软件需求与建模 复习笔记

Use Case

generalization
<< include >>: Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case. (happens every time when the including use case is executed)
<< extend >>: Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case. (only happens when the extended use case meets certain criterion)

Generalization: <|--
<< extend >> & << include >>: <..
Association: --

Domain Model Diagram

Noun extraction
Add relationship classes
Add controllers
Does not represent software classes: no methods, no artificial, programming-related (e.g. interface classes) classes;
Common mistake in a domain model: representing something as an attribute when it should be a concept;
要将概念的属性与概念本身分离开来，单独列为两个类

Class Diagram

Aggregation: o--
Association: --
Use: <..
Generalization: <|--
Implementation: <|..

Drawing utility:
PlantUML

Sequence Diagram

Emphasizes the order of messages between objects.

• lifeline box
• message -->
  • return message <..
• create: ..>
• destroy: x
• loop & alt

State Chart Diagram

Emphasizes the state transitions caused by events.

notations:

• state
• transition
• event
• guard condition
• start/end marker

Activity Diagram

Emphasizes the order of steps that are taken to finish a task and the participants involved.

notations:

• activity
• transition
• decision diamond
• splitting bar & synchronization bar
• start marker: a solid ball; stop marker: a solid ball inside a circle
• swim lane:

GRASP

General Responsibility Assignment Software Patterns:

• Creator 创建者

• Information Expert 信息专家

• Controller

• Low coupling 低耦合. Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

• High cohesion 高类聚. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system.

OOD Principles

• Single Responsibility Principle: if we have two reasons to change for a class, we have to split the functionality in two classes. 单一职责原则
• Open Close Principle: classes, functions and modules should be closed for modifications, but open for extension. 开闭原则
• Dependency Inversion Principle: High-level modules should not depend on low-level modules but their abstractions. 依赖倒置原则
• Interface Segregation Principle: instead of one fat interface, many small interfaces are preferred. 接口隔离原则
• Liskov's Substitution Principle: derived types must be completely substitutable for their base types. 里氏替换原则
• Composition Reuse Principle: favor composition of objects over inheritance as a reuse mechanism. 合成复用原则

Design Patterns

Factory pattern
Facade pattern
Composite pattern: transparent vs. safe
Observer pattern
Decorator pattern
Adapter pattern: transparent vs. semi-transparent
Strategy pattern