AnalysisHFOOAD Chapter 4

What is analysis?*Mt phng php tm hiu bn cht ca s vt hoc xc nh cc tnh nng ct li ca n v quan h gia chng.Mt phng php th hin cc khi nim hoc mnh phc tp bi kt hp ca cc khi nim n gin hn.S nh gi mt hot ng xc nh cc mc tiu mong mun v xc nh l trnh t c cc mc tiu mt cch hiu quLin quan g n vic pht trin phn mm?

Did we analyze the problem?*The Perfect WorldDogDoor.java

*Ta khng th c thi gian xt n tt c cc kh nng c th.ng vy, nhng ta c th xc nh nhng tnh nng ct li v cc quan h.

Th no l ct li?*Customer wont buy without itSystem wont work without itMany parts of the system depend upon it

*But we satisfied the requirements!There was nothing in the specs about other animals.How would we have known that it was important?

Why didnt the customer tell you?*

Gary Pollice - Actually, a drawing of a bike would be better here. Possibly someone signaling a left turn.

i vo nhng im ct li*

My essentials arent your essentials*Anyone have a shovel?I really need some salt. This shovel just wont do.

Gary Pollice - Need a picture here of someone with an umbrella trying to dig in the garden.

The 4+1 View Model of Software Architecture*ProcessorsData storesCode structurePackagesLibrariesLogical ViewProgress ViewDevelopment ViewPhysical ViewSystem engineersTopologyCommunicationsIntegratorsPerformanceScalabilityEnd-user FunctionalityProgrammersSoftware managementScenariosClassesObjectsBehaviorsThreadsProcessesCommunications

Lets play what if*How many what if questions can you think of?

UML sequence diagrams make it easy*

Generalize as much as possible*

*Vy l bt c con ch no sa cng lm ca m. C v khng nWhat would you do to change your solution?Try to change the sequence diagram.

*Ta c th ch thch, nhng vic ny khng hu ch cho vic tm thit k ng.

Our solution*

Some guidelinesTo cc lp n gin, chng cng tc vi nhau qua vic gi v nhn messageMi lp ch nn c MT trch nhimHu ht cc persistent object (nh Bark ting sa) thng c mt lp qun lCreate to miRetrieve cUpdate ghi Delete xa *Lm sao bit c l cn lp BarkManager?CRUD

*Cn use case th sao?Ta phi cp nht c use case na.

Khng nht thitTa sa use case nu thay i nh hng n use caseKhng phi thay i no cng mc use caseNu use case tng qut, v m t mt kch bn ch c mt mc tiu, n s khng hay phi thay iMt s use case khng cn nhiu chi tit*Vy l ln no cng phi sa use case?

Other use cases*Bark maintenance (CRUD)Initialize systemDisable (lock) doorReport activity

*C v tn kh nhiu cng cho vic hon thin v cp nht use case. C cch m t h thng no cng hn khng?Chc chn ri. Ta c th dng user story hoc CRC card.

CRC Cards*Class-Responsibility-CollaboratorBeck & CunninghamLow-techIndex cards and markersEasy to create and destroyUses spatial placement to show relationshipsGreat for students learning to think in O-O

*Class nameOptionalResponsibilities of this classClasses this class work with to perform its responsibilities

Our main use case in CRC cards*

CRC guidelinesng ngi x b cardNu mt lp c qu nhiu trch nhim khng ch ghi, hoc nu c nhiu hn 01 trch nhim chnh, tch n thnh nhiu lpNh duyt cc kch bn s dng chnh sa v hon thin cardVit ch r rngng mang xp card nhy xung h, n s mn ra.*That seems easy. Anything else I should know about?

User storiesM t mt tnh nng hoc mt n v cng vic cho mt lp trnh vinCung cp thng tin xc nh nhng nhu cu c bn c th tip tc hi khch hngKim th c bng test*

A typical user story*Open the dog doorDogDoor s nhn mt tn hiu m ca t mt thit b ngoi vi, chng hn remote hoc bark recognizer. Khi nhn c tn hiu m ca, ca s m v gi tnh trng m trong 5 giyWhat if the door is already open?

A typical user story (revised)*Open the dog doorDogDoor s nhn mt tn hiu m ca t mt thit b ngoi vi, chng hn remote hoc bark recognizer. Khi nhn c tn hiu m ca, ca s m v gi tnh trng m trong 5 giyHt giy th 5, ca s ng, nu ca ang m sn, ca s tip tc gi tnh trng ng trong 5 giy tip theo.

User stories for our main use case*I like this. Any additional words of wisdom?

User story guidelinesNu mt user story qu di, tch n raN qu to nu khng va mt index cardNu user story qu n gin, c th nhp n vo mt story khcHy m bo n c thng tin lp trnh vin ci c n hoc t nht c th hi thm v nNu mt story cn qu nhiu thi gian ci (nh gi tng i), hy chia nh n ra*

Comparing the three techniques*

Focus on the Bark*I dont see what was wrong with using Strings for the Bark.Youre obviously new to O-O.What is wrong with Randys approach?

Compare the code*

*String tm thi ok v ta cha c phn cng, nhng khi ta c c phn cng th s cn n format thc ca ting sa, v ta s phi sa. Nu dng lp Bark thay v String th ta ch phi sa c mt lp.

So, why did Maria win the laptop?*It was nothing really. I just did a better job of analysis than the guys.Yes, but you did not do a complete job. You missed a significant possibility.What did Maria miss and how could she have completed the job?

Three things we might have found outThere might be multiple dogs There might be multiple doors There might be multiple remotes

*How would this change your design? Draw a UML class diagram to show the improved solution.

*

Phn tch vn bnCc danh t trong cc yu cu v ti liuCc thc th v khi nimT min ng dngKinh nghimCc h thng trc*Where do classes come from?

Textual analysisTm tt c danh t trong ti liu (use case)Loi b cc t trng lpKhi c cc danh t ng ngha, chn ly t tt nht v loi b cc t khc*

Textual analysis solutionthe (owners) dogthe ownerthe buttonbark recognizerrequestinside/outsidedog doorremote controlbark

*Here are the nouns we circled in the use case:

Not all words are important in a documentEven though we might think they are Some nouns refer to entities outside of your systemOwner, dog Some nouns refer to things you dont have to model or createRequest*Do I have to have a class for all of the nouns?

*

*

Analysis is the next step as we progress from the customer needs, to requirements, to implementation. Remember, even though were going through this sequentially, things actually occur in parallel as we go through our iterations.*All of the definitions above were taken from www.dictionary.com. They all have a somewhat different focus, but in general, theyre all appropriate for understanding how we develop great software. If you dont remember what great software is, go back to chapter 1.*One might argue that weve analyzed the problem, but if you think about it, we really only looked at the problem cursorily. We took Dougs original requirements and implemented them. Then we added the capability for the bark recognizer. But we didnt actually look at all of the possible ways that our system might be used or misused. We built our system for the perfect world, that doesnt exist.*This is a key point. There will always be new ideas and possibilities, your job is to find those that are essential to the success of your product and project.*Answers appear on click*Ta c th a ra l do bin minh cho vic ta b qua ci g , nhiu l do trong kh hp l. Hoc, ta c th hc cch lm tt hn v luyn tp, luyn tp, luyn tp.*C nhiu l do cho vic khch hng khng ni ci h cn. H c th cho l ta bit mt tnh nng no ri, v i vi h n qu hin nhin. H c th khng ngh n mt s tnh hung c bit cn n tnh nng . Hoc h thm ch khng th bo ta rng h cn tnh nng , v n gin l h khng bit thc ra h c bit. V d. Hy th hi mt ngi xem lm th no r tri khi i xe p. S c t ngi ni rng u tin ta phi nh ghi ng sang phi. l v khi r tri, ta cn nghing xe sang tri v ta khng th lm vy m khng nh tay li sang phi. Ta ch c th bit c iu ny nu ta xem mt on phim quay chm mt ngi ang r tri. Ni cch khc, ta phn tch hnh ng trong ng cnh ca th gii thc.*Ta c c cc yu cut nht l b yu cu ban u. Gi ta phi dng b c lp lun v vic h thng s hot ng nh th no khi nhng con ngi thc s dng n trong mi trng ca h. T , ta rt ra mt tp cc tnh nng ct li v cc cng ngh ct li, v phc tho hnh dng ct li ca h thng ci m ta gi l kin trc.*Ci g l ct li i vi mt sn phm ty thuc vo gc nhn. Mi stakeholder c mt gc nhn ring. V d, chiu cao ca ca ch v tc , lc ng ca l quan trng i vi ngi thit k phn cng. Tuy nhin, nhng c im li khng quan trng i vi h thng phn mm. i vi h thng phn mm, im quan trng l ta c mt tc v timer quyt nh khi no th ng ca. Chuyn ny hon ton v hnh i vi nhng ngi lm phn cng v khch hng.Tuy nhin, c mt s phn l giao ca cc view khc nhau. V d, tn hin gi t remote hoc t bark recognizer ti phn mm l im quan trng. Phn cng cn gi ng tn hiu vo ng lc v phn mm cn phi phn ng vi tn hiu theo ng cch.*Phiippe Kruchten xut bn bi bo c tn Architectural BlueprintsThe 4+1 View Model of Software Architecture, ti tp ch IEEE Software, Nov. 1995. Trong , ng m t cc scenario (ngha l, use cases) l phn giao ca 4 gc nhn chnh i vi mt h thng.

Nu ta vit cc kch bn hay use case mt cch ng n, ta ang i ng hng trn con ng lit k b cc phn t ct li m tt c u quan tm.*Heres a nice diagram of how we think the system should work. With such a diagram, we can begin to reason about the design. We can ask a lot of what if questions.

Note, instructor may want to mention to students that it is not necessary to be a great artist to draw these sorts of diagrams and perform these analyses. *UML sequence diagrams are good ways to describe a scenario. You can easily draw such a diagram on a whiteboard or on a piece of paper. This diagram was generated by a software tool, but the value is not in the precision of the drawing, but the information it contains.

There are several parts to the sequence diagram. Weve indicated them by naming each part and pointing to the actual UML modeling element with a small arrow. The lifelines simply show that an object is active, or alive, during the scenario. When objects are created or destroyed they may have shorter lifelines than other objects. The rectangles and stick figure are objects. We may or may not know what class they are an instance of, but for most of the diagrams well use, we just consider them objects of an appropriate class. The UML standard for showing an object is to underline it. The tool we used does not do this. The lowercase letter beginning the names (except for Bruce) are a good hint that were talking about an object. Bruce is an actor, and an object here. Hes a specific instance of the Dog actor. (If youre interested, actors are simply classes in UML.) The message indicates a communication from one object to another or from an object to itself. The messages are also numbered to show the order in which they are sent. Notice that they go down the lifelines indicating a temporal ordering.The control focus blocks show the time the object is in control during the processing of a message. Some people use them quite a bit. We dont think theyre that useful for our analysis needs.*This is the same diagram as the previous one except that weve change Bruce to aDog. Weve generalized the scenario. Does this make you think of anything? In the text we talked about the owners dog. This might be even better for the specific scenario, but what if the people in the house are dog-sitting for a relative or friend? Now the dog isnt theirs, but they want the door to open when the dog barks, just as it does for their own dog. Is there a better name we can use for the actor?*This one simple change where we generalized more might have led you to think about what could really happen in the real world. Even if it didnt, you might have discovered it as you and your teammates walked through the scenario and asked a lot of what if questions. Why do you think the customer never thought of this problem?*Ta cn c th nhn dng mt ting sa v m bo rng l ting ca mt con ch m ta mun m ca. Ci g nn chu trch nhim cho vic ny? Ta c nn t trch nhim ny vo BarkRecognizer hay DogDoor, hay ta cn mt hoc vi class mi thc hin trch nhim ny? *Ta thm mt lp mi. i tng ca lp ny c dng y l barkManager. Tn lp chc s l BarkManager. BarkManager c trch nhim xc nh xem mt ting sa c phi l ting nn m c ca hay khng. Ta t trch nhim nhn dng mt ting sa vo mt lp ring, v nu ta t n vo lp BarkRecognizer, th BarkRecognizer s c hai trch nhim: yu cu ca mi v xc nh xem mt ting sa c hp l hay khng. thi im ny, vic ny c v khng quan trng g mt h thng n gin, nhng ta nn tp thi quen to cc lp ch c ng mt trch nhim. Lp BarkRecognizer cn n tri thc v chuyn mt ting sa c hp l hay khng, nhng n y nhim (delegate) trch nhim cho lp BarkManager.*Bn c th nhn thy ta khng v lp Bark trong cc biu trc. l v Bark ch l mt lp cha d liu. Ngha l mt bn ghi, hay mt cu trc d liu cha cc trng d liu m ta quan tm, cho n gi n cha c hnh vi g. Ta ch cn n cc phng thc get ly gi tr cc d liu lu trong i tng.

Tuy nhin, barkManager c trch nhim truy nhp cc i tng d liu, n c cc i tng Bark t ni lu tr d liu ri ghi cc i tng Bark vo li ni lu tr khi cn thit. Cc thao tc ny thng c vit tt l CRUD.

Bn c th ngh ra mt hnh vi no m mt i tng Bark cn c, ngoi cc hm get ly d liu i din cho ting sa?* rng use case khng nhc n i tng BarkManager. Ta c th a n vo, nhng vic khng thc s cn thit. Khch hng hay stakeholder c l khng quan tm n n. Nhng lp trnh vin phi xy dng h thng th c. Khng c cu tr li ng. iu quan trng l m bo rng c thng tin cn thit cho nhng thnh vin no cn bit v n. Cc thnh vin khc nhau trong nhm v cc stakeholder c cc level hoc view khc nhau v thng tin. Biu tun t c v BarkRecognizer v cho lp trnh vin bit n dng lm g.*There are some software tools that claim to help you keep your use cases synchronized with the other artifacts that depend upon them. They often require much formality in how you structure your use cases. This requires time to manage the format of the artifacts, and takes away from the time of describing the system. Sometimes the expense is worth it, especially on large systems. But you should be careful about falling into the trap of trying to let your tools dictate how you spend your time. Tools that dont support the way you work arent very helpful.*Him khi mt h thng ch c 1 use case, ngay c nhng h thng n gin. Nhng thay i ta va thc hin nn gi ta ngh v t nht mt use case na. Bn c th ngh ra bao nhiu cho h thng ca ch?

(Answers appear on click)

Khng phi tt c cc use case trong slide ny c th c suy ra t thng tin ta c c t cc yu cu ca stakeholder thi im ny. Chng c lit k ra y bn thy cc kh nng c th tn ti. Khi bn tr nn quen thuc hn vi h thng v mun ca khch hng, bn s c th pht hin ra mt use case quan trng vi khch hng m h cha ngh ra. Bn c th trnh by cho khch hng v h quyt nh. Thng c mt s use case d lm nhng li mang li c tnh nng lm cho khch hng quyt nh mua h thng ca bn thay v h thng tng t ca i th cnh tranh ca bn.

Ti slide ny, hai use case u c th thu c t yu cu. Ta nht nh cn thm ting sa ca mt con ch vo c s d liu ca h thng (mt file hoc mt CSDL no ) ta c th xc nh xem mt ting sa no c nn m c ca hay khng. Nu ta c th thm mt ting sa, ta nn c kh nng xa mt ting sa. Ta nht nh cn ly d liu v ting sa m ta ang mun so snh n vi ci m phn cng nhn dng ting sa gi. Ta chc khng cn update mt ting sa v kh nng ln l n nh dng m ta s khng sa. Ta vn nh du use case ny l CRUD. Ta cng khng mun vit qu nhiu chi tit v use case ny v cc thao tc loi ny thng qu quen thuc vi lp trnh vin.

H thng khng chy lin tc v hn. N c th ngng v s c in, hoc b tt khi khch hng i ngh di ngy. Sau n phi c khi ng li. h thng ny, cng vic khi ng c l khng nhiu, nhng vn nn c mt use case khi to. Nu , bn s hi ta c cn use case tt hay khng. Cu tr li l C.

Hai use case cui l chng ti ngh ra khi bn bc v hot ng h thng. Ta c th khng phi ci chng ngay t phin bn u tin, nhng nu ta ngh ra g , ngay c khi khch hng cha mun c n, ta cng nn lu li u , khi ta hon thnh phin bn 1.0, chn m tin thu c do bn bn 1.0, ta c th xem li cc tng ny v lm mt phin bn mi v c ci tin m ta c th bn vi gi cao hn. Tt nhin, khi nhn thy use case #3, khch hng c th quyt nh rng h mun c n ngay phin bn 1.0. Chng hn khi Fido chng may nut nhn ci ca h, v h khng mun Fido t ra ngoi m khng c ch i km, khi h s khng mun ca m khi Fido sa.*This is a great question. Use cases arent the only way to describe your system. There are several ways to describe a system. Once again, you have to decide what the right trade-offs are for the project and the people involved in the project. In the next few slides well look at user stories and CRC cards and how they can be used in place of, or along with use cases to get just the right level of detail to make everyone happy. Well describe the main use case using each of these techniques. These arent the only alternate techniques, but wed bore you to death (and us too) if we went into every one of the possibilities.

Remember, your mileage will vary depending upon your team and the project.*Kent Beck and Ward Cunningham developed the concept of CRC cards and used them in classes they taught to programmers who were trying to learn good O-O techniques. They found that the cards aided the students learning of how objects worked and helped them develop good O-O habits.*This is a basic CRC card. People have added modifications, but they all have this basic structure. In this case, the DogDoor doesnt need any other classes to help it perform its responsibilities. Well see examples coming up where this is not the case.*In this diagram, we have five classes that weve identified as participating in the use case. The proximity of one class to another means that they are more closely associated than if they were further apart. Here, the Remote and BarkRecognizer both depend upon the DogDoor in order to do their job. The BarkRecognizer also needs the BarkManager to do its job as well as a Bark. The Bark class needs a second Bark object in order to perform its comparison.*CRC cards are easy to use and are worth trying. Some developers really get into them easily while others struggle. If they work for you, use them. If not, dont. How Zen is that!?*User stories were described by Kent Beck in his book eXtreme Programming Explained (Addison Wesley). Since then there have been many books out that tell you how to write good user stories and use them for project planning. Many project teams like the user stories since they tend to be something that developers can more easily focus on. User stories work at a bit of a different level than use cases. Theyre not as complete and they dont necessarily define actions from the users point of view. However, they have been quite successful.

A development team will generally use user stories by having the customer write the stories. The developers look at the stories and estimate the work. They talk with the customer about the details that might be missing from the stories. They then estimate the user stories and let the customer select a specific amount of work to be done in the next iteration. This is called the planning game in eXtreme Programming (XP).

Oh yes, one other thing. For XP teams, they recommend writing the user stories on index cards. The index card companies love XP and Agile development teams.*The user story has a name. It may also have a user story number.

Now, our crouching friend has a great question. In this case, he would talk to the customer, or whoever wrote the user story (the promise of a conversation is fulfilled) about it and then (hopefully) will update the user story as in the following slide.***Here are some of the features weve found from using the three techniques. Each can be used to address the system at a different level. We have seen projects that use two of the techniques (usually use cases and user stories) effectively. The use cases are very good for describing how the whole system works and for reasoning about its completeness and coherence. The user stories are great ways of describing the features that are needed to make the use cases work. In fact, you might even think of the user stories to be somewhat analogous to the steps in the use case descriptions.*Back to our use case. One of the things we didnt show in our sequence diagram was how the BarkRecognizer determines if a bark is a known bark. Now we have a couple of ways to handle this. Remember Randy and Sams debate about how to handle the bark? Randy wanted to keep it as a String class while Sam wanted to create a Bark class. Before going on, think about why Sams approach is better.

Sam had to write more code since he created a new class just to hold the string that represents the bark. The code, shown on the next slide for comparison is almost identical. So, why do we need the Bark class?*Look at the code to do the comparison. There doesnt seem to be a difference except for a couple of minor changes that are almost cosmetic. Is it worth it?*Bn c t ngh ra khng? Encapsulation rt quan trng v n gip ta qun l thay i. Chng hn, nu phn cng gi mt file audio nh dng c bit, i hi mt thut ton c bit so snh hai file nh vy, ta c th che giu n bn trong phng thc equals ca lp Bark, v ta c lp cc thay i ca lp Bark v c l c cc lp m n y quyn (delegate) na. Encapsulation v delegation i vi nhau. Ta ng gi ting sa trong lp Bark v y quyn hnh vi so snh hai ting sa cho lp Bark.*Marias change is a simple extension to Sams solution. She realized that there could be multiple barks from the same dog. That was quite insightful, but she stopped short. Using the revelation that there could be multiple barks led her to use a collection of barks rather than a single bark. What did she miss? (Hint: Weve already taken care of the problem in our solution, but this is the point where, if we hadnt already taken care of it, we would discover the need now.)*Well, we have already isolated handling the barks to the BarkManager class. This handles the case when there might be multiple dogs and multiple doors. But, it seems like we need to do some other things to change the design of the system. Lets look at one possible solution.*We havent included the fields and methods in the diagram. For our purposes now we are focusing on the multiplicities of the associations between the classes. Weve added some comments to the diagram so you can follow the reasoning. It doesnt take a lot of effort to reason about how the different objects might be related as we analyze the requirements.*Weve come quite a ways in developing our system. Some of the classes might seem quite obvious and some not so obvious. One thing a good O-O developer does is find the right set of classes for the application at hand. There are some techniques, such as CRC cards and textual analysis, that will get you off to a good start. After that though, you need to apply reasoning and experience to determine the right set for your needs. Entities and concepts from the application domain are a primary source of classes for any application. These will often be identified in the requirements, but there will be others that are implied or assumed. This is where the experience of someone who is a domain expert can help identify such classes.

Lets take a look at textual analysis. This technique has been around for a long time.*Heres a simple recipe for finding classes from a requirements document, like a use case. Finish the textual analysis on this document.*This is the solution from p. 168 in the book. Notice that there are aliases here. For example door and dog door are the same entity. Which is the best one for our purposes?*Sometimes it seems obvious when a noun is important or not. But there are times when you arent sure. When youre not sure, add the class to the set of classes you think you need. If you really dont need it, youll find out when there is no behavior or useful properties assigned to it. Then you can remove it with no harm done. Using the possible classes as you go through scenarios with CRC cards or sequence diagrams will usually settle the issue of what classes are needed and which arent.*The nice thing about English and most other languages is that the nouns and verbs are already associated with each other correctly. This facilitates how we assign the correct behavior to the classes.*Before going onto the next chapter, you might want to try your hand at implementing the code for the design shown in slide 39.*