1 / 101

SE 430 Object Oriented Modeling

SE 430 Object Oriented Modeling. Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30. Administrivia. Comments and feedback Exam Partial credit given by system; I will finish grading it.

gregoryklein
Download Presentation

SE 430 Object Oriented Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 6

  2. Administrivia • Comments and feedback • Exam • Partial credit given by system; I will finish grading it. • Preliminary project description due October 20, 2016 SE 430: Lecture 6

  3. Discussion: Assignment 3 • Domain model. Produce a domain model diagram for the Visitor Information Subsystem. • Deliverables • Conceptual (Domain) model diagram with associations & attributes • System glossary • Domain model • Weak, missing major classes • Classes associated with wrong classes • Glossary still weak. • Include all items shown in domain model. • Include all items from previous glossaries. SE 430: Lecture 6

  4. Assignment 4 Mixed Information Display – Due October 20, 2016 Objects and Operations and Viewer Statechart • Create a CRC card for each object in the Mixed Information Display design • Create an operation contract for each operation shown in the sequence diagram • Create a statechart for the behavior of the Viewer object • Deliverables • Cover page. • Mixed Information Display Objects and Operations. • Viewer Statechart. SE 430: Lecture 6

  5. SE 430 – Class 6 Topics:Objects • The Nature of an Object; Relationships Among Objects • Design by Contract: • Operation Contracts: Assigning Responsibilities, System [Operation] Contracts and Dependencies • System Behavior Modeling: Object behavior: Object Interaction Diagrams • Communication (Collaboration) Diagrams and Message Sequence Diagrams • Object Statecharts • State Diagrams, State Space and Behavior Reading: Arlow & Neustadt, Ch.'s 12-13, 21 See also reading list SE 430: Lecture 6

  6. Thought for the Day "My guideline for process is just slightly less than enough." SE 430: Lecture 6

  7. Last Class Transition to Design • Software Architecture • Overview of Software Architecture • Architectural Planning • Tools and Techniques for Transition to Design • Design Scenarios • The Human Computer Interface: Tiered Architecture • Robustness Analysis • Function-Class Decomposition SE 430: Lecture 6

  8. Analysis Phase • Analysis Phase • emphasis on discovering and understanding the problem domain SE 430: Lecture 6

  9. Analyzing Requirements SE 430: Lecture 6

  10. Where do objects fit into O-O modeling? • Objects are with us throughout the modeling process. • Objects provide us with our most concrete handle on the modeling process. • The early phases of modeling – inception and early elaboration – deal mostly with discovered objects: • Domain objects and actors. • Domain entities uncovered in use cases. • Later phases of modeling – later elaboration – also deal with: • Inventedobjects. • Mechanisms of object interaction. SE 430: Lecture 6

  11. The Nature of an Object SE 430: Lecture 6

  12. What comprises an object? TimeOfDay State Minimum set of attributes that specifies the condition of the object. int hour int minute int second private boolean isUpdated int getHour() int getMinute() int getSecond() void update() // cur. time void setHour(int hour) void setMinute(int minute) void setSecond(int second) void print() Behavior External actions (self-initiated) and reactions (externally- initiated) of the object. «instanceOf» Identity Distinguishes object from all others. time:TimeOfDay IP address Process ID Unique ID Memory address. SE 430: Lecture 6

  13. Object state • The allowable state space for an object is determined by the rangeof allowable values for the attributes defined by the class of the object. • Example: The allowable values of hours, minutes, and seconds for an instance of TimeOfDay: 00:00:00 to 23:59:59. • The state of an object at a given time is determined by the current values of each of these attributes. • Example: The state of an instance of TimeOfDay at 13:28:37. • Event- and time-dependent behavior arises from changes in the attribute values and hence the state of an object. • Example: A simple program that prints the current values of hours, minutes, and seconds and invokes update on an instance of TimeOfDay. SE 430: Lecture 6

  14. Behavior – general • Behavior is how an object acts and reacts externally to state changes. • State changes can occur because of internal or external events. • A state change can occur when the object itself changes its internal state. • Example: An instance of TimeOfDay running in its own thread of execution invokes the update method on itself. • A state change can occur when an object receives a message invoking an operation on the object. • Example: A program invokes the update method on an instance of TimeOfDay as in the example on the previous slide. • An object may change its state but not exhibit different behavior. • Example: An instance of TimeOfDaychanges the value of the isUpdated private instance variable as part of update() operation. SE 430: Lecture 6

  15. Behavior – types of operations • Constructor: Creates an object and optionally initializes its state. [C++/Java new operation] • Modifierormutator: Alters the state of an object. • Selector or accessor: Accesses the state of an object without altering it. • Iterator: Permits all parts of an object to be accessed in some well-defined order. • Destructor: Frees the state of an object and/or destroys the object itself. [C++ delete operation] SE 430: Lecture 6

  16. Behavior – types of operations Two species of operations: • Instance.Most common. Behavior varies from instance to instance in response to operation, based on the state of the instance. Example: Java Integer toString() method. Integer foo = new Integer(42); System.out.println(foo.toString()); • Class. Define invariant behavior for any instance. Behaves as a stand-alone procedure, e.g. static methods in Java. Example: Java Integer toString(int i) method. System.out.println(Integer.toString(42)); SE 430: Lecture 6

  17. Object responsibilities • Responsibilities are the services an object provides in its contracts with clients and collaborators. Broader scope than an operation or method. • Operation contracts specify the pre- and postconditions for individual object operations (methods). • You already have experience specifying preconditions and postconditions for entire use cases. • Recall: • Preconditions define the conditions that must be true before a use case begins. • Postconditions define the conditions that must be true after the use case ends. • Contracts are a means of realizing design by contract. SE 430: Lecture 6

  18. Contracts and Dependencies SE 430: Lecture 6

  19. A possible point of confusion • Contracts come in several forms: use case contracts, system contracts and operation contracts; they are essentially the same except for the item they apply to. • We will be discussing operation contracts and statecharts in the context of objects • Reason 1: You will rarely encounter operation contracts and statecharts in domain analysis, though they are both potentially very useful there • Reason 2: Operation contracts and statecharts are definitely very useful in design • Discussion is equally valid in either context SE 430: Lecture 6

  20. System [Operation] Contract System [Operation] contract • Describes what the system [operation] must accomplish because of the operation • Obvious – show sub-totals • Hidden – update inventory • Do not describe the sequential steps necessary to achieve those changes • Precondition – what the system must know or what must be true before an operation can succeed • Post-condition– what the system will make true after successfully running an operation. SE 430: Lecture 6

  21. System [Operation] Contract • Make a contract for each system operation • Identify • Preconditions • Post-conditions • If a contract uncovers a hole in the conceptual model, then modify the model (add whatever is missing) • Emphasis is on stating what has occurred, it is still not important to define how it should happen (defer solutions) SE 430: Lecture 6

  22. Design by contract • Establishing a collaboration between objects in a system is similar to contracting for a service. • The two parties are referred to as the supplier and the client. • Both parties are entitled to benefits. • Both parties are subject to obligations. • A precondition is an obligation for the client and a benefit for the supplier. • A postcondition is a benefit for the client and an obligation for the supplier. SE 430: Lecture 6

  23. Preconditions • Preconditions specify what is assumed upon entering the operation. • Another view: Preconditions specify the conditions under which invoking the operation is correct or permissible. • It is the responsibility of the client to ensure that all preconditions are satisfied before the operation is invoked. • The supplier assumes that the preconditions have been met before the operation is invoked. • Example: An instance of TourGenerator (the client) uses an operation on an instance of MemberPreferences (the supplier) in the VIS: ArrayList getMemberPreferences(int memberID) Precondition: The operation requires an integer argument representing a valid Museum member ID number. SE 430: Lecture 6

  24. Postconditions • Postconditions: specify what should be true when the operation completes, provided the precondition was satisfied. • Alternatively: Postconditions specify the conditions under which the operation may be considered correct or complete. • It is the responsibility of the supplier to ensure that all postconditions will be met when the operation completes. • The client assumes that the postconditions will be met when the operation completes. • Example: TourGenerator expects to receive an instance of ArrayList populated with the preferences of the member represented by memberID. ArrayList getMemberPreferences(int memberID) SE 430: Lecture 6

  25. Contract format • Sections of a contract (from Larman, p. 183): • Operation name with parameters • Class containing operation. • Cross reference to use cases in which this operation occurs (for system operations) or design scenarios (for object operations). Acts as audit trail for operation • Preconditions • Postconditions • Example: • Operation name: getMemberPreferences(memberID) • Class:MemberPreferences • Cross reference: Generate custom tour for Museum member • Preconditions: Client must supply valid integer member ID number • Postconditions: Supplier will supply a list of preferences corresponding to the member ID number supplied by the client • Form for contract is available in the reading list. http://condor.depaul.edu/dmumaugh/readings/handouts/SE430/forms/contract.doc SE 430: Lecture 6

  26. Active and passive objects • A key element of modern O-O design is to have objects that are able to act on their own: active objects. • Active object: • Encompasses its own thread of control; that is,able to act without being acted upon. • Capable of changing its own state. • Passive object: • Does not encompass its own thread of control. • Must be explicitly acted upon to change its state. SE 430: Lecture 6

  27. Active object Imagine there is a Java ‘Circle’ object ready to run in its own thread: SE 430: Lecture 6

  28. Passive object And now a Java ‘Circle’ object not running in its own thread: SE 430: Lecture 6

  29. Identity • Identity is the property of an object distinguishing it from all others • Identity is generally not associated with an attribute of the object: it is a ‘meta-attribute’ of the object. • The name or label of object and its identity are not necessarily the same. • The name can be transferred or duplicated, identity cannot. • Example: The label of the Museum Head Librarian may be transferred from employee to employee. • In a complex, distributed environment, a vector of properties is needed to define the identity an object. (see slide 12 or note) SE 430: Lecture 6

  30. Relationships Among Objects SE 430: Lecture 6

  31. Unidirectional message passing: synchronous message pair Return value g e t A l l o w e d A c t i o n s ( u s e r ) a l l o w e d A c t i o n L i s t r o o m 1 2 1 4 A C P : : S e c u r i t y A c c e s s A c c e s s D i s p a t c h e r C o n t r o l P o i n t g e t A l l o w e d A c t i o n s ( u s e r , h a n d l e ) handle.receive(user,allowedActionList ) Note object labeling convention: instance:Class Bi-directional message passing: asynchronous message pair using a callback Links – general • Represents a physical or conceptual connection between objects. • Links enable message passing between objects. • Message passing can be unidirectional or bi-directional. • Data flow may be bi-directional via parameters, return values, or callbacks. SE 430: Lecture 6

  32. Links – visibility • In order to send message, receiver must be visible to sender • Ways a message receiver object may be visible to message sender: • Receiver has global scope relative to the sender object • Receiver is a parameter to operation of the sender object • Receiver is a locally-declared object in an operation of the sender • Receiver is an attribute of the sender object • If needed, use stereotypes to identify visibility on link: «global», «parameter», «local», and «association» (or, equivalently, «attribute»). SE 430: Lecture 6

  33. System Behavior Modeling SE 430: Lecture 6

  34. Dynamic Modeling The dynamic model represents control information: the sequences of events, states and operations that occur within a system of objects, usually involving the time dimension. SE 430: Lecture 6

  35. Object Interaction Diagrams SE 430: Lecture 6

  36. Interaction Diagrams Design • Decide how the objects will work together to fill the contract (dynamic behavior) • CRC cards and Robustness Diagrams • start the design process with approximate and informal solutions. • Use Interaction Diagrams for more detailed solutions. (Sometimes examination of details forces a revisit to previous decisions.) • Allocate behavior among objects. • Show the required detailed interactions among objects over time. • Distribute operations among classes. (This may include adding objects or attributes to existing objects.) SE 430: Lecture 6

  37. Interaction Diagrams • Interaction Diagrams describe how objects work together to fulfill the contract. • For each use case, an interaction diagram should be drawn to describe the behavior of your system at run time and how the system will accomplish that behavior. • the typical course • all alternate courses Two types of interaction diagrams, • (Message) Sequence Diagrams • emphasizes the time order of events by a clear sequencing of messages • Sometimes called Object Sequence Diagrams • Communication diagrams • emphasizes the organization of objects by showing their linkages • Previous to UML 2.0 these were called collaboration diagrams Each provides the same information, different format SE 430: Lecture 6

  38. Message Sequence Diagrams SE 430: Lecture 6

  39. Sequence Diagrams Librarian Book Borrower check book out allowed to check out check out update book list collaborations external event (Message) Sequence Diagrams – Useful for displaying time sequences, object activation and concurrent processes SE 430: Lecture 6

  40. Sequence Diagrams To model a flow of control by time ordering, • Select a use case • Place icons at the top of the diagram for objects that exist prior to the start of the use case (most important objects on the left, least on the right) • Set each object’s lifeline (a dashed vertical line beneath each object icon) Each object has a lifeline for the length of its existence. • For objects that exist throughout the use case, the lifeline is the length of the diagram • For objects being created, show <<create>> message to icon. Lifeline follows point of creation • For objects being destroyed, show <<destroy>> message to X which terminates lifeline. • Starting with the first message that causes the interaction, connect the lifelines of the initiator of a message with the lifeline of the object that receives the message. SE 430: Lecture 6

  41. Sequence Diagrams Time sequence – Messages closer to the top occur earlier than messages closer to the bottom Objects Created during the operation have an object icon appear at the time they are created, usually with a “create” message Objects Deleted during the operation have an X terminating their lifeline. (an object can delete itself or be deleted by a message) Textual descriptions of the use case can be included on the left side of the page parallel with the diagram messages. SE 430: Lecture 6

  42. Sequence Diagrams Messages are indicated by a solid line with an arrow. • Two kinds of arrows – synchronous and asynchronous. We will only show synchronous. SE 430: Lecture 6

  43. Sequence Diagrams A message • Has a message name (operation name) endSale() • Can have parameters used: setValue(3.4) • Can have a return variable: area := getArea(length,width) Messages can also have control information • iteration marker, iteration clause * : [for each item] *[x := 1..10] Message will be sent 10 times • condition of execution [check = true] Message if true [check = false]Message if false *[x >= 10] Message sent until x becomes less than 10. • This is UML 1.x but still used in 2.0 and communication diagrams. SE 430: Lecture 6

  44. Sequence Diagrams • Return messages are optional – use if they clarify, avoid if they add noise. • Some put named return values on return message • Indicate active objects by showing Focus of Control • Change an object’s lifeline to a thin rectangle when it is performing a computation, SE 430: Lecture 6

  45. Sequence Diagrams SE 430: Lecture 6

  46. Communication Diagrams SE 430: Lecture 6

  47. Communication Diagrams • Sequence diagrams can be used to show the time-dependent behavior of objects that don’t need a big state diagram • For some objects that have many interactions with objects of other classes, the communication diagram notation can be useful [also known as collaboration diagram]. • the communication diagram shows the same information as a sequence diagram, but in a different graphical form • communication diagrams need to show objects rather than classes • some example objects (in UML notation): object name is optional : Meter value = 150 truckCounter : Car counter car_count = 0 enteringCar : Car car_id = NJ 2345 weight = 2700 SE 430: Lecture 6

  48. Communication Diagram Example car_entering() inSensor : Car sensor 1: add_car() garageCounter : Car counter 1.1: update() garageMeter : Meter 1.2: close() garageGate : Gate • Each box represents an object • Each line connecting two objects represents a “message” or a function call [See note for equivalent sequence diagram] SE 430: Lecture 6

  49. Communication Diagram Example car_entering() inSensor : Car sensor 1: add_car() garageCounter : Car counter 1.1: update() garageMeter : Meter 1.2: close() garageGate : Gate • The numbers on each message indicate the sequence of messages • the “length” of the numbers on the messages indicate the “depth” of the collaboration • in this example, the update and close operations are performed on the Meter and Gate during the execution of add_car • [See note for equivalent sequence diagram] SE 430: Lecture 6

  50. Another Communication Diagram Example Student register_student() 2: is_full() aCourse : Course 1: validate_student() 3: add_student() theStudentDir : Student_directory courseWaitList : WaitingList Example: registering a student in a course that is full SE 430: Lecture 6

More Related