Giáo trình Phân tích và thiết kế hướng đối tượng - Nguyễn Thị Thanh Thoan
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Phân tích và thiết kế hướng đối tượng - Nguyễn Thị Thanh Thoan", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
Tài liệu đính kèm:
- giao_trinh_phan_tich_va_thiet_ke_huong_doi_tuong_nguyen_thi.pdf
Nội dung text: Giáo trình Phân tích và thiết kế hướng đối tượng - Nguyễn Thị Thanh Thoan
- 05/05/2012 PHẦN II: PHÂN TÍCH & THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Biên soạn: Nguyễn Thị Thanh Thoan Khoa Công nghệ thông tin Chƣơng 1: Giới thiệu về phƣơng pháp Hƣớng đối tƣợng 1
- 05/05/2012 Ý tƣởng Hướng đối tượng là thuật ngữ thông dụng hiện thời của ngành công nghiệp phần mềm. Các công ty đang nhanh chóng tìm cách áp dụng và tích hợp công nghệ mới này vào các ứng dụng của họ. Thật sự là đa phần các ứng dụng hiện thời đều mang tính hƣớng đối tƣợng. Nhƣng hƣớng đối tƣợng có nghĩa là gì? Ý tƣởng (tt) Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề, theo lối ánh xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực. Tức là chia ứng dụng thành các thành phần nhỏ, gọi là các đối tượng, chúng tương đối độc lập với nhau. Sau đó ta có thể xây dựng ứng dụng bằng cách chắp các đối tượng đó lại với nhau 2
- 05/05/2012 Ý tƣởng (tt) Mỗi đối tượng bao hàm trong nó cả dữ liệu và các xử lý tiến hành trên các dữ liệu này được gọi là bao gói thông tin. Nhờ các thông báo để thực hiện các chức năng lớn hơn các đối tượng độc lập. Ý tƣởng (tt) Một ví dụ đơn giản như: vấn đề rút tiền mặt tại nhà băng. Các thành phần ở đây sẽ là ánh xạ của các đối tượng ngoài đời thực như tài khoản, nhân viên, khách hàng, Và ứng dụng sẽ được sẽ được nhận diện cũng như giải đáp xoay quanh các đối tượng đó. 3
- 05/05/2012 Ƣu điểm Tính tái sử dụng là ưu điểm quan trọng bậc nhất, các đối tượng được tạo ra một lần và có thể được sử dụng nhiều lần sau đó. Vì các đối tượng đã được thử nghiệm kỹ càng trong lần dùng trước đó, nên khả năng tái sử dụng đối tượng có tác dụng giảm thiểu lỗi và các khó khăn trong việc bảo trì, giúp tăng tốc độ thiết kế và phát triển phần mềm. Ƣu điểm (tt) Các đối tượng là độc lập tương đối, vì vậy việc sửa đổi đối tượng này sẽ không gây ảnh hưởng lan truyền sang đối tượng khác Các đối tượng trao đổi thông tin bằng cách truyền thông điệp làm cho việc liên kết giữa các đối tượng lỏng lẻo, có thể ghép nối tuỳ ý, dễ dàng bảo trì, nâng cấp Các đối tượng có thể sử dụng lại do tính kế thừa và có thể mở rộng các đối tượng mà không ảnh hưởng đến các đối tượng khác đang hoạt động. 4
- 05/05/2012 Ƣu điểm (tt) Hệ thống hướng đối tượng dễ dàng được mở rộng thành các hệ thống lớn hơn nhờ tương tác thông qua việc gửi và nhận thông báo. Tăng cường tính mở rộng: việc mở rộng chức năng có thể được thực hiện qua việc tạo lớp con. Vì vậy không ảnh hưởng đến cấu trúc thông tin đã có. Hơn thế nữa phần mềm trở nên linh động hơn hẳn. Phương pháp hướng đối tượng giúp chúng ta xử lý các vấn đề phức tạp trong phát triển phần mềm và tạo ra các thế hệ phần mềm có khả năng thích ứng và bền chắc. Nhƣợc điểm Chưa có những hệ quản trị cơ sở dữ liệu hướng đối tượng chuẩn để hỗ trợ cho việc phân tích thiết kế hướng đối tượng. Sự trừu tượng hóa cao cùng với những khó khăn trong khâu phân tích, thiết kế làm hạn chế việc vận dụng phương pháp này vào thực tế. 5
- 05/05/2012 Giới thiệu về 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 bởi ba nhà khoa học Grady Booch, Ivar Jacobson và James Rumbaugh với mục đích là: 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. Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy. Giới thiệu về UML Điểm khác nhau cơ bản giữa phương pháp (method) và một ngôn ngữ mô hình hoá (modeling language) là: ngôn ngữ mô hình hoá không có một tiến trình (process) hay các câu lệnh (instruction) mô tả những công việc người sử dụng cần làm mà nó bao gồm các ký hiệu – những biểu tượng được dùng trong mô hình – và một tập các quy tắc chỉ cách sử dụng chúng. 6
- 05/05/2012 Giới thiệu về UML Mô hình hóa một hệ thống nhằm mục đích: Hình dung một hệ thống theo thực tế hay theo mong muốn của chúng ta . Chỉ rõ cấu trúc hoặc ứng xử của hệ thống. Tạo một khuôn mẫu hướng dẫn nhà phát triển trong suốt quá trình xây dựng hệ thống. Ghi lại các quyết định của nhà phát triển để sử dụng sau này. Các thành phần của UML Ngôn ngữ UML bao gồm một loạt các phần tử đồ họa (graphic element) có thể được kếp hợp với nhau để tạo ra các biểu đồ. Bởi đây là một ngôn ngữ, nên UML cũng có các nguyên tắc để kết hợp các phần tử đó. Một số những thành phần chủ yếu của ngôn ngữ UML: 1. Hướng nhìn (view): 2. Biểu đồ (diagram): 3. Phần tử mô hình hóa (model element): 4. Cơ chế chung 7
- 05/05/2012 1. Hƣớng nhìn (view ) Chỉ ra những khía cạnh khác nhau của hệ thống cần phải được mô hình hóa. Một hướng nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao gồm một loạt các biểu đồ khác nhau. Qua việc định nghĩa của một loạt các hướng nhìn khác nhau, mỗi hướng nhìn chỉ ra một khía cạnh riêng biệt của hệ thống, người ta mới có thể tạo dựng nên một bức tranh hoàn thiện về hệ thống. Cũng chính các hướng nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn phát triển 2. Biểu đồ (diagram): Là các hình vẽ miêu tả nội dung trong một hướng nhìn. UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống. 8
- 05/05/2012 3. Phần tử mô hình hóa (model element): Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc. Ví dụ như lớp, đối tượng, thông điệp cũng như các quan hệ giữa các khái niệm này, bao gồm cả liên kết, phụ thuộc, khái quát hóa. Một phần tử mô hình thường được sử dụng trong nhiều biểu đồ khác nhau, nhưng nó luôn luôn có chỉ một ý nghĩa và một kí hiệu. 4. Cơ chế chung Cung cấp thêm những lời nhận xét bổ sung, các thông tin cũng như các quy tắc ngữ pháp chung về một phần tử mô hình; Ngoìa ra chúng còn cung cấp thêm các cơ chế để có thể mở rộng ngôn ngữ UML cho phù hợp với một phương pháp xác định (một quy trình, một tổ chức hoặc một người dùng). 9
- 05/05/2012 Những vấn đề đặt ra Đặc điểm của phân tích thiết kế hướng đối tượng là nhìn hệ thống như một tập các đối tượng tương tác với nhau để tạo ra một hành động cho kết quả ở mức cao hơn. Để thực hiện được điều này người ta phải sử dụng hệ thống mô hình các đối tượng với các đặc trưng cơ bản sau : Tính trừu tượng hoá Tính bao gói thông tin Tính mô đun hoá Tính kế thừa Ngày nay, UML là một công cụ được thiết kế có tất cả những tính chất và điều kiện giúp ta xây dựng được các mô hình đối tượng có các dặc trưng nêu trên. Những vấn đề đặt ra Ba vấn đề lớn đặt ra trong giai đoạn phân tích và thiết kế : Làm sao để nhận biết được các lớp đối tượng từ hệ thống thực. Đa số có nhiều lớp đối tượng tương tác với nhau để thực hiện một hành vi lớn hơn. Vậy phải phân công trách nhiệm giữa các đối tượng như thế nào để đảm bảo chất lượng và thời gian thực hiện hành vi của chúng Phân chia công việc nhỏ đến đâu là vừa phải. 10
- 05/05/2012 Đặc trƣng của tiến trình phát triển phần mềm HĐT (RUP) 1. Ca sử dụng điều khiển toàn bộ quá trình phát triển 2. Quá trình phát triển lấy kiến trúc làm trung tâm 3. Tiến trình phát triển là quá trình lặp và tăng dần 1. Ca sử dụng điều khiển toàn bộ quá trình phát triển Ca sử dụng không chỉ là một công cụ để đặc tả yêu cầu của hệ thống mà còn điều khiển quá trình phân tích , thiết kế, cài đặt và kiểm thử : Ca sử dụng phản ánh yêu cầu của hệ thống. Dựa trên mô hình ca sử dụng, người phát triển tạo ra các mô hình phân tích, thiết kế và cài đặt nhằm vào việc thực hiện các ca sử dụng ở các mức khác nhau. Những người kiểm thử kiểm tra các cài đặt để đảm bảo các thành phần được cài đặt thực hiện đúng các ca sử dụng. 11
- 05/05/2012 1. Ca sử dụng điều khiển toàn bộ quá trình phát triển (tt) 2. Quá trình phát triển lấy kiến trúc làm trung tâm Kiến trúc là một cái nhìn thiết kế tổng thể những đặc điểm quan trọng nhất về hệ thống phần mềm khi tạm bỏ qua các chi tiết. Mọi sản phẩm phần mềm đều bao gồm chức năng và hình thức thể hiện. Chức năng tương ứng với ca sử dụng, còn hình thức thể hiện tương ứng với kiến trúc Mỗi ca sử dụng được lựa chọn là sự cụ thể hoá đặc trưng của kiến trúc và được thực hiện dưới dạng các hệ thống con, các lớp và các thành phần chủ yếu. 12
- 05/05/2012 3. Tiến trình phát triển là quá trình lặp và tăng dần Việc phát triển một phần mềm đòi hỏi một số lớn công việc và diễn ra trong một khoảng thời gian. Việc chia công việc thành các phần nhỏ là yêu cầu thiết thực. Mỗi dự án con là một bước lặp và tạo nên một sự tăng trưởng Để đạt hiệu quả, các bước lặp phải được điều khiển: Bước lặp trước hết phải liên quan tới một nhóm các ca sử dụng để mở rộng tính khả dụng của hệ thống khi phát triển. Thứ hai là bước lặp phải giải quyết những rủi ro quan trọng nhất Các giai đoạn và chu trình phát triển phần mềm HĐT Chu trình của một phần mềm có thể được chia thành các giai đoạn như sau: Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study) Phân tích yêu cầu (Analysis) Thiết kế hệ thống (Design of the System) Xây dựng phần mềm (Software Construction) Thử nghiệm hệ thống (System Testing) Thực hiện, triển khai (System Implementation) Bảo trì, nâng cấp (System Maintenance) 13
- 05/05/2012 Các giai đoạn và chu trình phát triển phần mềm HĐT Giai đoạn Phân tích hƣớng đối tƣợng (Object Oriented Analysis - OOA) Là giai đọan phát triển một mô hình chính xác và súc tích của vấn đề, có thành phần là các đối tượng và khái niệm đời thực, dễ hiểu đối với người sử dụng. Trong giai đoạn OOA, vấn đề được trình bày bằng các thuật ngữ tương ứng với các đối tượng có thực. Thêm vào đó, hệ thống cần phải được định nghĩa sao cho người không chuyên Tin học có thể dễ dàng hiểu được. 14
- 05/05/2012 Giai đoạn Phân tích hƣớng đối tƣợng (Object Oriented Analysis - OOA) tt Dựa trên một vấn đề có sẵn, nhà phân tích cần ánh xạ các đối tượng hay thực thể có thực như khách hàng, ô tô, người bán hàng, vào thiết kế để tạo ra được bản thiết kế gần cận với tình huống thực. Mô hình thiết kế sẽ chứa các thực thể trong một vấn đề có thực và giữ nguyên các mẫu hình về cấu trúc, quan hệ cũng như hành vi của chúng. Nói một cách khác, sử dụng phương pháp hướng đối tượng chúng ta có thể mô hình hóa các thực thể thuộc một vấn đề có thực mà vẫn giữ được cấu trúc, quan hệ cũng như hành vi của chúng Thiết kế hướng đối tượng (Object Oriented Design - OOD) Là giai đoạn tổ chức chương trình thành các tập hợp đối tượng cộng tác, mỗi đối tượng trong đó là thực thể của một lớp. Các lớp là thành viên của một cây cấu trúc với mối quan hệ thừa kế. Mục đích của giai đoạn OOD là tạo thiết kế dựa trên kết quả của giai đoạn OOA, dựa trên những quy định phi chức năng, những yêu cầu về môi trường, những yêu cầu về khả năng thực thi, OOD tập trung vào việc cải thiện kết quả của OOA, tối ưu hóa giải pháp đã được cung cấp trong khi vẫn đảm bảo thoả mãn tất cả các yêu cầu đã được xác lập. 15
- 05/05/2012 Thiết kế hướng đối tượng (Object Oriented Design - OOD) tt Trong giai đoạn OOD, nhà thiết kế định nghĩa các chức năng, thủ tục (operations), thuộc tính (attributes) cũng như mối quan hệ của một hay nhiều lớp (class) và quyết định chúng cần phải được điều chỉnh sao cho phù hợp với môi trường phát triển. Đây cũng là giai đoạn để thiết kế ngân hàng dữ liệu và áp dụng các kỹ thuật tiêu chuẩn hóa. Thiết kế hướng đối tượng (Object Oriented Design - OOD) tt Về cuối giai đoạn OOD, nhà thiết kế đƣa ra một loạt các biểu đồ (diagram) khác nhau. Các biểu đồ này có thể đƣợc chia thành hai nhóm chính là Tĩnh và động. Các biểu đồ tĩnh biểu thị các lớp và đối tƣợng, trong khi biểu đồ động biểu thị tƣơng tác giữa các lớp và phƣơng thức hoạt động chính xác của chúng. Các lớp đó sau này có thể đƣợc nhóm thành các gói (Packages) tức là các đơn vị thành phần nhỏ hơn của ứng dụng. 16
- 05/05/2012 Giai đoạn Lập trình hướng đối tượng (Object Oriented Programming - OOP) Giai đoạn xây dựng phần mềm có thể được thực hiện sử dụng kỹ thuật lập trình hướng đối tượng. Đó là phương thức thực hiện thiết kế hướng đối tượng qua việc sử dụng một ngôn ngữ lập trình có hỗ trợ các tính năng hướng đối tượng. Một vài ngôn ngữ hướng đối tượng thường được nhắc tới là C++ và Java. Kết quả chung cuộc của giai đoạn này là một loạt các code chạy được, nó chỉ được đưa vào sử dụng sau khi đã trải qua nhiều vòng quay của nhiều bước thử nghiệm khác nhau. UML và các giai đoạn của chu trình phát triển phần mềm 1. Giai đoạn nghiên cứu sơ bộ: 2. Giai đoạn phân tích: 3. Giai đoạn thiết kế: 4. Giai đoạn xây dựng: 5. Thử nghiệm: 17
- 05/05/2012 1. Giai đoạn nghiên cứu sơ bộ UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của khách hàng (người sử dụng). UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống. Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống (tức là Use case). 1. Giai đoạn nghiên cứu sơ bộ (tt) Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case của UML. Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng: Anh ta hay chị ta chờ đợi điều gì ở phía hệ thống mà không hề để ý đến việc chức năng này sẽ được thực thi ra sao. 18
- 05/05/2012 2. Giai đoạn phân tích Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa đầu tiên (các lớp và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn đề. Sau khi nhà phân tích đã nhận biết được các lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được miêu tả bằng công cụ biểu đồ lớp (class diagram) của UML. 2. Giai đoạn phân tích (tt) Sự cộng tác giữa các lớp nhằm thực hiện các UC cũng sẽ được miêu tả nhờ vào các mô hình động (dynamic models) của UML. Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa. Các lớp kỹ thuật định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giao diện người dùng, cho ngân hàng dữ liệu, cho sự giao tiếp, trùng hợp, v.v , chưa phải là mối quan tâm của giai đoạn này. 19
- 05/05/2012 3. Giai đoạn thiết kế Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thành một giải pháp kỹ thuật. Các lớp mới sẽ được bổ sung để tạo thành một hạ tầng cơ sở kỹ thuật: Giao diện người dùng, các chức năng để lưu trữ các đối tượng trong ngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi và các máy móc khác trong hệ thống, 3. Giai đoạn thiết kế (tt) Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở. Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống. 20
- 05/05/2012 4. Giai đoạn xây dựng Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng đối tượng cụ thể (không nên dùng một ngôn ngữ lập trình hướng chức năng!). Phụ thuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một công việc khó khăn hay dễ dàng. 4. Giai đoạn xây dựng (tt) Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên cố gắng tránh việc ngay lập tức biến đổi các mô hình này thành các dòng code. Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống; Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành code. 21
- 05/05/2012 5. Giai đoạn thử nghiệm Một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thử nghiệm khác nhau. Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp, Thử nghiệm tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), Giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này. Các bƣớc trong PTTK HĐT 1. Lập mô hình nghiệp vụ 2. Xác định yêu cầu HT 3. Phân tích 4. Thiết kế 5. Xây dựng và thử nghiệm 22
- 05/05/2012 CHƢƠNG 2: MÔ TẢ HOẠT ĐỘNG NGHIỆP VỤ Để hiểu đúng và đầy đủ hệ thống, cần xác định phạm vi và chức năng hệ thống bằng cách liệt kê các chức năng mà hệ thống thực hiện, chỉ ra mối quan hệ của nó với môi trường. Tiếp đó tìm các ca sử dụng nghiệp vụ, mô tả các ca sử dụng để hiểu được nội dung các dịch vụ mà hệ thống cần cung cấp. Các công việc này được trợ giúp bằng việc xây dựng mô hình miền và mô hình nghiệp vụ. Lập mô hình nghiệp vụ Mô tả hệ thống nghiệp vụ tốt là điều kiện ràng buộc giữa khách hàng và người phát triển hệ thống. Xác định phạm vi và các chức năng HT cần nghiên cứu bằng cách liệt kê các chức năng mà HT cần thực hiện Chỉ ra mối quan hệ của nó với môi trường thông qua việc sử dụng các chức năng của HT Tìm ra các ca sd nghiệp vụ từ các chức năng của HT mà qua đó con người và các ht khác sd chúng 23
- 05/05/2012 Lập mô hình nghiệp vụ (tt) Mô tả nội dung của các ca sd này để hiểu được nội dung các dịch vụ mà Ht cung cấp. Các công việc này được trợ giúp bằng việc xây dựng mô hình lĩnh vực và mô hình nghiệp vụ Sản phẩm của bƣớc Lập mô hình nghiệp vụ Mô hình lĩnh vực Mô hình nghiệp vụ của HT Bảng các thuật ngữ sử dụng (từ điển giải thích) Xác định các yêu cầu bổ sung. Chú ý: Tuỳ theo từng bài toán cụ thể mà có thể mô tả mô hình lĩnh vực hoặc mô hình nghiệp vụ hoặc không cần thiết. 24
- 05/05/2012 2.1 Mô hình lĩnh vực (mô hình miền) Mô tả các khái niệm quan trọng của HT qua các đối tượng của lĩnh vực nghiệp vụ và liên kết giữa chúng với nhau. Các đối tượng là những “Vật” hay khái niệm trong thực tế, hoặc các sự kiện diễn ra trong môi trường mà Ht làm việc. 2.1 Mô hình lĩnh vực (mô hình miền) (tt) Có 3 dạng dạng lớp đối tượng miền điển hình: 1. Các đối tượng nghiệp vụ: thể hiện những vật được quản lý trong hoạt động nghiệp vụ như: đơn đặt hàng, tài khoản, hợp đồng, 2. Các đối tượng của thế giới thực và khái niệm mà một HT cần theo dõi: giao dịch thanh toán, mua hàng, rút tiền 3. Các sự kiện sẽ hoặc đã xuất hiện : đưa thẻ vào máy, nhấn phím, trả tiền, Mô hình lĩnh vực có thể mô tả bằng biểu đồ lớp của UML 25
- 05/05/2012 2.1 Mô hình lĩnh vực (mô hình miền) (tt) Trong Hệ thống giao dịch tín dụng thường phải ghi nhận và theo dõi danh sách khách hàng. Mỗi khách hàng có một số tài khoản nhất định => Xác định 2 thực thể quan trọng KHACH HÀNG và TÀI KHOẢN 1 * 1 KHACH HANG TAI KHOAN 2.2 Mô hình nghiệp vụ Một mô hình nghiệp vụ được phát triển qua 2 bước: Xây dựng một mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ và các ca sử dụng nghiệp vụ mà các tác nhân sử dụng. Phát triển một mô hình đối tượng nghiệp vụ gồm những người tham gia nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các ca sử dụng nghiệp vụ. Các quy tắc nghiệp vụ và các điều chỉnh khác. 26
- 05/05/2012 2.2 Mô hình nghiệp vụ (tt) Mô hình ca sử dụng nghiệp vụ mô tả các quá trình nghiệp vụ của một tổ chức dưới dạng các ca sử dụng nghiệp vụ và các tác nhân nghiệp vụ tương ứng liên kết với nhau. Mô hình này xem xét một hệ thống nghiệp vụ từ quan điểm người sử dụng và chỉ ra cách thức làm thế nào để hệ thống cung cấp được một giá trị gia tăng cho tác nhân nghiệp vụ của nó. Mô hình ca sử dụng nghiệp vụ được miêu tả bằng các biểu đồ ca sử dụng. 2.3 Bảng các thuật ngữ sử dụng (Từ điển giải thích) Từ điển giải thích thường được dùng để xác định các thuật ngữ quan trọng và thông dụng mà người phát triển HT sử dụng để miêu tả HT. Nó đem lại sự thống nhất việc định nghĩa các khái niệm và các cách diễn đạt một cách nhất quán 27
- 05/05/2012 2.3 Bảng các thuật ngữ sử dụng (Từ điển giải thích) (tt) Theo ví dụ trên Từ điển giải thích: Tài khoản: là một loạt các thông tin dành cho mọt khách hàng, Khách hàng: là những người sở hữ những tài khoản nhất định 2.3 Xác định các yêu cầu bổ sung Các yêu cầu bổ sung là các yêu cầu phi chức năng chủ yếu mà không thể liên kết với một ca sử dụng cụ thể nào, nhưng chúng có ảnh hưởng đến nhiều ca sử dụng hoặc không đến một ca sử dụng nào Các yêu cầu này được sử dụng trong qúa trình phân tích thiết kế 28
- 05/05/2012 2.3 Xác định các yêu cầu bổ sung (tt) Có một số loại yêu cầu phi chức năng sau: Yêu cầu về giao diện Yêu cầu về vật lý đặc tả một đặc điểm vật lý mà một hệ thống phải có Yêu cầu về ràng buộc thiết kế thể hiện những ràng buộc về thiết kế hệ thống Yêu cầu về ràng buộc cài đặt đặc tả hoặc ràng buộc về mã hoá hoặc xây dựng hệ thống 2.3 Ví dụ 29
- 05/05/2012 Phân tích thiết kế hướng đối tượng Chƣơng 3: Xác định các yêu cầu hệ thống Nhiệm vụ chính Sử dụng các ca sử dụng để phát triển mô hình hệ thống cần xây dựng. 30
- 05/05/2012 Nội dung của bước xác định các yêu cầu Tìm các tác nhân và các ca sử dụng Xác định các UC và sắp thứ tự ưu tiên Mô tả mọi ca sử dụng đã được sắp thứ tự Đưa ra các giao diện người dùng thích hợp cho mỗi tác nhân tương tác với các UC Tái cấu trúc lại mô hình UC Sản phẩm của bước xác định các yêu cầu Một phiên bản đầu tiên của Mô hình ca sử dụng (Mô hình UC tổng thể) Mô tả về các ca sử dụng Các bản mẫu giao diện - người sử dụng. 31
- 05/05/2012 Xây dựng mô hình UC 3.1 Xác định tác nhân 3.2 Xác định ca sử dụng 3.3 Quan hệ giữa các UC 3.4 Quan hệ giữa tác nhân và UC 3.1 Xác định tác nhân Tác nhân tham gia vào các UC, kích hoạt hệ thống hoặc nhận kết quả từ hệ thống Tác nhân đại diện cho người hoặc một hệ thống khác sử dụng hay tương tác với hệ thống đang xét. Có 2 loại tác nhân: Tác nhân kích hoạt và tác nhân tham gia sử dụng hệ thống 32
- 05/05/2012 3.1 Xác định tác nhân (tt) Xác định tác nhân dựa vào 2 tiêu chuẩn sau: 1. Phải có ít nhất một người dùng hay một hệ thống cụ thể để thực hiện vai trò của tác nhân dự kiến 2. Những tác nhân khác nhau đóng vai trò trong mối quan hệ với hệ thống phải có sự trùng lặp là tối thiểu nhất. 3.1 Xác định tác nhân (tt) Tên của tác nhân phải là danh từ, và cần phải lựa chọn thích hợp để truyền đạt ý nghĩa tương ứng một cách nhiều nhất. Ký hiệu của tác nhân 33
- 05/05/2012 3.2 Xác định các UC Đ/n: Một UC là một phần chức năng của hệ thống cung cấp cho người dùng để đem lại một kết quả nào đó khi sử dụng nó. Các UC dùng để nắm bắt các các yêu cầu chức năng Tập tất cả các UC sẽ hình thành mô hình UC mô tả đầy đủ chức năng của hệ thống. 3.2 Xác định các UC (tt) Xác định các UC dựa vào mỗi tác nhân sử dụng chúng. Có 2 cách xác định các ca sử dụng 1. Tìm UC từ các tác nhân (kích hoạt or tham gia sd nó) 2. Tìm các UC từ các sự kiện (sự kiện kích hoạt các UC) 34
- 05/05/2012 3.2 Xác định các UC (tt) Khi xác định các UC dựa vào 2 tiêu chuẩn sau: 1. Kết quả có giá trị: Mỗi ca sử dụng thực hiện thành công phải cung cấp một giá trị cho tác nhân sử dụng hệ thống nhằm đạt được một mục tiêu xác định. 2. Tác nhân cụ thể: Việc xác định các ca sử dụng phải cho phép nhận biết một giá trị gia tăng được cung cấp cho một cá nhân người dùng thực hay một hệ thống cụ thể. 3.2 Xác định các UC (tt) Tên của 1 UC được đặt là Động từ + bổ ngữ. Phải được đặt sát với chức năng công việc mà UC thực hiện. Ký hiệu một UC 35
- 05/05/2012 Ví dụ tìm Use Case Nhà băng ABC đưa ra các yêu cầu sau: Một khách hàng có thể muốn gửi tiền vào, rút tiền ra hoặc đơn giản kiểm tra lại số tiền trong tài khoản của anh ta qua máy tự động rút tiền (ATM). Khi đưa tiền vào hoặc rút tiền ra, cần phải ghi ra giấy kết quả những chuyển dịch đã thực hiện và trao tờ giấy này cho khách hàng. Quan sát các chức năng căn bản và các thành phần tham gia, ta thấy có hai tác nhân dễ nhận ra nhất là khách hàng và nhân viên thu ngân. Ví dụ tìm Use Case Qua đó, có thể nhân dạng các Use Case sau: - Gửi tiền vào. - Rút tiền ra. - Kiểm tra mức tiền trong tài khoản - Thực hiện các chuyển dịch nội bộ hệ thống - In kết quả các chuyển dịch đã thực hiện 36
- 05/05/2012 3.2 Mô tả ngắn gọn các UC (tt) Mô tả ban đầu các ca sử dụng ở mức cao có nội dung sau: 3.3 Quan hệ giữa các UC Quan hệ mở rộng Quan hệ sử dụng Quan hệ phụ thuộc Quan hệ kế thừa Quan hệ bao gồm Quan hệ tổng quát hóa 37
- 05/05/2012 3.3 Quan hệ giữa các UC Quan hệ mở rộng: Quan hệ mở rộng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được dùng để mở rộng, đi kèm với từ >. 3.3 Quan hệ giữa các UC (tt) Quan hệ sử dụng được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được sử dụng, đi kèm với >. 38
- 05/05/2012 3.4 Quan hệ giữa tác nhân và UC Tác nhân UC Tác nhân tham gia kích hoạt UC thực Tác nhân hiệnUC Tác nhân nhận đầu ra từ UC Tác nhân UC Tác nhân và UC có tác động qua lại với nhau 3.4 Mô hình ca sử dụng tổng quát Sử dụng các biểu đồ để mô tả mô hình ca sử dụng tổng thể Mô tả các tác nhân, các ca sử dụng tương tác với nhau thế nào và các ca sử dụng liên kết với nhau ra sao. 39
- 05/05/2012 Ví dụ Mô hình ca sử dụng tổng quát Bài toán quản lý nhân sự được chia thành một số các công việc như sau : Quản lý hồ sơ nhân viên Quản lý lương Quản lý các phúc lợi xã hội. Ví dụ Mô hình ca sử dụng tổng quát 40
- 05/05/2012 Ví dụ Mô hình ca sử dụng tổng quát Ví dụ Mô hình ca sử dụng tổng quát 41
- 05/05/2012 Bài tập áp dụng Mỗi nhóm dự trên bài tập của mình sau đó xác định các tác nhân, các UC, các mối quan hệ giữ chúng và xây dựng biểu đồ UC tổng quát Bài toán gửi xe Khi khách đến gửi xe, người coi xe nhận dạng xe theo bảng phân loại, sau đó kiểm tra chỗ trống trong bãi. Nễu chỗ dành cho lại xe đó đã hết thì thông báo cho khách. Ngược lại ghi vé đưa cho khách và hướng dẫn xe vào bãi, đồng thời ghi sổ xe vào. Khi khách lấy xe, người coi xe kiểm tra vé xe xem vé thật hay giả, đối chiếu vé với xe. Nếu vé giả hay không đúng xe thì không cho nhận xe, ngược lại thì viết phiếu thanh toán và thu tiền, đồng thời ghi vào sổ xe ra. Khi khách đến báo có sự cố thì kiểm tra xe trong sổ xe ra và vào để xác minh xe có gửi và đã lấy ra chưa? Nếu không đúng thì không giải quyết, Trong trường hợp ngược lại tiến hành lập biên bản giải quyết và cần thiết thì viết phiếu chi bồi thường cho khách. 42
- 05/05/2012 Phát triển các mô hình ca sử dụng Xuất phát từ mô hình UC tổng quát, tiến hành phát triển từng UC thành các gói biểu đồ UC con tương ứng. Tiến hành xây dựng các gói biểu đồ UC con cho đến khi tất cả các UC đều được mô tả trong biểu đồ. Xây dựng một bài toán cụ thể bằng phƣơng pháp hƣớng đối tƣợng I. Mô tả bài toán II. Lập mô hình nghiệp vụ 1. Lập bảng danh sách các chức năng công việc mà hệ thống cần thực hiện. 2. Mô tả chi tiết các chức năng lá 3. Xây dựng các biểu đồ hoạt động cho mỗi chức năng lớn của bài toán 4. Xây dựng mô hình miền lĩnh vực 43
- 05/05/2012 Xây dựng một bài toán cụ thể bằng phƣơng pháp hƣớng đối tƣợng III. Xác định yêu cầu hệ thống 1. Lập bảng danh sách các tác nhân của bài toán 2. Lập bảng danh sách các ca sử dụng 3. Vẽ biểu đồ UC tổng quát 4. Mô tả khái quát các UC 5. Xây dựng các gói UC chi tiết 6. Mô tả chi tiết các UC trong biểu đồ UC chi tiết Bài ứng dụng cụ thể Bài toán Quản lý nhân sự trong một công ty liên doanh với nước ngoài 44
- 05/05/2012 Phát triển các mô hình ca sử dụng Xuất phát từ mô hình UC tổng quát, tiến hành phát triển từng UC thành các gói biểu đồ UC con tương ứng. Tiến hành xây dựng các gói biểu đồ UC con cho đến khi tất cả các UC đều được mô tả trong biểu đồ. Xây dựng một bài toán cụ thể bằng phƣơng pháp hƣớng đối tƣợng I. Mô tả bài toán II. Lập mô hình nghiệp vụ 1. Lập bảng danh sách các chức năng công việc mà hệ thống cần thực hiện. 2. Mô tả chi tiết các chức năng lá 3. Xây dựng các biểu đồ hoạt động cho mỗi chức năng lớn của bài toán 4. Xây dựng mô hình miền lĩnh vực (nếu có) 45
- 05/05/2012 Xây dựng một bài toán cụ thể bằng phƣơng pháp hƣớng đối tƣợng III. Xác định yêu cầu hệ thống 1. Lập bảng danh sách các tác nhân của bài toán 2. Lập bảng danh sách các ca sử dụng 3. Vẽ biểu đồ UC tổng quát 4. Mô tả khái quát các UC 5. Xây dựng các gói UC chi tiết 6. Mô tả chi tiết các UC trong biểu đồ UC chi tiết Bài ứng dụng cụ thể Bài toán Quản lý nhân sự trong một công ty liên doanh với nước ngoài 46
- 05/05/2012 Phân tích thiết kế hướng đối tượng Chƣơng 4:Phân tích Nhiệm vụ chính Làm mịn dần các yêu cầu đã được nhận từ pha trước (yêu cầu được hiểu chính xác hơn ) và tạo cấu trúc cho chúng (đưa ra cấu trúc cho toàn bộ hệ thống ) 47
- 05/05/2012 4 Mục tiêu cần đạt đƣợc Đặc tả yêu cầu chính xác hơn. Ngôn ngữ sử dụng là ngôn ngữ của nhà phát triển hệ thống, mang tính hình thức hơn. Mô hình yêu cầu được cấu trúc lại dễ hiểu hơn, dễ thay đổi và bảo trì. Mô hình phân tích có thể được xem như một lát cắt đầu tiên của mô hình thiết kế, và là đầu vào cơ bản cho thiết kế và triển khai hệ thống. Nội dung của bƣớc phân tích Cần phân tích mô hình ca sử dụng để tìm ra cách tổ chức các thành phần bên trong của nó nhằm thực hiện mỗi ca sử dụng. Các hoạt động trong pha này: 1. Phân tích kiến trúc 2. Phân tích một ca sử dụng 3. Phân tích một lớp 4. Phân tích một gói 48
- 05/05/2012 Sản phẩm của bƣớc phân tích Kết quả của bước phân tích cho ta một mô hình quan niệm: mô hình phân tích. Mô hình này được thể hiện bằng một hệ thống các gói phân tích ở mức cao. Bao gồm: - Các gói phân tích, các gói dịch vụ và các mối quan hệ phụ thuộc giữa chúng - Các lớp phân tích, các trách nhiệm, các thuộc tính và các mối quan hệ. - Các thực thi ca sử dụng phân tích. 1. Phân tích kiến trúc Xác định các gói phân tích, Xác định các lớp phân tích Xác định các yêu cầu đặc biệt chung 49
- 05/05/2012 Xác định các gói phân tích Khi xác định các gói phân tích có thể dựa trên các tiêu chí sau: Các ca sử dụng cần có để hỗ trợ một quá trình nghiệp vụ cụ thể. Các ca sử dụng cần có để hỗ trợ một tác nhân cụ thể của hệ thống. Các ca sử dụng có quan hệ với nhau bằng các quan hệ tổng quát hoá, mở rộng và bao gồm. Xử lý phần chung các các gói phân tích Tìm thấy và xác định các phần chung trong các gói phân tích (thông qua việc lần vết tới các lớp thực thể lĩnh vực hoặc nghiệp vụ) Đặt phần chung này vào các gói riêng Để các gói khác liên quan phụ thuộc vào gói mới chứa lớp chung này 50
- 05/05/2012 Xác định các gói dịch vụ Gói dịch vụ dùng để mô tả các gói phân tích được sử dụng ở một mức thấp hơn trong sơ đồ phân cấp cấu trúc các gói của hệ thống. Mỗi gói dịch vụ có các tính chất sau: - Chứa một tập các lớp có liên quan với nhau về mặt chức năng - Không thể chia nhỏ hơn - Có thể tham gia vào một hay nhiều thực thi UC - Phụ thuộc rất ít vào các gói dịch vụ khác - Các chức năng của nó được quản lý như một đơn vị riêng biệt Xác định các gói dịch vụ Cách xác định các gói dịch vụ: - Xác định một gói dịch vụ cho mỗi dịch vụ được chọn - XĐ một gói dịch vụ chp mỗi dịch vụ có thể trở thành tùy chọn cho nhiều UC. 51
- 05/05/2012 Xác định các mối quan hệ phụ thuộc giữa các gói Mục tiêu là tìm ra các gói phân tích tương đối độc lập với các gói khác, tức là chúng được ghép nối lỏng lẻo với nhau nhưng có tính kết dính cao bên trong. Xác định các lớp thực thể hiển nhiên Ta có thể xác định các lớp thực thể quan trọng nhất dựa trên các lớp miền hoặc các thực thể nghiệp vụ đã được xác định trong quá trình nắm bắt các yêu cầu. Mỗi lớp thực thể này có thể đưa vào một gói riêng Không nên xác định quá nhiều lớp mà chỉ phác thảo ban đầu chỉ gồm các lớp có ý nghĩa về mặt kiến trúc là đủ. 52
- 05/05/2012 Xác định các yêu cầu đặc biệt chung Một yêu cầu đặc biệt là một yêu cầu nảy sinh ra trong quá trình phân tích và việc nắm bắt nó là quan trọng. Các yêu cầu kiểu này có thể là: - Tính lâu bền (cần lưu trữ), - Sự phân bố và tính tương tranh, - Các điểm đặc trưng về an toàn, dung sai về lỗi, quản lý giao dịch Ví dụ Xác định gói phân tích: Trong hệ thống “Giao dịch tín dụng” xác định được 3 UC: Rút tiền, chuyển tiền và Gửi tiền => vì 3 UC này tương đối độc lập nên có thể để trong 3 gói 53
- 05/05/2012 Ví dụ Xác định gói dịch vụ: Cả 3 gói trên đều có 1 lớp chung là lớp thực thể Tài khoản và do đó cần tạo cho nó một gói riêng đặt tên là Quản lý tài khoản Ví dụ Xác định các mối quan hệ giữa các gói: 54
- 05/05/2012 2. Phân tích một UC Xác định các lớp phân tích Mô tả tương tác giữa các đối tượng phân tích Mô tả luống sự kiện phana tích Nắm bắt các yêu cầu đặc biệt Xác định các lớp phân tích Lớp phân tích thể hiện một sự trừu tượng của một hoặc nhiều lớp và/hoặc hệ thống con. Có ba kiểu lớp phân tích cơ bản sau: lớp biên, lớp điều khiển và lớp thực thể. 55
- 05/05/2012 Xác định các lớp phân tích Lớp biên (boundary class) được sử dụng để mô hình hóa sự tương tác giữa hệ thống và các tác nhân của nó. Lớp thực thể (entity class) được dùng để mô hình hóa các thông tin tồn tại lâu dài và có thể được lưu trữ. Nó thường thể hiện các cấu trúc dữ liệu lôgic và góp phần làm rõ về các thông tin mà hệ thống phải thao tác trên chúng. Lớp điều khiển (control class) thể hiện sự phối hợp, sắp xếp trình tự, các giao dịch, sự điều khiển của các đối tượng và thường được sử dụng để gói lại các điều khiển liên quan đến một ca sử dụng cụ thể. Các khía cạnh động của hệ thống được mô hình hóa qua các lớp điều khiển. Xác định các lớp phân tích Để xác định các lớp phân tích theo các cách sau: - Xác định các lớp thực thể bằng việc nghiên cứu mô tả UC và xem xét thông tin nào cần lưu trữ và cần thao tác - Xác định lớp biên dựa vào sự tương tác đối với mỗi tác nhân - Xác định lớp điều khiển chịu trách nhiệm quản lý và đk phối hợp hoạt động thực thi UC - Nhóm các lớp phân tích tham gia một UC vào biểu đồ lớp và sử dụng biểu đồ này để chỉ ra mối quan hệ được sử dụng trong thực thi UC. 56
- 05/05/2012 Ví dụ Tìm các lớp thực thi trong UC Rút tiền Ví dụ Xây dựng biểu đồ lớp mô tả quan hệ liên kết giữa các lớp thực thi UC 57
- 05/05/2012 Bài tập Hãy xác định các lớp phân tích cho ca sử dụng Gửi tiền và chuyển tiền Mô tả các tương tác giữa các đối tượng phân tích Mô tả cách thức mà các đối tượng phân tích tương tác với nhau. Đó chính là hành vi của hệ thống Mô tả những công việc mà hệ thống thực hiện Mô tả hành vi hệ thống bằng biểu đồ tuần tự và biểu đồ cộng tác. 58
- 05/05/2012 Biểu đồ cộng tác Biểu đồ cộng tác tập trung vào việc tìm kiếm các yêu cầu và các trách nhiệm của các đối tượng phân tích. Sự tương tác giữa các đối tượng được thể hiện bằng đường liên kết và các thông báo ghi bên cạnh các đối tượng này Một biểu đồ cộng tác xuất phát từ một điểm khởi đầu của luồng sự kiện UC, sau đó đi theo luồng từng bước và xác định xem đối tượng phân tích nào và các tương tác nào cần thiết để thực thi UC đó. Biểu đồ cộng tác Khi xây dựng biểu đồ cộng tác cần lưu ý: Một UC được gọi bằng một thông báo từ một tác nhân chuyển tới một đối tượng biên Mỗi lớp phân tích được xác định trong bước trước phải có ít nhất một đối tượng phân tích tham gia vào một biểu đồ cộng tác Các kết nối trong biểu đồ là thể hiện của các liên kết giữa các lớp phân tích Cần tập trung vào các quan hệ giữa các đối tượng và các yêu cầu cho từng đối tượng cụ thể Kiểm soát được mọi quan hệ cần thiết cho thực thi UC 59
- 05/05/2012 Xác định các hành vi của hệ thống và xây dựng biểu đồ cộng tác cho UC Rút tiền Bài tập Xây dựng biểu đồ cộng tác cho UC Gửi tiền và Chuyển tiền 60
- 05/05/2012 Biểu đồ tuần tự Mô tả một UC theo thứ tự thực hiện các sự kiện được phát sinh bởi các tác nhân ngoài và các sự kiện bên trong hệ thống Để xây dựng biểu đồ tuần tự cần xác định các thao tác hệ thống mà một tác nhân yêu cầu Biểu đồ tuần tự Các bước xây dựng biểu đồ tuần tự: Xác định từng tác nhân thao tác trực tiếp với hệ thống Từ tiến trình các sự kiện cơ bản của UC, xác định các sự kiện hệ thống được phát sinh bởi mỗi tác nhân 61
- 05/05/2012 Ví dụ về xây dựng biểu đồ tuần tự cho UC Rút tiền Bài tập Xây dựng biểu đồ tuần tự cho UC Gửi tiền và Chuyển tiền 62
- 05/05/2012 Điểm khác nhau cơ bản giữa biểu đồ tuần tự và biểu đồ cộng tác Biểu đồ cộng tác tập trung vào việc tìm kiếm các yêu cầu và trách nhiệm của các đối tượng. Biểu đồ tuần tự tập trung vào chuỗi tương tác theo thời gian. Mô tả luồng sự kiện phân tích Bên cạnh các biểu đồ, đặc biệt là biểu đồ cộng tác, ta cần bổ sung thêm các mô tả bằng văn bản để các biểu đồ trở nên dễ hiểu và dễ dùng hơn. 63
- 05/05/2012 Nắm bắt các yêu cầu đặc biệt Ta cần nắm bắt các yêu cầu (phi chức năng) cần cho việc thực thi một ca sử dụng mà đã được xác định trong phân tích nhưng phải được xử lý trong thiết kế và thực thi. VD: yêu cầu đặc biệt trong UC Rút tiền: Thời gian truy nhập hệ thống không chậm quá 1 giây Giao dịch thành công tiền phải được trả không quá 10 giây Mọi công việc thực hiện phải có thông báo Việc rút tiền phải diễn ra 24/24 giờ 4. Phân tích một lớp . Xác định trách nhiệm của lớp . Xác định các thuộc tính . Xác định các liên kết và các kết hợp . Xác định các lớp tổng quát hoá . Nắm bắt các yêu cầu đặc biệt của lớp phân tích 64
- 05/05/2012 Xác định trách nhiệm của lớp Các trách nhiệm của một lớp được xác định bằng cách tổ hợp các vai trò mà lớp đó đảm nhiệm dựa trên biểu đồ cộng tác và mô tả luồng sự kiện giữa chúng. Ví dụ 65
- 05/05/2012 Xác định các thuộc tính Một thuộc tính đặc tả một tính chất của một lớp phân tích và nó thường được gợi ý và đòi hỏi các trách nhiệm của lớp Tên của thuộc tính phải là một danh từ Xác định các thuộc tính Các hướng dẫn khi xác định thuộc tính: Kiểu chỉ mang tính khái niệm Nếu có một thuộc tính không thể chia sẻ cho nhiều đối tượng thì nó phải thuộc lớp riêng Các thuộc tính của lớp thực thể thường rõ ràng Các thuộc tính của lớp biên thường là các hạng mục thông tin mà tác nhân thao tác Các lớp đk có ít thuộc tính . 66
- 05/05/2012 Xác định các liên kết và kết hợp Số lượng các mối quan hệ giữa các lớp phải được tối thiểu hoá. Đó là các mối quan hệ cần phải tồn tại để đáp ứng lại các đòi hỏi từ các thực thi ca sử dụng khác nhau. Số lượng các đối tượng của hai lớp tham gia vào liên kết cũng rất quan trọng. Hai lớp có thể có nhiều mối liên kết. Ngược lại, một lớp có thể liên kết với nhiều lớp khác nhau. VD về xác định các liên kết và kết hợp 67
- 05/05/2012 Nắm bắt các yêu cầu đặc biệt của lớp phân tích Nắm bắt các yêu cầu khác sẽ phục vụ cho thiết kế sau này VD như về quy mô, dung lượng, số bản ghi tối đa, tần số truy nhập, 5. Phân tích một gói Mục đích của việc phân tích một gói nhằm: Đảm bảo gói phân tích càng độc lập đối với các gói khác nếu có thể. Đảm bảo gói phân tích hoàn thành mục đích của nó là thực thi những lớp miền hoặc các ca sử dụng nào đó. Mô tả các mối quan hệ phụ thuộc sao cho có thể ước tính được hiệu ứng của các thay đổi sau này. 68
- 05/05/2012 5. Phân tích một gói Một số nguyên tắc chung phân tích một gói: – Xác định và duy trì các mối quan hệ phụ thuộc giữa hai gói có chứa các lớp liên kết với nhau. – Mỗi gói chứa các lớp đúng. – Hạn chế tối đa các mối quan hệ phụ thuộc tới các gói khác bằng cách bố trí các lớp chứa trong một gói sang gói khác nếu nó quá phụ thuộc vào các gói khác. Nôi Dung báo cao I. Phát biêu bai toán II. Xác đinh yêu câu 1. Bảng Danh sách chức năng 3. Xây dưng mô hinh nghiêp vu III. Mô tả hoạt đông nghiêp vu 69
- 05/05/2012 Nôi Dung báo cao III. Mô tả hoạt đông nghiêp vu 1. Bảng DS các tác nhân 2. Danh sách các uc 3 .mô hinh uc tông Quát 4. mô hinh uc chi tiết Nôi Dung báo cao III. Phân tich 1.Xây dưng biểu đô tuần tự cho từng uc 2. Xây dưng biêu đô công tác cho tưng uc 3. XD biêu đô công tác Tông quát 70
- 05/05/2012 Nôi Dung báo cao III. Thiết kế 1. Xây dưng biêu đô lơp cho tưng uc 2. XD biêu đô lơp Tông quát 3. Thiết kế csdl vât lý 4. thiết kế môt sô giao diên ct Ôn tập Phần I: Phân tích thiết kế hướng cấu trúc Phần II: Phân tích thiết kế hướng đối tượng Đề cương ôn tập 71