ICGST-AIML Journal, Volume 12, Issue 1, July 2012
Toward An Intelligent Requirements Tool for Modeling Use Cases and Domains in Object‐Oriented Software Processes Azhari Gasmalla1 and Moawia Yahia2 Dept. of Computer Sciences and Information. Faculty of Sciences and Art AlJouf University, AlJouf, Saudi Arabia 2
King Faisal University, Alhasa 31982, Saudi Arabia azhari@ju.edu.sa, meyahia@hotmail.com cripples the resulting system if done wrong. No other Abstract part is more difficult to rectify later" [1]. The purpose of this paper is to discuss the ability of Carl Zetie stated “No single factor is responsible for developing a fully automated requirements tool that more wasted effort, rework, or failed projects than can be used to model use cases and domains in inadequate requirements.” [9] One study of factors object‐oriented software processes. Knowledge base challenged projects revealed that 37% of factors and natural language processing, some of artificial related to problems with requirements, making intelligence techniques, were utilized in the requirements issues the largest single contributor to development of the proposed tool. The results problems [3]. Ambiguity‐ where something can be indicated the possibility of developing requirements interpreted in more than one way‐ is endemic in tool that dispense with human intervention in many natural language, and therefore a considerable cases of modeling use cases and domains. Such tool problem for requirements that are written in natural can be used to support software named entity language [2]. Misinterpretation of requirements is recognizer building and vice versa. the source of over 40% of all software defects [6]. Writing use cases‐ stories of using a system‐ is one of Keywords: Requirements Tool, Natural Language excellent techniques that are used to understanding, Process, Knowledge base, Named Entity Recognizer, describing, finding‐ and more broadly, manage‐ Use cases, Domain Model, Computer‐Aided Software requirements [3]. Engineering Tool. CASE‐ Computer‐ Aided Software Engineering‐ tools are a class of software that automates many 1. Introduction activities associated with the software process‐ a Requirements engineering is crucial to the success of method of developing software. Tools that reduce the system engineering process .It is an important the amount of effort required to produce a work part of the systems engineering process and is cited product or accomplish some project milestone have as being critical to the success of the majority of the substantial benefit. But there’s something that’s world’s major construction, aerospace, and even more important. Tools can provide new ways of information system projects [16]. Errors in looking at software engineering information—ways requirements are mainly provoked by a gap existing that improve the insight of the engineer doing the between users and system development process. work. This leads to better decisions and higher This gap is due to the manual nature of requirements software quality [5]. engineering process since requirements are Software developers always looking for such CASE informally sought by analysts from users who then tools that assist them in many different ways during pursue others development activities according to the different development phases of software, so what they understand about users’ needs. One way that they understand the software and prepare a to bridge this gab, is an automatic generation of good end product that efficiently fulfill the user specifications from informal requirements [17]. "The requirements. Obviously, CASE tools provide the hardest single part of building a software system is ways that can fulfill these requirements of software deciding precisely what to build. No other part of the developers. But, There is limited scope for process conceptual work is as difficult as establishing the automation. This is due to the immense diversity of detailed technical requirements, including all the software process and its need for human judgment interfaces to people, to machines, and to other and creativity [18]. software systems. No other part of the work so 1
21
ICGST-AIML Journal, Volume 12, Issue 1, July 2012
database application development1. It is nothing more than a tool for visualizing models with automated notations and documentations. CaseComplete® is a software application from Serlio Software that allows business analysts and software developers to create and manage Use Cases and Software Requirements. CaseComplete® provides the ability to edit the textual portion of use cases and requirements in a guided environment and the ability to create various types of diagrams including use case diagrams, wireframes of graphical user interfaces, and flowcharts2. The user needs to populate specific forms (of specifications), and then the tool generates related models in text or figure context. The contribution of the paper is to address the requirements tool that fully automated the modeling of use cases and domains by adapting techniques from artificial intelligence (AI), in other words, the creation of an intelligent requirements tool. The organization of the paper is as follows: the second section addresses the methodology of the proposed tool, and the third section explains AI techniques that can be applied in the tool development. Section four determines the NER the proposed tool can be integrated with the proposed tool. Section five addresses address the relationship between Software NER and the proposed tool. Section six presents case study for the application of the proposed tool. Finally, the paper includes list of references and biographies. “Software processes are complex [13] and, like all intellectual processes, are reliant on human judgment. Because of the need for judgment and creativity, attempts to automate software processes have met with limited success. CASE tools can support some more process activities but there is no possibility, at least in the next few years, of more extensive automation where software takes over creative design from the engineers involved in the software process. One reason why there is limited scope for process automation is the immense diversity of software process. There is no ideal process and different approaches to software development. Processes have evolved to exploit the capabilities of the people in an organization and the specific characteristics of the systems which are being developed. Therefore, even with the same company, there may be many different processes used for software development.”[7]. In sum, requirements engineering is complex, error prone and in need of intelligent support for capturing complete, consistent requirement specifications and guiding the requirements engineering process. One solution advocated by the ESPRIT Nature project is to populate tools with domain abstractions to assist requirement specification [12]. A fully automated CASE tool is a CASE tool that automates all steps and guideline of methods of software process, and should be capable to use the professional experiences when there are no guidelines or apparent activity. Moreover, it must have a capability to translate informal inputs (or fuzzy input) to formal outputs. Each of these advances in CASE tool power will need to draw heavily on the field of AI before it will succeed. The domain of AI has techniques that can be used to deal with the using of past experiences, fuzzy, optimization and learning problems. Such techniques include expert systems, knowledge base, fuzzy logic, genetic algorithm, and machine learning – respectively. The essence, requirements engineering can be essentially improved by applying AI techniques [12][14] and applying AI technology in this area is appropriate because requirements are never ‘correct’ [15]. There is a large variety of existing literature that aims to help articulate the requirements of users. There are also a great number of commercial tools available to build, model and analyze business processes. IBM’s Rational Software is a prime example of the huge commercial effort that has gone into this field. Despite this, the requirements gathering process is still fraught with difficulties. IBM® Rational Rose® Data Modeler offers a sophisticated visual modeling environment for 2. The Tool’s Methodology Every tool has a specific methodology for designing and modeling of the system. Every CASE tool follows a methodology for the model the system. People who use any specific CASE tool for a longer period of time get used with the methodology of that tool and they try to apply the same methodology for other projects. The proposed tool models use cases and domains. The basic procedure for defining use cases is [3]: 1. Choose the system boundary. It is just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization? 2. Identify the primary actors‐ those that have user goals fulfilled through using services of the system. 1
. See http://www01.ibm.com/software/awdtools/developer/datamodele
r/
2
. See http://www.casecomplete.com/
22
ICGST-AIML Journal, Volume 12, Issue 1, July 2012
3.
Identify user goals for each primary actor. Raise them to the highest user goal level that satisfies the EBP3 guideline. 4. Define use cases that satisfy user goals; name them according to their goal. Defining use cases step has several level of effort, ranging from a few minutes to simply record names, up to weeks to write fully dressedz versions. In general, define one EBP‐level use case for each user name. Also, name use cases starting with a verb. A domain model illustrates meaningful conceptual classes in a problem domain; it is an important artifact to create during object‐oriented analysis [3]. Two techniques are presented to identify conceptual classes: 1. Use conceptual class category list. Identify noun phrases If there is an actor, a, and has user goals that fulfilled through using services of the system then generate fact that: PrimaryActor(a) Figure 2. Rule demonstration knowledge base for finding primary actors. Problem Statement NER Named Entities 3. The Tool’s Development Techniques Primary Actor Evaluation KB Generally, the tool uses two artificial intelligence techniques, knowledge base (KB) and natural language processing (NLP). In modeling use cases and with respect to the choosing of the system boundary; the tool uses the following domain‐specific knowledge base: For the purposes of software development, the system boundary is usually chosen to be the software (and possibly hardware) system itself. Figure 1 illustrates the representation of choosing‐
system‐boundary knowledge‐base: if there is software development purposes then generate fact that: System Boundary Is (software) Primary Actors
Figure 3. Finding primary actors’ data flow. Sometimes, goals reveal the actors, or vice versa. So, for each primary actor, to identify their goals, the tool uses the following domain‐specific knowledge: Searching up the goal hierarchy to find higher level user goals that still satisfy the elementary business process (EBP) guideline, to get at the real intent behind the action, and also to understand the context of the goals. Figure 4 illustrates the representation of identifying‐
user‐goals knowledge‐base. If there is an actor, a, which has a goal, g, that satisfy EBP guidelines then generate fact that: UserGoal (a, g) Figure 1. Rule demonstration knowledge base for choosing system boundary. An actor is something with behavior, such as a person (identified by role), computer system, or organization. As for identifying primary actors and user goals steps, the tool uses named entity recognition (NER) technique to extract actors, then uses the following domain‐specific knowledge to evaluate each actor: Primary actors have user goals fulfilled through using services of the system. Figure 2 illustrates the representation of actor‐
evaluation knowledge, and Figure 3 illustrates the data flow of finding primary actors step. Figure 4. Rule demonstration knowledge base for finding user goals. In defining use cases step, the tool uses the same name of the user goal to nominate the use case, and generates a simple definition for use case. Figure 5 illustrates the representation of defining‐
usecase knowledge‐base. If there is an actor, a, which has a user‐goal, ug, then generate fact that: UsesSystemTo (a, ug) 3
. EBP (elementary business process) is a term from
the business process engineering filed, defined as: a
task performed by one person in one place at one
time, in response to business event, which add
measurable business value and leaves the data in a
consistent state.
Figure 5. Rule demonstration knowledge base for defining use case. Finally, in modeling domain, the tool mixes the two techniques, mentioned early, in order to identify 23
ICGST-AIML Journal, Volume 12, Issue 1, July 2012
conceptual classes. Firstly, the tool uses NER technique to implement the second technique‐ identify noun phrases. The NER receives identified use‐cases and produces candidate conceptual classes. Then the tool uses knowledge base technique to implement the first technique‐ use conceptual class category list‐ to evaluate each candidate conceptual classes that produced by NER as shown in Figure 6. If there is a candidate class, c, which is physical, tangible object, specification, design, description, thing, place, transaction, roles of people, container of other thing, thing in container, other computer, electro‐mechanical system external to the system, abstract noun concept, organization, event, process, rule and policy, catalog, record of finance, work, contract, legal matter, financial instrument and service, manual, document, reference, paper, or book then generate fact that: ConceptualClass (a) Identified‐UseCase Figure 7. Rule demonstration knowledge base for conceptual classes’ evaluation. NER Candidate Conceptual Classes 5. The Tool and the Software NER As the wealth of software knowledge in the form of literature increases, there is a rising need for effective natural language processing tools to assist in organizing and retrieving this information. To that end, named entity recognition is an important first step for many of these larger information management goals. A particular category of software named entity recognizer can be: CLASS, USE CASE, DOMAIN MODEL, ATTRIBUTE, ASSOCIATION, etc. The tool plays an important role in the formation of software NER through the provision of its outcomes to software NER. In contrast, named entities are exchanged between the tool and proposed software NER as shown in Figure 8. Conceptual Classes Evaluation Conceptual Classes Figure 6. Identifying conceptual classes. Figure 7 shows the representation of conceptual classes’ evaluation knowledge‐base. Named entity recognition (NER) is a subtask of information extraction that seeks to locate and classify atomic elements in text into predefined categories such as the names of persons, organizations, locations, expression of times, monetary values, percentage, etc. Named Entity Recognition (NER) aims to extract and to classify rigid designators in text such as proper names, biological species, and temporal expressions. There has been growing interest in this field of research since the early 1990s [4]. The tool reuses the Parser and Name Finder tools of the OpenNLP. OpenNLP [8] [11] is a machine learning based toolkit for the processing of natural language text. It supports the most common NLP tasks, such as tokenization, sentence segmentation, part‐of‐speech tagging, named entity extraction, chunking, parsing, and coreference resolution. The Tool Software Named Entities Documents 4. The Tool’s NER Software NER Figure 8. The Tools and Software NER 6. Case Study: a Library System The paper presents a revised version of library system case study presented by Wilkinson [10]. The problem statement is: This application will support the operations of a technical library for a university department. This includes the searching for and lending of technical library materials, including books, videos, and technical journals. All library items have registration code. Each borrower can borrow up to 10 items. Each type of library item can be borrowed for a 24
ICGST-AIML Journal, Volume 12, Issue 1, July 2012
different period of time. If returned after their due date, the employee will be charged a fine, based on the type of item. In the following subsections, the paper applies the proposed tool step by step as describe in as described in sections 2‐3. 6.1 Choose the System Boundary For this case study, the Library System itself is the system under design; everything outside of it is outside the system boundary including employee, borrower, and so on. This indicates that a purpose of software development is exist. So, using Choose System Boundary’s domain‐specific knowledge base, the system boundary is a “Software. 6.2 Identify the Primary Actors and Their User Goals Using the OpenNLP tool, we underline all nouns and noun phrases in the problem statement: This application will support the operations of a technical library for a university department. This includes the searching for and lending of technical library materials, including books, videos, and technical journals. All library items have registration code. Each borrower can borrow up to 10 items. Each type of library item can be borrowed for a different period of time. If returned after their due date, the employee will be charged a fine, based on the type of item. Figure 10 shows partial parsing of the problem statement using the OpenNLP Parser Demo tool. The tool considers the underlined nouns are candidate primary actors (or, named entities) and subjects them to primary actor’s evaluation process. The evaluation process generated named entity “Employee” as primary actor because it has a user goal that fulfilled through using services of the Library system. Employee wants accurate, fast entry, and no borrowing errors, as bookshelf shortages are deducted from his/her salary. Using knowledge‐base of identifying user goals (which, investigating up the goal hierarchy :“What is the goal of that goal?”), the proposed Tool arrived at a mechanism‐independent goal: “handle a borrowing”. 6.3 Define Use Cases In defining use case step; “Handle Borrowing” is the name of the use case and the proposed Tool generated the following brief format for Handle Borrowing use case: Employee uses the system to handle a borrowing. 6.4 Modeling Domain In modeling domain step, by the proposed Tools extracting nouns from defined use cases‐ Handle Borrowing in this case, the proposed Tool generated “Employee” as a candidate conceptual class. User Problem Statement Use‐Case Modeler Use‐Case Models Use‐Case Models Software Named Entities
Software NER Use‐Cases Library Use‐Case Model Documentations Domain Models Domain Model Documentations Domain Modeler Domains Library Figure 9. The Tools Data Flow Diagram 7. Conclusion In software development process, requirements elicitation is difficult and, on the other hand, recognized as one of most critical software development activities. This is due to existence of a gap between users and requirements elicitation process introduced by a manual handling of their needs. In this paper, “and toward bridging that gap,” we discuss the ability of developing a fully automated scenario‐based requirements‐elicitation tool, aims to facilitate and improve requirements elicitation process. 25
ICGST-AIML Journal, Volume 12, Issue 1, July 2012
8. References
The proposed tool starts with modeling use cases, then models domains. In particular, the case study shows how the proposed tool helps users to model use cases and domain. The proposed tool has succeeded in automating most of its operations, while it partially failed in operations that their nature need for human judgment. For example, consider the automation of choose system boundary operation; the system boundary affects the identification of primary actors. In the case study; in addition to employee, is borrower a primary actor in the use case Handle Borrowing? Figure 9 shows the data flow diagram of the solution for the proposed tool. The answer depends on the system boundary of the system under design, and who developer is primarily designing system for. So, the operation requires human intervention from the developer to decide who primarily the system designing for, because it is not practical and inaccurate to extract this decision from problem statement. The failure and difficulty of automating such tasks is attributed to incomplete requirements and needs to natural language understanding (an immature research field that seeks to automate the task of information extraction from software development specification domain) when complete requirements are existed. So, we need to automate the task of Information Extraction (IE) from problem statements and software specifications (documents) in order to develop a fully automated requirement tools. [1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Figure 10. Partial Parsing for Problem Statement
[16]
26
Zetie F. Brooks. No Silver Bullet. IEEE Computer, 1987. Francis Chantree, Bashar Nuseibeh, Anne de Roeck, and Alistair Willis. Identifying Nocuous Ambiguities in Natural Language Requirements. In Proceedings of 14th IEEE International Requirements Engineering Conference (RE'06), Minneapolis, 2006. Larman, Craig. Applying UML and Patterns: An Introduction to Object‐Oriented Analysis and Design and the Unified Process. Prentice Hall, 2004. Nadeau, David. Semi‐Supervised Named Entity Recognition: Learning to Recognize 100 Entity Types with Little Supervision. PhD thesis, Ottawa University, 2007. Pressman, Roger S. Software Engineering: A Practitioner’s Approach. McGraw Hill, 2001. Sehlhorst, Scott. Writing Unambiguous Requirements. Tyner Blain, 2005. Sommerville, Ian. Software Engineering. Addison Wesley, 2001. Wilcock, Graham .Linguistic Processing Pipelines: Problems and Solutions. GSCL Workshop, Potsdam, Germany, 2009. Zetie, Carl. Forrester Research: research report, 2006. Wilkinson, N. Using CRC Cards, An Informal Approach to Object‐Oriented Development. New York, NY: SIGS Publication, 1995. SOURCEFORGE 2011. OpenNLP: Free Science & Engineering Software Downloads. [online] Available at: < http://sourceforge.net/projects/opennlp/> [Accessed 09 October 2012]. K. Pohl, P. Assenova, R. Doemges, P. Johannesson, N. Maiden, V. Plihon , J.R. Schmitt, and G. Spanoudakis, “Applying AI Techniques to Requirements Engineering: The NATURE Prototype,” ICSE – Workshop on Research Issues in the Intersection Between Software Engineering and Artificial Intelligence, Sorrento, Italy, May 1994. Wijers G.M.: Modeling Support in Information Systems Development, PhD Thesis, Thesis Publishers Amsterdam, 1991. PRESSMAN, ROGER S. Software Engineering: A Practitioner's Approach, 6th ed. McGraw‐Hill. 2005. Ian Sommerville. Artificial Intelligence and Systems Engineering, Prospects for Artificial Intelligence: Proceedings of AISB '93, 29 March‐2. Scott, W., and Cook, S. C. An Architecture for an Intelligent requirements Elicitation and Assessment Assistant. 13th Annual ICGST-AIML Journal, Volume 12, Issue 1, July 2012
[17]
[18]
International Symposium – INCOSE 2003, Crystal City, USA, July 1‐3. SOMΈ, S., DSSOULI, R., AND VAUCHER, J. 1995.Toward an Automation of Requirements Engineering Using Scenarios. Journal of Computing and Information 2, 1110‐1132. SOMMERVILE, I. Software Engineering, 9th ed. Addison‐Wesley. 2011. Dr. Moawia Elfaki Yahia received his PhD degree in Artificial Intelligence from Putra University, Malaysia in 1999. Currently, he is an Associate Professor of computer science at King Faisal University, Saudi Arabia. Dr. Yahia is working as a member of editorial board for many Int. Journal and member of program committee for many refereed conferences in computer science. He is a Member of ACM: Association for Computing Machinery, IEEE Computer Society, ACM SIG on Artificial Intelligence, ACM SIG on Knowledge Discovery in Data, Arabic Computer Society, and International Rough Sets Society. Dr. Yahia received TWAS award for Young Scientists in Developing Countries in 2006. He published over 25 articles in international journals and proceedings. Dr. Yahia was nominated for inclusion in Who's Who in the World, 28th Edition, 2011. His research interests are in: intelligent hybrid systems, expert systems, data mining, text mining, neural networks, rough set theory, and intelligent information retrieval. Biographies Azhari Gasmalla received his B.Sc. in computer sciences from International University of Africa, and M.Sc. in computer sciences from University of Khartoum. Now, he is PhD student at University of Khartoum and working at AlJouf University, in Saudi Arabia, as a head of computer and information sciences department at faculty of sciences and art. His research interests include information security, software analysis and design and information extraction. 27