Transcript Chapter 11

The Object-Oriented
Approach to Design:
Use Case Realization
Overview
• Primary focus of this chapter and the next is how
to develop detailed object-oriented design models
• Programmers use models to code the system
• Two most important models are design class
diagrams and interaction diagrams (sequence
diagrams and collaboration diagrams)
• Class diagrams are developed for domain, view,
and data access layers
• Interaction diagrams extend system sequence
diagrams
2
Object-Oriented Design – The Bridge
Between Analysis and Programming
• Bridge between user’s requirements and new
system’s programming
• Object-oriented design is process by which
detailed object-oriented models are built
• Programmers use design to write code and test
new system
• User-interface, network, controls, security, and
database requires design tasks and models
3
Overview of Object-Oriented Programs
• Set of objects that cooperate to accomplish result
• Object contains program logic and necessary
attributes in a single unit
• Objects send each other messages and
collaborate to support functions of main program
• OO system designer provides detail for
programmers
– Design class diagrams, interaction diagrams, (some)
statechart diagrams
4
Object-Oriented Event-Driven Program
Flow
5
Simplified Design Class for Student
Class
6
Object-Oriented Design
Processes and Models
• Diagrams developed during analysis
– Use case diagrams, use case descriptions and activity
diagrams, domain model class diagrams, and system
sequence diagrams
• Diagrams developed during design
– Design class diagrams – set of object-oriented classes
needed for programming, navigation between classes,
attribute names and properties and method names
and properties
– Interaction diagrams, package diagrams
7
Design Models with Their
Respective Input Models
8
Iterative Process of OO Design
• Create preliminary design class diagrams model
• Develop interaction diagrams for each use case
or scenario (realization of use cases)
• Return to design class diagram
– Develop method names based design of interaction
diagrams
– Update navigation visibility and attributes
• Partition design class diagram into related
functions using package diagrams (subsystems
or layers)
9
Design Classes and
Design Class Diagrams
• Design class diagrams and detailed interaction
diagrams
– Use each other as inputs and developed in parallel
• Design class diagram first-cut is from domain
model and engineering design principles
• Preliminary design class diagram used to develop
interaction diagrams
• Design decisions are made during development
of interaction diagrams
– Design class diagram is refined
10
Design Classes and
Design Class Diagrams (continued)
• Design class diagram extends domain model
class diagram developed during OO analysis
• Shows set of problem domain classes and their
association relationships
• Describes design components within the classes
• When developers build design class diagrams,
more classes are added
11
Design Class Symbols
• UML does not distinguish between design class
notation and domain model notation
• Domain modeling shows users’ work environment
• Design class design specifically defines software
classes
• UML uses stereotype notation to categorize a
model element by its characteristics
12
Standard Stereotypes Found
in Design Models
13
Standard Design Classes
• Entity – design identifier for problem domain class
– Persistent class – exists after system is shut down
• Boundary – designed to live on system’s
automation boundary
– User interface and windows classes
• Control – mediates between boundary and entity
classes, between the view layer and domain layer
• Data access – retrieve from and send data to
database
14
Design Class Notation
• Name – class name and stereotype information
• Attributes – visibility (private or public), attribute
name, type-expression, initial-value, property
• Method signature – information needed to invoke
(or call) the method
– Method visibility, method name, type-expression
(return parameter), method parameter list (incoming
arguments)
– Overloaded method – method with same name but two
or more different parameter lists
15
Internal Symbols Used to
Define a Design Class
16
Student Class Examples for the Domain
Diagram and the Design Class Diagram
17
Some Fundamental Design Principles
• Encapsulation – each object is self-contained unit
that includes data and methods that access data
• Object reuse – designers often reuse same
classes for windows components
• Information hiding – data associated with object is
not visible to outside world
• Navigation visibility – object is able to view and
interact with another object
18
Navigation Visibility Between
Customer and Order
19
Coupling and Cohesion
• Coupling – qualitative measure of how closely
classes in a design class diagram are linked
– Number of navigation arrows on design class diagram
– Low: system is easier to understand and maintain
• Cohesion – qualitative measure of consistency of
functions within a single class
– Separation of responsibility – divide low cohesive class
into several highly cohesive classes
20
Developing the First-Cut
Design Class Diagram
• Extend domain model class diagram:
– Elaborate attributes with type and initial value
information
– Add navigation visibility arrows
• Detailed design proceeds, use case by use case:
– Interaction diagrams implement navigation
– Navigation arrows are updated to be consistent
– Method signatures are added to each class
21
RMO Domain Model Class Diagram
22
First-cut RMO Design Class Diagram
23
Interaction Diagrams – Realizing Use
Case and Defining Methods
• Realization of use case done through interaction
diagram development
• Determine what objects collaborate by sending
messages to each other to carry out use case
• Sequence diagrams and collaboration diagrams
represent results of design decision
– Use well-established design principles such as
coupling, cohesion, separation of responsibilities
24
Partial Design Class Diagram for the
Look Up Item Availability Use Case
25
Object Responsibility
• Objects responsible for system processing
• Knowing about object’s own data and other
classes with which it collaborates to carry out use
cases
• Doing activities to assist in execution of use case
– Receive and process messages
– Instantiate, or create, new objects required to
complete use case
• CRC cards – class-responsibility-collaboration
26
A CRC Card
27
Back of CRC Card
28
Use Case Controller
• System sequence diagram (SSD) shows input
messages from external actors within use case
• Only indicates that messages go to system
• Use case controller classes are designed as
collection point for incoming messages
• Artifact – class invented to handle needed system
function
• Use case controller acts as intermediary between
outside world and internal system
29
Designing with Sequence
Diagrams
• Sequence diagrams used to explain object
interactions and document design decisions
• Documents inputs to and outputs from system for
single use case or scenario
• Captures interactions between system and
external world as represented by actors
• Inputs are messages from actor to system
• Outputs are return messages showing data
30
SSD for the Look Up Item Availability
Use Case
31
First-Cut Sequence Diagram
• Start with elements from SSD
• Replace :System object with use case controller
• Add other objects to be included in use case
– Select input message from the use case
– Add all objects that must collaborate
• Determine other messages to be sent
– Which object is source and destination of each
message?
32
Objects included in Look Up Item
Availability
33
First-Cut Sequence Diagram for the
Look Up Item Availability Use Case
34
Guidelines for Preliminary Sequence
Diagram Development
• Take each input message and determine internal
messages that result from that input
– For that message, determine its objective
– Needed information, class destination, class source,
and objects created as a result
• Identify complete set of classes affected by each
input message
– Select objects from domain class diagram
• Flesh out components for each message
35
Developing a Multilayer Design for
Look up item availability
• First-cut sequence diagram – classes in domain
layer
• Add design for user-interface classes – view layer
– Forms added as windows classes to sequence
diagram
• Add design for data access classes – data
access layer with separate classes for database
• Tools build GUI and problem domain classes
– Java and Visual Studio.NET
36
Look Up Item Availability Use Case with
View Layer and User-Interface Object
Class for input message
37
Partial Three-Layer Design for
Look Up Item Availability
Class for data access
38
Developing a First-Cut Sequence
Diagram for RMO Telephone Order
• Design for each input message in the SSD
• Design components for all messages are
combined to provide comprehensive sequence
diagram for entire use case
• Information from SSD and first-cut design class
diagram used to develop sequence diagram
• Which object is source and which object is
destination?
• Navigation visibility – destination object must be
visible to source object
39
Completed Three-Layer Design for
Look Up Item Availability
40
SSD for the Telephone Order Scenario
of the Create New Order Use Case
41
Partial Sequence Diagram for the
Telephone Order Scenario
42
Another Partial Sequence Diagram
for the Telephone Order Scenario
43
Sequence Diagram for Telephone Order
Scenario of Create New Order Use Case
44
Developing a Multilayer Design for
the Telephone Order Scenario
• To reduce complexity of diagrams, extend use
case scenario one message at a time
– Add user interface view layer to scenario
– Add single data access class
– Add each message to extend design
• Sequence diagrams can become complicated
• Completed design provides foundation for
programming the use case
45
Telephone Order Sequence Diagram
for the startOrder Message
46
Telephone Order Sequence Diagram
for the addItem Message
47
Telephone Order Sequence Diagram
for the final messages
48
Designing with Collaboration
Diagrams
• Collaboration diagrams and sequence diagrams
– Both are interaction diagrams
– Both capture same information
– Process of designing is same for both
• Model used is designer’s personal preference
– Sequence diagram – because use case descriptions
and dialog follow sequence of steps
– Collaboration diagram – emphasizes coupling
49
The Symbols of a Collaboration
Diagram
50
A Collaboration Diagram for
Look Up Item Availability
51
A Collaboration Diagram for
Create New Order
52
Look Up Item Availability Use Case
Using Iconic Symbols
53
Updating the Design Class Diagram
• Design class diagrams developed for each layer
– New classes for view layer and data access layer
– New classes for domain layer use case controllers
• Sequence diagram’s messages used to add
methods
– Constructor methods,
– Data get and set method
– Use case specific methods
54
Design Class, with Method Signatures,
for the Order Class
55
Updated Design Class Diagram
for the Domain Layer
56
Package Diagrams – Structuring
the Major Components
• High-level diagram in UML to associate classes
of related groups
• Identifies major components of a system and
dependencies
• Determines final program partitions for each layer
– View, domain, data access
• Can divide system into subsystem and show
nesting within packages
57
Partial Design of a Three-Layer
Package Diagram for RMO
58
RMO Subsystem Packages
59
Implementation Issues for ThreeLayer Design
• Construct system with programming
– Java or VB.NET
– IDE tools (JBuilder, Visual Studio) provides help
• Integration with user-interface design, database
design, and network design
• Use object responsibility to define program
responsibilities for each layer
– (View, domain, data access)
60
Summary
• Object-oriented design is the bridge between user
requirements (in analysis models) and final
system (constructed in programming language)
• Systems design is driven by use cases, design
class diagrams, and sequence diagrams
– Domain class diagrams are transformed into design
class diagrams
– Sequence diagrams are extensions of system
sequence diagrams
61
Summary (continued)
• Object-oriented design principles must be applied
– Encapsulation – data fields are placed in classes along
with methods to process that data
– Coupling – connectivity between classes
– Cohesion – nature of an individual class
– Navigation – access classes have to other classes
– Object responsibilities – which messages are sent and
received
• Three-layer design is used because maintainable
62