Showing papers on "Software construction published in 1994"
Proceedings Article•
[...]
TL;DR: The main focus in MUCKE is on cleaning large scale Web image corpora and on proposing image representations which are closer to the human interpretation of images.
Abstract: MUCKE aims to mine a large volume of images, to structure them conceptually and to use this conceptual structuring in order to improve large-scale image retrieval. The last decade witnessed important progress concerning low-level image representations. However, there are a number problems which need to be solved in order to unleash the full potential of image mining in applications. The central problem with low-level representations is the mismatch between them and the human interpretation of image content. This problem can be instantiated, for instance, by the incapability of existing descriptors to capture spatial relationships between the concepts represented or by their incapability to convey an explanation of why two images are similar in a content-based image retrieval framework. We start by assessing existing local descriptors for image classification and by proposing to use co-occurrence matrices to better capture spatial relationships in images. The main focus in MUCKE is on cleaning large scale Web image corpora and on proposing image representations which are closer to the human interpretation of images. Consequently, we introduce methods which tackle these two problems and compare results to state of the art methods. Note: some aspects of this deliverable are withheld at this time as they are pending review. Please contact the authors for a preview.
2,578 citations
Proceedings Article•
1 Jan 1994
TL;DR: This paper provides an introduction to the emerging field of software architecture by considering a number of common architectural styles upon which many systems are currently based and showing how different styles can be combined in a single design.
Abstract: As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.
1,408 citations
Book•
1 Dec 1994
TL;DR: Stephen H. Kan is responsible for IBM Rochester's software quality strategy and plans, quality assessment, software measurements, and statistical analysis.
Abstract: From the Publisher:
Author Biography:
Dr. Stephen H. Kan, an ASQC Certified Quality Engineer, is responsible for IBM Rochester's software quality strategy and plans, quality assessment, software measurements, and statistical analysis. He has been the software quality focal point for the software system of the AS/400 computer since its initial release in 1988.
1,164 citations
TL;DR: A power analysis technique is developed that has been applied to two commercial microprocessors and can be employed to evaluate the power cost of embedded software and can help in verifying if a design meets its specified power constraints.
Abstract: Embedded computer systems are characterized by the presence of a dedicated processor and the software that runs on it Power constraints are increasingly becoming the critical component of the design specification of these systems At present, however, power analysis tools can only be applied at the lower levels of the design-the circuit or gate level It is either impractical or impossible to use the lower level tools to estimate the power cost of the software component of the system This paper describes the first systematic attempt to model this power cost A power analysis technique is developed that has been applied to two commercial microprocessors-Intel 486DX2 and Fujitsu SPARClite 934 This technique can be employed to evaluate the power cost of embedded software This can help in verifying if a design meets its specified power constraints Further, it can also be used to search the design space in software power optimization Examples with power reduction of up to 40%, obtained by rewriting code using the information provided by the instruction level power model, illustrate the potential of this idea >
1,072 citations
21 May 1994
TL;DR: A five-step method for analyzing software architectures called SAAM (Software Architecture Analysis Method) is proposed and illustrated by analyzing three separate user interface architectures with respect to the quality of modifiability.
Abstract: While software architecture has become an increasingly important research topic in recent years, insufficient attention has been paid to methods for evaluation of these architectures. Evaluating architectures is difficult for two main reasons. First, there is no common language used to describe different architectures. Second, there is no clear way of understanding an architecture with respect to an organization's life cycle concerns -software quality concerns such as maintainability portability, modularity, reusability, and so forth. We address these shortcomings by describing three perspectives by which we can understand the description of a software architecture and then proposing a five-step method for analyzing software architectures called SAAM (Software Architecture Analysis Method). We illustrate the method by analyzing three separate user interface architectures with respect to the quality of modifiability. >
632 citations
1 Jul 1994
TL;DR: A historical approach is emphasized to show the relationships between well-understood design problems and the as-yet unsolved problems in co-design.
Abstract: This paper surveys the design of embedded computer systems, which use software running on programmable computers to implement system functions. Creating an embedded computer system which meets its performance, cost, and design time goals is a hardware-software co-design problem-the design of the hardware and software components influence each other. This paper emphasizes a historical approach to show the relationships between well-understood design problems and the as-yet unsolved problems in co-design. We describe the relationship between hardware and software architecture in the early stages of embedded system design. We describe analysis techniques for hardware and software relevant to the architectural choices required for hardware-software co-design. We also describe design and synthesis techniques for co-design and related problems. >
482 citations
Book•
[...]
1 Jan 1994
TL;DR: This text provides students with an introduction to the role of design in software engineering, reviewing the leading design methods, both formal and informal, from a neutral viewpoint.
Abstract: From the Publisher:
Based on a curriculum module originally written for the Software Engineering Institute at Carnegie Mellon University, this text provides students with an introduction to the role of design in software engineering. The book surveys a wide range of design methods and evaluates their strengths and weaknesses in various applications. The author adopts a neutral approach, concentrating on the role of design in software development creating a more effective tutorial text for students.
Features
Provides a balanced introduction to software design, reviewing the leading design methods, both formal and informal, from a neutral viewpoint.
Describes and evaluates a wide range of different design methods, including JSP, SSA/SD, JSD, object-oriented and object- based design
Focuses on design principles and strategies, which can be directly applied in practice.
423 citations
21 May 1994
TL;DR: A theory is presented for one aspect of architectural description, the interactions between components, to define architectural connectors as explicit semantic entities that characterize each of the participant roles in an interaction and how these roles interact.
Abstract: As software systems become more complex the overall system structure - or software architecture - becomes a central design problem. An important step towards an engineering discipline of software is a formal basis for describing and analyzing these designs. We present a theory for one aspect of architectural description, the interactions between components. The key idea is to define architectural connectors as explicit semantic entities. These are specified as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact. We illustrate how this scheme can be used to define a variety of common architectural connectors. We provide a formal semantics and show how this lends to a sound deductive system in which architectural compatibility can be checked in a way analogous to type checking in programming languages. >
422 citations
27 Jun 1994
TL;DR: Reliability theory applies to random variations in a population of similar objects, whereas software defects are all design flaws, not at all random, in a unique object.
Abstract: Reliability refers to statistical measures an engineer uses to quantify imperfection in practice. Often we speak imprecisely of an object having "high reliability", but technically, unless the object cannot fail at all, its reliability is arbitrarily close to zero for a long enough period of operation. This is merely an expression of the truism that an imperfect object must eventually fail. At first sight, it seems that software should have a sensible reliability, as other engineered objects do. But the application of the usual mathematics is not justified. Reliability theory applies to random (as opposed to systematic) variations in a population of similar objects, whereas software defects are all design flaws, not at all random, in a unique object. The traditional cause of failure is a random process of wear and tear, while software is forever as good (or as bad!) as new. However, software defects can be thought of as lurking in wait for the user requests that excite them, like a minefield through which the user must walk. >
416 citations
1 Aug 1994
TL;DR: The purpose of this paper is to explain in which way the problem of testing protocol implementations is different from the usual problem of software testing.
Abstract: Communication protocols are the rules that govern the communication between the different components within a distributed computer system. Since protocols are implemented in software and/or hardware, the question arises whether the existing hardware and software testing methods would be adequate for the testing of communication protocols. The purpose of this paper is to explain in which way the problem of testing protocol implementations is different from the usual problem of software testing. We review the major results in the area of protocol testing and discuss in which way these methods may also be relevant in the more general context of software testing.
1 Sep 1994
TL;DR: An automated solution to identify different kinds of code changes and their impact in an object-oriented class library is provided, and an OO software maintenance environment that implements the research result is described.
Abstract: In the object-oriented (OO) paradigm, new features (such as encapsulation, aggregation, inheritance, polymorphism and dynamic binding) introduce new problems in software testing and maintenance. One of them is the difficulty of identifying the affected components (such as classes) when changes are made in object-oriented class libraries or programs. This paper discusses the types of code changes in an object-oriented class library, and provides an automated solution to identify different kinds of code changes and their impact. In addition, an OO software maintenance environment that implements the research result is described. Our experience with the environment prototype shows promising results. >
TL;DR: The maintainability assessment polynomials presented here are accurate models of the test data on which they were constructed and are automated working models that can be used to quickly and easily predict software maintainability.
TL;DR: This chapter discusses the practical impact of calvinism in the southern baptist convention, the dangerous false teaching of andy stanley, and 10 benefits of giving thanks by charles f stansley.
21 May 1994
TL;DR: This paper presents the design and implementation of an automated software repository, where software components can be automatically stored and retrieved, based on a formal representation of programs and their specifications, as well as a refinement ordering of these specifications.
Abstract: Software reuse poses a number of challenges, ranging from managerial to technical - not least of these is the problem of storing and retrieving software components in a time efficient manner. This paper presents the design and implementation of an automated software repository, where software components can be automatically stored and retrieved. This repository is based on a formal representation of programs and their specifications, as well as a refinement ordering of these specifications. >
Book•
1 Jan 1994
TL;DR: Part One - What 1. Software Assessment and Improvement 2. BOOTSTRAP Methodology in a Nutshell 3. An Assessment Case Example 4. Results and Experiences 5. Exploitation and Future Directions.
Abstract: Part One - What 1. Introduction 2. Software Assessment and Improvement 3. BOOTSTRAP Methodology in a Nutshell. Part Two - Why 4. Software Process Assessment and Improvement with BOOTSTRAP 5. Software Process Areas. Part Three - How 6. Preparation of the Assessment 7. The Assessment 8. Capability and Maturity Level Determination 9. Assessment Outputs 10. Assessment Tools and Database 11. Software Process Improvement and Action Plan Generation. Part Four - How Well 12. An Assessment Case Example 13. Results and Experiences 14. Exploitation and Future Directions.
Book•
1 Oct 1994
TL;DR: This paper presents SLANG through a case study which illustrates SLANG main features, including process modularization, interaction with tools, and process evolution, and describes the architecture of the rst implementation of SPADE, called SPADE1, showing how the environment supports concurrent enaction of process activities, integration of external tools and storage of persistent data in an object-oriented database.
Abstract: The SPADE project aims at de ning and developing a software processcentered environment to describe, analyze, and enact software process models. These models are speci ed in SLANG (Spade LANGuage), a process modeling language that provides process speci c modeling facilities. This paper presents SLANG through a case study which illustrates SLANG main features, including process modularization, interaction with tools, and process evolution. In addition, it describes the architecture of the rst implementation of SPADE, called SPADE1, showing how the environment supports concurrent enaction of process activities, integration of external tools, and storage of persistent data in an object-oriented database.
21 May 1994
TL;DR: A scenario-based detection method, in which each reviewer executes a specific procedure to discover a particular class of defects has a higher defect detection rate than either ad hoc or checklist methods.
Abstract: Software requirements specifications (SRS) are usually validated by inspections, in which several reviewers read all or part of the specification and search for defects. We hypothesize that different methods for conducting these searches may have significantly different rates of success. Using a controlled experiment, we show that a scenario-based detection method, in which each reviewer executes a specific procedure to discover a particular class of defects has a higher defect detection rate than either ad hoc or checklist methods. We describe the design, execution and analysis of the experiment so others may reproduce it and test our results for different kinds of software developments and different populations of software engineers. >
1 Jan 1994
TL;DR: R reverse engineering technology developed as part of the Rigi project is presented, concerned with the analysis of existing software systems to make them more understandable for maintenance, re-engineering, and evolution purposes.
Abstract: Software engineering research has focused primarily on software construction, neglecting software maintenance and evolution. Observed is a shift in research from synthesis to analysis. The process of reverse engineering is introduced as an aid in program understanding. This process is concerned with the analysis of existing software systems to make them more understandable for maintenance, re-engineering, and evolution purposes. Presented is reverse engineering technology developed as part of the Rigi project. The Rigi approach involves the identi cation of software artifacts in the subject system and the aggregation of these artifacts to form more abstract system representations. Early industrial experience has shown that software engineers using Rigi can quickly build mental models from the discovered abstractions that are compatible with the mental models formed by the maintainers of the underlying software.
Book•
1 Feb 1994TL;DR: Educational Software Selecting Educational Software Checklists for Software Assessment Examination of the Checklist Approach in Software Selection Problems with the Check list approach to Software Selection Frameworks for Studying Educational Software.
Abstract: Educational Software Selecting Educational Software Checklists for Software Assessment Examination of the Checklist Approach in Software Selection Problems with the Checklist Approach to Software Selection Frameworks for Studying Educational Software A Perspectives Interactions Paradigm for Studying Educational Software The Teacher and Student Perspectives Interaction The Designer and Student Perspectives Interaction The Designer and Teacher Perspectives Interaction Choosing and Using Educational Software.
23 Sep 1994
TL;DR: This work introduces a new partitioning approach that caters to the main objective of the hardware/software partitioning problem, i.e., minimizing hardware for given performance constraints, and demonstrates results superior to those of previously published algorithms intended for hardware/ software partitioning.
Abstract: Partitioning a system ‘3 functionality among interacting hardware and software components is an important part of system design. We introduce a new partitioning approach that caters to the main objective of the hardware/software partitioningproblem, i.e., minimizing hardware ,for given performance constraints. We demonstrate results superior to those of previously published algorithms intendedjor hardware/software partitioning. The approach may be genera&able to problems in which one metric must be minimized while other metrics must merely satisfy constraints.
TL;DR: This paper introduces an incremental approach to software process management based on a net-based software process modeling language called FUNSOFT nets and model software processes by means of different views onto a software process model.
Abstract: Software processes are usually described by guidelines and advices. These guidelines are claimed to be valid for many projects. This understanding leads to software processes which deviate from initial plans and which frequently yield insufficient results. System-atic management of software processes can help to overcome these shortcomings. In this paper, we introduce an incremental approach to software process management. This approach covers the complete life-cycle of software process models, i.e., it deals with software process modeling, software process model analysis, and software process model enaction. It is based on a net-based software process modeling language called FUNSOFT nets. FUNSOFT nets are high-level Petri nets adapted to the application domain of software process management. We model software processes by means of different views onto a software process model. Our approach is implemented in a software process management environment called MELMAC.
1 Nov 1994
TL;DR: This paper begins by establishing a taxonomy of approaches to reusability metrics based on their empirical or qualitative orientation, and examines the disciplines, theories, and techniques used by numerous existingReusability measurement methods as they relate to the taxonomy.
Abstract: This paper examines various approaches to measuring software reusability. Knowing what makes software "reusable" can help us learn how to build new reusable components and help us to identify potentially useful modules in existing programs. The paper begins by establishing a taxonomy of approaches to reusability metrics based on their empirical or qualitative orientation. The paper then examines the disciplines, theories, and techniques used by numerous existing reusability measurement methods as they relate to the taxonomy. Recognizing that most of these methods focus exclusively on internal characteristics of components and ignore environmental factors, the paper challenges reusability researchers to incorporate domain attributes into their metrics. In fact, the application domain represents a critically important factor in whether or not we find a component reusable. The research, framework, and conclusions should provide a useful reference for persons interested in ways to determine the reusability of software. >
TL;DR: The authors present their cosynthesis approach, and specify system behavior using HardwareC, a hardware description language (HDL) that has a C-like syntax and supports timing and resource constraints and supports specification of unbounded and unknown delay operations that can arise from data-dependent decisions and external synchronization operations.
Abstract: Recent advances in the design and synthesis of integrated circuits have prompted system architects to investigate computer aided design methods for systems that contain both application-specific and predesigned reprogrammable components. For the most part, we can apply high level synthesis techniques to synthesis of systems containing processors by treating the latter as a generalized resource. However, the problem is more complex, since the software on the processor implements system functionality in an instruction-driven manner with a statically allocated memory space, whereas ASICs operate as data driven reactive elements. Due to these differences in computational models and primitive operations in hardware and software, a new formulation of the problem of cosynthesis is needed. The authors present their cosynthesis approach. They specify system behavior using HardwareC, a hardware description language (HDL) that has a C-like syntax and supports timing and resource constraints. It also supports specification of unbounded and unknown delay operations that can arise from data-dependent decisions and external synchronization operations. The particular choice of a HDL to specify system functionality is immaterial for the cosynthesis formulation here, and other HDLs such as Verilog could be used. >
1 Jun 1994
TL;DR: This paper introduces and compares four strategies for defining high-level design metrics, based on different sets of assumptions related to a well defined experimental goal they help reach: identify error-prone software parts.
Abstract: The availability of significant metrics in the early phases of the software development process allows for a better management of the later phases, and a more effective quality assessment when software quality can still be easily affected by preventive or corrective actions. In this paper, we introduce and compare four strategies for defining high-level design metrics. They are based on different sets of assumptions (about the design process) related to a well defined experimental goal they help reach: identify error-prone software parts. In particular, we define ratio-scale metrics for cohesion and coupling that show interesting properties. An in-depth experimental validation, conducted on large scale projects demonstrates the usefulness of the metrics we define.
5 Jul 1994
TL;DR: This position paper will elaborate the requirements and outline a strategy for the design and implementation of a composition language for the development of open systems to better support application evolution and flexibility.
Abstract: The key requirement for open systems is that they be flexible, or recomposable. This suggests that they must first of all be composable. Object-oriented techniques help by allowing applications to be viewed as compositions of collaborating objects, but are limited in supporting other kinds of abstractions that may have finer or coarser granularity than objects. A composition language supports the technical requirements of a componentoriented development approach by shifting emphasis from programming and inheritance of classes to specification and composition of components. Objects are viewed as processes, and components are abstractions over the object space. An application is viewed as an explicit composition of software components. By making software architectures explicit and manipulable, we expect to better support application evolution and flexibility. In this position paper we will elaborate our requirements and outline a strategy for the design and implementation of a composition language for the development of open systems.
Book•
1 Jun 1994
TL;DR: The software lifecycle - the user requirements definitionphase the software requirements definition phase the architectural design phase the detailed design and production phase the transfer phase the operations and maintenance phase procedure standards.
Abstract: The software lifecycle - the user requirements definition phase the software requirements definition phase the architectural design phase the detailed design and production phase the transfer phase the operations and maintenance phase procedure standards - management of the software lifecycle software project management software configuration management software verification and validation software quality assurance.