Unified Modeling Language

 Principles of Modeling:-
1. The choice of what models to create has a profound influence on how a
problem is attacked and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models.

Overview of the UML
 The Unified Modeling Language (UML) is a standard
language for writing software blueprints.
 The UML may be used to visualize, specify, construct, and
document the artifacts of a software intensive system.

 The UML Is a Language:-
 A modeling language is a language whose vocabulary and rules focus on
the conceptual and physical representation of a system.
 The UML Is a Language for Visualizing:
 For many programmers, the distance between thinking of an
implementation and then pounding it out in code is close to zero.
 The UML Is a Language for Specifying:
 UML addresses the specification of all the important analysis, design, and
implementation decisions that must be made in developing and deploying a
software-intensive system.

 The UML Is a Language for Constructing:-
 The UML is not a visual programming language, but its models can be
directly connected to a variety of programming languages.
 This means that it is possible to map from a model in the UML to a
programming language such as Java, C++, or Visual Basic.

 The UML Is a Language for Documenting:-
 A healthy software organization produces all sorts of artifacts in addition to
raw executable code.
 These artifacts include
Project plans
Requirements
Prototypes
Architecture
Design
Source code
Tests
Releases

 Where Can the UML Be Used?
 The UML is intended primarily for software-intensive systems. It has been
used effectively for such domains as
 Enterprise information systems
 Banking and financial services
 Telecommunications
 Transportation
 Defense/aerospace
 Retail
 Medical
 Electronics
 Scientific
 Distributed Web-based services

Object-Oriented Modeling
 In software, there are several ways to approach a model.
The two most common ways are from an algorithmic
perspective and from an object-oriented perspective.
 From an algorithmic perspective, the main building block of
all software is the procedure or function.
 From an object-oriented perspective, the main building
block of all software systems is the object or class.
 Every object has identity, state and behavior.

A Conceptual Model of the
UML
 Conceptual model requires learning three major elements:
1. The UML's basic building blocks.
2. The rules of the UML.
3. Common mechanisms of the UML.

 Building Blocks of the UML:-
 The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams

1. Things in the UML
 Things are the abstractions that are first-class citizens in a model.
 There are four kinds of things in the UML:
1. Structural things.
2. Behavioral things.
3. Grouping things.
4. Annotational things.

 Structural Things
 These are the mostly static parts of a model, representing elements that are
either conceptual or physical.
 Are several kinds of structural things:
 A class is a description of a set of objects.
 Class is rendered as a rectangle, usually including its name, attributes, and
operations.

 An interface is a collection of operations that specify a service of a class or
component.
 An interface rarely stand alone.
 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.

 A collaboration defines an interaction.
 A collaboration is rendered as an ellipse with dashed lines, usually
including only its name.

 A use case is a description of set of sequence of actions that a system
performs that yields an observable result of value to a particular actor.
 A use case is rendered as an ellipse with solid lines, usually including only
its name

 An active class is a class whose objects own one or more processes or
threads and therefore can initiate control activity.
 An active class is rendered just like a class, but with heavy lines, usually
including its name, attributes, and operations.

 A component is a modular part of the system design that hides its
implementation behind a set of external interfaces.
 A component is rendered like a class with a special icon in the upper right
corner.

 Node is used to represent physical part of a system like server, network
etc..
 A node is rendered as a cube, usually including only its name.

 Behavioral Things:-
 Behavioral things are the dynamic parts of UML models.
 An interaction is a behavior that comprises a set of messages exchanged
among a set of objects.
 A message is rendered as a directed line, almost always including the
name of its operation.

 A state machine is a behavior that specifies the sequences of states an
object.
 A state is rendered as a rounded rectangle, usually including its name and
its substates.

 An activity is a behavior that specifies the sequence of steps a
computational process performs.
 A step of an activity is called an action.
 An action is rendered as a rounded rectangle with a name indicating its
purpose.
 States & actions are distinguished by their different contexts.
process order

 Grouping Things
 Grouping things are the organizational parts of UML models.
 A package is a general-purpose mechanism for organizing elements into
groups.
 Structural things, behavioral things, and even other grouping things may be
placed in a package.
 Packages is purely conceptual.
 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.
 A note is simply a symbol for rendering constraints and comments attached
to an element or a collection of elements.
 A note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment.

2. Relationships in the UML
 There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization

 A dependency is a semantic relationship between two things in which a
change to one thing may affect the semantics of the other thing.
 A dependency is rendered as a dashed line, possibly directed, and
occasionally including a label.

 An association is a structural relationship that describes a set of links, a
link being a connection among objects.
 An association is rendered as a solid line, possibly directed, occasionally
including a label.

 A generalization is a specialization/generalization relationship in which
objects of the specialized element (the child) are substitutable for objects of
the generalized element.
 A generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.

 A realization relationship is a relationship between two model elements, in
which one model element (the client) realizes the behavior that the other
model element (the supplier) specifies.
 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
presented as a connected graph of things and relationships.
 UML includes few kinds of diagrams.
1. Class diagram consists of classes, interfaces, associations and
collaboration.
 Class diagrams basically represent the object oriented view of a system which
is static in nature.

2. Object diagrams are a set of objects and their relationships.
 Object diagram represent the static view of the system.
3. Component diagrams represent a set of components and their
relationships. These components consist of classes, interfaces or
collaborations.
 Component diagrams represent the implementation view of a system.

4. A use case diagram represents a particular functionality of a system.
 Represent the use case view of a system.
5. A sequence diagram is an interaction diagram.
 Interaction among the components of a system is very important from
implementation and execution perspective.
 Represent the dynamic view of interaction.

6. Communication diagram is an interaction diagram that highlight the
structural organization of the objects that send and receive messages.
7. A state diagram shows a state machine, consisting of states, transitions,
events, and activities.
 State diagrams address the dynamic view of a system.
8. Activity diagram describes the flow of control in a system.
 Activity diagrams address the dynamic view of a system

9. Deployment diagrams are a set of nodes and their relationships.
 These nodes are physical entities where the components are deployed.
10. Artifact diagram shows the physical element of a system on the computer.
 Artifacts include files, database etc.

11. Package diagram shows the decomposition of the model itself into
organization units & their dependencies.
12. Timing diagram is an interaction diagram that shows actual times across
different objects, relative sequences of messages.
13. Interaction overview diagram is hybrid of activity & sequence diagram.

 Rules of the UML:-
 A well-formed model is one that is semantically
self-consistent and in synchronization with all its related models.
 The UML has semantic rules for
 Names:- What you can call things, relationships, and diagrams.
 Scope:- The context that gives specific meaning to a name
 Visibility:- How those names can be seen and used by others
 Integrity:- How things properly and consistently relate to one another
 Execution:- What it means to run or simulate a dynamic model

 It is common for the development team to not only build models that are
well-formed, but also to build models that are:
 Elided:- Certain elements are hidden to simplify the view
 Incomplete:- Certain elements may be missing
 Inconsistent:- The integrity of the model is not guaranteed

 Common Mechanisms in the UML:-
 UML is made simpler by the presence of four common mechanisms that
apply consistently throughout the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

 Specifications
 Specifying something in a bit more detail so that the role and meaning of
the term being specified is presented to us in a more clear.
 Adornments
 Adornments are textual or graphical items, which can be added to the basic
notation of a UML building block in order to visualize some details from that
element’s specification.
 One of the most important kinds of adornments is a note

 Common Divisions
 In modeling Object Oriented systems, the world often gets divided in several
ways.
 First, there is the division of class and object.
A class is an abstraction; an object is one concrete manifestation of that
abstraction.
 Graphically, the UML distinguish an object by using the same symbol as its
class and then simply underlying the objects name.

 Second, there is the separation of interface and implementation.
 An interface declares a contract.
 An implementation represents one concrete realization of that contract,
responsible for faithfully carrying out the interface's complete semantics.

 Extensibility Mechanisms: – UML is opened ended language, making it
possible for You to extend the language in controlled ways:

There are three:-
Stereotype:- Stereotypes allow you to extend the vocabulary of the UML
so that you can create new model elements, derived from existing ones, but
that have specific properties that are suitable for your problem domain.

Tagged value:- A tagged value extends the properties of UML building
blocks ,allowing user to create new information in that elementary
specification.

Constraint: – This allows user to add new rules or modify existing ones.

 Architecture of modeling system’s
 A system's architecture is perhaps the most important artifact that can be
used to manage these different viewpoints and so control the iterative and
incremental development of a system throughout its life cycle.

 Architecture is the set of significant decisions about
 The organization of a software system.
 The selection of the structural elements and their interfaces by which the
system is composed.
 Their behavior, as specified in the collaborations among those elements.
 The composition of these structural and behavioral elements into progressively
larger subsystems.
 The architectural style that guides this organization

 The use case view of a system encompasses the use cases that describe
the behavior of the system as seen by its end users, analysts, and testers.
 The design view of a system encompasses the classes, interfaces, and
collaborations that form the vocabulary of the problem and its solution.
 The interaction view of a system shows the flow of control among its
various parts, including possible concurrency & synchronization
mechanisms.

 The implementation view of a system encompasses the components and
files that are used to assemble and release the physical system.
 The deployment view of a system encompasses the nodes that form the
system's hardware topology on which the system executes

 The nature of an object:-
 We define an object as a tangible entity that exhibits some well-defined
behavior.
 An object has state, exhibits come well-defined behavior, & has a unique
identity.
 An object is any of the following:-
A tangible &/or visible thing.
Something that may be apprehended intellectually.
Something towards which thought or action is
directed.

 Real-world objects share two characteristics: They all have state and
behavior.
 State : Every object, at any given point of time would have to have a set of
attributes defining its State.
 Behavior : Every object based on its state and optionally identity will have
particular behavior.
 Eg:-Dogs have state (name, color, breed, hungry) and behavior (barking,
fetching, wagging tail).
 Bicycles also have state (current gear, current pedal cadence, current
speed) and behavior (changing gear, changing pedal cadence, applying
brakes)

 THE PROPERTY (OBJECT ATTRIBUTE)
 Properties are variables contained in the class; every instance of the object
has those properties.
 The methods:-
 Methods follow the same logic as properties.
 The difference is that they are functions and they are defined as functions.
 Calling a method is similar to accessing a property, but you add () at the
end of the method name, possibly with arguments.

 The messages :-
 An object-oriented program is a growing and shrinking collection of objects
that interact via messages.
 Objects can send and receive messages.
 Over its lifetime, the object has a state that varies.
 A message is called a request or an event.
 The event contains the name of the object, the name of the operation, and
maybe a group of parameters.

 Object – Oriented Systems Development Life Cycle:-
 The essence of the software Development Process that consists of
 Analysis ,
 Design ,
 Implementation ,
 Testing , and
 Refinement
 To transform users’ needs into a software solution that satisfy the needs.

 The object oriented approach requires a more rigorous process to do things
right more rigorous process to do things right.
 You need not see code until after about 25 percent of the development time,
because you need to spend more time in gathering requirements,
developing a requirement model and an analysis model, then turning them
into the design model.

 The software development process also can be divided into smaller,
interacting subprocesses.
 Generally, the software development process can be viewed as a series of
transformations, where the output of one transformation becomes the input
of the subsequent transformation.

 Transformation1(Analysis):
 Translates the user’s needs into system requirements and responsibilities.
 The way they use the system can provide insight into the user’s
requirements.
 For example: one use of system might be analyzing an incentive payroll
system, which will tell us that this capacity will be included in the system
requirements.

 Transformation 2 (design):
 Begins with a problem statement and ends with a detailed design that can
be transformed into a operational system.
 This transformation includes the bulk of the software development activity,
including the definition of how to build the software, its development, and its
testing.
 It also includes design descriptions, the programs and the testing material.

 Transformation 3(Implementation)
 Refines the detailed design into the system deployment that will satisfy the
user’s needs.
 This takes into account equipment, procedures, people, and the like.
 It represents embedding the software product within its operational
environment.

 ADVANTAGES OF OBJECT ORIENTED METHODOLOGY
 Object Oriented Methodology closely represents the problem domain.
Because of this, it is easier to produce and understand designs.
 The objects in the system are safe to requirement changes. Therefore,
allows changes more easily.
 Object Oriented Methodology designs encourage more re-use. New
applications can use the existing modules, thereby reduces the
development cost and cycle time.

 Object Oriented Methodology approach is more natural. It provides nice
structures for thinking and abstracting and leads to modular design.

 The object-modeling technique (OMT) is an object modeling language for
software modeling and designing.
 It was developed by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as
a method to develop object-oriented systems, and to support object-
oriented programming.

 THE RAMBAUGH OMT
 The purposes of modeling according to Raumbaugh (1991) are:
 Testing physical entities before building them (simulation)
 Communication with customers
 Visualization (alternative presentation of information)
 Reduction of complexity.

 The Rambaugh OMT has proposed three main types of models:
 Object model : Main concepts are classes and associations, with attributes
and operations. Aggregation and generalization are predefined
relationships.
 Dynamic model : The dynamic model represents a state/transition view on
the model. Main concepts are states, transitions between states, and events
to trigger transitions. Actions can be modeled as occurring within states.
 Functional model : The functional model handles the process of the model,
corresponding roughly to data flow diagrams. Main concepts are process,
data store, data flow, and actors.
 OMT is a predecessor of the Unified Modeling Language (UML).

 THE BOOCH OMT
 The analysis phase is split into steps.
 Customer's Requirements Step:
 The first step is to gather the requirements from the customer
perspective. This analysis step generates a high-level description of the
system's function and structure.
 Domain analysis:
 The domain analysis is done by defining object classes; their attributes,
inheritance, and methods. State diagrams for the objects are then
established.
 The analysis phase is completed with a validation step.

 Once the analysis phase is completed, the Booch methodology develops
the architecture in the design phase.
 The design phase is iterative.
 A logic design is mapped to a physical design like processes, performance,
data types, data structures, visibility are defined.
 A prototype is created and tested.
 The process iterates between the logical design, physical design,
prototypes, and testing.

 The Booch software engineering methodology is sequential in the sense
that the analysis phase is completed and then the design phase is
completed.

 JACOBSON OOSE
 Object-Oriented Software Engineering (OOSE) is a software design
technique that is used in software design in object-oriented programming.
 OOSE is the first object-oriented design methodology that employs use
cases in software design.
 It includes requirements, an analysis, a design, an implementation and a
testing model.

 OBJECT-ORIENTED SOFTWARE ENGINEERING LIFE CYCLE
 Requirements Engineering:
 Requirements gathering,
 Object oriented analysis and
 Specification
 OO Design:
 Architectural design
 Detailed design
 Both require the transformation of functional requirements into OO design
elements

 Implementation or Coding:
 Programming using OO programming languages and tools.
 Testing:
 Unit testing; test methods within each object
 Integration testing; test collaborations between objects
 System testing; test the entire system as a collection of objects
 Acceptance testing; test for standards and customer satisfaction

 Iterative and Incremental:
 The Unified Process is an iterative and incremental development process.
 The Elaboration, Construction and Transition phases are divided into a series of
timeboxed iterations.
 Each iteration results in an increment, which results in improved functionality .
 Use Case Driven:
 In the Unified Process, use cases are used to capture the functional
requirements and to define the contents of the iterations.

 Risk Focused
 The Unified Process requires the project team to focus on the most critical risks
early in the project life cycle.
 The deliverables of each iteration, especially in the Elaboration phase, must be
selected in order to ensure that the greatest risks are addressed first.

 VIEWS IN UML
1. Functional View:
 This view describes functional requirements of the
system.
 Use case diagrams give static functional view for
functions and static relationships.
 Activity diagrams give dynamic functional view.
2. Static Structural View:
 The class and object diagrams give the structural view of system.

3. Behavioral (dynamic structural) view:
 Interaction diagrams- collaboration diagrams and sequence diagrams
describe sequences of interactions between objects.
 State transition diagrams show state-based behavior of objects.
4. Architectural View:
 This view describes logical and physical structure.
 Component diagrams and deployment diagrams are used in this view

Use Case Diagrams
 Use case diagrams are central to modeling the behavior of
a system, a subsystem, or a class.
 Each one shows a set of use cases and actors and their
relationships.
 Use case diagrams are important for visualizing, specifying,
and documenting the behavior of an element.

 A use case 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.
 Graphically, a use case is rendered as an ellipse.
 We apply use cases to capture the intended behavior of the system you are
developing, without having to specify how that behavior is implemented.

 Use case diagrams commonly contain
 Use cases
 Subject
 Actors
 Dependency, generalization, and association relationships
 Like all other diagrams, use case diagrams may contain notes and
constraints.

 Subject:-
 The subject is a class described by a set of use cases.
 The use cases represent aspects of the behavior of the class.
 The actor represent aspects of the other classes that interact with the
subject.

 Use Cases and Actors
 An actor represents a role that a human, a hardware device, or even
another system plays with a system.
 Represents an individual interacting with the system in a specific way.

 Use Cases and Flow of Events
 A use case describes what a system does but it does not specify how it
does it.
 Flow of event shows the behavior of the use case.
 Flow of events are 2 types:
 Main flow of events
 Exceptional flow of events.

 Use Cases and Scenarios
 A scenario is a specific sequence of actions that illustrates behavior.
 Scenario is basically one instance of a use case.
 Use Cases and Collaborations

 Organizing Use Cases
 You can organize use cases by grouping them in packages.
 You can also organize use cases by specifying generalization, include, and
extend relationships among them.
 Generalization among use cases is just like generalization among classes.
 An include relationship between use cases means that the base use case
explicitly incorporates the behavior of another use case at a location
specified in the base.

 An extend relationship between use cases means that the base use case
implicitly incorporates the behavior of another use case at a location
specified indirectly by the extending use case.

 Notation
 The subject is shown as a rectangle containing a set of use case.
 The name of subject is placed within a rectangle.
 The actor are shown as stick figures placed outside the rectangle.

 Use-case diagrams are helpful in the following
situations:
 Before starting a project, you can create use-case diagrams to model a
business so that all participants in the project share an understanding
of the workers, customers, and activities of the business.
 While gathering requirements, you can create use-case diagrams to
capture the system requirements and to present to others what the
system should do.
 During the analysis and design phases, you can use the use cases and
actors from your use-case diagrams to identify the classes that the
system requires.
 During the testing phase, you can use use-case diagrams to identify
tests for the system.

 Activity is an ongoing structured execution of a behavior.
 Activity is a behavior expressed as a set of actions connected by control &
data flows.
 An activity diagram shows the flow from activity to activity.
 Graphically, an activity diagram is a collection of nodes and arcs.

 Activity diagrams commonly contain
 Actions
 Activity nodes
 Flows
 Object values.
 Like all other diagrams, activity diagrams may contain notes and
constraints.

 Actions & activity nodes
 You might evaluate some expression that sets the value of an attribute or
that returns some value.
 You might call an operation on an object, send a signal to an object, or
even create or destroy an object.
 These executable, atomic computations are called action.
 Representation of action using a rounded box.

 An activity node is an organizational units within an activity.
 Activity nodes are nested grouping of actions.
 An action is an activity node that cannot be further decomposed.

 Control Flows
 When the action or activity of a state completes, flow of control passes
immediately to the next action or activity state.
 Indeed, a flow of control has to start and end someplace.
 You may specify this initial state (a solid ball) and stop state (a solid ball
inside a circle).

 Branching
 A branch may have one incoming transition and two or more outgoing ones.
 On each outgoing transition, you place a Boolean expression, which is
evaluated only once on entering the branch.
 Guards on the outgoing flow should not overlap but they should cover all
possibilities.
 When two paths of control merge back together, you can also use a
diamond symbol with 2 input arrows & 1 output arrow. No guard are
necessary on merge.

 Forking and Joining
 You use a synchronization bar to specify the forking and joining of these
parallel flows of control.
 A synchronization bar is rendered as a thick horizontal or vertical line.

 Swimlanes
 When you are modeling workflows of business processes, to partition the
activity states on an activity diagram into groups.
 Each group representing the business organization responsible for those
activities.
 In the UML, each group is called a swimlane because, visually, each group
is divided from its neighbor by a vertical solid line

 Object Flow
 An object flow is a path along which objects or data can pass. An object is
shown as a rectangle.
 With object we can include the state of the object.

 Expansion Region
 An expansion region is a structured activity region that executes multiple
times.
 Input and output expansion nodes are drawn as a group of three boxes
representing a multiple selection of items.

Unified Modeling Language

More Related Content

What's hot

Similar to Unified Modeling Language

Recently uploaded

Unified Modeling Language