j. Mô hình hoá CSDL
1.9.1.Chiến thuật đưa ra vết yêu cầu
Như đã nói ở trên, tồn tại 4 chiến thuật khác nhau để đưa ra vết yêu cầu. Từ thực tế, chúng ta có sử dụng công cụ EA làm phân tích và thiết kế hệ thống và hiện nay, quy trình phát triển phần mềm RUP đang được phát triển rộng rói nên chiến thuật thứ 2-Các đặc tính điều khiển mô hình Use-case sẽ là chiếng thuật đưa ra vết có đặc tính tốt nhất.
Trong chiến thuật này, các dạng đặc tả thành các mô hình một phần mềm hoàn chỉnh.Cỏc đặc tính được tạo văn bản trong văn bản mục tiêu và được tạo vết tới các đặc tả chi tiết khác hoặc các use-case. Chiến thuật này được sửsủ dụng trong quy trình Rational Unified Process (RUP).
Theo quy trình RUP, việc phân tích và thiết kế được tổ chức thành các mô hình theo sơ đồ sau:
Chương này gồm những nội dung chính sau:
√ Đưa ra phương pháp quản lý vết yêu cầu cần áp dụng dựa trên công cụ EA
√ Xác định được quy trình tìm vết
Hình 3-19 3-20: Mô hình phân tích thiết kế theo quy trình RUP
• Mô hình giao dịch
Mô hình miêu tả cả hành vi và luồng thông tin trong một tổ chức hay hệ thống. Giống như mô hình của hành động doanh nghiệp, nó giữ lại các sự kiện, đầu vào, tài nguyên, quy trình và đầu ra với các quá trình doanh nghiệp liên quan.
Quy trình giao dịch có mục đích, đầu vào, các tài nguyên được sử dụng, hành động được thực hiện trong một số trình tự, ảnh hưởng nhiều tới đơn vị tổ chức, giá trị của một vài dạng cho khách hàng. Khách hàng có thể bên trong hay bên ngoài.
• Mô hình phân tích Uusecase
Mô hình phõn tích usecase là tập các hành động được thiết kế để đưa ra các đầu ra cho khách hàng. Tập trung vào cách công việc được tiến hành trong tổ chức, trái ngược với việc nhận mạnh vào sản phẩm là gì?
Do đó một quy trình xắp xếp các công việc đặc biệt thông qua thời gian và địa điểm trong đó với bắt đầu và kết thúc và các đầu ra, đầu vào được định nghĩa rõ ràng; một chuỗi các hành động.
• Mô hình Use Case
Mô hình Use Case miêu tả chức năng nhóm của các Use Case. Mỗi Use Case miêu tả một tương tác đơn mà người sử dụng hay các “actor” mở rộng khi sử dụng hệ thống, nhấn mạnh viễn cảnh của hệ thống và các mối tương tác.
Sự miêu tả Use Case bao gồm
1. Chú thích và ghi chép thông thườngthưòng miêu tả use case;
2. Các yêu cầu, nhữngcầunhững thứ mà use case phải cho phép người sử dụng làm.
3. Ràng buộc-quy tắc về những gì có thể hay không thể làm
4. Tình huống-sự miêu tả tuần tự của các bước được đem ra. Cáo thể bao gồm nhiều tình huống để phục vụ cho trường hợp ngoại lệ và các đường quy trình luân phiên.
5. Sơ đồ tình huống-sơ đồ quân tự để miêumieu tả luồng công việc.
6. Các thuộc tính thêm như pha thực hiện, số phiên bản, tốc độ phức tạp, trạng thái và mẫu
Ánh xạ điều khiến
RUP định nghĩa hành vi thiết kế giao tiếp người dùng là kết quả nằm trong ánh xạ điều khiển. Sự ánh xạ này cơ bản dựa trên các trườngtruờng hợp sử dụng và hiển thị đường dẫn điều khiển quan trọng nhật. Một đường dẫn điều khiển quan trọng là luồng tuần tự của màn hình (cửa sổ, trạng web) đi qua. Vậy sự ánh xạc này như thế nào?
• Mô hình phân tích
Mô hình phân tích và mô hình thiết kế cùng nhau biểu lộ bên trong hệ thống để nhận ra các trường hợp sử dụng. Mô hình phân tích khái quát ở mức cao hơn mô hình thiết kế. Các đối tượng trong mô hình phân tích vẫn là những “lo- gic”(“logical”) trong tự nhiên trong khi các phân tử của mô hình thiết kế được nhận ra trực tiếp trong mã nguồn. RUP cho phép chúng ta đi từ các trường hợp sử dụng tới mô hình thiết kế nhưng nếu bước này quá lớn, chúng ta có thể thiết lập một mô hình phân tích bước đầu. Nên quyết định trong dự án bất cứ khi nào mô hình phân tích thay thế bởi mô hình thiết kế và duy trì như khái niệm tổng quan của mô hình thiết kếlế. Cả mô hình hõn tớch và thiết kế đều chửa biểu đồ lớp để đưa ra cấu trúc tính và các biểu đồ tương tác hiển thị sự nhận biết các trường hợp sử dụng trong các mục của các đối tượng cộng tác.
Mô hình thiết kế
Một trong 6 thực tế quan trọng nhất của RUP là sử dụng kiến trúc thànhthanhd phần. Để nhấn mạnh hơn về mô hình thiết kế, ta chia môo hình này thành 2 mức: Mức kiến trúc ( các thành phần được đưa ra từ hộp đen) và mức chi tiết các thành phần: bên trong mỗi thành phần được thiết kế.
Ở cả 2 mức này, kiến trúc tĩnh là cơ bản nằm trên hành đi động đương mô hình hoá.
1. Lớp kiến trúc:
Kiến trúc tính được đưa ra bởi 2 biểu đồ: (adsbygoogle = window.adsbygoogle || []).push({});
- Biểu đồ gói và biểu đồ thành phần. Kiến trúc phần mềm sẽ làm sáng rõ các biểu đồ này trong văn bản kiến trúc phần mềm
- Phần động của kiến trúc xem xét sự nhận ra các use-case. Nó đưa ra một biểu đồ tương tác cho môi use-case. Biểu đồ tương tác sẽ nằẳm ở mức thành phần.
2. Mức chi tiết các thành phần
Ở mức này, mô hình hoá mỗi thành phần từ các giao tiếp và tương tác với mỗi thành phần được định nghĩa trong lớp kiến trúc. Phần tĩnh là các biểu đồ lớp sẽ được lập trình để thực thi các thành phần. Phần động là tập sự nhận ra quá trình thành phần.
• Mô hình dữ liệu
Mô hình dữ liệu là mô hình CSDL. Mô hình dữ liệu chi tiết các bảng, cột và quan hệ khoá ngoại hay như các thủ tục và trigger. Các phõn tử này đặt trong biểu đồ lớp sử dụng các dạng đặc biệt như ôtableằ và ôcolumnằ. Khi sử dụng đa CSDL, mỗi CSDL nên được hiển thị như một thành phần trong mô hình thiết kế. Đôi khi, mô hình dữ liệu được chia thành các gói.
• Mô hình triển khai
Hô hình triển khai chi tiết phần cứng và phần mềm hay các kết nối mạng càn cần thiếthtiết cho phần mềm, trong các khung cơ sở này, ta có xác định các thành phần cho các máy mócmay mọc nên được cài đặt. Biểu đồ triển khai của UML có tớnh chấtchât hiển thị mô hình này.
•Mô hình thực thi
Mô hình này chỉ cần khi tổ chức mã nguồn vật lý đưa ra từ các gói và cấu trúc thành phần định nghĩa trong mô hình tiết kế. Trong trường hợp này, mô hình thực thi chi tiết hoá cấu trúc mã nguồn và đưa ra sự kết hợp. Nếu muốn mô tả điều này, ta sử dụng biểu đồ gói. Các mối quan hệ giữa các gói và các thành phần trong biểu đồ thiết kế nên rừ ràng.
Các đặc tính điều khiển mô hình use-case được giới thiệu mặc định bởi RUP và thông tin vết của nó được định nghĩa như hình sau:
Hình 3-21 3-22: Kỹ thuật yêu cầu