CSC 520 Advanced ObjectOriented Analysis and Design Applying

CSC 520 Advanced Object-Oriented Analysis and Design

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

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

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

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

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

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

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

Analysis and Design v Analysis emphasizes an investigation of the problem and its requirements, not the solution. q v 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. q In this context, it is best described as object design.

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

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

An Example: The Dice Game v 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.

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

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

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

Interaction Diagrams : Dice. Game : Die 1 play() roll() fv 1 = get. Face. Value() roll() fv 2 = get. Face. Value() : Die 2

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

Class Diagrams Dice Game die 1 : Die 1 2 face. Value : int die 2 : Die get. Face. Value() : int play() roll()

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

Waterfall Approach v Assumes that it's possible to capture all requirements and complete analysis before design starts q divided into several consecutive phases: l l l q 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.

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

Waterfall Approach

Iterative Approach v 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". q normally starts with a first draft of a program. q l This draft (sometimes called a prototype) is then discussed and refined in various iterations until it is commonly accepted.

Iterative Approach v 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". q Potential end users can influence the product very directly from early development. q v Experience shows that projects not performed under the stringent rules of the waterfall model tend to exceed established schedules significantly. q Conflict exists between "time to market" and product acceptance.

Iterative Approach

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

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

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

Iterative Development [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.

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

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

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

Which Approach? v At least for larger development projects the following arguments and statements will hold: q To achieve good results in a reasonable time frame, an evolutionary development approach normally needs highly skilled all-round developers l q 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. l 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.

Which Approach? v True Statements (continued): q Staged development cannot react to requirement changes affecting product acceptance during product introduction as quickly as an evolutionary approach. l q 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. l 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

Which Approach? v True Statements (continued): q 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.

Advantages of Hybrid Approach v v There 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. q v 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. q 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.

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

The Unified Process(UP) Phases v Inception – q v Elaboration – q v refined vision, iterative implementation, resolution of high risks, identification of most requirements and scope, more realistic estimates – not the requirements phase Construction – q v approximate vision, scope, vague estimates, business case – a feasibility phase iterative implementation of lower risk elements and preparation for deployment Transition – q beta tests and deployment

UP Disciplines v v 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. q v 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. Work goes on in almost all disciplines during an iteration. (See fig. 2. 4)

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

Case Study Fred’s PRC v Prescription Refill Center – PRC v See Use Cases and Scenarios for the PRC v In any application, consider q User Interfaces q Application logic and domain objects q Technical Services – Databases, error logging, etc. - things that are application independent.

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

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