Unit-2.pptx
- 2. Building Conceptual/Domain Models • It is a major activity in the development cycle. • A conceptual/domain model is a representation of concepts in a problem domain. • In UML it is a static structure diagrams in which no operations are defined. • A domain model illustrates meaningful (to the modelers) conceptual classes in a problem domain; it is the most important artifact to create during object-oriented analysis. • A domain 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
- 3. • Using UML notation, a domain model is illustrated with a set of class diagrams in which no operations are defined. • It may show: - domain objects or conceptual classes - associations between conceptual classes - attributes of conceptual classes • It must not show: - software artifacts such as window or database - responsibilities or methods
- 5. Domain Modeling • visual representation of domain concepts in simple UML - Other names: conceptual models, domain object model, analysis object model - Bounded by a specific domain as described in use cases - Concepts are not software classes (these are in domain layer ) • In object Oriented design the emphasis is on defining logical software objects that will ultimately be implemented in an object oriented programming language.
- 6. Steps for Creating a Domain Model i. Find the domain concepts ii. Draw them in a UML class diagram iii. Add associations and attributes
- 8. • Domain concepts noteworthy abstractions, domain vocabulary idea, thing or object e.g Payment, Sale • Associations relationships between concepts e.g. Payment Pays-For Sales • Attributes information content e.g. Sale records date and time
- 9. Domain Model : Identifying Conceptual Classes • The domain model illustrates conceptual classes or vocabulary in the domain. • Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension Symbol: words or images representing a conceptual class. Intension: the definition of a conceptual class. Extension: the set of examples to which the conceptual class applies.
- 10. Example • Conceptual class for the event of a purchase transaction: • Name : Sale. • Intension: represents the event of a purchase transaction, and has a date and time. • Extension: All the examples of sales; in other words, the set of all sales.
- 12. Example .. • Name : Card • Intension: represents one card in a poker deck that has a rank (1..13) and a suit • Extension: the set of all cards
- 13. Domain Models and Decomposition • Software problems can be complex • Decomposition: divide-and-conquer is a common strategy to deal with this complexity by division of the problem space into comprehensible units. • In structured analysis, the dimension of decomposition is by processes or functions. • In object-oriented analysis, the dimension of decomposition is fundamentally by things or entities in the domain.
- 14. How to Create a Domain Model • Find the conceptual classes • Draw them as classes in a UML class diagram • Add associations necessary to record relationships • Add attributes necessary for information to be preserved • Use existing names, the vocabulary of the domain 14
- 15. How do I find Conceptual Classes? • Reuse or modify existing models. If there are published models, prior art, or books, use them • Use a category list (given behind) • Identify noun phrases (linguistic analysis) 15
- 18. Noun Phrase Identification • Consider the following problem description, analyzed for Subjects, Verbs, Objects: The ATM verifies whether the customer's card number and PIN are correct. S V O O O If it is, then the customer can check the account balance, deposit cash, and withdraw cash. S V O V O V O Checking the balance simply displays the account balance. S O V O Depositing asks the customer to enter the amount, then updates the account balance. S V O V O V O Withdraw cash asks the customer for the amount to withdraw; if the account has enough cash, S O V O O V S V O the account balance is updated. The ATM prints the customer’s account balance on a receipt. O V S V O O
- 19. Noun Phrases Analyze each subject and object as follows: • Does it represent a person performing an action? Then it’s an actor, ‘R’. • Is it also a verb (such as ‘deposit’)? Then it may be a method, ‘M’. • Is it a simple value, such as ‘color’ (string) or ‘money’ (number)? Then it is probably an attribute, ‘A’. • Which NPs are unmarked? Make it ‘C’ for class. Verbs can also be classes, for example: • Deposit is a class if it retains state information
- 20. Where are the Terms? • Some are in the use case • Some come from domain experts • Natural language is imprecise and ambiguous, so you need to use judgment
- 21. Example from use case
- 23. POS example You can create a list, or you can use a set of class diagrams, per the table below Store Register Sale Item Payment Sales LineItem Cashier Customer Manager Product Catalog Product Specification
- 24. A Common Mistake in Identifying Conceptual Classes • Common mistake: representing something as an attribute when it should have been a class. • “If we do not think of some conceptual class X as a number or text in the real world, it should probably be a class, not an attribute.” • Should “store” be an attribute of Sale or should it be a class?
- 25. • In the real world, a store is not considered a number or text the term suggests a legal entity, an organization, and something occupies space. Therefore, Store should be a concept. • In Airline Domain, Will Destination be a concept of or an attribute Of Flight? or? • Destination Airport is a massive thing that occupies space so it is a concept not an attribute
- 26. Specification or Description Concepts
- 27. When Are Description Conceptual Classes Required? • Add a specification or description conceptual class (ProductDescription) when: - There needs to be a description 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
- 28. Example
- 29. Domain Modeling : Adding Associations(second step) • Association is a relationship between concepts that indicates some meaningful interesting connection.
- 30. The UML Notation for association • An association is represented as a line between classes with an association name. • The association is inherently bidirectional, meaning that from instances of either class, logical traversal to the other is possible.
- 33. High Priority Associations • Some high-priority association categories that are invariably useful to include in a domain model: A is a physical or logical part of B A is a physically or logically contained in B A is recorded in B
- 34. Association Guidelines • Focus on those associations in which knowledge of the relationship needs to be preserved need to know • It is more important to identify concepts then to identify associations • Too many associations tend to confuse a domain model rather than illuminate it. Their discovery can be time-consuming, with marginal benefit. • Avoid showing redundant or derivable associations.
- 35. Role • Each end of an association is called a role. Roles may optionally have: - name - multiplicity expression - navigability
- 36. Multiplicity • It defines how many instances of A can be associated with one instance of a type B, at a particular moment in time. • For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the * ) Item instances.
- 37. Examples of Multiplicity • In UML the multiplicity value is context dependent
- 38. Naming Association • Name an association based on a TypeName-VerbPhrase- TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context. • Association names should start with a capital letter, since an association represents a classifier of links between instances; in the UML, classifiers should start with a capital letter. • Good: Sale PaidBy CashPayment Bad: Sale uses CashPayment • Good: Player IsOn Square Bad: Player has Square • Two common and equally legal formats for a compound association name are: - Paid-by PaidBy
- 40. Multiple Associations between Two Types • Two types may have multiple associations between them; this is not uncommon.
- 41. Example(POS): Applying the Category of Associations Checklist
- 43. Point of Sale Domain Model
- 44. Domain Model: Identifying Attributes(step 3) • Attribute: It is a logical data value of an Object • Include the following attributes in a domain model: Those for which the requirements (for example, use cases) suggest or imply a need to remember information • UML Attribute Notation Attributes are shown in the second compartment of the class box. Their type may optionally be shown
- 45. Valid Attribute Types • Keep Attributes Simple • Intuitively, most simple attribute types are what are often thought of as primitive data types, such as numbers. • The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport. • For example, the currentRegister attribute in the Cashier class is undesirable because its type is meant to be a Register, which is not a simple attribute type (such as Number or String). • The most useful way to express that a Cashier uses a Register is with an association, not with an attribute.
- 46. • The attributes in a domain model should preferably be simple attributes or data types. • Very common attribute data types include: Boolean, Date, Number, String(Text), Time • Other common types include: Address, Color, Geometries (Point, Rectangle),Phone • Number, Social Security Number, Universal Product Code (UPC), SKU,ZIP or postal codes, enumerated types
- 47. Figure : Relate with associations, not attributes. Figure : Avoid representing complex domain concepts as attributes; use associations.
- 48. Data Types • Attributes should generally be data types. This is a UML term that implies a set of values for which unique identity is not meaningful. • For example, it is not meaningful to distinguish between: Separate instances of the Number 5. Separate instances of the String 'cat'. Separate instances of PhoneNumber that contain the same number. Separate instances of Address that contain the same address.
- 49. Non-Primitive Attribute Types • Represent what may initially be considered a primitive data type (such as a number or string) as a non-primitive class if: - It is composed of separate sections. - phone number, name of person - There are operations usually associated with it, such as parsing or validation. - social security number - It has other attributes. - promotional price could have a start (effective) date and end date - It is a quantity with a unit. - payment amount has a unit of currency - It is an abstraction of one or more types with some of these qualities. - item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) or European Article Number (EAN)
- 50. Attributes in the PoS Domain Model • The attributes chosen reflect the requirements for this iteration—the ProcessSale scenarios of this iteration
- 51. • The list of attributes should primarily be constrained to the requirements and simplifications currently under consideration. • Some attributes are clearly called for by reading Requirements specification • Current use cases under considerations Simplifications, clarifications, and assumption documents • e.g. It is necessary to record the date and time of a sale, therefore the sale concept requires a date and a time attribute.
- 52. A partial domain model.
- 53. Multiplicity from SalesLineItem to Item • It is possible for a cashier to receive a group of like items (for example, six tofu packages),enter the itemID once, and then enter a quantity (for example, six). • Consequently, individual SalesLineItem can be associated with more than one instance of item. The quantity that is entered by the cashier may be recorded as an attribute of the SalesLineItem . However, the quantity can be calculated from the actual multiplicity value of the relationship, so it may be characterized as a derived attribute—one that may be derived from other information. In the UML, a derived attribute is indicated with a "/" symbol.
- 55. Building System Sequence Diagrams - System Behavior • A system sequence diagram is a fast and easily created artifact that illustrates input and output events related to the systems under construction. • The UML contains notation in the form of sequence diagrams to illustrate events from external actors to a system.
- 56. System Behavior • It is a description of what system does, without explaining how system does it. • Before proceeding to a logical design of how a software application will work, it is useful to investigate and define its behavior as a "black box." • System behavior is a description of what a system does, without explaining how it does it. i. One part of that description is a system sequence diagram. ii. Other parts include the use cases, and system contracts
- 57. System Sequence Diagrams • Use cases describe how external actors interact with the software system • During this interaction an actor generates events to a system, usually requesting some operation in response. For example, when a cashier enters an item's ID, the cashier is requesting the POS system to record that item's sale. • That request event initiates an operation upon the system. • It is desirable to isolate and illustrate the operations that an external actor requests of a system, because they are an important part of understanding system behavior.
- 58. Contd… • The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them. • A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a usecase, the events that external actors generate, their order, and inter-system events. • All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems. • An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios.
- 60. Example of a sequence diagram • An SSD shows, for a particular course of events within a use case, the external actors that interact directly with the system, the system (as a black box), and the system events that the actors generate . • Time proceeds downward, and the ordering of events should follow their order in the use case. • System events may include parameters. • This example is for the main success scenario of the Process Sale use case. • It indicates that the cashier generates makeNewSale, enteritem, endSale, and makePayment system events.
- 61. Fig: SSD for a Process Sale scenario
- 63. Significance of Drawing System Sequence Diagrams • It is required to design software to handle events from mouse, keyboard etc coming in to the system and execute a response • Software system reacts to three things - External events from actors (human or computers) - Timer events - Faults or exceptions • So it becomes necessary to know the external/system events to analyze the system behavior • System sequence diagrams are drawn to investigate and define the behavior of a software application as a black box before going into detailed design of how it works • System behavior is a description of what a system does, without explaining how it does it and System sequence diagram is a part of that description
- 64. SSDs and Use Cases • An SSD shows system events for a scenario of a use case, therefore it is generated from inspection of a use case. So there can be multiple scenarios in case of a system and those scenarios can be further elaborated by using individual system sequence diagrams to depict the system events.
- 66. System Events and the System Boundary • To identify system events, it is necessary to be clear on the choice of system boundary. • For the purposes of software development, the system boundary is usually chosen to be the software (and possibly hardware) system itself; in this context, a system event is an external event that directly stimulates the software
- 67. • Consider the Process Sale use case to identify system events. First, we must determine the actors that directly interact with the software system. The customer interacts with the cashier, but for this simple cash-only scenario, does not directly interact with the POS system only the cashier does. Therefore, the customer is not a generator of system events; only the cashier is.
- 68. Giving Names to System Events and System Operations • System events (and their associated system operations) should be expressed at the level of intent rather than in terms of the physical input medium or interface widget level. • It also improves clarity to start the name of a system event with a verb (add...,enter..., end...,make...)
- 69. • A system event is an external input event generated by an actor to a system. • An Event initiates a responding operation. • A system operation is an operation of the system that executes in response to a system events • When the Cashier generates the enterItem system event it causes the execution of the enterItem system operation (in this case the event is the named stimulus and the operation is the response) So it is better to name a system event as enterItem rather than scan as scan is specific form of entering items into system Recording System Operations • The set of all required systems operations is determined by identifying the system events, using parameters e.g. enterItem(UPC, quantity), endSale(), makePayment(amount)
Editor's Notes
- #21: Time flies.