0% found this document useful (0 votes)
20 views24 pages

Unit3 Uml

The Unified Modeling Language (UML) is a standard visual language for modeling software systems, encompassing building blocks such as things, relationships, and diagrams. It includes various types of elements like structural, behavioral, grouping, and annotational things, as well as relationships such as dependency and association. UML diagrams, including class, object, and use case diagrams, serve to visualize different aspects of a system's architecture and behavior.

Uploaded by

blessy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views24 pages

Unit3 Uml

The Unified Modeling Language (UML) is a standard visual language for modeling software systems, encompassing building blocks such as things, relationships, and diagrams. It includes various types of elements like structural, behavioral, grouping, and annotational things, as well as relationships such as dependency and association. UML diagrams, including class, object, and use case diagrams, serve to visualize different aspects of a system's architecture and behavior.

Uploaded by

blessy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

Conceptual Model of UML

• UML is a standard language for specifying, visualizing,


constructing, and documenting the artifacts of software systems.

The Unified Modeling Language (UML) is a modeling


language that can be used for a variety of purposes. The primary goal
of UML is to establish a standard way to visualize how a system has
been constructed. It is very similar to blueprints used in other
engineering professions.

UML is a visual language that provides a way for software


engineers and developers to construct, document and visualize
software systems. While UML is not a programming language , it can
provide visual representations that help software developers better
understand potential outcomes or errors in programs.
Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building
blocks:
Things
Relationships
Diagrams

Things are the abstractions that are first-class citizens in a model;


relationships tie these things together; diagrams group interesting
collections of things.
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things
Structural Things
Structural things are the nouns of UML models.
These are the mostly static parts of a model.
Classes
A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
A class implements one or more interfaces. Graphically, a class is
rendered as a rectangle, usually including its name, attributes, and
operations.
Interface:

• An interface is a collection of operations that specify a service of a


class or component.
• An interface might represent the complete behavior of a class or
component or only a part of that behavior
• An interface defines a set of operation specifications (that is, their
signatures) but never a set of operation implementations.
• An interface provided by a class to the outside world is shown as a
small circle attached to the class box by a line.
• An interface required by a class from some other class is shown as
a small semicircle attached to the class box by a line
Collaboration

Collaboration: A collaboration is the collection of interactions among


objects to achieve a goal. Graphically collaboration is represented as a
dashed ellipse. A collaboration can be a collection of classes or other
elements.

Use Case:
• A use case is a description of sequences of actions that a system
performs that yield observable results of value to a particular actor.
• A use case is used to structure the behavioral things in a model.
• Graphically, a use case is rendered as an ellipse with solid lines,
usually including only its name
Component: A component is a physical and replaceable part of a
system. Graphically component is represented as a tabbed rectangle.

Examples of components are executable files, dll files, database


tables, files and documents.
Nodes:
A node is a physical element that exists at run time and represents a
computational resource, generally having at least some memory and,
often, processing capability.
A set of components may reside on a node and may also migrate
from node to node.
Graphically, a node is rendered as a cube, usually including only its
name.

Behavioral Things:
Behavioral things are the dynamic parts of UML models.
These are the verbs of a model, representing behavior over time and
space.
There are 2 primary kinds of behavioral things
Interaction
State
Interaction:
• It is a behavior that comprises a set of messages exchanged among a set of objects or roles
within a particular context to accomplish a specific purpose.
• An interaction involves a number of other elements, including messages, actions, and
connectors .
• Graphically, a message is rendered as a directed line, almost always including the name of
its operation

State:
• It is a behavior that specifies the sequences of states an object or an interaction goes
through during its lifetime in response to events, together with its responses to those
events.
• The behavior of an individual class or a collaboration of classes may be specified
with a state machine.
• A state machine involves a number of other elements, including states, transitions
(the flow from state to state), events (things that trigger a transition), and activities
(the response to a transition).
• Graphically, a state is rendered as a rounded rectangle, usually including its name
and its substates.
Grouping Things
• Grouping things are the organizational parts of UML models.
• There is one primary kind of grouping thing, namely, packages.
Package:
• A package is a general-purpose mechanism for organizing the design itself.
• Structural things, behavioral things, and even other grouping things may be placed in a
package.
• Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents
Annotational Things:
Annotational things are the explanatory parts of UML models.
These are the comments you may apply to describe, illuminate, and remark about any
element in a model.
There is one primary kind of annotational things, called a note.
A note is simply a symbol for rendering constraints and comments attached to an element or
a collection of elements.
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment.
Relationships in the UML
There are four kinds of relationships in the UML:
I. Dependency
II. Association
III. Generalization
IV. Realization
Dependency:
• A dependency is a semantic relationship between two model elements in which a change to
one element (the independent one) may affect the semantics of the other element.
• Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label

Association
• An association is a structural relationship among classes that describes a set of links.
• A link being a connection among objects that are instances of the classes.
• Aggregation is a special kind of association, representing a structural relationship between a
whole and its parts.
• Graphically, an association is rendered as a solid line, possibly directed, occasionally
including a label, and often containing other adornments, such as multiplicity and end
names.
Generalizations:
• A generalization is a specialization/generalization relationship in which the specialized
element (the child) builds on the specification of the generalized element (the parent).
• The child shares the structure and the behavior of the parent.
• Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.

Realizations:
A realization is a semantic relationship between classifiers, where in one classifier specifies a
contract that another classifier guarantees to carry out.

Graphically, a realization relationship is rendered as a cross between a generalization and a


dependency relationship.
Diagrams in the UML
• A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships).
• Drawing diagrams to visualize a system from different perspectives, so a diagram is a
projection into a system.
• A diagram may contain any combination of things and relationships.

List of UML Diagrams


I. Class diagram
II. Object diagram
III. Component diagram
IV. Deployment diagram
V. Use case diagram
VI. State diagram
VII. Activity diagram
VIII. Sequence diagram Interaction diagrams
IX. Collaboration diagram
Class diagram
• A class diagram shows a set of classes, interfaces, and collaborations and their
relationships.

• Class diagrams address the static design view of a system.

The following diagram is an example of an Order System of an application. It describes a


particular aspect of the entire application.

First of all, Order and Customer are identified as the two elements of the system. They
have a one-to-many relationship because a customer can have multiple orders.

Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In addition, they
have additional functions like dispatch () and receive ().
Object diagram
An object diagram shows a set of objects and their relationships.
Object diagrams represent static snapshots of instances of the things found in class
diagrams.
Component diagrams can also be described as a static implementation view of a system.
Static implementation represents the organization of the components at a particular
moment.
Component diagrams can be used to −
Model the components of a system.
Model the database schema.
Model the executables of an application.
Model the system's source code.
Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
Following is a sample deployment diagram to provide an idea of the deployment view of
order management system. Here, we have shown nodes as −
Monitor
Modem
Caching server
Server
Use case diagrams are considered for high level requirement analysis of a system. When the
requirements of a system are analyzed, the functionalities are captured in use cases.

Use case diagrams are drawn to capture the functional requirements of a system.
The interactive behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram.

The basic purpose of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and

collaboration diagram emphasizes on the structural organization of the objects that send
and receive messages.
To choose between these two diagrams, emphasis is placed on the type of requirement. If
the time sequence is important, then the sequence diagram is used. If organization is
required, then collaboration diagram is used.
Interaction diagrams can be used −
To model the flow of control by time sequence.
To model the flow of control by structural organizations.

Statechart diagrams are very important for describing the states. States can be identified as
the condition of objects when a particular event occurs.
Statechart diagram defines the states of a component and these state changes are dynamic
in nature. Its specific purpose is to define the state changes triggered by events. Events are
internal or external factors influencing 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.

The main element of an activity diagram is the activity itself. An activity is a function
performed by the system

The specific usage is to model the control flow from one activity to another. This control
flow does not include messages.

You might also like