![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Harmony system design model structure Topic Summary: Created On: 26-Oct-2005 15:07 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Dear Doctor, I'm thinking about packages!
We're doing some serious thinking about how to structure our system design model. I know of two key inputs available to us, from which I reproduce the project structure so that others can see what I'm talking about. Sorry it's a bit long. a) the default project that is set up by Rhapsody (6.1) when using the "Create Harmony Project" option, containing: [code] HarmonyProject Components ModelExecution Configurations Animate Packages <<WhiteBox>> TypesPkg Stereotypes ArchitecturalDesignPkg FunctionalAnalysisPkg InterfacesPkg PredefinedTypes Stereotypes Types RequirementsAnalysisPkg Use Case Diagrams Requirements Diagram UseCaseAnalysisPkg Use Case Diagrams Primary Uses Profiles HarmonyProfile [/code] b) your paper "The Transition to Software Engineering" that shows package structure: [code] SEModel Components Object Model Diagrams Packages _SystemsEngineeringModel Packages SystemRequirements Packages Requirements UseCase1 Packages UC1_BlackBox UC1_WhiteBox UseCase2 UseCase3 Use Case Diagrams Use Cases SystemsArchitecture Packages PhysicalArchitecture Classes Comments Object Model Diagrams Subsystem Architecture SubsystemInterfaces Classes Events Object Model Diagrams Subsystem Interfaces PredefinedTypes SubsystemSpecifications Packages FireControl_Subsystem Packages FireControl_Requirements UC_ManageStores UC_ReleaseStores Use Case Diagrams Use Cases HUD_Subsystem Targetting_Subsystem TrackManagement_Subsystem [/code] There are a number of advantages that the structure in your paper has over the one created by Rhapsody, e.g.: - It keeps all the system engineering stuff in a package, easier to link to other models, - It clarifies where the requirements flowed down to subsystems will be - There is a clear route to creating the models for the subsystems I guess you may be talking with the Rhapsody developers to get them to improve the structure created by the "Create Harmony Project" option, but some points: 1. I don't see an area for requirements that have been imported (e.g. a system spec that is mastered in Word, then transferred using Rhapsody Gateway) and will be linked to the use cases in the Requirements Analysis phase of the Harmony process. It is important to be able to keep these separately from the derived requirements (which are in the _SystemsEngineeringModel::SystemRequirements package) so I am considering a new package _SystemsEngineeringModel::SourceRequirements whose mission is to hold specs that are imported from Word/DOORS. This includes externally-authored requirements and external ICDs. 2. The _SystemsEngineeringModel::SystemRequirements package seems to cover the work products of both Requirements Analysis and System Functional Analysis stages of the Harmony process. I wonder if these might be better kept separate by stages, as is done in the structure created by Rhapsody. So I end up with a structure like this (missions shown in brackets): [code] SEModel Components Object Model Diagrams Packages _SystemsEngineeringModel Packages SourceRequirements (for the imported requirements) Requirements (the requirements imported by Gateway) RequirementsAnalysis (for the Requirements Analysis phase) Requirements (derived non-functional requirements) Use Case Diagrams Use Cases (top level use cases) Sequence Diagrams (top level SDs) FunctionalAnalysis (for the Functional Analysis phase) Packages Requirements (flowed-down non-functional requirements) UseCase1 Packages UC1_BlackBox UC1_WhiteBox UseCase2 UseCase3 SystemsArchitecture (for the System Architectural Design phase) Packages PhysicalArchitecture Classes Comments Object Model Diagrams Subsystem Architecture SubsystemInterfaces (holds interfaces between subsystems and external interfaces) Classes Events Object Model Diagrams Subsystem Interfaces PredefinedTypes SubsystemSpecifications Packages FireControl_Subsystem Packages FireControl_Requirements (allocated non-functional requirements) UC_ManageStores UC_ReleaseStores Use Case Diagrams Use Cases HUD_Subsystem Targetting_Subsystem TrackManagement_Subsystem [/code] Questions: 1. Is the package for SourceRequirements sensible? 2. What do you think of splitting the packages as per Harmony phases? 3. Have I correctly inferred the mission of the packages like "FireControl_Requirements" as being to hold any requirements that cannot be captured in the use cases (subsystem QoS requirements)? 4. Any idea what the Rhapsody-generated "Interfaces" package was for? 5. Am I right to infer that the SubsystemInterfaces contains both interfaces between subsystems and external interfaces copied from the external ICD? 6. Can Rhapsody Gateway be used to check coverage of the flowdown of requirements from the Requirements Analysis stage to the Functional Analysis stage, and from the Functional Analysis stage to the SubsystemSpecifications? (Do these need to be in separate Rhapsody projects so that impact can be traced?) 7. It seems that non-functional requirements will be copied three times (once in RequirementsAnalysis, once in FunctionalAnalysis, once in SubsystemSpecifications) ... any thoughts on how to reduce this to, say, one copy while retaining a nicely partitioned system design model? Regards, Charlie |
|
![]() |
|
![]() |
|
Could someone point me to the aforementioned "Transition to Software Engineering" paper? I'd like to structure my packages better and understand Charlie's questions in better detail.
|
|
![]() |
|
![]() |
|
Hmmm the papers used to be in the white papers section but I don't see them now. I'll see if I can get them reposted.
|
|
![]() |
|
![]() |
|
Health warning: My original post is now misleading!
This referred to rather old versions of Harmony and Rhapsody. What we're doing now (and what I'd recommend to others) is as per the Harmony Deskbook Rev 2.0 / 10-12-06, with some additions but no changes. (Actually the Deskbook needs updating -- we have spoken with Peter Hoffmann about this.) |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.