El documento describe el flujo de diseño del Proceso Unificado de Desarrollo de Software (UP). En menos de 3 oraciones: 1) El flujo de diseño de UP incluye principios para el diseño de componentes como el abierto-cerrado y la sustitución de Liskov. 2) El diseño de componentes también considera tipos como caja negra, caja blanca y marcos de trabajo, así como pasos para el diseño e interfaz. 3) Finalmente, el documento explica conceptos como cohesión, acoplamiento, paquetes y component

1. Parte 1.3
Proceso de Desarrollo Unificado
FLUJOS DE TRABAJO – UP
- Flujo de Diseño
Material académico preparado por:
Ph.D, Marta Silvia Tabares B.
Fecha última actualización 4-Sep-2011

2. Ingeniería de Software II
(mapa conceptual de tópicos de conocimiento)
Material Preparado por MARTA SILVIA TABARES B. UdeM

3. Bibliografía
• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.
• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and
Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John
Wiley & Sons © 2005.
• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo
de Software. Adisson Wesley. 2001.
• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented
Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.
• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07-
04. 2005.
• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos
del Sistema, Usando UML. McGraw-Hill, 2006.
Material Preparado por MARTA SILVIA TABARES B. UdeM

4. Proceso Unificado
Flujo de Diseño
PRODUCTOS
Dcto. de visión refinado
Dcto. de evaluación del riesgo
Fases
refinado
Disciplinas
Inicio Elaboración Construcción Transición
Modelo de requisitos No-
funcionales
Requisitos
Modelo de casos de uso
Análisis arquitectónicamente significativos
(Diagramas de Actividades,
Diagramas de Comunicación)
Diseño
Modelo de Clases
Implementación
Modelo de componentes
Pruebas Esquema de la base de datos
Iteraciones I1 I2 I3 I4 I5 I6 In+1 In+2 Im Im+1
Preliminares Prototipos definitivos
Arquitectura ejecutable
Modelo de Pruebas
Material Preparado por MARTA SILVIA
TABARES B. UdeM

5. Definición de Componente de
Software (1)
• Un componente representa una parte modular de un
sistema que encapsula sus contenidos y cuya
manifestación es reemplazable dentro de su
ambiente [UML].
• Un componente actúa como una caja negra cuyo
comportamiento externo está completamente
definido por sus interfaces requeridas y
proporcionadas.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

6. Definición de Componente de
Software (2)
• En la programación orientada a objetos y la
tecnología de objetos distribuidos, un COMPONENTE
es un conjunto de clases e interfaces que realizan los
requisitos funcionales y no funcionales con una API
externa reusable.
• Componentes podrían ejecutarse en un ambiente de
red distribuido para formar una aplicación en red.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

7. Diseño de Componentes (1)
Principios básicos: Primero
Principio “abierto-cerrado”
Un componente debe estar abierto a extensiones pero
debe estar cerrado para modificaciones. El/la diseñador(a)
debe especificar el componente de manera que puede
extenderse sin necesidad de hacer modificaciones internas
al código.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

8. Diseño de Componentes (2)
Principios básicos: Segundo
Principio “de substitución de Liskov”
Las subclases deben ser sustituibles por sus clases bases.
Cualquier clase derivada de una clase base debe cumplir
con cualquier contrato implícito de la clase base con
respecto a los componentes que la usan.
Un “contrato” es una precondición que debe ser
verdadera antes de que el componente use la clase base,
y una post-condición debe ser verdadera después de que
el componente usa la clase base.
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

9. Diseño de Componentes (3)
Principios básicos: Tercero
Principio “de Dependencia de Inversión”
Se debe depender de abstracciones, no de eventos
concretos.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

10. Diseño de Componentes (5)
Principios básicos: Quinto
Principio “de segregación de interfaces”
Varias interfaces dependientes del cliente son mejor
que una interfaz de propósito general
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

11. Diseño de Componentes (6)
Principios de EMPAQUETADO
Principio “de equivalencia de liberación y
reuso”
La granularidad del reuso es la granularidad de
liberación. Esto significa que se deben agrupar
clases reusables en paquetes que se puedan
administrar y controlar cuando una nueva
versión se genere.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

12. Diseño de Componentes (7)
Principios de EMPAQUETADO
Principio “de agrupamiento común”
Las clases que cambian al mismo tiempo
deben agruparse
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

13. Diseño de Componentes (8)
Principios de EMPAQUETADO
Principio “de reuso común”
Las clases que no se reusan al mismo tiempo
no deben agruparse
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

14. Diseño de Componentes (9)
Tipos de Componentes y Marcos de Trabajo
Componente CAJA NEGRA
Dispositivo o un sistema o un objeto cuando se ve sobre todo en
términos de sus características de la entrada y de salida. Casi
cualquier cosa se pudo referir de vez en cuando como caja negra: a
transistor, algoritmo, seres humanos, Internet.
Marcos de trabajo (framework) de Caja Negra
Su instanciación se realiza por medio de composición y delegación, en
lugar de utilizar la herencia. Los puntos de entrada se definen por medio
de interfaces que deben implementar los componentes que extiendan el
marco.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

15. Diseño de Componentes (10)
Tipos de Componentes y Marcos de Trabajo
Componente CAJA BLANCA
Un sistema donde están disponibles los componentes o la lógica
interna para la inspección (tal como a software libre/abra la fuente
programa) cuál se conoce a veces como a caja blanca, una caja de
cristal, o una caja clara.
Marcos de trabajo (framework) de Caja Blanca
Que se extienden mediante herencia, concretamente mediante la
implementación de las clases y métodos abstractos definidos como puntos
de entrada. Se tiene acceso al código del marco y se permite reutilizar la
funcionalidad de sus clases mediante herencia y
redefinición de métodos.
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

16. Diseño de Componentes (11)
Tipos de Componentes y Marcos de Trabajo
Marcos de trabajo (framework) Caja de Cristal
Admiten la inspección de su estructura e implementación,
pero no su modificación ni extensión, excepto en los
puntos de entrada.
Marcos de trabajo (framework) Caja de Cristal
Los puntos de entrada no son simplemente métodos abstractos, de los que
se declara meramente su signatura, sino que se definen por medio de un
lenguaje de especficación de alto nivel los requisitos que deben cumplirse a
la hora de implementarse.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

17. Pasos para el Diseño de Componentes
(1)
1. Identifique todas las clases de diseño que correspondan al dominio del
problema
2. Identifique todas las clases de diseño que correspondan al dominio de la
infraestructura (GUI, sistemas operativos, administración de datos etc.)
3. Elabore todas las clases que no provienen de clases reusadas
a) Especifique detalles de los mensajes entre clases que colaboran
b) Identifique las interfaces de cada componente
c) Elabore atributos y defina tipos de datos y estructuras de datos
requeridas para implementarlas
d) Describa el flujo de procesamiento de cada componente en detalle.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

18. Pasos para el Diseño de Componentes
(2)
4. Describa fuentes de datos persistentes (bases de datos y archivos) e
identifique las clases requeridas para manipularlos
5. Desarrolle y elabore representaciones del comportamiento de una clase o
componente (diagramas de estados)
6. Elabore diagramas de liberación (deployment) para dar detalles
adicionales de implementación
7. Revise cada representación de diseño de los componentes y siempre
considere alternativas
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

19. Modelos de Componentes (1)
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

20. Interfaz (1)
• Una interfaz especifica un nombrado conjunto de
características públicas.
• Para identificar una interfaz se debe separar la especificación
de funcionalidad de su implementación por un clasificador tal
como una clase o un subsistema.
• Una interfaz NO puede se puede instanciar. Esta sólo declara
un contrato que puede ser realizado por cero o muchos
clasificadores.
Flujo de Diseño UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

21. Interfaz (2)
Interfaz Específica Clasificador realizador
Operación Debe tener una operación con el misma identidad
(firma) y semántica.
Atributo Debe tener operaciones públicas para get y set los
valores del atributo.
Asociación Debe tener una asociación al clasificador destino, esto
si una interfaz especifica una asociación a otra interfaz,
el clasificador implementador de estas interfaces debe
tener una asociación entre ellas.
Restricción (constraint) Debe soportar restricción
Estereotipo (stereotype) Tiene un estereotipo
Valor etiquetado (tagged value) Tiene un valor etiquetado
Protocolo Debe realizar el protocolo definido p.ej., en una
máquina de estado finito.
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

22. Interfaz (2)
El conjunto de interfaces realizadas por un clasificador se conoce como
su interfaz PROPORCIONADA (provided).
Cuando un clasificador requiere una o más interfaces para su operación,
estas se conocen como sus interfaces REQUERIDAS (required)
Notación “Lollipop”
Interface (pirulí ☺)
Relación de
Realización
Libro CD
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

23. Interfaz (4)
Material Preparado por MARTA SILVIA TABARES B. UdeM
Flujo de Diseño UP

24. Interfaz (5)
En la tecnología de componentes la interfaz constituye el
elemento básico de interconectividad.
Cada componente debe describir de forma completa las
interfaces que ofrece, así como las interfaces que requiere
para su operación.
La interfaz debe operar correctamente con independencia
de los mecanismos internos que utilice para soportar su
funcionalidad.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

25. Modelos de Componentes (1)
• Un componente puede tener atributos y operaciones y
pueden participar en relaciones de asociación y
generalización.
Flujo de Diseño UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

26. Modelos de Componentes (2)
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

27. Modelos de Componentes (3)
cmp Modelo de Componentes
Modelo de Componentes
+ Active X Control
+ Dll
+ JavaBean
+ W eb Pages
+ Web Server
+ Node
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

28. Paquetes vs Componentes
Ejemplo (1): Modelo de Paquetes
pkg Sistema Univ ersitario
AgendaCalendario
+ Curso
+ Localizacion
+ Matricula
+ Seminario
Estereotipo
<<application>> indica que + T iempo
«import»
el paquete tiene interfaces
de usuario (UI)
Estudiante Punto de Contacto Infraestructura Jav a
«application»
Registro Seminarios «import»
Profesor
«import»
«import»
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP Fuente: http://www.agilemodeling.com/artifacts/componentDiagram.htm

29. Paquetes vs Componentes
Ejemplo(2): Modelo de Componentes
Fuente: http://www.agilemodeling.com/artifacts/componentDiagram.htm
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

30. Cohesión y Acoplamiento
• Cohesión: implica que un componente o clase
encapsula solo atributos y operaciones que
están altamente relacionados entre ellas y con
la clase. Se busca la máxima cohesión en una
clase.
• Acoplamiento: es la medida cualitativa del
grado en que una clase está conectada con
otra. Se busca el mínimo acoplamiento entre
clases.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

31. Cohesión y Acoplamiento
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

32. Tipos de Cohesión
Tomado de: http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/ing_sw_1/Criterios_Diseno_cohesion.pdf
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

33. Alta Cohesión
Indica la información que almacena una clase debe de ser
coherente y debe estar (en la medida de lo posible)
relacionada con la clase.
Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación
entre ellas.
Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en
tiempo de ejecución, sólo una de ellas será llevada a cabo.
Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como
única relación el deber ser ejecutadas “al mismo tiempo”.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

34. Alta Cohesión
La cohesión tiene que ver con la forma en la que
agrupamos unidades de software en una unidad
mayor.
Por ejemplo, la forma en la que agrupamos
funciones en una librería, o la forma en la que
agrupamos métodos en una clase, o la forma en
la que agrupamos clases en una librería, etc...
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

35. Alta Cohesión
Cohesión de Procedimiento: La única relación que guardan las tareas de un
módulo es que corresponden a una secuencia de pasos propia del “producto”.
Cohesión de Comunicación: Las tareas corresponden a una secuencia de
pasos propia del “producto” y todas afectan a los mismos datos.
Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su
propio punto de arranque, su codificación independiente y trabajan sobre los
mismos datos. El ejemplo típico: OBJETOS
Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea,
teniendo un único objetivo a cumplir, se dice que tiene Cohesividad
Funcional.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

36. Bajo acoplamiento
La idea de tener las clases lo menos ligadas entre sí que
se pueda. De tal forma que en caso de producirse una
modificación en alguna de ellas, se tenga la mínima
repercusión posible en el resto de clases, potenciando la
reutilización, y disminuyendo la dependencia entre las
clases.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

37. Bajo acoplamiento
Dos unidades están completamente desacopladas cuando hacen
su trabajo de manera totalmente independiente. Esto nos
permitiría coger una de ellas y utilizarla tal cual en un programa
sin necesidad de llevarnos la otra.
• Por ejemplo, estos dos métodos (en C#), están totalmente desacoplados.
Ninguno de ellos necesita al otro para hacer su trabajo.
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

38. Bajo acoplamiento
• Acoplamiento normal: es aquel en el que una unidad de software necesita
del trabajo que hace la otra. Así, descomponemos la solución de un
problema en varias partes.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

39. Acoplamiento normal
• La comunicación entre las unidades debe de producirse utilizando
puntos de entrada y de salida correctos y de su interfaz. Es decir, en
el caso de los métodos. toda comunicación entre un método y otro
acoplado normalmente debe producirse exclusivamente por los
parámetros (como entrada) y por el retorno (como salida).
• Si hablamos de métodos o funciones, los datos deben pasarse de
una a otra a través de parámetros, y devolverse los resultados como
retorno de la función o método y no de ninguna otra forma.
• Una clase está acoplada a otra normalmente si los objetos de una
utilizan a los de la otra, y se comunican invocando sus métodos y
pasándoles datos como parámetros exclusivamente y recibiéndolos
a través de canales normales, como retornos, propiedades, etc.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

40. Otros tipos de Acoplamiento
Acoplamiento de Datos: Una unidad de software está acoplada a
otra por los datos cuando ambas necesitan del mismo conjunto
local de datos para funcionar.
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

41. Otros tipos de Acoplamiento
Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control
que determina la lógica de ejecución del mismo.
Decimos que un método está acoplado a otro por control cuando de alguna manera
un método controla la ejecución del otro. En general, suele ocurrir cuando un método
pasa algún parámetro a otro, y en función de él se comporta de una u otra manera.
Material Preparado por MARTA SILVIA
TABARES B. UdeM Flujo de Diseño UP

42. Diagramas de Máquinas de Estado
Una máquina de estados o flujo de estados describe el comportamiento del sistema. Muestra todos los
estados que un objeto puede tomar en la transición entre sus diferentes estados.
Por el ejemplo, en la figura se muestra el diagrama de estados para la clase Seminar. Un seminario puede
tomar diferentes estados: ser Propuesto (Proposed), Agendado (Scheduled), estar Abierto para matrícula
(Open for Enrollment), estar lleno (full) o tener las matrículas cerradas (Closed to Enrollment)
Material Preparado por MARTA SILVIA
TABARES B. UdeM
Flujo de Diseño UP

43. Diagrama de Despliegue
Los Diagramas de Despliegue muestran la
disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM

44. Diagrama de Despliegue
Los estereotipos permiten precisar la naturaleza del equipo:
- Dispositivos
- Procesadores
- Memoria
Los nodos se interconectan mediante soportes bidireccionales (en principio) que
pueden a su vez estereotiparse
Material Preparado por MARTA SILVIA
Flujo de Diseño UP
TABARES B. UdeM