CLASS COMPONE DEPLOYME USE CASE SEQUENCE ACTIVITY

DIAGRAM NT NT DIAGRAM DIAGRAM DIAGRAM

DIAGRAM DIAGRAM
(static view) (use case (sequence of (flow of
(object (​implementatio (​deployment view) messages controls)
oriented) n view) view) (internal/extern among (sequence
(development (components (set of nodes al controllers) objects) from one
purpose) and their and their (high level (capture activity to
relationships) relationships) design) dynamic another)
(hardware behaviour​)
topology)

type -type of -type of -type of structural -type of -type of -type of

structural structural diagram behavioral behavioral behavioral
diagram diagram diagram diagram diagram

Consi -​Class diagram -​Component -​Deployment -​Use case -the ​sequence Activity
sts of consists of diagrams diagrams​ are a diagrams​ are a diagram​ deals diagram
classes, represent a ​set set of nodes and set of use with some consists of
interfaces, of components their cases, actors, sequences, activities and
associations, and their relationships. and their which are the links​. The flow
and relationships. These nodes are relationships. sequence of can be
collaboration. These physical entities messages sequential,
components where the flowing from concurrent, or
consist of components are one object to branched.
classes, deployed. another.
interfaces, or
collaborations.
View -​Class -​Component -represent the -visualize the
in diagrams diagrams use case view flow of
syste basically represent the of a system. controls​ in a
m represent the implementation system
object-oriented view ​of a
view​ of a system.
system, which is
static in nature.

descri -generally used -component -Deployment -describe the -Sequence -Activity

be for diagrams are diagrams are relationships diagram is used diagram
development used to used for among the to ​visualize the describes the
purpose​. This is visualize the visualizing the functionalities sequence of flow of control
the most widely implementation deployment and their calls ​in a in a system.
used diagram at . view​ of a system. internal/extern system to
the time of al controllers. perform a
system These specific
construction. controllers are functionality.
known as
actors​.

purpo -​Analysis​ and -Visualize the -Visualize the -Used to ​gather -To ​capture the -Draw the
se design​ of the components of a hardware the dynamic activity flow of a
static view​ of an system​. topology​ of a requirements ​of behaviour​ of a system.
application. system. a system. system.
-​Construct -Describe the
-Describe executables​ by -Describe the -Used to get an -To describe sequence from
responsibilities using forward hardware outside view of the ​message one activity to
of a system. and reverse components used a system. flow​ in the another.
engineering. to deploy system.
-​Base​ for software -​Identify the -Describe the
component and -​Describe the components. external and -To describe parallel,
deployment organization and internal factors the ​structural branched and
diagrams. relationships of -​Describe the influencing the organization of concurrent flow
the components​. runtime system. the objects. of the system.
-​Forward and processing
reverse nodes. -Show the -To describe
engineering. interaction the ​interaction
among the among objects​.
requirements
are actors​.
Used -​Describing the -Model the -To ​model the -Requirement -To model the -Draw the
for static view​ of components of hardware analysis and flow of control activity flow of
the system. a system. topology​ of a high level by time a system.
system. design. sequence.
-Showing the -Model the -Describe the
collaboration database -To ​model the -Model the -To model the sequence
among the schema. embedded context​ of a flow of control from one
elements of the system​. system. by ​structural activity to
static view. -Model the organizations​. another.
executables​ of -To model the -​Reverse
-Describing the an application. hardware details engineering​. -For ​forward -Describe the
functionalities for a engineering. parallel,
performed by the -Model the client/server -​Forward branched and
system. system's system. engineering. -For ​reverse concurrent
source code. engineering. flow​ of the
-Construction of -To model the system.
software hardware details
applications of a distributed
using ​object application​.
oriented
languages. -For ​Forward
and Reverse
engineering.
CLASS DIAGRAM
COMPONENT DIAGRAM

Component​ - an entity required to execute a stereotype function.

A component provides and consumes behavior through
interfaces, as well as via other components.
- ​Node​ - nodes are hardware or software objects, which are of a
higher level than components. Boxes represent nodes.
- ​Interface​ - show input or materials that a component either
receives or provides. Interfaces can be represented with textual
notes or symbols—such as the the lollipop, socket, and
ball-and-socket shapes.
- ​Port​ - symbolized with a small square, ports specify a separate
interaction point between the component and the environment.
- ​Package​ - groups together multiple elements of the system.
Packages are represented by file folders in Lucidchart. Just as
file folders group together multiple sheets, packages can be
drawn around several components.
- ​Note​ - this allows a developer to affix a meta-analysis to the
component diagram. Notes look like sticky notes.
- ​Dependency​ - shows that one part of your system depends on
another. Dependencies are represented by dashed lines linking
one component (or element) to another.
DEPLOYMENT DIAGRAM

● ​Artifact​ - a product developed by the software, symbolized by a

rectangle with the name and the word “artifact” enclosed by
double arrows.
●​ Association​ - a line that indicates a message or other type of
communication between nodes.
● ​Component​ - a rectangle with two tabs that indicates a software
element.
● ​Dependency​ - a dashed line that ends in a arrow, which indicates
that one node or component is dependent on another.
● ​Interface​ - a circle that indicates a contractual relationship;
those objects that realize the interface must complete some sort
of obligation.
● ​Node​ - A hardware or software object, shown by a
three-dimensional box.
● ​Node as container​ - A node that contains another node inside of
it—such as in the example below, where the nodes contain
components.
● ​Stereotype​ - A device contained within the node, presented at the
top of the node, with the name bracketed by double arrows.

USE CASE DIAGRAM

● ​Actor​ – anyone or anything that performs a behavior (who is using

the system)
● ​Stakeholde​r – someone or something with vested interests in the
behavior of the system under discussion (SUD)
● ​Primary Actor​ – stakeholder who initiates an interaction with the
system to achieve a goal
● ​Preconditions​ – what must be true or happen before and after the
use case runs.
● ​Triggers​ – this is the event that causes the use case to be initiated.
● ​Main success scenarios [Basic Flow]​ – use case in which nothing
goes wrong.
● ​Alternative paths [Alternative Flow]​ – these paths are a variation
on the main theme. These exceptions are what happen when things
go wrong at the system level.
- A use case diagram mainly consists of actors, use cases and
relationships.
- More complex larger diagrams can include systems and boundaries.
We’ll discuss the guidelines based on objects.
- It is important to remember that these are guidelines and not rules. Its
alright to deviate if it improves the overall quality of the diagram
SEQUENCE DIAGRAM

a)​Object Symbol ​:
This box shape represents a class, or object, in UML. They demonstrate
how an object will behave in the context of the system. Class attributes
should not be listed in this shape.
b) ​Activation Box​ :
Symbolized by a rectangle shape, an activation box represents the time
needed for an object to complete a task. The longer the task will take,
the
longer the activation box becomes.
c) ​Actor Symbol​ :
Represented by a stick figure, actors are entities that are both
interactive with and external to the system.
d) ​Package Symbol​ :
Also known as a frame, this is a rectangle shape that is used in UML 2.0
notation to contain interactive elements of the diagram. The shape has a
small inner rectangle for labeling the diagram.
e) ​Lifeline Symbol​ :
A dashed vertical line that represents the passage of time as it extends
downward. Along with time, they represent the sequential events that
occur
to an object during the charted process. Lifelines may begin with a
labeled
rectangle shape or an actor symbol.
f) ​Option Loop Symbol​ :
A rectangle shape with a smaller label within it. This symbol is used to
model "if then" scenarios, i.e., a circumstance that will only occur under
certain conditions.
g) ​Alternative Symbol ​:
Used to symbolize a choice (that is usually mutually exclusive) between
two or more message sequences. To represent alternatives, use the
labeled
rectangle shape with a dashed line inside.
★SEQUENCE MESSAGE SYMBOLS :
Packets of information that are transmitted between
objects. They may reflect the start and execution of an operation, or the
sending and reception of a signal.
a)​ Synchronous Message Symbol :
Represented by a solid line with a solid arrowhead. This symbol
is used when a sender must wait for a response to a message before it
continues. The diagram should show both the call and the reply.
b) ​Asynchronous Message Symbol :
Represented by a solid line with a lined arrowhead.
Asynchronous messages are those that don't require a response before
the sender continues. Only the call should be included in the diagram.
c)​Asynchronous Return Message Symbol :
Represented by a dashed line with a lined arrowhead.
d) ​Asynchronous Create Message Symbol :
Represented by a dashed line with a lined arrowhead. These
messages are sent to lifelines in order to create themselves.
e)​ Reply Message Symbol :
Represented by a dashed line with a lined arrowhead, these
messages are replies to calls.
f) ​Delete Message Symbol :
Represented by a solid line with a solid arrowhead, followed by
an X symbol. This messages indicates the destruction of an object and is
placed in its path on the lifeline.
g) ​Self Message
A message an object sends to itself, usually shown as a U shaped arrow
pointing back to itself.
h) ​Create Message :
This is a message that creates a new object. Similar to a return
message, it's depicted with a dashed line and an open arrowhead that
points
to the rectangle representing the object created.
i) ​Found Message :
A message sent from an unknown recipient, shown by an arrow from
an endpoint to a lifeline.
j)​ Lost Message :
A message sent to an unknown recipient. It's shown by an arrow going
from a lifeline to an endpoint, a filled circle or an x
ACTIVITY DIAGRAM

● Actions - a step in the activity wherein the users or software

perform a given task. This is symbolized with a round-edged
rectangle.
● Decision node - a conditional branch in the flow that is
represented with a diamond. It includes a single input and two or
more outputs.
● Control flows - this is another name for the connectors that show
the flow between steps in the diagram.
● Start node - symbolizes the beginning of the activity. This is
represented with a black circle.
● End node - represents the final step in the activity. It's modeled
with an outlined black circle.
The  ​Unified  Modeling  Language  (​UML​)  is  a  general-purpose  modeling  language  in 
the  field  of  software  engineering,  which  is  designed  to  provide  a  standard  way  to 
visualize  the  design  of  a  system.  This article will discuss about UML Building blocks. 
Basically it consists of 3 components namely, 

1. Things 
2. Relationship 
3. Diagrams 

1. Things
This is the most important part in UML building blocks. Things can be classified as, 

● Structural 
● Behaviour 
● Grouping 
 ● Annotation 

1.1 Structural
Structural things define the stable (static) part of the model. Structural things are 
class, Interface,collaboration, use case, component and node. 

● Classes​ ​are set of objectives which gave similar responsibilities.   

● Interfaces​ are set of operations which specify set of classes. 

● ​Collaborations​ defines connections between elements. 

● Use-case​ describes set of actions performed in a system.   

● Components​ describes the physical parts of the system.  

  

● Nodes​ describes a physical element which has a run time. 

1.2 Behaviour
Consists of all the dynamic parts of the system. 

● Interaction​ – Behaviour that consists of a group of messages exchanged 

among elements. 

● State machine​ – State machine can show the different states of an entity also 
how an entity responds to various events by changing from one state to 
another.  

1.3 Grouping
It is a mechanism to group the elements of UML model.   

● Package – ​Package is the only one grouping thing available for gathering 
structural and behavioral things.  

1.4 Annotation
Annotations  are  used  to  capture  remarks,  descriptions  and  comments  of  UML 
model elements. 

2. Relationship
Relationships  will  show  how  elements  are  connected  and  associated  with  each 
other. There are four (4) types of relationships available. 

● Dependency 
● Association 
● Generalization 
● Realization 

2.1 Dependency
Relationship between 2 things and change in one element affects the other. 

2.2 Association
Set  of  links  that  connect  elements  of  UML.  It  describes  how  many  objects  are 
participating in a particular relationship.  

 
2.3 Generalization
Connects a specialized element with a generalized element. 

2.4 Realization
One element describes some responsibility which is not implemented yet. 

Four Principles of Modeling

● The model you create influences how the problem

is attacked.
● Every model may be expressed at different levels of
precision.
● The best models are connected to reality.No single
model is sufficient.

Principle 1: The ​Choice of Model​ is Important

● The models you create profoundly influence how a
problem is attacked and how a solution is shaped.
● In software, the models you choose greatly affect
your world view.
● Each world view leads to a different kind of system
Principle 2: ​Levels of Precision ​May Differ
● Every model may be expressed at different levels of
precision.
● The best kinds of models let you choose your
degree of detail, depending on:
•Who is viewing the model.
•Why they need to view it.

Principle 3: The Best Models Are ​Connected to

Reality
● All models simplify reality.
● A good model reflects potentially fatal
characteristics.

Principle 4: ​No Single Model Is Sufficient

● No single model is sufficient.
● Every non-trivial system is best approached through
a small set of nearly independent models.
● Create models that can be built and studied
separately, but are still interrelated.
4+1 View Model :

- 4+1 is a view model designed by Philippe Kruchten for

"​describing the architecture of software-intensive
systems, based on the use of multiple, concurrent
views​".
- The views are used to describe the system from the
viewpoint of different stakeholders, such as end-users,
developers and project managers.
- ​The four views of the model are logical,
development,
process and physical view.
- In addition selected use cases or scenarios are used to
illustrate the architecture serving as the 'plus one' view.
- Hence the model contains 4+1 views.
●​ Development view ​:
- The development view illustrates a system from a
programmer's perspective and is concerned with
software
management.
- This view is also known as the implementation view.
- It uses the UML Component diagram to describe
system
components.
- UML Diagrams used to represent the development
view
include the Package diagram.
● ​Logical view :
- The logical view is concerned with the functionality that
the system provides to end-users.
- UML diagrams used to represent the logical view
include,
class diagrams, and state diagrams.
● ​Physical view :
- The physical view depicts the system from a system
engineer's point of view.
- It is concerned with the topology of software
components
on the physical layer as well as the physical connections
between these components.
- This view is also known as the deployment view.
- UML diagrams used to represent the physical view
include
the deployment diagram.
● ​Process view ​:
- The process view deals with the dynamic aspects of
the
system, explains the system processes and how they
communicate, and focuses on the runtime behavior of
the
system.
- The process view addresses concurrency, distribution,
integrators, performance, and scalability, etc. UML
diagrams to represent process view include the activity
diagram.
● ​Scenarios OR Use Case :
- The description of an architecture is illustrated using a
small set of use cases, or scenarios, which become a
fifth
view.
- The scenarios describe sequences of interactions
between
objects and between processes.
- They are used to identify architectural elements and to
illustrate and validate the architecture design.
- They also serve as a starting point for tests of an
architecture prototype.
- This view is also known as the use case view.
The 4+1 view model is generic and is not restricted to
any notation, tool or
design method.

The Inherent Complexity of Software

● The Complexity of the Problem Domain

● The Difficulty of Managing the Development
Process
● The Flexibility Possible through Software
● The Problems of Characterizing the Behavior of
Discrete Systems