Marco Referencial de la Arquitectura de Sistemas de Información

Kom i gang. Det er Gratis
eller tilmeld med din email adresse
Marco Referencial de la Arquitectura de Sistemas de Información af Mind Map: Marco Referencial de la Arquitectura de Sistemas de Información

1. Daniel Chacón Limón

2. Importancia en las Organizaciones

2.1. La arquitectura permite a la organización comprender mejor la forma en que está construído el Sistema de Información para mantener los datos del Sistema organizados de acuerdo a cómo fue planeado desde el inicio. También permite diseñar el Sistema con un enfoque dinámico y evolutivo desde el inicio, ofreciendo la posibilidad de mejorar, ampliar o modificar el Sistema de acuerdo a las necesidades que se presenten en el futuro.

3. Concepto

3.1. Es la organización básica de cualquier sistema que se encarga de los componentes y las relaciones entre estos y su entorno, así como su diseño y evolución.

4. Componentes

4.1. Organización

4.1.1. Acomoda y categoriza el contenido del sistema con base a los criterios seleccionados (ambiguos o subjetivos)

4.2. Navegación

4.2.1. Pueden ser globales, locales o contextuales con base en el contenido existente

4.3. Etiquetado

4.3.1. Elimina la ambigüedad, arbitrariedad y desorientación del lenguaje

4.4. Sistemas de Búsqueda

4.4.1. Ofrecen resultados coincidentes con las necesidades del usuario

4.5. Vocabulario

4.5.1. Se forma con un grupo de términos de lenguaje natural

5. Proceso

5.1. Planificación

5.1.1. Definir objetivos (misión, visión...)

5.1.2. Hacer una investigación temática

5.1.3. Estudiar el mercado y los usuarios

5.1.4. Seleccionar la información a utilizar

5.1.5. Definir los procesos de la producción

5.2. Organización

5.2.1. Organizar los procesos

5.2.2. Organizar los contenidos

5.2.3. Catalogar los contenidos

5.2.4. Crear una organización secuencial

5.2.5. Agrupar en categorías o clases

5.2.6. Clasificar la información en jerarquías

5.2.7. Asociar y relacionar los contenidos

5.2.8. Desarrollar una representación de contenidos

5.2.9. Hacer un diagrama de los contenidos organizados

5.2.10. Realizar un Maquetado del Sistema

5.2.11. Establecer los metadatos del contenido

5.3. Ejecución

5.3.1. Programación y almacenamiento del Sistema

5.4. Control

5.4.1. Efectuar Pruebas, Tests y Controles de calidad

6. Tipos

6.1. Tubería / Filtro

6.1.1. Orientada al Flujo de Datos.

6.1.2. Procesual y con menor ambigüedad.

6.1.3. Serie de transformaciones sobre piezas de los datos de entrada.

6.1.4. Secuencia de pasos conocidos.

6.1.5. + Simple de entender e implementar.

6.1.6. + Puede trabajar de manera paralela o distribuida.

6.1.7. - No puede ramificarse fácilmente.

6.1.8. - Es ineficiente usar condicionales, bucles y otros controles de flujo.

6.1.9. - No funciona con situaciones interactivas.

6.2. De Pizarra / Repositorio

6.2.1. Contiene 2 componentes principales: * Estructura de datos del estado actual. * Colección de componentes independientes que operan sobre ella.

6.2.2. Apto para operaciones complejas de interpretaciones de señales.

6.2.3. Requiere de:

6.2.3.1. Fuentes de Conocimiento para resolver el problemas.

6.2.3.2. Una pizarra (repositorio) con el estado actual de la resolución.

6.2.3.3. Una estrategia que regule el orden de las operaciones.

6.3. Model-View-Controller (MVC)

6.3.1. Su objetivo es tomar datos de almacenamiento y mostrarlos al usuario.

6.3.2. Separa el modelado del dominio, la presentación y las acciones sobre los datos en 3 clases:

6.3.2.1. Modelo. Administra el comportamiento y los datos del dominio.

6.3.2.2. Vista. Maneja la visualización de la información.

6.3.2.3. Controlador. Interpreta las entradas de usuario e informa al modelo y vista para que cambien según sea necesario.

6.3.3. + Soporte de vistas múltiples usando los mismos datos.

6.3.4. + Adaptación al cambio según los requerimientos del usuario y con facilidad.

6.3.5. - Es complejo de implementar y difícil de depurar.

6.3.6. Costoso de actualizar recientemente.

6.4. En Capas

6.4.1. Organización Jerárquica donde cada nivel sirve al inmediatamente superior.

6.4.2. Modelo característico: OSI.

6.4.3. Mínimo número de capas: 2 (Cliente-Servidor).

6.4.4. + Soporta diseños con altos niveles de abstracción.

6.4.5. + Las optimizaciones son sencillas de implementar.

6.4.6. + Permite una amplia reutilización de código, servicios y funciones.

6.4.7. - Es complicado crear una abstracción completa.

6.4.8. - No apta para aplicaciones simples pues las complica.

6.5. Orientada a Objetos

6.5.1. Basada en los principios Orientados a Objetos (OO): encapsulamiento, herencia y polimorfismo.

6.5.2. Las interfaces se separan en Implementaciones.

6.5.3. + Se puede modificar el objeto sin que afecte a los clientes.

6.5.4. + Los objetos son reutilizables.

6.5.5. - Las interacciones requieren conocimiento de las entidades por adelantado.

6.6. Basada en Componentes

6.6.1. Unidades de composición con interfaces especificadas y dependencias explícitas.

6.6.2. Una interfaz puede ser implementada por múltiples componentes.

6.7. Máquinas Virtuales

6.7.1. Intérpretes y sistemas basados en reglas.

6.8. Control de Procesos

6.8.1. Se caracterizan por los tipos de componentes y sus relaciones.

6.8.2. Su objetivo es mantener los valores dentro de los rangos especificados (llamados Puntos Fijos).

6.8.3. Arquitectura elástica ante ajetreos externos.

6.9. Basada en Atributos

6.9.1. Se le asocia un framework de razonamiento.

6.9.2. Su objetivo es proporcionar las bases para una disciplina con procesos predecibles y una metodología ad hoc.

6.9.3. Definen las condiciones en que los atributos de calidad serán usados.

6.10. Basada en Eventos

6.10.1. Referidas mayormente a interfaces de usuarios.

6.10.2. Se vincula con actores, "daemons" y redes de conmutación de paquetes.

6.10.3. En vez de invocar los procedimientos directamente, se difunden 2 o más eventos.

6.10.4. + Se optimiza el mantenimiento.

6.10.5. + El desarrollo en paralelo es recomendado.

6.10.6. + Sus transacciones pueden correr tanto de forma síncrona como asíncrona.

6.10.7. - No permite respuestas complejas.

6.10.8. - El componente no puede utilizar los datos o el estado de otro componente.

6.11. Orientada a Servicios

6.11.1. También conocida como "Procesos Distribuidos".

6.11.2. Se comunican a través de mensajes.

6.11.3. Cualquier equipo o entidad computacional puede comunicarse con otra.