In this Business Analysis Training session you will learn, Introduction to OOA and UML. Topics covered in this session are:
• Sequence Diagram (Cont…)
• Interaction Diagram
• State Diagram
• Activity Diagram
To learn more about this course, visit this link: https://www.mindsmapped.com/courses/business-analysis/foundation-level-business-analyst-training/
4. Page 4Classification: Restricted
Class Roles or Participants
Class roles describe the way an object will behave in context. Use the UML
object symbol to illustrate class roles, but don't list object attributes.
Basic Sequence Diagram Symbols and Notations
5. Page 5Classification: Restricted
Basic Sequence Diagram Symbols and Notations
Activation or Execution Occurrence
Activation boxes represent the time an object needs to complete a task.
When an object is busy executing a process or waiting for a reply message,
use a thin gray rectangle placed vertically on its lifeline.
6. Page 6Classification: Restricted
Basic Sequence Diagram Symbols and Notations
Messages
Messages are arrows that represent communication between objects. Use
half-arrowed lines to represent asynchronous messages. Asynchronous
messages are sent from an object that will not wait for a response from the
receiver before continuing its tasks..
7. Page 7Classification: Restricted
Basic Sequence Diagram Symbols and Notations
Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over
time.
8. Page 8Classification: Restricted
Basic Sequence Diagram Symbols and Notations
Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that
points to an X. This object is removed from memory. When that object's
lifeline ends, you can place an X at the end of its lifeline to denote a
destruction occurrence.
Loops
A repetition or loop within a sequence diagram is depicted as a rectangle.
Place the condition for exiting the loop at the bottom left corner in square
brackets [ ].
9. Page 9Classification: Restricted
Types of Messages in Sequence Diagram
Synchronous Message
A synchronous message requires a response before the interaction can
continue. It's usually drawn using a line with a solid arrowhead pointing
from one object to another.
10. Page 10Classification: Restricted
Types of Messages in Sequence Diagram
Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like
synchronous messages, they are drawn with an arrow connecting two
lifelines; however, the arrowhead is usually open and there's no return
message depicted.
16. Page 16Classification: Restricted
Sequence Diagram : Object interaction
Self-Call: A message that an
Object sends to itself.
Condition: indicates when a
message is sent. The message is
sent only if the condition is true.
Iteration
Condition
A B
Synchronous
Asynchronous
Transmission
delayed
Self-Call
[condition]
remove()
*[for each]
remove()
17. Page 17Classification: Restricted
Sequence Diagrams – Object Life Spans
• Creation
• Create message
• Object life starts at that point
• Activation
• Symbolized by rectangular stripes
• Place on the lifeline where object is
activated.
• Rectangle also denotes when object
is deactivated.
• Deletion
• Placing an ‘X’ on lifeline
• Object’s life ends at that point
Activation
bar
A
B
Create
X
Deletion
Return
Lifeline
19. Page 19Classification: Restricted
The second interaction diagram is collaboration diagram. It shows the
object organization. Here in collaboration diagram the method call
sequence is indicated by some numbering technique.
Collaboration Diagrams
21. Page 21Classification: Restricted
• Shows the relationship between objects and the order of messages passed
between hem.
• The objects are listed as rectangles and arrows indicate the messages being
passed
• The numbers next to the messages are called sequence numbers. They
show the sequence of the messages as they are passed between the objects.
• Convey the same information as sequence diagrams, but focus on object
roles instead of the time sequence.
Interaction Diagrams : Collaboration diagrams
22. Page 22Classification: Restricted
State Diagrams: (Billing Example)
State Diagrams show the sequences of states an object goes through during
its life cycle in response to stimuli, together with its responses and actions;
an abstraction of all possible behaviors.
Unpaid
Start End
Paid
Invoice created paying Invoice destroying
24. Page 24Classification: Restricted
Activity Diagram
Overview
• Activity diagram is another important diagram in UML to describe dynamic
aspects of the system.
• Activity diagram is basically a flow chart to represent the flow form one
activity to another activity. The activity can be described as an operation of
the system.
• So the control flow is drawn from one operation to another. This flow can
be sequential, branched or concurrent. Activity diagrams deals with all type
of flow control by using different elements like fork, join etc.
25. Page 25Classification: Restricted
Purpose of an Activity Diagram
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
32. Page 32Classification: Restricted
UML Modeling Tools
• Rational Rose (www.rational.com) by IBM
• TogetherSoft Control Center, Borland
(http://www.borland.com/together/index.html)
• ArgoUML (free software) (http://argouml.tigris.org/ )
OpenSource; written in java
• Others
(http://www.objectsbydesign.com/tools/umltools_byCompany.html )
33. Page 33Classification: Restricted
Reference
1. UML Distilled: A Brief Guide to the Standard Object Modeling Language
Martin Fowler, Kendall Scott
2. IBM Rational
http://www-306.ibm.com/software/rational/uml/
3. Practical UML --- A Hands-On Introduction for Developers
http://www.togethersoft.com/services/practical_guides/umlonlinecourse/
4. Software Engineering Principles and Practice. Second Edition;
Hans van Vliet.
5. http://www-inst.eecs.berkeley.edu/~cs169/
34. Page 34Classification: Restricted
•Requirements Management
•Requirement Prioritization
•MoSCoW Analysis
•Time Boxing
•Voting Technique
•Verifying and Validating Requirements
•Verifying Requirements
•Validate Requirements
•Key Requirements Management Practices
•The Requirements Baseline
•Requirements Version Management
•Requirements Change Control
•Impact Analysis of Requirements
•Requirements Attributes
•Requirements status tracking
•Requirements Traceability
•Requirements Traceability Matrix
Topics to be covered in next session