Sistemas de Informacion II

 

Modelo Esencial

 

Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo minimo posible acerca de cómo se implantara. Supone tecnología perfecta y sin costo.

Se debe evitar describir implantaciones especificas de procesos en el sistema. No debe mostrar las funciones del sistema que están siendo realizadas por humanos o por sistemas de computo existentes. Debe describir el contenido de los flujos o almacenes de datos, sin describir el medio.

Componentes del modelo esencial:

·         Modelo ambiental: define la frontera entre el sistema y el resto del mundo.

·         Modelo de comportamiento: describe el comportamiento que del sistema se requiere para que interactue de manera exitosa con el ambiente.

 

El modelo esencial describe:

·         La política o lógica, esencial de las funciones que se requiere realizar.

·         El contenido esencial de los datos que almacena y se mueven a través de el.

·         El comportamiento esencial dependiente del contexto.

 

Modelo de implementación del Usuario

Debe cubrir lo siguiente:

·         Distribución del modelo esencial entre personas y maquinas.

·         Detalles de la interacción humano – maquina.

·         Actividades manuales que se podrían requerir.

·         Restricciones operativas que el usuario desea imponer al sistema.

 

Determinación de la frontera de automatización

 

La frontera de automatización es casi irrelevante en el modelo esencial pues el usuario necesita una declaración bien hecha de los requerimientos de las funciones y datos que queden justo fuera de la frontera de automatización.

Hay tres casos extremos:

·         Al usuario no le importa donde este la frontera.

·         El usuario quiere escoger un sistema totalmente automatizado.

·         El usuario quiere un sistema totalmente manual.

 

Generalmente estas opciones extremas no ocurren. Basándose en interacciones con el usuario y el analista, se llegara a un compromiso. Se automatizara parte de las actividades del modelo esencial y otras se identificaran como manuales. No es labor del analista escoger la frontera de automatización, sino responsabilidad del usuario.

 

Identificación de las actividades de Apoyo

 

En el modelo ambiental se supone la existencia de tecnología perfecta, que significa entre otras cosas, suponer que la tecnología de implantación nunca se descompondrá o cometerá errores.

En general hay que preocuparse por la posibilidad de tecnología defectuosa en cuatro áreas principales:

·         Ingreso de datos al sistema.

·         Realización de cálculos.

·         Almacenamiento a largo plazo de datos.

·         Salida de datos del sistema.

 

Podría decidir añadirse cualquiera de lo siguiente al modelo esencial para vérselas con tecnología defectuosa:

·         Entradas o salidas redundantes.

·         Tecnología de procesador redundante.

·         Redundancia interna.

·         Controles por lote. 

·         Verificaciones secuenciales

 

Especificación de restricciones operacionales

 

Finalmente, se deberá decidir la combinación de hard, S.O., equipo de telecomunicaciones, lenguaje de programación y estrategia de diseño. Las cuestiones típicas son:

·         Volumen de datos.

·         Tiempo de respuesta de las entradas.

·         Restricciones políticas sobre modalidades de implantación.

·         Restricciones ambientales.

·         Restricciones de confiablidad y seguridad.

·         Restricciones de seguridad.

 

Modelo de Implementación de Programas

 

El diseño del software es un proceso mediante el que se traducen los requisitos en una representación del software.

El diseño del software se realiza en dos pasos:

·         El diseño preliminar se centra en la transformación de los requisitos en los datos y la arquitectura del software. (Modelo implementable, modelo arquitectonico)

·         El Diseño detallado se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algoritmicas del software. (Modelo procedimental y modelo de interfaz)

Dentro de los diseños preliminar y detallados, se llevan a cabo varias actividades de diseño diferentes. Además del diseño de datos, el arquitectónico y del procedimental, muchas aplicaciones modernas requieren diseño de la interfaz.

El diseño de la interfaz establece la disposición y los mecanismos para la interacción hombre maquina.

 

Fundamentos del diseño

 

Se han establecido un conjunto de conceptos fundamentales para el diseño de software:

·         Abstracción: pueden formularse muchos niveles de abstracción. En el nivel superior, se establece una solución en términos amplios. En los niveles inferiores, se toma una orientación mas procedimental. En el nivel mas bajo, se establece la solución de forma que pueda implementarse directamente. Conforme nos movemos por diferentes niveles de abstracción, trabajamos para crear abstracciones de datos y de procedimientos. Una abstracción procedimental es una determinada secuencia de instrucciones que tienen una función limitada y especifica. (los conceptos de refinamiento sucesivo y modalidad, están muy cerca del de abstracción).

Una vez que se ha definido una abstracción de datos, tambien se puede definir un conjunto de operaciones que pueden aplicarsele.

La abstraccion de controls, es la tercera forma de abstraccion que se utiliza en el diseño del softwares. Implica un mecanismo de control de programa, sin especificar los detalles internos usados para coordinar actividades en una S.O.

 

·         Refinamiento: es una primera estrategia de diseño descendente. La arquitectura de un programa se desarrolla en niveles de jerarquia descompoiniendo una declaracion macroscopica de una funcion de una forma sucesiva.

El refinamiento es un proceso de elaboracion. Hace que el diseñador amplie la declaracion original, dando cada vez mas detalles conforme se produzcan los sucesivos refinamientos.

 

·         Modularidad: el soft se divide en componentes con nombres y ubicaciones determinados, que se denominan modulos y que se integran para satisfacer los requisitos del sistema. Si partiesemos el soft indefinidamente, el esfuerzo requerido para desarrollarlo seria insignificantemente pequeño. El esfuerzo de desarrollo de un modulo individual disminuye conforme aumenta el numero total de modulos, el esfuerzo asociado a las interfaces entre los modulos, tambien crece. Hay un numero M de modulos para el que el coste de desarrollo es minimo, pero no tenemos los medios suficientes para predecir M con seguridad. Debe evitarse una excesiva modularizacion, asi como una pobre. El tamaño de un modulo, dependera de su fucion y su aplicación. Es importante tener en cuenta que un sistema se puede diseña de forma modular, incluso aunque su implementacion tenga que ser monolitica.

 

·         Arquitectura del Soft: se obtiene mediante un proceso de particion que relaciona los elementos de una solucion de soft con partes de un problema del mundo real definido implicitamente durante el analisis de los requisitos. La solucion aparece cuando cada parte del problema esta resuelta mediante uno o mas elementos del soft. Un problema puede ser resuelto mediante diferentes estructuras. Cada metodo de diseño dara como resultado una estructura diferente, para el mismo conjunto de requisitos del software.

 

·         Jerarquia de control: representa la organización de los componentes del programa e implica una jerarquia de control. No representa aspectos procedimentales del software, tales como la secuencia de procesos, la ocurrencia u orden de decisiones o la repeticion de operaciones.

La mas comun es un diagrama en forma de arbol. La profundidad y la anchura son una indicacion del numero de niveles de control y la amplitud global del control. El grado de salida es una medida del numero de modulos que estan directamente controlados por otros modulos. El grado de entrada indica cuantos modulos controlan directamente al modulo dado.

Las relaciones se expresan asi: Superior (modulo que controla a otro), subordinado (modulo controlado por otro).

Tambien representa las caracteristicas, sutimente diferenetes de la arquitectura del soft: visibilidad y conectividad.

 

·         Estructura de datos: es una representacion de la relacion logica existente entre los elementos individuales de datos. Dicta la organización, los metodos de acceso, el grado de asociatividad y las alternativas de procesamiento para la informacion.

 

·         Procedimientos del Soft: se centra sobre los detalles de procesamiento de cada modulo individual. Debe proporcionar una especificacion precisa del procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones. Debe incluir referencias a todos los modulos subordinados del modulo que describe.

 

·         Ocultamiento de la Informacion: los modulos deben especificarse y diseñarse para que la informacion contenida en ellos sea accesible solamente a los modulos que necesiten dicha informacion. Implica que para conseguir una modularidad efectiva hay que definir un conjunto de modulos independientes, que se comuniquen con los otros mediante la informacion que sea necesaria para realizar la funcion del software.

 

Diseño modular efectivo

 

La modularidad se ha convertido en un enfoque aceptado en todas las discoplinsa de ingenieria. Un diseño moudlar reduce la complejidad, facilita los cambios y produce como resultado una implementacion mas sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un sistema.

 

Tipos de modulo: para definir modulos, se utiliza la abstraccion y el ocultamiento de informacion. Ambos atributos deben ser traducidos a caracteristyicas operativas del modulo.

 

Un modulo puede ser clasificado como:

 

·         Secuencial: se ejecuta sin interrupcion.

·         Incremental: puede ser intrrumpido y posteriormente, restablecida su ejecucion en el punto en que se interrumpio.

·         Paralelo: se ejecuta a la vez que otro modulo.

 

Los 6 atributos que definen un modulo son: 1) Funcion 2) Nombre 3) Entrada 4) Salida 5) Mecanismos 6) Datos Internos.

 

Diagrama de estructura

 

La diferencia que hay entre el DFD y el diagrama de estructuras, es que el primero representa secuencialidad y el segundo representa jerarquia.

 

Propiedades del diagrama de estructuras

·         Hay niveles de complejidad en el mismo nivel, son iguales. La cantidad de niveles me define la profundidad.

·         Profundidad: es la cantidad de niveles que tiene el diagrama.

·         Grado de salida: es una caracteristica de un modulo no de el diagrama. Es la cantidad de subordinados directamente al modulo.

·         Grado de entrada: tambien se mide sobre un modulo, es la cantidad de modulos que llaman a un modulo determinado.

·         Amplitud global o anchura: el nivel que tiene mas modulos me da la anchura.

·         Alcance de control o visibilidad: se mide por modulo, es la cantidad de modulos que el llama directa o indirectamente.

·         No se puede repetir el nombre de un modulo.

 

Cohesion

 

Grado de relacion entre los elementos de un modulo. Si evaluamos el acoplamiento y la cohesion nos puede dar la calidad de un buen sistema de informacion.

La cohesion tiene que ser alta para que el sistema sea bueno.

A mayor cohesion menor acoplamiento.

 

Tipos de Cohesion:

·         Funcional: Es la ideal, todos los elementos del modulo contribuyen a cumplir una misma funcion (la del modulo).

·         Secuencial: Cuando los elementos de un modulo tienen (o pueden tener) distintas funciones, se relacionan con los mismos datos (comparten los datos) e importa el orden.

·         Comunicacional: Es igual al secuencial, pero difiere en que no importa el orden en que se ejecuten estos elementos. Es una variante la secuencial.

·         Procedural o procedimental: Los elemento estan relacionado por flujo de control. Son procedimientos obligatorios de la empresa: ingresarlo a la DB, darle una credencial, hacer tarjetas personales (cuando ingresa un nuevo empleado). No es bueno porque los procedimientos cambian constantemente. Importa el orden.

·         Temporal: La relacion es que tienen que ejecutarse al mismo tiempo. No importa el orden y conviene que evitarlos.

Para solucionar puedo hacer modulos distintos y que este tenga llamadas a funciones. Al estar separado en mas modulos me permite que sean rehusables. Hay que mirar los tipos de cohesion en el sentido de funcion, no de procedimiento.

·         Logica: Los elementos tienen el mismo nivel o categoria y estan relacionados a travez de un mismo elemento de datos. Esta muy ligado con el acolpamiento de control. Cuando hay acoplamiento de control, habra cohesion logica.

·         Coincidental: La relacion esta dada por coincidencia, no tienen un sentido.

 

Como determinar el grado de cohesion de un modulo:

 

 

                                      Funcional

                            Si

 

Tiene una sola                                                                       Si procedimental

Funcion?                                                                    Orden? 

                            No                         flujo de control                  No  Temporal

                                                                              

                                      Relacion de los                                    Si   Secuencial

                                      Modulos                  datos       Orden?

                                                                                              No  Comunic.

 

                                                           ninguno         = nivel       Si    Logico

                                                                           de actividad

                                                                                     No Coincidental

 

 

Acoplamiento

 

Propiedad que se define entre dos modulos, es el grado de relacion que hay entre estos dos modulos.

Para tener modularidad efectiva, hay que tratar de tener menos acoplamiento.

Con el menor acoplamiento logramos que si hay que cambiar un modulo no impacte en otro modulo y asi se produzca el efecto onda. Si hay demasiado acoplamiento, hay que analizar si no conviene juntarlos. Ademas si un modulo no esta tan relacionado con otro, lo puedo usar en otro lado.

 

                   Parametros tipo dato ( se puede procesar ).

 

                   Parametros tipo flag (no se pueden procesar ).

 

·         De datos: Cuando existe conexión entre los modulos y la comunicación es a travez de estructuras de datos simples (variables)

 

 

 

Ej.: Se envian datos simples y se devuelven simples

 

·         Estampado: Estan conectados y la comunicación es a travez de estructuras de datos compuestas (registros).

 

 

 

Ej.:Se envian datos compuestos y devuelve simples.

Como el segundo modulo retorna datos simples  la relacion es de datos y estampado. En estos caso se toma el de mayor acoplamiento. En ese caso seria estampado.

 

·         De control: Estan conectados y la comunicación es a travez de un indicador, flag o señal a partir de la cual se pueden tomar deciciones en el modulo subordinado o superior.

 

 

 

 

La desventaja es que hay mucha relacion entre los modulos, depende mucho uno de otro.

Ej.: El modulo subordinado, debe saber que opcion le manda el superior. El modulo subordinado no le puede informar al superior que datos debe enviarle.

 

Soluciones:

Que el subordinado devuelva un mensaje de error, y el superior decida que hacer.

         Que el subordinado cometa error, y no devuelva nada.

·         Comun o por area global: Pueden o no estar conectados, pero si comparten un area global de datos (variables globales).

Ej.: Si en una DB, tengo tres modulos que comparten una tabla y decido sacar una columna de la tabla, debo modificar los modulos que hagan referencia a la tabla.

 

 

·         Contenido o patologico: Cuando un modulo refernecia a otro de la siguientes formas:

Para extraer o modificar datos de ese modulo.

Se bifurca al interior de otro modulo.

Para modificar la sentencia de otro modulo.

Se da en lenguajes de bajo nivel (c, cobol, pascal).

 

Diseño orientado al flujo de datos

 

Permite una comoda transaccion de las representaciones de la informacion contenido en una especificacion de requisitos del software. Se realiza en 5 pasos:

·         Establecer el tipo de flujo de informacion.

·         Determinar los limites del flujo.

·         Convertir el DFD en la estructura del programa.

·         Definir al jerarquia de control mediante factorizacion.

·         Refinar la estructura resultante usando medidas y heuristicas de diseño.

 

Existen dos tipos de flujos de informacion:

 

·         Flujo de transformacion: La informacion entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como flujo entrante. En el interior del soft, se produce una transicion. Las datos entrantes pasan a traves de un centro de transformacion, moviendose por caminos hacia la salida, ahora se llama flujo saliente. 

·         Flujo de transaccion: se caracteriza por el movimiento de datos a traves de un camino de llegada que convierte la informacion del mundo exterior en una transaccion. Se evalua la transaccion y de acuero con su valor, el flujo sigue uno de los caminos de accion. Desde donde se emanan los caminos de accion, se llama centro de transaccion.

 

 

Diseño de Base de datos

 

Para la metodologia de desarrollo de base de datos, hay tres etapas:

 

·         Analisis

·         Diseño

·         Construccion

 

ANALISIS: Modelamos los datos. Modelamos la memoria esencial. Se modela el DER para ver como se relacionan los datos.

 

 

                  

         Requerimiento                                    DER

 

 

 

 

DER: Diagrama de Entidad de Relacion