segunda clase diseño de sistemas y software

tema 4 – diseño del software

enrique barreirodepartamento de informática

universidade de vigo

escuela superior de ingeniería informáticaingeniería del software de gestión


© enrique barreiro alonsouniversidade de vigo - departamento de informática


2 / 125

introducción y objetivos del diseño

diseño de sistemas: transformación del modelo de análisis en un modelo de diseño del sistema

se definen los objetivos de diseño del proyectose descompone el sistema en subsistemas más pequeños que pueden ser realizados por diferentes equiposse seleccionan estrategias para la construcción del sistema

plataforma de hardware y software en la que se ejecutaráel sistemaestrategia de almacenamiento de datos persistentesarquitectura estructural del sistemaflujo de control globalpolítica de control de accesocondiciones de interfaz...

resultado del diseño: modelo de diseñodescripción clara de las estrategiasdescomposición en subsistemasdiagramas que muestran la correspondencia entre hardware y softwaremodelo de objetos que describe la realización física de los casos de usomuestra el impacto en el sistema de requisitos funcionales, no funcionales y restriccionessirve de abstracción de la implementación del sistema, convirtiéndose en el input fundamental de las actividades de implementación

Ingeniería derequerimientos

Análisis

Modelo de casosde uso

:Modelo

Modelo deanálisis:Modelo

Diseño

Modelo dediseño

:Modelo




3 / 125

evolución del diseño de software

proceso continuo durante tres décadascriterios de desarrollo de programas modulares

refinamiento de arquitectura software top-down

programación estructurada

diseño estructurado

diseño orientado a objetos




4 / 125

calidad y diseño del software

concepto clave: CALIDAD

un diseño de calidad:proporciona representaciones del software en las que se puede evaluar la calidad

permite una “traducción” correcta de los requisitos en un programa

sirve como fundamento para las actividades posteriores (implementación, prueba y mantenimiento)

El principio de la sabiduría de un ingeniero del software es reconocer la diferencia entre conseguir que funcione un programa, y hacerlo bien.

M.A. Jackson, 1975

El principio de la sabiduría de un ingeniero del software es reconocer la diferencia entre conseguir que funcione un programa, y hacerlo bien.

M.A. Jackson, 1975




5 / 125

calidad y diseño del software

Sin diseño de calidad:Dificultades de gestión (el “destino cósmico” de los proyectos)

Sistemas poco satisfactorios e improductivos45% del tiempo en pruebas y corrección

Myers: se intenta resolver el problema apurando en el proceso de diseño para dejar tiempo suficiente al final del proyecto para corregir los errores cometidos por apurar en el proceso de diseño.

Sistemas poco fiables: pruebas poco fiables (“parece que funciona”) y sistemas que escapan al control de sus creadores.

Sistemas ineficientes: un buen diseño garantiza que se mantendrá el rendimiento a pesar de las modificaciones que se realicen.

Sistemas poco flexibles y difíciles de mantener:70% del coste en mantenimientoEl mantenimiento es caro:

1) Entender cómo funciona el sistema (o por qué no funciona)2) Diseñar la modificación3) Verificar el impacto4) Realizar la modificación5) Probar el sistema modificado6) Planificar, organizar, coordinar, medir y documentar estas

actividades

Los tres primeros casos se agravan con un mal diseñoLos tres primeros casos se

agravan con un mal diseño




6 / 125

conceptos esenciales del diseño

principios básicos para el proceso de diseño (Davis, 1995)1. Usar enfoques alternativos

2. Rastrear los requisitos en el diseño

3. Reutilizar si es posible

4. Representar la estructura del dominio del problema

5. Presentación uniforme e integrada

6. Estructurado para permitir cambios

7. Estructurado para degradarse poco a poco ante errores o circunstancias inusuales

8. Evaluación de la calidad del diseño mientras se realiza




7 / 125

ABSTRACCIÓN

- Procedimental- De datos- De control

ABSTRACCIÓN

- Procedimental- De datos- De control

REFINAMIENTO

La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarquía descomponiendo una abstracción procedimental para, paso a paso, llegar a los enunciados del lenguaje de programación

REFINAMIENTO

La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarquía descomponiendo una abstracción procedimental para, paso a paso, llegar a los enunciados del lenguaje de programación

- Requisitos familiares en el ámbito del problema

- Diseño arquitectónico

- Diseño procedimental

- Código

nive

les

deab

stra

cció

n

Conceptos complementarios

La abstracción permite especificar procedimientos y datos suprimiendo detalles de bajo nivel.El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.

La abstracción permite especificar procedimientos y datos suprimiendo detalles de bajo nivel.El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.





8 / 125


MODULARIDAD

- Componentes identificables y tratables por separado- Permite a un programa ser manejable intelectualmente- Criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:

Capacidad de descomposición modular

Capacidad de empleo de componentes modulares (reutilización)

Capacidad de comprensión modular (entender un módulo sin referencias a otros, o con las menos posibles)

Continuidad modular (cambios en módulos y con poco impacto)

Protección modular

MODULARIDAD

- Componentes identificables y tratables por separado- Permite a un programa ser manejable intelectualmente- Criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:

Capacidad de descomposición modular

Capacidad de empleo de componentes modulares (reutilización)

Capacidad de comprensión modular (entender un módulo sin referencias a otros, o con las menos posibles)

Continuidad modular (cambios en módulos y con poco impacto)

Protección modular

Número de módulos

M

Cos

tes

o es

fuer

zo

Costes totalesdel software

Coste/módulo

Coste deintegración

Región decostesmínimos

Fuente: Ingeniería del Software. Un enfoque práctico. R. S. Pressman




9 / 125

INDEPENDENCIA FUNCIONAL

• Consecuencia de la aplicación de conceptos como la modularidad, la abstracción y la ocultación de la información• Componentes con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización


• Consecuencia de la aplicación de conceptos como la modularidad, la abstracción y la ocultación de la información• Componentes con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización

COHESIÓN

Medida del grado de “fuerza funcional” de un componente: cuanto menor sea el número de tareas (elementos de procesamiento) que realiza un componente, mayor será su cohesión.Diferentes grados de cohesión:

COMPONENTE CONTAREA SIMPLE

COMPONENTE CON DIVERSASTAREAS POCO O NADARELACIONADAS

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 diseño: minimizar el acoplamiento utilizando conexiones sencillas entre los módulos.

Formas de reducir el acoplamiento:• Eliminando relaciones innecesarias• Reduciendo las relaciones necesarias

Beneficios de un bajo acoplamiento:• Menor transmisión de defectos (efectos secundarios)• Posibilidad de cambiar un componente (clase, subsistema, módulo,...) sin incidir sobre otros• En el mantenimiento de un componente no hay que tener en cuenta el contenido de otros


Conceptos complementariosMaximizar la cohesión es casi lo mismo que minimizar el acoplamiento

Conceptos complementariosMaximizar la cohesión es casi lo mismo que minimizar el acoplamiento




10 / 125

proceso del diseño

fuente: Ingeniería de Software, I. Sommerville




11 / 125

proceso del diseño

Diseño arquitectónicoIdentificación y documentación de los subsistemas que forman el sistema y sus relaciones

Especificación abstractaEspecificación de servicios y restricciones bajo los que funcionará cada subsistema

Diseño de la interfazDiseño y documentación de la interfaz de cada subsistema con otros subsistemas

Diseño de componentesAsignación de servicios a los componentes y diseño de sus interfaces

Diseño de la estructura de datos

Diseño de algoritmos




12 / 125

diseño arquitectónico

Los grandes sistemas se descomponen en subsistemas que proporcionan conjuntos de servicios relacionados

<<subsistema>>

Controlador del brazo

<<subsistema>>

Sistema de visión

<<subsistema>>

Sistema de identificación de objetos

<<subsistema>>

<<subsistema>>

Sistema de embalaje

<<subsistema>>Sistema de selección de embalajes

<<subsistema>>

Controlador del asidero

<<subsistema>>

Contro lador de cinta transportadora

<<subsistema>>




13 / 125


diseño arquitectónicoproceso inicial del diseño para identificar los subsistemas y establecer un marco de trabajo para el control y comunicación entre ellos

actividades principalesestructuración del sistema en varios subsistemas principalesmodelado del control entre las partes del sistemadescomposición modular: cada subsistema se descompone en módulos interconectados

salida del diseño arquitectónico: documento con diversas perspectivas de la arquitectura

modelo estructural estático: subsistemas o componentes a desarrollar como unidades separadasmodelo de proceso dinámico: organización del sistema en tiempo de ejecución, y que puede ser distinto al modelo estáticomodelo de interfaz: definición de los servicios ofrecidos por cada subsistema a través de su interfaz públicamodelos de relación: relaciones de, por ejemplo, el flujo de datos entre subsistemasmodelo de distribución: cómo se distribuyen los subsistemas entre los componentes físicos del sistema (computadores, nodos de red,…)

Estructuración del sistema

Modelado del control

Descomposición modular




14 / 125


diseño arquitectónico y requisitos no funcionalesla arquitectura puede estar en función 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 utilizarán pocos subsistemas con poca comunicaciónseguridad: las aplicaciones con elevado nivel de seguridad necesitarán estructurarse en capas con los recursos críticos protegidos en las capas más internas, que contarán con elevados nivel de validacióndisponibilidad: puede obligar a incluir componentes redundantes que puedan reemplazarse y actualizarse sin detener el sistemamantenibilidad: mejora cuando se utilizan componentes más pequeños, que pueden intercambiarse con facilidad




15 / 125

diseño arquitectónico: arquitectura

arquitectura o estructuración: identificación de subsistemas o capas clave a desarrollar de forma independiente

identificación de las relaciones entre subsistemas

efectivo para la comunicación entre los participantes en el proyecto y el reparto de tareas entre distintos grupos

modelos específicos de arquitecturamodelo de depósito o repositoriomodelo cliente/servidormodelo de máquina abstracta o en capas

diseño arquitectónico > arquitectura







16 / 125

modelo de repositorio

modelo de repositorio (o depósito)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 información corporativasistemas CAD y CASEsistemas de control de procesos...

editor de diseñoeditor de diseño generador de código

generador de código

editor de programaseditor de

programas

generador de informesgenerador

de informesanalizador de diseño

analizador de diseño

traductor de diseño

traductor de diseño Depósito de proyectos

arquitectura de un conjunto integrado de herramientas CASE

fuente: Ingeniería de Software, I. Sommerville,

arquitectura de un conjunto integrado de herramientas CASE

fuente: Ingeniería de Software, I. Sommerville,

diseño arquitectónico > arquitectura > modelo de depósito




17 / 125

modelo de repositorio

las herramientas compatibles con el modelo de datos se integran directamente

centralización de actividades de administración del depósito: respaldo, seguridad, control de acceso y recuperación de errores.

los subsistemas que producen datos no necesitan saber cómo son utilizados por otros subsistemas.

compartición eficiente de grandes cantidades de datos, sin necesidad de transmitir datos explícitamente de un subsistema a otro.

Ventajas

difícil distribuir el depósito en varias máquinas (problemas de inconsistencia y redundancia de los datos)

diferentes subsistemas pueden tener diferentes requerimientos de políticas de seguridad, recuperación y respaldo. El modelo de depósito impone la misma política a todos los subsistemas.

genera un gran volumen de información y es difícil hacer evolucionar el sistema.

los subsistemas deben estar acordes al modelo de depósito de datos, lo que lleva a un compromiso entre las necesidades específicas de cada herramienta, lo que puede afectar a cuestiones como el rendimiento.

difícil o imposible integrar subsistemas cuyos modelos de datos no se ajusten al esquema.

Inconvenientes

diseño arquitectónico > arquitectura > modelo de depósito




18 / 125

modelo cliente/servidor

modelo cliente/servidormodelo de sistemas distribuido que muestra cómo datos y procesamiento se distribuyen a lo largo de varios procesadores

componentesconjunto de servidores independientes que ofrecen servicios a otros subsistemas

servidores de impresiónservidores de administración de archivosservidores de bases de datos...

conjunto de clientesinvocan los servicios ofrecidos por los servidores mediante un protocolo de petición-respuesta (por ejemplo, http en la WWW)existen varias instancias de un programa cliente que se ejecuta de forma concurrentetienen 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 relación 1:1 entre procesos y procesadores: un computador servidor puede ejecutar varios procesos servidores (confusión entre servidor-proceso y servidor-computador)

diseño arquitectónico > arquitectura > modelo cliente / servidor




19 / 125


Servidor de catálogos

Servidor de catálogos

CatálogoCatálogo

Servidor de vídeosServidor de vídeos

Archivos de vídeosArchivos de vídeos

Servidor de imágenes

Servidor de imágenes

Fotografías digitalizadas

Fotografías digitalizadas

Servidor webServidor web

Páginas webPáginas web

INTE

RN

ET

Cliente 1Cliente 1

Cliente 2Cliente 2

Cliente 3Cliente 3

Cliente 4Cliente 4

Cliente 1Cliente 1




20 / 125


distintas arquitecturas cliente/servidortres capas lógicas

capa de presentación: se encarga de mostrar la información e interactuar con el usuario.capa de procesamiento de la aplicación: implementa la lógica de la aplicacióncapa de administración de datos: se refiere a todas las operaciones de la base de datos

modelo en dos capas físicas: la arquitectura más simple. La aplicación se organiza como un servidor (o varios idénticos) y un conjunto de clientes

modelo de “cliente delgado”todo el procesamiento de la aplicación y la administración de datos se realiza en el servidorel cliente únicamente ejecuta el software

modelo de “cliente grueso”el servidor sólo es responsable de la administración de datosel software del cliente implementa toda o gran parte de la lógica de la aplicación y las interacciones del usuario con el sistema


Capa de presentación

Capa de procesamiento de

la aplicación

Capa de administración de

datos




21 / 125


modelo de cliente delgadoutilizado 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 sencillossistemas basados en tecnologías web: los dispositivos de red ejecutan un navegador, que implementa la interfaz de usuariola aplicación misma actúa como servidor y maneja todo el procesamiento de la aplicación y administración de datos

desventajas implica una gran carga de procesamiento en el servidorel servidor realiza todos los cálculos, lo que provoca tráfico en la red entre cliente y servidor desaprovecha la capacidad de cálculo de equipos como los PCs

ClienteClienteServidor

Administrador de datosProcesamiento de la

aplicación

Servidor

Administrador de datosProcesamiento de la

aplicación

Presentación

diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente delgado




22 / 125


modelo de cliente gruesodistribuye al cliente procesamiento lógico de la aplicación y la presentación

aprovecha la capacidad de procesamiento disponible en los clientes

ejemplo: sistemas bancarios ATM (cajeros automáticos)

los ATM no se conectan directamente a la base de datos del cliente sino al gestor de transaccionesgestor de transacciones: sistema middleware que

organiza las comunicaciones con los clientes remotoscoloca 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

inconvenientesadministración del sistema más compleja al distribuirse la funcionalidad de la aplicación en diferentes computadoresmantenimiento: reinstalación en cada computador cliente si cambia la aplicación

diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente grueso

ClienteProcesamiento de las

aplicaciones y presentación

ClienteProcesamiento de las

aplicaciones y presentaciónServidor

Administrador de datos

Servidor

Administrador de datos

ATMATM

ATMATM

ATMATM

Monitor de teleprocesa-

miento

Base de datos de cuentas

Servidorde cuentas




23 / 125


problemas del enfoque de dos capas físicaslas tres capas lógicas (presentación, procesamiento y administración de datos) deben asociarse a dos sistemas de cómputo

problemas de escalabilidad y rendimiento en el modelo de cliente delgado

problemas de administración del sistema en el modelo de cliente grueso

alternativa: utilizar tres capas físicaslas tres capas lógicas son procesos separados lógicamente

no implica la existencia de tres sistemas de cómputo conectados a la red pero si es necesario se pueden separar fácilmente y ejecutar en procesadores separados

son más escalables que las arquitecturas de dos niveles

ejemplo: sistema bancario en Internet:administración de datos: suministrado por la base de datos del banco (normalmente en un mainframe)servicios de aplicación (transferencias, consulta de movimientos, pago de facturas,...) suministrados por un servidor Webpresentación: el cliente es el computador del usuario con un navegador websistema escalable: se pueden añadir fácilmente servidores web cuando aumenta el número de clientes

Consultas SQL

Clientes webClientes web

Interacción HTTP


Provisión del servicio de la cuenta

Servidorweb

Provisión del servicio de la cuenta

Servidorweb

SQLBase de datos de cuentas

Servidorde cuentas




24 / 125


Código móvil: applets de Java y controles ActiveX

permiten implementar un modelo cliente/servidor a medio camino entre los de cliente delgado y grueso

funcionamientoparte del software de procesamiento se descarga en el cliente como applet, aligerando la carga del servidorla interfaz de usuario se construye utilizando un navegador Web que ejecuta los applets o los controles ActiveX

problemasdiferencias en las implementaciones de Java en navegadores de distintos fabricantesnecesidad de una velocidad de transmisión aceptable para descargar los appletsproblemas de seguridadlibertad de configuración por el usuario


Administración datosProcesamiento aplicación

Servidorweb

PresentaciónEjecución applets

Clienteweb

Interacción HTTP




25 / 125


C/S de tres capas o múltiples capas

C/S de dos capas con clientes gruesos

C/S de dos capas con clientes delgados

Arquitectura

Aplicaciones de gran escala con cientos o miles de clientes.

Aplicaciones donde tanto los datos como la aplicación son volátiles.

Aplicaciones donde se integran datos de diversas fuentes.

Aplicaciones con procesamiento de datos computacionalmenteintensivo (por ejemplo, visualización de datos, animaciones gráficas,...)

Aplicaciones con funcionalidad para el usuario final relativamente estable utilizadas en un entorno con administración de sistemas bien establecido.

Aplicaciones de sistemas heredados donde no es práctico separar el procesamiento de las aplicaciones y la administración de datos.

Aplicaciones computacionalmente intensivas como los compiladores con poca o ninguna administración de datos.

Aplicaciones intensivas en datos (navegar y consultar) con poco o ningún procesamiento de la aplicación.

Aplicaciones





26 / 125

modelo en capas

modelo en capas o de máquina abstracta

modela la interacción entre los subsistemas organizando un sistema en una serie de capas

cada capa presta servicios a la capa inmediatamente superior y actúa como cliente de la que queda encerrada

el diseño incluye los protocolos que establecen cómo interactuará cada par de capas

arquitectura cambiable y portable: preservando la interfaz, una capa se puede reemplazar por otracuando cambian las interfaces de las capas sólo afecta a la capa adyacente

desventajasdifícil estructurar los sistemas pues es posible que el usuario requiera acceso a capas internas (p.ej., bases de datos) lo que subvierte el modeloel rendimiento puede resultar afectado por los múltiples niveles de interpretación de órdenes que se requieren a veces

Gestión de configuraciones del sistema

Gestión de objetos del sistema

Base de datos del sistema

Sistema operativo

diseño arquitectónico > arquitectura > modelo en estratos

Usuarios

Modelo de capas de un sistema de gestión de versiones.Fuente: Ingeniería del Software, I. Sommerville




27 / 125

modelo en capas: ejemplos

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

MEDIOS DE COMUNICACIÓN

Red

Enlace de datos

Física

Arquitectura de red OSI

Aplicación

Transporte

Interred

Host a red

TELNET FTP SMTP DNS

TCP UDP

IP

ARPANET INTERNET SATNET LAN

Arquitectura de red TCP/IP

Interconexión física

Transferencia de datos

Transferencia de información delas aplicaciones

diseño arquitectónico > arquitectura > modelo en estratos




28 / 125

diseño arquitectónico: modelado del control

modelos de controlrepresentan 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 genéricos:control centralizado: un subsistema es el responsable de controlar, iniciar y detener otros subsistemas. También 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

diseño arquitectónico > modelado del control







29 / 125

control centralizado

sistemas de control centralizadoun subsistema tiene la responsabilidad de controlar el sistema y administrar la ejecución de otros subsistemas

dos clases, según se ejecuten secuencialmente o en paralelo

modelo de llamada-retorno (ejecución secuencial): el control se inicia en la parte superior de una jerarquía y por medio de llamadas a subrutinas pasa a los niveles del árbolno es un modelo estructural, por lo que no es necesario, por ejemplo, que la Rutina 1.1. forme parte de la Rutina 1sólo se aplica a sistemas secuencialesutilizado por lenguajes de programación como Ada, Pascal y C, aunque también en lenguajes OO.ventaja: es relativamente sencillo analizar los flujos de control y conocer cómo responderá el sistema a cierto tipo de entradasinconveniente: las excepciones a operaciones normales son complicadas de gestionar

modelo del administrador: se aplica a los modelos concurrentes un componente del sistema se designa como administrador y controla el inicio, detención y coordinación del sistema según las variables de estado del sistema. Verifica si otros procesos han producido información para procesar o si ha que pasarles información para el procesamiento.un proceso es un subsistema o módulo que se ejecuta en paralelo con otros procesosutilizado en sistemas de tiempo real “suaves” (con restricciones de tiempo no muy estrictas)

programaprincipal

programaprincipal

rutina 1rutina 1 rutina 2rutina 2 rutina 3rutina 3

rutina 1.1rutina 1.1 rutina 1.2rutina 1.2 rutina 3.1rutina 3.1 rutina 3.2rutina 3.2

procesosdel sensor

controladorsistema

controladorsistema

procesosdel actuador

procesosde cálculo interfaz de

usuariointerfaz de

usuario controladorde fallos

controladorde fallos

diseño arquitectónico > modelado del control > control centralizado





30 / 125

control centralizado: ejemplo

Proceso detector de movimiento

Proceso detector de movimiento Proceso sensor de

puertasProceso sensor de

puertas Proceso sensor de ventanas

Proceso sensor de ventanas

Proceso de monitorización

edificio

Proceso de monitorización

edificio

Proceso del sistema de alarma

Proceso del sistema de alarma

400 Hz 60 Hz 100 Hz

560 Hz

Número de habitación

Estado del sensorEstado del sensorEstado del detector class BuildingMOnitor extends Thread {

BuildingSensor win, door, move ;

Siren siren = new Siren () ;Lights lights = new Lights () ;DoorSensors doors = new DoorSensors (30) ;

( ... )

BuldingMonitor(){

//inicializar sensores e iniciar procesos( ... )}public void run (){

int room = 0 ;while (true){//sondear movimiento sensores (400Hz)move = movements.getVal () ;

( ... )

}

class BuildingMOnitor extends Thread {

BuildingSensor win, door, move ;

Siren siren = new Siren () ;Lights lights = new Lights () ;DoorSensors doors = new DoorSensors (30) ;

( ... )

BuldingMonitor(){

//inicializar sensores e iniciar procesos( ... )}public void run (){

int room = 0 ;while (true){//sondear movimiento sensores (400Hz)move = movements.getVal () ;

( ... )

}


diseño arquitectónico > modelado del control > control centralizado

Ejemplo del modelo del administrador centralizado




31 / 125

control dirigido por eventos

sistemas de control dirigido por eventosse rigen por eventos generados en el exterior (señal de un sensor, comando desde un menú,…)

diferentes tipos de sistemas dirigidos por eventoshojas de cálculo (el valor cambiante de las celdas provoca que otras se modifiquen)sistemas de producción basados en reglas (por ejemplo, de Inteligencia Artificial) en los que una condición que se convierte en verdadera provoca que se dispare una acciónobjetos activos, en los que el cambio de valor de un atributo del objeto dispara algunas acciones

dos tipos de modelos principalesmodelos de transmisión (broadcast): los subsistemas registran un interés en eventos específicos y cuando ocurren el control se transfiere al subsistema que puede manejar el eventomodelos dirigidos por interrupciones: especialmente útiles para sistemas de tiempo real que necesitan manejar rápidamente eventos generados en el exterior

diseño arquitectónico > modelado del control > control dirigido por eventos




32 / 125

control por eventos: modelos de transmisión

modelos de transmisiónse diferencia del modelo del administrador en que la política 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 evolución es relativamente sencilla pues se pueden integrar nuevos subsistemas registrando sus eventos en el controlador de eventoscualquier subsistema puede activar otros subsistemas sin conocer su nombre o ubicaciónlos subsistemas se pueden incrementar en máquinas distribuidas, de forma transparente para otros subsistemas

desventaja: los subsistemas no saben si los eventos se manejarán ni cuando lo haráncuando un subsistema genera un evento no sabe qué otros subsistemas han registrado un interés en ese evento

Controlador de eventos y mensajes

subsistema1

subsistema1 subsistema

2subsistema

2 subsistema3

subsistema3

subsistema4

subsistema4 subsistema

5subsistema

5

diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión





33 / 125

modelos de transmisión: objetos distribuidos

modelos de transmisión: arquitecturas de objetos distribuidos

consiste en eliminar la distinción entre cliente y servidor y diseñar 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 suministranotros objetos llaman a estos servicios sin ninguna distinción lógica entre un cliente (receptor de un servicio) y un servidor (proveedor de un servicio)

funcionamientolos objetos se distribuyen a lo largo de varios computadores sobre una red se comunican a través de middleware (una especie de “bus de software” que provee un conjunto de servicios que permiten comunicación, agregación y destrucción de objetos del sistemamiddleware: agente de solicitud de objetos (ORB, Object RequestBroker) y provee una interfaz transparente entre objetos

ventajaspermite retrasar las decisiones sobre dónde y cómo se deben suministrar los servicios pues los objetos proveedores de servicios se pueden ejecutar en cualquier nodo de la redarquitectura abierta: permite agregar nuevos recursos si es necesario pues los estándares del ORB (p.ej., CORBA) se han desarrollado para permitir la comunicación y servicios entre objetos escritos en diferentes lenguajessistema flexible y escalable: se pueden crear diferentes instancias del sistema con el mismo servicio suministrado por objetos diferentes o por réplicas de objetos para hacer frente a diversas cargas del sistema

desventajasmás complejas de diseñar que los sistemas cliente/servidor clásicos

ORB

diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos


o1

s(o1)

o2

s(o2)

o3

s(o3)

o4

s(o4)

o5

s(o5)




34 / 125


utilización de una arquitectura de objetos distribuidoscomo modelo lógico para estructurar y organizar el sistema

se piensa únicamente en cómo proveer de funcionalidad a la aplicación (servicios y combinaciones de servicios)identificación de cómo suministrar los servicios utilizando varios objetos distribuidos

objetos de “grano grueso” (también llamados “objetos de negocio”) que suministran servicios específicos 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 lógico del sistema es un modelo c/s en el que clientes y servidores se realizan como objetos distribuidos que se comunican a través del ORBel sistema se puede cambiar fácilmente de dos capas a uno de múltiples capas (implementando el servidor o el cliente como un objeto compuesto de varios objetos pequeños que suministran servicios especializados)





35 / 125


ejemplo de arquitectura de objetos distribuidos

sistema de minería de datos que busca relaciones entre datos almacenados en varias bases de datos diferentes

cada base de datos se encapsula como un objeto distribuido con una interfaz que suministra acceso de sólo lecturalos objetos integradores recolectan información de todas las bases de datos para tratar de deducir relaciones específicas (cada uno tiene su especialidad, como variaciones por temporadas, relaciones entre tipos de bienes,...)los objetos visualizadores interactúan con los integradores para visualizar o generar informes

la arquitectura de objetos distribuidos es más adecuada para este tipo de aplicaciones que una c/s

el modelo lógico del sistema no es suministrar información proporcionada por diferentes servicios de administración de datos (como en los ATM)el número de bases de datos se puede incrementar sin perturbar el sistema pues son objetos distribuidos que pueden residir en diferentes máquinasse pueden explorar nuevos tipos de relaciones agregando nuevos objetos integradores que no necesitan conocer a los ya existentes

Base de datos 1

Base de datos 2

Base de datos 3

Integrador 1

Integrador 2

generador informes

pantalla

visualizador






36 / 125

control por eventos: modelos dirigidos por interrupciones

modelos dirigidos por interrupcionesútiles para

sistemas de tiempo real que necesitan manejar muy rápidamente eventos generados en el exterior (por ejemplo, sistemas de seguridad en automóviles)combinado con el modelo de administrador centralizado: el administrador central maneja la ejecución normal del sistema utilizando el control basado en interrupciones para casos de emergencia

interrupcionesexisten varios tipos de interrupciones conocidas con un controlador definido para cada tipocada tipo de interrupción se asocia con la ubicación de memoria en la que se almacena la dirección del controladorcuando se recibe una interrupción de un determinado tipo, un interruptor de hardware transfiere el control al controlador adecuadoel controlador puede iniciar o detener otros procesos en respuesta a los eventos recibidos por el interruptor

ventaja: permite dar respuestas rápidas a los eventos

desventajascomplejo de programar y difícil de validarsi el número de interrupciones está limitado por el hardware, cuando se alcanza el límite no se pueden gestionar más tipos de eventos (se pueden asignar distintos tipos de eventos a una interrupción, dejando que el controlador detecte qué evento ha ocurrido, pero disminuye el rendimiento

interrupciones

vector deinterrupción

controlador1

controlador1 controlador

2controlador

2 controlador3

controlador3 controlador

4controlador

4

proceso1

proceso1 proceso

2proceso

2 proceso3

proceso3 proceso

4proceso

4

diseño arquitectónico > modelado del control > control dirigido por eventos > modelos dirigidos por interrupciones





37 / 125

computación distribuida interorganizacional

Computación distribuida interorganizacionalPor seguridad e interoperabilidad se ha utilizado sobre todo computación distribuida intraorganizacional

Servidores dentro de la misma organizaciónFacilidad de aplicación de estándares locales y procesos operacionales

Modelos más recientes de computación distribuida interorganizacional

Computación peer-to-peer (p2p)Sistemas orientados a servicios




38 / 125

arquitecturas peer-to-peer

Sistemas peer-to-peer (p2p)Sistemas descentralizados:

los cálculos se pueden realizar en cualquier nodo de la redno se distingue, a priori, entre clientes y servidores

Sistemas diseñados para aprovechar la ventaja de potencia computacional y disponibilidad de almacenamiento de grandes redes

Estándares y protocolos de comunicaciones embebidos en la propia aplicación y cada nodo ejecuta una copia de la aplicación

Usados sobre todo en sistemas personales Compartición de ficheros (Gnutella, Kazaa, eMule,…)Sistemas de mensajería instantánea (ICQ, Messenger,…)Otras aplicaciones (SETI@home, Freenet,…)

Comienza a utilizarse en entornos corporativos para aplicaciones con grandes necesidades computacionales (Intel, Boeing,…)

Problemas: protección, autentificación,…Utilización en sistemas de información no críticos o cuando existen relaciones de trabajo entre las organizaciones




39 / 125


teóricamente, 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

n1n1

n2n2

n4n4

n3n3

n5n5

n9n9

n6n6

n7n7

n8n8

n10n10n11n11

n12n12

n13n13

n14n14

fuente: Ingeniería del Software, Ian Sommerville




40 / 125


arquitectura p2p descentralizadalos nodos de red actúan como interruptores de comunicaciones, encaminando datos y señales de control entre nodos.

búsqueda de un documentose envía comando de búsqueda a los nodos de la localidadlos nodos comprueban si tienen el documentosi lo tienen, lo devuelven al solicitantesi no lo tienen, encaminan la búsqueda a otros nodosal 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

desventajassobrecargas (la misma búsqueda es realizada por muchos nodos)replicaciones de comunicaciones entre nodos




41 / 125


arquitectura p2p semicentralizadanodos que actúan como servidores para facilitar las comunicaciones entre nodos

establecimiento de contactos entre nodoscoordinación de cálculos

una vez que se localizan los nodos disponibles se establecen comunicaciones directas y no es necesaria la conexión con el servidor

n1n1

n2n2

n4n4n3n3

n5n5

n6n6

Buscador deservicios





42 / 125

arquitectura de sistemas orientados a servicios

servicio webrepresentación estándar para cualquier recurso computacional o de información que pueda ser usado por otros programas

permite que la provisión de un servicio sea independiente de la aplicación que lo utiliza

las organizaciones pueden hacer accesible información a diferentes programas definiendo y publicando una interfaz de servicio web, que define

los datos disponiblescómo 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

Registro deservicios

Registro deservicios

Suministradorde servicios

Suministradorde servicios

Solicitante deservicios

Solicitante deservicios ServicioServicio

PublicarBuscar

Enlazar




43 / 125


algunas ventajaslos usuarios pueden pagar por los servicios sólo en función del uso

aplicaciones más pequeñas (manejos de excepciones como servicios externos)

construcción a medida de nuevos servicios, enlazando servicios existentes

estándares basados en XMLSOAP (Simple Object Access Protocol): define una organización para intercambio de datos estructurados entre servicios web

WSDL (Web Services Description Language): define cómo pueden representarse las interfaces de servicios web

UDDI (Universal Description, Discovery and Integration): estándar de búsqueda que define cómo puede organizarse la información de descripción de servicios




44 / 125


Reúne información

Servicio de información móvil

Recibe un flujo de información desde

los servicios

Receptor

Envía la posición y la petición de

información al servicio

Transmisor

Recibe peticiones del usuario

Interfaz de usuario

Traduce la información digital

a señal de radio

Radio

Encuentra la posición del

vehículo

Localizador

Encuentra un servicio disponible

Buscador de servicios

Información del tráfico de carreteras

Localizador decarreteras

Localizador decarreteras

Informaciónde tráfico

Informaciónde tráfico

Coordenadas GPS

Información deutilidades

Información deutilidades

Informacióndel tiempo

Informacióndel tiempo

Coordenadas GPS

Coordenadas GPS

Sistema software de vehículos

TraductorTraductorInformacióndel lenguaje

Comando decoordenadas

GPS





45 / 125

arquitecturas de aplicaciones

las empresas tienen necesidades similares de información (facturación, recursos humanos, contabilidad,…)

similares arquitecturas de las aplicaciones

diferencias en las funcionalidades específicas

arquitecturas genéricas según el tipo de aplicaciónaplicaciones de procesamiento de datos

procesamiento de datos por lotes con poca o nula interacción del usuario

aplicaciones de procesamiento de transaccionesprocesan peticiones del usuario para obtener información y para actualizar información en una base de datos

sistemas de procesamiento de eventosaplicaciones controladas por órdenes del usuario o cambios en valores de variables (juegos, hojas de cálculo, presentación de información,…)

sistemas de procesamiento de lenguajes




46 / 125

arquitecturas de aplicaciones: sistemas de procesamiento de datos

sistemas de procesamiento de datosdan soporte a parte del negocio como pago de nóminas, cálculo e impresión de facturas, renovación de suscripciones o pólizas,…

trabajan con grandes bases de datos

componentesentrada: reúne entradas desde una o más fuentesprocesamiento: realiza cálculos utilizando las entradassalida: genera salidas para ser escritas en la base de datos y/o impresas

modelo arquitectónico simple pero suele corresponderse con una compleja arquitectura de datos

SistemaSistema

EntradaEntrada ProcesamientoProcesamiento SalidaSalida

Base de datosBase de datos




47 / 125

arquitecturas de aplicaciones: sistemas de procesamiento de datos

Registros de empleados

Registros de empleados

Datos de pagos

mensuales

Datos de pagos

mensuales

Leer registro de empleadoLeer registro de empleado

Leer datos de pagos mensuales

Leer datos de pagos mensuales

Validar datos de empleado

Validar datos de empleado

Calcularsalario

Calcularsalario

Escribir transacciones de impuestos

Escribir transacciones de impuestos

Escribir datosde pensiones

Escribir datosde pensiones

Imprimirnómina

Imprimirnómina

Escribir transacción bancaria

Escribir transacción bancaria

Escribir datos de la Seguridad Social

Escribir datos de la Seguridad Social

Transacciones de impuestos

Transacciones de impuestos

Datos de pensionesDatos de pensiones

Transacciones del banco

Transacciones del banco

Datos de la Seguridad Social

Datos de la Seguridad Social

IMPRESORA

Información depagos

Registro deempleado

Registro válidode empleado

Tasas de pagos mensuales

Tasas de pagos mensuales

Tablas de impuestosTablas de impuestos

Pensión deducible + número SS

Gasto deducible +número SS + oficinatributaria

Datos del empleado +deducciones

Pago neto + informaciónde cuenta bancaria

Deducción de la SS +número SS





48 / 125

arquitecturas de aplicaciones: sistemas de procesamiento de transacciones

sistemas de procesamiento de transaccionesprocesan peticiones de usuario para obtener información o para actualizar una base de datos

transacción 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 automático

normalmente son sistemas interactivos en los que el usuario realiza peticiones de servicios de forma asíncrona

Procesamiento de E/S

Procesamiento de E/S

Lógica de la aplicación

Lógica de la aplicación

Gestor de transaccionesGestor de

transaccionesBase dedatos

Base dedatos




49 / 125


Obtener el identificador de

cuenta del cliente

Obtener el identificador de

cuenta del cliente

Validar la tarjeta

Validar la tarjeta

Seleccionar el servicio

Seleccionar el servicio

Imprimir detalles

Imprimir detalles

Devolver la tarjeta

Devolver la tarjeta

Dispensar efectivo

Dispensar efectivo

Consultar la cuenta

Consultar la cuenta

Actualizar la cuenta

Actualizar la cuenta

ATM ATMBase de Datos

Entrada Proceso Salida

la estructura entrada-proceso-salida también se aplica a muchos sistemas de procesamiento de transacciones (versiones interactivas de sistemas de procesamiento por lotes)




50 / 125


Monitor de teleprocesamiento(middleware)

Monitor de teleprocesamiento(middleware)

Bases de datos de cuentas




51 / 125


sistemas de información y de gestión de recursos: sistemas con gran interacción con una base de datos compartida

sistemas gestión documentalsistemas de ayuda a la toma de decisionessistemas de horariossistemas de gestión de tráfico aéreosistemas de bibliotecasistemas de comercio electrónico…

Interfaz de usuarioInterfaz de usuario

Comunicaciones del usuarioComunicaciones del usuario

Recuperación y modificación de informaciónRecuperación y modificación de información

Base de datos de gestión de transaccionesBase de datos de gestión de transacciones




52 / 125


Interfaz del navegador webInterfaz del navegador web

Identificaciónde usuario

Gestor de consultasy formularios

Gestor deimpresión

Búsquedadistribuida

Recuperaciónde documentos

Gestor dederechos

Registro decuentas

Índice de bibliotecaÍndice de biblioteca

BD1BD1 BD2BD2 BD3BD3 BD4BD4 BDnBDn

Interfaz de usuarioInterfaz de usuario

Identificaciónde usuario

Entrega derecursos

Gestiónde consultas

Gestión de recursos

Control de políticasde recursos

Asignaciónde recursos

Gestión de transacciones dela base de datos de recursos

Gestión de transacciones dela base de datos de recursos

Arquitectura de un sistema deasignación de recursos

Arquitectura de un sistema degestión de documentos




53 / 125

descomposición modular

descomposición modulardespués de diseñar la arquitectura estructural se descomponen los subsistemas en módulos

no existe una distinción rígida entre la descomposición del sistema y la descomposición modular:

los modelos arquitectónicos se pueden aplicar aquísin embargo, los componentes en los módulos son más pequeños que los subsistemas, por lo que se utilizan modelos alternativos de descomposición

modelos principales de descomposición modularmodelo orientado a objetos:

el sistema se descompone en un conjunto de objetos que se comunican entre elloslos módulos son objetos con estado privado y operaciones definidas sobre ese estado

modelo de flujo de datos (o estructurado): el sistema se descompone en módulos funcionales que reciben datos y los transforman en datos de salida

diseño arquitectónico > descomposición modular







54 / 125

diseño orientado a objetos: actividades

actividades (según el Proceso Unificado de Desarrollo)

diseño de la arquitecturarealizado por los arquitectosesbozan distintos componentes

subsistemas principales e interfacesclases del diseño importantes (como las activas)mecanismos genéricos de diseño del modelo de diseño

diseño de casos de usolo realizan los ingenieros de casos de usodetallan cada caso de uso en términos de clases y/o subsistemas del diseño participantes y sus interfaceslas realizaciones de casos de uso resultantes establecen los requisitos de comportamiento para cada clase o subsistema

diseño de claseslo realizan los ingenieros de componentesintegran los requisitos dentro de cada clase (creando operaciones, atributos y relaciones)

diseño de subsistemaslo realizan los ingenieros de componentesse identifican candidatos para ser subsistemas, especificando las interfaces entre ellos

Diseño de la arquitectura

Diseñar un caso de uso

Diseñar una clase

Diseñar un subsistema

Ingeniero de componentesIngeniero de casos de usoArquitecto

diseño orientado a objetos > actividades

fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh




55 / 125

diseño de la arquitectura

diseño de la arquitecturael objetivo es esbozar los modelos de diseño y despliegue y su arquitectura mediante la identificación de los siguientes elementos:

nodos y configuraciones de redsubsistemas e interfaces entre ellosclases del diseño significativas para la arquitecturamecanismos de diseño genéricos derivados de requisitos no funcionales (persistencia, distribución, rendimiento,...) identificados durante el análisis

los arquitectos consideran distintas posibilidades de reutilización (partes de sistemas parecidos o de productos software generales)

diseño orientado a objetos > diseño de la arquitectura



Diseñar una clase






56 / 125

identificación de nodos y configuraciones de red

configuraciones físicas de la redgran 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 datoscapa de lógica de negocio o aplicación

aspectos importantes de las configuraciones de red

número de nodos necesarios y capacidad en términos de potencia de proceso y tamaño de memoriatipo de conexiones entre los nodos y protocolos de comunicaciones a utilizarcaracterísticas de las conexiones y protocolos en aspectos como ancho de banda, disponibilidad y calidadnecesidad de capacidades de redundancia de procesos, gestión de fallos, migración de procesos, política de copias de seguridad,...una vez conocidos se pueden aplicar distintas tecnologías

ORB (Object Request Broker)servicios de replicación de datos...

las configuraciones de red se muestran en diagramas de despliegue

diseño orientado a objetos > diseño de la arquitectura > identificación de nodos y configuraciones de red

Cliente del comprador

Servidor del comprador

Servidor del vendedor

Servidor del banco

Cliente del vendedor

Intranet

internet

internet

internetintranet





57 / 125

identificación de nodos y configuraciones de red

Ejemplo de un sistema de comercio electrónico.

Se ejecuta sobre tres nodos servidores y un cierto número 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).

También existe un tercer nodo servidor para el propio banco. En él se producen los verdaderos pagos de facturas (es decir, las transferencias entre cuentas).




Servidor del banco


Intranet

internet

internet

internetintranet




58 / 125

identificación de subsistemas y sus interfaces

subsistemasforma de organizar el modelo de diseño en piezas manejables

representan varios tipos de subsistemas

software desarrollado internamente en el proyectoproductos reutilizadosrecursos existentes en la empresa

pasos en la identificación de subsistemas

identificación de subsistemas de aplicaciónidentificación de subsistemas intermedios y de software del sistemadefinición de dependencias entre subsistemasidentificación de interfaces entre subsistemas

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas

Capa específica de la aplicación

Capa general de la aplicación

Capa intermedia

Capa de software del sistema




Diseñar una clase






59 / 125

identificación de subsistemas de la aplicación

Subsistemas de la aplicaciónIdentificación de los subsistemas de las capas específica y general de la aplicación

Si hubo descomposición adecuada en paquetes en el análisis, se pueden utilizar para identificar subsistemas en el modelo de diseño



Capa intermedia

Capa de software del sistema




60 / 125

Gestión cuentas<<paquete del diseño>>

Gestión de facturas del comprador

<<paquete del análisis>>Gestión de cuentas

<<paquete del análisis>>Modelo de análisis

Modelo de diseñoGestión facturas comprador<<paquete del diseño>>


se parte de la descomposición de paquetes realizada en el análisis y, según los casos, puede ser necesario refinar esa identificación de subsistemas

parte de un paquete (subsistema) del análisis puede ser compartida por varios otros subsistemas, por lo que en sí puede ser un subsistemaalgunas partes de un paquete del análisis se realizan mediante productos reutilizados, por lo que esas funciones se pueden asignar a capas intermedias o subsistemas de software del sistemalos paquetes del análisis no representan una adecuada división del trabajolos paquetes del análisis no representan la incorporación de un sistema heredado, que se puede encapsular mediante un subsistema de diseño independientelos paquetes del análisis no están preparados para una distribución sobre los nodos decididos, por lo que se podrían dividir de forma que cada uno de ellos pueda asignarse a un nodo determinado. Luego se refinarán para minimizar el tráfico de la red

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación



Diseñar una clase






61 / 125


<<trace>> <<trace>>

MODELO DE ANÁLISIS

MODELO DE DISEÑO




62 / 125


Gestión facturas comprador

Gestión de planificación de pagos

Gestión de cuentas

capa específica de la aplicación

capa general de la aplicación

Durante el diseño se identificó el subsistema de servicio Gestión de Planificación de Pagos para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso

Durante el diseño se identificó el subsistema de servicio Gestión de Planificación de Pagos para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso

El subsistema Gestión Facturas Comprador se descompone recursivamente en tres nuevos subsistemas para tratar su distribución entre los distintos nodos

El subsistema Gestión Facturas Comprador se descompone recursivamente en tres nuevos subsistemas para tratar su distribución entre los distintos nodos

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación

<< subsistema de diseño >>Gestión facturas comprador

IU delcomprador

Gestión solicitudes pago Gestión de facturas

IUsolicitudde pago

procesamiento

solicitudes de pago

Gestor pedidos

confirmaciónpedidos

procesamiento facturas

factura

Clientecomprador

Servidorcomprador

Servidorvendedor




Diseñar una clase






Servidor del banco


Intranet

internet

internet

internetintranet




63 / 125

subsistemas intermedios y de software del sistema

Identificación de subsistemas intermedios y de software del sistema

toda la funcionalidad descansa sobresistemas operativossistemas de gestión de bases de datossoftware de comunicacionestecnologías de distribución de objetostecnologías de gestión de transaccionessoftware de diseño de interfaces de usuario

compra de middleware y software del sistema

poco o nulo control sobre su evoluciónimportante mantener libertad de acción y evitar hacerse totalmente dependientes de un producto o fabricante

considerar cada producto software comprado como un subsistema independiente con interfaces explícitos para el resto de sistemas

Java.applet Java.awt Java.rmi

Navegador web Máquina virtual java

TCP / IP

Abstract Windowing Toolkit

Remote Method Invocation

Capa intermedia

Capa de softwaredel sistema

En este ejem plo, el sis tem a debe ejecutarse en diferentes tipos de m áquinas y la empresa decid ió im plem entar esta arquitectura mediante los paquetes Java AWT, RMI y Applet, que se ejecutan sobre la m áquina virtual Java. Además, hay que uti lizar un navegador para cargar páginas web.A bajo n ive l, el sistema se construye sobre software del sistema, como el protocolo TCP/IP

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas intermedios y del sistema




Diseñar una clase






64 / 125

definición de dependencias entre subsistemas

dependenciasdeben definirse si hay relaciones entre los contenidos de unos subsistemas y otros

la dirección de la dependencia es la misma que la de la relación (navegabilidad)

Java.applet Java.awt Java.rmi

Navegador webMáquina virtual

java

TCP / IP

Gestión de planif icación de pagos Gestión de

cuentas

Gestión facturas

capa específica de la aplicación

capa general dela aplicación

capa intermedia

capa de softwaredel sistema

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > dependencias entre subsistemas





65 / 125

identificación de interfaces entre subsistemas

Una clase que hace referencia a

TransferenciaEntreCuentasdesde el exterior

MODELO DE ANÁLISIS

MODELO DE DISEÑO

Transferencias

<<trace>>




66 / 125

identificación de interfaces entre subsistemas

interfaces proporcionadas por un subsistema

definen operaciones que son accesibles “desde fuera” del subsistema

vienen proporcionadas por

clasessubsistemas dentro del subsistema

además hay que identificar las operaciones que se pueden definir sobre las interfaces (se hace en el diseño de casos de uso)

diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > identificación de interfaces

Gestión de facturas

<<subsystem >>


<<subsystem>>

Gestión de cuentas

<<subsystem >>



ReceptorDeFacturas

SolicitudDePago

Transferencias





67 / 125

identificación de mecanismos genéricos de diseño

requisitos especiales identificados durante el análisisdecidir cómo tratarlos, teniendo en cuenta las tecnologías de diseño e implementación disponibles

cuestiones relacionadas con diversas cuestiones, como:persistenciadistribución transparente de objetoscaracterísticas de seguridaddetección y recuperación de erroresgestión de transacciones

ejemplosse necesita que algunos objetos sean accesibles desde varios nodos de red

Necesita diseñarse un sistema distribuidoPosible solución: implementar esa distribución de objetos haciendo que cada clase distribuida sea subclase de la clase abstracta deJava, java.rmi.UnicastRemoteObject, que soporta RMI (técnica de Java para obtener una distribución transparente de objetos)

se necesita que algunos objetos sean persistentes (por ejemplo, Pedido y Factura)

Solución: utilizar un gestor de bases de datos orientado a objetos (buen rendimiento con estructuras de objetos complejas, migración difícil desde un sistema relacional,...)Solución: utilizar un gestor de bases de datos relacional (mejor rendimiento para datos tabulares, tecnología más madura,...)Necesario documentar en la solución cómo se tratarán los aspectos de persistencia

diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño

java.rmi.UnicastRemoteObject

Factura




68 / 125

identificación de mecanismos genéricos: patrones

identificación de colaboraciones genéricas (patrones)pueden servir como patrones utilizados por diferentes casos de uso en el modelo de diseño

ejemplo: un actor crea un objeto de negocio (pedido, factura,...) y lo envía 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 electrónicamente un pedido al vendedorejemplo 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 electrónicamente al compradorse trata de un comportamiento común que se puede representar mediante una colaboración genérica (utilización de clases abstractas)





69 / 125

identificación de mecanismos genéricos: patrones

Creación de objeto de negocio

: Emisor

: ControlProcesamientoEmisor

1: enviar objeto de negocio

2: crearObjetoDeNegocio

: Objeto de Negocio

3: crear( )

: Procesamiento Receptor4: recibirObjetoDeNegocio( objetoDeNegocio)

5: obtenerInformación( )

IU Presentación de objeto de negocio

6: presentarObjetoDeNegocio(ObjetoDeNegocio)

: Receptor

7: presentar objeto de negocio

Al diseñar el caso de uso Enviar Factura al Comprador, se puede hacer que algunas clases sean subtipos de cada una de las clases abstractas que participan en la colaboración genérica

Al diseñar el caso de uso Enviar Factura al Comprador, se puede hacer que algunas clases sean subtipos de cada una de las clases abstractas que participan en la colaboración genérica


IU Creación de objeto de negocio

ControlProcesamientoEmisor

Objeto denegocio

ControlProcesamientoReceptor

IU Present. de objeto de negocio : Receptor

: Emisor

: Comprador : Vendedor

IU Creación de facturas

ControlProcesamientoFacturas

Factura ProcesamientoSolicitudesPago

IU Present. de objeto de facturas

Clasificadores abstractos que participan en la colaboración genérica de envío de objetos de negocio

Clasificadores concretos que participan en la realización del caso de uso Enviar Factura al Comprador





70 / 125

diseño de un caso de uso

actividades del diseño de un caso de uso

identificar las clases del diseño 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 diseño

identificar los subsistemas e interfaces participantes

describir las interacciones entre subsistemas

identificar requisitos no funcionales



Diseñar una clase



diseño orientado a objetos > diseño de casos de uso




71 / 125

Diseño de un caso de uso

Definir objetosparticipantes

Definir objetosparticipantes

Definir objetosconceptuales

Definir objetosconceptuales Definir objetos

de interfazDefinir objetos

de interfaz Definir objetosde control

Definir objetosde control

Definir interacciones

Definir interacciones




72 / 125

Identificación de objetos de interfaz

objetos de interfazrepresentan la interfaz del sistema con los actores

en cada caso de uso cada actor interactúa con, al menos, un objeto de interfaz

recopilan la información 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 básico, que evolucionará durante el desarrollo

identificación de los objetos de interfazidentificar formularios y ventanas que el usuario necesita para introducir datos en el sistema (por ejemplo, FormularioInformeDeEmergencia, BotónInformeEmergencia,...)identificar noticias y mensajes que el sistema usa para responder al usuario (por ejemplo AcuseDeRecibo)




73 / 125

Identificación de objetos de interfaz

Ubicación Descripción del caso de uso

1. El OficialCampo activa la función Informar Emergencia en su PDA.

2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...

3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador

4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.

5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.







Estación OficialCampo

Estación Controlador


Formulario usado para la creación de Incidente. Este formulario se le presenta al Controlador en la EstaciónControlador cuando se recibe el InformeEmergencia. El Controlador también usa este formulario para asignar recursos y dar el acuse del recibo al informe del OficialCampo.

FormularioIncidente

Ordenador móvil utilizado por el OficialCampoEstaciónOficialCampo

Formulario usado para dar los datos de InformarEmergencia. Este formulario se le presenta al OficialCampo en la EstaciónOficialCampo cuando se selecciona la función InformarEmergencia. El FormularioInformeEmergencia contiene campos para especificar todos los atributos de un informe de emergencia y un botón (u otro control) para enviar el formulario cuando está cubierto.

FormularioInformeEmergencia

Botón usado por el OficialCampo para iniciar el caso de uso InformarEmergencia

BotónInformeEmergencia

Ordenador utilizado por el ControladorEstaciónControlador

Aviso usado para desplegar el acuse de recibo del Controladorhacia el OficialCampoAcuseDeRecibo




74 / 125

Identificación de objetos de control

objetos de controlresponsables de la coordinación 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 recopilación de información de los objetos de interfaz y de enviarla a los objetos de entidad

control del flujo de formularios en un proceso de negociocontrol de las colas de “deshacer” e historialesenvío de información en sistemas distribuidos...

identificación de objetos de controlidentificar un objeto de control por caso de uso o más si el caso de uso es complejo y si puede dividirse en flujos de eventos más cortosidentificar un objeto de control por actor en el caso de usola vida de un objeto de control debe ser la del caso de uso o la de la sesión del usuariosi es difícil de identificar inicio y final de la activación de un objeto de control puede deberse a que el caso de uso no tiene condiciones de entrada y salida bien definidas




75 / 125

Identificación de objetos de control



















Gestiona la función de informe de InformarEmergencia en la EstaciónControlador. 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 envía el acuse de recibo a la EstaciónOficialCampo.

ControlAdministrarEmergencia

Gestiona la función de informe de InformarEmergencia en la EstaciónOficialCampo. Este objeto se crea cuando el OficialCamposelecciona el botón InformarEmergencia. Luego crea un FormularioInformeEmergencia y lo presenta al OficialCampo. Después del envío 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 EstaciónControlador. Cuando llega el acuse de recibo, el objeto ControlInformarEmergencia crea un MensajeAcuseDeRecibo y la despliega ante el OficialCampo.

ControlInformarEmergencia




76 / 125

modelado de interacciones entre objetos

diagramas de interacciónrepresentan el comportamiento del sistema desde la perspectiva de un solo caso de uso

permiten ver cómo el sistema realiza un caso de uso o un escenarioparticular del caso de uso mostrando la distribución de su comportamiento entre los objetos participantes

dos tiposdiagramas de colaboracióndiagramas de secuenciamuestran casi la misma información (se pueden derivar directamente uno del otro con herramientas CASE)

BotónInformarEmergencia

: OficialCampo


FormularioInformarEmergencia

oprimir( )crear( )

crear( )

cubrirContenido( )enviar( )

enviarInforme( )


: OficialCampoControlInformar

Emergencia


1: oprimir( )2: crear( )

3: crear( )

4: cubrirContenido( )5: enviar( )

6: enviarInforme( )




77 / 125


componentes de los diagramas de interacciónobjetos

se muestra como un rectángulo (o con un icono en función del estereotipo utilizado), que se etiqueta con el nombre del objeto y la clase a la que pertenece: nombreObjeto:nombreClasela clase tiene que figurar en el modelo de clasespuede haber dos o más objetos diferentes de una misma clase

enlaces (en los diagramas de colaboración): los enlaces entre objetos son instancias de las asociaciones del modelo de clases. Por tanto, si hay enlace tiene que haber asociación

actoresaparecen los actores involucrados en el caso de usotienen que aparecer en el diagrama de casos de usopuede haber varios actores, pero por lo general hay uno que inicia la acción

interacciones: se muestra la secuencia de mensajes que pasan entre los distintos objetosaparecen junto a los enlaces e indican la dirección de la navegabilidadel objeto destino tiene que “entender” el mensaje, es decir, tiene que poder proporcionar la operación adecuada

BotónInformarEmergencia : Botón


2: crear( )





78 / 125


diagrama de secuencialos enlaces no aparecen de forma explícita pero están subyacentes en el intercambio de mensajes

el tiempo pasa según nos movemos de arriba abajo en el diagrama

reglas para la realización de diagramas de secuenciaprimera columna: actor que inicia el caso de usosegunda columna: objeto de interfaz que usa el actor para iniciar el caso de usotercera columna: objeto de control que gestiona el resto del caso de usolos objetos de control son creados por objetos de interfaz que inician el caso de usolos objetos de interfaz son creados por objetos de controllos objetos de entidad son accedidos por objetos de control y de interfazlos 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)




79 / 125




80 / 125


Al modelar el comportamiento del sistema se descubren los objetos AcuseDeRecibo y MensajeAcuseDeRecibo, lo que provoca cambios en la descripción del caso de uso InformarEmergencia y en la relación de objetos de entidad y de interfaz. fuente: Ingeniería del Software Orientado a Objetos, B.Bruegge y A.H. Dutoit, pp. 147-149


: OficialCampo




FormularioIncidente

Incidente AcuseDeRecibo

: Controlador

MensajeAcuseDeRecibo

InformeEmergencia

oprimir( )crear( )

crear( )

cubrirContenido( )enviar( )

enviarInforme( )

crear( )

enviarInformeAControlador( ) crear( )ver

crearIncidente( )crear( )

enviarAcuseDeRecibo( )

crear( )

inform eAcuseDeRecibo( )

crear( )

ver

enviarAcuseDeRecibo( )




81 / 125


diagrama de colaboracióncompuesto por

objetos: puede haber dos o más objetos de una misma claseenlacesactoresinteracciones

se muestra la secuencia de mensajes que pasa entre los objetos (interacciones)

BotónInf ormarEmergencia

: Of icialCampo

ControlInformarEmergenciaFormularioInf ormar

Emergencia


Inf ormeEmergencia

FormularioIncidente

Incidente

AcuseDeRecibo

: Controlador

MensajeAc useDeRecibo

2: crear( )

1: oprimir( )

4: cubrirContenido( )5: env iar( )

3: crear( )

6: env iarInf orme( )

7: crear( )

8: env iarIn formeAContro lador( )

16: inf ormeAcuseDeRecibo( )

17: crear( )

9: crear( )

15: env iarAcuseDeRecibo( )10: ver

11: crearIncidente( )13: env iarAcuseDeRecibo( )

12: crear( )

14: crear( )

18: v er




82 / 125


mensajes desde un objeto a sí mismo

eliminación de comportamiento detallado: utilización de paquetes

socioBiblioteca

okTomarPréstamoLibrosocioBiblioteca

okTomarPréstamoLibro




83 / 125


comportamiento condicional

socioBiblioteca

socioBiblioteca libro

pedirPréstamo

okTomarPrestado

tomarPrestado

s i préstamoPosible = s i

si no

préstamoDenegado

fin si ...




84 / 125

diseño de objetos con responsabilidades

Patrones GRASP (General Responsibility AssignmentSoftware Patterns)

Describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones

Cinco patronesExperto en InformaciónCreadorAlta CohesiónBajo AcoplamientoControlador




85 / 125


Patrón Experto en información (asignación de responsabilidades)

Problema: ¿Qué principio general se puede seguir para asignar responsabilidades a los objetos?

Solución: asignar una responsabilidad al experto en información, es decir, a la clase que tiene la información necesaria para realizar la responsabilidad

Localización de clases:Buscar primero en el Modelo de Diseño, si hay clases relevantesSi no hay, buscar en el Modelo de Dominio y utilizar (o ampliar) las clases para crear las correspondientes clases de diseño




86 / 125


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

¿Quién debería ser responsable de conocer el total de una venta?




87 / 125





88 / 125


Patrón CreadorProblema: ¿Quién es el responsable de crear una nueva instancia de alguna clase?

Solución: se asignará a la clase B la responsabilidad de crear una instancia de la clase A si se cumple uno o más de los casos siguientes:

B agrega objetos de AB contiene objetos de AB registra instancias de objetos de AB tiene datos de inicialización que se pasan a un objeto de A cuando es creado

La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos

Buena asignación implicaBajo acoplamientoMayor claridadMejor encapsulación y reutilización




89 / 125


Ejemplo: ¿quién debe crear una instancia de LineaDeVenta?Solución: Venta, pues agrega muchos objetos LineaDeVenta




90 / 125


Patrón ControladorProblema: ¿Quién controla un evento de entrada al sistema?

Solución: 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 sistemarecibe la solicitud de servicio desde la capa de IU y coordina su realización, normalmente delegando en otros objetos

VentajasMayor potencial de reutilización: la lógica de la aplicación no se encuentra en la capa de interfaz“Razonamiento” sobre el estado del caso de uso




91 / 125





92 / 125





93 / 125

identificación de las clases del diseño

clases que participan en la realización del caso de uso

estudiar las clases del análisis que participan en la realización del caso de uso-análisis, identificando las clases del diseño que poseen una traza hacia esas clases del análisis

estudiar requisitos especiales identificados en el caso de uso-análisis, identificando las clases del diseño que realizan esos requisitos especiales

identificación de todas las clases necesarias

diagrama de clases parcial: muestra las clases del diseño que participan en la realización del caso de uso



Diseñar una clase



diseño orientado a objetos > diseño de casos de uso > identificación de clases del diseño

Diagrama de clases parcial




94 / 125


: Admi nistra dor : :OpcionesMantenCatálogo

: AltaArticulo : FormularioAltaArt ículo : ValidarArtículo : ProcesarAltaArtículo :Artículo : MensajeResultado

Mostrar

Fin Si

Navegar

Mostrar

<<link>>

Mostrar

Introducir datos artículo Validar artículo

Si datos correctosEnviar datos

Introducir datos

Alta artículo( )

ConstruirSi es correcto insertar

Si no es correcto insertar Construir

Si datos i ncorrectosMostrar mensaje error

Fin Si




95 / 125


ValidarArtículo<<ClientScript Object>>

:OpcionesMantenCatálogo<<Client Page>> AltaArtículo

FormularioAltaArtículo<<Form>>

<<link>><<include>>

<<include>>

MensajeResultado<<Client Page>>

ProcesarAltaArt ículo<<Server Page>>

<<submit>><<build>>

Articulo(from Logical View)

+insertar






96 / 125

identificación de subsistemas e interfaces

identificar subsistemas e interfacesa veces es útil diseñar un caso de uso en términos de los subsistemas y/o interfaces que participan en él

pasosestudiar las clases del análisis que participan en las correspondientes realizaciones del caso de uso-análisis, identificando (si existen) los paquetes del análisis que contienen esas clases del análisis. Después, identificar los subsistemas del diseño que poseen una traza hacia esos paquetes del análisisestudiar los requisitos especiales de las realizaciones de caso de uso-análisis, identificando las clses del diseño que las realizan, si existen. Después, identificar los subsistemas del diseño que contienen esas clases.mostrar los subsistemas que participan en una realización de caso de uso en un diagrama de clases parcial, mostrando:

las dependencias entre esos subsistemas ylas interfaces que se utilicen en la realización del caso de uso



Diseñar una clase



diseño orientado a objetos > diseño de casos de uso > identificación de subsistemas e interfaces

IU Comprador<<subsistema diseño>>

Gestión de solicitudes de pago

<<subsistema diseño>>


<<subsistema diseño>>

Solicitud de pago

Gestión de facturas<<subsistema diseño>>





97 / 125

requisitos de implementación

captura de requisitos de implementaciónse incluye en la realización del caso de uso todos los requisitos identificados durante el diseño que deben tenerse en cuenta durante la implementación, como los no funcionales

ejemplo de requisito de implementación del caso de uso Pagar Factura:

Un objeto de la clase Procesamiento de Solicitudes de Pago debería ser capaz de soportar 10 clientes de Comprador diferentes sin un retraso perceptible para cada uno de los compradores



Diseñar una clase



diseño orientado a objetos > diseño de casos de uso > requisitos de implementación




98 / 125

diseño de clases

actividadesesbozar la clase del diseño

identificar operaciones

identificar atributos

identificar asociaciones y agregaciones

identificar generalizaciones

describir los métodos

describir estados

tratar requisitos especiales



Diseñar una clase



diseño orientado a objetos > diseño de clases




99 / 125

clase del diseño

clase del diseño: abstracción de una clase o construcción similar en la implementación del sistema

el lenguaje utilizado para especificar la clase del diseño puede ser el que se utilizará para su implementación

se suele especificar la visibilidad de los atributos y las operaciones

los métodos de la clase tienen correspondencia directa con el correspondiente método en la implementación del código de las clases

pueden incorporarse estereotipos que hagan corresponder la clase con una construcción específica del lenguaje de programación (por ejemplo, en VisualBasic, “class module”, “form”, “user control”,...)

pueden indicarse interfaces si tiene sentido en el lenguaje de programación (por ejemplo, una clase de diseño que se implementa como una clase Java)

Pedido<<form>>

diseño orientado a objetos > diseño de clases




100 / 125

esbozar clases de diseño

esbozar la clase del diseñoclases de interfaz

depende de la tecnología de interfaz a utilizar. Por ejemplo, clases diseñadas en Visual Basic implican clases del diseño estereotipadas como <<forms>> o <<controls>> de ActiveXen esta fase es esencial utilizar los prototipos de interfaz realizados anteriormente

clases de entidad con información persistente: su diseño requiere utilizar tecnologías de bases de datos específicas

adoptar una estrategia para hacer corresponder el modelo de diseño orientado a objetos con, por ejemplo, tablas en un modelo de datos relacionalrequiere trabajadores específicos (diseñadores de bases de datos), actividades de diseño de bases de datos y modelos distintos (modelos entidad-relación, por ejemplo)

clases de control: implica considerar diferentes aspectosaspectos de distribución (separación de clases en diferentes nodos de una red, por ejemplo)aspectos de rendimientoaspectos de transacción: los diseños deben incorporar cualquier tecnología de gestión de transacciones existente que se esté utilizando

las clases de diseño identificadas deben ser asignadas trazando dependencias a las correspondientes clases de análisis que son diseñadas



Diseñar una clase



diseño orientado a objetos > diseño de clases > esbozar la clase del diseño




101 / 125

identificación de operaciones

identificación de las operaciones que necesitan las clases de diseño

descripción de las operaciones utilizando la sintaxis de los lenguajes de programación a utilizar, lo que incluye especificar la visibilidad de cada operación (por ejemplo, en C++, public, protected, private)

datos importantes a tener en cuenta en esta fase

responsabilidades de cualquier clase del análisis que tenga una traza con la clase del diseño (una responsabilidad puede implicar una o varias operaciones)requisitos especiales de cualquier clase de análisis que tenga una traza con la clase del diseñointerfaces que la clase de diseño necesita proporcionarlas realizaciones de caso de uso-diseño en las que la clase participa



Diseñar una clase



diseño orientado a objetos > diseño de clases > identificar operaciones

Objeto de negocio

crear()enviar()plan ificar()cerrar()

Factura




102 / 125

identificación de operaciones

Operaciones de la clase Factura

La clase Factura participa en varias realizaciones de casos de uso, como aquellas de Pagar Factura, Enviar Aviso y Enviar Factura alComprador. Cada una de estas realizaciones leen o cambian ele stado de los objetos Factura. El caso de uso Enviar Factura al Comprador crea y envía facturas. El caso de uso Pagar Factura planifica Facturas, y así todos. Cada una de estas realizaciones de casos de uso, por tanto, utiliza objetos Facutra de forma diferente; en otras palabras, la clase Factura y sus objetos desempeñan distintos papeles en estas realizaciones de casos de uso.

Primero, los ingenieros de componentes pensaron en implementar estos cambios de estado como una operación llamada setStatus, que tenía un parámetro que indicaba la acción deseada y el estado destino (por ejemplo, setStatus(Planificada)). Pero entonces decidieron que era preferible implementar operaciones explícitas para cada transición de estados. Es más, decidieron utilizar este enfoque no sólo para la clase Factura, sino también para la clase Objeto de Negocio, de la cual es un subtipo la clase Factura. Laclase Objeto de Negocio soporta de esta forma las siguientes operaciones (cada una de las cuales cambia el estado de Objeto de Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estasoperaciones son solamente operaciones virtuales que definen un patrón. Las clases que son subtipos de la clase Objeto de Negocio tienen que definir cada una un método concreto que realice estas operaciones.

Operaciones de la clase Factura

La clase Factura participa en varias realizaciones de casos de uso, como aquellas de Pagar Factura, Enviar Aviso y Enviar Factura alComprador. Cada una de estas realizaciones leen o cambian ele stado de los objetos Factura. El caso de uso Enviar Factura al Comprador crea y envía facturas. El caso de uso Pagar Factura planifica Facturas, y así todos. Cada una de estas realizaciones de casos de uso, por tanto, utiliza objetos Facutra de forma diferente; en otras palabras, la clase Factura y sus objetos desempeñan distintos papeles en estas realizaciones de casos de uso.

Primero, los ingenieros de componentes pensaron en implementar estos cambios de estado como una operación llamada setStatus, que tenía un parámetro que indicaba la acción deseada y el estado destino (por ejemplo, setStatus(Planificada)). Pero entonces decidieron que era preferible implementar operaciones explícitas para cada transición de estados. Es más, decidieron utilizar este enfoque no sólo para la clase Factura, sino también para la clase Objeto de Negocio, de la cual es un subtipo la clase Factura. Laclase Objeto de Negocio soporta de esta forma las siguientes operaciones (cada una de las cuales cambia el estado de Objeto de Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estasoperaciones son solamente operaciones virtuales que definen un patrón. Las clases que son subtipos de la clase Objeto de Negocio tienen que definir cada una un método concreto que realice estas operaciones.

diseño orientado a objetos > diseño de clases > identificar operaciones



Diseñar una clase



Objeto de negocio

crear()enviar()plan ificar()cerrar()

Factura





103 / 125

identificación de atributos

identificación de atributosutilizar la sintaxis del lenguaje de programación

considerar los atributos de cualquier clase de análisis que tenga una traza con la clase de diseño (a veces implican más de un atributo en la clase de diseño)

los tipos de atributos están restringidos por el lenguaje de programación

una instancia única de atributo no puede ser compartida por varios objetos de diseño. 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



Diseñar una clase



diseño orientado a objetos > diseño de clases > identificar atributos




104 / 125

asociaciones, agregaciones y generalizaciones

identificación de asociaciones y agregacionesestudiar la transmisión de mensajes en los diagramas de secuencia para determinar quéasociaciones son necesarias

el número de relaciones debe estar minimizado, dando respuesta a las demandas de varias realizaciones de casos de uso

en ocasiones hay que modelar rutas de búsqueda óptimas a través de asociaciones y agregaciones para gestionar aspectos de rendimiento

refinar la multiplicidad, nombres de rol,... según el soporte del lenguaje de programación utilizado

identificación de generalizacionesdeben ser utilizadas con la misma semántica definida en el lenguaje de programación

si el lenguaje no admite herencia, las asociaciones y/o agregaciones deben utilizarse en vez de la generalización

diseño orientado a objetos > diseño de clases > identificar asociaciones y agregaciones



Diseñar una clase



Objeto de negocio

Factura Pedido




105 / 125

métodos y estados

descripción de los métodospueden especificarse algoritmos que se van a utilizar para realizar una operación, en seudocódeigo o lenguaje natural

la mayoría de los métodos no se especifican durante el diseño

descripción de estadosalgunos objetos del diseño 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



Diseñar una clase



diseño orientado a objetos > diseño de clases > descripción de métodos y estados

creada

pendiente

planificada

vencida y no pagada

cerrada

enviar()

planificar

cerrar()

[fuera de plazo: retraso en fecha de

pago]

cerrar()

Los objetos Factura cambian de estado según sean creados, enviados, planificados o cerrados. Como todos los objetos de negocio, estos estados cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede ser planificada antes de haber sido enviada.

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 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 pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el estado pasa a cerrada.

Los objetos Factura cambian de estado según sean creados, enviados, planificados o cerrados. Como todos los objetos de negocio, estos estados cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede ser planificada antes de haber sido enviada.

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 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 pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el estado pasa a cerrada.





106 / 125

requisitos especiales

requisitos especialesestudiar los requisitos formulados en la realización de los casos de uso en los que la clase participa

estudiar los requisitos especiales de cualquier clase de análisis que tenga una traza con la clase de diseño

algunos requisitos se posponen hasta la implementación (requisitos de implementación)

Factura

UnicastRemoteObject Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Servidor del Comprador y desde el Servidor del Vendedor. La Factura tiene que ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se implementa esta distribución de objetos haciendo la clase Factura una subclase de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño estáidentificado y descrito por el arquitecto en la actividad de diseño arquitectónico.

Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Servidor del Comprador y desde el Servidor del Vendedor. La Factura tiene que ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se implementa esta distribución de objetos haciendo la clase Factura una subclase de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño estáidentificado y descrito por el arquitecto en la actividad de diseño arquitectónico.

Ejemplo requisito de implementación:

Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz de gestionar 10 clientes de Comprador diferentes sin un retardo perceptible para los compradores.

Ejemplo requisito de implementación:

Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz de gestionar 10 clientes de Comprador diferentes sin un retardo perceptible para los compradores.



Diseñar una clase



diseño orientado a objetos > diseño de clases > requisitos especiales





107 / 125

Diseño de un subsistema

actividadesdefinición de las dependencias entre subsistemas

definición de las interfaces proporcionadas por el subsistema

refinar los contenidos de los subsistemas



Diseñar una clase






108 / 125

el diseño estructurado

Los modelos del análisis facilitan la información necesaria para crear los modelos del diseño

DICCIONARIODE DATOS

Diagrama de Flujo de

Datos

Diagrama deTransición de Estados

Diagrama Entidad-Relación

Descripció

n de entidades Especificación de procesos

Especificación de control

Diseñoprocedimental

Diseño deinterfaz

Diseñoarquitectónico

Diseño dedatos

MODELOS DEL ANÁLISISMODELOS DEL ANÁLISIS

MODELOS DEL DISEÑOMODELOS DEL DISEÑOEstructuras de datos necesarias para implementar el software

Estructuras de datos necesarias para implementar el software

Relación entre los principales elementos estructurales del programa

Relación entre los principales elementos estructurales del programa

Cómo se comunica el sistema consigo mismo, con otros sistemas y con los operadores

Cómo se comunica el sistema consigo mismo, con otros sistemas y con los operadores

Descripción procedimental de los componentes del software

Descripción procedimental de los componentes del software




109 / 125

conceptos del diseño estructurado

jerarquía de controlOrganización de los módulos de un sistema.

Jerarquía de control.

No se representan necesariamente aspectos procedimentales

Notación: diagrama estructurado (Constantine)

Profundidad: indica el número de niveles de control

Anchura: indica el ámbito global de control

Grado de salida: número de módulos controlados directamente por otro módulo.

Grado de entrada: número de módulos que controlan directamente a un módulo 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.

diseño estructurado > conceptos




110 / 125

Conceptos del diseño estructurado

M

cba

ed k l m

hgf qpon

ji r

Anchura

grado desalida

grado deentrada

profundidad





111 / 125


función 1

función 2

función 3

partición horizontal

partición vertical

módulos de tomade decisiones

módulos “de trabajo”

PARTICIÓN ESTRUCTURAL

Partición horizontal:ramas separadas para cada función

principal.Beneficios: facilidad de prueba y

mejora, mantenimiento, menos efectos secundarios.

Desventajas: mayor flujo de datos y control global del flujo del programa más complicado.

Partición vertical (factoring): control y trabajo distribuidos de manera descendiente en la arquitectura del programa.

Módulos de nivel superior: control y poco procesamiento.

Módulos de nivel inferior: procesamiento (entradas, cálculos y salida)

Mejor capacidad de mantenimiento.Cambios en módulos de control: más

probabilidad de propagar efectos secundarios, pero son menos habituales.

Cambios en módulos de trabajo: habituales, pero con poca probabilidad de propagar efectos secundarios.

PARTICIÓN ESTRUCTURAL

Partición horizontal:ramas separadas para cada función

principal.Beneficios: facilidad de prueba y

mejora, mantenimiento, menos efectos secundarios.

Desventajas: mayor flujo de datos y control global del flujo del programa más complicado.

Partición vertical (factoring): control y trabajo distribuidos de manera descendiente en la arquitectura del programa.

Módulos de nivel superior: control y poco procesamiento.

Módulos de nivel inferior: procesamiento (entradas, cálculos y salida)

Mejor capacidad de mantenimiento.Cambios en módulos de control: más

probabilidad de propagar efectos secundarios, pero son menos habituales.

Cambios en módulos de trabajo: habituales, pero con poca probabilidad de propagar efectos secundarios.





112 / 125



• Consecuencia de la modularidad, la abstracción y la ocultación de la información• Módulos con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización


• Consecuencia de la modularidad, la abstracción y la ocultación de la información• Módulos con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización

COHESIÓN

Medida del grado de “fuerza funcional” de un módulo: cuanto menor sea el número de tareas (elementos de procesamiento) que realiza un módulo, mayor será su cohesión.Diferentes grados de cohesión:

MÓDULO CONTAREA SIMPLE

MÓDULO CON DIVERSASTAREAS POCO O NADARELACIONADAS

ACOPLAMIIENTO

Medida de la interdependencia relativa entre los módulos, y depende de la interfaz entre éstos, es decir, de la cantidad y tipo de datos que comparten.

Objetivo durante el diseño: minimizar el acoplamiento utilizando conexiones sencillas entre los módulos.

Formas de reducir el acoplamiento:• Eliminando relaciones innecesarias• Reduciendo las relaciones necesarias

Beneficios de un bajo acoplamiento:• Menor transmisión de defectos (efectos secundarios)• Posibilidad de cambiar un módulo sin incidir sobre otros• En el mantenimiento de un módulo no hay que tener en cuenta el contenido de otros

CONCEPTOSCOMPLEMENTARIOSCONCEPTOS

COMPLEMENTARIOS

Maximizar la cohesión es casi lo mismo que minimizar el acoplamiento

Maximizar la cohesión es casi lo mismo que minimizar el acoplamiento





113 / 125

acoplamiento en el diseño estructuradoTI

POS

DE

AC

OPL

AM

IEN

TOTI

POS

DE

AC

OPL

AM

IEN

TO

ACOPLAMIENTO NORMAL

De datos: dos módulos se comunican por parámetros, siendo cada parámetro una porción elemental de datos.

Evitar datos que circulen sin necesidad.Fomentar conexiones formadas por pocos datos.

Compuesto: un módulo pasa al otro un dato compuesto.Introduce una cierta conexión indirecta (Diccionario de Datos)Evitar datos compuestos con subdatos innecesarios.Evitar agrupamientos de datos que no tienen nada en común.

De control: un módulo pasa a otro información de control destinada a controlar la lógica interna del segundo.

ACOPLAMIENTO NORMAL

De datos: dos módulos se comunican por parámetros, siendo cada parámetro una porción elemental de datos.

Evitar datos que circulen sin necesidad.Fomentar conexiones formadas por pocos datos.

Compuesto: un módulo pasa al otro un dato compuesto.Introduce una cierta conexión indirecta (Diccionario de Datos)Evitar datos compuestos con subdatos innecesarios.Evitar agrupamientos de datos que no tienen nada en común.

De control: un módulo pasa a otro información de control destinada a controlar la lógica interna del segundo.

ACOPLAMIENTO COMÚN

Dos módulos hacen referencia a una misma área de datos globales. No es recomendable por:

Posibilidad de que los errores se trasladen de unos módulos a otros.Baja flexibilidad modularComplica el mantenimientoDiferentes significados de los datos según el módulo que lo utiliceSi se cambia un módulo es difícil identificar los datos que hay que cambiar.

Excepción: BASES DE DATOS (no son volátiles, son diseñadas con disciplinas específicas y las conexiones son restringidas y controladas, no aleatorias).

ACOPLAMIENTO COMÚN

Dos módulos hacen referencia a una misma área de datos globales. No es recomendable por:

Posibilidad de que los errores se trasladen de unos módulos a otros.Baja flexibilidad modularComplica el mantenimientoDiferentes significados de los datos según el módulo que lo utiliceSi se cambia un módulo es difícil identificar los datos que hay que cambiar.

Excepción: BASES DE DATOS (no son volátiles, son diseñadas con disciplinas específicas y las conexiones son restringidas y controladas, no aleatorias).

ACOPLAMIENTO DE CONTENIDO

Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual en lenguajes de bajo nivel.Hay que evitarlo pues ataca al concepto de caja negra.

ACOPLAMIENTO DE CONTENIDO

Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual en lenguajes de bajo nivel.Hay que evitarlo pues ataca al concepto de caja negra. +

-

Gra

do d

e ac

opla

mie

nto





114 / 125

cohesión en el diseño estructurado

Tarea o elemento de procesamiento:órdenes en el módulo y procesos que resultan de llamadas a módulos subordinados

módulo

Principio asociativo: los elementos de procesamiento o tareas se agrupan en base a algún tipo de pertenencia entre ellos.La cohesión se aplica sobre todos los pares de tareas

Principio asociativo: los elementos de procesamiento o tareas se agrupan en base a algún tipo de pertenencia entre ellos.La cohesión se aplica sobre todos los pares de tareas

Las tareas que se encuentran dentro de un módulo subordinado no figuran en la cohesión del módulo que lo invoca

Cohesión funcional: sus elementos contribuyen a la resolución de una y sólo una tarea.

Cohesión secuencial: los datos de salida de una tarea sirven como datos de entrada para el siguiente elemento.

Cohesión comunicacional: todos sus elementos operan sobre los mismos conjuntos de entrada y/o producen los mismos datos de salida.

Cohesión procedural: las tareas efectúan diferentes (y seguramente no relacionadas) actividades y se efectúan en un orden determinado.

Cohesión temporal: sus elementos desarrollan actividades que se relacionan en el tiempo.

Cohesión lógica: las tareas desarrollan actividades de la misma clase, pero para utilizar el módulo hay que seleccionar la/s actividades que se necesitan

Cohesión casual: las tareas no tienen relación significativa entre ellas

+

-

Gra

do d

e co

hesi

ón





115 / 125

el diseño de datos

Diseño de datos:Profunda influencia en la calidad del software:

Influye en la estructura del programaInfluye en la complejidad procedimental

Fundamentos: ocultación de información y abstracción de datos

Actividades: escoger estructuras de datos para los datos identificados en el análisis.Identificar los módulos del programa que deben operar directamente sobre las estructuras de datos

Principios del diseño de datos1) Estudiar alternativas de estructuras de datos

2) Especificar las operaciones a llevar a cabo sobre los datos

3) Utilización del Diccionario de Datos

4) Retrasar las decisiones de bajo nivel

5) Representación de los datos conocida sólo por los módulos 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


Diseño de interfaz

Diseño arquitectónico

Diseño de datos diseño estructurado > diseño de datos




116 / 125

el diseño arquitectónico

Objetivos:Desarrollar una estructura de programa modular

Representar las relaciones de control entre los módulos

Combina la estructura del programa y la de datos, definiendo interfaces que permiten el flujo de datos a través del programa

Diversos métodos de diseño arquitectónico

En cierta forma, el diseño arquitectónicodesarrolla los “planos” del programa


Diseño de interfaz


Diseño de datos diseño estructurado > diseño arquitectónico




117 / 125

el diseño arquitectónicoDiseño

procedimental

Diseño de interfaz


Diseño de datos

FLUJO INFORMACIÓN(DFD)

DESCRIPCIÓN ESTRUCTURADA(Diagramas de estructura)

DISEÑO ORIENTADOAL FLUJO DE DATOSDISEÑO ORIENTADO

AL FLUJO DE DATOS

TIPOS DE FLUJOS:

1) De Transformación: a) La información entra en el sistema a lo largo de caminos que transforman los datos

externos a un formato interno: flujo de entradab) Esta información pasa a través de un centro de transformaciónc) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de

salida.

2) De Transacción: datos que se mueven a lo largo de un camino de entrada que convierte la información exterior en una transacción. Ésta se evalúa y, basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos posibles de acción. El proceso del que parten los caminos de acción se llama centro de transacción.

TIPOS DE FLUJOS:

1) De Transformación: a) La información entra en el sistema a lo largo de caminos que transforman los datos

externos a un formato interno: flujo de entradab) Esta información pasa a través de un centro de transformaciónc) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de

salida.

2) De Transacción: datos que se mueven a lo largo de un camino de entrada que convierte la información exterior en una transacción. Ésta se evalúa y, basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos posibles de acción. El proceso del que parten los caminos de acción se llama centro de transacción.

1

RECIBIRPEDIDO

Productos Devueltos

2

ENVIARPEDIDO

4

RECIBIRDEVOLUCIONES

5GENERARINFORMES VENTAS

3

GESTIONARSTOCKStock

Detalles_Pedido

Clientes

Representante Ventas

Cliente

Pago_Cliente

Pedido ClientePedido_Proveedor

Pago_Proveedor

Producto_Stock

Factura_Proveedor

Petición_Comprobación_Crédito

Detalles_Crédito

Informe_Ventas

Factura_Cliente

Envío_Cliente

Devolución_Cliente

Reintegro_Cliente

Producto_DevueltoNúmero_Empleado

Cliente

Detalles_Pedido

Producto_DevueltoDirección_Envío

Nombre_Empleado_y_Supervisor

Políticas_Ventas_y_Cuotas

Confirmación_Pedido

Dirección_Factura

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd0.dfdProcess OrdersFeb-18-1993Wayne McDonaldDec-12-1993EasyCASE

diseño estructurado > diseño arquitectónico




118 / 125


Análisis de transformaciónRevisar el modelo

Revisar y refinar los DFDs

Determinar las características de los DFDs

Aislar el centro de transformación

Descomposición inicial: establecer un “controlador principal” y otros controladores subordinados para entradas, transformaciones y salidas.

Descomposición de 2º nivel: convertir los procesos del DFD en los módulos correspondientes de la estructura del programa. Se pueden convertir varios procesos en un módulo, un proceso en varios módulos,...

Refinar (aplicar directrices de diseño)


Diseño de interfaz






119 / 125


Análisis de transacciónRevisar el modelo

Revisar y refinar los DFDs

Determinar las características de los DFDs

Identificar el centro de transacción y las características del flujo de cada camino

Descomponer y refinar la estructura y las ramas: el flujo de transacción se convierte en una estructura de programa que contiene una rama de entrada y una rama de distribución. Ésta contiene un módulo distribuidor que controla todos los módulos de acción subordinados. Cada flujo de acción se convierte en una estructura según sus características.

Refinar (aplicar directrices de diseño)

Transacción

Centro detransacción


Diseño de interfaz






120 / 125


Optimización:Representación que satisfaga los requisitos FUNCIONALES y de RENDIMIENTO

Simplicidad

Aplicaciones de rendimiento crítico (entre el 10-20% del software ocupa el 50-80% del tiempo de procesamiento):

Diseñar y refinar sin ocuparse del rendimientoSimular el rendimiento en tiempo de ejecuciónSeleccionar los módulos que ocupen demasiado tiempo y rediseñarlosCodificarAislar, rediseñar o recodificar para mejorar la eficiencia


Diseño de interfaz






121 / 125

el diseño de interfaz

Tres áreas principales:Diseño de interfaces entre los módulos software (interfaz interna): depende de los datos que deben fluir entre los módulos y las características del lenguaje de programación.

Diseño de interfaces entre el software y sistemas externos (interfaz externa): se evalúa cada entidad externa, determinando requisitos de datos y control de la misma, y se diseñan las interfaces externas adecuadas.

Diseño de interfaces hombre-máquina


Diseño deinterfaz


Diseño de datos diseño estructurado > diseño de interfaz




122 / 125


Diseñador deinterfaces

MODELO DE DISEÑO:Representaciones de datos, arquitectónicas, de interfaces y procedimentales. El diseño de interfaz suele ser secundario con respecto a éste, excepto en sistemas altamente interactivos.

MODELO DE USUARIO:Perfil de los usuarios finales del sistema (edad, capacidades físicas, estudios, nivel cultural, motivación,...). Pueden ser usuarios novatos, esporádicos o frecuentes.

PERCEPCIÓN DEL SISTEMA:imagen del sistema que percibe el usuario final. La exactitud de su descripción dependerá de su perfil.

IMAGEN DEL SISTEMA:Combinación del aspecto externo del sistema con toda la información de soporte que describen sintaxis y semántica del sistema.

Cuando coinciden, los usuarios se sienten a gusto con el software y lo utilizan eficazmente.

Cuando coinciden, los usuarios se sienten a gusto con el software y lo utilizan eficazmente.


Diseño deinterfaz






123 / 125


aspectos del diseño de interfaz persona-máquinatiempo de respuesta

duraciónvariabilidad

mensajes de errordescripción del problemainformación constructiva.consecuencias negativas posiblesseñal audible o visibleevitar juicios al usuario

etiquetado de órdenespoco habituales en entornos visualesórdenes para todas las opcionesformato de las órdenesfacilidad de aprendizaje y de recordarmacros de órdenesconvenios para uso en diferentes aplicaciones

ayuda al usuariointegradaagregada


Diseño deinterfaz






124 / 125


DIRECTRICES INTERACCIÓN

Consistencia de formatoRespuestas significativasVerificación de acciones destructivasDeshacer accionesEficiencia diálogo: distancia que debe moverse el ratón,...Autoprotección del sistema ante erroresCohesión órdenes y acciones: organización de órdenes por tipoAyudas sensibles al contextoVerbos y frases sencillos para las órdenes

DIRECTRICES INTERACCIÓN

Consistencia de formatoRespuestas significativasVerificación de acciones destructivasDeshacer accionesEficiencia diálogo: distancia que debe moverse el ratón,...Autoprotección del sistema ante erroresCohesión órdenes y acciones: organización de órdenes por tipoAyudas sensibles al contextoVerbos y frases sencillos para las órdenes

DIRECTRICES ENTRADA DE DATOS

Minimizar número acciones entrada: reducir la cantidad de escritura necesaria, usando el ratón, macros,...Consistencia visualización-introducciónPersonalizar entrada: órdenes personalizadas, eliminar mensajes de advertencia y verificación,...Interacción personalizada: por ejemplo, escoger teclado o ratón.Desactivar órdenes inapropiadasEliminar entradas innecesarias: .00 en cantidades enteras, información disponible automáticamente o que se puede calcular,...

DIRECTRICES ENTRADA DE DATOS

Minimizar número acciones entrada: reducir la cantidad de escritura necesaria, usando el ratón, macros,...Consistencia visualización-introducciónPersonalizar entrada: órdenes personalizadas, eliminar mensajes de advertencia y verificación,...Interacción personalizada: por ejemplo, escoger teclado o ratón.Desactivar órdenes inapropiadasEliminar entradas innecesarias: .00 en cantidades enteras, información disponible automáticamente o que se puede calcular,...

DIRECTRICES VISUALIZACIÓN

Información relevante en el contexto actualNo abrumar con datos: usar gráficos y esquemasMantener contexto visualEtiquetas consistentes, abreviaciones estándar y colores predeciblesMensajes de error significativosUso de ventanasPresentaciones analógicasGeografía de la pantalla

DIRECTRICES VISUALIZACIÓN

Información relevante en el contexto actualNo abrumar con datos: usar gráficos y esquemasMantener contexto visualEtiquetas consistentes, abreviaciones estándar y colores predeciblesMensajes de error significativosUso de ventanasPresentaciones analógicasGeografía de la pantalla

DIRECTRICES PARA EL DISEÑO DE INTERFACES HOMBRE -MÁQUINA

DIRECTRICES PARA EL DISEÑO DE INTERFACES HOMBRE -MÁQUINA


Diseño deinterfaz






125 / 125

bibliografía

C. Larman: UML y Patrones. Capítulos 15 y 16

Jacobson, Booch, Rumbaugh: El Proceso Unificado de Desarrollo de Software. Capítulo 9

I. Sommerville: Ingeniería del Software, Capítulos 11, 12, 13 y 14

segunda clase diseño de sistemas y software

Documents