This section gives a very brief and rough overview over the Harmony process. The overview is far from being exact or accurate. The reader is refered to the "System Engineering Best Practices with the Rational Solution for Systems and Software Engineering Deskbook" (Release 4.1) by Hans-Peter Hoffmann for exact and complete information regarding the Harmony process definition.
The Deskbook 4.1 is available for download here.
There also exists a new version of the Harmony Deskbook, Harmony aMBSE Deskbook (Version 1.0) by Bruce Powel Douglas, available for download here or here.
The Harmony aMBSE Deskbook takes also agile development considerations and workflows into account.
Since the Harmony aMBSE Deskbook has dropped the continuous references to one standard model - the Security System used in this tutorial - to favor glances into several other models instead, we still refer to the Harmony Deskbook 4.1. Moreover, agile workflows don't affect basic ATG use cases and workflows. ATG workflows are applicable to agile micro cycles in agile system engineering as well as to development steps in a more classical system engineering process.
The Harmony Process
The Harmony process is a well defined process supporting Model-Driven Development (MDD). The process definition provides system engineer with a step-by-step guide on using the SysML in a way that allows seamless transition to subsequent system development.
- Requirement Analysis: Requirements are collected and completed. Complex requirements are refined and categorized in functional and non-functional requirements. Requirements must not contradict each other.
Requirement Models are used to visualize the taxonomy of requirements.
Requirements are allocated to Use Cases. System Use Case Models are used to group requirements into Use Cases.
The models obtained from the Requirement Analysis Phase are not executable.
System Functional Analysis: The use cases identified in the requirement analysis are functionally analyzed. For the individual use cases, scenarios and activities are derived. From these activities and scenarios in turn executable models are obtained defining the system behavior for individual Use Cases. The behavioral models are verified against the underlying requirements through model execution.
Functional requirements are allocated to behavioral model elements of the executable models for the individual use cases.
- Design Synthesis:
The behavior of the executable models for the individual use cases are merged into one system model capturing all identified use cases. This composition is verified against the individual use cases and thus the underlying requirements through model execution.
Merging the Use Case models has to take care also of functional requirements allocated to behavioral model elements of the individual behavioral Use Case models.
Once an executable system model has been derived, the functionality is allocated to subsystems. According to this allocation, an architectural concept model is elaborated and the behavior is decomposed into the identified sub-systems. The decomposed architectural concept model is verified against the merged system model through model execution.
Non-functional requirements are allocated to architectural elements.
When decomposition into sub-systems has been completed and the architectural concept model has been verified against the results of the previous phases, system engineer's work is completed and the resulting model of the design synthesis phase is handed to subsequent sub-system decomposition or to HW/SW development. The System Architecture Baseline has been reached.
It obviously depends on the complexity of the system and on several individual constraints e.g. regarding sub-system reusablity or, how modular the system will be decomposed in sub-systems.
SW Analysis & Design: The resulting model of the previous system engineering process is handed as specification model to the subsequent HW and SW development. The software development can again follow a Model Based Development process. How SW Analysis and development is organized is not in the scope of the Harmony process.
SW Implementation & Unit Test: Development of the implementation for the individual sub-systems and SW components. How this implementation phase is organized in particular is not in the scope of the Harmony process.
Module Integration & Test: HW and SW components implemented and unit tested in the HW and SW implementation phase are (optionally) integrated in modules, i.e. functional sub-system realizations according to the system decomposition in the design synthesis phase. Module integration is verified against the system decomposition obtained from the design synthesis phase.
(Sub-)System Integration & Test: The modules are integrated in the system realization. The integrated system is verified against the requirements.
System Acceptance: If the integrated system adheres to all requirements, the system is accepted - engineering and development successfully terminate with system acceptance.
Harmony-Remarks regarding this tutorial
Use of actors: In the Harmony process, environmental aspects of the engineered system are modeled using actors. The identification and introduction of appropriate actors takes already place in the requirement analysis phase, where requirements are allocated to use cases. Actors are introduced in the early use case diagrams and are re-used throughout the subsequent system engineering phases.
Interface concept: Use of ports: The engineering phases of the Harmony process adhere to a clear and rigid interface concept: all communications among sub-systems and among (sub-)system and actors take place only via events exchanged via ports. Operations of (sub-)systems under consideration shall have no implementations and no side-effects. In particular, operations are not used to communicate with other (sub-)systems or actors.
Allocating Requirements to model elements: The Harmony process definition recommends linking model elements to requirements using stereotyped dependencies1. These dependencies establish traceability for modelling activities: Rhapsody supports navigating dependencies in various ways. In the model, the user can navigate from model elements to the requirements they satisfy. The other way round, the user can navigate from an individual requirement to the referencing model elements.
Virtualization of Verification Activities
Detecting errors due to incomplete or inconsistent requirements or due to specification errors in early engineering phases becomes the more costly the later the errors are detected.
Thus, the development process benefits from pushing up integration steps at least partially already to the early phases of the development process.
On the one hand, this can be achieved by 'doing the right thing by construction'. On the other hand, it can be achieved by virtually applying integration activities, such as (sub-)system integration tests on the decomposition artefacts e.g. already in the design synthesis phase.
The Harmony process aims at 'doing the right thing by construction' by defining a practical methodology on how to elaborate executable models from requirements. The engineering steps supported by the Harmony process are tailored towards establishing traceablity and seamless transition from requirements to a specification model.
TestConductor and Automatic Test Generator aim at easing testing efforts by supporting Model Based Testing (MBT). Automatic Test Generator automatically derives TestCases from a model. These TestCases can on the one hand be used to derive test cases to be later applied on the implementation. On the other hand, the TestCases can be executed on the model using TestConductor. Besides application of regression testing for guiding model transformations, testing on the model can be used e.g. to detect undesired behavior, to rule out 'dead code' in the model by measuring model element coverage or to automatically measure requirement coverage.
Model execution for verification of model transition in the Harmony process requires high manual efforts. Manual inspection and assessment of execution observations is necessary to establish evidence of correctness for a transition step. Besides being time consuming and requiring higher efforts compared to automated testing, manual assessment is always potentially error-prone. Here, TestConductor and Automatic Test Generator can help reducing testing efforts and automatically establishing evidence of correctness for model transition steps.