單元
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

單元 3 :軟體設計 3-3 架構設計 Architecture Design – Decomposing the System PowerPoint PPT Presentation


  • 132 Views
  • Uploaded on
  • Presentation posted in: General

單元 3 :軟體設計 3-3 架構設計 Architecture Design – Decomposing the System. Outline. Introduction OOSE Process Why System Design System design activities: Decomposing the System Define Design Goals Define Subsystems. Software life cycle. Software life cycle. Development cycle. Requirements

Download Presentation

單元 3 :軟體設計 3-3 架構設計 Architecture Design – Decomposing the System

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


3 3 3 architecture design decomposing the system

單元3:軟體設計

3-3 架構設計Architecture Design –

Decomposing the System


Outline

Outline

  • Introduction

    • OOSE Process

    • Why System Design

  • System design activities: Decomposing the System

    • Define Design Goals

    • Define Subsystems


Software life cycle

Software life cycle

Software life cycle

Development cycle

Requirements

Engineering

Design

Implementation

Testing

Requirements

Elicitation

System design

Analysis

Elicitation

Object design

Requirements

Specification

Analysis Model

SDD

Maintenance


System design

System design

Problem Statement

Requirements elicitation

Objectives

Nonfunctional requirements

Requirements Specification

Analysis

Function model (Use case)

Nonfunctional requirements

Analysis Model

Analysis object model (Class diagrams)

Dynamic model (Sequence diagrams)

System design

SDD

Design goals

Subsystem decomposition (Class diagrams)

Object design

Object design model (Class diagram)


Problem statement

Problem statement

  • Problem

  • Objectives

  • Functional requirements

  • Nonfunctional requirements

  • Target environment


O bjectives

Objectives

  • 建立一個教學網站系統,藉由此系統老師及助教可以很容易對於課程教材、學生資料以及作業、報告及成績等進行輕鬆的控管。學生可利用系統進行教材的下載,成績查詢等功能。

  • 老師,助教及學生也可以利用系統進行互相討論課業及互相聯絡的進階功能。

  • 教學網站為一個線上的系統, 使用者可透過網頁瀏覽器對教學網站進行管理,使用.

  • ...

  • ...


N onfunctional r equirements

Nonfunctional Requirements

  • Extensibility

    • 要在教學網站加入新功能時,不需要變更現有的系統架構

  • Scalability

    • 系統必須讓多個作業能同時進行繳交和下載,並且作業上傳功能要在50位學生使用的狀況下正常連線與執行

  • Low-bandwidth network

    • 學生只要有傳輸速率56K/s以上的modem就可以正常使用教學網站所有功能


Software requirements specifications

Software Requirements Specifications

1. Introduction

1.1Purpose

1.2Scope

1.3Definitions, acronyms, and abbreviations

1.4References

1.5Overview

2. Overall description

2.1Product perspective

2.2Product functions

2.3User characteristics

2.4Constraints

2.5Assumptions and dependencies

3. Specific requirements

3.1External interface requirements

3.2Functional requirements

3.3Performance requirements

3.4Design constraints

3.5Software system attributes

Appendices

Index


N onfunctional r equirements1

Nonfunctional Requirements


Analysis m odel

Analysis Model


Object m odel

Object Model


Dynamic m odel

建立作業Form

老師

建立作業()

建立作業

Control

«new»

輸入(名稱,要求, 截止日期)

檢查(..)

«new»

作業

Dynamic Model


System design document

System Design Document

Contents

1. Introduction

1.1 Purpose of the system

1.2 Design goals

2. Software Architecture

2.1 Overview

2.2 Subsystem decomposition

2.3 Hardware/software mapping

2.4 Persistent data management

2.5 Access control and security

2.6 Global software control

2.7 Boundary conditions

3. Glossary and References

Object model and


Why system design

Why System Design

  • During system design, developers define the design goals of the project and decompose the system into smaller subsystems that can be realized by individual teams.

    (定義design goal以及將系統分解成較小的子系統,讓每個成員都能了解系統的細部架構)

  • Developers also select strategies for building the system

    (開發者也可藉此選擇良好的系統發展策略)

    • Hardware/software mapping

    • Persistent data management

    • Global control flow

    • Access control policy

    • Handling of boundary conditions


System design activities

System design activities

Problem Statement

Objectives

Nonfunctional requirements

System design:

Decomposing the System

Requirements Specification

Define design goals

Nonfunctional requirements

Function model (Use case)

Define subsystems

Analysis Model

Concept

Analysis object model

Architectural

Dynamic model

System Design Document

Design goals

Subsystem decomposition


Design trade offs

Design Trade-offs

  • When defining design goals, only a small subset of these criteria can be simultaneously taken into account.

    (定義design goals時, 只有小部分的準則能同時被考慮到-必須做取捨)

  • Developers need to prioritize design goals and trade them off against each other as well as against managerial goal as the project runs behind schedule or over budget.

    (開發者必須考量design goals彼此之間的優先序,以及design goals和managerial goal之間的取捨)


Design criteria

Design criteria

  • 成本 (低成本)

  • 系統設計、開發、維護和管理時所需花費的成本

  • 維護

  • 系統的維護和變更

    • Extensibility

    • 系統功能的擴充能力

    • Modifiability

    • 系統功能修改的難易度

    • Readability

    • 程式碼的可讀性

  • 使用者需求

  • 使用者端所要求的品質,系統是否好用、提供的功能是否符合使用者需要

  • 效能

    系統效能.系統執行的速度和所需的空間

    • Response time

      系統回應使用者要求的時間

    • Memory

      系統執行時所需消耗的記憶體大小

  • 可靠性

    系統可靠性. 系統能夠維持正常的執行不會發生錯誤及安全性問題

    • Robustness (強壯)

      乘載使用者的能力

    • Availability

      系統正常運作的百分比

    • Fault tolerance

      在不正常的狀況下進行作業的能力


Examples of design goal trade offs

Examples of design goal trade-offs

  • Rapid development vs. Functionality

    (快速地開發或者是提供功能強大的系統)

  • Cost vs. speed

    (系統要有較高的response或through put就需要更多的硬體成本)

  • Delivery time vs. functionality

    (如果開發進度落後,project manager要在先提供功能未完整的版本或延後交貨時間補足功能做取捨。例如在作業截止前,尚未完成所有要求時,要考慮繳交屍體或遲交)

  • Delivery time vs. quality

    (如果測試進度落後,project manager要在時限內提供有bug的軟體版本推出後再進行patch或者修正bug延後交貨做取捨。例如微軟作業系統,推出後再針對bug發布更新檔)

    Managerial goals can be traded off against technical goals.


Define design goals teachingsite

Define Design Goals-TeachingSite

Problem Statement -

Nonfunctional requirements

Requirements Specification - Nonfunctional requirements

Design criteria

Trade-offs

Extensibility

Scalability

Cost

Packaging

  • Design goal:

  • 容易增加新功能

  • 使用者數量的規模擴充性

  • 發展流程文件化

  • 符合ISO/IEC 12207軟體開發流程

  • 低成本


Teachingsite design goal

TeachingSite Design Goal

  • 容易增加新功能

    網路服務不斷地精進和多樣化,硬體也不斷進步.教學網站如果要持續運作的話,必須要相容並容易增加新功能.

  • 使用者數量的規模擴充性

    Response time不會因為使用者增加而降低品質. 必要時可以新增硬體以維護連線品質.

  • 發展流程文件化

    教學網站發展過程中所產生的文件完全保留,以利眾人開發.

  • 符合ISO/IEC 12207軟體開發流程

    教學網站最主要的目的是作為軟體工程的實際範例. 因此,本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題.

  • 低成本

    硬體資源、網路資源和管理等支出最小化.


Fa ade design pattern

Façade Design Pattern

  • Intent

    • Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

      (在較高層的subsystem提供一個統一介面對底層的subsystem進行整合,以便於使用低層subsystem)

  • Benefits

    • Reducing the number of objects that clients deal with and making the subsystem easier to use.

      (減少clients所需要應付的Objects數量,讓subsystem更容易使用)

    • It promotes weak coupling between the subsystem and its clients. Weak coupling lets you vary the components of the subsystem without affecting its clients.

      (在subsystem和它的client之間產生weak coupling. Weak coupling讓你在變更subsystem內的components時不會對clients造成影響)


Subsystem

Subsystem

  • Subsystem:

    • Collection of classes, associations, operations, events and constraints that are interrelated

      (具有相互關係,各自operations的class所組合而成的集合)

    • Seed for subsystems: UML Objects and Classes.

      (subsystems是由Objects和Classes所構成)

  • (Subsystem) Service:

    • Group of operations provided by the subsystem

      (Subsystem所提供的操作群組)

    • Services are defined in System Design

    • 作業管理所提供的service:

      • 新增作業、修改作業、刪除作業、檢視作業


Coupling and cohesion

Coupling and Cohesion

  • Cohesion measures the dependence among classes.

    (子系統內類別之間的相依性)

    • High cohesion: The classes in the subsystem perform similar tasks and are related to each other.

      (子系統內的classes工作類似互為相關)

  • Coupling measures dependencies between subsystems.

    (子系統之間的相依性)

    • Low coupling: A change in one subsystem does not affect any other subsystem.

      (變更一個子系統時不會對其他子系統造成影響)

  • Subsystems should have as maximum cohesion and minimum coupling as possible.

    (最大的cohesion和最小的coupling)


Example subsystem

Example: Subsystem

課程管理

課程公告

講義

課程

使用者管理

學生

作業管理

使用者

作業

分組作業

助教

老師

個人作業


Software architectural styles

Software Architectural Styles

  • Subsystem decomposition

    • Identification of subsystems, services, and their relationship to each other.

  • Specification of the system decomposition is critical.

  • Patterns for software architecture

    • Repository(倉儲)

    • Client/Server

    • Layers

    • Three-tier

    • Others (Pipes and Filters, MVC).


Repository model

Repository

Subsystem

createData()

setData()

getData()

searchData()

Repository model

  • Subsystems must exchange data. This may be done in two ways:

    • Shared data is held in a central database or repository and may be accessed by all sub-systems; (共有資料庫)

    • Each sub-system maintains its own database and passes data explicitly to other sub-systems. (個別資料庫)

  • The majority of system that use large amounts of data are organised around a shared DB or repository.


Client server architectural style

Client/Server Architectural Style

  • One or many servers provides services to instances of subsystems, called clients.

    (Server提供服務給其他名為clients的subsystem)

  • Client calls on the server, which performs some service and returns the result

    • Client knows the interface of the server (its service)

      (Client知道server的介面)

    • Server does not need to know the interface of the client

      (Server不需要知道client的介面)


Layer architectural style

Layer 1

Layer 2

Layer 3

Layer architectural style

  • A layer is a subsystem that provides subsystem services to a higher layers

    (layer的subsystem對higher layers提供subsystem services)

    • A layer can only depend on lower layers

      (每個階層只會相依於較低層)

    • A layer has no knowledge of higher layers

      (每個階層對上層一點都不了解)


Three tier architectural style

Three-tier architectural style

  • The Three-tier architectural style organizes subsystems into three layers

    • The Presentation layer includes all boundary objects that deal with the user.

    • The Business logic layer includes all control and entity objects.

    • The Data layer realizes the storage, retrieval, and query of persistent object.

Form

Presentation

Business logic

Connection

Query

Data


System architecture

使用者2

使用者1

教學網站網頁介面

使用者管理

System architecture

Client

Presentation

Server

Business Logic

教學網站服務窗口

課程管理

作業管理

Repository model

Data

Repository

教學網站資料管理

資料庫

檔案系統


Choosing subsystems

Choosing Subsystems

  • Criteria for subsystem selection: Most of the interaction should be within subsystems, rather than across subsystem boundaries (High cohesion).

    (Subsystem挑選的準則:大部分的交互作用必須在 subsystems內,而不是橫跨數個subsystem邊界.)

  • Heuristics for grouping objects into subsystems

    • Assign objects identified in one use case into the same subsystem.

      (將一個use case內的objects分配至相同的subsystem.)

    • All objects in the same subsystem should be functionally related.

      (相同subsystem內的objects有功能上的關係)

    • Minimize the number of associations crossing subsystem boundaries.

      (將subsystem對外界的連結最小化)


Subsystem decomposition example teachingsite

Subsystem Decomposition Example- TeachingSite

  • TeachingSite functional requirements (top level use case)


Subsystem decomposition example teachingsite1

Subsystem Decomposition Example- TeachingSite

  • The initial subsystem decomposition

    • 根據functional requirement對system做partition

使用者管理

課程管理

作業管理

教學網站資料管理


Subsystem decomposition example teachingsite2

Subsystem Decomposition Example-TeachingSite

  • Refine the subsystem decomposition to address the design goals

    • According to

      • TeachingSite Objective

        • 建立一個教學網站系統,藉由此系統老師及助教可以很容易.....

      • TeachingSite Design Goal

    • Use

      • Three-tier architectural

      • Facade Design Pattern


Subsystem decomposition example teachingsite3

Subsystem Decomposition Example-TeachingSite

  • Design Goal:

    • 容易增加新功能

      網路服務不斷地精進和多樣化,硬體也不斷進步.教學網站如果要持續運作的話,必須要相容並容易增加新功能.

    • 使用者數量和現存課程的規模擴充性

      Response time不會因為使用者增加而降低品質. 必要時可以新增硬體以維護連線品質.

    • 發展流程文件化

      教學網站發展過程中所產生的文件完全保留,以利眾人開發.

    • 教學範例

      教學網站最主要的目的是作為軟體工程的實際範例. 因此,本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題.

    • 低成本

      硬體資源、網路資源和管理等支出最小化.


Subsystem decomposition example teachingsite4

Business Logic

Data

Subsystem Decomposition Example-TeachingSite

使用者2

使用者1

Presentation

使用者網頁介面

課程網頁介面

使用者管理

課程管理

作業管理

教學網站資料管理


Subsystem decomposition example teachingsite5

使用者1

使用者2

Business Logic

Data

Subsystem Decomposition Example-TeachingSite

Presentation

使用者網頁介面

課程網頁介面

教學網站網頁介面

教學網站服務窗口

課程管理

使用者管理

作業管理

教學網站資料管理


Teachingsite subsystem decomposition

使用者1

使用者2

Business Logic

Data

TeachingSite Subsystem Decomposition

Presentation

教學網站網頁介面

教學網站服務窗口

課程管理

使用者管理

作業管理

教學網站資料管理


  • Login