Specifying relations into component diagrams

[Davide]

Hi,
I have to document in a standard formalism (UML 2.1) the software architecture of a system to built. The software architecture is actually well defined and documented in a classical non-standard formalism i.e. PowerPoint  Now, how to translate it into UML2.1? I’ve started using a component diagram but I got difficulties in describing:
1.The middleware: how to describe a bus that interconnects all the components? My idea is to use a component called Middleware that is connected to all the components but it seems pretty weird.
2.The relations: how to describe the relations among components or their relation with the middleware? Some relations are asynchronous, other synchronous, other unidirectional, etc. My Idea is to define my own stereotypes, but again, it seems weird because these types of relations are pretty standard so there may be a related standard formalism.

Thanks for your suggestions,
Davide

[thomaskilian]

I guess there's nothing wrong in introducing a Middleware component. Depending on your legacy cemetery you might end up in a moloch, but that's live.

Regarding the connections: I use socket/plug connectors between components to show their relation to each other. Then I create instances where I plug in ports and exposed interfaces to show concrete relations. I further create traces to interface classes which hold all the information necessary to describe the (legacy) communication. The use of Tags helps a lot here.

I'm not completely comfortable with this methodology but have not come across something that fits better.

[Krzysztof Swiatkowski]

Seems like you are trying to mix two parts of architecture description. One is static structure showing what components are present and whether they are connected and can send a message to each other. Second is communication where synchronous, asynchronous and unidirectional _messages_ will be presented -> sequence or communication diagram should do fine and you woan't need to define new stereotypes.
I think that by trying to put all information on one diagram you may clutter the documentation instead of clarifying it.

And as for Middleware component I don't think it is bad. If your components don't communicate directly their messages still have to go somewhere.

Regards Kris

[Oliver F.]

Welcome to the modeling life...
Seems as you have stumbled across the standard pitfalls

First it is a good idea to think about what exactly you would like to visualise and for whom. Who is your target audience for that document ?
Eg. in my case there is a bunch of stake holders- product mangement would like to see the requirements being covered, testers have to build test cases out of it, system engeneers will have to deploy and install the solutions, developers realize implementations out of it, etc.

And, not to forget, in a few months somebody (or you/me) will have to maintain the whole thing and would like to know what those strang architecture guys thought when they did all those stupid things.

From those stakeholders the corresponding views must be identified:
- A functional/behavioral view for showing behavior and interactions between components and objects
- A structural (logical) view describing the architecture and habitat of the components involved
- Eventually a deployment view describing parameterisation and physical composition of the various components for installation
- Maybe a requirements view which describes the basic requirements (UseCases, Business Rules, Features, NFRs, etc.) which can then be linked to eg. activities or components to identify the relation between architecture and requirements, etc.
- tbc

It is not a good idea to generally mix those views- one can do it on a very high and abstract level, but one will see that the overview will get lost rather quick.
In general it is good idea to concentrate on one view instead of trying to describe everything at once.

The bad news: How to transform the requirements from Powerpoint textual representation to a formal UML view has been subject of loads of science.
A good idea could be to look for an article or book about software design and architecture. I once started with a book by Craig Larman ("Applying UML and patterns"), which was very helpful, but is a bit outdated today.

Oliver