Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 5, Analysis: Object Modeling
Outline ¨ ¨ ¨ ¨ From use cases to objects Object modeling Class vs instance diagrams Attributes Operations and methods Links and associations Examples of associations Two special associations w Aggregation w Inheritance Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Products of requirements elicitation and analysis Requirements Elicitation system specification : Model Analysis analysis model : Model Next chapter System Design system model : Model Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems Next chapter 3
The analysis model use case diagram: View class diagram: View functional model: Model object model: Model statechart diagram: View sequence diagram: View dynamic model: Model analysis model: Model Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
From Use Cases to Objects Level 1 Use Case Level 1 Level 2 Level 3 A Level 3 Level 4 Level 2 Use Cases Level 2 Level 3 Use Cases Operations Level 4 B Participating Objects Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
From Use Cases to Objects: Why Functional Decomposition is not Enough Scenarios Level 1 Level 2 Level 3 A Level 3 Level 4 Level 1 Use Cases Level 2 Use Cases Operations Level 4 B Participating Objects Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
From Use Cases to Objects Starting from use cases and scenarios, analysis activities performed to obtain the analysis model are: w Identifying entity objects w Identifying boundary objects w Identifying control objects w Mapping use cases to objects w Identifying associations among objects w Identifying object attributes w Modeling behavior with statecharts w Modeling generalization relationships w Reviewing the analysis model Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
Object Modeling ¨ ¨ Main goal: Find the important abstractions What happens if we find the wrong abstractions? w Iterate and correct the model ¨ Steps during object modeling w 1. Class identification t Based on the fundamental assumption that we can find abstractions w 2. Find the attributes w 3. Find the methods w 4. Find the associations between classes ¨ Order of steps w Goal: get the desired abstractions w Order of steps secondary, only a heuristic w Iteration is important Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
Class identification ¨ ¨ Class identification is crucial to object-oriented modeling Objects are not just found by taking a picture of a scene or domain The application domain has to be analyzed. Identify the boundaries of the system w What object is inside, what object is outside? ¨ Identify the important entities in the system w Depending on the purpose of the system different objects might be found t t How can we identify the purpose of a system? Scenarios and use cases Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
Pieces of an Object Model ¨ ¨ Classes Associations (Relations) w Part of- Hierarchy (Aggregation) w Kind of-Hierarchy (Generalization) ¨ Attributes w w ¨ Detection of attributes Application specific Attributes in one system can be classes in another system Turning attributes to classes Methods w Detection of methods w Generic methods: General world knowledge, design patterns w Domain Methods: Dynamic model, Functional model Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
UML: Class and Instance Diagrams Inspector joe: Inspector mary: Inspector Class Diagram anonymous: Inspector Instance Diagram Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11
Attributes and Values Inspector name: string age: integer joe: Inspector name = “Joe” age = 24 Bernd Bruegge & Allen Dutoit mary: Inspector name = “Mary” age = 18 Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12
Links and Associations ¨ ¨ Links and associations establish relationships among objects and classes. Link: w A connection between two object instances. A link is like a tuple. w A link is an instance of an association ¨ Association: w Basically a bidirectional mapping. w One-to-one, many-to-one, one-to-many, w An association describes a set of links like a class describes a set of objects. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
1 -to-1 and 1 -to-many Associations Hascapital Country name: String City name: String One-to-one association Workorder Sticky. Note * schedule() x: Integer y: Integer z: Integer One-to-many association Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
Object Instance Diagram Example for 1 -to-many : Sticky : Work. Order x, y, z=(-1, 0, 5) : Sticky x, y, z=(1, 10, 1) : Sticky x, y, z=(10, 1, 2) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
Many-to-Many Associations Mechanics Bernd Bruegge & Allen Dutoit * Work on * Plane Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16
Do UML associations have direction? A association between two classes is by default a bi-directional mapping. A t t B Class A can access class B and class B can access class A Both classes play the agent role. If you want to to make A a client, and B a server, you can make the Name of association unidirectional. The arrowhead. Name Direction server role: points to the A accesses Association Direction B Class A ( the “client”) accesses class B (“the server”). B is also called navigable Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
Aggregation ¨ ¨ ¨ Models "part of" hierarchy Useful for modeling the breakdown of a product into its component parts (sometimes called bills of materials (BOM) by manufacturers) UML notation: Like an association but with a small diamond indicating the assembly end of the relationship. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18
Aggregation Automobile Engine serial number year manufacturer model color weight horsepower volume on off drive purchase 3, 4, 5 Wheel diameter number of bolts Bernd Bruegge & Allen Dutoit * Brakelight on off 2, 4 Door open close Battery amps volts charge discharge Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19
Inheritance ¨ ¨ ¨ Models "kind of" hierarchy Powerful notation for sharing similarities among classes while preserving their differences UML Notation: An arrow with a triangle Cell Blood. Cell Red Bernd Bruegge & Allen Dutoit White Muscle. Cell Smooth Striate Nerve. Cell Cortical Object-Oriented Software Engineering: Conquering Complex and Changing Systems Pyramidal 20
Aggregation vs Inheritance ¨ Both associations describe trees (hierarchies) w Aggregation tree describes a-part-of relationships (also called and-relationship) w Inheritance tree describes "kind-of" relationships (also called or-relationship) ¨ Aggregation relates instances (involves two or more different objects) ¨ Inheritance relates classes (a way to structure the description of a single object) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21
Other Associations ¨ Uses: w A subsystem uses another subsystem (System Design) ¨ Contains: w Sometimes called “spatial aggregation” w. . . contains. . . w Example: A UML package contains another UML package ¨ Parent/child relationship: w. . . is father of. . . w. . . is mother of. . . ¨ Seniority: w. . . is older than. . . w. . . is more experienced than. . . Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22
Object Types ¨ Entity Objects w Represent the persistent information tracked by the system (Application domain objects, “Business objects”) ¨ Boundary Objects w Represent the interaction between the user and the system ¨ Control Objects: w Represent the control tasks performed by the system ¨ Having three types of objects leads to models that are more resilient to change. w The boundary of a system changes more likely than the control w The control of the system change more likely than the application domain ¨ Object types originated in Smalltalk: w Model, View, Controller (MV) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23
Example: 2 BWatch Objects ¨ ¨ UML provides several mechanisms to extend the language UML provides the stereotype mechanism to present new modeling elements <<entity>> Year <<entity>> Month <<control>> Change. Date. Control <<boundary>> Button. Boundary <<boundary>> LCDDisplay. Boundary <<entity>> Day Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24
Roles ¨ ¨ ¨ A role name is the name that uniquely identifies one end of an association. A role name is written next to the association line near the class that plays the role. When do you use role names? w Necessary for associations between two objects of the same class w Also useful to distinguish between two associations between the same pair of classes ¨ When do you not use role names? w If there is only a single association between a pair of distinct classes, the names of the classes serve as good role names Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25
Example of Role Problem Statement : A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person. Person Creates Workorders Person Bernd Bruegge & Allen Dutoit * * inspector Creates Workorders repairperson Person Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26
Roles in Associations ¨ Client Role: w An object that can operate upon other objects but that is never operated upon by other objects. ¨ Server Role: w An object that never operates upon other objects. It is only operated upon by other objects. ¨ Agent Role: w An object that can both operate upon other objects and be operated upon by other objects. An agent is usually created to do some work on behalf of an actor or another agent. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
How do you find classes? ¨ Learn about problem domain: Observe your client Apply general world knowledge and intuition Do a textual analysis of scenario or flow of events (Abbott Textual Analysis, 1983) Take the flow of events and find participating objects in use cases Apply design patterns Try to establish a taxonomy ¨ Nouns are good candidates for classes ¨ ¨ ¨ Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31
![Mapping parts of speech to object model components [Abbot 1983] Part of speech Model](https://present5.com/presentation/69941a1e7a4bad15a09c7b190279851f/image-29.jpg "Mapping parts of speech to object model components [Abbot 1983] Part of speech Model")
Mapping parts of speech to object model components [Abbot 1983] Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
Example: Scenario from Problem Statement ¨ ¨ ¨ Jim Smith enters a store with the intention of buying a toy for his 3 year old child. Help must be available within less than one minute. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. Jim selects a dangerous toy which is unsuitable for the child. The store owner recommends a more yellow doll. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33
Object Modeling in Practice: Class Identification Foo Balance Customer. Id Deposit() Withdraw() Get. Balance() Class Identification: Name of Class, Attributes and Methods Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34
Object Modeling in Practice: Encourage Brainstorming “Dada” Foo Balance Customer. Id Deposit() Withdraw() Get. Balance() Account Balance Customer. Id Naming is important! Bernd Bruegge & Allen Dutoit Deposit() Withdraw() Get. Balance() Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35
Object Modeling in Practice: A Banking System Account Bank Name Balance Account. Id Customer * Has Deposit() Withdraw() Get. Balance() Name Customer. Id Find New Objects Iterate on Names, Attributes and Methods Find Associations between Objects Label the associations Determine the multiplicity of the associations Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36
Object Modeling in Practice: Categorize! Account Bank * Name Balance Account. Id Customer * Has Deposit() Withdraw() Get. Balance() Name Customer. Id Savings Account Checking Account Mortgage Account Withdraw() Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37
Avoid Ravioli Models Account Bank Name * Balance Account. ID Customer * Has Deposit() Withdraw() Get. Balance() Name Customer. Id Don’t put too many classes into the same package: 7+-2 (or even 5+-2) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38
How to identify entity objects ¨ ¨ ¨ ¨ terms that developers or users need to clarify in order to understand the use case recurring nouns in the use cases (e. g. , Incident) real-world entities that the system needs to keep track of (e. g. , Field. Officer, Dispatcher, Resource) real-world activities that the system needs to keep track of (e. g. , Emergencyoperationsplan) use cases (e. g. , Report. Emergency) data sources or sinks (e. g. , Printer) always use the user’s terms Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39
How to identify boundary objects ¨ ¨ Identify forms and windows the users needs to enter data into the system (e. g. , Emergency. Report. Form, Report. Emergency. Button). Identify notices and messages the system uses to respond to the user (e. g. , Acknowledgment. Notice). Do not model the visual aspects of the interface with boundary objects (user mock-ups are better suited for that). Always use the user’s terms for describing interfaces as opposed to terms from the implementation technology. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40
How to identify control objects ¨ Identify one control object per use case or more if the use case is complex and if it can be divided into shorter flows of events. ¨ Identify one control object per actor in the use case. ¨ The life span of a control object should be extent of the use case or the extent of a user session. If it is difficult to identify the beginning and the end of a control object activation, the corresponding use case may not have a well-defined entry and exit condition. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41
An example: the Report. Emergency use case Use case name: Report. Emergency Entry condition: The Field. Officer activates the “Report Emergency” function of her terminal. Flow of events: 1. FRIEND responds by presenting a form to the officer. The form includes an emergency type menu (Genera 1 emergency, fire, transportation), a location, incident description, resource request, and hazardous material fields. 2. The Field. Officer fills the form, by specifying minimally the emergency type and description fields. The Field. Officer may also describes possible responses to the emergency situation and request specific resources. Once the form is completed, the Field. Officer submits the form by pressing the “Send Report” button, at which point, the Dispatcher is notified. 3. The Dispatcher reviews the information submitted by the Field. Of f icer and creates an incident in the database by invoking the Open. Incident use case. Al 1 the information contained in the Field. Officer’s form is automatically included in the incident. The Dispatcher selects a response by allocating resources to the incident (with the Allocate. Resources use case) and acknowledges the emergency report by sending a FRIENDgram to the Field. Officer. Exit condition: Bernd Bruegge & Allen Dutoit The Field. Officer receives the acknowledgment and the selected response. Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42
Entity objects in the example Dispatcher Police officer who manages Incidents. A Dispatcher opens, documents, and closes Incidents in response to Emergency Reports and other communication with Field. Officers. Dispatchers are identified by badge numbers. Emergency. Report Initial report about an Incident from a Field. Officer to a Dispatcher. An Emergency. Report usually triggers the creation of an Incident by the Dispatcher. An Emergency. Report is composed of a emergency level, a type (fire, road accident, or other), a location, and a description. Fieldofficer Police or fire officer on duty. A Field. Officer can be allocated to, at most, one Incident at a time. Field. Officers are identified by badge numbers. NOT TRUE in this UC. Here Field. Officers are actors, they can be entity objects in the Allocateresource UC Incident Situation requiring attention from a Field. Officer. An Incident may be reported in the system by a Field. Officer or anybody else external to the system. An Incident is composed of a description, a response, a status (open, closed, documented), a location, and a number of Field. Officers. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43
Boundary Objects in the example Acknowledgment. Notice used for displaying the Dispatcher’s acknowledgment to the Field. Officer. Dispatcher. Station Computer used by the Dispatcher. Report. Emergency. Button used by a Field. Officer to initiate the Report. Emergency use case. Emergency. Report. Form used for the input of the Report. Emergency. This form is presented to the Field. Officer on the Field. Officerstation when the “Report Emergency” function is selected. The Emergency. Report. Form contains fields for specifying all attributes of an emergency report and a button (or other control) for submitting the form once it is completed. Field. Officer. Station Mobile computer used by the Field. Officer. Incident Form used for the creation of Incidents. This form is presented to the Dispatcher on the Dispatcher. Station when the Emergency. Report is received. The Dispatcher also uses this form to allocate resources and to acknowledge the Field. Officer’s report. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44
Control objects in the example Report. Emergency. Control Manages the report emergency reporting function on the Field. Officerstation. This object is created when the Field. Officer selects the “Report Emergency” button. It then creates an Emergency. Report. Fom and presents it to the Field. Officer. After submission of the form, this object then collects the information from the form, creates an Emergency. Report, and forwards it to the Dispatcher. The control object then waits for an acknowledgment to come back from the Dispatcher. Station. When the acknowledgment is received, the Report. Emergency. Control object creates an Acknowledgment. Notice and displays it to the Fie 1 d. Officer. Manage. Emergency. Control Manages the report emergency reporting function on the Dispatcher. Station. This object is created when an Emergency. Report is received. It then creates an Incident. Fom and displays it to the Dispatcher. Once the Dispatcher has created an Incident, allocated Resources, and submitted an acknowledgment, Manage. Emergency. Control forwards the acknowledgment to the Field. Officerstation. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45
Summary In this lecture, we reviewed the construction of the object model from use case model. In particular, we described: ¨ Identification of objects (entity, boundary, control) ¨ Refinement of objects with attributes and operations ¨ Generalization of concrete classes ¨ Identification of associations ¨ Reduction of multiplicity using qualification. In the next lecture, we describe the construction of the dynamic model from the use case and object models. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 46
Скачать презентацию Conquering Complex and Changing Systems Object-Oriented Software Engineering
69941a1e7a4bad15a09c7b190279851f.ppt