Sistemas de Informacion II.

Envia tus archivos, resúmenes, monografías, etc.

Modelo Esencial, Modelo de implementación del Usuario, Determinación de la frontera de automatización, Identificación de las actividades de Apoyo, Modelo de Implementación de Programas, Fundamentos del diseño, Diagrama de estructura, diseño, construccion.

Agregado: 29 de AGOSTO de 2000 (Por ) | Palabras: 3555 | Votar | Sin Votos | Sin comentarios | Agregar Comentario
Categoría: Apuntes y Monografías > Computación > Varios >
Material educativo de Alipso relacionado con Sistemas Informacion II

Biografia y vida de Leopoldo II: Breve Biografia de Leopoldo II

Biografia y vida de Berengario II: Breve Biografia de Berengario II

Biografia y vida de Filipo Ii Rey De Macedonia : Breve Biografia de Filipo Ii Rey De Macedonia

Enlaces externos relacionados con Sistemas Informacion II

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

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

Entidad externa.

Conjunto de atributos.

Todos las entidades se vinculan entre si.

DISEÑO: Se diseña la base de datos.

Espacio

Tablas

Vistas

Indices

DER Definicion

de entidades relacionales

y de atributos

CONSTRUCCION: Se crea la base fisicamente..

Caracteristicas del DER

1. Sintaxis robusta. El der es calro y tiene un formato preciso.

2. Entendible por el usuario. Facil comunicación con el usuario.

3. Facil desarrollo. A medida que lo voy desarrollando tambien es facil el refinamiento.

4. Definicion de las fuentes. Da una imagen clara de los requerimientos de las fuentes de informacion.

5. Integracion de multiples aplicaciones. Como en el DER modelo los datos despues de el se van a desprender distintas aplicaciones.

6. 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 despues, cuando se relacionan.

Practica 2

CURSO

#* Codigo

* Nombre

* Costo

* Duracion

INSTRUCTOR

#* Codigo

* Nombre

o Numero de telefono

ALUMNO

# Codigo

* Nombre

o Numero de telefono.

Relaciones: Vinculaciones entre una entidad y otra o en una misma (recursividad).

Ej. Instrucción 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

uno a varios

varios a varios

Matriz de relaciones: herramienta para construir las relaciones del DER.

	Orden	Item	Cliente	Almacen
Orden	-	Incluido en	Originario de	-
Item	Emitido por	-	-	Repositor de
Cliente	Asignado por	-	-	-
Almacen	-	Almacenado en	-	-

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 dueño 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 Sub-Tipo

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 sub-tipo, quiere decir que se relaciona solo con ese sub-tipo.

Se utiliza para modelar relaciones exclusivas que tienen atributos y relaciones en comun.

Debe tener atributos y relaciones compartidas por sus sub-tipos. Si no tuviera atributos y relaciones compartidas, serian excluyentes.

Los sub-tipos, comparten atributos y relaciones y tienen atributos propios.

Clave primaria

• identifica univocamente

• 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

Sistemas de Informacion II.

Modelo Esencial

Modelo de implementación del Usuario

Determinación de la frontera de automatización

Identificación de las actividades de Apoyo

Especificación de restricciones operacionales

Modelo de Implementación de Programas

Fundamentos del diseño

Cohesion

Acoplamiento

Diseño de Base de datos

Caracteristicas del DER

Convenciones para las entidades

Practica 2

Convenciones de la relaciones

Nombre

Entidades exclusivas

Clave primaria

Clave alternativa o candidatas

Clave foranea

Integridad de los datos

Votar

Comentarios de los usuarios

Boletín de Novedades

Acceso rápido