Object Oriented Analysis and Design - Lecture 5

1
Chapter 10Drawing 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

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.
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.

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.

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.

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

7
SSDSystem 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.

8
Notation

• 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
9
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)
10
Fig 10.2 SSD forA Process SaleScenario.
Note the events generated by cashier (actor)
below.
What SSD info must be put into Glossary?
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.

12
Fig 10.3 SSDs are derived from use cases they
show one scenario.
13
Fig 10.4 Choose eventand 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.
14
Fig 10.5 SSD for a Play Monopoly Game scenario.
15
Chapter 11Operation Contracts

• When ideas fail, words come in very handy. -
  Johann Wolfgang von Goethe

• Objectives
• Define system operations.
• Create contracts for system operations.

16
Fig 11.1 Sample UP artifact influence.
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.
18
Fig 13.8 System operations in the SSDs and in
terms of layers.
19
System Operations andthe 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.

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.

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)

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.

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.

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.

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.

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 its 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).

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

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.
• Dont forget to include all the associations
  formed and broken.

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.

30
Operation ContractsWithin 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.

31
Chapter 12Requirements 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.

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.

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.

34
Didnt 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.

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.

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

37
Chapter 13Logical Architecture and UML Package
Diagrams

• 0x2B 0x2B. - Hamlet

• Objectives
• Introduce a logical architecture using layers.
• Illustrate the logical architecture using UML
  package diagrams.

38
Fig 13.1 Sample UP artifact influence.
39
Example
Fig 13.2 Layers shown with UML package diagram
notation.
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.

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.

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.

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-orie
  nted low-level design solutions.

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.

45
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.

Fig 13.3 Alternate UML approaches to show
package nesting.
Embedded packages
Circle cross symbol
UML fully-qualified names
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.
47
The Model-View SeparationPrinciple

• 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.

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.

49
Example
50
Fig 13.4 Common layers in an information system
logical architecture.
51
Fig 13.7 Mixing views of the architecture.
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.

53
Fig 13.5 Domain layer and domain model
relationship.