Information Technology Reference
In-Depth Information
Finally, stakeholders could process models including details
of the technological platforms used to implement the system.
These models are considered low-level abstraction models.
Thus, MDE conceives software development as a chain of
modifications (enhancements) where models of a system are
transformed through different levels of abstraction starting at
the problem space and finishing at the solution space.
The model presented before in Figure 3.1 is an example
of a high-level abstraction model including only concepts
regarding the problem space. Figure 3.6 presents a lower-
level abstraction model. This model includes software design
concerns to represent EJBSession and EJBEntity elements.
Thus, this model is closer to the solution space, i.e. it includes
more implementation details than the model presented in
Figure 3.1.
Figure 3.6. Low-level abstraction class model
The separation of concerns of a system in different models
according to the level of abstraction is only one of the criteria
that stakeholders can use to separate models.At each different
level of abstraction of a system, different stakeholders may
have different points of view of the system. Figure 3.7 presents
an example of a high-level class model including an extra
property, isPersistent , related to Class elements. This
property allows stakeholders to tag the Class elements whose
data need to be maintained in a data base repository.
3.3. UML class diagrams and OCL
In the previous sections, we saw how to describe models
and metamodels using structural descriptions inspired from
the so-called class diagram of UML. However, as for UML,
structural descriptions alone are not sufficient to precisely
Search WWH ::




Custom Search