Identification of main problems of software development automation.

Masar, Alojz ; Masarova, Renata

1. INTRODUCTION

It is clear that the development of software requires the collaboration of different professionals. Different groups of professionals use different jargon, methods, techniques, means and tools. They also are interested in the software in distinct way.

Despite these differences, they use common sequencing of activities:

* Gathering of requirements.

* Evaluation and analysis.

* Design of solution.

* Produce output.

* Release output.

* Maintain changes.

These activities are used during every stage and at every level of abstraction event though they usually have various extents or iterations.

We concentrated on applications. The application is software, which:

* Is given to solve some problem of particular domain or to support activities of specific user process.

* Has at least one interface (to the user or to another system).

* Optionally is able to retain some information.

We looked at the process of creating application from a possibility its automation utilizing today's technology and tools point of view.

2. REVIEW OF PRESENT STATE

2.1 Approach

One of the respected concept of software development is the Model Driven Architecture (OMG, 2003). MDA provides the approach for, and enables tools to be provided for:

* Specifying a system independently of the platform that supports it.

* Specifying platforms.

* Choosing a particular platform for the system, and transforming the system specification into one for a particular platform.

MDA is successfully adopted for design and construction phase of the domain and the persistence. Also is usable for transition from the design to the persistence. It is supported by commercial tools. In spite of this, an adoption to the requirements gathering, evaluation, analysis and transition evaluation, analysis and transition to the design is still poor.

[FIGURE 1 OMITTED]

Activities of creating interfaces, notably the activities of creating the user interface, have some specialties (Jespersen & Linvald, 2003) which complicate the adoption of this approach to them. There is not any widely accepted and used standardised approach to develop the user interface.

The system interface is not so complicated. The functionality of majority applications is usually deterministic and the communication respect technological standards which determine communication rules of systems. The specialization of these standards prevent simply adopt MDA approach also to the field of creating the system interface. The starting point of solution would be acceptance of more general standards like the ESB (Chappell, 2004).

2.2 Method of expression

It is very important to properly express the outputs from and the inputs to the activities. This enables easier way of artefact transformation for each part of application and for every activity, generation of output/input from/to activities and increase chance of automation.

[FIGURE 2 OMITTED]

The most adopted formalism is the UML (OMG, 2007). The UML is the way of model application structure, behaviour, architecture, business process and data structure. However, this standard doesn't tolerably cover activities oriented to the interfaces. It is not oriented to support early activities of software development too. These are covered by special means of expression which are not integrated to the one concept.

The UsiXML is the low level formalism to describe user interface. It is based on XML and is currently being submitted for standardization. The UsiXML describes the UI for multiple contexts of use such as Character User Interfaces (CUIs), Graphical User Interfaces (GUIs), Auditory User Interfaces, and Multimodal User Interfaces. Application can be described in a way that preserves the design independently from peculiar characteristics of physical computing platform.

2.3 Tools

There are a lot of tools which support the UML and the MDA. Whilst the UML is supported very well, the support of the MDA is restricted to the expressing capability of the UML. Each tool realizes the transformations by its own way. They suffer from round trip problems too.

3. STANDING PROBLEMS

We inspected some other existing methodologies, methods, techniques and tools. We attempted to determine some weighty gaps of software development. We based our point of view on the high level abstraction of application, on the main activities of development process and on the possibility of adopting the MDA approaches.

We paid attention to the following evaluation criteria:

* Correctness.

* Maintainability.

* Comprehensibility.

* Support of automated transformations or code generations.

* Amount of effort to make output against of effort to make things by usual way.

* Round trip ability.

* Support of visualizations.

* Support of existing standards.

* Support of testing outputs and artefacts.

We discovered that serious lack of standardization lay mainly in the area of creating user interface and its binding to the domain. The transformation of requirements to the form convenient for automation was appointed as second area, which would be explored.

3.1 User interface

We found some promising approaches such as UIOAD concept (Doroodchi et al., 2006) or the MDA compliant environment for developing UI (Vanderdonckt, 2005). The UIOAD assumed relatively direct transformation from the UI to the domain. Therefore was quite limited. The environment described in (Vanderdonckt, 2005) was directed only to user interface. None of them was widely adopted or standardised.

3.2 Binding UI and domain

Some work had been done in this area (Belenguer et al., 2003) or (Drori, 2003). However, we did not discover any solid solution. These two areas have different main concerns and solve problems using different approaches. The presented information via user interface had sometimes different structure from the structure which was conformed to the domain. Therefore, direct transformation from one to another was difficult. The transformation required some new piece of information from opposite area to do its job successfully. Due to the new approach would be required.

The whole user interface need not be transformed to the domain and vice versa not whole domain must be prepared to the representation via user interface. The part of user interface, which could be good candidate of transformation is usually named presentation logic.

The research of this area would be the job of the next work.

4. CONCLUSION

We found, that today's way of creating applications mainly suffers from the lack of:

* Suitable formalism to catch requirements

* Possibility of transform vague expression of requirements to the more formal form which would be suitable for MDA style decomposition.

* Standardised way of creating interfaces. Especially this problem is visible for the user interface.

* Standardised tools which would support automation of producing outputs of early activities.

* Insufficient formalism to create transformations from inputs early activities to its outputs.

5. REFERENCES

Belenguer, J.; Parra, J.; Torres I. & Molina P. J. (2003). HCI Designers and Engineers: It is possible to work together? Proceeding of INTERACT 2003 Workshop, Harning, M. B. & Vanderdonckt, J. (Ed.), pp. 14-19, Zurich, September 2003, Institut d'Administration et de Gestion (IAG), Universite catholique de Louvain (UCL), Louvain-la-Neuve

Chappell, D. (2004). Enterprise Service Bus, O'Reilly Media, Inc., ISBN 978-0596006754

Doroodchi, M.; Farahani, B. K. & Moravej, M. (2006) User Interface Oriented Application Development (UIOAD). Proceedings of World Academy of Science, Engeneering and Technology, Volume 16, November 2006, 216-220, ISSN 1307-6884

Drori, O. (2003). Integration of HCI Needs with SE Methods Using OODPM Methodology, Proceeding of INTERACT 2003 Workshop, Harning, M. B. & Vanderdonckt, J. (Ed.), pp. 20-26, Zurich, September 2003, Institut d'Administration et de Gestion (IAG), Universite catholique de Louvain (UCL), Louvain-la-Neuve

Jespersen, J. W. & Linvald, J. (2003). Investigating User Interface Engineering in the Model Driven Architecture, Proceeding of INTERACT 2003 Workshop, Harning, M. B. & Vanderdonckt, J. (Ed.), pp. 63-66, Zurich, September 2003, Institut d'Administration et de Gestion (IAG), Universite catholique de Louvain (UCL), Louvain-la-Neuve

OMG; (2003). MDA Guide Version 1.0.1, Available from: ftp://ftp.omg.org/pub/docs/omg/03-06-01.pdf Accessed: 2007-06-25

OMG. (2007). UML 2.1.2 Superstructure and Infrastructure, Available from: http://www.omg.org/spec/UML/2.1.2/ Accessed: 2007-06-25

Vanderdonckt, J. (2005). A MDA-Compliant Environment for developing User Interfaces of Information Systems. Proceedings of the 16th Conference on Advanced Information Systems Engineering, Pastor, O. & Cunha, J. F. (Ed.), pp. 16-31, ISBN 3-540-26095-1, Porto, June 2005, Springer-Verlag, Lecture Notes in Computer Science, Vol. 3520, Berlin.