Curso ADOO - UML

ESPECIALIZACIÒN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE
SOFTWARE
ANALISIS Y DISEÑO ORIENTADO A OBJETOS

UNIFIED MODELING LANGUAGE (UML)
Ing. Sandra Johanna Moreno Valero
(Este material es reproducido con fines educativos)
Mayo de 2006
1. INTRODUCCION
Análisis y diseño es el primer paso en el desarrollo de un sistema de software. Análisis es

el proceso de obtener los requerimientos del software y organizarlos en formatos
estándares que pueden ser pasados al diseño por ingenieros desarrolladores. Los
clientes, administradores y usuarios finales hablan un lenguaje diferente a los ingenieros
del software. El análisis es el puente entre quienes utilizaran el software y quienes los
desarrollarán.
En el contexto del desarrollo de software, la fase de análisis se enfoca en los siguientes

ítems:
Establecer una vista clara del problema del negocio

Hacer un bosquejo de las tareas que el sistema debe ejecutar
Desarrollar un vocabulario común para el problema del negocio
Hacer un bosquejo de la mejor solución para el problema del negocio
El diseño es el proceso de pasar los resultados del análisis en un borrador para el sistema
en desarrollo. El diseño muestra suficientes detalles que le permiten a un grupo diverso
de administradores y programadores desarrollar el sistema.
En el contexto del desarrollo de software, la fase de diseño se enfoca en los siguientes

ítems:
Resolver el problema del negocio

Definir cómo en lugar de qué
Introducir elementos de soporte que harán que el sistema trabaje
Definir una estrategia de implementación del sistema
Sin embargo, no existe una división clara entre análisis y diseño en el proceso de
desarrollo de un sistema de información
En los años 70’s las metodologías de análisis y diseño de sistemas se hicieron más
formales y proveían una manera estándar de hacer un sistema de información en papel
antes de iniciar el desarrollo. Estos métodos se centraban en el flujo de información
dentro de fuera de subsistemas funcionales.
Orden de
Orden Inventario compra Proveedor
Despachar Base de datos Ordenar
orden de inventarios inventario
Cliente
Orden
Orden Reporte
Tomar Base de datos de Despachar Administrador
orden órdenes Ordenes orden
Orden
Figura 1-1: Ejemplo de diagrama de flujo de datos
El flujo de datos está representado por las flechas comenzando del origen (como un
cliente) pasando por el proceso (como poner una orden o generar un reporte) y
terminando en la información de los clientes (como la administración). Descomponiendo el
sistema de esta manera, los subsistemas funcionales pueden ser desarrollados
individualmente. La mayoría de los principios desarrollados en estos tempranos modelos
de análisis y diseño desembocaron en las modernas metodologías de análisis y diseño
orientado a objetos.
1.1. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
Los modelos estructurados centran su atención en el flujo de información a través del

manejo de datos y funciones. Análisis y diseño permite a los diseñadores y
desarrolladores visualizar el software como un conjunto de funciones atómicas la cual
cada una de ellas realizan una tarea específica. Esto permite un desarrollo más rápido,
menos errores de código y reduce los riesgos del proyecto. Sin embargo, debido a que los
computadores cada vez son más veloces, pequeños y baratos, se ha demandado el
desarrollo de sistemas de información más complicados y menos centralizados los cuales
estén distribuidos sobre múltiples sistemas computacionales, sistemas operativos y
ubicación geográfica.
Los métodos orientados a objetos intentan satisfacer estas demandas. El componente

fundamental del modelo estructurado es la función. Los datos son generados fuera del
sistema y fluyen a través de un conjunto de funciones antes de ser almacenados o
procesados. En un modelo orientado a objetos, los datos se convierten en el componente
fundamental en forma de objetos.
Examine el flujo de datos de la figura anterior. Un cliente coloca una orden, su información
es pasada a las funciones “Tomar Orden” y “Despachar Orden”. En un modelo orientado a
objetos, la información de la orden podría ser identificada como un objeto. Un objeto
mantiene propiedades acerca de su estado. Por ejemplo, el objeto orden podría mantener
una lista de ítems ordenados, una dirección de envío y un método cuenta.
Pero ¿de qué manera es un objeto diferente de los datos en un programa estructurado?.
En un programa estructurado, los datos son pasados a través de funciones que operan en
ellos. En un programa orientado a objetos, se envían mensajes a los objetos para que
ellos decidan cómo operan sobre ellos mismos. La figura 2, ilustra un objeto orden con
propiedades definidas dentro de él. En lugar de pasar el objeto orden a través de una
función, el objeto orden es enviado al mensaje “Despachar Orden” y la orden se envía ella
misma.
Orden
Despachar
Ítems
Orden Dirección de
envío
Método de pago
Figura 1-2: Objeto Orden
1.2. METODOLOGÍA DE ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
Una metodología de análisis y diseño orientado a objetos es un proceso que contiene una
notación para la definición del software, basado en el concepto de objetos que combinan
la estructura y el comportamiento en una entidad simple. Este proceso no es
necesariamente lineal sino predecible, repetible, es posible probarlo y hacerle
seguimiento. La notación de OOA&D es una definición visual que permite compartir el
conocimiento acerca del sistema disminuyendo ambigüedades.
La metodología OOA&D consiste de tres partes:
Un proceso o secuencia de actividades relacionadas y entregables que son utilizadas

para modelar y construir el software.
Una notación o representación, generalmente gráfica, de los susbsistemas que forman
el sistema y la descripción de cómo interactúan.
Un conjunto de reglas que describen cómo funciona el sistema.
1.3. CRISIS DEL SOFTWARE
Análisis y diseño tiene varios propósitos. Esto permite a los desarrolladores enfocarse en
las dificultades técnicas, ayuda a asegurar que las entregas cumplan las expectativas del
usuario y lo más importante minimiza el riesgo.
Cuando el desarrollo de un producto es demorado se dice que existe crisis del software y
los eventos que llevaron a buscar soluciones a esto fueron:
En marzo de 1989, Arthur Andersen reportó:

o Más de $ 300 billones por año son gastados en las actividades de
mejoramiento de software comercial en los Estados Unidos.
o Sólo el 8% del software que es entregado trabaja sin ningún cambio.
El aeropuerto computarizado de Denver tuvo pérdidas millonarias debido al retraso
en la apertura del mismo a causa del software.
1.4. VENTAJAS DE LA TECNOLOGÍA DE OBJETOS
Un paradigma simple
El modelo refleja el mundo real
Mantenible: La programación orientada a objetos hacen el código mantenible,
porque es más fácil identificar el origen de los errores ya que se encuentran dentro
de los mismos objetos.
Reusable: Porque los objetos contienen datos y funciones que actúan sobre datos,
los objetos pueden ser como cajas negras. Esta característica hace fácil la
reutilización de código en nuevos sistemas. Los mensajes proveen una interfaz
predefinida de los datos y funcionalidad de un objeto.
Escalable: Los programas orientados a objetos son más escalables. Como una
interfaz de un objeto provee una ruta para la reutilización del objeto en una
aplicación nueva, también provee toda la información necesaria para reemplazar el
objeto sin afectar otro código.
1.5. DESVENTAJAS DE LA ORIENTACIÓN A OBJETOS
Existen pocos retos en esta transición de la ingeniería del software a la tecnología

orientada a objetos. Varios sistemas empresariales fueron construidos bajo el paradigma
estructural. Lograr interfaces con estos sistemas no provee retos técnicos sino retos de
diseño. La meta es minimizar los efectos de los sistemas estructurales sobre los nuevos
diseños orientados a objetos.
La capacitación hacia estas nuevas tecnologías podría ser una desventaja porque la
programación orientada a objetos ha existido desde finales de los 80’s, sin embargo, sus
principios aparecieron en el ámbito educativo sólo hasta 1995.
1.6. CARACTERÍSTICAS PRINCIPALES DE LA PROGRAMACIÓN ORIENTADA A
OBJETOS
1.6.1. Abstracción
Se refiere al concepto de ignorar los detalles y concentrarse en las características
esenciales de un objeto o entidad. La abstracción simplifica la funcionalidad y la
información y ayuda a los usuarios interactuar con el objeto. El proceso de desarrollar
clases en términos de sus interfaces y funcionalidad, en lugar de los detalles de
implementación, es llamado abstracción.
La abstracción es utilizada para manejar la complejidad. Los ingenieros del software

utilizan la abstracción para descomponer sistemas complejos en componentes más
pequeños.
1.6.2. Encapsulación
La encapsulación oculta los datos dentro de un objeto. Por ejemplo, el funcionamiento
interno de un teléfono está oculto para el usuario o está encapsulado. Los botones del
teléfono proveen la interfaz para que el usuario opere el teléfono.
La encapsulación produce dos vistas de cada objeto:

Vista externa, la cual muestra lo que el objeto hace
Vista interna, la cual muestra cómo el objeto ejecuta sus tareas
La ventaja de la encapsulación es que la clase puede cambiar. Si los cambios se reflejan

sólo en la implementación oculta, y si la nueva interfaz es compatible con la original, los
programas que utilizan dicha clase, no se ven afectados.
1.6.3. Asociación
La asociación es la forma en que los objetos interactúan. Los objetos son asociados
cuando un objeto “utiliza” los servicios u operaciones de otro objeto. Por ejemplo, dos
objetos independientes pueden decidir colaborar para alcanzar cierto objetivo. Después
que el objetivo es alcanzado, ellos continúan existiendo independientemente uno del otro.
1.6.4. Agregación
La agregación define un objeto en términos de las partes que lo componen. Por ejemplo,
un carro tiene un motor, llantas, sillas, etc. Si falta alguna de ellas, el carro no funciona
adecuadamente.
El carro es definido por sus partes, o el carro tiene una relación de agregación con sus
partes. Esta clase de relación “tiene un” es llamada agregación. La agregación es un tipo
de asociación.
1.6.5. Composición
La composición se da cuando un objeto es contenido dentro de otro. La composición se
caracteriza por una relación de “contención”. Por ejemplo, un lápiz está compuesto por
una mina en la punta y un objeto de madera en forma de tubo. Sin la mina, el lápiz no
ejecutaría su función correctamente.
En varias ocasiones, los objetos no pueden existir independientemente de otro. En este

caso, la composición es la relación más adecuada.
1.6.6. Herencia
La herencia es un mecanismo que define una clase nueva en términos de otra existente.
Esto permite agrupar clases relacionadas, por lo tanto, pueden ser usadas y manejadas
colectivamente. La herencia se identifica por las frases “Es un” o “Es una clase de”.
1.6.7. Cohesión y Acoplamiento

Cohesión es una medida del soporte que una entidad brinda en el mismo propósito dentro
del sistema. Acoplamiento es una medida de dependencia entre entidades.
El acoplamiento es también una medida de dependencia entre objetos. Los objetos

pueden ser clases, sistemas, subsistemas, aplicaciones, grupos de clases u objetos
individuales.
1.6.8. Polimorfismo
Polimorfismo es el concepto de definición operaciones similares para más de una clase.
Una función es descrita como polimórfica si es posible aplicarla a objetos de diferentes
clases para alcanzar el mismo resultado semántico.
El concepto de polimorfismo está basado en la herencia. El polimorfismo soporta la

reutilización y el mantenimiento.
La implementación de una función polimórfica depende del objeto en el cual se aplica.

Algunas clases definen objetos similares y tienen métodos iguales. Por ejemplo, si se
tiene una pelota de fútbol americano y otra de tenis, estas dos son similares y es posible
definir la operación “lanzar”. La implementación de la operación es diferente. Una pelota
de fútbol americano se lanza con las dos manos y una de tenis se lanza al aire con una
mano para servir.
Cuando se crea una nueva pelota, no es necesaria la instrucción para la utilización del
método. La hija reconoce la clase de pelota y aplica el método genérico “lanzar”.
El polimorfismo funciona sólo cuando la operación común es semánticamente similar.

2. UNIFIED MODELING LANGUAGE (UML)
Lenguaje escrito por Grady Booch, Jim Rumbaugh e Ivar Jacobson, y desde noviembre
de 1997 es un estándar y pertenece a la OMG (Object Management Group). UML es un
lenguaje gráfico para especificar, construir, visualizar y documentar los artefactos o
productos entregables de un sistema de software. UML utiliza un lenguaje de notación
gráfica para representar los artefactos que hacen parte del OOA&D.
UML brinda la sintaxis para describir la estructura de clases, componentes, programas y

sistemas de software así como también describe la interacción entre estos ítems.
Es importante recordar que UML no define un proceso, sólo se puede utilizar UML cuando
se tiene un proceso clara para OOA&D. El proceso OOA&D es una aplicación o un
problema independiente. A pesar que el proceso unificado (Unified Process) está
altamente relacionado con UML, UML fue desarrollado en forma separada de este
proceso y está diseñado para ser utilizado con cualquier proceso de desarrollo iterativo de
software.
UML maneja diagramas que permiten tener un modelo mental del sistema de software.
Estos diagramas son usados para construir varios artefactos en el flujo de trabajo y son
los siguientes:
o Diagrama de casos de uso que representan el comportamiento del sistema con un

actor dado.
o Diagrama de clases que representa una colección de clases de software y sus
relaciones.
o Diagrama de objetos que representa una toma de los objetos de software y sus
relaciones en el momento de ejecución.
o Diagrama de colaboración, representa una colección de objetos que trabajan en
conjunto para soportar el comportamiento del sistema.
o Diagrama de secuencia que representa una perspectiva de la colaboración de los
objetos durante un periodo de tiempo.
o Diagrama de actividades que representa un flujo de actividades que pueden
ejecutarse por el sistema o por un actor.
o Diagrama de transición de estados que representa el conjunto de estados que un
objeto puede experimentar y las transiciones que sufre de un estado a otro.
o Diagrama de componentes que representa una colección de componentes de
software y sus relaciones.
o Diagrama de distribución que representa una colección de componentes y muestra
cómo se distribuyen a través de uno o más computadores.
o Diagrama de paquetes que representa una colección de otros elementos y
diagramas modelados.
Los diagramas de UML crean diferentes vistas del sistema. Una vista de comportamiento
compuesta por el diagrama de casos de uso y presenta lo que se requiere del sistema;
una vista estructural que muestra cómo está estructurado el sistema para satisfacer los
requerimientos y está compuesto por los diagramas de paquetes, de componentes, de
clases, de objetos y de distribución; y una vista dinámica que muestra cómo el sistema
interactúa para satisfacer los requerimientos y está compuesta por los diagrama de
secuencia, de colaboración de transición de estados y de actividades.
Fuente: Object-Oriented Analysis and Design using UML. Student guide with instructor notes. Sun Microsystems 2003.
Revision C.
Figura 2-1. Vistas de los diagramas de UML.
Es posible ver la vista dinámica desde dos niveles: el ciclo de vida de un objeto desde que
se crea hasta que se libera, y la interacción de los objetos con el sistema, tal es el caso
del diagrama de estados de UML que describe un objeto y los diagramas de secuencia y
colaboración que describen la interacción entre objetos.
Existen otros elementos importantes dentro de UML como lo son la notación para los
paquetes, y los mecanismos de extensión como las notas, estereotipos, y reglas.
3. PROCESO UNIFICADO DE DESARROLLO
3.1. PROCESO DE DESARROLLO TRADICIONAL
El método de Cascada es el proceso de desarrollo de software más popular.
Tiempo
Requerimientos
Análisis
Diseño
Implementación
Pruebas
Figura 3-1: Metodología de cascada para el desarrollo de software
En el método de cascada, el proceso de desarrollo es completado en una dirección a

través de las fases requerimientos, análisis, diseño, implementación y pruebas. Cada fase
debe ser completada y documentada antes de pasar a la siguiente fase. Si se encuentra
un problema en una fase posterior, es difícil devolverse a una fase anterior. Los
proyectos que siguen este proceso toman mucho tiempo y esfuerzo en asegurar que cada
fase sea correcta.
Para maximizar los beneficios de UML, es necesario utilizar un proceso de análisis y

diseño orientado a objetos.
3.2. PROCESO UNIFICADO DE DESARROLLO
A continuación se describe una metodología basada en el proceso unificado de desarrollo

de software, desarrollado por Ivar Jacobson, Grady Booch y Jame Rumbaugh.
El proceso unificado de desarrollo de software es conducido por los casos de uso,

centrado en la arquitectura e Iterativo e Incremental.
Conducido por los casos de uso: Un caso de uso es la manera en la cual el usuario
interactúa con el sistema. Los casos de uso son el centro del proceso unificado. Ellos
funcionan como requerimientos del sistema de software. El modelo de casos de uso
representa la interfaz entre la funcionalidad del sistema y los usuarios del mismo. Cada
caso de uso sirve como un requerimiento que pasa a través del proceso de diseño,
implementación y pruebas.
Centrado en la arquitectura: El proceso unificado presta gran atención en la arquitectura

de un sistema de software. Ningún software existe en el vacío. Por ejemplo, en un sistema
de biblioteca que opera sobre un servidor UNIX y utiliza un paquete particular de base de
datos. También es posible acceder a datos de un mainframe. Los usuarios acceden al
sistema desde computadores con Windows localizados dentro de la biblioteca. Los
empleados de la biblioteca utilizan hardware especial para automatizar el proceso de
préstamo de libros. Los usuarios remotos acceden al sistema con una interfaz web y un
applet de Java.
Todas estas opciones de software componen la arquitectura del sistema de biblioteca.

Debido a que los computadores han llegado a ser más poderosos y omnipresentes, el
software ha incrementado la complejidad y han llegado a ser más distribuidos. Por lo
tanto, la arquitectura del sistema es bastante importante y requiere una atención especial.
El proceso unificado hace de la arquitectura una parte integral del desarrollo de software.
Iterativo e incremental: El proceso unificado divide un proyecto de desarrollo en una serie

de iteraciones. Una iteración es un ciclo de desarrollo que termina con la entrega de un
subconjunto del producto final. Cada iteración tiene todos los aspectos del desarrollo de
software. Cada entrega iterativa es una pieza totalmente documentada al final del
sistema.
Esta característica presenta los siguientes beneficios:
Reducción del riesgo basado en la temprana realimentación

Mayor flexibilidad de acomodar nuevos requerimientos
Reducción de costos
Incrementar la calidad del software
En cada iteración se deben realizar los siguientes pasos:

Seleccionar y analizar los casos de uso relevantes
Crear un diseño utilizando la arquitectura seleccionada
Implementar el diseño en componentes
Verificar que los componentes satisfacen los casos de uso
Cuando se consigue la meta en una iteración, se procede a la siguiente iteración.
El proceso está compuesto por fases, las cuales se componen de flujos de trabajos
(workflow), estos se componen de actividades específicas, las cuales involucran
trabajadores y artefactos. Un trabajador es una persona que ejecuta una actividad. Un
artefacto es una pieza tangible de información que es producida por una actividad; por
ejemplo, diagramas, documentos y el código de software.
Fuente: Object-Oriented Analysis and Design using UML. Student guide with instructor notes. Sun Microsystems
2003. Revision C.
Figura 3-2: Pirámide del desarrollo de software orientado a objetos
3.3. FASES DEL PROCESO UNIFICADO
El proceso unificado se compone de las fases de inicio, elaboración, construcción y

transición y no sigue actividades específicas como lo hacían modelos anteriores. Todas
las actividades de desarrollo desde los requerimientos hasta las pruebas, se realizan
durante cada fase. Por lo tanto, cada incremento del software consiste de cinco flujos de
trabajo:
Requerimientos y análisis inicial

Análisis
Diseño
Implementación
Pruebas
Figura 3-3: Fases del Ciclo de Desarrollo
3.3.1. Fase de Inicio
Los propósitos de la fase de inicio son:

Comenzar el proyecto
Establecer una fundamentación para el proyecto
Determinar el alcance del proyecto
Crea un problema de negocio
Identificar los riesgos críticos
Definir el alcance del proyecto para entender el problema
Crear documentos que expliquen el problema del negocio
Preparar el ambiente para el proyecto
Los productos entregables en esta fase son:
Principales requerimientos del proyecto (funcionales y no funcionales)

Una visión del producto
Estimación inicial de riegos
Glosario
Opcionales:
Un prototipo conceptual
3.3.2. Fase de Elaboración
Los propósitos de la fase de elaboración son:
Crear un modelo de análisis y diseño de alto nivel

Establecer una arquitectura de base para el proyecto
Analizar el dominio del problema
Monitorear los riesgos críticos del proyecto
Desarrollar un plan que presente cómo será terminado el proyecto.
Modelo del comportamiento del sistema

Una arquitectura a seguir
Un plan de desarrollo
Plan de iteraciones con entregas descritas
Unos criterios de evaluación
3.3.3. Fase de Construcción
El propósito de la fase de construcción es:
Desarrollar incrementalmente el producto software.

Administrar recursos, controlarlos y optimizarlos
Los productos entregables de esta fase son:
Entregas ejecutables
Prototipos de comportamiento
Resultados de calidad
Documentación del sistema y del usuario
Plan de distribución
Criterios de evaluación para la siguiente iteración
3.3.4. Fase de Transición
Los propósitos de la fase de transición son:
Presentación del producto al cliente

Completar la capacitación de usuarios y pruebas
Validar el sistema con las expectativas del usuario
Producto terminado
Análisis del proyecto
Documentación de pruebas
4. DESARROLLO DE UN SISTEMA DE SOFTWARE
4.1. CAPTURA DE REQUERIMIENTOS
Es posible obtener información de diferentes fuentes, dentro de las cuales encontramos:
Especificación inicial de requerimientos por parte del cliente

Expertos del dominio
Clientes y usuarios
Administradores
Proyectos anteriores
Documentación sobre políticas y procedimientos
2003. Revision C.
Figura 4-1: Mapa del proceso Captura de Requerimientos

Existen dos tipos de requerimientos a ser capturados, los requerimientos funcionales y los
no funcionales. Los requerimientos funcionales especifican las tareas que el sistema
ejecutará. En la mayoría de los casos, los requerimientos funcionales describen la forma
en la cual el sistema reaccionará con las entradas del usuario.
Los requerimientos funcionales (FR) también incluyen la interfaz del usuario, la cual debe
ser descrita en papel o es posible construir un prototipo para ayudar a los usuarios a
entender la manera como ellos interactuarán con el sistema.
Los requerimientos no funcionales (NFR) son propiedades del sistema, como rendimiento,
utilización de memoria, confiabilidad, flexibilidad, entre otros. En muchos casos, los
requerimientos no funcionales aplican a un conjunto específico de casos de uso.
Rendimiento se refiere a la habilidad de procesar operaciones de un usuario

dentro de los rangos de tiempos deseados.
Escalabilidad se refiere a la habilidad de crecer a través del tiempo y está
relacionada con el rendimiento.
Usabilidad se refiere a la forma de interacción del usuario con el sistema,
comúnmente su valor debe ser “fácil de usar”.
Seguridad es la habilidad de controlar el acceso a los servicios y la información de
un sistema, como también de detectar, aislar y recuperar información en caso de
fallas.
Después de la captura de requerimientos es conveniente generar un documento que

describa claramente los clientes y los requerimientos del sistema para el proyecto (SRS:
System Requirements Specification). Este documento en donde se declara el problema
debe especificar lo siguiente:
Toda la información que es pertinente para el análisis y diseño del proyecto

Cualquier regla o restricción que debe considerarse en el desarrollo del proyecto
Los usuarios que utilizarán el sistema
Las entradas y salidas del sistema
4.1.1. Diagramas de Casos de Uso
El principal medio de captura de requerimientos en el proceso unificado es el diagrama de

casos de uso, el cual ilustra las relaciones entre un sistema software y sus usuarios. Estos
diagramas describen todas las formas en las cuales un usuario interactúa con el sistema.
El conjunto de los diagramas de casos de uso y sus descripciones constituye el modelo
de casos de uso. Este modelo es uno de los principales entregables del flujo de trabajo de
requerimientos. El diagrama de casos de uso provee una representación visual de los
requerimientos funcionales del sistema.
4.1.1.1. Actores
Los usuarios de un sistema de software están representados como actores en un

diagrama de casos de uso. Los actores se utilizan para representar usuarios específicos,
grupos de usuarios, usuarios organizacionales e incluso sistemas de software externos.
Un actor se representa como la figura mostrada a continuación.
Estudiante
Figura 4-2: Ejemplo de un actor
Múltiples usuarios pueden asumir el rol de un actor. Por ejemplo, todos los estudiantes
asumirán el rol del actor estudiante.
4.1.1.2. Casos de Uso
Los actores mantienen relaciones con los casos de uso. Un caso de uso es la descripción
de alguna actividad del software que un actor debe iniciar; también se puede describir
como la especificación de una secuencia de acciones que el sistema debe ejecutar. Un
caso de uso se representa por un ovalo con una etiqueta que identifica el caso de uso.
Matricular
Figura 4-3: Ejemplo de un caso de uso
A continuación se presentan algunas preguntas útiles para encontrar casos de uso en un

sistema de software:
¿Qué tareas realiza el actor?

¿El actor crea, almacena, cambia, elimina o lee información del sistema?
¿Qué casos de uso crearán, almacenarán, cambiarán, leerán esta información?
¿El actor necesita informarle al sistema sobre cambios externos?
¿El actor necesita ser informado acerca de ocurrencias en el sistema?
¿Qué casos de uso darán soporte y mantenimiento al sistema?
El origen de la información para los casos de uso se encuentra en:
Especificación del sistema

Literatura correspondiente al dominio
Entrevistas con los expertos del dominio
Conocimiento personal del dominio
Sistemas anteriores
Ejemplo: Sistema Académico
Al comenzar cada semestre, los estudiantes requieren un catálogo que contiene la lista de
los cursos ofrecidos para cada semestre. La información de cada curso, como el profesor,
facultad y prerequisitos serán incluidos para ayudar a los estudiantes en la toma de
decisiones. El nuevo sistema le permitirá a los estudiantes seleccionar cuatro cursos para
el semestre entrante. Además, cada estudiante indicará dos alternativas en caso de que
un curso ofrecido se llene o sea cancelado. Ningún curso ofrecido tendrá más de 10
estudiantes, ni menos de 3 estudiantes. Un curso con menos de 3 estudiantes será
cancelado. Una vez el proceso de matrícula es completado por el estudiante, el sistema
de matrícula envía la información al sistema financiero.
Los profesores deben acceder el sistema en línea para indicar cuál curso enseñará.
También necesitan conocer cuáles estudiantes están matriculados para su curso.
Para cada semestre, existe un periodo de tiempo en el cual el estudiante puede cambiar
su horario. Los estudiantes accederán el sistema durante este tiempo y añadir y cancelar
cursos.
Actores
Estudiantes
Profesores
Sistema Financiero
Administrador Sistema
Casos de Uso
Estudiantes
Matricular
Profesores
Seleccionar cursos a enseñar
Requerir lista del curso
Administrador Sistema
Mantener información del curso
Mantener información del estudiante
Mantener información profesor
Generar catálogo
4.1.1.3. Relaciones de los Casos de Uso
En los casos de uso pueden participar cuatro tipos de relaciones: asociación,

generalización, inclusión y extensión. Cada relación tiene su propósito y notación.
Relación Propósito Notación

Asociación Denota una relación entre un actor y un
caso de uso
Generalización Denota herencia entre casos de uso
Inclusión Incluye la funcionalidad de uno caso de uso

<<include>
en otro >
Extensión Extiende la funcionalidad de un caso de uso <<extend>
a otro bajo ciertas condiciones >
Figura 4-4: Diagrama de Casos de Uso Sistema Académico
4.1.2. Escenarios de Casos de Uso
Un caso de uso describe una función fundamental del sistema desde la perspectiva del
usuario. Sin embargo, existe más de una forma para terminar una función dada. Un
escenario es una instancia de un caso de uso, esto es, un camino lógico del inicio al final
del mismo; es un ejemplo concreto de un caso de uso.
Los escenarios no contienen elementos condicionales porque describen uno de los
posibles caminos de un caso de uso. Por lo tanto, nunca se debe encontrar un “if” en un
escenario. Por ejemplo, no es posible tener un escenario con la siguiente oración “si el
cliente requiere una habitación doble, le pregunta si tiene más huéspedes”. Si esto se va a
presentar, entonces es necesario crear múltiples escenarios que cubran cada caso del “if”.
Todos los escenarios comienzan de la misma manera, sin embargo, cada uno de ellos
termina diferente.
No es necesario realizar todos los escenarios, pero si los principales. Es posible dejar de
definir escenarios cuando se haya descubierto el comportamiento del sistema. Existen
dos tipos de escenarios; los primarios que son aquellos que obtienen resultados exitosos
y los secundarios que obtienen eventos de fallas.
Los escenarios se utilizan para crear los diagramas de actividades, el plan de pruebas y
los diagramas de objetos.
Escenario para el caso de uso Matricular
Juan ingresa su identificación 91558899 la cual el sistema valida. De un catálogo de

cursos disponibles, Juan selecciona como cursos principales Inglés, Geología, Historia y
Álgebra. También selecciona Música y Java como materias alternativas.
El sistema determina que Juan cumple con los pre-requisitos necesarios y lo agrega a la
lista de estudiantes de ese curso. El sistema indica que la actividad se ha completado,
imprime el horario del estudiante y le envía la información correspondiente al sistema
financiero.
Escenarios secundarios
Estudiante no selecciona 4 cursos primarios

El curso primario no está disponible
Los cursos primarios y secundarios no están disponibles
No puede agregar el estudiante al curso
No puede crear el horario del estudiante
Ejercicio de trabajo durante el curso
Definir el la especificación de requerimientos funcionales, no funcionales y el diagrama de

casos de uso para el siguiente enunciado.
Una compañía requiere un sistema de nómina. Ellos necesitan que el sistema opere en
sus dos sucursales, cada una de ellas tiene diferente moneda, impuestos y políticas de
nómina. El pago es calculado mensualmente y semanalmente dependiendo del tipo del
pago del empleado. Actualmente los tipos de pago son, mensuales, semanales y por
horas.
Los empleados pagados mensualmente tienen un salario anual dividido en doce
cantidades iguales, las cuales corresponden a los pagos de cada mes. Los empleados
pagados semanalmente, son pagados con una tarifa semanal al final de la semana. Los
empleados pagados por hora tienen una tarifa por horas. Las horas trabajadas por estos
empleados están determinadas por el tiempo de entrada y el tiempo de salida
almacenado en un sistema de tiempo. Las horas extras son pagadas según las tarifas
aplicadas en la sucursal correspondiente.
La mayoría de los empleados son pagados por hora. La información del tiempo de trabajo
para estos empleados puede ser descargada directamente del sistema. Esto debe
hacerse cada 24 horas. Los empleados se identifican con sus nombres y el número de
identificación.
Los empleados pagados por hora y semanalmente, pueden elegir si desean el pago en
efectivo o en cheque. A los empleados mensuales sólo se les paga en cheque. Todos los
pagos se hacen en la moneda local aplicable a la sucursal correspondiente.
Los pagos son calculados aplicando los impuestos correspondientes según la sucursal.
Los impuestos son acumulados para el año financiero.
Los impuestos de pensión y de seguridad son descontados sobre el salario base y

proporcional a cada uno. Los impuestos de salud y de contaminación son descontados del
salario base y son tarifas fijas. Existen otros conceptos opcionales para descuento como
el seguro de salud. Las pensiones se descuentan a todos los empleados y tienen un
porcentaje fijo.
Las tasas de pago y los detalles de los empleados sólo pueden ser almacenados y
modificados a través de Recursos Humanos. Semanalmente y mensualmente se corre la
opción correspondiente por la persona encargada y se generan los pagos de nómina.
Esto produce una lista resumen de los pagos y descuentos realizados a cada empleado.
Este resumen presenta el total de descuentos generado por todos los empleados. Al final
del año, la persona encargada de esta labor, requiere un resumen de pagos de impuestos
para todos los empleados durante el año.
Impuestos Sucursal 1: Pensión, Contaminación y Seguridad.

Impuestos Sucursal 2: Pensión y Salud.
4.2. ANÁLISIS DE REQUERIMIENTOS
2003. Revision C.
* CRC = Class Responsability Collaborator
Figura 4-5: Mapa del proceso Análisis de Requerimientos
El análisis se refiere a la capacidad de extraer datos más detallados de la captura de

requerimientos. Para ello es necesario crear una descripción detallada de los casos de
uso y refinar el diagrama.
4.2.1. Descripción del caso de uso
La descripción del caso de uso contiene los siguientes ítems:
Código y nombre del caso de uso

Descripción
Actores
Prioridad (alta, media, baja)
Riesgo (alto, medio, bajo). Los casos de uso de alto riesgo deben desarrollarse en
las primeras iteraciones. Los riesgos se pueden encontrar en las siguientes áreas;
Riesgos de requerimientos; Riesgos tecnológicos, Riesgos de capacidades,
Riesgos de recursos, Riesgos de políticas
Precondiciones (desde el punto de vista del funcionamiento del caso de uso con el
usuario)
Flujo de eventos
Flujos alternos (desde el punto de vista del funcionamiento del caso de uso con el
usuario)
Poscondiciones
Requerimientos no funcionales
La descripción de los flujos de eventos sigue la estrategia de relevamiento como se

presenta en la siguiente figura:
Funcionalidad Errores
deseada
Excepciones
Camino
o flujo
básico
Funcionalidad
no deseada
Figura 4-6: Esquema de relevamiento de la descripción de los flujos de eventos
Para la descripción de cada uno de los pasos de los flujos de eventos, se recomienda
utilizar la técnica del scripting como se describe a continuación:
Rol: quien tiene la responsabilidad de llevar a cabo el comportamiento del sistema (actor)
Responsabilidad: cada comportamiento desarrollado por un rol
Dos tipos de actores: iniciador y participante
Dos tipos de responsabilidades: acción y servicio
Una colaboración: entre ambos roles
Descripción del caso de uso Matricular
Este caso de uso es iniciado por un estudiante y provee la posibilidad para que el
estudiante cree, elimine, modifique y revise la información de un horario de para un
semestre dado.
Precondiciones: Se muestra la pantalla principal de inclusión de cursos.
Flujo de Eventos – Matricular
Este caso de uso comienza cuando el estudiante digita su identificador. El sistema

verifica que este identificador sea válido, y le permite al estudiante seleccionar el
semestre actual o uno posterior.
El estudiante selecciona el semestre deseado. El sistema le presenta al estudiante las
siguientes actividades a realizar:
Crear horario
Revisar horario
Cambiar horario
Eliminar un curso
Agregar un curso
El estudiante indica que la actividad es finalizada. El sistema imprime el horario del
estudiante y notifica que su matrícula está terminada. El sistema le envía la información
al sistema financiero para su procesamiento.
Flujo alterno
Si el identificador es inválido, el sistema no le permite el acceso al sistema de
matrícula.
Si el estudiante intenta crear un horario para un semestre donde ya está
matriculado, el sistema solicita que elija otro semestre.
Crear un horario
El estudiante ingresa los 4 cursos primarios, selecciona los 2 cursos alternativos y el
sistema valida:
Verifica que los prerequisitos estén satisfechos para el curso requerido
Agrega el estudiante al curso, si éste está abierto.
Flujo alterno
Si el curso primario no está disponible, el sistema lo sustituye con un curso
alterno.
Flujo alterno
Si el estudiante no cumple con los prerrequisitos necesarios, el sistema le
presenta el mensaje al usuario y no lo matricula en el curso correspondiente.
Revisar un horario
El estudiante requiere la información de todos los cursos ofrecidos en los cuales
está matriculado para un semestre dado. El sistema muestra todos los cursos
solicitados, incluyendo el nombre del curso, número, días de la semana, tiempo,
ubicación, créditos.
Cambiar horario
Eliminar un curso
El estudiante indica cual curso va a eliminar. El sistema verifica que la fecha final
para los cambios no haya sido excedida. El sistema elimina al estudiante de los
cursos seleccionados. El sistema notifica que la solicitud ha sido tenida en
cuenta.
Agregar un curso
El estudiante indica cuál curso desea agregar. El sistema verifica que la fecha
final para cambios no haya sido excedida. El sistema:
Verifica que el máximo número de estudiantes del curso no sea excedido.
Verifica los prerequisitos
Agrega el estudiante en el curso
Poscondiciones: La información se almacena en la base de datos. Se cierra la ventana de

matrículas y se presenta la pantalla principal.
4.2.2. Refinación del diagrama de casos de uso
Algunos casos de uso definidos en la captura de requerimientos están en un nivel muy

superior, como por ejemplo información del curso. En este caso, es necesario introducir
nuevos casos de uso que separen las actividades involucradas en él. Por ejemplo, un
caso de uso para crear un nuevo curso, otro para consultar un curso, otro para modificar
un curso y otro para eliminar un curso.
Figura 4-7: Refinación caso de uso mantenimiento de la información de cursos

Otra forma de hacer refinamiento del diagrama de casos de uso es a través de la
identificación de herencia entre actores y casos de uso. Para ello:
Un actor puede heredar todos las asociaciones de los casos de uso de su actor
padre
Un caso de uso puede ser dividido en casos de uso especializados. Estos casos
de uso usualmente se identifican por variaciones en los escenarios. Por ejemplo
en las búsquedas de información por diferentes parámetros.
Finalmente, es necesario refinar las relaciones entre todos los casos de uso identificados
a través de las relaciones inclusión y extensión. Para ello se debe tener en cuenta:
Un caso de uso a incluye a un caso de uso b, si el caso de uso a requiere la

funcionalidad de otro caso de uso b y siempre ejecuta el caso de uso incluido.
Un caso de uso a extiende un caso de uso b, si el caso de uso a puede usar la
funcionalidad de otro caso b, por lo tanto, el caso de uso a se extiende al caso de
uso b. La extensión permite identificar comportamientos del sistema que no son
parte de flujos primarios, sino que existe en escenarios alternos.
Figura 4-8: Refinación caso de uso Matricular
Otro ejemplo de diagrama de caso de uso se presenta a continuación y se refiere a los

requerimientos funcionales de una tienda virtual.
Figura 4-9. Diagrama de casos de uso de una tienda virtual
4.2.3. Casos de Prueba
A partir de la descripción de los casos de uso, se definen los casos de prueba, con el fin
de utilizarlos al final de cada iteración y verificar la funcionalidad del sistema.
Caso Ingresa Ingresa Cumple con Hay cupo Resultado

de 4 cursos dos cursos prerrequisitos
prueba primarios alternos
FB 1 SI SI SI SI Estudiante matriculado
en los cursos primarios
seleccionados.
FB + FA1 2 SI SI SI NO Estudiante matriculado
en los cursos primarios y
alternos especificados.
FB + FA2 3 SI SI NO SI Estudiante matriculado
solo en los cursos en los
cuales tiene completos
los prerrequisitos.
FB= flujo básico

FA1= flujo alterno 1
Ejercicio: Realizar el diagrama de casos de uso y la descripción de uno de ellos

para el Sistema de Nómina.
4.2.4. Diagramas de Actividades
Después de crear los casos de uso, se pueden realizar los diagramas de actividades para
presentar gráficamente las actividades o flujos de eventos dentro de los casos de uso. El
diagrama de actividades puede extender la descripción de los casos de uso. Son similares
a un diagrama de flujo que describe el orden de las actividades de un proceso. Se debe
realizar un diagrama de actividades por cada caso de uso.
Los diagramas de actividades incluyen los siguientes elementos:
Actividades
Decisiones
División de control
Unión de control
Iteración
Flujo de objetos
Actividad Bifurcación
Flujo Unión
Inicio
Subdivisión
Fin
Separador Unión
Figura 4-10: Notación del Diagrama de Actividades
Selecciona
Matricular
Consultar Horario Crear Horario Modificar Horario
Agregar Cursos
Consulta Selecciona
Cursos Cursos
Eliminar Cursos
Elimina
Cursos
Curso Abierto
Actualiza
Matrícula
Figura 4-11: Diagrama de Actividades Caso de Uso Matricular – Sistema Académico

Un diagrama de actividades puede considerarse como un caso especial de un diagrama
de estados en el cual casi todos los estados son estados acción (identifican una acción
que se ejecuta al estar en él) y casi todas las transiciones evolucionan al término de dicha
acción (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a
un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones
internas al margen de las transiciones o eventos externos. En la figura siguiente se
presenta un ejemplo de diagrama de actividades para un mensaje de un objeto.
Figura 4-12: Ejemplo de un Diagrama de Actividades de una máquina dispensadora de

bebidas
La interpretación de un diagrama de actividades depende de la perspectiva considerada:

en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un
diagrama de especificación o de implementación, la actividad es un método de una clase.
Generalmente se suelen utilizar para modelar los pasos de un algoritmo.
Un estado de acción representa un estado con acción interna, con por lo menos una
transición que identifica la culminación de la acción (por medio de un evento implícito). No
deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este
el caso, se representaría con un diagrama de estados. Los estados de acción se
representan por un rectángulo con bordes redondeados, y permiten modelar un paso
dentro de un algoritmo.
Las flechas dirigidas entre estados de acción representan transiciones con evento
implícito que, en el caso de decisiones, pueden tener una condición o guarda asociada
(que al igual que en los diagramas de estado evalúa a true o a false).
Las decisiones se representan mediante una transición múltiple que sale de un estado y
donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual
llega la transición del estado origen y del cual salen las múltiples transiciones de los
estados destino. Un ejemplo se muestra en la figura 5.7 cuando no hay café y se toma
una decisión entre hay cola o no hay cola.
En un diagrama de actividades también pueden existir barras de sincronización

(synchronization bar), como la que sigue a [found cofee] en la figura anterior, a las que se
encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una
actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realizándose dichas
actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas
actividades es irrelevante, siendo válido cualquier orden entre ellas.
Dado que el diagrama de actividades permite expresar el orden en que se realizan las
cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de
programas concurrentes (permiten representa gráficamente los hilos de ejecución).
Como la mayoría de las técnicas de modelado de comportamiento, los diagramas de

actividades tienen sus puntos fuertes y sus puntos débiles, de forma que es necesario
utilizarlos en combinación con otras técnicas. Su principal aportación al modelado del
comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado
para el modelado de flujo de trabajo (workflow) y programación multihilo (multi-thread).
Por contra, su principal desventaja es que no muestran de una forma clara los enlaces
existentes entre las acciones y los objetos, siendo mucho más apropiado para ello los
diagramas de interacción.
En general resulta adecuado utilizar diagramas de actividades para:
Análisis de casos de uso: Durante el análisis de los casos de uso no estamos

interesados en asociar acciones a objetos, sino en entender qué acciones se
necesitan llevar a cabo y cuales son las dependencias en el comportamiento.
Comprensión del flujo de trabajo a lo largo de diferentes casos de uso.
Modelado de aplicaciones multihilo.
Por contra, resultan en general del todo inadecuados a la hora de mostrar la colaboración
entre objetos y la evolución del comportamiento de los objetos durante su tiempo de vida.
4.2.5. Abstracciones principales
El modelo de análisis provee más detalles de cada caso de uso, escrito en el lenguaje del
desarrollador; este modelo es una vista interna del sistema. La fase análisis identifica los
objetos requeridos por el problema para asegurar la funcionalidad del sistema y sigue el
siguiente proceso:
Definir qué debe hacer el sistema, esto es, la funcionalidad del mismo.
Identificar los candidatos a objetos y clases, analizando sus relaciones y
responsabilidades
Actualizar el diccionario de datos o glosario de términos. Todos los términos
nuevos identificados durante la fase de análisis, se deben incluir en el diccionario
de datos
En general, el modelo de análisis provee una transición entre la captura de requerimientos

y el diseño. El proceso de análisis sirva para modificar y finalizar requerimientos.
4.2.6. Clases y Objetos
Una clase es la plantilla para un objeto, es decir, una clase define un objeto. El siguiente
ejemplo de galletas ilustra el concepto. Considere la memoria dentro de un computador
como si fuera una masa para hacer galletas. Cuando se inicia, la masa no tiene
características. Cada parte luce exactamente como la otra.
Es posible utilizar un molde para crear las galletas deseadas. Sólo se posee un molde,
pero puede utilizarse para crear tantas galletas como las deseadas hasta utilizar toda la
cantidad de masa disponible. Todas las galletas son iguales después de cortadas. Cada
una de ellas puede ser única agregando diferentes caras y botones con colores y
decoraciones y todas tendrán características individuales. El molde es similar a una clase
en términos de programación orientada a objetos. Es posible definir una clase por cada
tipo de objeto que se necesita. Las clases se crean antes de que el programa se ejecute.
La galleta en forma de hombre y con sabor a ginebra es similar a un objeto en términos de

programación orientada a objetos. Son creados en tiempo de ejecución utilizando una de
las clases previamente definidas.
En la programación estructurada, las funciones son los componentes fundamentales de

una aplicación. Debido a que todos los datos y métodos están asociados con objetos,
éstos son los componentes fundamentales de un programa orientado a objetos. Aprender
a identificar objetos potenciales es un paso importante para entender el análisis y diseño
orientado a objetos.
Todos los objetos representan un sustantivo. El objeto más simple es un ítem tangible
como una persona, un orden de compra o un reporte. Los objetos también pueden
representar sustantivos intangibles como conceptos. Un objeto puede ser:
Una cosa: Un objeto puede representar un ítem tangible que existe dentro del
mundo real como una parte de un automóvil, un cliente o un elemento de una
interfaz gráfica como un botón.
Un evento: Un objeto puede representar un suceso como la fecha de entrega,
una llamada telefónica o la activación de un elemento dentro de una interfaz
gráfica.
Un proceso: Un objeto puede representar un proceso, como colocar una orden
o la interacción con una base de datos.
Un objeto puede ser simple o complejo, real o imaginario y puede tener atributos y
operaciones. Por ejemplo, si e objetos es un nube, los atributos pueden ser forma,
tamaño, contenido de agua. Un ejemplo de las operaciones puede ser llover, nevar o
tronar.
Cuando se intenta asignar operaciones a un objeto, las operaciones ejecutadas sobre el

objeto son asignadas al objeto mismo. Por ejemplo, si se tiene una cuenta bancaria como
un objeto, las operaciones de la cuenta podrían ser abrir la cuenta, cerrar la cuenta, y así
sucesivamente.
Un objeto es un concepto dinámico. En cualquier momento, un sistema involucra un

conjunto de objetos que contienen información e invocan funcionalidades entre si.
Identificación de los objetos del Sistema Académico
Para encontrar, se examinan los sustantivos de los casos de uso y los escenarios. Por lo
tanto, los sustantivos del escenario de matrícula:
Juan
Sistema
Horario
Cursos primarios
Geología
Algebra
Música
Pre-requisitos
Objetos candidatos
Juan (actor)
Sistema (lo que va a ser construido)
Horario (candidato a objeto)
Cursos primarios (estado de un curso)
Geología (candidato a objeto)
Algebra (candidato a objeto)
Música (candidato a objeto)
Pre-requisitos (candidato a objeto)
Ejercicio: Identificar los posibles objetos del Sistema de Nómina.
4.2.7. Diagramas de Clases
Un diagrama de clase es una notación gráfica utilizada para representar un conjunto de

objetos que comparten atributos y características comunes. Un diagrama de clase
consiste de uno o más rectángulos con una sección para el nombre de la clase, otra
parar los atributos y otra para las operaciones.
Profesor
nombre
Id
crear()
guardar()
eliminar()
cambiar()
Figura 4-13: Notación de clases en UML
Los diagramas de clases son utilizados para ilustrar las relaciones entre clases y son el
fundamento para el proceso de diseño. Las clases participan principalmente en cuatro
relaciones:
Asociación
Agregación
Composición
Generalización
4.2.7.1. Asociación
Una asociación ilustra una relación “utiliza un” entre las instancias de una clase. Una
asociación provee un camino de comunicación entre objetos. Esta relación está
representada por una línea entre dos clases.
Departamento Profesor
Figura 4-14: Ejemplo de una relación de asociación
Las asociaciones deben tener una dirección la cual indica la navegabilidad de la misma.
4.2.7.2. Multiplicidad
La multiplicidad es utilizada para denotar el número de instancias de una clase

involucradas en una relación.
Profesor 1 o..* Curso
Figura 4-15: Ejemplo de una relación de asociación con multiplicidad
Existen asociaciones reflexivas en donde los objetos de la misma clase están

relacionados.
Una materia puede tener
uno o varias materias
Materia 0..*
prerrequisitos y una materia
puede ser prerrequisito de
una o varias materias
Pre-requisitos 0..*
Figura 4-16: Ejemplo de una relación de asociación reflexiva
4.2.7.3. Agregación
La agregación es utilizada para mostrar que una clase es parte de otra. La relación se
denota utilizando un diamante y una línea entre las clases. El diamante del lado de la
clase Catálogo, indica que el “es parte de” la clase Catálogo.
Catálogo 1..* Curso
Figura 4-17: Ejemplo de una relación de agregación
4.2.7.4. Composición
La composición es el segundo tipo de una relación “es parte de” entre clases y es más
fuerte que la agregación, con la expresión “está compuesto por”. Esta relación es más
fuerte, porque las partes nacen y mueren con el todo. Está representada por un diamante
relleno y una línea entre las clases. El diamante relleno indica que el pensum “está
compuesto por” materias.
Pensum 1..* Materia
Figura 4-18: Ejemplo de una relación de composición
Un ejemplo de todas de un diagrama de clases con sus diferentes conceptos, se presenta

en la siguiente figura.
Persona
- atributo:
clase
+ operaci on() : voi d
nota
generalización
Vendedor Origen
Cliente
1..1 1..1
1..1
provi ene de
soli ci ta
0..* 0..*
atiende
Pedido
i ncl uye
Producto
navegabilidad
asociación 0..* 0..* 1..*
ItemPedido
clase asociación multiplicida
d
Figura 4-19: Conceptos involucrados en un diagrama de clases
4.2.7.5. Clase Asociación
Una clase asociación corresponde a asociación que se modela como clase o viceversa.
Es importante tener presente que la multiplicidad entre la clase y la asociación es 1..1.
Factura Artículo
0..* 1..*
ItemFacturado
Figura 4-20: Ejemplo 1 de una clase asociación
4.2.7.8. Dependencia
Una relación de dependencia significa que una clase es dependiente de otra por algún
servicio. Una relación de dependencia se indica si las operaciones de la clase cliente
crean objetos de la clase proveedora y si las operaciones de la clase cliente pasan
argumentos a las instancias de la clase proveedora.
4.2.7.9. Herencia
La herencia describe cómo es posible compartir atributos y funcionalidad entre clases de

naturaleza o propósitos similares. La herencia o generalización es una relación de “es un”.
Cuando una clase hereda de otra, esta es llamada subclase y la clase de la cual heredó,
es llamado superclase.
Existen dos tipos de herencia, la herencia simple la cual es la más común, y la herencia
múltiple. Esta última no es permitida por todos los lenguajes orientados a objetos, C++ lo
permite, pero Java no lo permite. Cuando se decida utilizar herencia múltiple, es
necesario considerar su relevancia dentro del sistema.
Una subclase hereda de su padre atributos, operaciones y relaciones. Una subclase

puede agregar atributos, operaciones y relaciones adicionales y redefinir las operaciones
heredadas.
Existen dos formas para añadir el concepto de herencia en un modelo, Generalización y

Especialización.
4.2.7.10. Generalización
Provee la capacidad de crear superclases que encapsulan la estructura y/o

comportamiento común de varias subclases. El procedimiento de generalización es
identificar las estructuras/comportamientos similares entre clases.
4.2.7.11. Especialización
Provee la capacidad de crear subclases que representan el refinamiento en el cual la

estructura y/o comportamiento de una superclase es añadido o modificado. El
procedimiento de especialización es identificar que algunas instancias de la superclase
exhiben comportamiento especializado.
4.2.8. Modelo del dominio
El modelo del dominio es una de las vistas del modelo de requerimientos, las otras
corresponden a los requerimientos textuales del documento SRS y el modelo de casos de
uso. Las clases en el modelo del dominio son las abstracciones principales del sistema y
el modelo se representa como un diagrama de clases con las abstracciones identificadas
durante el análisis.
Figura 4-21: Diagrama de clases del modelo del dominio
Una técnica para validar el modelo del dominio con el problema es construir el diagrama
de objetos desde los escenarios de los casos de uso y verificar si el diagrama de objetos
se ajusta con el diagrama de clases.
Ejercicio: Hacer el modelo del dominio para el sistema de nómina.

4.2.9. Diagrama de objetos
El diagrama de objetos es una instancia de un diagrama de clases y presenta los detalles

de un estado del sistema en un punto del tiempo determinado. En UML el diagrama de
objetos representa los objetos y sus relaciones en tiempo de ejecución.
Para validar el modelo del dominio es necesario ejecutar los siguientes pasos:
1. Elegir uno o más casos de uso que estén altamente relacionados con el modelo
del dominio.
2. Elegir uno o más escenarios de los casos de uso seleccionados en el punto
anterior. Es recomendable elegir escenarios que exploren diferentes situaciones.
3. Ir a través de cada escenario en forma separada, y construir los objetos con los
datos mencionados en el escenario.
4. Comparar cada diagrama de objetos con el modelo del dominio para analizar si se
han violado algunas restricciones.
Creando el diagrama de objetos desde el escenario: Juan ingresa su identificación

91558899 la cual el sistema valida.
Figura 4-22: Diagrama de objetos escenario de matricula paso 1
De un catálogo de cursos disponibles, Juan selecciona como cursos principales Inglés,

Geología, Historia y Álgebra. También selecciona Música y Java como materias
alternativas.

El sistema determina que Juan cumple con los pre-requisitos necesarios, lo agrega a la
lista de estudiantes de ese curso, imprime el horario del estudiante y le envía la
información correspondiente al sistema financiero
4.3. DISEÑO
2003. Revision C.
Figura 4-25: Mapa del proceso Diseño

El modelo de diseño es creado desde los requerimientos funcionales y describe los tipos
de componentes requeridos para ejecutar el caso de uso. El modelo de diseño se integra
con el modelo arquitectónico para producir la solución al modelo.
Ivar Jacobson identificó tres tipos principales de clases en un sistema orientado a objetos:
entidad, interfaz y control.
4.3.1. Clases Entidad
Las clases entidad, modelan el mundo real. Todos los objetos estudiados hasta el
momento son de entidad. El proceso de análisis comienza identificando las entidades de
información del negocio, como diferentes tipos de reportes, información de clientes, de
inventario, entre otras. La mayoría de esta información puede ser trasladada directamente
a clases entidad.
4.3.2. Clases Interfaz
Las clases interfaz son el puente entre el sistema y los usuarios. Los objetos que forman
una interfaz gráfica de usuario son ejemplos de clases interfaz. Estas clases
frecuentemente hacen parte de una ventana, o un objeto impresora. En análisis, cada
clase de tipo interfaz mantiene una relación con al menos un actor.
4.3.3. Clases de Control
Las clases de control implementan la lógica del negocio que no puede ser fácilmente
implementada en una clase entidad o interfaz. Las clases de control representan
conceptos utilizados para mantener el sistema unido.
Cada clase tiene su propia notación.
Clase entidad Clase interfaz Clase control
Figura 4-26: Estereotipos de clases en UML
4.3.4. Interacción entre Objetos
Una vez se han identificado los objetos es necesario modelar cómo éstos interactúan
dentro del sistema, para ello se utilizan los diagramas de secuencia y colaboración.
Los Diagramas de Secuencia presentan gráficamente los objetos que toman parte en un
escenario particular y muestra sus interacciones a través del tiempo. En análisis se debe
producir al menos un diagrama de secuencia por cada escenario, o por lo menos un
diagrama de secuencia por cada flujo básico de cada caso de uso.
Los pasos para elaborar este tipo de diagramas son:
1. Seleccione un caso de uso

2. Coloque el actor en el diagrama
3. Identifique las clases de interfaz
4. Identifique las clases de control
5. Identifique las clases de entidad
Figura 4-27: Diagrama de Secuencia –Caso de Uso Matricular
Los objetos son dibujados como rectángulos con los nombres subrayados, las líneas de
vida son representadas por líneas punteadas y la interacción se indica por una línea
horizontal entre objetos.
Los diagramas de colaboración son una alternativa de los diagrama de secuencia y

describe las relaciones entre objetos.
Figura 4-28: Diagrama de Colaboración –Caso de Uso Matricular
Ejercicio: Hacer el diagrama de secuencia para el caso de uso definido en clase.
4.3.5. Refinando el modelo de dominio
Una clase debe tener atributos y métodos asignados, los cuales le permiten conocer sus
responsabilidades. Los atributos le permiten a una clase almacenar información
relacionada con una tarea en particular. Los métodos u operaciones, son funciones que
manipulan los valores de los atributos. Las operaciones deben ser nombradas desde la
perspectiva del proveedor de la operación, no desde el cliente. Los nombres de los
métodos y atributos deben ser únicos dentro de una clase. Se pueden obtener de la
información filtrada de los casos de uso y escenarios.
Figura 4-29: Atributos y operaciones de la clase curso
Existen algunas convenciones recomendables, los atributos y operaciones deben

comenzar con una letra minúscula, no se deben utilizar guiones, los nombres compuestos
por varias palabras se unen con las primeras letras de cada palabra en mayúscula.
Durante la fase de diseño, todos los atributos deberían ser privados y sólo ser visibles a
otras clases a través de los métodos públicos, de esta manera se refleja la encapsulación,
una de las principales características de la programación orientada a objetos.
Cada atributo se debe definir en términos de:
Tipo de dato
Valor por defecto (si aplica)
Restricciones (si aplica)
Cada clase pueden tener métodos, existen diferentes tipos pueden ayudar a encontrar
métodos:
Métodos de acceso: para acceder atributos privados, por ejemplo, los métodos get
y set
Métodos de administración: como los constructores y destructores de C++,
consultas, cálculos, comparaciones, entre otros.
4.3.6. Paquetes
Es una forma de agrupar ítems. Se pueden utilizar para agrupar clases, componentes de
software, de hardware, otros paquetes y cualquier producto relevante dentro del modelo.
La notación de UML es similar al icono de carpeta de windows.
En las primeras fases del desarrollo del sistema es posible utilizar los paquetes para los
siguientes objetivos:
Tener una vista del sistema sin mucho detalle

Tener vistas de pequeñas porciones del sistema
Crear pequeñas porciones del sistema que pueden trabajar independientemente
En un nivel superior se identifican tres paquetes: Interfaces, Reglas del Negocio y Entidad
y los diagramas de clase se presentan organizados por paquetes.
Existe una dependencia entre paquetes cuando por lo menos una clase de un paquete
depende de una clase dentro de un segundo paquete. Esta relación se representa con
una línea punteada. Cuando existe dependencia cíclica entre paquetes, es recomendable
dividir los paquetes por funcionalidad, para romper estas dependencias cíclicas.
C D = A B
La clase C pertenece al paquete A, la clase D pertenece al paquete B. Si existe una

relación de asociación entre estas clases, existe una relación de dependencia entre
paquetes. En este caso, se construye primero el paquete B, porque A depende de B.
C D = A B

relación de agregación entre estas clases, existe una relación de dependencia entre
paquetes. En este caso, se construye primero el paquete B, porque A depende de B.
C D = A B

relación de herencia entre estas clases, existe una relación de dependencia entre
paquetes. En este caso, se construye primero el paquete A, porque B depende de A.
Figura 4-30: Relaciones entre paquetes
Figura 4-31: Relaciones entre los paquetes identificados del sistema académico
4.3.7. Diagrama de clases de diseño
Las nuevas clases identificadas en los diagramas de secuencia se deben representar y

relacionar en un nuevo diagrama de clases.
Figura 4-32: Diagrama de clases de diseño

Ejercicio: Identificar paquetes y realizar el diagrama de clases de diseño del
Sistema de Nómina, teniendo en cuenta los diferentes tipos de relaciones vistas
anteriormente.
4.3.7. Arquitectura del sistema
2003. Revision C.
Figura 4-33: Mapa del proceso Arquitectura
Los arquitectos del sistema se encargan de hacer cumplir los requerimientos no

funcionales como:
o Para manejo de errores: Los objetos deberían detectar errores que puedan violar
su integridad y se debe tener en cuenta que los errores pueden ser resultado de
superar sus operaciones, resultado de los parámetros recibidos por un cliente,
resultado de los valores retornados por un proveedor. Es importante tener un plan
para monitorear la “salud” del sistema.
o Para la comunicación entre procesos: Suponer que la Clase A llama a la Clase B,

¿qué pasa si la clase A y la B están en diferentes procesos?. Esto llega a ser un
hecho crítico en sistemas distribuidos, por lo tanto, es necesario definir
mecanismos estándares para el manejo de esta comunicación.
o Almacenamiento de datos: Las bases de datos relacionales son herramientas

poderosas para este objetivo. Sin embargo, el modelo relacional, difiere del
modelo de objetos y es conveniente separarlos con los objetos persistentes.
Un objeto persistente es un objeto que existe lógicamente y va más allá del

programa que lo crea. En los lenguajes orientados a objetos, éstos existen sólo en
memoria. Un objeto persistente tiene la habilidad de almacenar el valor de sus
atributos.
El almacenamiento puede hacerse utilizando simples archivos o sistemas
administradores de bases de datos. Existen diferentes modelos para DBMS:
Jerárquico
Relacional
Orientada a Objetos
Según el modelo existen consideraciones a tener en cuenta:

Se deben adicionar métodos para almacenar y recuperar estos objetos
Se deben adicionar atributos para manejar los detalles del almacenamiento
Se deben adicionar clases que sirvan de interfaz con el DBMS
Si se eligen bases de datos relaciones existen diferentes estrategias para las

superclases y las subclases como Repetir todos los atributos en la tabla
superclase, problema: desperdicio de espacio; o repetir todos los atributos en las
tablas subclase, problema: redundancia. Rendimiento vs Almacenamiento son
criterios involucrados en las situaciones de herencia.
Persona
Nombre
Telefono
Em pleado Cliente
FechaInicio Ide nti fica cio nCliente
Preferencias
Figura 4-34: Ejemplo de una relación de herencia
Persona
ID (PK)
Nombre
Teléfono
FechaInicio
NumeroCliente
Preferencias
TipoDeObjeto
Figura 4-35: Mapeo de herencia. Una tabla para la jerarquía de la clase persona
Figura 4-36: Mapeo de herencia. Una tabla por clase concreta
Persona
ID (PK)
Nombre
Teléfono
TipoDeObjeto
Es un Es un
Empleado Cliente
ID (FK) ID (FK)
FechaInicio NumeroCliente
Preferencias
Figura 4-37: Mapeo de herencia. Una tabla por clase
A continuación se presenta un cuadro comparativo de los métodos de mapeo presentados

anteriormente:
Factores a Considerar Una tabla para la jerarquía Una tabla por Una tabla por
entera de una clase clase concreta clase
Facilidad de Implementación Simple Media Difícil
Facilidad de Acceso de datos Simple Simple Simple/Media
Dependencia de las clases Muy Alta Alta Baja

Velocidad de Acceso de Datos Rápido Rápido Media/Rápido
Soporte a Polimorfismo Media Baja Alta
Normalización Ninguna Media Total
Necesidad de Espacio en la Alta Media Alta
BD
El mayor cuestionamiento asociado con la interfaz con un RDBMS es si se debe
separar el comportamiento de la aplicación del comportamiento de la base de
datos.
Suponer que la clase Cliente se ha decidido volver persistente:

¿Debería la clase cliente contener los detalles de pasar de OO a RDMSB?
¿Debería la clase cliente contener el comportamiento para interactuar con
un agente RDBMS?
¿Debería la clase cliente también saber que es persistente?
Cualquier modelo trabajaría, sólo que cada uno tiene sus ventajas y desventajas.
El primer modelo cada clase persistente puede tener crear, leer, actualizar y
borrar.
Ventajas:
Ninguna implementación técnicamente complicada
Desventajas:
OO y RDBMS no están separados
Funcionalidad CRUD no siempre es heredada transparentemente
Si el comportamiento de la aplicación se separa del comportamiento de la base de

datos, el sistema puede ser modelado en dos partes: Aplicación e Interfaz de Base
de Datos. Para cada clase persistente, es necesario definir una interfaz para la
base de datos que entienda la relación de OO a RDBMS.
Carga de trabajo del sistema

Dispositivos físicos
4.3.8. Tipos de arquitectura
La arquitectura depende de los siguientes factores:
o Las restricciones de la plataforma en los requerimientos del sistema, ya que en

muchos casos la especificación de requerimientos menciona sistema operativo y
hardware específicos.
o Las formas de interacción del usuario, por ejemplo si debe ser vía web o vía PDA.
o Los mecanismos de persistencia.
o La integridad de datos y transacciones.
Una capa es la organización física o lógica de componentes dentro de una cadena de
ordenamiento de clientes y proveedores. Existen metodologías que sugieren la
separación en tres, cuatro o cinco capas. A continuación se describen las cinco, pero se
pueden reducir de acuerdo a las necesidades de cada sistema.
o Capa del cliente, consiste de un cliente liviano como un navegador. La capa del
cliente contiene todos los componentes con los cuales interactúa el usuario. En
una aplicación web son las páginas web y los formularios que el servidor web
entrega al navegador.
o Capa de presentación que provee las páginas web y formularios que son enviados
al navegador y procesa los requerimientos del usuario.
o Capa del negocio que provee los servicios del negocio y las entidades. Allí los
componentes manejan la lógica, reglas y entidades de la aplicación.
o Capa de integración que provee componentes para integrar la capa de negocio
con la de recursos. Los componentes de esta capa ejecutan las operaciones de
crear, consultar, actualizar y eliminar una entidad.
o Capa de recurso que contiene los DBMS.
Existen cientos de arquitecturas exitosos, sin embargo las más comunes son:
o Aplicaciones standalone, compuesta de un componente que corre en una estación

de trabajo, como por ejemplo, una aplicación de procesador de palabra, editores
de texto, etc. Estas aplicaciones no acceden datos centralizados como una base
de datos, ni participan en comunicaciones a través de la red.
2003. Revision C.
Figura 4-38: Aplicaciones standalone
o Aplicaciones de dos capas (cliente/servidor), en la cual la aplicación reside en la

máquina del usuario y ésta se comunica a un almacenamiento de datos
centralizados.
2003. Revision C.
Figura 4-39: Aplicaciones cliente - servidor

o Aplicaciones de n capas, en las cuales se separan los componentes del negocio
de la aplicación del cliente. Por lo tanto, el servidor de aplicaciones se encarga de
administrar la integridad de datos y ejecuta todas las operaciones de
almacenamiento.
2003. Revision C.
Figura 4-40: Aplicaciones de n capas
o Aplicaciones web de n capas, en donde las aplicaciones se acceden a través de

un navegador y la lógica del negocio reside en un servidor web.
2003. Revision C.
Figura 4-41: Aplicaciones web de n capas
o Aplicaciones empresariales de n capas, la cual representa un híbrido entre las

aplicaciones de n capas y las aplicaciones web de n capas. En donde tanto los
servidores web como las estaciones de trabajo de los clientes se comunican con el
servidor de aplicaciones.
2003. Revision C.
Figura 4-42: Aplicaciones empresariales de n capas
4.3.9. Refinando el modelo de dominio
Posterior a la definición de la arquitectura, es necesario crear las clases identificadas

durante la arquitectura del sistema para el almacenamiento de la información.
Figura 4-43: Diagrama de clases de diseño
4.3.10. Diagrama de Transición de Estados
Los diagramas de transición de estados son similares a los diagramas de actividad. Los
estados de inicio y finalización también son representados con un círculo. Las transiciones
de los objetos van hasta su destrucción. Los estados son representados por rectángulos
con esquinas redondeadas y las transiciones entre estados son representadas por
flechas.
Un diagrama de transición de estados muestra cómo cambia un objeto a través del

tiempo. Todos los objetos tienen un estado y su valor lo determina el valor de sus
atributos. Un estado de un objeto es una de las posibles condiciones en las cuales puede
existir.
El estado inicial es que posee un objeto cuando es creado y es obligatorio. Sólo es

permitido un estado inicial. El estado final que indica el final de la vida del objeto y es
opcional. Puede existir más de un estado final. Un evento es una ocurrencia que sucede
en un punto del tiempo. El estado del objeto determina la respuesta a los diferentes
eventos. Una transición es un cambio hecho de un estado original a un estado sucesor
como resultado de un estímulo. Una acción es una operación que está asociada con una
transición. El nombre de una acción es mostrada en la flecha de la transición precedida
por un slash.
Agregar
estudiante(numest<10)
No Asignado
Do: Asignar profesor al curso
Iniciado Abierto
Do: Iniciar el objeto curso Entry: Matricular un estudiante
Cancelar Curso
Cancelar Curso
Cancelado Cupo Incompleto

Do: Enviar mensaje de cancelación Do: Eliminar estudiantes matriculados
Cancelar Curso
Finalización Matrícula
Cerrado
Do: Generar lista de clase
Do: Reporte curso lleno
Figura 4-44: Diagrama de Transición de Estados – Objeto Curso
4.3.11. Diagrama de Componentes
Los componentes son grupos de piezas de software clases que representan todo el
sistema, sus relaciones y son responsables por las operaciones dentro del sistema. Los
diagramas de componentes muestran el empaquetamiento físico del código. Esto puede
ser una clase, un archivo comprimido, un paquete, un ejecutable, librerías compartidas,
bases de datos, entre otras. Cuando un componente colabora con otro, esta colaboración
es representada como una dependencia entre el componente cliente y el componente
servicio. Control y Análisis
Interfaz de Terminal
Comment
Comment
Gestión de Cuentas Acceso a BD

Rutinas de Coneccion
Comment Comment Comment
Figura 4-45: Ejemplo de Diagrama de Componentes

Cuando uno de los componentes cambia, puede afectar a otro. Esto es llamado,
dependencia. Las clases de java son dependientes del código fuente.
4.3.12. Diagrama de Distribución
Algunos sistemas corren sobre una misma plataforma, mientras que otros están
distribuidos en una serie de máquinas. Existen diversas razones para construir soluciones
distribuidas. UML utiliza el diagrama de distribución para mostrar que el sistema corre a
través de diferentes plataformas.
Los diagramas de distribución consisten de nodos los cuales representan algún

dispositivo de hardware como servidores, estaciones de trabajo, PCs, sensores, teléfonos,
entre otros y muestran la configuración de los nodos, procesos, componentes y objetos
que residen en ellos en tiempo de ejecución. Las conexiones entre los nodos
corresponden a las conexiones de red entre ellos, presentadas como estereotipos.
Servidor Central Control y Análisis
Ac ceso a BD Comment
Comment
Rutinas de Coneccio n
Comment
Terminal de Consulta
Interfaz de Terminal
Comment Comment
Punto de Venta
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment
Figura 4-46: Ejemplo de Diagrama de Distribución

4.4. IMPLEMENTACIÓN DEL SISTEMA
El código es ejecutado dentro de la etapa de implementación. El modelo de

implementación describe cómo las clases e interfaces del sistema se convertirán en
código fuente y finalmente en archivos ejecutables. Dentro del proceso unificado, existen
dos entregas principales, el código fuente y los archivos ejecutables, llamados
componentes.
2203. Revision C.
Figura 4-47: Mapa del proceso Implementación
4.4.1. Plan de desarrollo
Basado en los requerimientos funcionales y los no funcionales, el arquitecto del sistema

determina cuánta gente es necesaria y qué habilidades requieren para desarrollar el
sistema.
Para determinar el número de desarrolladores se debe tener en cuenta:
o Tamaño y complejidad de los casos de uso

o Tamaño y complejidad de la arquitectura del sistema
o Integración con aplicaciones existentes
o Duración del proyecto
o Modularidad de los componentes
Para determinar las habilidades de los desarrolladores se debe tener en cuenta:
o El lenguaje de programación y la plataforma

o Tecnologías específicas
o Capa del cliente: HTML, JavaScript, Swing, VB
o Capa de presentación: JSP, PHP, ASP.
o Capa de negocio: RMI, EJB, CORBA.
o Capa de integración: JDBC, XA, MOM
o Capa de recurso: DBMS
o Ambiente de desarrollo en donde se tienen en cuenta las herramientas existentes.
Otra parte del plan de desarrollo es la selección de los casos de uso para las iteraciones y
cada uno debe entregar una parte claramente definida del comportamiento del sistema
completo. Por lo tanto, casos de uso completos deben asignarse a iteraciones
específicas.
Posterior a la definición de iteraciones, se estima el tiempo de desarrollo de los casos de

uso y por lo tanto, de cada iteración.
4.4.2. Código de la solución
4.4.2.1. Tipos de clases
Existen tres tipos de clases y para cada una de ellas existe un código de definición
diferente.
Clases concretas:
public class MyClass {

// members
}
Clases abstractas:
public abstract class AbsClass {
// members
}
Interfaz:
public interface MyInterface {
// members
}
Herencia:
El código para la definición de una subclase B que hereda de A es el siguiente:
public class B extends A {

// members
}
4.4.2.2. Atributos
El código para definir atributos de una clase es el siguiente:
public class Customer {

private final String firstName;
private final String lastName;
private Address address= new Address();
}
4.4.2.3. Relaciones
1 1..n
Estudiante Direcciones
Figura 4-48: Relación de asociación entre clases
public class Estudiante {

private Direcciones [] direcciones;
public [] Direcciones getDirecciones () {
return direcciones;
}
public void addDirecciones (Direcciones d) {
direcciones[0] = d;
}
}
//En otra parte de código
Estudiante est = new Estudiante (2344,”Sandra”);
Direcciones dir = new Direcciones (1,”carrera 29”);
est.addDirecciones(dir);
4.4.2.4. Agregación
1..n
Catálogo Cursos
Figura 4-49: Relación de agregación entre clases
import java.util.*;
public class Catalogo {
private Cursos [] cursos;
public Catalogo (Cursos cursos, String carrera){
this.cursos[0] = cursos
}
}
//En otro código
Cursos cursos = new Cursos (H99,”Álgebra”);
Catalogo catalogo = new Catalogo(cursos, “Facultad”);
4.4.2.5. Composición
Tomando el mismo ejemplo anterior.
import java.util.*;
public class Catalogo {
private Cursos []cursos;
Catalogo (int codigo, String nombre, String carrera){
this.cursos[0] = new Cursos (codigo,nombre);
//demás código
}
}
//En otro código
Catalogo catalogo = new Catalogo(H99, “Álgebra”, “Facultad”);
4.4.3. Ejemplo de la creación de un estudiante utilizando tres capas
Generalmente la programación se realiza en arquitecturas cliente servidor de la siguiente

manera:
import java.sql.*;
public class TodoenUno{
public static void main(String[] args) {
ResultSet rst = null;
PreparedStatement pstm = null;
Connection conn = null;
String nombre="Sandra Johanna";
String documento="63508526";
String apellido="Moreno Valero";
String mail="smoreno@unab.edu.co";
String strIP = "numeroIP";
String strPuerto = "1521";
String strNombreDB = "nombreBD";
String strUsuario = "nombreUsuario";
String strPassword = "contrasena";
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
conn = DriverManager.getConnection("jdbc:oracle:thin:@" + strIP + ":" + strPuerto + ":" + strNombreDB
+ "", "" + strUsuario + "", "" + strPassword + "");
pstm = conn.prepareStatement("INSERT INTO PERSONA MHOV_IDENTIFICA, CHOV_NOMBRES,
CHOV_PRIMERAPELLID, CHOV_EMAIL) VALUES (" + documento + ",'" + nombre + "','" + apellido +
"','" + mail+"')");
pstm.executeQuery();
pstm = conn.prepareStatement("SELECT A.CHOV_NOMBRES, A.CHOV_PRIMERAPELLID,
A.MHOV_IDENTIFICA, A.CHOV_EMAIL FROM PERSONA A WHERE A.MHOV_IDENTIFICA = " +
documento);
rst = pstm.executeQuery();
while (rst.next()) {
System.out.println(rst.getString(1));
}
Estudiante.java
if (pstm!=null) pstm.close();
if (conn!=null) conn.close();
}catch(SQLException error1){}
catch(ClassNotFoundException error2){}
}
}
Utilizando objetos y una arquitectura multinivel, el mismo código presentado anteriormente

quedaría:
public class Estudiante
{
protected String strNombre;
protected String strApellidos;
protected int intDocumentoIdentidad;
protected int intCodigo;
public Estudiante(String n, String a, int c, int d)
{
strNombre=n;
strApellidos=a;
intDocumentoIdentidad=c;
intCodigo=d;
}
public String getNombre()
{
return strNombre;
}
public String getApellidos()
{
return strApellidos;
}
public int getDocumentoIdentidad()
{
return intDocumentoIdentidad;
}
public int getCodigo()
{
return intCodigo;
}
public void guardarEstudiante() throws SQLException
{
public static ResultSet rst = null;

public static PreparedStatement pstm = null;
conn.setConeccion();
pstm = conn.prepareStatement("INSERT INTO ESTUDIANTES (NOIDENTIFICACION,
NOMBRES, APELLIDOS, CODIGO) VALUES+” (“+ intDocumentoIdentidad +”,”+ strNombre +”,” +
strApellidos+”,”+ intCodigo+”)");
pstm.executeQuery();
conn.cerrarConexion();
}
}
}
Coneccion.java
import java.sql.*;
public class Coneccion
{
public static Connection conn = null;
public static Connection setConeccion() throws ClassNotFoundException,SQLException
{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
conn = DriverManager.getConnection("jdbc:odbc:DRIVER={Microsoft Access Drive (*.mdb)};
DBQ=c:\\estudiantes.mdb", "admin","");
return conn;
}
public void CerrarConexion() throws SQLException
{
conn.close();
}
}
Programa principal o interfaz PruebaAdmStma.java
import java.sql.*;
public class PruebaAdmStma {
public static void main(String[] args) {
String nombre="Sandra Johanna";

int documento=5454545;
String apellido="Moreno Valero";
int codigo=1111;
Estudiante est = new Estudiante();
est.strNombre=nombre;
est.strApellidos=apellido;
est.intDocumentoIdentidad=documento;
est.intCodigo=codigo;
est.guardarEstudiante();
}
}
4.4.4. Refinación del diagrama de componentes
Interfaces Administrador. Entidades

.class class .class
Intefaces
.java DB.class
<<Applet>> Intefaces
ChartMaker. .jsp
class
Base de Datos
Figura 4-50: Diagrama de componentes
4.5. PRUEBAS DEL SISTEMA
2003. Revision C.
Figura 4-51: Mapa del proceso Pruebas

Dentro de esta etapa, los desarrolladores prueban el sistema. El modelo de pruebas
describe las pruebas para asegurar que la interfaz del sistema cumple con los
requerimientos del documento inicial. El modelo está compuesto por casos,
procedimientos y componentes de prueba.
Un caso de prueba describe una forma de probar el sistema y especifica las entradas del
sistema, las condiciones bajo las cuales deberían ser conducidas y las salidas esperadas.
Un procedimiento de prueba describe el método para ejecutar una o más pruebas y

describe cómo son ingresadas las entradas del sistema utilizando la interfaz del usuario y
cómo se muestran los resultados.
Los componentes de prueba son utilizados para automatizar el proceso de prueba y son
programas o scripts que son ejecutados en contra del sistema para realizar las pruebas.
Existen numerosas pruebas que se pueden aplicar. A continuación se mencionan algunas

de ellas:
Pruebas de un solo componente o unidad

Pruebas de integración que garanticen el adecuado funcionamiento de grupos de
componentes.
Pruebas funcionales las cuales se hacen a través de todo el sistema siguiente los
casos de uso definidos en la etapa de captura de requerimientos.
Pruebas de carga que verifican que el sistema puede manejar numerosos usuarios
concurrentes.
Pruebas con condiciones de límite que verifican que los componentes, las clases,
los subsistemas y el sistema en general puede manejar entradas que están fuera
de los valores aceptables.
Pruebas de usabilidad que verifican la eficiencia, claridad y facilidad de uso en la
interfaz del usuario.
Para desarrollar una prueba funcional es necesario seguir los siguientes pasos:
Identificar las entradas para la prueba, basadas en las entradas de un escenario

específico.
Especificar los resultados de la prueba.
Especificar las condiciones bajo las cuales se ejecutó la prueba
Escribir variaciones de la prueba para verificar fallas de procesamiento,
condiciones de límite, etc.
BIBLIOGRAFIA
Object-Oriented Application Analysis and Design for Java Technology (UML). 00-226.
Student Guide. Sun Microsystems. Revision B.2, April 2002.
Object-Oriented Analysis and Design: Academic Student Guide. CIW Object-Oriented

Analysis and Design Series. CIWv4. Prosoft Training. 2000-2002.
Methodology, Process, Education and Training for Today’s Software Development

Practices. Object- Oriented Analysis and Design. Student Manual. Rational University.
Product # 4100-06180, V3.5
Object-Oriented Analysis and Design Using UML. 00-226. Student Guide With Instructor
Notes. Sun Microsystems. Revision C. 2003.
ANEXO 1. PLANTILLA DE ESPECIFICACIÓN DE CASOS DE USO
<Project Name>
Use Case Specification: <Use-Case Name>
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and
should be deleted before publishing the document. A paragraph entered following this style will automatically
be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout the document by selecting
Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done
separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field
contents. See Word help for more information on working with fields.]
Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>
Table of Contents
1. Use-Case Name 70
1.1 Brief Description 70
2. Flow of Events 70
2.1 Basic Flow 70
2.2 Alternative Flows 70
2.2.1 < First Alternative Flow > 70
2.2.2 < Second Alternative Flow > 70
3. Special Requirements 71
3.1 < First Special Requirement > 71
4. Pre-conditions 71
4.1 < Pre-condition One > 71
5. Post-conditions 71
5.1 < Post-condition One > 71
6. Extension Points ¡Error! Marcador no definido.

6.1 <Name of Extension Point> ¡Error! Marcador no definido.
Use Case Specification: <Use-Case Name>
[The following template is provided for a Use-Case Specification, which contains the textual properties of the use
case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying
and marking the requirements within the use-case properties.
The use-case diagrams can be developed in a visual modeling tool, such as Rational Rose. A use-case report, with
all properties, may be generated with Rational SoDA. For more information, see the tool mentors in the Rational
Unified Process.]
Use-Case Name
Brief Description
[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this
description.]
Flow of Events
Basic Flow
[This use case starts when the actor does something. An actor always initiates use cases. The use case describes
what the actor does and what the system does in response. It is phrased in the form of a dialog between the actor
and the system.
The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific
about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer
information. It is better to say the actor enters the customer’s name and address. A Glossary of Terms is often useful
to keep the complexity of the use case manageable you may want to define things like customer information there
to keep the use case from drowning in details.
Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to describe what
happens when there is an alternative, do it directly within the Flow of Events section. If the alternative flow is more
complex, use a separate section to describe it. For example, an Alternative Flow subsection explains how to
describe more complex alternatives.
A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves
clarity, feel free to paste graphical depictions of user interfaces, process flows or other figures into the use case. If a
flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent
behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text.
Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that
your audience may not understand. Remember that your purpose is to clarify, not obscure.]
Alternative Flows
< First Alternative Flow >

[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of
Events section. Think of the Alternative Flow subsections like alternative behavior each alternative flow
represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as
necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events
of the main flow of events are resumed unless otherwise stated.]
< An Alternative Subflow >
[Alternative flows may, in turn, be divided into subsections if it improves clarity.]
< Second Alternative Flow >
[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative flow
separate to improve clarity. Using alternative flows improves the readability of the use case, as well as preventing
use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual
descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and
understandable way.]
Special Requirements
[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or
naturally specified in the text of the use case’s event flow. Examples of special requirements include legal and
regulatory requirements, application standards, and quality attributes of the system to be built including usability,
reliability, performance or supportability requirements. Additionally, other requirements such as operating
systems and environments, compatibility requirements, and design constraints should be captured in this section.]
< First Special Requirement >
Pre-conditions
[A pre-condition of a use case is the state of the system that must be present prior to a use case being performed.]
< Pre-condition One >
Post-conditions
[A post-condition of a use case is a list of possible states the system can be in immediately after a use case has
finished.]
< Post-condition One >
ANEXO 2. EJEMPLO DE PLANTILLA DE CASO DE USO
<Portales UNAB>
Especificación del Caso de Uso
<Solicitud Usuario UNAB>
Versión <1.0>
Historia de Revisiones
Fecha Versión Descripción Autor
26/08/2004 <1.0> Especificación inicial del caso de uso Camilo Ernesto Rodríguez
28/08/2004 <1.0> Ajuste de flujos alternos, especificación Sandra Johanna Moreno
de referencias, definiciones, Valero
requerimientos especiales y
poscondiciones.
31/08/2004 <1.0> Modificación de flujos alternos que Karol Dalila Reyes
verifica la coincidencia del correo
registrado en el sistema de información
con LDAP, antes de presentar el
mensaje que ya tiene un correo
asignado.
06/09/2004 <1.0> Agregar la validación que la persona Karol Dalila Reyes
que solicita no sea del Instituto Caldas
Tabla de Contenido
1. Introducción 75
1.1 Referencias 75
1.2 Definiciones, Acrónimos, y Abreviaturas 75
2. Flujo de Eventos 75
2.1 Descripción breve 75
2.2 Descripción del flujo normal 75
2.3 Descripción del flujo alterno 76
3. Requerimientos especiales 77
4. Precondiciones 77
5. Poscondiciones 77
Especificación del Caso de Uso
<Solicitud de usuario UNAB>
Introducción
Este documento presenta la especificación funcional del caso de uso solicitud de usuario
UNAB. El propósito de este documento es describir el comportamiento del servicio e identificar
los subsistemas relacionados. También describir los requerimientos no funcionales,
restricciones del diseño y otros factores necesarios para proveer una completa y comprensiva
descripción de los requerimientos del software.
Referencias
Caso de uso aplicación Alpha.
Manual de usuario aplicación Alpha.
Casos de prueba del caso de uso Solicitud de usuario UNAB. Doc N.
Manual de uso del correo electrónico UNAB.
Definiciones, Acrónimos, y Abreviaturas

Cosmos: Nombre dado al sistema académico de la UNAB.
SARA: Nombre dado al sistema de gestión de talento humano de la UNAB.
LDAP: Nombre dado al sistema que almacena la base de datos de usuarios UNAB.
IntraUNAB: Portal de acceso a servicios para docentes y administrativos de la
UNAB.
Portal del estudiante: Portal de acceso a servicios para estudiantes de pregrado y
posgrado de la universidad.
Alfa: Aplicación realizada en Java que permite actualizar datos en el LDAP y
desactivar cuentas de correo de estudiantes retirados.
Flujo de Eventos
Descripción breve
El caso de uso es iniciado por un estudiante o un empleado que va a solicitar un nombre de

usuario para acceder al correo electrónico y al portal del estudiante o IntraUNAB según
corresponda. Este caso de uso no aplica para los estudiantes del Instituto Caldas.
Descripción del flujo normal
{1}. El usuario selecciona la opción de solicitud de usuario UNAB y el sistema le presenta un

formulario para ingresar el documento de identidad.
{2}. El usuario ingresa su documento de identidad y el sistema valida que los caracteres
ingresados sean solo numéricos, y que el usuario no sea estudiante del Instituto Caldas
y se encuentre registrado en el sistema académico o de gestión de talento humano,
según sea estudiante o empleado.
{3}. El sistema verifica que el usuario no tenga registrado cuenta de correo en el sistema de
información correspondiente y le presenta un formulario para que pueda crear el usuario
y la cuenta de correo UNAB.
{4}. El usuario ingresa la contraseña y el sistema valida que tiene que ser mínimo 8
caracteres y debe ser diferente de la cédula y el código en caso sea estudiante.
{5}. El usuario ingresa confirmación de contraseña y el sistema valida que tiene que ser
igual a la contraseña digitada anteriormente.
{6}. El usuario ingresa correo contacto que es una cuenta alterna y el sistema valida que
cumpla con los parámetros generales de una cuenta que correo, donde verifica que
tenga la @ y su respectivo dominio.
{7}. El usuario envía los datos y el sistema crea el usuario y la cuenta de correo UNAB,
actualiza la información de correo en el sistema de información correspondiente.
Descripción del flujo alterno
Usuario no registrado
{2.1 }. La persona que solicita la creación de usuario UNAB, no se encuentra registrado en

el sistema de información correspondiente, por lo tanto, presenta un mensaje
indicando que no se encuentra registrado en el sistema y que se comunique con
Secretaría General o la Oficina de Personal según corresponda.
Cuenta de correo registrada en el sistema de información y en LDAP
{3.1}. La persona que solicita la creación de usuario UNAB, ya tiene registrada una cuenta
de correo en el sistema correspondiente y el sistema verifica que las cédula
registrada en LDAP de ese nombre de usuario, coincide con la cédula registrada en
el sistema de información.
{3.2}. El sistema presenta un mensaje indicando que la persona que solicita ya tiene un
usuario y cuenta de correo creada y le presenta el nombre de usuario con el cual
puede ingresar al portal del estudiante o IntraUNAB según corresponda y al correo
UNAB. Además, el sistema actualiza en LDAP los atributos correspondientes según
el caso. Para estudiantes, actualiza los atributos facultad, código y estudiante, para
administrativos, actualiza los atributos cargo, dependencia y administrativo y para los
docentes, actualiza los atributos cargo, dependencias y docente.
Cuenta de correo errónea registrada en el sistema de información y no existe usuario

en LDAP para la persona solicitante
{3.1.1}. La persona que solicita la creación de usuario UNAB, ya tiene registrada una cuenta
de correo en el sistema correspondiente y el sistema verifica que la cédula registrada en
LDAP de ese nombre de usuario, no coincide con la cédula registrada en el sistema de
información.
{3.1.2}. El sistema le presenta el formulario para que pueda solicitar usuario UNAB y se
ejecutan los pasos registrados en el flujo de eventos normal, presentados en el punto
2.2.
{3.1.3}. La persona envía la solicitud y el sistema verifica que no exista un usuario asignado
a la persona solicitante, crea el usuario, actualiza el dato correo en el sistema de
información correspondiente y presenta un mensaje indicando que se ha creado
satisfactoriamente el usuario.
Cuenta de correo errónea registrada en el sistema de información y si existe usuario
en LDAP para la persona solicitante
{3.1.2.1}. La persona envía la solicitud y el sistema verifica que si exista un usuario

asignado a la persona solicitante, por lo cual, actualiza el dato correo en el sistema de
información correspondiente y presenta un mensaje indicando que la persona ya tenía
un usuario creado pero no se encontraba registrado en el sistema correspondiente. Por
lo tanto, con el proceso que acaba de ejecutar, se han actualizado los datos del perfil
del usuario. Además, el sistema actualiza en LDAP los atributos correspondientes
según el caso. Para estudiantes, actualiza los atributos facultad, código y estudiante,
para administrativos, actualiza los atributos cargo, dependencia y administrativo y para
los docentes, actualiza los atributos cargo, dependencias y docente.
Requerimientos especiales
No identificados en esta fase.
Precondiciones
La persona que va a solicitar usuario y cuenta de correo UNAB debe ser un estudiante que se
encuentre registrado en el sistema Cosmos, o un empleado que se encuentre registrado en el
sistema SARA. La persona que no pertenezca a estos sistemas de información y desee usuario
y correo electrónico UNAB, necesitará comunicarse con la dependencia encargada para que se
le asigne utilizando un procedimiento diferente al especificado en este caso de uso.
Poscondiciones
Para mantener actualizados la información del servidor de directorios y los sistemas de

información que permiten validar los usuarios autorizados para ingresar a los portales se debe
tener en cuenta los siguientes procedimientos:
La persona encargada de administrador el correo UNAB deberá ejecutar la aplicación

alfa una vez al mes para desactivar los correos de los empleados retirados y una vez al
semestre para desactivar los estudiantes que se han retirado de la universidad.
Cada vez que un estudiante se gradúe o se retire de la universidad, se le debe eliminar
la información del correo institucional del sistema Cosmos, ya que los nombres de
usuarios y las cuentas de correo se desactivan en los servidores de directorio y correo y
se vuelven a reutilizar para otros usuarios. De lo contrario, si el estudiante regresa a la
universidad y va a solicitar nuevamente un correo, le aparecerá un mensaje indicando
que ya tiene asignado un correo.
Cada vez que un empleado se retire de la universidad, se le debe eliminar la
información del correo electrónico del SARA, para evitar el mismo inconveniente
descrito en el punto anterior.
ANEXO 3. EJEMPLO DE CASO DE PRUEBA
Portal de Estudiante
Especificación de Caso de Prueba:
Caso de Pruebas de Solicitud de Usuario UNAB
Version 1.0
Historial de Revisiones
Fecha Version Description Author
25/08/2004 1.0 Especificación inicial del caso de Camilo Ernesto Rodríguez
prueba
28/08/2004 1.0 Detalle de los resultados esperados y Sandra Johanna Moreno Valero
evaluación de la prueba. Quedaron
pendientes algunas pruebas por
desconocimiento de qué es lo que se
verifica.
Tabla de Contenido
1.Descripción
2.Estudiante que solicita un usuario UNAB
2.1 Descripción
2.2 Condiciones de ejecución
2.3 Entrada
2.4 Resultado esperado
2.5 Evaluación de la prueba
3. Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo institucional en
Cosmos
3.1 Descripción
3.3 Entrada
4. Estudiante que es administrativo y tiene una cuenta de correo UNAB, pero no están
actualizados los atributos de estudiante en LDAP.
4.1 Descripción
4.3 Entrada
5. Empleado que solicita un usuario UNAB.
5.1 Descripción
5.3 Entrada
6. Empleado que solicita un usuario UNAB, pero ya tiene registrado el campo email en SARA.
6.1 Descripción

6.3 Entrada
7. Empleado que tiene un usuario UNAB, pero no están actualizados los atributos de
empleado en LDAP.
7.1 Descripción
7.3 Entrada

1. Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso

“Solicitud Correo UNAB”.
Las pruebas realizadas a este caso de uso son:
Estudiante que solicita un usuario UNAB.

Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo
institucional en Cosmos.
Estudiante que es administrativo y tiene un usuario UNAB, pero no están
actualizados los atributos de estudiante en LDAP.
Empleado que solicita un usuario UNAB.
Empleado que solicita un usuario UNAB, pero ya tiene registrado el campo
mail en SARA.
Empleado que tiene usuario UNAB, pero no están actualizados los atributos
de empleado en LDAP.
El entorno del cual partiremos para realizar las pruebas será el formulario de
entrada de la aplicación, según sea el caso, Portal del estudiante o IntraUNAB.
2. Estudiante que solicita un usuario UNAB.
2.1 Descripción
Ingresamos al portal del estudiante como visitante y hacemos clic en la columna

derecha en “Solicita aquí tu usuario UNAB”, seguidamente nos envía a la pagina de
solicitud de usuario donde presenta una caja de texto. El sistema solicita la cédula del
estudiante y se procederá a crear el usuario UNAB.
2.2 Condiciones de Ejecución
Las condiciones de ejecución del caso de prueba es que el usuario con la cedula
63557609 se encuentre registrado en Cosmos y que la tabla General.Goremal de
Cosmos no tenga registrado ninguna cuenta de correo UNAB y en LDAP no tenga
asignado un usuario.
2.3 Entrada
El estudiante introduce en la caja de texto el numero de identificación

“63557609” y hace clic en buscar.
Aparece el formulario de solicitud de correo con los campos contraseña,
confirmar contraseña y correo contacto.
El estudiante ingresa en el campo contraseña 123456
El estudiante ingresa en el campo confirmar contraseña 1234567
El estudiante ingresa en el campo correo contacto jaimeBar@hotmail.cccs
El estudiante hace clic en enviar.
Aparece un mensaje que dice “La contraseña debe ser mínimo de 8
caracteres”.
El estudiante cambia la contraseña por 12345678.
Aparece un mensaje que dice “La contraseña debe ser igual que
confirmación contraseña”.
El estudiante cambia la confirmación contraseña por 12345678
El estudiante hace clic en enviar
Aparece un mensaje que dice “El dominio del correo contacto es incorrecto”
El estudiante cambia el correo por jaimeBar@hotmail.com
El sistema presentó un mensaje que dice “Tu usuario UNAB ha sido creado
satisfactoriamente, por lo cual estás habilitado para ingresar al Portal del
Estudiante y al servicio de correo UNAB, con Tu nombre: JULIANA
BALLESTEROS TRILLOS, Tu usuario: jballesteros3, Tu correo:
jaballesteros3@unab.edu.co.
Creación de la cuenta de correo para el estudiante con documento 63557609 y la

actualización de la tabla General.Goremal con esta información.
La prueba superada con éxito, ya que se verificó la creación del usuario en LDAP, se
accedió a la cuenta de correo a través de la web y comprobó la actualización de la
tabla General.Goremal en Cosmos.
3. Estudiante que solicita un usuario UNAB, pero ya tiene registrado el correo

institucional en Cosmos.
3.1 Descripción

derecha en “Solicita aquí tu usuario UNAB”, seguidamente se presenta la pagina de
solicitud de usuario donde nos muestra una caja de texto. Se ingresa la cedula del
estudiante y se procede a la creación del usuario UNAB.
13722001 se encuentra registrado en Cosmos y que en la tabla General.Goremal de
Cosmos se encuentre registrado el correo institucional.
3.3 Entrada
El estudiante introduce en la caja de texto el número de identificación

Aparece un mensaje que dice “El sistema reporta que ya tienes asignada la
cuenta de usuario UNAB crodrigr@unab.edu.co para acceder al Portal de
Estudiante y al servicio de correo. Para mayor información consulta con la
Red Institucional en el primer piso del edificio de biblioteca, o la extensión
389”
No se hizo la creación de la cuenta de correo UNAB, por que ya tiene asignada una
cuenta de correo en Cosmos
La prueba superada con éxito, ya que se verificó, que no se creó el usuario en LDAP, y
se verifico también, que en Cosmos en la tabla General.Goremal la cuenta de correo
crodrigr@unab.edu.co pertenece al estudiante con la cedula 13722001.
4. Estudiante que es administrativo y tiene una cuenta de correo UNAB, pero no

están actualizados los atributos de estudiante en LDAP.
4.1 Descripción

derecha en “Solicita aquí tu usuario UNAB”, seguidamente nos envía a la pagina de
solicitud de correo donde nos muestra una caja de texto, ingresamos la cedula del
estudiante y procedemos a solicitar el usuario UNAB.
77185418 se encuentra registrado en Cosmos y que la tabla General.Goremal no
tenga registrado ninguna cuenta de correo UNAB y que en LDAP tenga asignado una
cuenta de correo.
4.3 Entrada
El estudiante introduce en la caja de texto el número de identificación

El estudiante ingresa en el campo contraseña 12345678
El estudiante ingresa en el campo confirmar contraseña 12345678
El estudiante ingresa en el campo correo contacto Silvio@yahoo.com
El sistema presentó un mensaje que dice “El sistema reporta que ya tienes
asignada la cuenta de usuario UNAB scuellod@unab.edu.co para acceder
al Portal de Estudiante y al servicio de correo. Para mayor información
consulta con la Red Institucional en el primer piso del edificio de biblioteca, o
la extensión 389”
Actualizar el perfil de estudiante en LDAP y registrar en Cosmos en la tabla

General.Goremal la cuenta de correo scuello@unab.edu.co, la información para
actualizar en LDAP son los atributos, estudiante en “si”, código del estudiante y código
de la facultad.
La prueba superada con éxito, se verificó la correcta actualización de los atributos

estudiante “si”, código “U00009487” y facultad “EDRE” en LDAP y también se verificó
que se registró en la tabla General.Goremal de Cosmos, la cuenta de correo
scuellod@unab.edu.co.
5. Empleado que solicita un usuario UNAB.
5.1 Descripción
Ingresamos a la IntraUNAB y hacemos clic en “Solicitud usuario UNAB”,

seguidamente nos envía a la pagina de solicitud de usuario donde nos muestra una
caja de texto, ingresamos la cédula del empleado y procedemos solicitar el usuario
UNAB.
“13842037” se encuentre registrado en SARA y no tenga registrado ninguna cuenta de
correo UNAB y en LDAP no tenga asignado una cuenta de correo.
5.3 Entrada
El empleado introduce en la caja de texto el numero de identificación

El empleado ingresa en el campo contraseña 123456
El empleado ingresa en el campo confirmar contraseña 1234567
El empleado ingresa en el campo correo contacto
jmartineza@dian.gov.coom
El empleado hace clic en enviar.
Aparece un mensaje que dice “La contraseña debe ser mínimo de 8
caracteres”.
El empleado cambia la contraseña por 12345678.
Aparece un mensaje que dice “La contraseña debe ser igual que
confirmación contraseña”.
El empleado cambia la confirmación contraseña por 12345678
El empleado hace clic en enviar
Aparece un mensaje que dice “El dominio del correo contacto es incorrecto”
El empleado cambia el correo por jmartineza@dian.gov.co
El sistema presentó un mensaje que dice “Su usuario UNAB ha sido creado
satisfactoriamente, por lo cual estás habilitado para ingresar a la IntraUnab y
al servicio de correo UNAB. Tu nombre: AIME NEL MARTINEZ ANGEL, Tu
usuario: jmartinez7 , Tu correo: jmartinez7@unab.edu.co.
Creación de la cuenta de correo para el empleado con documento 13842037 y registro

de la cuenta de correo jmartinez7@unab.edu.co en la tabla
ACTUALIZACION_CORREO de SARA.
La prueba superada con éxito, se verificó la creación de la cuenta correo en LDAP y

registro de la misma en la tabla ACTUALIZACION_CORREO de SARA.
6. Empleado que solicita usuario UNAB, pero ya tiene registrado el dato email en
SARA.
6.1 Descripción
Ingresamos a la IntraUNAB y hacemos clic en “Solicitud usuario UNAB”, seguidamente
nos envía a la página de solicitud de correo donde nos muestra una caja de texto,
ingresamos la cédula del empleado y procedemos a solicitar el usuario UNAB.
13722001 se encuentra registrado en SARA y tiene registrado el dato email en SARA.
6.3 Entrada
El empleado introduce en la caja de texto el numero de identificación

Aparece un mensaje que dice “El sistema reporta que ya tienes asignada la
cuenta de usuario UNAB crodrigr@unab.edu.co para acceder a la
IntraUNAB y al servicio de correo. Para mayor información consulta con la
Red Institucional en el primer piso del edificio de biblioteca, o la extensión
389”
No se hizo la creación de la cuenta de correo UNAB, por que ya tiene asignada una
cuenta en SARA.
La prueba superada con éxito, se verificó en Ldap que ya existe una cuenta de correo
con la cedula 13722001 que corresponde al empleado Camilo Ernesto Rodríguez
Moreno, con cédula 13722001 y con la cuenta de correo crodrigr@unab.edu.co ,
también se verificó que la información con respecto al nombre, cédula y cuenta de
correo en LDAP es igual a la de SARA.
7. Empleado que un usuario UNAB, pero no están actualizados los atributos de

empleado en LDAP.
7.1 Descripción
Ingresamos a la IntraUNAB y hacemos clic en “Solicitud usuario UNAB”, seguidamente

nos envía a la pagina de solicitud de correo donde nos muestra una caja de texto,
ingresamos la cedula del empleado y procedemos a la creación del usuario UNAB.
Las condiciones de ejecución del caso de prueba es que el usuario con la cédula
13746331 se encuentra registrado en SARA y que no tenga registrado ninguna cuenta
de correo UNAB, pero que en LDAP tenga asignado una cuenta de correo.
7.3 Entrada
El empleado introduce en la caja de texto el número de identificación

El empleado ingresa en el campo contraseña 12345678
El empleado ingresa en el campo confirmar contraseña 12345678
El empleado ingresa en el campo correo contacto edgar@yahoo.com
El sistema presentó un mensaje que dice “El sistema reporta que ya tienes
asignada la cuenta de usuario UNAB eagudel2@unab.edu.co para acceder
a la IntraUNAB y al servicio de correo. Para mayor información consulta con
la Red Institucional en el primer piso del edificio de biblioteca, o la extensión
389”
Actualizar el perfil de empleado en LDAP y en la tabla ACTUALIZACION_CORREO.

La información a actualizar en LDAP son los atributos, según sea el caso,
administrativo en “si” o docente en “si”, dependencia y title.
La prueba superada con éxito, se verifico que se hizo la correcta actualización de los
atributos administrativo “si” ,docente “si” y facdocente “UNAB TECNOLÓGICA” en
LDAP y también se verificó que se actualizó en SARA en la tabla
ACTUALIZACION_CORREO el login “eagudel2” y cédula ”13746331”.

Curso ADOO - UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso ADOO - UML

Enviado por

Direitos autorais:

Formatos disponíveis

ESPECIALIZACIÒN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE

ANALISIS Y DISEÑO ORIENTADO A OBJETOS

Ing. Sandra Johanna Moreno Valero

(Este material es reproducido con fines educativos)

Análisis y diseño es el primer paso en el desarrollo de un sistema de software. Análisis es

En el contexto del desarrollo de software, la fase de análisis se enfoca en los siguientes

Establecer una vista clara del problema del negocio

En el contexto del desarrollo de software, la fase de diseño se enfoca en los siguientes

Resolver el problema del negocio

Figura 1-1: Ejemplo de diagrama de flujo de datos

1.1. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Los modelos estructurados centran su atención en el flujo de información a través del

Los métodos orientados a objetos intentan satisfacer estas demandas. El componente

Figura 1-2: Objeto Orden

1.2. METODOLOGÍA DE ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

La metodología OOA&D consiste de tres partes:

Un proceso o secuencia de actividades relacionadas y entregables que son utilizadas

1.3. CRISIS DEL SOFTWARE

En marzo de 1989, Arthur Andersen reportó:

1.4. VENTAJAS DE LA TECNOLOGÍA DE OBJETOS

1.5. DESVENTAJAS DE LA ORIENTACIÓN A OBJETOS

Existen pocos retos en esta transición de la ingeniería del software a la tecnología

La abstracción es utilizada para manejar la complejidad. Los ingenieros del software

La encapsulación produce dos vistas de cada objeto:

La ventaja de la encapsulación es que la clase puede cambiar. Si los cambios se reflejan

En varias ocasiones, los objetos no pueden existir independientemente de otro. En este

1.6.7. Cohesión y Acoplamiento

El acoplamiento es también una medida de dependencia entre objetos. Los objetos

El concepto de polimorfismo está basado en la herencia. El polimorfismo soporta la

La implementación de una función polimórfica depende del objeto en el cual se aplica.

El polimorfismo funciona sólo cuando la operación común es semánticamente similar.

UML brinda la sintaxis para describir la estructura de clases, componentes, programas y

o Diagrama de casos de uso que representan el comportamiento del sistema con un

Figura 2-1. Vistas de los diagramas de UML.

3.1. PROCESO DE DESARROLLO TRADICIONAL

El método de Cascada es el proceso de desarrollo de software más popular.

Figura 3-1: Metodología de cascada para el desarrollo de software

En el método de cascada, el proceso de desarrollo es completado en una dirección a

Para maximizar los beneficios de UML, es necesario utilizar un proceso de análisis y

3.2. PROCESO UNIFICADO DE DESARROLLO

A continuación se describe una metodología basada en el proceso unificado de desarrollo

El proceso unificado de desarrollo de software es conducido por los casos de uso,

Centrado en la arquitectura: El proceso unificado presta gran atención en la arquitectura

Todas estas opciones de software componen la arquitectura del sistema de biblioteca.

Iterativo e incremental: El proceso unificado divide un proyecto de desarrollo en una serie

Esta característica presenta los siguientes beneficios:

Reducción del riesgo basado en la temprana realimentación

En cada iteración se deben realizar los siguientes pasos:

Figura 3-2: Pirámide del desarrollo de software orientado a objetos

3.3. FASES DEL PROCESO UNIFICADO

El proceso unificado se compone de las fases de inicio, elaboración, construcción y

Requerimientos y análisis inicial

3.3.1. Fase de Inicio

Los propósitos de la fase de inicio son:

Los productos entregables en esta fase son:

Principales requerimientos del proyecto (funcionales y no funcionales)

3.3.2. Fase de Elaboración

Los propósitos de la fase de elaboración son:

Crear un modelo de análisis y diseño de alto nivel

Los productos entregables en esta fase son:

Modelo del comportamiento del sistema

3.3.3. Fase de Construcción

El propósito de la fase de construcción es: