SE 430 Object Oriented Modeling Dennis Mumaugh Instructor

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

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

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. October 13, 2016 SE 430: Lecture 6 3 of 101

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. October 13, 2016 SE 430: Lecture 6 4 of 101

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 October 13, 2016 SE 430: Lecture 6 5 of 101

Thought for the Day "My guideline for process is just slightly less than enough. " October 13, 2016 SE 430: Lecture 6 6 of 101

Last Class Transition to Design § Software Architecture Ø Ø Overview of Software Architectural Planning § Tools and Techniques for Transition to Design Ø Ø Design Scenarios The Human Computer Interface: Tiered Architecture Robustness Analysis Function-Class Decomposition October 13, 2016 SE 430: Lecture 6 7 of 101

Analysis Phase § Analysis Phase Ø emphasis on discovering and understanding the problem domain Aspect of problem domain Document by Processes Use Cases Objects, vocabulary, terms, concepts Conceptual Model System events, operations System sequence diagrams System and operations accomplishments Contracts October 13, 2016 SE 430: Lecture 6 8 of 101

Analyzing Requirements Focus of Analysis Diagrams Processes Data Flow, State chart Data Entity Relationship Objects Structural Class, Object, Component, Deployment Behavioral Use Case, System Sequence, Interaction and communication, State chart, Activity October 13, 2016 SE 430: Lecture 6 9 of 101

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: Ø Ø Invented objects. Mechanisms of object interaction. October 13, 2016 SE 430: Lecture 6 10 of 101

The Nature of an Object October 13, 2016 SE 430: Lecture 6 11 of 101

What comprises an object? Minimum set of attributes that specifies the condition of the object. External actions (selfinitiated) and reactions (externally- initiated) of the object. Time. Of. Day State int hour int minute int second private boolean is. Updated int get. Hour() int get. Minute() int get. Second() void update() // cur. time void set. Hour(int hour) void set. Minute(int minute) void set. Second(int second) void print() Behavior «instance. Of» Distinguishes object from all others. Identity time: Time. Of. Day IP address Process ID Unique ID Memory address. October 13, 2016 SE 430: Lecture 6 12 of 101

Object state § The allowable state space for an object is determined by the range of 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 Time. Of. Day: 00: 00 to 23: 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 Time. Of. Day at 20: 44: 53. § 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 Time. Of. Day. October 13, 2016 SE 430: Lecture 6 13 of 101

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 Time. Of. Day 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 Time. Of. Day as in the example on the previous slide. § An object may change its state but not exhibit different behavior. Ø Example: An instance of Time. Of. Day changes the value of the is. Updated private instance variable as part of update() operation. October 13, 2016 SE 430: Lecture 6 14 of 101

Behavior – types of operations § Constructor: Creates an object and optionally initializes its state. [C++/Java new operation] § Modifier or mutator: 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] October 13, 2016 SE 430: Lecture 6 15 of 101

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 to. String() method. Integer foo = new Integer(42); System. out. println(foo. to. String()); § Class. Define invariant behavior for any instance. Behaves as a standalone procedure, e. g. static methods in Java. Example: Java Integer to. String(int i) method. System. out. println(Integer. to. String(42)); October 13, 2016 SE 430: Lecture 6 16 of 101

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. October 13, 2016 SE 430: Lecture 6 17 of 101

Contracts and Dependencies October 13, 2016 SE 430: Lecture 6 18 of 101

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 October 13, 2016 SE 430: Lecture 6 19 of 101

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. October 13, 2016 SE 430: Lecture 6 20 of 101

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) October 13, 2016 SE 430: Lecture 6 21 of 101

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. October 13, 2016 SE 430: Lecture 6 22 of 101

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 Tour. Generator (the client) uses an operation on an instance of Member. Preferences (the supplier) in the VIS: Array. List get. Member. Preferences(int member. ID) Precondition: The operation requires an integer argument representing a valid Museum member ID number. October 13, 2016 SE 430: Lecture 6 23 of 101

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: Tour. Generator expects to receive an instance of Array. List populated with the preferences of the member represented by member. ID. Array. List get. Member. Preferences(int member. ID) October 13, 2016 SE 430: Lecture 6 24 of 101

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: get. Member. Preferences(member. ID) Ø Class: Member. Preferences Ø 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/SE 430/forms/contract. doc October 13, 2016 SE 430: Lecture 6 25 of 101

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. October 13, 2016 SE 430: Lecture 6 26 of 101

Active object Imagine there is a Java ‘Circle’ object ready to run in its own thread: October 13, 2016 SE 430: Lecture 6 27 of 101

Passive object And now a Java ‘Circle’ object not running in its own thread: October 13, 2016 SE 430: Lecture 6 28 of 101

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) October 13, 2016 SE 430: Lecture 6 29 of 101

Relationships Among Objects October 13, 2016 SE 430: Lecture 6 30 of 101

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. Unidirectional message passing: synchronous message pair Return value get. Allowed. Actions( user ) room 1214 ACP: Access Control. Point Note object labeling convention: instance: Class October 13, 2016 allowed. Action. List get. Allowed. Actions( user, handle ) : Security. Access Dispatcher handle. receive(user, allowed. Action. List ) Bi-directional message passing: asynchronous message pair using a callback SE 430: Lecture 6 31 of 101

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» ). Ø October 13, 2016 SE 430: Lecture 6 32 of 101

System Behavior Modeling October 13, 2016 SE 430: Lecture 6 33 of 101

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. October 13, 2016 SE 430: Lecture 6 34 of 101

Object Interaction Diagrams October 13, 2016 SE 430: Lecture 6 35 of 101

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. ) October 13, 2016 SE 430: Lecture 6 36 of 101

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 October 13, 2016 SE 430: Lecture 6 37 of 101

Message Sequence Diagrams October 13, 2016 SE 430: Lecture 6 38 of 101

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

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. October 13, 2016 SE 430: Lecture 6 40 of 101

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 can be included on the left side of the page parallel with the diagram messages. October 13, 2016 SE 430: Lecture 6 41 of 101

Sequence Diagrams Messages are indicated by a solid line with an arrow. § Two kinds of arrows – synchronous and asynchronous. We will only show synchronous. Arrow Meaning Synchronous Transfer control and wait for answer. (sequential operations) Return Arrow head style Returns a value to the caller [Note arrow head might be closed or line solid. There is a lot of divergence here]. October 13, 2016 SE 430: Lecture 6 42 of 101

Sequence Diagrams A message § Has a message name (operation name) end. Sale() § Can have parameters used: set. Value(3. 4) § Can have a return variable: area : = get. Area(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. October 13, 2016 SE 430: Lecture 6 43 of 101

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, October 13, 2016 SE 430: Lecture 6 44 of 101

Sequence Diagrams October 13, 2016 SE 430: Lecture 6 45 of 101

Communication Diagrams October 13, 2016 SE 430: Lecture 6 46 of 101

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): truck. Counter : Car counter entering. Car : Meter car_count = 0 car_id = NJ 2345 weight = 2700 object name is optional value = 150 October 13, 2016 SE 430: Lecture 6 47 of 101

Communication Diagram Example § Each box represents an object § Each line connecting two objects represents a “message” or a function call [See note for equivalent sequence diagram] car_entering() in. Sensor : Car sensor 1: add_car() garage. Counter : Car counter 1. 1: update() 1. 2: close() October 13, 2016 SE 430: Lecture 6 garage. Meter : Meter garage. Gate : Gate 48 of 101

Communication Diagram Example § The numbers on each message indicate the sequence of messages car_entering() 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] Ø in. Sensor : Car sensor 1: add_car() garage. Counter : Car counter 1. 1: update() 1. 2: close() October 13, 2016 SE 430: Lecture 6 garage. Meter : Meter garage. Gate : Gate 49 of 101

Another Communication Diagram Example: registering a student in a course that is full Student register_student() 2: is_full() a. Course : Course 1: validate_student() 3: add_student() the. Student. Dir : Student_directory October 13, 2016 course. Wait. List : Waiting. List SE 430: Lecture 6 50 of 101

Another Example: unregistering a student who is registered in the course Student unregister_student() 3: add_student(student_id) a. Course : Course 1: student_id : = get_first_student() 2: remove_student(student_id) course. Wait. List : Waiting. List October 13, 2016 SE 430: Lecture 6 51 of 101

Our example: Mixed information display § Recall our architectural patterns example from Class 5 § Essential system requirements: The system must be able to display multiple types of media within a single display page Ø The system must be able to retrieve media content from different sources § Let’s consider a simpler, alternative design approach that does not use the MVC and Broker architectural patterns Ø This approach is typical for a restricted, desktop application Ø It simplifies interactions in order to expose the techniques and notation Ø Techniques and notation are equally suitable for a more complex architecture Ø October 13, 2016 SE 430: Lecture 6 52 of 101

Simple Schematic for Problem October 13, 2016 SE 430: Lecture 6 53 of 101

Communication Diagram Notes • Communication diagrams were called collaboration diagrams in pre. UML 2. 0 • Callback handles left out to reduce clutter Synchronous message 1. 3: *[for each item]: display(item) 1: display(. . . ) : Viewer : Document Multiple objects 1. 1: *[for each item]: retrieve(item) Self link 1. 1. 4: receive(item) 1. 2. 1: destroy(self) 1. 1. 1: whereis(item) : Directory 1. 2: done() location Iteration & condition : Retrieval. Agent 1. 1. 2: request(item) 1. 1. 3: receive(item) : Server Asynchronous messages October 13, 2016 SE 430: Lecture 6 54 of 101

Basic Sequence Diagram Note: This sequence diagram shows the complete interaction for our example October 13, 2016 SE 430: Lecture 6 55 of 101

Sequence diagram with alt frame (partial) Anonymous participant : Viewer primary: Server : Directory backup: Server display(item, . . . ): void new loop Specific participant : Retrieval Agent [for each content item] retrieve(item) whereis(item) Note: This sequence diagram shows only part of the interaction for our example location list check server response Time response ch eck server response alt [primary < secon dary] request(item) rece (item) ive [else] receive(item) st(item) reque receive(item) October 13, 2016 Alternate interactio n frame SE 430: Lecture 6 56 of 101

Sequence diagram notation § Participant. An entity that takes part in the interaction Anonymous. No need to distinguish this type of participant [uses the anonymous object notation. ] Ø Specific. Participant must be distinguished from other, similarlytyped participants [use named object notation. ] Lifeline. Indicates the life span of the participant in the interaction Activation (optional). Shows when a participant is active in the interaction. Creation. Indicates when a participant is created as part of the interaction. Otherwise participants are assumed to have been created before the interaction commences. Deletion. Indicates when a participant is destroyed. May be done by another participant or by the participant itself. Ø § § October 13, 2016 SE 430: Lecture 6 57 of 101

Sequence diagram notation Messages § Found message. Message that initiates interaction § Synchronous. Indicates the sender blocks until the receiver returns response. Most synchronous messages have return values; however, void synchronous messages do not. [use a solid head arrow for message] § Asynchronous. Indicates the sender does not block until the receiver responds. Asynchronous messages that expect a return value have a corresponding asynchronous callback message [use an open arrow for message] § Return. Indicates a regular return value in a synchronous message or a call back for an asynchronous. [Synchronous messages may indicate the return as part of the originating message. ] § Self call. Indicates the participant is sending a message to itself October 13, 2016 SE 430: Lecture 6 58 of 101

Sequence diagram notation Interaction frames. Region of a diagram having a special operator and guard (condition) § loop. The fragment of the interaction executes multiple times § alt. Alternative, multiple fragments. The one which possesses the true condition will execute § Other operators: opt (optional), par (parallel), region (may only be executed by one thread at a time), neg (shows an invalid interaction), ref (off-page reference), sd (sequence diagram; encloses whole diagram) October 13, 2016 SE 430: Lecture 6 59 of 101

Communication vs. sequence diagrams Feature Communication Diagram Sequence clarity Low High Object lifetimes (incl. create/destroy) No Yes Readability Medium High Iteration Representation Yes (fair) (may not be in UML 2. 0) Yes (good) Self-activation Yes Sync/async Yes October 13, 2016 SE 430: Lecture 6 60 of 101

Interaction Diagrams October 13, 2016 SE 430: Lecture 6 61 of 101

Interaction Diagrams Guidelines for Creating an Interaction Diagram § Create a separate diagram for each system operation. Ø Ø A system operation is the response to a system event. The system operation is the starting message. § In most cases the diagram is for a use case. The difference is that System Sequence Diagrams treat the system as a black box and here we look at all of the components of the system affected by the use case. October 13, 2016 SE 430: Lecture 6 62 of 101

Interaction Diagrams § Develop a system of interacting objects that fulfill the system obligations based on your knowledge of Ø Ø Ø Use Case Descriptions Conceptual Model Contracts Post-conditions Patterns § If the diagram gets too complex, split it into smaller diagrams. § This will form the basis of your class diagram October 13, 2016 SE 430: Lecture 6 63 of 101

Interaction Diagrams Steps from Use Cases to Interaction Diagrams § Use cases identify system events that are then recorded on system sequence diagrams § Use case contracts are the first description of the effect of system events. § The system events represent messages that initiate interaction diagrams § Interaction diagrams contain Ø conceptual model objects (some discovered during design) Ø design objects (added during design) Interaction diagrams do NOT need to show § how information is displayed Interaction diagrams should show § the information to be displayed § Information that has been processed or created by domain objects and § Information that is available from domain objects October 13, 2016 SE 430: Lecture 6 64 of 101

Object Statecharts State-Space and Behavior October 13, 2016 SE 430: Lecture 6 65 of 101

Overview § Objects can have internal state changes, which can be modeled using state machine notations Ø UML State diagrams § State models are used to describe the “time-dependent behavior” of objects § Other notations can be used for time-dependent behavior: interaction diagrams Ø sequence diagrams Ø communication diagrams October 13, 2016 SE 430: Lecture 6 66 of 101

The reason for state models § The analysis-level model needs to express both static and dynamic views of a system § From James Rumbaugh, et. al. , Object-oriented modeling and design: Ø Class diagrams represent the static, structural, “data” aspects of a system Ø State models represent the temporal, behavioral, “control” aspects of a system § We will show some of the UML notations for representing the dynamic view of a system Ø The use case notation only shows the interactions between actors and the system at a high-level Ø The state model can be used to describe the interactions between objects that are defined by the class diagram October 13, 2016 SE 430: Lecture 6 67 of 101

Modeling entities as deterministic machines § Harel statecharts provide a highly-flexible notation for representing the § § § event-driven behavior of an entity Statecharts can be used to model use cases, components, or entire systems. We’ll look at them in the context of modeling objects Important! A statechart only models the states of the entity. It does not include any representations or behavior of external entities Statechart considers an object as the embodiment of a finite state machine Equally useful for both active and passive objects An important view of objects in the formal testing and real-time communities Ø Example: ROOM (Real-time Object-Oriented Modeling) Also, increasingly important in the context of model-driven architecture (MDA), in which detailed, formal specification of system behavior is essential October 13, 2016 SE 430: Lecture 6 68 of 101

Events, States and Activities § State Diagrams chart the life-span of an object from creation to § § destruction and the discrete (finite) states in-between Event Ø something that happens at a point in time. An event has no duration. For example, received messages, time-outs, error exceptions. State Ø an abstraction of the attribute values and links of an object Activity Ø an operation that takes time to perform Ø closely associated with a state Action Ø an operation performed on a state change October 13, 2016 SE 430: Lecture 6 69 of 101

State Diagram - Notation name of event which causes transition State 1 do/activity 1 a pre-condition before a transition occurs event [condition] /action State 2. . . Finish State Starting point October 13, 2016 an action that is performed when the event occurs SE 430: Lecture 6 70 of 101

Example State Diagram Invoice created Unpaid October 13, 2016 Paying SE 430: Lecture 6 Invoice destroyed Paid 71 of 101

Parts of a State Diagram § State: an abstraction of the 2 -speed ceiling fan Off Chain_pulled / motor off attribute values of an object § Action: an activity or an operation that is done inside of a state or on a transition § Event: a condition that can be detected by the object; events can cause a transition to another state and/or they can cause one or more actions to be triggered § Transitions: a connection between two states that is labeled by the event that triggers the transition Chain_pulled / motor to high speed High speed Chain_pulled / motor to low speed Low speed October 13, 2016 SE 430: Lecture 6 72 of 101

A more complex state machine Automated Driverless Subway train stopped at station stop marker detected / stop train approaching station entry / announce next stop do / slow down entry / announce arrival entry / open doors are open approach marker detected waiting for passengers running entry / set timer expiration / close doors are closed running speed reached ready to depart do / accelerate October 13, 2016 SE 430: Lecture 6 73 of 101

Basic statechart elements § Initial pseudostate. Not a true state. Points to initial state § State. Indicates a behavioral ‘atom’ of the object. In other words, the § § smallest ‘chunk’ of behavior of interest at the current level of abstraction Transition. Indicates movement from one state to another state Transition label. Consists of three optional parts: Ø Trigger signature. The single event that triggers the transition. Usually omitted in connection with activity states Ø Guard. A Boolean condition that must be true for the transition to occur Ø Activity. Behavior that is executed during the transition Ø Transition label format: trigger-signature [guard] /activity Final state. Indicates the completion of the state machine Essential statechart conventions: Ø Indicate starting state. Ø All transitions must have associated events. October 13, 2016 SE 430: Lecture 6 74 of 101

Advanced statechart elements § Internal activities represent a non-interruptible means for a state to react to events without a transition: the event, guard, and activity appear within the state itself Ø Two special activities are entry/ (executed upon entering the state) and exit/ (executed upon leaving the state) Ø A self-transition is a transition that loops back to the same state. It is equivalent to an internal activity Ø Internal activities and self transitions do not trigger entry or exit activities: only external transitions trigger these special activities § Activity states Ø Activity states represent a state in which the object is doing ongoing work and is interruptible Ø The ongoing activity is indicated with do/ Ø The state is named with a present participle form: ‘-ing’ for clarity. Ø October 13, 2016 SE 430: Lecture 6 75 of 101

Events § Events are “occurrences”: things that happen within the system § Events can cause transitions or they can trigger actions within a state § Events are not only “external” or “physical” events – it is useful to model many different kinds of occurrences as events in a state model: Ø one of the internal data members within the object reaches a threshold value » example: an airplane reaches cruising altitude Ø one of the objects embedded within the object changes its state » example: the tape drive of a VCR senses the end of tape, so it stops the motor of the VCR and it notifies the VCR’s display to change what it displays October 13, 2016 SE 430: Lecture 6 76 of 101

Events § Events are not only “external” or “physical” events – it is useful to model many different kinds of occurrences as events in a state model: Ø Ø Ø one of the objects that the object’s class has an “association” to changes its state » example: an employee transfers, so the states of two managers are updated (the manager gaining an employee and the manager losing an employee) someone calls one of the operations of the object » example: a web server logs the current user of a web page on its usage log (by calling one of the operations of the usage log class) an outside actor triggers an event » example: user presses microwave cook button October 13, 2016 SE 430: Lecture 6 77 of 101

Actions § Actions are the only things in the state model that can make changes to the data within objects § Some of the actions that might be performed in a state or on a transition Ø Ø set or modify one of the data members of the object trigger an event in another object execute one of the operations on this object call one of the public operations of another object October 13, 2016 SE 430: Lecture 6 78 of 101

State modeling assumptions § Within an object’s state machine, only one action can be executed at a time § Once an action is started, it runs to completion before another event is received § Actions in different state machines (different class, or same class but different object) can be executing simultaneously October 13, 2016 SE 430: Lecture 6 79 of 101

State modeling assumptions § Events are never lost Ø Ø if an action in state machine S 1 triggers an event in state machine S 2, it is assumed that the event will be received by S 2 (although it might wait until all of the “start” actions are completed) but the event will be ignored if it is “unexpected” (S 2’s current state doesn’t have a transition or an action with the received event) § Events are “used up” when received by a state machine October 13, 2016 SE 430: Lecture 6 80 of 101

What does a state represent? § A state represents one of the “personalities” of an object § When an object is in a specific state, that state puts some restrictions on what the object can do: Ø Ø For example, a automated driverless subway train object shouldn’t be able to open its doors while it is in the running state You may need to do a complete analysis of all events that an object can detect to make sure that it is “safe” October 13, 2016 SE 430: Lecture 6 81 of 101

Exercise: Identifying States § Identify some of the key states for the following objects: Ø Ø Microwave power tube Drawbridge Bank account Overnight express package October 13, 2016 SE 430: Lecture 6 82 of 101

Exercise: Identifying States § Identify some of the key states for the following objects: Ø Ø Microwave power tube » On » Off Drawbridge » Open » Closed » Raising » Lowering October 13, 2016 SE 430: Lecture 6 83 of 101

Exercise: Identifying States § Identify some of the key states for the following objects: Ø Ø Bank account » Has money » Zero Balance » Overdrawn Overnight express package » In truck » In distribution center » In airplane October 13, 2016 SE 430: Lecture 6 84 of 101

More about states § The state of an object might be a useful way to encode some information about what has happened to the object in the past: Ø some state machines have multiple branches, depending on key events Overnight express package received by customer entry / record package num and customer signature returning to sender entry / update package destination info October 13, 2016 ery liv de OK de l no iver t. O y K uck entry / verify shipping ticket entry / collect money put on truck put on tr picked up in truck entry / record package num and truck num arrival put on truck in sorting office entry / record package num entry / choose the next plane or truck in plane entry / record package num and plane num SE 430: Lecture 6 put on plane 85 of 101

State tables event: old state: picked up in truck in sorting office put on truck put on plane arrival delivery OK delivery not OK in truck can't happen can't happen in sorting off. can't happen in truck in plane can't happen received by customer returning to sender can't happen in plane can't happen in sorting off. can't happen received by customer can't happen can't happen can't happen returning to sender in truck The “state table” can be used to show the same information as the state diagram October 13, 2016 SE 430: Lecture 6 86 of 101

Relationship between State Diagram and Class Diagram § A state diagram relates to ONE class within a class diagram. The § § received events are often messages that will have originated at one of the other classes with which the class in question has a relationship. Events are basically received messages and are therefore handled by a receiving class operation. Actions - happening upon a state transition - are usually class operations that may result in a message being sent to another object. Activities - happening within a particular class state - are usually class operations. Most classes are uninteresting as far as state goes. But, many controller classes would be good candidates for state diagrams. October 13, 2016 SE 430: Lecture 6 87 of 101

Complex state diagrams § If an object has many internal states, the state diagram might be simplified by using “nested states” within a simple high-level state diagram Ø nested states are also a technique to refine existing state machines § If an object is an aggregate, its state diagram might contain “concurrent substates” that describe the states of the parts Ø Ø concurrent substates are another way to express the possibility of parallel operations in the model or it can express some operations where “order isn’t important” October 13, 2016 SE 430: Lecture 6 88 of 101

Nested state example Automated Driverless Subway train stopped at station stop marker detected / stop train entry / announce arrival entry / open doors approaching station approach marker detected entry / announce next stop do / slow down running doors are open decelerating waiting for passengers entry / set timer expiration / close doors are closed do / slow down semaphore is green semaphore is red accelerating do / accelerate October 13, 2016 SE 430: Lecture 6 train stopped waiting semaphore is green semaphore is red running speed reached full speed 89 of 101

Concurrent substates example Course registration request partially filled out SSN empty entry / clear SSN and course id SSN not valid / clear SSN validating entry / check SSN Course id empty cid not valid / clear cid October 13, 2016 validating entry / check cid user enters SSN valid user enters cid valid SE 430: Lecture 6 filled out This state will not be entered until both the SSN and Course id fields are filled in and valid 90 of 101

Use Case State Diagrams State charts are useful to describe legal sequence of external events § During process sale Ø Not legal to make. Credit. Payment until the end. Sale has occurred October 13, 2016 SE 430: Lecture 6 91 of 101

Example October 13, 2016 SE 430: Lecture 6 92 of 101

Retrieval agent behavior October 13, 2016 SE 430: Lecture 6 93 of 101

Basic statechart for retrieval agent Initial pseudostate Trigger signature retrieve(item) Wait State Locate Item Server item requested receive location Request Item Transition item returned Wait for Item Trigger signature w/ activity done()/ destroy(self) October 13, 2016 Return Item receive(item) Final state SE 430: Lecture 6 94 of 101

More detailed statechart for retrieval agent State w/ internal activities retrieve(item) Wait Locate Item Server receive location Request Item entry/open connection /request(item) /establish callback exit/close connection Regular activities occur ‘instantaneously’ and cannot be interrupted by regular events item returned item requested Selftransition done()/ destroy(self) Waiting for Item clear event queues Destroy do/monitor retrieve and connected/ receive queues request(item) Return Item receive(item) do-activities take finite time and can be interrupted. In this case, the interrupt is the invocation of the receive(item) callback from the server Activity state October 13, 2016 SE 430: Lecture 6 95 of 101

Statechart for retrieval agent with superstate Request Item Superstate with substates retrieve(item) Wait entry/open server connection /request(item) /establish callback exit/close server connection receive location Locate Item Server done()/ destroy(self) Initiate Request item requested start receive(item) Execute Callback Waiting for Item item returned clear event queues Destroy Return Item do/monitor retrieve and receive queues receive(item) complete entry/accept connection exit/open connection opened Transfer Item Trigger w/Guard October 13, 2016 receive data exit/close connection [~EOF] SE 430: Lecture 6 96 of 101

Statechart for retrieval agent showing Time out events October 13, 2016 SE 430: Lecture 6 97 of 101

Dynamic modeling notation choices State models and interaction diagrams emphasize different dynamic characteristics: § A state model emphasizes the different “personalities” (states) of the objects and the events that may change the current personality § A interaction diagram emphasizes the flow of control among the objects October 13, 2016 SE 430: Lecture 6 98 of 101

Dynamic modeling notation choices § When should you use state diagrams? When should you use interaction diagrams? Ø Ø If the classes have complex internal states, but the number of different events is relatively small, use state diagrams When you want to describe the collaboration among a group of classes that have simple internal states, use communication diagrams or sequence diagrams § When are state diagrams useful? Ø Ø Objects with distinctly different behavior during different time periods; event driven systems Objects that are aggregates, with complex interactions between the component parts October 13, 2016 SE 430: Lecture 6 99 of 101

Summary All systems have a static and dynamic behavior § The static structure can be described using class models § The behavior describes how the elements within the structure interact over time § The state diagram describes the behavior of and the internal states within a class, focusing on how objects over time change their states, depending on events that occur, the actions and when transitions occur § We have presented some notations for expressing time-dependent behavior Ø Interaction diagrams Ø State models § These diagrams add more information to the model Ø Information about the order in which the behavior of individual objects can be used Ø The possibility of changing the “personality” for some objects during their lifecycle October 13, 2016 SE 430: Lecture 6 100 of 101

Next Time § Packages § Frameworks § Patterns Overview Ø A System of Patterns Ø Coupling and Cohesion Ø Design Patterns Ø Architectural Responsibility Driven Design Ø GRASP Patterns Design Scenarios - used for assignment 5! Assignment 4 – Due October 20, 2016 Preliminary project description due October 20, 2016 Ø § § October 13, 2016 Reading: Ø Arlow & Neustadt, Ch. 's 19, 20 Ø Responsibility-based Modeling Ø Responsibility-Driven Design Ø Software Patterns Ø Java Go. F Creational Design Patterns Ø Java Go. F Behavioral Design Patterns Ø Java Design Patterns Reference and Examples SE 430: Lecture 6 101 of 101