Diseño de Software

Por Alicia Durango

Antes de comenzar el estudio y la práctica en la disciplina de la Arquitectura de Software, es apropiado que sepamos donde encaja a lo largo del Cuerpo de Conocimiento en Ingeniería de Software (Software Engineering Body of Knowledge). El diseño arquitectural, o proyecto de la arquitectura, es la primera de las dos actividades que componen el área de conocimiento de Diseño de Software (Software Design Knowledge Area). La actividad siguiente es el diseño detallado. Por ser una actividad de Diseño, el diseño arquitectural se hace con una mezcla de conocimiento y creatividad. Como la creatividad es algo que se obtiene a través de la experiencia, no es nuestro objetivo enseñarla. Sin embargo, buscamos a lo largo de ese libro transmitir el conocimiento necesario para la creación de arquitecturas de sistemas de software.

Ciertamente, una base conceptual en Diseño de Software es necesaria para una mejor comprensión de ese libro. De esa manera, este capítulo busca fundamentar el conocimiento del lector en esa área, de forma que su importancia y sus beneficios proporcionados sean reconocidos.

• Idioma: Español
• Editorial: IT Campus Academy
• Fecha de lanzamiento: 1 dic 2015
• ISBN: 9781519620736

Alicia Durango

Con experiencia en el mundo de formación desde el año 2010, Alicia empieza a escribir libros y a crear cursos online de informática para sus alumnos. Con una amplia experiencia laboral, Alicia Durango es una profesional con formación en Desarrollo de Aplicaciones Informáticas y Administración de Sistemas Informáticos, con más de 8 años de experiencia en el mundo de la informática, con amplia experiencia en los sectores de formación, publicidad y desarrollo web, llevando a cabo tareas de gestión, diseño gráfico, programación web y Directora de publicidad.

Vista previa del libro

Diseño de Software

2ª Edición

ALICIA DURANGO

Copyright © 2015 Alicia Durango

IT Campus Academy

ISBN-13: 978-1519620736

––––––––

Tabla de contenido

Nota del Autor

INTRODUCCIÓN AL DISEÑO DE SOFTWARE

DISEÑO DE SOFTWARE

QUE ES EL DISEÑO DE SOFTWARE

CARACTERÍSTICAS DEL DISEÑO DE SOFTWARE

ELEMENTOS DEL PROCESO DE DISEÑO DE SOFTWARE

OBJETIVOS

RESTRICCIONES

ALTERNATIVAS

REPRESENTACIONES

SOLUCIONES

NIVELES DE DISEÑO DE SOFTWARE

PRINCIPIOS Y TÉCNICAS DE DISEÑO DE SOFTWARE

DIVISIÓN Y CONQUISTA

ABSTRACCIÓN

ENCAPSULAMIENTO

MODULARIZACIÓN

SEPARACIÓN DE PREOCUPACIONES

ACOPLAMIENTO Y COHESIÓN

SEPARACIÓN DE DECISIONES DE EJECUCIÓN DE ALGORITMOS

SEPARACIÓN DE INTERFACES DE SUS IMPLEMENTACIONES

RESUMEN

TEORÍA EN DISEÑO DE SOFTWARE

PROCESO DE DISEÑO

TÉCNICAS Y HERRAMIENTAS

FUNDAMENTOS DE LA ARQUITECTURA DE SOFTWARE

MOTIVACIÓN PARA DESARROLLAR MEJORES SISTEMAS

LA ARQUITECTURA DE SOFTWARE

LA DEFINICIÓN DE ARQUITECTURA DE SOFTWARE DE PERRY Y WOLF

ARQUITECTURA DE SOFTWARE POR GARLAN Y SHAW

ARQUITECTURA DE SOFTWARE POR BASS ET AL

LA ARQUITECTURA DE SOFTWARE POR EL ESTÁNDAR ISO/IEEE 1471-2000

DESCOMPONIENDO LA DEFINICIÓN DE ARQUITECTURA DE SOFTWARE

ELEMENTOS ARQUITECTURALES

ELEMENTOS ARQUITECTURALES Y ATRIBUTOS DEL SISTEMA

DECISIONES ARQUITECTURALES

DEFINICIÓN DE DECISIÓN ARQUITECTURAL

Características

Rastreabilidad

Evolución

Reglas para adición de funcionalidad al sistema.

Reglas de atención a atributos de calidad.

ATRIBUTOS DE CALIDAD

Midiendo atributos de calidad

Relacionando atributos de calidad

VISIONES DE LA ARQUITECTURA

EL DOCUMENTO DE ARQUITECTURA

BENEFICIOS

DIFICULTADES

¿POR QUÉ DOCUMENTAR LA ARQUITECTURA DE SOFTWARE?

RESUMEN

EVOLUCIÓN DEL SOFTWARE

ELEMENTOS DE UNA ARQUITECTURA

STAKEHOLDERS

¿QUIENES SON LOS INTERESADOS EN UN SISTEMA DE SOFTWARE?

IMPORTANCIA DE LOS INTERESADOS

TIPOS DE STAKEHOLDERS Y SU RELACIÓN CON LOS ATRIBUTOS DE CALIDAD

ATENCIÓN A LOS REQUISITOS COMO MEDIDA DE ÉXITO

CONFLICTOS ENTRE REQUISITOS Y ATRIBUTOS DE CALIDAD

RESPONSABILIDADES DE LOS STAKEHOLDERS

RESUMEN

ATRIBUTOS DE CALIDAD

REQUISITOS FUNCIONALES Y NO-FUNCIONALES

DIFERENCIAS ENTRE REQUISITOS FUNCIONALES Y NO-FUNCIONALES

CONFLICTOS ENTRE REQUISITOS

EXPRESANDO REQUISITOS NO-FUNCIONALES

ATRIBUTOS DE CALIDAD

LÍMITES A LAS FUNCIONALIDADES

RELACIONES ENTRE ATRIBUTOS DE CALIDAD

A QUIEN INTERESA LOS ATRIBUTOS DE CALIDAD

MODELO DE CALIDAD

ESTÁNDAR ISO/IEC 9126-1:2001

Funcionalidad

Confiabilidad

Usabilidad

Eficiencia

Sostenibilidad

Portabilidad

CONFLICTOS ENTRE ATRIBUTOS DE CALIDAD

ATRIBUTOS DE NEGOCIO

MERCADO-BLANCO

TIME-TO-MARKET

COSTE Y BENEFICIO

VIDA ÚTIL

AGENDA DE LANZAMIENTO

DISEÑO ARQUITECTURAL PARA CALIDAD DE SOFTWARE

REFERENCIAS

REQUISITOS FUNCIONALES Y NO-FUNCIONALES

DIFERENCIAS ENTRE REQUISITOS FUNCIONALES Y NO-FUNCIONALES

ATRIBUTOS DE CALIDAD

ATRIBUTOS DE NEGOCIO

TÉCNICAS DE DISEÑO ARQUITECTURAL

PRINCIPIOS Y TÉCNICAS DE DISEÑO ARQUITECTURAL

ABSTRACCIÓN

SEPARACIÓN DE PREOCUPACIONES

ESTÁNDARES Y ESTILOS ARQUITECTURALES

Facilitan la comunicación. Los patrones arquitecturales

TÁCTICAS DE DISEÑO

RENDIMIENTO Y ESCALABILIDAD

No mantenga estado

Partición de datos

Caching

Tácticas de procesamiento

Menos capas de abstracción

Desventajas de las tácticas de rendimiento y escalabilidad

SEGURIDAD

Principio del más pequeño privilegio

Principio del fallo con seguridad

Principio de la defensa en profundidad

Desventajas de las tácticas de seguridad

TOLERANCIA A FALLOS

Evitar un punto único de fallos

Partición de datos

Partición y distribución de procesamiento

Redundancia

Desventajas de las tácticas de tolerancia a fallos

COMPRENSIBILIDAD Y MODIFICABILIDAD

OPERABILIDAD

Monitorización y análisis del estado del sistema

Computación autonómica

Desventajas de las técnicas de operabilidad

RESUMEN

REFERENCIAS

ABSTRACCIÓN Y SEPARACIÓN DE PREOCUPACIONES

ESTÁNDARES Y ESTILOS ARQUITECTURALES

TÉCNICAS ARQUITECTURALES

DOCUMENTACIÓN DE LA ARQUITECTURA

REFERENCIA BIBLIOGRÁFICA

Editorial.........................................................................................177

Acerca del Autor..............................................................................179

Nota del Autor

Esta publicación está destinada a proporcionar el material útil e informativo. Esta publicación no tiene la intención de conseguir que usted sea un maestro de las bases de datos, sino que consiga obtener un amplio conocimiento general de las bases de datos para que cuando tenga que tratar con estas, usted ya pueda conocer los conceptos y el funcionamiento de las mismas. No me hago responsable de los daños que puedan ocasionar el mal uso del código fuente y de la información que se muestra en este libro, siendo el único objetivo de este, la información y el estudio de las bases de datos en el ámbito informático. Antes de realizar ninguna prueba en un entorno real o de producción, realice las pertinentes pruebas en un entorno Beta o de prueba.

El autor y editor niegan específicamente toda responsabilidad por cualquier responsabilidad, pérdida, o riesgo, personal o de otra manera, en que se incurre como consecuencia, directa o indirectamente, del uso o aplicación de cualesquiera contenidos de este libro.

Todas y todos los nombres de productos mencionados en este libro son marcas comerciales de sus respectivos propietarios. Ninguno de estos propietarios ha patrocinado el presente libro.

Procure leer siempre toda la documentación proporcionada por los fabricantes de software usar sus propios códigos fuente. El autor y el editor no se hacen responsables de las reclamaciones realizadas por los fabricantes.

Este libro se lo dedico a mi familia y a mis compañeros por ayudarme y ser el empujón que me hace en esos días en los que uno piensa que ya no puedes más.

INTRODUCCIÓN AL DISEÑO DE SOFTWARE

Antes de comenzar el estudio y la práctica en la disciplina de la Arquitectura de Software, es apropiado que sepamos donde encaja a lo largo del Cuerpo de Conocimiento en Ingeniería de Software (Software Engineering Body of Knowledge). El diseño arquitectural, o proyecto de la arquitectura, es la primera de las dos actividades que componen el área de conocimiento de Diseño de Software (Software Design Knowledge Area). La actividad siguiente es el diseño detallado. Por ser una actividad de Diseño, el diseño arquitectural se hace con una mezcla de conocimiento y creatividad. Como la creatividad es algo que se obtiene a través de la experiencia, no es nuestro objetivo enseñarla. Sin embargo, buscamos a lo largo de ese libro transmitir el conocimiento necesario para la creación de arquitecturas de sistemas de software.

Ciertamente, una base conceptual en Diseño de Software es necesaria para una mejor comprensión de ese libro. De esa manera, este capítulo busca fundamentar el conocimiento del lector en esa área, de forma que su importancia y sus beneficios proporcionados sean reconocidos. En otras palabras, ese capítulo hará que el lector sea capaz de:

Reconocer  los  conceptos  básicos  de  diseño  de  software

Describir problemas  de diseño a través de sus elementos fundamentales

Identificar principios de  diseño de  software y explicar  sus beneficios

Diferenciar diseño de bajo-nivel (detallado) de diseño de alto- nivel (arquitectural) y saber cuándo aplicar cada uno.

DISEÑO DE SOFTWARE

La relevancia de proyectarse – o hacer diseño de software – puede ser explicada por la complejidad creciente de los sistemas de software. Debido a esa complejidad, el riesgo de construirse un sistema que no alcance sus objetivos es eminente.

Para evitar tal riesgo, la práctica común de cualquier ingeniería para construir un artefacto complejo, un sistema de software complejo en nuestro caso, es construirlo de acuerdo con un plan. En otras palabras, proyectar el sistema antes de construirlo. El resultado de esa actividad, también conocida como actividad de diseño, es también llamado diseño. El diseño facilita dos actividades que son esenciales en el ciclo de vida de un sistema de software. Primero, él posibilita la evaluación del sistema contra sus objetivos antes aún de ser construido. De esa manera, aumenta la confianza de que el sistema construido, de acuerdo con el diseño, alcanzará sus objetivos. Obviamente, una vez que en ese punto está sólo el modelo del sistema – el diseño –, la evaluación no será completa, pero eso tampoco quiere decir  que ella no ofrezca resultados importantes que lleven al éxito del sistema. De esta forma, otra actividad beneficiada por el diseño es la propia construcción del sistema, dado que también sirve como guía para la implementación del software.

A continuación, mostramos un ejemplo de como el diseño permite la evaluación del software. Se muestra parte de la primera  versión  del  diseño  de  un  sistema  distribuido  de almacenamiento, el HBase y, a través de una breve evaluación de ese diseño, observamos una grave limitación del software.

EJEMPLO:  El  HBase  es  un  sistema  de  almacenamiento distribuido. Eso quiere decir que los datos sometidos a él no serán guardados en un único servidor, sino en varios. De forma simplificada, el diseño del HBase define dos tipos de entidades en el sistema: el data nodo, que es el subsistema que almacena los datos, y el master nodo, que es el subsistema que sabe en que  data  nodos  los  datos  fueron  escritos  y  pueden  ser recuperados. En la primera versión del HBase, sólo existía un master nodo que coordinaba todos los data nodos. Así, para recuperar o escribir datos en el HBase, un cliente realizaba los siguientes  pasos:  primero,  el  cliente  se  comunicaba  con  el master nodo a fin de conseguir, de acuerdo con una clave, la dirección del data nodo en que él puede realizar la operación deseada (lectura o escritura). Enseguida, el master nodo, que coordina donde los datos deben quedar, devuelve la dirección del data nodo que debería poseer los datos para la referida clave.  A  partir  de  ahí,  el  cliente,  ya  con  la  dirección,  se comunicaba  directamente  con  el  data  nodo  y  realizaba  la operación deseada (escritura o lectura).

Si evaluáramos este diseño, podemos percibir dos características del HBase. La primera, es que no adopta el uso de un cliente flaco (thin client). Con eso, la implementación y configuración del cliente se hace más compleja, una vez que el cliente necesita conocer el protocolo de escritura y lectura del HBase, además de necesitar acceder tanto al master nodo como a los data nodos. Esto dificulta el desarrollo, la operabilidad y la eventual evolución del software, una vez que los cambios en el protocolo afectan a clientes y a servidores. Además de eso, por poseer sólo un master nodo, la funcionalidad del HBase queda condicionada a su disponibilidad. Finalmente, si el master nodo no es accesible, ningún cliente podrá leer o escribir en el sistema, lo que lo hace un punto único de fallos.

––––––––

QUE ES EL DISEÑO DE SOFTWARE

Para definir el diseño de software, algunos autores lo hacen en dos sentidos distintos: cuando el diseño de software es usado como producto y cuando es usado como proceso. Cuando es usado en el primer sentido, el término diseño de software indica el producto que emerge del acto (o proceso) de proyectar un sistema de software y siendo así algún documento u otro tipo de representación del deseo del director de proyecto (o diseñador). Ese producto es el resultado de las decisiones del diseñador para formar una abstracción del sistema que es deseado en el mundo real. Existen diversas formas de representar esa abstracción del sistema. Podemos citar, por ejemplo, dibujos usando cajas y flechas, textos descriptivos, o incluso el uso de lenguajes o herramientas creadas para este propósito, como lenguajes de modelado de software, redes, pseudocódigo, etc.

Por otro lado, cuando el término es usado en el segundo sentido, hacer diseño indica el proceso seguido para obtenerse un proyecto. Ese es un proceso que forma parte del proceso de las diversas partes interesadas en el desarrollo y que es orientado a los objetivos del software. Él debe ser realizado teniendo en mente el sistema y debe ser fundamentado en el conocimiento del diseñador sobre el dominio del problema.

A partir de la visión de diseño como artefacto, podemos observar que él debe describir diversos aspectos del software para que, así, posibilite su construcción. Entre estos aspectos, están:

la estructura estática del sistema, incluyendo la jerarquía de sus módulos;

la descripción de los datos a ser usados;

los algoritmos a ser usados;

el empaquetamiento del sistema, en términos de como los módulos están agrupados en