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

2. 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.

3. 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.

4. 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.

5. 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

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

7. 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.

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

9. Use Case Diagrams (Flight check-in)
Boundary
Actor

10. 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

11. 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.

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

13. 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

14. Class Diagrams (shapes)
Class Name
Attributes
Operations

15. 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

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

17. Sequence Diagrams (Booking Website)
Execution
Specification

18. 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.

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

20. 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

21. 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.

22. 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]

23. 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.

24. Prototyping phases (Documentation)

25. 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.

26. 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

27. Data dictionary