Generating functional artifacts from low level design diagrams

At least one design diagram is obtained from at least one previous software project. At least one service abstraction is extracted from the at least one design diagram. The at least one service abstraction is reused in a new software project. In another aspect, requirements are obtained for a current software project; at least one class diagram is obtained from at least one previous software project; a dependency graph is generated from the at least one design diagram, using link analysis; relationships between classes in the dependency graph are analyzed to obtain functional artifacts for the requirements; and the functional artifacts are reused in the new software project.

FIELD OF THE INVENTION

The present invention relates to the electrical, electronic and computer arts, and, more particularly, to software development and the like.

BACKGROUND OF THE INVENTION

In custom software development projects, in general, the same type of software is being built for different customers. The deliverables are similar because they address the same market (e.g., telecommunications, banking, and so on) or have similar functions, or both. However, most organizations do not take advantage of this similarity and conduct each project from scratch, leading to lesser margins and lower quality.

Software reuse is a significant issue for a large part of the information technology (IT) business involved with the development of custom software solutions. Most organizations build software solutions for focused markets, also called business lines, verticals or domains, and they seek to grow their expertise with every project.

SUMMARY OF THE INVENTION

Principles of the invention provide techniques for generating functional artifacts from low level design diagrams. In one aspect, an exemplary method (which can be computer-implemented) includes the steps of obtaining at least one design diagram from at least one previous software project; extracting, from the at least one design diagram, at least one service abstraction; and reusing the at least one service abstraction in a new software project.

In another aspect, an exemplary method (which can be computer-implemented) includes the steps of obtaining requirements for a current software project; obtaining at least one class diagram from at least one previous software project; generating a dependency graph from the at least one design diagram, using link analysis; analyzing relationships between classes in the dependency graph to obtain functional artifacts for the requirements; and reusing the functional artifacts in the new software project.

One or more embodiments of the invention or elements thereof can be implemented in the form of a computer product including a tangible computer usable storage medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include hardware module(s), software module(s), or a combination of hardware and software modules.

One or more embodiments of the invention may offer one or more of the following technical benefits:a) The Service information is explicitly represented after being extracted and stored in a usable format such as Uniform Modeling Language (UML); subsequently, it can be readily reused in new projects.b) The development time of the projects can be significantly reduced when existing assets are reused instead of creating services from scratch.c) The implementation artifacts can be obtained, given a services abstraction, in view of porting the functionality, given constraints of the target environment. For example, in view of porting the authentication functionality of banking software, the service abstraction defined as “Authentication” can be specified and the implementation artifacts related to authentication can be extracted and ported.d) High reusability can be achieved, such that the target requires substantially less time to obtain the functional artifacts. Therefore it significantly increases the reusability and reduces the time spent in creating new projects.e) Metrics from the service model being output, such as fan in and fan out presented in one or more embodiments of the invention, can be used to verify the correctness and accuracy of the models in the new project.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Systematic reuse of software artifacts has been an elusive goal for several years. Service-Oriented Architecture (SOA) has been touted in recent years due to its promise of fostering reuse. Even so, reuse with SOA continues to be limited. One major bottleneck hindering reuse has been the lack of formal techniques for extracting domain knowledge from existing reusable software assets. Aspects of the invention provide an approach that extracts the domain and service abstractions from design diagrams of existing software solutions and represents them in a form that can be reused in new projects. Design diagrams are an integral part of the software development process and therefore capture a large amount of domain information in the form of domain concepts and abstractions. The abstractions can be either directly used as services or can be used as seed services to model other high level services. Both domain and service abstractions are thus extracted through one or more inventive techniques, and promote reuse of software assets to a significant extent.

It will be appreciated that, in many cases, code is the most useful implementation artifact that, if reused, will significantly reduce the development time of projects. However, achieving code reuse is difficult, since requirements to code mapping, or capturing the intention of the requirements and the appropriate code, is quite infeasible with current techniques. Services are modular abstractions describing the inputs and outputs of a collection of related operations (functions) but without going into the details of how an operation is implemented. Accordingly, knowing about services in an implementation helps in understanding what the code “is about” and aids in better reuse of the code without going into details about the code itself. Furthermore, services provide a functional view, and a mapping between the service and its implementation can be achieved through mapping techniques. Services reusability is more clearly understood in terms of the functionality it provides.

In order to obtain an implementation view, in one or more embodiments, examine the diagrams that directly reflect the implementation aspects of a solution. Sequence and class diagrams are design diagrams that capture the intensions of the implementation in a diagrammatic method. In a similar manner, UML does not have service descriptions. Therefore, aspects of the invention present a representation of the output service description that is found. The service interfaces are specified in terms of Java interfaces. One or more embodiments of the invention provide a methodology where low level design diagrams, such as sequence diagrams or class diagrams, are examined, and wherein a methodology extracts service abstractions whose interfaces are specified in terms of Java interfaces.

InFIG. 1, a simplified project cycle100is shown. The project requirements are collected, as indicated in blocks102and110for Project1and Project2, respectively; the solution is developed and tested, as per blocks104,112; and finally released to the customer, as per blocks106,114. At the end of the project, a report is generated to capture the learning, as per blocks108,116. Heretofore, project-end deliverables or reports have typically not been explicitly used to improve the solution development process for new projects.

The similarity among the projects when extracted and represented makes the similarity across the projects explicit. However, manually creating such domain knowledge is infeasible due to efforts required for the training of the software professionals. Although many engineering tools have matured for years, acquisition of this knowledge remains a tedious task leading to domain knowledge acquisition bottlenecks. Design diagrams like UML are an integral part of software project deliverables, documenting significant facets of the solution, such as software artifacts, their relationships and runtime behavior. They are excellent sources of domain knowledge, especially the domain abstractions. In the world of SOA, these abstractions are typically referred to as services. In one or more embodiments of the invention, use is made of design diagrams to facilitate reuse of service abstractions. As shown inFIG. 1, services are extracted from blocks108,116and are present in block126, from which domain knowledge can be reused in steps118,120,122,124of a new project, and from which service abstractions can be reused in, for example, step120of a new project.

Existing work in converting UML to domain and/or services transformation has assumed that all UML elements contain domain information, and has therefore resulted in notation conversion approaches. See K. Falkovych, Ontology Extraction from UML Diagrams, Master's thesis, Vrije Universiteit Amsterdam, August 2002 (“Falkovych”); Jin Yang, in Chung, Automatic Generation of Service Ontology from UML Diagrams for Semantic Web Services, The Semantic Web ASWC 2006 (2006), pp. 523-529 (“Yang”). Much, but not all, information in UML diagrams represents abstractions. Embodiments of the invention extract and explicitly represent them, to enable shared and common domain theories which foster reuse. Services of a system are dependent on the dynamic interaction of the classes. “ServiceExtract” is a method that uses dynamic interaction diagrams, such as sequence diagrams, to extract the services. Now, the extracted service abstractions can be utilized in new projects. The lower half ofFIG. 1, with steps118-124, shows their reuse.

One or more embodiments of the invention provide one or more of the following: (i) use of design diagrams as a good source of service abstractions, capturing similarity among software projects; (ii) techniques to extract service abstractions from diagrams, such as UML diagrams, from a project; (iii) reasonably accurate service extraction; and (iv) extracted service abstractions which assist software reuse. The aforementioned ServExtract can be implemented, by way of example and not limitation, as a plug-in using IBM® Rational® Software Architect, an advanced model-driven development tool available from International Business Machines Corporation of Armonk, N.Y., USA.

Hereinafter, a standard domain example of student course registration will be presented, as will ServExtract (a technique for extracting service abstractions) using UML diagrams. Information extracted in accordance with one or more embodiments of the invention is reusable and accurate.

UML is often used as both a requirements representation (by an analyst) for expressing customer needs and as a specification representation (by a developer) for documenting what the solution system will do. See UML 2 Modeling Language.

Service abstractions represent logical abstractions that provide high level functions. Services are logical entities that encompass sets of operations to achieve business goals. See OWL-S Semantic Markup for Web Services. In view, for example, of promoting reuse, embodiments of the invention extract and represent the service abstractions.

Reuse of software components (code, library), legacy software systems, and the like, among projects is addressed in Marcus A. Rothenberger, System Development with Systematic Software Reuse: an Empirical Analysis of Project Success Factors (“Rothenberger”); D. Oberle, A. Eberhard, S. Staab, and R. Volz, Developing and managing software components in an ontology-based application server, in 5th International Middleware Conference, LNCS, Springer, 2004; and Happel, H.-J., Korthaus, A., Seedorf, S., and Tomczyk, P., KOntoR: An Ontology-enabled Approach to Software Reuse, in: Proceedings of the 18thInternational Conference on Software Engineering and Knowledge Engineering (SEKE), San Francisco, July 2006. Embodiments of the invention use design diagrams as sources of knowledge such as domain ontology and service abstractions. This knowledge, when extracted and represented, aids software professionals during the various stages of the software development process.

Approaches that rely on pattern, association rule, conceptual pruning, ontology pruning, and concept learning have been used to extract domain knowledge. See, respectively, Morin, E. (1999) Automatic acquisition of semantic relations between terms, from technical corpora, Proc. Of the Fifth Int. Congress on Terminology and Knowledge Engineering (TKE-99), TermNet-Verlag, Vienna; Adriaans, P., Zantinge, D., (1996) Data Mining, Addison-Wesley, 1996; Faure, D., Poibeau, T. (2000) First experiments of using semantic knowledge learned by ASIUM for information extraction task using INTEX, in: S. Staab, A. Maedche, C. Nedellec, P. Wiemer-Hastings (eds.), Proceedings of the Workshop on Ontology Learning, 14th European Conference on Artificial Intelligence ECAI '00, Berlin, Germany; Kietz, J. U., Maedche, A., Volz, R. (2000) A Method for Semi-Automatic Ontology Acquisition from a Corporate Intranet, in: Aussenac-Gilles, N., Bibow, B., Szulman, S. (eds.) EKAW'00 Workshop on Ontologies and Texts, Juan-Les-Pins, France, CEUR Workshop Proceedings; and Hahn, U., Schulz, S., (2000) Towards Very Large Terminological Knowledge Bases: A Case Study from Medicine, in Canadian Conference on AI 2000: 176-186. There has been work that aims at using UML as a representation language for both ontology and services abstractions. See Falkovych and Yang. Aspects of the invention provide an extraction technique that combines a rule based approach with conceptual pruning. One or more embodiments of the invention, rather than concentrating on converting UML to a service or ontology representation language, instead aim at extracting pertinent information from UML diagrams.

Example Domain

Purely by way of example and not limitation, a case study of student course registration taken from the Rational tutorial will be employed as the running example in the exemplary embodiment. In this non-limiting example:

(a) Each semester, students may request a course catalogue containing a list of course offerings for the semester.

(b) The new on-line registration system will allow students to select four course offerings and two alternative choices for the coming semester.

(c) No course offering will have more than ten students and less than three students.

(d) Billing is done for each student for the courses registered.

(e) Professors must be able update their course offerings and see which students signed up.

For the purpose of experimentation and evaluation, in this application, several solutions for the above problem are illustrated.FIG. 2gives the UML class diagram200for an exemplary solution, henceforth referred to as “Solution A” (SolA). Again, purely for illustrative purposes, two other solutions (class diagrams), taken from the aforementioned tutorial website of Rational Software Corporation are also employed; these are referred to as “Solution B” (SolB) and “Solution C” (SolC) (class room lecture of Prof. Dr. Bettina Berendt). These input class diagrams are taken as correct, for purposes of illustrating one or more non-limiting embodiments of the invention.

Classes and associations between two classes are represented as nodes and edges, respectively. Following this notation, inheritance and an aggregation and/or composition relationship can be represented as a Directed Acyclic Graph (DAG). Such a relationship between two nodes A and B is represented as a directed edge between these nodes. Associations of the form “USING” are described as bidirectional and directed edges between the nodes in the representation graphs. The terms nodes and classes are used interchangeably herein, as are the terms edges and associations.

FIG. 2includes registration manager202, student entity204, institute member entity206, professor and course information208, professor entity210, course information212, billing entity214, course package entity216, registered course entity218, and exemplary code statements220,222. In block218, stuId: Integer is an example of an attribute level implementation artifact. Block202is an example of a class level implementation artifact. The arrow between blocks204and206is an example of an environmental artifact.

Extracting Service Abstractions

An exemplary inventive system employs the UML diagrams and extracts Service Abstractions. Service abstractions capture significant functionalities that are offered by the interaction among domain concepts. ServiceExtract identifies them along with the implementation artifacts.

UML elements can be classified broadly as two categories:(a) Implementation artifacts: They represent low level details of the solution, such as messages exchanged and their behavior. These artifacts can be full-fledged classes or specific attributes of a class.(b) Environmental Artifacts: They include ontological entities and relationships, such as generalization (IS-A), aggregation/composition (HAS-A) and the “USING” association among entities. The interaction among the domain concepts in association with the implementation artifacts results in services (functionality).

Although all UML diagrams have domain knowledge, static information (such as concepts, relationships among them, and attributes) can be obtained from class diagrams. Services of a system are dependent on the dynamic interaction of the classes, and therefore ServiceExtract uses dynamic interaction diagrams, such as sequence diagrams, to extract the services. In view of providing a re-usable component, for each such service identified, an exemplary inventive system obtains the implementation artifacts from class diagrams.

Extraction of Service Abstractions

With the advent of Service Oriented Architectures (SOA), a more promising reusable component is a service. The domain analysis can be exploited to identify and design reusable service abstractions. Such service abstractions have significant reuse in a family of products designed in a domain. See James M. Neighbors, Draco: A method for engineering reusable software systems, in Software Reusability—Volume I: Concepts and Models, pages 275-294, 1989. Aspects of the invention extract these service abstractions from low level diagrams.

Two aspects of extracting services abstractions are addressed in one or more embodiments of the invention. In one aspect, both class diagram and sequence diagrams are used to generate services and their implementation artifacts. In another aspect, only class diagrams are considered and a service requirement in the form of the key work is taken as input. The services implementation artifacts are generated using other external sources and dependency analysis to generate the implementation artifacts of the services pertaining to the key word.

Services are traceable through diagrams representing dynamic interactions in the system. Interaction design diagrams, such as sequence diagrams, describe the services provided by objects through the exchange of messages.FIG. 6gives an overview of the system architecture800for extracting logical domain abstractions. As a preprocessing step, class diagrams are used to verify and/or populate the stereotypes for the classes in the sequence diagram. The low level design diagrams802include sequence diagrams1to n, designated as804, and class diagrams1to n, designated as806. As shown at808, ServiceExtract includes three major steps: step810, identification of the name for the candidate service, step812, obtaining the interfaces for the candidate services, and step814, obtaining the implementation artifact for the candidate services. The reusable service name operations are listed in block816and the implementation artifacts that were obtained are listed in block818. ServiceExtract is discussed hereinafter, in the context of both single and multiple sequence diagrams.

The term system is used herein to refer to a group of interacting, interrelated classes. (System is also used herein to refer to a computer system implementing one or more aspects of the invention; the skilled artisan will appreciate the intended meaning from the context). As a non-limiting running example, consider the sequence diagrams500,600, and700shown inFIGS. 3-5, for, respectively, the functionalities “Enroll a student in a course,” “Delete a student in a course,” and “Bill for semester.” Elements inFIG. 3analogous to those inFIG. 2have received the same reference character incremented by three hundred, and will not be separately described. Similarly, elements inFIG. 4analogous to those inFIG. 2have received the same reference character incremented by four hundred; while elements inFIG. 5analogous to those inFIG. 2have received the same reference character incremented by five hundred.

Extraction From Single Sequence Diagram

Services are offered by the system (interaction of classes) to the outside world (user of the system). Sequence diagrams model the interaction between the system and the outside world. In a sequence diagram, an actor (outside element) interacts with the system through the boundary classes. The controller classes carry out the necessary action and use the entity classes to store and/or obtain information. As a sequence diagram provides a single atomic service, the service offering of a sequence diagram can be modeled as a service abstraction.

This can be illustrated through an example.FIG. 3shows the sequence diagram of a student registering for a course. “Enroll a student in a course” is a function (at high level) provided by the system. This functionality is by itself a service in which the actor ‘student’504interacts with the system. When a single sequence diagram is considered, the name of the sequence diagram can be directly used as the name of the service abstraction.

In order to identify the operations of the service abstraction, embodiments of the invention look at the pattern of interaction between the system and the user of the system (actor in this case). The actors interact with the system through the interfaces provided to the boundary class by the system. In other words, the system exposes its services through these interfaces. The interactions between the actor and the system can be categorized into two kinds. They are: (i) the “ACTS UPON” interaction and (ii) the “RESPONSE” interaction.

ACTS UPON interaction: The ACTS UPON interaction reflects the services offered by the system. The boundary class ACTS UPON the system through these interactions. The interfaces contributing to such interactions form the operations offered by the services.

RESPONSE interaction: The boundary class gets the RESPONSE from the system for the requested service through these interfaces

InFIG. 3, the boundary class ACTS UPON the system through the interface “enroll Student(aStudent)”. This interface forms the service interface. The other interaction “enrollmentStatus” is a response from the system to the boundary class. The response messages do not convey any information about the services provided by the system.

The implementation artifacts are all the classes that participate in achieving the functionality. InFIG. 3student, courses, and RegistrationMgr are the classes involved in providing this functionality. These classes are preserved in the class diagram, along with the interactions among them. There might exist, between two classes, other classes (not part of the sequence diagram) that should be preserved. Such classes are eliminated and the relationships are propagated using the following method of propagation. In a class diagram when classes are removed relationships between the remaining classes should be preserved. Embodiments of the invention preserve this relationship by the process of propagation. Propagation results in new relationship (edges) among neighbors. The properties of the new relationship depend on the properties of two dangling edges that result in propagation.FIG. 20shows the nature of edges that are atypical of a relationship. InFIG. 20, case1and case2do not have propagating links, whereas case3is of interest and has propagation edges, where a new association is created between every incoming, bidirectional and outgoing link.FIG. 20thus depicts elimination of a node and its dangling edges.

The attributes such as name, direction, cardinality, and role names of the new association are obtained as follows:

Direction: The direction of the new edge depends on whether the dangling edges were bidirectional or directed. New edge assumes the direction of the dangling edge(s) if the dangling edges were directed; otherwise it is bidirectional.

Role name: The new edges assume the role name of the nodes that the new edge connects.

Cardinality: Cardinality of the new edge is obtained by finding the minimum and maximum number of instances of nodes that the new edge connects; can be associated through the node that is eliminated. In other words, the cardinality is calculated as the cross product of cardinality of the two links that results in propagation.FIG. 21Ashows the propagation of cardinality constraints among the dangling edges.FIG. 21Bshows the new edges with the properties after elimination of a node.

Extraction From Multiple Sequence Diagrams

For effective software reuse, there should be a way to combine separate services, each of which is derived from an individual generic system, to form a higher level atomic service abstraction. If this can be done, the number of service abstractions to be stored, maintained, and understood by potential users will be the total number of concepts, rather than the combinatorial product of the numbers of options for each decision. To make such an approach work, it must be possible to combine multiple services that operate toward a single goal, such as a business or enterprise goal. Higher levels of service abstraction are extracted, in one or more embodiments, by considering multiple sequence diagrams from a project and combining as many functionalities as possible into a single abstraction.

As the services are offered by the interaction of classes, ServiceExtract analyzes these interactions (usage patterns) to determine if the services are contributing to a single business logic. To provide an exemplary demonstration of ServiceExtract, consider two sequence diagrams (note, however, one or more techniques can be extended to any number of sequence diagrams).

As a first step, embodiments of the invention identify the matching classes between two sequence diagrams. If there are no matching classes among the sequence diagrams, then each sequence diagram is modeled as an independent service. However, if the two sequence diagrams have common classes, then further analysis should be performed on the pattern and usage of matching classes, to combine them into a single high level service.

Recall that a controller class performs the actual operation required to achieve the functionality. Therefore, the controller class plays an important role in determining if two services can be combined. If the common set (matching classes) does not have a matching controller class, then it can be said that the two sequence diagrams offer services which are distinctly different. In this case, the two sequence diagrams are modeled as independent services. For example, sequence diagrams shown inFIGS. 3 and 5do not have a matching controller class. In this case, ‘enroll a student for a course’ and ‘bill for the semester’ are modeled as two different services.

On the other hand, services can be combined if the following conditions are satisfied: (i) if the services are requested by the same boundary class, (ii) the services are provided by the same controller class, and (iii) the services use the same entity classes for storage and/or retrieval. Examples of this category are depicted inFIGS. 3 and 4. The interfaces identified in the individual sequence diagram (as interfaces of the individual services) can be combined into a high level abstraction. In this case, ‘enroll a student’ and ‘delete a student’ can be modeled as two operations of a service called “student utility.”

If a subset of classes exist that match between the two sequence diagrams, then the type (pattern) of classes and the level of matching between them determines whether they can be combined. The different usage patterns and their usefulness in identifying the services are discussed further hereinbelow.

Service Consumer Usage Pattern: In a typical product usage it is likely that actors (consumers) act upon an object, such as a business or enterprise object, for obtaining a service. For example, a student (actor) would like to add, delete, register or update his or her course (business object) details. These activities are utilized by the student and can be combined into a high level abstraction. It follows that these operations are performed by a single controller class (towards a business logic). Therefore, if the boundary classes (service requester) and the controller classes (performs the operations) match between the sequence diagrams, then they can be combined. The resultant service will include interfaces exposed to the boundary class in both the sequence diagrams. The name for the service can be either manually assigned or obtained by merging the names of the two individual sequence diagrams.

An example of this category can be seen inFIGS. 3 and 4. The consumer of the service is the ‘student’ (actor). The controller and boundary class are the same. The interfaces exposed can be combined into a service. The table ofFIG. 7presents the output for these input sequence diagrams, with the service in a first column902and the operations in a second column904.

Service Producer Usage Pattern: A service is performed by the controller classes (producer) by either obtaining data or storing data to persistent objects (entity class). If the matching classes between sequence diagrams are controller and entity classes, then the services might be related and combined into a higher level abstraction. The sequence diagrams shown inFIGS. 3 and 4can be considered for this case. The controller class being the same in both cases (class ‘RegistrationMgr’ and class ‘Course’), the two services can be combined. The operations of the combined service are ‘enrollStudent(aStudent)’ and ‘unregisterStudent(aStudent).’ The name for the new service is obtained by combining the names of the individual classes (‘Enroll or delete a course,’ in this case).

It should be noted that the sequence diagram considered in this running example falls under both service producer and service consumer usage patterns. Such inconsistencies are feasible and are addressed elsewhere herein.

Consumer-Storage Usage Pattern: The matching of the service requesting class and the persistent information class does not necessarily convey information about the relatedness of the services. The service requesting class can operate via a different controller to store or obtain information from the persistent objects. The operations performed by the controller class or raised by the boundary class might be entirely distinct. In this case, the two sequence diagrams are modeled as individual services. An example of this category isFIGS. 3 and 5. The course registration and the billing information are different logics (e.g., business or enterprise logics). The table ofFIG. 8summarizes the output using the consumer storage usage pattern for the sequence diagrams ofFIGS. 3 and 5. A first column1002lists the sequence diagrams, a second column1004lists the services, and a third column1006lists the operations.

For all the above cases, the implementation artifacts are obtained by considering all the classes of the sequence diagrams that are to be merged. The set of relationships among these classes is directly obtained from the class diagram and is preserved as implementation artifacts for the service. If there exists no direct relationship between two classes in the class diagram, propagation of relationships (as described above) is used for pruning the relationships.

Inconsistencies

Inconsistency due to pattern mismatch: Inconsistencies might arise while categorizing the sequence diagrams by using different patterns. For example, two sequence diagrams might fall into more than one category. In such a case, the table ofFIG. 9is used to facilitate categorization. A first column1102lists the service consumer, service producer, and consumer-storage, which are also the headings of, respectively, columns1104,1106, and1108. Column1110includes remarks.

Evaluation and Assessment

By way of example and not limitation, an evaluation follows, which concentrates on two aspects: (i) demonstrating that, in one or more embodiments, the extracted service abstractions are reusable and (ii) demonstrating that services abstractions obtained through ServiceExtract adhere to service requirements (demonstrating the correctness of the algorithm employed in one or more embodiments). Again, purely by way of example and not limitation, results are presented based on experiments conducted on two data sets: (a) the pedagogical student course registration and (b) data gathered from a large scale example, which data was used to conduct the aforesaid experiments.

Evaluation of Service Abstractions

Consider multiple sequence diagrams of the student registration problem and obtain the service abstractions. The table ofFIG. 10presents all the services identified from the sequence diagrams, with the service names in column1902and the operations in column1904. The sequence diagrams used for the experimental demonstrations were obtained from various sources, including UML 2 Sequence Diagrams, and Analysis and Design with UML, as well as those presented in “Extraction of Service Abstractions” above.

For illustrative purposes, it will be demonstrated that the extracted service abstractions adhere to the service requirements. Typically, a Service Litmus Test (SLT) is conducted to verify whether a service satisfies the requirements. The skilled artisan will be familiar with service definition. The litmus test puts forward qualitative evaluation criteria for a service. Essentially, such tests evaluate qualitatively whether a component is stateless, discoverable, autonomous, loosely coupled, composable and abstract. The skilled artisan will be familiar with such tests. A comprehensive list of the SLT criteria and methodology can be obtained as known to the skilled artisan. For purposes of the illustrative experimentation, the evaluation for the services was obtained from a group of experts (architects). The table ofFIG. 11presents evaluation of the extracted service abstractions against these metrics. This shows that, in one or more embodiments, the identified services adhere to the service definitions. In particular, column2002lists SLT criteria, and columns2004,2006, and2008list, respectively, the services “CourseRegistration,” “Student,” and “Course.”

Re-Usability Evaluation of Service Abstraction:

For exemplary purposes, consider the domain abstractions and/or services and the operations modeled by experts and/or architects for a problem. Compare these services, along with their operations, with those extracted by ServExtract. Let Anservbe the number of service abstractions defined by the architect and Anopsibe the number of service operations defined by the architect for the ithservice abstraction. Similarly, let Enservrepresent the service abstractions defined by the extraction algorithm and Enopsirepresent the operations for the ithservice abstraction. Then, reusability is measured by equation 2 below. High values of this metric indicate that the extracted abstraction can be used to replace or model the services of a problem in a similar, or the same, domain.

nservMatch=Enserv/Anserv(1)nopMatch=(Enopsi/Anopsi),for⁢⁢all⁢⁢i(2)
where nservMatchrepresents the service matches obtained and nopMatchrepresents the operations matched for each service.

The table ofFIG. 12gives the services modeled by two different experts for the problem defined in “Example Domain” above, and the table ofFIG. 10gives abstractions and the operations that were extracted by an exemplary algorithm, according to an aspect of the invention. InFIG. 12, columns2102and2104list service names and operations for the first architect, while columns2106and2108do the same for the second architect.

Equation 2 is used to measure the matching elements between the extracted abstraction and modeled services. The table ofFIG. 13summarizes the results. Columns2202and2204present services and operations for architect1, while columns2206and2208present the same for architect2. UsingFIG. 13, it can be seen that the number of services that matches the extracted services in the case where Architect1has designed the services is 100%, and the number of services that matches the extracted services in the case where Architect2has designed the services is 50%. In a similar way, it can be seen that the number of matching operations for the services were as high as 50% (the lower value being 25%). It should be noted that the extracted service abstractions and the operations are dependent on the number and the functionality of the sequence diagrams. For exemplary purposes, a limited set of sequence diagrams have been used, as shown inFIGS. 3-5. The reuse factor can be as high as 100% when the entire set of sequence diagram of a problem can be obtained and used for extraction of services. The above results indicate that one or more embodiments effectively extract domain services from low level design diagrams.

Exemplary Techniques Employing Class Diagrams But Not Sequence Diagrams

The examples presented thus far make use of sequence diagrams and corresponding class diagrams. In some instances, it may be desirable to implement techniques that employ class diagrams but not sequence diagrams. Such approaches might be particularly advantageous where sequence diagrams are not available.FIG. 14shows an exemplary architecture2300useful in the case where class diagrams, but not sequence diagrams, are to be employed. Architecture2300also is indicative of processing and data flow.

Dependency generator2306generates the dependency graph using link analysis. Inputs include one or more class diagrams and associated function(s) (functions can be viewed as services), as indicated at2302, and optionally, input such as a seed class and/or domain terminology, and the like, as indicated at block2304. The functional requirement is also taken as input along with the class diagram. The functional requirement is specified as a set of key words representing the function. Relationship analyzer2308analyzes the relationships between classes to obtain the implementation artifacts for the given requirements. The resulting output is a subset of classes, as per block2314.

By way of example, consider the functionality requirement as “authentication.” Given a class diagram2302and knowledge that ‘authentication’ is a process mapped with seed class ‘login,’ then the traversal of the dependency graph using the ‘login’ class will give the required artifacts. Relationship analyzer2308makes use of historical data pertaining to seed classes, relationships, and the like, as shown at block2310; analyzer2308also updates data2310, as indicated by the double-headed arrow between blocks2308and2310. Relationship analyzer2308also makes use of domain terminology, as shown at block2312; and analyzer2308also updates data2312, as indicated by the double-headed arrow between blocks2308and2312.

For illustrative purposes, consider user-defined functions. In such a case, a typical problem might be the identification of artifacts that implement a user defined function, given the class diagram2302and optional seed class2304. In this case, dependency analyzer2306constructs a dependency graph for the given class diagram. Typical rules are as follows:

Unidirectional links using links to unidirectional edge

Bidirectional using links to bidirectional edges

Classes are treated as nodes

Inheritance and/or association to dependency edges (special edges).

Relationship analyzer2308uses the graph to determine the artifacts, given some knowledge. Typical rules include obtaining the seed classes, by using, for example, domain expertise. The system follows the dependency paths and includes all classes that are dependent for a given functionality. In one or more embodiments, for each class included, if there are inheritance links, all parents of the inherited link have to be added, and all parents for the association link (if any are included) are added to the resultant graph.

In the above case, a simple dependency analyzer that follows the links and includes all classes along the path up to termination of the path is used for identifying implementation artifacts. In some cases the relationship analyzer can employ advanced mechanisms like calculation of fan-out and fan-in of classes to determine its functionality. The fan-in and fan-out of classes can be used to determine whether the class represents entity classes (real world domain classes) or boundary classes (that are used for interaction with the system) and controller classes (that achieve the functionality of a service). Once the classes are classified into the existing category(ies), further categorization using external sources can be carried out. By way of further illustration, consider three-tier decomposition. In this case, a typical problem is to identify the user interface (UI) (boundary), business (controller) and data (entity) classes, given the class diagram. A further classification can be used to map these set of classes (UI, business and data classes) to the ‘MVC’ paradigm of the OOD approach. MVC is the Model View Controller concept where the classes in the class diagram either represents the model/view/control classes. OOD is a short form of Object Oriented Design where the design of the software solution follows the object orientation principles. In this case, dependency generator2306constructs a dependency graph for the given class diagram, while relationship analyzer2308may employ ‘fanout’ as a performance metric. ‘Fanout’ defines the ratio of the incoming to the outgoing calls:
Fanout=Incoming link/outgoing link  (3)

Advantageously, a bottom-up approach can be employed. The system identifies the class roles by using the relationships between classes, using the fanout concept. Entity classes are storage and/or persistent elements. These classes often receive messages, since messages are often directed to the storage elements. Therefore, for these classes, fanout is greater than one. Boundary classes raise requests. These classes raise the messages to other classes. Therefore, for these classes, fanout is less than one. Controller classes mediate the requests. Due to mediating the requests between other classes, for every query that is raised there will be a response. Therefore, for these classes, fanout is approximately equal to one. Such patterns and definitions can be used to automatically classify the usage category of the classes.

With reference toFIG. 2, for the entity class “student”204, there is one incoming link and there are no outgoing links; accordingly, the incoming link dominates the ratio. For the entity class “billing”214, there are two incoming links and no outgoing links, so once again, the ratio is dominated by incoming links. Controller classes include the registration manager202, which has two incoming links (including a bi-directional link) and three outgoing links. There are some classes that are not detected; for example, “course,” etc., does not follow the rule. This type of behavior may indicate, in at least some instances, that the class diagram might not have been modeled appropriately.

In view of the discussion ofFIGS. 1-13, and with reference now toFIGS. 15A and 15B, it will be appreciated that, in general terms, an exemplary method2400, after beginning at step2402, includes the step2416of obtaining at least one design diagram from at least one previous software project. Step2450includes extracting, from the at least one design diagram, at least one service abstraction. Step2442includes reusing the at least one service abstraction in a new software project. Processing continues at block2444. Method2400is broken into flow chart2400A inFIGS. 15A and 2400BinFIG. 15B.

In one or more instances, the at least one design diagram includes one or more unified modeling language sequence diagrams and one or more unified modeling language class diagrams from the at least one previous software project, as per sub-steps2404and2406. Step2420may then include extracting the at least one domain ontology from the sequence diagram and the class diagram, and step250may then include extracting the at least one service abstraction from the sequence diagram.

Block2430includes determining whether there are multiple sequence diagrams. If such is not the case, as per the NO branch, the step of extracting the at least one service abstraction will include extracting same from only the single sequence diagram. Such extraction can include, as indicated at block2432, identifying a name of the sequence diagram as a name of the service to be extracted, identifying operations of the service to be extracted by examining interfaces between the service and boundary classes of the sequence diagram, and identifying implementation classes of the sequence diagram used for implementing the service, so as to obtain a service object. The service object characterizes the service to be extracted and includes the operations and the implementation classes.

If there are multiple sequence diagrams, as per the YES branch of block2430, the step of extracting the at least one service abstraction will include extracting from at least first and second sequence diagrams; this, in turn, can include determining whether matching classes exist between the first and second sequence diagrams, as at block2434. If such is not the case, as per the NO branch, the sequence diagrams are modeled separately, as indicated at block2440; for example, by executing block2432on each diagram. If there are matching classes, as per the YES branch of block2434, in block2436, a determination is made whether the first and second sequence diagrams can be combined to form a single high level service; if such is the case, as per the YES branch, they are combined in block2438; while if such is not the case, as per the NO branch, the sequence diagrams are modeled separately, as indicated at block2440; for example, by executing block2432on each diagram. Block2436can include, for example, determining whether the matching classes include a matching controller class, as well as, for example, determining whether the first and second sequence diagrams represent services which are requested by the same boundary class and use the same entity class for storage and retrieval.

As shown at block2406, in at least some instances, one or more unified modeling language class diagrams are obtained from the previous software project. They may be used, for example, to verify and/or populate classes in one or more sequence diagrams. Typically, the class diagrams include the stereotyped classes. These stereotypes can be used to populate the class types in a sequence diagram, and in case the stereotype exists, it is used to verify the correctness. That is, if the stereotyped classes are also present in the sequence diagram, correctness of the stereotyped classes in the sequence diagram is verified by using the unified modeling language class diagram, while if the stereotyped classes are not also present in the sequence diagram, classes in the sequence diagram are populated using the unified modeling language class diagram.

In view of the discussion ofFIG. 14, and with reference now toFIG. 16, it will be appreciated that, in general terms, an exemplary method2500, after beginning at step2502, includes the step2504of obtaining requirements for a current software project. Step2506includes obtaining at least one class diagram from at least one previous software project, while step2508includes generating a dependency graph from the at least one design diagram, using link analysis. Step2510includes analyzing relationships between classes in the dependency graph to obtain functional artifacts for the requirements; and step2512includes reusing the functional artifacts in the new software project. Processing continues at block2514.

In some instances, with reference toFIG. 18, the step2508of generating the dependency graph includes treating classes in the class diagram as nodes and the links are interpreted using the following rules:If a directional link exists, then the link is preserved as unidirectional.If bidirectional links exist, then they are preserved as bidirectional linksInheritance and/or association to dependency edges are considered as special edges and are preserved as is.

To summarize, if there is a unidirectional edge in the class diagram between two classes, insert a unidirectional edge on the corresponding nodes in the dependency graph. Similarly, insert a bidirectional edge for a bidirectional link between classes. Inheritance and/or associations between classes are modeled as special edges in the dependency graph. Completion of these three steps will lead to the generation of a dependency graph. Thus, as seen inFIG. 18, in one or more instances, the step of generating the dependency graph includes, as seen at block2702, treating classes in the class diagram as nodes. As per block2704, an additional step includes determining whether there is a unidirectional edge, in the class diagram, between two of the classes. In block2706, responsive to determining that there is a unidirectional edge, in the class diagram, between two of the classes, the system inserts a unidirectional edge on corresponding nodes in the dependency graph. In block2708, the system determines whether there is a bidirectional link, in the class diagram, between two of the classes; and in step2710, responsive to determining that there is a bidirectional link, in the class diagram, between two of the classes, the system inserts a bidirectional edge on corresponding nodes in the dependency graph. Step2712includes modeling at least one of inheritances and associations between the classes in the class diagram as special edges in the dependency graph. In some instances, steps may be performed by, or with the aid of, human intervention, instead of or in addition to performance by a computer system.

Furthermore, in some instances, with reference toFIG. 19, the step2510of analyzing the relationships includes obtaining a plurality of seed classes, following dependency paths in the dependency graph to identify all of the classes which are dependent for a given functionality; and employing the following rules to obtain the implementation artifacts of the required functionality.

Obtain the seed classes, using, for example, domain expertise. The seed classes are those classes that are related and/or required for the functionality. Typically, these classes are obtained from domain experts, who provide a list of classes that can implement a functionality. The actual class diagram(s) from one or more previous projects can be included in either all or a subset of these seed classes. To extract implementation classes for a functionality, for each of the seed classes, follow the dependency paths and include all classes that are dependent. In one or more embodiments, for each class included, if there are inheritance links, all parents of the inherited link have to be added and all parents for the association link (if any included) are added to the resultant graph. The classes that have been obtained following the dependency classes and all the classes related to these dependent classes, either through inheritance or through containment, are all part of the implementation artifact for a given functionality (specified in terms of seed class).

To summarize: obtain seed classes from domain expertise. Seed classes become the starting point for traversing the dependency graph. Follow dependency paths in the dependency graph to identify all of the classes which are dependent for a given functionality (these classes are the classes in the class diagram). If a seed class is input, start from that class and include all classes in the graph which are dependent on that initial class for a given functionality. In one or more embodiments, for each class included, if there are inheritance links, all parents of the inherited link have to be added and all parents for the association link (if any included) are added to the resultant graph. The output of traversing this dependency graph is a functional artifact which can be reused in a new software project. A non-limiting example of a functional artifact is the implementation classes for a given functionality.

Thus, as seen inFIG. 19, in one or more instances, the step of analyzing the relationships includes, as shown at block2802, obtaining a plurality of seed classes, based on domain expertise; and, as shown at block2804, beginning with the seed classes, following dependency paths in the dependency graph to identify all of the classes in the class diagram which are dependent for a given functionality, to obtain the functional artifacts.

Exemplary System and Article of Manufacture Details

A variety of techniques, utilizing dedicated hardware, general purpose processors, firmware, software, or a combination of the foregoing may be employed to implement the present invention or components thereof. One or more embodiments of the invention, or elements thereof, can be implemented in the form of a computer product including a computer usable medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention, or elements thereof, can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps.

Accordingly, computer software including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (for example, ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (for example, into RAM) and executed by a CPU. Such software could include, but is not limited to, firmware, resident software, microcode, and the like.

Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium (for example, media2618) providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus for use by or in connection with the instruction execution system, apparatus, or device. The medium can store program code to execute one or more method steps set forth herein.

Input/output or I/O devices (including but not limited to keyboards2608, displays2606, pointing devices, and the like) can be coupled to the system either directly (such as via bus2610) or through intervening I/O controllers (omitted for clarity).

It will be appreciated and should be understood that the exemplary embodiments of the invention described above can be implemented in a number of different fashions. Given the teachings of the invention provided herein, one of ordinary skill in the related art will be able to contemplate other implementations of the invention. Indeed, although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.