TECNOLOGIA ORIENTADA A OBJETOS

La Tecnología Orientada a Objetos es parte de la evolución de la tecnología de información (IT:

Information Technology). Es uno de los mayores logros en el modelamiento de sistemas en la
última década.

Permite:
- Construir aplicaciones más rápidamente.
- Incrementar la calidad del producto resultado.
- Soportar el cambio de requerimientos mas facilmente.
- Soportar la migración a plataformas distribuidas.
- Permite una relación entre un modelo de negocio orientado a objetos y los componentes de un
software
desarrollado en un lenguaje orientado a objetos.

Beneficios
- Es una vía de modelado muy intuitiva porque esta refleja la forma en que nosotros pensamos
en el mundo real (utiliza nuestro vocabulario).
- Facilidad en el mantenimiento de sistemas que reflejen cambios en sus requerimientos, debido
a que los componentes desarrollados pueden cambiar y modificarse sin efectos sobre otros
componentes.
- Un mismo modelo es usado a lo largo de todo el ciclo de vida de desarrollo, desde la fase de
análisis hasta la fase de implementación (usando los mismos conceptos, simplificando la
extensión del problema y refinándolo).
- Mantiene una clara separación entre la interfaz (¿QUÉ es lo que hace un objeto?) y su
implementación (¿CÓMO lo hace?). Esta separación permite que los objetos sean más flexibles
debido a que se puede cambiar la implementación de las clases sin afectar el resto del sistema.

Ejm. Metodo Factorial.

¿ “Que hace este me todo?: Calcular el factorial de un numero entregado como parámetro.
¿ “Como lo hace?: En caso el parámetro sea 1 entrega 1. En caso contrario multiplica este por la
invocación del factorial del mismo numero menos 1.
En el ejemplo, se puede cambiar la forma de cálculo recursivo por un método iterativo.

Cliente versus Equipo de Desarrollo

Hay un numero de retos a enfrentar en la relación existente entre los clientes (o usuarios) y los
Desarrolladores, debido a las diferentes perspectivas existentes.
Clientes: Conocen su negocio y sus propias necesidades.
Desarrolladores: Están enfrentados con las siempre cambiantes tecnologías y las reglas del
negocio.

Características del desarrollo Orientado a Objetos

El desarrollo Orientado a Objetos se enfoca en los objetos como unidades de abstracción.

“Que es un Objeto?
- Un objeto es definido como una abstracción de software que modela los aspectos relevantes de
una entidad tangible o conceptual dentro de una solución (modela alguna parte de la realidad).
- Un objeto es un "paquete" de software que contiene una colección de datos relacionados
(atributos) y procedimientos (métodos) que controlan dichos datos.
-La estructura y comportamiento de objetos similares están definidos en una clase común para
especificación y simplificación. Las clases son como plantillas a partir de las cuales se pueden
crear objetos con las mismas características (Un objeto es una instancia de una clase).
- Los objetos se comunican entre ellos enviando mensajes de una a otro, los cuales producen que
se ejecute una operación (también conocido como método) en el objeto que lo recibe, logrando
así que el sistema responda.

Un objeto es la instancia de una clase (o categoría), que cuenta con una estructura:
atributos (propiedades) y operaciones (metodos). Las operaciones son todas las
actividades que el objeto es capaz de realizar.
Los atributos y operaciones, en conjunto, se conocen como características o razgos.

- La Tecnología Orientada a Objetos descompone todo un sistema en objetos los cuales

interactúan entre ellos, haciendo cosas por el sistema. Para cada objeto que se defina se debe
pensar que hará este objeto por el sistema (“que servicios hará para otros objetos?).

- Lo importante es entender como el objeto será usado en el sistema especificando solo las
operaciones relevantes.

Atributos de un Objeto
-Los Objetos tienen todo el conocimiento del sistema. Cada pieza de conocimiento es llamada
atributo, el cuál tiene un nombre y un valor. El estado de un objeto esta definido por el valor de
sus atributos.
- Los atributos son normalmente deducidos después de que se haya decidido las operaciones
que este va a brindar.
El número de atributos depende de las operaciones que el objeto ejecuta.
-Los objetos pueden necesitar acceder a los datos almacenados en otros objeto.

Operaciones principales: ¿ Atributos

principales:

-Cuenta -Retirar Efectivo. -Numero de la Cuenta.

Bancaria: -Depositar Efectivo. -Saldo de la Cuenta.
-Depositar Cheque. -Tipo de Cuenta.
-Pagar Servicio. -Moneda de la Cuenta.

Como decidir que operaciones y atributos son relevantes en el modelado de un

sistema.
En primer lugar se debe entender como un objeto será usado por otros objetos del mismo
sistema.
- Se puede definir un numero casi infinito de atributos sin embargo se debe decidir cuales son los
relevantes de tal
forma que todas las operaciones tengan algo que ejecutar con estas características
almacenadas.
Por ejemplo se puede tener como atributo de un objeto el numero de átomos que lo conforma,
pero “es esta
información útil para alguno de las operaciones del objeto?

Abstracción
La abstracción se refiere a quitar las características de un objeto para dejar sólo aquellas que
sean necesarias. Diferentes tipos de problemas requieren distintas cantidades de información,
aún si estos problemas pertenecen a un área común.

Encapsulacion “ocultamiento de información”

Es un principio de estado que agrupa datos y procesos permitiendo ocultar a los usuarios de un objeto los
detalles de implementación, ofreciéndoles una interfaz externa mediante la cual poder interaccionar
con el objeto.
Es decir se esconde los atributos del objetos para otros objetos, permitiéndose el acceso a estos
mediante sus propios métodos. Con esto se protege los datos en el objeto, evitando que otros
objetos manipulen sus valores, ya que los pueden corromper o dañar. Asimismo, al ocultar sus
atributos, centraliza el acceso a ellos a través de los métodos,
evitando recargar a otros objetos con tareas de interpretación y consulta directa de ellos.

En un sistema que consta de objetos, éstos dependen unos de otros en diversas formas. Si uno
de ellos falla y los desarrolladores tienen que modificarlo, el ocultar sus operaciones de otros
objetos significará que tal vez no será necesario modificar los demás objetos.

Beneficios
Interno:
- Evita que se ”corrompan„ los datos.
- La implementación de una operación puede cambiar sin imposibilitar que los demás usuarios la puedan seguir usando de la misma
manera.

Externo:
- Evita que otros objetos se ”compliquen„ con el uso del objeto.

Relaciones entre Objetos: Relación de:

Clasificación (Es Miembro de) -> software Microsoft : Word, Excel
Generalización (Es un) -> Vehiculo : ciclomotor, camion, auto
Agregación (Es parte de)-> Automovil ruedas, motor, volante

Asociaciones
- Los Objetos necesitan comunicarse con otros objetos. Para ello los Objetos se asocian con otros
objetos a través de enlaces (Asociaciones). Un objeto puede pasar mensajes a otro objeto
utilizando estas Asociaciones.
Las asociaciones son bidireccionales. Cada objeto puede enviar mensajes al otro.

Agregación
Es un tipo de asociación mediante el cual un objeto se conforma de otros sub-objetos (una
combinación de diversos tipos de objetos).
¿ Por ejemplo un objeto Computadora esta compuesto por los subobjetos Monitor, Teclado, CPU,
Mouse, etc.
El uso de Agregación facilita el reúso de componentes desarrollados para otros objetos. Los
subobjetos
desarrollados para un sistema pueden ser utilizados para otros.

Multiplicidad
La Multiplicidad describe el número de objetos que son parte de una asociación o enlace en un
momento en el tiempo. Es necesario identificar la multiplicidad para entender las limitaciones y
habilidades del sistema que se está modelando.
Es usualmente expresado de las siguientes maneras.
- Solo 1
- 0o1
- 0 o mas
- De 1 a Muchos

Mensajes
En un sistema los objetos trabajan en conjunto interactuando a través del envió de mensajes.
Éstos mensajes indican la necesidad de un servicio del objeto que envía el mensaje (precisando
que método ejecutar) y el otro receptor ejecutará la operación.

“Una comunicación entre objetos que transmite información con la expectativa de desatar una
acción. La recepción de un mensaje es, normalmente, considerado como un evento”

Partes de un mensaje:
- Objeto receptor
- Metodo a activar
- Parametro (opcional)
En los mensajes existe el requerimiento, del objeto emisor al receptor, y una respuesta del
receptor al emisor.
La respuesta o valor de retorno de un mensaje puede ser un objeto o un tipo simple de dato.

Ejemplo de Asociaciones y Mensajes

Clases
Una clase es una categorizacion de objetos que tienen el mismo comportamiento y la misma
estructura, de manera que se pueda especificar atributos, operaciones y asociaciones comunes a
ellos.
Ademas es una plantilla para fabricar objetos con las mismas caracteristicas.

- Cuando se crea un objeto particular a partir de una clase, es necesario que se inicialicen los
atributos y asociaciones con valores especıficos.
Ejm. Para la clase Persona al momento de crearse un objeto a partir de ella es necesario definir
los atributos de este, como son el nombre, el apellido, direccio n, etc.

Clases versus Objetos

Las clases son definiciones estáticas que nos permiten entender a todos los objetos de la misma.
Los Objetos son entidades dinámicas, que existen en el mundo real o en una simulación de el.

Herencia
Herencia es la relacion existente entre clases donde una clase llama a la otra padre.
La clase hijo puede tener atributos adicionales y un comportamiento relevante a e l ası como
puede redefinir
operaciones especificadas en la clase padre en el caso fuera requerido.

Cuando un objeto de una clase hijo es creado, e l hereda todas las propiedades de su clase padre
ademas de los
definidos en la clase hijo.

La herencia puede mejorar la productividad debido a que nuevas clases pueden ser creadas
rapidamente basadas en
clases ya existentes.

Polimorfismo (”muchas formas")

Es la propiedad por la que una operación existe en varias clases y se comporta de forma
diferente en c/u de ellas (implementacion distinta). -> pueden haber varios métodos para una
misma operacion.

Es importante que cada metodo implementado tenga la misma semantica. (Los argumentos
pasados como
parametro y el valor de retorno deben ser consistentes en todos los me todos polimorficos).

* Permite detectar y aprovechar similitudes entre distintas clases de objetos

->Objetos distintos que responden a un mismo mensaje pueden ser tratados de la misma forma
por el remitente
* La importancia del polimorfismo es que permite sea invocada una operacion en un objeto de
cualquier clase.

Ejemplos.
¿ Si para las siguientes clases
-Prestamo Largo Plazo
-Prestamo a Corto Plazo
-Sobregiro
-Tarjeta de Credito
¿ Se desea implementar un metodo de calculo de interes, cada modalidad de credito puede tener su propia tasa de interes y su
propia formula de calculo.
¿ La implementacion de cada uno de estos metodos para cada una de estas clases serıa un conjunto de metodos polimo rficos.

En ocasiones una operación tiene el mismo nombre en diferentes clases. Por ejemplo, podrá abrir
una puerta, una ventana, un periódico, un regalo o una cuenta de banco, en cada uno de estos
casos, realizará una operación diferente. En la OO, cada clase “sabe” cómo realizar tal
operación. Esto es el polimorfismo.

Caso: Generacio n de cheques para pago a proveedores

En una empresa productora de colchones, diariamente llegan insumos y materias primas utilizadas en el proceso de fabricacion provenientes de
diferentes proveedores.
- Cada embarque de materias primas llega con una factura del proveedor.
- En el almacen de la fabrica se ingresan los insumos o materias primas habiendose verificado que lo especificado en la factura del proveedor sea
exactamente lo que se esta recibiendo. (En ocasiones parte de la mercaderıa no llega completa o se rechaza parte de ella por no cumplir con ciertas
especificaciones de la empresa en cuyo caso so lo se registra en el sistema lo que se ingresa.)
- Una vez ingresada la mercaderıa se genera la nota de ingreso de mercaderıa de almacen, que junto con la factura del proveedor es enviada al area
de contabilidad, para que esta registre en el sistema la factura del proveedor (Indicandose la fecha de vencimiento, forma de pago, moneda, ademas
de otros datos.)

Caso: Generacio n de cheques para pago a proveedores

Semanalmente se obtiene un listado de las facturas vencidas o por vencer en la semana para que pase por aprobacion del gerente financiero, el cual
indica que facturas deberan ser canceladas.
De la relacio n de facturas aprobadas por el gerente financiero la persona de contabilidad procedera a generar los cheques correspondientes
(Pudiendo un mismo cheque cancelar 2 o mas facturas de un mismo proveedor.)
Definir las clases requeridas para el siguiente caso. Adicionalmente dar ejemplos de objetos de las principales clases.

Resumen
Un objeto es una instancia de una clase. Una clase es una categoría genérica de objetos que tienen los
mismos atributos y operaciones. Cuando crea un objeto, el área del problema en que trabaje determinará
cuántos de los atributos y operaciones debe tomar en cuenta.
Un objeto hereda los atributos y operaciones de su clase. Una clase también puede heredar atributos y
operaciones de otra.
El polimorfismo esquecifica que una operación puede tener el mismo nombre en diferentes clases y cada
clase ejecutará tal operación de forma distinta.
Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto presenta una
interfaz para que otros objetos (y personas) puedan aprovechar su funcionalidad.
Los objetos funcionan en conjunto mediante el envío de mensajes entre ellos. Los mensajes son
peticiones para realizar operaciones.
Por lo general, los objetos se asocian entre sí y esta asociación puede ser de diversos tipos. Un objeto en
una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase.
La agregación es un tipo de asociación. Un objeto agregado consta de un conjunto de objetos que lo
componen y una composición es un tipo especial de agregación. En un objeto compuesto, los
componentes sólo existen como parte del objeto compuesto.

Clase 2

Ciclo de Desarrollo
Fases de un Proyecto
– Toma de Requerimientos: Identificar las necesidades explıcitas o implıcitas del negocio.
Se identifican las necesidades o problemas (requerimientos) que debe proporcionar el sistema.
Estos requerimientos pueden ser funcionales (Que es lo que debe proveer el sistema) o no
funcionales (restricciones que el sistema debe cumplir como rendimiento o confiabilidad).

– Analisis: Entendimiento de ¿Que debe hacer el sistema?

En esta etapa se especifica que debe hacer el sistema. Para ello:
– Conocer acerca de las reglas del negocio y los terminos especıficos de este (Vocabulario de la
empresa), para ello se capturan todas las entidades del negocio, sus interrelaciones y su
comportamiento.
– Se desarrolla un armazon de clases usando la clasificacion natural y sus relaciones.

– Diseno:
Definir como el sistema trabaja internamente, para que los requerimientos puedan ser
entregados.
– Se profundiza en el modelo obtenido del analisis, identificando en mayor detalle los objetos que
lo
conforman y sus interrelaciones en una mayor profundidad.

– Implementacion:
Construccion del modelo disenado en el paso anterior.

– Soporte y Mantenimiento:
Puesta en marcha del sistema.
Correccion de errores cometidos durante la etapa de implementacion.

Ciclo de Vida en Cascada (Ciclo Secuencial de Actividades)

El mas conocido ciclo de vida de un sistema.
– Cada etapa del desarrollo de un sistema tiene que estar completada para iniciar con la
siguiente etapa.
– Este enfoque se asegura que el sistema este bien estructurado y bien definidos sus
requerimientos, permitiendo flexibilidad y modularidad al sistema por desarrollar.
– Su principal debilidad es la cantidad de tiempo que se requiere para entregar un producto al
cliente, ademas que
no se consideran los casos en que existen malas interpretaciones iniciales de los requerimientos.

Fases secuenciales
Comienzo de una fase con el término de la anterior
Paso de fase al conseguir los objetivos
Obtención de documentos como criterio de finalización de

fase
El final de una fase puede suponer un punto de revisión

Inconvenientes
Exige al usuario que exponga explícitamente todos los requisitos al principio, presentando
problemas para gestionar la incertidumbre natural propia del comienzo de la mayoría de los
proyectos
Hasta llegar a las etapas finales del desarrollo no habrá una versión operativa del programa, lo
que influye negativamente en el descubrimiento a tiempo de errores o incongruencias en los
requisitos

Ciclo de Vida Iterativo sistema completo; funcionalidad parcial

Como respuesta a los tiempos extensos necesarios para el desarrollo de un sistema se desarrollo
el ciclo iterativo.
– En este ciclo de vida el desarrollo esta dividido en un numero de incrementos, en donde varias
etapas del
desarrollo pueden hacerse en paralelo sin esperar que la etapa previa haya concluido.
– De esta forma se pueden entregar muchas versiones parciales de un sistema, cada una con
algunas
funcionalidades incrementadas.
– Cada fase en sı, es un pequeno desarrollo de un proyecto de sistemas.

Un proceso iterativo permite una comprensión creciente de los requerimientos, a la vez que se va haciendo crecer el sistema. Así se
logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.

Este modelo se basa en la evolución de prototipos ejecutables, mensurables y evaluables, en los cuales se van incorporando mejoras
funcionales en cada iteración (versiones).
Cada iteración reproduce el ciclo de vida en cascada, pero a una escala menor. Los objetivos de cada iteración se establecen en función
de la evaluación de las iteraciones precedentes

RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.

Beneficios
Se alienta el feedback del usuario
Focalización en los temas más críticos, sin distracciones
Testing continuo e iterativo: evaluación objetiva
Inconsistencias entre requerimientos, diseños e implementaciones se detectan tempranamente
Carga de trabajo mejor repartida en el tiempo
Integración progresiva en lugar de Big Bang
Evidencias concretas a los sponsors
Se facilita la reutilización
Arquitectura más robusta

Análisis Orientado a Objetos

La fase del Análisis Orientado a Objetos se puede dividir en las siguientes etapas:
1) Identificar el alcance del sistema
– Investigar y documentar las decisiones acerca de cuales son los alcances que tendra el sistema y cuales requerimientos estaran fuera
de este. Estaes quizas la etapa mas crıtica de todo el proyecto. debido a que en ella el usuario (cliente) define que es lo que tendra y no
tendra en el sistema final.

2) Identificar los principales Conceptos del sistema

– Se debe investigar y documentar acerca del vocabulario de negocios de la empresa.
– Esto ayuda a clarificar los terminos usados por el usuario (cliente) de tal forma que se asegura que todos tienen un comun entendimiento
de que es lo que cada termino significa.

3) Especificacion detallada de Requerimientos.

– Se investiga y documenta como el usuario interactua con el sistema y como esto afecta al mismo.

4) Examinar el comportamiento de los Objetos.

– Investiga y documenta el dinamico comportamiento de objetos especıficos del negocio en el sistema.
– Solo los objetos mas importantes del negocio deben ser considerados en esta etapa.

Diseno Orientado a Objetos

La fase de Diseno Orientado a Objetos se puede dividir en las siguientes etapas.
1) Diseno de la Arquitectura
– La mayorıa de sistemas son demasiado complejos como para entenderse como una unidad.
– Es por esto que es necesario partirlos en un conjunto de subsistemas mas simples y faciles de manejar.
– Estos subsistemas forman la arquitectura del sistema.
– Cuando se disena esta arquitectura se definen los componentes de hardware que forman parte de la infraestructura (PC,
Servidores) y los componentes de software que son necesarios construir (Aplicaciones, librerıas).

2) Diseno de Requerimientos
– Se adiciona mas informacio n al modelo con el fin de especificar como los objetos se comunican entre sı utilizando mensajes.

3) Diseno de Clases
– En esta etapa se tiene un razonable detalle y descripcion de las principales clases en el sistema..
– Se debe revisar cada clase definiendoles los atributos y operaciones.

4) Diseno de Asociaciones
– En el Analisis Orientado a Objetos (OOA) se asume que todas las asociaciones son bidireccionales.
- En esta etapa se revisa cada asociacion y se identifica la mas eficiente implementacion para los fines buscados.
Implementacion
La fase de Implementacion se puede dividir en las siguientes etapas:
1) Definir las Clases en Codigo
– Para cualquier lenguaje de programacio n utilizado, como primer pasose debe definir cada clase en el lenguaje escogido.
– En la definicio n de la clase se debe especificar: nombre de la clase, nombre de los atributos (especificando los tipos) y nombres de las
operaciones indicando el nu mero y tipo de sus argumentos.

2) Implementar las Clases

– Cada operacio n definida en una clase debe ser implementada como una funcio n separada en el programa.
– Las clases simples pueden ser implementadas por un simple programador mientras que las clases complejas tienen que ser
desarrolladas por un equipo de programadores debido a que pueden tener cientos de operaciones relacionadas.

3) Prueba Unitaria
– Cada clase antes de poder ser considerada segura para ser reusada por otros programadores en otros proyectos deberaser probada
Debidamente
– Esta prueba deberaser realizada de forma separada para cada clase.

4) Prueba de Integracio n
– Una vez se tengan todas las clases operando apropiadamente de forma independiente se debera verificar que ademas trabajan
correctamente una vez que todas hayan sido reunidas.

5) Prueba de Aceptacion
– El sistema es probado por el cliente (usuario) con la finalidad que lo valide y verifique que cumple con los requerimientos especificados.

Unified Modeling Language (UML)

¿ Que es UML?

UML aparecio a trave s de un proceso de estandarizacio n con la OMG (Object Management

Group) del cual actualmente es un estandar.
– UML es un Modeling Language (Lenguaje de Modelado). Es una notacio n principalmente
grafica de me todos usados para expresar disenos y desarrollar software

UML no es una metodologıa. Es una sintaxis visual que puede ser usada para crear modelos
metodolo gicos
como es el caso del Proceso Unificado (Unified Process, UP) base de RUP (Rational Unified
Process).

UML logra unificar los siguientes puntos:

í Ciclo de vida del Desarrollo: Debido a que provee una sintaxis visual para todas las etapas del
desarrollo de software. Desde la
toma de requerimientos hasta la implementacio n.
í Tipos de Aplicacio n: Es usado para modelar casi cualquier tipo de sistema, como sistemas en
tiempo real, sistemas de informaci o n,sistemas de soporte para toma de decisiones, etc.
í Lenguajes y Plataformas: UML puede ser usado sobre cualquier plataforma y lenguaje de
programacio n aunque se obtienen mucho mejores resultados sobre lenguajes y plataformas
orientadas a objetos.
í Metodologıas de desarrollo: Aunque UP es probablemente la
metodologıa preferida para el uso de UML, el puede soportar muchos
otras metodologıas de ingenierıa de software.
í Sus propios Conceptos: UML es consistente y uniforme en la aplicacio n de todos sus conceptos.
– Los diagramas definidos en UML se utilizan para modelar cada etapa del ciclo de desarrollo.
– Para manejar casos particulares, UML provee las herramientas para construir diagramas
adicionales o
modificar los existentes.

Esto se debe a que permite a los analistas y diseñadores de sistemas crear diagramas que capturen los requerimientos de los usuarios y
las soluciones de los analistas en una forma sencilla y fácil de comprender por todo el equipo de desarrollo, así como por los usuarios
convencionales.
1) Provee a los desarrolladores un lenguaje de modelamiento visual listo para utilizar.
Consolida un conjunto de conceptos generalmente aceptados por muchos métodos y
herramientas.
2) Proporciona mecanismos de extensión y de especialización para ampliar los conceptos
básicos.
3) Es independiente de los lenguajes de programación y de métodologías de desarrollo de
software.
4) Proporciona una base formal para entender el lenguaje de modelado.
5) Anima el crecimiento del mercado de las herramientas OO.
6) Utiliza conceptos de alto nivel de desarrollo tales como colaboraciones, armazones,
modelos y componentes.
7) Integra las mejores prácticas de desarrollo de software.

Diagramas UML
UML dispone de los siguientes diagramas:

Etapas Objetivos Diagrama a usar:

Toma Requerimientos Identificar los requerimientos, tanto funcionales como no Diagramas Use Case
funcionales del sistema. Diagramas de Actividades

Análisis í Definir claramente el propo sito del sistema. Diagramas Use Case.
í Comprender las caracterısticas, relaciones y comportamiento de Diagramas de Clases.
todos los elementos involucrados en el sistema. Diagramas de Actividades.
 í Delimitar el alcance (requerimientos) y las restricciones del sistema.
í Entender las reglas del negocio.

Diseño í Refinar el modelo desarrollado en el analisis. Diagramas Use Case.

í Detallar el comportamiento a ser implementado. Diagramas de Clases.
í Definir la forma de implementacio n de los requerimientos identificados. Diagramas de Actividades.
í Delimitar el alcance del sistema en funcio n a las condiciones de hardware Diagramas de Estados.
y Diagramas de Interaccio n.
software. Diagramas de Componentes.
Diagramas de Despliegue.

Implementacion í Desarrollar los me todos definidos en las clases funcionales. í Diagramas de Casos de Uso.
í Desarrollar la interfaz grafica de usuario. í Diagramas de Interaccio n.
í Llevar a cabo las pruebas del sistema. í Diagrama de Despliegue.
í Capacitar a los usuarios.
í Instalar el sistema.