Bài giảng Phân tích và Thiết kế hệ thống - Chương 3: Mô hình hóa các khái niệm sử dụng mô hình domain

Chương 3Mô hình hóa các khái niệm sử dụng mô hình domainMô hình hóa phạm vi bài toán (domain modeling)Mục tiêu của mô hình hóa là để hiểu rõ hệ thống làm việc như thế nàoPhân tích yêu cầu là xác định cách mà người dùng sẽ tương tác với hệ thống (hành vi bên ngoài)Domain model xác định cách mà các yếu tố bên trong của hệ thống tương tác với nhau (hành vi bên trong) để thực hiện các hành vi bên ngoài.Mô hình hóa phạm vi bài toán (domain modeling)Mô hình hóa phạm vi bài toán dựa trên các yếu tốHiểu biết về các hoạt động mà hệ thống phải thực hiện (từ phân tích yêu cầu, ví dụ, use case)Tìm hiểu về phạm vi bài toán (domain)Kiến thức cơ bản về thiết kế phần mềmNhững kinh nghiệm về thiết kế phần mềm của những dự án trướcUse Cases và Domain ModelTrong phân tích use case, hệ thống được xem như một hộp đen “black box”, xem xét các hành vi bên ngoài hệ thốngTrong phân tích domain, hệ thống được xem như một hộp trong suốt “transparent box”, xem xét cấu trúc bên trong hệ thốngDomain modelDomain model là một đại diện trực quan của các lớp khái niệm (conceptual classes), các đối tượng và mối quan hệ giữa chúng trong phạm vi bài toán.Domain model là thành phần quan trọng nhất được tạo ra trong giai đoạn phân tích hướng đối tượng, là cơ sở cho việc thiết kế phần mềmDomain model còn được gọi là conceptual models, domain object model hoặc analysis object model.Domain model trong UMLTrong UML, domain model được biểu diễn bằng một tập hợp các sơ đồ lớp (class diagram), trong đó chỉ hiển thị: Đối tượng hoặc các lớp khái niệm Các mối quan hệ giữa các lớp khái niệm Các thuộc tính của các lớp khái niệmDomain model trong UMLVí dụ: domain model của một phần trong hệ thống ATMCác bước xây dựng Domain ModelTìm các lớp khái niệm trong phạm vi bài toánChuẩn bị từ điển dữ liệuTìm các mối quan hệ giữa các lớp hoặc các đối tượng.Xác định lượng số (Multiplicity) của loại đối tượng tham gia vào mối quan hệTìm các thuộc tính của các đối tượng.Tổ chức và đơn giản hóa các lớp bằng cách sử dụng tính kế thừa.Lớp khái niệm - Conceptual ClassesLớp khái niệm là những ý tưởng, sự vật hoặc đối tượng trong phạm vi bài toán.Lớp khái niệm có 3 phần:Symbol: biểu diễn bằng hình chữ nhậtIntension: Định nghĩa lớp khái niệm (conceptual class).Extension: thể hiện của một lớp. Lớp khái niệm - Conceptual ClassesMột lớp là một tập các đối tượng có cùng các thuộc tính, hành vi/trách nhiệm, mối quan hệ và ngữ nghĩa.Xác định các đối tượng được sử dụng để xác định các lớp khái niệm trong phạm vi bài toán.Lớp khái niệm có thể là:Các đối tượng doanh nghiệp (Business objects)Đối tượng trong thế giới thực (Real world objects)Những sự kiện xãy ra (Events that transpire)Cách xác định lớp khái niệmCó 2 cách để xác định các lớp khái niệm:Xác định các cụm danh từSử dụng một danh mục lớp khái niệm.Xác định cụm danh từCụm danh từ có thể được xác định từ các nguồn:Mô tả phạm vi bài toánTrong đặc tả use case, tìm kiếm các cụm danh từ có liên quan.Danh mục các thuật ngữCụm danh từ có thể là lớp khái niệm cũng có thể là thuộc tínhNếu cụm danh từ lưu thông tin trạng thái hoặc nó có nhiều hành vi, thì đó là một lớpNếu chỉ là một số hoặc một chuỗi, thì đó nó có thể là một thuộc tínhXác định cụm danh từVí dụ: mô tả một phần hoạt động rút tiền từ ATMATM kiểm tra số thẻ của khách hàng và mã PIN.Nếu đúng, thì khách hàng có thể kiểm tra số dư trong tài khoản, và rút tiền mặt.Nếu kiểm tra số dư, thì ATM hiển thị số dư trong tài khoản.Nếu rút tiền mặt thì ATM yêu cầu khách hàng nhập số tiền, ATM kiểm tra số tiền rút < số dư trong tài khoản. Nếu thỏa thì ATM xuất tiền mặt và cập nhật lại số dưATM in số dư trong tài khoản của khách hàng trên biên nhận.Sử dụng danh mục lớp khái niệmDanh mục lớp khái niệmVí dụĐối tượng vật lý hoặc hữu hìnhKhách hàng, máy ATMThông số kỹ thuật, hoặc mô tả sự vậtThông số kỹ thuật sản phẩm, Mô tả chuyến bay Nơi chốnCửa hàng, sân bayGiao dịch Giao dịch rút tiền, thanh toánVai trò của con ngườiThủ quỹ, phi côngHệ thống máy tính hoặc điện tửHệ thống chức thực thẻ thanh toán, hệ thống kiểm soát không lưuDanh mụcDanh mục sản phẩm, danh mục phòng banTổ chứcBộ phận bán hàng, hãng hàng khôngXác định lớp khái niệm ứng viênTừ việc phân tích các cụm danh từ và danh mục các lớp khái niệm, tạo ra danh sách lớp khái niệm ứng viên, bằng cách:Loại bỏ các cụm danh từ trùng lắp, không liên quan đến vấn đề đang phân tíchXem xét việc rút gọn các lớp dựa trên tính kế thừaTừ điển dữ liệuChuẩn bị một từ điển dữ liệu cho tất cả các yếu tố trong mô hình bao gồm:Mô tả phạm vi của các lớp trong các vấn đề hiện tại, gồm tất cả các giả định hoặc ràng buộc.Mô tả các mối quan hệ, các thuộc tính, các hoạt động và các giá trị kiểu liệt kêTừ điển dữ liệuTài khoản (Account)ATM Ngân hàng (Bank)Thẻ rút tiền (CashCard)Số dưTên ngân hàng Mã PINNhân viên NHKhách hàng Giao dịch Biên laiNgày thực hiện giao dịchLoại giao dịchVí dụ: Từ điển dữ liệu trong hệ thống ATMXác định lớp khái niệm ứng viênTừ việc phân tích các cụm danh từ và danh mục các lớp khái niệm, tạo ra danh sách lớp khái niệm ứng viên, bằng cách:Loại bỏ các cụm danh từ trùng lắp, không liên quan đến vấn đề đang phân tíchXem xét việc rút gọn các lớp dựa trên tính kế thừaXác định lớp khái niệm ứng viênBiểu diễn lớp trong UML: có dạng hình chữ nhật có 3 ngăn chứa 3 loại thông tin:Tên lớpDanh sách các thuộc tínhDanh sách các hoạt động (hành vi – phương thức)Tên lớpThuộc tínhHành viXác định lớp khái niệm ứng viênTài khoản (Account)ATM Ngân hàng (Bank)Thẻ rút tiền (CashCard)Nhân viên NHKhách hàng Giao dịch Biên laiVí dụ: các lớp khái niệm ctrong hệ thống ATMXác định lớp khái niệm ứng viênBiểu diễn các lớp trong domain model – chỉ có tên lớpTìm mối quan hệCó thể tìm mối quan hệ giữa những đối tượng hoặc khái niệm dựa vào danh mục các loại mối quan hệ sau:Danh mụcVí dụA là thành phần vật lý của BMáy bay – Cánh máy bayA là thành phần logic của BMôn học – Học kỳA được chứa trong BHành khách - máy bayA là thành phần logic chứa trong BSản phẩm – Danh mục sản phẩmChuyến bay – lịch trình chuyến bayA là một chi tiết trong giao dịch với BGiao dịch – nhật ký giao dichHóa đơn – chi tiết hóa đơnTìm mối quan hệDanh mụcVí dụA là thành phần của BNgân hàng – Nhân viên ngân hàngPhi công – hãng hàng khôngA sử dụng hoặc quản lý BThủ quỹ- sổ sách, Phi công - Máy bayA giao tiếp với BKhách hàng - Thu ngânA có liên quan đến giao dịch với B Khách hàng - Thanh toán, hành khách- VéA là thuộc sở hữu của BMáy tính tiền– Cửa hàng, Máy bay- hãng hàng khôngA là một sự kiện liên quan đến BBán hàng - Khách hàng, Bán hàng - Cửa hàngKhởi hành - Chuyến bayTìm mối quan hệBài tập: Tìm các mối quan hệ trong domain của hệ thống ATMKhách hàng - ?Nhân viên ngân hàng - ?ATM - ?Thẻ ATM - ?Roles Quan hệ giữa hai lớp được ký hiệu trong UML là một đường nối 2 lớp, tại hai đầu của đường nối thường được gán Role. Role bao gồm một trong các tùy chọn sau:Lượng số của các đối tượng tham gia (multiplicity)Tên của của quan hệĐiều hướng (navigability)Xác định lượng số tham gia (Multiplicity)Multiplicity: là số đối tượng của một lớp tham gia vào mối quan hệ.Với mỗi quan hệ, có 2 thông số multiplicity được tạo ở hai đầu của mối quan hệ.Các loại chỉ số tham gia của các đối tượng trong mối quan hệXác định lượng số tham gia (Multiplicity)Ví dụ: trong hệ thống ATMMột khách hàng có thể có nhiều thẻ ATM, một thẻ ATM chỉ thuộc 1 khách hàngMột thẻ ATM ứng với một tài khoản thuộc một ngân hàng, một ngân hàng có thể có nhiều thẻ rút tiền.Một nhân viên NH thuộc một ngân hàng, một ngân hàng có thể có nhiều nhân viên.Một ngân hàng có thể có nhiều ATM, một ATM chỉ thuộc 1 ngân hàngXác định lượng số tham gia (Multiplicity)Ví dụ: Biểu diễn mối quan hệ và lượng số tham gia của các lớp trong domain model của hệ thống ATMBài tậpHệ thống đặt vé máy bay, được mô tả như sau:Một chuyến bay (flight) có thể liên quan đến nhiều chặng dừng (stopovers) tại sân bay.Một điểm dừng có thời gian đến (arrival time) và thời gian khởi hành (departure time)Bài tậpHãy xác định multiplicity trong mô domain model sau:Tên của mối quan hệTên của mối quan hệ dựa trên định dạng TypeName-VerbPhrase-TypeName, là một chuỗi có thể đọc được và mang ý nghĩa trong ngữ cảnh của domain model.Ví dụ: Tên của mối quan hệLoại quan hệ giữa các lớpQuan hệ kết hợp – Association: có 2 loạiAggregation CompositionQuan hệ khái quát và kế thừa - GeneralizationQuan hệ giữa các lớpQuan hệ kết hợp loại Aggregation Một lớp là danh mục hoặc chứa các lớp khácCòn gọi là quan hệ “Has a” Chu trình sống của Lớp được chứa không phụ thuộc vào Lớp chứa. Nếu Lớp chứa bị hủy thì các Lớp được chứa vẫn tồn tạiKý hiệu trong UML Ví dụ: Quan hệ giữa các lớpQuan hệ kết hợp loại CompositionLà một quan hệ kết hợp mạnh “owns a” Một lớp bao gồm một danh mục các lớp khácChu trình sống của Lớp được chứa phụ thuộc vào Lớp chứa.Nếu hủy Lớp chứa thì các Lớp được chứa sẽ bị hủy theo.Ký hiệu trong UMLVí dụ: Quan hệ giữa các lớpQuan hệ tổng quát và kế thừa - Generalization Những đặc điểm chung của các lớp được đặt trong lớp cha gọi là lớp tổng quát, mỗi lớp con chỉ chứa những đặc riêng của nó. Quan hệ giữa lớp cha và lớp con gọi là quan hệ tổng quátKý hiệu trong UMLVí dụ: Xác định thuộc tính của lớpThuộc tính:Mô tả trạng thái của các đối tượng tại một thời điểmLà các giá trị dữ liệu thuần túy.Thuộc tính phải chứa thông tin của hệ thống đang xây dựngCó kiểu dữ liệu nguyên thủy (number, string, )Xác định thuộc tính của lớpPhân biệt Lớp (class) và thuộc tính (attribute) Nếu một thực thể có thuộc tính mô tả chính nó thì đó là một LớpNếu một thực thể không có thuộc tính mô tả chính nó thì nó chính là một thuộc tính.Biểu diễn thuộc tính trong domain modelThuộc tính của lớp được đặt trong ngăn thứ hai của ký hiệu Lớp trong UMLTên lớpThuộc tínhXác định thuộc tính của lớpThuộc tính thường có các kiểu dữ liệu nguyên thủy:Boolean, Date, Number, String (Text), Time Ví dụ: Tài khoản, có thông tin mô tả: Số tài khoản, số dư  Tài khoản là một Lớp, và Số tài khoản, số dư là thuộc tínhXác định thuộc tính của lớpLưu ý:Không sử dụng thuộc tính để duy trì mối quan hệ giữa các lớpKhông có thuộc tính khóa ngoại trong domain modelCác lỗi khi xác định lớp khái niệmLỗi thường gặp khi tạo domain model là sự nhầm lẫn giữa lớp khái niệm và thuộc tính.Ví dụ: domain model của hệ thống đặt vé máy bay. Điểm đến (destination) là một thuộc tính của chuyến bay (Flight), hay là một lớp khái niệm Sân bay (Airport) riêng biệt?Các lỗi khi xác định lớp khái niệmNguyên tắc: Nếu một sự vật trong thế giới thực không được xem như một số hoặc text, và có nhiều thông tin mô tả thì đó là lớp khái niệm. Ngược lại, thì đó là thuộc tínhVí dụ: Điểm đến (destination) không là thuộc tính mà là một lớp khái niệm Sân bay (Airport) riêng biệtBài tậpTừ mô tả hệ thống máy rút tiền tự động ATM, hãy vẽ sơ đồ lớp ở mức phân tích, gồm:Các lớp khái niệmThuộc tính của lớpMối quan hệ giữa các lớp Xác định lượng số tham gia của các đối tượng vào mối quan hệ giữa các lớpCác quy tắc hoạt động trong sơ đồ use case(OPERATION CONTRACTS )Các quy tắc (Contracts)Sơ đồ Use case mô tả đầy đủ các hành vi của hệ thống, nhưng không mô tả chi tiết.Domain model: mô tả trực quan các lớp khái niệm hoặc các đối tượng trong phạm vi của vấn đề đan gquan tâm.Các quy tắc (contracts) mô tả chi tiết hành vi của hệ thống về những thay đổi trạng thái của các đối tượng trong Domain Model sau khi hoạt động của hệ thống được thực hiện.Các quy tắc hoạt động giúp xác định hành vi của hệ thốngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền44Các quy tắc (Contracts)Các quy tắc dùng định nghĩa các hoạt động của hệ thốngCác hoạt động mà trong đó, hệ thống được xem như một hộp đen, xử lý các sự kiện tương tác với hệ thống thông qua giao diện chung.Ví dụ: quy tắc của hoạt động rút tiền qua ATMBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền45Các phần trong quy tắcHoạt động (Operation): tên của hoạt động và các tham sốTham chiếu (References): các use case mả hoạt động này có thể xãy ra Tiền điều kiện (Preconditions): Trạng thái của hệ thống hoặc các đối tượng trong domain model trước khi hoạt động được thực hiệnHậu điều kiện (Postconditions):Trạng thái của các đối tượng trong Domain Model sau khi hoạt động được thực thi thành công. Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền46Các phần trong quy tắcLưu ý:Các hậu điều kiện mô tả những thay đổi trạng thái của các đối tượng trong Model Domain. Sự thay đổi trạng thái của Domain Model bao gồm:Các phần tử được tạo raCác mối quan hệ được hình thành hoặc phá hủyCác thuộc tính thay đổi.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền47Các phần trong quy tắcVí dụ: quy tắc của hoạt động rút tiền từ ATMHoạt động: rút tiền, tham số: Số PIN, số tiền cần rútTham chiếu: use case rút tiền bằng thẻ ATMTiền điều kiện: Nhập số PIN thành công, tài khoản có đủ tiền, ATM phải có tiền.Hậu điều kiện của hoạt động rút tiền:Số tiền trong tài khoản giảm một số = số tiền rút, (trạng thái của tài khoải bị thay đổi)Một biên lai giao dịch được tạo ra (thực thể mới), liên quan đến Tài khoản và ATM. (domain model thay đổi)Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền48Cập nhật domain model từ các quy tắcTrong quá trình tạo các quy tắc hoạt động của hệ thống, sẽ khám phá các lớp khái niệm, thuộc tính, hoặc các mối quan hệ mới trong domain model. Hậu điều kiện trong các quy tắc thường hỗ trợ việc phân tích, chi tiết và chính xác.Từ các mô tả chi tiết trong các quy tắc, việc cập nhật domain model được lặp nhiều lần trong suốt giai đoạn phân tích.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền49Sử dụng quy tắcNếu Use case model chứa đầy đủ tất cả các yêu cầu chức năng chi tiết để cung cấp cho việc thiết kế hệ thống thì không cần các quy tắc.Quy tắc được dùng trong những tình huống mà các trạng thái của các yêu cầu thay đổi chi tiết và phức tạp khó nắm bắt trong use case.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền50Sử dụng quy tắcVí dụ: trong hệ thống đặt vé của hãng hàng không, hoạt động đặt vé addNewReservation có độ phức tạp cao liên quan đến tất cả các đối tượng trong domain model:Thay đổi trạng thái của domain modelTạo thêm đối tượng trong domain modelTrong trường hợp này cần phải viết các quy tắc để mô tả chi tiết hoạt động đặt vé để xác định các đối tượng liên quan.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền51Các quy tắc và các hoạt động (Contracts, Operations)Các quy tắc (Contract)Tiền điều kiện và hậu điều kiện trong quy tắc dùng để xác định hoạt động của các đối tượng.Hoạt động (Operation): Những yêu cầu hoặc truy vấn mà một đối tượng có thể được gọi để thực hiện