Amarco

Amarco  is a "service oriented" method developed by us since 1994. In 1995 we published an article in ROAD - a US Research magazine:  "MARCO - object architecture method".  You can find this article here.  You find here the basic concepts used in Amarco. The notions developed are based on a rich activity in electronic design and telecommunication software design and development.

Afterwards we started to develop supporting software, using from the start a database to store the definitions for systems and services. Than we used Visio (Shapeware Corporation, at that time), to draw automatically diagrams displaying object structures and service exchanges (interfaces) using the database information. Now this kind of diagrams are called "cartography diagrams", as they render the system organization and the information exchanges between system components.

In short: our vision is fundamentally "structure" oriented. A structure may represent an object, a system, a functional bloc etc.  This is recursively used, to build assemblies or to decompose into components. The "service point" notion  and definition is independent to that of an object. By associating a service point to an object, you impose that the same service point be found inside the objects organization, or inside a higher level object that uses it as a component. Also, associated to an object, it shows the flow of the information. More, it defines the coupling points that are to be observed if the object is to be connected to other ones.

As such, Amarco can be seen as an UML extension to support high level service oriented architecture.

For us, a "service" is a request or an answer to a request. By tying the answer to the request, we create a logical unit that can persist from functional analysis to real world implementation.

At their turn, processes are mapped on on objects, traverse the services points and are made of services. As such, they are truly "service oriented processes".

Use cases" and "sequence diagrams" in UML are very near to our "scenarios", except the use of the "service concept". The constraint to identify "requested services " and "rendered services" and to group them into "service points" limits the complexity and eases the global view of systems and the graphical rendering. You can easily model this kind of organization as business oriented "Web services" at higher abstraction levels, like functional domain. Consequently you avoid being overwhelmed by details. If required, you can drill down to a mode detailed view for the components that interest you.

Amarco tools build on these constraints and keep the coherence between various abstraction levels.