Reverse Engineering Methodology to Recover the Design Artifacts: A Case Study
|
|
- Alicia Sutton
- 7 years ago
- Views:
Transcription
1 Reverse Engineering Methodology to Recover the Design Artifacts: A Case Study Nadim Asif School of Computing, IES, Leeds Metropolitan University Beckett Park Campus, Leeds LS6 3QS, UK. N.Asif@lmu.ac.uk Abstract As a software system evolves, new features are added and obsolete are removed, the design artifacts gradually diverge from its original design. Many approaches for design recovery or reverse engineering has been suggested, most with some type of support tool. Since a project's time constraints may prohibit use of sophisticated techniques and/or tools due to the learning curves associated with the techniques and tools, methods that can be applied in lieu of complex support tools may be required. Reverse engineering produces a high-level representation of a software system from a low-level one. This paper describes a case study, which use the methodology for reverse engineering that recovers the design artifacts of a software system from its source code and related documentation. The methodology consists of five phases, which can be attempted at different levels of abstraction according to the task at hand to recover the design artifacts. The methodology also makes use of tools, approaches and representations typically found in the forward software development process. Key Words: Reverse Engineering, Design Recovery, Software Understanding and Maintenance. 1. Introduction The useful software systems continuously evolve [1]. As they evolve, so too do their designs. New modules and dependencies are added to support new features, while obsolete functionality is removed. Consequently, the design gradually diverges from its original design. Different design artifacts become inconsistent with the current implementations, making maintenance tasks difficult and error prone. Software maintenance of large systems depends on several factors including the existence of accurate documentation of the system design. In some cases, software and documentation fail to be consistent in that the documentation, and subsequently the design, is rarely updated to reflect modifications made to the system. In other cases the original system design does not have any type of existing documentation and, as such, any rationale behind the design decisions made during the implementation of the system are lost. In either case, lack of a consistent design has many impacts on the effectiveness of any efforts to maintain and modify existing systems. Reverse engineering is a crucial part of software maintenance and a maintainer needs to understand the code before attempting any modification. Reverse engineering is the process of creating higher-level of abstraction from source code and available documentation [2]. Reverse engineering can be used for a variety of purposes: to reconstruct or improve documentation; to facilitate software maintenance or conversion activities; or to redesign and re-engineer an existing system. Unfortunately, source code does not contain much of the design information and additional information sources are required. Usually the scale of the software is often large, the maintainer also needs some automated support for the understanding and the recovery of the design artifacts. The design information from a combination of code, existing design documentation (if available), and general knowledge about problem and application domain is required to recover the design artifacts. This paper first briefly summarizes the reverse engineering abstraction levels and important concepts necessary to understand the process. After that, it describe a methodology in which human and computer interact to recover the design artifacts, which is followed by a review of the experience in using this process for the case study. 2. Background This section gives background information in the area of reverse engineering abstraction, system artifacts and the Reverse Engineering Abstraction Methodology (REAM) [5] used in the case study to recover the design artifacts.
2 2.1 Abstraction Levels An abstraction for a software artifact is a succinct description that suppresses the details that are unimportant to software developer and emphasizes the information that is important. For example, the abstraction provided by high level programming language allows a programmer to construct the algorithms without having to worry about the details of hardware register allocation. Software typically consists of several layers of abstraction built on top of raw hardware; the lowest-level software abstraction is object code, or machine code. Implementation is a common terminology for the lowest level of detail in an abstraction. When abstraction is applied to computer programming, program behavior is emphasized and implementation details are suppressed. The knowledge of a software product at various levels of abstraction undoubtedly underlies operations regarding the maintenance and reuses the existing software components. It is, therefore natural that there is a steadying growing interest in reverse engineering, as a capable of extracting information and documents from a software product to present in higher levels of abstraction than that of code. The abstraction as the process of ignoring certain details in order to simplify the problem and so facilitates the specification, design and implementation of a system to proceed in step-wise fashion. In the context of software maintenance [3], four levels of reverse engineering abstraction are defined: implementation abstraction, structural abstraction, functional abstraction and domain abstraction. Implementation abstraction is a lowest level of abstraction and at this level the abstraction of the knowledge of the language in which the system is written, the syntax and semantics of language and the hierarchy of system components (program or module tree) rather then data structures and algorithms is abstracted. Structural abstraction level is a further abstraction of system components (program or modules) to extract the program structures, how the components are related and control to each other. Functional abstraction level is a higher abstraction level, it usually achieve by further abstraction of components or sub-components (programs or modules or class) to reveal the relations and logic, which perform certain tasks. Domain Abstraction further abstracts the functions by replacing its algorithmic nature with concepts and specific to the application domain. 2.2 System Artifacts Five levels of abstraction that scope the system artifacts are Requirements, Features, Architecture, Design and Implementation [4]. Since reverse engineering itself is a process requiring abstraction at different levels [2], the system artifacts should be constrained to five levels of abstraction. A distinction between the problem and solution domains has to be model. There are two ways to view software systems functionality. From the perspective of the user, the requirements of the system are specified in the problem domain. The problem domain outlines what the system is supposed to do. From the perspective of a developer, the system can be viewed in the solution domain, which specifies how the system achieves the tasks specified in the problem domain. The user requirements represent the highest level of abstraction at which the system can be represented. The functionality is expressed at a fine grain level without any emphasis whatsoever on the implementation dependent details. The software system is expected to satisfy the requirements specified. The requirement specification document is typically the product of a system analyst s interactions with the potential users and system experts, resulting in a text document supported by figures and diagrams. The features bridge the gap between the artifacts that are being developed and the requirements specified. The architecture of a system specifies how the artifacts of the system combine together to implement the desired functionality. The internal design and implementation of the system artifacts are the elements of the design layer of abstraction. The design only goes to show the functional decisions made while building the system, which usually resides in the minds of the developers and is rarely conveyed in any form. Design entities like classes, structures, and user-defined data types etc. are modeled in this layer of abstraction. Implementation is the lowest level of abstraction and constitutes those artifacts that implement the functionality of the system. It is done using a programming language and is usually rich details. Typically source files, directories and file systems make up the implementation layer. 2.3 Methodology The Reverse Engineering Abstraction Methodology (REAM) is aimed at assisting the activities of reverse engineering to recover the design of the software at different levels of abstraction. The methodology consists of (five phases) high level model, functional model, architectural model, source code model and mapping model. The figure I contains a graphical depiction of a REAM [5]. REAM help engineers perform various software engineering tasks by exploiting the high-level, functional, architectural, source code and mapping models to recover the design artifacts. The goal of this iterative approach is to enable
3 a software engineer to produce, within a time constraints of the task being performed, a high-level, functional, architectural, source code and mapping model that is suitable to use for recovering the design artifacts and reasoning about the tasks at hand. An engineer can interprets the models, as necessary, modifies the high-level model, functional model, architectural model, source code model, or mapping model to iteratively to recover and reasons about the systems artifacts. correspond to existing high-level models in the recovery process. The approach used to perform the case study described is based on a combined top-down and bottom-up approach to recover the design artifacts. Recent investigations have shown that this kind of approach is reasonable and appropriate by considering the time constraints and task in hand [6]. In order to facilitate the recovery of design artifacts from the existing system, system analysis and design (SA/SD) and UML is used to communicate the understanding and recover the design artifacts at each HIGH LEVEL MODEL FUNCTIONAL MODEL MAPPING DESIGN ARTIFACTS ARCHITECTURAL MODEL SOURCE CODE MODEL Figure I 3. Process Overview In the context of the Reverse Engineering Abstraction Methodology (REAM) [5], the diagram shown in figure II depicts the process that described in this paper. Specifically, this paper describes the approach and a case study that involved five distinct models of abstraction to recover the design artifacts. Each phase of the process is encapsulated in a box, artifact(s) in the process in rectangles, and activities in square. 3.1 Multi-level Abstraction Approach to Recover the Design Artifacts Several techniques have been suggested for recovering the design artifacts from the existing systems. These techniques range from formal approach [9] to semiformal functional abstraction [10] and structural abstraction [6]. The representations constructed by these techniques are often biased by the implementations, and as such, do not always (High-Level, Functional, Architectural, Source Code and Mapping) model. First High-Level model for the system is developed from the available documentation (documents, system knowledge) and experience and refined based on empirical investigations involving the existing system. Second, Source Code model (such as call graph) is constructed by using the third party tools. A prototype of a Design Recovery Tool (DRT) was developed during this research, the tool consists of several C++ programs, a user interface implemented in Visual Basic 6.0, and links to AT&T Graphviz package (Dotty) to view the particular artifacts. In the next step, the functional model is developed by using the high-level model and source code model. The mapping model between the two models is also defined to explore and build the functional model (relationship between high-level and source code model) to recover the design artifacts. At this stage an abstract understanding of the functions that the system performs is developed. It can consist of an analysis of the system's input/output behavior expressed in terms
4 High Level Model Functional Model Doc. System Knowledge Doc. Goals Func. Develop Develop Goals Sys. Summary Use Case Desc. UseCaseDiagram Mapping Model Design Artifacts Mapping Source Code Model Architectural Model Doc. S. Code CASE Tools Doc. CASE Tools Extract Abstract Class Diagram Code Doc. Component Diagram Arch. Desc. Figure II of nested data flow diagrams or it may be a Use Case diagram in UML, documents the functional features of the system. This help to understand some of the reasons driving the design decisions made by the developers of the software. The Architectural model is extracted from the understanding and the artifacts developed by (High- Level, Functional, Source Code and Mapping) models. The architectural description is extracted through out the length of the project. This provided a detail view of the system. The component and package diagram of UML is used to convey the information about the architecture of the system. Once the models are developed at the different levels of abstraction described above, it is important to correlate them to verify and glean away any discrepancies. Another useful exercise would be to try to map the feature description to the source and architectural models, which would make the abstractions completely connected among each other. Re-documentation of the models increase the comprehension about the system and also offer scope for improving the models before they are released. The result of this phase of the process is the reverse engineered documentation, which can then be utilized. Generally, the user iteratively computes and investigate successive mapping model until acquires enough information for the task being performed. 4. Case Study In this section we demonstrate how our approach supports to recover the design artifacts by applying it on the Mozilla [7]. Early in 1998, Netscape announced to the world that it would provide the source code for Netscape communicator freely to the internet community and that this free revision of communicator would be known as Mozilla. In the first phase the high-level model was developed from the available
5 documents and experience. From these available sources the functional description of the system was also developed and it started with a short summary of the overall system behavior. The Unified Modeling Language (UML) was selected to visualize and communicate the software system design. Due to space constraints, the recovered design artifacts are not included in the case study. The core functionality of Mozilla revolves around XUL (XML-based user interface language). XUL is an XML-based language for describing the layout and component of user interfaces and also use C++, Java Script and HTML. XUL is used to describe windows and their contents with application windows, such as the Mozilla browser window. Actually XUL is used to define every aspect of the windows user interface, from its menus to its toolbars to its status bars. The user interface is configurable through markup, it is not hard coded in the source, basically it is loaded at runtime enabling programmers to tweak the interface without having to recompile the source code. XUL makes the user interface dynamically configurable. Interactions and events related to the user interface flow through Java Script and are handled either in source code or in a script. More options normally specify command handlers, which flow through Java Script to C++ and from C++ the handlers may drop through directly to C. The HTML is used to describe the contents of a document and XUL markup is used to describe the contents of an active window, which can include multiple HTML documents. HTML, XML & XUL achieve flexibility through an object model called DOM. Interfaces into the DOM are defined in Interface Definition Language (IDL). These interfaces serve as the glue between Java Script and C/C++ source code. In the second phase the source code model was extracted and the process is depicted in Figure II. A prototype of Design Recovery Tool was used to extract the developer s documentation, functions, classes and flow of control from the source code. The developer s documentation provided knowledge about the components that implement the structure of the application. Several modules of the source were documented, and debugging the source was also important method used to extract the model as an abstraction. Debugging was also found to be the best method of understanding the program flow and extract the reference formats (reports, menu, and interfaces). These documents were scanned thoroughly for clues about the critical modules in the application. In the third phase a good understanding about the functional aspects of the application was developed. The Use Case description was built for the system from the available documents and by building a Use Case diagram at the system level and by providing fine grain Use Case diagram wherever necessary. Each Use Case was documented textually to provide more understanding about its functionality. It was revealed that application core implements the core functionality for application components and application services process XUL. C/C++ source code serves as the basis for an object class, which defines core functionality and services. Application Services are implemented by Application Runnrer (nsapprunner) and Application shell (nsappshell). Application Runner loads an XUL file and an application core hook them together through the applications shell. The main function main( ) of Mapping of nsiapprunner to Source Code Figure III
6 AppRunner sets up the application shell and handles tasks for initializing the shell, running the shell, and shutting down the shell. AppShell provides key services for the applications shell and XUL as well as controllers for widgets and windows callbacks. These features are implemented through nsappshellservices, nscommandlineservices, nswebshellwindow, and nsxulcommand Application shell provide services and hooks, it does not provide the core functionality for user interfaces. The application cores for the browser and editor components are defined in nsbrowserappcore and nseditorappcore respectively. The nsbrowsermain instantiate main and sets up the console and browser windows, nsbrowserwindow creates browser windows and nsxpbasewindow handles core windowing tasks. It is noted that many applications cores can be instantiated from nsappcore. These application cores provide the core functionality for the browser, mail and editor components. In the next phase the mapping process was performed to map the high-level and functional model to the source code model to consolidate all the models. All the models were reviewed again in the light of the goals specified during the start of the study. The class nsiapprunner is mapped to the source code files is depicted in figure III. The recovered class CHTMLToken relationship with the source files is depicted in figure IV. During this phase many additional relationships and corrections were made to the constructed models. Class CHTMLToken Relationship with Source Files Figure IV In the next phase the Architecture Model was abstracted and the process is depicted in figure II. Abstracting the architectural description was an ongoing process throughout the project. The static architecture of the system artifacts was identified in the beginning, and incremental changes were made as more information was learnt. However Component diagrams were built in UML and the relationships among the components were visually represented by a dependency relationship between them. This graphical view effort made possible to understand the architectural layout of the software. The end result of this study project was one coherent UML model that correlates all the knowledge HTML/CSS/JavaScript Layout/XUL - Interface Java Script - Event / Command Application Services Application Core Architecture Figure V gained at different levels of abstraction. The abstraction levels found very useful for the purpose of hiding the real complexity of the details (source code, textual descriptions, reference formats). It showed that few graphical descriptions can greatly reduced the effort in trying to comprehend the relationships and interaction among the different artifacts (source code, developers documents, reference formats). It helps to limit the scope of exploration, and enables to work without getting lost in the complex code. 5. Evaluation Table I list the application modules that were analyzed and their total size in line of code (LOC), including program files and header files. The proposed approach and tool have been evaluated by using two well known metrics of the information retrieval [8], related in particular to the retrieval effectiveness: recall and precision. Recall is the ratio of relevant documents retrieved for a given query over the number of relevant documents for that query in the database. Precision is the ratio of the number of relevant documents retrieved over the total number of documents retrieved. In fact recovery process can be seen as the retrieval, or even classification, of design artifacts present in the source code and the other related documents. Mozilla CPP C H Total LOC db xpfe editor HTML Parser Table I
7 The identification of the relevant artifacts and the validation of relevant retrieved artifacts have been done manually. Table II and III summarize an example data of db (functions). db(functions) Relevant Irrelevant Total Retrieved Table II Relevant and Irrelevant Retrieved functions db(functions) Retrieved Missed Total Relevant Table III Retrieved and Missed Relevant functions Therefore, the Recall and Precision measures are: Recall = # (Relevant ^ Retrieved ) % # Retrieved = 115/161 % = 71.43% Precision = # (Relevant ^ Retrieved ) % # Relevant = 115/115 = 100% This means the misclassification, that is the ratio between the number of irrelevant retrieved artifacts and the number of retrieved artifacts is 28.57%. 6. Conclusion The methodology permits the user to develop highlevel, functional, architectural, source code and mapping models to recover the design artifacts at different levels of abstractions by exploiting various types of information (like available documents, experience and source code). The approach not only providing a choice to derive the high level model from the source code model but it also provide the approach to develop and abstract the high-level model, functional model and architectural model from the source code model and available sources (like documents and domain knowledge), and correlate them at different levels of abstraction. The methodology is lightweight and iterative and can be used according to the tasks in hand at different levels of abstraction. The methodology also demonstrate that, high-level, functional, architectural and mapping models can be beneficial for planning, assessing, and executing tasks on an existing system to recover and abstract the design artifacts. Future work consists of using the methodology for building the new tools for process automation, and the refinement in the methodology based on the experiments. 7. Acknowledgements The Author would like to thank the Pat Allen, Janet Finlay and Mark Dixon for their comments on this paper. 8. References [1] M.M Lehman, L.A Belady," Program Evolution - Processes of Software Change", Academic Press, London, [2] Elliot J. Chikofsky and James H. Cross II, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software, vol. 7, no. 1, January [3] M.Harandi and J.Ning, Knowledge-Based Program Analysis, IEEE Software, 7(1), [4] C. Riva, Reverse Architecting: An Industrial Experience Report, IEEE Proceedings of Working Conference on Reverse Engineering (WCRE 00), [5] Nadim Asif, Mark Dixon, Janet Finlay, George Coxhead Recover the Design Artifacts, Proceedings of the International Conference of Information and Knowledge Engineering (IKE 02), pp , Las Vegas, June 24-27, [6] Gail C. Murphy, David Notkin and Kevin J. Sullivan, Software Reflexion Models: Bridging the Gap between Design and Implementation, IEEE Transaction on Software Engineering, vol. 27, No. 4, April [7] [8] W.B.Frakes and R.Baeza-Yates, " Information Retrieval: Data Structures and Algorithms. Prentice- Hall, Englewood Cliffs, NJ, [9] G.C. Gannod and B.H.C Cheng, "Strongest Postcondition as the Formal Basis for Reverse Engineering", Journal of Automated Software Engineering, vol 3, pp , June [10] A. Quilie,"Memory-Based Approach to Recognizing Programs Plans", Communication of the ACM, vol. 30, pp 84-93, May 1994.
Recovery of Metrics by using Reverse Engineering
International Journal of Innovation and Applied Studies ISSN 2028-9324 Vol. 10 No. 2 Feb. 2015, pp. 649-655 2015 Innovative Space of Scientific Research Journals http://www.ijias.issr-journals.org/ Recovery
More informationComponent visualization methods for large legacy software in C/C++
Annales Mathematicae et Informaticae 44 (2015) pp. 23 33 http://ami.ektf.hu Component visualization methods for large legacy software in C/C++ Máté Cserép a, Dániel Krupp b a Eötvös Loránd University mcserep@caesar.elte.hu
More informationChap 1. Introduction to Software Architecture
Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)
More informationTo introduce software process models To describe three generic process models and when they may be used
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationA Framework of Model-Driven Web Application Testing
A Framework of Model-Driven Web Application Testing Nuo Li, Qin-qin Ma, Ji Wu, Mao-zhong Jin, Chao Liu Software Engineering Institute, School of Computer Science and Engineering, Beihang University, China
More informationContents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53
Preface xvi Part I Introduction and System Engineering 1 Chapter 1 Introduction 2 1.1 What Is Software Engineering? 2 1.2 Why Software Engineering? 3 1.3 Software Life-Cycle Activities 4 1.3.1 Software
More informationAn Eclipse Plug-In for Visualizing Java Code Dependencies on Relational Databases
An Eclipse Plug-In for Visualizing Java Code Dependencies on Relational Databases Paul L. Bergstein, Priyanka Gariba, Vaibhavi Pisolkar, and Sheetal Subbanwad Dept. of Computer and Information Science,
More informationFourth generation techniques (4GT)
Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some
More informationRose/Architect: a tool to visualize architecture
Published in the Proceedings of the 32 nd Annual Hawaii International Conference on Systems Sciences (HICSS 99) Rose/Architect: a tool to visualize architecture Alexander Egyed University of Southern California
More informationRotorcraft Health Management System (RHMS)
AIAC-11 Eleventh Australian International Aerospace Congress Rotorcraft Health Management System (RHMS) Robab Safa-Bakhsh 1, Dmitry Cherkassky 2 1 The Boeing Company, Phantom Works Philadelphia Center
More informationAn Open Framework for Reverse Engineering Graph Data Visualization. Alexandru C. Telea Eindhoven University of Technology The Netherlands.
An Open Framework for Reverse Engineering Graph Data Visualization Alexandru C. Telea Eindhoven University of Technology The Netherlands Overview Reverse engineering (RE) overview Limitations of current
More informationSoftware maintenance. Software Maintenance. Fundamental problems. Maintenance activities. Lehman/Belady model of evolution. Topics
Software maintenance Software Maintenance Key problems/issues Historical models and data Program Defined in IEEE Standard 1219 as: The modification of a software product after delivery to correct faults,
More informationDocument Engineering: Analyzing and Designing the Semantics of Business Service Networks
Document Engineering: Analyzing and Designing the Semantics of Business Service Networks Dr. Robert J. Glushko University of California Berkeley glushko@sims.berkeley.edu Tim McGrath Universal Business
More informationCOMP5426 Parallel and Distributed Computing. Distributed Systems: Client/Server and Clusters
COMP5426 Parallel and Distributed Computing Distributed Systems: Client/Server and Clusters Client/Server Computing Client Client machines are generally single-user workstations providing a user-friendly
More informationSoftware Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville
Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when
More informationBetter, Faster, and Cheaper SAS Software Lifecycle
Better, Faster, and Cheaper SAS Software Lifecycle Edmond Cheng, Bureau of Labor Statistics, Washington, DC ABSTRACT In designing software applications, the enduring process faces realistic business challenges
More information6-1. Process Modeling
6-1 Process Modeling Key Definitions Process model A formal way of representing how a business system operates Illustrates the activities that are performed and how data moves among them Data flow diagramming
More informationJos Warmer, Independent jos.warmer@openmodeling.nl www.openmodeling.nl
Domain Specific Languages for Business Users Jos Warmer, Independent jos.warmer@openmodeling.nl www.openmodeling.nl Sheet 2 Background Experience Business DSLs Insurance Product Modeling (structure) Pattern
More informationAnalysis of the Specifics for a Business Rules Engine Based Projects
Analysis of the Specifics for a Business Rules Engine Based Projects By Dmitri Ilkaev and Dan Meenan Introduction In recent years business rules engines (BRE) have become a key component in almost every
More informationCo-Creation of Models and Metamodels for Enterprise. Architecture Projects.
Co-Creation of Models and Metamodels for Enterprise Architecture Projects Paola Gómez pa.gomez398@uniandes.edu.co Hector Florez ha.florez39@uniandes.edu.co ABSTRACT The linguistic conformance and the ontological
More informationAuditing UML Models. This booklet explains the Auditing feature of Enterprise Architect. Copyright 1998-2010 Sparx Systems Pty Ltd
Auditing UML Models Enterprise Architect is an intuitive, flexible and powerful UML analysis and design tool for building robust and maintainable software. This booklet explains the Auditing feature of
More informationBasic Unified Process: A Process for Small and Agile Projects
Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.
More informationApplying 4+1 View Architecture with UML 2. White Paper
Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was
More informationzen Platform technical white paper
zen Platform technical white paper The zen Platform as Strategic Business Platform The increasing use of application servers as standard paradigm for the development of business critical applications meant
More informationChapter 3. Technology review. 3.1. Introduction
Technology review Chapter 3 3.1. Introduction Previous chapter covers detail description about problem domain. In this chapter I will discuss the technologies currently available to solve a problem in
More informationProGUM-Web: Tool Support for Model-Based Development of Web Applications
ProGUM-Web: Tool Support for Model-Based Development of Web Applications Marc Lohmann 1, Stefan Sauer 1, and Tim Schattkowsky 2 1 University of Paderborn, Computer Science, D 33095 Paderborn, Germany {mlohmann,sauer}@upb.de
More informationThe Role of the Software Architect
IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation
More informationA Mind Map Based Framework for Automated Software Log File Analysis
2011 International Conference on Software and Computer Applications IPCSIT vol.9 (2011) (2011) IACSIT Press, Singapore A Mind Map Based Framework for Automated Software Log File Analysis Dileepa Jayathilake
More informationGadget: A Tool for Extracting the Dynamic Structure of Java Programs
Gadget: A Tool for Extracting the Dynamic Structure of Java Programs Juan Gargiulo and Spiros Mancoridis Department of Mathematics & Computer Science Drexel University Philadelphia, PA, USA e-mail: gjgargiu,smancori
More informationVisionet IT Modernization Empowering Change
Visionet IT Modernization A Visionet Systems White Paper September 2009 Visionet Systems Inc. 3 Cedar Brook Dr. Cranbury, NJ 08512 Tel: 609 360-0501 Table of Contents 1 Executive Summary... 4 2 Introduction...
More informationKarunya University Dept. of Information Technology
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
More informationINTERNET PROGRAMMING AND DEVELOPMENT AEC LEA.BN Course Descriptions & Outcome Competency
INTERNET PROGRAMMING AND DEVELOPMENT AEC LEA.BN Course Descriptions & Outcome Competency 1. 420-PA3-AB Introduction to Computers, the Internet, and the Web This course is an introduction to the computer,
More informationQuestions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements
Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements
More informationWHITE PAPER. Peter Drucker. intentsoft.com 2014, Intentional Software Corporation
We know now that the source of wealth is something specifically human: knowledge. If we apply knowledge to tasks we already know how to do, we call it productivity. If we apply knowledge to tasks that
More informationExample Software Development Process.
Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component
More informationAutomating the Measurement of Open Source Projects
Automating the Measurement of Open Source Projects Daniel German Department of Computer Science University of Victoria dmgerman@uvic.ca Audris Mockus Avaya Labs Department of Software Technology Research
More informationUtilizing Domain-Specific Modelling for Software Testing
Utilizing Domain-Specific Modelling for Software Testing Olli-Pekka Puolitaival, Teemu Kanstrén VTT Technical Research Centre of Finland Oulu, Finland {olli-pekka.puolitaival, teemu.kanstren}@vtt.fi Abstract
More informationWhat is a database? COSC 304 Introduction to Database Systems. Database Introduction. Example Problem. Databases in the Real-World
COSC 304 Introduction to Systems Introduction Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca What is a database? A database is a collection of logically related data for
More informationVerifying Business Processes Extracted from E-Commerce Systems Using Dynamic Analysis
Verifying Business Processes Extracted from E-Commerce Systems Using Dynamic Analysis Derek Foo 1, Jin Guo 2 and Ying Zou 1 Department of Electrical and Computer Engineering 1 School of Computing 2 Queen
More informationDeveloping SOA solutions using IBM SOA Foundation
Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this
More informationEvaluating OO-CASE tools: OO research meets practice
Evaluating OO-CASE tools: OO research meets practice Danny Greefhorst, Matthijs Maat, Rob Maijers {greefhorst, maat, maijers}@serc.nl Software Engineering Research Centre - SERC PO Box 424 3500 AK Utrecht
More informationSemantic Object Language Whitepaper Jason Wells Semantic Research Inc.
Semantic Object Language Whitepaper Jason Wells Semantic Research Inc. Abstract While UML is the accepted visual language for object-oriented system modeling, it lacks a common semantic foundation with
More informationTool Support for Software Variability Management and Product Derivation in Software Product Lines
Tool Support for Software Variability Management and Product Derivation in Software s Hassan Gomaa 1, Michael E. Shin 2 1 Dept. of Information and Software Engineering, George Mason University, Fairfax,
More informationA Visual Language Based System for the Efficient Management of the Software Development Process.
A Visual Language Based System for the Efficient Management of the Software Development Process. G. COSTAGLIOLA, G. POLESE, G. TORTORA and P. D AMBROSIO * Dipartimento di Informatica ed Applicazioni, Università
More informationEmbedded Software development Process and Tools: Lesson-1
Embedded Software development Process and Tools: Lesson-1 Introduction to Embedded Software Development Process and Tools 1 1. Development Process and Hardware Software 2 Development Process Consists of
More informationA Business Process Driven Approach for Generating Software Modules
A Business Process Driven Approach for Generating Software Modules Xulin Zhao, Ying Zou Dept. of Electrical and Computer Engineering, Queen s University, Kingston, ON, Canada SUMMARY Business processes
More informationJohannes Sametinger. C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria
OBJECT-ORIENTED DOCUMENTATION C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria Abstract Object-oriented programming improves the reusability of software
More informationThe role of integrated requirements management in software delivery.
Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?
More informationAn Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs)
An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) Rosziati Ibrahim, Siow Yen Yen Abstract System development life cycle (SDLC) is a process uses during the development of any
More informationWhat Is the Java TM 2 Platform, Enterprise Edition?
Page 1 de 9 What Is the Java TM 2 Platform, Enterprise Edition? This document provides an introduction to the features and benefits of the Java 2 platform, Enterprise Edition. Overview Enterprises today
More informationCase Studies of Running the Platform. NetBeans UML Servlet JSP GlassFish EJB
September Case Studies of Running the Platform NetBeans UML Servlet JSP GlassFish EJB In this project we display in the browser the Hello World, Everyone! message created in the session bean with servlets
More informationDesigning a Semantic Repository
Designing a Semantic Repository Integrating architectures for reuse and integration Overview Cory Casanave Cory-c (at) modeldriven.org ModelDriven.org May 2007 The Semantic Metadata infrastructure will
More informationManaging Variability in Software Architectures 1 Felix Bachmann*
Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie
More informationBusiness Application Services Testing
Business Application Services Testing Curriculum Structure Course name Duration(days) Express 2 Testing Concept and methodologies 3 Introduction to Performance Testing 3 Web Testing 2 QTP 5 SQL 5 Load
More informationConcepts of Database Management Seventh Edition. Chapter 9 Database Management Approaches
Concepts of Database Management Seventh Edition Chapter 9 Database Management Approaches Objectives Describe distributed database management systems (DDBMSs) Discuss client/server systems Examine the ways
More informationFormalization of Functional Requirements and Their Traceability in UML Diagrams A Z Notation Based Approach
Formalization of Functional Requirements and Their Traceability in UML Diagrams A Z Notation Based Approach Sabnam Sengupta 1,Swapan Bhattacharya 2 Department of Computer Science & Engineering, Jadavpur
More informationæ A collection of interrelated and persistent data èusually referred to as the database èdbèè.
CMPT-354-Han-95.3 Lecture Notes September 10, 1995 Chapter 1 Introduction 1.0 Database Management Systems 1. A database management system èdbmsè, or simply a database system èdbsè, consists of æ A collection
More informationUmbrello UML Modeller Handbook
2 Contents 1 Introduction 7 2 UML Basics 8 2.1 About UML......................................... 8 2.2 UML Elements........................................ 9 2.2.1 Use Case Diagram.................................
More informationComparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development
Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development Ahmet Demir Technische Universität München Department of Informatics Munich, Germany AhmetDemir@gmx.de
More informationSoftware Analysis Visualization
28th International Conference on Software Engineering Software Analysis Visualization Harald Gall and Michele Lanza !oftware Visualiza"o# Tutorial F7 Software Evolution: Analysis and Visualization 2006
More informationFirewall Builder Architecture Overview
Firewall Builder Architecture Overview Vadim Zaliva Vadim Kurland Abstract This document gives brief, high level overview of existing Firewall Builder architecture.
More informationVISUALIZATION TECHNIQUES OF COMPONENTS FOR LARGE LEGACY C/C++ SOFTWARE
STUDIA UNIV. BABEŞ BOLYAI, INFORMATICA, Volume LIX, Special Issue 1, 2014 10th Joint Conference on Mathematics and Computer Science, Cluj-Napoca, May 21-25, 2014 VISUALIZATION TECHNIQUES OF COMPONENTS
More informationPHP Code Design. The data structure of a relational database can be represented with a Data Model diagram, also called an Entity-Relation diagram.
PHP Code Design PHP is a server-side, open-source, HTML-embedded scripting language used to drive many of the world s most popular web sites. All major web servers support PHP enabling normal HMTL pages
More informationChapter 13: Program Development and Programming Languages
Understanding Computers Today and Tomorrow 12 th Edition Chapter 13: Program Development and Programming Languages Learning Objectives Understand the differences between structured programming, object-oriented
More information2667A - Introduction to Programming
2667A - Introduction to Programming Table of Contents Introduction Audience At Course Completion Prerequisites Microsoft Certified Professional Exams Student Materials Course Outline Introduction Elements
More informationThe EMSX Platform. A Modular, Scalable, Efficient, Adaptable Platform to Manage Multi-technology Networks. A White Paper.
The EMSX Platform A Modular, Scalable, Efficient, Adaptable Platform to Manage Multi-technology Networks A White Paper November 2002 Abstract: The EMSX Platform is a set of components that together provide
More informationThe structured application of advanced logging techniques for SystemVerilog testbench debug and analysis. By Bindesh Patel and Amanda Hsiao.
Logging makes sense for testbench debug The structured application of advanced logging techniques for SystemVerilog testbench debug and analysis. By Bindesh Patel and Amanda Hsiao. SystemVerilog provides
More informationARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS
ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS Lech MADEYSKI *, Michał STOCHMIAŁEK Abstract. Architectural design is about decisions which influence characteristics of arising system e.g. maintainability
More informationRUP Design. Purpose of Analysis & Design. Analysis & Design Workflow. Define Candidate Architecture. Create Initial Architecture Sketch
RUP Design RUP Artifacts and Deliverables RUP Purpose of Analysis & Design To transform the requirements into a design of the system to-be. To evolve a robust architecture for the system. To adapt the
More information601/8498/X IAO Level 3 Certificate in Web Design and Development (RQF)
601/8498/X IAO Level 3 Certificate in Web Design and Development (RQF) A summary of the qualification s content This is a regulated qualification designed to equip you with the knowledge and skills that
More informationJavaFX Session Agenda
JavaFX Session Agenda 1 Introduction RIA, JavaFX and why JavaFX 2 JavaFX Architecture and Framework 3 Getting Started with JavaFX 4 Examples for Layout, Control, FXML etc Current day users expect web user
More informationArchitecture of a Software Configuration Management System for Globally Distributed Software Development Teams
Architecture of a Software Configuration Management System for Globally Distributed Software Development Teams Muhammad Wasim Bhatti Engineering Management Department CASE, Center for Advanced Studies
More informationSoftware development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali
Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)
More informationProgram Understanding in Software Engineering
Taming the complexity: The need for program understanding in software engineering Raghvinder S. Sangwan, Ph.D. Pennsylvania State University, Great Valley School of Graduate Professional Studies Robert
More informationUML-based Test Generation and Execution
UML-based Test Generation and Execution Jean Hartmann, Marlon Vieira, Herb Foster, Axel Ruder Siemens Corporate Research, Inc. 755 College Road East Princeton NJ 08540, USA jeanhartmann@siemens.com ABSTRACT
More information1. Process Modeling. Process Modeling (Cont.) Content. Chapter 7 Structuring System Process Requirements
Content Chapter 7 Structuring System Process Requirements Understand the logical (&physical) process modeling by using data flow diagrams (DFDs) Draw DFDs & Leveling Balance higher-level and lower-level
More informationHow To Develop Software
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
More informationSIEMENS. Teamcenter 11.2. Change Manager PLM00140 11.2
SIEMENS Teamcenter 11.2 Change Manager PLM00140 11.2 Contents What is Change Manager?.............................................. 1-1 Related topics........................................................
More informationRecovering Workflows from Multi Tiered E-commerce Systems
Recovering Workflows from Multi Tiered E-commerce Systems Maokeng Hung ASUS Tek Computer Inc. Yonghe City, Taipei County 234 Taiwan (R.O.C.) alex1_hung@asus.com.tw Ying Zou Dept. of Electrical and Computer
More informationWebSphere Business Modeler
Discovering the Value of SOA WebSphere Process Integration WebSphere Business Modeler Workshop SOA on your terms and our expertise Soudabeh Javadi Consulting Technical Sales Support WebSphere Process Integration
More informationFrom Object Oriented Conceptual Modeling to Automated Programming in Java
From Object Oriented Conceptual Modeling to Automated Programming in Java Oscar Pastor, Vicente Pelechano, Emilio Insfrán, Jaime Gómez Department of Information Systems and Computation Valencia University
More informationRequirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao
Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated
More informationChapter 12 Programming Concepts and Languages
Chapter 12 Programming Concepts and Languages Chapter 12 Programming Concepts and Languages Paradigm Publishing, Inc. 12-1 Presentation Overview Programming Concepts Problem-Solving Techniques The Evolution
More informationChange Pattern-Driven Traceability of Business Processes
Proceedings of the International MultiConference of Engineers and Computer Scientists 2014 Vol I,, March 12-14, 2014, Hong Kong Change Pattern-Driven Traceability of Business Processes Watcharin Uronkarn
More informationSupporting Software Development Process Using Evolution Analysis : a Brief Survey
Supporting Software Development Process Using Evolution Analysis : a Brief Survey Samaneh Bayat Department of Computing Science, University of Alberta, Edmonton, Canada samaneh@ualberta.ca Abstract During
More informationModeling Web Applications Using Java And XML Related Technologies
Modeling Web Applications Using Java And XML Related Technologies Sam Chung Computing & Stware Systems Institute Technology University Washington Tacoma Tacoma, WA 98402. USA chungsa@u.washington.edu Yun-Sik
More informationIV. Software Lifecycles
IV. Software Lifecycles Software processes and lifecycles Relative costs of lifecycle phases Examples of lifecycles and processes Process maturity scale Information system development lifecycle Lifecycle
More informationTowards Collaborative Requirements Engineering Tool for ERP product customization
Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,
More informationQuotes from Object-Oriented Software Construction
Quotes from Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental
More informationDevelopment of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert
Int'l Conf. Software Eng. Research and Practice SERP'15 225 Development of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert Fraunhofer Institute of Optronics, System Technologies and
More informationRETRATOS: Requirement Traceability Tool Support
RETRATOS: Requirement Traceability Tool Support Gilberto Cysneiros Filho 1, Maria Lencastre 2, Adriana Rodrigues 2, Carla Schuenemann 3 1 Universidade Federal Rural de Pernambuco, Recife, Brazil g.cysneiros@gmail.com
More informationOWB Users, Enter The New ODI World
OWB Users, Enter The New ODI World Kulvinder Hari Oracle Introduction Oracle Data Integrator (ODI) is a best-of-breed data integration platform focused on fast bulk data movement and handling complex data
More informationCONDIS. IT Service Management and CMDB
CONDIS IT Service and CMDB 2/17 Table of contents 1. Executive Summary... 3 2. ITIL Overview... 4 2.1 How CONDIS supports ITIL processes... 5 2.1.1 Incident... 5 2.1.2 Problem... 5 2.1.3 Configuration...
More informationLecture 9: Requirements Modelling
A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview
More informationLightweight Data Integration using the WebComposition Data Grid Service
Lightweight Data Integration using the WebComposition Data Grid Service Ralph Sommermeier 1, Andreas Heil 2, Martin Gaedke 1 1 Chemnitz University of Technology, Faculty of Computer Science, Distributed
More informationAn Approach to Software Architecture Description Using UML
An Approach to Software Architecture Description Using UML Henrik Bærbak Christensen, Aino Corry, and Klaus Marius Hansen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N,
More informationIndustrial Adoption of Automatically Extracted GUI Models for Testing
Industrial Adoption of Automatically Extracted GUI Models for Testing Pekka Aho 1,2 pekka.aho@vtt.fi, Matias Suarez 3 matias.suarez@f-secure.com, Teemu Kanstrén 1,4 teemu.kanstren@vtt.fi, and Atif M. Memon
More informationChapter 13: Program Development and Programming Languages
15 th Edition Understanding Computers Today and Tomorrow Comprehensive Chapter 13: Program Development and Programming Languages Deborah Morley Charles S. Parker Copyright 2015 Cengage Learning Learning
More informationSOFTWARE TESTING TRAINING COURSES CONTENTS
SOFTWARE TESTING TRAINING COURSES CONTENTS 1 Unit I Description Objectves Duration Contents Software Testing Fundamentals and Best Practices This training course will give basic understanding on software
More informationFoundations of Model-Driven Software Engineering
Model-Driven Software Engineering Foundations of Model-Driven Software Engineering Dr. Jochen Küster (jku@zurich.ibm.com) Contents Introduction to Models and Modeling Concepts of Model-Driven Software
More information