Project?

[lwri...@frogooa.com]

Is the Project class necessary? Project isn't an element explicitly
named in the Mellor and Balcer book, and seems to me to be outside of
the concerns of modeling a domain. I made a similar comment, albeit
not as directed to the "specification", on Sean Kavanagh's OOATool
blog, but he disagreed with me.
Here's my thoughts on this:
* a domain under consideration (for modeling) IS the current project.
i.e., the domain chart defines all the elements needed to construct
that domain. In the Domain portion of the miUML metamodel, this is
covered by the Domain and R7 (Bridge) elements.
* the Project, if I'm reading the model correctly, is being used to
group Domains that might not be related across R7. This is orthogonal
to the goal of modeling a domain. It is an element that should be in
the model for a tool, and the Executable UML metamodel shouldn't be
tool specific, right? ??? Actually, what we are talking about
(following the same semantics that produced the term, "model
compiler") is a model linker.

[ToniS]

A project is what project management defines it to be, to be config
managed accordingly.
Unless the product under development is a tiny-scale single-domain
product it contains a defined number of domains to be developed and/or
updated.
To scale up to larger systems we need hierarchical system products of
components on different product levels interacting across defined
interfaces.
Adding new customer features to an existing large-scale system most
often involves a large number of components and interfaces on
different product levels.
Neither of the above is covered by the Executable UML book from 2002
referred to below. Lots of scaling-up things has happened since.
Short final comments:
* A domain (component + interfaces) is just one the domains under
consideration in a project.
* The Domain Subsystem mainly covers the modelling elements of a leaf-
component in a larger-scale system.
* Since Project and Domain/Component are separate subject matters, the
Project metaclass should be placed in a separate Project Subsystem.
* Since we must preserve PIM vs PSM separation for cross-platform
reuse, a "model compiler" is a separate subject matter too.
* How Domains/Components are "linked" (= wired across interfaces) must
be modelled and, thus, covered by separate metamodel subsystems.
* Projects must be managed via a tool, and if we like to have
portability of models between tools it should be part of the
metamodel.

[lwri...@frogooa.com]

On Mar 7, 5:04 pm, ToniS <toni.siljam...@ericsson.com> wrote:
> Neither of the above is covered by the Executable UML book from 2002
> referred to below. Lots of scaling-up things has happened since.

I think the lack of it (project composition) in the Executable UML
book was intentional. (more reasoning below)

> Short final comments:
> * A domain (component + interfaces) is just one the domains under
> consideration in a project.

This should be qualified with, "by a number of teams" or "at different
times". A domain is supposed to be able to stand alone. Bridges are
anonymous couplings, so the contents of other domains are irrelevant
with respect to the modeling of the domain under consideration of the
modeler(s).

> * The Domain Subsystem mainly covers the modelling elements of a leaf-
> component in a larger-scale system.

... in tool X. Tool Y might have something completely different for
project composition.

> * Since Project and Domain/Component are separate subject matters, the
> Project metaclass should be placed in a separate Project Subsystem.
> * Since we must preserve PIM vs PSM separation for cross-platform
> reuse, a "model compiler" is a separate subject matter too.
> * How Domains/Components are "linked" (= wired across interfaces) must
> be modelled and, thus, covered by separate metamodel subsystems.

OK. I'm saying separate domain, which correlates with separate subject
matter.

[ToniS]

My response to this was to the initial question: Is the Project class
necessary?
I simply "agree" to your question by saying "no, it should be
removed".

In any metamodel part like the miUML Domain Subsystem the fact that
there is a concept called "project" has no relevance.
(no relevance to the subject matter(s) under development/maintained/
being updated)

How different tools, real projects or companies handles the concept of
"projects" is unimportant wrt the model(s) under development.

One can just hope that the tool manages projects in a proper way.

[Leon Starr]

Hey guys, sorry to take so long to respond, but I'm on an ugly (modeling/analysis) deadline for my client and just wanted to let you all know that I am alive and well, monitoring the group.  I should have time to respond by the end of the week.  Hang in there!  Also, I have made a LOT of progress on the Action Language meta in the past couple of months, so that's coming as well.

Back soon!

- Leon

--
You received this message because you are subscribed to the Google Groups "miUML" group.
To post to this group, send email to star...@googlegroups.com.
To unsubscribe from this group, send email to starruml+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/starruml?hl=en.