Session 3

Introduction to Unified
Process

Dana Indra Sensuse (dana@cs.ui.ac.id)

Indra Budi (indra@cs.ui.ac.id)
Petrus Mursanto (santo@cs.ui.ac.id)

Analysis and Design Information System – MTI Fasilkom 2008
 Software Design Principles and
Object-Oriented Systems

Analysis and Design Information System – MTI Fasilkom 2008
 Software Design Principles and
Object-Oriented Systems
 Design Principle: Modularity (Modularisation):
 Decomposing large software into a number of smaller as
independent as possible components, usually with the goal of
placing different functionalities or responsibilities in different
components.
 Modularity allows the complexity of large software to be
manageable
 Object-Oriented Systems – Modularised
 Classes and objects as the basic components or modules provides a
convenient and effective way to realise and implement the
modularisation
Analysis and Design Information System – MTI Fasilkom 2008
 Software Design Principles and
Object-Oriented Systems (cont)
 Design Principle: Maximise Information Hiding
 Information hiding is a term to describe that components hides the
internal details and processing from one another
 Object-Oriented Systems – Information hided
 Maximising information hiding is achieved as only the information
required to be passed to and returned from a module is published.
Exactly how a module implements its functionality is not relevant
 This also provide the reusable objects

Analysis and Design Information System – MTI Fasilkom 2008
 Software Design Principles and
Object-Oriented Systems (cont)
 Design Principle: Minimise Coupling
 Coupling is a term to describe the interactions between components.
The lower coupling, the less interaction (i.e., the more independence)
between components
 Object-Oriented Systems – Loosely coupled:
 Encapsulation (i.e., combination of data and process into an entity)
minimises the need of coupling between data and process
 Information hiding minimises the communication coupling

Analysis and Design Information System – MTI Fasilkom 2008
 Software Design Principles and
Object-Oriented Systems (cont)
 Design Principle: Maximise Cohesion
 Cohesion is a term to describe the interactions within components.
The more cohesive a component, the more related the internal parts
of the component to each other and to its whole purpose
 Object-Oriented Systems – highly cohesive:
 Classes and objects provides highly cohesive units that contain both
data and process, as data and process that are strongly related can be
grouped together into a class and object

Analysis and Design Information System – MTI Fasilkom 2008
 Object Oriented Systems
Analysis and Design with Unified
Process

Analysis and Design Information System – MTI Fasilkom 2008
Object Oriented Systems Analysis
and Design
 Grady Booch, Ivar Jacobson & James Rumbaugh said that any
modern oo approach to develop IS must be:
 Use-case driven
 Use case the primary modeling to define the behaviour of the system
 Architecture Centric
 The underlying software architecture of the evolving system specification
drives the specification, construction and documentation of the system
 Support three separate but interrelated architectural views of a system
 Functional view

 Static (structure) view

 Dynamic (behaviour) view

 Iterative and Incremental

 Undergoes continous testing and refinement throughout the life of the project
 Each iteration of the system brings it closer and closer to real user needs
Analysis and Design Information System – MTI Fasilkom 2008
Unified Process
 A special methodology which uses UML techniques for OO analysis and
design
 Phases of Unified Process
 Inception, elaboration, construction, and transition

 Workflows of Unified Process

 Engineering workflows:
 Business modeling, requirements, analysis, design, implementation, test,
deployment
 Supporting workflows:
 Configuration and change management, project management, environment

Analysis and Design Information System – MTI Fasilkom 2008
Engineering Workflows

Analysis and Design Information System – MTI Fasilkom 2008
Supporting Workflows

Analysis and Design Information System – MTI Fasilkom 2008
The Rational Unified Process (RUP)
 RUP is an example of a specialized version of the Unified
Process that adds elements to the generic framework
 A Two-dimensional systems development process described by
a set of phases and workflows.
 The phases support an analyst in developing information
systems in an iterative and incremental manner, consists of
inception, elaboration, construction and transition
 The workflows describe the task of activites that a developer
performs to evolve an information system overtime, consists of:
business modelling, requirement, analysis, design,
implementation, test, deployment (Engineering Workflows),
project management, configuration and change managemen, and
environment (Supporting Workflows).

Analysis and Design Information System – MTI Fasilkom 2008
Unified Modeling Language (UML)

Analysis and Design Information System – MTI Fasilkom 2008
What Is the UML?
 The Unified Modeling Language (UML) is a
language for
 Specifying

 Visualizing

 Constructing

 Documenting

the artifacts of a software-intensive system

Analysis and Design Information System – MTI Fasilkom 2008
UML History*

* from http://vinci.org/uml/history.html

Analysis and Design Information System – MTI Fasilkom 2008
The Unified Modeling Language, Version 2.0
 Defines a set of fourteen (14) diagram to model
the system
 Classified into two groups in general
 StructureDiagrams
 Behavior Diagrams

Analysis and Design Information System – MTI Fasilkom 2008
UML 2.0 Diagram Summary

Analysis and Design Information System – MTI Fasilkom 2008
Use Case Diagram Example

Analysis and Design Information System – MTI Fasilkom 2008
Activity Diagram Example

Analysis and Design Information System – MTI Fasilkom 2008
 UML Diagrams Are Key System Artifacts in RUP
Use-Case
Class Diagram State Diagram
Diagram FileMgr
DocumentList
Document
add file

add( )
name : int
fetchDoc( ) delete( ) docid : int
sortByName( ) numField : int
Writing
add file [ numberOffile==MAX ] /
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( ) Openning

Use Case 1 add( )

fList create( )
fillDocument( )
delete( )
1 close file

Actor A Actor B
close file
Closing
Reading

rep
Use Case 2 File

<<entity>>
Repository

Customer
(from Persistence) GrpFile
read( )

name
name : char * = 0

Domain
read( )
readDoc( )

addr
open( )

Deployment
readFile( )
create( )
fillFile( )

receive()
withdraw()
Expert
Use Case 3
fetch()
send()

Diagram
UI

MFC Class
DocumentApp

ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

­ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
­ À©µµ¿ì NT: ÀÀ¿ë¼­¹ö
­ À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
­ IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö

DocumentList
RogueW ave

Persistence
Repository W indow95 W indows95

9: sortByName ( ) W indows95

global

¹®¼­°ü¸®

FileManager Ŭ¶óÀ̾ðÆ®.EXE
¹®¼­°ü¸® ¾ÖÇø´

mainWnd : MainWnd W indows

NT

Package
1: Doc view request ( ) L

Document Solaris

2: fetchDoc( )
¹®¼­°ü¸® ¿£Áø.EXE

4: create ( ) gFile : GrpFile

Alpha
UNIX
8: fillFile ( ) ÀÀ¿ë¼­¹ö.EXE

User Interface Diagram

Windows
NT

user : »ç¿ëÀÚ GraphicFile IBM

fileMgr : FileMgr Mainframe

3: create ( )
File FileList
6: fillDocument ( )

Definition
µ¥ÀÌŸº£À̽º¼­¹ö

7: readFile ( )

5: readDoc ( )
document : Document
repository : Repository

Forward Engineering(Code Generation)

Collaboration Diagram Component and

mainWnd fileMgr : document : gFile repository

Diagram Reverse Engineering
user FileMgr Document

Source Code edit, compile, debug, link

ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )

¹®¼­ÀÇ Á¤º¸¸¦ ÇØ ´ç ¹®¼­
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.

7: readFile ( )

8: fillFile ( )

È­¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
º¸¿©ÁØ´Ù.

Sequence Diagram

Executable System

Analysis and Design Information System – MTI Fasilkom 2008
The Rational Unified Process (RUP) *

* This part of slides mostly from Rational Presentation on Introduction to RUP

Analysis and Design Information System – MTI Fasilkom 2008
Building a System - A Language Is Not Enough

Team-Based
Development

Modeling
Process
Language

Analysis and Design Information System – MTI Fasilkom 2008
What Is a Process?

A process defines Who is doing What, When

and How to reach a certain goal. In software
engineering the goal is to build a software
product or to enhance an existing one
New or changed Software Engineering New or changed
requirements system
Process

Analysis and Design Information System – MTI Fasilkom 2008
An Effective Process ...
 Provides guidelines for efficient development of
quality software
 Reduces risk and increases predictability
 Captures and presents best practices
 Learn from other’s experiences
 Mentor on your desktop
 Extension of training material
 Promotes common vision and culture
 Provides roadmap for applying tools
 Delivers information on-line, at your finger tips
Analysis and Design Information System – MTI Fasilkom 2008
Rational Unified Process Delivers Best
Practices
Rational Unified Process describes how to
effectively implement the six best practices for
software development
Manage Requirements

Use
Develop Model Verify
Visually Component
Iteratively Quality Architectures

Control Changes

Analysis and Design Information System – MTI Fasilkom 2008
 Rational Unified Process Is Use-Case
Driven
An actor is someone
or something
Check Balance
Client outside the
system that
interacts with the
system
Withdraw Money A use case is a
sequence of
Use Cases for a Cash Machine actions a system
performs that
yields an
observable result
of value to a
Analysis and Design Information System – MTI Fasilkom 2008
Use Cases Include a Flow of Events
Flow of events for the Withdraw Money Use Case
1. The use case begins when the client inserts her ATM card.
The system reads and validates information on the card.
2. The system prompts for the PIN. The system validates the
PIN.
3. The system asks which operation the client wishes to
perform. The client selects “Cash withdrawal.”
4. The system requests the amount. The client enters the
amount.
5. The system requests the account type. The client selects
checking or savings.
6. The system communicates with the ATM network . . .
Analysis and Design Information System – MTI Fasilkom 2008
Benefits of a Use-Case Driven
Process
 Use cases are concise, simple, and understandable by a wide
range of stakeholders
 End users, developers and acquirers understand functional requirements
of the system
 Use cases drive numerous activities in the process:
 Creation and validation of the design model
 Definition of test cases and procedures of the test model
 Planning of iterations
 Creation of user documentation
 System deployment
 Use cases help synchronize the content of different models

Analysis and Design Information System – MTI Fasilkom 2008
RUP Is Architecture-Centric
 Architecture is the focus of the elaboration phase
 Building, validating, and baselining the architecture constitute the
primary objective of elaboration
 The Architectural Prototype validates the architecture and
serves as the baseline for the rest of development
 The Software Architecture Description is the primary artifact
that documents the architecture chosen
 Other artifacts derive from architecture:
 Design guidelines including use of patterns and idioms
 Product structure
 Team structure

Analysis and Design Information System – MTI Fasilkom 2008
Representing Architecture: The 4+1 View Model

Logical View Implementation

View

Analysts/
End-user Programmers
Designers
Structure Functionality Software management
Use-Case
View
Process View Deployment
View
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput communication

Analysis and Design Information System – MTI Fasilkom 2008
Benefits of an Architecture-Centric Process
 Architecture lets you gain and retain intellectual control over a
project, to manage its complexity, and to maintain system
integrity
 Architecture provides an effective basis for large-scale reuse
 Architecture provides a basis for project management
 Architecture facilitates component-based development
 A component fulfills a clear function in the context of a well-defined
architecture
 A component conforms to and provides the physical realization of a set
of interfaces
 Components exist relative to a given architecture

Analysis and Design Information System – MTI Fasilkom 2008
 Process Architecture - Lifecycle Phases
Inception Elaboration Construction Transition

time

The Rational Unified Process has four phases:

 Inception - Define the scope of project
 Elaboration - Plan project, specify features, baseline
architecture
 Construction - Build the product

 Transition - Transition the product into end user

community
Analysis and Design Information System – MTI Fasilkom 2008
 Phase Boundaries Mark Major Milestones

Inception Elaboration Construction Transition

time

Lifecycle Lifecycle Initial Operational Product

Objective Architecture Capability Release
Milestone Milestone Milestone

Analysis and Design Information System – MTI Fasilkom 2008
Iterations and Phases
Inception Elaboration Construction Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Minor Milestones: Releases

An iteration is a distinct sequence of activities with an

established plan and evaluation criteria, resulting in an
executable release (internal or external)

Analysis and Design Information System – MTI Fasilkom 2008
Major Workflows Produce Models
Business
Modeling supported by
Business Model

Requirements realized by
Use-Case
Model
Analysis &
Design implemented by
Design
Model

Implementation verified by

Implementation
Model
Test

Test
Model
Analysis and Design Information System – MTI Fasilkom 2008
Bringing It All Together: The
Iterative Model Phases
In an iteration,
you walk
Process Workflows Inception Elaboration Construction Transition all
through
Business Modeling workflows
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Workflows Environment
group Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
activities
logically Iterations
Analysis and Design Information System – MTI Fasilkom 2008
Iterative Development Life Cycle (UP) PSI

Disciplines

RBPL
SQA

Analysis and Design Information System – MTI Fasilkom 2008
 RUP is

A software engineering process

 A process product
 A process framework
 A collection of best practices

Analysis and Design Information System – MTI Fasilkom 2008
The RUP is a software engineering
process
 It provides a disciplined approach to assigning
tasks and responsibilities within a development
organization.
 Its goal is to ensure the production of high-
quality software that meets the needs of its end
users within a predictable schedule and budget.

Analysis and Design Information System – MTI Fasilkom 2008
RUP is a process product
 It is developed and maintained by Rational
Software and integrated with its suite of software
development tools.
 It is available from IBM on CD-ROM or through
the Internet.

Analysis and Design Information System – MTI Fasilkom 2008
The RUP is a process framework
 RUP can be adapted and extended to suit the
needs of an adopting organization

Analysis and Design Information System – MTI Fasilkom 2008
The RUP is a collection of best
practices
 The Rational Unified Process captures many of
the best practices in modern software
development in a form that is suitable for a
wide range of projects and organizations

Analysis and Design Information System – MTI Fasilkom 2008
 The RUP process
 A process describes who is doing what, how, and
when. The Rational Unified Process is represented
using five primary elements:
 Roles: the who
 Activities: the how

 Artifacts: the what

 Workflows: the when

 Disciplines: the "container" for the preceding four

kinds of element

Analysis and Design Information System – MTI Fasilkom 2008
Role, Activities and Artifact in RUP

Analysis and Design Information System – MTI Fasilkom 2008
 People and Roles

People Roles Activities

Paul Designer Define operations

Mary Use-Case Specifier Detail a Use-Case

Joe System Analyst Find Actors and Use-Cases

Sylvia Implementer Perform Unit Tests

Stephen Architect Identify Design Mechanisms

Each individual in the project is

Assigned to one or several roles
Analysis and Design Information System – MTI Fasilkom 2008
Articfacts
 Is a piece of information that is produced, modified, or
used by a process
 Artifacts take various shapes or forms:
 A model, such as the use-case model or the design model
 A model element—an element within a model—such as a
class, a use case, or a subsystem
 A document, such as a business case or software architecture
document
 Source code
 Executables

Analysis and Design Information System – MTI Fasilkom 2008
Sets of Artifacts
 Management set groups all artifacts related to the software business and to the
management of the project
 Planning artifacts, such as the software development plan (SDP), the business case, the
actual process instance used by the project (the development case), and so on
 Operational artifacts, such as a release description, status assessments, deployment
documents, and defect data
 The requirements set groups all artifacts related to the definition of the software
system to be developed:
 The vision document
 Requirements in the form of stakeholders' needs, use-case model, and supplementary
specification
 The design set contains a description of the system to be built (or as built) in these
forms:
 The design model
 The architecture description
 The implementation set includes these elements:
 The source code and executables
 The associated data files or the files needed to produce them
 The deployment set contains all the information delivered, including the following:
 Installation material
 User documentation
 Training material

Analysis and Design Information System – MTI Fasilkom 2008
Growing the information sets

Analysis and Design Information System – MTI Fasilkom 2008
Workflow
 A workflow is a sequence of activities that
produces a result of observable value

Analysis and Design Information System – MTI Fasilkom 2008
Requirements Workflow
D e v e lo p E lic it S t a k e h o ld e r
V is io n N eeds
F in d A c to r s
and U se C ases

C a p tu re a S tru c tu re th e
M anage
C om m on U s e ­C a s e M o d e l R e q u ir e m e n t s
D e p e n d e n c ie s
V o c a b u la r y R e v ie w e r

D e ta il a R e v ie w
U s e ­C a s e
S p e c ifie r U se C ase R e q u ir e m e n ts

U s e r­In te rfa c e U s e r­In te rfa c e

U s e r­In te rfa c e M o d e lin g P r o to ty p in g
D e s ig n e r

P r io r itiz e
A r c h ite c t U se C ases

Analysis and Design Information System – MTI Fasilkom 2008
 Tool Support for the Entire Project Lifecycle

Process Workflows
Business Modeling RequisitePro, Rose, SoDA
Requirements RequisitePro, Rose, SoDA
Analysis & Design Rose, SoDA, Apex
Implementation Rose, Apex, SoDA, Purify, …
Test SQA Team Test, Quantify, PerformanceStudio, …
Deployment SoDA, ClearCase, …
Supporting Workflows
Config & Change Mgmt ClearCase, ClearQuest
Project Management Unified Process, Microsoft Project, …
Environment Unified Process, Rational Tools

Analysis and Design Information System – MTI Fasilkom 2008