Software models and the Unified Modeling Language (UML) CS 560 Lecture 7

Models for requirements analysis and Specification A 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.

Principles of software Modeling UML  “Unified Modeling Language” Used to describe a software system at a high level of abstraction. Serves as a bridge between the requirements specifications and the implementation. Requirements  Design/Model  Implementation Process and programming language independent. Industry-standard process for specifying, visualizing, and documenting information about software systems. Simplifies the complex process of software design.

Models: Diagrams and documentation in UML In UML, a model consists of a diagram and documentation. Diagram: Graphical representation of components used in the software system. Each diagram is supported by technical documentation that specifies the components represented. A diagram without documentation is of little value.

Types of UML Diagrams Use Case Diagrams Interactions between a system and its environment Class 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 Diagrams Shows how the system reacts to internal and external events

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 scenarios Captures user requirements Contract between client and software developers

Use Case Diagrams Actors: Use case: System boundary: 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.

Use Case Diagrams (Library) Boundary Actor Library System Borrow Library Clerk Book Borrower Order Title Fine Library Supervisor

Use Case Diagrams (Flight check-in) Boundary Actor

Class Diagrams (Documentation) A class diagram depicts classes and their interrelationships Used for describing structure in the use cases Used for requirement capture, end-user and component interaction Detailed class diagrams are used for developers Used for communicating software connections/requirements

Class Diagrams Each 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 (most) operations are visible.

Class Diagrams (bank account) Account_Name - Customer_Name - Balance +addFunds( ) +withDraw( ) +transfer( ) Attributes Class Name Operations

Class Diagrams Inheritance is a required feature of object orientation Supertype Example: Customer Regular Customer Loyalty Customer Subtype1 Subtype2 Inheritance is a required feature of object orientation Promotes code reuse and flexibility

Class Diagrams (shapes) Class Name Attributes Operations

Sequence Diagrams (Documentation) Used 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. Actors and components are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by arrows. Can be used to show time information/constraints

Sequence Diagrams (Telephone Call) Lifelines Caller Phone Recipient Message Picks up Dial tone Timing Constraint Dial Ring notification Ring Picks up Hello

Sequence Diagrams (Booking Website) Execution Specification

State Diagrams (documentation) Models the behavior of the system in response to external and internal events. Shows the system’s responses to stimuli often used for modeling real-time systems/components. Shows states as nodes, and events as edges between these nodes. When an event occurs, the system moves from one state to another.

State Diagrams (Traffic Light Example) Start Traffic Light State Red Transition Yellow timer expires Yellow Car trips sensor Green timer expires Green Event

Reliable data transfer sender rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L L Wait for call 0from above Wait for ACK0 timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer Wait for ACK1 Wait for call 1 from above timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L Transport Layer

Modeling tools: pseudo-code (Documentation) 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.

Modeling tools: pseudo-code (Documentation) Example: Selection Sort for i  to n – 1 do min  i for j  i to n - 1 do if A[j] < A[min] then end for if min != i then swap A[i], A[min]

Prototyping models Prototyping is the most comprehensive of all modeling methods Validating requirements by building a system that demonstrates the functionality of key parts. Needs for software prototyping: Assess and better understand the requirements. Test feasibility without building the entire system. Allow stakeholders to be involved during design phase. Provides progress visibility.

Prototyping phases (Documentation)

Types of Prototyping Throw-away prototyping: Evolutionary prototyping: Objective: Provides a better understanding of poorly understood requirements. Demonstrate prototype with stakeholders to develop more detailed requirements documentation. Evolutionary prototyping: Deliver a working subsystem with detailed requirements documentation. Components are developed incrementally so that they can be modified based on feedback from stakeholders. Operational prototyping: Integration of throw-away and evolutionary prototyping.

Data dictionary (Documentation) Set of information describing content, format, and structure of data. Name (e.g., “vCounter") Brief definition (e.g., what is “vCounter") Where is it used (e.g., source, used by, etc.) How can it be modified? Exception handling May be combined with a glossary

Data dictionary