1.2 Elementos de un Sistema
Una definición básica de sistema es la siguiente: Grupo de elementos interdependientes o que interactuan regularmente formando un todo, a continuación se enumeran diversos ejemplos.
Un sistema gravitacional, un sistema termodinámico, un sistema de ríos, un sistema telefónico, un sistema de autopistas, el sistema newtoniano de la mecánica, el sistema de mecanografía al tacto, un sistema taxonómico, el sistema decimal, etcétera.
James Grier Miller en su libro Living System destaca 19 subsistemas críticos de todos los sistemas vivientes, haciendo una analogía con los mismos se pueden categorizar de la manera siguiente:
El reproductor, que es capaz de dar origen a otros sistemas similares aquel en el cual se encuentra. En una organización de negocios, pudiera ser una división de planeación de instalaciones que hace nuevas plantas y construye oficinas regionales nuevas.
La frontera, que mantiene unidos a los componentes que conforman el sistema, los protege de tensiones ambientales y excluye o permite la entrada de diversos tipos de materia-energía e información. En una organización de negocios, esto pudiera constituir la planta misma y los guardias u otro personal de seguridad que evitan el ingreso de intrusos indeseables.
El inyector, que transporta la materia-energía a través de la frontera del sistema desde el medio ambiente. En una organización de negocios, este pudiera ser el departamento de compras o recepción, que introduce la materia prima, los materiales de oficina, etc.
El distribuidor, que trae material desde el exterior del sistema y lo reparte desde sus subsistemas a cada componente. En una organización de negocios, pudiera estar conformado por las líneas telefónicas, correo electrónico, mensajeros, bandas, etc.
El convertidor, que cambia ciertos materiales que ingresan al sistema a formas más útiles para los procesos especiales de dicho sistema particular.
El productor, que forma asociaciones estables durables por períodos significativos con la materia-energía que ingresa al sistema o que egresa de su convertidor. Estos materiales sintetizados pueden servir para crecimiento o reparación de daños o reposición de componentes del sistema.
El subsistema de almacenamiento de materia-energía, que retiene en el sistema, durante diferentes períodos, depósitos de diversos tipos de materia-energía.
El expulsor, que transmite materia-energía hacia el exterior del sistema en forma de desechos o de productos.
El motor, que mueve el sistema o a sus partes en relación con todo o parte del medio ambiente, o bien que mueve a los componentes del ambiente.
El soporte, que mantiene las relaciones espaciales apropiadas entre los componentes del sistema, de manera que pueden interactuar sin ser un lastre o estorbo entre ellos.
El transductor de entrada, que traen señales portadoras de información al sistema, transformándolas en otras formas de materia-energía adecuadas para su transmisión al interior.
El transductor interno, que recibe de otros subsistemas o componentes del sistema señales que portan información acerca de alteraciones significativas en dichos subsistemas o componentes, transformándolos en otras formas de materia-energía transmisibles en su interior.
El canal y la red, que están compuestos por una sola ruta en el espacio físico, o bien por múltiples rutas interconectadas, mediante las cuales las señales portadoras de información se transmiten a todas partes del sistema.
El decodificador, que altera las claves de información que le es introducida por medio del transductor de entrada o del transductor interno, para dejar una clave privada que pueda ser utilizada internamente por el sistema.
El asociador, que lleva a cabo la primera etapa del proceso de aprendizaje, formando asociaciones duraderas entre elementos de información dentro del sistema.
La memoria, que lleva a cabo la segunda etapa del aprendizaje, almacenando diversos tipos de información en el sistema durante diferentes períodos.
El que decide, que recibe información de los demás subsistemas y les transmite información que sirve para controlar al sistema completo.
El codificador, que altera la clave de información que se le introduce desde otros subsistemas procesadores de información, convirtiéndola, de una clave privada utilizada internamente por el sistema, en una clave pública que pueden ser interpretada por otros sistemas en su medio ambiente.
El transductor de salida, que emite señales portadoras de información desde el sistema, transformando los marcadores dentro del sistema en otras formas de materia-energía que pueden ser transmitidas por medio de canales en el medio ambiente del sistema.
1.3 Sistemas de información más comúnes.
Existen dos categorías básicas en la clasificación de sistemas:
- Sistemas naturales.
- Sistemas hechos por el hombre.
Es conveniente dividir los sistemas naturales en dos subcategorías básicas:
? Sistemas físicos.
? Sistemas vivientes.
Los sistemas físicos incluyen:
? Sistemas estelares: galaxias, sistemas solares, etcétera.
? Sistemas geológicos: ríos, cordilleras, etcétera.
? Sistemas moleculares: organizaciones complejas de átomos.
Los sistemas vivientes comprenden toda gama de animales y plantas que nos rodean, al igual que la raza humana.
En lo que respecta a los sistemas hechos por el hombre existen una gran diversidad de sistemas construidos, organizados y mantenidos por humanos, tales como: sistemas sociales, sistemas de transporte, sistemas de comunicación, Sistemas de manufactura, sistemas financieros.
En la actualidad, la mayoría de estos sistemas incluyen las computadoras pero es importante señalar que dichos sistemas existían antes de que hubiera computadoras; de hecho, algunos sistemas continúan por completo sin computarizar y podrían permanecer así durante muchas décadas más. Otros contienen a la computadora como componente, pero también incluyen uno o más componentes no computarizados (o manuales).
Los sistemas automatizados son sistemas hechos por el hombre que interactuan con o son controlados por una o más computadoras. Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener componentes en común:
- El hardware de la computadora: los procesadores, los discos, terminales, impresora, unidades de cinta magnética, etcétera.
- El software de la computadora: Los programas de sistemas tales como sistemas operativos, sistemas de base de datos, programas de control de telecomunicaciones, etcétera.
- Las personas: los que operan el sistema, los que proveen su material de entrada y consumen su material de salida, y los que proveen actividades de procesamiento manual en un sistema.
- Los datos: la información que el sistema recuerda
- Los procedimientos: las políticas formales e instrucciones de operación del sistema.
Una división categórica de los sistemas automatizados es la siguiente:
? Sistemas en línea.
? Sistemas de tiempo real.
? Sistemas de apoyo a decisiones.
? Sistemas basados en el conocimiento.
Sistemas en línea: es aquel que acepta material de entrada directamente del área donde se creo. También es sistema en el que el material de salida, o resultado de la computación, se devuelve directamente a donde es requerido.
Sistemas de tiempo real: puede definirse como aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese momento.
Sistemas de apoyo a decisiones: Estos sistemas computacionales no toman decisiones por si mismos, sino ayudan a los administradores, y a otros profesionistas "trabajadores del conocimiento" de una organización a tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de la operación.
Sistemas basados en el conocimiento: Estos sistemas contienen grandes cantidades de diversos conocimientos que emplean en el desempeño de una tarea dada. Los sistemas expertos son una especie de sistemas basados en el conocimiento, aunque ambos términos a menudo se utilizan indistintamente.
Existen algunos principios generales que son de interés particular para quienes crean sistemas automatizados de información, e incluyen los siguientes:
- Entre más especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes.
- Cuanto mayor sea el sistema mayor es el número de sus recursos que deben dedicarse a su mantenimiento diario.
- Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en sistemas menores.
- Los sistemas crecen.
2.1 Modelo Clásico.
En el modelo clásico, cada proyecto atraviesa por algún tipo de análisis, diseño e implantación, aunque no se haga exactamente como se muestra en la figura 2.1.1(a) El ciclo de vida de proyecto utilizado, pudiera diferir del que se muestra en la figura 2.1.1(a) en una o todas de las formas siguientes:
- La fase de exploración y análisis pudieran juntarse en una sola.
- Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con las computadoras existentes sin causar mayor problema operacional.
- La fase de diseño preliminar y el diseño de detalles pudieran juntarse en una sola llamada simplemente de diseño.
- Diversas fases de pruebas pueden juntarse en una sola; de hecho, podrían incluirse con la codificación.
Figura 2.1:El ciclo de vida del proyecto clásico
El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los proyectos clásicos. Como se podrá ver en la figura 2.1, se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada. .
Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran número de dificultades serias:
- Nada esta hecho hasta que todo esté terminado.
- Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al final.
- La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema.
- La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba.
La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente. Querer esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella. El único problema del progreso ordenado es que no es nada realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos gubernamentales que afectan a las actividades del usuario).
2.2 Modelo Semiestructurado.
En la figura 2.2.1 se muestra el modelo semiestructurado, en donde se observa la siguiente diferencia con respecto al modelo clásico:
"La secuencia ascendente de codificación, la prueba de módulos y prueba del sistema se reemplaza por una implementación de arriba hacia abajo, que es un enfoque en el cual los módulos de alto nivel se codifican y prueban primero, seguidos por los más detallados de bajo nivel".
Figura 2.2:Modelo semiestructurado
Dentro del modelo semiestructurado encontramos otros detalles tales como, la implementación descendente que significa que se pondrán en ejecución paralelamente parte de la codificación y de las pruebas. Dándose con lo anterior una retroalimentación entre la codificación, la prueba y la eliminación de las fallas.
Como último punto acerca del modelo semiestructurado, tenemos que una gran parte del trabajo que se realiza bajo el nombre de "diseño estructurado" es en realidad un esfuerzo manual para enmendar especificaciones erróneas. Otra funcion de los diseñadores, es traducir un documento narrativo, ambiguo, monolítico y redundante a un modelo útil, que sirva de base para derivar la jerarquía de módulos que cumplan con los requisitos del usuario.
En general con este enfoque de desarrollo de sistemas los diseñadores tenían poco contacto con el analista que escribía la especificación y definitivamente "no tenía contacto con el usuario".
2.3 Modelo Estructurado.
En el modelo estructurado se examinan brevemente las nueve actividades y los tres terminadores que lo componen, como se muestra en la figura 2.3.1. Los terminadores son los usuarios, los administradores, y el personal de operaciones. Los cuales se tratan de individuos o grupos que proporcionan la entrada al equipo del proyecto, y son los beneficiados finales del sistema.
Figura 2.3: Modelo Estructurado
Actividad 1: La encuesta
Esta actividad también se conoce como el estudio de factibilidad o como el estudio inicial de negocios. Empieza cuando el usuario solicita que una o más partes de su sistema se automaticen. Los principales objetivos de la encuesta son:
- Identificar a los usuarios responsables y crear ""un campo de actividad" inicial del sistema.
- Identificar las deficiencias actuales en el ambiente del usuario.
- Establecer metas y objetivos para un sistema nuevo.
- Determinar si es factible automatizar el sistema y de ser así, sugerir escenarios aceptables.
- Preparar el esquema que se usará para guiar el resto del proyecto.
En general, la encuesta ocupa sólo del 5 al 10 por ciento del tiempo y los recursos de todo el proyecto, y para los proyectos pequeños y sencillos pudiera ni siquiera ser una actividad formal. A pesar de todo lo anterior, es una actividad importante debido a que la administración pudiera decidir cancelar el proyecto si no parece atractivo desde el punto de vista de costo-beneficio.
Actividad 2: El análisis de sistemas
El propósito principal de la actividad de análisis es transformar sus dos entradas - o insumos o factores - principales, las políticas del usuario y el esquema del proyecto, en una especificación estructurada. Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad-relación, diagramas de transición de estado, etc.
El proceso paso a paso del análisis de sistemas implica el desarrollo de un modelo ambiental y el desarrollo de un modelo de comportamiento, los cuales se combinan para formar el modelo esencial que representa una descripción formal de lo que el nuevo sistema debe hacer, independientemente de la naturaleza de la tecnología que se use para cubrir los requerimientos.
Al final de la actividad de análisis también se debe preparar un conjunto de presupuestos y cálculos de costo y beneficio más precisos y detallados.
Actividad 3: El diseño
La actividad de diseño se dedica a asignar porciones de la especificación (modelo esencial) a procesadores adecuados (máquinas o humanos) y a labores apropiadas (o tareas, particiones, etc.) dentro de cada procesador. Dentro de cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de módulos de programas y de interfases entre ellos para implantar la especificación creada en la actividad 2. Además, se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos.
Actividad 4: Implantación
Esta actividad incluye la codificación y la integración de módulos en un esqueleto progresivamente más complejo del sistema final. Por eso, la actividad 4 incluye tanto programación estructurada como implantación descendente.
Actividad 5: Generación de pruebas de aceptación
La especificación estructurada debe contener toda la información necesaria para definir un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptación desde la especificación estructurada.
Actividad 6: Garantía de calidad
La garantía de calidad también se conoce como la prueba final o la prueba de aceptación. Esta actividad requiere como entradas los datos de la prueba de aceptación generada en la actividad 5 y el sistema integrado producido en la actividad 4.
Actividad 7: Descripción del procedimiento
Esta actividad implica la generación de una descripción formal de las partes del sistema que se harán en forma manual, lo mismo que la descripción de como interactuarán los usuarios con la parte automatizada del nuevo sistema. El resultado de la actividad 7 es un manual para el usuario.
Actividad 8: Conversión de bases de datos
En algunos proyectos, la conversión de bases de datos involucraba más trabajo que el desarrollo de programas de computadoras para el nuevo sistema. En otros casos, pudiera no haber existido una base de datos que convertir. En el caso general, esta actividad requiere como entrada las base de datos actual del usuario, al igual que la especificación del diseño producida por medio de la actividad 3.
Actividad 9: Instalación
En esta actividad sus entradas son el manual del usuario producido en la actividad 7, la base de datos convertida que se creó con la actividad 8 y el sistema aceptado producido por la actividad 6. En algunos casos la instalación pudiera significar simplemente un cambio de la noche a la mañana al nuevo sistema; en otros casos, la instalación pudiera ser un proceso gradual, en el que un grupo tras otro de usuario van recibiendo manuales y entrenamiento y comenzado a usar el nuevo sistema.
3.1 Modelo Esencial.
El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posible acerca de como se implanta.
Específicamente, esto significa que cuando el analista habla con el usuario acerca de los requerimientos del sistema, debe evitar describir implantaciones especificas de procesos (burbujas en un diagrama de flujo de datos) en el sistema; es decir, no debe mostrar las funciones del sistema que están siendo realizadas por humanos o por sistemas de computo existentes. Como lo ilustran las figuras 3.1.1(a), ésta opción arbitrarias de cómo podría implantarse el sistema; pero esta decisión debería retrasarse hasta que haya comenzado la actividad de diseño.
Figuras: 3.1.1(a):Modelo que muestra como hará su labor una función
La figura 3.1.1(b) muestra un modelo esencial más apropiado de lo que la función del sistema debe realizar sin importar su implantación final.
Figura 3.1.1(b): Un modelo de cual es la función del sistema
Lo mismo se da para los flujos y almacenes de datos: el modelo esencial debe describir el contenido de los flujos o almacenes de datos, sin describir el medio (por ejemplo, disco o cinta) u organización física de los datos.
El modelo esencial consiste en dos componentes principales:
2.- Modelo de comportamiento
Recuerde que es importante desarrollar el modelo esencial de un sistema, pues muchos sistemas de información grandes tienen una vida media de unos
Para el analista de sistemas, la labor más difícil en la especificación de un sistema es a menudo determinar qué es parte del sistema y qué no.
Así, el primer modelo importante que se debe desarrollar como analista es uno que no haga más que definir las interfaces entre el sistema y el resto del universo, es decir, el ambiente. Por razones obvias, este modelo se conoce como el modelo ambiental. Por lo tanto, se necesita saber qué información entra al sistema desde el ambiente exterior, y qué información produce como salida al ambiente externo.
Otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. No para todos los acontecimientos; después de todo, el ambiente en su totalidad genera un número infinito de acontecimientos. Sólo nos preocupan aquellos que (1) ocurren en el ambiente exterior y (2) requieren una respuesta del sistema.
En un sistema grande se puede tomar en cuenta una cantidad de factores cuando se están escogiendo las perspectivas del proyecto. Entre los más importantes están los siguientes:
El deseo del usuario de lograr cierta participación en el mercado para el producto, o incrementarla a más de su nivel actual. Esto se puede hacer ofreciendo un nuevo producto o una mayor funcionalidad de uno existente.
La legislación establecida por el gobierno federal, estatal, o de la ciudad. Por ejemplo tendría que hacerse un nuevo sistema para considerar los cambios en las leyes sobre impuestos.
Deseo del usuario por minimizar gastos operativos de alguna área de su negocio. La mayor parte de las organizaciones que han tenido computadoras instaladas durante 10 años o más ya aprovecharon las oportunidades obvias de reducir el personal de oficina.
Deseo del usuario para lograr alguna ventaja estratégica para la línea de productos o áreas de negocios que opera. Un buen ejemplo de estos son las líneas aéreas donde mejor información acerca de tendencias del mercado y preferencias de los clientes pueden llevar a costos de pasajes e itinerarios de aerolíneas más eficientes.
A continuación se presentan dos tópicos importantes en el modelo ambiental:
Herramientas usadas para definir el ambiente
Construcción del modelo ambiental
3.2.1 Herramientas usadas para definir el ambiente.
El modelo ambiental consta de tres componentes:
1.- Declaración de propósitos.
2.- Diagrama de contexto.
3.- Lista de acontecimientos.
La declaración de propósitos consiste en la declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo superior, la administración de los usuarios, y otros que no están directamente involucrados con el desarrollo del sistema.
El siguiente es un ejemplo de la declaración de propósito típica:
El propósito del Sistema de Procesamiento de Libros Ajax es manejar todos los detalles de los pedidos de los libros de los clientes, además del envío, facturación y cobro retroactivo a clientes con facturas vencidas. La información acerca de los pedidos de los libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y contabilidad.
El diagrama de contexto es un caso especial de diagrama de flujo de datos, en donde una sola burbuja representa todo el sistema. La figura 3.2.1 muestra un diagrama de contexto de un sistema de pedidos de libros.
Figura 3.2.1: Diagrama de contexto
El diagrama de contexto enfatiza varias características importantes del sistema:
- Las personas, organizaciones y sistemas con los que se comunica el sistema. Se conocen como terminadores.
- Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma.
- Los datos que el sistema produce y que se envían al mundo exterior.
- Los almacenes de datos que el sistema comparte con los terminadores. Estos almacenes de datos se crean fuera del sistema para su uso, o bien son creados en él y usados fuera.
- La frontera entre el sistema y el resto del mundo.
La lista de acontecimientos es una lista narrativa de los estímulos que ocurren en el mundo exterior a los cuales el sistema debe responder. A continuación se muestra una lista de acontecimientos para el sistema de pedidos de libros.
1.- Un cliente hace un pedido (F).
2.- Un cliente cancela un pedido (F).
3.- La administración pide un reporte de ventas (T).
4.- Llega un pedido de reimpresión de un libro a la bodega (C).
Obsérvese que cada acontecimiento se etiqueta como F,T,C. Con ello se muestra si es de tipo de flujo, temporal, o de control. El orientado a flujos es el que se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún dato (o posiblemente varios). Los acontecimientos temporales arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos de acontecimientos temporales pudieran ser:
A las 9:00 de la mañana se requiere un reporte diario de todos los pedidos de libros.
Las facturas deben generarse a las 3:00 PM.
Se deben generar reportes administrativos una vez por hora.
Los acontecimientos de control deben considerarse un caso especial del acontecimiento temporal: un estímulo externo que ocurre en algún momento impredecible. A diferencia de un acontecimiento temporal normal, el acontecimiento de control no se asocia con el paso regular del tiempo, por lo que el sistema no puede anticiparlo utilizando un reloj interno.
3.2.2 Construcción del modelo ambiental
Construcción del diagrama de contexto
El diagrama de contexto consiste en terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el sistema. Se analizan uno por uno a continuación.
La parte más fácil del diagrama de contexto es el proceso; como hemos visto, consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido. En la figuras 3.2.2 se muestra un ejemplo.
Figura 3.2.2: Nombre tipico de proceso para un diagrama de contexto
Los terminadores se representan con rectángulos en el diagrama de contexto. Se comunican directamente con el sistema a través de flujos de datos o de control, como muestra la figura 3.2.3(a),
Figura 3.2.3(a):Comunicación directa entre terminado y sistema
o a través de almacenes externos, como se muestra en la figura 3.2.3(b).
Figura 3.2.3(b):Comunicación a traves de un almacen externo
Los terminadores no se comunican entre sí. En realidad, los terminadores si se comunican entre sí pero, dado que por definición son externos al sistema, la naturaleza y contenido de las interacciones terminador-terminador son irrelevantes para el sistema.
Hay que tomar tres punto mas en consideración de los terminadores:
- Algunos terminadores tienen un buen número de entradas y salidas. Para evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador más de una vez. Los terminadores duplicados se marcan con un asterisco.
- Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más que su identidad.
- Dado que estamos interesados en desarrollar un modelo esencial del sistema, es importante distinguir entre fuente y manejadores. Un manejador es un mecanismo, dispositivo, medio físico usado para transportar datos hacia o fuera del sistema. Dado que a menudo, dichos manejadores son familiares y visibles para los usuarios de la implantación actual de un sistema, existe la tendencia a mostrar al manejador, en lugar de la verdadera fuente de los datos.
Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, además de las señales de control que recibe o genera. Los flujos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (como datos) para producir una respuesta.
Construcción de la lista de acontecimiento
La lista de acontecimiento es un listado textual sencillo de los acontecimientos del ambiente a los cuales debe responder el sistema. Al crear la lista de acontecimiento se debe asegurar de distinguir entre un acontecimiento y un flujo relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no sea un acontecimiento:
"El sistema recibe el pedido del cliente"
Mas bien, sea el flujo de datos de entrada mediante el cual el sistema se da cuenta de que ha ocurrido el acontecimiento. Un nombre más apropiado para el acontecimiento sería:
"El cliente hace un pedido"
La manera más fácil de identificar los acontecimientos para un sistema es visualizarlo en acción: examinar cada terminador y preguntar qué efecto pueden tener sus acciones sobre el sistema.
La lista de acontecimiento debe incluir no sólo las interacciones normales ente el sistema y sus terminadores sino también situaciones de falla.
Puesto que los terminadores están por definición fuera de las fronteras del intento de construcción de sistema representado por el modelo, los realizadores no pueden modificar la tecnología de los terminadores para mejorar su confiabilidad. En lugar de ello, deben construir respuestas para los problemas de los terminadores en el modelo esencial del sistema. Un enfoque útil para modelar respuestas a los problemas de terminadores es construir una lista de acontecimientos "normales" y luego preguntar, para cada acontecimiento, "¿Necesita el sistema responder si este acontecimiento deja de ocurrir como se espera?.
Por ejemplo, nuestra lista de acontecimiento para el Sistema de Pedido de Libros Ajax incluía un acontecimiento llamado "el pedido de reimpresión de libro llega a la bodega". Pero ¿Qué tal si no llega a tiempo (por ejemplo, una semana después de la fecha prometida por el impresor)? ¿Qué debería hacer el sistema?, Por lo que se necesitaría un acontecimiento adicional iniciado por el sistema para hacer que se comunique con el impresor y localice el origen del retraso.
No hay comentarios:
Publicar un comentario