Systems Engineering Foundations of Software Systems Integration Peter Denno, Allison Barnard Feeney Manufacturing Engineering Laboratory National Institute.

Slides:



Advertisements
Similar presentations
ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Advertisements

© Gerald Kotonya and Ian Sommerville Viewpoint-Oriented Requirements Methods.
Architecture Representation
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
OASIS Reference Model for Service Oriented Architecture 1.0
Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Requirements Analysis Concepts & Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Web Service Architecture Part I- Overview and Models (based on W3C Working Group Note Frank.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Foundations This chapter lays down the fundamental ideas and choices on which our approach is based. First, it identifies the needs of architects in the.
An Intelligent Broker Architecture for Context-Aware Systems A PhD. Dissertation Proposal in Computer Science at the University of Maryland Baltimore County.
On Roles of Models in Information Systems (Arne Sølvberg) Gustavo Carvalho 26 de Agosto de 2010.
MDA Guide Version CYT. 2 Outline OMG Vision and Process Introduction to MDA How is MDA Used? MDA Transformations Other MDA Capabilities Using the.
UML Unified Markup Language Ziya Karakaya Atılım University, Computer Engineering
SC32 WG2 Metadata Standards Tutorial Metadata Registries and Big Data WG2 N1945 June 9, 2014 Beijing, China.
David Chen IMS-LAPS University Bordeaux 1, France
Requirements Analysis
Chapter 4 System Models A description of the various models that can be used to specify software systems.
TC Methodology Massimo Cossentino (Italian National Research Council) Radovan Cervenka (Whitestein Technologies)
Architecture Ecosystem Foundation (AEF) RFP aesig/ Draft RFP Presentation June 2010.
Introduction to MDA (Model Driven Architecture) CYT.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
A C-BML Standard Development Framework for Phase 2 and Beyond Kevin Gupton Applied Research Laboratories University of Texas at Austin
Alignment of ATL and QVT © 2006 ATLAS Nantes Alignment of ATL and QVT Ivan Kurtev ATLAS group, INRIA & University of Nantes, France
1 MFI-5: Metamodel for Process models registration HE Keqing, WANG Chong State Key Lab. Of Software Engineering, Wuhan University
1 Ontology-based Semantic Annotatoin of Process Template for Reuse Yun Lin, Darijus Strasunskas Depart. Of Computer and Information Science Norwegian Univ.
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
Chapter 7 System models.
Lecture 7: Requirements Engineering
LOGIC AND ONTOLOGY Both logic and ontology are important areas of philosophy covering large, diverse, and active research projects. These two areas overlap.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Illustrations and Answers for TDT4252 exam, June
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
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.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Software Design Process
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
MDA & RM-ODP. Why? Warehouses, factories, and supply chains are examples of distributed systems that can be thought of in terms of objects They are all.
Smart Home Technologies
11 th NASA/ESA Workshop on Product Data Exchange 2009 Allison Barnard Feeney, NIST David Price, Eurostep.
1 ME886.3 Topic 1: System and System Design (I). 2 What we design?
XASTRO-2 Presentation CCSDS SAWG th November 2004.
Requirements Analysis
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group January 2011.
Software Engineering Lecture 10: System Engineering.
Ontologies Reasoning Components Agents Simulations An Overview of Model-Driven Engineering and Architecture Jacques Robin.
Architecture Ecosystem SIG March 2010 Update Jacksonville FL.
Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013.
International Workshop 28 Jan – 2 Feb 2011 Phoenix, AZ, USA Ontology in Model-Based Systems Engineering Henson Graves 29 January 2011.
Developing an IDM Information Delivery Manual Part 1. Industry Workgroup Training, Creating IDMs Alliance NA 2010 Dianne Davis, NA-IDM Coordinator Jan.
International Workshop 28 Jan – 2 Feb 2011 Phoenix, AZ, USA Modeling Standards Activity Team Model-based Systems Engineering (MBSE) Initiative Roger Burkhart.
 System Requirement Specification and System Planning.
FROM THE ESSENCE OF AN ENTERPRISE TOWARDS ENTERPRISE SUPPORTING INFORMATION SYSTEMS Tanja Poletaeva Tutors: Habib Abdulrab Eduard Babkin.
M&CML: A Monitoring & Control Specification Modeling Language
The Systems Engineering Context
SysML 2.0 Interface Concepts Modeling Core Team
Model-Driven Analysis Frameworks for Embedded Systems
Tools of Software Development
Requirements I Peter Dolog dolog [at] cs [dot] aau [dot] dk
SysML 2.0 Interface Concepts Modeling Core Team
Chapter 10: Software Engineering
Presentation transcript:

Systems Engineering Foundations of Software Systems Integration Peter Denno, Allison Barnard Feeney Manufacturing Engineering Laboratory National Institute of Standards and Technology Gaithersburg, MD USA

Automating Integration : The Problem Integration - Enabling (actors, agents, components) to work jointly to achieve some task. Enabling the information flows that permits joint action. The Questions: –For Science & Technology generally: What of integration can be automated? What abilities do we lack? –For Systems Engineering: What are the relevant viewpoints? How do viewpoints compose and communicate? What are the problems? How are problems solved? – What is the systems engineering process?

What are the Relevant Viewpoints? A viewpoint on viewpoints, RM-ODP says: –Enterprise : purpose, scope, and policies of the system –Information : nature of information, constraints on its use and interpretation –Computation : functional decomposition into components, interaction and interfaces –Engineering : mechanisms and functions required to support integration –Technology : particular choice of technology

RM-ODP Assuming these viewpoints are sufficient (coverage seems right), what next? –What modeling notations populate these viewpoints? …and need they cleanly fit those categories? –Are other classifications of viewpoint also useful? e.g. conceptual / technical –How is viewpoint communication implemented?

Challenges of being comprehensive –Consistency: Do the concerns expressed in the various notations contradict each other? –Overlap: Do the viewpoints tend to emphasize equivalent concerns? –Traceability: How do I know whether a concern is being addressed amid the diversity of notations? –Composition: Do the various notations complement each other?

Advantages of being comprehensive Using a common modeling core means: –More concise language definition –Inter-model coherence Because viewpoint have a common vocabulary to ‘communicate,’ constraints can be written across models.

Common Core & Meta-Models Purpose of the meta-model: –Identify the fundamental modeling concepts that underlie the various notations (a common core) –So that we can reason about the models Identify equivalence –May be a different usage of MOF!

Meta-models (2) There are at least two kinds… –1: Axiomatic meta-model formal definitions of fundamental modeling concepts based on a small set of informally defined terms (primitives). –2: Hierarchical / Structural meta-models : modeling concepts defined as a population of the primitive terms. Interpretation of primitives ultimately relies on another approach (axiomatic, probably). OMG MOF, ISO IRDS

Which kind of Meta-Model? Aspects of both are needed: –The axiomatic approach helps one define constraints on usage and interpretation: What do we really mean by “class” ? –The hierarchical / structural approach provides management of instances And the models we use are composed of instances –e.g. in files encoded in XMI.

It becomes more difficult... The enterprise viewpoint concerns matters of purpose and policy –This may entail ontologies These may be expressed in their own axiomatic language And have no home in the hierarchical / structural framework

Part 2 : Automating Integration Tasks What stands in the way? –Technical Conflicts –Semantic Conflicts –Functional Conflicts –Quality of Service Conflicts –Logistical Conflicts A common core of modeling notions should enable reasoning about these! –If you can’t identify an equivalence in one of these dimensions, you can’t solve a problem in that dimension

Technical Conflicts Mismatch in the detail of behavior and information representation at the interface –Differing communication mechanism –Syntactic differences in data exchanged –Control conflicts Solutions? –Problem solvers with knowledge of interface technology –Mapping languages –Planning algorithms to synthesize coordination models

Semantic Conflicts Mismatch on concepts and terms leading to unexpected behavior Not about “preserving semantics” across information flows –The purpose of communication is to influence behavior Agreement on sense : models of objects and behaviors in the context of the role of the resource in the system Agreement on reference : the mapping of names to objects

Semantic Conflicts (2) Solutions? –Many research projects, past and present –Most problems require human intelligence –The Standard Upper Ontology may help

Functional Conflicts Behavior of a resource in joint action fails to provide expected function, or even interferes with achieving a function –mismatch in purpose –overlap in purpose –unexpected side-effect Solutions? – Self-description (behavioral, functional) of resources (but not easy?)

Quality of Service Conflict A resource fails to support a non-functional requirement –performance –reliability –security –cost Solutions? –Diverse bodies of knowledge and an ability to appraise the non-functional abilities of a proposed design. Difficult

Logistical Conflicts A matter of system validation: –Does the system really serve the requirements? –Have we provided for graceful evolution of the system? Solutions? –?

View translation Original Requirements Model Repository (meta-object facility) Enterprise Ontology SE Executor System Concept System Solution ATMS views terms blackboard Conceptual Problem Solver Technical Problem Solver refinements and design commitments conceptual technical

Conclusions Finding the correct meta-model and identifying what modeling notions to distinguish is at the heart of an approach to MDA. A model-driven architecture that adequately addresses all 5 integration concerns may be a long way off. –But some very useful work seems possible now

Similar to IEEE 1471 Viewpoint - a reusable template from which to build views; it defines well-formedness conditions on the views, and identifies an audience. View - a representation of the whole system from the perspective of a related set of concerns Model - the expression of a view conforming to a viewpoint’s well-formedness conditions.

Systems Engineering Any methodical approach to the synthesis of an entire system that: –defines views of that system that help elaborate requirements –manages the relationship of requirements to performance measures, constraints, components discipline-specific system views.

References NIST has a project to explore what can be automated and experiment with approaches: –Concepts for Automating Systems Integration (Barkmeyer,et al.) Long report, to be published soon. –