4
The total information processing needs total information modeling; as mentioned above, under our subject,
what problems faced by an enterprise application are essentially in changing and uncertain—it is open.
The inevitable mediating model thereby should satisfy three conditions: human-understandable /
operational, computer-treatable, and evolutionary with the changing of the target as well. Thus, a
predetermined domain model, namely enterprise model, is necessary for enterprise applications. Figure 2
shows some typical domains and their relationships for an enterprise application, in which the labels are
omitted “the domain of”, e.g. “the domain of a problem”. The dotted line indicates the border is relatively
uncertain.
3 SOFTWARE ENGINEERING ON THE LEFT
3.1 Difficulties and Transforming Barrier from Analysis to Design
Kaindl (1999) demonstrated the difficulties in the transition from object-oriented requirement analysis
(OOA) to the system design (OOD). He focused on two problems that are particularly difficult in OOD:
first, architectures: “Finding an architecture that fits well to solve a given problem is both difficult and
important.” Second, model of the domain inside the program: “the OOA model cannot be simply part of
the OOD model.” (pp. 99-100) This is involved in the design decisions about which information about
real world objects the deployed system will store and how it will be represented, i.e., how to model the
thing in domain inside the program. Such the opinion is appeared as a logical succession from the opinion
by Bosh and Molin (1997): “the most complex activity during application development is the
transformation of a requirement specification into an application architecture.”
In Kaindl (1999), the OOA model roughly is a problem model in which there are both the elements of
computer and other things involved in the problem. From a modeling perspective, the problem is the
transformation from the analysis models to a design model. Model transformation is the major strategy to
improve the system development in MDE, but it does not effectively address the problem even often
avoided the issue (see the discussions about MDE and CIM later). Karow et al. (2006) presented that “the
transformation results are potentially insufficient and inappropriate for the design process.” And “an
automation of the design starting from the CIM is not possible by utilising currently existent
transformation approaches.”
Flowing above accounts, we can describe the problem more generally, that is, in general, there is no
simple (liner or automatic) complete transformation from analysis model to design model or code. It can
be called transforming barrier between analysis model and design model. The analysis model here can be
involved in problem model, domain model, business (process) model (as is; to be), and may also the
functional model (as a black-box model of the system, e.g. the use case model) of the application system.
Against, the design model is somewhat white-box model of the system which are can be implemented in
some executable code.
3.2 Object-Orientation and Use-Case Driven
Some one might think that the scenario described in sec. 2.1 is very consistent with the object-oriented
(OO) approach: Classes / Objects are the models of the real world thing; this relationship is shown in
most the examples in OO books or articles. There was a cautious statement in Craig (2004, Sec. 9.3.):
“This is a key idea in OO: Use software class names in the domain layer inspired from names in the
domain model, with objects having domain-familiar information and responsibilities.” However, this
issue is indeed relating to the transforming barrier, “the question remains how OOD objects can be both
abstractions of something in a problem domain and objects in a solution space.” (Kaindl, 1999, p. 95) The
direct correspondence between the Classes / Objects in software and the objects in real word is helpful but
not enough to solve the transition difficulties. We prefer regard an Object as a container to the model of
the real object (if there is—an Object in software can also be not corresponding to any real world thing),
i.e., the data of a model is encapsulated in an Object as its private data; in other words, the model is hard-
coded, embedded in the code.