This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Abstract. This article revolves around generation of class diagrams from use cases. Contents are as per the review of five chosen research papers dealing with the generation of class diagrams. First part of article focuses on using UML to understand requirements in Business process and some basic rules to be followed while drawing a use case and class diagrams. Second part concentrates on automated transition from use case to class diagram. Some language patterns are introduced to make sure that automatic processing from use cases is possible. Implementation of tool is described. And it proposes an algorithm to i) extracting use cases from requirements ii) validating use cases so that classes can be identified and thereafter classes are automatically obtained from previously generated use cases. At last use case model is applied to validate the design.
Keywords: Use cases, Object-oriented design, Class identification and modeling.
The starting point for modeling requirements with the UML is use case. From users perspective use case diagrams are formalized notation for modeling. Use cases focus on what the system does and its behavior; it doesn't consider how it achieves it. A class is a 'description of set of objects which share same attributes, relationships, operations and semantics'. And some rules to be followed while drawing the diagrams so that we maintain consistency between them. To identify the objects from requirements and then to model in class diagrams is a difficult task because for that both domain experience and expertise are needed. Since there are no guide lines, so it presents an approach with set of artifacts and methodologies. To automate transition some language patterns are introduced. Some rules are summarized and adopted to automate. It introduces robustness analysis to bridge the gap between a use case and its realization. Alternatively three level algorithm is also discussed.
Use case typically represents some functionality of a system as perceived by user. It captures the contracts between stake holders of a system and its behavior. A use case notation consists of actors, use cases and associations. An actor represents the role played by a human or non human with respect to system. One single role can be played by multiple people. Actors execute use cases and the link between them is called association which says that there is a link between actors and use cases for sending or receiving messages. There are three types of associations between use cases: extension, inclusion and generalization.
Fig. 1. Example figure of use cases
Classes represent things and relationships represent connections between things. It says that there are mainly three types of relationships they are aggregation, association and generalization.
Fig. 2. Class diagram and association
In one of the paper it specifies some basic rules for drawing use case and class diagrams they are:
Name of use case must be verb
Use case must match interaction
Name of class must be noun
Attributes must be private
Classes must have methods
No abstract leaf classes
Multiplicity must watch in object diagram
No instances from abstract classes
After developing use case diagram the next step of analysis is use case realization. In UML collaboration or sequence diagram describes how use case is realized and interact with objects. Objects need to be identified before or either diagram can be created. It is hard to transit from use case to collaboration or sequence diagram without objects. To avoid such thing robustness diagram is introduced as a halfway point to bridge that gap. In the stage of robustness diagram attributes of objects and stereotyped objects are identified. In stage of collaboration diagram interactions among objects are identified.
Fig. 3. Example diagram of robustness
Automating the transition:
The methods and mechanisms used in automating the transition are discussed below:
Rational rose tool:
When documentation is done based on requirements and artifacts crested during development are named and specified and it is common that different engineers use different terms. This makes communication inside communication team problem and leads to deviation and mistakes. It introduces a shared vocabulary which makes requirements unambiguous. It introduces a glossary to remove the vagueness in natural language.
Use case language patterns :
As use cases are written freely without following any constraints it will give rise to semantic vagueness, which creates a problem when automating the transition. It introduces some language patterns which can partly formalize the use case language. Below tables lists the basic language patterns;
Fig. 4. Table of basic language patterns of use case
Process pattern :
For each and every use case with detailed specification, there is a corresponding use case realization. For that use case realization two artifacts are generated the robustness diagram and collaboration or sequence diagram which distribute the behavior to analyses classes found.
Fig. 5. Transition diagram from use case to class
The case tool is designed and developed as add- in of rose. The functionality of that tool is divided into two parts: one is use case realization and other is class diagram generation. This arrangement follows the process patterns. The use case specifications are generated and processed by XML (eXtensible Makeup Language) according to the XML schema. The corresponding XML schema is constructed based on use cases template and language patterns. The processing and parsing of XML files are done by vc++ with support of Xerces project . Then glossary can be loaded to tool according to different domains. This is also encoded in XML as well. The creation and visualization of UML artifacts are performed using the REI (Rational Rose Extensibility Interface).
NLP based case systems:
The following table describes strengths and weaknesses of NLP case tool
Fig. 6. NLP based case systems
NLP based case tool has many problems in automatic class generation because of inherent language ambiguity in requirements text. The solution of this is a Three level algorithm.
Three level algorithm :
A Three level algorithm is obtained to generate use cases from which classes can be obtained: 1) Extracting use case sentences from requirements. 2) Fill missing scripts in the use case sentence based on the pre defined verbs with corresponding indirect objects and indirect objects exclusively used for software development use. 3) Reuse validated/unambiguous domain use case sentences from previous analysis work. In level 1 the system gets the parse tree for a sentence then it checks the type of the verb if the verb is labeled as auxiliary or a classification verb then the system performs extraction of candidate classes and their attributes and moves to next sentence, else if the type of verb not a classification verb then the system does the following i) if the subject is an actor and there is no indirect object, the system flags the sentence as "no indirect object". ii) if sentence starts with "if" and sentence is known as previous objects then it flags as a "no conditional actor". Then the system saves the sentence to extracted Use case list. In level 2 it updates the use case list. In level 3 the system retrieves the use case from previous use case then the system makes comparison of semantic roles of the sentences of the stored use cases and semantic roles of processes use cases :if no match is found the add the stored use cases to the Final use case list.
Guide lines for Validation process :
Underline all noun phrases in the requirements document. Decide whether each noun phase can be represented by a class in a class diagram. For the noun phrases which do not represent classes, decide whether these can be represented as a attributes in class diagram instead. For the verbs or other sentences which represent actions performed by system classes or system. Decide whether these actions can be represented as a methods in the class diagrams
Create one sequence diagram for each use case. Study each use case description carefully, and underline the verbs and sentences describing an action. Decide whether it can be represented by one or more methods in the sequence diagram .
Validation of class diagram:
Considering each method in sequence diagram, if several methods together form a system service then treat it as single service. For each method or service, confirm the class that receives the method call contains matching or same functionality. If an object in class A calls a method in call B, then there should be association between classes A and B in the class diagram. If the class diagram contains any hierarchies, then we may trace the hierarchies upwards while validating it. If the validation in the previous step fails update it.
I have gone through different research papers which specified different methods and tools for automating the transition from use case to class diagrams. First two papers specify basic notations. One of paper deals with rose tool and follows its own style of methodologies. The other paper deals with Three level algorithm and argues that Three step level algorithm described in that paper can significantly ease the burden of identifying classes and it presented a test case showing manual application of algorithm using genuine outputs from NLP tool. And the other paper deals with Tau UML suite from Telelogic . After comparing all papers Rose tool is more effective in my perspective.
Though the software development, developers may make some basic mistakes, to ensure that diagrams are correct and consistent some basic rules are discussed. The methodology to automate the transition from use case to class diagram is discussed. Use cases, robustness analysis, the patterns and practices which is used for transition are discussed in detail. The implementation of Rose case tool is also discussed. To overcome the disadvantages of NLP tool the Three level algorithm is discussed and at last how to validate the class diagrams also discussed.
Telelogic Tau UML suite
Bryant, B. R. "objects oriented natural language requirement specification"
Borstler, J.Record-requirements collection "reuse and documentation"
An Automated NLP based case tool
The Apache XML project,
Lee, B. S. "automated conversion from requirements documentation to an object oriented formal specification language" in the proceeding of SAC 2002.
 Applying use cases to design versus validate class diagrams - a controlled experiment using a professional modeling tool Anda, B.., Sjoberg, D. I. K.; Empirical Software Engineering, 2003. ISESE 2003. Proceedings. 2003 International Symposium on 30 Sept.-1 Oct. 2003 Page(s):50 - 60 Digital Object Identifier 10.1109/ISESE.2003.1237964
IBM, Rational rose,
 Derivation of Classes from Use Cases Automatically Generated by a Three-Level Sentence Processing Algorithm Giganto, R.; Smith, T.; Systems, 2008. ICONS 08. Third International Conference on13-18 April 2008 Page(s):75 - 80 Digital Object Identifier 10.1109/ICONS.2008.50
Basic Rules to Build Correct UML Diagrams Alanazi, M.N.;
New Trends in Information and Service Science, 2009. NISS '09. International Conference on June 30 2009-July 2 2009 Page(s):72 - 76 Digital Object Identifier 10.1109/NISS.2009.252
Requirements analysis and UML use cases and class diagrams
Vidgen, R.; Computing & Control Engineering Journal Volume 14,Â Issue 2,Â April/May 2003 Page(s):12 - 17