Chiến lược tìm vết là một phần rất quan trọng của hướng dẫn tìm vết. Định nghĩa các vết tiềm ẩn và rõ ràng được sử dụng trong dự án. Vết tiềm ẩn thiết lập cấu trúc ánh xạ giữa các mô hình và quan hệ các mục mô hình.
Có 2 phương pháp chiến lược quyết định các yêu cầu phần mềm được tập hợp. 1. Một phương pháp là tất cả các yêu cầu được đưa vào trong chi tiết đặc tả
yêu cầu phần mềm.
2. Cỏch khác được định nghĩa tại 2 vị trí, mô hình use-case và bản đặc tả bổ sung. Phương pháp này bao gồm 4 chiến thuật khác nhau để quản lý kết nối hai phần tử đó và lưu vết giữa chúng.
Bốn chiến thuật như sau:
- Chỉ mô hình Use-case: Chiến thuật này chỉ sử dụng mô hình usecase như trạng thài các yêu cầu hệ thống. Chiến thuật này có thể được chọn cho các dự án có kết cấu đón giữa khách hàng và người phát triển. Dự trờn cỏc mô hình use-case, thuật ngữ, dạng đặc tả bổ sung các trạng thái của các yêu cầu hệ thống. Không có định nghĩa thêm nào về các yêuyeu cầu, đặcđăck tính sản phẩm hay các yêu cầu phần mềm.
- Các đặc tính điều khiển mô hình Use-case: Trong chiếnchíên thuật này, các dạng đặc tả 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 [RUP15].
- Mô hình Use-case là một mô tả của bản đặc tả yêu cầu. Trong trường hợp mô hình Use-Case là một phần mô tả thêm vào trong bản đặc tả yêu cầu. Nó được sử dụng khi bản đặc tả yêu cầu được yêu cầu các mẫu và mô hình UseCase cho phép thực tể của sự phát triển điều khiển use-case. Các đặc tính được tìm vết trong bản đặc tả yêu cầu thông thường và các yêu cầu được tìm vết trong mô hình Use-Case.
- Mô hình use-case tương thích với tập các yêu cầu phần mềm được thêm vào. Mô hình Use-case là sự giải thích của bản đặc tả yêu cầu thông thường từ nhiều nguồn và cung cấp chi tiết của hệ thống đơn. Trong chiến thuật này, mỗi stakeholder đều có tập các đặc tính sản phầm và yêu cầu phên mềm riêng. Những mặt này được kết hợp hài hoà trong mô hình use- case đơn được chi tiết hoá những gì mà hệ thống sẽ làm [Spence & Probasco 1998, p. 6-710]
1.3. Phương thức dò vết yêu cầu trong UML
Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng với mục đích mô hình hoỏ cỏc hệ thống sử dụng các khái niệm hướng đối tượng, thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá, giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau và có thể tạo ra một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy.
Hiện này, UML được dùng chủ yếu trong phát triển phần mềm để phân tích, thiết kế hệ thống phần mềm, chính vì lẽ đó nên việc xây dựng vết yêu cầu phải dựa trên những phương thức dò vết trong UML để đảm bảo tính phù hợp và hữu dụng trong quy trình phát triển phần mềm.
1.3.1. Vết yêu cầu trong UML
Sử dụng bao quát các kết nối giữa mã nguồn và thành phần được gọi là vết dựa trên kịch bản (Scenario-Based Traceability-SBT). Sự thúc đẩy bên dưới sự phát triển dạng vết này được dùng khi người sử dụng vết yêu cầu không tin tưởng vào liên kết nhận được từ công cụ quản lý yêu cầu. Chỉ khi có 30% tỷ lệ lỗi xuất hiện trong các liên kết được trả về từ hệ thống dựa trên hững ngưỡng được đưa ra, nếu người sử dụng không biết 30% lỗi, tập các liên kết trả về ít được sử dụng cho đến khi không có thời gian kiếm tra hết chúng [11Egyed 00]. Để làm tăng độ chính xác của các liên kết nhạn được, chi tiết hoa trong suốt kỹ thuật ảo trì sử hệ thống, vết dựa trên
kịch bản tạo ra thông tin vết dựa trên khả năng suy xét kếtkêt quả của kịch bản kiểm thử được thực thi trong hệ thống.
Có 3 yêu cầu trước tiên để đạt được kỹ thuật này[11Egyed 00]..
Đầu tiên, phải chạy hệ thống để kiểm thử lại. Hệ thống không cần phải hoàn thành, khi những nguyờn mõu và phần nhỏ hoàn thành là được.
Yêu cầu thứ hai là phải có mô hình phần mềm tương ứng với hệ thống như UML.
Cuối cùng là phải cú cỏc trường hợp kiểm thử hay kịch bản được thực thi.
Hình 1-13 1-14: Mô hình vết tổng quan
STB có thể kiểm tra 4 dạng vết khác nhau : • Vết giữa kịch bản và hệ thống
• Vết giữa phần tử mô hình và hệ thống • Vết giữa kịch bản và phần ử mô hình • Vết giữa các phần tử mô hình
Nếu vết sau yêu cầu có thể chắc chắn bởi việc tạo sự phát triển các mẫu thì vết trước cần làm tăng tới các văn bản hay ma trận vết. Các vết này chắc chắn bất cứ thành phần nào của dự án được kiểm tra và phân tích tới giai đoạn trước và sau luôn sẵn sàng. Vết nên chắc chắn rằng các liên kết sau được đưa ra:
- Yêu cầu chức năng và UseCase bởi người phần tích yêu cầu - Use-case và Module bởi nhà kiến trúc và kỹ sư phần mềm - Module và các lớp thiết kế bởi kỹ sư phần mềm
- Các lớp thiết kế và Test_case bởi kỹ sư kiểm thử và thiết kế - Test-case và Use-case bởi kỹ sư kiểm thử
Hướng đi
• Định nghĩa vết đa mô hình. Có khả năng thích ứng và mở rộng thiết lập thông tin vết.
• Thiết lập tích hợp với kỹ thuật UML. UML được sử dụng như vị trí thông thường cỏc cỏc chi tiết kỹ thuật bao gồm các chi tiết kỹ thuật nguyên bản (các yêu cầu, quan hệ, kiểm thử)
Xác định yêu cầu
Yêu cầu khách hàng Yêu cầu kỹ thuật Sản phẩm thiết kế
Kiểm thử chấp nhận Kiểm thử hệ thống
• Thiết lập quy trình dò vết bao gồm quy trình quản lý yêu cầu được coi là một phần của quy trình phát triển phần mềm. s
• Cung cấp công cụ hỗ trợ sử dụng kiến trúc công cụ hỗ trợ CASE hiện tại.
1.4. Kết chương
Như vậy ở chương này đó trỡnh bầy tổng quỏt hoá về quản lý yêu cầu và vết yêu cầu cùng tầm quan trọng của vết yêu cầu trong thiết kế và xây dựng phần mềm. Vết yêu cầu đó gúp một phần không nhỏ trong việc quản lý thay đổi và đón đến thành công của hệ thống.
Vấn đề đặt ra:
- Cần có những hướng dẫn các dạng thông tin phải được đưa ra và được sử dụng trong ngữ cảnh nào. Giải thích điều kiện và khả năng liên vết giữa các thành phần hệ thống tới người sử dụng
- Cần có kiến trúc mở rộng để cho phép kiểm tra quan hệ tập hợp và tổng quát hoá trong nhiệm vụ tìm vết.
- Cần dịch vụ hỗ trợ ngữ cảnh của các dạng liên kết vết khác nhau.
- Sự cần thiết các kiến trúc cho phép quản lý dự án và người phát triển định nghĩa và đưa ra một quy trình vết điều khiển mô hình kèm theo quy trình phát triển
- Hầu hết các công cụ hỗ trợ đều làm việc theo hướng văn bản mà không tích hợp với các module trong ngữ cảnh công cụ CASE.
Từ những vấn đề đặt ra bên trên trong quy trình đưa ra vết yêu cầu dẫn tới những nhiệm vụ cần thực hiện như sau:
- Tìm hiểu về các phương pháp quản lý yêu cầu phần mềm và vết yêu cầu phần mềm
- Lựa chọn công cụ phù hợp
- Quản lý yêu cầu, quản lý vết và quản lý kiến trúc yêu cầu - Xây dựng ứng dụng và thử nghiệm
CÔNG CỤ ENTERPRISE ARCHITECTURE 7.0
Enterprise Architecture (EA) là một sản phẩm của Sparx Systems-Nhật Bản. Đây là công cụ kỹ thuật phần mềm trợ giúp máy tính (CASE ) dùng cho thiết kế và xây dựng hệ thống phần mềm. EA dựa trên đặc tả UML 2.1-ngôn ngữ ảo cho phép sử dụng để mô hình hoá lĩnh vực hay hệ thống riêng biệt (kể cả đang tồn tại và được đưa ra).
EA là một công cụ tiên tiến hỗ trợ tất cả các mặt của chu trình phát triển, cung cấp đầy đủ thông tin vết từ giai đoạn thiết kế ban đầu thông qua triển khai và bảo trì. Công cụ này luôn hỗ trợ kiểm thử và quản lý thay đổi. Với hơn 100 000 giải pháp, EA được phổ biến trên diện rộng và được sử dụng bởi hàng ngàn công ty lớn nhỏ khác nhau từ các tổ chức đa quốc gia... tới cỏc cụng ty co phụ thuộc, EA trở thành công cụ mô hình hoá cho sự lựa chọn cho người phát triển, xây dựng và phân tích ở trên 60 quốc gia khác nhau.
1.5. Khái niệm
EA là một công cụ kĩ thuật phần mềm trợ giúp máy tính dùng cho thiết kế và xây dựng hệ thống phần mềm, trong các mô hình tiến trình và các yêu cầu mô hình hoá. EA dựa trên UML 2.1-ngôn ngữ ảo dùng để mô hình lĩnh vực hay hệ thống. (đang tồn tại hay được yêu cầu).
EA có 3 bản khác nhau : Corporate, Professional, DdesktopDestop. Các bản EA khác nhau có chức năng khác nhau được miêu tả trong bảng sau:
Chức năng Bản Corporate Bản Professional Bản Desktop
Các tệp .EAP Có Có Có
Mô hình được chia sẻ
Có Có Không
Kỹ thuật mã nguồn Có Có Không
Kỹ thuật CSDL Có Có Không
Tương tác với Microsoft Access
Có Có Có
Tương tác với Có Không Không
Điều khiển phiên bản
Có Có Có
Bản sao Có Có Không
Kỹ thuật MDG Có Có Không
Chương này gồm những nội dung chính sau:
Giới thiệu tổng quản về công cụ EA Thấy được quản lý yêu cầu trong EA Ưu/nhược điểm của công cụ EA
Kỹ thuậttuật MDG Link cho Elipse và MDG Link cho Visual Studio .Net
Có Có Không
Bảo mật Có Không Không
Thẩm tra Có Không Không
Bảng 2-6: Bảng phân tích chức năng của các bản
Đặc trưng Quản lý