Interconnections between the Paradigm of SWC and Object Orientation

It is often argued why to introduce or invent a new paradigm — e.g., a software confederation paradigm — when object-oriented paradigm works fine. We must point out that the SWC paradigm was invented long time ago and have been used in practice with very good results. It is an optimal tool for large and/or real-time software systems. The SWC paradigm is applicable in the domain where object-oriented paradigm is not optimal and vice versa.

It follows from the above discussion that object orientation and confederation orientation are substantially different paradigms. Let us repeat the main differences (compare Table 1):

  1. Object orientation is not based on the concept of massively parallel systems implemented as an open P2P network of permanent services and utilities. Object-orientation started from sequential programs; object-oriented programs are not massively parallel. They have a controlled level of parallelism (compare the activity diagrams in UML).

  2. Basic building units in OO are methods encapsulated into classes. The practice indicates that in well-written OO programs, the methods tend to be rather (very) simple. Therefore, the complexity of class methods is also very low. It implies that the developers must remember a very large number of interfaces and methods. The OO programs must be therefore understood and visible in quite small details. The concept of UML components is trying to change it, but the success is still not too convicting. The most important consequence is that under these circumstances, the system must usually be designed as one logical entity without black boxes inside. It does not exclude the possibility that it is distributed. It increases development effort, limits the modifiability and openness of the developed system.

Table 1: The comparison of autonomous components an object-oriented components
 

Middleware orientation-autonomous components

Object orientation-object-oriented components

concurrency

Inherently parallel

Tend to be sequential, parallel rather an added feature

interface

Interface asynchronous, message oriented, messages have complex syntactic structure

Primarily synchronous, procedure call oriented, syntax - procedure calls only

building units

Components rather large, autonomous, components used as black boxes

Building units (objects, components) tend to be small; system usually designed as a whole and then decomposed by grouping building units

middleware

Middleware properties and/or services should be explicitly specified

Middleware properties used mainly implicitly

On the other hand, the confederative orientation need not be an optimal attitude for the development of very small systems. It is usually optimal to apply object orientation during the development of the small systems for which it is not effective to use confederative architecture (we call such systems atomic ones).

UML is not as an object-oriented tool not fully applicable in the case of SWC. Applied cannot, it seems, be the diagrams describing the implementation details like class diagrams an sometimes the state transitions diagrams.

Useful are the diagrams describing the interaction of the system with the environment, especially:

  • Use Case Diagrams.

  • Diagrams able to describe scenarios like sequential diagrams, activity diagrams and collaboration diagrams.

  • A modification of data-flow diagrams intended to be included into new UML standard.

It follows that there are no available diagrams describing the internal dynamics of software confederations. Due to the properties of a SWC-like message routing, the diagrams should describe only some chosen activities of the confederation.



Managing Globally with Information Technology
Managing Globally with Information Technology
ISBN: 193177742X
EAN: 2147483647
Year: 2002
Pages: 224

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net