1. SE 430 Object Oriented Modeling
Lecture 1
SE 430
October 13, 2016
January 8, 2008
SE 430 Object Oriented Modeling
Dennis Mumaugh, Instructor
Office: CDM, Room 428
Office Hours: Thursday, 4:00 – 5:30
October 13, 2016
SE 430: Lecture 6
Lecture 6
SE 425
1/108

2. Administrivia Comments and feedback Exam
SE 430
October 13, 2016
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
Lecture 6

3. Discussion: Assignment 3
SE 430
October 13, 2016
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
Lecture 5

4. Assignment 4 Mixed Information Display – Due October 20, 2016
SE 430
Assignment 4
October 13, 2016
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
Lecture 6

5. SE 430 – Class 6 Topics: Objects Reading:
October 13, 2016
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
Lecture 6

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

7. Last Class Transition to Design Software Architecture
SE 430
Last Class
October 13, 2016
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
October 13, 2016
SE 430: Lecture 6
Lecture 6

8. Analysis Phase Analysis Phase
October 13, 2016
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
Lecture 6

9. Analyzing Requirements
SE 430
Analyzing Requirements
October 13, 2016
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
Lecture 6

10. Where do objects fit into O-O modeling?
SE 430
Where do objects fit into O-O modeling?
October 13, 2016
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
Lecture 6

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

12. What comprises an object?
October 13, 2016
Minimum set of attributes that specifies the condition of the object.
Identity
Behavior
State
External actions (self-initiated) and reactions (externally- initiated) of the object.
Distinguishes object from all others.
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()
TimeOfDay
IP address
Process ID
Unique ID
Memory address.
time:TimeOfDay
«instanceOf»
Will discuss state, behavior, and identity in more detail, following.
Attributes are formalized in the class, but discovered through the objects.
October 13, 2016
SE 430: Lecture 6
Lecture 6

13. SE 430
Object state
October 13, 2016
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 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 10:01:57.
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.
October 13, 2016
SE 430: Lecture 6
Lecture 6

14. SE 430
Behavior – general
October 13, 2016
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 TimeOfDay changes the value of the isUpdated private instance variable as part of update() operation.
Message may change a single attribute value or do something more radical such as destroy the object.
October 13, 2016
SE 430: Lecture 6
Lecture 6

15. Behavior – types of operations
SE 430
Behavior – types of operations
October 13, 2016
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
Lecture 6

16. Behavior – types of operations
SE 430
Behavior – types of operations
October 13, 2016
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));
October 13, 2016
SE 430: Lecture 6
Lecture 6

17. Object responsibilities
SE 430
Object responsibilities
October 13, 2016
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
Lecture 6

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

19. A possible point of confusion
SE 430
A possible point of confusion
October 13, 2016
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
Lecture 6

20. System [Operation] Contract
SE 430
System [Operation] Contract
October 13, 2016
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
Lecture 6

21. System [Operation] Contract
SE 430
System [Operation] Contract
October 13, 2016
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
Lecture 6

22. SE 430
Design by contract
October 13, 2016
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
Lecture 6

23. SE 430
Preconditions
October 13, 2016
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.
October 13, 2016
SE 430: Lecture 6
Lecture 6

24. SE 430
Postconditions
October 13, 2016
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)
October 13, 2016
SE 430: Lecture 6
Lecture 6

25. Contract format Sections of a contract (from Larman, p. 183):
October 13, 2016
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.
October 13, 2016
SE 430: Lecture 6
Lecture 6

26. Active and passive objects
SE 430
Active and passive objects
October 13, 2016
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
Lecture 6

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

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

29. SE 430
Identity
October 13, 2016
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)
Identity may be a ‘meta-attribute’ (something not integral to the object or its class) such as a pointer.
Identity: IP address.Process ID.Unique ID.Memory address.
October 13, 2016
SE 430: Lecture 6
Lecture 6

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

31. SE 430
Links – general
October 13, 2016
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 g e t A l o w d c i n s ( u r , h a ) L m 1 2 4 C P : S y D p
handle.receive(user,allowedActionList )
Bi-directional message passing: asynchronous message pair using a callback
Return value
Note object labeling convention:
instance:Class
Links are the most general form of relationship between objects Then come associations, etc.
October 13, 2016
SE 430: Lecture 6
Lecture 6

32. SE 430
Links – visibility
October 13, 2016
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
Lecture 6

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

34. SE 430
Dynamic Modeling
October 13, 2016
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
Lecture 6

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

36. Interaction Diagrams Design
SE 430
Interaction Diagrams
October 13, 2016
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
Lecture 6

37. SE 430
Interaction Diagrams
October 13, 2016
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
Lecture 6

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

39. SE 430
Sequence Diagrams
October 13, 2016
(Message) Sequence Diagrams – Useful for displaying time sequences, object activation and concurrent processes
external
event
Librarian
Book
Borrower
check book out
check out
update book list
collaborations
allowed to check out
In this simple scenario, a Librarian object is responsible for checking a book out (in response to an external event – probably a request by an outside actor in a use case). In this example, the Librarian performs the task by “collaborating” with a Book and a Borrower. The Librarian object tells each of them to perform one or more specific responsibilities.
Note: This kind of scenario diagram has the same form as the scenario diagrams shown earlier, but the context is different. The scenario diagrams earlier were used to describe use cases, so there was one column for the “system” and other columns for outside “actors”. The scenario diagram above is describing behavior of “objects” inside of the system, so each column represents an object from the given class.
October 13, 2016
SE 430: Lecture 6
Lecture 6

40. Sequence Diagrams To model a flow of control by time ordering,
October 13, 2016
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
Lecture 6

41. SE 430
Sequence Diagrams
October 13, 2016
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.
October 13, 2016
SE 430: Lecture 6
Lecture 6

42. SE 430
Sequence Diagrams
October 13, 2016
Messages are indicated by a solid line with an arrow.
Two kinds of arrows – synchronous and asynchronous. We will only show synchronous.
Arrow
Meaning
Arrow head style
Synchronous
Transfer control and wait for answer. (sequential operations)
Return
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
Lecture 6

43. Sequence Diagrams Messages can also have control information A message
October 13, 2016
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.
October 13, 2016
SE 430: Lecture 6
Lecture 6

44. SE 430
Sequence Diagrams
October 13, 2016
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
Lecture 6

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

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

47. Communication Diagrams
SE 430
Communication Diagrams
October 13, 2016
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):
communication or collaboration diagrams are used to describe object behavior in some software development projects. No elaborate CASE tool support is needed: communication diagrams can be created with simple drawing packages such as Visio or MS Word.
The UML notation for an object in a communication diagram is similar to the notation for a class in a Class diagram: a multipart rectangular box. There are three differences:
an object is at most a two-part box, with the name of the object and its data
the name section of an object is underlined
the name section of an object can have the name of the object and its class type
When should you use state diagrams? When should you use communication diagrams?
state diagrams are most useful for describing individual classes that have complex internal states, but the interactions between objects of different classes can be viewed in terms of “events transmitted to another object” - the state model is most useful when the set of events is relatively simple (the average class responds to about 3 or 4 events, the worst class responds to no more than 12 events)
communication diagrams are most useful for describing a group of classes that have simple internal states, but the interactions between the objects of different classes can be viewed in terms of “function calls to the public interface of objects”
truckCounter : Car counter
car_count = 0
enteringCar : Car
car_id = NJ 2345
weight = 2700
: Meter
value = 150
object name
is optional
October 13, 2016
SE 430: Lecture 6
Lecture 6

48. Communication Diagram Example
SE 430
October 13, 2016
Each box represents an object
Each line connecting two objects represents a “message” or a function call
[See note for equivalent sequence diagram]
inSensor : Car sensor
garageCounter : Car counter
garageMeter : Meter
car_entering()
1: add_car()
1.1: update()
garageGate : Gate
1.2: close()
The “messages” in a communication diagram might be synchronous or asynchronous. This example shows synchronous messages (“function calls”).
Here is an example of the equivalent Sequence diagram that corresponds to the example communication diagram.
October 13, 2016
SE 430: Lecture 6
inSensor
(Car sensor)
garageCounter
(Car counter)
garageMeter
(Meter)
garageGate
(Gate)
car_entering()
add_car()
update()
close()
Lecture 6

49. Communication Diagram Example
SE 430
Communication Diagram Example
October 13, 2016
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]
inSensor : Car sensor
garageCounter : Car counter
garageMeter : Meter
car_entering()
1: add_car()
1.1: update()
garageGate : Gate
1.2: close()
The “messages” in a communication diagram might be synchronous or asynchronous. This example shows synchronous messages (“function calls”).
Here is an example of the equivalent Sequence diagram that corresponds to the example communication diagram.
October 13, 2016
SE 430: Lecture 6
inSensor
(Car sensor)
garageCounter
(Car counter)
garageMeter
(Meter)
garageGate
(Gate)
car_entering()
add_car()
update()
close()
Lecture 6

50. Another Communication Diagram Example
SE 430
Another Communication Diagram Example
October 13, 2016
Example: registering a student in a course that is full
theStudentDir :
Student_directory
aCourse : Course
courseWaitList : WaitingList
register_student()
2: is_full()
3: add_student()
1: validate_student()
Student
This is equivalent to the following sequence diagram:
aCourse
(Course)
theStudentDir
(Student directory)
courseWaitList
(Waiting List)
register_student()
October 13, 2016
SE 430: Lecture 6
validate_student()
is_full()
add_student()
Lecture 6

51. SE 430
Another Example
October 13, 2016
Example: unregistering a student who is registered in the course
aCourse : Course
courseWaitList : WaitingList
unregister_student()
1: student_id :=
get_first_student()
Student
2: remove_student(student_id)
3: add_student(student_id)
This is equivalent to the following sequence diagram:
aCourse
(Course)
courseWaitList
(Waiting List)
unregister_student()
October 13, 2016
SE 430: Lecture 6
student_id := get_first_student()
remove_first_student(student_id)
add_student(student_id)
Lecture 6

52. Our example: Mixed information display
SE 430
Our example: Mixed information display
October 13, 2016
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
Lecture 6

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

54. Communication Diagram
SE 430
Communication Diagram
October 13, 2016
Notes
Communication diagrams were called collaboration diagrams in pre-UML 2.0
Callback handles left out to reduce clutter 1 . 3 : * [ f o r e a c h i t m ] d s p l y ( ) V w R v A g n S D u 2 q I
& M b j k 4
October 13, 2016
SE 430: Lecture 6
Lecture 6

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

56. Sequence diagram with alt frame (partial)
October 13, 2016 : D i r e c t o y p m a S v n w V T ( ) R l A g q u s h [ f ] d , . b k
<
Note: This sequence diagram shows only part of the interaction for our example
October 13, 2016
SE 430: Lecture 6
Lecture 6

57. Sequence diagram notation
October 13, 2016
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, similarly-typed 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
Lecture 6

58. Sequence diagram notation
October 13, 2016
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
Lecture 6

59. Sequence diagram notation
October 13, 2016
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
Lecture 6

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

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

62. Interaction Diagrams Guidelines for Creating an Interaction Diagram
SE 430
Interaction Diagrams
October 13, 2016
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
Lecture 6

63. SE 430
Interaction Diagrams
October 13, 2016
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
Lecture 6

64. Interaction Diagrams Steps from Use Cases to Interaction Diagrams
October 13, 2016
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
Lecture 6

65. SE 430 State-Space and Behavior
October 13, 2016
Object Statecharts
State-Space and Behavior
State diagrams are only one notation for describing time-dependent interactions. We have already seen another: sequence diagrams. State diagrams can describe a whole set of scenarios in a concise form.
State diagrams aren’t always the best or clearest notation for describing behavior information. They require some description of additional elements (events and actions) that are not already part of the static model.
When does it make sense to use a state diagram to describe the behavior of a class? This unit will show some examples of the two types of items listed above.
October 13, 2016
SE 430: Lecture 6
Lecture 6

66. SE 430
Overview
October 13, 2016
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
The modeling notations that are discussed here come from a wide variety of sources.
The state model notation that will be described in this unit is standard UML notation based on Harel statecharts. This notation has been used for modeling state machines in OMT and in the Booch methodology since the early 1990s, because the notation is relatively easy to read and it is much more expressive and compact than some other alternative state modeling notations used in other methodologies.
Sequence diagrams have already been presented as a technique for describing use cases. They are related to the “protocol diagrams” or “event traces” that have been used for many years to design communication protocols and electronic circuits. Sequence diagrams were made popular for object oriented system documentation by Ivar Jacobson.
communication diagrams are very similar to the “object interaction graphs” notation in the HP Fusion methodology. They are distantly related to dataflow diagrams and other popular flow-based notations of the 1970s. The UML notation for communication diagrams was first proposed by James Rumbaugh in 1994.
October 13, 2016
SE 430: Lecture 6
Lecture 6

67. The reason for state models
SE 430
The reason for state models
October 13, 2016
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
Lecture 6

68. Modeling entities as deterministic machines
SE 430
Modeling entities as deterministic machines
October 13, 2016
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
Lecture 6

69. Events, States and Activities
SE 430
Events, States and Activities
October 13, 2016
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
Lecture 6

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

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

72. Parts of a State Diagram
SE 430
Parts of a State Diagram
October 13, 2016
State: an abstraction of the 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
2-speed ceiling fan
Off
Chain_pulled /
motor to high speed
Chain_pulled / motor off
High speed
What does it mean to say that the “state” is an abstraction of attribute values? It means that we don’t necessarily look at the fine details, only the things that matter for the problem at hand. Examples of objects and their states:
airplane flight: boarding, departing, on time, late, landed, arrived
steak: raw, rare, medium rare, medium, medium well, well-done, burnt
library book: in, checked out, overdue, lost
Some notes on the UML notation:
Each state is in a box with rounded corners.
The arrow with the black dot indicates the initial state of the ceiling fan.
Each transition arrow is labeled with two things: the event that triggers the transition and the action that is performed when the event is detected.
In this diagram, there are three states for the fan object (Off, High speed, and Low speed), there is one transition out of each state, and there is only one kind of event (Chain_pulled). In UML, there is always a “/” between the event and the action that is associated with the event.
Chain_pulled /
motor to low speed
Low speed
October 13, 2016
SE 430: Lecture 6
Lecture 6

73. A more complex state machine
SE 430
October 13, 2016
running
stopped at station
entry / announce arrival
entry / open doors
waiting for passengers
entry / set timer
timer expiration / close doors
doors are open
doors are closed
ready to depart
do / accelerate
running speed reached
approaching station
entry / announce next stop
do / slow down
stop marker detected /
stop train
approach marker
detected
Automated Driverless Subway train
This state diagram describes the operation of an automated driverless subway train. The train is designed to stop at each station, open the doors, wait for a fixed period of time, close the doors, and proceed to the next station.
In this state diagram, most of the actions are within the states (except for the “stop train” action at the top). In UML, when an action is listed within a state, it is preceded by a label that indicates when the action is supposed to happen. There are four possible kinds of labels:
entry: the action is performed when the state is entered
exit: the action is performed just before the transition to a new state
do: the action is performed continuously during the entire period that the object is in this state
any event name: the action is performed when the event occurs and the object stays in the same state
This state diagram is somewhat unrealistic, because the model doesn’t concern itself with avoiding other trains on the same track. This would make the model much more complex.
October 13, 2016
SE 430: Lecture 6
Lecture 6

74. Basic statechart elements
SE 430
Basic statechart elements
October 13, 2016
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
Lecture 6

75. Advanced statechart elements
SE 430
Advanced statechart elements
October 13, 2016
Internal activities
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
Lecture 6

76. Events Events are “occurrences”: things that happen within the system
October 13, 2016
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
In UML, a simple conditional expression can be used to express the first kind of event. For example:
number of passengers > 15 / illuminate elevator warning light
October 13, 2016
SE 430: Lecture 6
Lecture 6

77. SE 430
Events
October 13, 2016
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
In UML, a simple conditional expression can be used to express the first kind of event. For example:
number of passengers > 15 / illuminate elevator warning light
October 13, 2016
SE 430: Lecture 6
Lecture 6

78. SE 430
Actions
October 13, 2016
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
In the UML notation, most actions are described using simple pseudocode.
There may be operations for a class that are only invoked when an object enters a specific state, or when the state machine for the object makes a specific transition. This is a common way that a “restricted” function (a function that can only be called in special circumstances) is represented in a state diagram. For example, the “open doors” operation in the Automated Driverless Subway train should only be invoked when the train object is in the “stopped at station” state.
Some operations only exist to trigger events in other state machines.
Note on notation for state machine pros: in UML state notation, actions can either be in a state (for example: the announce arrival action in the “stopped at station” state) or on a transition (for example: the stop train action next to the “stop marker detected” event). There are other non-UML forms of state modeling notation that may limit actions to one form or the other. In “Mealy machines” (used in the SDL notation and elsewhere), the actions can only appear on transitions. In “Moore machines” (used in Shlaer-Mellor and elsewhere), the actions can only appear in states.
October 13, 2016
SE 430: Lecture 6
Lecture 6

79. State modeling assumptions
SE 430
State modeling assumptions
October 13, 2016
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
The state models assume a “concurrent processing” model, but as we will see in the design unit, the actual implementation might not be capable of doing multiple concurrent things. If it is known at analysis time that concurrent operations will not be possible in the final system, then the analysis-level state model will need to be carefully checked over in order to insure that it doesn’t actually require a “concurrent implementation architecture”.
October 13, 2016
SE 430: Lecture 6
Lecture 6

80. State modeling assumptions
SE 430
State modeling assumptions
October 13, 2016
Events are never lost
if an action in state machine S1 triggers an event in state machine S2, it is assumed that the event will be received by S2 (although it might wait until all of the “start” actions are completed)
but the event will be ignored if it is “unexpected” (S2’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
The state models assume a “concurrent processing” model, but as we will see in the design unit, the actual implementation might not be capable of doing multiple concurrent things. If it is known at analysis time that concurrent operations will not be possible in the final system, then the analysis-level state model will need to be carefully checked over in order to insure that it doesn’t actually require a “concurrent implementation architecture”.
October 13, 2016
SE 430: Lecture 6
Lecture 6

81. What does a state represent?
October 13, 2016
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”
The complete internal state for an object is the combination of the data values within the object. This may lead to thousands or millions of different states, so the states we choose to describe in a state model usually depend either on a grouping of data values and ranges, or they depend on the group of operations that are permitted on the object during different parts of its lifecycle.
October 13, 2016
SE 430: Lecture 6
Lecture 6

82. Exercise: Identifying States
October 13, 2016
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
Lecture 6

83. Exercise: Identifying States
October 13, 2016
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
Lecture 6

84. Exercise: Identifying States
October 13, 2016
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
Lecture 6

85. More about states Overnight express package
SE 430
More about states
October 13, 2016
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
picked up
entry / verify shipping ticket
entry / collect money
in truck
entry / record
package num
and truck num
returning to sender
entry / update package
destination info
received by customer
entry / record package num
and customer signature
delivery OK
in plane
and plane num
in sorting office
entry / choose the next
plane or truck
put on truck
put on plane
arrival
not OK
This state machine is more complicated than the previous examples. During the state “in sorting and transport” (when the package spends most of its time in trucks, planes, or in one or more express package sorting offices), there are three major events that could happen. The information that is recorded is different in each case, and if the “delivery not OK” event happens (if the destination address is bad or the customer doesn’t sign for the package) there will be some modification of the internal data in the Overnight express package object to make sure that it will get back to the sender.
October 13, 2016
SE 430: Lecture 6
Lecture 6

86. SE 430
State tables
October 13, 2016
picked up
in sorting office
received by customer
put on
truck
delivery OK
delivery
not OK
in truck
received
by customer
old state:
event:
can't happen
returning to sender
in plane
plane
returning
to sender
in sorting off.
arrival
In this example, the state diagram has been transformed into a table. This form is useful for small dense state machines. The table entries can be augmented to show the actions as well as the new state for each “old state, event” combination.
State tables force the analyst to consider all combinations of state and event. One common analysis mistake is to incorrectly label one of the boxes as “can't happen” – which will create an incomplete description of system behavior. This kind of problem is easier to catch when the state transitions are written in this tabular form.
The “state table” can be used to show the same information as the state diagram
October 13, 2016
SE 430: Lecture 6
Lecture 6

87. Relationship between State Diagram and Class Diagram
SE 430
Relationship between State Diagram and Class Diagram
October 13, 2016
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
Lecture 6

88. Complex state diagrams
SE 430
Complex state diagrams
October 13, 2016
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”
The examples on the next two slides show some of the added flexibility of the Harel statechart modeling notation. The goal of using these “advanced” notations is to try to model the problem more precisely – to communicate the essential structure of the problem to the designers and coders.
October 13, 2016
SE 430: Lecture 6
Lecture 6

89. waiting for passengers
Nested state example
October 13, 2016
stopped at station
entry / announce arrival
entry / open doors
waiting for passengers
entry / set timer
timer expiration / close doors
doors are open
doors are
closed
approaching station
entry / announce next stop
do / slow down
stop marker detected /
stop train
approach marker
detected
Automated Driverless Subway train
running
waiting
full speed
semaphore
is green
is red
accelerating
do / accelerate
decelerating
speed
reached
train
stopped
The running state has been decomposed into a bunch of states. When the running state is entered, the initial state of the nested state machine will be accelerating. All of the internal transitions will take place, but if one of the events on a transition from the running state is received, the nested state machine will be exited immediately, no matter which of the four nested states it is in.
As this example illustrates, the nested states notation can be used to add more information about the behavior within a single state. In this example, the running state is the only part of the state machine that cares about “semaphore” events - it is the only part of the system that needs to avoid other trains.
October 13, 2016
SE 430: Lecture 6
Lecture 6

90. Concurrent substates example
October 13, 2016
filled out
Course registration request
partially filled out
SSN empty
validating
entry / check SSN
user
enters
SSN
valid
SSN not
valid /
clear SSN
Course id
empty
entry / check cid
cid
cid not
clear cid
entry / clear
SSN and
course id
This state will not
be entered until
both the SSN and
Course id fields are
filled in and valid
In the partially filled out state, the state is split into two substates. These substates are viewed (for modeling purposes) as having separate “threads of control”. That is, each substate can act independently of the other – one of them responds to SSN entry and SSN validity check events, the other one responds to course id entry and course id validity check events. The transition to the next state only happens when both fields are filled out.
The example below shows a different application of concurrent states. In this state machine, the filled out state is reached when one of the two fields has been completed.
October 13, 2016
SE 430: Lecture 6
waiting for one field to be filled in
SSN empty
validating
entry / check SSN
user enters SSN
SSN valid
HRid valid
HRid not valid / clear HRid
SSN not valid / clear SSN
HRid empty
entry / check HRid
user enters HRid
filled out
empty
entry / clear SSN
and HRid
Lecture 6

91. Use Case State Diagrams
October 13, 2016
State charts are useful to describe legal sequence of external events
During process sale
Not legal to makeCreditPayment until the endSale has occurred
October 13, 2016
SE 430: Lecture 6
Lecture 6

92. Example October 13, 2016 SE 430: Lecture 6 SE 430 October 13, 2016

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

94. Basic statechart for retrieval agent
SE 430
Basic statechart for retrieval agent
October 13, 2016 L o c a t e I m S r v R u n i ( ) l W q s d / y f T g w p F
October 13, 2016
SE 430: Lecture 6
Lecture 6

95. More detailed statechart for retrieval agent
SE 430
More detailed statechart for retrieval agent
October 13, 2016 L o c a t e I m S r v R u n d / q s ( i ) D y W l f - w p b h k x g A
Regular activities occur ‘instantaneously’ and cannot be interrupted by regular events
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
October 13, 2016
SE 430: Lecture 6
Lecture 6

96. Statechart for retrieval agent with superstate
SE 430
Statechart for retrieval agent with superstate
October 13, 2016 I n i t a e R q u s r y / o p v c ( m ) b l h k x T f E C d [ ~ O F ] g w G S L D W
October 13, 2016
SE 430: Lecture 6
Lecture 6

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

98. Dynamic modeling notation choices
SE 430
Dynamic modeling notation choices
October 13, 2016
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
Some guidelines for choosing state diagrams versus communication diagrams:
state diagrams are most useful for describing individual classes that have complex internal states, but the interactions between objects of different classes can be viewed in terms of “events transmitted to another object” – the state model is most useful when the set of events is relatively simple (the average class responds to about 3 or 4 events, the worst class responds to no more than 12 events)
communication diagrams are most useful for describing a group of classes that have simple internal states, but the interactions between the objects of different classes can be viewed in terms of “function calls to the public interface of objects”
October 13, 2016
SE 430: Lecture 6
Lecture 6

99. Dynamic modeling notation choices
SE 430
Dynamic modeling notation choices
October 13, 2016
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
Some guidelines for choosing state diagrams versus communication diagrams:
state diagrams are most useful for describing individual classes that have complex internal states, but the interactions between objects of different classes can be viewed in terms of “events transmitted to another object” – the state model is most useful when the set of events is relatively simple (the average class responds to about 3 or 4 events, the worst class responds to no more than 12 events)
communication diagrams are most useful for describing a group of classes that have simple internal states, but the interactions between the objects of different classes can be viewed in terms of “function calls to the public interface of objects”
State diagrams are only one notation for describing time-dependent interactions. We have already seen another: sequence diagrams. State diagrams can describe a whole set of scenarios in a concise form.
State diagrams aren’t always the best or clearest notation for describing behavior information. They require some description of additional elements (events and actions) that are not already part of the static model.
October 13, 2016
SE 430: Lecture 6
Lecture 6

100. Summary All systems have a static and dynamic behavior
SE 430
Summary
October 13, 2016
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
Lecture 6

101. Next Time Packages Frameworks Patterns Patterns Overview
SE 430
Next Time
October 13, 2016
Packages
Frameworks
Patterns
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
Reading: 
Arlow & Neustadt, Ch.'s 19, 20
Responsibility-based Modeling
Responsibility-Driven Design
Software Patterns
Java GoF Creational Design Patterns
Java GoF Behavioral Design Patterns
Java Design Patterns Reference and Examples
October 13, 2016
SE 430: Lecture 6
Lecture 6