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

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ả

Domain Model Lecture Hoa Sen University Agenda     Recap Case Requirements Elaboration process Domain model – Introduction and definition – How to create a domain model Hoa Sen University Recap       Inception activities Different types of requirements Scenario & Use case Writing Use Cases Use Case Diagram Use case relationships Hoa Sen University 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 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 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 Incremental Development  Incremental development for the same use case across iteration  .  Use Case Use Case Use Case Process Sale Process Sale Process Sale Feature:  Logging 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 Rentals Hoa Sen University 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 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, 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 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 Naming association  Name an association based on a ClassName-VerbPhrase-ClassName format  Eg – Sales paid-by CashPayment  Bad alternative: Sales uses CashPayment – Piece is-on Square  Bad alternative: Piece has Square Hoa Sen University 37 Applying UML: multiplicity  Multiplicity defines how many instances of a class A can be associated with one instance of class B Store Stocks * Item multiplicity of the role Hoa Sen University 38 Multiplicity values  Multiplicity focus on the relationship at a particular moment, rather than over a span of time  Eg “In countries with monogamy laws, a person can be Married-to only one other person at any particular moment, even though over a span of time, that same person may be married to many persons.” * * 40 3, 5, 8 Hoa Sen University T zero or more;  "many" T one or more T one to 40 T exactly 5 T exactly 3, 5, or 8 39 Multiplicity values Store Stocks  * or 0 Item Multiplicity should "1" or "0 1"? The answer depends on our interest in using the model. Typically and practically, the muliplicity communicates a  domain constraint that we care about being able to check in software, if this relationship was implemented or  reflected in software objects or a database.  For example, a particular item may become sold or discarded, and thus  no longer stocked in the store. From this viewpoint, "0 1" is logical, but  Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensure  that an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault or  corruption in the software elements or data This partial domain model does not represent software objects, but the multiplicities record constraints whose  practical value is usually related to our interest in building software or databases (that reflect our real­world domain)  with validity checks. From this viewpoint, "1" may be the desired value.   Hoa Sen University 40 Multiple association between two classes * Flight * Flies­to Flies­from Hoa Sen University Airport 41 Find association  Use the common associations list – A is a physical part of B  Square – Board – A is a logical part of B  SalesLineItem – Sale – A uses or submanages B  Cashier- Register – A communicates with B  Customer – Cashier – etc Hoa Sen University 42 POS partial domain model Records­sale­of  Ledger Product Catalog Records­ accounts­ for Sales LineItem * 1 Logs­ completed * Describes * * Sale * Used­by 1 Contains Store Contained­in Product Description Stocks Item * * Houses * Register Captured­on 1 Paid­by CashPayment 1 Is­for   Works­on 1 Customer Cashier Hoa Sen University 43 Monopoly partial domain model Hoa Sen University 44 Attributes  An attribute is a logical data value of an object  When to show attribute – Include attributes that the requirements suggest or imply a need to remember information – Eg  Sale needs a dateTime attribute  Store needs a name and address Hoa Sen University 45 UML notation  Attributes are shown in the second compartment of the class box  Type and other information may optionally be shown  Derived attribute – The total attribute in the Sale can be calculated from other information – It is worth noting down Sale ­ dateTime : Date ­ / total : Money Private visibility  attributes Math + pi : Real = 3.14 {readOnly} Public visibility readonly  attribute with initialization Hoa Sen University Person firstName middleName : [0 1] lastName Optional value 46 Suitable attribute types  Most attribute types should be what are often thought of as “primitive” data types  Relate conceptual classes with an association, not with an attribute Worse Better Worse Better Cashier not a "data type" attribute name currentRegister Cashier Uses name number Flight destination is a complex  concept destination Flight Hoa Sen University Register 1 Flies­to Airport 47 Data types as attributes  We sometimes represent what may initially be considered a number or string as a new data type class in the domain model  We can show the data type only in attribute compartment or as a separate class associated with another class Address ItemID OK OK Product Description Product Description itemId : ItemID 1 Store id manufacturerCode countryCode 1 street1 street2 cityName Store address : Address Hoa Sen University 48 Attributes are NOT foreign keys  During implementation, there are many ways to relate objects, including foreign key, but the decision should be deferred till DESIGN stage Worse Better Cashier a "simple" attribute, but being  used as a foreign key to relate to  another object name currentRegisterNumber Cashier Works­on name Register number Hoa Sen University 49 Modelling quantities Payment not useful amount : Number Payment * Payment amount : Quantity Payment amount : Money Has­amount Quantity amount : Number quantities are pure data  values, so are suitable to  show in attribute section * Is­in Unit better variation: Money is a  specialized Quantity whose  unit is a currency Hoa Sen University 50 Iterative and evolutionary domain model  Is the domain model correct? – There is no such thing as a single correct domain model! – Domain model is incrementally evolve over several iterations – In each iteration, the domain model is limited to the prior and current scenarios under consideration Hoa Sen University 51