Bài giảng Phân tích thiết kế hệ thống: Chương 2 - Từ Thị Xuân Hiền

Bài giảng Phân tích thiết kế hệ thống: Chương 2 do Từ Thị Xuân Hiền biên soạn nhằm mục đích phục vụ cho việc giảng dạy. Nội dung bài giảng gồm: Yêu cầu của hệ thống, tiến trình phân tích yêu cầu bài toán, mục tiêu của phân tích yêu cầu, các loại tài liệu trong phân tích yêu cầu,...

Chương 2

Mô hình hóa yêu cầu của bài toán

sử dụng use case diagram

Yêu cầu của hệ thống

 Những chức năng mà hệ thống phải thực hiện.

 Những đặc tính mong muốn của người dùng đối với hệ

thống.

 Những phát biểu về những đề xuất đối với hệ thống mà tất cả các bên tham gia đống ý về các vấn đề của khách hàng phải được giải quyết thỏa đáng.

Tiến trình phân tích yêu cầu bài toán

 Tìm hiểu, khám phá và phân tích các yêu cầu của của người dùng đối với hệ thống.

 Xây dựng các tài liệu yêu cầu

 Kiểm tra tính hợp lệ của các yêu cầu

 Quản lý các yêu cầu

 Mô hình hóa yêu cầu

Mục tiêu của phân tích yêu cầu

 Yêu cầu thường không được nêu một cách rõ ràng, don đó

người phát triển hệ thống cần phải làm việc với khách hàng

và các bên liên quan để khai thác:

• Các dịch vụ mà hệ thống cần cung cấp

• Những ràng buộc mà hệ thống phải đáp ứng

Mục tiêu của phân tích yêu cầu

 Mục tiêu:

• Đảm bảo các yêu cầu đối với sản phẩm phần mềm được định nghĩa và hiểu một cách rõ ràng

• Thiết lập và duy trì các thỏa thuận về yêu cầu với các bên liên quan

• Đảm bảo tất cả các yêu cầu được đáp ứng

• Tài liệu phân tích yêu cầu dùng để kiểm soát và là cơ sở cho việc phát triển phần mềm và sử dụng trong quản lý dự án

• Phát hiện và giải quyết mâu thuẫn giữa yêu cầu

• Xác định phạm vi của phần mềm và cách nó tương tác với môi trường

Các loại tài liệu trong phân tích yêu cầu

 Xác định yêu cầu người dùng (URD – User requirement definition)

• Xác định những gì người dùng cần cho công việc của họ

• Bao gồm yêu cầu doanh doanh nghiệp, quy tắc nghiệp vụ và các ràng buộc khác

Các loại tài liệu trong phân tích yêu cầu

 Đặc tả yêu cầu phần mềm (SRS – Software requirement specification)

• Một tập hợp các yêu cầu phần mềm: đầy đủ, nhất quán và chính xác

từ quan điểm của nhà phát triển

• Tài liệu đặc tả yêu cầu dùng làm cơ sở tham chiếu chung của các yêu cầu phần mềm cho khách hàng, nhà phát triển, thử nghiệm và quản lý

dự án

Các loại yêu cầu

Yêu cầu chức năng - Functional requirements

 Mô tả sự tương tác giữa hệ thống và môi trường của nó

 Mô tả cách ứng xử của hệ thống với hành vi kích hoạt của người dùng

• Có thể sử dụng mô hình - một sự kết hợp của các ký hiệu đồ họa và cấu trúc ngôn ngữ tự nhiên

• Sử dụng use case diagram, activity, state diagram

• Prototype,

Yêu cầu phi chức năng - NonFunctional requirements

 Mô tả các hạn chế trên một hệ thống làm hạn chế sự lựa chọn

và từ đó đưa ra một giải pháp cho một vấn đề xác định

 Các yêu cầu phi chức năng không được mô hình hóa => được chỉ định chỉ sử dụng ngôn ngữ tự nhiên có cấu trúc

Tính hợp lệ của các yêu cầu

 Đánh giá các yêu cầu - Requirements Review

• Phân tích thủ công có hệ thống các yêu cầu

• Tham gia của nhà phát triển, khách hang, các bên tham gia

Quản lý các yêu cầu thay đổi

 Yêu cầu thay đổi (CR – Change request)

• Các yêu cầu từ quan điểm khác nhau thay đổi trong quá trình phát triển

• Khách hàng có thể xác định các yêu cầu từ góc độ kinh doanh mâu thuẫn với yêu cầu của người dùng cuối

• Môi trường kinh doanh và kỹ thuật của hệ thống thay đổi trong quá trình phát triển hệ thống

 Tiến trình yêu cầu thay đổi

Thuật ngữ - Glossary

 Khái niệm:

• Một tập hợp các thuật ngữ được định nghĩa làm cơ sở cho giao tiếp

• Một từ điển để thực hiện mô hình hóa

Thuật ngữ - Glossary

 Ví dụ

Nội dung trong tài liệu xác định yêu cầu hệ thống

1 Mục đích

2 Phạm vi

3 Tổng quan hệ thống

4 Tài liệu tham khảo

5 Xác định các điều khoản, các thuật ngữ chuyên môn

6 Yêu cầu chức năng

7 yêu cầu phi chức năng

Bài tập

 Viết một đặc tả yêu cầu cho một hệ thống bán hàng trong siêu thị.

Mô hình hóa yêu cầu hệ thống

sử dụng mô hình use case

Use case diagram

 Mô tả trực quan các chức năng được cung cấp bởi hệ thống

 Một Use Case thể hiện một hành động tương tác riêng biệt giữa người dùng (human or machine) và hệ thống.

 Use case diagram chứa các thành phần:

• Use cases

• Actors

• Relationships

Use case diagram

 Use case

• Một use case đại diện cho một chức năng hoàn chỉnh, bao gồm một

chuỗi các hoạt động khác nhau mà hệ thống có thể thực hiện bằng

cách tương tác với các actor bên ngoài hệ thống.

• Các yếu tố của một use case

• Kịch bản (scenarios): là một tập các ràng buộc theo mục tiêu người dùng,

thường là một chuỗi các giao dịch được thực hiện bởi một hệ thống, có thể nhìn thấy được, đo lường được kết quả.

Use case diagram

 Use Cases

• Mô tả hoặc nắm bắt yêu các cầu chức năng của hệ thống

• Một use case đại diện cho một chuỗi các hành vi tương tác của hệ thống và các actor bên ngoài

 Ký hiệu use case trong UML

Use case diagram

 Actor:

• Là một thực thể tương tác với hệ thống, actor có thể là người dùng, hoặc các ứng dụng bên trong, hoặc một hệ thống bên ngoài của hệ thống đang xây dựng

 Loại Actor:

• Primary Actor: Actor trực tiếp kích hoạt giao tiếp giữa actor và hệ

thống Thông thường là người sử dụng

• Secondary actor: Actor chỉ thực hiện giao tiếp khi được yêu cầu từ hệ

thống tại thời điểm thực thi của một use case nào đó

Use case diagram

 Ký hiệu Actor trong UML

• Tên actor là một danh từ

Các mối quan hệ trong use case diagram

 Quan hệ giữa Actors và use cases: Association

• Actor tham gia tương tác với hệ thống được mô tả bởi use case

• Nếu quan hệ association có hướng:

• Xác định hướng tương tác của actor chính

• Xác định luồng điều khiển (not data flow)

Login

Các mối quan hệ trong use case diagram

 Quan hệ giữa Actor và Actor:

• Administrator có những thao tác riêng mà User

và Client không thực hiện được

Các mối quan hệ trong use case diagram

 Quan hệ giữa Use case với use case

• Include

• Extend

• Generalization/Specification

Các mối quan hệ trong use case diagram

 Include : hành vi của included use case là thành phần của

base use case

• Hành vi của base use case không hoàn thành nếu không có included use case.

• Use case included là bắt buộc (mandatory)

Các mối quan hệ trong use case diagram

 Ví dụ: để thực hiện hành vi Xem điểm thì bắt buộc phải thực hiện hành vi Đăng nhập

Base Use case Included Use caseSinhvien

Các mối quan hệ trong use case diagram

 Extend : extending use case phụ thuộc vào base use case.

• Extending Use case thường là tùy chọn và kèm theo điều kiện thực

hiện

Các mối quan hệ trong use case diagram

 Ví dụ: sau khi Đăng ký học phần thì sinh viên có thể Xem lịch

học (hành vi Xem lịch học là tùy chọn)

Sinhvien

Các mối quan hệ trong use case diagram

 Generalization: được sử dụng khi có hai hoặc nhiều use case

có cùng hành vi, cấu trúc và mục đích

 Specialized use cases có cùng hành vi, yêu cầu, ràng buộc

• Những thành phần chung nhất được mô tả 1 lần trong general use case

• Những thành phần khác nhau được mô tả trong specialized use case

 Ký hiệu trong UML

Các mối quan hệ trong use case diagram

Thanh toán bằng thẻ ATM

Cách xác định use case

 Dựa trên kịch bản của những hoạt động bên ngoài có thể nhìn thấy, đo lường được kết quả của giá trị mà các actor mong muốn

 Từ mô tả yêu cầu chức năng của hệ thống.

 Tìm các động từ mô tả hành vi tương tác của hệ thống và actor trong phần mô tả hệ thống.

Cách xác định use case

 Có thể dùng các câu hỏi sau đây

• Những chức năng gì mà các actor mong muốn từ hệ thống?

• Hệ thống lưu trữ những thông tin gì? Các actor thực hiện những thao tác gì trên những thông tin này?

• Hệ thống có cần hiển thị thông báo cho actor về những thay đổi trạng thái bên trong hệ thống không?

Câu hỏi

 Xác định Primary actors và Secondary actors của hệ thống ATM

• Khách hàng

• Chủ thẻ VISA

• Nhân viên ngân hàng

• Hệ thống thông tin ngân hàng (Bank IS)

• Hệ thống chứng thực thẻ VISA (VISA AS)

 Xác định các use case của hệ thống ATM

 Vẽ sơ đồ use case của hệ thống ATM

Hệ thống ATM

Đặc tả Use-Case

 Một use case đại diện cho một hành vi tương tác hoàn chỉnh,

nó bao gồm một chuỗi tuần tự các hoạt động giao tiếp giữa actor và hệ thống

 Đặc tả use case nhằm mô tả chi tiết chuỗi các hoạt động để thực hiện hành vi của use case từ lúc bắt đầu đến kết thúc bao gồm các lỗi trong quá trình thực hiện

Đặc tả Use-Case

 Mỗi use case gắn liền với các kịch bản bao gồm các một chuỗi tuần tự các sự kiện:

• Basic flow: một luồng sự kiện thành công chính

• Alternative flows: Có nhiều luồng sự kiện thanh thế

• Exceptional flows: Ngoại lệ cho những trường hợp lỗi

Mẫu nội dung đặc tả Use-Case

Bài tập

 Hãy viết đăc tả các use case trong hệ thống ATM

• Kiểm tra tài khoản

• Rút tiền

Mô hình hóa luồng sự kiện

với activity

Các ký hiệu trong sơ đồ Activity

 Điểm bắt đầu (Initial State):

• Biểu diễn điểm khởi đầu cho sơ đồ hoạt động Đối với sơ đồ hoạt động

sử dụng swimlanes, phải đảm bảo các điểm bắt đầu được đặt ở góc trên cùng bên trái của cột đầu tiên

• Ký hiệu trong UML

Các ký hiệu trong sơ đồ Activity

 Hoạt động (Activity)

• Hoạt động là một hành vi đại diện điều phối dòng chảy của hành động

• Hoạt động (activity) chứa các nút có thể là:

• Hoạt động (action)

• Đối tượng (object)

• Điều khiển (Control)

Các ký hiệu trong sơ đồ Activity

Các ký hiệu trong sơ đồ Activity

Các ký hiệu trong sơ đồ Activity

 Nút Merge

• Sự kết hợp của các luồng sự kiện Các đầu vào không đồng bộ

• Nhiều đầu vào và chỉ có một đầu ra

• Ký hiệu trong UML

Các ký hiệu trong sơ đồ Activity

 Đồng bộ hóa (Synchronization)

• Nút fork được sử dụng để chia một luồng đến đơn thành nhiều luồng

đồng thời

• Ký hiệu trong UML

• Nút Join nối nhiều dòng đồng thời trở thành một luồng đi duy nhất.

• Ký hiệu trong UML

Các ký hiệu trong sơ đồ Activity

• Fork và Join được sử dụng cùng nhau gọi là đồng bộ hóa.

Activity

Activity Activity

Fork

Join

Các ký hiệu trong sơ đồ Activity

 Nút kết thúc (Final State hoặc End Point)

• Nút kết thúc hoạt động cho thấy một hoạt động được hoàn tất

• Một sơ đồ hoạt động có thể có nhiều hơn một nút kết thúc

• Ký hiệu trong UML

Các dạng Activity

 Activity Partition (swimlane)

• Đại diện cho một số thuộc tính như vị trí mà tại đó một hành vi được thực hiện

• Activity hiển thị bằng ký hiệu swimlane với các dòng thường song song, hoặc ngang hoặc thẳng đứng Bất kỳ các nút hoạt động đặt giữa những dòng này được coi là chứa trong phân vùng đó

Các dạng Activity

 Sub Activity

Mô hình hóa hoạt động của use case

với Sequence diagram

Sơ đồ tuần tự - Sequence diagram

 Sơ đồ tuần tự được sử dụng trong cả giai đoạn phân tích và thiết kế

 Trong giai đoạn phân tích yêu cầu của bài toán, sơ đồ tuần tự

được sử dụng để mô tả luồng sự kiện theo thời gian cấu trúc

các hoạt động thực hiện một use case.

 Sơ đồ tuần tự biểu diễn chi tiết quan hệ giao tiếp giữa các đối

tượng trong quá trình thực hiện use case

Sơ đồ tuần tự - Sequence diagram

 Sơ đồ hoạt động và tuần tự

trong phân tích yêu cầu bài

toán

• Sơ đồ hoạt động mô tả một chuỗi

các hoạt động theo cấu trúc điều

kiện, vòng lặp hoặc đồng thời để

thực thi một use case

• Sơ đồ trình tự mô tả chuỗi các

thông điệp giao tiếp giữa các đối

Các thành phần trong sơ đồ tuần tự

 Lifeline là một yếu tố được đặt tên đại diện cho một cá nhân

tham gia trong sự tương tác

Các thành phần trong sơ đồ tuần tự

 Đối tượng tham gia (Participant): đối tượng thực hiện hành

động trong sơ đồ trình tự.

• Ký hiệu trong UML

Các thành phần trong sơ đồ tuần tự

 Lifeline: biểu diễn thời gian sống của đối tượng trong sơ đồ

Các thành phần trong sơ đồ tuần tự

 Thông điệp (Messages): biểu diễn giao tiếp giữa các đối

tượng

• Thông điệp không đồng bộ: được gửi từ một đối tượng sẽ không

chờ thông điệp trả về từ đối tượng nhận trước khi tiếp tục

• Ký hiệu trong UML:

• Ví dụ:

Các thành phần trong sơ đồ tuần tự

• Thông điệp đồng bộ: đối tượng gửi thông điệp chờ đến khi thông

điệp được xử lý trước khi tiếp tục

• Ký hiệu trong UML:

Các thành phần trong sơ đồ tuần tự

 Return Message

• Thông điệp trả về kết quả cho đối tượng gửi

• Ký hiệu trong UML

return

Các thành phần trong sơ đồ tuần tự

 Self Message

• Một một cuộc gọi đệ quy của một hoạt động, hoặc một phương thức gọi một phương thức khác trên cùng một đối tượng

• Ký hiệu:

Các thành phần trong sơ đồ tuần tự

 Thời gian sống của một đối tượng

• Một đối tượng bắt đầu bằng lệnh create và kết thúc bằng Delete

• Creation: biểu diễn bằng mũi tên với nhãn 'new‘

• Một đối tượng được tạo sau khi bắt đầu kịch bản sẽ xuất hiện thấp hơn những đối tượng khác

• Deletion: ký hiệu X tại cuối của lifeline

Hoạt động tương tác trong sơ đồ tuần tự

 Frame: một hộp biểu diễn một phần của

sơ đồ tuần tự để thể hiện sự lựa chọn

hoặc lặp

 hộp xung quanh một phần của biểu đồ

trình tự để biết sự lựa chọn hoặc loop

Hoạt động tương tác trong sơ đồ tuần tự

 Alt

• Biểu diễn cho một sự lựa chọn hoặc thay thế của hành vi

• Ví dụ:

Hoạt động tương tác trong sơ đồ tuần tự

 Option

• Đại diện cho một sự lựa chọn của hành vi mà một trong hai (duy nhất) toán hạng sẽ xảy ra hoặc không có gì xảy ra

• Ví dụ:

Hoạt động tương tác trong sơ đồ tuần tự

 Loop

• Vòng lặp sẽ được thực hiện chính xác số lần quy định

Hoạt động tương tác trong sơ đồ tuần tự

 Ví dụ: sơ đồ tuần tự tính tiền hóa đơn (Order)