Unified Modeling Language - PowerPoint PPT Presentation

Loading...

PPT – Unified Modeling Language PowerPoint presentation | free to view - id: 361dd-OTRlN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Unified Modeling Language

Description:

Unified Modeling Language – PowerPoint PPT presentation

Number of Views:107
Avg rating:3.0/5.0
Slides: 129
Provided by: rwgut
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com