Relating Problem & Solution Structures

1. Relating Problem & Solution Structures Bashar Nuseibeh & Michael Jackson Computing Department, The Open University, UK David Bush National Air Traffic Services, UK

2. The Open University • One of the world’s 11 “mega-universities”: • The UK’s largest university (200,000+ students) • Specialist in distance education and e-learning • Computing Department research areas: • Software Engineering • Human-Computer Interaction • Educational Technology

3. Requirements Denote stakeholder goals & expectations Are expressed in the vocabulary of the problem world Can conflict & change Architectures Denote systems’ structure Are expressed in terms of components & inter-connections in the solution world Should be stable & robust Requirements & Architectures

4. Problem and Solution Structures • The development process constructs: • problem structures (requirements), and • solution structures (architecture). • For large systems that develop and evolve: • there is often a discontinuity between the two structures; • this leads to poor traceability of design decisions back to requirements, and inadequate change impact analysis.

5. Research Areas • Development Processes - • There is a need for closer intertwining of requirements & architecture development. • Development Products - • There is a need to develop and relate patterns of requirements & architecture.

6. ImplementationDependence Independent Dependent General Level of Detail Detailed The “Twin Peaks” Process:weaving requirements & architectures Specification Requirements Architecture

7. Problem Frames • A problem frame defines the shape of a problem for which there is an known solution. • Separates phenomena of “world” from “machine”; • separates assumptions (domain properties) from requirements. • Simple problem frames can be composed together to produce more complex (and realistic) composite frames. • A number of basic problem frames have already been identified by Jackson (2000).

8. Components Problem and solution patterns Requirements Problem Frames Architectural Styles Design Patterns Architecture Design

9. Research Issues • Searching for and identifying (basic & composite) patterns of requirements and architectures in existing ATM systems. • Relating these patterns to provide more effective traceability and (change) impact analysis. • Using these relationships to provide more effective reuse between different ATM systems and their development.

10. Research Methodology • Case study-driven investigation • Initially, document-driven analysis • Eventually, stakeholder-driven elicitation • Precedent: working with NATS on STCA & MSAW.

11. Desirable Endpoint? • Architectural stability in the face of inevitable requirements volatility. • Maintainable systems though improved change impact analysis, traceability, and reuse. • Applicable to technical, socio-technical, and business systems?

12. Architectural Styles • Architectural styles define the shape or structure of a solution that has some known characteristics. • Describe components & interconnection types. • An architecture is a particular instance of an architectural style. • Examples: pipe-and-filter and blackboard.