4Object-Oriented Analysis and Design Methods
4.1 General aspects
4.1.1 Why were they necessary ?
Object-Oriented Analysis and Design Methods (OOADM) have appeared as a response to the strive to solve the development of complex applications problems, which could not be solved only with the aid of environments and programming languages.
4.1.2 Objectives of analysis, design and ... implementation methods
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.
4.1.3 The problem of terminology
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.
4.1.4 A broader definition
By an object-oriented analysis and design method we understand a set of:
4.1.5Recurrency, the separation between analysis, design, .. implementation and testing
Figure 4.1 - Software development stages
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.
4.1.6 Method Classifying Criteria
The possible clasifications are not rigid, for at least two reasons:
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:
Along with the above-mentioned classification criterion we can also take into consideration:
4.2 Object Constraint Language
Is used to describe the formal textual annotations in UML, having the following features:
The following domains have been taken into consideration for using the language:
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:
4.2.1 UML concept classification by functionality
Packages, classes, associations, generalizations, states, events, transitions, use cases, collaborationsare 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.
4.2.2 The Foundation Package
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.
184.108.40.206The entities of the Core subpackage
The analysis of the class diagram associated to "Core" subpakage, prezented in figure 4.4 allows us to make the following assertions:
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.
Figure 4.5 -Class semantics
The class is the description of an object collection that share the same attributes, operations, methods, relationships and semantics.
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:
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.
4.3 Models, views and diagrams
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:
Figure 4.6 - View models and diagrams
To each view correspond one or more diagrams. The basic role of diagrams is to offer the framework for the analysis and design stages.
4.4 Activities done for constructing and implementing models
There are no magic recipes for creating an application.
The activities realised when applying an OOAD run counter to those used when applying a recipe.
Generally, the activities performed when developing an application are the following:
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.
4.5 Design patterns
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:
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.
4.6 Open problems in the modeling domain
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.
4.6.1 Attributes and associations
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.
4.6.2 Implementation solutions
One of the most important contradictions is related to the way associations are implemented. The solutions adopted up to now have shown three different cases:
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:
The number and kind of models and documents constructed, the operations succession differs from an application to another. They depend on:
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.