HeadFirstOOAD_Ch04.ppt

Editor's Notes

• #2: 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.
• #3: 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.
• #4: 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.
• #5: 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.
• #6: Answers appear on click
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #12: 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.
• #13: 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.
• #14: 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?
• #15: 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?
• #16: 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.
• #17: 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.
• #18: 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?
• #19: 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.
• #20: 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.
• #21: 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.
• #22: 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.
• #23: 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.
• #24: 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.
• #25: 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.
• #26: 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!?
• #27: 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.
• #28: 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.
• #32: 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.
• #33: 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?
• #34: 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?
• #35: 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.
• #36: 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.)
• #37: 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.
• #38: 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.
• #39: 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.
• #40: Here’s a simple recipe for finding classes from a requirements document, like a use case. Finish the textual analysis on this document.
• #41: 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?
• #42: 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.
• #43: 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.
• #44: Before going onto the next chapter, you might want to try your hand at implementing the code for the design shown in slide 39.