Title: OO Analysis and Design
1OO Analysis and Design
2OO Development
- Instead of programming the computer to do
calculation (in mathematical functions), OO
programming attempts to model interacting
components to build a solution. - analysis, design, and programming
3Evolution
Decomposition into functions and processes
- Programming - sequencing of instructions
- for the computer
- Procedural - Functional decomposition, functions
are building blocks data is global - Modular - Data organized in modules for functions
which operate on them - Object based - Models of objects (classes) which
encapsulate data and functions together - Object oriented - Modeling of objects also
supports inheritance and polymorphism.
Decomposition into objects and concepts
4OOA, OOD, OOP
- Object-oriented analysis, design and programming
are related but distinct. - OOA is concerned with developing an object model
of the application domain. - OOD is concerned with developing an
object-oriented system model to implement
requirements. - OOP is concerned with realising an OOD using an
OO programming language such as Java or C.
5Analysis
- OOAD - system analysis and design making use of
object-oriented programming as the technology
base to develop information system solutions
consisting of interacting objects. - investigation of the problem to find the objects
(and their relationships) in the problem domain,
to build a conceptual model - what are the concepts in the problem domain?
6Design
- OOAD - to understanding the problem domain in
terms of objects, and by properly assigning
responsibilities to the objects, their
interaction constitutes the information system
solution - figuring out what the objects are
- assigning responsibilities to these objects
- coming up with a logical solution to assign
responsibilities to these objects so that they
can interact in collaboration for a solution - what do (should) the domain concepts do?
7Construction
- implementation of the design to realize the
solution coding the model of objects which make
up the solution - realize the logical solution
8Analysis and Design
- Requirement Analysis discover and express
requirements in use cases. A Use Case is a
textual description of a business process in the
system - Domain Analysis develop a conceptual model of
the problem domain. Includes the things, the
concepts, and the roles people may take and the
relationships between them. - Design Assignment of Responsibilities
allocate tasks to software objects as well as
roles people take, illustrated in interaction
diagrams and logical class diagrams
9Analysis Activities
- define essential use cases
- refine use case diagrams
- refine conceptual model
- refine glossary
- define system sequence diagrams
- define operation contracts
- define state diagrams
10Analysis - approaches
- Domain Analysis life cycle
- Static, dynamic, and functional models
- Application Analysis and User Requirements
11OOA from www.sei.cmu.edu
- Object-oriented analysis (OOA) is concerned with
developing software engineering requirements and
specifications that expressed as a system's
object model (which is composed of a population
of interacting objects), as opposed to the
traditional data or functional views of systems.
OOA can yield the following benefits
maintainability through simplified mapping to the
real world, which provides for less analysis
effort, less complexity in system design, and
easier verification by the user reusability of
the analysis artifacts which saves time and
costs and depending on the analysis method and
programming language, productivity gains through
direct mapping to features of Object-Oriented
Programming Languages
12Design Activities
- define real use cases
- define UI and storyboards
- refine system architecture
- define interaction diagrams
- define logical class diagrams
- define database schemas
13Design (2)
- Software architectures
- Contracts
- Class design guidelines
- Error handling
- Storage management
14OOD from www.sei.cmu.edu
- Object-oriented design (OOD) is concerned with
developing an object-oriented model of a software
system to implement the identified requirements.
Many OOD methods have been described since the
late 1980s. The most popular OOD methods include
Booch, Buhr, Wasserman, and the HOOD method
developed by the European Space Agency . OOD can
yield the following benefits maintainability
through simplified mapping to the problem domain,
which provides for less analysis effort, less
complexity in system design, and easier
verification by the user reusability of the
design artifacts, which saves time and costs and
productivity gains through direct mapping to
features of Object-Oriented Programming Languages
15in OOD
- Objects are abstractions of real-world or system
entities and manage themselves. - Objects are independent and encapsulate state and
representation information. - System functionality is expressed in terms of
object services. - Shared data areas are eliminated. Objects
communicate by message passing. - Objects may be distributed and may execute
sequentially or in parallel.
16Vision Scope Document
- Business Requirements
- Vision of the Solution
- Scope and Limitations
- Business Context
?
?
?
?
17Requirements Analysis
- IEEE Standard Glossary of Software Engineering
Terminology - A condition or capability needed by a user to
solve a problem or achieve an objective - A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or
other formally imposed document - A description of needs and desires for a product
- Primary goal is to identify and document what is
really needed, in a form that clearly
communicates to both client and to development
members (and to all other stakeholders)
18Business Requirements
- High-level objectives of the organization
- These are at the top-most level of the
requirements chain - These come from
- the funding sponsor, or
- the customer, or
- marketing
19Business Requirements (cont)
- We must have these before any other (e.g., user
and functional) requirements - These must show how the project will achieve
business objectives - These are the basis for determining product
features and proposed releases - These should be very public
- Record these in a Vision and Scope document
20User Requirements
- User tasks that the user must be able to perform
- These can be described by
- use cases, or
- scenario descriptions, or
- event-response tables or
- Ex Make a reservation with the airline
- Record these in a Use Case document
21System Requirements
- These are for systems, i.e., things that
contain subsystems - Subsystems may be hardware or software or both
- People are part of a system, too
- Example Airline reservation system
- Software subsystems dbase manager, graphical UI,
communication system, etc. - Hardware subsystems Mainframes, access
terminals, communication infrastructure, etc. - People Travel agents, etc.
22Functional Requirements
- Software functionality that developers must build
to enable users to achieve their tasks - Traditional shall statements
- The system shall record the sale transaction in
the global database - The system shall provide the user with the
opportunity to edit her comment text - Upon identifying a misspelled word, the program
shall present a list of possible alternative
words/spellings
23Business Rules
- Not really software requirements, but facts and
constraints that must be respected - Corporate policies, government regulations,
industry standards, accounting practices, etc. - Sales tax is not collected on shipping charges
- Non-refundable tickets incur a fee when the
purchaser changes an itinerary.
24Quality Attributes
- Users
- Availability
- Efficiency
- Flexibility
- Integrity
- Interoperability
- Reliability
- Robustness
- Usability
- Developers
- Maintainability
- Portability
- Reusability
- Testability
25External Interfaces
- Most computer programs do not stand alone they
must co-exist - Are there external data inputs?
- Are there external outputs?
- How should local errors be explained?
- How does external data affect my user interfaces?
- etc.
26Constraints
- These are choices available to developer for
design and construction of product - Our servers are brand XXX, and run YYY software
- We are an open source shop
- All our HTML must be interpretable by IE v. xxx,
we dont care about Netscape - All of our numerical output must be correct to
within - 10e-22
27Features vs. Requirements
- A feature is a set of logically related
functional requirements - It provides capability to a user and enables
satisfaction of a business objective - Examples
- Its easy to add clip art to your presentation!
- All of last years messages from XXX can be
displayed instantly! - Our Web-Link technology discovers the identity
of selected clients in your database!
28What Requirements Are Not
- Design or implementation details
- Project planning information
- Testing strategies or details
- Other project requirements like
- Development environment
- Budget limitations
- Training
29Quality Requirements
- Defining quality
- Measured conformance with specs
- Quality as satisfied users
- What does the user expect?
- Expectations vs. specifications.
- How can we measure quality in advance of
implementation?
30Eliciting Quality Requirements
- What are your integrity requirements? probably
wont work! - Try How important is it to prevent users from
viewing orders they didnt place? - Maybe get answers on a scale (1-5)
- Ask what would constitute unacceptable
performance - Then work on specific, measurable, verifiable
requirements for each attribute
31Eliciting Requirements
- Interviews
- Joint Application Design
- Prototypes
- Questionnaires
- Observation
- Sampling
32Interviews
- First steps
- Understand the business
- Understand the terms (glossary brace, beam,
girder, strut)) - Understand the operating environment (plant tour)
- Understand what can change
- Select interviewees from all the user classes
- clerks and trench workers
- supervisors
- upper management
33Interviews (cont)
- Prepare questions tailored to the interviewee
- Open-ended vs. close-ended questions
- Gather samples of documents and reports
- Have a known management sponsor
- Stay out of power struggles!
- After, write a report, and give it to the
interviewee
34Joint Application Design
- A better interviewing technique
- Designed to shorten the requirements definition
process - Get involvement, commitment, and hopefully
ownership - Originally developed by IBM
35Rapid Prototyping
- Will our design reflect what we know how to
build, rather than what the client needs? - ...even the most talented people require
approximately a decade to reach top professional
proficiency. (Simon) - Prototypes yield much needed experience
- Plan to throw one away you will anyway
(Brooks) - Some projects are first-of-a-kind
36Prototypes (cont)
- The goal is to reduce uncertainty
- A prototype is a kind of simulation
- Among other things, prototypes may be useful for
- Process flow design
- User interface design
- Performance modeling
37Prototypes (cont)
- A prototype is not a complete specification
- Cant be used as evidence in court
- Maintenance and enhancements would be difficult,
since there is no clear current spec - The end product is insight, not a finished product
38Rapid Prototyping Dangers
- Prototypes are smoke and mirrors
- Big changes can be made quickly
- Management may think real changes to the real
system can be made just as easily. - Relying on the prototypes design will likely
make integration difficult. - Management doesnt like the idea of building
something just to be thrown away.
39And Use Cases
- a textual description of a business process in
the information system. involves with actors and
objects of the system. - - for requirements analysis
- Example
- Use Case Place an Order
- Description A customer calls a sales rep to
order a certain quantity of certain product, to
be delivered by certain due date
40More on Use Case
- A use case is a narrative document that describes
the sequence of events of an actor (an external
agent) using a system to complete a process - Use Case descriptive name of the use case
- Actors name the roles of the external parties
that interact with the use case - Purpose the intention
- Overview narrative description of the process
- Type primary, seconday, or optional
41Use Case Type
- Primary major common process
- Secondary minor or rare process
- Optional do not need to address now
- Essential Use Case expanded use case that is
expressed in an ideal form, remaining relatively
free of technology and implementation details. - Real Use Case concretely describes the process
in terms of its real current design, committed to
specific technologies for implementation.
42Use Cases
- Notice that the emphasis is on users
- Traditionally, weve asked what the system should
do - The objective is to describe all tasks that users
need/want to perform - Then the stakeholders verify that they are within
the current scope
43Main Success Scenario
- Basic flow of operations
- Also called happy path scenario
- Describes the physical success path that
satisfies the stakeholders - Suggestion
- Do not include any conditions and branching
statements at main success scenario
44Alternate Scenarios
- Things dont always go smoothly!
- Additional paths can be recorded in one or more
Alternate Course blocks - These describe reasons why the normal course (the
happy path?) isnt followed, and what alternate
actions are performed
45Alternate Scenario (cont)
- Usually considerably longer and more complex than
happy path - Indicates all branching points and conditions not
covered at Main Success Scenario
46Exceptions
- Both normal and alternate courses lead to
successful conclusions - Exceptions are different they prevent a task
from being completed - We need to elicit exception handling from users,
or else - The implementation team dreams up a response
- The system fails
47Use Case Formats
- Brief
- A one-paragraph summary, usually of the main
success scenario - Casual
- Multi-paragraphs that cover various scenarios
such as main success and alternate scenarios - Fully Dressed
- All steps and variations are written in detail,
and there are supporting sections such as
preconditions and success guarantees
48Fully Dressed Format
- Primary Actor Principle actor that calls upon
system services to fulfill a goal - Stakeholders and Interests List of stakeholders
that are affected and their interests fulfilled - Preconditions What must always be true before
beginning scenario - Postconditions What must be true on successful
completion of use case - Main Success Scenario
- Alternative Flows
- Special Requirements A non-functional
requirement, quality attribute, or constraint
that relates to use case - Technology and Data Variation List A technical
variation in how something must be done (not what
must be done). What variations in data scheme
exist - Frequency of Occurrence
- Open Issues
49Identifying Use Cases
- Actor-Based Approach
- Identify actors related to a system or
organization - Then, for each actor, identify the process they
initiate or participate in - Event-Based Approach
- Identify external events that a system must
respond to - Relate events to actors and use cases
- Yet Another Approach
- Express business processes in terms of specific
scenarios, then generalize
50Actors
- An entity external to the system who participates
in story of use case - Usually stimulates the system with input events
- Typical Actors
- Roles that people play
- Computer systems
- Electrical or mechanical devices
-
51A Common Mistake
- Do not represent individual steps, operations, or
transactions as use cases - Tip Use case is relatively large end-to-end
process description that satisfies a user goal
52Use Case Elicitation
- Ask questions like
- What is the default?
- What else should the user be able to do here?
- What should happen if ltexceptiongt?
- How fast does this need to be processed?
- Who else will use the system in this way?
- Should this be a secure operation?
53UML Use Cases
- A simple diagram, like this
Use Case
Actor
54UML Extend Relationship
- Used when a second use case story follows the
story of a prior use case - Extending a use case is, effectively, an
alternate course of base use case - Introduce an extending use case whenever logic
for an alternate course of action is at a
complexity level similar to that of your basic
course of action
55Example
University Enrolment System
Enroll In University
ltltincludegtgt
Enroll in Seminar
ltltextendgtgt
Enroll Family Member in University
Perform Security Check
56Use Cases
- Developers implement functional requirements, not
use cases or business requirement - Uses cases omits lots of details details not
concerned by end-users
57Object Modeling
- Identify objects and classes
- Prepare a data dictionary
- Identify associations between objects
- Identify attributes of objects and links
- Organize and simplify object classes using
inheritance - Verify that access paths exist for likely queries
- Iterate and refine the model
- Group classes into modules
58Conceptual Model
- Things, people, concepts, theirs roles and their
relationships in the problem domain - May use logical class diagrams to show structure
of the model of classes in the solution detailed
models of the software constructs - Objects of the classes interact (for the
solution) - The interaction can be illustrated with UML in
the Collaboration Diagrams and Sequence Diagrams
collectively known as Interaction Diagrams
59Definition
- A representation of concepts in a problem
domain J.Martin/J.Odell and M.Fowler - Most important step in OO analysis and
investigation - Decomposition of problem into individual concepts
and objects
60Conceptual Model
- It is a representation of real-world things, not
of software components - It may show
- Concepts
- Association between concepts
- Attributes of concepts
61Concepts
- Informally, an idea, thing or object
- Formally, considered in terms of its symbol,
intension and extension J.Martin/J.Odell - Symbol - words or images representing concepts
- Intension definition of a concept
- Extension set of examples to which concept
applies
62Concepts Example
- The event of a purchase transaction
- Symbol Sale
- Intension Represents the event of a purchase
transaction, and has a date and time - Extension Set of all sales
63Identifying Concepts
- General guideline
- It is better to overspecify a conceptual model
with lots of fine-grained concepts, than to
underspecify it - It is common to miss concepts during initial
phase and discover them later (e.g., during
design) - Do not exclude a concept simply because
requirements do not indicate any obvious need for
it - It is perfectly acceptable to have purely
behavioral or attributeless concepts
64Identifying Concepts (cont)
- Two strategies
- Conceptual Category List
- Noun Phrase List
65Conceptual Category List
- Create a conceptual model by making candidate
concepts from a list - Contains many common categories that worth
considering
66Conceptual Category List (cont)
67Conceptual Category List (cont)
68Noun Phrase Identification
- Proposed by R.Abbot, 1983
- Identify nouns and noun phrases in textual
description of a problem and consider them as
candidate concepts or attributes - Fully dressed use cases are excellent description
to draw concepts - Warning a mechanical noun-to-concept mapping
isnt usually possible and words in natural
language are ambiguous
69UML Notation
- In UML, conceptual model is illustrated via a set
of static structure diagrams in which no
operations are described
Concept
70How to make a conceptual model
- List candidate concepts using Concept Category
List and noun phrase identification related to
current requirements under consideration - Draw them in a conceptual model
- Add associations necessary to record
relationships for which there is a need to
preserve some memory - Add attributes necessary to fulfill information
requirements
71On Naming and Modeling Things Mapmaker
- Make a conceptual model in the spirit of how a
cartographer or mapmaker works - Use existing names in territory
- Use the vocabulary of domain when naming concepts
and attributes - Exclude irrelevant features
- Exclude concepts in the problem domain not
pertinent to the requirements (e.g., pen,
paperbag) - Do not add things that are not there
- Exclude things not in the problem domain under
consideration
72Concept vs. Attribute
- Do not represent something as an attribute when
it should have been a concept - Guideline
- If X cannot be considered as number or text in
real world, X is probably a concept, not an
attribute - Question Is Destination an attribute of Flight
or separate concept named Airport? - When in doubt, make it a separate concept
73Specification Concept
- In general, add a description or specification
concept when - Deleting instances of things they describe
results in loss of information that needs to be
maintained - It reduces redundant or duplicate information
74Definition
- An association is a relationship between concepts
that indicates some meaningful and interesting
connection
Records-current
Register
Sale
1
1
75Associations to Consider
- Knowledge of the relationship needs to be
preserved for some duration - Need-to-know associations
- Associations derived from Common Associations List
76High Priority Associations
- A is physical or logical part of B
- A is physically or logically contained in/on B
- A is recorded in B
77UML
- class description of a set of objects that share
the same attributes, operations, methods,
relationships, and semantics. - implementation class class implemented in
software construct. - operation a service that can be requested from
an object to effect certain behavior. - method implementation of an operation,
specifying the procedure (steps) for the
operation. - type specification of software entity, rather
than its implementation. - interface the set of externally visible
operations.
78UML modelling
- System Model
- From analysis to design, our effort is primarily
concerned about building a system model,
expressed in UML which is a detailed notation for
that purpose. - Analysis Model - for the investigation of the
problem domain so that we may understand the
issues involved in the problem. - Design Model - to express logically how the
system may be constructed to be the solution.
79UML diagrams
- Use Cases
- Conceptual Model concepts attributes
- Association
- Interaction Diagrams
- Collaboration Diagram
- Sequence Diagram
- Logical Class Diagram
- much more next lecture
80OO Process
- At a high level, the major steps involved are
- Plan and elaborate - planning, defining the
- requirements, feasibility (including prototype,
if appropriate) - Build - construction of the system.
- Deploy - bringing the system into use
81Plan and Elaborate
- Plan and elaborate - includes the projects
initial investigation and conception, planning,
and the specification of requirements
82Plan and Elaborate(2)
- 1. List functional requirements of the system.
- 2. Identify actors and use cases (Note system
boundary). - 3. Write all the use cases in the high-level
format, categorize them as primary, secondary, or
optional. - 4. Draw a Use Case Diagram.
- 5. Identify the most critical, influential use
cases and write them out in the expanded
essential format. - 6. Defer real use cases as far as possible.
(Certain contract situation may not allow that.) - 7. Rank the use cases.
83Rank Use Cases
- Rank the use cases in their essential forms, by
the relative importance to the final outcome of
the system. - Select a minimal set of use cases to be included
for the next development cycle. - Pick the User Cases which include
- Significant impact on the architectural design.
- Significant information and insight.
- Risky, time-critical, or complex functions.
- Use of new technology.
- Primary line-of-business processes.
- Revenue increase and/or cost reduction.
84Iterative Development
- Build . The Build phase involves repeated
development cycles within each cycle, the system
is extended. The final objective is a working
system that correctly meets the requirements.
85Key Points
- OOD is an approach to design so that design
components have their own private state and
operations. - Objects should have constructor and inspection
operations. They provide services to other
objects. - Objects may be implemented sequentially or
concurrently. - The Unified Modeling Language provides different
notations for defining different object models.
86Key Points (2)
- A range of different models may be produced
during an object-oriented design process. These
include static and dynamic system models. - Object interfaces should be defined precisely
using e.g. a programming language like Java. - Object-oriented design potentially simplifies
system evolution.