Shaw, M. Larger Scale Systems Require Higher-Level Abstractions. In Proceedings of the Fifth International IEEE Computer Society Workshop on SoftwareSpeci #cation and Design #1989#, pp. 143#146.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....be reused in a wide variety of similar situations. Since humans can be expected to learn and participate in a restricted set of artifacts, an adequate collection of general architectures might be eminently manageable in size. The same basic vision has driven software architectures research in SE [578, 580]. What these standard DC models might be is beyond the scope of this work. The main point of bringing up DC architectures in this chapter is to ensure that the importance of the DC architectural level of analysis is realized. This will become important in later sections since they will be ....

Shaw, M. Larger scale systems require higher-level abstractions. In Proceedings of the Fifth International Workshop on Software Specification and Design (Pittsburgh, Pennsylvania, May 19--20

....1990 was unheard of To begin, the field did not spontaneously create itself in 1990. But that time frame was when the term software architecture began to gain widespread acceptance and when the field first attracted substantial attention from both industry and the research community (e.g. [40], 34] The field was created out of necessity. Software systems were growing larger: systems of hundreds of thousands or even millions of lines of code were becoming commonplace. Clearly the foundations of the ideas underlying the field that is today called software architecture were laid by ....

....must be used as both a description and prescription, must be used by multiple stakeholders. While the architect designs the overall structure of a computational system, many specialists will refine and implement each of the views. Common architectural structures include (e.g. see [27] and [40]) functional (or logical) view . code view . development (or structural) view . concurrency (or process thread) view . physical (or deployment) view The precise number, names, and types of these views are still a subject of some debate, and not a particularly interesting debate at that. ....

[Article contains additional citation context not shown here]

Shaw, M., "Larger Scale Systems Require Higher-Level Abstractions", Proceedings of Fifth International Workshop on Software Specification and Design, IEEE Computer Society, 1989, 143-146.

....by current documentation techniques. Understanding these systems involves uncovering the system level design of software: discovering the kinds of modules and subsystems used and the way these modules and subsystems are organized. This level of abstraction is called the software architecture level [15, 16]. Managing complexity and supporting evolution are two fundamental problems with largescale software systems [17] As the size of software systems increases, the design problems go beyond the algorithms and data structures of computation [18] Without proper documentation or aid, gaining an ....

M. Shaw. Larger scale systems require higherlevel abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....construction, which typically deal with exact information for purposes such as code generation, debugging, and integration, architectures for understanding must allow and deal with inexact or partial information. The art of effective understanding is to know what to leave out and what to ignore [4]. Incompleteness is the norm, not only for practical reasons of the scalability and immaturity of the analysis methods, but because there cannot be a definitive architecture in an evolving system. Even inconsistency and conflicts from trying to consolidate two architectures are acceptable, since ....

M. Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....is an emerging one with little agreement over the definition of architecture. The only consensus seems to be that architecture is related to the structure of a system and the interactions among its components [15, 29] Some of the work focuses on building theory and models of architecture [2, 39], with an emphasis on taxonomy, description 2 languages, and verification of architectural properties. Several efforts have been made to generate code based on parts of architecture [14, 31] In general, the literature relies heavily on informal examples and anecdotes, and most of this work has ....

....In our software structure categories, these issues are addressed in the execution structure. Now research is progressing to higher abstraction levels. Software engineers would like to be able to compose software systems using concurrent objects [1, 38] or assemblies of components and connectors [5,8,10,26,39]. We place these concerns in the conceptual structure category. In the rest of this section, we use System B as an example to discuss the typical categories of software structures across all the systems we studied. We describe the four categories of structures, the relationships among them, and ....

M. Shaw. Larger scale systems require higher level abstractions, in Proceedings of the Fifth International Workshop on Software Specification and Design, IEEE Computer Society, pages 143-146, May 1989.

....begun to emerge as discipline of study in its own right. This has come about in part by a recognition of the central role of common design patterns and idioms or architectural style. Among early efforts to identify, name, and analyze these patterns, in 1989 Shaw categorized a number of idioms [33] and later Garlan and Shaw [18] extended this list, providing several examples of their use in understanding real systems. Concurrently, Perry and Wolf [30] also recognized the importance of architectural patterns and outlined the use of styles in characterizing applications such as compilers. A ....

Shaw, M. Larger scale systems require higher level abstractions. Proceedings Fifth International Workshop on Software Specification and Design, IEEE Computer Society, Software Engineering Notes 14, 3 (May 1989), 143--146.

....by the majority of distributed programming languages, see [5, 7] We therefore concentrate on the second category, paradigms supporting algorithm design, in the context of an operational programming language such as Hermes. A number of paradigms within this second category are described in [11, 19, 39, 47]. Based on [11] these paradigms are grouped in three classes: result parallelism, specialist parallelism, and agenda parallelism. These three classes capture different approaches towards the construction of parallel and distributed algorithms. Result parallelism produces a series of values with ....

....results are combined to give the final result, see also [39] In blackboard systems, a central data structure represents the current stat of the computation. A number of independent processes, each responsible for a certain kind of knowledge, check the current state and update it if they can ([47]) Iterative relaxation divides the data space into adjacent regions, which are then assigned to different processes. Each process carries out activities local to its region, communicating with neighbours when necessary ( 19] 3.4 Specialist Parallelism Paradigms Paradigms following the ....

[Article contains additional citation context not shown here]

Mary Shaw. Larger Scale Systems Require Higher--Level Abstractions. 5th International Workshop on Software Specification and Design, 14(2):143--146, May 1989. Appeared as ACM SIGSOFT Software Engineering Notes.

....research, which analyzes the similarities and differences between architectures and attempts to map out the shape of the whole field. The aim of this work is to identify and codify commonly used architectural paradigms, and to understand the tradeoffs in choosing one paradigm over another [15]. At the other extreme is the investigation of specific software structures. These studies typically elucidate the structure of specific software systems by describing them as high level components and connections. This work aims to document the structure of a single system or class of related ....

Shaw, M. Larger Scale Systems Require Higher Level Abstractions. Proceedings Fifth International Workshop on Software Specification and Design, IEEE Computer Society, Software Engineering Notes, vol. 14 (1989), pp. 143--146.

....much more cleanly with windows and a mouse. However, the presentation of 137 the program is still at the level of the implementation. This may show more detail than is desirable for restructuring the tool user in many cases is thinking in terms of module structure and overall architecture [Shaw 89] One obstruction to presenting an architectural view is the lack of high level constructs in programming languages, which often do not go beyond the module level to describe properties such as layering and other salient relationships [Shaw 89] Without this linguistic (i.e. syntactic) basis, it ....

.... in terms of module structure and overall architecture [Shaw 89] One obstruction to presenting an architectural view is the lack of high level constructs in programming languages, which often do not go beyond the module level to describe properties such as layering and other salient relationships [Shaw 89] Without this linguistic (i.e. syntactic) basis, it is difficult to build predictable, precise, high level models for manipulation. As described in Chapter 2.4, the basis for restructuring transformations is the set of syntactic forms in the language. Given this basis, it is not difficult to ....

M. Shaw. Larger scale systems require higher-level abstractions. In Proceedings of the Fifth International Workshop on Software Specification and Design, pages 143--146. IEEE Computer Society, 1989. ACM SIGSOFT Software Engineering Notes, 14(3).

....guidelines that improve the system quality and performance by enabling experience reuse. Such guidelines are diverse in nature, ranging from environment specific programming conventions[Mey92] to rules of thumb like the information hiding principle[Par72] to domain independent design idioms[Sha89] Recently, research in software architecture has focused on identifying and cataloging reusable design models and rules, including object oriented patterns[GHJV94] frameworks[Deu89] architectural styles[PW92, GAO94] and common software connectors[SDZ96] Unfortunately, system design and ....

Mary Shaw. Larger Scale Systems Require Higher-Level Abstractions. In Proceedings of the Fifth Workshop on Software Specification and Design, 1989.

....maximal number of subclusters in a cluster, and the individual cluster evaluations. The derivation of such a quantitative measure, however, is lacking a firm foundation. Contrary to the evaluation of individual clusters, not much is known about what constitutes a good cluster hierarchy. Shaw[25], for example, states the need for the development for higher level abstractions for larger scale systems, such as distributed applications. The paper discusses a number of potential abstractions and states that such abstractions, while used informally, are not yet systematically understood. This ....

Mary Shaw. Larger Scale Systems Require Higher--Level Abstractions. 5th International Workshop on Software Specification and Design, 14(2):143--146, May 1989. Appeared as ACM SIGSOFT Software Engineering Notes.

....space and associated rules for user interface software, and it discusses an experiment that validated these design rules by comparing their predictions to real system designs. 1. Introduction Software architecture is the study of the large scale structure and performance of software systems [Shaw 89] Important aspects of a system s architecture include the division of functions among system modules, the means of communication between modules, and the representation of shared information. The architectural alternatives available to a system designer can be described and classified by ....

Mary Shaw. Larger Scale Systems Require Higher-Level Abstractions. In Proceedings of Fifth International Workshop on Software Specification and Design, pages 143-146. IEEE Computer Society, May 1989. ACM SIGSOFT Software Engineering Notes, Volume 14 Number 3.

....investigated, and irrelevant parts can be ignored. To gain useful knowledge, the information must be effectively summarized and abstracted. In a sense, a key to program understanding is deciding what information is material and what is immaterial: knowing what to look for and what to ignore [31]. 4.2 Rigi framework The most recent results of the Rigi project include: a reverse engineering environment consisting of a parsing subsystem, a distributed, multi user repository, and an interactive graph editor [32] a representation for software structure based on (k; 2) partite graphs [33] a ....

M. Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

.... : 6 6 Recognition Queries Reusable Styles (Idealized and As Built) Architectural Representation Recognition Engine Source Code Figure 1: Architectural Recovery Engine Figure 2: Bird s Eye Overview 2. 1 Architectural Styles The research community has provided detailed examples [6, 7, 8, 2] of idealized architectures abstractions that can guide architectural discovery. We have attempted to recognize instances of these abstractions in source code. 2.1.1 Entity and Relation Representation To support recognition, we have developed a dictionary of entity and relation terminology ....

M. Shaw. Larger scale systems require higher-level abstractions. In Proceedings of the 5th International Workshop on Software Specification and Design, 1989.

....and classes. Higherlevel entities, such as subsystems, projects, and libraries, which have no analogue in most conventional programming languages, exist as well. The concept of the Software Landscape is related to a new stream of Software Engineering research dealing with software architectures [13]. Landscape entities are interconnected through explicitly defined relations. There are Landscape relations between language level units, such as imports, exports, or inherits, as well as other relations, such as part of (e.g. an entity is part of a subsystem) which is not expressible in most ....

Shaw, M. Larger Scale Systems Require Higher-Level Abstractions. In Proceedings of the Fifth International IEEE Computer Society Workshop on Software Specification and Design (1989), pp. 143--146.

....large systems, the information generated during reverse engineering is prodigious. Presenting the user with reams of data is insufficient; knowledge is gained only through the understanding of this data. In a sense, a key to program understanding is deciding what to look for and what to ignore [17]. Once the artifacts have been identified and extracted from the source code, the next step in the reverse engineering process is to extract system abstractions and design information. This is usually accomplished with various clustering algorithms to aggregate lower level objects into logical ....

M. Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....reverse engineering is prodigious. Simply presenting the user with reams of data is insufficient; knowledge is gained only through the understanding of the data. In a sense, a key to HSU is deciding what information is material and what is immaterial: knowing what to look for and what to ignore [Sha89] 2.2.2.2 Knowledge organization For HSU, gathered data must be put into a representation that facilitates efficient storage and retrieval, permits analysis of the artifacts and relationships, and yet reflects the users perspective of the subject system s structure. This requirement the need ....

Mary Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....accumulated during program understanding is staggering. To gain useful knowledge, one must effectively summarize and abstract the information. In a sense, a key to program understanding is deciding what information is material and what is immaterial: knowing what to look for and what to ignore [28]. 4.2 Redocumentation strategy There are tradeoffs in program understanding environments between what can be automated and what should (or must) be left to humans. Structural redocumentation in Rigi is initially automatic and involves parsing the source code of the subject system and storing the ....

M. Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....is prodigious. Presenting the user with reams of data is insufficient. Knowledge is gained only through the understanding of this data. In a sense, a key to program understanding is deciding what information is material and what is immaterial: knowing what to look for and what to ignore [11]. 2.3 Domain independence Many current systems support only relatively small programs. Others support just one programming language, usually because their parsing system, database, and support environment are tightly coupled. Some 3 The term extraction time is similar to compile time, ....

M. Shaw. Larger scale systems require higher-level abstractions. ACM SIGSOFT Software Engineering Notes, 14(3):143--146, May 1989. Proceedings of the Fifth International Workshop on Software Specification and Design.

....architecture for a specific application domain while we are attempting to define the philosophical underpinnings of the discipline, to determine a notation for expressing the specification of the various architectural documents, and determine how these documents can be used in automated ways. Shaw [21] comes the closest in approach to ours. She takes the view of a programming language designer and abstracts classes of components, methods of composition, and schemas from a wide variety of systems. These correspond somewhat to our notions of processing and data elements, connecting elements, and ....

M. Shaw, Larger Scale Systems Require HigherLevel Abstractions, Proc. Fifth Inter. Workshop on Software Specification and Design, Pittsburgh, PA, May 1989, appearing in ACM SIGSOFT Notes, Vol. 14, No. 3, May 1989, pp. 143--146.

....how current notations fail to satisfy those properties. 1 Introduction As the size and complexity of software systems increase, the design and specification of overall system structure become a more significant issue than the choice of algorithms and data structures of computation [DK76, Sha89] Structural issues include the gross organization of the system; the global control structure; the protocols for communication, synchronization, and data access; the assignment of functionality to design elements; the composition of design elements; scaling and performance; and selection among ....

....terms refer to common, or idiomatic, patterns used to organize the overall system. These are often widely used among software engineers in high level descriptions of system designs. A number of the more pervasive patterns have been identified in descriptions of architectural idioms [GKN88, GS93b, Sha89, Sha91] and material based on these patterns is beginning to appear in courses on architectural design of software [GSO 92] Among the more common architectural patterns are: Pipes and filters Graph of incremental stream transformers. Examples: Unix pipes, signal processing. Client server ....

Mary Shaw. Larger scale systems require higher level abstractions. Proceedings Fifth International Workshop on Software Specification and Design, IEEE Computer Society, Software Engineering Notes, 14(3):143--146, May 1989.

No context found.

Shaw, M. Larger Scale Systems Require Higher-Level Abstractions. In Proceedings of the Fifth International IEEE Computer Society Workshop on SoftwareSpeci #cation and Design #1989#, pp. 143#146.

No context found.

M. Shaw, "Larger Scale Systems Require Higher-Level Abstractions", Proc. 5th Int. Workshop on Software Specification and Design, Pittsburgh, PA, May 1989, pp. 143--146.

No context found.

Shaw, M., "Larger Scale Systems Require Higher-Level Abstractions", Proceedings of Fifth International Workshop on Software Specification and Design, IEEE Computer Society, 1989, 143146.

No context found.

Shaw, M., "Larger Scale Systems Require Higher-Level Abstractions", Proceedings of Fifth International Workshop on Software Specification and Design, IEEE Computer Society, 1989, 143146.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC