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.