Seeing the Forest in the Midst of the Trees

40
Intro to UML (materials herein excerpted from Seeing the Forest in the Midst of the Trees)

description

Intro to UML (materials herein excerpted from Seeing the Forest in the Midst of the Trees). Seeing the Forest in the Midst of the Trees. What is happening in the software world. The Good News…. “26% of software projects succeed.” Standish Group, CHAOS Report, 2000. The Bad News…. - PowerPoint PPT Presentation

Transcript of Seeing the Forest in the Midst of the Trees

Page 1: Seeing the Forest in the Midst of the Trees

Seeing the Forest in the Midst of the Trees

Seeing the Forest in the Midst of the Trees

Intro to UML(materials herein excerpted from Seeing the Forest in the Midst of

the Trees)

Intro to UML(materials herein excerpted from Seeing the Forest in the Midst of

the Trees)

Page 2: Seeing the Forest in the Midst of the Trees

What is happening in the software world

What is happening in the software world

Page 3: Seeing the Forest in the Midst of the Trees

.

.

.

.

.

.

.

.

..

.

.

. .

.

. ..

..

.

.

.

.

.

“26% of software projects succeed.”Standish Group, CHAOS Report, 2000

The Good News…The Good News…

Page 4: Seeing the Forest in the Midst of the Trees

.

.

.

.

.

.

.

.

..

.

.

. .

.

. ..

..

.

.

.

.

.

That means 74% failed!Standish Group, CHAOS Report, 2000

The Bad News…The Bad News…

Page 5: Seeing the Forest in the Midst of the Trees

Software Development is ComplexSoftware Development is Complex

Poorly designed project architectures require untimely changes

Requirements are undefined or change mid-project

Discovering defects late in project or flaws in architecture and design

Lack of communication between disparate team members

Artifacts are not accessible to all team members

Poorly designed project architectures require untimely changes

Requirements are undefined or change mid-project

Discovering defects late in project or flaws in architecture and design

Lack of communication between disparate team members

Artifacts are not accessible to all team members

Poor Management = CHAOSPoor Management = CHAOS

Page 6: Seeing the Forest in the Midst of the Trees

Standish Group, CHAOS Report, 2000Standish Group, CHAOS Report, 2000

How To Make Sure Your Project will FailHow To Make Sure Your Project will Fail Lack of user input Unclear objectives Incomplete requirements and specifications Changing requirements and specifications Lack of planning

Lack of user input Unclear objectives Incomplete requirements and specifications Changing requirements and specifications Lack of planning

COMMUNICATION COMMUNICATION

Page 7: Seeing the Forest in the Midst of the Trees

Necessity of CommunicationNecessity of Communication Think of a 100 man-person team

Analysts, developers, QE, documentation, contractors Marketing, product management, VPs

Geographically dispersed Different offices Different countries Different time zones

Requirements change or priorities are rearranged Different sub-systems are developed at different timesNumber of communication paths

increases by the square of the team size

Think of a 100 man-person team Analysts, developers, QE, documentation, contractors Marketing, product management, VPs

Geographically dispersed Different offices Different countries Different time zones

Requirements change or priorities are rearranged Different sub-systems are developed at different timesNumber of communication paths

increases by the square of the team size

Page 8: Seeing the Forest in the Midst of the Trees

Higher QualityHigher Quality

Faster Time to Market

Faster Time to Market

The Software Development ParadoxThe Software Development Paradox

Internet time :(Now do it with less …

Internet time :(Now do it with less …

Page 9: Seeing the Forest in the Midst of the Trees

Over the life of a product, the distribution of effort is: 30% development 70% maintenance

Development 40% analysis &design 20% implementation 40% validation

Maintenance 20% adaptive 60% perfective 20% corrective

Over the life of a product, the distribution of effort is: 30% development 70% maintenance

Development 40% analysis &design 20% implementation 40% validation

Maintenance 20% adaptive 60% perfective 20% corrective

The Software Effort BreakdownThe Software Effort Breakdown

< Requirements and modeling< Requirements and modeling

< Testing< Testing< IDE and compiler (fun?)< IDE and compiler (fun?)

Page 10: Seeing the Forest in the Midst of the Trees

What is MissingWhat is Missing Need a common language that unifies the different

stake holders Different stake holders have different software

abstractions (models) and artifacts We need ….

Need a common language that unifies the different stake holders

Different stake holders have different software abstractions (models) and artifacts

We need ….

Page 11: Seeing the Forest in the Midst of the Trees

Communication Using the Unified Modeling Language Communication Using the Unified Modeling Language

Data Modeling

Data Modeling

Web Modeling

One language – One tool – One teamOne language – One tool – One team

Application Modeling

Application Modeling

Business Modeling

Requirements Modeling

Requirements Modeling

Page 12: Seeing the Forest in the Midst of the Trees

Who Should Model?Who Should Model?

RequirementsRequirementsandand

Business ModelsBusiness Models

RequirementsRequirementsandand

Business ModelsBusiness Models

HTMLHTMLCGICGIXMLXML

JavaScriptJavaScript

HTMLHTMLCGICGIXMLXML

JavaScriptJavaScript

Data ModelsData Models

Data ModelsData Models

C++C++JavaJava

SW ModelsSW Models

C++C++JavaJava

SW ModelsSW ModelsSoftwareEngineerSoftwareEngineer

DatabaseDesignerDatabaseDesigner

Web ContentDeveloper

Web ContentDeveloper

BusinessAnalyst

BusinessAnalyst

Page 13: Seeing the Forest in the Midst of the Trees

Host or Target ApplicationHost or Target Application

The Developer’s ViewThe Developer’s View

The Model is The ApplicationThe Model is

The Application

Use Case DiagramUse Case Diagram

Sequence DiagramSequence Diagram

Class DiagramClass Diagram

Structure DiagramStructure Diagram

Behavior DiagramBehavior Diagram

Component DiagramComponent Diagram

Deployment DiagramDeployment Diagram

Page 14: Seeing the Forest in the Midst of the Trees

The Unified Modeling LanguageThe Unified Modeling Language

Page 15: Seeing the Forest in the Midst of the Trees

UML HistoryUML History 1994: Grady Booch and Jim Rumbaugh

began unifying their modeling techniques at Rational Software

1995: Ivar Jacobson joins team at Rational 1996: Consortium of 12 companies formed

to oversee UML Jan 1997: Version 1.0 published Sept 1997: Revised Version 1.1 Nov 1997: Object Management Group

standardized Version 1.4 just accepted Working on version 2.0

1994: Grady Booch and Jim Rumbaugh began unifying their modeling techniques at Rational Software

1995: Ivar Jacobson joins team at Rational 1996: Consortium of 12 companies formed

to oversee UML Jan 1997: Version 1.0 published Sept 1997: Revised Version 1.1 Nov 1997: Object Management Group

standardized Version 1.4 just accepted Working on version 2.0

Page 16: Seeing the Forest in the Midst of the Trees

Why is the Word “Model” Important?Why is the Word “Model” Important? Developing software is about developing executable

abstractions

An abstraction or view is a model For example, a class is an abstraction of a real-world entity or

concept Different stake holders have different abstractions

Marketing has the feature sheet Developers have the requirements Testing have test cases and configurations

There are model types in building a system

Developing software is about developing executable abstractions

An abstraction or view is a model For example, a class is an abstraction of a real-world entity or

concept Different stake holders have different abstractions

Marketing has the feature sheet Developers have the requirements Testing have test cases and configurations

There are model types in building a system

Page 17: Seeing the Forest in the Midst of the Trees

Why is UML So Great?Why is UML So Great? Combines best ideas from software engineering,

database theory, and system design Technology agnostic Problem domain agnostic

Extensibility mechanisms allow tailoring to the domain Scalable

Recursive, hierarchical decomposition Bootstrapping principle

Language that can define itself High information density

Visual Packs a lot into a small space

Combines best ideas from software engineering, database theory, and system design

Technology agnostic Problem domain agnostic

Extensibility mechanisms allow tailoring to the domain Scalable

Recursive, hierarchical decomposition Bootstrapping principle

Language that can define itself High information density

Visual Packs a lot into a small space

Page 18: Seeing the Forest in the Midst of the Trees

UML ModelsUML Models Models capture

the structural, or static, features of systems the behavioral, or dynamic, features of systems.

Models have several independent dimensions Each emphasize particular qualities of a model Each dimension has a diagram type

Models capture the structural, or static, features of systems the behavioral, or dynamic, features of systems.

Models have several independent dimensions Each emphasize particular qualities of a model Each dimension has a diagram type

Page 19: Seeing the Forest in the Midst of the Trees

UML DiagramsUML Diagrams Use case diagrams depict the functionality of a system. Class and object diagrams for the static structure Sequence (collaboration) diagrams for behavior in a

scenario State diagrams for execution Activity diagrams for process descriptions Component diagrams for dependencies between

components Deployment diagrams for configuration and environment

Use case diagrams depict the functionality of a system. Class and object diagrams for the static structure Sequence (collaboration) diagrams for behavior in a

scenario State diagrams for execution Activity diagrams for process descriptions Component diagrams for dependencies between

components Deployment diagrams for configuration and environment

Page 20: Seeing the Forest in the Midst of the Trees

Other Elements of UMLOther Elements of UML There are many

Package, sub-system, class, classifier, interface, … We really don’t have the time to discuss this Talk to your professors There are many good books around

There are many Package, sub-system, class, classifier, interface, …

We really don’t have the time to discuss this Talk to your professors There are many good books around

Page 21: Seeing the Forest in the Midst of the Trees

USE CASEsUSE CASEs

Describes the proposed functionality of a system Represent functional requirement Notation

Use cases: ellipse with action phase Actors is a user of the system or other systems

Describes the proposed functionality of a system Represent functional requirement Notation

Use cases: ellipse with action phase Actors is a user of the system or other systems

Page 22: Seeing the Forest in the Midst of the Trees

Logical ModelLogical Model

Class and Object Diagrams Class Diagram Notation

3-compartment rectangle Relationship among classes

Object diagram: instance of a class

Accessibility Notation

Class and Object Diagrams Class Diagram Notation

3-compartment rectangle Relationship among classes

Object diagram: instance of a class

Accessibility Notation

Page 23: Seeing the Forest in the Midst of the Trees

Logical Model (continued)Logical Model (continued)

Class and Object Relationship Inheritance: generally describes the hierarchical relationship between

classes (family tree) .

Class and Object Relationship Inheritance: generally describes the hierarchical relationship between

classes (family tree) .

Some materials herein are excerpted from The Logical Model by Geoffrey SparksSome materials herein are excerpted from The Logical Model by Geoffrey Sparks

Page 24: Seeing the Forest in the Midst of the Trees

Logical Model (continued)Logical Model (continued)

Class and Object Relationship Association: generally relate to one object having an instance of another

as an attribute or owning.

Class and Object Relationship Association: generally relate to one object having an instance of another

as an attribute or owning.

Some materials herein are excerpted from The Logical Model by Geoffrey SparksSome materials herein are excerpted from The Logical Model by Geoffrey Sparks

Page 25: Seeing the Forest in the Midst of the Trees

Sequence Diagrams (dynamic relationship)Sequence Diagrams (dynamic relationship)

illustrates this message passing and the sequence in which it occurs normally within a given usecase

illustrates this message passing and the sequence in which it occurs normally within a given usecase

Some materials herein are excerpted from The Logical Model by Geoffrey SparksSome materials herein are excerpted from The Logical Model by Geoffrey Sparks

Page 26: Seeing the Forest in the Midst of the Trees

Logical Model (continued)Logical Model (continued)

Class and Object Relationship Aggregation: generally define whole/part relationships..

Class and Object Relationship Aggregation: generally define whole/part relationships..

Some materials herein are excerpted from The Logical Model by Geoffrey SparksSome materials herein are excerpted from The Logical Model by Geoffrey Sparks

Page 27: Seeing the Forest in the Midst of the Trees

Cool Things to do with UMLCool Things to do with UML

Page 28: Seeing the Forest in the Midst of the Trees

Do all of this for Multiple LanguagesDo all of this for Multiple Languages UML models can be targeted for different languages

Java Microsoft Visual C++ Microsoft Visual Basic ANSI C++ Ada IDL XML-DTD SQL

UML models can be targeted for different languages Java Microsoft Visual C++ Microsoft Visual Basic ANSI C++ Ada IDL XML-DTD SQL

Page 29: Seeing the Forest in the Midst of the Trees

Keeping the Model and Code SynchronizedKeeping the Model and Code Synchronized

Manual model and code synchronization On-demand

synchronization Complete control as

updates occur Auto synchronization

Source is updated when model is modified

Rational Rose model updated when source is modified

Manual model and code synchronization On-demand

synchronization Complete control as

updates occur Auto synchronization

Source is updated when model is modified

Rational Rose model updated when source is modified

Page 30: Seeing the Forest in the Midst of the Trees

Unit Test FunctionalityUnit Test Functionality Generate test code directly from model Provide test data and expected results

Generate test code directly from model Provide test data and expected results

Generate Component Test

Generate Component Test

StubStubStubStub

TestDriverTest

DriverModelModel

Test GenerationTest Generation

Developer AddsTest Data

Developer AddsTest Data

Page 31: Seeing the Forest in the Midst of the Trees

System Test FunctionalitySystem Test Functionality

????

Model

Create Create ComponentsComponents

Create Create ComponentsComponents

Brief Description:The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description.

Flow of Events:This use case starts when the actor does something. An actor always initiates use Cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a dialog between the actor and the system.

The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information; it is better to say the Actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable; you may want to define things like customer information there, to keep the use case from drowning in details.

Simple alternatives may be presented within the text of the use case. If it only takes a few

and what the system does in response. It should be phrased in the form of a dialog between the actor and the system.

The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information; it is better to say the

Actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable; you may want to define things like customer information there, to

keep the use case from drowning in details.

Simple alternatives may be presented within the text of the use case. If it only takes a few

TestsTests

Generate “Skeleton”

Code

Generate “Skeleton”

Code

code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code

Complete Code

code

code

codecodecode

codecodecodecodecodecode

Automates Component TestingAutomates Component Testing

1. Embellish model Easier testing More complete

testing

1. Embellish model Easier testing More complete

testing

2. Automatically generate component tests from the model

2. Automatically generate component tests from the model

Automatically generate code for component testing from a UML model

Enable scenario-based testing during component integration, before system is complete

Automatically generate code for component testing from a UML model

Enable scenario-based testing during component integration, before system is complete

Page 32: Seeing the Forest in the Midst of the Trees

Ready made design and code solutions for common development tasks COM, MFC, ATL MTS, ADO ASP, DHTML

Fully customizable You can create your own

code templates to automatecommon design and implementation tasks to ensure consistencyin both design and code

Ready made design and code solutions for common development tasks COM, MFC, ATL MTS, ADO ASP, DHTML

Fully customizable You can create your own

code templates to automatecommon design and implementation tasks to ensure consistencyin both design and code

Code Templates For Architecture DesignCode Templates For Architecture Design

Page 33: Seeing the Forest in the Midst of the Trees

Frameworks For Architecture DefinitionFrameworks For Architecture Definition

Frameworks: Predefined model element sets for modeling specific systems

Used to: Define the architecture of

specific types of systems Provide a set of

reusable components Create templates for

new models Simplify development with

commercial frameworks Promote reuse and standards

with custom user frameworks

Frameworks: Predefined model element sets for modeling specific systems

Used to: Define the architecture of

specific types of systems Provide a set of

reusable components Create templates for

new models Simplify development with

commercial frameworks Promote reuse and standards

with custom user frameworks

Page 34: Seeing the Forest in the Midst of the Trees

Robust Development Using Proven PatternsRobust Development Using Proven Patterns

Develop your application using predefined industry recognized patterns: Apply patterns

to existing model elements

Create new model elements automatically via patterns

Leverage proven designs

Develop your application using predefined industry recognized patterns: Apply patterns

to existing model elements

Create new model elements automatically via patterns

Leverage proven designs

Page 35: Seeing the Forest in the Midst of the Trees

UML Model DebuggingUML Model Debugging

Rational Rose RealTime ModelModel

Generate/CompileGenerate/Compile Control/ObserveControl/Observe

Page 36: Seeing the Forest in the Midst of the Trees

Distributed UML DesignsDistributed UML Designs Enables deployment and visualization of distributed applications Supports patterns for creating high-availability applications Provides the distributed communication infrastructure

Enables deployment and visualization of distributed applications Supports patterns for creating high-availability applications Provides the distributed communication infrastructure

COTS Server

Shelf ControllerShelf ControllerCall ServerCall ServerAdministrationAdministration H/W ControlH/W Control

Page 37: Seeing the Forest in the Midst of the Trees

That’s allThat’s all

Page 38: Seeing the Forest in the Midst of the Trees

Some Important Web SitesSome Important Web Sites The SEEDS program will let your college get Rose

http://www.rational.com/corpinfo/college_relations/seed/termscond.jsp

.NET development http://rational.devx.com/index.htm/CONTENT_ID/5959

Java development www.jroundup.com

Project management www.ganthead.com

The SEEDS program will let your college get Rose http://www.rational.com/corpinfo/college_relations/seed/

termscond.jsp .NET development

http://rational.devx.com/index.htm/CONTENT_ID/5959 Java development

www.jroundup.com Project management

www.ganthead.com

Page 39: Seeing the Forest in the Midst of the Trees
Page 40: Seeing the Forest in the Midst of the Trees

“ClearCase is the dominant SCM tool.” Ovum“ClearCase is the dominant SCM tool.” Ovum

No.1 in Visual Modeling, 4 years running1 Rational RoseNo.1 in Visual Modeling, 4 years running1 Rational Rose

No.1 in SCM, 3 years running1 Rational ClearCaseNo.1 in SCM, 3 years running1 Rational ClearCase

“…a major contender as the de facto standard for real-time embedded ...” IDC“…a major contender as the de facto standard for real-time embedded ...” IDC

Real-time embedded leadership Rational Rose RealTimeReal-time embedded leadership Rational Rose RealTime

“...the battle for dominance is over: Rational wins.” Ed Yourdon“...the battle for dominance is over: Rational wins.” Ed Yourdon

Driving Standards in Best Practices UML, WebDAVDriving Standards in Best Practices UML, WebDAV

“…the company that put the ‘unified’ in modeling languages…” JavaPro“…the company that put the ‘unified’ in modeling languages…” JavaPro

“Easy-to-use...ideal for team based development...” InfoWorld“Easy-to-use...ideal for team based development...” InfoWorld

No.1 in Requirements Management2 Rational RequisiteProNo.1 in Requirements Management2 Rational RequisitePro

1 IDC, 2 Standish1 IDC, 2 Standish

Rational: Ongoing LeadershipRational: Ongoing Leadership