Lecture 6: Domain modeling. The main contents of this chapter include all of the following: Identifying concepts, concept attributes, concept associations, contracts: preconditions and postconditions. | Ivan Marsic Rutgers University LECTURE 6: Domain Modeling Topics Identifying Concepts Concept Attributes Concept Associations Contracts: Preconditions and Postconditions Domain Modeling Why? —The goal of domain modeling is to understand how system-to-be will work Requirements analysis determined how users will interact with system-to-be (external behavior) Domain modeling determines how elements of system-to-be interact (internal behavior) to produce the external behavior How? —We do domain modeling based on sources: Knowledge of how system-to-be is supposed to behave (from requirements analysis, ., use cases) Studying the work domain (or, problem domain) Knowledge base of software designs Developer’s past experience with software design Use Cases vs. Domain Model (b) (a) In use case analysis, we consider the system as a “black box” In domain analysis, we consider the system as a “transparent box” Example: ATM Machine (b) (a) Building Domain Model from Use Cases . | Ivan Marsic Rutgers University LECTURE 6: Domain Modeling Topics Identifying Concepts Concept Attributes Concept Associations Contracts: Preconditions and Postconditions Domain Modeling Why? —The goal of domain modeling is to understand how system-to-be will work Requirements analysis determined how users will interact with system-to-be (external behavior) Domain modeling determines how elements of system-to-be interact (internal behavior) to produce the external behavior How? —We do domain modeling based on sources: Knowledge of how system-to-be is supposed to behave (from requirements analysis, ., use cases) Studying the work domain (or, problem domain) Knowledge base of software designs Developer’s past experience with software design Use Cases vs. Domain Model (b) (a) In use case analysis, we consider the system as a “black box” In domain analysis, we consider the system as a “transparent box” Example: ATM Machine (b) (a) Building Domain Model from Use Cases Step 1: Identifying the boundary concepts Step 2: Identifying the internal concepts Use Case 1: Unlock Use Case UC-1: Unlock Related Requirements: REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1 Initiating Actor: Any of: Tenant, Landlord Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically. Participating Actors: LockDevice, LightSwitch, Timer Preconditions: • The set of valid keys stored in the system database is non-empty. • The system displays the menu of available functions; at the door keypad the menu choices are “Lock” and “Unlock.” Postconditions: The auto-lock timer has started countdown from autoLockInterval. Flow of Events for Main Success Scenario: 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock” 2. include::AuthenticateUser (UC-7) 3. System (a) signals to the Tenant/Landlord the lock status, ., “disarmed,” (b) signals to LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on 4. .
