Chapter Object-Oriented Analysis Learning Objectives ‘ter studying this chapter, ou should be able to + Perform the analysis worklow, ‘+ Extract the boundary, control, and entity classes ‘= Perform functional modeling ‘= Perform class modeling ‘+ Perform dynarnic modeting. + Pérfor use-case realization Tn Ghapter 11, we examincd various classical analysis techniques. This chapter is the ‘objeci-oriented counterpart of Chapter 11. ‘Object-oriented analysis (OOA) is a semiformal analysis technique forthe object- ‘oriented paradigm. In Chapter 1, We pointed out thata number of different techniques arc used for structured systems analysis, all essentially equivalent, Siailarly, well over 60 dif ferent techniques have been put forward for OOA. Again, all the techniques are largely ‘equivalent. The “For Further Reading” section ofthis chapter includes references to a wide ‘variety of techniques, a8 well as to published comparisons of different techniques. However, as expiaiued in Section 3.1, today the Unified Process [Jacobson, Booch, and Rumbaugh, 1999] is almost always the methodology of choice for object-oriented software pproduetion, For this zeason, the fist and last part ofthis chapter are devoted tothe analysis ‘workfiow ofthe Unified Pracess. Object-oriented analysis is a key component of the object-oriented paradigm. When this ‘workfiow is performed, the classes are extracted, The use cases and the classes ae the basis a8Most of the major advancesin the object-oriented paradigm wvere made between 1990 and 1995, Bacause it usually takes some 15 yeurs for new technology to. become: accepted, ‘widespread adoption of the object-oriented caradigm should have started no sooner then 2005. However, the millennium bug or Y2K problem changed the expected timetable. Inthe 1960s, when computers first started to be used for business on a widespread basis, hardware was far more expensive than itis today. As 2 result, the vast majority of software products of that vintage represented a date using only the last two digfts for @ year; the leading 19 was understood, The problema with this scheme is that the year 00 is then inter- preted as 1900, not 2000, ‘When hardware became cheaper in the 1970s and 1980s, few managers saw ary point in spending large sums af money rewriting existing software products with four-digit dates. Afterall, by the time the year 2000 arrived, it woul! be someone else's problem. As a result, segacy systems remained year-2000 noncompliant. However, as the deadline of January 1, 2000, neared, so‘twire organizations were forced to work against the clack to ix their soft. ‘ware products; there vias no way to postpone the acrval of Y2K. Problems facing the maintenance programmers included @ lack of decumentation for many legacy software prociucts, as well as software products writen in programming ian- guages that were now cbsolete. When modifying an existing software product was impos- sible, tre only alternative was to start again from scratch. Some companies decided to use COTS technology (Section 1.11). Others decided that new custom software products were. needed. For obvious reasons, managers wanted these software products to be developed Using modem technology that had already been shown to be cost effective, and that meant using the object-oriented parad'gm. The Y2K problem was therefore a significant catalyst {or the widespread acceptance of the object-oriented paradigm, of the object-otianted software product to be developed. (For more insight into the object- oriented paradigm, see Just in Case You Wented to Know Box 12.1.) rilow is workflow of the Unified Provess [Jacobson, Booch, and Rumbaugh, 1999) has two aims. From the viewpoint of the requirements workfiow (the preceéing workflow), the aim of the analysis workflow is to obiain a deeper understanding of the requirements. Conversely, from the viewpoint of the design and implementation worklows (the work- fiows that follow the analysis workfiow), the aim of the analysis workflow is to describe those requiremexts in such @ way that the resulting design and implomentation are easy to ‘The Unified Process is use-case driven. During the analysis workflow, the use eases are Xoscribed in terms of the classes of the software product. The Unified Process bas three types of classes: entity classes, boundary classes, and control classes. An entity class ‘nwodels information thats long lived. In the ease of banking software product, Account, Class is an cntity class because information on accounts has to stay in the software proc- ‘uct, For the MSG Foundation software prodvct, Investment, Class is an entity class: ‘again, information on investanents bas to be long lived. A boundary ciast models the interaction between the software product and its actors. ‘Boundary classes are generally associated with input end output. For example, in the MSGChapter 12 Objoce Oram dncyse 377 FIGURE 12.1. UML sereetypes (exuesions of UML) for representing an ouity class, boundary class, and a control lass. Oo oO Entity Class Boundary Class Control Class Foundation software product, reports have to be printed listing the investments of the Foundation, a well a al the morigages currently hold. This means tha: boundary classes Investments Report Class aud Mortgages Report Class are nsvded. “Acontrol class models complax compiations and algorithms Inthe ease ofthe MSG Foundation software product, the algorithms for estimating the funds available for the week isa control class, nam, Estimate Funds for Week Class, ‘The UML notation for these three types of classes is shown in Figure 12.1. These are stereotypes, tha is, extensions of UML. A strength of UML is that it allows adéitional constructs to be defined that are not pact of UML but may be needed to model a specific sysiem aseurstely, {As stated at the beginaiing of this section, during the analysis workflows the use cases are describod in terms of the classes of the software product. The Unified Process itself does not describe how classes arc to be extracted, because users of the Unified Process are ex- pected to have a background in object-oriented analysis and design. Accordingly, this is- cussion of the Unified Proces is tmporarly suspended so that an explanation can be given of how classes are extracted; we rerum to the Unified Provess in Section 12. Entity classes, that i, clases that model Jong-lived information, are considered Gist 12.2 Extracting the Entity Classes nti class extraction consists of tare steps tat are carried oxt iteratively and incrementally: 1. Functional modeling, Present scenarios of all the use cases (a Scenario is an in- stance of a use case). 2, Entity class modeling, Derermine the entity classes and their attributes, Then, detor- ‘mine the interrelationships and interactions between the entity classes. Present this ‘fermation in the form of a class diagram. 3, Dynamic modeling, Determine the operations performed by orto each catty class or subelass, Present this information in the form of a statechart However, as with oll iterative and incremental processes, the three steps are not neces sarily always performed in this order; @ cbange in one model fcequently triggers corre- sponding revisions of the other two models. "To show how this is €one, we now extract the entity classes of the elevator problem case study:378 Part Two The Moros othe Softmare Lye Chole jase Study plZ24 Object-Oriented Analysis: The Elevator Problem Case Study ‘The elevator problem case study is described in Chapter 11. For ease of reference, the problem is repeated here. A product isto be installed to control n elevators ina building with m fioors. The problem concems the logic requited to move elevators between floors according to the following constraints: |. Bach elevator bas a set of m buttons, one for eact floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The iluminatioa is, canceled winen the corresponding floor is visited by the elevator 2, Bach floor, except the fist floor and the top Boor, has two buttons, one to request ‘an up-elevator and one to request a down-elevator. These buttons iiuminate when pressed. The illumination is canceled when an elevator visits the Boor and then ‘moves in the desired direction. 3. When an elevator has no requests, itremains atts current floor with its doors closed. ‘The first step in OOA is to model the use cases. Functional Modeling: The Elevator Problém Case Study A use case describes the interaction between the product to be constructed and the actors, that is, the extemal users of that product. The only interactions possible between 2 user and an elevator are the user pressing an elevator button to summon an elevator or the user pressing a fioor button to request the elevator to stop at a spotific floor, hence, the two use cases, yess an Elevator Button and Press 2 Floor Sutton. The two use cases are shown in the use-case diagram (ection 10.7) of Figure 12.2, FiGune 12.2 TT Uee-case Hlevator eae case oO Elevator Sutton, study, oo EEE |Chapter 12 Object Orienled Analyeiy 379 FIGURE 12.3. The first iteration of a normal scenario, User A presses the Up ‘loor burton at floor 3 to request an elevator. User A wishes t0 go to fcor 7, 2. The Up flcor bution is turned on, 3. An elevator arives a floor 3. It contains User 8, who has entered the elevator at floor T and prosced the elevator button for floor 8. 4, The elevator doors open. 5. The timer starts, | User A enters the elevator. 6. User A presses the elevator button for floor 7. 7. The elevator button for floor / is turned on. 8. The elevator doors close after a timeout 9. The Up floor button is tured oft, 10. The elevator travels to floor 7. 11, The elevator bution for floor 7 is turned of. 12. The elevator doors open to allow User A to exit fram the elevator. 13, The timer starts. User & exits from the elevator 14, The elevator doors dose afer # timeout. | 13, The elevator proceeds to floor 9 with User B. A.use case provides a generic description of the overll functionality; a scenario is a specific instantiation of a use case, just as an object is an instantiation of a class. fa {gencral, there are a lage number of scenarios, each zepresenting one specific set of interacsions. In this section, we consider the scenario of Figure 12.3, which incorpo- rates instantiations of both use cases. Figure 12.3 depiets a normal scenario; that is, a set of interactions between users and elevators that corresponds to the way we understand elevators should be used.Figure 12.3 was constructed after carefully observing different users interact- ing with elevators (or, more precisely, with elevator butions and floor buttons). The 15 numbered events describe in detail the tno interactions between User A and the bouttons of the elevator system (event 1 and event 6) and the operations performed by the components of the elevator system (evenss 2 through $ and 7 through 15). Two items, User & enters the elevator and User A exits from the elevator, are un- numbered. Such items essentially are comments; User A does not interact with the ‘components of the elevator when entering or leaving an elevator, In contrast, Figure 12.4 isan exception scenario. It depicts what happens when ‘auser presses the Up button at floor 3 but accuslly wants to go down to oor 1. This scenario, 100, was eonstzucted by observing the actions of many users in elevators; it is unlikely that someone who has never used an elevator would realize that users sometimes press the wrong button. “The scenarios of Figures 12.3 and 12.4, plus innumerable others, are specifi ia- stances of the use cases shown in Figure 12.2. Sufficient scenarios should be studied380 Part Tino The Workflows ofthe Sofware Life Cle FIGURE 12.4 An exception scenario, 1. User A presses the Up floor bution at flaor 3 to request an elevator. User A wishes to-go 10 floor # 2. The Up floor button is turned on. 3. An elevator arrives at floor 3. It contains User B, vho has entered the elevator at ‘floor 1 and pressed the elevator button for floor 9. 4. The elevatar doors open, 5. The timer starts, User A enters the elevator. 6. User A presses the elevator button for flear 1 7. The elevator button for floor 1 is tured on. 1 elevator doors close after @ timecut, 9. The Up floor bution is turned ‘The elevator travels to floor 9, 11. The elevator button for floor 9 is turned off. | 12, The elevator doors open to allow User B to exit from the elevator. “The timer starts. User B exits from the elevator. ‘The elevator doors cinse after a timeout. 5. The elevator proceeds to floor T with User A. 3 to give the OOA team a comprehensive insight into the behavior of the system being modeled. This information is used in the next step, entity class modeling, to deter= rine the entity classes. ase Study 5, Entity Class Modeling: The Elevator Problem Case Study In this step, the entity classes and their attributes are extracted and represented in a UML class diagram. Only the attributes of an entity class are determined at this time, sortie moods he ater a asigneé hs lacs dng ie bjeceonentd dee sign (OOD) workflow. ‘A charactsisic of the whole cbjeccorinted paradigm is thatthe various steps rarely are'casy to carry out. Fortunately, the benefits of using objects make the effort #f? worthwhile. So it should not come as a surprise that the first part of the analysis = workfiow, extracting entity classes end their attributes, usually is difficult wo getright he fs: ie, : Ope method of determining the entity classes is to deduce them from the use” _” cases, That is, the developers cxzeflly sty all she scenarios, both normal andChapter 12 Objec-Qrenod Anais exception, and identify the components tha ley arolsin the use ceses. From just the scenarios of Figures 123 znd 12.4, candidate entity classes are elevator buttons, oor buttons, elevators, doors, and timers. As we will oe, these candidate entity classes are close to the etual classes extracted ducing entity class modsiing. In gencral, how es, there are many scenarios and, consequently, a lange numberof potential classes. ‘An inexperienced develozer may be tempted to infir too rary candidate entity classes from the scenarios. This ha a dsicterious effect on tke entity class modeling, because its easier to add u new entity class than to remove a candida:> entity class ‘bat should not have been. included. ‘Another approach to determining the eaity classes, which i effective when tho developers have domain expertise is CRC cards Section 12.5.2) Howeves ifthe de- velopers hive litle or no experience in the application éomein then tis advisable to ‘se noun extraction, described in Sootion 12.5.1. 12.5.1 Noun Extraction For developers with n0 domain expertise, a good way to proveed is to use the follow- ing two-stage noun-extraction method to extract candidate entity classes and then to refine the eolusion: Stage 1. Describe the Software Product in a Single Paragraph One possible way to do this for the elevator problem case study is as follows: ‘Buttons in elevators and on the Hoore contol she movement ofn elevators in a building ‘with m flrs. Bamons luninate when pressed to cequsst the elevator to stop ata pe- cific oer; the iRumination is eancalad wien the request hes beea sated. Wen an levator has zo requests, it resains a its cureat floor with i doors closed. Stage 2. Identify the Nouns [dentify the nowns inthe informal streteay (excluding those that le outside the prob- Jem: boundary), and then se these nouns as candidate entity classes, The informal strategy is now reproduced, but zis time with the identified nouns prited in a sans serif typetece. Buttons ix elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate wien pressed to request ax elevator to stop at a specific floor; the illumination is canceled when the request as besa satisfied, When an elevator has co requests, it remains at its current floor with its doors closed “There are eight different nouns: button, elevator, floor, movement, building, mination, request, and door. Three of these nows—floor, buitding, sad door—ie ev'side the problem boundary and thewefore may be ignoted. Three ofthe remaining nexns—movement, ilination, and request—are 2bstract nouns, that is, ey ienity things thar have no physical existence, A useful rule of tu is that abstract nouns rarely end up corzesponding to classes, Instead, they frequontly are atibutes of elasces. For example, illumination is zn attribute of button. This 381 i eee382 ParcTive The Worloas ofthe Sofeare Lie Cyl FIGURE 12.5 The first iteration of the class diagram forthe elevator problem case study. Button Class Tluminated ; Boolean Floor Button Class| a2 communicates with ST Gtevator Gass [2— (doors open : Boolean leaves two nouns and, therefore, two candidate entity classes: Elevator Chass and Button Class, (The UML convention is to use boldface for class names and capi- talize the initial letter of each word in a class name.) The resulting class diagram is shown in Figure 12.5, Button Class has the Boolean ztiribute illuminated to model events, 7, 9, and 11 of the scenarios of Fig- ‘ures 12.3 and 12.4. Tee problem specifies two types of button, so two subclasses of Button Class arc defined: Elevator Button Class an¢ Floor Button Class (the open triengle denotes inHeritancs in UML). Each instance of Elevator But- ton Class and Floor Button communicstes with the instance of Elevator Class. The latte class has the Boolean attcibute doors open to model events 4, 8 12, and 14 of the two scenarios. ‘Unfortunately, this is not 2 good bogianing. Ina weal elevator, che burtons do not directly communicate with the elevators; some sort of clevater controler is needed, foaly to docide which elevator to dispatch in response to a pactioular request. How- ‘ever, the problem statewent makes no mention of a controller, so it was not selected 3 a entity class during the noun-extraction process. In other words, the technique of ‘his section for finding candidate entity classes provides a stating point but certainly should not be relied on to do more than thet. ‘Adding the Elevator Controller Class to Figure 12.5 yields Figure 12.6. This certainly makes more sense. Furthermore, thore are now one-to-many relationships in Figure 12.6, as opposed to the hard to model many-io-mazy relationship of Fig- ‘ure 12,5, I therefore seems reasonable to go on to step 3 at this poine,beacing ining ‘that i is possible to return to entity class modeling at any time, even as late as the ins- plemertation worktow. However, before proceeding ‘with the dynamic modeling, a ‘dierent technique for entity class modeling is considered.FIGURE 12.6 ‘Tae second iterason of the class diagram Torts clevase problem ease study Chapter 12 ObecrOrened Anabee 383 Elevator Button Class) [Floor Button Class| 7A lam = 2 controls controls Elevator Controller Cl F controls Elevator Class ‘doors open : Boolean | 12.5.2 CRC Cards Fora numberof years, class-responsibility-collaboration (CRC) cards have bees ute lized during the object-oriented analysis workflow [Wits-Brock, Wilkerson, and Wiener, 1990]. For each clas, the software development team fils in a card showing che name of the clas, its fmctionality (responcibilin), and 2 Hst ofthe other classes it invokes to achieve that fnetionlty (oUboration). ‘This approach subsequently has been extended. Fest, a CRC card offen explicitly con- ‘eins the atribotes and methods ofthe eless rather than just is “responsibilty” expressed in some naturel Inguage. Seoond, the technology bas changed, Instead of using exes, some organizations put the names of the classes on Post-it Notes, which they mave arouad os.a white boar ines aze drawn betwen the Post.it Notes to denote collaboration. Nowa- Gays the whole process can be automated; CASE tools like System Architect iachude com- ‘ponents for creating and updating CRC “cards” on the soreen. ‘Tae strength of CRC cards ig taat, when ublized by @ team, the itorsotion among the members ean highlight missing or incorrect fields in class, whether attributes or methods ‘Als, the relationships between classes are clarified when CRC cards are used. One espe- cially powerful technique is to dstibmte the cars among the team members, wito then act ont the responsibilities of their clases, Thus, someone might say, “Iam the Date Class, aad my responsibility is to create new date objects.” Another team mamiber might then interject that he or she needs additional functionality fora the Date Class, suck asHow do we find the aumber of days bewween Febuary 21, 1999; and August 16, 20077 Such subtractions are needed in many financial computations, such as calculating ar ‘est payriont or determining the: present value of a future cesh flow. The usual way this done isto convert each date inso an integer, the number of days since a specified starting date. The problem is that we cannot agree what starting date to use. ‘Astronomers use julan days, the number of days since roan GMT on January 1, 4713, B.C. This system was invented in 1982 by Joseph Scaliger, who named it for his fathei, ulus Caesar Scaliger. (IF you realy, really have to know why jenuary 1, 4773 Bc. was chosen, consult [USNO, 2000}.) ° . ‘A illan date is the aumber cf days since October 15, 1582, the frst day of the Gregorian calendar, introduced by Pope Gregory Xill. Lian dates are named for Lulg! Lilo, a leading proponent of the Gregorian calendar reform. Lilo was resparsible for deriving many of the algarthms of the Gragarian calendar, incuding the rule for leap years. Turning to software, COBOL intrinsic funetions use January 1, 1600 as the starting date for ineger dates. Almost al spreadsheets, however, use January 1, 1900, folowing the lead fof Lotus 1-2-3. converting a date from the conventional format to an integer, the number of days from Jamary 1, 1900, so that finding the mumber of days betwoen any two dates can be computed easily by subtracting the corresponding two integers (see lust in Case You Wanted to Know Box 122). Thus, acting out the responsibilities of CRC cards is an effective means of verifying that the class diagram is complete aad correct, ‘A weakness of CRC cards is that this approach generally is not a good way of ideatify- ing entity classes unless the team members Inve considerable experience in tho relovant application domain, On the other hand, once the developers have dewerenined many of the clasans and have a good ides oftheir responsibilities and collaborations, CRC carts ean be an excellent way of completing the process and making sure that everything is corcect. This is described in Seetion 12.7. /* sé Study S ' Dynamic Modeling: The Elevator Problem Case Study ‘The tim of dynamic modeling is to produce a statechart, a deseription of the target product similar to a finite state machine, for each class. First, consider Elevator Controller Class. For simplicity, only one elevator is considered. ‘The relevant stetechart for Elevator Controller Class is in Figure 12.7. ‘Tee notation is somewhat similar to that ofthe finite sea machine (PSM) of Seo- tion 11.7, but there isa significant difference, An FSM as presented in Chapter 11 i8, ‘an example of a formal techoique. The state transition diagrams themselves are not a ‘complete representation ofthe product to be built Instead, the model consists of set of transition rules ofthe for given in equation (11.2) ‘current state and event and predicate —> next stateFIGURE 12,7 The Chapter 12 ObjaneCriemed Analysis 385 iteration of the stateckart for Elevator Controller Class, button it (Pee pushed, | : Processing New Request] “Tarn on button Update requests Move elevator | Open doors and one floor start timer ‘ho requests pending, doors closed aeveior eeevator elevator moving in stopped, stopped diection 6, request) no requests floor fis next pending pending, State Tiose elevator doors after timeout Determining Sop Requested Seca ee Continuing | (Stopping At Floor Moving | "Stop devaior Turning Off Floor Button: Tum off floor irectiond | | Update requests elevator elevator bbutton fit button unlit Processing Next Request ove elevator one floor in direction, fof next request | Turning OFF Elevator Button) — J Formality is achiaved by presenting the model in the form of a set of mathernatical rales In contrast, the representation of a UML. statechart is somewhat less formal. The three aspects of a state machine (state, event, and predicate) ae distributed over the UML diagram, For example, the state Going Into Wait State in Tigure 12.7 is entered if the present state is Elevator Event Loop and ths eveat elevator stopped, no requests pending is true. When the state Going Into Wait State ‘has been entered, opcration Close elevator doors after timeouts to be cartied out, ‘Current versions of OOA are semiformal (graphical) techniques, and the intcinsic leck of formality of the statechart accordingly is no problem, However, when the object-oriented paradigm metures, itis likely that more formal versions will be de- veloped and the comesponding dynamic models will be somewhat closer to finite > state machines.386 Park Two The Kortfous of he Softuare Life Cle “To see the equivalence ofthe statechart of Figure 12.7 and the STDs of Figures 1.15 ‘through 11.17, consider various scenarios. For example, consider the fret part af the scenario of Figure [2.3. Bvent | is User A presses the Up floor button st floor 3 First consider the STD of Figure 11.16. {f the floor button is off then tke button is, tured on, Now consider the statechart of Figure 12.7. The solid circle denotes the start stat, which takes the system into stete Elevator Event Loop. Following the leftmost vertical ling, ifthe button is unlit when posed, the system enters state Pro- cessing New Request of Figure 12.7, and the button is turned on. The following state ig Elevator Event Loop. ‘Next, the elevator nests floor 3, First consider the STD approach. In Figure 11.17, the elevator goes into state S(U, 3); thatis, it stops at Loor 3, about to go up. (Because the simplifying assumption has beer. made of only one elevator, the argument in Figure 11.17 is suppressed here.) Now the doors close (Figure 11.17), the Up fear bbutton is turned off (Figure 11.16), and the elevator starts 10 move toward oor 4. Returning to the statechart of Figure 12.7, consider what happens whea the eleva- tor nears oor 3, Because the elevator is in motion, the next stale enterod is Deter- mining If Stop Requested. The requests are checked and, bocause Liser A has requested the elevator to stop there, the next siaie is Stopping At Floor. The clo- ‘ator stops at floor 3, the doors open, and the timer starts, The elevator button for for 3 has not been pressed, so state Elevator Event Loop is next. ‘User A enters and presses the elevator burton for Soor 7. Therefore, the next state is agein Processing New Request, followed cgsin by Elevator Event Loop. The elevaior has stopped and two requests are pending, so state Closing Elevator Doors is noxt and the doors close after a timeout. The floor button at floor 3 was pressed by UserA, so Turning Off Floor Button is the following state, and the floor butwoa is turned off, State Processing Next Request is nex:, and the ele- vator starts 10 move toward floor 4. The relevant aspects of the corresponding dia- grams clearly are equivalent with respect to this scenario; you may wish to consider other possibre scenarios as well, From the preceding discussion, it should come as no surprise to learn that Figuee 12.7 was constructed from the scenarios. More precisely, the specific events of the scenarios were generalized, For example, consicer the fits: event of the scenario of Figure 12.3, User A presses the Up floor button at floor 3.’This specific event is generalized to en exbittary butioa (floor button or elevator button) being pushed. ‘Thea, there are two possibilities. Lither the button already is lit in which case noth- ing happens) or the button is unlit (in which case action mast be taken to process he users request). ‘To model this event, the Elevator Event Loop state is drawn in Figure 12.7. The case of an already lit button is modeled by tke do-nothing loop with event button pushed, button litin the top left-hand commer of Figure 12.7. The other case, an unit button, is modeted by the arrow labeled withthe event button pushed, button unlit lcading to state Processing New Request. From ovent 2 ofthe scenario itis clear thal the operation Turn on burton is needed in this state. Furthermore, the purpose of the user’ actioa of pressing an arbitrary button js to request an elevator (floor button) “orrequestan clevator tomove to a specific oor (elevator button), so operation Update requests also must be carried out in he state Processing New Request.Chapter 12. Object Oriented nave 387 ‘ovr consider event 3 of te sconaria, An elevator arrives at floor 3. This was gen- xalized to the concept of an abitrary clevator moving between floors. Tne motion of the elevatoris modeled by the event elevator moving in direction 4, floor Fis next and the state Determining If Stop Requested. But thore agein ae to pos bilities, either a request to stop at floocf or no sach cequest. In the Zormer case, corre> sponding to event no request to stop at fioor f, the elevator simply mus: be in the sate of Continuing Moving one more foor io diceerion d. In the latter case (corresponding te event user fas requested stop at floor f, fromthe scenario ofFig- ure 12.3 itis clear that itis necessary to Stop elevator (from event 3), and then Open doors and start timer (from events 4 and 5); state Stopping at Floor is needed to perfocm these actions. Also, similar to the Processing New Request state it be- ames appacent thet itis necessary slso to Update requests in state Stopping at Floor. [n addition, generalizing event 9 ofthe scenario lends othe realization thatthe floor button has to be tumed off if it is lit This is modeled by stats Turning OfF Floor Button, together with the two events cbave tho box reprosenting thet state, Simila:ly, generalizing event 14 ofthe seenario similarly implies thatthe elevator bur- ton has to be turned off if is lit, This is modeled by state Turning Off Elevator Button, together withthe to events above the box representing that state. s Generalizing event $ of the scenario of Figure 12.3 yields state Closing Eleva- tor Doors; generalizing eveat 10 yields state Processing Next Request. How- ever, the need for the site Going into Wait State aud the event no requests pending, doors closed is deduced by generalizing an event of difixont seenazio, fone in which the user exits from the elevator but no buttons remain Ii The statecharts for the other classes are zelatively siraigheforward and therefore left as an exercise (Problem 12.1). fos. Study (CARIESE The Test Workflow: Object-Oriented Analysis Atthis poins, the functional, enty class, and dynamic models appear tobe corapiete and the test workfiow resumes. The next step is 19 review the analysis wor'iow to date. Que component of this review, as suggested ia Section 12.5.2, is to use CRC cares, Accondingly, CRC cards are dled in for each of the entity classes, Button. Class, Elevator Button Class, Floor Button Class, Elevator Class, and Elevator Controller Class. The CRC card for Elevator Controller Class, shown in Figure 12.8, is deduced Srot the lass diagram of Figure 12.5 and the stat~ echast of Figure 12.6. In more detail, the RESPONSIBILITY of Elevator Con- troller Class is obtained by listing all the operations inthe statechart for Elevator Controtier Class (Figure 12.7), The COLLABORATION of the Elevator Con- troller Classis determined by exemining the class diagram of Figuce {2.6 end not- ing that classes Elevator Button Class, Floor Button Class, and Elevator ‘Class interact with class Elevator Controller Class.368 Part Two The Mitfons ofthe Sofware Lif le FIGURE 12.8 Tae frst eration of the CRCeard oe Elevator Controller lass. CASS Elevator Controller Class RESPONSIBILTY 1. Tum on elevator button 2. Tum cif elevator burton Turn on focr button. Turn off oor button Move elevator up are floor Move elevator down one floor ‘Open elevator doors and start timer | Cage elevator doors ater timeout Check requests Update requests COLLABORATION Elevator Button Class 2, Floor Button Class 3. Flevator Class Seevaure ‘This CRC card highlights two mejor problems with the first iteration ofthe object. oriected analysis 1. Consider responsibilty 1. Turn on elevator button. This command is ttally out of place in the object-oriented paradigm. From the viewpoint of responsibility: Aeiven design (Section 1.9), objects (instances) of Elevator Button Class az ‘responsible for tuming themselves on or off. Also, from the viewpoint of infor- uation hiding (Section 7.6) ze Elevator Controller Class shculd not have the knowledge ofthe interals of Elevator Button Class necded to numa ona ‘button, The correct esponsibility is ths: Sead a message to Elevator Button Class to tum itself 0. Similar changes are needed for responsibilities ? through 6 in Figure 12.8. Thoso six cocrections are reflected in Figure 12.9, the second it craton of the CRC card for te Elevator Controller Class. 2, A-class has been overlooked. Returning to Figure 12.8, consider responsibility 7 ‘Open elevator doors and start timer. The key concep! here is the notion of state, The attributes of a class sometimes are termed state variables. The rea- son for this teeaiaology is that, in most object-oriented implementations, the state ‘of the product is determined by the values of the ettributes ofthe various compo- neat objec. The statechart has many featizes in common with a finite state mac chine, Accordingly ts not surprising that the concept of sic plays an igortant role in the object-oriented paradigm. This concept can be used to help determine ‘whether a component should be modeled as a class. Ifthe component in question possesses a stato that is changed during exteution of the implementation, then it ‘probably should be modeled as a class. Clealy, the dears ofthe elevator possess ‘state (open or closed), and Elevator Doors Class therefore should be a class.FIGURE 129 The second iteration of the ERC card for the ciass Elevator Controller Class. CUS Elevator Controller Class RESPONSIBLITY 1, Send message to Elevator Button Class to turs on button 2, Send message to Elevator Button Class to tun off button 3 Send message to Floor Button Class to turn on button 4, Send message to Floor Button Class to tien off button 5. Send message to Elevator Class to move up ane floor 6. Send message to Elevator Class to move down one floor 7, Send message to Elevator Doors Class to open 8. Start mer 9, Send message to Elevator Doors Class to close after tmeout 10. Check requests 11. Update requests COLLABORATION 1, Elevator Button Class (subclass) 2. Floor Button Class (subclass) 3. Elevator Doors Class | 4, Elevator Class | There is another reason why Elevator Doors Class should be « class. The object-oriemed paradigm allows the state to be hidden within an object and hence protected from unauthorized chenge. If there is an Elevator Doors Class object, ‘the only way that che doors of the elevator can be opensd or shut is by sending a mes- sage (0 thet Elevator Doors Class object. Serious accidents can be caused by opening or closing the doors of am elevator st the wrong time; see Justin Case You ‘Wantod to Know Box 12.3. Thereiore, for certain types of products, safety consider- ations should be ated to the otber strengths of objects listed in Chapters 7 and 8. Adding Elevator Doors Class means that responsibilities 7 end 8 in Fig ure 12.8 need to be changed analogously to responsibilities 1 through 6. That is, ‘messages should be sent to instances of the Elevator Doors Class io opea and close themselves. But there is an additional complication. Responsibility 7 is Open elevator doors and start. timer. This must be split into two seperate responsibilities, A mescage indeed must be sent to Elevator Doors Class to open. However, tu timer is part of the Elevator Controller Class, and stsrting the timer therefore isthe responsibility of the Ele- vator Controller Class itself. The second iteration of the CRC card for Eleva tor Controller Class (Figure 12.9) shows that this separation of responsibilities has been achieved satisfactorily : In addition to the v0 major problems highlighted by the CRC card of Figuce 12.8, responsibilities Check requests and Update requests of Elevator Controller Class zequire the atixibute requests be added to Elevator Controller Class. At | this stage, requests are defined simply to be of type requestType; a data stractaze for requests will be chosen during the design workdlow,FIGURE 12.10 ‘The tied ftoration ofthe class diagram forthe elevator robles case study some year ago, | was oa the 0th Aor ofa bu bg, wating impatient Yorn elevator. “The doars opened, I started to step forward—only no elovator was thers, What saved my life was the tota blackness | aw as | was about t9 step ino thé elevator shatt, andl insti: tively realized that something wes wrong. Perhaps, if that elevztor control system had been develoved using the’ objezt-riented paradigm, the inappropriate opening of the doars.on.the 10th floor might have been avoided. ‘The corrected class diagram is shown in Figure 12.10. Having rodified the class diagcam, the use-case diagram and statecharts must be reexamined to sev if they, oo, need farther tefinement. The use-case diagram clearly sll is adequate. However, the ‘operations in the statechart of Figuse 12,7 must be modified ta reflect the responsi bilities of Figure 12.9 (the second tteration of the CRC card) anc not Figure 12.8 (the first iteration). Also, the set of statecharts must be extended to include the additional ‘lass. The seatarios need to be updated to reffect these changes; Figure 12.11 shows fae second iteration of the scenario of Figure 12.3. Even afterall these changes have been made and checked (inchiding the modified CRC cards), i still may be necessary during the object-oriented design workflow to return to the object-oriented analysis -worldiow and revise ont or more of the analysis arifucts. However, at this stage it ap- ‘pears thet the entity classes forthe elevator problem case study have been correctly extracted, Button Class ‘uminated : Boolean Elevator Button Class| ir Button Class | fam = 2 controls controls 1[Reator cniroer | [Hevaterdoor cass en reguas request pe enc 400° open Boban i coatrels Elevator ClassChapter 12 ObjecrOriemd Anabyis 391 FIGURE 12.11 ‘The sevond tortion ofa nomnal soeuario for the elevator problem case study. 1. User A presses the Up floor bution at oor 3 to request an elevator User A wishes te goto floor 7. 2. The loor button informs the elevator controler that the gor burton has been pushed 3, The elevator controller sencis a message to the Up floor button to turn itself on. 4, The elevator controller sencs a serias of messages to the elevator to move ise up to floor 3. The elevator contains User 8, who has entered the elevater at floor 1 and presied the eievator buttan fer floor 9. 5. ‘he elevator controler sends a message to the elevator doors to open themselves. 6. The clevator controller stars the time. User A enters the elevator. 7. User A presses elevator button for floor 7. 8, The elevator button informs the elevator controller thatthe elevator button has been pushed. 9 The levator controls sends a message to the elevator button for Hor 7 9 tun itself on 10, The elevator controller sends a message to the elevator doors to close themselves | after a timeout 11. The elevator controller sends @ message to the Up floor button to tum ise off. | 12. The elevator controller sends a series of messages tothe elevator to move itsll, | upto floor 7. | 13, The elevater controller sends @ message to the elevator button for floor 7 to turn isel oft 14, ‘The elevator controller sends a message to the elevator doors to open themselves to allow User A to ext frors the elevator. 15, The elevator controller starts the timer. User A exits from the elevator. 16. The elevator controller sends a message to the elevator doors to close themselves aera timeout. | 12, The elevator contrller sends a seres of messages to the elevator to move Ise Upto floor 9 with User B. 12.8 _Extracti ‘Unlike entity classes, boundary classes aze usually easy to extract. In general, each input screen, output screen, and printed report is modeled by its own boundary class. Recall that 4 class incorporates attributes (data) and operations. The boundary class modicting (say) & ‘printed repor incorporates all the various dete items that cen be included inthe report and the various operations carried out to print the report, Control classes are usually as easy to extract as boundary classes. ln general, each nom stivial computation is modeled by a contro class. ‘We now illustrate entity, boundary, and contol class extraction by extracting the classes of the MSG Foundation case study, The starting point is the use-case diagram of Fig- “ure 1042, reproduced here as Figure 12.12. the Boundary and Control Ci:392 Par Two The Mirklows of he Saftare Lif Cte FIGURE 12.12 TAS Found: 4 “Tes seventh Information System | iteration of the ~ | dings of Eecinace Sends) | dings ‘oka fos Foundation case say Investment a MN Msc staff Borrowers ‘Member pass Botinated gansal Operating, ‘Expenses Produce @ Report | The Initial Functional Mode! The MSG Foundation Case Study As described in Section 12.2, functional modeling consists of finding the scenacios of ‘the use cases. Recall that a scenario isan instance ofa use ease. Consider the ase case Manage a Mortoagé (Figures 10.32 and 10.33). One possible scenario is shown in Figure 12.13, Thete is a change in the anmmual real-estate tax to be paid on a home for which the MSG Foundation nas provided a mortgage. Because the borrowers pay this tax in equal weekly payments, any change ia the real-estate tax must be entered inthe relevant mortgage record, so thatthe total weekly installment (and perhaps the grant} can be adjusted accordingly. The normal portion of the extended scenario models ax. MSG staff member eccessing the relevant mortgage record and changing the annual real-estate tax. Soraetimes, however, the staff member niay not be able to locete the corest morigege stored in the software product because he or she hasChapter 12 ObjecrOriewed Anais 393 FIGURE 12.13 An extended seesario of managing a mortgage. ‘An MSG Foundation staff member wants to update the annual real-estate tax on ‘home for which the Foundation has provided a mortgage, i 1, The staff member enters the new value of the annual real-estate tax. \ 2. The information system updates the date on which the annual real-estate tax was lest changed. Possible Alternative A, The staff member enters the mortoage numer incorrectly FIGURE 12.14 Another extended scenario of managing « mortgage. “There is a change in the weekly income of a couple who have borrowed money from the MSG Foundation. They wish to have zheie weeidy income updated in the Foundation records by an MSG staff member so that their mortgage payments will be comectly computed. i The siaif member enters the new velue of the weekly income. 2. The information system updates the date on which the weekly Income was last changed, Possible Alternatives | 2 Tesafmentr enn the noag runt nse B, The borrowers do not bring documentation regarding their new income. centered the woorigage murber incorrectly. This pessibility is modeled by the excep- ‘ion portion of the scenario. A second scenario corresponding to the Manage @ Mortgage use case (Fig tres 10.32 and 19.33) is shown in Figure [2.14. Here the borrowers? weekly income bhas changed. They would like this information to be reflected in the MSG Foundation records so that their weekly installment can be correctly computed. The normal portion of this extended scenario shows this operation proceeding as expected, The abnormal portion of this scenario shows two possibiltes, First, 23 in the previous scenario, the staff member may enter the mocigage number inoarrestly. Second, the borroners may not bring with them adequate documentation to support theie claims reganding their income, in which ease the requested change is not impleniented, ‘A third scenario (Figure 12.15) is an instance of use case Estimate Funds Available fcr Week (Figure 10.42), This scenario is directly derived from the | description of the use casc (Figure 10.43). “The scenarios of Figures 12.16 and 12.17 ae instances of use case Produce @ Report. Again, these scenatios are directly derived from the corresponding de- ‘eriptioa ofthe use case (Figure 10.39). The remaining scenarios ace equally straght- ‘forward and are therefore left as an exercise (Probslems 12.8 and 12.9)394 ParcTwo The Werifows ofthe Software Lie Cple FIGURE 12.15 A scenario ofthe Estimate Funds av lable for Week usecase, ’an MSG Foundation staff member wishes to determine the funds available for mortgages this week 1. Foreach investment the information system extract the estimated annual return on that invesirent. t sums the seperate returns and dviges the result by 52 to yield the estimated investment income forthe week 2. The information system shen extracts the estimated ennval MSG Foundstion operating excerses and divides te result by 52. 3. For each mortgage: . 3.1 The information system comptes the smaunt tobe paid this week by adding the principal and interest payment 0 dnd ofthe sum of the annual reahestate tax and the annual homeowners insuiance prersium. 3.2 It then computes 28 percent of the couple’s current gross weekly income. 3.3 ithe esult of Step 3.118 greater than the result of Step 3.2, then it determines she morgage payment for the week asthe result of Sep 3.2, end the amount of the grant for this weak as the diflerence between the result of Step 3.1 and the result of Step 3. 3.4 Otherwise, fetakes the mortgage payment for this week as the result of 9 31, ane there sna gram forthe week. 4. The information system sums the mortgage payments of Stes 3.3 and 3.4 to yield the estimate total merigage payments forthe week, 5. It sums the grant payments of Step 3.3 to yield the estimated total grant payrnents for the week, 6, The information system acds the results of Steps 1 and 4 and subtracts the results of Steps? end 5. Trib athe total amount avalable for morgeges var the current, week. 7. Fal the sofoware procct pent the total amount avaible for new morigages dluriag the curent week FIGURE 12.16 scenario ofthe Produce a Reper= ‘An MSG staff member wishes to print alist of all mortgages. 1. The siaif member requests a report listing all mortgages. FIGURE 12.17 Another somario ofthe Produce a Report use case, ‘An MSG staff member wishes te print a fist ofall Investments. 1, The staff member requests a report listing all investments,Chapter 12 Onier Onenad Anes 395 fase Study ee "8 The Initial Class Diagram: The MSG Foundation Case Study “The seuond step is class modeling, The aim of this sep is to extract the entity clases, evermine thor interelationships, ard find their ateibutes, The best way to sazt his step is usualy to use the two-stage noun extraction rtd (Seaton 12.5.1). Tn Stage 1 we describe the software product in a single paragreph. [a the case of the MSG Foundation ease study, a way to 60 this is ‘Weekly zeports are tobe prited showing how much money is avellabe for mortgages. Jn addon, lists of investments and mortgages must bs printed on demand. ay ae = ee ese = In Stage 2 we identify che nouns ia this paragraph. For clasty, the nouns are printed in sans serif type. “Weekly reports are to be preted showing how much money is available for mortgages. ‘In addon, ists of investments and mortgages must te printed on demand, “The nouns ace report, money, mortgage, list, and investment, Nouns report and list are not long lived, so they are unlikely to be entity classes (report will ely tum out to be a boundary class), and money issn abstract noun. This caves two can- didate ensity classes, tamely, Mortgage Class and Investment Class, as shown in Figure 12.18, the first iteration of the initial class diagram. Now we consider interactions between hse two entity classes, Looking at tho de- scriptions of use cases Manage an Investment aidMenage a Mortgage (Figures 1031 and 1033, respectively) it appears thet tue operations performed oa the tea entity classes aze likely to be very similar, neinely, insertions, deletions, and modifications. Also, the second iteration of the description of use cass Produce @ Report (Figure 10.39) shows all the members of both entity classes have to be printed en demand. In other words, Mortgage Class and Investment Class should probably be subclasses of some superclass. We will call that superclass Asset Glass, because mortgages and investments are both assets of the MSG Foundation. ‘The resulting secouc iteration of the initial class diagram is showm in Figure 12.19 ‘A useful side effect of constructing this superclass is that we can once again reduce the number of use cases. As showin in Figure 12.12, we currently have five use FIGURE 12.18 The fist iteration ofthe initial ‘lass diagram of the MSG Foundation case study _Morigage Cass | [Investment Gass396 Part Two The Mention ofthe Sofware Life Cele FIGURE 12.19 ‘The second sation of the suite class diagram of tie SG Foundation case study FIGURE 12.20 The cighth iteration ofthe diagram of the MSG Fouidaton case study. The new se cass, Manage an asset, is shaded, Mortgage Cass Tnvestment Class Information System Gocinate nds ‘Bvailable 20r ‘Weeks A Borrowers MSG State Member Produce a Report cases, including Nanage 2 Mortgace and Manage an Investment, How- ever, if we consider a mortgage or an investment to be a special case of an asset, we can combine the two use cases into a single use case, Manage an Asset. The eighth itertion of the use-case diagram is shown in Figure 12.20. The new vse case. is shaded. Now the attributes are added, as shown in Figure 12.21 ‘The phrase “iteration and incrementation” also includes the possibility ofthe weed for a decrementation in what has been developed to date. There are two reasons for such 2 decrease. Fist, if mistake is made, the best way to correct it may be to backtrack to an earlier version of the software product nd find a better way of ‘performing the step that was incorrectly carried out. When backwracking, everythingChapter 12 ObjeorGreatd Anais FIGURE 12.21 Attributes adéed to the second iteration ofthe inital class diagram of te MSG Foundation case study. ‘Asset Class, aserNumber 1 Mortgage Clase InvestmentNare lastNameOfMortgeaces estimatedannaalRetura originaPurchasoP rice sateUpdated sateMoregagelssuee \weekyPrincpalancinterestrayment combined Weskgineome ateWVeekivincometip dated annuaealEstateTox {ateAnrualReaesteeTaxUpdated annualsuraneePremium : selected, update estimated annual operating expenses selected, produce a re- port selected, and quit selected, (An event causes a transition between states) ‘When the system is in state MSG Foundation Event Loop, uny onc of the five events may occur, depending on which option the MSG staff member selects from the mena, shown i Figure 12.23, thet will be incorporated in the target soft- ware product. (The C++ end Jave iniplememations of the MSG Foundation case study givea in Appeadices H and I, respectively, ys a textual interface cater han a {geapbical user interface (GUD. That is, instead of clicking on a box, as shown in Fig- tue 12.23, the uscr types ina choice, as shown in Figure 12.24. For example, the user types 1 to fstimate funds available for week, 2 to Manage an asset, and so on. ‘The reason the implementations in Appendices H and I use 2 texiual interface, suck as Figure 12.24, is that textual interface can be run on all computers; a GUI gener- ally needs special softwere.)Chapter 12 Obpect Oriented Anaiyis 399 Suppose thatthe MSG staff: member clicks or the choice Manage on asset in the menu of Figure 12.23. The event manage an asset selected (second from the left below the MSG Foundation Event Loop box in Figure 12.22) has now oc- curred, so the system moves ftom its curtent state, MSG Foundation Event Loop, to he state Managing An Asset. The operations that the MSG staif mem- ber can perform in this state, namely, Add, delete, or modify a mortgage or in- vestment, appear below the linc in the box with rounded comters. Once the operation has been performed, the system returns to the staiz MSG Foundation Event Loop, as shown by the erzows, The bebavior ofthe rest of the statechartis equally stmnightforvard, In summary, the software product moves from state to state. In each slave, the MSG staff member can perform the operations supported by thet state, 2s listed below the line in the box with rounded corners that represents the state, This contin- ‘ues until che MSG staff member clicks on menu choice Quit when the software prod- ucts ia the siate MSG Foundation Event Loop. Atthis time the software prod ‘vet enters the Saal state (represented by the white ciscle containing the small black circle), When this state is catered, execution of the staischari terminates; recall that the statochart is a model of the execution of the target software product, ase Study me Revising the Entity Classes: “ The MSG Foundation Case Study The initial functional model, the initial class diagram, and the intial éynamie model have now besn completed. However, a check of all three models reveals that some- thing has been overlooked, Look at the initial starechart of Figure 12.22 and cousider state Updating Esti- mated Annual Operating Expenses with operation Update the estimated annual operating expenses. This operation bas to be performed on data, namely, the current value of the estimated annual oparating expenses. But where is the value ofthe estimated annual operating expenses to be found? Looking at Figure 12.21, it ‘would have been a serious error to have it as cn attribute of Asset. Class or either of its subclasses, On the other hand, currently there is only one cless (Asset Class) and ‘ts two subclasses. This means that the only way a value can be stared on a long-term basis is as an atiribute of an instance of that class o its subclasses. The solution is obvious: Another catity class is needed in which the value of the estimated annual operating expenses can be stored. In fact, other values need to be stored as well; the result is shown in Fignce 12.25. new class, MSG Application Class, has been introduced in which the vacious attributes shown in the top box in ‘the figure can be stored. In addition, tae MSG Application Class will be assigaed the task of starting the execution of the rest of the software product. ‘Now the class diagram of Figure 12.25 is redraum to reflect the stereotypes. This is shown in Figure 12.26. Ail four classes are entity classes. The entity classes seem to be correct, atleast for now. The next step is to determine the boundary classes and control classes.400. Part Two The Hrifous ofthe Sfimure Life ele FIGURE 12.25 The third iteration ofthe inital class diagram of the MSG Foundation case smd. MSC Application Class estimstedAnnyolOperatingExpenses dateEtimatedériaualO perating Expenses Updated avalableFuncsForiveek expeciedAnnusitetumOntnvestments datebxpectedAnnualRewumiOninvestmentsUpdated expectedGrantsFoWeek expectedNorigagePaymentsFoeWeek Asset Class sasetNumber —_ the seroouypes, Aptcaion ‘Class O tnvestment ‘clase Investment Clase Mortgage Class InvestmentName lastNameotMortgagess cesimatedAnnualReturs riginalPurchasePrice dlatetstimatedResu Updated dateMoricugelssued ‘weekiyPrincpalandlnterestPayment combinedWeekiyincame GateCombinecWethiyincomeLpested annvalRealesatetax ‘ated nualRealEstateTaxUpdated lannwallasurancePreriven ‘atednnualinsurancePremiumUpdated FIGURE 12.26 Figure 12.25 reérawa to show Mortgage ‘Clare ae(Chapter 12 Objece Oriented Amalie 40% ase Study 3 Extracting the Boundary Classe: The MSG Foundation Case Study Extracting entity clastos is usually considerably harder than extracting boundary classes. Affcr all, entity classes gonoraly have interelationshins, whereas each input ‘sereen, output sereea, and printed report is usually modeled by an (independent) ‘Loundary oless, as pointed out in Section 12.8. In view ofthe fact thatthe target MSG Foundation software produet appears to be rwlatively stnightforward (at least at tis early staze of the Unified Process}, itis tea sonable to try to have just one scrcon that the MSG staff member ean use forall four usecases: Ratimate Funds Available for Week,Manage an Asset, Update Estimated Annual Operating Bxpenses, and Produce a Repost. As more is learned about the MSG Foundation, itis certainly possible thet this onc screen may bave lo be refined into two or more screens. But the initial class ‘extaction has just the one screen class, User Interface Class. ‘There are three reports that have to be printed, the estimated funds forthe week re ‘por: and the two asset reports, namely, the complete listing of ell mortgages or of all investments. Each of these bas to be modeled by 2 separate boundary class because the content of each report is different. The four corresponding initial boundary slasses are then User Interface Class, Estimated Funds Report Class, Mortgages Report Class, and Investments Report Class. These four classes ere displayed in Figure 12.27. URE T227 trie Ga est cs | tomate and Report Cs fossa | Morgage toon Cs eens | ste Repont Cas study. fase Study Extracting the Control Classes: The MSG Foundation Case Study CContol clases are generally as easy-to extract as boundary classes because each ‘nontrivial computation js almost always modeled by a control class, a stated in Soo- ‘ion 12.8, Forthe MSG Foundation case study, ture is just one computation, namely, estimating the funds avaiable for the week. This yields the inal control cless Esti- mate Funds for Week Class showa in Figure 12.28,402 Par Two The Wortfows ofthe Safran Lie Cole FIGURE 12.28 The iital conto! ‘las of the MSG Foundation cae study. Estimate Funds for Week Class The next step is to check all three sets of classes: entity classes, boundary classes, ‘and control classes, Careful examization of ths classes yields no obvious discrepancies, Having completed cless extraction, we now return to the Unified Process. a fos Study 19, Use-Case Realization: The MSG Foundation Case Study ‘A.use ease is a description of am interaction between an actor and the software prod uct, Use eases ar fitt utilized atthe beginning ofthe software life eyele, tha is in the requirewents workilow: During the analysis and éesiga workflows, more details are added to each use ase, including a description ofthe classes favolved in carry ing out the usecase, This process of exiending and refining use cxscs is called use ‘case realization. Finally, during the implementation workflow, he use cases are ‘implemented in code. This icnminology is somewhat confusing, because the verb realize cane used in ‘atleast three different senses: + Understand (Harvey slowly began to reclize that he was in the wrong classe ‘oon : f + Receive (“Ingrid wil realize a profit of $43,000 onthe stock trecssction”) + Acgomplish (Janet hopes o realize her dream of stating a software developanent organization). In the phrase realize 2 usecase the word realize is used inthis lst sens that sit means to accomplish (or aoheve) the use case, An interaction diagram (sequence diagram or collaboration diagram) depicts the realization of a specific scenario of the use case. We first consider the use. case Sstinace Funde Available for Week 12.15.1 Estimate Funds Available for Week Use Case The use-case dingram of Figure 12.20 shows all the use cases. These include Es Funds Available for seek, which is shown separately in Figure 12.29, ‘The description of that use case was given in Figure 10.43, whichis reproduced bexe 1s Figure 12.30 for convonicnce. From the description we deduce that, a reflected in the class diagrain of Figure 12.31, the classes that exter into this use case are User Interface Class, wich models the user interface; Estimate Funds for Week ‘Class, the conte! class that models the computation of te estimate ofthe funds chatChapter 12 Objecs Oniemed Arabic 403 FIGURE 12.29 The nacimare punts peiaie ©) for weexue = Tt MSG Foundation Information System Brief Description The Zetimate Funde Availat staff member to estimate how much money the Foundation has available that week to fund mortgages. Step-by-Step Description 1. For each investment, entrac the estimated annual return on that investment. ‘Summing the separate returns ane divicing the result by 52 yields the estimated investment incorne forthe week. 2. Determine the estimated MSG Foundation operating expenses forthe week by ‘extracting the estimated annual MSG Foundation operating expenses and dividing | _ by 52, 3. For each mortgage: 3.1 The amount to be paid this week isthe total ofthe principal and Interest payment and dnd of the sum ofthe enaual real-estate tax and the annual homeowner’ insurance premium. 3.2 Compute 28 cerceft of the couple's current gross weekly income, | 313 ifthe result of Step 3.1 is gresterthan the result of Step 3. then the mortgage ‘payment for this week i the result of Step 3.2, andthe amountof the grantfor this weekis the diference hetween the rest of Step 3.1 and the resuf of Step 3.2. 3.4 Otherwise, the mortgage payment for this week is the result of Step 3.1, and there is no grant this week. 4, Summing the mortgage payments of Steps 3.3 and 3.4 yields the estimated total mortgage payments for the week. 5. Summing the grant payments of Step 3.3 yields the estimated total rant payments for the week 6 Ad the results of Steps 1 and 4 and subtract the results of Steps 2 and 5. This is the al amount avaiable for mortgages for the current week. . 2. Print the total amount available for new mortgages during the current week are available to find morrgages during that week; Mortgage Class, which models ‘the estizzated grants and payments for the week; Investment Class, which moc- cls the estimated return on investments for the week: MSG Application Class, ‘which models the estimated operating expenses for the week; and Estimated Funds Report Class, which models the printing of the report.604 Pare Two The Woifiwe ofthe Sofware Life Cee FIGURE 12.31 Chass diagsaen = 2AO—O Msc Estimate Funds Foundation case for Week Class sdy, O-'0 MSC Application Estimated Funds lass Report lace Figure 12.31 iss class diagram. Tati, it shows the classes that pertiejpate im the realization of thowse case and their relationshios. A working software prodact, onthe other hand, uses objects rather than classes. For example, a specific mortgage cannot bbe represented by Mortgage Class but rather by an object, a specific instance of Mortgage Class, denoted by; Mortgage Class. Ais, the clas diagram of Fig- ure 1231 shows the participaling classes in the use case and their relationships it Goes not show the sequence of events as they eccur, Something moze is needed 10 raodel a specific scenario such as the scenario of Figure 12.15, reproduced here as Figure 12.32. ‘Now consider Figure 12.33. This figure is @ collaboration diagram. It therefore shows the objects that interactas well a the messages that ars sent, mumbered inthe order in which they are sent. A collaboration diagram éepicts a zealization of 2 spe- cific scenario of a use cass, Is this case, Figure [2.33 depicts the scenario of Figure 12.32. In more detail, in the scenario the staff meraber wants to compute ths fands available for the work. This is represented by message 1: Request estimate of junds available for week fom MSG Staff Member co : User Interface ass, sn instance of User Interface Class. ‘Next, his request is passed on to : Estimate Funds for Week, Class, an in- staace ofthe control clas that actually performs the calvalation. This is represented ‘by message 2: Trensier request. Four separate financial estimates sre now determined by : Esti Funds for, Week Class, In step 1 of the scenario (Figure 12.32), the estimated annual ream on investments is sumumed for each investunent and the result divided by $2. ThisChapter 12 ObjecnOnenred arable 405 FIGURE 12.32 Asconario ofthe Retinate Funds Available fox Weekuse cate 'An MSG Foundation staff member wishes to detesmine the fends available for mortgages this week 1. Foreach investment, the information system extracts the estimated annual retuen fon that investment. ft sums the separate returns and divides the result by 52 to yield the estimated investment income for the week. 2. The information system then extrects the estimated annual MSG Foundation ‘operating expenses and divides the result by $2. 3. For each mortgage 3.1 The information system computas the amount to be paid this week by adging the principal and interest payment to gd of the sum of the annul real-estate tax and the annual homeowner’ insurance premium, 32 It then computes 28 percent of the couple's current grass weekly income. 3.3 I the result of Step 3.1 is greater than the result of Step 3.2, then it determines the mortgage payment for the wack as the result of Step 3.2, andithe amount ‘of the grant for this week asthe difference between the wesult of Step 3.1 and the result of Step 3.2. 3.4 Otherwise it takes the mortgage payment for this week as the result of, Step 3.1, and there is no grant for the week. 4. The information system sums the mortgage payrnents of Steps 3.3 and 3.4 to yield the estimated total mortgage payment for the week, 5. Ie sums the grant payments of Step 3.3 to yield the estmated total grant payments for the vieek, 6. The information system acids the results of Steps 1 and 4 and subtracts the resuks ‘of Steps 2 and 5. This is the total amount available for morcgages for the current week 7. Final, the software produet prints the total amount avaiable for new mortgages during the current week. extraction of the estimated weekly return is modeled in Figure 12.33 by message 3: Request estimated return on investments for week from : Estimate Funds for Week Class 10 : Investment Class followed by message 4: Return esti- mated weekly return on investments in the reverse direction, thet is, back to the object that is controling the computation, ‘n step 2 of the scenario (Figure 12.32), the weekly operating expenses are esti- ‘mated by taking the estimated annual operating expenses and dividing by 52. This ox- traction of te weekly return is modeled in Figure 12.33 by message 5: Request es- timated operating expenses for week stom : Estimate Funds for Weel Glass 10 i MSG Application Class followed by message 6: Return estimated operating expenses for week in the other direction. In steps 3, 4, and 5 of the svenario (Figure 12.32), two estimates are determined, namely, the estimated grants for the week and the estimated paymexts forthe week. This is modeled in Figure 12.33 by message 7: Request estimated grents and payments for week from : Estimate Funds for Week Class to : Mortgage Class and by message 8: Retum estimated grants and payments for week in tae reverse direction,405 Past Two The Workflows ofthe Software Le Gyo FIGURE 12.33 A collaboration diagram of the realization ofthe seennsi of Figure 12.32 ofthe Estimate Funds Available for Weekuse ssse of she MSG Foundation eave sd, 3: Request expecta payments tor foot es Bvcrens sweet ‘ere 9: Compute etnatoc Q “acer QO vague Zio ae Clase srount sealable 1s Regu Nipyeeebe Ferweek “4 Rum expacted wey cxipate ee cet in ret anneestren fare avaliable raster ! oO ferweee KO) en O A 1S: Dapley suc vaste sce we se oERien ae “CER ton ate ‘Member’ messce wwesage smmunaercrtrains | pone apd opeing contre sete seamen cote {lf 1: Transfer estimated ameunt mresage Balabie for week tates mind 2 asm Sw / Aeaiaton Srpssn Clase ‘Now the arithmetic computation of step 6 of the scevario is performed. This is spdeled in Figure 12.33 by message 9: Compute estimated mount available Jor week. This isa self-call, that is,: Estimate Funds for Week Class tll it- selfto perform the calculation, The result of the computation is stored in: MSG Ap- plication Class by message 10: Transfer estimated amount available for week ‘Next, the result is printed in step 7 of the sconario (Figure 12.32). This is modeled sn Figure 12.33 by message 11: Print estimated amount available from : MSG Application Class to : Estimated Funds Report Class, Finally, an acknowledgment is sent to the MSG staff member thet the task bas been successfully completed. This is modeled in Figure 12.33 by messages 12: Send successful completion message, 13: Send successful campletion message, 14: Transfer successful completion message, and 15: Display successfut comple © tion messageChapter 12 Dbjsen Orion Anaiest FIGURE 12.34 ‘The low of events of the eollaboration diagram of Figure 12.33 of the realization of ie soenatio of Figue 12.32 of tie BStimaze Funds Available for weekuse case ofthe MSG Foundation case study. ‘Ary MSG staif member requests an esimate of the funds avallable for mortgages for the week (1,2). “The information system estimates the return on investments forthe vieek (3, 4), the operating expenses | for the week 5, 6), and the grants and payments for the week (7, 8). Then it estimates (9), stores (10), and prints ous (11-15) the funds available for Ue week, No client is going to approve the specification document unless he er she under- stands presiscly wha: the proposed! software product will do. For this reason, a written descxipticn ofthe collaborarion diagram is essential, This is showm in Figure 12.24, the flow of events. Finally, the equivalent sequence diagram of the realization of the scenario is shown. in Figure 12.35. When constructing a software product, either a collaboration diagram or a sequence diagram mey prove to give better insight of a realization of 9 use case, In some situations, both are needed to ect a full under- standing of a specific realization of a given usc case. Taat is why, in this chepter, every collaboration diagram is followed by the equivalent sequence diagrara. The 5° ‘quence diagram of Figure 12.35 is fully ecuivalent to the collaboration diagram of Figure 12.33, soit flow of events is also shown in Figure 12.34. “The strength of sequence diagram is that it shows the flow of messages unam- ‘viguously. The order of the messages is particularly clear, as are the sender and re- ceiver of each individual message. So, when the transfer of information is the focus of attention (which is the case for much of the ime when performing the analysis ‘worksow), a sequence diagram is superior to a collaboratioa diagram. On the other hand, the similarity between a class diagram (such as Figure 12.31) an¢ the collabo- ration diagram that realizes the relevant scenario (Such as Figure 12.33) is stroag, ‘Accordingly, on those gecasions when the developers aze concentrating on the classes, «collaborstion diagram is gonerally more usoful than the equivalent sequence diagram, Surnmarizing, Figures 12.29 through 12.35 do not depict a random collection of UngL artifacts. On the contrary, these figures depict a uss case and artifacts derived from that use case, In more derail: + Figure 12.29 depicts the vse case Bstimate Funds Available for Week. ‘That is, Figure 12.29 models all possible sets of intersetions, between the actor MSG Staff Member (en entity that is external to the software product) and the MSG Foundation software product itself, thet relate to the action of estimating funds available for the week + Figure 12.30 isthe description ofthat use case; that is, it provides a writen account oft details of the Eetimete Funds available Zor Weelcuse case of Figure 12.29, . + Figure 12.31 is a class diagram showing the classes that realize the Est inate Funds Available for Weekuse case. The class diagram depicts the classes that are needed te model all possible scenarios of the use case, together with theit interactions. us seAOE Part Two The Hoviffows of the Software Life pete FIGURE 12.35 A sequenos diagram of the realization of the socnario of Figure 12.32. of io Zt mate Funds Available for Week use ease af the MSG Foundation case study. This soquence diagram is fully equivalent to the collaboration diagram of Figure 12.33, so ics flow of events is also sbown in Figure 12.34, SOO OOOO Weer Estimated ann laterface epteation unde Member last Report Glas Tunes avaiable ot week [3s Request eqpecied ‘atu on fvest ‘ents forweek | “4: Reurn expected} return on vest ren for wees |s:Recusstexpecte operating i expenses tor week | 6: Reture expecta oneatng | Spend for wack Y cost expected grants art payments for wee | 8: Return expected grants ane payiners for week | comaae eimates amount pralabe far wees Io:Tonster exsmetee amount "waibie for week Mi Frint estimated amount | availabe ' EL IeeS TI \2Send sxcestcompl | ‘tion message 113: Send successful completion | 4 ESE message : ¢ Ta Teanstersuce: | «stu! complesion roessage [stip weet SEP econ toFIGURE 12.36 Thewarace an Reset use ease, FIGURE 12.37 Description of Be Manage: an Reset tse case Chapter 12 ObjeerGrieted Amalie + Figure 12.32 is a scenario, that is, one specific instance of the use case o: ure 12.29. + Figure 12.33 is a collaboration diagram of the realization ofthe soenario of Fig- le 12,32; that i, it depicts the cbjects and the messages sent between them inthe realization of that one specific scenario, + Figure 12.34 isthe flow of events ofthe collaboration diagram ofthe realization of the scenario of Figure 12.32. That i, just as Figure 12.30 iss written description of the Escinate Funds Available for Week use case of Figure 12.29, Fig- ure 12.34 ise written description of the realization of the scenario of Figure 12.32. + Figure 12.35 is the séquence disgram that is fully equivalent to the collaboration diagram of Figure 12.33, That is, the sequence diagram. depicts the objects and the sessages sent between them in the realization of the scenario of Figure 12.32. Its flow of events is therefore also shown in Figure 12.34. ie {thas been stated many times in this book thatthe Unified Process is use-case dri- ven, These bulleted items explicitly state the precise relationship between cach of the artifacts of Figures 12.30 through 12.35 and the use case of Figure 12.29 that under- lies each of them, 12.18.2 Manage an Asset Use Case ‘Thetianace an Asset use case is shown in Figure 12.36 and its description in Figure 12.37. A class diagram showing the classes that realize the Manage ar. Ascot use case is shown in Figure 12.58. Initially it was assumed that onty one control class sc {ans & a a ‘Thewanage an Asset use case enables an | MSG Foundation staff member to add and delete assets and manage the portfolio of assets (nvestments and mortgages). Managing a mortgage includes updating the weekly income cof a couple who have borrowed! money from the Foundation. ‘Step-by Step Description 1. Add, modify, or delete an investerent or mortgage, or update the borrower's ‘weekly income. 408410 Part Two FIGURE 12.38 ‘Achass diagram, showing tne Manage an of tie MSG Foundation ease study. FIGURE 12:39 ‘Ascenso of tewanace: an Asset use The Morfions of te Sofware Life Cle the borrowers tl the | MSG staff member their iyo | eutrent wey income. oO wemane 4 oS xy User Interface Manage an wecsnt tra oom O Investment, ‘class [aa MSG Foundation staff member wants to update the enrual feahestate taxon a homsfor wich the Foundation has provided of a mortgage: 1. The staff member enters the new value of the annual real. estate tax. 2, The information systern updates the dace on w real-estate tax was last changes. the annual is needed (see Figure 12.28). However, Figure 12.38 shows tat 2 second covtol class, Manage an Asset Class, is require; additional control clases may have (o be added is subsequzat iterations. The normal part of the extended scenario of Figure 12.13 of the use case Manage a Morzgage (and hence of Menage an. Asset) is reproduced as Figure 12.39, In his scenario, an MSG staff member updates the ancual real-estate tax oa a mort- aged home and the software product updates toe date on which the tax wes last changed. Figure 12.40 is the collaboration Giagram ofthis soznaio. Notice that ob- ject Investment Class does not play an zctive role in this coliaboretion diagram ‘because the scenatio of Figure 12.39 does not involve an iawestmet, only a mort- gage. Also, the Borrowers do nt play a role in this scenario either. The flow ofchapter 12 Obect-Oriened Anaieie 412 FIGURE 12.40 A collaboration igram of the realization of te scenasio of Figure 12.39 ofthe Manage an Asset use cage of the MSG Foundation case study ina ae veae™ {| * Seta ooh O Taare OEE 6; Display successful 3: Send successful aR Nad 8 ete MiSaett lee” aries cn events is left as an exercise (Problem 12,10). The sequence diagram equivalent ro the collaboration diagram of Figure 12.40 is shown in Figure 12.41, ‘Now consider a different scenario of the use case Manage an Asse: (Fig- ‘ure 12,36) namely, the extended scevario of Figure 12.14, the normal part of which js reproduced here as Figure 12.42. In this scenario, at the request ofthe borzowers, |) the MSG saif member updates the weekly iacome of a couple who have an MSG mortgage. As explained in Section 10.7, the scenario is initiated by the Borrowers, and their data are entered into the software product by the MSG Staff Member, as stated in the note in tke collaboration diagram of Figure 12.43, The flow of events ig again left as an exercise (Problem 12.11). The equivalent sequence diagram is sown in Figure 12.44, Comparing the collaboration diagrams of Figures 12.40 and 12.43 (or, equive- ently, the sequence diagrams of Figures 12.41 arc 12.44), we see that, other than the412 Part Two The Honpinus ofthe Sofovare Life Cle FIGURE 12.41 A sequence ciagram of the realization of the scenario of Figure 12.39 ofthe Manage aa. Asset use case of the MSG Foundation ease study a & & Qo Member Gace Asset Cla” 15 Update annual reaberatc rae | 3: Update tax and ate “4 Send succenstt | competion | <————] mraige” | Send sacesl ' conpleton | : mmesmge | | Is: Okploy | succesful comp! lation mesage FIGURE 12.42 A second scenario ofthe Manage an Avegt use case. ‘There is 2 change in the weekly income of a,Couple who have borrowed money from the MSG Foundation. They wish to have thele weekly income updated in the Foundation records by 2n MSG staff member so that their mortgage payments will be correctly computed. | 1. The staff member enters the new value of the weekly income, 2. The information system updates the date on which the weekly incarme was last changed. actors involved, the only other difference between the two diagrams is that messages 1,2, and 3 involve annual real-estate tax in the case of Figure 12.40 (or Figure 12.41) | and weekly income in the case of Figure 12.43 (or Figure 12.44). This example high- lights the difference between a use case, scenarios (instances of the use case), and collaboration or sequence diagrams of the realization of different scenarios of that se case Boundary class User Interface Class appears in all the realizations considered ‘so far. In fact, the same screen will be used for all commands of the software prod- wet, An MSG staff member clicks on the appropriate operation in the revised menu ofChapler12 Dbjocr Orlented Anatoly 413 FIGURE 12.43 Acallaboration diagram of the realization of the soecacio of Figure 12412 of Gemanage an Accet usecase of the MSG Foundation case study. Teberrowers tet DS the MSG staff member e777] their current weekly income Mortgage “Class Borrowers + + nf sors veenal Ht * sess 1: Update 2: Transfer data 6: Display tO) MSG staff completion Member message Neer terface ‘Class Figure 12.45, (The corresponding textual interface, as implemented in Appendices H. ‘and I is given in Figure 12.46.) 12.15.3 Update Estimated Annual Operating Expenses Use Case ‘The usecase Update Estimated Annual Operating Expenses isshown jn Figure 10.17 with a description ia Figure 10.18. A class diagram shawing the classes that realize the Update Estimated Amnual Cperating Bx- ‘peases use case appears in Figure 12.47, and a collaboration diagram of realize- tion of a scenario of the use case in Figure 12.48. The equivalent sequence diagrara is shown in Figure 12.49. Details of the scenario and the flow of events are left as an exercise Problems 12.12 and 12.13)AVE Port Two The Workflows ofthe Software Life Cyele FIGURE 12.44 A soquance diegramof ths realization of the scenerio of Figure 1242 of the Manage ant Asset use case of the MSG Foundation case study, econ 2 Fane dis | ! +: wpantancom ' and date i t Bread | { Tieden! ' cain | | sey soe | | [* a cor | See sucrsta | ; omic i | nese | 38 messge : ' FIGURE 12.45, Click on your choices ~ Roisal Roel Tinga nd a Tek tases — Foundation filonoas a mortgage ‘case study, éanage an investment Tadate estimated annus operating expenses, ‘ada mage aR. Fa on en pt Ficuae 12.46 WAN WEN fuel vied MARTHA STOCKTON GREENGAGE FOUNDATION fe revise 1. Estimate funds avaiable for week tren of 2. Manage a mortgage Fine 124s. | 3. Sfarage an este 4 Undate esimeted anal opertng expenses 5, Provace a mortgages repo 6. Procace an ivermen' report 7. Quit “ype your choice and press

You might also like

• The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life

  

  From Everand

  The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life

  Mark Manson

  Rating: 4 out of 5 stars

  4/5 (5834)
• The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are

  

  From Everand

  The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are

  Brené Brown

  Rating: 4 out of 5 stars

  4/5 (1093)
• Never Split the Difference: Negotiating As If Your Life Depended On It

  

  From Everand

  Never Split the Difference: Negotiating As If Your Life Depended On It

  Chris Voss

  Rating: 4.5 out of 5 stars

  4.5/5 (852)
• • Magazines
  • Podcasts
  • Sheet music
• Principles: Life and Work

  

  From Everand

  Principles: Life and Work

  Ray Dalio

  Rating: 4 out of 5 stars

  4/5 (612)
• The Glass Castle: A Memoir

  

  From Everand

  The Glass Castle: A Memoir

  Jeannette Walls

  Rating: 4.5 out of 5 stars

  4.5/5 (1720)
• Grit: The Power of Passion and Perseverance

  

  From Everand

  Grit: The Power of Passion and Perseverance

  Angela Duckworth

  Rating: 4 out of 5 stars

  4/5 (590)
• Sing, Unburied, Sing: A Novel

  

  From Everand

  Sing, Unburied, Sing: A Novel

  Jesmyn Ward

  Rating: 4 out of 5 stars

  4/5 (1194)
• Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race

  

  From Everand

  Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race

  Margot Lee Shetterly

  Rating: 4 out of 5 stars

  4/5 (903)
• Shoe Dog: A Memoir by the Creator of Nike

  

  From Everand

  Shoe Dog: A Memoir by the Creator of Nike

  Phil Knight

  Rating: 4.5 out of 5 stars

  4.5/5 (541)
• The Perks of Being a Wallflower

  

  From Everand

  The Perks of Being a Wallflower

  Stephen Chbosky

  Rating: 4.5 out of 5 stars

  4.5/5 (2106)
• The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers

  

  From Everand

  The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers

  Ben Horowitz

  Rating: 4.5 out of 5 stars

  4.5/5 (350)
• Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future

  

  From Everand

  Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future

  Ashlee Vance

  Rating: 4.5 out of 5 stars

  4.5/5 (474)
• Bad Feminist: Essays

  

  From Everand

  Bad Feminist: Essays

  Roxane Gay

  Rating: 4 out of 5 stars

  4/5 (1029)
• The Outsider: A Novel

  

  From Everand

  The Outsider: A Novel

  Stephen King

  Rating: 4 out of 5 stars

  4/5 (1872)
• Her Body and Other Parties: Stories

  

  From Everand

  Her Body and Other Parties: Stories

  Carmen Maria Machado

  Rating: 4 out of 5 stars

  4/5 (824)
• The Sympathizer: A Novel (Pulitzer Prize for Fiction)

  

  From Everand

  The Sympathizer: A Novel (Pulitzer Prize for Fiction)

  Viet Thanh Nguyen

  Rating: 4.5 out of 5 stars

  4.5/5 (122)
• The Emperor of All Maladies: A Biography of Cancer

  

  From Everand

  The Emperor of All Maladies: A Biography of Cancer

  Siddhartha Mukherjee

  Rating: 4.5 out of 5 stars

  4.5/5 (271)
• Angela's Ashes: A Memoir

  

  From Everand

  Angela's Ashes: A Memoir

  Frank McCourt

  Rating: 4.5 out of 5 stars

  4.5/5 (443)
• Brooklyn: A Novel

  

  From Everand

  Brooklyn: A Novel

  Colm Tóibín

  Rating: 3.5 out of 5 stars

  3.5/5 (1948)
• The Little Book of Hygge: Danish Secrets to Happy Living

  

  From Everand

  The Little Book of Hygge: Danish Secrets to Happy Living

  Meik Wiking

  Rating: 3.5 out of 5 stars

  3.5/5 (405)
• A Man Called Ove: A Novel

  

  From Everand

  A Man Called Ove: A Novel

  Fredrik Backman

  Rating: 4.5 out of 5 stars

  4.5/5 (4772)
• Steve Jobs

  

  From Everand

  Steve Jobs

  Walter Isaacson

  Rating: 4.5 out of 5 stars

  4.5/5 (809)
• The World Is Flat 3.0: A Brief History of the Twenty-first Century

  

  From Everand

  The World Is Flat 3.0: A Brief History of the Twenty-first Century

  Thomas L. Friedman

  Rating: 3.5 out of 5 stars

  3.5/5 (2259)
• The Art of Racing in the Rain: A Novel

  

  From Everand

  The Art of Racing in the Rain: A Novel

  Garth Stein

  Rating: 4 out of 5 stars

  4/5 (4214)
• The Yellow House: A Memoir (2019 National Book Award Winner)

  

  From Everand

  The Yellow House: A Memoir (2019 National Book Award Winner)

  Sarah M. Broom

  Rating: 4 out of 5 stars

  4/5 (98)
• Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America

  

  From Everand

  Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America

  Gilbert King

  Rating: 4.5 out of 5 stars

  4.5/5 (266)
• A Tree Grows in Brooklyn

  

  From Everand

  A Tree Grows in Brooklyn

  Betty Smith

  Rating: 4.5 out of 5 stars

  4.5/5 (1930)
• Yes Please

  

  From Everand

  Yes Please

  Amy Poehler

  Rating: 4 out of 5 stars

  4/5 (1905)
• A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story

  

  From Everand

  A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story

  Dave Eggers

  Rating: 3.5 out of 5 stars

  3.5/5 (231)
• Team of Rivals: The Political Genius of Abraham Lincoln

  

  From Everand

  Team of Rivals: The Political Genius of Abraham Lincoln

  Doris Kearns Goodwin

  Rating: 4.5 out of 5 stars

  4.5/5 (234)
• The Woman in Cabin 10

  

  From Everand

  The Woman in Cabin 10

  Ruth Ware

  Rating: 3.5 out of 5 stars

  3.5/5 (2526)
• Wolf Hall: A Novel

  

  From Everand

  Wolf Hall: A Novel

  Hilary Mantel

  Rating: 4 out of 5 stars

  4/5 (3973)
• Fear: Trump in the White House

  

  From Everand

  Fear: Trump in the White House

  Bob Woodward

  Rating: 3.5 out of 5 stars

  3.5/5 (738)
• John Adams

  

  From Everand

  John Adams

  David McCullough

  Rating: 4.5 out of 5 stars

  4.5/5 (2410)
• On Fire: The (Burning) Case for a Green New Deal

  

  From Everand

  On Fire: The (Burning) Case for a Green New Deal

  Naomi Klein

  Rating: 4 out of 5 stars

  4/5 (74)
• The Light Between Oceans: A Novel

  

  From Everand

  The Light Between Oceans: A Novel

  M.L. Stedman

  Rating: 4.5 out of 5 stars

  4.5/5 (789)
• Manhattan Beach: A Novel

  

  From Everand

  Manhattan Beach: A Novel

  Jennifer Egan

  Rating: 3.5 out of 5 stars

  3.5/5 (880)
• The Constant Gardener: A Novel

  

  From Everand

  The Constant Gardener: A Novel

  John le Carré

  Rating: 3.5 out of 5 stars

  3.5/5 (104)
• The Unwinding: An Inner History of the New America

  

  From Everand

  The Unwinding: An Inner History of the New America

  George Packer

  Rating: 4 out of 5 stars

  4/5 (45)
• Intro To BMW

  

  Document54 pages

  Intro To BMW

  Anonymous iUW0JL6O5

  100% (8)
• Rise of ISIS: A Threat We Can't Ignore

  

  From Everand

  Rise of ISIS: A Threat We Can't Ignore

  Jay Sekulow

  Rating: 3.5 out of 5 stars

  3.5/5 (137)
• Little Women

  

  From Everand

  Little Women

  Louisa May Alcott

  Rating: 4 out of 5 stars

  4/5 (105)
• Microsoft Development Center Serbia Programming Course

  

  Document11 pages

  Microsoft Development Center Serbia Programming Course

  Anonymous iUW0JL6O5

  No ratings yet
• 06 Design MVC

  

  Document19 pages

  06 Design MVC

  Anonymous iUW0JL6O5

  No ratings yet
• Lesson 5 - Delegates and Lambda Expressions: Microsoft Development Center Serbia Programming Course

  

  Document8 pages

  Lesson 5 - Delegates and Lambda Expressions: Microsoft Development Center Serbia Programming Course

  Anonymous iUW0JL6O5

  No ratings yet
• Real Examples of Using C# Features: Microsoft Development Center Serbia Programming Course

  

  Document11 pages

  Real Examples of Using C# Features: Microsoft Development Center Serbia Programming Course

  Anonymous iUW0JL6O5

  No ratings yet
• Mixing Linq Providers Linq Objects

  

  Document4 pages

  Mixing Linq Providers Linq Objects

  Anonymous iUW0JL6O5

  No ratings yet
• SWSY Sem ProgAnalysis Generics Lkretsch

  

  Document23 pages

  SWSY Sem ProgAnalysis Generics Lkretsch

  Anonymous iUW0JL6O5

  No ratings yet
• Delegates, Lamdba Expressions and Anonymous Methods: Declare, Instantiate, and Use A Delegate

  

  Document10 pages

  Delegates, Lamdba Expressions and Anonymous Methods: Declare, Instantiate, and Use A Delegate

  Anonymous iUW0JL6O5

  No ratings yet
• Multithreading PDF

  

  Document17 pages

  Multithreading PDF

  Anonymous iUW0JL6O5

  No ratings yet
• CH 11

  

  Document14 pages

  CH 11

  Anonymous iUW0JL6O5

  No ratings yet
• Microsoft Realtests 70-483 v2015-03-09 by Betty 296q PDF

  

  Document410 pages

  Microsoft Realtests 70-483 v2015-03-09 by Betty 296q PDF

  Anonymous iUW0JL6O5

  No ratings yet
• 00000000000-Writing Answers Explained Sat 2010

  

  Document45 pages

  00000000000-Writing Answers Explained Sat 2010

  Anonymous iUW0JL6O5

  No ratings yet
• Generating C# Source From UML Class Diagram in Visual Studio

  

  Document7 pages

  Generating C# Source From UML Class Diagram in Visual Studio

  Anonymous iUW0JL6O5

  No ratings yet
• 20483

  

  Document9 pages

  20483

  Anonymous iUW0JL6O5

  No ratings yet
• Tutorial Class ERD PDF

  

  Document15 pages

  Tutorial Class ERD PDF

  Anonymous iUW0JL6O5

  No ratings yet
• Practical2 Final

  

  Document896 pages

  Practical2 Final

  Anonymous iUW0JL6O5

  No ratings yet
• What's The Difference Between Traditional or Structured Analysis and OO Analysis?

  

  Document7 pages

  What's The Difference Between Traditional or Structured Analysis and OO Analysis?

  Anonymous iUW0JL6O5

  No ratings yet
• OOP Lecture 10

  

  Document22 pages

  OOP Lecture 10

  Anonymous iUW0JL6O5

  No ratings yet
• سلسلة دروس جان و الفلك

  

  Document7 pages

  سلسلة دروس جان و الفلك

  Anonymous iUW0JL6O5

  100% (2)