Diseño del Software

Diseño del Software
Requirements
specification
Design acti
vities
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specifica
tion
Component
specification
Data
structure
specification
Algorithm
specifica
tion
Design pr
oducts
De la Arquitectura al Diseño
ξ ≅ ∃ω α(ω) ⇒ (α ∧ σ) ∨ ∀ε β(ε) ⇒ρ(ε)
∨ ∀ ε ε ∉ Ω ∧ ∑φ(ε) ≈ 2.4 ∨ ¬λ ⇒δ≤τ
program pepe();
Diseño del Software
Ingeniería del Software 1
2
Criterios Generales
n
n
n
No existe “el” método ni “el” criterio
general
Hay criterios
Uso de varias técnicas
– Formalidad vs. facilidad de instrumentos
n
División en módulos para reducir la
complejidad y prevenir cambios
Diseño del Software
Ingeniería del Software 1
3
Módulos: Visión estática
n
De c/u de los
subsistemas.
n
– El detalle hacia el
código
n
n
pueden estar
divididos en submódulos
no son rutinas
– pueden tener
memoria persistente
Diseño del Software
n
Herramienta para
reagrupar tipos,
estructuras de
datos,
subprogramas, etc.
Porción de software
que brinda recursos
y servicios
computacionales
Ingeniería del Software 1
4
Diseño
n
Esta fase se refiere
por lo tanto a la
identificación de
varios módulos y su
interrrelación
Diseño del Software
Ingeniería del Software 1
5
Estrategias de Diseño
u
Diseño funcional
•
u
El sistema es diseñado desde un punto de vista funcional. El
estado del sistema es centralizado y compartido entre las
funciones que operan sobre el mismo.
Diseño Orientado a Objetos
•
El sistema es visto como una colección de objetos
interactuando. El estado del sistema es decentralizado y cada
objeto maneja su propio estado. Objetos pueden ser instancias
de clases de objetos y pueden comunicarse a través de métodos.
Diseño del Software
Ingeniería del Software 1
6
Factores Principales
n
Cohesión:
n
– unidad
sustancialmente
homogénea y que
sea fácilmente
comprendida
Desacoplamiento
– entre módulos
– ser comprendidos
mirando sólo a ellos
Hacen a la independencia funcional
Alta cohesión no implica alto desacoplamiento, ni
viceversa
Diseño del Software
Ingeniería del Software 1
7
Niveles Cohesión
u
Coincidental cohesion (débil)
•
u
Logical association (débil)
•
u
Componentes que realizan funciones similares son agrupadas
Temporal cohesion (débil)
•
u
Las partes son unidas por coincidencia
Componentes que son activadas al mismo tiempo son agrupadas
Procedural cohesion (débil)
•
Los elementos en una misma secuencia son agrupados
Diseño del Software
Ingeniería del Software 1
8
Niveles de Cohesión
u
Communicational cohesion (media)
•
u
Sequential cohesion (media)
•
u
El output de una parte del componente es el input de otra parte
Functional cohesion (fuerte)
•
u
Todos los elementos de una misma componente operan sobre el
mismo input o producen el mismo output
Cada parte de una componente es necesaria para la ejecución de
una función
Object cohesion (fuerte)
•
Cada operación provee funcionalidades para modificar o
inspeccionar los atributos de un objeto
Diseño del Software
Ingeniería del Software 1
9
Acoplamiento fuerte
Module A
Module C
Module B
Module D
Shared data
area
Diseño del Software
Ingeniería del Software 1
10
Acoplamiento débil
Module A
A’s data
Module B
Module C
B’s data
C’s data
Module D
D’s data
Diseño del Software
Ingeniería del Software 1
11
Hacia un Diseño Modular
5 Criterios
– Descomponibilidad
– Componibilidad
– Comprensibilidad
– Continuidad
– Protección
5 Reglas
– Mapeo Directo
– Pocas Interfaces
– Pequeñas interfaces
– Interfaces explícitas
– Information Hiding
5 Principios
– Unidad Lingüística Modular
– Autodocumentación
– Uniformidad de Acceso
– Abierto-Cerrado
– Simple Opción
Diseño del Software
Ingeniería del Software 1
12
Descomponibilidad Modular
n
Un método de construcción
satisface DM si ayuda en la
tarea de descomposición
del problema software en
un número de problemas
menos complejos
conectados por una
estructura simple y lo
suficientemente
independiente para permitir
que el resto del trabajo
proceda separadamente
(B. Meyer)
Diseño del Software
n
n
n
n
División de Trabajo
Dependencias: pocas pero
Conocidas
Ej. Top-Down Design
ContraEj.: Módulo global de
inicialización
–
–
–
–
buena cohesión temporal
poca autonomía modular
se rompe information hiding
En OO cada módulo es
responsable de su
inicialización.
Ingeniería del Software 1
13
Componibilidad Modular
n
Un método de construcción
satisface CM si ayuda en la
producción de elementos
que pueden ser libremente
compuestos uno con el otro
para producir sistemas
nuevos, posiblemente en un
ambiente distinto del cual
fue inicialmente
desarrollado.
(B. Meyer)
n
n
n
– atención con Top-Down
Design
n
n
n
Diseño del Software
Sacarlos del contexto
original para ser reusados
El sueño de la fábrica de
ensamblaje
Independiente de
Descomponibilidad
EJ.1.: librerías
Ej.2: Shells Unix
ContraEj.: Preprocesadores
(c++)
Ingeniería del Software 1
14
Comprensibilidad Modular
n
Un método de construcción
satisface Comprensibilidad
Modular si ayuda en la
producción de software en la
cual un lector humano puede
entender cada módulo sin
tener que conocer o
examinar a ninguno del
resto.
n
Proceso de Mantenimiento
n
ContraEj.: dependencia
secuencial A!B!C (se
entiende B sin A y C?)
n
Documentación
(B. Meyer)
Diseño del Software
Ingeniería del Software 1
15
Continuidad Modular
n
Un método de construcción
satisface Continuidad
Modular, si en la arquitectura
de software en la cual se
basa, un pequeño
problema en la
especificaicón dispara un
cambio de sólo un módulo
o un pequeño grupo de
módulos
(B. Meyer)
Diseño del Software
n
n
n
n
n
n
Extendibilidad
No definible formalmente
Ej.1.: Constantes simbólicas
Ej.2.: Principio de Acceso
Uniforme (a un objeto sea
este un dato directo o algo a
ser computado)
ContraEj.1: Usar
representaciones físicas
ContraEj.2: Arrays estáticos
Ingeniería del Software 1
16
Protección Modular
n
Un método de construcción
satisface Protección
Modular, si lleva a que en
las arquitecturas en las que
ocurre una condición
anormal en run time en un
módulo queden confinados
al mismo, o a lo sumo sólo a
pocos vecinos.
(B. Meyer)
Diseño del Software
n
Evitar propagación de
Errores Runtime por
hardware, mal input, falta de
recursos como memoria, etc.
n
Ej.: validar input en la fuente
n
ContraEj.: Excepciones
Indisciplinadas
Ingeniería del Software 1
17
Mapeo Directo
n
Una estructura modular
definida en el proceso de
construcción de un sistema
software debe mantenerse
compatible con toda
estructura modular definida
en el proceso de modelar el
dominio del problema.
(B. Meyer)
n
n
n
Modelos
Continuidad
Descomponibilidad
(aprovechar lo hecho)
Diseño del Software
Pocas Interfaces
n
Cada Módulo debe
comunicarse con los menos
posibles de otros
(B. Meyer)
n
n
n
Si hay n módulos en lo
posible lo más cerca de n-1
conexiones y no a n(n-1)/2!
Continuidad
Componibilidad
Ingeniería del Software 1
18
Pequeñas Interfaces Explícitas
n
Si dos módulos se
comunican, deberían
intercambiar la menor
cantidad de información
posible.
(B. Meyer)
n
n
n
Cuando dos módulos A y B
se comunican, esto debe ser
obvio del texto código de
ambos.
(B. Meyer)
n
Continuidad
Protección
ContraEj.: Common de
Fortran, Programación
extremadamente
estructurada (muchos
parámetros)
Diseño del Software
n
n
n
n
n
Continuidad
Componibilidad
Descomponibilidad
Comprensibilidad
Problema con los
acoplamientos indirectos
como por Shared Memory
Ingeniería del Software 1
19
Information Hiding
n
El diseñador de cada
módulo debe seleccionar un
subconjuto de propiedades
del módulo como la
información oficial sobre el
mismo, para hacerlo
disponible a los autores de
los módulos clientes.
(B. Meyer)
n
n
No implica protección
Encapsulamiento
Diseño del Software
n
n
n
n
n
n
n
n
Propiedades Publicas y
Privadas (o secretas)
Separación de funciones de
implementación (TDA y OO)
Interfaz --- Iceberg
Continuidad
Descomponibilidad
Componibilidad
Comprensibilidad
Ej.: procedimiento de
acceso a una tabla indexada
Ingeniería del Software 1
20
Notación
n
Sea M un conjunto de módulos:
M = {m1,m2,....,mn}
n
Una relación R sobre M es
R⊆MxM
n
Un módulo mi está en relación R con mj
ssi <mi,mj> ∈ R.
Notación: miRmj
Diseño del Software
Ingeniería del Software 1
21
Representación en Grafo
n
Grafo dirigido
a
G = <N,A>
A⊆NxN
N≅M
A≅R
n
b
Ej: M = {a,b,c,d,e}
R = {<a,b>,<a,e>,<b,c>
<e,d>,<d,c>}
Diseño del Software
c
Ingeniería del Software 1
e
d
22
Características de la relación
n
n
n
No puede ser reflexiva: <mi,mi> ∉ R
puede ser simétrica y transitiva
grafos acíclicos:
– Ej.: árboles
– si ∀i <mi,mi> ∉ R* (clausura transitiva)
– directo y acíclico ⇒ jerarquía
• muchos caminos entre dos nodos
• concepto de nivel
Diseño del Software
Ingeniería del Software 1
23
Distintos Niveles
System level
Sub-system
level
Diseño del Software
Ingeniería del Software 1
24
La relación USA
n
n
Describe las
n mi esta en relación
funcionalidades que
USA con mj
brinda un módulo y
(mi USA mj ) si para
cuales son las
que el módulo mi
sea correcto si
funcionalidades que
necesita la correcta
un módulo necesita
ejecución de mj .
mi resulta ser un
cliente de los
servicios que provee
mj
Ingeniería del Software 1
25
Diseño del Software
La relación USA
n
n
n
n
se define
estáticamente
describe el
desacoplamiento
llamadas a
procedimientos no
siempre implican
USA y viceversa
aciclicidad
Diseño del Software
n
Casos extremos:
– USA = M x M
– USA = ∅
n
Indicaciones:
– minimizar arcos
salientes
– maximizar arcos
entrantes
análisis por niveles
de
abstracción
Ingeniería del Software 1
26
n
La relación Es_Componente_De
n
n
Relación en la
dirección de
refinamiento
sucesivos (topdown)
Debe ser una
jerarquía (no
necesariamente un
árbol)
Diseño del Software
n
n
Sólo las hojas se
implementan
efectivamente
Los nodos internos
son módulos lógicos
Ingeniería del Software 1
27
Indicaciones
n
n
n
Redefinición de USA
respecto a
Es_Componenete_De
Construcción
Incremental
Postergar las
decisiones
Diseño del Software
n
INFORMATION HIDING
– cajas negras
– definidas por los servicios
que brindan
– Interfaz e Implementación
– Exportación e Importación
– principio de división de
trabajo
– ¿Qué esconder?
Ingeniería del Software 1
28
Descripciones de Diseño
u
u
u
u
Notaciones Gráficas. Usadas para mostrar
relaciones entre los componentes
Lenguajes de descripción de Programas. Basados
en lenguajes de prog. pero con más flexibilidad
para representar conceptos abstractos.
Texto informal Descripción en lenguaje natural
Todas estas notaciones pueden ser usadas para
diseñar sistemas grandes
Diseño del Software
Ingeniería del Software 1
29
Diseño Orientado a Objetos
n
Estrategia de diseño basada en
– INFORMATION HIDING
– ABSTRACCION
– MODULARIDAD
n
Crea una representación del mundo
real y lo corresponde con una solución
basada en los datos
Diseño del Software
Ingeniería del Software 1
30
Diseño OO
n
El software es visto como un conjunto
de objetos que interactúan, con su
estado privado, en vez de un conjunto
de funciones que comparten un estado
global O2
O1
estado 1
estado 2
O4
estado 4
O3
estado 3
El mundo es visto como un conjunto....
Diseño del Software
Ingeniería del Software 1
31
Características
n
Los objetos son abstracciones del mundo real o entidades del
sistema que son responsables de manejar su estado privado y
ofrecen servicios a otros objetos.
– Son un modelo de los objetos externos que pueblan el
mundo en que actúa el programa.
n
Los objetos son entidades independientes que pueden ser
rápidamente cambiados por la información de la representación
y el estado queda dentro del objeto.
– un objeto es caracterizado al exterior sólo por la interfaz que
brinda, es decir el conjunto de recursos que pone a
disposición.
Diseño del Software
Ingeniería del Software 1
32
Características
n
La funcionalidad del sistema es expresada en términos de operaciones
y servicios asociados con cada objeto.
n
Áreas de datos compartidos son eliminados. Los objetos se comunican
llamando los servicios ofrecidos en vez de compartir variables.
– Disminuye el acoplamiento
– Disminuye el riesgo de modificaciones a datos compartidos
n
Los objetos pueden ser distribuidos y pueden ejecutarse en paralelo o
concurrentemente. Estas decisiones no deben tomarse tempranamente.
– recordar: posponer lo mayor posible toda decisión trascendente de
diseño.
Diseño del Software
Ingeniería del Software 1
33
No preguntes qué hace el sistema sino qué le
hace a qué cosa
n
OOD es el método
que permite definir
arquitecturas del
software basados
en los objetos que
todo sistema o
subsistema usa
Diseño del Software
n
OOD es la
construcción de
sistemas software
como una colección
estructurada de
TAD.
Ingeniería del Software 1
34
Criterios
n
n
n
n
n
Descomponibilidad: facilidad de descomponer un
gran problema en subproblemas
Componibilidad: facilidad de reuso
Comprensibilidad: facilidad de entender un
módulo por sí solo
Continuidad: pequeños cambios implican pocos
cambios
Protección: reducir efectos colaterales
lo buscado por cualquier método de diseño
Diseño del Software
Ingeniería del Software 1
35
7 conceptos
n
n
n
n
Object based modular structure: los sistemas
están modularizados en base a su estructura de
datos.
Data abstraction: los objetos deberían ser
descriptos como implementaciones de TADs.
Automatic Memory Management: los objetos no
usados deberían ser liberados por el lenguaje
subyacente.
Clases: cada tipo no primitivo es un módulo y
cada
módulo de altoIngeniería
niveldeles
un tipo.
Software 1
36
Diseño del Software
7 conceptos
n
n
n
Una clase puede ser definida como una
extensión o una restricción sobre otras.
Polimorfismo y Dynamic Binding: se
deben permitir referencias a objetos de más
de una clase y las operaciones deben poder
realizarse en diferentes clases.
Múltiple y repetida herencia: debe ser posible
declarar una clase como herede de más de
una clase o más veces de la misma.
Diseño del Software
Ingeniería del Software 1
37
Clases
n
module
La clase es el tipo del objeto
implementation
Clase Persona
atributos
nombre: string;
apellido: string;
servicios
Mario
Rossi
Francisca
Verdi
Carla
Bianchi
presentate()
exports
clase persona: descripción de las características
comunes a todos los objetos de tipo persona
Diseño del Software
Ingeniería del Software 1
38
HERENCIA
En el mundo real los objetos son clasificados según
características comunes
Título del diagrama
Vertebrados
Peces
Corvinas
Anfibios
Surubíes
Reptiles
Pájaros
Mamíferos
Carnívoros
Herbívoros
El mismo principio se puede aplicar a los objetos de un
programa. La clasificación se hace definiendo un
nuevo tipo como extensión de un tipo preexistente
Diseño del Software
Ingeniería del Software 1
39
La relación HEREDA_DE
presentate()
Persona
Atributos
nombre: string;
apellido: string
presentate()
Estudiante
Atributos
matrícula: int;
Diseño del Software
la clase (el módulo) estudiante
“extiende” la clase (el módulo)
persona:
n AGREGANDO un nuevo
atributo (matrícula)
n REDEFINIENDO un servicio
(presentate)
Heredadas
Heredadaspor
por
ser
persona
ser personatambién
también
nombre = Piero
apellido = Fraternalli
matricula = 585/96
presentate() = “Buen día soy
Fraternalli, estudiante 585/96”
Ingeniería del Software 1
40
HEREDA_DE => ES_UN (IS_A)
unión
nombre
Persona
peso
existe
vacío
Hombre
Embarazada
Mujer
Conj. de
Enteros
Conj. de
Enteros
Ordenados
1er Elem
Diseño del Software
Ingeniería del Software 1
existe
41