CSC%20520%20Advanced%20Object-Oriented%20Analysis%20and%20Design

1
CSC 520Advanced Object-Oriented Analysis and
Design
2
Applying UML and Patterns

• UML is a standard diagrammatic notation
• UML Tools of interest, but not critical
• Possibly the most critical skill is proper
  assignment of responsibilities to components
• Patterns well known, best-practice solutions to
  common problems

3
Prerequisite Activity

• Requirements Analysis
• Use Cases
• Unified Process - UP an iterative development
  process
• Use
• apply principles and patterns to create better
  object designs
• Follow a set of common activities in analysis and
  design based on the UP
• Create frequently used diagrams in the UML
  notation

4
Other Skills Needed

• Usability engineering
• User Interface Design
• Database Design
• Most critical skills
• Assignment of responsibilities to classes of
  objects
• How should objects interact?
• Answers strongly influence the robustness,
  maintainability, and reusability of the
  components
• Emphasis
• principles of responsibility assignment

5
Object-Oriented A and D

• Object-oriented analysis
• emphasizes the finding and describing the objects
  in the problem domain.
• Object-oriented design
• emphasizes the definition of software objects and
  how they collaborate to fulfill the requirements.
• Object-oriented programming
• the design objects are implemented.

6
Object-Oriented Analysis

• An investigation of the problem (rather than how
  a solution is defined)
• During OO analysis, there is an emphasis on
  finding and describing the objects (or concepts)
  in the problem domain.
• For example, concepts in a Library Information
  System include Book, and Library.

7
Object-Oriented Design

• Emphasizes a conceptual solution that fulfils he
  requirements.
• Need to define software objects and how they
  collaborate to fulfil the requirements.
• For example, in the Library Information System, a
  Book software object may have a title attribute
  and a getChapter method.
• Designs are implemented in a programming
  language.
• In the example, we will have a Book class in
  Java.

8
From Design to Implementation?
Analysis investigation of the problem
Design logical solution
Construction code
public class Book public void print() private
String title
Book
Book (concept)
title print()
Representation in an object-oriented programming
language.
Domain concept
Representation in analysis of concepts
9
Analysis and Design

• Analysis emphasizes an investigation of the
  problem and its requirements, not the solution.
• In this context, it is best described as object
  analysis, an investigation of the domain objects
• Design emphasizes a conceptual solution that
  fulfills the requirements, not the
  implementation.
• In this context, it is best described as object
  design.

10
The Unified Process
Define Use Cases
Define Domain Model
Define Interaction Diagrams
Define Design Class Diagrams
11
Use Cases

• Use cases are not object oriented components
• Very popular and extraordinary useful in
  describing the requirements
• An important part of the unified process (UP)

12
An ExampleThe Dice Game

• A Use Case
• A player picks up and rolls the dice. If the
  dice face value total seven, the player wins
  otherwise, the player loses.

13
Domain Model

• a decomposition of the domain model involves an
  identification of its
• concepts
• attributes
• associations
• This decomposition is shown in a domain model
• not software objects
• a visualization of the real-world domain.

14
Domain Model
Player
rolls
1
Die
1
2
2
plays
1
1
Dice Game
includes
What about Yahtzee?
15
Interaction Diagrams

• objects interact and collaborate with one
  another.
• Interaction diagrams capture this interaction and
  show the flow of messages from object to
  object.

16
Interaction Diagrams
DiceGame
Die1
Die2
play()
roll()
fv1 getFaceValue()
roll()
fv2 getFaceValue()
17
Class Diagrams

• Interaction diagrams capture the dynamic view
• Class diagrams capture the static relationship
  between classes.
• It illustrates the attributes and methods of a
  class and the classes relationship to other
  classes

18
Class Diagrams
Dice Game die1 Die die2 Die play()
Die faceValue int getFaceValue() int roll()
1
2
19
Iterative Development and the Unified Process

• Waterfall approach vs the iterative approach
• Sometimes called incremental development
• UP combines commonly accepted best practices and
  activities into a cohesive and well-documented
  description
• The most important UP idea is iterative
  development

20
Waterfall Approach

• Assumes that it's possible to capture all
  requirements and complete analysis before design
  starts
• divided into several consecutive phases
• Product Specification
• High Level Design
• Low Level Design
• Coding
• Testing
• Introduction
• To enter a new phase is only allowed, if the
  final checkpoint of the previous phase has been
  passed successfully.

21
Waterfall Approach

• basis of design was to minimize the use of very
  expensive computing resources.
• A vestige of the time in which it was developed,
  where computer time was most precious
• development time is now the most expensive part
  of a project budget.

22
Waterfall Approach
23
Iterative Approach

• The advent of new object oriented programming
  languages like Smalltalk and Java caused many s/w
  developers to discard the waterfall approach in
  favor of an iterative approach
• often called "spiral" or "fountain".
• normally starts with a first draft of a program.
• This draft (sometimes called a prototype) is then
  discussed and refined in various iterations until
  it is commonly accepted.

24
Iterative Approach

• advocates claim it will generate results which
  are better accepted by the potential end users.
• Because these potential end users get an
  impression relatively early about the look and
  feel of the new product by playing around with
  the early "prototypes".
• Potential end users can influence the product
  very directly from early development.
• Experience shows that projects not performed
  under the stringent rules of the waterfall model
  tend to exceed established schedules
  significantly.
• Conflict exists between "time to market" and
  product acceptance.

25
Iterative Approach
26
Iterative Development

• Development is organized into a series of short
  fixed-length mini-projects called iterations.
• The outcome of each iteration is a tested,
  integrated and executable system.
• An iteration represents a complete development
  cycle it includes its own treatment of
  requirements, analysis, design, implementation
  and testing activities.

27
Iterative and IncrementalDevelopment
Iteration 1
Iteration 2
Requirements Design Implementation Test
More Design
Requirements Design Implementation Test
More Design
The system grows incrementally
eg, about 4 weeks
28
Iterative Development

• The iterative lifecycle is based on the
  successive enlargement and refinement of a system
  though multiple iterations with feedback and
  adaptation.
• The system grows incrementally over time,
  iteration by iteration.
• The system may not be eligible for production
  deployment until after many iterations.

29
Iterative Development
iteration N Requirements Analysis - Design-
Implementation - Testing
iteration N1 Requirements Analysis - Design-
Implementation - Testing
Feedback from iteration N leads to refinement and
adaptation of the requirements and design in
iteration N1.
The system grows incrementally.
30
Iterative Development

• The output of an iteration is not an experimental
  prototype but a production subset of the final
  system.
• Each iteration tackles new requirements and
  incrementally extends the system.
• An iteration may occasionally revisit existing
  software and improve it.

31
Benefits

• early, rather than late, mitigation of high risks
• (technical, requirements, objectives, usability,
  etc.)
• early visible progress
• early feedback, user engagement, and adaptation
  leading to a refined system that meets the real
  needs of the users.
• managed complexity
• learning within an iteration can be used to
  improve the development process

32
Time-boxing Iterations

• A specific time frame for an iteration
• If it will (may?) not be met, drop some tasks or
  requirements from the iteration
• recommended time is 2 to 6 weeks.
• Problem Can time frame be realistically be
  accommodated?

33
Which Approach?

• At least for larger development projects the
  following arguments and statements will hold
• To achieve good results in a reasonable time
  frame, an evolutionary development approach
  normally needs highly skilled all-round
  developers
• Problem Easier said than found 
• A staged development with well defined
  intermediate results based on the envisaged
  functionality providing the basis for the future
  work allows to use specialists to generate these
  intermediate results.
• Good specialists for development stages like
  "Business Analysis", "Business Design",
  "Technical High and Low Level Application
  Design", or "Coding and Testing" are not so rare
  as really good all-round developers.
• the intermediate results (e.g. in the form of
  business models which are by themselves valuable
  deliverables) may be conserved and updated
  independently for future usage. 

34
Which Approach?

• True Statements (continued)
• Staged development cannot react to requirement
  changes affecting product acceptance during
  product introduction as quickly as an
  evolutionary approach.
• A trade-off between "time to market", "product
  appearance", and "product functionality" may have
  to be made according to the envisaged lifetime of
  the product.
• A purely evolutionary development approach tends
  to lengthen the development time and increase
  development costs because of uncontrolled and
  permanent changes.
• may create a lot of required adaptations even in
  parts which seem to have been finished. Risk
  increases, for customer to get impatient,
  forcing release of an early version of the
  product (comprising very likely a lot of
  compromises) or even cancellation 

35
Which Approach?

• True Statements (continued)
• A smart combination of a staged development
  supported by an ingenious waterfall approach and
  disciplined evolutionary development can result
  in a reasonable "time to market" and an
  acceptable "quality" (functionality, user
  friendliness, efficiency) as well as a good long
  term "profitability" of the product, because the
  maintenance costs promise to be low, the lifetime
  of the program tends to be long, and at least
  intermediate results like business analysis and
  business design may be reused for successor
  projects.

36
Advantages of Hybrid Approach

• There are a few important milestones which allow
  the management to decide about a go or no-go of
  the development.  
• For each development phase the adequate
  specialists can be hired, contributing
  significantly to the overall quality of the
  envisaged product.
• It is much more likely that an established
  schedule is met, because there is no (or only a
  short) learning phase for these specialists and
  due to that only a small number of unproductive
  iteration cycles.
• It can be decided individually and independently
  for each phase how it's development progress
  should be controlled.
• For tasks dealing mainly with problem analysis,
  product design, and product specification an
  iterative approach can be selected. For coding
  and testing as well as for information
  development a staged approach with adequate
  checkpoints can be used, hence validating the
  hybrid approach.

37
More Best Practices

• consider high risk, high value issues early
• continuously engage users for feedback
• build a cohesive, core architecture early
• test early, often, and realistically
• test against the use cases
• Use a UML tool
• carefully manage requirements

38
The Unified Process(UP) Phases

• Inception
• approximate vision, scope, vague estimates,
  business case a feasibility phase
• Elaboration
• refined vision, iterative implementation,
  resolution of high risks, identification of most
  requirements and scope, more realistic estimates
  not the requirements phase
• Construction
• iterative implementation of lower risk elements
  and preparation for deployment
• Transition
• beta tests and deployment

39
UP Disciplines

• A discipline is a set of activities and related
  artifacts in one subject such as requirements
  analysis.
• An artifact is the general term used for
  something produced by that discipline such as use
  cases.
• Software artifact Any piece of software (i.e.
  models/descriptions) developed and used during
  software development and maintenance. Examples
  are requirements specifications, architecture and
  design models, source and executable code
  (programs), configuration directives, test data,
  test scripts, process models, project plans,
  various documentation etc. etc.
• Work goes on in almost all disciplines during an
  iteration. (See fig. 2.4)

40
Development Case

• Artifacts are optional
• what is produced at each phase and each iteration
  is project dependent
• pick the ones that most address the needs of the
  project
• Write a development case
• a chart that describes which artifacts will be
  used

41
Case StudyFreds PRC

• Prescription Refill Center PRC
• See Use Cases and Scenarios for the PRC
• In any application, consider
• User Interfaces
• Application logic and domain objects
• Technical Services Databases, error logging,
  etc. - things that are application independent.

42
Inception

• What is the business case for the project?
• Is it Feasible?
• Buy and/or build
• Rough estimate of cost?
• Proceed or stop?

43
Artifacts of Inception

• Business Case a description of the high level
  goals
• Use-Case Model
• Supplementary Specifications
• Risk list and management
• Prototype(?)
• Iteration Plan
• Phase plan software development plan
• Development Case