需求分析笔记第三章 可视化建模

overview

• Use case view
• Activity view
• Structure view
• Interaction view
• State machine view
• Implementation view

Kinds of UML (logical) models

• State model
  • static view of the system
    • models data requirements and operations on data
    • operations obtain from behavioral model
  • class diagram
• Behavior model
  • operational view of the system
    • models function requirements
  • diagrams
    • use case
    • activity
    • communication
• State change model
  • dynamic view of the system
    • models object evolution over time
  • state machine diagram

Summary

• The use case model is the main UML representative and the focal point of behavior modeling.

• The activity model can graphically represent the flow of events of a use case.

• Class modeling integrates and embodies all other modeling activities.

• Interaction modeling captures the interactions between objects needed to execute a use case or part of it.

• A state machine model specifies dynamic changes in a class.

• UML provides component diagrams and deployment diagrams as two tools for architectural/structural modeling of physical implementation of the system.

  ---

1.use case

overview

• 用例驱动整个软件开发的生命周期
• 用例：参与者外部可见，且可单独测试，不应该有孤立用例，不是所有用例都需要和角色关联
• 用例间不要泛化

Documenting use cases

• Brief Description
• Actors involved
• Preconditions necessary for the use case to start
• Detailed Description of flow of events that includes:
  • Main Flow of events, that can be broken down to show:
  • Subflows of events (subflows can be further divided into smaller subflows to improve document readability)
  • Alternative Flows to define exceptional situations
• Postconditions that define the state of the system after the use case ends

---

2. The activity view

overview

• Can graphically represent the flow of events of a use case
• Can also be used:
  • to understand a business process at a high-level of abstraction before use cases are produced
  • at a much lower level of abstraction to design complex sequential algorithms or to design concurrency in multithreaded applications
• Activity Diagram shows transitions between actions
• start of an activity： A solid filled circle represents the
• The end of an activity is shown using a bull’s eye symbol
• Transitions can branch and merge (diamond) –alternative computation threads
• Transitions can fork and re-join (bar line) – concurrent (parallel) computation threads
• Activity diagram without concurrent processes resembles a conventional flowchart

---

3. The structure view (class diagram)

• it represents data structures and their relationships
• it identifies operations that act on these data
• 不应该有孤立的类
• class
  • entity classes : loaded to memory from persistent database
  • presentation (boundary) classes (view classes) : classes that define GUI objects (such as forms or webpages)
  • control classes: classes that control the program’s logic and process use events
  • resource classes: classes responsible for communication with external data sources (DAO)
  • mediator classes: classes responsible for managing entity objects in memory cache and for conducting business transactions (JDBC)

4. The interaction view

• Two kinds of interaction diagrams
  • Sequence diagram – concentrate on time sequences
  • Communication diagram (called collaboration diagram prior to UML 2.0) – emphasize object relationships

Sequence Diagram

• Roles - horizontal dimension (与类图中保持一致)
• Message sequence - top to bottom on vertical dimension
• Each vertical line - the object’s lifeline （过程中生成的对象，要有始有终）
• Activation (execution specification) – a method activated on a lifeline（多次调用，要分开；一个激活内有自调用时，产生新的激活）
• Arrow - message from a calling object (sender) to an operation (method) in the called object (target)
• Showing the return of control from the target to the sender is not necessary(不显示返回结果)
• Iteration marker – an asterisk in front of the message label – indicates iterating over a collection

Communication diagram

message/function

• 通过交互图确定类图中的方法

5.state diagram

• specifies dynamic changes in a class
• Normally attached to a class, but can be attached to other modeling concepts, e.g. a use case
• When attached to a class, the diagram determines how objects of that class react to events
  • Determines – for each object state – what action the object will perform when it receives an event
  • The same object may perform a different action for the same event depending on the object’s state
  • The action’s execution will typically cause a state change
• The complete description of a transition consists of three parts
  • event (parameters) [guard] / action
• 状态可嵌套，下图中1为嵌套状态，状态转出嵌套状态时，可到任意转态
  

6.The implementation view

• architectural/structural modeling of the physical implementation of a system

• provides a connection between the logical and physical structure of the system

• Component - modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces

  • component diagram

• Node - physical object that represents a processing resource, generally, having at
  least a memory and often processing capability as well

  • includes computing devices but also human resources or mechanical processing resources
  • deployment diagram

Subsystems and packages

• Subsystem
  • encapsulates some part of system behavior
  • its services are the result of the services provided by its classes
  • its services are defined using interfaces
• Package
  • grouping of modeling elements
  • like subsystem, its services are the result of the services provided by its classes
  • unlike subsystem, its services are not exposed using interfaces
• “The difference between a subsystem and a package is that, for a package, a client asks some element inside the package to fulfill a behavior; for a subsystem, a client asks the subsystem itself to fulfill the behavior.” from Ferm (2003, p.2)