- 10 process Overview Asoftware development ‘process provides a basis for the organized production of software, using a collection of predefined techniques and notations. The process in this book starts with formulation of the problem, then continues through analysis, design, and implementa- tion, The presentation of the stages is linear, but the actual process is seldom linear. 10.1 Development Stages Software development has a sequence of well-defined stages, each with a distinct purpose, input, and output, i System conception. Conceive an application and formulate tentative requirements. 1 Analysis, Deeply understand the requirements by constructing models. The goal of analysis is to specify what needs to be done, not how it is done. You must understand a problem before attempting a solution. System design. Devise a high-level strategy—the architecture—for solving the appli- cation problem. Establish policies to guide the subsequent class design. W Class design. Augment and adjust the real-world models from analysis so that they are amenable to computer implementation. Determine algorithms for realizing the operations. Implementation. Translate the design into programming code and database structures. M Testing. Ensure that the application is suitable for actual use and that it truly satisfies the requirements. M Training. Help users master the new application. ¥ Deployment, Place the application in the field and gracefully cut over from legacy ap- plications. © Maintenance. Preserve the long-term viability of the application, 167 @ scanned with OKEN ScannerChapter 10/ Process Overyg, invally elaborate and optimize models as your focys : yess. You continua ly wn, Throughout development the same con, rocess i eran to implementa” in perspective from the inital em, sift fo mi only difference computer resources. cepts i Se needs tothe te development effort up to analysis and de. re (00 approach moves on to spend more time during analysis and design, but ths . Itis sometimes disconcerO ster and simpler implementation. Because ther. more than compen table, future changes are much easier. \day . . clean ae es and Pat 3 covers implementation. In this book we em. the first fow" IOP ny consider testing, training, deployment, and mainte. bri I Soe important, but are not the focus of this book. sigi extra effort ism sulting design is Part 2 covers phasize development an nance. These last four top! tem Conception ; oe deals with the genesis of an application. Initially somebody thinks of an icati i idea to the organization. The i ication, prepares a business case, and sells the. idea to 01 eae understand both business needs and technological capabilities. 10.1.2 Analysis Analysis focuses on creation of models. Analysts capture and scrutinize requirements by constructing models. They specify what must be done, not how it should be done. Analysis is a difficult task in its own right, and developers must fully understand the problem before addressing the additional complexities of design. Sound models are a prerequisite for an ex- tensible, efficient, reliable, and correct application. No amount of implementation patches can repair an incoherent application and compensate for a lack of forethought. During analysis, developers consider the available sources of information (documents, business interviews, related applications) and resolve ambiguities, Often business experts are Not sure of the precise requirements and must refine them in tandem with software develop- ment. Modeling quickens the convergence between developers and business experts, because itis much faster to work with multiple iterations of models than with multiple implementa- tions of code, Models highlight omissions and inconsistencies so that they can be resolved. As developers elaborate and refine a model, it gradually becomes coherent, There are two substages of analysis: domain analysis and application analysis, Domain analysis focuses on real-world things whose semantics the application captures, For exam- ple, an airplane flight is a real-world object that a flight reservation system must represent. Domain objects exist independently of any application and are meaningful to business ex- pers. You find them during domain analysis or by prior knowledge, Domain objects carry information about real-world objects and are generally passive—domain analysis emphasiz- es concepts and relationships, wth much of the functionality being implicit ith ee iiade el. The job of constructing a domain model is mainly to decide which inf ae and how to represent it. jermalon [Link] Domain analysis is then followed by application anal aspects ofthe application that are visible o users. For on iets that addresses the computer ‘ample, a flight reservation screen iS @ scanned with OKEN Scannerjo Development Stages meaningful only in th ‘ god ae meaninght dain "is cmteat ofan slide exist in the problem domain ons, because the oer PPiction objects, however, are recribe the implemen hid A must agree with them. th . 2 Ie Outside; n of the application. It describes pizton classes with domain analysis, by yoy ce 8eE-PX View oft. You canot Find ap- fjons. Otherwise, YOu must devise app Can often reuse them from previous applica- 1 ication obj . jaterfaces with other systems and how y Objects during analysis as you think about ‘Our application interacts with users. 10.1.3 System Design During system design, the developer makes ‘ vou must formulate an archi Strategic decisions with Wesequent, more detailed orton a ig: he slobal ste ‘and polio gue the ; : ma - The architecture is the high-| - a ene a pti i The choice of chica fapeclee a eee a ton that can be tested. The vine aan the architecture should include an executable 2 z ler Must understand how a new s; interacts with other systems. The architecture must also support future modification of the ‘pplic. we ion. For straightforward problems, preparation of the architecture follows analysis. Howev- er for large and complex problems'their preparation must be interleaved. The architecture helps to establish a model’s scope. In turn, modeling reveals important issues of strategy to resolve. For large and complex problems, there is much interplay between the construction of amodel and the model’s architecture, and they must be built together. 10.1.4 Class Design During class design, the developer expands and optimizes analysis models; there is a shift in emphasis from application concepts toward computer concepts. Developers choose algo- rithms to implement major system functions, but they should continue to defer the idiosyn- crasies of particular programming languages. 10.1.5 Implementation Implementation is the stage for writing the actual code. programming language and database code. Often, tools can generate some the design model. Developers map design elements to of the code from 10. ; ; 0.1.6 Testing put it must be carefully tested before being After implementation, the system is complete, be I is i eed the original project should have been commissioned for actual use. The ideas that inspired the orig! ements Nurtured through the previous stages bye ole poet urna Test- inal business requirements and verify that Ne 8 can als NV ve introduced. If an application ; 30 accidental errors (bugs) that have been introd ppl incover i be tested on all of them, i ratforms, it should "uns on multiple hardware and operating system Pl @ scanned with OKEN ScannerChapter 10/ Process o,, My 170 ral levels. Unit tests exercise smay, sssibly we cabs Unit tests discover local Probie of code, such as methods or Pettit be built into the code. System tests exercise = often require that extra neni. In contrast to unit tests, system tests can Aiscove ; a subsystem or the eatire Ge Both unit and system tests are necessary. Testing shout ‘ fies to meet specie coded. It must be planned from the beginning, any . pes a be pecfoned ding implementation. 10.1.7 Training from an application, Tyaj,: ‘organ mst ain wes oat they can filly Benefit fom an application Tg i te team should prepare user the software learning curve. A separa Feaon nparllel i the development effort. Quality control can then Check the sof Spat to wer documentation to ensure that the software meets its original goals, Developers should check a program 10.1.8 Deployment 2 gat ‘The eventual system must work in the field, on various platforms and in various configura. tions. Unexpected interactions can occur when a system is deployed in customer environ. ment. Developers must tune the system under various loads and write scripts and instal] procedures. Some customers will require software customizations. Staff must also localize the product to different spoken languages and locales. The result is a usable product release 10.1.9 Maintenance Once development is complete and a system has been deployed, it must be maintained forcon tinued success. There are several kinds of maintenance. Bugs that remain in the original sytem will gradually appear during use and must be fixed. A successful application will also lead enhancement requests and a long-lived application will occasionally have to be restructure. Models ease maintenance and transitions across staff changes. A model expresses the business intent for an application that has been driven jnto the programming code, user in- terface, and database structure, 10.2 Development Life Cycle An 00 approach to software development supports multiple life-cycle styles. You can use® Waterfall approach performing the phases of analysis, design, ang implementation in strict seuignce forthe entire system. However, we typically secommend an rernn ne Jopment Strategy. We summarize the distinction here and elaborate in Chapter 21 aaa 10.2.1 Waterfall Development ‘The waterfall approach dictates that developers perf i je wate c form the soft ae . Seed eee ceases no backtracking. Developers first oem setemea ‘ysis model, then perform a system, design, then prepare a clase design, fol- me @ scanned with OKEN Scanner03 chapter Summary 4 1 sat 171 by implementation, testing, a sowed BY Trext stage is begun, ©” °° ployment, Ba ‘The waterfall approach is suitable for from analysis and design, by Well-understood applicati 4 cutptts » but such appticat; applications with predictable , »mpt to follow a waterf 'pPlications i: asa developers complain eens are a Te i alenble Software development ES ehiements, and te busines complains soo! Nuntilcompletion, This makes ntl approach a Pome nee yee + inte makes it dificult to assess mre eset deliver a useful pas gone awry. Progress and correct a project that Stage is completed in its entirety 10.22 Iterative Development nratve development is more flexible, First ing, designing, implementing, and delivering system, adding Lats and behavior to objets. There are multiple iterations as the system evolves to the final deliverable. Each iteration includes a full complement of stages: analysis, design, implementation, aniteting. Unlike the strict sequence ofthe waterfall method, iterative development can in, teleave the different stages and need not construct the entire system in lock step. Some parts may be completed early, while other, less crucial parts are completed later. Each iteration ul- tintately yields an executable system that can be integrated and tested. You can accurately gauge progress and make adjustments to your plans based on feedback from the early itera- tions. If there is a problem, you can move backward to an earlier stage for rework. erative development is the best choice for most applications because it gracefully re- sponds to change and minimizes risk of failure. Management and business users get early feedback about progress. You develop the nucleus of a system—analy2- Working code, Then you grow the scope of the Cxisting objects, as well as adding new kinds of 10.3 Chapter Summary A software engineering process provides a basis for the organized production of software. There is a sequence of well-defined stages that you can apply to each of the pieces of a sys- (em, For example, parallel development teams might develop a database design, key algo- ‘ths, and a user interfiice. An iterative development of software is flexible and responsive toevolving requirements. First you prepare anucleus of a system, and then you successively OW its scope until you realize the final desired software. analysis domain analysis syste conception application analysis implementation osen lesig architecture iterative development en mainte deployment Figure 10.1 Key concepts for Chapter 10 i . @ scanned with OKEN Scannerr tt jl system Conception Sy abs ea = fae genesis of am pplication, Initially some person, who un- eds and technology, thinks of an idea f ication. ers must then explore the idea to understand the needs and Pear puose of systent conception is to defer details and understand the big picture—what need does the proposed system ‘meet, can it be developed at a reasonabl i for the result justify the cost of building it? bible ean Wl eee This chapter introduces the automated teller machine (ATM) case study that threads throughout the remainder of the book. 11.1 Devising a System Concept sisting ideas. For example, a human relations benefit choices and require that a clerk enter es to view and enter their own changes. and so on), but the new idea Mostideas for new systems are extensions of © department may have a database of employee changes. An obvious extension is to allow employes There are many issues to resolve (security, reliability, privacy, isa straightforward extension of an existing concept. : Occasionally a new system is a radical departure from the past. For example, an online auction automates the ancient idea of buyers bidding against each other for products, but the first online auction systems were brand new software. The concept became feasible when widespread personal computer several enabling technologies came into place: the Internet, ; f access, and velnble rie ‘The large customer base ‘and low unit cost due,to automation changed the nature of avetions—an online ucla sell inexpensive items and sil make profit. In addition, online systems have made the auction process concurrent and distribut- a , system concepts. Here are some ways,to find new 8 Be ality (0. an existin: i stem. New functionality. Addsfunction B sy 173 @ scanned with OKEN Scanner| ee Chapter 1 /Sy6m Cong, 174 : t Streamlining. Remove restrictions or generalize the way a system works, Simplification, Let ordinary persons perform tasks previously assigned to Speci, aly, Automation. Automate manual processes. Integration. Combine functionality from different systems, Analogies. Look for analogies in other problem domains and see if they have Useful jes ‘Travel to other countries and observe their cultural and business Practc. es. 11.2 Elaborating a Concept Most systems start as vague ideas that need more substance. A good system concept mus, answer the following questions. Whois the application for? You should clearly understand which persons and organi. zations are stakeholders ofthe new system, Two of the most important kinds Of stake. holders are the financial sponsors and the end users, ‘The financial sponsor are important because they are paying for the new system, They expect the project to be on schedule and within budget. You should get the finan. cial sponsors fo agree to some measure of success. You need to know when the system is complete and meets their expectations, The users are also stakeholders, but in another sense, The users will ultimately de- termine the success of the new system by an increase (or decrease) in their productivity in your project so that you can obtain their buy-in. If you cannot get their buy-in, you should question the need for the project and reconsider doing it, = What problems will it solve? You must Clearly bound the size of the effort and estab- lish its scope. You should determine which features will be in the new system and which will not. You must reach various kinds of users in different organizations with their own viewpoints and political motivations, You must not only decide which features are ap- Propriate, but you must also obtain the agreement of influential persons, Where will it be used? At this early stage, itis helpful to get a general idea of where the new system might be used. You should determine if; the new system is mission-crit- ical software for the organization, experimental software, or a new capability that you u should have a rough idea about how Stems. Itis important to know if the soft- @ scanned with OKEN ScannerUBRARY ATME ,y2_exboratng @ Concept MYSORE 175 nisitneeded? Two aspects of time are; fine inch te system ean be develope nota Theft the fable ime the ources. The other is the required time, wher in the constraints of cost and available s. You must make sure thatthe timing ecm tem is needed to meet business gre consistent with the timing the businegs reno dtven by technical feasibility initiate a dialogue between technologists ani Ault. theresa disconect, you must is it needed? You may ness experts to reach a solution. we not already done 4. Toe ets ‘business case forthe new system if some- on system. including theo es CE cons the nancial jusieaton fr ees. You MUst be sure thet gee neiole benefits, intangible benefits, isk, and alle- ee rie bualiess caseill a You clearly understand the motivation for the new sys- ce respcope, aod ray eye? YOU insight ito what stakeholders expect, roughly in- s reasonable selling price; the revenue Imo cover coma be sold and determine 1 How will it work? You should brainstorm about the feasibility of th Forl gystems you should consider the merits of diferent architecanes he pps of is speculation is not to choose a solution, but to increase confid . ‘ lence that the problem can be solved reasonably. You might need some prototyping and experi se a 11.2.1 The ATM Case Study Figue 11.1 lists our original system concept for an Automated ‘Teller Machine (ATM). We ask high-level questions to elaborate the initial concept, Develop software so that customers can access a bank's computers and carry out their own financial transactions without the mediation of a bank employee. Figure 11.1 System concept for an automated teller machine mber of companies provide ATM products, Conse~ Who is the application for? A nut aoa cial company could possibly justify the cost and quently, only a vendor or a large finan effort of building ATM software. : : ‘A vendor would be competing for customers in an established market, A large ven dor could certainly enter such a market, but might find it advantageous to partner with or acquire an existing supplier. A small vendor would need some special feature to dif- ferentiate itself from the crowd and attract attention, : re Itis unlikely that a financial company could justify developing ATM software just it i re expensive than purchasing a product. el conpany waned yal asl the sponsoring company, and then market ito others. @ scanned with OKEN ScannerChapter 11 / System Cong gy 176 n For the ATM case study, we will assume that we are a vendor building the So! i ir i ig tee ‘We will assume that we ee en rca procs nee deep Complexitie 7 the ATM problem domain are beyond the scope of this book. will it solve? The ATM software is intended to serve both the bank . qecmonee Fe the bank, ATM software increases automation and reduces mana handling of routine paperwork. For the Customer, the ATM is ubiquitous and always available, handling routine transactions whenever and wherever the customer desir, ATM software must be easy to use and convenient so that customers will use it in Pref, erence to bank tellers. It must be reliable and Secure since it will be handling Money, Where will it be used? ATM software has become essential to financial institution, Customers take it for granted that a bank will have an ATM machine. ATM. Machine, are available at many stores, Sporting events, and other locations throughout the World @ = Whenis it needed? Any software development effort is a financial proposition, Thein. ‘estment in development ultimately leads to a revenue stream, From an economic per. Spective, itis desirable to minimize the investment, maximize the Tevenue, and realize Hevenve 2 soon as possible. Thoughtful modeling and OO techniques are conducive ig this goal. Why is it needed? There are many reasons why a vendor might decide to build a sop. Ware Product. If other companies are making money with similar Produc How will it work? We will adopt a three-tier architecture to separate the user interface {fom programming logic, and programming logic from the database. In reality, the ar chitecture is n-ter, because there can be any number of intermediate programming lev. cls communicating with each othet. We will discuse architecture further in the System Design chapter, 11.3 Preparing a Problem Statement Once you have fleshed out the raw idea by answering the high-level questions, you are ready to write a requirements statement that. Outlines the goals and Seneral approach of the desired system, @ scanned with OKEN Scannerpreparing & Problem Statemeny 9 77 ads of brake pads are on the wh, “a nds ming code. els. Implementation deals with th jn 0 Oy customers mix tre requ With the ultimate realiza- . rements wi separate requireme With desi dn ee eee nicaly there ee eo Se8ign decisinns elon Usually this isa bad id goa dosiet 'y there are many 1Ons, you preserve the freedom to pane ‘i Possible we : ig solution until you fully understand a problen 2° designa system, and you should ox isa det ble cost. Its a “proof of existence” enentation could be done differently j im! iy proposed as a possibility. for example, when the Apollo program to put a man ; athe plan was to place a rocket man on the moon in the 1960s was first ono cet in earth orbit, th we on's surface In the inal sucessful it, then launch a Janding vehicle directly ott vb, from which the land Program, the rocket was launched directly into lunar Bae aial: ho ler was launched to the moon’s surface. It was not a bad thing the ‘n ape 5 dilate Bave confidence that there was a feasible approach. ‘As Figure 11.2 shows, the problemi statement should state what is to be done and not powitis to be implemented. It should be a statement of needs, not a proposal for a system ctitectre. The requestor should avoid describing system internals, as this restricts devel- opment flexibility. Performance specifications and protocols for interaction with external stems are legitimate requirements. ‘Software engincering standards, such as modular con- ttustion, design for testability, and provision for future extensions, ae also proper. statement, However, the nal go eater thatthe sample ‘The sample implementation is Requirements Design Implementation Statement @ General approach 1 Platiorms Problem scope Algorithms mw Hardware specs 1m What is needed m Data structures w Software libraries Application context m Architecture W Interface standards Assumptions 1 Optimizations Performance needs Capacity planning ents, Do not make early’ design and implementation by .2. Kinds of requirem Ce eae 1] compromise development. decisions or you wil ss detail, A requirement for a conventional stem, may have considerable detail, A re- but presumably the research A problem statement may have more oF Tes ‘am or a billing sy’ Product, such as a payroll progr: i Guirement for a research effort in a new area may lack details, hes some objective that should be clearly statet pee _ Most problem statements are ambiguous, pments, although precisely stated, have un- Gtirements are just plain wrong. Some requiremen” ble implementation For of impose unreasonal Aleasant consequences on the syste re a as the requestor thought. The problem jor) s, Some requirements do not W' ‘or even inconsistent. Some re~ @ scanned with OKEN ScanneraN 178 Chapter / System Concenig, statement is just a starting point for understanding the problem, not an immutable docume, The purpose of the subsequent analysis (next chapter) i to fully understand the problem er a its implications. There is no reason to expect that a problem statement prepared without 7 full analysis will be correct. 11.3.1 The ATM Case Study Figure 11.3 shows a problem statement for an automated teller machine (ATM) network, Cashier Station am™ Account Bank ~~! Computer ~[hecount ATM Central )—~—~] Computer . Account, bank bo mputer| —~ account ATM Figure 11.3 ATM network. The ATM case. study threads throughout the remainder of this book. Design the software to support a computerized banking network including both human cash- iers and automatic teller machines (ATMs) to be shared by a consortium of banks, Each bank - provides its’own computer to maintain its own accounts and process transactions against them. Cashier stations are owned by individual banks and communicate directly with their ‘own bank's computers. Human cashiers enter account and transaction data, Automatic teller machines conimunicate with a central computer that clears transac- ions with the appropriate banks, An automatic teller machine accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts. The system requires appropriate recordkeeping and security provi- sions, The system must handle concurrent accesses to the same account correctly, The banks will provide their own software for their own computers; you are to design the sofiware for the ATMs and the network. The cost of the shared system will be appor- tioned to the banks according to the number of customers with cash cards, 11.4 Chapter Summary ‘The first stage of a project is to devise a new idea. The idea can involve a new system or an improvement to an existing system. Before investing time and Money into development, itis @ scanned with OKEN Scannerso ry to evaluate the feasibility of es e005 for the system, and the Cast bene sy difiaty and risk of developing it th i sk of developing it, the gett f all the stakeholders of 0, of the system This process should consider the view- ats pois” od chance Of success, not juge ond Should » Not just techni make the trade-offs necessary to pro- vide? i ts i fi casually tesults in some adjusime ts nts » but al i i ;scomplete, Write a problem stateme, italia Whentesyemeonepon sage” statement need not be com tha serves asthe stating pein feranaa The ‘Starting point for analysis. The jem he + ooo ofthe statement, Piel, and it wil mang oF helps to focus the atentign er anee during development, but the 179 tothe or; ‘on of the project. business case cost-benefit trade-off Problem statement design decision ac implementation constraint ape system conception Figure 11.4 Key concepts for Chapter 11 Exercises 111 @) Consider anew antilock braking system for crash avoidance in an automobile. Elaborate the following high-level questions and explain your answers. a, Who is the application for? Who are the stakeholders? Estimate how many persons ‘in your country are potential customers. bs Identify three features that should be included and three features that should be omitted , Identify three systems with which it must work. 4. What are two of the largest risks? 112. @)Repeat Exercise 11.1 for software that supports Intemet sling of books: 113 (3) Repeat Exercise 11.1 for software that supports the remodeling of kitchens. for an online auction system. 114 (3) Repeat Exercise 11.1 tem, for each of the following {1s tement, similar to that for the ATM system, fr each of eee ay in he scope of the syste, ut be precise and avoid making implementa- tion decisions. Use 75-150 words per specification a. bridge player ». change-making machine ¢, car cruise control d. electronic typewriter i spelling checker si fener ige, Remove any design deci- 'L6 @ Rephrase the following requirements (0 make them more precis nae tions post ts: vera telecommunicaton line. T wa Stem 0 tester dt from one com ver ama ot be sti the rece systém should transmit data reliably over @ scanned with OKEN ScannerRARY up RAR 2 mySORE pomain Analysis Domain analysis, the next stage of development, i ae : ee thebuilder must understand the requirements, Requirements can be tain word, but these are often imprecise and ambiguous. During analysis, we build models and begin to under- sfand the requirements deeply. To build a domain model, you must interview business experts, examine requirements statements, and scrutinize related artifacts. You must analyze the implications of the require- rents and restate them rigorously. It is important to abstract important features first and de- fersmall details until later. The successful analysis model states what must be done, without restricting how it is done, and avoids implementation decisions. ih this chapter you will learn how to take OO concepts and apply them to construct 8 domain model. The model serves several purposes: It clarifies the requirements, it provides and the developers, and it becomes the start- a basis for agreement between the stakeholders ing point for design and implementation. 12.1 Overview of Analysis As Figure 12.1 shows, analysis begins with a problem statement generated during system conception. The statement may be ‘incomplete or informal; analysis makes it more precise and exposes ambiguities and inconsistenc ‘The problem statement should not be taken as im asis for gefiing the real requirements. wet oe ah the real-world system described by the problem statement, eae atural language are often am- isd abstract its essential features into Rees peontie precise, conse representa iguous, incomplete, and inconsistent. The , i ee and building a solution, Subsequent fe its answering questions and bu 181 @ scanned with OKEN ScannerON 182 3.4 929) Chapter 12/ Domain Analysis Users ; Generate tic Developers requests System Conception Managers Problem Statement User interviews Analysis: Domain knowledge Build Domain Analysis Real-world experience Lilia Application Analysis Related systems Class Model State Model Interaction Model wane nnn nen ney Design Figure 12.1 Overview of analysis. The problem statement should not be taken as im- mutable, but rather as a basis for refining the requirements. Perhaps even more important, the process of constructing a rigorous model of the problem domain forces the developer to confront misunderstandings early in the development process while they are still easy to correct. The analysis model addresses the three aspects of objects: static structure of objects (class model), interactions among objects (interaction model), and life-cycle histories of ob- jects (state model). All three submodels are not equally important in every problem. Almost all problems have useful class models derived from real-world entities. Problems concerning reactive control and timing, such as user interfaces and process control, have important state models. Problems containing significant computation as well as systems that interact with other systems and different kinds of users have important interaction models, Analysis is not a mechanical process, The exact representations involve judgment and in many regards are a matter of art. Most problem statements lack essential information, which must be obtained from the requestor or from the analyst's knowledge of the real-world problem domain, Also there is a choice in te lee of abstraction for the model. The analyst must communicate with the requestor to clarify ambiguiti i etd ysis models enable precise communication. en ues and misconceptions, The anal- We have divided analysis into two substages, rae . this chapter and focuses on understanding the reaneri eee analys ane 4, application analysis, is covered in the next chapter and builds on there genes en, porating major application artifacts that are seen by users and must he eet te ist be approved by them. @ scanned with OKEN Scannerpamain lass Model w Py) pomain Class Mode} step in analyzing the i ne fos the static strctureofthe ra 18 t0 construct : in “ode! describes Tealsneanoelds sem and a domain model, The domain 6TH ysis, the class model precede Classes and theireleionatea ete ni 8 the state and thease to each other. Dur- Meraction models because static 183 sty on a single source, ‘r all information that is available and do oe “4, jnd classes and associations first, as 4 : Fin Next add atibutes to ue oe the overall structure and approach to Pomme and organize lasses sing ineranee, network of classes and association. iy without first understanding classes and their atibles can fae a aie ‘preconceived notions. Operations are usually cae te aa in purpose of a domain model is to capture the information covtent oF «do serie its best to get ideas down on paper before trying to organize them too much they may be redundant and inconsistent, 0 as not to lose iapana tae "An inital ismodelis likely (0 contain laws that must be comected by later iterations, The cae rds need nat be constructed uniformly. Some aspects ofthe problem ean be analyzed in depth through several iterations while other aspects are still sketchy. You must perform the following steps to construct a domain class model. Find classes, (12.2.1-12.2.2] Prepare a data dictionary. [12.2.3] Find associations. [12.2.4-12.2.5] Find attributes of objects and links. (12.2.6-12.2.7] Organize and simplify classes using inheritance. [12.2.8] Verify that access paths exist for likely queries. [12.2.9] Ilerate and refine the model. (12.2.10] Reconsider the level of abstraction. [12.2. Group classes into packages. [12.212] 1] 12.2, ; The} ny Finding Class s model is to find relevant classes for objects a 7 ap- step i ing a clas: 7 and machines, tcaiondronn: Objects include pysical ens roe uses Pent schedules. Al Swell ; iectories, seating assien"" i tation con- ttaeaet ea ta plicaton jomain; avoid computes i oben! state- a en make sense in - applica Not all classes are explicit i Pr Such as linked lists and su! routines. Some are implicit in the application €o™ @ scanned with OKEN Scanneran 184 Chapter 12/ Domain Aq As Figure 12.2 shows, begin by listing candidate classes found in the written eset of the problem. Don’t be too selective; write down every class that comes to mind. Classen often correspond to nouns. For example, in the statement “a reservation System 10 sell tig (o performances at various theaters” tentative classes would be Reservatioy t, System, Ti : Performance, and Theater. Don't operate blindly, however. The idea to is capture Concepts not all nouns are concepts, and concepts are also expressed in other Parts of speech, Tentative Eliminate Classes Figure 12.2 Finding classes. You can find many classes by considering nouns, Don’t worry much about inheritance or high-level classes; first Bet specific classes Tight So that you don’t subconsciously suppress detail in an attempt to fit a Preconceived stric. ture. For example, if you are building a cataloging and checkout system for a library, iden. tify different kinds of materials, such as books, magazines, Rewspapers, records, videos, and so on. You can organize them into broad categories later, by looking for similarities and differences, ATM example. Examination of the concepts in the ATM problem statement from Chap. ter 11 yields the tentative classes shown in Figure 12,3. Figure 12.4 shows additional classes that do not appear directly in the statement but can be identified from our knowledge of the problem domain. 7 Software Banking Cashier | [ATM Consortium Bank Bank Account | [Transaction Cashier Accor T n Computer [Account] [Transaction] Siar | Data” ore Central Cash User Cash compa, | [ Card [eas Receipt | [system Recordkeepin, Securl Ae Proven” | | provisich | CAeces] [Got] Peumiomer Figure 12.3 ATM classes extracted from Problem statement nouns @ scanned with OKEN Scannerpomaln Class Model 5 yp? weeping the Right Classes . i unnecessary and inc fi cad an NOOR class. pows the classes eliminated from the apnyn ording 5 ATM examen (th following erteria, Figure ple, pi Bad Classes vague attribute Accour irrelevant (ster Data" | [Receipt ai ourity . provision = Cash] ‘rat recordkeeping pagal] implementation Provision Transaction) [Access 9 Barre redundant Software Weer Communications Line Good Classes Account] [_ATM Bank | {Bank | [ c : comuter| | Garg] Loestiee Cashier Central — coantral Consortium] [Customer | [Transaction Figure 12.5 Eliminating unnecessary clases from ATM problem ame concept, you should keep the most ‘mer might describe a person taking an he other hand, if the problem concerns te word, since a contract Redundant classes. If two classes express the s descriptive name. For example, although Custo airline flight, Passenger is more descriptive. Ont n contracts for a charter airline, Customer js also an appropriat might involve several passengers: i ATM example. Customer ‘and User are redundant; we retain Customer because it is more descriptive. Irrelevant classes. If class has it do with the problem, eliminate it. is i ju i context the class could be important. For ex- Tinos ot another >t ne occupations of the ticket holders are ample, in a theater ticket reservation system, 0 inden i sonnel may be important. inelevant, but the occupations of the theater pers Se te ani ‘oni is outside th A™ . Apportioning: Cost is outsi é i Vague agree te specifi. Some rentable classes may have ill-defined Ad boundaries or be too broad in SCOP J or nothing to @ scanned with OKEN ScannerChapter 12/ Domain Anaya, 186 le 1d is handled by Transacy, ingProvision'is vague an' ton, ATM example, cory be included in ober classes, such a8 StockSaes, 7, In other applicat 7 a ineFailures. - phoneCalls, or a no describe individual objects should be restated ag 5, Attributes. Names thet Pi rdhdate, and weight are usually attributes. Ifthe indepe, tributes, For exam ey is important, then make it a class and not an attribute, dent Prpeae soine’s office would be a class in an application to reassign offices af. example, an emp TT as. :Data is underspecified but in any case probably describes ile. Account ‘s = ane ATs dispenses cash and receipts, but beyond that cash and receipts are peripheral to the problem, so they should be treated as attributes. ; ; Operations. If a name describes an operation that is applied to objects an Not manip. ulated in its own right, then itis not a class. For example, a telephone call is a sequence of actions involving a caller and the telephone network. If we are simply building tele. phones, then Call is part of the state model and not a class. ‘An operation that has features of its own should be modeled as a class, however, For example, in a billing system for telephone calls a Call would be an important class with attributes such as date, time, origin, and destination. @ Roles. The name of a class should reflect its intrinsic nature and not a role that it plays in an association. For example, Owner would be a poor name for a class in a car manu- facturer’s database. What if a list of drivers is added later? What about persons who lease cars? The proper class is Person (or possibly Customer), which assumes various different roles, such as owner, driver, and lessee. One physical entity sometimes corresponds to several classes, For example, Person and Employee may be distinct classes in some circumstances and redundant in others. From the viewpoint of a company database of employees, the two may be identical. In @ government tax database, a person may hold more than one job, so it is important to distinguish Person from Employee; each person can correspond to zero or more instanc- es of employce information. @ Implementation constructs. Eliminate constructs from the analysis model that are ex- ae ta —— hie may ema later during design, but not now. For ex- mec Toe mist applications althou rf ihe a iterept are implementation cor y ‘gh they are legitimate classes for an operating sys- tem, Data structures, such as linked lists, trees, implementation constructs, } arrays, and tables, are almost always ATM example, S ; TransactionLog iS siraply the ene . ally implementation constructs. sue, Communication Ii 3 MS exact representation is ign is- the physi tunication links can be shown as associations; Communicati + a desig ‘ 'ysical implementation of such a link, 7 icationsLine is simply Derived classes. As a general rule, Omit classes that can be derive class a li derived from other es classes. If a derived class is especially i arin; ‘ ally important, you can j i Mark all derived classes with a Preceding sash (inthe clase name tag name. tative classes are re; t of transactions; » @ scanned with OKEN Scannerr 3 pomain Class Model @ 187 pas ords pera aes Dictiona wi y inter jt fs, Write a paragraph precisely dao to prepare w data de em the current problem, including anetibing each cas, Cuan, for all modeling witty also describes associations, attentions > oda scope of ie ore . 8, use, The data 4a ga data diction: , rag stows # ary forthe classes in the ATi enumeration values Figue 9,24 Finding Associations .d associations between cl: est find ass lasses. A structural relati : tion. A al relations d ons attribute employer; relate 1 ; Sinn Wok Asolo show relfonshs ben Sansa sue d etasracion Ideagas Themselves, While object-valued attributes hide depentenccs obscl 'y nature. Associations can be implemented in various ways, but fechimplomentation decisions should be kept out of the analysis model to preserve design freedom. ‘Associations often correspond to stative verbs or verb in i sean (Next To, PartOf, Containedin, directed actions Se ea caieD) ownership (Has, PartOf), or satisfaction of some condition (WorksFor, MarriedTo, Manag: Extract all the candidates from the problem statement and get them down on paper first; don'ttry to refine things too early. ‘Again, don’t treat grammatical forms blindly; the idea is tpcapture relationships, however they are expressed in natural language, 'ATM example. Figure 12.7 shows associations. The majority are taken directly from verb phrases in the problem statement. For some associations the verb phrase is implicit in thewatement, Finally, some associations depend on real-world knowledge or asstinp ‘These must be verified with the requestor, as they are not in the problem statement. tions. 12.2.5 Keeping the Right Associations ns, using the following criteria. Now discard unnecessary and incorrect associatio inated one of the classes 1 Associations between eliminated classes. Ifyou have eliminated oF in the association, you must eliminate the association or restate it in terms of other classes, ATM example. We ATMs, ATM dispenses cash, tioned to banks, System. provides Te Irrelevant or impl tation ass 7 : plement const Sidhe problem domain o deal we implemen concuTet svecess is an implementa- ATM example. For example, Sis handles conc isthe implementation of ton concept, Real-world objects ‘nherently concusTent ets it. the access algorithm that must be concurrent imi i includes cashier stations and eliminate Banking network inclu ot ATM prints receips, Banks provide software, Cost appor- riecping, ana Sytem proves Seu). ate any associations that are out- . Elimins ape structs. @ scanned with OKEN ScannerON Chaptor 12/ Domain Analysi, it at a bank against which transactions can be applied, Ac- Seaunte neg eae types, such ag checking or savings. A customer ean rola more than one account. \‘TM¥—a ‘s customers to entor thelr own transactions using’cash caret os dentficalon The ATA Tntoracte with tho customorto gather transaction in- formation, sends the transaction information to the central computer for validation and processing, and dispenses cash to the user. We assume that an ATM need not Operate independently of the network, ink inancial institution that holds accounts for customers and Issues cash ca aatoaang access to accounts over the ATM network. 1KComputer—the computer owned by a bank that interfaces with the ATM net- ork and the banks own cashes stations” A bank may have its own internal comput- ers to process accounts, but we are concerned only with the one that talks to the ATM network. CashCard—a card assigned to a bank customer that authorizes access of accounts using an ATM machine. Each card contains a bank code and a card number. The bank code uniquely identifies the bank within the consortium. The card number de- termines the accounts that the card can access. A card does not necessarily access all of a customer's accounts. Each cash card is owned bya single customer, but mul- tiple copies of it may exist, so the possibility of simultaneous use of the same card from different machines must be considered, Cashier—an employee of a bank who is authorized to enter transactions into cashier stations and accept and dispense cash and checks to customers. Transactions, ash. and checks handled by each cashier must be logged and properly accounted for. CashlerStation—a station on which cashiers enter transactions for customers, Cashiers dispense and accept cash and checks; the station prints receipts, The cash- ier station communicates with the bank computer to validate and process the trans- ns. CentralComputer—a computer operated by the consortium that dispatches transac- tions between the ATMs and the bank computers. The central computer validator bank codes but does not process transactions diracly. Consortium—an organization of banks that commissions and operat ' work. The network handles transactions only for banks in the conectaat Customer—the holder of one or more accounts ina bank. A customer can consist of ne of more persons or corporations; the correspondence is not relevant to this prob- fern ane a person holding an account at a different bank Is considered a different Transaction—a single integral request for ‘operations on the ai i ir customer. We sealed only that ATMs must dispense cash, but we shout we: clude the possibility of printing checks or ‘accepting cash or checks. We may also ‘want to provide the {| ilit hisnot a 7 ine tlexiolity to operate on accounts of different Customers, although Figure 12.6 Data dictionary for ATM classes. Prey ti for all modeling elements, Pare adata dictionary @ scanned with OKEN Scannerpan Class Model ‘e 189 Verb phy Banking network ineludee 2" Consortium sharos Ags CAShier stat Berk rove tens lons and ATMs Bank compuner maintains econ Bank owns castiorage® Wansacton against hier stati oe ES en hemp Is comm a . Central computer, oat ‘range eta shox hk ATM accepts casi a's "ansacton wih pant ransaction ATM interacts with usor ATM dispenses cash ATM prints rccips system handles cor Banks provide softwarg. C2288 Cost apportioned to banks Implicit verb Consortium consists of banks ies Bank Le account ‘onsortium owns central comput System provides recordkeeping a ‘System provides security Customers have cash cards Knowledge of problem domain Cash card accesses accounts Bank employs cashiers Figure 12.7 Associations from ATM problem statement It Actions, An association should describe a structural property ofthe application domain, nota transient event. Sometimes, a requirement expressed as an irae implies an un- derlying structural relationship and you should rephrase it accordingly. "ATM example. ATM accepts cash card describes pat of the interaction ore be tween an ATM and a customer, not a permanent relationship between ATM ci : cards, We can also eliminate ATM interacts with user: Central compute iis tena tion with bank describes an action that implies the structural relationship Cent i ith bank. puter communicates with bar assoratons among three oF more 1 Ternary associations. You ca” beri oF equaled associations. Ifa term ina Glasses into binary associations Ore and has no identity of iS tenthe em ‘emary association is purely des me association COMPA) pays salary 10 ee a matte on binary assoeio company ploy person witha sary val tephrased as binary associat Company-Person link. vy require a general Occrtonlly, an application wil ring teaches course in room cannot be decomPP in our work: encountered associations with ary association. Professor terijaformation, We have not four or more © @ scanned with OKEN ScannerChapter 12 / Domain Analysis ATM example, Bank computer, ‘processes transaction against account can be bry. ken into Bank computer processes ‘ransaction and Transaction concerns account. Casp, roken similarly. ATMs communicate with cen, ier enters transaction for account can bebr Th tral computer about transaction is really the binary associations ATMs communicate with central computer and Transaction entered on ATM. an be defined in terms of other associa, i Derived associations. Omit associations that 2 tions, because they are redundant. For example, GrandparentOf can be defined in terms of a pair of ParentOf associations. Also omit associations defined by conditions on a. tributes. For example, youngerThan expresses & condition on the birth dates of two per. sons, not additional information. “Ne much as possible, classes, attributes, and associations in the class model should represent independent information. Multiple paths between classes sometimes indicate derived associations that are compositions of primitive associations. Consortium shares ATMs is a composition of the associations Consortium owns central computer and Cen. tral computer communicates with ATMs. De careful, because not all associations that form multiple paths between classes in- dicate redundancy. Sometimes the existence of an association can be derived from two ‘or more primitive associations and the multiplicity can not, Keep the extra association in Figure 12.8 a com- ifthe additional multiplicity constraint is important. For example, pany employs many persons and owns many computers. Each employee is assigned ero or more computers for the employee's personal use; some computers ate for public ‘use and are not assigned to anyone. The multiplicity of the AssignedTo association can- not be deduced from the Employs and Owns associations. Company | Emplovs _f Person 1 0.1 Owns Assi * ‘Computer * ignedTo Figure 12.8 Nonredundant associations, Not all associations that form multiple paths between classes indicate redundancy. ‘Although derived associations do not add information, thet is agh der i , they are useful in the real world and in design. For example, kinship relationships such as Uncle, MotherInLaw, and Cousin have names because they describe common relationships considered impor fant thin oF pound If ey are especially important, you may show derived associ- jons in class diagrams, but put a slash in front of their indi i . dent status and to distinguish them from fundamental astolations a Farther specify the semantics of associations as follows: ‘ ™ Misnamed associations. Don't say how or why a situation came about, ‘Names are important to understanding and should be chosen with great cath i are. 1 @ scanned with OKEN Scanneryr pomain Class Model f example. Bank com; 191 pute; as Bank holds account, maintains accounts is a statem ent of action; re- p A sociation end names. Add Association ¢ ciation yer i class tingui: i cai iguish the instances. For example, the as~ ave thi ied associations. Usually a name ia end panes boss and worker. dvs are not globally unique, The context ra ilar neat. For example, the name of a compan es with the name to uniquely identify te at may be duplicated in othe states (ee so, Indiana, California, and New Jersey) Then ce was a Standard Oil Company in ciation State charters company; ‘State end Cangas de of a company qualifies the asso- paler distinguishes objects onthe “many” ae ee ea i ation. 'ATM example. The qualifier bankCode distinguishes the different banks in a con- ortium. Each cash card needs a bank cod 7 “paar sortium. code so that transactions can be directed to the appropriate bank. Maltiplicity. Speetiy multiplicity, ‘but don’t put too much effort into getting it right, as auliplcity often changes during analysis. Challenge multiplicity values of “one.” For example, the association one. Manager manages many employees precludes matrix man- nt or an employee with divided responsibilities. For multiplicity values of “nany” consider whether a qualifier is needed; also ask if the objects need to be ordered insome way. Missing associations. Add any missing associations that are discovered. ATM example. We ‘overlooked Transaction ‘entered on cashier station, Customers have accounts, and Transaction ‘authorized by cash card. If cashiers are restricted to spe- cific stations, then the association Cashier authorized on cashier station would be need- ed. A jon is important pate geregation, Aggregation is IMPIT of material. For other applications agerega- gation or ordinary a8- those involving mechanical parts and Bs tons relatively minor and it can be une agen Sociation, For these other applications, don't sent fog tee toasting & tween association and aggregation. ation is j tations, Use whichever ome more natural athe te and me _ ATM example. We decide that a Bank is @ part of "elationship wit ip with aggregation. i vi mM example. Figure 12.9 shows @ class diagram wt teen Med only significant association names. Note ion Person manages person would h for certain kinds of aplication. especially for indicate the ing associations. We have split Transaction into Re- @ scanned with OKEN Scanner« | 192 Chapter 12/ Domain Analyis moteTransaction and CashierTransaction to accommodate different reine The dig, gram shows multiplicity values. We could have made some analysis cenit Aiffereny Don't worry; there are many possible correct models of a problem. We have shown the ang - ysis process in small steps; with practice, you can elide several steps together in your ming * * 1 Consortium |bankCode 9-1) Bank 1 ‘Account Custom, 1 May i] if [* 7 Employs 1 i . Semen] COmmuicates —— i en hier Computer [7 +] Computer Cas 1 7] q CommunicatesWith EnteredBy & * * * i Cashier| Enteredon | Cashier comin Station 1 * Transaction : * EnteredOn Remote pe || Transaction CashCard * AuthorizedBy 1 : Figure 12.9 Initial class diagram for ATM system 12.2.6 Finding Attributes Next find attributes. Attributes are data properties of individi locity, or color. Attribute values should not be objects; use tionship between two objects. Attributes usually correspond to nouns followed by or of the car” or “‘the position of the cursor.” Adjectives often . less key tobe fully described in the problem statement You must dog oe ledge of the sppticaton domain i the real world to find them. You can also tad detent in the artifacts of S. il ae related systems. Fortunately, attributes seldom affect the basic structure of the Do not carry discovery of attributes to excess, Onl ‘othe application. Get the most important attributes fi ual objects, such as weight, ve an association to show any rela- Possessive phrases, such as “the col- Y consider attributes ditectly relevant st You can add fine details later, Dur @ scanned with OKEN Scanner