1. Building Systems out of Available Components: Quality and Adaptation Considerations
Tony Gillan (B.InfTech)
6190CIT : Honours Research Project
School of Computing and Information Technology
Griffith University
Nathan, Queensland, 4111, Australia

2. Problem
Given a statement of quality requirements for a system, how can these be allocated and defined for the identified components?
definition and specification of quality attributes
component and integrated system quality
adaptation of existing software components
Problem Statement

3. Approach quality attribute definition/quantification
1.0 High-to-Low Approach:
quality attribute definition/quantification
distill/trace quality requirements down through to the implementation
2.0 Low-to-High Approach:
identify applicable attributes of/within the architecture and trace-up to quality requirements
Problem Solution

4. Solution 1.0 Quality Attribute Specification
1.1 Determine standard representation (SQuaRE)
1.2 Trace/embed representation within architecture
1.3 Attach architecture to component product
2.0 Quality Attribute Determination
2.1 Identify attributes within architecture (Behavior Trees)
2.2 Determine effects of component integration on quality attributes
2.3 Determine overall system quality (iteration)
Problem Solution

5. 1.0 Quality Attribute Specification
Functional Requirements
define behaviour of individual functionality of the system
Non-functional Requirements
Define overall behaviour of the system
1.0 Quality Attribute Specification

6. Quality Attribute Research
Gilb(1988)
Deutsch & Willis(1988)
ISO9126(1991)
Abel & Rout (1993)
Dromey (1996)
Bass(1998)
Wiegers(1999)
SQuaRE(2002)
1.0 Quality Attribute Specification

7. Product Quality Standards
ISO9126 (1991) & ISO14596 (1995)
Product quality & evaluation
good high level description of attributes.
implies quality at implementation level.
ISO25000 (in progress) SQuaRE
Software Quality Requirements & Evaluation
no user/developer can know all quality attributes
measures quality from changing viewpoints/levels in lifecycle
suggests high/medium/low weighting scheme
1.0 Quality Attribute Specification

8. SQuaRE - Quality in the Lifecycle
1.0 Quality Attribute Specification

9. Product Certification
Software Standards
IEEE/ISO/OMG, UML/XML/MDA/CORBA
Much done in software standardisation
need to certify that people are following (OOSPICE)
need to specify when and how to record:
risks & mitigation strategies
quality attribute levels/requirements
Certification
independent 3rd party
assure that standards requirements are met
1.0 Quality Attribute Specification

10. Component Integration & Quality
Software Component Re-use
Commercial Off-The-Shelf (COTS)
Internal Product Line
Review Integration Lifecycle
Augment components to allow for quality requirement specifications.
Determine quality attributes of overall integrated systems.
2.0 Quality Attribute Determination

11. COTS System Integration Lifecycle
2.0 Quality Attribute Determination

12. COTS Component Qualification Phase
current qualification process (SEI)
is there a way of embedding/tracing these requirements into the component product?
2.0 Quality Attribute Determination

13. Genetic Software Engineering
Behavior Tree Architecture Model
proceeds in a systematic way from initial set of functional requirements to an architectural design.
provides clear representation of dynamic behaviour of component-based system.
identifies and resolves problems with requirements as early as possible.
independent of implementation issues.
2.0 Quality Attribute Determination

14. Component Architecture Development
Behaviour Tree Integration Process
2.0 Quality Attribute Determination

15. Component Augmentation
Embedding the Behaviour Tree Architecture
2.0 Quality Attribute Determination

16. Updated COTS Lifecycle
Traceability of all requirements
2.0 Quality Attribute Determination

17. Component Adaptation Phase
Comparing/Modifying Behaviour Trees
2.0 Quality Attribute Determination

18. 2.0 Quality Attribute Determination
Comparing Behaviour
2.0 Quality Attribute Determination

19. Case Studies Stack, Queue, Set (linear & unordered collections)
Concurrent Stack with Operator control
Hospital Bed allocation system
Car Space allocation system
Safety, reliability, availability, security, adaptability, portability, testability
Performance concurrency & resource efficiency

20. Basic Stack Allocation
Component Behaviour

21. Adapting the Stack for
Availability Control
(Reliability and Maintainability)

22. Adapting the Stack for
Concurrent Processes
(Performance & Resource Efficiency)

23. Adapting the Stack for
Set Behaviour
(Adaptability & Reusability)

24. Original Hospital Bed
Allocation System

25. Original Car Space
Allocation System

26. 2.0 Quality Attribute Determination
Equivalency Results
2.0 Quality Attribute Determination

27. Quality Attributes in Behaviour Trees
Safety & Reliability
Mine-Pump, Cruise Control (Dromey)
Industrial Press (Xuelin)
Security (Taylor)
Changeability (Wen)
Usability
Calytrix

28. 2.0 Quality Attribute Determination
Conclusions (1)
Quality attributes are difficult to apply
require a complete and consistent set of functional and non-functional requirements.
relate to behaviour of overall component, not just particular functionality.
different, historical categorisation of attributes.
SQuaRE uses changing quality viewpoints (in-use, external, and internal)
cannot build quality into black-box components, but can build quality into system that integrates them.
2.0 Quality Attribute Determination

29. Conclusions (2)
Architecture is the best place to determine quality attributes.
most attributes visible at architecture level
can transform/adapt architecture after implementing functional requirements
time/cost benefits
avoids implementation issues
assists certification and validation of components
Conclusions

30. Conclusions (3)
Behavior Tree model used as an Architecture Description.
clear methodology for representing and validating functional requirements
can be pruned, projected, integrated, and augmented, and transformed
quality attributes analysis requires a clear representation of dynamic behaviour of overall system.
Conclusions

31. Summary of Contributions
Identified quality attributes within Behavior Tree architectures.
Explored methods of integration and adaptation of existing architectures using Behavior Trees.
Developed an XML Schema specification of Behavior Trees, and Requirements Specifications.
Defined a process for specifying and tracing quality attributes from a set of requirements through to an architecture.
Conclusions

32. Future Research
Implement the component augmentations & interactions using JavaBeans, DCOM, etc.
Integrate component integration results with other research using Behavior Tree model.
Adapt quality attribute work with evolving MDA, OOSpice, SQuaRE etc.
Conclusions

33. Questions
Building Systems out of Available Components: Quality and Adaptation Considerations