ADS-mod 24

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
¿Qué es el diseño de
sistemas?
Análisis y Diseño de
z Es la evaluación de las distintas soluciones
Sistemas alternativas y la especificación de una solución
detallada de tipo informático.
Dpto. Ciencias e Ingeniería de la Computación
Universidad Nacional del Sur z Decidir a partir de las distintas alternativas.
Clase 2
z La elección la hacen propietarios del sistema y
24 – Diseño de Sistemas equipo técnico.
Lic. María Mercedes Vitturini
z El diseño transforma progresivamente los
[mvitturi@cs.uns.edu.ar] requerimientos del sistema a través de un
número de pasos intermedios hasta llegar al
1er. CUATRIMESTRE 2006 producto final.
Análisis y Diseño de Sistemas - Clase 24
Diseño Diseño de Sistemas

Qué
z El objetivo del diseño consiste en llegar a un
Requerimientos del Análisis
producto final con calidad.
Diseño1 ¿Cómo?
z Salidas: el diseño del sistema que incluye:
z Diseño de la arquitectura
Diseño2
z Diseño detallado (diseño de módulos, funciones)
z Diseño de las estructuras de datos
DISEÑO Cómo
z Diseño de las interfaces
PRODUCTO
Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24
Modelos del Diseño Modelos del Diseño

z Diseño Arquitectónico: se identifican los z Diseño de Interfaz: describe la manera de
subsistema que forman el sistema. Se define la
relación entre los mismos, los patrones de diseño y comunicarse con el software, con sistemas que
las restricciones que afectan a la manera en que se interoperan dentro de él y con las personas que lo
pueden aplicar los patrones. usan.
z Diseño de Datos: transforma el modelo del dominio z Diseño a nivel de componente: se asignan
de información del análisis en las estructuras de servicios a los distintos componentes y se diseñan
datos que se necesitan para implementar el sus interfaces.
software.
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
1
Claves del diseño Reglas de Diseño

z Identificar dos fases: z En el proceso de diseño no usar “orejeras”.
z Diversificación z El diseño debe rastrearse hasta el modelo del
z Convergencia análisis.
⇓ z El diseño no debe inventar nada que ya este
Intuición y juicio en función de la inventado.
experiencia adquirida z El diseño no es escribir código.
z El diseño debe evaluarse en términos de la
calidad y mientras se va creando.
Subsistemas y módulos Principios de Diseño

z Un subsistema es un sistema por sí mismo z Un principio para tener presente durante el
cuya operación no depende de los servicios proceso de diseño es el diseño para el
suministrados por otros subsistemas. Los cambio.
subsistemas se componen de módulos y tienen
z Cambio de algoritmos
interfaces definidas que se utilizan para la
comunicación con otros subsistemas. z Cambio en la representación de datos
z Cambio de plataforma (máquina virtual)
z Un módulo es generalmente un componente
del sistema que suministra uno o más servicios z Cambio de dispositivos periféricos
a otros módulos. Utiliza los servicios z Cambio del entorno social
suministrados por otros módulos. Por lo general z Se relaciona con la calidad de evolutividad.
no se considera un sistema independiente.
Modularización
z La modularización es un principio
Modularización fundamental del diseño..
z La descomposición modular se realiza en
varias etapas y de varias formas y se aplica
en forma iterativa.
Conceptos relacionados con el z Las estrategias de descomposición son:
principio de “modularización” z Estrategia top down (descendente)
z Estrategia bottom-up (ascendente)
z Combinación de ambas estrategias
2
Técnicas de Modularización Descomposición modular

z Módulo: es un componente bien definido de Costo de
integración
un sistema de software. Es un proveedor de Costo total
del SW
un recurso o servicio computacional.
COSTO DE ESFUERZO
z Interesa definir las relaciones entre los REGION DE
módulos: COSTO
MÍNIMO
z Para asignar tareas.
z Para controlar el desarrollo.
Costo / módulo
NUMERO DE MODULOS
Técnicas de Modularización Técnicas de Modularización

z Sea S un sistema de software compuesto por z La clausura transitiva de una relación r en S, es
módulos M1, M2, ... Mn también una relación en S, que se nota r+.
S = {M1, M2, ... Mn}
z Sean Mi, Mj ∈ S, Mi r+ Mj si y sólo si:
z Una relación r en S, es un subconjunto de S x S. z Mi r M j o
Si Mi y Mj están en S, decimos que < Mi,Mj> ∈ r, y z ∃ Mk ∈ S tal que Mi r Mk y Mk r+ Mj
usamos la notación Mi r Mj
z Estudiamos relaciones que describan relaciones z Una relación r es una jerarquía si y sólo si
mutuas entre módulos. Asumimos que r es z no existen dos elementos Mi, Mj ∈ S tal que Mi r+ Mj
irreflexiva, esto es que Mi r Mi no es válido para y Mj r+ Mi
ningún módulo Mi ∈ S.
Técnicas de Modularización La Relación “usa”

z La clausura transitiva capta la idea intuitiva de z Para dos módulos distintos Mi y Mj se dice que
relaciones directas o indirectas.
Mi usa Mj si y sólo si la correcta ejecución de Mj
z Ejemplo: sean dos módulos A y B, A invoca+ B, esto
es, A invoca directamente a B, o indirectamente a es necesaria para que Mi complete la tarea
través de una cadena de invocaciones. descripta en su especificación.
z Las relaciones se pueden representar mediante

z Si Mi usa Mj se dice que Mi es cliente de Mj, ya
grafos dirigidos, donde los nodos son
que Mi requiere los servicios de Mj.
nombrados con los elementos de S, y existe un
arco entre Mi y Mj si y sólo si Mi r Mj
3
La Relación usa Cohesión y Acoplamiento

z Un módulo tiene máxima cohesión si todos sus
z Una buena restricción para la relación usa es
elementos están fuertemente relacionados.
que sea una jerarquía. Cooperan para lograr un objetivo común.
z La cohesión es una propiedad interna del
z Beneficios: módulo.
z Facilidad de comprensión. z El acoplamiento mide la interdependencia
z La estructura resultante define el sistema a entre módulos
través de niveles de abstracción. z Un buen diseño debe:
z maximizar la cohesión y
z minimizar el acoplamiento.
Fan In – Fan Out

z En el gráfico de la relación usa:
z El número de arcos salientes de un módulo es el FAN Diseño de Sistemas
OUT.
z El número de arcos entrantes de un módulo es el FAN
IN.
z Un buen diseño debiera mantener un fan out

bajo y un fan in alto.
Diseño Orientado a Objetos
Decisiones de Diseño Partición en Subsistemas

z Organizar el sistema en subsistemas (Diseño z El primer paso de diseño es dividir el sistema en un
arquitectónico). número pequeño de componentes.
z Identificar la concurrencia. z Cada componente principal es un subsistema.
z Asignar subsistemas a procesadores. z Cada subsistema engloba aspectos del sistema que
z Elegir enfoque para implementación de comparten propiedades comunes:
almacenamientos. z Funcionalidad, ubicación física, ejecución en el mismo
z Administrar acceso a recursos generales. hardware.
z Elegir implementación de control. z Un subsistema es un paquete de clases,

asociaciones, operaciones, eventos y restricciones
z Manejar condiciones límites.
interrelacionados con una interface razonable y
z Setear balance de prioridades. pequeña.
4
Subsistemas Relaciones entre Subsistemas

z Un subsistema se identifica por los servicios que z Cliente-Servidor: el cliente invoca al servidor
provee: grupo de funciones relacionadas que para que realice un servicio y este responde
comparten un propósito común. con un resultado.
z Cada subsistema tiene interfaces bien definidas. El cliente conoce las interfaces del
z En menor nivel de abstracción se definen servidor, no a la inversa.
módulos.
z Par a Par: cada subsistema puede invocar a
z La relación entre dos subsistemas puede ser: los demás.
z Cliente-servidor Cada subsistema debe conocer las
z Par a par (peer to peer) interfaces de los demás.
Descomposición en Capas y
Particiones Diseño en Capas
z La descomposición de un sistema en
z Un sistema en capas es un conjunto
subsistemas puede ser organizada como:
ordenado de mundos virtuales, cada uno
z Capas (horizontales)
construido en términos de los inferiores y
z Particiones (verticales) proveyendo la base de implementación para
los superiores.
z El conocimiento es en una sola vía (se
conocen las capas inferiores).
Capas Capas
z Las arquitecturas por capas pueden ser:
z La capa superior es el sistema deseado.
z Abiertas: usa aspectos de cualquier capa
inferior. z La capa inferior son los recursos disponibles:
hardware, sistema operativo, librerías.
z Reduce la necesidad de redefinir operaciones.
z Menos robusta.
z Permite portabilidad reescribiendo una sola
capa.
z Es más difícil reemplazar una capa.
z Es recomendable introducir una capa de
z Cerradas: construida en términos de la capa
abstracción entre la aplicación y los servicios
inmediata inferior. provistos por el sistema operativo o hardware.
z Respeta principio de ocultamiento de información.
5
Diseño en Particiones Capas y Particiones

z Las particiones dividen verticalmente al
sistema en subsistemas independientes o
débilmente acoplados, cada uno proveyendo un
tipo de servicio.
z Ejemplo:
z En un SO se pueden distinguir el sistema de
archivos, control de procesos, manejo de memoria
virtual y manejo de dispositivos.
z Un sistema puede sucesivamente dividirse en
capas y particiones.
Topología del Sistema Identificación de Concurrencia

z El diseñador debe mostrar el flujo de z Identificar el procesador dónde serán
información entre subsistemas usando un implementados los objetos.
diagrama de flujo de datos.
z Posibilidades: Pipeline – Estrella z Identificar objetos concurrentes.
z Estrella: un subsistema controla la interacción
con todos los demás.
z Identificar objetos mutuamente excluyentes y
z Usar topologías simples para minimizar agruparlos en threads o tareas.
interacciones.
Definición de tareas
Concurrencia Inherente concurrentes
z El modelo dinámico es una guía para identificar z Thread (hilo) de Control: es un camino a
la concurrencia. través del diagrama de estados en el cual hay
z Dos objetos son inherentemente concurrentes si un sólo objeto activo.
pueden recibir eventos simultáneamente sin z Un hilo permanece en un diagrama hasta que
interactuar entre sí. se envía un evento a otro objeto. Eventualmente
z Aunque todos los objetos son conceptualmente puede retornar.
concurrentes, en la práctica varios objetos de un z El hilo se bifurca si envía un evento y sigue
sistema son interdependientes. ejecutando.
z Son deseables subsistemas independientes, z Los hilos se implementan como tareas.
para asignarlos a diferentes computadores.
6
Asignación de subsistemas a Estimación de Requerimientos

procesadores de Recursos de Hardware
z Cada subsistema se asigna a un procesador. z La decisión de usar múltiples procesadores está
z El diseñador debe: basada en la necesidad de mayor performance
que una CPU.
z Estimar necesidades de performance y recursos
necesarios. z Deben considerarse el volumen de cálculo y la
z Elegir la implementación por HW o SW.
velocidad de la máquina.
z Asignar subsistemas a procesadores. z Estimación tiempo de procesamiento:
z Nro. Transacciones p/seg * Tiempo p/transacc
z Determinar conectividad de las unidades físicas.
Asignación de Tareas a
Consideraciones de Hw-Sw Procesadores
z Decidir qué subsistemas serán implementados z Criterios:
por hardware y cuales en software. z Ciertas tareas se requieren en determinada
z Razones para implementar en HW: ubicación física, por ejemplo para controlar cierto
z HW provee exactamente la funcionalidad requerida. hardware.
z Si se necesita mayor performance que la actual y z El tiempo de respuesta o el flujo de información
existe HW más eficiente. de una tarea.
z Tener presente la flexibilidad ante futuros z Minimizar costo de comunicaciones. Subsistemas
cambios. independientes podrían asignarse a
procesadores separados.
Determinación de la Administración de
Conectividad Física Almacenamientos de Datos
z Diferentes clases de almacenamientos proveen distintos
z Después de determinar el tipo y número de tipos de consideraciones: costo, tiempo de acceso,
unidades, decidir cómo se van a conectar: capacidad, confiabilidad.
z Elegir la topología de conexión. z Archivos:
z Elegir la topología de unidades repetidas. Tienen z son económicos, simples. Se necesita código adicional para su
inspección.
un patrón regular: secuencia lineal, estrella, árbol. z Las aplicaciones portables deben aislar las dependencias con el
z Elegir la forma de canales de conexión y los file system.
protocolos de comunicación (sincrónica, z Bases de datos administradas por DBMS (Data Base
asincrónica). Management System).
z Buscan optimizar costo y performance en accesos de memoria a
disco.
z Aplicaciones con DBMS más fáciles de portar. Pueden tener
Análisis y Diseño de Sistemas - Clase 24 interfaces complejas.
7
Bases de Datos Sistema de Archivos

z Características de los datos que favorecen el z Características de los datos que favorecen el uso
uso de DBMS: de archivos:
z Datos con acceso a detalles, con niveles finos de z Datos con baja densidad de información, como
abstracción utilizados por varios usuarios.
por ejemplo dumps, registros históricos.
z Datos que pueden ser eficientemente manejados con
z Datos crudos que están sumarizados en la base
los comandos del DBMS.
z Datos portables a través de varias plataformas de
de datos.
HW y SO. z Datos volátiles que se guardan poco tiempo y
z Datos que deban estar accesibles por varios luego se descartan.
programas de aplicación. z Datos no estructurados.
Ventajas de usar una BD

Desventajas de usar una BD
z Proveen facilidades:
z Recuperación sin pérdida de información. z Performance (analizar).
z Compartir datos: z Funcionalidad insuficiente para aplicaciones
z Entre varios usuarios.
z Entre varias aplicaciones.
avanzadas que requieran tipos de datos más
z Distribución de datos. complejos u operaciones no estándar.
z Integridad. z Interfaces complejas con lenguajes de
z Soporte de transacciones. programación.
z Posibilidades de extensión.
z Cada aplicación accede al subconjunto de datos que
necesita e ignora el resto.
z Lenguaje de acceso estándar.
Administración de Recursos Administración de Recursos

Globales Globales
z El diseñador deben identificar y determinar z Si el recurso es un objeto lógico, se puede
mecanismos para controlar el acceso a recursos controlar mediante un objeto guardián.
globales. z Todos los accesos deben pasar por el objeto
z Entre los recursos globales se incluyen: unidades guardián.
físicas (procesador, periféricos, líneas de z Un guardián puede controlar varios recursos.
comunicaciones), espacio en disco, terminales,
nombres de bases de datos, nombres de clases, z Un recurso lógico se puede particionar para
acceso a datos compartidos. que sea controlado por varios objetos
guardianes.
z Si el recurso es un objeto físico, se controla
z Ejemplo:
estableciendo un protocolo para obtener el z Estampilla de tiempo de transacciones en sistema
acceso en un sistema concurrente. distribuido.
8
Administración de Recursos Elección de la Implementación

Globales del Software de Control
z El los sistemas con restricciones fuertes de z En general se elige una implementación común
tiempo puede resultar crítico el costo de pasar para todo el sistema.
todos los recursos a través del objeto z Existen dos formas de flujos de control:
guardián. En su lugar se pueden ubicar z Control Externo: responde a eventos externamente
visibles
lockeos. z Control Interno: corresponde con el flujo de control
z Lockeo: objeto lógico asociado con un dentro de un proceso.
subconjunto del recurso que da al poseedor z Control Externo: existen tres clases de control
del lockeo el derecho de acceso al recurso. para los eventos externos:
z Secuencial conducido por procedimientos.
z Secuencial conducido por eventos.
z Concurrentes.
Sistemas Conducidos por

Software de Control Procedimientos
z Control Interno: flujo de control dentro de un z El control reside dentro del código.
proceso. Existe sólo en la implementación y por lo z El procedimiento requiere una entrada externa,
tanto no es inherentemente secuencial ni cuando el input llega, el control vuelve al proceso
concurrente. que efectúo la llamada.
z Son comunes: z Estado del sistema: ubicación del puntero del
z Llamados a procedimientos. programa + pila de llamadas a procedimientos +
z Llamados a tareas casi-concurrentes. variables locales
z Llamados entre tareas concurrentes.
z Ventajas: Es fácil de implementar.
z Casi-Concurrentes: corutinas o procesos de menor peso. z Desventajas: Se necesita mapear la concurrencia a
Conveniencias de programación en la cual existen múltiples un flujo de control secuencial.
escenarios de direcciones o pilas de llamadas pero sólo un
thread de control activo.
Sistemas Conducidos por Sistemas Conducidos por

Eventos Eventos
z El control reside en un despachante o monitor provisto
por el lenguaje, subsistema o sistema operativo. z Los procedimientos deben usar variables globales para
mantener el estado o el despachante debe mantener
z Los procedimientos de la aplicación están asociados a
los eventos y son llamados por el despachante cuando estados locales para ellos.
ocurre el correspondiente evento.
Ventajas:
z Los llamados de procedimientos al despachante envían
el output o permiten el input pero no esperan en línea. z Permiten patrones de control más sencillos que los
z Todos los procedimientos envían el control al conducidos por procedimientos.

despachante.
z Los eventos son manejados directamente por el z Da lugar a sistemas más modulares y pueden manejar
despachante. mejor las condiciones de error.
9
Sistemas Concurrentes Control Interno

z El control reside concurrentemente en varios z Las interacciones internas entre objetos pueden
objetos independientes, cada uno en tareas ser vistas de manera similar a las interacciones
separadas.
externas entre objetos.
z Una tarea puede esperar por un input, pero
otras continúan con su ejecución. z La diferencia importante es que las interacciones
externas incluyen la espera por eventos, no se
z Los SO proveen mecanismos de colas.
fuerza a que los objetos respondan.
z El SO resuelve los conflictos de planificación
entre tareas. z En las interacciones internas los patrones de
respuesta son predecibles. Muchos se pueden
implementar como llamados a procedimientos.
Manejo de Condiciones
Otros Paradigmas Límites
z Otros paradigmas: z Inicialización: Se deben inicializar datos constantes,
z Sistemas basados en reglas parámetros, variables globales, tareas, objetos
guardianes. Puede estar disponible un subconjunto de la
z Sistemas de programación lógica funcionalidad.
z Programas de formas no procedurales z Terminación: más sencillo que la inicialización. La
mayoría de los objetos se abandonan. Se deben liberar
recursos que hayan sido reservados. En un sistema
z Estos constituyen otros sistemas de control en concurrente la tarea debe notificar su fin.
el cual el control explícito es reemplazado por z Caídas: terminación no planeada del sistema. Errores
especificaciones declarativas con reglas de del usuario, agotamiento de recursos, caídas externas.
evaluación implícitas, posiblemente no El buen diseñador debe planificar una salida ante los
casos de error dejando el entorno lo más limpio posible
determinísticas. y guardando información.
Balance de Prioridades Temas de la clase de hoy

z Muchas veces están definidas en los requerimientos, z Diseño de Sistemas
pero otras el diseñador debe reconciliar deseos z Modularización
incompatibles del cliente y decidir un balance. z Cohesión y Acoplamiento
z Decisiones del Diseño
z No se hacen todos los balances en el diseño, pero se
establecen las prioridades.
z Bibliografía:
z El sistema se puede ver afectado por el balance de “Fundamentals of Software Engineering”. Carlo
decisiones hechas por el diseñador. Ghezzi – Capítulo 5.
z Si no se establecen prioridades amplias del sistema “Object Oriented Modeling and Design”.
puede suceder que distintas partes optimicen Rumbaugh – Capítulo 9.
objetivos contrapuestos.
10

ADS-mod 24

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ADS-mod 24

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación

Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.

Diseño Diseño de Sistemas

Modelos del Diseño Modelos del Diseño

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Claves del diseño Reglas de Diseño

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Subsistemas y módulos Principios de Diseño

Técnicas de Modularización Descomposición modular

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Técnicas de Modularización Técnicas de Modularización

Técnicas de Modularización La Relación “usa”

z Las relaciones se pueden representar mediante

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

La Relación usa Cohesión y Acoplamiento

Fan In – Fan Out

z Un buen diseño debiera mantener un fan out

Análisis y Diseño de Sistemas - Clase 24

Decisiones de Diseño Partición en Subsistemas

z Elegir implementación de control. z Un subsistema es un paquete de clases,

Subsistemas Relaciones entre Subsistemas

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Diseño en Particiones Capas y Particiones

Topología del Sistema Identificación de Concurrencia

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Asignación de subsistemas a Estimación de Requerimientos

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Bases de Datos Sistema de Archivos

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Ventajas de usar una BD

Administración de Recursos Administración de Recursos

Administración de Recursos Elección de la Implementación

Sistemas Conducidos por

Sistemas Conducidos por Sistemas Conducidos por

z Todos los procedimientos envían el control al conducidos por procedimientos.

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Sistemas Concurrentes Control Interno

Análisis y Diseño de Sistemas - Clase 24 Análisis y Diseño de Sistemas - Clase 24

Balance de Prioridades Temas de la clase de hoy

S-ar putea să vă placă și