|
|
Amarco makes a parallel between objects and systems. An object is an entity that is neatly separated from its environment by a frontier. This frontier is impenetrable, with the exemption of service points areas. We can see the service points as a generalization of the notion of interface. In real life, when two objects connect, they use complimentary solutions for the same purpose: the connection (an electrical appliance has two parts, male- female, but its definition is unique). In real life, when a connection is made, one asks for a service, the other renders one of possible return services. When a call is made through an interface, we can receive various return values. When you address a request to a public service, you may have also various return results. A service point gather associated couples: requested services - rendered services. We call the two complimentary definitions for service points as client and server (like in real life). Two objects connect if one is provided with a client service point, and the other with the server service point. External architecture The external architecture of an object shows the service points and the external systems that are connected. We thus get the global picture:
With the answers at these questions we know the purpose of the system. How it is built at the interior, how it works, all these are questions irrelevant at this time of presentation. We have everything to do a shopping on the market, to ask about the availability of systems that provide theses services. This view may be applied to any system: application software, hardware system, organizational system, company etc. Internal architecture - System structure If we now open the external architecture, we can see the internal structure of the object, with the following remarks:
The whole structure is kept together through the connection between similar (and complimentary: client - server) service points. The internal structure of an object (of a system) is based upon the external architectures of the component objects. In this way we may conceive some iterations of decomposition. Each one will show the embedded objects. These objects can be catalogued. Internal architecture - System behavior We can also study how the system works. An external service request translates into exchanges of requested services and rendered services between the internal objects and potentially some other external objects. We study the behavior of the system by analyzing how it manages to answer with that requested service at a service request. In other words, we can see the internal processes of the system. The process is made of services exchanged between objects. This means that we have a very powerful method to build and analyze any internal process. It is intuitive and rigorous, because any scenario is mapped on objects and service points and is built upon the services exchanged. All the services involved are defined in the service point specification. Consequently, we can easily imagine that such a scenario can be displayed dynamically for a better understanding of its relations in time. With the tools that support Amarco we can build and display the dynamic execution of scenarios. |
|
||||||||||||||||||
|
||||||||||||||||||||