Un video de interés.

Presentamos a ustedes un video de mucho interés. Esperamos que sea de suma utilidad.

Introducción.

Con este blog trataremos de dar presente nuestra intención y es la de presentar este material y poner en conocimiento este tema que es de mucho interés para no solo a los ingenieros sino a las personas que no conocen estas herramientas, y que las sepan utilizar para que las apliquen en alguna dificultad relacionada con los sistemas. A través de estos contenidos esperamos a los visitantes que lean esta temática y sepan como aprovecharlos de manera clara y correcta y adquirir conocimiento de resolución a partir de estos temas.

El Análisis de Problemas.

Al tener una forma para percibir y concebir los problemas podemos concentrarnos también en la naturaleza y clase de los mismos. Entendiendo un problema como la desviación de una situación actual de una deseada en un punto de tiempo dado. Posee cinco componentes:
- Quienes enfrentan el problema y quien(es) toman decisiones
- Aspectos del problema que se pueden controlar
- Aspectos de la situación problema que se escapan del control de quien toma la decisión
- Las restricciones que se imponen desde dentro o desde fuera sobre los aspectos mencionados
- Los posibles resultados producidos al hacer una decisión

Existen además tres formas de hacerle frente a los problemas: Resolución, solución y disolución del problema
- Resolución: selección arbitraria de una acción lo suficientemente buena para eliminar el problema (enfoque clínico)
- Solución: selección de una acción de entre varias que ofrece el resultado óptimo (enfoque de investigación)
- Disolución: eliminación del problema mediante un cambio de intenciones de los involucrados o mediante un cambio de naturaleza y/o ambiente del problema (enfoque de diseño).

Aún así, cualquiera de los tres enfoques que se emplee no significa la completa desaparición de problemas, dado que el tratamiento de un problema genera nuevos problemas.
El analista de situaciones problema debe tener en cuenta dos conceptos del Enfoque de Sistemas que le ayudan a formular el problema:
- Toda situación problemática involucra a un sistema que contiene el problema y a otro que lo soluciona; debiéndose delimitar los límites de cada uno.
- Existen problemas bien estructurados, con objetivos definidos, fronteras y restricciones definidas y variables cuantificables (duros), y problemas mal estructurados, en los que todos sus elementos son en sí mismos problemáticos, no hay fronteras ni objetivos bien definidos y algunas de sus variables no son cuantificables (blandos).

La tarea del analista es construir una descripción pictórica de quien percibe qué clase de cambio es necesario en una situación y por qué razones. Realiza cuestionamientos para identificar el problema, sus posibles fuentes, su prioridad, posibles soluciones, implicaciones de la solución, recursos empleados, el proceso en cuestión (elementos que por su naturaleza cambian frecuentemente), ambiente, estructura (elementos que no cambian en el corto plazo dentro de la organización) en que se opera, etc. Algo fundamental para el analista es decidir al final de todo esto si el problema es duro o blando, y posteriormente preparar el equipo de estudio.

Además se hace énfasis en el ambiente del problema, queriendo decir que el ambiente está dentro del sistema del problema y del sistema que lo soluciona, pero del ambiente provienen las oportunidades y los hechos para tomar decisiones sobre el problema.

Formular un problema involucra las siguientes actividades para el analista:
- Seleccionar datos y sugerencias que conlleven a elaborar hipótesis y estructuras conceptuales
- Documentar el sistema que contiene el problema y el que lo soluciona (naturaleza, recursos)
- Comparar recursos del sistema que soluciona contra los requerimientos del que lo contiene
- Iterar un ciclo de actividades del problema e identificar sus interacciones
- Al existir un mayor entendimiento de las actividades se documenta completamente el problema
- Recolectar datos del problema y definir objetivos del estudio - Definir el sistema que contiene el problema (dueño, tomador de decisión, objetivos, valores)

Documentar el problema puede tener un formato como el siguiente:
1. Fuente y antecedentes del problema
2. Razones para la atención
3. Grupos o instituciones hacia los cuales se dirige la actividad correctiva
4. Beneficiarios y perdedores
5. Programas relacionados y actividades
6. Metas y objetivos
7. Medidas de efectividad
8. Estructura para el análisis
Clases de alternativas, métodos posibles, suposiciones críticas
9. Alternativas
Descripciones, efectividad, costos, excesos, comentarios y otras consideraciones
10. Recomendaciones que puedan surgir
11. Apéndices (según se requieran)

Arquitectura en un sistema.

La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información.
La Arquitectura de Software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de información, cubriendo todas las necesidades.
Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.

La Investigación de Operaciones en la Ingeniería de Sistemas.

La Investigación de Operaciones en la Ingeniería de Sistemas se emplea principalmente en los aspectos de coordinación de operaciones y actividades de la organización o sistema que se analice, mediante el empleo de modelos que describan las interacciones entre los componentes del sistema y de éste con este con su medio ambiente
La Investigación de Operaciones o Investigación Operativa, es una rama de las Matemáticas consistente en el uso de modelos matemáticos, estadística y algoritmos con objeto de realizar un proceso de toma de decisiones. Frecuentemente, trata del estudio de complejos sistemas reales, con la finalidad de mejorar (u optimizar) el funcionamiento de los mismos. La investigación de operaciones permite el análisis de la toma de decisiones teniendo en cuenta la escasez de recursos, para determinar cómo se puede optimizar un objetivo definido, como la maximización de los beneficios o la minimización de costes.
Objetivos y métodos.
La investigación operacional consiste en la aplicación del método científico, por parte de grupos interdisciplinares, a problemas de control de sistemas organizativos con la finalidad de encontrar soluciones que atiendan de la mejor manera posible a los objetivos de la organización en su conjunto. No se sustituye a los responsables de la toma de decisiones, pero dándoles soluciones al problema obtenidas con métodos científicos, les permite tomar decisiones racionales. Puede ser utilizada en la programación lineal (planificación del problema); en la programación dinámica (planificación de las ventas); en la teoría de las colas(para controlar problemas de tránsito).
Fases
La elaboración del problema esta subdividida en fases obligatorias, las principales son:
• examen de la situación real y recolección de la información;
• formulación del problema, identificación de las variables controlables y las externas (no controlables) y la elección de la función objetivo, a ser maximizada o minimizada;
• construcción del modelo matemático, destinado a dar una buena representación del problema; debe ser fácil de usar; representar el problema, dando toda la información para poder tomar una decisión lo más idónea posible;
• resolución del modelo (mediante diferentes modalidades);
• análisis y verificación de las soluciones obtenidas: se controla si la función objetivo ofrece las ventajas esperadas; se verifica la representatibilidad del modelo; y, se efectúan análisis de sensibilidad de la solución obtenida.

Diseño de sistemas. Parte 2.

Administración de los recursos
El diseñador de sistemas debe identificar los recursos globales y tiene que determinar mecanismos para controlar el acceso a ellos. Entre los recursos globales se cuentan: unidades físicas, tales como procesadores, unidades de cinta y satélites de comunicación; espacio, tal como el espacio en disco, una pantalla de una estación de trabajo, y los botones de un ratón; nombres lógicos, tales como la identificación de los objetos, nombres de archivos y nombres de clases; y el acceso a datos compartidos, tales como bases de datos.
Si el recurso es un objeto físico se puede controlar a sí mismo estableciendo un protocolo para obtener el acceso dentro de un sistema concurrente. SI el recurso es una entidad lógica, tal como la identidad de un objeto, o una base de datos, existe el peligro de que el acceso produzca conflictos en un entorno compartido. Podría ser, por ejemplo, que varias tareas independientes utilizasen simultáneamente la misma identidad de un objeto. Todo recurso global debe ser poseído por un objeto guardián que controle el acceso a éste. Un objeto guardián puede controlar varios recursos. Todo el acceso al recurso debe pasar a través del objeto guardián. Por ejemplo, la mayoría de los administradores de bases de datos son tareas libres a las cuales invocan otras tareas para obtener datos de la base de datos. La asignación de cada recurso global compartido a un único objeto es un reconocimiento de que ese recurso tiene una identidad.
Un recurso lógico también se puede descomponer lógicamente, de forma que los subconjuntos se asignan a distintos objetos guardianes para ser controlados de modo independiente.
En una aplicación en la cual el tiempo sea crítico, el costo de pasar todo el acceso a un recurso a través de un objeto guardián resulta a veces excesivo, por lo que los clientes deben acceder directamente al recurso. En este caso, se pueden situar bloqueos en subconjuntos del recurso. Un bloqueo es un objeto lógico asociado con algún subconjunto definido de algún recurso que proporciona a quien posea el bloqueo el derecho de acceder directamente a ese recurso. Sigue siendo necesario que exista un objeto guardián para asignar los bloqueos, pero tras una interacción con el guardián para obtener un bloqueo, el usuario del recurso puede acceder directamente al recurso. Esta aproximación es más peligrosa porque hay que confiar en que todos los usuarios de recursos se comporten correctamente en su acceso al mismo. El uso de accesos directos a recursos compartidos no debe de propugnarse en un diseño orientado a objetos a no ser que resulte absolutamente necesario.
Software de control
Durante el análisis, todas las interacciones se muestran como sucesos entre objetos. El control del hardware se parece mucho al modelo de análisis, aunque el diseñador de sistemas de be escoger entre varias maneras de implementar el control en software. Aún cuando no existe una necesidad lógica de que todos los subsistemas utilicen la misma implementación, lo normal es que el diseñador seleccione un único estilo de control. Existen dos clases de flujos de control en un sistema de software: el control externo y el interno.
El control externo es el flujo de los sucesos externamente visibles entre los objetos del sistema. Existen tres clases de control para sucesos externos: secuencial, controlado por procedimientos, secuencial controlado por sucesos, y concurrente. El estilo de control que se adopte dependerá de los recursos disponibles y de la trama de interacciones existentes en la aplicación.
El control interno es el flujo de control dentro de un proceso. Solo existe en la implementación y, por tanto, no es inherentemente concurrente ni secuencial. El diseñador puede decidir descomponer un proceso en varias tareas por claridad lógica o por rendimiento. A diferencia de los sucesos externos, las transferencias internas de control, tales como las llamadas a procedimientos o las llamadas entre tareas, están dirigidas por el programa y se pueden estructurar de la forma que más convenga. Son frecuentes tres clases de control de flujo: llamadas a procedimientos, llamadas entre tareas que son casi concurrentes y llamadas entre tareas concurrentes. Las llamadas entre tareas casi concurrentes, tales como las corrutinas o procesos ligeros, son conveniencias de programación en las cuales existen múltiples espacios de direcciones o pilas de llamada, pero en las que solamente puede estar activo un hilo de control en cada momento.
DISEÑO DE LOS OBJETOS
La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque. La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.
Aspectos generales del diseño de objetos
Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecución, la memoria y el costo. En particular, las operaciones identificadas durante el análisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas. Las clases, atributos y asociaciones del análisis deben de implementarse en forma de estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos. La optimización del diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la extensibilidad son también objetivos importantes.
Algoritmos
Cada operación especificada en el modelo funcional debe ser formulada como un algoritmo. El análisis de especificaciones dice lo que hace la operación desde el punto de vista de sus clientes y los algoritmos muestran cómo se hace. Un algoritmo se puede subdividir en llamadas a operaciones más sencillas y así sucesivamente, hasta que las operaciones del nivel más bajo sean suficientemente sencillas para implementarlas directamente sin más refinamiento.
El diseñador de algoritmos debe:
- Seleccionar algoritmos que minimicen el costo de implementar las operaciones
- Seleccionar estructuras de datos adecuadas para los algoritmos
- Definir nuevas clases y operaciones internas según sea necesario
- Asignar la responsabilidad de las operaciones a las clases adecuadas
Controles
El diseñador debe refinar la estrategia para implementar los modelos de estados y sucesos presentes en el modelo dinámico. Como parte del diseño del sistema, se habrá seleccionado una estrategia básica para construir el modelo dinámico. Durante el diseño de objetos, es necesario desarrollar esta estrategia.
Para implementar el modelo dinámico hay tres aproximaciones básicas:
- Utilizar la posición dentro del programa para almacenar el estado (sistema controlado por procedimientos
- Implementación directa de un mecanismo de máquina de estados (sistema controlado por sucesos)
- Utilización de tareas concurrentes
Asociaciones
Las asociaciones son el pegamento de nuestro modelo de objetos, y proporcionan vías de acceso entre objetos siendo entidades conceptuales útiles para el modelado y el análisis. Durante la fase de diseño de objetos hay que formularse una estrategia para implementar las asociaciones habidas en el modelo de objetos. Se puede seleccionar una estrategia global para implementar todas las asociaciones uniformemente o bien seleccionar una técnica particular para cada asociación, teniendo en cuenta la forma en que será utilizada en la aplicación. Para tomar decisiones inteligentes acerca de las asociaciones se necesita analizar primero la forma en que serán utilizadas.

Diseño de sistemas. Parte 1.

El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado
La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. Una forma de caracterizar una aplicación es por la importancia relativa de sus modelos de objetos, dinámica y funcional. Las distintas arquitecturas ponen distintos grados de énfasis en los tres modelos.
El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. AL tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajarán independientemente en distintos subsistemas. El diseñador de sistemas debe tomar las siguientes decisiones:
- Organizar el sistema en subsistemas
- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades

Definición de subsistema
En todas las aplicaciones, salvo en las más pequeñas, el primer paso para diseñar un sistema consiste en dividir el sistema en un pequeño número de componentes. Cada uno de los componentes principales de un sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que comparten alguna propiedad común.
Un subsistema no es ni una función ni un objeto, sino un paquete de clases, asociaciones, operaciones, sucesos y restricciones interrelacionados, y que tienen una interfaz razonablemente bien definida y pequeña con los demás subsistemas. Normalmente, un subsistema se identifica por los servicios que proporciona. Un servicio es un grupo de funciones relacionadas que comparten algún propósito común, tal como el procesamiento de entrada-salida, dibujar imágenes o efectuar cálculos aritméticos. Un subsistema define una forma coherente de examinar un aspecto del problema.
Cada subsistema posee una interfaz bien definida con el resto del sistema. Ésta especifica la forma de todas las interacciones y el flujo de información entre los límites de subsistemas, pero no especifica cómo está implementado internamente el subsistema. Cada subsistema se puede diseñar, entonces, independientemente, sin afectar a los demás.
Los subsistemas deberían definirse de tal manera que la mayoría de las interacciones se produzcan dentro de y no entre los límites de distintos subsistemas, con objeto de reducir las dependencias existentes entre ellos. Todo sistema debería dividirse en un pequeño número de subsistemas. Cada subsistema, a su vez, debe descomponerse en subsistemas propios aún más pequeños. Los subsistemas de más bajo nivel se denominan módulos.
La relación entre dos subsistemas puede ser cliente-proveedor o punto a punto. En las primeras, el cliente debe conocer la interfaz del proveedor, pero éste no necesita conocer las interfaces de aquellos porque todas las interacciones son iniciadas por los clientes, empleando la interfaz del proveedor. En una relación entre pares, cada subsistema puede llamar a los demás. Una comunicación desde un subsistema hacia otro no va necesariamente seguida por una respuesta inmediata. Las interacciones entre pares son más complejas porque los subsistemas deben conocer las interfaces del otro. Hay ciclos de comunicaciones que son difíciles de entender y proclives a sutiles errores de diseño. Hay que buscar descomposiciones cliente-proveedor siempre que sea posible, porque una interacción mono direccional es mucho más fácil de construir, comprender y modificar que una interacción bidireccional.
Identificación de la concurrencia
EN el modelo de análisis, al igual que en el mundo real y en el hardware, todos los objetos son concurrentes. En una implementación, sin embargo, no todos los objetos del software son concurrentes, porque un procesador puede dar soporte a muchos objetos. En la práctica, se pueden implementar muchos objetos en un único procesador si los objetos no pueden estar activados a la vez. Un objetivo importante del diseño del sistema es identificar los objetos que deben estar activados concurrentemente, y los objetos que tienen actividad que sea mutuamente exclusiva. Estos últimos objetos se pueden plegar y juntar en un único hilo de control o tarea.
Asignación
Cada subsistema concurrente debe ser asociado a una unidad de hardware, bien a un procesador de propósito general o a una unidad funcional especializada. El diseñador del sistema deberá:
- Estimar las necesidades de rendimiento y los recursos necesarios para satisfacerlas
- Seleccionar las implementaciones de hardware o de software para los subsistemas
- Asignar los subsistemas de software a los procesadores para satisfacer las necesidades de rendimiento y para minimizar la comunicación entre procesadores
- Determinar las conexiones de las unidades físicas que implementan los subsistemas.
Almacenamiento de datos
Los almacenes de datos internos y externos dentro de un sistema proporcionan puntos limpios de separación entre subsistemas con interfaces bien definidas. En general, todo almacén de datos puede combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos de almacenamiento secundario. Los distintos tipos de almacenes de datos proporcionan diversas compensaciones entre costo, tiempo de acceso, capacidad y fiabilidad.
Los archivos son una forma de almacenamiento de datos barata, sencilla y permanente. Sin embargo, las operaciones de archivos son de bajo nivel y las aplicaciones deben incluir un código adicional para proporcionar un nivel de abstracción adecuado. Las implementaciones de los archivos son distintas según los diferentes sistemas de computadoras, así que las aplicaciones transportables deben de aislar cuidadosamente las dependencias con sistemas de archivos. Las implementaciones para archivos secuenciales son las más comunes, pero las ordenes y los formatos de almacenamiento para ficheros de acceso aleatorio e indexado varían mucho.
Las bases de datos, que son administradas mediante sistemas de gestión de bases de datos, son otro tipo de almacenamiento. Existen varios tipos de sistemas de gestión disponibles comercialmente: jerárquicos, en red, relacionales, orientados a objetos y lógicos. Estos sistemas intentan reservar los datos de acceso frecuente en memoria, con objeto de alcanzar la mejor combinación posible de costo y rendimiento desde y hacia la memoria y el almacenamiento en disco. Las bases de datos son potentes y hacen que las aplicaciones sean más fáciles de transportar a sistemas operativos y a distintas plataformas, por cuanto el vendedor transporta el código del sistema de gestión. Una desventaja es que tienen una interfaz compleja.
Las siguientes líneas generales caracterizan el tipo de datos que pertenece a una base de datos formal:
- Datos que requieran un acceso a niveles finos de detalle por parte de múltiples usuarios
- Datos que puedan ser administrados eficientemente mediante órdenes de un sistema gestor de base de datos
- Datos que deban transportarse a través de múltiples sistemas operativos y muchas plataformas hardware
- Datos a los que deba acceder más de un programa de aplicación
Las siguientes líneas caracterizan las clases de datos que pertenecen a un archivo y no a una base de datos relacional:
- Datos que sean voluminosos respecto a cantidad pero difíciles de estructurar en los confines de un sistema de datos.
- Datos que sean voluminosos en cantidad y con una baja densidad de formación
- Datos crudos que estén resumidos en la base de datos
- Datos volátiles que se mantengan durante un corto periodo de tiempo y se descarten después.