Agusti Canals

La prochaine réunion du Club Génie Logiciel Toulousain du mois de septembre, aura lieu à CS le 11, en salle VISIO à partir de 9h.

Thème:
SysML

Ordre du Jour:
09-00/09-30 : Accueil des participants
09-30/10-30 : Présentation générale de SysML par Françoise CARON de la société EIRIS (membre actif de l'AFIS et coordinatrice des remarques sur SysML envoyées par l'AFIS à l'OMG)
10-30/11-00 : Pause café
11-00/11-30 : Retours d'expérience d'utilisation de SysML par Nicolas BELLOIR de l'Université de PAU (qui a mené une étude de cas sur la modélisation des réseaux de capteurs avec SysML)
11-30/12-00 : Présentation de l'outil TOPCASED/SysML par un membre du consortium Topcased (à définir)
12-00/12-30 : Débat, échanges ...

Contactez moi si vous souhaitez y participer

Activity C : System Description

This activity is composed of three "steps" (use case definition, domain analysis and scenario definition) and consists in finding the interactions between the active actors and our system. Each interaction is illustrated with a use case. Definition:An interaction is a direct communication between an active actor and the system, this communication embedding an active data flow.

Step 1: Use Case definition: A use case is one essential thing for which the active actor uses our system. To find the use cases, the approach consists in answering the following question "WHAT WILL EACH ACTIVE ACTOR USE OUR SYSTEM FOR?"

Recommendations:
1. Each Use Case is described in the final documentation as specified by a standard skeleton,
2. The role definition of the actors can be used to find the use cases.

Note: During this step, one or more use cases diagrams are designed, depending on the model complexity.

Step 2: The Domain analysis: The domain analysis is a "business analysis" made through the use of "class diagrams". It allows the business classes to be found. The domain analysis must be totally independent of the solution used to implement it. To make this concept clear, let’s imagine that the system to model is an electronic mail system. For this example, the domain analysis is the same as for the next two cases: a "postal mail" or the "pony express mail -Solution used in the "far west" during the 19th Century-". For example the class "ADDRESS" is without doubt a domain class in this context.

To find these domain classes, the most important thing to wonder is "IS EACH IDENTIFIED CLASS INDEPENDENT OF THE FUTURE SOLUTION?"

Recommendations:
1. Each class is described in the final documentation as specified by a standard skeleton,
2. The domain analysis must be performed by both an analyst and a business expert, working together.

Note: During this step, one or more class diagrams are designed, depending on the model complexity.

Note: The Use Cases and the domain analysis are the entry points of the following step, namely the scenario definition

Step 3: The scenario definition: For each use case, one or more sequence diagrams are designed. There are two kinds of sequence diagrams: (1) Some of them describe the interactions between the active actors and the system. They are called functional sequence diagrams. To build this kind of diagram, the most important thing to wonder for each use case is: "WHAT IS THE DATA FLOW BETWEEN THE ACTOR AND OUR SYSTEM IN THE USE CASE CONTEXT?"

Recommendations:
1. Most of the time, each Use Case is associated with one and only one of these diagrams
2. Our discipline recommends use of "Notes" attached to internal events or methods in the sequence diagrams. These notes indicate the next "scenario" or "use case" that will implement this event or method.

(2) The other sequence diagrams describe the collaboration between the objects (whether they are domain or application related) that implement the actors/system interactions. They are also called "level 2" sequence diagrams.

To build this kind of diagrams, the most important thing to wonder is: "HOW DOES THE SYSTEM IMPLEMENT THE INTERACTION BETWEEN THE ACTOR AND OUR SYSTEM IN THE CONTEXT OF THE USE CASE?"

Recommendation: Most of the time, there is one diagram for each internal event or method extracted from the functional sequence diagram.

This second type of sequence diagram is the link between the Use Cases and the class diagrams. Indeed, the secondary sequence diagrams are used to initialise the design of the unique class diagram associated with each use case.

To build such a diagram, the most important thing to wonder is: "WHAT ARE THE STATIC LINKS BETWEEN THE CLASSES COLLABORATING TOGETHER, IN THE CONTEXT OF THE USE CASE ?"

Note: The "level 2" sequence diagrams and the class diagram of the use case are the entry points of the object analysis. Moreover, this last step can be performed at the end of the requirement analysis or at the beginning of the object analysis.

IMPORTANT: Naturally, if a class is active (it has a personal behaviour), it is not excluded to design a state diagram.

Next chapter (coming soon)

Previous chapter

TOPCASED is an integrated System/Software engineering toolkit compliant with the requirements of critical and embedded applications.

News and information are available on :
linuxfr.org
Plume project
wikipedia !!
Topcased site
...

Examples are available on :
Using ATL
...

Note that CS is one of the main contributor of this tool.

First IEEE International workshop UML and Formal Methods co-organized by CS, CEA and Telecom Paris Tech.

Held in conjunction with the 10th International Conference on Formal Engineering Methods, ICFEM 2008

L'objectif de ce numéro spécial concernant "L'ingénérie des modèles" de la revue TSI est de faire le point sur les travaux récents du domaine. Plus précisément, ce numéro special offre à la communauté un vecteur de présentation, de synthèse, et de discussion de leurs résultats et idées sur ces thèmes. Outre les présentations classiques de résultats de recherche, nous voulons encourager des articles faisant des synthèses d'état de l'art et/ou de travaux réalisés ainsi que des retours d'expériences de développements dirigés par les modèles par les industriels. Nous sommes également ouverts à des articles présentant et discutant d'idées novatrices.

Thèmes proposés

Les métamodèles, les langages de modélisation et de métamodélisation
Les types de modèles (modèles exécutables, modèles de plate-forme)
Les caractéristiques des modèles (exécutabilité, complétude, conformité)
Les opérations sur les modèles et métamodèles (fusion, différence, composition)
Les transformations de modèles
Les modèles et les exigences (normes, tests, validation)
Les lignes de produits et les modèles
Les cycles de vie des modèles
L'ingénierie directe et la rétro ingénierie basée sur des modèles
L'évolution logicielle et l'IDM
Les modèles de domaine et les langages spécifiques au domaine
Les processus collaboratifs de modélisation
La séparation des préoccupations et l'IDM
Les environnements et outils pour l'IDM
La mise au point et la trace de logiciels basées sur des modèles
Optimisation, test et validation basés sur les modèles
La normalisation des modèles et métamodèles
Les nouvelles applications de l'IDM
Validation des résultats de l'IDM (succès ou échecs)

Soumission

TSI est une revue francophone ; les articles doivent être rédigés en français sauf si aucun des auteurs n'est francophone.

Les articles seront relus par deux lecteurs de la rédaction de TSI et deux membres du Comité de Lecture.

Comité de lecture:

- Franck Barbier, Université de Pau et des Pays de l'Adour, France
- Jean-Philippe Babau, Université Bretagne Occidentale, France
- Xavier Blanc, Université Paris 6, Laboratoire LIP6, France
- Mireille Blay-Fornarino, Université de Nice, Laboratoire I3S, France
- Antoine Beugnard, Telecom Bretagne, France
- Isabelle Borne, Université de Bretagne-Sud, laboratoire VALORIA, France
- Agusti Canals, CS, France
- Rubby Casallas, University of Los Andes, Bogotá, Colombie
- Laurence Duchien, Université de Lille 1, LIFL, INRIA, France
- Anne Etien, Université de Lille 1, LIFL, INRIA, France
- Jean-Marie Favre, Université Joseph Fourier, LIG, Aconit, France
- Sébastien Gérard, CEA, France
- Marianne Huchard, Université de Montpellier 2, France
- Jean-Marc Jezequel, Univ. Rennes 1 & INRIA, France
- Philippe Lahire, Université de Nice, Laboratoire I3S, France
- Tom Mens, Service de Génie Logiciel, Institut d'Informatique, Faculté des Sciences, Université de Mons-Hainaut, Mons, Belgique
- Marc Pantel, IRIT, ENSEEIHT, INPT, Université de Toulouse, France
- Houari Sahraoui, DIRO, Université de Montréal, Canada

Les décisions seront prises sur la base de leurs avis et des discussions qui en découleront.
La soumission se fait par envoi de l'article, au format PDF, par courrier électronique à Laurence Sourdillon - sourdillon@lavoisier.fr
Si vous ne recevez pas de message confirmant sa bonne réception moins d'une semaine après envoi, nous vous demandons de nous contacter directement.

RECOMMANDATIONS AUX AUTEURS

Les soumissions devront respecter la feuille de style de la revue, disponible sur le serveur
Les articles de recherche doivent contenir entre 20 (minimum) et 25 pages au format TSI, les articles d’application ne doivent pas dépasser 20 pages et les articles de synthèse peuvent aller jusque 30 pages. Ils sont acceptés en français (ou en anglais si aucun des auteurs n’est francophone).

Coordonatrices: Mireille Blay-Fornarino et Laurence Duchien

OREKIT un outil open source publié par CS

OREKIT (ORbits Extrapolation KIT) is a free low level space dynamics library written in Java.It provides basic elements (orbits, dates, attitude, frames ...) and various algorithms to handle them (conversions, analytical and numerical propagation, pointing ...).

Activity B: Definition of Context

This activity consists in finding the static and dynamic data flows between the external entities and our system. These data flows show that our system uses or produces data without direct communication. To find this data flows the most important thing to wonder is "WHAT EACH EXTERNAL ENTITY WILL EXCHANGE WITH OUR SYSTEM?"

The static data flow is a unique collaboration diagram that illustrates our system with the external entities and the data, whether they are produced or consumed.

The dynamic data flow is made up of one (or more) sequence diagram(s) that illustrate(s) the chronological relationship between the external entities and our system. It shows, in other words, when the system processes the input data and/or when the system produces and transfers the output data.

Important: These diagrams are produced if the order of the data exchanged is important. Otherwise, they are not needed.

The next chapter: Activity C

Previous chapter

Take a look to NASTEC'08

The 1st annual North American Simulation Technology Conference (NASTEC) aims at bridging the information gap in research and improving scientific exchanges between Europe and North-America. For this reason EUROSIS has set up the NASTEC conference, which aims to provide an insight into the latest hot research topics in the field of modeling and simulation. ...

Activity A: Definition of Actors

This activity consists in defining the actors (an actor is "something" always out of our system). Our Easy method suggests two kinds of actors:

An "active" actor (the standard UML actor) is a participant or a process role, which interacts with the system to be modelled, and actively works in the realisation of the system Use Cases.

An "external entity" is a stereotyped actor that does not actively participate in the realisation of the system Use Cases (e.g. a process producing or consuming data for our - but not necessary only - system, but not in direct communication).

To find these actors, the most important things to wonder are “WHO WILL USE OUR FUTURE SYSTEM ?”, and, “WHAT (not to say WHO) WILL BE USED BY OUR FUTURE SYSTEM ?”.

Recommendations:

1) Each actor must be described through his role and his responsibilities.

2) During this activity, it is possible to start the "physical Architecture Description" activity, the two activities running parallel.

If "External Entities" have been identified during this activity, the next one is then Activity B. If not, the following step is Activity C.

The next chapter: Activity B

Previous Chapter

This is the first chapter:

Requirements Analysis

The aim of the "Requirements Analysis" is to get a complete description of our system environment, focusing on the user needs. The objective is thus to identify the external actors, the data flows between the actors and the system and finally the list of Use Cases.

Actors:

The analyst team, specialised in collecting and formalising the user requirements.

The key question here is:
"What is the system ?"

Inputs:
User Requirements (needs)

Outputs:
UML Model
MMI prototype (if needed)
Requirements Analysis Document
Validation Plan Document

Activities:
Activity A : Definition of Actors
Activity B : Definition of Context
Activity C : System Description

The next chapter: Activity A

La conférence MODELS est l’une des plus importantes dédiée à la modélisation logicielle. Co-sponsorisée par l’IEEE et l’ACM (peu de conférences obtiennent ce double label), elle alterne entre continent américain et européen chaque année.

Cette année à Toulouse, du 28 Septembre au 3 Octobre (au centre Pierre Baudis) sera célébré le 10ème anniversaire de cette conférence. On espère donc y battre des record d’assistance. Déjà, un nombre record de soumissions d’articles de recherche, a forcé le Comité d’Organisation à élargir le Comité de Programme et à augmenter le nombre de sessions de présentation lors de la conférence.

Nous attendons cette année plus de 450 visiteurs, que ce soit des chercheurs académiques ou des industriels concernés par l’engouement actuel autour du Model-Driven Engineering.

Une salle de 85m2, ouverte en permanence pendant la conférence et donnant directement sur le hall des pauses café, sera dédiée à l’exposition d’outils liés au développement et à la modélisation logicielle.

Vous souhaitez exposer votre société ou vos produits à la conférence MODELS’2008 ?

Nous vous proposons plusieurs solutions en fonction de vos besoins et de votre budget. Nous nous tenons également à votre disposition pour étudier ensemble toute autre proposition qui serait plus adaptée à votre attente.

Jean-Michel Bruel & Ileana Ober General co-Chair

Agusti Canals Exhibitor Chair

TOOLS EUROPE 2008: 46th International Conference Objects, Models, Components, Patterns co-located with International Conference on Model Transformation 2008 Software Engineering Approaches for Offshore and Outsourced Development 2008 http://tools.ethz.ch/

Dans le cadre de Models 2008 deux évènements trés interessants:

Model Based Architecting and Construction of Embedded Systems
Call for Research Projects Symposium

N'hésitez pas à proposer des articles et/ou à vous inscrire

CS participe au 8ième congrés WCCM

Atelier A2120
Atelier Crimson
Atelier Polymere

The International Association for Computational Mechanics (IACM) and the European Community on Computational Methods in Applied Sciences (ECCOMAS) are happy to announce the joint organization of the 8th. World Congress on Computational Mechanics (WCCM8) and the 5th. European Congress on Computational Methods in Applied Sciences and Engineering (ECCOMAS 2008) to be held at the Lido Island in Venice (Italy) on 30 June - 4 July 2008

N'hésitez pas à consulter le site de l'action IDM (Ingénierie Dirigée par les Modèles) une association trés active ...

L'action IDM regroupe des équipes appartenant au GdR CNRS Architectures, Systèmes et Réseaux (ASR), au GdR Génie de la Programmation et du Logiciel (GPL) et au GdR Information, Interaction, Intelligence (I3). Elle vise à la diffusion des informations et à la concordance des travaux des équipes travaillant sur des thématiques relatives à l'ingénierie dirigée par les modèles (IDM).......