diseño lógico y diseño físico
- 1. IFM-0435 SISTEMAS DE INFORMACION II UNIDAD I
- 2. DISEÑO CONCEPTUAL El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa
- 3. DISEÑO CONCEPTUAL Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución.
- 4. DISEÑO LÓGICO El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física.
- 5. ETAPAS Y TAREAS DEL DISEÑO LOGICO DETALLADO (diseña el exterior y documentarlo) 1.- Generar alternativas de solución (mínimo 2) Se puede generar alternativas: a) Agregando una función b) Eliminando una función o fundiéndola c) Modificando fuertemente el interior Se evalúan técnica, económica y operacionalmente las alternativas generadas. (bienes de capital; costo - beneficio) y se elige una.
- 6. ETAPAS Y TAREAS… 2.- Documentar la alternativa elegida Se debe documentar cada función del exterior, en formulario que contendrá: - Nombre de la función - Situación - Objetivo; lo que pretende hacer - Información de entrada; y de donde proviene; detallada - Información de salida; y a donde va; detallada - Archivos internos que usa: fichero, memoria, kárdex,.... - Recursos utilizados. Secretaria, máquinas, teléfono fax,.... - Procedimiento general (describir la manera en que ella se realizará) - Observaciones
- 7. ETAPAS Y TAREAS… 3.-Documentar los procedimientos administrativos Formularios usados; con su diseño. Se debe indicar todos los formularios a usar, los que usa ahora, y los que usará: - Flujograma de formularios; tabla de doble entrada origen - destino de los formularios original y copias que se tiene contemplado utilizar. - Sistemas de codificación usados. Los códigos que se utilizará, estén ya en uso o a ser usados ahora.
- 8. ETAPAS Y TAREAS… 4.-Requerimientos al interior. Se debe especificar aquí lo que se quiere que el computador acepte como información de entrada a él y que proveniente del exterior del sistema o medio ambiente, y lo que se quiere que el computador genere como información de salida para alimentar las funciones contempladas en el diseño del SI: Descripción de la información de Entrada, con el origen, cantidad, periodicidad, tipo. Descripción de la información de Salida. Se hace por medio del: - Diseño de los formularios de salida (listados que se espera) - Diseño de las pantallas de consultas (menú, formatos de respuestas)
- 9. EL DISEÑO LÓGICO GLOBAL Objetivo: Establecer las alternativas de diseño en relación a la situación actual, y elegir la "mejor" de ellas a través de un proceso de evaluación. El resultado final es un conjunto de funciones a ser realizadas por el sistema, junto con la especificación de la manera en que ellas se llevarán a cabo, los flujos de información que los conectarán y el rol del computador. Modelos : Se usa dos tipos de modelos para visualizar el sistema.
- 10. 1º.- Aquí el sistema se concibe como una "malla" o red de funciones interactuando a través de información que reciben de entradas de las funciones relacionadas, y generan salidas hacia ellas, y que además regulan el funcionamiento de la malla de los procesos del sistema.
- 11. 2º Visualizar el sistema como una partición jerárquica de cada uno de los elementos que lo componen en la forma: Entrada -- Función -- Salida. Los elementos son los que están en el modelo descrito en la malla de funciones. Es un diagrama del tipo árbol.
- 12. DISEÑO FISICO
- 13. El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o económica. El componente es la unidad de construcción elemental del diseño físico. Las características de un componente son: Se define según cómo interactúa con otros Encapsula sus funciones y sus datos Es reusable a través de las aplicaciones Puede verse como una caja negra Puede contener otros componentes
- 15. ACOPLAMIENTO: Mide el grado de independencia entre los módulo. Un buen diseño debe minimizar el acoplamiento (aumentar la independencia.) por las sig. Razones: 1º Cuanto menos conexiones existan entre 2 módulos, menos oportunidad hay de que aparezca el efecto RIPPLE (1 defecto de 1 módulo aparece afectando a otro). 2º Se desea poder cambiar un modulo sin que afecte a otro. 3º Mientras se mantiene un módulo, no debemos preocuparnos de otro, máxima sencillez.
- 16. COHESIÓN: Mide el grado de integración de los elementos de un módulo, para organizar todos los elementos de forma que los que estén más relacionados a la hora de realizar una tarea pertenezcan al mismo módulo y los elementos relacionados entre sí en módulos separados.
- 17. Cuanto más vinculados estén los elementos de un módulo, más fuerte es su cohesión, lo que lleva a un mejor acoplamiento y a un mejor sistema (el SW es fácil de mantener y los módulos fáciles de usar). A medida que aumenta el número de módulos, el coste por interfaz crece y el esfuerzo para desarrollar cada módulo decrece.
- 18. Iceberg de la usabilidad Qué es la Arquitectura del Software y que relación tiene con la usabilidad. Tener en cuenta la usabilidad en el momento del diseño de la arquitectura de un sistema interactivo nos puede ahorrar muchos problemas.
- 19. Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en cuenta: la presentación de la información la funcionalidad de la aplicación la Arquitectura del Software ¿Cuántas veces hemos tenido que correr a realizar cambios profundos en la funcionalidad de una aplicación después de haber detectado problemas de usabilidad?
- 20. Dick Berry, en su analogía del Iceberg de la usabilidad, explica que los aspectos relacionados con la presentación, es decir, lo que normalmente entendemos como look & feel, sólo afectan en un 40% a la usabilidad. El 60% restante está influenciado por lo que él llama “modelo del usuario”, que está constituido por los objetivos que el usuario quiere alcanzar con sus tareas.
- 21. Arquitectura de software y usabilidad El usuario pueda visualizar el progreso de sus peticiones, que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que ha introducido anteriormente, y muchas otras cosas. Si analizamos estos escenarios de interacción, veremos que la causa de que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en la Arquitectura del Software.
- 22. Arquitectura de software Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de: Definir los módulos principales Definir las responsabilidades que tendrá cada uno de estos módulos Definir la interacción que existirá entre dichos módulos: Control y flujo de datos Secuenciación de la información Protocolos de interacción y comunicación Ubicación en el hardware
- 23. La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”
- 24. Uno de los modelos más conocidos es el “4+1” de Philippe Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes: Vista lógica: describe el modelo de objetos. Vista de proceso: muestra la concurrencia y sincronía de los procesos. Vista física: muestra la ubicación del software en el hardware. Vista de desarrollo: describe la organización del entorno de desarrollo. Existe una quinta vista que consiste en una selección de casos de uso o de escenarios que los arquitectos pueden elaborar a partir de las cuatro vistas anteriores
- 25. Heurísticas de diseño Las heurísticas de diseño son un conjunto de recomendaciones que ayudan a mejorar la estructura del sistema, optimizando la modularidad. La aplicación de estas recomendaciones depende en gran medida del diseño específico, así como de las características del equipo físico donde se desarrolla el sistema.
- 26. 1).- Tamaño del módulo El desarrollo del sistema de una estructura modular define la funcionalidad propia de cada módulo. Sin embargo, es recomendable revisar independientemente cada módulo a efectos de optimizar su tamaño en número de sentencias, para facilitar el desarrollo técnico del programa y su posterior mantenimiento. En general, podemos resumir diferentes versiones sobre el tamaño óptimo de un módulo definiendo que, el coste en el desarrollo y mantenimiento de un sistema será óptimo, cuando su estructura esté compuesta por módulos con un tamaño comprendido entre 10 y 100 sentencias.
- 27. Tamaño del módulo Un módulo demasiado grande a menudo puede deberse a: a) Dos o más funciones han sido combinadas (frecuentemente con cohesión lógica) en un mismo módulo.
- 28. 2).- Ámbito de control Se llama ámbito de control de un módulo a todos los módulos llamados por él y a los llamados por éstos, es decir, a todos los módulos que hay por debajo de él, en esa rama del diagrama de descomposición funcional. Un módulo que llama a muchos otros puede ser difícil de entender, y en el otro extremo, si los módulos forman una larga secuencia lineal, es posible que pueda suprimirse alguno de ellos. Debe evitarse ambos extremos:
- 29. Ambito de control alto: Normalmente se produce cuando no se tienen en cuenta los niveles intermedios. El estudio de los grupos de módulos subordinados que permitan combinar sus funciones en una sola, puede solucionar el problema. Resistencia por parte del diseñador a delegar responsabilidades en módulos subordinados. Solución: debe considerarse la posibilidad de agruparse varios subordinados en una función combinada. El principio de cohesión debe guiar este proceso para evitar módulos de baja cohesión.
- 30. Ámbito de control bajo: Para optimizar una estructura de este tipo se deben revisar las posibilidades de descomponer las funciones en subfunciones con entidad propia, para formar nuevos módulos, o por el contrario, comprimir módulos subordinados en el módulo de nivel superior. esto es válido si se puede dar a los nuevos módulos un sentido dentro de la estructura del problema.
- 31. Ámbito de control correcto