Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
OCL-based Component Storage and Retrieval Richa Nigam1, Rajesh Bhatia2 Department of Computer Science Engineering, Thapar University Patiala, India.
[email protected] 2 Department of Computer Science Engineering, Thapar University Patiala, India.
[email protected] 1
Abstract Software components have played an important role in modern software and system development. The main contribution of software components is reuse which helps reduce development cost and time and increase productivity. While libraries of Unified Modeling Language (UML) diagrams do exist, one of the challenges that still remain is to locate suitable diagrams and adapt them to meet the specific requirements of the software designer. Traditional approaches to component retrieval are text-based; it is therefore difficult for the designers to express their requirements in a precise and unambiguous manner. A more promising approach is the formal-based retrieval, where the OCL constraints attached to the UML diagrams are used to retrieve components. In this paper retrieval of UML class diagrams is discussed. Keywords: Software Engineering, Software Design, Software Reuse, Unified Modeling Language, Object Constraint Language 1.
INTRODUCTION
Software reuse refers to reusing software modules that have been developed on previous software projects. It is a worthwhile goal to reuse software, since it has been shown that it can help to reduce software costs, and improve software quality as well as programmer productivity. The current topic of interest is design reuse [l], at both the architectural level and the library based component level. Software design involves translating a set of task requirements into a structured description of a computer program that will perform the task. Reuse of existing generics and component designs clearly offer time savings in implementation, as well as the longer term benefit of improved software quality due to the employment of previously tested designs [2]. Experience with software design reuse has shown that development improvements can be achieved in two main areas, namely reduced design time and increased quality of delivered software. A software designer can use design schema, collaborative design knowledge, or can reuse design artifacts. The goal of the analysis & design process component is to show how the system will be realized in the implementation phase. Analysis & design results in a design model that serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. Many projects today employ object-
52
oriented programming languages to obtain reusable, changetolerant, and stable systems. UML is a graphical language, used to describe software systems. The diagrams range from requirement analysis using Use Cases, to structural information using Class Diagrams, passing by behavioral knowledge specified using State Machines. UML diagrams are not usually sufficiently precise to set out all relevant aspects of a specification. Beyond straightforward constraints, for example concerning association multiplicities, there exist a range of complex and sometimes subtle restrictions that are not easily conveyed in diagrammatical form. Accuracy and non-ambiguity in specification have been, for many years, the aims of the branch of computer science known as “formal methods”. Several attempts have been made to combine them with objectoriented modeling. The most recent and promising approach, which bridges formal methods with object-orientation is called OCL -Object Constraint Language, and it is a part of the UML standard, published by the OMG (Object Management Group). Designers may typically develop use case text, a class diagram, and a more complex sequence diagram. Having developed such systems before, many designers retrieve related UML artifacts and copy and edit them as necessary. This manual strategy works well for a small set of predefined designs. However, the strategy breaks down when the design library contains many designs produced by different designers. It becomes difficult and time-consuming to know the library’s scope as well as to find the best-matching artifacts. The disadvantages of earlier formal methods are reduced by UML OCL [7]: The notation of OCL has a simple structure and is oriented towards the syntax of object oriented programming languages. Software developers can therefore handle OCL much easier than earlier formal methods that were based on set theory and predicate logic. This is one reason why OCL is recommended by many authors for the specification of software components. 2.
RELATED WORK
Software Reuse Libraries. In traditional software reuse, a library of reusable code components is developed. This approach requires the establishment of a library of reusable components and of an approach for indexing, locating, and distinguishing between similar components (Prieto-Diaz and Freeman 1987). Problems with this approach include managing the large number of components that such a reuse library is likely to contain and distinguishing among similar though not identical components.
Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
Software Architecture and Design Reuse. Instead of reusing an individual component, it is much more advantageous to reuse a whole design or subsystem, consisting of the components and their interconnections. This means reuse of the control structure of the application. Architecture reuse has much greater potential than component reuse because it is large-grained reuse, which focuses on reuse of requirements and design. Using WordNet for case-based retrieval of UML models. It has a central knowledge base that can be used through CaseBased Reasoning. The knowledge base integrates a common ontology called WordNet. providing classification for software objects. This paper focuses on the retrieval of design models using the combination of WordNet and Case-Based Reasoning. Analogy and Software Reuse. Analogy involves a structural comparison of two concepts that appear substantially different on the surface but which exhibit important causal or semantic symmetries. Computational models of analogy have shown themselves to be valuable in the development of UML level reuse techniques; examples include ReBuilder. ReBuilder uses several UML diagrams to specify and design a software system, usually class diagrams, which can be used for mapping concepts between different domains. It comprises mapping between a source design and a target design, and it is a suitable mechanism for transfer of ideas across different domains. Object Constraint Language OCL has been integrated into the UML standard as a means of precisely expressing side-effect-free constraints on models. An OCL constraint is written within a context, which is the class or operation that the constraint is for. Within each context their can be invariants, pre-conditions and post-conditions specified. Invariants are used to express a range of restrictions over class features. System behavior is then clarified through pre and post conditions, describing, respectively, the applicability and impact of particular operations. Kristofer Johannisson developed a KeY tool[4], which bridges the gap between formal and informal specifications. Specifications need to be understood, maintained and authored by people with varying levels of familiarity with a formal specification language such as OCL. The KeY tool addresses these problems by making it possible to automatically translate formal (OCL) specifications to natural language (NL), and by providing a multilingual editor in which specifications can be edited in OCL and natural language in parallel. 3.
FORMAL SPECIFICATIONS AND OCL
specification. There is a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. To write unambiguous constraints so-called formal languages have been developed. Problem specifications are essential for designing, validating, documenting, communicating, engineering, and reusing solutions for software systems. The process of writing a “correct” specification is very difficult – probably as difficult as writing a correct program. Formal specifications [8], which refer to a mathematical description of the system’s requirements can greatly benefit requirements specification. Generally speaking, a formal specification is the expression, in some formal language and at some level of abstraction, of a collection of properties that a system must satisfy. Formality helps in obtaining high quality specifications within software development processes; it also provides the bases for their automated support. Usually, “formal” is confused with “precise” (the former term entails the latter, but the reverse is not true). To be formal a specification must be expressed in a language made of three components: • • •
Rules for determining the grammatical well-forming of sentences (the syntax); Rules for interpreting sentences in a precise, meaningful way within the domain considered (the semantics); and Rules for inferring useful information from the specification (the proof theory).
The Object Constraint Language (OCL) is a modeling language with which you can build software models. It is defined as a standard "add-on" to the Unified Modeling Language (UML), the Object Management Group (OMG) standard for objectoriented analysis and design. Some of the most important characteristics of OCL are: it is a declarative language; it is not a programming language, it is a modeling language; it is a formal language; it is a typed language. OCL is an improvement over its competitors in that traditional formal languages are usable only to persons with a strong mathematical background, but difficult to use for the average business or system modeler. OCL has been developed to fill this gap. OCL is a formal language, which remains easy to read and write. OCL allows expressions using simple logic operations, first order logic, and also set operations. First order logic allows a wide range of expression allowing universal quantifiers leading to generation of some powerful expressions. OCL is not the only formal language that can be used for specification, nor is it the most rigorous or complete one. But it does have some important things going for it:
In object-oriented modeling, a graphical model, like a class model, is not enough for a precise and unambiguous
53
Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
• • • •
It does not have overly complicated mathematical symbols and rules. It is easy to learn and begin applying. It is part of a standard adopted by many organizations. It will be supported by many new tools under development. 4. REUSE APPROACH
The approach described in this paper focuses on methods to improve searching and retrieving of UML class diagrams in large software component repositories. The approach followed is to accept a user query using natural language and mathematical OCL operators; apply formal technique to analyze a user query, and translate the query into the OCL internal format. The system assists the reuse of UML artifacts, including use cases, class diagrams, and sequence diagrams. In this paper, we focus on class diagram reuse. OCL supplements UML by providing expressions that have neither the ambiguities of natural language nor the inherent difficulty of using complex mathematics. OCL expression reference model elements and UML elements adorned with information from OCL expressions shown in Figure 2.
Fig. 2 Bank System
An OCL invariant must always evaluate to true. Many invariants can be contained by a class (Class). An invariant’s expression must always be of boolean type. Format: context className inv : param1 > ... Example: context Account inv: balance >= 0 Similarly, a precondition is an assertion before a statement executes, that defines the expected state. It defines requirements that must be true in order for the statement to do what it intends. A postcondition is an assertion after a statement executes that describes what the statement has caused to become true.
Fig. 1 OCL Metamodel and UML Metamodel
The Object Constraint Language (OCL) is an expression language that describes constraints on object-oriented languages and other modeling artifacts. A constraint can be seen as a restriction on a model or a system. OCL is part of Unified Modeling Language (UML) and it plays an important role in the analysis phase of the software lifecycle. A bank class diagram example is shown in the figure 2 on which the three types of OCL constraints attached are shown thereafter.
Format: context Typename::operationName(param1 : Type1, ... ): ReturnType pre : param1 > ... post: result = ... Example: context CheckingAccount::withdraw(amount : Real) pre: amount >= 500 post: balance = balance-amount A software designer can browse the list of the best matches and directly open each artifact from the list. The selected match must then be adapted to satisfy the current problem. The system uses a two-level query to find matching components. In general, a software designer can obtain a subset of related artifacts from
54
Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
the first level query, and the system will return the best matching artifacts based on their structural correspondence from the second level query. The proposed system is described in Figure 1: Search Module
Repository Builder
User query in Natural Language & OCL operators/keywords
UML + OCL class diagrams in repository
context Chauffer inv: years>=21 this is also converted to S>=D the desired component can still be retrieved, i.e. be it any other word for driver, age and value, the desired component is still retrieved. The main advantages of formal versus informal definitions here are that a formal definition is mathematically precise and unambiguous and that a formal definition is typically much more concise than a corresponding English prose description.
Extract OCL constraints
OCL expressions stored in database
OCL expressions to OCL internal format
The advantage is that if the software designer inputs the following constraint in order to retrieve this above component,
5. OCL expressions to OCL internal format
Internal representation of a query
Internal representation of a query Matcher
List of components
Level 1 Query
Display & select class names from these components
List of relevant components
Level 2 Query
Fig. 3 System Data Flow Diagram
It is all about ‘constraints’ and ‘not functionality’. So the constraints input to the proposed system is that kind of an input which results in a Boolean output, i.e. either True or False, which is possible when we apply mathematical operators in our input. So strings are replaced by ‘S’ and numbers by ‘D’ and operators are kept as it is. For example, consider that the following class component is stored in the repository. context Driver inv: age>=18
is converted to
S>=D
SYSTEM OVERVIEW
A Repository Architecture Before newly required components are submitted to the library, they are subject to a certification process. The components are then classified into constraint categories and made available for searching and library browsing by the software designers. All the OCL expressions attached to the class diagrams are transferred to separate files. Any of the OCL tools can be used to perform this provided they can store the OCL expressions in an HTML file format. Like Oclarity tool generates two files for each class diagram, one an XML file and the other an html file, both of which contain all the OCL constraints of the respective UML class diagrams. The next step is to extract the OCL constraints stored in the file to the database. Whenever ‘AND’ or ‘OR’ OCL operators are encountered in any of these 3 constraints a new record is inserted along with the other required component specification. The OCL constraints obtained are then converted to OCL internal format. Rather than analyze the UML artifacts directly, the system analyzes the operators and the keywords in the OCL expressions. Also there may be more than one operators in some OCL expressions like, context account::withdraw() post: balance=balance-amount Following the OCL precedence rules the system translates the OCL expressions into its internal representation. This results in a UML artifact’s internal query representation. The precedence order [6] for the operations, starting with highest precedence, in OCL is: • @pre • dot and arrow operations: ‘.’ and ‘->’ • unary ‘not’ and unary minus ‘-’ • ‘*’ and ‘/’ • ‘+’ and binary ‘-’ • ‘if-then-else-endif’ • ‘’, ‘=’ • ‘=’, ‘’
55
Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
• ‘and’, ‘or’ and ‘xor’ • ‘implies’ Disadvantage of traditional formal languages is that it is difficult for the average business or system modeler; OCL is developed to fill this gap. OCL is a formal language, which remains easy to read and write. OCL allows expressions using simple logic operations, first order logic, and also set operations. First order logic allows a wide range of expression allowing universal quantifiers leading to generation of some powerful expressions. Following tables show the OCL operators used:
round floor
a.round() a.floor()
Integer Integer
B. Component Search and retrieval Finding the best match is the first, and most important, step in reuse. In order to express software designer’s input, the input is expected in the form of constraints. The software designer is given a choice whether to retrieve the class diagram by class name or by function name and if by function name then whether to retrieve the class diagram by precondition or by postcondition. The query is expressed in the form of a string, then an OCL operator & then a string.
Table1: Standard operations for the Boolean type
Operation or and Exclusive or negation equals Not equals implication If then else
Notation a or b a and b a xor b Not a a=b ab a implies b If a then b1 else b2 endif
Return Type boolean boolean boolean boolean boolean boolean boolean Type of b
Table2: Standard operations for Real and Integer types
Operation
Expression
Return Type
concatenation
s.concat(string)
string
size
s.size()
integer
To lower case
s.tolower()
string
To upper case
s.toupper()
string
substring
s.substring(int,int)
string
Equals
s1=s2
boolean
Not equals
s1s2
boolean
Table 3: Standard operations for the String type
Operation plus minus multiply divide modulus Integer division Absolute value Maximum minimum
Notation a+b a-b a*b a/b a.mod(b) a.div(b) a.abs(b) a.max(b) a.min(b)
Return Type Integer or real Integer or real Integer or real Real Integer Integer Integer or real Integer or real Integer or real
‘string/number operator string/number’ eg. age>=18 This query is converted into the OCL internal format. Here, it is converted to S>=D. The system employs an algorithm to find matches for a given query & to form a match between two constraints, at least one operator or keyword must match. In UML, this typically begins with a matching stereotype name and is refined with matching names for some use cases, classes, or objects. A class names synonym list of the repository, provided by the administrator, permits equivalence between different constraints. In fact, close matches are most helpful because they provide new structures that you can reuse. The best case is obtained if a user enters the exact constraints in the form of operators and/or keywords and the repository also has those constraints for the respective classes or functions. The obtained OCL internal format is matched with the stored formats in the repository. All the components with the matching formats are retrieved along with their pathnames, in order to access the respective class diagrams. After getting the list of components, there is a complete procedure for component retrieval, which is undergone. 7. CONCLUSIONS & FUTURE DIRECTIONS Software reuse and formal specification are two methodologies that show high potential impact on software productivity and reliability. Used together, they permit increased automation and assurance in the reuse process. The approach was primarily to automate the process for UML diagrams search and retrieval; formal language OCL was employed to annotate a software component with a formal description of the classes and operations provided by the class diagram using OCL; a formal language interface provided to the designers for the description of the queries. Formal method technique was employed to match the queries to the components. The system promises that the precision granted by the formality of OCL comes at a much lower cost than when using other formal specification constructs.
56
Proceedings of National Conference on Challenges & Opportunities in Information Technology (COIT-2007) RIMT-IET, Mandi Gobindgarh. March 23, 2007.
Although this approach works, we see opportunities for future improvements such as utilizing OCL templates for the input. In the meantime, designers can improve their system’s quality and efficiency by applying this component retrieval approach.
REFERENCES [l] 'Reuse Directions in British Telecom', Steven Whalley, in Software Reuse and Reverse Engineering in Practice, Chapman and Hall, 1992. [2] 'Quantitative Studies of Software Reuse', R. W. Selby, in Software Reusability: Application and Experience, vol. 2, eds. T.J. Biggerstaff and AJ. Perlis, ACM 1989. [3] Johannisson, K.: Disambiguating implicit constructions in OCL (2004) Online proceedings of OCL and Model Driven Engineering Workshop at UML 2004, http: //www.cs.kent.ac.uk/projects/ocl/oclmdewsuml04/ description.htm. [4] Ahrendt, W., Baar, T., Beckert, B., Bubel, R., Giese, M., H¨ahnle, R., Menzel, W.,Mostowski, W., Roth, A., Schlager, S., Schmitt, P.H.: The KeY tool. Software and System Modeling 4 (2005) [5] H¨ahnle, R., Johannisson, K., Ranta, A.: An authoring tool for informal and formal requirements specifications. In Kutsche, R.D., Weber, H., eds.: Fundamental Approaches to Software Engineering. Number 2306 in LNCS (2002) [6] The Object Management Group: Object constraint language specification (2004) http://www.omg.org/docs/formal/0303-13.pdf [7] R. Hennicker, H. Hussmann, M. Bidoit, On the Precise Meaning of OCL Constraints. In: Clark/Warmer (eds): Advances in Object Modelling with the OCL, Springer LNCS Vol. 2263, pp. 70-85, Berlin 2001. [8] H. Hussmann, Formal Specification of Software Systems, Lecture Notes, http://www-st.inf.tudresden.de/fs, 2002
57
