OOM Module 4

Objectives
 The Primary focus of this chapter is on how to develop detailed Object-

oriented Design Models, which programmers then use to code the System.
 The two most important Models that must be developed are: -

- Design Class Diagrams
- Interaction Diagrams (Sequence Diagrams ,
Communication Diagrams)
 Develop Class Diagrams for each of the “Three Layer Design”

- View Layer,
- Domain Layer
- Data Access Layer.
 Design Class Diagrams extends the Domain Class Diagram Model that was
developed during Requirements Activities.
Object-Oriented Analysis and Design and the Unified Process 2

Objectives (continued)
 Interaction Diagrams
 Extend System Sequence Diagrams
 Develop detailed Sequence Diagrams as the core process in

systems design
 Develop Communication Diagrams as part of Systems Design
 Document the Architecture Design using Package Diagrams

 Package Diagrams
 Show relationships and dependencies among Classes

What is Object-Oriented Design?
 Object-Oriented Design is the process by which a set of detailed
Design Models is built which the Programmer will later use to
write Program codes and test the System.
 System Design is A ‘Bridge’ between a User’s Requirements and
Programming for the new System.
 A Systems Developer would never try to develop a large System
without a set of Design Models.
 An Adaptive approach to development including (UP) necessitates
 Requirements and design are done incrementally within an iteration
 A complete set of Designs Models may not be developed at one time.
◘ The Requirements for a particular Use Case may be developed and then Design
Documents developed for the Use Case.
◘ Immediately following the Design of the solution, the Programming can be done.
Usually there is no need to generate a formal set of Documents since their
purpose is simply to direct Programming.

Overview of Object-Oriented Programs
 Object-oriented Programs consist of a set of ‘Computing Objects’ that cooperate to
accomplish a result.
 Each Object has Program Logic and Data encapsulated within it;
 Each Object works by sending each other Messages to collaborate to support the
functions at the main Program.
 Most Object-oriented Programs are ‘Event-driven’ . Program execution is initiated by an

Actor waiting to carry out a Use Case that is Business event.
 A Use Case is executed by a set of collaborating and interacting Objects.
 An Object-Oriented System consists of a set of Computing Objects. Each Object has
Program Logic and Data encapsulated within it. Analyst define the structure of the
Program Logic and Data fields by a Class.
 Class Definition describe the structure or template of what an ‘Executing Object’ looks
like.
 The Executing Object itself does not come into existence until the Program begins to
execute. This is called ‘Instantiation of a Class’ or making an instance (Object) based
on the template provided by the Class Definition.

Object-Oriented Event-Driven Program flow
Object-Oriented Design Models
 The Objective of O-O Design is to Identify all Objects that must work together to carry out a
Use Case.
 Additional Objects to perform specific services such as Logon and Authentication may
also be required.
 Divide Objects into different groups for that purpose is called ‘Multilayer Design’.
◘ Object groups:- User Interface Objects
Problem Domain Objects
Database Objects
 The most important diagrams in Design is a ‘System Sequence Diagram’ - or its first cousin
a Communication Diagrams. These diagrams describe the ‘Messages’ that are sent between
Objects.
 Analyst extends the System Sequence Diagram by modifying the single :System Object to
include all of the interacting ‘User-Interface’, ‘Problem Domain’ and ‘Database Access’
Objects.
 The other major Design Model is ‘Design Class Diagram’. The purpose is to document and
describe the ‘Programming Classes’ that will be built for the new System.
 Design Class Diagrams are the end result of the Design process. They describe the set of
Classes needed for Programming Navigation between Classes, Attribute Names and
Properties.
Thus, Design Class Diagram is a summary of he final Design that was developed using
the Detailed Sequence Diagrams.

Design Class for Student Class
Design Analysis
Object-Oriented Class Diagrams
and Design anddocument and describe
the Unified Process the Programming Classes
8
 As a Designer you will need to provide
enough detail so that a Programmer can
write initial Class Definition and then add
considerable detail to the Code.
e.g. A Design Class Specification
helps define the ‘Attributes’ and the
‘Methods’.
A Class Definition example of a JAVA

Programming Language
Notice that the Class Name ,the Attributes and

the Method Names are derived from the
Design Class Notation.

 Another important Design Model we use in design is
Detailed Statechart Diagram.
 Statechart Diagram is useful to describes the Life Cycle of
an Object. It captures information about the valid ‘States’
and ‘Transitions’ of an Object.
 Statecart Diagrams are an effective tool, but in Designing
Business Systems, they are only used for special
situations.
 A final model that is used to document Subsystems is
called ‘Package Diagram’. It denotes which Classes work
together as a Subsystem.
Design Models with their respective Input Models
Object-Oriented Design Process
 Object-oriented Design is Use Case Driven meaning that we develop a Design
with a Sequence Diagram Use Case by Use Case one at a time.
 The Process of Designing requires several steps or iterations.

◘ First step is to create a preliminary version or ‘First-cut Model of the
‘Design Class Diagram’.
◘ The second step in designing is to develop Iteration Diagram resulting in

Detailed Sequence Diagram for each Use Case or Scenario.
– Designing a Sequence Diagram is the heart of Object-Oriented Systems Design.
◘ The third step is to return the Design Class Diagram and develop Method
Names, Attributes, and Navigation Visibility based on information developed
during the Design of the Iteration Diagrams.
◘ Final Step is to partition the Design Class Diagram into related functions
using Package Diagrams
– Package Diagram provides an Architectural High-level view of the final System.

Design Classes and Design Class Diagrams
 First iteration of Design Class Diagram is extensions of Domain Class Model
Diagrams:
– Elaborate on Attribute details
– Define Parameters and Return Values of Methods
– Define the internal Logic of Methods
 A first-cut Design Class Diagram is based on the Domain Model and engineering
Design principles
 The Preliminary Design Class Diagram is then used to help develop Interaction
Diagrams.
 As Design decisions are made during development of the Interaction Diagrams,
the results are used to refine the Design Class Diagram
 Analyst must specify:
◘ The Class Attributes by its ‘Type’ such as character, numeric etc., |
◘ Methods with Parameters and Returns ?Values that are passed as well as
Visibility of Attributes and Methods.
 Design Class Diagram is more detailed version of the Domain Model Class
Diagram. We complete the Design Class Diagram by integrating information
from Interaction Diagrams and other Models.
Design Class Symbols
 Since many different types of Design Classes will be identified during the
Design Process UML has a special notation called ‘Stereotype’ that allows
Designer to designate a special type of Class
 Stereotype is simply way to categorize a model element as a certain type
 Two types of Stereotype Notation

◘ Full Notation with guillemets («»)
◘ Shorthand Notation with ‘Circular Icons’
 Four types of Design Class are considered to be Standard :-

◘ Entity Class,
◘ Control Class,
◘ Boundary Class,
◘ Data Access Class.

Standard Stereotypes found in Design Models
Design Class Symbols
 An Entity Class comes from Domain Class, (it is the Design
Identifier for a Problem Domain Class). These Classes are normally
passive in that they wait for some Business Events to occur before
they do anything. They are also ‘Persistent Classes’
– Persistent Class is one that exists after the program quits (i.e. System is
shut down.)
 A Boundary Class is specifically designed to live on the System’s
Automation Boundary. i.e. Windows Classes and all other Classes
associated with the User Interface in a Desktop based System..
 A Control Class mediates between the Boundary Classes and the
Entity Classes. (It catches the messages from the Boundary Class
Objects and send them to the correct Entity Class Objects.)
 Control Class acts as a Switchboard between the ‘View Layer’
and ‘Domain Layer’.
 A Data Access Class is used to access Database to retrieve data
from and send data to a Database.
 (i.e. A separate Layer of Classes to access the Database is
included in the Design rather than inserting SQL Statements into
the Entity Class Methods )
Internal Symbols used to define a Design Class
Design Class Notation
 The First compartment shows the Class Name and Stereotype information.
 The second compartment contains more detail about the Attributes such as
Visibility, Type-expression, Name, Initial value, and Properties.
◘ ‘Attribute Visibility’ denotes whether other Objects can directly
access the Attribute.
– Visibility (+) sign indicates Public and Visibility (-) indicates a Private
Visibility .
◘ Attribute Name and Type expression indicate name of the Attributes
and whether it is ‘Character, ‘String’, ‘Integer, number, Date,
cufrrency etc….
◘ Initial Value (Default Value or specific starting Value)
◘ Properties are placed within curly brackets { }.
 The third compartment contains more details about the Method Signature
information (i.e. Information needed to call the Method
◘ Method Visibility, ( +) Public and (-) Private Method.
◘ Method Name,
◘ Type-expression – (The Type of the Return Parameters from the Method)
◘ Method Parameter List – (Incoming Arguments)
Student Class examples for the Domain Diagram and the Design Class Diagram
Design Class Notation
• In
 O-O Programming Analyst use the entire Message SIGNATURE to identify a Method to
|
distinguish between Overloaded Methods .
• However some O-O Programming Languages allow multiple Methods to have

the same Method Name as long as they have different ‘Parameter List’ or Return-Type.
• An Overloaded Method – is a Method that occurs more than once with the same Name
but with two or more different Parameter lists.
•Constructor Method is the Method that makes or creates new Objects for the Class.
(e.g. Constructor such as createStudent (name, address, major):Student
- In many Programming languages the Constructor Method is given the same name as the
Class Name.
- We use a Create Statement to follow more closely the Message Names used in
Interactions Diagram (i.e Sequence Diagram and Collaboration Diagram).
• Class-Level Method is a Method that is associated with a Class instead of with Objects of
the Class. Class Level Method is Underlined.
(e.g. +findAboveHours(int hours):StudentArray
• In JAVA environment Class Level Method is called a ‘Static Method’ and in

(.NET)
Object-Oriented Environment
Analysis and Designitand
is called a ‘Shared
the Unified Process Method’. 20
Some Fundamental Design Principles
 Encapsulation - Is a Design principle that each Object is a self-contained
unit containing both Data and program Logic
 Programmers depend heavily on the benefits of Encapsulation to support the idea

of ‘Object reuse’
 Object Reuse - A design Principle in which a set of standard Objects can be

used over and over again within a System. (e.g. one frequent application of Object
Reuse is the design of the User Interface either for desktop of Web Applications.
 Information Hiding – Is a Design Principle in which Data associated with an

Object are no visible to the outside world, but methods are provided to access or
change the Data.
◘ This principle is primarily a Programming concept, several important principles are

based on it.
 Navigation visibility – Interactions between Objects can only be
accomplished with Navigation Visibility.
 Designer has to ddescribe which Objects can interact with each other (Ability of one
Object to view and interact with another Object)
 Navigation Visibility can be either one way or two ways. (e.g A Customer Object may
able to view an Order Object.
 That means the Customer Object may be able to view an Order Object. In
Programming terms the Customer Class has a Variable or Reference Variable
(such as ‘myOrder’ variable) holds a value to refer to an Order instance.
 Coupling - Measures how closely Classes in a Design Class Diagram are
linked.
 Coupling is derived from Navigation Visibility.
 Designer must develop a feel for Coupling - to recognize when there is too much
Coupling or to know when it is reasonable amount of Coupling.
 Coupling is evaluated as a Design processes Use Case by Use Case. Generally if each
Use Case Design has a reasonable level of Coupling the entire System will, too .
 High Coupling is primarily bad because it adds unnecessary Complication to a
System making it very hard to maintain . A change in one Class ripples
throughout the entire system
◘ Coupling
Object-Oriented Analysis and can beand
Design simplified
the Unified to reduce “Ripple Effects” on the System.
Process 22
Customer and Order - coupling
 Cohesion – Measures the consistency of functions within a Single
Class. It focuses on a single Class.
 Classes can have Very low, low, medium and high Cohesion. Classes with High level of
Cohesion are most Desirable.
An example of a Medium Cohesion would be a Class that has closely related responsibilities , such as
“Maintain Customer Information’ and another task of “Maintaining Customer Account
Information”.
Two Highly Cohesive Class could be defined one Class to Maintain Customer Information and the
other class for Customer Account Maintenance.
Classes with Low Cohesion have several negative effects
1. Hard to maintain since they do many different functions and tend to be over sensitive to changes
within the system, suffering from ripple effect
2. Hard to be reused since they have many unrelated functions; thus does not make sense to re-use
them.
3. It is difficult to understand the Class since their functions are intertwined and their logic is complex.
 The common solution to Classes with Low Cohesion is to divide a Class into several
highly Cohesive Classes, This Design concept is called “Separation of Class
Responsibilities”.
Developing the First-Cut Design Class Diagram
The ‘First-Cut Design Diagram” is developed by extending the Domain Model
Class Diagram in two steps:-
1. Elaborate the Attributes with Type and Initial Value information

- Attribute Types information is based on Designer’s expertise
- In most instances all Attributes Visibility is kept Private unless stated.
2. Adding Navigation Visibility Arrow

Based on which Classes need access to which other Classes:
Some Navigation Visibility Guidelines
- Navigation from Superior to /Subordinate (1: M relationship)

- Navigation from Independent Class to Dependant Class (Mandatory relaxations)
- Object requiring info from other Object Points to Object or its Parent
- Navigation Arrows may also be bidirectional.

Developing the First-Cut Design Class Diagram
Despite the Navigation Visibility Guidelines, the best way to
implement Navigation between Classes may not be clear. Therefore we
may need to wait until additional Design is done and other Design
Principles can be applied.
The important points to note with regards to Navigation Visibility
as Design proceeds are:-:-
1. We will need to be updated as design progresses Use Case by Use Case

to ensure that Interaction Diagrams support and implement Navigation
initially defined
2. Navigation arrows will need to be Updated to be consistent with Design

details
3. Method Signatures will be added to each Class based on Design decisions

when creating Interaction Diagrams for the Use case.

Interaction Diagrams–Realizing Use Cases and Defining Methods
 The Realization of a Use Case- Determine what Objects collaborate by sending messages to
each other to carry out the Use Case- is done through the development of an Interaction
Diagram.
 Developing Interaction Diagrams is at the heart of Object-Oriented design
 Two types of Interaction Diagrams are developed during Design :
◘ Sequence Diagrams
◘ Communication Diagrams
 Design can be done using either Sequence Diagram or Communication Diagram .This is a matter of
a Designer’s preference.
----------------------------------------------------------------------------------------------
 It is important to note that The Interaction Diagrams like Design Class
Diagram, developed while Software Design, are not end in themselves.
Instead they represent the result of Design Decisions based on well
established Design Principles such as ‘Coupling’, ‘Cohesion’ and
‘Separation of Responsibilities’.
 These Diagrams may be modified several times as Designers refine them to

improve their qualities and correct errors.

Object Responsibility
One of the fundamental Principle of Object-Oriented Development is the idea of “Object
Responsibility”.
 Object Responsibility is a Design Principle that indicates which Objects are responsible
for carrying out System Processing
 One of the most important activities of a Designer is to determine Object Responsibility

and build the System based on those decisions.
 The Card Responsibility Collaboration Index Cards (CRC) technique is still used to
assist the Design process
Two MajorAareas of Object Responsibility

What is an Object needs to know ? and What is an Object needs to do or initiate ?
 Knowing
◘ Knowledge about its own Data and about other Classes (have Navigation
Visibility), with which it must collaborate to carry out Use Cases
◘ Doing
– All the activities an Object does to assist in the execution of a Use Case.
(e.g Receive and Process messages, other responsibility will be to instantiate or create new objects that may be required
for completion of a Use Case.

Use Case Controller
To simplify the collection and Processing of all the Messages for a Use Case, Systems Designer frequently
make up a new class (An artificial Class called Artifact) that can serve as a collection point for incoming
messages. This Class is called a “Use Case Controller:
 Use Case Controller Serves as a collection point for incoming messages. It acts
as an Intermediary between the outside world and the internal system
e.g. A single Input Window object (User Interface layer) may need to send messages to several
Objects in Domain Layer. In that circumstance the Coupling between the Input Window
Object and the System would be very high. (as in Fig 8.1) By using a Single Use Case
Controller Object to handle all the Input messages the coupling could be reduced.
There are several ways to create Use Case Controllers:
 A Single Use Case could be defined for all Use Cases within the System. This would
result in Low Cohesiveness, since the set of responsibilities assigned to a single Use
Case Controller would be vary broad.
 A Single Use Case could be defined for all Use Cases in a Subsystem with a set of
responsibilities assigned to it. (remember there could be many Subsystems in a System)
 One Use Case Controller for each Use Case wit a set of specific responsibilities
◘ Creating several Use Cases Controllers would raise the Coupling between
the User Interface Classes and the Internal Classes, but it would result in
highly cohesive Classes with a defined set of responsibilities for each.

Object-Oriented Event-Driven Program flow
Example of a Single Use Case Controller for a single Use Case (Look Up
Object-Oriented Analysis and DesignItem
and theAvailability
Unified Process Use Case) 32
Designing with Sequence Diagrams
 Interaction Diagrams (Sequence Diagram, and Communication Diagram)
form the heart of the Object-Oriented Design process.
 Sequence Diagrams are used to explain Object interactions and document Design
decisions.
 A Systems Sequence Diagram (SSD) captures the interactions between the System
and the External world represented by Actors. The System is treated like a (“Black
box”) i.e. a Single Object.
 The Objective of Designing Detailed Sequence Diagram is to open up the

“Black Box” (The System Object) and determine the Internal Processing that must
occur within the Automated System..
 A Detailed Sequence Diagram uses all of the same elements as an SSD including the
Input Message Syntax:
* [true / false condition] return-value:- message-name (parameter-list)
except that the :System Object is replaced by all of the Internal Objects and
Messages within the System

SSD for the Look Up Item Availability Use Case
First-Cut Sequence Diagram
 Replace the :System Object with a Use Case Controller Object
eg. :Availability Handler) on the Sequence Diagram.
 Determine which other Objects are needed to carry out the Use Case and add
these Objects to Sequence Diagram
The first step is to select an Input Message from the Use Case and add it to
Sequence Diagram
The next step is to Determine which other Messages must be sent, and which
Objects should be the Source and Destination of each Message.
◘ Decision about which Other Messages are required, based on Design

Principles such as Coupling, Cohesion, Object Responsibilities and
Controller.
◘ Message can be directly sent from one Object to other Object providing that
there is a Navigation Visibility. Otherwise, Messages will be sent indirectly
via an Object(s) that has Navigation Visibility to the required Object.

First-Cut Sequence Diagram (Continued)
 The Use Case Controller provides the link between the Internal Objects and the
External Environment . This limits the Coupling to the External Environment to
that single Object
Using a Use Case Controller as the Switchboard limits the overall Coupling
between the Domain Objects and the Environment.
 The :Availability Handler Class also is highly Cohesive with only two primary
Responsibilities. (Receive Incoming messages from the External Environment
and return the System response to the Destination)
 An Object can be “Active” or “Inactive”. (An Active object resides in memory

awaiting further Messages and Values of its Attributes)
 We Use “Activation Lifelines” to indicate when an Object is Executing a

Method.
 Activation Life is represented with narrow vertical rectangles.

First-cut Sequence Diagram for the Look Up Item Availability Use Case
First-Cut Sequence Diagram
Let us explain the First- Sequence Diagram of Look-Up Item Availability
- To make an Item Inquiry Actor sends an Input Message (InquiryOnitem) containing Parameter list of
(CatalogId ProdId and Size)
-The Single Use Case Controller (:AvailabilityHandler) acts like switchboard, forwards the Input Messages to the
relevant Superior Object which has Navigations to Subordinate Objects.
- From the Design Class Diagram determine which other Objects required to process the Look-Up Item Availability Use
Case. :Catalog, :CatalogProduct, :ProductItem, and :InventoryItem.
-- The (:AvailabilityHandler) forwards the Input Message to the :Catalog .Object since the Catalog has a
Superior / subordinate relationship (Navigation Visibility) to :CatalogProduct, and :ProductItem objects to get
Description and the Price.
- :Catalog then forwards the message to :ProductItem to initiate Method getDescription )

to :CatalogProduct to initiate message getPrice( )
- However :Catalog does not have direct Navigation Visibility to :InventoryItem to get “quantity”. So it sends
another Message to ask help from :ProductItem in getting the Quantity from :InventoryItem since it has a direct
Navigation to it.
:Catalog collects all information and returns it to the (:AvailabilityHandler which send it back to the Actor.
- Note: The Activation Lifeline under :AvailabilityHandlerexe is the indication of “+InquiryOnitem “ Method
execution. The Acivation Lifeline under :Catalog Indicates the Execution of “+getDescription” Method and
“getPrice” Method.
Guidelines for First-Cut (Preliminary) Sequence Diagram Development
The following three steps will produce the Preliminary Sequence Diagram. Remember
that refinement and modifications to the Preliminary Sequence Diagram may be
necessary.
1. Take each Input Message and determine all of the Internal Messages that result
from each Input Message.
To define the Internal Messages :-

- Determine the Objectives of each Message.
- Determine What information is needed, Which Classes need it, the Source and Destination .
- Determine what Objects are created as a result of that Input.
- 2. For each Input Message, Identify the complete set of Classes that will be
affected by that Message. Such Classes are those listed in the Use Case
Description either in the Preconditions or Postconditions for a Use Case () .
Also other Classes such as Creators of Objects for the Use Case that are updated
during the Use Case. These Classes should be included in the Design.
3. Flesh out the components for each Message. Add Iteration , True / False
conditions, Return Values and Passed Parameters.
Note :- Passed Parameters should be based on the attributes of the Domain Class Diagram . Return Values
and Passed Parameters can be attributes but they may also be objects from Classes.
Developing a Multilayer Design
 The First-cut Sequence Diagram focuses only on the Class in the Domain Layer.
However, in Systems Design we must also Design the “User Interface Classes”
and the “Data Access Classes”.
 In the early days of Interactive Systems and Graphical User Interface (GUI) Tools,
Software Vendors invented Languages and Tools (early version of VB, Delphi etc) that
made it easy to develop Systems with GUI such as windows and buttons.
 However in these Languages the Program Domain Logic was attached to the
Windows and other Graphical components. So to move these Systems to other
environments such as Browser-based Systems, Designers had to completely rewrite
the System.
 Remember too that when a Class contains both User Interface Function and Business
Logic Function:’ the Class Cohesiveness becomes low!!!.
 As O-O Languages become more prevalent and tools integrated both O-O Programs and
GUI, it becomes easier to build Systems that could be partitioned and that allowed Class
Responsibilities to be separated. Such as the User Interface Classes do not need to have
Business Logic – other than Edits on the Input Data).
 So, Designers Could build Multilayer Systems that were more robust and easier
to maintain and conform with good Design. Tools such as JAVA and Visual Studio (.NET)
provide the capability to easily build GUI as well as sophisticated Problem Domain Classes.
Designing The View layer
 The View Layer involves Human Computer Interaction (HCI) and requires
designing the User Interface for each Use Case.
 The Designer takes the step in a Use Case Description and begins to develop a
Dialog Design for the Use Case , Usually defining one or more Window
Forms or Web Forms that the User will use to interact with the System.
 Once the Electronic Forms are designed an Object-Oriented Window Class can
be defined for each Form
 Each Electronic Input Form is added as Window Class <<boundary>>

on to the Sequence Diagram
 Since the Data are entered by the Actor via keyboard and the User Interface
Window Object catches that information, formats it and transmits the Message
to the Use Case Controller Object, the User Interface Object is placed between
the “Actor” and the “Use Case Controller” Object.
Designing the Data Access Layer
 The Principles of Separation of Responsibilities applies to Data Access Layer

Design as well.
 On Smaller Systems “Two Layer Design’’ exist, in which the SQL Statements to access a Database are
embedded within the Business Logic Layer. This implies that SQL statements are included in Methods of
the Problem Domain Classes.
 On Large and more complex Systems , it makes sense to create Classes whose sole responsibilities is to
execute Database SQL Statements, get the results of query and provide that information to the Domain
Layer.
 Because of a problem between Object-Oriented Programming Languages and Database

Languages (i.e Mismatch between O-O Programming Languages and Database SQL
Statements) , have partially driven the trend to a Multilayer Design.
 Rather than mixing the Business Logic with the Data Access Logic, it is better to define
separate Classes and let each Class to focus on its Primary Responsibility is an
application of Good Design principles of Highly Cohesive Classes with appropriate
Responsibilities.
Notes:- Description of each Domain Object has a prefix of (aX) identifie, where (X) is replaced by
the first character of Class. Eg. aC:Catalog and the Data Access Classes have Suffix of (DA).
e.g. aC:Catalog , aP:Product and :CatalogDA. Etc
The set of ‘’initxxxx’’ messages ( initCatalog , initProduct etc ) can either create a new Object if
necessary or simply verify that existing Objects are in memory.
Completed Three-Layer Design for Look up Item Availability
A First-Cut Sequence Diagram for an RMO Telephone Order
 Define a User Controller Object (:OrderHandler)
 Define a “Create Message’’ for new Order Objects which will create a new Object
within Order.
 When a ‘Create Message’’ is sent to an Object, it is often drawn directly to the Object
box and not to the Lifeline (Optional Diagramming technique).
 Another way is let the Customer Object create the Order Object. Since Order Object
are not allowed unless a Customer Object exist. This is one way to ensure that the
Customer existence Precondition.
◘ Note that a specific Identifier (anOrd) is given to the newly created Order Object
e.g. anOrd:Order,. The (anOrd Identifier is then passed back to the Customer Object,
which in turn passes it back to :OrderHandler
 Define other Internal Messages along with Source and Destination as well as passed
Parameters and Navigation Visibility for each Message.
 addItem (), createOrdItem (), getDescription(), getPrice(), updateQty ()
 Working with Design Models enable the Designer to think through all the requirements to
process a Use Case without having to worry about code.
SSD for the Telephone Order Scenario of the Create new order Use Case
Sequence
Object-OrientedDiagram
Analysis andfor Telephone
Design Order
and the Unified ProcessScenario of Create New Order Use Case
47
Developing a Multilayer Design for the Telephone Order Scenario
 Extend one Message at a time
 View Layer
◘ There is a :MainWindow; with a Menu Item or a Buttonthat

opens :OrderWindow
 Data Layer
◘ Customer Object initializes itself aC:Customer

◘ Add items to an Order with a repeating Message
◘ Save Order and OrderItem to the Database
◘ Update Database inventory
◘ Complete transaction

TIPS FOR SEQUENCE DIAGRAM DESIGN
 When developing a Sequence Diagram it is often necessary to work
on several tasks at the same time . Such tasks are The Database
Design and the User-Interface Prototyping might be ongoing
activities that are concurrent with Detail Design.
 Sequence Diagrams may incorporate the Design element such as

‘’Cover Error Handling’’ or failure in the Use Case.
Despite the fact that the Sequence Diagrams may get somewhat
busy and complicated yet, they provide an excellent foundation for
Programming the Use case.
 Sequence Diagram enables a The Designer to think through the

complexity of each Use Case without programming complications.

DESIGNING WITH COMMUNICATION DIAGRAMS
 Communication Diagrams are Interaction Diagrams like
Sequence Diagrams and they capture same information.
 The choice of using Sequence Diagram or Communication

Diagram is primarily a matter of personal preference.
 Many Designers prefer to develop Sequence Diagram because,

Use Case Descriptions and Dialog Designs follow a Sequence of
Steps.
 Communication Diagram are useful for Showing a different view

of the Use Case that emphasizes Coupling.

Designing with Communication Diagrams
 Communication Diagram Uses the same symbols as a Sequence
diagram for Actors, Objects, and Messages except that the
Lifeline and the Activation Lifeline symbols are not used
 Different Symbols used for Communication Diagram

 Link symbol is used to carry messages between Objects or
between Actors and Objects.
 Numbers on the messages indicate the sequence in which
messages are sent. Hierarchical dot numbering scheme is used
(5. 5.1, 5.2) when messages are dependent on other messages.
 The Message format also differs slightly and each message is
numbered sequentially.
 Message Descriptor Syntax
◘ [true/false condition] Sequence-no : return-value: = message-name (parameter-list)

The symbols of a Communication Diagram
A Communication Diagram for Create new Order
Comparison of Sequence and Communication Diagrams
 Communication Diagram focuses on Object themselves.
 Drawing an Communication Diagram is an effective way to get a
quick overview of the collaborating objects .
 However, You have to hunt to find the numbers to see the
sequence of the Messages.
 Communication Diagrams are used to sketch out a solution.
When to use Sequence Diagram or Communication Diagram

 If the Use Case is small and not too complex a simple
Communication Diagram may suffice.
 For more complex situations, Sequence Diagram may be
required to allow you visualize the flow and Message sequence.
You can mix the usage of both Interaction Diagrams within the same set of specifications.

UPDATING THE DESIGN CLASS DIAGRAM
Design Class Diagram can be developed for each Layer.
- In the View and Data Access Layers, several new Classes must be specified.
- The Domain Layer also has the new Classes added for the Use Case Controller.
AFTER CREATING SEVERAL SEQUENCE DIAGRAMS :
a) Method Information can be added to the Classes
b) Navigation Arrows may also require updating as a result of decisions made
during Sequence Diagram Development
 Update Classes with Method Signatures

 TYPES OF METHODS
- Constructor Methods (creates new instance of the Object)

- Data Get and Set Method (retrieves and updates Attribute value)
- Use Case Specific Methods
Since every Class must have Constructor, Get and Set methods it is optional to include
these in the Design Class.
However the Use Case Specific Methods must be included in the Design Class Diagram

Updating the Design Class Diagram (continued)
• Every Message that appears in the Sequence Diagram requires a
Method in the Destination Object
• The Process of Adding Method Signature is to go through every

Message in a Sequence Diagram and find the Messages sent to that
class. Remember that each ‘Message’ indicates a ‘Method’.
 For Every Class in the Domain Layer including the Use Case
Controller Classes we identify the Messages and ‘Create Methods’.
 The additions to the Domain Layer are:-

◘ The Use Case Handlers;
◘ Additional Navigation Arrows (to document which Classes are visible
from the Controller Class).

PACKAGE DIAGRAMS
Package Diagram is a high level Diagram that allows the Designer to associates
Classes of related groups.
 A Package Diagram can group Classes by Subsystem or by Layer (View Layer,

Domain Layer and Data Access Layer).
 To develop Package Diagram extract information from Updated Design Class Diagram
and Interaction Diagram (Sequence Diagram) for each Use Case.
 Place the Classes inside the appropriate Packages based on the Layer or Subsystem to
which they belong.
 Dependency Relationships (Dashed arrow line ) shows which elements affect

other elements in a System. The arrow tail is connected to the Package that is
dependent. And the arrow head is connected to the independent Package.
 Dependence Relationship may exist between Packages, or between Classes

within Packages

Package Diagrams (Continued)
- Dependency Relationship help designer to track the carry-through effect of
changes.
 Package Diagrams can also be nested to show different level of Packages .
 Package Diagrams helps to document the Sub-systems
 The Benefit of using the Package Diagrams for Documentation is that different
Packages can be assigned to different Programming teams to program the
Classes.
 Dependency arrow will help Designers recognize where communication among
teams must occur to ensure a totally integrated system.

Partial Design for a Three-Layer Package Diagram for RMO
IMPLEMENTATION ISSUES FOR THREE-LAYER DESIGN
 Using Design Class Diagrams, Interaction Diagrams and Package Diagrams,
Programmers can begin to build (Construct) the components of a System by using
Programming languages like Java or VB.Net
 Over the last few years powerful Integrated Development Environment Tools (IDE)
have been developed to help Programmers construct the Systems.
 The IDE tools provide a very high level of Programming support especially in the
construction of the new View Layer Classes ( Windows and Window Components of the
System).
 Some IDE Tools for :-

JAVA (Jbuilder and Eclips )
Visual Basic and C# (Visual Studio)
C++ (C++ Builder)
 Unfortunately some of these IDE Tools propagate some bad Programming habits in
the Developers since they:-
 Contain Database Engines, to allow the building of the entire System with only
one Class.
 Creates Window Classes with Programming Codes automatically inserted in the
Window Class
The Problem with IDE Tool approach is the difficulty of maintaining the System
Codes since they scattered throughout the Graphical Use Interface (GUI)
Classes, that becomes very hard to find and maintain.
-If a Network-based System needs to be enhanced to include Web- front end then a
Programmer must rebuild nearly the entire System.
-If two User Interfaces are desired , then all of the Business Logic is programmed
twice.
However without the IDE tool that generates code, it is almost impossible to keep
the
System current. This problem is exacerbated by new releases of the IDE tools
which
may not be compatible with earlier version. Many Programmers had to rewrite the
Front end of Systems because of new IDE Tool releases
We recommend that the would be Analysts and Programmers should use Good Design
Principles in the Development of new Systems
- For example given the Design Principles of Object Responsibility it is possible to define what
program responsibilities belong to each System Layer.
- If you follow
Object-Oriented these
Analysis andguidelines
Design and in
thewriting Program code, the new System will be much more 65
Unified Process
THE PRIMARY RESPONSIBILITIES OF EACH LAYER
View Layer Classes should have Programming Logic to:-
- Display Electronic Forms and reports

- Capture input (such events as Clicks, rollover, key entry etc)
- Display data fields
- Accept input data
- Edit and validate input data
- Forward input data to Domain Layer Class
- Start up and Shut down the System
Domain Layer Classes should have following Responsibilities
- Create Problem Domain (Persistent) Classes

- Process all Business rules with appropriate logic
- Prepare Persistent Classes for storage to the Database
Data Access Layer Classes should perform the following:

- Establish and maintain connections to the Database
- Contain all SQL statements
- Process result sets (Result of SQL execution) into appropriate Domain objects
- Disconnect gracefully from Database.

OOM Module 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOM Module 4

Uploaded by

Copyright:

Available Formats

Objectives

 The Primary focus of this chapter is on how to develop detailed Object-

 The two most important Models that must be developed are: -

 Develop Class Diagrams for each of the “Three Layer Design”

Object-Oriented Analysis and Design and the Unified Process 2

 Develop detailed Sequence Diagrams as the core process in

 Develop Communication Diagrams as part of Systems Design

 Document the Architecture Design using Package Diagrams

Object-Oriented Analysis and Design and the Unified Process 3

Object-Oriented Analysis and Design and the Unified Process 4

 Most Object-oriented Programs are ‘Event-driven’ . Program execution is initiated by an

Object-Oriented Analysis and Design and the Unified Process 5

Object-Oriented Analysis and Design and the Unified Process 7

A Class Definition example of a JAVA

Notice that the Class Name ,the Attributes and

Object-Oriented Analysis and Design and the Unified Process 9

 The Process of Designing requires several steps or iterations.

◘ The second step in designing is to develop Iteration Diagram resulting in

– Package Diagram provides an Architectural High-level view of the final System.

Object-Oriented Analysis and Design and the Unified Process 12

 Stereotype is simply way to categorize a model element as a certain type

 Two types of Stereotype Notation

 Four types of Design Class are considered to be Standard :-

Object-Oriented Analysis and Design and the Unified Process 14

• However some O-O Programming Languages allow multiple Methods to have

(e.g. +findAboveHours(int hours):StudentArray

• In JAVA environment Class Level Method is called a ‘Static Method’ and in

 Programmers depend heavily on the benefits of Encapsulation to support the idea

 Object Reuse - A design Principle in which a set of standard Objects can be

 Information Hiding – Is a Design Principle in which Data associated with an

◘ This principle is primarily a Programming concept, several important principles are

Classes with Low Cohesion have several negative effects

1. Elaborate the Attributes with Type and Initial Value information

2. Adding Navigation Visibility Arrow

Some Navigation Visibility Guidelines

- Navigation from Superior to /Subordinate (1: M relationship)

Object-Oriented Analysis and Design and the Unified Process 25

1. We will need to be updated as design progresses Use Case by Use Case

2. Navigation arrows will need to be Updated to be consistent with Design

3. Method Signatures will be added to each Class based on Design decisions

Object-Oriented Analysis and Design and the Unified Process 27

 Developing Interaction Diagrams is at the heart of Object-Oriented design

 Two types of Interaction Diagrams are developed during Design :

 These Diagrams may be modified several times as Designers refine them to

Object-Oriented Analysis and Design and the Unified Process 28

 One of the most important activities of a Designer is to determine Object Responsibility

Two MajorAareas of Object Responsibility

Object-Oriented Analysis and Design and the Unified Process 29

There are several ways to create Use Case Controllers:

Object-Oriented Analysis and Design and the Unified Process 30

 The Objective of Designing Detailed Sequence Diagram is to open up the

Object-Oriented Analysis and Design and the Unified Process 33

◘ Decision about which Other Messages are required, based on Design

Object-Oriented Analysis and Design and the Unified Process 35

 An Object can be “Active” or “Inactive”. (An Active object resides in memory

 We Use “Activation Lifelines” to indicate when an Object is Executing a

 Activation Life is represented with narrow vertical rectangles.

- :Catalog then forwards the message to :ProductItem to initiate Method getDescription )

To define the Internal Messages :-

 Each Electronic Input Form is added as Window Class <<boundary>>

 The Principles of Separation of Responsibilities applies to Data Access Layer

 Because of a problem between Object-Oriented Programming Languages and Database

◘ There is a :MainWindow; with a Menu Item or a Buttonthat