Segunda Clase Diseño de Sistemas y Software

tema 4 diseo del software
enrique barreiro departamento de informtica universidade de vigo escuela superior de ingeniera informtica ingeniera del software de gestin
introduccin y objetivos del diseo

diseo de sistemas: transformacin del modelo de anlisis en un modelo de diseo del sistema
se definen los objetivos de diseo del proyecto se descompone el sistema en subsistemas ms pequeos que pueden ser realizados por diferentes equipos se seleccionan estrategias para la construccin del sistema
Modelo de casos de uso :Modelo Anlisis Modelo de anlisis :Modelo Diseo Modelo de diseo :Modelo
Ingeniera de requerimientos
plataforma de hardware y software en la que se ejecutar el sistema estrategia de almacenamiento de datos persistentes arquitectura estructural del sistema flujo de control global poltica de control de acceso condiciones de interfaz ...
resultado del diseo: modelo de diseo
descripcin clara de las estrategias descomposicin en subsistemas diagramas que muestran la correspondencia entre hardware y software modelo de objetos que describe la realizacin fsica de los casos de uso muestra el impacto en el sistema de requisitos funcionales, no funcionales y restricciones sirve de abstraccin de la implementacin del sistema, convirtindose en el input fundamental de las actividades de implementacin
enrique barreiro alonso universidade de vigo - departamento de informtica
escuela superior de ingeniera informtica ingeniera del software de gestin
2 / 125
evolucin del diseo de software

proceso continuo durante tres dcadas

criterios de desarrollo de programas modulares refinamiento de arquitectura software top-down programacin estructurada diseo estructurado diseo orientado a objetos
3 / 125
calidad y diseo del software

El principio de la sabidura de un ingeniero del software El principio de la sabidura de un ingeniero del software es reconocer la diferencia entre conseguir que funcione es reconocer la diferencia entre conseguir que funcione un programa, y hacerlo bien. un programa, y hacerlo bien. M.A. Jackson, 1975 M.A. Jackson, 1975
concepto clave: CALIDAD un diseo de calidad:

proporciona representaciones del software en las que se puede evaluar la calidad permite una traduccin correcta de los requisitos en un programa sirve como fundamento para las actividades posteriores (implementacin, prueba y mantenimiento)
4 / 125
calidad y diseo del software

Sin diseo de calidad:

Dificultades de gestin (el destino csmico de los proyectos) Sistemas poco satisfactorios e improductivos
45% del tiempo en pruebas y correccin Myers: se intenta resolver el problema apurando en el proceso de diseo para dejar tiempo suficiente al final del proyecto para corregir los errores cometidos por apurar en el proceso de diseo.
Sistemas poco fiables: pruebas poco fiables (parece que funciona) y sistemas que escapan al control de sus creadores. Sistemas ineficientes: un buen diseo garantiza que se mantendr el rendimiento a pesar de las modificaciones que se realicen. Sistemas poco flexibles y difciles de mantener: 70% del coste en mantenimiento El mantenimiento es caro:
Los tres primeros casos se Los tres primeros casos se agravan con un mal diseo agravan con un mal diseo
1) 2) 3) 4) 5) 6)
Entender cmo funciona el sistema (o por qu no funciona) Disear la modificacin Verificar el impacto Realizar la modificacin Probar el sistema modificado Planificar, organizar, coordinar, medir y documentar estas actividades
5 / 125
conceptos esenciales del diseo

principios bsicos para el proceso de diseo (Davis, 1995)

1. Usar enfoques alternativos 2. Rastrear los requisitos en el diseo 3. Reutilizar si es posible 4. Representar la estructura del dominio del problema 5. Presentacin uniforme e integrada 6. Estructurado para permitir cambios 7. Estructurado para degradarse poco a poco ante errores o circunstancias inusuales 8. Evaluacin de la calidad del diseo mientras se realiza
6 / 125

REFINAMIENTO REFINAMIENTO ABSTRACCIN ABSTRACCIN -- Procedimental Procedimental -- De datos De datos -- De control De control Conceptos complementarios La arquitectura de un programa se La arquitectura de un programa se desarrolla refinando sucesivamente desarrolla refinando sucesivamente niveles de detalle procedimental. niveles de detalle procedimental. Se desarrolla una jerarqua Se desarrolla una jerarqua descomponiendo una abstraccin descomponiendo una abstraccin procedimental para, paso a paso, procedimental para, paso a paso, llegar a los enunciados del llegar a los enunciados del lenguaje de programacin lenguaje de programacin
La abstraccin permite especificar La abstraccin permite especificar procedimientos y datos suprimiendo detalles de procedimientos y datos suprimiendo detalles de bajo nivel. bajo nivel. El refinamiento ayuda a revelar detalles de bajo El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseo. nivel a medida que progresa el diseo.
niveles de abstraccin
- Requisitos familiares en el mbito del problema - Diseo arquitectnico - Diseo procedimental - Cdigo
7 / 125

MODULARIDAD MODULARIDAD
-- Componentes identificables y tratables Componentes identificables y tratables por separado por separado -- Permite a un programa ser manejable Permite a un programa ser manejable intelectualmente intelectualmente -- Criterios que permiten evaluar un Criterios que permiten evaluar un mtodo de diseo con respecto a su mtodo de diseo con respecto a su capacidad de definir un sistema modular capacidad de definir un sistema modular eficaz: eficaz: Capacidad de descomposicin Capacidad de descomposicin modular modular Capacidad de empleo de Capacidad de empleo de componentes modulares componentes modulares (reutilizacin) (reutilizacin) Capacidad de comprensin Capacidad de comprensin modular (entender un mdulo sin modular (entender un mdulo sin referencias a otros, o con las menos referencias a otros, o con las menos posibles) posibles) Continuidad modular (cambios en Continuidad modular (cambios en mdulos y con poco impacto) mdulos y con poco impacto) Proteccin modular Proteccin modular
Costes totales del software Costes o esfuerzo Coste de integracin
M
Regin de costes mnimos
Coste/mdulo
Fuente: Ingeniera del Software. Un enfoque prctico. R. S. Pressman Nmero de mdulos escuela superior de ingeniera informtica ingeniera del software de gestin
8 / 125

INDEPENDENCIA FUNCIONAL INDEPENDENCIA FUNCIONAL Consecuencia de la aplicacin de conceptos Consecuencia de la aplicacin de conceptos como la modularidad, la abstraccin y la como la modularidad, la abstraccin y la ocultacin de la informacin ocultacin de la informacin Componentes con funcin nica y poca Componentes con funcin nica y poca interaccin con otros interaccin con otros Ms fciles de mantener y probar Ms fciles de mantener y probar Menos efectos secundarios por Menos efectos secundarios por modificaciones modificaciones Reducida propagacin de errores Reducida propagacin de errores Facilita la reutilizacin Facilita la reutilizacin
ACOPLAMIENTO
Medida de la interdependencia relativa entre componentes, y depende de la interfaz entre stos, es decir, de la cantidad y tipo de datos que comparten. Objetivo durante el diseo: minimizar el acoplamiento utilizando conexiones sencillas entre los mdulos. Formas de reducir el acoplamiento: Eliminando relaciones innecesarias Reduciendo las relaciones necesarias Beneficios de un bajo acoplamiento: Menor transmisin de defectos (efectos secundarios) Posibilidad de cambiar un componente (clase, subsistema, mdulo,...) sin incidir sobre otros En el mantenimiento de un componente no hay que tener en cuenta el contenido de otros
COHESIN
Medida del grado de fuerza funcional de un componente: cuanto menor sea el nmero de tareas (elementos de procesamiento) que realiza un componente, mayor ser su cohesin. Diferentes grados de cohesin:
COMPONENTE CON TAREA SIMPLE COMPONENTE CON DIVERSAS TAREAS POCO O NADA RELACIONADAS
Conceptos complementarios Conceptos complementarios Maximizar la cohesin es casi Maximizar la cohesin es casi lo mismo que minimizar el lo mismo que minimizar el acoplamiento acoplamiento
9 / 125
proceso del diseo

fuente: Ingeniera de Software, I. Sommerville
10 / 125
proceso del diseo

Diseo arquitectnico
Identificacin y documentacin de los subsistemas que forman el sistema y sus relaciones
Especificacin abstracta
Especificacin de servicios y restricciones bajo los que funcionar cada subsistema
Diseo de la interfaz
Diseo y documentacin de la interfaz de cada subsistema con otros subsistemas
Diseo de componentes
Asignacin de servicios a los componentes y diseo de sus interfaces
Diseo de la estructura de datos Diseo de algoritmos
11 / 125
diseo arquitectnico
Los grandes sistemas se descomponen en subsistemas que proporcionan conjuntos de servicios relacionados
<<subsistema>>
Sistema de visin <<subsistema>>

<<subsistema>> Controlador del brazo <<subsistema>> Co ntrolador del asidero
<<subsistema>>
Sistema d e i dentificaci n de objetos
<<subsistema>> <<subsistema>>
Sistema de seleccin de embalajes
<<subsistema>> <<subsistema>> Sistema de embalaje

Contro lado r de cinta transportadora
12 / 125
diseo arquitectnico
diseo arquitectnico
proceso inicial del diseo para identificar los subsistemas y establecer un marco de trabajo para el control y comunicacin entre ellos
Estructuracin del sistema
actividades principales
estructuracin del sistema en varios subsistemas principales modelado del control entre las partes del sistema descomposicin modular: cada subsistema se descompone en mdulos interconectados
Modelado del control
salida del diseo arquitectnico: documento con diversas perspectivas de la arquitectura

modelo estructural esttico: subsistemas o componentes a desarrollar como unidades separadas modelo de proceso dinmico: organizacin del sistema en tiempo de ejecucin, y que puede ser distinto al modelo esttico modelo de interfaz: definicin de los servicios ofrecidos por cada subsistema a travs de su interfaz pblica modelos de relacin: relaciones de, por ejemplo, el flujo de datos entre subsistemas modelo de distribucin: cmo se distribuyen los subsistemas entre los componentes fsicos del sistema (computadores, nodos de red,)
escuela superior de ingeniera informtica ingeniera del software de gestin 13 / 125
Des compos icin modular
diseo arquitectnico
diseo arquitectnico y requisitos no funcionales

la arquitectura puede estar en funcin de requisitos no funcionales (rendimiento, robustez, mantenibilidad, etc) necesarios para el sistema y que en ocasiones pueden exigir arquitecturas contradictorias
rendimiento: si se necesita un elevado rendimiento se utilizarn pocos subsistemas con poca comunicacin seguridad: las aplicaciones con elevado nivel de seguridad necesitarn estructurarse en capas con los recursos crticos protegidos en las capas ms internas, que contarn con elevados nivel de validacin disponibilidad: puede obligar a incluir componentes redundantes que puedan reemplazarse y actualizarse sin detener el sistema mantenibilidad: mejora cuando se utilizan componentes ms pequeos, que pueden intercambiarse con facilidad
14 / 125
diseo arquitectnico: arquitectura

diseo arquitectnico > arquitectura
arquitectura o estructuracin:
identificacin de subsistemas o capas clave a desarrollar de forma independiente
identificacin de las relaciones entre subsistemas efectivo para la comunicacin entre los participantes en el proyecto y el reparto de tareas entre distintos grupos modelos especficos de arquitectura
modelo de depsito o repositorio modelo cliente/servidor modelo de mquina abstracta o en capas
15 / 125
modelo de repositorio
diseo arquitectnico > arquitectura > modelo de depsito
modelo de repositorio (o depsito)

arquitectura en la que todos los datos compartidos se ubican en una base de datos central a la que acceden todos los subsistemas til en sistemas que utilizan grandes cantidades de datos, generados por un subsistema y utilizados por otro
sistemas de informacin corporativa sistemas CAD y CASE sistemas de control de procesos ...
editor de diseo editor de diseo generador generador de cdigo de cdigo
traductor traductor de diseo de diseo
Depsito de proyectos
editor de editor de programas programas
analizador analizador de diseo de diseo enrique barreiro alonso universidade de vigo - departamento de informtica
generador degenerador informes de informes
arquitectura de un conjunto integrado de arquitectura de un herramientas CASE conjunto integrado de herramientas CASE
fuente: Ingeniera de Software, I. Sommerville, fuente: Ingeniera de Software, I. Sommerville,
16 / 125
modelo de repositorio
diseo arquitectnico > arquitectura > modelo de depsito
Ventajas
Inconvenientes los subsistemas deben estar acordes al modelo de depsito de datos, lo que lleva a un compromiso entre las necesidades especficas de cada herramienta, lo que puede afectar a cuestiones como el rendimiento. difcil o imposible integrar subsistemas cuyos modelos de datos no se ajusten al esquema. genera un gran volumen de informacin y es difcil hacer evolucionar el sistema. diferentes subsistemas pueden tener diferentes requerimientos de polticas de seguridad, recuperacin y respaldo. El modelo de depsito impone la misma poltica a todos los subsistemas. difcil distribuir el depsito en varias mquinas (problemas de inconsistencia y redundancia de los datos)
comparticin eficiente de grandes cantidades de datos, sin necesidad de transmitir datos explcitamente de un subsistema a otro.
los subsistemas que producen datos no necesitan saber cmo son utilizados por otros subsistemas. centralizacin de actividades de administracin del depsito: respaldo, seguridad, control de acceso y recuperacin de errores. las herramientas compatibles con el modelo de datos se integran directamente
17 / 125
modelo cliente/servidor
diseo arquitectnico > arquitectura > modelo cliente / servidor
modelo de sistemas distribuido que muestra cmo datos y procesamiento se distribuyen a lo largo de varios procesadores componentes
conjunto de servidores independientes que ofrecen servicios a otros subsistemas
servidores de impresin servidores de administracin de archivos servidores de bases de datos ...
conjunto de clientes
invocan los servicios ofrecidos por los servidores mediante un protocolo de peticin-respuesta (por ejemplo, http en la WWW) existen varias instancias de un programa cliente que se ejecuta de forma concurrente tienen que conocer los nombres de los servidores disponibles y los servicios que suministran, pero los servidores no conocen a los clientes
una red que permite a los clientes acceder a los servicios
no existe una relacin 1:1 entre procesos y procesadores: un computador servidor puede ejecutar varios procesos servidores (confusin entre servidorproceso y servidor-computador)
enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
18 / 125
Servidor de Servidor catlogosde catlogos Catlogo Catlogo Cliente 1 Cliente 1
Servidor de vdeos Servidor de vdeos Archivos de vdeos Archivos de vdeos INTERNET Cliente 2 Cliente 2
Servidor de Servidor imgenesde imgenes Fotografas Fotografas digitalizadas digitalizadas
Cliente 3 Cliente 3
Servidor web Servidor web Cliente 4 Cliente 4 Pginas web Pginas web
Cliente 1 Cliente 1 enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
19 / 125
distintas arquitecturas cliente/servidor

tres capas lgicas
capa de presentacin: se encarga de mostrar la informacin e interactuar con el usuario. capa de procesamiento de la aplicacin: implementa la lgica de la aplicacin capa de administracin de datos: se refiere a todas las operaciones de la base de datos
Capa de presentacin
modelo en dos capas fsicas:

Capa de procesamiento de la aplicacin
la arquitectura ms simple. La aplicacin se organiza como un servidor (o varios idnticos) y un conjunto de clientes modelo de cliente delgado
todo el procesamiento de la aplicacin y la administracin de datos se realiza en el servidor el cliente nicamente ejecuta el software el servidor slo es responsable de la administracin de datos el software del cliente implementa toda o gran parte de la lgica de la aplicacin y las interacciones del usuario con el sistema
Capa de administracin de datos
modelo de cliente grueso
20 / 125
diseo arquitectnico > arquitectura > modelo cliente / servidor > modelo de cliente delgado
modelo de cliente delgado

utilizado cuando los sistemas heredados centralizados (p.ejemplo, sistemas basados en mainframes grandes servidores corporativos) evolucionan a una arquitectura cliente/servidor
la interfaz migra a los PCs, estaciones de trabajo o a dispositivos de red sencillos sistemas basados en tecnologas web: los dispositivos de red ejecutan un navegador, que implementa la interfaz de usuario la aplicacin misma acta como servidor y maneja todo el procesamiento de la aplicacin y administracin de datos
desventajas
implica una gran carga de procesamiento en el servidor el servidor realiza todos los clculos, lo que provoca trfico en la red entre cliente y servidor desaprovecha la capacidad de clculo de equipos como los PCs
Cliente Cliente
Presentacin
Servidor Servidor
Administrador de datos Administrador de datos Procesamiento de la Procesamiento de la aplicacin aplicacin
21 / 125
diseo arquitectnico > arquitectura > modelo cliente / servidor > modelo de cliente grueso
modelo de cliente grueso

Cliente Cliente
distribuye al cliente procesamiento lgico de la aplicacin y la presentacin

Servidor Servidor
Administrador de datos Administrador de datos
Procesamiento de las Procesamiento de las aplicaciones y presentacin aplicaciones y presentacin
aprovecha la capacidad de procesamiento disponible en los clientes ejemplo: sistemas bancarios ATM (cajeros automticos)
los ATM no se conectan directamente a la base de datos del cliente sino al gestor de transacciones gestor de transacciones: sistema middleware que organiza las comunicaciones con los clientes remotos coloca en serie las transacciones de los clientes para ser procesadas por la base de datos, lo que permite al sistema recuperarse de fallos sin corromper los datos
Servidor de cuentas
ATM ATM
Monitor de teleprocesamiento
Base de datos de cuentas
inconvenientes
administracin del sistema ms compleja al distribuirse la funcionalidad de la aplicacin en diferentes computadores mantenimiento: reinstalacin en cada computador cliente si cambia la aplicacin
ATM ATM
ATM ATM
problemas del enfoque de dos capas fsicas

Servidor de cuentas
las tres capas lgicas (presentacin, procesamiento y administracin de datos) deben asociarse a dos sistemas de cmputo problemas de escalabilidad y rendimiento en el modelo de cliente delgado problemas de administracin del sistema en el modelo de cliente grueso
SQL
Base de datos de cuentas
Consultas SQL
alternativa: utilizar tres capas fsicas

las tres capas lgicas son procesos separados lgicamente
Servidor web Provisin del servicio de la cuenta
Servidor web Provisin del servicio de la cuenta
no implica la existencia de tres sistemas de cmputo conectados a la red pero si es necesario se pueden separar fcilmente y ejecutar en procesadores separados son ms escalables que las arquitecturas de dos niveles ejemplo: sistema bancario en Internet:
administracin de datos: suministrado por la base de datos del banco (normalmente en un mainframe) servicios de aplicacin (transferencias, consulta de movimientos, pago de facturas,...) suministrados por un servidor Web presentacin: el cliente es el computador del usuario con un navegador web sistema escalable: se pueden aadir fcilmente servidores web cuando aumenta el nmero de clientes
Interaccin HTTP
Clientes web Clientes web enrique barreiro alonso universidade de vigo - departamento de informtica
23 / 125
Cdigo mvil: applets de Java y controles ActiveX

Servidor web
permiten implementar un modelo cliente/servidor a medio camino entre los de cliente delgado y grueso funcionamiento
parte del software de procesamiento se descarga en el cliente como applet, aligerando la carga del servidor la interfaz de usuario se construye utilizando un navegador Web que ejecuta los applets o los controles ActiveX
Administracin datos Procesamiento aplicacin
Interaccin HTTP
problemas
Cliente web
Presentacin Ejecucin applets
diferencias en las implementaciones de Java en navegadores de distintos fabricantes necesidad de una velocidad de transmisin aceptable para descargar los applets problemas de seguridad libertad de configuracin por el usuario
24 / 125
Arquitectura
Aplicaciones Aplicaciones de sistemas heredados donde no es prctico separar el procesamiento de las aplicaciones y la administracin de datos.
C/S de dos capas con clientes delgados
Aplicaciones computacionalmente intensivas como los compiladores con poca o ninguna administracin de datos. Aplicaciones intensivas en datos (navegar y consultar) con poco o ningn procesamiento de la aplicacin. Aplicaciones con procesamiento de datos computacionalmente intensivo (por ejemplo, visualizacin de datos, animaciones grficas,...) Aplicaciones con funcionalidad para el usuario final relativamente estable utilizadas en un entorno con administracin de sistemas bien establecido. Aplicaciones de gran escala con cientos o miles de clientes. Aplicaciones donde tanto los datos como la aplicacin son voltiles. Aplicaciones donde se integran datos de diversas fuentes.
C/S de dos capas con clientes gruesos
C/S de tres capas o mltiples capas
25 / 125
modelo en capas
diseo arquitectnico > arquitectura > modelo en estratos
modelo en capas o de mquina abstracta

Usuarios Gestin de configuraciones del sistema Gestin de objetos del sistema Base de datos del sistema Sistema operativo
modela la interaccin entre los subsistemas organizando un sistema en una serie de capas cada capa presta servicios a la capa inmediatamente superior y acta como cliente de la que queda encerrada el diseo incluye los protocolos que establecen cmo interactuar cada par de capas arquitectura cambiable y portable:
preservando la interfaz, una capa se puede reemplazar por otra cuando cambian las interfaces de las capas slo afecta a la capa adyacente
desventajas
difcil estructurar los sistemas pues es posible que el usuario requiera acceso a capas internas (p.ej., bases de datos) lo que subvierte el modelo el rendimiento puede resultar afectado por los mltiples niveles de interpretacin de rdenes que se requieren a veces
Modelo de capas de un sistema de gestin de versiones. Fuente: Ingeniera del Software, I. Sommerville
26 / 125
modelo en capas: ejemplos

diseo arquitectnico > arquitectura > modelo en estratos
Arquitectura de red OSI

Aplicacin Presentacin Sesin Transporte Red Enlace de datos Fsica Red Enlace de datos Fsica MEDIOS DE COMUNICACIN Aplicacin Presentacin Sesin Transporte Red Enlace de datos Fsica Interconexin fsica Transferencia de datos Transferencia de informacin de las aplicaciones
Arquitectura de red TCP/IP

Aplicacin Transporte Interred Host a red ARPANET INTERNET TELNET TCP IP SATNET LAN FTP SMTP UDP DNS
27 / 125
diseo arquitectnico: modelado del control

diseo arquitectnico > modelado del control
modelos de control
representan la forma en que los subsistemas se controlan para que sus servicios se entreguen en el lugar correcto y en el momento justo el arquitecto organiza los subsistemas acorde a un modelo de control dos modelos de control genricos:
control centralizado: un subsistema es el responsable de controlar, iniciar y detener otros subsistemas. Tambin puede pasar el control a otros subsistemas, pero espera que se le devuelva esa responsabilidad de control. control basado en eventos: cada subsistema puede responder a eventos generados en el exterior, provenientes de otros subsistemas o del entorno del sistema
complementan los modelos estructurales, y todos stos se pueden llevar a cabo utilizando un control centralizado u orientado a eventos
28 / 125
control centralizado
diseo arquitectnico > modelado del control > control centralizado
sistemas de control centralizado

programa programa principal principal
un subsistema tiene la responsabilidad de controlar el sistema y administrar la ejecucin de otros subsistemas

rutina 3 rutina 3
rutina 1 rutina 1
rutina 2 rutina 2
dos clases, segn se ejecuten secuencialmente o en paralelo

modelo de llamada-retorno (ejecucin secuencial):
el control se inicia en la parte superior de una jerarqua y por medio de llamadas a subrutinas pasa a los niveles del rbol no es un modelo estructural, por lo que no es necesario, por ejemplo, que la Rutina 1.1. forme parte de la Rutina 1 slo se aplica a sistemas secuenciales utilizado por lenguajes de programacin como Ada, Pascal y C, aunque tambin en lenguajes OO. ventaja: es relativamente sencillo analizar los flujos de control y conocer cmo responder el sistema a cierto tipo de entradas inconveniente: las excepciones a operaciones normales son complicadas de gestionar se aplica a los modelos concurrentes un componente del sistema se designa como administrador y controla el inicio, detencin y coordinacin del sistema segn las variables de estado del sistema. Verifica si otros procesos han producido informacin para procesar o si ha que pasarles informacin para el procesamiento. un proceso es un subsistema o mdulo que se ejecuta en paralelo con otros procesos utilizado en sistemas de tiempo real suaves (con restricciones de tiempo no muy estrictas)
rutina 1.1 rutina 1.1
procesos del sensor
procesos del actuador
modelo del administrador:

controlador controlador sistema sistema
procesos de clculo
interfaz de interfaz de usuario usuario
controlador controlador de fallos de fallos
29 / 125
control centralizado: ejemplo

diseo arquitectnico > modelado del control > control centralizado
Ejemplo del modelo del administrador centralizado

400 Hz 60 Hz 100 Hz
Proceso detector Proceso detector de movimiento de movimiento Estado del detector 560 Hz
Proceso sensor de Proceso sensor de puertas puertas
Proceso sensor de Proceso sensor de ventanas ventanas class BuildingMOnitor extends Thread { class BuildingMOnitor extends Thread { BuildingSensor win, door, move ; BuildingSensor win, door, move ; Siren siren = new Siren () ; Siren siren = new Siren () Lights lights = new Lights () ;; Lights lights = new Lights () ; DoorSensors doors = new DoorSensors (30) ; DoorSensors doors = new DoorSensors (30) ; ( ... ) ( ... ) BuldingMonitor() { BuldingMonitor() { //inicializar sensores e iniciar procesos ( ... ) //inicializar sensores e iniciar procesos } ( ... ) } public void run () { public void run () { int room = 0 ; int room = while (true) 0 ; { while (true) { //sondear movimiento sensores (400Hz) //sondear movimiento sensores move = movements.getVal () ; (400Hz) move = movements.getVal () ; ( ... ) ( ... ) } }
Estado del sensor
Estado del sensor
Proceso de Proceso de monitorizacin monitorizacin edificio edificio Nmero de habitacin
Proceso del Proceso del sistema de alarma sistema de alarma
30 / 125
control dirigido por eventos

diseo arquitectnico > modelado del control > control dirigido por eventos
sistemas de control dirigido por eventos

se rigen por eventos generados en el exterior (seal de un sensor, comando desde un men,) diferentes tipos de sistemas dirigidos por eventos
hojas de clculo (el valor cambiante de las celdas provoca que otras se modifiquen) sistemas de produccin basados en reglas (por ejemplo, de Inteligencia Artificial) en los que una condicin que se convierte en verdadera provoca que se dispare una accin objetos activos, en los que el cambio de valor de un atributo del objeto dispara algunas acciones
dos tipos de modelos principales

modelos de transmisin (broadcast): los subsistemas registran un inters en eventos especficos y cuando ocurren el control se transfiere al subsistema que puede manejar el evento modelos dirigidos por interrupciones: especialmente tiles para sistemas de tiempo real que necesitan manejar rpidamente eventos generados en el exterior
31 / 125
control por eventos: modelos de transmisin

diseo arquitectnico > modelado del control > control dirigido por eventos > modelos de transmisin
modelos de transmisin
se diferencia del modelo del administrador en que la poltica de control no est contenida en el controlador de eventos y mensajes, sino que los subsistemas deciden qu eventos requieren y el controlador asegura que estos eventos sean enviados a dichos subsistemas efectivos para integrar subsistemas distribuidos a lo largo de diferentes computadores de una red utilizados por los agentes de solicitud de objetos (ORBs) para las comunicaciones de objetos distribuidos ventajas:
la evolucin es relativamente sencilla pues se pueden integrar nuevos subsistemas registrando sus eventos en el controlador de eventos cualquier subsistema puede activar otros subsistemas sin conocer su nombre o ubicacin los subsistemas se pueden incrementar en mquinas distribuidas, de forma transparente para otros subsistemas
subsistema subsistema 1 1
Controlador de eventos y mensajes
desventaja:
los subsistemas no saben si los eventos se manejarn ni cuando lo harn cuando un subsistema genera un evento no sabe qu otros subsistemas han registrado un inters en ese evento
32 / 125
modelos de transmisin: objetos distribuidos

diseo arquitectnico > modelado del control > control dirigido por eventos > modelos de transmisin > arquitecturas de objetos distribuidos
modelos de transmisin: arquitecturas de objetos distribuidos

consiste en eliminar la distincin entre cliente y servidor y disear la arquitectura del sistema como una arquitectura de objetos distribuidos los componentes fundamentales son
objetos que proveen una interfaz a un conjunto de servicios que suministran otros objetos llaman a estos servicios sin ninguna distincin lgica entre un cliente (receptor de un servicio) y un servidor (proveedor de un servicio)
o1 s(o1)
o2 s(o2)
o3 s(o3)
funcionamiento
los objetos se distribuyen a lo largo de varios computadores sobre una red se comunican a travs de middleware (una especie de bus de software que provee un conjunto de servicios que permiten comunicacin, agregacin y destruccin de objetos del sistema middleware: agente de solicitud de objetos (ORB, Object Request Broker) y provee una interfaz transparente entre objetos
ventajas
ORB permite retrasar las decisiones sobre dnde y cmo se deben suministrar los servicios pues los objetos proveedores de servicios se pueden ejecutar en cualquier nodo de la red arquitectura abierta: permite agregar nuevos recursos si es necesario pues los estndares del ORB (p.ej., CORBA) se han desarrollado para permitir la comunicacin y servicios entre objetos escritos en diferentes lenguajes sistema flexible y escalable: se pueden crear diferentes instancias del sistema con el mismo servicio suministrado por objetos diferentes o por rplicas de objetos para hacer frente a diversas cargas del sistema
o4 s(o4)
o5 s(o5)
desventajas
ms complejas de disear que los sistemas cliente/servidor clsicos escuela superior de ingeniera informtica ingeniera del software de gestin
33 / 125

utilizacin de una arquitectura de objetos distribuidos

como modelo lgico para estructurar y organizar el sistema
se piensa nicamente en cmo proveer de funcionalidad a la aplicacin (servicios y combinaciones de servicios) identificacin de cmo suministrar los servicios utilizando varios objetos distribuidos
objetos de grano grueso (tambin llamados objetos de negocio) que suministran servicios especficos del dominio. Por ejemplo, objetos de control de existencias, comunicaciones con el cliente, pedidos,...
como un enfoque flexible para implementar sistemas cliente/servidor

el modelo lgico del sistema es un modelo c/s en el que clientes y servidores se realizan como objetos distribuidos que se comunican a travs del ORB el sistema se puede cambiar fcilmente de dos capas a uno de mltiples capas (implementando el servidor o el cliente como un objeto compuesto de varios objetos pequeos que suministran servicios especializados)
34 / 125

ejemplo de arquitectura de objetos distribuidos

sistema de minera de datos que busca relaciones entre datos almacenados en varias bases de datos diferentes
generador informes Base de datos 1
Integrador 1
Base de datos 2
visualizador
cada base de datos se encapsula como un objeto distribuido con una interfaz que suministra acceso de slo lectura los objetos integradores recolectan informacin de todas las bases de datos para tratar de deducir relaciones especficas (cada uno tiene su especialidad, como variaciones por temporadas, relaciones entre tipos de bienes,...) los objetos visualizadores interactan con los integradores para visualizar o generar informes
Integrador 2 Base de datos 3 pantalla
la arquitectura de objetos distribuidos es ms adecuada para este tipo de aplicaciones que una c/s
el modelo lgico del sistema no es suministrar informacin proporcionada por diferentes servicios de administracin de datos (como en los ATM) el nmero de bases de datos se puede incrementar sin perturbar el sistema pues son objetos distribuidos que pueden residir en diferentes mquinas se pueden explorar nuevos tipos de relaciones agregando nuevos objetos integradores que no necesitan conocer a los ya existentes
35 / 125
control por eventos: modelos dirigidos por interrupciones

diseo arquitectnico > modelado del control > control dirigido por eventos > modelos dirigidos por interrupciones
modelos dirigidos por interrupciones

interrupciones
vector de interrupcin
tiles para sistemas de tiempo real que necesitan manejar muy rpidamente eventos generados en el exterior (por ejemplo, sistemas de seguridad en automviles) combinado con el modelo de administrador centralizado: el administrador central maneja la ejecucin normal del sistema utilizando el control basado en interrupciones para casos de emergencia
interrupciones existen varios tipos de interrupciones conocidas con un controlador definido para cada tipo controlador controlador controlador controlador cada tipo de interrupcin se asocia con la ubicacin de controlador controlador controlador controlador 1 2 3 4 memoria en la que se almacena la direccin del controlador 2 3 4 1 cuando se recibe una interrupcin de un determinado tipo, un interruptor de hardware transfiere el control al controlador adecuado proceso proceso proceso proceso el controlador puede iniciar o detener otros procesos en proceso proceso proceso proceso 1 2 3 4 1 2 3 4 respuesta a los eventos recibidos por el interruptor ventaja: permite dar respuestas rpidas a los eventos
desventajas complejo de programar y difcil de validar si el nmero de interrupciones est limitado por el hardware, cuando se alcanza el lmite no se pueden gestionar ms tipos de eventos (se pueden asignar distintos tipos de eventos a una interrupcin, dejando que el controlador detecte qu evento ha ocurrido, pero disminuye el rendimiento
36 / 125
computacin distribuida interorganizacional

Computacin distribuida interorganizacional

Por seguridad e interoperabilidad se ha utilizado sobre todo computacin distribuida intraorganizacional
Servidores dentro de la misma organizacin Facilidad de aplicacin de estndares locales y procesos operacionales
Modelos ms recientes de computacin distribuida interorganizacional

Computacin peer-to-peer (p2p) Sistemas orientados a servicios
37 / 125
arquitecturas peer-to-peer
Sistemas peer-to-peer (p2p)

Sistemas descentralizados:
los clculos se pueden realizar en cualquier nodo de la red no se distingue, a priori, entre clientes y servidores
Sistemas diseados para aprovechar la ventaja de potencia computacional y disponibilidad de almacenamiento de grandes redes Estndares y protocolos de comunicaciones embebidos en la propia aplicacin y cada nodo ejecuta una copia de la aplicacin Usados sobre todo en sistemas personales
Comparticin de ficheros (Gnutella, Kazaa, eMule,) Sistemas de mensajera instantnea (ICQ, Messenger,) Otras aplicaciones (SETI@home, Freenet,)
Comienza a utilizarse en entornos corporativos para aplicaciones con grandes necesidades computacionales (Intel, Boeing,)
Problemas: proteccin, autentificacin, Utilizacin en sistemas de informacin no crticos o cuando existen relaciones de trabajo entre las organizaciones
38 / 125
tericamente, cada nodo en la red puede conocer cualquier otro nodo, pero como es inviable se organizan por localidades, con nodos-puente entre localidades
arquitecturas p2p descentralizadas arquitecturas p2p semicentralizadas
n6 n6 n4 n4
n8 n8
n13 n13
n3 n3 n9 n9
n7 n7
n12 n12
n2 n2
n14 n14 n10 n10 n11 n11
n1 n1
n5 n5
fuente: Ingeniera del Software, Ian Sommerville
39 / 125
arquitectura p2p descentralizada

los nodos de red actan como interruptores de comunicaciones, encaminando datos y seales de control entre nodos. bsqueda de un documento
se enva comando de bsqueda a los nodos de la localidad los nodos comprueban si tienen el documento si lo tienen, lo devuelven al solicitante si no lo tienen, encaminan la bsqueda a otros nodos al encontrar el documento, el nodo que lo posee lo encamina de vuelta al nodo solicitante.
ventaja: muy redundante y por lo tanto tolerante a fallos y a desconexiones de nodos desventajas
sobrecargas (la misma bsqueda es realizada por muchos nodos) replicaciones de comunicaciones entre nodos
40 / 125
arquitectura p2p semicentralizada

nodos que actan como servidores para facilitar las comunicaciones entre nodos
establecimiento de contactos entre nodos coordinacin de clculos
una vez que se localizan los nodos disponibles se establecen comunicaciones directas y no es necesaria la conexin con el servidor
Buscador de servicios
n1 n1 n6 n6 n3 n3 n4 n4
n2 n2
n5 n5
41 / 125
arquitectura de sistemas orientados a servicios

servicio web
representacin estndar para cualquier recurso computacional o de informacin que pueda ser usado por otros programas permite que la provisin de un servicio sea independiente de la aplicacin que lo utiliza las organizaciones pueden hacer accesible informacin a diferentes programas definiendo y publicando una interfaz de servicio web, que define
los datos disponibles cmo acceder a los datos
proveedores de servicios: desarrollan y ofertan servicios a usuarios y permiten construir aplicaciones enlazando servicios de diferentes proveedores diferentes tipos que se ajustan al mismo modelo
Buscar
Registro de Registro de servicios servicios
Publicar
Solicitante de Solicitante de servicios servicios
Enlazar
Suministrador Suministrador de servicios de servicios
Servicio Servicio
42 / 125

algunas ventajas
los usuarios pueden pagar por los servicios slo en funcin del uso aplicaciones ms pequeas (manejos de excepciones como servicios externos) construccin a medida de nuevos servicios, enlazando servicios existentes
estndares basados en XML

SOAP (Simple Object Access Protocol): define una organizacin para intercambio de datos estructurados entre servicios web WSDL (Web Services Description Language): define cmo pueden representarse las interfaces de servicios web UDDI (Universal Description, Discovery and Integration): estndar de bsqueda que define cmo puede organizarse la informacin de descripcin de servicios
43 / 125

Informacin del trfico de carreteras

Informacin de Informacin de utilidades utilidades Coordenadas GPS Coordenadas GPS Localizador de Localizador de carreteras carreteras Informacin Informacin de trfico de trfico
Informacin Informacin del tiempo del tiempo
Coordenadas GPS
Servicio de informacin mvil

Traductor Traductor Informacin del lenguaje
Rene informacin
Comando de coordenadas GPS
Buscador de servicios Encuentra un servicio disponible
Receptor Recibe un flujo de informacin desde los servicios
Transmisor Enva la posicin y la peticin de informacin al servicio
Interfaz de usuario Recibe peticiones del usuario
Radio Traduce la informacin digital a seal de radio

Localizador Encuentra la posicin del vehculo
Sistema software de vehculos
44 / 125
arquitecturas de aplicaciones
las empresas tienen necesidades similares de informacin (facturacin, recursos humanos, contabilidad,)
similares arquitecturas de las aplicaciones diferencias en las funcionalidades especficas
arquitecturas genricas segn el tipo de aplicacin

aplicaciones de procesamiento de datos
procesamiento de datos por lotes con poca o nula interaccin del usuario
aplicaciones de procesamiento de transacciones

procesan peticiones del usuario para obtener informacin y para actualizar informacin en una base de datos
sistemas de procesamiento de eventos

aplicaciones controladas por rdenes del usuario o cambios en valores de variables (juegos, hojas de clculo, presentacin de informacin,)
sistemas de procesamiento de lenguajes
45 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de datos

sistemas de procesamiento de datos

dan soporte a parte del negocio como pago de nminas, clculo e impresin de facturas, renovacin de suscripciones o plizas, trabajan con grandes bases de datos componentes
entrada: rene entradas desde una o ms fuentes procesamiento: realiza clculos utilizando las entradas salida: genera salidas para ser escritas en la base de datos y/o impresas
modelo arquitectnico simple pero suele corresponderse con una compleja arquitectura de datos Sistema Sistema
Entrada Entrada
Procesamiento Procesamiento
Salida Salida
Base de datos Base de datos
46 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de datos

Registros de Registros de empleados empleados
Escribir transacciones Escribir transacciones de impuestos de impuestos

Gasto deducible + nmero SS + oficina tributaria
Transacciones Transacciones de impuestos de impuestos
Leer registro Leer registro de empleado de empleado

Registro de empleado
Tasas de pagos Tasas de pagos mensuales mensuales
Escribir datos Escribir datos de pensiones de pensiones

Pensin deducible + nmero SS
Datos de Datos de pensiones pensiones
Validar datos Validar datos de empleado de empleado

Informacin de pagos
Registro vlido de empleado
Calcular Calcular salario salario
Datos del empleado + deducciones
Imprimir Imprimir nmina nmina
IMPRESORA
Pago neto + informacin de cuenta bancaria
Leer datos de pagos Leer datos de pagos mensuales mensuales
Tablas de Tablas de impuestos impuestos
Escribir transaccin Escribir transaccin bancaria bancaria
Transacciones Transacciones del banco del banco
Deduccin de la SS + nmero SS
Datos de Datos de pagos pagos mensuales mensuales
Escribir datos de la Escribir datos de la Seguridad Social Seguridad Social
Datos de la Datos de la Seguridad Social Seguridad Social
47 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones

sistemas de procesamiento de transacciones

procesan peticiones de usuario para obtener informacin o para actualizar una base de datos transaccin de una base de datos: secuencia de operaciones tratada como una nica unidad, en la que todas las operaciones tienen que ser completadas antes de que los cambios en la base de datos sean permanentes
ejemplo: reintegro en un cajero automtico
normalmente son sistemas interactivos en los que el usuario realiza peticiones de servicios de forma asncrona
Procesamiento Procesamiento de E/S de E/S
Lgica de la Lgica de la aplicacin aplicacin
Gestor de Gestor de transacciones transacciones
Base de Base de datos datos
48 / 125

la estructura entrada-proceso-salida tambin se aplica a muchos sistemas de procesamiento de transacciones (versiones interactivas de sistemas de procesamiento por lotes)
Entrada Obtener el Obtener el identificador de identificador de cuenta del cliente cuenta del cliente Validar la Validar la tarjeta tarjeta
Proceso
Salida Imprimir Imprimir detalles detalles
Consultar la Consultar la cuenta cuenta
Devolver la Devolver la tarjeta tarjeta Actualizar la Actualizar la cuenta cuenta
Seleccionar el Seleccionar el servicio servicio
Dispensar Dispensar efectivo efectivo
ATM
Base de Datos
ATM
49 / 125

Bases de datos de cuentas
Monitor de teleprocesamiento Monitor de teleprocesamiento (middleware) (middleware)
50 / 125

sistemas de informacin y de gestin de recursos: sistemas con gran interaccin con una base de datos compartida
sistemas sistemas sistemas sistemas sistemas sistemas gestin documental de ayuda a la toma de decisiones de horarios de gestin de trfico areo de biblioteca de comercio electrnico
Interfaz de usuario Interfaz de usuario
Comunicaciones del usuario Comunicaciones del usuario
Recuperacin y modificacin de informacin Recuperacin y modificacin de informacin
Base de datos de gestin de transacciones Base de datos de gestin de transacciones
51 / 125

Arquitectura de un sistema de gestin de documentos Interfaz del navegador web Interfaz del navegador web
Arquitectura de un sistema de asignacin de recursos
Interfaz de usuario Interfaz de usuario
Identificacin Gestor de consultas de usuario y formularios
Gestor de impresin
Identificacin de usuario
Entrega de recursos
Gestin de consultas
Bsqueda Recuperacin Gestor de distribuida de documentos derechos
Registro de cuentas
Gestin de recursos
Control de polticas de recursos
Asignacin de recursos
ndice de biblioteca ndice de biblioteca BD1 BD1 BD2 BD2 BD3 BD3 BD4 BD4 BDn BDn
Gestin de transacciones de Gestin de transacciones de lala base de datos de recursos base de datos de recursos
52 / 125
descomposicin modular
diseo arquitectnico > descomposicin modular
descomposicin modular
despus de disear la arquitectura estructural se descomponen los subsistemas en mdulos
no existe una distincin rgida entre la descomposicin del sistema y la descomposicin modular:
los modelos arquitectnicos se pueden aplicar aqu sin embargo, los componentes en los mdulos son ms pequeos que los subsistemas, por lo que se utilizan modelos alternativos de descomposicin
modelos principales de descomposicin modular

modelo orientado a objetos:
el sistema se descompone en un conjunto de objetos que se comunican entre ellos los mdulos son objetos con estado privado y operaciones definidas sobre ese estado
modelo de flujo de datos (o estructurado):

el sistema se descompone en mdulos funcionales que reciben datos y los transforman en datos de salida
53 / 125
diseo orientado a objetos: actividades

diseo orientado a objetos > actividades
actividades (segn el Proceso Unificado de Desarrollo)

diseo de la arquitectura
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
realizado por los arquitectos esbozan distintos componentes
Diseo de la arquitectura
subsistemas principales e interfaces clases del diseo importantes (como las activas) mecanismos genricos de diseo del modelo de diseo
Disear un caso de uso
Disear una clase
diseo de casos de uso

lo realizan los ingenieros de casos de uso detallan cada caso de uso en trminos de clases y/o subsistemas del diseo participantes y sus interfaces las realizaciones de casos de uso resultantes establecen los requisitos de comportamiento para cada clase o subsistema
Disear un subsistema
diseo de clases
lo realizan los ingenieros de componentes integran los requisitos dentro de cada clase (creando operaciones, atributos y relaciones)
diseo de subsistemas
lo realizan los ingenieros de componentes se identifican candidatos para ser subsistemas, especificando las interfaces entre ellos
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
54 / 125
diseo orientado a objetos > diseo de la arquitectura
el objetivo es esbozar los modelos de diseo y despliegue y su arquitectura mediante la identificacin de los siguientes elementos:
nodos y configuraciones de red subsistemas e interfaces entre ellos clases del diseo significativas para la arquitectura mecanismos de diseo genricos derivados de requisitos no funcionales (persistencia, distribucin, rendimiento,...) identificados durante el anlisis
Disear una clase
los arquitectos consideran distintas posibilidades de reutilizacin (partes de sistemas parecidos o de productos software generales)
55 / 125
identificacin de nodos y configuraciones de red

diseo orientado a objetos > diseo de la arquitectura > identificacin de nodos y configuraciones de red
Cliente del comprador
configuraciones fsicas de la red

gran influencia sobre la arquitectura del software las configuraciones habituales utilizan una arquitectura en tres capas (por ejemplo, cliente / servidor)
capa de clientes (interacciones de usuarios) capa de funcionalidad de la base de datos capa de lgica de negocio o aplicacin
Intranet Servidor del comprador
internet Servidor del vendedor
aspectos importantes de las configuraciones de red

nmero de nodos necesarios y capacidad en trminos de potencia de proceso y tamao de memoria tipo de conexiones entre los nodos y protocolos de comunicaciones a utilizar caractersticas de las conexiones y protocolos en aspectos como ancho de banda, disponibilidad y calidad necesidad de capacidades de redundancia de procesos, gestin de fallos, migracin de procesos, poltica de copias de seguridad,... una vez conocidos se pueden aplicar distintas tecnologas
ORB (Object Request Broker) servicios de replicacin de datos ...
internet
int ernet Servidor del banco

intranet
Cliente del vendedor
las configuraciones de red se muestran en diagramas de despliegue

enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin 56 / 125
identificacin de nodos y configuraciones de red

Ejemplo de un sistema de comercio electrnico. Se ejecuta sobre tres nodos servidores y un cierto nmero de nodos cliente. En primer lugar existe un nodo servidor para el comprador y uno para el vendedor, debido a que cada una de las organizaciones compradoras o vendedoras necesitan un servidor central para sus objetos de negocio y su procesamiento. Los usuarios finales, como el Comprador, acceden al sistema mediante nodos cliente. Estos nodos se comunican mediante el protocolo TCP/IP de Internet (o de intranets). Tambin existe un tercer nodo servidor para el propio banco. En l se producen los verdaderos pagos de facturas (es decir, las transferencias entre cuentas).
internet

intranet
57 / 125
Arquitecto
Ingeniero de casos de uso
Ingeniero de componentes
Disear una clase
identificacin de subsistemas y sus interfaces

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas
subsistemas
forma de organizar el modelo de diseo en piezas manejables
Capa especfica de la aplicacin
representan varios tipos de subsistemas

software desarrollado internamente en el proyecto productos reutilizados recursos existentes en la empresa
Capa general de la aplicacin
pasos en la identificacin de subsistemas

Capa intermedia
Capa de software del sistema
identificacin de subsistemas de aplicacin identificacin de subsistemas intermedios y de software del sistema definicin de dependencias entre subsistemas identificacin de interfaces entre subsistemas
58 / 125
identificacin de subsistemas de la aplicacin

Subsistemas de la aplicacin
Identificacin de los subsistemas de las capas especfica y general de la aplicacin Si hubo descomposicin adecuada en paquetes en el anlisis, se pueden utilizar para identificar subsistemas en el modelo de diseo
Capa especfica de la aplicacin
Capa general de la aplicacin
Capa intermedia
59 / 125
Arquitecto
Disear una clase

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas > subsistemas de la aplicacin
se parte de la descomposicin de paquetes realizada en el anlisis y, segn los casos, puede ser necesario refinar esa identificacin de subsistemas
parte de un paquete (subsistema) del anlisis puede ser compartida por varios otros subsistemas, por lo que en s puede ser un subsistema algunas partes de un paquete del anlisis se realizan mediante productos reutilizados, por lo que esas funciones se pueden asignar a capas intermedias o subsistemas de software del sistema los paquetes del anlisis no representan una adecuada divisin del trabajo los paquetes del anlisis no representan la incorporacin de un sistema heredado, que se puede encapsular mediante un subsistema de diseo independiente los paquetes del anlisis no estn preparados para una distribucin sobre los nodos decididos, por lo que se podran dividir de forma que cada uno de ellos pueda asignarse a un nodo determinado. Luego se refinarn para minimizar el trfico de la red
<<paquet e del anlisis>> Gestin de facturas del c omprador
<<paquete del an li sis>>
Gestin de cuentas
Modelo de anlisis
<<paquet e del diseo>>

Gestin facturas comprador
<<paquete del diseo>> Gestin cuentas
Modelo de diseo
60 / 125

MODELO DE ANLISIS
MODELO DE DISEO
<<trace>>
<<trace>>
61 / 125
Arquitecto
Disear una clase

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas > subsistemas de la aplicacin
Gestin facturas comprador
capa especfica de la aplicacin capa general de la aplicacin

Gestin de planificacin de p agos
Durante el diseo se identific el subsistema de Durante el diseo Planificacin de Pagos para servicio Gestin de se identific el subsistema de servicio Gestin de Planificacin de Pagos proporcionar un servicio general que puedanpara proporcionar un servicio general casos de uso utilizar diferentes realizaciones de que puedan utilizar diferentes realizaciones de casos de uso
Gestin de cuentas
El subsistema Gestin Facturas Comprador se El subsistema Gestin Facturas Comprador descompone recursivamente en tres nuevos se descompone recursivamente en tres entre los subsistemas para tratar su distribucinnuevos subsistemas para tratar su distribucin entre los distintos nodos distintos nodos << subsistema de diseo >> Gestin facturas comprador
IU del comprador Gestin solicitudes pago procesamie nto solicitudes de pago Gestin de facturas
IU solicitud de pago
Gestor pedidos confirmacin pedidos
procesamiento facturas factura
internet

intranet
Cliente comprador
Servidor comprador
Servidor vendedor
62 / 125
Arquitecto
Disear una clase
subsistemas intermedios y de software del sistema

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas > subsistemas intermedios y del sistema
Abstract Windowing Toolkit
Remote Method Invocation
Identificacin de subsistemas intermedios y de software del sistema

Java.rmi
Java.applet
Java.awt
toda la funcionalidad descansa sobre

sistemas operativos sistemas de gestin de bases de datos software de comunicaciones tecnologas de distribucin de objetos tecnologas de gestin de transacciones software de diseo de interfaces de usuario
Navegador web
Capa intermedia
Mquina virtual ja va
TCP / IP
En este ejem plo, el sis tem a de be ejecutarse en diferentes ti pos de m qui nas y la empresa decid i im plem entar esta arquitectura me diante los pa quetes Java AWT, RMI y Appl et, que se ejecutan sobre l a m qui na virtual Java. Ad ems, h ay q ue uti li zar un naveg ador para cargar p ginas w eb. A baj o n ive l, el sistema se construye so bre so ftware del si stema, como el pro tocolo TCP/IP
compra de middleware y software del sistema

poco o nulo control sobre su evolucin importante mantener libertad de accin y evitar hacerse totalmente dependientes de un producto o fabricante
considerar cada producto software comprado como un subsistema independiente con interfaces explcitos para el resto de sistemas
63 / 125
definicin de dependencias entre subsistemas

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas > dependencias entre subsistemas
Gestin facturas
dependencias
capa especfica de la aplicacin
Gestin de planif icacin de pagos
deben definirse si hay relaciones entre los contenidos de unos subsistemas y otros
capa general de la aplicacin
Gestin de cuentas
la direccin de la dependencia es la misma que la de la relacin (navegabilidad)
Java.applet
Java.awt
Java.rmi
Mquina virtual java
Navegador web
capa intermedia
capa de software del sistema
TCP / IP
64 / 125
identificacin de interfaces entre subsistemas

Una clase que hace referencia a TransferenciaEntreCuentas desde el exterior
MODELO DE ANLISIS
<<trace>> MODELO DE DISEO
Transferencias
65 / 125
identificacin de interfaces entre subsistemas

diseo orientado a objetos > diseo de la arquitectura > identificacin de subsistemas > identificacin de interfaces
interfaces proporcionadas por un subsistema

definen operaciones que son accesibles desde fuera del subsistema
<<subsystem >> Gestin de facturas
vienen proporcionadas por

ReceptorDeFacturas Capa especfica de la aplicacin Capa general de la aplicacin
clases subsistemas dentro del subsistema
SolicitudDePago
<<subsystem>> Gestin de planificacin de pagos
<<subsystem >> Gestin de cuentas

Transferencias
adems hay que identificar las operaciones que se pueden definir sobre las interfaces (se hace en el diseo de casos de uso)
66 / 125
identificacin de mecanismos genricos de diseo

diseo orientado a objetos > diseo de la arquitectura > identificacin de mecanismos genricos de diseo
requisitos especiales identificados durante el anlisis

decidir cmo tratarlos, teniendo en cuenta las tecnologas de diseo e implementacin disponibles cuestiones relacionadas con diversas cuestiones, como:
persistencia distribucin transparente de objetos caractersticas de seguridad deteccin y recuperacin de errores gestin de transacciones
ejemplos
se necesita que algunos objetos sean accesibles desde varios nodos de red
java.rmi.UnicastRemoteObject
Necesita disearse un sistema distribuido Posible solucin: implementar esa distribucin de objetos haciendo que cada clase distribuida sea subclase de la clase abstracta de Java, java.rmi.UnicastRemoteObject, que soporta RMI (tcnica de Java para obtener una distribucin transparente de objetos)
Factura
se necesita que algunos objetos sean persistentes (por ejemplo, Pedido y Factura)
Solucin: utilizar un gestor de bases de datos orientado a objetos (buen rendimiento con estructuras de objetos complejas, migracin difcil desde un sistema relacional,...) Solucin: utilizar un gestor de bases de datos relacional (mejor rendimiento para datos tabulares, tecnologa ms madura,...) Necesario documentar en la solucin cmo se tratarn los aspectos de persistencia
identificacin de mecanismos genricos: patrones

identificacin de colaboraciones genricas (patrones)

pueden servir como patrones utilizados por diferentes casos de uso en el modelo de diseo ejemplo: un actor crea un objeto de negocio (pedido, factura,...) y lo enva a otro actor
ejemplo 1: cuando un comprador solicita un pedido, invoca el caso de uso realizar pedido. el caso de uso permite al comprador especificar y enviar electrnicamente un pedido al vendedor ejemplo 2: cuando un vendedor decide enviar una factura a un comprador, invoca el caso de uso enviar factura al comprador, que permite al vendedor escoger una factura y enviarla electrnicamente al comprador se trata de un comportamiento comn que se puede representar mediante una colaboracin genrica (utilizacin de clases abstractas)
68 / 125
identificacin de mecanismos genricos: patrones

1: enviar objeto de negocio
Creacin de objeto de negocio 3: crear( )
: Objeto de Negocio
: Emisor
2: crearObjetoDeNegocio
: ControlProcesamientoEmisor
5: obtenerInformacin( ) : Procesamiento Receptor
4: recibirObjetoDeNegocio( objetoDeNegocio)
6: presentarObjetoDeNegocio(ObjetoDeNegocio)
Al disear el caso de uso Al disear el caso de uso Enviar Factura al Comprador, Enviar Factura al Comprador, se puede hacer que algunas se puede hacer que algunas clases sean subtipos de cada clases sean subtipos de cada una de las clases abstractas una de las clases abstractas que participan en la que participan en la colaboracin genrica colaboracin genrica
IU Present acin de objeto de negocio
7: presentar objeto de negocio : Recept or
Clasificadores abstractos que participan en la colaboracin genrica de envo de objetos de negocio Clasificadores concretos que participan en la realizacin del caso de uso Enviar Factura al Comprador
: Emisor
IU Creacin de objeto de negocio
ControlProcesamie ntoEmisor
Objeto de negocio
ControlProcesamie ntoReceptor
IU Present. de objeto de negocio
: Receptor
IU Creacin de facturas
: Vendedor
ControlProcesamie ntoFacturas
Factura
Procesamiento SolicitudesPago
IU Present. de objeto de facturas

: Comprador
69 / 125
diseo de un caso de uso

diseo orientado a objetos > diseo de casos de uso
actividades del diseo de un caso de uso

identificar las clases del diseo y/o subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de sucesos del caso de uso describir las interacciones entre objetos del diseo identificar los subsistemas e interfaces participantes
Disear una clase
describir las interacciones entre subsistemas identificar requisitos no funcionales
70 / 125
Diseo de un caso de uso

Definir objetos Definir objetos participantes participantes
Definir objetos Definir objetos conceptuales conceptuales
Definir objetos Definir objetos de interfaz de interfaz
Definir objetos Definir objetos de control de control
Definir Definir interacciones interacciones
71 / 125
Identificacin de objetos de interfaz

objetos de interfaz
representan la interfaz del sistema con los actores en cada caso de uso cada actor interacta con, al menos, un objeto de interfaz recopilan la informacin del actor y la traduce para que pueda ser usada por los objetos de entidad y por los objetos de control modelan la interfaz del usuario a un nivel muy bsico, que evolucionar durante el desarrollo identificacin de los objetos de interfaz
identificar formularios y ventanas que el usuario necesita para introducir datos en el sistema (por ejemplo, FormularioInformeDeEmergencia, BotnInformeEmergencia,...) identificar noticias y mensajes que el sistema usa para responder al usuario (por ejemplo AcuseDeRecibo)
72 / 125
Identificacin de objetos de interfaz

Ubicacin Descripcin del caso de uso Ubicacin Descripcin del caso de uso 1. El OficialCampo activa la funcin Informar 1. El OficialCampo activa Emergencia en su PDA. la funcin Informar Estacin Emergencia en su PDA. OficialCampo 2. El sistema COMUNICA responde presentando 2. unEl sistema COMUNICA responde presentando formulario al OficialCampo. El formulario un formulario de tipos de emergencia incluye un menal OficialCampo. El formulario incluye accidente, disturbios,...) y campos (incendio, un men de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicacin, descripcin del para introducir la ubicacin, descripcin del incidente, peticin de recursos,... incidente, peticin de recursos,... 3. El OficialCampo cubre el formulario, y puede 3. El OficialCampo cubre el formulario, y puede tambin describir respuestas posibles a la tambin describir respuestas posibles a la situacin de emergencia y solicitar recursos situacin Una vez que ha solicitar recursos especficos.de emergencia y llenado el especficos. Una vez que ha llenado el formulario, el OficialCampo lo enva oprimiendo el formulario, el OficialCampo lo enva oprimiendo botn Enviar Informe y en ese momento se le el botnal Controlador y en ese momento se notifica Enviar Informe le notifica al Controlador 4. Al Controlador se le notifica un nuevo informe 4. deAl Controlador se le notifica un de dilogo incidente mediante un cuadro nuevo informe Estacin de incidente Controlador revisa de desplegable. Elmediante un cuadro la dilogo Controlador desplegable. El Controlador revisa la informacin recibida y crea un Incidente en la informacin llamando crea un Incidente en la base de datos recibida y al caso de uso base de datos llamando al caso contenida AbrirIncidente. Toda la informacinde uso enAbrirIncidente. Toda la informacinincluye el formulario del OficialCampo se contenida en el formulario del OficialCampo Controlador automticamente en el Incidente. El se incluye automticamente en el asignando recursos al selecciona una respuestaIncidente. El Controlador selecciona una respuesta asignando recursos incidente (con el caso de uso AsignarRecursos) al incidente (con recibo de uso AsignarRecursos) y da un acuse deel caso al informe de y da un acuse de recibo al informe de emergencia enviando un mensaje breve al emergencia OficialCampo. enviando un mensaje breve al OficialCampo. Estacin 5. El OficialCampo recibe el acuse de recibo y la OficialCampo 5. El OficialCampo recibe respuesta seleccionada. el acuse de recibo y la respuesta seleccionada.
AcuseDeRecibo Estacin Controlador BotnInforme Emergencia
Aviso usado para desplegar el acuse de recibo del Controlador hacia el OficialCampo Ordenador utilizado por el Controlador Botn usado por el OficialCampo para iniciar el caso de uso InformarEmergencia Formulario usado para dar los datos de InformarEmergencia. Este formulario se le presenta al OficialCampo en la EstacinOficialCampo cuando se selecciona la funcin InformarEmergencia. El FormularioInformeEmergencia contiene campos para especificar todos los atributos de un informe de emergencia y un botn (u otro control) para enviar el formulario cuando est cubierto. Ordenador mvil utilizado por el OficialCampo
Formulario Informe Emergencia
EstacinOficialCampo
Formulario usado para la creacin de Incidente. Este formulario se le presenta al Controlador en la EstacinControlador cuando se FormularioIncidente recibe el InformeEmergencia. El Controlador tambin usa este formulario para asignar recursos y dar el acuse del recibo al informe del OficialCampo. escuela superior de ingeniera informtica enrique barreiro alonso universidade de vigo - departamento de informtica ingeniera del software de gestin 73 / 125
Identificacin de objetos de control

objetos de control
responsables de la coordinacin entre objetos de interfaz y conceptuales no representan entidades del dominio del problema se crean al inicio del caso de uso y dejan de existir cuando termina es responsable de la recopilacin de informacin de los objetos de interfaz y de enviarla a los objetos de entidad
control del flujo de formularios en un proceso de negocio control de las colas de deshacer e historiales envo de informacin en sistemas distribuidos ...
identificacin de objetos de control

identificar un objeto de control por caso de uso o ms si el caso de uso es complejo y si puede dividirse en flujos de eventos ms cortos identificar un objeto de control por actor en el caso de uso la vida de un objeto de control debe ser la del caso de uso o la de la sesin del usuario si es difcil de identificar inicio y final de la activacin de un objeto de control puede deberse a que el caso de uso no tiene condiciones de entrada y salida bien definidas
74 / 125
Identificacin de objetos de control

Ubicacin Descripcin del caso de uso Ubicacin Descripcin del caso de uso 1. El OficialCampo activa la funcin Informar 1. El OficialCampo activa Emergencia en su PDA. la funcin Informar Estacin Estacin Emergencia en su PDA. OficialCampo OficialCampo 2. El sistema COMUNICA responde presentando 2. unEl sistema COMUNICA responde presentando formulario al OficialCampo. El formulario un formulario de tipos de emergencia incluye un menal OficialCampo. El formulario incluye accidente, disturbios,...) y campos (incendio, un men de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicacin, descripcin del para introducir la ubicacin, descripcin del incidente, peticin de recursos,... incidente, peticin de recursos,... 3. El OficialCampo cubre el formulario, y puede 3. El OficialCampo cubre el formulario, y puede tambin describir respuestas posibles a la tambin describir respuestas posibles a la situacin de emergencia y solicitar recursos situacin Una vez que ha solicitar recursos especficos.de emergencia y llenado el especficos. Una vez que ha llenado el formulario, el OficialCampo lo enva oprimiendo el formulario, el OficialCampo lo enva oprimiendo botn Enviar Informe y en ese momento se le el botnal Controlador y en ese momento se notifica Enviar Informe le notifica al Controlador 4. Al Controlador se le notifica un nuevo informe 4. deAl Controlador se le notifica un de dilogo incidente mediante un cuadro nuevo informe Estacin Estacin de incidente Controlador revisa de desplegable. Elmediante un cuadro la dilogo Controlador Controlador desplegable. El Controlador revisa la informacin recibida y crea un Incidente en la informacin llamando crea un Incidente en la base de datos recibida y al caso de uso base de datos llamando al caso contenida AbrirIncidente. Toda la informacinde uso enAbrirIncidente. Toda la informacinincluye el formulario del OficialCampo se contenida en el formulario del OficialCampo Controlador automticamente en el Incidente. El se incluye automticamente en el asignando recursos al selecciona una respuestaIncidente. El Controlador selecciona una respuesta asignando recursos incidente (con el caso de uso AsignarRecursos) al incidente (con recibo de uso AsignarRecursos) y da un acuse deel caso al informe de y da un acuse de recibo al informe de emergencia enviando un mensaje breve al emergencia OficialCampo. enviando un mensaje breve al OficialCampo. Estacin Estacin 5. El OficialCampo recibe el acuse de recibo y la OficialCampo OficialCampo 5. El OficialCampo recibe respuesta seleccionada. el acuse de recibo y la respuesta seleccionada.
ControlInformar Emergencia
Gestiona la funcin de informe de InformarEmergencia en la EstacinOficialCampo. Este objeto se crea cuando el OficialCampo selecciona el botn InformarEmergencia. Luego crea un FormularioInformeEmergencia y lo presenta al OficialCampo. Despus del envo del formulario crea un InformeEmergencia y se lo pasa al Controlador. El objeto de control luego espera la llegada de un acuse de recibo desde la EstacinControlador. Cuando llega el acuse de recibo, el objeto ControlInformarEmergencia crea un MensajeAcuseDeRecibo y la despliega ante el OficialCampo. Gestiona la funcin de informe de InformarEmergencia en la EstacinControlador. Este objeto se crea cuando se recibe un InformeEmergencia. Luego crea un FormularioIncidente y lo despliega ante el Controlador. Una vez que el Controlador ha creado un Incidente, le ha asignado Recursos y ha enviado un acuse de recibo, ControlAdministrarEmergencia enva el acuse de recibo a la EstacinOficialCampo. 75 / 125
ControlAdministrar Emergencia
modelado de interacciones entre objetos

diagramas de interaccin
representan el comportamiento del sistema desde la perspectiva de un solo caso de uso permiten ver cmo el sistema realiza un caso de uso o un escenario particular del caso de uso mostrando la distribucin de su comportamiento entre los objetos participantes dos tipos
diagramas de colaboracin diagramas de secuencia muestran casi la misma informacin (se pueden derivar directamente uno del otro con herramientas CASE)
BotnInformar Emergencia
: OficialCampo
FormularioInformar Emergencia
1: oprimir( )
oprimir( ) crear( ) crear( )
Bot nInformar Emergencia
2: crear( )
: OficialC ampo
4: cubrirContenido( ) 5: enviar( )
6: enviarInforme( )
cubrirContenido( ) enviar( ) enviarInforme( )
3: crear( )
FormularioInformar Emergencia
76 / 125

componentes de los diagramas de interaccin

objetos
BotnInformar Emergencia : Botn
se muestra como un rectngulo (o con un icono en funcin del estereotipo utilizado), que se etiqueta con el nombre del objeto y la clase a la que pertenece: nombreObjeto:nombreClase la clase tiene que figurar en el modelo de clases puede haber dos o ms objetos diferentes de una misma clase
enlaces (en los diagramas de colaboracin): los enlaces entre objetos son instancias de las asociaciones del modelo de clases. Por tanto, si hay enlace tiene que haber asociacin actores
aparecen los actores involucrados en el caso de uso tienen que aparecer en el diagrama de casos de uso puede haber varios actores, pero por lo general hay uno que inicia la accin
interacciones:
se muestra la secuencia de mensajes que pasan entre los distintos objetos aparecen junto a los enlaces e indican la direccin de la navegabilidad el objeto destino tiene que entender el mensaje, es decir, tiene que poder proporcionar la operacin adecuada
Bot nInformar Emergencia
2: crear( )
Cont rolInformar Emergencia
77 / 125

diagrama de secuencia
los enlaces no aparecen de forma explcita pero estn subyacentes en el intercambio de mensajes el tiempo pasa segn nos movemos de arriba abajo en el diagrama reglas para la realizacin de diagramas de secuencia
primera columna: actor que inicia el caso de uso segunda columna: objeto de interfaz que usa el actor para iniciar el caso de uso tercera columna: objeto de control que gestiona el resto del caso de uso los objetos de control son creados por objetos de interfaz que inician el caso de uso los objetos de interfaz son creados por objetos de control los objetos de entidad son accedidos por objetos de control y de interfaz los objetos de entidad nunca tienen acceso a los objetos de frontera o control (pueden utilizarse en distintos casos de uso, con diferentes objetos de interfaz y de control)
78 / 125
79 / 125

BotnInformar Emergencia : OficialCampo ControlInformar Emergencia
Formul arioInfo rmar Emergencia
Informe Emergencia
MensajeAcuse DeRecibo
ControlAdministr arEmergencia
Formulari o Incidente
Incidente
AcuseDeRecibo : Controlador
oprimir( ) crear( ) crear( )
cubrirContenido( ) enviar( ) enviarInforme( ) crear( ) enviarInformeAControlador( ) crear( ) crearIncidente( ) crear( ) enviarAcuseDeRecibo( ) crear( ) enviarAcuseDeRecibo( ) i nform eAcu seDe Reci bo( ) crear( ) ver ver
Al modelar el comportamiento del sistema se descubren los objetos AcuseDeRecibo y MensajeAcuseDeRecibo, lo que provoca cambios en la descripcin del caso de uso InformarEmergencia y en la relacin de objetos de entidad y de interfaz. fuente: Ingeniera del Software Orientado a Objetos, B.Bruegge y A.H. Dutoit, pp. 147-149 enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
80 / 125

diagrama de colaboracin
compuesto por
objetos: puede haber dos o ms objetos de una misma clase enlaces actores interacciones
se muestra la secuencia de mensajes que pasa entre los objetos (interacciones)

Men sajeAc use DeRecibo Inf orme Emergencia
18: v er
17: crear( )
7: crear( )
4: cubrirContenido( ) 5: env iar( ) FormularioInf ormar Eme rge nci a : Of icialCampo
6: env iarInf orme( )
8: env i arIn fo rmeA Contro lador( )
3: crear( ) 16: inf ormeAcuseDeRecibo( )
ControlAdministr arEmergencia
1: oprimir( ) 2: crear( ) Incidente 15: env iarAcuseDeRecibo( ) 9: crear( )
10: ver
BotnInf ormar Emergencia AcuseDeR ecibo
12: crear( )
Formulario Incidente
: Controlador 11: crearIncidente( ) 13: env iarAcuseDeRecibo( )
14: crear( )
81 / 125

mensajes desde un objeto a s mismo

socioBiblioteca
okTomarPrstamoLibro
socioBiblioteca
okTomarPrstamoLibro
eliminacin de comportamiento detallado: utilizacin de paquetes
82 / 125

comportamiento condicional
socioBiblioteca socioBiblioteca
libro
pedirPrstamo
okTomarPrestado
s i prs tamoPosible = s i tomarPrestado si no

prstamoDenegado
fin si
...
83 / 125
diseo de objetos con responsabilidades

Patrones GRASP (General Responsibility Assignment Software Patterns)

Describen los principios fundamentales del diseo de objetos y la asignacin de responsabilidades, expresados como patrones Cinco patrones
Experto en Informacin Creador Alta Cohesin Bajo Acoplamiento Controlador
84 / 125

Patrn Experto en informacin (asignacin de responsabilidades)

Problema: Qu principio general se puede seguir para asignar responsabilidades a los objetos? Solucin: asignar una responsabilidad al experto en informacin, es decir, a la clase que tiene la informacin necesaria para realizar la responsabilidad Localizacin de clases:
Buscar primero en el Modelo de Diseo, si hay clases relevantes Si no hay, buscar en el Modelo de Dominio y utilizar (o ampliar) las clases para crear las correspondientes clases de diseo
85 / 125

Ejemplo: en el sistema PDV se necesita conocer el total de una venta

Quin debera ser responsable de conocer el total de una venta?
86 / 125

87 / 125

Patrn Creador
Problema: Quin es el responsable de crear una nueva instancia de alguna clase? Solucin: se asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple uno o ms de los casos siguientes:
B agrega objetos de A B contiene objetos de A B registra instancias de objetos de A B tiene datos de inicializacin que se pasan a un objeto de A cuando es creado
La creacin de instancias es una de las actividades ms comunes en un sistema orientado a objetos Buena asignacin implica
Bajo acoplamiento Mayor claridad Mejor encapsulacin y reutilizacin
88 / 125

Ejemplo: quin debe crear una instancia de LineaDeVenta?

Solucin: Venta, pues agrega muchos objetos LineaDeVenta
89 / 125

Patrn Controlador
Problema: Quin controla un evento de entrada al sistema? Solucin: se asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase Controlador de caso de uso Evento de entrada al sistema: evento generado por un actor externo Controlador
objeto que no pertenece a la interfaz de usuario, responsable de recibir o manejar un evento del sistema recibe la solicitud de servicio desde la capa de IU y coordina su realizacin, normalmente delegando en otros objetos
Ventajas
Mayor potencial de reutilizacin: la lgica de la aplicacin no se encuentra en la capa de interfaz Razonamiento sobre el estado del caso de uso
90 / 125

91 / 125

92 / 125
Arquitecto
Disear una clase
identificacin de las clases del diseo

diseo orientado a objetos > diseo de casos de uso > identificacin de clases del diseo
Diagrama de clases parcial
clases que participan en la realizacin del caso de uso

estudiar las clases del anlisis que participan en la realizacin del caso de uso-anlisis, identificando las clases del diseo que poseen una traza hacia esas clases del anlisis estudiar requisitos especiales identificados en el caso de uso-anlisis, identificando las clases del diseo que realizan esos requisitos especiales identificacin de todas las clases necesarias diagrama de clases parcial: muestra las clases del diseo que participan en la realizacin del caso de uso
93 / 125

: A dmi nistra dor
: :OpcionesMantenCatlogo
: AltaArticulo
: F ormularioAltaArt culo
: ValidarArtculo
: ProcesarAltaArtculo
:Artculo
: MensajeResultado
Navegar Mostrar <<link>>
Mostrar
Introducir datos artculo
Validar artculo Si datos correctos Enviar datos
Introducir datos
Alta artculo( ) Si es correcto insertar Construir Mostrar
Si no es correcto insertar
Construir
Si datos i ncorrectos Mostrar mensaje error Fin Si
Fin Si
94 / 125

<<Client Page>> : OpcionesMantenCatlogo
<<link>>
AltaArtculo
<<include>> <<ClientScript Object>> ValidarArtculo
<<include>>
<<Form>> FormularioAltaArtculo <<submit>> <<build>> <<Server Page>> ProcesarAlt aA rt culo +insertar <<Client Page>> MensajeResultado
Diagrama de clases Diagrama de clases parcial parcial
Articulo
(from Logical View)
95 / 125
Arquitecto
Disear una clase
identificacin de subsistemas e interfaces

diseo orientado a objetos > diseo de casos de uso > identificacin de subsistemas e interfaces
identificar subsistemas e interfaces

a veces es til disear un caso de uso en trminos de los subsistemas y/o interfaces que participan en l pasos
<<subsistema diseo>> IU Comprador <<subsistema diseo>> Gestin de solicitudes de pago
Solicitud de pago
<<subsistema diseo> > Gestin de planificacin de pagos
<<subsistema diseo> > Gestin de facturas
estudiar las clases del anlisis que participan en las correspondientes realizaciones del caso de uso-anlisis, identificando (si existen) los paquetes del anlisis que contienen esas clases del anlisis. Despus, identificar los subsistemas del diseo que poseen una traza hacia esos paquetes del anlisis estudiar los requisitos especiales de las realizaciones de caso de uso-anlisis, identificando las clses del diseo que las realizan, si existen. Despus, identificar los subsistemas del diseo que contienen esas clases. mostrar los subsistemas que participan en una realizacin de caso de uso en un diagrama de clases parcial, mostrando:
las dependencias entre esos subsistemas y las interfaces que se utilicen en la realizacin del caso de uso
96 / 125
Arquitecto
Disear una clase
requisitos de implementacin
diseo orientado a objetos > diseo de casos de uso > requisitos de implementacin
captura de requisitos de implementacin

se incluye en la realizacin del caso de uso todos los requisitos identificados durante el diseo que deben tenerse en cuenta durante la implementacin, como los no funcionales ejemplo de requisito de implementacin del caso de uso Pagar Factura:
Un objeto de la clase Procesamiento de Solicitudes de Pago debera ser capaz de soportar 10 clientes de Comprador diferentes sin un retraso perceptible para cada uno de los compradores
97 / 125
diseo de clases
diseo orientado a objetos > diseo de clases
actividades
esbozar la clase del diseo
identificar operaciones identificar atributos identificar asociaciones y agregaciones identificar generalizaciones describir los mtodos describir estados tratar requisitos especiales
Disear una clase
98 / 125
clase del diseo

diseo orientado a objetos > diseo de clases
clase del diseo: abstraccin de una clase o construccin similar en la implementacin del sistema
el lenguaje utilizado para especificar la clase del diseo puede ser el que se utilizar para su implementacin se suele especificar la visibilidad de los atributos y las operaciones los mtodos de la clase tienen correspondencia directa con el correspondiente mtodo en la implementacin del cdigo de las clases
<<form>> Pedido
pueden incorporarse estereotipos que hagan corresponder la clase con una construccin especfica del lenguaje de programacin (por ejemplo, en VisualBasic, class module, form, user control,...) pueden indicarse interfaces si tiene sentido en el lenguaje de programacin (por ejemplo, una clase de diseo que se implementa como una clase Java)
99 / 125
Arquitecto
Disear una clase
esbozar clases de diseo

diseo orientado a objetos > diseo de clases > esbozar la clase del diseo
esbozar la clase del diseo

clases de interfaz
depende de la tecnologa de interfaz a utilizar. Por ejemplo, clases diseadas en Visual Basic implican clases del diseo estereotipadas como <<forms>> o <<controls>> de ActiveX en esta fase es esencial utilizar los prototipos de interfaz realizados anteriormente
clases de entidad con informacin persistente: su diseo requiere utilizar tecnologas de bases de datos especficas
adoptar una estrategia para hacer corresponder el modelo de diseo orientado a objetos con, por ejemplo, tablas en un modelo de datos relacional requiere trabajadores especficos (diseadores de bases de datos), actividades de diseo de bases de datos y modelos distintos (modelos entidad-relacin, por ejemplo)
clases de control: implica considerar diferentes aspectos

aspectos de distribucin (separacin de clases en diferentes nodos de una red, por ejemplo) aspectos de rendimiento aspectos de transaccin: los diseos deben incorporar cualquier tecnologa de gestin de transacciones existente que se est utilizando
las clases de diseo identificadas deben ser asignadas trazando dependencias a las correspondientes clases de anlisis que son diseadas
100 / 125
Arquitecto
Disear una clase
identificacin de operaciones
diseo orientado a objetos > diseo de clases > identificar operaciones
identificacin de las operaciones que necesitan las clases de diseo

Obj eto de negocio crea r() enviar() plan ifi car() cerrar()
descripcin de las operaciones utilizando la sintaxis de los lenguajes de programacin a utilizar, lo que incluye especificar la visibilidad de cada operacin (por ejemplo, en C++, public, protected, private) datos importantes a tener en cuenta en esta fase
responsabilidades de cualquier clase del anlisis que tenga una traza con la clase del diseo (una responsabilidad puede implicar una o varias operaciones) requisitos especiales de cualquier clase de anlisis que tenga una traza con la clase del diseo interfaces que la clase de diseo necesita proporcionar las realizaciones de caso de uso-diseo en las que la clase participa
Factura
101 / 125
Arquitecto
Disear una clase
identificacin de operaciones
diseo orientado a objetos > diseo de clases > identificar operaciones
Operaciones de la clase Factura Operaciones de la clase Factura La clase Factura participa en varias realizaciones de casos de uso, La clase Factura participa en varias realizaciones de casos de uso, como aquellas de Pagar Factura, Enviar Aviso yy Enviar Factura al como aquellas de Pagar Factura, Enviar Aviso Enviar Factura al Comprador. Cada una de estas realizaciones leen oo cambian ele Comprador. Cada una de estas realizaciones leen cambian ele stado de los objetos Factura. El caso de uso Enviar Factura al stado de los objetos Factura. El caso de uso Enviar Factura al Comprador crea yy enva facturas. El caso de uso Pagar Factura Comprador crea enva facturas. El caso de uso Pagar Factura planifica Facturas, yy as todos. Cada una de estas realizaciones de planifica Facturas, as todos. Cada una de estas realizaciones de casos de uso, por tanto, utiliza objetos Facutra de forma diferente; casos de uso, por tanto, utiliza objetos Facutra de forma diferente; en otras palabras, la clase Factura yy sus objetos desempean en otras palabras, la clase Factura sus objetos desempean distintos papeles en estas realizaciones de casos de uso. distintos papeles en estas realizaciones de casos de uso. Primero, los ingenieros de componentes pensaron en implementar Primero, los ingenieros de componentes pensaron en implementar estos cambios de estado como una operacin llamada setStatus, estos cambios de estado como una operacin llamada setStatus, que tena un parmetro que indicaba la accin deseada y el estado que tena un parmetro que indicaba la accin deseada y el estado destino (por ejemplo, setStatus(Planificada)). Pero entonces destino (por ejemplo, setStatus(Planificada)). Pero entonces decidieron que era preferible implementar operaciones explcitas decidieron que era preferible implementar operaciones explcitas para cada transicin de estados. Es ms, decidieron utilizar este para cada transicin de estados. Es ms, decidieron utilizar este enfoque no slo para la clase Factura, sino tambin para la clase enfoque no slo para la clase Factura, sino tambin para la clase Objeto de Negocio, de la cual es un subtipo la clase Factura. La Objeto de Negocio, de la cual es un subtipo la clase Factura. La clase Objeto de Negocio soporta de esta forma las siguientes clase Objeto de Negocio soporta de esta forma las siguientes operaciones (cada una de las cuales cambia el estado de Objeto de operaciones (cada una de las cuales cambia el estado de Objeto de Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estas Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estas operaciones son solamente operaciones virtuales que definen un operaciones son solamente operaciones virtuales que definen un patrn. Las clases que son subtipos de la clase Objeto de Negocio patrn. Las clases que son subtipos de la clase Objeto de Negocio tienen que definir cada una un mtodo concreto que realice estas tienen que definir cada una un mtodo concreto que realice estas operaciones. operaciones.
Obj eto de negocio crea r() enviar() plan ifi car() cerrar()
Factura
102 / 125
Arquitecto
Disear una clase
identificacin de atributos
diseo orientado a objetos > diseo de clases > identificar atributos
identificacin de atributos
utilizar la sintaxis del lenguaje de programacin considerar los atributos de cualquier clase de anlisis que tenga una traza con la clase de diseo (a veces implican ms de un atributo en la clase de diseo) los tipos de atributos estn restringidos por el lenguaje de programacin una instancia nica de atributo no puede ser compartida por varios objetos de diseo. Si fuera necesario, el atributo necesita ser definido en una clase separada si hay muchos atributos o son complejos los atributos de una clase se puede ilustrar sta en un diagrama de clases separado que muestre solamente el apartado de atributos
103 / 125
Arquitecto
Disear una clase
asociaciones, agregaciones y generalizaciones

diseo orientado a objetos > diseo de clases > identificar asociaciones y agregaciones
identificacin de asociaciones y agregaciones

estudiar la transmisin de mensajes en los diagramas de secuencia para determinar qu asociaciones son necesarias el nmero de relaciones debe estar minimizado, dando respuesta a las demandas de varias realizaciones de casos de uso en ocasiones hay que modelar rutas de bsqueda ptimas a travs de asociaciones y agregaciones para gestionar aspectos de rendimiento refinar la multiplicidad, nombres de rol,... segn el soporte del lenguaje de programacin utilizado
Objeto de negocio
identificacin de generalizaciones
deben ser utilizadas con la misma semntica definida en el lenguaje de programacin si el lenguaje no admite herencia, las asociaciones y/o agregaciones deben utilizarse en vez de la generalizacin
Factura
Pedido
104 / 125
Arquitecto
Disear una clase
mtodos y estados
diseo orientado a objetos > diseo de clases > descripcin de mtodos y estados
descripcin de los mtodos

creada
pueden especificarse algoritmos que se van a utilizar para realizar una operacin, en seudocdeigo o lenguaje natural la mayora de los mtodos no se especifican durante el diseo
enviar() pendiente
planificar planificada cerrar() [fuera de plaz o: retraso en fecha de pago] vencida y no pagada cerrar() cerrada
descripcin de estados
algunos objetos del diseo son estados controlados, es decir, sus estados determinan su comportamiento cuando reciben un mensaje se utilizan diagramas de estado para describir las transiciones de estado de un objeto
Los objetos Factura cambian de estado segn sean creados, enviados, Los objetos Factura cambian de estado segn sean creados, enviados, planificados o cerrados. Como todos los objetos de negocio, estos estados planificados o cerrados. Como todos los objetos de negocio, estos estados cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede ser planificada antes de haber sido enviada. ser planificada antes de haber sido enviada. Una factura se crea cuando un vendedor quiere que un comprador pague un Una factura se crea cuando un vendedor quiere que un comprador pague un pedido. Entonces la factura es enviada al comprador, y el estado cambia a pedido. Entonces la factura es enviada al comprador, y el estado cambia a pendiente. Cuando elcomprador decide pagar, el etado de la factur a pasa a pendiente. Cuando elcomprador decide pagar, el etado de la factur a pasa a planificada. Entonces, si el comprador no paga a tiempo, el estado de la factura planificada. Entonces, si el comprador no paga a tiempo, el estado de la factura pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el estado pasa a cerrada. estado pasa a cerrada.
105 / 125
Arquitecto
Disear una clase
requisitos especiales
diseo orientado a objetos > diseo de clases > requisitos especiales
requisitos especiales
estudiar los requisitos formulados en la realizacin de los casos de uso en los que la clase participa estudiar los requisitos especiales de cualquier clase de anlisis que tenga una traza con la clase de diseo algunos requisitos se posponen hasta la implementacin (requisitos de implementacin)
UnicastRemoteObject
Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Servidor del Comprador yy desde el Servidor del Vendedor. La Factura tiene que Servidor del Comprador desde el Servidor del Vendedor. La Factura tiene que ser diseada, pues, para un sistema dsitribuido. En este ejemplo se ser diseada, pues, para un sistema dsitribuido. En este ejemplo se implementa esta distribucin de objetos haciendo la clase Factura una subclase implementa esta distribucin de objetos haciendo la clase Factura una subclase de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la Invocacin de Mensajes Remotos (RMI). Este mecanismo de diseo est Invocacin de Mensajes Remotos (RMI). Este mecanismo de diseo est identificado yy descrito por el arquitecto en la actividad de diseo arquitectnico. identificado descrito por el arquitecto en la actividad de diseo arquitectnico. Ejemplo requisito de implementacin: Ejemplo requisito de implementacin: Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz de gestionar 10 clientes de Comprador diferentes sin un retardo de gestionar 10 clientes de Comprador diferentes sin un retardo perceptible para los compradores. perceptible para los compradores.
Factura
106 / 125
Diseo de un subsistema
actividades
definicin de las dependencias entre subsistemas definicin de las interfaces proporcionadas por el subsistema
Disear una clase
refinar los contenidos de los subsistemas
107 / 125
el diseo estructurado
Los modelos del anlisis facilitan la informacin necesaria para crear los modelos del diseo
Es
n ci rip Diagrama sc De EntidadRelacin

DICCIONARIO DE DATOS
de
en
es ad id t
Descripcin procedimental Descripcin procedimental de los componentes del de los componentes del software software
pe ci f i ca ci
de
Diagrama de Flujo de Datos
pr oc
es
os
Diseo procedimental Diseo de interfaz Diseo arquitectnico Diseo de datos MODELOS DEL DISEO MODELOS DEL DISEO
Cmo se comunica el Cmo se comunica el sistema consigo mismo, sistema consigo mismo, con otros sistemas y con con otros sistemas y con los operadores los operadores
Diagrama de Transicin de Estados
Especificacin de control
Relacin entre los Relacin entre los principales elementos principales elementos estructurales del programa estructurales del programa
MODELOS DEL ANLISIS MODELOS DEL ANLISIS
Estructuras de datos Estructuras de datos necesarias para necesarias para implementar el software implementar el software
108 / 125
conceptos del diseo estructurado

diseo estructurado > conceptos
jerarqua de control
Organizacin de los mdulos de un sistema. Jerarqua de control. No se representan necesariamente aspectos procedimentales Notacin: diagrama estructurado (Constantine) Profundidad: indica el nmero de niveles de control Anchura: indica el mbito global de control Grado de salida: nmero de mdulos controlados directamente por otro mdulo. Grado de entrada: nmero de mdulos que controlan directamente a un mdulo determinado. Visibilidad: conjunto de componentes que pueden invocarse o cuyos datos pueden ser usados por un componente dado, incluso aunque se haga indirectamente. Conectividad: conjunto de componentes que son invocados directamente o cuyos datos son usados por un componente determinado.
109 / 125
Conceptos del diseo estructurado

M
grado de salida
profundidad
q
grado de entrada
j
Anchura
110 / 125

PARTICIN ESTRUCTURAL PARTICIN ESTRUCTURAL Particin horizontal: Particin horizontal: ramas separadas para cada funcin ramas separadas para cada funcin principal. principal. Beneficios: facilidad de prueba Beneficios: facilidad de prueba yy mejora, mantenimiento, menos efectos mejora, mantenimiento, menos efectos secundarios. secundarios. Desventajas: mayor flujo de datos y Desventajas: mayor flujo de datos y control global del flujo del programa ms control global del flujo del programa ms complicado. complicado. Particin vertical (factoring): control y trabajo Particin vertical (factoring): control y trabajo distribuidos de manera descendiente en la distribuidos de manera descendiente en la arquitectura del programa. arquitectura del programa. Mdulos de nivel superior: control Mdulos de nivel superior: control yy poco procesamiento. poco procesamiento. Mdulos de nivel inferior: Mdulos de nivel inferior: procesamiento (entradas, clculos y procesamiento (entradas, clculos y salida) salida) Mejor capacidad de mantenimiento. Mejor capacidad de mantenimiento. Cambios en mdulos de control: ms Cambios en mdulos de control: ms probabilidad de propagar efectos probabilidad de propagar efectos secundarios, pero son menos habituales. secundarios, pero son menos habituales. Cambios en mdulos de trabajo: Cambios en mdulos de trabajo: habituales, pero con poca probabilidad de habituales, pero con poca probabilidad de propagar efectos secundarios. propagar efectos secundarios.
funcin 1
funcin 3
funcin 2 particin horizontal

mdulos de toma de decisiones
mdulos de trabajo
particin vertical
111 / 125

INDEPENDENCIA FUNCIONAL INDEPENDENCIA FUNCIONAL Consecuencia de la modularidad, la Consecuencia de la modularidad, la abstraccin la ocultacin de la informacin abstraccin yy la ocultacin de la informacin Mdulos con funcin nica y poca Mdulos con funcin nica y poca interaccin con otros interaccin con otros Ms fciles de mantener y probar Ms fciles de mantener y probar Menos efectos secundarios por Menos efectos secundarios por modificaciones modificaciones Reducida propagacin de errores Reducida propagacin de errores Facilita la reutilizacin Facilita la reutilizacin
ACOPLAMIIENTO
Medida de la interdependencia relativa entre los mdulos, y depende de la interfaz entre stos, es decir, de la cantidad y tipo de datos que comparten. Objetivo durante el diseo: minimizar el acoplamiento utilizando conexiones sencillas entre los mdulos. Formas de reducir el acoplamiento: Eliminando relaciones innecesarias Reduciendo las relaciones necesarias Beneficios de un bajo acoplamiento: Menor transmisin de defectos (efectos secundarios) Posibilidad de cambiar un mdulo sin incidir sobre otros En el mantenimiento de un mdulo no hay que tener en cuenta el contenido de otros
COHESIN
Medida del grado de fuerza funcional de un mdulo: cuanto menor sea el nmero de tareas (elementos de procesamiento) que realiza un mdulo, mayor ser su cohesin. Diferentes grados de cohesin: MDULO CON TAREA SIMPLE MDULO CON DIVERSAS TAREAS POCO O NADA RELACIONADAS CONCEPTOS CONCEPTOS COMPLEMENTARIOS COMPLEMENTARIOS
Maximizar la cohesin es Maximizar la cohesin es casi lo mismo que casi lo mismo que minimizar el acoplamiento minimizar el acoplamiento
112 / 125
acoplamiento en el diseo estructurado

ACOPLAMIENTO NORMAL ACOPLAMIENTO NORMAL De datos: dos mdulos se comunican por parmetros, siendo cada parmetro una De datos: dos mdulos se comunican por parmetros, siendo cada parmetro una porcin elemental de datos. porcin elemental de datos. Evitar datos que circulen sin necesidad. Evitar datos que circulen sin necesidad. Fomentar conexiones formadas por pocos datos. Fomentar conexiones formadas por pocos datos. Compuesto: un mdulo pasa al otro un dato compuesto. Compuesto: un mdulo pasa al otro un dato compuesto. Introduce una cierta conexin indirecta (Diccionario de Datos) Introduce una cierta conexin indirecta (Diccionario de Datos) Evitar datos compuestos con subdatos innecesarios. Evitar datos compuestos con subdatos innecesarios. Evitar agrupamientos de datos que no tienen nada en comn. Evitar agrupamientos de datos que no tienen nada en comn. De control: un mdulo pasa a otro informacin de control destinada a controlar la De control: un mdulo pasa a otro informacin de control destinada a controlar la lgica interna del segundo. lgica interna del segundo.
TIPOS DE TIPOS DE ACOPLAMIENTO ACOPLAMIENTO
ACOPLAMIENTO COMN ACOPLAMIENTO COMN Dos mdulos hacen referencia a una misma rea de datos globales. No es recomendable Dos mdulos hacen referencia a una misma rea de datos globales. No es recomendable por: por: Posibilidad de que los errores se trasladen de unos mdulos a otros. Posibilidad de que los errores se trasladen de unos mdulos a otros. Baja flexibilidad modular Baja flexibilidad modular Complica el mantenimiento Complica el mantenimiento Diferentes significados de los datos segn el mdulo que lo utilice Diferentes significados de los datos segn el mdulo que lo utilice Si se cambia un mdulo es difcil identificar los datos que hay que cambiar. Si se cambia un mdulo es difcil identificar los datos que hay que cambiar. Excepcin: BASES DE DATOS (no son voltiles, son diseadas con disciplinas Excepcin: BASES DE DATOS (no son voltiles, son diseadas con disciplinas especficas y las conexiones son restringidas y controladas, no aleatorias). especficas y las conexiones son restringidas y controladas, no aleatorias). ACOPLAMIENTO DE CONTENIDO ACOPLAMIENTO DE CONTENIDO Existe cuando un mdulo se refiere de algn modo al contenido de otro. Es ms habitual Existe cuando un mdulo se refiere de algn modo al contenido de otro. Es ms habitual en lenguajes de bajo nivel. en lenguajes de bajo nivel. Hay que evitarlo pues ataca al concepto de caja negra. Hay que evitarlo pues ataca al concepto de caja negra.
+
113 / 125
Grado de acoplamiento
cohesin en el diseo estructurado

elementos de procesamiento o tareas elementos de procesamiento o tareas se agrupan en base a algn tipo de se agrupan en base a algn tipo de pertenencia entre ellos. pertenencia entre ellos. La cohesin se aplica sobre todos los La cohesin se aplica sobre todos los pares de tareas pares de tareas
Principio asociativo: los Principio asociativo: los
mdulo Tarea o elemento de procesamiento: rdenes en el mdulo y procesos que resultan de llamadas a mdulos subordinados
Cohesin funcional: sus elementos contribuyen a la resolucin de una y slo una tarea. Cohesin secuencial: los datos de salida de una tarea sirven como datos de entrada para el siguiente elemento. Cohesin comunicacional: todos sus elementos operan sobre los mismos conjuntos de entrada y/o producen los mismos datos de salida. Cohesin procedural: las tareas efectan diferentes (y seguramente no relacionadas) actividades y se efectan en un orden determinado. Cohesin temporal: sus elementos desarrollan actividades que se relacionan en el tiempo. Cohesin lgica: las tareas desarrollan actividades de la misma clase, pero para utilizar el mdulo hay que seleccionar la/s actividades que se necesitan Cohesin casual: las tareas no tienen relacin significativa entre ellas enrique barreiro alonso universidade de vigo - departamento de informtica
Grado de cohesin
Las tareas que se encuentran dentro de un mdulo subordinado no figuran en la cohesin del mdulo que lo invoca escuela superior de ingeniera informtica ingeniera del software de gestin
114 / 125
Diseo procedimental Diseo de interfaz
el diseo de datos
diseo estructurado > diseo de datos
Diseo arquitectnico
Diseo de datos
Diseo de datos:
Profunda influencia en la calidad del software:
Influye en la estructura del programa Influye en la complejidad procedimental
Fundamentos: ocultacin de informacin y abstraccin de datos Actividades:

escoger estructuras de datos para los datos identificados en el anlisis. Identificar los mdulos del programa que deben operar directamente sobre las estructuras de datos
Principios del diseo de datos

1) Estudiar alternativas de estructuras de datos 2) Especificar las operaciones a llevar a cabo sobre los datos 3) Utilizacin del Diccionario de Datos 4) Retrasar las decisiones de bajo nivel 5) Representacin de los datos conocida slo por los mdulos que hacen uso directo de los datos en la estructura 6) Crear bibliotecas de estructuras de datos 7) Soporte del lenguaje para los tipos abstractos de datos
enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin 115 / 125
el diseo arquitectnico
diseo estructurado > diseo arquitectnico
Diseo arquitectnico
Diseo de datos
Objetivos:
En cierta forma, el diseo arquitectnico desarrolla los planos del programa
Desarrollar una estructura de programa modular Representar las relaciones de control entre los mdulos Combina la estructura del programa y la de datos, definiendo interfaces que permiten el flujo de datos a travs del programa
Diversos mtodos de diseo arquitectnico
116 / 125
Factura_Proveedor
Diseo arquitectnico
Diseo de datos
Pago_Cliente Pedido Cliente Detalles_Crdito
Confirmacin_Pedido Peticin_Comprobacin_Crdito 1 RECIBIR PEDIDO Cliente Stock 3
Producto_Stock
Pedido_Proveedor
GESTIONAR STOCK
Pago_Proveedor
Clientes
Direccin_Envo Producto_Devuelto 2 ENVIAR PEDIDO
Detalles_Pedido
Factura_Cliente Envo_Cliente Productos Devueltos Producto_Devuelto Direccin_Factura Cliente
Nmero_Empleado
Detalles_Pedido
Representante Ventas 4 RECIBIR DEVOLUCIONES Nombre_Empleado_y_Supervisor 5 GENERAR INFORMES VENTAS Project Name: Project Path: Chart File: Chart Name: Created On: Created By: Modified On: Modified By: Sample Yourdon process model c:\ecwin\samples\yddfd\ dfd0.dfd Process Orders Feb-18-1993 Wayne McDonald Dec-12-1993 EasyCASE Reintegro_Cliente
Polticas_Ventas_ y_Cuotas
Informe_Ventas Devolucin_Cliente
DISEO ORIENTADO DISEO ORIENTADO AL FLUJO DE DATOS AL FLUJO DE DATOS
FLUJO INFORMACIN (DFD)
DESCRIPCIN ESTRUCTURADA (Diagramas de estructura)
TIPOS DE FLUJOS: TIPOS DE FLUJOS:

1) De Transformacin: 1) De Transformacin: a) La informacin entra en el sistema a lo largo de caminos que transforman los datos a) La informacin entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno: flujo de entrada externos a un formato interno: flujo de entrada b) Esta informacin pasa a travs de un centro de transformacin b) Esta informacin pasa a travs de un centro de transformacin c) Los datos pasan por uno o ms caminos que conducen hacia fuera del software:flujo de c) Los datos pasan por uno o ms caminos que conducen hacia fuera del software:flujo de salida. salida. 2) De Transaccin: datos que se mueven a lo largo de un camino de entrada que convierte la 2) De Transaccin: datos que se mueven a lo largo de un camino de entrada que convierte la informacin exterior en una transaccin. sta se evala y, basndose en ese valor, se inicia el flujo a informacin exterior en una transaccin. sta se evala y, basndose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos posibles de accin. El proceso del que parten los caminos de lo largo de uno de muchos caminos posibles de accin. El proceso del que parten los caminos de accin se llama centro de transaccin. accin se llama centro de transaccin.
117 / 125
Diseo arquitectnico
Diseo de datos
Anlisis de transformacin
Revisar el modelo Revisar y refinar los DFDs Determinar las caractersticas de los DFDs Aislar el centro de transformacin Descomposicin inicial: establecer un controlador principal y otros controladores subordinados para entradas, transformaciones y salidas. Descomposicin de 2 nivel: convertir los procesos del DFD en los mdulos correspondientes de la estructura del programa. Se pueden convertir varios procesos en un mdulo, un proceso en varios mdulos,... Refinar (aplicar directrices de diseo)
118 / 125
Diseo arquitectnico
Diseo de datos
Anlisis de transaccin
Revisar el modelo Revisar y refinar los DFDs Determinar las caractersticas de los DFDs Identificar el centro de transaccin y las caractersticas del flujo de cada camino Descomponer y refinar la estructura y las ramas: el flujo de transaccin se convierte en una estructura de programa que contiene una rama de entrada y una rama de distribucin. sta contiene un mdulo distribuidor que controla todos los mdulos de accin subordinados. Cada flujo de accin se convierte en una estructura segn sus caractersticas. Refinar (aplicar directrices de diseo)
Transaccin
Centro de transaccin
119 / 125
Diseo arquitectnico
Diseo de datos
Optimizacin:
Representacin que satisfaga los requisitos FUNCIONALES y de RENDIMIENTO Simplicidad Aplicaciones de rendimiento crtico (entre el 10-20% del software ocupa el 50-80% del tiempo de procesamiento):
Disear y refinar sin ocuparse del rendimiento Simular el rendimiento en tiempo de ejecucin Seleccionar los mdulos que ocupen demasiado tiempo y redisearlos Codificar Aislar, redisear o recodificar para mejorar la eficiencia
120 / 125
Diseo procedimental
Diseo de interfaz
Diseo arquitectnico Diseo de datos
el diseo de interfaz
diseo estructurado > diseo de interfaz
Tres reas principales:

Diseo de interfaces entre los mdulos software (interfaz interna): depende de los datos que deben fluir entre los mdulos y las caractersticas del lenguaje de programacin. Diseo de interfaces entre el software y sistemas externos (interfaz externa): se evala cada entidad externa, determinando requisitos de datos y control de la misma, y se disean las interfaces externas adecuadas. Diseo de interfaces hombre-mquina
121 / 125
Diseo procedimental
Diseo de interfaz
MODELO DE DISEO: Representaciones de datos, arquitectnicas, de interfaces y procedimentales. El diseo de interfaz suele ser secundario con respecto a ste, excepto en sistemas altamente interactivos.
Diseador de interfaces
MODELO DE USUARIO: Perfil de los usuarios finales del sistema (edad, capacidades fsicas, estudios, nivel cultural, motivacin,...). Pueden ser usuarios novatos, espordicos o frecuentes.
PERCEPCIN DEL SISTEMA: imagen del sistema que percibe el usuario final. La exactitud de su descripcin depender de su perfil. Cuando coinciden, los usuarios se Cuando coinciden, los usuarios se sienten gusto con el software y lo sienten aa gusto con el software y lo utilizan eficazmente. utilizan eficazmente.
IMAGEN DEL SISTEMA: Combinacin del aspecto externo del sistema con toda la informacin de soporte que describen sintaxis y semntica del sistema.
122 / 125
Diseo procedimental
Diseo de interfaz
aspectos del diseo de interfaz persona-mquina

tiempo de respuesta
duracin variabilidad
mensajes de error
descripcin del problema informacin constructiva. consecuencias negativas posibles seal audible o visible evitar juicios al usuario
etiquetado de rdenes
poco habituales en entornos visuales rdenes para todas las opciones formato de las rdenes facilidad de aprendizaje y de recordar macros de rdenes convenios para uso en diferentes aplicaciones
ayuda al usuario
integrada agregada
123 / 125
Diseo procedimental
Diseo de interfaz
DIRECTRICES ENTRADA DE DATOS DIRECTRICES ENTRADA DE DATOS

DIRECTRICES PARA EL DISEO DIRECTRICES PARA EL DISEO DE INTERFACES HOMBRE - DE INTERFACES HOMBRE MQUINA MQUINA Minimizar nmero acciones entrada: reducir la Minimizar nmero acciones entrada: reducir la cantidad de escritura necesaria, usando el cantidad de escritura necesaria, usando el ratn, macros,... ratn, macros,... Consistencia visualizacin-introduccin Consistencia visualizacin-introduccin Personalizar entrada: rdenes personalizadas, Personalizar entrada: rdenes personalizadas, eliminar mensajes de advertencia yy eliminar mensajes de advertencia verificacin,... verificacin,... Interaccin personalizada: por ejemplo, escoger Interaccin personalizada: por ejemplo, escoger teclado oo ratn. teclado ratn. Desactivar rdenes inapropiadas Desactivar rdenes inapropiadas Eliminar entradas innecesarias: .00 en Eliminar entradas innecesarias: .00 en cantidades enteras, informacin disponible cantidades enteras, informacin disponible automticamente oo que se puede calcular,... automticamente que se puede calcular,...
DIRECTRICES VISUALIZACIN DIRECTRICES VISUALIZACIN

Informacin relevante en el contexto actual Informacin relevante en el contexto actual No abrumar con datos: usar grficos yy No abrumar con datos: usar grficos esquemas esquemas Mantener contexto visual Mantener contexto visual Etiquetas consistentes, abreviaciones Etiquetas consistentes, abreviaciones estndar yy colores predecibles estndar colores predecibles Mensajes de error significativos Mensajes de error significativos Uso de ventanas Uso de ventanas Presentaciones analgicas Presentaciones analgicas Geografa de la pantalla Geografa de la pantalla
DIRECTRICES INTERACCIN DIRECTRICES INTERACCIN

Consistencia de formato Consistencia de formato Respuestas significativas Respuestas significativas Verificacin de acciones destructivas Verificacin de acciones destructivas Deshacer acciones Deshacer acciones Eficiencia dilogo: distancia que debe moverse el ratn,... Eficiencia dilogo: distancia que debe moverse el ratn,... Autoproteccin del sistema ante errores Autoproteccin del sistema ante errores Cohesin rdenes yy acciones: organizacin de rdenes por tipo Cohesin rdenes acciones: organizacin de rdenes por tipo Ayudas sensibles al contexto Ayudas sensibles al contexto Verbos yy frases sencillos para las rdenes Verbos frases sencillos para las rdenes
bibliografa
C. Larman: UML y Patrones. Captulos 15 y 16 Jacobson, Booch, Rumbaugh: El Proceso Unificado de Desarrollo de Software. Captulo 9 I. Sommerville: Ingeniera del Software, Captulos 11, 12, 13 y 14
125 / 125

Segunda Clase Diseño de Sistemas y Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Segunda Clase Diseño de Sistemas y Software

Enviado por

Direitos autorais:

Formatos disponíveis

tema 4 diseo del software

introduccin y objetivos del diseo

resultado del diseo: modelo de diseo

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

evolucin del diseo de software

proceso continuo durante tres dcadas

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

calidad y diseo del software

concepto clave: CALIDAD un diseo de calidad:

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

calidad y diseo del software

Sin diseo de calidad:

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

conceptos esenciales del diseo

principios bsicos para el proceso de diseo (Davis, 1995)

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

conceptos esenciales del diseo

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

conceptos esenciales del diseo

Costes totales del software Costes o esfuerzo Coste de integracin

conceptos esenciales del diseo

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

proceso del diseo

fuente: Ingeniera de Software, I. Sommerville

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

proceso del diseo

Diseo de la estructura de datos Diseo de algoritmos

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

Sistema de visin <<subsistema>>

<<subsistema>> <<subsistema>> Sistema de embalaje

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

Modelado del control

salida del diseo arquitectnico: documento con diversas perspectivas de la arquitectura

Des compos icin modular

enrique barreiro alonso universidade de vigo - departamento de informtica

diseo arquitectnico y requisitos no funcionales

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

diseo arquitectnico: arquitectura

Modelado del control

Des compos icin modular

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

modelo de repositorio (o depsito)

traductor traductor de diseo de diseo

editor de editor de programas programas

generador degenerador informes de informes

escuela superior de ingeniera informtica ingeniera del software de gestin

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

una red que permite a los clientes acceder a los servicios

Servidor de Servidor catlogosde catlogos Catlogo Catlogo Cliente 1 Cliente 1

Servidor de Servidor imgenesde imgenes Fotografas Fotografas digitalizadas digitalizadas