chuong 3. cnpm

1

CHƯƠNG 3. QUY TRÌNH XÂY DỰNG PHẦN MỀM

Bộ môn Công nghệ thông tinTrường Đại học Thương mại

2

Nội dung

3.1. Phân tích và đặc tả yêu cầu phần mềm 3.1.1. Đặc tả yêu cầu phần mềm

3.1.2. Phân tích yêu cầu hệ thống 3.2. Thiết kế phần mềm

3.2.1. Thiết kế giao diện3.2.2. Thiết kế chương trình3.2.3. Thiết kế các tập tin dữ liệu

3.3. Lập trình3.3.1. Khái niệm

3.3.2. Phương pháp lập trình3.3.3. Ngôn ngữ lập trình3.3.4. Phong cách lập trình

3.4. Kiểm thử3.4.1. Khái niệm3.4.2. Các phương pháp kiểm thử3.4.3. Các kỹ thuật kiểm thử3.4.4. Các loại kiểm thử3.4.5. Các hoạt động kiểm thử

3.5. Cài đặt phần mềm 3.5.1. Lập kế hoạch cài đặt 3.5.2. Biến đổi dữ liệu3.5.3. Biên soạn tài liệu hệ thống

3.6. Bảo trì phần mềm

3

3.1. Phân tích và đặc tả yêu cầu phần mềm

Phân tích và đặc tả yêu cầu là bản đặc tả các dịch vụ mà hệ thống cung cấp và các ràng buộc để xây dựng và vận hành hệ thống.Quá trình tìm kiếm, phân tích, tư liệu hoá, vàkiểm tra các dịch vụ và các ràng buộc của hệthống được gọi là kỹ thuật xác định yêu cầu (Requirements Engineering - RE).

4

3.1. Phân tích và đặc tả yêu cầu phần mềm

Chúng ta cần phải viết các yêu cầu ở các mức chi tiết khác nhau vì có nhiều người sử dụng khác nhau sử dụng chúng theo những cách khác nhau.Phân tích yêu cầu là khâu kỹ thuật đầu tiên trong quá trình xây dựng phần mềm. Bên phát triển vàkhách hàng cần phối hợp thực hiện, tìm hiểu xem hệ thống cần làm gì.

5

3.1.1. Đặc tả yêu cầu phần mềm

Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác.Thông thường các yêu cầu phần mềm được phân loại theo 4 thành phần của phần mềm:– Các yêu cầu về phần mềm (Software)– Các yêu cầu về phần cứng (Hardware)– Các yêu cầu về dữ liệu (Data)– Các yêu cầu về con người (People, Users)

6


Mục đích: mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu vàmong muốn của khách hàng - người sử dụng phần mềm.Lý do: Khách hàng chỉ có những ý tưởng còn mơ hồvề phần mềm cần phải xây dựng để phục vụ công việc của họ, người phát triển phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết”.– Khách hàng rất hay thay đổi các đòi hỏi của mình,

người phát triển cần nắm bắt được các thay đổi đóvà sửa đổi các mô tả một cách hợp lý

7


8


Mục tiêu của quy trình xác định yêu cầu là đưa ra các tài liệu yêu cầu của hệ thống. Quy trình xác định yêu cầu biến đổi phụ thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu. Tuy nhiên, những quy trình này vẫn có chung một số hoạt động sau: phát hiện yêu cầu, phân tích yêu cầu, đánh giá yêu cầu và quản lý yêu cầu.

9


Nội dung– Phát hiện các yêu cầu phần mềm (Requirements

elicitation)– Phân tích các yêu cầu phần mềm và thương lượng với

khách hàng (Requirements analysis and negotiation)– Mô tả các yêu cầu phần mềm (Requirements

specification)– Mô hình hóa hệ thống (System modeling)– Kiểm tra tính hợp lý các yêu cầu phần mềm

(Requirements validation)– Quản trị các yêu cầu phần mềm (Requirements

management)

10


Tuy nhiên, trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay cả khi đang xây dựng hệthống. Vì vậy, người ta thường sử dụng mô hình xoắn ốc để xác định các yêu cầu. Mô hình này cho phép việc xác định yêu cầu và cài đặt hệthống được thực hiện cùng lúc.

11

Mô hình xắn ốc trong quy trình xác định yêu cầu

Mô hình xắn ốc trong quy trình xác định yêu cầu

12

Phân tích và phát hiện yêu cầu PM

Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v.Tìm kiếm các nhân sự (chuyên gia, người sửdụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp người phát triểnxác định yêu cầu phần mềm.Xác định “môi trường kỹ thuật” (technicalenvironment)

13


Xác định các “ràng buộc lĩnh vực” (domain constraints)Thu hút sự tham gia của nhiều chuyên gia, khách hàng để người phát triển có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàngThiết kế các kịch bản sử dụng của phần mềmPhân tích dựa trên khung nhìn cho phép phát hiện nhiều khía cạnh khác nhau của một vấn đề và giúp phát hiện ra sự xung đột giữa các yêu cầu.

14


Khung nhìn được chia thành 3 loại chính và mỗi loại sẽ cung cấp các yêu cầu khác nhau.

– Khung nhìn tương tác: là những người hoặc hệ thống khác tương tác với hệ thống. Trong hệ thống ATM, khách hàng và CSDL tài khoản là những khung nhìn tương tác

– Khung nhìn gián tiếp: là những stakeholder không sử dụng hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong hệ thống ATM, nhân viên quản lý và bảo mật là những khung nhìn gián tiếp.

– Khung nhìn miền ứng dụng: là những đặc điểm và ràng buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu. Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều ngân hàng là một ví dụ.

15


Ta có thể phát hiện khung nhìn dựa trên:– Người cung cấp và người nhận các dịch vụ của hệ

thống– Các hệ thống tương tác trực tiếp với hệ thống cần xây

dựng.– Các chuẩn và các quy tắc– Tài nguyên và các yêu cầu phi chức năng– Marketing và các khung nhìn nghiệp vụ khác.

16

Ví dụ

Ví dụ về hệ thống quản lý thư viện (HTQLTV) cóyêu cầu sau:

– Trường đại học X cần xây dựng một Hệ thống thư viện có chức năng cung cấp một giao diện đơn giản để lưu cơ sở dữ liệu về các bài báo trên các thư viện khác nhau. Người sử dụng có thể tìm kiếm, download và in những tài liệu này.

17

Ví dụ

Khung nhìn phân cấp của HTQLTV

18


Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho các bên liên quan về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Vàcác yêu cầu sẽ được lấy ra từ những câu trả lời của người sử dụng.

19

Phỏng vấn được chia thành hai loại:– Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa

trước và có nhiều đáp án để người sử dụng lựa chọn trảlời.

– Phỏng vấn mở: tất cả các vấn đề không được xác định trước và người sử dụng phải tự giải thích và phát biểu theo quan điểm của mình.

20


Kết quả của giai đoạn đặc tả yêu cầu phần mềm chúng ta thu được các tài liệu sau:– Bảng kê (statement) các đòi hỏi và chức năng khả thi

của phần mềm– Bảng kê phạm vi ứng dụng của phần mềm– Mô tả môi trường kỹ thuật của phần mềm– Bảng kê tập hợp các kịch bản sử dụng của phần mềm– Các nguyên mẫu xây dựng, phát triển hay sử dụng

trong phần mềm (nếu có)– Danh sách nhân sự tham gia vào quá trình phát hiện

các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng

21


Đặc tả các yêu cầu phần mềm là công việc xây dựngcác tài liệu đặc tả, trong đó có thể sử dụng tới cáccông cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịchbản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợpcác công cụ nói trênChất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức– Tính rõ ràng, chính xác– Tính phù hợp– Tính đầy đủ, hoàn thiện

22


Các thành phần của hồ sơ đặc tả– Đặc tả phi hình thức (Informal specifications) được

viết bằng ngôn ngữ tự nhiên– Đặc tả hình thức (Formal specifications) được viết

bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ

– Đặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng

– Đặc tả mô tả (Descriptive specifications) – đặc tả các đặc tính đặc trưng của phần mềm.

23


Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại: yêu cầu chức năng, yêu cầu phi chức năng và yêu cầu miền ứng dụng. Tuy nhiên, trong thực tế chúng ta rất khó phân biết ba loại yêu cầu này một cách rõ ràng. Trong phần này chúng ta tìm hiểu:

– a. Các loại đặc tả– b. Phương pháp xác định các yêu cầu hệ thống – c. Đặc tả miềm ứng dụng– d. Một số kỹ thuật đặc tả yêu cầu HT

24

a. Đặc tả chức năng

Đặc tả chức năng (Operational Specifications): Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. Đặc điểm của yêu cầu chức năng:

– Tính mập mờ, không rõ ràng của các yêu cầu: Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. Các yêu cầu mập mờ có thể được người xây dựng và người sử dụng hiểu theo nhiều cách khác nhau.

– Tính hoàn thiện và nhất quán: Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được điều này.

25


Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau

– Biểu đồ luồng dữ liệu (Data Flow Diagrams)– Máy trạng thái hữu hạn (Finite State Machines)– Mạng Petri (Petri nets)

26


Ví dụ xác định các yêu cầu chức năng của HTQLTV– Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một

tập con của CSDL.– Hệ thống sẽ cung cấp những giao diện thích hợp để

người sử dụng đọc tài liệu.– Tất cả những hoá đơn mà người sử dụng đăng ký để in

sao tài liệu có một mã duy nhất.

27

b. Đặc tả phi chức năng

Đặc tả phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …và các ràng buộc của hệthống như: khả năng của thiết bị vào/ra, giao diện …Một số đặc tả phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình …Các đặc tả phi chức năng có thể là hạn chế hơn những đặc tả chức năng. Nhưng nếu nó không được thoả mãn thì hệthống sẽ không sử dụng được.

28


Các đặc tả phi chức năng xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa phần cứng và phần mềm và đặc tả phi chức năng như sau:– Các đặc tả về sản phẩm xác định ứng xử của sản phẩm

như: hiệu năng, khả năng sử dụng, độ tin cậy … của sản phẩm.

– Các đặc tả về tổ chức: các đặc tả này được lấy từnhững chính sách và quy tắc của khách hàng hoặc tổchức sử dụng hệ thống.

– Các đặc tả ngoài: được xác định từ các tác nhân ngoài của hệ thống.

29Phân loại các yêu cầu phi chức năng

30


Khó xác định chính xác và rất khó thẩm tra những yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu đặc tả yêu cầu, người ta thường bổ sung các mục tiêu. Mục tiêu rất hữu ích đối với người phát triển hệthống khi nó truyền tải được những mong muốn của người sử dụng hệ thống. Còn với những đặc tả phi chức năng có thể thẩm định được là những yêu cầu có thể kiểm thử một cách khách quan.Tuy nhiên, trong nhiều trường hợp thường xảy ra xung đột giữa các đặc tả phi chức năng đối với những hệ thống phức tạp.

31


Ví dụ xác định các đặc tả phi chức năng của HTQLTV– Đặc tả về sản phẩm: HTQLTV phải được cài đặt bằng

HTML mà không có frame hoặc Java applets.– Đặc tả về mặt tổ chức: Quy trình xây dựng hệ thống và

các tài liệu chuyển giao phải thoả mãn các quy tắc đã được định nghĩa trong phần phụ lục của tài liệu HTQLTV.

– Yêu cầu ngoài: Hệ thống không được để lộ các thông tin cá nhân của khách hàng.

32

Các đặc tả phi chức năng có thể thẩm định được của HTQLTV – Mục tiêu của hệ thống là dễ sử dụng đối với những

người sử dụng có kinh nghiệm và được tổ chức để sao cho tối thiểu hoá được lỗi.

– Các đặc tả phi chức năng có thể thẩm định được: Những người sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày.

33

c. Đặc tả miền ứng dụng

Đặc tả miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính vàràng buộc của miền ứng dụng. Nó có thể là yêu cầu chức năng hoặc phi chức năng.

34


Nếu đặc tả miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. Một số vấn đề liên quan:

– Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng.

– Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật.

35


Ví dụ về đặc tả miền ứng dụng của HTQLTV:– Giao diện người dùng chuẩn cho tất cả các CSDL đều

dựa trên chuẩn phù hợp với mô hình mạng Client-Server.

– Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay khi vừa chuyển đến.

– Phụ thuộc vào yêu cầu của người sử dụng, những tài liệu đó có thể được in ngay trên server và chuyển đến cho người sử dụng hoặc gửi đến cho máy in mạng.

36

d. Một số kỹ thuật đặc tả yêu cầu HT

1. Đặc tả bằng ngôn ngữ hướng cấu trúc:– Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người

viết đặc tả tuân theo những mẫu được định nghĩa trước. Tất cả các yêu cầu đều được viết theo chuẩn và các thuật ngữ được sử dụng có thể bị hạn chế.

– Ưu điểm của phương pháp này là đạt được mức độdiễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ đồng nhất lại bị lạm dụng trong các đặc tả.

37

d. Một số kỹ thuật đặc tả yêu cầu HT

2. Đặc tả dựa biểu mẫu (Form-based):– Đặc tả dựa biểu mẫu định nghĩa các chức năng hoặc

thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả đầu ra và nơi nó sẽ đến. Đặc tả dựa biểu mẫu chỉ rõ những thực thể cần thiết, các điều kiện trước và sau (nếu thích hợp), các ảnh hưởng của chức năng.

3. Biểu đồ trình tự:– Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra

khi người sử dụng tương tác với hệ thống. Nếu ta đọc biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tựcủa các hành động được thực hiện.

38


Đặc tả mô tả (Descriptive Specifications)– Biểu đồ thực thể liên kết (Entity-Relationship

Diagrams)– Đặc tả Logic (Logic Specifications)– Đặc tả đại số (Algebraic Specifications)

39

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

Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện bởi đội phát triển hệ thống.Tài liệu đặc tả yêu cầu nên bao gồm cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu hệ thống.Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập những gì hệ thống phải làm, chứ không phải mô tả rõ làm như thếnào.

40

Các yêu cầu của một đặc tả tốt

Dễ hiểu với người dùngCó ít điều nhập nhằngCó ít quy ước khi mô tả, có thể tạo đơn giảnVới phong cách từ trên xuống (topdown)Dễ triển khai cho những pha sau của vòng đời:thiết kế hệ thống và thiết kế chương trình và giao diện dễ làm, đảm bảo tính nhất quán, . . .

41

Ví dụ tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE:– 1. Giới thiệu

1.1. Mục đích của tài liệu yêu cầu1.2. Phạm vi của sản phẩm1.3. Các định nghĩa, từ viết tắt1.4. Các tham chiếu1.5. Tổng quan về tài liệu yêu cầu

– 2. Mô tả chung2.1. Giới thiệu chung về sản phẩm2.2. Các chức năng của sản phẩm2.3. Đặc điểm của người sử dụng2.4. Các ràng buộc2.5. Giả thiết và các phụ thuộc

– 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện.

– 4. Phụ lục– 5. Chỉ mục

42

3.1.2. Phân tích hệ thống

43


Nghiªn cøukh¶ thi

B¸o c¸okh¶ thi Tài liệu mô tả

hệ thống

Ph©n tÝchyªu cÇu

X¸c ®Þnhyªu cÇu

Tµi liÖu yªu cÇu

§Æc t¶yªu cÇu

Tµi liÖu®Æc t¶ yªu cÇu

Tµi liÖu®Þnh nghÜa yªu cÇu

Quá trình hình

thành yêu cầu

Thẩm định

44


Xác định khách hàng, cùng khách hàng phát triển các yêu cầuXây dựng mô hình phân tích (hiểu bài toán):– dữ liệu– chức năng– trạng thái

Làm bản mẫu đối với các chức năng chưa rõ ràngTạo đặc tả yêu cầu phần mềmThẩm định đặc tả yêu cầu

45


Các nguyên lý phân tíchCác phương pháp mô hình hóa

46

Nguyên lý 1

Nội dung: Mô hình hóa miền thông tinPhải hiểu và biểu diễn được miền thông tin (problem

domain)

– định danh dữ liệu (đối tượng, thực thể)

– định nghĩa các thuộc tính

– thiết lập các mối quan hệ giữa các dữ liệu

Từ điển dữ liệu, mô hình thực thể mối quan hệ, mô hình khái niệm

47

Nguyên lý 2

Bản chất của phần mềm là biến đổi thông tin– định danh các chức năng (biến đổi thông tin)

– xác định cách thức dữ liệu (thông tin) di chuyển trong hệthống

– xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữliệu

Nội dung: Mô hình hóa chức năng

Mô hình phân rã chức năng, mô hình luồng dữ liệu

48

Nguyên lý 3

Nội dung: Mô hình hóa hành viPhần mềm (hệ thống) có trạng thái (hành vi)

xác định các trạng thái của hệ thốngxác định các dữ kiện làm thay đổi hành vi hệ thống

ví dụ: bàn phím, chuột, các cổng thông tin...

Biểu đồ trạng thái

49

Nguyên lý 4

Làm mịn, phân hoạch và biểu diễn các mô hình ởcác mức khác nhau

– làm mịn các mô hình dữ liệu

– tạo cây (mô hình) phân rã chức năng

– biểu diễn hành vi ở các mức chi tiết khác nhau

Nội dung: Phân hoạch các mô hình

Mô hình luồng dữ liệu các mức 1,2,3,..

50

Mô hình hóa

Biểu đồ phân rã chức năng (FDD)Biểu đồ luồng dữ liệu (DFD)Biểu đồ thực thể mối quan hệ (ER)

51

Mô hình hóa với FDD

Biểu đồ phân rã chức năng(Function Decomposition Diagram)

• Xác định phạm vi của hệ thống• Phân hoạch chức năng• Tạo nền tảng cho thiết kế kiến trúc hệ thống

chức năngliên kết

52

Mô hình hóa với FDD (2)

• Ví dụ

bán hàng

nhận đơn hàng xử lý đơn hàng gửi hàng

53

Ví dụ mô hình phân cấp chức năng đối với HTQLTV

CẬP NHẬT TÌM KIẾM THỐNG KÊ

Cập nhậtbạn đọc

Cập nhậtSách

Tìm kiếmbạn đọc

Tìm kiếmsách

Xử lýmượn

Xử lýSách mất

Thống kêSách

Thống kêbạn đọc

XỬ LÝ

Nhậpthông

tin bạnđọc

Sửa, Xoá

thôngtin bạnđọc

Xử lýTrả

TK Nhàxuấtbản

TK Sáchbổ

sung

TK Loạisách

TK sáchđangmượn

TK têntácgiả

Nhậpthông

tin sách

Sửa,Xoáthông

tin sách

Tìmtheomãbạnđọc

Tìmtheotênbạnđọc

Tìmtheomã

sách

Tìmtheotên

sách

TìmtheoLoạisách

Tìmtêntácgiả

Tìmnhàxuấtbảnsách

TK bạnđọcđangmượn

TK bạnđọcquáhạn

HỆ THỐNG QUẢN LÝ THƯ VIỆN

54

Mô hình hóa với DFD

Biểu đồ luồng dữ liệu - Data Flow Diagram• Cách thức dữ liệu được xử lý trong hệ thống• Có nhiều mức chi tiết khác nhau (có cấu trúc)• Có nhiều biến thể và mở rộng khác nhau

55

Mô hình hóa với DFD (2)

• Các đối tượng trong DFD(cã nhiÒu c¸ch biÓu diÔn kh¸c nhau)

T¸c nh©n ngoµi

- ®èi t−îng bªn ngoµi hÖ thèng- ph¸t sinh hoÆc tiÕp nhËn th«ng tin

TiÕn tr×nh

- thao t¸c ®èi víi th«ng tin (biÕn ®æi)

56


• Các đối tượng trong DFD(cã nhiÒu c¸ch biÓu diÔn kh¸c nhau)

Luång d÷ liÖu

- luång th«ng tin di chuyÓn trong hÖ thèng

Kho d÷ liÖu

- n¬i l−u tr÷ d÷ liÖu

57


• Các bước để xây dựng

o Ph©n r· chøc n¨ng hÖ thèng

o LiÖt kª çc t¸c nh©n, çc kho¶n môc d÷ liÖu

o VÏ DFD cho çc møc

58


•Một số nguyên tắc

o C¸c tiÕn tr×nh ph¶i cã luång vµo vµ luång ra

o Kh«ng cã luång d÷ liÖu trùc tiÕp gi÷a t¸c nh©n víi t¸c nh©n hay kho d÷ liÖu

o Luång d÷ liÖu kh«ng quay l¹i n¬i xuÊt ph¸t

59

Mô hình ngữ cảnh HTQLTV

HHệệ ththốốngngququảảnn lýlýthưthư viviệệnn

Bạn đọc

Nhà xuất bản

Ban giám đốc

Yêu cầu hủy thẻ

Lý do từ chối

Phiếu thu /chi

Cấp thẻ

Nhắc trả sáchYêu cầu mượn - trả

Yêu cầu tìm kiếm

Kết quả

Yêu cầuđặt sách

Cung cấp sách

Từ chối

Kết qủaBáo cáo

Yêu cầu cấp thẻ

Yêu cầuChỉ đạo

60

Biểu đồ DFD mức đỉnh của HTQLTV

BẠN ĐỌC

KKếếtt ququảả Y / C Y / C ttììmm kikiếếmm

CẬP NHẬT( 1 )

THỐNG KÊ

( 4 )

TÌM KIẾM( 2 )

XỬ LÝ MƯỢN TRẢ( 3 )

BAN GIÁM ĐỐC

BAN GIÁM ĐỐCNHÀ XUẤT BẢN

SSááchch

SSááchch mưmượợnn

YêuYêu ccầầuu ccấấpp ththẻẻYêuYêu ccầầuu hhủủyy ththẻẻLýLý do do ttừừ chchốốii

CCấấpp ththẻẻPhiPhiếếuu thuthu

YêuYêu ccầầuu mưmượợnn–– trtrảả

LýLý do do ttừừ chchốốii

ThôngThông tin tin vvềề ssááchchPhiPhiếếuu chichi

NhNhắắcc trtrảả ssááchch SSááchch mưmượợnn

BBạạnn đđọọcc

PhiPhiếếuu thuthu chichi

BBạạnn đđọọcc

Y/CY/Cđđặặtt

ssááchch

TTừừ

chchốốii

CungCungccấấppssááchch

Y/CY/Cttììmmkikiếếmm

KKếếtt

ququảả

Y/CY/Cchchỉỉđđạạoo

KKếếttququảả,,bbááooccááoo

61

DFD mức dưới đỉnh chức năng QLTT Bạn đọc

Yêu cầu cấp thẻ

Bạn đọc

Bạn đọc

Phiếu thu chi

Thêm thôngtin bạn đọc

( 1.1.1 )

Sửa, xóathông

tin bạn đọc( 1.1.2 )

Bạn đọc

Lý do từ chối

Cấp thẻ

Phiếu thu

Yêu cầu hủy - sửa thẻ

Lý do từ chối

Phiếu chi

Sách mượn

Thông tin bạn đọc

62

DFD mức dưới đỉnh chức năng Xử lý mượn trả

Yêu cầu mượn - trả

Xử lýMượn - Trả

( 3.1 )

Xử lýSách mất

( 3.2 )

Bạn đọc+ Sách mất+ Số thẻSách mượn

Bạn đọc

Sách

Phiếu thu chi

Lý do từ chối

Thông tin sách

Phiếu thu

63

DFD mức dưới đỉnh chức năng Tìm kiếm sách

Bạn đọc Ban quản lý

Tìm kiếmtheo

mã sách( 2.2.1)

Tìm kiếmtheo

Tên sách( 2.2.2 )


Kết quả


Kết quả

Kết quả



Kết quả

Sách

64

DFD mức dưới đỉnh chức năng Thống kê bạn đọc

Yêu cầuThống kê BĐ

quá hạn( 4.1.1 )

Thống kê BĐ đang mượn

( 4.1.2 )

Ban quản lý

Sách mượn Bạn đọcBạnđọc

Nhắc trả sáchBáo cáo

Yêu cầu

Báo cáo

65

Mô hình hóa với ER

Mô hình dữ liệu được sử dụng để mô tả cấu trúc logic của dữ liệu được xử lý bởi hệ thống. Thông thường, chúng ta hay sử dụng mô hình quan hệ -thực thể (ER) nhằm thiết lập mối quan hệ giữa các thực thể và thuộc tính của các thực thể. Mô hình này được sử dụng trong thiết kếCSDL và thường được cài đặt trong các CSDL quan hệ.

66

Mô hình hóa với ERBiểu đồ thực thể mối quan hệ

(Entity Relationship Diagram)

• Mô tả mối quan hệ vốn có của thế giới thựco Thực thểo Mối quan hệ

Phân tích dữ liệu độc lập với xử lýTạo ra mô hình trừu tượng hướng khách hàng

67

Mô hình hóa với ER (2)•Các đối tượng

Thùc thÓ- lµ c¸c ®èi t−îng thÕ giíi thùc mµ chóng ta muèn xö lý- cã thÓ lµ ®èi t−îng thùc hoÆc trõu t−îng

Thuéc tÝnh

- ®Æc ®iÓm cña thùc thÓ

68

Mô hình hóa với ER (3)• Các đối tượng

Mối quan hệ

- mèi liªn hÖ gi÷a c¸c thùc thÓ- lµ th«ng tin cÇn l−u tr÷/xö lý

KÕ thõa

- quan hÖ kÕ thõa gi÷a c¸c thùc thÓ

69

Mô hình hóa với ER (4)

• Ví dụ

sinh viªn

tªn m· sv

®Þa chØ

phim l−u tr÷ bản sao

70

Mô hình hóa với ER (5)• Lực lượng tham gia mối quan hệ

objectobject objectobjectrelationshiprelationship11 22(0, m)(0, m)

(1, 1)(1, 1)

(0, m) (1, 1)objectobject11 objectobject22

relationshiprelationship

71

Mô hình hóa với ER (6)•Xây dựng các thực thể và mối quan hệ

Thùc thÓ- lµ çc danh tõ (trong c©u m« t¶ yªu cÇu)- cã çc thuéc tÝnh khãa (x¸c ®Þnh duy nhÊt)

Mối quan hệ- ho¹t ®éng xÈy ra gi÷a çc thùc thÓ- cã nghÜa víi ho¹t ®éng cña hÖ thèng - lµ ®éng tõ

72

Mô hình hóa với ER (7)

• Các bước mô hình hóa với ER

o Xác định các thực thể và các thuộc tính của các thực thể

o Xác định các mối quan hệ giữa các thực thểo Mô tả các thực thể, mối quan hệ và các thuộc tính

73

Ví dụ mô hình ER của HTQLTV

74

Từ điển dữ liệu

Trên thực tế, mô hình dữ liệu thường không chi tiết. Người phát triển có thể sử dụng từ điển dữliệu làm công cụ bổ trợ. Từ điển dữ liệu là danh sách tất cả các tên gọi được sử dụng trong các mô hình hệ thống. Đó có thể là các thực thể, quan hệvà các thuộc tính …Ưu điểm của từ điển dữ liệu là: – hỗ trợ quản lý tên và tránh trùng lặp tên, – lưu trữ kiến thức một cách có tổ chức kết nối pha phân

tích, thiết kế và cài đặt.

75

Ví dụ: từ điển dữ liệu của HTQLTV

Tên Mô tả KiểuSach Tên quyển sách có

trong thư việnThực thể

Tacgia Tên tác giả viết sách

Thuộc tính

NXB Địa chỉ nhà xuất bản quyển sách

Thuộc tính

… … …

76

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

3.2.1. Thiết kế giao diện3.2.2. Thiết kế chương trình3.2.3. Thiết kế các tập tin dữ liệu

77


Là thiết kế cấu hình phần cứng và cấu trúc phần mềm (gồm cả chức năng và dữ liệu) để có đượchệ thống thỏa mãn các yêu cầu đề ra.Đặc điểm:– Phân chia mô hình phân tích ra các hệ con– Tìm ra sự tương tranh (concurrency) trong hệ thống– Phân bố các hệ con cho các bộ xử lý hoặc các nhiệm

vụ (tasks)– Phát triển thiết kế giao diện– Chọn chiến lược cài đặt quản trị dữ liệu

78


Đặc điểm:– Tìm ra nguồn tài nguyên chung và cơ chế điều khiển

truy nhập chúng– Thiết kế cơ chế điều khiển thích hợp cho hệ thống, kể

cả quản lý nhiệm vụ– Xem xét các điều kiện ràng buộc được xử lý như thế

nào

79


Lưu ý trong quá trình thực hiện thiết kế phần mềm:

(1) Có thể trích được luồng dữ liệu từ hệ thống: đólà phần nội dung đặc tả yêu cầu và giao diện

(2) Xem xét tối ưu tài nguyên kiến trúc lên hệthống rồi quyết định kiến trúc

(3) Trong quá trình biến đổi dữ liệu, hãy xem những chức năng được kiến trúc như thế nào

(4) Từ kiến trúc các chức năng theo (3), hãy xem xét và chỉnh lại, từ đó chuyển sang kiến trúc chương trình và thiết kế chi tiết

80


(5) Quyết định các đơn vị chương trình theo các chức năng của hệ phần mềm có dựa theo luồng dữ liệu vàphân chia ra các thành phần

(6) Khi cấu trúc chương trình lớn quá, phải phân chia nhỏ hơn thành các môđun

(7) Xem xét dữ liệu vào-ra và các tệp dùng chung của chương trình. Truy cập tệp tối ưu

(8) Hãy nghĩ xem để có được những thiết kế trên thì nên dùng phương pháp luận và những kỹ thuật gì?

81

3.2.1. Thiết kế giao diện

Giao diện người dùng cần phải được thiết kế sao cho phù hợp với kỹ năng, kinh nghiệm và sự trông đợi của người sử dụng nó.Người sử dụng hệ thống thường đánh giá hệthống thông qua giao diện hơn là chức năng của nó. Giao diện hệ thống nghèo nàn có thể khiến người sử dụng tạo ra các lỗi hết sức nghiêm trọng. Đó là lý do tại sao nhiều hệ thống phần mềm không bao giờ được sử dụng.

82


Tác nhân con người trong thiết kế giao diện– Một nhân tố quan trọng ảnh hưởng tới quá trình thiết

kế giao diện đó chính là người sử dụng hệ thống. Do đó, chúng ta phải tìm hiểu một số đặc điểm của người sử dụng có liên quan đến giao diện hệ thống:

Khả năng nhớ tức thời của con người bị hạn chế: con người chỉ có thể nhớ ngay khoảng 7 loại thông tin. Nếu ta biểu diễn nhiều hơn 7 loại, thì có thể khiến người sử dụng không nhớhết và gây ra các lỗi.

83

– Người sử dụng có thể gây ra lỗi: khi người sử dụng gây ra lỗi khiến hệ thống sẽ hoạt động sai, những thông báo không thích hợp có thể làm tăng áp lực lên người sử dụng và do đó, càng xảy ra nhiều lỗi hơn.

– Người sử dụng là khác nhau: con người có những khả năng khác nhau. Những người thiết kế không nên chỉthiết kế giao diện phù hợp với những khả năng của chính họ.

– Người sử dụng thích các loại tương tác khác nhau: một số người thích hình ảnh, văn bản, âm thanh …

84


Các nguyên tắc thiết kế giao diên– Sự quen thuộc của người sử dụng: giao diện phải được xây

dựng dựa trên các thuật ngữ và các khái niệm mà người sửdụng có thể hiểu được hơn là những khái niệm liên quan đến máy tính. Ví dụ: hệ thống văn phòng nên sử dụng các khái niệm như thư, tài liệu, cặp giấy … mà không nên sửdụng những khái niệm như thư mục, danh mục …

– Thống nhất: hệ thống nên hiển thị ở mức thống nhất thích hợp. Ví dụ: các câu lệnh và menu nên có cùng định dạng …

– Tối thiểu hoá sự bất ngờ: nếu một yêu cầu được xử lý theo cách đã biết trước thì người sử dụng có thể dự đoán các thao tác của những yêu cầu tương tư.

85


Các nguyên tắc thiết kế giao diên– Khả năng phục hồi: hệ thống nên cung cấp một số khả

năng phục hồi từ lỗi của người sử dụng và cho phép người sử dụng khôi phục lại từ chỗ bị lỗi. Khả năng này bao gồm cho phép làm lại, hỏi lại những hành động như xoá, huỷ …

– Hướng dẫn người sử dụng: như hệ thống trợ giúp, hướng dẫn trực tuyến …

– Tính đa dạng: hỗ trợ nhiều loại tương tác cho nhiều loại người sử dung khác nhau. Ví dụ: nên hiển thịphông chữ lớn với những người cận thị

86


Biểu diễn thông tin– Biểu diễn thông tin có liên quan tới việc hiển thị các

thông tin trong hệ thống tới người sử dụng. Thông tin có thể được biểu diễn một cách trực tiếp hoặc có thể được chuyển thành nhiều dạng hiển thị khác như: dạng đồ hoạ, âm thanh …

– Thông tin cần biểu diễn được chia thành hai loại:– Thông tin tĩnh: được khởi tạo ở đầu của mỗi phiên. Nó

không thay đổi trong suốt phiên đó và có thể là ở dạng số hoặc dạng văn bản.

– Thông tin động: thay đổi trong cả phiên sử dụng và sự thay đổi này phải được người sử dụng quan sát

87


Quy trình thiết kế giao diện người dùng – Thiết kế giao diện người dùng là một quy trình lặp lại

bao gồm sự cộng tác giữa người sử dụng và người thiết kế. Trong quy trình này gồm 3 hoạt động cơ bản:

Phân tích người sử dụng: tìm hiểu những gì người sử dụng sẽlàm với hệ thống.Lập mẫu thử hệ thống: xây dựng một tập các mẫu thử để kiểm thửĐánh giá giao diện: kiểm thử các mẫu thử cùng với người sửdụng.

88

Quy trình thiết kế giao diện người dùng

89


Thiết kế về các thủ tục người dùng và các giao diệnb1. Thủ tục người dùng/chức năng thủ công

– Gồm:Mã hoá thông tin thu nhậpKiểm soát và sửa chữa thông tinNhập thông tinKiểm tra tài liệu xuấtPhân phối tài liệu xuất

– Yêu cầu thiết kế chức năng thủ công: Miêu tả nội dung công việc rõ ràng: Mục đích cần đạt đáp ứng yêu cầu của hệ thống, các bước thực hiện, yêu cầu của mỗi bướcThông tin chính xác; Ấn định độ chính xác phải đạtẤn định mức năng suất cần thiết (gõ phím ít nhất), hướng dẫn mức xử lý khi có sai sót

90

3.2.1.Thiết kế giao diệnb2. Thiết kế việc thu nhập dữ liệu thông qua các biểu mẫu (tờ khai, các

phiéu điều tra, v..v)– Chọn phương thức thu nhập :

On-lineTrì hoãn Từ xa

– Xác định khuôn mẫu thu nhập:Khung (để điền)Câu hỏi (câu hỏi đóng: trả lời xác định trước, câu hỏi mở: gợi ý)

– Yêu cầu biểu mẫu: Thuận tiện cho người điều traThuận tịện mã hoáThuận tiện người gõ phímNội dung đơn giản, rõ ràng, chính xác

91

3.2.1.Thiết kế giao diện

b3. Thiết kế các tài liệu xuấtTài liệu xuất:

– Các bảng biểu thống kê, tổng hợp– Các chứng từ giao dịch (đơn hàng, hóa đơn v..v)

Xác định:– Phương tiện: giấy, màn hình, đĩa, v..v– Phương thức: lập tức hay trì hoãn– Dạng tài liệu xuất : có cấu trúc hay không có cấu trúc– Cách trình bày: đầu _ thân_cuối

Yêu cầu:– Đủ, chính xác (kiểm tra không nhập nhằng), dễ hiểu, dễ đọc.

92

3.2.1.Thiết kế giao diện

b4. Thiết kế các màn hình và đơn chọn: giao diện đối thoại giữa người dùng và máy tính

– Dựa trên yêu cầu của người dùng và việc hiển thị chi tiết về dữliệu, các dạng hội thoại thường gồm:

Câu lệnh, câu nhắc: Máy hỏi hay nhắc, người đáp lạiĐơn chọn (Menu): Người dùng chọn một mục trong nhiều mụcĐiền mẫu: Người dùng điền thông tin vào ô mẫu trên màn hìnhSử dụng các biểu tượng (Icon) để tăng tính trực quan

– Yêu cầu thiết kế:Vào / ra gần nhauThông tin thường tối thiểu (cần đâu lấy đấy)Sáng sủa (dễ nhìn, dễ đọc)Lệnh phải rành mạch (muốn gì? Làm gì?)

93

Ví dụ thiết kế giao diện HTQLTV

94

Giao diện chức năng Thêm bạn đọc

95

Giao diện chức năng Sửa thông tin bạn đọc

96

Giao diện chức năng Hủy thẻ bạn đọc

97

Giao diện chức năng Thêm đầu sách

98

Giao diện chức năng Mượn sách

99

Giao diện chức năng Trả sách

100

Giao diện chức năng Tìm kiếm thông tin

101

Giao diện chức năng Thông kê bạn đọc mượn sách quá hạn

102

3.2.2.Thiết kế chương trình

Thiết kế nội dung của chương trình mà không phải viết chương trình cụ thể. Người phát triển cần thiết kế:– Chức năng như trong BLD. Ngoài ra:– Chức năng đối thoại – Chức năng xử lí lỗi – Chức năng xử lí vào/ ra – Chức năng tra cứu CSDL – Chức năng Module điều hành

103


Nội dung chủ yếu trong giai đoạn thiết kế chương trình là:– Xác định cấu trúc tổng quát – Phân định các Module CT – Xác định mối liên quan giữa các Module đó (thông qua

lời gọi và các thông tin trao đổi) – Đặc tả các Module chương trình – Gộp các Module thành chương trình – Thiết kế các mẫu thử

104


Thiết kế chương trình theo mô hình kiến trúc client-server– Là một mô hình hệ thống trong đó hệ thống bao gồm

một tập hợp các server cung cấp dịch vụ và các client truy nhập và sử dụng các dịch vụ đó. Các thành phần chính của mô hình này bao gồm:

Tập hợp các server sẽ cung cấp những dịch vụ cụ thể như: in ấn, quản lý dữ liệu…Tập hợp các client truy nhập đến server để yêu cầu cung cấp dịch vụ.Hệ thống mạng cho phép client truy cập tới dịch vụ mà

server cung cấp.

105

Mô hình Client – Server

Client (máy khách) phải biết tên của Server (máy chủ) và các dịch vụ mà server cung cấp. Nhưng server thì không cần xác định rõ client và hiện tại có bao nhiêu client. Client tạo ra một yêu cầu tới server và chờ server trả lời.Ưu điểm của mô hình client - server:– Phân tán dữ liệu rõ ràng– Sử dụng các hệ thống được kết nối mạng một cách

hiệu quả và chi phí dành cho phần cứng có thể rẻ hơn.– Dễ dàng bổ sung hoặc nâng cấp server

106

Mô hình Client – Server

Nhược điểm của mô hình client - server:– Không phải là mô hình dữ liệu dùng chung nên các hệ

thống con có thể sử dụng các tổ chức dữ liệu khác nhau. Do đó, việc trao đổi dữ liệu có thể không hiệu quả.

– Quản lý mỗi server không thống nhất, dư thừa.– Không đăng ký tên và dịch vụ tập trung. Điều này làm

cho việc tìm kiếm server hoặc các dịch vụ rất khó khăn.

107

Mô hình Client – Server của hệ thống thư viện phim và ảnh

108

3.2.3. Thiết kế các tập tin dữ liệu

Thiết kế tập tin dữ liệu phải dựa vào: – Biểu đồ cấu trúc dữ liệu: mô hình quan hệ, mô

hình quan hệ thực thể liên kết E-R– Biểu đồ luồng dữ liệu trong đó đặc biệt quan

tâm đến kho dữ liệu. – Hệ Quản trị CSDL có sẵn: Mỗi hệ quản trị

CSDL đều có ngôn ngữ định nghĩa dữ liệu sẵn.

109

3.2.3. Thiết kế các tập tin dữ liệu

Khi thiết kế các tập tin dữ liệu/CSDL phải đảm bảo sao cho các dữ liệu phải đủ, không trùng lặp, việc truy cập đến các tập tin dữ liệu phải thuận tiện, tốc độ nhanh. – Bổ xung thêm một số thuộc tính tính toán, lặp lại một

số thuộc tính, ghép một số thực thể thành một tập tin....– Đôi khi đã chuẩn hóa dữ liệu đạt chuẩn 3 NF, BCNF..

nhưng để phục vụ các thao tác tìm kiếm, xử lý nhanh chóng, thì các chuẩn trên có thể bị phá vỡ thành các chuẩn mức thấp hơn.

110

3.3. Lập trình

3.3.1. Khái niệm3.3.2. Phương pháp lập trình3.3.3. Ngôn ngữ lập trình3.3.4. Phong cách lập trình

111

3.3.1. Khái niệm

Lập trình là quá trình chuyển đổi từ thiết kế chi tiết sang mã lệnhLựa chọn ngôn ngữ lập trình- Phụ thuộc vào cấu hình máy – Phụ thuộc vào số lượng ngôn ngữ lập trình sẵn có– Phụ thuộc vào thói quen sử dụng ngôn ngữ lập trình – Phụ thuộc vào khách hàng

112

3.3.1. Khái niệm

Người lập trình cần xây dựng thông tin tối thiểu cho một mô-đun chương trình, bao gồm:– Tên mô-đun– Mô tả vắn tắt các công việc mô-đun phải thực hiện– Tên lập trình viên– Ngày viết– Ngày chỉnh sửa– Danh sách các tham số– Danh sách các biến

113

3.3.2. Phương pháp lập trình

Lập trình tuyến tínhLập trình cấu trúcLập trình Hướng đối tượng

114

Lập trình tuyến tính

Chương trình được viết tuần tự với các câu lệnh thực hiện từ đầu đến cuối.Không có/thiếu các lệnh có cấu trúc (for, while..)Thiếu khả năng khai báo biến cục bộNgôn ngữ lập trình: assembly, basic..

115

Lập trình tuyến tính

Ngôn ngữ lập trình tuyến tính không có khả năng kiểm soát phạm vi nhìn thấy của các dữ liệu. Mọi dữ liệu trong chương trình đều là dữ liệu toàn cục, nghĩa là chúng có thểbị sửa đổi ở bất kỳ phần nào của chương trình. Việc dò tìm các thay đổi không mong muốn đó của các phần tử dữliệu trong một dãy mã lệnh dài thường làm cho các lập trình viên mất rất nhiều thời gian. Lập trình tuyến tính được sử dụng trong các phần mềm còn rất đơn giản. Hiện nay, khoa học máy tính ngày càng phát triển, các phần mềm đòi hỏi ngày càng phức tạp vàlớn hơn rất nhiều, phương pháp lập trình tuyến tính được coi là kém hiệu quả.

116

Lập trình cấu trúc

Phương pháp lập trình thủ tục hay lập trình cấu trúc: hệ thống chia các chức năng (hàm) thành các chức năng nhỏ hơn. Các chức năng nhỏ này lại được chia tiếp thành các chức năng nhỏ hơn nữa cho đến khi được các khối (hàm) chương trình đủnhỏ. Việc phân tích này được thể hiện trực quan theo sơ đồ khối. Chương trình được tổ chức thành các chương trình con. Chương trình = Cấu trúc dữ liệu + giải thuật

117


Lập trình có cấu trúc sử dụng các lệnh có cấu trúc, sử dụng chương trình con, biến cục bộ.Các ngôn ngữ hỗ trợ lập trình hướng cấu trúc phổbiến là Pascal, C, FoxproLập trình hướng cấu trúc đã trở nên rất phổ biến trong những năm 80 và đầu những năm 90, nhưng do những hạn chế và những nhược điểm rõ ràng khi lập trình hệ thống lớn, lập trình hướng cấu trúc đã dần bị thay thế cho phương pháp lập trình hướng đối tượng

118


Những ngôn ngữ lập trình hướng cấu trúc chỉ còn được sử dụng để dạy học và lập trình những chương trình nhỏ mang tính chất cá nhân. Trong thương mại, nó đã không còn được dùng đến nhiều.

119

Lập trình Hướng đối tượng

Lập trình hướng đối tượng (Object Oriented Programming-OOP): Là phương pháp lập trình lấy đối tượng làm nền tảng để xây dựng thuật giải, xây dựng chương trình. OOP là kĩ thuật lập trình hỗ trợ công nghệ đối tượng. OOP được xem là giúp tăng năng suất, đơn giản hóa độ phức tạp khi bảo trì cũng như mởrộng phần mềm bằng cách cho phép lập trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn.

120


Dữ liệu + Hành vi của dữ liệu = Đối tượngNhững đối tượng trong một ngôn ngữ OOP là sựkết hợp giữa mã và dữ liệu mà chúng được nhìn nhận như là một đơn vị duy nhất. Mỗi đối tượng có một tên riêng biệt và tất cả các tham chiếu đến đối tượng đó được tiến hành qua tên của nó.

121


Như vậy, mỗi đối tượng có khả năng nhận vào các thông báo, xử lý dữ liệu (bên trong của nó), và gửi ra hay trả lời đến các đối tượng khác hay đến môi trường. Các ngôn ngữ hỗ trợ lập trình hướng đối tượng phổ biến là: C#, C++, Java, Perl, PHP, Smalltalk..

122

3.3.3. Ngôn ngữ lập trình

Lập trình là một trong những giai đoạn không thểthiếu trong công nghệ phần mềm. Ngôn ngữ lập trình là phương tiện để liên lạc giữa con người vàmáy tính. Tiến trình lập trình - sự liên lạc thông qua ngôn ngữ lập trình - là một hoạt động con người.

123

3.3.3. Ngôn ngữ lập trình

Đối với từng dự án phần mềm khác nhau người ta sẽ lựa chọn ngôn ngữ lập trình phù hợp. Tuy nhiên, ngôn ngữ lập trình được lựa chọn cần cócác đặc trưng sau:– dễ dịch thiết kế sang chương trình, – có trình biên dịch hiệu quả, – khả chuyển chương trình gốc, – có sẵn công cụ phát triển: – dễ bảo trì.

124

Lựa chọn ngôn ngữ lập trình

Dựa vào:– Đặc trưng của ngôn ngữ:

Năng lực (kiểu biến, các cấu trúc): Có cấu trúc, câu lệnh phong phú, hỗ trợ nhiều kiểu dữ liệu, hỗ trợ con trỏ, đệ qui, hỗtrợ hướng đối tượng, thư viện phong phú..Tính khả chuyển: khi thay đổi phần cứng, thay đổi OS Mức độ hỗ trợ của các công cụ (editor, debugger, linker, make..): nhằm hỗ trợ biên dịch tốc độ cao, khả năng tối ưu cao, khả năng khai thác các tập lệnh, kiến trúc phần cứng mới.

– Miền ứng dụng của ngôn ngữ – Năng lực, kinh nghiệm của nhóm phát triển – Yêu cầu của khách hàng

125


Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền ứng dụng của ngôn ngữ. Miền ứng dụng là yếu tố chính đểchúng ta lựa chọn ngôn ngữ cho một dự án phần mềm. Ngôn ngữ FORTRAN: có khả năng tính toán với độ chính xác cao và thư viện toán học phong phú thường được sửdụng trong các dự án phần mềm trong lĩnh vực khoa học kỹ thuật.COBOL: là ngôn ngữ cho ứng dụng kinh doanh và khai thác CSDL lớn. Tuy nhiên, hiện nay các ngôn ngữ thế hệthứ tư đã dần dần chiếm ưu thế so với COBOL.

126


PASCAL và C: là ngôn ngữ hay được chọn cho việc phát triển phần mềm hệ thốngLISP, PROLOG hay OPS5: là ngôn ngữ thường được dùng trong các ứng dụng trí tuệ nhân tạo.C++: Với đặc trưng hướng đối tượng, tính hiệu quả thực hiện cũng như có nhiều công cụ và thư viện, C++ hiện đang được sử dụng rộng rãi trong lĩnh vực phát triển các ứng dụng nghiệp vụ.Smalltalk, C++, Java: là các ngôn ngữ lập trình hướng đối tượng được dùng rộng rãi nhất trong việc phát triển phần mềm hướng đối tượng.

127

Java: là ngôn ngữ hướng đối tượng đang được sửdụng rộng rãi cho phát triển các dịch vụ Web vàphần mềm nhúng vì các lý do độ an toàn cao, tính trong sáng, tính khả chuyển và hướng thành phần. ASP, JavaScript, PERL: là các ngôn ngữ biên dịch (script) với những câu lệnh và thư viện mạnh. Các ngôn ngữ này hiện đang được sử dụng rộng rãi trong lập trình Web.

128

3.3.4. Phong cách lập trình

Phong cách lập trình được coi là tốt khi:– Tuân theo các chuẩn thông dụng– Chú giải đầy đủ mỗi khi không tuân theo chuẩn

Tuân theo chuẩn:– Cách đặt tên hàm và biến– Cách xây dựng câu lệnh, cấu trúc chương trình – Các viết chú thích– Cách xử lý lỗiNhằm hướng tới phong cách làm cho mã nguồn:

dễ hiểu, dễ sửa đổi, an toàn (ít lỗi)

129

Cách đặt tên hàm và biến

Đặt tên biến, tên hàm có nghĩa, gợi nhớ– Sử dụng các ký hiệu, từ tiếng Anh có nghĩa– Viết tên hàm dễ đọc: ví dụ viết DateOfBirth thay cho

dateofbirth– Tránh đặt tên quá dài– Thống nhất cách dùng biến trong toàn bộ chương trình

130

Cách xây dựng cấu trúc chương trình

Chương trình cần được chia thành nhiều mô đun (hàm). Không viết hàm quá dài:– không quá 2 trang màn hình– tạo ra các hàm thứ cấp để giảm độ dài từng hàm– Không dùng quá nhiều biến cục bộ: vì lập trình viên

khó có thể theo dõi đồng thời hoạt động của nhiều biến (thông thường một mô đun không quá 7 biến cục bộ).

131

Cách viết chú thích

Mọi thứ trong chương trình đều được chú thích:– Mục đích sử dụng của các biến– Chức năng của khối lệnh, câu lệnh

các lệnh điều khiển các lệnh phức tạp

– Chú thích các mô đunmục đích, chức năng của mô đun tham số, giá trị trả lại (giao diện) - các mô đun thuộc cấp cấu trúc, thuật toánnhiệm vụ của các biến cục bộ - tác giả, người kiểm tra, thời gian

132

Cách xử lý lỗi

Nhất quán trong xử lý lỗi:– phân loại lỗi– thống nhất định dạng thông báo lỗi,…

Có thể phát hiện lỗi trong khi thực hiện, ví dụ lỗi chia cho 0Các hàm thư viện nên tránh việc tự đưa ra thông báo lỗi.

133

3.4. Kiểm thử

3.4.1. Khái niệm3.4.2. Các phương pháp kiểm thử3.4.3. Các kỹ thuật kiểm thử3.4.4. Các loại kiểm thử3.4.5. Các hoạt động kiểm thử

134

3.4.1. Khái niệm

Kiểm thử là một trong những giai đoạn quan trọng trong phát triển phần mềm, là mấu chốt của đảm bảo chất lượng phần mềmKiểm thử là tiến trình xem xét lại đặc tả, thiết kếvà mã hoá…nhằm phát hiện lỗi phần mềm.Kiểm thử thành công khi phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Theo Sue A.Conger- The New SE)

135

3.4.1. Khái niệm

Một phép thử được gọi là thành công nếu nó phát hiện ra khiếm khuyết của phần mềm. Kiểm thử chỉ chứng minh được sự tồn tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi. Một phép kiểm thử (ca kiểm thử) bao gồm

– tên của mô đun kiểm thử– dữ liệu vào – dữ liệu ra mong muốn (kết quả đúng) – dữ liệu ra thực tế (khi đã tiến hành kiểm thử)

Các ca kiểm thử nên được thiết kế khi chúng ta tạo các tài liệu phân tích và thiết kế, chứ không phải là khi đã viết xong mã nguồn.

136

Những lưu ý khi kiểm thử

1) Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử

(2) Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình

(3) Người kiểm thử và người phát triển nên khác nhau.

137

Những lưu ý khi kiểm thử

(4) Dữ liệu thử cho kết quả bình thường thìkhông có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi.(5) Khi thiết kế trường hợp thử, không chỉ dữliệu kiểm thử nhập vào, mà phải thiết kế trước cảdữ liệu kết quả sẽ có.(6) Khi phát sinh thêm trường hợp thử thì nên thửlại những trường hợp thử trước đó để tránh ảnh hưởng lan truyền sóng khi kiểm thử.

138

3.4.2. Các phương pháp kiểm thử

Kiểm thử tĩnhKiểm thử trên máy

139

Kiểm thử tĩnh

Kiểm thử tĩnh (hay kiểm thử trên bàn): sử dụng giấy và bút, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong. Kiểm thử tĩnh thường được tiến hành trước nhằm tạo ra kịch bản cho kiểm thử động. Có 2 kỹ thuật được sử dụng– Đi xuyên suốt (walk through)– Thanh tra (inspection)

140

Kiểm thử trên máy

Kiểm thử trên máy hay kiểm thử động: Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình.9 bước của trình tự kiểm thử bằng máy:(1) Thiết kế trường hợp thử theo kiểm thử tĩnh(2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được

(3) Dịch chương trình nguồn và tạo môđun tải để thực hiện

141

(4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp

(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử

(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)

(7) Thực hiện môđun tải và ghi nhận kết quả

(8) Xác nhận kết quả với kết quả kỳ vọng

(9) Lặp lại thao tác (5)-(8)

142

3.4.3. Các kỹ thuật kiểm thử

Kiểm thử hộp trắng hay kiểm thử cấu trúc Kiểm thử hộp đen (black box testing) hay kiểm thử chức năng (functional testing)

143

Kiểm thử hộp trắng

Kiểm thử hộp trắng (white box testing): sử dụng các ca kiểm thử để kiểm tra mã nguồn ở mức các mô đun đơn vị nhằm mục đích phát hiện ra các lỗi trong các chi tiết thủ tục (thuật toán), các luồng điều khiển, các trạng thái của chương trình (dữliệu).Kiểm thử hộp trắng là sự kiểm thử dựa trên việc phân tích chương trình. Kỹ thuật chính ở đây làxác định đường đi của chương trình (điều khiển) từ đầu vàô (input) đến đầu ra (output).

144

Kiểm thử hộp trắng

Mục đích của kiểm thử hộp trắng là kiểm tra tất cả các đường đi có thể. Tức là đảm bảo mọi lệnh đều được thực hiện ít nhất một lần trong một ca thử nhiệm nào đó.Kiểm thử hộp trắng chú trọng vào phân tích các cấu trúc rẽ nhánh và các vòng lặp..

145

Kiểm thử hộp đen

Kiểm thử hộp đen (black box testing) hay kiểm thử chức năng: sử dụng các ca kiểm thử được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết, các lỗi của từng mô đun chương trình vàtoàn bộ hệ thống.

146

Kiểm thử hộp đen

Kiểm thử chức năng nhìn nhận mô đun được kiểm thử như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức làkiểm tra xem có hoạt động đúng với đặc tả hay không. Các ca kiểm thử bao gồm các trường hợp bình thường và không bình thường (dữ liệu không hợp lệ...) của mô đun.

147

3.4.4. Các loại kiểm thử

1. Kiểm thử đơn vị: là bước kiểm thử đối với từng chức năng (hàm) nhằm mục đích chính phát hiện lỗi lập trình. Người ta thường sử dụng nhiều kiểm thử cấu trúc.

2. Kiểm thử mô đun: là hình thức kiểm thử từng mô đun riêng lẻ hoặc có thể liên kết với một sốhàm, mô đun khác có liên quan.

3. Kiểm thử hệ con: nếu hệ thống bao gồm một sốhệ con độc lập thì đây là bước tiến hành kiểm thử với từng hệ con riêng biệt.

148


4. Kiểm thử hệ thống (tích hợp): kiểm thử sự hoạt động tổng thể hệ thống, kiểm tra tính đúng đắn của giao diện, tính đúng đắn với đặc tả, và tính dùng được. Chủ yếu sử dụng kiểm thử chức năng.

5. Kiểm thử thu (alpha): kiểm thử được tiến hành bởi một nhóm nhỏ người sử dụng dưới sự hướng dẫn của người phát triển, sử dụng các dữ liệu thực, thẩm định tính dùng được của hệ thống.

149


6. Kiểm thử beta: là mở rộng của kiểm thử alpha, được tiến hành với một số lớn người sử dụng không có sự hướng dẫn của người phát triển, kiểm tra tính ổn định, điểm tốt và không tốt của hệ thống.

150

3.4.5. Các hoạt động kiểm thử

Cài đặt và chuẩn bịTest

Bắt đầu

Lập kế hoạch Test

Thiết kế Test

Test tích hợp

Kết thúc

Test hệ thống

Tổng hợp, báo cáo

Xem xét và Đánh giá kết quả test

Chuẩn bị

Test

Phân tích kết quả

Lập kế hoạch

151



Bắt đầu


Thiết kế Test

Test tích hợp

Kết thúc

Test hệ thống


Xem xét và Đánh giákết quả test

Kế hoạch test

Test caseTest procedure

Test scripTest dataMôi trường

LỗiBiên bản test

Bcáo KQ testĐề xuất

Bcáo tổng hợp testHồ sơ

152


Construction Thử nghiệm

Construction Lập trình

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

Definition Xác định yêu cầu


Bắt đầu


Thiết kế Test

Test tích hợp

Kết thúc

Test hệ thống


Xem xét và Đánh giákết quả test

Termination (Kết thúc)

Transition (Triển khai)

Definition (Xác định yêu cầu)

Solution (Thiết kế kiến trúc)

Construction (Xây dựng)

Coding (lập trình)

Testing (thử nghiệm)

Initiation (khởi động)

153

3.5. Cài đặt phần mềm

3.5.1. Lập kế hoạch cài đặt3.5.2. Biến đổi dữ liệu3.5.3. Biên soạn tài liệu hệ thống

154

3.5.1. Lập kế hoạch cài đặt

Từ HTTT cũ sang HTTT mới, cần phải:Chuyển đổi phần cứngChuyển đổi phần mềm Chuyển đổi cơ sở dữ liệuChuyển đổi công nghệ quản lýChuyển đổi hệ thống biểu mẫu (thông dụng) Chuyển đổi các phương pháp truyền đạt thông tin Chuyển đổi các phương thức lưu trữ dữ liệu, thông tinChuyển đổi tác phong của lãnh đạo và các nhân viên

155

3.5.1. Lập kế hoạch cài đặt

Trong quá trình lập kế hoạch cài đặt, việc chuyển đổi kỹ thuật tương đối đơn giản. Tuy nhiên, việc chuyển đổi về con người tương đối phức tạp và kéo dài do sức ỳ vàtâm lý ngại thay đổi của người sử dụng.

Vì vậy, phải lập kế hoạch chuyển đổi tỷmỷ, bao quát tất cả các lĩnh vực của hệthống thông tin.

156

3.5.2. Biến đổi dữ liệu

Dữ liệu giữa hai hệ thống cũ và mới thường không tương thích với nhau về phương thức lưu trữ cũng như quy cách truy cập. Do đó rất dễ dẫn đến sai sót khi biến đổi dữ liệu.

Qúa trình biến đổi dữ liệu:Xác định khối lượng và chất lượng của dữ liệu (độ chính xác, tính đầy đủ và thứ tự).Làm ổn định một bản dữ liệu và tổ chức những thay đổi cho phù hợp.

157


Qúa trình biến đổi dữ liệu:Tổ chức và đào tạo đội ngũ thực hiện công việc biến đổi dữ liệu.Lập lịch thời gian của quá trình biến đổi dữ liệu.Bắt đầu quá trình biến đổi dữ liệu

dưới sự chỉ đạo thống nhất.

158


Thực hiện những thay đổi trong các tệp dữ liệu;Nếu trong hệ thống cũ có các tệp dữ liệu thì tốt nhất tổ chức biến đổi các tệp dữ liệu này trước, sau đó mới đến các tệp mới chuyển từ phương thức tổ chức thủ công sang.Thực hiện bước kiểm chứng lần cuối cùng để đảm bảo các tệp dữ liệu đã biến đổi phù hợp với các yêu cầu của hệ thống quản lý mới.

159

3.5.3. Biên soạn tài liệu hệ thống

Một phần mềm khi được chuyển giao cho phía khách hàng (người sử dụng) thường kèm theo 2 loại tài liệu sau:– Tài liệu hướng dẫn sử dụng, thông tin được thu thập

từ các nguồn khác nhau bao gồm các báo cáo xác định vấn đề, nghiên cứu tính thức thi, đề xuất hệthống và

– Tài liệu kỹ thuật cho người lập trình và bảo trì hệthống.

160

3.6. Bảo trì phần mềm

Là pha cuối cùng của vòng đời hệ thốngCác hoạt động cần thực hiện

– Quản lý hoạt động bảo trì– Chuẩn hóa hoạt động bảo trì (IEEE 840-1992)

161

Các hoạt động bảo trì phần mềm

Các yêu cầu bảo trì

Yêu cầu bảo trì được đề xuất

Yêu cầu bào trì

được chấp nhận

Mã nguồn& tài liệu đã được sửa

Mã nguồn& tài liệu hiện thời

Ban quản lý thay đổiKỹ sư bảo trì

Chăm sóc khách hàngKhách hàng

162


Yêu cầu bảo trì được đề xuất

Yêu cầu bào trì

được chấp nhận

Mã nguồn& tài liệu đã được sửa

Mã nguồn& tài liệu hiện thời

Ban quản lý thay đổiKỹ sư bảo trì

Các yêu cầu bảo trì

Khách hàngChăm sóc khách hàngQuản lý

bảo trì

Marketing

Yêu cầu bịtừ chối

163


Các công việc cần thực hiện:1. Hiểu kĩ yêu cầu bảo trì2. Phân loại yêu cầu: sửa đổi hay nâng cấp?3. Thiết kế các sửa đổi được yêu cầu4. Kế hoạch chuyển đổi từ thiết kế cũ5. Đánh giá các ảnh hưởng của sửa đổi lên ứng dụng6. Triển khai các sửa đổi7. Thực hiện các kiểm thử đơn vị cho các phần thay đổi8. Tiến hành kiểm thử tăng dần, thực hiện kiểm thử hệ thống

với các khả năng mới9. Cập nhật các tài liệu cấu hình, yêu cầu, thiết kế và

kiểm thử.

164

Ví dụ về chi phí hoạt động bảo trì

Hoạt độngĐánh giá(person-

days)Hoạt động

Đánh giá

(person-days)

1. Hiểu yêu cầu và xác định chức năng cần sửa đổi hay thêm vào

2 - 5 6. Dịch và tích hợp 2 - 3

2. Thay đổi thiết kế 1 - 4 7. Kiểm thử chức năng thay đổi 2 - 4

3. Phân tích ảnh hưởng trình diễn 1 - 4 8. Kiểm thử trình diễn 2 - 4

4. Triển khai các thay đổi thành mã nguồn 1 - 4 9. Đưa ra bản mới và

báo cáo kết quả 1

5. Thay đổi thông tin cấu hình 2 - 6 TỔNG 14 - 35

165

Chuẩn hóa hoạt động bảo trì

Hiện nay, chuẩn IEEE 840-1992 thường được dùng trong các hoạt động bảo trì phần mềm.

Các bước bảo trì phần mềm theo chuẩ 840-19921. Xác định vấn đề

2. Phân tích

3. Thiết kế

4. Triển khai

5. Kiểm thử hệ thống

6. Kiểm thử chấp nhận

7. Chuyển giao phần mềm

166

Ví dụ bảo trì phần mềm đối với giai đoạn thiết kế

a. Đầu vào •Tài liệu dự án gốc•Các phân tích từ pha trước

b. Tiến trình •Tạo ra các trường hợp kiểm thử (test cases)•Duyệt (các yêu cầu; kế hoạch triển khai)

c. Điều khiển •Kiểm chứng thiết kế•Kiểm tra thiết kế và các trường hợp kiểm thử

d. Đầu ra•Duyệt( các sửa đổi; phân tích chi tiết; kế hoạch triển khai)•Cập nhật(thiết kế gốc; kế hoạch kiểm thử)

e. Nhân tố chất lượng liên quan

•Độ linh hoạt (của thiết kế)•Khả năng lần vết (traceability)•Khả năng sử dụng lại (Reusability)•Khả năng có thể hiểu (Comprehensibility)

f. Độ đo•Chi phí người-giờ•Thời gian•Số lượng tiếp nhận thay đổi

167

Câu hỏi ôn tập

1. Nhiệm vụ chính của giai đoạn phân tích và đặc tảyêu cầu? Các công việc cần thực hiện? Các tài liệu cần bàn giao sau giai đoạn phân tích và đặc tả yêu cầu?

2. Các mô hình sử dụng trong quá trình phân tích và đặc tả yêu cầu?

3. Trình bày tầm quan trọng của thiết kế giao diện khi xây dựng phần mềm. Những điểm cần chú ý trong thiết kế giao diện

4. Các nguyên tắc thiết kế tập tin dữ liệu, những lưu ý khi thiết kế tập tin dữ liệu là gì?

168

Câu hỏi ôn tập

5. Người phát triển lựa chọn ngôn ngữ lập trình dựa trên những yếu tố nào? Phong cách lập trình ảnh hưởng tới chất lượng phần mềm như thếnào?

6. Trình bày các hoạt động kiểm thử phần mềm?7. Những lưu ý trong quá trình lập kế hoạch cài đặt

phần mềm?8. Bảo trì phần mềm là gì? Hoạt động nào trong

bảo trì phần mềm là chính yếu ?

chuong 3. cnpm

Documents