Designing Systems to Meet Their Objectives

1. Designing Systems to Meet Their Objectives Department of Computer Science University of York, UK Iain Bate iain.bate@cs.york.ac.uk

2. Problem Statement – Origin of Work • The size and complexity of systems is growing and hence the right architecture is needed to improve: • Technology transparency • Ability to support change • Cost of verifying requirements are met • Best solution for a system is only known with hindsight • Each system has different characteristics and objectives • Objectives considered so far include: • Safety, dependability, managed change, performance • Trade-offs need to be made between good solutions for one objective and their impact on other objectives • Design assessment is needed to determine which is probably the best solution across a range of objectives • Design assessment has to work for: • Physical, logical, functional, non-functional • To support reuse and certification approach needs to capture rationale and assumptions, and support traceability

3. The Overall Problem

4. Process Steps • Architectural model is produced showing components, interactions, attributes and operations • Technique could be UML • Produce a set of objectives/claims for each interaction are decomposed in traceable manner to form arguments • Currently produced in Goal Structuring Notation (GSN) • Arguments for key properties (eg timing), objectives (eg change) • Some of the arguments can be reused in the safety arguments • From the arguments, different design choices identified • Assessment criteria derived from the arguments • Early in the design process, assessment may be qualitative when insufficient design information is available • Results of the evidence can be used as part of certification • Assessment produces design recommendations for: • Improvement of the design • Refinement of the design • Optimisation using simulated annealing

5. Potential Ways Forward • Work needs to be multi-disciplinary • Failure behaviour, timing, safety, function … • Hardware, software, control, scheduling etc • Some work has been performed but more is needed, especially on • Optimisation approaches • Fitting the technique into a systems engineering process • Information representation for • Gathering evidence in traceable manner • Specifying contracts between components • Verification techniques that support modular approaches • Integrating with best practice on fault tolerance, dependability, reliability analysis, ways of scoring whether system’s objectives are met etc • Dealing with assessment which is largely qualitative • Case study needed to • Demonstrate the technique, and • Identify potential refinements to improve reuse within the technique (e.g. arguments) and scalability • Tool support for arguments, verification techniques and optimisation making use of common information repository