Here's the transcript, for those that need it:
00:00:00
Hello, in this video I thought I'd cover some of the features associated with this Executable MBSE profile, so I'll just look at the requirement analysis side of it and I'll start by creating a project.
00:00:17
Doesn't really matter too much about this example. The first thing to know about the profile is that it's a helper to be able to set up and create model. I don't have a single model structure, rather I try and build kind of reusable components developed by different people in different models that can be shared. One aspect of that is this idea that particular packages, which have particular types, can be consumed by different projects or they could be stacked in the same project.
00:01:00
So, when I say create a project, I always create it with one of these structures. Now here's an example.
A use case package structure creates a package for doing use case modeling, but it doesn't just create that package, it also creates a shared app package and optionally a requirement package.
00:01:27
And it does it based on a unique name. In this case, I'll just take the default. The idea of that unique name is that you might have different people working on different aspects of the system, which you could call features or functions, but essentially they are collections of use cases, or more importantly, they have ownership within the model.
00:01:52
Where somebody could be working in this package independently with someone working in a different package, and this is what I mean by stacking.
00:00:00
Hello, in this video I thought I'd cover some of the features associated with this Executable MBSE profile, so I'll just look at the requirement analysis side of it and I'll start by creating a project.
00:00:17
Doesn't really matter too much about this example. The first thing to know about the profile is that it's a helper to be able to set up and create model. I don't have a single model structure, rather I try and build kind of reusable components developed by different people in different models that can be shared. One aspect of that is this idea that particular packages, which have particular types, can be consumed by different projects or they could be stacked in the same project.
00:01:00
So, when I say create a project, I always create it with one of these structures. Now here's an example.
A use case package structure creates a package for doing use case modeling, but it doesn't just create that package, it also creates a shared app package and optionally a requirement package.
00:01:27
And it does it based on a unique name. In this case, I'll just take the default. The idea of that unique name is that you might have different people working on different aspects of the system, which you could call features or functions, but essentially they are collections of use cases, or more importantly, they have ownership within the model.
00:01:52
Where somebody could be working in this package independently with someone working in a different package, and this is what I mean by stacking.
00:02:01
So, if I create another use case package here, I'm going to stack it. This is Feature B and I’ll create a separate requirements package for that because it's owned by a different user.
00:02:17
I could flow the requirements here into the same requirements are developed by the other feature, but I'm grouping requirements here in terms of features, but I am sharing the active package so here I have feature B package.
00:02:33
Which is kind of like user A and user B packages, but this is common model. And I I could develop these in different models and then bring them together later, and an aspect of that is the unique naming of the package because that unique naming also relates to the file on the file system.
00:03:00
So this is an .sbsx file. What we call it unit and Rhapsody. I'm so here I am, I'm user A working on feature A and this is going to have a use case Trap a mouse involving the homeowner.
00:03:21
Some of the settings here about what actors are created in the actor package to begin with are driven from properties on the model, and there’s subject for this Executable MBSE profile where I've grouped together the properties. These are the default actors.
00:03:43
You can change the property file in the profile if you're in a particular domain where there's certain actors and like automotive, or you could just create the actors and rename them.
00:03:59
I always have an Environment actor, and I'm not going to remove that. That's quite useful. I can explain a little in a different video, perhaps, why that's the case.
00:04:12
One of the features of this profile is to flow requirements from a use case package into a requirements package, and that's just to automate one of the very common manual steps when performing requirement analysis with the use cases.
00:04:29
This, perhaps, is a requirement about the goals of what the mousetrap is going to do. So, the goal might be “The mousetrap shall remove mice from the home”.
00:04:51
This refinement tool is actually added by the profile, so there are customizations here to make the process of creating models a lot smoother just by putting certain tools into the pallets in the right places according to the profile and the process.
00:05:13
Fundamentally, what relationship we're going to use for use cases? Well, if I chose a refinement, then I put it in the toolbar rather than make people draw dependencies and apply a new term (which is going to have its own problems). So let's now will show you another bit of automation.
00:05:32
If I double-click, this question appears. This is the profile’s plugin that's running because of this Executable MBSE profile, and this is what we mean by accelerating a process with a toolkit that uses product automation to automate steps.
00:05:57
This has created an activity diagram with a template for performing use case analysis with some properties set on the diagram to make it easy to write free flowing text, and this is one of my approaches to use case modeling and so rather than model functions here, I'm going to model steps of the use case that I might have written in a Word document.
00:06:26
And I just feel that that's a very easy and accessible method which can then be used to perform more detailed analysis later. It's also very easy to get non-technical or non-model-based system engineering experts to get value from modeling very quickly.
00:06:48
So, the preconditions are that “the trap is set”. Then the “Mouse enters the trap” and the “Trap springs capturing the mouse”. Obviously, this could have a bit more of complicated flow, but I've got pre and post conditions associated with the use case, and I can build one scenario for this use case and go on to expand it with decision nodes.
00:07:33
I have also simplified the Activity Diagram toolbar here. My automations are done with new term stereotypes, and this is a textual activity diagram that this profile has been set up to create actively diagrams with.
00:07:51
And that just removes some of the things like action pins and activity parameters and swim-lanes because I'm not going to use them for this part of the model so don't give people the option because we want consistency in our modeling.
00:08:13
We don't want, when we are doing large scale modeling, to have deviations from the method, unless those deviations are considered important in the process. Which means we'd modify the helper or the profile accordingly, rather than allow people to do everything.
00:08:38
This method has some other automation here that's useful. Notice, for example, the actions on activity diagrams have different action text from their name in the browser. This is one of the things in Rhapsody because it was built for software code generation initially, it has this idea of keeping the names in the browser so that they don't have things like spaces, and they are essentially codable.
00:09:19
To these actions to appear in DOORS Next, for example, with the same name as the text there's some automation here to effectively auto rename actions and this automation is similar to that provided by the SE toolkit, which supports the Harmony/SE methods.
00:09:42
This particular helper, this Executable MBSE helper, is an alternative to the Harmony/SE toolkit, and it does some of the similar things.
00:09:52
I've got some naming conventions here, for example. This activity diagram is a child of the use case, so it has the same name. So, if I rename the name of the use case, I have some automation to be able to auto-update the activity diagram names. This just helps keep the model consistent.
00:10:18
So, it's very subtle. One of less subtle things is this idea of capturing requirements and moving them automatically into this requirement package, and I do particularly find this quite valuable to collect the requirements together in the same location. There's also a little helper here to create requirements from the text of the actions.
00:10:44
It's just putting a requirement on the diagram, taking the text on these actions and it also moves that requirement. It does this providing that there's a dependency from the use case package to a type of package, which is a requirement package, then that automation moves that requirement into that requirement package. I don't need to write the text from scratch, I can just manipulate the text that’s there.
00:11:24
So those are some of the automations associated with the requirement analysis section. If I go one step further, because obviously I might have multiple use case packages, I could have one use case package for the whole system if I was just, you know one developer, but really I'm trying to get different people to be working on different parts of the model to avoid conflicts and people editing the same diagrams and using the diff merge because although Rhapsody can do that, sometimes it just makes sense to organize your users so that they are isolated and use case analysis is a very good way of doing that.
00:12:08
I therefore have these types of packages. New term packages in the model and rather than have ”base” UML packages I think the new term packages give a bit more ability to get straight to the point of action, tthe place on the coalface where the users are working.
00:12:35
So rather than have a big office where everybody is doing everything., I'm organizing my accountants to be in the same room, and my workshop to be slightly differently because people working in the workshop are going to need different tools than someone working in the accountancy office, and that's how I organize these models.
00:12:56
And that goes as far as also changing the right click menus. I've got a very simplified right click menu for the use case packages because I'm not going to do block definition diagrams here. My requirements packages are for capturing requirements, so I can have tables and matrices but not use case diagrams.
00:13:20
The profile provides focus for parts of the model to have particular roles, and that becomes important when we look at the process, which is the flow of information between different developers and modelers across a large organization or a large project.
So, if I create another use case package here, I'm going to stack it. This is Feature B and I’ll create a separate requirements package for that because it's owned by a different user.
00:02:17
I could flow the requirements here into the same requirements are developed by the other feature, but I'm grouping requirements here in terms of features, but I am sharing the active package so here I have feature B package.
00:02:33
Which is kind of like user A and user B packages, but this is common model. And I I could develop these in different models and then bring them together later, and an aspect of that is the unique naming of the package because that unique naming also relates to the file on the file system.
00:03:00
So this is an .sbsx file. What we call it unit and Rhapsody. I'm so here I am, I'm user A working on feature A and this is going to have a use case Trap a mouse involving the homeowner.
00:03:21
Some of the settings here about what actors are created in the actor package to begin with are driven from properties on the model, and there’s subject for this Executable MBSE profile where I've grouped together the properties. These are the default actors.
00:03:43
You can change the property file in the profile if you're in a particular domain where there's certain actors and like automotive, or you could just create the actors and rename them.
00:03:59
I always have an Environment actor, and I'm not going to remove that. That's quite useful. I can explain a little in a different video, perhaps, why that's the case.
00:04:12
One of the features of this profile is to flow requirements from a use case package into a requirements package, and that's just to automate one of the very common manual steps when performing requirement analysis with the use cases.
00:04:29
This, perhaps, is a requirement about the goals of what the mousetrap is going to do. So, the goal might be “The mousetrap shall remove mice from the home”.
00:04:51
This refinement tool is actually added by the profile, so there are customizations here to make the process of creating models a lot smoother just by putting certain tools into the pallets in the right places according to the profile and the process.
00:05:13
Fundamentally, what relationship we're going to use for use cases? Well, if I chose a refinement, then I put it in the toolbar rather than make people draw dependencies and apply a new term (which is going to have its own problems). So let's now will show you another bit of automation.
00:05:32
If I double-click, this question appears. This is the profile’s plugin that's running because of this Executable MBSE profile, and this is what we mean by accelerating a process with a toolkit that uses product automation to automate steps.
00:05:57
This has created an activity diagram with a template for performing use case analysis with some properties set on the diagram to make it easy to write free flowing text, and this is one of my approaches to use case modeling and so rather than model functions here, I'm going to model steps of the use case that I might have written in a Word document.
00:06:26
And I just feel that that's a very easy and accessible method which can then be used to perform more detailed analysis later. It's also very easy to get non-technical or non-model-based system engineering experts to get value from modeling very quickly.
00:06:48
So, the preconditions are that “the trap is set”. Then the “Mouse enters the trap” and the “Trap springs capturing the mouse”. Obviously, this could have a bit more of complicated flow, but I've got pre and post conditions associated with the use case, and I can build one scenario for this use case and go on to expand it with decision nodes.
00:07:33
I have also simplified the Activity Diagram toolbar here. My automations are done with new term stereotypes, and this is a textual activity diagram that this profile has been set up to create actively diagrams with.
00:07:51
And that just removes some of the things like action pins and activity parameters and swim-lanes because I'm not going to use them for this part of the model so don't give people the option because we want consistency in our modeling.
00:08:13
We don't want, when we are doing large scale modeling, to have deviations from the method, unless those deviations are considered important in the process. Which means we'd modify the helper or the profile accordingly, rather than allow people to do everything.
00:08:38
This method has some other automation here that's useful. Notice, for example, the actions on activity diagrams have different action text from their name in the browser. This is one of the things in Rhapsody because it was built for software code generation initially, it has this idea of keeping the names in the browser so that they don't have things like spaces, and they are essentially codable.
00:09:19
To these actions to appear in DOORS Next, for example, with the same name as the text there's some automation here to effectively auto rename actions and this automation is similar to that provided by the SE toolkit, which supports the Harmony/SE methods.
00:09:42
This particular helper, this Executable MBSE helper, is an alternative to the Harmony/SE toolkit, and it does some of the similar things.
00:09:52
I've got some naming conventions here, for example. This activity diagram is a child of the use case, so it has the same name. So, if I rename the name of the use case, I have some automation to be able to auto-update the activity diagram names. This just helps keep the model consistent.
00:10:18
So, it's very subtle. One of less subtle things is this idea of capturing requirements and moving them automatically into this requirement package, and I do particularly find this quite valuable to collect the requirements together in the same location. There's also a little helper here to create requirements from the text of the actions.
00:10:44
It's just putting a requirement on the diagram, taking the text on these actions and it also moves that requirement. It does this providing that there's a dependency from the use case package to a type of package, which is a requirement package, then that automation moves that requirement into that requirement package. I don't need to write the text from scratch, I can just manipulate the text that’s there.
00:11:24
So those are some of the automations associated with the requirement analysis section. If I go one step further, because obviously I might have multiple use case packages, I could have one use case package for the whole system if I was just, you know one developer, but really I'm trying to get different people to be working on different parts of the model to avoid conflicts and people editing the same diagrams and using the diff merge because although Rhapsody can do that, sometimes it just makes sense to organize your users so that they are isolated and use case analysis is a very good way of doing that.
00:12:08
I therefore have these types of packages. New term packages in the model and rather than have ”base” UML packages I think the new term packages give a bit more ability to get straight to the point of action, tthe place on the coalface where the users are working.
00:12:35
So rather than have a big office where everybody is doing everything., I'm organizing my accountants to be in the same room, and my workshop to be slightly differently because people working in the workshop are going to need different tools than someone working in the accountancy office, and that's how I organize these models.
00:12:56
And that goes as far as also changing the right click menus. I've got a very simplified right click menu for the use case packages because I'm not going to do block definition diagrams here. My requirements packages are for capturing requirements, so I can have tables and matrices but not use case diagrams.
00:13:20
The profile provides focus for parts of the model to have particular roles, and that becomes important when we look at the process, which is the flow of information between different developers and modelers across a large organization or a large project.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.