Purpose
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.

Definition
Component diagrams are used in modeling the physical aspects of
object-oriented systems that are used for visualizing,specifying, and
documenting component-based systems and also for constructing
executable systems through forward and reverse engineering.
Component diagrams are essentially class diagrams that focus on a
system's components that often used to model the static
implementation view of a system.

Where to use?
Model the components of a system.
Model the database schema
Model the executables of an application.
Model the system's source code.

Component
A component is a class representing a modular part of a system with encapsulated content and whose manifestation is replaceable
within its environment
A component is shown as a classifier rectangle with the keyword «component»
Optionally, a component icon similar to the UML 1.4 icon can be displayed in the top right corner of the component rectangle. If the
icon symbol is shown, the keyword «component» may be omitted.

Port
A port specifies an interaction point through which a classifier can communicate with its environment, with other
classifiers, or with its internal parts. Encapsulated classifier is defined in UML as structured classifier with the
ability to own ports, and thus port is a property of an encapsulated classifier. Port by default has public visibility
Port is shown as a small square placed either overlapping the boundary of the rectangle denoting the
encapsulated classifier, or it may be shown inside that rectangle symbol. . The name of the port is placed near the
small square

Provide Instance

A provided interface is the one that is either:
Realized directly by the component itself, or
Realized by one of the classifiers realizing component, or
Is provided by a public port of the component

Required Interface
A required interface is either:
Designated by usage dependency from the component itself, or
Designated by usage dependency from one of the classifiers realizing
component, or
Is required by a public port of the component.

Agreegation
A kind of association that has one of its end marked shared as kind of
aggregation, meaning that it has a shared aggregation

Constraint
A condition or restriction expressed in natural language text or in a machine
readable language for the purpose of declaring some of the semantics of an
element

Composition
Composite aggregation is a strong form of aggregation that requires a part instance be
included in at most one composite at a time
If a composite is deleted, all of its parts are normally deleted with it.

Dependency
A dependency is a relationship that signifies that a single or a set of model
elements requires other model elements for their specification or implementation
This means that the complete semantics of the depending elements is either
semantically or structurally dependent on the definition of the supplier element(s)

Assciation
components, interfaces and dependency, aggregation, constraint, generalization, association,
and realization relationships. It may also contain notes and constraints
It has at least two ends represented by properties, each of which is connected to
the type of the end.More than one end of the association may have the same
type.

Links
A generalization is a taxonomic relationship between a more general classifier and
a more specific classifier
Each instance of the specific classifier is also an indirect instance of the general
classifier
Thus, the specific classifier inherits the features of the more general classifier.

State machine diagram is a behavior diagram which shows discrete behavior of a part of designed
system through finite state transitions.
State machine diagrams can also be used to express the usage protocol of part of a system

Behavioral state machines
Shows discrete behavior of a part of designed system through finite state transitions

Protocol state machines : Shows usage protocolor a lifecycle of some classifier, e.g. which operations of the classifier may be called in each state of the classifier, under which specific conditions, and satisfying some optional post conditions after the classifier transitions to a target state.

Purpose
Shows structure of the designed system,
subsystem or component as related
classes and interfaces, with their features,
constraints and relationships - associations,
generalizations, dependencies, etc.

Elements :
Class, interface, feature,
constraint, association,generalization, dependency.

Where to use:
Represents the static view of an application. Used
for visualizing, describing, and documenting
different aspects of a system. Constructing
executable code of the software application

Definition:
A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram .
Class diagram shows a collection of classes, interfaces, associations, collaborations, andconstraints

Definition
Package diagram, a kind of structural diagram, shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules,showing different views of a system, for example, as multilayered (aka multi-tiered) application - multi-layered
application model.

Purpose
Package diagrams are used to structure high level system
elements. Packages are used for organizing large system which
contains diagrams, documents and other key deliverables.

Concept:
Package name should not be the same for a system, however classes inside different packages could have the same name. Packages can include whole diagrams, name of components alone or no components at all. Fully qualified name of a package has the following syntax.

Packages can be represented by the notations with some examples
shown below

<<import>> - one package imports the functionality of other package

<<access>> - one package requires help from functions of other package.

Definition
A composite structure diagram is a UML structural
diagram that contains classes, interfaces, packages, and
their relationships, and that provides a logical view of all,
or part of a software system. It shows the internal structure
(including parts and connectors) of a structured classifie,or collaboration.

The internal actions of a class, including the relationships of nested classes, can be detailed.

Objects are shown to be defined as a
composition of other classified objects

Composite Structure Diagrams allow the users to "Peek Inside" an object to see exactly what it is composed of

Port
A port defines the interaction point between a
classifier instance and its environment or between
the behavior of the classifier and its internal parts.

Interface
Composite Structure diagram supports the ball-and-socket
notation for the provided and required interfaces. Interfaces
can be shown or hidden in the diagram as needed.

Parts:
A collaboration describes a structure of collaborating parts
(roles). A collaboration is attached to an operation or a classifier
through a Collaboration Use. You use a collaboration when you
want to define only the roles and connections that are required
to accomplish a specific goal of the collaboration.

Connector
A line that represents a relationship in a model. When you model the internal
structure of a classifier, you can use a connector to indicate a link between two
or more instances of a part or a port. The connector defines the relationship
between the objects or instances that are bound to roles in the same structured
classifier and it identifies the communication between those roles. The product
automatically specifies the kind of connector to create

Collaboration:
A collaboration describes a structure of collaborating parts
(roles). A collaboration is attached to an operation or a
classifier through a Collaboration Use. You use a
collaboration when you want to define only the roles and
connections that are required to accomplish a specific goal
of the collaboration

Definition
Profile diagram is structure diagram which describes lightweight extension mechanism to the UML by
defining custom stereotypes, tagged values, and constraints. Profiles allow adaptation of the UML
metamodel for different:
Platforms, such as Java Platform, Enterprise Edition (Java EE) or Microsoft .NET Framework, or
Domains, such business process modeling, service-oriented architecture, medical applications, etc

Purpose
Auxiliary UML diagram which allows to define custom stereotypes, tagged,
values, and constraints as a lightweight extension mechanism to the UML
standard. Profiles allow to adapt the UML matamodel for different phatforms
(such as J2EE or .NET), or domains (such as real-time or business process
modeling).

Tagged Values
Tagged values are used to extend the properties of UML so that you can add additional
information in the specification of a model element. It allows you to specify keyword value pairs
of a model where keywords are the attributes. Tagged values are graphically rendered as string
enclose in brackets

Constraints
They are the properties for specifying semantics or conditions that must be held true at all the
time. It allows you to extend the semantics of UML building block by adding new protocols.
Graphically a constraint is rendered as string enclose in brackets placed near associated
element.

Stereotypes
Stereotypes allow you to increase vocabulary of UML. You can add, create new model
elements, derived from existing ones but that have specific properties that are suitable to your
problem domain. Stereotypes are used to introduce new building blocks that speak the language
of your domain and look primitive. It allows you to introduce new graphical symbols.

Definition
Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases)
that some system or systems (subject) should or can perform in collaboration with one or more external users
of the system (actors). Each use case should provide some observable and valuable result to the actors or
other stakeholders of the system
Use case diagrams are in fact twofold - they are both behavior diagrams, because they describe behavior of
the system, and they are also structure diagrams - as a special case of class diagrams where classifiers are
restricted to be either actors or use cases related to each other with associations.

Actor
An actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g.,
by exchanging signals and data), a human user of the designed system, some other system or hardware using
services of the subject.
The term "role" is used informally as some type, group or particular facet of users that require specific services from
the subject modeled with associated use cases. When an external entity interacts with the subject, it plays the role of
a specific actor. That single physical entity may play several different roles, and a specific role may be played by
single or multiple different instances.
Standard UML notation for actor is "stick man" icon with the name of the actor above or below of the icon. Actor
names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should be
shown in italics.

Use Case
Use cases allow to capture requirements of systems under design or consideration, describe functionality provided by
those systems, and determine the requirements the systems pose on their environment.
A use case is a kind of behaviored classifier that specifies a [complete] unit of [useful] functionality performed by [one
or more] subjects to which the use case applies in collaboration with one or more actors, and which [for complete use
cases] yields an observable result that is of some value to those actors [or other stakeholders] of each subject.

Purpose
Use case diagrams are typically develop in early stage of development and people often apply use case
modeling for the following purposes:
Specify the context of a system.
Capture the requirements of a system.
Validate a systems architecture.
Drive implementation and generate test cases
Developed by analysts together with domain experts.

Where to use?
Requirement analysis and high level design.
Model the context of a system.
Reverse engineering.
Forward engineering.

Subject
A subject of a use case defines and represents boundaries of a business, software system, physical system or
device, subsystem, component or even single class in relation to the requirements gathering and analysis.
A subject is a classifier (including subsystem, component, or even class) representing a business, software system,
physical system or device under analysis, design, or consideration, having some behavior, and to which a set of use
cases applies.

Extend
Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional)
extending use case can be inserted into the behavior defined in the extended use case.
Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically
defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the
extending use case. The same extending use case can extend more than one use case, and extending use case may
itself be extended.
Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the
extended (base) use case. The arrow is labeled with the keyword «extend».

Include
Use case include is a directed relationship between two use cases which is used to show that behavior of the
included use case (the addition) is inserted into the behavior of the including (the base) use case.
The include relationship could be used:
To simplify large use case by splitting it into several use cases,
To extract common parts of the behaviors of two or more use cases

Association Between Use Cases
Use cases can only be involved in binary associations.
Two use cases specifying the same subject cannot be associated since each of them individually describes a
complete usage of the system.

Definition: Activity diagram is another important diagram in UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent
the flow from one activity to another activity. The activity can be described as an operation of the
system

Where to use
Modeling work flow by using activities.
Modeling business requirements.
High level understanding of the system's functionalities.
Investigating business requirements at a later stage.

Purpose: Shows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are
commonly called control flow and object flow classifiers own those behaviors. These are
commonly called control flow and object flow

Activity:is a parameterized behavior represented as coordinated flow of actions.
Activity: contains activity nodes which could be:Action, Object Control.
Activities may contain actions of various kinds:
Occurrences of primitive functions, such as arithmetic functions.
Invocations of behavior, such as activities. Communication actions, such as sending of signals. Manipulations of objects, such as reading or writing
attributes or associations

An activity is activity group for actions that have some common characteristic
Partitions often correspond to organizational units or business actors in a business model.
Partitions provide a constrained view on the behaviors invoked in activities. Constraints could be selected according to the type of the element that
the partition represents. The following constraints are normative (standard) in UML

Action is a named element which represents a single atomic step within activity, i.e. that is not further decomposed within the activity. Activity
represents a behavior that is composed of individual elements that are actions.

An node is an abstract activity node that is used to define object flows in an activity. Object nodes include pin, central buffer, parameter,
expansion nodes

Control node is an activity node used to coordinate the flows between other nodes. It includes: initial node, flow final node, activity final node decision node ,merge node ,fork node ,join
node.

Activity Edge: is an abstract class for the directed connections along which tokens or data objects flow between activity nodes. It includes control edges
and object flow edges. The source and target of an edge must be in the same activity as the edge.

To describe the structural organization of the objects.

Where to use
To model the flow of control by time sequence.
To model the flow of control by structural organizations
For forward engineering.
For reverse engineering.

Combined fragment is an interaction fragment
which defines a combination (expression) of interaction fragments. A combined fragment is
defined by an interaction operator and corresponding interaction operands. Through the
use of combined fragments the user will be able to describe a number of traces in a compact and
concise manner

Interaction use is an interaction fragment which
allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with
interaction uses. It is also common to reuse some interaction between several other interactions.

Message is a named element that defines one
specific kind of communication between lifelines ofan interaction. The message specifies not only the
kind of communication, but also the sender and thereceiver. Sender and receiver are normally two
occurrence specifications (points at the ends of messages).

A state invariant is an interaction fragment which
represents a runtime constraint on the participants of invariant is an interaction fragment which
represents a runtime constraint on the participants of variables, internal or external states, etc.

Execution (full name - execution specification,
informally called activation) is interaction fragmen which represents a period in the participant's lifetime
when it is executing a unit of behavior or action within the lifeline, sending a signal to another
participant, waiting for a reply message from another participant

Destruction occurrence is a message occurrence
which represents the destruction of the instance described by the lifeline. It may result in the
subsequent destruction of other objects that this object owns by composition. No other occurrence
may appear below the destruction event on a given

Lifeline is a named element which represents an
individual participant in the interaction. While parts
and structural features may have multiplicity greater
than 1, lifelines represent only one interacting entity

Lifeline is a named element which represents an
individual participant in the interaction. While parts
and structural features may have multiplicity greater
than 1, lifelines represent only one interacting entity

Message is a named element that defines one
specific kind of communication between lifelines of
an interaction. The message specifies not only the
kind of communication, but also the sender and the
receiver. Sender and receiver are normally two
occurrence specifications (points at the ends of
messages)..

Destruction occurrence is a message occurrence
which represents the destruction of the instance
described by the lifeline. It may result in the
subsequent destruction of other objects that this object owns by composition. No other occurrence
may appear after the destruction event on a given lifeline

Duration constraint is an interval constraint that
refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied

State or Condition Timeline Timing diagram could show states of the
participating classifier or attribute, or some testable conditions, such as a discrete or enumerable value
of an attribute
UML also allows the state/condition dimension be
continuous. It could be used in scenarios where
entities undergo continuous state changes, such as
temperature or density.

Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied

Lifeline is a named element which represents an
individual participant in the interaction. While parts
and structural features may have multiplicity greater
than 1, lifelines represent only one interacting entity.

Fork node is a control node that has one incoming
edge and multiple outgoing edges and is used to split incoming flow into multiple concurrent flows.
Fork nodes are introduced to support parallelism inactivities. As compared to UML 1.5, UML 2.0 activity
forks model unrestricted parallelism.

Join node is a control node that has multiple
incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. Join nodes are introduced to support parallelism in activities

Merge node is a control node that brings together
multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge
should not be used to synchronize concurrent flows.

An interaction diagram of any kind may appear
inline as an invocation action. The inline interaction diagrams may be either anonymous or named.

Decision node is a control node that accepts
tokens on one or two incoming edges and selects one outgoing edge from one or more outgoing flows.
Decision nodes were introduced in UML to support conditionals in activities.

An interaction use may appear as an invocation
action.

Activity final node is a control final node that stops
all flows in an activity. Activity final was introduced in UML 2.0.

Duration constraint is an interval constraint that
refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied

Flow final node is a control final node that
terminates a flow. It destroys all tokens that arrive at it but has no effect on other flows in the activity.
Flow final was introduced in UML 2.0.

Time constraint is an interval constraint that refers
to a time interval. The time interval is time expression used to determine whether the constraint is satisfied

Initial node is a control node at which flow starts
when the activity is invoked

Where to use
Making the prototype of a system. Reverse engineering
Modeling complex data structures.
Understanding the system from practical perspective

Definition:
Object diagrams represent an instance of a class
diagram. Object diagrams represent an instance of a class diagram.

Purpose:
During the analysis phase of a project, you might create a class diagram to describe the structure of a system and then create a set of object diagrams
as test cases to verify the accuracy and completeness of the class diagram.
Before you create a class diagram, you might create an object
diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.

Object Names
Offers the name from the object and its class underlined as well
as divided with a colon. We use a rectangle to represent an
object in an Object Diagram

Attributes List object attributes inside a separate compartment.
However, unlike classes, object attributes should have values assigned for them.

Association is a reference relationship between
two objects (or classes).

Aggregation Aggregation represents a “has a” relationship.

Definition Profile diagram is structure diagram which describes lightweight extension mechanism to the UML by
defining custom stereotypes, tagged values, and constraints. Profiles allow adaptation of the UML
metamodel for different:
Platforms, such as Java Platform, Enterprise Edition (Java EE) or Microsoft .NET Framework, or
Domains, such business process modeling, service-oriented architecture, medical applications, etc.

Purpose Auxiliary UML diagram which allows to define custom stereotypes, tagged,
values, and constraints as a lightweight extension mechanism to the UML standard. Profiles allow to adapt the UML matamodel for different phatforms
(such as J2EE or .NET), or domains (such as real-time or business process
modeling).

Stereotypes allow you to increase vocabulary of UML. You can add, create new model
elements, derived from existing ones but that have specific properties that are suitable to your problem domain. Stereotypes are used to introduce new building blocks that speak the language
of your domain and look primitive. It allows you to introduce new graphical symbols

Tagged Values
Tagged values are used to extend the properties of UML so that you can add additional
information in the specification of a model element. It allows you to specify keyword value pairs
of a model where keywords are the attributes. Tagged values are graphically rendered as string
enclose in brackets

Constraints They are the properties for specifying semantics or conditions that must be held true at all the
time. It allows you to extend the semantics of UML building block by adding new protocols. Graphically a constraint is rendered as string enclose in brackets placed near associated
element