Domain Modeling (Business Concept Modeling)

1. Domain Modeling (Business Concept Modeling) Software Architecture Research Group, Department of Computer and Information Science, University of Mississippi

2. References This section is based on: Doug Rosenberg and Kendall Scott. “Domain Modeling” in Use Case Driven Object Modeling with UML, Chapter 2, Addison-Wesley, 1999

3. Domain Modeling • Involves building static conceptual model of the system’s problem domain - Problem domain: real world entities and concepts related to problem to be solved • Discovers “objects” representing those concepts • Creates common vocabulary (glossary of terms) for stating requirements

4. Development Workflow Business requirements Requirements Use case models Business concept models Technical constrains Components Use case models Specification Provisioning Assembly Component specs & architectures Applications Test Tested applications Deployment

5. Sources of Domain Information • High-level problem statement • Lower-level requirements statement • Documentation, reports, outputs, user notes, etc. relating to system being replaced • Expert knowledge of the problem domain • Existing models or descriptions of the domain or similar domains

6. Steps in Domain Modeling • Make a quick pass through the problem statement and other relevant documents • List key words and phrases to identify objects and their attributes and relationships • Refine lists as work progresses

7. Grammatical Analysis • Nouns and noun phrases become objects and attributes • Verbs, transitive verbs and verb phrases become operations and associations • Adjectives, possessive phrases indicate that nouns may be attributes rather than objects • Intransitive verbs become associations among objects - Attribute refers to the property of an object • Adjectives may be subclasses or attributes For example, • truck - class • fire truck - subclass • red truck - attribute

8. Discovering Domain Concepts • Eliminate duplicate terms, make plural terms singular and sort alphabetically • Eliminate unnecessary items from list of candidate classes • Retrace the problem statement and requirements, read between lines and discover more classes • Do not spend more than a few hours

9. Requirements Statement for a Course Registration System This project is to develop a new class registration system for the University of Mississippi. A studentwishing to register for classes must first enter his identifying information. Once given access, the student may select a term and then build a personal class schedule from among the classes offered that term. A student may add and deleteclasses from the schedule. A student will not be allowedto create an invalid schedule such as scheduling two classes at the same time or scheduling a class that is full. Once the schedule is complete, the studentmay then submit the schedule for final processing. The systempasses the information about the student's schedule to the tuition billing system. The student may print the schedule if he wishes. At any point, the studentmay cancel his schedule and exit the registration systemwithout completing registration or being chargedtuition. A student may also use the system to subsequently add and deleteclasses from his schedule. The student billing system will generate any needed bill for tuition or feesrequired by the schedule change. An instructormay use the registration system to print a listingof his or her classes and the studentsin those classes. The administrator of the registration system may manage thesystem as needed, carrying out such operations as adding and deletingclasses, updatinginformation about classes, and adding and deletingstudents or instructors .

10. Course Registration SystemFirst Set of Candidate Classes project, class registration system, University of Mississippi, student, class, identifying information, access, term, personal class schedule, invalid schedule, schedule, student’s schedule, same time, tuition billing system, point, registration, tuition, system, bill, fees, schedule change, instructor, listing, administrator, operations, information about classes

11. Course Registration SystemElimination Process • Student, instructor, and administrator are actors – might only be in use case model, unless system holds information about them • Project implies whole system to be built – no need to model explicitly • University of Mississippi is the single target for system – no need to model explicitly • Access implies action – not modeled as entity

12. Course Registration SystemElimination Process • Tuition billing system is out of scope of system • Identifying information, information about classes are attributes of other entities • Same time is too vague to be domain entity • Tuition, bill, fees are out of scope • Registration, operations are operations • System itself represents system to be built

13. Course Registration SystemRefined Set of Candidate Classes • Person • Student schedule • Instructor schedule • Term • Course • Section

14. Build Generalization Relationships Generalization: kind-of relationship, where one class is a kind of another class. Former class is superclass, or parent while latter class is subclass or child

15. Person Administrator Student Instructor Course Registration SystemGeneralization of Person Class

16. Build Associations Between Classes Association: relationship between classes that are independent of time (state) • Associations show dependencies between classes, not actions • Candidates from verbs, verb phrases, domain knowledge, etc. • Refine list by eliminating actions and other details irrelevant for conceptual model • Represent one-to-one, one-to-many, and many-to-many relationships (multiplicities)

17. Aggregation and Composition Aggregation: association in which one class is made up of other classes (part-of relationship) • Serves as a reference to something Composition: strong form of aggregation • “piece” class is “owned by” one larger class • Avoid until detailed design

18. Draw Class Diagram Person 1 1 1 0..1 0..1 0..1 Administrator Student Instructor 1 1 * * Instructor Schedule Student Schedule 1 * 1 * * * Section 1 * * Term 1 1 Course 1

19. Top Domain Modeling Errors • Assigning multiplicities to associations • Spending too much time on noun and verb analysis • Assigning operations to classes without exploring and in interactions • Optimizing code for reusability before satisfying user’s requirements • Wasting time on aggregation vs. composition issue

20. Top Domain Modeling Errors (contd) • Presuming specific implementation strategy without modeling problem space • Using hard to understand class names • Jumping directly to implementation constructs • Creating one-for-one mapping between domain classes and relational database tables • Performing ‘premature patternization’ (i.e. using patterns without any valid connection to user problems)

21. Acknowledgement Development of the course materials was supported, in part, by a grant titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE) ” from Acxiom Corporation

22. Extra Slides

23. Unified Modeling Approach Dynamic GUI Prototype Sequence Diagram Use Case Model Robustness Diagram Static CODE Domain Model Class Diagram

24. Discover Classes Jim Rumbaugh: Class: a description of group of objects with similar properties, common behavior, common relationships, and common semantics • Find classes representing abstractions of problem domain • Builds solid foundation on which to build the system • Excellent prospects for reuse of system

25. Course Registration SystemNouns project, class registration system, University of Mississippi, student, classes,identifying information, access, student, term, personal class schedule, classes, term, student, classes, schedule, student, invalid schedule, classes, same time, class, schedule, student, schedule, final processing, system, information, student’s schedule, tuition billing system, student, schedule, point, student, schedule, registration system, registration, tuition, student, system, classes, schedule, student, billing system, bill, tuition, fees, schedule change, instructor, registration system, listing, classes, students, classes, administrator, registration system, system, operations, classes, information about classes, students, instructors

26. Course Registration System Verbs develop, wishing to register, enter, select, build, add and delete, not be allowed, to create, scheduling, submit, passes, print, wishes, cancel, exit, without completing, being charged, use, add and delete, generate, use, print, manage, carrying out, adding and deleting, updating, adding and deleting