ANÁLISIS DE SISTEMAS I

Descripción
Gráfica de los
Sistemas

Unidad II
 DESCRIPCIÓN GRÁFICA DE LOS SISTEMAS
Podemos realizar la descripción gráfica de un sistema o
subsistema, según la forma en que existe dentro de la
organización corporativa de varias formas.

Los diversos
modelos gráficos
muestran los
límites del sistema
y la información
que utiliza.
Los sistemas y el diagrama de flujo de datos
a nivel de contexto
El primer modelo es el diagrama de flujo de datos a nivel
de contexto (también conocido como modelo ambiental).

Los diagramas de flujo de datos se enfocan en los datos

que fluyen hacia el sistema y salen de él, además del
procesamiento de estos datos.

Podemos describir con detalle estos componentes

básicos de todo programa computacional y utilizarlos
para analizar la precisión e integridad del sistema.
Los sistemas y el diagrama de flujo de datos
a nivel de contexto
En la figura podemos ver que el diagrama
de flujo de datos a nivel de contexto
emplea sólo tres símbolos:
1) un rectángulo con esquinas redondas,
2) un cuadrado con dos bordes
sombreados y
3) una flecha.

Los procesos transforman los datos

entrantes en información de salida y el
nivel de contenido tiene sólo un proceso,
que representa a todo el sistema completo.
Los sistemas y el diagrama de flujo de datos
a nivel de contexto

La entidad externa representa a cualquier

entidad que suministra o recibe
información del sistema, pero que no
forma parte del mismo.

Esta entidad puede ser una persona, un

grupo de personas, un puesto o
departamento corporativo o, inclusive,
otros sistemas.

Las líneas que conectan a las entidades

externas con el proceso se llaman flujos de
datos y representan los datos.
Los sistemas y el diagrama de flujo de datos
a nivel de contexto

En la figura podemos
ver un ejemplo de
diagrama de flujo de
datos a nivel de
contexto.
 Los sistemas y el diagrama de flujo de datos
a nivel de contexto
En este ejemplo se representan los elementos más básicos del
sistema de reservación de una aerolínea. El pasajero (una entidad)
inicia una solicitud de viaje (flujo de datos).

El diagrama a nivel de contexto no muestra el suficiente detalle

como para indicar con exactitud lo que ocurre (no se supone que
deba hacerlo), pero podemos ver que las preferencias del pasajero y
los vuelos disponibles se envían al agente de viajes, quien a su vez
envía la información sobre los boletos de vuelta al proceso. También
podemos ver que la reservación del pasajero se envía a la aerolínea.

El diagrama de flujo de datos a nivel de contexto sirve como un buen

punto de inicio para dibujar el diagrama de casos de uso. Es una
manera de mostrar el alcance del sistema o lo que se va a incluir en
él. Las entidades externas están fuera del alcance y esto es algo
sobre lo que el sistema no tiene control.
Los sistemas y el modelo de entidad-relación
Otra forma en que un analista de sistemas puede mostrar el alcance
del sistema y definir límites apropiados para el mismo es mediante el
uso de un modelo entidad-relación.

Los elementos que conforman un sistema organizacional se pueden

denominar entidades.

Una entidad puede ser una persona, un lugar o una cosa, como un
pasajero en una aerolínea, un destino o un avión. O bien, una
entidad puede ser un evento, como el fin de mes, un periodo de
ventas o el tiempo de inactividad de una máquina.

Una relación es la asociación que describe a la interacción entre las

entidades.
Los sistemas y el modelo de entidad-relación

Hay muchas convenciones para dibujar diagramas de

entidad-relación (E-R) (con nombres como las notaciones
tipo pata de cuervo [crow’s foot], Arrow o Bachman).

Utilizaremos la notación tipo pata de cuervo.

Por ahora vamos a suponer que una entidad es un

cuadro rectangular simple.
Los sistemas y el modelo de entidad-relación
Notaciones tipo pata de cuervo [crow’s foot]
Los sistemas y el modelo de entidad-relación
En la figura aparece un diagrama de entidad-relación simple.

Las flechas rojas no forman

parte del diagrama de
entidad-relación; aparecen
sólo para indicar cómo
leerlo.

La frase del lado derecho

de la línea se lee de arriba
hacia abajo de la siguiente
manera: “Un EMPLEADO se
asigna a una EXTENSIÓN
TELEFÓNICA”.

Del lado izquierdo, leyendo

de abajo hacia arriba, la
flecha dice: “Una
EXTENSIÓN TELEFÓNICA se
enlista para un
Los sistemas y el modelo de entidad-relación
De manera similar, en la
figura se muestra otra
relación.
De manera similar, en la
figura se muestra otra
relación. Es obvio que en este
diagrama se utiliza la
notación tipo pata de cuervo
(>—+), y este ejemplo
específico contiene una
relación de varios a uno.

Si leemos de izquierda a
derecha, la flecha indica:
“Varios EMPLEADOS son
miembros de un
DEPARTAMENTO”.

Si leemos de derecha a
izquierda, implica: “Un
DEPARTAMENTO contiene
varios EMPLEADOS”.
Los sistemas y el modelo de entidad-relación

La figura
muestra más La primera, “Un EMPLEADO se
detalles asigna a una OFICINA” es una
relación de uno a uno.
sobre este
esquema.
Aquí
enlistamos
varias La segunda es una relación de uno a
varios: “Una AERONAVE DE CARGA
relaciones de servirá a uno o más CENTROs DE
entidades DISTRIBUCIÓN”.
comunes.
Los sistemas y el modelo de entidad-relación
Más ejemplos de relaciones de entidades comunes.

La tercera es ligeramente De igual forma, el círculo (O)

distinta, ya que tiene un círculo indica que es posible no tener
en un extremo. Se puede leer así: ningún mantenimiento
“Un ANALISTA DE SISTEMAS se programado en la siguiente
puede asignar a VARIOS relación. Recuerde que la marca
PROYECTOS”, lo cual significa que corta significa uno. Por lo tanto,
el analista se puede asignar a podemos leerlo de la siguiente
ningún proyecto [el círculo (O) forma: “Una MÁQUINA puede o no
indica cero], a uno o a varios tener asignado un
proyectos. MANTENIMIENTO PROGRAMADO”.
Observe que la línea se escribe como “tiene
asignado”, pero las marcas de los extremos
de la línea indican que no se va a realizar
ningún mantenimiento (O) o que se va a
realizar un mantenimiento (I).
Los sistemas y el modelo de entidad-relación
Otros ejemplos de relaciones de entidades comunes.

La siguiente relación establece que: “Uno o La relación final que se muestra en esta
más VENDEDORES (plural de VENDEDOR) figura se puede leer así: “Varios
se asignan a uno o más CLIENTEs”. Ésta es PASAJEROs van a volar a varios
la clásica relación de varios a varios. DESTINOs”.

Algunas personas prefieren usar este

símbolo [>—+] para indicar una condición
de “varios” obligatoria (¿sería posible
tener sólo un pasajero o sólo un
La siguiente relación se puede leer así: destino?).
“La OFICINA PRINCIPAL puede tener uno
o varios EMPLEADOs”, o “Uno o más Aún así, algunas herramientas CASE como
EMPLEADOs pueden asignarse o no a la Visible Analyst no ofrecen esta posibilidad, ya
OFICINA PRINCIPAL”. Una vez más, los que es suficiente con la condición opcional de
símbolos I y O juntos implican una uno o varios que se muestra en la relación
VENDEDOR-CLIENTE.
situación booleana; en otras palabras,
uno o cero.
Los sistemas y el modelo de entidad-relación

Hasta ahora hemos modelado todas nuestras relaciones

mediante un solo rectángulo simple y una línea.

Este método funciona bien cuando examinamos las

relaciones de cosas reales, como personas, lugares y
cosas.

Pero algunas veces creamos elementos en el proceso de

desarrollo de un sistema de información.
Los sistemas y el modelo de entidad-relación

Algunos ejemplos son facturas, recibos, archivos y bases

de datos.

Por ejemplo, cuando queremos describir la forma en que

se relaciona una persona con un recibo, es conveniente
indicar el recibo de una manera distinta, como se
muestra en la figura, en forma de entidad asociativa.
Los sistemas y el modelo de entidad-relación

Una entidad asociativa puede

existir sólo si está conectada con
por lo menos otras dos
entidades.

Por esta razón algunos la llaman

gerundio, cruce, intersección o
entidad concatenada.

Esta formulación tiene sentido, ya que un recibo no sería necesario a menos

que hubiera un cliente y un vendedor para realizar la transacción.
Los sistemas y el modelo de entidad-relación

La entidad atributiva es otro tipo

de entidad.

Cuando un analista quiere

mostrar datos que dependen por
completo de la existencia de una
entidad fundamental, hay que
utilizar una entidad atributiva.

Por ejemplo, si una biblioteca tiene varias copias del mismo libro, se puede
utilizar una entidad atributiva para designar qué copia del libro se va a sacar.
La entidad atributiva es útil para mostrar grupos de datos repetitivos. Por
ejemplo, suponga que vamos a modelar las relaciones que existen cuando
un patrocinador obtiene boletos para un concierto o show.
Los sistemas y el modelo de entidad-relación
Al principio las entidades
parecen obvias: “Un CLIENTE y
un CONCIERTO/SHOW”, como
se muestra en la figura.
¿Qué tipo de relación existe? A
primera instancia, el CLIENTE
obtiene una reservación para un
CONCIERTO/SHOW y se puede
decir que el CONCIERTO/SHOW
hizo una reservación para un
CLIENTE .

Desde luego que el proceso no

es tan simple, por lo que el
diagrama E-R tampoco necesita
ser así de simple.
Los sistemas y el modelo de entidad-relación
En realidad el CLIENTE hace una
RESERVACIÓN, como se muestra en
la figura.

La RESERVACIÓN es para un
CONCIERTO/SHOW.

El CONCIERTO/SHOW contiene la
RESERVACIÓN y la RESERVACIÓN
está a nombre del CLIENTE.

Agregamos una entidad asociativa en

este caso ya que se creó una
RESERVACIÓN debido a que el
sistema de información requiere que se
relacionen el CLIENTE y el
CONCIERTO/SHOW.
Los sistemas y el modelo de entidad-relación
Podemos ver de nuevo que este proceso es
bastante simple, pero como los conciertos y
shows tienen varias presentaciones, en la
figura dibujamos una vez más el diagrama E-
R.

Ahora agregamos una entidad atributiva para

manejar las diversas presentaciones del
CONCIERTO/ SHOW.

En este caso se hace la RESERVACIÓN

para una PRESENTACIÓN específica y la
PRESENTACIÓN es una de varias que
pertenecen a un CONCIERTO/SHOW
específico.

A su vez, el CONCIERTO/SHOW tiene varias

presentaciones y una PRESENTACIÓN tiene
una RESERVACIÓN que está a nombre de
un CLIENTE específico.
Los sistemas y el modelo de entidad-relación
A la derecha de este diagrama E-R hay un
conjunto de atributos de datos que
conforman cada una de las entidades.

Algunas entidades pueden tener atributos en

común.

Es posible realizar búsquedas con los

atributos que están subrayados.

Los atributos se denominan claves.

A menudo los diseñadores de sistemas

utilizan diagramas E-R para ayudar a
modelar el archivo o la base de datos. Sin
embargo, es aun más importante que el
analista de sistemas comprenda lo más
pronto posible tanto las entidades como las
relaciones en el sistema organizacional
Los sistemas y el modelo de entidad-relación
Al realizar bosquejos de algunos diagramas E-R básicos,
el analista necesita:

1. Enlistar las entidades en la organización para obtener

una mejor comprensión de la misma.

2. Elegir las entidades clave para reducir el alcance del

problema a una dimensión manejable y significativa.

3. Identificar cuál debe ser la entidad principal.

4. Confirmar los resultados de los pasos 1 al 3 por medio

de otros métodos de recopilación de datos.
Los sistemas y el modelo de entidad-relación

Es imprescindible que el analista de sistemas empiece a

dibujar diagramas E-R al entrar a la organización en vez
de esperar a que sea necesario diseñar la base de datos,
ya que los diagramas E-R ayudan al analista a
comprender cuál es la verdadera actividad de la
organización, a determinar el tamaño y alcance del
problema, y a discernir si está tratando o no con el
problema correcto. Hay que confirmar o revisar los
diagramas E-R a medida que se lleve a cabo el proceso
de recopilación de datos.
 MODELADO DE CASOS DE USO

Aunque en un principio se presentaron como un

diagrama para usarlo en el UML orientado a objetos,
ahora los casos de uso se utilizan sin importar la
metodología para el desarrollo de sistemas. Se pueden
utilizar como parte del SDLC o en el modelado ágil.

Un modelo de caso de uso describe qué hace un sistema

sin describir cómo lo hace; es decir, es un modelo lógico
del sistema.

El modelo de caso de uso presenta al sistema desde la

perspectiva de un usuario fuera del mismo (por ejemplo,
los requerimientos del sistema).
 MODELADO DE CASOS DE USO

Un analista desarrolla casos de uso en un esfuerzo de

cooperación con los expertos de negocios que ayudan
a definir los requerimientos del sistema.

El modelo de caso de uso provee un medio efectivo de

comunicación entre el equipo de negocios y el equipo de
desarrollo.

Un modelo de caso de uso particiona la forma en que

trabaja el sistema en comportamientos, servicios y
respuestas (los casos de uso) que sean importantes para
los usuarios del sistema.
 MODELADO DE CASOS DE USO

Desde la perspectiva de un actor (o usuario), un caso de

uso debe producir algo de valor.

Por lo tanto, el analista debe determinar qué es

importante para el usuario y debe recordar incluirlo en el
diagrama del caso de uso.

Por ejemplo, ¿introducir una contraseña es algo de valor

para el usuario? Tal vez se deba incluir si al usuario le
preocupa la seguridad o si es algo imprescindible para el
éxito del proyecto.
 Símbolos de los casos de uso

Un diagrama de caso de uso contiene los símbolos del

actor y del caso de uso, junto con líneas conectoras.

Los actores son similares a las entidades externas;

existen fuera del sistema.

El término actor se refiere a un rol específico de un

usuario del sistema. Por ejemplo, un actor puede ser un
empleado, pero también puede ser un cliente en la tienda
de la empresa. Incluso cuando es la misma persona en el
mundo real, se representa como dos símbolos distintos
en un diagrama de caso de uso, ya que la persona
interactúa con el sistema en distintos roles.
 Símbolos de los casos de uso

El actor existe fuera del sistema e interactúa con éste de

una manera específica. Un actor puede ser un humano,
otro sistema o un dispositivo como un teclado o una
conexión Web.

Los actores pueden iniciar una instancia de un caso de

uso.

Un actor puede interactuar con uno o más casos de uso;

un caso de uso puede involucrar a uno o más actores.
 Símbolos de los casos de uso

Los actores se pueden dividir en grupos.

Los actores principales suministran datos o reciben

información del sistema.

Algunos usuarios interactúan en forma directa con el

sistema (actores del sistema), pero los actores
principales también pueden ser personas de negocios
que no interactúen directamente con el sistema sino que
participen en cierta forma.

Los actores principales son importantes ya que son las

personas que usan el sistema y pueden proveer los
detalles acerca de lo que debería hacer el caso de uso.
 Símbolos de los casos de uso

También pueden proveer una lista de objetivos y

prioridades.

Los actores de soporte (también conocidos como actores

secundarios) ayudan a mantener el sistema en
funcionamiento o a proveer otros servicios; son las
personas que operan el departamento de soporte
técnico, los analistas, los programadores, etcétera.
 Símbolos de los casos de uso

Algunas veces es conveniente crear un perfil de actor

que enliste a los actores, su historial y sus habilidades en
un formato de tabla.

Esto puede ser útil para entender cómo interactúa el

actor con el sistema.

Por ejemplo, el perfil del Especialista de procesamiento

de pedidos sería: “Un usuario rutinario del software,
familiarizado con las características menores, las
excepciones de los pedidos y la personalización de
pedidos”.
 Símbolos de los casos de uso

También es conveniente hacer una lista de los actores

junto con sus objetivos y prioridades. Cada objetivo se
puede convertir en un caso de uso.

Un caso de uso provee a los desarrolladores una

perspectiva de lo que quieren los usuarios, sin detalles
técnicos o implementación.

Podemos considerar un caso de uso como una

secuencia de transacciones en un sistema.

El modelo de casos de uso se basa en las interacciones

y relaciones de casos de uso individuales.
 Símbolos de los casos de uso

Un caso de uso siempre describe tres cosas:

• un actor que inicia un evento,

• el evento que desencadena un caso de uso y;
• el caso de uso que realiza las acciones
desencadenado por el evento.
 Símbolos de los casos de uso

En un caso de uso, un actor que utiliza el sistema inicia

un evento que comienza una serie relacionada de
interacciones en el sistema.

Los casos de uso se utilizan para documentar una

transacción o evento únicos.

Un evento es una entrada para el sistema que ocurre a

una hora y lugar específicos, y provoca que el sistema
haga algo.
 Símbolos de los casos de uso

Es mejor crear menos casos de uso que un exceso de

ellos.

A menudo no se incluyen las consultas y los informes; 20

casos de uso (y no más de 40 o 50) son suficientes para
un sistema grande.

Los casos de uso también se pueden anidar, si es

necesario.
 Símbolos de los casos de uso

Algunos casos de uso utilizan el verbo administrar para

agrupar casos de uso de manera que se puedan agregar,
eliminar y cambiar a otro diagrama de casos de uso de
menor nivel.

Usted puede incluir un caso de uso en varios diagramas,

pero el verdadero caso de uso está definido sólo una vez
en el repositorio.

El nombre de un caso de uso consta de un verbo y un

sustantivo.
 Relaciones de los casos de uso

Las relaciones activas se conocen como relaciones de

comportamiento y se utilizan principalmente en los
diagramas de casos de uso.

Hay cuatro tipos básicos de relaciones de

comportamiento:
• comunica,
• incluye,
• extiende y;
• generaliza.

Observe que todos estos términos son verbos.

 Relaciones de los casos de uso

En la figura se muestran las flechas y líneas que se

utilizan para dibujar diagramas de cada uno de los cuatro
tipos de relaciones de comportamiento.

A continuación describiremos estas cuatro relaciones.

 COMUNICACIÓN

Esta relación de comportamiento se utiliza para conectar

un actor con un caso de uso.

Recuerde que la tarea del caso de uso es proporcionar

cierto tipo de resultado que sea benéfico para el actor en
el sistema.

Por lo tanto, es importante documentar estas relaciones

entre los actores y los casos de uso.
 COMUNICACIÓN

En nuestro primer
ejemplo, un
Estudiante se
comunica con Inscribir
en el curso.

En los diagramas de
casos de uso de la
figura se muestran
ejemplos de algunos
componentes de un
ejemplo de inscripción
de estudiantes.
 INCLUSIÓN

Esta relación (también conocida como relación de usos) describe la

situación en la que un caso de uso contiene comportamiento común
para más de un caso de uso.

En otras palabras, el caso de uso común se incluye en los otros

casos de uso.

Una flecha punteada que apunta al caso de uso común indica la

relación de inclusión.

Un ejemplo sería un caso de uso Pagar cuotas de estudiantes que

se incluye en Inscribir en el curso y Hacer arreglos de
hospedaje, ya que en ambos casos los estudiantes deben pagar
sus cuotas. Varios casos de uso pueden usar esto. La flecha apunta
hacia el caso de uso común.
 EXTENSIÓN

Esta relación describe la situación en la que un caso de

uso posee el comportamiento que permite al nuevo caso
de uso manejar una variación o excepción a partir del
caso de uso básico.

Por ejemplo, el caso de uso extendido Seguro médico

de estudiantes extiende el caso de uso básico Pagar
cuotas de estudiantes. La flecha va del caso de uso
extendido al caso de uso básico.
 GENERALIZACIÓN

Esta relación implica que una cosa es más común que

otra.

Esta relación puede existir entre dos actores o dos casos

de uso.

Por ejemplo, un Estudiante de medio tiempo generaliza

a un Estudiante. De manera similar, algunos de los
empleados de la universidad son profesores. La flecha
apunta a la cosa general.
Bibliografía
ANÁLISIS Y DISEÑO DE SISTEMAS
OCTAVA EDICIÓN
KENNETH E. KENDALL
JULIE E. KENDALL

Prentice Hall

FIN