lOMoAR cPSD| 19893192

UNIT III

Class & Object Diagrams: Terms, concepts, modeling techniques for Class & Object Diagrams.
Advanced Structural Modeling: Advanced classes, advanced relationships, Interfaces, Types
and Roles, Packages. Case Study: AI: Cryptanalysis.

Class Diagrams
Class diagrams are most commonly found diagrams while modeling software systems. A class
diagram consists of classes, collaborations and interfaces. A class diagram is used to model the
static design view of the system.
Common Properties:
The class diagram shares the common properties with the rest of the diagrams, a name and
graphical elements that are a projection into the model. What distinguish the class diagram from
the others are the contents of the diagram.
Contents:
Class diagram contains the following:
Classes
Interfaces
Collaborations
Generalization, dependencies and associations
Like other diagrams, class diagrams may also contain notes and constraints. Class diagrams may
also contain packages or subsystems which are used to organize the elements into groups.
Generally, the class diagrams are used for:
Modeling the vocabulary of the system
Modeling the collaborations
Modeling the logical database schema
Common Modeling Techniques
Modeling Simple Collaborations:
To model simple collaborations,
1. Identify the function or behavior of the part of a system you would like to model.
2. For each function or mechanism identify the classes, interfaces, collaborations and relationships
between them.
3. Use scenarios (sequence of activities) to walk through these things. You may find new things or
find that existing things are semantically wrong.
4. Populate the things found in the above steps. For example, take a class and fill its
responsibilities. Now, convert these responsibilities into attributes and operations.
Modeling a Logical Database Schema:
To model a schema,
1. Identify the classes whose state must be saved over the lifetime of the application.
2. Create a class diagram and mark these classes as persistent by using tagged values.
3. Provide the structural details for these classes like the attributes, associations with other classes
and the multiplicity.
4. Minimize the common patterns which complicate the physical database design like cyclic
associations, one-to-one associations and n-ary associations.
5. Provide the behavior for these classes by listing out the operations that are important for data
access and integrity.
6. Wherever possible, use tools to convert the logical design to physical design.
Forward and Reverse Engineering:
To forward engineer a class diagram,
1. Identify the rules for mapping the models to the implementation language of your choice.
2. Depending on the semantics of the language, you may want to restrict the information in your
UML models. For example, UML supports multiple inheritance. But some programming
languages might not allow this.
3. Use tagged values to specify the target language.
4. Use tools to convert your models to code.
To reverse engineer the code,
1. Identify the rules for mapping the implementation language to a model.
 lOMoAR cPSD| 19893192

2. Using a tool, navigate to the code that you want to reverse engineer. Use the tool to generate a
new model.
Object diagrams
An object diagram models the instances of classes in a class diagram. An object diagram contains
objects and links connecting the related objects. Object diagrams allow us to model the static
design view or static process view. It involves
modeling a snapshot of the system which contains objects (instances), their state and links
between objects.
An object diagram represents the static part of an interaction
containing the objects that communicate and the links between them without any messages.
Common Properties:
An object diagram shares the same common properties like the rest of the diagrams, a name which
identifies the diagram and graphical contents which are a projection into the model. What
distinguish an object diagram from the rest of the diagrams are its contents.
Contents:
Object diagrams contain:
Objects
Links
Like all other diagrams, object diagrams may contain notes and constraints. Object diagrams may
also contain packages and subsystems which are used to group the related elements in the model
together. Sometimes we can also include classes in the object diagrams. Generally, object
diagrams are used to model the object structures.
Common Modeling Techniques
Modeling Object Structures:
To model an object structure,
1. First, identify the function or behavior or part of a system you want to model as collect ion of
classes, interfaces and other things.
2. For each function or mechanism identify the classes and interfaces that collaborate and also
identify the relationships between them.
3. Consider a scenario (context) that walks through this mechanism and freeze at a moment in
time and identify the participating objects.
4. Represent the state of objects by listing out the attributes and their values.
5. Represent the links between objects which are instances of associations.
Forward and Reverse Engineering:
Forward engineering a object diagram is theoretically possible but practically of limited value as
the objects are created and destroyed dynamically at runtime, we cannot represent them statically.
To reverse engineer a object diagram,
1. Choose the target (context) you want to reverse engineer.
2. Use a tool to stop execution at a certain moment in time.
3. Identify the objects that collaborate with each other and represent them in an object diagram.
4. To understand their semantics, expose these object’s states.
5. Also identify the links between the objects to understand their semantics.
 lOMoAR cPSD| 19893192

Advanced Structural Modeling

ADVANCED CLASSES

A classifier is a mechanism that describes structural and behavioral features. Classifiers

include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

The most important kind of classifier in the UML is the class. A class is a description of a set
of objects that share the same attributes, operations, relationships, and semantics. Classes are
not the only kind of classifier, however. The UML provides a number of other kinds of
classifiers to help you model.

• Interface A collection of operations that are used to specify a service of a class or a component
• Datatype A type whose values have no identity, including primitive built-in types (such as
numbers and strings), as well as enumeration types (such as Boolean)
• Signal The specification of an asynchronous stimulus communicated between instances
•Component A physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces
• Node A physical element that exists at run time and that represents a computational
resource, generally having at least some memory and often processing capability
• Use case A description of a set of a sequence of actions, including variants, that a system
performs that yields an observable result of value to a particular actor
• Subsystem A grouping of elements of which some constitute a specification of the behavior
offered by the other contained elements

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. In the UML, you can specify any of three levels of visibility.

1. public Any outside classifier with visibility to the given classifier can use the feature;
specified by prepending the symbol +
2. protected Any descendant of the classifier can use the feature; specified by prepending the
symbol #
3. private Only the classifier itself can use the feature; specified by prepending the symbol -
 lOMoAR cPSD| 19893192

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 or whether there is just a single instance of the feature for all
instances of the classifier. In the UML, you can specify two kinds of owner scope.

1. instance Each instance of the classifier holds its own value for the feature.
2. class There is just one value of the feature for all instances of the classifier.

Abstract, Root, 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. For example, as Figure shows, Icon, RectangularIcon, and ArbitraryIcon are all abstract
classes. By contrast, a concrete class (such as Button and OKButton) is one that may have
direct instances.

However, you can also specify that a class may have no children. Such an element is called a
leaf class and is specified in the UML by writing the property leaf below the class's name a class
may have no parents. Such an element is called a root class, and is specified in the UML by
writing the property root below the class's name.
Operations have similar properties. Typically, an operation is
polymorphic, which means that, in a hierarchy of classes, you can specify operations with the
same signature at different points in the hierarchy. Ones in the child classes override the behavior
of ones in the parent classes. When a message is dispatched at run time, the operation in the
 lOMoAR cPSD| 19893192

hierarchy that is invoked is chosen polymorphically—that is, a match is determined at run time
according to the type of the object.
For example, display and isInside are both polymorphic operations.
Furthermore, the operation Icon::display() is abstract, meaning that it is incomplete and requires a
child to supply an implementation of the operation. In the UML, you specify an abstract operation
by writing its name in italics, just as you do for a class. By contrast, Icon::getID() is a leaf
operation, so designated by the property leaf. This means that the operation is not polymorphic
and may not be overridden.
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.

Multiplicity applies to attributes, as well. You can specify the multiplicity of an attribute
by writing a suitable expression in brackets just after the attribute name. For example, in
the figure, there are two or more consolePort instances in the instance of
NetworkController.

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. That's usually enough information for
the average reader to understand the intent of your model. As the previous sections have
described, however, 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:

origin Name only

+origin Visibility and name
origin : Point Name and type
head : *Item Name and complex type

name [0..1] : String Name, multiplicity, and type

origin : Point = (0,0) Name, type, and initial value
id : Integer {frozen} Name and property
 lOMoAR cPSD| 19893192

There are three defined properties that you can use with attributes.

1. changeable There are no restrictions on modifying the attribute's value.

2. addOnly For attributes with a multiplicity greater than one, additional values may be
added, but once created, a value may not be removed or altered.
3. frozen The attribute's value may not be changed after the object is initialized.

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. That's usually
enough information for the average reader to understand the intent of your model. As the
previous sections have described, however, you can also specify the visibility and scope of
each operation. There's still more: 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.
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:

display Name only

+ display Visibility and name
set(n : Name, s : String) Name and parameters
getID() : Integer Name and return type
restart() {guarded} Name and property

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 An input parameter; may not be modified

out An output parameter; may be modified to communicate information to the caller

inout An input parameter; may be modified

In addition to the leaf property described earlier, there are four defined properties that you
ca
n 1. isQuery Execution of the operation leaves the state of the system unchanged. In
us other words, the operation is a pure function that has no side effects.
e 2. sequential Callers must coordinate outside the object so that only one flow is in the
w object at a time. In the presence of multiple flows of control, the semantics
it and integrity of the object cannot be guaranteed.
h
o 3. guarded The semantics and integrity of the object is guaranteed in the presence of
pe ol byflows
multiple sequentializing all calls toIn all
of contr operations. of the object's this
effect,exactucing guarded
to sequential
ra y one
semantics. operation at a time can be invoked on the object, red
tions.
 lOMoAR cPSD| 19893192

4. concurrent The semantics and integrity of the object is guaranteed in the presence of
multiple flows of control by treating the operation as atomic. Multiple calls from
concurrent flows of control may occur simultaneously to one object on any
concurrent operation, and all may proceed concurrently with correct semantics;
concurrent operations must be designed so that they perform correctly in the
case of a concurrent sequential or guarded operation on the same
object.

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.
Dependency
 A dependency is a using relationship, specifying that a change in the specification of one
thing may affect another thing that uses it, but not necessarily the reverse. Graphically, a
dependency is rendered as a dashed line
 There are 17 such stereotypes, all of which can be organized into six groups.
 First, there are eight stereotypes that apply to dependency relationships among classes and
objects in class diagrams.
Specifies that the source instantiates the target template using the given
1 bind actual parameters
2 derive Specifies that the source may be computed from the target
3 friend Specifies that the source is given special visibility into the target

4 instanceOf Specifies that the source object is an instance of the target classifier

5 instantiate Specifies that the source creates instances of the target

Specifies that the target is a powertype of the source; a powertype is a
6 powertype classifier whose objects are all the children of a given parent
7 refine Specifies that the source is at a finer degree of abstraction than the target
Specifies that the semantics of the source element depends on the
8 use semantics of the public part of the target

* There are two stereotypes that apply to dependency relationships among packages.
Specifies that the source package is granted the right to reference the
9 access elements of the target package
A kind of access that specifies that the public contents of the target
package enter the flat namespace of the source, as if they had been
10 import declared in the source

* Two stereotypes apply to dependency relationships among use cases:

11 extend Specifies that the target use case extends the behavior of the source
Specifies that the source use case explicitly incorporates the behavior of
12 include another use case at a location specified by the source

* There are three stereotypes when modeling interactions among objects.

Specifies that the target is the same object as the source but at a later
13 become point in time and with possibly different values, state, or roles
14 call Specifies that the source operation invokes the target operation
Specifies that the target object is an exact, but independent, copy of the
15 copy source
 lOMoAR cPSD| 19893192

* One stereotype you'll encounter in the context of state machines is

16 send Specifies that the source operation sends the target event

17 trace Specifies that the target is an historical ancestor of the source

Generalization
A generalization is a relationship between a general thing (called the superclass or
parent) and a more specific kind of that thing(called the subclass or child).
In a generalization relationship, instances of the child may be used anywhere instances of
the parent apply—meaning that the child is substitutable for the parent.
A plain, unadorned generalization relationship is sufficient for most of the
inheritance relationships you'll encounter. However, if you want to specify a shade of
meaning,
The UML defines one stereotype and four constraints that may be applied to
generalization relationships.

Specifies that the child inherits the implementation of the parent but
does not make public nor support its interfaces, thereby violating
1 implementation substitutability

Next, there are four standard constraints that apply to generalization relationships
Specifies that all children in the generalization have been specified in the
1 complete model and that no additional children are permitted
Specifies that not all children in the generalization have been specified
2 incomplete (even if some are elided) and that additional children are permitted
Specifies that objects of the parent may have no more than one of the
3 disjoint children as a type
Specifies that objects of the parent may have more than one of the
4 overlapping children as a type

Association
An association is a structural relationship, specifying that objects of one thing
are connected to objects of another.
We use associations when you want to show structural relationships.
There are four basic adornments that apply to an association: a name, the role at each
end of the association, the multiplicity at each end of the association, and aggregation.
For advanced uses, there are a number of other properties you can use to model subtle
details,
such as
Navigation
Vision
Qualification
various flavors of aggregation.
Navig
ation
 Unadorned association between two classes, such as Book and Library, it's
possible to navigate from objects of one kind to objects of the other kind.
Unless otherwise specified, navigation across an association is bidirectional.
 However, there are some circumstances in which you'll want to limit navigation to just one
direction.
 lOMoAR cPSD| 19893192

Generalization
A generalization is a relationship between a general thing (called the superclass or
parent) and a more specific kind of that thing(called the subclass or child).
In a generalization relationship, instances of the child may be used anywhere instances of
the parent apply—meaning that the child is substitutable for the parent.
A plain, unadorned generalization relationship is sufficient for most of the
inheritance relationships you'll encounter. However, if you want to specify a shade of
meaning,
The UML defines one stereotype and four constraints that may be applied to
generalization relationships.

Specifies that the child inherits the implementation of the parent but
does not make public nor support its interfaces, thereby violating
1 implementation substitutability

Next, there are four standard constraints that apply to generalization relationships
Specifies that all children in the generalization have been specified in the
1 complete model and that no additional children are permitted
Specifies that not all children in the generalization have been specified
2 incomplete (even if some are elided) and that additional children are permitted
Specifies that objects of the parent may have no more than one of the
3 disjoint children as a type
Specifies that objects of the parent may have more than one of the
4 overlapping children as a type

Association
An association is a structural relationship, specifying that objects of one thing are
connected to objects of another.
We use associations when you want to show structural relationships.
There are four basic adornments that apply to an association: a name, the role at each
end of the association, the multiplicity at each end of the association, and aggregation.
For advanced uses, there are a number of other properties you can use to model subtle
details,
such as
Navigation
Vision
Qualification
various flavors of aggregation.

Navigation
Unadorned association between two classes, such as Book and Library, it's possible
to navigate from objects of one kind to objects of the other kind. Unless otherwise specified,
navigation across an association is bidirectional.
However, there are some circumstances in which you'll want to limit navigation to
just one direction.
 lOMoAR cPSD| 19893192

Visibility
 Given an association between two classes, objects of one class can see and navigate to
objects of the other, unless otherwise restricted by an explicit statement of navigation.
 However, there are circumstances in which you'll want to limit the visibility across
that association relative to objects outside the association.
 In the UML, you can specify three levels of visibility for an association end, just as
you can for a class's features by appending a visibility symbol to a role name the
visibility of a role is public.
 Private visibility indicates that objects at that end are not accessible to any objects
outside the association.
 Protected visibility indicates that objects at that end are not accessible to any objects
outside the association, except for children of the other end.

Qualification

In the context of an association, one of the most common modeling idioms you'll
encounter is the problem of lookup. Given an object at one end of an association, how do you
identify an object or set of objects at the other end?
In the UML, you'd model this idiom using a qualifier, which is an association
attribute whose values partition the set of objects related to an object across an association.
You render a qualifier as a small rectangle attached to the end of an association,
placing the attributes in the rectangle

Interface Specifier
An interface is a collection of operations that are used to specify a service of a class
or a component
Collectively, the interfaces realized by a class represent a complete specification of
the behavior of that class.
However, in the context of an association with another target class, a source class
may choose to present only part of its face to the world

a Person class may realize many interfaces: IManager, IEmployee, IOfficer, and so on you
can model the relationship between a supervisor and her workers with a one-to-many
 lOMoAR cPSD| 19893192

association, explicitly labeling the roles of this association as supervisor and worker
 In the context of this association, a Person in the role of supervisor presents only the
IManager face to the worker; a Person in the role of worker presents only the
IEmployee face to the supervisor. As
the figure shows, you can explicitly show the type of role using the syntax rolename :
iname, where iname is some interface of the other classifier.
Composition
 Simple aggregation is entirely conceptual and does nothing more than distinguish
a "whole" from a "part."
 Composition is a form of aggregation, with strong ownership and coincident
lifetime as part of the whole.
 Parts with non-fixed multiplicity may be created after the composite itself, but
once created they live and die with it. Such parts can also be explicitly removed
before the death of the composite.
 This means that, in a composite aggregation, an object may be a part of only one
composite at a time
 In addition, in a composite aggregation, the whole is responsible for the
disposition of its parts, which means that the composite must manage the creation
and destruction of its parts

Association Classes
 In an association between two classes, the association itself might have properties.
 An association class can be seen as an association that also has class properties,
or as a class that also has association properties.
 We render an association class as a class symbol attached by a dashed line to an
association

Constraints

UML defines five constraints that may be applied to association relationships.

Specifies that the relationship is not manifest but, rather, is only

1 implicit conceptual
Specifies that the set of objects at one end of an association are in an
2 ordered explicit order
3 changeable Links between objects may be added, removed, and changed freely
New links may be added from an object on the opposite end of the
4 addOnly association
A link, once added from an object on the opposite end of the
5 frozen association, may not be modified or deleted
 lOMoAR cPSD| 19893192

Realization
1. Realization is sufficiently different from dependency, generalization, and association
relationships that it is treated as a separate kind of relationship.
2. A realizationis a semantic relationship between classifiers in which one classifier
specifies a contract that another classifier guarantees to carry out.
3. Graphically, a realization is rendered as a dashed directed line with a large open
arrowhead pointing to the classifier that specifies the contract.
4. You'll use realization in two circumstances: in the context of interfaces and
in the context of collaborations
5. Most of the time, you'll use realization to specify the relationship between an interface
and the class or component that provides an operation or service for it
6. You'll also use realization to specify the relationship between a use case and the
collaboration that realizes that use case

Realization of an Interface

Interfaces, type and roles

Interface
 An interface is a collection of operations that are used to specify a
service of a class or a component
Type
 A type is a stereotype of a class used to specify a domain of objects, together
with the operations (but not the methods) applicable to the object.
Role
 A role is the behavior of an entity participating in a particular context.

Names
 Every interface must have a name that distinguishes it from other interfaces.
 A name is a textual string. That name alone is known as a simple name;
 A path name is the interface name prefixed by the name of the package
 lOMoAR cPSD| 19893192

Simple and Path Names

Operations
 An interface is a named collection of operations used to specify a
service of a class or a component.
 Unlike classes or types, interfaces do not specify any structure (so they
may not include any attributes), nor do they specify any implementation
 These operations may be adorned with visibility properties, concurrency
properties,stereotypes, tagged values, and constraints.
 you can render an interface as a stereotyped class, listing its operations in the
appropriate compartment. Operations may be drawn showing only their
name, or they may be augmented to show their full signature and other
properties

Operations
Relationships
 Like a class, an interface may participate in generalization,
association, and dependency relationships. In addition, an interface
may participate in realizationrelationships.
 An interface specifies a contract for a class or a component without dictating
itsimplementation.
 A class or component may realize many interfaces
We can show that an element realizes an interface in two ways.
o First, you can use the simple form in which the interface and its realization relationshipare
rendered as a lollipop sticking off to one side of a class or component.
o Second, you can use the expanded form in which you render an interface as a stereotyped
class, which allows you to visualize its operations and other properties, and then draw
arealization relationship from the classifier or component to the interface.
 lOMoAR cPSD| 19893192

Types and Roles

A role names a behavior of an entity participating in a particular context. Stated
another way, a role is the face that an abstraction presents to the world.
For example, consider an instance of the class Person. Depending on the context,
that Person instance may play the role of Mother, Comforter, PayerOfBills, Employee,
Customer, Manager, Pilot, Singer, and so on. When an object plays a particular role, it
presents a face to the world, and clients that interact with it expect a certain behavior
depending on the role that it plays at the time.

 Type is a stereotype of class, and you use it to specify a domain of objects, together
with the operations (but not the methods) applicable to the objects of that type. The
concept of type is closely related to that of interface, except that a type's definition may
include attributes while an interface may not.

Common Modeling Techniques

 Modeling the Seams in a System

 The most common purpose for which you'll use interfaces is to model the seams in a
system composed of software components, such as COM+ or Java Beans.
 Identifying the seams in a system involves identifying clear lines of demarcation in
your architecture. On either side of those lines, you'll find components that may change
independently, without affecting the components on the other side,

 The above Figure shows the seams surrounding a component (the library ledger.dll)
drawn from a financial system. This component realizes three interfaces: IUnknown,
ILedger, and IReports. In this diagram, IUnknown is shown in its expanded form; the
 lOMoAR cPSD| 19893192

other two are shown in their simple form, as lollipops. These three interfaces are
realized by ledger.dll and are exported to other components for them to build on.
 As this diagram also shows, ledger.dll imports two interfaces, IStreaming and
ITransaction, the latter of which is shown in its expanded form. These two interfacesare
required by the ledger.dll component for its proper operation. Therefore, in a running
system, you must supply components that realize these two interfaces.
 By identifying interfaces such as ITransaction, you've effectively decoupled the
components on either side of the interface, permitting you to employ any component
that conforms to that interface.

 Modeling Static and Dynamic Types

 Most object-oriented programming languages are statically typed, which means that the
type of an object is bound at the time the object is created.
 Even so, that object will likely play different roles over time.
 Modeling the static nature of an object can be visualized in a class diagram.
However,when you are modeling things like business objects, which naturally change
their rolesthroughout a workflow,
 To model a dynamic type
o Specify the different possible types of that object by rendering each type as aclass
stereotyped as type (if the abstraction requires structure and behavior) or as interface
(if theabstraction requires only behavior).

o Model all the roles the of the object may take on at any point in time. You can
doso in two ways:
1.) First, in a class diagram, explicitly type each role that the class plays in
association with Other classes. Doing this specifies the face instances of that class put
on in the context of the associated object.
2.) Second, also in a class diagram, specify the class-to-type relationships using
eneralization.

o In an interaction diagram, properly render each instance of the dynamically

typedclass. Display the role of the instance in brackets below the object's name.

o To show the change in role of an object, render the object once for each role
itplays in the interaction, and connect these objects with a message stereotyped
as become.

Modeling Static Types Modeling Dynamic Types

Package
“A package is a general-purpose mechanism for organizing elements into
groups.”Graphically, a package is rendered as a tabbed folder.
 lOMoAR cPSD| 19893192

Names
 Every package must have a name that distinguishes it from other packages. A name is
atextual string.
 That name alone is known as a simple name; a path name is the package name
prefixedby the name of the package in which that package lives
 We may draw packages adorned with tagged values or with additional compartments
toexpose their details.

Simple and Extended Package

Owned Elements
A package may own other elements, including classes, interfaces, components,
nodes, collaborations, use cases, diagrams, and even other packages.
Owning is a composite relationship, which means that the element is declared in
the package. If the package is destroyed, the element is destroyed. Every element is
uniquely owned by exactly one package.
Elements of different kinds may have the same name within a package. Thus,
you can have a class named Timer, as well as a component named Timer, within the same
package.
Packages may own other packages. This means that it's possible to
decompose your models hierarchically.
We can explicitly show the contents of a package either textually or graphically.

Importing and Exporting

In the UML, you model an import relationship as a dependency adorned with the
stereotype
import
Actually, two stereotypes apply here—import and access— and both specify that
the source package has access to the contents of the target.
Import adds the contents of the target to the source's namespace Access does not
add the contents of the target
 lOMoAR cPSD| 19893192

The public parts of a package are called its exports.

The parts that one package exports are visible only to the contents of those
packages that explicitly import the package. Import and access dependencies are not
transitive

Generalization
There are two kinds of relationships you can have between packages: import and
access dependencies used to import into one package elements exported from another and
generalizations, used to specify families of packages
Generalization among packages is very much like generalization among classes
Packages involved in generalization relationships follow the same principle of
substitutability as do classes. A specialized package (such as WindowsGUI) can be used
any where a more general package (such as GUI) is used

Generalization Among Packages

Standard Elements
o The UML defines five standard stereotypes that apply to packages

1. facade Specifies a package that is only a view on some other package

2. framework Specifies a package consisting mainly of patterns
3. stub Specifies a package that serves as a proxy for the public contents
of another package
4. subsystem Specifies a package representing an independent part of the entire
system being modeled
5. system Specifies a package representing the entire system being modeled
 lOMoAR cPSD| 19893192

Common Modeling Techniques Modeling Groups of Elements

The most common purpose for which you'll use packages is to organize-modeling
elements
into groups that you can name and manipulate as a set.
There is one important distinction between classes and packages:
Packages have no identity (meaning that you can't have instances of
packages,so they are invisible in the running system);
classes do have identity (classes have instances, which are elements of a running
system).
To model groups of elements,
Scan the modeling elements in a particular architectural view and look for
clumpsdefined by elements that are conceptually or semantically close to one another.
Surround each of these clumps in a package.
For each package, distinguish which elements should be accessible outside the
package. Mark them public, and all others protected or private. When in doubt, hide
the element.
Explicitly connect packages that build on others via import dependencies
In the case of families of packages, connect specialized packages to their more general
part via generalizations

Modeling Architectural Views

o We can use packages to model the views of an architecture.

o Remember that a view is a projection into the organization and structure of a
system,focused on a particular aspect of that system.
o This definition has two implications. First, you can decompose a system into almost
orthogonal packages, each of which addresses a set of architecturally significant
decisions.( design view, a process view, an implementation view, a deployment
view,and a use case view)
o Second, these packages own all the abstractions germane to that
view.(Implementationview)
To model architectural views,
o Identify the set of architectural views that are significant in the context of your problem
As necessary, further group these elements into their own packages.
o There will typically be dependencies across the elements in different views. So,in
general, let each view at the top of a system be open to all others at that level.

Modeling Architectural Views