Foundations of ISA – Base paradigm – Scale ISA global
Iteration 1: Available paradigms overview
Let me make a first list of artifacts oriented paradigms applicable at ISA in its whole:
Before being able to choose among these paradigms, let's make a grid of pros and cons on them at the ISA scale in its whole.
| Meaning | |||
| No main paradigm is defined. All paradigms of any kind can be implemented. | |||
| Pros | Lets many oportunities to innovative approaches and technologies.
Reactivity to changes. Normalization could compensate some of the problems listed below. |
||
| Cons | That's the current situation where every things, every kind of software or of hardware product can be done in any possible ways. This leads to technological proliferation, to difficulties in integrations, to incompatibilities, to important impedance mismatch needing Mediator (like ESB) to achieve interoperability, to the quick obsolesce of technology.
This approach also leads to solutions that are the more quickly available even if it is not the more pertinent (and almost always should I say): MSDOS, TCP/IP, HTML, REST, etc. On the other hand, the basics of existing way of doing things are often never really questioned. It is impossible to change the base paradigm if there is no shared one. Therefore this leads to paradigms stratification and cohabitation. Some examples: Operating Systems based on the Unix principles, Object Relational Mapping, Resistances of programming languages, Programming languages embedding several paradigms. This situation also limits innovation by rendering paradigm shifts difficult (Cf. Thomas Samuel Kuhn – The Structure of Scientific Revolutions). |
||
| Meaning | |||
| The object concept is put at the heart of the architecture. An Object is the computing representation of a real world concept.oo Programming is the main implementation of the oo concept.In ISA, oo means that most or even all artifacts are objects. | |||
| Pros | Long experience in language conception, application design and programming using the oo concepts. This branch of computer science is one of the most mature.
The community recognized advantages of the OO approach.(Cf Ups and Downs of Object-Oriented Systems Development – Advantages). OO is applicable to a wide range of IT issues (Cf. Wikipedia). OO merge the concepts of Type and of Module this promotes abstraction and reuse. The encapsulation ensures the isolation of the inside/outside of an object making a frontier. This limits change impacts and provide a clear interface to externals. The polymorphism is a way to manage dependancies. It inverts the dependency by transfering the flow of control to another module relying only on a given interface. |
||
| Cons | The community recognized disadvantages of the OO approach.(Cf Ups and Downs of Object-Oriented Systems Development – Disadvantages).
OO is usualy limited to programming and doesn't always fit well with other Information Technology artefacts (files, database, OS, etc.). By definition an Object is unitary oriented, this has advantages, but it also explains why it does not support well with transversal behaviors or the ensemblist approach, and this either at larger scale (like classes) or at a smaller one (like fields). Merging the concepts of Type and of Module leads to almost fine grained modules, needing a wider modularization system like packages (Java) or namespace and assembly (.NET). The static typing and the inheritance are rigid structurations requiring several Design Patterns in order to have more flexibility. The dynamic typing doesn't help to structure a software system and is difficult to program. These complexities limit system size. OO is also not a natural approach for the humans, at least at first, because they are more procedural, case of use oriented. This is often also the way soa services are implemented: In a procedural way, not thru true Facade and/or Business Object (Cf. Anemic Domain Model). There is the noticeable exception of direct object manipulation like in drawing software, and also, to a lesser extent, in documents editions software. OO doesn't provides in it self a way to deal with concurrency. There are of course several practices (mutex, immutable, etc.), but not a common basic mechanism. Distributing objects could drive to performance and reliability issues (Cf. First Law of Distributed Object Design: “don't distribute your objects” . M. Fowler) |
||
| Meaning | |||
| This paradigm is directly derived from the mathematical Sets notion. They can be defined informally as collections of objects. In computer science and in information technologies, Sets are mainly present via the relational model. This model relies on the set theory. It can be formally expressed using this root branch of mathematics. The relational model has proven its efficiency in database management systems (RDBMS). | |||
| Pros | Very efficient for large volume data access in a transactional and consistent context (ACID properties).
Availability of the standardized SQL language. This language is powerful, efficient and largely diffused among professionals. Long experience in the IT field. This technology is very mature. |
||
| Cons | While OO focus in providing a model of the world it represents, Sets are just what they are in themselves (collections of objects). Therefore, this situation can be seen like this : OO is an approach for building systems from an outside point of view with an ad hoc dedicated paradigm. While Sets starts from what they are, and the design and development activities consist to put the real world in that paradigm (mainly in that way of representing data). This leads to have rigid structures. Not efficient for very large data storage (Big Data). Performance limitation when multiple navigations are required (number of joins). |
||
| Meaning | |||
| This paradigm also relies on a branch of mathematics. At its heart, there is the evaluation of mathematical functions.The functional programming only applies to activities of coding the treatments of computer science. | |||
| Pros | Solves several classes of problems in a concise, efficient and elegant manner.
Efficient and secure in multithreaded contexts. |
||
| Cons | While OO focus in offering a model of the world it represents, The Functions, like Sets, are just what they are in themselves, and in particular for functions on what they do. Therefore, this situation can be seen like this : OO is an approach for building systems from an outside point of view with an ad hoc dedicated paradigm. While Functions starts from what they do, and the design and development activities consist to put the real world in that paradigm (in that way of representing behaviors). This leads to make behaviors done in an unilateral way. Which can be uncomfortable to deal with, in particular for wide scale systems. Difficult to apprehend for most programmers, and even very difficult for some kinds of features (state management, monad). Can drive to build unstable systems when operating a large scale (lazy resolution, stack overflow). Generally less performant than imperative programming. |
||
This long list of paradigms properties could be discussed. And the readers are encouraged to do so.
However, in order to go a step further, one can state that the Object Oriented paradigm has not really any concurrent. The others paradigms are limited in scope, and the “without paradigm” approach is not ideal… Before all, this is not in accordance with the ISA requirements expressed in the post “Foundations of ISA – Base paradigm – Requirements“.
So, despite of all it's (well known) problems, the OO paradigm is retained for ISA.
It can be argued that not all paradigms have been evocated (like Aspect, Role or Subject). It's true, but none of them has the importance of the ones detailed here. Moreover, together with the Sets and functional ones, these paradigms could be mobilised to compensate the OO weaknesses.
So the next post, will go a step further Iteration 2 will focus on the OO implementation in ISA.
Atomic paradigm Another way to address the OO problems, and also the most important ones of others paradigms, could be to create a new paradigm. This new paradigm should be both as modular as Object Oriented and as efficient as Relational and Aspect on scale change (down and up). In my experience, the only way to get a fine grain result, is to work at that finest grain scale. Otherwise, when you aggregate, you lost some information. Therefore, it appears that it is necessary to work at the most basic constituant level : the atom.We can call this paradigm “Atom Oriented“. It could be close to the graph oriented model (and database). This new paradigm will be discussed in a post as soon as possible. While this new paradigm could have the same extension that the OO, it is not mature at all, since I have just invented it ! Therefore ISA can not be build on it. |