17.1 Kinds of Domains


The domain chart in Figure 17.1 shows the various subject matters required to build the system. Each domain can be modeled using Executable UML, and the techniques described so far apply uniformly to each domain, though we have focused in the examples on an application, the online bookstore.

Figure 17.1. Domain Chart for the Online Bookstore

graphics/17fig01.gif

17.1.1 Application User Interface

In addition to the application domain, it is common to model the application user interface, a generic name given to the domain that captures the rules for how the user interface is utilized. On the domain chart, this is labeled Web GUI to indicate that we expect to use a web-based application user interface. We distinguish between the application user interface that captures the layout of menus for the application and the technologies that provide the widgets for realizing that user interface, such as HTML and a Web server.

An example of a small portion of the application user interface is shown in Figure 17.2. Note that this model is both more general than a particular application (there's nothing about Bookstore things in it) and not specific to a particular implementation technology it could be implemented using HTML in a browser, Java Swing components, an ActiveX control, or other technologies.

Figure 17.2. Example of a Web GUI Domain

graphics/17fig02.gif

17.1.2 Generic Service Domains

Some domains represent services in a form more generic than the application and potentially reusable throughout the application and on entirely different applications.

Consider the problem of stocking product inventory in the bookstore. As product is shipped, the inventory count decreases. At some predetermined point, an order is sent to the publisher for more.

Now suppose we also want to track the boxes, tape, packing material, and labels used during shipping. Just like the products, these items are consumed and reordered when the quantities on hand drop below a certain predetermined level. We could add this capability to the bookstore models by adding new classes and state machines.

But a more appropriate solution is to abstract an entirely new domain, Inventory, and to make use of that domain's services while modeling both product inventory and shipping.

Figure 17.3 shows a class diagram for an Inventory domain. Again, notice that this domain is more generic than the application itself. By using an Inventory domain in our system, we can model the bookstore application assuming that some domain will provide the services of tracking quantities of products and automatically reordering stock when the quantities on hand fall below the reorder thresholds.

Figure 17.3. Class Diagram for the Inventory Domain

graphics/17fig03.gif

17.1.3 Realized Domains

Some domains may already be realized as code and do not require further modeling. These include the implementation technologies that are used to realize other domains (e.g., HTML, Java, XML), external systems (e.g., the credit card and package-delivery companies' systems), and third-party components (e.g., the Web server).

Definition: A realized domain is a domain supplied as code.

On the domain chart, denote each of the realized domains with a «realized» stereotype.

To build the system, all domains must be modeled or realized.



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net