Bài giảng Phân tích và thiết kế hệ thống hướng đối tượng

Trong mục này chúng ta khảo sát sự phát triển của các công cụ để giúp chúng ta hiểu sự thành

lập và các nét nổi bật của kỹ thuật hướng đối tượng. Trong quá trình phát triển công nghệ phần

mềm chúng ta có thể để ý và nghiên cứu theo 2 hướng sau:

- Phát triển các chương trình nhỏ tới các chương trình lớn

- Sự phát triển của các ngôn ngữ lập trình bậc cao hơn.

Hầu hết tất cả các chương trình phần mềm ngày càng đòi hỏi cao vào phức tạp hơn. Chính điều

này đã thúc đẩy việc nghiên cứu trong lĩnh vực công nghệ phần mềm, mà đặc biệt quan tâm tới sự

phân tích, trừu tượng và tổ chức cho hệ thống. Đi đôi với điều này, việc phát triển các ngôn ngữ lập

trình cũng đã đáp ứng được phần nào về giải quyết yêu cầu phức tạp của hệ thống.

Wenger đã phân loại ra một số ngôn ngữ lập trình bậc cao phổ biến và sắp xếp theo thứ tự tùy

thuộc và một số đặc tính của từng loại ngôn ngữ:

pdf52 trang | Chia sẻ: Mr Hưng | Lượt xem: 997 | Lượt tải: 0download
Bạn đang xem trước 20 trang nội dung tài liệu Bài giảng Phân tích và thiết kế hệ thống hướng đối tượng, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
hách hàng. - Nhận đơn đặt hàng. - Xác nhận đơn - Gửi đơn đặt hàng đi. Sau khi nhận được đơn đặt hàng, điều tra điều kiện được thực hiện để kiểm tra xem đơn đặt hàng là 1 trong 2 loại normal hay special order. Sau khi loại đơn đặt hàng được xác định hành động gửi đi được thực hiện và được xem như là kết thúc một tiến trình hoạt động. 36 Bài tập 1) Biểu đồ lớp là gì? Mục đích và cách vẽ biểu đồ lớp (Class diagram)? 2) Biểu đồ đối tượng là gì? Mục đích và cách vẽ biểu đồ đối tượng (Object diagram)? 3) Biểu đồ Use case là gì? Mục đích và cách vẽ biểu đồ Use case? 4) Biều đồ tuần tự là gì? Mục đích và cách vẽ biểu đồ tuần tự (Sequence diagram)? 37 CHƢƠNG V: QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ 5.1. Nền tảng Phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra. Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án. Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirements engineering). Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tên như thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêu cầu (requirements specification). Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tài liệu yêu cầu). Tùy theo mức độ phức tạp của phần mềm làm ra, người thiết kế phần mềm sẽ ít nhiều dùng đến các phương tiện để tạo ra mẫu thiết kế theo ý muốn (chẳng hạn như là các sơ đồ khối, các lưu đồ, các thuật toán và các mã giả), sau đó mẫu này được mã hoá bằng các ngôn ngữ lập trình và đưọc các trình dịch chuyển thành các khối lệnh (module) hay/và các tệp khả thi. Tập hợp các tệp khả thi và các khối lệnh đó làm thành một phần mềm. Thường khi một phần mềm được tạo thành, để cho hoàn hảo thì phần mềm đó phải đưọc điều chỉnh hay sửa chữa từ khâu thiết kế cho đến khâu tạo thành phiên bản phần mềm một số lần. Một phần mềm thông thường sẽ tương thích với một hay vài hệ điều hành, tùy theo cách thiết kế, cách viết mã nguồn và ngôn ngữ lập trình được dùng. 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm Mục đích của quy trình vĩ mô là để hướng dẫn toàn bộ triển khai hệ thống. Một cách cơ bản là để hướng dẫn tạo ra hệ thống. Phạm vi của quy trình vĩ mô là từ một ý tưởng ban đầu của hệ thống phần mềm mà thực hiện triển khai ý tưởng đó. 5.2.1. Quy trình vĩ mô theo nội dung Quy trình vĩ mô theo nội dung bao gồm một số các giai đoạn sau: - Yêu cầu (Requirements): Thiết lập và duy trì sự thỏa thuận với các khách hàng và các nhà đầu tư khác trên những gì hệ thống nên làm. Thiết lập giới hạn của hệ thống. - Phân tích và thiết kế: Biến đổi những yêu cầu trong thiết kế hệ thống, cái mà phục vụ như là một đặc tả của sự thi hành trong môi trường thi hành đã chọn. - Thi hành (Implementation): thi hành, kiểm tra và tích hợp hệ thống, kết quả một hệ thống có thể thực thi. 38 - Kiểm định: Kiểm định thực thi để đảm bảo rằng đã hoàn thành các yêu cầu. Xác nhận thông qua các bản demo mà phần mềm thực hiện các chức năng như đã thiết kế. - Triển khai: Đảm bảo rằng sản phẩm phần mềm là sẵn sàng cho người dùng cuối của nó. Các quy tắc sau sẽ được thực hiện qua vòng đời của phần mềm - Quản lý dự án: Quản lý dự án phát triển phần mềm, bao gồm: lên kế hoạch, phục vụ và giám sát dự án cũng như quản lý rủi ro. - Quản lý cấu hình và sự thay đổi: Xác định cấu hình các mục, điều khiển sự thay đổi của các mục đó và quản lý cấu hình của các mục đó. - Môi trường: Cung cấp môi trường phát triển phần mềm bao gồm cả các quy trình và công tụ mà hỗ trợ cho đội triển khai. 5.2.2. Quy trình vĩ mô theo thời gian – Mốc và giai đoạn a. Giai đoạn bắt đầu (Inception): Mục đích: Mục đích của giai đoạn khởi đầu là đảm bảo rằng dự án có tính ứng dụng và khả thi. Hoạt động: Trong suốt giai đoạn Khởi đầu, bạn thiết lập và ưu tiên những yêu cầu cốt yếu của hệ thống, đạt được thỏa thuận với khách hàng trên những gì được xây dựng, đảm bảo rằng bạn hiểu và nắm được những rủi ro kèm theo việc xây dựng một hệ thống và quyết định môi trường triển khai nào được sử dụng (gồm cả quy trình và công cụ). 39 Sản phẩm (Work Products): Sản phẩm chính của giai đoạn khởi đầu là tầm nhìn về những gì được xây dựng, các thuộc tính hành vi, một danh sách rủi ro, xác định kiểu kiến trúc kĩ thuật và môi trường phát triển. Tầm nhìn cung cấp một cách mô tả rõ ràng về những gì được xây dựng bao gồm phạm vi của nó, đặc trưng, ảnh hưởng qua lại và quan hệ với các hệ thống đã tồn tại cũng như là bất kì các rằng buộc phải được theo dõi, xem xét. Mốc (Milestone): Phạm vi được hiểu. Giai đoạn Khởi tạo được hoàn thành khi có sự hiểu rõ ràng về những gì được xây dựng (toàn bộ phạm vi và các yêu cầu chính của hệ thống), hiểu rõ sự ưu tiên của các yêu cầu liên quan. b. Chi tiết bổ sung (Elaboration): Mục đích: Điều đầu tiên đó là những gì cần xây dựng phải được hiểu và đạt được sự đồng ý, chấp thuận. Hoạt động: Giai đoạn Elaboration bao gồm việc quyết định đưa ra kiến trúc, thiết lập phần nền tảng của kiến trúc, triển khai phần cốt lõi, kiểm định và tinh chỉnh nền tảng xây dựng hệ thống dựa trên kết quả của việc kiểm định. Sản phẩm (Work Product): Trong suốt giai đoạn Elaboration, kiến trúc được phê duyệt bằng việc tao ra một chuỗi kiến trúc có thể thực thi. Kết quả của giai đoạn Elaboration không chỉ cung cấp một tài liệu về kiến trúc mà còn bao gồm những ấn phẩm thực tế của hệ thống. Mốc: Giai đoạn Elaboration được hoàn thành khi kiến trúc được xác lập tính hợp lệ với tất cả các yêu cầu của hệ thống và về chức năng và không chức năng, và khi tất cả các rủi ro đã được giảm bớt để xác định giá và lịch biểu cho quá trình triển khai hệ thống. c. Xây dựng (Construction) Mục đích: Xây dựng một kiến trúc ổn định, tập trung vào việc chuyển từ hiểu vấn đề và xác định những giải pháp chính tới việc triển khai một sản phẩm có thể triển khai. Hoạt động: Trong suốt giai đoạn xây dựng, việc phát triển hệ thống được hoàn thành dựa trên kiến trúc cơ sở được xây dựng từ giai đoạn trước. Sản phẩm: Trong suốt giai đoạn này, một chuỗi các ấn bản có thể thực thi được đưa ra đáp ứng những kịch bản, yêu cầu của người dùng cuối. Mốc: Hệ thống sẵn sàng cho người dùng cuối kiểm tra: Giai đoạn xây dựng hoàn thành khi các chức năng và chất lượng của các ấn bản là cần thiết để triển khai tới người dùng cuối cho một số người dùng cuối khác kiểm tra. d. Chuyển giao. Mục đích: Giai đoạn chuyển giao được thực hiện khi bạn chắc chắn sản phẩm có thể được chấp nhận bởi người dùng cuối. Hoạt động: Trong suốt giai đoạn chuyển tiếp, sản phẩm được cung cấp tới người dùng cho việc đánh giá và kiểm định. Sau đó nhóm triển khai thu thập những phản hồi của người dùng. Trong giai đoạn này chủ yếu tập chung vào làm cho chương trình khớp với yêu cầu, 40 thiết lập cấu hình, cài đặt và hướng dẫn sử dụng. Các tài liệu hỗ trợ dùng chương trình được hoàn thiện và gửi cho người dùng cuối. Sản phẩm: Sản phẩm được đưa ra trong suốt giai đoạn chuyển giao bao gồm sản phẩm đóng gói, tài liệu hỗ trợ, tài liệu hướng dẫn. Mốc: Hệ thống sẵn sàng cho việc triển khai. 5.2.3. Quy trình vĩ mô theo thời gian – Lặp đi lặp lại Trong quy trình vĩ mô, các mốc đạt được bằng việc thực hiện 1 hoặc nhiều lần lặp lại và những lần lặp lại này có thể bao gồm các hoạt động trong bất kì vào trong toàn bộ quy tắc. Tuy nhiên, thời gian lặp lại sử dụng trong các quy tắc khác nhau phụ thuộc vào xuất hiện trong giai đoạn lặp nào. Nếu quá trình lặp lại được thực hiện trong giai đoạn khởi đầu, phần lớn thời gian sẽ được sử dụng trên việc xử lý các yêu cầu. Nếu quá trình lặp lại được thực hiện trong giai đoạn chi tiết, phần lớn thời gian sẽ được sử dụng trên việc phân tích và thiết kế. Nếu quá trình lặp lại được thực hiện trong giai đoạn xây dựng thì phần lớn thời gian được sử dụng trên việc triển khai và kiểm định. Tất nhiên, đối với một số disciplines, như là cấu hình và thay đổi quan lý, môi trường, quản lý dự án, được thực hiện thông qua vòng đời của chương trình. Hình trên miêu tả một dự án di chuyển thông qua một chuỗi quá trình được lặp đi lặp lại. Kích thước của các hộp trong mỗi giai đoạn biểu thị lượng thời gian được sử dụng trên giai đoạn đó. 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế Như hình mô tả dưới đây, quá trình phân tích và thiết kế hệ thống được thực hiện trong toàn bộ quá trình phát triển phần mềm. Quá trình vĩ mô cung cấp đầu vào cho quá trình vi mô và sử dụng đầu ra của quá trình vi mô. Đặc biệt quá trình vi mô lấy yêu cầu được cung cấp bởi quá trình vĩ mô và sản xuất ra đặc tả thiết kế mà đã được thực hiên, kiểm thử và triển khai trong quá trình vĩ mô. 41 Chúng ta đã mô tả quá trình vĩ mô trong 2 lĩnh vực đó là thời gian và nội dung, ở đây chúng ta cũng sẽ mô tả quá trình vi mô trong 2 lĩnh vực đó là khái niệm và nội dung. 5.3.1. Mức độ trìu tƣợng, khái niệm Trong quá trình vi mô, các giai đoạn phổ biến, truyền thống của phân tích và thiế kế là tập trung vào việc làm mờ và thay thế được thực hiện tại các mức độ khác nhau của trìu tượng. Phân tích lấy các yêu cầu của hệ thống và đưa ra một giải pháp ban đầu, và thiết kế lấy kết quả của quá rình phân tích và đưa ra một đặc tả mà có hiệu quả trong việc thực hiện. Việc phân tích được xem như là hoàn thành khi nó biểu diễn đúng đắn, chính xác các yêu cầu của hệ thống, là phù hợp và có thể phục vụ tốt cho việc thiết kế. Việc thiết kế được xem như là hoàn thành khi nó mô tả chi tiết đủ để thực hiện và kiểm định. Phân tích tập trung vào hành vi chứ không phải cấu tạo. Trong phân tích, bạn tìm đến xây dựng một thế giới bằng việc xác định các phần tử mà tạo nên các vấn đề trong hệ thống và mô tả chức năng của chúng, trách nhiệm và sự cộng tác. Trong thiết kế, bạn sáng tạo ra các phần tử mà cung cấp các hành vi mà các phần tử trong giai đoạn phân tích yêu cầu. Bạn bắt đầu quá trình thiết kế ngay khi bạn hoàn thành việc xây dựng mô hình các hành vi của hệ thống. Phân tích và thiết kế được thực hiện tại các mức của trìu tượng qua vòng đời phát triển. Số mức không thể xác định, nó phụ thuộc vào phạm vi của hệ thống. 42 Các hành động Quá trình vi mô bao gồm một tập các hành động, mà được thực hiện cho phạm vi xác định và tại mức độ trìu tượng xác định. - Xác định các phần tử? Tìm hiểu, khám phá hoặc đề xuất các phần tử sẽ sử dụng. - Định nghĩa sự kết hợp giữa các phần tử: Mô tả các phần tử kết hợp với nhau như thế nào để cung cấp các hành vi mà hệ thống yêu cầu. - Định nghĩa các mối quan hệ giữa các phần tử. Định nghĩa các mối quan hệ giữa các phần tử, hỗ trợ cho sự kết hợp các phần tử. - Định nghĩa semantic của các phần tử: Thiết lập các hành vi và các thuộc tính của các phần tử, chuẩn bị các phần tử cho mức độ trìu tượng tiếp theo. Các hoạt động của quá trình vi mô được mô tả bởi hình sau: Sản phẩm Có 2 sản phẩm chính sẽ được sinh ra trong quá trình vi mô: - Mô tả kiến trúc: Mô tả kiến trúc của hệ thống, bao gồm cả việc miêu tả kĩ thuật chung. Việc mô tả bao gồm cấu trúc cần thiết cho diện mạo của mô hình phân tích và thiết kế. 43 - Mô hình phân tích thiết kế bao gồm các phần tử phân tích thiết kế của giải pháp phần mềm và việc tổ chức chúng, cũng như các mối quan hệ mà miêu tả hành vi yêu cầu của hệ thống được thực hiện như thế nào trong các phần tử đó. Quá trình vi mô và mức độ trừu tƣợng Quá trình vi mô áp dụng như nhau đối với kiến trúc sư dự án và kĩ sư ứng dụng, sự khác biệt đó là mức độ trìu tượng được đề cập. Từ góc nhìn của kiến trúc sư, quá trình vi mô cung cấp một khuôn mẫu cho phát triển và khám phá kiến trúc thay thế. Từ quan điểm của kĩ sư, quá trình vi mô cung cấp các hướng dẫn trong việc ra quyết định thích ứng với từng kiểu cấu trúc. Khi thực hiện phân tích kiến trúc, quá trình vi mô tập trung vào việc tạo một phiên bản ban đầu của kiến trúc, những kiến trúc này thúc đẩy các kiến trúc đã tồn tại hoặc các kiến trúc nền tảng ban đầu. Trong quá trình thiết kế kiến trúc, kiến trúc ban đầu được phát triển từ kiến trúc phân tích mà đã được lọc, lựa chọn dựa trên những kinh nghiệm trong suốt quá trình phân tích kiến trúc. Quá trình vi mô tập trung vào việc chọn lọc các phần tử đã được phân tích rõ ràng, các phần tử thiết kế và trách nhiệm của chúng. Các phần tử thiết kế được định nghĩa tại mức độ này biểu diễn các khối chính của toàn bộ kiến trúc nền tảng và các mối quan hệ của chúng xác định toàn bộ cấu trúc của hệ thống. Các kĩ thuật phân tích cũng được chọn lựa vào trong kĩ thuật thiết kế mà thúc đẩy các công nghệ trước đó. Việc sử dụng lại cũng đóng vai trò quan trọng. Trong thành phần phân tích, quá trình vi mô tập trung vào việc phân tích các phần tử xác định và trách nhiệm cũng như là tương tác giữa chúng. Việc phân tích các phần tử này miêu tả gần đúng các thành phần của hệ thống mà được sử dụng trong quá trình thiết kế thành phần dể xác định việc thiết kế các phần tử. Trong thành phần thiết kế, quá trình vi mô tập trung vào việc chọn lọc việc thiết kết các thành phần bằng việc định nghĩa nó trong các lớp mà có thể thực thi trực tiếp bằng các kĩ thuật thực hiện đã chọn. Trong suốt quá trình thiết kế chi tiết, bạn tiếp tục chọn lựa các lớp thông qua làm việc với các nội dung, hành vi và quan hệ của chúng. Quá trình chọn lựa nên dừng lại khi có đủ chi tiết cho việc thiết kế các lớp được thực thi. Bài tập 1) Trình bày quy trình xây dựng phần mềm? 2) Trình bày quy trình phân tích và thiết kế trong xây dựng phần mềm? 44 CHƢƠNG VI: ÁP DỤNG PHÂN TÍCH BÀI TOÁN CỤ THỂ 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông Khởi đầu Ở một số nước tiên tiến thì việc sử dụng hệ thống xe lửa được coi như là phổ biến. Người dân vẫn thích sử dụng hệ thống xe lửa để đi lại những cung đường dài. Hơn nữa, việc sử dụng xe lửa đi lại cũng được coi như là phương tiện an toàn nhất trong các phương tiện đường bộ. Chúng ta có thể thấy rằng hệ thống xe lửa ở các nước phát triển rất mạnh bởi vì nó mang lại hiệu quả kinh tế cao hơn so với các phương tiện khác. Vì vậy, đối với một hệ thống xe lửa cần phải được giám sát chặt chẽ, bởi vì mỗi chuyến sức vận chuyển có nó có thể lên tới hàng trăm thậm chí hàng ngàn người. Trong bài này chúng ta tập phân tích một hệ thống quản lý đường xe lửa bằng việc xác định các yêu cầu và hệ thống tác nhân. Yêu cầu cho hệ thống quản lý tuyến đƣờng xe lửa: Hệ thống quản lý tuyến đường xe lửa có 2 chức năng chính: Dẫn đường và giám sát tuyến đường. Các chức năng liên quan bao gồm lập kế hoạch, dự báo lỗi, theo dõi vết tuyến đường, giám sát giao thông, tránh va chạm, xung đột tuyến đường và ghi lại nhật ký. Từ những chức năng trên, chúng ta có thể đưa ra 8 use cases sau: - Route Train: Thiết lập một kế hoạch, kế hoạch này vạch rõ các tuyến đường mà xe lửa sẽ đi qua. - Plan Traffice: Thiết lập một kế hoạch giao thông mà cung cấp hướng dẫn trong việc triển khai kế hoạch tuyến xe lửa tại một thời gian nhất định và một vùng nhất định. - Monitor Train Systems: Giám sát hệ thống xe lửa cho nhưng chức năng thích hợp. - Predict Failure: Thực hiên phân tích những điều kiện của hệ thống và đưa ra những cảnh báo lỗi liên quan tới kế hoạch vận hành của từng tuyến xe lửa. - Track Train Location: Giám sát vị trí của các xe lửa. - Monitor Traffic: Giám sát tất cả các tuyến xe lửa trong một vùng. - Avoid Collision: Đưa ra biện pháp, có thể là tự động hoặc làm thủ công để tránh những vụ va chạm trên tuyến xe lửa. - Log Maintenance: Đưa ra biện pháp để ghi lại những nhật kí đã thực hiện trên tuyến xe lửa. Những use cases này thiết lập các yêu cầu chức năng cơ bản cho hệ thống quản lý giao thông xe lửa. Chúng cho ta biết hệ thống phải làm những gì đối với người sử dụng nó. Thêm vào đó chúng ta 45 có những yêu cầu không có chức năng và giằng buộc mà tác động lên các yêu cầu được định rõ bởi các use case của chúng ta: Những yêu cầu không có chức năng: - Vận chuyển hành khách và hàng hóa an toàn. - Hỗ trợ tốc độ xe lửa lên tới 250 dặm/giờ. - Cung cấp một hệ thống hoạt động chính xác ở mức 99.99% - Cung cấp các đầy đủ các chức năng, trách dư thừa. - Cung cấp vị trí chính xác của tàu trong vòng 10 yards. - Cung cấp chính xác vận tốc của xe lửa. - Đáp ứng đầu vào trong vòng 10s. Những ràng buộc. - Đáp ứng các tiêu chuẩn quốc gia - Phù hợp về giá thành cả về phần cứng và phần mềm. Bây giờ chúng ta đã có những yêu cầu của bài toán. Quay lại bài toán quản lý hệ thống đường xe lửa của chúng ta. Qua tìm hiểu và phân tích thì chúng ta có thể đưa ra 3 kiểu người dùng khác nhau tác động tới hệ thống: Dispatcher, TrainEngineer, và Maintainer. Ngoài ra hệ thống còn giao tiếp, tương tác với thiết bị ngoài, Navstar GPS. Các tác nhân đóng vai trò sau trong hệ thống. - Dispatcher: Thiết lập tuyến đường xe lửa và theo dõi việc tiến hành của từng xe lửa riêng biệt. - TrainEngineer: Giám sát tình trạng hoạt động của xe lửa. - Maintainer: Giám sát tình trạng duy tri hệ thông xe lửa. - Navstar GPS: Cung cấp dịch vụ định vị dùng để theo dõi tàu hỏa. 46 6.2. Ứng dụng Web: Hệ thống theo dõi kì nghỉ Ngày nay, đối với nhiều doanh nghiệp, sự tự chủ và độc lập của công nhân ngày càng tăng. Mỗi công nhân có thể tham gia vào nhiều dự án vì thế phải phân chia thời gian sao cho hợp lý. Tương ứng với số thời gian làm việc thì đòi hỏi thời gian nghỉ ngơi cũng phải hợp lý. Vì vậy, các nhà quản lý có ít thời gian gặp được công nhân, do đó việc quản lý thời gian làm việc cũng như thời gian nghỉ gặp nhiều khó khăn. Giải pháp được đưa ra là chúng ta xây dựng một hệ thống cho phép theo dõi thời gian làm việc cũng như kì nghỉ của mỗi công nhân. Khởi đầu Yêu cầu của hệ thống là được miêu tả một cách tóm tắt các tài liệu, các đặc tính chủ yếu, các mô hình use case, các đặc tả use case chính và các kiến trúc cần thiết. Yêu cầu: 47 Hệ thống theo dõi kì nghỉ sẽ cung cấp từng nhân viên riêng biệt cùng với khả năng để quản lý thời gian nghỉ của họ, nghỉ việc vì đau ốm, và thời gian nghỉ thương niên. Hệ thống sẽ cung cấp các đặc tính chính sau: - Thực thi một cách linh hoạt cho việc kiểm chứng và xác minh lại thời gian yêu cầu. - Cho phép quản lý phê duyệt. - Cho phép người dùng có thể truy cập lại thời gian trước đó và cho phép yêu cầu được thực hiên đến một năm rưỡi trong tương lai. - Sử dụng e-mail thông báo để yêu cầu quản lý phê duyệt và thông báo cho nhân viên biết trạng thái thay đổi. - Sử dụng phần cứng hiện tại. - Được thực hiện, triển khai mở rộng của mạng nội bộ hiện tại và sử dụng tính năng đăng nhập một lần cho tất cả các cơ chế xác thực. - Lưu giữ lại những bản ghi cho tất cả các giao dịch. - Cho phép người quản lý trực tiếp tặng thời gian nghỉ thêm cho nhân viên. - Cung cấp một dịch vụ giao diện Web cho các hệ thống nội bộ khác truy vấn và đưa ra bất kỳ thời gian nghỉ của nhân viên nào. Mô hình use case mức cao nhất chưa 4 tác nhân và 8 use case được miêu tả ở hình dưới đây: Nhìn vào sơ đồ trên, chúng ta thấy có 4 tác nhân sau; - Employee: là người sử dụng hệ thống chủ yếu. Một nhân viên sử dụng hệ thống để quản lý thời gian nghỉ của họ. 48 - Manager: là một nhân viên cũng sử dụng hệ thống như các nhân viên khác với mục đích tương tự nhưng có thêm một số quyền cao hơn nhân viên bình thường. Có thể quản lý thời gian gian nghỉ của một nhóm nhân viên. - Clerk: Một thành viên của hệ thống quản lý người có đầy đủ các quyền để xem hồ sơ, dữ liệu cá nhân của một nhân viên và chịu trách nhiệm cho tất cả các thông tin về nhân viên. Một thư ký có thể thêm hoặc loại bỏ bất kỳ một bản ghi nào trong hệ thống. - System Admin: Có vai trò chịu trách nhiệm cho hệ thống chạy ổn định, trơn, không bị lỗi Sơ đồ trên còn mô tả các use case chính sau: - Manage Time: Miêu tả các nhân viên yêu cầu và xem thời gian nghỉ như thế nào. - Approve Request: Miêu tả một quản lý đáp ứng yêu cầu của một nhóm như thế nào. - Edit Employee Record: Miêu tả một Clerk của hệ thống chỉnh sửa thông tin của một nhân viên như thế nào. - Manage Locations: Miêu tả một Clerk quản lý các bản ghi như thế nào. - Manage Leave Categories: - Override Leave Records: - Back Up System Logs. Miêu tả Admin sao lưu dữ liệu. Bài tập 1) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Hồ sơ sinh viên? 2) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Kết quả học tập của sinh viên? 49 MỘT SỐ ĐỀ THI MẪU 50 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Đề thi số: Ký duyệt đề: x x Thời gian: 60 phút Câu 1: (2 điểm) So sánh Phân tích thiết kế hệ thống hướng cấu trúc với Phân tích thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Đối tượng là gì? Mối quan hệ giữa các đối tượng? Câu 3: (3 điểm) Trình bày các phương pháp phân loại? Lấy ví dụ? Câu 4: (3 điểm) Trình bày các khối cơ bản trong UML? ----------------------------***HẾT***---------------------------- Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi 51 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Đề thi số: Ký duyệt đề: x x Thời gian: 60 phút Câu 1: (2 điểm) Trình bày những ưu và nhược điểm của Phân tích và thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Lớp là gì? Mối quan hệ giữa các lớp? Câu 3: (3 điểm) Liệt kê các loại biểu đồ (Diagrams) trong UML? Mục đích của từng loại biểu đồ? Câu 4: (3 điểm) Biểu đồ lớp là gì? Trình bày mục đích và cách vẽ biểu đồ lớp trong UML? ----------------------------***HẾT***---------------------------- Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi 52 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN -----***----- THI KẾT THÚC HỌC PHẦN Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x Đề thi số: Ký duyệt đề: x x Thời gian: 60 phút Câu 1: (2 điểm) Đối tượng là gì? Lớp là gì? Trình bày mối quan hệ giữa Lớp và Đối tượng? Cho ví dụ? Câu 2: (2 điểm) Trình bày các khái niệm: Use case, Actor trong UML? Cho ví dụ? Câu 3: (3 điểm) Vòng đời của xây dựng phần mềm? Câu 4: (3 điểm) Biểu đồ tuần tự (Sequence) là gì? Trình bày mục đích và cách vẽ biểu đồ tuần tự trong UML? ----------------------------***HẾT***---------------------------- Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi

Các file đính kèm theo tài liệu này:

  • pdfbaigiangphantichvathietkehethong_7463.pdf
Tài liệu liên quan