Japanese Engineer Training (JET)Randy Guthrie – Microsoft Corporation1 UML and the design of...

1

UNIFIED MODELING LANGUAGE

Japanese Engineer Training (JET) Randy Guthrie – Microsoft Corporation

UML and the design of Object-Oriented Information Systems

Professor Randy Guthrie

Randy Guthrie - Cal Poly Pomona 2

ABOUT YOUR INSTRUCTOR

Japanese Engineer Training (JET)


Your Instructor

15 Years Industry Experience Contract Administrator Project Manager Financial Analyst

9 Years University Teaching Experience

1 Year with Microsoft Corporation



Your Instructor

My Family Married 29 years Six Children

three married Three in college one still in school


Randy Guthrie - Cal Poly Pomona 5Japanese Engineer Training (JET)


WHERE I LIVE


Denver, Colorado


Colorado



My Home in Denver(Winter)



OVERVIEW



Rational Unified Process (RUP)

Four Stages: Inception Elaboration Construction Transition



RUP - Inception

Making the business case to management

High level goals of the project Rough estimates of costs & benefits Rough estimates of resource

commitments



RUP - Elaboration

Better definition of overall goals of project

Iterative implementation of core architecture

Resolution of high risks Identification of most of the requirements Realistic estimates



RUP - Construction

Iterative implementation of lower-risk elements

Preparation for deployment Training Hardware installation & test



RUP - Transition

Beta or limited-release testing Deployment



RUP & Iterations



Unified Process Iterative Development

software/system developed in iterations (cycles)

each iteration critical use cases developed first two-four weeks duration based on use cases

fully-dressed use cases domain model robustness diagram sequence diagram class diagram working code tested code



Unified Process

Each iteration completes a portion of the system client evaluates software at each iteration changes are incorporated into next

iteration cycle continues until system is complete



Unified Process


EventAnalysis

BriefUse

Cases

PrototypeScreens

RankUse Cases

Casual / Full DressUse Case

RobustnessDiagram

SequenceDiagram

ClassDiagram

DomainModel

Codeand Test

UnifiedProcess / Iterative

Development


Unified Process

Some Best Practices Iterative Development

Project developed in 2-4 week phases Called “time-boxes”

Use of software design “patterns” GRASP Gang of Four Many others



Analysis Phase

Exploring the “problem domain” Defining system and problem boundaries

What is “in-scope” vs. “out-of-scope” Discovering system requirements



Design Phase

Creating a conceptual solution Identifying software classes Assigning responsibilities to the software

classes



Design Phase

Software Classes have two types of responsibility: “knowing” (attributes / data) “doing” (behavior / methods)

Assigning responsibilities to classes is a critical activity of software design In other words, deciding where the variables

and operations go is really important



Analysis and Design

Are done at the same time Most analysis is completed during

elaboration phase during early iterations



What Is the Unified Modeling Language

(UML) A standardized set of documentation

and diagramming techniques that are useful for analyzing and designing information systems that will be implemented using object-oriented software



RATIONAL UNIFIED ARCHITECTURE



Rational Unified Architecture


End-userFunctionality

Programmers

System EngineersTopology/Communications

IntegratorsPerformanceScalability

Logical ViewDevelopment

View

Process View Physical View

Scenarios


Logical Architecture

Supports Functional Requirements what services the system should provide to

the users Focus on objects and object classes

class diagrams



Process Architecture

Specifies non-functional requirements performance availability fault tolerance

Specifies how functional requirements will be met



Development Architecture

Focuses on how the actual software modules/class are organized software structure

Object Oriented or structured three-tier architecture



Physical Architecture

Addresses physical infrastructure and topologies for system hardware/software platforms networks terminals protocols storage media backup / recovery



Scenarios

All four views are integrated (related) through “scenarios” Scenario is a story about how the system is

used sometimes referred to as “use cases”



USE CASES


Stories about how a feature is used to complete a task


Use Case

Not part of UML and not OO Text Document, not a “diagram” Focuses on one task / feature Can be high level and brief Can be low-level and detailed Typically avoids mention specific

technology such as “scan bar code”



Use Case

Three general types of use case Brief: one paragraph summary Casual: information paragraph format–

multiple paragraphs cover various scenarios Detailed (full dress): formal structure



Detailed Use Case

Sections of Detailed Use Case: Primary Actor Stake Holders and Interests Preconditions Success Guarantees (Post Conditions) Main Scenario (basic flow) Extensions (alternative flows)



Use Case

Optional Sections Special Requirements Technology and Data Variations List Frequency of Occurrence Open Issues



Use Case

Primary Actor the person that is interacting directly with the

system (entering data and receiving output) Sometimes called the “user”



Use Case

Stakeholders and Interests individuals and entities that have an interest

in the successful completion of the use case Includes the person triggering the event if not

the user Usually people/roles, but can also be

organizations helps to define what should be included in use

case



Use Case

Preconditions a statement describing environmental

conditions that must always be true before beginning the use case scenario example: must have an account with the bank

before you can deposit money



Use Case

Success Guarantees (Post Conditions) State what must be true on successful

completion of the use case Describes what useful function the system

performed and/or what thing of value was delivered to the customer

Describes the system state, data storage, and activities completed



Use Case

Main Success Scenario (basic flow) numbered steps describing both user and

system behavior and interaction interactions validation state changes

write in third person (sports announcer)



Use Case

Extensions (Alternative Flows) Similar format as main success scenario Identifies what to do when there is a problem

or failure in main success scenario Numbers correspond to step in main success

scenario



Use Case

Special Requirements Identifies any non-functional requirements,

quality / performance attributes, or other constraint language time constraints business rules



Use Case

Technology and Data Variations List known technology requirements

operating system input/output devices ie: scanner, bar code, etc. interfaces / links



Exercise 1 – Full Dress Use Case

Write a “full-dress” use case for withdrawing funds from a bank ATM



WHICH USE CASES SHOULD YOU DEVELOP FIRST?



Ranking Use Cases

In iterative development, you develop ( the most critical use cases first find out early about critical problems

can cancel with minimal investment more schedule/budget flexibility when

complicated parts of system are done early later project cost /schedule estimates will be

more accurate



Ranking Use Cases

Three Criteria Risk Coverage Criticality



Use Case Risk

Technical Risk cutting edge technology not a lot of in-house expertise

Scope Risk size of effort

Cost Risk cost of hardware/software cost of outside labor/consulting



Use Case Coverage

The number of processes that are impacted by this use case Is this an important pre-condition for other use

cases?



Use Case Criticality

The importance of the use case to the overall goals of the system/business If use case describes a process central to the

reason the system is being developed, it is more critical



Ranking Matrix


Use Case Risk Coverage Criticality Total

Check out Book

3 6 8 17

Search Catalog

3 2 2 7


USE CASE DIAGRAM



Use Case Diagram

System is shown as a hollow rectangle Use cases are shown as labeled ovals

inside the rectangle Actor(s) are shown as stick figures on the

left of the rectangle Supporting actors are shown as stick

fingers on the right of the rectangle.



Use Case Diagram Use Case

Diagram



Use Case DiagramSystem

Sell Item Reorder Inventory

Ship Item



INTERACTIVE QUESTIONS 16 & 17


Use Case Diagram


Exercise 2 – Use Case Diagram

Prepare a Use Case Diagram showing three basic banking functions: deposit withdrawal balance enquiry



DOMAIN MODEL



Domain Model

Represents real thing (not software class)

Class diagram structure: Name Attributes Associations

name (may have a reading arrow) multiplicity



Domain Class

-name-address-e-mail-major-idNumber

Student


Name

Attributes


Domain Model


Student

-name-department-phone-empID-rank

Professor

0..* 0..*

Is Taught By4


Association Name

Multiplicity

Association

Reading Arrow


Multiplicity Indicates how many instances of

an object can be associated with a single instance of another


Student

-name-department-phone-empID-rank

Professor

0..* 0..*

Is Taught By4


One student is associated with 0 to many professorsOne professor is associated

with 0 to many students


INTERACTIVE QUESTION 18


Multiplicity


Domain Model

Use Category List to help identify domain objects physical objects places transactions people roles organizations events collections of things containers of things



Domain Model

Nouns in use cases and other documents are often important objects Use case Event tables Other analysis artifacts



Domain Model

Naming objects Use existing names within the problem

domain Exclude features not related to problem Do not add things that do not currently exist



Domain Model

Associations (connecting lines) relationship between conceptual classes that

is meaningful or significant relationship that needs to be preserved over

some time duration show only those that you know are important inherently bi-directional can have multiplicity (cardinality)



Composition

Strong (mandatory) relationship Whole cannot exist without the parts Example:

Computer processor motherboard memory power supply



Aggregation

Weaker relationship (optional) Whole can exist without all the parts Example:

Computer Floppy drive Mouse



Generalization / Specialization

Sometimes called “inheritance” Child classes are specific instances of

parent class Child classes possess all attributes of

parent Is-A type relationship



Domain Model

Attributes logical data values should be simple (primitive) are similar to variables in class diagrams should not be used as “foreign keys”



Domain Model

Process: identify classes add associations add attributes





Real World Objects


EXERCISE 3


Write a domain model for a bank


SYSTEM DESIGN



System Design Artifacts

Feature Design Prototype GUI Windows Detailed Specification

Scenarios System specifications

Software Design (UML) Robustness Diagram Interaction Diagrams Class Diagrams


Planner, Designer or Program Manager

Systems Analyst, Software Engineer

or Programmer


PROTOTYPE INTERFACES



Prototype Interfaces

Based on a use case Is a “feature” in the system Highest ranked features are developed

first Can be drawn by hand

Or use Visual Studio or Visio



Prototype Catalog Search


Select Search Type

Enter Search Words

Search

List Box

Text Field

Button

Results Window

Text Area


ROBUSTNESS ANALYSIS



Robustness Analysis

Links your interfaces with software logic Not a formal part of the UML Shows how data moves between

interfaces and entity classes



Boundary Objects

Represent GUI Components

Can interact with Actors Can interact with Control

Objects Cannot directly interact

with Entity Objects



Control Objects

Represent methods Can interact with Boundary

Objects Can interact with Entity

Objects Can interact with other

Control Objects Cannot interact with Actors



Entity Objects

Represent software classes

Represent real-world concepts

Supply or store data Can only interact with

Control Objects



INTERACTIVE QUESTION 20 & 21


Boundary Rules


Robustness Interactions

Show how Control Objects move data between Boundary Objects and Entity Objects

Arrow shows the direction that data is moving

Customer Info Window

CustomerGet Customer Info



Sample Robustness Diagram

Patron

Search Type List Box

Keyword Text Field

Search Button

Catalog

Results Window

Search Catalog

Display Results



INTERACTION DIAGRAMS



Interaction Diagrams

Illustrates how instances of software classes interact via “messages” A message is sent to a class instance in

order to make it fulfill one of its “responsibilities” Usually method calls

set methods get methods constructor methods (<<create>>) query operations input / output operations



Interaction Diagram

Notation for instances is slightly different than class notation name is preceded by a colon name is underlined static methods should be sent to the class

(name not underlined)



Interaction Diagram

Two Kinds: Sequence

Diagram

Collaboration Diagram

Object1 Object2 Object3

Top Package::Actor1

onClick()

getData(no)

performFunction(fno)

ObjectA

ObjectC

ObjectB

Top Package::ActorA

2. performFunction(fno)

1. getData(no)onClick()



Sequence Diagram

Messages flow from top to bottom in the order they would be sent in the use case

Object1 Object2 Object3

Top Package::Actor1

onClick()

getData(no)

performFunction(fno)


Time


Sequence Diagram Example:



Messages

Actor1

Object1

click

Object Object

getData(parameter)

returnValue


Three kinds of messages


Sequence Diagram

Message Notation return :=message(parameter: parameter

type) : return type example:

amount:=getDepositAmount(transNo: int) :double

or more simply: getDepositAmount(transNo) create



Sequence Diagram

Returns can optionally be modeled by a dashed arrow can be labeled to show what is being

returned



Sequence Diagram

Process: Select use case (see use case ranking) Examine robustness diagram for the boundary

classes and entity classes Add pure fabrication classes as needed

refer to software design patterns (ie: Expert, Controller, Pure Fabrication)

Decide where operations go and add messages to perform the indicated operations



Sequence Diagram

Process (continued) Draw classes (instances) from left-to-right

from most highly-coupled to least coupled controller classes should be furthest left



INTERACTIVE QUESTIONS 22-24



Exercise 4

Practice individually making a sequence diagrams using Visio based on Robustness Diagram you created in previous exercise.



INTERACTION DIAGRAMS


Collaboration Diagrams



Similar notation as sequence diagram with some minor differences arranged in “network” structure instances (or classes) are connected by a link

(line) messages are located on the link

link can have multiple messages messages are numbered (except first

incoming)




Example

Actor1

InputWindow

Button Data Class

1. enter data

2. on click

3. g

etD

ata(

)

4. calcResult(data)




Associations in collaboration diagrams can have multiple messages

Object1 Object2

1. calcResult()2. getData(no)




Process: Draw classes (instances) on diagram with

most highly-coupled on the top left to least coupled on lower right controller classes should be furthest left locate classes that collaborate close to each other

Draw association lines (hint: no arrow heads or messages on associations)

Examine methods in class diagram and create numbered messages that would invoke those methods



Exercise 5

Individually practice making a collaboration diagram using Visio using the robustness diagram (or sequence diagram) from the prior exercise.



CLASS DIAGRAMS


Specifying Software Classes


Class Diagrams

Illustrates the specifications for software classes and interfaces

Shows the final (static) design of the software

Can show multiple use cases But can be too complex to be useful



Class Structure

Three sections Class Name Variables Functions/Method

Uses correct syntax for programming language

+setAttributes()+getAttributes()

-idNo-name-address-phone-majorDept

Student



Attribute/Method Visibility

+ means public access - means private access # means protected access public: item is accessible anywhere private

Java: accessible only within the class C++: within the class and its “friends”



Attribute/Method Visibility

Protected C++: accessible by the class and its

subclasses Java: accessible by classes in same package

and subclasses everywhere Package (Java only)

accessible only from classes within the same package





Visibility


Types of Operations

Constructor: initializes an instance Query: returns a value but does not

change the state (variables) of an instance

Update: carries out some action that changes the state of the instance

Destructor: used to delete instances



INTERACTIVE QUESTIONS 26-28


Method Types


Class Attributes/Methods

Values and operations that span multiple instances of objects number of orders cumulative sales

Class attributes and operations are underlined in class diagrams In Java, are preceded by the word static



Associations

relationship between classes in a class diagram represents dependencies between classes in

the implementation components

name reading arrow multiplicities at ends



Associations

+operation1()

-attribute1-attribute2

Class1

+operation1()+operation2()

-attribute1-attribute2-attribute3

Class2

0..1 1..*

uses4


multiplicities

Association

Association Name

NavigationArrow

Reading Direction


Navigation Arrow

Shows which class contains a reference to another class

The calling class points to the class with the method



Secondary Actors as Classes

Shown in class diagram to show how the system interacts with them


<<actor>>Telephone

Agent

<<actor>>Credit Card

Authorization


Class Diagrams

Process: created in parallel with Interaction Diagrams determine scope of the present iteration select classes from the Domain model that are

relevant to the current iteration Draw in a network structure including attributes Add any obvious or missing attributes

Draw navigation based on messages



Class Diagrams

Process: (continued) Add constructor methods Add mutator (“set”) methods Add accessor (“get”) methods Add process methods

calculations input / output GUI/interface



Example Class Diagram



Exercise 6

Individually practice making a class diagram using Visio based on the banking system we have been discussing



Design to Code

Reverse Engineering Looking a source code and making UML

diagrams from the code CASE tools can usually create class diagrams

from source / object code



Exercise 7

With your groups, reverse engineer the instructor-provided Java program and create a sequence diagram and a class diagram



Suggested Books


Japanese Engineer Training (JET)Randy Guthrie – Microsoft Corporation1 UML and the design of...

Documents

Transcript of Japanese Engineer Training (JET)Randy Guthrie – Microsoft Corporation1 UML and the design of...