5 Instrumente CASE pentru analizã ši proiectare orientatã-obiect

5 CASE tools for object-oriented analysis and design

5.1 General presentation

The appearance of the analysis and design methods presented in the previous chapter is one of the solutions offered, the one referring to the methodological framework. After 1985, a significant part of research carried out was concentrated towards the automation of the software "production" process. In this framework, tools that can support, (partly or entirely), the construction stages of any medium or large sized system (specification, analysis, design, implementation, testing, use and maintenance), known under the generic term "CASE tools", have been designed and built.

CASE tools were built around a repository that memorizes the information used in the analysis, design and code generation stages.

Definition 5.1.1

Repository - A complex data structure, allowing an efficient storage of the information characterized by a great number of semantic links. The repository's architecture is object-oriented. Consistency preservation and the possibility to obtain information quickly through a natural and simple way is a basic requirement for any repository.

Considering the support given to the object-oriented paradigm, CASE tools can be classified in:

non object-oriented,

hybrid,

object-oriented.

In the following we will deal exclusively with object-oriented CASE tools. The object-oriented technology and the CASE tools complete each other happily. Object-orientation is not only an analysis, design or programming tool - it is a manner of thinking. The purpose of the OO CASE tools is to help system designers, end users or decision factors to visualize the system by the agency of constructed models. Using CASE tools allows quick building of systems with robust, checked structures, easy to change and maintain.

5.1.1 Classification criteria for object-oriented CASE tools

From our point of view, in order to classify the OO CASE tools, we have to analyze at least the following features:

the stages from the product's construction cycle for which the tool gives support:

the whole life cycle (I-CASE) - or,

one or more parts of the life cycle (F-CASE),

the structure of the code generated by the tool. If it contains:

only templates describing the classes structure and the static relationships among them, or

full code (by this we understand complete code for the methods body (if they are fully specified). An immediate consequence for this property is that the project can be quickly translated into executable code and tested.

the level of the information consistency preservation among different views of the same model,

the reuse support at all levels (classes, design templates, projects),

the support for formal textual annotations, materialized in the possibility of checking the formal textual specifications and their translation in the implementation language,

whether the tool allows iterative development or not. The return to an earlier phase, updating the related (dependent) diagrams.

the tool's ease of use,

the support for group work (by implementing some efficient project management concepts and mechanisms) and for networking (with the possibility of concurrent access to information and by providing effective protection for these activities),

the support for reverse-engineering. The reverse engineering (RE) tool's flexibility and the quality of class diagrams automatically built for the information offered by the RE tool,

the possibility for connecting the tool to an Integrated Development Environment (IDE),

the possibility of exchanging information with other tools implementing the same method.

5.2 ROCASE's position relative to the classification criteria

The tool specified, designed and implemented by us:

supports all the stages included in the system development life cycle,

generates "full code". Our statement is based on the manner of associations implementation, on the fact that it generates code for OCL assertions (class invariants, preconditions and postconditions), for explicit constructors - (the code generator for the body of reactive objects' methods specified by the State-Transition Diagrams is under implementation).

has a very high level of information consistency preservation (we don't know any other tool with similar performances),

provides reuse support for all the abstraction levels,

offers a real framework for using formal annotations, by implementing an OCL analyzer. Moreover, formal annotations are converted into C++ code,

supports iterative development by a round-trip engineering mechanism,

is extremely easy to use,

effectively supports group work by the conformity preservation mechanism. Networking facilities are not implemented yet,

supports UML. Taking into consideration the specifications of this "modeling language", it can support: OMT, Booch's method, Objectory and Syntropy. After UML's adoption as standard, we have considered the support for the other methods less important,

has reverse-engineering facilities offered by a high performance tool, called Phoenix. The quality of the automatic class diagram generator is outstanding,

is not included into an integrated development environment,

the component (module) that allows information exchange with Rational-Rose is under implementation.

5.3 ROCASE Architecture

The tool is splitted in modules, each having a well defined main functionality. The central element of this architecture is the repository. A great part of this chapter is reserved to describing the ROCASE architecture and functionality. As you can see from figure 5.1., practically all the tool's components exchange information with the repository one way or another. In the module design and implementation we have intended to achieve a maximal independence. Thus, the reverse-engineering module, called Phoenix, is practically entirely independent from ROCASE. The only link with the tool is made for exchanging the information obtained in the code analysis process. The diagram editor and the text editor have, in their turn, a high degree of independence. The same goes for the syntactical component of the OCL analyzer. Obviously, the semantic component is dependent on the repository's architecture. The code generator and the ROCASE browser are in the same situation.

Figure 5.1 - ROCASE - General architecture

5.4 Analysis and design of the ROCASE repository metamodel

The ROCASE repository metamodel:

describes semantics of the modeled concepts,

offers a reasonable formal support for the modeled concepts,

allows performing checks like an intelligent tool and supports the consistency preservation of information in the model,

supports information exchange among various tools and methods, one of the basic declared purposes of UML,

offers testing possibilities for the first standard adopted in the object-oriented analysis and design field, materialized by the adoption of UML.

The grouping of the modeled entities in subsystems is different in ROCASE from UML. ROCASE subsystems are: Types architecture, Project Management (Module diagrams), Classes and relationships (Class diagrams), States and transitions (State transition diagrams), Objects, bindings and messages (Object diagrams). Less detailed compared to UML, this division takes into consideration the use of entities in diagrams. The "basic module and composed module" concepts described in the Module diagrams subsystem support a project management which, in our case is more rigorous than in UML. Another fundamental feature that distinguishes the ROCASE repository metamodel from the UML metamodel is the formal annotation support, materialized in the possibility of declaring: invariants (at the classes and states level), preconditions and postconditions at the methods and events level. From this point of view, the tool also satisfies the Syntropy Method, proposed by S. Cook and J. Daniels [Cook94].

The type system is similar to those implemented in strongly typed object-oriented languages (Eiffel, C++, Ada, etc.). It considers that a class determines a type. A particular attention was given to generic classes modeling ("templates" in C++ terminology). This concern was materialized in modeling the concept of "generic derivation" (instancing template classes) and in the implementation of a semantic checking system. Initially, the solution adopted was closely linked to the genericity implementation in Eiffel, the most complete object-oriented programming languages known to us. The difference from the Eiffel type system consists in the fact that standard types (predefined), called in the ROCASE metamodel RCSBasedTypes, cannot be inherited. Thus, we achieved the necessary concordance with the implementation language type system, in which we generate code at present - C++.

Figure 5.2 - Architecture of ROCASE metamodel subsystems

5.4.1 Architecture in ROCASE

Figure 5.3 -- Architecture of ROCASE type system

The repository's architecture sets the upper level of the type hierarchy, RCSType but leaves open the lower level to be extended depending on the specific features of the object-oriented programming language in which the application code will be generated. In ROCASE, type architecture is flexible as it captures both existing relationships in strongly typed languages (C++, Eiffel, Ada) and those in untyped languages (Smalltalk, etc.).

The direct descendents of the abstract class RCSType are grouped in two basic categories. On the one hand, inheritable types, represented by the abstract class RCSInheritableType (and its descendents) and on the other hand, uninheritable types, modeled with the help of the RCSStandardTypes classes (and of its descendants RCSEnumeratedType, RCSSubdomainType) and RCSDummyType created for modeling formal generic parameters. Another distinctive feature for the two categories, as they have been modeled, is the fact that while inheritable classes can be abstract, all the classes from the second category, RCSStandardTypes, are concrete. In the case of the RCSInheritableType classes, this information is stored in the boolean attribute m_abstract.

Modeling generic RCSTemplateClass classes led to the apparition of two other classes: RCSDummyType and RCSInstantiatedClass. RCSInstantiatedClass models classes obtained by instancing at least one formal parameter of a generic or incompletely instanced class. Instanciation can be partial or total. Only completely instanced classes can have objects.

5.4.2 Architecture of module diagram entities

The project is made up of one or more composed modules, instances of the RCSComposedModule class (which, in their turn, can contain other composed modules or based modules instances of the class RCSBasedModule). Each instance of RCSClass is defined in only one based module, but it can be used in different based modules if the class' and module's visibiliy is interface. In ROCASE, the concept of module is equivalent to that of UML subsystem. The module's functionality must be, as much as possible, independent from the other modules functionality. Use relationships can exist between modules.

In ROCASE the module's role is double. It favors the increase of the project's intelligibility and imposes a discipline in the classes' management. ROCASE, through the feature called visibility, fills in the lack of the package concept in OOLs other than Java and Ada. As modeled in ROCASE, the module can also be used for managing design patterns.

Figure 5.4 Architecture of the "subsystem's" project management entities

The use relationship between two modules can be explicitly specified by the designer or automatically detected by the tool and rendered at module diagram level after the materialization of a client-server type relationship between two entities belonging to different basic modules. A special use relationship refers to the modules called BasicTypes and CollectionTypes. They are at the user's disposition from the beginning of a new project. The BasicTypes modules contain "based types" if the user declares attributes', methods' and parameters' type. The CollectionTypes instances are used if the module contains multiple associations, implemented in ROCASE by the Collection classes specified in OCL, or if the module contains generic Collection classes or classes instanced from them.

Further on, the thesis presents the subsystems' architectures:

class diagrams,
state transition diagrams and
object diagrams

and explains the solutions adopted for modeling.

5.5 Performing semantic checking in the CASE tools

Keeping the project's semantic consistency eventually leads to the reduction of an important part of compilation and/or execution errors, depending on the type of the language used. Moreover, checking is important in application's incremental development - removing of some system components should lead to automatic exclusion of all entities dependent on those eliminated or updating the references towards the eliminated entity. Lack of checking can lead to unpleasant situations, having as consequence the impossibility of using the model built.

There are two possible approaches with regard to the checking time:

implicit checking -is performed at the tool's initiative, while adding, modifying or deleting entities in the internal model,

explicit checking -is performed at the explicit user's request, before using data stored in the model for certain operations (like checking part of the model, saving, code generating, etc.).

Each of these two approaches presents advantages and disadvantages:

Implicit checking has the advantage of being distributed in time, therefore avoiding a long checking operation. Besides, this approach does not allow the designer to introduce errors that could propagate afterwards in such a way that after their detection it would be too late to correct them easily. On the other hand, it has a disadvantage: the lack of flexibility - sometimes, imposed restrictions can become annoying. The reason that determined us to impose this rigor was the desire to stop as much as possible the introduction of a chain of errors difficult to detect later. On the other hand, this type of approach increases the tools' teaching qualities. Moreover the chosen variant greatly simplifies operations that must be carried out in the event of a global checking.

Explicit checking is executed when it is desired to use the project for a certain purpose like: code generation, state chart diagram architecture validation, etc. Such checking has the advantage that error detection is not blocking. The main disadvantage of this approach is the time necessary for correction, greatly influenced by the side effects leading to the domino phenomenon of errors propagation.

5.5.1 ROCASE approach -general presentation

The approach adopted in ROCASE is mixed: both implicit and explicit checks are performed. Implicit checks allow the user a certain flexibility absolutely necessary in case some late decisions must be made. The designer can assign entities the "pseudotype" Undefined and postpone the type declaration until just before automatic code generation or even after, if there are good reasons for this decision.

Operations that can be carried out on the ROCASE metamodel are: adding, deleting, modifying (updating) entity properties. Adding and deleting RCSDiagramEntity descendents is carried out exclusively by the graphical editor. Operations referring to textual annotations are carried out with the help of dialog boxes.

Implicit checks - carried out when adding an entity, do not allow the user to execute operations that may lead to conflicts or inconsistencies in the system. For example, we present a few operations that are realized when adding an entity:

Inside a visibility domain conflicting names are forbidden.

The operation of declaring an entity's type, descendent from RCSProperty is assisted by the tool. In this case, a project instance can only receive a type visible in the respective domain, which is shown in a list. The freedom necessary to the user in the analysis phase or sometimes even in the design one is offered by the Undefined "pseudotype", whose presence is always signaled in the final checking phase or before a code generation operation.

The declaration of the following relationships is forbidden:

illogical (cyclical inheritance, inheritance relationship between a generic instanced class and another class, association relationship between an instanced class and another class, inheritance between a simple class and a generic or partially instanced one, inheritance between template classes that do not have the same number and type of generic arguments)

unacceptable inherited relations in the case of a number of programming languages - repeated cyclical inheritance (unaccepted in C++, but accepted in Eiffel)

useless or incompletely specified - associations that cannot be followed in any direction, declaring multiple associations without indicating the collection type, declaring qualified associations without specifying the qualifier or a derived association without specifying alternative navigation paths.

5.5.2 Checks performed when adding entities to the model

In this paragraph we will refer to the checks performed when adding entities to the model through its interface.

5.5.2.1 Adding a use relationship between modules (RCSModuleUse)

Figure 5.5 - Use relationships between two basic modules

For a correct representation and the complete use of information concerning this relationship, we must specify that it can have two different meanings. If the user adds such a relationship in the analysis phase, this means that permission is granted to the client module's entities to use the server module's entities. Normally, this permission is materialized when a client module entity calls on the services of a entity of the server module. After materialization, the line style used for rendering changes. The solution we have chosen offers another advantage too. If the user declares a utilization relationship that will not be materialized, he can be warned after performing a checking. In the situation when between two modules a use relationship has not been declared, but the user declares a client-server relationship between two entities defined in different based modules, the tool automatically creates the use module relationship, introduces it in the metamodel and shows it on the diagram.

Information referring to an entity visibility is stored into an enumeration type attribute. In UML, the enumeration type instance, the same for all the model's entities, is called VisibilityKind and has 4 values {public, protected, private, implementation}. In ROCASE, we have considered sufficient that modules and classes have only two values {interface, implementation}, that allows representing all situations.
5.5.2.2 Declaring an entity's type

Is one of the most important decisions taken when designing a system and later when transforming the design model into the code written in a typed programming language. In order to take advantage of the project management mechanism implemented with the help of the module concept and of the visibility property existent both at module and class level, the type that can be assigned to a project entity must satisfy visibility constraints. The tool implemented by us provides effective support to the designer, placing at his disposition the set of visible types in each module.

In ROCASE, a type can only be declared at the level of a RCSBasedModule. Because of this, we are interested in the set of visible types in such a module, that we will call viz(M_p)'. Due to the role they can play, elements of visible type sets are also known as potential server types.

We will present the way this set can be calculated in two steps.

In the first, we will not take into consideration generic types. Then the set of visible types in the module M_p will be made up of the conjunction of the type set defined in this module with the type set imported in M_p.

viz(M_p)' = {T_p | T_p.definedIn == M_p} È {T_q | T_q Ì imp(M_p)}

The set of types imported in a module M_p satisfies the following definition:
Definition 5.5.2.2.1

Let: M_p, M_q, M_r be three modules of a system having the following signification:

M_p the basic module for which imp(M_p) is determined,

M_q a basic module (any) from which types can be imported,

M_r parent module of M_q,

that satisfy the following relationships:

M_p.isKindOf(RCSBasedModule) == true,

M_q.isKindOf(RCSBasedModule) == true, M_q ¹ M_p,

M_q Í M_r Ì MainModule - M_r Í M_p.containedIn (if M_p and M_q have a common parent different from MainModule, M_n is "the smallest common parent", or any parent of M_q, in any other case),

M_q.vizibilityKind == interface, and M_n.vizibilityKind == interface

Then, the set of types imported in the module M_p noted imp(M_p), is given by the reunion of the set of types with visibility interface, declared in the basic module M_q.

imp(M_p) = È {T_q | T_q.definedIn==M_q and T_q.vizibilityKind==interface }

Figure 5.6 - Imported types defined in a basic module M_q. M_p and M_q have a common parent module, different from MainModule - M_n. (The visibility of M_n and of the modules in which it is contained does not matter)

Figure 5.7 Imported types defined in a basic module M_q. M_p and M_q do not have a common parent module, different from MainModule. The visibility of all modules in which M_q is included must be interface.

In a basic module, are imported all the types with visibility value interface, declared in the basic modules other than the one in which the import is performed, on condition that the visibility of these basic modules and of those composed in which they are included (up to the nested level of the module that is "the smallest common parent" for M_p and M_q), is interface.

Taking into consideration generic types

In the first step, we have considered that all generic types are part of the potential server types of each module entity, which is correct only in the situation when the type is implemented through a generic class RCSTemplateClass. In the case when we deal with a type implemented through RCSSimpleClass or through RCSInstantiatedClass (irrespective of whether it is partial or total instantiation), dummy types, generic types and part of the partially instantiated types must be eliminated. We call the types that must be eliminated types introducing dummy dependencies. We will have to compute, for each type T, the set of dummy dependencies, given by:

Definition 5.5.2.3.1

The set of dummy dependencies of a type T noted dep(T), is given by:

dep(T) = Æ , if T.GetRuntimeClassName() = "RCSSimpleClass", or if - T.GetRuntimeClassName() = "RCSStandardType" (T is implemented by a simple class or is a standard type)

dep(T) = {T}, if T is of dummy type

dep(T) = T.GetFormalGenericArguments(), the set of types constituting formal generic arguments of that class if T is implemented through a generic class T.GetRuntimeClassName()=="RCSTemplateClass"

dep(T) = È dep(P_i), if T is a instantiated type class with actual generic arguments P_i, i = 1,..n(T.GetRuntimeClassName() = "RCSInstantiatedClass")

Example:

dep(Set[INTEGER]) = Æ

dep(Set[Sequence[T]]) = {T}

dep(Set[Bag[HASH_TABLE[T,Integer]],G]) = {T, G}
Definition 5.5.2.3.2

The set of potential server types of a T_p type (descendent of RCSInheritableType) defined in the basic module M_p, is given by the equation:

pser(T_p)=viz(M_p)'\{T_p'Ì viz(M_p)'|(dep(T_p')¹ Æ )and(dep(T_p')\dep(T_p)¹ Æ )}

In other words, the set of potential server types of a T_p type is obtained by eliminating from the visible type sets at the M_p module level of the types whose set of dummy dependencies is different from the set of dummy dependencies for T_p.

Example:

Let the type Class1<G> be defined in the module M. If viz(M)' = {T₁,..., T_n, Class2<G, H>, Class2<G, Char>, Class2<Integer, H>, Class3<H>, Class3<F, G>, F, G, H}, where T₁,..., T_n are implemented through simple classes. Then:

pser(Class1<G>)= {T₁,..., T_n, Class2<G, Char>, G } - for simplicity we have ignored predefined types and those defined in the classes Collection.

A similar constraint exists in the Eiffel language, to which we have decided to relate considering it the most representative language for the implementing manner of object-oriented concepts.

We will now present a few examples in which the set of pser(T) types is used for checks performed in ROCASE

Figure 5. 8 Inheritance relationships allowed between classes with different dummy dependencies

Regarding the relationships presented above we must point out that reverse relationships, in which, for example, Class_1<G> would inherit from Class_2<G,H> or Class_3 would inherit from Class_4<G>, are not allowed. There are still client server relationships in the case when in Class_2<G,H> we would have a declaration of the form: "Class_1<G> a". For the same reasons presented above, in Class_3 we cannot have declarations of the form: "Class_4<G>" a; or "G a". All these situations are discovered and forbidden in the semantic checks implicitly performed by ROCASE.

Taking into account the fact that any new ROCASE project must be able to use basic (standard) types and Collection types defined in OCL and used in UML for specifying multiple associations, we have decided that in any project, basic types be implemented in a basic module, named BasicTypes, and the Collection types in another basic module named CollectionTypes. These basic modules have visibility interface and are defined at project level, that is:

BasicTypes.containedIn == MainModule,

CollectionTypes.containedIn == MainModule

The instances of the enumeration and subdomain types, can be defined at the level of each module. If it is desired that some of them be global, to allow their referral from anywhere in the system, they can be defined in MainModule.

5.5.3 Checks performed when deleting entities from the system - through the graphical editor

While previous checks support the designer in building a semantically correct system, the role of the checks performed when deleting entities are to ensure preserving system consistency.

A first criterion to be taken into account is that if the entities that are to be deleted from the system are used as servers in other locations, different from the one in which the deletion is to be performed, the user must be warned.

Example:

Let A be a type defined in the basic module M₁. Suppose that besides the relationships in which it is involved as server, relationship declared in the class diagram where the modification is carried out (for example: class B inherits from class A, or in the class B we have an attribute declaration of the form A a1; etc), in another module of the project - M_i, we have another similar relationship in which A is server.

In this case, the effect of deleting A will reflect in all the modules in which it is used as server. To offer additional flexibility in the deletion operations category, ROCASE allows the user to change the module in which a class was defined with another module in which the respective class is used. This operation is called Main set. In this case, it is possible to carry out the operation of deleting the class in the module in which the entity was initially defined, its effects being limited only to the graphically represented entities, directly bound with the deleted class.

Figure 5.9 Applying operation "Main set" to the TutorialCom class
5.5.4 Checks performed when deleting entities through dialog boxes

This case refers to deleting attributes, methods, parameters or generic arguments declared in some classes. If the respective attributes or methods are used in formal annotations (class or state invariants, assertions referring to methods), events in state transition diagrams or messages in object diagrams, their deletion involves updating the contexts in which deleted elements are used as servers, either by deleting them, or by replacing them with Undefined. The general rule is respected in this case too, in the sense that when deleting a server is desired, the user is informed about its current clients, in order to take the correct decision.

Figure 5.10 - Deleting graphically unrepresented entities, with the help of dialog boxes
5.5.4.1 Checks performed when deleting generic parameters

Deleting generic parameters can cause some problems when at least one of the parameters that are to be deleted are used as server for declaring the attributes, methods or parameters' type. In these cases, the user must be informed in order to take decisions that would avoid such situations. The checking operation involves determining the respective entity's list of clients, displaying the list and warning the user - if the list is not empty.

5.5.5 Checks performed when modifying entities

All the modifications that can be executed in ROCASE are carried out trough the GUI, or more precisely by dialog boxes. The graphical diagrams editor allows only operations of introducing or deleting components. After carrying out such checks, the tool can automatically update information regarding the modified server in all its clients or forbid performing any modifications (in the event that these should introduce inconsistencies) and to present the user the list of clients of the entity that is to be modified. This way, the user can take the needed decisions so that the modification that are to be carried out on the server be possible.

In most cases, the checks performed depend on the entity on which modifications are to be done. Because of this, the modifications of each entity will be presented separately.

In the thesis, the situations that may arise are presented as well as the solutions for solving them when modifying:

name and/or import state for a module,

name and/or label of an enumeration type,

name and/or "margins" of a subdomain type,

name, export state or abstract or concrete class state of a simple class,

generic parameters of a template or partially instanced class,

name of an attribute or method or state of an attribute (stored or calculated).

5.5.6 Checks performed in object diagrams

Like in the case of the other kind of diagrams, the most consistent checks that can be effectuated refer to the design stage. Most of them are referring to keeping concordance between information in existing class diagrams and the information in object diagrams. Types that can be assigned to objects in an object diagram are part of the visible and instantiable type set at module level for which the respective diagram is built. Links between objects must be instances of the class diagram associations, for which compliance with the multiplicity order is verified. Messages sent are selected from those available in the receiver's interface. Thus, if methods from the receiver's class are implemented, the tool can automatically render the chain of messages generated after executing a method. If the methods' body will be implemented after the scenario building or if modifications have been carried out in the body of those methods, the object diagram can be automatically updated by the tool. The tool checks the values of the current methods' parameters.

5.5.7 Checks performed for the state diagrams

5.5.7.1 Conceptual framework

Building a rigorous framework for performing these checks require:

Establishing a correspondence between the concepts used in states transition diagrams: state, event, transition, entry and exit operations, and those used in programming languages: attribute (instance variable) and method.

Designating a suitable language (expressive and minimal) for specifying formal textual annotations that would allow a complete behavior description. It is desirable that this language (possibly with small extensions) allow the description of non-reactive objects' behavior, also known as transformational objects.

With regard to the condition previously mentioned, we specify the following:

State must be determined exclusively by boolean expressions whose operands are class' attributes. For pointer type attributes (associations) only the value of the reference can be taken into consideration (attached or not (void, null, nil)). Otherwise an object's state could be modified through actions upon associated objects, actions that cannot be mentioned in the state transition diagram. In this situation, the diagram cannot describe completely the objects' behavior.

Events in transition diagrams are in a bijective relationship with the messages sent to the objects or with internally generated exceptions - clock interrupts, etc. The way in which an object responds when receiving an event is described through the agency of an associated method. Because in programming languages messages are called (somewhat improperly) the method's name, the correspondence event - method is also bijective.

Entry and exit operations are an action list that must be performed when entering, or exiting a state. Each action name must correspond to the name of a method from the class protocol. In the case when sending an event to an associated object is involved, the communication path must be correct and the message must be implemented in the target's class.
5.5.7.2 Actions involving keeping concordance between information in the class diagram and in the states transition diagram
Checking state invariants

Checking the syntax of invariants is automatically carried out with the help of the OCL expressions analyzer. A convenient definition of state invariants and of the class invariant should also allow checking the implication invstate Þ invclass. This checking will have to be performed manually, otherwise it would uselessly complicate the analyzer.
Forbidden transitions

It is forbidden to introduce in the diagram:

transitions towards initial states, transitions from History or final states, (this involves obviously forbidding any self-transition for these states),

transitions from or towards the states machine associated to a class, which, from the graphical point of view is represented as a composed state,

transitions between two states belonging to two different orthogonal components of the same machine.
Name of states, events, transitions and the signature's conformity

To avoid strange situations encountered in other CASE tools, we have decided that each of the above mentioned entities (just like any other entity in the ROCASE metamodel) receives an implicit name. Excepting pseudo-states, the names of the other entities can be changed through the user's explicit intervention. To ensure conformity between events' signature and the signature of the associated method, the explicit name declaration is achieved:

when introducing the transition, by choosing a name from the list of modules included in the class protocol,

later, to verify if all transitions have an associated message.

Checking performed before code generation is intended to eliminate inconsistencies that can appear due to the use of inexistent methods in the protocol of a class.

ROCASE also checks:

the number of initial and history states with respect to their semantics,

the correctness of different transitions starting from the same state and triggered by the same event,

the correctness of postconditions, of entry and exit sections,

the minimal states diagram,

the transitions towards orthogonal states.

5.5.7.3 Checking depending exclusively on the architecture of the states transition diagram

These checks are performed in most cases after the complete description of the states machine or before code generation. They involve building two types of matrices.

states-events matrix, in which on one hand are mentioned all the events that can trigger transitions and on the other hand all the simple states from the states machine associated to the class. A cell corresponds to an event - state association. The information from the respective cell must contain the precondition that must be fulfilled to trigger a transition, the final state and possibly information referring to the postcondition, that can be displayed optionally.

Building this matrix invites to finding some answers to the following questions:

regarding states:

When the system is in a certain state, are there other events (except those mentioned in the matrix), that can have a significant effect in the respective state?

Are there additional states (noticeable or internal) except the ones mentioned?

regarding events:

Is it true that the only states in which a certain event has an effect on the system are those indicated in the matrix ?

Are there events that can influence the class behavior that are not mentioned on the diagram ?

square states- matrix called quality matrix. This matrix allows the determination of states that cannot be reached by starting from the initial state, of states or groups of trap states, of the possibility of reaching a state when leaving from a certain given state and of the number of transitions that have to be carried out in this case.

The previously described matrices are built for transition diagrams of flattened states (in which all states are on the same level). In addition to this, checks can be carried out referring to the architecture of the states' transition diagrams before their flattening.

For this purpose in the thesis were stated and demonstrated the following lemmas:
Lemma 5.5.7.3.1

If the states machine associated to an instantiable (concrete) class does not have at least one entry state from which starts a transition towards a simple state, then that machine is incomplete.
Lemma 5.5.7.3.2

Let a states machines contain at least one composed state in which at the first level, entry states are not included (not associated to a constructor) or history states, or contain an entry state (not associated to a constructor) from which there is no path towards a simple state. If towards the composed state there is at least one transition and if there is no transition starting from the exterior of the composed state towards a simple state included, the machine is incomplete or redundant.

Further on in the thesis, are presented the algorithm for flattening a state, described with the help of the Harel formalism, and the algorithm used for determining unreachable and trap states.

5.5.7 Conclusions

Defining and implementing a consistent check set has a crucial importance for a CASE tool. Ideally all checks would be performed automatically. For the time being, this is impossible. The current situation has several causes. The most important are the lack of a formal framework which would include information for all checks, the complexity and even the impossibility of performing checks even in the event when all the required information were available. However, signaling all "delicate" situations for which the designer has to take decisions is of great help. The checks mentioned and implemented in our tool offer a framework in which systems can be more rigorously implemented than when using other existing tools.

5.6 The OCL analyzer

Is an important component of our tool. It supports effectively the use of checks because, as we have shown in the previous chapter, OCL is a language used by UML for describing formal textual annotations.

Our tool is conceived in such a way that only syntactically and semantically correct OCL expressions are accepted for inclusion in the repository. Semantic correctness refers to the visibility and to the operands semantics, not of the expression as a whole. Expressions analysis is a two step process, carried out with the help of two analyzers: one syntactical, the other semantic. If the analyzers detect an error, the user is informed about its type so that the necessary corrections can be made.

Figure 5.11 OCL Expression Analysis and the generation of the associated code in ROCASE

Being supporters of programming by contracts, we have decided to extend the OCL use. OCL annotations are translated in C++ code, thus being used for system validation. Therefore, class invariants are transformed in C++ assertions included both in the constructor body and in the function members capable of modifying the state of the object.

5.7 Code generation in ROCASE

In most cases, obtaining an executable system fulfilling the requirements imposed by the system users is the final goal of a project. For medium and large sized projects, and in many cases even for small sized projects it is preferable to automatically generate the code. Two important reasons support this conclusion. One is referring to requirements, the other to implementation:

Matching code written in a programming language with the requirements expressed in natural language is not a simple problem. Between programming languages and the natural ones there is a big difference. Models allow capturing the requirements and expressing them in a much more transparent and in the same time abstract manner, thus allowing an easy transformation into code. The concepts with which object-oriented models operate are well suited to the real world's concepts. They allow a higher abstracted level than the code that has features that are specific to each programming language.

The system implementations must often by modified (changes start even while writing software). There are various reasons imposing the change: changing the functionality requirements, requiring the application extension on different platforms, requiring the use of new libraries, etc. Unfortunately, most programming languages, even the best ones (and C++ is not necessarily one of them) are often too rigid, if changes need to be made. They mix low level constructions with high level ones, in such a way that modifying one affects the others. Models allow a greater part of the code (but not the whole code) to be generated, starting from a form that clearly separates high level abstractions from low level programming details. Thus, changes made on the implementation do not influence the systems logic.
5.7.1 Code generation possibilities

When operating with static models - (represented by classes and module diagrams), code generation is to a great extent declarative (defining classes, types and modules). But it can also include methods' generation body for access functions and other operations: constructors and destructors.

For reactive objects, the methods' body can be generated starting from the states transition diagrams and the main function code, using information provided by the object diagrams. For transformational (non reactive) objects, the code can be generated using the information from activity diagrams. Another option is using information offered by a formal description (presented in the thesis in the m FOOPS Appendix). The options previously mentioned suppose the translation of the modeling information, expressed in a specification language, into source code. In some situations direct coding in the programming language is preferable. This goes especially for simple methods, whose code is expressive enough.

5.7.2 The relationship model - generated code

Generating class structure is not a problem, because most object-oriented languages directly implement the class concept. But the module concept is implemented only in a few languages (Java and Ada, where it is called package). Other important concepts: state, association, etc. are not implemented in programming languages. They must be implemented using other concepts or mechanisms supported by languages.

5.7.2.1 The structure of the generated code and the management of #include directives

The code generator implemented in ROCASE uses a set of conventions for placing generated code in files. These conventions are consistent with the structure of the model described in ROCASE and with C++ programming usage, being materialized in the following rules:

Generating code is implicitly performed in a project subdirectory. This subdirectory, named CodeGen is automatically created when saving the project or generating code for the first time. Each project has associated a composed module MainModule that contains all the other project modules, hierarchically organized. The code generated for classes declared in each basic module is included in a subdirectory (of the directory corresponding to the composed module) with the same name as the basic module. For each module a file having the module name and the .h extension is created. Any composed module will contain an #include directive for each module contained or used by it. Basic modules will contain an #include directive for each class defined in the basic module and for each module used.

For each class (instance of RCSSimpleClass) two files with the class name are generated. One with the .h extension and the other with the .cpp extension. The file with the .h extension contains the class declaration, and the file with the .cpp extension the implementations of all the class' methods (including the ones automatically generated).

For the RCSTemplateClass instances only one file with the .h extension is generated, and for the RCSInstantiatedClass instances no file is generated.

Declaration of subdomain and enumeration types is included in the.h files associated to the module in which these types have been declared.

Figure 5.12 - Automatically generated code for the structure of the Conference class

5.7.2.2 Code generation for class structures, attributes and methods declarations

The concepts of class, attribute and method appear both in modeling and programming. Being directly supported by object-oriented programming languages, code generation for these concepts is performed almost directly, taking into account the following rules:

For each simple or generic class, defined in the model a C++ class with the same name is generated. Inheritance from the internal model is translated in C++ inheritance. The implicit export state for inheritance is public.

For each stored attribute an attribute is generated, with the same name and type and optionally, two member functions (methods): get<nume_atribut> and respectively set<nume_atribut>. They are implemented in the macros:

DECLARE_ATTRIBUTE(attributeName, attributeType, get_visibility, set_visibility)

IMPLEMENT_ATTRIBUTE(attributeName, attributeType, className, get_visibility, set_visibility)

For each derived method or attribute declared in the project a C++ member function is generated. The C++ code associated to member functions can be generated automatically, using information in the state transition diagrams, or can be explicitly introduced by the user in a dialog box.

For each class, ROCASE generates implicit constructors and destructors. The generated code for explicit constructors is realized at the user's explicit specification.

5.7.2.3 Generating code for associations

In ROCASE associations are unidirectional. Bi-directional associations are formed of two unidirectional associations the modification of which must respect the requirements imposed for consistency, presented in the thesis paragraph 4.7.2.1.

With regard to the model in which they are defined, features of a project's elements can be: logical features, design features, and specific features of the target language. The project's evolution always takes place by adding new features, and not by replacing. Finally, the implementation model will contain logical features, design features and features specific to the target language.

Design information can be modified without changing logical information. Thus a distinction of analysis decision from the design ones can be made, as well as a significant reduction of the risk of accidental changes of requirements during implementation. On the other hand, if analysis information is changed as a result of requirement modifications, the generated code will be automatically updated with these modifications.

In the thesis are presented the user's options concerning the code generated for associations, and the macros used for implementing simple and multiple associations. For implementing multiple associations our implementation of the collection classes specified in OCL is used. In ROCASE, this implementation also serves as reusable components.
5.8 Examples of using the ROCASE to design and implement applications

For any new tool, its usage for designing and implementing applications is one of the most important validation activities. In this activity takes place a first identification of the tool's strong and weak points.

During 1998, the following systems known from literature were realized: "Home Heating System, Problem Reporting System" [Booch91], "Conference Registration" [Walden95] and "Document Filling" [Derr95] as well as a set of examples that demonstrate the possibilities offered by the code generator.

In Appendix C of the thesis are presented the modeling solutions proposed for these systems and the results obtained (materialized in the generated code).

The conclusions obtained after the completion of the above mentioned projects can be thus summarized:

Using the tool for designing and implementing systems considerably reduces realization time and exempts the designers from almost all of routine activities.

The tool is extremely powerful, especially with regard to the design stage.

Due to the semantic checking performed by ROCASE, and to the code generator's qualities, the code is compilable and executable.

Our tool generates code for the system's structure, for the associations management, for the constructors and destructors and for de assertions.

Introducing consistency rules for bidirectional associations in the generated code, has proved very useful.

The fully translation of the OCL specification in the C++ code, increased the system correctness.

The Collection template classes can be used both for generating associations code, and for various systems in which containers are used,

Implementing the possibility to import classes, design templates or even projects from previously analyzed libraries or applications with the "Phoenix" tool is extremely useful. From the point of view of reusability, it is capital.

Extending the tool with component management facilities, will lead to an increase of performances.

Using object diagram informations to the code generated for the main "programme" (main.c) is possible and useful,

Project management variants can be conceived and implemented to reduce the number of dependencies (#include directives, - in the sense of introducing several classes in a single file). This is consistent with the files role in C++ projects, as an independent compilable unit.

5.9 Conclusions

The uninterrupted activity in the OO CASE tools field in the last four years, the results obtained, entitle us to state the following:

CASE tools play an essential role in the new software engineering technologies.

Between analysis and design methods (visual modeling languages) and CASE tools supporting these languages there is a perfect symbiosis.

The first role of CASE tools is to validate the metamodels proposed by the new modeling languages. For this activity, they offer the best framework.

The realization of medium or large size projects and team work support are practically unconceivable without the effective assistance of CASE tools.

CASE tools are certainly the technology for software development that will be used in the future in symbiosis with development environments. Our statement is based on the fact that:

Representing project's information in graphical form accompanied by textual annotations is:

much more suggestive, being easier and quicker understood by a greater number of people,

much more complex, because it presents several orthogonal views of the same entity,

extremely precious for building medium and large sized systems using a great number of components.

There is the possibility of performing consistent semantic checking allowing the exclusion of a great number of errors from the early stages of the system's design.

Tools can help to the consistency and completeness checking for the systems. In the analyze stage they can help the designer to visualize the project outcomes. When studying a module diagram, a developer may wish to study in detail a particular mechanism; the tool can help him locate a certain objet's class, see the object's place in the inheritance tree.

Using tools in the activities of developing software systems relieve the designers of caring for details, thus allowing them to concentrate on the design process.