DOCSLIB.ORG

Using Software Categories for the Development of Generative Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Software Categories for the Development of Generative Software Using Software Categories for the Development of Generative Software Pedram Mir Seyed Nazari and Bernhard Rumpe Software Engineering, RWTH Aachen University, Aachen, Germany Keywords: Model-driven Development, Code Generators, Software Categories. Abstract: In model-driven development (MDD) software emerges by systematically transforming abstract models to concrete source code. Ideally, performing those transformations is to a large extent the task of code generators. One approach for developing a new code generator is to write a reference implementation and separate it into handwritten and generatable code. Typically, the generator developer manually performs this separation — a process that is often time-consuming, labor-intensive, difficult to maintain and may produce more code than necessary. Software categories provide a way for separating code into designated parts with defined dependencies, for example, “Business Logic” code that may not directly use “Technical” code. This paper presents an approach that uses the concept of software categories to semi-automatically determine candidates for generated code. The main idea is to iteratively derive the categories for uncategorized code from the dependencies of categorized code. The candidates for generated or handwritten code finally are code parts belonging to specific (previously defined) categories. This approach helps the generator developer in finding candidates for generated code more easily and systematically than searching by hand and is a step towards tool-supported development of generative software. 1 INTRODUCTION model, the generator developer creates the reference implementation. Next, it has to be determined which Models are at the center of the model-driven devel- code parts need to be or can be generated and which opment (MDD) approach. They abstract from tech- ones should remain handwritten. Finally, the transfor- nical details, facilitating a more problem-oriented de- mations are defined to transform the reference model velopment of software. In contrast to conventional to the aforementioned generated code. general-purpose languages (GPL, such as Java or C), Often, the third step, i.e., ’separation of hand- the language of models is limited to concepts of a written and generated code’ is not explicitly men- specific domain, namely, a domain-specific language tioned in the literature. This separation is implicit (DSL). To obtain an exectuable software application, part of the last step, i.e., ’creation of transformations’, code generators systematically transform the abstract since the transformations are only created for code models to instances of a GPL (e.g., classes of Java). that ought to be generated. However, the separation However, code generators are software themselves of handwritten and generated code ought to be distin- and need to be developed as well. There are different guished as a step on its own, since it is not always development processes for code generators. One that obvious which classes need to be generated. is often suggested (e.g., (Kelly and Tolvanen, 2008) In general, every class can be generated, espe- and (Schindler, 2012)) is shown in Fig. 1. cially when using template-based generators. In an The approach includes four steps. First, a refer- extreme case, a class can be fully copied into a tem- ence model is created, which ultimately serves as in- plate containing only static template code (and, thus, put for the generator. Depending on this reference is independent of the input model). This is not de- sired, following the guideline that only as much code Creation of Creation of Separation of Creation of should be generated as necessary (Stahl et al., 2006), Reference Model Reference Impl. HW and Gen Code Transformations (Kelly and Tolvanen, 2008), (Fowler, 2010). Opti- result result result result mally, most code is put into the domain framework Handwritten Reference Reference Code Templates Model Impl. Templates (or domain platform), increasing the understandabil- Generated Templates Code ity and maintainability of the software. The gener- Figure 1: Typical development steps of a code generator. ated code then only configurates the domain frame- 498 Mir Seyed Nazari P. and Rumpe B.. Using Software Categories for the Development of Generative Software. DOI: 10.5220/0005328204980503 In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 498-503 ISBN: 978-989-758-083-3 Copyright c 2015 SCITEPRESS (Science and Technology Publications, Lda.) UsingSoftwareCategoriesfortheDevelopmentofGenerativeSoftware work for specific purposes (Rumpe, 2012). CardGameGUISwing refines One important criterion for a code generator to be reasonable is the existence of similar code parts, ei- CardGameGUI SheepsHead ther in the same software product or in different prod- ucts (e.g., software product lines). Typically, genera- Swing CardGame tion candidates are similar code parts that are also re- lated to the domain. For example, in a domain about 0 cars, the classes Wheel and Brake would be more likely generation candidates than the domain indepen- Figure 2: Software categories for virtual SheepsHead (Siedersleben, 2004) (shortened). dent and thus unchanged class File. This, of course, is the case, since the information for the generated categories, such as persistence, gui and application. code is obtained by the input model which, in turn, Therefore, (Siedersleben, 2004) suggests using soft- is an instance of a DSL that by definition describes ware categories for finding appropriate components. elements of a specific domain. Of course, the logi- In the following this idea is demonstrated by an ex- cal relation to the domain is not a necessary criterion, ample.1 because if the DSL is not expressive enough, the gen- erated code is additionally integrated with handwrit- Suppose that a software system for the card game ten code. Nevertheless, the generated code often has Sheepshead should be developed. The following cat- some bearing on the domain. egories then could be created (see Fig. 2): In most cases, the generator developer manually • 0 (Zero): contains only global software that is separates handwritten code from generated code. This well-tested, e.g., java.lang and java.util of process can be time-consuming, labor-intensive and the JDK. may impede maintenance. Furthermore, when using • CardGame a domain framework, this separation is insufficient, : contains fundamental knowledge since the handwritten code needs to be separated into about card games in general. Hence, it can be used handwritten code for a specific project and handwrit- for different card games. ten code concerning the whole domain. This sepa- • SheepsHead: Contains rules for the the ration also impacts the maintenance of the software Sheepshead game, e.g., whether a card can (Stahl et al., 2006). To address this problem, software be drawn. categories, as presented in (Siedersleben, 2004), are • CardGameGUI: determines the design of the card suited. game, independent of the used library, e.g., that The aim of this paper is to show how soft- the cards should be in the middle of the screen. ware categories can be exploited to categorize semi- automatically classes and interfaces of an object- • CardGameGUISwing: extends Swing by illustra- oriented software system. The resulting categoriza- tion facilities for cards. tion can be used for determining candidates for gen- • Swing: contains fundamental knowledge about erated code, supporting the developer performing this Java Swing. separation task. This paper is structured as follows: Sec. 2 intro- An arrow in Fig. 2 represents a refinement rela- duces software categories and the used terminology. tion between two categories. Classes that are in a cat- In Sec. 3, these software categories are adjusted for egory C1 that refines another category C2 may use generative software. Sec. 4 presents the allowed de- classes of this category C2. The other way around pendencies derived by the previously defined software is not allowed. Every category - directly or indi- categories. The general categorization approach is ex- rectly - refines the category 0 (arrows in Fig. 2). plained in Sec. 5 and exemplified in Sec. 6. Sec. 7 Hence, software in 0 can be used in every cate- outlines further possible dependencies. Finally, Sec. gory without any problems. CardGame is refined 8 concludes the paper. by SheepsHead and CardGameGUI which means that code in these categories can also use code in CardGame. Note that a communication between CardGameGUI and SheepsHead is not allowed di- 2 SOFTWARE CATEGORIES rectly, but rather by using CardGame or 0 interfaces. Since the category CardGameGUISwing refines both Software systems, especially larger ones, consist of a number of components that interact with each other. 1The example is taken from (Siedersleben, 2004) and re- The components usually belong to different kinds of duced to only the aspects required to explain our approach. 499 MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment AT DT the sake of readability, we do not explicitly mention interfaces, albeit what applies to classes applies to in- A T D T terfaces as well. 0 DG (a) (b) 0‘ 3 CATEGORIES FOR Figure 3: Software categories (a) in general (Siedersleben, GENERATIVE SOFTWARE 2004) and (b) adjusted for generative software. While (Siedersleben, 2004) aims for finding compo- CardGameGUI and Swing, it is a mixed form of these nents from the defined software categories,
Load more

Recommended publications
  • What Is Project Management Software?
    HOW TO SELECT & IMPLEMENT PROJECT MANAGEMENT SOFTWARE Considering a new PM solution? Don’t forget: Picking a product is only half the journey—getting your team to actually use the software is the ultimate goal. To help you reach your implementation destination, we’ve created this road map, and we’re guiding you through the process from tool selection to user adoption. Each stop along the path represents an important step in the process—skipping ahead will only jeopardize your chance of success! StartStart HereHere CHANGE This team’s They should meet MANAGEMENT responsibility? with teams and leaders to understand Establish an Organizational Identify the need workflows, goals and Change Management Team for change. pain points. BACK TO START If you haven’t established HINT: a change management team. A need for change might be a process that can be improved, a pain point that can be mitigated or a near-term goal you hope to achieve. STAKEHOLDER ANALYSIS Perform a Stakeholder Analysis Use these requirements 2 SPACES BACK to create a list of must-have capabilities. Identify end users and If you haven’t identified their requirements. the needs of your team. These will drive your search & selection process. SOFTWARE HINT: EVALUATION Create a Shortlist Identifying “must-have” vs. “nice-to-have” capabilities will help focus your search on products that are most valuable to your team. Read reviews to see how peers rate each tool for qualities such as: ease of use and support. Set up a vendor demo for each stakeholder group. Users can evaluate how the tool aligns with Keep the following existing workflows, meets Ease of Use considerations in mind immediate needs and when evaluating Timeline for drives near-term goals.
    [Show full text]
  • APR1400-Z-J-NR-14003-NP, Rev 0, "Software Program Manual."
    Non-Proprietary Software Program Manual APR1400-Z-J-NR-14003-NP, Rev.0 Software Program Manual Revision 0 Non-Proprietary November 2014 Copyright ⓒ 2014 Korea Electric Power Corporation & Korea Hydro & Nuclear Power Co., Ltd. All Rights Reserved KEPCO & KHNP Non-Proprietary Software Program Manual APR1400-Z-J-NR-14003-NP, Rev.0 REVISION HISTORY Revision Date Page Description November 0 All First Issue 2014 This document was prepared for the design certification application to the U.S. Nuclear Regulatory Commission and contains technological information that constitutes intellectual property. Copying, using, or distributing the information in this document in whole or in part is permitted only by the U.S. Nuclear Regulatory Commission and its contractors for the purpose of reviewing design certification application materials. Other uses are strictly prohibited without the written permission of Korea Electric Power Corporation and Korea Hydro & Nuclear Power Co., Ltd. KEPCO & KHNP ii Non-Proprietary Software Program Manual APR1400-Z-J-NR-14003-NP, Rev.0 ABSTRACT This technical report (TeR) provides the software engineering process for digital computer-based instrumentation and control (I&C) systems of the APR1400. This report describes the processes which ensure the reliability and design quality of the software throughout its entire life cycle. By implementing the processes in this report, the digital I&C system software achieves the following: Desired level of quality and reliability required for nuclear power plants (NPPs) Safety-related I&C functions for protecting and securing the safe operation of the NPPs Satisfactory conformance to nuclear codes and standards KEPCO & KHNP iii Non-Proprietary Software Program Manual APR1400-Z-J-NR-14003-NP, Rev.0 TABLE OF CONTENTS 1.0 INTRODUCTION .................................................................................................
    [Show full text]
  • Software: a Primer for Managers a Gallaugher.Com Chapter Provided Free to Faculty & Students for Non-Commercial Use © Copyright 1997-2009, John M
    Understanding Software: A Primer for Managers a gallaugher.com chapter provided free to faculty & students for non-commercial use © Copyright 1997-2009, John M. Gallaugher, Ph.D. – for more info see: http://www.gallaugher.com/chapters.html Last modified: March 8, 2009 (draft version: comments very much welcomed) Note: this is an earlier version of the chapter. All chapters updated after July 2009 are now hosted (and still free) at http://www.flatworldknowledge.com. For details see the ‘Courseware’ section of http://gallaugher.com INTRODUCTION We know computing hardware is getting faster and cheaper, creating all sorts of exciting and disruptive opportunities for the savvy manager. But what’s really going on inside the box? It’s software that makes the magic of computing happen. Without software, your PC would be a heap of silicon, wrapped in wires encased in plastic and metal. But it’s the instructions—the software code--that enable a computer to do something wonderful, driving the limitless possibilities of information technology. Software is everywhere. An inexpensive cell phone has about 1 million lines of code, while the average car contains nearly 100 million1. In this chapter we’ll take a peek inside the chips to understand what software is. There are a lot of terms associated with software: operating systems, applications, enterprise software, distributed systems, and more. We’ll define these terms up front, and put them in a managerial context . A follow‐up chapter, “Software in Flux”, will focus on changes impacting the software business, including open source software, software as a service (SaaS), and cloud computing.
    [Show full text]
  • IDC's Worldwide Semiannual IT Spending Guide by Industry and Company Size Taxonomy, 2018
    ANALYZE THE IDC FUTURE Taxonomy IDC's Worldwide Semiannual IT Spending Guide by Industry and Company Size Taxonomy, 2018 Stephen Minton Jessica Goepfert Angela Vacca Ivana Slaharova Roberto Membrila Naoko Iwamoto Ashutosh Bisht Nikhil Anand Jebin George IDC'S WORLDWIDE INDUSTRY AND COMPANY SIZE TAXONOMY FIGURE 1 IDC's Standard Industries, 2018 Manufacturing Distribution and Finance Infrastructure Public Sector Consumer and Resources Services I I I Discrete Telecommunica- Federalfcentral Banking Retail Consurner manufacturing bons government I I I I Process State,local Insurance Wholesale Utilities manufacturing government I I I I Securities and Resource Healthcare investment Transportation industries provider services I I I DUSTRIES Professional IN Construction Education services I Personal arid consumer services I Media Source: IDC, 2018 January 2018, IDC #US43526718 INDUSTRY AND COMPANY SIZE TAXONOMY CHANGES FOR 2018 There have been no major changes to the overall industry and company size taxonomy since the 2H16 version, but the taxonomy structure has been reorganized to align with other IDC research including the Worldwide Black Book and the latest versions of worldwide tracker products. These changes include the following: . Telecom services has been added as a new technology group and includes fixed voice, fixed data, mobile voice, and mobile data services. Where telecom services are included in a deliverable, a new taxonomy dimension called "spending group" is also now included to differentiate between IT spending and telecom spending. Telecom spending includes telecom services, as listed previously, and telecom equipment (telecom equipment is carrier-specific equipment including wireless infrastructure, purchased by telecom service providers for the delivery of public telecom services).
    [Show full text]
  • Appendix D – NTETC Software Sector
    NTEP Committee 2009 Final Report Appendix D – NTETC Software Sector Appendix D National Type Evaluation Technical Committee Software Sector May 20 - 21, 2008 – Reynoldsburg, Ohio Meeting Summary Agenda Items Carryover Items ........................................................................................................................................................ D2 1.a. NTETC Software Sector Mission ................................................................................................................. D2 1.b. NCWM/NTEP Policies – Issuing Certificates of Conformances (CC) for Software ................................... D2 1.c. Definitions for Software Based Devices ...................................................................................................... D3 1.d. Software Identification/Markings ................................................................................................................. D5 2. Identification of Certified Software.............................................................................................................. D7 3. Software Protection/Security ........................................................................................................................ D9 4. Software Maintenance and Reconfiguration .............................................................................................. D16 5. Verification in the Field, by the Weights and Measures Inspector ............................................................. D19 6. NTEP Application
    [Show full text]
  • CPA's Guide to Restaurant Management Strategies : Accounting, Cost Controls, and Analysis; Marsha Huber
    University of Mississippi eGrove American Institute of Certified Public Accountants Guides, Handbooks and Manuals (AICPA) Historical Collection 2000 CPA's guide to restaurant management strategies : accounting, cost controls, and analysis; Marsha Huber Follow this and additional works at: https://egrove.olemiss.edu/aicpa_guides Part of the Accounting Commons, and the Taxation Commons Recommended Citation Huber, Marsha, "CPA's guide to restaurant management strategies : accounting, cost controls, and analysis;" (2000). Guides, Handbooks and Manuals. 130. https://egrove.olemiss.edu/aicpa_guides/130 This Book is brought to you for free and open access by the American Institute of Certified Public Accountants (AICPA) Historical Collection at eGrove. It has been accepted for inclusion in Guides, Handbooks and Manuals by an authorized administrator of eGrove. For more information, please contact [email protected]. s G u i d e t o R e s t a u r a n t M a n a g e m e n t S A CPA's Guide to t r a t e g i e s : Restaurant A c c o u n t Management i n g , C o s t Strategies: C o n t r o l s , Accounting, Cost Controls, a n d A n a and Analysis l y s i s A I C P A Marsha Huber, CPA A m e r i c a n I n s t i t u t e A CPA's Guide to o f C e Restaurant r t i f i e d Management P u b l i c Strategies: A c c o u n Accounting, Cost Controls, t a n t s and Analysis Marsha Huber, CPA Notice to Readers A CPA’s Guide to Restaurant Management Strategies does not represent an official position of the American Institute of Certified Public Accountants, and it is distributed with the understanding that the author and publisher are not rendering legal, accounting, or other professional services in this publication.
    [Show full text]
  • DOE Federal Source Code Policy
    DOE Federal Source Code Policy DOE CODE is a software service platform and search tool that allows for scientific and business software to be provided to the U.S. Department of Energy (DOE). DOE CODE provides functionality for collaboration, archiving, and discovery of scientific and business software. DOE CODE replaces the Energy Science and Technology Software Center (ESTSC). The DOE Office of Scientific and Technical Information (OSTI) is charged with fulfilling the Department's responsibilities to collect, preserve, and disseminate scientific and technical information, including software, emanating from DOE R&D activities. In addition to OSTI's charge for scientific software, the Office of the Chief Information Officer (OCIO) and OSTI are partnering to leverage DOE CODE to maintain a comprehensive inventory of DOE-funded custom-developed business software. In accordance with Office of Management and Budget Memorandum M-16-21, Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software, DOE CODE will fulfill requirements to maintain an inventory of all DOE-funded custom-developed software and to report this inventory to the government-wide Code.gov website. When providing software and code to DOE CODE, users will first need to identify what type of software they are submitting - scientific or business software. Users who are unsure of the type of software are encouraged to please work with their site's Dissemination Authority. Note: throughout this policy, the terms "software"
    [Show full text]
  • Open Source Design Software Overview
    SEGD.org Open Source Design Software prepared by Chad Eby Herron School of Art + Design at IUPUI SEGD Academic Task Force SEGD Training Module Training SEGD Introduction to EGD Overview What is Open Source? Free and open source software (sometimes called FOSS) tools are developed “in the open” so that anyone may inspect an application’s source code—the underlying set of instructions that make the application work—that is hidden by design in proprietary tools. Not only is the source code visible, it is generally permissible to use, re- distribute and modify without restriction. This makes it free (as in freedom). As a side effect, many open source software tools are also free (as in beer), meaning image credit they are usable at no cost. Photo by Marc Mueller from Pexels Open Source Design Software Overview Why Use Open Source? An open source design software tool may be attractive to individuals and organizations due to the transparent nature of its development, the lack of restrictions on distribution and use, the suitability for a niche purpose too small for commercial viability, the low cost/no cost aspect or some combination of these factors. As good as open source tools may seem at first blush, there are some caveats. FOSS projects, especially in the early stages, may have sporadic development cycles and are sometimes abandoned entirely. Even in projects that are actively developed and well established, the documentation for the tool may lag well behind the latest released version. Finally, since some FOSS tools are passion projects of individuals or small teams, the software user interface may be quite eccentric.
    [Show full text]
  • Data and Information Management in the Ecological Sciences, 1998.Pdf
    Data and Information Management in the Ecological Sciences: A Resource Guide Edited by William K. Michener, John H. Porter, and Susan G. Stafford This publication should be cited as: Michener, W.K., J.H. Porter, and S.G. Stafford. 1998. Data and information management in the ecological sciences: a resource guide. LTER Network Office, University of New Mexico, Albuquerque, NM. Publisher: LTER Network Office, University of New Mexico, Albuquerque, NM Preface More than 100 individuals attended a two-day workshop (August 8-9, 1997) entitled "Data and Information Management in the Ecological Sciences" that was held at the University of New Mexico in Albuquerque. Objectives of the workshop were to: effect technology transfer, especially at biological field stations and marine laboratories; facilitate people networking; communicate training needs and opportunities; identify future needs for data management at field stations; and produce hard copy and digital versions of the proceedings. Workshop instructors provided comprehensive overviews of the technological infrastructure for a data management system (e.g., hardware, software, communications, and networking), data entry, quality assurance, database management systems, metadata, archival, the World Wide Web, and scientific visualization. Additional roundtable discussions focused specifically on software for field stations, challenges and opportunities at field stations, and site-specific data management implementation. The editors are grateful to: the National Science Foundation Database Activities
    [Show full text]
  • ONLINE LOCAL FOOD MARKETS: Choosing the Right Software
    ONLINE LOCAL FOOD MARKETS: Choosing the Right Software Abstract A Brief History of Online Online local food markets have proven effective by increasing Food Shopping access for customers and supporting farm and specialty food businesses. Starting an online market is a complex endeavor that In the early 2000s, online grocery shopping companies (called e- requires time, planning, and many decisions. The engine for this grocers at the height of the boom) experienced a boom and bust type of market is the software, and, with so many options, it can cycle as they launched almost as quickly as they failed. be difficult to know how to get started. This publication is Companies poured considerable money into warehouses, designed to help businesses, cooperatives, consultants, farmers, transportation fleets, and marketing. E-grocers at that time or any team to identify which software to choose. Using a three- needed to meet minimum weekly sales goals in order to fund step process outlined in this publication, anyone considering their expensive infrastructure, and when they were not able to starting an online market can assess internal technological and reach these goals, they failed. What did show promising results, business needs; evaluate technological considerations, functions, however, were larger grocery retailers (such as Safeway) who and categories; and evaluate and select the right software. used their existing warehouse space to reduce food storage costs. These companies saw promising results with increased sales Introduction from 2005 to 2009 (Tedeschi 2002). Despite emerging potential, the profitability of early online According to a 2019 survey conducted by Coresight Research, shopping was primarily concentrated in metropolitan areas.
    [Show full text]
  • Mining and Analyzing User Rationale in Software Engineering
    University of Hamburg Mining and Analyzing User Rationale in Software Engineering Dissertation with the aim of achieving a doctoral degree (Dr. rer. nat) at the Faculty of Mathematics, Informatics, and Natural Sciences Department of Informatics of the University of Hamburg submitted by Zijad Kurtanović from Sarajevo Hamburg, 2018 Day of oral defense: 19.04.2018 Head of examination commission: Prof. Dr. Ingrid Schirmer Evaluators of the dissertation: 1. Prof. Dr. Walid Maalej 2. Prof. Dr. Nicole Novielli To my family, with love. Acknowledgments I would like to express my deep gratitude to Walid Maalej, for his trust, visionary guidance, and inspirational support. I feel honored to had him as my supervisor and cannot express how much I learned from him. Thank you for your invaluable feedback and encouragement to pursue this topic and the opportunity to learn and continuously grow in and beyond research. I also thank Nicole Novielli who accepted to be my second supervisor. Thank you for the inspiring talks and discussions on natural language processing during your stay in Hamburg and your valuable feedback. I am lucky to have worked with great colleagues at the Applied Software Tech- nology Group: Alexander Beifuß, Mathias Ellmann, Fariba Fazli, Davide Fucci, Marlo Häring, Chakajkla Jesdabodi, Timo Johann, Clara Marie Lüders, Na- talia Mannov, Daniel Martens, Lloyd Montgomery, Yen Dieu Pham, Christoph Stanik, Rebecca Tiarks, and Nedaa Zirjawi. I am grateful for all the fruitful discussions, your valuable feedback, all the shared experiences and memorable moments that shaped me and my research. Thank you for any kind of support. I am deeply thankful to all of you for amplifying my moments of joy and being there in tough times.
    [Show full text]
  • Software and Software Engineering
    UNIT- I Software and Software Engineering: The Nature of Software, The Unique Nature of WebApps, Software Engineering, The Software Process, Software Engineering Practice, Software Myths Process Models: A Generic Process Model, Process Assessment and Improvement, Prescriptive Process Models, Specialized Process Models, The Unified Process, Personal and Team Process Models, Process Technology, Product and Process. Agile Development: Agility, Agility and the Cost of Change, Agile Process, Extreme Programming, Other Agile Process Models Software and Software Engineering Software engineering stands for the term is made of two words, Software and Engineering. Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods. Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. Definitions IEEE defines software engineering as: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in the above statement. Fritz Bauer, a German computer scientist, defines software engineering as: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines. 1 Software Engineering (R15) The Nature of Software Software takes Dual role of Software.
    [Show full text]