CS 360 Lecture 6. A model is a simplification of reality We build models to better understand the system being developed. We build models of complex.

SYSTEM MODELING AND THE UNIFIED MODELING LANGUAGE (UML)CS 360

Lecture 6

MODELS FOR REQUIREMENTS ANALYSIS AND SPECIFICATIONA model is a simplification of reality

We build models to better understand the system being developed.

We build models of complex systems because we cannot comprehend such a system in its entirety.

Models can be formal or informal.The more complex a project becomes, the more valuable a formal model becomes.

2

PRINCIPLES OF SOFTWARE MODELINGUML “Unified Modeling Language”

Expresses an idea, not detailed description on functionality. Used to describe a software system at a high level of abstraction.

Serves as a bridge between the requirements specifications and the implementation.

Is process and programming language independent. An industry-standard process for specifying, visualizing, constructing, and documenting information about software systems.

Simplifies the complex process of software design.3

MODELS: DIAGRAMS AND DOCUMENTATION IN UML In UML, a model consists of a diagram and documentation. A diagram is the graphical representation of a set of elements representing components of the software system.

Each diagram is supported by technical documentation that specifies the components represented.

A diagram without documentation is of little value.

4

UML: USE OF GRAPHICAL MODELSMeans of discussion about an existing or proposed system

Way of documenting an existing system Models should be an accurate representation of the system but need not be complete.

Detailed system description that can be used to generate a system implementation Models have to be both correct and complete.

5

TYPES OF UML DIAGRAMSUse Case Diagrams

Interactions between a system and its environmentClass Diagrams

Shows the object classes in the system and the associations between those classes

Sequence Diagrams Interactions between actors and the system, and between system components

State DiagramsShows how the system reacts to internal and external events

6

USE CASE DIAGRAMS (DOCUMENTATION)A use case is a model of the interaction between

External users of a software product (actors) and The software product itself

describes a set of scenarioscaptures user requirementscontract between client and software developers

7

USE CASE DIAGRAMSActors:

A role that a user plays with respect to the system.

Use case: A set of scenarios that describing an interaction between a user and a system.

System boundary: rectangle diagram representing the boundary between the actors and the system. 8

USE CASE DIAGRAMS (LIBRARY)

9

Library System

Borrow

Order Title

Fine

ClientEmployee

Supervisor

BoundaryActor

Use Case

USE CASE DIAGRAMS (FLIGHT CHECK-IN)

10

BoundaryActor

Use Case

CLASS DIAGRAMS (DOCUMENTATION)A class diagram depicts classes and their interrelationshipsUsed for describing structure and behavior in the use cases

Used for requirement capture, end-user interactionDetailed class diagrams are used for developers

Used for communicating software connections/requirements

11

CLASS DIAGRAMSEach class is represented by a rectangle subdivided into three compartments Name Attributes Operations

Modifiers are used to indicate visibility of attributes and operations. ‘+’ is used to denote Public visibility ‘#’ is used to denote Protected visibility ‘-’ is used to denote Private visibility

By default, attributes are hidden and operations are visible.12

CLASS DIAGRAMS (BANK ACCOUNT)

13

Account_Name

- Customer_Name- Balance

+addFunds( )+withDraw( )+transfer( )

Attributes

Operations

Class Name

CLASS DIAGRAMS (SHAPES)

14

Operations

Class Name

Attributes

CLASS DIAGRAMS

15

Subtype2

Supertype

Subtype1

• Inheritance is a required feature of object orientation

• Promotes code reuse and flexability

Regular Customer

Loyalty Customer

Customer Example:

SEQUENCE DIAGRAMS (DOCUMENTATION)Sequence diagrams

Used to model the interactions between the actors and the objects within a system.

Shows interactions of specific use cases.Objects and actors are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by arrows.

16

SEQUENCE DIAGRAMSUsed to model the interactions between the actors and the objects within a system.Shows the sequence of interactions that take place during a particular use case.

Example:User making a phone call

17

SEQUENCE DIAGRAMS (TELEPHONE CALL)

18

Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello

SEQUENCE DIAGRAMS (BOOKING WEBSITE)

19

STATE DIAGRAMS (DOCUMENTATION)Models the behavior of the system in response to external and internal events.

Shows the system’s responses to stimulioften used for modelling real-time systems.

Shows states as nodes, and events as edges between these nodes. When an event occurs, the system moves from one state to another.

20

STATE DIAGRAMS (BILLING EXAMPLE)State Diagrams show the sequences of states an object goes through during its life cycleabstraction of all possible behaviors

21

Unpaid

Start End

Paid

Invoice created

paying

Invoice destroying

STATE DIAGRAMS (TRAFFIC LIGHT EXAMPLE)

22

Yellow

Red

Green

Traffic LightState

Transition

Event

Start

UML DIAGRAMSUML is a standardized specification language for object modeling

Several UML diagrams:Use-case diagram: models the interaction between actors and software

Class diagram: a model of classes showing the static relationships among them.

Sequence diagram: shows the way objects interact with one another as messages are passed between them.

State diagram: shows states, events that cause transitions between states.

23

MODELING TOOLS: PSEUDO-CODE An informal modeling technique to show the logic behind part of a system.

Example: University Admission Decision adminDecision (application)

if application.SAT == null then error (incomplete) if application.SAT > S1 then accept(application) else if application.GPA > G1 then accept(application) else if application.SAT > S2 and application.GPA > G2

then accept(application) else reject(application)

Pseudo-code can be informal, or a standard used by a software development organization, or based on a regular programming language.

What matters is that its interpretation is understood by everybody involved.

24

PROTOTYPING REQUIREMENTSRapid prototyping is the most comprehensive of all modeling methodsSpecifying requirements by building a system that demonstrates the functionality of key parts of the required system

Particularly valuable for user interfaces

25

REQUIREMENTS DEFINITION: DATA DICTIONARYA data dictionary is a list of names used by the system

Name (e.g., "start date") Brief definition (e.g., what is "date") Where is it used (e.g., source, used by, etc.) May be combined with a glossary

As the system is developed, the data dictionary in the requirements is the basis of the system data dictionary, which is part of the final specification.

26

SOFTWARE MODELING: KEY POINTSA model is an abstract view of a system that ignores system details. System models can be developed to show the system’s context, interactions, structure and behavior.

Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the product. Describes interactions between a system and external actors.

Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system.

27