Ingenieria de Software IX

Anlisis del sistema

Objetivos Identificar las necesidades. Objetivos del producto. Recursos necesarios. Lmites de presupuesto y tiempo. Mercado potencial del producto. Evaluar la factibilidad del sistema. Factibilidad econmica. Factibilidad tcnica. Factibilidad legal. Alternativas. Realizar anlisis econmico de costo/beneficio y tcnico. Asignar funciones a los elementos del sistema (hardware, software, personas, etc). Establecer calendarios y restricciones. Crear la especificacin del sistema. Es un documento que describe: La funcin, rendimiento y restricciones del sistema. La informacin (datos y control) que entran y salen del sistema. Como ayuda se usa un diagrama de contexto de la arquitectura del sistema:

http://eclases.tripod.com/id19.html

Interface de usuario Procesamiento y control Entradas Salidas Mantenimiento y comprobacin

Anlisis de requisitos
Es el primer paso en la construccin de un sistema. Define el qu no el cmo. Qu necesidades tiene el usuario. Cul es el sistema actual. Qu restricciones existen. Requisito. Caracterstica del sistema usada para cumplir el propsito del sistema. Los requisitos pueden ser: Funcionales. Describen el comportamiento. No funcionales. Restricciones del sistema como dinero, tiempo, etc. El anlisis de requisitos tiene cinco pasos: 1. Reconocimiento del problema. Estudiar la especificacin del sistema y el plan temporal. Establecer comunicacin (reuniones) con el cliente. 2. Evaluacin y sntesis. Definir objetos. Evaluar el flujo de la informacin. Definir las funciones del sistema. Definir la interface hombre-mquina. Descubrir restricciones adicionales de diseo. Enfocarse en el qu y no el cmo. 3. Modelado. Modelos funcionales. Representan las entradas, salidas y procesamiento. Modelos de comportamiento. Representan los estados del sistema y los eventos que hacen que cambien de estado. 4. Especificacin. Principios de la especificacin: Separar la funcionalidad de la implementacin. Modelar el comportamiento. Como responde a los eventos del medio ambiente. Establecer el contexto. Como interacta con otros sistemas. Permitir cambios y agregados. 5. Revisin. Revisar las metas y objetivos. Comparar requerimientos con las metas y objetivos. Checar si se han considerado todos los riesgos, todas las restricciones, etc. Checar que los requerimientos son: Correctos. Consistentes (sin contradicciones). Completos. Externamente. Todas las propiedades deseadas estn completas. Internamente. No hay referencias sin definir. Realistas. Suficientes (cada requerimiento describe algo que el cliente necesita). Verificables (se puedan probar). Seguibles (monitoreables).

1 de 7

14/12/2011 22:09

Ingenieria de Software IX

http://eclases.tripod.com/id19.html

Tcnicas para facilitar las especificaciones de una aplicacin (F.A.S.T.) Reuniones en lugares neutrales. Se establecen reglas para participacin y preparacin. Se sugiere una agenda formal pero flexible y con lluvia de ideas. Se designa un coordinador (cliente, desarrollador o neutral). Mecanismos de definicin (hojas, rotafolios, pizarrones, etc.). Objetivos: Identificar el problema. Proponer soluciones. Negociar enfoques. Establecer un conjunto de requisitos preliminares. Principios del anlisis Representar y entender el dominio de la informacin del problema. Contenido de la informacin. Objetos y eventos del sistema. Flujo de la informacin. Como cambian los objetos y eventos con el tiempo. Estructura de la informacin. Organizacin interna de los datos. Definir modelos para representar las funciones y el comportamiento del software. Partir el problema y los modelos para descubrir detalles. El anlisis va de la informacin esencial al detalle.

Anlisis estructurado
Objetivos Describir los requerimientos del cliente. Establecer una base para la creacin de un diseo de software. Definir un conjunto de requisitos que se puedan validar una vez que se ha construido el software. Elementos Diccionario de Datos (DD). Definiciones de los objetos de datos. Diagrama Entidad-Relacin (DER). Representa las relaciones entre los objetos de datos sin tener en cuenta el proceso que los transforma. Diagrama de Flujo de Datos (DFD). Proporciona una indicacin de cmo se transforman los datos en el tiempo. Representar las funciones que transforman el flujo de datos. Diagrama de Transicin de Estados (DTE). Representa el comportamiento del sistema con respecto a eventos externos, mediante el uso de estados y transiciones entre estados. Diagrama Entidad-Relacin (DER) Es un modelo que describe con un alto nivel de abstraccin la distribucin de los datos almacenados en un sistema. Componentes Entidades. Son objetos fsicos o lgicos sobre los que se quiere guardar informacin. Equivale casi a lo que en programacin orientada a objetos se conoce como clase, y por eso generalmente se escriben en singular. Ej. carro, persona, pliza, cheque, producto, etc. Se dibujan como rectngulos. Atributos. Son propiedades relevantes de las entidades o de las relaciones. Pueden ser simples, por ejemplo, el RFC, nombre-de-pila, edad, y en ese caso se dibujan como lneas con un crculo en la punta, o compuestos cuando por razones de comodidad se agrupan varios atributos simples. Por ejemplo, el atributo direccin puede definirse como compuesto de calle, nmero, colonia, ciudad, estado y cdigo postal, y en este caso se dibuja el atributo compuesto como un valo con los atributos simples saliendo de l. Jerarquas de entidades. A veces es necesario representar una entidad como si estuviera compuesta de una o ms sub-entidades. Cada sub-entidad tiene (hereda) los atributos de la entidad padre o super-entidad y tiene uno o ms atributos especficos de la sub-entidad. Este tipo de jerarquas genera lo que se llama una particin. Las particiones se pueden clasificar en: totales. Si todos los elementos de la super-clase estn en al menos una sub-clase. Por ejemplo, la particin generada por la super-clase persona y las sub-clases hombre y mujer o la generada por la super-clase deportista y las sub-clases gimnasta y esgrimista, en un club de gimnasia y esgrima que exige que sus socios practiquen por lo menos uno de esos deportes. parciales. Si hay algn elemento de la super-clase que no pertenezca a ninguna sub-clase. Por ejemplo, la particin generada por la super-clase persona y las sub-clases hombre y empleado, o la generada por la super-clase vehculo y las sub-clases carro y bicicleta. y tambin en: exclusivas. Si cada elemento de la super-clase est a lo ms en una sub-clase. Por ejemplo, la particin generada por la super-clase persona y las sub-clases hombre y mujer, adems de ser total, es exclusiva. Y la generada por la super-clase vehculo y las sub-clases carro y bicicleta, adems de ser parcial tambin es exclusiva. superpuestas (overlayed). Si es posible que un elemento de la super-clase est en dos o ms

2 de 7

14/12/2011 22:09

Ingenieria de Software IX

http://eclases.tripod.com/id19.html
superpuestas (overlayed). Si es posible que un elemento de la super-clase est en dos o ms sub-clases. Por ejemplo, la particin generada por la super-clase persona y las sub-clases hombre y empleado, adems de ser parcial, es superpuesta. Y la generada por la super-clase deportista y las sub-clases gimnasta y esgrimista, adems de ser total, es superpuesta. Relaciones. Expresan conexiones entre entidades y por lo general son verbos. Por ejemplo, entre las entidades biblioteca y libro puede surgir la relacin tiene, indicando que las bibliotecas tienen libros. Se dibujan como rombos que conectan las entidades. Las relaciones pueden ser: unarias. Si relacionan una entidad consigo mismo. Por ejemplo, la relacin es-padre-de relaciona la entidad persona consigo misma. binarias. Si relacionan dos entidades. Son las mas comunes. Por ejemplo, la relacin es-dueo-de relaciona la entidad persona con la entidad carro. n-arias. Si relacionan tres o ms entidades. Por ejemplo, la relacin se_imparte que relaciona las tres entidades de materia, da y saln. Tambien se pueden catalogar las relaciones por su cardinalidad en: uno a uno (1:1). Si un elemento de una entidad puede estar relacionado con mximo un elemento de la otra entidad y viceversa. Por ejemplo, la relacin est-casado-con que relaciona las entidades de hombre y mujer. uno a muchos (1:n). Si un elemento de una entidad puede estar relacionado con uno o ms elementos de la otra entidad, pero cada elemento de la segunda entidad solo puede estar relacionado con mximo un elemento de la primera. Por ejemplo, la relacin es-dueo-de que relaciona las entidades de persona y carro y que significa que una persona puede ser duea de varios carros, pero un carro slo puede tener un dueo. muchos a muchos (n:n). Si un elemento de una entidad puede estar relacionado con uno o ms elementos de la otra entidad, y cada elemento de la segunda entidad tambin puede estar relacionado con uno o ms elementos de la primera. Por ejemplo, la relacin habita que relaciona las entidades de persona y edificio y que significa que una persona puede habitar en varios edificios, y que un edificio puede ser habitado por varias personas. O por su modo en: obligatorias. Si un elemento de una entidad tiene que estar relacionado con al menos un elemento de la otra entidad. Por ejemplo, en la relacin naci-en que relaciona las entidades persona y ciudad, la participacin de la entidad persona es obligatoria, porque una persona tuvo que nacer en alguna ciudad. Se identifica poniendo una rayita del lado de la entidad obligatoria. opcionales. Si un elemento de una entidad puede estar relacionado con cero elementos de la otra entidad. Por ejemplo, en la relacin es-dueo-de que relaciona las entidades persona y edificio, la participacin de la entidad edificio es opcional, porque es posible que una persona no sea duea de ningn edificio. Se representa poniendo una bolita del lado de la entidad opcional. Metodologa para crear un DER 1. 2. 3. 4. 5. 6. 7. 8. Listar los objetos (entidades). Definir relaciones entre objetos. Crear parejas de entidad-relacin. Para cada pareja entidad-relacin, determinar su cardinalidad y modo. Repetir los pasos del 2 al 4, hasta tener todas las relaciones. Definir los atributos de cada entidad. Revisar el DER. Si es necesario, repetir los pasos del 1 al 7.

Diagrama de Flujo de Datos (DFD) Modela las funciones que lleva a cabo un sistema. Componentes Proceso.Es una actividad que genera, usa, manipula o destruye informacin o que simplemente tranforma datos de entrada en datos de salida. Se representa por un crculo o burbuja. Flujo de datos. Es un intercambio de informacin entre procesos, no es un flujo de control, indica paquetes de discretos de datos que fluyen hacia adentro o hacia fuera del proceso. Se representa por una flecha indicando el sentido en el que fluye la informacin. Pueden manejarse flujos de entrada, de salida, dilogos y flujos divergentes. Almacn de datos. En general es un depsito de informacin. Puede ser un archivo temporal, un formulario electrnico o de papel, memoria intermedia (buffer), una estructura de datos (cola, pila, lista, etc.), una base de datos, etc. Se representa por dos lneas horizontales paralelas o por un rectngulo al que le falta el lado derecho. Terminador o Interface. Es un usuario externo al sistema que puede ser el originador o el receptor de los flujos o de los almacenes de datos. Se representa por un cuadrado. Metodologa para crear un DFD 1. Partir de un DFD de nivel 0.

3 de 7

14/12/2011 22:09

Ingenieria de Software IX

http://eclases.tripod.com/id19.html

2. Anotar las entradas y salidas principales. 3. Aislar los procesos, objetos de datos y almacenes de datos que sean candidatos a ser refinados para el siguiente nivel. 4. Las flechas y las burbujas deben rotularse con nombres significativos. 5. Cuidar que no haya burbujas que sean sumideros de informacin ni que sean de generacin espontnea y que todas las flechas tengan por lo menos un sentido. 6. Entre niveles sucesivos debe mantenerse la continuidad del flujo de informacin. 7. Refinar las burbujas una por una. 8. Para diagramas complejos pueden organizarse las burbujas en niveles de modo que cada nivel proporcione ms detalles que el nivel anterior. El DFD puede acompaarse de una especificacin del proceso, tambin llamada minispec por mini especificacin, para detallar el DFD y describir: La entrada, salida y algoritmo aplicado a cada burbuja. Restricciones y limitaciones del proceso. Caractersticas relevantes de rendimiento. Restricciones de diseo. La minispec debe expresarse de una manera que puedan verificar tanto el usuario como el analista. Hay varias herramientas para hacer una minispec, destacan, entre otras: Seudo-cdigo. Utiliza un lenguaje estructurado informal para describir el algoritmo. Hay que tener cuidado con la complejidad para que se mantenga legible por el cliente. Ejemplo para un proceso llamado calculo-de-raz-cuadrada:

W 0 = 17 REPITE desde n = 0, de uno en uno W n + 1 = (W n - (X / W n)) / 2 HASTA que |W n + 1 - W n| < 0.0001

Pre/post condiciones. Describen la funcin del proceso sin decir nada del algoritmo. Las pre-condiciones describen las cosas que deben darse antes de que el proceso pueda ejecutarse, por ejemplo: Las entradas que estn disponibles. Las relacin que debe existir entre las entradas. Las relaciones que deben existir entre las entradas y los almacenes de datos. Las relaciones que deben existir entre los diferentes almacenes de datos o dentro de un almacn dado. Las post-condiciones describen lo que debe darse de cuando el proceso ha concluido, por ejemplo: Las salidas que generar y producir el proceso. Las relaciones que existirn entre los valores de salida y los valores originales de entrada. Las relaciones que existirn entre los valores de salida y los valores en uno o varios almacenes. Los cambios que se hayan dado en los almacenes. Ejemplo para un proceso llamado calculo-de-raz-cuadrada:

PRE-CONDICION Existe un nmero X no negativo POST-CONDICION Se produce un nmero W tal que: X=W*W
Tablas de decisin. Se usan cuando el proceso debe producir una salida o tomar una accin basada en decisiones complejas. Para crearlas hay que. Listar las condiciones y las acciones relevantes en las columnas de la tabla. Generar todas los posibles valores para las condiciones. Marcar las acciones que corresponden a cada condicin. Ejemplo:

Condicin

Accin

Edad > 18 Sexo Peso > 100 Medicina 1 Medicina 2 Medicina 3 Ninguna No F No X X No F Si X No M No X No M Si X X Si F No X Si F Si X

4 de 7

14/12/2011 22:09

Ingenieria de Software IX
Si Si Si F M M Si No Si X X X

http://eclases.tripod.com/id19.html

Tambin puede usarse con condiciones que no son binarias con el peligro de que las tablas crezcan demasiado. Aqu puedes ver un ejemplo. Diagrama de Transicin de Estados (DTE) Modela el comportamiento dependiente del tiempo de un sistema. Componentes Estado. Modo observable de comportamiento. Condicin. Evento externo que el sistema es capaz de detectar y que provoca que cambie de un estado a otro. Accin. Actividad que realiza el sistema al pasar de un estado a otro, puede ser una salida, un clculo, etc. Metodologia para crear un DTE 1. Establecer los estados del sistema y representarlos con cuadrados. 2. Establecer las conexiones (cambios) entre estados y dibujarlas con flechas entre los estados. Las condiciones y acciones se ponen a un lado de las flechas. 3. Repetir 1 y 2 cuantas veces sea necesario. Reglas Normalmente habr slo un estado inicial. Puede haber varios estados finales excluyentes entre s. Todos los estados (excepto el estado inicial) tienen flechas entrantes. Todos los estados (excepto los estados finales) tienen flechas salientes. Todas las transiciones tienen condiciones. No todas las transiciones tienen acciones. Diccionario de datos (DD) Describe el significado y contenido de los objetos definidos durante el anlisis estructurado. Por lo general contiene la siguiente informacin: Nombre. El nombre del elemento. Alias. Nombres alternos que tenga el elemento. Dnde se usa/cmo se usa. Listado de los procesos que usan el elemento y cmo lo usan, si como entrada o salida del proceso, como almacn, como entidad externa, etc. Descripcin del contenido. Describe los valores legales que puede tomar el elemento. Informacin adicional. Alguna otra informacin, valores implcitos, restricciones, etc. Notacin para describir el contenido

Smbolo Significado compuesto por + y rango () optativo {} iteracin [] seleccionar una alternativa ** comentario @ campo llave de un almacn | separa alternativas
Ejemplo de descripcin del nombre de una persona: nombre = titulo + nombre de pila + (segundo nombre de pila) + apellido paterno + apellido materno titulo = [Sr. | Srita. | Sra. | Dr. | Ing. | Lic. | Prof.] nombre de pila = {letra} segundo nombre de pila = {letra} apellido paterno = {letra} apellido materno = {letra} letra = {a-z | A-Z} Si es necesario se pueden poner lmites inferiores y/o superiores a las iteraciones. Si por ejemplo, se quiere indicar que el nombre de pila deben tener una extensin entre 1 y 10 caracteres, entonces la definicin puede quedar asi: nombre de pila = 1{letra}10

5 de 7

14/12/2011 22:09

Ingenieria de Software IX
nombre de pila = 1{letra}10 Ejemplo de definicin de valores legales: peso = *peso de la persona, unidades: kilogramos, rango: 1-200* sexo = *valores: [M | F]* Ejemplo de definicin de una entidad

http://eclases.tripod.com/id19.html

Por lo general los objetos del DER corresponden con almacenes del DFD (lee abajo la seccin de balanceo de modelos). Esto significa que en el diccionario de datos, el nombre de la entidad alumno es una definicin de un objeto y una instancia de un almacn llamado alumnos: alumnos = {alumno} alumno = @matrcula + nombre + carrera + domicilio La arroba indica que el campo matrcula es el campo llave, es decir, el campo que nos permite distinguir un alumno de otro. Ejemplo de definicin de una relacin: La definicin de una relacin debe incluir su significado, los elementos que forman parte de la relacin (los campos llave de las entidades relacionadas y los atributos propios de la relacin) y su cardinalidad.

es-dueo-de = *relacion entre la persona y el (los) carro(s) que tiene* @RFC + 1{marca + modelo + fecha-compra + @placa}
Balanceo de modelos Objetivo: Buscar que el anlisis sea: Completo. Que no haya elementos sin definir. Consistente. Que no haya contradicciones entre las definiciones. Balanceo entre el DFD y el DD Cada flujo y cada almacn del DFD deben estar en el DD. Dato no definido. Cada dato y cada almacn del DD debe aparecer en algn lado del DFD. Dato fantasma. Balanceo entre el DFD y la especificacin de proceso (minispec) Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificacin de procesos, pero no ambos. Dato redundante. Cada especificacin de proceso debe tener una burbuja de nivel inferior asociada en el DFD. Especificacin vagabunda. Las entradas y las salidas deben coincidir. Balanceo entre la especificacin de proceso (minispec) con el DFD y el DD Cada referencia de un dato en la minispec debe satisfacer alguna de las siguientes reglas: Es el nombre de un flujo de datos o almacn conectado a la burbuja descrita en la minispec. Es un trmino local definido explcitamente en la minispec. Aparece como componente en una entrada del DD para un flujo o almacn conectado a la burbuja. Balanceo entre el DD con el DFD y la especificacin de proceso (minispec) Cada entrada del DD debe tener referencia en una especificacin de proceso, un DFD, u otro DD. Balanceo entre el DER con el DFD y la especificacin de proceso (minispec) Cada almacn del DFD debe corresponder con una entidad, una relacin o una combinacin de ambos. Los nombres de los objetos del DER y los nombres de los almacenes del DFD deben coincidir. Las entradas del DD deben aplicarse al modelo del DFD y al del DER. En algn lado de la minispec debe venir el proceso de crear y eliminar los objetos definidos en el DER. Alguna burbuja del DFD define valores para cada dato asignado a cada instancia de cada tipo de objeto, y algn proceso del DFD usa o lee valores de cada dato.

El proceso del anlisis

El anlisis del sistema debe incluir el desarrollo de dos modelos, el modelo Ambiental y el modelo de Comportamiento, que juntos hacen el modelo Esencial. Modelo Esencial Describe lo que debe hacer el sistema para satisfacer los requerimientos del usuario diciendo lo

6 de 7

14/12/2011 22:09

Ingenieria de Software IX

http://eclases.tripod.com/id19.html
Describe lo que debe hacer el sistema para satisfacer los requerimientos del usuario diciendo lo menos posible de cmo el sistema ser implementado. Consta de dos modelos: Modelo Ambiental. Define los lmites entre el sistema y el resto del mundo. Tiene 3 actividades: Declaracin de propsito. Dice que hace y que no hace el sistema. No debe ser ms grande que un prrafo. Diagrama de contexto. Muestra los objetos externos con los que interacta el sistema y su interface con el sistema. Consta de un diagrama de flujo de alto nivel que muestra al sistema como una caja negra con interfaces a las fuentes externas y con interfaces a los usuarios de los datos de la aplicacin. Lista de eventos. Lista todos los eventos externos al sistema. Lista todos los eventos a los cuales el sistema debe responder. Modelo de Comportamiento. Describe el comportamiento requerido del sistema necesario para interactuar con xito con el medio ambiente. Tiene 5 actividades: Diagrama de flujo de datos. Especificacin del proceso (minispec). Diccionario de datos. Diagrama entidad-relacin. Diagrama de transicin de estados.

7 de 7

14/12/2011 22:09