State Of The Art

Introduction

  • Write about modeling in general. What it's by definition.
  • Define what a domain model is.
  • Write about the modeling phase in software development process
  • Introduce the context of web applications
    • What is the relation between the domain model and the rest of the application ?
    • Explain the difference between thin domain and rich domain
      • Explain the differences in web application architecture ?
      • Explain how the Fénix project architecture has evolved ?

When someone tries to create a software application to solve a complex problem, the solution is the result of the software development process.
The early stage of software development process is analysis. Software engineers analyze the problem and design a possible solution.
A way to capture some part of the real or even imaginary world is to create a model, describing concepts and creating abstractions of real or imaginary things [2].
Within the whole process different kinds of models are created. When building a software application there is the need to describe and materialize concepts which are part of the nature of the problem. When an analist gathers the requirements of some system - he creates models based in his background experience, knowledge and skills - in some schematic drawing or even by describing them in plain textual form. These artifacts are representations of the models. They describe ideas and concepts regarding the domain of the problem decomposing it into small and simple pieces becoming part of the solution. Therefore, models are abstractions used as tools to help software engineers to comunicate, express their ideas and to specify a solution for the problem they are trying to solve. Usually this models are created using a modeling language which in general is very generic and does not have a well-defined semantic for the constructs available.
At the implementation phase these models need to be translated and refined to some target programming language. The challenge is the simpleness and efficiency of the transformation between the abstraction present in the model and the concrete implementation.[10]

Some might argue that this transformation can be done automatically, using tools and frameworks to execute the models created at analysis and design time, others prefer to be more realistic and adopt the traditional approach letting the developers be responsible to translate and refine these models successfully.

In the context of software engineering, a domain model represents the entities and the relationships among them. Usually, it is described as a class diagram or entity diagram using a modeling language such as UML. This model must be understood and certainly will be used by all team members even as a communication artifact since all the business logic will manage and use those entities. It is a framework of understanding since in it, rely the entities and the relationships among them that will be present along the development of the application for every kind of purpose.

The object-oriented programming paradigm defines a set of well defined concepts such as class, object, inheritance, and much more. These concepts define what object-oriented programming is and what concepts are available. Such concepts are then mapped into object-oriented languages as semantic constructs to be used by developers when creating their implementation models. During the analysis and design fase, the development team agree on which entities are part of the domain, and the relationships between them. When the developers need to implement this models they need to refine this models into an implementation model which is different from the original one due to the lack of constructs supported by the programming language.

The Web in the last years has grown a lot and nowadays it is a undeniable resource. People want web applications deployed everywhere with a short time-to-market. Web applications are now an enormous concern within the software engineering community. Back in 2000, reports indicate that web applications represent more than thirty percent of software applications across all industry sectors [11].
Complex applications are now available through a web browser client. The architecture of a web application has evolved a lot too. Efforts have been made to simplify the process of web applications development.
The compromise of this work is to the new paradigm of Rich Domain Applications. The key idea is to include all the business logic in the domain model, creating “fat” objects, each of them representing data and behavior, letting them deal with other objects using their relations as the business logic demands. The domain objects become the core of the application, not just by representing data resulting in a thin layer within the architecture, but being the entire business logic layer.

Since we consider the domain model the backbone of our software, this work pretends to discuss the different possibilities that engineers have when creating domain models and how efficiently they are implementing them on some target language.

Goals

This work is an attempt to minimize the gap between the domain model design and the concrete implementation.
Increase expressiveness and features related to relations semantic support.

  • Keep the developers working on the business logic of the application instead of implementation details.
  • Give them the tools necessary to implement the business logic with less effort.
  • The main goal is to provide new features to the DML in order to minimize the developers' effort.

Related Work

Domain Driven Design

  • Domain model as the core of the application
  • Talk about MDD in DDD approach
  • Domain Driven Design vs Model Driven Development
  • Introduction about the work developed and the motivation of MDD approach. [4]

There are many software development methodologies - each of them with specific purposes and goals - but in all of them, models are used as tools to form a conceptual understanding of the problem and solution [10].

"Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs. … Java and many other tools allow the creation of objects and relationships directly analogous to conceptual object models. " [14]

The word analogous is carefully chosen in this statement. Relationships are refined during implementation. There is no construct available in Java to represent a relation between two objects and guarantee the same semantic given when creating the abstract model during the analysis and design phase.

Implementing Relationships

  • relationships as high level concept and programming languages lack of relationships constructs
  • relationships from analysis are lost during design and implementation.
  • tradicional approach to implement relationships identified in analysis and why they don't maintain the same semantics.
  • advantages of relationship code dispersed in the domain model vs relationship objects (decoupling)
  • Basic Relationship Patterns introduce ways of mitigating the problem and propose patterns to implement relations.
  • Relations as Semantic Constructs in an Object Oriented Language define a new language where relation is a language construct and treated at the same level just like classes,attributes and methods.
  • Explicit Relationships in Object Oriented Development is a case study which identifies how relations are traditionally implemented and proposes different ways of implementing them.

When one software engineer tries to decompose a domain, he tries to gather the relevant information needed to embody the software that he is developing. Using object-oriented methodology he tries to create a representation of the real domain decomposing its concepts in objects and relations.

A relation is an abstraction stating that objects from certain classes are associated in some way. [8]

Although it is a frequently used concept it is not present in the most recent object-oriented programming languages.
The lack of high-level constructs such as relationships in the object-oriented languages (e.g. Java) increases the gap between design and implementation models. In fact, such constructs would allow developers to create the domain model of the application more effectively and simply.
This conclusion was made a long time ago by Rumbaugh and Noble. They both argue that relations should be at the same semantic level than other high-level constructs such as generalization. In fact, Rumbaugh was the first to realize that, after applying relationships constructs at the implementation level within some software projects, simplifies conceptualization and implementation.

Domain Example

domainexample.png
The class diagram above is a subset of the domain model present in FénixEDU Project. It is also a slight variation of the domain example presented in [7]
The figure shows that many students can attend many courses and students have name and numbers whereas courses have title, name and a course code.
One course can have many lesson plannings containing some title and the planning description. A teacher can teach many courses, though there is the restriction that a course can only be taught by one teacher (in a real world example this usually is not the case). This simple domain model will be used in the next sections to exemplify different approaches on transforming it to a implementation level model.

As identified in [1], the previous work on trying to minimize the gap between modeling and implementation level regarding relationships can fit within one of the following approches :

  • Definition of first-class constructs (such as relationships constructs) available at programming language level.
  • Development of patterns or libraries which provide high-level concepts support at implementation level.
  • Development of tools which transform a model representation written using a modeling language to some target programming language.

Patterns for implementing relationships

The traditional approach to implement relationships is using collections. Most of the

[6]
[5]
[7]

Relationships as first-class language constructs

Rumbaugh was the first to propose a language where relations are a first-class construct within a programming language.[9]
At that time, languages like Smalltalk didn't provide such high-level constructs so it was necessary to improve object-oriented languages to provide such concepts. After careful analysis of what object-oriented programming languages should provide, Rumbaugh states that relationship information should be equally expressed among models (e.g. conceptual and implementation model). Due to the lack of features of the most popular object-oriented languages he proposed a new one where relations constructs were available at implementation level. Providing such construct at implementation level, Rumbaugh argues that if developers consider and use these constructs as semantically equivalent to those they use when modeling, the design will become more expressive, easy to use and to maintain.[8]

Generating the code for relationships

Code generation from UML models

UML stands for Unified Modeling Language. It is a graphical modeling language widely used among the software development community. It is a general purpose language, so it is independent of programming languages, software development methodologies or even software tools and development environments. It was designed to be simple, powerful, flexible and extensible letting their users design models without concerning about implementation details not important at design phase. In UML, the domain model is described using a class diagram. Entities are represented as square boxes meaning classes and the lines between them represent the relations. There is a large set of semantic constructs in UML allowing the users to choose the most fit to their needs. Users can create new constructs using “stereotypes” giving user-defined semantic. Allowing this kind of features and its nature, the language becomes ambiguous. Some concepts are not formally defined; therefore they become ambiguous and can lead to misunderstandings.
Due to the ambiguity and the general purpose of this language, it is fairly difficult to minimize the gap between the conceptual model and the concrete implementation. Even though, there are some partial solutions to this problem provided in some of the modeling tools used to create UML models. Source code generation from UML class diagrams, is already well-understood, tough, as I stated before, it is not a complete translation therefore some information is lost. Constructs such weak or strong aggregation or information about associations are high-level concepts which cannot be translated in semantically equal code. As studied by some new software development methodologies pioneers [12] UML needs to be fully expressive to let an effective translation into efficient code be possible. The lack of efficient tools and inexistent reference implementation turns UML to be far away from the concrete implementation of a software application [4]. Some approaches [13] let to other solutions such as extending the target language with concepts of the model language, trying to pull the target language to the model language level. In fact, languages with metaobject protocols, such as LISP/CLOS, “blur the distinction between languages designers and language users”. However, this approach has several disadvantages such as target language features requirements and compatibly issues with legacy systems.

Domain Modeling Language

  • Motivation of the DML [1]
  • Explain the DML Runtime in detail ?
  • Compare DML with MDD approach ?

The Domain Modeling Language is an approach to reduce the gap between the abstract model language - such as UML - and the target language. The motivation of this work is the lack of support in Java for the implementation of associations between classes [1].
It is a domain-specific language designed to represent only the structural aspects of a domain model giving programmers a domain model implementation ready to be used. Model designers can use the DML constructs such as entities or relations to design the domain model. After its compilation, it results in a well-defined API available to be used. Developers can use this API, which semantically respects the model described using DML, to implement the business logic. They do not change or maintain the generated code; it is only used as an API able to give them all the classes and methods needed to implement entities and the relations among them.
Comparing DML with UML, DML has well defined semantics for the entire set of constructs available. It cannot be extended without defining a strict implementation pattern for the new constructs or features pretended. The possibility of defining a domain model using a well-defined language gives no space for ambiguities the way UML does.
For communication purposes among the development team, it is far simpler to transform a DML model into an UML diagram than the opposite. Despite this possibility, it does not mean that UML to DML translation is doable or pretended. Other representations of the domain model, such as a graphical one, can be done using graphical constructs within the same meta-model as UML does.
DML was designed inspired by the lack of features in Java and it is pretended to be used within a Java solution, therefore its syntax is a based in Java syntax. It was meant this way because most of the programmers are familiar to Java syntax and since its target language is Java it was clearer to be that way. Nevertheless, it is possible to create different back-ends for different target languages.

Solution's Architecture

  1. Identify the several new features such as indexed, ordered, transitive, abstract and inherited relations.
  2. Identify the example cases in the Fénix project
  3. Propose pattern design for some of these features (indexed and ordered)

The steps of the work development can be :

  1. Identify possible features
  2. Gather requirements of the pretended feature
    1. Define explicitly what to be done
    2. Study different situations where the feature will be applied
    3. Identify examples of the feature (in Fénix or simple examples)
  3. Design different patterns of implementation
    1. Identify the most feasible one regarding the requirements
    2. Identify other problems related to that particular implementation
    3. Choose a pattern based on functional and non-functional requirements
  4. Implement the chosen pattern

Indexed Relationships

Ordered Relationships

Methodology for Evaluating the Work

  1. Measure the impact of the pattern in non-funcional requirements of the application (benchmarks evaluation)
    1. Is it explicit enough and simple to use by the developers ?
    2. Is it possible to measure the acceptance of the new feature by the developers?

Conclusions

References

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License