Unit 1 Ooad 2020

CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
STAFF NAME:E.LAVANYA CLASS: III/CSE SEM: V
SUBJECT CODE: CS8592 SUBJECT NAME: OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT I - UNIFIED PROCESS AND USE CASE DIAGRAMS

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
PART – A (2 Marks)
1. What is Object-Oriented Analysis?
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?

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, NOV / DEC 2013]
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? [MAY / JUNE 2013]

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

A static view of the class definitions is usefully shown with a design class diagram. This illustrates
the attributes and methods of the classes.
6. What is UML? [APRIL/MAY 2012 & MAY / JUNE 2013]

The Unified Modeling Language is a visual language for specifying, constructing and documenting
the artifacts of systems.
7. Define the inception step. [APRIL/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.
8. 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-of-concepts etc.
PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 1

9. Define Requirements and mention its types.
Requirements are capabilities and conditions to which the system and more broadly, the project must
conform.
 Functional
 Reliability
 Performance
 Supportability
10. What are Actors? [NOV / DEC 2011]

An actor is something with behavior, such as a person (identified by role), computer system, or
organization; for example, a cashier.
11. 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.
12. Define Use case. [NOV / DEC 2011, NOV / DEC 2013]
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.
13. What Tests Can Help Find Useful Use Cases?

The Boss Test
The EBP Test
The Size Test
14. 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.
15. 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.
16. Why do we need object oriented system development? [NOV / DEC 2012]
A critical ability of Object Oriented development is to skillfully assign responsibilities to software
objects. It is one activity that must be performed either while drawing a UML diagram or programming and
it strongly influences the robustness, maintainability, and reusability of software components.
17. Define a Domain Model.

Object-oriented analysis is concerned with creating a description of the domain from the perspective
of objects. There is an identification of the concepts, attributes, and associations that are considered
noteworthy. The result can be expressed in a domain model that shows the noteworthy domain concepts or
objects.

18. What are the three ways to apply UML? (NOV/DEC 2015)
1) UML as sketch Informal and incomplete diagrams created to explore difficult parts of the problem or
solution space, exploiting the power of visual languages.
2) UML as blueprint relatively detailed design diagrams used either for
i) Reverse engineering to visualize and better understanding existing code in UML diagrams,
ii) Code generation (forward engineering).
3) UML as programming language - Complete executable specification of a software system in UML.
Executable code will be automatically generated, but is not normally seen or modified by developers;
one works only in the UML "programming language”.
19. What are the three perspectives to apply UML? (NOV/DEC 2015)
Three Perspectives to Apply UML
1. Conceptual perspective the diagrams are interpreted as describing things in a situation of the
real world or domain of interest.
2. Specification perspective the diagrams describe software abstractions or components with
specifications and interfaces, but no commitment to a particular implementation (for example, not
specifically a class in C# or Java).
3. Implementation perspective the diagrams describe software implementations in a particular
technology (such as Java).
20. Define Conceptual Class.
Conceptual class is a real-world concept or thing. A conceptual or essential perspective is the UP
Domain Model contains conceptual classes.
21. Define Software Class
Software class a class representing a specification or implementation perspective of a software
component, regardless of the process or method.
22. Define Implementation Class.
Implementation class a class implemented in a specific OO language such as Java.
23. What is the Unified Process (UP)?
 A software development process describes an approach to building, deploying, and possibly
maintaining software.
 The Unified Process has emerged as a popular iterative software development process for
building object-oriented systems.
 In particular, the Rational Unified Process or RUP, a detailed refinement of the Unified Process,
has been widely adopted.
24. What is the importance of the Unified Process(UP)?
1) The UP is an iterative process. Iterative development influences how to introduce OOA/D, and to
understand how it is best practiced.
2) UP practices provide an example structure for how to do and thus how to explain OOA/D.
3) The UP is flexible, and can be applied in a lightweight and agile approach that includes practices from
other agile methods (such as XP or Scrum).
25. What are the benefits of iterative development?

Benefits include:
 less project failure, better productivity, and lower defect rates; shown by research into iterative
and evolutionary methods
 early rather than late mitigation of high risks (technical, requirements, objectives, usability,
and so forth) early visible progress
 early feedback, user engagement, and adaptation, leading to a refined system that more closely
meets the real needs of the stakeholders

 managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and
complex steps
 the learning within an iteration can be methodically used to improve the development process
itself, iteration by iteration
26. What are the other Critical UP practices?

The idea for UP practice is short time boxed iterative, evolutionary, and adaptive development.
Some additional best practices and key ideas in UP are
a) Tackle high-risk and high-value issue in early iterations
b) Continual evaluation, feedback and requirements from users
c) Build cohesive, core architecture in early iterations
d) Continuously verify quality; test early, often and realistically
e) Practice Change Request and Configuration Management
27. What are the different UP Phases?
An UP Project organizes work and iterations across four major phases:
1) Inception – approximate Vision, Business case, Scope, vague estimates
2) Elaboration – Refined Vision, iterative implementation of the core architecture, resolution of
high risks, identification of most requirements and scope, more realistic estimates
3) Construction – Iterative implementation of the remaining lower risk and easier elements, and
preparation for deployment
4) Transition – beta tests, deployment
28. What are the UP disciplines?

In the UP, an artifact is the general term for any work product : Code, Web Graphics, Schema, Test
documents, diagrams, model and so on.
Some of the artifacts in the following Disciplines are:
a) Business Modeling – The Domain Model artifact, to visualize noteworthy concepts in
the application domain
b) Requirements – The Use Case Model and Supplementary specification artifacts to
capture functional and non-functional requirements
c) Design – The Design Model artifact, to design the software artifacts
d) Implementation – Programming and building the system, not deploying it
29. What is Use-case Modeling?
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. The Use-Case Model may optionally include a UML use case
diagram to show the names of use cases and actors, and their relationships. This gives a nice context
diagram of a system and its environment. It also provides a quick way to list the use cases by name.
30. What are preconditions?
Preconditions state what must always be true before a scenario is begun in the use case.
Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true.
Typically, a precondition implies a scenario of another use case, such as logging in, that has successfully
completed.
Example:
Preconditions: Cashier is identified and authenticated.

31. List any five inception artifacts.
32. What are the types and categories of requirements?

In the UP, requirements are categorized according to the FURPS+ model [Grady92], a useful
mnemonic with the following meaning :
 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 for example, a physical box.
 Legal licensing and so forth.
33. What are the three kinds of Actors?

Actors are roles played not only by people, but by organizations, software, and machines.
There are three kinds of external actors in relation to the SuD:
1) Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.
Why identify? To find user goals, which drive the use cases.
2) 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.
Why identify? To clarify external interfaces and protocols.
3) Offstage actor has an interest in the behavior of the use case, but is not primary or supporting;
for example, a government tax agency.
Why identify? To ensure that all necessary interests are identified and satisfied.
34. What are Success guarantees (or postconditions)?

Success guarantees (or postconditions) state what must be true on successful completion of the
use case either the main success scenario or some alternate path. The guarantee should meet the needs of
all stakeholders.
Example:
Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and
Inventory are updated. Commissions recorded. Receipt is generated.
35. Define use case Include relationships.

Use cases can be related to each other. 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 subfunction use case, and indicate its
inclusion. This is simply refactoring and linking text to avoid duplication.
36. Define use case Extend relationships.

Extend Relationship
 Extend puts additional behavior in a use case that does not know about it.
 It is shown as a dotted line with an arrow point and labeled <<extend>>
 In this case, a customer can request a catalog when placing an order
37. List out any four reasons for the complexity of software. [NOV / DEC 2011]
We observe that complexity derives from four elements: the complexity of the problem domain,
the difficulty of managing the development process, the flexibility possible through software, and the
problems of characterizing the behavior of discrete systems.
38. List the relationships used in use cases. [APRIL/MAY 2012]
 include Relationship
 extend Relationship
 generalize Relationship
39. List out the steps for finding use cases. [NOV / DEC 2012]
 Choose the system boundary.
 Identify the primary actors those that have goals fulfilled through using services of the
system.
 Identify the goals for each primary actor.
 Define use cases that satisfy user goals; name them according to their goal.
40. What is the need for modeling? [MAY / JUNE 2014]
Modeling is a common approach to modeling applications, systems, and business domains by

using the object-oriented paradigm throughout the entire development life cycles. Modeling is a
main technique heavily used by both OOA and OOD activities in modern software engineering.
Modeling typically divides into two aspects of work: the modeling of dynamic behaviors like
business processes and use cases, and the modeling of static structures like classes and components.
PART – B
1. What do you mean by Unified Process in OOAD? Explain the phases with suitable diagrams.

(APRIL/MAY 2011, NOV / DEC 2011, APRIL/MAY 2012, NOV / DEC 2012, MAY / JUNE 2013 & NOV / DEC 2013,
NOV / DEC 2015)
 The Unified Software Development Process or Unified Process is a popular iterative and
incremental software development process framework.
 The refinement of the Unified Process is called Rational Unified Process (RUP).
UP Characteristics
Iterative and Incremental
• The Elaboration, Construction and Transition phases are divided into a series of timeboxed
iterations.
• Each iteration results in an increment, which is a release of the system that contains added
functionality compared with the previous release.
• Most iterations will work in most of the process disciplines the relative effort and emphasis will
change over the course of the project.
Use Case Driven
• Use cases are used to capture the functional requirements of the iterations.
• Each iteration takes a set of use cases from requirements all the way through implementation,
test and deployment.
Architecture Centric
• The UP insists on architecture of the system.
• The Unified Process supports multiple architectural models and views.
• The executable architecture baseline which is created during the Elaboration phase, serves and
validates the architecture and act as a foundation for remaining development.
Risk Focused
• The Unified Process requires the project team to focus on addressing the most critical risks early
in the project life cycle.
• The deliverables of each iteration, especially in the Elaboration phase, must be selected in order
to ensure that the greatest risks are addressed first.
UP Phases
A UP project organizes the work and iterations across four major phases:
1. Inception: approximate vision, business case, scope, vague estimates.
2. Elaboration: refined vision, iterative implementation of the core architecture, resolution of high
risks, identification of most requirements and scope, more realistic estimates.
3. Construction: iterative implementation of the remaining lower risk and easier elements, and
preparation for deployment.
4. Transition: beta tests, deployment.
UP Disciplines

• Discipline is a set of activities in one subject area, such as the activities within requirements
analysis.
• The UP describes work activities, such as writing a use case, within disciplines.
• In the UP, an artifact is the general term for any work product.
• The UP disciplines are Business Modeling, Requirements, Design, Implementation, Test,
Deployment, Configuration and change management, Project Management and Environment.
We focuses on some artifacts as follows:
 Business Modeling: The Domain Model artifact, 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: The Design Model artifact, to design the software objects.
Relationship between the Disciplines and Phases

• One iteration work goes on in most or all disciplines. However, the relative effort across these
disciplines changes over time.
• In elaboration, for example, the iterations tend to have a relatively high level of requirements
and design work, although definitely some implementation as well.
• In construction, the emphasis is heavier on implementation and lighter on requirements
analysis.
FOUR PHASES OF UNIFIED PROCESS

The Unified Process divides the project into four phases:
 Inception
 Elaboration
 Construction
 Transition
Inception Phase
 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 following elaboration phase.
 Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires doing
some requirements exploration.
 The purpose of the inception phase is not to define all the requirements, or generate a believable
estimate or project plan.
 Inception is the smallest phase in the project, and ideally it should be quite short.
 If the Inception Phase is long then it may be an indication of excessive up-front specification,
which is contrary to the spirit of the Unified Process.
 The following are typical goals for the Inception phase.
 Establish a justification or business case for the project
 Establish the project scope and boundary conditions
 Outline the use cases and key requirements that will drive the design tradeoffs
 Outline one or more candidate architectures
 Identify risks
 Prepare a preliminary project schedule and cost estimate
 The Lifecycle Objective Milestone marks the end of the Inception phase.
Elaboration Phase
 The Elaboration phase the project team is expected to capture a healthy majority of the system
requirements.
 The primary goals of Elaboration are to address known risk factors and to establish and validate
the system architecture.
 Common processes undertaken in this phase include the creation of use case diagrams,
conceptual diagrams (class diagrams with only basic notation) and package diagrams
(architectural diagrams).
 The architecture is validated primarily through the implementation of an Executable
Architecture Baseline.
 This is a partial implementation of the system which includes the core, most architecturally
significant, components.
 It is built in a series of small, timeboxed iterations. By the end of the Elaboration phase the
system architecture must have stabilized and the executable
Construction Phase
 The construction phase the product is moved from the architectural baseline to a system
complete enough to transition to the user community.
 The architectural baseline grows to become the completed system as the design is refined into
code.
 Construction is the largest phase in the project. In this phase the remainder of the system is built
on the foundation laid in Elaboration.
 System features are implemented in a series of short, timeboxed iterations.
 Each iteration results in an executable release of the software.
 Common UML (Unified Modelling Language) diagrams used during this phase include Activity,
Sequence, Collaboration, State (Transition) and Interaction Overview diagrams.
 The Initial Operational Capability Milestone marks the end of the Construction phase.

Transition Phase
 The final project phase is Transition. In this phase the system is deployed to the target users.
 Feedback received from an initial release may result in further refinements to be incorporated
over the course of several Transition phase iterations.
 The Transition phase also includes system conversions and user training. The Product Release
Milestone marks the end of the Transition phase.
 In the transition phase the goal is to ensure that the requirements have been met to the
satisfaction of the stakeholders.
 This phase is often initiated with a beta release of the application.
 Other activities include site preparation, manual completion, and defect identification and
correction.
 The transition phase ends with a postmortem devoted to learning and recording lessons for future
cycles.
2. Explain in detail about OOAD?

Object-oriented analysis and design
 OOAD is a software engineering approach that models a system as a group of interacting objects.
Each object represents some entity of interest in the system being modeled, and is characterized
by its class, its state (data elements), and its behavior.
 Various models can be created to show the static structure, dynamic behavior, and run-time
deployment of these collaborating objects.
 There are a number of different notations for representing these models, such as the Unified
Modeling Language (UML).
 Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional
requirements for a system.
 Object-oriented design (OOD) elaborates the analysis models to produce implementation
specifications. OOA focuses on what the system does, OOD on how the system does it.
Object-oriented systems
 An object-oriented system is composed of objects. The behavior of the system results from the
collaboration of those objects.
 Collaboration between objects involves those sending messages to each other. Sending a
message differs from calling a function in that when a target object receives a message,
 It decides on its own what function to carry out to service that message.
 The implementation of "message sending" varies depending on the architecture of the system
being modeled, and the location of the objects being communicated with.
Object Orientation emphasizes representation of Objects

Object-oriented analysis
 Object-oriented analysis (OOA) is the process of analyzing a task (also known as a problem
domain), to develop a conceptual model that can then be used to complete the task.
 A typical OOA model would describe computer software that could be used to satisfy a set of
customer-defined requirements.
 During the analysis phase of problem-solving, the analyst might consider a written requirements
statement, a formal vision document, or interviews with stakeholders or other interested parties.
 The task to be addressed might be divided into several subtasks (or domains), each representing a
different business, technological, or other areas of interest. Each subtask would be analyzed
separately.
Object-oriented design
 Object-oriented design (OOD), a developer applies implementation constraints to the conceptual
model produced in object-oriented analysis.
 Such constraints could include not only constraints imposed by the chosen architecture but also
any non-functional – technological or environmental – constraints, such as
transaction throughput, response time, run-time platform, development environment, or those
inherent in the programming language.
 Architecture baseline must demonstrate that the architecture will support the key system
functionality and exhibit the right behavior in terms of performance, scalability and cost.
3. Briefly explain about UML?

 The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
 The word visual in the definition is a key point the UML is the standard diagramming notation
for drawing or presenting pictures related to software primarily OO software.
 Unified Modeling Language (UML)
o Unified Modeling Language (UML) is the set of notations, models and diagrams used
when developing object-oriented (OO) systems.
o The UML was formed from the coming together of three leading software
methodologists; Booch, Jacobson and Rumbaugh.
o UML is not limited simply modeling software.
o It can also be used to build models for system engineering, business processes, and
organization structures.
o UML can be used to represent behaviors, classes, and aggregation.
Three Ways to Apply UML
In three ways people apply UML are introduced:
 UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards) created
to explore difficult parts of the problem or solution space, exploiting the power of visual
languages.
 UML as blueprint relatively detailed design diagrams used either for
1) Reverse engineering to visualize and better understanding existing code in UML
diagrams
2) Code generation (forward engineering).

 UML as programming language Complete executable specification of a software system in
UML. Executable code will be automatically generated, but is not normally seen or modified by
developers; one works only in the UML "programming language."
Three Perspectives to Apply UML
a. Conceptual perspective the diagrams are interpreted as describing things in a situation of the
real world or domain of interest.
b. Specification perspective the diagrams describe software abstractions or components with
specifications and interfaces, but no commitment to a particular implementation.
c. Implementation perspective the diagrams describe software implementations in a particular
technology.
4. Explain with an example, how Use-Case modeling is used to describe functional requirements.
Identify the actors, scenario and use cases for the example.
(APRIL/MAY 2011, APRIL/MAY 2012, MAY / JUNE 2013, NOV / DEC 2013, NOV / DEC 2015 )
 Use cases are text stories, widely used to discover and record requirements.
 Use cases are not diagrams, they are text. Focusing on secondary-value UML use case diagrams
rather than the important use case text is a common mistake for use case beginners.
 Use cases are requirements, primarily functional or behavioral requirements that indicate what
the system will do.
Use Cases and the Use-Case Model
 The UP defines the Use-Case Model within the Requirements discipline. Primarily, this 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.
 The Use-Case Model is not the only requirement artifact in the UP. There are also the
Supplementary Specification, Glossary, Vision, and Business Rules. These are all useful for
requirements analysis, but secondary at this point.
 The Use-Case Model may optionally include a UML use case diagram to show the names of use
cases and actors, and their relationships. This gives a nice context diagram of a system and its
environment. It also provides a quick way to list the use cases by name.
Actors, Scenarios, and Use Cases
 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. 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.
 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:
Three Kinds of Actors
Actors are roles played not only by people, but by organizations, software, and machines. There
are three kinds of external actors in relation to the SuD:
 Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.

 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.
 Offstage actor has an interest in the behavior of the use case, but is not primary or supporting;
for example, a government tax agency.
Three Common Use Case Formats

Use cases can be written in different formats and levels of formality:
 Brief: Terse one-paragraph summary, usually of the main success scenario. The prior Process
Sale example was brief.
 Casual: Informal paragraph format. Multiple paragraphs that cover various scenarios. The prior
Handle Returns example was casual.
 Fully dressed: All steps and variations are written in detail, and there are supporting sections,
such as preconditions and success guarantees.
Fully dressed
Fully dressed use cases show more detail and are structured
Fully dressed template:
1. Scope- The scope bounds the system (or systems) under design. Typically, a use case
describes use of one software (or hardware plus software) system; in this case it is known as
a system use case.
2. Level- Use cases are classified as at the user-goal level or the subfunction level, among
others.
3. Primary Actor- The principal actor that calls upon system services to fulfill a goal.
4. Stakeholders and Interests- This list is more important and practical than may appear at
first glance. It suggests and bounds what the system must do.
5. Preconditions and Success Guarantees (Postconditions)
Preconditions state what must always be true before a scenario is begun in the use case.
Success guarantees (or postconditions) state what must be true on successful completion of
the use case either the main success scenario or some alternate path. The guarantee should
meet the needs of all stakeholders.
6. Main Success Scenario and Steps (or Basic Flow)- This has also been called the "happy
path" scenario, or the more prosaic "Basic Flow" or "Typical Flow."
7. Extensions (or Alternate Flows)- Extensions are important and normally comprise the
majority of the text. They indicate all the other scenarios or branches, both success and
failure.
8. Special Requirements- If a non-functional requirement, quality attribute, or constraint relates
specifically to a use case, record it with the use case.
9. Technology and Data Variations List-Often there are technical variations in how something
must be done, but not what, and it is noteworthy to record this in the use case.
Guideline for Use cases

 Write in an Essential UI-Free Style
 Write Terse Use Cases
 Write Black-Box Use Cases

 Take an Actor and Actor-Goal Perspective
How to Find Use Cases

Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure is:
1. Choose the system boundary. Is it just a software application, the hardware and application
as a unit, that plus a person using it, or an entire organization?
2. Identify the primary actors those that have goals fulfilled through using services of the system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually, user-
goal level use cases will be one-to-one with user goals, but there is at least one exception, as
will be examined.
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.
Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted
from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort
- Company: Wants to accurately record transactions and satisfy customer interests.
- Manager: Wants to be able to quickly perform override operations, and easily debug Cashier
problems.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting and
Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are
recorded.
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:

*b. At any time, System fails:
Special Requirements:
- Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
- Credit authorization response within 30 seconds 90% of the time.
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or entering an
authorization code via the keyboard.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
- What are the tax law variations?
- Explore the remote service recovery issue.
5. Briefly explain the different relationships between Use Cases

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.
Terminology: Concrete, Abstract, Base, and Addition Use Cases
(i).Concrete use case
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.
(ii). Abstract 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.
(iii).Base use case
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 subfunction use case.
(iv) Addition use case
On the other hand, the use case that is an inclusion, extension, or specialization is called an
addition use case. Handle Credit Payment is the addition use case in the include relationship to Process
Sale. Addition use cases are usually abstract. Base use cases are usually concrete.
Different relationships between Use Cases are
o The include Relationship
o The extend Relationship
o The generalize Relationship
1. Include 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 subfunction use case, and
indicate its inclusion. This is simply refactoring and linking text to avoid duplication.
 This is the include relationship.
 A slightly shorter notation to indicate an included use case is simply to underline it or highlight it
in some fashion.
 A simple, practical guideline of when to use the include relationship is offered by Fowler:
 Use cases include when you are repeating yourself in two or more separate use cases and
you want to avoid repetition. Another motivation is simply to decompose an
overwhelmingly long use case into subunits to improve comprehension.
Using include with Asynchronous Event Handling
Another use of the include relationship is to describe the handling of an asynchronous event,
such as when a user is able to, at any time, select or branch to a particular window, function, or Web
page, or within a range of steps. The basic notation is to use the a*, b*, ... style labels in the Extensions
section.
2. Extend Relationship
 A use case's text should not be modified for some reason.
 Perhaps continually modifying the use case with countless new extensions and conditional
steps is a maintenance headache, or the use case has been baselined as a stable artifact, and
can't be touched.
 How to append to the use case without modifying its original text? 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. For example:
 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.
 Sometimes, the extension point is simply "At any point in use case X." This is especially
common in systems with many asynchronous events.
3. Generalize Relationship
 Generalization between use cases is similar to generalization between classes – child use
case inherits properties and behavior of the parent use case and may override the behavior of
the parent.

 Notation: Generalization is rendered as a solid directed line with a large open arrowhead
(same as generalization between classes).
6. Describe the Case Study: NextPOS System

 The first case study is the NextGen point-of-sale (POS) system. In this apparently
straightforward problem domain, we shall see that there are interesting requirement and design
problems to solve. In addition, it's a real problem groups really do develop POS systems with
object technologies.
 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. 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.
 Furthermore, we are creating a commercial POS system that we will sell to different clients with
disparate needs in terms of business rule processing.
 Each client will desire a unique set of logic to execute at certain predictable points in scenarios
of using the system, such as when a new sale is initiated or when a new line item is added.
 Therefore, we will need a mechanism to provide this flexibility and customization.
 Using an iterative development strategy, we are going to proceed through requirements, object-
oriented analysis, design, and implementation.

Architectural Layers and Case Study Emphasis
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.
• OOA/D is generally most relevant for modeling the application
logic and technical service layers.
• The NextGen case study primarily emphasizes the problem
domain objects, allocating responsibilities to them to fulfill the requirements of the application.
• Object-oriented design is also applied to create a technical service subsystem for interfacing with
a database. In this design approach, the UI layer has very little responsibility; it is said to be thin.
Windows do not contain code that performs application logic or processing. Rather, task requests
are forwarded on to other layers.
7. Define Inception. Explain about artifacts of Inception (NOV/DEC 2015)

 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 following elaboration phase.
 Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires doing
some requirements exploration. However, the purpose of the inception phase is not to define all
the requirements, or generate a believable estimate or project plan.
 At the risk of over-simplification, the idea is to do just enough investigation to form a rational,
justifiable opinion of the overall purpose and feasibility of the potential new system, and decide
if it is worthwhile to invest in deeper exploration (the purpose of the elaboration phase).
 Most requirements analysis occurs during the elaboration phase, in parallel with early
production-quality programming and testing.
 Thus, the inception phase should be relatively short for most projects, such as one or a few
weeks long. Indeed, on many projects, if it is more than a week long, then the point of inception
has been missed: It is to decide if the project is worth a serious investigation (during
elaboration), not to do that investigation.
Inception in one sentence:
Envision the product scope, vision, and business case.
The main problem solved in one sentence:
Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in
serious investigation?
Objectives
The primary objectives of the Inception phase include:
o Establishing the project's software scope and boundary conditions, including an operational
vision, acceptance criteria and what is intended to be in the product and what is not.
o Discriminating the critical use cases of the system, the primary scenarios of operation that will

drive the major design tradeoffs.
o Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the
primary scenarios
o Estimating the overall cost and schedule for the entire project (and more detailed
estimates for the elaboration phase that will immediately follow)
o Estimating potential risks (the sources of unpredictability)
Preparing the supporting environment for the project.
Essential Activities
The essential activities of the Inception include:
1. Formulating the scope of the project. This involves capturing the context and the most
important requirements and constraints to such an extent that you can derive acceptance
criteria for the end product.
2. Planning and preparing a business case. Evaluating alternatives for risk management,
staffing, project plan, and cost/schedule/profitability tradeoffs.
3. Synthesizing a candidate architecture, evaluating tradeoffs in design, and in
make/buy/reuse, so that cost, schedule and resources can be estimated. The aim here is to
demonstrate feasibility through some kind of proof of concept. This may take the form of a
model which simulates what is required, or an initial prototype which explores what are
considered to be the areas of high risk.
The prototyping effort during inception should be limited to gaining confidence that a solution
is possible - the solution is realized during elaboration and construction.
4. Preparing the environment for the project, assessing the project and the organization,
selecting tools, deciding which parts of the process to improve.
5. Milestone The Lifecycle Objectives Milestone evaluates the basic viability of the project.
6. Tailoring Decisions The example iteration workflow shown at the top of this page represents a
typical Inception iteration in medium sized projects.
The Sample Iteration Plan for Inception represents a different perspective of the breakdown of
activities to undertake in Inception iteration.
This iteration plan is more complete in terms of workflow details and activities, and as such,
more suitable for large projects.
Small projects might decide to do only a subset of these workflow details, deviations should be
challenged and documented as part of the project-specific process.
Inception Phase includes:
 Refining the scope of the project
 Project planning
 Risk identification and analysis
 Preparing the project environment
 Estimating the Budget
 In UP terms, the realistic exploration step is the elaboration phase. The preceding inception
phase is akin to a feasibility study to decide if it is even worth investing in exploratory drilling.
 Only after serious exploration (elaboration) do we have the data and insight to make somewhat
believable estimates and plans. Therefore, in iterative development and the UP, plans and
estimates are not to be considered reliable in the inception phase.
 They merely provide an order-of-magnitude sense of the level of effort, to aid the decision to
continue or not. 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 before hand 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.
Artifacts of Inception
A key insight regarding iterative development is to appreciate that these are only partially
completed in this phase, will be refined in later iterations, and should not even be created unless it is
deemed likely they will add real practical value. And since it is inception, the investigation and artifact
content should be light.
Inception artifacts
Artifact Comment
Vision and Business Case Describes the high-level goals and constraints, the business case,
and provides an executive summary.
Use-Case Model Describes the functional requirements. During inception, the names
of most use cases will be identified, and perhaps 10% of the use
cases will be analyzed in detail.
Supplementary Specification Describes other requirements, mostly non-functional. During
inception, it is useful to have some idea of the key non-functional
requirements that have will have a major impact on the
architecture.
Glossary Key domain terminology, and data dictionary.
Risk List & Risk Management Describes the risks (business, technical, resource, schedule) and
Plan ideas for their mitigation or response.
Prototypes and proof-of- To clarify the vision, and validate technical ideas.
concepts
Iteration Plan Describes what to do in the first elaboration iteration.
Phase Plan & Software Low-precision guess for elaboration phase duration and effort.
Development Plan Tools, people, education, and other resources.
Development Case A description of the customized UP steps and artifacts for this
project. In the UP, one always customizes it for the project.

8. By considering the Library Management system, perform the Object Oriented System

Development and give the use case model for the same (use include, extend and generalization).
( NOV / DEC 2011 & NOV / DEC 2012)

ANNA UNIVERSITY QUESTIONS(OLD REGULATION)
PART - A
1. What is Object Oriented Analysis and Design? (Q. No. 3)

2. Define the inception step. (Q. No. 7)
3. List out any four reasons for the complexity of software. (Q. No. 37)
4. What is UML? (Q. No. 6)
5. List the relationships used in use cases. (Q. No. 38)
6. Why do we need object oriented system development? (Q. No. 16)
7. List out the steps for finding use cases. (Q. No. 39)
8. What is Analysis and Design? (Q. No. 4)
9. What are actors? (Q. No. 10)
11. Define use case. (Q. No. 12)
12. What is the need for modeling? (Q. No. 40)
13. What are three ways and perspectives to apply UML? (Q.NO:18, 19)
PART – B
1. Briefly explain the different phases of Unified Process. (Q. No. 1)

2. Explain with an example, how usecase modeling is used to describe functional requirements. Identify the
actors, scenario and use cases for the example. (Q. No. 4)
3. What do you mean by Unified Process in OOAD? Explain the phases with suitable diagrams. (Q. No. 1)
4. By considering the Library Management system, perform the Object Oriented System Development and
give the use case model for the same (use include, extend and generalization). (Q. No. 14)
6. Explain with an example, how use case modeling is used to describe functional requirements. Identify the
8. By considering the Library Management system, perform the Object Oriented System Development and
give the use case model for the same (use include, extend and generalization). (Q. No. 14)
actors, scenario and use cases. (Q. No. 4)
13. List various UML diagrams and explain the purpose of each diagram. (Q. No 4,6,7,8,9)(Refer all the
diagrams).

ANNA UNIVERSITY QUESTION PAPERS
APRIL/MAY 2011
Part – A
2. Define the inception step. (Q. No. 7)
Part – B
2. Explain with an example, how usecase modeling is used to describe functional requirements. Identify the actors,
scenario and use cases for the example. (Q. No. 4)
NOVEMBER/DECEMBER 2011
Part – A
1. List out any four reasons for the complexity of software. (Q. No. 42)
2. What do you mean by use cases and actors? (Q. No. 10 & 12)
Part – B
2. By considering the Library Management system, perform the Object Oriented System Development and give
the use case model for the same (use include, extend and generalization). (Q. No. 8)
APRIL/MAY 2012
Part – A
2. List the relationships used in use cases. (Q. No. 43)
Part – B
Part – A
1. Why do we need object oriented system development? (Q. No. 16)
2. List out the steps for finding use cases. (Q. No. 44)
Part – B
2. By considering the Library Management system, perform the Object Oriented System Development and give
the use case model for the same (use include, extend and generalization). (Q. No. 8)
MAY / JUNE 2013
Part – A
1. What is Analysis and Design? (Q. No. 4)
Part – B
Part – A
2. Define use case. (Q. No. 12)
Part – B


Unit 1 Ooad 2020

Uploaded by

Copyright:

Available Formats

Unit 1 Ooad 2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 1 Ooad 2020

Uploaded by

Copyright:

Available Formats

CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

STAFF NAME:E.LAVANYA CLASS: III/CSE SEM: V

UNIT I - UNIFIED PROCESS AND USE CASE DIAGRAMS

2. What is Object-Oriented Design?

4. What is Analysis and Design? [MAY / JUNE 2013]

5. Define Design Class Diagrams

6. What is UML? [APRIL/MAY 2012 & MAY / JUNE 2013]

7. Define the inception step. [APRIL/MAY 2011]

8. What Artifacts May Start in Inception?

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 1

10. What are Actors? [NOV / DEC 2011]

11. What is a scenario?

13. What Tests Can Help Find Useful Use Cases?

14. What are Use Case Diagrams?

15. What are Activity Diagrams?

17. Define a Domain Model.

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 2

25. What are the benefits of iterative development?

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 3

26. What are the other Critical UP practices?

28. What are the UP disciplines?

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 4

31. List any five inception artifacts.

32. What are the types and categories of requirements?

33. What are the three kinds of Actors?

34. What are Success guarantees (or postconditions)?

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 5

35. Define use case Include relationships.

36. Define use case Extend relationships.

Modeling is a common approach to modeling applications, systems, and business domains by

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 6

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 7

Relationship between the Disciplines and Phases

FOUR PHASES OF UNIFIED PROCESS

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 8

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 9

2. Explain in detail about OOAD?

Object Orientation emphasizes representation of Objects

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 10

3. Briefly explain about UML?

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 11

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 12

Three Common Use Case Formats

Guideline for Use cases

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 13

How to Find Use Cases

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 14

5. Briefly explain the different relationships between Use Cases

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 15

 This is an example of an extend relationship.

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 16

6. Describe the Case Study: NextPOS System

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 17

Architectural Layers and Case Study Emphasis

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

7. Define Inception. Explain about artifacts of Inception (NOV/DEC 2015)

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 18

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 19

PREPARED BY: Mrs. E. LAVANYA, Asso.Prof./CSE 20