Diseño y Arquitectura de

Software

Unidad 2
Tema: Diseño de la arquitectura de
software
¿Qué es el diseño de
la arquitectura del
software?
Análisis
Entrada
Conocimiento del dominio de la aplicación,
actividades de los usuarios, mercado, etc.
Actividades
Identificar las necesidades del usuario
Análisis de viabilidad
Determinar los requisitos de la aplicación
Salida
Documento de requisitos del software
Diseño
Entrada
Documento de requisitos del software
Actividades
Establecer una(s) estrategia(s) de
solución
Análisis de alternativas. Formalizar la
solución
Descomponer y organizar la aplicación
Fijar descripciones de cada módulo
Salida
Documento de diseño del software
Diseño de Software
Un diseño de software es un modelo de un
sistema del mundo real que tiene muchas
entidades participantes y relaciones entre ellas.
Debe ser posible visualizarlo a diferentes niveles
de abstracción.
Traduce los requisitos del software a un conjunto
de representaciones (gráficas, tabulares, basadas
en lenguajes) que describen la estructura de
datos, la arquitectura, el procedimiento algorítmico
y las características de la interfaz.
El diseño del SW
El diseño debe actuar como base para la implementación.
Es un medio de comunicación entre los diseñadores de
subsistemas
Provee información para el mantenimiento, a cerca de la
intención original.
El proceso de diseño
involucra:
Describir el sistema como un número de
diferentes niveles de abstracción.
El diseño es descompuesto y se va refinando,
errores y omisiones en etapas tempranas son
descubiertos.
Las etapas que se muestran a continuación son
arbitrarias pero muestran el proceso y permiten
la administración del proceso:

Diseño
Diseño
Diseño mas
Diseño terminado
informal formal
Informal
mejorado
Capas del diseño
El diseño se enfoca sobre cuatro atributos distintos del
programa:
La estructura de los datos
La arquitectura del software
El detalle procedimental y
La caracterización de la interfaz.
Principios del diseño
El proceso de diseño no debe sugerir de "visión de túnel"
El diseño debe ser rastreable hacia el modelo de análisis
El diseño no debe "reinventar la rueda"
El diseño debe "minimizar la distancia intelectual" entre el
software y el problema como en el mundo real.
El diseño debe exhibir uniformidad e integración.
El diseño debe estructurarse para soportar el cambio.
El diseño debe ser estructurado para acoplarse, aún cuando datos
aberrantes, eventos o condiciones de operación se presenten.
El diseño no es codificación, codificar no es diseñar.
El diseño debe establecerse para calidad como será creado, no
después de contruir el software.
El diseño debe ser revisado para minimizar errores conceptuales
(semántica).
Metodología de diseño
Evaluar y comprender la especificación
Idear una estrategia de solución, informal
Formalizar la estrategia
Validar el modelo: escenarios, etc.
¿Hay elementos complejos? → Iterar
Diseño detallado
Metodología de diseño
Formalizar la estrategia
Identificación de entidades (clases,
métodos, ...)
Agrupar métodos en clases
Identificar y asignar responsabilidades
Identificar relaciones entre clases
Refinar las clases
Diseño detallado
Definir atributos, argumentos de las
operaciones, ...
Codificar interfaces (código Ada, C++,
Java, ...)
Reutilización
Componentes
Librerías, genéricos, etc.
Esquemas de arquitectura (Frameworks)
Módulos fijos, ya definidos
Módulos específicos, a crear en cada caso
Patrones de diseño
Esquemas conocidos (no reinventar la
rueda)
E.Gamma, R.Helm, R.Johnson, J.Vlissides:
Design Patterns: ... - (“la banda de los
cuatro”)
 Diseño en capas
• Aspectos transversales
– Seguridad
– Comunicaciones
– Administración y operaciones
Puntos clave del Diseño
Un diseño es un proceso creativo, aunque los métodos y
líneas guía son útiles, el juicio y pericia del ingeniero de
software son requeridas para diseñar el sistema de
software.
Las principales actividades de diseño en el proceso de
software es:
El diseño arquitectónico,
La especificación del sistema,
El diseño de la interfaz, la estructura de datos
y el diseño de algoritmos.
La descomposición funcional involucra considerar un
sistema como un conjunto de unidades funcionales que
interactúan entre sí.
Puntos clave del Diseño
Una decisión sobre si un sistema debe ser implementado
como una simple secuencia de procesos o como un
número de procesos en paralelo es una decisión del
diseño detallado.
El diseño debe partir el sistema en unidades
(componentes) lógicas que interactúan entre sí, puede ser
realizado secuencialmente o en paralelo.
La cualidad más importante de los atributos de diseño es el
mantenimiento. Maximizar la cohesión en un componente y
minimizar el acoplamiento entre componentes es deseable
para tener un diseño mantenible.
El uso de herencia en los sistemas OO puede mejorar la
calidad de un diseño pero puede hacer del diseño más
difícil de entender.
Diseño de la Interfaz de
usuario
1. La interfaz debe usar términos y conceptos
que son familiares para una clase de usuario .
2. La interfaz debe ser apropiadamente
consistente.
3. El usuario no debe ser sorprendido por el
sistema.
4. La interfaz debe incluir algún mecanismo que
permita al usuario recuperarse de sus errores.
5. La interfaz debe incorporar alguna forma de
guía para el usuario
Diseño de la ayuda de
usuario
La interfaz de usuario debe siempre proveer alguna forma
de ayuda en línea. El diseño de la ayuda es una faceta de
la interfaz de usuario que cubre las siguientes áreas:
La documentación provista con el sistema
La ayuda en línea del sistema
Los mensajes producidos por el sistema en respuesta a las
acciones del usuario.
Diseño de mensajes
Cuando se diseñan mensajes de cualquier tipo, los
siguientes principios deben ser tomados en cuenta:
Los mensajes debe están el contexto del usuario.
Los mensajes deben tomar en cuenta el nivel de
experiencia del usuario. Como los usuarios se
familiarizan con el sistema se irritan con
mensajes largos. Sin embargo los que no tienen
experiencia encuentran dificultad entender un
mensaje corto.
Los mensajes deben tomar en cuenta las habilidades
de los usuarios. No es lo mismo que la
experiencia, por ejemplo un staff de secretarias y
de programadores pueden usar el mismo sistema
integrado.
Diferente terminología puede ser apropiado cuando
se generan mensajes.
Los mensajes deben ser positivos y no negativos.
Se debe usar el modo activo y no el pasivo, nunca
se debe insultar o tratar de ser gracioso.
Diseño de la Ayuda del
sistema
La información de ayuda se prepara al mismo tiempo del
manual de usuario del sistema.
No simplemente se reduce a una pantalla con el listado del
manual del papel, las razones para esto son:
La gente no es tan buena leyendo pantallas como
lo son leyendo texto en papel.
Mantenimiento
El mantenimiento es un proceso iterativo:
Nuevos requerimientos deben formalizarse y
validar
Componentes del sistema son rediseñados e
implementados
Todos el sistema debe ser testeado
Los sucesivos cambios, originan que la estructura original
se corrompa: los programas se hacen menos entendibles y
por lo tanto más difíciles de cambiar.
Mantenimiento

Lientz & Swason: encontraron la siguiente

relación de los diferentes tipos de mantenimiento.

Adaptativo
18%

Correctivo
17% Perfectivo
65%
Tipos de mantenimiento
Corrección
Aunque se hayan tomado las mejores medidas y
actividades de garantía de calidad, es muy probable
que el cliente descubra defectos en el software. El
mantenimiento correctivo cambia el software para
corregir los errores
Adaptación
Con el paso del tiempo es probable que cambie el
entorno original (Sistema Operativo, periféricos,
UCP) para el que se desarrollo el software. El
mantenimiento adaptativo consiste en modificar el
software para acomodarlo a los cambios de su
entorno externo.
Perfectivo
Conforme utilice el software el cliente/usuario
puede descubrir funciones adicionales que podrían
ser incorporadas al software. El mantenimiento
perfectivo amplía el software más allá de sus
requisitos funcionales originales.
Fase de mantenimiento
El Software es como un iceberg: fuera de lo que se ve gran
masa de problemas existe bajo la superficie.
El cambio es algo inevitable => se deben desarrollar
mecanismos para evaluar, controlar y realizar
modificaciones.
La fase de mantenimiento se centra en el cambio que va
asociado a la corrección de errores, a las adaptaciones
requeridas por la evolución del entorno del software y a las
modificaciones debidas a los cambios de los requisitos del
cliente dirigidos a reforzar o ampliar el sistema. La fase de
mantenimiento vuelve a aplicar los pasos de las fases de
definición y de desarrollo pero en el contexto del software
ya existente.
Modelo del proceso de
mantenimiento

Req. Cambios Análisis Planeamiento Implementación del Entrega

Impacto de entrega cambio del sistema

Correción Adaptación Mejora

Costos de Mantenimiento
Existe evidencia que el costo de mantenimiento es
el más grande costo en el proceso de desarrollo
de sistemas y son subestimados cuando el
sistema es construido (análisis, diseño,
implementación).
Costos varían de un dominio a otro en promedio
son 2 a 4 veces costo de desarrollo
Por lo que resulta efectivo en pos de reducir
costos invertir tiempo y esfuerzo en el diseño y
codificación para reducir costos de mantenimiento.
Reingeniería de Software

Una de las razones del alto costo de mantenimiento es

porque la estructura de los sistemas ha de ser modificada:
Puede no existir
No es obvia para el lector
Continuos mantenimientos puede haber corroído la
estructura original y no es discernible.
Reingeniería de
Software
La REESTRUCTURACIÓN (parcial/completa) Vs.
RESCRIBIR TODO EL PROGRAMA.
Esta actividad involucra examinar partes del programa y su
reescritura para MEJORAR su ESTRUCTURA.
Por lo que la reingeniería es útil si los cambios
son solo de una parte del sistema (y ninguna otra
parte necesita ser cambiada o revalidada).
Quitar código extraño.
Identificar abstracciones de datos
Asignar nombres significativos
Simplificar condiciones
Quitar goto
Reformatear programa
FUENTES DE INFORMACIÓN

Bibliografía Base:
• CERVANTES MACEDA, HUMBERTO (2016)
Arquitectura de software, Addison Wesley Longman.
Pearson
• PANTALEO, GUILLERMO (2015) Ingeniería de software,
Cengage Learning

Bibliografía Complementaria:
• PRESSMAN, ROGER S. Ingeniería del software
• MARTIN, ROBERT C. Clean Architecture
• LEN SILVERSTON, PAUL AGNEW The Data Model
Resource Book