lOMoARcPSD|41687779

OOAD-UNIT-3 - R20

Object Oriented Analysis and Design (Jawaharlal Nehru Technological University,

Kakinada)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
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
Terms
Terms & concepts
 A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
 Graphically, a class diagram is a collection of vertices and arcs.

Common Properties AClass 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 a class diagram from all other kinds of diagram is its particular content.

Contents
 Class diagrams commonly contain the following things:
o Classes
o Interfaces
o Collaborations
o Dependency, generalization, and association relationships

 Like all other diagrams, class diagrams may contain notes and constraints
 Class diagrams may also contain packages or subsystems

Note: Component diagrams and deployment diagrams are similar to class diagrams, except that instead of
containing classes, they contain components and nodes

Example

Common Uses
o You use class diagrams to model the static design view of a system. This view primarily supports the
functional requirements of a system
o We'll typically use class diagrams in one of three ways:
1. To model the vocabulary of a system
2. To model simple collaborations
3. To model a logical database schema

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Modeling the vocabulary of a system

o 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
Modeling simple collaborations
o 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.
Modeling logical database schema
o We can model schemas for these databases using class diagrams.
Common Modeling Techniques

Modeling Simple Collaborations

o When you create a class diagram, you just model a part of the things and relationships that make up your
system's design view. For this reason, each class diagram should focus on one collaboration at a time.
o To model a collaboration

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

o For each mechanism, identify the classes, interfaces, and other collaborations that participate in this
collaboration. Identify the relationships among these things, as well.

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

o Be sure to populate these elements with their contents. For classes, start with getting a good balance
of responsibilities. Then, over time, turn these into concrete attributes and operations.

Modeling a Logical Database Schema

o The UML is well-suited to modeling logical database schemas, as well as physical databases themselves.
o The UML's class diagrams are a superset of entity-relationship (E-R) diagrams, Whereas classical E-R
diagrams focus only on data, class diagrams go a step further by permitting the modeling of behavior, as
well. In the physical database these logical operations are generally turned into triggers or stored
procedures.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

o To model a schema,

o Identify those classes in your model whose state must transcend the lifetime of their applications.

o Create a class diagram that contains these classes and mark them as persistent (a standard tagged
value). You can define your own set of tagged values to address database-specific details.

o Expand the structural details of these classes. In general, this means specifying the details of their
attributes and focusing on the associations and their cardinalities that structure these classes.

o Watch for common patterns that complicate physical database design, such as cyclic associations,
one-to-one associations, and n-ary associations. Where necessary, create intermediate abstractions to
simplify your logical structure.

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

o Where possible, use tools to help you transform your logical design into a physical design.

Forward and Reverse Engineering

o Forward engineering is the process of transforming a model into code through a mapping to an
implementation language
o Forward engineering results in a loss of information, because models written in the UML are
semantically richer than any current object-oriented programming language.
o To forward engineer a class diagram,

o 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.
o Depending on the semantics of the languages you choose, you may have 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 either choose to prohibit developers from
modeling with multiple inheritance (which makes your models language-dependent)
o Use tagged values to specify your target language.
o Use tools to forward engineer your models.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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.
 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,

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

Object Diagram
Terms & 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 a
class diagram from all other kinds of diagram is its particular content.

Contents
 Object diagrams commonly contain
 Objects
 Links
 Like all other diagrams, object diagrams may contain notes and constraints.
 Object diagrams may also contain packages or subsystems

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Example:

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
 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

 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
Common Modeling Techniques
Modeling Object Structures
 An object diagram shows one set of objects in relation to one another at one moment in time.
 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.
 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.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
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 -

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
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.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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 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
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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

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

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 can use with
operations.

1. isQuery Execution of the operation leaves the state of the system unchanged. In other words, the
operation is a pure function that has no side effects.
2. sequential Callers must coordinate outside the object so that only one flow is in the object at a time. In
the presence of multiple flows of control, the semantics and integrity of the object cannot
be guaranteed.
3. guarded The semantics and integrity of the object is guaranteed in the presence of multiple flows of
control by sequentializing all calls to all of the object's guarded operations. In effect,
exactly one operation at a time can be invoked on the object, reducing this to sequential
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

semantics.
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
* 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

Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
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.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
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
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

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
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
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
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 theymay 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.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
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 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 interfaces are required by the ledger.dll
component for its proper operation. Therefore, in a running system, you must supply components
that realize these two interfaces.
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

 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 itsassociation with
Other classes. Doing this specifies the face instances of that class put on inthe context of the
associated object.
2.) Second, also in a class diagram, specify the class-to-type relationships usinggeneralization.

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.

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

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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 samepackage.
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 thestereotype
import
Actually, two stereotypes apply here—import and access— and both specify thatthe source
package has access to the contents of the target.
Import adds the contents of the target to the source's namespaceAccess 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 thosepackages 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 usedanywhere a more
general package (such as GUI) is used
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

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

Common Modeling Techniques

Modeling Groups of Elements
The most common purpose for which you'll use packages is to organizemodeling 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 theelement.
Explicitly connect packages that build on others via import dependencies
In the case of families of packages, connect specialized packages to their moregeneral 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)
o To model architectural views,
o Identify the set of architectural views that are significant in the context of yourproblem.
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

In practice, this typically includes a design view, a process view, animplementation

view, a deployment view, and a use case view.
o 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.
o As necessary, further group these elements into their own packages.
o There will typically be dependencies across the elements in different views. So,in
o general, let each view at the top of a system be open to all others at that level.

Modeling Architectural Views

Case Study: AI: Cryptanalysis.
Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how
they work and finding and improving techniques for defeating or weakening them. For example,
cryptanalysts seek to decrypt ciphertexts without knowledge of the plaintext source, encryption key or the
algorithm used to encrypt it.

Artificial Intelligence Artificial intelligence (AI) refers to the simulation of human intelligence in
machines that are programmed to think like humans and mimic their actions.

Problem to solve
 Our problem is designing a system with artificial intelligence that performs
cryptanalysis.
 The process of transforming ciphertext back to plaintext.
 Manually converting the ciphertext back to plaintext through brute force or any
approachtakes time and more work.
 So we have to apply software engineering concepts for designing the system.
INCEPTION –
Our problem is one of cryptanalysis, the process of transforming ciphertext back to plaintext. ourproblem is
relatively simple because we limit ourselves to single substitution ciphers.

Cryptanalysis Requirements
Cryptography “embraces methods for rendering data unintelligible to unauthorized parties” . Using
cryptographic algorithms, messages (plaintext) may be transformed into cryptograms (ciphertext) and
back again. One of the most basic kinds of cryptographic algorithms, employed since the time of the
Romans, is called a substitution cipher. With this cipher, every letter of the plaintext alphabet is mapped
to a different letter.
Cryptography – Cryptographic algorithms

-Ex – Substitution Cipher

Plain text - CLOS is an object-oriented programming language Cipher
text - DMPT jt bo pckfdu-psjfoufe qsphsbnnjoh mbohvbhf
Downloaded by Ganesh Pavan Kumar Battula ([email protected])
 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

-Methods
 Trail and Error
 Knowledge of spelling and grammar
 Backtracking
-Knowledge of Artificial Intelligence and
Blackboard systems.Boundaries of the Problem
Assuming that the plaintext alphabet encompasses only the 26 uppercase English characters, there are 26!
(approximately 4.03 * 10 ^ 26) possible combinations.
Thus, we must try something other than a brute force attack.
An alternate technique is to make an assumption based on our knowledge of sentence, word, and letter
structure and then follow this assumption to its natural conclusions.

Architecture of the Blackboard Framework

Englemore and Morgan - Blackboard framework.

Domain knowledge - partitioned into knowledge sources - separate and independent.
A knowledge source - current information on the blackboard - update it. The
knowledge sources - procedures, sets of rules, or logic assertions.
Example – Common prefixes, Common suffixes, Vowels, Consonants, Direct substitution, Double letters,
Letter frequency, Legal Strings, Pattern matching, Sentence structure, WordStructure etc.

Elaboration
Now we are ready to design a solution to the cryptanalysis problem using the blackboard
framework.
The architecture of the blackboard framework suggests that among the highest level objects in our
system are a blackboard, several knowledge sources, and a controller.
Our next task is to identify the domain-specific classes and objects that specialize these general key
abstractions.
Blackboard Objects

register() - Add the object to the blackboard.

resign() - Remove the object from the blackboard

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Dependencies Affirmations

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Dependency class
references - Collection of knowledge sources
add() - Add a reference to the knowledge source.
remove() - Remove a reference to the knowledge source.

numberOfDependents() - Return the number of dependents.

notify() - Broadcast an operation of each dependent.

Affirmation class
make - Make a statement.
retract - Retract a statement.
ciphertext - Given a plaintext letter, return its ciphertext equivalent.
plaintext - Given a ciphertext letter, return its plaintext equivalent.
target() - The blackboard object about which the assumption was made creator. The knowledge
source that created the assumption
reason() - The reason the knowledge source made the assumption. plainLetter() -
The plaintext letter about which the assumption is being made. cipherLetter() - The
assumed value of the plaintext letter.

3.Construction:
Design of the Sentence, Word, and Cipher Letter classes, followed by the Alphabet class, bydoing a little
isolated class design
1.Designing the Blackboard Objects
A sentence is quite simple: It is a Black board Object as well as a Dependent, and it denotes a list of words
that compose the sentence. We make the superclass Dependent abstract 1 (Figure 10–4)because we expect
there may be other Sentence subclasses that try to inherit from Dependent as well. By marking this
inheritance relationship abstract, we cause such subclasses to share a single Dependent superclass.

In addition to the operations register and resign defined by its superclass Black board Object,plus the four
operations defined in Dependent, we add the following two sentence-specific operations:

■ value Return the current value of the sentence.

■ isSolved Return true if there is an assertion for all words in the sentence.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

At the start of the problem, value returns a string representing the original cryptogram. OnceisSolved
evaluates as true, the operation value may be used to retrieve the plaintext solution. Accessing value
before isSolved is true will yield partial solutions.
the Sentence operations, we define the following two operations for the class Word:

■ value Return the current value of the word.

■ isSolved Return true if there is an assertion forevery letter in the word.
Next define the class Cipher Letter. An instance of this class is a kind of Blackboard Object and a kind of
Dependent. In addition to its inherited behaviors, each Cipher Letter object has a value (such as the
ciphertext letter H) together with a collection of assumptions and assertions regarding its corresponding
plaintext letter. We can use the class Affirmation to collect these statements.
Figure 10–5 illustrates the addition of the design of Cipher Letter and Word in our architectureframework.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

This decision influences our design decisions about the Affirmation class, to which we add the following
operations:
■ most Recent A selector: returns the most recent assumption or assertion
■ statement At A selector: returns the nth statement.
Consider next the class named Alphabet. This class represents the entire plaintext and ciphertext alphabet,
plus the mappings between the two. This information is important because each knowledge source can use
it to determine which
mappings have been made and which are yet to be done.
For example, if we already have an assertion that the ciphertext letter C is really the letter M, then an
alphabet object records this mapping so that no other knowledge source can apply the plaintext letter
M. For efficiency, we need to query about the mapping both ways: Given a ciphertext letter, return its
plaintext mapping, and given a plaintext letter, return its ciphertextmapping.
Figure 10–6 illustrates the addition of the design of the Alphabet class.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

The Cipher Letter Class, we also include a protected member object affirmations and provide suitable
operations to access its state.
To define the Blackboard class. This class has the simple responsibility of collecting instances of the
Black board Object class and its subclasses. Thus we may design Blackboard as a type of instance of a
Dynamic Collection.
We have chosen to inherit from rather than contain an instance of the Dynamic Collection class because
Blackboard passes our test for inheritance: A Blackboard is indeed a kind of collection. The Blackboard
class provides operations such as add and remove, which it inherits from the Collection class. Our
design includes five operations specific to the blackboard.

■ reset Clean the blackboard.

■ assertProblem Place an initial problem on the blackboard.
■ connect Attach the knowledge source to the blackboard.
■ isSolved Return true if the sentence is solved.
■ retrieveSolution Return the solved plaintext sentence. The second operation is needed to
createa dependency between a blackboard and its knowledge sources.
In Figure 10–7, we summarize our design of the classes that collaborate with Blackboard. In this
diagram, notice that we show the Blackboard class as both instantiating and inheriting from the template
class Dynamic Collection.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Designing the Knowledge Sources

In a previous section, we identified 13 knowledge sources relevant to this problem. Just as we did for
the Blackboard objects, we can design a class structure encompassing these knowledge sources and
thereby elevate all common characteristics to more abstract classes.

Designing Specialized Knowledge Sources

Assume for the moment the existence of an abstract class called Knowledge Source.
groups: Some knowledge sources operate on whole sentences, others on whole words, others oncontiguous
strings of letters, and still others on individual letters. We may capture these design decisions by creating
the following subclasses:

For each of these classes, we may provide another level of specification. For example, the subclasses of the
class Sentence Knowledge Source include the following:

Similarly, the subclasses of the intermediate class Word Knowledge Source include these:

the purpose of a pattern-matching knowledge source was to propose words that fit a certain pattern. We can use
regularexpression pattern matching symbols such as:

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Hierarchical Structure of common source

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

The reason for this simple interface is that knowledge sources are relatively autonomous entities: We point one
to an interesting Blackboard object and then tell it to evaluate its rules according to the current global state of the
Blackboard. As part of the evaluation of its rules, a given knowledge source might do any one of several things.

In fact, this class has only one critical operation that it makes visible to knowledge sources:

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Finally, each knowledge source must have an association to a controller, with which it collaborates by
sending hints of solutions; in turn, the controller might trigger the knowledgesource from time to time.
Figure 10–10 illustrates these design decisions.

One of the responsibilities of this class is that when we create an instance of Knowledge Sources, we also
create the 13 individual Knowledge Source objects. We may perform threeoperations on instances of this
class:

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Final Class Diagram of Knowledge Source

Figure 10–11 The Refined Design of the Knowledge Source Class Diagram
Designing the Controller
Consider for a moment how the controller and individual knowledge sources interact. At each stage in
the solution of a cryptogram, a particular knowledge source might discover that it has a useful
contribution to make and so gives a hint to the controller.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

How does the controller decide which knowledge source to activate? We may devise a fewsuitable rules.

For example, consider the state transition diagram shown in Figure 10–12. Here we see that a controller
may be in one of five major states: Initializing, Selecting, Evaluating, Stuck, and Solved. The controller’s
most interesting activity occurs between the Selecting and Evaluatingstates.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Figure 10–12 The Controller State Machine

Integrating the Blackboard

Framework
Defined the key abstractions for our domain, we may continue by putting them together to form a
complete application. We will proceed by implementing and testing a vertical slice through the
architecture and then by completing the system one mechanism at a time.

Integrating the Topmost Objects

Figure 10–13 is a composite structure diagram that captures our design of the top most object in the
system, paralleling the structure of the generic blackboard framework shown earlier in Figure 10–1. In
Figure 10–13, we show the physical containment of blackboard objects by the collection the Black board
and knowledge sources by the collection the Knowledge Sources, using a short hand style identical to that
for showing nested classes

Figure 10–13 The Cryptanalysis Composite Structure Diagram

Two primary operations for the Cryptographer class:

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Sequence Diagram
Figure 10–14 illustrates the flow of control using a sequence diagram.

Figure 10–14 The decipher

Sequence Diagram Implementing the Assumption
Mechanism
implemented the mechanisms that allow us to set and retrieve values for Blackboard objects. Thenext major
function point involves the mechanism for making assumptions about Blackboard objects. This is a
particularly significant issue because assumptions are dynamic (meaning that they are routinely created and
destroyed during the process of forming a solution), and their creation or retraction triggers controller
events
Figure 10–15 illustrates the primary scenario of when a knowledge source states an assumption. As this
communication diagram shows, once the Knowledge Source creates an Assumption, it notifies the
Blackboard, which in turn makes the Assumption for its Alphabet and then for each Blackboard Object to
which the Assumption applies. Using the dependency mechanism, the affected Blackboard Object in turn
might notify any dependent Knowledge Source.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

Adding New Knowledge Sources

4.Post Transition –
In this section, we consider an improvement to the functionality of the cryptanalysis system and observe
how our design weathers the change.

1.System Encements:
In any intelligent system, it is important to know what the final answer is to a problem, but it isoften equally
important to know how the system arrived at this solution.
To add this new functionality, we need to do two things.
First, we must devise a mechanism for keeping track of the work that the controller and each knowledge
source perform, and second, we must modify the appropriate operations so that they record this
information. Basically, the design calls for the knowledge sources and the controller to register what they
did in some central repository.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779
lOMoAR cPSD| 19893192

First, we might define the class Action, which serves to record what a particular
knowledge source or controller did. Figure 10–16 presents the design of the Action
class as it fits intoour architectural design.
For example, if the controller selected a particular knowledge source for activation, it would create an
instance of this class, set the who argument to itself, set the what argument to the knowledge source, set
the why argument to some explanation (perhaps including the current priority of the hint), and set when
this occurred.
The first part of our task is done, and the second part is almost as easy. Consider for a moment where
important events take place in our application.
As it turns out, five primary kinds of operations are affected:

1. Methods that state an assumption

2. Methods that retract an assumption
3. Methods that activate a knowledge source
4. Methods that cause rules to be evaluated 5. Methods that register hints from a
knowledgesource

Figure 10–16 Additional Functionality Provided through the Action

Class Design

Downloaded by Ganesh Pavan Kumar Battula ([email protected])

 lOMoARcPSD|41687779

Object Oriented Analysis and Design Using UML

2.Changing the Requirements

Once we have a stable implementation in place, many new requirements can be incorporated with
minimal changes to our design. Let’s consider three kinds of new requirements:

1. The ability to decipher languages other than English

2. The ability to decipher using transposition ciphers as well as single substitution ciphers
3. The ability to learn from experience.
The first change is fairly easy because the fact that our application uses English is largely immaterial to
our design. Assuming the same character set is used, it is mainly a matter of changing the rules
associated with each knowledge source. Actually, changing the character set is not that difficult either
because even the Alphabet class is not dependent on what characters itmanipulates.
The second change is much harder, but it is still possible in the context of the blackboard framework.
Basically, our approach is to add new sources of knowledge that embody information about
transposition ciphers. Again, this change does not alter any existing key abstraction or mechanism in
our design; rather, it involves the addition of new classes that useexisting facilities, such as the Inference
Engine class and the assumption mechanism.
The third change is the hardest of all, mainly because machine learning is on the fringes of our
knowledge in artificial intelligence. As one approach, when the controller discovers it can no longer
proceed, it might ask the user for a hint. By recording this hint, along with the actions that led up to the
system being stuck, the blackboard application can avoid a similar problem in the future. We can
incorporate this simplistic learning mechanism without vastly altering any of our existing classes; as with
all the other changes, this one can build on existing facilities.

Important Questions
1. a) Describe terms and concepts of advanced classes. [7M]
b) Briefly explain about inception phase of Cryptanalysis. [7M]
2. a) Explain common modeling techniques of class and object diagrams. [9M]
b) Describe blackboard objects of Cryptanalysis.
3. a) What are common modeling techniques of advanced relationships? Explain. [7M]
b) Describe designing the knowledge sources of Cryptanalysis. [7M]
4. a) Write and explain terms and concepts of interfaces, types and roles. [7M]
b) Discuss about post transition of Cryptanalysis.
5. a) What is an object diagram? Explain identifying objects in object diagrams. [7M]
b) Discuss about designing the controller of Cryptanalysis.
6. a) How to identify classes in class diagrams? Explain. [7M]
b) Discuss about the elaboration phase of Cryptanalysis. [7M]
7. a) Describe common modeling techniques of Packages. [7M]
b) What are requirements of Cryptanalysis? Explain about analysis of knowledge
sources.
8. a) Enumerate steps to model vocabulary of a system. [7M]
b) What is Object diagram? Explain the purpose of Object diagram and also explain the
notations used in object diagrams.[7M]
9. a) Draw and explain the class diagram for credit card validation system. [7M]
b) Explain about the package used in UML and also draw the package diagram for hotel
management system

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ganesh Pavan Kumar Battula ([email protected])