Ch1.
1. do what customer what. meet the requirement is always the first priority.
2. then think about using basic OO principle and design pattern
3. encapsulation also for code reuse. encapsulate what varies.
4. delegation. instead of doing the action, forward to another object to do the action.
5. separate relatively stable code to change frequently code.
Ch2.
1. main path to handle the main work flow and alternate path to achieve the goal when users do not follow the common rule. always consider something else that even the customer did not consider and did not tell. make a use case to a requirement.
2. use case describe a function or a goal to achieve by a software system. it will have an external initiator, start condition, end condition, clear value(that the function the system provided.) A use case is simply several scenario that how the system works to realize an function.
Ch3.
1. requirement always change.
2. alternate path makes several scenario for one use case.
Ch4.
1. what is OOA? using OO methodology to figure out the problems of the app and resolve them before release the app.
2. text analysis of the use case, nouns and verbs are good candidate for class and class behavior.
Ch5.good design=flexible software using basic OO principle.
1. do initial analysis. find problems that do not looks right.
2. cohesion. one class just do one thing. each class should have only one reason to change. high cohesion means loosely coupled which end in flexible software.
3. review basic OO principle to find solutions.
3.1 inheritance: abstract same attribute and behavior
3.2 encapsulation: protect attribute not accessed by other class. and also encapsulate what varies.
3.3 polymorphism: code to interface instead of implementation
3.4 abstraction: define behavior and subclass implement the behavior
4. after redesign. review the design to see how many classes need to change when requirement changes. the best way to see how the software is designed is try to change it
Ch6.complicated system
1. domain analysis and feature list to requirement. break down big problem to small ones and resolve one by one.
2. use case diagram for blueprint, helping for seeing the whole system. feature check when done to see if missed something
3. then, design pattern--a way to design a solution for particular problems.
Ch7. building orders.
1. after breaking down big problem to pieces of small problems(use cases extracted from requirement), which problem to resolve first?
1.1. essence problem which is the base of the application.
1.2 things that not clear what it is.
1.3 things that not clear how to implement it.
2. commonality analysis. if commonality are even less than variation, generation may not be a good solution
3. focus on one feature that would reduce the risk at one time.
4. architecture highlight the most important part of the app and the relationships between these parts.
5. a scenario would be helpful to gather requirement quickly.
Ch8. design principles
1. inheritance
2. delegation
3. composition
4. aggregation
5. close for modification and open for extend.
6. one class do one thing. cohesion. class behavior belongs to this class. class do not do other behavior which is not him, self check.
7. do not repeat yourself. place code in a single place to use. not only for code but also for requirement and feature analysis
8. subclass is substitutable for super class. otherwise inheritance is not a good choice. using others. super class behavior should be meaningful for subclass.
Ch9. iteration and testing
1. which function to start? feature list driven and use case driven.
2. testing: creative thinking, not only the normal situation but also error handling
3. contract programming and defensive programing
4. design is a trade off
Ch10. put all things together
1. feature list--> use case diagram--> break up to modules-->
for each model
requirement--> domain analysis--> preliminary design-->implementation
2. feature list is about the system functionality. use case is emphasize on that how user use the system.
Appendix I
1. ways to write use case, crc card
2. sequence diagram
3. statechart diagram
4. metrics
5. coding format
6. unit test
7. problem of is-a and has-a
8. anti pattern
9. refactoring
分享到:
相关推荐
NULL 博文链接:https://mydownload.iteye.com/blog/1350398
Java OOA & OOD & UML
OOA&OOD面向对象分析实验报告.doc
NULL 博文链接:https://clarkhtht.iteye.com/blog/582549
“《深入浅出面向对象分析与设计》对OOA&D这个主题的探讨令人耳目一新。 本书与众不同之处在于它将焦点摆在学习上,本书的诸位作者让从业人员对OOA&D的内涵不再感到遥不可及,而且它在实际工作中确实有用。” ...
“《深入浅出面向对象分析与设计》对OOA&D这个主题的探讨令人耳目一新。 本书与众不同之处在于它将焦点摆在学习上,本书的诸位作者让从业人员对OOA&D的内涵不再感到遥不可及,而且它在实际工作中确实有用。” ...
“《深入浅出面向对象分析与设计》对OOA&D这个主题的探讨令人耳目一新。 本书与众不同之处在于它将焦点摆在学习上,本书的诸位作者让从业人员对OOA&D的内涵不再感到遥不可及,而且它在实际工作中确实有用。” ...
“《深入浅出面向对象分析与设计》对OOA&D这个主题的探讨令人耳目一新。 本书与众不同之处在于它将焦点摆在学习上,本书的诸位作者让从业人员对OOA&D的内涵不再感到遥不可及,而且它在实际工作中确实有用。” ...
圖解基於UML的面向對像分析與設計 本文以实例的方式,展示了如何使用UML进行面向对象的分析与...本文的目的是通过一个完整的实例,展现基于UML的OOA&D过程的一个简化模式,帮助朋友们更好的认识UML在OOA&D中起的作用。
一、导言为什么要写这个系列“OO都是一个已经被讨论烂的话题了,还有什么可写的!”不知当你看到文章标题时,是不是有这种疑问,或者鄙夷。不错,OO从诞生到现在经历了不短的岁月,与其相关的理论、技术、原则、实践...
《深入浅出面向对象分析与设计...你是否早已对市面上那些只有在成为专家以后读起来才有感觉的OOA&D书籍感到厌倦?你可能早就听说过OOA&D书籍能帮助你写出伟大的软件——让老板高兴、客户满意的软件。但如何办到呢?
《深入浅出面向对象分析与设计...你是否早已对市面上那些只有在成为专家以后读起来才有感觉的OOA&D书籍感到厌倦?你可能早就听说过OOA&D书籍能帮助你写出伟大的软件——让老板高兴、客户满意的软件。但如何办到呢?
你是否早已对市面上那些只有在成为专家以后,读起来才有感觉的 OOA&D 书籍感到厌倦?你可能早就听说过 OOA&D 书籍能帮助你写出伟大的软件 — 让老板高兴、客户满意的软件。., 但如何办到呢?, 《深入浅出面向对象...
五、需求分析之前的故事高质量软件的第一要素到目前为止,我们做了很多工作,但是我一直在强调这些都还不是需求分析。在很多人心目中,软件开发的第一件事就是先做需求分析。那么我们为什么不这样做呢?...
因为它从各种OOA&D方法中吸取了大量的概念,并在“UML语义”、“UML表示法指南”、“对象约束语言规约”等UML文献中对这些概念的语义、图形表示法和使用规则作了完整而详细的定义。可以说,UML对系统模型的表达能力...
因为它从各种OOA&D方法中吸取了大量的概念,并在“UML语义”、“UML表示法指南”、“对象约束语言规约”等UML文献中对这些概念的语义、图形表示法和使用规则作了完整而详细的定义。可以说,UML对系统模型的表达能力...
HeadFirst系列OOA和OODPart4