OOAD
Transcript of OOAD
UNIT I
Introduction to OOAD – What is OOAD? – What is UML? What are the Unified Process (UP)
phases - Case study – the NextGen POS system, Inception -Use case Modeling - Relating Use
cases – include, extend and generalization.
INTRODUCTION TO OOAD
Analysis - emphasizes an investigation of the problem and requirements, rather than a
solution. For example, if a new online trading system is desired, how will it be used? What are
its functions?
"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the
requirements) or object-oriented analysis (an investigation of the domain objects).
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.
The term is best qualified, as in object-oriented design or database design.
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 itself decides what function to carry
out to service that message. The same message may be implemented by many different
functions, the one selected depending on the state of the target object.
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-oriented analysis – Object-oriented analysis (OOA) looks at the problem
domain, with the aim of producing a conceptual model of the information that exists in the area
being analyzed. Analysis models do not consider any implementation constraints that might
exist, such as concurrency, distribution, persistence, or how the system is to be built.
Implementation constraints are dealt during object-oriented design (OOD). Analysis is done
before the Design.
The sources for the analysis can be a written requirements statement, a formal vision document,
and interviews with stakeholders or other interested parties. A system may be divided into
multiple domains, representing different business, technological, or other areas of interest, each
of which are analyzed separately.
The result of object-oriented analysis is a description of what the system is functionally required
to do, in the form of a conceptual model. That will typically be presented as a set of use cases,
one or more UML class diagrams, and a number of interaction diagrams. It may also include
some kind of user interface mock-up. The purpose of object oriented analysis is to develop a
model that describes computer software as it works to satisfy a set of customer defined
requirements.
Object-oriented design - Object-oriented design (OOD) transforms the conceptual model
produced in object-oriented analysis to take account of the constraints imposed by the chosen
architecture and any non-functional – technological or environmental – constraints, such as
transaction throughput, response time, run-time platform, development environment, or
programming language.
The concepts in the analysis model are mapped onto implementation classes and interfaces. The
result is a model of the solution domain
WHAT IS 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.
WHAT IS UML?
Three ways to apply UML
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, or for
2) code generation.
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
Conceptual perspective – the diagrams are interpreted as describing things in a situation
of the real world or domain of interest.
Specification perspective - the diagrams describe software abstractions or components
with specifications and interfaces.
Implementation Perspective - the diagrams describe software implementations in a
particular technology (such as Java).
The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
Figure 1. Different perspectives with UML.
WHAT IS THE UNIFIED PROCESS (UP) PHASES?
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.
The Unified Process divides the project into four phases:
Inception
Elaboration
Construction
Transition
Inception Phase
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
During the Elaboration phase the project team is expected to capture a healthy majority of the
system requirements. However, 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, time-boxed iterations. By
the end of the Elaboration phase the system architecture must have stabilized and the executable
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.
The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the
Construction phase. At this point the plan should be accurate and credible; since it should be
based on the Elaboration phase experience and since significant risk factors should have been
addressed during the Elaboration phase.
The Lifecycle Architecture Milestone marks the end of the Elaboration phase.
Construction Phase
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, time-
boxed iterations. Each iteration results in an executable release of the software. It is customary to
write full text use cases during the construction phase and each one becomes the start of a new
iteration. Common UML (Unified Modeling Language) diagrams used during this phase include
Activity, Sequence, Collaboration, State (Transition) and Interaction 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 (or initial releases) 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.
Agile Unified Process (AUP)
It is a simplified version of the IBM Rational Unified Process (RUP).
It describes a simple, easy to understand approach to developing business application
software using agile techniques and concepts yet still remaining true to the RUP.
The AUP applies agile techniques including test driven development (TDD), Agile
Modeling, agile change management, and database refactoring to improve productivity
CASE STUDY – THE NEXTGEN POS SYSTEM
The Case study allows us to concentrate on learning fundamental OOA/D, requirements
analysis, UML and patterns, rather than explaining the problems.
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.
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.
A POS system increasingly must support multiple and varied client-side terminals and
interfaces.
INCEPTION
How long is inception?
The intent of inception is to establish some initial common vision for the objective
of the project, determine if it is feasible and decide if it is worth.
It may include the first requirement workshop, Planning for the first iteration and
then quickly moving forward to elaboration.
What Artifacts may start in Inception?
Inception is the initial short step to establish a common vision and basic scope for the
project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-
functional requirement, creation of a business case, and preparation of the development
environment.
Inception in one sentence: Envision the product scope, vision, and business case.
Table 1 lists common inception (or early elaboration) artifacts and indicates the issues
they address.
Artifact CommentVision and Business Case
Describes the high-level goals and constraints,
the business case, and provides an executive
summary.
Use-Case ModelDescribes 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 SpecificationDescribes 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 PlanDescribes the risks (business, technical,
ressource, and schedule) and ideas for their
mitigation or response.
Prototypes and proof-of-concepts To clarify the vision, and validate technical
ideas.
Iteration Plan Describes what to do in the first elaboration
iteration.
Phase Plan & Software Development PlanLow-precision guess for elaboration phase
duration and effort. Tools, people, education,
and other resources.
Development CaseA description of the customized UP steps and
artifacts for this project. In the UP, one always
customizes it for the project.
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.
USE CASE MODELINGS
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.
A Use Case Model describes the proposed functionality of a new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the system.
Example: such as Create Account or View Account Details.
Use cases are requirements, primarily functional or behavioral requirements that indicate
what the system will do. Use case defines a contract of how a system will behave.
Why use cases?
It is simple and makes it possible for the domain experts or requirement to themselves
write use cases.
It emphasize the user goals and perspective
Strength of use case is the ability to scale both up and down in terms of sophistication
and formality. Each Use Case describes the functionality to be built in the proposed
system, which can include another Use Case's functionality or extend another Use Case
with its own behavior.
A Use Case description will generally includes:
General comments and notes describing the use case.
Requirements - The formal functional requirements of things that a Use Case must
provide to the end user, such as <ability to update order>. These correspond to the
functional specifications found in structured methodologies, and form a contract that the
Use Case performs some action or provides some value to the system.
Constraints - The formal rules and limitations a Use Case operates under, defining what
can and cannot be done. These include:
o Pre-conditions that must have already occurred or be in place before the use case
is run; for example, <create order> must precede <modify order>
o Post-conditions that must be true once the Use Case is complete; for example,
<order is modified and consistent>
o Invariants that must always be true throughout the time the Use Case operates; for
example, an order must always have a customer number.
Scenarios – Formal, sequential descriptions of the steps taken to carry out the use case, or
the flow of events that occur during a Use Case instance. These can include multiple
scenarios, to cater for exceptional circumstances and alternative processing paths. These
are usually created in text and correspond to a textual representation of the Sequence
Diagram.
Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but
graphically portrayed.
Additional attributes, such as implementation phase, version number, complexity rating,
stereotype and status.
Actors
Use Cases are typically related to 'actors', which are human or machine entities that use
or interact with the system to perform a piece of meaningful work that helps them to
achieve a goal. The set of Use Cases an actor has access to define their overall role in the
system and the scope of their action.
There are three kinds of external actors.
Primary actor has user goals.
Example: the cashier.
Supporting actor provides a service (for example, information).
Example: The automated payment authorization service. Often a computer system, but could be an organization or person.
Offstage actor has an interest in the behavior of the use case
Example: a government tax agency.
Use cases can be written in different formats and levels of formality:
brief: Terse one-paragraph summary, usually of the main success scenario.
casual: Informal paragraph format. Multiple paragraphs that cover various scenarios.
fully dressed: All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.
Fully dressed Use case: Example – Process Sale
Fully dressed use cases show more detail and are structured; they dig deeper. Various
format templates are available for detailed use cases.
Here's the template:
Use Case Section Comment
Use Case Name Start with a verb.
Scope The system under design.
Level "user-goal" or "subfunction"
Primary Actor Calls on the system to deliver its services.
Stakeholders and Interests 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 A typical, unconditional happy path scenario of success.
Extensions Alternate scenarios of success or failure.
Special Requirements Related non-functional requirements.
Technology and Data Variations List Varying I/O methods and data formats.
Frequency of Occurrence Influences investigation, testing, and timing of implementation.
Miscellaneous Such as open issues.
What does the Section mean?
Scope: The scope bounds the system (or systems) under design
EX - Scope: NextGen POS application
Level: use cases are classified as at the user-goal level or the sub function level
EX - Level: user goal
Primary Actor: The principal actor that calls upon system services to fulfill a goal.
EX - Primary Actor: Cashier
Stakeholders and Interests List Important: This list is more important and practical than may
appear at first glance. It suggests and bounds what the system must do.
EX - 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.
- …
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.
EX - Preconditions: Cashier is identified and authenticated.
Success Guarantees (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.
EX - Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated.
Accounting and Inventory are updated. Commissions recorded. Receipt is generated.
Main Success Scenario and Steps (or Basic Flow): Also called “Basic Flow" or "Typical
Flow." It describes a typical success path that satisfies the interests of the stakeholders.
EX - Main Success Scenario:
1. Customer arrives at a POS checkout with items to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. …
Cashier repeats steps 3-4 until indicates done.
5. …
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.
EX - Extensions:
3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and tracking unique item identity not important
(e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
Special Requirements: If a non-functional requirement, quality attribute, or constraint relates
specifically to a use case, record it with the use case
EX - 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.
- Language internationalization on the text displayed.
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. A common
example is a technical constraint imposed by a stakeholder regarding input or output
technologies. For example, a stakeholder might say, "The POS system must support credit
account input using a card reader and the keyboard."
EX - Technology and Data Variations List:
3a. Item identifier entered by laser scanner or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict many
customers will want digital signature capture.
Relating Use cases – include, extend and generalization
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.
This is simply refactoring and linking text to avoid duplication
Example: UC1 Process Sale
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.
…
Fig 2 Use case include relationship in the Use-Case Model.
Using include with Asynchronous Event Handling:
The basic notation is to use the a*, b*, ... style labels in the Extensions section.
Example - UC1: Process FooBars
Main Success Scenario:
1. …
Extensions:
a*. At any time, Customer selects to edit personal information: Edit Personal Information.
b*. At any time, Customer selects printing help: Present Printing Help.
Terminology:
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.
Example - Process Sale is a concrete use case.
Abstract use case: An abstract use case is never instantiated by itself; it is a subfunction use
case that is part of another use case.
Example - Handle Credit Payment
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.
Example - Process Sale
Addition use case: The use case that is an inclusion, extension, or specialization is called an
addition use case.
Example - Handle Credit Payment
Addition use cases are usually abstract.
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.
Base use cases are usually concrete.
Fig 2. UML notation for the include relationship
Extend Relationship: Suppose a use case's text should not be modified (at least not
significantly) for some reason. Perhaps continually modifying the use case with myriad new
extensions and conditional steps is a maintenance headache, or the use case has been base lined
as a stable artifact, and can't be touched. How to append to the use case without modifying its
original text?
Example: UC15: Handle Gift Certificate Payment
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.
…
Fig 3. UML notation for the extend relationship
Generalization Relationship: The concepts CashPayment, CreditPayment, and CheckPayment
are all very similar. In this situation, it is possible (and useful[1]) to organize them (as in Figure
32.1) into a generalization-specialization class hierarchy (or simply class hierarchy) in which
the superclass Payment represents a more general concept, and the subclasses more specialized
ones.
Fig 4. Generalization – Specialization Hierarchy
Generalization is the activity of identifying commonality among concepts and defining
superclass (generals concept) and subclass (specialized concept) relationships. It is a way to
construct taxonomic classifications among concepts which are then illustrated in class
hierarchies.
Identifying a superclass and subclasses is of value in a domain model because their
presence allows us to understand concepts in more general, refined and abstract terms. It leads to
economy of expression, improved comprehension and a reduction in repeated information.
In the UML, the generalization relationship between elements is indicated with a large
hollow triangle pointing to the more general element from the more specialized one. Either a
separate target or shared target arrow style may be used.
Fig 5. Class hierarchy with separate and shared arrow notations