TERM PAPER
ON
Extending UML to Support Domain Analysis
SUBMITTED TO:- SUBMITTED BY:-
Mr. SANDEEP SINGH AKANSHU KUMAR Reg No:-11112286 ROLL No:- A21 SECTION:- K1107
Abstract:-
The process of modelling and developing commonality and variability for system families should be supported by suitable methods and notations. The object-oriented methods and their notations, which are used at present, focus on the development of a single system at a time. In this paper we analyse feature models as a representation of the common parts and variants contained in a system family, and propose using a feature diagram as a basic representation of commonality, variability and dependencies. We examine various approaches to customizing the standard modelling language UML to model system families and propose how to extend the UML for the purposes of modelling variants in object-oriented analysis and design techniques. We recommend the use of UML standard lightweight extensibility mechanisms (stereotypes combined with tagged values) without changing the UML metamodel. This enables us to join the advantages of feature models with UML and provides the traceability of a concept throughout system development. An application of lightweight UML extension mechanisms allows the existing standard UML modelling tools to be used without any adaptations. An example of an application illustrates our approach.
Acknowledgments:-
This Term paper is made possible through the help and support from everyone, including: parents, teachers, family, friends, and in essence, all sentient beings. Especially, please allow me to dedicate my acknowledgment of gratitude toward the following significant advisors and contributors.
First and foremost, I would like to thank my teacher for his most suport and encouragement. He kindly read my paper and offered invaluable detailed advices on grammar, organization, and the theme of the paper
I sincerely thank to my parents and friends, who provide the advice and financial support. The product of this research paper would not be possible without all of them.
Contents:-
1- Introduction 2- The process 3- The notation 4- Tool support 5- Conclusion 6- References 7-
Introduction:-
Domain ( An area of expertise for which multiple, related software systems are required or potentially useful) understanding and description activities are still a challenge in the context of the software process.There are a variety of methods that can be used “to identify, organize and model knowledge about the solution of a class of problems to support its reuse among all elements in the class”. The feasibility of reuse implies planning. One reuse approach is to produce applications one by one, trying to reuse what is available from applications already delivered.
The feasibility of reuse implies planning. One reuse approach is to produce applications one by one, trying to reuse what is available from applications already delivered. Another approach is to identify what is reusable before building the first application. This implies restricting the scope to similar applications (or domain), understanding and describing the domain, building reusable artifacts for the domain. Next, applications are built starting from reusable artifacts of the domain. When this approach is feasible (A domain can be identified and it is relatively stable over time), reuse offers the maximum leverage, in terms of cost, reliability and time to market. Further, this approach can protect an organization from turnover.
The more mature and stable a domain, the easier to identify and organize the reusable artifacts for it. Examples for such domains are Airbus airplanes cockpits, IBM 360 computers, Internet browsers, satellites, and telecommunication softwar. In the following we will refer to all the activities needed to produce reusable artifacts for a domain (including domain identification and description, and development of reusable artifacts) with the term domain engineering. Application engineering refers to developing an application in the domain starting from reusable artifacts. Domain engineering is the foundation for emerging product line software development approaches 171. A product line is “A family of products designed to take advantage of their common aspects and predicted variabilities”.
A product line development approach involves many different stakeholders. This includes the domain engineer and the application engineer as well as customers who are paying for application development, users who execute the application, and the organization (represented by its senior management) that produces the product line.
Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adaptability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions.
While most domain analysis approaches are functional oriented, the idea of applying the object oriented approach in domain analysis is not new. Propose to use UML as the notation underlying domain analysis.Propose to use the design pattern notation and style to represent discriminants, or features that distinguish one application from another. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. Moreover, the extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support.
The underlying philosophy is not introducing yet another domain engineering method, but merging seamlessly existing ideas and tools. We present our approach using, as a working example, a software product line for the Guidance Navigation and Control (GNC) Flight Software (FSW) domain under development at the NASA Goddard Space Flight Center. The paper is organized as follows. Section 2 describes the process and its activities. Section 3 describes the notation, based on UML with a few extensions. Tools to provide semi-automated support to the domain and application engineering processes are presented in section 4. Finally, some partial results are discussed in section 5.
The object-oriented paradigm has brought new concepts like classes and objects, inheritance, dynamic polymorphism and dynamic binding to s oftware engineering. Despite the advantages of the above concepts, the objectoriented software paradigm has not reached productivity, which had been expected in the area of reuse, adaptability and management of complexity . The object-oriented approach mainly supports the reuse of assets in the next versions of a single software product. A software asset is a description of some partial solution (component, design document, model or knowledge) that engineers use to create or modify software products. The development of a group of systems built from common generic software assets is a goal achieved by building software productlines upon the product families. A reason for creating program families has already been presented in the early works by Dijkstra(1972) and Parnas (1976). Program families are defined by Parnas as “sets of programs, whose common properties are so extensive thatit is advantageous to study the common properties of the programs before analyzing individual members ” (Parnas, 1976). The family is further (Weiss and Lai, 1999) “a set of items that have common aspects and predicted variabilities”. According to Weiss and Lai, the term variability is defined as “an assumption about how members of a family may differ from one another” and commonality is “an assumption that is true for all members of a family.” Building the sets of related systems helps us to achieve remarkable gains in productivity and improves time-to-market and product quality.
Developing system families with Domain Engineering.
Developing system families encompasses the development of core assets and building products using the core assets. The two complete development cycles are presented in Figure. The development of core assets, i.e. Domain Engineering and the development of products, i.e. Application Engineering . Domain Engineering is the development for reuse and it embraces creating, among other things, domain models and architectures. It also supplements the object-oriented methods and helps us solving problems associated with the reuse of software assets. Their identification, documentation, classification, c oordination, integration and evolution. Application Engineering, the development with reuse, is the process of using the results from Domain Engineering (domain assets) to produce (possibly to generate) system family members, i.e. concrete software systems. New products can be developed upon core assets as core assets may also be extracted from the existing products. Both the processes (Domain Engineering and Application Engineering) are different from a typical object-oriented process such as the Unified Process (Kruchten, 1998), aimed at developing one system at a time.
This figure shows an example of using extensions described in an UML activity diagram for registering a mail subscription (in a mail subscription system). On this diagram the subsequent steps for registering a new subscriber use case are shown. The first difference between various subscription systems can be recognized in the first branching activity: one can register by mail (with a properly formatted message) or just fill in a WWW form (here there is a choice between the standard HTTP protocol andthe more secure but slower HTTPS protocol). Activities implementing the corresponding variable elements from the feature diagram are marked with the _variable_ stereotype. The consistency between the model and the feature diagram is maintained by using the property “feature” contained in the tagged value.
The UML component diagram for implementing a mail subscription system acts in a similar way . The groups of features are modelled as packages and the features themselves (mandatory and optional features) are modelled as components. Similarly to the activity diagram, the optional components are distinguished by the stereotype _variable.
The process:-
Synthesis and FAST influence the process used in our approach. Two main sub-processes are defined: domain engineering and application engineering. The former aims at producing the deliverables that describe a domain, the latter develops an application starting from and reusing domain eliverables. Domain engineering is composed of three phases. Domain analysis defines the scope of the domain, describes the domain and performs commonality and variability analysis on it. Its main deliverable is a document in UML and text. Section 3 is dedicated to present the notation used in this document. Next, domain design focuses on design decisions (such asimplementation of persistence, user interfaces, thread of control, messages and events, choice of design patterns to use) for the domain, and delivers a document in UML and text. Finally, domain implementation develops source code modules in a specific programming language. Application engineering is composed of the same three phases, analysis, design and implementation. These phases have the usual meaning, however they do not develop the corresponding deliverables from scratch, but simply modify and adapt the correspondent domain engineering deliverable. Heuristics guide this process. They are collected and documented during domain engineering. The application engineer uses them to make analysis, design and implementation decisions. Verification and validation phases and activities are also planed.
The notation:-
This section presents the notation bused in the domain analysis phase to produce the domain analysis deliverable. To present the notation we will use an example from the Guidance Navigation and Control (GNC) domain. GNC is a family of embedded computer applications that determine and control the state (orbit, attitude, and momentum) of a scientific satellite. GNC use measurements from onboard sensors and /or ground updates to compute the state, and control onboard actuators to modify it. Solar system is one of the GNC sub-domains. Figure 1 shows the corresponding domain analysis deliverable. The solar system model is composed of the sun, nine planets and their moons. Regularly (every 1 to 60 seconds) GNC compares the position of solar system planets, as captured by sensors, with the solar system model at a certain time to compute the position of the satellite. The notation is based on UML as applied to object oriented (00) analysis. In 00 analysis it is assumed that:
1- A single application is analyzed to capture its concepts (classes), properties (attributes), behaviors (operations) and static relationships.
2- All elements in the 00 analysis model (classes, attributes, operations, relationships) are part of the application.
3- A domain (i.e. a set of applications) is analyzed.
4-Elements in the domain analysis are part of the domain, not always part of the application. In other words commonality, variability and exclusion need to be represented. Our approach is to use a special symbol <V> to remesent variabilitv. And to intermet. Exclusion is not represented (however, elements excluded and rationales for exclusion can be detailed in the text that can be associated to UML).
In the following we discuss the notation using and other smaller ones. The classes Solar System, Celestial Body, Celestial Body Ephemeris are common to all applications, i.e. each single application in the domain has them. The class Celestial Body Gravity is tagged by a <V>, it could be present in some applications while not in others.
The same applies to operations and attributes. Operation position(time) in class Celestial Body Ephemeris is present in all applications, while in the same class velocity(time) could or could not be present. Generalization and aggregation relationships can change, indirectly, the availability of a class in an application. Consider classes Point Mass and Spherical Harmonic. They are not tagged by a <V>, but they are specializations of class Celestial Body Gravity, so they are part of an application only if Celestial Body Gravity is part of it. The same applies to aggregation, or part-of, relationships. If class A is part-of class B, and B is variable, A is in the application only if B is in the application. Considering that generalization and aggregation relationships define sets of classes (the set of specializations and the set of parts, respectively) we can also support the concept of discriminants [14]. In a single discriminant only one of the classes is present in an application. Classes are tagged by the <xorV> symbol. In the example aside (Figure 2) only one of Al, A2 or A3 is present in an appli'cation from the domain. In a multiple discriminant zero, one or more of the classes in a set can be present in an application. The notation uses the usual <V> tag. In the example on the side zero or more among Al, A2, and A3 can be present in an application. Inheritance, as associated to generalization, interacts with variable operations. Let's suppose an operation is defined <V> on a class that is further specialized. According to inheritance rules, on the domain the operation is inherited by all specialized classes, and the <V> is inherited too. As a consequence, at the application level, the user must define, for each specialized class, if the operation is kept or not. In the example of Figure 4, the domain is on the left, an application derived from it on the right. Op-A(), Op-B() and @-CO are inherited, in the domain, by AI, A2 and A3. When defining an application, the application engineer has to resolve the variabilities. For instance, she can decide that Op-A() is kept and common to Al, A2, and A3 (therefore it appears on A), while @-CO is not kept, and Op-B() is on AI and A2 but not on A3. The same idea can be used when dealing with variabilities in attributes and arguments of operations. Supported by heuristics, application engineers can decide about which attributes should be present at the application level, and about the right set of arguments and corresponding types for the operations. Due to space limitations, we can report here only part of the notation and its semantics. A full definition can be found in.
Tool support:-
The domain analysis model is produced with an industrial UML CASE tool. Tagging variable elements with the <V> symbol did not require any adjustment to the tool. The domain diagram represented by Figure 1 was produced using the tool. Given a domain analysis model, several different application analysis models can be generated from it. Each variability on the domain analysis model (depicted by a <V>, at the level of any model element, i.e. subsystem, class, association, operation, attribute) is a decision point to be resolved by the application engineer, in function of mission requirements and choices based on heuristics and experience.
Each engineer should be able to follow the decision process he/she likes best. However, a reasonable, top- down decision process, is the following:
Resolve <V> on subsystems For each subsystem left in the application.
For each <V> class resolve <V>
For each class left in the application
For each <V> operation resolve <V> For each <V> attribute resolve <V>
The tool has been designed to support this process. Each decision point is documented with guidance on constraints and options for the choice, under the form of pop up windows containing text. Invoking a new command, the user of the tool can produce an application analysis model, starting from the domain analysis model. The new command, implemented as a script, leads the user through all decision points. At each decision point the user makes a decision, while the tool presents the resulting application analysis model on another window. The tool resolves also choices deducible or constrained by previous choices. For instance, if a <V> class is excluded, all related associations are dropped too. And if a <V> class origin of a generalization or aggregation relationship is dropped, related classes are dropped too.
Conclusion:-
Existing domain engineering approaches rely mostly on natural language for the documents they produce, and are independent of software engineering tools. We have presented an innovative approach to domain engineering based on the idea of merging existing processes, and specifically domain analysis and commonality variability analysis, with a popular semi-formal language such as UML. Our goal has been the integration of existing concepts and ideas in a lightweight approach, and not the definition of yet another domain engineering method. However, the approach and the extensions are formally defined. As a result we could use an industrial UML CASE tool to support the approach. The tool supports the definition of domain analysis diagrams and the semiautomatic generation of application analysis diagrams.
This approach has been evaluated and refined based on experiences in engineering parts of the GNC domain. The results of this experimentation are very positive. 1- The UML extension for domain analysis is usable and capable of capturing key concepts of the domain, not excluding variabilities 2- The use of UML allows for conciseness, precision and better structuring of information. For instance, in the Solar System sub-domain two UML diagram. 3- Conciseness is a prerequisite for understandability and better quality assurance. Using UML instead of text, several errors and omissions previously overlooked were noticed, deeper discussion stimulated and further insight of the system was acquired. 4- UML knowledge is required to read the documents. This excludes some stakeholders (especially non-IT staff) from the loop. Text documents with some redundant information must be kept along with UML diagrams. 5- UML analysis documents can be influenced, or anticipate, design choices. This is a well-known issue in object-oriented analysis and design.
