Phân tích và thiết kế hướng đối tượng (Object Oriented System Analysis and Design)

động song song Nốt kết hợp (join node) Dùng để kết hợp các luồng hoạt động song song 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) Xây dựng biểu đồ hoạt động: Xác định phạm vi và ngữ cảnh của quá trình kinh doanh rồi đặt cho biểu đồ hoạt động 1 tiêu đề phù hợp Xác định các hoạt động, luồng điều khiển, luồng đối tượng diễn ra giữa các hoạt động. Xác định các quyết định lựa chọn trong quá trình kinh doanh Xác định khả năng thực hiện song song của các hoạt động (nếu có). Vẽ biểu đồ hoạt động 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) VD: CD selections Internet Order System – Functional requirements: Maintain CD Information 1.1…… 1.2….. 1.3….. Maintain CD marketing information 2.1…. 2.2…. 2.3…. Place CD Orders 3.1 Search CDs from “CD Selection” web site; 3.2 Place orders; 3.3…… Maintain Orders 4.1….. 4.2… 4.3 Place Instore Hold: If ordered CDs are available in a near store, the CDs are on hold and to be picked up in the store 4.4. Place Special Order: If ordered CDs is not available in a near store, the ordered CDs will be sent to a near store and email to the customer when it is available in the near store 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) VD: CD selections Exercise: Create the activity diagram for Internet Order System Analysis: Main activities: Maintain CD Information, Maintain CD marketing information, Place CD Orders, Maintain ordered CDs Control flows: Three main parallel processes: Maintain CD Information Maintain CD marketing information Place CD Orders -> Maintain ordered CDs in which a decision needs to be made related to placing instore hold or placing special order 4.2.2 Mô hình quá trình kinh doanh bằng biểu đồ hoạt động (activity diagrams) VD: CD selections 4.2.3 Mô tả ca sử dụng Một ca sử dụng miêu tả các hoạt động do người sử dụng hoặc các hệ thống khác tác động lên hệ thống. Ca sử dụng là mô hình logic vì chúng miêu tả các hoạt động của hệ thống mà không miêu tả các hoạt động đó được thực hiện thế nào. Ca sử dụng miêu tả chức năng của hệ thống: Người sử dụng có thể làm gì Hệ thống đáp ứng như thế nào Ca sử dụng có thể được dùng để mô tả hệ thống hiện tại và hệ thống cần xây dựng Ca sử dụng miêu tả tương tác giữa người sử dụng và hệ thống 4.2.3 Mô tả ca sử dụng 2 bước để xây dựng biểu đồ ca sử dụng Viết bản mô tả ca sử dụng Chuyển từ bản mô tả ca sử dụng sang biểu đồ ca sử dụng Mỗi một ca sử dụng chỉ miêu tả duy nhất một chức năng của hệ thống Để xác định nội dung của ca sử dụng, người phát triển hệ thống phải làm việc cùng với người sử dụng 4.2.3 Mô tả ca sử dụng Các thành phần của bản mô tả ca sử dụng: 4.2.3 Mô tả ca sử dụng Ví dụ: 4.2.3 Mô tả ca sử dụng Ví dụ: 4.2.3 Mô tả ca sử dụng Ví dụ: 4.2.3 Mô tả ca sử dụng Guidelines for Creating Use-Case Descriptions Write each step in “SVDPI (subject-verb-direct object and optionally preposition-indirect object)” form Example. “The patient (subject) contacts (verb) the office (direct object) regarding (preposition) an appointment (indirect object). Clarify initiator and receivers of action Write from independent observer perspective Write at same level of abstraction Ensure a sensible set of steps Apply KISS (keep it simple, stupid) principle liberally Write repeating instructions after the set of steps to be repeated. 4.2.4 Biểu đồ ca sử dụng An Actor A use case A Subject Boundary An associate relationship 4.2.4 Biểu đồ ca sử dụng 4.2.4 Biểu đồ ca sử dụng 4.2.4 Biểu đồ ca sử dụng 4.2.4 Biểu đồ ca sử dụng 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng 4 bước chính: Bước I. Xác định các ca sử dụng chính Bước II. Mở rộng ca sử dụng chính Bước III. Khẳng định lại các ca sử dụng chính Bước IV. Vẽ biểu đồ ca sử dụng 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước I (5 bước nhỏ): Xác định các ca sử dụng chính Xem lại biểu đồ hoạt động Xác định phạm vi của hệ thống Liệt kê các tác nhân chính (primary actors) và mục đích của các tác nhân đó Xác định và viết các ca sử dụng chính Xem xét lại cẩn thận các ca sử dụng và sửa đổi nếu cần 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước I: Ví dụ Review activity diagram of Internet order System: Place CD Order Maintain CD marketing information Maintain CD Information Maintain CD Order 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước I: Ví dụ Identify and write the major (overview) use-cases 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước II (5 bước nhỏ): Mở rộng ca sử dụng chính Chọn 1 ca sử dụng chính để mở rộng Điền các chi tiết vào form Điền các bước của luồng sự kiện bình thường (normal flow of events) Chuẩn hoá kích thước của mỗi bước (nếu bước nào quá phức tạp hoặc quá dài, chia nhỏ thành các subflows hoặc đưa thêm ca sử dụng) Miêu tả các bước thay thế hoặc ngoại lệ (alternate/exceptional) Với mỗi bước thay thế hoặc ngoại lệ, miêu tả cách thức mà tác nhân (actor) và hệ thống đáp ứng 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước II: Ví dụ: kết quả sau bước 7 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước II: Ví dụ: kết quả sau bước 8 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước II: Ví dụ: kết quả sau bước 11 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước II: Ví dụ: kết quả sau bước 11 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước III (2 bước nhỏ): Khẳng định lại các ca sử dụng chính Xem xét lại các ca sử dụng, sửa lại nếu cần Xem xét lại cú pháp và ngữ nghĩa Làm việc cùng với người sử dụng Lặp lại 12 bước cho đến khi tất cả các ca sử dụng được xác định 4.2.5 Xây dựng mô tả ca sử dụng và Biểu đồ ca sử dụng Bước IV (4 bước nhỏ): Vẽ biểu đồ ca sử dụng Vẽ gianh giới của hệ thống Vẽ các ca sử dụng (vẽ theo thứ tự dễ nhìn) Vẽ các tác nhân Vẽ các quan hệ Exercise: Draw use-case diagram Question. Suppose that 7 major use cases have been identified as below, draw the corresponding use-case diagram Maintain CD marketing information Maintain CD information Maintain CD order Place CD order Place instore hold Place special order > > > Store > Distribution System Check out > > Credit Card Centre 4.3 Mô hình hoá cấu trúc 4.3.1 Giới thiệu 4.3.2 Các phần tử của mô hình cấu trúc 4.3.3 Thẻ CRC (Class-Responsibility-Collaboration) 4.3.4 Biểu đồ lớp 4.3.5 Xây dựng thẻ CRC và biểu đồ lớp 4.3.1 Giới thiệu Mục đích của mô hình cấu trúc: Mô tả cấu trúc của dữ liệu được sử dụng trong hệ thống. Rút ngắn khoảng cách giữa thế giới thực và thế giới phần mềm Xây dựng thuật ngữ chung cho người sử dụng và người phân tích hệ thống Biểu diễn sự vật, ý tưởng và khái niệm quan trọng trong hệ thống Các mô hình cấu trúc: CRC cards, class diagrams, object diagrams. 4.3.2 Các phần tử của mô hình cấu trúc Lớp (Classes) Kiểu dữ liệu để định nghĩa đối tượng (Templates for creating instances or objects) Cụ thể (Concrete) Trừu tượng (Abstract) Thuộc tính (Attributes) Đơn vị thông tin liên quan đến việc miêu tả lớp Chỉ nên đưa vào các thuộc tính quan trọng Các thuộc tính phải có kiểu cơ bản: nguyên, xâu, ngày, tháng, boolean …. Các thuộc tính phức tạp đựơc biểu diễn bằng quan hệ (relationship) giữa các lớp 4.3.2 Các phần tử của mô hình cấu trúc Hoạt động (Operations) Hành động mà đối tượng có thể thực hiện Tại bước phân tích này, chỉ tập trung vào các hoạt động liên quan trực tiếp đến vấn đề cần mô hình hoá Sau này, hoạt động sẽ được chuyển đổi sang phương thức (methods) Quan hệ (Relationships) Tổng quát hóa (Generalization) Cho phép kế thừa thuộc tính và hoạt động a-kind-of (e.g. secretary is a kind of employee) Tổng thể (Aggregation) Kết nối giữa bộ phận với tổng thể a-part-of ( e.g. a door is a part of a car) hoặc has part Kết hợp (Association) Các quan hệ khác giữa các lớp 4.3.3 Thẻ CRC (Class-Responsibility-Collaboration) Trách nhiệm (responsibility) và hợp tác (collaboration) Trách nhiệm Đối tượng của một lớp phải có trách nhiệm: biết giá trị các thuộc tính và các quan hệ của nó thực hiện hoạt động của nó Hợp tác Các đối tượng hợp tác với nhau để thực hiện một công việc Mô hình Client-server-contract Thẻ CRC được dùng để miêu tả các phần tử cơ bản của một lớp 4.3.3 Thẻ CRC (Class-Responsibility-Collaboration) 4.3.3 Thẻ CRC (Class-Responsibility-Collaboration) 4.3.4 Biểu đồ lớp 4.3.4 Biểu đồ lớp Cú pháp: 4.3.4 Biểu đồ lớp Thuộc tính: Derived attributes /age, for example can be calculated from birth date and current date Visibility Public: + Protected: # Private: - 4.3.4 Biểu đồ lớp Hoạt động (operations): Constructor Creates object Query Makes information about state available Update Changes values of some or all attributes 4.3.4 Biểu đồ lớp Quan hệ: Multiplicity of relationship exactly one: 1 zero or more: 0..* one or more: 1..* zero or one: 0..1 specified range: 2..4 multiple disjoint ranges: 1..5,7 4.3.4 Biểu đồ lớp Biểu đồ đối tượng: cụ thể hóa biểu đồ lớp 4.3.5 Xây dựng thẻ CRC và biểu đồ lớp Three common approaches Textual analysis of use-case information to create an initial rough structure model Nouns suggest classes Verbs suggest operations Creates a rough(trạng thái thô ban đầu) first cut Common object list Physical or tangible things Incidents Roles Patterns Useful groupings of classes that occur in various situations 4.3.5 Xây dựng thẻ CRC và biểu đồ lớp 1.Create CRC cards by performing textual analysis on the use-cases. 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 3. Role-play each use-case using the CRC cards. 4. Create the class diagram based on the CRC cards. 5. Review the class diagrams and structural model for missing and/or unnecessary classes, attributes, operations, and relationships. 6. Incorporate useful patterns. 7. Review the structural model. 4.3.5 Xây dựng thẻ CRC và biểu đồ lớp CD Selections Textual Analysis: Nouns suggest classes Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis Results: Identified potential classes Customer Search Request CD CD List Review (i.e., CD review information) If further analyse the Maintain Order and Checkout use cases, further potential classes will be identified such as Order Order Item Credit card centre etc Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes Textual Analysis: Verbs suggest operations: For each identified class, check the related verbs to identify the operations as well as the relationships with other classes Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis Result: For Customer Class, the identified operations (i.e., Responsibilities) and the relationship with other classes (i.e., Collaborators) are Make Search request Search request Select CD for Info Place Order CD List Get Credit Card Info Exit Order Credit Card Centre This forms the front of “Customer class” CRC Card Not include as it can be included in Search request Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Verbs suggest operations: Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be Order; Search request; Credit Card Centre Step 1. Create CRC cards by performing textual analysis on the use-cases Step 2 and 3. Examine Common Object Lists and Role-play the CRC Cards Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. Role-play each use-case using the CRC cards. Possible outcomes: Search request class need having 3 sub-classes: Title Search, Artist Search and Category Search Step 4. Create the Class Diagram based on the CRC Cards Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. For customer class, assume that all attributes are private type whereas all operations are public type For other associate classes, only the class names and the relationships with the customer class need to be given Step 4. Create the Class Diagram based on the CRC Cards Solution: Customer -First name -Middle initial Last name …… +Make search req() +Place order() +Get credit info() +Exit() Credit Card Centre Order Search Reg Check -> 0..* 0..* place -> 0..* 1 Make -> 0..* 0..* Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the Model Review the class diagrams and structural model for any missing and/or redundancy Incorporate useful patterns. One possible pattern Review the structural model. 4.4 Mô hình hoá hoạt động 4.4.1 Giới thiệu 4.4.2 Biểu đồ tương tác 4.4.3 Biểu đồ máy trạng thái 4.4.1 Giới thiệu Mục đích của mô hình hoạt động: Miêu tả cách thức các đối tượng trong mô hình cấu trúc tương tác với nhau trong mỗi ca sử dụng Miêu tả hoạt động bên trong của hệ thống Miêu tả ảnh hưởng của các hoạt động tới hệ thống Được sử dụng để kiểm tra và thay đổi các mô hình chức năng và mô hình cấu trúc Các loại mô hình hoạt động: Biểu đồ tương tác (Interaction Diagrams) Biểu đồ tuần tự (sequence diagram) Biểu đồ giao tiếp (cộng tác) (communication diagram) Biểu đồ máy trạng thái (Behavioral state machine diagram) 4.4.2 Biểu đồ tương tác Các phần tử cơ bản: Đối tượng (Objects) 1 bản sao của lớp Có các thuộc tính miêu tả đối tượng Hoạt động (Operations) Truyền hoặc nhận thông điệp Thông điệp (Messages) Chỉ thị cho đối tượng thực hiện một hoạt động 4.4.2 Biểu đồ tương tác Biểu đồ tuần tự (sequence diagram) Miêu tả các đối tượng tham gia vào 1 ca sử dụng Biểu diễn các thông điệp được truyền giữa các đối tượng trong 1 ca sử dụng 4.4.2 Biểu đồ tương tác Biểu đồ tuần tự (sequence diagram): ví dụ 4.4.2 Biểu đồ tương tác Biểu đồ tuần tự (sequence diagram): Các phần tử 4.4.2 Biểu đồ tương tác Biểu đồ tuần tự (sequence diagram): Các phần tử 4.4.2 Biểu đồ tương tác 6 bước xây dựng biểu đồ tuần tự Xác định ngữ cảnh của biểu đồ tuần tự Xác định các đối tượng tham gia Xác định đường sống (lifeline) cho mỗi đối tượng Biểu diễn các thông điệp Biểu diễn các điểm xuất hiện hoạt động (execution occurrence) trên mỗi đường sống của đối tượng Kiểm tra lại biểu đồ Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website. Application Example: Application Example: 4.4.2 Biểu đồ tương tác Biểu đồ giao tiếp (communication diagram) Tập trung miêu tả tương tác giữa các đối tượng mà không tập trung vào miêu tả thời gian và trình tự của các tương tác 4.4.2 Biểu đồ tương tác Biểu đồ giao tiếp : Ví dụ 4.4.2 Biểu đồ tương tác Biểu đồ giao tiếp : Các phần tử 4.4.2 Biểu đồ tương tác 5 bước xây dựng biểu đồ giao tiếp Xác định ngữ cảnh Xác định các đối tượng và các liên kết giữa các đối tượng 2 Vẽ các đối tượng và liên kết Thêm các thông điệp Kiểm tra lại biểu đồ giao tiếp Technique to Identify Collaborations between Objects - “CRUD” Analysis What is “CRUD” analysis: identifying the processes to Create, Read or Reference, Update or Delete objects based on use cases The process of each user case is represented by “CRUD” matrix: a class-by-class matrix in which each cell in the matrix represents the interaction between instances of the classes “CRUD” Analysis Example C C Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic (market) information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website. Application Example: Application Example: 4.4.3 Biểu đồ máy trạng thái Là mô hình động biểu diễn các trạng thái khác nhau của một đối tượng và các sự kiện làm thay đổi trạng thái của đối tượng cũng như đáp ứng và hành động của đối tượng khi chuyển trạng thái. 4.4.3 Biểu đồ máy trạng thái Ví dụ: 4.4.3 Biểu đồ máy trạng thái Các phần tử của biều đồ máy trạng thái: 4.4.3 Biểu đồ máy trạng thái Transitions: A transition indicates a movement from one state to the next one, denoted by lines with arrowheads. A transition has a label in the form of three parts: Event [guard]/activity. All three parts are optional. Event or Trigger: the signal event that triggers a potential change of state Guard: If presented, is a Boolean condition that must be true in order for the trigger to cause the transition Action or Activity: is some behaviour that has executed during the transition state Event [guard]/activity transition Các phần tử của biều đồ máy trạng thái: 4.4.3 Biểu đồ máy trạng thái 5 bước xây dựng biểu đồ máy trạng thái: Xác định ngữ cảnh Xác định trạng thái bắt đầu, kết thúc và các trạng thái ổn định của đối tượng Xác định thứ tự của các trạng thái mà đối tượng sẽ trải qua Xác định các sự kiện, hành động và điều kiện của mỗi chuyển trạng thái Kiểm tra Application Example: The Life of an Order Object: Application Example: Chương 5. Thiết kế hệ thống 5.1 Chuyển sang thiết kế 5.2 Thiết kế lớp và phương thức 5.3 Thiết kế lớp quản lý dữ liệu 5.4 Thiết kế lớp tương tác người-máy 5.5 Thiết kế lớp kiến trúc vật lý 5.1 Chuyển sang thiết kế 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế 5.1.2 Gói và Biểu đồ gói 5.1.3 Các chiến lược thiết kế 5.1.4 Xây dựng thiết kế thực tế Factoring: Creating modules* that reflect similarities and differences between units of interest Here, module = new class | new method New classes can be represented by:- Generalization Aggregation New classes identified by: Abstraction e.g. classes for nurse, admin and doctor share attributes and methods, so “factor our” common attributes and methods, create new class “employee”, relate employee to nurse, admin and doctor classes as generalisation (a-kind-of) relationship – a form of abstraction Refinement Identifying additional subclasses (of a higher level class) is a form of refinement 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế Partitions and Collaborations Creating subsystems*, i.e. collections (usually sets) of related components In object-oriented designs/implementations the “pattern of activity”, i.e. messages sent between objects, provides one basis for partitioning system into (smaller-scale) subsystems (where subsystem = partition) Grouping units that collaborate e.g. as modelled in UML communications diagram (for each use-case), CRUD analysis, clients(i.e. objects that are message senders)-servers(i.e. objects that receivemessages) & contracts (i.e. specifications of interactions between objects) May have collaboration among units (e.g. a class) or partitions (i.e. collections/sets of classes whose objects send/receive messages) The more messages or contracts between objects, the more likely they are in the same partition 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế Layers A system’s environment includes software architecture, user interface and stored data Layer enables useful separation of (related) concerns, e.g. application logic from user-interface considerations Model-view-controller (MVC) architecture Models implement application logic Views and controllers manage interfaces Views = output logic Controllers = input logic Models = application logic Suggested layers now include foundation, physical, HCI, data access and management, problem domain. n.b. layer constrains kind(s) of classes that exist “on that layer” Foundation = programming language and IDE constructs Physical architecture = classes used for communication HCI = classes enabling user interaction Data access and management = classes for persistence Problem domain = classes to be refined into implementable (effective and efficient) 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế 5.1.1 Chuyển từ mô hình phân tích sang mô hình thiết kế Layers 5.1.2 Gói và biểu đồ gói Package = UML representation  (or abstraction over)  collaboration OR partition OR layer Logical grouping of any UML elements Simplifies (large numbers of) UML diagrams Groups related elements into a single higher-level element Packages involving different kinds of construct (e.g. at particular layers) use different kinds of relationship between those constructs, i.e. in a class diagram, package = group (or set) of classes by aggregation or association relationship Also need “dependency” relationships between packages A UML package diagram can be a class diagram that contains only package symbols and dependency relationships (dotted arrows) Package symbol is similar to tabbed folder symbol Dependency relationship implies change in one package may require change in dependent package e.g. change in (the signature) of one method will cause interface for all objects of this class to change, therefore, all classes that have objects that send messages to instances of modified class may need to be modified. 5.1.2 Gói và biểu đồ gói 5.1.2 Gói và biểu đồ gói 5.1.2 Gói và biểu đồ góiVí dụ Collaborations, partitions and layers Collaborations usually are modelled as packages in UML Collaborations usually factored into a set of partitions on a layer Partitions can be composed of other partitions (hierarchically hence forming subsystems) Classes can be in partitions, those partitions then contained in other partitions, placed on a layer Simple example:- small part of appointments system 5.1.2 Gói và biểu đồ gói Package Diagram of Appointment System Patient UI dependent on Patient class DM-Patient class dependent on Patient class Patient table dependent on Patient class Problem domain Classes: Patient, Appt. Separated from object persistence Classes: Patient table, Appt. table by intermediate Data Access and Manipulation (DM) Classes: DM-Patient, DM-Appt Modularity (information hiding and encapsulation again) simplifies maintenance (changes are encapsulated within “module boundary”) and increases reusability (module’s interface defines messages that can be responded to, module can be used/reused “as is” or adapted for other uses Steps for Identifying Packages and Building Package Diagrams Set the context Cluster classes together based on shared relationships Model clustered classes as a package Identify dependency relationships among packages Place dependency relationships between packages 5.1.2 Gói và biểu đồ gói Step 1: Set the context, i.e. model a partition or a layer, e.g. for appointments system we might choose context = problem domain (PD) layer Step 2: Cluster classes together based on shared relationships, i.e. form partitions using relationships (generalisation, aggregation, kinds of association and message passing between objects) shared by classes Examine analysis models Class Diagram Sequence Diagram(s) Communication Diagram(s) Classes in a generalisation hierarchy put in a single partition Step 3: Place clustered classes in partition and model clustered classes as a package, i.e. model partitions as packages Step 4: Identify dependency relationships between packages, i.e. relationships that cross boundaries of packages = potential dependencies a) association relationship between Person Pkg and Appt. Pkg via Association between Doctor class and Appt. class and Patient Pkg contained in Person Pkg b) Appt. pkg via association between Patient and Appt classes and Treatment Pkg via association between Patient and Symptom classes Step 5: Place dependency relationships between packages, i.e. between Person Package and Appt. Package, Person Package and Treatment Package Show dependency relations as “pure” package diagram showing ONLY dependency relations that CAN be createdbetween packages  PD Layer Appt. Package Treatment Package Person Package Patient Package Worked Example: Applying Concepts at CD Selections: First, previous lectures... Chapter 5: Functional and Non-functional Requirements Chapter 6: Functional Model = activity diagram + use-case descriptions & diagrams Chapter 7: Structural Model = CRC cards + class diagram Chapter 8: Behavioural Models for “Places Order” use-case + “Order” class (sequence diagram, communication diagram, behavioural state machine) Next: Create package diagram for CD Selections Example: Applying Concepts at CD Selections Set the context = Problem Domain Layer Cluster classes, i.e. review relationships amongst classes CD Selections Class Diagram (Places Order Use-Case View) Sequence Diagram (Places Order Use Case) Communication Diagram (Place Order Use Case) Keep classes in a generalisation hierarchy together = cluster Customer, Individual and Organisation(al) classes into partition Aggregation relationships = cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition Association relationship (between CD class and Mkt Info class) and message sending pattern of activity = place in same partition Also, Vendor class only related to CD class = same partition (as CD and Market Info classes) Recall, cluster Mkt Info, Review, Artist Info, Sample Clip classes into partition Order Class and Order Item Class = partition Search Req Class and CD List Class = partition Model each partition as a package n.b. Credit Card Centre not yet contained in a package Identify dependency relationships between packages = Customer Package + Order Package, Customer Package + Search Package, Order Package + CD Package, Search Package + CD Package (also between Credit Card Centre + Customer package) Place the dependency relations on the package diagram (and increase clarity by dependency relationships between packages = pure package diagram of PD layer of CD Selections containing highest level packages only (+ Credit Card Centre class) and their dependency relationships 5.1.3 Các chiến lược thiết kế Custom Development Has potential for meeting highly specialized requirements e.g. for CD selections, order taking process could be web-based, linking tightly with the existing distribution system, or, the technical environment may enforce constraint that all information systems are built using standard technology and interface designs (for consistency, ease of reuse) Has potential for greater flexibility and creativity in solving problems e.g. for CD selections, can use ordering “web interface” as strategic enabler to better understand customer’s who order online, using technology to mine data obtained via custom applications Has potential to change components e.g. for CD selections all components in custom application are available and can be reused in whole or part Usually increases personnel skills e.g. for CD selections, developers build technical skills and business knowledge as they further evolve the system Potentially requires significant resources Potentially adds significant risk 5.1.3 Các chiến lược thiết kế Packaged Software Software already written – so available, “as is” For CD selections, could use “shopping cart” software installed into existing web page Potentially more efficient, better tested (even proven!) - because developers/implementors more skilled in techniques used to specify/design + implement, test (or even prove!) For CD selections, “shopping cart” is freely available “software tool”, other simple components also available, e.g. ActiveX controls, Java “beans”, whole approach scales-up to Enterprise Resource Planning applications (ERP’s), e.g. SAP, Oracle Functionality provided “as is” For CD selections, packed software may require change to existing business practice, but could customise an order processing application, or “work around” via custom-built application that “wraps around” packaged software giving additional functionality 5.1.3 Các chiến lược thiết kế Packaged Software (cont.) Systems Integration: building new systems from combinations of packaged software, existing legacy systems and new custom developed software to integrate these together. Problem is usually integrating data, different formats must be resolved For CD selections, integrating data in new online order system with data in legacy distribution application may be problematic Could develop “object wrapper” around legacy system (and its data) so that new object oriented web based ordering system can send messages to the “wrapper” 5.1.3 Các chiến lược thiết kế Outsourcing – (now increasingly popular) = pay external vendor, developer, service provider to create system For CD selections, use a Web Service Provider who provides commercial order taking system Potentially external suppliers have higher level of skill Their services MUST work to generate income, so web services are built by “experts” with significant experience Is not “cost free” – lose absolute control over software and data, inhouse expertise is not increased Only outsource what is properly understood in advance Needs rigorous planning and analysis of needs in advance of contract negotiations, must identify vendor, developer or service provider with proven track record of success in system and supporting technology for system’s needs Vendor choice and contract & payment method by strictly controlled criteria Time and arrangement deal Fixed price Value added contract 5.1.3 Các chiến lược thiết kế Outsourcing Guidelines Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don’t outsource what you don’t understand Emphasize flexible requirements, long-term relationships, and short-term contracts 5.1.3 Các chiến lược thiết kế Select a strategy (1): Business need Common business needs best served by packaged systems, i.e. when custom built alternative does not require any special business needs, when system is not critical to company In-house experience Custom application only feasible if sufficient in-house skills for all functional and technical challenges, otherwise packaged system (possibly with in-house integration software added) Project skills Technical, e.g. Java programming and IDE skills, data design and SQL programming skills Functional, e.g. in electronic commerce If electronic commerce is to become basis for company’s future development, in-house skills in EC and technical skills in its exploitation must be further developed Some skills, e.g. network security, might be operational issue which can be outsourced 5.1.3 Các chiến lược thiết kế Select a strategy (2): Project management Custom applications require significant project management via application of a proven system development methodology (or collection of integrated methods) Packaged and outsourced systems require different kinds of management, e.g. of contract and delivery Time frame If time to meet business requirement(s) is limited (or short), requirements are “standard” and well-defined, then packaged or outsourced most likely strategies, outsourced for standard, packaged for well-defined 5.1.4 Phát triển thiết kế thực tế Alternative Matrix Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Created using same steps as feasibility analysis (chapter 3), but combines several analyses into a single matrix for comparison Matrix is represented by a grid Contains technical, budget, organisational feasibilities for each candidate, pro’s and cons, other useful information, e.g. criticality, future-proofing Sometimes “weights” are provided n.b. in AHP weights are derived (mathematically) from judgements over criteria Request For Proposal Aids development of alternative matrix Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements. Similar (less effort-intensive) Request For Information (RFI) 5.1.4 Phát triển thiết kế thực tế 5.2 Thiết kế lớp và phương thức 5.2.1 Giới thiệu 5.2.2 Các tiêu chí thiết kế 5.2.3 Các hoạt động thiết kế đối tượng 5.2.4 Ràng buộc và giao kèo 5.2.5 Xác định phương thức 5.2.1 Giới thiệu Các mức trừu tượng của hệ thống hướng đối tượng 5.2.2 Các tiêu chí thiết kế Coupling Cohesion Connascence 5.2.2 Các tiêu chí thiết kế Coupling: Indicates the interdependence or interrelationships of the modules Interaction coupling Relationships with methods and objects through message passage Inheritance coupling Deals with how tightly coupled the classes are in an inheritance hierarchy 5.2.2 Các tiêu chí thiết kế Types of interaction coupling 5.2.2 Các tiêu chí thiết kế Interaction coupling: Law of Demeter = minimise number of objects that can receive messages from a given object Objects only send message to: A) Itself B) An object an object “contained” in an attribute of itself (or an object of one of its superclasses) C) An object passed as a parameter to the mehod D) An object created by the method E) An object stored in a variable whose declaration scope is the entire program (a “global” variable) Coupling increase if: calling method passes attributes to called method Calling method depends on value returned by called method 5.2.2 Các tiêu chí thiết kế Cohesion: Refers to how single-minded a module is within a system 3 types of cohesion: Method Class Generalization/specialization 5.2.2 Các tiêu chí thiết kế Cohesion: Method cohesion: Address the cohesion within an individual method. Methods should do one and only one thing 5.2.2 Các tiêu chí thiết kế Cohesion: Class cohesion: Is the level of cohesion among the attributes and methods of a class A class should only represent one thing A cohesive class should: Contain multiple methods that are visible outside the class Have methods that refer to attributes or other methods defined with the class or its superclass Not have any control-flow coupling between its methods 5.2.2 Các tiêu chí thiết kế Cohesion: Class cohesion: 5.2.2 Các tiêu chí thiết kế Cohesion: Generalization/specialization cohesion: Addresses the sensibility of the inheritance hierarchy 5.2.2 Các tiêu chí thiết kế Connascence: Two modules (classes or methods) are so intertwined, that if you make a change in one, it is likely that a change in the other will be required Connascence and encapsulation Minimize overall connascence by eliminating any unnecessary connascence throughout the system, Minimize connascence across any encapsulation boundaries, such as method boundaries and class boundaries, Maximize connascence within any encapsulation boundary. 5.2.2 Các tiêu chí thiết kế Connascence: 5.2.3 Các hoạt động thiết kế đối tượng Additional specification Identifying opportunities for reuse Restructuring the design Optimizing the design Map Problem Domain Classes to Implementation Languages 5.2.3 Các hoạt động thiết kế đối tượng Additional specification: Ensure the classes are both necessary and sufficient for the problem Finalize the visibility of the attributes and methods of each class Determine the signature of every method of each class Define constraints to be preserved by objects 5.2.3 Các hoạt động thiết kế đối tượng Identifying opportunities for reuse: Analysis patterns Representations of the problem-domain Design patterns Useful grouping of collaborating classes that provide a solution to a commonly occurring problem Many design patterns are available in C++ or Java source code Frameworks A set of implemented classes that can be used as a basis for implementing an application Most frameworks allow us to create subclasses to inherit from classes in the framework Libraries components 5.2.3 Các hoạt động thiết kế đối tượng Identifying opportunities for reuse: Libraries Class library similar to framework, i.e. has classes designed for reuse More domain specific, i.e. can be used to realise some layer, e.g. HIC layer Can be used to:- Create instances of classes in library Create subclasses by inheritance, and then objects of subtype(s) Using inheritance again increases inheritance coupling and Connascence Directly instantiating class in library, object dependency created between created object and library object due to signatures of methods in library object, i.e. increases interaction coupling between class library object and created object 5.2.3 Các hoạt động thiết kế đối tượng Identifying opportunities for reuse: Components: Self-contained & encapsulated software that can be plugged into a system Provides specific funtionality Typically components implemented using ActiveX or JavaBean Component has well-defined Application Program Interface (API) API = set of method interfaces to objects contained in component Internal operation of component hidden by API Components can be implemented using class libraries and frameworks Unless API changes between between version of component, only need to relink component to application (no recompilation required) 5.2.3 Các hoạt động thiết kế đối tượng Identifying opportunities for reuse: 5.2.3 Các hoạt động thiết kế đối tượng Restructuring the design: Factoring Separate out shared aspects of a method or class into a new method or class New class related to existing classes via inheritance, aggregation or association Normalization Identifies classes missing from the design All association and aggregation relationships converted to attributes of the class Challenge inheritance relationships to ensure they only support a generalization/specialization semantics 5.2.3 Các hoạt động thiết kế đối tượng Optimizing the design Simple optimisations make an existing design more efficient, but must not make optimised design significantly more difficult to reason about, i.e. optimsation is a “trade-off” between efficiency and ease of understanding the design optimisations below need to be considered. [1] access paths between objects [2] attributes of each class [3] direct and indirect “fan-out” of each method [4] execution order of statements [5] unnecessary recomputation 5.2.3 Các hoạt động thiết kế đối tượng Optimizing the design [1] access paths between objects A message from one object to another may go though many intervening objects If a) the path though the intervening objects is long and b) the message is sent frequently consider a “redundant path”, i.e. an additional attribute in the calling object that stores a direct connection to object at end of path [2] attributes of each class If methods that use an attribute only read and update attribute and only instances of a single class send those messages then attribute may belong to calling class. [3] direct and indirect “fan-out” of each method Fan-out = number of messages sent by a method Direct Fan-out = number of messages sent by given method Indirect Fan-out includes number of messages sent by methods called by other methods in a message tree If fan-out of a method significantly higher than other methods in a system then should be optimised, e.g. add an index to attributes used to send messages to objects in message tree 5.2.3 Các hoạt động thiết kế đối tượng Optimizing the design [4] execution order of statements In frequently used methods, order of statements may be non-optimal Changing order should not affect result of computation Changing order can be more efficient, e.g. when searching, if one attribute known to narrow search then search on that attribute first [5] unnecessary recomputation Derived attributes (or active values) need not be recomputed until attributes that are involved in its computation change, e.g. A) Add “trigger” to attributes in computation of derived attribute and when any of those attributes change recompute derived attribute B) Mark derived attribute and recompute only when it is next accessed 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: OO designs assume class-based OO programming language used to implement those designs e.g. UML class diagram is-a specification of a class in a class-based OO programming language Need to resolve any conflicts between constructs assumed in the design to be available in programming language but are not present in that language e.g. [1] design uses multiple inheritance, language has only single inheritance [2] implementation language is object-based and not class-based, i.e. implementation language supports object creation but not implementation inheritance [3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance A) Convert multiple inheritance relationships to “superclass”-subclass association relationships If additional superclasses are concrete (objects of the class can be instantiated) then multiplicity from superclass to subclass is 0..1 Otherwise multiplicity is 1..1 Add an exclusive-OR constraint between associations Add appropriate methods to ensure all information remains available to existing class B) Copy ALL the attributes and methods of the additional superclasses to ALL the subclassess and remove additional superclass from the design 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance SuperClass 1 - attribute 1 - attribute 2 SuperClass 2 - attribute 3 - attribute 4 SuperClass 3 - attribute 7 - attribute 8 Class 1 - attribute 5 - attribute 6 Class 2 - attribute 5 - attribute 6 concrete 0..* 1..1 0..* 1..1 {XOR} [1]All classes preserved [2]Increases amount of message passing [3]Adds to processing requirement due to XOR 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [1] design uses multiple inheritance, language has only single inheritance SuperClass 1 - attribute 1 - attribute 2 SuperClass 2 - attribute 3 - attribute 4 SuperClass 3 - attribute 7 - attribute 8 Class 1 - attribute 5 - attribute 6 Class 2 - attribute 5 - attribute 6 -attribute3 -attribute4 -attribute3 -attribute4 Potential Inheritance Conflicts abstract 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not class-based Need to factor out ALL uses of inheritance from problem-domain class design SuperClass 1 - attribute 1 - attribute 2 SuperClass 2 - attribute 3 - attribute 4 SuperClass 3 - attribute 7 - attribute 8 Class 1 - attribute 5 - attribute 6 Class 2 - attribute 5 - attribute 6 All superclasses concrete 0..* 1..1 0..* 1..1 {XOR} 1..1 1..1 1..1 1..1 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [2] implementation language is object-based and not class-based SuperClass 1 - attribute 1 - attribute 2 SuperClass 2 - attribute 3 - attribute 4 SuperClass 3 - attribute 7 - attribute 8 Class 1 - attribute 5 - attribute 6 Class 2 - attribute 5 - attribute 6 -attribute3 -attribute4 -attribute3 -attribute4 If all superclasses are abstract -attribute7 -attribute8 -attribute7 -attribute8 -attribute1 -attribute2 -attribute1 -attribute2 Potential Inheritance Conflicts 5.2.3 Các hoạt động thiết kế đối tượng Map Problem Domain Classes to Implementation Languages: [3] language is of another (less expressive) language paradigm, e.g. C or Pascal are of the imperative-procedural paradigm Stay away from this! But if necessary, factor out all uses of Polymorphism Dynamic binding Encapsulation Information hiding 5.2.4 Ràng buộc và giao kèo Contract formalises interactions between client and server objects Contract is a set of constraints and guarantees If constraints are met, server object will guarantee certain behaviour Constraints can be stated in natural language or formal language, e.g. OCL (Object Constraint Language) Constraints may be pre-conditions, post-conditions or invariants Contracts establish pre- and post-conditions for a method to execute correctly Pre-condition is constraint which must be met for a method to execute e.g. actual parameters passed must be valid, if not exception must be raised Post-condition is constraint that must be met after method executes Otherwise effect of method execution must be undone e.g. method cannot make any attributes take invalid value Exception must be raised, and effect of method’s execution must be undone 5.2.4 Ràng buộc và giao kèo Pre- and post-conditions model constraints on individual methods Invariants model constraints (that must always be true) for all instances of a class, e.g. Domains (in DB) or types (in design/programming language) of attributes Multiplicity of attributes Legal values of attributes including attributes that model association and aggregation and relationships e.g. if association relationship is required, invariant is created to enforce relationship to have valid value for instance to exist Invariants usually attached to the class, e.g. CRC cards or class diagrams as a set of assertions Example:- Back: Order Number (1:1) (unsigned long) Attributes: Date (1..1) (Date) Sub Total (0..1) (double) Tax (0..1) (double) {Sub Total = sum(Product Order.GetExtension())} Shipping (0..1) (double) Total (0..1) (double) Customer (1..1) (Customer) Cust ID (1..1) (unsigned long) (Cust ID = Customer.GetCustID()} State (1..1) (State) StateName (String) {State Name = State.GetState()} Relationships: Generalisation(a-kind-of): Aggregation (has-parts): Other Associations: Product{1..*} Customer(1..1} State{1..1} Attribute Constraint: Order Number IS unsigned long Attribute Constraint: Customer IS INSTANCE OF Customer Class Attribute Constraint: Cust ID IS unsigned LongAND Invariant MUST HAVE one and ONLY one value (1..1) = GetCustID() Customer. Constraint: Instance of Order EXISTS IF (instance of Customer class AND instance of State class AND >=1 instance of Product class) ASSOCIATED WITH order object Invariants On a Class Diagram(Not recommended – Use CRC card for Invariants) Order -Order Number: unsigned long -Date[1..]: Date -Sub Total[0..1]: double -Tax[0..1]:double -Shipping[0..1]:double -Total[0..1]double -Tax[0..1]: double -Customer[1..1]: Customer -Cust ID[1..1]: unsigned long -State[1..1] State -State Name[1..1: String Customer -Cust ID -Last Name -First Name 1..1 0..* Product -Product Number -Product Desc -Price 0..* 1..* State -State Tax RateProduct Desc 0..* 1..1 Product Order Order Product Quantity Extension > {Cust ID=Customer.GetCustID()} > {State Name=State.GetState()} > {Tax=State.GetTaxRate() *SubTotal} > {Sub Total= Sum(Product Order.GetExtension())}} 5.2.4 Ràng buộc và giao kèo Contract: Contracts document message passing between objects, i.e. messages sent to server objects by implementor’s client object, and values returned by server Ideally a contract for each message sent and received by each object, i.e. one contract per interaction In practice, one contract for each method that can receive messages from other objects, i.e. each visible method Contracts are declarative = documents for client object’s implementor what the method does Method name, class name, ID number, client objects, associated use cases, description, arguments received, type of reurn value, pre- and post-conditions Does NOT contain details of how method works i.e. not procedural Specific Method OF specific Class Unique Contract ID List of classes and methods that send a message to this method List of use cases containing this method where method is used to realise implementation of the use case (from server class’s CRC card and associated use cases) What the method does NOT how it does it types of parameters passed type of value returned to its clients = method signature 5.2.5 Xác định phương thức General information Events Message passing Algorithm specification Structured English Pseudocode UML activity diagram Method Name Class Name ID: Contract ID Programmer: Date Due: Programming Language: Visual Basic SmallTalk C++ Java Triggers/Events Arguments Received: Data Type: Notes: Messages Sent & Arguments Passed ClassName.MethodName: Data Type: Notes: Argument Returned: Data Type: Notes: Algorithithm Specification: General Information (for managing programming effort) e.g. user initiated event(mouse event, keystroke event), system event or event initiated by another method Message passing to and from method (c.f. sequence and collaboration diagrams) Arguments = attributes and data structures in implemented method Structured English will suffice for algorithm specification… Algorithm Specification: Action Statement Examples: Profits = Revenues – Expenses Generate Inventory-Report IF Statement Examples: IF Customer NOT in Customer Object Store THEN Add Customer record to Customer Object Store ELSE Add Current-Sale to Customer’s Total Sales Update Customer record in Customer Object Store FOR Statement Examples: FOR all Customers in Customer Object Store DO Generate a new line in Customer-Report Add Customer’s Total-Sales to Report-Total CASE Statement Examples: CASE IF Income < 10,000: Marginal-tax-rate = 10 percent IF Income < 20,000: Marginal-tax-rate = 20 percent IF Income < 30,000: Marginal-tax-rate = 31 percent IF Income < 40,000: Marginal-tax-rate = 35 percent ELSE Marginal-tax-rate = 38 percent ENDCASE Notes: Pseudocode = “programming specific” language with initialisation and linking instructions (Get_CD_Info Module) Accept(CD.Title) {Required} Accept(CD.Artist) {Required} Accept(CD.Category) {Required} Accept(CD.Length) Return