Ingeniería de

Software
PRY3111
DISEÑANDO
NUESTRO
SOFTWARE
 Necesitamos Modelar!!!!

» Para simplificar estas definiciones

debemos elaborar modelos.

3
 Modelando Software
“Modelo de datos”

» En el proceso de desarrollo de software podemos utilizar diversos

modelos para lograr simplificaciones de aspectos que son
complejos de describir, por ejemplo, comprender como se
relacionan los datos en un repositorio se puede facilitar mediante
un modelo de datos.
4
 Modelo de datos

Hay muchos tipos de modelos de datos.

Algunos de los más comunes incluyen:

 Modelo de base de datos jerárquico

 Modelo relacional
 Modelo de red
 Modelo de base de datos orientado a objetos
 Modelo entidad-relación
 Modelo de documentos
 Modelo entidad-atributo-valor
 Esquema de estrella
 Modelo relacional de objetos, que combina los dos que
forman su nombre
5
Ejemplo
Modelo de datos

6
 Modelando Software
“Modelo de Procesos”
» Para comprender como se integrará el software en la
organización se puede facilitar con un modelo de procesos.

7
Ejemplo
Modelo de proceso

8
 Modelando Software
“Modelo de dominio”
» Un modelo de dominio nos podrá indicar el alcance de la
solución según los objetos que considera el software.

9
 El diseño del software

» La base conocimiento de la Ingeniería de software define el

diseño como "el proceso de definición la arquitectura,
componentes, interfaces y otras características de un sistema
o componente“.
» En este proceso de diseño los requisitos de software son
analizados para producir una descripción de la estructura
interna de la solución de software, la cual servirá de base
para su construcción.
» Es aquí donde los modelos nos permitirán generar las
descripciones antes señaladas.

10
 ¿Que genera el diseño?

» Producto del proceso de diseño obtendremos:

• Una descripción de la arquitectura del software señalando
cómo se descompone el software, cómo estará organizado en
sus componentes y las interfaces entre esos componentes,
como una visión de alto nivel.
• Los componentes a un nivel de detalle de tal forma que
permitan su construcción.

11
 ¿en que más ayuda?

» A través del diseño podemos examinar

y evaluar posibles alternativas de
solución ajustando o integrando otros
componentes.
» Los modelos no permitirán ajustar la
planificación inicial y guiar el desarrollo
posterior.
» Los modelos nos ayudarán en
actividades de verificación y validación
del sistema.
» Estos modelos serán los artefactos de
entrada para la construcción y pruebas
del software.

12
 Principios de diseño

» Para poder enfrentar el proceso de diseño, debemos conocer y

aplicar algunos principios fundamentales que nos permitirán
llevar a modelos la solución de software propuesta:

• Abstracción.
• Acoplamiento y Cohesión
• Descomposición y Modularidad
• Encapsulación

13
 Abstracción

» Es la capacidad de observar elementos específicos bajo un

mismo concepto o generalidad.
Ejemplo:
En la sección 04 de Ingeniería de Software el profesor le indica a Mario y
Verónica que deben rendir una prueba, la cual será registrada en el sistema de
notas.
Mario y Verónica son personas diferentes, pero en un contexto de sistema de
notas, ambos pasan a conformar el concepto de Alumno, ya que no nos interesa
el género o la estatura o los aspectos específicos de ellos, sólo los trataremos
bajo una abstracción de Alumno para poder evaluarlos.

Alumno
14
 Acoplamiento

» El acoplamiento implica que los componentes de software

están afectados entre sí, si hay un cambio en uno debo cambiar
los otros.
» Un diseño de software debe apuntar a tener un bajo
acoplamiento, es decir, los componentes deben ser más
independientes, con el objeto de reducir el esfuerzo a la hora
de hacer un cambio en el software (mantención).
» Esto queda en evidencia si al modificar un módulo deja de
funcionar otro que aparentaba no estar relacionado.
Controlador de
Componente A Componente A
componentes A

Controlador de Controlador de
Componente B Componente B
componentes componentes B

Controlador de
Componente C Componente C
componentes B
15
Ejemplo de Acoplamiento

» El servicioFacturación esta
ligado a tres Servicios
adicionales , el primero valida ,
el segundo paga la factura y el
tercero envía un correo con el
pago realizado.
» Esto es lo que se denomina
acoplamiento entre clases .
» La clase ServicioFacturación
depende de otros servicios y
por lo tanto cada cambio que
realicemos en cualquiera de
estas clases implica que el
ServicioFacturación también se
verá afectado.
16
 Cohesión

» La cohesión se refiere a la relación de dependencia de las

partes o estructuras de un mismo módulo o componente de
software.
» Una alta cohesión indica que el componente realiza su función
específica, lo que permite que el componente pueda ser
cambiado y afectar sólo a la funcionalidad que representa,
tiene un alcance definido, límites claros y ubicado.
» Una baja cohesión implica que internamente al cambiar una
funcionalidad debo revisar todas las restantes por tener
atributos o aspectos comunes, aumentando el esfuerzo de
cambio.
Lavado
fecha
Lavado
precio

X
fecha vehiculo
precio lavado
vehiculo secado
servicios encerado
limpiaLlantas 17
 Cohesión

» En palabras simples, la cohesión es la medida en la que un

componente o clase realiza únicamente la tarea para la cual fue
diseñada.

18
 Acoplamiento y Cohesión

» Un bajo acoplamiento nos garantiza:

» Mejorar la mantenibilidad de los módulos del software, facilitar
los cambios en el software sin tener que revisar todos los
módulos dependientes.
» Mejorar la reutilización de las unidades del software.
» Facilitar las pruebas unitarias de cada módulo, al ser más
independientes.

19
 Acoplamiento y Cohesión

» Por otro lado, una alta cohesión nos permite:

» Tener un código mas entendible, legible y coherente.
» Mejorar la reutilización, al tener todo lo relacionado con una
cosa, en esa cosa, y no disperso entre módulos.
» Mejorar el mantenimiento del software, ya que todo está
perfectamente localizado y los cambios en un módulo no
afectarán a módulos externos.
» Facilita las pruebas de caja negra, ya que toda la funcionalidad
relacionada con una cosa, está encerrada en esa cosa.

20
 Descomposición y
modularidad
» Este concepto implica que un gran módulo de software se
divide en una serie de componentes menores.
» Los componentes menores son identificables, con sus
respectivas responsabilidades y con interfaces que describen
las interacciones entre ellos.

21
 Encapsulación

» Es la capacidad de disminuir la exposición de la operación de

una funcionalidad en uno o más módulos de software,
reduciendo la posibilidad de acceder a estas funcionalidades
directamente.
» Encapsulación es una forma de ocultación de información,
logrando una abstracción de los detalles internos y haciendo
esos detalles inaccesibles a entidades externas.
Ascensor Ascensor
+ marca + marca
+ año + año
+ verificarPiso - verificarPiso
+ calcularLimite - calcularLimite
+ subePiso - subePiso
+ subir()

Ascensor. verificarPiso [Link]()

calcularLimite
subePiso

Operaciones visibles Encapsula operaciones 22

no son visibles
 Otros aspectos claves en
un diseño de software
» Calidad que todo software debe cumplir, tales como:
rendimiento, seguridad, fiabilidad, usabilidad y otros.
» Aspectos de concurrencia: ver procesos y separación de tareas.
» Persistencia de datos: qué y dónde guardar información.
» Distribución de componentes: ver si el software debe ser
ejecutado en uno o varios componentes.

23
 Otros aspectos claves en
un diseño de software
» Manejo de errores y tolerancia a fallas: prevenir fallas y
considerar el cómo tratarlas.
» Interacción y Presentación: como se usan las interfaces con el
usuario .
» Seguridad: ver como prevenir divulgación de información
indebida, prevenir ataques y verificar tiempos de recuperación.

24
 Resumiendo…

Para lograr un buen diseño de software debemos considerar la

capacidad del equipo de desarrollo para plasmar la solución a
través de diversos modelos, lograremos desarrollar los modelos
en la medida que podamos:
• Hacer abstracciones de la realidad y llevarlas a
los modelos.
• Lograr componentes que no dependan en
exceso entre ellos y que no acumulen
funciones diversas, lograr que se dediquen a
realizar sólo sus tareas.
• Tener la capacidad de dividir funciones en
subfunciones de software.
• Realizar componentes con funciones de acceso
simple que oculten la complejidad a otros
componentes usuarios. 25
 Modelo 4+1
El modelo de vista 4+1 fue propuesto por Philippe Kruchten en 1995 como
una forma de organizar y presentar las vistas de arquitectura de un sistema de
software. El modelo consta de cuatro vistas lógicas: la vista lógica, la vista de
desarrollo, la vista de proceso y la vista física. La quinta vista, la vista de
escenario, no es una vista separada, sino más bien una colección de casos de
uso o escenarios que ilustran cómo el sistema cumple con los requisitos y
objetivos de las partes interesadas. La vista de escenario ayuda a validar y
comprobar las demás vistas y a identificar cualquier laguna o incoherencia.

26
Para entender el
modelado

Nivel construcción

27
Para entender el
modelado

Nivel construcción
Nivel eléctrico

28
Para entender el
modelado

Nivel construcción
Nivel eléctrico

Nivel saneamiento

29
 Modelo 4+1
Vista Lógica
En esta vista se representa la funcionalidad que el sistema
proporcionara a los usuarios finales.
Es decir, se ha de representar lo que el sistema debe hacer, y las
funciones y servicios que ofrece. Para completar la documentación de
esta vista se pueden incluir los diagramas de clases, de comunicación
o de secuencia de UML.

Ejemplo Diagrama de Clases

30
 Modelo 4+1
Vista Despliegue
Es un recurso gráfico que muestra un sistema de software que tiene
varios componentes; pero también muestra las dependencias que
existen entre los mismos..

Ejemplo Diagrama de Componentes

31
 Modelo 4+1
Vista Proceso
Es lo mismo que un diagrama de
flujo. Pone especial atención en la
secuencia y también las
condiciones que se dan dentro del
proceso que se está analizando.

Casi todos los procesos o flujos de

trabajo parten de un punto inicial
para llegar a un punto final. Este
tipo de diagrama se basa
justamente en mostrar secuencia
de las actividades o acciones .

32
Ejemplo Diagrama de Actividades
 Modelo 4+1
Vista Física
El modelo de datos físicos representa cómo se construirá el modelo
en la base de datos.
Un modelo de base de datos física muestra todas las estructuras de
tabla, incluidos el nombre de columna, el tipo de datos de columna,
las restricciones de columna, la clave principal, la clave externa y las
relaciones entre las tablas.
Ejemplo Diagrama de Despliegue

33
 Modelo 4+1
Vista Escenarios (+1)
Esta vista va a ser
representada por los
casos de uso software y
va a tener la función de
unir y relacionar las
otras 4 vistas, esto quiere
decir que desde un caso
de uso podemos ver
como se van ligando las
otras 4 vistas, con lo que
tendremos una
trazabilidad de
componentes, clases,
equipos, paquetes, etc..
34
Ejemplo Diagrama de Casos de Uso
 Matriz R.A.C.I

Responsable: Aunque en la mayoría de los casos es el ejecutor de la

tarea en cuestión, si en alguna circunstancia la delega en terceras
personas, tendrá que responder de la entrega de la misma.

Aunque a veces puede ser más de una persona, te aconsejamos

minimizar la cantidad de personas involucradas.

Aprobador: No harán el trabajo, pero son responsables de asegurarse

de que esté finalizado.

35
 Matriz R.A.C.I

Consultado: Generalmente son expertos con opiniones de valor o que

tienen en su poder información de utilidad para poder completar la
tarea con éxito.
La comunicación con el consultado es bidireccional y normalmente son
requeridos por los responsables o aprobadores.

Informado: Deben ser actualizados sobre el avance. A diferencia del

consultado, en este caso la comunicación es unidireccional.

36
Ejemplo Matriz R.A.C.I

37
 Estilos
Arquitectónicos
y Patrones de
Diseño
 Estilos Arquitectónicos

» Junto con considerar los principios de diseño antes señalados,

el equipo desarrollo deberá lidiar con la definición de un estilo
de arquitectura en la cual basará su solución.
» El estilo a elegir será el que se ajuste a la solución de software
definida según los requerimientos , por cuanto deberá el
equipo de desarrollo deberá considerar los aspectos de alto
nivel que los requerimientos demanden.

» Podemos considerar los estilos

como marcos de referencia de
soluciones de alto nivel.
» Estas soluciones son un conjunto
de componentes organizados de
un forma predefinida.
40
 Algunos ejemplo de
estilos
» Estilo por capas, se usa en soluciones que deben separar
funcionalidades y prestar servicios definidos entre capas.

41
 Algunos ejemplo de
estilos
» Estilo tuberías, se utiliza en soluciones donde deban enviarse
estructuras en forma secuencial o serial, por ejemplo en
sistema de mensajes.

42
 Algunos ejemplo de
estilos
» Estilo pizarra, donde sea necesario usar un lugar común de
transferencia de información compartida entre todos, por
ejemplo una sala de chat.

Proc. 1

Proc. 8 Proc. 2

Proc. 3 Pizarra
P Proc. 3

Proc. 6 Proc. 4

Proc. 5

43
 Algunos ejemplo de estilos

» Cliente-Servidor, esta modalidad se utiliza en la mayoría de las

aplicaciones que usan servicios que proveen otros, por ejemplo,
un sistema que requiere el servicio de datos que provee un
servidor de base de datos.

44
 Algunos ejemplo de estilos

» Orientación a los Servicios, esta modalidad provee diferentes

servicios publicados que son consumidos por diversas
aplicaciones.

45
 Patrones de Diseño

» Los patrones de diseño son especificaciones más detalladas de

estructuras o formas reiterativas de hacer las cosas, es una
solución a un problema común en un contexto dado.
» Llevado a desarrollo de software, representan una buena
práctica que es reconocida y aplicada.
» Al ser aplicados, lograremos mayor capacidad de mantención
del software y disminuir tiempos en solicitudes de cambios.

46
 Patrones de Diseño

» Pueden ser aplicados en diferentes partes de la solución de

software y pueden convivir entre ellos.
» Existen diversos patrones según su objetivo, por ejemplo, de
creación, estructurales o comportamiento.

47
 Objetivos de un patrón de Diseño

» El patrón de diseño será la guía para codificar un módulo de

software de manera que sea comprensible por desarrolladores
sin que ellos hallan creado dicho código.
» El patrón se implementa en algún lenguaje de programación para
construir los módulos del software.

48
 Ejemplo de uso Singleton
» Por ejemplo, un patrón muy conocido es el patrón singleton, en
orientación a objetos, si se programa en la forma en que se
presenta este patrón, lograremos que se pueda crear una instancia
de un objeto y mantener dicha instancia durante la ejecución del
software, aún cuando se vuelva a crear un objeto en otra parte del
código.

49
 Ejemplo de uso Singleton
» Este patrón se utiliza mucho cuando necesitamos crear clases de
conexión a base de datos, donde durante la ejecución del software
necesitaremos varias veces conectarnos a la base de datos, pero
necesitamos siempre estar utilizando el objeto inicial y no creando
nuevos objetos de conexión cada vez que necesitemos leer o grabar
información.

50
 Ejemplo de uso Singleton
» Si un usuario envía una solicitud a la impresora, el patrón singleton
hace la “pregunta”: “¿Ya hay un objeto de la impresora? Si no,
entonces crea uno.” Esto se resuelve con un if/then-statement
(devolver impresora == cero ?). Para evitar el acceso y los cambios,
las variables individuales y la impresora se establecen como
“privadas” en lugar de “públicas”.

51