views:

116

answers:

4

I've created a service which enables users to connect to the server with mobile phone and send some data. Now I have to prepare a formal service presentation - present the whole architecture, how the data are exchanged and then also the complete presentation of the client side and server side. So far I haven't written any formal documentation so I would really appreciate if anyone could recommend any good book or web resource where any good examples (graphic representation and code - object and process description) could be found.

Thanks!

+1  A: 

There are a number of languages for representing architectural models that attempt to present the architecture at a number of different levels (See TOGAF and Zachman). You could describe it like this, but it might be overkill for what you want.

I'd stick to a two or three diagrams that present the architecture from a number of different levels. At the lowest level you would have the protocols and low level code required to talk to the service. At the highest level you would have a conceptual block level diagram to describe the major components in the system (mobile phone, server). Between those two levels you should focus on modeling a specific aspect of the system - a UML sequence diagram is good for describing order of events between components.

There are a few books on software architecture, some of them can be a bit fluffy though. There's a very good article by Neal Ford that describes software design and architecture here:

http://www.ibm.com/developerworks/java/library/j-eaed1/index.html

I'm not sure any of them will really help you with what you want to convey here though. The best thing to do is to keep it simple...

Jon
A: 

There are as many different styles of architecture documents as there are architects. You might as well just take a shot at it yourself.

Identify the components of the solution. Describe the inside of each component at the level of detail that is required. This includes code modules, databases, frameworks that you used, etc.

Then, for each of the components that you have already described, find the interfaces that are either used by the solution internally, or that are used by external applications, and document them. This would include your service descriptions.

Add a couple of diagrams, and that's about it.

cdonner
A: 

Applying UML and patterns

Andrei