软件设计模式

《软件设计模式》课堂笔记。
更新中喔 ️๑•́₃•̀๑

Object-oriented Software Design

The Agile Unified Methodology (AUM)

methodology: how
method: framework

Use case Modeling

What’s use case? A business process, begins and ends with the actor (attention: not the system!!!), and the actor tells the complishment of the process.

3 levels of abstraction:
1 st. Abstract Use Case: Noun + Verb. (The usual meaning of use case)
2 nd. High Level Use Case: when, where it begins with / ends with.
3 rd. Expanded Use Case: how to interact with the system. A two column table (the actor and the system, list their action and the response respectively).

| requirement | Verb-noun phase | business process | Begin with actor | End with actor | Task for actor is meaningful | Use case | Actor | System |

STEPS:

  1. Derive use cases from requirements
  2. Verify them (all three factors of the use case)
  3. Priortize the requirements (i.e. the effort to achieve them)
  4. Identify the actor, system and the subsystem (to what the use case belongs).

—> use cases + scopes —> Actor System Interation Modeling (ASIM) —> Object Interation Modeling (OIM). Business process = foreground process + background process. ASIM: foreground process, OIM: background process.

An example of the subsystem of the library system: the circulation system.

Note the difference between action and BP.
i.e. action: click the button. BP: book a room.

What’s the difference between object & attribute?
attribute: scalar type (the base of judgement), can be typed in, but can not exist indenpently.


Domain Modeling.

  1. Collect domain level information.
  2. Brainstorming
    How to identify domain specific things?
    no domain specific: can be applied to different domains.
    domain specific: maybe some application also has it, but they are different. –> take them into the domain model.
  3. Classfying brainstorming result.
    | classes | attributes / attribute values | relationships |
  4. Document result using UML class diagram

Relationship

Three types of relationship: Inheritance, Aggregation and Association

  • Inheritance: IS-A relationship
    • Conformance test: relationships of superclass are also relationships of subclass. (ATTENTION: EASILY BE IGNORED!!!)
    • IS-A test: every instance of subclass is also an instance of superclass.


≈ OR (in math)

  • Aggregation: part-of relationship


≈ AND (in math)

  • Assocaition: (maybe it effects) data integrity. How to store the information about the association? (the location)
    • 1:1 (either), 1:m, m:1, m:n


Association class: defines properties and operations for an association between two classes.


Object Interation Modeling (OIM)

background process –> sequence diagram
scenarios and scenarios tables.

  1. find the nontrivial steps.
  2. divide the scenario: subject, action, object, (possibly) other objects required by the action, and draw the scenario table.
  3. convert the scenario table into the sequence diagram


    << >> 表示 UML 不能表示的东西。

Taking search for a doc file as an example:

  1. Simple Analysis
  • System retrieve doc call number
  • System search db using the call #
  • db returns doc into the system
  • System displays doc into the patron
  1. Refinement
    Patron enters doc call # and clicks Submit button
    2.1 System checkout GUI checks out doc with Checkout controller using call #
    2.2 Checkout controller retrieve doc from DB manager using call #
    2.3 DB manager returns doc to Checkout controller
    2.4 Checkout controller updates doc
    2.5 Checkout controller save doc with DB manager
    2.6 Checkout controller return checkout message to GUI
    2.7 Checkout GUI display checkout msg to Patron
  2. Analysis Using a Table
no. subject action other objects object
1 Patron enters doc call # Checkout GUI
2.1 Checkout GUI checks out doc using call # Checkout controller
2.2 Checkout controller retrieve doc using call # DB manager
2.3 DB manager returns doc Checkout controller
2.4 Checkout controller updates doc
2.5 Checkout controller save doc DB manager
2.6 Checkout controller return checkout message GUI
2.7 Checkout GUI display checkout msg Patron
  1. Draw Seq. Diagram

    这是 informal/analysis seq diagram。但是这样具有二义性,因此我们可以将 << >> 内的内容替换为函数调用 –> formal/design seq diagram
    做法:除了保留人机交互外,其他的全部用函数调用替换。

Design Seq Diagram

Design class diagram (DCD): classes, attributes, relationships between the classes and operations/functions/methods. What’s more, the design pattern. Design classes and implemention classes.

Domain model class diagram (DMCD): classes, attributes, relationships. Domain model only contains domain application objects (classes).

The classes of DCD and DMCD are different (thus resulting the difference of attributes and relationships). But they have something in commn.

Steps for Deriving DCD

  1. Identify all classes used in each of the sequence diagrams and put them down in the DCD
    1.1 classes of objects that send or receive messages
    1.2 classes of objects that are passed as parameters or return types/values
  2. Identify methods belonging to each class and fill them in the DCD
  3. Identify and fill in attributes from sequence diagrams and domain model (scalar types)
  4. Identify and fill in relationships from sequence diagram and domain model:
  • arrows from one object to another is a call and hence it is a dependence relationship
  • objects passed as parameters or return type/value is an association or uses relationship
  • two or more objects passed to a constructor may indicate association and an association class
  • the domain model may contain useful relationships as well

–> finally: seq. diagram to code.


ASIM

expanded use cases


Design Patterns

26 design patterns in total.

Intro.

design pattern —> maintainace & extensiblity
Most design patterns are not meant to improve efficiency or performance.

The following content is purely from my personal opinion, I can not guarantee that they are all right. Please contact me if you find any error.

Where does the design pattern derive from, or, how to design a system?
Firstly, we should analyze the system type, that is, we should know how the data and the control signal flows. Different system types correspond to different solutions. So, what is system type? There are interactive system (Ch 5-11), event-driven system (Ch 13) and tree system. The sequence diagram, activity diagram and <??? I forget it> are used to discribe them, respectively. In general, the interactive systems are described using multi-tier architecture (i.e. tier 1 is controller, tier 2 is DB manager, and so on), the event-driven systems are described using state machine, and the tree systems are described using tree diagram. The design pattern we learn in this class are only used to solve problems we encounter in interactive system.
Secondly, we should analyze the software architecture. This is beyond the topic of this blog and I have already introduced software architecture in this post.
Finally, we use design pattern to design the project for specific problem.
(I’ve not consider the sequence between the 2nd and the 3rd point clearly.)

So, what is design pattern on earth? In my opinion, design pattern is a design idea that provides a general solution to a common set of problems.
Based on this opinion, I think that when we are learning software design pattern, we should analyze the problem we are meeting now, know the pros and cons of each design pattern, and choose a suitable pattern (solution). This is an iterative process.

Based on my opinion above, when introducing each design pattern, I will analyze the problem we meet, the characteristic of each pattern, and its advantages and disadvantages.

P27没大听懂

Three Commonly Used GRASP Patterns

implementation of GUI: Swing, AWT, JSP

Controller Pattern

benefits: separation of concerns –> UML 9 diagrams are also used to separation concerns.

Facade Controller

Role Controller

Use Case Controller

use case <--> GUI <--> Controller
一一对应

i.e.

use case GUI Controller
Login LoginGUI/LoginJSP LoginController
Checkout doc. CheckoutGUI/CheckoutJSP CheckoutController

Expert Pattern

Pattern Other
controller pattern who should be responsible for handling an actor request –> controller the controller does the business logic
expert pattern who should be responsible for handling a request from an object (obj to obj) –> info expert, who has the info (attribute) to fulfill the request the expert does not do the business logic
creator pattern Who should be responsible for creating an object?

//还是没大理解透控制器模型和专家模型的区别

23 Patterns

Bridge Pattern

DBMagr 下有很多 implementation,IF 下也有很多,这两者如何区别?

Template Method

common steps of every subclass –> put them into parent class
different steps –> put them into subclass –> hook method //what’s the relationship between hook method and hook function in Linux Kernal 桩方法
template method: reused by the subclasses

Factory Method

工厂模式是模板模式的一个特例。

Summary of Patterns

Name
Abstract factory You want to create objects of a selected family of classes but you don’t want the client to be affected by the choice. –> misuse (why?)
Adapter You want to convert one interface to another.
Bridge You want to switch between different implementations at run time without affecting the client.
Builder You want to change the processes and process steps at run time to produce various categories of products.
Chain of responsibility You want to pass a request along a reconfigurable chain of handlers until one that handles it.
Command You want to encapsulate requests as (command) objects so that you can: (1) delegate the requests to the command objects, (2) queue the requests and execute them at a different time, (3) generate a plan of actions dynamically, and/or (4) stack the requests to support undo and redo.
Composite You want to represent components with recursive part-whole relationships and allow the client to interact with components and composites uniformly.
Decorator You want to dynamically add/remove functionality to/from objects.
Facade You want to simplify the interface for a client that interacts with a web of components.
Factory method You want to create or use objects of different classes but you want to delay the decision to the subclasses so that the decision can be changed at run time.
Flyweight You want to save time and space incurred in the creation, initialization, and storage of many occurrences of an object.
Interpreter You want dynamic modification of a portion of your program but you don’t want to recompile the system.
Iterator You want a traversal mechanism that hides the structure traversed.
Mediator You want to simplify the complex interaction among several components.
Memento You want to store and restore the state of an object but you don’t want to expose the internals of the state to a third party.
Observer You want to decouple change and related responses so that you can add or remove such dependencies freely and dynamically.
Prototype You want to: (1) reduce object creation and initialization costs, (2) reduce number of classes, or (3) use dynamically loaded classes.
Proxy You want to: (1) hide the use of a remote object, (2) defer creation of an object until it is actually used, (3) control access to an object, or (4) keep track of references or update to an object.
Singleton You want to create at most one or a limited number of globally accessible instances of a class.
State You want a low complexity and easy to extend solution to implement a state machine.
Strategy You want to let the client select an algorithm from available algorithms to accomplish a given task.
Template method You want the steps of a computation to vary but you don’t want to do so with conditional statements.
Visitor You want to decouple type-dependent operations from a class structure to achieve high-cohesion and designing “stupid objects.”

Homework

第一次提交:

  • Domain modeling: Brainstorming (class, attribute, relationship) + classification sheets + domain model class diagram (include association classes)
    sw: ArgoUML
  • Deriving use cases from requirements: Brainstorming (Excel) –> 9 个要素
    | requirement | Verb-noun phase | business process | Begin with actor | End with actor | Task for actor is meaningful | Use case | Actor | System/Subsystem |

    use case diagrams —> 根据 use case 划分功能子系统

TUCBW –> click the button
TUCEW –>

第二次提交:

  • ASIM: find 3-4 use cases –> expanded use cases
  • OIM: find nontrivial step –> scenarios –> scenarios tables –> informal seq. diagrams –> design seq. diagrams
  • DCD

We should put the controller pattern, expert pattern and creator pattern into the scenario. (finally: apply 6 patterns every team)


4 use cases:

  1. Create an online Account (actor? sys?)
  2. Login NTSS (actor? sys?)
  3. Submit an event proposal (actor? sys?)
  4. Evaluate an event proposal (actor? sys?)

做第二次提交的内容

1.2 下周交,全部的学期结束后交