Gestion informatica i

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.

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
PRODUCTOSPEDIDO
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
OUTPUTINPUT
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)

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:
……
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:
……
(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

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.
1: Encender
2: Envío Señal
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 ReposoTermina
de Ingerir
Alimentos
Sirven
Alimentos
En ReposoTermina
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
Sirven
Alimentos
En ReposoTermina
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
AltaSin Riesgo
Observando Operando
Ejecutan
Intervención
Recuperación
Término de
Intervención

Gestion informatica i

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Gestion informatica i

Similar a Gestion informatica i (20)

Gestion informatica i