sábado, 28 de mayo de 2016

Introducción



                       


Blog creado por ;
Elver Hernandez López 
Angel Brian López López

Materia ; Ingenieria de Software

Creado con el proposito de que otros internautas encuentren esta información útil 




      


A través de la historia de la ingeniería del software ha evolucionado un conjunto de conceptos fundamentales de diseño de software, aunque el grado de interés en cada concepto ha variado con los años, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados.

El diseño de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la aplicación. 

Estos modelos puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.

Diseño es definido como: "El proceso de definición de la arquitectura de componentes, interfaces y otras características de un sistema o componente que resulta de este proceso" [IEEE610.12-90].







Temas Claves en el Diseño de Software



  • Control y manejo de Eventos
Cómo organizar los datos y el controlar el flujo, manejo de reactivo y temporal de los acontecimientos a través de diversos mecanismos, tales como la invocación implícita de llamadas y sus intentos.
  • Distribución de Componentes
Cómo distribuir el software en el hardware, cómo los componentes se comunican, cómo se puede usar una plataforma al utilizarse para hacer frente a software heterogéneos.


  • Error y Gestión de Excepciones Tolerancia a Fallos.
El análisis y la gestión del riesgo son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre.

Un riesgo es un problema potencial que puede ocurrir o no. Pero sin tener en cuenta el resultado, realmente es una
buena idea es identificarlo, evaluar su
probabilidad de aparición, estimar
su impacto, y establecer un plan de contingencia por si ocurre el problema.


Una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia. Después, el equipo de Software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada.



Fundamentos del Diseño de Software



























  • Conceptos generales de diseño.
El software no es el único campo donde el diseño se encuentra inmiscuido. En general podemos ver el diseño como una forma para resolución de problemas. El problema sin solución definitiva es interesante en términos de comprensión del diseño. Un numero de otras nociones y conceptos son también de interés en la comprensión del diseño en su sentido general, objetivos, limitaciones, alternativas, representaciones y soluciones


  • Contexto del diseño de software.
El diseño del software se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de manera independiente al modelo de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseño del software es la última acción de la ingeniería correspondiente dentro de la actividad del modelado, la cual establece una plataforma para la construcción (generación de código y prueba).


"El milagro más común de la ingeniería de software es la transición del análisis al diseño y del diseño al códigoRichard Due


  • Proceso del Diseño de Software.
  • Diseño Arquitectónico.
El diseño arquitectónico puede representarse al usar uno o más de muchos modelos diferentes. Los modelos estructurales representan la arquitectura como una colección organizada de componentes del programa. Los modelos del marco de trabajo repetible incrementan el grado de abstracción del diseño al intentar identificar marcos de trabajo repetibles del diseño arquitectónico que se encuentran en tipos de aplicaciones similares.

  • Diseño Detallado.
El diseño detallado se describe el comportamiento específico de estos componentes.


  • Técnicas Permitidas.
  • Abstracción
Abstracción es el proceso o el resultado de la generalización de la reducción del contenido de la información de un concepto o un fenómeno observable, por lo general, con el fin de conservar únicamente la información que es relevante para un propósito en particular. Cuando se considera una solución modular a cualquier problema se pueden exponer muchos grados de abstracción.

Descomposición modular



a) Independencia funcional
Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.
Para medir la independencia funcional hay dos criterios:acoplamiento y cohesión


b) Acoplamiento
El acoplamiento es un medida de la interconexión entre módulos en la estructura del programa. Podemos graduardarla en un amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interfase:

. Fuerte
– Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.
– Común, se emplea una zona común de datos a la que tienen acceso varios módulos.
. Moderado
– De control, la zona común es un dispositivo externo al que estan ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos.
– Por etiqueta, intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, árbol,grafo,…)
. Débil
– De datos, viene dado por los datos que intercambian los módulos. Es el mejor.
– Sin acoplamiento directo , es el acoplamiento que no existe


c) Cohesión
Un módulo coherente ejecuta una tarea sencilla en un procedimiento de sw y requiere poca interacción con procedimientos que se ejecutan en otras partes de un programa. podemos decir que un módulo coherente es aquel que intenta realizar solamente una cosa.
Para que n° de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo.
  • ALTA
. Cohesión abstraccional, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos
. Cohesión funcional, el módulo realiza una función concreta y específica
  • MEDIA
. Cohesión secuencial, los elementos del módulo trabajan de forma secuencial
. Cohesión de comunicación, elementos que operan con el mismo conjunto de datos de entrada o de salida
. Cohesión temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej.Arrancar o parar dispositivos
  • BAJA
. Cohesión lógica, se agrupan elementos que realizan funciones similares.
. Cohesión coincidental, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna
La descripción del comportamiento de un módulo permite establecer el grado de cohesión:
– Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA
– Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o secuencial
– Si la descripción no se refiere a algo especifico(Ej. Todos los errores), cohesión lógica
– Si aparece “inicial-izar”, “preparar”, “configurar”, probablemente sea temporal.


d) Comprensibilidad
Para facilitar los cambios, el mantenimiento y la re utilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable:
– Identificación, el nombre debe ser adecuado y descriptivo
– Documentación, debe aclarar todos los detalles de diseño e implementan que no queden de manifiesto en el propio código
– SIMPLICIDAD, las soluciones sencillas son siempre laas mejores


e) Adaptabilidad
La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad:

– Previsión, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles

-Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementan para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación
– Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados

PATRONES DE DISEÑO



a) Independencia funcional
Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.
Para medir la independencia funcional hay dos criterios:acoplamiento y cohesión


b) Acoplamiento
El acoplamiento es un medida de la interconexión entre módulos en la estructura del programa. Podemos graduardarla en un amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interfase:

. Fuerte
– Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.
– Común, se emplea una zona común de datos a la que tienen acceso varios módulos.
. Moderado
– De control, la zona común es un dispositivo externo al que estan ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos.
– Por etiqueta, intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, árbol,grafo,…)
. Débil
– De datos, viene dado por los datos que intercambian los módulos. Es el mejor.
– Sin acoplamiento directo , es el acoplamiento que no existe


c) Cohesión
Un módulo coherente ejecuta una tarea sencilla en un procedimiento de sw y requiere poca interacción con procedimientos que se ejecutan en otras partes de un programa. podemos decir que un módulo coherente es aquel que intenta realizar solamente una cosa.
Para que n° de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo.
  • ALTA
. Cohesión abstraccional, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos
. Cohesión funcional, el módulo realiza una función concreta y específica
  • MEDIA
. Cohesión secuencial, los elementos del módulo trabajan de forma secuencial
. Cohesión de comunicación, elementos que operan con el mismo conjunto de datos de entrada o de salida
. Cohesión temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej.Arrancar o parar dispositivos
  • BAJA
. Cohesión lógica, se agrupan elementos que realizan funciones similares.
. Cohesión coincidental, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna
La descripción del comportamiento de un módulo permite establecer el grado de cohesión:
– Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA
– Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o secuencial
– Si la descripción no se refiere a algo especifico(Ej. Todos los errores), cohesión lógica
– Si aparece “inicial-izar”, “preparar”, “configurar”, probablemente sea temporal.


d) Comprensibilidad
Para facilitar los cambios, el mantenimiento y la re utilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable:
– Identificación, el nombre debe ser adecuado y descriptivo
– Documentación, debe aclarar todos los detalles de diseño e implementan que no queden de manifiesto en el propio código
– SIMPLICIDAD, las soluciones sencillas son siempre laas mejores


e) Adaptabilidad
La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad:

– Previsión, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles

-Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementan para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación
– Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados

Arquitectura en el Diseño del software




En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los años 1990 tras reconocerse la denominada crisis del software y como tema de interés de la incipiente disciplina de la ingeniería del software.

¿Qué es arquitectura?
Es la representación que capacita al ingeniero del software para:
  • Analizar la efectividad del diseño para la consecución de los requisitos fijados.
  • Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil.
  • Reducir los riesgos asociados a la construcción del software.


En el diseño arquitectónico, un componente del software puede ser tan simple como un módulo de programa, pero también puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuración de una red de clientes y servidores.


El diseño de la arquitectura del software tiene en cuenta 2 niveles de la pirámide, el diseño de datos y el diseño arquitectónico. El diseño de datos nos facilita la representación de los componentes de datos de la arquitectura. El diseño arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones.

¿Por qué es importante la arquitectura?
  • Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computadora.
  • Destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software.
  • Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.


Arquitecturas más comunes

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:


Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.


Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). 

Una capa solamente tiene relación con la siguiente.
Otras arquitecturas afines menos conocidas son:

  • Modelo Vista Controlador.
  • En pipeline.
Entre pares.
  • En pizarra.
  • Orientada a servicios.
  • Dirigida por eventos.
  • Máquinas virtuales

Modelos o vistas

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

  • La visión estática: describe qué componentes tiene la arquitectura.
  • La visión funcional: describe qué hace cada componente.
  • La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.

Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. 

El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. 

Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).



DISEÑO DE SOFTWARE DE LA ARQUITECTURA MULTIPROCESADOR





¿De que trata ?


Los sistemas multiprocesador (MP) son un tipo de arquitectura con una importancia creciente y ampliamente difundido. La mayoría de los constructores de computadores ofrece máquinas en las que están presentes más de una CPU, configuración que es hoy en día de uso habitual en casi todos los sistemas de tamaño medio y grande, incluso ya en ordenadores personales. 

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las cpu´s solo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultanea varios procesos es tener varias cpu´s ya sea en una maquina o en varias en un sistema distribuido.


Los sistemas de software compuestos de procesos múltiples no necesariamente son sistemas distribuidos. Si mas de un procesador esta disponible, entonces se puede implementar la distribución, pero los diseñadores del sistema no siempre consideran los puntos de distribución durante el proceso de diseño. El enfoque de diseño para este tipo de sistema es el mismo para los de Tiempo Real.
ejecutándolas. Para el desarrollo de estos procesos se ocupan modelos de programación concurrente y paralela:
Los objetivos de la programación paralela, son:
·Reducir el tiempo de cómputo.
·Reducir la complejidad del algoritmo,
·Aprovechar al máximo la capacidad de las computadoras multiproceso.

Existen diferentes tipos de programación:
Multihilo: El cual permite a una aplicación realizar varias tareas concurrentemente.

Los distintos hilos que se ejecutan comparten una serie se recursos.
Ø  Pase de mensaje:
MPI ("Message Passing Interface") es un estándar que define la sintaxis y la semántica de las funciones usada en programas que exploten la existencia de múltiples procesadores.

VENTAJAS:
v  La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.
v  Los hilos que se ejecutan comparten ciertos recursos como el espacio del mensaje, la cual permite simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones simultáneamente.
v  Es económica
v  Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para adecuarse a la necesidad.
v  El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento.
DESVENTAJAS:
v  Puede ser limitante física, existen factores que limitan la velocidad máxima de un procesador independiente del factor económico.
v  Las barreras físicas infranqueables tales como la velocidad de la luz, efectos al reducir el tamaño.
    Problemas causados por fenómenos eléctricos a pequeñas escalas restringen la capacidad máxima del sistema multiprocesador.