2. A Model is a simplification of reality. A
model provides the blueprints of a system.
Models may encompass detailed plans.
• A Model is a semantically closed abstraction
of the system.
• A model may be structural, emphasizing the
organization of the system, or it may be
behavioral, emphasizing the dynamics of the
system.
3. • Why do we model ?
We build models so that we can better
understand the system we are developing.
4. • Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as
we want it to be.
2. Models permit us to specify the structure or
behavior of a system.
3. Models give us a template that guides us in
constructing a system.
4. Models document the decisions we have made.
5. 1. Principles of Modeling:
a) The choice of what models to create has a
profound influence on how a problem is attacked
and how a solution is shaped. In other words,
choose your models well.
b) Every model may be expressed at different levels
of precision.
c) The best models are connected to reality.
d) No single model is sufficient. Every nontrivial
system is best approached through a small set of
nearly independent models
6. • To understand the architecture of such a system, we
need views like:
• A use case view (exposing the requirements of the
system),
• A design view (capturing the vocabulary of the
problem space and the solution space),
• A process view (modeling the distribution of the
system's processes and threads),
• An implementation view (addressing the physical
realization of the system),
• A deployment view (focusing on system
engineering issues).
7. • Each of these views may have structural, as well as
behavioral, aspects. Together, these views
represent the blueprints of software.
• Depending on the nature of the system, some
models may be more important than others.
8. 2. Object-Oriented Modeling:
• In software, there are several ways to approach a
model. The two most common ways are :
a) Algorithmic perspective
b) Object-oriented perspective.
• The traditional view of software development takes
an algorithmic perspective. In this approach, the
main building block of all software is the procedure
or function.
9. • An object-oriented perspective, the main building
block of all software systems is the object or class.
• An object is a thing.
• A Class is a description of a set of common objects.
• Every object has identity, state, and behavior.
10. Introducing the UML
Chapter-2
• The Unified Modeling Language (UML) is a
standard language for writing software blueprints.
• The UML is language for
visualizing,
specifying,
constructing
documenting the artifacts of a software-intensive
system.
11. • 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 Documenting: A healthy
software organization produces all sorts of artifacts
in addition to raw executable code. These artifacts
include: Requirements, Architecture, Design, Source
code, Project plans, Tests, Prototypes, Releases.
12. • The UML is only a language and so is just one part
of a software development method.
• The UML is Process independent.
• Specifying means building models that are
precise, unambiguous, and complete.
13. A Conceptual Model of the UML:
• To understand the UML, you need to form a
conceptual model of the language, this requires
learning three major elements:
1. Building blocks of UML.
2. Rules of the UML.
3. Common mechanisms.
14. 1. Building Blocks of the UML:
• The vocabulary of the UML encompasses three
kinds of building blocks:
a) Things.
b) Relationships.
c) Diagrams.
15. • Things are the abstractions that are first-class
citizens in a model.
• Relationships tie these things together.
• Diagrams group interesting collections of things.
16. 1.1: Things in the UML
• There are four kinds of things in the UML:
a) Structural things.
b) Behavioral things.
c) Grouping things.
d) Annotational things.
17. 1.1:
a) Structural Things
• Structural things are the nouns of UML models.
• These are the mostly static parts of a model,
representing elements that are either conceptual or
physical.
18. • In all, there are seven kinds of structural things.
1. Class.
2. Interface.
3. Collaboration.
4. Use Case.
5. Active Classes.
6. Components.
7. Nodes.
19. 1 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, as below.
20. 2. Interface is a collection of operations that specify a
service of a class or component.
• An interface therefore describes the externally
visible behavior of that element.
• An interface might represent the complete behavior
of a class or component or only a part of that
behavior.
• Graphically, an interface is rendered as a circle
together with its name. << >>
• An interface rarely stands alone. Rather, it is
typically attached to the class or component that
realizes the interface.
21. 3. A Collaboration defines an interaction and is a
society of roles and other elements that work
together to provide some cooperative behavior
that's bigger than the sum of all the elements.
(Semantical meaning: The action of working with
someone to produce something).
• Therefore, collaborations have structural, as well as
behavioral, dimensions. A given class might
participate in several collaborations.
• Graphically, a collaboration is rendered as an ellipse
with dashed lines.Example: Control Panel.
22. 4. Use case: 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 used to structure the behavioral things
in a model.
• A use case is realized by a collaboration.
• Graphically, a use case is rendered as an ellipse with
solid lines, usually including only its name.
23. 5. 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 just like a class except that its
objects represent elements whose behavior is
concurrent with other elements.
• Graphically, an active class is rendered just like a
class, but with heavy lines, usually including its
name, attributes, and operations.
24. 6. A Component is a physical and replaceable part of a
system that conforms to and provides the
realization of a set of interfaces.
• In a system, you'll encounter different kinds of
deployment components, such as Java Beans,
source code files.
• Graphically, a component is rendered as a rectangle
with tabs, usually including only its name.
• Example: Orderform.java
25. 7. 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.
26. b) 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 two primary kinds of behavioral things.
1. Interaction.
2. State Machine.
27. 1. An interaction is a behavior that comprises a set of
messages exchanged among a set of objects within
a particular context to accomplish a specific
purpose.
• The behavior of a society of objects or of an
individual operation may be specified with an
interaction.
• Graphically, a message is rendered as a directed
line.
28. 2. A State machine 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.
• Graphically, a state is rendered as a rounded
rectangle, usually including its name and its
substates, if any.
29. 1.3: Grouping Things:
• Grouping things are the organizational parts of
UML models.
• These are the boxes into which a model can be
decomposed.
• There is one primary kind of grouping thing called
packages.
30. • 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.
• Unlike components (which exist at run time), a
package is purely conceptual (meaning that it exists
only at development time).
• Graphically, a package is rendered as a tabbed
folder, usually including only its name and,
sometimes, its contents.
31. d) Annotational Things:
• Annotational things are the explanatory parts of
UML models.
• These are the comments you may apply to describe
about any element in a model.
• There is one primary kind of annotational thing,
called a note.
• A note is 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.
32. Building Blocks of UML:
2. Relationships in the UML:
• There are four kinds of relationships in the UML:
1. Dependency.
2. Association.
3. Generalization.
4. Realization.
• These relationships are the basic relational building
blocks of the UML.
• We use them to write well-formed models.
33. 1. A Dependency is a semantic relationship between
two things in which a change to one thing may
affect the semantics of the other thing.
• Graphically, a dependency is rendered as a dashed
line, possibly directed, and occasionally including a
label.
34. 2. An Association is a structural relationship that
describes a set of links, a link being a connection
among objects.
• 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 role names.
35. 3. A Generalization is a relationship in which objects
of the specialized element (the child) are
substitutable for objects of the generalized element
(the parent).
• In this way, 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.
36. 4. 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.
37. C) 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 arcs (relationships).
• You draw diagrams to visualize a system from
different perspectives.
• A diagram is a projection into a system.
• In theory, a diagram may contain any combination
of things and relationships.
38. • For this reason, the UML includes nine such
diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
39. • A Class diagram shows a set of classes, interfaces,
and collaborations and their relationships.
• These diagrams are the most common diagram
found in modeling object-oriented systems.
• Class diagrams address the static design view of a
system.
• Class diagrams that include active classes address
the static process view of a system.
40. • 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.
41. • A Use case diagram shows a set of use cases and
actors (a special kind of class) and their
relationships.
• Use case diagrams address the static use case view
of a system.
• These diagrams are especially important in
organizing and modeling the behaviors of a system.
42. • Both sequence diagrams and Collaboration
diagrams are kinds of interaction diagrams.
• Interaction diagrams address the dynamic view of a
system.
• A sequence diagram is an interaction diagram that
emphasizes the time-ordering of messages.
• A collaboration diagram is an interaction diagram
that emphasizes the structural organization of the
objects that send and receive messages.
• Sequence diagrams and collaboration diagrams are
isomorphic, meaning that you can take one and
transform it into the other.
43. • A Statechart diagram shows a state machine,
consisting of states, transitions, events, and
activities.
• Statechart diagrams address the dynamic view of a
system.
• They are especially important in modeling the
behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of an object,
which is especially useful in modeling reactive
systems.
44. • An Activity diagram is a special kind of a statechart
diagram that shows the flow from activity to activity
within a system.
• Activity diagrams address the dynamic view of a
system.
• They are especially important in modeling the
function of a system and emphasize the flow of
control among objects.
45. • A Component diagram shows the organizations and
dependencies among a set of components.
• Component diagrams address the static
implementation view of a system.
• A deployment diagram shows the configuration of
run-time processing nodes and the components
that live on them.
• Deployment diagrams address the static
deployment view of an architecture.
• They are related to component diagrams in that a
node typically encloses one or more components.
46. 2. Rules of the UML:
• UML has a number of rules that specify what a well-formed
model should look like. A well-formed model is one that is
semantically self-consistent and in harmony with all its
related models. The UML has semantic rules for:
a) Names: What you can call things, relationships, and
diagrams.
b) Scope: The context that gives specific meaning to a name.
c) Visibility: How those names can be seen and used by
others.
d) Integrity: How things properly and consistently relate to
one another.
e) Execution: What it means to run or simulate a dynamic
model.
47. 3. Common Mechanisms in the UML
• Four Common mechanisms that apply consistently
throughout UML are:
I. Specifications.
II. Adornments.
III. Common divisions.
IV. Extensibility mechanisms.
48. • Adornments: Class's specification may include
other details, such as whether it is abstract or the
visibility of its attributes and operations.
• For example, below diagram shows a class, adorned
to indicate that it is an abstract class with two
public, one protected, and one private operation.
49. Common Divisions
• There is the division of class and object.
• A class is an abstraction; an object is one concrete
manifestation of that abstraction.
• In the UML, you can model classes as well as
objects, as shown below.
51. • A stereotype extends the vocabulary of the UML,
allowing you to create new kinds of building blocks
that are derived from existing ones but that are
specific to your problem i.e that they are treated
like basic building blocks—by marking them with an
appropriate stereotype, as shown below.
52. • A tagged value extends the properties of a UML
building block, allowing you to create new
information in that element's specification.
• A Constraint extends the semantics of a UML
building block, allowing you to add new rules or
modify existing ones.
• In other words a constraint is a condition such as an
attribute having a specific value.
53. Systems Architecture:
• Visualizing, specifying, constructing, and
documenting a software-intensive system demands
that the system be viewed from a number of
perspectives.
• 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.
54. • Software architecture is not only concerned with
structure and behavior, but also with usage,
functionality, performance, reuse, economic and
technology constraint.
55. • The architecture of a software-intensive system can
best be described by five interlocking views.
• Each view is a projection into the organization and
structure of the system, focused on a particular
aspect of that system as explained below:
1. 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.
56. 2.The design view of a system encompasses the
classes, interfaces, and collaborations that form the
vocabulary of the problem and its solution. This
view primarily supports the functional requirements
of the system, meaning the services that the system
should provide to its end users.
3.The process view of a system encompasses the
threads and processes that form the system's
concurrency and synchronization mechanisms. This
view primarily addresses the performance,
scalability, and throughput of the system.
57. 4. The implementation view of a system
encompasses the components and files that are
used to assemble and release the physical system.
This view primarily addresses the configuration
management of the system's releases.
5. The deployment view of a system encompasses the
nodes that form the system's hardware topology on
which the system executes. This view primarily
addresses the distribution, delivery, and installation
of the parts that make up the physical system.
58. Software Development Life Cycle:
• The UML is largely process-independent, meaning
that it is not tied to any particular software
development life cycle.
• However, to get the most benefit from the UML,
you should consider a process that is
1. Use case driven.
2. Architecture-centric.
3. Iterative and incremental.
60. 1. Use case driven means that use cases are used as a
primary artifact for establishing the desired
behavior of the system, for verifying and validating
the system's architecture, for testing, and for
communicating among the stakeholders of the
project.
2.Architecture-centric means that a system's
architecture is used as a primary artifact for
conceptualizing, constructing, managing, and
evolving the system under development.
61. 3. An iterative process is one that involves managing
a stream of executable releases.
• An iterative and incremental process is risk-driven,
meaning that each new release is focused on
attacking and reducing the most significant risks to
the success of the project.
