5

TỔNG QUAN VỀ CÔNG NGHỆ

HỆ THỐNG

Nội dung

5.1 Khái niệm Hệ thống

5.2 Kỹ nghệ mô hình hoá

5.3 Phân tích yêu cầu

5.4 Mô hình hoá kiến trúc và đặc tả hệ thống

5.1 Khái niệm về hệ thống

Công nghệ phần mềm ra đời là kết quả của quá trình được gọi là "kỹ nghệ hệ thống". Thay vì chỉ tập trung vào phần mềm, quá trình này tập trung vào nhiều thành phần, phân tích, thiết kế và tổ chức các thành phần vào trong một hệ thống. Hệ thống này có thể là một sản phẩm, một dịch vụ hay một kỹ thuật chuyển hóa thông tin hoặc điều khiển.

Quá trình kỹ nghệ hệ thống được gọi là kỹ nghệ quy trình nghiệp vụ khi công việc chỉ tập trung vào hoạt động nghiệp vụ của một công ty. Còn khi xây dựng một sản phẩm, (trong ngữ cảnh này một sản phẩm bao gồm tất cả mọi thứ từ điện thoại không dây đến một hệ thống điều khiển không lưu), quá trình sẽ trở thành kỹ nghệ sản phẩm.

Cả kỹ nghệ quy trình nghiệp vụ và kỹ nghệ sản phẩm đều nhằm thiết lập một trật tự cho hoạt động phát triển các hệ thống dựa máy tính. Mặc dù mỗi quá trình được áp dụng trên một lĩnh vực ứng dụng khác nhau, cả hai đều có mục đích định rõ vai trò cho phần mềm máy tính và thiết lập những ràng buộc giữa phần mềm và các thành phần khác trong một hệ thống dựa máy tính.

5.1.1 Hệ thống và hệ thống dựa vào máy tính

Từ điển Webster đã định nghĩa hệ thống như sau:

1. Một tập hoặc một trình tự sắp xếp các sự vật có liên quan nhằm hình thành nên một thể thống nhất .

2. Tập các sự kiện, nguyên lý, quy tắc,... được phân lớp và sắp xếp trong một trật tự nhằm đưa ra một kế hoạch logic liên kết nhiều bộ phận với nhau.

3. Một phương pháp hay kế hoạch phân lớp hay sắp xếp

4. Một cách thức tiến hành công việc; phương pháp; thủ tục...

 Một hệ thống dựa máy tính là một tập hợp các phần tử được tổ chức để thực hiện một số mục tiêu được xác định trước thông qua việc xử lý thông tin.

Mục đích của các hệ thống dựa máy tính là hỗ trợ các chức năng nghiệp vụ hay phát triển một thương mại... Để đạt được mục đích này, một hệ thống dựa máy tính sẽ sử dụng các thành phần:

• Phần mềm: các chương trình máy tính, cấu trúc dữ liệu và các tài liệu liên quan để triển khai các phương pháp logic, thủ tục hay điều khiển cần thiết.

• Phần cứng: các thiết bị điện tử cung cấp năng lực tính toán, các thiết bị kết nối (ví dụ: switch mạng, các thiết bị viễn thông) cho phép lưu chuyển dữ liệu, và các thiết bị cơ điện tử (ví dụ như bộ cảm biến, mô tơ, ..) cung cấp các chức năng bên ngoài.

• Con người: người sử dụng và người vận hành phần cứng, phần mềm.

• Cơ sở dữ liệu: Một tập lớn và có tổ chức các thông tin truy nhập thông qua phần mềm.

• Tài liệu: Thông tin mô tả (ví dụ như hướng dẫn sử dụng bản giấy in, tập tin trợ giúp trực tuyến, Web sites) cách sử dụng và vận hành hệ thống.

• Các thủ tục: Các bước định nghĩa cách sử dụng cụ thể từng thành phần hệ thống hay ngữ cảnh thủ tục của hệ thống.

Kỹ nghệ hệ thống bao gồm một tập các phương pháp trên-xuống và dưới-lên để có thể đi qua các phân cấp minh họa trong hình 10.1. Quá trình kỹ nghệ hệ thống thường bắt đầu với một "khung nhìn toàn thể" trong đó xem xét toàn bộ nghiệp vụ và sản phẩm để đảm bảo xây dựng được chính xác quy trình nghiệp vụ và tìm được công nghệ phù hợp. Sau đó, khung nhìn tổng thể được làm mịn để tập trung vào phạm vi cụ thể của vấn đề quan tâm với việc phân tích yêu cầu cho các phần tử của hệ thống đích (dữ liệu, phần mềm, phần cứng, con người). Cuối cùng, các bước phân tích, thiết kế và xây dựng hệ thống đích sẽ được khởi xướng.

5.1.2 Mô hình - Thông tin - Sản phẩm

Mô hình: là 1 thuật ngữ khá phổ biễn trong nhiều lĩnh vực. Ở đay, ta dùng theo nghĩa nó là một hình ảnh (một biểu diễn) của một hệ thống thực, được diễn tả:

- Ở một mức độ trừu tượng hoá nào đó,

- Theo một góc nhìn nào đó,

- Bởi một hình thức hiểu được nào đó (văn bản, phương trình, bảng, đồ thị,...).

Người ta thường phân biệt hai mức độ trừu tượng hoá chính:

- Mức lôgíc (trả lời câu hỏi "là gì ? "),

- Mức vật lý (trả lời câu hỏi "như thế nào ? ").

Có bốn góc nhìn cơ bản (gọi là 4 trục mô hình hoá):

- Vhức năng,

- Dữ liệu,

- Động thái (ứng xử),

- Kiến trúc.

Các phương pháp hiện đại thường sử dụng mô hình dưới dạng các biểu đồ và hạn chế sử dụng văn bản.

Kỹ nghệ hệ thống là một quá trình mô hình hóa. Dù tập trung vào khung nhìn tổng thể hay chi tiết, người kỹ sư sẽ tạo ra các mô hình cho phép nhằm:

• Định nghĩa các tiến trình đáp ứng nhu cầu của khung nhìn.

• Miêu tả hành vi của các tiến trình và các tiền đề là cơ sở cho hành vi.

• Định nghĩa tường minh đầu vào cả ngoại sinh lẫn nội sinh cho mô hình.

• Miêu tả các liên kết (gồm cả đầu ra) cho phép người kỹ sư hiểu khung nhìn rõ hơn.

Thông tin dùng trong mọi hệ thống kinh doanh hay dịch vụ mà chúng ta xây dựng ứng dụng được phân làm hai loại:

• Thông tin tự nhiên: là các thông tin sinh ra và thu nhận bởi con người trực tiếp bằng các cơ quan biểu đạt hay cảm thụ tự nhiên của con người. Đó là:

- thông tin viết (văn bản),

- thông tin miệng (lời nói),

- thông tin âm thanh, xúc giác, khứu giác ...,

- thông tin hình ảnh (tranh, ảnh, sơ đồ ...).

• Thông tin có cấu trúc (ở đây gọi là dữ liệu ): là các thông tin được chắt lọc từ các thông tin tự nhiên, bằng cách cấu trúc hoá lại, làm cho nó ngắn gọn hơn, chặt chẽ hơn. Đó là các dẫy giá trị (số, chữ, ...) được bố trí theo một quy cách nào đấy (cú pháp) và được hiểu nghĩa theo một cách giải thích nào đấy (ngữ nghiã). Chúng được dùng phổ biến trong các ứng dụng (phần mềm) vì:

- nhờ tính ngắn gọn mà chúng truyền đạt nhanh, tin cậy và ít tốn chỗ

- nhờ có cú pháp chặt chẽ mà chúng có thể được xử lý bằng các giải thuật, đặc biệt là bởi máy tính.

Sản phẩm: Trong ngữ cảnh của tài liệu này nó chính là phần mềm được chế tác bới các nhà phát triển theo yêu cầu của khách hàng - người dùng. Nó bao gồm các thành phần như định nghĩa trong phần 1.1 (chương 1) và đáp ứng các yêu cầu về chất lượng (1.4 - chương 1). Sản phẩm là cái đích cuối cùng, cái mà cả nhà phát ttriển và khách hàng mong đợi. Việc chế tác ra nó theo các qui trình chuẩn bởi một trong các mô hình (chương 2).

5.2 Kỹ nghệ Mô hình hoá

Người ta phân biệt 2 kỹ nghệ : kỹ nghệ hướng nghiệp vụ và kỹ nghệ hướng sản phẩm.

5.2.1 Kỹ nghệ hướng nghiệp vụ

Mục đích của kỹ nghệ quy trình nghiệp vụ (BPE) là định nghĩa các kiến trúc cho phép sử dụng thông tin hiệu quả trong công việc.

Phân tích bài toán nghiệp vụ liên quan đến việc xác định chi tiết dữ liệu (trong dạng thức của kiểu thực thể (đối tượng dữ liệu) và các yêu cầu chức năng (trong dạng thức của các xử lí (quá trình) của phạm vi nghiệp vụ đã chọn, được xác định trong ISP; xác định khả năng tương tác giữa chúng . Hoạt động này chỉ liên quan đến việc xác định những yêu cầu trong phạm vi nghiệp vụ.

Ba kiến trúc cần phân tích và thiết kế khi xem xét các mục đích và mục tiêu nghiệp vụ:

• Kiến trúc dữ liệu: Kiến trúc dữ liệu cung cấp một khung làm việc cho các nhu cầu thông tin của một công việc (nghiệp vụ) hoặc của một chức năng nghiệp vụ. Các phần tử của kiến trúc này chính là các đối tượng dữ liệu được sử dụng bởi công việc. Một đối tượng dữ liệu chứa một tập các thuộc tính định nghĩa các khía cạnh, đặc tính, chất lượng hay mô tả về dữ liệu.

• Kiến trúc ứng dụng: gồm các thành phần của hệ thống biến đổi các đối tượng bên trong một kiến trúc dữ liệu nhằm một số mục đích nào đó. Trong khuôn khổ tài liệu này, chúng ta coi kiến trúc ứng dụng là hệ thống các chương trình (phần mềm) thực hiện việc biến đổi này.

• Cơ sở hạ tầng công nghệ: cung cấp nền tảng cho dữ liệu và kiến trúc ứng dụng. Cơ sở hạ tầng bao gồm phần cứng và phần mềm được sử dụng để hỗ trợ ứng dụng và dự liệu, bao gồm máy tính, hệ điều hành, mạng máy tính, các kết nối viễn thông, công nghệ lưu trữ và kiến trúc (ví dụ Khách /Chủ) được thiết kế để thực hiện các công nghệ đó.

5.2.2 Kỹ nghệ hướng sản phẩm

Mục đích của kỹ nghệ sản phẩm là biến mong muốn của khách hàng về các tính năng thành một sản phẩm hữu hình. Để đạt được điều đó, kỹ nghệ sản phẩm - cũng như quá trình kỹ nghệ nghiệp vụ phải bắt nguồn từ kiến trúc và cơ sở hạ tầng. Kiến trúc bao gồm bốn thành phần hệ thống tách biệt: phần mềm, phần cứng, dữ liệu (cơ sở dữ liệu) và con người. Một cơ sở hạ tầng hỗ trợ được thiết lập và bao gồm cả công nghệ cần thiết để liên kết các thành phần lại với nhau và thông tin (ví dụ, tài liệu, CD-ROM, video) dùng để hỗ trợ các thành phần đó (hình 10.3).

5.3 Phân tích yêu cầu

Kỹ nghệ yêu cầu cung cấp cơ chế thích hợp để có thể hiểu khách hàng muốn gì, phân tích nhu cầu, ước định tính khả thi, thương thảo một giải pháp hợp lý, và đặc tả giải pháp một cách rõ ràng tường minh, thẩm định lại đặc tả và quản lý các yêu cầu khi chúng được biến đổi sang hệ thống vận hành [THA97]. Quá trình kỹ nghệ yêu cầu có thể chia thành năm bước [SOM97]:

• Phát hiện thu thập yêu cầu (requirements elicitation)

• Phân tích và thương lượng yêu cầu (requirements analysis and negotiation)

• Đặc tả yêu cầu (requirements specification)

• Mô hình hóa hệ thống (system modeling)

• Thẩm định yêu cầu (requirements validation)

• Quản lý yêu cầu (requirements management)

5.3.1 Phân tích yêu cầu

Trong hầu hết các hệ thống, sản phẩm công việc của bước này bao gồm:

- Phát biểu về nhu cầu và tính khả thi.

- Phát biểu về phạm vi của hệ thống hay sản phẩm.

- Danh sách khách hàng, người sử dụng và các cá nhân liên quan tham gia vào hoạt động thu thập yêu cầu.

- Bản mô tả môi trường kỹ thuật của hệ thống

- Danh sách các yêu cầu (được tổ chức theo chức năng) và các ràng buộc phạm vi trên các yêu cầu này

- Tập hợp các ngữ cảnh sử dung cung cấp tường tận cách sử dụng hệ thống hay sản phẩm trong các điều kiện vận hành khác nhau.

- Các mẫu thử nếu có để xác định tốt hơn các yêu cầu.

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

Các câu hỏi sau thường được đặt ra khi bắt đầu việc phân tích yêu cầu:

- Yêu cầu có nhất quán với mục tiêu tổng thể của hệ thống/sản phẩm?

- Tất cả các yêu cầu có được đặc tả ở một mức độ trừu tượng hóa phù hợp? Nghĩa là, liệu có một vài yêu cầu ở mức quá chi tiết về kỹ thuật nên không thích hợp ở giai đoạn này?

- Yêu cầu có thật sự là cần thiết hay chỉ thể hiện một tính năng bổ sung nào đó không phải là chủ chốt, thiết yếu của hệ thống?

- Yêu cầu có xác định phạm vi và không nhập nhằng?

- Mỗi yêu cầu đều có ghi lại nguồn (thông thường là một cá nhân cụ thể)

- Có yêu cầu nào xung đột, mâu thuẫn với các yêu cầu khác?

- Liệu yêu cầu có thể thực hiện được trong môi trường kỹ thuật của hệ thống/sản phẩm.

5.3.3 Đặc tả yêu cầu

Trong ngữ cảnh các hệ thống dựa máy tính (và phần mềm), thuật ngữ đặc tả có thể hiểu theo nhiều cách khác nhau. Một đặc tả có thể là một tài liệu viết, một mô hình hình học, một mô hình toán học hình thức, một tập các kịch bản sử dụng, hay là kết hợp các loại tài liệu này.

Đặc tả hệ thống là sản phẩm cuối cùng tạo ra từ hệ thống và kỹ sư yêu cầu. Đặc tả hệ thống được coi là tài liệu nền tảng cho kỹ nghệ phần cứng, kỹ nghệ phần mềm, kỹ nghệ cơ sở dữ liệu và kỹ nghệ nhân lực. Tài liệu này mô tả chức năng và hiệu năng của một hệ thống dựa trên máy tính với các ràng buộc nhằm quản lý tiến trình phát triển. Đặc tả này bao trùm tất cả các thành phần có trong hệ thống.

5.3.4 Mô hình hoá hệ thống

Mỗi hệ thống dựa máy tính đều có thể mô hình như một bộ chuyển đổi thông tin theo mẫu đầu vào-xử lý-đầu ra.

Sử dụng các biểu diễn đầu vào, xử lý, đầu ra, xử lý giao diện người dùng và tự kiểm thử, người kỹ sư hệ thống có thể mô hình các thành phần hệ thống tạo nên nền tảng cho các bước tiếp theo của quy trình kỹ nghệ.

5.3.5 Thẩm định yêu cầu

Các sản phẩm công việc được tạo ra như là kết quả của quá trình kỹ nghệ yêu cầu (một đặc tả hệ thống và thông tin liên quan) được đánh giá chất lượng trong suốt giai đoạn thẩm định. Thẩm định yêu cầu kiểm tra đặc tả để đảm bảo:

- Tất cả các yêu cầu hệ thống là không nhập nhằng.

- Những chi tiết không nhất quán, thiếu sót hay lỗi được phát hiện và chỉnh sửa.

- Sản phẩm công việc thích hợp với các chuẩn được thiết lập về quy trình, dự án và sản phẩm.

5.3.6 Quản lý yêu cầu

Quản lý yêu cầu là một tập các hoạt động nhằm giúp nhóm dự án xác định, điều khiển, theo dõi các yêu cầu và những thay đổi trên các yêu cầu tại bất cứ thời điểm nào của dự án. Nhiều hoạt động trong số này đồng nhất với các kỹ thuật quản lý cấu hình phần mềm được trình bày trong chương 4.

5.4 Mô hình hoá kiến trúc và đặc tả hệ thống

Giống như hầu hết các hệ thống được dùng trong kỹ nghệ hệ thống và kỹ nghệ phần mềm, mẫu mô hình hệ thống cho phép nhà phân tích tạo được phân cấp chi tiết cho hệ thống. Biểu đồ ngữ cảnh hệ thống - System Context Diagram (SCD) sẽ nằm ở đỉnh của phân cấp. Biểu đồ này sẽ "thiết lập biên thông tin giữa hệ thống sẽ được xây dựng và môi trường vận hành hệ thống" [HAT87]. Như vậy, SCD sẽ định nghĩa tất cả các đối tượng bên ngoài mà cung cấp thông tin hệ thống cần hoặc sử dụng thông tin do hệ thống xuất ra cùng tất cả những thực thể giao tiếp thông qua giao diện hệ thống hoặc thực hiện chức năng bảo trì và tự kiểm thử.

Các hệ thống con và thông tin qua lại giữa chúng có thể đặc tả (hoặc ràng buộc) vào các giai đoạn kỹ nghệ sau đó. Bản mô tả của từng hệ thống con và tất cả các luồng dữ liệu qua lại giữa các hệ thống con này là những thành phần quan trọng trong bản Đặc tả Hệ thống.

6

ĐẶC TẢ YÊU CẦU NGƯỜI DÙNG

Nội dung

6.1 Yêu cầu người dùng là gì ?

6.2 Nh÷ng vÊn ®Ò trong xác ®Þnh yªu cÇu người dùng

6.3 Nội dung và Qui trình xác định yªu cÇu

6.4 Phương pháp và công cụ đặc tả

6.5 Ứng dụng các nguyên lý phân tích yêu cầu

6.1 Yêu cầu người dùng là gì ?

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)

• 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

6.2 Nh÷ng vÊn ®Ò trong xác ®Þnh yªu cÇu người dùng

• 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ọ, chúng ta 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, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý

6.3 Nội dung và Qui trình xác định yªu cÇu

6.3.1 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)

6.3.2 Qui trình

6.3.3 Mô hình phân tích

6.4 Phương pháp và công cụ đặc tả

• Đặc tả các yêu cầu phần mềm là công việc xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các cô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ịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên

• Chấ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

• Có 2 kiểu đặc tả: phi hình thức và hình thức.

- Đặ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ẽ, thí dụ ký pháp đồ họa dùng các lưu đồ.

• Hai khía cạnh trong phần mềm phải dadực tả đó là đặc tả vận hành chức năng/chức năng và đặc tả mô tả/phi chức năng:

- Đặ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ác dịch vụ mà hệ thống phải cung cấp, hệ thống sẽ phản ứng với đầu vào cụ thể ra sao, Hành vi của hệ thống trong các tình huống đặc biệt.

- Đặc tả mô tả hay đặc tả phi chức năng (Descriptive specifications) - đặc tả các đặc tính, đặc trưng của phần mềm: các ràng buộc về các dịch vụ hay các chức năng hệ thống cung cấp như thời gian, ràng buộc về các quá trình phát triển, các chuẩn,...

• Đặc tả chức năng (Funtional Specifications):

i) Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu PM và mong đợi của người dùng

ii) 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),...

Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự nhiên.

• Đặc tả phi chức năng (Non-Funtional Specifications):

i) Định nghĩa các tính chất của hệ thống, các ràng buộc, thí dụ như độ tin cậy, thời gian trả lời, dung lượng bộ nhớ,...

ii) Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, chuẩn tài liệu,...

iii, Các yêu cầu từ ngoài

Đặc tả mô tả thường sử dụng các công cụ:

- Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)

- Đặc tả Logic (Logic Specifications)

- Đặc tả đại số (Algebraic Specifications)

Nhìn chung đặc tả phi chức năng rất khó phát biểu chính xác và rất khó kiểm tra. Trong khuôn khổ tài liệu này chúng tôi chỉ đề cập đến đặc tả dữ liệu.

6.4.1 Đặc tả chức năng bằng sơ đồ luồng dữ liệu DFD

• Biểu đồ luồng dữ liệu: là một công cụ cho phép diễn tả một quá trình xử lý thông tin (một chức năng) với các yêu cầu sau:

- Có thể áp dụng ở 2 mức độ: lôgic và vật lý.

- Chỉ rõ các chức năng con phải thực hiện để hoàn tất quá trình xử lý thông tin

- Chỉ rõ các thông tin được chuyển giao giữa các chức năng và cho phép hình dung trình tự thực hiện của chúng.

• Trong kiểu đặc tả này, phần mềm được coi là một Hệ thống (System) gồm tập hợp các dữ liệu (data) được xử lý bằng các chức năng tương ứng (functions)

• Các ký pháp sử dụng:

- Chức năng (functions): biểu diễn bởi vòng tròn

Trong chứa tên chức năng và thường là động từ

- Luồng dữ liệu: biểu diễn bằng mũi tên một/hai chiều.

Chiều mũi tên chỉ chiều vận động của lưồng thông tin

- Kho dữ liệu: Nơi lưu trữ dữ liệu tạm thời hay lâu dài

cho xử lý và được biểu diễn bởi 2 gạch song song bên

trong có tên. Tên kho là danh từ + tính từ

- Bộ phận vào ra dữ liệu: biểu diễn sự tương tác giữa

hệ thống và người sử dụng. Cách biểu diễn là khá khác

nhau theo qui ước.

Biểu đồ lường dữ liệu có thể phân mức. Nguyên tắc phân mức được chỉ ra trong phần nguyên lý phân tích dưới đây.

 Các hạn chế của DFD

- Trong DFD không xác định rõ các hướng thực hiện (control aspects)

- DFD không xác định sự đồng bộ giữa các chức năng / mô-đun

6.4.2 Đặc tả chức năng bằng máy trạng thái hữu hạn FSM

Công cụ này được sử dụng trong nhiều lĩnh vực. Nó bao gồm:

- Tập hữu hạn các trạng thái Q

- Tập hữu hạn các đầu vào I

- Các chức năng chuyển tiếp

Xét thí dụ về quản lý thư viện. Ta có tập hợp các sách (mỗi đầu sách có thể có nhiều quyển sách trong thư viện). Mỗi quyển sách có thể có 1 trong 5 trạng thái sau:

(AV) - Available được phép mượn, (CO) - (BR) - đã mượn (Check Out; Borrow), (L): Last, (R): Remove

6.4.3 Đặc tả dữ liệu bằng sơ đồ thực thể liên kết ERD...

Có nhiều mô hình cho phép biểu diễn các đối tượng của hệ thống. Trong đó phải kể đến mô hình thông dụng như mô hình thực thể liên kết, mô hình hướng đối tượng. Ở đây ta chỉ xét mô hình thực thể liên kết.

Mô hình này sử dụng 3 thành phần chính:

- Tực thể (Entity)

- Thuộc tính (Attibutes)

- Quan hệ (Relationship)

Kết quả của mô hình này là lưu đồ thực thể liên kết - ERD (Entity Relationship Diagram). Nó biểu diễn tập các đối tượng cần thiết của hệ thống cũng như mối quan hệ giữa các thực thể. Nó là nền tảng để thiết kế cơ sở dữ liệu trong giai đoạn sau của vòng đời phần mềm.

• Thực thể - tập hợp các thông tin liên quan cần được xử lý trong phần mềm

Người ta biểu diễn thực thể bằng một hình chữ nhật, bên trong có tên. Tên thường là một danh từ. Hình dưới đây biểu diễn 2 thực thể "Người" và "Xe" với mối quan hệ: Người sở hữu 1 Xe.

Thực thể có các thuộc tính

• Thuộc tính: Thể hiện một tính chất nào đó của thực thể như tên, màu sắc,... Tập các thuộc tính của 1 đối tượng dữ liệu được xác định thông qua ngữ cảnh của bài toán.

• Quan hệ: chỉ ra mối liên quan gữa các đối tượng dữ liệu

Người ta thường sử dụng 3 loại quan hệ:

- Quan hệ 1 - 1: Một thể hiện của kiểu thực thể A ứng với 1 thể hiện của kiểu thực thể B. Quan hệ kiểu này có thể biểu diễn bởi 1 đoạn thẳng nối 2 kiểu thực thể. Cũng có khi không cần biểu diễn

- Quan hệ một nhiều: 1 - N. Một thể hiện của kiểu thực thể A ứng với 0, 1, 2,... nhiều thể hiện của kiểu thực thể B. Cách biểu diễn như trên. Thí dụ một Phòng có nhiều Nhân viên.

- Quan hệ nhiều nhiều: M - N. Một thể hiện của A ứng với nhiều thể hiện của kiểu thực thể B và ngược lại, một thể hiện của kiểu thực thể B ứng với nhiều thể hiện của A. Người ta thường biểu diễn:

Tuy nhiên, trong thực tế người ta thường sử dụng 2 kiểu liên kết (quan hệ) một nhiều để biểu diễn quan hệ này. Thực thể trung gian dùng để biểu diễn mối liên kết gọi là thực thể liên kết.

Trong biểu diễn, để làm rõ nghĩa các quan hệ, người ta dùng thêm bản số (Cardinality). Các bản số này có giá trị 0, 1, 2,... (như hình trên). Việc dùng bản số là không bắt buộc.

Ngoài mối quan hệ 2 ngôi, người ta có thể dùng thêm mối quan hệ nhiều ngôi. Việc sử dụng các mối quan hệ nào xuất phát từ bài toán phải giải quyết.

6.5 Ứng dụng các nguyên lý phân tích yêu cầu

Trong quá trình phân tích, đặc tả yêu cầu phần mềm, người ta thường áp dụng 5 nguyên lý được trình bày dưới đây.

6.5.1 Nguyên lý mô hình hoá dữ liệu

- Xác định các đối tượng dữ liệu: các đối tượng thoả định nghĩa ở trên và thường ở các nguồn sau: con người, tài nguyên, sổ sách có cấu trúc và các giao dịch

- Xác định các đặc tính của các đối tượng dữ liệu: Phụ thuộc vào bản chất bài toán

- Thiết lập các mối quan hệ giữa các đối tượng dữ liệu: các mối quan hệ tự nhiên và do nhu cầu quản lý

6.5.2 Nguyên lý mô hình hoá chức năng

- Xác định các chức năng chuyển đổi đối tượng dữ liệu: xuất phát từ nhu cầu xử lý

- Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào: Qui trình xử lý

- Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệu: Các nguồn cung cấp thông tin và thu nhận thông tin (các tác nhân ngoài)

6.5.3 Nguyên lý mô hình hoá hành vi

- Chỉ ra các trạng thái (states) khác nhau của hệ thống

- Đặc tả các hiện tượng (events) làm hệ thống thay đổi trạng thái

Nguyên lý này thường sử dụng cho các hệ thống mà chúng ta mô tả qua tập các trạng thái.

6.5.4 Nguyên lý phân rã

Tinh lọc từng mô hình để biểu diễn các mức trừu tượng thấp hơn:

- Lọc đối tượng dữ liệu

- Tạo ra phân cấp chức năng

- Biểu diễn hành vi (behavior) ở các mức chi tiết khác nhau

Đây là nguyên lý rất quan trọng cho phép phân rã để hiểu hệ thống hơn theo kiểu Top - Down

6.5.5 Nguyên lý dựa vào bản chất

Hãy bắt đầu bằng cách tập trung vào bản chất của vấn đề chứ không xem xét những chi tiết cài đặt.