1. IMPORTANT NOTICE TO STUDENTS:
These slides are NOT to be used as a replacement for student notes.
These slides are sometimes vague and incomplete on purpose to spark class discussions.
Software models and the Unified Modeling Language (UML) - Behavioral Diagrams
CS 360
Lecture 9

2. Outline What is UML? Behavioral UML Diagrams System Boundary
Use Case Diagram
Use Case Scenarios
Requirements Tracing
Sequence Diagram
State Diagram

3. The Unified Modeling Language
UML:
A general purpose visual modeling
language for software systems.
Designed to incorporate current best
practice in modeling techniques and
software engineering.

4. Behavioral UML Diagrams
Emphasize what must happen in the system being modelled.
Use Case Diagram
Sequence Diagram
State Diagram

5. The System Boundary Define what the system should/should not do:
Shows other systems that use the system
being built.
Identifies where the system begins/ends
System scalability boundaries
System portability boundaries
Defining System Boundaries
Physical – Infrastructure, resources
Logical – data types, interfaces
Social – traditions, behavioral
Economic – use of limited resources,
benefits to society
Political – community concern, legal
issues

6. Team Activity
Discuss and draw diagram(s) representing the system boundaries for your project.
Physical – Infrastructure, resources
Logical – data types, interfaces
Social – traditions, behavioral
Economic – use of limited resources, benefits to society
Political – community concern, legal issues

7. The Use Case Diagram
Graphical visualization of the interactions among the elements of a software system.
Use Case Diagrams always provide:
The System Boundary
Defines the system in relation to external components.
The Actors
Individuals or external components that interact with your system.
The Use Cases
Actions that your system can perform by interacting with internal components and outside actors.
The relationships between Actors and Use Cases.

8. The use case Diagram
Identifying Actors

9. The use case Diagram
Identifying Use Cases

10. The use case Diagram - Example
System
Boundary
4. Relationships
3. Use
Cases
2. Actors

11. Use Case Scenarios Scenarios:
Whenever possible, Use Cases should be kept simple.
Scenarios:
Another way of viewing a Use Case.
Exactly one Primary Scenario per Use Case.
“Scenario where everything goes as planned.”
Zero to many Secondary Scenarios per Use Case.
Captures errors, exceptions, branches, etc. of the main Scenario.

12. Use Cases – Requirements Tracing
With a Requirements Specification document and a set of Use Cases, you effectively have two “databases” of functional requirements.
Requirements tracing can be accomplished by creating a Requirements Traceability Table.
If there’s a req that doesn’t map to any use case, then there is a missing Use Case.
If there is a Use Case that doesn’t map to any req, then the set of reqs is incomplete.
Use Cases
Requirements
UC 001
UC 002
UC 003
UC 004 R1 X R2 R3 R4 R5

13. Team Activity
Discuss and create the initial Actors and Use Cases for your project.
Generate your first Primary Scenario.
Generate a Requirements Traceability Table based on the Use Cases that you have defined and your project Requirements.

14. The Sequence Diagram
Shows Instance and actor interactions arranged in a time sequence.
Sequence Diagrams always provide:
The Instance Symbols
Represents a class, object, or component.
The Actor Symbols
Entities that interact with or are external to the system.
Lifelines
Represents the passage of time as it extends downward. May begin with Instances and/or Actors.
Activation Boxes
Represents the time needed for Instances and/or Actors to complete a task. Also known as Focus Boxes.
Message Symbols
Represents how information is transmitted between Instances and Actors. Solid lines for requests, dashed lines for responses.

15. The Sequence Diagram - Example
1. Instance Symbols
5. Messages
2. Actor
Symbols
3. Lifelines
4. Activation
Boxes

16. The Sequence Diagram
Sequence diagrams can become complex if they’re not bound.
Generally, sequence diagrams are used to show Instance and Actor interactions for specific Use Case Scenarios.

17. Team Activity
Discuss and create the initial Sequence Diagram for the Primary Scenario that you developed earlier.

18. The State Diagram Describes the different states of a software system.
State diagrams can be used to describe the state of individual components, sets of components, or an entire software system.
State Diagrams always:
Identifies important component(s) to be analyzed.
Represents a class, use case, object, subsystem, or entire system.
Identifies the states:
Unique conditions for the identified component(s)
Identifies the events:
Action that can be used to generate a component state change.

19. The State Diagram - Example
1. Components
3. Events
2. States

20. Team Activity
Discuss and create a State Diagram for the user login interface of your project.