OOAD Session 9

Object Oriented Analysis and
Design using UML

Session 9
By Dr. K. Satyanarayan Reddy
So far
4 July 2014
2
BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy
Requirements are capabilities and conditions
to which the systemand more broadly, the
projectmust conform
The UP promotes a set of best practices, one
of which is manage requirements.
In the context of inevitably changing and unclear
stakeholder's wishes"a systematic approach to
finding, documenting, organizing, and tracking the
changing requirements of a system
Evolutionary Requirements
4 July 2014
3
Types of Requirements
In the UP, requirements are categorized
according to the FURPS+ model:
Functionalfeatures, capabilities, security.
Usabilityhuman factors, help,
documentation.
Reliabilityfrequency of failure,
recoverability, predictability.
Performanceresponse times, throughput,
accuracy, availability, resource usage.
Supportabilityadaptability,
maintainability, internationalization,
configurability.
4 July 2014
4
Types of Requirements
The "+" in FURPS+ indicates ancillary and
sub-factors, such as:
Implementationresource limitations,
languages and tools, hardware, ...
Interfaceconstraints imposed by
interfacing with external systems.
Operationssystem management in its
operational setting.
PackagingFor example, a physical box
Legallicensing and so forth.
4 July 2014
5
Requirements Artifacts Organization
Vision Short document for describing or learning
the project's big ideas
Glossary noteworthy terms used in the project
Supplementary Specification Basically, all
nonfunctional requirements such as reports,
documentation, supportability, licensing, and so
forth.
UseCase Model A set of typical scenarios of
using the system (functional requirements)
Business Rules requirements or policies that
transcend the software project (ex. govern. tax
laws)
4 July 2014
6
Not All the Requirements at Once
In Iterative Development We Do Not
Implement All the Requirements at
Once.
4 July 2014
7
Use Cases
An actor is something with behaviour, such
as:
a person (identified by role) - cashier
computer system
Organization
A scenario is a specific sequence of actions
and interactions between actors and the
system under discussion; it is also called a
use case instance.
A Use Case is a collection of related success
and failure scenarios that describe actors
using a system to support a goal.
4 July 2014
8
Not exactly requirements
specification but useful for a better
understanding of system
requirements.
The use-case model describes the
uses of the system and shows the
courses of events that can be
performed.
Can be at different levels of detail
Use Cases
4 July 2014
9
Use case describe the sequence of
events in using the system.
Systematically identify uses of the
system and therefore the system's
responsibilities.
Use cases illustrate and imply
requirements in the stories that they
narrate.
Use Cases
4 July 2014
10
Use Case Formality Types
In addition to the black-box versus white-box
visibility type, use cases are written in varying
degrees of formality:
Briefterse one-paragraph summary, usually of
the main success scenario.
The prior Process Sale example was brief.
Casualinformal paragraph format. Multiple
paragraphs that cover various scenarios.
The prior Handle Returns example was casual.
Fully Dressedthe most elaborate. All steps and
variations are written in detail, and there are
supporting sections, such as preconditions and
success guarantees.
4 July 2014
11
Use Case Diagrams
4 July 2014
12
Most important and classic model in OO analysis
Domain Model illustrates meaningful concepts in a
problem domain
Representation of real world things, not software
components
Set of static structure diagrams; no operations are
defined.
It shows:
concepts (conceptual classes)
associations between concepts
attributes of concepts
Domain Model: What is it?
4 July 2014
13
Domain Model: Example
4 July 2014
14
Domain versus Design Model
4 July 2014
15
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.
4 July 2014
16
System Sequence Diagrams(2)
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.
4 July 2014
17
System Sequence Diagrams(3)
The operations of the system in
response to the events generated.
System Sequence Diagrams depict
the temporal order of the events.
System Sequence Diagrams
should be done for the main
success scenario of the use-case,
and frequent and alternative
scenarios.
4 July 2014
18
SSDs are derived from use cases.
4 July 2014
19
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.
4 July 2014
20
Example Contract : 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)
Contract CO2: enterItem
4 July 2014
21
Contract Sections
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.
4 July 2014
22
Unified Process Artifacts
Business Model
Requirements
Design
Domain Model
Use Case Model
Operation Contract
Use Case Text
System Sequence
Diagrams
Interaction Diagrams
Supplementary
Specifications
Vision
Glossary
See Figure 11.1 in text for more detail
4 July 2014
23
Requirements To Design -
Iteratively
Objectives
Motivate the transition to design
activities.
Contrast the importance of object
design skill versus UML notation
knowledge.
4 July 2014
25
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.
4 July 2014
26
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.
4 July 2014
27
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.
4 July 2014
28
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
diagram can be drawn.
4 July 2014
29
On to Object Design
In practice, the creation of
interaction and class diagram
happens in parallel and
synergistically, but their
introduction is linear in this case
study for simplicity and clarity.
4 July 2014
30
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
4 July 2014
31
Logical Architecture and
UML Package Diagrams
Applying UML and Patterns
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.
4 July 2014
33
Definition Variance
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.
4 July 2014
34
Definitions
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:
It is the resolution of these requirements in
the design of software.
4 July 2014
35
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.
4 July 2014
36
What is a Layer?
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.
4 July 2014
37
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.
4 July 2014
38
Architectural Pattern:Layers
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.
4 July 2014
39
Inter-Layer and Inter-Package Coupling
It is informative to include a
diagram in the logical view
that shows the coupling
between the layers and
packages.
Following figure shows the
coupling.
4 July 2014
40
Partial Coupling Between Packages
4 July 2014
41
Inter-Layer and Inter-Package Interaction
Emphasizes the dynamics of
how objects across the layers
connect and communicate.
The interaction diagram
focuses on the logical view and
on the collaborations between
the layers and package
boundaries.
4 July 2014
42
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.
4 July 2014
43
Package Diagram
UI Domain
Swing Web Sales
4 July 2014
44
Logical vs. Process and Deployment of
Architecture
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.
4 July 2014
45
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.
4 July 2014
46
Layers and Partitions
4 July 2014
47
How do we design application logic with
objects?
We could create one class and put all
logic in it, but that violates the whole
spirit of object orientation.
We create software objects with names
drawn from the real world, and assign
application logic responsibilities to them.
It takes a lot of skill and experience to do
a good job of choosing objects and
assigning responsibilities.
4 July 2014
48
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.
Do not confuse the problem with the
solution.
4 July 2014
49
Information Systems (IS)
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.
4 July 2014
50
Information Systems(cont..)
The middle tier
communicates with the
back-end storage layer.
The following is an
example of 3-tier
architecture.
4 July 2014
51
Example:
4 July 2014
52
Two-tier Design
In this design, the application
logic is placed within window
definitions, which read and
writes directly to database.
There is no middle tier that
separates out the application
logic.
4 July 2014
53
The Model-View Separation Principle
The principle states that
model(domain) objects should not
have direct knowledge of
view(presentation) objects.
Furthermore, the domain classes
should encapsulate the information
and behavior related to application
logic.
4 July 2014
54
Need for Model-View Separation
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.
4 July 2014
55
Continued..
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.
4 July 2014
56
THANK YOU
4 July 2014 BITS-WASE: OOAD Session 9 by Dr. K. Satyanarayan Reddy
57

OOAD Session 9

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

OOAD Session 9

Încărcat de

Drepturi de autor:

Formate disponibile

Object Oriented Analysis and

Design using UML

S-ar putea să vă placă și