Concept Java Framework


Published on

Simplified Framework for developing Object Oriented Rich Internet Applications (Java+Vaadin+DB4O+AspectJ).
It uses the "Paradigm Shifting Technique" to identify opportunities and obstacles.

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Concept Java Framework

  1. 1. Concept Framework (2012­1014) (Layers, Tiers and Barriers) Diego E. Malpica Chauvet et al., diego­ Abstract Simplified Framework for developing Object Oriented Rich Internet Applications 1 Introduction In these last two decades there has been a lot of advances in information technology, there is so much change that it is essential to continuously review the adequacy and effectiveness of our paradigms. Our current paradigms for example the ones related with multi­tier architectures can get in our way becoming effective barriers against software quality. In this paper we present part of our work dedicated to review our current paradigms: tools, techniques and architectures. There are lot of tools and techniques that may help to increase the quality by reducing the complexity and cost. They all share common goals that can be expressed as a set of factors [1][2] like: 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 Techniques may substantially increase solution development quality reducing complexity and cost. Multi­tier architectures represented by mayor platforms .Net, and JEE have become barriers that difficult to use techniques like Object Oriented and Aspect Oriented. Tiers are mainly based in t functional decomposition Top­Down techniques. Each tier may increases the complexity to establish contexts, and to coordinate events and actions. The communication between layers can have a severe negative impact in the complexity and performance of the solutions. 3 Strategy We try various promising object oriented tools and techniques isolating one time efforts in a framework from effort of developing specific solutions. So we made two efforts: One effort to develop a framework that we named "Concept Framework"[3], and other to develop a end user application using the framework that we called "Share Center"[4]. These are the main requirements for the "Share Center" application: Provide and Integral solution considering three mayor topics in the problem domain: Knowledge, Content and Commitment Management. Support for at least 1000 users with high concurrency. Define an updated architecture and tools considering the problem domain and the quality factors that affect the full life cycle of software solutions. 4 Execution We identified and selected several promising techniques and tools. The selection was done to using a "Paradigm Shifting Technique"[17] that is illustrated shown in Figure 1. The selection criteria favours object oriented technologies
  2. 2. with common tools and knowledge base in order to increase re­utilization and reduce the number of specialities needed to develop a solution. As metrics we defined the specialities needed for development and the number of models needed/used to document and implement the solution. The last criteria we used for the selection of technologies is the one that defines a promising technology for our work we define a promising technology as the one that has stated (even in an informally brochure) that they may increase the return of investment , reduce the complexity and/or cost. 4.1 Paradigm Shifting Paradigm Shifting from 1991 to 2013 2005 BUP & EPF Virtualization Mobile WWW CPU (Hardware) Operative System Languages Frameworks DataBase Presentation Architecture Quality Applications Social Technologies 1979 Unix 1981 MS­DOS 1966 DOS 1985 Windows 1991 Linux 2007 Linux Android 1993 Newton 1988 Mac 2004 Linux­Ubuntu 1978 8086 1982 286 1993 Pentium 2006 Dual Core 2007 Quad Core 2011 10 Core 1988 SUN softpc 1979 IBM VM 1997 MAC virtualpc 1998 VMWare 2003 XEN 2008 KVM 1993 Newton 2007 Kindle 2010 Ipad 2011 Galaxy 2007 IPhone 2007 Android 1991 HTML 1995 AWT 1999 JSP 2002 Vaadin 1992 OpenGL 2006 GWT 1.0 2004 JSF 1.0 1993 Mosaic 1994 Newton 1994 Netscape 1996 Safari 1998 Firefox 1995 IExplorer 2011 BBerry 2011 FFox M 2011 Chrome 2007 Safari M 2008 Android M 2008 Chrome 2009 Opera M 2001 Explorer M 1996 Apache 1987 CMM 1989 ITIL 1991 SCRUM 1993 MSF 1999 XP 2003 RUP 1998 ASP 1996 Flash 2007 SilverLight 1999 GPU 2013 1996 Palm 2000 PocketPC 2001 Win XP 2009 Win 7 1996 Win NT 1987 OS/2 1984 GNU 2008 Atom 2002 CMMI 1990 WWW 2000 PocketPC 1960 1980 1990 2000 2010 2011 Chrome M 2009 GWT 2.0 2007 Vaadin/GWT 1970 2000 2010 1990 1960 1980 1970 1975 Tandem 1991 Tandem­Mips 2001 Tandem­Itanium 1975 Tandem T/TOS 1994 Tandem OSS (Unix) 2006 JSP­JSTL 2000 HTML 4 2008 HTML 5 1991 2006 Linux 2.4 2011 Linux 3.0 2001 MAC OS 10 2012 MAC OS 10.8 2009 2009 JSF 2.0 1997 WAP 2013 Vaadin 7 1970 DBMS 1978 RDMS 1979 Oracle 1997 Oracle ORDBMS 1994 Mysql 2004 DB4O 2001 HSQL 2005 H2 1980 OODMS 1988 Oracle RDBMS 1979 MVC 1980 OSI 1998 XML 1981 RPC 1996 DCOM 1997 RMI 1998 SOAP 2000 REST 2007 Cloud 2000 Ajax 1997 MVP 1987 Sybase RDBMS 1989 Microsoft SQL 1967 Object Oriented 1983 Internet 1970 Chat 1970 Enail 1991 WWW­3 Layer 2002 RIA 2002 Prevayler 1972 C 1972 SQL 1983 C++ 2001 AspectJ 2001 C# 2003 Scala 1999 J2EE 2000 .NET 2001 Hibernate 2006 OpenJDK 2005 Harmony 1967 Simula 1968 BI 1980 BPMS 1970 Ecommerce 1984 Staroffice 1989 MS office1990 ERP 2000 OpenOffice 2006 Google Docs 2011 MS Off365 2000 RSA Public 1991 ISO­S. Engineering 1993 ISO­S. Process 1960 RFC 1950 Freesoftware 1970 BBS 1958 Lisp 1959 Cobol 2007 Clojure 2004 BPMN 2004 OODVS 2009 JSF 2.0 2002 Spring2000 Liferay 1991 MS Visual Basic 2004 Eclipse 1991 MS Power Builder 2012Win Phone 8 1985 MacApp 1995 Java 1996 Cocoa 1991 MS Visual Basic 1995 Wikis 1997 Google 1998 Opensource 1999 Sourceforge 2001 Wikipedia 2003 Linkedin 2004 Facebook 1990 WWW 1995 MS Visual Studio 1997 Netbeans 1995 Java 1995 PHP 1995 JavaScript 1997 UML 2012 Win 8, WinServer 2012 Linux U Unity 2012 Linux Android 4.1 2008 Hyper­V Granted Obsolete Old and Valid Target New Promissing 2009 Mongo DB 2007 Amazon EC2 2009 Windows Azure 2009 Google Apps Engine 2010 OpenStack 2006 Twitter 1999 RSS 2006 OpenUP 2001 OWASP & ISO­Security 1993 MSF 1993 EDI 2004 PCI 1990 Versant ObjecttDB 2007 Hadoop 2010 Maria DB 1980 DIS 1993 CORBA 2000 HLA 1998 Java 3D 1995 VRML 2004 Hypper Threading 1980 Small talk MVC 2004 Naked Objects 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].
  3. 3. Layers Persistency (DB4O) Same Model and Same Paradigms(Tools) (Java,AspectJ) Presentation (Vaadin) Logic Tiers Presentation Document Oriented Logic Object Oriented Persistence Relational Oriented Presentation Object Oriented Logic Object Oriented Persistence Object Oriented Diferent Models and Same Paradigms(Tools) Presentation Object Oriented Logic Object Oriented Persistence Object Oriented Diferent Models and Diferent Paradigms(Tools) Same Model and Same Paradigms(Tools) 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) Architecture 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). 4.1.5 Model View Presenter (MVP) Architecture 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
  4. 4. 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 Naked Objects Architecture Naked objects favors a Object Oriented Approach that is based in 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 favoured the technology of reflection. 4.2 Tools These are the tools that we found interesting in terms of improving productivity by promoting the use of object oriented approaches. 4.2.1 Business Layer (Code Quality) There are several quality metrics that can be measured and enforced in object oriented code that may increase developer productivity and example may be: Increase In Developer Productivity When Using Jtest 90% . [11] 4.2.2 Presentation Layer(GWT/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 backend and the UI components make building a great user experience easy. You could say that Vaadin is a superset of GWT for business oriented applications with focus on developer productivity. [12] 4.2.3 Persistence Layer (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] 4.2.4 Cross­cutting (AspectJ) 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 specialities used as a key indicators of the complexity and the effort needed to implement a solution. We measure our architecture against conventional architectures and we obtained the following numbers: Architecture Granted­Paradigms Reviewed Frameworks Reviewed Architecture Overall Characterization Different Models Different Tools Separation of Concerns Different Models Same Tools Separation of Concerns Same Model Same Tools Separation of Concerns Crosscut Concerns Presentation Documents HTML(1) Objects JScript(2) Object Document Mappers JSP(3) Objects Java(1), Vaadin(2) Objects Java(1), Vaadin(2), DBO(3),Application Objects Objects
  5. 5. Java(4), EJBs(5) Java(1), Vaadin(2), DB4O(3) AspectJ(4) Persistence Relational Tables SQL(5) Object Relational Mappers JPA(6) Objects Java(1), DB4O(3) Models 3 3 1 Specialities 6 3 4 Complexity 18 9 4 We generated a single model for the solution. Concept Concept Concept Wrapper Property Concept Container BaseI Wrapper BaseI PropertyPresenter File Article Organization Person Group ProjectPermision CommentCommitment Wrapper child parent child property instance Inheritance Composition Figure 2: Object Model
  6. 6. Figure 3: "Share Center" Solution. 6. Conclusions 6.1 We manage to use one model instead of three and to avoid the principal physical and logical barriers while maintaining a good concern separation and modularization. The numbers of specialities (languages and tools) needed was significantly reduced.The main requirements was cover with and must of the effort was for the framework(first time effort). 6.2 Regarding or initial hypothesis we confirmed that a top­down approach is generalized in the multi tier architectures been its main representatives .Net and J2EE. 6.3 There are big opportunities for increase the productivity by the broad use object oriented techniques and tools. 6.4 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 to validate and measure the productivity achievements as a constant effort After the fist internal release we will work on the open source release for the "Concept framework" and the "Share Center" Application. 8. Licences
  7. 7. 9. References [1] "Object­oriented Software Construction" , Bertrand Meyer. Prentice Hall International Series in Computer Science, 1988, Great Britain.­Oriented_Software_Construction [2] "Metrics in software quality assurance" , J. E. Gaffney Jr., ACM '81 Proceedings of the ACM '81 conference, Pages 126­130. [3] "Concept Framework" , [4] "Share Center" , [5] "Multitier architecture" , [6] "The difference between layers and tiers" ,­the­difference­between­layers­and­tiers [7] "Object Oriented Analysis and Design" ,­oriented_analysis_and_design [8] "Object Oriented Software Construction" ,­Oriented_Software_Construction [9] "Model View Controller", [11] "Java Software Quality Assurance", [12] "Object­Oriented Presentation Layer", [13] "Object­Oriented Persistence Layer",­ 8.1/java/reference/ [14] "Aspect­Oriented Cross­cutting Concerns",­oriented_programming [15] "CMMI Level 5", [16] "Model View Presenter",­view­presenter [17] "Paradigm Shifting", [18] "Naked Object Principles Wikipedia", [19] "Naked Object Principles Richard Pawson's PhD thesis ",
  8. 8.