Object oriented analysis and design
•Download as PPTX, PDF•
0 likes•800 views
Object oriented analysis and design of Use cases and softwares
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Object oriented analysis and design
Similar to Object oriented analysis and design (20)
Recently uploaded
Recently uploaded (20)
Object oriented analysis and design
- 1. Presenter : Aseem Jain Oct 10, 2014
- 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. Getting to the essentials 3 Gather requirements Analyze in real world context Develop the architecture
- 4. Scenarios unify the views Code structure Packages Libraries 4 Processors Data stores End-user Functionality Logical View Progress View Development View Physical View System engineers Topology Communications Integrators Performance Scalability Programmers Software management Scenarios Classes Objects Behaviors Threads Processes Communications
- 5. 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 5
- 6. A typical user story (revised) 6 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.
- 7. User stories for our main use case 7 I like this. Any additional words of wisdom?
- 8. 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 8
- 9. Comparing the three techniques 9 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
- 10. Textual analysis Nouns in requirements and documents Entities and concepts From the application domain Experience Previous systems 10 Where do classes come from?
- 11. 11
- 12. Questions ?
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.