Cmpm chuong 9-14 12-2009

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ÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 2

Các bước chính trong tiến trình PMBài toán

Đặc tả yêu cầu

Đặc tả chương trình

Chương trình

Chương trình làm việc

Bảo trì

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

building a system is deciding what to build

• Đặc tả yêu cầu phầnmềm– Bước đầu tiên trong tiến

trình phần mềm– Các yêu cầu của người

dùng về hệ thống tương laiphải được thu thập và tàiliệu hóa. Chỉ tập trung vàowhat và bỏ qua how

• Đặc tả yêu cầu khác vớiphân tích yêu cầu và đặctả 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ậphuấn, giá thành,…

• Kết quả của đặc tả: tài liệu đặctả yêu cầu– Phản ánh sự hiểu biết

chung về vấn đề cần giảiquyết giữa người phân tíchvà 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 cho

nhó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


3. Nội dung đặc tả • Phần mềm:

– Môi trường làm việc củaphần mềm: OS, DBMS

– Các phần mềm giao tiếp với phần mềm muốn pháttriển:

• Các hệ thống đang tồn tại• Dữ liệu: nguồn dữ liệu,

format, dùng lại CSDL cũ. • Giải thuật

• Phần cứng: khả năng củaphần cứng. – Khả năng lưu trữ– Khả năng đáp ứng một tác

vụ …

• Con người: các lớpngười dùng, trình độ– người dùng– người quản trị…

• Tài liệu– Các yêu cầu về tài liệu– Các biểu mẫu

• Thủ tục– Qui trình nghiệp vụ

• Chức năng– Các chức năng theo từng

nhóm người dùng• Chất lượng

– Yêu cầu chất lượng– Giá thành– Thời gian đáp ứng


4. Hình thức đặc tả

• Dùng ngôn ngữ tự nhiên– Ngữ nghĩa không rõ ràng, thường có nhiều lỗi

xảy ra– Ngôn ngữ tự nhiên không phải là phương

cách tốt để đặc tả sản phẩm• Dùng ngôn ngữ qui ước

– Bán hình thức/ đồ họa• Phân tích theo cấu trúc• Mô hình thực thể quan hệ• OOP

– Ngôn ngữ hình thức• 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”– Nhóm các user

• Người thủ thư• Đọc giả• Người quản lí• Người quản trị hệ thống

– Nhóm các yêu cầu theo• 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• Nắm bắt yêu cầu

(requirement elicitation): hiểu cácyêu cầu– Nhà phân tích # chuyên

gia của lĩnh vực.• Đặc tả các yêu cầu:

mô tả các yêu cầutà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đúng.

– Kiểm tra – xác nhận(validation): yêu cầuđúng đã được phát biểuvà tài liệu hóa.

user

elicitation

User requirements

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ốngphải được phát biểuchí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ìnhmuố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àocủa bước phân tích-thiết kế hệthống để có đặc tả hệ thống(kiến trúc hệ thống)

• Tài liệu đặc tả phải– Dễ đọc– Dễ hiểu– Đúng đắn (xác nhận bởi user)– Không “mù mờ”– Đầy đủ (chức năng, chất

lượng…)– 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

thế giới thực– Response: trả lời (đầu ra)– Functional hierarchy: tổ chức

phân cấp các chức năng.(tham khảo một tài liệu đặc tả

trang 228-229)


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ằngNN tự nhiên và NN của ngườidù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

không được đề cập– Đặc tả thừa: đề cập đến cách

giải quyết hơn là vấn đề phảigiải quyết

– Mâu thuẫn: 1 vấn đề đặc tảnhiều lần không nhất quán

– Nhập nhằng– Tham khảo về phía sau– Mơ mộng (wishful thingking):

mô tả siêu thực

• Mô hình thực thể quan hệ

• Máy trạng thái hữu hạn

• SADT

• Các sơ đồ UML– Use case– Class– State – Cooperation– …


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 }• K = {1T, 1P, 2T, 2P, 3T, 3P}• T = như hình vẽ• S = {Khóa an toàn}• F = {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

mô hình phân tích– Định nghĩa rõ các thuật ngữ (từ

điển dữ liệu)• Phân tích = xây dựng mô hình hệ

thống– ERD– DFD– State diagram

• Kết quả của giai đoạn phântích MÔ HÌNH PHÂN TÍCH


10. Đặc tả các yêu cầu phi chức năng• Yêu cầu phi chức năng (non-

functional requirements)– Giao diện với ht khác( External

interface)– Yêu cầu về hiệu quả– Ràng buộc về thiết kế– Các đặc tính của hệ thống

• Giao diện với ht khác và ràngbuộ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à giaotiếp giữa chúng

– Giao diện người dùng theo chuẩncủ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 khicòn được xem như yêu cầu vềchất lượng

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

• Lưu ý:– Các yêu cầu phi chức năng

có giá để thực hiệnphải khả thi trong sự cânbằng với ngân sách.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ầucủa khách hàng. Xác nhậncó 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ểmtra (checklist). Ví dụ: – đã chỉ rõ các tài nguyên

phần cứng? – đã chỉ rõ các tiêu chuẩn

chấp thuận ?

• Bằng việc kiểm tra tài liệuđặc tả yêu cầu– Thiết lập test plan– Xác định nguồn lực, pp để

kiểm thử trong quá trìnhphát triển.

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


Tổng kết chương• Đặc tả yêu cầu:

– Làm rõ yêu cầu của bàitoán

– Làm rõ các ràng buộc tronggiải pháp

– Xác định cụ thể chức năngphải bàn giao và các yêucầu bắt buộc về môitrường hoạt động

• Đặc tả yêu cầu là quátrình lặp của ba hoạtđộng chính:– Requirement elicitation: để

hiểu vấn đề– Requirement specification: để mô tả vấn đề

– Requirement validation: đểthống nhất về vấn đề.

• Công cụ để mô tả vấn đề:– Ngôn ngữ tự nhiên– Ngôn ngữ bán hình thức:

hình ảnh, biểu đồ– 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 đượckiểm tra, xác nhận, phêchuẩn.– Làm cơ sở cho kế hoạch

kiể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ốngvà khung cho giao tiếp và điều khiển các hệ thốngcon 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ínhchấ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ế

• Một thiết kế tốt– Dễ đọc, hiểu– Tin cậy– Dễ phát triển– bao trùm tất cả các yêu cầu tường minh– Cung cấp hình ảnh tồng quan về pm

• Kiến trúc PM phục vụ:– 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.

• Một kiến trúc có thể gồm nhiều thành phần cócấu trúc. Mỗi thành phần có cấu trúc có thể xemxét riêng biệt còn gọi là khung nhìn (view)– Conceptual/logical view– Implementation view– Process view– Deployment view.


2. Mô hình kiến trúc

• Dùng để tài liệu hóa một kiến trúc.• Mô hình cấu trúc tĩnh: các thành phần

chính của HT.• Mô hình cấu trúc động: cấu trúc của tiến

trình trong HT.• Mô hình giao diện: giao tiếp giữa các HT

con.• Mô hình quan hệ: quan hệ giữa các HT

con.


3. Kiểu kiến trúc• Kiến trúc là một sự xếpđặt hình thức các phầntử kiến trúc.

• Một kiểu kiến trúc là sựxếp đặt có luật lệ cácphần tử kiến trúc

• Kiến trúc phần mềm dựatrên:– Các kiểu thành phần

(components)• Computational• Memory• Manager• Controller

– Các kiểu kết nối• Procedure call• Dataflow• Implicit invocation: internal

events • Message passing • Shared data• Instantiation• Chương trình chính-ct con• Kiểu dữ liệu tt• Implicit invocation• Pipe and filter• Repository• Layered

• Một HT lớn có thể baogồm nhiều kiểu kiến trú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

(khối lượng lớn) dữliệu

• Hai kiểu trao đổi– CSDL tập trung hoặc

kho DL (repository): truy cập bởi tất cả HT con

– Mỗi HT con lưu trữ dữliệu của riêng mình vàtruyền dữ liệu tườngminh cho các HT khác

Ví dụ về kiến trúc củamột CASE toolset (Rational Rose chẳnghạ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)• Hệ thống phân tán:

dữ liệu và xử lí đượcphân bố phân tántrong các thành phần.

• Tập hợp các máy chủchuyên biệt cung cấpcác dịch vụ.

• Các máy con gọi đếncác dịch vụ

• Mạng cho phép truycập các máy chủ.


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 cungcấp một số dịch vụ.

• Hỗ trợ phát triển theo môhình tăng trưởng các hệthống con trong cáctầng. Khi có thay đổi chỉcó tầng liền kề bị ảnhhương.

• Mô hình phân tầng chỉ làkiến trúc nhân tạo.


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ầntương tác với nhau để giảiquyết một vấn đề nào đó trongmột ngữ cảnh cụ thể.

• Mỗi mẫu thường chứa đựngnhiều thành phần đơn lẻ.

• Một mẫu thiết kế điển hình làModel – view – controller (MVC). MVC gồm 3 thànhphần– Model: gồm dữ liệu và thao

tác dữ liệu– View: cách thức hiển thị dữ

liệu– Controller: là cách thức xử lí

của một view; cách thức điềukhiển các hành vi từ dữ liệuđầu vào. Ví dụ update.

• Các tính chất của các mẫuthiết kế:– Một mẫu có thể coi là dùng lại

ý tưởng thiết kế. Nó thực chấtlà lặp lại ý tưởng thiết kế trongmột hoàn cảnh cụ thể

– Một mẫu phải cân nhắc cácyêu cầu đối lập; các tính chấtcủa bài toán phải được tínhđến trong giải pháp

– Các mẫu là những thiết kế tốtđã biết. Nó chứa đựng nhiềuthà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àiliệ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ứcnăng như: tính mềm dẽotính thay đổi được và giaodiệ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ếmtài liệu (search) và đặtmượn từ xa.

– Với yêu cầu này ngườithiết kế có thể nghĩ ngayđến kiến trúc client-server (một mẫu kiến trúc)

Trong mẫu (pattern) này cónhiều thành phần:

- 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ề saukiểm tra cẩn thận & phải được phê duyệt.

• Xét duyệt (review) và thanh tra (inspections) có thể đượcdù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ác

giữ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


1. Thiết kế phần mềm

• Từ mô hình phân tích thiết kế

Data Dictionary

Entity-RelationshipDiagram Data Flow

Diagram

State-TransitionDiagram

Data design

Architectural design

Interface design

Procedural design


2. Nguyên tắc thiết kế• Chia hệ thống thành các hệ

thống con và đơn thể– hệ thống con (sub-system):

bao gồm các phép toán vàdịch vụ/chức năng độc lập

– Đơn thể (module): là mộtthành phần cung cấp dịch vụcho các thành phần khácnhưng không phải là một hệthống độc lập

• Nguyên tắc module hóa– Trừu tượng hóa:

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

• Data: Một đối tượng đượcmô hình hóa bằng cáchthuộc tính phù hợp và cầnthiết

– Mịn dần


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

• Chia để trị (devide and conquer)

• Mịn từng bước (stepwise refinement)– Top-down: từ chức năng

chính các chức năng cơbản

– Bottom-up: các chức năng cơbản chức năng chính

• Cả top-down và bottom up đềuđược dùng trong quá trình thiếtkế.

• 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ảnnhất. Không thể thu được hìnhảnh hoàn hảo của hệ thốngngay từ đầu

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

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

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


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

• Abstraction• Refinement• Modularity• Software Architecture• Control Hierarchy• Structural Partitioning• Data Structure• Software Procedure• Information Hiding


4. Đánh giá thiết kế• Tối ưu về giá (cost)

– Cost/module– Cost tích hợp– Total cost

• Đánh giá bằng fan-in, fan-out: Tránh high fan-out; cố gắng xây dựngcấu trúc phân cấp

• Đánh giá module hóa– Độc lập chức năng– Hợp nhất (cohesion)– Gắn kết (coupling)– Nguyên tắc: High

cohesion-low coupling

g hed

i

f

a b c

MFan-out

Fan-in

Width

Depth


Tính hợp nhất (cohesion)• Tính hợp nhất: là mức độ

gắn kết giữa các phầntrong một module– Một thiết kế tốt thì module đơn nhất, tức là các thànhphần gắn kết chặt chẽ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ácthành phần không liênquan với nhau

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

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

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

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

• Hợp nhất tuần tự: nhiều thànhphần độc lập thực hiện theo trìnhtự, cái này làm đầu vào cho cáikia.

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


Độ gắn kết (coupling)• Độ gắn kết chỉ mức độ

phụ thuộc giữa cácmodule

• 6 mức độ gắn kết(Yourdon)– Gắn kết nội dung: module

này làm thay đổi dữ liệucủ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ựchiệ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ắnkết là hai tính chất song hành: nếu tính hợp nhấttrong một module cao(tốt) thì độ gắn kết giữacác module sẽ thấp (tốt)


5. Độ phức tạp (complexity)• Độ phức tạp của một bài

toán là mức độ nỗ lực đòihỏi để giải bài toán

• Độ phức tạp của PM làmức độ nỗ lực để PTPM hoặc bảo trì PM.

• Đo độ phức tạp– Nội module: đo dựa trên

các thuộc tính bên trong 1 module đơn lẻ

– 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 • Số dòng lệnh (LOC)

– Số dòng lệnh lý tưởng30LOC/module (Weiberg,71)

• Có những dòng lệnh “khóhơn” những dòng khác

– i:=1;– 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– N1: tổng số toán tử– N2: tổng số toán hạng– Các độ đo:

• n=n1+n2 : số từ vựng• N= N1+N2: độ dài chương

trình (program length).

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

• Cấp độ chương trình (program level):L=V*/V; V* là biểu diễn Compact nhấtcủ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ìnhE=V/L

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

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


Ví dụ1. Procedure sort(var x:array;

n:integer);2. Var i,j,save:integer;3. Begin4. for i:=2 to n do5. for j:=1 to i do6. if x[i]<x[j] then begin7. save:=x[i];8. x[i]:=x[j];9. x[j]:=save10. end11. End;

operatorProcedure 1Sort() 1Var 2: 3Array 1; 6Integer 2, 2Begin end 2For do 2If then 1:= 5< 1[] 6n1=14N1=35

operandX 7N 2I 6J 5Save 3“2” 1“1” 1

n2=7N2=25


• Áp dụng công thức tính– Size of vocabulary: n=21– Program length: N=60– Estimated program length N’=73– Program volume V=264– Level of abstraction L=0.044– Estimated level of abstraction L’=0.040– Programming effort E=6000– Time T=333s


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

(McCabe)– Dùng một đồ thị có hướng để

biểu diễn các dòng điều khiểnchương trình

– Trong trường hợp tổng quátthì đồ thị gồm nhiều thànhphần liên thông.

• Giả sử một thủ tục hoặc mộtct chính có một lối vào (start) và một lối ra (end), thì đồ thịlà liên thông (chỉ có 1 thànhphần liên thông)

– Độ phức tạp của chương trình= độ phức tạp của đồ thị:C = e – n + p + 1

e: là số cạnh; n: số nútp: số thành phần liên thông

• Ví dụ: thủ tục sort ở trang 34 có đồ thị như sau:

Độ phức tạp: C=13-11+1+1=4


• Cyclomatic complexity có thểxem là số đường đi độc lậptrong đồ thị.

• Cách tính khácC = D+1D là số nút điều kiện (phân

nhánh)C= 3+1=4

• 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àytrong test: tính số đường điđộ lập số test case

– Đo độ khó của chươngtrì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ồngnhau. Độ đo của McCabe không thể hiện ngữ cảnh cácIF lồng nhau không thỏađiều kiện biểu diễn.

– Độ đo của Halstead khôngtí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:– A chứa B– A theo sau là B– A cung cấp dữ liệu cho B– A dùng B

• Call graph: đồ thị biểu diễn mốiquan hệ “A dùng B”

• Call graph – Đồ thị có hướng– Có thể có chu trình

• 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ộtmức.


Cấu trúc hệ thống-Call graph• Cấu trúc tốt-đơn giản nhất: call

graph hình cây.– Cây có n nút sẽ có số cạnh tối

đa là (n-1)• Cấu trúc không tốt-phức tạp:

call graph có chu trình.– Phức tạp nhất là đồ thị mà mỗi

căp nút đều nối với nhau, lúcđó số cạnh sẽ là n(n-1)/2

• Đo độ phức tạp của call graph (một đồ thị liên thông) tínhbằngM(G)=2(e-n+1)/(n-1)(n-2)M(G) biến thiên từ 0 đến 1M(G)=0 call graph hình câyM(G) = 1 call graph có các đỉnh

là nối kết đầy đủ.

• M(G) cho biết độ phức tạptrong cấu trúc của hệ thống = độ phức tạp trong quan hệgiữa các module.


Cấu trúc hệ thống-fan• Độ phức tạp trong cấu trúc còn

được đo bằng độ phức tạptrong luồng thông tin giữa cácmodule:– Luồng cục bộ (local flow) từ A

đến B:• A gọi B và truyền tham số• B gọi A và A trả về một giá trị

– Luồng toàn cục từ A đến B: A 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)= (fan-in(M)xfan-out(M))2

ví dụ: complexity(A)=complexity(E)=0complexity(B)=complexity(C)=1complexity(D)=9

Fan-in(A)=0

Fan-out(A)=3


5. Phương pháp thiết kế• Bảng quyết định• ER• Dòng dữ liệu (Flowchart)• Phân tích cấu trúc (Structure Analysis/Structure

Design)• 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ácthành phần, chức năng ướclượng chi phí

2. Người quản lí cấu hình: thôngtin về ráp nối các thành phầnvà 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, quanhệ 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ànhphần, giải thuật được dùng vàdữ liệu cần thiết

6. Người kiểm tra tích hợp: quanhệ giữa các thành phần, chứcnăng và các thành phần có liênquan

7. Người lập trình bảo trì: cácthành phần, cách hiện thức hóacác yêu cầu người dùng

• 10 thuộc tính của tài liệu thiết kế1. Định danh: tên2. Kiểu: kiểu của thành phần3. Mục đích4. Chức năng5. Hỗ trợ: thực thể hợp thành từ

những thành phần nào6. Phụ thuộc7. Giao diện: với thành phần khác8. Nguồn lực cần thiết9. Xử lí: giải thuật, khởi tạo, quản lí

ngoại lệ.10.Dữ liệu: mô tả, formart, ý nghĩa

Chuẩn IEEE 1016


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


Tổng kết chương• Nguyên tắc:

– thiết kế là phân chia hệ thốngthành các thành phần nhỏ, ítphức tạp

– Bên trong một module phải cótính kết hợp cao

– Giữa các modules phải có độphụ thuộc thấp

– Mỗi module phải che dấuthông tin

– Cấu trúc của hệ thống là phâncấp (hình cây)

• Một số độ đo chất lượng– Cohesion– Coupling

• Các độ đo độ phức tạpcủa module– 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ềmột phần thế giới thực hoặctưởng tượng

• Có một ID để phân biệt vớicác đối tượng khác

• Có tính chất để giữ thông tin về đối tượng

– Object=identity + variables + operations

– Object= identity + state + behavior

– Theo quan điểm SE: đốitượng là sự TTH dữ liệu, baogói dữ liệu và các thao táctrên dữ liệu đó

• Giữa các đối tượng có mốiquan hệ với nhau:– Tổng quát hóa/ĐB hóa, is-a

• Book is a Document– Whole-part, has

• Book has Ttitle– Member-of, has

• Library has Member

BOOK-------------------author: stringTitle: stringISBN: number--------------------Archive()Borrow (Client)Return()Dispose()


Phương pháp phân tích và TK HĐT• Dựa vào đặc tả

– Xác định đối tượng– Xác định thuộc tính– Xác định quan hệ giữa các đối tượng

• Dùng phương pháp phân tích HĐT– Booch– OMT– UML

OMT (Rumbaugh et al.)

Booch

OOSE(Jacobson et al.)

UML0.9

1996UML1.1

Nov. 1997

UML1.4

May 2000

UML2.0

2004


Các sơ đồ UML

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

ActivityDiagrams

Models


Designer /Developer

Analyst Tester

DatabaseAdministrator

PerformanceEngineer

ReleaseEngineer

ProjectLeader


Các khái niệm trong OOAD• OOAD dùng các ký hiệu đồ họa để vẽ mô hình

– Trường hợp sử dụng (use case)– Sơ đồ lớp: mô hình tĩnh về phân chia hệ thống– Sơ đồ trạng thái: hành vi động của đối tượng– Sơ đồ tương tác

• Tuần tự (Sequence)• Colaboration (hợp tác)

– CRC (class – responsibility – collaborators)


Trường hợp sử dụng• Mô tả chức năng hệ thống• Mô tả chi tiết từng chức năng

bằng các kịch bản (senario)

Borrower

Return of i tem

Make re servati on

Librarian

Remove Reservation

Lend item<<uses>>


Sơ đồ lớp• Biểu diễn mối quan hệ giữa các

lớp– Tổng quát hóa– Kết hợp (association)– Kết tập (aggregation)– Hợp thành (composition)

• Bản số (multiplicity)• Vai trò (role)


Sơ đồ đối tượng


Sơ đồ trạng thái• Sơ đồ trạng thái tương tự như FSM.• Biểu diễn hành vi của một đối tượng

– Một đối tượng có thể có nhiều trạng thái khác nhau– Các trạng thái được chuyển lẫn nhau

Sơ đồ trạng thái củamột “lớp học”

Openentry: Register studentexit: Increment count

Initializationdo: Initialize course

Closeddo: Finalize course

Canceleddo: Notify registered students

Add Student / Set count = 0

[ count = 10 ]

Cancel

Cancel

Cancel

Add student[ count < 10 ]


Sơ đồ hoạt động• Mô tả chi tiết cách thức

hoạt động của hệ thống:– các hoạt động để tạo ra

một chức năng nào đó– chi tiết hóa một use case


Sơ đồ tuần tự, hợp tác• Biểu diễn sự hợp tác giữa các

đối tượng (theo thời gian) đểthực hiện một tác vụ

• Các đối tượng hợp tác bằngcách “truyền thông điệp”

Sơ đồ hợp tác : Giống nhưsơ đồ tuần tự nhưng khôngnhấn mạnh vào tính tuần tựtheo thời gian của thông điệp

: Librarian : Maintenance Window

: Borrower information

1: create borrower ( )

2: create (String, String) : Librarian : Maintenance Window

: Borrower information

1: create borrower ( )

2: create (String, String)


Sơ đồ thành phần components


Sơ đồ triển khai


Rational Rose

• Công cụ hỗ trợ– Qui trình RUP– Phân tích & thiết kế theo UML


Tổng kết chương• Đối tượng• Nguyên tắc PT & TK HĐT• PP phân tích và TK HĐT: UML

– Các sơ đồ UML– Rational Rose

• Bài tập: dùng Rational Rose để PT và thiết kế PM “đăng kí môn học” (có tài liệu đặc tả)

Chương 13: Kiểm thử phần mềmSoftware testing


Kiểm thử phần mềm là gì• Test:

– Thường được nghĩ như làthực hiện chương trình vàkiểm tra xem output cóđúng không.

– Các hoạt động kiểm thửnhằm để đảm bảo tínhđúng đắn của chương trình

• Có thể tạo ra phần mềm khônglỗi?– 30-85 lỗi/KLOC– Quá trình test phát hiện

0.5-3 lỗi/KLOC• Hầu hết các lỗi xuất phát từ

các giai đoạn rất sớm trong qui trình phần mềm [Boemh].

– 60% lỗi thiết kế– 40% lỗi cài đặt

• Kinh nghiệm cho thấy– Càng phát hiện lỗi muộn giá

sửa lỗi càng cao– Không thể test được mọi

trường hợp: • số test case rất lớn• Chi phí test cao


Các chiến lược kiểm thử• Kiểm thử bao trùm (coverage-based testing) • Kiểm thử lỗi (fault-based testing): dựa trên kỹ thuật phát

hiện lỗi.• Kiểm thử sai lầm (error-based testing): dựa trên các

lỗi/sai lầm hay mắc phải• Kiểm thử hộp đen (black-box testing) hay kiểm thử chức

năng• Kiểm thử hộp trắng (white-box testing) hay kiểm thử cấu

trúc

• Kiểm thử đơn vị (unit testing)• Kiểm thử hệ thống (integration testing).


Mục đích kiểm thử• Các khái niệm

– Error: một hành động củacon người dẫn đến kết quảsai; kết quả là chương trìnhchứa lỗi (fault)

– Fault: một thể hiện của lỗitrong chương trình. Fault có thể đưa đến cái khôngmong đợi (failure)

• Failure có nguyên nhân làfault; fault bắt nguồn từerror của con người.– Failure có thể bắt nguồn từ

nhiều fault– Fault có thể dẫn đến nhiều

failure.

• Verification và validation [IEEE]– Verification: là quá trìnhđánh giá một hệ thốnghoặc một thành phần đểxác định rằng nó thỏa mãncác điều kiện áp đặt tại giaiđoạn bắt đầu. Have we build the system right?

– Validation: là quá trìnhđánh giá một hệ thốnghoặc một thành phần tronghoặc sau quá trình pháttriển để xác định rằng nóđúng đặc tảHave we build the right system?


Qui trình kiểm thử

• Vấn đề: chọn tập hợp con của input để test (test cases). Test cases nhằm mục đích phát hiện lỗi.

• Kỹ thuật test: xác định các test cases một cách có hệ thống– Chia miền dữ liệu của input làm các lớp

• Mục đích test: làm xuất hiện các lỗi (fault)


Hoạt động kiểm thử trong tiến trình phần mềm

• Hoạt động test diễn ratrong suốt quá trình pháttriển phần mềm– Giai đoạn đặc tả

• Xác định chiến lược• Đặc tả kiểm thử• Sinh dữ liệu test chức

năng– Thiết kế

• Kiểm tra sự phù hợp giữathiết kế & đặc tả

• Đánh giá kiến trúc• Kiểm thử kiến trúc• Sinh ra dữ liệu test chức

năng và cấu trúc

– Cài đặt• Kiểm tra sự phù hợp giữa

cài đặt với thiết kế• Cài đặt test• Sinh ra dữ liệu test chức

năng và kiến trúc• Thực hiện test

– Bảo trì• Lặp lại các test trên trong

quá trình phát triển lại


Các giai đoạn test• Mô hình chử V• Unit test

– Test từng module• Test từ dưới lên• Test từ trên xuống

– Test từng module nhằm xác địnhtính đúng đắn của từng module, tức là chất lượng của code

• System test– Test tích hợp các module

(integration testing) hay test chấp nhận (acceptance test)

– Thường là test tính dùngđược của hệ thống hơn là test sự đúng đắn của code với đặctả

– Test tích hợp có thể bao gồmcả test cài đặt

– Test tích hợp còn nhằm kiểmtra độ tin cậy của hệ thống


Testing Tools


Kế hoạch kiểm thử & tài liệu• Như các công đoạn khác trong

tiến trình phần mềm, kiểm thửphải có kế hoạch và tài liệu

• Tài liệu bao gồm [IEEE,83]– Test plan: Chuẩn IEEE 1012 – Test design – Test cases: Mỗi test case mô

tả• Input• Output mong đợi• Các điều kiện thực hiện

– Test procedure: Đặc tả chuỗicác hoạt động để thực hiệntest

– Test report: Cung cấp thôngtin về việc thực hiện test

Test plan theo IEEE 1012


Các kỹ thuật test thủ công• Đọc (reading)

– Đọc, đọc đi đọc lại• Đặc tả yêu cầu, • Design

– Peer review • Đọc và đánh giá code lẫn

nhau• Nặc danh

• inspections– Kiểm tra thực hiện bởi một đội

(thường là 4 người)– Mỗi người nhận tài liệu và

code– Sau vài ngày nghiên cứu, cả 4

ngồi lại để inspection– Tác giả code có mặt nhưng

không phát biểu, chỉ trả lờicâu hỏi (nếu có)

– Các thành viên inspection sẽ đọc code thành từngcụm (chunk) và phân tíchtìm lỗi:

Lỗi dùng dữ liệu: biếnkhông khởi tạo, vượt chỉsố mảng, con trỏ nguyhiểmLỗi khai báo: không khaibáo, hoặc khai báo cùngtên trong các khối lồngnhauLỗi tính toán: chia 0, trànsốLỗi trong phép toán quanhệ: dùng > thay vì >=; thứtự ưu tiên.Lỗi trong dòng điều khiển: lặp (n+1) lần thay vì n lần!Lỗi giao tiếp: tham sốtruyền sai kiểu, sai sốtham số…


Các kỹ thuật test thủ công(tt)– Quá trình inspection để phát

hiện lỗi, không sửa.• Walkthroughs

– Trong quá trình test có thểdùng dữ liệu đơn giản để chỉlỗi.

– Giả lập bằng tay– Walkthroughs và inspection có

thể thực hiện ở bất kỳ giaiđoạn nào của tiến trình phầnmềm miễn là tài liệu rõ ràngvà test được.

– Khuyết điểm của PP:• Người tham gia có kiến thức

nông cạn• Không đủ kiến thức về lĩnh

vực đang xét

• Đánh giá kịch bản– Dựa trên các use case và

senario (mô tả use case)

• Chứng minh tính đúngđắn: {P} S {Q}

• Trừu tượng hóa từngbuớc– Ngược lại với stepwise

refinement (top-down)– TTH từng buớc áp dụng

với bottom-up: từ cụ thểtổng quá hóa lên cái trừutượng


Kỹ thuật kiểm thử bao trùm(coverage-based testing)

• Kiểm thử bao trùm– Số chỉ thị– Số đường đi / nhánh chương trình

• Chương trình mô hình hóa bởi đồ thị– Control graph: mô hình hóa các dòng điều khiển– Data flow: mô hình hóa dòng xử lí từ khai báo 1 biến

tới kết quả– Mô hình hóa đặc tả yêu cầu bởi đồ thị: mô hình dòng

dữ liệu (DFD)• Dùng độ đo McCabe để tính số test case

– V(G) = số nhánh độc lập = số nút đk + 1


Ví dụ về control graph1. Procedure sort(var x:array;

n:integer);2. Var i,j,save:integer;3. Begin4. for i:=2 to n do5. for j:=1 to i do6. if x[i]<x[j] then begin7. save:=x[i];8. x[i]:=x[j];9. x[j]:=save10. end11. End;

Số đường đi độc lập: V(G)=4- 1-2-3-4-11- 1-2-3-4-5-6-7-8-9-10-4-11- 1-2-3-4-5-6-10-4-11- 1-2-3-4-5-4-11


Kỹ thuật test dựa trên lỗi (fault)• Seed fault

– Cài một số lỗi vào module– Kiểm thử để phát hiện lỗi– Trong quá trình kiểm thử phát

hiện lỗi “cài cắm vào” sẽ pháthiện ra một số lỗi “thật”

• Kiểm tra bằng cách thay thế– Giả sử có chương trình P cần

kiểm thử. P sinh ra kết quảđúng với một số test case (vdT1 và T2)

– Sửa P tại 1 chổ nào đó P’– Kiểm thử P’ với T1 và T2– Giả sử P’(T1)=P(T1) và

P’(T2)=P(T2) – T1 có ý nghĩa trong test vì nó

có thể cho biết có sai sót trongP hoặc P’

– Một số nguyên tắc thay thế:• Thay hằng bởi hằng khác• Thay biến bởi biến khác• Thay hằng bởi biến• Thay phép toán số học bằng

phép toán số học khác• Thay phép toán logic bằng

phép toán logic khác• Thêm phép toán một ngôi• Xóa một dòng lệnh

– Ví dụ• If x<4.5 thenCó thể thay thế bởi:• If x>4.5 then• If x=4.5 then• If x<4.6 then• If x<4.4 then• …


Kỹ thuật test dựa trên sai lầm (error)• Test các giá trị biên

– ON point: điểm nằm trên biêncủa một miền con

– OFF point: điểm nằm cạnhbiên (trong hoặc ngoài)

– Nếu có n miền con Di, i=1..n• Test n ON point• Test ít nhất 1 OFF point cho

mỗi biên– Lưu ý: các miền có thể có ON

point chung hoặc OFF point chung.

• Vd:– Đặc tả

• Nếu 80%<Tỉ lệ <=100% “chắc chắn”

• Nếu 50<= tỉ lệ <= 80% “khá chắc chắn”

• Nếu 0<= tỉ lệ <50% “khôngchắc chắn

– Các test case

Tỉ lệ =0% (ON)Tỉ lệ = -1 % (OFF)Tỉ lệ = 1% (OFF)Tỉ lệ =49% (OFF)Tỉ lệ = 50% (ON)

Tỉ lệ = 70% (OFF)Tỉ lệ = 80% (ON)Tỉ lệ = 99% (OFF)Tỉ lệ = 100% (ON)Tỉ lệ = 1000% (OFF)


Các nghiên cứu thực nghiệm• Meyer, 88

– 85% lỗi được phát hiện trong quá trình inspection ở các giai đoạn đặc tả, thiết kế, code review

– Inspection là tốt hơn walkthroughs• Collofello,89

– Phân tích 700000 dòng code phát triển bởi 400 ngườiphát hiện 676 lỗi, trong đó

• 54% phát hiện bởi xem xét thiết kế• 33% phát hiện bởi xem xét code• 38% phát hiện bởi test


Tổng kết chương• Test thủ công

– Peer review– Inspection– Walkthroughs

• 3 kỹ thuật– Test bao trùm– Test dựa trên lỗi– Test dựa trên sai lầm

• Bài tập: 1 14 trang442,443

Chương 14: Bảo trì phần mềmChương 19: Công cụ phần mềm

Tự đọc thêm

Lưu ý ngày thi!

Documents

Cmpm chuong 9-14 12-2009