1. Trang chủ
  2. » Công Nghệ Thông Tin

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

51 608 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Cấu trúc

  • Domain Model

  • Agenda

  • Recap

  • Case requirements

  • Slide 5

  • Slide 6

  • Incremental Development

  • Process: inception

  • Process: on to Elaboration

  • Slide 10

  • Domain models

  • Example

  • What is a domain model

  • Domain models is a visual dictionary

  • Domain model is not a picture of software objects

  • What are conceptual classes

  • Domain model vs. Data model

  • Motivation

  • How to create a Domain Model

  • Find conceptual classes

  • Use a category list

  • Noun Phrase Identification

  • Example: flow of event

  • Mapping parts of speech to object model components

  • Example: find and draw conceptual classes

  • Initial POS domain model

  • Initial Domain model of Monopoly game simulation

  • Agile modelling style

  • Include report objects?

  • Class or Attributes

  • Description Class

  • Description classes

  • Associations

  • When to show association

  • Associations and implementation

  • Association Notation

  • Naming association

  • Applying UML: multiplicity

  • Multiplicity values

  • Slide 40

  • Multiple association between two classes

  • Find association

  • POS partial domain model

  • Monopoly partial domain model

  • Attributes

  • UML notation

  • Suitable attribute types

  • Data types as attributes

  • Attributes are NOT foreign keys

  • Modelling quantities

  • Iterative and evolutionary domain model

Nội dung

Domain Model Domain Model Lecture 3 Lecture 3 Hoa Sen University 1 Agenda Agenda  Recap  Case Requirements  Elaboration process  Domain model – Introduction and definition – How to create a domain model Hoa Sen University 2 Recap Recap  Inception activities  Different types of requirements  Scenario & Use case  Writing Use Cases  Use Case Diagram  Use case relationships Hoa Sen University 3 Case requirements 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 Case requirements 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 Case requirements 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 Incremental Development Incremental Development  Incremental development for the same use case across iteration Hoa Sen University 7 1 A use case or feature is often too complex to complete in one short iteration. Therefore, different parts or scenarios must be allocated to different iterations. Use Case Process Sale 2 3 . . . Use Case Process Sale Use Case Process Sale Use Case Process Rentals Feature: Logging Process: inception 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 Process: on to Elaboration 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 Process: on to Elaboration 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

Ngày đăng: 05/07/2014, 16:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN