1 / 36

Case Study – Building Analysis Model

Case Study – Building Analysis Model. Objectives. Identify analysis classes related to the current iteration requirements. Create an initial domain model. Distinguish between correct and incorrect attributes. Add specification analysis classes, when appropriate.

nitesh
Télécharger la présentation

Case Study – Building Analysis Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Case Study – Building Analysis Model

  2. Objectives • Identify analysis classes related to the current iteration requirements. • Create an initial domain model. • Distinguish between correct and incorrect attributes. • Add specification analysis classes, when appropriate. • Compare and contrast analysis and implementation views.

  3. Road Map

  4. Review • A analysis model • a source of inspiration for designing software objects, and a required input to build design model • A analysis model illustrates meaningful analysis classes in a problem domain; • it is the most important artifact to create during object-oriented analysis. • Identifying Analysis Classes is at the heart of object-oriented analysis • A analysis model is a representation of real-world conceptual classes, not of software components. • It is not a set of diagrams describing software classes, or software objects with responsibilities • They have also been called conceptual models, domain models, and analysis object models.

  5. Analysis Models in UML • Using UML notation, a analysis model is illustrated with a set of class diagrams in which no operations are defined. It shows: • analysis objects or conceptual classes • associations between analysis classes • attributes of analysis classes

  6. Case Study: Sample DM of POS

  7. Analysis Models Are not Models of Software Components • A analysis model is a visualization of things in the real-world domain of interest, not of software components such as a Java or C++ class

  8. Analysis Class Identification • It is better to overspecify a analysis model with lots of fine-grained analysis classes than to underspecify it. • Do not worry missed analysis classes during the initial identification step • during later (design) work. When found, they may be added to the analysis model • Do not exclude a analysis class simply because the requirements do not indicate any obvious need to remember information about it

  9. How to identify Analysis Classes • 1. Use a analysis class category list. • 2. Identify noun phrases. • Another excellent technique for analysis modeling is the use of analysis patterns

  10. Case Study: Identify Analysis Classes of POS • Method 1 - Use a Analysis Class Category List (common categories)

  11. Case Study: Identify Analysis Classes of POS • Method 1 - Use a Analysis Class Category List (common categories)

  12. Finding Analysis Classes with Noun Phrase Identification • Care must be applied with this method • a mechanical noun-to-class mapping isn't possible, • words in natural languages are ambiguous Main Success Scenario (or Basic Flow): 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 2-3 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory). 9. System presents receipt. 10.Customer leaves with receipt and goods (if any).

  13. Continue Extensions (or Alternative Flows): 7a. Paying by cash: 1. Cashier enters the cash amount tendered. 2. System presents the balance due, and releases the cash drawer. 3. Cashier deposits cash tendered and returns balance in cash to Customer. 4. System records the cash payment.

  14. List Candidate Analysis Classes for the Sales Domain • Register (need discussion) • Item • Store • Sale • Payment • ProductCatalog • ProductSpecification • SalesLineItem • Cashier • Customer • Manager • Should we include “Register”? It represents the POS system itself, I can be considered as a Controller. It can be renamed to “POS”.

  15. Common Mistake in Identifying Analysis Classes • Confusion between Attributes and Analysis Classes • The most common mistake when creating a analysis model is to represent something as an attribute when it should have been a concept. • A rule of thumb to help prevent this mistake is: If we do not think of some Analysis class X as a number or text in the real world, X is probably a Analysis class, not an attribute For example, Store, Yes Amount, No

  16. Why not a Receipt concept? • Receipt is a record of a sale and relatively important concept in domain of sales • Receipt is report of a sale. In general, showing a report in a analysis model is not useful since all its info is derived from other sources • However, it has a special role in terms of business rules; customer uses it to return a previously bought item

  17. Specification or Description Analysis Classes Add a specification or description analysis class when: • There needs to be adescription about an item or service, independent of the current existence of any examples of those items or services. • Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing. • It reduces redundant or duplicated information.

  18. Discussion: How DM used in Design Stage ? • The Analysis Model provides a visual dictionary of the domain vocabulary and concepts from which to draw inspiration for the naming of some things in the software design. (one of Advantages of OOAD)

  19. How to Make a Analysis Model Apply the following steps to create a analysis model: • 1. List the candidate analysis classes using the analysis Class Category List and noun phrase identification techniques related to the current requirements under consideration. • 2. Draw them in a analysis model. • 3. Add the associations necessary to record relationships for which there is a need to preserve some memory • 4. Add the attributes necessary to fulfill the information requirements

  20. Analysis model: adding associations • It is useful to identify those associations of analysis classes that are needed to satisfy the information requirements of the current scenarios under development • An association is a relationship between types (or more specifically, instances of those types) that indicates some meaningful and interesting connection

  21. Association Guidelines • Focus on those associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-know" associations). • It is more important to identify analysis classes than to identify associations. • Too many associations tend to confuse a analysis model rather than illuminate it. • Avoid showing redundant or derivable associations. Most important and common associations in a analysis model: • A is a physical or logical part of B. • A is physically or logically contained in/on B. • A is recorded in B.

  22. Naming Associations • Name an association based on a TypeName-VerbPhrase-TypeNameformat that is readable and meaningful in the model context. • The default direction to read an association name is left to right or top to bottom.

  23. Case Study: Add Associations (1/2)

  24. Case Study: Add Associations (2/2)

  25. Analysis model: adding attributes Objectives • Identify attributes in a analysis model. • Distinguish between correct and incorrect attributes. • An attribute is a logical data value of an object. • Include the following attributes in a analysis model: Those for which the requirements (for example, use cases) suggest or imply a need to remember information

  26. Attributes Rules • Keep Attributes Simple, such as a number, string, boolean, date, or time • The type of an attribute should not normally be a complex domain concept • Attributes should generally be data types • Avoid representing complex domain concepts as attributes; use associations - No Attributes as Foreign Keys

  27. An Attribute or a Analysis Class • A analysis model is a tool of communication; choices about what is shown should be made with that consideration in mind • As a rule of thumb, stick to the basic test of "simple" attribute types: Make it an attribute if it is naturally thought of as number, string, boolean, date, or time (and so on); otherwise, represent it as a separate analysis class.

  28. Modeling Attribute Quantities and Units • Most numeric quantities should not be represented as plain numbers. Consider price or velocity. These are quantities with associated units, and it is common to require knowing the unit, and to support conversions.

  29. Case Study: Add Attributes (1/2)

  30. Case Study: Add Associations (2/2)

  31. It is easy, isn’t it?

  32. Exercise – Draw DM for the previous Bodyshop example

  33. Main scenario 1. Customer arrives with damaged car (or it is towed in). 2. Estimator enters customer identification into system. 3. Estimator enters vehicle information (make, model, year, VIN, etc) into system. 4. Estimator enters into system either a part for repair/replacement or a labor item (e.g., "paint front fender"). 5. System accumulates cost of replacement part and/or labor associated. Repeat steps 4-5 for all damaged or missing parts or shop tasks. 6. Estimator indicates end of parts & labor data entry. 7. System generates estimate (parts list, labor total, and estimated completion date). Estimate is saved (for comparison with actual work, in case of dispute with customer, and for statistics). 8. System prints estimate for customer.

  34. Alternate flows • 5b. System has no record of the specified part or labor item. • 5b1. System notifies estimator that database contains no record for this item. • 5b2. Estimator enters manual estimate for that item. • 5b3. System accumulates manual estimate and notes this line item as such. • 5b4. System files this manual estimate for later review and 'official' entry into database. • 8a. Customer chooses to have work performed. • 8a1. See Use Case BS2, "Body Shop Open Repair Order"

  35. Answer: Analysis Model

  36. Road Map to next

More Related