The final purpose of a method is to gather the pieces of information necessary for describing a given problem and the solution to that problem, and to support the very implementation of that solution. Thus, it is clear that the system implementation (code generation) has to be taken into consideration, naturally followed by its testing. This is, after all, the final purpose for most projects.

Unfortunately, even the meaning of frequently-used terms like request, specification, analysis, design etc. is different from that in spoken English, being defined for small communities.

• Fundamental modeling concepts necessary to obtain the semantic information relative to a problem and its solution.
• Views and notations used to present the users the main information related to modeling. The presentation must be made in a way to allow their easy understanding and modification. Normally, views are graphical but with the current multimedia technology interfaces can also be realized. The views present only a part of the whole semantic model, and different views can present the same semantic information in different forms.
• Iterative processes used step by step to construct models and to implement them. Processes can be described at different detail levels, from complex project management to low-level models. Processes describe the construction mode for specific models. They can also specify the basic rules for evaluating the project quality.
• Empirical rules recommended for the project development. These rules are not organized in steps and can be applied whenever they make sense. From one point of view, templates are a description of some successful experiments realized in a uniform manner. They represent design solutions to frequently encountered problems. Templates can be applied at different detail levels, from large scale architectures to low level structures and algorithms.

OO technology leads to a very flexible recursive model. First, the initial requirements are analyzed and a preliminary model is designed. The class structure and the model interfaces are then transformed in a new set of requests for the next abstraction level. The analysis and the design are applied dually a number of times until the desired level is obtained. In most cases, this level means executable code.

While specifying the requests or while analyzing, the abstraction level can be higher and details can be omitted. In these phases what is important is the clear problem understanding. During the design and the implementation stages, we must offer enough data to construct the application. The possibility of constructing views for different abstraction levels is one of the characteristics of the design and analysis methods, one of their qualities.

The answer to the question "How much can the design and analysis activities be combined ?" depends ,first of all, on problem complexity. For simpler problems (as mentioned in Syntropy [Cook94]) the design model can be made directly without passing through the analysis model. The answer to this question depends though on the experience and the characteristics of the application's work team.

The possible clasifications are not rigid, for at least two reasons:

• core concepts that are not understood in the same way by the scientific community,
• every method supports mainly an aspect or another, but without completely neglecting the others.

The technique used to identify and describe the objects and the relationships between them allows us to classify methods (from the first and second generation) in three big cathegories:

• data driven
• behavior driven
• use case driven

Along with the above-mentioned classification criterion we can also take into consideration:

• the life-cycle stages supported by the method (analysis, design or analysis and design) and
• the degree of formalism

Is used to describe the formal textual annotations in UML, having the following features:

• it is a typed language (every entity has a type)
• it doesn't support the concepts relative to implementation - (OCL is a modeling language)
• it has no side effects. The expression evaluation does not lead changements of the object state. The only effect obtained after the an OCL expression evaluation is the return of the desired result,
• it is not a programming language. Thus, it is not possible to write a programme in it.

The following domains have been taken into consideration for using the language:

• specification of model constraints
• specification of the stereotypes' type invariant
• description of pre- and post-conditions for operations and methods
• description of the protections
• navigation within the model architecture
• specification of some operation constraints.
• Core concepts for modeling in UML 1.1

The detailled definition of the concepts used in the analysis and design methods is one of the core objectives of UML. Even if it doesn't declare it explicitely, UML must offer the minimal basis necessary for classifying the modeling concepts. A first classification, explicitely made, refers to the concepts organization in packages and subpackages, relative to component functionality. Another classification has as basis the implementation of modeling concepts in OOLs, or in a larger context the correspondance between modeling concepts and concepts implemented in programming languages.

Within this classification we distinguish three cathegories:

• concepts used by programming languages (class, attribute, method, type, package, interface, visibility etc.)
• concepts that are not used in programming languages, but the introduction of which is extremely useful and is worth doing as soon as possible (associations, aggregations, state variables etc.)
• concepts which are not closely related to programming languages (actor, use cases, role, colaboration, interaction, etc.)

Packages, classes, associations, generalizations, states, events, transitions, use cases, collaborations are some of the most important modeling concepts used in UML. For a better management and understanding of their semantics, the metamodel components have been grouped in three packages. In their turn, these packages are organized in subpackages. Of the three packages, only the one named "Foundation" is independent. Grouped in the subpackages "Data Types", "Core", "Auxiliary Elements" and "Extension Mechanisms", the concepts defined in the package "Basic elements" form the so-called metamodel core. These specify the architectural components necessary for an elementary metamodel and define the framework necessary for adding some suplimentary language constructions, metaclasses, metaassociations and metaattributes.

Is the most important, being the only independent package. The concepts defined in it are reffered by the concepts defined in the other two packages. They introduce the concret and abstract constructions necessary for making any model. ModelElement, GeneralizableElement and Classifier are the most important abstract constructions, while Class, DataType, Attributte, Operation, Method and Assocoation are some of the most important concrete constructions.

Represents the highest abstraction for any entity of the modelled system. In a NameSpace, any ModelElement is caracterized by its name. A ModelElement can have associated lots of constraints and can be associated with other ModelElements as client or supplier.

NameSpace, Characteristic, Parameter and Constraint are the four direct descendants of ModelElement. Of these, NameSpace and Constraint have a special role because, as seen in figure 4.4, they can be associated to any ModelElement. All GeneralizableElements are modelled as descendents of a NameSpace. Thus, the operations defined in NameSpace are extremely important. Along with the operations defined for Classifier (another fundamental concept of the UML metamodel), they are used at defining the behavior of many concepts presented within the metamodel.

Figure 4.2 - Components of the Core subpackage

The component vizibility in a name space is elegantly modelled by the association class ElementOwnership. This class ties ModelElements to the NameSpace to which it belongs. A very inspired solution, it highlights the fact that vizibility is not an exclusive feature of ModelElement or of a NameSpace. It defines the association of the two. Still, the concept of feature, modelled by the class with the same name, has in its turn an attribute vizibility, which has the same role and name as the attribute of class ElementOwnership. Here we have an over-modeling, class Feature, a direct descendant of class ElementModel, which inherits all the associations of the latter, including ElementOwnership. Consequently, the inclusion of the attribute vizibility in class Feature is not justified.

Any model entity that can participate in a generalizing (specializing) relationship is a GeneralizableElement. The generalization and association relationships are the most important relationships that allow the classification of a model's elements. Generalization is not modelled as a descendent of the depending relationship, as it would be natural. Both of them are modelled as direct descendants of ModelElement (see figure 4.5 Relationships).

Is the abstract construction which describes the behavioural and structural caracteristics of the model's elements. In the metamodel, a classifier allows the declaration of an attribute, operation and method set. Generally called features, attributes and operations are contained in the NameSpace associated to the classifier and can be referred by the association with the role name OwnedElement inherited by Classifier from NameSpace as it was shown above. In the class diagram prezented in figure 4.4, the Classifier has an agregation to Feature class and an association to StructuralFeature class, a direct descendent of the first one, both having the same name for the association end "feature". Besides the fact that it doubles the information, this modeling cannot be implemented, as within the same "Classifier" class we cannot have two characteristics with the same name but of different types. Moreover, the bidirectional association of StructuralFeature and Classifier allows the StructuralCharacteristic instances to know its associated type. Unfortunately, not the same thing is happening with BehaviouralCharacteristic, even if the information tied to the type returned by a characteristic is absolutel necessary in a typed environment. Our proposal relies on the fact that any characeristic is typed. In this case, the correct solution would be the inclusion in the class diagram of the standard stereotype <<type>> associated to Class and the declaration of an association between Feature and <<type>>. The proposed modification would allow the determination of the type of the BehaviouralCharacteristics as well as the removal of the association between Classifier and StructuralFeature.

Figura 4.3 - The core subpackage - Relationships

Instance, Class and DataType are direct descendants of the Classifier, presented in the figure 4.4 diagrams. In the AuxiliaryElements package, Classificator gets two new deescendants, Node and Component, and in the other two packages, three other - Actor and UseCases in package BehaviouralElements and Subsystem in package ModelManagement. We wanted to explicitate the whole descendant list because between the first three (represented in figure 4.2) and the other five there are notable differences that greatly diminish modeling naturalness. It is first of all about the fact that the first three are well defined, having direct correspondants in the programming languages, while the rest, apart from the fact that they have no correspondent in the programming languages, are more vaguely defined except for the concepts of Actor, UseCase and Subsystem. (While the structure for Instance, Class and DataType is explicitely defined, for the other five no structure is explicitely given.)

Still, even in the "group" formed of the first three, the operation is the only common characteristic. As it is known and even mentioned at the presentations of Interface and DataType, these elements do not have attributes or methods. They only have operations. This also happens in the case of Actors and UseCases.

The normal wish of factorig of the metamodel's components at the highest level possible, demanded the introduction of a much higher number or verifications, thus resulting a less natural modeling for the components which have a direct correspondent in programming languages. Our point of view is that this subject will have to be seriously considered when constructing some performant instruments which will have to respect the UML metamodel.

Another factoring consequence is the fact that DataType, a Classifier descendant, appears as being a GeneralizableElement, a property competely true only in Eiffel.

Every object created by a class will contain its own value collection corresponding to the StructuralCharacteristics declared in the class. In Java, a class can implement many interfaces.

The diagram presented in figure 4.6, taken from "UML v 1.1 Semantics", pp. 39, raises a couple of questions:

• In the UML documentation it is not explained what ModelElements (other than attributes, operations and methods) enter in class componence. Thus, the presence of ModelElement as a component of the logical element of a class is not necessary, especially at this generalization level, and with no associated constraint.
• The aggregation relationship between Class and Method is not placed correctly. This is because a method is the implementation of an operation. The correct place for the above-mentioned aggregation relationship must be between the Operation (the whole) and the Method (a part). In this situation, due to transitivity, the Method will be in its turn part of Class, by the agency of the Operation.

The different presentation for AssociationRole and Attribute is suggestive for the different functionality of the two concepts.

The introduction of the relationship in the definition of the class is arguable. In the case of 0 .. n multiplicity associations, not all the class instancies have such relationships. It is true that all the instancies of client class have implemented the support for relationship construction, which is another thing. It could be argued that most classes fulfill their responsibilities with the help of collaborations, so making use of relationships. The counter argument for this assertion is the unanimously accepted definition of the class as an implementation of an abstract data-type, definition which does not take relationships into consideration. Relationships are truly important for a mechanism or for the components of a subsystem.

The attempt to factoring the properties at the highest level possible, the important differences that exist between the definitions of validated concepts, the definitions of newly introduced concepts and the great number of concepts are the main reasons for the present situation. This is caracterised by the existence of some inadequate modelings, i.e. redundant or with a high degree of ambiguity.

On the other hand, the adoption of UML as standard has led to a great increase of the number of language users. This aspect will undoubtedly favour the test and validation process of the new concepts and techniques. The use of the language will support the definition of a core of the metamodel that would be accepted by most specialists.

Depending on the objectives, the analysis and design methods used, and the complexity of the problem, several models are built. Each of them can be described by one ore more views, represented by associated diagrams. The views are orthogonal and allow the complete description of a certain model.

A model is a system description, which it describes from a certain point of view and at a certain abstraction level. A model is complete if it completely describes the modelled system, at the chosen abstraction level and from the point of view taken into consideration.

A view is the description of a well-defined aspect of a model. Some views have a formal interpretation, others are rather informal.

A diagram is a projection attached to the view's elements. The same elements can appear in several diagrams. In a diagram it is possible to present only a few details of a particular event, not necessarily all of them. All diagrams are represented by graphs. View entities are represented by nodes, and the relationships between entities by arcs.

In the UML models, the following views can be constructed:

• use case view
• logical view (static or dynamic view)
• components view
• deployment view

To each view correspond one or more diagrams. The basic role of diagrams is to offer the framework for the analysis and design stages.

Generally, the activities performed when developing an application are the following:

• identification of all use cases and their description,
• refining the description of use cases by factoring the common parts and by describing the relations between these cases,
• instantiation of use cases using object diagrams,
• identification of subsystems and packages (modules)
• identification of the classes corresponding to the objects identified in the object diagrams,
• deciding upon class semantics and relationships,
• identification of the design templates that are recommended to use,
• implementation and testing of the classes.

For small applications, the start coincides with identifying the objects and classes which form the problem's subject. The final purpose is the "identification" of all the entities of the problem's domain which will play a role in the application. Then comes the specification of interractions among entities. For each entity the following will be specified: its functionality, the services it needs for fulfilling its responsibilities, the associated objects which will offer these services. The activity stops if no more abstractions or important mechanisms can be found or if the classes that have already been discovered can be implemented with the aid of existing software components.

Design patterns are solutions for the key aspects of a common design structure, solutions repeatedly validated by practice.

Key aspects highlight the fact that design templates concentrate only upon the most important aspects of the design problem. After the discovery of the solution, it is sought that the generality degree of problem formulation and of its solution should allow the successful reuse of the pattern in as many situations as possible.

Common design structures are related to problem size, in direct relationship with the solution size, reflected in the number of classes used, at a medium granularity level. Neither simple problems, the solution of which can be expressed by means of a single class (the design of linked lists, hashing tables etc), nor problems of large or medium size are taken into consideration.

Generally, a pattern has four essential elements:

1. Name
2. Problem
3. Solution
4. Consequences

The use of patterns brings real benefits to application designers, like: decrease of making costs and time, increase of application quality because of an increased flexibility and better component testing. The increase of the designers' knowledge level, who will have to know as many patternsas possible, is the price that has to be paid to obtain the above-mentioned benefits. On the other hand, the continual increase of available patterns demands building of adequate instruments that would allow an efficient search in a library, and an easy use in new projects.

Association modeling is one of the much debated design subjects. Closely related to associations, attributes too have been the center point of some controversies, though of smaller importance.

Even if the role and the representation of the two concepts are different, there are some semantic overlaps.

While attributes are used to represent the values that compose objects, vlues which have no identity - associations are used to represent the relations between the objects of an application, objects which have an identity.

Figura 4.21 - Modeling an association using a type

As for implementation, in most cases associations are represented by attributes that contain pointers. Still, when the attribute type has a complicated structure, especially if the dimension is big or variable, attributes can be implemented as separate objects, accessed by a pointer to the source object.

The OOAD methods have offered specialists the methodologic framework necessary for developping new software systems. If compared with programming languages and the traditional development technologies, the new design and analysis methods have:

• created the framework to promote reusing at a higher level (materialized in using design patterns and some application architectures - "frameworks")
• offered a better communication environment between application users and developers, because of the inteligibility of graphic representations
• allowed a more thorough description of the systems by introducing more orthogonal views for the same components,
• provided the users with an adequate environment for making thorough semantic checks
• opened the way to an effective automation of the software development process,
• highlighted new extremely useful concepts for software development, which have not yet been implemented in programming languages (association, role, state, transition, templates, use cases, subsystems etc).

The number and kind of models and documents constructed, the operations succession differs from an application to another. They depend on:

• problem complexity
• experience of the designer team,
• available tools,
• quality of available reusable "components"
• communication way and relationships among the team members

The universe of OOAD methods is populated by dozens of methods. After having signed an open letter in 1993 where they explained that the momemt for method fusion had not come yet, the main method authors - Grady Booch, James Rumbaugh, Ivan Jacobson and others - have decided at the end of 1994, beginning of 1995 to work together to unify methods. Thus appeared the "Unified Modeling Language", UML. This is not the only unification project. Brian Henderson Sellers, David Firensmith and Ian Graham, helped by a team, have made a simmilar proposition, called OML [Henderson97].

Even after the wide acceptance of the unifying tendency, new methods continued to appear. Catalysis is one of the most well known. It continues to be used independently, even if its creators sustain that it had thoroughly influenced UML [D'Souza97].

What will future bring us ? Lots of novelties, to be sure! A still important number of concepts have to be validated. Others (part of which are related to component technology) are still to be clearly defined and introduced. It is certain that the development and use of the CASE instruments that sustain method application will contribute to a faster validation of the concepts and to a larger spread of the methods.