 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

 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

 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

 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.

 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 .

 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.

Analysis investigation of the problem
Design logical solution
Construction code
Book
(concept)
Domain concept
Book title print()
} public class Book { public void print(); private String title;
Representation in analysis of concepts
Representation in an object-oriented programming language.

 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.

Define
Use
Cases
Define
Domain
Model
Define
Interaction
Diagrams
Define
Design Class
Diagrams

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

 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.

 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.

Player
1
1
1
Dice Game plays
1 rolls
2
Die
2 includes
What about Yahtzee?

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

:DiceGame :Die1 :Die2 play() roll() fv1 = getFaceValue() roll() fv2 = getFaceValue()

 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

Dice Game die1 : Die die2 : Die play()
1 2
Die faceValue : int getFaceValue() : int roll()

 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

 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.

 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.

 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.

 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.

 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.

Iteration 1 Iteration 2
Requirements
Design
Requirements
Design
Implementation Implementation
& Test & More & Test & More
Design Design
The system grows incrementally eg, about 4 weeks

 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.

[iteration N]
Requirements – Analysis - Design- Implementation - Testing
[iteration N+1]
Requirements – Analysis - Design- Implementation - Testing
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration
N+1.
The system grows incrementally.

 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.

 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

 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?


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 allround 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.

 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

 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.

 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.

 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

 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

 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)

 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

 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.

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

 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