Vous êtes sur la page 1sur 11

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 cmo se implantara. Supone tecnologa perfecta y sin costo. Se debe evitar describir implantaciones especificas de procesos en el sistema. No debe mostrar las funciones del sistema que estn 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 poltica o lgica, esencial de las funciones que se requiere realizar. El contenido esencial de los datos que almacena y se mueven a travs de el. El comportamiento esencial dependiente del contexto. Modelo de implementacin del Usuario Debe cubrir lo siguiente: Distribucin del modelo esencial entre personas y maquinas. Detalles de la interaccin humano maquina. Actividades manuales que se podran requerir. Restricciones operativas que el usuario desea imponer al sistema. Determinacin de la frontera de automatizacin La frontera de automatizacin es casi irrelevante en el modelo esencial pues el usuario necesita una declaracin bien hecha de los requerimientos de las funciones y datos que queden justo fuera de la frontera de automatizacin. 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. Basndose 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 automatizacin, sino responsabilidad del usuario. Identificacin de las actividades de Apoyo 1

En el modelo ambiental se supone la existencia de tecnologa perfecta, que significa entre otras cosas, suponer que la tecnologa de implantacin nunca se descompondr o cometer errores. En general hay que preocuparse por la posibilidad de tecnologa defectuosa en cuatro reas principales: Ingreso de datos al sistema. Realizacin de clculos. Almacenamiento a largo plazo de datos. Salida de datos del sistema. Podra decidir aadirse cualquiera de lo siguiente al modelo esencial para vrselas con tecnologa defectuosa: Entradas o salidas redundantes. Tecnologa de procesador redundante. Redundancia interna. Controles por lote. Verificaciones secuenciales Especificacin de restricciones operacionales Finalmente, se deber decidir la combinacin de hard, S.O., equipo de telecomunicaciones, lenguaje de programacin y estrategia de diseo. Las cuestiones tpicas son: Volumen de datos. Tiempo de respuesta de las entradas. Restricciones polticas sobre modalidades de implantacin. Restricciones ambientales. Restricciones de confiablidad y seguridad. Restricciones de seguridad. Modelo de Implementacin de Programas El diseo del software es un proceso mediante el que se traducen los requisitos en una representacin del software. El diseo del software se realiza en dos pasos: El diseo preliminar se centra en la transformacin de los requisitos en los datos y la arquitectura del software. (Modelo implementable, modelo arquitectonico) El Diseo detallado se ocupa del refinamiento de la representacin arquitectnica que lleva a una estructura de datos detallada y a las representaciones algoritmicas del software. (Modelo procedimental y modelo de interfaz) Dentro de los diseos preliminar y detallados, se llevan a cabo varias actividades de diseo diferentes. Adems del diseo de datos, el arquitectnico y del procedimental, muchas aplicaciones modernas requieren diseo de la interfaz. El diseo de la interfaz establece la disposicin y los mecanismos para la interaccin hombre maquina. Fundamentos del diseo Se han establecido un conjunto de conceptos fundamentales para el diseo de software: 2

Abstraccin: pueden formularse muchos niveles de abstraccin. En el nivel superior, se establece una solucin en trminos amplios. En los niveles inferiores, se toma una orientacin mas procedimental. En el nivel mas bajo, se establece la solucin de forma que pueda implementarse directamente. Conforme nos movemos por diferentes niveles de abstraccin, trabajamos para crear abstracciones de datos y de procedimientos. Una abstraccin procedimental es una determinada secuencia de instrucciones que tienen una funcin limitada y especifica. (los conceptos de refinamiento sucesivo y modalidad, estn muy cerca del de abstraccin). Una vez que se ha definido una abstraccin 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 diseo 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 diseo 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 diseador 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 pequeo. 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 tamao de un modulo, dependera de su fucion y su aplicacin. Es importante tener en cuenta que un sistema se puede disea 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 diseo dara como resultado una estructura diferente, para el mismo conjunto de requisitos del software. Jerarquia de control: representa la organizacin 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 3

conectividad. Estructura de datos: es una representacion de la relacion logica existente entre los elementos individuales de datos. Dicta la organizacin, 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 disearse 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. Diseo modular efectivo La modularidad se ha convertido en un enfoque aceptado en todas las discoplinsa de ingenieria. Un diseo 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 4

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 conexin entre los modulos y la comunicacin es a travez de estructuras de datos simples (variables) Ej.: Se envian datos simples y se devuelven simples Estampado: Estan conectados y la comunicacin 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 comunicacin es a travez de un indicador, flag o seal 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). Diseo 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 diseo. 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. Diseo de Base de datos Para la metodologia de desarrollo de base de datos, hay tres etapas: Analisis Diseo 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 Entidad externa.

Conjunto de atributos. Todos las entidades se vinculan entre si. DISEO: Se disea la base de datos. DER Definicion de entidades relacionales y de atributos CONSTRUCCION: Se crea la base fisicamente.. Caracteristicas del DER Sintaxis robusta. El der es calro y tiene un formato preciso. Entendible por el usuario. Facil comunicacin con el usuario. Facil desarrollo. A medida que lo voy desarrollando tambien es facil el refinamiento. Definicion de las fuentes. Da una imagen clara de los requerimientos de las fuentes de informacion. Integracion de multiples aplicaciones. Como en el DER modelo los datos despues de el se van a desprender distintas aplicaciones. Independencia de Hardware y Software. En el DER que creo lo puedo implementar en cualquier tipo de DB. Entidad: Es un objeto de relevancia cuya informacion se quiere mantener. Se actualiza, se consulta a travez de procesos. Tabla: Implementacion de una entidad. Convenciones para las entidades Sinonimo: Diferentes nombres para significar lo mismo. Una entidad debe tener multimples instancias (ocurrencias, filas). Hay tablas de una sola instancia. Cada instancia de una entidad debe tener valores determinados para cada uno de los atributos de la misma. ( osea que el conjunto de valores de los atributos en cada instancia es el mismo). Cada instancia debe tener un identificador unico. La fila es el conjunto de atributos que identifican a la entidad. La columna es el conjunto de valores que identifican al atributo. Las instancias no se pueden repetir. * Obligatorio, Not Null. o Opcional. # Identificador. En las tablas se ponen los atributos que Identifican y Describen a la entidad, no los que vinculan. Eso va 8

despues, cuando se relacionan. Practica 2 CURSO INSTRUCTOR #* Codigo #* Codigo * Nombre * Nombre * Costo o Numero de telefono * Duracion Relaciones: Vinculaciones entre una entidad y otra o en una misma (recursividad). Ej. Instruccin Curso Una relacion tiene tres componentes Nombre Opcionalidad Grado o cardinalidad La opcionalidad puede ser que una relacion puede o debe. Grado de cardianlidad es: (1 a n) , (n a 1), (n a n). Existe grado 0 cuando no hay nada en una de las entidades y en otra si. Es opcionaldad puedo. Convenciones de la relaciones Nombre Esta asignado a Tiene incluido Opcionalidad: Debe Puede Debe haber un empleado por departamento y puede haber un empleado por depto. Un empleado debe estar asignado a un departamento. Un depto. puede incluir un empleado. Cardinalidad: uno a uno o Numero de telefono. * Nombre # Codigo ALUMNO

uno a varios varios a varios Matriz de relaciones: herramienta para construir las relaciones del DER. Orden Emitido por Asignado por Item Incluido en Almacenado en Cliente Originario de Almacen Repositor de

Orden Item Cliente Almacen Se lee asi:

Atributos: Informacion sobre una entidad. Permiten calificar, identificar, clasificar y cuantificar. No deben incluir nunca el nombre de la entidad. Hay que verificar que cada atributo tenga un valor simple para cada instancia. Los atributos de calculo no se consideran atributos. No tiene sentido almacenar los resultados de otros atributos, porque son claculables sin tenerlos. Cuando un atributo tiene atributos propios, es otra entidad. El modelo de datos normalizado es el dueo de la base de datos. Entidades exclusivas Tienen el mismo nombre de relacion. Las descripciones de cada producto son excluyenetes. Una entidad puede no formar parte de dos relaciones exclusivas. Modelo SubTipo Tiene entidades que contienen atributos en comun. Son excluyentes. Si la relacion es en el borde del general, es que se relaciona con cualquiera de los subtipos. Si solo llega a un subtipo, quiere decir que se relaciona solo con ese subtipo. Se utiliza para modelar relaciones exclusivas que tienen atributos y relaciones en comun. Debe tener atributos y relaciones compartidas por sus subtipos. Si no tuviera atributos y relaciones compartidas, serian excluyentes. Los subtipos, comparten atributos y relaciones y tienen atributos propios. Clave primaria identifica univocamente 10

no puede ser nula puede ser comnpuesta es unica Clave alternativa o candidatas Cuando tengo sos posible claves primarias y debo elegir una de esas dos como primaria. Clave foranea Es foranea en una entidad y primaria en otra. Es una columna o combinacion de columnas en una tabla principal y una clave primari en otra entidad. Si la foranea no existe en la tabla referencial, en la tabla principal toma valor null. Integridad de los datos Se refiere a la consistencia. Hay cuatro tipos de integridad. De la entidad. De referencia. De la columna. Definida por el usuario. La clave primaria siempre tiene que ser Not Null y Unique. El nombre de la tabla para identificar a una entidad puede ser plurar. Modelo explicito: Se genera una columna FK para cada relaion implicita o incluida en el arco. Modelo generico: igualo una columna simple y una columna de flag de relacion por el arco, la columna simple v a ser FK y la otra, not null

Espacio Tablas Vistas Indices Diseo DB

11

Vous aimerez peut-être aussi