Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA 15213-3890 Dennis Smith, David Carney and Ed Morris DEAS.

Slides:



Advertisements
Similar presentations
1 From Grids to Service-Oriented Knowledge Utilities research challenges Thierry Priol.
Advertisements

Technology Drivers Traditional HPC application drivers – OS noise, resource monitoring and management, memory footprint – Complexity of resources to be.
A Unified Approach to Combat Counterfeiting: Use of the Digital Object Architecture and ITU-T Recommendation X.1255 Robert E. Kahn President & CEO CNRI,
Incremental Commitment Spiral Model, Expedited Engineering, and Kanban Jo Ann Lane and Alexey Tregubov USC CSSE Rich Turner Stevens University.
Welcome to DEAS 2005 Design and Evolution of Autonomic Application Software David Garlan, CMU Marin Litoiu, IBM CAS Hausi A. Müller, UVic John Mylopoulos,
© 2011 Carnegie Mellon University System of Systems V&V John B. Goodenough October 19, 2011.
Quality Management. What is a software product? Software product = computer programs (sources and executable) + associated documentation Software products.
Systems Engineering in a System of Systems Context
Objektorienteret Middleware Presentation 2: Distributed Systems – A brush up, and relations to Middleware, Heterogeneity & Transparency.
© 2006 Carnegie Mellon University Establishing a Network Centric Capability: Implications for Acquisition and Engineering Dennis Smith Complex System Symposium.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
Software Engineering Techniques for the Development of System of Systems Seminar of “Component Base Software Engineering” course By : Marzieh Khalouzadeh.
K.M. Corker, Ph.D.Industrial & Systems Engineering System Engineering ISE 222 Spring 2005 Notes & Course Materials
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
27 September 1999 Crisis Management William L. Scherlis Carnegie Mellon University School of Computer Science.
Unified Modeling (Part I) Overview of UML & Modeling
Model Driven Architecture (MDA) Partha Kuchana. Agenda What is MDA Modeling Approaches MDA in a NutShell MDA Models SDLC MDA Models (an Example) MDA -
© 2007 The MITRE Corporation. All rights reserved Approved for Public Release; Distribution Unlimited Potential New Ideas from Complexity Science.
National Institute of Standards and Technology Computer Security Division Information Technology Laboratory Threat Information Sharing; Perspectives, Strategies,
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
Copyright 2007 by Linda J. Vandergriff All rights reserved. Published 2007 System Engineering in the 21st Century - Implications from Complexity.
Computational Thinking Related Efforts. CS Principles – Big Ideas  Computing is a creative human activity that engenders innovation and promotes exploration.
Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version E-Gov 2006Benefits, Misconceptions and SOA Governance Issues -
On Roles of Models in Information Systems (Arne Sølvberg) Gustavo Carvalho 26 de Agosto de 2010.
Desired Quality Characteristics in Cloud Application Development Leah Riungu-Kalliosaari.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
A Research Agenda for Accelerating Adoption of Emerging Technologies in Complex Edge-to-Enterprise Systems Jay Ramanathan Rajiv Ramnath Co-Directors,
UML - Development Process 1 Software Development Process Using UML (2)
UML Unified Markup Language Ziya Karakaya Atılım University, Computer Engineering
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Lecture 9: Chapter 9 Architectural Design
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
Ævol : A Tool for Planning Architecture Evolution David Garlan & Bradley Schmerl Carnegie Mellon University.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
CPSC 871 John D. McGregor Module 6 Session 3 System of Systems.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
Lockheed Martin Aeronautics Company Candidate Collaborative Projects for Net-Centric Application Michael F. Siok, PE Lockheed Martin Aeronautics Company.
June 05 David A. Gaitros Jean Muhammad Introduction to OOD and UML Dr. Jean Muhammad.
The roots of innovation Future and Emerging Technologies (FET) Future and Emerging Technologies (FET) The roots of innovation Proactive initiative on:
Lecture 7: Requirements Engineering
Service Oriented Architecture (SOA) Dennis Schwarz November 21, 2008.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
Introduction Infrastructure for pervasive computing has many challenges: 1)pervasive computing is a large aspect which includes hardware side (mobile phones,portable.
Investigating Survivability Strategies for Ultra-Large Scale (ULS) Systems Vanderbilt University Nashville, Tennessee Institute for Software Integrated.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
1 By Paul Murray Claire McQuade Kashif Rafiq David Miller.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
THE VISION OF AUTONOMIC COMPUTING. WHAT IS AUTONOMIC COMPUTING ? “ Autonomic Computing refers to computing infrastructure that adapts (automatically)
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. NFP Design Techniques Software Architecture Lecture 20.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. NFP Design Techniques Software Architecture Lecture 20.
Mahmut Ali GÖKÇEIndustrial Systems IEU Introduction to System Engineering ISE 102 Spring 2007 Notes & Course Materials Asst. Prof. Dr. Mahmut.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
CS223: Software Engineering Lecture 13: Software Architecture.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Interoperability: Issues, Challenges, Solutions Bill Lober, MD MS Associate Professor, Health Informatics and Global Health Schools of Medicine, Nursing,
Basic Concepts of Software Architecture. What is Software Architecture? Definition: – A software system’s architecture is the set of principal design.
 System Requirement Specification and System Planning.
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Distribution and components
Web *.0 ? Combining peer production and peer-to-peer systems
Software Life Cycle Models
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Chapter 9 Architectural Design.
Automated Analysis and Code Generation for Domain-Specific Models
Presentation transcript:

Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS Workshop May 21, 2005 Interoperability Issues for Autonomic Computing

© 2005 by Carnegie Mellon University Smith - 2 DEAS Workshop Context for Interoperability Most modern systems are usually a heterogeneous collection of custom and commercial products Integration provided by some third-party technology Modern systems are seldom expected to function independently Expected to cooperate with existing systems The ability to achieve “cooperation” is generally termed "interoperability“ Elements of these cooperating systems undergo frequent (e.g., upgrades of commercial products) Thus: boundaries within and between systems begin to blur Distinction between a "system of systems" and a single, complex, distributed system disappears

© 2005 by Carnegie Mellon University Smith - 3 DEAS Workshop System “C” We know quite a lot about constructing systems from components (over which we may have little or no control). Current State of Our Knowledge We know something about composing systems of systems from individual systems (over which we may have little or no control). System “B” We know very little about constructing an interoperable network of systems…the key distinction being that the network is unbounded (or very loosely bounded) and has no single controlling authority. System “A” “SYSTEM D” Unplanned, unexpected, emergent behavior here…

© 2005 by Carnegie Mellon University Smith - 4 DEAS Workshop Autonomic Computing Requires Attention to Interoperability Issues Selected relevant autonomic characteristics: Reflexivity: detailed knowledge of a system’s components and their inter-dependencies Self-configuration: reconfiguring at run-time and adaptive algorithms can benefit from research in interoperability on “emergent algorithms” Evolving: the evolution of systems relies directly on understanding how to add components and systems to an existing system or system of systems

© 2005 by Carnegie Mellon University Smith - 5 DEAS Workshop Interoperability Issues That Can Impact Autonomic Systems Tests to verify interoperability often fail to identify interoperability shortfalls When interoperability is achieved, it is often difficult to maintain as new versions of constituent systems are released Planned interoperability between new systems is often scaled back to maintain compatibility with older systems Strict specification of standards for achieving desired levels of interoperability is often insufficient because organizations constructing compliant standards often interpret them in different ways

© 2005 by Carnegie Mellon University Smith - 6 DEAS Workshop Principles Required to Address Interoperability for Autonomic Systems- 1 No clear distinction can be made between Systems and Systems of Systems. One man’s system-of-systems is another’s system. The critical factor is less where a boundary might lie and more where control lies -most systems are now created with some components over which the integrator has less than complete control There will always be new things to integrate into the system.

© 2005 by Carnegie Mellon University Smith - 7 DEAS Workshop Principles Required to Address Interoperability for Autonomic Systems- 2 Interoperability problems are independent of domain Most complex systems in almost every domain are now expected to interact with other complex systems Solutions cannot rely on complete information Classic software engineering practice assumes a priori understanding of the system being built, including complete and precise comprehension of assumptions, functionality, services, data and quality attribute needs. Multiple organizations have multiple—and rarely parallel—sets of expectations about the constituent parts and the entire system of systems

© 2005 by Carnegie Mellon University Smith - 8 DEAS Workshop Principles Required to Address Interoperability for Autonomic Systems- 3 No one-time solution Is possible As a result, new approaches are needed to -vet proposed requirements changes at the system and system-of-systems level -analyze the effect of proposed requirements and structural changes to systems and systems of systems -structure systems and systems of systems to avoid (or at least delay) the effect of changes -verify interoperability expectations to avoid surprises when systems are deployed

© 2005 by Carnegie Mellon University Smith - 9 DEAS Workshop Principles Required to Address Interoperability for Autonomic Systems- 4 Networks of interoperability demonstrate emergent properties Emergent properties are those properties of a whole that are different from, and not predictable from, the cumulative properties of the entities that make up the whole In very large networks, it is not possible to predict the behavior of the whole network from the properties of individual nodes. -Such networks are composed of large numbers of widely varied components (hosts, routers, links, users, etc.) that interact in complex ways with each other, and whose behavior “emerges” from the complex set of interactions that occur

© 2005 by Carnegie Mellon University Smith - 10 DEAS Workshop Common Observed Interoperability Problems- 1 Need for understanding on scope and mechanisms of interoperability Divisions of responsibility Many divisions in responsibility, obligation, and management Potential results of these divisions: -Things will fall through cracks -When problems occur, finger pointing can occur Requirements Requirements for interoperability are often ill –defined except to “work together” Requirements for different components and systems often continue to evolve Functionality Not all capabilities of different versions are compatible Achieving backward compatibility represents a major challenge

© 2005 by Carnegie Mellon University Smith - 11 DEAS Workshop Common Observed Interoperability Problems- 2 Processes (development and integration) There is often some degree of misfit between processes, methods and tools employed by different contributors to the system Other potential showstopper issues Scalability Performance Security Testing

© 2005 by Carnegie Mellon University Smith - 12 DEAS Workshop Selected Emerging Research Areas on Interoperability Issues for Autonomic Computing Models of interoperability Evolution of components Semantic issues Testing and validation Migration to net centric services Impact of joint interoperability and survivability requirements Characteristics of interoperability Implications of Service Oriented Architectures