PA103 - Object-oriented Methods for Design of Information Systems Introduction to object-oriented design © Radek Ošlejšek Fakulta informatiky MU oslejsek@fi.muni.cz PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 2Spring 2015 Lecture 1 / Part 1: Course Organization PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 3Spring 2015 Course Organization Prerequisites:  Knowledge of object-oriented programming principles  e.g. the basic Java, C++ or C# courses  Core knowledge of software engineering and UML  PB007 – Software Engineering I Follow-Up Courses:  PA104 – Team Project Leadership  PV167 – Project in Object-oriented Design of Information Systems  PA017 – Software Engineering II PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 4Spring 2015 Significant Changes in Courses Before 2012/2013: Since 2012/2013: PB007 System Analyses Design PA103 OO Methods for design of IS PV167 Project in OOD of IS PB007 Software Engineering I PA103 OO Methods for design of IS PV167 Project in OOD of IS cca1/3ofpreviouscontent UMLfundamentals Practical UM L m odeling SE Fundamentals OO principles, SW patterns, component systems, ... Component modeling, analysis and design patterns, extra-functional requirements PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 5Spring 2015 About the course Lectures: 1. Course organization, OO design vs. structured design, OO fundamentals, OO modeling vs. ER modeling 2. Interface as contract, introduction to components, from classes to components 3. Object Constraint Language 4. Software re-use, software patterns at various stages of software life cycle (analysis, design, architecture, coding). 5. Design patterns in detail. 6. Analysis patterns, Java patterns, anti-patterns. 7. Code refactoring („refactoring to patterns“). 8. Software architectures, architectural patterns. 9. Component systems. Qualitative attributes and their evaluation. 10. Object-oriented methods for software development, application of UML models in RUP. 11. Special methods and architectures: MDD, FDD, SOA, ... 12. Model-Driven Architecture (MDA), employing OCL in MDA. Evaluation:  Exam = multichoice test + practical question(s), 90 min.  Grades: A: 100-90 B: 89-80 C: 79–70 D: 69-60 E: 59-50 F: 49-0 PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 6Spring 2015 Lecture 1 / Part 2: Structured vs. Object-oriented Paradigms PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 7Spring 2015 Why models?  Information systems are always composed of data and operations, which are responsible for data manipulation and presentation to users  Many relationships => it's infeasible to treat a complex system as a whole  Modeling = controlling the complexity by the “divide et impera” principle Source: objekty.vse.cz PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 8Spring 2015 Structured Modelling Consistency between models Consistency within models  Separate functional and data models  Context diagram, data flow diagram, events, functional requirements, ...  Entity-relationship diagram, data vocabulary, ...  Continuous particularization of models  Consistency checking  Within models  Between models PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 9Spring 2015 Structured Modelling (cont.)  Functional hierarchies and data clustering help to organize functional and data models.  Still too complex relationships mainly between functional and data models. Source: objekty.vse.cz PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 10Spring 2015 OO Modelling  Division of system into objects handling data as well as operations => function-data dependencies are internal, hidden inside objects.  Object-to-object relationships are simplified.  Hierarchical clustering of objects/classes into packages and components brings even more “clarification” of the system. On the other hand, components bring much more complicated communication dependencies then objects/classes.  Network of objects and their relationships as opposed to layers in structured design PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 11Spring 2015 OO Modelling (cont.)  More models than in the case of structured modeling  Not all models, e.g. UML models, are always used. Some models are relevant to only selected phases of software life cycle and/or selected parts of the system.  Continuous particularization of models  Consistency checking  Inside models  Between models  Class diagram as the main model. Other models just help to design correct final class diagram.  Incremental and iterative development  complex life cycle management Consistency checking and particularization of models Use case diagram State machine diag. Interaction diag. Class and object diag. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 12Spring 2015 Lecture 1 / Part 3: OO Fundamentals PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 13Spring 2015 Objects  Object is the smallest unit combining (encapsulating) data and functions and instantiating classes.  Classes represent static view (design-time entities), while objects represent dynamic view (run-time entities)  Objects store data in field behind the “layer” of functions (operations).  Concrete data (values of fields) define object state.  Methods define behavior. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 14Spring 2015 Objects cooperation Structured program:  Code of procedures is allocated in memory before the program is executed. Procedures then read/write data and calls other procedures. OO program:  Objects are instantiated and removed dynamically. Initial object which is instantiated by OS or interpreter is responsible for the instantiation of other objects.  Nodes of invocation tree are dynamically allocated and removed.  Objects cooperate in order to successfully respond to method invocation.  Methods/objects can instantiate other objects.  Methods typically send messages to other objects by calling their methods and waiting for response.  Data and responsibilities are distributed among objects. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 15Spring 2015 Abstraction Proposal of suitable classification scheme is the key task for object-oriented analysis and design Abstraction = Classification of objects and classes PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 16Spring 2015 Abstraction (cont.)  Proposal of suitable classification scheme is the key task for object-oriented analysis and design.  How many classes is in the picture?  Trees, leaves, ...  Electronic devices vs mobile devices  Cats vs fast moving objects – how to classify the lion?  ... PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 17Spring 2015 Inheritance vs association Engineer CivilEngineer SoftwareEngineer B. Every software engineer has engineering skills A 1..n1..n B SoftwareEngineer Poet 1..n Engineer Workman A. Every software engineer is engineer  Inheritance can be always replaced by association.  New trend in higher (component) level is dependency injection  Association is more flexible because links are created at run-time.  Never use inheritance if object's role can vary in time, e.g. one day the SW engineering is rather poet while another day he/she is rather Workman  Objects can never change affiliated class (i.e. the type) during their life time! PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 18Spring 2015 Object role Every object instantiating sub-class must be always usable in the context of its super-class(es) Q: Is CarOwner always Person? Q: Is CarOwner always Car? Person CarOwner Car Person CarOwner Car 1 n PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 19Spring 2015 Types of object connections Object Connection - physical or conceptual link between objects. Denotes the possibility of (client) object to use services of another (server, supplying) object or to navigate the object. When the connection is established: • At design time – „really“ static connection – Embedded classes, inheritance, • At compile time – static connection – Association, aggregation, composition • At runtime – dynamic connection – Dependency – Methods call ClassA ClassB attribute print () { ... attribute.foo(); ... } ClassB foo () { ... } Static connection Dynamic connection Runtime call PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 20Spring 2015 Polymorphism  Concept from the theory of types  „+“ means the same for real as well as for integer  „+“ is has different implementation (behavior) for real and integer  Polymorphism is a product of inheritance and dynamic connection  Sub-class inherits name of the method  Biding the method name with its implementation is accomplished at runtime. ClassA print () { echo „A“ } ClassB print () { echo „B“ } ClassA object; object = new ClassB(); object.print(); Q: What is the output of the following code? PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 21Spring 2015 Lecture 1 / Part 4: Software Architectures – Key Concepts PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 22Spring 2015 Multi-layered Architecture (I)  Based on structured models  Suitable for client-server applications  Multi-layered vs multi-tier Architecture: The concepts of layers and tiers are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up your software solution, while a tier is a physical structuring mechanism for the system infrastructure Application/logic layer Presentation layer Data layer clientserver PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 23Spring 2015 Multi-layered Architecture (II)  Typical features:  Strong dependences in DB  Communication through DB  Autonomous clients  Complex SQL queries  Realization:  Forms (HTML, XML, CSS, ...)  Scripting (PHP, ASP, ...)  Relational databases  Common use:  PHP-based web pages  Client-server applications DatamodelFunctionalmodel Relational database Relational database Application script Application script Client Client Application layer Presentation layer Data layer Client Client Client Client Application script Application script Application script Application script Interconnection through data layer: + rapid implementation + utilization of known development processes + proven technologies - single table is handled by multiple scripts - complex database scheme - poor scalability PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 24Spring 2015 Multi-layered Architecture (III)  Naive adoption of multi-layered architecture to OO design  Interaction  Upper layers play the role of clients to their lower layers  Lower layers play the role of severs to their upper layers  Object should not depend on objects from upper layers Persistent objects Persistent objects Business objects Business objects Presentation objects Presentation objects Application layer Presentation layer Data layer  Q: Where to verify the input data? 1) In the presentation layer, application layer just handles the data by passing them to data layer.  Data verification is not typical responsibility of presentation objects.  Duplication of the verification code across many presentation objects.  Application layer relay on valid data => is dependent on presentation layer 2) In the application layer, presentation layer just reads the input and show results.  Intensive client-server communication, slow response PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 25Spring 2015 Multi-layered Architecture (IV)  Presentation objects  User input/output  Business objects  Forms conceptual structure of the system  Independent from presentation  Independent from data store  Persistent objects  Forms persistent layer of the system  Data storage and their accessibility  Locking  Integrity checking Persistent objects Persistent objects Business objects Business objects Presentation objects Presentation objects Application layer Presentation layer Data layer PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 26Spring 2015 Multi-layered Architecture (V)  Utilization of component technologies  Interconnection through the application layer  Handling complexity of connection via components  Typical feature:  Data separation  Context management in the application layer  Realization:  CORBA, DCOM, SOAP/XML Interconnection through application layer: + robustness and scalability + maintenance and extensions + parallel development + easy integration with other systems - complex application layer - require modern approaches for development and management - it's not feasible to utilize advanced features of modern relational databases Application component Application component Client Client Application layer Presentation layer Data layer Client Client Client Client Application component Application component Application component Application component Data Data Data Data Data Data Relational database Application script Client Application layer Presentation layer Data layer Client Client Application script Application script PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 27Spring 2015 Multi-layered Architecture (VI) ShoppingCart displayContent () { SELECT * FROM ... } <> ShoppingCart addGoods () { ... } removeGoods () { ... } getGoods () { ... } <> Goods getPrice () { ... } getSize () { ... } <> ShoppingCartGUI ShippongCart cart; displayContent () { for i in cart.getGoods() { ... } } Presentation, application and data logic in single class PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 28Spring 2015 ORM: Object-Relational Mapping  In the real world, the OO software is often combined with relational databases  Relational databases present proven, tuned and highly optimized technology (efficiency, scalability, data integrity, etc.)  => It's necessary to map object model to entity-relational model  => Object-Relational Mapping, ORM  Java Persistence API, Hibernate, …  Note1: Although object databases exists a long time, they still play a minority role.  Note2: NoSQL databases represent a new trend in dynamic data storage, e.g. in facebook and other social sites. They have no fixed relational scheme. Instead, they the information scheme is based on ontologies (SQRL, OWL, ...). Query languages, e.g. SparQL, SQWRL enables to query data and also support automatic inference. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 29Spring 2015 ORM: Tables vs. objects (I)  Relational Technology  Data are stored in tables  Rows represent records, columns represent values of concrete types  Tables are connected by relations  Primary/foreign keys  Cardinality of relations  Relational algebra and SQL for data retrieval  OO technology  Classes contain data as well as operations  Associations with cardinality  Inheritance  Associations and objects are in memory => data manipulation is based on object interaction.  Ex.: get all students enrolled in given course – difference between SQL and object interaction PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 30Spring 2015 ORM: The Basic Mapping Principles  Persistence class = entity set (table)  Object = entity (record, line in the table)  Primitive class attribute = entity attribute (column in the table)  Key is selected from primitive attributes or is created a new one  Association/aggregation/composition defines relation (interconnection of tables by means of foreign keys)  M:N associations must be decomposed  Mapping of class inheritance:  1:1 mapping  Combining to super-class  Splitting to sub-classes PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 31Spring 2015 ORM: class diagram vs. ER diagram Relational scheme Persistent objects DB managers (handle SQL) PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 32Spring 2015 Inheritance mapping: 1:1  Every class becomes a table  All tables share the primary key  Discriminator becomes an attribute  Queries search in the table of the concrete sub-class and its super-class  Data of single instance is stored in multiple tables  Complex data retrieval PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 33Spring 2015 Inher. mapping: combining to super-class  Attributes of all sub-classes are stored in single table  Some attributes can by NULL  4NF violation  Suitable for class hierarchies with few sub-classes and few attributes PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 34Spring 2015 Inheritance mapping: splitting to sub-classes  Attributes of super-class are duplicated in tables of all (non-abstract) sub-classes.  Suitable if:  Super-class has few attributes  There exist a lot of sub-classes (spreading class hierarchy)  Sub-classes have a lot of specific attributes PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 35Spring 2015 Association vs. entity relation (I) ico name Company id name Person ico name Company id name Person job_id company_ico person_id salary Job PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 36Spring 2015 Association vs. entity relation (II) -name Person -ico -name Company 0..* 0..* employs 0..* 0..* ico name Company id name Person Note (often mistake): The Person class has no attribute id in the class model !!! • Q: Is this model directly implementable? • A: Yes. As opposed to ER model, M:N relationships pose no problem. • For example, the Company class can include an array of Persons and vice versa. On the other hand, there are many ways to elaborate this initial decomposition. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 37Spring 2015 Association vs. entity relation (III)  Approach 1, model 1: We prefer one direction  Company stores persons (employees) in array  Person has no link to its companies  Problem: There are many companies registered in the system. Where they are stored? How we get link to concrete address if we have no query mechanism? -name Person -ico -name Company 0..* 0..* employs 0..* 0..* -ico -name -employees : Person[] +getEmployees() : Person [] Company -name Personemployes * ** * PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 38Spring 2015 Association vs. entity relation (IV)  Approach 1, model 2: Single JobsMngr stores all the companies and mediates access to companies and their employees.  Q: Is the getCompanies() method implementable? How effectively? -name Person -ico -name Company 0..* 0..* employs 0..* 0..* -companies : Company[] +getEmployees(c : Company) : Person [] +getCompanies(p : Person) : Company [] JobsMngr -ico -name -employees : Person[] +getEmployees() : Person [] Company -name Person* * * employes * * * PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 39Spring 2015 Association vs. entity relation (V)  Approach 1, model 2: getCompanies() is less effective /O(n*n)/ than getEmployess() /O(n)/. The reason is that each invocation of the company.contains() searches in the list of employees. -companies : Company[] +getEmployees(c : Company) : Person [] +getCompanies(p : Person) : Company [] JobsMngr -ico -name -employees : Person[] +getEmployees() : Person [] Company -name Person * * * * employes * * PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 40Spring 2015 Association vs. entity relation (VI)  Approach 2, model 1: Bidirectional association  Pros: Clear responsibilities. Responsibilities are uniformly distributed to all classes  Cons: Very complicated memory management, especially without automatic “garbage collection“ -name Person -ico -name Company 0..* 0..* employs 0..* 0..* -name -companies : Company[] +getCompanies() : Company [] Person -ico -name -employees : Person[] +getEmployees() : Person [] Company -companies : Company[] -employees : Person[] +getCompany(c : Company) : Company +getEmployee(p : Person) : Person <> JobsMngr 0..* 0..* 0..* 0..* employs 0..* 0..* 0..* 0..* PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 41Spring 2015 Association vs. entity relation (VII)  Approach 2, model 2: Preserved bidirectional association, responsibility located in a big “God” object.  Pros: (a) Management code located in JobsMngr => maintainability. (b) Efficiency.  Q: Where to store salary? -name Person -ico -name Company 0..* 0..* employs 0..* 0..* -companies : Map> -employees : Map> +getCompanies(e : Person) : Set +getEmployees(c : Company) : Set <> JobsMngr -ico -name Company -name Person * * * * PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 42Spring 2015 Association vs. entity relation (VIII)  Approach 3, model 1: Helper class (similar to the association entity in ERD). This class links concrete couple and stores additional data related to the couple.  Q: Putting jobs to list/array is not optimal. Do you know better solution? -name Person -ico -name Company 0..* 0..* employs 0..* 0..* -jobs : Job[] +getCompanies(p : Person) : Compan... +getEmployees(c : Company) : Person [] <> JobsMngr -salary -company : Company -employee : Person +getCompany() : Company +getEmployee() : Person +getSalary() : double Job -ico -name Company -name Person* 1 * 1 1 ** 1 1* 1* PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 43Spring 2015 Association vs. entity relation (IX)  Approach 3, model 2: Maps provide efficient access to the individual sets of companies and employees as well as to concrete jobs (couples). On the other hand, this solution is unnecessary complicated in many situations. => Designer has to choose the best solution for concrete context=> Designer has to choose the best solution for concrete context -salary -company : Company -employee : Person +getCompany() : Company +getEmployee() : Person +getSalary() : double Job -ico -name Company -name Person -companies : Map> -employees : Map> +getJobs(p : Person) : Set +getJobs(c : Company) : Set +getCompanies() : Set +getEmployees() : Set <> JobsMngr * 1 * * 1 * companies employees 1 1 PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 44Spring 2015 Conclusion: Entity-relational paradigm is definitely not the same as object-oriented paradigm. Therefore, ER diagrams are definitely not the same as UML class diagrams, although they look similar. PA103: OO Methods for Design of Information Systems © R. Ošlejšek, FI MU 45Spring 2015 Questions? Three Engineers There are three engineers in a car going for a drive. The first is a mechanical engineer, the second an electronics engineer and the third is a software engineer. Fortunately, the mechanical engineer is driving because the brakes fail as they are going downhill. The mechanical engineer eventually brings the car safely to a halt and gets out to examine the hydraulic systems. The electronics engineer gets out and checks the body computer, ABS system and the power train CAN bus. The software engineer stays in the car and when queried about it says that they should all just get back in the car and see if it happens again!