1. Sự cố phần mềm
3.4.4 Phát triển các trường hợp sử dụng
- Điều kiện hư hỏng. Khi kịch bản thành công được liệt kê, tất cả các điều kiện thất bại có thể được xác định. Ở cấp độ này, đối với mỗi bước trong kịch bản thành công chính, các cách khác nhau mà một bước có thể thất bại hình thành các điều kiện thất bại. Trước khi quyết định điều gì nên được thực hiện trong các điều kiện lỗi này (được thực hiện ở cấp độ tiếp theo), tốt hơn hết là liệt kê các điều kiện lỗi và xem xét tính đầy đủ.
– Diễn viên và mục tiêu. Danh sách diễn viên-mục tiêu liệt kê các trường hợp sử dụng và chỉ định các diễn viên cho từng mục tiêu. (Tên của trường hợp sử dụng thường là mục tiêu.)
- Xử lý sự cố. Đây có lẽ là phần phức tạp và khó khăn nhất khi viết ca sử dụng. Thông thường, người ta tập trung quá nhiều vào chức năng chính mà mọi người không chú ý đến cách xử lý lỗi. Việc xác định hành vi nên là gì trong các điều kiện lỗi khác nhau thường sẽ
Các cấp độ khác nhau có thể được sử dụng cho các mục đích khác nhau. Để thảo luận về chức năng hoặc khả năng tổng thể của hệ thống, các tác nhân và mô tả mức mục tiêu là rất hữu ích. Mặt khác, các điều kiện lỗi rất hữu ích để hiểu và trích xuất các yêu cầu chi tiết và quy tắc kinh doanh trong các trường hợp đặc biệt.
Bảng này có thể được mở rộng bằng cách đưa ra một mô tả ngắn gọn về từng trường hợp sử dụng. Ở cấp độ này, các trường hợp sử dụng cùng xác định phạm vi của hệ thống và đưa ra một cái nhìn tổng thể về những gì nó làm. Tính đầy đủ của chức năng có thể được đánh giá khá tốt bằng cách xem xét những điều này.
xác định các quy tắc kinh doanh mới hoặc tác nhân mới.
UC không chỉ ghi lại các yêu cầu, vì hình thức của chúng giống như kể chuyện và sử dụng văn bản, cả hai đều dễ dàng và tự nhiên với các bên liên quan khác nhau, chúng còn là một phương tiện tốt để thảo luận và động não. Do đó, UC cũng có thể được sử dụng để khơi gợi yêu cầu và phân tích vấn đề. Trong khi phát triển các trường hợp sử dụng, các mô hình chính thức hoặc không chính thức cũng có thể được xây dựng, mặc dù chúng không bắt buộc.
– Kịch bản thành công chính. Đối với mỗi trường hợp sử dụng, kịch bản thành công chính ios được cung cấp ở cấp độ này. Với các kịch bản chính, hành vi hệ thống cho từng trường hợp sử dụng được chỉ định. Mô tả này có thể được xem xét để đảm bảo rằng lợi ích của tất cả các bên liên quan được đáp ứng và trường hợp sử dụng đang mang lại hành vi mong muốn.
UC có thể được phát triển theo cách sàng lọc từng bước với mỗi bước bổ sung thêm chi tiết. Cách tiếp cận này cho phép các UC được trình bày ở các mức độ khác nhau của ab straction. Mặc dù có thể có bất kỳ mức độ trừu tượng nào, bốn mức độ tự nhiên xuất hiện:
3.4 Đặc tả chức năng với các trường hợp sử dụng 57
có được các chi tiết của các kịch bản. Rất thường xuyên, khi quyết định các kịch bản thất bại, nhiều quy tắc kinh doanh mới về cách đối phó với các kịch bản này được phát hiện.
Bước 2. Hiểu và chỉ định kịch bản thành công chính cho từng UC, đưa ra chi tiết hơn về các chức năng chính của hệ thống. Tương tác và thảo luận là phương tiện chính để khám phá những kịch bản này mặc dù các mô hình có thể được xây dựng nếu cần. Trong bước này, nhà phân tích có thể phát hiện ra rằng để hoàn thành một số trường hợp sử dụng, một số trường hợp sử dụng khác là cần thiết chưa được xác định. Trong trường hợp này, danh sách các trường hợp sử dụng sẽ được mở rộng.
Mặc dù chúng tôi đã giải thích các bước cơ bản trong việc phát triển các trường hợp sử dụng, nhưng ở bất kỳ bước nào, nhà phân tích có thể phải quay lại các bước trước đó vì trong một số phân tích chi tiết, các tác nhân mới có thể xuất hiện hoặc các mục tiêu mới và trường hợp sử dụng mới có thể chưa được đề cập. Nghĩa là, sử dụng các trường hợp sử dụng để phân tích cũng là một nhiệm vụ tương tác.
Bốn cấp độ này cũng có thể hướng dẫn hoạt động phân tích. Ứng dụng từng bước
một câu hỏi như thế này; câu trả lời thực tế luôn phụ thuộc vào dự án và tình huống. Vì vậy, đó là với các trường hợp sử dụng. Nói chung, thật tốt khi có đủ thông tin chi tiết không quá choáng ngợp nhưng đủ để xây dựng hệ thống và đáp ứng các mục tiêu chất lượng của hệ thống. Ví dụ: nếu có một nhóm nhỏ được hợp tác xây dựng hệ thống, rất có thể các trường hợp sử dụng liệt kê các điều kiện ngoại lệ chính và đưa ra một số bước chính cho các tình huống là đủ. Mặt khác, đối với một dự án mà sự phát triển của nó sẽ được ký hợp đồng phụ với một số tổ chức khác, tốt hơn là nên có các trường hợp sử dụng chi tiết hơn.
Bước 3. Khi kịch bản thành công chính cho một trường hợp sử dụng được thống nhất và các bước chính trong quá trình thực hiện nó được chỉ định, thì có thể kiểm tra các điều kiện không thành công.
Liệt kê các điều kiện lỗi là một phương pháp tuyệt vời để phát hiện các tình huống đặc biệt có thể xảy ra và hệ thống phải xử lý.
Mức độ chi tiết trong một trường hợp sử dụng là gì? Không có câu trả lời nào cho
Để viết các trường hợp sử dụng, các quy tắc viết kỹ thuật chung sẽ được áp dụng. Sử dụng ngữ pháp đơn giản, chỉ định rõ ràng ai đang thực hiện bước này và giữ cho kịch bản tổng thể càng đơn giản càng tốt. Ngoài ra, khi viết các bước, để đơn giản, tốt hơn là
phương pháp phân tích khi sử dụng các trường hợp sử dụng là:
Bước 4. Cuối cùng, chỉ định những gì nên được thực hiện đối với các tình trạng lỗi này. Vì chi tiết xử lý các tình huống lỗi có thể đòi hỏi nhiều nỗ lực và thảo luận, tốt hơn hết là liệt kê các điều kiện lỗi khác nhau và sau đó
Bước 1. Xác định các bên liên quan và mục tiêu của họ và đạt được thỏa thuận với các bên liên quan về mục tiêu. Danh sách tác nhân-mục tiêu sẽ xác định rõ ràng phạm vi của hệ thống và sẽ cung cấp một cái nhìn tổng thể về khả năng của hệ thống.
Nguyên tắc cơ bản được sử dụng trong phân tích cũng giống như trong bất kỳ nhiệm vụ phức tạp nào: chia để trị. Đó là, phân chia bài toán thành các bài toán con và sau đó cố gắng hiểu từng bài toán con và mối quan hệ của nó với các bài toán con khác nhằm nỗ lực hiểu bài toán tổng thể.
Các khái niệm về trạng thái và phép chiếu đôi khi cũng có thể được sử dụng hiệu quả trong quá trình phân vùng. Một trạng thái của một hệ thống đại diện cho một số điều kiện về hệ thống. Thông thường, khi sử dụng trạng thái, trước tiên hệ thống được xem là đang hoạt động ở một trong số các trạng thái có thể có, sau đó phân tích chi tiết được thực hiện cho từng trạng thái. Cách tiếp cận này đôi khi được sử dụng trong phần mềm thời gian thực hoặc phần mềm điều khiển quy trình.
Trong phép chiếu, một hệ thống được xác định từ nhiều quan điểm [86]. Trong khi sử dụng phép chiếu, các quan điểm khác nhau của hệ thống được xác định và sau đó hệ thống được phân tích từ những quan điểm khác nhau này. Các "dự đoán" khác nhau thu được được kết hợp để tạo thành phân tích cho toàn bộ hệ thống. Việc phân tích hệ thống từ các quan điểm khác nhau thường dễ dàng hơn, vì nó giới hạn và tập trung vào phạm vi nghiên cứu.
Mục đích cơ bản của phân tích vấn đề là để có được sự hiểu biết rõ ràng về nhu cầu của khách hàng và người dùng, chính xác những gì được mong muốn từ phần mềm và những hạn chế đối với giải pháp là gì. Thường thì khách hàng và người dùng không hiểu hoặc biết tất cả các nhu cầu của họ, bởi vì tiềm năng của hệ thống mới thường không được đánh giá đầy đủ.
Các nhà phân tích phải đảm bảo rằng các nhu cầu thực sự của khách hàng và người dùng được phát hiện ra, ngay cả khi họ không biết rõ ràng về chúng. Nghĩa là, các nhà phân tích không chỉ thu thập và sắp xếp thông tin về tổ chức của khách hàng và các quy trình của nó, mà họ còn đóng vai trò là nhà tư vấn đóng vai trò tích cực trong việc giúp khách hàng và người dùng xác định nhu cầu của họ.
kết hợp một số bước thành một bước hợp lý, nếu nó hợp lý. Ví dụ: các bước “người dùng nhập tên của anh ấy”, “người dùng nhập số SSN của anh ấy” và “người dùng nhập địa chỉ của anh ấy” có thể dễ dàng kết hợp thành một bước “người dùng nhập thông tin cá nhân”.
Trong phần còn lại của phần này, chúng ta sẽ thảo luận về hai phương pháp khác để phân tích vấn đề. Vì mục tiêu của phân tích là hiểu được lĩnh vực vấn đề, một nhà phân tích phải làm quen với các phương pháp phân tích khác nhau và chọn cách tiếp cận mà anh ta cảm thấy phù hợp nhất với vấn đề hiện tại.
3.5 Các phương pháp phân tích khác
3.5 Các phương pháp phân tích khác 59
3.5.1 Sơ đồ luồng dữ liệu
Trong DFD này có một luồng dữ liệu đầu vào cơ bản, bảng chấm công hàng tuần, bắt nguồn từ nhân viên nguồn. Đầu ra cơ bản là tiền lương, phần chìm cũng là công nhân.
Trong hệ thống này, trước tiên, hồ sơ của nhân viên được truy xuất lại, sử dụng ID nhân viên, có trong bảng chấm công. Từ hồ sơ nhân viên, tỷ lệ thanh toán và làm thêm giờ được lấy. Các mức này và số giờ bình thường và số giờ làm thêm (từ bảng chấm công) được sử dụng để tính lương. Sau khi tổng số tiền được xác định, thuế được khấu trừ. Để tính khoản khấu trừ thuế, thông tin từ tệp thuế suất được sử dụng. Số tiền thuế đã khấu trừ được ghi vào hồ sơ của nhân viên và công ty. Cuối cùng, séc thanh toán được phát hành cho khoản thanh toán ròng. Số tiền thanh toán cũng được ghi lại trong hồ sơ công ty.
Sơ đồ luồng dữ liệu (còn gọi là biểu đồ luồng dữ liệu) được sử dụng phổ biến trong quá trình phân tích vấn đề. Sơ đồ luồng dữ liệu (DFD) khá chung chung và không giới hạn trong việc phân tích vấn đề cho đặc tả yêu cầu phần mềm. Chúng đã được sử dụng từ rất lâu trước khi ngành công nghệ phần mềm bắt đầu. DFD rất hữu ích trong việc hiểu một hệ thống và có thể được sử dụng hiệu quả trong quá trình phân tích.
Cần giải thích một số quy ước được sử dụng để vẽ DFD này. Tất cả các tệp bên ngoài như hồ sơ nhân viên, hồ sơ công ty và thuế suất được hiển thị dưới dạng một đường thẳng được gắn nhãn. Nhu cầu về nhiều luồng dữ liệu của một quy trình được
lặp lại “*” giữa các luồng dữ liệu. Biểu tượng này biểu thị AND được gửi lại bởi
một “*” giữa hai luồng dữ liệu đầu vào Một mối quan hệ. Ví dụ: nếu có a và B cho một quy trình, điều đó có nghĩa
là A VÀ B là cần thiết cho quy trình. Trong DFD, đối với quy trình “trả lương hàng tuần”, cả hai luồng dữ liệu “giờ” và “mức lương” đều cần thiết, như được trình bày trong DFD. Tương tự, mối quan hệ OR được thể hiện bằng dấu “+” giữa các luồng dữ liệu.
DFD hiển thị luồng dữ liệu thông qua một hệ thống. Nó xem một hệ thống như một chức năng chuyển đổi đầu vào thành đầu ra mong muốn. Bất kỳ hệ thống phức tạp nào cũng sẽ không thực hiện quá trình chuyển đổi này trong “một bước duy nhất” và dữ liệu thường sẽ trải qua một loạt các quá trình chuyển đổi trước khi trở thành đầu ra. DFD nhằm mục đích nắm bắt các biến đổi diễn ra trong một hệ thống đối với dữ liệu đầu vào để cuối cùng dữ liệu đầu ra được tạo ra. Tác nhân thực hiện việc chuyển đổi dữ liệu từ trạng thái này sang trạng thái khác được gọi là quá trình (hay bong bóng). Do đó, DFD hiển thị chuyển động của dữ liệu thông qua các quá trình hoặc biến đổi khác nhau trong hệ thống. Các quy trình được hiển thị bằng các vòng tròn được đặt tên và các luồng dữ liệu được biểu thị bằng các mũi tên có tên đi vào hoặc rời khỏi bong bóng. Một hình chữ nhật đại diện cho một nguồn hoặc phần chìm và là người khởi tạo mạng hoặc người tiêu dùng dữ liệu. Nguồn hoặc phần chìm thường nằm ngoài hệ thống nghiên cứu chính. Một ví dụ về DFD cho một hệ thống trả lương cho công nhân được thể hiện trong Hình 3.6.
DFD này là một mô tả trừu tượng về hệ thống xử lý thanh toán.
Cần chỉ ra rằng DFD không phải là một lưu đồ. DFD biểu thị luồng dữ liệu, trong khi lưu đồ biểu thị luồng điều khiển. DFD không đại diện cho thông tin thủ tục. Vì vậy, trong khi vẽ DFD, người ta không được tham gia vào các chi tiết thủ tục và phải tránh tư duy thủ tục một cách có ý thức. Ví dụ, phải bỏ qua việc xem xét các vòng lặp và các quyết định.
Khi vẽ DFD, người thiết kế phải chỉ định các biến đổi chính trong đường dẫn của dữ liệu chảy từ đầu vào đến đầu ra. Làm thế nào những biến đổi đó được thực hiện không phải là một vấn đề trong khi vẽ biểu đồ luồng dữ liệu.
Nhiều hệ thống quá lớn để một DFD đơn lẻ có thể mô tả quá trình xử lý dữ liệu một cách rõ ràng. Điều cần thiết là một số cơ chế phân tách và trừu tượng hóa được sử dụng cho các hệ thống như vậy. DFD có thể được tổ chức theo thứ bậc, giúp Không quan trọng hệ thống là tự động hay thủ công. Sơ đồ này rất có thể dành cho một hệ thống thủ công trong đó tất cả các tính toán đều được thực hiện bằng máy tính và các bản ghi là các thư mục và sổ cái vật lý. Các chi tiết và đường dẫn dữ liệu nhỏ không được trình bày trong DFD này. Ví dụ: điều gì sẽ xảy ra nếu có lỗi trong bảng chấm công hàng tuần không được hiển thị trong DFD này. Điều này được thực hiện để tránh bị sa lầy vào các chi tiết trong khi xây dựng DFD cho toàn bộ hệ thống. Nếu muốn biết thêm chi tiết, DFD có thể được tinh chỉnh thêm.
Hình 3.6: DFD của một hệ thống trả lương cho người lao động.
3.5.2 Sơ đồ ER
3.5 Các phương pháp phân tích khác 61
Một bộ DFD được phân cấp có một DFD bắt đầu, đây là một biểu diễn rất trừu tượng của hệ thống, xác định các đầu vào và đầu ra chính cũng như các quy trình chính trong hệ thống. Thông thường, trước DFD ban đầu, một biểu đồ ngữ cảnh có thể được vẽ trong đó toàn bộ hệ thống được hiển thị dưới dạng một quy trình duy nhất với tất cả các đầu vào, đầu ra, phần chìm và nguồn của nó. Sau đó, mỗi quy trình được tinh chỉnh và DFD được rút ra cho quy trình. Nói cách khác, bong bóng trong DFD được mở rộng thành DFD trong quá trình sàng lọc. Để hệ thống phân cấp nhất quán, điều quan trọng là đầu vào và đầu ra ròng của DFD cho một quy trình giống như đầu vào và đầu ra của quy trình trong DFD cấp cao hơn.
Quá trình sàng lọc này dừng lại nếu mỗi bong bóng được coi là "nguyên tử", trong đó mỗi bong bóng có thể được xác định hoặc hiểu một cách dễ dàng. Cần chỉ ra rằng trong quá trình sàng lọc, mặc dù đầu vào và đầu ra ròng được giữ nguyên, nhưng việc sàng lọc dữ liệu cũng có thể xảy ra. Nghĩa là, một đơn vị dữ liệu có thể được chia thành các thành phần của nó để xử lý khi DFD chi tiết cho một quy trình đang được vẽ. Vì vậy, khi các quy trình được phân tách, quá trình phân tách dữ liệu cũng xảy ra.
Từ điển dữ liệu liên quan nêu chính xác cấu trúc của từng luồng dữ liệu trong DFD. Để xác định cấu trúc dữ liệu, một ký hiệu kiểu biểu thức chính quy được sử dụng. Trong khi chỉ định cấu trúc của một mục dữ liệu, trình tự hoặc thành phần được biểu thị bằng dấu
“+”, lựa chọn bằng thanh dọc “|” (có nghĩa là cái này HOẶC cái kia) và lặp lại bởi “*”.
Đây là các thực thể và các mối quan hệ. Các thực thể là những người nắm giữ thông tin chính hoặc các khái niệm trong một hệ thống. Các thực thể có thể được xem như các kiểu mô tả tất cả các phần tử thuộc kiểu nào đó có các thuộc tính chung. Các thực thể được đại diện Sơ đồ mối quan hệ thực thể (ERD) đã được sử dụng trong nhiều năm để mô hình hóa các khía cạnh dữ liệu của một hệ thống. ERD có thể được sử dụng để mô hình hóa dữ liệu trong hệ thống và cách các mục dữ liệu liên quan với nhau, nhưng không bao gồm cách xử lý dữ liệu hoặc cách dữ liệu thực sự được thao tác và thay đổi trong hệ thống. Nó thường được các nhà thiết kế cơ sở dữ liệu sử dụng để biểu diễn cấu trúc của cơ sở dữ liệu và là một công cụ hữu ích để phân tích các hệ thống phần mềm sử dụng cơ sở dữ liệu. Các mô hình ER hình thành thiết kế cơ sở dữ liệu logic và có thể dễ dàng chuyển đổi thành cấu trúc bảng ban đầu cho cơ sở dữ liệu quan hệ.
Trong DFD, các luồng dữ liệu được xác định bằng các tên duy nhất. Những tên này được chọn để chúng truyền đạt một số ý nghĩa về dữ liệu là gì. Tuy nhiên, để chỉ định cấu trúc chính xác của luồng dữ liệu, từ điển dữ liệu thường được sử dụng.
dần dần phân vùng và phân tích các hệ thống lớn. Các DFD như vậy cùng nhau được gọi là một bộ DFD được phân cấp [28].
Sơ đồ ER có hai khái niệm và ký hiệu chính để biểu diễn chúng.