我在英國日不落

期中範圍：１、４、６、７、８、１１、１４，附帶cohesion、OOA、OOD。

軟工期中考前重點詳解  v 2.0 final version

Chapter 1

1. 軟體本質上的問題 ?
        ans：
                a). Complexity (複雜性)：發展過程、應用領域、系統內部的複雜程度。
                b). Conformity (一致性)：軟體無法很制式且完整的被表現出來。
                c). Changeability (易變性)：軟體容易因客戶的需求變化而作改變。
                d). Invisibility (不可見性)：一般使用者無法看見軟體內部結構。

2. 軟體跟硬體的差異 ?
        ans：軟體為邏輯要素，通常是因為市場或客戶要求而去發展或設計某套軟體。
                   硬體為實體要素，通常是由已經存在的元件組合成一個硬體機械。

3. What is software ?
        一般軟體產品可分為兩種：
        (1). Generic products： Solded on the open market to any customer.
        (2). Customised products：Commissioned by a particular customer.

        Software：包含程式以及相關的文件。
                Computer programs and associated documentation.

4. What is software engineering ?
        ans.：
                Software engineering is an engineering discipline which is concerned with 
        all aspects of software production.
        軟體工程是一種全方面的軟體生產的工程訓練。

5. What is software process ?
        ans：
                A set of activities whose goal is the development or evolution of software.
        一連串以開發或改進軟體為目的的活動。

6. What is the difference between software engineering and Computer science?
        ans：
                Compuetr science is concerned with theory and fundamentals; software engineering
        is about the practiticalties of developing and delivering useful software.
        Computer science與理論及基本原理有關；
        Software engineer則是與實際上的發展、實作有關。

7. What is the difference between software engineering and system engineering?
        ans：
                System engineering is concerned with all aspects of computer-based system
        developments, including hardware, software, and process engineering.
                Software engineering is part of this process.
        系統工程為各方面以電腦為基礎的系統發展，包含了硬體、軟體以及程序工程，
        軟體工程只是其中一部份。

8. What is CASE ?
        ans： Computer-Aided Software Engeering(電腦輔助軟體工程)
                Software system which are intended to provide automated support for software process
        activities.
        對軟體流程各階段活動提供自動化支援的系統工具，

Point： Figure 1.1(p. 6)

Chapter 4

Software process的基本活動：
        a). Software specification (軟體規格)
        b). Software design and implementation (軟體設計與實作)
        c). Software validation  (軟體驗證)
        d). Software evolution (軟體發展)

1. Waterfall model (p. 66)
        將process分成固定的數個phase，每一個phase需要等到上一個phase完成之後才能
        開始發展， 適用於已經充分了解需求或不會輕易更改需求的系統發展。
        a). Steps：
                (1). Requirement analysis and definition.
                (2). System and software design.
                (3). Implementation and unit testing.
                (4). Integration and system testing.
                (5). Operation and maintenance.

        b). Advantages：
                (1) 每個phase都有documentation
                (2) 可相容於其他的process model
        c).Disadvantages：
                客戶需求改變時需重新發展，無法對需求的改變做快速的回應。

2. Evolutionary development (p. 68)
        以最初步發展的implementation為基礎，結合客戶的意見並不斷的修正直到軟體發展完成。
        適用於中小型以及生命期短的系統。
        a).兩種發展方式：
                (1).Exploratory development：
                                由已經了解的部份開始，逐步的加入新的特徵以符合客戶的需求。
                (2).Throwaway prototyping：
                                設計雛型model來實驗客戶需求中較難理解的部份，結束後就丟棄雛型
                                並將結果整合。
        b).Two problems：
                (1). The process is not visible：文件產生的速度跟不上軟體發展的速度。
                (2). System are often pooly structured：快速的修正造成軟體結構性貧弱。

3. Incremental delivery (p. 72)
        事先將需求分類並規劃優先順序，依照優先權去分析各個phase，而當某個phase進入發展
        階段時，接下來的phase仍可繼續做需求分析的動作，每當一個phase完成之後就交付給客
        戶與已完成的phase做整合。
        a). Advantages：
                (1). 客戶不需等待整個系統完成即可獲得某些value。
                (2). 客戶可利用已完成的phase作為參數來實驗其他未完成的phase。
                (3). 擁有低風險性。
                (4). 愈重要的服務將會愈早被發展並驗證。

4. Spiral development (p. 74)
        process呈現螺旋形。每一圈皆為軟體程序的一個階段，loop開始前都會先做風險的評估，
        確定可執行後才往下一個sector。
        a). Four sector：
                (1). Objective setting(目標設定)
                (2). Risk assessment and reduction(風險評估與減少)
                (3). Development and validation(發展與驗證)
                (4). Planning (計畫)

5. Reuse model (p. 70)
        利用為數龐大的現有軟體元件來構築軟體，減少了發展軟體的金錢以及風險，
        並加速軟體完成。
        a). Step：
                (1). Component analysis(元件分析)
                (2). Requirements modification(需求修正)
                (3). System with reuse(系統架構重複利用)
                (4). Development and integration (發展與整合)

6. Rational Unified Process(RUP)  (p. 83)
        將process分成四個分離的phase，每個phase獨立運作但彼此相關，
        並且會不斷循環驗證改進。
        a). Three perspectives：
                (1). Dynamic perspective that shows the phase of the model over time.
                (2). Static perspective that shows the process activities that are encated.
                (3). Practice perspective that suggests good practices to be used during the process.
        b). Four phases：
                (1). Inception(開端)：建立系統的business case
                (2). Elaboration(細節)：了解問題並建立系統架構、發展計畫及風險評估。
                (3). Construction(建構)：系統的設計、程式化以及測試。
                (4). Transition(轉變)：將系統從發展環境轉變到客戶環境並實際運作。

7. CMMI  (p. 680)

        a) What is CMMI?
                 Capability Maturity Model Integration(能力成熟度整合模式 )
                 提供系統工程及產品整合之流程改善以及評鑑標準的完善架構。 

        b) CMMI's model
                (1). Staged model：總共分為5個評鑑等級。
                        I). Initial
                        II). Managed
                        III). Defined
                        IV). Quantitatively managed
                        V). Optimizing
                (2). Continuous model←似乎並不常用，跳過。

Chapter 6

1. What is requirment engeering?  (p. 118)
        ans：
                The process of finding out, analysing, documenting and checking these service and
        constraints.
        分析、文件化以及確認服務及限制的流程。

        a). User requirement：用自然語言及圖表描述系統期望提供的功能與限制。

        b). System requirement：詳述系統功能、服務以及操作上的限制。
                        可分為functional以及non-functoinal requirements
                        (1). Functional requirements：系統所提供的功能以及如何對特殊情況做出反應。
                        (2). Non-functional requirement：服務或功能上的限制。
                        (3). Domain requirement：應用領域上的需求。
                
2. The type of non-fucntional requirement (p. 123)
        a). Product requirement(產品需求)
        b). Organizational requirement(組織需求)
        c). External requirement(外部需求)

3. Property for specifying non-functional requirement (p. 125)
    Figure 6.6
        a). Speed(速度)
        b). Size(大小)
        c). Ease of use(易用度)
        d). Reliability(可靠度)
        e). Robustness(強壯度)
        f). Portability(可攜度)

4. Notation for requirements specification (p. 131)
    Figure 6.11
        a). Structured natural Llnguage(結構化自然語言)
        b). Design descricption language(設計描述語言)
        c). Graphical notations(圖像表示)
        d). Mathematical specfication(數學說明)

point： Figire6.14 (p. 134)

Chapter 7

1. Common requirements engineering process (p. 143)
        a). Requirements elicitation(需求導出)
        b). Requirements analysis(需求分析)
        c). Requirements validation(需求驗證)
        d). Requirements managements(需求管理)

2. Process activities of requirement elication and analysis (p. 147)
        a). Requirements discovery(需求發現)
        b). Requirements classification and organization(需求分類與組織)
        c). Requirements prioritization and negotiation(需求優先與協商)
        d). Requirements documentation(需求文件)

3. Requirement validation (p. 159, 160)
        a). Five checks：
                (1). Validity(正確性)
                (2). Consistancy(一致性)
                (3). COmpleteness(正確性)
                (4). Realism(現實性)
                (5). Verifiability(可證明性)
        b). Three techniques：
                (1). Requirements reviews(需求再檢查)
                                check for：
                                        I). Verifiability(可證明性)
                                        II). Comprehensity(可瞭解性)
                                        III). Traceability(可追溯性)
                                        IV). Adaptability(適應性)
                (2). Prototyping(雛型創建)
                (3). Test-case generation(測試案例)

4. Use case diagram and Sequential diagram (p. 156)
    Figure 7.7, 7.8

Chapter 8

1. Context model：描述系統內部與外部動作的關係(多個process)

2. Behavioral model：描述整個系統行為。
        a). Data-flow models：描述系統內部資料處理的動作流程(單一process)
        b). State machine models：描述系統如何回應events。

3. Data models：描述資料之間的關係(如ERD、SDM)
        Data dictionary： An alphabetic list of objects by the names included in the system models

4. Object models：描述物件之間的關係
        a). Inheritance(繼承關係)
        b). Aggregation(聚合關係)

Chapter 11

1. Repository model (p. 247)
        a). All shared data is held a cental database that can ve accessed by all sub-systems.
             每個子系統共用同一個中央資料庫。
        b). Each sub-system maintains its own database.
             每個子系統擁有自己的資料庫，系統間藉由訊息傳遞來做資料交換。

2. The cilent-server model (p. 249)
        A set of services and associated servers and cilents.

3. The layered model (p. 250)
         The layered model of an architecture organizes a system into layers, each of layers provide
         a set of services.

4. COntrol style (p. 256)
        a). Centralised control：由一個中央控制系統管理所有子系統
                (1) Call-return model (p. 257)
                      Figure 11.7
                      Similar to top-down subroutine.
                      
                (2) Real-time system (p. 258)
                      Figure 11.8
                      依照中央控制系統給予的state做動作，各個子系統可以平行運作。
        
        b). Event-driven systems：對外部事件做出回應。
                (1). Broadcast models
                        每個event都由Event and message handler廣播給所有子系統。
                        當子系統欲新增case時必須向handler註冊。
                        I). Advantages：演進十分容易，只需要跟控制系統註冊就可以。
                        II). Disadvantages：新增case時，無法確定其他子系統是否也有同名的case。
                (2) Interrupt-driven control model (p. 260)
                      Figure 11.10

        c). Reference architectures：針對特殊的model建立獨特的架構。

Chapter 14

1. Package diagram

2. Sequence diagram

3. State transition


Cohesion and Coupling

Cohesion：模組內部的關連程度
1. Coincidental(偶然緊密性)：模組裡的工作彼此沒有關聯。
2. Logical(邏輯緊密性)：模組裡的工作性質是類似的。
3. Temporal(時間緊密性)：模組裡的工作必需在同一段時間內執行。
4. Procedure(程序緊密性)：模組裡的工作有一定的執行順序。
5. Commuication(溝通緊密性)：模組裡的工作參考到特定的相同資料。
6. Informational(順序緊密性)：模組內的工作有不同的編號，
                                                       而這些工作可以套用相同的處理方式。
7. Functional(功能緊密性)：模組只做一個動作。

Coupling：模組間的關連程度
1. Content(內容關聯性)：一個模組參考到另一個模組的資料或者是從模組中間執行。
2. Common(共同關聯性)：模組與模組之間共用同一部份的資料。
3. Control(控制關聯性)：模組間傳遞控制資料。(ex： case number、 op code)
4. Stamp(記號關聯性)：模組間以資料結構作為傳遞資料的方式。
5. Data (資料關聯性)：模組之間傳遞的資料是一個一個參數。