viernes, 30 de agosto de 2013

Trabajar con métodos

Este artículo es la continuación de la implementación de un Primer Programa Orientado a Objetos. Aquí veremos cómo crear métodos de la clase, cómo sobrecargarlos y cómo rellenar un ListBox utilizando el objeto ArrayList de .NET. También veremos como agregar un control a un formulario en tiempo de ejecución. Finalmente utilizaremos los métodos para arrastrar y soltar objetos dentro de un formulario.

Consideraciones en el diseño de clases reutilizables


La idea de la POO es hacer que nuestro código pueda ser reutilizable o incluso exportable a otros programas a través del conocido Copiar y Pegar, para hacer esto posible hay que tener en cuenta algunos conceptos importantes:


Abstracción


Cuando se crea una clase, existe la tentación de agregar una gran cantidad de funciones de apoyo, no obstante hay que tener en cuenta que cada método, propiedad o evento que se añada a la clase va a limitar las opciones de reutilización de la clase. También es necesario saber que una clase debe hacer una cosa bien. Si utilizamos una abstracción clara, será más fácil para los desarrolladores, pues sus métodos y propiedades tendrán sentido y su comportamiento será más predecible.


Contención


Una clase es una especie de caja negra donde se almacena un tipo de objeto con datos diversos y los métodos que trabajan con ellos, por ejemplo La clase CHospital puede almacenar Nombres, direcciones, Números de habitación, Historias clínicas o cualquier otra cosa. Por lo tanto, hay que tener cuidado de no hacer ninguna suposición sobre el contexto de la clase. A pesar de que se va a desarrollar una clase en un contexto de una aplicación de Windows, la clase no debe contener ninguna referencia a un formulario.

Es posible que se desee añadir un comportamiento que dependa del código de cliente. Se podría añadir un método que tome un argumento para especificar una forma de tratar la infoirmación. En este caso es mejor agregar un método que cree un objeto específico de .NET
De tal forma que sea utilizable a través de una serie de códigos de cliente más amplia.

Por ejemplo, si se desea agregar código que muestre un dibujo de un hospital para cada hospital agregado. Se puede añadir un método que cree un objeto de .NET Graphics. Esto nos va permitir escribir código para dibujar el hospital en cualquier objeto que contenga un objeto Graphics de .NET.

Código Cliente


Si la clase está bien diseñada, el código de cliente se simplificará mucho, las estructuras de decisión y los bucles estarán contenidos en los métodos de la clase, de este modo no aparecerán en el código de cliente que se limitará a llamadas a los métodos de las clases.


Interfaz


Hay que proporcionar una interfaz completa, pero sin exajerar. Implementar el interfaz lo suficientemente bien como para que un posterior desarrollador  pueda extenderla. Por ejemplo, la clase CHospital tiene un método para dar de alta a un Médico en un hospital y otro para Ubicar un paciente en una sala, pero posteriormente se puede seguir completando, añadiéndo metodos por ejemplo para asignar una especialidad a un médico o un paciente a un médico.


A continuación continuamos añadiendo funcionalidad a la Clase CHospital, en este caso agregaremos un constructor y más métodos.

métodos el la programación orientada a objetos


jueves, 1 de agosto de 2013

Curso básico de análisis orientado a objetos (AOO)

Con la última entrada se completa un curso básico de Análisis Orientado a Objetos.

Análisis orientado a objetos (AOO) V

El modelo Objeto-Comportamiento

Consiste en evaluar el funcionamiento dinámico del sistema obedeciendo a estímulos externos. El modelo se crea siguiendo los siguientes pasos:

-       Evaluación de todos los casos de uso
-       Crear una traza de sucesos para cada caso de uso
-       Identificación de sucesos y comprender como se relacionan con los objetos
-       Construir un diagrama de transición de estados

Evaluación de los casos de uso


Se considera que ocurre un suceso, cada vez que un actor (puede ser humano o no) intercambia información con el sistema. Es importante recordar que un suceso es booleano (o sucede o no sucede) no caben más posibilidades, es decir un suceso no es la información que se intercambia si no solamente la contabilización de dicho suceso.

Por ejemplo una persona se acerca a un cajero automático y realiza las siguientes operaciones:

1-     Introduce la tarjeta en la ranura y teclea su número de 4 cifras. La contraseña se compara con la almacenada en el sistema. Si dicha contraseña es incorrecta un mensaje por pantalla avisará y restaurará el sistema a las condiciones iniciales, si es correcta  muestra un menú y espera la siguiente acción.

2-     El usuario elije sacar dinero y el sistema comprueba si el saldo tecleado es igual a superior al máximo diario  o al saldo disponible en la cuenta. Si es así entrega el dinero y muestra de nuevo el menú, en caso contrario muestra un mensaje indicando la situación entrega la diferencia y muestra el menú con la opción sacar dinero deshabilitada.

3-     El usuario coge el dinero y la tarjeta, si no se detecta la retirada del dinero o de la tarjeta envía un mensaje en pantalla y otro sonoro indicando el olvido. Si la retirada es completa vuelve al estado inicial. Si no persiste la señal unos segundos y vuelve al estado inicial.

La partes subrayadas indican sucesos. Debe buscarse un actor para cada suceso y anotar la información que se intercambia en cada suceso junto con posibles restricciones o condiciones.
Por ejemplo, en el caso en el que el usuario teclea su contraseña de 4 cifras desde el punto de vista del Análisis OO el actor transmite un suceso al teclado, dicho suceso se puede llamar clave_introducida pero la clave concreta en sí, no es una parte esencial del modelo. En este caso, el hecho de introducir la clave no cambia el flujo de control del caso de uso pero la tarea comparar_contraseña si lo cambia pues a partir de aquí el flujo discurrirá por dos caminos diferentes si la contraseña es correcta o incorrecta.
Cuando se han identificado todos los sucesos, se asocian a los objetos que pueden generar sucesos, incluidos los actores

Construcción del diagrama de transición de estados


Para construir este diagrama hay que tener en cuenta dos caracterizaciones diferentes de estados, una que muestra el estado de cada objeto y otra que muestra el estado del sistema en su conjunto.
También hay que distinguir entre características pasivas (estado actual de todos los atributos de un objeto) y características activas que indica el estado actual del objeto en el momento de producirse el cambio de estado.
Un ejemplo de características pasivas de una cuenta corriente en un cajero sería el titular, el Nº de cuenta etc. Las características activas sería el saldo, si la cuenta está anulada o no, etc. Para pasar una transición de estado activo a otro debe ocurrir un suceso (p.ej. sacar dinero y el saldo de la cuenta cambia).  Cada componente de un modelo objeto-comportamiento es una representación de los estados activos de cada objeto y de los sucesos que producen dichos cambios en estos estados activos.
Diagrama de transición de estados
El esquema mostrado arriba se llama de transición de estados, en él cada flecha es una transición de un estado activo de un objeto a otro. Las etiquetas al lado de cada flecha son los sucesos que disparan la transición. Existe el concepto de guarda, que es una condición booleana que posibilita la ocurrencia de una transición.  La guarda de una transición depende de los valores tomados por uno o varios atributos de un objeto. La guarda depende de un estado pasivo del objeto.
Una acción ocurre como consecuencia de una transición, e implica una o más responsabilidades del objeto. Por ejemplo introduce contraseña en el esquema de arriba es una acción.

Hay otro tipo de esquema para representar los estados del sistema, se trata de modelo  de traza de sucesos. En este modelo se indica como un suceso causa una transición del sistema de un estado a otro. Lo sucesos son booleanos. El sistema del cajero automático representado con este tipo de esquema quedaría del siguiente modo:

modelo  de traza de sucesos

En este esquema, el  usuario introduce la contraseña  a través del teclado, el sistema la compara, si es incorrecta avisa de que la contraseña se debe introducir de nuevo, si es correcta muestra el menú de las  operaciones a realizar.