Architectural Mismatch: Why Reuse Is So Hard
IEEE Software
Architectural Mismatch: Why Reuse Is So Hard
IEEE Software
Scenario-Based Analysis of Software Architecture
IEEE Software
Modularisation and composition of aspectual requirements
Proceedings of the 2nd international conference on Aspect-oriented software development
Software Architecture in Practice
Software Architecture in Practice
Object-Oriented Software Engineering: A Use Case Driven Approach
Object-Oriented Software Engineering: A Use Case Driven Approach
Explicit assumptions enrich architectural models
Proceedings of the 27th international conference on Software engineering
Multi-Dimensional Separation of Concerns in Requirements Engineering
RE '05 Proceedings of the 13th IEEE International Conference on Requirements Engineering
Recovering architectural assumptions
Journal of Systems and Software
Aspect-Oriented Development with Stratified Frameworks
IEEE Software
Architectural Mismatch: Why Reuse Is Still So Hard
IEEE Software
Multi-view refinement of AO-connectors in distributed software systems
Proceedings of the 11th annual international conference on Aspect-oriented Software Development
Using connectors to model crosscutting influences in software architectures
ECSA'07 Proceedings of the First European conference on Software Architecture
Domain-Driven discovery of stable abstractions for pointcut interfaces
Transactions on Aspect-Oriented Software Development IX
Hi-index | 0.00 |
In software architecture design, the end product is the combined result of a wide variety of inputs, most of which are provided by the non-technical stakeholders. These include the analysis of the problem domain, the functional and non-functional requirements, the architectural or technical constraints. However, a software architecture is typically also influenced by different, less visible factors such as the architect's prior experience and his creativity. In this paper, we focus on so-called architectural assumptions, which are key premises made by technical stakeholders in the early phases of the software development life-cycle. Often these assumptions are made silently and not documented explicitly in the description of the architecture. As a result, they introduce a certain degree of rigor in the software product that hinders the evolvability, variability, and reusability of the architectural solution as a whole and its individual building blocks. Additionally, architectural assumptions in many cases exert a crosscutting influence on the software architecture and its description. This makes it hard to discover them, assess their individual architectural impact, and treat them as first-class architectural elements. In this position paper, we explore and discuss these modularity problems in specific examples from a patient monitoring system (e-health). Furthermore, we introduce the distinction between problem-space and solution-space architectural assumptions, and we discuss their intrinsic differences.