Requirements Model (Analysis Model)

Prachi Shah
IT Dept.
BVM
 Use Case Diagram
“A use case specifies the behavior of a system or a part of a
system, and is a description of a set of sequences of actions,
including variants, that a system performs to yield an observable
result of value to an actor.”

“An actor is an idealization of an external person, process, or

thing interacting with a system, subsystem, or class. An actor
characterizes the interactions that outside users may have with
the system.”
 Use Case Diagram (Cont’d)

A use case is rendered as an ellipse

Register for Courses
in a use case diagram. A use case is
always labeled with its name.
Use Case Diagram (Cont’d)

An actor is rendered as a stick

figure in a use case diagram.
Each actor participates in one or
more use cases.

Student
 Use Case Diagram (Cont’d)
Actors can participate in a generalization relation with other
actors.

Student Person
Use Case Diagram (Cont’d)

Actors may be connected to use cases

only by associations.

Register for Courses

Student
 Use Case Diagram (Cont’d)
Here we have a Student interacting with the Registrar and the
Billing System via a “Register for Courses” use case.

Billing System

Student Register for Courses

Registrar
Use Case
Diagram
(Online
shopping)
Data Flow Diagram
DFD: A diagram about the data flow between
external agents (sources/ sinks) and the processes
and data stores within a system
Key Components:

External
Agent
 General Information System
In general, a system could be viewed as a
single Process

0
Trans
Report
Source Data Information Sink
(Customer) System (Mgmt)

You could have multiple sources and sinks

This generic diagram is called “Context Diagram”
An Example -
A Data Flow Diagram for a Banking System
A Context Diagram
• An overview of an organizational system
that shows the system boundary, sources /
sinks that interact with the system, and the
major information flows between the entities
and the system
• A Context Diagram addresses only one
process.
An Example - a Fast-Food IS
Context Diagram (or 0-level diagram)
 A Systematic Way for Process Modeling
Process Decomposition
In general, a system could be too complex to
understand when viewed as a single Process
 We need a Process Decomposition scheme
i.e., to separate a system into its subsystems
(sub-processes), which in turn could be further
divided into smaller subsystems until the final
subsystems become manageable units
Level-1 Diagram

• A DFD that represents the primary

functional processes in the system at
the highest possible level
• An Example ...
Example
Level 1 Data Flow Diagram
Example - A further decomposition
Level-2 Data Flow Diagram
(for receive & transform order)
Example: RMS Calculating Software

Data- Compute-
items RMS
0

User
result

Context Diagram
 Example: RMS Calculating Software

numbers
Read- Validate-
numbers numbers
1.0 2.0
Valid -
Data- numbers
items error

Compute-
Display rms
4.0 3.0
User

result RMS

Level 1 DFD
 Example: RMS Calculating Software

Squared-
Calculate- sum Calculate-
squared-sum mean
3.1 3.2

Valid -
numbers Mean-
Calculate- square
root
User 3.3

RMS

Level 2 DFD
 Example: RMS Calculating Software
a b c

Square Square Square

3.1.1 3.1.2 3.1.3

sq(a) sq (b)
sq (c)
Sum
3.1.4

Squared-sum

Level 3 DFD
 E-R Diagram: Basic Concepts
• Entity set – an abstraction of similar things,
e.g. cars, students
– An entity set contains many entities
• Attributes: common properties of the entities
in a entity sets
• Relationship – specify the relations among
entities from two or more entity sets
An Example
 Relationship
• The degree of a relationship = the number of
entity sets that participate in the relationship
• Mostly binary relationships
• Sometimes more
• Mapping cardinality of a relationship
• 1 –1
• 1 – many
• many – 1
• Many-many
1- many
Many - 1
Many - many
Alternative Cardinality Specification
 Total Participation
• When we require all entities to participate in the
relationship (total participation), we use double lines to
specify
• Every loan has to have at least one customer
 Self Relationship
• Sometimes entities in a entity set may relate to
other entities in the same set. Thus self relationship
• Here employees mange some other employees
• The labels “manger” and “worker” are called roles
of the self relationship
 More examples on self-relationship
• People to people
– Parent – children
– Manager – employee
– Husband – wife
• Word to word
– Root – synonym
 Attributes
• Both entity sets and relationships can have
attributes
• Attributes may be
– Composite
– Multi-valued (double ellipse)
– Derive (dashed ellipse)
Another Example
Ternary Relationship
Converting Ternary to binary
 Weak Entity Set
• Some entity sets in real world naturally
depend on some other entity set
– They can be uniquely identified only if
combined with another entity set
• Example:
– section1, section2, … become unique only if
you put them into a context, e.g. csce4350
 Weak Entity Set Notations
 Double rectangles for weak entity set
 Double diamond for weak entity relationship
 Dashed underscore for discriminator
 Specialization
• A lower-level entity set inherits all the attributes
and relationship participation of the higher-level
entity set to which it is linked.
• A lower-level entity set may have additional
attributes and participate in additional relationships
 Specification
• Disjoint
• Completeness constraint (use double lines)
– total : an entity must belong to one of the lower-
level entity sets
– partial: an entity need not belong to one of the
lower-level entity sets
Notations
Notations
 ER Practice
• Design an ER diagram for an online music
store. The database will contain at least the
following concepts: songs, artists, bands,
albums, and genres.
 Class Diagram
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a
rectangle, usually including its name,
operations attributes, and operations in separate,
designated compartments.
 Class Names
The name of the class is the only required
ClassName tag in the graphical representation of a
class. It always appears in the top-most
attributes compartment.

operations
 Class Attributes

Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled.
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.
 Class Attributes (Cont’d)
Attributes are usually listed in the form:

Person attributeName : Type

name : String A derived attribute is one that can be

address : Address computed from other attributes, but
birthdate : Date doesn’t actually exist. For example,
/ age : Date a Person’s age can be computed from
ssn : Id his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/ age : Date
 Class Attributes (Cont’d)

Person
Attributes can be:
+ name : String
+ public
# address : Address
# protected
# birthdate : Date
- private
/ age : Date
/ derived
- ssn : Id
 Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play
 Class Operations (Cont’d)

PhoneBook

newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)

getPhone ( n : Name, a : Address) : PhoneNumber

You can specify an operation by stating its signature: listing the

name, type, and default value of all parameters, and, in the case of
functions, a return type.
 Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.

Person Person Person

name : String
birthdate : Date
Person ssn : Id
name Person eat()
address sleep()
birthdate eat work()
play play()
 Class Responsibilities
A class may also include its responsibilities in a class diagram.

A responsibility is a contract or obligation of a class to perform

a particular service.

SmokeAlarm

Responsibilities

-- sound alert and notify guard station

when smoke is detected.

-- indicate battery state

 Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations

• associations
 Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.

CourseSchedule
Course
add(c : Course)
remove(c : Course)
Generalization Relationships

Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student
Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.

Student Employee

TeachingAssistant
 Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.

An association denotes that link.

Student Instructor
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*
Association Relationships (Cont’d)

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*
Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*
Association Relationships (Cont’d)
We can also name the association.

membership
Student Team
1..* 1..*
Association Relationships (Cont’d)
We can specify dual associations.

member of
1..* 1..*
Student Team
1 president of 1..*
Association Relationships (Cont’d)
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking
the operations of) the server. The direction of the association
indicates that the server has no knowledge of the Router.

Router DomainNameServer
Association Relationships (Cont’d)
Associations can also be objects themselves, called link classes
or an association classes.

Registration
modelNumber
serialNumber
warrentyCode

Product Warranty
Association Relationships (Cont’d)
A class can have a self association.

next

LinkedListNode
previous
Association Relationships (Cont’d)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between an

aggregate (a whole) and a constituent part, where the part can
exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission
Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *
 Another example

Whole Class
Class W Association
Models the part–whole relationship

Composition
Class P1 Class P2 Also models the part–whole relationship but, in
addition, Every part may belong to only one
whole, and If the whole is deleted, so are the
Part Classes parts
[From Dr.David A. Workman]
Example Example:
A number of different chess boards: Each square
belongs to only one board. If a chess board is
thrown away, all 64 squares on that board go as
well.

Figure 16.7
 Interfaces

An interface is a named set of

operations that specifies the behavior
of objects without showing their inner
<<interface>>
structure. It can be rendered in the
ControlPanel
model by a one- or two-compartment
rectangle, with the stereotype
<<interface>> above the interface
name.
 Interface Services

<<interface>> Interfaces do not get instantiated.

ControlPanel They have no attributes or state.
Rather, they specify the services
getChoices : Choice[] offered by a related class.
makeChoice (c : Choice)
getSelection : Selection
Interface Realization Relationship
A realization relationship
<<interface>>
connects a class with an
ControlPanel
interface that supplies its
specifier behavioral specification. It is
rendered by a dashed line with
a hollow triangle towards the
specifier.
implementation

VendingMachine
 Interfaces
inputStream

FileWriter
{file must not be locked}

A class’ interface can also be

rendered by a circle
File
connected to a class by a
solid line.

{file must exist}

FileReader
outputStream
 Packages

A package is a container-like element

for organizing other elements into
groups.
A package can contain classes and
Compiler
other packages and diagrams.
Packages can be used to provide
controlled access between classes in
different packages.
 Packages (Cont’d)
Classes in the FrontEnd package and classes in the BackEnd
package cannot access each other in this diagram.

Compiler

FrontEnd BackEnd
 Packages (Cont’d)
Classes in the BackEnd package now have access to the classes
in the FrontEnd package.

Compiler

FrontEnd BackEnd
 Packages (Cont’d)

We can model generalizations and

Compiler dependencies between packages.

JavaCompiler Java
Cardinality in Class diagram
Class diagram for
Banking system
Class diagram for
Shopping system
 Activity Diagram
• An activity diagram is essentially a flowchart, showing
the flow of control from activity to activity.
• Use activity diagrams to specify, construct, and
document the dynamics of a society of objects, or to
model the flow of control of an operation.
• Whereas interaction diagrams emphasize the flow of
control from object to object, activity diagrams
emphasize the flow of control from activity to activity.
• An activity is an ongoing non-atomic execution within
a state machine.
 Activity Diagram – example 1
Receive
Order

Multiple Trigger

for each line

* item on order

Check
Cancel Authorize
Line
Order [failed]
Payment
Item

[succeeded] [in stock]

Assign to
Order

Synchronization Condition

[need to
reorder] Reorder
Item
[stock assigned to
all line items and
payment authorized]

Dispatch
Order
 Activity diagram
(Online shopping)
Activity diagram for
 State Diagram
• “The state diagram describes the dynamic behavior of objects
over time by modeling the lifecycles of objects of each class.
• Each object is treated as an isolated entity that communicates with
the rest of the world by detecting events and responding to them.
• Events represent the kinds of changes that objects can detect...
Anything that can affect an object can be characterized as an
event.”
• An object must be in some specific state at any given time during
its lifecycle.
• An object transitions from one state to another as the result of
some event that affects it.
• There can be only one start state in a state diagram, but there may
be many intermediate and final states.
State Diagram symbols
start state final state

simple state

concurrent composite state

sequential composite state

 State Diagram – example 1
download course offerings downloading
unscheduled
make a course selection

selecting

make a different selection verify selection

verifying
select another course

check schedule
sign schedule
checking schedule

scheduled
State diagram (Online shopping)
Activity Diagram

State Diagram
 Sequence Diagram
A sequence diagram is an interaction diagram that emphasizes
the time ordering of messages. It shows a set of objects and the
messages sent and received by those objects.

Graphically, a sequence diagram is a table that shows objects

arranged along the X axis and messages, ordered in increasing
time, along the Y axis.
 Sequence Diagram
an Order Line

An object in a sequence diagram is rendered

as a box with a dashed line descending from it.
The line is called the object lifeline, and it
represents the existence of an object over a
period of time.
 Sequence Diagram
an Order Line a Stock Item

Messages are rendered as horizontal

check() arrows being passed from object to
[check = “true”] object as time advances down the
remove()
object lifelines. Conditions ( such as
[check = “true”] ) indicate when a
message gets passed.
 Sequence Diagram
an Order Line a Stock Item

check()

[check = “true”]
Notice that the bottom arrow is different.
remove() The arrow head is not solid, and there is
no accompanying message.

This arrow indicates a return from a

previous message, not a new message.
 Sequence Diagram
an Order a Order Line

* prepare()
An iteration marker, such as * (as
shown), or *[i = 1..n] , indicates
that a message will be repeated as
Iteration indicated.
marker
 Sequence Diagram Example 1
an Order Entry
an Order an Order Line a Stock Item
window
prepare()
Condition
* prepare()
Object
check()

Message [check = “true”]

remove() needsToReorder()
Iteration
Return Self-Delegation
[needsToReorder = “true”]
new
A Reorder
Item
[check = “true”]
A Delivery
new
Item

Creation
Sequence
diagram
(Online
shopping)
Swim-lane
diagram
 Collaboration Diagram
A collaboration diagram emphasizes the relationship of the
objects that participate in an interaction. Unlike a sequence
diagram, you don’t have to show the lifeline of an object
explicitly in a collaboration diagram. The sequence of events are
indicated by sequence numbers preceding messages.
Object identifiers are of the form objectName : className, and
either the objectName or the className can be omitted, and the
placement of the colon indicates either an objectName: , or a
:className.
 Collaboration vs Sequence
Diagram

Both a collaboration diagram and a sequence diagram derive

from the same information in the UML’s metamodel, so you can
take a diagram in one form and convert it into the other. They
are semantically equivalent.
 Collaboration Diagram
: Order Entry Window Object
Sequence Number

1: prepare() Message

: Order Self-Delegation
5: needToReorder()

2*: prepare() 3: check()

4: [check == true] remove()

: Order Line : Stock Item

7: [check == true] new 6: new

:Delivery Item :Reorder Item

• State diagrams are good for modeling the
lifetime of an object or actor, also for
modeling user interfaces and business
processes which involve many states.
• Activity diagrams are good for modeling
business processes and system processes
which involve a lot of concurrency.
• Sequence and collaboration diagrams are
useful for modeling interactions
 CRC Models
Main structure:

Examples:
Another example
Requirements Model (Analysis Model)

Scenario- Class-based Flow-oriented Behavioral

based model model model model

Use cases: Data flow

Class diagrams State diagrams
Text diagrams

Use-case Sequence
CRC models
diagrams diagrams

Activity Collaboration
diagrams diagrams

Swim lane
diagram