principles of object technology module 1: principles of modeling

Principles of Object TechnologyModule 1: Principles of Modeling

Principles of Object TechnologyModule 1: Principles of Modeling

Principles of Object Technology, v1.0Copyright © 2000 Rational Software, all rights reserved 2

Objectives: Principles of Modeling

Understand the importance of visual modeling. Define the four principles of visual modeling. Explain what the Unified Modeling Language

(UML) represents. Define the type process that best relates to the

UML. Understand the structure of the Rational Unified

Process (RUP).


Where Are We?

What is modeling? Four principles of visual modeling The UML Process and visual modeling The Rational Unified Process (RUP)


The Importance of Modeling

Paper Airplane F-15 Fighter Jet

Less Important More Important


Software Teams Often Do Not Model

Many software teams build F-15 fighter jets approaching the problem like they were building paper airplanes. Start coding from project requirements Work longer hours and create more code Lack of any planned architecture Most of these projects fail

A common thread to successful projects is modeling.


What Is a Model?

A model is a simplification of reality.


Why Do We Model?

We build models to better understand the system we are developing.

Modeling achieves four aims. Modeling Helps us to visualize a system as we want it to be. Permits us to specify the structure or behavior of a

system. Gives us a template that guides us in constructing a

system. Documents the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.


Where Are We?



Four Principles of Modeling

The model you create influences how the problem is attacked.

Every model may be expressed at different levels of precision.

The best models are connected to reality. No single model is sufficient.


Principle 1: The Choice of Model Is Important

The models you create profoundly influence how a problem is attacked and how a solution is shaped. In software, the models you choose

greatly affect your world view. Each world view leads to a different

kind of system.

Deployment Diagram

Process Model

Design Model


Principle 2: Levels of Precision May Differ

Every model may be expressed at different levels of precision. The best kinds of models are those that let you

choose your degree of detail, depending on who is doing the viewing and why they need to view it.


Principle 3: The Best Models Are Connected to Reality

The best models are connected to reality. All models simplify reality. A good model will reflect potentially fatal

characteristics.


Principle 4: No Single Model Is Sufficient

No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. Create models that can be built and studied separately,

but that are still interrelated.

Process View Deploym ent View

Logical View

Use-Case View

Im plem entation View

End-user FunctionalityEnd-user Functionality

Program m ersSoftw are m anagem ent

Perform anceScalab ilityThroughput

System in tegratorsPerform anceScalab ilityThroughput

System in tegratorsSystem topo logy

Delivery, installationcom m unication

System eng ineering

Analysts /DesignersStructure


Where Are We?



What Is the UML?

The UML is a language for Visualizing Specifying Constructing Documenting

the artifacts of a software-intensive system.


The UML Is a Language for Visualizing

Communicating conceptual models to others is prone to error unless everyone involved speaks the same language.

There are things about a software system you can’t understand unless you build models.

An explicit model facilitates communication.


The UML Is a Language for Specifying

The UML allows the building of models that are precise, unambiguous, and complete.


The UML Is a Language for Constructing

UML models can be directly connected to a variety of programming languages. Maps to Java, C++, Visual Basic, and so on Tables in a RDBMS or persistent store in an

OODBMS Permits forward engineering Permits reverse engineering


The UML Is a Language for Documenting

The UML addresses documentation of system architecture, requirements, tests, project planning, and release management.

Actor A

Use-Case 1

Use-Case 2

Actor B

u s e r : » ç ¿ ë À Ú

ma in Wn d : Ma in Wn d

file Mg r : F ile Mg r

re p o s ito ry : Re p o s ito ryd o c u me n t : Do c u me n t

g F ile : Grp F ile

9 : s o rtB y N a m e ( )

L1 : D o c v ie w re q u e s t ( )

2 : fe tc h D o c ( )

5 : re a d D o c ( )

7 : re a d F ile ( )

3 : c re a te ( )

6 : fillD o c u m e n t ( )

4 : c re a te ( )

8 : fillF ile ( )

G rp F ile

re a d ( )o p e n ( )c re a te ( )fillF ile ( )

re p

R e p o s ito ry

n a m e : c h a r * = 0

re a d D o c ( )re a d F ile ( )

(fro m P e rs is te n c e )

F ile M g r

fe tc h D o c ( )s o rtB y N a m e ( )

D o c u m e n tL is t

a d d ( )d e le te ( )

D o c u m e n t

n a m e : in td o c id : in tn u m F ie ld : in t

g e t( )o p e n ( )c lo s e ( )re a d ( )s o rtF ile L is t( )c re a te ( )fillD o c u m e n t( )

fL is t

1

F ile L is t


1

F ile

re a d ( )

re a d () fill th e c o d e ..

U I

M F C

R o g u e W a v e

g lo b a l

D o c u m e n tA p p

P e rs is te n c e W in d o w 9 5

¹® ¼ °ü ® Å ¬ ¶ ó À Ì¾ ð Æ ® .E X E

W in d o w sN T

¹® ¼ °ü ® ¿ £ Á ø .E X E

W in d o w sN T

W in d o w s 9 5

S o la ris

À À ¿ ë ¼ ¹ö .E X E

A lp h aU N IX

IB M M a in fra m e

µ ¥ À ÌÅ º£ À Ì½ º¼ ¹ö

W in d o w s 9 5

¹® ¼ °ü ® ¾ Ö Ç Ã ¸

ºÐ » ê È ¯ °æ À Ç Ç Ïµ å ¿ þ ¾ î¹× ³× Æ ® ¿ ÷ À ·ÎÀ Ç Á ¤ º ½ Ã ½ ºÅ Û ¿ ¬ °á ð µ ¨ - À © µ µ ¿ ì 9 5 : Å ¬ ¶ ó À Ì¾ ð Æ ® - À © µ µ ¿ ì N T : À À ¿ ë ¼ ¹ö - À ¯ Ð ½ º Ó ½ Å : À À ¿ ë ¼ ¹ö ¹× µ ¥ À ÌÅ ¼ ¹ö , Å ë ½ Å ¼ ¹ö - IB M Þ À ÎÇ Á ·¹À Ó : µ ¥ À ÌÅ ¼ ¹ö , Å ë ½ Å ¼ ¹ö

Document

FileManager

GraphicFileFile

Repository DocumentList

FileList

u s e r

m a in Wn dfile M g r : F ile M g r

re p o s ito ryd o c u m e n t : D o c u m e n t

g F ile

1 : D o c v ie w re q u e s t ( )

2 : fe tc h D o c ( )

3 : c re a te ( )

4 : c re a te ( )

5 : re a d D o c ( )



8 : fillF ile ( )


Æ ¯ Á ¤ ¹® ¼ ¿ ¡ ë Ç Ñ º± â ¦ » ç ¿ ë À Ú °¡ ¿ ä Ã » Ç Ñ Ù .

È À Ï°ü ® À Ú Â À Ð ¾ î¿ Â ¹® ¼ À Ç Á ¤ º¦ Ç Ø ç ¹® ¼ °Ã ¼ ¿ ¡ ¼ ³Á ¤ À » ¿ ä Ã » Ç Ñ Ù .

È é °Ã ¼ Â À Ð ¾ îµ é À Î °Ã ¼ µ é ¿ ¡ ë Ç Ø À Ì§ º°·Î Á ¤ ·Ä À » ½ Ã Ä Ñ È é ¿ ¡ º¿ © Á Ø Ù .

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

DomainExpert

O p e n n in g

W ritin g

R e a d in gC lo s in g

a d d file [ n u m b e rO ffile = = M A X ] / fla g O F F

a d d file

c lo s e file

c lo s e file

Use-Case 3

Source Code edit, compile, debug, link

Use-Case Diagram

Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

State Diagram

Package Diagram

Deployment DiagramClass

Actor A

Use-Case 1

Use-Case 2

Actor B

u s e r : » ç ¿ ë À Ú

ma in Wn d : Ma in Wn d

file Mg r : F ile Mg r

re p o s ito ry : Re p o s ito ryd o c u me n t : Do c u me n t

g F ile : Grp F ile


L1 : D o c v ie w re q u e s t ( )

2 : fe tc h D o c ( )

5 : re a d D o c ( )


3 : c re a te ( )


4 : c re a te ( )

8 : fillF ile ( )

G rp F ile


re p

R e p o s ito ry

n a m e : c h a r * = 0



F ile M g r




D o c u m e n t



fL is t

1

F ile L is t


1

F ile

re a d ( )


U I

M F C

R o g u e W a v e

g lo b a l


P e rs is te n c e

G rp F ile


re p

R e p o s ito ry

n a m e : c h a r * = 0



F ile M g r




D o c u m e n t



fL is t

1

F ile L is t


1

F ile

re a d ( )


U I

M F C

R o g u e W a v e

g lo b a l


P e rs is te n c e W in d o w 9 5

¹® ¼ °ü ® Å ¬ ¶ ó À Ì¾ ð Æ ® .E X E

W in d o w sN T

¹® ¼ °ü ® ¿ £ Á ø .E X E

W in d o w sN T

W in d o w s 9 5

S o la ris

À À ¿ ë ¼ ¹ö .E X E

A lp h aU N IX

IB M M a in fra m e

µ ¥ À ÌÅ º£ À Ì½ º¼ ¹ö

W in d o w s 9 5

¹® ¼ °ü ® ¾ Ö Ç Ã ¸

ºÐ » ê È ¯ °æ À Ç Ç Ïµ å ¿ þ ¾ î¹× ³× Æ ® ¿ ÷ À ·ÎÀ Ç Á ¤ º ½ Ã ½ ºÅ Û ¿ ¬ °á ð µ ¨ - À © µ µ ¿ ì 9 5 : Å ¬ ¶ ó À Ì¾ ð Æ ® - À © µ µ ¿ ì N T : À À ¿ ë ¼ ¹ö - À ¯ Ð ½ º Ó ½ Å : À À ¿ ë ¼ ¹ö ¹× µ ¥ À ÌÅ ¼ ¹ö , Å ë ½ Å ¼ ¹ö - IB M Þ À ÎÇ Á ·¹À Ó : µ ¥ À ÌÅ ¼ ¹ö , Å ë ½ Å ¼ ¹ö

Document

FileManager

GraphicFileFile


FileList

Document

FileManager

GraphicFileFile


FileList

u s e r

m a in Wn dfile M g r : F ile M g r

re p o s ito ryd o c u m e n t : D o c u m e n t

g F ile

1 : D o c v ie w re q u e s t ( )

2 : fe tc h D o c ( )

3 : c re a te ( )

4 : c re a te ( )

5 : re a d D o c ( )



8 : fillF ile ( )


Æ ¯ Á ¤ ¹® ¼ ¿ ¡ ë Ç Ñ º± â ¦ » ç ¿ ë À Ú °¡ ¿ ä Ã » Ç Ñ Ù .

È À Ï°ü ® À Ú Â À Ð ¾ î¿ Â ¹® ¼ À Ç Á ¤ º¦ Ç Ø ç ¹® ¼ °Ã ¼ ¿ ¡ ¼ ³Á ¤ À » ¿ ä Ã » Ç Ñ Ù .

È é °Ã ¼ Â À Ð ¾ îµ é À Î °Ã ¼ µ é ¿ ¡ ë Ç Ø À Ì§ º°·Î Á ¤ ·Ä À » ½ Ã Ä Ñ È é ¿ ¡ º¿ © Á Ø Ù .

Customernameaddr


receive()

<<entity>>Customernameaddr


receive()

<<entity>>

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

DomainExpertDomainExpert

O p e n n in g

W ritin g



a d d file

c lo s e file

c lo s e file

O p e n n in g

W ritin g



a d d file

c lo s e file

c lo s e file

Use-Case 3

Source Code edit, compile, debug, link

Use-Case Diagram

Class Diagram

Collaboration Diagram

Sequence Diagram

Component Diagram

State Diagram

Package Diagram

Deployment DiagramClass


History of the UML


Inputs to the UML

Fusion

Operation descriptions,Message numbering

Fusion

Operation descriptions,Message numbering

Meyer

Before and after conditions

Meyer

Before and after conditions

Harel

State charts

Harel

State charts

Wirfs-Brock

Responsibilities

Wirfs-Brock

Responsibilities

Embley

Singleton classes, High-level view

Embley

Singleton classes, High-level view

Odell

Classification

Odell

Classification

Shlaer - Mellor

Object Lifecycles

Shlaer - Mellor

Object Lifecycles

Gamma, et.al

Frameworks, patterns,notes

Gamma, et.al

Frameworks, patterns,notes

BoochRumbaugh Jacobson


Where Are We?



A Language Is Not Enough to Build a System

Modeling Language

Unified Process

Team-Based Development


What Type of Process Most Benefits the UML?

The UML is largely process independent. However, to get the most benefit from the UML, you should consider a process that is Use-case driven. Architecture-centric. Iterative and incremental.


A Use-Case Driven Process

Use cases defined for a system are the basis for the entire development process.

Benefits Use cases are concise, simple, and understandable by

a wide range of stakeholders. Use cases help synchronize the content of different

models.

Withdraw MoneyWithdraw Money

CustomerCustomer

Check BalanceCheck Balance


An Architecture-Centric Process

A system’s architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development.

Benefits You gain and retain intellectual control over a

project to manage its complexity and to maintain system integrity.

It provides an effective basis for large-scale reuse.

It provides a basis for project management. It helps with component-based development.


An Iterative and Incremental Process

Critical risks are resolved before making large investments.

Initial iterations enable early user feedback. Testing and integration are continuous. Objective milestones focus on the short

term. Progress is measured by assessing

implementations. Partial implementations can be deployed.


Iterative and Incremental Development

Earliest iterations address greatest risks. Each iteration produces an executable

release, an additional increment of the system.

Each iteration includes integration and test.

T I M E

Iteration 1 Iteration 2 Iteration 3

IC

DR

TI

CD

R

TI

CD

R

T


Where Are We?



Introducing the Rational Unified Process (RUP)

The Rational Unified Process is Use-case driven. Architecture-centric. Iterative and incremental.


Process Structure: Lifecycle Phases

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 to end user.

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

timetime


Phase Boundaries Mark Major Milestones

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransitionInceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Lifecycle Objective Milestone

Lifecycle Architecture

Milestone

Initial Operational Capability Milestone

Product Release

Lifecycle Objective Milestone

Lifecycle Architecture

Milestone

Initial Operational Capability Milestone

Product Release

time


Iterations and Phases

An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external).

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration


Devel. Devel. IterationIteration



TransitionTransitionIterationIteration



PreliminaryPreliminaryIterationIteration









Minor Milestones: Releases


Bringing It All Together: The Iterative Approach

Project Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration & Change Mgmt

Requirements

Elaboration TransitionInception Construction

Workflowsgroup activitieslogically

In an iteration,you walk through all workflows


Checkpoints

What is a model? What are the four principles of

modeling? Describe each one. What is the UML? Describe each of its

four benefits. What process characteristics best fit

the UML? Describe each characteristic. What are the four phases of the

Rational Unified Process? Describe each one.

What is an iteration? What is a phase?

principles of object technology module 1: principles of modeling

Documents

principles of modeling

principles of visual

rational software

importance of visual

software teams

unified modeling language

choice of model

single model