scispace - formally typeset
Search or ask a question

Showing papers on "Database-centric architecture published in 1998"


Proceedings ArticleDOI
10 Aug 1998
TL;DR: The Architecture Tradeoff Analysis Method is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.
Abstract: This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

647 citations


Journal ArticleDOI
01 Jul 1998
TL;DR: In this paper, the authors present a formalism for the definition of software architectures in terms of graphs, where nodes represent the individual agents and edges define their interconnection, and the dynamic evolution of an architecture is defined independently by a "coordinator".
Abstract: We believe that software architectures should provide an appropriate basis for the proof of properties of large software. This goal can be achieved through a clearcut separation between computation and communication and a formal definition of the interactions between individual components. We present a formalism for the definition of software architectures in terms of graphs. Nodes represent the individual agents and edges define their interconnection. Individual agents can communicate only along the links specified by the architecture. The dynamic evolution of an architecture is defined independently by a "coordinator". An architecture style is a class of architectures specified by a graph grammar. The class characterizes a set of architectures sharing a common communication pattern. The rules of the coordinator are statically checked to ensure that they preserve the constraints imposed by the architecture style.

280 citations


Proceedings ArticleDOI
13 May 1998
TL;DR: This paper introduces a new field-programmable architecture that is targeted at compute-intensive applications that is more area-efficient than traditional FPGAs by a factor of more than 2.5 times.
Abstract: This paper introduces a new field-programmable architecture that is targeted at compute-intensive applications. These applications are important because of their use in the expanding multi-media markets in signal and data processing. We explain the design methodology, layout and implementation of the new architecture. A synthesis method has also been developed with which we have mapped several circuits to the new architecture. In this paper, we show that the invented architecture is more area-efficient than traditional FPGAs by a factor of more than 2.5 times.

151 citations


Proceedings ArticleDOI
01 Apr 1998
TL;DR: This work presents two examples of extending UML, an emerging standard design notation, for use with two architecture description languages, C2 and Wright, and suggests a practical strategy for bringing architectural modeling into wider use.
Abstract: Software architecture descriptions are high-level models of software systems. Some researchers have proposed special-purpose architectural notations that have a great deal of expressive power but are not well integrated with common development methods. Others have used mainstream development methods that are accessible to developers, but lack semantics needed for extensive analysis. We describe an approach to combining the advantages of these two ways of modeling architectures. We present two examples of extending UML, an emerging standard design notation, for use with two architecture description languages, C2 and Wright. Our approach suggests a practical strategy for bringing architectural modeling into wider use, namely by incorporating substantial elements of architectural models into a standard design method.

137 citations


Journal ArticleDOI
TL;DR: This paper reports on the experience with a relational approach to support the analysis of existing software architectures and the theory, the tools and some of the applications developed so far.
Abstract: This paper reports on our experience with a relational approach to support the analysis of existing software architectures. The analysis options provide for visualization and view calculation. The approach has been applied for reverse engineering. It is also possible to check concrete designs against architecture-related rules. The paper surveys the theory, the tools and some of the applications developed so far. © 1998 John Wiley & Sons, Ltd.

111 citations


Journal ArticleDOI
01 Oct 1998
TL;DR: This paper investigates the feasibility of performing behaviour analysis on systems which conform to the change model, and associates behavioural specifications with the components of a software architecture and analyses the behaviour of systems composed from these components.
Abstract: The software architecture of a system is the overall structure of the system in terms of its constituent components and their interconnections. Dynamic changes to the instantiated system architecture (to the components and/or interconnections) may take place while it is running. In order that these changes do not violate the integrity of the system, we adopt a general model of dynamic configuration which only permits change to occur when the affected portions of the system are quiescent. This paper investigates the feasibility of performing behaviour analysis on systems which conform to the change model. The analysis approach associates behavioural specifications with the components of a software architecture and analyses the behaviour of systems composed from these components. The changes that can occur are modelled as constraints on the architecture, thereby permitting incremental and even concurrent changes. Analysis is used to check that the architecture satisfies the properties required of it: before, during and after the changes. The paper uses an example to illustrate the approach.

69 citations


Proceedings ArticleDOI
01 Nov 1998
TL;DR: An quantitative approach based on clustering techniques forSoftware architecture restructuring and reengineering as well as for software architecture recovery is presented.
Abstract: 1. ABSTRACT Capturing of software architecture is critical for maintenance and evolution. However, existing approaches often are limited only to software architecture recovery in the reverse engineering process. What is needed more is a systematic and effective approach to help the designer to restructure or reengineer an architecture for improvement. This paper presents an quantitative approach based on clustering techniques for software architecture restructuring and reengineering as well as for software architecture recovery. Clustering techniques are built on top of reverse engineering tools. The approach has been applied to several examples at various levels of abstraction. Two case studies are presented in this paper. One is an empirical study of a decoupling effort for a real-time telecommunications system. The other example shows a research potential to enforce the designer to improve an architecture by adopting a design pattern based on the clustering results. 1.1 Keywords Architecture recovery, restructuring, evolution, clustering, patterns

68 citations


Journal ArticleDOI
01 Oct 1998
TL;DR: The ability of the formalism to express the dynamics of the architecture itself and to unify different approaches to reconfiguration within a single framework is explored.
Abstract: The chemical abstract machine is a general-purpose, simple, and intuitive progranning model. Among other domains, it has been used for the specification and analysis of the computational behaviour of software architectures. In this paper we explore the ability of the formalism to express the dynamics of the architecture itself and to unify different approaches to reconfiguration within a single framework.

52 citations



Proceedings ArticleDOI
24 Jun 1998
TL;DR: The framework is applied to analyze the actual software architecture of 6 subsequent releases of a 15MLoc telecommunications product and shows that the framework can provide much insight on the actual implementation of a system with a layered architecture.
Abstract: This paper presents the results of an empirical study. The study aims at evaluating the ability to understand the coherence between design documents that describe the layered architecture of large scale systems, and the actual structure of the software source file organization. A clear set of objectives to be addressed for achieving a good understanding of a layered architecture is defined. The objectives are focused on identifying the interfaces between layers, in terms of cross-layer file dependencies. An analysis framework for achieving these objectives is proposed. The framework is applied to analyze the actual software architecture of 6 subsequent releases of a 15MLoc telecommunications product. Results of that experiment show that the framework can provide much insight on the actual implementation of a system with a layered architecture.

38 citations


Journal ArticleDOI
TL;DR: An agent software architecture using a model of agent is presented, composed of three abstract levels over which the complexity is distributed and reduced, which helps in understanding how non-determinist behavior can emerge from interactions between agents.
Abstract: This paper’s object is to present the results of the GEAMAS project which aims at modeling and simulating natural complex systems. GEAMAS is a generic architecture of agents used to study the behavior emergence in such systems. It is a multiagent program meant to develop simulation applications. Modeling complex systems requires to reduce, to organize the system complexity and to describe suitable components. Complexity of the system can then be tackled with an agent-oriented approach, where interactions lead to a global behavior. This approach helps in understanding how non-determinist behavior can emerge from interactions between agents, which is near of self-organized criticality used to explain natural phenomena. In the Applied Artificial Intelligence context, this paper presents an agent software architecture using a model of agent. This architecture is composed of three abstract levels over which the complexity is distributed and reduced. The architecture is implemented in ReActalk, an open agent-oriented development tool, which was developed on top of Smalltalk-80. To illustrate our purpose and to validate the architecture, a simulation program to help in predicting volcanic eruptions was investigated. This program was run over a period of one year and has given many satisfying results unattainable up to there with more classical approaches.

Proceedings ArticleDOI
16 Apr 1998
TL;DR: An approach to using architectural description for the behavioural analysis of distributed software systems and some of the issues which arise in providing tool support are discussed.
Abstract: A Software Architecture is the overall structure of a system in terms of its constituent components and their interconnections. In this position paper, we discuss an approach to using architectural description for the behavioural analysis of distributed software systems and some of the issues which arise in providing tool support. The approach is based on the use of finite state automata to specify behaviour and Compositional Reachability Analysis to check composite system models. The architecture description of a system is used directly to generate the model used for analysis.

Proceedings ArticleDOI
02 Dec 1998
TL;DR: This paper contends that the existence of a "software architecture level of design" is based on the implicit assumption that the software development process is analogous to those "construction" disciplines in which the completed artefacts or systems exhibit a unique representational abstraction, fixed during the early stages of design, which is described as "the architecture".
Abstract: In recent years, software engineering researchers have elevated the study of software architecture to the level of a major area of study. A review of the published literature however, shows quite clearly that a unified view of software architecture has not been forth-coming. This paper contends that the existence of a "software architecture level of design" is based on the implicit assumption that the software development process is analogous to those "construction" disciplines in which the completed artefacts or systems exhibit a unique representational abstraction, fixed during the early stages of design, which we describe as "the architecture". We argue that our problems in obtaining an acceptable definition of software architecture are due to the assumption that software systems have an analogous, unique design abstraction determinable at the early stages of the design. To determine the validity of this analogy, we contrast the nature and use of architecture in the traditional building process with software development to identify the differences, rather than the similarities that exist. These differences are explained using a theory of the software development process which highlights why these differences arise and, subsequently why there has been trouble in developing a community-wide understanding of software architecture. Our conclusion is that due to the fundamental nature of the systems we construct, attempts to depict the large-scale structure of the system, in an analogous manner traditional building disciplines, results in many different architectures. These are fundamentally different representations and not merely different views of a single whole. Moreover, each of these is equally qualified to be labelled as the system architecture with respect to the general notion of what architecture is.

Proceedings ArticleDOI
01 Nov 1998
TL;DR: Some common misconceptions about architectures are dispels and problem areas for which architecture is well suited and those for which it is not are discussed, to attempt to clearly delineate the boundaries of applicability and effectiveness of software architectures.
Abstract: 1. ABSTRACT Explicit focus on architecture has shown tremendous potential to improve the current state-of-the-art in software development. Relatively quickly, software architecture research has produced credible results. However, some of this initial success has also resulted in unrealistic expectations and failure to recognize the limits of this line of research, which can result in backlash when the unrealistic expectations are not met. One solution is to attempt to clearly delineate the boundaries of applicability and effectiveness of software architectures. This paper represents a step in that direction: it dispels some common misconceptions about architectures and discusses problem areas for which architecture is well suited and those for which it is not.’

Proceedings ArticleDOI
01 Nov 1998
TL;DR: This position paper argues the need for specifying distinct views of a software architecture, each characterizing a specific type of properties (i.e. functional, interaction, and quality properties), and proposes some hints on how this can be handled.
Abstract: The specification of a software architecture using different ADLs allows system designers to carry out a number of complementary analyses. In this position paper, we go one step further in this direction by advocating the need for specifying distinct views of a software architecture, each characterizing a specific type of properties (i.e. functional, interaction, and quality properties). Multi-view description of a software architecture raises the issue of combining a set of architectural views so as to derive the resulting overall architecture. We propose some hints on how this can be handled.

Proceedings ArticleDOI
01 Nov 1998
TL;DR: MobiS, a coordination language based on multiple tuple spaces is introduced and it is shown through an example how it can be used for the specification of software architectures containing mobile components.
Abstract: Modern Software Architectures often have to deal with mobile components. Therefore, the structure of these systems is dynamic and continuously changing.We introduce mobiS, a coordination language based on multiple tuple spaces and show through an example how it can be used for the specification of software architectures containing mobile components. The flexibility of the language encodes mobility in the model, so the specification of mobile components and of reconfigurable systems is easy.Due to the non-determinism of the coordination model the behaviors of components context-dependent can be specified and used to make assumptions on the kind of architecture the component can be put into.

Proceedings ArticleDOI
22 Sep 1998
TL;DR: The author develops the notion of architecture fragments, i.e. reusable architectural specifications that describe a design pattern or a framework architecture that describes the structure of an architecture in terms of its components, the architecture-specific behaviour of the components and the Architecture-specific interaction between the components.
Abstract: Object-oriented software architectures, such as design patterns and frameworks, have found extensive use in software industry. Their implementation in traditional object-oriented programming languages, however, is often difficult, since no support for the explicit specification of software architectures is provided. The author develops the notion of architecture fragments, i.e. reusable architectural specifications that describe a design pattern or a framework architecture. An architectural fragment describes the structure of an architecture in terms of its components (roles), the architecture-specific behaviour of the components and the architecture-specific interaction between the components. Fragments can be composed with each other and with reusable components. To illustrate the use of fragments, the author describes the role and architecture language constructs in the layered object model (L/sup AY/OM) and presents examples.

Proceedings ArticleDOI
24 Jun 1998
TL;DR: The key features of the X-RAY approach for recovering distributed software architectures are illustrated through the depiction of a step-by-step recovery experiment performed on a small yet non-trivial distributed software system.
Abstract: The extraction of high-level architectural information from existing software systems, or architecture recovery, is a recent research area. This paper presents X-RAY, an approach for recovering distributed software architectures. X-RAY builds on previous work on architecture recovery and more traditional reverse engineering techniques, as well as on notations for architecture description. The key features of the approach are illustrated through the depiction of a step-by-step recovery experiment performed on a small yet non-trivial distributed software system. Initial results from an ongoing experiment involving a larger-scale system are also discussed.

Proceedings ArticleDOI
01 Nov 1998
TL;DR: This paper explores some issues in the expressiveness of Architecture Description Languages (ADLs) based on work architecting large, software-intensive systems for command and control and related domains and suggests approaches to addressing some of these cases.
Abstract: This paper explores some issues in the expressiveness of Architecture Description Languages (ADLs) based on our work architecting large, software-intensive systems for command and control and related domains. We briefly outline and motivate several cases where current ADLs lack architecturally useful forms of expression and suggest approaches to addressing some of these cases. 1 Architectural Description Architects don’t make architectures, they make representations of architectures. Architectural description ‐ the means to record architectural information in a form such that it may be used (communicated, analyzed, manipulated) and re-used ‐ is central to the emerging practice of software systems architecture. Interest in architectural description has taken various forms. One active area of current research is architecture description languages (ADLs) as witnessed by:

Proceedings ArticleDOI
01 Nov 1998
TL;DR: This work focuses on architecture hierarchies as a means of enabling formal demonstrations through proof that an architecture does indeed possess the desired dependability properties, and poses a challenge problem for dependable software architectures.
Abstract: Dependable architectures demonstrably possess properties such as safety, security, and fault tolerance. We are interested in developing methods allowing formal demonstrations through proof that an architecture does indeed possess the desired dependability properties. We focus on architecture hierarchies as a means of enabling such demonstrations. We pose a challenge problem for dependable software architectures and we propose a research agenda for solving it. 1 What are dependable software architectures? Software architectures describing software products that are used to implement critical functions must be trustworthy. Dependability is the property of a computing system which allows reliance to be justi ably placed on the service it delivers. The service delivered by a system is its behavior as it is perceived by its users. Dependability is a qualitative judgment about a system. The software architecture community has made great strides toward characterizing and capturing system descriptions appropriately and toward providing linguistic support for de ning families of software products, but current ADLs and their associated methodologies do not adequately address dependability. When software products are deployed in a high-integrity system, their dependability pro le is key to the survivability of the system. It is desirable to have developers of critical systems also bene t from software architecture technology. For example, an autopilot software producer would like to be able to derive, from a single abstract speci cation of a dependable software architecture, implementations for a number of aircraft variants. The derivation process would be supported by tools for applying dependability-preserving transformations that make abstract speci cations more concrete. So, these implementations would be known to share dependability attributes as well as functionality. Such dependability-preserving transformations are key not only for e ective and timely resource development, but also for assurance and certi cation. Enriching software architecture descriptions by including dependability attributes will enable and facilitate the reuse of not only software components but certi cation data as well. In critical systems, the cost of assurance and certi cation is comparable with the development cost. Dependable architectures demonstrably possess properties such as safety, security, and fault tolerance. It is our objective to produce methods allowing formal demonstrations through proof that an architecture does indeed possess the speci ed dependability properties. One important limitation on the utility of applying typical formal methods to reasoning about architectures is the purely informal connection between the mathematical models that are analyzed and the system being modeled. If formal analysis of a model reveals the presence of a aw, it is generally easy to determine whether that aw is present in the implemented system. But it is highly desirable to use formal methods to establish that the software is free of certain types of aws, such as failing to meet safety, security, or fault tolerance objectives. Security properties typically state that certain sorts of error cannot occur. For example, a security property might state that certain sorts of communication within the system | such as ow of restricted information to a component without adequate clearances | cannot occur. Tools supporting various formal methods can be used to prove that any correct implementation of the abstract mathematical model has these properties. However, there is no guarantee that the actual software correctly implements the model. The problem of gaining con dence in the correctness of the implementation is especially acute in the case of dynamic, dependable architectures, where exhaustive testing of architectural con gurations is frequently prohibitively expensive, when not theoretically infeasible. 2 IMA: a challenge problem for dependable software ar-

Journal ArticleDOI
01 Jul 1998
TL;DR: This paper examines current definitions of “systems architecture”, and proposes a taxonomy of terms to distinguish “single use” from “enduring” applications of architecture.
Abstract: The term “System Architecture” has been widely used in the systems engineering community for at least three decades. Even today, however, the use of this term often elicits more confusion than understanding! In particular, “System Architecture” has been used to describe, at various times, both the evolutionary system framework (Rechtin 91) (Rechtin/Maier 97), and the specific physical design or component interrelationship (Hatley 88). Even when it is agreed that the “System Architecture” represents a framework in which detailed design is performed, it is not generally agreed what aspects of behavior and structure should be captured in such a framework, how it should be represented, and how it relates to the specifics of system design. This paper examines current definitions of “systems architecture”, and proposes a taxonomy of terms to distinguish “single use” from “enduring” applications of architecture. Particular attention is paid to enduring architectures and their relationship to systems engineering.

Proceedings ArticleDOI
13 Sep 1998
TL;DR: This paper presents a software architecture for composing complete system-level simulations of mechatronic systems, and illustrates the individual concepts of the architecture in the design of a missile seeker.
Abstract: This paper presents a software architecture for composing complete system-level simulations of mechatronic systems. The proposed architecture will provide the designer with the infrastructure to rapidly create simulations of alternative designs. The architecture promotes modularity and composability through the use of the design entity. Moreover, the architecture supports hierarchical modeling and provides the infrastructure to seamlessly integrate mechanics models with electronics and information technology models. Finally, the architecture facilitates distributed computing to take full advantage of the power of networked computers. This paper introduces the individual concepts of our architecture, and illustrates them in the design of a missile seeker.

Journal ArticleDOI
TL;DR: The authors have used the terminology and framework to develop a set of issues which need to be addressed when constructing a control architecture and these issues have been used to compare two architectures developed at National Institute of Standards and Technology.
Abstract: The development of architectures for control systems has been an active area of research for at least twenty years. This research has produced many different architectures which use different terminologies and address different issues. In order to analyse existing architectures and to determine issues that must be addressed in defining a new one, a common terminology for discussing architectures and a framework for organizing information about architectures is needed. Based upon an examination of many control architectures in the areas of computer integrated manufacturing and robotics, the authors propose a terminology for discussing control architectures and a framework for constructing control architectures. The authors have used the terminology and framework to develop a set of issues which need to be addressed when constructing a control architecture. These issues have been used to compare two architectures developed at National Institute of Standards and Technology. This paper presents the terminolog...

DissertationDOI
01 Jan 1998
TL;DR: The development of a generalized and practical framework for scalable persistent system design is described and cause for optimism that orthogonal persistence will play an important role in the future of scalable information management is given.
Abstract: The subject of this thesis is scalability and persistence. A convergence of computing and communications technologies has lead to the ‘information explosion’. Demand for information has grown at an unprecedented pace, placing pressure on the scalability of information servers. At the same time there has been a revolution in switching technology which has seen the once exotic tightly coupled distributed memory computer become widely available through commodity components. These two developments in computing and communications technologies come together, the former bringing with it the challenge of constructing systems capable of scaling to address the spiraling demand for information, and the latter offering a scalable hardware architecture upon which such systems can be based. The most elegant approach to persistent data management lies in the use of orthogonal persistence. Orthogonally persistent programming languages bring together the disparate concerns of programming languages and databases by making the persistence of data a property orthogonal to all others. However, while users are presented with a unified view of the concerns, implementers of orthogonally persistent programming languages must confront the disparity head-on. The quest to design efficient, scalable, orthogonally persistent systems represents a bringing together of the challenge of constructing systems capable of scaling, with the challenge of constructing orthogonally persistent systems. This raises the deeper question as to whether there exists a generalized framework for scalable persistent system design. The framework will bring together the fundamental concerns of concurrency, replication, coherency, latency, and stability. The major result in this thesis is the description of such a framework. The fundamental concerns are met through a reference architecture based on caching, atomicity, and a layered software architecture. The framework has been realized in the form of the Persistent Store Interface (PSI). The effectiveness of PSI for scalable persistent system construction is demonstrated through a number of experiments with PSI prototypes, both stand-alone and distributed. In addition, two supporting experiments are described, one examining the issues of designing scalable stores that present users with a single store image and the other examining mechanisms for scalable coherency and recovery. The development of a generalized and practical framework for scalable persistent system design in this thesis gives cause for optimism that orthogonal persistence will play an important role in the future of scalable information management.

Book ChapterDOI
TL;DR: This paper introduces the approach to recover and describe a system's architecture: different aspects of a system (i.e. architectural properties) are recovered and then described, and an example illustrating the applicability of the framework is presented.
Abstract: The increasing interest in the software architecture of systems stems from the need to generate product families, to facilitate the reuse of components, to better understand systems and to redocument them This paper introduces our approach to recover and describe a system's architecture: different aspects of a system (ie architectural properties) are recovered and then described The recovery process focuses on architectural properties, such as safety and variance and their description, but not on the recovery of a complete system's architecture Such a property-driven recovery allows to incrementally investigate those aspects of a system that are of special interest for the recovery purpose Additionally the paper presents our architecture recovery framework and process, and an example illustrating the applicability of our framework

Proceedings ArticleDOI
11 Oct 1998
TL;DR: The purpose of this investigation is to show that the architecture can perform latent learning, and that this knowledge can be used to improve the performance of subsequent reward-based learning phases.
Abstract: This paper describes a fresh interpretation of, and experimental modifications to, an architecture which has arisen from the author's previous work (1997). The previous published work concentrates upon the learning structure adopted, which is based on an adaptive heuristic critic. This paper focuses upon the nature of the knowledge representation acquired by the architecture, and in particular on the case of "latent" or "reward-free" learning. The purpose of this investigation is to show that our architecture can perform latent learning, and that this knowledge can be used to improve the performance of subsequent reward-based learning phases. The results of simulation experiments which have been devised to test performance under these circumstances are given.

Proceedings ArticleDOI
01 Jun 1998
TL;DR: This paper describes both the structure and the architecture of a pedagogic computer named "Máquina Rudimentaria", designed to be used in a first course on logic design or computer architecture.
Abstract: This paper describes both the structure and the architecture of a pedagogic computer named "Maquina Rudimentaria". This computer has been designed to be used in a first course on logic design or computer architecture. Therefore, the orthogonality and simplicity have been the major goals. The description of the computer includes the definition of both the machine and the assembly language, the implementation of the data-path and the optimization of the control unit. A programming framework has also been designed to provide the development of small complexity programs in assembly language, its compilation and detailed simulation on the proposed architecture.

Book ChapterDOI
TL;DR: This paper shows how to model variations within a domain model and describe the mechanism for mapping variations into the architecture component interfaces and applied described techniques in domain engineering projects in the facility reservation and software project domains.
Abstract: A reference architecture implements features that can be reused, after possible customizations, across members of a system family. Family members display similarities but they also vary one from another in user, design or implementation requirements. In this paper, we describe techniques that allow us to handle certain classes of variations at the architecture level and to build systems by customizing the architecture rather than by implementing variations at the code level. To achieve this end, we model variations within a domain model and then define how variations in system requirements affect the configuration of a reference architecture at different levels of granularity and abstraction. During system engineering, we customize a reference architecture by selecting architecture components to be included into the target system, by customizing component interfaces and, finally, by modifying components at the code level. In this paper, we show how we model variations within a domain model and describe the mechanism for mapping variations into the architecture component interfaces. We applied described techniques in our domain engineering projects in the facility reservation and software project domains.

Proceedings ArticleDOI
21 Mar 1998
TL;DR: The dynamic predictive memory architecture is an architecture for integrating natural language understanding with dynamic task execution and issues which became evident while implementing a control station for a free-flying camera.
Abstract: The dynamic predictive memory architecture (DPMA) is an architecture for integrating natural language understanding with dynamic task execution. We describe the architecture and its components, as well as issues which became evident while implementing a control station for a free-flying camera.

Proceedings ArticleDOI
19 Aug 1998
TL;DR: This work introduces a flexible and extensible language called Architecture Structure Description Language (ASDL) developed for describing structural aspects of software architectures and their properties and focuses on the domain of embedded real time systems that have to meet certain timing and safety constraints.
Abstract: To support architecture based development, different modeling notations and languages, so called architecture description languages (ADLs), have been designed. To be of help in the development process, software architectures must be described in a complete and consistent manner but without being overloaded with information provided to the system stakeholders. Current architecture description languages provide information about software architectures in a domain independent way. This may lead to inappropriate and incomplete descriptions of software architectures. We introduce a flexible and extensible language called Architecture Structure Description Language (ASDL) developed for describing structural aspects of software architectures and their properties. We thereby focus on the domain of embedded real time systems that have to meet certain timing and safety constraints. The language was developed in an architecture recovery process of a real world Train Control System (TCS) and has been used to describe and reason about TCS's architecture.