# Object Oriented Analysis and Design - Lecture 5 - PowerPoint PPT Presentation

PPT – Object Oriented Analysis and Design - Lecture 5 PowerPoint presentation | free to download - id: 64e925-ODQzO

The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
Title:

## Object Oriented Analysis and Design - Lecture 5

Description:

### Title: Object Oriented Analysis and Design - Lecture 5 Author: KIVANCD Description: RLSD 51011 KD Last modified by: KIVANCD Created Date: 9/12/2005 3:51:44 AM – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 54
Provided by: KIVA9
Category:
Tags:
Transcript and Presenter's Notes

Title: Object Oriented Analysis and Design - Lecture 5

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

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 for A Process Sale Scenario.
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 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.
14
Fig 10.5 SSD for a Play Monopoly Game scenario.
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.

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

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

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.

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

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

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.