OBJECT-ORIENTED MODELING AND DESIGN Process Overview

CONTENTS: 1. Development Stages. 2. Development Life Cycle. 3. Summary. A software Development process provides a asis for t!e organi"ed production of software# using a collection of predefined tec!ni$ues and notations. 1. Development Stages: The development stages can be summarized as follo s: % System Conception % Analysis % System design % Class design % &mplementation % 'esting % 'raining % Deployment % (aintenance S!stem Conception) Conceive an application and formulate tentative re$uirements. "nal!sis: % *nderstand t!e re$uirements y constructing models+focus on w!at+rat!er t!en !ow, % 'wo su stages of analysis) Domain analysis and application analysis. % Domain analysis focuses on real-world t!ings w!ose semantics t!e application captures. .g) Airplane flig!t is a real world o /ect t!at a flig!t reservation system must represent.
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S 1 of 8

2 % Domain ) 9enerally passive information captured in class diagrams % Domain analysis is t!en followed y application analysis. % Application analysis addresses t!e computer aspects of t!e application t!at are visi le to users. .g ) flig!t reservation screen is a part of 7lig!t 5eservation System. % Application O /ects are meaningful only in t!e conte:t of an application. % 3ot t!e implementation aspect ; lac0 o: view< S!stem Design: % Devise a !ig! level strategy-t!e arc!itecture. % 7ormulate an arc!itecture and c!oose glo al strategies and policies. % =ig! Level plan or strategy. % Depends on t!e present re$uirement and past e:periences. % '!e arc!itecture must also support future modifications to t!e application % 7or simple systems. arc!itecture follows analysis. % 7or large and comple: systems) t!ere is interplay etween t!e construction of a

model and t!e model>s arc!itecture and t!ey must e uilt toget!er Class design: % Augment and ad/ust t!e real-world models from analysis so t!at t!ey are amena le to implementation. % Developers c!oose algorit!ms to implement ma/or system functions. #mplementation: % 'ranslate t!e design into code and data ase structure. % Often tools can generate some of t!e code from t!e design model. Testing: % .nsure t!at t!e application is suita le for actual use and t!at it truly satisfies t!e re$uirements.
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S 2 of 8

3 % *nit tests discover local pro lems and often re$uire t!at e:tra instrumentation e uilt into t!e code. % System test e:ercise $ ma/or su system or t!e entire application. '!is can discover road failures to meet specifications. % ?ot! unit and system tests are necessary. % 'esting s!ould e planned from t!e eginning and many tests can e performed during implementation. Training: % =elp users master t!e new application. % Organi"ation must train users so t!at t!ey can fully enefit from an application. Deplo!ment: % Place t!e application in t!e field. % '!e eventual system must wor0 on various platforms and in various configurations. % Developers must tune t!e system under various loads and write scripts and install procedures. % Locali"e t!e product to different languages. $aintenance: % Preserve t!e long-term via ility of t!e application. % ?ugs t!at remain in t!e original system will gradually appear during use and must e fi:ed. % A successful application will also lead to en!ancement re$uests and long lived application will occasionally !ave to e restructured. % (odels ease maintenance and transition across staff c!anges. % A model e:presses t!e usiness intent for an application t!at !as een driven into t!e programming code# user interface and data ase structure
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S 3 of 8

@ %. Development &ife C!cle. ;a< 6aterfall Development % 5igid linear se$uence wit! no ac0trac0ing. % Suita le for well understood applications wit! predicta le outputs from

analysis and design# suc! systems seldom occur. % A waterfall approac! also does not deliver a useful system until completion. % '!is ma0es it difficult to assess progress and correct a pro/ect t!at !as gone awry. ; < &terative Development % (ore fle:i le. % '!ere are multiple iterations as t!e system evolves to final delivera le. % .ac! iteration includes a full complement of stages) analysis# design# &mplementation and testing. % '!is is t!e est c!oice for most applications ecause it gracefully responds to c!anges and minimi"es ris0 of failure. % (anagement and usiness users get early feed ac0 a out progress. '. Chapter Summar! % A software .ngineering Process provides a asis for t!e organi"ed production of software . % '!ere is a se$uence of well defined stages t!at can apply to eac! piece of a system. % Parallel development teams mig!t develop a data ase design# 0ey algorit!ms # and an user interface. % An iterative development of software is fle:i le and responsive to evolving re$uirements. 7irst you prepare a nucleus of a system# and t!en you successively grow its scope until you reali"e t!e final desired software.
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S @ of 8

A E(ercises 1. &t seems t!ere is enoug! time to do a /o rig!t t!e first time# ut t!ere is always time to do it over. Discuss !ow t!e approac! presented in t!is c!apter overcomes t!is tendency of !uman e!avior. 6!at 0inds of errors do you ma0e if you rus! into t!e implementation p!ase of a software pro/ect, Compare t!e effort re$uired to prevent errors wit! t!at needed to detect and correct t!em. "ns er: 6e !ave learned t!is lesson more times t!an we would care to admit. Carpenters !ave a similar ma:im) B(easure twice# cut once.C '!is e:ercise is intended to get t!e student to t!in0 a out t!e value of software engineering in general. '!ere is no single correct answer. &t is pro a ly too early in t!e oo0 for t!e student to answer in detail a out !ow software engineering will !elp. Loo0 for indications t!at t!e student appreciates t!e pitfalls of ypassing careful design. '!e effort needed to detect and correct errors in t!e implementation p!ase of a software system is an order of magnitude greater t!an t!at re$uired to prevent errors t!roug! careful design in t!e first place. (any programmers li0e to design as t!ey code# pro a ly ecause it gives t!em a sense of immediate progress. '!is leads to conceptual errors w!ic! are difficult to distinguis! from simple coding mista0es. 7or e:ample# it is easy to ma0e conceptual errors in algorit!ms t!at are designed as t!ey are coded. During testing# t!e algorit!m may produce values t!at are difficult to understand. Analysis of t!e symptoms often produces misleading conclusions. &t is difficult for t!e programmer to

recogni"e a conceptual error# ecause t!e focus is at a low level. '!e programmer Bcannot see t!e forest for t!e treesC. E(ercise on re)uirement capturing using use cases: %. Case Stud!: Online travel agent: *repare a use case diagram+ using the generalization and include relationships . Purc!ase a flig!t. 5eserve a flig!t and provide payment and address information. Provide payment &nformation) Provide a credit card to pay for t!e incurred c!arges. Provide address) provide mailing and residence address. Purc!ase car rentals) 5eserve a rental car and provide payment and address information. Purc!ase a !otel stay) reserve a !otel room and provide payment and address info. (a0e a purc!ase) (a0e a travel purc!ase and provide payment and address information.
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S A of 8

8
www. oo0spar.com 1 2'* 3O'.S 1 4*.S'&O3 PAP.5S 1 3.6S 1 5.S*L'S 1 7O5*(S