Domain Modelling - Appropriate Process

1 Domain Modelling Paul Oldfield Mentors of Cally Ltd. Member of the Appropriate Process Movement Abstract The concept of Domain Modelling takes several forms. This document is about one of those forms. The concept, its philosophy, its uses and advantages, and ideas on how to perform Domain Modelling of this form are all introduced. In depth discussion is not attempted, here you will find the merest introduction to the topics. This document is not static and may be updated as the author sees fit. Copyright Note This document resides online at and has been authored by Paul Oldfield of Mentors of Cally Ltd. and of the Appropriate Process Movement. It may be copied freely in part or in whole, with the restriction that anywhere using a copy of more than three paragraphs must include as reference the web address of its origin, as given above.

2 Contents Abstract .. 1. Copyright 1. 1. Introduction .. 2. Business to Analysis Model: Outline of Two Approaches .. 2. The Robustness Diagram 2. The Class, Responsibility, Collaborator 3. What is a Domain Model .. 3. Why do different people have different ideas on this? .. 3. Classes and Logical Model in Analysis model .. 3. The RUP idea .. 3. CRC 4. Invariant Properties .. 4. How to Model the Domain : Basics .. 5. Who, What, Where, When, Why, 5. Responsibilities in the Right 5. Copyright 2002, Appropriate Process Group 1. 6. Responsibilities : Knowledge; 7. Abstractions, Responsibilities and Relationships .. 7. Controller Objects? No, Thank You .. 8. Collaborations .. 8. Rules and 9.

3 How to Model the Domain : Finer Points .. 9. Requirements 9. Domain Expert has Left The Room .. 10. Independence of Use .. 11. Use Roles: Think of each abstraction in 11. The feel good' 11. Controlling 12. How to Model the Domain : 12. Precondition Postcondition 12. Model in Parallel .. 13. Domain Expert Learns Domain 13. 14. Advantages and 14. Reuse .. 14. Flexibility .. 14. Extend don't 14. Cost .. 15. Summary .. 15. Acknowledgements and 15. References .. 16. Introduction Different people have different ideas about Domain Modelling ; what it is, what use it is, how to do it, why one should do it, and in what circumstances. In this document, one particular set of answers to those questions is presented.

4 In brief. The full answers would fill a book, I don't have time to write it, and it wouldn't sell very well. Business to Analysis Model: Outline of Two Approaches Of all the topics in OO software and systems development, the problem of arriving at a suitable Object Model starting from a Use Case Model is probably that which most often gives cause for concern. Here two approaches are outlined The Robustness Diagram Approach An outline of the Robustness Diagram approach is given in the article at and the subsequent article in that series. Copyright 2002, Appropriate Process Group 2. In short, Use Cases are first modelled in terms of Boundary, Controller and Entity objects, with all responsibilities for behaviour initially assigned to Controller objects.

5 As development progresses, these responsibilities are pushed down from the Controller objects to the Entity objects, until ideally the Controller object is slimmed down to at most a script for implementing the specific Use Case. The Class, Responsibility, Collaborator Approach An outline of a particular version of the CRC approach is given in this document. In short, the Domain is modelled independently of how the model is to be used in a given system, responsibilities are assigned to abstractions during that Process , and the responsibilities required to realize specific Use Cases are identified as the Use Case is mapped onto the Domain Model. What is a Domain Model A Domain model is a model of the Domain within which an Enterprise conducts its business.

6 The Domain Model for one Enterprise should be the same as that for any other Enterprise conducting business in the same Domain . When we get down to more detailed levels, different people have different ideas about what constitutes a Domain Model. Why do different people have different ideas on this? There are several different, but related, concepts of a Domain Model when we look at the topic in detail. These derive from how the model is used in the context of particular families of methodologies. Here are two of the more common alternative interpretations that aren't discussed further in this document. Classes and Logical Model in Analysis model Often the term Domain Model' is used to refer to the class diagram that one finds in the Analysis model.

7 Typically, this will include classes with attributes and operations, and will have related sequence diagrams. This reflects the views of the practitioners that the classes are created specifically for use with the current system. The responsibilities are already assigned to Attributes and Operations. This may or may not be the best assignment of responsibilities to support future changes, but the sequence diagrams are used to show that this arrangement supports the current requirements as captured in the Use Cases. Typically, practitioners do not consider the conversion of responsibilities into Attributes and Operations to be design or decision. The methodology may or may not have a task to try and assign the responsibilities to the right classes.

8 Commonly, the assignment of responsibilities to classes is in the form of defining operations on the classes, as the sequence diagrams for the system are being built. The RUP idea RUP describes a Domain model as an incomplete business object model, focusing on explaining products, deliverables, or events that are important to the business Domain . Such a model does not include the responsibilities people carry . It is also described as an alternative to a glossary. It would appear that the responsibilities are not recorded at Copyright 2002, Appropriate Process Group 3. all, either with the people or with the entities, unless in a very informal manner. Entities are typically described in terms of the dumb objects that are manipulated by workers in the processes used to perform the business of the enterprise.

9 CRC origins On the one hand you have behaviour, on the other hand you have things; entities if you prefer that word. All systems need to relate behaviour to things. Computer programmers started by concentrating on behaviour, and bringing in the entities where they were needed. This culminated in Procedural programming. Organisation of the behaviour is the driving force; the entities follow the behaviour. Object-Oriented programming takes a different approach, concentrating on entities (objects) first, and letting the behaviour follow the entities. However, requirements tend to arrive in terms of behaviour. These lumps' of behaviour will need to be broken up and divided between the entities.

10 One of the mantras of OO programming since its early days has been Get the Responsibilities in the Right Place . If we can do this, then building and modifying the system will be easier and success will be more likely. See the section Responsibilities in the Right Place. Over the years, one of the most useful techniques in placing responsibilities has been Class; Responsibility; Collaboration card sessions (see Beck (1989) Wirfs-Brock (1990). Bellin (1997)). There are many variants on how to hold such a session. All benefit from the flexibility of using cards physically rather than on the computer. Each class is written on a card-index card or similar. Its responsibilities are listed briefly under the class name.