Re: UML - Modeling Interfaces in "complex" systems

Responding to Lilly...

Dear all, we are modeling a "complex" system involving

1- an existing ERP
2- an existing Planning and Budget Systems (PBS)
3- a new Advanced Planning and Budget Planning System (APBS),
that takes input data from 1 and 2 and sends them some Output data ad
well.

New APBS system is a package we just have to buy from supplier,
no real development involved inside our company, except for
interfaces.

So we modeled ERP, PBS and APBS as 3 Packages

I can buy APBS as a package since it will be third party software. But I would expect both ERP and PBS to be multiple packages for anything other than a Ma & Pa business.

BTW, in UML v2.0 they changed things. The <<subsystem>> stereotype is now derived from Component rather than Package. This was because Packages were really intended to support configuration management and version control rather than application partitioning (i.e., they defined what model elements were relevant to a release rather than defining a logical unit of the software itself). If you look at the semantics of <<subsystem>> you will see that it is a much better fit to what you are describing than Package. Corollary: the Component Diagram is now a better place to describe application partitioning in the Systems Engineering sense than the Package Diagram.

I tried the normal way i.e. exposing interfaces but that's not really
useful, I find it better
to depict interface as a Class or Artifact and then draw "uses" lines
among packages.

e.g. the interface that takes data from ERP into PBS is depicted like
this
| PBS | ---uses--> | I_ERP_PBS_interfacename | ----- uses -----> |
ERP |

This is fairly routine. You can use the Interface model element (aka lollipop) and associate it with a subsystem just like you would with a class. In a Component Diagram you can provide associations between the <client> subsystems and the Interfaces to indicate which interfaces are paired with which subsystems.

However, the arrows are dependencies, not associations. They should go directly between the subsystems because they capture the relative level of abstraction and a client/service view of the flow of requirements. That really doesn't have anything to do with interfaces. That is, the communications implicit in interfaces are orthogonal to the logical dependencies between subsystems.

For example, one might have a low level subsystem for the UI. The rest of the application defines requirements for it and depends upon it to communicate with the software user, so the dependency arrows go TO the UI subsystem. But the UI is very likely to initiate almost all of the actual communications as the user does things interactively in the UI. So the UI will be mostly talking to the interfaces of the other application subsystems rather than the other way around.

Also I can't find a nice way to depict
- frequency (or expected volume) of needed interfaces,

You can't. That has nothing to do with the resolution of functional requirements. At best, it just specifies a nonfunctional requirement and UML is not a requirements specification notation.

- availability of existig ones

Presumably any Interface model element you identify will be needed available to clients in the solution. Remember that the Component and Package Diagrams are essentially static views of the system. They don't describe how and when things are used dynamically.



*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: implementing roles in OOP......
    ... > object has to satify is by implementing the interfaces of those roles. ... different subsystems abstract the same ... entity with different views tailored to the subject matter. ...
    (comp.object)
  • Re: Is this the DIP confusion?
    ... > implementation package? ... The dependency referred to by the DIP is usage dependency, ... You DIP when you create the interfaces and use them instead ... and have the functionality providers expose ...
    (comp.object)
  • Re: One class per file?
    ... I checked the Python style guide and there seems to be no ... dependencies (well, the non-abstract dependencies anyway, interfaces ... package, and make the "public" classes visible on a package level by ... Interfaces in python represent an implicit dependency. ...
    (comp.lang.python)
  • Re: How Our Brains Ignore Unpleasant Facts was: Re: The Reasonable
    ... subsystems that don't have any idea about the other components status, ... and independently the interfaces between ... Nowhere in real life activities ...
    (talk.origins)
  • Re: Is this the DIP confusion?
    ... You could try to forget about DIP and build some application. ... I have been accused by Mr Martin as practicing OOOD - overly object ... I have interfaces coming out of every corner of my applications, ... Do you generally put your interfaces in the client package? ...
    (comp.object)