March 2005 - 1 ASSERT WP4.2 – Framework Development Experiment Main FwDE Activities Domain Analysis Objective: Characterize the functionalities to be covered.

Slides:



Advertisements
Similar presentations
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
Advertisements

Solutions to Review Questions. 4.1 Define object, class and instance. The UML Glossary gives these definitions: Object: an instance of a class. Class:
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Amit, Keyur, Sabhay and Saleh Model Driven Architecture in the Enterprise.
2 Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how statecharts can be used to describe system behaviors  Use statecharts.
Lecture 13 Revision IMS Systems Analysis and Design.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
November 18, 2004 Embedded System Design Flow Arkadeb Ghosal Alessandro Pinto Daniele Gasperini Alberto Sangiovanni-Vincentelli
Describing Syntax and Semantics
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Domain-Specific Software Engineering Alex Adamec.
Roles and Responsibilities Jahangheer Shaik. Service Specification Specification requires development of three inter-related documents CIM, PIM and PSM.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
UML - Development Process 1 Software Development Process Using UML (2)
Faculty of Informatics and Information Technologies Slovak University of Technology Peter Kajsa and Ľubomír Majtás Design.
Workshop - November Toulouse Ronan LUCAS - Magillem Design Services 07/04/2011.
Workshop on Integrated Application of Formal Languages, Geneva J.Fischer Mappings, Use of MOF for Language Families Joachim Fischer Workshop on.
Introduction to MDA (Model Driven Architecture) CYT.
SaveUML System design. System overview Possible...
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
Selected Topics in Software Engineering - Distributed Software Development.
Using Architecture and Analysis Design Language (AADL) to Independently Validate and Verify (IV&V) System Performance Requirements and Design Performance.
Systems Analysis and Design in a Changing World, 3rd Edition
The Systems Development Life Cycle
1 5 Nov 2002 Risto Pohjonen, Juha-Pekka Tolvanen MetaCase Consulting AUTOMATED PRODUCTION OF FAMILY MEMBERS: LESSONS LEARNED.
NJIT UML Class Diagrams Chapter 16 Applying UML and Patterns Craig Larman.
MDA – Model Driven Architecture Olivier Riboux. Overview What is MDA? The Challenges MDA addresses Developing in the MDA Benefits / Conclusion Case Study:
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.
Rational Unified Process Fundamentals Module 7: Process for e-Business Development Rational Unified Process Fundamentals Module 7: Process for e-Business.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
ModTransf A Simple Model to Model Transformation Engine Cédric Dumoulin.
Rational Unified Process (RUP)
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Cross Language Clone Analysis Team 2 February 3, 2011.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with IBM Rational Software Architect, V7.5 Module 18: Applying Patterns and Transformations.
CSCI 3428: Software Engineering Tami Meredith UML Unified Modeling Language.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
TTCN-3 Testing and Test Control Notation Version 3.
MDD-Kurs / MDA Cortex Brainware Consulting & Training GmbH Copyright © 2007 Cortex Brainware GmbH Bild 1Ver.: 1.0 How does intelligent functionality implemented.
Page 1 Hitachi Ltd. – FhI FOKUS TTCN-3 User Conference, June 2005 MDA based approach for generation of TTCN-3 test specifications Hideto Ogawa, Hitachi.
CHESS Methodology and Tool Federico Ciccozzi MBEES Meeting Sälen, January 2011 January 2011.
Page 1 Feature Modeling and Configuration Management Roche Diagnostics, 16 th October 2007 O. Rohlik (ETH Zurich and P&P Software)
FESA Overview Leandro Fernandez On behalf of the FESA Team 6/22/2010FESA Overview1.
1 Week 3 Software Engineering Spring Term 2016 Marymount University School of Business Administration Professor Suydam.
Page 1 Data Read/Write from/to Data Pool Framework Boundaries - AOCS Activity Manager Part of the AOCS application instantiated from the AOCS Framework.
Lesson # 9 HP UCMDB 8.0 Essentials
SysML 2.0 Requirements for Visualization
Metamodel-driven development environments
Physical Data Model – step-by-step instructions and template
Objects as a programming concept
Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN
Unified Modeling Language
Introduction to Unified Modeling Language (UML)
About the Presentations
Architecture Components
Chapter 6 Database Design
Software Design Methodology
UML dynamic Modeling (Behavior Diagram)
System Concept Simulation for Concurrent Engineering
Evaluating Compuware OptimalJ as an MDA tool
UML profiles.
Constructing MDA-based Application Using Rational XDE for .NET
Metadata Framework as the basis for Metadata-driven Architecture
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CSE 1020:Software Development
Software Development Process Using UML Recap
Software Architecture & Design
Presentation transcript:

March ASSERT WP4.2 – Framework Development Experiment Main FwDE Activities Domain Analysis Objective: Characterize the functionalities to be covered by the FwDE Baseline Tools: XFeature Expected Output: feature model for FwDE PlM Component View Objective: Define the functional interfaces for the FwDE building blocks Baseline Tools: Rhapsody Expected Output: UML Component Model Functional Verification Objective: Define and verify functional properties for the PIM (optional activity owing to uncertainty over tool support) Baseline Tools: TBD (HRT-UML or IF) Expected Output: Verified Functional Properties PlM Behavioural View Objective: Define the functional behavioural specification for the FwDE building blocks Baseline Tools: Rhapsody Expected Output: UML State Chart Model Domain Design Objective: Map the PIM to the RT Java Platform Baseline Tools: Rhapsody Expected Output: UML Class Model PSM Class View PSM Timing View Domain Implementation Objective: Impose the Ravenscar Computation Model upon the PIM Baseline Tools: HRT-UML (TBC) Expected Output: HRT-UML Class Model Result Evaluation Objective: Evaluate results of FwDE Baseline Tools: n.a. Expected Output: technical note PSM Code Gen. Objective: Generate code for PSM (only part of the code is covered) Baseline Tools: Rhapsody Expected Output: Source Code N.B. Activities within the same box are not necessarily done in the order in which they are shown

March ASSERT WP4.2 – Framework Development Experiment Cyclical Telemetry Concept TmStream AppComp TmManager PUS Application Process TM packets are loaded and unloaded into the TmManager by application components The TmManager is responsible for managing the list of pending TM packets and periodically asking them to update themselves and serialize themselves to a TmStream TmFactory The TmFactory returns unconfigured TM packet components Each TmManager is associated to a TmStream Terminated TM packets are returned to the TmFactory TmRegistry filters TM packets

March ASSERT WP4.2 – Framework Development Experiment FW Adaptation Process Framework Software Component Framework-level Properties capturing domain-invariant behaviour and functionalities Framework-level Properties (inherited from framework component) + Application-level Properties capturing application-specific behaviour and functionalities (introduced by adaptation process) Adaptation Process Application Software Component

March ASSERT WP4.2 – Framework Development Experiment Framework -Based Process Domain Model Design Pattern Model Component View Class View Timing View Platform-Independent Model Formal Verification Domain Design PhaseDomain Implementation PhaseDomain Analysis Phase Objective: Define the domain to be covered by the framework Technology : Feature Modelling Tool : XFeature (from Task 4.2.3) Objective: Define non-functional characteristics of FW components Technology : HRT-UML Tool : HRT-UML Tool (Task 4.2.1) Objective: Define functional interfaces of the framework Technology : UML2 Tool : UML2 Eclipse Plug-In Objective: Verify functional properties exported by the framework Technology : Design-By-Contract Tool : See WP4.3 Objective: Define functional behaviour of FW components Technology : State-Charts Tool : UML2 Eclipse Plug-In Objective: Describe design solutions Technology : Design Patterns Tool : None (follow GoF standard) Objective: Define code generators for framework component models Technology : Code Generation Tool : JET Eclipse Framework Objective: Define residual part of FW component implementation Technology : Ada/C/C++/Java Tool : SW Development Tool Platform-Specific Model Code Generator Manual Coding

March ASSERT WP4.2 – Framework Development Experiment Family-Based Process Domain Analysis Domain Needs Domain Design Domain Model Domain Implementati on Requir. Definition Application Needs Adaptation of Family Assets Integratio n & Testing Family Creation Process Family Instantiation Process Domain Model Application Family Assets Non-Family Building Blocks Asset Models

Page 6 Shared Properties NB: Formal verification activities are outside the scope of CORDET! Shared Properties Domain Dictionary Shared properties are expressed in natural language in terms of entries in the domain dictionary Design Entities Shared properties and domain dictionary entries are mapped to design entities in the domain design Map from domain analysis to domain design level LFormulas (TBC) Verification Models Shared properties are expressed in terms of a verification language (out of scope of CORDET) Domain Design Domain Models Design Models Domain Analysis Logical Formulas Verification Models

Page 7 Shared Properties NB: Formal verification activities are outside the scope of CORDET! Shared Properties Domain Dictionary Shared properties are expressed in natural language in terms of entries in the domain dictionary A. - G. Contracts UML2 Model Elements Shared properties are mapped to assume-guarantee contracts defined on the UML2 design models Logical Formulas Verification Models Shared properties are expressed in terms of a verification language (out of scope of CORDET) Domain Design Domain Models Design Models Domain Analysis

Page 8 Domain Model Shared Properties Domain Dictionary Captures invariants in natural language in terms of entries in domain dictionary Factors of Variation Domain Model Captures variability within the domain Defines terms required to express shared properties Feature Model Gives an overview of the domain model with special emphasis on variability

Page 9 Design Model Two Meta-Models covering data pool and parameter database concepts Control Framework Meta Model UML2 Model UML2 Model covering Activity and Mode Management concepts UML2 Model UML2 Model covering all parts of the DH Framework CORDET Framework Design Model UML2 Models are merged in one single

Page 10 Embedding Rules Additional Component Functional Component CASE 1: Functional component can be embedded “as is” in RCM container Additional component that interfaces the functional component with the RCM container RCM Container Functional Component Functional Component CASE 2: Functional component must be combined with an additional component Functional Component RCM Container

March ASSERT WP4.2 – Framework Development Experiment Telecommand Concept TcStream TcLoader TcManager Raw TC data are read by the TcLoader from the TcStream The TcLoader de-serializes the raw TC data and constructs the TC components PUS Application Process The TC components are loaded into the TcManager component(s) The TcManager is responsible for executing the TC components TcFactory The TcLoader takes unconfigured TC components from the TcFactory The TcManager returns completed TC components to the TcFactory

March ASSERT WP4.2 – Framework Development Experiment Cyclical Telemetry Concept TmStream AppComp TmManager PUS Application Process TM packets are loaded and unloaded into the TmManager by application components The TmManager is responsible for managing the list of pending TM packets and periodically asking them to update themselves and serialize themselves to the TmStream TmFactory The TmFactory returns unconfigured TM packet components Each TmManager is associated to the TmStream Terminated TM packets are returned to the TmFactory TmRegistry filters TM packets Application component wish to create and send a TM packet