I need other opinions, please

[GMFMAS]

good Morning (here);

I am collaborating auditing internally some design models made by a company with EA and the end user is very formal with the model reviews.

My client made the software system partition with a package diagram and not with a deplyment diagram for abstraction purposes. Also, before this work my client and the end user agreed a general scope document in which this product would be made using a package diagram.

the diagram shows packages and associations with multiplicity between them.  No dependencies. I understand that there is no semantic arguments to make this and that the onlt formal allowed connections between packages are dependencies and nesting relationship.

I would like to know your opinion, in order to enforce my internal quality report.

Thank you for all

gmas

[Paolo F Cantoni]

gmas,

Some clarifications perhaps?

I am collaborating auditing internally some design models made by a company with EA and the end user is very formal with the model reviews.

The company is your client,  not the end user?

My client made the software system partition with a package diagram and not with a deployment diagram for abstraction purposes. Also, before this work my client and the end user agreed a general scope document in which this product would be made using a package diagram.

So your client appears to have met the, agreed, requirements?

The diagram shows packages and associations with multiplicity between them.  No dependencies. I understand that there is no semantic arguments to make this and that the only formal allowed connections between packages are dependencies and nesting relationship.

Your role is to perform an internal audit for your client prior to delivery of the model to the end user?

Or have I misunderstood everything?

Paolo

[GMFMAS]

Hi Paolo;

Yes I have to make a prior audit (internal) to muy client before to deliver the product to the end user, which will make another formal (and definitive) audit.

I've made an overview audit but I want to contrast with your opinion (peope of this forum) about it.

thanks

[thomaskilian]

And the problem is that the client wants to use a Package Diagram rather than a Deployment?

[KP]

the diagram shows packages and associations with multiplicity between them.

A package is a namespace - I can't think of a sensible reason why a namespace would have a multiplicity.

I understand that there is no semantic arguments to make this and that the only formal allowed connections between packages are dependencies and nesting relationship.

Also PackageImport (quote: a relationship that allows the use of unqualified names to refer to package members from other namespaces) and PackageMerge (quote: defines how the contents of one package are extended by the contents of another package).

[Paolo F Cantoni]

Hi Paolo;

Yes I have to make a prior audit (internal) to my client before to deliver the product to the end user, which will make another formal (and definitive) audit.

I've made an overview audit but I want to contrast with your opinion (people of this forum) about it.

thanks

I forgot to ask:
What s the UML competence level of:
1) your client
2) the end user
3) and you?

And a clarification - are you independent of your client?That is, you are in a contractor or consultant role with respect to them for this specific assignment only (at this time).

Are you able to provide some indication of your findings in the overview audit?

As you've already pointed out, and we've confirmed, there doesn't seem to be much semantic relevance to what you've been provided.  Apart from meeting the requirements (who decided them - do you know?) what rationale have you been provided for the use of the package diagram?  For example, what did your client mean by the association multiplicities between the packages?

HTH,
Paolo

[alexander]

A package is a namespace - I can't think of a sensible reason why a namespace would have a multiplicity.


Also PackageImport (quote: a relationship that allows the use of unqualified names to refer to package members from other namespaces) and PackageMerge (quote: defines how the contents of one package are extended by the contents of another package).

Agreed, packages should have only dependency relationships with other packages or interfaces.
A relationship with cardinality doesn't make much sense to me.