CSC/ECE 517 Fall 2010/ch6 6h AS

From Expertiza_Wiki
Revision as of 03:31, 17 November 2010 by Adszalas (talk | contribs)
Jump to navigation Jump to search

Domain Object Model

Overview

In software engineering, looking at the entire system is not required for every feature. In order to help clarify the specific problem or feature, only the main components specific to that feature should be shown in its description. This subset of the entire domain of the system is known as the Domain Object Model (DOM). The objective of designing using this style is that it allows the engineers to focus only on the main objects of the feature, throwing away the other objects as extraneous.

Background

When using Feature Driven Development (FDD), system engineers need to quickly focus in on the main players of a particular feature that is required[1]. The DOM is a methodology that allows the engineers to only focus on the required pieces of the system that is affected by the system.

DOM Creation

Once a feature is determined as needed, the affected portions of the system are determined. Within this subsystem, the scenarios, use cases, and feature set are developed for the feature. From this the feature is developed and tested.

Advantages of using DOM

  • With the scope of the DOM being a reduced part of the entire system, it is possible to reuse the DOM for another purpose[2].
  • The flexibility of the feature can be enhanced through the DOM[2].

Disadvantages of using DOM

  • With the reduced system scope, it is possible for unforeseen system interactions to occur between features.
  • Assertions made about the DOM tend to be made very rigidly, causing enhancements to cause the DOM to be extended instead of changed[2].
  • DOM's are created as an "up front" design cost. It is further accepted that this cost is rarely recovered in development phase. This documentation is crucial for the training of those that come afterward[2].

Example

As an example of using the DOM model, the system for this example is a printer. The feature that is being considered is that of controlling a paper roll that will be used to feed paper out of the printer.

Breakdown

Within this example, we can immediately focus on portions of the printer that does not to be considered. For example, objects within the system like putting the ink/toner on the paper, fusing the toner onto the paper, feeding the paper from the paper tray, feeder tray paper height, and normal system User Interface (UI) display are parts of the system that has no bearing upon this specific feature (although it is possible that if a fault is detected that a fault message may be required to be displayed on the UI. The following figure can show from a paper path perspective which parts are irrelevant:
DOM Breakdown
DOM Breakdown
With this in mind, the focus of this feature would be upon those hardware subsystems that as specifically involved. Further analysis could also reveal that the hardware subsystem feeding paper into this paper roll and the hardware subsystem that the paper roll feeds into would also be affected (if the paper exits, then the exit tray would be the affected subsystem). Also, as earlier stated, the UI and overall system controller would be affected by this paper roll in the event of a fault occurring..

UML

When the focus is broken down, it makes working with the classes involved much simpler. In this example, we are looking a the classes affected by the PaperExitRoll class.
UML Diagram
UML Diagram
Here have interaction with the roll that preceeds it and tray that it feeds into. Further, UI interaction is needed in order to raise any faults that may occur. Assertions made in creating this simple UML diagram:
  • We don't care about the paper feeding into the PreExitRoll.
  • We don't care about how multiple faults are handled within the system, only the ones we raise.

Conclusion

With more modern Agile Methodologies available (Extreme Programming (XP), scrum, Test Driven Development (TDD)), the usefulness of DOM has been greatly diminished. However there are scenarios when using DOM is a valid and useful way to design products. The usefulness will be determined based upon the policies and processes in place within the company.

References

[1] Author Not Listed, Domain model – Wikipedia, the free encyclopedia, Last Revised 15-Oct-2010, Wikimedia Foundation, Inc., http://en.wikipedia.org/wiki/Domain_model
[2] Paul Oldfield, Domain Modelling, 2002, Appropriate Process Group, http://www.aptprocess.com/whitepapers/DomainModelling.pdf
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch6_6h_AS&oldid=40950"