E-Clases
Ingenieria de Software IX
Home
SIA: Definiciones
SIA: Centros de Cómputo
SIA: Areas de Administracion de un CC
SIA: Técnicas y sistemas de gestión de la innovación
Matematicas
SIA II - Proyecto
Códigos para Programadores
Bases de Datos I
Diseño Páginas Web
Curso de Ingles Diciembre 2003
Ingles Tecnico
CENAFOM - Computación 02076
Ingenieria de Software I
Ingenieria de Software II
Ingenieria de Software III
Ingenieria de Software IV
Ingenieria de Software V
Ingenieria de Software VI
Ingenieria de Software VII
Ingenieria de Software VIII
Ingenieria de Software IX
Ingenieria de Software X
Ingenieria de Software XI
Encuestas y Libro de Visitas
Sitios Web
De todo Un Poco
Servicio Tecnico
Nuestros Clientes
Trabajos
Introducción a la Programación

clases2.jpg

Análisis:

Análisis del sistema

Objetivos

  • Identificar las necesidades.
    • Objetivos del producto.
    • Recursos necesarios.
    • Límites de presupuesto y tiempo.
    • Mercado potencial del producto.
  • Evaluar la factibilidad del sistema.
    • Factibilidad económica.
    • Factibilidad técnica.
    • Factibilidad legal.
    • Alternativas.
  • Realizar análisis económico de costo/beneficio y técnico.
  • Asignar funciones a los elementos del sistema (hardware, software, personas, etc).
  • Establecer calendarios y restricciones.
  • Crear la especificación del sistema. Es un documento que describe:
    • La función, rendimiento y restricciones del sistema.
    • La información (datos y control) que entran y salen del sistema.
    Como ayuda se usa un diagrama de contexto de la arquitectura del sistema:

    Interface de usuario
    Entradas Procesamiento y
    control
    Salidas
    Mantenimiento y comprobación

Análisis de requisitos

  • Es el primer paso en la construcción de un sistema.
  • Define el qué no el cómo.
  • Qué necesidades tiene el usuario.
  • Cuál es el sistema actual.
  • Qué restricciones existen.
Requisito. Característica del sistema usada para cumplir el propósito del sistema. Los requisitos pueden ser:
  • Funcionales. Describen el comportamiento.
  • No funcionales. Restricciones del sistema como dinero, tiempo, etc.

El análisis de requisitos tiene cinco pasos:

  1. Reconocimiento del problema.
    • Estudiar la especificación del sistema y el plan temporal.
    • Establecer comunicación (reuniones) con el cliente.
  2. Evaluación y síntesis.
    • Definir objetos.
    • Evaluar el flujo de la información.
    • Definir las funciones del sistema.
    • Definir la interface hombre-máquina.
    • Descubrir restricciones adicionales de diseño.
    • Enfocarse en el qué y no el cómo.
  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. Especificación. Principios de la especificación:
    • Separar la funcionalidad de la implementación.
    • Modelar el comportamiento. Como responde a los eventos del medio ambiente.
    • Establecer el contexto. Como interactúa con otros sistemas.
    • Permitir cambios y agregados.
  5. Revisión.
    • 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 están completas.
        • Internamente. No hay referencias sin definir.
      • Realistas.
      • Suficientes (cada requerimiento describe algo que el cliente necesita).
      • Verificables (se puedan probar).
      • Seguibles (monitoreables).

Técnicas para facilitar las especificaciones de una aplicación (F.A.S.T.)

  • Reuniones en lugares neutrales.
  • Se establecen reglas para participación y preparación.
  • Se sugiere una agenda formal pero flexible y con lluvia de ideas.
  • Se designa un coordinador (cliente, desarrollador o neutral).
  • Mecanismos de definición (hojas, rotafolios, pizarrones, etc.).
  • Objetivos:
    • Identificar el problema.
    • Proponer soluciones.
    • Negociar enfoques.
    • Establecer un conjunto de requisitos preliminares.

Principios del análisis

  • Representar y entender el dominio de la información del problema.
    • Contenido de la información. Objetos y eventos del sistema.
    • Flujo de la información. Como cambian los objetos y eventos con el tiempo.
    • Estructura de la información. Organización 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 análisis va de la información esencial al detalle.

Análisis estructurado

Objetivos

  • Describir los requerimientos del cliente.
  • Establecer una base para la creación de un diseño 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-Relación (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 indicación de cómo se transforman los datos en el tiempo.
    • Representar las funciones que transforman el flujo de datos.
  • Diagrama de Transición de Estados (DTE). Representa el comportamiento del sistema con respecto a eventos externos, mediante el uso de estados y transiciones entre estados.

Diagrama Entidad-Relación (DER)

Es un modelo que describe con un alto nivel de abstracción la distribución de los datos almacenados en un sistema.

Componentes

Entidades. Son objetos físicos o lógicos sobre los que se quiere guardar información. Equivale casi a lo que en programación orientada a objetos se conoce como clase, y por eso generalmente se escriben en singular. Ej. carro, persona, póliza, cheque, producto, etc. Se dibujan como rectángulos.

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 líneas con un círculo en la punta, o compuestos cuando por razones de comodidad se agrupan varios atributos simples. Por ejemplo, el atributo dirección puede definirse como compuesto de calle, número, colonia, ciudad, estado y código postal, y en este caso se dibuja el atributo compuesto como un óvalo con los atributos simples saliendo de él.

Jerarquías de entidades. A veces es necesario representar una entidad como si estuviera compuesta de una o más sub-entidades. Cada sub-entidad tiene (hereda) los atributos de la entidad padre o super-entidad y tiene uno o más atributos específicos de la sub-entidad. Este tipo de jerarquías genera lo que se llama una partición. Las particiones se pueden clasificar en:

  • totales. Si todos los elementos de la super-clase están en al menos una sub-clase. Por ejemplo, la partición 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 algún elemento de la super-clase que no pertenezca a ninguna sub-clase. Por ejemplo, la partición generada por la super-clase persona y las sub-clases hombre y empleado, o la generada por la super-clase vehículo y las sub-clases carro y bicicleta.
y también en:
  • exclusivas. Si cada elemento de la super-clase está a lo más en una sub-clase. Por ejemplo, la partición generada por la super-clase persona y las sub-clases hombre y mujer, además de ser total, es exclusiva. Y la generada por la super-clase vehículo y las sub-clases carro y bicicleta, además de ser parcial también es exclusiva.
  • superpuestas (overlayed). Si es posible que un elemento de la super-clase esté en dos o más sub-clases. Por ejemplo, la partición generada por la super-clase persona y las sub-clases hombre y empleado, además de ser parcial, es superpuesta. Y la generada por la super-clase deportista y las sub-clases gimnasta y esgrimista, además 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 relación 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 relación es-padre-de relaciona la entidad persona consigo misma.
  • binarias. Si relacionan dos entidades. Son las mas comunes. Por ejemplo, la relación es-dueño-de relaciona la entidad persona con la entidad carro.
  • n-arias. Si relacionan tres o más entidades. Por ejemplo, la relación se_imparte que relaciona las tres entidades de materia, día y salón.

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 máximo un elemento de la otra entidad y viceversa. Por ejemplo, la relación 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 más elementos de la otra entidad, pero cada elemento de la segunda entidad solo puede estar relacionado con máximo un elemento de la primera. Por ejemplo, la relación es-dueño-de que relaciona las entidades de persona y carro y que significa que una persona puede ser dueña de varios carros, pero un carro sólo puede tener un dueño.
  • muchos a muchos (n:n). Si un elemento de una entidad puede estar relacionado con uno o más elementos de la otra entidad, y cada elemento de la segunda entidad también puede estar relacionado con uno o más elementos de la primera. Por ejemplo, la relación 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 relación nació-en que relaciona las entidades persona y ciudad, la participación 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 relación es-dueño-de que relaciona las entidades persona y edificio, la participación de la entidad edificio es opcional, porque es posible que una persona no sea dueña de ningún edificio. Se representa poniendo una bolita del lado de la entidad opcional.

Metodología para crear un DER

  1. Listar los objetos (entidades).
  2. Definir relaciones entre objetos.
  3. Crear parejas de entidad-relación.
  4. Para cada pareja entidad-relación, determinar su cardinalidad y modo.
  5. Repetir los pasos del 2 al 4, hasta tener todas las relaciones.
  6. Definir los atributos de cada entidad.
  7. Revisar el DER.
  8. 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 información o que simplemente tranforma datos de entrada en datos de salida. Se representa por un círculo o burbuja.

Flujo de datos. Es un intercambio de información 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 información. Pueden manejarse flujos de entrada, de salida, diálogos y flujos divergentes.

Almacén de datos. En general es un depósito de información. Puede ser un archivo temporal, un formulario electrónico o de papel, memoria intermedia (buffer), una estructura de datos (cola, pila, lista, etc.), una base de datos, etc. Se representa por dos líneas horizontales paralelas o por un rectángulo 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.

Metodología para crear un DFD

  1. Partir de un DFD de nivel 0.
  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 información ni que sean de generación espontánea y que todas las flechas tengan por lo menos un sentido.
  6. Entre niveles sucesivos debe mantenerse la continuidad del flujo de información.
  7. Refinar las burbujas una por una.
  8. Para diagramas complejos pueden organizarse las burbujas en niveles de modo que cada nivel proporcione más detalles que el nivel anterior.

El DFD puede acompañarse de una especificación del proceso, también llamada minispec por mini especificación, para detallar el DFD y describir:

  • La entrada, salida y algoritmo aplicado a cada burbuja.
  • Restricciones y limitaciones del proceso.
  • Características relevantes de rendimiento.
  • Restricciones de diseño.
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-código.
    • 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-raíz-cuadrada:

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

  • Pre/post condiciones. Describen la función 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 están disponibles.
    • Las relación 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 almacén 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 existirán entre los valores de salida y los valores originales de entrada.
    • Las relaciones que existirán 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-raíz-cuadrada:

    PRE-CONDICION
      Existe un número X no negativo
    POST-CONDICION
      Se produce un número W tal que:
        X = W * W

  • Tablas de decisión. Se usan cuando el proceso debe producir una salida o tomar una acción 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 condición.

    Ejemplo:

    Condición Acción
    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  
    Si M No   X    
    Si M Si X      

    También puede usarse con condiciones que no son binarias con el peligro de que las tablas crezcan demasiado. Aquí puedes ver un ejemplo.

Diagrama de Transición de Estados (DTE)

Modela el comportamiento dependiente del tiempo de un sistema.

Componentes

Estado. Modo observable de comportamiento.

Condición. Evento externo que el sistema es capaz de detectar y que provoca que cambie de un estado a otro.

Acción. Actividad que realiza el sistema al pasar de un estado a otro, puede ser una salida, un cálculo, 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á sólo 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 análisis estructurado.

Por lo general contiene la siguiente información:

  • Nombre. El nombre del elemento.
  • Alias. Nombres alternos que tenga el elemento.
  • Dónde se usa/cómo se usa. Listado de los procesos que usan el elemento y cómo lo usan, si como entrada o salida del proceso, como almacén, como entidad externa, etc.
  • Descripción del contenido. Describe los valores legales que puede tomar el elemento.
  • Información adicional. Alguna otra información, valores implícitos, restricciones, etc.

Notación para describir el contenido

Símbolo   Significado
=   compuesto por
+   y
-   rango
()   optativo
{}   iteración
[]   seleccionar una alternativa
**   comentario
@   campo llave de un almacén
|   separa alternativas

Ejemplo de descripción 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 límites inferiores y/o superiores a las iteraciones. Si por ejemplo, se quiere indicar que el nombre de pila deben tener una extensión entre 1 y 10 caracteres, entonces la definición puede quedar asi:

nombre de pila = 1{letra}10

Ejemplo de definición de valores legales:

peso = *peso de la persona, unidades: kilogramos, rango: 1-200*
sexo = *valores: [M | F]*

Ejemplo de definición de una entidad

Por lo general los objetos del DER corresponden con almacenes del DFD (lee abajo la sección de balanceo de modelos). Esto significa que en el diccionario de datos, el nombre de la entidad alumno es una definición de un objeto y una instancia de un almacén llamado alumnos:

alumnos = {alumno}
alumno = @matrícula + nombre + carrera + domicilio

La arroba indica que el campo matrícula es el campo llave, es decir, el campo que nos permite distinguir un alumno de otro.

Ejemplo de definición de una relación:

La definición de una relación debe incluir su significado, los elementos que forman parte de la relación (los campos llave de las entidades relacionadas y los atributos propios de la relación) y su cardinalidad.

es-dueño-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 análisis 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 almacén del DFD deben estar en el DD. Dato no definido.
  • Cada dato y cada almacén del DD debe aparecer en algún lado del DFD. Dato fantasma.

Balanceo entre el DFD y la especificación de proceso (minispec)

  • Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificación de procesos, pero no ambos. Dato redundante.
  • Cada especificación de proceso debe tener una burbuja de nivel inferior asociada en el DFD. Especificación vagabunda.
  • Las entradas y las salidas deben coincidir.

Balanceo entre la especificación 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 almacén conectado a la burbuja descrita en la minispec.
  • Es un término local definido explícitamente en la minispec.
  • Aparece como componente en una entrada del DD para un flujo o almacén conectado a la burbuja.

Balanceo entre el DD con el DFD y la especificación de proceso (minispec)

  • Cada entrada del DD debe tener referencia en una especificación de proceso, un DFD, u otro DD.

Balanceo entre el DER con el DFD y la especificación de proceso (minispec)

  • Cada almacén del DFD debe corresponder con una entidad, una relación o una combinación 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 algún 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 algún proceso del DFD usa o lee valores de cada dato.

El proceso del análisis

El análisis 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 menos posible de cómo el sistema será implementado. Consta de dos modelos:

  • Modelo Ambiental. Define los límites entre el sistema y el resto del mundo. Tiene 3 actividades:
    • Declaración de propósito.
      • Dice que hace y que no hace el sistema.
      • No debe ser más grande que un párrafo.
    • Diagrama de contexto.
      • Muestra los objetos externos con los que interactúa 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 aplicación.
    • 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.
    • Especificación del proceso (minispec).
    • Diccionario de datos.
    • Diagrama entidad-relación.
    • Diagrama de transición de estados.

WorldPrime Computacion (C) 2004