41,683 research outputs found
Semantic Component Composition
Building complex software systems necessitates the use of component-based
architectures. In theory, of the set of components needed for a design, only
some small portion of them are "custom"; the rest are reused or refactored
existing pieces of software. Unfortunately, this is an idealized situation.
Just because two components should work together does not mean that they will
work together.
The "glue" that holds components together is not just technology. The
contracts that bind complex systems together implicitly define more than their
explicit type. These "conceptual contracts" describe essential aspects of
extra-system semantics: e.g., object models, type systems, data representation,
interface action semantics, legal and contractual obligations, and more.
Designers and developers spend inordinate amounts of time technologically
duct-taping systems to fulfill these conceptual contracts because system-wide
semantics have not been rigorously characterized or codified. This paper
describes a formal characterization of the problem and discusses an initial
implementation of the resulting theoretical system.Comment: 9 pages, submitted to GCSE/SAIG '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
Forum Session at the First International Conference on Service Oriented Computing (ICSOC03)
The First International Conference on Service Oriented Computing (ICSOC) was held in Trento, December 15-18, 2003. The focus of the conference ---Service Oriented Computing (SOC)--- is the new emerging paradigm for distributed computing and e-business processing that has evolved from object-oriented and component computing to enable building agile networks of collaborating business applications distributed within and across organizational boundaries. Of the 181 papers submitted to the ICSOC conference, 10 were selected for the forum session which took place on December the 16th, 2003. The papers were chosen based on their technical quality, originality, relevance to SOC and for their nature of being best suited for a poster presentation or a demonstration. This technical report contains the 10 papers presented during the forum session at the ICSOC conference. In particular, the last two papers in the report ere submitted as industrial papers
Designing Software Architectures As a Composition of Specializations of Knowledge Domains
This paper summarizes our experimental research and software development activities in designing robust, adaptable and reusable software architectures. Several years ago, based on our previous experiences in object-oriented software development, we made the following assumption: âA software architecture should be a composition of specializations of knowledge domainsâ. To verify this assumption we carried out three pilot projects. In addition to the application of some popular domain analysis techniques such as use cases, we identified the invariant compositional structures of the software architectures and the related knowledge domains. Knowledge domains define the boundaries of the adaptability and reusability capabilities of software systems. Next, knowledge domains were mapped to object-oriented concepts. We experienced that some aspects of knowledge could not be directly modeled in terms of object-oriented concepts. In this paper we describe our approach, the pilot projects, the experienced problems and the adopted solutions for realizing the software architectures. We conclude the paper with the lessons that we learned from this experience
A Framework for Evaluating Model-Driven Self-adaptive Software Systems
In the last few years, Model Driven Development (MDD), Component-based
Software Development (CBSD), and context-oriented software have become
interesting alternatives for the design and construction of self-adaptive
software systems. In general, the ultimate goal of these technologies is to be
able to reduce development costs and effort, while improving the modularity,
flexibility, adaptability, and reliability of software systems. An analysis of
these technologies shows them all to include the principle of the separation of
concerns, and their further integration is a key factor to obtaining
high-quality and self-adaptable software systems. Each technology identifies
different concerns and deals with them separately in order to specify the
design of the self-adaptive applications, and, at the same time, support
software with adaptability and context-awareness. This research studies the
development methodologies that employ the principles of model-driven
development in building self-adaptive software systems. To this aim, this
article proposes an evaluation framework for analysing and evaluating the
features of model-driven approaches and their ability to support software with
self-adaptability and dependability in highly dynamic contextual environment.
Such evaluation framework can facilitate the software developers on selecting a
development methodology that suits their software requirements and reduces the
development effort of building self-adaptive software systems. This study
highlights the major drawbacks of the propped model-driven approaches in the
related works, and emphasise on considering the volatile aspects of
self-adaptive software in the analysis, design and implementation phases of the
development methodologies. In addition, we argue that the development
methodologies should leave the selection of modelling languages and modelling
tools to the software developers.Comment: model-driven architecture, COP, AOP, component composition,
self-adaptive application, context oriented software developmen
Metamorphic Domain-Specific Languages: A Journey Into the Shapes of a Language
External or internal domain-specific languages (DSLs) or (fluent) APIs?
Whoever you are -- a developer or a user of a DSL -- you usually have to choose
your side; you should not! What about metamorphic DSLs that change their shape
according to your needs? We report on our 4-years journey of providing the
"right" support (in the domain of feature modeling), leading us to develop an
external DSL, different shapes of an internal API, and maintain all these
languages. A key insight is that there is no one-size-fits-all solution or no
clear superiority of a solution compared to another. On the contrary, we found
that it does make sense to continue the maintenance of an external and internal
DSL. The vision that we foresee for the future of software languages is their
ability to be self-adaptable to the most appropriate shape (including the
corresponding integrated development environment) according to a particular
usage or task. We call metamorphic DSL such a language, able to change from one
shape to another shape
- âŠ