chu trình sống của phần mềm - tiến trình phát triển phần mềm

• Nội dung đặc tả – Yêu cầu chức năng – Yêu cầu không chức năng: hiệu quả của hệ thống, độ tin cậy, tài liệu người dùng, tập huấn, giá thành,… • Kết quả của đặc tả: tài liệu đặc tả yêu c

PHẦN 2:

Chu trình sống của phần mềm / Tiến trình phát triển phần mềm

TS TRẦN CAO ĐỆ

NĂM 2010

Các bước chính trong tiến trình PM

Kiểm thử Cài đặt

Thiết kế Tìm hiểu yêu cầu

Chương 9:

Đặc tả yêu cầu

Requirement Engineering

1 Khái niệm đặc tả yêu cầu

• The hardest single part of

phải được thu thập và tài

liệu hóa Chỉ tập trung vào

what và bỏ qua how

• Đặc tả yêu cầu khác với

phân tích yêu cầu và đặc

tả hệ thống

• Nội dung đặc tả

– Yêu cầu chức năng – Yêu cầu không chức năng: hiệu quả của hệ thống, độ tin cậy, tài liệu người dùng, tập huấn, giá thành,…

• Kết quả của đặc tả: tài liệu đặc

tả yêu cầu– Phản ánh sự hiểu biếtchung về vấn đề cần giảiquyết giữa người phân tích

và khách hàng

– Cơ sở để nghiên cứu khảthi

– Cơ sở để kiểm thử-chấpnhận

2 Yêu cầu về tài liệu đặc tả yêu cầu

• Tài liệu đặc tả phải đáp ứng:

– rõ ràng và dễ hiểu đối với khách hàng (dễ thuyết phục)

– đầy đủ và chi tiết vì đây là nguồn thông tin duy nhất dành chonhóm phân tích & thiết kế

• Đặc điểm:

– Các lỗi xảy ra trong giai đoạn này sẽ ảnh hưởng đến các giai đoạn còn lại của toàn bộ tiến trình

– Là hợp đồng (contract) giữa khách hàng và nhà phát triển

– Phải bao gồm các ràng buộc mà sản phẩm phải đáp ứng

– Đặc tả yêu cầu rất khó độc lập với phân tích, thiết kế

• Loại đặc tả

– Client – driven

– Market – driven

– người dùng– người quản trị…

• Chất lượng

– Yêu cầu chất lượng– Giá thành

– Thời gian đáp ứng

• Z, VDM, Petri net.

Case study - Thảo luận

• Viết đặc tả yêu cầu cho “hệ thống QL thư viện”

• Chức năng

• Chất lượng

• Công nghệ: DB, bộ nhớ, phần cứng

5 Ba bước chính trong đặc tả yêu cầu

mô tả các yêu cầu Æ

tài liệu hóa

• Kiểm tra và xác nhận :

– Kiểm tra (verification):

yêu cầu được phát biểu

Problem domain

Domain knowledge

specification validation

knowledge

Request more knowledge

Requirements model

validation results

Domain knowledge

User feedback Models to be validated by user

6 Phát biểu yêu cầu

• Các yêu cầu phải được phát

biểu tường minh và tài liệu hóa

• Mô hình hóa: một phần của thế

giới thực được quan tâm:

universe of discourse (UoD)

• Mỗi người lên quan trong UoD

đều có một mô hình riêng,

không tường minh về thế giới

đó

• Phát biểu yêu cầu

(requirements elicitation) là

phát biểu tường minh về mô

hình không tường minh đó

• Vai trò người phân tích:

– Phân tích bài toán– Thương thảo các yêu cầu

• Các yêu cầu về hệ thống phải được phát biểu

chính xác và đầy đủ

– Nhiều người liên quan– Trình độ khác nhau– Tầm nhìn khác nhau

• Các điểm cần lưu ý

– Con người thường cóthành kiến với phỏng vấn– Con người thường không

có suy nghĩ logic nhất quán– Người ta thường không thểchính xác hóa cái mình

muốn

7 Các kỹ thuật dùng để phát biểu yêu cầu

8 Tăi liệu đặc tả yíu cầu

• Tăi liệu đặc tả: lă sp cuối cùng

của bước đặc tả, lă đầu văo

của bước phđn tích-thiết kế hệ

– Nhất quân: câc yíu cầu không

mđu thuẫn nhau.

– Có thứ tự: quan trọngƯít

quan trọng

– Kiểm tra được: câc đặc tả

phải định lượng để có thể test

– Thay đổi được – Lần vết được

• Chuẩn cho tăi liệu đặc tả:

IEEE 830

• Dăn ý cho một tăi liệu đặc tả(theo IEEE 830)

Tài liệu đặc tả yêu cầu (tt)

• Phần 3 “specific requirements”

là phần dài nhất trong tài liệu,

bao trùm nhiều khía cạnh:

– Mode: chế độ vận hành (thử

nghiệm, thí điểm, dùng)

– User class: nhóm người dùng

– Objects: các đối tượng trong

9 Kỹ thuật đặc tả yêu cầu

• Tài liệu đặc tả yêu cầu phục vụ

cho:

– Người dùng

– Người thiết kế

• Tài liệu thường được viết bằng

NN tự nhiên và NN của người

dùng:

– Nhiễu (noise): dư thừa nhiều

thông tin không cần thiết

– Im lặng (silence): cái chính lại

– Tham khảo về phía sau

– Mơ mộng (wishful thingking):

Ví dụ về bộ điều khiển an toàn (két sắt)

• J = {Khóa an toàn, A, B, Không khóa an toàn, Chuông báo động }

Phân tích

• Phân tích là bước trung gian giữa

đặc tả và thiết kế

• Mục đích:

– Làm rõ thêm các yêu cầu

– Trình bày các yêu cầu bằng các

10 Đặc tả các yêu cầu phi chức năng

• Yêu cầu phi chức năng

• Giao diện với ht khác và ràng

buộc về thiết kế được xem như là

những yêu cầu bắt buộc, ví dụ:

– Phần cứng, phần mềm và giao

tiếp giữa chúng

– Giao diện người dùng theo chuẩn

của công ty.

– Format của tài liệu, báo cáo

– Ràng buộc về qui trình (vd ISO

9000)

– Giới hạn của phần cứng

• Các yêu cầu phi chức năng đôi khi còn được xem như yêu cầu về chất lượng

– Phải xác định và test được vd: 80% giao dịch được đáp ứng trong 1s; 20% còn lại đáp ứng trong 3s.

ÆPhải khả thi trên thực tế

ÆNếu cần thiết phải nghiêncứu khả thi trước

11 kiểm tra (verification) và kiểm tra-xác nhận (validation)

• Tài liệu đặc tả phải được:

– Kiểm tra (verification): đúng

đắn, đầy đủ, nhất quán

Nghĩa là tài liệu đặc tả có

chất lượng

– Kiểm tra-xác nhận

(validation): tài liệu đặc tả

mô tả đúng đắn yêu cầu

của khách hàng Xác nhận

có hiệu lực/ giá trị

• Đối chiếu lại tài liệu đặc tả

với một danh sách kiểm

– Xác định kế hoạch kiểmthử bàn giao (acceptance test)

phải bàn giao và các yêu

cầu bắt buộc về môi

– Ngôn ngữ hình thức

• Tài liệu đặc tả phải mô tả:

– Yêu cầu chức năng– Yêu cầu phi chức năng

• Tài liệu đặc tả phải được kiểm tra, xác nhận, phê chuẩn.

– Làm cơ sở cho kế hoạchkiểm thử & kiểm thử

– Làm cơ sở cho hợp đồng & bàn giao sản phẩm

Chương 10:

Kiến trúc phần mềm

Software architecture

1 Thiết kế kiến trúc

• Xây dựng PM = xây dựng hệ thống Æ có thiết

kế Æ kiến trúc pm.

• Kiến trúc = thiết kế

– Quá trình xác định các hệ thống con trong hệ thống

và khung cho giao tiếp và điều khiển các hệ thống

con gọi là TKKT

– Sản phẩm của quá trình TKKT là kiến trúc PM.

– Kiến trúc của một xác định các thành phần tính toán

và tương tác giữa chúng trong hệ thống (Shaw,95)

– Kiến trúc pm (của một ct hoặc một ht tính toán) là cấu trúc của hệ thống, bao gồm các thành phần, các tính chất nhìn thấy được của các thành phần và quan hệ giữa chúng.

Ví dụ một hệ thống máy (robot) đóng gói

Yêu cầu của một thiết kế

– Trừu tượng hóa về hệ thống.

– Trao đổi, thương thảo giữa các bên liên quan – Trợ giúp quyết định.

Đặc trưng của KTPM

• Kiến trúc PM ảnh hưởng bởi:

– nhà phát triển.

– kiến thức và kinh nghiệm của người phân tích.

– Môi trường kỹ thuật và tổ chức.

Ba kiểu kiến trúc thông dụng

– Data repository (kho dữ liệu);

– Shared services and servers;

– Abstract machine or layered.

Mô hình kho dữ liệu (repository)

• Các HT con trao đổi

– Mỗi HT con lưu trữ dữ

liệu của riêng mình và

truyền dữ liệu tường

minh cho các HT khác

Ví dụ về kiến trúc của một CASE toolset (Rational Rose chẳng hạn)

Đặc trưng của mô hình kho dữ liệu

• Thuận lợi

– Hiệu quả để chia sẻ một lượng lớn dữ liệu;

– Các HT con không không cần quan tâm đến dữ liệu được quản lí thế nào (cập nhật, bảo mật,…).

– Lược đồ kho dữ liệu phải được chia sẻ.

• Hạn chế

– Các HT con phải thống nhất trên mô hình kho dữ liệu, tức là phải có “cam kết và nhất trí”;

– Dữ liệu phát triển khó khăn và bảo trì đắt;

– Khó khăn khi phải giải quyết các chính sách đặc thù; – Khó phân tán một cách hiệu quả.

Khách - chủ (Client – server)

• Thuận lợi

– Phân tán dữ liệu trực tiếp, tường minh.

– Sử dụng hiệu quả mạng Dùng chung tài nguyên

– Dễ thêm máy chủ và nâng cấp máy chủ.

• Bất lợi

– Không chia sẻ mô hình dữ liệu Æ các hệ thống con dùng dữ liệu khác nhau Trao đổi dữ liệu khó khăn, không hiệu quả

– Quản lí dư thừa trên các máy chủ;

– Không có lưu trữ tập trung tên và dịch vụ Æ khó tìm một dịch vụ, cùng với một máy chủ sẳn sàng.

Mô hình phân tầng (layered)

• Dùng để mô hình tương

tác giữa các hệ thống con

• Tổ chức hệ thống thành

tập hợp các tầng (layer)

hoặc máy ảo (abstract

machines); mỗi tầng cung

4 Các mẫu thiết kế (design patterns)

• Một mẫu thiết kế là một cấu

trúc lặp lại của các thành phần

tương tác với nhau để giải

quyết một vấn đề nào đó trong

một ngữ cảnh cụ thể

• Mỗi mẫu thường chứa đựng

nhiều thành phần đơn lẻ

• Một mẫu thiết kế điển hình là

Model – view – controller

– Một mẫu có thể coi là dùng lại

– Các mẫu là những thiết kế tốt

đã biết Nó chứa đựng nhiều thành phần đơn lẻ nhưng đã được biết rõ Ví dụ: quicksort, FFT,…

– Các mẫu là phương tiện để tài liệu hóa phần mềm

(documentation) Nó còn là chuẩn phải tuân theo.

Các mẫu thiết kế (tt)

– Các mẫu không diễn tả một

số yêu cầu không chức

năng như: tính mềm dẽo

tính thay đổi được và giao

diện người dùng

• Ví dụ về mẫu thiết kế

– Hệ thống quản lí thư viện

cho phép độc giả tìm kiếm

tài liệu (search) và đặt

- Application trên máy chủ

- Application trên máy client

- Phương thức giao tiếp

(TCP/IP)

• CGI / ASP / JSP / PHP …

• Cache

• Proxy

4 Kiểm tra và xác nhận

• Kiến trúc phần mềm đưa ra các quyết định về thiết kế

Nó ảnh hưởng đến toàn bộ quá trình phát triển về sau Æ kiểm tra cẩn thận & phải được phê duyệt.

• Xét duyệt (review) và thanh tra (inspections) có thể được dùng

• Đánh giá kiến trúc qua các tiêu chí chất lượng

• Đánh giá dựa trên đặc tả

Tổng kết chương

• Kiến trúc phần mềm mô tả các phần tử trong hệ thống và tương tácgiữa chúng

• Các mẫu thiết kế (design patterns)

– định hướng cho thiết kế, tức là dàn xếp các phần tử trong hệ thống

– dùng lại ý tưởng thiết kế: áp dụng cấu trúc các thành phần đã biết vào một hoàn cảnh cụ thể.

– Là phương tiện giao tiếp “chuẩn” trong thảo luận thiết kế

• Kiến trúc phần mềm đóng vai trò quan trọng

– Nó trình bày một thiết kế của phần mềm Là sự tích hợp công nghệ vào giải pháp cho bài toán

– nó giúp xác định, mô tả, phân loại các thành phần trong hệ thống ở

mức trừu tượng

– Nó thể hiện các quyết định về thiết kế để có thể xem xét, thảo luận

đánh giá giữa/bởi các bên có liên quan

– Nó thể hiện sự tương tự với các sp cùng họ Æ trợ giúp quyết định dùng lại (reuse)

Chương 11:

Thiết kế phần mềm

Software Design

Data design Architectural design

Interface design Procedural design

• Nguyên tắc module hóa

– Trừu tượng hóa:

• Proceduce: một chức năng được mô hình hóa

• Data: Một đối tượng được

mô hình hóa bằng cách thuộc tính phù hợp và cần thiết

– Mịn dần

Phân tách chức năng (functional decomposition)

• Chia để trị (devide and

• Cả top-down và bottom up đều

được dùng trong quá trình thiết

kế

• Hướng dẫn của Parnas:

– Xác định các hệ thống con Bắt đầu với tập hợp đơn giản nhất Không thể thu được hình ảnh hoàn hảo của hệ thống ngay từ đầu

– Áp dụng nguyên tắc che thông tin/bao gói

– Từng bước chia nhỏ các hệ thống con đồng thời thêm các chức năng mới vào hệ thống (mở rộng).

– Áp dụng use-relation để thiết lập cấu trúc phân cấp

3 Các khái niệm trong thiết kế

nhau để tạo nên chức năng

đơn nhất của module

– Đánh giá theo 7 cấp độ

(Yourdon)

• Hợp nhất ngẫu nhiên: các thành phần không liên

quan với nhau

• Hợp nhất logic: module làm nhiều chức năng có liên quan logic với nhau VD module chứa tất cả các thành phần input.

• Hợp nhất theo thời gian: Các thành phần khác nhau cùng được khởi tạo vào 1 thời điểm.

• Hợp nhất thủ tục: nhiều thành phần độc lập thực hiện theo trình

tự

• Hợp nhất giao tiếp: nhiều thành phần độc lập thực hiện trên cùng một dữ liệu.

• Hợp nhất tuần tự: nhiều thành phần độc lập thực hiện theo trình

tự, cái này làm đầu vào cho cái kia.

• Hợp nhất chức năng: các thành phần gắn kết nhau tạo nên chức nằng đơn nhất của module.

– Gắn kết nội dung: module

này làm thay đổi dữ liệu

của module khác

– Gắn kết chung: chia sẽ dữ

liệu

– Gắn kết ngoài: hai module

trao đổi dữ liệu thông qua

một media (vd file)

– Gắn kết điều khiển: module

chuyển điều khiển thực

hiện cho module khác

–

– gắn kết nhãn: hai module chia sẽ cùng CTDL

– Gắn kết dữ liệu: dữ liệuđược chuyển từ 1 module sang 1 module khác

• Tính hợp nhất & độ gắn kết là hai tính chất song hành: nếu tính hợp nhất trong một module cao (tốt) thì độ gắn kết giữa các module sẽ thấp (tốt)

– Ngoại module: đo dựa trêncác thuộc tính của hệ

thống (tức là tập hợp cácmodule)

– Đo dựa trên kích thước(size-based)

– Đo dựa trên cấu trúc(structure-based)

Đo độ phức tạp theo size

– While p^.next<>nil do p:=p^.next;

• Software science (Halstead)

– n1: số toán tử phân biệt

– n2: số toán hạng phân biệt

• Độ lớn chương trình (program volume) V= Nlog2n (diễn dịch là số bits tối

thiểu)

• Cấp độ chương trình (program level): L=V*/V; V* là biểu diễn Compact nhất của giải thuật đang xét L được xấp xỉ bởi L’=(2/n1)(n2/N2)

• Công sức viết chương trình E=V/L

• Thời gian viết chương trình T=E/18 s

• Halstead ước lượng N bởi N’=n1log2n1+n2log2n2

– Estimated level of abstraction L’=0.040

– Programming effort E=6000

Đo độ phức tạp theo cấu trúc

• Khuyến cáo của McCabe

– Cyclomatic complexity của

một module không nên quá

10

– Có thể dùng độ đo này

trong test: tính số đường đi

độ lập Æ số test case – Đo độ khó của chương

trình= mật độ IF: C/LOC.

• Phản biện về độ đo

– Chương trình chứa các IF tuần tự là “dễ” hơn các IF lồng nhau Độ đo của McCabe không thể hiện ngữ cảnh các

IF lồng nhau Æ không thỏa điều kiện biểu diễn.

– Độ đo của Halstead không tính đến các dòng điều khiển.

Cấu trúc của hệ thống- Call Graph

• Kiến trúc của hệ thống có thể xem

như một đồ thị:

– Một nút: một module

– Một cạnh: quan hệ giữa 2 module

• Các mối quan hệ giữa hai module:

• Nếu Call graph không có chutrình ta gọi là cấu trúc phâncấp và có thể phân chia thànhcác lớp sao cho mỗi module trong một lớp chỉ gọi đến cácmodules trong các lớp dưới

• Các độ đo trên call graph

– Size: số nút, số cạnh – Depth: đường đi dài nhất từ nút gốc tới nút lá (trong đồ thị không có chu trình)

– Width: số nút lớn nhất tại một mức.

Cấu trúc hệ thống-Call graph

• Cấu trúc tốt-đơn giản nhất: call

độ phức tạp trong quan hệgiữa các module

cập nhật dữ liệu toàn cục và B

truy cập vào dữ liệu đó.

• Fan –in: tất cả các luồng ra

• Fan-out: tất cả các luồng vào

• Độ đo của Shepperd: độ phứctạp của module M là:

Complexity(M)=

ví dụ:

complexity(A)=complexity(E)=0 complexity(B)=complexity(C)=1 complexity(D)=9

Fan-in(A)=0 Fan-out(A)=3

• SADT (structured analysis and Design technique)

• OOD (object oriented design)

• FSM (finite state machine)

• …

6 Tài liệu thiết kế

• 7 vai trò của tài liệu thiết kế

1 Cho người quản lí: biết các

thành phần, chức năngÆ ước

lượng chi phí

2 Người quản lí cấu hình: thông

tin về ráp nối các thành phần

và kiểm soát thay đổi

3 Người thiết kế: chức năng và

thành phần của hệ thống, quan

hệ giữa các thành phần

4 Programmer: giải thuật, CTDL,

tương tác giữa các thành phần

5 Người kiểm tra đơn vị (unit

tester): thông tin về thành

phần, giải thuật được dùng và

các yêu cầu người dùng

• 10 thuộc tính của tài liệu thiết kế

Tài liệu thiết kế (tt)

• IEEE 1016 nhóm 10 thuộc tính trên vào 4 nhóm sao cho mỗi vai trò người dùng (user role) chỉ dùng 1 nhóm

– Mô tả phân tách

– Mô tả phụ thuộc

– Mô tả giao diện

– Mô tả chi tiết

– Halstead– McCabe– Shepperd– Độ phức tạp của call graph

• Phương pháp thiết kế theo cấu trúc

– Phân tách chức năng– Thiết kế dòng dữ liêu– Thiết kế cấu trúc dữ liệu,…

• Bài tập: 1Æ11 trang 346 và 347

Chương 12: Phân tích & Thiết kế

hướng đối tượng (OOAD)

Khái niệm về đối tượng

• Đối tượng (object)

– Là một mô hình quan niệm về

operations

– Object= identity + state +

behavior

– Theo quan điểm SE: đối

tượng là sự TTH dữ liệu, bao

gói dữ liệu và các thao tác

Borrow (Client) Return()

Dispose()

OOSE (Jacobson et al.)

UML 0.9

1996

UML 1.1

Nov 1997

UML 1.4

May 2000

UML 2.0

2004

Các sơ đồ UML

Use Case Diagrams Use Case Diagrams Use Case Diagrams

Scenario Diagrams Collaboration Diagrams Scenario Diagrams

State Diagrams Diagrams Component State Diagrams

Component Diagrams Component Diagrams

Deployment Diagrams

State Diagrams Diagrams State Object Diagrams

Scenario Diagrams Diagrams Scenario Statechart Diagrams

Use Case Diagrams Diagrams Use Case Sequence Diagrams

State Diagrams Diagrams State Class Diagrams

Activity Diagrams

Models