3D Builder begins
Fury::1
.
3D::Google
![[ Puerto Cero Uno ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiXs7hWiiK0_ETMqSqjEYdPtKVGAtAw_S16cM3u-3t1kwYIw-FM1aSQeOkrlr9lmqom-9Kw9kz0ZoPNXfpYGC_CIbLwn20L7Ps3leRsUpjPp63xioaYTeMLJsI-2JnRc8mWwH76Jbhn-jx/s752/puertocerounobanner.jpg)
Java/J2EE, Spring, Linux
viernes, 22 de diciembre de 2017
domingo, 3 de diciembre de 2017
Design by contract (Software engineering, Bertrand Meyer)
1. Design by contract
As object-oriented techniques steadily gain ground in the world of software development. users and prospective users of these techniques are clamof object-oriented or more and more loudly for a “methodology” software construction - or at least for some methodological guidelines.
This article presents such guidelines, whose main goal is to help improve the reliability of software systems. Reliability is here defined as the combination of correctness and robustness or more prosaically, as the absence of bugs.
Everyone developing software systems. or just using them, knows how pressing
this question of reliability is in the current state of software engineering. Yet the
rapidly growing literature on object-oriented analysis, design, and programming
includes remarkably few contributions on how to make object-oriented software
more reliable. This is surprising and regrettable, since at least three reasons justify
devoting particular attention to reliability in the context of object-oriented development:
The cornerstone of object-oriented technology is reuse. For reusable components, which may be used in thousands of different applications, the potential
consequences of incorrect behavior are even more serious than for application specific developments.
Proponents of object-oriented methods make strong claims about their beneficial effect on software quality.
Reliabitity is certainly a central component of any reasonable definition of quality as applied to software.
*The object-oriented approach, based on the theory of abstract data types,
provides a particularly appropriate framework for discussing and enforcing
reliability.
Reliability is even more important in object-oriented programming than elsewhere. This article shows how to reduce bugs by building software
components on the basis of carefully designed contracts.
The pragmatic techniques presented in this article, while certainly not providing infallible ways to guarantee reliability, may help considerably toward this goal. They rely on the theory of design by contract. which underlies the design of the Eiffel analysis, design, and programming language’ and of the supporting libraries, from which a number of examples will be drawn.
The contributions of the work reported below include a coherent set of methodological principles helping to produce correct and robust software; a systematic approach to the delicate problem of how to deal with abnormal cases. leading to a simple and powerful exception-handling mechanism; and *a better understanding of inheritance and of the associated techniques (redeclaration, polymorphism, and dynamic binding) through the notion of subcontract, allowing a systematic approach to using these powerful but sometimes dangerous mechanisms.
Most of the concepts presented here have appeared elsewhere. They were previewed in the book “Object-Oriented Software Construction”; and a more complete exposition was presented in a recent book chapter,”from which this article has been adapted”. More profoundly, this work finds its root in earlier work on systematic program development and abstract data types. This article focuses on the central ideas, introducing them concisely for direct application by developers.
lunes, 5 de junio de 2017
Requisitos y patrones J2EE aplicables
1. Requisitos y Patrones de diseño en J2EE
Presentaremos una lista de requisitos que surgen a la hora de crear una aplicación J2EE. Junto al requisito, se indica el o los patrones que se suelen aplicar. Esto puede ser util a la hora de identificar cual puede ser (los) patrones a aplicar.
|
Requisitos |
Patrones |
|---|---|
|
Intercepting Filter |
|
|
Añadir la capacidad de logging, depuracion, u otro comportamiento que debe completar cada request |
Front Controller Intercepting Filter |
|
Centralizar el control para el manejo de la request |
Front Controller Intercepting Filter Application Controller |
|
Crear un interfaz generico de tipo Command o un objeto que contenga el contexto, de manera que se reduzca el acoplamiento entre los elementos que manejan el control c y los elementos que actuan como helpers |
Front Controller Application Controller Context Object |
|
Si hemos de implementar nuestro Controller como un servlet o bien como JSP |
Front Controller |
|
Crear una vista a partir de varias sub-vistas |
Composite View |
|
Si hemos de implementar nuestra View como un servlet bien como JSP |
View Helper |
|
Como descomponer nuestra View y Model |
View Helper |
|
Donde encapsular los datos provenientes de la presentacion y su logica |
View Helper |
|
Si debemos de implementar nuestros Helpers como JavaBeans o como Custom tags |
View Helper |
|
Combinar multiples patrones de presentación |
Intercepting Filter Dispatcher View |
|
Donde encapsular el manejo de la Vista y la lógica de Navegacion, lo que implica seleccionar una de las Vistas y servirla |
Pattern Service to Worker Dispatcher View |
|
Donde guardar el estado de la Session |
Session State on the Client Session State in the Presentation Tier Storing State on the Business Tier |
|
Control de acceso del cliente a ciertas vistas |
Design "Controlling Client Access" Hide Resources From a Client |
|
Controlar el flujo de requests hacia la aplicacion |
Design "Duplicate Form Submissions" Design "Introduce Synchronizer Token" |
|
Controlar la llegada de submits duplicados |
Design "Duplicate Form Submissions" Introduce Synchronizer Token |
|
Problemas de diseño al usar el mecanismo de populacion de valores estandar de JSP <jsp:setProperty> |
"Helper Properties—Integrity and Consistency" |
|
Reducción del acoplamiento entre la capa de presentación y la de negocio |
"Hide Presentation Tier-Specific Details From the Business Tier" "Introduce Business Delegate" |
|
Particionar el codigo de acceso a datos |
"Separate Data Access Code |
|
Requisitos |
Patrones |
|---|---|
|
Reducir el acoplamiento entre la capa de presentación y la capa de negocio |
Business Delegate |
|
Poner en cache los servicios de la capa de negocio a los clientes |
Business Delegate |
|
Ocultar los detalles de implementacion de lookup/creacion/acceso de los servicios de la capa de negocio |
Business Delegate Service Locator |
|
Encapsular las dependencias propietarias de lookup en los servicios |
Service Locator |
|
Proveer un metodo uniforme para lookup y creacion en los servicios de la capa de negocio |
Service Locator |
|
Ocultar la complejidad de las dependencias de los enterprise bean y el lookup de los componentes JMS |
Service Locator |
|
Transferir los datos entre los objetos de negocio y los clientes pasando por las distintas capas |
Transfer Object |
|
Proveer de un interfaz simple para los clientes remotos |
Business Delegate Session Façade Application Service |
|
Reducir las invocaciones a metodos remotos mediante el acceso a metodos que agrupen varias funcionalidades dentro de la capa de negocio |
Session Façade |
|
Manejar las relaciones entre los componentes enterprise bean y ocultar la complejidad de las interacciones |
Session Façade |
|
Proteger los componentes de la capa de negocio de ser expuestos directamente al cliente |
Session Façade Application Service |
|
Proveer una capa uniforme de acceso a los componentes de la capa de negocio |
Session Façade Application Service |
|
Implementar un modelo conceptual de dominio complejo mediante objetos |
Business Object |
|
Identificar objetos que manejan dependencias y sus objetos dependientes en el diseño de objetos de negocio y entity beans |
Business Object Composite Entity |
|
Diseñar entity beans que manejan varias otras dependencias |
Composite Entity |
|
Reducir o eliminar la dependencia entre entity beans y el esquema de base de datos |
Composite Entity |
|
Reducir o eliminar la dependencia entre entity beans locales y entity beans remote |
Composite Entity |
|
Reducir el numero de entity beans y mejorar su manejo |
Composite Entity |
|
Obtener el modelo de datos de la aplicacion a partir de componer varios componentes de la capa de negocio |
Transfer Object Assembler |
|
Construcción dinamica del modelo de datos de aplicacion |
Transfer Object Assembler |
|
Ocultar la complejidad de la construcción del modelo de datos a los clientes |
Transfer Object Assembler |
|
Proveer de un procesamiento de peticiones y resultados en la capa de negocio |
Value List Handler |
|
Reducir la sobrecarga del uso de metodos lookup de enterprise bean |
Value List Handler |
|
Proveer de peticion-resultados cacheados para el cliente, dentro del servidor, con posibilidad de hacer-deshacer |
Value List Handler |
|
Elegir entre el uso de sessions beans con estado o sin el |
Session Bean—Stateless Versus Stateful |
|
Evitar el acceso directo por parte del cliente a entity beans |
Wrap Entities With Session |
|
Encapsular los servicios de la capa de negocio y ocultar los detalles de implementación |
Introduce Business Delegate |
|
Añadir logica de negocio dentro de un entity bean |
Business Logic in Entity Beans Move Business Logic to Session |
|
Crear session beans como gruesos servicios de la capa de negocio |
Merge Session Beans Wrap Entities With Session |
|
Reducir o eliminar sobrecargas de red o servidor debido a la comunicacion entity-bean-to-entity-bean |
Reduce Inter-Entity Bean Communication |
|
Particionar el codigo de acceso a datos |
Separate Data Access Code |
|
Requisitos |
Patrones |
|---|---|
|
Reducir el acoplamiento entre la capa de negocio y la de recursos |
Data Access Object |
|
Centralizar el acceso a la capa de recursos |
Data Access Object |
|
Minimizar la complejidad de los componentes de la capa de recursos y los de la capa de negocio |
Data Access Object |
|
Proveer procesamiento asincrono en aplicaciones empresariales |
Service Activator |
|
Enviar una peticion asincrona hacia los servicios de la capa de negocio |
Service Activator |
|
Procesamiento asincrono de una peticion, subdividiendola en sub tareas concurrentes |
Service Activator |
|
Persistir de manera transparente un objeto del modelo |
Domain Store |
|
Implementar un framework de persistencia propio |
Domain Store |
|
Exponer un servicio web mediante XML y un protocolo standard de Internet |
Web Service Broker |
|
Ofrecer de forma centralizada y distribuir servicios existentes bajo la forma de web services |
Web Service Broker |
jueves, 13 de abril de 2017
POC of Suscription Board (Dojo,Dojo mobile, Spring MVC, JPA, Hibernate, Mysql)
You can find a Proof of concept of a "suscription board project", using: Dojo, Dojo mobile, Spring, JPA, Hibernate, Mysql and Amazon AWS technologies, at:
http://discussion.puertocerouno.net
Project now supports:
- File attachments for discussion and replies
Regards.
Suscribirse a:
Entradas
(
Atom
)