Unidades14a20 PDF

Ingeniería del Software 2 – Curso 2009-2010 29
Tema III. DISEÑO ARQUITECTÓNICO (diseño de alto nivel)
14. Presentación / La transición del análisis al diseño

Presentación de IS2
Profesorado. Web de la asignatura
Relación con otras asignaturas: IS1 + IS2
Objetivos de la asignatura
Programa de la asignatura: teoría
Programa de la asignatura: prácticas
o Reestructuración de equipos: alumnos nuevos, alumnos que no continúan, etc.
Documentación entregada
Descripción de la práctica
Formato de los documentos
o ¿Trabajo excesivo? Promedio de 58 horas/alumno dedicadas a la práctica en IS1
Programa de la asignatura: calendario
Trabajo en equipo y dedicación a la práctica
Evaluación de la asignatura
Bibliografía
La transformación de modelos: del análisis al diseño

Ambos representan lo mismo (el sistema), pero desde una perspectiva diferente.
Análisis: estudiar los requisitos sin tomar decisiones de implementación.
o Representa un vista lógica del sistema que se desea construir.
o No introduce artefactos de diseño o implementación.
o Su objetivo es especificar y clarificar los requisitos, y los conceptos utilizados en ellos.
Diseño: establecer cómo debe construirse el sistema antes de construirlo.
o Representa también el sistema que se desea construir: vista física del sistema.
o Omite más o menos detalles de implementación, mientras que el modelo de análisis
omite la implementación misma.
o La diferencia es más radical todavía con el modelo del dominio, que no representa el
sistema, sino el mundo real.
Dos niveles de abstracción en los modelos de diseño:
o Diseño de alto nivel, diseño arquitectónico, diseño preliminar, arquitectura del software:
la finalidad es plantear las grandes líneas de la solución.
o Diseño de bajo nivel, diseño detallado:
la finalidad es describir en detalle cada una de las partes de la solución.
La transición del análisis al diseño no es fácil, inmediata ni automática, ni tiene por qué serlo.
o La estructura de la solución no tiene por qué imitar la estructura del problema.
o Entran en juego los requisitos NF, que no influyeron en el modelo de análisis.
Transformación metódica pero no determinista, sino creativa.
Relación lógico-temporal entre el análisis y el diseño

El proceso de desarrollo iterativo e incremental posibilita la evolución en paralelo de los
distintos flujos de trabajo, y por tanto el trabajo en paralelo de distintos equipos de personas.
No hay precedencia temporal estricta análisis-diseño:
o Son modelos interdependientes, pueden evolucionar en paralelo.
o El análisis es anterior al diseño sólo dentro de cada “trayectoria de versión”.
Las distintas versiones de los documentos/modelos producidas en cada iteración no
necesariamente son compatibles entre sí: necesidad de organizar bien la documentación.
El documento de diseño arquitectónico en el estándar ESA
Lo que dice cada uno de los documentos:
o ESA software engineering standards (PSS-05-0).
o Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1).
o Guide to the software architectural design phase (PSS-05-04).
Nociones importantes:
o Modelo físico = modelo de componentes (descomposición en subsistemas).
o Diversas formas de reutilización: librerías, marcos, patrones…
o Criterios de calidad del diseño: número de elementos, grado de reutilización,
profundidad de las jerarquías, cohesión y acoplamiento, modularidad…
Contenido del documento.
El documento de diseño detallado en el estándar ESA

Lo que dice cada uno de los documentos:
o ESA software engineering standards (PSS-05-0).
o Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1).
o Guide to the software detailed design and production phase (PSS-05-05).
Nociones importantes:
o En diseño detallado, los elementos del diseño arquitectónico se descomponen en partes
que tienen correspondencia directa con módulos del lenguaje de programación elegido.
o “Diseño defensivo”: anticipar una lista de posibles problemas.
o Omitir los aspectos de “producción”: codificación, pruebas, integración, etc.
Contenido del documento.
15. Introducción al diseño arquitectónico

¿Qué es la arquitectura de software?
Analogía: proceso de construcción de un puente... (proceso de decisiones similar en IS).
o Análisis de requisitos decidir dónde debe comenzar y terminar el puente, y qué tipo
de cargas debe soportar.
o Diseño arquitectónico elegir entre puente colgante, puente volado, puente tensado, u
otro tipo que satisfaga los requisitos: esto son arquitecturas de puente (elegir un estilo
arquitectónico es elegir un tipo de solución).
Diseño encontrar soluciones a problemas complejos.
o Fundamentalmente mediante la descomposición de la solución, es un proceso iterativo.
o Arquitectura = tipos de elementos en la solución, tipos de relaciones entre ellos.
Interacción arquitectura-requisitos
Es probable que la descomposición del sistema en subsistemas (arquitectura) influya en la
forma de estructurar los requisitos, para lograr una más clara correspondencia entre los
requisitos y el diseño.
El análisis y el diseño se entrelazan en un proceso iterativo.
El diseño puede por tanto influir en el análisis, pero cuidando de no influir en exceso.
Madurez de la arquitectura del software

Las arquitecturas limpias y elegantes facilitan implementaciones libres de defectos y son más
fáciles de mantener, extender y reutilizar.
Aunque tenga mucho de arte, la arquitectura de software debe superar la inmadurez:
o Antes: creación de diseños ad hoc a partir de la nada, reutilización de diseños
encontrados por casualidad.
o Ahora: diseño metódico y disciplinado.
El diseño de software metódico y disciplinado consiste en descomponer la solución en
elementos y relaciones entre elementos (metódico, pero no automatizable...).
La arquitectura se refiere principalmente a la descomposición del software en módulos
relacionados entre sí (arquitectura lógica, arquitectura del software), y secundariamente a su
distribución entre las partes físicas (arquitectura física, arquitectura del hardware).
La especificación clara de arquitecturas software, importante para todas las aplicaciones, es
indispensable en el trabajo en equipo: modularización y ensamblaje.
¿Cómo lograr una descomposición modular eficaz?

Máxima cohesión, mínimo acoplamiento.
o Cohesión dentro de un módulo: grado de comunicación entre sus elementos.
o Acoplamiento entre módulos diferentes: grado de comunicación entre ellos.
Alta intra-cohesión, bajo inter-acoplamiento = minimizar dependencias.
o Estas dos características hacen la arquitectura mucho más fácil de modificar, ya que los
cambios sólo tienen efectos locales.
Por lo tanto... diseñar para el cambio, diseñar para la extensión (= mantenibilidad).
Descomposición modular recursiva

No es difícil escribir pequeños programas.
El principal problema de las aplicaciones grandes es la complejidad: no tanto el número de
líneas de código, sino sus interrelaciones (dependencias entre elementos).
La mejor arma contra la complejidad es la descomposición modular, de tal forma que cada
módulo sea como un pequeño programa, también en su grado de dificultad.
Una buena descomposición modular es de importancia crítica, y lograrla constituye un reto de
primer orden para el diseño.
La descomposición debe ser recursiva: los módulos se descomponen a su vez en submódulos.
o Cada módulo, paquete o componente debe contener un número pequeño de submódulos
(orientativo: 7±2), tanto en proyectos grandes como pequeños.
o Los proyectos grandes se distinguen porque el número de niveles de anidamiento es
mayor, no por tener más submódulos en cada módulo.
La descomposición perfecta (con pocas dependencias) es difícil, y no sólo en ingeniería del
sofware. ¿Cómo lograrla de antemano, sin conocer aún las dependencias entre componentes?
o Ejemplo: el requisito de ajustar en un espacio pequeño los componentes de un aparato
electrónico puede establecer fuertes dependencias entre ellos.
Diseño arquitectónico = primer nivel de descomposición:
o Elegir subsistemas/componentes/módulos y relaciones entre ellos.
Criterios para la selección de una arquitectura (o estilo arquitectónico)

Para un proyecto software dado puede haber varias arquitecturas apropiadas.
Se elige una teniendo en cuenta los objetivos, que deben estar priorizados, ya que unas
arquitecturas satisfacen mejor unos objetivos que otros.
Criterios clásicos:
o Extensibilidad: facilitar la adición de nuevas caracterísiticas (features).
Hace más complejo el diseño.
Aporta mayor grado de abstracción.
• Ejemplo: arquitectura que soporte no este juego de tablero particular, sino
cualquier tipo de juego de tablero.
Generalizar requiere invertir tiempo en el diseño: decidir qué tipo de extensiones
pueden surgir, etc.
La distinción de requisitos opcionales/deseables es útil aquí, ya que señala hacia
dónde apunta el desarrollo del sistema.
o Modificabilidad: facilitar el cambio de requisitos.
Es distinto del anterior, aunque requiera técnicas similares.
• Ejemplo: posibilidad de cambiar las reglas del juego.
o Simplicidad: hacer fácil de entender, hacer fácil de implementar.
Difícil de coordinar con los dos anteriores.
o Eficiencia: lograr alta velocidad o pequeño tamaño.
Otros criterios: reuso, escalabilidad, coste, requisitos no funcionales...
Los requisitos no funcionales guían la selección de la arquitectura más conveniente. Ej:
o Rendimiento Componentes de grano grueso (reducen comunicaciones).
o Mantenibilidad Componentes de grano fino (simplifican modificaciones).
o Disponibilidad Componentes redundantes (si uno falla, otro sigue funcionando).
Reutilización de diseños
La mala costumbre de “reinventar la rueda” en ingeniería del software impide su desarrollo
como disciplina de ingeniería.
Una posible razón: organización inadecuada de arquitecturas, diseños y código, que hace casi
imposible la reutilización.
Otras dificultades del diseño para el reuso:
o Es más difícil, requiere más tiempo, pero los plazos siguen siendo ajustados.
o Aumenta la complejidad, por tanto puede reducir el rendimiento.
o La clasificación y recuperación de componentes requiere búsqueda por contenido.
El uso de tecnologías de objetos y componentes facilita la reutilización: Microsoft MFC,
controles VB, objetos COM, Java Beans, etc.
Sin fiabilidad no hay reusabilidad. Un componente reutilizado debería ser tan fiable (correcto
y robusto) como la máquina sobre la que funciona. También es esencial que estén
perfectamente especificados los contratos de operación del componente reutilizado.
Elección de un componente para reutilizarlo:
o ¿Está documentado tanto como el resto de la aplicación?
o ¿Hay que adaptar el componente o la aplicación para poder usarlo? (proxy,
recubrimiento).
o ¿Ha sido probado tanto como el resto de la aplicación?
Reutilizar tanto desarrollos (marcos, componentes) como ideas (patrones).
Marcos de trabajo (frameworks)

Al inventar el modelo de clases puede ser recomendable utilizar o desarrollar una colección
de software preexistente que forma la base de una familia de aplicaciones similares: esta
colección es lo que llamamos un marco de trabajo (framework).
Un marco (análogo a librería o toolkit) es una colección de clases interrelacionadas e
incluidas en un paquete, que pueden ser usadas por varias aplicaciones diferentes. Las clases
de un marco pueden ser abstractas, es decir, pensadas para usarse sólo a través de herencia.
Ejemplo: Java Application Programming Interface (API)
o Los paquetes de la aplicación se relacionan con los paquetes marco a través de herencia
o agregación (en realidad, asociación o tipado de atributos).
o Java Abstract Windowing Toolkit: las clases propias de la aplicación heredan de clases
awt, o agregan objetos awt en forma de atributos (el paquete awt no se modifica).
Los marcos pueden ser de propósito general o específico, y ambos tipos pueden encontrarse
en una misma aplicación:
o General: sirven para un rango de aplicaciones muy variado (Java API)
o Específico: desarrollados a la vez que una aplicación determinada, sólo servirán
normalmente para aplicaciones muy semejantes.
Algunos creen que los marcos sólo deberían desarrollarse si van a ser usados por un gran
número de aplicaciones. No obstante, también hay ventajas (extensibilidad y mantenibilidad)
en desarrollar un marco específico en paralelo con una aplicación, aunque no vaya a ser
empleado en muchas otras aplicaciones.
Ejemplos de marcos específicos:
o Encounter: marco para juegos de rol en general.
o Parchís: marco para juegos de tablero y fichas.
16. Modelado arquitectónico con UML

Nociones de módulo, paquete, subsistema, componente y clase
Cuando hablamos de descomposición arquitectónica, estos cinco términos son prácticamente
sinónimos, ya que todos ellos responden a la siguiente definición:
o un X es una unidad autónoma, reemplazable y reutilizable, habitualmente ejecutable,
o que encapsula el estado y comportamiento de una parte de la implementación de un
sistema,
o que proporciona una o más interfaces a otros X’s y requiere una o más interfaces de
otros X’s,
o y que puede a su vez descomponerse en uno o más X’s.
No obstante, en determinadas metodologías, lenguajes o entornos tecnológicos, estos términos
se usan a menudo con matices que pueden distinguirlos:
o Módulo tiene un “aire” más de diseño estructurado y es menos frecuente usarlo en el
paradigma orientado a objetos.
o Paquete se usa para designar un contenedor totalmente genérico, que define un “espacio
de nombres” y es utilizado para organizar los elementos de un modelo (puede contener,
por ejemplo, requisitos, clases, actores, casos de uso, diagramas, colaboraciones, etc.).
o Subsistema se usa para designar los elementos resultantes del primer nivel de
descomposición de un sistema (“un sistema se descompone en subsistemas”).
En UML1 un subsistema es un tipo especial de paquete.
En UML2 un subsistema es un tipo especial de componente.
o Componente se usa para designar los elementos resultantes del segundo nivel de
descomposición (“un subsistema se descompone en componentes”) y hasta el penúltimo
nivel (“componente de nivel 2, componente de nivel 3, ... componente de nivel n-1”).
o Clase se usa para designar los elementos resultantes del último nivel de descomposición
(“un componente se descompone en componentes, o finalmente en clases”).
Aquí “clase” significa clase de implementación, es decir, representación simbólica
de un fragmento de código en un lenguaje de programación orientado a objetos.
No olvidar que “clase”, en general, no siempre representa un fragmento de
código: por ejemplo, clases de dominio, que representan conceptos del entorno del
sistema; o clases arquitectónicas, que aún deben ser refinadas, y tal vez
descompuestas en otras clases, para llegar a las clases de implementación.
Algunos autores (por ejemplo, UML1) reservan el término “componente” para el penúltimo
nivel de descomposición, utilizando para los demás el término “subsistema” (“un sistema se
descompone en subsistemas, que a su vez se descomponen en subsistemas o finalmente en
componentes, que a su vez se descomponen en clases”). Es obvio que aquí no hay ninguna
diferencia conceptual sino meramente terminológica.
En UML 1 hay que tener en cuenta que un componente no puede anidar otros componentes,
por lo que es necesario usar subsistemas (paquetes) hasta llegar al penúltimo nivel. Esta
restricción ha desaparecido en UML 2.
En el estándar ESA se utiliza el término “componente” en el sentido genérico explicado más
arriba: todo son componentes, desde el nivel más alto (subsistemas) hasta el más bajo (clases).
Esto hay que tenerlo en cuenta a la hora de adaptar este estándar a la terminología UML.
Noción de dependencia
La clave para lograr una descomposición modular eficaz es minimizar las dependencias.
La relación de dependencia (representada como una flecha discontinua) significa que:
o el elemento dependiente requiere la presencia del elemento independiente, y
o los cambios en el elemento independiente pueden afectar al elemento dependiente.
La dependencia puede establecerse entre cualesquiera dos elementos (componentes, clases…).
Noción de interfaz
La dependencia queda mejor definida si se establece con respecto a una interfaz.
o De esta manera se establece una dependencia parcial o restringida: la dependencia ya
no es hacia el componente/clase, sino sólo hacia la interfaz.
o Una misma interfaz puede ser realizada por varios componentes/clases.
o Un componente UML equivale aproximadamente a un paquete Java.
Dos formas alternativas de representación:
o Abreviada: icono circular.
o Completa: rectángulo «interface» con compartimentos para atributos y operaciones.
Características de una interfaz:
o No contiene la implementación de las operaciones (métodos).
o Puede contener también atributos (properties). Esto es nuevo en UML2.
o Si un componente/clase realiza una interfaz, se compromete a implementar todas las
operaciones definidos en la interfaz. Puede tener más operaciones, pero no menos.
o Dos interfaces ofrecidas por un mismo componente no son necesariamente disjuntas.
Cómo se deben nombrar las interfaces:
o Suelen nombrarse empezando por “i” (regla de estilo no obligatoria).
o El nombre de la interfaz debe escogerse para que signifique adecuadamente el “nombre
común” (en singular) de todas sus instancias indirectas. Ejemplos:
iCaminante: implementada por Hormiga, Robot…(operaciones: avanzar, girar…).
iImprimible: implementada por Texto, Imagen … (operaciones: imprimir…).
Definición de interfaz:
o De modo general (no sólo en OO/UML, también en programación estructurada) una
interfaz es un conjunto de operaciones que ofrecen un servicio coherente.
o Pero en OO/UML toda operación se invoca sobre una instancia (salvo el caso especial
de las operaciones estáticas):
Para usar las operaciones de la interfaz es necesario crear en el componente una
clase que realiza (o implementa) la interfaz, y es necesario instanciar esta clase.
Las operaciones se invocan sobre las instancias “indirectas” de la interfaz
(instancias de la clase o clases compatibles con la interfaz).
o Así pues, una interfaz define un tipo (un tipo abstracto de datos) que proporciona un
conjunto coherente de operaciones sobre las instancias compatibles con ese tipo.
o Análoga a una clase abstracta con todas sus operaciones abstractas: no puede tener
instancias directas.
Cómo usar/instanciar las interfaces de un componente:
o Problema: para crear una instancia indirecta de una interfaz necesito una operación (las
interfaces no tienen constructores), pero sólo puedo utilizar la operación si previamente
ya tengo una instancia sobre la que invocarla.
o Existen dos soluciones generales, más una intermedia:
Proporcionar una o más clases públicas compatibles, usar sus constructores.
Proporcionar una fábrica y gestor de instancias (patrón AbstractFactory).
Proporcionar la interfaz, pero no las clases concretas.
o Ejemplo: componente GestiónEmpleados:
interfaz iEmpleado, clases públicas EmpleadoFijo, EmpleadoTemporal, etc.: más
flexibilidad, menos encapsulación (las clases se puede usar en cualquier lugar).
interfaz iGestorEmpleados, clase pública GestorEmpleados, clases de paquete (no
visibles desde fuera del mismo) EmpleadoFijo, etc.: más encapsulación, menos
flexibilidad (las operaciones de GestorEmpleados no pueden recibir ni devolver
valores de tipo Empleado).
interfaz iGestorEmpleados, interfaz iEmpleado, clase pública GestorEmpleados
clases privadas EmpleadoFijo, etc.: situación intermedia (no se puede usar el
constructor directamente, pero sí el tipo abstracto iEmpleado).
Interfaces proporcionadas y requeridas

Un componente/clase puede relacionarse de dos formas distintas con una interfaz:
o El componente proporciona (realiza, implementa) la interfaz: interface realization.
o El componente requiere (usa, depende de) la interfaz: interface usage.
Es posible mostrar las interfaces requeridas sin mostrar quién las proporciona.
Diagrama de componentes (o de estructura)

Muestra principalmente componentes e interfaces, y relaciones entre ellos.
Distintas formas de expresar el cableado (wiring) de componentes:
o Dependencia y realización.
o Uso y realización (conector de ensamblaje ball and socket).
Cableado en árbol: cuando varios componentes requieren/proporcionan una misma interfaz.
o Las dos representaciones (independiente/en árbol) son totalmente equivalentes.
o Aunque en el diagrama se puede expresar que dos o más componentes proporcionan la
misma interfaz, habrá que escoger uno de ellos en el diseño final (no si requieren).
Anidamiento de componentes
Los subcomponentes/clases que constituyen un componente se muestran en su interior.
No hay límite en el número de niveles de anidamiento, ni en el cableado interno.
La correspondencia entre interfaces super/sub componente requiere:
o Definición de puertos para las interfaces externas del supercomponente.
o Conectores de delegación entre puertos e interfaces internas (dependencia).
El sentido de la dependencia de delegación siempre es:
o Desde el puerto hacia la interfaz interna proporcionada.
o Desde la interfaz interna requerida hacia el puerto.
Un puerto tiene nombre y tipo (opcionales), puede contener varias interfaces proporcionadas y
requeridas, y puede delegar hacia/desde varias interfaces internas. Pero debe mantenerse una
definición consistente de los puertos, sin mezclar interfaces que tengan poco que ver entre sí.
Un puerto UML equivale aproximadamente a una clase pública de un paquete Java (patrón
Fachada).
Diagrama de despliegue (arquitectura física del sistema)

Un nodo representa un recurso computacional en tiempo de ejecución. Pueden estar anidados.
o Los nodos se interconectan mediante rutas de comunicación, incluso con multiplicidad.
o Pueden representar tanto dispositivos hardware como entornos de ejecución software.
Un artefacto representa una pieza física de información localizada en un nodo.
o Ejemplos: hoja de estilos, script, componente ejecutable, base de datos, DLL, etc.
o La localización puede indicarse mediante anidamiento o con una dependencia deploy.
o La relación de un artefacto con componentes u otros elementos lógicos (uno o más)
puede indicarse con una dependencia manifest.
17. Herramientas de modelado UML (laboratorio)

Instalación, licencias y requisitos hardware y software
Instalación: http://www.altova.com/download/umodel/uml_tool_enterprise.html
Licencias
Requisitos hardware y software
Visión general de la herramienta

Creación de un proyecto
Modelos, vistas y diagramas
Organización en paquetes
Exportación de diagramas
Diagramas de componentes (o de estructura) y de despliegue

Componentes, Interfaces, Cableado, Anidamiento, etc.
Ejercicio práctico: representar los diagramas de la unidad anterior.
Otras herramientas alternativas

Visio: http://www.softwarestencils.com/uml/index.html
Telelogic Tau
swReuser
…
18. Vistas arquitectónicas

Por qué es necesario hablar de vistas arquitectónicas
Recapitulación (IEEE Std 1471-2000): la arquitectura del software es…
o la organización fundamental de un sistema
o encarnada en sus componentes,
o las relaciones entre ellos y con el entorno,
o y los principios que orientan su diseño y evolución.
La arquitectura de software no puede reducirse al aspecto de la descomposición del software
en módulos (de código) interrelacionados.
o Por el contrario, necesitamos distintos tipos de “planos” para representar distintos
aspectos (concerns) del sistema en desarrollo. No basta un único lenguaje descriptivo
(por ejemplo, módulos de código y relaciones entre ellos).
o La arquitectura es la parte del diseño que trata de dominar la complejidad de todos los
aspectos del sistema en desarrollo, no sólo la descomposición del código en módulos.
o La arquitectura debe tener muy en cuenta todos los requisitos no funcionales.
Las diferentes vistas de un sistema software no pueden obtenerse como proyección
(subconjunto) de una vista global. La analogía con las vistas en arquitectura civil es limitada.
o Por ejemplo, podemos considerar que en un único plano es posible representar la
estructura mecánica de un edificio, así como el saneamiento, las conducciones
eléctricas, el mobiliario, etc. De esta única representación global es fácil obtener
representaciones parciales mediante proyección: el subsistema eléctrico, etc.
o En cambio, no existe una única vista o plano de un sistema informático, del que se
puedan obtener por proyección, por ejemplo, la vista de ejecución (los procesos) y la
vista de implementación (el código).
Por lo tanto, necesitamos integrar distintas vistas para expresar la arquitectura de un sistema.
Según IEEE Std 1471-2000, cada punto de vista está dirigido a un conjunto de stakeholders,
trata aspectos bien determinados, y usa lenguajes y técnicas de modelado específicos. No
define ningún punto de vista en particular, tan solo especifica cómo hay que definirlos.
Ejemplo: el estándar ODP (Open Distributed Processing) define cinco puntos de vista para la
arquitectura: Enterprise, Information, Computational, Engineering, Technology.
El modelo de 4+1 vistas (Philippe Kruchten)

Se ha hecho clásica la representación de la arquitectura de un sistema mediante 4+1 vistas:
o Vista lógica (o conceptual)
o Vista de proceso (o de ejecución)
o Vista de desarrollo (o de implementación)
o Vista física (o de despliegue)
o Vista de casos de uso: unifica (supuestamente) las otras cuatro vistas y sus relaciones.
En cada vista podemos distinguir diferentes características:
o Aspecto del sistema tratado de modo especial en la vista (complementario a los demás).
o A quién va dirigida de modo particular esta vista (stakeholders).
o Tipos de requisitos relacionados más estrechamente con la vista.
o Notación: elementos y conectores esenciales en el lenguaje diagramático de cada vista.
No todas las vistas son igualmente necesarias e importantes en cada proyecto.
Relaciones entre las cuatro vistas:
o VLVP: identificar las clases que tendrán un hilo de control propio (clases activas).
o VLVD: descomponer en subsistemas de clases estrechamente relacionadas
(minimizar dependencias); aparecen nuevas clases de diseño que no son conceptuales.
o VP y VDVF: tener en cuenta los requisitos no funcionales de la vista física.
En proyectos grandes no debe esperarse una correspondencia 1-1 entre las distintas vistas.
19. Estilos arquitectónicos

Clasificación de arquitecturas según Shaw & Garlan
Estas arquitecturas pueden ser adecuadas para un problema dado, o al menos pueden dar ideas
para la modularización. Cada estilo promueve de distinta forma la extensibilidad,
modificabilidad, simplicidad y eficiencia.
o Ejemplo: añadir nuevos filtros o tuberías.
También se los denomina en algunos libros “patrones arquitectónicos” (pero no confundir con
los “patrones de diseño”, que son de más bajo nivel y orientados a la programación).
Arquitecturas de flujo de datos (Dataflow Architectures)

Adecuadas para aplicaciones que se entienden mejor en términos de datos que fluyen entre
unidades de procesamiento: procesamiento distribuido con serialización.
Los DFDs ilustran esta perspectiva de transformaciones funcionales.
o Cada unidad de procesamiento es diseñada con dependencias bien definidas respecto de
las otras: sus entradas/salidas de datos.
o Los datos tienen una fuente/origen y terminan en uno o varios sumideros/destinos.
o No hay correspondencia inmediata entre DFDs y modelos de clases; las unidades
funcionales podrían ser objetos, o podrían ser métodos.
o El tiempo no está representado en los DFDs – las flechas no indican secuencia temporal.
o Analogía con los “sistemas lineales” de procesamiento de la señal.
o Ejemplo: simulación de clientes y cajeros; cálculo del IRPF.
Arquitectura de “tuberías y filtros” (pipe and filter).
o Los elementos de proceso (filtros) aceptan una corriente de entrada (secuencia de datos
uniformes) en cualquier momento, y producen corrientes de salida.
o Cada filtro debe ser independiente de los otros. Ventajas: modularidad.
Arquitectura secuencial por lotes (batch sequential).
o Los filtros trabajan con lotes de datos, y la transacción típicamente implica el
procesamiento del lote completo, en contraste con el procesamiento continuo de la
arquitectura pipe and filter.
Ha sido la forma más común de expresar arquitecturas, no desaparecerá de inmediato.
Arquitecturas de componentes independientes

Consiste en componentes que operan en paralelo (en principio) y se comunican entre ellos de
tiempo en tiempo. Ejemplo: WWW, con miles de servidores y millones de navegadores.
Arquitectura cliente-servidor.
o El componente servidor sirve las necesidades del cliente, expresadas como peticiones.
o La relación c/s es muy natural en ingeniería del software con equipos de trabajo
separados: diferentes paquetes de clases encargados a personas o grupos de desarrollo
distintos, con relaciones c/s entre paquetes.
o No es necesario que los módulos software se encuentren en partes hardware distintas.
o Ventaja: bajo acoplamiento. Problema: los servicios requeridos se encuentran en
distintos estadios de desarrollo a medida que progresa el proyecto.
o Un componente actúa más eficazmente como servidor cuando su interfaz es “estrecha”,
es decir, la interfaz (básicamente, una colección de funciones) no contiene partes
innecesarias, está recogida en un único sitio, y está claramente definida.
Arquitectura de procesos paralelos (Parallel Comunicating Processors).
o Los componentes son procesos que se ejecutan en paralelo (threads en Java).
o Debe usarse si resulta más natural que el modelado sin paralelismo.
o Ejemplo: sesiones de conexión a un sistema bancario.
o Precaución: no adoptar decisiones prematuras acerca de la concurrencia de un sistema.
Arquitectura de sistema de eventos.
o En esta arquitectura la aplicación es un conjunto de componentes que esperan a que
ocurra un evento que les afecte.
o Ejemplos: procesador de textos, aplicación interactiva en general.
Arquitectura de máquina virtual

En esta arquitectura se define un lenguaje especial, con el que es posible escribir diversos
programas, que son interpretados y ejecutados en la máquina virtual.
La máquina virtual requiere la construcción de un intérprete, que interpreta expresiones
(programas completos, partes de programa, expresiones primitivas…).
Adecuada para gramáticas pequeñas y velocidad poco relevante.
Como hay que construir un intérprete del lenguaje, esta arquitectura rinde más si hay que
escribir varios “programas” o “aplicaciones”.
Ejemplos: intérprete de instrucciones de ensamblaje de ordenadores; intérprete de fórmulas
matemáticas para cálculo numérico; programador de calefacción; intérprete SQL.
Ventaja: facilidad de generar nuevas aplicaciones en el lenguaje de propósito especial.
Esta arquitectura puede ser ventajosa para el procesamiento de scripts, escritos en un lenguaje
accesible para usuarios de formación media.
Arquitecturas de repositorio
Son arquitecturas construidas principalmente en torno a los datos.
Desacoplan los componentes clientes de los que proporcionan persistencia y gestión de datos.
Ejemplos:
o Sistema de transacciones contra una base de datos.
o Entornos de desarrollo interactivos (IDEs).
o Editores de texto, aplicaciones ofimáticas.
o Repositorio (en sentido restringido): acceso uniforme a una colección de BD.
Es adecuada cuando el procesamiento es despreciable frente al formateado y almacenamiento
de los datos; extensibilidad y modificabilidad en la estructura de datos.
Peligro: que haya una gran candidad de procesamiento escondido entre los datos; complicar la
base de datos con procedimientos ad hoc almacenados que pervierten el diseño limpio de la
aplicación.
Arquitectura en capas o niveles (Layered Architectures)

Una capa arquitectónica es una colección coherente de artefactos software (componentes).
Objetivo: reducir dependencias entre artefactos situándolos en capas lógicas:
o cada capa depende del servicio prestado por la capa inferior...
o y presta un servicio a la capa superior.
La construcción de aplicaciones en capas puede simplificar (o complicar) el trabajo.
o Ventajas: simplicidad conceptual, reutilización, mantenimiento...
o Desventajas: mayor coste de desarrollo inicial.
Ejemplos:
o Arquitectura cliente-servidor (2 capas).
Problema: alto grado de interdependencia.
Solución: arquitectura en tres capas, insertar una capa intermedia que las aísle;
puede seleccionar dinámicamente un servidor entre varios, por ejemplo.
o Modelo OSI (7 capas).
o Juegos interactivos: representación gráfica, definición del juego, ejecución.
Arquitectura MVC (Model - View - Controller)
Fue un concepto introducido por los creadores del lenguaje Smalltalk en los años 80, con la
idea de agrupar las clases en función del rol que desempeñan en la aplicación.
Versión original (sistemas antiguos sin GUI propiamente dicha):
o Modelo: modelo conceptual, clases resultantes del análisis (refinadas en diseño).
o Vista: clases dedicadas a la presentación (gráfica) de la aplicación (interfaz de salida).
o Controlador: gestiona los mensajes recibidos del usuario (interfaz de entrada) y los
traduce a mensajes comprensibles por el modelo conceptual; es responsable, también,
del flujo de la aplicación y del control de la navegación entre ventanas.
Analogía: Vista: los ojos del usuario, Controlador: sus manos, Modelo: su mente.
Versión moderna (adaptada a la unificación de interfaces de entrada/salida en el GUI):
o Modelo: idem.
o Vista: engloba View original y la parte de interfaz de entrada de Controller, y se añade
la posibilidad tecnológica de generarla mediante aplicaciones de generación de GUI.
o Controlador: centrado en el control interno de la aplicación, gestiona los mensajes
recibidos de los distintos componentes del GUI, los verifica (correctos/completos), los
traduce para el modelo conceptual, y aplica las reglas de negocio que estén definidas.
Ni la versión original ni la moderna son verdaderas arquitecturas en capas, ya que las
dependencias “cruzan” la capa intermedia. Ahora bien, esto no es necesariamente un defecto.
Variantes: RUP/BCE (Boundary-Control-Entity), PAC (Presentation-Abstraction-Control),
Model-2 de Java, etc. Algunas de estas variantes son verdaderas arquitecturas en capas
(eliminan la dependencia Vista-Modelo, todo pasa a través del Controlador).
Consecuencias:
o (+) Fácil de explicar y entender.
o (+) Reduce dependencias y potencia la reutilización (cambiar interfaz sin tocar el resto).
o (+) Permite dividir el trabajo en base a distintos roles (el diseñador gráfico no tiene por
qué saber cómo se ha implementado el resto de componentes).
o (–) No es “pura”: las dependencias cruzan varias capas.
o (–) Complejidad (valorar costes).
Arquitectura en cuatro capas (Four Layer Achitecture)

La factorización propuesta por MVC facilita la reutilización (separando representación,
modelo y control), pero no cubre aspectos de bajo nivel (protocolos de red, persistencia...).
Ésta combina arquitectura en capas “pura” con MVC para aprovechar las ventajas de ambas:
o Vista: Vista del MVC.
o Modelo de Aplicación: Controlador del MVC.
o Modelo Conceptual: Modelo del MVC.
o Infraestructura: Alberga clases que abstraen mecanismos de conexión con dispositivos
o sistemas en los que se apoya la aplicación: acceso a BDs, directorios, puerto serie, etc.
Todos los mensajes que llegan al controlador lo hacen a través del interfaz, y la interfaz se
comunica con el modelo sólo a través del controlador.
Consecuencias:
o (+) Ventajas de MVC y Capas.
o (+) Permite independizar la “aplicación” de la representación y los mecanismos de
persistencia (en general, plataforma).
o (–) Más restrictivo (ej. no existe comunicación directa interfaz-modelo).
Arquitectura en Tres Escalones (Three-Tier Architecture)
Propósito: optimizar el uso de componentes y recursos en aplicaciones distribuidas mediante
la distribución de la funcionalidad del sistema.
Solución: arquitectura que divida la responsabilidad en tres escalones de procesamiento.
o Cliente: Destinado a interpretar y mostrar la información. Es el componente donde se
lleva a cabo la interacción usuario-aplicación. De este modo, deberá optimizarse para la
visualización de la interfaz de usuario y proporcionar una interfaz física de red con
capacidad suficiente (clientes ligeros: thin client).
o Servidor Departamental (o servidor de dominio): Posee mayor capacidad de
computación que los clientes, así como más memoria y disco. Estos recursos le
permiten actuar como caché de información compartida entre varios clientes,
reduciendo la necesidad de almacenamiento en los mismos, así como el tráfico hacia el
Servidor Empresarial. También mejora la seguridad.
o Servidor Empresarial (o servidor de negocio, o servidor de persistencia): Típicamente
un servidor de altas prestaciones (mainframe). Aunque no suele poseer la última
tecnología (típicamente heredados, legacy systems), poseen altas prestaciones en cuanto
a capacidad y velocidad en el proceso de transacciones.
Consecuencias:
o (+) Proporciona la mejor arquitectura para nuevos desarrollos, aprovechando los
sistemas existentes (amortización de inversiones: servidores heredados).
o (+) Permite desacoplar los clientes del servidor empresarial y reduce las necesidades de
los clientes (clientes ligeros).
o (+) Reduciendo las dependencias entre el servidor departamental y el empresarial,
permite la retirada/renovación paulatina del segundo.
o (–) Complejidad (valorar costes).
o (–) Mayor carga de administración.
Uso combinado de arquitecturas

Es normal que una misma aplicación use distintas arquitecturas (en distintos niveles de
descomposición) para resolver distintos aspectos del mismo problema.
Ejemplo: Parchís.
o Base de datos para Partidas realizadas.
o Procesos paralelos para los Jugadores (humanos, artificiales).
o Sistema de eventos para el Control General.
Las distintas arquitecturas estudiadas tienen muchos puntos en común:
o Máquina virtual  Arquitectura multicapa.
o Repositorio de datos  Cliente-servidor.
o Sistema de eventos  Procesos paralelos.
o Tuberías y filtros  Procesos paralelos, etc.
20. Qué es diseño orientado a objetos (artículo)

Lectura obligatoria y examen
Wayne Haythorn. “What is Object-Oriented Design?” Journal of Object-Oriented
Programming 7(1): 67-78 (1994).
Diseño basado en objetos vs. Diseño orientado a objetos

Diseño basado en objetos (ingenuo o inicial): identificación de tipos de cosas a partir de los
objetos del dominio
Diseño orientado a objetos (sistemático): uso de clases abstractas y polimorfismo para reducir
la complejidad del sistema (es decir, de los cambios que habría que hacer para mantener el
sistema)
¿Cómo se logra un diseño mantenible? Para encontrar las clases abstractas adecuadas:
Anticipar una lista de posibles cambios
Examinar críticamente el diseño inicial, evaluar la mantenibilidad
Encapsular posibles variaciones dentro de clases abstractas
Un buen diseño debe localizar los efectos de los posibles cambios anticipados
Encapsular decisiones de diseño difíciles o arriesgadas
Las clases abstractas nos protegen de posibles variaciones futuras
Todo lo contario de “simular entidades del mundo real”
No creamos clases abstractas porque son evidentes en el dominio, las creamos porque hay
cambios que pueden venir del dominio y queremos controlar su impacto en el sistema
Esta técnica recibe diversos nombres: análisis defensivo (Haythorn), análisis de robustez
(Jacobson), “objetificar” las variaciones (Gamma)
Ejemplos. Parchís: tablero, jugadores, turnos, reglas...
El papel del mantenimiento en la economía del software

Punto de partida: un proyecto software no termina cuando se entrega, sino cuando se retira.
El coste marginal en economía se define como “el incremento del coste total que supone la producción adicional
de una unidad de un determinado bien”. Cuando se ha realizado una gran inversión para producir determinados
bienes (un fábrica de zapatos), el coste marginal para producir una unidad más (un par de zapatos) es muy
pequeño. La diferencia entre el coste marginal y el precio obtenido por su venta es lo que amortiza la inversión
inicial, además de proporcionar los beneficios.
En la ingeniería del software no producimos artefactos materiales, como zapatos o coches. El producto
verdaderamente análogo al zapato o al coche no es una nueva instalación del sistema del sistema producido. El
coste marginal de esta nueva instalación es ridículo, comparado con la inversión necesaria para su desarrollo.
Rentabilizar la inversión inicial mediante la venta de nuevas instalaciones elevaría excesivamente el precio de
éstas, habitualmente más allá de lo que el cliente percibe como razonable. Esto es una dificultad seria en el
negocio informático.
En la ingeniería del software el coste marginal hay que buscarlo en el mantenimiento: el análogo al coche o al
zapato es la acción de mantenimiento. El cliente percibe bien el valor de las acciones de mantenimiento. Si
conseguimos que su coste sea reducido, entonces podemos transformar la venta de instalaciones en venta de
acciones de mantenimiento, y estaremos rentabilizando mucho mejor la producción de software.
Ejemplo: tenemos uno o dos proyectos en desarrollo, por los que no cobramos todo lo que nos cuesta; y muchos
más proyectos en mantenimiento, por los que cobramos más de lo que nos cuesta mantenerlos, gracias a que el
mantenimiento nos cuesta muy poco. De esta forma aplicamos al negocio del software lo que funciona en otros
ámbitos de la industria y la economía.
El negocio informático se transforma: de ofrecer bienes a ofrecer servicios. El cliente ya no se ve obligado a
realizar un gran desembolso inicial, muchas veces inseguro de si el producto que ofrecemos es lo que realmente
necesita, sino que podemos ofrecer una tarifa plana por el servicio continuado de mantenimiento. Al cliente le
puede interesar mucho más pagar por un año de servicio que pagar por el producto entregado. Así puede cambiar
más fácilmente su sistema informático, sin necesidad de amortizarlo hasta el final.
Conclusión: los diseños mantenibles tienen un impacto directo en el negocio informático.
1. ¿Qué caracteriza el diseño orientado a objetos frente al diseño basado en objetos? ¿Por qué
es insuficiente el diseño basado en objetos desde el punto de vista de la mantenibilidad?
¿Cómo ayuda la orientación a objetos a reducir la “complejidad” de un programa?
Uso de herencia y polimorfismo frente a meras clases y asociaciones. El diseño basado en

objetos es es insuficiente porque es incapaz de hacer frente a los cambios en los requisitos.
La complejidad depende de la cantidad de “lógica de ramificación condicional” que contenga
el código. En la orientación a objetos se sustituyen las ramificaciones condicionales por
invocaciones polimórficas, porque facilitan el mantenimiento del código cuando se añadan nuevos
tipos de datos/objetos.
2. Describa brevemente en qué consiste el método propuesto por Wayne Haythorn para
obtener “clases magníficas”, y qué beneficios aporta. ¿Cómo se aplica el método para evaluar
y comparar diseños?
Elaborar una lista de cambios previsibles. Diseñar clases abstractas (interfaces) que
encapsulen la variabilidad identificada y así defiendan el diseño frente a ella. Medir y comparar las
modificaciones que requeriría cada diseño para hacer frente a esos cambios.

Unidades14a20 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unidades14a20 PDF

Загружено:

Авторское право:

Доступные форматы

Ingeniería del Software 2 – Curso 2009-2010 29

Tema III. DISEÑO ARQUITECTÓNICO (diseño de alto nivel)

14. Presentación / La transición del análisis al diseño

La transformación de modelos: del análisis al diseño

Relación lógico-temporal entre el análisis y el diseño

El documento de diseño detallado en el estándar ESA

15. Introducción al diseño arquitectónico

Madurez de la arquitectura del software

¿Cómo lograr una descomposición modular eficaz?

Descomposición modular recursiva

Criterios para la selección de una arquitectura (o estilo arquitectónico)

Marcos de trabajo (frameworks)

16. Modelado arquitectónico con UML

Interfaces proporcionadas y requeridas

Diagrama de componentes (o de estructura)

Diagrama de despliegue (arquitectura física del sistema)

17. Herramientas de modelado UML (laboratorio)

Visión general de la herramienta

Diagramas de componentes (o de estructura) y de despliegue

Otras herramientas alternativas

18. Vistas arquitectónicas

El modelo de 4+1 vistas (Philippe Kruchten)

19. Estilos arquitectónicos

Arquitecturas de flujo de datos (Dataflow Architectures)

Arquitecturas de componentes independientes

Arquitectura de máquina virtual

Arquitectura en capas o niveles (Layered Architectures)

Arquitectura en cuatro capas (Four Layer Achitecture)

Uso combinado de arquitecturas

20. Qué es diseño orientado a objetos (artículo)

Diseño basado en objetos vs. Diseño orientado a objetos

El papel del mantenimiento en la economía del software

Uso de herencia y polimorfismo frente a meras clases y asociaciones. El diseño basado en

Вам также может понравиться