• No se han encontrado resultados

DESCRIPCIÓN GRÁFICA DE SISTEMAS

In document ANÁLISIS Y DISEÑO DE SISTEMAS (página 58-65)

Un sistema, o subsistema, tal como existe dentro de una organización, se puede describir gráficamente de varias maneras. Los diversos modelos gráficos muestran las fronteras y la in- formación que se utiliza en el sistema.

SISTEMAS Y EL DIAGRAMA DE FLUJO DE DATOS DE CONTEXTO

El primer modelo es el diagrama de flujo de datos de contexto (también denominado mo- delo del entorno). Los diagramas de flujo se enfocan en el flujo de datos que entran y sa- len del sistema y en el procesamiento de los datos. Estos componentes básicos de cada pro- grama de cómputo se pueden describir en detalle y utilizar para analizar la precisión y plenitud del sistema.

Como se muestra en la figura 2.4, el diagrama de flujo de datos de contexto sólo em- plea tres símbolos: (1) un rectángulo con esquinas redondeadas, (2) un cuadrado con dos bordes sombreados y (3) una flecha. Los procesos transforman los datos entrantes en infor- mación de salida, y el nivel de contenido sólo tiene un proceso, que representa el sistema completo. La entidad externa representa cualquier entidad que proporciona o recibe infor- mación del sistema pero que no forma parte del mismo. La entidad podría ser una persona, un grupo de personas, un puesto o departamento de una corporación, u otros sistemas. Las líneas que conectan a las entidades externas con el proceso se denominan flujos de datos, y representan datos.

En la figura 2.5 se ofrece un ejemplo de diagrama de flujo de datos de contexto, que re- presenta los elementos más básicos de un sistema de reservaciones de una aerolínea. El pa- sajero (una entidad) llena una solicitud de viaje (el flujo de datos). El diagrama de contexto no muestra suficientes detalles para indicar con exactitud lo que sucede (ése no es su pro- pósito), pero podemos apreciar que las preferencias del pasajero y los vuelos disponibles se

Un proceso denota la ejecución de alguna acción o grupo de acciones.

I C. ~. l ih'ili.'i h M C I " 'l:j li i J . ' ' . . i i . •!•• l i l . i .

Una entidad es una persona, un grupo, un departamento o cualquier sistema que recibe o emite información o datos.

Un flujo de datos muestra que la información se emite o se recibe de un proceso.

envían al agente de viajes, quien a su vez envía información sobre la venta de boletos al pro- ceso. También podemos ver que la reservación del pasajero se envía a la aerolínea.

En el capítulo 7 veremos que un flujo de datos contiene una cantidad considerable de información. Por ejemplo, la reservación del pasajero contiene el nombre de éste, la aerolí- nea, el (los) número(s) de vuelo, la (las] fecha(s) de viaje, el precio, el asiento preferido, etc. Sin embargo, por el momento únicamente nos interesa analizar la manera en que el diagrama de contexto define las fronteras del sistema. En el ejemplo anterior, tan sólo las reservacio- nes forman parte del proceso. Algunas decisiones relacionadas que podría tomar la aerolínea (como la compra de aviones, el cambio de programación de vuelos, la fijación de precios) no forman parte de este sistema.

SISTEMAS Y EL MODELO DE ENTIDAD-RELACIÓN

Una forma en que un analista de sistemas puede definir fronteras de sistema apropiadas es mediante el uso de un modelo de entidad-relación. Los elementos que conforman un sis-

Preferencias y vuelos disponibles

r-ISURA 2.5

iJn : J i " í ; n r i i 1 ¡l< '.K;-- C¿ c:.,ii:-,

< .' ( i:-| i.X O '1.1'í. I'1 '.IVv.ül!-! l i l :

• • •!•.••!• i . - i i - .!•.: . i i i - - . . i r . I !• v ¡ . Solicitud de vuelo 0 Sistema de reservaciones de la aerolínea Información sobre la venta de boletos Reservación del pasajero Aerolínea

FISURA 2.6

Un diagrama de entidad-relación que muestra una relación uno a uno.

tema organizacional se pueden denominar entidades. Una entidad podría ser una perso- na, un lugar o una cosa, como el pasajero de una aerolínea, un destino o un avión. Asimismo, una entidad podría ser un evento, como un fin de mes, un periodo de ventas o la descom- postura de una máquina. Una relación es la asociación que describe la interacción entre las entidades.

Existen diversas convenciones para dibujar diagramas de entidad relación, o E-R (con nombres como notación de pata de cuervo, Flecha o Bachman). En este libro utilizamos la notación de pata de cuervo. Por el momento, daremos por sentado que una entidad es un rectángulo plano.

La figura 2.6 muestra un diagrama de entidad-relación sencillo. Dos entidades se co- nectan mediante una línea. En este ejemplo, los extremos de la línea se marcan con dos líneas paralelas cortas (II), lo cual denota que esta relación es de uno a uno. De esta mane- ra, exactamente un empleado es asignado a una extensión telefónica. Nadie más comparte la extensión telefónica en esta oficina.

Las flechas no forman parte del diagrama de entidad-relación. Su propósito es demos- trar cómo se debe leer el diagrama de entidad-relación. La frase del lado derecho de la línea se lee de la siguiente manera, de arriba hacia abajo: "Un EMPLEADO es asignado a una EX-

FiGÜRA 2.7

ue

que muestra una relación muchos a uno.

TENSIÓN TELEFÓNICA". Del lado izquierdo, al leer de abajo hacia arriba, la flecha dice: "Una EXTENSIÓN TELEFÓNICA se registra a nombre de un EMPLEADO".

De igual manera, en la figura 2.7 se muestra otra relación. La notación de pata de cuer- vo (V-t-) es evidente en este diagrama, que ilustra una relación muchos a uno. Al leer de iz- quierda a derecha, la flecha significa: "Muchos EMPLEADOS son miembros de un DEPAR- TAMENTO". Al leer de derecha a izquierda, indica: "Un DEPARTAMENTO contiene muchos EMPLEADOS".

Observe que cuando se presenta una relación muchos a uno, la gramática cambia de "es" a "son", aun cuando el singular "es" se escribe sobre la línea. La pata de cuervo y la linea paralela corta no significan literalmente que este extremo de la relación debe ser un "muchos" obligatorio. Más bien, implica que este extremo puede ser de uno o de muchos.

En la figura 2.8 se dan más detalles de este esquema, con varias relaciones comunes en- tre entidades. La primera, "Un EMPLEADO es asignado a una OFICINA", es una relación uno a uno. La segunda es una relación uno a muchos. "Un AVIÓN DE CARGA dará servicio a uno o más CENTROS DE DISTRIBUCIÓN". El tercero es ligeramente distinto porque tiene un círculo en uno de sus extremos. Se puede leer como "Un ANALISTA DE SISTE- MAS podría ser asignado a MUCHOS PROYECTOS", lo que significa que el analista podría ser asignado a ningún proyecto [eso es lo que significa el círculo [O], de cero], a uno o a muchos proyectos. De igual manera, el círculo (O) indica que en la relación próxima cabe la posibilidad de que no haya nada. Por lo tanto, podemos leer de la siguiente manera: "Una MÁQUINA podría o no recibir MANTENIMIENTO PROGRAMADO". Observe que en

Empleado es asignado a

es ocupada por Oficina

FIGURA 2 . 8

Ejemplos de diversos tipos de relaciones en diagramas E-R.

Avión de carga • -H+ dará servicio a recibirá servicio de Contra de distribución Analista de sistemas es asignado a será desarrollado por<X

Máquina Agcnlc de vantas recibe '>+• se da a es asignado a -CM- es llamado por - K Mantenimiento programado Cliente

Oficina en casn - K > tiene

es asignado a - K Empleado

Pasajero vuela a

será visitado por i Destino

la línea se escribe "recibe", pero las marcas al final de la línea indican que en realidad no se recibe mantenimiento (O) o sí se recibe mantenimiento [I].

La siguiente relación indica: "Uno o muchos AGENTES DE VENTAS (plural de AGENTE DE VENTAS) son asignados a uno o muchos CLIENTEs". Es la clásica relación muchos a muchos. La siguiente relación se puede leer así: "La OFICINA EN CASA puede tener uno o muchos EMPLEADOS", o "Uno o muchos EMPLEADOs podrían ser o no asignados a la OFICINA EN CASA". Una vez más, la I y el O juntos implican un caso boo- leano, es decir, uno o cero.

La última relación que se muestra puede leerse como: "Muchos PASAJEROS vuelan a muchos DESTINOs". Algunas personas prefieren utilizar el símbolo [—<] para denotar una condición "muchos" obligatoria. (¿Sería posible contar con sólo un pasajero o sólo un desti- no?} Aún así, algunas herramientas CASE como Visible Analyst no ofrecen esta posibilidad, aunque la condición uno o muchos opcional como se muestra en la relación AGENTE DE VENTAS-CLIENTE sí lo hará.

Hasta el momento hemos modelado todas nuestras relaciones utilizando tan sólo un rectángulo sencillo y una línea. Este método es adecuado al examinar las relaciones de cosas reales como personas, lugares y objetos. No obstante, en ocasiones creamos nuevos elemen- tos en el proceso de desarrollo de un sistema de información, como facturas, recibos, archivos y bases de datos. Por ejemplo, cuando deseamos describir la relación entre una persona y un recibo es mejor indicar de una manera distinta el recibo, como se muestra en la figura 2.9 en forma de entidad asociativa.

Una entidad asociativa sólo puede existir si se conecta al menos con dos entidades más. Por este motivo, algunos la denominan conjunción, unión, intersección o entidad concate- nada. Esta definición tiene lógica porque un recibo sólo es necesario si hay un cliente y un agente de ventas que realicen la transacción.

Otro tipo de entidad es la atributiva. Cuando un analista desea mostrar datos que de- penden totalmente de la existencia de una entidad fundamental, debe utilizar una entidad atributiva. Por ejemplo, si una tienda de vídeos tiene muchas copias del mismo título de DVD, se podría utilizar una entidad atributiva para determinar cuál copia del DVD se está rentando. Las entidades atributivas son útiles para repetir grupos de datos que se repiten. Por ejemplo, suponga que vamos a modelar las relaciones que existen cuando un cliente ha- bitual compra boletos para un concierto o un espectáculo. De entrada, las entidades parecen evidentes: "un CLIENTE y un CONCIERTO/ESPECTÁCULO", como se observa en la figura 2.10. ¿Qué tipo de relación existe? A primera vista el CLIENTE obtiene una reser- vación para un CONCIERTO/ESPECTÁCULO, y se puede decir que el CONCIER- TO/ESPECTÁCULO ha realizado una reservación para un CLIENTE.

FIGURA 2.9

Tres tipos distintos de entidades

que se utilizan en diagramas E-R. Entidad

fundamental Por lo general, una entidad real:una persona, un lugar o una cosa

Algo que se crea para unir dos entidades

/

\

Entidad atributiva

Algo útil para describir atributos, especialmente grupos que se repiten

FIGURA 2 . 1 0 • • - 1 . • • • . • . i > - " i : hace una reservación para /k obtiene una reservación para Concierto/ Espectáculo

Por supuesto, el proceso no es tan sencillo, y el diagrama E-R tampoco tiene que ser tan sencillo. En realidad, el CLIENTE obtiene una reservación, como se muestra en la figu- ra 2.11. La RESERVACIÓN es para un CONCIERTO/ESPECTÁCULO. El CONCIER- TO/ESPECTÁCULO hace la RESERVACIÓN y la RESERVACIÓN está a nombre del CLIENTE. Aquí agregamos una entidad asociativa porque el sistema de información re- quería una RESERVACIÓN para relacionar al CLIENTE con el CCNCIERTÓ/ESPEC- TÁCULC.

De nueva cuenta este proceso es demasiado sencillo, pero dado que los conciertos y los espectáculos tienen muchas funciones, el diagrama de entidad-relación se dibuja una vez más en la figura 2.12, en la cual hemos incorporado una entidad atributiva para manejar las

está a nombre de

FIGURA 2 . 1 1

Mejora del diagrama E-R mediante la incorporación de una entidad asociativa denominada RESERVACIÓN. obtiene . ... tiene es paraun Concierto/ Espectáculo

FIGURA 2.12

Diagrama E-R más completo que muestra atributos de daios de las entidades.

a nombre de obtiene tiene es para una tiene pertenece a Concierto/ Espectáculo Nombre-cliente Dirección-cliente Teléfono-cliente Tarjeta-crédito-cliente Número-reservación Nombre-cliente Número-función Concierto/Espectáculo Fecha Hora Localidad Precio Número-función Concierto/Espectáculo Fecha Hora Localidad Opciones-precio Concierto/Espectáculo Detalles-concierto Fechas-de-evento Localidad

numerosas funciones del CONCIERTO/ESPECTÁCULO. En este caso la RESERVACIÓN se realiza para una FUNCIÓN específica, y la FUNCIÓN es una de las tantas que perte- necen a un CÓNCIERTÓ/ESPECTÁCULÓ. A su vez, el CÓNCIERTÓ/ESPECTÁCU- Ló tiene muchas funciones, y una FUNCIÓN tiene una RESERVACIÓN a nombre de un CLIENTE específico.

A la derecha de este diagrama E-R se encuentra un conjunto de atributos de datos que conforman a cada una de las entidades, algunas de las cuales podrían tener atributos en co- mún. Los atributos subrayados se pueden buscar. Los atributos se mencionan como claves y se describen en el capítulo 13.

Los diseñadores de sistemas utilizan con frecuencia los diagramas entidad-relación pa- ra modelar archivos o la base de datos. Sin embargo, es aún más importante que el analista de sistemas entienda en las fases iniciales las entidades y las relaciones del sistema organiza- cional. Para bosquejar algunos diagramas E-R básicos, el analista necesita:

1. Enumerar las entidades de la organización para comprenderla mejor.

2. Seleccionar entidades clave para reducir el alcance del problema a una dimensión ma- nejable y que tenga sentido.

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

4. Confirmar los resultados de los pasos 1 a 3 a través de otros métodos de recopilación de datos (investigación, entrevistas, aplicación de cuestionarios, observación y elaboración de prototipos), como se describe en los capítulos 4 a 6.

Es muy importante que el analista de sistema comience a dibujar diagramas E-R tan pronto se incorpore a la organización en vez de esperar a que se diseñe la base de datos, por- que estos diagramas son útiles para que el analista entienda cabalmente el negocio en el que se desenvuelve la organización, determine el tamaño del problema y distinga si se está abor- dando el problema correcto. Es necesario confirmar o revisar los diagramas E-R conforme se realiza el proceso de recopilación de datos.

Los factores organizacionales que influyen en el análisis y diseño de sistemas de infor- mación son los niveles de administración y la cultura organizacional. En las secciones res- tantes de este capítulo describiremos cada uno de estos factores y sus implicaciones para el análisis y diseño de sistemas de información.

In document ANÁLISIS Y DISEÑO DE SISTEMAS (página 58-65)