Building Systems out of Available Components: Quality and Adaptation Considerations

Seminar

Author: Tony Gillan (B.InfTech)
Date: September 2002
Subject: 6190CIT : Honours Research Project
School: School of Computing and Information Technology
University: Griffith University
Campus: Nathan, Queensland, 4111, Australia
Contact: [email protected]
Final Dissertation: Download here

S2. 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

S3. Approach

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

S4. Solution

1. Quality Attribute Specification
   1. Determine standard representation (SQuaRE)
   2. Trace/embed representation within architecture
   3. Attach architecture to component product
2. Quality Attribute Determination
   1. Identify attributes within architecture (Behavior Trees)
   2. Determine effects of component integration on quality attributes
   3. Determine overall system quality (iteration)

S5. Quality Attributes

• Functional Requirements
  • define behaviour of individual functionality of the system
• Non-functional Requirements
  • Define overall behaviour of the system

S6. Quality Attribute Research

• Gilb(1988)
• Deutsch & Willis(1988)
• ISO9126(1991)
• Abel & Rout (1993)
• Dromey (1996)
• Bass(1998)
• Wiegers(1999)
• SQuaRE(2002)

S7. 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

S8. SQuaRE – Quality in the Lifecycle

S9. 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

S10. Component Integration & Quality

• Software Component Re-use
  • Commercial Off-The-Shelf (COTS)
  • Internal Product Line

1. Review Integration Lifecycle
2. Augment components to allow for quality requirement specifications.
3. Determine quality attributes of overall integrated systems.

S11. COTS System Integration Lifecycle

S12. COTS Component Qualification Phase

• current qualification process (SEI)

S13. 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.

S14. Component Architecture Development

• Behaviour Tree Integration Process

S15. Component Augmentation

• Embedding the Behaviour Tree Architecture

S16. Updated COTS Lifecycle

• Traceability of all requirements

S17. Component Adaptation Phase

• Comparing/Modifying Behaviour Trees

S18. Comparing Behaviour

S19. 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

S20-S25.

S26. Equivalency Results

S27. Quality Attributes in Behaviour Trees

• Safety & Reliability
  • Mine-Pump, Cruise Control (Dromey)
  • Industrial Press (Xuelin)
• Security (Taylor)
• Changeability (Wen)
• Usability
  • Calytrix

S28. 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.

S29. 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
• 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.

S31. 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.

 S32. 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.