[Instituto Tecnológico

Superior de Lerdo]

Materia

Sistemas de Información II.

Ensayo: DESARROLLO DE SISTEMAS DE

INFORMACIÓN

Alumna

Yazmin Ibarra Ceniceros.

07230475

Docente

Ing. Ricardo de Jesús Bustamante González.

Desarrollo de sistemas de información

En el momento en que se decide que hay que desarrollar un sistema de

información, es muy importante el tomar en cuenta algo que nos servirá de mucho

a la empresa para que el sistema sea realizado e implementado de manera

exitosa.

Estas actividades son las que se deben de tomar en cuenta, ya que son parte del

Ciclo de Vida del desarrollo de los Sistemas de Información:

Investigación preliminar.

Requerimientos.

Diseño.

Prueba del sistema.

Implementación.

Muerte del sistema (Fin de la realización del sistema).

Investigación Preliminar

Aquí es donde inicia el desarrollo del proyecto, este inicia cuando una empresa o

persona solicita al desarrollador el proyecto, y el desarrollador tiene que investigar

que es lo que la empresa necesita para el proyecto y poder satisfacer a la

empresa. Para poder cumplir el objetivo, el desarrollador debe verificar tres

aspectos importantes:

Factibilidad económica: aquí se determina si se tiene el presupuesto

necesario para poder desarrollar el proyecto.

Factibilidad técnica: aquí se determina si cuentan con la tecnología

necesaria para poder desarrollar el proyecto.

Factibilidad administrativa: por medio de esta se determina si hay el tiempo

suficiente y el personal para pode cumplir con el proyecto solicitado.

Terminado este paso, la empresa analizara si se aprueba el proyecto o no.

Análisis y determinación de los requerimientos

En esta parte es también muy importante ya que los desarrolladores deben de

saber muy bien qué es lo que se realizara que es lo que hará el sistema, en esta

fase debe tener la noción de cómo debe funcionar el sistema, con qué tiempos se

trabajara, debe de estudiar muy bien que es todo lo que realiza la empresa para la

cual desarrollara el sistema, además de tener en cuenta como es la manera en

que manejan todos los archivos y la información dentro de la empresa.

Diseño

En esta etapa, ya se tendrán todos los requerimientos bien aclarados, el siguiente

paso es el diseño del sistema, donde se establece todo con lo que contara el

sistema y se volverá a tomar en cuenta cómo es que la empresa maneja los datos,

como la entrada, la salida y el procesamiento de los mismos.

Pruebas del sistema

En esta etapa hay que realizar pruebas y ver si en verdad el sistema funciona

como debería y observar si realiza las operaciones deseadas.

Implementación del sistema

El sistema realizado, es instalado en la empresa, a la vez tiene que ser observado

el sistema, para saber que tan agradable es al usuario, como se comporta en los

equipos de la empresa y ver que opiniones tiene el dueño de la empresa acerca

del mismo.

Muerte del sistema

Esta es la última fase, esta ocurre cuando el proyecto está terminado, y se termina

el contrato con la empresa o el programa es remplazado por otro o por una versión

nueva del mismo.

El proyecto de ejemplo consiste en el diseño de un sistema para cajero automático

simple, originalmente se le realizaron cuatro ampliaciones, en este ejemplo solo se

muestran dos.

2. Diseño de un cajero automático simple

2.1 Introducción

Se trata de construir el software para un cajero automático muy simple. Un problema

familiar, por razones didácticas. Pero donde vamos a suponer que las necesidades del cliente

aparecerán poco a poco y que no las conocemos de antemano. El objetivo es apreciar el método

de desarrollo y diseño para abordar la incertidumbre. Si el problema fuese realmente desconocido

se desviaría la atención hacia la comprensión, que no es nuestro asunto. Debemos concentrarnos

en el método de trabajo.

Desarrollaremos el software por aproximaciones sucesivas, comenzando por lo más

importante. Las decisiones complementarias se van dejando para después, cuando se demuestre

que hemos alcanzado lo esencial. Así reducimos nuestro riesgo de hacer algo más allá y tenerlo

que desechar. Este será nuestro modo cíclico de actuar frente a la incertidumbre: reducir

progresivamente el riesgo. Hacer apuestas pequeñas, contrario a la Cascada, que lo apuesta todo a

un disparo, supuestamente certero. Para que el desarrollo sea evolutivo, el diseño tiene que serlo

también.

2.2 Extracción sobre una cuenta

Empezaremos por la extracción de dinero que es la operación de mayor interés.

Siguiendo la línea de desarrollo evolutivo, es decir, crecimiento y mejora progresiva del

software, partiremos de una situación simple.

Tarea inicial: hacer una sola extracción sobre una cuenta.

Como el diseño es un acto creativo se nos pueden ocurrir muchas soluciones

válidas; unas serán mejores que otras, de acuerdo a las condiciones específicas del

problema y su entorno. Ahora, como no tenemos experiencia, comenzaremos con la

primera que se nos ocurre cuando respondemos a la pregunta ¿Qué mecanismo software se

necesita para realizar esta operación?

El mecanismo debe averiguar la cantidad de dinero que desea extraer, solicitar la

autorización de ese retiro sobre la cuenta y averiguar si el dispositivo físico puede entregar

el dinero solicitado. En el caso que no se pueda entregar el dinero, el mecanismo software

debe explicar la causa. La Figura 1 muestra una implementación en objetos del mecanismo

descrito. Los mensajes forman parte del código del método “trabaja” del objeto

oExtracción.

oExtracción oCuenta oMonedero

trabaja

dameImporte

autoriza(importe)

entrega(importe)

resta(importe)

oInterfaz

Extracción

Figura 1. Diagrama de Secuencia de una extracción sobre una cuenta

En esta implementación hemos diseñado el objeto oExtracción para que su método

“trabaja” se ocupe de ejecutar el mecanismo de extracción. Lo primero que hace este

método es, crear al objeto oInterfazExtracción y pedirle el importe de la extracción. El objeto

oInterfazExtracción, de alguna forma no definida aún, suministra esa información. Su papel

es ocultar al objeto oExtracción la forma de obtener el valor del importe. Así no se

compromete el algoritmo de extracción con obtener el valor del importe, que es algo

accesorio a la extracción. En el primer prototipo, se puede inventar ese valor y asignarlo

directamente en el código de oInterfazExtracción.

Cuando el objeto oExtracción recibe el valor del importe, le pide la autorización de

entrega del importe al objeto oCuenta. Suponiendo que lo autoriza, oExtracción le dice al

objeto oMonedero que entregue el importe y a oCuenta que reste el importe del saldo.

Siguiendo nuestro estilo de primero lo esencial, nos ocuparemos después de lo que

sucede si, por alguna causa, no se puede entregar el importe.

Los objetos que se han diseñado para que participen en la escena EXTRACCIÓN son:

oExtracción : responsable de la tarea de extracción de dinero

oInterfazExtracción: delegado por el objeto oExtracción para obtener el valor del

importe. Aunque el objeto oExtracción puede conseguir este valor directamente con

el usuario, se debe dejar esa tarea a otro objeto porque conseguir el importe no

forma parte de la esencia de su trabajo. La separación de tareas reduce el impacto

del cambio. En definitiva, el papel de oInterfazExtracción es independizar la forma de

solicitar el valor del importe, del uso del importe, que es lo que es importante para

oExtracción. El objeto oInterfazExtracción oculta a oExtracción cómo averigua la

cantidad y así cuando sea necesario modificar ese “cómo” no hay que leer ni

modificar oExtracción.

oCuenta: encargado de operar con la cuenta donde se extrae el importe. Una vez

más, su papel es ocultar la forma de trabajar con la cuenta. Conoce el mecanismo

particular para autorizar una extracción, incluso cómo hacerlo para cada cliente. Por

tanto, es el objeto que debe autorizar la entrega de dinero. La variante de diseñar el

objeto oCuenta sólo para ocultar la información de la cuenta, por ejemplo el saldo,

requeriría demasiada especialización en oExtracción, que debe ser una operación

general.

oMonedero: es el intermediario o interfaz del sistema software con el dispositivo

externo que controla el dinero del cajero. Su razón de ser es independizar el resto

del sistema software de ese dispositivo, ocultando la forma de operar con él. La

presencia de oMonedero permite que el sistema se defienda del impacto de un

cambio en el dispositivo ya que es el único que se debe modificar, si hay un cambio

de efecto moderado.

Resumiendo, oExtracción es la pieza de software que hemos diseñado para que se

ocupe de la extracción de dinero. Este objeto delega en oInterfazExtracción la obtención del

importe, mientras que oCuenta y oMonedero se ocupan de operar con el dinero en la cuenta y

en el monedero del cajero respectivamente. El diseño consiste en concebir piezas software

para que realicen tareas y enlazarlas entre sí. Observe la importancia que le hemos dado a la

delegación de tareas con el objetivo de ocultar detalles del funcionamiento al método que se

ocupa de realizar la extracción para poder cambiar los detalles sin afectar a este método.

Todos los objetos se comunican en forma individual, uno con otro y de manera secuencial.

Diagrama de Clases de una extracción sobre una cuenta

En el diagrama de clases del mecanismo de extracción sobre una cuenta se ilustran

las clases de cada uno de los objetos que participan en la construcción del mecanismo y las

relaciones que existen entre ellas. Figura 2. Desde el punto de vista sintáctico, debe existir

una línea entre clases si existe al menos un mensaje entre los objetos de esas clases.

Extracción

Interfaz

Extracción

Monedero

Cuenta

Figura 2 Diagrama de Clases de una extracción sobre una cuenta

La clase Extracción usa a la clase InterfazExtracción: el mensaje dameImporte que envía el

objeto oExtracción al objeto oInterfazExtracción establece una relación de uso del primer

al segundo objeto. En el diagrama de Clases se refleja esta relación, como una línea que

une ambas clases. Algunos autores emplean puntas de flecha para indicar el sentido de

uso.

La clase Extracción usa a la clase Cuenta: esta relación representa los mensajes que el

objeto oExtracción envía al objeto oCuenta: autoriza(importe) y resta(importe).

La clase Extracción usa la clase Monedero: oExtracción envía un mensaje al objeto

oMonedero: entrega(importe).

El diagrama de clases de la Figura 3, también representa la estructura de clases del

mecanismo de extracción sobre una cuenta pero con una notación resumida que une la clase

y su interfaz correspondiente. Esta notación, aunque la mayoría de las herramientas CASE

no la permiten, es la que vamos a usar en este documento porque facilita la comprensión de

los diagramas, al dejar clara la esencia del mecanismo software.

Extracción

Monedero

Cuenta

Interfaz

Figura 3 Diagrama de Clases reorganizado de una extracción sobre una cuenta

Hecho el diseño lo codificamos, lo probamos y le mostramos al cliente este primer

prototipo para evaluarlo y, si es necesario, corregir el rumbo del proyecto. Sólo arriesgamos

el trabajo que hemos hecho sobre la esencia del problema. En caso de fallo, no se pierde el

trabajo hecho sobre los detalles o las excepciones. Es una manera de ser prudente ante la

incertidumbre.

2.3 Primera Ampliación. Hacer varias extracciones sobre una cuenta

En el prototipo anterior nos concentramos en conseguir el mecanismo para una sola

extracción. Ahora debemos ampliarlo a varias extracciones guardando la información de

cada extracción. Por tanto, crearemos un objeto oExtracción por cada extracción y

almacenaremos dentro de él, la información relevante, por ejemplo, el importe y la fecha.

Extracción

Importe

Fecha

Cuenta

Trabaja

Esta información aparecerá como atributos del objeto oExtracción. Figura 6.

Figura 6. Representación de la clase Extracción

Se añade una nueva responsabilidad al objeto oExtracción: custodiar los datos de

una extracción.

Este diseño muestra una diferencia notable con un diseño equivalente en software

estructurado. Mientras que en el software estructurado tendríamos una sola función para

hacer todas las extracciones y guardar la información en un almacén, separado de la

función, en el software orientado a objetos hay un objeto por cada extracción que realiza la

tarea y guarda, en su interior, la información.

La causa de esa importante diferencia radica en sus interpretaciones respectivas del

software. El modelo estructurado interpreta el software como funciones que actúan sobre

datos, mientras que el modelo orientado a objetos interpreta el software como módulos

integrales de datos y funciones, que interactúan entre ellos para realizar tareas. Por tanto, si

queremos conservar información debemos hacerlo en objetos, lo que en el fondo no es tan

diferente, porque los objetos son las variables del modelo orientado a objetos. La novedad

es que esas variables son activas, realizan tareas. En nuestro diseño cada objeto :Extracción

se ocupa de hacer una extracción y de almacenar la información relevante. Hemos sustituido

el objeto concreto oExtracción por el objeto anónimo :Extracción, porque ya no tenemos uno solo,

sino muchos.Después tendremos que encargarnos de no perder esos objetos cuando se

apague la máquina.

Los diversos objetos :Extracción se irán creando según se hagan las extracciones y

formarán una colección que necesitaremos manejar. Agregamos, entonces, un objeto para

gestionar la colección formada por los objetos :Extracción. Se llamará oGestorExtracciones.

En general, el manejo de colecciones de objetos se hace a través de objetos

especializados que se denominan Gestores. Sus funciones básicas son tres: entregar, añadir

y quitar un objeto de su colección cuando se le solicita. Los gestores de colecciones no

deben modificar los contenidos de los miembros de su colección. Si nos restringimos a

estas funciones básicas todos los gestores serán muy similares entre sí, independiente de la

colección que manejen. Es una decisión de diseño para no elevar, gratuitamente, la

complejidad del software teniendo gestores distintos.

Vistos en el sentido de ocultamiento, el papel fundamental de los gestores es ocultar

los detalles de acceso a la colección. Los que diseñan la parte esencial del sistema software

no tienen que preocuparse por la colección, ni de dónde está, ni cómo está organizada. Esto

es una tarea de los que diseñan los gestores de colecciones. Si se trabaja con bases de datos

externas, los gestores actúan como interfaces con esas bases de datos.

Con los gestores hemos resuelto el manejo de las colecciones de objetos, pero nos

queda el asunto pendiente de los objetos :Extracción, aún después de apagada la máquina.

Los debemos hacer persistentes. Es decir, objetos que tienen la propiedad de estar

presentes, siempre que se les necesite. Pero, una vez más, diremos que no nos interesan, por

ahora, los detalles de cómo se consigue la persistencia. Alguien se ocupará de conseguirlo,

en su momento.

Diagrama de secuencia de muchas extracciones sobre una cuenta

Cuando cada objeto :Extracción termine de ejecutar la extracción, debe solicitar al

objeto oGestorExtracciones que lo añada a su colección. Si la extracción no ha tenido éxito,

por alguna razón, no se incluye el objeto creado y la colección se mantiene como antes.

Este diagrama de secuencia sólo considera que la extracción ha tenido éxito. Figura 7.

:Extracción oCuenta oMonedero

trabaja

dameImporte

autoriza(importe)

entrega(importe)

resta(importe)

oInterfaz

Extracción

agrega(me)

oGestor

extracciones

Figura 7. : Diagrama de secuencia de varias extracciones sobre una cuenta

La nueva solicitud de nuestro cliente ha obligado a aumentar la capacidad del

sistema, respecto a la cantidad de información que maneja. Ha sido un cambio cuantitativo

en los requisitos, que resolvimos con un cambio cuantitativo en la solución, añadiendo un

objeto y un mensaje, sin necesidad de alterar el código anterior. El objeto

oGestorExtracciones y el mensaje agrega(me) están indicados en negrilla en la Figura 7.1. La

redacción del mensaje agrega(me) aprovecha un rejuego con el español para expresar mejor

qué solicita. El parámetro (me) contiene la referencia del objeto :Extracción. Observe que

el método de trabajo ha sido diseñar el mecanismo para un único objeto y después tener en

cuenta la colección.

Sin embargo, la sencillez de la modificación para asimilar cambios cuantitativos no

debe inducirnos a pensar que siempre puede ser así. La modificación ha sido simple porque

hemos supuesto un cambio cuantitativo modesto. Si el cambio cuantitativo es muy

pronunciado, puede requerir un cambio cuantitativo en el sistema, de manera análoga al

cambio de velocidad de 10 km/h a 100 km/h.

En las siguientes páginas se muestran el nuevo diagrama de clases del software y el

nuevo código, ambos, ajustados a realizar muchas extracciones sobre una cuenta.

La Figura 8.1 destaca la clase GestorExtracción que se ha añadido y la Figura 8.2,

reorganiza el diagrama para no perder la esencia de la estructura del software entre tantos

elementos accesorios. Por ejemplo la interfaz y el gestor. Pero se debe recordar que esta

forma peculiar de representar el diagrama de clases es una convención sólo nuestra,

inspirada en Coad.

La figura 9 muestra el código Java del programa. Los elementos añadidos se realzan

en negrilla.

Figura 8.1: Diagrama de clases de varias extracciones sobre una cuenta

Extracción

Monedero

Interfaz

Cuenta

Gestor

Extracción

Gestor

Extracción

Monedero

Interfaz

Cuenta

Figura 8.2: Diagrama de clases reorganizado de varias extracciones sobre una cuenta

//Clase Extraccion Versión 02

//Varias extracciones sobre una cuenta

//Con registro histórico de las extracciones

import java.io.*;

import java.util.*;

public class Extraccion implements Serializable{

private Cuenta oCuenta;

private Date fecha;

private float importe;

public Extraccion(){

fecha=new Date();

}

public float dameImporte() {

return (importe);

}

public Date dameFecha() {

return (fecha);

}

public Cuenta dameCuenta() {

return (oCuenta);

}

<- 1

<- 2

public void trabaja(){

InterfazExtraccion oInterfazExtraccion;

Monedero oMonedero;

GestorExtracciones oGestorExtracciones;

oInterfazExtraccion= new InterfazExtraccion();

importe=oInterfazExtraccion.dameImporte();

oCuenta=new Cuenta(“12345”,1000000);

oMonedero=Monedero.dameSolitario();

oCuenta.autoriza(importe));

oMonedero.entrega(importe);

oCuenta.resta(importe);

oGestorExtracciones=GestorExtracciones.dameSolitario()

;

oGestorExtracciones.agrega(this);

}

}

}

<- 3

1-> public class Extraccion implements Serializable{

Al decir que la clase Extraccion implementa la interfaz

Serializable, se está se consigue la capacidad para transformar el

estado completo de un objeto en una secuencia de bytes, y poder

crearlo nuevamente leyendo la secuencia de bytes correspondientes.

Esta cualidad nos permite, entre otras cosas, que un objeto pueda

ser guardado y leído de un archivo de objetos.

Es importante observar que esta interfaz no define métodos,

simplemente indica que la serialización es permitida.

2-> fecha=new Date();

Al crear una instancia de la clase Extracción se asigna la fecha

actual del sistema a su atributo fecha.

3-> oGestorExtracciones=GestorExtracciones.dameSolitario();

La clase GestorExtracciones también tiene una única instancia.

Nuevamente se utiliza el patrón “Solitario” y en esta línea se

solicita la instancia única de la clase GestorExtracciones.

Figura 9: Código Java de varias extracciones sobre una cuenta

2.4 Segunda Ampliación. Varias extracciones sobre una cuenta de varias

posibles

Han aumentado los clientes, necesitamos poder realizar varias extracciones sobre una

cuenta de varias posibles.

Antes los objetos :Extracción conocían la dirección del objeto oCuenta sobre el que

delegaban la autorización porque había un solo objeto oCuenta. Sin embargo, ahora hay

muchos, de manera que cada objeto :Extracción debe conocer la cuenta en particular sobre la

que debe actuar. El cliente dice que el identificador de la cuenta se obtiene de una tarjeta.

Se diseña un objeto oTarjeta para suministrar el identificador de la cuenta, ocultando la

manera de obtenerlo. Con este identificador se debe localizar el objeto :Cuenta específico que

trabaja con la cuenta referida. Hemos sustituido el objeto oCuenta conocido por el objeto anónimo

:Cuenta. Figura 10.

Figura 10: Diagrama de secuencia de una extracción sobre una cuenta, de

varias posibles.

:Extracción :Cuenta oMonedero

trabaja

dameImporte

autoriza(importe)

entrega(importe)

resta(importe)

oInterfaz

Extracción

agrega(me)

oGestor

Extracciones

oTarjeta oGestor

Cuentas

dameIdCuenta

Dame(idCuenta)

Puesto que hay una colección de objetos :Cuenta, debe existir un objeto gestor de

esta colección que proporcione el objeto cuenta a partir del identificador de la cuenta.

Ahora tenemos a un gestor de colecciones, en otra de sus funciones básicas: dar un

elemento de su colección. Es decir, un objeto. Para hacer esta nueva ampliación hemos

supuesto que la colección está formada de antemano, justo lo contrario de la situación

anterior, donde formamos la colección al añadir cada objeto :Extracción.

Resumiendo. De nuevo, el incremento de la complejidad del problema ha obligado a

elevar la complejidad de la solución. Hemos logrado resolver el cambio cuantitativo en los

requisitos mediante cambios cuantitativos en la solución, añadiendo elementos software al

diseño. En concreto, dos nuevos objetos:

oTarjeta: suministra el identificador de la cuenta de interés.

oGestorCuentas: suministra al objeto :Cuenta encargado de operar con la cuenta,

cuyo identificador ha dado el objeto oTarjeta. En el prototipo anterior, el objeto

:Extracción accedía al objeto oCuenta mediante el recurso del Solitario, porque

existía un solo objeto oCuenta. Ahora, hay varios objetos :Cuenta. Por tanto,

debe conocer a cuál se debe dirigir y después solicitarlo al objeto

oGestorCuentas.

En esta etapa es suficiente considerar que tenemos un solo objeto :Cuenta en la

colección de cuentas porque estamos diseñando el mecanismo de extracción. El

funcionamiento del objeto oGestorCuentas debe ser simple para no distraer nuestra

atención. Después, podremos ocuparnos de enriquecerlo, sin modificar el mecanismo de

extracción que hemos diseñado.

De manera semejante a la extensión anterior, el aumento de la capacidad

cuantitativa del sistema se ha conseguido añadiendo objetos y mensajes, sin necesidad de

alterar lo que ya estaba escrito. Los objetos añadidos son: oTarjeta y oGestorCuentas

mientras que los mensajes añadidos son: dameIdCuenta y dame(idCuenta) indicados en negrilla

en la Figura 10.

La técnica de diseño se repite: trabajar con un objeto como si fuese único y después

agregar los medios de acceso a ese objeto, en este caso los objetos oTarjeta y

oGestorCuentas. La esencia del mecanismo no se altera, cuando en vez ser un único objeto,

son muchos. Esto permite obtener un prototipo simple, que se concentre en la esencia, y

después ampliarlo de forma natural. Insistimos, siempre que no se rebasen los límites que

provoquen cambios cualitativos.

Tarjeta

Gestor

Extracción

Monedero

Interfaz

Cuenta

Gestor

Figura 11: Diagrama de clases del software de la segunda ampliación

El camino de considerar primero una situación simple y después hacerla más

compleja nos ha permitido avanzar poco a poco, haciendo apuestas pequeñas de cada vez,

sin desviar la atención de los objetivos prioritarios. Pero, además, ese camino también nos

ha conducido a un diseño de software que nos ha defendido de los cambios que se han

producido y, lo más importante, que nos defenderá contra muchos de los cambios que se

pueden producir en el futuro.

La condición de conocer, desde el principio, la presencia de varias

extracciones y varias cuentas debe conducirnos a un diseño de la misma naturaleza

defensiva que el conseguido, suponiendo incertidumbre, porque es una manera de

protegernos de la incertidumbre del mañana.

//Clase Extraccion Versión 03

//Extracción sobre varias cuentas

//Con registro histórico de las extracciones

import java.io.*;

import java.util.*;

public class Extraccion implements Serializable{

private Cuenta oCuenta;

private Date fecha;

private float importe;

public Extraccion(){

fecha=new Date();

}

public float dameImporte() {

return (importe);

}

public Date dameFecha() {

return (fecha);

}

public Cuenta dameCuenta() {

return (oCuenta);

}

public void trabaja(){

InterfazExtraccion oInterfazExtraccion;

Monedero oMonedero;

GestorExtracciones oGestorExtracciones;

GestorCuentas oGestorCuentas;

Tarjeta oTarjeta;

String idCuenta;

oInterfazExtraccion= new InterfazExtraccion();

importe=oInterfazExtraccion.dameImporte();

oTarjeta=Tarjeta.dameSolitario();

idCuenta=oTarjeta.dameIdCuenta();

oGestorCuentas=GestorCuentas.dameSolitario();

oCuenta=oGestorCuentas.dame(idCuenta);

oMonedero=Monedero.dameSolitario();

oCuenta.autoriza(importe);

oMonedero.entrega(importe);

oCuenta.resta(importe);

oGestorExtracciones=GestorExtracciones.dameSolitario();

oGestorExtracciones.agrega(this);

}

}

<- 1

<- 2

1-> oTarjeta=Tarjeta.dameSolitario();

La clase Tarjeta, por tener una única instancia, se implementa con

el patrón “Solitario”.

2-> oGestorCuentas=GestorCuentas.dameSolitario();

La clase GestorCuentas se implementan también con el patrón

“Solitario”.

Figura 12. Código Java de varias extracciones sobre varias cuentas

Diagrama de clases del sistema completo

La Figura 35 muestra el diagrama de clases del software del cajero.

Control

Acceso

Interfaz

Lector

Tarjeta

Tarjeta

Cuenta

Gestor

Selector

Monedero

Interfaz Interfaz

{Otra

Operación}

Gestor Gestor

Operación

trabaja

Extracción

trabaja

Ingreso

trabaja

Interfaz

Figura 4 Diagrama de Clases CAJERO

Observe que no existe ningún objeto cajero. El software del cajero funciona sin una

definición explícita. Este es uno de los recursos de la orientación a objetos que hemos

empleado en el diseño para facilitar su evolución. Empezamos con la extracción, después

añadimos el acceso y por último, agregamos el ingreso sin tener que modificar ninguna

definición, porque no existía. El sistema cumple su función sin necesidad de una definición

explícita de un cajero dentro del código

Un objeto cajero, para definir el sistema, conteniendo los objetos del diseño no

desempeña un papel relevante en el software. De tenerlo, habría que modificarlo cada vez

que se cambiara algo.

Otra observación interesante es que podemos tener una visión integral de la

estructura del sistema con el diagrama de clases. Pero con los diagramas de secuencia, sólo

tenemos trozos del comportamiento del sistema, como escenas sueltas de una obra de

teatro.

2. 6 Recapitulemos

El método de trabajo ha sido considerar una situación simple y después

enriquecerla. Por ejemplo, una extracción y después, varias extracciones.

Cuando aumentamos la capacidad cuantitativa de nuestro sistema software, para

operar con más de una extracción y con más de una cuenta, sólo tuvimos que añadir piezas

de software, objetos y código, que encajaron sin dificultad en el mecanismo existente. Las

exigencias cuantitativas del entorno se pudieron resolver con cambios cuantitativos en el

sistema, gracias a la aplicación del principio de ocultamiento de información.

Los diseños deben mostrar esta cualidad, siempre que los cambios cuantitativos no

impliquen cambios cualitativos. Como hemos dicho, manejar diez datos es cualitativamente

distinto de manejar un millón. Un salto cuantitativo de ese orden debe provocar cambios

sustanciales en el mecanismo, que no se resuelven solamente añadiendo más piezas de

software. Pero, mientras que no ocurran tales cambios nuestro software debe evolucionar de

manera simple.

Cuando el entorno exigió agregar la función del control de acceso se produjo un

cambio cualitativo. Hubo que hacer modificaciones en el software precedente para

acoplarlo a la función de acceso. En general, los cambios cualitativos en el problema

provocan cambios cualitativos en la solución software. Se deben aprovechar tales cambios

para mejorar las cualidades del sistema.

Algo parecido sucedió con la función ingreso, hubo que modificar el software

existente. Cambió la geometría del sistema al crearse un punto de bifurcación.

Estabilizamos ese punto de futuros cambios colocando un mecanismo de estabilización

para enfrentar esa incertidumbre. Aquí empleamos el polimorfismo.

En ningún caso, hubo una anticipación a los acontecimientos, sólo se aplicó una

disciplina de diseño: modularizar y aplicar sistemáticamente el Principio de Ocultamiento

de la Información. Lo hicimos cada vez que separamos y delegamos tareas, al utilizar

objetos interfaces con el exterior y entre secciones del sistema, y también cuando usamos el

polimorfismo. Las operaciones particulares quedan ocultas detrás de la clase abstracta. En

fin, introduciendo incertidumbre dentro del diseño.

Bibliografía

http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/curso/06CursoOO_DisenoEvolutivo.doc