Unified Modeling Language

1
Unified Modeling Language

• UML and the design of Object-Oriented Information
  Systems
• Professor Randy Guthrie

2
About Your Instructor
3
Your Instructor

• 15 Years Industry Experience
• Contract Administrator
• Project Manager
• Financial Analyst
• 9 Years University Teaching Experience
• 1 Year with Microsoft Corporation

4
Your Instructor

• My Family
• Married 29 years
• Six Children
• three married
• Three in college
• one still in school

5
(No Transcript)
6
Where I Live

• Denver, Colorado

7
Colorado
8
My Home in Denver(Winter)
9
Overview
10
Rational Unified Process (RUP)

• Four Stages
• Inception
• Elaboration
• Construction
• Transition

11
RUP - Inception

• Making the business case to management
• High level goals of the project
• Rough estimates of costs benefits
• Rough estimates of resource commitments

12
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

13
RUP - Construction

• Iterative implementation of lower-risk elements
• Preparation for deployment
• Training
• Hardware installation test

14
RUP - Transition

• Beta or limited-release testing
• Deployment

15
RUP Iterations
16
RUP Iterations
17
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

18
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

19
Unified Process
Prototype Screens
Domain Model
Casual / Full Dress Use Case
Unified Process / Iterative Development
Brief Use Cases
Event Analysis
Rank Use Cases
Robustness Diagram
Code and Test
Sequence Diagram
Class Diagram
20
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

21
Analysis Phase

• Exploring the problem domain
• Defining system and problem boundaries
• What is in-scope vs. out-of-scope
• Discovering system requirements

22
Design Phase

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

23
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

24
Analysis and Design

• Are done at the same time
• Most analysis is completed during elaboration
  phase during early iterations

25
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

26
Rational Unified Architecture
27
Rational Unified Architecture
End-user Functionality
Programmers
Logical View
Development View
Scenarios
Process View
Physical View
Integrators Performance Scalability
System Engineers Topology/Communications
28
Logical Architecture

• Supports Functional Requirements
• what services the system should provide to the
  users
• Focus on objects and object classes
• class diagrams

29
Process Architecture

• Specifies non-functional requirements
• performance
• availability
• fault tolerance
• Specifies how functional requirements will be met

30
Development Architecture

• Focuses on how the actual software modules/class
  are organized
• software structure
• Object Oriented or structured
• three-tier architecture

31
Physical Architecture

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

32
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

33
Use Cases

• Stories about how a feature is used to complete a
  task

34
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

35
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

36
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)

37
Use Case

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

38
Use Case

• Primary Actor
• the person that is interacting directly with the
  system (entering data and receiving output)
• Sometimes called the user

39
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

40
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

41
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

42
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)

43
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

44
Use Case

• Special Requirements
• Identifies any non-functional requirements,
  quality / performance attributes, or other
  constraint
• language
• time constraints
• business rules

45
Use Case

• Technology and Data Variations List
• known technology requirements
• operating system
• input/output devices ie scanner, bar code, etc.
• interfaces / links

46
Exercise 1 Full Dress Use Case

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

47
Which use cases should you develop first?
48
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

49
Ranking Use Cases

• Three Criteria
• Risk
• Coverage
• Criticality

50
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

51
Use Case Coverage

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

52
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

53
Ranking Matrix
54
Use Case Diagram
55
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.

56
Use Case Diagram

• Use Case Diagram

57
Use Case Diagram
58
Interactive Questions 16 17

• Use Case Diagram

59
Exercise 2 Use Case Diagram

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

60
Domain Model
61
Domain Model

• Represents real thing (not software class)
• Class diagram structure
• Name
• Attributes
• Associations
• name (may have a reading arrow)
• multiplicity

62
Domain Class
Name
Attributes
63
Domain Model
Reading Arrow
Association Name
Association
Multiplicity
64
Multiplicity

• Indicates how many instances of an object can be
  associated with a single instance of another

One professor is associated with 0 to many
students
One student is associated with 0 to many
professors
65
Interactive Question 18

• Multiplicity

66
Domain Model

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

67
Domain Model

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

68
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

69
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)

70
Composition

• Strong (mandatory) relationship
• Whole cannot exist without the parts
• Example
• Computer
• processor
• motherboard
• memory
• power supply

71
Aggregation

• Weaker relationship (optional)
• Whole can exist without all the parts
• Example
• Computer
• Floppy drive
• Mouse

72
Generalization / Specialization

• Sometimes called inheritance
• Child classes are specific instances of parent
  class
• Child classes possess all attributes of parent
• Is-A type relationship

73
Domain Model

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

74
Domain Model

• Process
• identify classes
• add associations
• add attributes

75
Interactive Question 19

• Real World Objects

76
Exercise 3

• Write a domain model for a bank

77
System Design
78
System Design
Planner, Designer or Program Manager

• Artifacts
• Feature Design
• Prototype GUI Windows
• Detailed Specification
• Scenarios
• System specifications
• Software Design (UML)
• Robustness Diagram
• Interaction Diagrams
• Class Diagrams

Systems Analyst, Software Engineer or Programmer
79
Prototype Interfaces
80
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

81
Prototype Catalog Search
List Box
Select Search Type
Enter Search Words
Text Field
Search
Button
Results Window
Text Area
82
Robustness Analysis
83
Robustness Analysis

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

84
Boundary Objects

• Represent GUI Components
• Can interact with Actors
• Can interact with Control Objects
• Cannot interact with Boundary Objects

85
Control Objects

• Represent methods
• Can interact with Boundary Objects
• Can interact with Entity Objects
• Can interact with other Control Objects
• Cannot interact with Actors

86
Entity Objects

• Represent software classes
• Represent real-world concepts
• Supply or store data
• Can only interact with Control Objects

87
Interactive Question 20 21

• Boundary Rules

88
Robustness Interactions

• Show how Control Objects move data between
  Boundary Objects and Entity Objects
• Arrow shows the direction that data is moving

89
Sample Robustness Diagram
90
Interaction Diagrams
91
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 (ltltcreategtgt)
• query operations
• input / output operations

92
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)

93
Interaction Diagram

• Two Kinds
• Sequence Diagram
• Collaboration Diagram

94
Sequence Diagram

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

Time
95
Sequence Diagram

• Example

96
Messages
Three kinds of messages
97
Sequence Diagram

• Message Notation
• return message(parameter parameter type)
  return type
• example
• amountgetDepositAmount(transNo int) double
• or more simply
• getDepositAmount(transNo)
• create

98
Sequence Diagram

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

99
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

100
Sequence Diagram

• Process (continued)
• Draw classes (instances) from left-to-right from
  most highly-coupled to least coupled
• controller classes should be furthest left

101
Interactive Questions 22-24
102
Exercise 4

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

103
Interaction Diagrams

• Collaboration Diagrams

104
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)

105
Collaboration Diagram

• Example

106
Collaboration Diagram

• Associations in collaboration diagrams can have
  multiple messages

107
Collaboration Diagrams

• 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

108
Exercise 5

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

109
Class Diagrams

• Specifying Software Classes

110
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

111
Class Structure

• Three sections
• Class Name
• Variables
• Functions/Method
• Uses correct syntax for programming language

112
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

113
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

114
Interactive Question 25

• Visibility

115
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

116
Interactive Questions 26-28

• Method Types

117
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

118
Associations

• relationship between classes in a class diagram
• represents dependencies between classes in the
  implementation
• components
• name
• reading arrow
• multiplicities at ends

119
Associations
Association Name
Association
Reading Direction
multiplicities
Navigation Arrow
120
Navigation Arrow

• Shows which class contains a reference to another
  class
• The calling class points to the class with the
  method

121
Secondary Actors as Classes

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

ltltactorgtgt Credit Card Authorization
ltltactorgtgt Telephone Agent
122
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

123
Class Diagrams

• Process (continued)
• Add constructor methods
• Add mutator (set) methods
• Add accessor (get) methods
• Add process methods
• calculations
• input / output
• GUI/interface

124
Example Class Diagram
125
Exercise 6

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

126
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

127
Exercise 7

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

128
Suggested Books