UNIT – III

Advanced classes, advanced relationships, interfaces, types and roles, packages, terms, concepts,
modeling techniques for class and object diagrams; Interactions: Interaction diagrams; Use cases:
Use case diagrams, activity diagrams.

UNIT-III
CLASS & OBJECT DIAGRAMS
Class Diagrams:
TERMS AND CONCEPTS
A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their
relationships. Graphically, a class diagram is a collection of vertices and arcs.

Common Properties:
A class diagram is just a special kind of diagram and shares the same common properties as do all other
diagrams name and graphical content that are a projection into a model. What distinguishes a class
diagram from other kinds of diagrams is its particular content.

Contents:
Class diagrams commonly contain the following things:
• Classes
• Interfaces
• Collaborations
• Dependency, generalization, and association relationships. Like all other diagrams, class diagrams may
contain notes and constraints.
Class diagrams may also contain packages or subsystems, both of which are used to group elements of
your model into larger chunks. Sometimes you'll want to place instances in your class diagrams as well,
especially when you want to visualize the (possibly dynamic) type of an instance.

Common Uses :
You use class diagrams to model the static design view of a system. This view primarily
supports the functional requirements of a system the services the system should provide to its end users.
When you model the static design view of a system, you'll typically use class diagrams in one of three
ways.
1. To model the vocabulary of a system Modeling the vocabulary of a system involves making a
decision about which abstractions are a part of the system under consideration and which fall outside its
boundaries. You use class diagrams to specify these abstractions and their responsibilities.
2. To model simple collaborations
A collaboration is a society of classes, interfaces, and other elements that work together to provide some
cooperative behavior that's bigger than the sum of all the elements. For example, when you re modeling
the semantics of a transaction in a distributed system, you can't just stare at a single class to understand
what's going on. Rather, these semantics are carried out by a set of classes that work together. You use
class diagrams to visualize and specify this set of classes and their relationships.

3. To model a logical database schema

Think of a schema as the blueprint for the conceptual design of a database. In many domains, you'll
want to store persistent information in a relational database or in an object-oriented database. You can
model schemas for these databases using class diagrams.

COMMON MODELING TECHNIQUES

1.Modeling Simple Collaborations
To model a collaboration,
• Identify the mechanism you'd like to model. A mechanism represents some function or behavior of the
part of the system you are modeling that results from the interaction of a society of classes, interfaces,
and other things.
• For each mechanism, identify the classes, interfaces, and other collaborations that participate in this
collaboration. Identify the relationships among these things as well.
• Use scenarios to walk through these things. Along the way, you'll discover parts of your model that
were missing and parts that were just plain semantically wrong.
• Be sure to populate these elements with their contents. For classes, start with getting a good balance of
responsibilities. Then, over time, turn these in to concrete attributes and operations.

2. Modeling a Logical Database Schema

To model a schema, • Identify those classes in your model whose state must transcend the lifetime of
their applications.
• Create a class diagram that contains these classes. You can define your own set of stereotypes and
tagged values to address database-specific details.
• Expand the structural details of these classes. In general, this means specifying the details of their
attributes and focusing on the associations and their multiplicities that relate these classes.
• Watch for common patterns that complicate physical database design, such as cyclic associations and
one-to-one associations. Where necessary, create intermediate abstractions to simplify your logical
structure.
• Consider also the behavior of these classes by expanding operations that are important for data access
and data integrity. In general, to provide a better separation of concerns, business rules concerned with
the manipulation of sets of these objects should be encapsulated in a layer above these persistent classes.
• Where possible, use tools to help you transform your logical design into a physical design.

Forward and Reverse Engineering:

Forward engineering is the process of transforming a model into code through a mapping to an
implementation language. Forward engineering results in a loss of information, because models written
in the UML are semantically richer than any current object-oriented programming language. In fact, this
is a major reason why you need models in addition to code. Structural features, such as collaborations,
and behavioral features, such as interactions, can be visualized clearly in the UML, but not so clearly
from raw code.
To forward engineer a class diagram,
• Identify the rules for mapping to your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole.
• Depending on the semantics of the languages you choose, you may want to constrain
your use of certain UML features. For example, the UML permits you to model multiple
inheritance, but Smalltalk permits only single inheritance. You can choose to prohibit
developers from modeling with multiple inheritance (which makes your models
language-dependent), or you can develop idioms that transform these richer features into the
implementation language (which makes the mapping more complex).
• Use tagged values to guide implementation choices in your target language. You can do
this at the level of individual classes if you need precise control. You can also do so at a
higher level, such as with collaborations or packages.
• Use tools to generate code.
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {}
}
Reverse engineering is the process of transforming code into a model through a mapping from a specific
implementation language. Reverse engineering results in a flood of information, some of which is at a
lower level of detail than you'll need to build useful models. At the same time, reverse engineering is
incomplete. There is a loss of information when forward engineering models into code, and so you can't
completely recreate a model from code unless your tools encode information in the source comments
that goes beyond the semantics of the implementation language.
To reverse engineer a class diagram,
•Identify the rules for mapping from your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
• Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new model or
modify an existing one that was previously forward engineered. It is unreasonable to expect to reverse
engineer a single concise model from a large body of code. You need to select portion of the code and
build the model from the bottom.
• Using your tool, create a class diagram by querying the model. For example, you might start with one
or more classes, then expand the diagram by following specific relationships or other neighboring
classes. Expose or hide details of the contents of this class diagram as necessary to communicate your
intent.
• Manually add design information to the model to express the intent of the design that is missing or
hidden in the code.
Object Diagrams:
Object diagrams model the instances of things contained in class diagrams. An object diagram shows a
set of objects and their relationships at a point in time.

TERMS AND CONCEPTS

An object diagram is a diagram that shows a set of objects and their relationships at a point in time.
Graphically, an object diagram is a collection of vertices and arcs.

Common Properties
An object diagram is a special kind of diagram and shares the same common properties as all other
diagrams that is, a name and graphical contents that are a projection into a model. What distinguishes an
object diagram from all other kinds of diagrams is its particular content.
Contents
Object diagrams commonly contain
•Objects
•Links
Like all other diagrams, object diagrams may contain notes and constraints.
Sometimes you'll want to place classes in your object diagrams as well, especially when you want to
visualize the classes behind each instance.

Common Uses
You use object diagrams to model the static design view or static process view of a
system just as you do with class diagrams, but from the perspective of real or prototypical
instances.

This view primarily supports the functional requirements of a systemthat is, the
services the system should provide to its end users. Object diagrams let you model static data structures.
When you model the static design view or static process view of a system, you typically use object
diagrams in one way:
To model object structures
Modeling object structures involves taking a snapshot of the objects in a system at a given moment in
time. An object diagram represents one static frame in the dynamic storyboard represented by an
interaction diagram. You use object diagrams to visualize, specify, construct,
and document the existence of certain instances in your system, together with their relationships to one
another.

COMMON MODELING TECHNIQUES

Modeling Object Structures
To model an object structure,
•Identify the mechanism you'd like to model. A mechanism represents some function or behavior of the
part of the system you are modeling that results from the interaction of a society of classes, interfaces,
and other things.
• Create a collaboration to describe a mechanism.
• For each mechanism, identify the classes, interfaces, and other elements that participate in this
collaboration; identify the relationships among these things as well.
•Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in time,
and render each object that participates in the mechanism.
•Expose the state and attribute values of each such object, as necessary, to understand the scenario.
•Similarly, expose the links among these objects, representing instances of associations among them.

FORWARD AND REVERSE ENGINEERING

Forward engineering ( the creation of code from a model) an object diagram is theoretically possible but
pragmatically of limited value. In an object-oriented system, instances are things that are created and
destroyed by the application during run time. Therefore, you cannot exactly instantiate these objects
from the outside.
Reverse engineering (the creation of a model from code) an object diagram can be useful. In fact, while
you are debugging your system, this is something that you or your tools will do all the time. For
example, if you are chasing down a dangling link, you'll want to literally or mentally draw an object
diagram of the affected objects to see where, at a given moment in time, an object's state or its
relationship to other objects is broken.
To reverse engineer an object diagram,
•Chose the target you want to reverse engineer. Typically, you'll set your context inside an operation or
relative to an instance of one particular class.
• Using a tool or simply walking through a scenario, stop execution at a certain moment in time.
• Identify the set of interesting objects that collaborate in that context and render them in an object
diagram.
• As necessary to understand their semantics, expose these object's states.
• As necessary to understand their semantics, identify the links that exist among these objects.

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 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
• Data type
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 - 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 -.

Scope- It 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. Classifier - There is just one value of the feature for all instances of the classifier.
• Figure shows, a feature that is classifier scoped is rendered by underlining the feature's name
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.
• 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
• You can 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}].
•
There are three defined properties that you can use with attributes.

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

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
frozen The attribute's value may not be changed after the object is initialized.

Operations
• 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.
• 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}]
• 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
1) in 2) out 3) inout
Template Classes
- A template is a parameterized element. In such languages as C++ and Ada, you
can write template classes, each of which defines a family of classes.
• A template includes slots for classes, objects, and values, and these slots serve as the
template's parameters.
• The most common use of template classes is to specify containers that can be
instantiated for specific elements, making them type-safe
template<class Item, class Value, int Buckets> class Map {
public:
virtual Boolean bind(const Item&,
constValue&); virtual Boolean isBound(const
Item&) const;

... };
Standard Elements - The UML defines four standard stereotypes that apply to classes.

1. metaclass - Specifies a classifier whose objects are all classes

2. powertype - Specifies a classifier whose objects are the children of a given parent
3. stereotype - Specifies that the classifier is a stereotype that may be applied to other elements
4. utility - Specifies a class whose attributes and operations are all class
scoped Common Modeling Techniques
1. Modeling semantics of 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, post condition, 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 postconditions 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.

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, directed to the thing that is
depended on.
Eight Stereotypes that apply to dependency relationships among classes and objects

bind the source instatiates the target template

derive the source may be computed from target
friend the source is given special visibility into target
instanceOf source object is an instance of the target classifier
instantiate source object creates instance of the target
powertype target is a powertype of the source
refine source is at a finer degree of abstraction than target
use the semantics of the source element depends on the semamtics of the
public
part of the target

• Two stereotypes that apply to dependency relationships among packages.

– access – source package is granted the right to reference the elements of
the target package.
– import – a kind of access, but only public content.
• Two stereotypes that apply to dependency relationships among use case.
– extend – target use case extends the behavior of source.
– include – source use case explicitly incorporates the behavior of another use
case at a location specified by the source
 • Three stereotypes when modeling interactions among objects.
– become – target is the same object of source at later time
– call – source operation invoke the target operation
– copy – target is an exact, but different, copy of source
• In the context of state machine
– send – source operation sends the target event
• In the context of organizing the elements of your system into subsystem and model
– trace – target is an historical ancestor of the source (model relationship among
elements in different models)

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).

There is the one stereotype.

• Implementation: Specifies that the child inherits the implementation of the parent but
does not make public nor support. Its interfaces, thereby violating substitutability

The four constraints that may be applied to generalization relationships.

1. Complete - Specifies that all children in the generalization have been specified in the model
and that no additional children are permitted
2. Incomplete - Specifies that not all children in the generalization have been specified and that
additional children are permitted
3. Disjoint - Specifies that objects of the parent may have no more than one of the children
as a type 4.Overlapping - Specifies that objects of the parent may have more than one of the
children as a type

Association
• An association is a structural relationship, specifying that objects of one thing are
connected to object of another.
• Basic adornments: name, role, multiplicity, aggregation.
• Advanced adornments: navigation, qualification, various flavors of aggregation

Navigation
- Given a plain, 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.
Visibility
- 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

Qualification: A form of aggregation with strong ownership and coincident lifetime of

the parts by the whole.

• Interface specifier : An interface is a collection of operations that are used to

specify a service of a class or a component; every class may realize many
interfaces.
Composition
• In a composite aggregation, an object may be a part of only one composite at a time.
• For example, in a windowing system, a Frame belongs to exactly one Window.
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.

Constraints
1. implicit: The relationship is not manifest but, rather, is only conceptual.
2. ordered: the set of objects at one end of an association are in an explicit order.
3. changeable: links between objects may be changed.
4. add Only: new links may be added from an object on the opposite end of
association.
5. frozen: a link added may not be modified or deleted.
6. Xor: over a set of associations, exactly one is man fest for each associated
object.
Realization
• A realization is a semantic relationship between classifiers in which one
classifier specifies a contract that anther classifier guarantees to carry out.
• Use in two circumstances:
– In the context of interfaces.
– In the context of collaborations.

– Rendering as:

Common Modeling Techniques

1. Modeling Webs of Relationships

• Apply use cases and scenarios to drive your discovery of the relationships among
a set of abstractions.
• In general, start by modeling the structural relationships that are present. These
reflect the static view of the system and are therefore fairly tangible.
• Next, identify opportunities for generalization/specialization relationships; use
multiple inheritance sparingly.
• Only after completing the preceding steps should you look for dependencies; they
generally represent more-subtle forms of semantic connection.
• For each kind of relationship, start with its basic form and apply advanced
features only as absolutely necessary to express your intent.
• Remember that it is both undesirable and unnecessary to model all relationships
among a set of abstractions in a single diagram or view. Rather, build up your
system's relationships by considering different views on the system. Highlight
interesting sets of relationships in individual diagrams.
Interfaces, Types and Roles

• An interface is a collection of operations that are used to specify a service of a

class or a component. Graphically, an interface is rendered (represented) as a
circle; in its expanded form, an interface may be rendered as a stereotyped class(a
class with stereotype interface)
Names
• Every interface must have a name that distinguishes it from other interfaces
• Two naming mechanism:
• A simple name (only name of the interface).
• A path name is the interface name prefixed by the name of the package in which
 that interface lives represented.

Operations:
• To distinguish an interface from a class, prepend an ‗I‘ to every interface name.
• Operations in an interface may be adorned with visibility properties,
concurrency properties, stereotypes, tagged values, and constraints.
• Interface don't have attributes. interfaces span model boundaries and it doesn't
have direct instances.

Understanding an Interface

• In the UML, you can supply much more information to an interface in order to
make it understandable and approachable.
• First, you may attach pre- and postconditions to each operation and invariants to
the class or component as a whole. By doing this, a client who needs to use an
interface will be able to understand what the interface does and how to use it,
without having to dive into an implementation.
• We can attach a state machine to the interface. You can use this state machine to
specify the legal partial ordering of an interface's operations.

• We can attach collaborations to the interface. You can use collaborations to

specify the expected behavior of the interface through a series of interaction
diagrams.

Interface relationships

• An interface may participate in generalization, association, dependency and

realization relationships. Realization is a semantic relationship between two
classifiers in which one classifier specifies a contract that another classifier
guarantees to carry out.
Types
and
Roles
Type:
• A type is a stereotype of a class used to specify a domain of objects, together with
the operations applicable to the object of that type.
• To distinguish a type from an interface or a class, prepend a ‗T‘ to every type.
Role
• A role names(indicates) a behavior of an entity participating in a particular
context. Or, 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.

Common Modeling Techniques

1. Modeling the Seams in a Systemeling the Seams in a System

• Within the collection of classes and components in your system, draw a line
around those that tend to be tightly coupled relative to other sets of classes and
components.
• Refine your grouping by considering the impact of change. Classes or
components that tend to change together should be grouped together as
collaborations.
• Consider the operations and the signals that cross these boundaries, from
instances of one set of classes or components to instances of other sets of classes
and components.
• Package logically related sets of these operations and signals as interfaces.
• For each such collaboration in your system, identify the interfaces it relies on
(imports) and those it provides to others (exports). You model the importing of
interfaces by dependency relationships, and you model the exporting of interfaces
by realization relationships.
• For each such interface in your system, document its dynamics by using pre- and
postconditions for each operation, and use cases and state machines for the
interface as a whole.
2. Modeling Static and Dynamic Types
To model a dynamic type
• Specify the different possible types of that object by rendering each type as a class
stereotyped as type (if the abstraction requires structure and behavior) or as
interface (if the abstraction requires only behavior).
• Model all the roles the class of the object may take on at any point in time. You
can do so in two ways:
 First, in a class diagram, explicitly type each role that the class plays in its
association with other classes. Doing this specifies the face instances of
that class put on in the context of the associated object.
 Second, also in a class diagram, specify the class-to-type relationships
using generalization.
• In an interaction diagram, properly render each instance of the dynamically
typed class. Display the role of the instance in brackets below the object's name.
• To show the change in role of an object, render the object once for each role
it plays in the interaction, and connect these objects with a message stereotyped
as become.
• For example, Figure shows the roles that instances of the class Person might play
in the context of a human resources system.

Fig: Modeling Static Types

Figure shows the dynamic nature of a person's type. In this fragment of an interaction
diagram, p (the Person object) changes its role from Candidate to Employee.
Fig: Modeling Dynamic Types
Packages

―A package is a general-purpose mechanism for organizing elements into groups.‖

Graphically, a package is rendered as a tabbed folder.

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

Visibility

• You can control the visibility of the elements owned by a package just as you
can control the visibility of the attributes and operations owned by a class.
• Typically, an element owned by a package is public, which means that it is visible
to the contents of any package that imports the element's enclosing package.
• Conversely, protected elements can only be seen by children, and private elements
cannot be seen outside the package in which they are declared.
• We specify the visibility of an element owned by a package by prefixing the
element's name with an appropriate visibility symbol.
Importing and Exporting

• Suppose you have two classes named A and B sitting side by side. Because they
are peers, A can see B and B can see A, so both can depend on the other. Just two
classes makes for a trivial system, so you really don't need any kind of packaging.
• 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
• 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 anywhere a more general package (such as GUI) is used.
All of the UML's extensibility mechanisms apply to packages. Most often, you'll use tagged
values to add new package properties (such as specifying the author of a package) and
stereotypes to specify new kinds of packages (such as packages that encapsulate operating
system services).

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

Common Modeling Techniques

1. Modeling Groups of Elements
• Scan the modeling elements in a particular architectural view and look for
clumps defined 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
2. Modeling Architectural Views
• Identify the set of architectural views that are significant in the context of your
problem. In practice, this typically includes a design view, a process view, an
implementation view, a deployment view, and a use case view.
• Place the elements (and diagrams) that are necessary and sufficient to visualize,
specify, construct, and document the semantics of each view into the appropriate
package
• As necessary, further group these elements into their own packages.
• 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

Fig: Modeling techniques for Class and Object diagram