Fundamentos diseño software

1
Unidad I Unidad Curricular Ingeniería de Software II; Modulo: FUNDAMENTOS DE DISEÑO DE SOFTWARE
Profesor Alfonso Galea Bracho
Diseño
El diseño es una
representación de
algo que se desea
construir
Software
Es el conjunto de los programas de
cómputo, procedimientos,
reglas, documentación y datos
asociados que forman parte de las
operaciones de un sistema de
computación
Diseño DE SOFWARE
•“Búsqueda de soluciones que se ajusten a los requisitos
o requerimientos del usuario”
•“Proceso “repetitivo” mediante el cual los requisitos se
traducen en un “plano” para construir el software”
•“Proceso de definir la arquitectura, componentes,
interfaces y otras características de un sistema”

2
Diseño es un proceso repetitivo
“El diseño no es escribir código y
escribir código no es diseñar”

3
Contexto del diseño de software
•El diseño es técnicamente la parte central de la ingeniería
del software
•Durante el diseño se desarrollan, revisan y se documentan
los refinamientos progresivos de las estructuras de
datos, de la estructura del programa y de los detalles
procedimentales.
•El diseño da como resultado representaciones cuya
calidad puede ser evaluada.
•Establece una plataforma para la construcción
(generación de código y prueba).

4
Proceso del diseño de software
•Diseño de Datos: MODELO ER y DD
•Diseño arquitectónico: Describe cómo se
descompone y como están organizados los
componentes en el software A TRAVES DE
MODELOS
•Diseño de Interfaz: Comunicación del software
consigo mismo, con los sistemas que operan
con él y con los operadores que lo emplean.
•Diseño Detallado o Procedimental: Describe el
comportamiento específico de los componentes

5
IMPORTANCIA DEL DISEÑO DE
SOFTWARE
“El diseño traduce con precisión los requisitos o requerimientos
del cliente en un producto o sistema acabado”
“El diseño de software es la base para las fases posteriores

6
METODOS PARA LA ACTIVIDAD
DE DISEÑO DE SOFTWARE
los métodos de diseño tienen varias características
comunes:
1) Mecanismo para la traducción de requisitos
en una representación de diseño.
2) Notación para representar los componentes
funcionales y sus interfaces.
3) Heurísticas o creatividad para el refinamiento
y la partición o subdivisión

7
METODOS PARA LA ACTIVIDAD
DE DISEÑO DE SOFTWARE
los métodos de diseño tienen varias características
comunes:
Sus actividades son:
• DISEÑO DE DATOS
• DISEÑO ARQUITECTONICO
• DISEÑO DE INTERFAZ
• DISEÑO PROCEDIMENTAL

8
ESTRATEGIAS DE DISEÑO DE
SOFTWARE
Declaración de alto nivel sobre el enfoque del
Sistema de Información a desarrollar QUE
SIGUEN LOS METODOS O METODOLOGIAS
Incluye la funcionalidad del sistema, el
hardware y la plataforma de software del
sistema, y el método o metodología para su
adquisición o desarrollo.

9
Estrategia de diseño orientado a
funciones o estructural
Es la organización de los módulos
(procedimientos y funciones)
Para conseguir la funcionalidad descrita en
el análisis.
Se considera dentro de la categoría de las
estrategias orientadas por la función.

10
Estrategia de diseño estructural
HERRAMIENTAS DE REPRESENTACION
•Diagrama de estructura.
•Lenguaje de especificación de módulos
• Especificación de las interfaces de
módulos
• Especificación por pseudocódigo.

11
DIAGRAMA DE ESTRUCTURA

12
Especificación de módulos por interfaces
Modulo Seleccionarsitiodepasajeros
Propósito Elegir para cada cliente el sitio que cumpla los requisitos de su clase y
preferencias
Usa Preferencias,sitio.
Devuelve Sitio_seleccionado;Preferencias_disponibles.
Detalle
Funcionales
Buscarentrelossitiosdisponiblesaquellosquecumplanlascondicionesenel
siguienteorden:clase,fumador yfila.
Estructura
dedatos
Preferencias_sitio
Clase_asignada*Primera,Negocios,TuristaFumador*S/N
Fila*Pasillo,Medio,Ventana

13
Especificación de módulos por pseudocódigo
Módulo. Seleccionar sitios de pasajeros.
Call ObtenerPrimerSitio (Sitio,NoHaySitios)
While Not NoHaySitios
Comprobar Sitio con Preferencias_sitio
Si es válido Añadir a la Lista_sitios
Call ObtenerSiguienteSitio(Sitio,NoHaySitios)
EndWhile
Mostrar la lista al usuario para que seleccione el
número de sitio.
Accept Numero_sitio
Sitio_seleccionado=Lista_sitios(Numero_sitio)
Return Sitio_seleccionado

14
Organización de las actividades de diseño
FLUJO DE TRANSFORMACION
MODIFICACION CALCULOS ELIMINACION

15
FLUJO DE TRANSACCIONES
PAGOS VENTAS DEPOSITOS

16
ANSLISIS DE TRANSFORMACION
Paso 1. Revisión del modelo fundamental del sistema O DE REQUERIMIENTOS DFD
Paso 2. Revisión y refinamiento de los DFD del software
Paso 3. Determinar si el DFD tiene características de transformación o de transacción
Paso 4. Aislar el centro de transformación especificando los límites de los flujos entrantes y
salientes
Paso 5. Realización del Primer Nivel de Factorización
Paso 6. Ejecución del Segundo Nivel de Factorización
Paso 7. Refinar la estructura inicial del programa utilizando medidas y heurísticas de diseño

17
ANALISIS DE TRANSFORMACION
Paso 5. Realización del Primer Nivel de
Factorización

18
Paso 6. Ejecución del Segundo Nivel de
Factorización

19
ANALISIS DE TRANSACCIONES
Paso 1. Revisión del modelo fundamental del sistema O DE REQUERIMIENTOS DFD
Paso 2. Revisión y refinamiento de los DFD del software
Paso 3. Determinar si el DFD tiene características de transformación o de transacción
Paso 4. Aislar el centro de transformación especificando los límites de los flujos
entrantes y salientes
Paso 5. Realización del Primer Nivel de Factorización
Paso 6. Ejecución del Segundo Nivel de Factorización
Paso 7. Refinar la estructura inicial del programa utilizando medidas y heurísticas de
diseño
Paso 4. Identificar el centro de transacción y las características del flujo de cada camino
de acción
Paso 5. Transformar el DFD en una estructura de software adecuada al procesamiento de
transacciones
Paso 6. Factorizar y refinar la estructura de transacciones y la estructura de cada camino
de acción

20
Paso 5. Transformar el DFD en una estructura de software
adecuada al procesamiento de transacciones

21
Heurísticas o creatividad de diseño estructurado
1. Evaluar la estructura de programa preliminar
para reducir el acoplamiento y reducir la cohesión
Expande un módulo cuando en dos o más módulos
existe un componente de procesamiento común
que puede redefinirse como un módulo cohesivo
aparte.
Para reducir el acoplamiento, se pueden juntar
varios módulos para evitar las interfaces
complejas y reducir el número de referencias a
datos globales.

22
2. Intentar minimizar las estructuras con alto
grado de salida. Fomentar un alto grado de
entrada conforme aumente la profundidad
La estructura de control no debe ser demasiado
ancha, sino que se opta por estructuras con varias
capas de control y gran utilización de los módulos
inferior

23
3. Mantener el efecto de un módulo dentro del
ámbito de control de ese módulo
4. Evaluar las interfaces de los módulos para
reducir la complejidad y la redundancia y mejorar
la consistencia
La complejidad en las interfaces es una causa
principal de los errores del software.
Las interfaces deben diseñarse para que sólo se
pase la información necesaria y deben ser
consistentes con la función del módulo.

24
5. Definir módulos cuyas funciones sean
predecibles
Los módulos deben tener una apariencia de caja
negra, ocultando los detalles de procesamiento.
6. Fomentar módulos con entrada única y salida
única
El software es más fácil de comprender, y por tanto,
es más fácil de mantener, si a los módulos se entra
por el principio y se sale por el final.

25
Medidas de calidad del diseño estructural
La cohesión y el acoplamiento son dos medidas
que permiten evaluar la calidad de la partición de los
módulos y, por lo tanto, ayudan a refinar el diseño.
Un buen diseño se caracteriza por
Acoplamiento bajo: Poca interdependencia entre
módulos
Cohesión alta: significando que los elementos que
componen un módulo están muy relacionados.

26
ESTRATEGIA DE DISEÑO ORIENTADA A OBJETO DOO
Diseñar sistema usando objetos y clases de
objetos
El DOO produce un diseño que interconecta objetos
de datos y operaciones de procesamiento para esos
objetos, de forma que se modulariza la información
y el procesamiento, en lugar de aislar el
procesamiento.

27
ESTRATEGIA DE DISEÑO ORIENTADA A OBJETO
Características del DOO
• Los objetos son abstracciones del mundo real o
entidades del sistemas y manejarse ellos
mismos
• Los objetos son independientes y encapsulan
estado y representan información
• La funcionalidad del sistema se expresa en
términos de servicios de objetos
• Las áreas de datos compartidos se eliminan.
• Los objetos se comunican a través de paso de
mensajes
• Los objetos pueden se distribuidos y pueden se
ejecutados secuencialmente o en paralelo

28
Ventajas del DOO
Mantenimiento más fácil. Los objetos se pueden
entender como entidades independientes
• Los objetos son componentes apropiados
reusables
• Para algunos sistemas, puede haber una obvia
correspondencia entre entidades del mundo real
y objetos del sistema

29
Desarrollo orientado a objetos
• El análisis, diseño y programación orientados a
objetos están relacionados pero distintos
• El AOO es concerniente con el desarrollo de un
modelo de objetos del dominio de la aplicación
• El DOO es concerniente con el desarrollo de un
sistema orientado a objetos del sistema para
implementar requerimientos
• La POO es concerniente con la implementación de
un DOO usando un lenguaje OO tal como java o
C++.

30
PASOS DEL DISEÑO orientado a objetos
El DOO tiene que comenzar con una descripción en
lenguaje natural de la estrategia de solución (DER y
DOCUMENTACION DE CASOS DE USOS) , y a
partir de esta descripción, el diseñador identifica las
clases, objetos y operaciones

31
PASOS DEL DISEÑO orientado a objetos
1) Definición del problema y su solución (DER-CU
DOCUMENTADOS)
2) Desarrollo informal de la forma de procesamiento para
la realización del software (Diagrama de Clases con
SUBSISTEMAS y MODELO E-R)
3) Formalización de la forma de procesamiento.
(Diagramas de componentes y de implementación)
a) Identificar los objetos y sus atributos
b) Identificar las operaciones de los objetos
c) Establecer las interfaces que muestren las
relaciones entre los objetos y las operaciones
d) Crear un diseño detallado que proporcione una
descripción de la implementación de los objetos

32
ESTRATEGIA DE DISEÑO ORIENTADA A ASPECTOS
Esta estrategia se fundamenta en la
programación orientada a aspectos (AOP
Aspect Oriented Programming).
La cual es una metodología de programación
que aspira a soportar la separación de
competencias en aspectos.

33
QUE SON LOS ASPECTOS
• No suelen ser unidades de descomposición
funcional del sistema.
• Son propiedades que afectan al
rendimiento o la semántica de los
componentes.
•Algunos ejemplos de aspectos son:
•Patrones de acceso a memoria.
•Sincronización de procesos
concurrentes.
•Manejo de errores.
•Encriptamiento.

34
Enfoque orientado a aspectos
• Define un mecanismo que ayuda a resolver
problemas de codificación en los
requerimientos.
• Es un código disperso (scattered) y
diseminado (tangled), que no se resuelven
fácilmente usando el enfoque orientado a
objetos.
• Este mecanismo se enfoca principalmente
en la separación de intereses (separation
of concerns) de un sistema para obtener una
mejor modularización.

35
Separación de intereses

36
Estructura de un programa orientado a aspectos

37
Que es la programación orientada a aspectos (AOP)
• La programación orientada a aspectos AOP, es una
nueva evolución en la línea de la tecnología para la
separación de las concerns (propiedades o áreas de
interés),
• Es una tecnología que nos permite al diseño y a la
codificación ser estructuradas para reflejar la manera
en que los desarrolladores quieren pensar acerca del
Sistema.
• La AOP está construida sobre tecnología existente, y
provee mecanismos adicionales que hacen posible el
afectar la implementación de un sistema en una
manera “crosscuting” (tomar un atajo).

38
• En AOP, un sólo aspecto puede contribuir a la
implementación de un número de
procedimientos, módulos, u objetos.
• La contribución puede ser homogénea, por
ejemplo al proveer un comportamiento de
registro que todos los procedimientos deben
seguir en una interfaz dada.
• Puede ser heterogéneo, por ejemplo,
implementando los dos lados de un protocolo
entre dos clases diferentes.

39
Comparación programa tradicional vs AOP

40
Un programa orientado a aspectos necesitamos
definir los siguientes elementos
• Lenguaje para definir la funcionalidad básica.
como C++ o Java.
• Uno o varios lenguajes de aspectos. El lenguaje
de aspectos define la forma de los aspectos – por
ejemplo, los aspectos del AspectJ ((AspectJ es una
extensión de Java). se programan de forma muy
parecida a las clases.
• Un tejedor de aspectos. El tejedor se encargará de
combinar los lenguajes. En tiempo de ejecución, o
hacerse en tiempo de compilación.

41
Implementación de AOP

42
Tejiendo Clases y aspectos
• Los aspectos describen apéndices al
comportamiento de los objetos.
• Hacen referencia a las clases de los objetos y
definen en qué punto se han de colocar estos
apéndices.
• Los join points O PUNTOS DE UNION pueden ser
tanto métodos como asignaciones de variables.
• Los join points o puntos de unión son una clase
especial de interfaz entre los aspectos y los
módulos del lenguaje de componentes.
• Son los lugares del código en los que éste se
puede aumentar con comportamientos
adicionales.(Aspectos)

43
El entrelazado estático implica modificar el código
fuente de una clase insertando sentencias en
estos puntos de enlace.
Es decir, que el código del aspecto se introduce
en el de la clase.
Un ejemplo de este tipo de tejedor es el Tejedor de
Aspectos AspectJ (AspectJ es una extensión de
Java).
Entrelazado dinámico es que los aspectos existan
de forma explícita tanto en tiempo de compilación
como en tiempo de ejecución

44

45
Los aspectos en el diseño
En las primeras fases, la orientación a aspectos se
centró principalmente en el nivel de
implementación y codificación, pero en los últimos
tiempos cada vez se elevan más voces y surgen más
trabajos para llevar la separación de
funcionalidades a nivel de diseño.
Proponen utilizar UML como lenguaje de modelado,
ampliando su semántica con los mecanismos
que el propio lenguaje unificado tiene para
representar el diseño funcional de los objetos
separado del diseño no funcional del mismo

46
Las ventajas que tiene el capturar los aspectos ya
desde la fase de diseño son claras:
• Facilita la creación de documentación y el
aprendizaje.
•Facilita la reutilización de los aspectos.

47
Añadir nuevos elementos al metamodelo UML para
el aspecto y la clase “tejida”, y se reutilizar un
elemento ya existente para la relación clase-
aspecto:
•Aspecto.
•Relación aspecto-clase.
•Clase tejida.

48
UML y DOA

Fundamentos diseño software

Recomendados

Recomendados

Más contenido relacionado

Similar a Fundamentos diseño software

Similar a Fundamentos diseño software (20)

Fundamentos diseño software