DISCUSIÓN DE RESULTADOS

“No object is an island”, wrote XX [ref] several years ago. The same can be said to be true for software systems in general. All software has to interface with one or more external entities. Different from what one may suspect, it is the externally vis-

Comments SubClass1 Subclass2 AggregatedClass SuperClass (from java.awt) Aggregation AssociatedClass Generalization Generalization Association

Functionality-based Architectural Design

ible behavior of a system that is the thing that counts. All our efforts as software architects and engineers are judged from this perspective, although it is difficult to maintain this viewpoint since virtually all of our efforts are spend on the internals of software systems.

FIGURE 6.UML Sequence diagram

The entity at the other end of an interface may be located at a lower-level, a higher- level or at the same-level as the system that we are designing. Examples of lower- level entities include network interface and sensor or actuator interfaces, whereas same-level entities often are systems that address a different functional domain, but need to communicate because of system integration requirements. For instance, in the case of Securitas Larm, high-end fire-alarm system has to interface with other building automation systems to achieve more intelligent behavior. For instance, if no humans are supposed to be in one part of the building, the particle-density sen- sors should be more sensitive then when smoking persons might be walking around in that part. In the latter case, sensors should not activate the alarm when temporary peeks in particle density are detected. Higher-level entities may be system integra- tion software, e.g. in the case of the fire-alarm system, the building automation inte- gration system, or human beings, e.g. operators of the system or other users. Explicitly defining the system in terms of the functionality and quality required on its interfaces is an important starting point once the requirements by the customer

anObject anotherObject aThirdObject

msg1

msg2

msg3

msg4 _msg5

Defining the System Context

have been defined. It allows one to distribute requirements to the interfaces and to define the various quality requirements more precisely. Interface-specific require- ments allow for the specification of both operational and development quality requirements. For example, performance, real-time and reliability requirements can be expressed on the services provided on the interface. In addition, maintainability and flexibility requirements can be expressed in terms of the likely changes at the interface.

An additional reason for explicitly defining the system context and boundaries is because our experience is that there is a natural tendency to include more and more aspects during design. In the situations that explicit effort is spent on software architecture design, there generally also is an understanding that this process should be allowed to take time. Because there is no extreme time pressure, software archi- tects, in our experience, try to extend the domain of the design because each of these extensions will improve the applicability of the architecture and allow for likely future requirements to be integrated more easily. The problem, however, is that these extensions increase the design and development cost, resulting in the sit- uation where the current development project budget is partially used for mainte- nance activities in response to likely, but not certain future requirements. Management may easily react to this development using the well-known tool, i.e. strict deadlines, not allowing for a sufficiently thought-through architecture. The more fruitful approach to this is to explicitly define the system boundaries and the functional and quality requirements, requiring software engineers to stick to their appointed domain.

In the case of a software architecture design for a product-line, the definition of the system context is somewhat more complicated since products in the product-line tend to have variations in the interfaces they provide. The product-line architecture has to support the superset over all products of the interfaces, functional require- ments and quality requirements without sacrificing cost and resource efficiency for the low-end product. The latter may prove difficult to achieve in practice, but, in our experience, the reasons for these difficulties are often located in the reusable assets rather than in the architecture. Since the architecture is primarily facilitating the fulfillment of functional and quality requirements, it often quite possible to exclude or short-cut parts of the architecture for low-end products. In later chapters, we address the implementation of variability in reusable assets, including the issues related to excluding functionality for low-end instantiations of reusable compo- nents.

Functionality-based Architectural Design

•

Define the interfaces of the system to external entities. These entities may be

located at a lower level, a higher level or at the same level.

•

Associate functional and quality requirements with each interface. Both opera-

tional and development quality requirements can be associated with interfaces.

•

In the case of a product-line architecture, the variability in the interfaces sup-

ported by the various products in the product-line should be explicitly identified and specified. The cost and resource efficiency of low-end products should not be sacrificed for the requirements of high-end products.

In document UNIVERSIDAD DE GUAYAQUIL (página 64-69)