0
Tải bản đầy đủ (.pdf) (90 trang)

Các quy tắc ràng buộc và suy diễn

Một phần của tài liệu PHÂN TÍCH THIẾT KẾ HỆ THỐNG QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC THEO HƯỚNG ĐỐI TƯỢNG (Trang 29 -29 )

Trong mô hình hóa hệ thống với UML, ta có thể sử dụng ngôn ngữ ràng buộc đối tượng (OCL) để đặc tả chính xác các phần tử của hệ thống và các ràng buộc chặt

chẽ giữa các mối quan hệ, giới hạn phạm vi của mô hình hệ thống cho phù hợp với điều kiện ràng buộc thực tế.

Trong UML có hai quy tắc chính:

- Quy tắc ràng buộc được sử dụng để giới hạn phạm vi của mô hình, ví dụ các qui tắc hạn chế, quy định rõ phạm trù của các mối quan hệ như kết hợp, kế thừa hay khả năng nạp chồng trong các lớp.

- Quy tắc suy dẫn chỉ ra cách các sự vật có thể suy dẫn được, ví dụ tuổi của một người có thể suy ra được từ ngày/tháng/năm hiện thời trừ đi ngày/tháng/năm sinh.

2.3. Quá trình phát triển phần mềm hƣớng đối tƣợng

Để xây dựng được những hệ thống phần mềm đáp ứng những yêu cầu chất lượng, chúng ta cần phải:

- Có một qui trình phát triển phần mềm thống nhất gồm các bước thực hiện rõ ràng, mà sau mỗi bước đều phải có các sản phẩm cụ thể;

- Có các phương pháp và kỹ nghệ phù hợp với từng pha thực hiện phát triển phần mềm;

- Có công cụ để làm ra sản phẩm phần mềm theo yêu cầu.

Quá trình phát triển một sản phẩm là quá trình định nghĩa ai làm cái gì, làm khi nào và như thế nào. Quá trình xây dựng một sản phẩm phần mềm hoặc nâng cấp một sản phẩm đã có được gọi là quá trình phát triển phần mềm.

Quá trình phát triển phần mềm được xác định thông qua tập các hoạt động cần thực hiện để chuyển đổi các yêu cầu của khách hàng (người sử dụng) thành hệ thống phần mềm.

Có năm bước chính cần thực hiện trong quá trình phát triển phần mềm: - Xác định các yêu cầu;

- Phân tích hệ thống; - Thiết kế hệ thống;

- Lập trình và kiểm tra hệ thống; - Vận hành và bảo trì hệ thống.

Có thể thực hiện các bước trên theo nhiều phương pháp khác nhau. Theo đó, số các bước đề xuất của các phương pháp cũng có thể khác nhau. Có dự án có thể thực hiện theo những mô hình khác nhau như mô hình “thác nước”, mô hình “tạo nguyên mẫu”, mô hình “xoắn ốc”, … tùy thuộc vào từng dự án khác nhau.

2.3.1 Xác định các yêu cầu của hệ thống

Trong bước xác định các yêu cầu của hệ thống, ta chia thành 2 giai đoạn: + Xây dựng mô hình nghiệp vụ

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

2.3.1.1. Xây dựng mô hình nghiệp vụ

Để nắm bắt được yêu cầu của một hệ thống tin học hóa, ta cần tìm hiểu hệ thống thực. Công việc này được tiến hành bằng cách tìm hiểu hoạt động nghiệp vụ và

xây dựng các mô hình miền và mô hình nghiệp vụ để nắm bắt toàn bộ các vấn đề thuần nghiệp vụ của hệ thống.

Việc tìm hiểu hoạt động nghiệp vụ được tiến hành qua các bước sau - Tìm hiểu bối cảnh hệ thống

- Nắm bắt các yêu cầu phi chức năng

a. Tìm hiểu bối cảnh hệ thống

Mô tả bối cảnh của một hệ thống bằng cách xây dựng mô hình miền và mô hình nghiệp vụ của nó. Tùy theo yêu cầu của từng bài toán cụ thể mà ta có thể xây dựng một mô hình miền hoặc một mô hình nghiệp vụ đầy đủ, hoặc cả hai hoặc không cần mô hình nào cả.

- Xây dựng mô hình miền: Mục đích của mô hình hóa miền là để hiểu và mô tả các lớp quan trọng nhất bối cảnh của miền. Ta có thể lập một từ điển giải thích để định nghĩa về các lớp miền. Từ điển thuật ngữ và mô hình miền giúp khách hàng và người phát triển chia sẻ những thuật ngữ khái niệm chung. Đối với những miền nghiệp vụ rất nhỏ, không cần thiết phát triển một mô hình miền mà chỉ cần sử dụng từ điển thuật ngữ là đủ.

Mô hình miền (domain model) mô tả các khái niệm quan trọng của hệ thống qua các đối tượng của miền nghiệp vụ và liên kết giữa chúng với nhau. Các đối tượng miền là những vật hay khái niệm trong thực tế hoặc các sự kiện diễn ra trong môi trường mà hệ thống làm việc. Mô hình miền có thể mô tả bằng nhiều biểu đồ lớp của UML. Có 3 dạng lớp đối tượng miền điển hình

+ Các đối tượng nghiệp vụ thể hiện những vật được quản lý trong hoạt động nghiệp vụ như: đơn đặt hàng, tài khoản, hợp đồng…

+ Các đối tượng thế giới thực và các khái niệm mà một hệ thống cần theo dõi, ví dụ như giao dịch thanh toán, mua hàng, rút tiền…

+ Các sự kiện sẽ hoặc đã xuất hiện: đưa thẻ vào máy, nhấn phím, trả tiền… - Xây dựng mô hình nghiệp vụ: Mô hình nghiệp vụ (Bussiness model) được thể hiện ra bằng một mô hình ca sử dụng nghiệp vụ. Nó có thể bao gồm các chế tác (thành phần) sau:

+ Đối tượng miền; + Đối tượng nghiệp vụ;

+ Người tham gia nghiệp vụ và các trách nhiệm, thao tác tương ứng;

+ Mô hình ca sử dụng nghiệp vụ mô tả các quá trình nghiệp vụ của một tổ chức dưới dạng các ca sử dụng nghiệp vụ và các tác nhân nghiệp vụ tương ứng. Nó xem xét một hệ thống nghiệp vụ từ quan điểm người sử dụng và chỉ ra làm thế nào để hệ thống cung cấp một giá trị gia tăng cho tác nhân nghiệp vụ hệ thống đó. Mô hình ca sử dụng nghiệp vụ được miêu tả bằng sơ đồ ca sử dụng [3]

Mô hình miền là một trường hợp riêng của mô hình nghiệp vụ mà ở đó ta chỉ tập trung vào các vật, các lớp miền hoặc các thực thể nghiệp vụ mà người tham gia nghiệp vụ sẽ phải làm với chúng.

Một mô hình nghiệp vụ được phát triển qua hai bước:

+ Xây dựng một mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ mà các tác nhân sử dụng. Mô hình cho phép người phát triển hiểu rõ hơn về giá trị mà nghiệp vụ đem lại cho tác nhân sử dụng nó

+ Phát triển một mô hình đối tượng nghiệp vụ bao chứa những người tham gia nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các ca sử dụng nghiệp vụ. Các quy tắc nghiệp vụ và các điều chỉnh khác trong nghiệp vụ được liên kết với các đối tượng khác

b. Nắm bắt các yêu cầu bổ sung

Các yêu cầu bổ sung là các yêu cầu phi chức năng mà không thể liên kết với các ca sử dụng nghiệp vụ cụ thể nào. Chúng có ảnh hưởng đến nhiều ca sử dụng hoặc chỉ đến một ca sử dụng nghiệp vụ nào đó. Ví dụ như tính thể hiện, các giao diện, các yêu cầu thiết kế vật lý và kiến trúc, các ràng buộc về thiết kế và cài đặt.

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

Mục tiêu của việc xác định yêu cầu là phát triển một mô hình ca sử dụng của hệ thống cần xây dựng bằng cách dùng các ca sử dụng. Các ca sử dụng cung cấp một cách có hệ thống và trực quan để nắm bắt các yêu cầu có tính chức năng mà tập trung đặc biệt vào giá trị gia tăng đem lại cho mỗi cá nhân người dùng hoặc mỗi hệ thống bên ngoài tương tác với hệ thống. Kết quả của luồng công việc này là một phiên bản đầu tiên của mô hình ca sử dụng, các ca sử dụng và các bản mẫu giao diện – người sử dụng đã được tổng hợp lại. Các kết quả của các lần lặp tiếp theo sẽ gồm các phiên bản mới của các thành phần này nhưng chúng sẽ được hoàn thiện, được cải tiến và làm mịn dần trong quá trình các bước lặp.

Để mô tả yêu cầu nghiệp vụ của hệ thống dưới góc độ phát triển phần mềm cần:

a. Tìm các tác nhân và các ca sử dụng

Việc xác định các ca sử dụng và các tác nhân gồm bốn bước dưới đây. Các bước này không bắt buộc phải thực hiện theo thứ tự mà thường được thực hiện đồng thời. Kết quả của hoạt động này là một phiên bản của mô hình ca sử dụng với các tác nhân và các ca sử dụng

Bước 1: Tìm các tác nhân

Tác nhân (actor) thể hiện cho những phần ngoài hệ thống mà tương tác với hệ thống. Tác nhân có thể là các kiểu người dùng hoặc các kiểu hệ thống ngoài của hệ thống. Một tác nhân đóng một vai trò nào đó đối với mỗi ca sử dụng mà nó tương tác. Mỗi khi một người dùng (hoặc hệ thống ngoài cụ thể) tương tác với hệ thống, thể hiện của tác nhân tương ứng đóng một vai trò mà người dùng thực hiện

Có hai tiêu chuẩn để xác định các tác nhân:

- Phải có ít nhất một người dùng mà có thể thực hiện vai trò của tác nhân dự kiến - Sự trùng lặp giữa các vai trò của những tác nhân khác nhau đóng vai trong mối quan hệ với hệ thống là tối thiểu nhất

Sau khi tìm được tác nhân cần mô tả ngắn gọn các vai trò của mỗi tác nhân tương tác với hệ thống và mục tiêu sử dụng hệ thống. Việc mô tả ngắn gọn mỗi tác nhân phải nêu bật được các yêu cầu và các trách nhiệm của tác nhân đó. Các tác nhân nhận được ở đây có thể dùng làm điểm xuất phát để tìm các ca sử dụng

Bước 2: Tìm các ca sử dụng

Mỗi cách thức mà tác nhân sử dụng hệ thống được gọi là một ca sử dụng. Từ danh sách các tác nhân, ta xác định các ca sử dụng mà mỗi tác nhân này thực hiện. Mỗi ca sử dụng đặc tả một chuỗi các hành động (kể cả các chuỗi hành động thay thế) mà hệ thống có thể thực hiện khi tương tác với các tác nhân của nó. Một thể hiện ca sử dụng là sự thực hiện (hoặc xử lý) của ca sử dụng đó.

Bước 3: Mô tả ngắn gọn mỗi ca sử dụng

Sau khi tìm được các ca sử dụng, trước hết mô tả nó một cách ngắn gọn để tóm tắt các hành động của ca sử dụng.

Bước 4: Mô tả Mô hình ca sử dụng tổng thể

Một mô hình ca sử dụng là một mô hình của một hệ thống. Nó bao gồm các tác nhân, các ca sử dụng và các mối quan hệ giữa chúng. Chúng ta sử dụng các biểu đồ và các mô tả để diễn đạt mô hình ca sử dụng tổng thể, đặc biệt là các ca sử dụng có liên quan đến nhau. Các ca sử dụng trong mô hình ca sử dụng có thể được tổ chức thành các cụm ca sử dụng được gọi là các gói ca sử dụng

Kết quả của bước này cũng là một mô tả tổng quan của mô hình ca sử dụng. Nó mô tả các tác nhân và các ca sử dụng tương tác với nhau như thế nào, và các ca sử dụng liên kết với nhau như thế nào.

b. Sắp xếp thứ tự ưu tiên các ca sử dụng

Mục đích hoạt động này là nhằm lập thứ tự ưu tiên các ca sử dụng để quyết định những ca sử dụng nào cần được triển khai ngay trong những lần lặp đầu và chúng đóng vai trò như kiến trúc của hệ thống

Mô tả kiến trúc là một cái nhìn về mặt kiến trúc của mô hình ca sử dụng. Nó gồm những ca sử dụng mang ý nghĩa về mặt kiến trúc. Một mô tả kiến trúc của một mô hình ca sử dụng thường bao gồm các ca sử dụng mô tả một vài chức năng cốt yếu và quan trọng hoặc liên quan đến một vài yêu cầu quan trọng mà cần được phát triển. Mô tả kiến trúc này thường được sử dụng như là đầu vào để phân loại các ca sử dụng cho việc phát triển trong một vài bước lặp đầu

c. Mô tả chi tiết một ca sử dụng

Mục đích chính ở đây là mô tả luồng các sự kiện của ca sử dụng một cách chi tiết khi khởi đông, tương tác với các tác nhân như thế nào đến kết thúc. Để mô tả chi tiết ca sử dụng ta có thể mô tả bằng văn bản (hay bảng) và các biểu đồ ca sử dụng kèm theo.

Luồng các sự kiện của một ca sử dụng là luồng các sự kiện đặc tả chuỗi công việc mà hệ thống làm khi một ca sử dụng cụ thể được thực hiện. Luồng các sự kiện cũng đặc tả cách thức mà hệ thống tương tác với các tác nhân khi ca sử dụng được thực hiện. Nó có thể được mô tả dưới dạng văn bản (hay bảng) chuỗi các hoạt động của một ca sử dụng.

- Cấu trúc của một mô tả ca sử dụng thường được tổ chức sao cho cả người phát triển, khách hàng, và người dùng đều có thể hiểu được. Mô tả ca sử dụng cần có cấu trúc như sau:

 Trạng thái xuất phát (tiền điều kiện)

 Làm thế nào và khi nào thì ca sử dụng khởi động (tức là hành động thứ nhất được thực hiện như thế nào)

 Các chuỗi hành động phải được thực hiện theo thứ tự. Ở đây thứ tự được xác định bởi chuỗi hành động đã đánh số

 Ca sử dụng kết thúc như thế nào và khi nào  Trạng thái khi kết thúc (hậu điều kiện)  Các con đường không được phép thực hiện

 Mô tả các con đường cơ bản (phương án) mà dãy hành động xảy ra  Mô tả các phương án ngoại lệ

Có thể mô tả mỗi phương án thực hiện ca sử dụng bằng văn bản (hay một bảng với cột tác nhân và cột phản ứng của hệ thống)

Một nhiệm vụ quan trọng nữa là đặc tả là những yêu cầu phi chức năng. Đa số các yêu cầu phi chức năng đều có liên quan tới một ca sử dụng cụ thể nào đó. Chẳng hạn các yêu cầu về tốc độ thực hiện, tính khả dụng, độ chính xác, thời gian phúc đáp, thời gian phục hồi. Các yêu cầu như vậy được gọi là các yêu cầu đặc biệt của ca sử dụng đang xét. Ta có thể chuẩn bị chúng như một phần tài liệu của Mô tả ca sử dụng

- Hình thức hóa các mô tả ca sử dụng: Đối với các ca sử dụng phức tạp, có nhiều trạng thái và sự chuyển tiếp, các mô tả ca sử dụng bằng văn bản thường không đảm bảo tính chất nhất quán và làm cho người phát triển khó hình dung. Do vậy, có thể mô tả cấu trúc đó bằng cách sử dụng các biểu đồ có tính trực quan hơn.

d. Tạo bản mẫu Giao diện người dùng

Bây giờ ta cần phác thảo các giao diện người dùng để giúp cho người thực hiện các ca sử dụng một cách hiệu quả. Với mỗi ca sử dụng, ta cố gắng để nhận biết xem cái gì là cần đối với các giao diện người dùng để tạo ra khả năng cho mỗi tác nhân

dùng các ca sử dụng. Công việc này gọi là thiết kế giao diện người dùng logic. Sau đó ta tạo thiết kế giao diện người dùng thực và phát triển các bản mẫu để minh họa cách thức mà các người dùng có thể dùng hệ thống để thực hiện các ca sử dụng.

- Tạo một thiết kế Giao diện người dùng Logic: Khi các tác nhân tương tác với hệ thống, tác nhân sẽ dùng và thao tác qua yếu tố giao diện người dùng thể hiện cho các thuộc tính của các ca sử dụng. Ta sẽ xác định và đặc tả các yếu tố này cho một tác nhân tại một thời điểm xác định bằng cách duyệt qua mọi ca sử dụng mà tác nhân có thể truy nhập và xác định các yếu tố giao diện người dùng tương ứng cho mỗi ca sử dụng.

- Tạo một thiết kế giao diện người dùng thực và làm bản mẫu: Trước tiên, ta chuẩn bị các phác thảo thô của chùm các yếu tố giao diện - người dùng hình thành các giao diện người dùng có ích cho các tác nhân. Sau đó bổ sung các yếu tố cần thiết để tổ hợp hàng yếu tố của giao diện – người dùng thành các giao diện người dùng đầy đủ. Các yếu tố bổ sung này có thể bao gồm các bộ chứa (container) các yếu tố giao diện

Một phần của tài liệu PHÂN TÍCH THIẾT KẾ HỆ THỐNG QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC THEO HƯỚNG ĐỐI TƯỢNG (Trang 29 -29 )

×