 ADVANCED STRUCTURAL MODELING:

ADVANCED CLASSES,
ADVANCED RELATIONSHIPS,
INTERFACES,
TYPES AND ROLES,
PACKAGES.
ADVANCED STRUCTURAL MODELING
Advanced Classes
 Classes - most important building
block of any object-oriented system.
 However, classes are just one kind of
an even more general building block
in the UML - classifiers.
 Classifiers (and especially classes)
have a
 number of advanced features beyond
the simpler properties of attributes and
operations
 You can model multiplicity, visibility,
signatures, polymorphism, and other
characteristics.
Fig: Advanced Classes
TERMS AND CONCEPTS
 Classifiers
 Visibility

 Instance and Static Scope

 Abstract, Leaf and Polymorphic Elements

 Multiplicity

 Attributes

 Operations

 Template Classes

 Standard Elements
 Classifiers
 A classifier is a mechanism that describes structural and behavioral
features.
 Classifiers - classes, interfaces, data types, signals, components, nodes,
use cases, and subsystems.
 Every instance of a classifier shares the same features definitions,
but each instance has its own value for each attribute

Fig: Classifiers
Visibility
 One of the most important details you can specify for a classifier's
attributes and operations is its visibility.
 The visibility of a feature specifies whether it can be used by
other classifiers.
 UML, you can specify any of four levels of visibility.
 (+)public – any outside classifier
 (#)Protected- descendant
 (-)Private- only classifier itself
 (~)Package- same package

Fig: Visibility
Instance and Static Scope
 Another important detail you can specify for a classifier's attributes
and operations is its owner scope.
 The owner scope of a feature specifies whether the feature appears
in each instance of the classifier has its own distinct values or
whether there is just a single value of the feature shared by all
instances of the classifier.
 In UML you can specify two kinds of owner scope.

static

static scope

Fig: Owner Scope

 Abstract, Leaf and Polymorphic Elements
 You use generalization relationships to model a lattice of classes, with
more generalized abstractions at the top of the hierarchy and more-specific
ones at the bottom.
 Within these hierarchies, it's common to specify that certain classes are
abstract - meaning that they may not have any direct instances.
 In the UML, you specify that a class is abstract by writing its name in italics.
 Operations have similar properties- operations is polymorphic means
 In hierarchy of classes-you can specify operations with the same signature at
different points in the hierarchy
 An operation in a child class overrides the behavior of a similar operation in the
parent class.
 When a message is dispatched at run time, the operation is invoked is chosen
polymorphically – match is determined at run time according to the type of the object
Fig: Abstract and Concrete Classes and Operations
Multiplicity
 The number of instances a class may have is called its
multiplicity. Multiplicity is a specification of the range of
allowable cardinalities an entity may assume.
 In the UML, you can specify the multiplicity of a class by writing a
multiplicity expression in the upper-right corner of the class icon.

For example, in Figure

NetworkController is a
singleton class. Similarly, there
are exactly three instances of
the class ControlRod in the
system.
Fig: Multiplicity
Attributes
 At the most abstract level, when you model a class's structural features
(that is, its attributes), you simply write each attribute's name.
 You can also specify the visibility, scope, and multiplicity of each attribute.
There's still more. You can also specify the type, initial value, and
changeability of each attribute.
 In its full form, the syntax of an attribute in the UML is
[Visibility] name [multiplicity] [: type] [= initial-value] [{property-string}]
 For example, the following are all legal attribute declarations:
Operations
 At the most abstract level, when you model a class's behavioral features
(that is, its operations and its signals), you will simply write each
operation's name
 You can also specify the visibility and scope of each operation.
 You can also specify the parameters, return type, concurrency
semantics, and other properties of each operation. Collectively, the
name of an operation plus its parameters (including its return type,
if any) is called the operation's signature.
 The UML distinguishes between operation and method.
 An operation specifies a Service that can be requested from any object of
the class to affect behavior;
 A method is an implementation of an operation. Every non abstract
operation of a class must have a method, which supplies an executable
algorithm as a body.
 In its full form, the syntax of an operation in the UML is
[Visibility] name [(parameter-list)] [: return-type] [{property-string}]
 For example, the following are all legal operation declarations:

 In an operation's signature, you may provide zero or more

parameters, each of which follows the Syntax
[direction] name : type [= default-value]
 Direction may be any of the following values:
 In addition to the leaf and abstract property described earlier, there
are four defined properties that you can use with operations
 Template Classes
 A template is a parameterized element.
 A template includes slots for classes, objects, and values, and these slots serve as the
template's parameters.
 You can't use a template directly; you have to instantiate it first. Instantiation
involves binding these formal template parameters to actual ones.
 For a template class, the result is a concrete class that can be used just like any ordinary
class.
 The most common use of template classes is to specify containers that can be
instantiated for specific elements, making them type-safe.
 For example, the following C++ code fragment declares a parameterized Map class.
template<class Item, class Value, int Buckets>
class Map {
public:
virtual Boolean bind(const Item&, const Value&);
virtual Boolean isBound(const Item&) const;
...
};
 You might then instantiate this template to map Customer objects to Order objects.
m : Map<Customer, Order, 3>;
 You can model the instatantiaon of template classes in two –ways in
the UML . As Figure shows, you render a Template class just as you do
an ordinary class, but with an additional dashed box in the upper
right corner of the class icon, which lists the template parameters.

Fig: Template Classes

 Standard Elements
 All of the UML's extensibility mechanisms apply to classes. Most often,
you'll use tagged values to extend class properties (such as specifying
the version of a class) and stereotypes to specify new kinds of
components (such as model- specific components).
 The UML defines four standard stereotypes that apply to classes.
 Common Modeling Techniques
 Modeling the Semantics of a Class
 Specify the responsibilities of the class. A responsibility is a contract or obligation of a
type or class and is rendered in a note (stereotyped as responsibility) attached to the
class, or in an extra compartment in the class icon.
 Specify the semantics of the class as a whole using structured text, rendered in a
note (stereotyped as semantics) attached to the class.
 Specify the body of each method using structured text or a programming
language, rendered in a note attached to the operation by a dependency relationship.
 Specify the pre- and post-conditions of each operation, plus the invariants of the
class as a whole, using structured text. These elements are rendered in notes
(stereotyped as precondition, postcondition, and invariant) attached to the operation or
class by a dependency relationship.
 Specify a state machine for the class. A state machine is a behavior that specifies the
sequences of states an object goes through during its lifetime in response to events,
together with its responses to those events.
 Specify a collaboration that represents the class. A collaboration 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. A collaboration has a structural part, as well as
a dynamic part, so you can use collaborations to specify all dimensions of a class's
semantics.
 Specify the pre- and post-conditions of each operation, plus the invariants of the
class as a whole, using a formal language such as OCL.
 ADVANCED RELATIONSHIPS
 A relationship is a connection among things. In object-oriented
modeling, the four most important relationships are dependencies,
generalizations, associations, and realizations.
 Graphically, a relationship is rendered as a path, with different kinds
of lines used to distinguish the different relationships.