Software intensive systems are systems strongly depending on supporting software. The software is typically large, complex, and it as a rule interacts with human users. The failure of the software implies failure of the system usually causing substantial losses. Such systems are critical. The prospective redevelopment all at once of the software is no feasible solution. It is shown that such software should usually be service-oriented. The interfaces of services should be user-oriented (well understood by users and the users can use it easily). The services should be of two basic types: application services and architecture (enabling to develop an architecture) services. We present the most important infrastructure services as basic service-oriented design patterns.
TopIntroduction
We understand as software intensive systems the systems strongly depend on supporting software. The software is typically large and the design of the systems should take into account the activities of people, the users of the system. To be more specific, the dependency of the system on its software implies that the system cannot work properly if the supporting software does not work (fails). The software is moreover so complex that its redevelopment effort is so high and its development duration so large that the redevelopment of the entire system in “Big Bang” manner is no feasible solution. A very important but often neglected dimension of the software intensiveness is the degree of user involvement (agility) in the system and software actions and the degree of interaction of the system with real world.
All the aspects imply that the software supporting software intensive systems is a very complex high-tech engineering artifact. As such the software must be properly structured in the large. It must have a proper architecture.
The architecture should meet the following requirements:
- 1.
The all at once (re)development of the system is too costly and time consuming so the architecture should enable a cheap seamless integration of existing (large) software artifacts like legacy systems, third party products, or newly developed artifacts.
- 2.
The integration of the artifacts usually must not influence existing capabilities of the artifacts and their availability (but it can enhance them). It implies that the local (existing) user interfaces must be preserved, and eventually extended. These conditions enable that the exiting users of the “old” artifacts capabilities need not be aware that the integration just takes place or that the artifact has already been integrated.
- 3.
The integrated software artifacts should be integrated with minor changes, if any, of its code to save the integration investments, to reduce the errors caused by the changes, and to reduce other undesirable effects affecting the users.
- 4.
The integration of artifacts can be gradual (incremental). No “Big Bang” is necessary.
- 5.
The resulting system should be easily maintainable (enhanced, extended, per partes modified).
- 6.
It is desirable that the architecture is good for the application of modern development and integration methods (prototyping, incremental development, agile development, and the support for the overall improving software engineeringsoftware engineering quality of the new product).
- 7.
The architecture should enable the effective implementation of the requirements of business people. An example is the support, supervision, and use of business processes offered by the system. The processes must be understood by human process users to enable online modification of the processes and commitment of business steps.
We must be aware that architecture in general means integration in the large. A change of an architecture type implies changes of the development processes. Let us remember the following analogy: Being able to lay bricks (objects or small programs) does not directly imply the ability to build good houses (large artifacts). The ability to build good houses need not imply the ability to develop good towns (large software-intensive systems).
Large technical artifacts, large software systems inclusive, cannot be reasonably developed as logical monoliths (compare power plants). Such systems must be built as compositions of quite large components and complex autonomous units. The compositions can be again composed into larger compositions, if appropriate. In software it implies that we must start with entities providing basic capabilities. In software systems the entities are usually called applications. We must have also software entities enabling communication, collaboration and orchestration of collaborating applications as well as the users and maybe real-world entities. The main, if not one and only, feasible way to implement such software systems is service orientation. Service orientation assumes that the system has a specific structure (architecture), that it has service-oriented architecture (SOA). Service-oriented (SO) paradigm and SOA are the proper solution for the majority (if not almost all) of large software (intensive) systems (Král & ·Žemlička, 2002).