I agree that change over time is a major factor. Using systems and procedure that capture and manage change should be a part of any project. In fact, they should be the core of a project's risk management strategies (we all know about "risk management", don't we?).

It is said that when something is measured, it is changed. As a corollary, when something is analyzed, it is changed.

In systems development, we must not only capture and manage change, we must desire and embrace change wherever we can instigate it.

Life is change; without it, there is no life. Are we not all change masters?

A very interesting thread so far, but I would caution against the Systems Approach thinking (aka. the "water Fall" ontology). If Design has a start, both an end and a sequential ordering of processes could be implied.

Known generically as the Scientific Methodology (aka. RUP), parallel iterations are today's "Best Practice". In that ontology, Requirements Gathering, System Design, Software Development, etc. are all timeless, parallel processes. They began with the Big Bang and will end with the Big Collapse (I think :-/). Kinda like my wife's never ending shopping trip. Process boundaries are fuzzy, not crisp as in the Water Fall approach.

Project beginings, endings and internal milestones are management artifacts imposed on a system's process for defining points of review and approval. Process boundaries are management vehicles for assigning areas of accountability, and perhaos, modus operandi. For clarity of thinking, I like to keep the Whos and the Whens apart from the Whats, the Whys, and the Hows.

I agree with Thomas. I view a Use Case as a protocol specification between actors and the system. If the protocol does not change from a prior system, what new business benefits do the stakeholders gain? Yeah, one may argue for cost reduction, but new systems aimed at revenue enhancements or operational improvements yield a bigger payback.

I was hoping Sparx Sales would chime in on this one. I know what you are looking for, but I'm not aware of any EA add-on that will do it. However, since the EA repository is a relational database one may access directly, you could roll your own package if you wish.

Are you asking about using EA for activity based costing of domain level activities such as a manufacturing process, or are you asking about cost accounting for software development projects driven by UML activities?

While I've had similar organizational thoughts, thinking deeply I see more complexity from a management perspective than I care to deal with at this time. I'll take the high road, treating Sparks as a fully encapsulated object, and simply concern myself with their Unique Interface The implementation details are theirs to wrestle with.

I do wonder at times...Does Sparks develop Use Cases that get reviewed with Stakeholders? If so, do they fully depend upon EA to write them? :-/

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.

Please implement a control to manage the font size on Association stereotypes. I'm planning on using EA for a Podcasted UML course, but at the current size, the stereotype text is not visible on class diagrams.

Actually, I should be able to control the font size of everything that might appear as text on any UML diagram.