Session 3 Introduction to Unified Process Dana Indra Sensuse (
[email protected]) Indra Budi (
[email protected]) Petrus Mursanto (
[email protected])
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
Structure
Diagrams 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 Diagram
Class Diagram
State Diagram
Document add( ) delete( )
fetchDoc( ) sortByName( )
name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( )
FileList
Use Case 1
fList add( ) delete( )
Actor A
Writing
add file [ numberOffile==MAX ] / flag OFF
read() fill the code..
Openning
close file
1
Actor B close file Reading
Closing
rep
Use Case 2
File
Repository (from Persistence)
Domain Expert
add file
DocumentList FileMgr
read( )
<<entity>> Customer name addr receive() withdraw() fetch() send()
GrpFile
name : char * = 0 read( ) open( ) create( ) fillFile( )
readDoc( ) readFile( )
Use Case 3 UI
Deployment Diagram
Class
MFC
DocumentApp ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® À©µµ¿ì NT: ÀÀ¿ë¼¹ö À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
RogueW ave
Repository
Persistence
9: sortByName ( )
DocumentList
W indows95
W indow95
W indows95
global
FileManager
mainWnd : MainWnd 1: Doc view request ( )
L
2: fetchDoc( )
gFile : GrpFile
4: create ( ) 8: fillFile ( )
User Interface Definition
¹®¼°ü¸® Ŭ¶óÀ̾ðÆ®.EXE
user : »ç¿ëÀÚ fileMgr : FileMgr 3: create ( )
Package Diagram
¹®¼°ü¸® ¾ÖÇø´
W indows NT
Document
Solaris
¹®¼°ü¸® ¿£Áø.EXE
Alpha UNIX ÀÀ¿ë¼¹ö.EXE Windows NT
GraphicFile File
IBM Mainframe
FileList
6: fillDocument ( ) µ¥ÀÌŸº£À̽º¼¹ö
7: readFile ( ) 5: readDoc ( )
document : Document
repository : Repository
Collaboration Diagram mainWnd user
ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
fileMgr : FileMgr
document : Document
gFile
Component Diagram
Forward Engineering(Code Generation) and Reverse Engineering
repository
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 Language
Analysis and Design Information System – MTI Fasilkom 2008
Process
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 requirements
Software Engineering Process
Analysis and Design Information System – MTI Fasilkom 2008
New or changed system
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
Develop Iteratively
Model Visually
Verify Quality
Control Changes
Analysis and Design Information System – MTI Fasilkom 2008
Use Component Architectures
Rational Unified Process Is Use-Case Driven Check Balance Client
Withdraw Money
Use Cases for a Cash Machine
Analysis and Design Information System – MTI Fasilkom 2008
An actor is someone or something outside the system that interacts with the system A use case is a sequence of actions a system performs that yields an observable result of value to a
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
Use cases drive numerous activities in the process:
End users, developers and acquirers understand functional requirements of the system 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
Analysts/ Designers Structure
End-user Functionality
Implementation View
Use-Case View
Process View System Integrators Performance Scalability Throughput
Analysis and Design Information System – MTI Fasilkom 2008
Programmers Software management
Deployment View
System Engineering System topology Delivery, installation communication
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 Objective Milestone
Lifecycle Architecture Milestone
Analysis and Design Information System – MTI Fasilkom 2008
Initial Operational Capability Milestone
Product Release
Iterations and Phases Inception
Preliminary Iteration
Elaboration
Construction
Architect. Architect. Devel. Iteration Iteration Iteration
Devel. Iteration
Devel. Iteration
Transition
Transition Transition 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
Analysis & Design
realized by Use-Case Model implemented by Design Model verified by
Implementation Implementation Model
Test Test Model Analysis and Design Information System – MTI Fasilkom 2008
Bringing It All Together: The Iterative Model Phases Process Workflows
Inception Elaboration
Construction
Business Modeling
In an iteration, you walk Transition all through workflows
Requirements Analysis & Design Implementation Test Deployment
Supporting Workflows
Workflows group activities logically
Configuration Mgmt Management Environment
Preliminary Iteration(s)
Analysis and Design Information System – MTI Fasilkom 2008
Iter. #1
Iter. #2
Iter. #n
Iter. Iter. #n+1 #n+2
Iterations
Iter. #m
Iter. #m+1
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 highquality 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
The requirements set groups all artifacts related to the definition of the software system to be developed:
The design model The architecture description
The implementation set includes these elements:
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:
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 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 V is io n
E lic it S t a k e h o ld e r N eeds
M anage D e p e n d e n c ie s
F in d A c to r s and U se C ases S tru c tu re th e U s e C a s e M o d e l
C a p tu re a C om m on V o c a b u la r y
D e ta il a U se C ase
U s e C a s e S p e c ifie r
U s e rIn te rfa c e M o d e lin g
U s e rIn te rfa c e D e s ig n e r
A r c h ite c t
P r io r itiz e U se C ases
Analysis and Design Information System – MTI Fasilkom 2008
U s e rIn te rfa c e P r o to ty p in g
R e q u ir e m e n t s R e v ie w e r
R e v ie w R e q u ir e m e n ts
Tool Support for the Entire Project Lifecycle Process Workflows Business Modeling
RequisitePro, Rose, SoDA
Requirements
RequisitePro, Rose, SoDA
Analysis & Design Implementation Test Deployment
Rose, SoDA, Apex Rose, Apex, SoDA, Purify, … SQA Team Test, Quantify, PerformanceStudio, … SoDA, ClearCase, …
Supporting Workflows Config & Change Mgmt Project Management Environment
ClearCase, ClearQuest Unified Process, Microsoft Project, … Unified Process, Rational Tools
Analysis and Design Information System – MTI Fasilkom 2008