Systems Analysis and Design

Chapter 9: A&D in RUP

Slides in this presentation contain

hyperlinks. JAWS users should be
able to get a list of links by using
INSERT+F7
Questions
– Clarify difference between Analysis and Design
Analysis and Design Activity Overview
Topics covered

• Analysis and design

• Objects and object classes
• An object-oriented design process
• Design evolution
The Object-Oriented Analysis

• In Analysis we model the users’ requirements

• For what the eventual system must DO

• Output of this process is a conceptual model
• Consisting of 2 deliverables:
– Requirements Model
– Object Model
The Requirements model

• Project Scope
• Context Diagram
• Use Case Model
– Use case diagram
– Activity diagram

• Interface Descriptions
• Feasibility study
Object model

• Class diagram
• State transition diagram
• Sequence diagram
• Collaboration diagram
The Object-Oriented Design

• Modify Analysis model to reflect design decisions,

• Mostly by adding information to the existing model.
• Add some new classes that do not directly model things in the real
world.

• Result is a plan of how the system will do what the

Requirements Analysis asks for
Analysis and Design Overview

Analysis and
Design
Design Model
Use-Case Model

Architecture
Document
Glossary Supplementary
Specification Data Model
 Analysis Versus Design

•Analysis •Design
– Focus on understanding the – Focus on understanding the solution
problem – Operations and Attributes
– Idealized design – Performance
– Behavior – Close to real code
– System structure – Object lifecycles
– Functional requirements – Non-functional requirements
– A small model – A large model
Analysis and Design is not Top-Down or Bottom-Up
Subsystems

Top
Down

Use Cases

Design Classes Bottom

Up
Topics covered

• Analysis and design

• Objects and object classes
• An object-oriented design process
• Design evolution
Object-oriented development

• Object-oriented analysis, design and programming are

related but distinct.
• OOA is concerned with developing an object model of
the application domain.
• OOD is concerned with developing an object-oriented
system model to implement requirements.
• OOP is concerned with realising an OOD using an OO
programming language such as Java or C++.
Characteristics of OOD

• Objects are abstractions of real-world or system entities and

manage themselves.
• Objects are independent and encapsulate state and
representation information.
• System functionality is expressed in terms of object
services.
• Shared data areas are eliminated. Objects
communicate by message passing.
• Objects may be distributed and may execute
sequentially or in parallel.
Advantages of OOD

• Easier maintenance. Objects may be

understood as stand-alone entities.
• Objects are potentially reusable components.
• For some systems, there may be an obvious
mapping from real world entities to system
objects.
 Objects and classes

An object is an entity that has a state and a defined set of

operations which operate on that state. The state is represented as
a set of object attributes. The operations associated with the object
provide services to other objects (clients) which request these
services when some computation is required.

Objects are created according to some object class definition. An

object class definition serves as a template for objects. It includes
declarations of all the attributes and services which should be
associated with an object of that class.
Object communication
• Conceptually, objects communicate by message
passing.
• Messages
– The name of the service requested by the calling object;
– Copies of the information required to execute the service
and the name of a holder for the result of the service.

• In practice, messages are often implemented

by procedure calls
– Name = procedure name;
– Information = parameter list.
Interacting objects
Generalisation and inheritance

• Objects are members of classes that define

attribute types and operations.
• Classes may be arranged in a class hierarchy
where one class (a super-class) is a generalisation of one or
more other classes (sub-classes).
• A sub-class inherits the attributes and
operations from its super class and may add
new methods or attributes of its own.
• Generalisation in the UML is implemented as inheritance in
OO programming languages.
A generalisation hierarchy

Emplo yee

Mana ger Prog rammer

budgetsControlled project
progLanguages
dateAppointed

Project Dept. Strateg ic

Mana ger Mana ger Mana ger

projects dept responsibilities

Generalisation and inheritance

• Advantages and disadvantages of inheritance

Advantages of inheritance

• It is an abstraction mechanism which may be used to

classify entities.
• It is a reuse mechanism at both the design and the
programming level.
• The inheritance graph is a source of organisational
knowledge about domains and systems.
Problems with inheritance

• Object classes are not self-contained. they cannot be

understood without reference to their super-classes.
• Designers have a tendency to reuse the inheritance graph
created during analysis. Can lead to significant inefficiency.
• The inheritance graphs of analysis, design and
implementation have different functions and should be
separately maintained.
Topics covered

• Analysis and design

• Objects and object classes
• An object-oriented design process
• Design evolution
Some UML modeling notations

• Use case diagram

• Class diagram
• Sequence diagram
• Statechart diagram
• Activity diagram
• Deployment diagram
• Component diagram
• Collaboration diagram
An object-oriented design process
• Structured design processes involve developing a number of
different system models
• They require a lot of effort for development and maintenance
of these models, and, for small systems, this may not be
cost-effective
• However, for large systems developed by different groups
design models are an essential communication mechanism.
Process stages
• Highlights key activities without being tied to any
proprietary process such as the RUP.
– Define the context and modes of use of the system;
– Identify the principal system objects;
– Design the system architecture;
– Develop design models;
– Specify object interfaces.
Analysis and Design Activity Overview
 Use-Case
Realization
Architect Designer

Package/
Subsystem
Design Model Class

Software Architecture
Design
Document
Reviewer

Data Model
Database Designer
Architecture
Reviewer
Running example: Simple personnel
information system

• Design a simple information system to support a personnel

manager.
• Features include the ability to add, query and delete
personnel in a database.
System context and models of use

• Develop an understanding of the relationships between

the software being designed and its external
environment
• System context
– A static model that describes other systems in the environment.
Use a subsystem model to show other systems.

• Model of system use

– A dynamic model that describes how the system interacts with
its environment. Use use-cases to show interactions
Use-case models

• Use-case models are used to represent each interaction with

the system.
• A use-case model shows the system features as ellipses
and the interacting entity as a stick figure.
• Flow of events within a use case can be depicted using
sequence diagrams.
 Use cases for the personnel
information system

The diagram is only part of the story.

Need to also develop use case descriptions (not shown here).
Sequence models

• Uses
– OOA – depict flow of events within a use case; helps identify initial
objects
– OOD – depict interactions of objects; helps identify methods and
other attributes and classes
• Review
– Objects are arranged horizontally across the top;
– Time is represented vertically so models are read top to bottom;
– Interactions are represented by labelled arrows, Different styles of
arrow represent different types of interaction;
– A thin rectangle in an object lifeline represents the time when the
object is the controlling object in the system.
Add personnel sequence

: : : Personnel
: Manager
PersonnelForm PersonnelControl
1: enter data

2: select add

3: add personnel

4: add

5: successful

6: display success

7: read
Object identification

• Identifying objects (or object classes) is the most difficult part

of object oriented analysis and design.
• There is no 'magic formula' for object identification. It relies
on the skill, experience and domain knowledge of system
designers.
• Object identification is an iterative process. You are unlikely
to get it right first time.
Approaches to identification

• Use a grammatical approach based on a natural

language description of the system.
• Base the identification on tangible things in the
application domain.
• Use a behavioural approach and identify objects based
on what participates in what behaviour.
• Use a scenario-based analysis. The objects, attributes
and methods in each scenario are identified.
Application domain objects

PersonnelForm

PersonnelControl PersonnelSearch

Personnel

Initial class diagram derived from the behavioral models

(sequence diagrams).
Architectural design
• Once interactions between the system and its
environment have been understood and initial objects
have been identified, you use this information for
designing the system architecture.
• A layered architecture is appropriate for this information
system
– User interface layer for handling interactions;
– Application logic layer for controlling data access and updates;
– Data management layer for storing data.
• There should normally be no more than 7 subsystems
in an architectural model.
Design models

• Design models show the objects and object classes and

relationships between these entities.
• Static models describe the static structure of the system in
terms of object classes and relationships.
• Dynamic models describe the dynamic interactions between
objects.
Examples of design models

• Sub-system models that show logical groupings of

objects into coherent subsystems.
• Sequence models that show the sequence of object
interactions.
• State machine models that show how individual objects
change their state in response to events.
• Other models include use-case models, aggregation
models, generalisation models, etc.
Subsystem models

• Shows how the design is organised into logically related

groups of objects.
• In the UML, these are shown using packages - an
encapsulation construct. This is a logical model. The actual
organisation of objects in the system may be different.
Application domain objects

PersonnelForm

PersonnelControl PersonnelSearch

Personnel

(Initial class diagram)

Subsystem decomposition

<<subsystem>>
userInterface

PersonnelForm In this case,

each layer is one
<<subsystem>>
subsystem.
appLogic

PersonnelControl PersonnelSearch In general, a

layer can have
more than one
<<subsystem>>
dataManagement subsystem.
Personnel
Distribution strategy

Client

userInterface

Webserver

appLogic

DatabaseServer

dataManagement
(Deployment diagram)
Platforms and implementation
technologies

Client Webserver
appLogic
userInterface
Java servlet

JVM Browser Webserver

JDBC

DatabaseServer
(Deployment diagram) JDBC
dataManagement

Relational DBMS
Object interface specification

• Object interfaces have to be specified so that the objects

and other components can be designed in parallel.
• Designers should avoid designing the interface
representation but should hide this in the object itself.
• Objects may have several interfaces which are viewpoints
on the methods provided.
• The UML uses class diagrams for interface specification but
Java may also be used.
• Heuristic: figure out how you plan to divide the work, and
specify the interfaces between the divisions.
Database interface

• An interface can be defined to hide the details of how the

underlying database tables are organized.

interface class DatabaseInterface {

public void AddPersonnel();
public void DeletePersonnel();
public void queryPersonnel()
}

public class ProxyDatabaseInterface implements DatabaseInterface {

…
}

public class RealDatabaseInterface implements DatabaseInterface {

…
}
Topics covered

• Analysis and design

• Objects and object classes
• An object-oriented design process
• Design evolution
Design evolution

• Hiding information inside objects means that

changes made to an object do not affect other
objects in an unpredictable way.
• Example: the system must now support different types
of personnel with different attributes.
• To support this, we can create subclasses of Personnel
class as well as PersonnelForm class to accommodate
different types of Personnel. The application logic does
not have to change (ideally).
Key points

• OOD is an approach to design so that design

components have their own private state and
operations.
• Objects should have constructor and inspection
operations. They provide services to other objects.
• Objects may be implemented sequentially or
concurrently.
• The Unified Modeling Language provides different
notations for defining different object models.
Key points

• A range of different models may be produced during an

object-oriented design process. These include static and
dynamic system models.
• Object interfaces should be defined precisely using e.g. a
programming language like Java.
• Object-oriented design potentially simplifies system
evolution.