1. Chapter 10 Drawing System Sequence Diagrams
“In theory, there is no difference between theory and practice.
But in practice, there is.” - Jan L.A. van de Snepscheut
Objectives
Identify system events.
Create system sequence diagrams for use case scenarios
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

2. Fig 10.1: Sample UP artifact influence.
An SDD is a fast and
easily created artifact
that illustrates i/o
events related to
systems under
discussion.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

3. Iteration 1 First real development iteration.
The requirement work done during inception phase was to decide if the project was worth more serious investigation.
Before starting iteration 1 design work, further investigation of the problem domain is useful such as clarification of the input and output system events, related to the system.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

4. SSD versus Sequence Diagram
A System Sequence Diagram (SSD) is an artifact that illustrates input and output events related to the system under discussion.
SSDs are typically associated with use-case realization in the logical view of system development.
System Sequence Diagrams should be done for the main success scenario of the use-case, and frequent and alternative scenarios.
Sequence Diagrams (Not System Sequence Diagrams) display object interactions arranged in time sequence.
Sequence Diagrams depict the temporal order of the events.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

5. Sequence Diagrams
Sequence Diagrams depict the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the system.
The operations of the system in response to the events generated.
Sequence diagrams can be used to drive out testable user interface requirements.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

6. System Sequence Diagrams
Use cases describe-
How actors interact with system
Typical course of events that external actors generate, and
The order of the events
For a particular scenario of use-case an SSD shows-
The external actors that interact directly with the system.
The System (as a black box).
The system events that the actors generate.
Note: A software system basically reacts to three things:
External events from actors
Timer events
Faults or exceptions
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

7. SSD—System Behavior
is a description of what a system does, w/o explaining how it does it.
One part of that description is a SDD. Other parts include the use cases and system operation contracts.
System behaves as a “Black Box”.
Interior objects are not shown, as they would be on a Sequence Diagram.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

8. Notation : System actor1 Object: Objects are instances of classes.
Object is represented as a rectangle which contains the name of the object underlined.
Because the system is instantiated, it is shown as an object.
Actor: An Actor is modeled using the ubiquitous symbol, the stick figure.
: Object1
: System
actor1
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

9. messageName(argument)
Notation (2)
Lifeline: The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object.
Message: Messages, modeled as horizontal arrows between Activations, indicate the communications between objects.
messageName(argument)
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

10. Fig 10.2: SSD for A Process Sale Scenario.
Note the events generated
by cashier (actor) below.
What SSD info must be
put into Glossary?
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

11. Constructing a SSD from a Use Case
1. Draw a line representing the system as a black box.
2. Identify each actor that directly operates on the system. Draw a line for each such actor.
3. From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram.
4. Optionally, include the use case text to the left of the diagram.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

12. Fig 10.3: SSDs are derived from use cases; they show one scenario.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

13. Fig 10.4: Choose event and operation names at an abstract level.
System events should be expressed at the abstract level of intention
rather than in terms of the physical input device.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

14. Fig 10.5: SSD for a Play Monopoly Game scenario.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

15. Chapter 11 Operation Contracts
“When ideas fail, words come in very handy.” - Johann Wolfgang von Goethe
Objectives
Define system operations.
Create contracts for system operations.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

16. Fig 11.1: Sample UP artifact influence.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

17. Fig 11.2: SDD. System operations handle input system events.
Operation contracts may be defined for system operations – operations that the system as a black box component offers in its public interface.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

18. Fig 13.8: System operations in the SSDs and in terms of layers.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

19. System Operations and the System Interface
Contracts may be defined for system operations – operations that the system as a black box offers in its public interface to handle incoming system events. System operations can be identified by discovering these system events.
The entire set of system operations, across all use cases, defines the public system interface, viewing the system as a single component or class.
In the UML, the system as a whole can be represented as one object of a class named System.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

20. Domain Model And Contracts
A Domain Model is a visual representation of conceptual classes or real-world objects in a domain of interest.
Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed.
Guideline: Keep it Agile
In many, or even most software development projects, operation contracts may be unnecessary. For an agile process, use them only when necessary to add additional detail and understanding.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

21. Example Contract: enterItem
Contract Template:
Operation: Name Of operation, and parameters.
Cross References: (optional) Use cases this can occur within.
Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation.
Postconditions: -The state of objects in the Domain Model after completion of the operation.
Contract CO2: enterItem
Operation: enterItem(itemID : ItemID, quantity : integer)
Cross References: Use Cases: Process Sale
Preconditions: There is a Sale Underway.
Postconditions: - A SalesLineItem instance sli was created (instance creation) - sli was associated with the current Sale (association formed) - sli.quantity became quantity (attribute modification) - sli was associated with a ProductSpecification, based on itemID match (association formed)
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

22. Writing Contracts Leads to Domain Model Updates
New conceptual classes, attributes, or associations in the Domain Model are often discovered during contract writing.
Enhance the Domain Model as you make new discoveries while thinking through the operation contracts.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

23. Why Contracts
Use cases are the primary mechanism in the UP to describe system behavior, and are usually sufficient.
However, sometimes a more detailed description of system behavior has value. Contracts for operations can help define system behavior.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

24. Contracts vs. Use Cases
The use cases are the main repository of requirements for the project. They may provide most or all of the detail necessary to know what to do in the design.
If the details and complexity of required state changes are awkward to capture in use cases, then write operation contracts.
If developers can understand what to do based on the use cases and ongoing (verbal) collaboration with a subject matter expert, avoid writing contracts.
Operation contracts are uncommon. If a team is making contracts for every system operation:
the use cases are poorly done, or
there is not enough collaboration or access to a subject matter expert, or
the team is doing too much unnecessary documentation.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

25. Postconditions
The postconditions describe changes in the state of objects in the Domain Model.
Domain Model state changes include
instances created,
associations formed or broken,
and attributes changed.
Postconditions are not actions to be performed, during the operation; rather, they are declarations about the Domain Model objects that are true when the operation has finished.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

26. The Spirit of Postconditions: The Stage and Curtain
Express postconditions in the past tense, to emphasize they are declarations about a state change in the past.
(better) A SalesLineItem was created.
(worse) Create a SalesLineItem.
Think about postconditions using the following image:
The system and it’s objects are presented on a theatre stage.
Before the operation, take a picture of the stage.
Close the curtains on the stage, and apply the system operation
Open the curtains and take a second picture.
Compare the before and after pictures, and express as postconditions the changes in the state of the stage (A SalesLineItem was created…).
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

27. Guideline: Writing Contracts
To make contracts:
Identify system operations from the SSDs.
For system operations that are complex and perhaps subtle in their own results, or which are not clear in the use case, construct a contract.
To describe the postconditions, use: - instance creation and deletion - attribute modification - associations formed and broken
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

28. The Most Common Mistake In Creating Contracts
The most common problem in creating contracts is forgetting to include the forming of associations.
Particularly, when new instances are created, it is very likely that associations to several objects need be established.
Don’t forget to include all the associations formed and broken.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

29. Contracts, Operations, and the UML
The UML formally defines operations. To quote:
An operation is a specification of a transformation or query that an object may be called to execute [RJB99]
An operation is an abstraction, not an implementation. By contrast, a method (in the UML) is an implementation of an operation.
A UML operation has a signature (name and parameters), and also an operation specification, which describes the effects produced by executing the operation; the postconditions.
A UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

30. Operation Contracts Within the UP
A pre- and postcondition contract is a well-known style to specify an operation. In UML, operations exist at many levels, from top level classes down to fine-grained classes.
Operation specification contracts for the top level classes are part of the Use-Case Model.
Phases
Inception – Contracts are not needed during inception – they are too detailed.
Elaboration – If used at all, most contracts will be written during elaboration, when most use cases are written. Only write contracts for the most complex and subtle system operations.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

31. Chapter 12 Requirements to Design - Iteratively
“Hardware, n.: The parts of a computer system that can be kicked.” - anonymous
Objectives
Quickly motivate the transition to design activities.
Contrast the importance of object design skill versus UML notation knowledge.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

32. Introduction
Following the UP guidelines, perhaps 10% of the requirements were investigated in inception, and a slightly deeper investigation was started in this first iteration of elaboration.
Now we shift our emphasis toward designing a solution for this iteration in terms of collaborating software objects.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

33. Iteratively Do the Right Thing, Do the Thing Right
The requirements and object-oriented analysis has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the Next-Gen POS, and related rules and constraints.
In iterative development, a transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

34. Didn’t That Take Weeks To Do? No, Not exactly.
When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to do all the actual modeling that has been explored so far is realistically just a few days.
However that does not mean that only a few days have passed since the start of project. Many other activities such as proof-of-concept programming finding resources (people,software ….) planning,setting up the environment could consume a few weeks of preparations.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

35. On to Object Design
During object design, a logical solution based on the object-oriented paradigm is developed. The heart of this solution is the creation of interaction diagrams which illustrates how objects collaborate to fulfill the requirements.
After-or in parallel with-drawing interaction diagrams, (design) class diagrams can be drawn.
In practice,the creation of interaction and class diagram happens in parallel and synergistically, but their introduction in the textbook case study is linear for simplicity and clarity.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

36. Importance of Object Design Skill vs UML Notation skill
Drawing UML interaction diagrams is the reflection of making decisions about the object design.
The object design skills are what really matter, rather than knowing how to draw UML diagrams.
Fundamental object design requires knowledge of :
Principles of responsibility assignment
Design patterns
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

37. Chapter 13 Logical Architecture and UML Package Diagrams
“0x2B | ~ 0x2B.” - Hamlet
Objectives
Introduce a logical architecture using layers.
Illustrate the logical architecture using UML package diagrams.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

38. Fig 13.1: Sample UP artifact influence.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

39. Fig 13.2: Layers shown with UML package diagram notation.
Example
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

40. Definition: Architecture
In software development, architecture is thought of as both noun and a verb.
As a noun, the architecture includes the organization and structure of the major elements of the system.
As a verb, architecture is part investigation and part design work.
Architectural investigation: involves functional and non-functional requirements that have impact on system design.
Some of these are: market trends, performance, cost and points of evolution.
Architectural Design: is the resolution of these requirements in the design of software.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

41. Definition: Software Architecture
There are various forms of it. But the common theme is that it has to do with large scale-the Big Ideas in the forces, organization, styles, patterns, responsibilities, collaborations, connections and motivations of a system and major subsystems.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

42. Architectural Dimension and Views in UP
The common dimensions are:
The logical architecture, describes the system in terms of its conceptual organization in layers, packages, classes, interfaces and subsystems.
The deployment architecture, describes the system in terms of the allocation of process to processing unit and network configurations.
Architectural Layers are a logical view of the architecture
They are not a deployment view of elements to process.
Depending on platform, all layers could be deployed within the same process on same node OR across many computers.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

43. Architectural Patterns and Pattern Categories
Architectural patterns: Relates to large-scale design and typically applied during the early iterations (in elaboration phase).
Design patterns: Relates to small and medium-scale design of objects and frameworks.
Idioms: Relates to language or implementation-oriented low-level design solutions.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

44. Architectural Pattern: Layers
A layer is a coarse grained grouping of classes packages or subsystems that has cohesive responsibility for a major aspect of the system.
Higher layers call upon the services of lower layers.
Strict layered vs. relaxed layered architectures
Idea behind Layer patterns:
Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities with a clean, cohesive separation of concerns such that the “lower” layers are low-level and general services, and the higher layers are more application specific.
Collaboration and coupling is from higher to lower layers.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

45. Fig 13.3: Alternate UML approaches to show package nesting.
UML Package Diagrams
UML Package Diagrams are often used to show the contents of components, which are often packages in the Java sense.
Each package represents a namespace.
Packages, as components, can be nested inside other packages.
Embedded packages
Fig 13.3: Alternate UML approaches to show package nesting.
Circle cross symbol
UML fully-qualified names
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

46. Terminology: Tier, Layers, and Partitions
Tier relates to physical processing node or clusters of node, such as “client tier”.
Layers of an architecture represent the vertical slices.
Partitions represents a horizontal division of relatively parallel subsystems of a layer.
Fig 13.6: Layers and partitions.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

47. The Model-View Separation Principle
The principle states that
model (domain) objects should not have direct knowledge of view (presentation) objects.
the domain classes should encapsulate the information and behavior related to application logic.
Why?
To support cohesive model definitions that focus on the domain process, rather than on interfaces.
To allow separate development of the model and user interface layers.
To minimize the impact of requirements changes in the interface upon the domain layer.
To allow new views to be easily connected to an existing domain layer, without affecting the domain layer.
To allow multiple simultaneous views on the same model object.
To allow execution of the model layer independent of the user interface layer.
To allow easy porting of the model layer to another user interface framework.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

48. Information Systems
In IS layered architecture was known as three-tier architecture.
A three-tier architecture has interface, application logic and a storage.
The singular quality of 3-tier architecture is:
Separation of the application logic into distinct logical middle tier of software.
The interface tier is relatively free of application processing.
The middle tier communicates with the back-end storage layer.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

49. Example:
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

50. Fig 13.4: Common layers in an information system logical architecture.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

51. Fig 13.7: Mixing views of the architecture.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

52. Domain Layer and Domain Model
These are not the same thing. Domain model shows the real world, while the Domain layer shows the software architecture.
But the Domain model inspires the Domain layer, and is the source of many of the concept, especially class names.
We could create one class and put all logic in it, but that violates the whole spirit of object orientation.
Do not confuse the problem with the solution.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005

53. Fig 13.5: Domain layer and domain model relationship.
Dr. Kivanc Dincer
CS319 Week 5 - Oct.10,2005