Softare dev circle

requirement

1. Business modeling(What should the program achieve)
   • for manager
2. System requirement modeling(Anysis feature)
   • for designer

Analysis

What entities should we need in this program. And clear the realationship of this entities

Design

Specification

Implementation

Unit test is included in this process

Testing

Deployment

Maintenance

Agile vs. Traditional

1. Extreme Programming(XP)[https://www.geeksforgeeks.org/software-engineering/software-engineering-extreme-programming-xp/]

UML Guideline | UML 建模指南

This section is a complete practical guideline for UML learning and project delivery. 本节是一个可直接用于学习和项目交付的 UML 实战指南。

Scope and Unified Case | 范围与统一案例

Case system: Online Shopping System (customer, admin, payment gateway, warehouse). 统一案例系统：在线购物系统（客户、管理员、支付网关、仓储系统）。

Main business flow: 核心业务流程：

1. Customer registers and logs in.
2. Customer browses products and adds items to cart.
3. Customer places order and pays.
4. System checks inventory and ships.
5. Admin handles refund and reporting.

Modeling Workflow | 建模工作流

Recommended order in real projects: 真实项目推荐顺序：

1. Use case diagram (what the system should do).
2. Activity and sequence diagrams (how the flow runs).
3. Class diagram (core domain structure).
4. State diagram (lifecycle-critical objects like Order).
5. Component, package, deployment diagrams (architecture and delivery).
6. Object, communication, interaction overview, timing (analysis deepening).

1. Use Case Diagram | 用例图

Purpose: 用途：

• Define system boundaries, actors, and goals.
• 明确系统边界、参与者和目标。

Detailed case: 详细案例：

• Customer can register, login, browse products, place order, and request refund.
• Admin can manage products, process refunds, and view reports.

  flowchart LR
    Customer((Customer))
    Admin((Admin))
    PaymentGateway((Payment Gateway))
    Warehouse((Warehouse System))

    subgraph ShoppingSystem[Online Shopping System]
        UC1[Register/Login]
        UC2[Browse Product]
        UC3[Place Order]
        UC4[Pay Order]
        UC5[Track Shipment]
        UC6[Request Refund]
        UC7[Manage Catalog]
        UC8[Process Refund]
        UC9[View Dashboard]
    end

    Customer --> UC1
    Customer --> UC2
    Customer --> UC3
    Customer --> UC4
    Customer --> UC5
    Customer --> UC6
    Admin --> UC7
    Admin --> UC8
    Admin --> UC9
    UC4 --> PaymentGateway
    UC5 --> Warehouse

2. Class Diagram | 类图

Purpose: 用途：

• Describe static structure: entities, attributes, operations, and relationships.
• 描述静态结构：实体、属性、操作与关系。

Detailed case: 详细案例：

• User has two roles: customer and admin.
• Order is composed of multiple OrderItem.
• Order references payment and shipment information.

  classDiagram
    class User {
        +Long id
        +String email
        +String passwordHash
        +login()
    }

    class Customer {
        +String level
        +addToCart(productId, qty)
    }

    class Admin {
        +manageCatalog()
        +approveRefund(orderId)
    }

    class Product {
        +Long id
        +String name
        +Decimal price
        +Integer stock
    }

    class Cart {
        +Long id
        +addItem(productId, qty)
        +clear()
    }

    class Order {
        +Long id
        +String status
        +Decimal totalAmount
        +submit()
        +cancel()
    }

    class OrderItem {
        +Long id
        +Integer qty
        +Decimal unitPrice
    }

    class Payment {
        +Long id
        +String method
        +String status
        +pay()
        +refund()
    }

    class Shipment {
        +Long id
        +String carrier
        +String trackingNo
        +ship()
        +deliver()
    }

    User <|-- Customer
    User <|-- Admin
    Customer "1" --> "1" Cart
    Customer "1" --> "0..*" Order
    Cart "1" --> "0..*" Product
    Order "1" *-- "1..*" OrderItem
    OrderItem "*" --> "1" Product
    Order "1" --> "0..1" Payment
    Order "1" --> "0..1" Shipment

3. Sequence Diagram | 时序图

Purpose: 用途：

• Show message sequence among participants in one scenario.
• 展示单个场景中参与者之间的消息时序。

Detailed case: 详细案例：

• Scenario: customer places order and pays successfully.
• 场景：客户下单并支付成功。

  sequenceDiagram
    actor C as Customer
    participant W as WebApp
    participant O as OrderService
    participant I as InventoryService
    participant P as PaymentGateway
    participant S as ShipmentService

    C->>W: Checkout(cart)
    W->>O: createOrder(cart)
    O->>I: reserveStock(items)
    I-->>O: reserved
    O-->>W: orderCreated(orderId, amount)
    W->>P: pay(orderId, amount)
    P-->>W: paymentSuccess(txId)
    W->>O: confirmPayment(orderId, txId)
    O->>S: createShipment(orderId)
    S-->>O: trackingNo
    O-->>W: orderConfirmed
    W-->>C: Show success page

4. Activity Diagram | 活动图

Purpose: 用途：

• Describe workflow, decisions, and exception branches.
• 描述流程、分支决策与异常路径。

Detailed case: 详细案例：

• Covers checkout, payment success/failure, and stock rollback.
• 覆盖结算、支付成功/失败，以及库存回滚。

  flowchart TD
    Start((Start)) --> ValidateCart[Validate Cart]
    ValidateCart --> StockCheck{Stock Available?}
    StockCheck -->|No| EndNoStock[Show Out-of-Stock]
    StockCheck -->|Yes| CreateOrder[Create Order]
    CreateOrder --> Pay{Payment Success?}
    Pay -->|No| ReleaseStock[Release Reserved Stock]
    ReleaseStock --> EndFail[Show Payment Failed]
    Pay -->|Yes| CreateShipment[Create Shipment]
    CreateShipment --> NotifyUser[Notify Customer]
    NotifyUser --> EndOK((End))

5. State Diagram | 状态图

Purpose: 用途：

• Model lifecycle transitions of a key entity.
• 建模关键实体的生命周期状态迁移。

Detailed case: 详细案例：

• Entity: Order from creation to completion/refund/cancel.
• 对象：Order 从创建到完成/退款/取消。

  stateDiagram-v2
    [*] --> Created
    Created --> AwaitingPayment: Submit
    AwaitingPayment --> Paid: PaymentConfirmed
    AwaitingPayment --> Cancelled: PaymentTimeout
    Paid --> Packed: PickAndPack
    Packed --> Shipped: HandOverCarrier
    Shipped --> Delivered: CustomerSign
    Delivered --> Completed: ConfirmReceipt
    Delivered --> RefundRequested: RequestRefund
    RefundRequested --> Refunded: ApproveRefund
    Cancelled --> [*]
    Completed --> [*]
    Refunded --> [*]

6. Component Diagram | 组件图

Purpose: 用途：

• Show system modules/services and their dependencies.
• 展示系统模块/服务及其依赖关系。

Detailed case: 详细案例：

• Frontend depends on API gateway, which routes to order, payment, inventory, and user services.
• 前端依赖 API 网关，网关路由到订单、支付、库存、用户服务。

  flowchart LR
    FE[Web Frontend]
    APIGW[API Gateway]
    UserSvc[User Service]
    CatalogSvc[Catalog Service]
    OrderSvc[Order Service]
    InventorySvc[Inventory Service]
    PaymentSvc[Payment Service]
    NotifySvc[Notification Service]

    FE --> APIGW
    APIGW --> UserSvc
    APIGW --> CatalogSvc
    APIGW --> OrderSvc
    OrderSvc --> InventorySvc
    OrderSvc --> PaymentSvc
    OrderSvc --> NotifySvc

7. Deployment Diagram | 部署图

Purpose: 用途：

• Show runtime nodes, deployed artifacts, and network links.
• 展示运行节点、部署产物与网络连接。

Detailed case: 详细案例：

• Cloud load balancer routes requests to app containers; services access database and message queue.
• 云端负载均衡将请求转发到应用容器；服务访问数据库和消息队列。

  flowchart LR
    UserNode((User Browser))

    subgraph Cloud[Cloud VPC]
        LB[Load Balancer]
        subgraph AppCluster[App Cluster]
            WebPod[Web Pod]
            OrderPod[Order Pod]
            PaymentPod[Payment Pod]
        end
        DB[(MySQL)]
        MQ[(Message Queue)]
        Cache[(Redis)]
    end

    UserNode --> LB
    LB --> WebPod
    WebPod --> OrderPod
    OrderPod --> PaymentPod
    OrderPod --> DB
    OrderPod --> MQ
    WebPod --> Cache

8. Object Diagram | 对象图

Purpose: 用途：

• Capture runtime snapshots with concrete instance values.
• 捕获运行时快照，展示实例与具体值。

Detailed case: 详细案例：

• Snapshot at checkout moment: one customer, one order, two order items.
• 结算时刻快照：一个客户、一个订单、两条订单项。

  classDiagram
    class customer_1001 {
        <<instance>>
        id = 1001
        name = "Alice"
        level = "Gold"
    }

    class order_9001 {
        <<instance>>
        id = 9001
        status = "AwaitingPayment"
        total = 299.00
    }

    class item_1 {
        <<instance>>
        sku = "KB-001"
        qty = 1
        unitPrice = 99.00
    }

    class item_2 {
        <<instance>>
        sku = "MS-002"
        qty = 2
        unitPrice = 100.00
    }

    customer_1001 --> order_9001
    order_9001 --> item_1
    order_9001 --> item_2

9. Package Diagram | 包图

Purpose: 用途：

• Organize model/code into packages and reveal dependencies.
• 将模型/代码组织为包，并揭示依赖关系。

Detailed case: 详细案例：

• UI depends on Application; Application depends on Domain; Infrastructure supports Application and Domain.
• UI 依赖应用层；应用层依赖领域层；基础设施层支撑应用层与领域层。

  flowchart TD
    subgraph Presentation
        WebUI[Web UI]
        AdminUI[Admin UI]
    end

    subgraph Application
        OrderApp[Order Application]
        UserApp[User Application]
    end

    subgraph Domain
        OrderDomain[Order Domain]
        ProductDomain[Product Domain]
        UserDomain[User Domain]
    end

    subgraph Infrastructure
        RepoImpl[Repository Impl]
        PaymentAdapter[Payment Adapter]
        MQAdapter[MQ Adapter]
    end

    Presentation --> Application
    Application --> Domain
    Infrastructure --> Domain
    Infrastructure --> Application

10. Composite Structure Diagram | 复合结构图

Purpose: 用途：

• Show internal parts and connectors inside one classifier.
• 展示一个分类器内部部件与连接器结构。

Detailed case: 详细案例：

• Internal design of OrderService: validator, pricing, inventory checker, payment orchestrator.
• OrderService 内部结构：校验器、定价器、库存检查器、支付编排器。

  flowchart TB
    subgraph OrderService[OrderService Internal Structure]
        InPort[Order API Port]
        Validator[Order Validator]
        Pricing[Pricing Engine]
        StockChecker[Stock Checker]
        PaymentOrchestrator[Payment Orchestrator]
        OutPort[Domain Event Port]
    end

    InPort --> Validator
    Validator --> Pricing
    Pricing --> StockChecker
    StockChecker --> PaymentOrchestrator
    PaymentOrchestrator --> OutPort

11. Timing Diagram (Approximation) | 时序约束图（近似表达）

Purpose: 用途：

• Describe time constraints and timeout behavior.
• 描述时间约束与超时行为。

Detailed case: 详细案例：

• Payment must complete within 15 minutes, otherwise order is canceled.
• 支付必须在 15 分钟内完成，否则订单取消。

  stateDiagram-v2
    [*] --> AwaitingPayment
    AwaitingPayment --> Paid: payment < 15 min
    AwaitingPayment --> Cancelled: timeout = 15 min
    Paid --> Processing
    Processing --> Completed
    Cancelled --> [*]
    Completed --> [*]

12. Communication Diagram | 通信图

Purpose: 用途：

• Highlight object collaboration topology and message numbering.
• 强调对象协作拓扑和消息编号。

Detailed case: 详细案例：

• Checkout collaboration among UI, controller, service, payment adapter, and repository.
• 展示结算时 UI、控制器、服务、支付适配器、仓储之间协作。

  flowchart LR
    UI[CheckoutPage]
    C[OrderController]
    S[OrderService]
    P[PaymentAdapter]
    R[OrderRepository]

    UI -- 1: submitOrder() --> C
    C -- 2: createOrder() --> S
    S -- 3: pay() --> P
    P -- 4: paymentResult --> S
    S -- 5: save(order) --> R
    S -- 6: result --> C
    C -- 7: response --> UI

13. Interaction Overview Diagram | 交互总览图

Purpose: 用途：

• Combine multiple interactions into one high-level flow.
• 将多个交互场景组合成一个高层流程。

Detailed case: 详细案例：

• Main interaction branches: login check, checkout path, and refund path.
• 主交互分支：登录校验、下单路径、退款路径。

  flowchart TD
    Start[Start] --> Auth{Authenticated?}
    Auth -->|No| LoginSeq[Sequence: Login]
    LoginSeq --> Auth
    Auth -->|Yes| Action{Choose Action}
    Action -->|Checkout| CheckoutSeq[Sequence: Checkout and Payment]
    Action -->|Refund| RefundSeq[Sequence: Refund Process]
    CheckoutSeq --> End[End]
    RefundSeq --> End

Common Pitfalls and Review Checklist | 常见问题与检查清单

1. Keep diagram scope small and focused.

2. Names should reflect business language, not technical noise.

3. One diagram should answer one key question.

4. Align terms across use case, class, and sequence diagrams.

5. Explicitly model exception paths (timeout, payment failure, stock shortage).

6. 图要小而清晰，避免一个图承载过多目标。

7. 命名要贴近业务语言，避免技术噪音。

8. 一张图回答一个核心问题。

9. 用例图、类图、时序图的术语保持一致。

10. 必须显式建模异常路径（超时、支付失败、缺货）。

Assignment 1

1. Business modeling: A online shopping system
   • Project workbook
   • Assign team roles
   • glossary
   • From an informal problem statement
   • Business actors(User?)
   • Business funcions
2. System requirement modeling: An online shopping system
3. Static analysis(Class diagram): An online shopping system
4. dynamic analysis(Sequence diagram): An online shopping system
5. System design

Milestone

1. Read
2. Plan
3. Organize
4. Execute
5. Review

Dynamic Analysis

Dynamic analysis focuses on the behavior and interactions of objects over time, complementing static analysis (class diagrams) which only shows structure.

Key Diagrams

Sequence Diagram | 时序图

• Shows message exchange between objects in chronological order.
• Best for modeling a single scenario or use case flow.
• Lifelines represent participating objects; arrows represent messages.

Communication Diagram | 通信图

• Emphasizes object relationships and message numbering rather than time axis.
• Equivalent information to sequence diagrams but with a different emphasis.

State Diagram | 状态图

• Models the lifecycle of a single object across all scenarios.
• Useful for entities with complex state transitions (e.g., Order, Payment).

Activity Diagram | 活动图

• Describes workflow with decisions, branches, and parallel actions.
• Can model business processes spanning multiple objects.

Dynamic vs. Static Analysis

How to Perform Dynamic Analysis

1. Identify key scenarios from use cases (e.g., “Place Order”, “Request Refund”).
2. For each scenario, create a sequence diagram showing object interactions.
3. For objects with complex lifecycles, create a state diagram.
4. For workflows with decisions, create an activity diagram.
5. Validate consistency: ensure all messages in sequence diagrams correspond to operations defined in the class diagram.

Chapter 6

System requirement modeling

• Functional requirement: What the system should do e.g. An online shopping system should allow users to add items to their cart and checkout.

• Non-functional requirement: How the system should be e.g. An online shopping system should respond to user actions within 2 seconds.

• Use cases: widely considered as the most effective way to capture functional requirements. list of steps, typically defining the interactions between a user and the system to achieve a specific goal.

  1. System use case: A user can add items to their cart.
  2. Business use case: A user can purchase items from the online store.
  • Business(Use case) model contains: 1. Actors list 2. Glossary(行话名词解释) 3. Use cases 4. Communication diagram(Optional) 5. Activity diagram(Optional)
  3. System use case: A user can checkout their cart.

Threading

Thread pools

Fork-join parallelism

Grand Central Dispatch (GCD)

Intel Threading Building Blocks (TBB)

Hyperthreading by Intel or SMT

Scheduling

First-come, first-served (FCFS)