David;
I share your reservation about the languages. I was hesitant to mention any specific languages in my first post, there are, of course, more than two AOP languages. I also recognize that generating code to weave aspects together at the byte code levels is very complex; but must I wait for that kind of code generation before I can begin to model separated concerns?
I strongly believe that Aspect Oriented Modeling solves some significant modeling issues and that the AO community is getting close to bringing their ontology into the modeling mainstream. Other tool developers are hard at work to implement the ontology (yes, even including Microsoft
). We don't want to be left behind; or, as business analysts, we want to keep ahead of the early adopting programmers so that they get proper guidance.
Personally, we are not interested in code generation support. We won't be until we can get the PIM models correct, and that means being able to model cross cutting concerns, etc. And the most important aspect modeling place to start is with Use Case Stereotypes and related elements that support aspect notations--similar to those suggested by Jacobson & Ng. Shortly thereafter, I'll be looking for the ability to associate attributes and behaviors to named aspects so that I can easily generate diagrams (of specific concerns) without having to set element visibilities at tediously low levels of granularity.
I think the issue of
concerns feeds directly into database views too.
I've been watching EA develop for 6+ years now and I always thought of EA/Sparxians to be a leading force in the modeling world, I hope they continue to sustain that leadership. I hope that control of Sparks is not moving from the ontologists to the financial and/or marketing managers! If that happens, I'll have to reconsider my options for, in my 30+ years of experience, that has always been the end of a good product.
Show Posts
Process boundaries are fuzzy, not crisp as in the Water Fall approach.
