Gestion informatica i
155
-
Upload
jose-nain-castillo-castaneda -
Category
Marketing
-
view
415 -
download
2
Transcript of Gestion informatica i
1
2
3
4
TABLA DE CONVERSIONES
UNIVERSIDAD PERUANA LOS ANDES
Educación a Distancia.
Huancayo.
Impresión Digital
SOLUCIONES GRAFICAS SAC
Jr. Puno 564 - Hyo.
Telf. 214433
5
INDICE
PRESENTACION 9
UNIDAD TEMÁTICA I
INTRODUCCIÓN AL UML 11 INTRODUCCIÓN. 11
El Lenguaje de Modelado Unificado 12 Beneficios del UML 13 Lo que UML no intenta 15
Lenguajes de programación 15 Herramientas 16
Origen de UML y como se convirtió en un estándar 16 UML presente y futuro 18 La importancia de Modelar 19
Vistas de un Modelo 20 Diagramas UML 21
UNIDAD TEMÁTICA II MODELAMIENTO DE PROCESOS 23
Terminologías Básicas 23 Esquema de dato e información 24
¿Qué es un modelo? 24 Proceso 25 Beneficios de tener modelos de los procesos 25
Abstracción 26 Importancia del proceso de abstracción. 26
Usuarios 26 Los usuarios primarios
Los Usuarios finales Sistemas 27
Características importantes de los Sistemas 27
Sistemas de Información (SI) 28 Tecnología de Información (TI) 29
Tecnología de Información versus Sistemas de Información 29 Procesos 29
Información de los Procesos
Diferencia entre Proceso y Procesamiento Pasos para Analizar Procesos de Negocios 31
Identificar los Procesos Identificar a los propietarios de los procesos Mantener la relación entre cada uno de los procesos
Documentar Crear diagramas de procesos de primer nivel
Crear diagramas de procesos de 2do. Nivel Entrega de diagramas a los propietarios de cada uno de los procesos para su revisión.
Concientizar explicando los procesos Características de los procesos 34
6
Los procesos y las organizaciones 35 Orientación de las Organizaciones 35
Calidad del requerimiento 36 Definición de IDEF 36
Tipos de diagramas IDEF 37
IDEFO (Modelamiento de procesos) IDEF3 (Diagrama de flujos de trabajos WorkFlow)
DFD (Diagrama do Flujo de Dalos) Tipos de Modelos 42
Modelo AS-IS (como es).
Modelo TO-BE (va a ser). Esquema de análisis y diseño de sistemas 42
Árbol De Nodos 43 Diagrama de Descomposición Funcional 44
UNIDAD TEMÁTICA III ANALISIS
DIAGRAMA DE CASOS DE USO 47 INTRODUCCIÓN 47
Diagramas de Casos de Uso 48 Casos de Uso 48 Representación gráfica de los Casos de Uso 49
Nomenclatura de los casos de Uso 50 Representación gráfica de un actor 50
Nomenclatura de un Actor 51 Relaciones en los diagramas de casos de uso 51 Representación gráfica de una asociación 52
Relación <<include>> 52 Representación gráfica de una relación «include» 53
Nomenclatura de una relación «include» 53 Casos Típicos 53
Relación «Extend» 54
Representación gráfica de una relación «extend» 55 Nomenclatura de una relación «extend» 55
Casos típicos 55 Puntos de extensión en un caso de uso 56 Cuándo usar «include» y «extend» 57
Representación gráfica de los diagramas de casos de uso 57 Documentación de los diagramas de casos de uso 58
Documentación de un caso de uso con relación «extend» 60
Paquetes de casos de uso 61
Cómo construir los diagramas de caso de uso 62 Cómo encontrar los Actores 62
Cómo encontrar los casos de uso 62 Cómo encontrar las relaciones entre actores y casos de uso 63 Describir el flujo de eventos 63
EJEMPLOS VARIOS 63
7
UNIDAD TEMÁTICA IV
DISEÑO
DIAGRAMA DE SECUENCIA, COLABORACIÓN, ESTADO Y ACTIVIDADES
Diagrama de Secuencia 77 Tipos de Línea de Mensaje 79 Simple:
Síncrono: Asíncrono:
Foco de Control Visión del Diagrama de Secuencia 81
Casuísticas de Diagramas de secuencia. 82 Mensajes síncronos: Mensaje Recursivo:
Iteración de Mensajes: Bifurcación de Mensajes
Diagrama de Colaboración 84 Diagrama de Estado 86
¿Qué es un Diagrama de Estados? 87
Representación de acciones 88 Sub-Estados.-
Sub Estados Secuénciales.- El Sub Estado Concurrentes.- Estados Históricos.-
Diagrama de actividades 94 Transición de actividad a otra 95
Decisiones 96 Envío de Señal 97 Creadores de Patrones 98
¿Qué es un contrato? 98 Patrones GRASP 99
Patrón Creador 100 Patrón Agente Dispositivo (Pandilla de los Cuatro) 101 Patrón Comando (Pandilla de los Cuatro) 101
UNIDAD TEMÁTICA V
DIAGRAMA DE CLASES 103 INTRODUCCIÓN 103 Diagrama de Clases 104
Diagrama de Objetos 104 Clase 105
Representación Gráfica 105 PRIMER COMPARTIMIENTO 106 Nombre 106
Multiplicidad de la Clase 107 SEGUNDO COMPARTIMIENTO 107
Atributos 107
8
Especificando atributos 108 Visibilidad de los atributos 108
Multiplicidad (multiplicity) de los atributos 109 El tipo (type) de los atributos 109 Valor inicial de un atributo 110
Cadena de propiedades (property string) 110 Alcance de los atributos 111
TERCER COMPARTIMIENTO 112 Operaciones 112 Visibilidad de las Operaciones 113
Lista de parámetros (parameters list) 114 El tipo de retorno (return-type) de las operaciones 115
Alcance de las Operaciones 116 Polimorfismo y operaciones polimórficas 116
Responsabilidades de las clases 118 Casos Particulares de clases 119 Clase Abstracta: 120
Clase Parametrizada 121 Clase Asociación 123
Clase Activa 123 Clase Utilidad (Utility Class) 124 Clase Interfaz (Interfaz Class) 124
Clase Hoja (Leaf Class) 125 Clase Raíz (Root Class) 125
Metaclase (metaclass) 126 Relaciones entre Clases 126 Relación de Dependencia 126
Relación de Generalización 129 Relación de Asociación 129
Extremo de la Asociación (Association End) 131 Detallando una Asociación 131 Clasificación de una Relación de Asociación 133
Clasificación según el número de clases participantes 133 Asociación binaria 133
Asociación N-aria 133 Clasificación según como se unen para formar otra clase 135
Asociación AND (And Association) 135
Asociación de Agregación 135 Asociación de Composición 136
Asociación XOR (Xor Association) 136 Estrategias para la creación de Diagrama de Clases 138 EJERCICIOS RESUELTOS 138
BIBLIOGRAFIA 155
9
PRESENTACION
La Gestión Informática está orientada al análisis y representación
de modelos especialmente intensivos en el uso y desarrollo de la
gestión administrativa y contable, utiliza diversos métodos pero se
obtiene mayor provecho cuando se utiliza con el Proceso Unificado de
Desarrollo.
Existen diferentes textos sobre el tema de Proceso Unificado que
les podrá ayudar si desean tener un enfoque amplio sobre el UML, que
en combinaciones con los patrones de software a esto podemos
considerar las herramientas CASE, el Lenguaje Visual.
También podemos considerar el manual oficial de UML o buscar
por internet páginas sobre el tema para una mayor consistencia en
nuestros conocimientos.
Dentro de la asignatura de Gestión Informática no se puede
enseñar todo al mismo tiempo, por lo que el libro se ha dividido en 5
capítulos en donde considero en el capítulo I el UML como herramienta
primordial como una unificación del desarrollo y diseño de modelos, el
capítulo II contempla el Modelamiento de Procesos, nos ayuda a
entender y a modelar procesos bajo un esquema fácil a través de
ejemplos, el capítulo III contempla el análisis ya en sí dentro del campo
de la Gestión por lo que recurre al Análisis para luego en el capítulo IV
considerar los diagramas de secuencia, colaboración, estado y
actividades que son parte del análisis y diseño, finalmente en el
capítulo V determinamos nuestros diagramas de clases producto de los
análisis desarrollados en los capítulos anteriores.
10
11
INTRODUCCIÓN AL UML
OBJETIVOS GENERALES
- Analizar y Diseñar el modelado de procesos de negocios a través
de la representación gráfica de un sistema.
OBJETIVOS ESPECIFICOS
- Visualizar de una forma gráfica un sistema de forma que otro lo pueda
entender.
- Especificar cuáles son las características de un sistema antes de su
construcción.
- Construir sistemas a través de modelos especificados.
- Documentar los elementos que sirven para el modelamiento para su futura
revisión.
INTRODUCCIÓN.
Cuando la "Orientación a objetos empieza a ponerse de moda, surgen
diversos estudiosos cada uno con su propia metodología y símbolos
para representar sus ideas. Hacia 1994, existan más de 50 métodos de
desarrollo de software orientado a objeto, cada uno con su respectivo
lenguaje de modelado. Cada metodólogo defendía su método
provocando la llamada “Guerra de los Métodos”. Esto ocasiono un
panorama desalentador para las personas que deseaban aprender a
modelar bajo el paradigma orientado a objetos, que ofrecía la mejor
manera de desarrollar software superado las limitaciones del pasado;
pues se debía de aprender muchos métodos y su simbología, así como
conceptos en algunos casos contradictorios.
12
Bajo este panorama surge la necesidad de unificar la metodología de
desarrollo de software orientado a objetos, pero ella era una empresa
demasiado ambiciosa y fue mucho más fácil proponer primero un
lenguaje común de modelado orientado a objetos: el UML, y luego
proponer una metodología unificada para el desarrollo de software: el
Proceso Unificado.
Así, el UML satisface esta necesidad y, apoyado poi las más
importantes empresas de tecnologías de información, se convierte en
un estándar mundialmente aceptado, facilitándonos el aprendizaje y
aplicación del paradigma orientado a objetos.
El Lenguaje de Modelado Unificado
El UML (Unified Modeling Languaje o Lenguaje Unificado de
Modelado) es un lenguaje gráfico para la especificación, visualización,
construcción y documentación de piezas de información usadas o
producidas durante el proceso de desarrollo de software. A estas piezas
de información se les conoce como Artefactos. El UML provee un
marco arquitectónico de diagramas para trabajar sobre análisis y
diseño orientado a objetos, así como también el modelamiento de
negocios y otros sistemas que no son software. El UML es pues un
lenguaje simbólico para expresar modelos orientados a objetos y no
una metodología para desarrollarlos.
Este lenguaje es el resultado de la convergencia de las mejores
prácticas en la industria de tecnología de software orientado a objetos,
en especial de la simbología utilizada por tres de los principales
métodos de análisis y diseño orientado a objetos como son Booch
(Booch), OMT (Rumbaugh), y OOSE (Jacobson)-cuyos autores se
agruparon en Rational Software para desarrollarlo. El UML surge
pues como la unión de la simbología utilizada por estos métodos, pero
13
es mucho más, puesto que Incluye formas adicionales para manejar
problemas que el modelado con estos métodos no abarcaba
completamente.
Muchas compañías están incorporando el UML como estándar en sus
procesos y productos, que cubren disciplinas tales como
modelamiento del negocio, requisitos de gerencia, análisis y
diseño.
Beneficios del UML
Los beneficios aportados por el UML son:
1) Provee a los desabolladores un lenguaje de modelamiento visual
listo para utilizar, es así como nosotros podemos desarrollar e
intercambiar modelos orientados a objetos significativos. El UML
consolida un conjunto de conceptos que son generalmente
aceptados por muchos métodos y herramientas de modelado y
necesarios en una amplia gama de aplicaciones. Este es uno de los
principales beneficios aportados por el UML, permitiendo el avance
de la industria del software para construir modelos que puedan ser
utilizados por diferentes herramientas, debido a su aceptación como
un estándar de modelado.
2) Proporciona mecanismos de extensión y de especialización para
ampliar los conceptos básicos. El UML puede ser ampliado para
nuevas necesidades en un dominio especifico. Los conceptos no
pueden ser cambiados mas de lo necesario, pues los usuarios
necesitan construir modelos usando conceptos fundamentales para
las aplicaciones más comunes, sin necesidad de usar los
mecanismos de extensión; pero, pueden añadir nuevos conceptos y
notaciones para usos no cubiertos por sus definiciones, escoger
entre interpretaciones variables de conceptos existentes cuando no
existe un claro consenso y, especializar conceptos, notaciones y
restricciones de un particular dominio de la aplicación.
14
3) Proporciona una base formal para entender el lenguaje de
modelado. Los usuarios usan la formalidad para ayudarse a
comprender el sistema, pero el formalismo no debe requerir muchos
niveles o capas y uso excesivo de matemáticas. UML provee de una
definición formal del modelo estático usando el Diagrama de Clase.
Este diagrama es muy popular y ampliamente aceptado como
aproximación formal de un modelo y del intercambio de
información, pero además, el UML expresa las restricciones en OCL
(Object Constraint Languaje) y las operaciones en un lenguaje
natural muy preciso.
4) Anima el crecimiento del mercado de las herramientas de
Orientación a Objetos, porque permite a los vendedores soportar un
lenguaje estándar de modelado usado por muchas herramientas, en
beneficio de la industria. La interoperatibilidad requiere que los
modelos puedan ser cambiados entre usuarios y herramientas sin
perder información. Esto solo es posible cuando las herramientas
manejan un conjunto de conceptos relevantes y ampliamente
aceptados por la industria del software.
5) Utiliza conceptos de alto nivel de desarrollo tales como
colaboraciones, armazones, modelos y componentes, definiendo
claramente la semántica de estos conceptos lo cual es esencial para
obtener los beneficios de la orientación de objetos, colocando
dentro de un contexto completo un lenguaje de modelado único.
6) Integra las mejores prácticas de desarrollo de software. La
motivación clave para el desarrollo del UML es la integración de las
mejores prácticas de la industria, acompañados de variedades
amplias de vistas en niveles de abstracción, dominios,
arquitecturas, ciclos de vida, tecnologías de implementación, etc.
15
Primero, unifica los conceptos de los métodos Booch, OMT y OOSE. El
resultado es un simple, común y ampliamente utilizable lenguaje para
usuarios de estos y otros métodos.
Segundo, UML pone sobre el tapete lo que pueden hacer los métodos
existentes. Por ejemplo, los autores de UML modelaron sistemas
distribuidos para asegurar que el UML trate adecuadamente estos
dominios.
Tercero, UML se centra en unificar el lenguaje de modelado, y no un
proceso de desarrollo estándar. Aunque la experiencia demuestra que
las diversas organizaciones y dominios del problema requieren diversos
procesos de desarrollo UML puede ser utilizado en esos procesos. Sin
embargo, el UML promueve el desarrollo de procesos manejados por
casos de uso, centrado en arquitectura, iterativos e increméntales. Es
por olio que los esfuerzos se centraron primero en crear un
metamodelo común y luego en una notación común.
Lo que UML no intenta
El UML se centra en simplificar y estandarizar modelos, dando la
flexibilidad necesaria para ser utilizado en el diseño de una variedad de
sistemas en una amplia gama de industrias. Sin embargo, no puede
abarcarlo todo, algunas áreas importantes fuera del alcance del UML
incluyen:
Lenguajes de programación
El UML es un lenguaje de modelamiento visual, en el sentido del tener
toda la ayuda visual y semántica necesaria para substituir lenguajes de
programación, sin embargo, no está pensado para ser un Lenguaje
de Programación Visual. El UML es un lenguaje para visualizar,
especificar, construir, y documentar los artefactos de un sistema
16
orientado a objetos donde se hará uso intensivo del software, y solo le
indica el camino cuando usted tenga que implementar el código. El
UML especifica mediante gráficos lo que una familia de lenguajes
Orientados a Objetos debe hacer.
Herramientas
Estandarizar un lenguaje es necesariamente definir los fundamentos
para las herramientas y el proceso. La meta fundamental del OMG era
permitir interoperabilidad entre las diferentes herramientas. Sin
embargo, las herramientas y su interoperabilidad son muy
dependientes de una sólida semántica y la definición de una notación,
tal como el UML proporciona. El UML define un meta modelo
semántico, no una interfaz de la herramienta, almacenaje, o modelo
runtime, aunque éstos deben estar bastante cerca de uno otro.
Origen de UML y como se convirtió en un estándar
Los lenguajes de modelado orientados al objeto identificabas
comenzaron a aparecer a mediados de la década de 70 y al final de los
'80, en donde varios metodólogos experimentaron con diversos
acercamientos al análisis y al diseño orientados al objeto. El número de
lenguajes que modelaban objetos aumentó de menos de 10 a más de
50 durante el período entre 1989-1994. Muchos de los que utilizaban
estos métodos no encontraban satisfacción completa en alguno de los
lenguajes de modelado propuestos, esto motivo la llamada "Guerras
de los Métodos". Hacia mediados de 1990, estos métodos
comenzaron a madurar y las nuevas iteraciones aparecieron
incorporando otras técnicas, haciendo que algunos de estos métodos
prevalecieran sobre otros.
El desarrollo de UML comenzó hacia finales de 1994 en que Grady
Booch y Jim Rumbaugh de Rational Software Corporation,
comenzaron su trabajo sobre la unificación de sus propios métodcs:
17
Booch y OMT (Object Modeling Techniqué). A finales de 1995,
Ivar Jacobson y su compañía de Objectory se unieron a Rational y
combinaron sus métodos.
Los autores de los métodos OMT, Booch y OOSE, Jim Rumbaugh,
Grady Booch e Ivar Jacobson (conocidos en el medio como los tres
amigos) fueron motivados para crear un lenguaje unificado de
modelado por tres razones:
Primero, estos métodos se desarrollaban uno independientemente de
los otros. Tuvo sentido continuar esta evolución juntos en vez de
separados, eliminando cualquier diferencia innecesaria y gratuita que
confundiera más a los usuarios de sus métodos. Segundo, unificando
la semántica y la notación de sus métodos, traerían cierta estabilidad
al mercado orientado al objeto. Al permitir la creación de un lenguaje
de modelamiento maduro, le deja a los constructores de herramientas
la implementación de características más útiles en su software, en vez
de distraer este esfuerzo en varios lenguajes de modelamiento.
Tercero, contaban con que su trabajo conjunto rindiera mejoras en los
tres métodos anteriores, ayudándose con las lecciones aprendidas a
resolver los problemas que ninguno de sus métodos manejaba bien.
Los "tres amigos" al unificar la simbología de sus métodos enfocaron
sus esfuerzos en:
Permitir modelar los sistemas, no necesariamente software, que
usan conceptos orientados a objetos.
Establecer un lenguaje que acople conceptos orientados a objetos
y permita su intercambio, así como también de sus artefactos.
Tratar las aplicaciones de sistemas complejos y misión-críticos en
la escala adecuada.
Crear un lenguaje de modelado utilizable por los hombres
y las máquinas.
18
Los esfuerzos de Booch, Rumbaugh, y Jacobson, dieron frutos al
liberar los documentos de UML 0,9 y 0,91 en junio y octubre de
1996. Durante 1996, los autores de UML y la empresa
Rational Software
invitaron a la comunidad de desarrolladores a realizar sus
aportes, incorporando esta retroalimentación pero aun faltaba
más por hacer. Mientras esto ocurría, los esfuerzos de la industria
del software eran hechos con la meta más amplia de definir un
lenguaje de modelamiento estándar. En junio de 1995, el OMG
reunió a todos metodólogos importantes, dando lugar al primer
acuerdo mundial para buscar estándares bajo la batuta del OMG.
Este pedido del OMG proporcionó al catalizador para estas
organizaciones para unir fuerzas alrededor de un lenguaje
unificado. Durante 1996, varias organizaciones consideraron UML
como estratégico a su negocio.
UML no garantiza éxito del proyecto sino que mejora muchas cosas.
Por ejemplo, baja perceptiblemente el coste continuo de entrenamiento
y del uso de herramientas cuando se cambia de proyecto u
organización y proporciona la oportunidad para !a nueva integración
entre las herramientas, procesos y dominios.
UML presente y futuro
El UML no es propiedad de ninguna empresa es decir está abierto a
todos. Trata de resolver las necesidades de los desarrolladores de
software y creadores de herramientas así como de comunidades
científicas, según lo establecido por la experiencia con los métodos
subyacentes en los cuales se basa. Muchos metodólogos,
organizaciones, y vendedores de herramientas han confiado en él para
utilizarlo. Puesto que las estructuras de UML se basan sobre la
semántica y notación de Booch, OMT, OOSE y de otros métodos, han
19
incorporado el aporte de los socios de UML y del público en general, la
adopción del UML como estándar está garantizada. Hay dos aspectos
que el UML alcanza:
Primero, termina con eficacia muchas de las diferencias, a menudo
inconsecuentes, entre los lenguajes de modelado de métodos
anteriores.
Segundo, y quizás más importante, unifica las perspectivas entre
muchas diversas clases de los sistemas (negocio y lógica de software),
de fases del desarrollo (análisis, diseño y puesta en práctica), y de
conceptos internos relativos a la tecnología orientada a objetos y al
desarrollo de software.
Aunque el UML se define como un lenguaje exacto, no es una barrera
para mejoras futuras. El UML puede ser extendido sin la redefinición de
sus fundamentos. Se espera que el UML en su forma actual, sea la
base para la creación de muchas herramientas, incluyendo los
ambientes visuales de modelado, de simulación y de desarrollo.
Puesto que se están desarrollando integraciones interesantes
entre las herramientas, los estándares basados en el UML llegarán a
ser cada vez más utilizadas.
La importancia de Modelar
Desarrollar un modelo para un sistema de software antes de su
construcción o renovación es tan esencial como tener un modelo para
un edificio antes de levantarlo. Los buenos modelos son esenciales para
la comunicación entre equipos de proyecto y asegurar validez
arquitectónica. Mientras que la complejidad de los sistemas aumenta se
hace más importante las buenas técnicas de modelado. Hay muchos
factores adicionales para el éxito de un proyecto, pero tener un
lenguaje estándar riguroso de modelamiento es esencial.
Un lenguaje de modelamiento debe incluir:
• Elementos fundamentales que modelan conceptos y la semántica
20
• Notación para la representación visual de los elementos del
modelo.
• Guías de consulta para el uso de los desarrolladores, vendedores y
la enseñanza.
Mientras que el valor estratégico del software aumenta, la industria
busca técnicas para automatizar la producción del software, mejorar la
calidad, reducir los costos y el tiempo necesario para poner un producto
en el mercado. Estas técnicas incluyen tecnología de componentes, la
programación visual, modelos y marcos de trabajo. Los negocios
también intentan técnicas para manejar la. complejidad de sus
sistemas mientras que aumentan de alcance y tamaño, reconociendo
la necesidad de solucionar problemas arquitectónicos que se repiten,
tales como distribución física, ejecución simultánea, réplica, seguridad,
balance de carga y tolerancia de tallos. Además, el desarrollo del
World Wide Web, hace algunas cosas más simples, pero ha
aumentado tremendamente estos problemas arquitectónicos. El
Lenguaje Unificado de Modelado (UML) fue diseñado para responder a
estas necesidades, y es la respuesta bien definida y extensamente
validada a la necesidad de modelar visualmente sistemas cada vez más
complejos.
Vistas de un Modelo
Para desarrollar un sistema es necesario verlo desde diferentes
perspectivas, lo que da lugar a diferentes vistas del sistema,
dependiendo de lo que deseamos mostrar en un instante determinado.
Vista de Diseño
Vista de
Procesos
Vista de
Implementación
Vista de
Despliegue
Vista de los
Casos de Uso
21
La vista de Casos de Uso, muestra la descripción del comportamiento
del sistema tal como lo observan los usuarios finales.
La Vista de Diseño, muestra los servicios que nuestro sistema debe
proporcionar y como lo hará. Comprende las clases, interfaces y
colaboraciones.
La vista de Procesos, comprende los hilos y procesos que forman
mecanismos de sincronización y concurrencia del Sistema.
La Vista de Implementación, comprende los componentes que pn
sistema-^- disponte e, sistema físico.
La Vista de despliegue, contiene los nodos que forman la topología
del hardware sobre la que se ejecuta el sistema.
Cada una de estas vistas se puede representar mediante los diagramas
UML.
Diagramas UML
El UML puede describir cualquier tipo de sistema en términos de
diagramas orientados a objetos. Entre los diferentes tipos
tenemos de sistemas de información, sistemas de tiempo real, sistemas
embebidos, sistemas distribuidos, software de sistemas, sistemas de
negocios.
Los diagramas se utilizan para dar diferentes perspectivas del problema
según lo que nos interese representar en un determinado momento.
Los diagramas que UML define son:
1.- Diagramas de Casos de Uso
2.- Diagramas de Clases
3.- Diagramas de Objetos
4.- Diagramas de Secuencia
5.- Diagramas de Colaboración
6.- Diagramas de Estado
7.- Diagramas de Actividad
8.- Diagramas de Componente
9.- Diagramas de Despliegue
22
Estos diagramas proveen múltiples perspectivas del sistema bajo el
análisis y desarrollo: además, estos diagramas soportan una adecuada
documentación y algunas herramientas de software, pueden mostrar
diferentes vistas a partir de estos diagramas. Este libro cubre la
descripción de estos diagramas mediante ejemplos que le permitirán
adiestrarse en su construcción, y capacitarlo para poder enfrentar al
mundo real construyendo sus propios modelos.
23
MODELAMIENTO DE PROCESOS
OBJETIVOS GENERALES
- Identificar el área correcta para cambiar y mejorar los procesos
como parte integral para el éxito total de la organización
considerando el modelamiento.
OBJETIVOS ESPECÍFICOS
- Proporcionar maneras de expresar procesos de negocio o estrategias en
términos de negocios de actividades económicas y comportamiento
colaborativo.
- Aumentar la velocidad del cambio en los negocios.
Terminologías Básicas
Dato
Es cualquier hecho que ocurre en el universo y que tiene una
representación almacenable.
Información
Datos procesados que son utilizados en un contexto y transmiten un
significado a los individuos. Las computadoras procesan los datos sin
tener constancia de lo que éstos representan en realidad.
24
Esquema de dato e información
El presente gráfico nos da una idea de cómo podemos diferenciar el
concepto de dato e información. Si un periodista recolecta datos (notas
de expresiones, graba declaraciones, toma fotos) de un hecho; en este
caso una huelga; ha capturado datos, que luego los llevará a un
proceso donde intervienen las actividades: separar, clasificar, sacar
resumen entre otros; para luego producir información: artículo
periodístico, nota televisiva.
¿Qué es un modelo?
Cada vez que queremos construir una casa o edificio, lo primero que se
debe hacer es dibujar un plano y crear maquetas de la edificación;
igual sucede para construir un sistema. Se deberán crear los modelos
que son como los planos que servirán para identificar procesos,
construir base de dalos entre otros; estando estos procesos
identificados podemos construir sistemas de acuerdo a los
requerimientos de los usuarios.
Un modelo es la visión de lo que se diagnóstica o se desea construir.
UNIVERSO
DATO
PROCESO
Separar, Clasificar,
Ordenar, Calcular,
Insertar, Consultar,
Actualizar, Eliminar
INFORMACION
25
Proceso
Los procesos están conformados o integrados por grandes conjuntos de
actividades, funciones o tareas que existen debido a un negocio. Estos
forman la gran estructura del negocio para la acción, es decir toma de
decisiones. A todo proceso se le deberá identificar sus entradas y
salidas; porque, siempre tendrán un comienzo y un final.
Beneficios de tener modelos de los procesos
Uno de los beneficios es conocer las actividades más importantes
que interactúan en el negocio con la finalidad que se pueda lograr
una documentación clara, precisa y gráfica de los procesos; para
que de esa manera puedan ser analizados y diseñados
efectivamente. Esto permitirá diagnosticar y plantear soluciones o
reestructurar problemas en el enlomo del negocio.
Otro beneficio de modelar procesos, es acceder a una certificación
ISO (Organización de Estándares Internacionales), tales como:
ISO 9000, ISO 2000. Los ISO están conformados por un conjunto
de propiedades o características de un producto o servicio en el
desenvolvimiento del mismo dentro de una organización, la cual
permite asegurar la calidad para quienes adquieren o hacen uso
de los productos o servicios. Para ello se obtiene una certificación
ISO.
VENDER
PRODUCTOS PEDIDO
DOCUMENTO
DE VENTAS
SUMAR
CALCULAR TOTAL
EMITIR DOCUMENTO
ENTRADA PROCESO SALIDA
26
Abstracción
Se refiere a quitar las propiedades y acciones de un objeto para dejar
sólo aquellas que sean necesarias.
De acuerdo con los objetos mostrados, aplicando abstracción hemos
identificado tres atributos para cada objeto, sería innecesario identificar
quien se sentará o en que lugar se deba colocar etc.
Importancia del proceso de abstracción.
Es la capacidad humana que tenemos de poder discernir y obtener las
propiedades y acciones necesarias de los objetos para los modelos a
construir, porque de no tener claro este concepto llenaríamos de
objetos con acciones innecesarias a la lógica del negocio de estudio,
dificultando la identificación de los objetivos.
Usuarios
Los usuarios son los que interactúan con el sistema o se benefician de
los resultados de los mismos.
• Los usuarios primarios, son los que interactúan con el sistema.
Ellos lo alimentan (entradas) o reciben salidas, quizá por medio de
un terminal.
• Los Usuarios finales, para este grupo se considera aquellos que
usan los resultados para la toma de decisiones como son los
gerentes administrativos y asesores. Dentro de este grupo
tendríamos los usuarios externos de la organización, recibiendo la
información, como los recibos e informes de estado.
Por ejemplo, si analizamos el sistema de información de una empresa
de telefonía: los usuarios primarios serían los operadores que
manipulan las interfaces de pagos, consultas, entre otros; mientras,
que los usuarios finales serían los gerentes que esperan los gráficos
estadísticos de ventas o servicios para tomar una decisión.
Hoy en día los usuarios externos que adquieren los recibos de servicios
para la mayoría de los sistemas Web, estos hasta cierto punto son
27
primarios, porque pueden hacer transacciones desde cualquier lugar del
mundo.
Sistemas
Es un conjunto de componentes que interactúan entre sí para lograr un
objetivo común.
Ejemplo:
Sistema contable
Sistema nervioso
Sistema de gobierno
Sistema educativo
Sistema contable
Sistema digestivo
Características importantes de los Sistemas
Todo sistema tiene una razón o fin de existencia.
Los sistemas interactúan con el medio ambiente.
Los componentes que forman un sistema pueden ser a su vez
sistemas más pequeños; es decir, los sistemas pueden estar
formados por varios niveles de sistemas o subsistemas. El cuerpo
humano, por ejemplo, contiene subsistemas tales como los
sistemas respiratorio y circulatorio. Un automóvil tiene sistemas
de combustión, eléctricos y de control de emisiones. En general,
en situaciones de sistemas, es común tener vanos niveles de
sistemas interactuando entre sí.
Ejemplos de sistemas
Sistema de Tienda
Subsistema de
Compras
Subsistema de
Almacén
Subsistema de Ventas
Facturación
28
Sistema de gobierno
Sistema de banco
Sistemas de Información (SI)
Basándonos en la definición propuesta por Andreu, Ricart y Valor
(1991), entendemos por Sistema de Información a:
Conjunto integrado de procesos, principalmente formales;
desarrollados en un entorno usuario-ordenador, que operando sobre un
conjunto de datos estructurado (base de datos) de una organización,
recopilan, procesan y distribuyen selectivamente la información
necesaria para la operatividad habitual de la organización y las
actividades propias de la dirección de la misma.
Poder Ejecutivo
Poder
Legislativo
Poder Judicial
Jurado nacional
de Elecciones
Subsistema
Ahorros
Subsistema
Prestamos
Subsistema
Cuenta
Corrientes
Subsistema
Publicidad
Subsistema
Finanzas
29
Tecnología de Información (TI)
Conjunto de tecnologías que proporciona soluciones claras a
determinados problemas. Considera a la informática,
telecomunicaciones. Ejerce un papel de capacitador, catalizador y
apoyo para los sistemas de información.
[GIL IGNACIO "Sistemas y Tecnología de información para la Gestión.
Editorial MCGRAWHILL. España 97]
Tecnología de Información versus Sistemas de Información
Hoy en día no existe un matrimonio armonioso entre los sistemas y
tecnologías de información, debido a que los usuarios no están
capacitados en el conocimiento de tecnologías y en contraparte los
desarrolladores no logran aprender los procesos de negocios por no
manejar un lenguaje común entre usuarios y desarrolladores. En
consecuencia, se crean sistemas de información con tecnologías que no
se adaptan a las necesidades de los usuarios. Cuando no existe una
sincronización entre los procesos reales, sistemas y Tecnologías de
información, muchos usuarios de los que se resisten al cambio, creen
que la forma en que llevan en la actualidad sus procesos es
conveniente y más segura, dando por conclusión la no adaptación a los
avances tecnológicos. Quedando rezagados de los beneficios del mundo
informático.
Procesos
Información de los Procesos
Cuando se inicia el estudio de una organización lo primero que
debemos hacer es identificar los procesos: que son como piezas
de rompecabezas que tenemos que armar para interpretar los
negocios y de esta manera poderlos diagnosticar y después
reestructurar.
30
Diferencia entre Proceso y Procesamiento
Proceso.- Es el conjunto de actividades de trabajo
interrelacionadas que se caracterizan por requerir ciertos insumos
(inputs, productos o servicios obtenidos de otros proveedores) y
tareas que implican valor añadido, con miras a obtener ciertos
resultados.
Procedimiento.- Es un conjunto de reglas o instrucciones que
determinan la manera de proceder o de obrar para conseguir un
resultado.
Pasos para Analizar Procesos de Negocios
1. Identificar los Procesos
En la mayoría de nuestras organizaciones tienen el modelo
jerárquico en su administración; por lo tanto tenemos que
empezar a identificar a los procesos unidepartamentales, y en
esta parte iremos aprendiendo las actividades de cada uno de
ellos. Aquí se deberá tener cuidado con la revisión de
documentos oficiales de la empresa ya que no siempre se
sincronizan las funciones definidas con las del desempeño de
cada uno de los procesos. A continuación, se deben identificar
los procesos multidepartamentales que son los que enlazan la
tela de araña de los flujos de cada uno de los procesos en la
organización.
Dirección
Dpto_1 Dpto_2 Dpto_3
Ofici_1 Ofici_2
Procesos
Unidepartamentales
Procesos
Multidepartamentales
31
2. Identificar a los propietarios de los procesos
Una vez identificados los procesos, se deberá identificar
quienes son propietarios de cada uno de ellos, porque
conociendo al experto podremos programar sesiones de
aprendizaje de las actividades.
3. Mantener la relación entre cada uno de los procesos
Cuando ya conocemos a los propietarios y tenemos toda una
tormenta de procesos y actividades, debemos mantener una
relación entre los procesos identificados para no malversar la
visión general de los procesos del negocio.
4. Documentar
No basta con solo identificar y sincronizar, sino documentar
los procesos diagnosticados para poderlos modelar y de esa
manera tener una referencia de lo que estamos aprendiendo.
Cuando los procesos están documentados, los encargados de
dirigir el negocio pueden administrar
y reestructurar; para de esta manera
seguir el ciclo.
32
5. Crear diagramas de procesos de primer nivel
Para comenzar a crear los diagramas del primer nivel, suelen
ser por lo general complicado armarlos, ya que no siempre los
usuarios te proporcionan el conocimiento del negocio con
flexibilidad. Lo importante es que logremos involucrar al
cliente en el levantamiento de información. Si el nivel cultural
de los propietarios de los procesos es bajo, se recomiendo
usar mapas mentales como herramientas iniciales para el
levantamiento de datos, ya que iremos diagramando con
dibujos naturalmente entendibles la lectura de los procesos,
reinando para ello un lenguaje de comunicación entre el
desabollador y cliente.
Si los propietarios de los procesos tienen un nivel cultural
adecuado al aprendizaje de los modelos técnicos, se
recomiendo usar la metodología IDEFO (Integración y
Definición de Funciones Organizacionales), ya que permitirá
descomponer los procesos de arriba hacia abajo, identificando
las entradas, salidas, mecanismos (son los autores y/o
elementos que transforman el proceso), así como también los
controles (reglas, políticas), que se definen para cada uno de
los procesos en todos sus niveles.
Una vez identificados los procesos, se constituirán en la
antesala para la construcción de los casos de uso que están
orientados a los escenarios, teniendo la particularidad de
crear subprocesos reutilizables con los conceptos de
<<extend>>, proceso extendido y «Include», proceso
incluido.
33
6. Crear diagramas de procesos de 2do. Nivel
Una vez identificados cada uno de los procesos se debe
descomponer en niveles, y cuando ya se desintegró en un
nivel considerable de jerarquización para cada uno de los
procesos, se deben desmenuzar en actividades.
Este criterio de descomposición en niveles, es relativo; porque
hoy en día con los casos de uso, se recomienda dividirlo por
conjunto de procesos en función a la administración del
negocio y no crear una escalera de niveles de procesos, que
en muchos casos hace perder la visión holística de lo que se
diagnóstica o desea construir.
7. Entrega de diagramas a los propietarios de cada uno de
los procesos para su revisión.
Una vez construido los diagramas en cada uno de los niveles,
deberán ser entregados a los propietarios de cada uno de los
procesos para su revisión, nunca los analistas deberán
subestimar el conocimiento del negocio; porque, por muy
similares que puedan ser los negocios siempre cada negocio
tiene sus características peculiares.
34
8. Concientizar explicando los procesos
Aquí es donde se pone a prueba la capacidad del Analista, con
respecto a ser un Diplomático, Pedagogo, Psicólogo y Líder.
En función de llevar al grupo de desarrollo y los clientes a una
comunión entre las partes, tanto para vender su producto y
hacer que ese producto satisfaga los requerimientos de los
clientes. Para que de esa manera el sistema de información no
fracase.
Características de los procesos
Una vez diagnosticados cada uno de los procesos se debe
tener en cuenta, qué es lo que hacemos con los procesos
identificados, para tal caso tenemos que evaluar si los
modelos son de transición o transformación.
Si se encuentra en el criterio de someter a una transición,
deberá diseñar la manera de manejar los procesos con el
sistema de información computarizado.
En caso de tener el considerar o aplicar la transformación de
los modelos de los procesos, deberá reestructurarlos o en
todo caso aplicar reingeniería, que consiste en hacer una
revisión fundamental y rediseño de forma radical de los
procesos con el objetivo de tener grandes mejoras.
MODELO DE
PROCESOS
DIAGNOSTICADOS
MODELO DE
PROCESOS
SISTEMATIZADOS
35
Los procesos y las organizaciones
Orientación de las Organizaciones
Debe tener orientación al cliente
Toda organización que desee estar en la vanguardia de este mundo
globalizado, deberá tener sus procesos correctamente modelados en
función al cliente, teniendo como secuencia indicar "que es lo que
necesita el cliente del negocio proveedor"; para ello deberá haber
definido correctamente la misión del negocio. A continuación se debe
tener en claro COMO y CUANDO necesita el servicio o producto, para
luego definir los procesos con el fin de indicar la organización funcional
que administrara los mismos. No sólo basta tener correctamente
definido el proceso para estar a la vanguardia, sino definir la gestión
que permitirá administrar el proceso modificado, rediseñado o definido
para que cumpla su fin. Seguidamente buscar y liderar los equipos
humanos que serán los actores o el cumplimiento de los objetivos
establecidos. Si descuidamos al factor humano no motivando ni
liderando, por más que tenga sofisticados modelos de procesos, estos
fracasarán y fenecerán en muy corto tiempo.
Organización ¿Qué necesita?
¿Cómo?
¿Cuándo?
Definición de procesos
Organización
Gestión
Equipos Humanos
36
Calidad del requerimiento
Para definir correctamente los requerimientos se tiene que integrar tres
criterios; necesidades del cliente, expectativas y posibilidades
del proveedor del servicio o producto.
El primer criterio tiene que ver con lo explicado en el gráfico anterior,
sobre tener claro las necesidades del cliente, para luego medir las
expectativas con respecto al servicio o producto; y después, integrar
las posibilidades del proveedor que tienen que estar correctamente
ensambladas y comunicadas. Que pasaría si un cliente "A", tiene una
gran expectativa de lo que recibirá; pero, el proveedor no puede
proporcionarlo, entonces todo nuestro esquema de procesos no tendría
sentido de existencia, porque el negocio no sería rentable.
Toda organización estructurada jerárquicamente, tendrá dificultad para
integrarse a la lógica de los negocios globalizados; mientras, que las
estructuradas con procesos se integrarán sin dificultad.
Definición de IDEF
Es una técnica de análisis y diseño de sistemas que es utilizada para la
definición de sistemas, análisis de requisitos y diseño de software.
Consiste en un conjunto de procedimientos, que permiten al analista de
sistemas descomponer y comprender mejor las interrelaciones del
sistema y sub-sistemas de los procesos de negocio paso a paso para
explicar el proceso total. Cada actividad es administrada como una
Necesidades del
Cliente
Expectativas Posibilidades del
Proveedor
37
transformación de entradas en salidas, tomando control sobre las
restricciones y mecanismos o factores de producción consumidos por la
actividad, bajo el modelo ICOM Input Control Output Mecanismo).
También es una técnica de modelamiento de datos que permite graficar
los objetos que intervienen en el proceso de investigación de un
negocio. IDEF fue creado por la Fuerza Aérea de los EEUU, que deriva
de la metodología SADT (Structured Analisys and Design Tecnique)
utilizada para la modelización funcional de actividades y que ha
alcanzado la categoría de estándar en EEUU.
Tipos de diagramas IDEF
IDEFO (Modelamiento de procesos)
Representan el Modelamiento de actividades IDEFO o procesos de
negocio, es una técnica para realizar el sistema total de estudio
como un conjunto de actividades o funciones interrelacionadas
entre si. Las actividades que son las acciones del sistema en
estudio, son analizadas independientemente del o de los objetos
que intervienen en el proceso de negocio.
IDEF3 (Diagrama de flujos de trabajos WorkFlow)
Representan redes de flujo procesos, algunas veces referidos
como diagramas workflow, es una metodología de modelamiento
cuya meta primaria es proveer un método estructurado que
describa una situación como una secuencia ordenada de eventos,
igualmente describe cualquier objeto participante y las reglas
asociadas.
La diagramación workflow, es una técnica bien adaptada para
reunir datos como parte del análisis y diseño estructurado.
38
DFD (Diagrama do Flujo de Dalos)
Los diagramas de flujo de dalos modelan los sistemas como una
red do actividades que procesan datos para y desde almacenes
que so encuentran dentro o fuera de los límites del sistema
estudiado.
Simbología Gráfica ICOM
Descripción De Elementos
INPUT Son elementos o ítems que van a sufrir una
transformación o cambio de estado al someterse al proceso, tal
como: un pedido, capital, solicitud.
En la mayoría de los casos cada entrada va a estar asociada a
una entidad y dicha entidad contendrá a un grupo de atributos.
Ejemplo: El flujo de entrada "ficha de datos" tendrá la
entidad FICHA y la misma contendrá los atributos de
CÓDIGO, APELLIDO PATERNO, APELLIDO MATERNO,
NOMBRES, FECHA DE NACIMIENTO.
ACTIVIDAD
CONTROL
OUTPUT INPUT
MECANISMO
Pedido
Solicitud
Ficha de Datos
39
CONTROLES. Son las restricciones o reglas de gobierno del
proceso, por tal sentido intervienen las reglas de negocio,
políticas, etc.
Los controles se representan por un flujo, para que más
adelante sean ilustrados por cuadros, o idioma estructurado.
Aumentos
X fiestas Lista de
Precios
Tipos de
servicios
40
Reglas de negocio.
Ilustración Del Control "Lista De Precios"
DESTINO
ORIGEN TUMBES TALARA SULLANA TRUJILLO LIMA
TUMBES XXXXXX S/. 7.5
S/. 5
S/. 7.7
S/. 8
S/. .21
S/. 20
TALARA XXXXXX XXXXXX S/. 3
S/. 3
S/. 12
S/. 14
SULLANA XXXXXX XXXXXX XXXXXX S/. 13
S/. 13
TRUJILLO XXXXXX XXXXXX XXXXXX XXXXXX
LIMA 80
90
70
80
60
70
40
50 XXXXXX
Nota: El precio del pasaje de Lima a Sullana cuesta 70
soles y de Sullana a Lima cuesta 60 Soles.
Ilustración de aumentos por lista de pasajes
Días de Viaje Tasa de
aumentos
26 Julio al 29 Julio 50%
20 Diciembre al 2
Enero
50%
2/sem Abril(semana
santa)
20%
OUTPUTS. Viene a ser el resultado del proceso, es una entrada
transformada, ejemplo: Pedido aceptado, Solicitud aceptada,
Factura cancelada, etc.
41
Al igual que los flujos de entrada, los flujos de salida también
tienen entidades a las cuales se le debe asociar.
MECANISMO. Son los recursos utilizados para transformar las
entradas hacia las salidas.
Ejemplos: personas, equipos, sistemas, etc.
Ejemplo:
Proceso: Compra al crédito un Televisor. En Sagafallabela
Punto de Vista: Empresa de crédito.
Nivel: 0
Factura Cancelada
Recibo sellado
Guía verificada
SECRETARIA
VENDEDOR TELEFONO
GERENTE
COMPRA AL
CRÉDITO
Línea de Crédito
Estado de Cuenta
Plazo de Pago
Tasa de Interés
Solicitud de compra
Aceptada
Artículo
Tarjeta CMR
Solicitud de Compra
Vendedor
Cliente
Personal de Crédito
42
Tipos de Modelos
El objetivo es descomponer los procesos de negocio, paso a paso para
explicar el proceso total. Cada actividad es administrada como una
transformación de entradas en salidas, tomando control sobre las
restricciones y mecanismos o factores de producción consumidos por la
actividad. Para ello se tiene 2 tipos de diagramas que se subdividen en:
• MODELO AS-IS (como es)
• MODELO TO-BE (va a ser).
• Modelo AS-IS (como es). Es aquel que va a graficar, cómo los
procesos de negocio se encuentran desempeñándose en la
actualizada, explicando en forma encapsulada la descripción de
procesos y subprocesos. Es como sacar una radiografía del
proceso.
• Modelo TO-BE (va a ser). Permite graficar como va a ser el
sistema; después de haber sido analizado, hay que considerar
dos cosas importantes: si el sistema será de transición o de
transformación, para este segundo caso se deberá aplicar los
principios de reingeniería para posteriormente graficar el sistema
propuesto.
Esquema de análisis y diseño de sistemas
Organigrama: determinar la unidad orgánica de estudio, unidades
relacionadas y límites.
Punto de partida
Para empezar el proceso de descomposición se tiene que basar en la
estructura organizacional de la empresa, la que nos dará una idea de
cuáles son las unidades organizacionales a estudiar y cuáles son las
43
relacionadas, para nuestro caso estudiaremos la Empresa de
Transportes UNIDOS S.A., quien tiene la siguiente estructura.
De hecho que al pasar a construir el árbol de nodos se debe haber
interpretado, los procesos de las unidades orgánicas en mención.
Árbol De Nodos
El árbol de nodos es un esquema que grafica de qué manera se están
desarrollando las actividades del proceso. Estudiado en forma de rama,
para que usted tenga facilidades en la construcción de estas, tendrá
que tener práctica de abstracción de procesos.
Ejemplo de árbol de nodos de la empresa de transporte
GERENCIA
Áreas de Estudio
DEPARTAMENTO
GIROS/ENCOMIENDAS
DEPARTAMENTO
CONTROL DE
UNIDADES
DEPARTAMENTO
PASAJES
Emp. Transportes Unidos (AO)
Sub-Sistema de
Pasajes (A1)
Sub-Sistema de
Giros/Encomiendas (A2)
(A.1.1)
Registrar
Viaje
(A.1.2)
Atención
de Pasajes
(A.1.3)
Preparar
Liq. Diaria
(A.2.1)
Recepcionar
Giros/Encom
(A.2.2)
Entregar
Giros/Encom
44
Diagrama de Descomposición Funcional
Es un diagrama que cumple el mismo objetivo que el árbol de nodos,
con la diferencia que aquí se plasma hasta el mínimo nivel de
abstracción estudiado.
EMPRESA DE TRANSPORTES UNIDOS S.A.
SUB-SISTEMA DE VIAJES
Registrar Viaje
Atención de Pasajes
Preparar Liquidación Diaria
SUB-SISTEMA DE GIROS/ENCOMIENDAS
Recepcionar Giros/Encomiendas
Consultar Flete
Crear Boleta
Elaborar Lista Giros/Encomiendas
Elaborar Informe de Ingresos
Entregar Giros/Encomiendas
Registrar Giros/Encomiendas
Buscar Datos de Destinatario
45
Diagrama IDEF – Nivel 0 (Diagrama de Contexto)
46
47
ANALISIS
DIAGRAMA DE CASOS DE USO
OBJETIVOS GENERALES
- Determinar los requisitos funcionales de un sistema en estudio
documentando el comportamiento del mismo desde el punto de
vista del usuario.
OBJETIVOS ESPECIFICOS
- Determinar los requisitos previos en base a encuestas,
entrevistas para determinar los requerimientos del usuario.
- Planificar la iteración de desarrollo del sistema en estudio.
- Validar el sistema.
INTRODUCCIÓN
Cuando obtenemos los requerimientos de un nuevo sistema,
necesitamos una forma de documentar dichos requerimientos y aun
mas, debido a que el sistema debe cumplirlos, el desarrollo del sistema
debe girar en tomo a ellos. Durante mucho tiempo, tanto en el
desarrollo de Sistemas tradicionales como en los primeros desarrollos
orientados a objeto, los desarrolladores de software se ayudaban de los
escenarios para comprender los requerimientos de un sistema, pero sin
documentarlos debidamente y más bien se llevaba a cabo de manera
informal.
Ivar Jacobson se da cuenta de este detalle y le dio la importancia que
merece. Hacia 1994 propuso los Casos de Uso (Use Cases) como una
técnica formal para capturar requerimientos, que luego se constituyo
48
en un elemento fundamental en la elaboración de requerimientos y Ia
planificación de proyectos. Los Casos de Uso son considerados por
muchos especialistas como una excelente forma de especifica el
comportamiento externo de un sistema, esto es su comportamiento con
el mundo real.
Diagramas de Casos de Uso
Un Diagrama de Casos de Uso representa lo que hace el sistema y
como se relaciona con su entorno, representa los distintos
requerimientos que le hacen los usuarios al sistema, especificando las
características de funcionalidad y comportamiento durante su
interacción con los usuarios u otros sistemas. A dichas funcionalidades
se le conocen como Casos de Uso propiamente dichos, mientras que a
los que provocan su ejecución se les conoce como Actores. Los Casos
de Uso y Actores interactúan produciendo Relaciones.
Debemos hacer notar que los Diagramas de Casos de Uso se basan
en la idea de que la mejor manera de comprender un sistema es
mediante su descomposición funcional, independientemente de los
objetos participantes. En ese sentido los Diagramas de Casos de Uso
se acerca más al análisis estructurado y poco tienen que ver con
entender cómo un conjunto de objetos interactúan. De lo anterior
deducimos que los Casos de Uso son independientes del paradigma de
construcción de software y por lo tanto del lenguaje de programación,
pudiendo utilizarse como punto de partida para diseñar un sistema con
un enfoque estructurado o un sistema con un enfoque orientado a
objetos. Esto le da mayor flexibilidad y es sin duda una de las razones
fundamentales para su amplia aceptación.
Casos de Uso
Un Caso de Uso (Use Case) es una secuencia de acciones
realizadas por el sistema que producen un resultado
observable y valioso para alguien en particular. Todo sistema
49
ofrece a sus usuarios una serie de servicios. Un caso de uso es
justamente una forma de representar como alguien (persona u
otro sistema) usa nuestro sistema.
El Caso de Uso al dar una respuesta a un evento que inicia un
agente externo (llamado actor), debe ser desarrollado en
función a lo que los usuarios necesitan. Un caso de uso es
pues en esencia una interacción típica entre el usuario y el
sistema, aunque un caso de uso también puede ser invocado por
otro caso de uso.
La idea fundamental en los Casos de Uso es definir los
requerimientos desde el punto de vista de quien usa el sistema y
no de quien lo construye. De esta manera, nos aseguramos que
los Casos de
Uso permita conocer los requerimientos del usuario para poder
construir el software y denotan una operación completa
desarrollada por el sistema. Debemos mencionar que se puede
aplicar la técnica de los Casos de Uso a todo el sistema, a partes
del sistema incluyendo a sus subsistemas, o a un elemento
individual como pueden ser las clases e interfaces.
Representación gráfica de los Casos de Uso
Los casos de uso se representan mediante elipses en cuyo interior
se encuentra su nombre.
Representación gráfica de un caso de uso
Nombre
50
Nomenclatura de los casos de Uso
Los casos de uso son acciones que debe realizar el sistema, es
por ello que debe nombrárseles mediante un verbo seguido
por el principal objeto que es afectado por la acción. A
veces es conveniente utilizar un prefijo delante del nombre de
caso de uso, el cual debe indicar el paquete en el que se ubica
(un paquete es un elemento para agrupar a otros), este nombre
es llamado path name, mientras que si solo se muestra el
nombre del caso de uso se le llamará simple name.
Ejemplos de casos de uso con simple name son: colocar
orden, validar usuario, etc., y de casos de uso con path name
serán ventas::ingresar pedido, almacén::despachar
producto, etc., donde ventas y almacén son los nombre dados
a los paquetes que agrupan a los casos de uso ingresar pedido
y despachar producto respectivamente.
Representación gráfica de un actor
Los actores se representan mediante "hombres de palo" (stick
man) tal como se muestra más adelante. Usted puede utilizar los
mecanismos de extensión previstos en el UML para estereotipar
un Actor proveyendo un icono diferente que pueda ofrecer mejor
visibilidad para su propósito. Por ejemplo puede representar un
Actor mediante un rectángulo con el estereotipo «actor».
Recuerde que un actor también es un clasificador y por lo tanto
puede representarse como una clase. Cada tipo actor tiene un
conjunto de especificaciones idénticas a la especificación de una
clase esto es un conjunto de compartimentos, pero con el campo
adicional del estereotipo «actor».
51
Cuando el Actor resulta ser un Sistema se suele representar
mediante una computadora, para resaltar este hecho.
Posibles representaciones de un Actor. El "hombre de palo" es la
más utilizada. La última representación es utilizada solo cuando
se trata de sistemas.
Nomenclatura de un Actor
Ya que para cada caso de uso, pueden existir diversos Actores a
cada uno de ellos se le tiene que asignar un nombre. El nombre
del Actor se escribe debajo del icono que representa a dicho
Actor.
Relaciones en los diagramas de casos de uso
Un diagrama de casos de uso muestra las relaciones entre los
Actores y los Casos de Uso dentro de un sistema. Estas relaciones
pueden ser de los siguientes tipos:
Relaciones de asociación entre actores y casos de uso.
Relaciones de generalización entre actores.
Relaciones de generalización entre casos de uso.
Relaciones incluye (include) entre casos de uso.
Relaciones extiende (extend) entre casos de uso.
Estas relaciones son fuente de confusión así que preste especial
atención a su explicación. ,
En los Diagramas de Casos de Uso, una Relación de
Asociación representa la participación de un Actor en un Caso
de Uso.
<<actor>>
52
Es la más general de las relaciones y la relación semántica más
débil, siempre parte de los actores y viajan en una sola dirección.
A esta relación también se le conoce como relación de
comunicación y suele estereotiparse como <<comunicates>>
aunque esto no es indispensable pues es la única posible entre un
actor y un caso de uso.
Representación gráfica de una asociación
Se representa mediante una línea sólida; como siempre parten de
los Actores hacia los Casos de Uso no necesita colocarse una
cabeza de flecha que indique la dirección.
Relación <<include>>
Al desarrollar un Diagrama de Casos de Uso a menudo nos
encontramos con casos de uso que son incluidos como parte de
otro u otros Casos de Uso, y es que algunos casos de uso pueden
compartir un comportamiento común. Este comportamiento
común es “factorizado” en versiones de casos de uso
especializados.
Una Relación «include» entre casos de uso significa que el caso
de uso base incorpora explícitamente el comportamiento de otro
caso de uso. El caso de uso base siempre utiliza al caso de uso
incluido. El objetivo de la relación «include» es permitir invocar
el mismo comportamiento muchas veces, colocando el
comportamiento común en un caso de uso que puede ser
invocado por otro u otros casos de uso.
De manera general una relación «include», es una relación de
dependencia, puesto que su ejecución depende siempre del caso
de uso; base, pues es este el que invoca. El caso de uso
incluide no puede ejecutarse sin el caso de uso que lo
incluye.
53
La relación «include» es también un ejemplo de delegación,
pues tomamos un grupo de responsabilidades del sistema y los
ubicamos en un lugar (el caso de uso incluido), el cual es
"invocado" por otro caso de uso cuando necesitamos usar esa
funcionalidad.
Observe que la utilización de la relación «include», esta más
ligada al concepto de descomposición funcional (muy común en
los modelos estructurados) que a los conceptos orientados a
objetos. Esto es así, porque los casos de uso solamente nos
sirven para averiguar lo que el usuario necesita del sistema y
no cómo lo hace. Cuando necesitemos conocer más detalles
acerca del caso de uso recurrimos a otros tipos di diagramas que
estén más relacionados con el enfoque orientado a objetos.
Representación gráfica de una relación «include»
Se representa mediante una línea discontinua con una cabeza de
flecha abierta, desde el case de uso base hacia el caso de uso
incluido. La dirección de la flecha significa que "el caso de uso
base incluye al caso de uso incluido".
Nomenclatura de una relación «include»
La flecha es nombrada con la palabra clave «include» y no es
necesario colocarle algún otro nombre.
Casos Típicos
Una Relación «Include» desde una Caso de Uso A hacia
un Caso de Uso B, indica que una instancia de A debe
también incluir el comportamiento especificado por B.
«include»
Representación de una Relación include
54
El comportamiento es incluido junto a la ubicación en la
cual está definida A. Esto significa que cada vez que se
utilice el caso de uso A, siempre se utilizará el caso de uso
B.
Es posible que el caso de uso B, pueda ser invocado por
varios casos de uso, tal como se muestra en el diagrama
adjunto. Esto nos indica que B, es un comportamiento
común a A y C, que ha sido "factorizado" para evitar
definirlo nuevamente, permitiendo su reutilización.
Relación «Extend»
Una relación «extend» entre casos de uso significa que se
ejecuta el caso de uso base pero, bajo ciertas condiciones,
este caso de uso llama a otro caso de uso que extiende el
comportamiento del primero. Esto significa que el caso de
caso de uso base implícitamente incorpora el comportamiento de
otro caso de uso.
Se debe utilizar para modelar la parte del caso de uso que tiene
un comportamiento opcional, así podemos separar el
comportamiento que siempre ocurrirá del comportamiento que
ocurrirá bajo ciertas condiciones.
Para encontrar las relaciones «extend», debemos observar los
casos de uso similares, pero que contengan alguna diferencia en
cómo realizan las operaciones y qué casos de uso redefinen la
A
B «include»
C
«include»
A
B «include»
55
forma de realizar éstas operaciones dentro de otro caso de uso.
Se debe pensar en la conducta normal en un caso y la
conducta inusual en otro caso, unidos por la relación
«extend».
De manera general una relación «extend», es también una
relación de dependencia, puesto que el caso de uso extendido
entra en acción dependiendo de las condiciones que se den al
efectuarse el case de uso base. Recuerde que el caso de uso
extendido, sólo se utilizará bajo ciertas condiciones.
Representación gráfica de una relación «extend»
Se representa mediante una línea discontinua con una cabeza de
flecha abierta, desde el use case extendido hacia el use case
base. La dirección de la relación significa que el caso de uso
extendido extiende al caso de uso base".
Nomenclatura de una relación «extend»
La flecha es nombrada con el estereotipo «extend». La condición
de la extensión es opcionalmente presentada después de la
palabra clave.
Casos típicos
Una relación «extend» desde un Caso de Uso A hacia
un Caso de Uso B indica que una instancia de B puede ser
extendida por el comportamiento especificado por A. El
caso de uso A, será ejecutado cuando al ser ejecutado B, se
den las condiciones que activen a A.
«extend»
Representación de una Relación extend
56
Esta relación está sujeta a las condiciones especificadas en
la extensión. El comportamiento es insertado en la
ubicación definida en el punto de extensión de B, el cual
es referenciado por la relación «extend».
Puntos de extensión en un caso de uso
Una forma de extender la especificación de un caso de uso dentro
de la misma elipse que lo representa mediante una cabecera
denominada Extensión Point. Un caso de uso puede tener más
de un punto de extensión. Dentro de las elipses también se puede
mostrar cornpartimientos presentando atributos, operaciones y
por supuesto puntos de extensión. La descripción de la extensión
normalmente se realizan en texto ordinario, pero también se
puede especificar en otras formas, como un diagrama de estados,
o mediante pre o postcondiciones.
El diagrama adjunto muestra la representación de un caso de uso
extendido y la especificación de las condiciones para que el caso
de uso base sea extendida.
A
B «extend»
Descripción de la Condición
Caso de uso base
Extension points
Descripción de
cuando se
extiende el caso
Caso de
uso
extendido
«extend»
57
Cuándo usar «include» y «extend»
Ambos tipos de relación implican la factorización de
comportamientos comunes de varios casos de uso; sin embargo,
en la relación «include» se trata de factorizar
comportamiento comunes para no repetir la definición y los
casos de uso factorizados pueden ser utilizados por otros casos
de uso; mientras que en la relación «extend» se tienen en
cuenta los factores variantes, esto es casos que ocurren bajo
ciertas circunstancias, poniendo este comportamiento en otro
caso de uso extendiendo al caso base. Se debe organizar los
casos de uso extrayendo el comportamiento común mediante
relaciones «include» y distinguiendo las variaciones mediante
relaciones «extend», con el objetivo de crear un simple,
balanceado y comprensible conjunto de casos de uso para su
sistema.
En la relación «extend» los Actores siguen "conectados" con
los casos de uso extendidos. En la relación «include», es el
caso de uso base el que se "conecta" con el caso de uso incluido
al invocarlo.
Sugerencia:
Utilice «extend» cuando describa una variación de la conducta
normal.
Utilice «include» cuando un caso de uso siempre es usado por
otro ü otros casos de uso y desee evitar repeticiones.
Representación gráfica de los diagramas de casos de uso
Un diagrama de casos de uso muestra el conjunto de actores
externos y los casos de uso del sistema en los cuales esos actores
participan. Los diagramas de casos de uso, contienen iconos
representando actores, casos de uso, asociaciones,
relaciones de generalización, include o extend, y
58
posiblemente elementos de notación (notas o comentarios) y
de agrupación (paquetes). Usted puede crear un nivel superior
de diagrama de casos de uso para visualizar el contexto de un
sistema y el limite del comportamiento del sistema, o crear uno o
más diagramas de casos de uso para describir una parte del
sistema, los casos de uso pueden pues, incluir otros casos de uso
y parte de su comportamiento.
Una especificación de casos de uso permite mostrar y modificar
las propiedades de un caso de uso. Los casos de uso mostrados
en un diagrama de casos de uso se pueden opcionalmente
encerrar dentro de un rectángulo que representa los límites del
sistema.
Documentación de los diagramas de casos de uso
Un diagrama de caso de uso describe lo que hace el sistema,
pero no describe cómo lo hace, al construir los diagramas de
casos de uso se debe tener bien en claro esta separación.
El comportamiento de un caso de uso, puede ser descrito de
muchas maneras dependiendo de la conveniencia, a veces
podemos usar pseudocódigo; sin embargo, comúnmente un caso
<<extend>>
<<include>>
Nombre del Caso de Uso
59
de uso se documenta de manera informal mediante una lista de
pasos que sigue el Actor durante su interacción con el sistema. A
esta lista se le denomina Flujo de Eventos (Flow of Events).
En muchas ocasiones no existe una única vía de ejecución de los
casos de uso pues hay alternativas, aparecen errores o
excepciones. Por ejemplo cuando se desea comprar un producto
que no existe o esta descontinuado, o tal vez cuando el
comprador desea pagar con tarjeta de crédito, efectivo o cheque.
Estas desviaciones al curso normal de los casos de uso se
denominan alternativas, las cuales cuentan con algunas
características que no permiten definirlas como casos de uso,
tales como:
o Representan un error o excepción en el curso normal del caso
de uso.
o No tienen sentido por si mismas fuera del contexto del caso
de uso en el que ocurren.
Una forma de describir el flujo de eventos, es mediante el
siguiente cuadro.
Flujo de Eventos del Caso de Uso:
Actor:
Curso Normal: Alternativas:
Un caso de uso se documenta generalmente con texto informal,
por lo tanto si tenemos que especificar formalmente un
algoritmo, los casos de uso no son los más adecuados, en su
tugar, debemos usar los diagramas de actividad, el moderno
60
heredero de los diagramas de flujo. También podemos utilizar
los diagramas de colaboración y los diagramas de estado.
Dado que los casos de uso son un elemento poderoso durante la
etapa de requerimientos, esto es qué es lo que hace o debe
hacer el sistema, debe tener siempre presente que durante esta
etapa no debería indicar cómo lo hace, para que el análisis no
sea influenciado por la implementación.
Documentación de un caso de uso con la relación
«include»
Para especificar la ubicación en el Flujo de Eventos en el
cual el caso de uso incluye el comportamiento de otro,
usted simplemente debe escribir include seguido del
nombre del caso de uso a incluir, tal como se muestra.
Flujo de Eventos del Caso de Uso:
Actor:
Curso Normal: Alternativas:
……
Include (......)
……
……
Dentro del paréntesis deberá escribir el nombre del caso de
uso a incluir, el cual será documentado con un Flujo de
Eventos propio en una tabla adicional.
Documentación de un caso de uso con relación
61
«extend»
Para documentar el Flujo de Eventos de un caso de uso
que contiene una relación extend, se puede hacer tal
como se muestra:
Flujo de Eventos del Caso de
uso:
Actor:
Curso Normal: Alternativas:
……
(punto de extensión) Si condición entonces
extend(...)
……
……
Debe indicar el punto de extensión tal como se muestra,
mientras que dentro del paréntesis que sigue a extend,
deberá escribir el nombre del caso de uso que extiende la
conducta del caso de uso base. El caso de uso extendido
será documentado con un Flujo de Eventos propio en una
tabla adicional.
Paquetes de casos de uso
Podemos organizar los casos de uso agrupándolos en paquetes de la
misma manera que organizamos otros elementos (como las clases),
pues no es conveniente, atiborrar el diagrama con demasiados casos de
uso, solo debe mostrar la cantidad que el usuario pueda distinguir
rápidamente, recuerde la regla 7+2 clásica de los Diagramas de Flujo
de Datos, la cual nos dice que el hombre puede distinguir desde 5
hasta 9 elementos en cualquier diagrama, esto por supuesto, no debe
62
ser tomado al pie de la letra; sin embargo, no conviene colocar muchos
casos de uso en un mismo diagrama.
Cómo construir los diagramas de caso de uso
Los casos de uso se obtienen hablando con los usuarios y
analizando sus necesidades. Debemos centrarnos primero en los
objetivos de usuario y luego ver que casos de uso los pueden
cumplir. Se recomienda identificar primero a los actores, luego
los casos de uso y finalmente sus relaciones, retinándolas luego
como include, extend, o como de generalización, para
finalmente describir el flujo de eventos de cada caso de uso.
Cómo encontrar los Actores
Para encontrar los actores, debemos realizar los siguientes pasos:
Identificar los usuarios del sistema.
Identificar los roles que realizan estos usuarios desde el
punto de vista del sistema.
Identificar otros sistemas con los cuales exista
comunicación.
Cómo encontrar los casos de uso
Para encontrar los casos de uso, debemos hacernos las siguientes
preguntas:
Cuáles son las principales tareas de un actor.
Que información tiene el actor que consultar, actualizar,
modificar y cómo.
Que cambios del exterior deben, informar los actores
a nuestro sistema.
Qué información debe dar el sistema al actor:
Piense en los eventos ante los cuales el actor debe
reaccionar.
63
Cómo encontrar las relaciones entre actores y casos de uso
Identifique los casos de uso en los cuales se ve implicado un
actor y luego establezca las relaciones entre ellos, este paso debe
ser refinado para encontrar relaciones de generalización, include
y extend.
Describir el flujo de eventos
Debemos describir cada caso de uso, mediante su flujo de
eventos. Recuerde que hay más de una manera de llevar a cabo
un caso de uso, esto es un caso de uso puede tener muchas
realizaciones. Una realización es cada uno de los posibles
modelos que podemos tener para representar los casos de uso.
En muchas ocasiones es conveniente incluir un diccionario con los
términos del dominio del problema, para evitar confusiones
acerca del significado de los términos empleados.
Para sistemas grandes es aconsejable describir el por qué se
desecho una realización para evitar discusiones futuras durante
la revisión de los casos de uso.
EJEMPLOS CASOS DE USO
Ejemplo 3.1:
En un procesador de textos, ¿qué caso de uso sería más adecuado
modelar?
a) Dar estilo al párrafo
b) Dar formato al documento.
Solución:
Dado que el verdadero objetivo para el usuario se cumple cuando
se da formato a! documento, este debería ser e! caso de uso
recomendado. Tal vez cuando se profundice en su detalle sea necesario
64
especificar luego dar estilo al párrafo. Cuando creamos los casos de
uso es mejor centrarnos en los objetivos de usuario más que en la
interacción del usuario con el sistema.
Ejemplo 3.2:
Considere un procesador de palabras. Indique 5 casos de uso típicos y
represéntelos gráficamente.
Solución:
Podemos mencionar los siguientes: crear índice, imprimir documento,
elaborar vista previa, formatear documento, configurar página, entre
muchos otros posibles.
Algunos casos de uso de un procesador de texto
En cada caso de uso se observa que realiza una función visible para el
usuario, cumplen un objetivo puntual, y además puede ser simple o
complejo.
Ejemplo 3.3.
Identifique los Actores en un Sistema de Ventas de un Supermercado.
Solución:
Los compradores, vendedores y cajeros serán actores.
Comprador Vendedor Cajero
Formatear
Documento Configurar
Página
Imprimir
Documento
Elaborar
Vista Previa Crear Índice
65
Ejemplo 3.4:
Suponga que usted es Empleado de un Banco y al mismo tiempo
tuviera una cuenta en dicho Banco. Identifique los actores y diga qué
Actor es usted.
Solución:
Aquí una misma persona puede ser Empleado y Cliente del Banco; así,
podemos observar al menos dos Actores: Empleado y Cliente, usted
será ambos pero dependerá del rol que asuma en un determinado
momento, a veces se comportará como Empleado y otras como
Cliente. Recuerde que un Actor tiene un único rol para cada caso
de uso que se comunica con él, pero un mismo usuario puede jugar
el rol de diferentes Actores.
Ejemplo 3.5:
Si se sabe que un Sistema de Venías provee información al Sistema
Contable, ¿cuál es el Actor y cuál el Sistema?
Solución:
En realidad depende de lo que nos interese modelar en un determinado
momento Si deseamos modelar el Sistema Contable entonces el
Sistema de Ventas será un Actor; mientras que si deseamos modelar
el Sistema de Ventas entonces el Sistema Contable será un Actor.
En ambos casos el actor puede representarse mediante un hombre de
palo mediante el estereotipo de una computadora que representa
un sistema en si, o estereotipada como una Clase, tal como se
muestra en los diagramas adjuntos. Observe que un Actor no
66
necesariamente debe ser un humano, siendo en este ejemplo un
sistema externo al que modelamos.
Ejemplo 3.6:
En una empresa de servicio público se identifica el caso de uso "enviar
factura". ¿Cuál es la implementación que usted escogería y porqué?
Solución:
El Actor debe ser quien obtenga un valor del caso de uso, en
nuestro ejemplo el Departamento de Facturación será el interesado
puesto que el Cliente no se molestaría si no le llega la factura. Por lo
tanto se escoge la implementación B.
Cliente
Enviar
Factura
A
Dpto. de
Facturación
Enviar
Factura
B
67
Ejemplo 3.7:
En una empresa comercial, el Supervisor de Ventas realiza las
funciones de cualquier Vendedor pero además supervisa a otros
vendedores. Muestre los actores y la relación entre ellos.
Solución:
Este es un ejemplo de generalización entre actores. Según el enunciado
el Supervisor de Ventas tiene todo el comportamiento del Vendedor
pero hace algo más, por lo tanto se da una Relación de
Generalización entre ambos, la cual se muestre en la figura adjunta.
Note que el hijo puede remplazar eventualmente al padre.
Ejemplo 3.8:
En un Banco se necesita verificar la identidad de una persona. El caso
general es Validar Usuario, pero esto se puede realizar de diferentes
maneras: comprobando el password, comprobando la huella digital o
tal vez comprobando la retina, todos verifican la identidad pero de
diferentes maneras. Muestre la relación entre estos casos de uso.
Solución:
En este ejemplo se trata de una relación de generalización entre casos
de uso.
68
Validar usuario es el caso de uso general el cual es especializado por
cualquiera de los tres casos de uso mostrados. Debe tener en cuenta
que comprobar retina, comprobar huella o comprobar password,
son formas distintas de validar usuario. No se podría validar usuario
a menos que se ejecute cualquiera de sus formas. Cuando se tiene una
relación de generalización entre casos de uso solo se producirá una de
sus formas.
Ejemplos 3.9:
Una compañía desea vender un activo al crédito. Para ello se debe
analizar el riesgo asociado con el cliente y negociar el precio. En ambos
casos se requiere valorar el activo. Muestre los casos de uso.
Solución:
Se tiene tres casos de uso: Analizar Riesgo, Negociar Precio y
Valorar Activo. Cuando analizamos el riesgo de vender el activo a
un cliente, se debe tomar en cuenta, entre otros factores, el costo del
activo (valorar e activo), por lo tanto Analizar Riesgo incluirá
Valorar Activo.
Cuando negociamos el precio también se necesita conocer i valor del
activo, esto es Negociar Precio incluirá Valorar Activo.
Como podemos observar tanto para analizar el riesgo como para
negociar precio se incluirá Valorar Activo por lo tanto los tres casos
de uso se pueden representar tal como se muestra en el siguiente
diagrama
Vender Activo
69
Note como la relación «include» permite la reutilización de caso de
uso; esto es Valorar Activo se define una sola vez, pero puede ser
utilizado por varios casos de uso, además el caso de uso incluido usa
de todas maneras.
Ejemplo 3.10:
Un sistema típico de ventas puede tener los siguientes casos de uso.
Colocar orden, Preguntar por estado de Orden (para que el cliente
sepa en qué situación se encuentra la misma) y Enviar Orden
(debemos comprobar que el cliente sea quien reciba la orden). Para
cualquiera de los casos de uso indicados, se hace necesario Validar
Cliente, mientras que para Enviar Orden se podrá Enviar Orden -
Parcial, cuando no se puede atender el pedido completo. Muestre estos
casos de uso y las relaciones entre ellos.
Solución:
El siguiente diagrama muestra las condiciones planteadas en el
enunciado.
Observe como un mismo caso de uso (Enviar Orden) puede tener al
mismo tiempo relaciones «include» y «extend». Recuerde la relación
«include» siempre es incluida en el caso de uso base, mientras
que la relación «extend»; ocurre cuando se da una condición para
extender el caso de uso base.
70
Ejemplo 3.11:
Un caso de uso para un sistema de ventas de un centro comercial, será
realizar cobranza. Sin embargo, existen muchas formas de Realizar;
Cobranza, entre ellas realizar cobranza en efectivo, realizar
cobranza con tarjeta de crédito y realizar cobranza con cheque.
Cada una de estas formas de realizar cobranza es un caso especializado
del caso de uso más general. Muestre los casos de uso involucrados y
sus relaciones.
Solución:
Dado que son cada una de las formas particulares de realizar cobranza
se trata de una relación de generalización, tal como se muestra en
el diagrama adjunto. Al realizar cobranza necesariamente se
efectuará una cualquiera de las tres formas.
Una de las alternativas de implementación analizadas, es tratar 3 los
casos de uso del enunciado como relaciones extend, sin embargo
nosotros preferimos la implementación anterior, pues el caso descrito
se ajusta mas al concepto de generalización. Podemos pensar acerca
Realizar
Cobranza
Cobranza con
Cheque
Cobranza en
Efectivo
Cobranza con
Tarjeta de Crédito
71
del por qué no es muy conveniente modelar los casos de uso para este
ejemplo tal como se muestra en el siguiente diagrama.
Ejemplo 3.12:
Existe una diferencia entre escenarios y casos de uso: los casos de
uso muestran los diversos escenarios que pueden ocurrir. Por
ejemplo en un sistema de ventas se pueden presentar dos escenarios:
Que se reciba una orden de compra y que no existan artículos.
Que se reciba una orden de compra y que el crédito sea
rechazado.
Muestre los distintos escenarios para este sistema, utilizando un
diagrama de casos de uso.
Solución:
Un escenario es una secuencia específica de acciones que ilustran un
comportamiento particular de un caso de uso. En otras palabras los
escenarios son los caminos alternativos que puede seguir él flujo de
eventos de un caso de uso. Los escenarios son a los casos de uso lo
que las instancias son a las clases. Esto significa que un escenario es
básicamente una instancia de un caso de uso.
Realizar Cobranza
Punto de Extensión:
Cuando Cliente Paga
Cobrar en
Efectivo
Cobrar con
Tarjeta de
Crédito
Cobrar con
Cheque
<<extend>>
Si efectivo
<<extend>>
Si tarjeta
<<extend>>
Si cheque
72
Los escenarios de un caso de uso pueden representarse en un mismo
diagrama, tal como se muestra.
Observe como un mismo caso de uso puede tener dos o más puntos de
extensión.
Ejemplo 3.13: -
Modele el comportamiento de un teléfono celular que cuenta con las
siguientes características:
Colocar llamadas. Esto incluye llamadas multiusuarios mediante
el servicio de llamadas conferencia.
Recibir llamadas. Considere que puede recibir una segunda
llamada se encuentra ocupado.
El teléfono cuenta con una agenda telefónica.
Solución:
El siguiente diagrama de casos de uso muestra el comportamiento del
teléfono celular. Observe como se ha modelado la Red Celular como
un actor que participa junto con el Cliente en colocar y recibir llamada.
Cliente
73
En este diagrama no se indican los puntos de extensión y su
condiciones con el fin de hacerlo más claro y; además, porqué en este
caso particular, no son del todo indispensables.
Ejemplo 3.14:
Se tiene un sistema de pedidos por teléfono. El Cliente realiza una
llamada comunicándose con el vendedor, el cual verifica su identidad.
Posteriormente, el cliente coloca un pedido de compra con el vendedor.
Dado su naturaleza de venta al crédito, este pedido debe ser aprobado
por el supervisor, el cual también puede actuar como vendedor. Si no
existe inconveniente el despachador, programa la entrega. Construya
un diagrama de casos de uso que represente este proceso.
Solución:
El diagrama del caso de uso Pedidos Telefónicos, muestra las
condiciones dadas por el enunciado.
En el diagrama anterior observe la presencia de la relación de
generalización entre el supervisor y el vendedor.
Ejemplo 3.15:
Se tiene una máquina lavadora de botellas, tarros y bidones. Muestre
los siguientes requerimientos mediante un diagrama de casos de uso.
El cliente deposita los ítems y automáticamente se le entrega un vale.
74
El cliente puede imprimir en cualquier momento un recibo que indique
el ítem depositado y la cantidad.
El operador presiona el botón de comienzo para iniciar el lavado.
El operador desea saber cuántos ítems han sido procesados en el día.
Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
El operador debe además poder cambiar la información asociada a los
ítems y dar una alarma en caso de eventualidad.
Solución:
A continuación se describe la construcción del diagrama de casos de
uso paso a paso.
Paso 1: Los Actores
Como una primera aprobación identificamos a los actores que
interactúan con el sistema: el Cliente y el Operador.
Paso 2: Relaciones de Asociación
Luego tenemos que un Cliente puede Depositar ítems e imprimir su
vale, y un Operador puede cambiar la información de un Item, iniciar el
lavado, sonar la alarma, imprimir el vale para el cliente o generar un
reporte diario.
Paso 3: Relaciones de Generalización
La máquina lavadora debe saber lavar para tres tipos de ítems: lavar
botellas, lavar tarros o lavar bidones.
Paso 4: Relaciones include
Siempre que el cliente deposite items se imprimirá un vale. El operador
al final del día genera un reporte el cual siempre debe ser impreso.
Paso 5: Relacíones-extend
Cuando se esta lavando el Ítem, y éste atora se genera, una alarma.
También se genera una alarma cuando estamos imprimiendo y falta
papel.
75
Paso 6: Juntando las piezas
Entonces, el diagrama de casos de uso completo es:
Cliente Operador
76
77
DISEÑO
DIAGRAMA DE SECUENCIA, COLABORACIÓN, ESTADO Y
ACTIVIDADES
OBJETIVOS GENERALES
- Ilustrar la interacción entre objetos y el orden secuencial en el
que ocurren determinando la comunicación entre los objetos
- Mostrar las interacciones organizadas alrededor de los roles.
- Establecer la secuencialización entre los modelos e integrar la
información con nuestros sistemas.
DIAGRAMA DE SECUENCIA
Concepto.- Los Diagramas de Secuencia permiten graficar los
mensajes que interactúan los objetos para un determinado flujo de una
tarea. Generalmente son utilizados para explicar la secuencia de pasos
que están comprendidos en un caso de uso.
No siempre son usados para la descripción de un caso de uso, se
pueden usar de forma independiente para ir recogiendo la descripción
aislada de los procesos; para después juntar las partes que simulan
armar el rompecabezas, que para nuestro caso sería el modelo.
Nota: Usaremos un ejemplo, ingerir gaseosa por una persona.
Simbología:
Para graficar un diagrama de secuencia, se coloca en la parte superior
a los objetos que estarán involucrados en la secuencia, como por
ejemplo:
: Bebedor : Botella : Vaso
78
Los elementos mostrados, representan a las
instancias u objetos de un grupo, por ejemplo:
Julio y Pedro pertenecen a la clase bebedor, ellos
ingieren la gaseosa. Para representar a Pedro como
instancia de la clase, se representa de la siguiente forma.
Si queremos generalizar, se podría usar:
Tal como se definió en la parte superior.
Luego, se debe graficar la línea de vida para cada uno de los objetos:
Una vez que ya definimos la línea de vida, se debe listar los mensajes
que interactúan, para nuestro caso tenemos:
Coger
Vaciar líquido
Coger Vaso
Ingerir Líquido
Pedro : Bebedor
:Bebedor
: Bebedor : Botella : Vaso
Línea de Vida
79
Colocar los mensajes entre los objetos.
Tipos de Línea de Mensaje
Simple:
Representa al envío de un mensaje sencillo de un objeto a otro,
dentro de la secuencia
Síncrono:
Envío de mensaje de un objeto a otro, pero el objeto que envía el
mensaje espera la respuesta para seguir su flujo.
Asíncrono:
Envío de mensaje de un objeto a otro, no importando que el
objeto emisor tenga que esperar la respuesta para continuar su
flujo.
a:aa b:bb
a:aa b:bb
a:aa b:bb
:Bebedor
Coger
:Botella :Vaso
Vaciar Líquido
Coger Vaso
Levantar e Ingerir Líquido
80
Foco de Control
Es la barra que se ubica sobre la línea de vida de los objetos que
intervienen en la secuencia, donde representa al foco de control
para indicar e! desplazamiento en el tiempo.
Mensaje recursivo, cuando un mensaje recae sobre el mismo
objeto.
Simbología de creación de un objeto y en la parte final se elimina
o destruye.
Bifurcación de mensajes, se desencadena de acuerdo a la
evaluación del criterio o condición.
Inicio de tiempo
Fin de tiempo
a:aa
X
creat
e
a:aa
[ X >= 0 ]
[ X <= 0 ]
81
Iteración de mensajes, indica la forma cómo expresar la
repetición de un mensaje y la condición se coloca dentro de los
corchetes, anteponiendo un *.
Tiempos de transición, se coloca delante de cada mensaje, para
poder expresar los tiempos, cuando los mensajes son
concurrentes.
Visión del Diagrama de Secuencia
a:aa
[Para cada i]
b:bb
t1: Pedir ()
T2: Pedir ()
:a :b
Lapso de
Tiempo
Disposición de
los Objetos
82
Los diagramas de secuencia, manejan 2 dimensiones:
Verticalmente manejan el lapso en que transcurren las
actividades y Horizontalmente se expresan la disposición de los
objetos.
Casuísticas de Diagramas de secuencia.
Mensajes síncronos: El mensaje entre el Pasajero y Vendedora
se expresa como "Solicitar Pasaje", se tiene que dar como
requisito, para luego enviar el mensaje de registro de datos hacia
la hoja de viaje y luego enviar datos de viaje al objeto pasaje.
Mensaje Recursivo: El operador envía el mensaje de marcar
número y el operador tiene que hacer un mensaje recursivo con
la marca de cada uno de los dígitos.
:Operador :Teléfono
Marcar Dígito Marcar Número
:Pasajero
Solicitar Pasaje
:Vendedora :Hoja de Viaje :Pasaje
Registro de Datos Enviar Datos de Viaje
Recoger Pasaje
83
Iteración de Mensajes: El juez envía hasta 3 notificaciones al
implicado.
Bifurcación de Mensajes: El vendedor determina si el diento es
persona natural, le emite una boleta. Si el cliente es una persona
jurídica, le emite una factura.
:juez :implicado
[Envío de Notifica<= 3]
:Vendedora
[Cliente = Persona Natural] Emitir
:Boleta :Factura
[Cliente = Persona Jurídica] Emitir
:Usuario
Ingresa Login
:Interfaz acceso :Tabla
Ingresa
Consulta ()
[login y clave = ok] dar acceso
[login y clave = incorrecto] negar acceso
84
El usuario tendrá que ingresar el login y clave, para después
consultar a la tabla de registro de usuarios, el resultado de la
evaluación se desencadena, la acción de dar o negar acceso
según condición.
DIAGRAMA DE COLABORACIÓN
Definición: Los Diagramas de Colaboración van a mostrar la forma en
que los objetos colaboran para cumplir sus responsabilidades y tienen
la misma función que los diagramas de secuencia.
Entonces, se debe plantear algunas interrogantes: ¿Por qué el UML
necesita de otro diagrama para cumplir la misma función?, ¿no son lo
mismo?, la respuesta es que los dos van a representar interacciones,
con la diferencia que el diagrama de secuencia va a mostrar las
interacciones con la dimensión del tiempo, mientras que el diagrama de
colaboración va a mostrar interacciones de un contexto y organización
general de cómo los objetos interactúan desde el punto de vista del
espacio. Aquí podemos identificar en cada una de las asociaciones la
cantidad de mensajes que interactúan de ida y vuelta entre los objetos,
así como también del tiempo en que se desencadenan, porque cada
uno de los mensajes tiene un número que significa el orden en que
cumple su función.
Simbología
Las instancias de las clases se deben unir con una línea de asociación.
Para nuestro caso tenemos ai "radio escucha" que se asocia con el
receptor.
: Radioescucha : Receptor
85
Luego, se debe ir trabajando graficando los mensajes, siempre
numerados y con las flechas que toman la misma notación o
características de los diagramas de secuencia y se gráfica como sigue:
Se puede enviar varios mensajes de un objeto a otro.
Envío de mensajes a múltiples objetos
Representación de mensajes para devolver valor.
En este tipo de mensaje se expresa la forma cómo interactúan con
parámetros, y en ese mismo mensaje recoger la respuesta con una
variable contenida en el mensaje.
: Radioescucha : Receptor
1: Encender
2: Envío Señal
: Radioescucha : Receptor
1: Encender
2: Cambiar Emisora
3: Apagar
1: Sueldo=CalculoSueldo(idtrabajador) single
: trabajador : planilla
86
Ejemplos:
El ejemplo que presentamos, es la lectura de un libro por parte de un
lector que envía el mensaje de "abrir", para luego leer y extraer el
conocimiento que llegará al lector, luego interpretar párrafo y hacerlo
tantas veces para pasar a sacar resumen y enviar los resúmenes a la
instancia "hoja de resumen", para después enviar el mensaje de cerrar.
DIAGRAMA DE ESTADO
Definición.- Ningún objeto que se interrelaciona en un mundo real se
mantiene estático, un estado representa la característica del objeto en
el tiempo; ¿quién hace cambiar de estado a los objetos?, son los
sucesos o eventos. Por ejemplo, usted como objeto se encuentra
leyendo la presente publicación en su oficina, tiene el estado de
"leyendo'1, pero llega la hora de salida, esto implica que cambiará al
estado "caminando" para salir. Si tiene que viajar a su casa y posee
movilidad, se optará por e! estado de "conduciendo" y/o viajando";
pueden ser ambos estados, entonces aquí habrá estados simultáneos o
concurrentes.
1: Abrir
2: Leer
3: Cerrar
4: Conocimiento
: lector : libro
: Hoja Resumen
5: Resumen
Interpretar Párrafo
87
¿Qué es un Diagrama de Estados?
Tienen la visión de modificación de estados de los objetos en respuesta
a los sucesos en el tiempo. Generalmente un diagrama de estados
muestra las condiciones de un solo objeto.
Simbología
Estado
Se representa por un rectángulo de vértices redondeados.
El símbolo de una línea continua y una punta de flecha con un
círculo relleno, se interpreta como el inicio y una diana representa
el punto final del diagrama. Por lo general se muestra solo el
nombre de estado, ocasionalmente se incluyen las acciones y
eventualmente se incluyen a las variables de estado.
Por ejemplo un estado se puede representar de la siguiente
manera:
El objeto adquiere el
estado de desaprobado,
tiene la variable promedio menor o igual a diez, que es aquella
Nombre
Variables de
estado
Acciones
Desaprobado
Promedio <= 10
Entra : Programar Sustitutorio
Mientras: no Promover Grado
Salir : Crear acta de
Recuperación
88
que toma al encontrarse en el estado, y en la parte inferior se
considera a las acciones a seguir. Cuando entra: Programar
Examen Sustitutorio. Al salir: Crear acta de recuperación y
mientras tiene el estado no podrá promoverse de grado.
Otro ejemplo de elementos de estado.
Analizamos el estado de un aportador a una entidad de seguro.
Un aportador ingresa al estado de jubilado, para nuestro caso lo
rotulamos en la primera parte. En el área de variables debe
cumplirse que el objeto aportante tendrá la edad de mayor o
igual a 60 años y las acciones a seguir son:
Al entrar: Calcular Monto de cobertura, mientras tiene el
estado, dar mensualidad; cuando sale del estado asignar
beneficios de cobertura de seguro.
Representación de acciones
Las acciones que se disparan cuando se toma, un estado están
comprendidas por:
Entrada.- Indicar qué es lo que pasa cuando el objeto entra al estado.
Mientras.- hacen referencia a lo que pase mientras se tiene el estado.
Salida. ¿Qué acciones se siguen cuando se sale del estado?
Jubilado
Edad >= 60
Entra : Calcular Monto de
Cobertura
Mientras: Dar Mensualidad
Salir : Asignar Beneficios de
Cobertura
89
Ejemplo:
Para explicar el ejemplo de los estados que tomará un cliente dentro
del universo de una empresa de telefonía. En primer lugar tendrá el
estado de habilitado, al no pagar el recibo de servicio, adquiere el
estado de moroso y dentro de éste se desencadenan las acciones de:
Cortar línea, cuando entra al estado y mientras tiene el estado se le
niega el servicio telefónico, cuando sale del estado con el suceso de
pago d& recibo, se le activa la línea telefónica.
Sub-Estados.- Vienen a sor las transiciones internas que tienen
los objetos mientras adquieren un estado y se clasifican en sub-
estados secuénciales y concurrentes.
Sub Estados Secuénciales.- Se dan uno después del otro y lo
explicamos con un ejemplo:
Me he ubicado solo en dos estados de lo que obtendrá un
empleado en su centro de labores. Inicialmente e identificado el
estado "trabajando" y el suceso de inicio de tiempo de descanso,
Moroso
Entra : Cortar Línea
Mientras: Negar Servicio
Telefónico
Salir : Actuar Línea
Habilitado No Paga
Recibo
Efectúa Pago
Recibo
Trabajando Almorzando Inicio de
Tiempo de
Descanso
Término de
Tiempo de
Descanso
90
quien origina el estado de almorzando, el cual comprende tres
sub estados que les muestro a continuación.
El sub estado de solicitante, se da cuando el empleado está
pidiendo en el comedor sus alimentos; luego el obtiene el sub
estado de comiendo al recibir los alimentos, para cuando termina
pasará al estado de "en reposo". Todos estos sub estados
representan a la transición del objeto dentro del estado
almorzando.
El Sub Estado Concurrentes.- Son aquellos que representan al
comportamiento del objeto dentro del estado cuando se manejan
estados internos que se desencadenan en forma simultánea. Se
grafican en la parte inferior del área de estado debajo de una
línea media discontinua.
Como puede observar, los sub estados concurrentes se realizan al
mismo tiempo, porque para nuestro caso, mientras el empleado
almuerza puede estar escuchando música y al mismo tiempo
puede estar pensando una solución.
Solicitante Comiendo Sirven
Alimentos En Reposo Termina
de Ingerir
Alimentos
Solicitante Comiendo Sirven
Alimentos En Reposo Termina
de Ingerir
Alimentos
Escuchar
Música
Pensando
Solución
91
Estados Históricos.- Permiten retomar un sub estado, cuando
se haya salido por alguna situación y se simbolizan con la "H"
dentro de un circulo y muestra que un estado recuerda el sub
estado activo de donde salió para poderlo retomar.
Quiere decir que el estado histórico de solicitante lo podrá
retomar después de haber obtenido el incidente que se originó en
la empresa.
Ejemplos:
1. Caso de Libro do Biblioteca
El objeto libro inicialmente se ubica en el estado de estar "En
estante", para después desencadenar el suceso de solicitar
préstamo y entra al estado de "En sala". Se desencadenan las
Solicitante Comiendo Sirven
Alimentos En Reposo Termina
de Ingerir
Alimentos
Oyendo
Música
Pensando
Solución Lapso de
Estado
Lapso de
Transición
Llamada por
Incidente en
la Empresa
H
En Estante
En Sala
Entra: Presentar Carné Lector
Mientras: No Admitir Préstamo
Salir: Entregar Carné Lector
Devuelto
Solución Préstamo
Fin
Inicio
Requerimiento de
Ordenar Libro
Cumple Tiempo
de Lectura
92
acciones al entrar se retiene carné de lector, mientras se tiene el
estado no admitir préstamo, al salir se entrega el carné de lector.
2. Situaciones de estados de un trabajador
EI objeto se encuentra inicialmente en el estado "trabajando", el
suceso de cumplir 1 año de servicio entra al estado de
"vacaciones", cuando cumple el tiempo de vacaciones retorna el
estado de "trabajando". Si pide una dispensa obtiene el estado de
"permiso", cuando cumple el tiempo de dispensa retoma el
estado de "trabajando". Si se le asigna una tarea extra entra al
estado de "comisionado", cuando cumple la tarea extra vuelve al
estado de "trabajando"; por último cumple con tiempo de
servicio, entra al estado de "jubilado".
Jubilado
Trabajando
Permiso
Cumple
Tiempo
Servicio
Comisionado
Vacaciones
Cumple
Tarea Extra
Asigna Tarea Extra
Cumple Tiempo de Vacaciones
Cumple Año de Servicio
Solicitud
Dispensa
Cumple tiempo de
Dispensa
93
Ejemplo sub estados de un paciente
El presente diagrama del paciente se inicia en el estado
"esperando", que se da cuando el paciente espera cupo o cama
para ser alojado en el hospital. Cuando entra al estado de
"hospitalizado" se desencadenan 3 sub estados secuenciales que
son: "observado" que consiste en tomar las pruebas, cuando
ejecutan intervención pasa al sub estado de "operando", luego
que termina la intervención entra al sub estado de "recuperación"
pudiendo retroalimentarse con el sub estado de "observado", al
salir de este estado pasa al estado de "alta".
Esperando Hospitalizado Obtiene
Disponibilidad
Cupo
Alta Sin Riesgo
Observando Operando
Ejecutan
Intervención
Recuperación
Término de
Intervención
94
DIAGRAMA DE ACTIVIDADES
Definición.- Al mirar los diagramas de actividades le traerá a la
memoria los diagramas de flujo, que sirven para poder gradear la
lógica de cómo se daría solución a un problema de programación.
El presente diagrama nos permitirá explicar las actividades que
describen a los procesos para que sean atendidos por los propietarios
de los mismos, así como también los implementadores de software, los
diagramas de actividades contienen bifurcaciones, así como también
barras de sincronización y las actividades propiamente dichas.
Las barras de sincronización, indican que las actividades que se
encuentran comprendidas, se estarán dando al mismo tiempo
Señal de envío de mensaje hacia un objeto representada por un
pentágono convexo que apunta al objeto
Actividad
Bifurcación
Inicio y fin
Simbología
Señal Objeto
95
Señal que permite recepcionar la señal del objeto y está representado
por un pentágono cóncavo.
Los diagramas de actividades han sido creados para poder presentar
una visión de las tareas que se desarrollan en un determinado proceso,
generalmente van a permite escribir las actividades que se disparan en
la transición de un estado a otro. Lo que se representa por una flecha
en el diagrama de estado, tendrá su descomposición con el diagrama
de actividades.
No solo se usa en esta situación, sino tiene usted la libertad de
poderlos usar en el modelado de un determinado flujo. Si usted ha
realizado análisis estructurado, estos diagramas son los equivalentes al
flujo-grama. Existen clientes que se familiarizan con estos diagramas y
en algunos casos, yo particularmente los uso como principales paro
luego, ir armando el rompecabezas del modelo.
Transición de actividad a otra
Después de ejecutar una actividad se conlleva a una siguiente.
Señal Objeto
Actividad 1
Actividad 2
Actividad 3
Después de Ejecutar una
Actividad se conlleva a una
siguiente
96
Decisiones
El símbolo de decisión, le permite bifurcar la secuencia del diagrama
de acuerdo a las condiciones planteadas
Representación de actividades que se realizan al mismo tiempo.
El símbolo de
decisión nos
permite bifurcar
la secuencia del
diagrama de
acuerdo a las
condiciones
planteadas
Adquisición de
Software
Gestionar
Adquisición
Dar
Mantenimiento
Convocar a Grupo
de Proyecto
Planificar
Ejecutar Proyecto
[Desarrollo]
[Compra]
Comprar
Entradas
Comprar
Golosinas
Ingerir
Golosinas Ver Película
Ingerir
Golosinas
97
Las actividades Ver Película e Ingerir golosinas se realizan al mismo
tiempo Ias actividades de produciendo ítem y promocionando se
realizan en forma simultánea.
' .
Envío de Señal
El presente diagrama de actividades explica los pasos a seguir para
tomar una fotografía; permitiendo enviar un mensaje al objeto cámara
cuando se dispara el botón y la cámara tiene que capturar la imagen.
Comprar
Insumos
Promocionando Produciendo
Elementos
Vender
98
Creadores de Patrones
Cuando se inició la oleada del UML, participaron varios expertos, cada
uno con proyectos de metodología de desarrollo, liderando como es
conocido los "tres amigos", pero dentro de estos participantes
estuvieron: Erich Gamma, Richard Helm, Ralph Johnson y John
Vlissides que aportaron las Reglas o Patrones para UML; a estos
señores se les conoce como la Pandilla de los Cuatro(Gang of Four -
conocidos por "GoF"), quienes publicaron su libro Design Patterns en el
año de 1995 difundiendo 23 patrones.
¿Qué es un contrato?
Booch y Rumbaugh definen la responsabilidad como "Un contrato u
obligación de un tipo o Clase".
Es aquí donde se documentarán las operaciones asignadas a cada una
de las clases, las cuales servirán como herramientas para la
construcción, del sistema orientado a objetos.
Formato del Contrato
Nombre Se coloca el nombre de la
operación con sus parámetros,
si lo tuviera.
Responsabilidades Se definen las
responsabilidades que tendrá
la operación.
Tipo Podrá ser de sistema/usuario.
Referencias
Cruzadas
Aquí colocará las referencias
de los diagramas de donde
viene la responsabilidad y
adonde va.
Notas
99
Excepciones
Salida Datos de salida.
Precondiciones Condiciones antes de la
operación.
Poscondiciones Condiciones después de la
operación.
Patrones GRASP
General Responsability Assignments Software Patterns (Patrones
Generales de Software para Asignar Responsabilidades)
Patrón Experto
Solución
Asignar una responsabilidad al experto en información
necesaria para cumplir la responsabilidad.
Problema
¿Cuál es el principio fundamental en virtud del cual se
asigna las responsabilidades en el diseño orientado a
objetos?
Ejemplo
Calcular gran total de la Boleta
1. Total("NumeroBoleta")
Boleta
NumeroBol
Fecha
Total()
DetaBol
NumeroBol
CodProd
Cant
PuVenta
Importe
SubTotal()
Boleta DetaBol
100
Ejemplo de Contrato Para Total
Nombre
Responsabilida
des
: Total("NumeroBoleta")
: Hallar el total de la Boleta, para, tal caso
deberá sumar los importes de la clase
"Detabol".
Tipo
Referencias
Cruzada
: Sistema 3: Caso de Uso Comprar
Producto.
Notas
Excepciones
: Si el número de boleta, no Existe;
entonces, presentar un mensaje de error.
Salida
Precondiciones
: La Boleta deberá contener al menos un
producto y deberá estar activa.
Poscondiciones
Es la responsabilidad so la asignamos a la clase Boleta, porque
esta delegará sub-operaciones a las clases acopladas para que
cumplan el fin propuesto.
Patrón Creador
Solución
Asignarle a la clase B la responsabilidad de crear una instancia de
clase A en uno de los siguientes casos:
B agrega los objetos A
B Contiene los objetos A
Problema
¿Quién debería ser responsable de crear una nueva instancia a la
clase? El ejemplo explica quien tiene la responsabilidad de
ingresar una instancia a la clase DetaBol, aplicando este patrón la
tendrá la clase Boleta.
101
Ejemplo de Patrón Creador
Patrón Agente Dispositivo (Pandilla de los Cuatro)
Solución
Definir una clase que representa al dispositivo y asignarle la
responsabilidad de interactuar con él.
Problema
Se requiere interactuar con un dispositivo electromecánico. ¿Qué
hacer?
Para el caso se implementa la clase Lector de Tarjeta
"LectorDeTarjeta", porque existe un dispositivo que se acoplará al
sistema y es en esta clase donde se deben manejar las
operaciones para la manipulación del dispositivo que interactuará
con el sistema.
Patrón Comando (Pandilla de los Cuatro)
Solución
En cada comando, definir una clase que lo represente y asignarle
la responsabilidad de ejecutarse él mismo.
Boleta
DetaBol Boleta
Numero Bol
Fecha
Total()
InsertaProductoDetaBo
l
Se hace uso del
concepto de
Agregación
InsertarProductoDetabo(numeroBoleta,CodPro,Cantidad)
LectorDeTarjeta
LeerNumero
DispositivoLectordeTarjeta
102
Problema
Un objeto o sistema puede recibir varias peticiones o comandos.
Reducir la responsabilidad del receptor en el manejo de los
comandos, aumenta la facilidad con que pueden agregarse otros
comandos y ofrece las bases para registrar los comandos, para
formar colas de espera con ellos y para cancelarlos (deshacerlos).
Es una combinación del patrón Experto con Polimorfismo.
Hagamos un ejemplo de cómo funciona este patrón con respecto
al uso de una aplicación en Windows; por ejemplo usted puede
tener abierta la aplicación de Word varias veces, pero ¿Cuántos
archivos ejecutables de la aplicación tiene? Sólo uno, para este
caso se instancia la aplicación varias veces con todas sus
operaciones, para no congestionar el sistema.
aplicacionWord
abrirDocumento()
aplicacionWord
abrirDocumento()
cerrarDocumento()
aplicacionWord
abrirDocumento()
cerrarDocumento()
aplicacionWord
abrirDocumento()
cerrarDocumento()
103
DIAGRAMA DE CLASES
OBJETIVOS GENERALES
- Construir un conjunto de clases a partir de los objetos
determinados dentro de los procesos considernado sus
características y comportamientos así como sus relaciones.
OBJETIVOS ESPECIFICOS
- Cubrir la vista estática de un sistema tomando en cuenta la
estructura estática y el conjunto de clases y objetos de clases
que conforman un sistema
- Determinar las relaciones existentes entre los objetos
determinados, sin considerar su actuación ni los mensajes que se
envían.
INTRODUCCIÓN
La Clase es el elemento de más amplia aceptación en la comunidad de
desarrolladores de software orientado a objetos. Una Clase es un
conjunto de cosas que tienen los mismos atributos y comportamiento.
Representan aquello que siempre está presente y que en su ausencia
nuestro sistema difícilmente funcionaría. Cada una de las ocurrencias
de una clase constituye un Objeto. Las clases poseen atributos y
comportamiento y cada objeto perteneciente a una clase tiene atributos
con valores conocidos.
El conjunto de clases y sus relaciones forman los Diagramas de
Clase, el diagrama más importante y más común de todas las
metodologías de desarrollo, incluyendo la Metodología Estructurada,
104
pues un Diagrama de Clases es básicamente un modelo
Entidad/Relación evolucionado.
Los Diagramas de Clases muestran la Vista Estática del sistema e
indican las Clases que intervienen en él y como se relacionan con otras
clases para cumplir los objetivos del sistema.
Las clases se irán descubriendo a medida que avance en la
comprensión del sistema y, el Diagrama de Clases se irá construyendo
paulatinamente conforme identificamos las clases y sus relaciones.
Diagrama de Clases
Muestran un conjunto de clases (grupos de objetos que tienen las
mismas características y comportamiento), así como sus relaciones.
Estos diagramas son los más comunes en el modelado de sistemas
orientado a objetos y cubren la vista estática de un sistema. Un
diagrama de estructura estática muestra el conjunto de clases y
objetos de clases y objetos importantes, que conforman un sistema,
junto con las relaciones existentes entre los mismos, pero no como
actúan unos con otros, ni que mensajes se envían.
Un diagrama de clases está compuesto por los siguientes elementos:
Clases: Las cuales contienen atributos y operaciones.
Relaciones: Que pueden ser dependencia, generalización y asociación.
Diagrama de Objetos
Dado que las Clases son agrupaciones de cosas necesitamos un
diagrama que nos muestra las ocurrencias de cada elemento que
constituye la clase, a cada uno de estos elementos se les llama
Objetos.
Un Objeto se define como una instancia de una clase. Así, estas
ocurrencias se representan mediante un Diagrama de Objetos.
Los diagramas de objetos muestran un conjunto de objetos y sus
relaciones, son como fotos instantáneas de los diagramas de clase y
105
también cubren la vista de procesos estática desde la perspectiva de
ocurrencias reales o prototípicas.
Clase
Una Clase es un conjunto de objetos que comparten los mismos
atributos, operaciones y semántica. En otras palabras una clase
describe un conjunto de objetos con características y
comportamiento idéntico, se puede decir que las clases son como
una plantilla para formar objetos. Las clases sirven para abstraer
objetos del mundo real y a través de ella podemos modelar el entorno
en estudio. La Clase es un concepto similar a Entidad en un modelo
entidad/relación esto es "un conjunto de objetos que tienen las
mismas características". Sin embargo, al concepto de Clase a
diferencia del concepto de Entidad, se le ha agregado el
comportamiento, incluyendo las operaciones que puede realizar a
través de sus métodos.
En realidad, las clases que seleccionemos corresponden al dominio del
problema que deseamos resolver. Debemos enfocar nuestra atención
sólo a las clases, sus atributos y comportamiento que nos permitan
resolver el problema. Cualquier conjunto de objetes presentes en
nuestro sistema constituyen una clase. También debemos mencionar
que estas clases no existen aisladas sino que se relacionan entre ellas.
Representación Gráfica
En UML, una clase es representada mediante un rectángulo por lo
general con tres divisiones internas llamadas compartimientos, en
los cuales se indica el nombre de la clase, sus atributos y operaciones,
tal como se muestra en el diagrama y en donde:
106
NombreClase
atributoUno
atributoDos
….
operaciónUno
operaciónDos
….
Compartimiento Superior: Contiene el nombre de la Clase
Compartimiento Intermedio: Contiene los atributos que caracterizan
a la Clase.
Compartimiento Inferior: Contiene las operaciones, los cuales son la
forma cómo interactúan un objeto de la clase con su entorno
Adicionalmente, podemos colocar otros compartimientos en los cuales
se pueden describir, en texto libre, otras características de las clases
como pueden ser sus responsabilidades, esto es, los objetivos que
persigue la clase. No es necesario mostrar todos los compartimentos a
la vez, sino que más bien depende de lo que queramos visualizar en un
momento determinado, dejando a la herramienta de software que nos
muestre u oculte las partes según nuestra conveniencia.
A continuación describiremos cada uno de los tres compartimientos
estándar:
PRIMER COMPARTIMIENTO
Contiene el nombre de la Clase y opcionalmente su multiplicidad.
Nombre
A cada clase debemos asignarle un nombre que nos de una idea de lo
que representa. Se acostumbra a escribir la primara letra del nombre
de la clase en mayúsculas.
107
Un nombre es solo una cadena de caracteres que puede ser escrito de
dos formas: como simple name, que muestra solo el nombre de la
clase; o como path name o class path name, en donde se
muestra además del nombre del paquete al cual pertenece la clase
(los paquetes sirven para agrupar objetos según conveniencia).
Multiplicidad de la Clase
Sirven para indicar la cantidad de objetos que puedo tener una clase.
La multiplicidad de clases se indica mediante un número en la esquina
superior derecha del rectángulo que representa la clase y por lo general
no suele indicarse
SEGUNDO COMPARTIMIENTO
Contiene los atributos de la clase, mostrando su visibilidad, nombre
mutiplicidad, tipo de dato, valor inicial, etc.
Atributos
Un atributo representa alguna propiedad de los objetos que estamos
modelando, y que son compartidos por todos los objetos de una clase.
Los atributos se representan en un compartimiento debajo del nombre.
Los atributos pueden ser representados solo mostrando su nombre.
Se acostumbra a colocar en mayúscula la primera letra de cada palabra
en el nombre del atributo a excepción de la primera letra.
NombreClase
NombrePaquete::NombreClase
simple name
Path name
NombreClase
Nro
108
NombreClase
atributoUno
atributoDos
….
Especificando atributos
Podemos mencionar solo el nombre del atributo o especificarlo al nivel
de detalle que necesitemos. Así, para cada atributo además del
nombre, podemos indicar la visibilidad, la multiplicidad, el tipo, el valor
inicial, la cambiabilidad de cada atributo y el alcance, según la siguiente
sintaxis:
Sintaxis:
[visibility] name [multiplicity]: [type] [= initial-value] [{property-
string}]
Visibilidad de los atributos
Los Atributos de una Clase pueden ser accesibles por:
Todas las clases.
Las clases en las que son definidas
Las clases en las que son definidas y por sus descendientes
A esta característica se le llama visibilidad (visibility). Hay tres tipos de
visibilidad:
public (+): Indica que el atributo será visible tanto dentro como fuera
de la clase, es decir, será accesible desde todos lados. Para indicar que
un atributo es público se coloca el signo + delante del nombre del
atributo.
private (-): Indica que el atributo sólo será accesible desde dentro de
la clase, esto significa que sólo sus métodos lo pueden accesar. Para
indica que un atributo es privado se coloca el signo - delante del
nombre de atributo.
109
protected (#): Indica que el atributo será accesible por métodos de I
clase en la que se define, además de las subclases que se deriven de
ella. Para indicar que un atributo es protegido se coloca el signo #
delante d nombre del atributo.
Cuando la visibilidad no está especificada se asume que public, pero
siempre es mejor indicarla pues las herramientas de software a
menudo permiten ocultar algunos detalles, como la visibilidad, dando
lugar a posibles confusiones.
En el diagrama adjunto seobserva que atributoUno y atributoDos
son públicos, mientras que atributoTres es privado y atributoCuatro
es protegido.
NombreClase
+atributoUno
+atributoDos
-atributoTres
#atributoCuatro
Multiplicidad (multiplicity) de los atributos
Muestra la cantidad de veces que el atributo se repite. Se coloca
inmediatamente después del nombre del atributo encerrado entre
corchetes.
En el diagrama adjunto se muestra que atributoTres es privado y
tiene una multiplicidad de 0, 1, 2 ó 3.
NombreClase
+atributoUno
+atributoDos
-atributoTres
[0…3]
110
El tipo (type) de los atributos
Es el tipo de dato que tiene el atributo. Los tipos de datos
realmente dependen del lenguaje de programación; sin embargo,
se pueden indicar cualquiera de los tipos de uso común, tales como int,
char, float, double, date, string, etc.
Si el atributoUno fuera string,el atributoDos int y el atributoTres
date, entonces los atributos y sus tipos de datos se representarán como
se muestra en el diagrama adjunto.
Valor inicial de un atributo
En muchos casos es útil especificar el atributo con un valor inicial, el
cual se utilizará por defecto si es que no se le indica un valor al operar
con él. Con esto, se podrá evitar problemas de inconsistencia de datos
cuando no se conoce el valor y por defecto haremos que asuma un
valor. Por ejemplo, podemos utilizarlo cuando deseamos que un
atributo asuma la fecha actual, o tal vez el código de usuario, o tal vez
una cantidad de artículos por defecto, o un número correlativo de
transacción, entre muchos otros posibles.
En el diagrama adjunto se muestra que atributoUno de tipo cadena,
asumirá el valor del nro de movimiento, atributoDos de tipo entero
será 1 unidad, atributoTres podrá tener hasta tres valores cada uno
inicializado en su debida oportunidad con la fecha actual.
Cadena de propiedades (property string)
Es un conjunto de propiedades que indican el grado de cambio que
pueden sufrir los atributos. Estos son:
Changeable, se utiliza para indicar que no existen restricciones para
modificar los valores de los atributos.
AddOnly se usa cuando los atributos tienen una multiplicidad mayor
que 1, y significa que pueden añadirse mas valores, pero una vez
creados los valores no pueden ser removidos ni alterados.
111
Frozen, los valores de los atributos no pueden ser cambiados después
que el objeto fue inicializado. Se usa para definir constantes o cuando
se graba un valor por una sola vez. Por ejemplo, cuando grabamos la
fecha y hora de una transacción.
En caso de no especificarse ningún tipo, el atributo se considera
Changeable.
Si por ejemplo el atributoUno es la clave primaria, la cual, viene dada
por un número correlativo (en formato cadena) que el sistema genera,
entonces podrá modelarse como {frozen}. Si el atributoDos puede
ser modificado sin restricciones entonces será {changeable}. Si el
atributoTres tiene multiplicidad mayor que uno (por ejemplo 0..3) y
se desea guardar todos los valores ingresados, entonces será
{addonly}. Esto se muestra en el diagrama adjunto:
En la mayoría de casos no se acostumbra a utilizar esta especificación,
así que usted es libre de hacerlo.
Alcance de los atributos
Es otro importante detalle que podemos especificar en los atributos ral
de una clase. En UML podemos especificar dos tipos de alcances:
De Clase.- El valor que toma el atributo tiene alcance de clase
cuando existe un único valor que es válido para todas las instancias de
NombreCIase
+ atributoUno : string =
nromvmto(frozen)
+ atributoDos : int =l
(changeable)
- atributoTres [0..3]: date-=Fecha
(addonly)
…
112
la clase. El ámbito de clase se representa subrayando la definición del
atributo.
De Instancia.- El valor que toma el atributo tiene el alcance de
instancia cuando sólo es válido para dicha instancia. Si el atributo no
está subrayado significa que tiene alcance de instancia.
El uso más común del Alcance es para atributos privados que deben ser
compartidos entre un conjunto de instancias; esto es, todas las
ocurrencias de este conjunto tienen el mismo valor de atributo y
garantiza que otras instancias no tienen acceso a este atributo.
En el diagrama adjunto el atributoTres tiene ámbito de clase.
TERCER COMPARTIMIENTO
Contiene las operaciones que pueden realizar los objetos de una clase,
mostrando su visibilidad, nombre, lista de parámetros, tipo de dato
retornado, valores por defecto y el alcance de las operaciones.
Operaciones
El conjunto de operaciones describen el comportamiento de los objetos
de una clase; es decir, cómo una clase interactúa con su entorno.
Se representa en el tercer compartimiento del rectángulo que identifica
a la clase.
NombreClase
operacionUno
operacionDos
operacionTres
….
NombreCIase
+ atributoUno : string =
nromvmto(frozen)
+ atributoDos : int =l
(changeable)
- atributoTres [0..3]: date-=Fecha
(addonly)
…
113
Es conveniente hacer la distinción provista por UML respecto a
operaciones y métodos. Una operación representa el servicio que
puede ser requerido por una instancia de la clase y que afecta su
comportamiento. Un método es la implementación de una operación,
esto es la forma específica de cómo lleva a cabo la operación.
Todas las operaciones que no sean abstractas (aquellas que solo se
definen su nombre pero que no se implementan) deben tener un
método. Cuando entra en acción la herencia pueden haber muchos
métodos para la misma operación, esto se conoce como polimorfismo.
El mecanismo de herencia selecciona el método adecuado para la
operación escogida de la subclase que lo requirió.
La sintaxis de las operaciones en UML es similar a la de los
atributos, tal como se muestra:
[visibility] name [(parameter-list)]: [return-type] [{propety-string}]
Visibilidad de las Operaciones
Una Clase tienen un conjunto de operaciones que pueden ser invocados
por todas las clases del sistema, solamente por ella misma, ó por ella
misma y sus clases descendientes. Para esto se debe especificar la
visibilidad de las operaciones, las cuales pueden ser:
public (+): Indica que la operación será visible tanto dentro como
fuera de la clase, es decir, pueden ser invocados desde todos lados.
private (-): Indica que la operación sólo será accesible desde dentro
de la clase. Solamente la clase en la que está definida la operación
puede Invocarla.
protected (#): Indica que la operación no será accesible desde fuera
de la clase, pero podrá ser invocada por la clase en la que se define, y
además por las subclases que se deriven de ella.
114
El diagrama muestra qué operación puede ser invocada por todas las
clases, operación2 solo puede ser invocada por Clase1, mientras que
operación3 podrá ser invocada por Clase1, C!ase2 y Clase3, pero no
por Clase4 ni por Clase5.
Lista de parámetros (parameters list)
Normalmente cada operación necesita utilizar parámetros y/ó devolver
valores después de haber realizado la tarea encomendada. Los
parámetros van separados por comas y cada parámetro tiene la
siguiente sintaxis:
[direction] name: type [=default-value]
La dirección (direction) puede ser cualquiera de los siguientes valores:
in.- Cuando se trata de un parámetro de ingreso a la operación, el cual
no puede ser modificado por ella.
out.- Cuando la operación modifica el valor del parámetro para
comunicar alguna información al programa que lo invocó.
inout.- Cuando el valor del parámetro de entrada puedo ser modificado
(durante la ejecución de la operación.
En la siguiente expresión se muestra la operación1 de visibilidad
pública con 3 parámetros, par1 de ingreso, y que no puede ser
modificado par2 de salida y que puede cambiar de valor y ser
Clase 1
+ Operación1
- Operación2
# Operación3
Clase 4
Clase 5
Clase 2
Clase 3
115
reconocido fuera de operación1 y, par3 un parámetro de entrada que
puede ser modificado:
+operación1 (in par1, out par2, inout par3)
El tipo (type) indica el tipo de dato del parámetro, el cual puede ser
cualquiera de los tipos estándar conocidos. En la siguiente expresión se
indica que par1 será tipo int, par2 tipo date y par3 tipo char.
+operación1 (in par1: int, out par2: date, inout par3: char)
El valor por defecto (default valué) indica el valor que asumirá el
parámetro cuando al invocar la función, no se indica su valor. A
continuación se muestra una expresión en donde par1 asumirá el valor
de 5 y par3 el valor de '0', siempre que no se indiquen los valores
respectivos al invocar la operación.
+operación1 (in par1: int=5, out par2:date, inout par3:char='0’)
El tipo de retorno (return-type) de las operaciones
La operación puede o no retornar valores, el tipo de retorno es
justamente el tipo de dato del valor retornado.
Observe con atención la siguiente expresión:
+operación1 (in par1: int=5, out par2:date, inout
par3:char='0’): string
Aquí, operación1 con visibilidad pública (+), tiene tres parámetros, .
par1 de ingreso y tipo entero que será inicializada a 5 si es que no se le
indica el valor en la llamada a la operación; par2 de salida esto es, un
parámetro cuyo valor será modificado al ejecutarse operación1
116
pudiendo ser utilizado por el programa que lo invocó y es del tipo date
y; par3 es un parámetro cuyo valor puede ser modificado por
operación1, es del tipo char y tomará el valor de '0' cuando no se le
indique un valor al invocar a la operación: Finalmente, el tipo de dato
del valor retornado es un string.
El valor por defecto (default value) de las operaciones
[=default value] indica el valor por defecto que asumirá la operación, si
es que no se le indica el valor que debe retornar.
En la siguiente expresión operación1 retornará por defecto la cadena
"hola", a menos que durante la ejecución de la operación se le indique
que retorne otro valor para la cadena.
+ operaciónl( ) : string = '"hola"
Alcance de las Operaciones
En UML podemos especificar dos tipos de alcances o ámbito para las
operaciones:
De Clase.- Son aquellas que sirven para toda la clase, tales como las
que crean las instancias de clase (constructor). El ámbito de clase se
representa subrayando la definición de la operación.
De Instancia.- Las operaciones tienen alcance de instancia cuando son
válidas sólo para las instancias. Si la operación no está subrayada
significa que tiene alcance de instancia.
En el diagrama adjunto la operacionDos tiene ámbito de clase, mientras
que las otras dos tienen alcance de instancia.
Polimorfismo y operaciones polimórficas
En muchas ocasiones, debido a su naturaleza, es necesario que las
clases respondan de manera distinta ante el mismo mensaje. Por
ejemplo, el mensaje abrir puede enviarse a la clase regalo, a la clase
117
cuenta bancaria, a la clase ventana, a la clase puerta, o alguna otra;
pero, cada clase ejecutará su propia versión de abrir, en respuesta al
mensaje respectivo. La operación abrir es implementada de diversas
formas, una para cada clase. Al hecho de que una misma operación
tome diversas formas de implementación, se le conoce como
polimorfismo.
En el diagrama anterior se observa que abrir regalo, abrir cuenta
bancaria, abrir ventana de software, abrir ventana común (como la de
nuestras casas u oficinas), tienen sus propias implementaciones cada
una diferente de las otras. En el caso de abrir puerta nos encontramos
con una jerarquía de clases, en donde la clase raíz muestra una
operación abstracta (una operación que se identifica pero que no se
implementa), en donde cada uno de sus descendientes tiene su propia
versión de abrir Puerta.
Observe que VentanaSoftware y VentanaComun se refieren a clases
completamente diferentes por lo que no es conveniente crear una
jerarquía de clases para ellas. Sin embargo, es posible modelar
diversas subclases para cada una de ellas por ejemplo; para ventanas
de software, existen, ventana de dialogo, ventana de error, ventana
principal, ventana hija, ventana emergente, ventana MDI (interfaz de
múltiples documentos)entre algunas otras; mientras que para ventana
Puerta
abrir()
…
PuertaCorrediza
abrir()
…
PuertaGiratoria
abrir()
…
Regalo
abrir()
…
CuentaBancaria
abrir()
…
VentanaSoftware
abrir()
…
VentanaComun
abrir()
…
118
común, como aquellas que encontramos en nuestras casas, pueden ser
corredizas, giratorias, con huecos, etc. Las clases escogidas
dependerán de las necesidades del sistema que estemos modelando.
Para algunos casos la operación abrir será la misma, mientras que en
otros, cada clase tendrá su propia versión de abrir.
Se pueden especificar en la jerarquía de clases operaciones con el
mismo nombre en diferentes clases. Las operaciones de las clases hijas
redefinen la operación a ser ejecutada, la cual se determina en tiempo
de ejecución. Una operación polimórfica, es justamente la misma
operación implementada de manera distinta por dos o más clases.
Responsabilidades de las clases
Todas las clases deben cumplir una labor. En el argot de la orientación
a objetos, a dicha labor se le conoce como responsabilidad. Una
responsabilidad es un contrato u obligación que la clase debe
cumplir, pues viene a ser el fin para la cual fue creada. Los atributos y
comportamiento son las características de la clase que le permiten
cumplir con esas responsabilidades.
Una buena manera de iniciar el modelado orientado a objetos, es
identificar las clases con sus respectivas responsabilidades; cuando se
va refinando el modelo, las responsabilidades se traducen en atributos
y operaciones que permiten cumplirlas, esto significa que las
responsabilidades tienen un nivel de abstracción superior a los
atributos y operaciones.
Las responsabilidades se colocan en un cuarto compartimiento, del
rectángulo que representa a la clase.
119
Las responsabilidades se indican con frases cortas en texto libre.
NombreClase
Responsabilidades
……………………….
……………………….
A menudo, un comportamiento deseado es distribuido entre varias
clases que colaboran entre sí, se asignan responsabilidades para cada
clase cuidando de no asignar demasiadas responsabilidades a una sola
clase, ni tener clases con pocas responsabilidades. Esto permite pensar
en distribuir las responsabilidades entre otras clases o unirlas en una
sola cuando sean necesarias.
Casos Particulares de clases
Cuando trabajamos con clases se presentan casos particulares de
éstas, cuyos conceptos debemos conocer para poder aplicarlos en el
momento adecuado. No todos los tipos de clases se utilizarán en
nuestros diagramas; sin embargo, es necesaria su distinción. Así
tenemos:
• Clase Abstracta
• Clase Parametrizada
• Clase Asociación
• Clase Activa
• Clase Utilidad (utility class)
• Clase Interfaz (interface class)
• Clase Hoja (leaf class)
• Clase Raíz (root class)
• Metaclase (metaclass)
120
Clase Abstracta:
Las Clases "Abstractas son aquellas que no tienen instancias y sirven
para definir otras subclases las cuales sí podrán ser instanciadas. La
única forma de utilizar clases abstractas, es definiendo subclases que
hereden los atributos y operaciones abstractas definidos y en las cuales
recién éstos serán implementados. Una operación abstracta es aquella,
que se declara en una clase abstracta pero que no se implementa.
Una clase abstracta se denota con el nombre de la clase y las
(operaciones con letra "itálica" y opcionalmente colocando la etiqueta
{abstract} debajo del nombre de la clase; Cualquier clase que no sea
abstracta será una Clase Concreta o simplemente Clase.
Recuerde siempre el siguiente enunciado: "Si todos los miembros de
una clase T, han de pertenecer a una subclase de T, entonces la
clase T es abstracta". La clase T no tendrá ocurrencias pero sus
clases descendientes si.
ClaseAbstracta
(abstract)
atributoUno
atributoDos
…
operaciónUno
operaciónDos
…
Clase1
OperaciónUno
OperaciónDos
…
Clase2
OperaciónUno
OperaciónDos
…
121
Las operaciones OperaciónUno y OperaciónDos, pertenecientes a
claseAbstracta, solo se declaran más no se implementan (no poseen
métodos). Sin embargo, estas operaciones también están declaradas
en Clase1 y Clase2, y cada una tiene una versión propia de las
operaciones (esta situación como ya vimos se conoce como
polimorfismo: una operación con el mismo nombre pero con
diferentes implementaciones).
Una clase Abstracta solo sirve para dar a conocer la existencia de esa
clase con operaciones y atributos pero nunca habrá una instancia real
de la misma y por lo tanto no existirá una implementación real do su:;
operaciones. Una Clase Abstracta sirve para factorizar las
propiedades comunes a diversas clases, pero es demasiado genérica
para instanciar objetos, una Clase Abstracta no tiene pues ninguna
instancia, porque no tiene las suficientes propiedades para precisar
claramente a sus instancias.
Clase Parametrizada
Anteriormente mencionamos que una clase es como una plantilla para
generar objetos, así un objeto es la instancia de una clase. El UML
nos proporciona un mecanismo para crear clases de mañera similar a
como creamos objetos. Esto se logra mediante la Clase Paramétrica o
Parametrizada, que viene a ser una clase que puede instanciar a otra
clase según sea el parámetro que se le envíe. Las clases
parametrizadas permiten escribir una plantilla de clases, que se
puede aplicar a varios casos que se diferencian solo mediante los tipos
de parámetros enviados. Esto significa que las clases parametrizadas
definen en realidad una familia de clases. Se podrá generar una clase
concreta enviándole parámetros a una clase parametrizada. Las
variables locales dentro de la : operación tienen un tipo de datos
122
genérico que depende del tipo de la instancia, es decir del parámetro
utilizado en la clase.
Una plantilla de clases no se puede utilizar directamente sino que
primero debe instanciarse. La instanciación enlaza los parámetros
formales de la plantilla hacia la clase instanciada. A la instancia de una
dase con parámetro, se le llama elemento enlazado
(bound). La instanciación de una clase parametrizada da como
resultado una clase concreta que puede ser usada como una clase
cualquiera. Típicamente los parámetros representan los tipos de
atributos, y aún más, ellos también pueden representar operaciones.
La clase parametrizada corresponden al concepto de clase genérica en
los conceptos básicos orientados a objetos o al concepto de plantilla
(template) en C++. Así, para implementar clases parametrizadas se
puede usar los templates del C++ o bien de alguna estructura
predefinida de especialización a través de clases. El uso común de las
témplate class es especificar contenedores que pueden ser instanciados
para elementos específicos, construyendo tipos seguros.
En UML las clases parametrizadas se representan como una clase
acompañada de un rectángulo de líneas discontinuas en la esquina
superior derecha, en dicho rectángulo se especifican los parámetros
que deben ser pasados a la clase para que esta pueda ser instanciada.
Los parámetros deben escribirse separados por comas o uno por línea,
con la siguiente sintaxis:
name: type [= default-value]
NombreClase Parámetros
123
Donde:
name: es el identificador del parámetro cuyo ámbito de existencia es
solo, dentro de la plantilla
type: indica el tipo de dato del parámetro.
default-value: es el valor que es usado cuando el correspondiente
valor del parámetro no se indica al instanciar la clase.
Clase Asociación
Una Clase Asociación modela las propiedades de una Relación de
Asociación, considerándolas como un tipo particular de clase. Las
propiedades son almacenadas en una clase, y enlazadas a la relación
de asociación. Para poder crear una Clase Asociación, necesitamos
tener primero una Relación de Asociación entre dos clases
(trataremos esto más adelante), luego definimos la clase asociación y
la unimos mediante una línea discontinua con la asociación.
En el diagrama adjunto se muestra una Clase Asociación, en ella
debemos indicar los atributos y operaciones que surgen como
consecuencia de la relación entre las clases Clase1 y Clase2.
Clase Activa
Una Clase Activa es una clase cuyos objetos son Objetos Activos.
Un Objeto Activo es el que contiene su propio flujo de control, a
diferencia de un Objeto Pasivo que encapsula datos y solo reacciona al
enviarle un mensaje.
En otras palabras, una Clase Activa es una clase cuyos objetos tienen
uno o más procesos de ejecución; esto es, tienen comportamiento
Clase1 Clase2
ClaseAsociacion
124
concurrente con otros elementos y, por tanto, pueden dar lugar a
actividades de control. Una Clase Activa modela una familia de
procesos o hilos de ejecución.
Las clases activas, se representan igual que las clases comunes, pero
con un rectángulo de bordes más grueso. Los mensajes entre los
objetos pasivos se representan mediante una flecha completa mientras
que los mensajes de los objetos activos mediante una flecha
incompleta
Clase Utilidad (Utility Class)
Es una agrupación de variables globales y procedimientos públicos
declarados en forma de una clase. No es una construcción fundamental,
pero es muy conveniente usarla durante la programación.
Una Clase Utilidad es representada como una clase con el
estereotipo utilidad.
<<utility>>
Clase Interfaz (Interfaz Class)
Es una clase particular que consta solo de operaciones. Las clases
interfaz o simplemente interfaces suelen definir comportamientos
genéricos que no pueden encapsularse en clases propiamente dichas,
porque no forman parte de la semántica de los objetos. Las clases
interfaz son muy útiles, puesto que los paquetes y clases comunes
pueden tener interfaces para ser utilizadas por otras clases. De esta
manera, basta con que una clase o paquete se conecte a otra por
Clase Activa
Mensajes enviados por
Objeto pasivo
Objeto activo
125
medio de su interfaz para : solicitar algún servicio, permitiendo menor
acoplamiento entre clases y/o j _ paquetes y por lo tanto mejora el
mantenimiento ante posibles cambios. En i C++ las interfaces pueden
implementarse como clases abstractas que sólo contienen funciones
virtuales puras. En Java la noción de interfaz está integrada al
lenguaje.
Una Clase Interfaz es representada como una clase con el estereotipo
«interface»
<<interface>>
Clase Hoja (Leaf Class)
Es una clase que no tiene descendientes. Es una clase como cualquier
otra, pero se encuentra en el último nivel de descendencia en la
jerarquía de clases.
Clase Raíz (Root Class)
Es una clase que no tiene padres. Es una clase como cualquier otra
pero que se encuentra en el nivel más superior dentro de la jerarquía
de clases.
(leaf)
ClaseHoja
(root)
ClaseRaiz
126
Metaclase (metaclass)
Es una clase cuyas instancias son clases. Se representan como clases
con el estereotipo «metaclass».
Relaciones entre Clases
Comprendido el concepto de Clase, es necesario explicar cómo se
pueden interrelacionar dos o más clases que buscan cumplir un
objetivo común.
Existen tres tipos de relaciones entre las clases, las cuales son:
Relación de Dependencia
Relación de Generalización
Relación de Asociación la que a su vez se puede dividir de dos
formas, según el criterio adoptado:
o Según el número de clases participantes: Binaria y N-aria.
o Según como contribuyan a formar la clase, se dividen a su
vez en:
AND que puede ser Agregación y Composición, y
XOR
Esto se representa en el siguiente cuadro:
<<metaclass>>
Tipos de
Relaciones
entre Clases
Dependencia
Generalización
Asociación
Según el número
de Clases
participantes
Según como se
unan las Clases
Binaria
N-aria
AND
XOR
Agregación
Composición
127
A continuación explicaremos detenidamente cada una de ellas:
Relación de Dependencia
Es, una relación semántica entre, dos elementos en la cual un cambio
en un elemento (el elemento independiente) puede afectar a la
semántica del otro elemento (elemento dependiente). El elemento
dependiente es aquel que necesita de otro (el independiente), para
poder cumplir su responsabilidad. Este tipo de relación denota pues, la
dependencia que tiene una clase respecto a otra.
Se representa con una línea discontinua, dirigida según el sentido de la
dependencia y que a veces incluye una etiqueta y un estereotipo, que
dan una explicación del tipo de dependencia presentada.
Una relación de dependencia va dirigida desde la clase dependiente
(también llamada origen) hacia la clase independiente (también
llamada destino).
Aunque no es indispensable aplicar estereotipos a la relación de
dependencia, se han reconocido 8 estereotipos de uso común entre las
clases y objetos, los cuales son:
Relación de Dependencia
ClaseDependiente
ClaseIndependiente
128
Bind.- Se utiliza cuando se desea detallar que la clase
dependiente es la instancia de una clase parametrizada, la
relación de dependencia estereotipada con Bind incluye una lista
de los actuales argumentos que vienen de los argumentos de la
plantilla.
Derive.- Se utiliza cuando se desea modelar la relación entre dos
atributos o dos asociaciones, en donde una de ellas puede ser
obtenida a partir de la otra (es derivada de la otra). Esto significa
que en realidad un elemento es concreto, mientras que el otro es
puramente conceptual.
Friend.- Este estereotipo se utiliza cuando se desea" modelar el
concepto Clases Amigas muy popular en C++. Especifica que la .
Clase Amiga puede utilizar los métodos de otra clase.
InstanceOf.- Se utiliza cuando deseamos mostrar en un mismo
diagrama la relación entre una clase y ún objeto, o entre una
clase y su metaclase. Especifica que el objeto origen es una
instancia de la clase clasificador.
Instantiate.- Especifica que la clase origen crea instancias de la
clase destino. Se utiliza cuando deseamos especificar cuáles
elementos crean instancias de otros. La clase origen tiene la
responsabilidad de crear objetos de la clase destino.
Powertype- Indica que la clase destino es un powertype de la
clase origen. Un powertype es un clasificador cuyos objetos son
todos hijos de un padre dado. Se-usa para modelar clases que
cubren otras clases como cuando se modelan bases de datos.
Refine.- Especifica que la clase fuente es un grado más fino de
abstracción que el destino. Se utiliza cuando deseamos modelar
clases que son esencialmente las mismas, pero que tienen
diferentes niveles de abstracción.
129
Use:- Especifica que una clase utiliza a otra. Esto es la semántica
de la clase origen (dependiente) depende de la parte pública de
la clase destino (independiente).
El diagrama adjunto muestra una relación de dependencia
estereotipada como Bind. Esta relación se da entre una Clase
Parametrizada (independiente) y la clase instanciada (dependiente).
El siguiente diagrama muestra dos clases amigas. Las operaciones
operación1 y operación2 pueden ser usadas por ClaseFuente.
ClaseFuente obtiene una visibilidad especial de ClaseDestino.
Relación de Generalización
Es una relación entre dos clases en donde una de ellas, llamada
subclase o clase hija (subclass o child), hereda los atributos y el
comportamiento de otra, llamada superclase o clase padre
(superclass o parent)
En esta relación, está involucrado el mecanismo de herencia por el
cual el hijo comparte la estructura y el comportamiento visibles
del padre, esto es, aquellos atributos y operaciones de la Clase Padre
ClaseDependiente
ClaseIndependiente
Parámetros
<<Bind>>
ClaseDependiente ClaseIndependiente <<friend>>
130
que tengan visibilidad public o protected, pero a la vez puede definir
o redefinir nuevos atributos y operaciones que son propias de la
subclase. . Esto significa que el hijo puede sustituir al padre, pues
contiene todos sus atributos y operaciones. A esta relación también se
le conoce como "es un tipo de" porque el hijo es un tipo de la clase
padre.
En la gran mayoría de casos se puede establecer una relación de
generalización donde cada hijo tenga un solo padre, en este caso se
llama herencia simple; mientras que, en ocasiones se presenta el
caso de que un hijo puede tener múltiples padres, llamándose a este
caso herencia múltiple. En realidad hay que tener cuidado al utilizar
herencia múltiple pues los atributos y comportamientos podría
sobreponerse o el lenguaje de programación a utilizar podría no
soportarla. En este case, se heredaría solo de un padre y el
comportamiento adicional se modelaría como una agregación para
obtener la estructura y el comportamiento requerido.
Se representa mediante una línea continúa con punta de flecha
hueca dirigida desde la Clase Child hacia la Clase parent.
El diagrama siguiente muestra a Clase2 que es un hijo de Clase1 y
por tanto hereda atributo1 y atributo3, así como operación1 y
operación3 pues tienen visibilidad pública y protegida. Lo mismo
ocurre con Clase3. El atributo2 y la operación2 no se heredan pues
estar definidos como privados.
Relación de Asociación
Es una relación estructural que describe un conjunto de enlaces o
conexiones entre dos o más clases, permitiendo asociar objetos de las
Relación de Generalización
131
clases que colaboran entre sí para llevar a cabo un comportamiento
deseado.
Extremo de la Asociación (Association End)
Una Asociation End es simplemente un extremo de una Relación
Asociación, la cual se conecta a la clase. La Association End es parte
de la relación por lo que no puede separarse de ella.
Detallando una Asociación
Una Relación de Asociación puede presentar algunos
elementos adicionales que la detallan, tales como:
Name: Toda relación debe llevar un nombre la cual consta de
una cadena de caracteres que sirve para identificar a la relación.
Rolename: Describe el significado de la relación en cada uno de
sus extremos y se identifican con nombres en cada extremo de la
línea de la relación.
Clase1 Clase2
Relación de Asociación
Clase1 Clase2
Extremos de la Asociación
Clase1 Clase2 Nombre
Clase1 Clase2
Rol1 Rol2
132
Multiplicity. Indican cuantos elementos de un clase se conectan
con .la otra clase. Se escriben en cada extremo de la relación y
éstas pueden ser:
1 a muchos : 1..*
0 a muchos : 0..*
un número fijo: M
Ordering: Si la multiplicidad es más que uno, entonces los
elementos pueden estar ordenados o desordenados. Esto se
puede especificar escribiendo las palabras {ordered},
{unordered}, o {sorted} pero no se especifica cómo se mantiene
los elementos ordenados. Si no se especifica ningún tipo se
asume qué están desordenados: Si las clases se detallan a nivel
de implementación es posible especificar el uso de índices
mediante la palabra {sorted} la cual no añade ninguna
información adicional sino que expresa una decisión de diseño.
Qualifier. Es un atributo o lista de atributos cuyos valores sirven
para particionar el conjunto de instancias asociadas con una
instancia a través de una asociación. Los cualificadores (o
calificadores) son atributos de la asociación. Se representa
mediante un pequeño rectángulo unido al extremo de la
asociación junto a la clase conectada, los atributos del
cualificador se escriben dentro del rectángulo correspondiente al
cualificador, el cualificador es un atributo de la asociación,
no parte de la clase. Una instancia de la clase junto con un
valor del cualificador seleccionan únicamente una partición en el
conjunto de la clase destino. Los atributos del cualificador tienen
la misma notación que los atributos de la clase, excepto que el
Clase1 Clase2
1…* M
Clase1 Clase2 1…* M
133
valor inicial no tiene significado. Es raro encontrar cualificadores
en cada extremo de la asociación. Una asociación que contenga
un cualificar se le llama comúnmente Asociación Cualificada o
Asociación Calificada.
Navegability. Una flecha puede colocarse al extremo de la
asociación para indicar el sentido de la navegación hacia la clase
junto a la flecha, la navegabilidad puede tener cero, uno o dos
cabezas de flechas. A menudo la navegabilidad solo será en
ambos sentidos, pero algunas veces solo tendrá un único sentido,
esto ocurre cuando deseamos ir de un objeto a otro, pero no de
manera inversa.
Agregation indicator. El Indicador de agregación, muestra dos
formas de asociación. Una de ellas llamada Asociación de
Agregación y otra llamada Asociación de Composición, ambas se
explicará, más adelante.
Clasificación de una Relación de Asociación
Las asociaciones las podemos subdividir según el número de clases que
participen en: Asociación Binaria y Asociación N-aria; y según
como, contribuyen ahormar una clase en: Asociación de Agregación
y Asociación de Composición.
Clase1 Clase2
Cualificador
Clase1 Clase2
Navegabilidad
134
Clasificación según el número de clases participantes
Asociación binaria
Es una asociación exactamente entre dos clases, incluyendo el
Caso de una asociación reflexiva de una clase consigo misma.
Una Asociación reflexiva significa que un objeto de una clase se
puede conectar con otros objetos de la misma clase. La
asociación binaria se representa mediante una línea sólida que
une dos clases.
Asociación N-aria
Es una forma de expresar una relación entre tres o más clases.
Se representa mediante un rombo o diamante, del cual salen
líneas de asociación a las clases. El nombre de la asociación se
escribe dentro del rombo. Se pueden incluir roles en cada camino
al igual que en una relación binaria, así como la multiplicidad,
pero los cualificadores, e indicadores de agregación y
composición no son permitidos.
Una Clase Asociación puede ser enlazada hacia el rombo
mediante una línea discontinua. Esto indica una Asociación N-
aria que tiene atributos, operaciones y asociaciones.
Clase1 Clase2 Clase
Asociación Binaria
Asociación Binaria Reflexiva
Clase 1
Clase 2 Clase 3 Clase 2 Clase 3
Clase 1
Clase Asociación Relación N-aria
135
El diagrama anterior muestra en su lado izquierdo una Asociación N-
aria, y en su lado derecho una Asociación N-aria con una Clase
Asociación que describe los atributos de la asociación y su
comportamiento.
Clasificación según como se unen para formar otra clase
Cuando agrupamos objetos, puede ocurrir que un objeto puede estar
formado por varios otros (Asociación AND) o podrán estar formados
por cualquier objeto de un conjunto dado (Asociación XOR)
Asociación AND (And Association)
Si un objeto (al que llamaremos objeto base) está formado por
otros objetos, entonces tendremos una Asociación AND entre
las clases correspondientes. Sin embargo, las partes constitutivas
del Objeto Base pueden tener existencia por sí mismas, con lo
cual dan lugar a un tipo especial de relación denominada
Relación de Agregación, o en case contrario las partes
constitutivas del Objeto Base dejarán de existir, al dejar de existir
este, con lo cual dan lugar a una relación denominada Relación
de Composición. Ambas relaciones se explican a continuación.
Asociación de Agregación
La Agregación es un tipo especial de asociación e indica que el
objeto base solo utiliza al objeto incluido para poder funcionar. Si
el objeto base desaparece no desaparecen los objetos incluidos.
El objeto incluido existe por sí mismo, el objeto base lo usa. Este
tipo de asociación tiene tres características:
Primero, sus elementos no tienen dependencia existencial, el
elemento incluido no desaparece al destruirse el elemento que
lo contiene.
136
Segundo, pertenencia fuerte, el objeto contenido es parte
constitutiva, pero no vital del que lo contiene.
Tercero, se permite compartir los objetos contenidos.
Se representa mediante un rombo transparente ubicado al lado
de la clase base.
Cuando desaparece el objeto perteneciente a ClaseBase, los
objetos de Clase1, Clase2 y Clase3 que lo componen no
desaparecen pues tienen existencia propia.
Asociación de Composición
La Composición es un tipo especial de asociación, en donde el
tiempo de vida del objeto incluido está condicionado por el tiempo
de vida del que lo incluye. El objeto incluido solo existe mientras
exista el objeto base. El objeto base se construye a partir de los
objetos incluidos pero no podría existir sin ellos y viceversa, los
objetos incluidos no pueden existir sin la existencia del objeto que
los incluye.
Este tipo de asociación tiene tres características:
Primero, dependencia existencial, el elemento incluido
desaparece al destruirse el elemento que lo contiene y, si es
de cardinalidad 1, el objeto incluido es creado al mismo tiempo
que el objeto base.
Segundo, pertenencia fuerte, el objeto contenido es partía
constitutiva y vital del que lo contiene.
Tercero, los objetos contenidos no son compartidos esto es
no forman parte de otro objeto.
ClaseBase
Clase1 Clase2 Clase3
137
Se representa mediante un rombo relleno al lado de la clase1
contenedora.
El objeto de ClaseBase está formado por objetos de Clase1,
Clase2 y Clase3. Al destruirse el objeto de ClaseBase, los objetos
de las otras clases dejan de existir.
Asociación XOR (Xor Association)
Es un tipo de asociación en donde una instancia de una clase (un
objeto), solo puede formar una única asociación de un conjunto
posible de asociaciones. Esto significa que solo una de las
asociaciones mostradas puede ocurrir en un momento
determinado.
Se representa mediante una línea discontinua etiquetada con
{xor} y conectada a dos o más asociaciones, las cuales deben
tener una clase común (ClaseBase).
Un objete de ClaseBase solo podrá asociarse con un objeto de la Clase1
o bien con un objeto de la Clase2, pero no ambos.
ClaseBase
Clase1 Clase2 Clase3
ClaseBase
Clase1
Clase2
{xor}
138
Estrategias para la creación de Diagrama de Clases
1. Identificar las clases que participan en el sistema
2. Dibujarlas en un diagrama de clases
3. Asignar sus responsabilidades
4. Agregar a las clases todos los atributos que se identificaron
5. Agregar las operaciones necesarias para cumplir sus
responsabilidades
6. Especificar los detalles de tipos de datos, visibilidad, etc.. a las
operaciones y atributos de cada clase.
7. Agregar las asociaciones necesarias.
8. Especificar la navegabilidad de las asociaciones, creando flechas
en los extremos de ellas según sea necesario.
9. Detallar las relaciones distinguiendo dependencia, generalización
y asociación en cualquiera de sus formas.
10. Validar el modelo
EJEMPLOS CLASES
Ejemplo 5.1
Muestre Las posibles clases que puede encontrar en una casa.
Solución:
Siendo las clases un conjunto de objetos que tienen características y
comportamiento común, en una casa podemos distinguir:
Pared.- Todas poseen características comunes como alto, ancho,
color habitaciones que conecta y comportamiento común
(operaciones) por ejemplo pueden ser pintadas.
Piso.- Ya que poseen características como acabado, color, estado de
conservación y operaciones que les podemos hacer como barrer,
encerar.
139
Ventana.- Podemos mencionar características como alto, ancho,
material y operaciones como limpiar, abrir, cerrar entre otras. .
Puerta.- Algunas de sus características son alto, ancho, material,
color, y podemos mencionar operaciones como pintar, cerrar, abrir.
Tubería.- Que tienen como características el tipo de tubería
(agua, desagüe), el diámetro, etc.
Cada Clase tiene los mismos atributos, esto no significa que el valor de
cada atributo tenga "que ser el mismo, pero tampoco lo prohíbe. Así,
una pared puede medir 3m de alto, 4m de largo y color verde, mientras
que otra puede tener 3m de alto, 3m de largo y color azul. Ambas
paredes pertenecen a la Clase Pared, pero son objetos diferentes.
Debemos mencionar que en el paradigma orientado a objetos, aún si
dos objetos tienen las mismas características serán objetos diferentes.
Así si dos paredes tienen el mismo alto, largo y color serán objetos
diferentes pues cada uno tiene existencia propia.
Observe que el atributo estConservacion se nombra con In primera
letra de cada palabra en mayúsculas a excepción de la primera letra.
Para nombrar la Clase Tubería se usó el path name, es decir se
indica en qué paquete se encuentra la clase, mientras que para las
Clases Pared, Piso, Ventana y Puerta se hace uso del simple hame.
Esto significa que si mostramos los paquetes y si agrupamos las clases
Pared, Piso, Ventana y Puerta en el Paquete Estructura tendríamos lo
siguiente:
Pared
alto
ancho
color
Piso
acabado
color
estConservacion
Ventana
alto
ancho
material
Puerta
alto
ancho
color
materia
AguaDesague::Tuberia
tipo
diametro
Pared
alto
ancho
color
Piso
acabado
color
estConservacion
Ventana
alto
ancho
material
Puerta
alto
ancho
color
materia
Tuberia
tipo
diametro
Estructura AguaDesague
140
Podemos imaginarnos otros tipos de paquetes que pueden agrupar a
los objetos que normalmente se encuentran en una casa, como por
ejemplo el paquete Muebles que podría contener las clases sillón,
mesa, ropero, vitrinas, etc., o tal vez el Paquete Utensilios de
Cocina que contendrá a las clases cucharas, tenedores, cucharones,
etc. Las clases y paquetes que representemos dependen del problema
que deseamos resolver; así, en muchos casos no serán necesarios
algunos de éstos paquetes, mientras que en otros casos sí.
Ejemplo 5.2:
Muestre la complejidad y el tipo de cada atributo
De la Clase Pared, si se sabe que ésta puede tener hasta 3 colores
diferentes.
Solución:
El diagrama muestra lo pedido. La visibilidad de los atributos es
protegida pues cualquier tipo de pared siempre tendrá los atributos
alto, ancho y color.
Imagínese que se le ocurra modelar dos subclases: Pared Fija y Pared
Movible. Ambas subclases tienen comportamientos diferentes y por lo
tanto serán clases diferentes, sin embargo mantienen los atributos alto,
ancho y color, por ello es que son atributos protegidos (#), es decir
accesibles desde la clase en la qué están definidas y sus descendientes.
Además, observe que cuando la multiplicidad es 1, no es necesario
especificarla, mientras que la multiplicidad del atributo color puede ser
Pared
# alto : float
# ancho : float
# color[0…3] : int
141
0, tienen el tipo int, mientras que el alto y el ancho son siempre valores
reales con punto decimal, esto es el tipo float (valores almacenados en
punto flotante).
Ejemplo 5.3:
Se diseña una casa para contener un máximo de 5 pisos. Muestre la
multiplicidad de la Clase Pisos, la cual tiene los atributos área
techada, área total y el número del piso. Asimismo, el número del piso
es un atributo que no puede cambiar puesto que el primer piso siempre
será el primer piso; indique que este atributo no cambia mediante la
cadena de propiedades de los atributos.
Solución:
Por el mismo diseño de la casa, ésta sólo podrá tener hasta 5 pisos, por
lo que la multiplicidad de la Clase (que no es lo mismo que la
multiplicidad de los atributos) se representa tal como se muestra en el
diagrama adjunto. La cadena de propiedades contiene la cadena
{frozen} que indica que dicho valor nunca puede cambiar.
Ejemplo 5.4:
En una casa se sabe que el techo se ubicará a 2.5 m. del piso, entonces
las paredes por defecto medirán 2.5m. Cuando las paredes' son
construidas se les pinta con pintura Base lo que podemos deducir es
que el valor inicial del color sea Blanco y se muestra esto haciendo la
especificación del valor inicial.
Solución:
Tomando como base la descripción de los atributos de la Clase Pared
del Ejercicio 5.2 y añadiéndole los valores iníciales tendremos el
diagrama adjunto.
Visibilidad, nombre, multiplicidad, tipo y valores iniciales de los
atributos de la clase Pared
142
Ejemplo 5.5:
En una casa muestre la relación entre la Clase Pared y la Clase
Ventana.
Solución:
Las ventanas se ubican en las paredes, por lo tanto existe una
Relación de Asociación entre las clases Pared y Ventana. Esta
relación necesita la posición de la ventana respecto a la pared. La
posición está dada por los atributos posx y posy de la relación, los
cuales no pueden tomarse como atributos de Pared o Ventana, ya que
el contexto de su existencia está dado precisamente por la relación
entre las dos clases. Por lo tanto debemos modelarla como una Clase
Asociación a la cual llamamos Ubicación con dos atributos que
indiquen la posición de la ventana en la pared.
Se desea implementar un conjunto de funciones matemáticas tales
como generar números aleatorios, resolver ecuaciones simultáneas y
calcular la inversa de una matriz, etc. Modele una clase que permita
agrupar estas funciones.
Solución:
class: tal como se muestra en el diagrama adjunto. Las clases utilidad
se indican mediante el estereotipo «utility» y solo sirven como un
agrupamiento por conveniencia, más que por la existencia real de la
clase con sus atributos y operaciones.
Pared Ventana
Ubicación
Posx
Posy
143
Ejemplo 5.6:
Se tiene un sistema que implementa una interfaz gráfica en base a
ventanas. La Clase Aplicación es capaz de crear instancias de la
ventana pero ambas son clases diferentes. Modele este hecho. Observe
que se trata de una alta relación de dependencia en donde una clase
crea instancias de otra
Solución:
Dado que la Clase Ventana depende siempre de la aplicación que la
crea, la creación del Objeto Ventana está condicionado a la
instanciación proveniente desde el objeto Aplicación, por lo tanto existe
una relación de dependencia entre ambas. Debemos destacar que el
objeto creado (la Clase Ventana gráfica) no se almacena dentro del
objeto que lo crea (la Clase Aplicación) pues son clases diferentes. Por
lo tanto, tenemos dos clases, la Clase Aplicación crea una instancia de
la clase ventana, por lo que debe haber una relación de dependencia
que puede ser estereotipada como «instantiate».
Ejemplo 5.7:
Se desea modelar un sistema comercial para una empresa, después de
arduas discusiones el personal desabollador identificó la Clase
Persona, en la cual algunas instancias de la ClasePersona eran
Persona Natural (cualquier persona individual) mientras que otras
resultaban ser "Persona jurídica" (cualquier empresa o razón social).
Muestre estas clases mediante un diaqrama.
Solución:
Veamos, tenemos la Clase Persona con dos especializaciones: las
subclases Persona Natural y la subclase Persona Jurídica.
Sea el objeto de cualquiera de las subclases nunca dejará de ser
persona, por lo tanto se presenta el mecanismo de herencia que se
manifiesta mediante la relación de generalización; además, no existe
ninguna ocurrencia de Persona, pues cualquier ocurrencia siempre
144
será Natural o Jurídica, por lo que se trata de una Clase Abstracta.
Note que a la clase Persona le falta algunos atributos para poder
valerse por sí misma, y por ende no tiene ninguna instancia.
Ejemplo 5.8:
Una Cuenta Bancaria puede ser solamente Cuenta de Ahorros y Cuenta
Corriente. Muestre la Clase Cuenta si posee atributos como
NroCuenta, propietario, Saldo Neto, Fecha de Apertura, entre
otras, y si pueden realizar las siguientes operaciones: depósito, retiro,
anulación y calcular saldo.
Solución:
La Clase Cuenta no tiene ninguna ocurrencia cualquiera; Cuenta
siempre será Cuenta de Ahorros o Cuenta Corriente por lo que Cuenta
será una Clase Abstracta. Asimismo, todos sus atributos y operaciones
serán abstractos.
Persona
direccion
telefono
Natural
nombre
FechaNacim
Juridica
razonSocial
fechaConst
Cuenta
NroCuenta
idPropietario
saldoNeto
fechaApertura
deposito( )
retiro( )
anulacion( )
calculaSaldo( )
CuentaCorriente CuentaAhorros
145
Ejemplo 5.9:
Se desea implementar un software que permita jugar ajedrez,
identifiquen una clase abstracta que resulte conveniente modelar:
Solución:
Veamos, todas las piezas de ajedrez tiene un color, una imagen, un
estado y cuentan con algunas operaciones como obtener posición,
mover pieza, etc. Si modelamos una clase PiezaAjedrez con estos
atributos y operaciones, esta clase no tendrá ninguna ocurrencia, pues
las piezas de ajedrez reales estarán formando parte de las subclases de
PiezaAjedrez, tal como la subclase Peón, Torre, Alfil, etc. Por lo
tanto la clase PiezaAjedrez será una clase, abstracta, lo cual se
representa en el siguiente diagrama:
Observe que las clases abstractas contienen atributos y operaciones
abstractas que serán implementadas en las subclases, y que son
representadas con letras itálicas.
Ejemplo 5.10:
Un vehículo puede ser automóvil, camión, barco o avión. Muestre clase
vehículo con sus respectivos atributos y visibilidad y las relaciones de
generalización entre los subclases.
PiezaAjedrez
(abstract)
Color
Imagen
Estado
ObtenPosición( )
MoverPieza( )
Peón Torre Alfil Caballo Rey Reina
146
Solución:
Veamos los vehículos tiene uno o más dueños, una fecha de
fabricación, los automóviles y camiones tienen un número de puertas,
una determinada cantidad de ruedas, un número de placa, los barcos y
camiones una capacidad de carga.
El atributo dueño lo tienen todos los vehículos así como también las
subclases barco y avión, por lo tanto es un atributo protegido (#
dueño), pues es una característica de la clase vehículo y sus
descendientes: las subclases automóvil, barco y avión. El atributo
número de puertas parece ser exclusivo de los automóviles y de los
camiones por lo tanto será protegido a la subclase automóvil (#
nroPuertas). Lo mismo ocurre con el atributo ruedas, también será
protegido a la subclase automóvil (#nroRuedas). Por lo tanto se podrán
representar como:
Puede usted añadir otros atributos mediante un mayor análisis y tal vez
podría preferir dividir la Clase Vehículos en subclases vehículos
Terrestres, Aéreos, Marítimos y Anfibios. Esto dependerá de sus
necesidades particulares.
Vehículo
#Dueño
#fechaFabric
Automóvil
#Placa
#nroPuertas
#nroRuedas
Camión
#Placa
#nroPuertas
#nroRuedas
#CapCarga
Barco
#capCarga
Avión
#capCarga
147
Ejemplo 5.11:
Se desea modelar un conjunto de compañías cada una dejas cuales
tiene un conjunto de empleados. Se pide mostrar las clases
involucradas, así como el nombre de la asociación, los roles, y la
multiplicidad.
Solución:
Se tiene dos Clases: Compañía y Personar, la relación recibe el nombre
de "Trabaja Para", cuyo sentido va desde la Clase Persona hacia la
Clase Compañía (pudo escogerse el nombre "Emplea a y el sentido
seria el inverso). El rol que cumple la Clase Compañía es de
"empleador", mientras que la Clase Persona cumple el rol de
"empleado". La multiplicidad se obtiene razonando de la siguiente
manera "una compañía emplea a uno o más empleados (1..*),
mientras que una persona trabaja para ninguna o muchas compañías
(0..*)", (siempre se toma un objeto de una clase y se pregunta con
cuantos objetos de la otra clase se relaciona).
Ejemplo 5.12:
En cada Temporada de un Torneo de Fútbol participan Equipos los
cuales juegan Partidos. Como consecuencia de esto se obtiene el
Record que indica los goles a favor, goles en contra, partidos ganados,
perdidos y empatados. Modele esta situación haciendo uso de una
Clase Asociación.
Solución:
El siguiente diagrama muestra el modelo pedido.
Observe que se trata de una asociación ternaria con atributos propios
por lo que fue modelada como una clase asociación. Este diagrama
representa solo un nivel lógico, cuando quiera implementarlo
Temporada
Compañía Persona
1…* 0…*
Trabaja para
empleador empleado
148
físicamente, deberá transformar la asociación ternaria en asociaciones
binarias.
Ejemplo 5.13:
Modele la Clase Polígono, Recuerde que un polígono queda
completamente definido cuando se conocen sus vértices, que al menos
deben ser 3.
Solución:
Identificamos la Clase Polígono y la Clase Puntos, (que hace las veces
de vértices). Un polígono queda definido al conocerse 3 o más puntos
que se unen, por lo que la multiplicidad se obtendrá así: "un polígono
se asocia con 3 o más puntos (3., ), mientras que un punto pertenece a
cero o muchos polígonos (0..*)".
La relación se llama "Es definido por", pues representa justamente la
razón de la relación y su direccionalidad es desde la Clase Polígono
hacia la Clase Punto. Se muestra {ordered} pues los puntos guardan
un orden para poder formar el polígono (los puntos no pueden unirse
por rectas de cualquier manera, pues aunque sean los mismos puntos,
algunas combinaciones dan diferentes polígonos). Polígono y Punto se
relacionan mediante una Asociación de Agregación que es representada
mediante el rombo junto, a la Clase Polígono, pues los puntos definen
al polígono y éstos siguen existiendo aunque el polígono deje de existir.
Ejemplo 5.14:
Modele una computadora personal mostrando sus componentes.
Solución:
La relación de una computadora personal con sus partes es un típico
ejemplo de Asociación de Agregación. La PC está formada por CPU,
Teclado, Monitor y Mouse. Si desaparece la PC como un todo, sus
partes constitutivas aun tienen existencia. A su vez la CPU está
Polígono Punto 3…* 0…* Es definido por
149
formada por microprocesador, disco duro, disquetera para discos
flexibles, CD ROM, memorias, etc., manteniendo también una
Asociación de Agregación con dichas partes, pues si la CPU deja de
existir su partes seguirán existiendo.
EJEMPLO 5.15:
Una factura puede modelarse mediante dos clases la Cabecera de
factura que indica aquellos datos que son únicos para toda la factura y
el detalle de las facturas que son aquellos renglones que indican la
cantidad y el ítem adquirido. Modele la Clase Factura.
Solución:
Conociendo que Facturas está formada por las Clases Cabecera y
Detalle, y si la Factura deja de existir su cabecera y detalle no tendrían
sentido, por lo tanto se trata de una Asociación de Composición
Ejemplo 5.17:
Se tiene una Cuenta Bancaria que puede ser Cuenta Corriente, Cuenta
de Ahorros, a su vez una Cuenta pertenece a una Persona que puede
ser Persona Natural o Persona Jurídica. Modele este caso utilizando la
Factura
Detalle Cabecera
1…* 1…*
150
Relación de Generalización y la Asociación XOR. Distinga ambas
relaciones claramente y reflexione sobre su diferencia.
Solución:
Tal como vimos en el Ejemplo 3.9 la Clase Cuenta es una clase
abstracta de la cual se heredan las clases Cuenta Corriente y Cuenta de
Ahorro. Mientras que en el Ejemplo 3.8 la Clase Persona también era
una clase abstracta de la cual se heredan las Clases Natural y Jurídica
(empresa). Ahora bien cada Cuenta se debe asociar con una Persona
que puede ser Natural o Jurídica. Note que cada subclase involucrada
en la Relación de Generalización es un tipo de la clase madre (Cuenta
Corriente y Cuenta de Ahorro son cada una un tipo de Cuenta),
mientras que las clases que se relacionan en una Asociación XOR, son
distintas (la Clase Cuenta se asocia con la Clase Natural o con la
Jurídica). Este hecho se modela en el siguiente diagrama:
Ejemplo 5.18:
Se desea implementar una Lista de Elementos, estos elementos
pueden ser de cualquier tipo tales como pares de coordenadas,
números enteros, números reales, números complejos, cadenas de
caracteres (como nombres de invitados a una cena), etc. Defina una
Clase Parametrizada: que permita recibir el parámetro tipo y que
pueda instanciar las que requeriría.
Solución:
Veamos, una lista debe tener las operaciones siguientes: insertar
elemento, modificar elemento, eliminar elemento, mostrar lista, buscar
Cuenta
Natural
Jurídica
{xor}
Corriente Ahorro
Ahorro
151
elemento, ordenar lista, entre otras (como por ejemplo eliminar lista).
Pero, ésta puede ser una lista de números enteros, una lista de
números reales, una lista de números complejos, una lista de invitados
a un evento, una lista de animales en un zoológico, una lista de cosas,
una lista de tareas a ejecutar, entre muchas otras posibles. Cada una
de ellas tendrá sus propios atributos que dependen justamente' del tipo
de lista implementada.
Una forma de modelar una lista sería crear una clase para cada tipo de
lista y definir las operaciones respectivas. Así, tendríamos que definir
todos los atributos y operaciones para cada una de las clases creadas.
Una forma más general sería definir una Clase parametrizada que,
según sean los parámetros enviados, cree una clase particular de lista.
La representación gráfica de esta clase se muestra en el diagrama
adjunto.
Podemos usar esta Clase Parametrizada para instanciar varias otras
clases. Así si deseamos una Clase Lista que gestione números enteros
tendríamos:
Si deseamos una lista de cosas tendríamos:
De manera similar se puede obtener las otras clases, enviándole los
parámetros apropiados, que incluso pueden corresponder a los
atributos propios de cada clase.
152
Ejemplo 5.19:
Modele la relación entre un ómnibus y sus asientos como una
asociación calificada
Solución:
Recordemos que un calificador divide el conjunto de instancias de una
clase, permitiendo reducir su multiplicidad. Es como un índice que nos
facilita ubicar los elementos, además el calificador sugiere las claves en
el modelo de base de datos. Cada uno de los grupos en que se ha
dividido las instancias se llaman partición. Una partición es la
descomposición de un conjunto en subconjuntos, en donde ningún
elemento puede pertenecer a dos subconjuntos (son disjuntos) y cuya
unión forma la totalidad de las instancias.
En nuestro ejemplo tenemos la clase ómnibus, relacionada con la clase
Asiento, para cada ómnibus tenemos muchos asientos, pero cada
asiento sólo está en un único ómnibus. Por lo que podemos
representarla como:
Observe que tenemos una relación 1 a muchos, si deseamos reducir
esta multiplicidad necesitamos un calificador. Busquemos uno
adecuado.
Veamos, los asientos para venta al público en un ómnibus tienen la
disposición mostrada en la figura adjunta.
Podemos dividir a estos asientos en grupos según diversos criterios: la
fila, la columna, si están junto el pasillo, si están junto a la ventana, o
según el número de asiento.
Analicemos detenidamente cada una de las alternativas para luego
escoger el calificador adecuado.
omnibus asiento 1 *
153
Si utilizamos el criterio del número de fila para dividir a las instancias
de la clase " asientos, tendremos que "para un ómnibus y dada una fila
obtendremos 4 asientos"
Si utilizamos el criterio del número de columna para dividir a las
instancias de la clase asientos, tendremos que "para un ómnibus y
dada una columna obtendremos N asientos".
El criterio de si está junto al pasillo no es aplicable, puesto que los que
están en el pasillo son solo una parte del total, por lo que no se
formará particiones, y por lo tanto, este criterio no puede utilizarse
como calificador.
De manera similar, el criterio de si está junto a la ventana no es
aplicable, puesto que los que están en la ventana son solo una parte
del total, por lo que no se formará particiones, y por lo tanto, este
criterio no puede utilizarse como calificador.
ómnibus fila
asiento 1 4
ómnibus col
asiento 1 N
154
Si utilizamos el criterio del número de asiento para dividir a las
instancias de la clase asientos, tendremos que "para un ómnibus y un
número de asiento tendremos un único asiento".
Este último criterio permite reducir la multiplicidad que antes era de uno a muchos a otra que es de uno a uno, además suma de los
subconjuntos da el todo, por lo tanto es el calificador escogido.
ómnibus num
asiento 1 1
155
- BOOCH, Grady – JACOBSON, Ivar – RUMBAUGH, James
El Lenguaje Unificado de Modelado, Manual de Referencia
Addison Wesley Iberoamericana, Madrid 2000 - MARTIN, James – ODELL, James J.
Análisis y diseño orientado a objetos Prentice Hall Hispanoamericana, México
- LIZA AVILA, César Modelando con UML – Principios y Aplicaciones
Grupo Creadores, Primera Edición, Agosto 2001 - TABOADA JIMENEZ, Alberto
Análisis de Procesos y Datos usando UML Instituto Peruano de Ciencias de la Información E.I.R.L.
Direcciones Web - http://sigifredo.laengle.googlepages.com/20071002-
Presentacion-AM.pdf - http://es.wikipedia.org/wiki/Modelado_de_procesos
- http://www.osmosislatina.com/lenguajes/uml/casos.htm - http://www.osmosislatina.com/lenguajes/uml/clasesob.htm
- http://www.scribd.com/doc/2458886/Uso-Diagrama-de-
actividades-Negocio
