CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT I

Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use Case –
Case study – the Next Gen POS system, Inception -Use case Modelling – Relating Use
cases– include, extend and generalization – When to use Use-cases

1.1 INTRODUCTION TO OOAD

Object is a combination of data and logic that represents some real world entity. Data are called
attributes ,logic is called as functions. Example: car(object)

❖ Attributes:car name,color,number of doors

❖ Functions: stop, change,milage.

Window
Size

Color
Open()

Close()

Fig1.1 Object representation

1.1.1.Analysis and Design:

❖ Analysis emphasizes an investigation of the problem and requirements, rather than a

solution.ie)do the right thing
❖ Design emphasizes a conceptual solution that fulfills the requirements, rather than its
implementation, do the thing right

1.1.2.What is OOAD:

❖ Object-oriented analysis there emphasis on finding and describing the objects or

concepts in the problem domain.

Department of CSE Page 1

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

❖ For example, in the case of the flight information system, some of the concepts include
Plane, Flight, and Pilot.
❖ During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements.
❖ For example, a Plane software object may have a tail Number attribute and a
getFlightHistory method.

1.1.3OOAD steps:

a)Define Use Cases

❖ Requirements analysis may include a description of related domain processes; these can
be written as use cases.
❖ Use cases are written stories.
❖ They are a popular tool in requirements analysis and are an important part of the Unified
Process.
❖ For example, here is a brief version of the Play a Dice Game use case: Play a Dice Game:
A player picks up and rolls the dice.
❖ If the dice face value total seven, they win; otherwise, they lose.

b)Define a Domain Model

❖ Object-oriented analysis is concerned with creating a description of the domain from the
perspective of classification by objects.
❖ A decomposition of the domain involves an identification of the concepts, attributes, and
associations that are considered noteworthy.
❖ The result can be expressed in a domain model.

Department of CSE Page 2

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure.1.2. Partial domain model of the dice game.

c)Define interaction diagrams:

❖ Object-oriented design is concerned with defining software objects their responsibilities

and collaborations.
❖ A common notation to illustrate these collaborations is the sequence diagram.
❖ It shows the flow of messages between software objects, and thus the invocation of
methods.

Figure1.3.Sequence diagram illustrating messages between software objects.

d)Define Design class diagrams:

❖ The static view of the class definitions is usually shown with a design class diagram.
This illustrates the attributes and methods of the classes.
❖ Domain model, shows real-world concepts; but DCD shows software classes.

Department of CSE Page 3

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure1.4 Partial design class diagram.

1.2.UNIFIED PROCESS

❖ The UP is an iterative process. The UP promotes several best practices iterative

development.
❖ In this approach, development is organized into a series of short, fixed-length (for
example, four week) mini-projects called iterations; the outcome of each is a tested,
integrated, and executable system.
❖ Each iteration includes its own requirements analysis, design, implementation, and
testing activities.

1.2.1 What is Iterative and Evolutionary Development?

❖ Development is organized into a series of short, fixed-length mini-projects called

iterations; the outcome of each is a tested, integrated, and executable partial system.
❖ Each iteration includes its own requirements analysis, design, implementation, and
testing activities.
❖ The system grows incrementally over time, iteration by iteration, and thus this approach
is also known as iterative and incremental development

Advantages of UP:

❖ Rapid feedback from users and developers

❖ Then adapt to changes in the next iteration (adaptive development)
❖ Visible progress
❖ Start with high risk

Department of CSE Page 4

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

❖ Manage complexity by dividing the problem into smaller ones

1.2.2Risk-Driven and Client-Driven Iterative Planning?

In risk-driven and client-driven iterative planning, the goals of the early iterations are chosen to

1) identify and drive down the highest risks, and

2) build visible features that the client cares most about.

Risk-driven iterative development includes more specifically the practice of architecture-centric

iterative development, meaning that early iterations focus on building, testing, and stabilizing the
core architecture.

1.2.3Best practices and key concepts in UP:

• tackle high-risk and high-value issues in early iterations

• continuously engage users for evaluation, feedback, and requirements
• build a cohesive, core architecture in early iterations
• continuously verify quality; test early, often, and realistically
• apply use cases where appropriate
• do some visual modeling (with the UML)
• carefully manage requirements
• practice change request and configuration management

1.2.4. UP Phases:

Four phases are:

1.Inception

2.Elaboration

3.Construction.

4.Transition.

Department of CSE Page 5

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.Inception

❖ Approximate vision, business case, scope, vague estimates.

❖ Inception is a feasibility phase, where just enough investigation is done to support a
decision to continue or stop.

2.Elaboration

❖ In this phase the core architecture is iteratively implemented, and high-risk issues are
mitigated, refined vision, iterative implementation of the core architecture, resolution of
high risks, identification of most requirements and scope, more realistic estimates are
made.

3.Construction

Iterative implementation of the remaining lower risk and easier elements, and preparation
for deployment.

4.Transition

Beta tests, deployment.

Figure1.5 Schedule-oriented terms in the UP.

Department of CSE Page 6

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.2.5.UP disciplines:

❖ The UP describes work activities, such as writing a use case, within disciplinesa set of
activities (and related artifacts) in one subject area, such as the activities within
requirements analysis.
❖ In the UP, an artifact is the general term for any work product: code, Web graphics,
database schema, text documents, diagrams, models, and so on.

There are several disciplines in the UP;

➢ Business Modeling - to visualize noteworthy concepts in the application domain.

➢ Requirements The Use-Case Model and Supplementary Specification artifacts to
capture functional and non-functional requirements.
➢ Design - to design the software objects.
➢ In the UP, Implementation means programming and building the system, not
deploying it.
➢ The Environment discipline refers to establishing the tools and customizing the
process for the project that is, setting up the tool and process environment.

1.3 UML DIAGRAMS

❖ The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
❖ Unified Modeling Language (UML) is a standardized general-purpose modeling
language in the field of software engineering.
❖ The standard is managed, and was created by, the Object Management Group. UML
includes a set of graphic notation techniques to create visual models of software-intensive
systems.

There are two broad categories of diagrams and they are again divided into subcategories −

1. Structural Diagrams
2. Behavioral Diagrams

Department of CSE Page 7

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1. Structural Diagrams

❖ The structural diagrams represent the static aspect of the system. These static aspects
represent those parts of a diagram, which forms the main structure and are therefore
stable.
❖ These static parts are represented by classes, interfaces, objects, components, and nodes.
The four structural diagrams are
a) Class diagram
b) Object diagram
c) Component diagram
d) Deployment diagram

A)Class Diagram

➢ Class diagrams are the most common diagrams used in UML. Class diagram consists of
classes, interfaces, associations, and collaboration. Class diagrams basically represent the
object-oriented view of a system, which is static in nature.
➢ Active class is used in a class diagram to represent the concurrency of the system.
➢ Class diagram represents the object orientation of a system.
➢ Hence, it is generally used for development purpose. This is the most widely used
diagram at the time of system construction.

b)Object Diagram

➢ Object diagrams can be described as an instance of class diagram. Thus, these diagrams
are more close to real-life scenarios where we implement a system.
➢ Object diagrams are a set of objects and their relationship is just like class diagrams.
They also represent the static view of the system.
➢ The usage of object diagrams is similar to class diagrams but they are used to build
prototype of a system from a practical perspective.

Department of CSE Page 8

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

c)Component Diagram

➢ Component diagrams represent a set of components and their relationships. These

components consist of classes, interfaces, or collaborations.
➢ Component diagrams represent the implementation view of a system.
➢ During the design phase, software artifacts (classes, interfaces, etc.) of a system are
arranged in different groups depending upon their relationship.
➢ Now, these groups are known as components.
➢ Finally, it can be said component diagrams are used to visualize the implementation.

d)Deployment Diagram

➢ Deployment diagrams are a set of nodes and their relationships. These nodes are physical
entities where the components are deployed.
➢ Deployment diagrams are used for visualizing the deployment view of a system. This is
generally used by the deployment team.

2)Behavioral Diagrams

➢ Any system can have two aspects, static and dynamic. So, a model is considered as
complete when both the aspects are fully covered.
➢ Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect
can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams −

a) Use case diagram

b) Sequence diagram
c) Collaboration diagram
d) State chart diagram
e) Activity diagram

Department of CSE Page 9

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

a)Use Case Diagram

➢ Use case diagrams are a set of use cases, actors, and their relationships. They represent
the use case view of a system.
➢ A use case represents a particular functionality of a system.
➢ Hence, use case diagram is used to describe the relationships among the functionalities
and their internal/external controllers. These controllers are known as actors.

b)Sequence Diagram

➢ A sequence diagram is an interaction diagram.

➢ From the name, it is clear that the diagram deals with some sequences, which are the
sequence of messages flowing from one object to another.
➢ Interaction among the components of a system is very important from implementation
and execution perspective.
➢ Sequence diagram is used to visualize the sequence of calls in a system to perform a
specific functionality.

c)Collaboration Diagram

➢ Collaboration diagram is another form of interaction diagram. It represents the structural

organization of a system and the messages sent/received.
➢ Structural organization consists of objects and links.
➢ The purpose of collaboration diagram is similar to sequence diagram.
➢ However, the specific purpose of collaboration diagram is to visualize the organization of
objects and their interaction.

d)State chart Diagram

➢ Any real-time system is expected to be reacted by some kind of internal/external events.

These events are responsible for state change of the system.
➢ State chart diagram is used to represent the event driven state change of a system. It
basically describes the state change of a class, interface, etc.

Department of CSE Page 10

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

➢ State chart diagram is used to visualize the reaction of a system by internal/external

factors.

e)Activity Diagram

➢ Activity diagram describes the flow of control in a system. It consists of activities and
links. The flow can be sequential, concurrent, or branched.
➢ Activities are nothing but the functions of a system. Numbers of activity diagrams are
prepared to capture the entire flow in a system.
➢ Activity diagrams are used to visualize the flow of controls in a system. This is prepared
to have an idea of how the system will work when executed.

1.4.USE CASES

Use cases are text stories widely used to discover and record requirements. They are text stories
of some actor using a system to meet goals.

Example: Process sale

A customer arrives at a checkout with items to purchase. The cashier uses the POS system to
record each purchased item. The system presents a running total and line-item details. The
customer enters payment information, which the system validates and records. The system
updates inventory. The customer receives a receipt from the system and then leaves with the
items.

1..4.1Actors, Scenarios, and Use Cases

Actor: an actor is something with behavior, such as a person (identified by role), computer
system, or organization; for example, a cashier.

A scenario is a specific sequence of actions and interactions between actors and the system; it is
also called a use case instance.

Department of CSE Page 11

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

❖ It is one particular story of using a system, or one path through the use case; for example,
the scenario of successfully purchasing items with cash, or the scenario of failing to
purchase items because of a credit payment denial.
❖ Informally then, a use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal.

For example, here is a casual format use case with alternate scenarios:

Handle Returns

Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses
the POS system to record each returned item

Alternate Scenarios:

❖ If the customer paid by credit, and the reimbursement transaction to their credit account
is rejected, inform the customer and pay them with cash.
❖ If the item identifier is not found in the system, notify the Cashier and suggest manual
entry of the identifier code (perhaps it is corrupted).
❖ If the system detects failure to communicate with the external accounting system, …

1.4.2.Use case Model:

Use case model is the set of all written use cases; it is a model of the system's
functionality and environment.

Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing
text, not drawing diagrams.

Department of CSE Page 12

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.4.3. Kinds of actors:

1.Primary actor

Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.

2.Supporting actor

❖ Supporting actor provides a service (for example, information) to the SuD.

❖ The automated payment authorization service is an example. Often a computer
system, but could be an organization or person.

3.Offstage actor

Offstage actor has an interest in the behavior of the use case, but is not primary or
supporting; for example, a government tax agency.

Department of CSE Page 13

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.4.4. Three Common Use Case Formats

1.brief Terse one-paragraph summary, usually of the main success scenario. The prior
Process Sale example was brief
2.casual Informal paragraph format. Multiple paragraphs that cover various scenarios.
The prior Handle Returns example was casual.
3.fully dressed All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.

1.4.5. How to find Use cases:?

1.Choose the system boundary.

2.Identify the primary actors.
3.Identify the goals for each primary actor.
4.Define use cases that satisfy user goals. Name them according to their goal.

1.4.6.Use case section:

Use case section Comment

Use case name Start with verb
Scope The system under design
Level “user goal “or “sub function”
Primary actor Calls on the system to deliver its services
Stack holder&Interest Who cares about this use case and what do
they want
Preconditions What must be true on start, and worth telling
the reader
Success Guarantee What must be true on successful completion
and worth telling the reader
Main success scenario Unconditional happy path scenario of success
Extensions Alternate scenarios of success or failure
Special requirements Related nonfunctional requirements
Technology and data variations list Varying I/O methods and data formats

Department of CSE Page 14

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Frequency of occurrence Influence investigation testing timing of

implementation.
Miscellaneous Such as open issues

1.4.6.Use case diagrams:

Use Case Diagrams The UML provides use case diagram notation to illustrate the names
of use cases can actors, and the relationships between them. It serves as a communication tool
that summarizes the behavior of the system and its actors.

Figure 1.6. Partial use case context diagram.

1.5.THE NEXTGEN POS SYSTEM

❖ The case study is the NextGen point-of-sale (POS) system

❖ A POS system is a computerized application used (in part) to record sales and handle
payments;
❖ it is typically used in a retail store. It includes hardware components such as a computer
and bar code scanner, and software to run the system.
❖ It interfaces to various service applications, such as a third-party tax calculator and
inventory control.

Department of CSE Page 15

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

❖ These systems must be relatively fault-tolerant; that is, even if remote services are
temporarily unavailable (such as the inventory system), they must still be capable of
capturing sales and handling at least cash payments (so that the business is not crippled).
❖ A POS system increasingly must support multiple and varied client-side terminals and
interfaces.
❖ These include a thin-client Web browser terminal, a regular personal computer with
something like a Java Swing graphical user interface, touch screen input, wireless PDAs,
and so forth

1.5.1Architectural Layers

❖ A typical object-oriented information system is designed in terms of several architectural

layers or subsystems. The following is not a complete list, but provides an example:

• User Interface—graphical interface; windows.

• Application Logic and Domain Objects—software objects representing domain

concepts (for example, a software class named Sale) that fulfill application requirements.

• Technical Services—general purpose objects and subsystems that provide

supporting technical services, such as interfacing with a database or error logging. These
services are usually application-independent and reusable across several systems.

Department of CSE Page 16

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.6.INCEPTION

Inception is the initial short step to establish a common vision and basic scope for the
project. Inception is Envision the product scope, vision, and business case.

1.6.1 How Long is Inception?

❖ The intent of inception is to establish some initial common vision for the objectives of the
project, determine if it is feasible, and decide if it is worth some serious investigation in
elaboration.
❖ If it has been decided beforehand that the project will definitely be done, and it is clearly
feasible (perhaps because the team has done projects like this before), then the inception
phase will be especially brief.
❖ It may include the first requirements workshop, planning for the first iteration, and then
quickly moving forward to elaboration.

1.62. Inception artifact:

The following table shows some sample inception artifacts:

Department of CSE Page 17

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.6.3.How Much UML During Inception?

The purpose of inception is to collect just enough information to establish a common vision,
decide if moving forward is feasible, and if the project is worth serious investigation in the
elaboration phase. Inception focuses on understanding the basic scope and 10% of the
requirements, expressed mostly in text forms.

1.6.4.Undestanding Requirements:

Requirements are capabilities and conditions to which the systemand more broadly, the
project must conform.

Types of Requirements

In the UP, requirements are categorized according to the FURPS+ model

• Functional—features, capabilities, security.

• Usability—human factors, help, documentation.
• Reliability—frequency of failure, recoverability, predictability.
• Performance—response times, throughput, accuracy, availability, resource usage.
• Supportability—adaptability, maintainability, internationalization, configurability.
The "+" in FURPS+ indicates ancillary and sub-factors, such as:
• Implementation—resource limitations, languages and tools, hardware, ...
• Interface—constraints imposed by interfacing with external systems.
• Operations—system management in its operational setting.
• Packaging
• Legal—licensing

Department of CSE Page 18

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1.7. USECASE MODELING:

❖ The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the
system.
❖ A Use Case is a single unit of meaningful work; for example login to system, register
with system and create order are all Use Cases.
❖ Each Use Case has a description which describes the functionality that will be built in the
proposed system.
❖ A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case
with its own behavior. Use Cases are typically related to 'actors'.
❖ An actor is a human or machine entity that interacts with the system to perform
meaningful work.
❖ Actors-An Actor is a user of the system.
❖ This includes both human users and other computer systems. An Actor uses a Use
Case to perform some piece of work which is of value to the business.
❖ The set of Use Cases an actor has access to defines their overall role in the system and the
scope of their action. Constraints, Requirements and Scenarios

The formal specification of a Use Case includes:

1. Requirements: These are the formal functional requirements that a Use Case must
provide to the end user. They correspond to the functional specifications found in structured
methodologies. A requirement is a contract that the Use Case will perform some action or
provide some value to the system.

2. Constraints: These are the formal rules and limitations that a Use Case operates under,
and includes pre-post-and invariant conditions. A pre-condition specifies what must have already
occurred or be in place before the Use Case may start. A post-condition documents what will be
true once the Use Case is complete. An invariant specifies what will be true throughout the
time the Use Case operates.

Department of CSE Page 19

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.Scenarios:Scenarios are formal descriptions of the flow of events that occurs

during a Use Case instance. These are usually described in text and correspond to a
textual representation of the Sequence Diagram.

1.8. RELATING USECASES:

Use cases can be related to each other. Organizing use cases into relationships has no
impact on the behavior or requirements of the system. It is simply an organization mechanism to
improve communication and comprehension of the use cases, reduce duplication of text, and
improve management of the use case documents.

1.8.1.Relationships of use case:

The Three relationships of use cases are:

1.The include Relationship
2.The extend Relationship
3.The generalize Relationship

1.The include Relationship:

❖ This is the most common and important relationship.

❖ It is common to have some partial behavior that is common across several use
cases.
❖ For example, the description of paying by credit occurs in several use cases,
including Process Sale, Process Rental, Contribute to Lay-away Plan, and so
forth.
❖ Rather than duplicate this text, it is desirable to separate it into its own sub
function use case, and indicate its inclusion.
❖ For example: UC1: Process Sale

Department of CSE Page 20

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Main Success Scenario:

1 . Customer arrives at a POS checkout with goods and/or services to purchase. .

7. Customer pays and System handles payment.

Extensions:

7b. Paying by credit: Include Handle Credit Payment.

7c. Paying by check: Include Handle Check Payment.

UC7: Process Rental

Extensions: 6b.

Paying by credit: Include Handle Credit Payment.

UC12: Handle Credit Payment

Level: Sub function Main Success Scenario:

1. Customer enters their credit account information.

2. System sends payment authorization request to an external Payment Authorization

Service System, and requests payment approval.

3. System receives payment approval and signals approval to Cashier.

4. ...

Extensions:

2a. System detects failure to collaborate with external system:

1 . System signals error to Cashier.

Department of CSE Page 21

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

2. Cashier asks Customer for alternate payment.

Include relationship can be simply indicated by underline it or highlight it.

UC1: Process FooBars

Main Success Scenario:

1. ... Extensions:
2. a*. At any time. Customer selects to edit personal information: Edit Personal
Information.
3. b*. At any time. Customer selects printing help: Present Printing Help. 2-1 1 . Customer
cancels: Cancel Transaction Confirmation.

The include relationship can be used for most use case relationship problems.

1.8.2.Terminology: Concrete, Abstract, Base, and Addition Use Cases

A concrete use case is initiated by an actor and performs the entire behavior desired by
the actor. These are the elementary business process use cases. For example, Process Sale is a
concrete use case.
An abstract use case is never instantiated by itself; it is a sub function use case that is part of
another use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is always
part of another story, such as Process Sale.
A use case that includes another use case, or that is extended or specialized by another use case
is called a base use case. Process Sale is a base use case with respect to the included Handle
Credit Payment sub function use case.

2.The extend Relationship

The extend relationship provides an answer. The idea is to create an extending or addition
use case, and within it, describe where and under what condition it extends the behavior of some
base use case.

Department of CSE Page 22

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

UC1: Process Sale (the base use case)

Extension Points: VIP Customer, step

1 . Payment, step 7. Main Success Scenario: 1 . Customer arrives at a POS checkout with
goods and/or services to purchase. … 7. Customer pays and System handles payment. …

UC15: Handle Gift Certificate Payment (the extending use case)

… Trigger: Customer wants to pay with gift certificate. Extension Points: Payment in
Process Sale. Level: Sub function Main Success Scenario: 1 . Customer gives gift certificate to
Cashier. 2. Cashier enters gift certificate ID. …

This is an example of an extend relationship. Extension points are labels in the base use
case which the extending use case references as the point of extension, so that the step
numbering of the base use case can change without affecting the extending use case—indirection
yet again.

1.8.3.The generalize Relationship:

This is an optional relationship.

It adds another level of complexity to use cases.

1.8.4.Use Case Diagrams

❖ The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the
system.A Use Case is a single unit of meaningful work; for example login to system,
register with system and create order are all Use Cases. A Use Case may 'include' another
Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases
are typically related to 'actors'.

Department of CSE Page 23

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure1.8.4 Use case include relationship in the Use-Case Model.

The extend relationship notation is illustrated in Figure

Figure 1.8The extend relationship

Department of CSE Page 24

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

POSSIBLE TWO MARKS

1.What is Object-Oriented Analysis? Nov/Dec 2016

During object-oriented analysis there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the flight information system, some
of the concepts include Plane, Flight, and Pilot.

2. What is Object-Oriented Design?

During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. The combination of these
two concepts shortly known as object oriented analysis and design.

3. What is Object-Oriented Analysis and Design? APRIL/MAY-2011

During object-oriented analysis there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the flight information system, some
of the concepts include Plane, Flight, and Pilot.

During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. The combination of these
two concepts shortly known as object oriented analysis and design.

4. What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a solution.
Design emphasizes a conceptual solution (in software and hardware) that fulfills the
requirements, rather than its implementation. For example, a description of a database schema
and software objects.

5. Define Design Class Diagrams April/May 2016

A static view of the class definitions is usefully shown with a design class diagram. This
illustrates the attributes and methods of the classes.

Department of CSE Page 25

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

6. What is the UML? MAY/JUNE 2012

The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.

7. What are the three ways and perspectives to Apply UML?

Ways - UML as sketch, UML as blueprint, UML as programming language

Perspectives-Conceptual perspective, Specification (software) perspective, Implementation
(Software) perspective.

8. What is Inception? APIRAL/MAY-2011

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 so
that programming can start in the elaboration phase. Inception in one Sentence: Envision the
product scope, vision, and business case.

9. What Artifacts May Start in Inception?

Some sample artifacts are Vision and Business Case, Use-Case Model, Supplementary
Specification, Glossary, Risk List & Risk Management Plan, Prototypes and proof-ofconcepts
etc.

10. Define Requirements and mention its types.

Requirements are capabilities and conditions to which the system and more broadly, the project
must conform.
1. Functional
2. Reliability
3. Performance
4. Supportability

Department of CSE Page 26

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

11. What are Actors?

An actor is something with behavior, such as a person (identified by role), computer system, or
organization; for example, a cashier.

12. What is a scenario?

A scenario is a specific sequence of actions and interactions between actors and the system; it is
also called a use case instance. It is one particular story of using a system, or one path through
the use case; for example, the scenario of successfully purchasing items with cash, or the
scenario of failing to purchase items because of a credit payment denial.

13. Define Use case. A use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal. Use cases are text documents, not diagrams,
and use-case modeling is primarily an act of writing text, not drawing diagrams.

14. What are Three Kinds of Actors?

Primary actor, Supporting actor, offstage actor.

15. What Tests Can Help Find Useful Use Cases?

1. The Boss Test

2. The EBP Test
3. The Size Test 16.

17.What are Use Case Diagrams?

A use case diagram is an excellent picture of the system context; it makes a good context
diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used.
It serves as a communication tool that summarizes the behavior of a system and its actors.

Department of CSE Page 27

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

18. What are Activity Diagrams?

A diagram which is useful to visualize workflows and business processes. These can be a useful
alternative or adjunct to writing the use case text, especially for business use cases that describe
complex workflows involving many parties and concurrent actions.

19. List the relationships used in use cases? MAY/JUNE 2012

1.Include
2.Extend
3.Generalize

20.List out the steps for finding use cases. NOV/DEC 2012

❖ Identifify the actor Name the use cases

❖ Describe the usecse by using terminologies.

21. What is an object?

An object is a combination of data and logic; the representation of some real-world entity.

22. What is the main advantage of object-oriented development?

• High level of abstraction

• Seamless transition among different phases of software development
• Encouragement of good programming techniques.
• Promotion of reusability.

23. What is Object Oriented System development methodology?

Object oriented system development methodology is a way to develop software by building self-
contained modules or objects that can be easily replaced, modified and reused.

24. Distinguish between method and message in object.

Department of CSE Page 28

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

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

PART B QUESTIONS
1.What is the unified process?Is the UP iterative and incrementa?Expalin:
2.Explain about Unified process phases?
3.Explain about use case model for a case study of your choice?
4.List out the various UML diagrams?
5.Write about Inception
6.Discuss about relationships in use case diagrams?

PART C QUESTIONS

1.Draw the use case diagram FOR Online recruitment system.

2.Draw the usecase diagram for the following:

A coffee machine dispense coffee to customers. Customers order coffee by selecting a

recipe from a set of recipes. Customers pay for the bill using coins. Change is given back, if any.
The service staff loads ingredients(coffee power,milk,sugar,water,chocolate) into the coffee
machine. The service staff can also add a recipe by indicating the name of the coffee, the units
coffee power,milk,sugar to be added as well as the cost of the coffee?

Department of CSE Page 29