SOFTWARE ARTIFACTS SPECIFICATION WITH UML

Transcription

1 SOFTWARE ARTIFACTS SPECIFICATION WITH UML Marcos Silva, Ricardo Bastos Informatics Faculty, Pontifical Catholic University of Rio Grande do Sul, Ipiranga Avenue, 6681, Porto Alegre, Brazil Toacy Oliveira School of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Kleinner Oliveira Department of Informatics, Pontifical Catholic University of Rio de Janeiro Marques de Sao Vicente Street, 225, Rio de Janeiro, Brazil Keywords: Abstract: Authoring, Software Artifacts, Software Development Process, Separated Content, Meta-modeling, UML Software Artifacts are key elements to software development processes as they ultimately gather all the information required to specify, develop and maintain a software-based system. It is important that software artifacts are handled on an environment that inhibits scattering and replication of information and foster organization and structuring. In this work we present our approach to Software Artifact Authoring based on UML models to better organize the specification of documents derived from software development processes, a guideline which provides steps for authoring help, and a prototype tool for automation and support. The approach uses the concept of meta-modeling to define two layers: Document and Process. The former allows the specification of artifacts in general while the latter focuses on software process documents exclusively. We also present the specification of some Unified Process artifacts to illustrate the approach using the prototype tool for a proof-of-concept evaluation. 1 INTRODUCTION Software Development Processes (SDP) prescribe how software systems are envisioned, built and maintained (Sommerville, 2004). In essence, SDPs define a set of activities and roles to manipulate documents, namely Software Artifacts (SA), which come in several flavors such as source code, diagrams and natural language specifications. SAs have great influence in the way software is developed and in the final running application given that they capture all the information that analysts, project managers, and other actors require when playing their roles (Fuggetta, 2000). Given the SAs need, typical SDPs instances devote a great deal of time authoring such artifacts. For example processes based on the Rational Unified Process (RUP) (Kruchten, 2000) may handle up to 108 different types of artifacts that can either be textual, source-code, image, and binaries. Although most artifacts are carefully specified they are typically handled by unrelated tools. For example, source code is authored with the help of Integrated Development Environments; diagrams are designed with CASE tools; and natural language textual specifications with Office tools, such as Microsoft Word TM. Each of these tools is extremely efficient but they have their own internal representation structure and even import/export operations are available, it s very hard to obtain an integrated view of the manipulated information. The lack of an integrated model to conventional artifact authoring approaches gives rise to three major problems: (i) Software Artifacts are poorly structured; (ii) Software Artifacts content and structure are difficult to reuse; and (iii) Software Artifacts evolution is not handled properly. In most SDPs such SAs are typically defined as monolithic and unstructured pieces of loosely coupled information (Tilley and Huang, 2002). These artifacts are mostly textual documents composed of nested sections, which may have titles to indicate the meaning of the associated content (Akpotsui et al., 1992). Manipulating unstructured artifacts poses a problem to SDPs because there is no associated data model (structure) to indicate intra or extra artifact dependencies and relationships among artifacts sections. As a result of poor structuring, sections can be inadvertently modified when adding, removing or altering pieces of information, based on the developers interpreta-

2 tion (Skene and Emmerich, 2006), what may dramatically increase the number of different artifacts exposing same information. The lack of proper underlying structure also poses another problem: software artifacts content and structure are hard to reuse wisely. The information tends to get scattered and repeated across several different artifacts leading to a difficult manipulation process. Reusing software artifacts does not mean just reusing template documents but also composing bits of information that are represented in a well structure repository system to create new perspectives of the same information or new ways to gathering them. The last issue is related to current version control approaches. The SAs evolution is typically controlled by a version control system, such as Concurrent Versioning System or Subversion, which treat SAs as a monolithic stream of text. As a result evolution is recorded as a set of changes in the text rather than a set of changes in a structured content. In such scenario it s very difficult to understand how artifacts have evolved and infer the impact of such evolution. The work presented in this paper aims at solving these problems. We have created a model (structure) to facilitate authoring Software Artifacts in an organized manner, thus paving the way to solve the reuse and evolution problems. We have used the concept of meta-modeling to create two abstraction layers which are based on two technologies, the Software Engineering Process Meta-model (SPEM) (Object Management Group, 2007c) and the Unified Modeling Language (UML) (Object Management Group, 2003). We chose those technologies as they are well integrated and provide mature infrastructure to software development. Thus, we have also developed a structured guideline based on the artifact authoring steps and a prototype tool which implements both meta-model and guideline. This work is structured as follows: Section 2 presents an overview of the model abstraction layers; the used guideline is explained in the Section 3; a sample of the approach test and use with a developed prototype tool is presented at the Sections 4 and 5; related work is in Section 6; and finally, some conclusions can be viewed in Section 7. 2 META-MODELING We have used the concept of meta-modeling to create layers of abstraction to better organize our approach and allow a seamless integration with the Software Engineering Process Meta-model (SPEM) and the Unified Modeling Language (UML). SPEM and UML are also specified using meta-models and some of their classes are used as underlying concepts present in our Software Artifact Meta-model. The layered meta-model fosters the definition of self-contained layers, which are stacked to represent more specialized and increase the expression power. As a side effect a layered meta-model also promotes information reuse given that more specialized layers are instances (re-uses) of less specialized ones. We have defined two layers for our meta-model: the Artifact Layer and the Process Layer. The Artifact Layer is represented in Figure 1 as the M2 Metamodel and it is the less specialized one in our work. The Process Layer, or M1 Concept Model, specifies the basic elements to create SAs. For example, in Figure 1, M2 exemplify the specification of the metaclass Artifact that has a collection of instances of the meta-class Information that can be of type Text, Image or List 1. Figure 1: Artifact Authoring Layers Figure 1 also illustrates the Process Layer represented as the M1 Model. The Process Layer specializes the Artifact Layer, i.e. the elements in M1 are instances of elements from M2 Meta-model. M1 adds process specific semantic to M2 that is required to specified the artifacts present in a SDP. For instance, the Unified Process defines a Vision Document as a collection of Stakeholders and Requirements. In M1, the class Vision has a collection of instances from classes Requirement and Stakeholder, which further detail the structure to define a requirement and a sta- 1 These classes are illustrative. The real M2 model has over 100 classes to organize artifacts among sections, types of information, reuse and versioning

3 keholder respectively. The Artifact and Process models are of no use without a real software artifact containing concrete information. For that reason Figure 1 brings the M0 Layer, which is the Project Layer, to represent the instances of the artifacts that are specified in layer M1 and are present on the running project. Using the M1 Vision class, one can say that a valid instance would be an artifact V that has two stakeholders, John Doe and Paul Doe, and two requirements, Pay with Debit Card and Print Receipt : Vision V=(Stakeholder= John Doe ; Stakeholder= Paul Doe ; Requirement= Pay with Debit ; Requirement= Print Receipt ). Using the Software Artifact Meta-model requires understanding the difference between a SDP and a Software Development Project, or just Project. A SDP defines the activities, roles and artifacts that are used during the project. One can argue that project is an enactment of a SDP, where real people, namely Software Engineers, perform the prescribed activities and fill the artifacts with actual data. Therefore Software Engineers that are executing the software development project typically use the M0 layer. On the other hand, M1 defines the artifacts structures and should not be modified by regular software engineers during a project but by those in charge of defining the software process that fits a starting project needs. Modifying M1 elements is called Software Process Tailoring (Pereira et al., 2008). A major task for Process Tailoring is to customize a given software process to capture the information that is important to create the system under and requires knowledge about the current organization and personnel. M2 is the less specialized layer and it is supposed to be used by tool vendors when creating software applications that facilitate the manipulation of M2 and M1 instances. M1 and M2 contain classes that should be instantiated by M0 or M1 elements respectively, but creating such instances with a diagram can be daunting. For that reason our approach brings the Software Artifact Modeling Tool which uses M2 classes to specify process artifacts with forms. M3 is the MOF (Object Management Group, 2006) layer. It is supposed that every meta-model is defined by MOF capabilities, thus, the M2 layer instantiates the M3 layer meta-classes. In Figure 1 there is an extra meta-class VersionedExtent which is part of the MOF Versioning and Development Life-Cycle Specification (Object Management Group, 2007a), giving new capabilities such as version control. 3 THE AUTHORING GUIDELINE Analyzing software engineering related approaches we did not find any agreement about the activities, steps or any particularities inherent of process or artifact authoring. There are not descriptions or even drafts which give some solution about it. Thus, aiming to provide a better idea about how to proceed an authoring, we have developed a guideline with a set of steps to follow with. First we have considered a body of work with the intention of making a survey of the basic requirements for the process authoring. Second we have observed that artifact authoring is a minor part of the process authoring, nevertheless, one of the most important, in that case, we focuses on artifact authoring. Third we have realized the activities about artifact construction, involving defining in a generic method library and using this artifact in to a specific process structure. Fourth, and finally, we have built a link between these two concepts and have added activities allowing artifact publication. Our approach is based on the separation of content (definition) and structure (use) as stated at (Object Management Group, 2007c). This concept defines that there should be a library of generic elements derived from the analysis of the interesting processes and other library with the structure of a particular process, able to use the library with the generic elements already defined. In Figure 2 is presented a diagram with the activities for the entire artifact authoring. In (A) we have the decision about among the initial flow for (i) Process Authoring, (ii) Process Tailoring or (iii) Process Enactment, based on SDP Life-Cycle. Once the focus of this work is about software authoring, we have chosen Process Authoring instead the others two. Thus in (B) we have the four activities for artifact authoring: Defines the Library: it puts together the activities that are responsible for defining a library of configuration. This library will be able to create the contents and structure of a SDP. Creates a Method Content: it puts together the activities that are responsible for defining content. Hence, it is possible to use the content defined previously in other to build a family of SDPs. Creates the Process Structure: it puts together the activities that are responsible for defining a structure of a SDP. This structure specifies how should be the use of the Method Content. Publish: in this high-level activity, we can find the activities that are related to publish the SDP.

4 4 AUTHORING TOOL - SWAT For the purpose of automating and putting our approach in practice, it was developed a tool of software artifact authoring, named Software Artifact Authoring Tool (SwAT). Along with it has been made an evaluation of this work modeling some real artifacts. Examples of use, tests, source code and details about the approach are available in: The SwAT prototype architecture is divided in to functional layers and it is depicted in Figure 3 Eclipse Project SwAT Java Development Tools (JDT) Eclipse Platform Workbench Help Jface SWT Team Interface Gráfica Eclipse Edit Eclipse Editor Model Model Impl Model Meta Model Plugin Development Environment (PDE) Workspace Debug Platform Runtime EMF ECORE Validation Framework Teneo Model Query Meta Meta Model Figure 3: Architecture of SwAT Tool Figure 2: Software Artifact Authoring Guideline The Figure 2 also shows the produced activity products, as well as the responsible roles for each previous activity: Configurer: actor of this role should be responsible for configuring the process authoring environment as whole. Thus, it will produce the library artifact (Spemxt Library) and prepare to receive data from the next activities. At present, Spemxt Library finds itself null regarding the software development process. Knowledge Engineer: the actor of this role is responsible for creating reusable content by the process, defining elements such as roles, activities, and artifacts. The produced content will entry in the Spemxt Library. Process Engineer: it should be not only responsible for creating the structure of the process, reusing the produced elements by the knowledge engineer, but also it should be able to combine the existing elements into the content to create a process that may be domain specific. All produced structure as well as the relationships were created to use the elements of the content will get into the Spemxt Library. Besides the Process Engineer should publish the SDP. The plug-in Infrastructure Layer is based on the Eclipse Project 2, which consists in a Rich Client Platform API for the plug-in basic functionalities. The modeling Infrastructure Layer is based on the Eclipse Modeling Framework (Eclipse, 2008). It provides also reusable infrastructure functionalities such as: persistence in XMI, validation of model integrity and management of data using transaction. The Model Layer implements the proposed metamodel. All implementation was made in Java. Thus, in this layer are the contract and constraints made from the Java Interfaces. The prototype graphical user interface (GUI) is based on the concepts of Views, Perspectives e Wizards as defined in the Eclipse Platform. SwAT tool is an Eclipse Plug-in. 4.1 Functionalities The main tool s functionalities are in the packages: Artifact Authoring - it has functionalities related to authoring of ASs. It permits the creation of constructs defined in the extension of SPEM v2. Process Authoring - it has functionalities related to authoring of SDPs. It permits the creation of process constructs already defined in the SPEM v2 e redefined in this work. Authoring Configuration - it has functionalities related to configuration of authoring process. It 2

5 permits a creation of packages of libraries, separating the content of the process itself. 4.2 Prototype Limitations and Scope Once the Knowledge Engineer should build the definition of the software artifacts to guide it to a correct setup of the Method Content and, a the same time, the Process Engineer should be able to use the library built from the Engineer Knowledge, mounting the Process Structure, we have developed a tool which helps the Software Artifact Authoring. Due to the tool foundation, the prototype gives functionalities for process authoring as well, since we have based our approach on the SPEM meta-model, going beyond the artifact authoring. However, this paper is aimed at artifact authoring. In this context, the prototype is limited to: (i) artifacts authoring, using the, using the principles of separation of content (Method Content) and structure (Process Structure); (ii) identify and check problems that arise during the authorship, like checking integrity and fields; and (iii) model import, load and save for data exchange. 5 APPROACH EVALUATION The approach evaluation consists in to model artifacts using the Software Artifact Meta-model and the Artifact Authoring Guideline. Conceptually, we claim to give a proof-of-concept modeling real artifacts from a real SDP using our approach with the SwAT prototype. However, due to the paper space, we only present the artifact modeling for some RUP artifacts, from different disciplines: Business Glossary; Glossary; Use-Case Specification; Analysis Model; and Design Model. As defined at the Guideline (Section 3), we first need to select to create a new Process for SDP authoring. Second, we must create a new library, creating a new model. Third, we create the Method Content for the process and fourth we can add the Process Structure. Since we have used the SwAT Prototype the guideline following is automated. Because we have selected real RUP artifacts, it has been necessary to map each one from its concept to the model. Thus we have paid attention to the artifacts structure using information types and containers where applicable. Figure 4 brings an illustration of the M1 Model for the Unified Process Use-Case Specification artifact. In order to better expose the model we have organized it in columns with the corresponding M2 meta-classes on the top and the M1 instances bellow. For example the Class FlowOfEvents in the second column (from left to right) indicates it is an instance on the meta-class ContainerDefinition. It s also important to notice the first column on the left. It has a snapshot of the real Use-Case Specification artifact, where it s possible to observe the title of sections that build the document. In the following paragraphs we describe the rationale and the design elements used to specify the Use-Case Specification artifact: Use-Case Specification, it is an artifact and therefore it has been modeled as instance of the meta-class ArtifactDefinition; the sections of the artifact have been modeled as instances of the ContainerDefinition and are in the column defined by this meta-class; 1. the classes which represent lists of bespoke information have been modeled with the List meta-class (in the List column); 2. the classes Flow, Requirement, Condition, Extension Point, Use-Case and Actor are instances of meta-class Group; 3. the internal information about name and description, from Use-Case and Actor, are text type and instances of Text meta-class. Figure 4 also illustrates relationships that are denoted by five types of connecting lines, which are instances of different M2 meta-classes: 1. the relationship between the artifact Use-Case Specification with and its sections (or containers) is an instance of ArtifactContainer Relatioinship, represented as dash dot dot lines. 2. the relationship between artifact and Use-Case is an instance of ArtifactFragment Relationship meta-class, since Use-Case is an instance of the information type Group. This relationship is represented as a dashed line; 3. the relationships among containers, represented as sections, and theirs information must use instances of the ContainerFragment Relationship meta-class. These kinds of relationships are represented as solid lines; 4. the relationship between Flow of Events and Alternative Flows is an instance of the ContainerDefinition Relationship and it is expressed as a solid line with a hollow diamond; 5. finally, the relationship between Group or List with others information types are made by instances of the auto composed relationship. Such relationship has been modeled because once lists and groups perform as organizers, it has

6 Figure 4: An Artifact Modeling Concept Sample been important to allow their association with other information types. These kinds of relationship are expressed using the solid line with a black diamond; In the Figure 5 is presented the M1 layer modeled using the SwAT prototype. This model contains the artifacts (at E), theirs containers (at D) and information types (at A, B e C), and at last the relationships (at F, G e H). The table in Figure 5 shows each artifact with its used information type and the relationship. The containers (at D) have been modeled to supply the Use-Case Specification artifact, but excepting the section Introduction which has two other containers, References and Definitions, Acronyms and Abbreviations as subsections, which are shared. The information types have been grouped in three information packages: 1. the first package (at (A), at the left, from top to down) has the information types for the artifacts Business Glossary and Glossary, such as Abbreviation, Acronym, Definitions and Term - instances of the meta-class LabeledText for labeled texts. Ex.: Abbreviation=(label: Doctor, value: Doc.); 2. the second package (at (B)) has the information types for the artifacts Analysis Model and Design Model, such as Use-Case Analysis and Design - instances of the meta-class BehaviorDiagram which represents a UML Behavior Diagram; 3. the last package (at (C)) has the information types for the Use-Case Specification which has already been presented in Figure 4. The Process Structure has been done using the Method Content previously defined. Thus, it is possible to use the artifacts and theirs information types to model a specific SDP structure. In our approach, we have selected to model the RUP process, adding the artifacts and tracing them with the defined artifacts of the Method Content. In such case, it is possible to realize the information structure and content reuse, once we share the information instead of copy-and-past them. The creation of libraries has given some foundation to Method Content or Process Structure reuse, once we can adapt or share the entire library. The version control mechanism presented by MOF Versioning takes care about the M1 and M2 layers elements. Therefore we can define several versions of the Method Content, aligned with several versions of Process Structure, and both aligned with a version of the meta-model. 6 RELATED WORK There is few related work to Software Artifact Authoring. In fact we managed to find works for document management, document structuring and document classification but none that leveraged the peculiarities of artifacts derived from software process. (A) - In a mathematical study for editing document systems (Akpotsui et al., 1992) have considered documents as logical structures, made up of elements such as title, section, paragraph, and composed into a logical structure. These documents could be viewed

7 Figure 5: Sample of the Artifact Authoring Evaluation into a tree structure and each element had a type and the relationships amongst them define a generic document model structure. (B) and (D) - In literature, some authors have researched about works in document composition, also now as Compound Documents (Network, 2008). One of these words is the HotDoc Framework (Buchner, 2000) - (B). The authors have supposed that Hot- Doc gave more functions to authoring documents, allowing the combination of different parts of the document by an author. (Herzner and Hocevar, 1991) - (D) - have suggested the creation of the CDAM. It is another work about document composition. (C) - Labyrinth (Cattaneo et al., 2000) is a web document management system based on a semantic model to enhance the web document management capabilities guaranteeing scalability, integrability, web interface with a repository. It is described through entity-relationship model but the authors have considered object-oriented approach as an evolution. (E) and (G) - Research about document categories and types could be also found. According to (Laitinen, 1992) - (E), it has been important to know how to control and to manage every artifact in a uniform way. The authors have suggested an approach to classify documents, providing identification about the kind of document information giving a nomenclature. As stated in (Visconti and Cook, 1993) - (G), in the industrial environment was detected that about 20% of maintenance problems occurred because the lack of good documentation. The authors approach has indentified a way to improve the process documentation defining four maturity levels. (F) - (Tilley and Müller, 1991) suggests that at the programmer s perspective, revising full source-code to check correctness of the comments is a repetitive and mechanical task. Therefore, the authors have created INFO, a hypertext facility which has allowed document annotations in a non-intrusive way. 6.1 Comparisons In our analysis we have compared these approaches in terms of: (i) language, using attributes related to language description and construction which consists on: Static Semantic (1), Dynamic Semantic (2), Abstract Definition (3), Concrete Definition (4), and Language Rules (5). These attributes are better described in (Object Management Group, 2007b); (ii) artifact authoring: used paradigm (6) and the artifacts types (7); and (iii) using and test: approach use, tests or implementation (8) and tool (9). The Table 1 shows the analysis for related work in comparison with our one. As can be viewed, from the seven approaches only one has complete semantic meaning descriptions, three have only dynamic semantic and the rest does not have any semantic description. The abstract and concrete descriptions are supplied only by one approach, without any specified rule. In terms of paradigm, four approaches use logically structured one, but only one has the scope for artifacts.

8 Table 1: Comparison among related approaches. Language Authoring Test Work A x x x x doc B x x doc x x C x x x art x x D x x doc x x E x doc x F x code x x G x x x doc SwAT x x x x x x art x x Therefore, our approach pays attention to these attributes, authoring structured SAs with the use of a meta-model and a guideline, using a tool as a support. 7 CONCLUSIONS This work presented an approach to Software Artifact Authoring. Software artifacts play a central role in software development process, gathering the required information to specify, develop and maintain a software-based system. We have developed a Software Artifact Meta-model that allows the definition of software artifacts, an Authoring Guideline which provides steps to be followed to author of artifacts, and the Software Artifact Authoring Tool, which implements our approach. We believe that using our Software Artifact Metamodel prevents document for being monolithic structures that do not share a well-defined structure. Moreover, our approach allows the definition of artifacts that are well coordinated with the Software and System Process Meta-model and the Unified Modeling Language, which allows a seamless integration with current approach to software process tailoring. Although our work enhances current approaches to software artifact specification, we believe there is room for improvements. For example, artifacts are specified as a collection of classes and relationships but not constraints. There is a need to specify such types of structure which do not fit well together and this can be accomplished with the use of the Object Constraint Language (OCL). REFERENCES Akpotsui, E., Quint, V., and Roisin, C. (1992). Type modelling for document transformation in structured editing systems. Mathematical and Computer Programming, Special Issue devoted to the 1992 Workshop on Principles documents. Buchner, J. (2000). Hotdoc: a framework for compound documents. ACM Comput. Surv., 32:Article No. 33. Cattaneo, F., Nitto, E. D., Fuggetta, A., Lavazza, L., and Valetto, G. (2000). Managing software artifacts on the web with labyrinth. In ICSE 00, pages , New York, NY, USA. ACM. Eclipse, I. (2008). Eclipse modeling framework project (emf). Fuggetta, A. (2000). Software process: a roadmap. In ICSE 00, pages 25 34, New York, NY, USA. ACM. Herzner, W. and Hocevar, E. (1991). Cdam compound document access and management: an object-oriented approach. SIGOIS Bull., 12(1):1 18. Kruchten, P. (2000). The Rational Unified Process: An Introduction, Second Edition. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Laitinen, K. (1992). Document classification for software quality systems. SIGSOFT Softw. Eng. Notes, 17(4): Network, M. D. (2008). Compound documents. Object Management Group (2003). Unified modeling language specification v Object Management Group (2006). Meta object facility v Object Management Group (2007a). Meta-object facility versioning and development lifecycle specification v Object Management Group (2007b). Omg unified modeling language (omg uml), infrastructure, v Object Management Group (2007c). Software & systems process engineering metamodel specification Pereira, E., Bastos, R., and Oliveira, T. (2008). Process tailoring based on well-formedness rules. In SEKE 08. Skene, J. and Emmerich, W. (2006). Specifications, not meta-models. In GaMMa 06, pages 47 54, New York, NY, USA. ACM. Sommerville, I. (2004). Software Engineering (7th Edition). Pearson Addison Wesley. Tilley, S. and Huang, S. (2002). Documenting software systems with views iii: towards a task-oriented classification of program visualization techniques. In SIGDOC 02, pages , New York, NY, USA. ACM. Tilley, S. and Müller, H. (1991). Info: a simple document annotation facility. In SIGDOC 91, pages 30 36, New York, NY, USA. ACM. Visconti, M. and Cook, C. (1993). Software system documentation process maturity model. In CSC 93, pages , New York, NY, USA. ACM.