Objectives
1. Knowledge sintetization in domain of formal modeling of component-based systems - comparative analysis of different modeling methods
2. Development of a component model as formal as possible, that will allow a further precise analysis
3. Creating a new algorithm for automatic generation of the structure of a component-based system from a set of given formal specified components
Software systems continue to become larger and more complex. In the
most theatres where complexity is an issue, a winning technique has
been to break the problem into pieces and then create the required
solution by combining a collection of these pieces. This technique has
been deployed in software development as the need arises to mange the
construction and control of systems more effectively.
Development process of a component-based system is made of two processes: component development and system development.
When building a system from components, we have the same concerns when we design a large software system: system's structure (which parts are it to be made of) and system's behavior (how will these parts collaborate in order to realize our requirements). Deciding how the components will be plugged together is the structural description.
Deciding how they will each use the services of the others to realize our requirements is the behavioral description. From other point of view, building a software system by combining collections of components consist of: a) the connection of components in order to fit; b) understanding of what interconnections mean and what the behavior of the entire system is of if it behaves as requirements.
The matter of making pieces of software which will fit together has been the subject of considerable effort and systems and schemes exist which address these issues (COM, EJB, and RMI). Typically, these arrangements work by managing and controlling the interfaces between components (as well as providing some underlying support). By forcing components to conform to rules about how they interact with the outside world, these systems ensure that components do not damage each other when they are connected.
The other problem is more subtle and difficult. We need to ensure that the assembled system does what is required. Just because the interfaces between two components permit them to be connected is no assurance that the system do what we want to do or what we expect to do: even if two components can be connected, this does not assure us the way they interact or even that making the connection makes any sense at all. One approach to solving this problem is to enhance a component's interfaces with requirements about their use, with the way of composing them. This approach has shortcomings: even for small components decorating interfaces in this way is an enormous task and would prevent the component from being used for a purpose which was not envisaged when it was designed.
The real solution to this problem is to reason about and check the behavior of a system and the components from which it is built. These activities must be completed without having access to system, because the system must be built. Even for trivial systems these activity is discouraging, but models can help. These models do not need to replicate the behavior of the whole system. All they need to do is to represent the particular aspects of the behavior of the system which we are concerned to check. This means that these models can abstract away unimportant detail which in turn reduces their complexity and the amount of time and effort required to construct them.
Development process of a component-based system is made of two processes: component development and system development.
When building a system from components, we have the same concerns when we design a large software system: system's structure (which parts are it to be made of) and system's behavior (how will these parts collaborate in order to realize our requirements). Deciding how the components will be plugged together is the structural description.
Deciding how they will each use the services of the others to realize our requirements is the behavioral description. From other point of view, building a software system by combining collections of components consist of: a) the connection of components in order to fit; b) understanding of what interconnections mean and what the behavior of the entire system is of if it behaves as requirements.
The matter of making pieces of software which will fit together has been the subject of considerable effort and systems and schemes exist which address these issues (COM, EJB, and RMI). Typically, these arrangements work by managing and controlling the interfaces between components (as well as providing some underlying support). By forcing components to conform to rules about how they interact with the outside world, these systems ensure that components do not damage each other when they are connected.
The other problem is more subtle and difficult. We need to ensure that the assembled system does what is required. Just because the interfaces between two components permit them to be connected is no assurance that the system do what we want to do or what we expect to do: even if two components can be connected, this does not assure us the way they interact or even that making the connection makes any sense at all. One approach to solving this problem is to enhance a component's interfaces with requirements about their use, with the way of composing them. This approach has shortcomings: even for small components decorating interfaces in this way is an enormous task and would prevent the component from being used for a purpose which was not envisaged when it was designed.
The real solution to this problem is to reason about and check the behavior of a system and the components from which it is built. These activities must be completed without having access to system, because the system must be built. Even for trivial systems these activity is discouraging, but models can help. These models do not need to replicate the behavior of the whole system. All they need to do is to represent the particular aspects of the behavior of the system which we are concerned to check. This means that these models can abstract away unimportant detail which in turn reduces their complexity and the amount of time and effort required to construct them.