CoreLinux++ Functional Requirement Document
Revision $Revision: 1.3 $
Last Modified : Thursday, May 11, 2000

Title : Composite Pattern

Requirement ID: 3143
Analysis References: Use Case Report, Analysis Diagrams
Design References: Class Report, Design Diagrams
Cross References: Iterator , Vistitor

1. Introduction

The Composite pattern is useful when you want a client to be able to ignore the difference between compositions of objects and individual objects or you want to represent part-whole hierarchies of objects. By composing objects into tree structures, Composite lets clients treat individual objects and compositions of object uniformly.

1.1 Deliverables Overview

For the Composite pattern there are a number of participants involved:

Component

Declares the interface for objects in the composition, implements default behavior for the interface common to all classes (as appropriate), declares an interface for accessing and managing its child components, and optionally defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.

Leaf

Represents leaf objects in the composition. A leaf has no children.

Composite

Defines behavior for components having children, stores child components, implements child-related operations in the Component interface.

The CoreLinux++ team will deliver a base Component object that does not include child management interface.

The CoreLinux++ team will deliver a templated TransparentComponent which declars child management interface.

The CoreLinux++ team will NOT deliver ConcreteComposites as they are domain defined with the implementation of a Component.

Users can utilize these as a basis for creating their own Composite implementation hierarchies outside of the libcorelinux++ library.

2. Functional Requirements

Composite and the participants will be publicly available for extension.

2.1 User Interface Specifications

NA

2.2 Product Services

NA

2.3 External Interfaces and Database Requirements

NA

2.4 Error Handling

NA

2.5 Foreseeable Functional Changes and Enhancements

Issue in whether we declare that leafs have a reference to the parent Composite or not.

3. Non-Functional Requirements

Precondition constraints: None

Postcondition constraints: None

Invarient constraints: None

3.1 Performance Requirements

NA

3.2 User Documentation and Other User Aids

This Document

Analysis Use-Case diagrams

Design class diagrams

3.3 Development Requirements

Standards: CoreLinux++ C++ Standards and Guidelines

Will be part of the libcorelinux++ shared library.

3.4 Foreseeable Non-Functional Changes

NA

4. Remarks and Guidelines for Later Life Cycle Phases

TBD

5. Term Glossary

TBD