Object-oriented analysis and design knowledge summary

Object-oriented analysis and design knowledge summary

---

Examination Content

%50 Basic concepts involved in the textbook

15% Design a simple static conceptual model or static design model according to business needs

15% refactor

20% design pattern

---

Design pattern examination scope

Strategy mode (Strategy)

Observer mode (Observer)

Concrete Factory Mode (Concrete Factory)

Single instance mode (Singleton)

• Iterator mode (Iterator)

• Decorator mode (Decorator)

• Combined mode (Composite)

The asterisks are supplementary content

---

PPT knowledge points (no corresponding points in the book)

Chapter2.5 Object Oriented Introduction

1. A pure object-oriented programming language does not guarantee to write an object-oriented style program, the key point is whether the programmer of the program conforms to the object-oriented programming paradigm
2. Use delayed binding mechanism to achieve polymorphism
3. Whenever you find that you know how to use this class by looking at the internal implementation, you are not programming for the interface.

Chapter 22.1 Test Driven Development

1. Traditional test methods and problems

• Tests are often incomplete, leading to missed errors
• Testing is often carried out by dedicated testers, who are often not familiar with the details of the program
• Testers usually think about what to test based on documents, not code, and these documents are easily out of date and inconsistent with the code
• Most tests are based on manual and cannot be done automatically, so they cannot be performed frequently

2. What is test-driven development?

• Write unit test cases first, then code
• Test to determine what kind of code is needed
• Complete set of test cases written and maintained by programmers
• Only when the code has the corresponding test code, the code can be used as the finished code

3. Advantages of test-driven development

• Can guarantee to write unit tests
• Make programmers feel satisfied, so that they can consistently write tests
• Help clarify the details of the interface and behavior
• Provable, reproducible, and automatically verifiable
• The confidence to change things

4. Points to note when writing test cases

• Use setup() and tearDown() to create, initialize and release common test objects and required environments between test cases
• Make sure the test has no side effects
• Ensure that there are no dependencies between test cases

5. Pros and cons of mock objects

• Advantages: no need to run the container to execute the test
• Disadvantages: no interaction between the test container and the component, no deployment part of the test component, a good understanding of the called API is required to simulate it (this may be difficult)

Chapter 21.2 Refactoring

1. Layout and Style

• Good visual layout shows the logical structure of the program
• A small part of programming work is to make the machine understand the code, and most of the content is to make other people understand the code
• The goal of a good layout: accurately express the logical structure of the code, consistently express the logical structure of the code, improve readability, and withstand modification

2. Layout techniques: white space, brackets, use other tools

3. Self-Documenting Code

   1. Programming Style as Documentation: The main contributor to code-level documentation is not comments, but good programming styles. These styles include-good program structure, variable naming, clear layout, and the use of named constants instead of literals.
   2. To Comment or Not to Comment: The comment should be a summary of the code, a description of the intent of the code, and information that cannot be expressed by the code itself, avoiding duplication of code, interpreting the code, and marking in the code. The optimal number of comments : one comment for every 10 statements. Too few comments will make the code difficult to understand, and too many comments will reduce the readability of the code.

4. Refactor

   1. Software evolution philosophy : If you realize that evolution in the development process is an iterative and important phenomenon and execute it as planned, then you can benefit from it; evolution should improve the internal quality of the program.
   2. What is refactoring : A modification to the internal structure of the software that makes it easier to understand and cheaper to modify without changing the external behavior of the software.
   3. Reasons to Refactor :
      1. Code duplication
      2. Method is too long
      3. The loop is too long or the nesting is too deep
      4. Class cohesion is low
      5. The interface does not provide a consistent level of abstraction
      6. The parameter list is too long
      7. Modifications to a class are often separated (class cohesion is low)
      8. Changes often need to modify multiple classes in parallel (the coupling between these classes is too high and can be combined into one class)
      9. The inheritance hierarchy must be modified in parallel
      10. The case statement needs to be modified in parallel (there is a problem with the inheritance structure and needs to be adjusted)
      11. Data items used together are not organized into a class
      12. A method uses the properties of other classes more than the properties of the class it is in
      13. Basic data types are overloaded
      14. One class does not do too many tasks
      15. One class is too close to another
      16. Poorly named function
      17. Data member is public
      18. The subclass uses only a small part of the superclass function
      19. Comments are used to explain complex code
      20. Use global variables
      21. The code contained in a program seems to be used someday
   4. Refactor safely : Save the code before starting the refactoring, keep the refactored part as small as possible, do only one refactoring operation at a time, make a refactoring list, check frequently, pay attention to compiler warnings, re-test, and add tests Use cases, review changes

Iterator mode (Iterator)

1. Motivation: Aggregate objects like lists should provide you with a way to access their elements without exposing their internal structure. In addition, you may want to traverse the list in different ways, depending on the task you want to accomplish. The iterator pattern allows you to accomplish all of this. The key idea of ​​this mode is to be responsible for accessing and traversing the list object and putting it into the iterator object.
2. Purpose: To provide a way to access aggregate object elements sequentially without disclosing its underlying representation.
3. Applicability: access to the content of aggregate objects without disclosing its internal representation; support multiple traversals of aggregate objects; provide a unified interface for traversing different aggregate structures
4. Participants: Iterator, ConcreteIterator, Aggregate, ConcreteAggregate

Combined mode (Composite)

1. Motivation: Users of graphical applications can group components to form larger components, and these components can be grouped to form larger components. The base object and the container object should share the same interface.
2. Purpose: Combine objects into a tree structure to represent part-whole hierarchy. Composite allows the client to uniformly handle single objects and combinations of objects.
3. Applicability: You want the client to be able to ignore the difference between the combination of objects and individual objects. The client will uniformly process all objects in the combined structure.
4. Participant
   1. Component: Declare the interface of the object in the combination, and implement the default behavior for the interface common to all classes as needed.
   2. Leaf: The leaf node in the combination, without child nodes, defines the behavior of the base object in the combination.
   3. Combination: Define the behavior of components with children and store child nodes.
   4. Client: Manipulate the objects in the composition through the component interface.
   5. Attention : Both leaves and combinations implement component interfaces.

---

Knowledge point quick reference table

Knowledge points	Book page code
What is analysis and design?	5
The difference between analysis and design	5
What is object-oriented analysis and design?	5
The relationship between object-oriented analysis and object-oriented design	5
Define the domain model	6
Define interaction diagram	7
Define design class diagram	7
What is UML and three ways to apply UML	8
What is the software development process	13
What is iterative development	15
Iteration time box	15 \ 17
A three-week iteration example	15
How to handle changes in iterative projects	16
Why iterative \ advantages of iterative development	17
UP unified process	14
Agile Manifesto	21
Agile principles	21-22
敏捷UP（Agile UP）	23
UP stage	25
UP subjects	25-26
Determine whether you understand iterative development or UP	28-29
What is the initial stage	36-37
Duration of the initial phase	37
Products created in the initial stage	38
Misunderstanding at the initial stage	39
What is demand	40
How to obtain demand	40
Evolutionary demand and waterfall demand	41
Classification of needs	42
How UP organizes demand	43
What are use cases?	47
Use case definition	47
Three representation methods of use cases\ format	49
Use case writing guideline 1: Write use cases in a style without user interface constraints	61
Use case writing guideline 2: Write concise use cases	62
Use case writing rule three: adopt the participant’s perspective	62
Use case writing guideline 4: keep the black box style	62
How to discover use cases	62-63
Boss test, EBP test, scale test	66
UML use case diagram	67
Other methods of describing requirements (UML activity diagram, feature list)	69
Other demand products	76
Supplementary specifications	78
Glossary	87
Imagine	82
Business Rules	88
Requirements and focus of iteration one	92
The contents completed in the initial stage are	94
Where the refinement	95
Refined products	96
What is a domain model	100
Domain model expressed by UML	101
Domain model is not a model of software objects	101
Domain model is not data model	102
How to create a domain model	104
Concept class and its notation	102
Three strategies for finding concepts	104
Find conceptual classes by identifying noun phrases	105
Several guidelines for finding and describing conceptual classes	107-108
The problem of not using the description class	110
Related	111
Association naming	113
Role	113
Multiple associations between two classes	114
Attributes	117
Proper attributes	117
When to define a new data type	120
No attribute represents a foreign key	121
What is a system sequence diagram	128
UML sequence diagram and system sequence diagram (SSD)	129
How to name system events and operations	130
SSD and glossary	130
Why an operation contract is needed	133
What is system operation	135
Components of an operating contract	135
Steps to write an operation contract	139
Why a layered architecture is needed	147
Design with layers	149
Problems solved using layers	149
Do not represent external resources as the lowest level	153
Model-view separation principle	154
什么是动态模型和静态模型	156
交互图比类图重要	159
CRC卡	159
交互图的两种类型	161
顺序图和通信图的优点和缺点	163
交互图中的单实例对象	165
顺序图的基本表示法	166
表示回答或返回	167
发送给自身的消息	167
UML顺序图中的图框	168
交互图的关联	172
主动对象	174
UML顺序图中异步和同步调用的表示	174
通信图的基本表示法	175
UML类图中的类型	180
属性表示	182
表示集合属性	185
依赖	189
组合优于聚合	191
UML类图中接口的表示	191
限定关联	192
UML类图中单实例类的表示	193
职责和职责驱动设计	198
行为职责和认知职责	200
GRASP的作用	200
什么是模式	201
怎样降低依赖性，减少变化带来的影响	206
耦合与低耦合	206
高内聚	227
内聚性低导致的问题	227
内聚程度的一些场景	229
内聚与耦合的关系	229
创建者	210
最好把创建职责委派给工厂类	212
信息专家	212
信息专家的优点	215
控制器	208
控制器的优点	209
对象的可见性	261-262
实现全局可见性的推荐方法是使用单实例类	264
变量作用域的管理	265
将设计映射为代码	265
多态所解决的问题	301
何时使用接口、何时不使用接口	300
纯虚构	306
间接性	309
防止变异	310
防止变异的方法	311
与保护变化有关的几个原则	312
变化点和进化点	314
单实例类（单例模式）	321
不能将单实例类中的所有方法定义为静态方法的原因	323
适配器模式	317 \ 324
工厂模式	319
策略模式	324
使用工厂和单例模式创建策略对象	327
观察者模式	337
观察者模式的特点	340
MVC	316
活动图的应用	346
使用活动图建模的一些准则	350
令牌	351
UML状态机图	352
用例关联简介（作用）	357
用例的包含关系	358
包含关系的使用场景	359
扩展关系	360
识别领域模型中概念的方法	364
泛化	365
泛化准则	367
将概念划分为子类的动机	368
何时定义概念超类	369
抽象概念类	371
对变化的状态建模	372
关联类	373-374
领域模型中引入关联类的场景	375
组合和聚合关系	375-376
使用组合关系的情形	376
显示组合关系的用处	376
使用包来组织领域模型	380
如何划分领域模型	381
组织包结构的准则	381