-
[show abstract]
[hide abstract]
ABSTRACT: An analysis of the current practice for representing architectural views reveals that they focus mainly on functional concerns and are limited when considering quality concerns. We introduce the recovery style for modeling the structure of the system related to the recovery concern. The recovery style is a specialization of the module viewtype in the Views&Beyond approach. It is used to communicate and analyze architectural design decisions and to support detailed design with respect to recovery. We illustrate the style for modeling the recovery views for the open-source software, MPlayer.
Software Architecture, 2008. WICSA 2008. Seventh Working IEEE/IFIP Conference on; 03/2008
-
[show abstract]
[hide abstract]
ABSTRACT: Aligning adequately business requirements and software functionality as well as achieving 'loose coupling' for service functionalities, are identified challenges relevant to service-oriented software design. Furthering previous related work, we propose in this paper an application design process that, taking the above challenges into account, addresses systematically and separately business requirements, the identification of (desirable) service functionalities, and their mapping onto technology platforms. With respect to service modeling, a communication pattern has been identified that is relevant and useful. As for the enforcement of social restrictions in the application functionality, semiotic norms are helpfully applied. And finally, 'loose coupling' is achieved in an orchestration-driven way.
e-Business Engineering, 2007. ICEBE 2007. IEEE International Conference on; 11/2007
-
[show abstract]
[hide abstract]
ABSTRACT: Aspect-oriented software development has focused on the software life cycle's implementation phase: developers identify and capture aspects mainly in code. But aspects are evident earlier in the life cycle, such as during requirements engineering and architecture design. Early aspects are concerns that crosscut an artifact's dominant decomposition or base modules derived from the dominant separation-of-concerns criterion, in the early stages of the software life cycle. In this article, we describe how to identify and capture early aspects in requirements and architecture activities and how they're carried over from one phase to another. We'll focus on requirements and architecture design activities to illustrate the points, but the same ideas apply in other phases as well, such as domain analysis or in the fine-grained design activities that lie between architecture and implementation
IEEE Software 02/2006; · 1.51 Impact Factor
-
[show abstract]
[hide abstract]
ABSTRACT: We propose a Software Architecture Reliability Analysis (SARA) approach that benefits from both reliability engineering and scenario-based software architecture analysis to provide an early reliability analysis of the software architecture. SARA makes use of failure scenarios that are prioritized with respect to the user-perception in order to provide a severity analysis for the software architecture and the individual components.
Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on; 02/2005
-
IEE Proceedings - Software 09/2004; 151(4):153- 155. · 0.40 Impact Factor
-
B. Tekinerdogan
[show abstract]
[hide abstract]
ABSTRACT: Software architecture analysis methods aim to predict the quality of a system before it has been developed. In general, the quality of the architecture is validated by analyzing the impact of predefined scenarios on architectural components. Hereby, it is implicitly assumed that an appropriate refactoring of the architecture design can help in coping with critical scenarios and mending the architecture. This paper shows that there are also concerns at the architecture design level which inherently crosscut multiple architectural components, which cannot be localized in one architectural component and which, as such, can not be easily managed by using conventional abstraction mechanisms. We propose the aspectual software architecture analysis method (ASAAM) to explicitly identify and specify these architectural aspects and make them transparent early in the software development life cycle. ASAAM introduces a set of heuristic rules that help to derive architectural aspects and the corresponding tangled architectural components from scenarios. The approach is illustrated for architectural aspect identification in the architecture design of a window management system.
Software Architecture, 2004. WICSA 2004. Proceedings. Fourth Working IEEE/IFIP Conference on; 07/2004
-
[show abstract]
[hide abstract]
ABSTRACT: Changes in requirements may have a severe impact on development processes. For example, if requirements change during the course of a software development activity, it may be necessary to reschedule development activities so that the new requirements can be addressed in a timely manner. Unfortunately, current software development methods do not provide explicit means to adapt development processes with respect to changes in requirements. The paper proposes a method based on Markov decision theory, which determines the estimated optimal development schedule with respect to probabilistic product demands and resource constraints. This method is supported by a tool and applied to an industrial case.
IEE Proceedings - Software 05/2004; · 0.40 Impact Factor
-
[show abstract]
[hide abstract]
ABSTRACT: The separation of concerns principle aims at decomposing a given design problem into concerns that are mapped to multiple independent software modules. The application of this principle eases the composition of the concerns and as such supports composability. Unfortunately, a clean separation (and composition of concerns) at the design level does not always imply the composability of the concerns at the implementation level. The composability might be reduced due to limitations of the implementation abstractions and composition mechanisms. The paper introduces the notion of composition anomaly to describe a general set of unexpected composition problems that arise when mapping design concerns to implementation concerns. To distinguish composition anomalies from other composition problems the requirements for composability at the design level is provided. The ideas are illustrated for a distributed newsgroup system.
01/2003;
-
01/2002: pages 357-384; , ISBN: 0792375769
-
[show abstract]
[hide abstract]
ABSTRACT: It is generally acknowledged that separation of concerns is a key requirement for effective software engineering: it helps in managing the complexity of software and supports the maintainability of a software system. Separation of concerns makes only sense if the realizations in software of these concerns can be composed together effectively into a working program. The ability to compose systems from independently developed components that can be adapted and extended easily is a long-standing goal in the software engineering discipline. However, both research and practice have shown that composability of software is far from trivial and fails repeatedly. Typically this occurs when components exhibit complex behavior, in particular when multiple concerns are involved in a single component. We believe that, to address the composability problems, we need a better understanding of the requirements involved in successful composition, and in addition define the situations where composition fails. To this aim, in this paper we introduce a number of requirements for designlevel composability and define a category of composition problems that are inherent for given composition models, which we term as composition anomalies.
Electronic proceedings at ACM OOPSLA'2000 workshop on Advanced Separation of Concerns, Minneapolis, USA; 01/2000
-
[show abstract]
[hide abstract]
ABSTRACT: Software is rarely designed for ultimate adaptability, performance
or reusability but rather it is a compromise of multiple considerations.
Even for a simple architecture specification, one may identify many
alternative implementations. The paper makes an attempt to depict the
space of implementation alternatives of architectures, and to define
rules for selecting them. The applicability of this approach is
illustrated by means of a simple design problem
Object-Oriented Real-Time Distributed Computing, 1999. (ISORC '99) Proceedings. 2nd IEEE International Symposium on; 02/1999
-
01/1999: pages 169-198; , ISBN: 0-471-24875-4
-
01/1999;
-
OOPSLA Workshop on Product Lines, Atlanta, USA; 01/1997
-
01/1997: pages 12-23; , ISBN: 3920993675
-
[show abstract]
[hide abstract]
ABSTRACT: current and future trends in computer science require extensions to Smalltalk. Rather than arguing for particular language mechanisms to deal with specific requirements, in this position paper we want to make a case for two requirements that Smalltalk extensions should fulfill. The first is that the extensions must be integrated with Smalltalk without violating its basic object model. The second requirement is that extensions should allow for defining objects that are still adaptable, extensible and reusable, and in particular do not cause inheritance anomalies. We propose the composition filters model as a framework for language extensions that fulfills these criteria. Its applicability to solving various modeling problems is briefly illustrated. 1. Motivation and approach Despite the severe competition in the language market, Smalltalk remains as one of the major players among commercial object-oriented languages. This may be attributed to Smalltalk's pureness as an object-o...
10/1996;
-
Workshop, San Jose, USA; 01/1996
-
Memoranda informatica - University of Twente, Department of Computer Science. 01/1995;
