M.A.M. COLLEGE OF ENGINEERING, TIRUCHIRAPPALLI 621 105

M.A.M. COLLEGE OF ENGINEERING, TIRUCHIRAPPALLI 621 105
QUESTION BANK – JULY 2013 - VII SEMESTER CSE
CS1310- OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT I
PART A
1. What is meant by Object Oriented? What are advantage of object oriented
development?
Object Oriented means we organize the software as a collection of discrete objects
that incorporate both data structure and behavior.
Advantage of OO Development
• High level of abstraction
• Seamless transition among different phases of software development
• Encouragement of good programming techniques.
• Promotion of reusability.
2. Write the characteristics of an object.

Identity

Classification

Polymorphism and

Inheritance.
3. What is dynamic binding and static binding?
Dynamic binding
The process of determining (dynamically) at run time which functions to invoke is
termed dynamic binding.
Static binding
The process of determining at compile time which functions to invoke is termed
static binding.
4. Write the four quality measures for software development?

Correspondence

Correctness

Verification and

Validation.
5. What is object persistence?

Objects have life time. They are created and can exist for a period of time.

Traditionally, it has been the duration of the process in which they were
created.

A file or database can provide support for objects having a longer lifeline
longer than the duration of the process for which they were created. This
characteristics called object persistence.
6. What is cardinality?
Cardinality specifies how many instances of one class may relate to a
single instance of an associated class.
7. What is a meta-class?
A meta-class is a class about a class. They are normally used to provide instance
variables and operations.
8. What are orthogonal views of software?
 Object oriented development methods differ from traditional development
techniques in that the traditional techniques view software as a collection
of programs and isolated data.
Algorithm + data = programs
It primarily focus on functions or data.
 Object oriented methodology centers on objects which combines data and
functionality.
9. Distinguish between method and message in object.
Method and Message
i) Methods are similar to functions, procedures or subroutines in more traditional
programming languages. Message essentially are non-specific function calls.
ii) Method is the implementation. Message is the instruction.
iii) In an object oriented system, a method is invoked by sending an object a message. An
object understands a message when it can match the message to a method that has the
same name as the message.
10. What are the primary goals in the design of UML?
• Provide extensibility and specialization mechanism to extend the core concepts.
• Be independent of particular programming language and development process.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the OO tools market.
• Support higher – level development concepts.
• Integrate best practices and methodologies.
PART B
1. Briefly explain about object oriented system development (OOSD) life cycle.
Object Oriented Systems Development Life Cycle
Goals

The software development process

Building high-quality software

Object-oriented systems development

Use-case driven systems development

Prototyping

Rapid application development

Component-based development

Continuous testing and reusability
The Software Development Process
System development can be viewed as a process. The development is a process of change,
refinement, transformation or addition to existing product.
The process can be divided into small, interacting phases in to sub process. The sub processes
must be defined in such a way to allow each activity to be performed as independently of other
sub process as possible.
Each sub processes must have the following

A description in terms of how it works

Specification of the input required for the process.
Specification of the output to be produced.
The software development process also can be divided into smaller, interacting sub processes. It
can be viewed as a series of transformation.
Transformation 1(analysis) translates the users need into system requirements and
responsibilities. It provide insight into the users requirements.
Transformation2(design) begins with a problem statement and ends with a detailed design that
can be transformed into operational system. It includes software development activity, definition
of how to build the software, its development and testing.
What
How
Do it
Test
Use
FIG Software process reflecting transformation from needs to a software product that satisfy those needs
Transformation 3(Implementation) refines the detailed design into the system
deployment that will satisfy the user needs.
The essence of the software process is the transformation of

Users‘ needs to

The application domain into

A software solution.

As an example of software development process is the water fall approach which starts
with deciding what is to be done.

Once the requirement has been determined, next must decide how to accomplish them.
This is followed by a step in which “do it. We then must “test’ the result to see if we have
satisfy the user requirements.

System and programming changes in this approach, make the process increasingly
complex, since each request must be considered in regard to the original statement of
needs as modified by other requests.
Building High Quality Software
There are two basic approaches to systems testing. We can test a system according to how it has
been built. Alternatively, we can test the system with respect to what it should do.
Quality Measures
Systems can be evaluated in terms of four quality measures
Correspondence
Correctness
Verification
Validation




Correspondence measures how well the delivered system matches the needs of
the operational environment as described in the original requirement statement.
Validation is the task of predicting correspondence.
Correctness measures the consistency of the product requirement with respect to
the design specification.
Verification is the exercise of correctness.
Validation
Verification
Needs
Requirements
Correctness
Correspondence
Design
Softwrae
Object Oriented System Development: A Use-case driven Approach
The object oriented software development life cycle consists if three macro process:
Build a Use-case
Model
Object Analysis
Analysis
Validate/ Test
Iteration and Reuse
Using TOOLS
CASE and /or OOP
Programming
Languages
User
satisfaction
usability and
QA Test
Design Classes,
Define
attributes and
methods
Implementation
Build object
& dynamic
Model
Design
Fig : Object oriented System Development Approach
Object oriented development Consists of three macro processes

Object- oriented Analysis

Object oriented Design
Object-Oriented Systems has the following development activities

Object-oriented analysis.

Object-oriented design.

Prototyping.

Component-based development.
Build user
interface &
Prototype
User satisfaction Test,
usability test, QA Test

Incremental testing.
Object-Oriented Analysis
OO analysis concerns with determining the system requirements and identifying classes and their
relationships that make up an application.
Object-oriented design
The goal of object-oriented design (OOD) is to design the classes identified during the analysis
phase and the user interface. During this interface we identify and define additional objects and
classes that support implementation of the requirements.
First build the object model based on object and their relationship, then iterate and refine the
model.

Design and refine classes

Design and refine attributes

Design and refine methods

Define and refine structures

Define and refine association.
Few guideline to use object oriented design
Reuse rather than build, a new class. Know the existing class.Design a large number of simple
classes, rather than a small number of complex classes.
Prototype
A Prototype enables you to fully understand how easy or difficult it will be to implement
some of the features of the system. It can also give users a chance to comment on the usability
and usefulness of the design.
Types of Prototypes
Horizontal prototype is a simulation of the interface but contain no functionality. This has the
advantage of being very quick to implement ,providing a good overall feel of the system and
allowing users to evaluate the interface on the basis of their normal expected perception of the
system.
Vertical Prototype is a subset of the system features with complete functionality. The advantage
of this methods is that the few implemented functions can be tested in grate depth.
Analysis prototype is a aid for exploring the problem domain. This class of prototype is used to
informs the user and demonstrate the proof of concept.
Domain prototype is a aid for the incremental development of the ultimate software solution It
often used as the tools for staged delivery of the subsystem to the users or other members of the
development team.
Implementation: Component based development
Component base development is an industrial approach to the software development process.
Application development moves from custom development to assembly of prebuilt, pretested,
reusable software component that operate with each other. The basic ideas underlie component
based development.
First the application development can be improved significantly if application can be assembled
quickly from prefabricated software compacts.
Second an increasingly large collection of interpretable software component could be made
available to developers in both general and specialist catalogues.
Rapid application development is a set of tools and techniques that can be used to build an
application faster than typically possible with traditional methods. The term often is used in
conjunction with software prototyping.
Incremental Testing
If wait until after development to test an application for bugs and performance could be wasting
thousands of dollars and hours of time. The problem was the developer would turn over
application to a quality assurance group for testing only after development was completed.
2. Explain the following
(i). Class hierarchy (8)
CLASS HIERARCHY






A n object oriented system organize classes into a subclass, super class
hierarchy.
Different properties and behaviors are used as the basis for making
decision between classes and subclasses.
At the top of the class hierarchy are most general classes and at the bottom
are the more specific.
The family car in a figure is a sub classes of a car. A subclasses inherits all of
the property and methods define in it super class.
Subclasses generally add new methods and properties specific to that class.
Sub classes may refine are constraint the state and behavior inherited from
its super class .
In our example race car only one occupant the driver. In this manner sub
classes modify the attribute of tit super classes, car.
Motor Vehicle
Bus
Truck
Car
Fig: Super class / sub Class


The Car class in a formal class also called an abstract class. Formal or
abstract classes have no instance but define the common behaviors that
can be inherited by more specific classes.
In some object oriented language the terms super class and sub class are
used to instead of base and derive.
Inheritance





Inheritance is a property of object oriented system that allows objects to be build
form other object.
Inheritance allows explicitly taking advantage of the commonality of a object when
constructing new classes.
Inheritance is relationship between classes where one class is the parent class of
another class. The parent class is known as the base class or super class.
For example, The car class defines the general behavior of class. The Ford class
inherits the general behavior form the car class and adds behavior specific to
Fords.
Dynamic inheritance allows object to change and evolve other time. Since base
classes provide properties and attributes for on object, changing base classes
changes the property an attributes of class.
Vehicle
Car
Ford
Taurus
Mustang
Thunderbird
Fig: Class Hierarchy
Multiple inheritance


Some object oriented system permit a class to inherit its state and behavior from
more than one super class.
This kind of inheritance referred to as multiple inheritance. For example a utility
vehicle inherits attribute from both the car and Truck classes.



Multiple inheritance can pose some difficulties. For example several distinct
parent classes can declare a member within a multiple inheritance hierarchy.
This then can become an issue of choice particularly an several super classes
define a same method.
It also a more difficult to understand programs written in multiple inheritance
system. The benefits of multiple inheritance in the language with single
inheritance Is to inherit form the most appropriate class and then add an object of
the class as an attribute.
(ii). Object relationships and associations (8)
OBJECT RELATIONSHIPS AND ASSOCIATIONS

Association represents the relationship between object and classes. Fort
example, in the statement “A pilot can fly planes”. Here can is association.

Associations are bi directional that means they can be transferred in both
directions, perhaps with different call notations. The direction implied by
the name is the forward direction. The opposite direction is the inverse
direction.
Pilot
Can fly
Flown by
Plane
An important issue in association is cardinality, which specifies how many
instance of one class nay relate to single instances of an associated class.
 Cardinality constraints the number of related objects and often is described
as being “one or many”
Consumer Producer Association

A special form of association is a consumer producer relationship, also known as a
client server association are a use relationship.
The consumer producer relationship can be viewed as one way interaction: One
object requires a service of another object.
The object that makes the request is the consumer or client, and the object that
receives the request and provides the service is the producer or server.



3. Briefly explain about the characteristics of an object and software development
processes?
Characteristics of an object
Objects in "object-oriented programming" are essentially data structures together with
their associated processing routines. For instance, a file is an object: a collection of data
and the associated read and write routines. Objects are considered instances of classes.
1. An object has identity (it acts as a single whole).
2. An object has state (it has various properties, which might change).
3. An object has behavior (it can do things and can have things done to it).
Characteristics of OOP are:
Class definitions – Basic building blocks OOP and a single entity which has data and
operations on data together
5. Objects – The instances of a class which are used in real functionality – its variables
and operations
6. Abstraction – Specifying what to do but not how to do ; a flexible feature for
having a overall view of an object’s functionality.
4.
Encapsulation – Binding data and operations of data together in a single unit – A
class adhere this feature
8. Inheritance and class hierarchy – Reusability and extension of existing classes
9. Polymorphism – Multiple definitions for a single name - functions with same name
with different functionality; saves time in investing many function names Operator
and Function overloading
10. Generic classes – Class definitions for unspecified data. They are known as
container classes. They are flexible and reusable.
7.
Software Process


The process that deals with the technical and management issues of software
development is called a software process.
A software development project must have at least development activities and
project management activities.

The fundamental objectives of a process are the same as that of software
engineering viz. optimality and scalability.

Optimality means that the process should be able to produce high-quality software
at low cost, and scalability means that it should also be applicable for large
software projects.

To achieve these objectives, a process should have some properties. Predictability
of a process determines how accurately the outcome of following a process in a
project can be predicted before the project is completed.

Predictability can be considered a fundamental property of any process, In fact, if a
process is not predictable, it is of limited use.

One of the important objectives of the development project should be to produce
software that is easy to maintain.

And the process should be such that it ensures this maintainability. Testing
consumes the most resources during development.

Underestimating the testing effort often causes the planners to allocate
insufficient resources for testing, which, in turn, results in unreliable software or
schedule slippage.

The goal of the process should not be to reduce the effort of design and coding,
but to reduce the cost of maintenance.

Both testing and maintenance depend heavily on the design and coding of
software, and these costs can be considerably reduced if the software is designed
and coded to make testing and maintenance easier.

Hence, during the early phases of the development process the prime issues
should be "can it be easily tested" and "can it be easily modified".

Errors can occur at any stage during development. However error detection and
correction should be a continuous process that is done throughout software
development.

Detecting errors soon after they have been introduced is clearly an objective that
should be supported by the process. A process is also not a static entity.

As the productivity (and hence the cost of a project) and quality are determined
largely by the process to satisfy the engineering objectives of quality improvement
and cost reduction, the software process must be improved.

Having process improvement as a basic goal of the software process implies that
the software process used is such that is supports its improvement.
4. Explain about object oriented system development methodology.

Object-oriented development offers a different model from the traditional
software development approach, which is based on functions and procedures.

In simplified terms, object-oriented system development is a way to develop
software by building self-contained modules or objects that can be easily replaced,
modified, and reused.

Furthermore, it encourages a view of the world as a system of cooperative and
collaborating objects.

In an object-oriented environment, software is a collection of discrete objects that
encapsulate their data as well as the functionality to model real-world “objects.”

An object orientation yields important benefits to the practice of software
construction.

Each object has attributes (data) and methods (functions). Objects are grouped
into classes; in object- oriented terms, we discover and describe the classes
involved in the problem domain.

In an object-oriented system, everything is an object and each object is
responsible for itself.

For example, every Windows application needs windows objects that can open
themselves on screen and either display something or accept input.

A windows object is responsible for things like opening, sizing, and closing itself.
Frequently, when a window displays something, that something also is an object (a
chart, for example).

A chart object is responsible for things like maintaining its data and labels and
even for drawing itself.

The object-oriented environment emphasizes its cooperative philosophy by
allocating tasks among the objects of the applications.

In other words, rather than writing a lot of code to do all the things that have to
be done, you tend to create a lot of helpers that take on an active role, a spirit,
and that form a community whose interactions become the application.

Instead of saying, “system”, compute the payroll of this employee,” you tell the
employee object, “compute your payroll.” This has a powerful effect on the way
we approach software development.
UNIT II
PART A
1. What is the need of an Object diagram?
An object diagram is used to show the existence of objects and their relationships in
the logical design of a system. A static object diagram is an instance of a class
diagram. It shows snapshot of the detailed state of the system at a point in time.
2. Write some applications of object model?
They include

Air traffic control

Animation

Avionics

Database

Robotics etc.
3. Name the five levels of process maturity in OOD?

Initial

Repeatable

Defined

Managed and

Optimized
4. What are the steps followed in macro development process?

Conceptualization

Analysis and development of the model

Design or create the system architecture

Evolution or implementation

Maintenance.
5. Give short notes on OMT functional model.
OMT functional model uses dataflow diagram that shows the flow of data between
different processes in a business.Data flow diagrams use four primary symbols. They
are process, data flow, data store, external entity.
6. What is Objectory? Name the models in objectory.
Objectory, is a method or object-oriented development with the specific aim to fit the
development of large, real-time systems.
Model in objector are Use case model, domain object model, analysis object model,
implementation model, test model.
7. What is Inception?
Inception is the initial short step to establish a common vision and basic scope for the project. It
will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional
requirement, creation of a business case, and preparation of the development environment.
8. Define Domain model. Write any two advantages of modeling?
A domain model captures the most important types of objects in the context of the
business. The domain model represents the ‘things’ that exist or events that transpire
in the business environment.
Advantages:
 The main reason for modeling is the reduction of complexity.
 The cost of the modeling analysis is much lower than the cost of similar
experimentation conducted with real time.
9. Define Dynamic model?
It can be viewed as a collection of procedures or behaviors that taken together
reflect the behavior of a system over time. Dynamic modeling is the most useful during
the design and implementation phases of the system development.
10.What is a qualifier? Give one example.
A qualifier is an association attribute. The qualifier rectangle is part of the association
path, not part of the class.
For example, a person object may associate bank object. An attribute of this association is
the account#. The account# is the qualifier of this association.
PART B
1.What are the various diagrams that are used in analysis and design steps
Of Booch Methodology? Explain with your own example.
The Booch methodology covers the analysis and design phases of systems
development. Booch sometimes is criticized for his large set of symbols.
The Booch method consists of the following diagrams:
 Class diagrams
 Object diagrams
 State transition diagrams
 Module diagrams
 Process diagrams
 Interaction diagrams
Class Diagram
Class Diagram
 A class diagram describes the types of objects in the system and the various kinds
of static relationships that exist among them.
 Object diagram is instance of a class diagram. A central modeling technique that
runs through nearly all object-oriented methods.
 A class diagram shows the existence of classes and their relationships in the logical
view of a system
Interaction Diagram




Interaction diagrams describe how groups of objects collaborate to get the job
done.
Interaction diagrams capture the behavior of a single use case, showing the
pattern of interaction among objects.
The purpose of Interaction diagrams is to:
Model interactions between objects
Assist in understanding how a system (a use case) actually works
Verify that a use case description can be supported by the existing classes. Identify
responsibilities/operations and assign them to classes
There are two kinds of Interaction diagrams:
Sequence diagrams
Collaboration diagrams
State Transition Diagram
A state diagram is a type of diagram used in UML, it describe the behavior of
systems. State diagrams require that the system described is composed of a finite number
of states; sometimes, this is indeed the case, while at other times this is a
reasonable abstraction. Many forms of state diagrams exist, which differ slightly and have
different semantics.

Booch's work on object-oriented design is well matured and respected in the field
of object- oriented analysis and design.

Object-Oriented design with applications is an ideal text for introducing the
concepts of object-orientation. It is divided into three main sections, the first
introducing key object-oriented concepts, the second setting out Booch's method
for object- oriented design and the third giving five case studies.
Booch suggests the following steps for analyzing a system in preparation for designing a
solution in an object-oriented manner:
1. Define the problem.
2. Develop an informal strategy for the software realization of the real world
problem domain.
3. Formalize the strategy.
 The problem is defined in a concise, informal textual description, then information
on the objects and operations represented in the system can be obtained from
this description.
 Objects are represented by nouns, and operations by verbs. Pressman [Pres87]
notes that the first two steps are actually performed during the software
requirements analysis stage of development, rather than the design.
Booch suggests the following order of events for the formalization of the strategy:
 Identify the classes and objects at a given level of abstraction.
 Identify the semantics of these classes and objects.
 Identify the relationships among these classes and objects.
 Implement these classes and objects.
 The process of object-oriented design starts with the discovery of the classes and
objects that form the vocabulary of our problem domain;
 It stops whenever we find that there are no new primitive abstractions and
mechanisms or when the classes and objects we have already discovered may be
implemented by composing them from existing reusable software components.
 Implementing classes and objects involves delving into the classes and objects and
determining how to implement them in the chosen programming language.
 This is also the step where components are used, and the classes and objects are
structured into modules.
 The notations for class and object modeling use annotations or variant symbols
(e.g. different kinds of arrow) to convey detailed information.
 Booch suggests that a subset of the notations can be used in the earlier stages of
design, with the detail being filled in later.
 There is also a textual form for each notation, consisting of templates for
documenting each major construct.
 The notations are defined in terms of a large repertoire of symbols, but there
seems to be no real definition of syntax or static semantics.
2. Briefly explain about Rumbaugh methodology
RUMBAUGH ET AL.’S OBJECT MODELING TECHNIQUE:

The object modeling technique (OMT) presented by Jim Rumbaugh. It describes a
method for analysis, design, and implementation of a system using an objectoriented technique.

OMT is a fast, intuitive approach for identifying and modeling all the objects
making up a system.

Details such as class, attributes, method, inheritance, and association also can be
expressed easily.

The dynamic behavior of objects within a system can be described using the OMT
dynamic model.

This model lets you specify detailed state transitions and their descriptions within
a system. Finally, a process description and consumer-producer relationships can
be expressed using OMT’s functional model.OMT consists of four phases, which,
which can be performed iteratively:
1. Analysis: The results are objects and dynamic and functional models.
2. System design: The results are a structure of the basic architecture of the system
along with high-level strategy decisions.
3. Object design: This phase produces a design document, consisting of detailed
objects static, dynamic, and functional models.
4. Implementation: This activity produces reusable, extendible, and robust code.
OMT separates modeling into three different parts:
1. An object model, presented by the object model and the data dictionary.
2. A dynamic model, presented by the state diagrams and event flow diagrams.
3. A functional model, presented by data flow and constraints.
The Object Model:

The object model describes the structure of the objects in the system: their
identity, relationships to other objects, attributes, and operations.

The object model is represented graphically with an object diagram. The object
diagram contains classes interconnected by association lines. Each class
represents a set of individual objects.
Client
Account
First name
Last name
PinCode
Checking
account
withdraw
Transaction
Clinet account
Number
Balance
Acc transaction Transdate
Transtime
Transtype
Amount
postbal
Deposit
Withdraw
Create Transccation
CheckingSavinAccount
Saving account
Fig: Object Model
The association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to the objects of another class.
The OMT Dynamic Model:
OMT provides a detailed and comprehensive dynamic model, in addition to letting
you depict states, transitions, events, and actions. The OMT state transition diagram is a
network of states and events. Each state receives one or more events, at which time it
makes the transition to the next state. The next state depends on the current state as well
as the events.
The OMT Functional Model:
The OMT data flow diagrams (DFD) shows the flow of data between different
processes in a business. An OMT DFD provides a simple and intuitive method for
describing business processes without focusing on the details of computer systems.
Data flow diagrams use four primary symbols:
1. The Process is any function being performed; for example, Verify Password or PIN
in the ATM system.
2. The Data flow shows the direction of data element movement; for example, PIN
code.
3. The data store is a location where data are stored; for example, account is a data
store in the ATM example.
4. An external entity is a source or destination of a data element; for example, the
ATM card reader.
Overall, the Rumbaugh OMT methodology provides one of the strongest tool sets for
the analysis and design of object-oriented systems.
3. Explain about Booch methodology
The booch methodology is a widely used object oriented method that helps you to
design your system using object paradigm.
 This methodology covers the analysis and design phases of systems development.
Booch sometimes is criticized for his large set of symbols.

The Booch method consists of the following diagrams:
o Class diagrams Object diagrams
o State transition diagrams
o Module diagrams
o Process diagrams
o Interaction diagrams
The Booch methodology prescribes
– A macro development process
– A micro development process.
The Macro Development Process:
It servers as a controlling framework for the micro process. The primary concern is
Technical Management of the System. The macro development process consists of the
following steps:
1.
2.
3.
4.
5.
Conceptualization
Analysis and development of the model.
Design or create the system architecture.
Evolution or implementation.
Maintenance.
1.Conceptualization:
•
•
Establish the core requirements of the system
Establish a set of goals and develop prototype to prove the concept
2.Analysis and development of the modal:
• Using the class diagram to describe the roles and responsibilities objects are to
carry out in performing the desired behavior of the system.
• Using the object diagram to describe the desired behavior of the system in terms
of scenarios or, alternatively
• Using the interaction diagram to describe behavior of the system in terms of
scenarios
3.Design or create the system architecture:
• Using the class diagram to decide what mechanisms are used to regulate how
objects collaborate
• Using the module diagram to map out were each class and object should be
declared
• Using the process diagram to determine to which processor to allocate a
process. Also, determine the schedules for multiple processes on each relevant
processor
4.Evolution or implementation:
• Successively refine the system through many iterations
• Produce a stream of software implementations, each of which is refinement of
the prior one
5.Maintenance:
• Make localized changes to the system to add new requirements and eliminate bugs.
Car
color
manufacture
rsuperclass cost
inherits
Ford
inherits
Es
co
rt
Mustang
Taurus
The Micro Development Process
Each micro development process has its own micro development process.The micro
development process consists of the following steps:
•
•
•
•
Identify classes and objects.
Identify class and object semantics.
Identify class and object relationships.
Identify class and object interfaces and implementation
Operator::TurnOffAlarm
Enabled
SoundAlarm
Silenced
Sounding
SilenceAlarm
Enable
Disable
AlarmFixed
Disabled
4. Briefly explain about UML Dynamic Modeling.
Unified Modeling Language
A model is an abstract representation of a system, constructed to understand the
system prior to building or modifying it. Most of the modeling techniques involve
graphical languages.
Objectory is build around several different models
Use-case model : The use-case model defines the outside and inside of the system’s
behavior.
Domain object model: Objects of the real world are mapped into the domain object
model.
Analysis object model: The analysis object model presents how the source code should
be carried out and written.
Implementation model The implementation model represents the implementation of
the system.
Test model: The test model constitutes the test plan, specification and reports.
Static or Dynamic Models
Static Model
Static model can be viewed as a snapshot of a system’s parameter at rest or at a
specific point in time. Static model are needed to represent to represent the
structural or static aspect of a system.
Dynamic Model
A dynamic model can be viewed as a collection of procedures or behaviors that
reflect the behavior of a system over time. Dynamic relationship show how the
business objects interact to perform task.
Advantages of Modeling



Models reduce complexity by separating those aspects that are
unimportant from those that are important.
Models enhance learning.
The cost of the modeling analysis is much lower than the cost of similar
experimentation conducted with a real system.
Manipulation of the model (changing variables) is much easier than
manipulating a real system.
The goals of UML were as follows
1. Provide user a ready to use, expressive visual modeling language so they
can develop and exchange meaningful models.
2. Provide extensibility and specialization mechanism to extend the core
concepts.
3. Be independent of particular programming language and development
process.
4. Provide a formal basis for understanding the modeling language.

5. Support higher level development concept.
6. Integrate best practice and methodologies.
UML Diagrams
The UML defines nine graphical diagrams:
1. Class diagram
2. Use-case diagram
3. Behavior diagram
3.1 Interaction diagram
3.1.1 Sequence diagram
3.1.2 Collaboration diagram
3.2 State chart diagram
3.3 Activity diagram
4. Implementation diagram
4.1 Component diagram
4.2 Deployment diagram
UML Class diagram
A class diagram is a collection of static modeling elements, such as classes and their
relationship , connected to graph to each other and to their contents.
Account
Number
Balance
Deposit
Withdraw
Create Transccation
Class notation: static structure
A class is rectangle with three components separated by horizontal lines. The top name
compartment holds the class name, other general properties of the class such as
attributes are in the middle compartment and the bottom holds the list of methods.
Object diagram
A static object diagram is an instance of a class diagram. It was snapshot of the
detailed state of the system at a point in time. Notation is same for an object diagram and
class diagram.
Association Role
A simple association , a solid line connecting two class symbols. The end of an
association where it connects to a class, shows the association role. The role is part of an
association
Qualifier
A qualifier is an association attribute. For example, a person object may be
associated to a bank object.
Multiplicity
Multiplicity specifies the range of allowable associated classes. It given for roles
with in association, parts within composition, repetition and other purposes.
Use Case Diagram
A use case diagram is a graph of actor, a set of use cases enclosed
by a system boundary, communication association between the actor and the usecase
and generalization among the use cases.
Make a call
Take the call
Operator
Do research
Return a call
Spplier
The following relationship are used in use- case diagram
Communication - The communication relationship of an actor in a use case is shown by
connecting the actor symbol to the use – case symbol with a solid path.
Uses - A uses relationship between use cases is shown by a generalization arrow from the
use case.
Extends – The extend relationship is used one use case that is similar to another use case
but does it bit more.
Interaction Diagrams
UML provides two sorts of interaction diagram,
•
•
sequence and
collaboration diagrams.
Collectively, the objects which interact to perform some task, together with the links
between them, are known as a collaboration
•
•
•
Objects
o Each object is shown as rectangle, which is labelledobjectName: className
Links
o Links between objects are shown like associations in the class model.
Actors
o Actors can be shown as on a use case diagram
Diagram Page No: 104 & 105
State Chart Diagram
A state chart diagram (also called a state diagram) shows the sequence of
states that an object goes through during its life in response to outside stimuli and
messages. A state chart diagram is a view of a state machine that models the changing
behavior of a state. State chart diagrams show the various states that an object goes
through, as well as the events that cause a transition from one state to another.
Diagram model elements
The common model elements that state chart diagrams contain are:







States 
Start and end states 
Transitions 
Entry, do, and exit actions 
A state represents a condition during the life of an object during which it satisfies some
condition or waits for some event. Start and end states represent the beginning or
ending of a process. A state transition is a relationship between two states that indicates
when an object can move the focus of control on to another state once certain
conditions are met.
Activity Diagram
•
Activity Diagram – a special kind of State chart diagram, but showing the flow
from activity to activity (not from state to state).
•
Activity – an ongoing non-atomic execution within a state machine. Activities
ultimately result in some action.
– A real world process or execution of a software routine
•
Action – made up of executable atomic computations that results in a change in
state of the system or the return of a value (i.e., calling another operation, sending
a signal, creating or destroying an object, or some pure computation).
Activity diagrams commonly contain:
•
•
Activity states and action states
Transitions
Implementation diagrams
Implementation diagram show the implementation phase of systems development such
as source code structure and runtime implementation structure.
Two types of implementation diagram:


Component diagram: it shows the structure of code it self.
Deployment diagram: shows the structure of runtime system.
Component Diagram:
Component diagrams model the physical component in a design.
This high level components may or may not be equivalent to many smaller components in
the application.
Another way of looking at components is the concept of packages. A package is used to
show how you can group classes together.
Deployment Diagram:
This shows the configuration of run-time processing elements and software
components, process and objects that live in them.
It is a graph of nodes connected by communication association, nodes may contain
component, instances, which means that the component lives or runs on that node.
Components are connected by other components by dashed arrow dependencies, usually
through interfaces. (FOR DIAGRAM REFER PGNO:113 in textbook)
5. Briefly explain about design patterns and frameworks.
A pattern is an instructive information that captures the essential structure and insight of a
successful family of proven solutions to a recurring problem that arises within a certain
context and system of forces. The main idea behind using patterns is to provide
documentation to help categorize and communicate about solutions to recurring problems.
The pattern has a name to facilitate discussion and the information it represents.
A good pattern will do the following:
It solves a problem. Patterns capture solutions, not just abstract principles or
strategies.
It is a proven concept. Patterns capture solutions with a track record, not
theories or speculation.
The solution is not obvious. The best patterns generate a solution to a problem
indirectly—a necessary approach for the most difficult problems of design
It describes a relationship. Patterns do not just describe modules, but describe
deeper system structures and mechanisms. The pattern has a significant human
component. All software serves human comfort or quality of life; the best patterns
explicitly appeal to aesthetics and utility.
Framework

A framework is a way of presenting a generic solution to a problem that can be
applied to all levels in a development.

A single framework typically encompasses several design patterns and can be
viewed as the implementation of a system of design patterns.
Differences Between Design Patterns and Frameworks



Design patterns are more abstract than frameworks.
Frameworks can be embodied in the code, but only example of pattern can
be embodied in code. A strength of framework can be written in
programming language.
Design patterns are smaller architectural elements than frameworks.
A typical framework contain several design pattern but the reverse is never
true.
Design patterns are less specialized than frameworks.
Framework always have a particular application domain. The design pattern
can be used in nearly any kind of application .
6. Briefly explain about unified approach.
The unified approach to software development has the following processes and
concepts. The processes are:

Use-case driven development

Object oriented analysis

Object oriented design

Incremental development and prototyping

Continuous testing
The method and technology include

Unified modeling language used for modeling

Layered approach

Repository of object oriented system development pattern

Component based development
Object oriented Analysis
Analysis is the process of extracting the need and what the system must to do
satisfy the users requirements. The goal of object oriented analysis is to first understand the
domain of the problem and the system responsibility by understanding how the user use the
system.
OOA process consists of the following steps
1. Identify the actors
2. Develop a simple business process model using UML activity diagram
3. Develop the use case
4. Develop interaction diagram
5. Identify classes
Object oriented Design
OOD process consists of;

Designing classes, their attributes, methods, association, structure and protocols ,
apply design axioms

Design the access layer

Design and prototype user interface.

User satisfaction and usability test based on the usage / use case

Iterate and refine the design
Iterative development and continuous Testing
Since testing uncovers the design weaknesses or provide additional information
repeat the entire processes. The UA encourages the integration of testing plans from day
1 of the project. Usage scenarios or Use Cases can become test scenarios; therefore, use
cases will drive the usability testing.
Modeling based on the Unified modeling Language
The UML becoming universal language for modeling system. It is used to express model
of many different kind and purposes. The UA uses the unified modeling language (UML) to
describe and model the analysis and design phases of system development.
The UA proposed Repository
The requirement, analysis, design, and implementation documents should be stored in
the repository, so reports can be run on them for traceability. This allows us to produce
designs that are traceable across requirements, analysis, design, implementation, and
testing.
The layered approach to software development
Most systems developed with today's CASE tools or client-server application development
environments tend to lean toward what is known as two-layered architecture: interface
and data.
The better approach to system architecture is one that isolates the functions of the
interface from the function of the business. This approach also isolates the business form
the details of the data access.
The business Layer
The business layer contains all the objects that represents the business. Model the
object of the business and how they interact to accomplish the business processes. These
object should not responsible for the following.
Displaying details: Business object should have no special knowledge of how they
are being displayed and by whom. They are designed to be independent of any particular
interface, so the details of how to display an object should exist in the interface layer of
the displaying it.
Data access details: Business object also should have no special knowledge of
where they come from. It does not matter to the business model whether the data are
stored and retrieved via SQL.
The User Interface Layer
The user interface layer consists of objects with which user interacts as well as
objects needed to manage or control the interface. The user interface layer also called
view layer.
It responsible for two major aspects.
Responding to user interaction: The user interface layer object must be designed to
translate action by the user such as clicking on a button or selecting from a menu in to an
appropriate response.
Displaying business object: This layer must paint the picture of business object for the
user.
The Access Layer
The access layer contains objects that know how to communicate with the place where
the data actually reside whether it be relational database, main frame, internet or file.
The layer has two major two responsibilities:
Translate request: The access layer must be able to translate any data related request
from the business layer into the appropriate protocol for data access.
Translate results: The access layer also must be able to translate the data retrieved back
into the appropriate business object and pass those object backup into the business layer.
Access objects are identified during object oriented design.