programming logic and design fourth edition, comprehensive chapter 15 system modeling with the uml

Programming Logic and Design

Fourth Edition, Comprehensive

Chapter 15System Modeling with the UML

Programming Logic and Design, Fourth Edition, Comprehensive 2

Objectives

• Understand the need for system modeling

• Describe the UML

• Work with use case diagrams

• Use class and object diagrams

• Use sequence and communication diagrams


Objectives (continued)

• Use state machine diagrams• Use activity diagrams• Use component and deployment diagrams• Diagram exception handling• Decide which UML diagrams to use


Understanding the Need for System Modeling

• Most programs are part of a larger system• System design: detailed 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


Understanding the Need for System Modeling (continued)

• Unified Modeling Language (UML)– Popular design tool– Allows you to break a system into subsystems


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 non-technical in nature


What is UML? (continued)

• UML has 13 diagram types in three major categories:– Structure diagrams– Behavior diagrams– Interaction diagrams

• Each type supports multiple variations



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



• Behavior diagrams– Use case diagrams– Activity diagrams– State machine diagrams

• Interaction diagrams:– Sequence diagrams– Communication diagrams– Timing diagrams– Interaction overview diagrams


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

system’s actors

• Analyze the main events in a system to establish use cases


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



• Stereotype: adds more meaning to the UML vocabulary of shapes – Add “<<extend>>” near the relationship line



• Include variation:– When a case can be part of multiple use cases– Shown with an oval and a dashed arrow


Using Use Case Diagrams (continued)• Generalization variation:

– When you want to substitute a more specific case for a general one

– Use open-headed dashed arrows


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


Using Class and Object Diagrams• Class diagrams:

– Illustrate names, attributes, and methods– Are 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


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



• 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


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


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 on object roles


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


Using State Machine Diagrams (continued)


Using Activity Diagrams

• Activity diagrams:– Resemble flowcharts– Show 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


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• Join:

– Reunites the flow of control after a fork


Using Activity Diagrams (continued)• Time signal:

– Indicates that a specific amount of time has passed before an action is started

– Shaped like an hourglass


Using Component and Deployment Diagrams

• Component diagram:– Used to emphasize files, databases, documents and

components used by a system’s software• Deployment diagram:

– Focuses on a system’s hardware


Using Component and Deployment Diagrams (continued)


Diagramming Exception Handling

• Program code uses try-catch blocks to trap errors and handle them

• Protected node: – A try block in UML– Uses a rounded rectangle– Exceptions that may be thrown are shown as

lightning bolts

• Handler body node: a catch block in UML


Diagramming Exception Handling (continued)


Deciding Which UML Diagrams to Use

• 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


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

• Object diagram models a specific instance of a class at one point in time


Summary (continued)

• 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

• Activity diagram shows the flow of actions

• Use forks and joins to depict simultaneous activities


Summary (continued)

• Component diagram emphasizes the files, database tables, documents and other components in a system

• Each diagram represents a different view of the system

programming logic and design fourth edition, comprehensive chapter 15 system modeling with the uml

Documents