[b]Ch1.[/b]
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.
[b]Ch2.[/b]
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.
[b]Ch3.[/b]
1. requirement always change.
2. alternate path makes several scenario for one use case.
[b]Ch4.[/b]
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.
[b]Ch5.good design=flexible software using basic OO principle. [/b]
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
[b]Ch6.complicated system[/b]
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.
[b]Ch7. building orders.[/b]
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.
[b]Ch8. design principles[/b]
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.
[b]Ch9. iteration and testing[/b]
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
[b]Ch10. put all things together[/b]
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.
[b]Appendix I[/b]
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
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.
[b]Ch2.[/b]
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.
[b]Ch3.[/b]
1. requirement always change.
2. alternate path makes several scenario for one use case.
[b]Ch4.[/b]
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.
[b]Ch5.good design=flexible software using basic OO principle. [/b]
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
[b]Ch6.complicated system[/b]
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.
[b]Ch7. building orders.[/b]
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.
[b]Ch8. design principles[/b]
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.
[b]Ch9. iteration and testing[/b]
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
[b]Ch10. put all things together[/b]
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.
[b]Appendix I[/b]
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
扫一扫
1855
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
