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 |
- Derive use cases from requirements
- Verify them (all three factors of the use case)
- Priortize the requirements (i.e. the effort to achieve them)
- 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.
- Collect domain level information.
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.
- Classfying brainstorming result.
| classes | attributes / attribute values | relationships |
- Document result using UML class diagram
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.
background process –> sequence diagram
scenarios and scenarios tables.
- find the nontrivial steps.
- divide the scenario: subject, action, object, (possibly) other objects required by the action, and draw the scenario table.
- convert the scenario table into the sequence diagram
<< >> 表示 UML 不能表示的东西。
Taking search for a doc file as an example:
- 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
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
- Analysis Using a Table
|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.5||Checkout controller||save||doc||DB manager|
|2.6||Checkout controller||return||checkout message||GUI|
|2.7||Checkout GUI||display||checkout msg||Patron|
- Draw Seq. Diagram
这是 informal/analysis seq diagram。但是这样具有二义性，因此我们可以将 << >> 内的内容替换为函数调用 –> formal/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.
- 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
- Identify methods belonging to each class and fill them in the DCD
- Identify and fill in attributes from sequence diagrams and domain model (scalar types)
- 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.
expanded use cases
26 design patterns in total.
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.
implementation of GUI: Swing, AWT, JSP
benefits: separation of concerns –> UML 9 diagrams are also used to separation concerns.
use case <--> GUI <--> Controller
|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?|
DBMagr 下有很多 implementation，IF 下也有很多，这两者如何区别？
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
|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.”|
- Domain modeling: Brainstorming (class, attribute, relationship) + classification sheets + domain model class diagram (include association classes)
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
ASIM: find 3-4 use cases –> expanded use cases
- OIM: find nontrivial step –> scenarios –> scenarios tables –> informal seq. diagrams –> design seq. diagrams
We should put the controller pattern, expert pattern and creator pattern into the scenario. (finally: apply 6 patterns every team)
4 use cases:
- Create an online Account (actor? sys?)
- Login NTSS (actor? sys?)
- Submit an event proposal (actor? sys?)
- Evaluate an event proposal (actor? sys?)