Professional Documents
Culture Documents
enrique barreiro departamento de informtica universidade de vigo escuela superior de ingeniera informtica ingeniera del software de gestin
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 ...
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
2 / 125
3 / 125
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
4 / 125
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
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
enrique barreiro alonso universidade de vigo - departamento de informtica
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
10 / 125
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
11 / 125
diseo arquitectnico
tema 4 diseo del software
Los grandes sistemas se descomponen en subsistemas que proporcionan conjuntos de servicios relacionados
<<subsistema>>
<<subsistema>>
Sistema d e i dentificaci n de objetos
<<subsistema>> <<subsistema>>
Sistema de seleccin de embalajes
12 / 125
diseo arquitectnico
tema 4 diseo del software
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
diseo arquitectnico
tema 4 diseo del software
14 / 125
arquitectura o estructuracin:
identificacin de subsistemas o capas clave a desarrollar de forma independiente
Estructuracin del sistema
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
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo de depsito
Depsito de proyectos
analizador analizador de diseo de diseo enrique barreiro alonso universidade de vigo - departamento de informtica
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
tema 4 diseo del software
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
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor
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
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
modelo cliente/servidor
tema 4 diseo del software
Servidor de vdeos Servidor de vdeos Archivos de vdeos Archivos de vdeos INTERNET Cliente 2 Cliente 2
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
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor
Capa de presentacin
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
20 / 125
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor > modelo de cliente delgado
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
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor > modelo de cliente grueso
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
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
escuela superior de ingeniera informtica ingeniera del software de gestin 22 / 125
ATM ATM
ATM ATM
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor
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
Consultas SQL
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
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor
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
Interaccin HTTP
problemas
Cliente web
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
modelo cliente/servidor
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo cliente / servidor
Arquitectura
Aplicaciones Aplicaciones de sistemas heredados donde no es prctico separar el procesamiento de las aplicaciones y la administracin de datos.
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.
25 / 125
modelo en capas
tema 4 diseo del software
diseo arquitectnico > arquitectura > modelo en estratos
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
27 / 125
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:
Modelado del control
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
enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
28 / 125
control centralizado
tema 4 diseo del software
diseo arquitectnico > modelado del control > control centralizado
rutina 1 rutina 1
rutina 2 rutina 2
procesos de clculo
29 / 125
Proceso detector Proceso detector de movimiento de movimiento Estado del detector 560 Hz
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 () ; ( ... ) ( ... ) } }
30 / 125
31 / 125
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
subsistema subsistema 2 2
subsistema subsistema 3 3
subsistema subsistema 4 4
subsistema subsistema 5 5
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
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
fuente: Ingeniera de Software, I. Sommerville
ms complejas de disear que los sistemas cliente/servidor clsicos escuela superior de ingeniera informtica ingeniera del software de gestin
33 / 125
34 / 125
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
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
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
fuente: Ingeniera de Software, I. Sommerville
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
escuela superior de ingeniera informtica ingeniera del software de gestin
36 / 125
37 / 125
arquitecturas peer-to-peer
tema 4 diseo del software
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
enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
38 / 125
arquitecturas peer-to-peer
tema 4 diseo del software
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
n1 n1
n5 n5
fuente: Ingeniera del Software, Ian Sommerville
39 / 125
arquitecturas peer-to-peer
tema 4 diseo del software
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
arquitecturas peer-to-peer
tema 4 diseo del software
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
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
Publicar
Enlazar
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
43 / 125
Coordenadas GPS
Rene informacin
Comando de coordenadas GPS
44 / 125
arquitecturas de aplicaciones
tema 4 diseo del software
las empresas tienen necesidades similares de informacin (facturacin, recursos humanos, contabilidad,)
similares arquitecturas de las aplicaciones diferencias en las funcionalidades especficas
45 / 125
modelo arquitectnico simple pero suele corresponderse con una compleja arquitectura de datos Sistema Sistema
Entrada Entrada
Procesamiento Procesamiento
Salida Salida
46 / 125
IMPRESORA
Deduccin de la SS + nmero SS
47 / 125
normalmente son sistemas interactivos en los que el usuario realiza peticiones de servicios de forma asncrona
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
ATM
Base de Datos
ATM
49 / 125
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
51 / 125
Arquitectura de un sistema de gestin de documentos Interfaz del navegador web Interfaz del navegador web
Gestor de impresin
Identificacin de usuario
Entrega de recursos
Gestin de consultas
Registro de cuentas
Gestin 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
tema 4 diseo del software
diseo arquitectnico > descomposicin modular
descomposicin modular
despus de disear la arquitectura estructural se descomponen los subsistemas en mdulos
Estructuracin del sistema
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
53 / 125
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 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
54 / 125
diseo de la arquitectura
tema 4 diseo del software
diseo orientado a objetos > diseo de la arquitectura
diseo de la arquitectura
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
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 un subsistema
los arquitectos consideran distintas posibilidades de reutilizacin (partes de sistemas parecidos o de productos software generales)
55 / 125
internet
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
57 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
subsistemas
forma de organizar el modelo de diseo en piezas manejables
Capa especfica de la aplicacin
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
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 intermedia
59 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
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
Modelo de diseo
60 / 125
MODELO DE ANLISIS
MODELO DE DISEO
<<trace>>
<<trace>>
61 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
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
internet
Cliente comprador
Servidor comprador
Servidor vendedor
62 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
Java.applet
Java.awt
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
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
considerar cada producto software comprado como un subsistema independiente con interfaces explcitos para el resto de sistemas
63 / 125
Gestin facturas
dependencias
capa especfica de la aplicacin
deben definirse si hay relaciones entre los contenidos de unos subsistemas y otros
capa general de la aplicacin
Gestin de cuentas
Java.applet
Java.awt
Java.rmi
Navegador web
capa intermedia
TCP / IP
64 / 125
MODELO DE ANLISIS
Transferencias
65 / 125
SolicitudDePago
<<subsystem>> Gestin de planificacin de pagos
adems hay que identificar las operaciones que se pueden definir sobre las interfaces (se hace en el diseo de casos de uso)
66 / 125
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
escuela superior de ingeniera informtica ingeniera del software de gestin 67 / 125
68 / 125
: Objeto de Negocio
: Emisor
2: crearObjetoDeNegocio
: ControlProcesamientoEmisor
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
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
ControlProcesamie ntoEmisor
Objeto de negocio
ControlProcesamie ntoReceptor
: Receptor
IU Creacin de facturas
: Vendedor
ControlProcesamie ntoFacturas
Factura
Procesamiento SolicitudesPago
69 / 125
Diseo de la arquitectura
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 un subsistema
70 / 125
71 / 125
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
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.
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
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
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 ...
74 / 125
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
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
ControlInformar Emergencia
FormularioInformar Emergencia
1: oprimir( )
2: crear( )
: OficialC ampo
4: cubrirContenido( ) 5: enviar( )
ControlInformar Emergencia
6: enviarInforme( )
3: crear( )
FormularioInformar Emergencia
76 / 125
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
2: crear( )
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
Informe Emergencia
MensajeAcuse DeRecibo
ControlAdministr arEmergencia
Formulari o Incidente
Incidente
AcuseDeRecibo : Controlador
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
18: v er
17: crear( )
7: crear( )
ControlInformar Emergencia
3: crear( ) 16: inf ormeAcuseDeRecibo( )
ControlAdministr arEmergencia
10: ver
12: crear( )
Formulario Incidente
14: crear( )
81 / 125
socioBiblioteca
okTomarPrstamoLibro
82 / 125
comportamiento condicional
socioBiblioteca socioBiblioteca
libro
pedirPrstamo
okTomarPrestado
fin si
...
83 / 125
84 / 125
85 / 125
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
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
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
93 / 125
: :OpcionesMantenCatlogo
: AltaArticulo
: F ormularioAltaArt culo
: ValidarArtculo
: ProcesarAltaArtculo
:Artculo
: MensajeResultado
Mostrar
Introducir datos
Si no es correcto insertar
Construir
Fin Si
94 / 125
<<link>>
AltaArtculo
<<include>>
<<Form>> FormularioAltaArtculo <<submit>> <<build>> <<Server Page>> ProcesarAlt aA rt culo +insertar <<Client Page>> MensajeResultado
Articulo
(from Logical View)
95 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
Solicitud de pago
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
Ingeniero de componentes
Diseo de la arquitectura
requisitos de implementacin
tema 4 diseo del software
diseo orientado a objetos > diseo de casos de uso > requisitos de implementacin
Disear un subsistema
97 / 125
diseo de clases
tema 4 diseo del software
diseo orientado a objetos > diseo de clases
actividades
esbozar la clase del diseo
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseo de la arquitectura
identificar operaciones identificar atributos identificar asociaciones y agregaciones identificar generalizaciones describir los mtodos describir estados tratar requisitos especiales
Disear un subsistema
98 / 125
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
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
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)
las clases de diseo identificadas deben ser asignadas trazando dependencias a las correspondientes clases de anlisis que son diseadas
100 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
identificacin de operaciones
tema 4 diseo del software
diseo orientado a objetos > diseo de clases > identificar operaciones
Disear un subsistema
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
Ingeniero de componentes
Diseo de la arquitectura
identificacin de operaciones
tema 4 diseo del software
diseo orientado a objetos > diseo de clases > identificar operaciones
Disear un subsistema
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.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
Obj eto de negocio crea r() enviar() plan ifi car() cerrar()
Factura
102 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
identificacin de atributos
tema 4 diseo del software
diseo orientado a objetos > diseo de clases > identificar atributos
Disear un subsistema
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
Ingeniero de componentes
Diseo de la arquitectura
Disear un subsistema
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
Ingeniero de componentes
Diseo de la arquitectura
mtodos y estados
tema 4 diseo del software
diseo orientado a objetos > diseo de clases > descripcin de mtodos y estados
Disear un subsistema
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.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
105 / 125
Arquitecto
Ingeniero de componentes
Diseo de la arquitectura
requisitos especiales
tema 4 diseo del software
diseo orientado a objetos > diseo de clases > requisitos especiales
Disear un subsistema
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.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
Factura
106 / 125
Diseo de un subsistema
tema 4 diseo del software
actividades
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseo de la arquitectura
definicin de las dependencias entre subsistemas definicin de las interfaces proporcionadas por el subsistema
Disear un subsistema
107 / 125
el diseo estructurado
tema 4 diseo del software
Los modelos del anlisis facilitan la informacin necesaria para crear los modelos del diseo
Es
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
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
Especificacin de control
Relacin entre los Relacin entre los principales elementos principales elementos estructurales del programa estructurales del programa
Estructuras de datos Estructuras de datos necesarias para necesarias para implementar el software implementar el software
108 / 125
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
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.
enrique barreiro alonso universidade de vigo - departamento de informtica
funcin 1
funcin 3
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 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.
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
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
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
el diseo de datos
tema 4 diseo del software
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
el diseo arquitectnico
tema 4 diseo del software
diseo estructurado > diseo arquitectnico
Diseo arquitectnico
Diseo de datos
Objetivos:
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
116 / 125
el diseo arquitectnico
tema 4 diseo del software
diseo estructurado > diseo arquitectnico
Factura_Proveedor
Diseo arquitectnico
Diseo de datos
Producto_Stock
Pedido_Proveedor
GESTIONAR STOCK
Pago_Proveedor
Clientes
Detalles_Pedido
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
117 / 125
el diseo arquitectnico
tema 4 diseo del software
diseo estructurado > diseo arquitectnico
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
el diseo arquitectnico
tema 4 diseo del software
diseo estructurado > diseo arquitectnico
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
el diseo arquitectnico
tema 4 diseo del software
diseo estructurado > diseo arquitectnico
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
tema 4 diseo del software
diseo estructurado > diseo de interfaz
121 / 125
Diseo procedimental
Diseo de interfaz
Diseo arquitectnico Diseo de datos
el diseo de interfaz
tema 4 diseo del software
diseo estructurado > 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.
enrique barreiro alonso universidade de vigo - departamento de informtica
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
Diseo arquitectnico Diseo de datos
el diseo de interfaz
tema 4 diseo del software
diseo estructurado > diseo de interfaz
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
enrique barreiro alonso universidade de vigo - departamento de informtica escuela superior de ingeniera informtica ingeniera del software de gestin
123 / 125
Diseo procedimental
Diseo de interfaz
Diseo arquitectnico Diseo de datos
el diseo de interfaz
tema 4 diseo del software
diseo estructurado > diseo de interfaz
bibliografa
tema 4 diseo del software
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