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

Design time detection of architectural mismatches in service oriented architectures

Service Oriented Architecture (SOA) is a software component paradigm that has the potential to allow for exible systems that are loosely coupled to each other. They are discoverable entities that may be bound to at run time by a client who is able to use the service correctly by referring to the service's description documents. Assumptions often have to be made in any design process if the problem domain is not fully speci ed. If those decisions are about the software architecture of that component and it is inserted into a system with di ering and incompatible assumptions then we say that an architectural mismatch exists. Architectural styles are a form of software reuse. They can simply be used by referring to a name such as \client-server" or \pipe and lter", where these names may conjure up topologies and expected properties in the architects mind. They can also however be more rigorously de ned given the right software environment. This can lead to a vocabulary of elements in the system, de ned properties of those elements along with rules and analysis to either show correctness of an implementation or reveal some emergent property of the whole. SOA includes a requirement that the service components make available descriptions of themselves, indicating how they are to be used. With this in mind and assuming we have a suitable description of the client application it should be the case that we can detect architectural mismatches when designing a new system. Here designing can range from organising a set of existing components into a novel con guration through to devising an entirely new set of components for an SOA. This work investigates the above statement using Web Services as the SOA implementation and found that, to a degree, the above statement is true. The only element of description required for a web service is the Web Service Description Language (WSDL) document and this does indeed allow the detection of a small number of mismatches when represented using our minimal web service architectural style. However from the literature we nd that the above mismatches are only a subset of those that we argue should be detectable. In response to this we produce an enhanced web service architectural style containing properties and analysis supporting the detection of this more complete set of mismatches and demonstrate its e ectiveness against a number of case studies.EThOS - Electronic Theses Online ServiceGBUnited Kingdo