Designing Non-Functional Properties

1. Designing Non-Functional Properties • Def 1: (author’s) A non-functional property of a software system is a constraint on the manner in which the system implements and delivers the functionality • Def2: (mine) A non-functional property of a system is a constraint placed on the system’s behavior and/or construct. • Non-functional properties are usually • difficult to define • possibly multi-dimensional (has sub-characteristics) • do not have “universally accepted” definition • difficult to measure (designing meaningful metric is “hard”) • Sometimes, optimizing one may cause a conflict with others (prioritization is important) Try defining complexity , reliability or usability

2. Some “common” Non-Functional Properties • Reliability • Security • Efficiency • Availability • Maintainability • Complexity • Scalability • Usability • Reusability • Adaptability • Dependability (this is a composite property) • ---- we will cover those How would we “design” for these properties when they are not well defined? Is there some guideline?

3. Efficiency (definition) • Efficiency is a characteristic that reflects a software system’s ability to meet its “performance requirements” (throughput, response time, etc.) while minimizing its usage of the resources in its computing environment. (It is a measure of the system’s resource usage economy.) • Assuming that the system functions correctly • We will explore the characteristic in terms of 3 aspects: • components • connectors • configuration

4. Efficiency (design guidance) • Component Guidance: • Keep component size small to serve single purpose and single need (resembles the notion of “cohesion” property) ; this will eliminate some “extra” resources that may not be needed. • Keep component interface simple and compact; having complex and broad interface may drag in extra resources such as adaptors and wrappers • This guideline needs to be applied cautiously so that other properties such as scalability or reusability are not impacted • This guideline may also be viewed in terms of “coupling”- (content, common, etc.) • Allow multiple interfaces to the same functional component (see figure on page 453 of your text) • Separate processing component from data, allowing more efficient design of processing algorithm and more efficient data design (BUT --- is this counter to OO design?!) • Separate data from meta data (e.g. data format), making the movement of data more efficient • this consideration is especially relevant for distributed systems where the meta data may be sent once and the actual data may be repeatedly sent without the meta data; the representation (rendering) of data may be done at the receiving end

5. Efficiency (design guideline) • Connector Guidance: • Careful selection of connectors - ensuring that there is no “extra” functionalities embedded --- selecting simple and specific ones for connecting just 2 components while more complex ones (with redundancy) may be needed for real-time and life threatening case • Use broadcast connectors with caution – not always needed even though it is easier to connect; use alternate connectors such as publish-subscribe mechanism to connect to just the subscribers. • Use asynchronous interaction whenever possible – synchronous processing ties up all the resources and many are in “wait” state; note that some asynchronous processing is such that resources are just put into “suspense state” and not really freed up. • Use location transparency judiciously – connectors that provide location transparency may be a performance “hog”; sometimes it is better to distinguish local from remote connectors, even at the expense of some complexity.

6. Efficiency (design guideline) • Configuration guidance: • Keep frequently interacting components “close” – use less indirection if possible; especially beware of the layered style where there may be multiple layers to go through until the desired layer is reached. • Place connectors with care – use multiple specialized connectors to connect components that are close to each other and only broad, universal connectors when necessary (because the universal connectors tend to use unnecessary resources). • Consider the architecture style and patterns choices – i) asynchronous interactions such as publish-subscribe may not work for real-time, ii) large repository and blackboard architecture may be cause a memory problem, iii) decompose and compose streams of data is costly, iv) pipe-filter and batch processing styles are not a good fit for data that needs to be delivered incrementally

7. Complexity (definition) • Def 1: (IEEE) Complexityis thedegreeto which a software system or one of its component has a design or implementation that is difficult to understand and verify. • Whose definition do we use to gauge “difficult” to understand? • Def 2: (text author) Complexity is a software system’s property that is proportional to the size of the system, the number of constituent elements, the size and internal structure of each element, and the number and nature of the elements interdependence. • What is size (loc ?; number of modules?; etc.) • What is internal structure ? (loop, case, etc.? data structure?) • What is interdependencies? (calls?, passing parameters?, using db?) Your thoughts on “Complexity” attribute ? ------

8. Complexity (design guide) • Component guidance: • Separate concerns into different components – abstraction, modularity and separation of concern is the basis for this; when all other parameters are equal, the component of smaller size is less complex. • Different concerns (functionality) should be placed in different components, or component should be cohesive • A large number of different types of components causes increase in interdependence, or coupling • Keep functionality inside the component, not interaction • Move the interaction, or coupling, out of component and into the connectors • Keep component cohesive – single purpose and self contained • There are many ways to measure this structural property of cohesion; each method should be cohesive (intra-method cohesion) and so should the whole class 9inter-method cohesion). • Beware of “off-the-shelf component – these are often made for universal usage and thus “large” and complex • Insulate process component from data change – data formats often change and processing should be shielded from these complexities

9. Complexity (design guidance) • Connectors guidance: • Treat connectors explicitly – application-dependent interaction and data should be separated from application-independent interactions; application independent interactions are candidates to be placed into the connectors • Keep only application-independent interaction facilities inside the connectors • Separate interaction concerns (functionalities) into different connectors – there may be different connector concerns, in which case separate those concerns into different connectors (e.g. transmission connector and data compaction connectors should be separated out as opposed to merged into one --- cohesion of connector) • Restrict interactions facilitated by each connector – ensure that unnecessary components are not brought into the interaction by the connector • Beware of off-the-shelf connectors – same concern as off-the-shelf component

10. Complexity (design guidance) • Configuration guidance: • Eliminate unnecessary dependencies – the less number of components and connectors the smaller the potential number of interaction paths, thus less complexity. • Manage all dependencies explicitly • Use hierarchical decomposition and composition – this approach gives us a more organized way to “grouping” of components and connectors and the over-all configuration

11. Scalability and Heterogeneity (definition) • Definition: Scalability is the capabilityof a software system to be adapted to meet new requirements of size or scope. • Ability to support larger and more complex systems without compromising too much complexity and performance • Note performance speed is not part of scalability definition here • We are dealing with scalability of scope, meaning adapting to heterogeneity and portability (adaptability is defined later!) • Def 1: Heterogeneity is the characteristics of the system consisting of disparate constituents or functioning in disparate computing environment. • Def 2: Heterogeneity is the ability to i) consist of multiple disparate constituents or ii) function in disparate computing environment • Def 3: portability is a special case of Heterogeneity – ability to execute on multiple platforms with minimal modification and minimal degradation of system characteristics.

12. Scalability (design guidance) • Component guidance: • Give each component a clearly defined single purpose – this allows “growth” and future changes a lot easier to handle; this same guideline (component cohesion) appears repetitively. • Give each component simple and understandable interface – allows adding new component to interact with existing ones easier. • Do not burden components with interaction responsibilities – keep interaction responsibilities in the connectors so that the above first rule is met. • Avoid unnecessary heterogeneity - this complicates and decreases the possibilities of adding new components that can interact with the existing ones • Distribute data source – this allows the scaling up of size and amount of data where a single centralized data base may not support the scaled up number of users • Replicate data when necessary – this also allows the support of growing number of distributed users Note that some of these are starting to repeat from earlier property guidance

13. Scalability (design guidance) • Connectors guidance: • Use explicit connectors - also needed for a lot of properties mentioned earlier • Give each connector a clearly defined responsibility • Choose the simplest connector suited for the task • Be aware of direct and indirect dependency differences - direct dependencies between two components and the connector are simpler to understand and design, but scaling up would mean duplicating the connectors or possibly a more complex design; indirect dependencies such as a data base may grow independently of the scaling up of functions ---- (remember, however, common coupling is viewed as worse than data coupling!) • Do not place application functionality inside the connector • Leverage explicit connectors to support data scalability – connectors that deal with buffering, caching, etc. of data are more likely to allow growth of data or number of users.

14. Scalability (design guidance) • Configuration guidance: • Avoid system bottleneck – look for configuration that has a potential connector bottleneck or a component bottleneck; scaling up other parts of the system would make the bottleneck worse. • Take advantage of parallel capabilities – this would require independence in computation and independence of data requirements; design configuration with the independence in mind • Place data source close to the data consumers – provides performance advantage for growth • Make distribution transparent (location transparency) – makes growth a lot easier, but there is a price to pay for other properties such as efficiency • Choose architecture style carefully - ensure that the architectural style such as publish-subscribe is considered for scalability.

15. Adaptability (definition) • Adaptability is a software system’s abilityto satisfy new requirements and adjust to new operating conditions during its lifetime • This definition is very similar to scalability (which was mostly size and scope), but adaptability (any new requirements and new operating environment) is more general than scalability

16. Adaptability (design guidance) • Component (guidance) --- similar to scalability & the tone is to keep component complexity down, cohesion high, and coupling low • Give each component a single clearly defined purpose • Minimize component interdependence • Avoid burdening component with interaction responsibilities • Separate processing from data • Separate data from meta-data

17. Adaptability (design guidance) • Connector guidance – connectors are extremely important to this characteristic of adaptability since connectors are really “adaptors” • Give each connector a clearly defined responsibility • Make connectors flexible – note that this may conflict with other properties • Support connector composability – this may introduce complexity and other constraints, but clearly gives “extensibility” to the design • Be aware of difference in direct and indirect dependencies

18. Adaptability (design guidance) • Configuration guidance: • Leverage explicit connectors • Make distribution transparent (location transparency) – same comment as for scalability ----- it may conflict with efficiency • Be aware of the different architecture styles

19. Dependability (definition) • (Author) Dependability is a really a composite non-functional property, made up of several sub-properties: • reliability, • availability, • robustness, • fault-tolerant, • survivability, • safety and • security. (addressed separately in Chapter 13) (I believe that each of these sub-properties, not just security, should be considered separately.)

20. More Non-functional Sub-Property Definitions • Reliability is the probability that the system will perform according to requirements, under specific design limits, without failure for a specified period of time. • Availability is the probabilitythat the system is operational at any particular instance of time • Robustness is the ability to respond adequately to unanticipated runtime conditions. • What is considered “adequate” ? • How is this different from Scalability? (anticipated vs unanticipated) • Fault-tolerance is the ability to respond gracefully to run-time failure • What is considered “gracefully”? (treat all failure severities the same?) • Failures may occur : in system environment; in components; in connectors; connector-component. • Survivability is the ability to recognize, resist, recover from , and adaptto mission-compromising threats. Note threats may be from i) attacks, ii) failures, or iii) accidents • Safety is the ability to avoid failures that will result in severe damages such as loss of life, injury, loss of property, or destruction of property. Note that many of these are abilities --- does that translate to functionalities?

21. Dependability (design guidance) • Component guidance: (Note that we can seldom develop 100% reliable and fault-tolerant component.) But ---- • Carefully control external component interdependencies amongcomponents; making the component interfaces explicit and minimal (loose coupling among components) • Provide reflection capabilities (functionalities) in components: include functionalities that will allow others to query the component states: note that this may conflict with earlier attributes such as efficiency • Provide suitable exception handling mechanism • Specify the component’s “key” state invariants in the component design

22. Dependability (design guidance) • Connector guidance • Employ connectors that strictly control component dependencies • Insulate components from each other • Provide appropriate component interaction guarantees • Ensure that the component data is transmitted • Ensure that the component interactions are guaranteed for i) at least once, ii) at most once, iii) exactly once • Support dependability techniques via advanced connectors • Some advanced connectors can allocate “replacement” component when one fails • Some may cache the data and still deliver partial inforamtion when the data source component fails

23. Dependability (design guidance) • Configuration guidance • Avoid single point of failure • Do not have one component/connector which many others dependent on; this also cause potential bottleneck in performance. (minimize the fan-ins to any one or a small set of components) • Provide back-ups of critical functionality and/or data • This obviously depends on other properties such as efficiency, complexity, etc. • This is clearly asking for more functionality • Support non-intrusive system health monitoring • Embed system monitoring functionalities in components or connectors • Support Dynamic Adaptation • This is not easy to do ---- lots of extra functionalities with uncertain results