Designing Systems to Meet Their Objectives Department of

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

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

The Overall Problem

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

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