Recommended
Recommended
More Related Content
Similar to HeadFirstOOAD_Ch04.ppt
Similar to HeadFirstOOAD_Ch04.ppt (20)
Recently uploaded
Recently uploaded (20)
HeadFirstOOAD_Ch04.ppt
- 2. What is analysis? 2 • A method of studying the nature of something or of determining its essential features and their relations • A method of exhibiting complex concepts or propositions as compounds or functions of more basic ones • The evaluation of an activity to identify its desired objectives and determine procedures for efficiently attaining them So what’s this got to do with developing software?
- 3. Did we analyze the problem? 3 The Perfect World DogDoor.java The Real World DogDoor.jav a
- 4. 4 We can’t take the time to go through all of the possibilities. No, but we can identify the essential features and relations.
- 5. What make something essential? 5 Customer won’t buy without it System won’t work without it Many parts of the system depend upon it … 1 2 3 4
- 6. 6 But we satisfied the requirements! There was nothing in the specs about other animals. How would we have known that it was important?
- 7. Why didn’t the customer tell you? 7
- 8. Getting to the essentials 8 Gather requirements Analyze in real world context Develop the architecture
- 9. My essentials aren’t your essentials 9 Anyone have a shovel? I really need some salt. This shovel just won’t do.
- 10. Scenarios unify the views 10 Processors Data stores Code structure Packages Libraries Logical View Progress View Development View Physical View System engineers Topology Communications Integrators Performance Scalability End-user Functionality Programmers Software management Scenarios Classes Objects Behaviors Threads Processes Communications
- 11. Let’s play what if… 11 How many “what if” questions can you think of?
- 12. UML sequence diagrams make it easy 12 Lifeline Message Object Control focus
- 13. Generalize as much as possible 13
- 14. 14 So any dog bark can open the door. That doesn’t seem correct. What would you do to change your solution? Try to change the sequence diagram.
- 15. 15 We can put a comment in, but that isn’t too helpful for getting to the right design.
- 16. Our solution 16
- 17. Some guidelines ‣ Make simple classes that work together by sending and responding to messages ‣ Classes should have one responsibility ‣ Most persistent objects (like the bark) will usually have a class that manages them ‣ Create ‣ Retrieve ‣ Update ‣ Delete 17 So how did you know that you needed the BarkManager class?
- 18. 18 And what about the use case? You have to update the use case too.
- 19. ‣ Not necessarily ‣ You change the use case if the change affects the use case ‣ Not all changes are at the use case level ‣ If the use case is sufficiently general, and describes a single goal-oriented sequence, it won’t change that much ‣ Some use cases really don’t need a lot of detail 19 So every time we make a change we have to change the use case?
- 20. Other use cases 20 Bark maintenance (CRUD) Initialize system Disable (lock) door Report activity 1 2 3 4
- 21. 21 Use cases seem to require a lot of care to keep them up to date and complete. Are there other ways we can describe the system with a little less effort? Sure, we could adopt user stories or CRC cards.
- 22. CRC Cards 22 ‣ Class-Responsibility-Collaborator ‣ Beck & Cunningham ‣ Low-tech ‣ Index cards and markers ‣ Easy to create and destroy ‣ Uses spatial placement to show relationships ‣ Great for students learning to think in O-O
- 23. 23 Class name Optional Responsibilities of this class Classes this class work with to perform its responsibilities
- 24. Our main use case in CRC cards 24
- 25. CRC guidelines ‣ Don’t be afraid to rip a card up ‣ If a class has more than one primary responsibility or its responsibilities don’t fit on a card, break it up into more than one class ‣ Make sure you can recreate the configuration and walk through scenarios with the cards ‣ Write legibly ‣ Don’t fall in the lake while carrying the cards—they disintegrate when wet 25 That seems easy. Anything else I should know about?
- 26. User stories ‣ Describe a single feature or unit of work for a developer ‣ Provides enough information to define the basic need ‣ “A promise for a conversation” – Allistair Cockburn ‣ Should be able to be tested with unit tests 26
- 27. A typical user story 27 Open the dog door The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds What if the door is already open?
- 28. A typical user story (revised) 28 Open the dog door The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds. At the end of 5 seconds, the door will close. If the door is already open, then the door will not close until 5 seconds from the current signal reception has elapsed.
- 29. User stories for our main use case 29 I like this. Any additional words of wisdom?
- 30. User story guidelines ‣ If the user story gets too long, break it up into two or more ‣ If it won’t fit on an index card, it’s too big ‣ If the user story is trivial, it can probably be combined with another ‣ Make sure there’s enough information for the developer to implement the user story or at least ask intelligent questions about it ‣ If a user story will take too much time (which is relative) to implement, break it up into smaller user stories 30
- 31. Comparing the three techniques 31 Use cases CRC Cards User stories Address complete goal-oriented sequences of actions the system must perform Can be used to describe complete sequences and scenarios Feature oriented rather than a user’s goal oriented. Unifies several features or parts of features to provide value. Does not address the class level view. Shows relationships between classes by proximity. Can be at a technical level but does not relate features to higher level goals. Mainly requirements and analysis More design level than the other two techniques Can include technical details needed to satisfy requirements Explicitly describes multiple paths Implicitly represents multiple paths and scenarios Does not address paths Can be used for estimation (large granularity estimation) Not very useful for estimation Good for individual programmer task estimation
- 32. Focus on the Bark 32 I don’t see what was wrong with using Strings for the Bark. You’re obviously new to O-O. What is wrong with Randy’s approach?
- 34. 34 Strings are okay for now since we don’t have the hardware, but when we get the hardware the real format for the bark will be needed and we’ll have to make a change. This way, we only have to change one class.
- 35. So, why did Maria win the laptop? 35 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?
- 36. Three things we might have found out ‣ There might be multiple dogs ‣ There might be multiple doors ‣ There might be multiple remotes 36 How would this change your design? Draw a UML class diagram to show the improved solution.
- 37. 37
- 38. ‣ Textual analysis ‣ Nouns in requirements and documents ‣ Entities and concepts ‣ From the application domain ‣ Experience ‣ Previous systems 38 Where do classes come from?
- 39. Textual analysis 1. Identify all nouns in a document (use case) 2. Remove duplicates 3. Where there are aliases, select the best-named and remove the others 39
- 40. Textual analysis solution ‣ the (owner’s) dog ‣ the owner ‣ the button ‣ bark recognizer ‣ request ‣ inside/outside ‣ dog door ‣ remote control ‣ bark 40 Here are the nouns we circled in the use case:
- 41. ‣ Not all words are important in a document ‣ Even though we might think they are ‣ Some nouns refer to entities outside of your system ‣ Owner, dog ‣ Some nouns refer to things you don’t have to model or create ‣ Request 41 Do I have to have a class for all of the nouns?
- 42. 42
- 43. 43 We’ve added a little design here that wasn’t in the book. That should whet your appetite for what’s coming up. Analysis gives us confidence that we understand how the system will work. Now onto design.
Editor's Notes
- Analysis is the next step as we progress from the customer needs, to requirements, to implementation. Remember, even though we’re 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, they’re all appropriate for understanding how we develop great software. If you don’t remember what great software is, go back to chapter 1.
- One might argue that we’ve analyzed the problem, but if you think about it, we really only looked at the problem cursorily. We took Doug’s original requirements and implemented them. Then we added the capability for the bark recognizer. But we didn’t 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 doesn’t 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
- You can make excuses, many of them quite reasonable, about why you missed something. Or, you can learn how to do a better job and practice, practice, practice.
- There are many reasons why the customer might not tell you what they need. They might assume that you know about a feature because to them it’s obvious. They might not think about some of the special conditions where the feature would be needed. Or they might not even be able to tell you that it’s necessary because they just don’t know—yet they do know internally. Here’s an example. Try to tell someone how you turn left on a bicycle. Few people will say that one of the first things you have to do is turn right with the handlebars. This is because you need to begin falling to the left and you can’t do that without turning the handlebars to the right. The only way you would know this is if you watched yourself or someone turn to the left in slow motion. In other words, if you analyzed the action in the context of the real world.
- We’ve got the requirements—at least our initial set of requirements. Now we have to use our brains (which is what you’re getting paid for) to reason about how the system will work when real people use it in their environments. From this we derive a set of essential features and technologies and create the essential shape of our system, which we call the architecture.
- What is essential to a product depends upon your point of view. Each stakeholder has a different viewpoint, some of them are important to your project and some aren’t. For example, the height of the dog door and the speed and force with which it closes are quite essential to the hardware designers. However, they are unimportant to the software system. The fact that you have a timer task that determines when to close the door is very important to your software system, but invisible to the hardware folks and the customers. There are, however, some places where views overlap. For example, the of signal sent from the remote or bark recognizer to the software is essential. It’s important that the hardware can send the right signal at the right time and it’s important that the software can react to the signal properly.
- Phiippe Kruchten published an article called Architectural Blueprints—The “4+1” View Model of Software Architecture, in IEEE Software, Nov. 1995. In the article he describes how scenarios (therefore, use cases) overlap four other primary views of a system. This slide is taken from that article and shows the four views, how they relate to each other, and who cares about them. The callouts show the type of information that is stored in each view. If you have the scenarios or use cases developed properly, you are well on your way to covering the set of essential elements that everyone cares about.
- Here’s 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. We’ve 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 we’ll 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 we’re talking about an object. Bruce is an actor, and an object here. He’s a specific instance of the Dog actor. (If you’re 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 don’t think they’re that useful for our analysis needs.
- This is the same diagram as the previous one except that we’ve change Bruce to “aDog”. We’ve generalized the scenario. Does this make you think of anything? In the text we talked about “the owner’s 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 isn’t 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 didn’t, 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?
- We need to be able to recognize a bark and make sure that it’s a bark from a dog who we want to open the door for. Who should be responsible for doing this? Should we put the responsibility in the BarkRecognizer or DogDoor class or do we need a new class or classes to handle this responsibility? Before going to the next slide, think about how you would do that and why your solution is a good one. We’ve introduced a new UML element here. The Note is a rectangle with a folded down corner. It is attached (anchored) to any other element by a dashed line.
- We added a new class. The object instance of it is called barkManager. The class name will probably be BarkManager. The BarkManager has the responsibility for determining whether a bark is one that should open the door. We put the responsibility for recognizing a bark in a separate class because if we put it in the BarkRecognizer class, then the BarkRecognizer would have two responsibilities, telling the door to open and deciding if the bark is “valid.” Now, this may not seem like a big deal in a simple system, but you should be getting in the habit of creating classes with single responsibility. The BarkRecognizer requires knowledge of whether the bark is valid, but it delegates that responsibility to the BarkManager class. This solution is a little different than the solution in the text at this point. If you don’t take this approach just yet, that’s okay, but this is a good place to get you familiar with some of the design trade-offs that you’ll get in the habit of making easily as you get more practice.
- You might have noticed that we didn’t show the Bark class in the previous diagrams. That’s because the Bark is basically a data container class. That is, it’s a record, or structure that contains fields we want to look at, but so far it has no behavior. The only methods are those that get the value of the data stored in the object (the fields). The manager, however, is responsible for accessing the data objects. It gets them from secondary storage and stores them in the storage when appropriate. These operations, shown in the last set of bullets are commonly abbreviated CRUD. Can you think of any behavior that a Bark object should have other than getting the data that identifies the bark?
- Notice that the use case doesn’t mention the BarkManager object. We could put it in, but that’s not really necessary. The customer or stakeholder who’s reviewing the use case probably doesn’t care about it. The developers who have to implement the system will. There’s no right answer. The important thing is to make sure that all of the necessary information is available to the team members who need to know about it. There are different levels or views of the information for the various team members and stakeholders. The sequence diagram shows the BarkRecognizer and shows the developers how it will be used.
- 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 don’t support the way you work aren’t very helpful.
- There is seldom just one use case for a system, even simple systems. The change we just made should make you think of at least one more use case. How many can you think of for the dog door software system? (Answers appear on click) Not all of the use cases in this slide can be inferred from the information we have from the stakeholders’ requirements at this point. We include them here to show you the possibilities that might exist. As you become familiar with the system and what your customers want, you might uncover a use case that is important to the customer that she hasn’t thought of yet. You can ask to present the use case as a possibility and let the customer decide. Often, some of the use cases are easy to implement and provide just the feature that will sway the customer to buy your system rather than your competitor’s. We often call these features delighters. In this slide, the first two use cases can be obtained from the requirements thus far. You certainly need to add a dog’s bark to the system’s database (a file, or some other persistent storage) so you can determine if a bark is one that should cause the door to open. If you can add a bark, you probably need to delete a bark. You certainly will need to retrieve the bark when you try to compare it to one sent by the bark recognition hardware. You probably don’t need to “update” a bark since it’s most likely in a form that you won’t edit. We still mark the use case as a CRUD use case. We also don’t have to provide too much detail on it since these operations are usually well-understood by the developers. If you look in the text on p. 154, there is a description of the use case to store (create) a bark. You can decide if it needed to be written out at all. Systems don’t run forever. They might stop because of power failures, but more likely will be shut down when the customer goes on vacation. They then have to be restarted. There might not be too much to do in this system, but it’s a good idea to include an initialization use case. If you’re paying attention, you should be asking if we need a system shutdown use case. The answer is “yes.” This is usually a good idea too. We just wanted to see if you were paying attention. The last two use cases on this slide are ones that we came up with as we talked about what the system might do. We might not have to implement these for our first version, but if you think of something, even if the customer doesn’t want it yet, it’s not a bad idea to store the ideas away so that when you’re finished with version 1.0 and you get tired of counting all the money you made on it, you can come revisit these ideas and work on a “new and improved” version that you can sell for a higher price. Of course, once your customer sees a use case like #3 here, they might decide they need it in the first version. This seems like an important thing. Let’s say Fido swallowed your spouse’s wedding ring and you don’t want him to go out unless you’re with him. You might want to make sure the door doesn’t open even if Fido barks.
- This is a great question. Use cases aren’t 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 we’ll 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. We’ll describe the main use case using each of these techniques. These aren’t the only alternate techniques, but we’d 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 doesn’t need any other classes to help it perform its responsibilities. We’ll see examples coming up where this is not the case.
- In this diagram, we have five classes that we’ve 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 it’s 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, don’t. 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. They’re not as complete and they don’t necessarily define actions from the user’s 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 we’ve 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 didn’t 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 Sam’s 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 Sam’s 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 doesn’t seem to be a difference except for a couple of minor changes that are almost cosmetic. Is it worth it?
- Did you figure it out? The reason that encapsulation is so important is that it helps us manage change. If, for example, the hardware sends a special format of audio file that requires special algorithms to compare two such files, we can hide that behind the equals method of the Bark class and we have isolated the changes to the Bark class and perhaps any of its delegates. Encapsulation and delegation go hand-in-hand. We encapsulated the bark and delegated the behavior for comparing two barks to the Bark class.
- Maria’s change is a simple extension to Sam’s 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: We’ve already taken care of the problem in our solution, but this is the point where, if we hadn’t 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. Let’s look at one possible solution.
- We haven’t included the fields and methods in the diagram. For our purposes now we are focusing on the multiplicities of the associations between the classes. We’ve added some comments to the diagram so you can follow the reasoning. It doesn’t take a lot of effort to reason about how the different objects might be related as we analyze the requirements.
- We’ve 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. Let’s take a look at textual analysis. This technique has been around for a long time.
- Here’s 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 aren’t sure. When you’re not sure, add the class to the set of classes you think you need. If you really don’t need it, you’ll 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 aren’t.
- 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.