Motivation: Why Create a Domain Model? - UML

I'll share a story that I've experienced many times in 00 consulting and coaching. In the early 1990s I was working with a group developing a funeral services business system in Smalltalk, in Vancouver (you should see the domain model!). Now, I knew almost nothing about this business, so one reason to create a domain model was so that I could start to understand their key concepts and vocabulary.

We also wanted to create a domain layer of Smalltalk objects representing business objects and logic. So, we spent perhaps one hour sketching a UML - ish (actually OMT - ish, whose notation inspired UML) domain model, not worrying about software, but simply identifying the key terms. Then, those terms we sketched in the domain model, such as Service (like flowers in the funeral room, or playing "You Can't Always Get What You Want"), were also used as the names of key software classes in our domain layer implemented in Smalltalk.

This similarity of naming between the domain model and the domain layer (a real "service" and a Small talk Service) supported a lower gap between the software representation and our mental model of the domain.

Motivation: Lower Representational Gap with 00 Modeling

This is a key idea in 00: Use software class names in the domain layer inspired from names in the domain model, with objects having domain - familiar information and responsibilities. Figure illustrates the idea. This supports a low representational grip between our mental and software models. And that's not just a philosophical nicety - it has a practical time - and - money impact. For example, here's a source - code payroll program written in 1953:

1000010101000111101010101010001010101010101111010101 ...

As computer science people, we know it runs, but the gap between this software representation and our mental model of the payroll domain is huge; that profoundly affects comprehension (and modification) of the software. OO modeling can lower that gap.

Of course, object technology is also of value because it can support the design of elegant, loosely coupled systems that scale and extend easily, as will be explored in the remainder of the book. A lowered representational gap is useful, but arguably secondary to the advantage objects have in supporting ease of change and extension, and managing and hiding complexity.

Figure 9.6 Lower representational gap with OO modeling

Lower representational gap with OO modeling


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics