Concept Framework (2019)
(Paradigm Shifting,  Software Quality, Cognitive Complexity)
Diego E. Malpica Chauvet et al.
okc.mx, diego-malpica@openknowledge.mx

 

The rate of  advances in information technology has been continuously increasing in a way that it is a necessity to continuously review the adequacy and effectiveness of our current set of paradigms in shorter periods of time. In this paper we present our work dedicated to review the paradigms used in the implementation of Knowledge Management Solutions.

  


Abstract

The rate of  advances in information technology has been continuously increasing in a way that it is a necessity to review the adequacy and effectiveness of our current  set of paradigms in shorter periods of time. In this paper we present our work dedicated to review the paradigms we will use in the implementation of our Knowledge Management Solutions.

1 Introduction
Software quality  be expressed as a set of factors [1][2]:
  • Flexibility: The ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed.
  • Maintainability: The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment.
  • Re-usability: The degree to which a software module or other work product can be used in more than one computing program or software system.
  • Scalability: The ease with which a system or component can adjust to changing load 
2 Hypothesis
  • A broader use of Object Oriented Software Construction Techniques may substantially reduce complexity and cost.
  • Multi-tier architectures can become barriers that increases the complexity and decreases the quality of software solutions.
3 Strategy
The strategy for this effort is based in the selection of promising technologies and the  isolation one time efforts by implementing a framework: "Concept Framework"[3]  that with the goal of implement a knowledge management solution solution "Better Tools"[4].
 
These are the main requirements for  "Better Tools" :
  • Provide an integral solution for Knowledge,Commitment and Resource Management.
  • Support for at least 10000 concurrent users.
4 Execution
We identified various promising technologies using our "Paradigm Shifting Methodology"[17] that is illustrated in Figure 1 with the following criteria:
  1. Favor technologies based in the same paradigm for example "Object Oriented"  to increase re-utilization and reduce the number needed models and specialties (languages and tools).
  2. Define a metric:  "Cognitive Complexity" that will be the product of  the number of models  by number of tools used to implement the solution.
  3. Favor "Promising technology " that are the ones that has stated (even in an informally brochure) that they may increase the return of investment, reducing complexity and/or costs.
  4. Identify and replace the Obsolete technologies that acts as barriers increasing the complexity or preventing the adoption of promising technologies. 
 
4.1 Paradigm Shifting
Figure 1
4.1.1 Multi Layer/Tier Architectures(Top-Down)
Layers : "Logical layers are merely a way of organizing your code. Typical layers include Presentation, Business and Persistence ”the same as the traditional 3-tier model. But when we are talking about layers, we are only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function"[5][6]. Typical layers are:
  • Presentation Layer : User Interface, the main function is to translate the tasks and results to something the user can understand.
  • Business Layer : Coordinates the application processes commands and make logical decisions and evaluations, and performs calculations. I moves and processes data between the two surrounding layers.
  • Persistence Layer : Information store and retrieval from data base system.
Tiers: "Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers".[5][6].

4.1.2 Object Oriented Architectures (OO)
An object-oriented system[7] is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves them sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it decides on its own what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object. Object Oriented Systems[8] are constructed as structured collections of abstract data types implementations.

4.1.3 Service Oriented Architecture s (SOA)
In software engineering, a service-oriented architecture is a set of principles and methodologies for designing and developing software in the form of inter-operable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration. [9]

4.1.4 Model View Controller (MVC) 
A model view controller[9] (design pattern), separates concerns in tree roles:
  • Model: A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands.
  • View: A view requests from the model the information that it needs to generate an output representation.
  • Controller: A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document).

The common interpretation of MVC (Smalltalk-80) differs from the autor (Trygve Reenskaug) intention presenting layers. The original MVC (Trygve-78) is OOP friendly. "Its purpose was to bridge the gap between the user’s mind and the computer held data. The center of this solution was the Model that was a representation of the user’sdomain information. The View was an editor that enabled the user to inspect and modify this information. The Controller coordinated the capabilities of several Views making it a comprehensive tool that the user applied in the performance of specific tasks"[19]

4.1.5 Model View Presenter (MVP)
Model-View-Presenter is a derivative of the Model-View-Controller (MVC) software pattern, also used mostly for building user interfaces. In MVP the presenter assumes the functionality of the middle-man (played by the controller in MVC). In MVP, all presentation logic is pushed to the presenter. Eventually, the model becomes strictly a domain model.
MVP is a user interface design pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:
  • Model: is an interface defining the data to be displayed or otherwise acted upon in the user interface.
  • View: is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
  • Presenter: The Presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.
4.1.6  Data Context Interaction (DCI)
The essence of object orientation is that networks of communicating objects work together to achieve a common goal. DCI  paradigm separates a program into different perspectives where each perspective focus on a certain system property. Code in the Data perspective specifies the representation of system state. Code in the Context perspective specifies runtime networks of communicating objects. Code in the Interaction perspective specifies how the networked objects collaborate to achieve the system behavior.

4.1.7 Naked Objects Architecture
Naked objects favors a Object Oriented Approach that is based in the original MVC (Trygve-78)[19] supporting the following principles [18][19]:
  • All business logic should be encapsulated onto the domain objects. This principle is not unique to naked objects: it is just a strong commitment to encapsulation .
  • The user interface should be a direct representation of the domain objects, with all user actions consisting, explicitly, of creating or retrieving domain objects and/or invoking methods on those objects. This principle is also not unique to naked objects: it is just a specific interpretation of an object-oriented user interface(OOUI).
    The original idea in the naked objects pattern arises from the combination of these two, to form the third principle:
  • The user interface should be created 100% automatically from the definition of the domain objects. This may be done using several different technologies, including source code generation; implementations of the naked objects pattern to date have favored the technology of reflection.
Naked Objects considers that he most important principle of object-orientation is 'behavioural completeness': an object should completely model the behaviour of the thing that it represents[22].

4.1.8 Object Oriented Software Construction (OOSC)
Object Oriented Software Construction considers software quality as a consequence of modularity. [8]

4.1.9 Object Oriented User Interface (Vaadin)
"The server-side development model doubles productivity by automating everything related to browser and ajax communication. Built-in themes make your application look great, data sources help you connect to the back-end and the UI components make building a great user experience easy. You could say that Vaadin is a super set of GWT for business oriented applications with focus on developer productivity. [12]

4.1.10 Object Oriented Persistence (DDB)
Differential Data Base our own persistence engine inspired on DB4O and the Prevalent System pattern that state:
  • DB4O, no time is spent on learning a separate data manipulation or query language. Unlike incumbent, string-based, non-native APIs (such as SQL, OQL, JDOQL and others) Native Queries and LINQ are 100% type-safe, 100% refactorable and 100% object-oriented, boosting developer productivity by up to 30%. [13]
  • Prevalent System, Prevayler is the simplest and fastest way to provide ACID persistence for your "plain old Java objects".[21]
4.1.11 Aspect Oriented Programming (AOP)
To integrate different tools may be difficult, object oriented tools may be complemented using aspect oriented tools to take care of cross-cutting concerns. [14]
"In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.
AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while aspect-oriented software development refers to a whole engineering discipline."[14]
 
 
5 Results
We manage to isolated two objective and relevant metrics that are number of models and number of specialties used as a key indicators of the complexity and the effort needed to implement a solution.
We had to implement our own persistence engine Differential Data Base (DDB) inspired on DB4O.
We measure our architecture against conventional architectures and we obtained the following Cognitive Complexity Metrics:

Architecture

Granted Paradigms

Reviewed Architecture

Concept Framework

Reviewed Architecture and Framework 

Overall Characterization

Different Models
Different Tools
Separation of Concerns

Different Models
Same Tools
Separation of Concerns

Same Model
Same Tools
Crosscut Concerns

Presentation

Documents
HTML(1)
Objects
JScript(2)
Object Document Mappers
JSP(3)

Objects
Java(1), Vaadin(2)

Objects
Java(1),
Vaadin(2),
Concept Framework(3),
AspectJ(4)

Application

Objects
Java(4)
Object Relational Mappers
Hibernate(5)

Objects
Java(1), Vaadin(2), DB4O(3)

Persistence

Relational Tables
SQL(6)

Objects
Java(1),
DB4O(3)

Models (M)

3

3

1

Technologies (T)

6

3

4
Cognitive Complexity (M x T) 18 9 4
 
Figure 1: Object Oriented Model
Figure 2: "OKC Dynamic Knowledge Repository" sample screen shoot.

6. Conclusions
  • We manage to use one model instead of three and to avoid the principal self imposed physical and logical barriers while maintaining a good concern separation and modularization. The numbers of specialties (languages and tools) needed was significantly reduced. The main requirements was cover with one time efforts focused on the "Concept Framework".
  • There are big opportunities for increase the productivity by the broad use object oriented techniques and tools.
  • By promoting object/aspect oriented approaches we are in the way of diminishing barriers in order to reduce the complexity of the solutions.

7. Future Work
We will continue our work focused in productivity and user experience in our open source releases for the "Concept framework" and or "Dynamic Knowledge Repository".
7. Open source Licenses
Share Center platform is composed by several Open Source Products that complies with the open source license GPL 3.
 
9. References
[1] "Object-oriented Software Construction" , Bertrand Meyer. Prentice Hall International Series in Computer Science, 1988, Great Britain.
[2] "Metrics in software quality assurance" , J. E. Gaffney Jr., ACM '81 Proceedings of the ACM '81 conference, Pages 126-130. http://dl.acm.org/citation.cfm?id=809854
[6] "The difference between layers and tiers" ,
[7] "Object Oriented Analysis and Design" ,
[8] "Object Oriented Software Construction" ,
[9] "Model View Controller",
[12] "Object-Oriented Presentation Layer", https://vaadin.com/gwt
[14] "Aspect-Oriented Cross-cutting Concerns",
[17] "Paradigm Shifting",
[18] "Naked Object Principles Wikipedia", http://en.wikipedia.org/wiki/Naked_objects
[19] "Naked Object Principles Richard Pawson's PhD thesis ", http://downloads.nakedobjects.net/resources/Pawson%20thesis.pdf
[21] "Prevalent System design pattern", http://prevayler.org/
[22]  "Naked Objects", http://www.nakedobjects.org/book/section12.html
[23] ¨DB4O Database for Objects¨, https://en.wikipedia.org/wiki/Db4o