OBJECT-ORIENTED MODELING and DESIGN in UML

1
OBJECT-ORIENTED MODELING and DESIGN inUML
2

• Object oriented modeling and design is a way of
  thinking about problems using models organized
  around real-world concepts. The fundamental
  construct is the object, which combines both data
  structure and behavior. OO models are useful for
  understanding problems, communicating with
  application experts, modeling enterprises,
  preparing documentation and designing programs
  and databases.

3

• What is Object Orientation
• The term Object Oriented means that we
  organize software as a collection of discrete
  objects that incorporate both data structure and
  behavior.
• Identity means that data is quantized into
  discrete, distinguishable entities called
  OBJECTS. Each object has its own inherent
  identity, ie two objects are distinct even if all
  their attribute values are identical

4

• Classification means that objects with same data
  structure and behavior are grouped into a class.
  A class is abstraction that describes properties
  important to an application and ignores the rest.

Object Class
Bicycle Attributes framesize wheelzise material Operations shift, Move, repair
5

• Inheritance
• Sharing of attributes and operations among
  classes based on a hierarchical relationship.
  Inheritance (by D from C) is the facility by
  which a class D has implicitly defined upon it
  each of the attributes and operations of class C,
  as if those attributes and operations had been
  defined upon D itself.
• C is termed a super class of D
• D is a subclass of C

6

• Polymorphism
• It is the facility by which a single operation
  or attribute name may be defined upon more than
  one class and may take on different
  implementations in each of those classes.
• It is the property whereby an attribute or
  variable may point to (hold the handle of)
  objects of different classes at different times.
  The same operation may behave differently for
  different classes.

7

• Encapsulation
• It is the grouping of related ideas into one
  unit, which can thereafter be referred to by a
  single name.
• Object oriented encapsulation
• It is the packing of operations and attributes
  representing state into an object type so that
  state is accessible or modifiable only via the
  interface provided by the encapsulation

8

• Information/Implementation hiding
• It is the use of encapsulation to restrict from
  external visibility certain information or
  implementation decisions that are internal to the
  encapsulation structure.
• Object identity
• It is the property by which each object can be
  identified and treated as a distinct software
  entity
• State Retention
• It is the ability of an object to retain the
  state.

9

• Messages
• A message is a vehicle by which a sender object
  obj1 conveys to a target object obj2, a demand
  for the object obj2 to apply one of its methods
• Message Structure
• The handle of the object obj2
• The name of the operation pf obj2 that obj1
  wishes to execute
• Any supplementary information that obj2 will
  require in the execution of its operation

10

• Object Oriented Methodology
• The process consists of building a model of an
  application and then adding the details to it
  during design.
• System Conception Software development begins
  with business analysis or users conceiving an
  application and formulating tentative
  requirements.
• Analysis The analysis scrutinizes and rigorously
  restates the requirements from system conception
  by constructing models.

11
The analysis model has two parts. The domain
model, a description of the real-world objects
reflected within the system and the application
model, a description of the parts of the
application system itself that are visible to the
user. System Design The development team
devise a high-level strategy (system
architecture) for solving the application
problem. Class design The class designer adds
details to analysis model in accordance with the
system design strategy. The class designer
elaborates both domain and application objects
using the same OO concepts and notation.
12
Implementation Implementers translate the
classes and relationships developed during class
design into a particular programming language,
database or hardware. Programming should be
straight-forward. It is important to follow good
software engineering practice so that
traceability to design is apparent and so that
the system remains flexible and extensible.
The three models We use three kinds of models
to describe a system from different viewpoint.
The class model describes the static structure
of the objects in a system and their relation
ships. It defines the context for software
development.
13
A class diagram is a graph whose nodes are
classes and whose arcs are relationships among
classes. The state model describes the aspects
of an object that change over time. The state
model specifies and implements control with state
diagrams. It is a graph whose nodes are states
and whose arcs are transitions between states
caused by events. The interaction model
describes how the objects in a system cooperate
to achieve broader results. The interaction model
starts with use cases that are then elaborated
with sequence and activity diagrams.
14
A use case focuses on the functionality of a
system (what the system does for the user). A
sequence diagram shows the objects that interact
and the time sequences of their interactions. An
activity diagram elaborates important processing
steps. The three models are separate parts of
the description of a complete system but are
cross-linked. The class model is most
fundamental, because it is necessary to describe
what is changing or transforming before
describing when or how it changes.
15

• Object Oriented Themes
• Abstraction
• Encapsulation
• Combining Data and Behavior
• Sharing
• Emphasis on the Essence of an Object
• Synergy (combined effort)

16
Introduction to Unified Modeling Language
17
What is UML?

• UML (Unified Modeling Language) is a language
• For specifying, visualizing, constructing, and
  documenting the artifacts of software systems
• For business modeling and other non-software
  systems
• UML Definition consists of
• UML Semantics
• UML Notation Guide
• UML Extensions

18
Why UML?

• Motivation
• Good models are essential for communication among
  project teams and to assure architectural
  soundness
• Goals in the design of the UML
• Provide users a ready-to-use, expressive visual
  modeling language so they can develop and
  exchange meaningful models.
• Provide extensibility and specialization
  mechanisms to extend the core concepts.
• Be independent of particular programming
  languages and development processes.
• Provide a formal basis for understanding the
  modeling language.
• Encourage the growth of the OO tools market.
• Support higher-level development concepts such as
  collaborations, frameworks, patterns, and
  components.
• Integrate best practices.

19
UML Artifacts

• Use Case diagram
• Implementation diagrams
• Component diagram
• Deployment diagram
• Behavior diagrams
• State chart diagram
• Activity diagram
• Interactive diagram
• Sequence diagram
• Collaboration diagram
• Class diagram

20
Use Case Diagram
21
Implementation Diagram
Example Component diagram
22
Behavior Diagram
Example Interaction diagram
23
Class Diagram
24
Implementation Diagram
Example Deployment diagram
25
Class Modeling

• The purpose of the class modeling is to describe
  objects. An object is a concept, abstraction or
  thing with identity that has meaning for an
  application objects often appear as proper nouns
  or specific references in problem descriptions.
  Some objects have real-world counterparts, while
  others are conceptual entities. Still others are
  introduces for implementation reasons and have no
  correspondence to physical reality. The choice of
  objects depends on judgment and the nature of a
  problem.

26
The Class

• The class symbol (a) is central to any
  application of UML. The topmost of the symbols
  three components shows the class name, by
  convention starting with an uppercase letter.
  This ones imaginatively named SomeClass.
• The middle compartment shows the attributes
• The bottom compartment shows its operations

27
The Class

• The alternative symbol for the class is (b). This
  abbreviated symbol is handy when you want to show
  only a class and its name.

• Equivalent symbols for depicting an object

28
The Attributes

• An attribute represents information about an
  object
• An attribute represents an abstractly defined
  property, independent of how that property is
  internally implemented. A variable is an internal
  implementation mechanism.
• An attribute is both gettable and settable from
  outside the object.
• Some attributes are read only (gettable)
• Typically the attributes are derived from others
• Eg age of a person, capacity of a cuboid

29
The Attributes

• Read only attributes can be represented with a
  forward slash (/)

30
The Operations

• Operations appear in the lowest compartment with
  their full formal signature. Each of the
  signature comprises the operation name, together
  with the list of operations formal input and
  output arguments. The UML standard calls for the
  keywords in and out before each argument to show
  its direction.

31
The Operations

• A typical attribute require two standard
  operations a get operation and a set operation.
• An attribute thats read only doesnt need a set
  operation
• A few attributes call for operations that need
  input arguments. Such attributes often hold data
  on the previous history of that attribute.
• Some operations require communication with other
  objects through message passing.

32
Overloaded Operations

• Operations that are overloaded will appear many
  times on the class diagram, each time with a
  different signature.

33
Visibility of Attributes and Operations

• UML attaches a prefix to an attribute or
  operation name to indicate the features
  visibility. Public attributes or operations are
  prefixed with a plus sign (). Protected with a
  number sign () and private with a minus sign (-).

34
Class Attributes and Operations

• A public class attribute an d a private class
  operation

35
Abstract Operations and Classes

• An operation is abstract if it has no
  implementation.
• It has an interface and a defined functionality,
  but no implementation method with actual code
• An abstract class does not instantiate objects,
  usually, because it has at least one abstract
  operation defined on it.

36
The Utility

• The utility (utility package) is a group of
  procedures and functions encapsulated into a
  single unit with a set of private data. It
  differs from the class in that individual objects
  are never instantiated from it
• The utility is like a class with no objects its
  operations are, in effect, class operations.

37
Parameterized Classes

• UML shows a parameterized class with a dotted box
  over the top right of the standard class symbol.
  Into this box goes the list of formal class
  arguments

• A typical container class, which takes a class
  formally named T as an argument

38
Parameterized Classes

• When an actual class, such as Car is supplied for
  T, each of the objects of that class represent a
  set of cars. The name of the bound, parameterized
  class is then given as SetltCargt

• A bound class, formed from a parameterized class

39
Parameterized Classes

• A bound class, formed from parameterized class
  another depiction

40
CLASS DIAGRAMS
41

• Generalization Concepts
• Single Inheritance
• Multiple Inheritance
• Subclass Paritioning
• Partitioning discriminators

42
Single Inheritance
43
Single Inheritance hierarchy Shared Target
notation
44
Single Inheritance hierarchy Normal abbreviated
notation
45
Multiple Inheritance
46
Subclass Partitioning
The term disjoint partitioning applies to two or
more groups of things that are cleanly
partitioned. ie no single thing can belong to
more than one group at the same time.
The term incomplete partitioning means that not
all of the groups possible subgroups are
included in the model. ie the group may have some
members that dont belong to any of the modeled
subgroups
47
Subclass Partitioning
The term dynamic partitioning to a things
membership in more than one subgroup over time ie
a thing may begin life as a member of one
subgroup but later become a member of different
subgroup
48
Subclass Partitioning
Animals overlapping subclasses, Herbivore and
Carnivore could have a common subclass Omnivore
49
Partitioning Discriminators
50
The Association Construct
Objects are often associated with, or related
to, other objects. For example Students are
ON WAITING LIST for seminars, professors INSTRUCT
seminars, seminars are an OFFERING OF courses, a
professor LIVES AT an address, and so on.
Associations are modeled as lines connecting
the two classes whose instances (objects) are
involved in the relationship. When you model
associations in UML class diagrams, you show them
as a thin line connecting two classes.
51
The Association Construct
Associations can become quite complex
consequently, you can depict some things about
them on your diagrams. The label, which is
optional, although highly recommended, is
typically one or two words describing the
association. For example, professors instruct
seminars.
Associations are often two-way streets. The
multiplicity of the association is labeled on
either end of the line, one multiplicity
indicator for each direction
52
The Association Construct
53
The Association Construct
Association in UML represents a varying
population of relationship links between
instances of classes. Modeling associations is
the backbone of a powerful analysis technique
called information modeling An association or
relationship is usually named with a verb form in
traditional information modeling Some
multiplicity may be debatable UML doesnt insist
on a name for an association. UML doesnt require
role names either. UML modeling tools often
abbreviate multiplicity like 0..
54
Higher-order Association
55
Higher-order Association
56
Whole/Part Association
UML has special notation for two who/part
associations composition and aggregation Compos
ition is a common structure in software systems.
Eg an e-mail missive is a composite containing a
header and a few text paragraphs. In turn, the
header is a composite of the senders name, the
receivers address, the message title and some
other e-stuff. The composite object does not
exist without its components. At any time, given
component object may be part of only one
composite. Composition is typically heteromeric
57
Composition
The role of the component object in the
composition appears at the component end of the
association line. If the multiplicity at the
composite end is not shown then it is assumed to
be exactly 1. The association has no name
58
Aggregation
Like composition aggregation is a familiar
construct whereby software systems represent
structures from real life. For example, a city is
an aggregate of houses, a forest is an aggregate
of trees etc. In other words aggregation is a
group/member association.
59
Some Observations An association between the
aggregate and its constituent is denoted by a
little open diamond on the aggregate end of the
association line. The classes of the aggregate
and the constituent appear at the respective ends
of the association line. The role of the
constituent object also appears at the
constituent end of the association
line. Multiplicity 0.. means a paragraph may
belong to many management report at the same time
and a management report may comprise many
paragraphs The ordered property on the
association reveals that the paragraphs are in a
defined sequence.
60
Assignment 1 What makes a good Model? When to
apply UML? How to apply UML?