Unified Modeling Language

Department of Computer
Engineering, MITAOE, Alandi (D)
■ Importance of Modeling
■ Principles of Modeling
■ UML Diagrams
Use case Diagram
Sequence Diagram
Activity Diagram
 Importance of Modeling
■ Why do we model?
We build models to better understand the systems we
are developing.
To help us visualize
To specify structure or behavior
To provide template for building system
To document decisions we have made
 Principles of Modeling
■ The models we choose have a profound
influence on the solution we provide
■ Every model may be expressed at different
levels of abstraction
■ The best models are connected to reality
■ No single model is sufficient, a set of models is
needed to solve any nontrivial system
 UML
■ UML is a visual modeling language
■ “A picture is worth a thousand words.” -old
saying
■ Unified Modeling Language:
■ “A language provides a vocabulary and the
rules for combining words [...] for the purpose
of communication.
 What is UML ?
■ Standard language for specifying, visualizing,
constructing, and documenting the artifacts of software
systems, business modeling and other non-software
systems.
■ The UML represents a collection of best engineering
practices that have proven successful in the modeling of
large and complex systems.
■ The UML is a very important part of developing object
oriented software and the software development process.
■ The UML uses mostly graphical notations to express the
design of software projects.
■ Using the UML helps project teams communicate,
explore potential designs, and validate the architectural
design of the software.
 Usages of UML
■ UML is used in the course to
■ i. Document designs
design patterns / frameworks
■ ii. Represent different views/aspects of design–
visualize and construct designs
static / dynamic / deployment / modular aspects
■ iii. Provide a next-to-precise, common,
language –specify visually
for the benefit of analysis, discussion,
comprehension.
Use Case Diagram
 Use case diagrams
■ The purposes of use case diagrams can be said
to be as follows −
■ Used to gather the requirements of a system.
■ Used to get an outside view of a system.
■ Identify the external and internal factors
influencing the system.
■ Show the interaction among the requirements
and actors.
■ When we are planning to draw a use case
diagram, we should have the following items
identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors
■ After identifying the above items, we have to use
the following guidelines to draw an efficient use
case diagram
■ The name of a use case is very important. The name should be
chosen in such a way so that it can identify the functionalities
performed.
■ Give a suitable name for actors.
■ Show relationships and dependencies clearly in the diagram.
■ Do not try to include all types of relationships, as the main
purpose of the diagram is to identify the requirements.
■ Use notes whenever required to clarify some important points.
Example: Registration System
 Interaction Diagram
■ The purpose of interaction diagram is −
■ To capture the dynamic behavior of a system.
■ To describe the message flow in the system.
■ To describe the structural organization of the
objects.
■ To describe the interaction among objects.
Sequence Diagram
Sequence Diagram
 Activity Diagram
■ Activity is a particular operation of the system.
Activity diagrams are not only used for visualizing
the dynamic nature of a system, but they are also used
to construct the executable system by using forward
and reverse engineering techniques.
■ The purpose of an activity diagram can be described
as −
■ 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.
 Activity Diagram
■ Before drawing an activity diagram, we should
identify the following elements −
■ Activities
■ Association
■ Conditions
■ Constraints
■ What is the difference between requirements analysis
and specification?
■ Why is it hard to define and specify requirements?
■ What are use cases and scenarios?
■ What is the difference between functional and
non-functional requirements?
■ What’s wrong with a requirement that says a product
should be “user-friendly”?
■ What’s the difference between evolutionary and
throw-away prototyping?