Modularity, Upgradeability and Openness – How to meet Requirements in a Family of Systems Peter Henderson University of Southampton.

Slides:



Advertisements
Similar presentations
Annual Conference of ITA ACITA 2009 Realising Management and Composition of Self-Managed Cells in Body Area Networks Alberto Schaeffer-Filho, Emil Lupu,
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Introducing Campus Networks
Nocturne Requirements (Element14 discussion on UI) Caregiver 1. Essential - Mobile interface 2. Essential - Some form of user interface 3. Essential -
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
ATN 2002 London September 2002 Presented by Aloke Roy Authors: Christophe Hamel Tom Judd Ketan Nguyen Bryan Rowe Kevin Wohlers ATN AIRBORNE IMPLEMENTATION.
e-Framework Components and Responsibilities.
Microkernels How to build a dependable, modular and secure operating system?
March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
Software Engineering Techniques for the Development of System of Systems Seminar of “Component Base Software Engineering” course By : Marzieh Khalouzadeh.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Rational Unified Process
Use-case Modeling.
1 Short presentation title Name Organisation Contact details © EPoSS 2015EPoSS Brokerage Workshop on IoT Large Scale Pilots, London,
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Thee-Framework for Education & Research The e-Framework for Education & Research an Overview TEN Competence, Jan 2007 Bill Olivier,
1 SWE Introduction to Software Engineering Lecture 5.
12-1 Copyright © 2013 Pearson Canada Inc. Enhancing Decision Making Oleh : Kundang K Juman Enhancing Decision Making Oleh : Kundang K Juman CHAPTER TWELVE.
Managing International Information Systems
Developed by Reneta Barneva, SUNY Fredonia Component Level Design.
Robots at Work Dr Gerard McKee Active Robotics Laboratory School of Systems Engineering The University of Reading, UK
By N.Gopinath AP/CSE. Why a Data Warehouse Application – Business Perspectives  There are several reasons why organizations consider Data Warehousing.
Chapter 13 Starting Design: Logical Architecture and UML Package Diagrams.
April 2006Peter Henderson, University of Southampton1 The Architecture of Open Systems Peter Henderson Dependable Systems and Software Engineering and.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
3- System modelling An architectural model presents an abstract view of the sub-systems making up a system May include major information flows between.
Changing Perspective From Structured to Object-oriented.
UNIT – II ARCHITECTING WEB SERVICES. WHAT ARE WEB SERVICES ? Web Services are loosely coupled, contracted components that communicate via XML-based interfaces.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 11 Subsystem Design.
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
1 Sub-Phase Low Level Design (cont). Janice Regan, Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces.
Session 26 Modeling the Static View: The Deployment Diagram Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 27, 2011 Presented.
Hampshire Constabulary IT Sourcing Strategy Steve Vercella (Head of IT) & Martin Nel (IT Vendor Manager)
Software Architecture in Practice Architectural description (The reduced version)
Architectural Design Identifying system components and their interfaces.
Can architecture descriptions help prospective users to visualise the solution in terms of meeting its requirements? Peter Henderson Open Middleware Infrastructure.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
Welcome Experiences in the Use of MDA and UML in Developing NATO Standards 16 July 2008 Chris Raistrick, Kennedy KC.COM.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Validating Integration Requirements Diagrams for illustrative.
Computational Autonomy. Broadening the Focus Computational Autonomy is seen as a way of enlarging the narrow focus of a program, which carries out one.
1 CMPT 275 High Level Design Phase Modularization.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
Copyright © Yokogawa Electric Corporation FDT Technology “one tool for all” September 26, 2006 Yokogawa Electric Corporation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
TK2023 Object-Oriented Software Engineering CHAPTER 8 LOGICAL ARCHITECTURE.
Component Design Elaborating the Design Model. Component Design Translation of the architectural design into a detailed (class-based or module- based)
1 Here are some quotations to get an overview of the kinds of issues of interest.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
Basic Characteristics of Object-Oriented Systems
©Ian Sommerville 2007COTS-based System Engineering Slide 1 COTS-based System Engineering.
Basic Concepts Key Learning Points : The objectives of this chapter are as follows:  To provide an introduction to the basic Concepts of enterprise architectures,
OSLC PLM Reference model February Summary of the OSLC PLM Reference Model V0.2 February 22 nd 2011 Gray Bachelor Mike Loeffler OSLC PLM Workgroup.
EDI ( ELECTRONIC DATA INTERCHANGE). Strategic Impact of EDI Business processes can become more efficient Customer-supplier relationships may change more.
CS 325: Software Engineering
Slideshow1 Home About Us Case Studies Meet the Team Partners
Software Reuse Objectives
Starting Design: Logical Architecture and UML Package Diagrams
Functionality Calibrates Bump Tests Charges Prints certificates
Architecture Description Languages
Information Hidding Dr. Veton Kepuska.
Open Systems and Open Architecture – the benefits case
Presentation transcript:

Modularity, Upgradeability and Openness – How to meet Requirements in a Family of Systems Peter Henderson University of Southampton

September, 2007Peter Henderson, University of Southampton 2 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.

September, 2007Peter Henderson, University of Southampton 3 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 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton 4 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 CommsManager CommsManager

September, 2007Peter Henderson, University of Southampton 5 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 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton 6 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 1Power CommsManager Sensor 2Drive

September, 2007Peter Henderson, University of Southampton 7 Upgrade to RAV1.2 Sensor 1Power CommsManager Sensor 2Drive Sensor 1Power CommsManager Sensor 2Drive Instuments RAV1.0RAV1.2

September, 2007Peter Henderson, University of Southampton 8 Upgrade to RAV2.0 Sensor 1Power CommsManager Sensor 2Drive Instuments RAV1.2 RAV2.0 Sensor 1Power CommsManager 1 Sensor 2 Drive Instuments Manager 2

September, 2007Peter Henderson, University of Southampton 9 Upgrade to RAV2.0 cont. RAV2.0 Sensor 1Power CommsManager 1 Sensor 2 Drive Instuments Manager 2 Comms Sensor 2Instuments Manager 3 RAV2.0 AV 1.0

September, 2007Peter Henderson, University of Southampton 10 Upgrade to RAV2.2 Comms Sensor 2Instuments Manager 3 RAV2.2 The autonomous part of the vehicle is now procured separately. Two alternative autonomous vehicles are ordered, from different suppliers The rest of the RAV architecture is opened for value-adding contributions, particularly to the Manager Application One Requirement to be met by RAV3.0 is collaboration within a group of RAVs AV 1.0

September, 2007Peter Henderson, University of Southampton 11 Upgrade to RAV3.0 Comms Sensor 2Instuments Manager 4 RAV3.0 One Requirement to be met by RAV3.0 is collaboration within a group of RAVs This will require at very least a much more elaborate Manager module It may not require changes to other components The ability of third-parties to supply value-addding Manager applications creates new business for platform suppliers This leads to a strong business case for Openness AV 1.0

September, 2007Peter Henderson, University of Southampton 12 Openness Comms Sensor 2Instuments Manager 4 RAV3.0 A modular architecture such as this may be Open in the sense that independent suppliers can supply replacement components, relying on the interface specifications Open Standards are needed to de-risk this dependence on interfaces In a specific application area (such as RAVs) it would be necessary to establish this Standards Body AV 1.0

September, 2007Peter Henderson, University of Southampton 13 Open Standards Body Comms Sensor 2Instuments Manager 4 RAV3.0 The RAV Standards Body would maintain an Architecture Specification which includes … description of the behaviour of each component … description of the the interfaces to each component … and description of the chatter across these interfaces … in evolving versions AV 1.0

September, 2007Peter Henderson, University of Southampton 14 Lessons from Open Source Many of the business benefits of Open Source can be realised in the more restricted domain of Open Systems In particular –New business models –Higher Quality –More Rapid Technology Roll Out

September, 2007Peter Henderson, University of Southampton 15 Open Source – New Business Models Indirect Sale Value models (from Eric Raymond) 1.Open Source maintains a market position for proprietary software 2.Open Source applications increase sales of specialised hardware 3.Open Source creates a market for support services 4.Open Source creates a market for accessories 5.Sell Open Source Futures 6.Sell the Brand by branding derivatives 7.Sell the Content

September, 2007Peter Henderson, University of Southampton 16 Open Source – Higher Quality Arises from greater attention to testing and debugging coming from larger developer community Plus some selection process that guarantees improvement as part of evolution

September, 2007Peter Henderson, University of Southampton 17 Open Source – Rapid Technology Roll Out Also arises from greater attention to product coming from larger developer community More options discovered/invented More options pursued Survival of the fittest

September, 2007Peter Henderson, University of Southampton 18 Structural Architecture of RAV1.0 alternative model (cf slide 3) 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. Infrastructure Sensor 1 Power CommsManager Sensor 2Drive