2009 ISECS International Colloquium on Computing, Communication, Control, and Management (CCCM 2009)

978-1-4244-4246-1/09/$25.00 ©2009 IEEE CCCM 2009

An approach for modeling business application using refined use case

Jinan Duan Information Science and Technology Department

Beijing University of Chemical Technology Beijing, China

E-mail: jarenduan@gmail.com

Abstract—Use cases are often recommended as a powerful tool to find classes when moving from requirements analysis to design. However, non-prescriptive use cases are hard to parse and analyze. Traditional approach for identifying objects includes simple noun/verb search[1] and interrogation of the use case diagram[2]. These ways might involve much human participation and are not effective enough[3]. Effectively finding class within the use case is still not entirely obvious. On the other hand, large amount of modern business applications, especially the data-centric enterprise information systems, have a certain pattern in their models. Thus how to modeling these applications from the frequently changing requirements become an important problem. This paper presents an approach for generating business application models using refined use cases and mapping them to classes. Finally this paper presents an automatic tool – ModelGenerator -- for designer to modeling these business applications from the refined use case.

Keywords- use case; modeling business application; eliciing object; requirement analysis

I. INTRODUCTION Use cases are not only a requirements description tool;

they are also useful in recommended means of aiding the transition from a problem domain-oriented view to a solution-oriented view of the system [4]. The noun/verb searching is well known as being used to find object in the problem domain. However, this simple approach has a few problems with large amounts of textual use case documentation [5]. A more prescriptive approach presented by Fernandes and Machado[6] introduced three kind of objects (entity, interface and control) for modeling a real application. Liang[7] proposes an entity model between the use case goals and a class model by questioning the goals the actors. It can elicit classes from use case by using interviewing and Elicitation Questions[8] which involves many human behaviors. It is so hard to find classes from use cases that use case are used as a validation tool instead of a modeling tool in many circumstances. Though applying those approaches such as interviewing and typical noun/verb searching are both very beneficial, moving from use cases to design classes is still not effective.

On the other hand, modern business applications have their own characteristic in their lifecycle. They usually are built on popular technologies, so they have certain pattern in their models, such as behaviorally-weak object, multiple logical layers, etc. Simultaneously, data-centric and frequently changed requirements become obstacles during

object-oriented modeling process. It forces designers to maintain or modify existent model to fulfill the new coming requirements. Thus, the ideal way is to describe requirements in a proper form [9] that computer and human both could understand, and then computer automatically generate model from the requirements. This paper presents an approach using refined use case to aid designers to generate business application model. The rest of this paper is organized as follows. Section 2 discusses refined use cases. Section 3 introduces our approach and a few issues about modeling business application from refined use cases. Section 4 introduces a tool based on the approach which can help developer model their application. Section 5 gives some conclusions.

II. REFINED USE CASES Use case is functionality-oriented procedure description

from a user’s point of view, which differs from object-oriented model we expected very much. To bridge the gap between use case and object, this paper introduces refined use cases, a document written in a kind of high-level language form, for requirement analyst or designer to describe the user action flow, system’s response, pre-condition and interfaces etc. Designer could get the refined use case from the use case, diagrams, business rules or any other documents obtained in requirement analysis phrase, or they could get directly from the original requirements by communicating with final user of the application. Through the designer participation, requirements are refined into a certain form that computer could understand, this is the first step for computer to build model for us.

Figure 1. Refined use case for creating a new order

For example, supposing that we’re developing a product sale system, Figure 1 shows a possible refined use case for the requirement, creating a new order for customer.

As the figure shows, NewOrdercase is a refined use case describing the process of creating a new order. PreCondition section points out the pre-condition of executing the case, normally authority checking. Data section describes data sources and formulas involved in the case. Flow section is the core of the case. Fill consists of actions, and each of them describes a concrete user operation or system response. Constraints section represents constraints of data. And Post represents end of Fill process, system will take over and handle the data. To describe a complicated action flow, such as multiple alternative flows in a use case, there could be several Fill-Constraints-Post structures in Flow which could be parallel or embedded in each other. Flow section only concern about the data structure and data stream, while all the visual states and behaviors are being described in View section.

In requirements analysis phase, original requirements are usually simple textual for reading and comprehension. Being written casually, they can’t be parsed effectively by computer even with natural language understanding. There is no effective way to convert original requirements to refined user case, Thus, designers’ participation is still necessary for grabbing knowledge from unformatted use cases or other requirements and keeping their semantics, however, designers don’t have to worry about how to modeling, they just concern about how to express the requirements in the expected way using refined use case. It is computer’s responsibility to build model. And naturally, when requirements changes, designers just need directly modify existent refined use cases to fulfill the changed requirements, and then, model will be modified automatically by computer, which reduces a large amount of work.

III. MODELING FROM REFINED USE CASES

A. Business application From practical point of view, there are relatively mature

patterns of model in modern business application built on popular technologies, such as Java EE or .NET platform:

1) A business application usually has been divided into couple of logical layers, such as entity persistence layer, business logic layer and UI layer.

2) An entity persistence layer encapsulates data using simple “dumb objects” which barely has any behaviors.

3) A business logic layer provides services using components like “controller classes”, the controllers change the entities states based on specific business logic.

4) A UI layer provides visual elements such as controls for users to invoke the functions of controllers, and get the feedback for users.

B. Mapping refined use case to classes According to above reasons, we introduce a set of

mapping rules as the guidance of modeling business application from refined use cases.

1) Rule 1: mapping case to controller class Each refined use case describes a functionality unit that

provides a group of related services. By executing the case, user can invoke the method to modify system state. It resembles the controller class in modern business application. So we map case to a controller class, for example, NewOrderCase is mapped to NewOrderController.

2) Rule 2: Mapping action to method of controller class. Given an action like:

user save name, age, gender as customer (1)

Where save is an operation that user wants to execute, which should be one of the services provided by the controller. So save is mapped to method of controller class.

3) Rule 3: A object holding other object is mapped to an Entity class or a Collection class

For the action (1), because user wants to persistent three fields into an object, Customer is obviously holding name, age and gender. So it is an entity. We map this kind of object to entity classes with an ID field for the sake of persistent. This kind of actions in refined use case holds semantics of models. When designers are writing those actions, they actually point out the entities.

Another example for identifying collection class is as follow:

user select customer in customer-list (2)

Obviously, user wants to select a few customers from the list of customers, so we need to map customer-list to a Collection class of Customer class. In general, we consider A-list as a collection class for A. For example, “product-list” is mapped to a collection class of “product”, where “product” object could be an entity or just a field.

4) Rule4: Mapping field to attribute Considering an action:

user input name (3)

Where name holds a string, it is mapped to an attribute of controller class. There is an exception when the field “name” is referred by an action like (1), name should be move to entity class from controller class, becoming an attribute of Customer class, and Customer is an attribute of controller class.

5) Rule 5 : Inferring data type of field Field could be in any kind of simple data type like: int,

float, decimal, datatime, etc. There are several ways to decide field type:

a) Specificed by designers: designers can specific field type in the refined use case for the sake of precision.

b) Inferring from expressions: there are many formulas and constrains in the refined use case. We can infer field type from the expressions within them.

c) Inferring from controls in the view: if a field was bound with a control in the view, we can infer its type from the value type of that control.

d) If there is no obvious type, just use “object”. This approach builds model by applying those rules on

each action or case. So every element of model, such as classes, attributes and methods, is iteratively established. As the more and more cases being parsed, field might be lift up to an entity, so that it can hold fields or other entities, or its type is lift from integer to decimal for more precision. After all the cases are parsed, we can get a complete reference relationship among classes which fulfill the current requirements.

C. An Example Considering the refined use case in the Figure 1, we

analyze the case line by line, and the modeling process is as follow:

1) According to Rule 1: NewOrderCase is mapped to NewOrderController class.

2) According to Rule 3: Product entity class is identified from Data section

3) According to Rule 4 and 5: a Boolean typed field “available” is mapped to Product.Available attribute, and “unitprice” is also mapped to Product.Unitprice attribute.

4) According to Rule 4: product-list, product, price and amount become attributes of NewOrderController class

5) According to Rule 3 and 4: “orderItem” is mapped to Orderitem class. Product, price and amount are moved to attributes of Orderitem from NewOrderController class. Orderitem is a attribute of NewOrderController class

6) According to Rule 3 and 5: Order class is identified, and a date-time type field “orderTime” is mapped to Order.OrderTime. Orderitem-list is removed from NewOrderController class and become Order.OrderItem-list attribute.

7) According to Rule 2: Save is a method of controller class. Figure 2 shows what we finally got.

Figure 2. Model for the refined use case

D. A few issues about this approach 1) There should be syntax supporting for multiple

instances of a same class: because we use instance to infer class, which is simple and effective, but also might involves ambiguous explanations. Using a prescriptive postfix can partially solve the problem.

2) New requirements may conflict with the former requirements: such as different objects with same name. Designer should eliminate the inconsistency among requirements when they are trying to get valid refined user case.

3) The entities identified are “dumb object” without behaviors and inheritance hierarchies: Although they are not modeling in a “pure” object-oriented way, they fit well for the modern distributed environment in many circumstances.

IV. MODELGENERATOR – A TOOL FOR BUSINESS APPLICATION AUTO-MODELING

Based on the concepts introduced in the previous section, we present a supporting tool – ModelGenerator, which is a project of Intelligent Engineering Laboratory, Information Science and Technology Department of BUCT. The project aims to build a tool for automatically modeling of business applications. ModelGenerator takes refined use cases texts as its input, and outputs source code files which implement the classes of entities, controllers and views in C#. It supports entire process of the approach, including analyzing refined use cases text, parsing the actions, mapping to the classes and generating the codes.

In order to support the refined user case syntax, there is a tiny built-in description language called Refined Use Case Description Language (RUCDL) inside of ModelGenerator. RUCDL supports most of the features we discussed above. RUCDL uses syntax as simple as possible, for example the action description

user/sys verb object0 [, object1…]] [prep object] (4)

Each action represents only one user operation or system response without further responsibility. This kind of syntax close to natural language is easy for designers to read and write, which avoids high learning-curve and maintenance costs. RUCDL now is still evolving under development. There are still some very complicated requirements cannot be transformed to refined user cases by RUCDL at present, so it might need designer to do a little modification. With more and more features added, it can support even more and much complicated requirements in the future.

V. CONCLUSION This paper represents a modeling approach which

identifies classes and the relationships between them for business application from refined use cases. It provides a use case refining language for designer to establish the refined use case from the original use case or other requirements. It

also provides a set of mappings for bridging the gap between the refined use case and objects, so that developer can use a tool like the one introduced by this paper to generate the models. The designers do not need to concern how to build models to fulfill the requirements, which reduce large amount of model maintaining work. This paper shows an example of applying the approach in object modeling. The classes generated by the approach are based on a popular pattern of modern business applications. The author thinks that the approach in general has following special characteristics in comparison with other use case-driven object modeling approaches:

1) Automatically model generating: the approach focuses on automatically generating model by using refined use cases rather than depending on much human behavior. Although it still involves human anticipation, there is a very good concern separation for designers and the model maintenance become efficiency.

2) Concerning about modern business application: it identifies entities, controllers using a set of mapping which is based on mature pattern of modern business applications, so the classes and their relationships fit for modern business application implement well.

3) No future costs: Traditional modeling approach might obtain a very rich model, however, the models that this approach generates only focus the present requirements from a user perspective, so it’s simple and clear. There is no complicated inheritance hierarchies and multiple interfaces which are based on certain estimation of the future

requirements. It also avoids the costs for those future features.

REFERENCES

[1] Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G., 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Wokingham.

[2] Liang, Y., 2003. From use cases to classes: a way of building object model for UML. Information and Software Technology 45, pp,83–93.

[3] Booch, G., Rumbaugh, J., Jacobson, I., 1999. The Unified Modelling Language User Guide. Addison-Welsey.

[4] Overmyer, S., Lavoie, B., Rambow, O., 2001. Conceptual modeling through liguistic analysis using LIDA. In: 23rd International Conference on Software Engineering. Toronto, 12–19 May. IEEE Computer Society Press, Toronto, pp. 401–410.

[5] Rubin, K., Goldberg, A., 1992. Object behavior analysis. Communications of the ACM 35 (9),pp. 48–62.

[6] Fernandes, J.,Machado, R., 2001. From use cases to objects: an industrial information systems case study analysis. In: Wang, Y., Patel, S.,Johnston, R, (Eds.), 7th International Conference on Object-Oriented Information Systems, Calgary, 27–29 August, In: Lecture Notes in Computer Science. Springer-Verlag, London, pp. 319–328.

[7] Liang, Y., 2001. Actor-led object modeling for requirements and systems analysis. In: Lecture Notes in Computer Science. Springer-Verlag, London, pp. 37–46.

[8] Practical experience of eliciting classes from use case descriptions, Karl Cox,Keith T. Phalp Journal of Systems and Software Volume 80 , Issue 8 (August 2007) ,pp. 1286-1304

[9] Hurlbut, R., 1997. A survey of approaches for describing and formalizing use cases. Technical Report XPT-TR-97-03, Expertech Ltd., <http://www.iit.edu/~rhurlbut/xpt-tr-97-03.html>.