BIENVENIDA

    BIENVENIDOS…

Este blog es realizado con la finalidad de aprender y dar a conocer información y conocimientos con respecto a los que es la Ingeniera del Software, y más aun el Diseño Arquitectónico, esta información es recolectada a través de una serie de paginas y documento con la finalidad de dar a conocer la importancia de la Ingeniería del Software y el Diseño Arquitectónico en la realización de los proyectos de software, puesto que permiten tener una gestión de los recursos y actividades a realizar, así como una estructura en la que se pueden plasmar de manera eficaz todos los componentes de un sistema, lo que beneficiara al programador al momento de desarrollar el software en cada una de sus fases u etapas. 

Esperando que sea de su agrado y ayude a la compresión de los diferentes temas aquí plasmados...

INGENIERÍA DE SOFTWARE - ARQUITECTURA DEL SOFTWARE

INGENIERÍA DE SOFTWARE - ARQUITECTURA DEL SOFTWARE

En los primeros tiempos de la informática, la programación se consideraba un arte y se desarrolló como tal debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y directrices generales, sobre la base de las cuales se pueden resolver los problemas. Se han llamado arquitectura de software, porque, al igual que los planos de un edificio o una construcción, indican la estructura, el funcionamiento y la interacción entre las partes del software. Por lo que, la arquitectura de software es el diseño de más alto nivel de la estructura de un sistema.

§ Una arquitectura de software, también llamada arquitectura lógica, consiste en un conjunto de patrones coherentes y abstracciones que proporcionan un marco definido y claro para interactuar con el código fuente del software.

§ La arquitectura de un programa informático se selecciona y diseña en función de los objetivos (requisitos) y las limitaciones. Los objetivos son los prefijados para el sistema de información, pero no sólo los funcionales sino también otros objetivos como el mantenimiento, la auditoría, la flexibilidad y la interacción con otros sistemas de información.

§ Las restricciones son las limitaciones derivadas de las tecnologías disponibles para aplicar los sistemas de información. Algunas arquitecturas son más aconsejables de implementar con ciertas tecnologías mientras que otras no son adecuadas para determinadas arquitecturas. Por ejemplo, no es factible utilizar una arquitectura de programas informáticos de tres niveles para implantar sistemas en tiempo real.

§ La arquitectura de programas informáticos define, de manera abstracta, los componentes que realizan alguna tarea de cálculo, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser ejecutable en una arquitectura física, que consiste simplemente en determinar qué computadora se asignará a cada tarea.

El Diseño en la Ingeniería De Software

     El Diseño en la Ingeniería De Software    

Es el proceso de diseño para la planificación de una solución de software, este proceso es por regla general, necesaria para que los programadores puedan manejar la complejidad que la mayoría de los programas informáticos poseen y para disminuir el riesgo de desarrollos erróneos. De forma más sencilla, es definida como el proceso de definición de la arquitectura, componentes, interfaces y otras características de un sistema o componente que resulta de este proceso. También, como un proceso que transforma los requisitos del usuario de una manera conveniente, lo que ayuda al programador a en la codificación e implementación del software.

Para evaluar los requisitos del usuario, un documento SRS (Software Requirement Specification, en español “ERS” - Especificación de Requisitos de Software) se crea tanto para codificar como para implementar, hay una necesidad de especificar de un modo más detallado los requisitos en términos de Software. El resultado de este proceso puede ser usado directamente en la implementación de lenguajes de programación. Además, el diseño de Software es el primer paso en el SFDLC (Software Design Life Cycle o en español Ciclo de Vida del Diseño de Software).  Cabe agregar, que el diseño de datos es la primera de las tres actividades de diseño, los datos bien diseñados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.

Diseño de Niveles o Entornos de Software

Diseño de Niveles o Entornos de Software

El diseño de Mediante Software produce tres tipos o niveles de resultado: 

Ø Diseño arquitectónico: Define las relaciones entre los principales elementos estructurales del programa, es decir, el diseño arquitectónico, es la versión más abstracta del sistema. Identifica el software como un sistema con distintos componentes que interactúan entre ellos. En este momento es cuando los diseñadores conciben la idea de posibles soluciones de dominio.

Ø Diseño de alto nivel - El Diseño de alto nivel, rompe con el concepto de diseño arquitectónico que se refiere a “Componente de única entidad múltiple”, por lo contrario tiene un punto de vista menos abstracto de los subsistemas y módulos y representa la existente interacción entre ellos. El Diseño de alto nivel se centra en cómo el sistema junto con todos sus componentes se puede implementar en forma de módulos. Reconoce estructuras modulares de cada subsistema y su relación e interacción entre las mismas.

Ø Diseño detallado - Es más detallado en cuanto a los módulos y a su implementación,  define estructuras lógicas de cada módulo y de sus interfaces para comunicarse con los otros módulos. Además, se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software.  Igualmente, el diseño detallado describe cada componente y su comportamiento específico, de forma que puede procederse a su construcción

Conceptos Básicos del Diseño

    Conceptos Básicos del Diseño

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.

·      Abstracción Procedimental: Se refiere a una secuencia de instrucciones que tiene una función específica y limitada.

·      Abstracción de Datos: Es una colección nombrada de datos que describe un objeto de datos.

 

Cohesión

La Cohesión es una medida que define el grado de interdependencia entre los elementos que conforman los módulos. A mejor cohesión, mejor diseño de programa obtenemos. Hay siete tipos de cohesión, llamados:

§  Cohesión coincidente - Es una cohesión no planificada y aleatoria, la cual puede romper el programa en pequeños módulos por el bien de la modularización. Como que no tiene una planificación, puede confundir a los programadores. Por eso este tipo no está generalmente aceptado.

§  Cohesión lógica - La categorización de manera lógica en la que los elementos se colocan juntos en un mismo módulo, se denomina Cohesión lógica.

§  Cohesión temporal - Cuando los elementos del módulo se organizan de manera que se procesan en un momento similar en el tiempo, hablamos de Cohesión temporal.

§  Cohesión procedimental - Cuando los elementos del módulo se agrupan juntos, y se ejecutan de forma secuencial para poder llevar a cabo una tarea, hablamos de Cohesión procedimental.

§  Cohesión comunicativa - Cuando los elementos del módulo se agrupan juntos, y se ejecutan y funcionan en los mismos datos (información) de forma secuencial, hablamos de Cohesión comunicativa.

§  Cohesión secuencial - Cuando los elementos del módulo se agrupan porque el resultado de un elemento sirve de entrada a otro y así sucesivamente, hablamos de Cohesión secuencial.

§  Cohesión funcional - Se considera la mejor en cuanto a mayor grado de cohesión, y es altamente previsible. Los elementos del módulo en cohesión funcional se agrupan porque todos ellos contribuyen a conseguir una función única y bien definida. También se puede reutilizar.

 

Acoplamiento

El acoplamiento es una medida que define el nivel de interdependencia entre los módulos del programa. Nos muestra el nivel en que los módulos interfieren e interactúan entre ellos. A menor acoplamiento, mejor programa se obtiene. Hay cinco niveles de acoplamiento, llamados:

·      Acoplamiento de contenido - Cuando un módulo puede acceder, modificar o consultar directamente el contenido de otro módulo hablamos de acoplamiento del nivel de contenido.

·      Acoplamiento común- Cuando múltiples módulos han leído y escrito el acceso a algún dato global, hablamos de acoplamiento global o común.

·      Acoplamiento de Control- Dos módulos se denominan acoplados de control si uno de ellos decide la función del otro o cambia su flujo de ejecución.

·      Acoplamiento 'stamp'- Cuando múltiples módulos comparten la misma estructura de datos y funcionan en diferentes partes de la misma, hablamos de acoplamiento 'stamp'.

·      Acoplamiento de datos- Se da cuando dos módulos interactúan entre ellos con la finalidad de pasarse información (como parámetro). Si un módulo pasa una estructura de datos como parámetro, el módulo receptor debe usar todos sus componentes.

 

No hay un tipo de acoplamiento que se considere el mejor.

 

Fundamentos de Diseño

     Fundamentos de Diseño

a) Modularidad

El software se divide en componentes con nombres determinados que se denominan módulos. Además, de que un programa compuesto de un solo módulo no puede ser fácilmente manejado intelectualmente. Asimismo, se puede suponer que es más fácil resolver problemas complejos cuando se descomponen en trozos más manejables, es decir, que si dividiéramos el software indefinidamente el esfuerzo para desarrollarlo sería insignificantemente pequeño. No obstante, existen otros factores que hacen inválida esta conclusión. Por otro lado,  al modular se debe evitar tanto una excesiva modularización, como una pobre.

b) Arquitectura del Software

La arquitectura del software se refiere a:

1.- La estructura jerárquica de los componentes procedimentales.

2.- La estructura de los datos.

La arquitectura del software se obtiene mediante un proceso de partición, que relaciona los elementos de una solución de software con partes de un problema del mundo real definido en el análisis de requisitos. 

Usando alguna de las metodologías de diseño del software se producirá un determinado tipo de estructura del software.

c) Jerarquía de Control

La jerarquía de control, también denominada “estructura del programa”, representa la organización de los componentes del programa (módulos). Esto no representa aspectos procedimentales del software, tales como la secuencia de procesos, la ocurrencia u orden de las decisiones o la repetición de operaciones. Para representar la jerarquía de control lo más común es usar un diagrama en forma de árbol.

d) Estructura de Datos.

La estructura de datos es una representación de la relación lógica existente entre los elementos individuales de datos. Debido a que la estructura de la información afectará invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura del programa en la representación de la arquitectura del software, puesto que esta dicta la organización, los métodos de acceso, y las alternativas de procesamiento para la información.

e) Procedimientos del Software.

El procedimiento del software se centra sobre los detalles de procesamiento de cada módulo individual. Este debe proporcionar una especificación precisa del procesamiento, incluyendo la secuencia de procesos, las decisiones y la repetición de operaciones. Además, la representación procedimental del software se realiza por capas.

 

Importancia del Diseño

Importancia del Diseño de Software

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 pueden 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.

Trazabilidad de los Requisitos en el Diseño.

    Trazabilidad de los Requisitos en el Diseño.

La trazabilidad en la Ingeniería de Software es una práctica de control que ayuda a obtener el producto en el dominio de la solución lo más exacto y fiable posible a las necesidades expresadas por el cliente en el dominio del problema. Esta se encuentra condicionada por los cambios y las validaciones que los participantes del proyecto hagan al sistema durante el proceso de desarrollo. Según el estándar IEEE 830-1998, la trazabilidad es la habilidad para seguir la vida de un requerimiento en ambos sentidos, hacia sus orígenes o hacia su implementación a través de las especificaciones generadas durante el proceso de desarrollo de software. Cabe destacar que la trazabilidad se considera como una medida de la calidad del sistema y la madurez del proceso de desarrollo, además es una prescripción de muchas normas o estándares.

La Trazabilidad de Requerimientos se presenta como la habilidad para describir y seguir la vida de un requerimiento, de manera ideal, a través de todo el ciclo de vida del proyecto. Poder conocer desde el origen de todos y cada uno de los puntos que han aportado a la vida de un producto software, es sin duda un gran valor agregado para el mismo.  Asimismo, la trazabilidad de requerimientos es clave para conseguir una exitosa gestión de requerimientos. Para ello el proceso de trazabilidad ha de considerar dos subprocesos: a) configuración de la trazabilidad de acuerdo con las necesidades concretas del proyecto, para así conseguir un resultado positivo respecto del costo-beneficio asociado, b) especificación de la trazabilidad en el proyecto y la posterior explotación de dicha información. No existen estándares asociados al proceso de trazabilidad que ayuden a determinar qué tipos de artefactos y de enlaces se han de considerar.

Atributos de Calidad

    Atributos de Calidad

Atributos de la Funcionalidad: Habilidad del software de realizar las funciones para las que fue creado.

ü Idoneidad: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

ü Precisión: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisión. 

ü Interoperabilidad: Capacidad del producto software para interactuar con uno o más sistemas especificados.

ü Seguridad: Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados.

ü Cumplimiento de la funcionalidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad.

Atributos de la Fiabilidad: Habilidad del software para mantenerse operativo (funcionando) dentro de condiciones normales.

ü Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software.

ü Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados.

ü Capacidad de recuperación: Capacidad del producto software para restablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo.

ü Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones relacionadas con la fiabilidad.

 Atributos de la Usabilidad: Habilidad del software para que el usuario invierta el mínimo esfuerzo.

ü Inteligibilidad: Capacidad del producto software que permite al usuario entender si el software es adecuado y cómo puede ser usado para unas tareas o condiciones de uso particulares.

ü Facilidad de aprendizaje: Capacidad del producto software que permite al usuario aprender sobre su aplicación.

ü Operabilidad: Capacidad del producto software que permite al usuario operarlo y controlarlo.

ü Atractividad: Capacidad del producto software para ser atractivo al usuario. Cumplimiento de la usabilidad ∗ Capacidad del producto software para adherirse a normas, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.

Atributos de la Eficiencia: Habilidad del software para responder a una petición de usuario con la velocidad apropiada.

ü     Comportamiento en el tiempo: Capacidad del producto software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas.

ü     Utilización de recursos ∗ Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.

ü     Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la eficiencia.

Atributos de la Mantenibilidad: Habilidad del software para que el usuario invierta el mínimo esfuerzo para mantenerlo o mejorarlo.

ü Capacidad para ser analizabilidad: Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de los fallos en el software, o para identificar las partes que han de ser modificadas.

ü Cambiabilidad: Capacidad del producto software que permite que una determinada modificación sea implementada.

ü Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software.

ü Pruebabilidad: Capacidad del producto software que permite que el software modificado sea validado.

ü Cumplimiento de la mantenibilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la mantenibilidad.

Atributos de la Portabilidad: Habilidad del software para ser transferido de un ambiente a otro y funcionar en este.

ü Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado.

ü Facilidad de instalación: Capacidad del producto software para ser instalado en un entorno especificado.

ü Coexistencia: Capacidad del producto software para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes.

ü Intercambiabilidad: Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propósito, en el mismo entorno.

ü Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad.

Patrones de Diseño

     Patrones de Diseño

Un Patrón de Arquitectura de Software es un conjunto de decisiones de diseño que se pueden aplicar a un problema de diseño recurrente y que pueden parametrizarse para diferentes contextos donde ese problema de diseño aparece:

·  Estructuras

·  Capas

·  Pipes and Filters

·  Blackboard

·  Sistemas Interactivos

·  Model-View-Controller

·  Presentation-Abstraction-Communication

·  Sistemas Distribuidos

·  Broker

·  Trader

·  Sistemas Adaptables

·  Reflection

·  Microkernel

Evaluación Del Diseño

         Evaluación Del Diseño

El primer paso para la evaluación de una arquitectura es conocer qué es lo que se quiere evaluar. De esta forma, es posible establecer la base para la evaluación, puesto que la intención es saber qué se puede evaluar y qué no. Resulta interesante el estudio de la evaluación de una arquitectura: si las decisiones que se toman sobre la misma determinan los atributos de calidad del sistema, es entonces posible evaluar las decisiones de tipo arquitectónico con respecto al impacto sobre estos atributos.

La arquitectura de software posee un gran impacto sobre la calidad de un sistema, por lo que es muy importante estar en capacidad de tomar decisiones acertadas sobre ella, en diversos tipos de situaciones, entre las cuales destacan:

·  Comparación de alternativas similares.

·  Comparación de la arquitectura original y la modificada.

·  Comparación de la arquitectura de software con respecto a los requerimientos del sistema.

·  Comparación de una arquitectura de software con una propuesta teórica.

·  Valoración de una arquitectura en base a escalas específicas.