1. Incremental Synchronization of Organizational Models, Requirements Models and Object-Oriented Software Design Models
Presenter:
M.Sc. Marat Abilov
Tróia, Portugal
Contributors:
Marat Abilov
Jorge Marx Gómez

2. Introduction Background Proposed approach Conclusion Agenda
Agenda of my presentation is as follows:
Introduction: Motivation, Goal
Background: Related approaches, Triple Graph Grammar
Proposed approach: Model Synchronization, Metamodels, Transformation, Example
Conclusion

3. Artifacts contain some similar and some unique information
Motivation
Three different key artifacts during software development process: organizational model, requirements, and software design
Artifacts contain some similar and some unique information
Full automatic derivation would require specification of everything in one artifact, creating mixture
Separation creates problem of synchronization between these models
During synchronization unique information should not be overwritten.
This can be achieved by using incremental bidirectional synchronization
There are three different key artifacts designed during software development process: organizational model, requirements, and software design
These artifacts contain some similar, and some unique information
Full automatic derivation of software design or software code would require specification of everything in the one artifact, which would create mixture of contexts.
Separation of them creates the problem of synchronization between these models to keep them in consistent state.
During synchronization unique information for specific artifact should not be overwritten.
This can be achieved by using incremental bidirectional synchronization techniques.

4. Goals
Development or refining state-of-the-art meta-models for organizational, requirements and software design artifacts in software development process.
Development of machine process-able incremental and bidirectional model synchronization rules between the developed meta-models.
The goals of this approach is as follows:

5. Related approaches Approach From Separate SD Tr. type Inc. upd.
 To
Separate SD
Tr. type
Inc. upd.
Biderecional
OO-Method [Pastor and Molina, 2007]
PIM
PSM -
Program
OOWS [Ruiz and Pelechano, 2007]
Rules
00-H [Gómez et al, 2001]
CIM(OM+RM)
Pattern
UCDA [Liu, 2003]
CIM(RM) +
NLP
SG2HSD [Yu et al, 2005]
CIM(OM)
Algorithm
ROOPODA [Redding et al, 2008]
BPMN2UC [Rodríguez et al, 2010]
CIM (OM)
CIM (RM)
CA [Ruiz, 2012]
UCM [Yue et al, 2013]
BPR&OOCM [González, 2011]
RSUCS [Śmiałek and Straszak, 2012]
Approaches that support automatic software design derivation
They are not bidirectional
They do not support incremental updates
They do not allow to separate software design from organizational and requirements-related information or from model transformation code.

6. Triple Graph Grammar
TGG allows definition of rules for model synchronization using three parts: left side, correspondence side, and right side.
No distinction between source and target models, because the approach is bidirectional.
On the left and right sides of a rule, graph patterns from two meta-models are defined.
These patterns depict incremental changes on both sides of transformation that have similar semantic effect on both models.
A transformation rule defines how synchronization must be performed if an incremental change occurs on any side of the rule.
The correspondence side helps to query traceability links of already performed synchronizations and defines new links for the incremental changes to occur.
[Schürr, 1995]

7. Model Synchronization Metamodels Transformation Example
Proposed approach
Model Synchronization
Metamodels
Transformation
Example
Proposed approach consists of
general concept of model synchronization between artifacts,
the metamodels either adopted or introduced in the study
the organization of transformations
the example

8. Model Synchronization
Model synchronization will be performed between three models in software development process, namely: organizational, requirements, and software design models.
From MDA perspective the first two models are computational independent models, containing problem-specific information in different perspectives.
The organizational models define context information and requirements models define software-related information.
The software design models contain solution-specific information.
These infer that only partial information may be synchronized between these models.

9. Organizational metamodel
The organizational meta-model consists of three packages: Goal Metamodel, Business Process Metamodel, and Extended Entity-Relationship Metamodel.
Goal Metamodel is used to represent organizational goal schema with different types of dependencies between goals, such as “requires”, “support”, “obstruction”, “conflict” and “equivalence”, and different types of decompositions, such as “AND” and “OR”.
Goals can be achieved by means of several business processes that are defined in the form of Business Process Models.
A business process contains flow nodes that are connected with each other by means of sequence flows.
A flow node can have input, output information.
Structure of this information is defined using Extended Entity-Relationship Metamodel.

10. Requirements metamodel
Generic meta-model for requirements, adopted from Pohl, consists of three packages: Goal Metamodel, Scenarios Metamodel, and Solution Metamodel.
Goal Model depicts stakeholder intentions towards software requirements. In this meta-model it has the similar structure as in organizational meta-model.
The goals from organizational model may also appear on this level because there might be dependencies and decompositions links between software goals and organizational goals.
Scenarios Model shows examples of system usage and illustrates goals satisfaction.
It consists of use cases, which contain in addition to one main scenario several alternative and extension scenarios.
Each scenario consists of user-system interaction steps.
Solution Model defines requirements that are most close to the target software.
It contains three perspectives: Data perspective that is usually represented using Extended Entity-Relationship diagram,
Functional perspective that is usually depicted using Data-Flow diagrams,
Behavioral perspective that is usually specified using Automata or/and State charts.
Artifacts from different perspectives have relationships between each other, such as entities defined in EER diagram are also used in data-flow diagram, and data-flow diagrams depicts functions of the system and state charts shows states, when these functions can be executed.
Adopted from [Pohl 2010]

11. Design metamodel
Generic meta-model for a software design consists of the following packages: Component Model, Design Model, Static Aspect, and Dynamic Aspect.
Component Model defines the organization of software components, which is driven by selected architectural style.
Design model represents the basic structure of a component and its main classes are derived from a component pattern.
Usually the choice of which pattern to use in each case depends on software architect’s decision.
The low-level design decisions are covered in the Static and Dynamic Aspects, which present concrete structure and behavior of a single component.

12. Mapping schema between artifacts
Artifacts in each of the sides can be mapped to each other according to mapping schema.
As it was mentioned before, Goal Models in both Organizational and Requirements Model have the similar structure.
Elements of Organizational Goal Model are partially copied to elements of Requirements Goal Model according to the requirements choice.
In contrast to this, the synchronization between Goal Model and Component Model cannot be performed in straight-forward way and hardly influenced by decision of the concrete software architecture.
The information that can be synchronized between these models is the subject of the ongoing research.
Elements from Business Process Models are possible to map to elements from Scenarios Model, since both models contain a sequence of actions.
In Scenarios Model the same actions that appear in Business Process Model will be completed with details of user-computer interaction.
Solution Model’s Functional perspective contains data flow diagrams, elements of which can be synchronized to actions and data inputs/outputs of Business Process Model.
Solution Model’s Behavioral Perspective defines states of the system and transition rules from one state to another.
The derivation of state charts from Business Process Model has already been performed by me and now it is being upgraded to support bidirectional and incremental synchronization.
Dynamic Aspect Model which contains Sequence Diagrams and State chart diagrams can be synchronized to Business Process Models, Scenarios Model, and Functional and Behavioral perspective of Solution Model.
Organizational Entity Model and Data Perspective of Solution Model are depicted using the same Extended Entity-Relationship Meta-model.
Not all entities that appear in Organizational Model should be transformed to Requirements Model, only those that are required in development of current system. On requirement level these entities are then completed with detailed information for this specific system.
Synchronization between Extended Entity-Relationship Model and Class Diagram of Software Design model is not an issue and there is already some work performed in this domain.

13. Example. Publishing agency
Goal diagram
Review Business process
Use Case for Review process
State Chart for Review process
Data Flow for Review process
Let’s consider the example of application of organizational and requirements model synchronization techniques.
The example describes publishing agency and consists of goal diagram, one example business process, which is review process.
Then on the requirements level after applying forward synchronization, there are use case, state chart and data flows for review process.

14. Goal Diagram
The goal diagram for the publishing agency is depicted on the slide.
As you can see the main goal, also known as mission of the company is to publish information that is interesting to a certain audience.
This mission decomposes with “AND” to 5 major goals, one of which is to have information.
This goal decomposes with “OR” into two goals: “to produce information “, or “to acquire information”.

15. Review Business Process
The goal “to acquire information” is achieved by execution of review business process defined on this slide.
The process starts when publishing agent receives proposed content from the author.
After receive he checks the content and determines whether it should be placed for further review or not.
If he decides that the content is good enough, he places it in so-called “slush pile”.
A publisher reader takes the content from it, reads it through and determines its potential quality.
If the publisher reader determines that the content is of sufficient quality he hands it forward to acquisition editor.
Acquisition editor makes the final review of the content and decides whether to accept it or not.
If the content is accepted the signal to stat the process of commission and contract negotiation with author is generated and the process terminates.
If the content was rejected on any step of the review process, the reject message is sent to the author and the process terminates.

16. Use Case for Review Process
Use Case: Review process
Alternative Scenario 1
Input: Content
Condition: (2) No
Output: Content accepted | Content rejected
Derivation start:2
Main Scenario 1
Reject proposal
Check Content 2
Place proposal for review?
Alternative Scenario 2 3
Place proposed content in slush pile
Condition: (5) No 4
Determine quality of proposal 5
Is proposal of sufficient quality? 6
Review proposal
Alternative Scenario 3 7
Accept proposal?
Condition: (7) No 8
Accept proposal
After execution of forward type of model synchronization, the high level use case for the review process is produced.
This use case is specified using defined domain specific language. On the slide it presented in the table form.
The name of the use case is the same as the name of business process.
Its input is the content and its output is decision of content acceptance or rejection.
Main scenario of the use case consists of the steps that resemble the sequence of nodes in the business process.
Each activity of business process is converted into scenario step.
Exclusive diverging gateways are translated also to scenario steps, after which alternative scenarios are forked.
Each alternative scenario has a condition which is the same as condition of a non-default sequence flow after exclusive diverging gateway.
Derivation starts of alternative scenario points to scenario steps in main scenario, after which they are forked.

17. State Chart Diagram for Review Process
State chart for review process is presented on this slide.
As you can see, each action in business process is transformed to state in state chat, for which entry action should be defined.
An exclusive converging gateway is also transformed to state with several transitions that have the same conditions as non-default sequence flows after the gateway.
A start event is synchronized to idle state and transition with event catch condition from it.
An end event is synchronized to the state with entry action specified as raise event.

18. Data Flow for Review Process
The data flow for review process is presented on this slide.
As you can see, each activity in business process is synchronized to data transformation in data flow diagram.
An exclusive diverging gateway is synchronized to so called data OR split with several output data flows.
Data inputs and outputs of an activity are synchronized as input and output data flows for transformation.

19. Conclusion
Model synchronization between analysis and design artifacts is an open challenge in model-driven development
Although containing partially related information, organizational, requirements, and design models have different perspectives
Complete derivation of one model from another in most cases is impossible or very specific
Partial incremental bidirectional model synchronization of changes between these models will give an opportunity to work separately on each of the models without the problem of outdated information in other models
The transformation definitions are not yet complete and are the subject of the ongoing research.

20. Comments, Questions,
Feedback
My congratulations!
You are done!