Show Posts
1
General Board / Re: Best diagram to model layered architecture
« on: January 16, 2008, 06:42:36 am »
Good suggestion. I will look into the collaboration diagram as an option.
I do see exactly what you mean with the concept of these 'component's being instances. I still disagree in this instances however. Perhaps I should have used a more viable examples than 'components'.
If you consider 2 logical layers, lets say business layer (BL) and data access layer (DAL), and you want to show the possible allowed interactions between these, including allowed 'self' interaction, then unless you make up arbitrary instances to represent multiple copies of the BL or DAL, then you need some way to be able to show these logical layers multiple times on the same diagram.
Now granted, if I have multiple DAL layers listed on a diagram, I can certainly see that this walking a fine line between instance and logical layer, so I don't fault your arguement. I guess I'm just convinced that there is a subtle difference here, primarily because I'm still showing logical layers. I.e., I am not showing an implementation of a DAL, I'm showing the logical concept of a DAL in order to document its allowed interactions with other layers, and even itself. Of course this will be realized with real DAL component implementations, and once we have an idea of a couple of actual applications we could created a diagram to depict the physical implementation plans of a given application. But, at this point, I would want to pull out the logical diagram and review the plan to make sure the implementation is within our planned architecture.
I guess another angle on this, if you're still not buying into my logical vs instance arguement, is that it is a matter of practicality. If I am creating models during the logical architectual planning, and I have no real instances/components, I should be able to list my logical items multiple times to show interaction at this level. Even if I have a couple of applications that have components I could use to model this, it doesn't make sense, because the interactions I'm modeling are global to all possible applications, and it wouldn't make sense to try to use any one implementation to capture that. So I'm left with the option of creating arbitrary, fake instances, which clutter up my model, and are impossible to maintain (because they are all, for example, DAL, DAL, DAL, DAL, BL, BL, BL, BL, not App1BL, App2BL, App1DAL, App2DAL.
Having said all of that, I will look into the collaboration diagram. Perhaps this is what I need. Also, I would like to be clear that I'm not trying to say that your arguement is invalid. It may be dead on for the diagrams we're talking about, and perhaps I have not found the correct diagram I need to capture this type of information yet. I hope this is the case. If it is not, then I really hope EA considers this as an option (not a primary work flow, but at least an option). Or I'm going to have to look into other products because I have to do a lot of this and it is just not practical using EA given my current understanding of the product and diagrams. So I do hope I find a diagram that meets the need.
Thanks
I do see exactly what you mean with the concept of these 'component's being instances. I still disagree in this instances however. Perhaps I should have used a more viable examples than 'components'.
If you consider 2 logical layers, lets say business layer (BL) and data access layer (DAL), and you want to show the possible allowed interactions between these, including allowed 'self' interaction, then unless you make up arbitrary instances to represent multiple copies of the BL or DAL, then you need some way to be able to show these logical layers multiple times on the same diagram.
Now granted, if I have multiple DAL layers listed on a diagram, I can certainly see that this walking a fine line between instance and logical layer, so I don't fault your arguement. I guess I'm just convinced that there is a subtle difference here, primarily because I'm still showing logical layers. I.e., I am not showing an implementation of a DAL, I'm showing the logical concept of a DAL in order to document its allowed interactions with other layers, and even itself. Of course this will be realized with real DAL component implementations, and once we have an idea of a couple of actual applications we could created a diagram to depict the physical implementation plans of a given application. But, at this point, I would want to pull out the logical diagram and review the plan to make sure the implementation is within our planned architecture.
I guess another angle on this, if you're still not buying into my logical vs instance arguement, is that it is a matter of practicality. If I am creating models during the logical architectual planning, and I have no real instances/components, I should be able to list my logical items multiple times to show interaction at this level. Even if I have a couple of applications that have components I could use to model this, it doesn't make sense, because the interactions I'm modeling are global to all possible applications, and it wouldn't make sense to try to use any one implementation to capture that. So I'm left with the option of creating arbitrary, fake instances, which clutter up my model, and are impossible to maintain (because they are all, for example, DAL, DAL, DAL, DAL, BL, BL, BL, BL, not App1BL, App2BL, App1DAL, App2DAL.
Having said all of that, I will look into the collaboration diagram. Perhaps this is what I need. Also, I would like to be clear that I'm not trying to say that your arguement is invalid. It may be dead on for the diagrams we're talking about, and perhaps I have not found the correct diagram I need to capture this type of information yet. I hope this is the case. If it is not, then I really hope EA considers this as an option (not a primary work flow, but at least an option). Or I'm going to have to look into other products because I have to do a lot of this and it is just not practical using EA given my current understanding of the product and diagrams. So I do hope I find a diagram that meets the need.
Thanks