![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Open Space Discussion - Use of UML in systems engineering (e.g. HARMONY) Topic Summary: Created On: 13-Jun-2006 18:31 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Leader Name: Jürgen Strauss
Attendees: Wolfgang Messner Joseph Reale Jörg Christoffers Charlie Lane Eike Römer Rene Seiler Peter Schmittinger Winfried Reichardt Stenio Lingaya Philip Zollinger Georg Heinrich Harald Hewel Thomas Schütz Session Notes: Topic: ?The Harmony process is (still) constantly changing.? This often is a problem in safety critical projects, because the development process needs to be agreed on and fixed at project start. Changes are not possible. Topic: How deep goes Systems Engineering? Modeling the logic/logical view -> yes; modeling the physical view -> no (no bits & bytes, no modeling of busses, ?). Good experience to have the systems part as a model (for the first time). Topic: What?s the best balance between a system and a software model? Topic: Model organization (e.g. handoff to subcontractors) -> flexible model structure (e.g. see Harmony) Topic: Harmony for big SW projects (SW-System-Engineering) -> ok, but the constant changing Harmony again is an issue. Topic: Stick to a process for 2 or 3 years (mandated to management) -> good experience to have common language, common toolset, common infrastructure for systems and software. Topic: Modeling the ?Bus?? In general possible, yes. Two possible scenarios: allocation (from one model to the other) or an evolving mode. E.g. at Eurocopter: Generated a ?synchronous model? from the original Harmony model. Recommended if nearer to reality is needed (more software centric systems engineering) Topic: Synchonize the two models (full SE model and evolved model ) -> recommendation: No. Topic: ?Don?t go too deep? Stay on operational / functional level. Always tailor the process to your needs/workflows/project reality, ? See also the Harmony Desk book (latest). Topic: ?Can top-level test cases run against the model for integration testing? One solution that has been used in the field is to use SystemC blocks to emulate system integration. Added blocks for simulation only; not in final delivery. Topic: Tracability Is done through Gateway or RM tool (e.g. DOORS) not requirements diagrams (?Requirements diagrams don?t scale.?) Dependencies of type <<satisfy>> can be used (SysML notation) to connect requirements with model elements (any kind) ? in UML formerly: An anchor was used to do this (still valid). Impact analysis possible: Yes, in Gateway (or RM tool) or write your own wizard (script) for traceability checking. Topic: What to trace? Trace from textual requirements to Use cases, then create opCons (= SW requirements!) from the Use Cases and trace back from the opCons to the textual requirements. Not supported in Gateway today: Bring over tables and pictures. Topic: Sometimes multi-cast ports would be nive to have. Topic: Ports for Rhapsody in C are missing today -> will be in Pisces release. Topic: Multilanguage support -> will be in Pisces Topic: Systems engineers stay responsible for interface management during the whole project time. Feel free to discuss further... |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.