Can architecture descriptions help prospective users to visualise the solution in terms of meeting i...
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

Peter Henderson Open Middleware Infrastructure Institute Electronics and Computer Science PowerPoint PPT Presentation


  • 83 Views
  • Uploaded on
  • Presentation posted in: General

Can architecture descriptions help prospective users to visualise the solution in terms of meeting its requirements?. Peter Henderson Open Middleware Infrastructure Institute Electronics and Computer Science University of Southampton September 2007. Abstract.

Download Presentation

Peter Henderson Open Middleware Infrastructure Institute Electronics and Computer Science

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Peter henderson open middleware infrastructure institute electronics and computer science

Can architecture descriptions help prospective users to visualise the solution in terms of meeting its requirements?

Peter Henderson

Open Middleware Infrastructure Institute

Electronics and Computer Science

University of Southampton

September 2007


Abstract

Abstract

  • Defining requirements is a complex matter. Without realising it, we often end up describing something that is too hard to visualise and may well be undeliverable.

  • Business leaders and their analysts regularly define IT requirements that are not achievable. It is as if, in engineering terms, they are requesting a 1000 metre cantilever bridge, which is way beyond current capabilities. It is not so easy to visualise software architecture, so the impossible is not so obvious.

  • This session will discuss the importance of linking requirements to architecture and using the architecture to focus on the customer's real business needs. The group discussion will focus on approaches to effectively capture and manage requirements.

  • This will be achieved by drawing on a realistic solution, a "roving autonomous vehicle" capable of being used on a Mars landing. The proposed solution will be required to focus on open systems, due to the nature of how the solution will be delivered from a consortium of independent vendors, to re-use available assets and for the ability for it to be upgradeable throughout its life.

Peter Henderson, University of Southampton


Architecture and requirements

Architecture and Requirements

  • What is therelationship between architecture [description] and requirements gathering?

  • Can we use architecture descriptions to better help prospective users visualise our solution?

  • How do top-level requirements induce lower-level requirements in a loosely-coupled modular architecture?

  • Are there architecture lessons from Open Systems/Open Source that need to be applied more broadly?

Peter Henderson, University of Southampton


Modularity upgradeability openness

Modularity, Upgradeability, Openness

  • Take it as given that large, complex systems will be modular

  • And that one of the main requirements will be upgradeability to meet evolving business requirements

  • Which in turn leads to an arguable requirement for openness in the architecture, enabling independent suppliers to contribute value-adding components.

Peter Henderson, University of Southampton


Motivating example

Motivating Example

  • This is a Roving Autonomous Vehicle. It accepts instructions in the form of a plan, which it then carries out autonomously. It is a fictional example.

Peter Henderson, University of Southampton


Structural architecture of rav1 0

Structural Architecture of RAV1.0

  • The Manager module is in charge.

  • It instructs the Power module when movement is required.

  • It instructs the Drive module when steering is required.

  • It uses information from Sensor 1 to avoid collisions.

  • It uses information from Sensor 2 to determine its own location.

  • It uses the Comms module to communicate with home.

Sensor 1

Power

Comms

Manager

Sensor 2

Drive

This is Version 1.0. The RAV has been developed through many versions, separating autonomy from more advanced functionality and opening the system to competitive supply of components.

Peter Henderson, University of Southampton


A note on notation

A note on Notation

  • Using a shorthand for UML component diagrams

  • The arrows can be read as “uses”

  • Or as interfaces, supplied by one component to another

  • Or as a place to address functional requirements

  • Components may be hardware, software or a combination of both

  • Components are potentially independently procurable

Comms

Manager

Comms

Manager

Peter Henderson, University of Southampton


Supply of rav1 0

Supply of RAV1.0

  • There are 7 components here. The six modules and the platform

  • As well as supplying the physical solutions (wheels, etc), the platform also provides the on-board networking and other infrastructural aspects.

  • Each of the 7 components is potentially separately procurable. Colour here denotes supplier.

  • Each component contains both hardware and software.

Sensor 1

Power

Comms

Manager

Sensor 2

Drive

Peter Henderson, University of Southampton


Mapping requirements onto architecture

Mapping Requirements onto Architecture

  • Requirement on RAV

    • The RAV will accept an instruction to move to a new location

  • Induced Requirement on Comms module

    • The Comms module will store received messages until they are requested

  • Induced Requirement on Manager Module

    • … etc.

  • Induced Requirement on Infrastructure

    • … etc.

Sensor 1

Power

Comms

Manager

Sensor 2

Drive

Peter Henderson, University of Southampton


Open systems

Open Systems

  • What does it mean for a system like this to be Open?

    • A specified Architecture

    • Specified Interfaces within the Architecture

    • A responsible Standards Body/Design Authority for those specifications

    • A Conformance Body?

    • Planning for evolution of requirements that meet perceived business needs

Sensor 1

Power

Comms

Manager

Sensor 2

Drive

Peter Henderson, University of Southampton


Related issues

Related Issues

  • Must meet both functional and non-functional requirements, where the latter are either qualities or constaints. As architects, we need to make trade-offs.

  • Can we draw a parallel between COTS packages and bespoke systems, where we need Architecture+Open Systems+Re-usable assets to achieve an equivalent level of early visualisation?

Peter Henderson, University of Southampton


Discussion

Discussion

  • What is the relationship between architecture [description] and requirements gathering?

  • Can we use architecture descriptions to better help prospective users visualise our solution?

  • How do top-level requirements induce lower-level requirements in a loosely-coupled modular architecture?

  • Are there architecture lessons from Open Systems/Open Source that need to be applied more broadly?

Sensor 1

Power

Comms

Manager

Sensor 2

Drive

Peter Henderson, University of Southampton


  • Login