lunes, 29 de abril de 2013

Análisis orientado a objetos (AOO).

Introducción


El objetivo del Análisis Orientado a Objetos (AOO) es desarrollar un modelo que describa el software de computadora necesario para satisfacer los requisitos definidos por el cliente. El modelo de análisis contiene el funcionamiento y el comportamiento de los elementos del modelo de objetos.

Nadie tiene muy claro por qué el Análisis Orientado a Objetos ha tardado tanto tiempo en ser aplicado a pesar de que maneja conceptos que aprendimos en la guardería como objeto, clase, miembro etc. No existe un acuerdo sobre los conceptos que sirven de base para el AOO, aunque se repiten a menudo un número de ideas clave.

El propósito es definir todas las clases, atributos, operaciones y relaciones de comportamiento asociado entre ellos que sean relevantes al problema que se va a resolver. Para realizar dicho análisis se deben ejecutar las siguientes tareas:

-Identificar los escenarios o casos de uso.


-Identificar las clases,


-Definir sus atributos y métodos.


-Especificar la jerarquía entre las clases.


-Representar las relaciones entre los diferentes objetos del sistema.


-Modelar el comportamiento de cada objeto.


-Repetir iterativamente las tareas anteriores hasta completar el modelo.

UML


Existían varios métodos para realizar AOO pero esos métodos se recombinaron en uno sólo llamado UML (Lenguaje de Modelo Unificado) este sistema aúna todos los procesos comunes y trata de tomar de cada método lo mejor. UML se caracteriza por cinco vistas independientes de un mismo problema, cada vista contiene un enfoque diferente del problema y lo muestra con gráficos de diferentes tipos.

Las cinco visiones diferentes de UML son:

Vista del usuario: representa el sistema desde la perspectiva de los usuarios (llamados actores en UML). Para este tipo de vista se utiliza el diagrama de casos de uso.


Vista estructural: modela la estructura estática (clases, objetos y sus relaciones).

Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en las vistas anteriores.

Vista de implementación: aquí se representan tal y como van a ser implementados los aspectos estructurales y de comportamiento.

Vista del entorno: muestra como irán los módulos implementados dentro del proyecto físico y las relaciones entre los diferentes módulos.

El AOO se centra en las vistas del usuario y estructural.

El DOO (modelo de diseño Orientado a Objetos) se centra más en las vistas del comportamiento y entorno.

Análisis del dominio


Es la primera actividad técnica a la hora de comenzar un nuevo proyecto. El objetivo de este análisis es definir las clases y objetos que están presentes en el dominio del problema propuesto. Esto dependerá del tipo de enfoque que se dé al problema o del área de negocio que se desea modelizar y se encuentra encuadrado dentro de un nivel medio de abstracción. Sirve para crear una biblioteca de clases que posteriormente podrán ser reutilizables (componentes).


Para ello cuando se diseñan las clases hay que tener en mente que no se realizarán con el único objetivo de integrarlas en una aplicación concreta, sino que deben diseñarse pensando en una posterior reutilización, esto es lo que llamamos análisis del dominio.

Por tanto se trata de identificar los requisitos comunes de una aplicación específica con vistas a su reutilización posterior dentro de un dominio de aplicación específico.

Un analista de dominio debe verse a sí mismo como un diseñador de herramientas para que los demás trabajen con ellas.



Definir el dominio


Consiste en aislar el área del negocio, se extraen las especificaciones y diseños de código que ya existan, clases, interfaz gráfica y clases de acceso a bases de datos, bibliotecas comerciales, también políticas, procedimientos, estándares, guías etc. En definitiva todo lo relevante para el proyecto. Se clasifican los elementos definiendo categorías de elementos y la nomenclatura de cada una de ellas.

Se deben identificar los objetos candidatos, ver si dichos objetos son reutilizables o adaptarlos para que lo sean y definir qué porcentaje de la aplicación podrá construirse con estos objetos reutilizables.

Se trata de desarrollar un modelo de análisis para los objetos que posteriormente servirá como base para la construcción de los objetos del dominio y su reutilización.

Componentes genéricos


Se trata de desarrollar un modelo del mundo real, dejando los detalles para más adelante. Se distingue entre componentes estáticos (que no cambian durante la vida de la aplicación) y componentes dinámicos (que se centran en el control y dependen del tiempo y de los sucesos).

Vista estática de clases, las que persisten a lo largo de toda la vida de la aplicación.

Vista estática de atributos, para definir las clases anteriores.

Vista estática de relaciones, para definir las conexiones e interacciones entre los objetos anteriores.

Vista estática de comportamientos, consiste fundamentalmente en un modelo de casos de uso que define una secuencia de operaciones genérica.

Vista dinámica de comunicación, define la comunicación dinámica entre objetos definiendo los mensajes que producen transiciones de un estado a otro.

Vista dinámica de control y tiempos, describe el tipo y duración de los sucesos que provocan la transición de estados entre ellos.

jueves, 25 de abril de 2013

Gestión de proyectos de software

El marco de proceso común para POO

Para el desarrollo de proyectos en POO el marco que mejor se ajusta es el recursivo /paralelo, adaptado a este tipo de programación podríamos definir el proceso de la siguiente manera:

-Aislar las clases del problema y las conexiones más importantes entre ellas.
-Intentar determinar si el diseño se puede llevar a la práctica, para ello es útil hacer un pequeño esquema de clases.

-Extraer los objetos reutilizables para montar una biblioteca de clases. O reutilizarlos si ya existen.

-Modificar el prototipo basándose en lo que se ha aprendido al realizar el diseño y de la realimentación obtenida del propio cliente.

-Ensamblar el prototipo usando los objetos de la biblioteca y los que se hayan creado nuevos.

-Realizar pruebas y de nuevo realimentación.

Este modelo indicado también se puede aplicar a componentes independientes del proyecto, también es útil tratar de descomponer a su vez cada componente en nuevos componentes  independientes y reiterar este proceso en cada resultado obtenido (recursividad).
Si en algún momento se detecta un componente o subcomponente existente en una biblioteca, se utiliza y se para el proceso de descomposición. Una vez identificados todos los componentes, es fácil trabajar sobre ellos en paralelo  (cada programador con uno) de modo que el progreso es fácil de realizar y fácil de medir.

Hitos

Se pueden de finir hitos en el desarrollo del proyecto cuando se han completado las siguientes tareas:

Fase de análisis

- Todas las clases y la jerarquía de clases se han definido y revisado.
- Lo mismo para los atributos y operaciones de las clases.
- Idem para las relaciones entre las clases.
- Se ha revisado el modelo de comportamiento.
- Se han establecido las clases reutilizables.

Fase de Diseño

- Se han definido todos los subsistemas.
- Cada clase se ha asignado a un subsistema.
- Se han identificado las responsabilidades y colaboraciones.

Fase Programación

- La implementación en código de cada clase.
- La integración de cada clase de una biblioteca.

Fase Pruebas

- Se ha revisado el modelo.
- Se han diseñado y ejecutado  casos de pruebas para cada clase.
- Se ha diseñado y ejecutado casos de pruebas para el sistema en su conjunto.

martes, 23 de abril de 2013

Solucionar problemas de referencia circular en SQL Server


Algunas veces los errores más enrevesados tienen la solución más sencilla, este es un caso que puede tenernos horas parados si no nos damos cuenta pensando que no hay forma de romper la referencia circular de una tabla sobre otra, mucho cuidado porque si en vez de en  dos tablas se da entre varias puede tenernos entretenidos mucho tiempo.
Hacemos este Update:

update exportacion_paises_relacion set CodigoExportacion = 'ot' where CodigoExportacion = 'zz'

y nos da este error:

Mens. 547, Nivel 16, Estado 0, Línea 1
The UPDATE statement conflicted with the FOREIGN KEY constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises", column 'Codigo'.

Buscamos la tabla de la foreign key y tratamos de solucionarlo

update exportacion_paises set Codigo = 'ot' where Codigo = 'zz'

Pero al ejecutar obtenemos otro error:

Mens. 547, Nivel 16, Estado 0, Línea 1
The UPDATE statement conflicted with the REFERENCE constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises_Relacion", column 'CodigoExportacion'.

Comprobamos con horror que ahora el problema está en la primera tabla, de tal forma que si hacemos primero un update nos da error una tabla y si hacemos primero el otro nos da error la otra.

update exportacion_paises_relacion set CodigoExportacion = 'ot' where CodigoExportacion = 'zz'
update exportacion_paises set Codigo = 'ot' where Codigo = 'zz'
Mens. 547, Nivel 16, Estado 0, Línea 1

The UPDATE statement conflicted with the FOREIGN KEY constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises", column 'Codigo'.
The statement has been terminated.

Mens. 547, Nivel 16, Estado 0, Línea 2
The UPDATE statement conflicted with the REFERENCE constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises_Relacion", column 'CodigoExportacion'.
The statement has been terminated.

Y si lo intentamos del revés nos da los mismos errores pero en orden inverso.

update exportacion_paises set Codigo = 'ot' where Codigo = 'zz'
update exportacion_paises_relacion set CodigoExportacion = 'ot' where CodigoExportacion = 'zz'

Mens. 547, Nivel 16, Estado 0, Línea 2
The UPDATE statement conflicted with the REFERENCE constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises_Relacion", column 'CodigoExportacion'.
The statement has been terminated.

Mens. 547, Nivel 16, Estado 0, Línea 1
The UPDATE statement conflicted with the FOREIGN KEY constraint "FK__Exportaci__Codig__7A16EC61". The conflict occurred in database "dbPrueba", table "Exportacion_Paises", column 'Codigo'.
The statement has been terminated.

La solución es muy sencilla, basta con darse cuenta de que el código que intentamos modificar NO EXISTE en la tabla de códigos, en este caso exportacion_paises por tanto siempre dará error. Basta con darlo de alta, hacer el update correspondiente en la otra tabla y eliminar el código antiguo si fuera necesario.

insert into exportacion_paises values ('OT','Desconocido')
update exportacion_paises_relacion set CodigoExportacion = 'ot' where CodigoExportacion = 'zz'
delete exportacion_paises where Codigo = 'zz' 

  

lunes, 22 de abril de 2013

Principios de la programación orientada a objetos (III)

Cómo identificar las Clases y Objetos


En el mundo real es sencillo identificar los objetos, sus atributos y sus funciones, pero a la hora de hacer un programa informático esta identificación no resulta tan evidente. Los objetos desde la realidad se manifiestan como:

Entidades Externas. Pueden ser cosas o personas externos al sistema pero que producen o consumen información del sistema.

Cosas. Objetos físicos del sistema, informes, facturas, maquinas, etc.

Ocurrencias o sucesos. Cuando se produce un cambio en el tiempo, sacar dinero de una cuenta, una máquina llega al final de carrera, etc.

Papeles o roles. Los desempeñados por personas que interactúan en el sistema

Unidades organizacionales. Si son relevantes en un sistema, división, equipo, etc.

Lugares. Establecidos en el contexto del sistema. Planta, Nº de aparcamiento, Plaza, Almacén, etc.

Estructuras. Una clase de objetos, maquinas, sensores, etc.

Así por ejemplo para un programa que juegue al ajedrez podemos identificar:

Clase/ Objeto Potencial

Jugador -> entidad externa o rol

Pieza ->cosa

Tablero -> cosa

Posición -> atributo de la pieza

Captura -> ocurrencia

Movimiento -> ocurrencia

Color -> atributo de la pieza

Para definir las clases y los objetos conviene analizar sintácticamente el enunciado o especificación del software a desarrollar detectando los posibles objetos (nombres) y los posibles métodos (verbos). Se han definido seis características para considerar si se incluye un objeto en un modelo de análisis:

Servicios Necesarios. Debe ser capaz de cambiar el valor de sus atributos a través de un conjunto de operaciones identificables.

Información retenida. La información acerca del objeto debe ser recordada para que el sistema funcione.

Atributos Múltiples. Un objeto debe tener atributos múltiples, si sólo tiene uno se puede considerar durante el análisis pero seguramente se pueda incluir dicho atributo dentro de otro objeto 

Operaciones Comunes. Las operaciones tienen que ser aplicables a todas las ocurrencias del objeto.

Atributos Comunes. Los atributos tienen que ser aplicables a todas las ocurrencias del objeto.

Requisitos esenciales. Las entidades externas que intervienen en el problema consumiendo o produciendo información esencial para el sistema también deben ser incluidas como objetos.

Para incluir un objeto en nuestro modelo, debe satisfacer la mayoría de los puntos mostrados anteriormente. Una vez elegido el objeto, sus atributos se buscan con la premisa de que definan completamente los objetos que los hacen únicos.

Si retomamos el ejemplo del ajedrez podemos ver si cumplen los requisitos.

Clase/ Objeto Potencial

Jugador -> entidad externa o rol Rechazado: no cumple muchas características.

Pieza ->cosa Aceptado: Cumple todas

Tablero -> cosa Rechazado: solo contiene la posición que pasa a atributo de la pieza

Posición -> atributo de la pieza.
Pasa a atributo de la pieza

Captura -> ocurrencia.
Pasa a método de la pieza

Movimiento -> ocurrencia.
Pasa a método de la pieza

Color -> atributo de la pieza.
Pasa a atributo de la pieza

Para encontrar las operaciones (métodos) hay que prestar atención a los verbos de la definición del sistema. Así en la definición del juego de ajedrez el verbo mover es importante y define un método. También existe el verbo capturar, por lo que habrá que tenerlo en cuenta a la hora de diseñar la clase.

Finalmente tendremos sólo una clase principal llamada Pieza que tendrá como propiedades el color de la pieza y su posición sobre el tablero, también será necesario añadir otra propiedad que no viene en la lista que nos diga el tipo de pieza de que se trata.

Tendrá un método mover y otro capturar que puede fusionarse como caso especial del método mover. También es conveniente heredar una clase para cada tipo de pieza. De este modo tendremos la clase padre Pieza con las clases hijas Peón, Torre, Caballo, Alfil, Rey y Reina, todas heredan todos los atributos como Color, Posición, etc. y cada una de ellas implementa un método diferente llamado Mover que incluye el caso especial Capturar. Dicho caso especial obliga a introducir otro atributo en la clase pieza que nos indique si la pieza está en juego o no. 

El sistema para un lenguaje concreto (Visual Basic.NET) se representaría así en UML:


Programación orientada a objetos



viernes, 19 de abril de 2013

Principios de la programación orientada a objetos


Clases y Objetos

Se define una clase como un concepto que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Además este encapsulamiento aísla la clase del resto del código de programa lo que permite ocultar la información que contiene y desacoplar la clase del resto del código del programa. Esto es muy beneficioso pues una vez una clase ha sido implementada y probada podemos desacoplarla del resto del programa haciendo este más sencillo, además de poder reutilizar dicha clase como un módulo en múltiples programas.
Una vez una clase está hecha y probada al programador le basta con saber cómo invocarla y lo que hace esta para poder utilizarla como un módulo separado del resto del programa. Este modo de trabajar permite montar programas como si trabajásemos con ladrillos o bloques de construcción, sin perder el tiempo de redefinir y probar cada ladrillo cada vez que lo necesitamos.
 No hay que olvidar que cada clase en realidad es un patrón o una plantilla que describe una colección de objetos similares y que el objeto concreto será lo que utilizaremos en el código fuente de nuestro programa.
Todos los objetos que genera la clase heredan sus propiedades o atributos y las operaciones o métodos disponibles para la manipulación de estos.
Las clases soportan la herencia por lo que una clase puede tener una o varias clases hijas que heredan las propiedades y métodos de la clase base.
 La mayoría de los objetos físicos tienen características tales como forma, peso, color y tipo de material. Las personas tienen características como fecha de nacimiento, padres, nombre y color de los ojos. Un atributo o propiedad puede verse como una relación binaria entre una clase y su dominio.
La «relación» binaria anteriormente señalada implica que un atributo puede tomar un valor definido por un dominio enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto de valores específicos.
Por ejemplo, la clase Coche tiene una propiedad colorEl dominio de valores de color puede ser (blanco, negro, plata, gris, azul, rojo, amarillo, verde). Pero el dominio también puede ser un conjunto de clases por ejemplo su en vez de Color fuera TipoMotor, en este caso el dominio sería Inyección, Diesel, Gasolina que representa un conjunto de clases que a su vez tiene sus propiedades.

Métodos

Si un método no devuelve un valor como por ejemplo Acelerar, lo llamamosProcedimiento, si por el contrario tiene un valor de retorno por ejemplo CalculaArea lo llamamos Función.
Dentro de una clase nos referimos a ellos como Métodos.
Los métodos son algoritmos que operan con los datos contenidos en las propiedades y representan el comportamiento del objeto.
El disparo de un método en un objeto concreto se llama mensaje y puede ir de algo tan sencillo como devolver el color de una pieza de ajedrez en el objeto Torre de la clase Pieza a algo tan complejo como calcular la declaración de la renta del objeto declaracionClientexx de la clase Renta2013. Este último caso puede implicar la generación de otros mensajes a otros objetos en cascada.
Los mensajes son el medio a través del cual interactúan los objetos. Los métodos son los procedimientos invocados cuando un objeto recibe un mensaje.

Encapsulamiento, herencia y polimorfismo

Como ya se ha dicho anteriormente, la clase encapsula las propiedades y los métodos, quedando estos ocultos al programa principal, lo que reduce la propagación de errores si hay cambios, pues estos son mucho más sencillos de realizar y más localizados. Además si no se toca la clase y está suficientemente probada, se sabe que la clase no contiene los fallos.
La encapsulación facilita la reutilización de código, (componentes). Además las interacciones entre módulos están simplificadas, el objeto llamante sólo debe conocer los parámetros a enviar sin preocuparse de la estructura interna del objeto llamado.
Una Clase hereda todos los atributos de su clase padre, esto quiere decir que todo el código de la clase padre está disponible para la clase hija, no siendo necesario repetirlo de nuevo.
De este modo cualquier cambio en una clase padre se propaga inmediatamente a todas las clases hijas, una clase existente puede sobrescribirse e implementar nuevas versiones de propiedades o métodos para la nueva clase.
El polimorfismo permite utilizar toda la operativa común de una clase y al mismo tiempo dividir las partes que difieren, de tal forma que se reutiliza solamente el código necesario. Así si queremos calcular el área de diferentes formas geométricas podemos definir una clase padre Figura que contenga los atributos y operaciones comunes para todas las figuras y luego crear clases derivadas para cada figura, por ejemplo Cuadrado, Triangulo, Circulo. En la clase base definimos el método calcular área y lo dejamos vacío y luego en cada clase hija definimos el método concreto de cada figura de tal forma que en el código cliente bastará con llamar a
Circulo1.CalcularArea, Cuadrado3.CalcularArea o Triangulo57.CalcularArea sin preocuparnos más, pues cada objeto ya sabe cómo calcular el área correspondiente.
Si hay que añadir una nueva figura apenas hay que tocar código, basta con crear una nueva clase hija y redefinir en ella el método CalcularArea. Sólo tendremos que crear y probar la nueva clase, y si hay fallos sabemos que estarán localizados en la nueva clase y no afectarán a lo anteriormente hecho

Principios de la programación orientada a objetos

Introducción

La programación orientada a objetos (POO) o por sus siglas en inglés (OOP) es un paradigma que enfoca la programación como si trabajásemos con objetos del mundo real, esto es muy atractivo desde el punto de vista de la clasificación y análisis de las partes que integrarán un programa pues es posible pensar en objetos del mundo real y sus interacciones entre ellos.

Así pues el concepto más importante de dicho paradigma es la Clase que establece la definición genérica de un Objeto o Instancia dentro de un programa, en el mundo real una clase es un Coche, un Animal, una Factura o cualquier cosa tangible o intangible del mundo real.

El objeto o instancia es la ocurrencia concreta de la clase. Así, mi coche es un objeto de la clase coche, un coche tiene 4 ruedas, un volante, un motor, faros, etc, etc. Mi coche particular es de un modelo concreto, es rojo o amarillo, tiene x kilómetros pero hay muchos coches concretos, cada uno con sus atributos, así una clase es un Molde que establece las Propiedades (color, marca, modelo) de cada coche concreto, objeto.
Además de propiedades un coche puede interaccionar con el mundo, por ejemplo puede acelerar, frenar, girar a la derecha a izquierda, este tipo de interacción se llama Método o Función y se define en cada clase junto con las propiedades.
                             
principios programación orientada a objetos

De este modo tenemos la clase coche con las propiedades color, marca, modelo, etc y los métodos acelerar, frenar, girar. Todo esto se encapsula y sirve de molde para implementar diferentes objetos u ocurrencias concretas, coche azul marca X que acelera de 0 a 100 en 7 segundos, etc, etc.
La OOP nos permite pensar en el mundo real y diseñar inmediatamente el código que maneje cualquier información.  Podemos pensar en una clase Factura que tiene unas propiedades: Importe, datos de cliente, datos de cabecera, etc y unos métodos: Imprimir, borrar, grabar, etc.
Toda esta operativa se programa en un mismo módulo (Encapsulación) y ya no es necesario tocar  pues permite crear un código de cliente que opere con los objetos  de cada clase sin necesidad de tocar el código de las clases.

Las clases soportan la Herencia, Un Animal puede ser un perro o un gato, del mimo modo que la clase animal puede derivarse en otras clases perro o gato que generen propiedades concretas de perro o gato pero posean los mismos métodos (como comer) aunque definidos de forma diferente.(Polimorfismo)
Los métodos pueden cambiar los atributos o propiedades de un objeto, así por ejemplo si tengo Un objeto cuadrado con un valor del lado y uso el método crecer puedo cambiar su valor del lado.
La encapsulación permite la reutilización del código, la clase Imprimir, si está bien diseñada se puede utilizar para imprimir cualquier cosa de tal modo que al programar ya nunca tendremos que programar de nuevo dicha operativa y bastará con escribir  NombreObjeto.Imprimir.
Resumiendo: Un programa orientado a objetos tiene una serie de Moldes (Clases) que contienen la información genérica de cada objeto, (Métodos y Propiedades) dentro de un mismo contenedor (Encapsulación), las clases permiten la herencia y por tanto definir los mismos métodos de diferente forma (Polimorfismo). Cada Ocurrencia concreta de una clase se llama objeto o Instancia y representa un objeto concreto del mundo real como un coche azul o una factura del cliente X por importe Y.