Product Design ObjectOriented analysis and design Prof Yoram

Product Design Object-Oriented analysis and design Prof. Yoram Reich School of Mechanical Engineering Faculty of Engineering Tel Aviv University Copyright © 2005 Reich This presentation includes material copyrighted by others. Please do not distribute. Copyright © 2003 -2005 Yoram Reich

Origin of OO and the way we practice it today n n n A response of the software industry to manage complex software projects Several methods emerged and consolidated into a standard: UML – Uniform Modeling Language New contenders: u u OPM – Object Process Methodology … Copyright © 2003 -2005 Yoram Reich 2

Object n n An object has a label and attributes There are methods that can be done on objects There is an interface between the object and the world outside it that allows executing the methods Examples: u u n n A point A bicycle An object in the real world is complex An object in OO analysis is a model that includes what is necessary for our task Copyright © 2003 -2005 Yoram Reich 3

Class n n A description of a scheme that describes objects – “type” Examples: u u u Point class Bicycle class Polygon objects abstract n n Polygon class Attributes Vertices Border color Fill pattern Operations Draw Erase Move A class is not a set of objects Object creation from a class - instantiation Copyright © 2003 -2005 Yoram Reich 4

Class: Visibility Prefixes n UML visibility prefixes (used for information hiding) u Prefix + indicates that an attribute or operation is public F u Prefix – denotes that the attribute or operation is private F u Visible only in the class in which it is defined Prefix # denotes that the attribute or operation is protected F n Visible everywhere Visible either within the class in which it is defined or within subclasses of that class Example: u Class diagram with visibility prefixes added 4 Attribute account. Balance is visible only within the Bank Account Class 4 Operations deposit and withdraw are accessible from anywhere within the software product Copyright © 2003 -2005 Yoram Reich Bank Account Class - account. Balance + deposit( ) + withdraw( ) 5

Class diagram n Classes and their interrelations Copyright © 2003 -2005 Yoram Reich 6

Class hierarchy and Inheritance Polymorphic method/operation: This method will be called the same in different objects but might be implemented differently. Helps understanding and ease of references. Copyright © 2003 -2005 Yoram Reich 7

Multiple inheritance Copyright © 2003 -2005 Yoram Reich 8

Concrete and abstract classes Serves to structure the problem but is not implemented. This method will be called the same in different objects but might be implemented differently. Helps understanding and ease of references. Implemented in the final system. Copyright © 2003 -2005 Yoram Reich 9

Aggregation n = Example: “A car consists of a chassis, an engine, wheels, and seats” The open diamonds denote aggregation 4 Aggregation means part–whole relationship = The diamond is placed at the “whole” (car) end, not the “part” (chassis, engine, wheels, or seats) end of the line connecting a part to the whole Copyright © 2003 -2005 Yoram Reich 10

Recursive aggregation Copyright © 2003 -2005 Yoram Reich 11

Composition n Aggregation example: Every chess board consists of 64 squares n This relationship goes further u It is an instance of composition, a stronger form of aggregation n Aggregation u Models the part–whole relationship Composition u Also models the part–whole relationship but, in addition, u Every part may belong to only one whole, and u If the whole is deleted, so are the parts Example: A number of different chess boards u Each square belongs to only one board u If a chess board is thrown away, all 64 squares on that board go as well Composition is depicted by a solid diamond n n n Copyright © 2003 -2005 Yoram Reich 12

Composition and Aggregation Copyright © 2003 -2005 Yoram Reich 13

Association: from objects to classes Bounded by 2 Copyright © 2003 -2005 Yoram Reich

Association as a class n An example of association: n A radiologist consults a lawyer u n The optional navigation triangle shows the direction of the association The association between the two classes may be modeled as a class u Example: Suppose the radiologist consults the lawyer on a number of occasions, each one for a different length of time F A class diagram is needed such as that depicted in the next slide Copyright © 2003 -2005 Yoram Reich 15

A complicated diagram Copyright © 2003 -2005 Yoram Reich 16

Exercise: What is this? A graph editor Copyright © 2003 -2005 Yoram Reich 17

Right now window is defined by 2 points explicitly: (x 1, y 1), (x 2, y 2). An alternative definition is that it would be defined by two points whose type is of point type. In this case, it makes sense to connect the point and window alternative classes by an aggregation link. Class diagram windowing system Copyright © 2003 -2005 Yoram Reich 18

Class diagram Copyright © 2003 -2005 Yoram Reich 19

UML – Uniform Modeling Language n n The standard notation for drawing OO diagrams Consist of several diagrams: u Structured aspect: Use cases diagram F Static diagram – Class diagram F u Dynamic aspect F Interaction diagrams • Sequence diagram • Collaboration diagram F u State diagram Implementation aspect Package diagram F Component diagram F Deployment diagram F Copyright © 2003 -2005 Yoram Reich 21

CRC (Class Responsibility Collaborators) cards n n n A social process in which project participants work with scenarios and 3 x 5 in cards to identify classes, their responsibility in different scenarios and their class collaborators The cards merely support quick addition/removal/modification of classes as well as their interaction with respect to different scenarios Reminiscent of brainstorming (e. g. , deep dive) Copyright © 2003 -2005 Yoram Reich 23

Now to additional examples… Copyright © 2003 -2005 Yoram Reich 25

Use-Case Diagrams n A use case is a model of the interaction between u u External users of a product (actors) and The product itself F n n More precisely, an actor is a user playing a specific role A use-case diagram is a set of use cases Generalization of actors is supported u The open triangle points toward the more general case Copyright © 2003 -2005 Yoram Reich 26

Stereotypes n n A stereotype in UML is a way of extending UML There could be numerous stereotypes: u The «include» stereotype The names of stereotypes appear between guillemets u Example: «This is my own construct» Example: u All three primary U. S. tax forms need to be printed u The other three use cases incorporate Print Tax Form Copyright © 2003 -2005 Yoram Reich 27

Stereotypes (continued) n n In the «extend» relationship, one use case is a variation

Complex use case diagram Copyright © 2003 -2005 Yoram Reich 29

Interaction Diagrams n Interaction diagrams show objects interact with one another n UML supports two types of interaction diagrams u u Sequence diagrams Collaboration diagrams Copyright © 2003 -2005 Yoram Reich 30

Sequence Diagrams n n A message is optionally followed by a message sent back to the object that sent the original message Even if there is a reply, it is not necessary that a specific new message be sent back u n n Instead, a dashed line ending in an open arrow indicates a return from the original message, as opposed to a new message Iteration an indeterminate number of times is modeled by an asterisk (Kleene star) Example: Elevator *move up one floor u The message means: “move up zero or more floors” An object can send message to self u A self-call Example: u The elevator has arrived at a floor u The elevator doors open and a timer starts u At the end of the timer period the doors close again u The elevator controller sends a message to itself to start its timer — this selfcall is shown in the UML diagram Copyright © 2003 -2005 Yoram Reich 31

Collaboration Diagrams n Collaboration diagrams are equivalent to sequence diagrams u All the features of sequence diagrams are equally applicable to collaboration diagrams n Use a sequence diagram when the transfer of information (and not timing) is the focus of attention n Use a collaboration diagram when concentrating on the classes Copyright © 2003 -2005 Yoram Reich 32

Collaboration Diagrams n n Object: The objects interacting with each other in the system. Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction. Relation/ association from class diagram Copyright © 2003 -2005 Yoram Reich 33

Statecharts n n = An event also causes transitions between states Example: The receipt of a message The elevator is in state Elevator Moving 4 It performs an operation: Move up one floor while guard [no message received yet] is true, until it receives message Elevator has arrived at floor = = Receipt of this message [event] causes the guard to be false It also enables a transition to state Stopped at Floor 4 In this state, performs activity Open the elevator doors Copyright © 2003 -2005 Yoram Reich 34

Statecharts n There are two places where an operation can be performed in a statechart u When a state is entered F u As part of a transition F n u n Action Technical difference: u n Activity An activity can take several seconds An action takes places essentially instantaneously An event can be specified in terms of words like “when” or “after” Example: u when (cost > 1000) or after (2. 5 seconds) Copyright © 2003 -2005 Yoram Reich 35

Statecharts n = = Superstates combine related states States A, B, C, and D all have transitions to Next State Combine them into superstate ABCD Combined 4 Now there is only one transition 4 The number of arrows is reduced from four to only one = States A, B, C, and D all still exist in their own right Copyright © 2003 -2005 Yoram Reich 36

Case Study: Elevator analysis with OO Copyright © 2003 -2005 Yoram Reich 37

Steps of OOA (Object Oriented Analysis) 1. Use-case modeling u Determine how the product is used (without regard to sequencing) 2. Class modeling (“object modeling”) u Determine the classes, their attributes and the interrelationships u Purely data-oriented 3. Dynamic modeling u Determine the actions performed by or to each class u Purely action-oriented n Iterative process Copyright © 2003 -2005 Yoram Reich 38

Elevator Problem: OOA n 1. Use-Case Modeling u Use case: Generic description of overall functionality Scenario: Instance of a use case Get comprehensive insight into behavior of product u n Copyright © 2003 -2005 Yoram Reich 39

Normal Scenario Copyright © 2003 -2005 Yoram Reich 40

Exception Scenario Copyright © 2003 -2005 Yoram Reich 41

Class Modeling n n Extract classes and their attributes Represent them using an class diagram Deduce the classes from use cases and their scenarios Often there are many scenarios u Possible danger: too many candidate classes Copyright © 2003 -2005 Yoram Reich 42

Two Approaches to Class Modeling n Noun extraction u n Always works CRC classes

Noun Extraction n Stage 1. Concise Problem Definition u Define product in single sentence F n Buttons in elevators and on the floors control the motion of n elevators in a building with m floors. Stage 2. Informal Strategy u Incorporate constraints, express result in a single paragraph F Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. See how the sentence in stage 1 transformed itself into the paragraph in stage 2. Copyright © 2003 -2005 Yoram Reich 44

Noun Extraction (cont) n Stage 3. Formalize the Strategy u Identify nouns in informal strategy. Use nouns as candidate classes Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. F F n Nouns u u u n n button, elevator, floor, movement, building, illumination, request, door floor, building, door are outside problem boundary — exclude movement, illumination, request are abstract nouns — exclude (may become attributes or other things) Candidate classes: Elevator and Button Subclasses: Elevator Button and Floor Button Copyright © 2003 -2005 Yoram Reich 45

First Iteration of Class Diagram n Problem u u Buttons do not communicate directly

Second Iteration of Class Diagram n All relationships are now 1 -to-n u u Makes design and implementation easier (makes system operation less robust – everything depends on one controller) Copyright © 2003 -2005 Yoram Reich 47

CRC Cards n n Used since 1989 for OOA For each class, fill in card showing u u n Strength u n Name of Class Functionality (Responsibility) List of classes it invokes (Collaboration) Now automated (CASE tool component) – but this looses its flexibility When acted out by team members, powerful tool for highlighting missing or incorrect items Weakness u Domain expertise is needed Copyright © 2003 -2005 Yoram Reich 48

Nothing happens. The button is already lit, so pushing it does not change anything Dynamic Modeling n n n Produce UML state diagram State, event, predicate distributed over state diagram UML “guards” are in brackets Syntax of links: [action, present state] e. g. , [button pushed, button unlit] The elevator moves in the direction of the floor. A check is done and based on it, the controller responses. If a stop was requested, stop at floor and subsequently continue. Copyright © 2003 -2005 Yoram Reich 49

Testing during the OOA Phase n CRC cards are an excellent testing technique Collected

CRC Cards n Consider responsibility 1. Turn on elevator button n Totally unacceptable for object-oriented paradigm u u n Responsibility-driven design ignored Information hiding ignored (how would I know how to turn it on? ) Responsibility 1. Turn on elevator button should be 1. Send message to Elevator Button to turn itself on Copyright © 2003 -2005 Yoram Reich 51

CRC Cards (cont) n A class has been overlooked u u n n Once the class elevator doors is added, it will have to get its own state diagram (each class has one for itself). We now have one state change from this: transition from closed doors to open doors Elevator doors have a state that changes during execution (class characteristic) Add class Elevator Doors Reconsider class model Then reconsider dynamic model, use-case model Copyright © 2003 -2005 Yoram Reich 52

Second Iteration of CRC Card Bold letters specify the classes now also in the

Third Iteration of Class Diagram nm Copyright © 2003 -2005 Yoram Reich 54

Second Iteration of Normal Scenario Previous version. Notice the differences with the new version

Elevator Problem: Sequence diagram n Diagram of 1 st scenario Copyright © 2003 -2005

Elevator Problem: Collaboration diagram n n The messages that are passed between objects must be addressed later in the design. Each such message should get an action in the receiving class to allow it to respond to this message. Copyright © 2003 -2005 Yoram Reich 57

Elevator Problem: Construct Detailed Class Diagram n n To which class do we assign an action? Criteria u u n Information hiding Responsibility-driven design Examples “close doors” is assigned to Elevator Doors “move one floor down” is assigned to Elevator Copyright © 2003 -2005 Yoram Reich 58

Elevator Problem: Detailed class diagram These actions address the messages passed to the button to lit or unlit itself. Here they are abstract actions. Actions inherited and given concrete meaning to address messages 10 and 13 in the collaboration and sequence diagrams nm Compare these action with the actions mentioned in the dynamic modeling (state diagram) Copyright © 2003 -2005 Yoram Reich 59

Elevator Problem: OOA (cont) n All three models (class, sequence, and collaboration) are now fine n We should rather say: u n All three models are fine for now We may need to return to the object-oriented analysis phase during subsequent design and implementation stages Copyright © 2003 -2005 Yoram Reich 60

Elevator Problem n n A 2 nd example of more complicated design The solution

Elevator example: Use case diagram Copyright © 2003 -2005 Yoram Reich 62

Elevator example: Use case diagram n Process Car Calls: This use case includes several scenarios, which will be described in detail in later sections of this paper. These scenarios includes that the elevator receives car calls from the passengers, turns on or turns off the light of car call buttons, updates the record of car calls stored in system controlling parts, etc. n Process Hall Calls: Similar to Car Call processing, this use case includes that the elevator receives hall calls from the passengers, turns on or turns off the light of hall call buttons, updates the record of hall calls in system controlling parts, etc. n Move/Stop the Car: The main function of an elevator, detailed action will include the changing of driving speed, how to make the decision of stop, and driving directions of the car. n Indicating Moving Direction: The elevator should have this mechanism to let the passengers know the current moving direction of the car such that the passenger might decide whether to enter the car or not. n Indicating Car Position: Similarly, the elevator should let the passengers know whether his/her destination floor is reached so that the passenger may decide to leave the car. n Open/Close the Doors: The elevator should be able to open and close the doors for the passengers to get in and out of the car. The functional areas of this use case should also enable the passengers to make door reversals when the doors are closing and the passenger wants to get in the car. n Trigger Emergency Brake: There is safety mechanism within the car to make sure that an unsafe state is not transiently generated. Copyright © 2003 -2005 Yoram Reich 63

Elevator example: Class diagram Was not present before Copyright © 2003 -2005 Yoram Reich

Elevator example: Class diagram n Problems: u u n Overburdening central object: Elevetor. Control Most other objects are idle most of the time Competition over computing resources for controlling multiple objects (several elevators) Low overall system efficiency Addition of control objects – distributed control Copyright © 2003 -2005 Yoram Reich 65

End! Copyright © 2003 -2005 Yoram Reich 73

Stereotypes (continued) u Example: A separate use case to model the situation of the

Sequence Diagrams n n Example: u Dynamic creation followed by destruction of an object lifelines in the sequence diagram u An active object is denoted by a thin rectangle (activation box) in place of the dashed line = = Creation of the : Masterpiece Class object is denoted by the lifeline starting at the point of dynamic creation Destruction of that object after it receives message denoted by heavy X n 9: Destroy object Copyright © 2003 -2005 Yoram Reich 83

Sequence Diagrams n n A message is optionally followed by a message sent back to the object that sent the original message Even if there is a reply, it is not necessary that a specific new message be sent back u = Instead, a dashed line ending in an open arrow indicates a return from the original message, as opposed to a new message There is a guard on the message n 9: [offer rejected] Destroy object 4 Only if Osbert’s offer is rejected is message 9 sent = A guard (condition) is something that is true or false 4 The message sent only if the guard is true = The purpose of a guard 4 To ensure that the message is sent only if the relevant condition is true Copyright © 2003 -2005 Yoram Reich 84

Collaboration Diagrams Copyright © 2003 -2005 Yoram Reich 85

Statecharts n Statechart with guards Copyright © 2003 -2005 Yoram Reich 86

Statecharts n n = An event also causes transitions between states Example: The receipt of a message The elevator is in state Elevator Moving 4 It performs operation n Move up one floor while guard [no message received yet] is true, until it receives message n = = Elevator has arrived at floor Receipt of this message [event] causes the guard to be false It also enables a transition to state Stopped at Floor 4 In this state, activity n Open the elevator doors is performed Copyright © 2003 -2005 Yoram Reich 87

Statecharts (contd) n Example: Four states are unified into Osbert Combined Copyright © 2003

Statecharts The most general form of a transition label is n F u If F event [guard] / action event has taken place and F [guard] is true, the transition occurs, and, while it is occurring, F action is performed = The transition label is 4 Elevator arrived at floor [a message is received] / Open the elevator doors = The guard 4 [a message has been received] is true when the event 4 Elevator has arrived at floor = has occurred and the message has been sent The action to be taken is 4 Open the elevator doors Copyright © 2003 -2005 Yoram Reich 89

Elevator n n n Our elevator has the basic function that all elevator systems have, such as moving up and down, open and close doors, and of course, pick up passengers. The elevator is supposed to be used in a building having floors numbered from 1 to Max. Floor, where the first floor is the lobby. There are car call buttons in the car corresponding to each floor. For every floor except for the top floor and the lobby, there are two hall call buttons for the passengers to call for going up and down. There is only one down hall call button at the top floor and one up hall call button in the lobby. When the car stops at a floor, the doors are opened and the car lantern indicating the current direction the car is going is illuminated so that the passengers can get to know the current moving direction of the car. The car moves fast between floors, but it should be able to slow down early enough to stop at a desired floor. In order to assure system safety, emergency brake will be triggered and the car will be forced to stop under any unsafe conditions. Copyright © 2003 -2005 Yoram Reich 90

Outline n Elevator problem – Case Study u Object Oriented Analysis F Use-case modeling F Class modeling F Dynamic modeling u Object Oriented Design F Interaction diagrams F Detailed Class diagrams Copyright © 2003 -2005 Yoram Reich 91