Bài Giảng Phân tích thiết kế hướng đối tượng (phần 3)

Chia sẻ: Nguyen Kien | Ngày: | Loại File: PPT | Số trang:51

lượt xem

Bài Giảng Phân tích thiết kế hướng đối tượng (phần 3)

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'bài giảng phân tích thiết kế hướng đối tượng (phần 3)', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Nội dung Text: Bài Giảng Phân tích thiết kế hướng đối tượng (phần 3)

  1. Domain Model Lecture 3 Hoa Sen University 1
  2. Agenda  Recap  Case Requirements  Elaboration process  Domain model – Introduction and definition – How to create a domain model Hoa Sen University 2
  3. Recap  Inception activities  Different types of requirements  Scenario & Use case  Writing Use Cases  Use Case Diagram  Use case relationships Hoa Sen University 3
  4. Case requirements  The requirements for the first iteration of the NextGen POS: – Implement a basic, key scenario of the Process Sale use case – Implement a Start Up use case as necessary to support the initialization needs of the iteration – Nothing fancy or complex is handled – No collaboration with external services – No complex pricing rules are applied Hoa Sen University 4
  5. Case requirements  Monopoly – Implement a basic, key scenario of the Play Monopoly Game use case: players moving around the squares of the board – Implement a start Up use case as necessary to support the initialization needs of the iteration – Two to eight players can play – A game is played as a series of rounds Hoa Sen University 5
  6. Case requirements  Monopoly (cont) – Play the game for only 20 rounds – After the dice are rolled, the name of the player and the roll are displayed. When the player moves and lands on a square, the name of the player and the name of the square that the player landed on are displayed. – In iteration-1 there is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind – Square name will be “Go”, “Square 1”, “Square 2”, …“Square 39” Hoa Sen University 6
  7. Incremental Development  Incremental development for the same use case across iteration A use case or feature is 1 2 3 ... often too complex to complete in one short iteration. Therefore, different parts Use Case Use Case Use Case or scenarios must be Process Sale Process Sale Process Sale allocated to different iterations. Use Case Process Rentals Feature: Logging Hoa Sen University 7
  8. Process: inception  What happened in inception – Last only one week – Most actors, goals and use cases named – Most use cases written in brief format; 10-20% of the use cases are written in fully dressed detail – Recommendations on what components to buy/build/reuse, to be refined in elaboration  Technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements/  High-level candidate architecture and components proposed – NOT necessary to be final or correct  Plan for the first iteration Hoa Sen University 8
  9. Process: on to Elaboration  What happens in Elaboration – The core, risky software architecture is programmed and tested – The majority of requirements are discovered and stabilized – The major risks are mitigated or retired – Commonly, 2 or more timeboxed iterations  Elaboration in one sentence – Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources. Hoa Sen University 9
  10. Process: on to Elaboration  Best practices in elaboration – Do short timeboxed risk-driven iterations – Start programming early – Adaptively design, implement, and test the core and risky parts of the architecture – Test early, often, realistically – Write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration Hoa Sen University 10
  11. Domain models  Illustrates noteworthy concepts in a domain  Drawn with UML class diagram  As with all things in an agile modelling and UP spirit, a domain model is optional  Input – Problem Description, Use Cases, …  Output – A set of class diagrams Hoa Sen University 11
  12. Example concept Sales Item or domain LineItem Records-sale-of object 1 quantity 0..1 1..* * Stocked-in association Contained-in 1 1 Sale Store attributes date address time 0..1 name 1 1 Houses Paid-by 1..* 1 Register Captured-on o Payment 1 amount Identifying a rich set of conceptual classes is at the heart of OO analysis Hoa Sen University 12
  13. What is a domain model  A domain model is a visual representation of conceptual classes or real-situation objects in a domain. – Various names  conceptual models, domain object models, analysis object models  A domain model is illustrated with a set of CLASS DIAGRAMS in which no operations (method signatures) are defined Hoa Sen University 13
  14. Domain models is a visual dictionary  Domain model provides a conceptual perspective – Domain objects or conceptual classes – Associations between conceptual classes – Attributes of conceptual classes  The information it illustrates could alternatively have been expressed in plain text Hoa Sen University 14
  15. Domain model is not a picture of software objects  Domain model is visualization of a real-world concept in a visualization of Sale dateTime the domain of interest it is a not a picture of a software class things in a real- world domain of interest av o id SalesDatabase software artifact; not part of domain model  Not suitable in a domain model av o id date Sale software class; not part of domain model – Software artefacts time print() – Responsibilities or methods Hoa Sen University 15
  16. What are conceptual classes  A conceptual class may be considered in terms of date Sale concept's symbol – Symbol – words or images time representing a conceptual class "A sale represents the event of a purchase transaction. It has a date and time." concept's intension – Intension – the definition of a conceptual class sale-1 – Extension – the set of sale-3 sale-2 concept's extension examples to which the sale-4 conceptual class applies Hoa Sen University 16
  17. Domain model vs. Data model  Data model – persistent data to be stored somewhere  Domain model also include – Temporary object – Object with no attribute Hoa Sen University 17
  18. Motivation  Help to understand the key concepts in a business or problem domain  Lower representational gap with OO Modelling UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. Sale A Payment in the Domain Model Payment 1 1 Pays-for is a concept, but a Payment in date the Design Model is a software amount time class. They are not the same thing, but the former inspired the inspires naming and definition of the objects latter. and names in This reduces the representational gap. Sale This is one of the big ideas in Payment object technology. 1 1 date: Date Pays-for amount: Money startTime: Time getBalance(): Money getTotal(): Money ... UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered. Hoa Sen University 18
  19. How to create a Domain Model  Steps – Find the conceptual classes – Draw them as classes in a UML class diagram – Add associations and attributes Hoa Sen University 19
  20. Find conceptual classes  Three strategies to find conceptual classes – Reuse or modify existing models  There are published, well-crafted domain models and data models for common domains: inventory, finance, health..  Books: Analysis patterns by Martin Fowler, Data Model Patterns by David Hay, Data Model Resource Book by Len Silverston – Use a category list – Identify noun phrases Hoa Sen University 20



Đồng bộ tài khoản