Pia Maria Maccario
CSELT - STET
via Reiss Romoli 274
10148 Torino, Italy
Tel: +39-11-2286793
Fax +39-11-2286862
Email:
Pia.Maccario@cselt.stet.it
This position paper shortly presents the work carried out at CSELT for defining and integrating Domain Analysis concepts within a specific methodology. This methodology, called DOMINO (Distributed Object-oriented Methodology for an Incremental approach), uses an object oriented approach (based on Use case and Object Modelling Technique) supported by an incremental life cycle for engineering and specifying the user requirements related to telecom applications. The methodology refers to OSCA and TINA as architectural framework.
Our Domain Analysis approach, called DADO (Domain Analysis for DOMINO) has been defined starting from already existing approaches (FODA and Sandwich) and adapting them in order to satisfy our specific requirements. Furthermore our proposal introduces domain analysis as an explicit task of the software life cycle specified in the methodology. The domain analysis task produces a complete representation of the target domain and reusable resources in a way compatible with the one used inside DOMINO.
Keywords: Domain analysis, object technology, software architecture, reuse, methodology .
Workshop Goals: Exchange of ideas and experiences with other researchers.
Working Groups: Domain analysis and engineering, object oriented issues, process related aspects of reuse.
Building a distributed application (like the telecom ones) is very hard if there is no methodology to support the development process as a whole. Object oriented technology provides distributed computing with all its power, such as encapsulation and re-use. In fact, the application of object orientation to distributed computing is an intuitive and natural thing.
Therefore, in order to produce such modular and reusable objects/components it's necessary to define a complete development process where the reuse "key" principles are followed. Furthermore this development process should take into account not only the needs of reusing objects but also the knowledge taken from the target domain starting from the customer requirements down to the code that realised the corresponding services.
Domain analysis is one technique that can be applied to discover and exploit in a systematic way commonalties across related systems .
We need to identify components encapsulating an idea because they can be reused in a new system, if the same "idea" occurs in that system. We think we can use domain analysis techniques for coding knowledge at different levels of abstraction and for storing those information for future reuse.
We can obtain components encapsulating knowledge/idea as elements resulting from domain analysis. We define domain analysis as "the process where the knowledge of user/customer needs is identified, elaborated and organised in such a way that the applications planned inside a Domain (or an Application Family) can be analysed and designed following modularity and reusability criteria" [13].
We think that domain analysis allows the integration of the reuse process in the software production life cycle and holds the key for a systematic, formal and effective practice of software reuse. This is possible only if the development methodology explicitly contains the domain analysis task.
The different application modules should be characterised by internal high cohesion and a well defined way for communicating with the other components (i.e. pre-fixed interfaces); this means that each application should have an architectural framework. We think that also the objects obtained applying the domain analysis process should adhere to this architectural framework (when it is specifically defined) in order to have more traceability and to be more reusable.
The approach we propose (DADO), as shown in the following, introduces explicitly domain analysis as an explicit task of the software life cycle specified in the methodology and uses a notation coherent with the methodology and the architectural framework adopted.
2.1 Why do we need a new approach?
Why do we need to define a new domain analysis method that i ntegrates different approaches?
When we started our work, we had to satisfy two different and "heavy" requirements:
* DOMINO [1,2] is based on object oriented analysis, therefore the domain analysis step should produce models that are compatible with this representation;
* our architectural framework is OSCA/TINA compliance therefore we are interested in identifying in the domain analysis task reusable objects compatible with those architectural principles.
We didn't find an existing approach satisfying them but analysing FODA (Feature Oriented Domain Analysis) [3] we found that it introduces the concepts of feature that is a key factor for modelling services and their different versions for customer specific needs. Furthermore it's possible to adapt its architectural modelling phase introducing the OSCA - TINA principles.
The proposed approach [13, 14, 15] uses ideas and concepts taken from the following methodologies and techniques: FODA (Feature-Oriented Domain Analysis) [3] as general guidelines; OMT (Object Modelling Techniques) [4] for analysis and design; OSCA - TINA [5,6,7] as target architecture; Prieto-Diaz "Sandwich" domain analysis process [11] for management aspects not covered in FODA.
2.2 The life cycle model
The following figure shows a simplified version of our software development process, that is based on incremental approach and highlights how the domain analysis is performed.
Without considering the domain analysis task, first we make a feasibility study (not shown) for each application to be developed, then we start to define the application itself, its boundaries and we define the different application releases (application definition task). For each application release (called increment) we us e a spiral approach (OOA-OOD- Implementation) in order to develop its objects.
The domain analysis results, when available, are used in the development cycle for achieving reuse and for providing guidance in the process of identifying the application objects and their relationships.
The domain analysis infrastructure (Domain Model, Reusable Resources, Model and resources reuse data) is seen from the users as a set of services (such as reusable components libraries), tools (such as classification schem a and browsers) and personnel (librarians, asset manager, etc.).
During the process of developing a new application, resources reuse data are collected: this information constitute a useful feedback to the domain analysis process and allow the refinement and update of the domain model and the other products.
2.3 The DADO approach
DADO main activities are: Context Analysis; Domain Modelling; Domain Implementation, briefly analysed in the following sections.
In DOMINO each application is defined in the Application Definition task, in terms of the following models/documents: Application definition, Context model, Structure model, Macro-Element model and Dictionary. They are used as input in the domain analysis activities.
2.3.1 The context analysis
The context analysis activity defines the context where the domain analysis will be executed producing as output the context model. This model shows: the domain's boundaries; the problem space for which reusable resources will be available and a dictionary containing the domain terms. The context analysis tasks are:
* Domain definition;
* Structure diagram definition;
* Context diagram production;
* Dictionary definition.
This activity uses the DOMINO Application Definition models in order: to clearly identifying which are the existing applications related to the specific domain, to define the domain boundary and as a guide to increase the domain understanding.
2.3.2 Domain modelling
The domain modelling is the most important activity and the most "expensive" one. It has been defined integrating the FODA's domain modelling phase and the OMT's object-oriented analysis. Domain modelling produces the most important product of the domain analysis process: the domain model that is a representation of: domain concepts, domain objects, operations and their relationships.
The Domain Modelling activities are:
* Information collection;
* Feature analysis: the purpose of feature[1] analysis is to capture and model domain's features and their relationships using one or more Feature Diagrams, where each feature is modelled as an object. This model is used with end-users as an instrument to help them to identify the availability of features in a domain application.
* Object modelling: its output is an object diagram representing the objects classes needed for each domain application. This task is similar to the corresponding OMT one, but single steps have been redefined in order to model not sin gle but family of applications[2];
* Behaviour modelling its output is the definition of a state-transition diagram for each object class in the domain. This diagram shows similar and different aspects of the target domain applications behaviour using the f eatures and object models previously defined.
* Functional analysis. its output is a DFD-like model representing the domain functional model. It shows: domain application functions, their input and output, data structures and the information flow between the domain objects and their manipulation process .
2.3.3 Domain implementation / Architectural modelling
Not all domain analysis methodologies define a domain implementation activity; in DADO it has been included because we need to have reusable resources adhering to a pre-defined architectural framework.
The purpose of domain implementation phase is to provide a software "solution" to the domain problems. It uses as input the models previously defined and the domain knowledge and it identifies the domain architectural scheme that can be used to design a new domain application.
Starting from the domain application general models, the domain implementation activity extracts low level components (object class, subsystems, etc.) and maps them in architectural objects that can be reused for producing new domain applications or for re-engineering existing ones.
The architectural objects are contained in the architectural domain model where they are categorised as: user interface, network interfa ce, corporate data and process.
Then they are grouped in Building Blocks highlighting their main interfaces (contracts) as request from OSCA - TINA. Furthermore the main relationships existing between these architectural objects are shown.
This model is used in the DOMINO Application definition task for defining the architecture of a new domain application.
We can use the Architectural Domain Model and the Features model to design a new application starting from the different user needs: in particular different versions of the same product will be identified starting from a "core" set of elements given by the objects corresponding to the mandatory features and changing the alternative ones or adding the optional ones, we can model a service corresponding to user specific requirements.
Some object oriented analysis and design methodologies contain steps that can considered domain analysis steps. For example, the JODA methodology [8], describes a domain analysis process based almost entirely on Coad and Yourdon Object-Oriented Analysis [9]. Vice versa, Booch's Object-Oriented Design methodology [10] explicitly executes an informal domain analysis step.
The difference between these OO methodologies and DADO is mainly in their scope and purpose: object oriented analysis consider a specific problem while domain analysis considers the set of problems common to an application family.
We think that a domain model should be powerful enough to represent different kinds of relationships between its elements. In DADO this requirement is met using the OMT techniques for modelling and representing domain information .
The integration of FODA principles with an object oriented methodology for objects analysis and design is quite natural and using OMT as a modelling technique gives rise to many advantages, such as:
* object oriented concepts and mechanisms are "natural" and effective for modelling a domain and representing its variations, i.e. the different ways of implementing similar or correlated features of the different applications domain;
* many CASE tools have been developed for supporting OMT and it's possible to adapt them for supporting automatically the main phases of the domain analysis process.
As far as the "management aspects" are concerned, they have not been included in FODA but are needed in our context; the DADO approach "borrowed" some ideas by other methodologies like Sandwich of Prieto-Diaz [11].
A mandatory requirement for our approach was that the results of domain analysis steps give rise to components/objects adhering with the OSCA-TINA architectural framework principles in order to obtain components (specifications, objects class...) that can be directly reused for inside systems having the same architectural framework. Obviously, none of the existing domain analysis approaches satisfy this specific request but we think that our experience can be used and improved by others.
Finally, in order to have a more effective reuse support we introduce the DADO approach inside our specific development methodology.
[1] Bartocci A., Grasso E., Maccario P.M., Martini G. Proposta di approccio metodologico ed architettura di riferimento per i sistemi di supervisione e controllo, 1996, CSELT Technical Report.
[2] Bartocci A, Maccario P.M. Proposta di approccio metodologico per l'analisi di applicazioni software orientate ad oggetti - La Metodologia DOMINO, 1996, CSELT Technical Report.
[3] Kang Kyo C., Cohen Sholom G., Hess James A., Novak William E., Peterson A. Spencer; Feature-Oriented Domain Analysis Feasibility Study ; 1990; CMU/SEI-91-TR-21
[4] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W.; Object-oriented modelling and design; 1991; Prentice Hall
[5] Bellcore; The Bellcore Osca(TM) architecture; 1992; Bellcore Technical Advisory
[6] Tina-C deliverable, Computational Modelling Concepts , vers.3.2, May 1996.
[7] Tina-C deleverable, TINA Distributed Processing Environment , December 1995.
[8] Holibaugh Robert; Joint integrated avionics working group (JIAWG) object-oriented domain analysis method (JODA) version 3.1 ; November 1993; CMU/SEI-92-SR-3
[9] Coad P., Yourdon E.; Object-Oriented Analysis; 1990; Prentice Hall
[10] Booch G.; Object oriented design with application; 1991; The Benjamin/Cummings Publishing Company
[11] Prieto Diaz Ruben; Software technology for adaptable, reliable systems (STARS) program - Reuse library process model; 1991; STARS Technical Report
[12] Jacobson I. Object Oriented Software Engineering - A use case driven approach, Addison Wesley 1992
[13] Maccario P.M., Diana G., Dionisi Vici A., Introduzione al riuso del software ed alla domain analysis, 1995, CSELT Technical Report DTR 95.0210.
[14] Maccario P.M., Tamietti C. Una metodologia di Domain Analysis per la produzione di specifiche Object Oriented riusabili per sistemi di telecomunicazioni, 1995, CSELT Technical Report.
[15] Maccario P.M. The OODA (Object Oriented Domain Analysis) methodology 1995, OOPSLA'95 Workshop "Application of Domain Analysis Techniques to Object Oriented System"
Pia Maria Maccario is a Researcher in the Software Design and Product Quality Support research group of CSELT in Turin, Italy. She is currently responsible of the software life cycle definition activity and is involved in the definition of corporate methodologies and for developing software and supports the introduction of the Object Oriented approach in the different projects.
In the past years she works in the Software Engineering department defining methodologies for software management from the public telecom operator viewpoint, especially those related to reuse and object orientation, analysing also their possible CASE and tools support. She obtained a Computer Science degree in 1988 from the University of Turin.