UNIT - II

 Introduction to UML:
 Importance of modeling,
 principles of modeling,
 object oriented modeling,
 conceptual model of the UML,
 Architecture, and Software Development Life Cycle.
 Basic Structural Modeling:
 Classes,
 Relationships,
 common Mechanisms, and diagrams.
 Case Study: Control System: Traffic Management.
 BASIC STRUCTURAL MODELING
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.
 The UML provides a graphical representation of class.

s/w things
h/w things
Purely
conceptual
TERMS AND CONCEPTS
 Names
 Attributes
 Operations
 Organizing Attributes and Operations
 Responsibilities
TERMS AND CONCEPTS
 Names
 Every class must have a name that distinguishes it from other
classes.
 A name is a textual string that name alone is known as a simple
name – short noun or noun phrase
 A path name is the class name prefixed by the name of the
package in which that class lives.
TERMS AND CONCEPTS
 Attributes
 An attribute is a named property of a class that describes a range
of values that instances of the property may hold.
 A class may have any number of attributes or no attributes at all.
 You can further specify an attribute by stating its class and possibly
a default initial value.
 Operations
 An operation is the implementation of a service that can be
requested from any object of the class to affect behavior.
 A class may have any number of operations or no operations at all
 Graphically, operations are listed in a compartment just below
the class attributes
 You can specify an operation by stating its signature, covering the
name, type, and default value of all parameters and a return type.

invoking an
operation on an
object changes
the data/state

Fig: Operations
 Organizing Attributes and Operations
 To better organize long lists of attributes and operations, you can also
prefix each group with a descriptive category by using
stereotypes
 Responsibilities
 A Responsibility is a contract or an obligation of a class.
 When you model classes, a good starting point is to specify the
responsibilities of the things in your vocabulary.
 A class may have any number of responsibilities, although, in
practice, every well-structured class has at least one
responsibility and at most just a handful.
 Graphically, responsibilities can be drawn in a separate compartment
at the bottom of the class icon

Credit Card Application

Processing orders,
Determing – legitimate
Phrase or
suspect sentence or
fraudulent short paragraph
COMMON MODELING TECHNIQUES
 Modeling the Vocabulary of a System
 Modeling the Distribution of Responsibilities in a System

 Modeling Non-software Things

 Modeling Primitive Types

 Modeling the Vocabulary of a System
 You'll use classes most commonly to model abstractions
that are drawn from the problem you are trying to solve or
from the technology you are using to implement a solution to
that problem.

 To model the vocabulary of a system

 Identify those things that users or implementers use to
describe the problem or solution.
 Use CRC cards and usecase-based analysis to help find
these abstractions.
 For each abstraction, identify a set of responsibilities.
 Provide the attributes and operations that are needed to
carry out these responsibilities for each class.
 CRC- Class-Responsibility-Collaboration cards
Fig: Modeling the Vocabulary of a System

Track orders

Figure shows a set of classes drawn from a retail system

 Modeling the Distribution of Responsibilities in a
System
 Once you start modeling more than just a handful of classes,
you will want to be sure that your abstractions provide a
balanced set of responsibilities.
 To model the distribution of responsibilities in a system
 Identify a set of classes that work together closely to carry out
some behavior.
 Identify a set of responsibilities for each of these classes.
 Look at this set of classes as a whole, split classes that have
too many responsibilities into smaller abstractions,
 Consider the ways in which those classes collaborate with one
another, and redistribute their responsibilities accordingly
so that no class within a collaboration does too much or
too little.
Fig: Modeling the Distribution of Responsibilities in a System - smalltalk
 Modeling Non-software Things
 Sometimes, the things you model may never have an analog in
software
 To model non-software things
 Model the thing you are abstracting as a class.
 If you want to distinguish these things from the UML's defined building
blocks, create a new building block by using stereotypes to specify these
new semantics and to give a distinctive visual cue.
 If the thing you are modeling is some kind of hardware that itself
contains software, consider modeling it as a kind of node, as well, so
that you can further expand on its structure.
 Modeling Primitive Types
 At the other extreme, the things you model may be drawn
directly from the programming language you are using to
implement a solution.
 Typically, these abstractions involve primitive types, such as
integers, characters, strings, and even enumeration
types.
 To model primitive types
 Model the thing you are abstracting as a class type or an
enumeration, which is rendered using class notation with
the appropriate stereotype.
 If you need to specify the range of values associated with this
type, use constraints.
Fig: Modeling Primitive Types
 BASIC STRUCTURAL MODELING
RELATIONSHIPS
 In the UML, the ways that things can connect to one another,
either logically or physically, are modeled as relationships.
 In object-oriented modeling, there are three kinds of
relationships that are most important:
 Dependencies - using relationships among classes(trace&bind)
 Generalizations – link generalized classes to their
specializations
 Associations - structural relationships among instances/objects
 Graphically, a relationship is rendered as a path, with different
kinds of lines used to distinguish the kinds of relationships.
Fig: Relationships
TERMS AND CONCEPTS
 A relationship is a connection among things
 Dependencies
 A dependency is a relationship that states that a change in
specification of one thing may affect another thing that
uses it but not necessarily the reverse.
 Graphically dependency is rendered as a dashed directed
line, directed to the thing being depended on.

Fig: Dependencies
 Generalization
 A generalization is a relationship between a general
thing (called the super class or parent)and a more
specific kind of that thing (called the subclass or
child).
 Generalization means that the child is substitutable for
the parent. A child inherits the properties of its parents,
especially their attributes and operations
 Generalization is some times called as “is-a” kind of
relationship.
Fig: Generalization
 Association
 An association is a structural relationship that specifies that objects
of one thing are connected to objects of another
 An association that connects exactly two classes is called a
binary association
 An associations that connect more than two classes; these are
called n-ary associations.
 Graphically, an association is rendered as a solid line connecting the
same or different classes.
 Beyond this basic form, there are four adornments that apply to
associations
 Name

 Role

 Multiplicity

 Aggregation
 Name - An association can have a name, and you use that
name to describe the nature of the relationship

 Role - When a class participates in an association, it has a

specific role that it plays in that relationship;
 Multiplicity - it's important for you to state how many
objects may be connected across an instance of an
association
 This "how many" is called the multiplicity of an
association's role
 Aggregation - Sometimes, you will want to model a "whole/part"
relationship, in which one class represents a larger thing (the
"whole"), which consists of smaller things (the "parts"). “Has-A”
relationship

 Aggregation is really just a special kind of association and is

specified by adorning a plain association with an open diamond at
the whole end
COMMON MODELING TECHNIQUES FOR RELATIONSHIPS

 Modeling Simple Dependencies

 Modeling Single Inheritance

 Modeling Structural Relationships

 Modeling Simple Dependencies
 The most common kind of dependency relationship is the
connection between classes that only uses another class
as a parameter to an operation

To model simple dependencies

 Create a dependency pointing from the class with the
operation to the class used as a parameter in the operation.
 Modeling Single Inheritance
 To model single inheritance relationships
 Given a set of classes, look for responsibilities,
attributes, and operations that are common to two or
more classes.
 Elevate these common responsibilities, attributes, and
operations to a more general class. If necessary, create a
new class to which you can assign these
 Specify that the more-specific classes inherit from the
more-general class by placing a generalization
relationship that is drawn from each specialized class to its
more-general parent.
Fig: Inheritance Relationships – Trading Application
 Modeling Structural Relationships
 Given a generalization relationship between two classes, the child inherits
from its parent but the parent has no specific knowledge of its children.
 Dependency and generalization relationships are one-sided.
 Associations are, by default, bidirectional; you can limit their direction

 To model structural relationships

 For each pair of classes, if you need to navigate from objects of one to objects
of another, specify an association between the two. This is a data-driven
view of associations.
 For each pair of classes, if objects of one class need to interact with objects
of the other class other than as parameters to an operation, specify an
association between the two. This is more of a behavior-driven view of
associations.
 For each of these associations, specify a multiplicity (especially when the
multiplicity is not *, which is the default), as well as role names (especially if it
helps to explain the model).
 If one of the classes in an association is structurally or organizationally a
whole compared with the classes at the other end that look like parts,
mark this as and aggregation by adorning the association at the end near the whole
Fig: Modeling Structural Relationships
DIAGRAMS
 The UML defines nine kinds of diagrams, which you can mix and match to assemble each view.
 You’ll use the UML's diagrams in two basic ways:
 To specify models from which you'll construct an executable system (forward
engineering)
 To reconstruct models from parts of an executable system (reverse engineering)

 Terms and Concepts

System
A system is a collection of subsystems organized to accomplish a purpose and
described by a set of models, possibly from different viewpoints
Subsystem
A subsystem is a grouping of elements, of which some constitute a specification
of the behavior offered by the other contained elements.
Model
A model is a semantically closed abstraction of a system, meaning that it
represents a complete and self-consistent simplification of reality, created in order
to better understand the system. In the context of architecture
View
view is a projection into the organization and structure of a system's model,
focused on one aspect of that system
 Diagram
 A diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and arcs
(relationships).
 Typically, you'll view the static parts of a system using one of the four
following diagrams.
 Class diagram
 Object diagram Structural Diagrams
 Component diagram
 Deployment diagram

 You'll often use five additional diagrams to view the dynamic parts of
a system.
 Use case diagram
 Sequence diagram Behavioral Diagrams
 Collaboration diagram
 Statechart diagram
 Activity diagram.
 Structural Diagrams
 The UML's four structural diagrams exist to visualize,
specify, construct, and document the static aspects of a
system.
 The UML's structural diagrams are roughly organized
around the major groups of things you'll find when modeling
a system.
 Class diagram : Classes, interfaces, and
collaborations
 Object diagram : Objects

 Component diagram : Components

 Deployment diagram : Nodes

 Behavioral Diagrams
 The UML's five behavioral diagrams are used to visualize, specify,
construct, and document the dynamic aspects of a system.
 The UML's behavioral diagrams are roughly organized around the
major ways you can model the dynamics of a system.
 Use case diagram : Organizes the behaviors of the
system
 Sequence diagram : Focused on the time ordering of
messages
 Collaboration diagram : Focused on the structural
organization of objects that Send and receive messages
 Statechart diagram : Focused on the changing state of
a system driven by Events
 Activity diagram : Focused on the flow of control from
activity to Activity
Fig: Interaction Diagram at a High Level of Abstraction
Fig: Interaction at a Low Level of Abstraction