Topic
Database-centric architecture
About: Database-centric architecture is a research topic. Over the lifetime, 1799 publications have been published within this topic receiving 48836 citations.
Papers published on a yearly basis
Papers
More filters
••
23 Oct 2009TL;DR: The notion of architectural scripting (ASL) is detailed as a way to model the dynamic aspects of runtime and deployment-time software architecture, complementary to the ability of architecture description languages to model architectures statically.
Abstract: We detail the notion of architectural scripting (ASL) as a way to model the dynamic aspects of runtime and deployment-time software architecture. This is complementary to the ability of architecture description languages to model architectures statically in that we define scripting operations to modify architectures at runtime. The scripting operations have as verification of the approach been implemented in an interpreter bundle on the OSGi platform. This implementation is used in our self-management system for generating correct reconfiguration plans in a self-managed system.
10 citations
••
08 Apr 2002TL;DR: This work uses SAAM to analyze the architecture of a nuclear simulation system, and finds the method to be of great help when selecting the architecture alternative to use, and to draw attention to the importance of software architecture in large.
Abstract: The Software Architecture Analysis Method (SAAM) is a method for analyzing architectural designs, providing support in the design process by comparing different architectures and drawing attention to how a system's quality attributes are affected by its architecture. We used SAAM to analyze the architecture of a nuclear simulation system, and found the method to be of great help when selecting the architecture alternative to use, and to draw attention to the importance of software architecture in large. It has been recognized that the quality properties of a system is to a large extent determined by its architecture; there are, however, other important issues to consider that belong to "lower" design levels. We describe how detailed technical knowledge affected the design of the architecture, and show how the development process in large, and the end product can benefit from taking these issues into consideration already during the architectural design phase.
10 citations
••
05 May 2010TL;DR: The Data Distribution Service specification provides a totally decentralized data-centric approach with real-time quality of service support, and is a perfect base upon which to develop a framework for the integration of real- time distributed architectures.
Abstract: In recent times real-time distributed systems have definitively become peer-to-peer organized. The common interactions are those of different real-time components dealing with sensors or actuators, implementing controllers, performing monitoring and surveillance tasks, and interacting between them in a dynamic decentralized way. There is a need for mechanisms that allow the integration of these independent components, saving development time while keeping their real-time capability. Services and events, thanks to their decoupled nature are perfect candidates for supporting these architectures. The data centric approach goes even farther, introducing a global data space that allows a flexible, decoupled and scalable coordination environment over which services and events can be added as specific interactions mechanisms inside this global data space, in order to support all the architectural possibilities. The Data Distribution Service specification provides a totally decentralized data-centric approach with real-time quality of service support. It is a perfect base upon which to develop a framework for the integration of real-time distributed architectures.
10 citations
••
23 Aug 2010TL;DR: An approach that considers variation in systems and system architectures according to the kind of relation among the variants in the software family, based on whether the system architecture remains constant (architecture-based variation), or whether the architecture itself is variable, i.e. the variants do not share a common architecture.
Abstract: This paper presents an approach that considers variation in systems and system architectures according to the kind of relation among the variants in the software family. The approach highlights why it is beneficial to consider such different variation relations separately and gives examples of what these relations may be.Two main categories of variation relations are presented, based on whether the system architecture remains constant (architecture-based variation), or whether the architecture itself is variable, i.e. the variants do not share a common architecture. The paper introduces several different kinds of variation families that seem to belong to these two categories, as well as yet other families comprising variants that do not neatly fit in either category, with only a subset of the variants sharing a common architecture. Each kind of variation relation is illustrated with an example software family from different domains, including operating systems (OS).
10 citations