Hình 3-27 3-28 Mô phỏng mô hình yêu cầu trong EA
Mô hình yêu cầu là chuỗi các yêu cầu của người sử dụng cuối và các mối quan hệ giữa chúng.
Hình 3-29 3-30: Mô phỏng thông tin vết đặc tả yêu cầu
Mô hình yêu cầu là sản phẩm công việc của quy trình thu thập và quy trình khái quát hệ thống. Mô hình yêu cầu trong EA cho phép chúng ta tổ chức các yêu cầu thành các biểu đồ.
Trong EA, có 2 loại yêu cầu:
- Yêu cầu mở rụng-yờu cầu được mô hình hoá như các thành phần riêng của nó
- Yêu cầu bên trong-một yêu cầu được mô hình như nhiệm vụ của thành phần đang tồn tại.
Sử dụng biểu đồ custom diagram, EA cho phép mô hình hoỏ cỏc yêu cầu với đầy đủ thông tin vết liên quan giữa các yêu cầu với nhau và các thông tin thuộc tính của từng phần tử như: mô tả nhắn gọn, các chú ý, trạng thái, nằm trong giai đoạn nào, tác giả, ngày tạo, ngày cuối cùng cập nhật, pha, phiên bản...
Hai mô hình phân tích và thiết kế nằm trong quy trình thiết kế và thực thi. Mô hình này cho phép người sử dụng có thể tạo ra các biểu đồ Use-Case, các biểu đồ lớp.... Trong quy trình dò vết, mô hình này cung cấp thông tin liên quan giữa các yêu cầu được nhận ra bởi các use-case và các use-case được nhận ra bởi các lớp trong các mô hình được đưa ra vết nhờ ma trận vết yêu cầu.
1. Mô hình phân tích
Đặc tả tổng quan các Use Case. Mô hình này sử dụng các Use-Case để đặc 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.
Hình 3-31 3-32: Mô hình đặc tả usecase
Sử dụng ma trận vết, ta có thể đưa ra vết giữa yêu cầu tới các Use-case và thông tin về các Use-Case
Hình 3-33 3-34: Mô phỏng thông tin vết yêu cầu-use case được đưa ra
2. Mô hình thiết kế
Mô hình thiết kế là mô hình tổng quan đưa ra từ người thiết kế bao gồm 3 mô hình nhỏ: Mô hình đặc tả chi tiết usecase, mô hình lớp, mô hình CSDL • Mô hình đặc tả chi tiết từng use-case
Đặc tả cụ thể từng Use-case sử dụng các biểu đồ tuần tự, máy trạng thái, thời gian...để chi tiết hoạ cụ thể từng luồng thông tin và đối tượng trong từng Use-Case
Hình 3-35 3-36 Mô phỏng mô hình usecase trong EA
• Mô hình lớp
Mô hình lớp là mô hình logic chặt chẽ của hệ thống phần mềm. Các lớp thường có mốimổi quan hệ trực tiếp tới mã nguồn hay các phần mềm khác có thể được gom nhóm lại vào trong các thành phần có thực hiện được.
Hình 3-37 3-38 Đặc tả mô hình lớp trong EA
• Mô hình Database
Mô hình Database miêu tả dữ liệu phải được lưu trữ và nhận như một phần của thiết kế hệ thống tổng quan. Điều này có nghĩa các mô hình Database liên quan miêu tả thành các bảng và dữ liệu trong các chi tiết và sự phát sinh có thể của kịch bản DLL để tạo và cài đặt Database
Hình 3-39 3-40 Đặc tả mô hình kiểm thử trong EA
Sử dụng ma trận vết, ta có thể đưa ra vết giữa yêu cầu tới các Use-case và thông tin về các Use-Case
Trong mô hình này, thông tin vết tập trung vào quan hệ giữa các use-case và các lớp được thực thi tương ứng. Sử dụng ma trận vết trong EA, ta có thể dễ dàng đưa ra thông tin vết từ các Use-Case tới các lớp tương ứng.
Hình 3-41 3-42: Mô phỏng thông tin vết Use-case-Class
c. Mô hình kiểm thử
Mô hình test miêu tả và duy trì các danh sách test, kế hoạch test và kếtkêt quả thực thi mô hình hiện tại. Ứng với từng phần tử, EA cho phép thiết lập từng test- suite tương ứng với các thông tin về trạng thái, người thực thi, tên...
Hình 3-43 3-44 Mô phỏng mô hình kiểm thử trong EA
Thông tin vết tới các Test case được thực hiện thông qua khung nhìn Testing cho phép thiết lập các test-suite ứng với từng phần tử trong các biểu đồ (adsbygoogle = window.adsbygoogle || []).push({});
Hình 3-45 3-46: Mô phỏng thông tin yêu cầu-Test và Class-test
Những mô hình này luôn gắn liền với từng quy trình nhỏ trong quy trình tổng thể thiết kế và xây dựng hệ thống phần mềm.
1.11. Kiến trúc vết yêu cầu trong EA
EA cho phép hiện kiến trúc vết các yêu cầu theo cấu trúc cây với nút gốc là yêu cầu cần đưa ra thông tin vết và các liên kết được đưa ra.
Hình 3-47 3-48:Kiến trúc vết hiển thị trong EA
1.12. Kết chương
Như vậy, trong chương này chúng ta đã làm rõ được sự hỗ trợ của công cụ EA trong vấn đề lưu vết yêu cầu. Đồng thời cũng chỉ ra việc lưu vết yêu cầu trong công cụ EA. Việc lưu vết này tuân theo từng quy trình nhỏ được thể hiển ở từng phần tử trong từng mô hình ở các giai đoạn khác nhau.
Tuy nhiên cũng có một số vấn đề về khiếm khuyết trong việc đưa ra vết yêu cầu trong công cụ này càn cần khắc phục và làm toàn vẹn hơn tính năng lưu vết yêu cầu của công cụ nhằm hỗ trợ cho việc quản lý thay đổi tạo nền tảng cho việc xây dựng hệ thống phầàn mềm thành công.
XÂY DỰNG ỨNG DỤNG VÀ THỬ NGHIỆM
1.13. Ý tưởng
Chương 3 đã nói tới việc chiến thuật được áp dụng và việc đưa ra thông tin vết theo quy trình gắn liến với các mô hình sử dụng EA làm công cụ CASE thực hiện.
Việc xuất hiện lỗi trong quá trình lưu vết của EA và yêu cầu đưa ra được thông tin vết một cách chính xác và toàn vẹn nhất thành những bản báo cáo đã tạo tiền đề để đưa ra ứng dụng này. Thông tin đưa ra sẽ được tổ chức dưới dạng thẻ trong file .xml hoặc dạng bảng trong file Word.
Từ mô hình yêu cầu trong EA, ứng dụng sẽ phải đưa ra được thông tin đặc tả về các yêu cầu của phần mềm có trong mô hình bao gồm các thông tin như ID, Name, Related Requirement, Date, Created by, Note. Quy tắc xây dựng ID trong ứng dụng là sử dụng chữ viết tắt gắn liền tới ID mà EA cung cấp cho từng phần tử trong dự án.
- US:UseCase - Cl: Class - UT: Unit Test - ST: System Test - IT: Intergration Test - AT: Acceptance Test - ScT: Scenorio Test
Thông tin đưa ra được tổ chức thành dạng bảng trong file Word như sau:
ID Name Related
Requirement Date byCreated Note
Bảng 4-7: Bảng đặc tả yêu cầu
Từ mô hình phân tích và thiết kế sẽ đưa ra thông tin vết giữa cỏc yờu cầu-usecase và từ các usecase tới các lớp. Thông tin vết giữa các yêu cầu tới các lớp là thông tin gián tiếp thông qua use-case.
Bảng thông tin vết được cập nhật thêm thông tin về các usecase và lớp tương ứng có quan hệ tới các use-case được đưa ra như sau
:
ID Name Use-case Class
Chương này gồm những nội dung chính sau:
√ Đưa ra ý tưởng về ứng dụng √ Thiết kế chương trình
√ Xây dựng mô hình thử nghiệm √ Kết quả đạt được
Bảng 4-8: Bảng thông tin vết khi có Class và Use-Case
ID Name Description Note
Bảng 4-9: Bảng thông tin vềvể Use-Case
ID Name Use-case Class
Bảng 4-10: Bảng thông tin vết khi có Use-Case và Class (adsbygoogle = window.adsbygoogle || []).push({});
ID Name Description Note
Bảng 4-11: Bảng thông tin vềvể Class
Từ mô hình kiểm thử bảng thông tin vết sẽ được cập nhật thêm trường test-suite đồng thời đưa ra được trạng thái của yêu cầu ở thời điểm hiện tại.
Các trạng thái bao gồm: đã kiểm thử qua hết-pass, bị lỗi-failt, chưa xác định- N/A(Trạng thái của được phân tích thiết kế đầy đủ), chưa chạy: Not-Run:Trạng thái của được tiến hành kiểm thử đầy đủ các test-suite...
ID Name Use-Case Class Test-Suite Status
Bảng 4-12: Mô phỏng thông tin vết yêu cầu-testcript
ID Description Status Note
Bảng 4-13: Bảng thông tin vết đưa ra khi có Test-Suite tương ứng
Ngoài thông tin vết ra, ứng dụng sẽ đưa ra một số tỷ lệ thực hiện các yêu cầu như: bao nhiêu yêu cầu được đưa ra, bao nhiêu yêu cầu đã qua và tỷ lệ...
Để cụ thể hoá mức độ hoàn thành dự án, thông tin vết cần kèm theo mức độ đánh giá về tiến độ hoàn thành. Trạng thái cụ thể của từng yêu cầu đang ở trong giai đoạn nào từ việc thống kê dựa trên toàn bộ yêu cầu phần mềm được đưa ra và thông tin về các vết kèm theo với nó.
Ứng dụng sẽ không chỉ hỗ trợ EA loại bỏ những thông tin vết không theo đúng chuẩn UML mà còn đưa ra thành các báo cáo với đầyày đủ các nội dung cần thiết và các mức độ đánh giá về tiến độ hoàn thành dự án.
• Đầu vào là thông tin được đưa ra từ các mô hình có trong EA • Có khả năng tìm kiếm tất cả các phần tử được yêu cầu
• Đọc và đưa ra thông tin cụ thể từng phần tử trong mô hình • Đưa ra thông tin thành file Word hoặc xml
• Đưa ra được những đánh giá và tỷ lệ thực hiện chính xác
1.14.2. Kiến trúc hệ thống
Hình 4-49 4-50: Mô phỏng kiến trúc hệ thống
• GUI & Controller: Đảm nhiệm các công việc về hiển thị, giao tiếp với
người dùng và điều khiển các khối khác.
• Intergrate EA: Đảm nhiệm công việc tương tác vào EA, lấy ra các thông
tin cần thiết.
• Solve Connector: Đảm nhiệm công việc xoá bỏ những kết nối không
theo chuẩn UML và sai khác với quy tắc lưu vết trong quy trình đưa ra. • Create Report: Đảm nhiệm công việc đưa ra báo cáo dưới dạng Word
hoặc XML.
1.14.3. Thiết kế chức năng
a. Lấy thông tin
Hình 4-51 4-52: Mô phỏng chức năng lấy thông tin
Chương trình sẽ thực hiện tuần tự theo các bước sau đây: 1. Tương tác với EA để lấy ra thông tin
2. Thông tin được sử lý trong khối SolveConnector 3. Thông tin sai sẽ bị xoá bỏ
4. Thông tin đúng được lưu vào trong ListView để đưa ra dưới dạng báo cáo
b. Báo cáo (adsbygoogle = window.adsbygoogle || []).push({});
Hình 4-53 4-54: Mô tả chức năng báo cáo
Chương trình sẽ thực hiện tuần tự theo các bước sau đây: 1. Lấy thông tin từ khối SovleConnector
2. Đưa thông tin ra cho khối CreateReport
3. Khối CreateReport xử lý dữ liệu và cho phép lựa chọn loại báo cáo và nội dung đưa ra trong báo cáo
4. CreateReport tạo và lưu báo cáo lại
1.14.4. Thiết kế chi tiết
Dựa trên thiết kế cơ bản, và thiết kế chức năng, thiết kế chi tiết cần có một số chức năng chi tiết sau đây:
STT Tên chức năng chi tiết Ý nghĩa
1 Tích hợp với EA Tích hợp ứng dụng vào thành một chức năng trong EA
2 Tìm kiếm yêu cầu
Duyệt tất cả các mô hình và biểu đồ để lấy ra các yêu cầu
3 thái yêu cầuĐưa ra trạng Thiết lập trạng thái yêu cầu dựa trên thông tin đã có được 4 Xử lý kết nối Lấy ra các liên kết tương ứng với từng yêu cầu và kiểmkiểm tra đúng sai 5 Lập báo cáo Cho phép thiết lập một số thông tin về báo cáo
đưa ra
6 Help Mở file trợ giúp người dùng về chương trình sử dụng
Bảng 4-14: Bảng chức năng chi tiết của ứng dụng
Hình 4-55 4-56:: Chức năng tích hợp EA
Chương trình thực hiện tuần tự theo các bước sau đây:
• Kết nốinôí với EA nhằm tích hợp trực tiếp ứng dụng và lấyây thông tin từ các mô hình trong EA
• Tạo menu và submenu trên thanh menu của EA • Xử lý sự kiện khitrong nhấn vào menu
b. Tỡm kiếm yêu cầu
Hình 4-57 4-58: Chức năng tìm kiếm yêu cầu
Chương trình thực hiện tuần tự theo các bước sau đây: • Truy cập vào kho của dự án
• Duyệt tất cả các mô hình, nếu là các package thì cho vào Stack, gặp các phần tử thì kiểm tra xem phải là yêu cầu không, nếu có sẽ lấy ra thông tin, không phải thì bỏ qua và xoá bỏ.
• Đưa thông tin về yêu cầu vào trong Listview
Hình 4-59 4-60: Chức năng đưa ra trạng thái yêu cầu
Chương trình thực hiện tuần tự theo các bước sau đây: • Xác định các yêu cầu tìm được
• Lấy thông tin các yêu cầu
• Tìm kiếm các kết nối tới các phần tử khác
• Lấy các kết nối và thông tin về các phần tử trong kết nối với yêu cầu đó • Đưa ra trạng thái yêu cầu
d. Xử lý kết nối (adsbygoogle = window.adsbygoogle || []).push({});
Hình 4-61 4-62: Chức năng xử lý kết nối
Chương trình thực hiện tuần tự theo các bước sau đây: • Đưa ra các kết nối tìm được
• Kiểm tra xem phần tử này đã kết nối với nhau hay chưa • Xử lý các kết nối sai, không đúng hoặc đã tồn tại
Hình 4-63 4-64: Chức năng lập báo cáo
Chương trình thực hiện tuần tự theo các bước sau đây: • Ấn nút tạo báo cáo
• Thiết lập một số thông số về báo cáo
• Chọn lựa loại báo cáo đưa ra (Word hoặc XML). Mặc đinh là Word
• Sau khi tạo báo cáo có thể xem lại báo cáo trực tiếp bằng việc nhấn nút View trên Form
f. Chức năng trợ giúp
Hình 4-65: Chức năng trợ giúp
Chương trình thực hiện tuần tự theo các bước sau đây: • Ấn nút Help trên giao diện chính
• Mở file help.text
1.14.5. Giao diện chương trình
Hình 4-66 4-67: Giao diện sử dụng chính
Hình 4-68 4-69: Giao diện cho phép thiết lập chọn lưa báo cáo đưa ra
1.15. Mô hình DMS
1.15.1. Giới thiệu
a. Hệ thống quản lý tài liệu được xây dựng nhằm mục đích:
Tổ chức lưu trữ các tài liệu điện tử cho các doanh nghiệp, cơ quan nghiên cứu, trường học. Giải pháp “ Nghiên cứu – Đào tạo – Hỗ trợ phát triển Nhân lực”, DMS (Document Manage System) giúp quản lý và chuẩn bị nội dung cho việc nghiên cứu, tổ chức sách và tài liệu điện tử cho đào tạo và các hệ thống khác
b. Mô tả
Như đã trình bày ở trên, DMS phục vụ việc tổ chức lưu trữ tài liệu điện tử cho các doanh nghiệp, cơ quan nghiên cứu, trường học…, mỗi đơn vị có khái niệm “tài liệu” riêng. Với cơ quan nghiên cứu đó là các tài liệu khoa học, công văn giấy tờ, với trường học tài liệu lại có thể là các bài giảng…. Vì vậy, việc áp dụng DMS có thể khác nhau về loại dữ liệu cần lưu trữ giữa các cơ quan, đơn vị nhưng tựu chung lại đều là quản lý tài liệu. Áp dụng DMS vào giải pháp “ Nghiên cứu – Đào tạo –
Hỗ trợ phát triển Nhân lực”, DMS giúp quản lý và chuẩn bị nội dung cho việc
nghiên cứu, tổ chức sách và tài liệu điện tử cho đào tạo và các hệ thống khác, vì vậy hệ thống có 3 loại người dựng chớnh: Quản trị hệ thống, quản lý mã nguồn, quản lý sách.
Hình 4-70 4-71: Mô phỏng phân lớp người sử dụng trong hệ thống DMS
1.15.2. Phõn tích thiết kế
a. Mô hình quy trình giao dịch
Hình 4-72 4-73: Biểu đồ giao dịch
1.Mô hình lĩnh vực
Đưa ra những khái niệm về nghiệp vụ và lĩnh vực của hệ thống Người sử dụng
Hình 4-74 4-75: Biểu đồ domain (adsbygoogle = window.adsbygoogle || []).push({});