e"

i

INFORME DE REALIZACIóN DE PROYECTO TERMINAL

PAGINA WEB COMO SISTEMA TUTORIAL DE ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

LICENCIATURA EN COMPUTAClbN L. B . x -

Prof. Luis Fernando Castro Careaga Alum. María Teresaeojas Rajs

t M. 933 22 502

...

P

L

c

L

c

L-

INDICE

I. INTRODUCCI~N ......................................................................................... 3

II. OBJETIVOS DEL PROYECTO .................................................................. 3

111. METODOLOGíA Y HERRAMIENTAS ....................................................... 4

IV. DESARROLLO DEL PROYECTO ............................................................

V. RESULTADOS OBTENIDOS ....................................................................

VI. CONCLUSIONES .....................................................................................

VII. BIBLIOGRAFíA .......................................................................................

4

5

5

6

2

i

r-

L

I. INTRODUCCI~N

El proyecto desarrolló una página Web o documento electrónico para Internet con miras a la difusión académica del curso de análisis y diseño orientado a objetos.

junto con sus espectativas, productos obtenidos, críticas y evaluaciones. Se anexa copia del disco donde se incluye el tutorial en cuestión.

En este documento se detallan todas las etapas de el proyecto realizado,

II. OBJETIVOS DEL PROYECTO

El presente proyecto consiste en desarrollar un sistema tutorial, es decir, de enseñanza a través de Internet, buscando promover la elaboración de este tipo de publicaciones en la universidad como parte de su inserción en las nuevas tecnologías de información existentes. El tema que se ha utilizado es uno de los que hace falta profundizar dentro de la Licenciatura en Computación, pues si bien dentro del plan de estudios se contempla el Análisis y Diseño de Sistemas de Computación, es en particular el enfoque orientado a objetos el que interesa destacar, ya que no es especificado como necesario en dicho curso. Actualmente muchas aplicaciones, incluyendo la programación para Windows e Internet, utilizan en dicho enfoque, de suerte que el contar con este tutorial puede auxiliar en la modernización de la enseñanza de la Licenciatura, además de difundir en línea este curso para el público en general.

De manera explícita, los objetivos son: 1. Desarrollar una página Web que condense el curso de Análisis y Diseño Orientado a Objetos que imparte el Prof. Luis Castro, dentro y fuera de la universidad. 2. lmplementar al interior de esta página applets, o pequeñas aplicaciones de Java, como animaciones o figuras interactivas, para el mejor apoyo del curso.

3

. "

, .

111. METODOLOGíA Y HERRAMIENTAS

La metodología a seguir tuvo dos vertientes: la investigación bibliográfica y el desarrollo de applets de Java para internet, que por su puesto se circunscriben en la concepción de análisis y diseño orientado a objetos.

Llegado este punto se hace indispensable especificar ¿porqué Java? Existen dos razones para programar en Java: “que su plataforma es independiente y que soporta contenido interactivo en las páginas Web (2: pp.7). Esto significa que Java puede visualizarse desde cualquier máquina que tenga un visualizador apropiado, debido a que el código que genera tras compilarse y prepararse para la ejecución no es un ejecutable binario, si no lo que se llama un “código virtual”. Este código puede entonces ejecutarse desde cualquier máquina y/o plataforma, ya que es el visualizador el que se encarga de averiguar estos detalles. Esta es la razón del auge de Java en Internet, su portabilidad e universalidad, a la vez que se cuenta con todas las ventajas de un lenguaje de programación orientado a objetos.

En particular, se propone el desarrollo de applets, que son “los programas de Java que se integran en las páginas Web. Cuando una página Web que contiene un applet se abre con un visualizador de Web, el applet se busca y ejecuta. La salida del applet se despliega en una región definida del área de la página visualizada”. Técnicamente, (...) “la clase Applet es una subclase de la clase Panel, y los applets se implementan como panels dentro del documento Web (2: pp.294).

IV. DESARROLLO DEL PROYECTO

La primera parte del presente proyecto consistió en investigación y estudios bibliográficos, para empaparse de los contenidos del curso propuesto. Se revisó asimismo material existente en forma de presentaciones de Power Point, donde el Prof. Luis Castro había anteriormente condensado los primer íterns del curso según su experiencia, y además de reutilizar estar presentaciones, éstas sirvieron de lineamiento para el desarrollo del resto del texto. Se intentó bajar de Internet algunas herramientas para la transformación del formato de Power Point a HTML, lo que no fue posible debido a fallas de la red de la UAM, por lo que el proceso de transformación se realizó manualmente.

Posteriormente se redactó en extenso el resto del curso en formato HTML, sometiéndose a revisiones sucesivas. Para ello se construyeron nuevos ejemplos a la luz de la bibliografía, pero en general se siguió el orden propuesto por la bibliografía básica principal (I), que posee una adecuada dosificación del conocimiento. Aunque existen herramientas para el desarrollo de éste código, no se apeló a ninguna, lo que hizo el trabajo quizás más pesado de lo necesario.

4

En paralelo a ello se consiguieron las herramientas de programación para Internet que se consideraron adecuadas, en particular el Microsoft Developers Studio, que auxilia la elaboración de código de Java con un entorno integrado bastante amable. Tras ello vino el aprendizaje de esta herramienta.

En este punto se desarrollaron diversos applets de prueba, que posteriormente no se incluyeron en la página, pero que sirvieron para recopilar la experiencia al respecto.

V. RESULTADOS OBTENIDOS

Se cuenta con la página que se entrega en el disco anexo, que consta de cinco archivos HTML, con varias imágenes gráficas. Quizás lo más valuable de estos archivos es el texto en sí, que fue realmente la parte más difícil de conseguir, para sistematizar y presentar de una manera comprensible todos los contenidos deseados.

Sólo se integró un applet al tutorial, que representa con animación el diagrama de interacción, mismo que se presta mucho para la animación, ya que consiste en, ya en la etapa de diseño, representar por medio de un diagrama la comunicación entre los objetos por medio de estímulos, y cómo una transacción completa se compone del envío de estímulos entre objetos y la respuesta de estos, incluyendo como respuesta una acción o el envío de nuevos estímulos. El código de este applet se anexa a este documento para cualquier ulterior uso que otra persona pueda darle.

VI. CONCLUSIONES

El proyecto se desarrolló de forma satisfactoria, aunque probablemente los resultados hubieran podido ser mejores si se hubieran incluido más personas en éI y si se hubiera desarrollado el código HTML en una herramienta como Front Page, por ejemplo. No empero lo anterior, pienso que lo más rescatable del proyecto no es sólo el tutorial mismo, si no la línea de trabajo en el desarrollo de educación a distancia por medio de Internet, que será relevante en esta época.

5 ""

I

C '

..,

c-

VIL BIBLIOGRAFíA

(1) JACOBSON, Ivar, Obiect Oriented Software Ennineerina - A Use Case Driven Al"Oach, Ed. Addison Wesley, U.S.A., 1992.

(2) JAWORSKI, Jamie, JAVA Developer's Guide, Ed. Sams Net, U.S.A., 1996.

ANEXO: copia del texto de la página HTML, así comodel pseudocódigo asociado al applet presentado.

c

"

6

Análisis y Diseño Orientado a Objetos

Luis Fernando Castro Careaga Universidad Autónoma Metropolitana - Iztapalapa lucas@xanum.uam.mx

Presentación El desarrollo de sistemas en la actualidad tiende hacia la eficiencia y calidad de los productos generados. El enfoque de Orientación a Objetos emerge como una alternativa viable para la obtención de estos objetivos. El análisis y diseño son las etapas de los métodos que más influyen en características de eficiencia y calidad, pues son en donde se determina la estructura del sistema. Existen gran variedad de métodos de Análisis y Diseño Orientados a Objetos, sin embargo, comparten aspectos de arquitectura comunes: algunos pasos del método, los procesos y las herramientas con las que se elaboran. Las variaciones más significativas estarán en la notación, la cual está en vías de estandarizarse con el Lenguaje de Modelado Unificado (UML).

Temario

Parte 1 Introducción

Parte 2 Conceptos y Método

SIGUIENTE

Parte 1 - Introducción

1 Ciclo de Vida de los Sistemas 1.1 Desarrollo de los sistemas como un proceso de cambio

0 Todos los sistemas cambian durante su tiempo de vida.

0 La mayoría de los desarrollos de sistemas se enfocan sólo sobre sistemas nuevos y no sobre cambios

Los sistemas desarrollan cambios en varias versiones.

Bajo este punto de vista, un desarrollo nuevo sólo es un caso especial.

0 Las actividades que se realizan en la generación de versiones son: Análisis, Construcción y Pruebas.

o El desarrollo se puede ver de forma incremental:

O Históricamente los sistemas se especifican por medio de requerimientos y éstos sirven como entrada para el análisis, construcción y pruebas.

O Lo anterior no funciona pues no se conocen todos los requerimientos del sistema final al momento de iniciar el proyecto.

O En realidad, el conocimiento sobre el sistema se incrementa progresivamente conforme el desarrollo avanza.

O Cuando se libera la primera versión, surgen nuevos requerimientos y cambian algunos de los originales. Este tipo de estrategia permite una rápida retroalimentación.

O En la práctica significa que el sistema puede dividirse en partes que correspondan a los servicios solicitados por el cliente.

O Es vital encontrar los requerimientos básicos desde las primeras versiones.

Prototipos:

O Sirven para determinar la factibilidad de sistema.

O Los prototipos se enfocan sobre las propiedades del sistema, pudiendo dejar de lado algunas características.

-. .. . - . ..

O Permiten la experimentación de diferentes opciones de diseño.

O Sirven de medio de comunicación entre el cliente y el supervisor.

O Una especificación no captura la dinámica del sistema de la misma forma que lo hace un prototipo.

O Debe utilizarse cuidadosamente pues es factible que un prototipo pueda tener buen grado de kncionalidad y tomarse como versión final sin cubrir la totalidad de requerimientos.

1.2 Desarrollo de sistemas y reutilización

La reutilización en distintas disciplinas es algo obvio.La Ingeniería de Software no ha logrado ubicar la reutilización en esa dimensión.

Su utilización se hace evidente en la programación, aumentando la eficiencia de los equipos de desarrollo. Pero puede aumentarse aún más la eficiencia si la reutilización se aplica a otras etapas.

El problema de la reutilización incluye el descubrimiento, comprensión e idoneidad de lo que se reutilizará.

Componentes de reutilización

0

0

O

O

Son unidades ya implantadas que se utilizan para mejorar las construcciones de un lenguaje de programación.

Deben ser poderosas y tener interfaces sencillas, permitiendo la construcción de nuevos componentes en base a ellas.

Los componentes se agrupan en catálogos de muy variadas materias, incluyendo estadística, electrónica, interfaces gráficas, etc..

En la actualidad se hace muy poco uso de la reutilización, los programadores por lo regular no buscan en catálogos, sino que prefieren realizar ellos mismos su código.

Aplicaciones cambiantes:

O Una aplicación debe diseñarse de tal forma que permita una alteración constante.

O Para construir una aplicación se juntan módulos de aplicación que sean modificables.

O Los módulos deben elegirse de tal forma que puedan combinarse en diferentes configuraciones por diferentes clientes o en diferentes sistemas instalados.

O E n la actualidad un pequeño cambio con frecuencia resulta en una alteración desproporcionadamente costosa.

0 Reutilización de otras descripciones:

O Los sistemas no sólo están compuestos por código, sino por un número significativo de otros documentos relacionados.

O La reutilización debe abarcar no sólo el código sino descripciones del sistema tales como documentos de análisis, manuales técnicos y de usuario, etc..

O Esta reutilización tiene mayores efectos que la reutilización de módulos a nivel de código fuente.

1.3 Desarrollo de sistemas y metodología

Es importante conocer cómo los distintos pasos del método cooperan y el papel que juegan dentro del proceso de desarrollo como un todo. Las partes de un desarrollo son:

Arquitectura

o La propiedad clave de un sistema de software es su estructura interna.

o Una buena estructura hace que el sistema sea fácil de comprender, modificar, probar y mantener.

Método

0 Un método es un procedimiento planificado por medio del cual se alcanza un objetivo especificado paso a paso.

0 Un método está basado en una noción preconcebida de la arquitectura del sistema en operación.

0 Los pasos de un método pueden dividirse en elementos más detallados, describiendo cómo debe realizarse el trabajo.

o Un buen método debe simplificar el desarrollo de sistemas bajo una arquitectura dada.

Proceso

Un proceso es la generalización de un método.

Un método se describe como el desarrollo ideal de la primera versión del sistema, mientras que un proceso se describe como el principio ideal de administración de la organización durante toda la vida del sistema.

Los procesos también pueden dividirse en subprocesos.

0 Los procesos expresan más que un método.

0 La descripción de procesos define cómo diferentes procesos deben cooperar y que cosas pueden hacerse en paralelo.

0 Es posible reemplazar un subproceso con uno nuevo que realice una tarea equivalente.

Herramienta

0 Para ser completamente eficientes, el trabajo de desarrollo necesita herramientas.

0 La introducción de herramientas no necesariamente cambia el proceso aunque por lo general lo hace.

0 Las herramientas se usan para automatizar un gran número de tareas, principalmente las triviales de gran volumen.

0 Para que una herramienta se utilice a gran escala debe soportar el proceso sobre el que se basa.

0 Los procesos pueden integrarse en la herramienta como una extensión.

. SIGUIENTE . . . . . . . . . . . . . .".". . . . ." "" ..

2 Orientación a Objetos La Orientación a Objetos es una técnica para el modelado de sistemas.

Se modela a los sistemas como conjuntos de objetos que interactúan entre sí.

Ya que las personas visualizan su ambiente en fbnción de objetos, se reduce el espacio semántico entre la realidad y el modelo. .

0 Presenta dos características básicas:

0 Comprensión más fácil del sistema

Modificación a nivel local

2.1 Objetos

0 Un objeto está caracterizado por varias operaciones y un estado el cual registra el efecto de estas operaciones.

0 Un modelo orientado a objetos consiste de varios objetos, los cuales son partes claramente delimitadas del sistema modelado.

Los objetos estarán compuestos por operaciones e información.

0 Las operaciones permiten el registro, consulta y manipulación de la información.

0 La única parte que es visible de un objeto son sus operaciones.

0 Dentro de la infsrmación de un objeto están su asociaciones con otros objetos. Las asociaciones pueden ser estáticas y dinámicas:

Las asociaciones estáticas subsisten por períodos largos de tiempo, lo que significa que dos objetos saben de la existencia del otro.

0 Las asociaciones dinámicas se dan cuando dos objetos se comunican entre sí.

Los objetos pueden estar compuestos por otros objetos. La razón para estructurar objetos en composición puede depender de muchos factores tales como incrementar la comprensión del modelo, y/o manejar partes reutilizables.

0 La dinámica de un objeto se crea a través de sus relaciones dinámicas, por medio de objetos enviando estímulos a otros objetos.

0 Un estímulo provoca una operación en el objeto que lo recibe.

0 El comportamiento e información están encapsulados. La única forma de afectar al objeto es a través de operaciones sobre él.

0 Para usar un objeto no es necesario saber cómo están representadas su información O SUS

operaciones.

0 Encapsulación significa entonces que todo lo que se ve de un objeto es su interfaz.

Los objetos cuyo tiempo de vida es mayor que la ejecución del programa que los manipula se conocen como objetos persistentes.

0 La ventaja de utilizar objetos es que pueden utilizarse independientemente de su implantación, o modificaciones en la misma.

Otra ventaja radica en que se reduce la complejidad, ya que no es posible tener contacto directo con la estructura interna de un objeto, eliminando la posibilidad de afectar su código y por lo mismo errores indeseables.

Ejemplos: una persona se puede considerar como un objeto de programación, porque tiene una serie de propiedades (su nombre, edad, estatura, profesión, etc.) y realiza acciones, que corresponderían a los métodos. También se tienen relaciones estáticas (la familia, amigos, etc.) y dinámicas (como la que se establece con una operadora por teléfono o con el chofer de un camión).

2.2 Clases e instancias

0 Una Clase representa una plantilla o molde para varios objetos y describe cómo estos objetos están estructurados internamente.

0 Los objetos que pertenecen a la misma clase tienen la misma definición para sus operaciones y para su estructura de información.

Una Instancia es un objeto creado a partir de una clase. La clase describe (en su

comportamiento e información) la estructura de la instancia, mientras que el estado actual de la instancia está definido por las operaciones realizadas sobre la misma.

e Un tipo está definido por qué manipulaciones pueden hacerse con él.

0 En una clase puede verse su interior, por lo que se puede ver más como una implantación de un tipo.

Ejemplos: continuando con el ejemplo anterior, las personas también se agrupan en clases. Por ejemplo, la clase "estudiante": todos los estudiantes pueden inscribirse en cursos, y deben hacer el mismo trámite para ello. Pero cierto estudiante en particular, Paco, se inscribe en ciertos cursos, mientras otro, José, toma algunos de éstos y otros más; estas dos personas representan instancias de la clase estudiante.

2.3 Polimorfismo y herencia

m

e

e

e

e

e

e

e

e

e

Polimorfismo significa que el objeto que envía un estimulo no necesita conocer la clase de la instancia destino. La instancia receptora puede pertenecer a una clase arbitraria.

Un estímulo puede interpretarse de distintas formas, dependiendo de la clase receptora.

La instancia receptora y no la emisora es quien determina la interpretación del estímulo.

Puede confhdirse el polimorfismo con la situación en la que se permiten distintas implantaciones para una hnción o enlazado dinámico.

El transmisor de un estímulo sólo necesita saber que la otra instancia puede realizar una cierta fbnción.

Sólo se especifica qué debe ocurrir y no cómo debe ocurrir.

Si se desea agregar un objeto de una clase nueva, esta modificación sólo afectará al objeto nuevo y no a aquéllos que le envíen estímulos.

Herencia significa que yo puedo declarar una nueva clase reutilizando tanto métodos como propiedades de una clase existente, tan solo declarándola una "hija" de la anterior.

Esto permite una gran flexibilidad y eficiencia; la idea es que si en varias clases tengo una serie de propiedades y operaciones comunes, las reúno, y las convierto en una superclase que las contenga a todas, de manera de definirla sólo una vez.

Puedo agregar y eliminar clases nuevas sin afectar el uso de este código para las otras.

Ejemplos: para ilustrar la herencia, pensemos en una familia; siempre se puede agregar un miembro más sin afectar a ésta en cuanto a sus lazos consanguíneos anteriores. Además, cuando una persona va al doctor no se le pregunta acerca de las enfermedades de sus hijos, sino de los padres; de la misma manera, al diseñan una clase interesa conocer los métodos y propiedades que ésta hereda de sus antecesores, y no los que facilitará a sus hijos. En cuanto al polimorfkmo, supóngase que en una oficina una persona necesita enviar un fax urgentemente; envía el estímulo

"enviar fax" a la primera persona que está disponible, ya sea una secretaria, o un ayudante cualquiera que esté capacitado para la tarea, quien, a su vez, puede realizar el envío por medio de la máquina de fax o por el módem. A la persona que escribió el fax no le importa quién y cómo mandó el fax, el emitió el estímulo y continuó desarrollando otras tareas.

3 Desarrollo Orientado a Objetos Para el desarrollo del sistema se utilizan varios modelos; en primer término se explicita el problema por medio del modelo de requerimientos, que establece los posibles cursos del uso del sistema. En base al anterior se generan los demás modelos; en el análisis se proponen las clases, sus relaciones y hnciones primordiales, que posteriormente se refinan en un proceso de diseño, donde se elabora el detalle de todas las partes del sistema, hasta el nivel de implementación. En todo momento se deben someter los modelos a diversas pruebas. Este es el tema del segundo gran apartado del curso.

Parte 2 - Conceptos y Método

4. Modelo de Requerimientos El modelo lo compone principalmente un Modelo de Casos (Use Case), que utiliza:

Actores Representan todo aquello que interactúa con el sistema y son objetos cuyo comportamiento es no determinístico.

Casos. Es una secuencia de transacciones en un diálogo con el sistema realizadas por un Actor.

Cada caso es una secuencia completa de eventos en el sistema desde la perspectiva del usuario.

El Caso contendrá en forma textual la descripción de la secuencia de pasos de la transacción.

Los actores modelan cualquier cosa que necesite intercambio de información con el sistema.

Los actores que interactuan directamente con el sistema se les llama actores primarios.

Los actores que supervisan y mantienen el sistema se denominan secundarios.

Los Casos pueden ser instanciados en cuyo caso se les denomina escenarios.

El sistema puede visualizarse como un objeto en donde sus propiedades son las clases

II ..

It-

L."*

c- "

"

.I.

. .- P .. c-

I .*

*.-

0.".

". c

i

Y

que lo componen y sus métodos son los Casos que realiza.

En un diagrama de Casos, varios casos interactuan entre sí:

0 Un Caso puede verse como la composición de varios casos más detallados.

0 En este caso el Use Case usa todos los casos más detallados.

o Cuando un Use Case utiliza otro Use Case pero sólo en ciertos casos especiales, se dice que éste último extiende al primero.

0 En el primer caso se describe esta relación con una flecha de generalización pero etiquetada con el estereotipo de usa.

0 En el segundo caso se describe con el estereotipo de extiende.

0 Ya los casos puede visualizarse como en estereotipo de clases, pueden tener estructuras de Generalización-Especialización, de tal manera que conforme se detalle más en levantamiento de requerimientos, los casos pueden especializarse.

0 Los objetos que se desprenden de los casos serán Escenarios a través de los cuales se plantean ejemplos de sebuencias de transacciones, las cuales constituyen una entrada para '

el proceso de pruebas.

0 Los escenarios tienen una gran importancia dentro del desarrollo ya que serán los casos de prueba que deben tomarse en cuenta para realizar el proceso de pruebas.

0 Ya que el modelo de requerimientos se construye cuando el analista no conoce la aplicación, es un mecanismo de capacitación para el personal de desarrollo con respecto a la aplicación.

0 Durante las primeras semanas del proyecto no es conveniente profbndizar sobre los Casos.

Conforme se desarrollan versiones se va detallando cada Caso hasta tener la especificación completa de los requerimientos.

0 El modelo de requerimientos constituye un elemento para establecer el contrato entre el cliente y el equipo de desarrollo.

0 Un segundo item en el desarrollo del modelo de requerimientos es, tras desarrollar el Use

J .

C "

."

.."

c...

c-.

, .I

C"

"

"

c -1

"

Case, proponer en base al mismo el Conjunto de Clases del Sistema. En éste, se definen 10s conceptos con los que el sistema trabajará.

Se nombran los primeros objetos, con sus atributos más evidentes y las relaciones entre ellos, sin prohndizar demasiado para permitir un análisis flexible.

Como ulterior refinamiento del modelo de requerimientos, se elabora la Descripción de la Interfaz .

o Se diseñan propuestas de la interfaz (por ejemplo, las pantallas que aparecerán en cierta aplicación), que se discuten con el usuario.

Es importante en este punto CONSIDERAR LA OPINION DEL USUARIO, no solo en cuanto a su aspecto hncional, si no en su representación del sistema según éste lo entiende.

5. Modelo de Análisis En este modelo se espera asociar el comportamiento del sistema en cada uno de los Use Case a un objeto en particular, reutilizando el mayor número de objetos que sea posible.

Para ello, se describen tres tipos de objetos: objetos entidad, de interfaz y de control. Esta '

descripción es preferentemente verbal, y detalla sus responsabilidades y funciones.

Entre los objetos pueden existir, como se mencionó antes, relaciones o asociaciones estáticas, que significan que una instancia sabe de la existencia de la otra. Para intercambiar información, se requiere además de la existencia de una asocación dinámica,

En el diagrama de análisis se unen los objetos que tienen relaciones estáticas con una línea, rotulada con el nombre que identifica la relación.

Asimismo, estas asociaciones estáticas poseen una cardinalidad, que indica cuántas instancias pueden estar asociadas estáticamente al mismo tiempo con otra.

Esta cardinalidad se simboliza entre corchetes cuadrados [ 3 dentro de los diagramas.

Los objetos de interfaz n de los actores con el sistema, en sentido bidireccional: transform or en eventos al interior del sistema y viceversa.

Cabe distinguir entre los objetos de interfaz que interaccionan con otros sistemas, de los que se comunican con el usuario. Para los primeros se requieren protocolos de comunicación, que pueden cambiar. Es importante considerar ello en el análisis, para que cualquier modificación a los objetos de interfaz en general sólo los afecte a ellos localmente. Los objetos de interfaz

también pueden manejar información y poseer algunos métodos, en la cantidad requerida en cada caso especificado en el Use Case. Los objetos entidad se construyen para modelar la información que el sistema usará de manera persistente, es decir, que en general sobrevive tras el "case" particular. También puede consistir en una información que, aunque no sea persistente, es esencial para el sistema. Para almacenar la información es que los objetos entidad requieren contar con atributos, cada uno de los cuales se caracteriza por su nombre, tipo de datos y rango de los mismos. Por ejemplo, el objeto "estudiante" puede tener un atributo "edad", que sea un entero entre 18 y 60. Normalmente, la mayoría de los objetos descritos en el Conjunto de Clases del Sistema se transforman en objetos entidades. Sin embargo, se requiere un análisis mas fino para discernir cuáles de los datos deben modelarse como entidades en sí mismas, y cuáles como atributos de otras entidades. Como se quiere minimizar el número de objetos existentes, es en este punto donde se deben buscar los atributos comunes que puedan tener varios de los mismos, para concebir una clase que los otorgue como herencia. La manipulación de la información que contiene el objeto, es decir de sus atributos, se consigue con los métodos, u operaciones. Para definir claramente qué atributos y operaciones debe tener cada objeto es de gran ayuda el seguimiento de los distintos use cases desarrollados. Típicamente, un objeto entidad posee los métodos de crear una instancia, destruirla, almacenamiento y uso de información, y otros. Una entidad puede necesitar información de otra entidad en alguno de sus métodos, para ello se establecen asociaciones de comunicación , que modela la comunicación como un estímulo enviado por parte de una instancia hacia otra, donde se realiza la manipulación de información requerida. Los objetos de control se utilizan para facilitar el ulterior mantenimiento del sistema; en rigor, se podrían obviar, describiendo el sistema sólo en fbnción de entidades y objetos de interfaz. Pero de esta manera, un cambio en el comportamiento de este objeto debería afectar a varios objetos, lo que es menos eficiente. Dentro de los objetos de control se incluyen todas las operaciones que no se integraron "naturalmente" dentro de los objetos de interfaz y las entidades. Nuevamente, no apoyamos en los Use Cases desarrollados, asociándole inicialmente un objeto de control. Si las tareas descritas ya se incluyen en los objetos de interfaz y entidades, y esto se considera correcto a la luz de este criterio de facilitar el mantenimiento, no hace falta un objeto de control. En otro caso, un objeto de control pasa a realizar la transacción del caso en particular. Si la tarea es muy compleja o compromete a demasiados actores, es mejor dividir el objeto en varios. Los objetos de control cohesionan a los otros tipos de objetos para conseguir que se complete el Use Case. Su vida suele ser efimera, es decir, se crean para la transacción, y son destruidos al final del use case.

La notación que se utiliza para cada uno de los objetos citados es:

Para cada Use Case se identifican los tres tipos de objetos necesarios, y se continúa analizando el siguiente. Esto se conoce como PROCESO ITERATIVO .

0 El siguiente Use Case requerirá la alteración de algunos objetos o la creación de algunos nuevos. El objetivo el conseguir una estructura estable con el mínimo de objetos posible, apoyándose en la reutilización de los objetos existentes y en la abstracción de atributos comunes en clases.

0 Cuando la complejidad del sistema planteado es demasiada, es probable que la cantidad de objetos sea muy grande.

." .

En este caso, es adecuado considerar al sistema como composición de subsistemas, que a su vez pueden subdividirse de esta forma.

Para el sistema, el subsistema es prácticamente un objeto, es decir, realiza una serie de operaciones y contiene cierta información, sin que deba conocer en detalle el cómo.

S1GLflENTE

Tras el análisis, la siguiente fase es la construcción, que contiene los modelos de diseño e implementación, así como diversas pruebas.

6 . Modelo de Diseño

El modelo de diseño formaliza la estructura propuesta en el análisis, considerando el entorno de implementación del sistema.

Este modelo se compone de bloques, que implementan una clase (o subsistema).

La primera aproximación del modelo de diseño se obtiene transformando cada uno de los objetos de análisis en un bloque. Así se establece la traceabilidad, por medio de la cual podemos identificar bidireccionalmente los bloques y objetos que se relacionan, lo que apoya cualquier cambio necesario.

Para adaptar el modelo al entorno de implementación hace falta estudiarlo; buscaremos involucrar o agregar el menor número de objetos para resolver los detalles técnicos relacionados con éste, recurriendo a los criterios de encapsulamiento, de manera que cualquier cambio sea local.

Los puntos a considerar dentro del entorno son:

El ambiente o sistema operativo, cuyas posibles ocurrencias deben encapsularse en un block, para mayor transportabilidad.

El lenguaje de programación , cuyas cualidades inciden directamente en cómo se manejan desde los tipod de datos y la forma de invocar las hnciones, hasta la herencia y comunicación entre procesos.

Los componentes que se utilizarán, o sea librerías de hnciones y tipos de datos.

Otros productos existentes que el sistema utilizará, tales como administradores de bases de datos o sistemas de interfaz con el usuario. También influyen los compiladores, depuradores y otras herramientas que se apliquen en la elaboración del código.

Deben estimarse las limitaciones de memoria y requerimientos del hncionamiento. Por ejemplo, es necesario diseñar la aplicación de manera que maneje una base de datos del tamaño estimado en un tiempo óptimo.

El personal y la organización, que deben afectar lo menos posible, ya que probablemente cambiará durante el ciclo de vida del sistema.

Todos estos factores deben incorporarse con el máximo de cambios en la estructura propuesta por el análisis, así como con el mayor encapsulamiento posible, para mantener la robustez del sistema.

A continuación se estructuran los diagramas de interacciones , que consisten en el diseño detallado de cada uno de los Use Case.

Estos diagramas permiten especificar la forma que tendrán los estímulos que se envíen las diversas instancias, Se han usado por largo tiempo en telecomunicaciones, donde sirven para definir los protocolos a emplear.

Cada bloque participante se representa por una línea vertical, en orden arbitrario; la línea en la extrema izquierda representa la frontera del sistema.

El eje temporal es paralelo a estas líneas, y va desde la parte superior de la hoja (antes) hacia abajo (después).

Cada operación se describe en el extemo izquierdo de la hoja, ya sea con una descripción verbal muy precisa y/o con pseudocódigo, separándose de la siguiente por medio de una línea punteada. Los bloques participantes en esta operación se destacan con un rectángulo.

Los estímulos se representan como flechas horizontales desde el bloque que lo envía al que lo recibe. La línea punteada representa estímulos alternativos.

Supongamos, por ejemplo, que se quiere obtener dinero de un cajero automático. Simplificando la operación, podemos decir que el actor es el usuario que requiere la transacción, y las clases del sistema son: el cajero, la cuenta y el depósito de efectivo. El proceso aparece animado en el siguiente APPLET.

Hay dos estructuras básicas para el desarrollo del Use Case, que se distinguen fácilmente en base al diagrama de interacciones.

En la estructura centralizada, existe un objeto que controla el flujo, envía y recibe estímulos de los demás objetos, y opera sobre ellos.

En la estructura descentralizada , los estímulos son enviados por un bloque al siguiente. En el caso extremo, el diagrama de interacción (adecuadamente ordenado) asemeja una "escalera".

¿Cuál estructura es mejor? Ello depende de qué fbturos cambios esperamos en el sistema.

La estructura centralizada es conveniente cuando las operaciones a realizar pueden cambiar de orden, ampliarse o reducirse.

La estructura descentralizada corresponde cuando no se espera que el orden de las operaciones cambie, y se desea encapsular el comportamiento del bloque o una parte de él.

0 Una vez que se han diseñado todos los Use Case que atañen a un bloque en particular, se procede al diseño de bloque.

Diseño de bloques

0 La implementación del bloque se realiza desde los ancestros, para luego ir desarrollando las clases descendentes.

o Para el diseño del bloque en particular se cuentan con las descripciones de requerimientos de los Use Case, que se han explicitado por medio de los diagramas de interacción. En ellos ya hay una descripción de las operaciones en el margen izquierdo, y al reunirlos todos se tendrá la visión de las operaciones e interfaces necesarias.

o En cuanto a la interfaz del bloque, se pueden empezar a contemplar conceptos propios de la programación, tales como los métodos y propiedades que serán públicos o privados, lo que permite una reducción de la complejidad, al encapsular los detalles de la implementación.

0 El comportamiento de los objetos puede ser descrito con un Diagrama de Transición de Estado, en el que se describen los resultados de recibir ciertos estímulos.

0 Estos diagramas de transición de estado sirven para describir un autómata finito, y se conocen como máquinas de Mealy.

0 L o anterior también se puede llevar a diagramas de flujo, como los que se usaban para la programación estructurada, o bien redactar en pseudocbdigo de forma más detallada.

Aquí falta ejemplo con figura.

3.4 Modelo de Pruebas e Implementación

o Una vez que se ha llegado a detallar los diagramas de transición o de flujo, deviene el desarrollo del código de programación. De hecho, existen herramientas que realizan esta tarea automáticamente, pero incluso en ése caso siempre es necesaria la supervisión por parte del programados de algunos detalles.

0 Una característica relevante del modelo del sistema desarrollado es la traceabilidad de las clases que ahora se implementarán, es decir, desde el código fuente se puede saber a qué clase en el análisis se refiere, y viceversa.

Esta característica es de gran utilidad para el mantenimiento del sistema.

o En la implementación se deben considerar las características del lenguaje de programación, y mantener la estructura propuesta por el sistema ya sea por medio de las clases que ofrezca el lenguaje, o por medio de archivos y librerías.

0 Por una prueba entendemos un punto en algún use case donde otro comportamiento puede insertarse. Como la descripción original debe ser independiente de la nueva, deben evaluarse las estructuras de control al presentarse esta inserción.

. ES preferible comenzar la etapa de construcción tempranamente, casi paralelo al análisis, y aplicar pruebas a los use case desde el papel. Ambas medidas pueden dar contexto al desarrollo del sistema, en aras de su robustecimiento.

paginas-tere

P-

/ / Este applet anima un diagrama de transicion

import java.applet.*; import java.awt.*;

public class transicion extends Applet implements Runnable I

private Thread m-transicion = null; private int m-fps = 10; public final static Color azul = new Color(0,0,255); public final static Color blanco = new Color(255,255,255); public final static Color negro = new Color(O,O,O); public final static Color rojo = new Color(255,0,0); public final static Color verde = new Color(0,255,0); public final static Color cyan = new Color(0,255,255); public final static Color amarillo = new Color (255,255, O) ; public String st = "Bold"; public Font let = new Font (st, 1,181 ; public Font lety = new Font(st,l,l2); public int flag; / / se utiliza para iniciar la animación public int pant; //contador de las pantallas fps public int cont; / / representa el contador del tiempo //en este array se encuentran todos los incrementos de las flechas public int [I F; public int delta = 1;

/ / Parameter names. To change a name of a parameter, you need only make / / a single change. Simply modify the value of the parameter string

below. //"""""""""""""""""""""""""""""""""""-

"_ private final String PARAM - fps = "fpsV1;

/ / doble buffer para la imagen

private Image m-image; / / off-screen image private Graphics m-g; / / objeto gráfico asociado Dimension m-dimImage; / / tamaño de m-image

public transicion ( ) I I

public String getAppletInfo() (

return "Name: transicion\r\n" + "Author: María Teresa Rojas Rajs\r\n" + "Created with Microsoft Visual Jt+ Version 1.1";

I

public String [ I [ I getParameterInfo ( ) 1

String[] [ I info =

( PARAM-fps, 'lint'', "Parameter description" }, I ; return info;

1

public void init ( ) {

paginas-tere

String param; flag == O; cont = O; pant = O; F = new int [6] ; param = getParameter(PARAM fps); if (param ! = null)

-

m-fps = Integer.parseInt(param); resize (600, 415) ;

F[O] = 200; F[1] = 300; F[2] = 400; F[3] = 400; F[4] = 500; Dimension dim = size();

I

public void destroy0 I 1

public void paint(Graphics g) I

g . setFont (let) ; / / lo que siempre se tiene que dibujar

g.setColor(amarillo) ; g.drawLine(200,30,20Ot390); g.setColor(verde); //hacerla dashed g.drawLine(20,10Ot 600,100) ; g.drawLine (20,200,600,200) ; g.drawLine(20,30Ot 600,300) ;

g.setColor(azu1); g.drawLine (300,30,300,390) ; g.drawLine (400,30,400,390) ; g.drawLine (500,30,500,390) ; g . setcolor (negro) ; g.drawString("Frontera", 150,15) ; g.drawString("Cajero",255,15); g.drawString("Cuenta",350,15) ; g.drawString ("Deposito", 450,lS) ; g.drawString (""+cont,20,30) ; g.drawString("E1 usuario pide", 20,60) ; g.drawString("una suma de dinero", 20,90) ; g.drawString("E1 cajero pregunta", 20,140) ; g.drawString("a la cuenta su saldo", 20,170) ; g.drawString ("La cuenta establece", 20,240) ; g.drawString ("si hay solvencia", 2 0 , 2 7 0 ) ; g.drawString ("Entrega de efectivo", 20,350) ;

g.setColor(cyan); g. fillRect (280,100,40,100) ; g. fillRect (380,200,40,100) ; g. fillRect (480,300,40,100) ;

/ / lo que se anima g . setFont (lety) ; g . setcolor (negro) ; g.drawStr ing("Sol ic i tud" ,220 ,90) ; g.drawLine(200,100,F[O],lOO); g.drawLine(F[0]-10,9O,F[O],lOO); g.drawLine(F[0]-10,110,F[0],100);

if(F[O] >= 300) ( g.drawString("Saldos",330,190) ; g.drawLine(300,200,F[l] ,200); g.drawLine(F[1]-10,190,F[1],200); g.drawLine(F[1]-10,2lO,F[l],~OO);

if (F[1] >= 400) ( g.setColor(rojo);

g.drawLine (400,300, F[2], 300) ; g.drawLine(F[2]-10,290,F[Z] ,300); g.drawLine (F[21-10,310, F[2], 300) ;

g.setColor(negro); g. drawstring ("Solvencia", 430,290) ; g. drawstring ("No-Solvencia", 280,290) ;

if (F[2]>=500) t g. setcolor (negro) ; g.drawLine(500,40O,F[4],400); g.drawLine(F[4]+10,390,F[4],400); g.drawLine(F[41+10,410,F[4],400); g.drawString ("Efectivo", 430,390) ;

public void start() t

if (m-transicion == null) (

m-transicion = new Thread(this); m-transicion.start0;

I I

public void stop()

paginas-tere

if (m transicion != null) I

-

m-transicion.stop(); m transicion = null;

I -

1

public void run0 (

while (true & & F[4]>200) (

try (

pant++; if (pant813==0) cont++; if(F[0]<300) { F[O] = F[O] + delta;) else { if (F[1]<400) (F[l] = F[1] + delta;] else ( if (F[3]>200) (F[3] = F[3] - delta;]

if(F[2]<500) (F[2] = F[2] + delta; else

( if 1

1 repaint ( ) ; Thread.sleep

1

F[41>200) F[4] = F[4] - delta;]

5 0 ) ;

catch (InterruptedException e) (

stop ( ) ;

I

public boolean mouseDown(Event evt, int x, int y) t

flag == 1; return true;

1

public boolean mouseUp(Event evt, int x, int y ) I

1 return true;