RRC AD

Software Engineering Process
Disciplined, Modern, and Mature
An Overview Workshop for the Railroad
Commission of Texas
January 21 & 22, 2003

Analysis and DesignAnalysis and Design
Analysis and Design Overview
• The purpose of analysis and design is to:
 Transform the requirements into a design of
the system to-be
 Evolve a robust software architecture
 Adapt the design to match the
implementation environment, designing it for
performance

Analysis and Design Overview
• Inputs to Analysis and Design
 Use Case Model
 Supplementary Specification
 Glossary
• Outputs from Analysis and Design include:
 Design Model
 Software Architecture Document
 Physical Data Model
 User Interface Design Document
 Report Design Document

Analysis vs. Design
• Analysis
 Focus on understanding the problem
 Idealized design
 System behavior
 System structure
 Functional requirements
 A small analysis model

Analysis vs. Design
• Design
 Focus on understanding the solution
 Operations and attributes
 Performance
 Close to real code
 Object lifecycles
 Non-functional requirements
 A large model

Software Architecture
• Encompasses the set of significant decisions
about the organization of a software system
 Selection of the structural elements and their
interfaces by which a system is composed
 Behavior as specified in collaborations
among those elements
 Composition of those structural and
behavioral elements into large subsystems
 Architectural style that guides the
organization

Software Architecture
• In addition to the set of strategic design decisions
that have been made by the Software Architect,
architecture includes consideration for rules or
patterns that constrain the design
• Software Architecture: The “4+1View” Model
 Use Case View
 Logical View
 Implementation View
 Process View
 Deployment View

Architecture Analysis
• Architectural Analysis is where an initial
attempt is made at:
 Defining the pieces/parts of the system and
their relationships
 Organizing on these pieces/parts into well-
defined layers with explicit dependencies
 Concentrating on the upper layers of the
system
• While the above is easy to say, there are specific
steps identified in RUP to assist in this effort

What is Use-Case Realization?
• Development is the process of creating a system
from requirements
• A use case realization describes how a particular
use case is realized in the design model, in terms
of collaborating objects
• A use case realization ties together the use cases
from the Use Case Model with the classes and
relationships of the design model
• A use case realization specifies what classes must
be built to implement each use case

Object-Oriented Concepts
• Recall that “Use Component Architectures” is one
of the Best Practices of Software Engineering
• RUP itself is generic business process for object-
oriented software engineering customizable to the
needs of your organization or project
• If your organization is new to object-oriented
analysis and design, however, don’t be overly
concerned
• OOAD is a very natural and logical way of
approaching software development

• While object-orientation has a specific meaning
when it comes to programming, it is important to
note that we think about the world in object-
oriented terms all the time
• This is what makes an object-oriented approach so
powerful
• Think about a tree for a moment, a tree is an
object
• Now think about a pecan tree, the State Tree of
Texas

• A pecan tree is a kind of tree with specific
characteristics
• The pecan tree in my neighbors back yard is an
instance of a pecan tree
• This pecan tree knows how to do certain things
but I don’t know how it does it
• And information is stored in the pecan tree that I
can not see or directly access

• I can, however, communicate with this tree by
sending it fertilizer messages through its roots
• What I have described is an object-oriented
approach
• That is, object-oriented development methodology
is a methodology that is based on the concepts of
classes, objects, encapsulation, messages, and
inheritance

• A class is a description of a set of objects that
share the same attributes, operations,
relationships, and semantics (e.g., pecan tree)
• An object is an instance of a class with a well-
defined boundary and unique identity that
encapsulates state and behavior (e.g., my
neighbors pecan tree)
• Encapsulation is the hiding of a software object’s
internal representation (e.g., I am clueless how the
pecan tree uses fertilizer I provide, but it does)

• The object provides an interface (i.e., a set of
operations) that support the querying and
manipulation of the data (e.g., the pecan tree’s
roots)
• This interface provides access to the data without
exposing the underlying structure or the
implementation details that support the interface
(Note: think SQL, or structured query language)
• Software objects communicate with each other
using messages

• The types of messages that an object understands
correspond to the operations that the object
supports, which, in turn, defines its behavior (e.g.,
the fertilizer and water messages sent to the pecan
tree)
• A class inherits state and behavior from its
superclass (e.g., the pecan tree is a kind of tree)
• Inheritance provides a powerful and natural
mechanism for hierarchically organizing and
structuring software programs

• While this Overview Workshop is not intended to
be a course on object-oriented programming
concepts, this is important because the use-case
realization process is at its core object-oriented
• That is, use case realization describes how a
particular use case is realized in the design model,
in terms of collaborating objects
• To help us understand how to approach OOAD,
RUP provides a pattern that we will apply to the
use case realization process

• To help us understand how to approach OOAD,
RUP provides a pattern that we will apply to the
use case realization process
• Patterns address common design problems by
providing generalized solutions for these problems
• The major benefit of utilizing a pattern is that the
pattern documents existing, well-proven design
experience

Boundary, Control, and Entity Design Pattern
• The BCE pattern represents a refinement of the
model-view-controller (MVC) design pattern, a
pattern that dates back to the early days of the
Smalltalk-80 object-oriented language
• The goal of the MVC design pattern is to
decompose the application into three distinct types
of objects:
 Model Objects
 View Objects
 Controller Objects

• Rules govern how each of these objects can
communicate with the other objects associated
with the pattern
• Prior to the MVC design pattern, event-driven
software designers tended to collapse the logic
associated with each of these three object types
into the GUI itself
• As one might imagine, doing so created a very fat
client application that lacked flexibility,
scalability, and the possibility of component reuse

MVC Design PatternMVC Design Pattern
Controller
Model
ViewView
Notify Notify
Query Query
ChangeChange
Change

• The BCE design pattern is closely related to the
MVC design pattern
• As such, its goal is to decompose the application
into three distinct types of objects:
 Boundary objects
 Control objects
 Entity objects
• The primary distinction between these two design
patterns is the rules that govern object
communication

• This innovative approach to analysis and design,
which was originally introduced by Doug
Rosenberg and Kendall Scott
• Stereotypes (i.e., a meta-classification of an
element) based upon these three object types are
available in Rational Rose for creating interaction
and class diagrams
• Once this pattern has been describes, an analysis
or design model in Rose will become very
recognizable

Stereotype
UML Element Element in Rational Rose
Icon in the Rational Unified
Process
«boundary» Class Class with stereotype «boundary»
«control» Class Class with stereotype «control»
«entity» Class Class with stereotype «entity»

Boundary Objects
• Boundary objects are responsible for supporting
communications between the system’s external
environment (e.g., its users, other systems, or
hardware devices) and its internal workings (i.e.,
control and entity objects)
• Within the context of use case realization, there
will be one boundary class for each user interface
• The actor(s) identified within the Use Case Model
will always interact with the system through these
boundary objects

Boundary Objects
• Within the various interaction and class diagrams
created in Rational Rose, a boundary class is
commonly used as a placeholder for a GUI that
will be created using the features and capabilities
provided by an integrated development
environment (IDE)
• Boundary classes, however, are not used
exclusively as a placeholder for a GUI
• Boundary classes will also be used to support
communications with legacy systems

Boundary Objects
• In these instances, the legacy system will be
modeled as an actor and a boundary class will be
created to provide the actor with an interface to
the system
• Unlike view objects within the MVC pattern, a
boundary object will always interface with a
control object and never directly with an entity
class

Control Objects
• Control objects are responsible for application
specific business logic
• In addition, these object types also function as an
intermediary between the system’s various
boundary and entity objects
• Within the context of use case realization, each
boundary class will communicate with a single
control class and control classes will be used to
manage each use case’s flow of execution

Control Objects
• To manage this flow, the control object must
coordinate the activities required to support the
use case realization, including interactions with
other control objects and the data aware entity
objects
• Each entity object will be tightly coupled with a
control object
• When a control object functions in this capacity,
its role is referred to as an object-relational broker
(ORB)

Control Objects
• An ORB’s responsibilities include:
 Managing the activities associated with
retrieving the data
 Instantiating the entity object
 Making the data encapsulated within the
entity object persistent

Entity Objects
• Entity objects are the data aware objects within
the system
• Taken together, these objects are responsible for
providing support for the entities that constitute
the problem domain (e.g., in STARS stations, sites,
etc.)
• When the system uses a RDMBS, the data
encapsulated within the system’s entity objects are
made persistent within the RDBMS by the control
classes functioning as an ORB

Entity Objects
• When an instance of an entity (e.g., a particular
station) must be retrieved from the RDBMS for
displaying at a GUI, the ORB tightly coupled with
that entity object will retrieve the data and
instantiate the entity object
• To display the data, the data encapsulated within
the entity object will traverse a path that
eventually leads to the control object that is tightly
coupled to the boundary object

Entity Objects
• At this point, the data will be passed to the
boundary object for displaying in the GUI
• If the data is updated while being displayed at the
GUI, the updated data will traverse this path in
reverse until the ORB makes the updated data
encapsulated within the entity object persistent
within the RDBMS

• Collaborating together, the various boundary,
control, and entity objects within the BCE design
pattern realize the behavior documented in the
system’s Use Case Model
• The rules that govern communication between the
various object types within the BCE design
pattern are illustrated in the tables that follow

Allowed Communication within the BCE Design Pattern
Actor or Object Initiating
Communication Flow of Communication Target Object

Communication Not Allowed within the BCE
Actor or Object
Initiating
Communication
Flow of
Communication Target Object

Layers Design Pattern
• A layer represents a slice through the software
architecture, with each layer representing a
grouping of related functionality
• Layering provides a way to decompose the system
into more manageable software components and
restrict inter-system dependencies with the goal
being to design a system that is more loosely
coupled and thus easier to maintain

• An important characteristic of the layers design
pattern is the directional dependencies that exist
between the various layers
• That is, a software component within a given layer
should ideally access only components within its
own layer or components in the layers beneath it
• This directional dependency rule is one of the
mechanisms by which the goal of the layers design
pattern is realized

• A common application of the layers design pattern
organizes and defines the various layers within the
problem domain based upon the responsibilities
assigned to each layer
• Responsibility-based layering isolates and
organizes the various system responsibilities into a
hierarchical structure, typically comprised of a
Presentation, Business Logic, and Data Access
Layers

• Presentation Layer
This top layer provides support for the
interactions between the actors, or the users of the
system, and the software system itself through the
presentation of user interfaces
• Business Logic Layer
This middle layer provides support for application
specific business processes, as well as, the
application and enforcement of business and data
integrity rules

• Data Access Layer
This bottom layer provides support for data access
and persistence when using, for example, a
relational database

Layers Design Pattern - Communication
• Presentation Layer
Initiates communication with the Business Logic
Layer and, occasionally, the Data Access Layer,
but neither of these two lower layers would initiate
communication with the Presentation Layer
• Business Logic Layer
Initiates communication with the Data Access
Layer, but the Data Access Layer would never
initiate communication with the Business Logic
Layer

• Data Access Layer
While never initiates communication with either
of the two layers structurally above it, this layer
does initiate communication with the RDBMS

<< layer >>
Presentation
Layer
<< layer >>
Business Logic
Layer
<< layer >>
Data Access
Layer

Common Solution Space Layers
<< layer >>
Presentation
Layer
<< layer >>
Business Logic
Layer
<< layer >>
Data Access
Layer
System Software Layer
Middleware Layer
Application Layer

• The responsibilities assigned to each layer
precisely define the purpose for each layer
• As a result, this architectural pattern provides
an elegant solution for decomposing a complex
system in order to facilitate the comprehension,
organization, manageability, and maintainability
of the system
• And it relates exactly with the BCE Design
Pattern

Layers and BCE Design Patterns
• BCE design pattern’s objects map to the layers
defined by the layers design pattern and
conforms to its rules of communication
Object Type Presentation Layer Business Logic Layer Data Access Layer
Boundary Object X
Control Object X
Entity Object X

Stereotype
Icon in the Rational Unified
Process Implementations
«boundary»
HTML
DHTML
ASP .NET
Client and Server Scripts
Presentation Services
«control»
Web Services
Com+
Business Services
«entity»
ADO .NET
XML
Stored Procedures
RDBMS objects
Data Services
From Analysis to Design with the BCE Pattern

Mechanics of Use Case Realization
• With the above concepts in place, the mechanics
of the use case realization process is, more or
less, fairly straight forward
• That is, we will apply the BCE Design Pattern to
identify the objects that will collaborate together
to support the behavior/functional requirements
specified in our Use Case Model
• To accomplish this, three UML diagrams will be
created: Sequence, Collaboration, and a “View
of Participating Classes” Class Diagram

Sequence Diagram
• A diagram that shows object interactions
arranged in time sequence
• In particular, it shows the objects participating
in the interaction and the sequence of messages
exchanged
• A sequence diagram includes time sequences but
does not include object relationships
• A sequence diagram helps identify the objects
that will collaborate together to support a use
case

Sequence Diagram
• One or more sequence diagrams may illustrate
the object interactions which enact a use case
• A typical organization is to have one sequence
diagram for the main flow of events and one
sequence diagram for each independent sub-flow
or alternate flow of the use case

Collaboration Diagram
• A collaboration diagram describes a pattern of
interaction among objects
• It shows the objects participating in the
interaction by their links to each other and the
messages that they send to each other
• Collaboration diagrams are used to show how
objects interact to perform the behavior of a
particular use case, or a part of a use case
• In contrast to Sequence Diagrams, the timing of
the interactions are not shown

View of Participating Classes – Class Diagram
• A use-case realization represents the design
perspective of a use case in terms of
collaborating objects
• Having identified the boundary, control, and
entity classes that will collaborate to support the
behavior/flow of events in the use case, these
classes are captured in a “View of Participating
Classes” Class Diagram
• Taken together, these class diagrams roll back
the lid on the ‘Design Black Box’

Group Activity
• Review the Course Registration System Rose
Model
• Review the STARS Rose Model
• Review the STARS Software Architecture
Document
• Review the other design deliverables from the
STARS Project: Data Model, UI Design
Document, Report Design Document

RRC AD

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (11)

Similar to RRC AD

Similar to RRC AD (20)

More from Terry Startzel, MS, PMP, SCPM, CSM

More from Terry Startzel, MS, PMP, SCPM, CSM (7)

RRC AD