Chapter 5, Object Modeling From use cases to class diagrams Model - PDF document

Object-Oriented Software Engineering Outline Chapter 5, Object Modeling ♦ From use cases to class diagrams ♦ Model and reality ♦ Activities during object modeling Using UML, Patterns, and Java ♦ Object identification ♦ Object types ! entity, boundary and control objects ♦ Object naming ♦ Abbott’s technique helps in object identification ♦ Users of class diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 From Use Cases to Objects: Why Functional From Use Cases to Objects Decomposition is not Enough Level 1 Use Case Scenarios Level 1 Level 1 Level 2 Use Cases Level 1 Use Cases Level 2 Level 2 Level 2 Level 2 Level 3 Use Cases Level 2 Use Cases Level 3 Level 3 Level 3 Level 3 Level 3 Level 3 Operations Operations Level 4 Level 4 Level 4 Level 4 A B A B Participating Participating Objects Objects Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Reality and Model Why models? ♦ Reality R: Real Things, People, Processes happening ♦ We use models during some time, Relationship between things ! To abstract away from details in the reality, so we can draw complicated conclusions in the reality with simple steps in the ♦ Model M: Abstractions from (really existing or only model thought of ) things, people , processes and relationships ! To get insights into the past or presence between these abstractions. ! To make predictions about the future Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Page 1

What is a “good” model? Models are falsifiable ♦ Relationships, which are valid in reality R, are also valid in model M. ! I : Mapping of real things in reality R to abstractions in the model M abbildet ♦ In the middle age people believed in truth (Interpretation) ♦ Models of reality cannot be true ! f M : relationship between abstractions in M ! f R : relationship between real things inR ♦ A model is always an approximation ♦ In a good model the following diagram is commutative: ! We must say “according to our knowledge”, or “with today’s knowledge” ♦ Popper (“Objective Knowledge): f M ! We can only build models from reality, which are “true” until, we M M have found a counter example (Principle of Falsification) " And even then we might stick with the model (“because it works quite I well in most settings”) I ♦ The falsification principle is the basis of software development R R f R ! The goal of prototypes, reviews and system testing is to falsify the software system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Models of models of models... Activities during Object Modeling ♦ Main goal: Find the important abstractions ♦ Modeling is relative. We can think of a model as reality and ♦ What happens if we find the wrong abstractions? can build another model from it (with additional ! Iterate and correct the model abstractions). ♦ Steps during object modeling The development of ! 1. Class identification …. Software-Systemes is a Transformation of " Based on the fundamental assumption that we can find abstractions f M2 ! 2. Find the attributes Models: M 2 M 2 Analysis, Design, ! 3. Find the methods Implementation,Testing ! 4. Find the associations between classes Analysis I 2 f M1 ♦ Order of steps M 1 M 1 ! Goal: get the desired abstractions Requirements ! Order of steps secondary, only a heuristic I 1 Elicitation ! Iteration is important R R f R Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Class Identification Class identification is an ancient problem ♦ Identify the boundaries of the system ♦ Objects are not just found by taking a picture of a scene or domain ♦ Identify the important entities in the system ♦ The application domain has to be analyzed. ♦ Class identification is crucial to object-oriented modeling ♦ Depending on the purpose of the system different objects might ♦ Basic assumption: be found ! 1. We can find the classes for a new software system (Forward ! How can we identify the purpose of a system? Engineering) ! Scenarios and use cases ! 2. We can identify the classes in an existing system (Reverse Engineering) ♦ Another important problem: Define system boundary. ♦ Why can we do this? ! What object is inside, what object is outside? ! Philosophy, science, experimental evidence Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Page 2

Pieces of an Object Model Object vs Class ♦ Classes ♦ Object (instance): Exactly one thing ♦ Associations (Relations) ! This lecture on Software Engineering ! Generic associations ♦ A class describes a group of objects with similar properties ! Canonical associations " Part of- Hierarchy (Aggregation) ! Game, Tournament, mechanic, car, database " Kind of-Hierarchy (Generalization) ♦ Object diagram: A graphic notation for modeling objects, classes ♦ Attributes and their relationships ("associations"): ! Detection of attributes ! Class diagram: Template for describing many instances of data. Useful for ! Application specific ! Attributes in one system can be classes in another system taxonomies, patters, schemata... ! Turning attributes to classes ! Instance diagram: A particular set of objects relating to each other. Useful ♦ Operations for discussing scenarios, test cases and examples ! Detection of operations ! Generic operations: Get/Set, General world knowledge, design patterns ! Domain operations: Dynamic model, Functional model Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Class identification How do you find classes? ♦ Finding objects is the central piece in object modeling ♦ Finding objects is the central piece in object modeling ! Learn about problem domain: Observe your client ♦ Approaches ! Apply general world knowledge and intuition ! Application domain approach (not a special lecture, examples): ! Take the flow of events and find participating objects in use cases " Ask application domain expert to identify relevant abstractions ! Try to establish a taxonomy ! Syntactic approach (today): ! Do a syntactic analysis of problem statement , scenario or flow of " Start with use cases. Extract participating objects from flow of events events " Use noun-verb analysis (Abbot’s technique) to identify components of ! Abbott Textual Analysis, 1983, also called noun-verb analysis the object model " Nouns are good candidates for classes ! Design patterns approach (Lecture on design patterns) " Verbs are good candidates for opeations " Use reusable design patterns ! Apply design knowledge: ! Component-based approach (Lecture on object design): " Distinguish different types of objects " Identify existing solution classes " Apply design patterns (Lecture on design patterns) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 How do you find classes? Finding Participating Objects in Use Cases ♦ Finding objects is the central piece in object modeling ♦ Pick a use case and look at its flow of events ! Learn about problem domain: Observe your client ! Find terms that developers or users need to clarify in order to ! Apply general world knowledge and intuition understand the flow of events ! Take the flow of events and find participating objects in use cases ! Look for recurring nouns (e.g., Incident), ! Try to establish a taxonomy ! Identify real world entities that the system needs to keep track of ! Apply design knowledge: (e.g., FieldOfficer, Dispatcher, Resource), " Distinguish different types of objects ! Identify real world procedures that the system needs to keep track " Apply design patterns (Lecture on design patterns) of (e.g., EmergencyOperationsPlan), ! Do a syntactic analysis of problem statement , scenario or flow of ! Identify data sources or sinks (e.g., Printer) events ! Identify interface artifacts (e.g., PoliceStation) ! Abbott Textual Analysis, 1983, also called noun-verb analysis ♦ Be prepared that some objects are still missing and need to be " Nouns are good candidates for classes found: " Verbs are good candidates for opeations " Model the flow of events with a sequence diagram ♦ Always use the user’s terms Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Page 3