83 research outputs found
Using an Architecture Description Language to Model a Large- Scale Information System – An Industrial Experience Report
An organisation that had developed a large Information System wanted to embark on a programme of significant evolution for the system. As a precursor to this, it was decided to create a comprehensive architectural
description. T his undertaking faced a number of challenges, including a low general awareness of software modelling and software architecture practices . The approach taken for this
project included the definition of a simple, specific, architecture description language. This paper describes the experiences of the project and the ADL created as part of it
Recommended from our members
A component-based product line architecture for workflow management systems
This paper presents a component-based product line for workflow management systems. The process followed to design the product line was based on the Catalysis method. Extensions were made to represent variability across the process. The domain of workflow management systems has been shown to be appropriate to the application of the product line approach as there are a standard architecture and models established by a regulatory board, the Workflow Management Coalition. In addition, there is a demand for similar workflow management systems but with some different features. The product line architecture was evaluated with Rapide simulation tools. The evaluation was based on selected scenarios, thus, avoiding implementation issues. The strategy that has been used to populate the architecture and experiment with the product line is shown. In particular, the design of the workflow execution manager component is described
A Middleware Framework for Constraint-Based Deployment and Autonomic Management of Distributed Applications
We propose a middleware framework for deployment and subsequent autonomic
management of component-based distributed applications. An initial deployment
goal is specified using a declarative constraint language, expressing
constraints over aspects such as component-host mappings and component
interconnection topology. A constraint solver is used to find a configuration
that satisfies the goal, and the configuration is deployed automatically. The
deployed application is instrumented to allow subsequent autonomic management.
If, during execution, the manager detects that the original goal is no longer
being met, the satisfy/deploy process can be repeated automatically in order to
generate a revised deployment that does meet the goal.Comment: Submitted to Middleware 0
On the Notion of Abstract Platform in MDA Development
Although platform-independence is a central property in MDA models, the study of platform-independence has been largely overlooked in MDA. As a consequence, there is a lack of guidelines to select abstraction criteria and modelling concepts for platform-independent design. In addition, there is little methodological support to distinguish between platform-independent and platform-specific concerns, which could be detrimental to the beneficial exploitation of the PIM-PSM separation-of-concerns adopted by MDA. This work is an attempt towards clarifying the notion of platform-independent modelling in MDA development. We argue that each level of platform-independence must be accompanied by the identification of an abstract platform. An abstract platform is determined by the platform characteristics that are relevant for applications at a certain level of platform-independence, and must be established by balancing various design goals. We present some methodological principles for abstract platform design, which forms a basis for defining requirements for design languages intended to support platform-independent design. Since our methodological framework is based on the notion of abstract platform, we pay particular attention to the definition of abstract platforms and the language requirements to specify abstract platforms. We discuss how the concept of abstract platform relates to UML
A Historical Perspective on Runtime Assertion Checking in Software Development
This report presents initial results in the area of software testing and analysis produced as part of the Software Engineering Impact Project. The report describes the historical development of runtime assertion checking, including a description of the origins of and significant features associated with assertion checking mechanisms, and initial findings about current industrial use. A future report will provide a more comprehensive assessment of development practice, for which we invite readers of this report to contribute information
Recommended from our members
Intrusion Management Using Configurable Architecture Models ; CU-CS-929-02
Enhancing Architectural Mismatch Detection with Assumptions
Detecting software architecture inconsistencies is a critical issue in software design. Software systems are described in terms of components, component behavior and interaction and mismatch detection is explored through techniques based on behavior analysis. Integration problems, however, are not only caused by behavioral mismatch: components make assumptions about their environment to guarantee functional and non-functional properties. If the actual deployment environment of each component does not satisfy its assumptions, component and system properties may not hold. In this work we propose to extend the idea of architectural mismatch to include the notion of assumption. We concentrate on a subset of possible assumptions and show how software architects can benefit from using them. We also present a discussion on how architecture description languages (ADLs) can be extended to include assumptions. 1
- …