Customizable descriptions of object-oriented models

Abstract

With the emergence of object-oriented technology and user-centered software engineering paradigms, the requirements analysis phase has changed in two important ways: it has become an iterative activity, and it has become more closely linked to the design phase of software engineering (Davis, 1993). A requirements analyst builds a formal object-oriented (OO) domain model. A user (domain expert) validates the domain model. The domain model undergoes subsequent evolution (modification or adjustment) by a (perhaps different) analyst. Finally, the domain model is passed to the designer (system analyst), who refines the model into a OO design model used as the basis for implementation. Thus, we can see that the OO models form the basis of many important flows of information in OO software engineering methodologies. How can this information best be communicated? It is widely believed that graphical representations are easy to learn and use, both for modeling and for communication among the engineers and domain experts who tqgether develop the OO domain model. This belief is reflected by the large number of graphical OO modeling tools currently in research labs and on the market. However, this belief is not accurate, as some recent empirical studies show. For example, Kim (1990) simulated a modeling task with experienced analysts and a validation task with sophisticated users not familiar with the particular graphical language. Both user groups showed semantic error rates between 25% and 70% for the separately scored areas of entities, attributes, and relations. Relations were particularly troublesome to both analysts and users. Petre (1995) compares diagrams with textual representations of nested conditional structures (which can be compared to OO modeling in the complexity of the "paths" through the system). She finds that "the intrinsic difficulty of

Automated knowledge acquisition for instructional text generation

“…Another approach, exemplified by ModelExplainer [15], acquires lexical items for new domains by extracting text from object-oriented class diagrams. Although this is adequate for that application, the resulting KB is too "shallow" to support the generation of instructions.…”

Generating Natural Language specifications from UML class diagrams

“…With regards to systems that attempt to generate software specifications from design, there is relatively little research. These systems lack domain independence because they either assume a domain analysis prior to execution [22], or they do not perform domain analysis but do not guarantee that the generated text makes sense [40]. Although it has been widely recognised [14,36] that users should be involved in the early stages of software development and that natural language (NL) is undeniably the best medium of communication and understanding between software engineers and users, little work has been done in validating the software models in a way users can understand them.…”

“…Deep reasoning approaches are domain independent and expensive. It is worth mentioning that some NLG systems do not employ any sophisticated content determination techniques because they assume an interaction with the user where the appropriate concepts are specified while the input to the system is entered [16,40].…”

“…The ModEx (Model Explainer ) system [40] generates NL from the description of OO software models. Its architecture is composed of a text planner, a sentence planner, a realizer and a formatter.…”

“…This simplifies the overall architecture of the system and at the same time makes it extensible to any domain of application. In fact the authors [40] state "it lacks domain knowledge. This means that the system is fully portable between modelling domains and is not overly costly in use".…”