Programming Logic and Design Fifth Edition, Comprehensive

1
Programming Logic and Design Fifth Edition,
Comprehensive

• Chapter 13
• System Modeling with the UML

2
Objectives

• Understand the need for system modeling
• Be able to describe the UML
• Understand use case diagrams
• Understand class and object diagrams
• Understand sequence and communication diagrams

3
Objectives (continued)

• Understand state machine diagrams
• Understand activity diagrams
• Understand component and deployment diagrams
• Be able to diagram exception handling
• Be able to decide when to use the UML and which
  UML diagrams to use

4
Understanding the Need for System Modeling

• Most programs are part of a larger system
• System design specification of how all parts of
  the system are implemented and coordinated
• Some guidelines
• Large systems are easier to understand when
  broken down into subsystems
• The larger the system, the more important are
  modeling techniques
• Good models promote communication in the
  development team

5
Understanding the Need for System Modeling
(continued)

• Unified Modeling Language (UML)
• Popular design tool
• Allows you to break a system into subsystems
• Hides implementation details
• Means for programmers and businesspeople to
  communicate about system design
• Plan division of responsibilities

6
What is UML?

• UML
• Standard way to specify, construct, and document
  systems
• Modeling language, not a programming language
• Creates top-view diagrams of business processes
• Designed to be nontechnical in nature

7
What is UML? (continued)

• UML has 13 diagram types in three major
  categories
• Structure diagrams
• Behavior diagrams
• Interaction diagrams
• Each type supports multiple variations

8
What is UML? (continued)

• Structure diagrams
• Class diagrams
• Object diagrams
• Component diagrams
• Composite structure diagrams
• Package diagrams
• Deployment diagrams

9
What is UML? (continued)

• Behavior diagrams
• Use case diagrams
• Activity diagrams
• State machine diagrams
• Interaction diagrams
• Sequence diagrams
• Communication diagrams
• Timing diagrams
• Interaction overview diagrams

10
Using Use Case Diagrams

• Use case diagram
• Shows how a business works from the perspective
  of someone outside the business
• Includes users (employees, customers, suppliers)
• Represents only the functions that are visible to
  the systems actors
• Analyze the main events in a system to establish
  use cases

11
Figure 13-1 Use case diagram for librarian
12
Using Use Case Diagrams (continued)

• Each use case has at least one main scenario, but
  may also have more that are variations
• Three variations in use cases
• Extend
• Include
• Generalization
• Extend variation
• Shows functions beyond those in the base case
• Usually an optional activity

13
Figure 13-2 Use case diagram for librarian with
scenario extension
14
Using Use Case Diagrams (continued)

• Stereotype adds more meaning to the UML
  vocabulary of shapes
• Add ltltextendgtgt near the relationship line
• Include variation
• When a case can be part of multiple use cases
• Shown with an oval and a dashed arrow
• Generalization variation
• When you want to substitute a more specific case
  for a general one
• Use open-headed dashed arrows

15
Figure 13-3 Use case diagram for librarian using
stereotype
16
Figure 13-4 Use case diagram for librarian using
include relationship
17
Figure 13-5 Use case diagram for librarian with
generalizations
18
Using Use Case Diagrams (continued)

• Use case diagrams may show multiple actors
• Use case diagrams are only tools to aid
  communication
• Keep them visually pleasing and not overcrowded
• Use separate diagrams for different points of
  view
• Might emphasize actors and their relationships
• Might emphasize actions and hide some of the
  specific actors to keep it simple

19
Figure 13-6 Use case diagram for librarian with
multiple actors
20
Figure 13-7 Use case diagram emphasizing actors
21
Figure 13-8 Use case diagram emphasizing system
requirements
22
Using Class and Object Diagrams

• Class diagrams
• Illustrate names, attributes, and methods
• More useful to programmers than users
• Class diagram is a rectangle with three sections
• Top name of the class
• Middle names of attributes
• Bottom names of methods

Figure 13-9 Book class diagram
23
Using Class and Object Diagrams (continued)

• Use generalizations with class diagrams to show
• More general (parent) classes
• More specific (child) classes that inherit
  attributes from parents
• Association relationship
• Describes the connection between objects
• May include information about arithmetic
  relationships such as cardinality or multiplicity
• Shown with a straight line between classes

24
Figure 13-10 LibraryItem class diagram showing
generalization
25
Figure 13-11 Class diagram with association
relationship
26
Figure 13-12 Class diagram with several
association relationships
27
Using Class and Object Diagrams (continued)

• Whole-part relationship
• One or more classes make up the parts of a larger
  whole class
• Also called an aggregation
• Use open diamond at the whole part end of the
  line
• Represents a has-a relationship
• Object diagram
• Models specific instances of classes
• Shows a snapshot of an object at one point in
  time
• Can use class diagrams or object diagrams
  interchangeably to suit your needs

28
Figure 13-13 Class diagram with whole-part
relationship
29
Figure 13-14 Object diagram for Library
30
Using Sequence and Communication Diagrams

• Sequence diagram
• Shows timing of events in a single use case
• Horizontal axis represents objects
• Vertical axis represents time
• Vertical dashed line from x-axis to object shows
  period of time that the object exists
• Horizontal arrows show communication between
  objects over time

31
Figure 13-15 Sequence diagram for checking out a
Book for a Patron
32
Using Sequence and Communication Diagrams
(continued)

• Communication diagram
• Emphasizes the organization of objects in a
  system
• Contains sequence numbers to show the precise
  order in which activities occur
• Focus is on object roles

33
Figure 13-16 Communication diagram for Book class
34
Using State Machine Diagrams

• State machine diagram
• Shows the different statuses of a class or object
  at different points in time
• Use rounded rectangles for each state and labeled
  arrows to show sequence of events that affect the
  state
• Solid dot indicates start and stop states for a
  class or object

35
Figure 13-17 State machine diagram for checking
out a Book for a Patron
36
Using Activity Diagrams

• Activity diagram
• Resembles a flowchart
• Shows flow of actions in the system
• Use flowchart start and stop symbols (lozenges)
  to describe actions
• Use solid dots to show start and stop states
• Use diamonds for decisions, with possible
  outcomes shown along the branches

37
Figure 13-18 Activity diagram showing branch
38
Using Activity Diagrams (continued)

• Forks and joins
• Used to show simultaneous activities
• Indicated by thick straight lines
• Fork
• Defines a branch in which all paths are followed
  simultaneously

39
Using Activity Diagrams (continued)

• Join
• Reunites the flow of control after a fork
• Time signal
• Indicates that a specific amount of time has
  passed before an action is started
• Shaped like an hourglass

40
Figure 13-19 Activity diagram showing fork and
join
41
Figure 13-20 A time signal starting an action
42
Using Component and Deployment Diagrams

• Component diagram
• Used to emphasize files, databases, documents,
  and components used by a systems software
• Deployment diagram
• Focuses on a systems hardware

43
Figure 13-21 Component diagram
44
Figure 13-22 Deployment diagram
45
Diagramming Exception Handling

• Program code uses try-catch blocks to trap errors
  and handle them
• Protected node
• A try block in UML
• Use a rounded rectangle
• Exceptions that may be thrown are shown as
  lightning bolts
• Handler body node a catch block in UML

46
Figure 13-23 Exceptions in the Book check-out
activity
47
Deciding Which UML Diagrams to Use

• UML widely recognized modeling standard
• Criticisms of UML
• Size UML too large and complex
• Many diagrams infrequently used
• Several are redundant
• Imprecision UML a combination of rules and
  English
• Problems when diagrams applied to tasks not
  implemented in OO languages
• Complexity UML relatively difficult to learn

48
Deciding Which UML Diagrams to Use (continued)

• Each type of UML diagram provides a different
  view of a system
• No view is superior to the others
• Most complete picture is achieved by several
  views
• UML diagrams are a communication tool

49
Summary

• UML allows programmers and businesspeople to
  communicate about system design
• UML has 13 diagram types
• Use case diagram shows how business works from
  the standpoint of those who use the business
• Class diagram illustrates the names, attributes,
  and methods of a class or set of classes

50
Summary (continued)

• Object diagram models a specific instance of a
  class at one point in time
• Sequence diagram shows the timing of events in a
  single use case
• Communication diagram shows the organization of
  objects in a system
• State machine diagram shows status of a class or
  object at a specific point in time

51
Summary (continued)

• Activity diagram shows the flow of actions
• Use forks and joins to depict simultaneous
  activities
• Component diagram emphasizes the files, database
  tables, documents, and other components
• Each diagram represents a different view of the
  system