Hello,
Thanks for your question.
When importing things like Application Dependencies, you can (and should) make use of derived instances in the Import Activities wherever you can as this reduces the amount of content that must be captured in the data-capture spreadsheet.
In your example, to capture those dependencies, we need to capture:
- Composite Application Provider (or Application Provider if that’s what you are using) for each of the applications for which we want to define dependencies
- Static Application Provider Architecture - instances of which are where we define those dependencies
- :APU-TO-APU-STATIC-RELATION - which capture the dependencies between the applications (and on which we can capture the Information that is being exchanged - out of scope for this post!)
- Static Application Provider Usage - which capture the ‘use’ of a Composite Application Provider in a particular architecture instance.
The Essential Meta Model allows you to capture these dependencies in any way that you like BUT I strongly recommend modelling these dependencies using a pattern that we call ‘nearest neighbours’, which makes the dependency models must easier to manage and maintain.
The process we need to follow is that for a Composite Application Provider:
- Define a Static Application Provider Architecture for that Composite Application Provider (connected via the ap_static_architecture slot on the Application Provider)
- Create a new Static Application Provider Usage in that new architecture and connect it to the ‘focus’ application provider
- Create new Static Application Provider Usages for each of the other applications on which the focus application depends, and connect each usage to the relevant application provider
- Create new instances of the :APU-TO-APU-STATIC-RELATION instances to connect the ‘focus’ application usage to each of the usages on which it depends. In this case the :FROM slot will be the focus application usage and the :TO slot will be the usage of the application on which it depends.
As I’ve described the process, it follows our nearest neighbours approach, where we have a focus application (to which the Static Application Provider Architecture is connected) and only define dependencies that this application has on others. In this approach, there should NOT be any dependencies where the focus application is at the :TO end of the relationships.
This approach means that you have many, smaller and simpler dependency models that are much easier to manage. The Views understand that they must look over all the dependency models, e.g. finding USAGES of the focus application that are at the :TO end of relationships on other application’s dependency models!
All of the instances that I’ve described above can be modelled by hand using the graphical editors but, importantly for this case, can also be modelled via the Import Utility using a combination of simple and derived instances. To follow the pattern I’ve described above, we can define:
- A data capture spreadsheet that has two worksheets. One to define each Composite Application Provider that we want to use and one to define the dependencies. The dependency worksheet could be as simple as two columns for the source and target applications.
- An Import Specification that imports each of these worksheets.
The first worksheet - the ‘Definitions’ sheet - is all about using Simple instances. Perhaps this sheet has two columns; name and description (maybe also an ID column). The Import Activity for this simply creates new Simple instances using the name column and sets the ‘description’ slot with the other column.
The second worksheet - the ‘Dependencies’ sheet - maps the application dependencies. We don’t need any IDs here, as we want to use the names of each in our spreadsheet to ensure that it is easy to define and validate the dependencies as we capture them. We normally use the definitions worksheet to validate these cells to ensure that we don’t have any typographical errors in the dependencies worksheet (and therefore erroneous, duplicate application dependencies).
In our example, let’s say that this worksheet has the 2 columns, A and B which contain:
<SOURCE application> and <TARGET application>
which captures that information flows from the SOURCE application TO the TARGET application.
In the Import Specification for this second sheet, we are going to create a number of derived instances for each row that we import, as follows:
- Create a simple instance for the target (focus) application provider and give this variable a name that makes it easy to use, e.g. aFocusApp. We’ll get this from Column B in the source spreadsheet
- Create a simple instance for the source application provider and give this a variable name, e.g. aSourceApp. We’ll get this from Column A in the source spreadsheet.
- Create a new derived instance of the Static Application Provider Architecture class. We can use a pattern to derive the name for this from the content in the worksheet. Following the nearest-neighbours pattern that I described above, we will use the <TARGET> column for the name of this Application Architecture. This is because the arrows on the dependency model show the direction of the dependency, NOT the direction of information. So, if A is a source of information for target B, then B depends on A.
We can use a simple pattern to define the ID and the name of this derived instance. Note that the import utility will create this instance if it does not already exist and will re-use it if it does exist. We are using the name-based matching mode as the dependency worksheet only contains the names of the source and target application, so we select the ‘ByName’ match mode.
In the Derived Instance forms, we can use a combination of the Column References (e.g. B) and static text to build the name of the Static Application Provider Architecture, e.g. ‘Static Architecture of ‘ B. The ID Format will show the pattern that you’ve defined, with each part (segment) of that pattern show in the ID Segments field. Make sure to push the ‘Set Ref’ button to set the specified column on the selected Reference segment (push the ‘Add Ref’ button to create new references)
Add a new instance slot to this Derived Instance for the ‘static_architecture_of_app_provider’ slot. Set this to the Target Application Simple Instance, e.g. aTargetApp.
- With the Static Application Provider Architecture instance defined, we then create a new Derived Instance for the focus Application Provider’s usage. Following the same pattern as above, we use the ‘ByName’ match mode and create new instances of each usage using a pattern of <B> ‘ usage in static architecture of ‘ <B>.
Next, create a new instance slot and set ‘static_usage_of_app_provider’ to aTargetApp, to specify which application it is that we are using. Then create another new instance slot, this time for the Static Application Provider Architecture, used_in_static_app_provider_architecture, and set this to the name of the derived instance for the architecture (above).
- Next we can create another derived instance, for the source application as above, with the ‘ByName’ match-mode and using a pattern of <A> ‘ usage in static architecture of ‘ <B>. Add the instance slots for the ‘static_usage_of_app_provider’ and ‘used_in_static_app_provider_architecture’ as per the target application usage.
- Define the dependency between the two applications, by creating a new instance of the :APU-APU-STATIC-RELATION class. Again, use the match-mode ‘ByName’. Build the automatic name for this new relation so that it follows the auto-naming pattern in your repository, e.g. “Static Application Provider Architecture of “<TARGET> “: from: “<TARGET>” to: “<SOURCE>. Note that you can use Column A and Column B of your spreadsheet for the <SOURCE> and <TARGET> elements of the pattern but will need to compute the name of the ‘owning’ architecture.
Create the new simple instance slots for the :FROM (set to aTargetApp), the :TO (set to aSourceApp) and the ‘contained_in_static_application_provider_architecture’ (set to aStaticAppArchitecture)
The order of these steps is important to ensure that instances are going to be connected exist before they are used. You can re-order each of these steps as required, in the panel on the left of the editor.
Check the ‘Name Format’ with each of the derived instances to make sure that they match what you expect / require.
This is a pretty complex modelling pattern but once you’ve defined it, capturing those dependencies via the spreadsheet is very simple - just define the applications on one worksheet and then map them to each other on the next.
Make sure to define the Instance Variable Name for each derived instance, as you can see there’s a lot of connections that need to be made between the derived instances. For now, you can ignore the offers to create a template for each type but that might be worth considering once you are comfortable with such import specifications.
Jonathan
; as u can see in the picture the import create the APU-TO-APU dependencies and associate the dependencies to the relative architecture.