Architectural analysis is the activity of discovering important system properties using the system’s architectural model.
The analysis of architectural models can have varying goals like early estimation of system size, complexity and cost. It can include satisfaction of system requirements-both functional and non-functional, evaluation of opportunities for reusing existing functionalities etc.
Consistency is one of the goals of software analysis. Consistency is an internal property of an architectural model which is intended to ensure that different elements of that model do not contradict one another. Even if no architectural designs are invalidated during architectural design process, capturing the details of those designs during modeling may result in inconsistencies. The inconsistencies in a model include:
- Name inconsistencies: it occurs at the level of components and connectors or their constituent elements such as names of services exported by a component.
Multiple system elements and services may have similar names. E.g.: a large system may have two similarly named GUI rendering components, here determining that wrong component is accessed becomes difficult. In a java environment, attempting to access a nonexistent class or method will often result in compile time errors. Such factors which give rise to inconsistency should be avoided.
- Interface inconsistencies: it include naming inconsistency and other forms of inconsistencies. A components service name might be same as another component but their parameter list may differ.
Consider the following interface of a QueueClient component:
ReqInt: getSubQ(Natural first, Natural last, Boolean remove) returns FIFOQueue;
This interface is intended to access a service that returns the subset of a FIFOQueue between the specified first and last indices.
The QueueServer component may export two getSubQ interfaces:
ProvInt1: getSubQ(Index first, Index last) returns FIFOQueue;
ProvInt2: getSubQ(Natural first, Natural last, Boolean remove) returns FIFOQueue;
All three interfaces have identical names but the parameter list and return types are not identical. If the QueueClient and QueueServer were objects implemented in java and the provided and required interfaces denoted method invocations, the system might not even compile. The determination of whether there exists an interface inconsistency in a system depends on several factors.
- Behavioral inconsistencies: it occurs between components that request and provide services whose names and interfaces match but behaviors don’t.
Consider the interface: subtract (Integer x, Integer y) returns Integer;
This service takes two integers as input and returns their difference. It can be assumed that the operation is arithmetic but suppose the component providing this service gives a calendar subtraction operation. If requesting component expect difference between 427 and 27 will be 400, while the service treats it as subtraction of 27 days from February and return 131(January 31). An architectural model may provide a behavioral specification for the system’s components and their services.
- Interaction inconsistencies: it occurs when a component’s provided operations are accessed in a manner that violates certain interaction constraints like the order in which the components operations are to be accessed. Such constraints comprise the component’s interaction protocol. The interaction protocols are modeled using state-transition diagrams. Analyzing the system for interaction consistency consist of ensuring that a given sequence of operation request matches some sequence of legal state transitions specified by each component protocol.
- Refinement inconsistencies: it stems from the fact that a system’s architecture is frequently captured at multiple levels of abstraction. E.g.: a very high level model of the architecture may only represent the major sub-systems and their dependencies, while a lower level model may elaborate on those details of subsystems and dependencies.
and 4 others joined a min ago.
teamques10
★ 68k