OO Analysis and Design - PowerPoint PPT Presentation

1 / 86
About This Presentation
Title:

OO Analysis and Design

Description:

refine glossary. define system sequence diagrams. define ... IEEE Standard Glossary of Software ... the terms (glossary: brace, beam, girder, ... – PowerPoint PPT presentation

Number of Views:81
Avg rating:3.0/5.0
Slides: 87
Provided by: carbonC
Category:

less

Transcript and Presenter's Notes

Title: OO Analysis and Design


1
OO Analysis and Design
2
OO 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

3
Evolution
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
4
OOA, 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.

5
Analysis
  • 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?

6
Design
  • 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?

7
Construction
  • implementation of the design to realize the
    solution coding the model of objects which make
    up the solution
  • realize the logical solution

8
Analysis 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

9
Analysis Activities
  • define essential use cases
  • refine use case diagrams
  • refine conceptual model
  • refine glossary
  • define system sequence diagrams
  • define operation contracts
  • define state diagrams

10
Analysis - approaches
  • Domain Analysis life cycle
  • Static, dynamic, and functional models
  • Application Analysis and User Requirements

11
OOA 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

12
Design Activities
  • define real use cases
  • define UI and storyboards
  • refine system architecture
  • define interaction diagrams
  • define logical class diagrams
  • define database schemas

13
Design (2)
  • Software architectures
  • Contracts
  • Class design guidelines
  • Error handling
  • Storage management

14
OOD 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

15
in 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.

16
Vision Scope Document
  • Business Requirements
  • Vision of the Solution
  • Scope and Limitations
  • Business Context

?
?
?
?
17
Requirements 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)

18
Business 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

19
Business 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

20
User 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

21
System 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.

22
Functional 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

23
Business 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.

24
Quality Attributes
  • Users
  • Availability
  • Efficiency
  • Flexibility
  • Integrity
  • Interoperability
  • Reliability
  • Robustness
  • Usability
  • Developers
  • Maintainability
  • Portability
  • Reusability
  • Testability

25
External 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.

26
Constraints
  • 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

27
Features 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!

28
What Requirements Are Not
  • Design or implementation details
  • Project planning information
  • Testing strategies or details
  • Other project requirements like
  • Development environment
  • Budget limitations
  • Training

29
Quality 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?

30
Eliciting 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

31
Eliciting Requirements
  • Interviews
  • Joint Application Design
  • Prototypes
  • Questionnaires
  • Observation
  • Sampling

32
Interviews
  • 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

33
Interviews (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

34
Joint Application Design
  • A better interviewing technique
  • Designed to shorten the requirements definition
    process
  • Get involvement, commitment, and hopefully
    ownership
  • Originally developed by IBM

35
Rapid 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

36
Prototypes (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

37
Prototypes (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

38
Rapid 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.

39
And 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

40
More 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

41
Use 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.

42
Use 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

43
Main 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

44
Alternate 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

45
Alternate Scenario (cont)
  • Usually considerably longer and more complex than
    happy path
  • Indicates all branching points and conditions not
    covered at Main Success Scenario

46
Exceptions
  • 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

47
Use 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

48
Fully 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

49
Identifying 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

50
Actors
  • 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

51
A 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

52
Use 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?

53
UML Use Cases
  • A simple diagram, like this

Use Case
Actor
54
UML 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

55
Example
University Enrolment System
Enroll In University
ltltincludegtgt
Enroll in Seminar
ltltextendgtgt
Enroll Family Member in University
Perform Security Check
56
Use Cases
  • Developers implement functional requirements, not
    use cases or business requirement
  • Uses cases omits lots of details details not
    concerned by end-users

57
Object 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

58
Conceptual 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

59
Definition
  • 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

60
Conceptual Model
  • It is a representation of real-world things, not
    of software components
  • It may show
  • Concepts
  • Association between concepts
  • Attributes of concepts

61
Concepts
  • 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

62
Concepts 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

63
Identifying 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

64
Identifying Concepts (cont)
  • Two strategies
  • Conceptual Category List
  • Noun Phrase List

65
Conceptual Category List
  • Create a conceptual model by making candidate
    concepts from a list
  • Contains many common categories that worth
    considering

66
Conceptual Category List (cont)
67
Conceptual Category List (cont)
68
Noun 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

69
UML Notation
  • In UML, conceptual model is illustrated via a set
    of static structure diagrams in which no
    operations are described

Concept
70
How 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

71
On 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

72
Concept 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

73
Specification 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

74
Definition
  • An association is a relationship between concepts
    that indicates some meaningful and interesting
    connection

Records-current
Register
Sale
1
1
75
Associations to Consider
  • Knowledge of the relationship needs to be
    preserved for some duration
  • Need-to-know associations
  • Associations derived from Common Associations List

76
High Priority Associations
  • A is physical or logical part of B
  • A is physically or logically contained in/on B
  • A is recorded in B

77
UML
  • 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.

78
UML 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.

79
UML diagrams
  • Use Cases
  • Conceptual Model concepts attributes
  • Association
  • Interaction Diagrams
  • Collaboration Diagram
  • Sequence Diagram
  • Logical Class Diagram
  • much more next lecture

80
OO 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

81
Plan and Elaborate
  • Plan and elaborate - includes the projects
    initial investigation and conception, planning,
    and the specification of requirements

82
Plan 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.

83
Rank 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.

84
Iterative 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.

85
Key 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.

86
Key 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.
Write a Comment
User Comments (0)
About PowerShow.com