1 a) Explain the conceptual model of the UML.

[8]

To understand the UML, you need to form a conceptual model of the language, and this requires learning
three major elements:
1. The UML's basic building blocks ----5M
2. The rules that dictate how those building blocks may be put together------1M
3. Common mechanisms that apply throughout the UML. ------2M
Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks
1. Things
2. Relationships
3. Diagrams
Things in the UML
There are four kinds of things in the UML:
1. Structural things------Class, Interface, Use case, Collaboration, Active Class, Component, Node
2. Behavioral things-----Interaction, State Machine
3. Grouping things-------package
4. Annotational things---Note
Relationships in the UML
There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
Diagrams in the UML
A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices
(things) and arcs (relationships). five most useful views that comprise the architecture of a software-intensive
system. For this reason, the UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
Rules of the UML
The UML has semantic rules for
Names
What you can call things, relationships, and diagrams
Scope
The context that gives specific meaning to a name
Visibility
How those names can be seen and used by others
Integrity
How things properly and consistently relate to one another
Execution
What it means to run or simulate a dynamic model

Common Mechanisms in the UML

1.
2.
3.
4.

Specifications
Adornments
Common divisions
Extensibility mechanisms

b) Briefly explain object oriented modeling.

[7]

In software, there are several ways to approach a model. The two most common ways are from an algorithmic
perspective and from an object-oriented perspective.
The traditional view of software development takes an algorithmic perspective. In this approach, the main building
block of all software is the procedure or function. This view leads developers to focus on issues of control and the
decomposition of larger algorithms into smaller ones. There's nothing inherently evil about such a point of view
except that it tends to yield brittle systems. As requirements change (and they will) and the system grows (and it
will), systems built with an algorithmic focus turn out to be very hard to maintain.
The contemporary view of software development takes an object-oriented perspective. In this approach, the main
building block of all software systems is the object or class. Simply put, an object is a thing, generally drawn from
the vocabulary of the problem space or the solution space; a class is a description of a set of common objects. Every
object has identity (you can name it or otherwise distinguish it from other objects), state (there's generally some data
associated with it), and behavior (you can do things to the object, and it can do things to other objects, as well).
For example, consider a simple three-tier architecture for a billing system, involving a user interface, middleware,
and a database. In the user interface, you will find concrete objects, such as buttons, menus, and dialog boxes. In the
database, you will find concrete objects, such as tables representing entities from the problem domain, including
customers, products, and orders. In the middle layer, you will find objects such as transactions and business rules, as
well as higher-level views of problem entities, such as customers, products, and orders.
The object-oriented approach to software development is decidedly a part of the mainstream simply because it has
proven to be of value in building systems in all sorts of problem domains and encompassing all degrees of size and
complexity. Furthermore, most contemporary languages, operating systems, and tools are object-oriented in some
fashion, giving greater cause to view the world in terms of objects. Object-oriented development provides the
conceptual foundation for assembling systems out of components using technology such as Java Beans or COM+.
Visualizing, specifying, constructing, and documenting object-oriented systems is exactly the purpose of the Unified
Modeling Language.

2 a) Discuss how object diagram can be used in modeling object structures.

[8]

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.

For example, Figure 14-2 shows a set of objects drawn from the implementation of an autonomous robot. This
figure focuses on some of the objects involved in the mechanism used by the robot to calculate a model of the world
in which it moves. There are many more objects involved in a running system, but this diagram focuses on only
those abstractions that are directly involved in creating this world view.
Figure 14-2 Modeling Object Structures

b) Explain the modeling semantics of class.

[7]

To model the semantics of a class, choose among the following possibilities, arranged from informal to formal.

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 postconditions of each operation, plus the invariants of the class as a whole, using
structured text. These elements are rendered in notes (stereotyped as precondition, postcondition, and
invariant) attached to the operation or class by a dependency relationship.
Specify a state machine for the class. A state machine is a behavior that specifies the sequences of states an
object goes through during its lifetime in response to events, together with its responses to those events.
Specify a collaboration that represents the class. A collaboration is a society of roles and other elements
that work together to provide some cooperative behavior that's bigger than the sum of all the elements. A
collaboration has a structural part, as well as a dynamic part, so you can use collaborations to specify all
dimensions of a class's semantics.
Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using a
formal language such as OCL.

3 a) Draw the activity diagram for ATM and explain.

b) What are the common modeling techniques of use case diagrams? Explain.-------[7]
Modeling the Context of a System -----------3M

[8]

a)To model the context of a system,

Identify the actors that surround the system by considering which groups require help from the system to
perform their tasks; which groups are needed to execute the system's functions; which groups interact with

external hardware or other software systems; and which groups perform secondary functions for
administration and maintenance.
Organize actors that are similar to one another in a generalization/specialization hierarchy.
Where it aids understandability, provide a stereotype for each such actor.
Populate a use case diagram with these actors and specify the paths of communication from each actor to
the system's use cases.

b)Modeling the Requirements of a System------- 4M

To model the requirements of a system,

Establish the context of the system by identifying the actors that surround it.
For each actor, consider the behavior that each expects or requires the system to provide.
Name these common behaviors as use cases.
Factor common behavior into new use cases that are used by others; factor variant behavior into new use
cases that extend more main line flows.
Model these use cases, actors, and their relationships in a use case diagram.
Adorn these use cases with notes that assert nonfunctional requirements; you may have to attach some of
these to the whole system.

4 a) Discuss clearly the forward and reverse engineering of component diagrams.

[8]

a)Forward and Reverse Engineering

To forward engineer a component diagram,

For each component, identify the classes or collaborations that the component implements.
Choose the target for each component. Your choice is basically between source code (a form that can be
manipulated by development tools) or a binary library or executable (a form that can be dropped into a
running system).
Use tools to forward engineer your models.

To reverse engineer a component diagram,

Choose the target you want to reverse engineer. Source code can be reverse engineered to components and
then classes. Binary libraries can be reverse engineered to uncover their interfaces. Executables can be
reverse engineered the least.
Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new model or to
modify an existing one that was previously forward engineered.
Using your tool, create a component diagram by querying the model. For example, you might start with one
or more components, then expand the diagram by following relationships or neighboring components.
Expose or hide the details of the contents of this component diagram as necessary to communicate your
intent.
b) What is a component diagram? State and explain different types of components.
[7]
COMPONENT DIAGRAM------2M
A component diagram shows a set of components and their relationships. Graphically, a component diagram is a
collection of vertices and arcs.A component diagram is just a special kind of diagram and shares the same common
properties as do all other diagramsa name and graphical contents that are a projection into a model. What
distinguishes a component diagram from all other kinds of diagrams is its particular content.
Component diagrams commonly contain

Components
Interfaces
Dependency, generalization, association, and realization relationships

Common Uses
1. To model source code
2. To model executable releases
3. To model physical databases
4. To model adaptable systems
COMPONENT-------------2M
A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of
interfaces. Graphically, a component is rendered as a rectangle with tabs.
Every component must have a name that distinguishes it from other components. A name is a textual string. That
name alone is known as a simple name; a path name is the component name prefixed by the name of the package in
which that component lives. A component is typically drawn showing only its name, as in Figure 25-2. Just as with
classes, you may draw components adorned with tagged values or with additional compartments to expose their
details, as you see in the figure.
Figure 25-2 Simple and Extended Components

Kinds of Components-----------------3M
Three kinds of components may be distinguished.
First, there are deployment components. These are the components necessary and sufficient to form an executable
system, such as dynamic libraries (DLLs) and executables (EXEs). The UML's definition of component is broad
enough to address classic object models, such as COM+, CORBA, and Enterprise Java Beans, as well as alternative
object models, perhaps involving dynamic Web pages, database tables, and executables using proprietary
communication mechanisms.
Second, there are work product components. These components are essentially the residue of the development
process, consisting of things such as source code files and data files from which deployment components are
created. These components do not directly participate in an executable system but are the work products of
development that are used to create the executable system.
Third are execution components. These components are created as a consequence of an executing system, such as a
COM+ object, which is instantiated from a DLL.
5 a) What are common causes for redesigning the design patterns? Explain them in detail. [7]
Some common causes of redesign
Creating an object by specifying a class explicitly. (Abstract Factory, Factory Method, Prototype)
Dependence on specific operations.
Dependence on hardware and software platform. (Chain of responsibility, Command)
Dependence on object representations or implementations. (Abstract Factory, Bridge)
Algorithmic dependencies

Tight coupling.
Extending functionality by subclassing.
Inability to alter classes conveniently.

5 b) Give a detailed note on organizing the catalog. [8]

Purpose

Creational

Structural

Behavioral

Class

Factory Method

Adapter(Class )

Interpreter
Template Method

Object

Abstract Factory
Builder
Prototype
Singleton

Adapter (Object)
Bridge
Composite
Decorator
Faade
Flyweight
proxy

Chain of responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
visitor

Scope

6 a) Write short notes on abstract factory pattern. [8]

Intent
Provide an interface for creating families of related or dependent objects without specifying
their concrete classes.
Motivation Problem : To be portable across look-and-feel standards, an application should not hard-code its
widgets for a particular look and feel.

instantiating look and- feel-specific classes of widgets throughout the application makes it
hard to change the look and feel later.
Solution for this problem is define an abstract WidgetFactory class that declares an interface for
creating each basic kind of widget.

6 b) Explain the structure & participants of prototype with an example [7]

Structure:

Participants
Prototype(Graphic)
- declares an interface for cloning itself.
ConcretePrototype (Staff,WholeNote,HalfNote)
- implements an operation for cloning itself.
Client(GraphicalTool)
- creates a new object by asking a prototype to clone itself.
7 a) What are the Known uses & related patterns of facade pattern? Explain. 8M.
Known uses

ObjectWorks \ Smalltalk compiler system

ET++ application frame work
The Choices Operating System uses facade to compose many framework into one.

Related Patterns
Abstract Factory
Mediator
Singleton

7 b) Write & explain the structure & participants of Decorator pattern.7M

Structure-

Participants
Component (VisualComponent)
Defines the interface for objects that can have responsibilities added to them dynamically
Concrete component (TextView)
Defines an object to which additional responsibilities can be attached
Decorator
Maintains a reference to a component object and defines an interface that conforms to
components interface
Concrete Decorator (BorderDecorator, ScrollDecorator)
Adds responsibilities to the component

8 a) What is the motivation for Iterator pattern? Explain. [8

Motivation-:
Problem
An aggregate object such as list should give you a way to access its elements without exposing its internal
structure.
We also require to traverse the list in different ways.
we do not want to expand the list interface with operations for different traversals.
Solution
The iterator pattern takes the responsibility for access and traversal out of the list object and put it into an iterator
object.

8 b) Describe the structure & participants of strategy pattern.

Structure-:

Participants-:
Strategy (Compositor)
declares an interface common to all supported algorithmsg. Context uses this interface to call the
algorithm defined by a ConcreteStrategy.
ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor)
implements the algorithm using the Strategy interface.
Context (Composition)
is configured with a ConcreteStrategy object.
maintains a reference to a Strategy object.
may define an interface that lets Strategy access its data