Archivos para agosto, 2006

Que Hermosura!!

Publicado: agosto 21, 2006 en Bellezas

MIS JAPON

497506.jpg

Talvéz no tiene nada que ver con informática, pero me atrevo a decir que es la japonesa más linda que he visto.
Además esta mujer debió ser la Miss Universo 2006. Aunque salió segunda en el Miss Universo 2006, ese nos queda como consuelo.

A continuación se presentan algunas consideraciones respecto a cómo el MOO es presentado mayoritariamente en la literatura. Muchos autores afirman incluso la conveniencia de usar orientación a objetos en el modelado conceptual. Estas afirmaciones serán analizadas críticamente en las siguientes secciones.

  1. Naturalidad.- La esencia del paradigma de la orientación a objetos y más específicamente, del MOO, es la visión de la realidad compuesta por objetos. Frecuentemente se afirma que esta visión es “más natural” que una visión funcional o comportamental. Por ejemplo, en el ámbito de la ingeniería de negocios, algunos autores, sugieren utilizar el modelo de objetos para diseñar negocios dada esta aparente naturalidad que facilitaría la comunicación
  2. Encapsulamiento .-

    En Informática existe una fuerte tendencia a forzar la realidad modelada a una conceptualización originada de la construcción de software. Por ejemplo, el MOO se sustenta en el encapsulamiento que propone separar los aspectos externos de los internos. Los aspectos externos son cono-cidos por otros objetos, en cambio los aspectos internos son de conocimiento exclusivo del objeto propietario. De esta forma, los objetos son autocontenidos y no comparten ningún tipo de dato que no sea solicitado en las colaboraciones con otros objetos. La cuestión es la siguiente: ¿tiene sentido encapsular en el nivel de abstracción requerido en elmodelado conceptual? Dado que la mayor ven-taja del encapsulamiento se revela en la fase de implementación, ¿qué beneficios se podrían esperar
    del encapsulamiento en el modelado conceptual? ¿encapsular en el modelado conceptual no representaría introducir prematuramente rasgos de implementación?.
  3. Continuidad Estructural.-

    La continuidad estructural, en las sucesivas fases del ciclo de vida orientado a objetos, es comúnmente indicada como una ventaja. El gap semántico1se vería dismi-nuido: por ejemplo, los objetos identificados en el dominio del problema serían mapeados directa-mente en los objetos especificados en el dominio de la solución durante el diseño. Lo mismo sucede-ría con estos objetos al ser mapeados en los objetos codificados de la implementación. Se puede afirmar entonces, que el MOO sería ventajoso si tanto el diseño como la implementación fueran también conducidos bajo este mismo paradigma. Sin embargo, el beneficio de la continuidad estructural no debería tener el costo de colocar el MOO más cerca del diseño orientado a objetos. El modelado conceptual, en la perspectiva de la ingeniería de requerimientos, debe ser orientado al problema (realidad) y no a la solución concreta (implementación orientada a objetos).

  4. Transición al Diseño.-

    La confusión existente entre lo que es el análisis y el diseño orientados a objetos, es decir, la poca claridad en los límites entre estas dos fases es indicada en la literatura. El principio de la ingeniería de software de que el análisis debe ser declarativo con relación al diseño, es decir, que describe qué debe hacer el sis-tema en contraste con el diseño que establece cómo ha de hacerse, no ocurre en la orientación a objetos. En la práctica, los modelos orientados a objetos del análisis son sólo menos detallados que los del diseño o sólo constituyen el “centro” del modelo de diseño; así la pretensa declaratividad no es alcanzada. De esta forma, el MOO puede entenderse como un diseño preliminar, porque una vez que los requerimientos son entendidos, éstos se organizan en un modelo que sirve como estructura interna del sistema a ser diseñado.La orientación a objetos debe ser considerada entonces como una decisión de diseño e implementación y no como una decisión de modelado conceptual o de análisis de requerimientos.Por lo anterior, los términos análisis y orientación a objetos en realidad se contraponen. La noción de análisis como descomposición y examen crítico con el fin de aumentar la comprensión no alcancalza con las ideas de síntesis (encapsulamiento de atributos y operaciones en los objetos) y de alter-nativa de diseño e implementación de la orientación a objetos.Una forma de resolver este problema es creando mecanismos que permitan postergar el en-capsulamiento tanto cuanto sea posible. En otras palabras, modelar el dominio del problema fuera del paradigma de la orientación a objetos, con suficiente poder de expresión y flexibilidad para poder derivar modelos orientados a objetos con relativa facilidad, si la implementación desea ser realizada bajo este paradigma. De esta forma, el modelado concluye antes de introducirse el encapsulamiento, punto en el cual comienza el diseño orientado a objetos3.En este sentido, el modelo de casos de uso (use case), propuesto por Jacobson, puede utilizarse previo a la construcción de modelos de objeto. Un modelo de casos de uso representa una manera específica de usar el sistema: a través de la ejecución de alguna parte de su funcionalidad. Cada caso de uso describe un escenario completo de eventos iniciados por un actor (o papel de usuario) y especifica la interacción que ocurre entre el actor y el sistema. Corresponde así a una visión externa del sistema, que no se construye bajo el paradigma de la orientación a objetos.

Conclusiones 

Bajo los argumentos aquí presentados, el MOO debe ser considerado como una alternativa más para hacer frente al análisis de sistemas, con una fuerte restricción impuesta a priori de implementar orientado a objetos. Con el fin de obviar esta restricción se sugiere modelar usando técnicas que posterguen el encapsulamiento, es decir, que permitan modelar fuera del paradigma de la orientación a objetos y que, eventualmente y si así se desea, sea posible realizar un mapeamiento a un modelo de objetos, momento en el cual se iniciaría el diseño orientado a objetos. Esta evolución del pensamiento sobre el MOO, se ve reflejada en la reciente propuesta de utilizar el modelo de casos de uso como conductor del proceso de desarrollo de software orientado a objetos, es decir, un modelo no orientado a objetos sirve como guía o marco para el resto de los modelos orientados a objetos.En el caso de optar por un análisis orientado a objetos, se debe estar consciente de que en realidad se está construyendo un modelo de diseño inicial o preliminar del sistema. Los términos para el análisis orientado a objetos se contraponen a los del diseño orientado a objetos, se reconocienda en ambos el carácter de diseño.

Definicion de Patrones

Los desarrolladores orientados a objetos con experiencia acumulan un repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos estilos que les guían en la creación de software. Estos principios y estilos, si se codifican con un formato estructurado que describa el problema y la solución, y se les da un nombre, podrían llamarse “Patrones”.
De manera mas simple un patrón es un par problema/solución con nombre que se puede aplicar en nuevos contextos, con consejos acerca de como aplicarlo en nuevas situaciones y discuciones sobre sus compromisos.
Un patrón es una descripción de un problema bien conocido que suele incluir:

  • Descripción
  • Escenario de Uso
  • Solución concreta
  • La consecuencias de utilizar este patrón
  • Ejemplos de implementación
  • Lista de patrones relacionados

Lo patrones de GRASP, no compiten con los patrones de diseño….. los patrones de GRASP, nos guían para ayudarnos a encontrar los patrones de diseño (que son más concretos)…..
Ahora Veremos un catálogo de patrones, los cuales son los primeros cinco patrones GRASP:

  1. Bajo Acoplamiento.-Debe haber pocas dependencias entre las clases. Si todas las clases dependen de todas ¿cuanto software podemos extraer de un modo independiente y reutilizarlo en otro proyecto?.Para determinar el nivel de acoplamiento de clases, son muy buenos los diagramas de colaboración de UML. Uno de los principales síntomas de un mal diseño y alto acoplamiento es una herencia muy profunda. Siempre hay que considerar las ventajas de la delegación respecto de la herencia.
  2. Experto.-La responsabilidad de realizar una labor es de la clase que tiene o puede tener los datos involucrados (atributos) . Una clase, contiene toda la información necesaria para realizar la labor que tiene encomendada. Hay que tener en cuenta que esto es aplicable mientras estemos considerando los mismos aspectos del sistema:
    • Lógica de negocio
    • Persistencia a la base de datos
    • Interfaz de usuario
  3. Alta Cohesión.-Cada elemento de nuestro diseño debe realizar una labor única dentro del sistema, no desempeñada por el resto de los elementos y auto-identificable.
    Ejemplos de una baja cohesión son clases que hacen demasiadas cosas. En todas las metodologías se considera la refactorización. Uno de los elemento a refactorizar son las clases saturadas de métodos.Ejemplos de buen diseño se producen cuando se crean los denominados “paquetes de servicio” o clases agrupadas por funcionalidades que son fácilmente reutilizables (bién por uso directo o por herencia).
  4. Creador.-Se asigna la responsabilidad de que una clase B cree un Objeto de la clase A solamente cuando
    1. B contiene a A
    2. B es una agregación (o composición) de A
    3. B almacena a A
    4. B tiene los datos de inicialización de A (datos que requiere su constructor)
    5. B usa a A.

La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad,encapsulación y reutilización.

5.- Controlador .-Asignar la responsabilidad de controlar el flujo de eventos del sistema, a clases específicas. Esto facilita la centralización de actividades (validaciones, seguridad, etc.) . El controlador no realiza estas actividades, las delega en otras clases con las que mantiene un modelo de alta cohesión.Un error muy común es asignarle demasiada responsabilidad y alto nivel de acoplamiento con el resto de los componentes del sistema.
En proceso unificado, al construir el modelo de análisis, existen estereotipos predefinidos que favorecen la separación de entidades, mecanismos de interfaz y mecanismos de control.En conclusión el libro, llamado UML y Patrones (Craig Larman) en el capitulo 16 (GRASP:Diseño de objetos con responsabilidades)nos puede ayudar en el diseño y la identificación de las clases en base a su responsabilidad. Este Capitulo de este libro es muy bueno pero puede ser un poco denso para usuarios principiantes ….. aunque si comenzamos a leerlo al final no tiene desperdicio.

En Conclusión este libro, llamado UML y Patrones (Craig Larman) en el capítulo 16(GRASP: Diseño de objetos con responsabilidades) nos puede ayudar en nuestro diseño y a la identificación de las clases en base a su responsabilidades, Es un capítulo muy bueno pero puede ser un poco denso y cansador para usuarios principiantes, aunque una vez comenzemos a leer no habra ningún desperdicio de tiempo.