Re: How to correctly model API dependencies in UML


If the GUI is encapsulated in a subsystem or layer, then the /only/ classes that exist there are things like Window and Button.


It's not. I shouldn't have taken that example :)
It's not only a GUI thing, I was more referring to the general problem, when you heavily use some API (for whatever purpose), and its classes and objects are strongly related to your own classes, be it through inheritance, composition or whatever.
The question then would be, how to integrate these into your class diagram for example, without remodelling the whole API.

Then the question is: API to what? If it allows external access, then the API should be expressed as a subsystem interface (e.g., the methods presented by a Facade pattern class). IOW, the API itself should not have multiple classes; it should be a simple message-based data transfer interface to minimize coupling. So I think we need a specific example of what you mean by 'API'.

[There is an exception. When the client and service have very different views of the semantics, it is sometimes necessary to introduce a "buffer" subsystem to provide the transformation of views. Such a subsystem is essentially a two-way version of a Facade interface class that may be implemented with multiple classes. However, both client and service still perceive it as a single message-based interface; they just "see" different sides of it.]


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Loading