Ingeniería del Software II Lección 2
Anuncio
Ingeniería del Software II
Bloque III: Proceso Unificado
Simona Bernardi
Dipartimento di Informatica
Università di Torino (Italia)
Duración: 4 horas
Objetivo: Conocer un proceso de desarrollo de software
diferente a OMT
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
1
Lección 2
Segunda fase: Elaboración (1a iteración)
Disciplina: Modelado de negocio
Disciplina: Requerimientos
Modelo de dominio
Diagrama de secuencia de sistema
Contrato de operaciones
Disciplina: Diseño
Arquitectura lógica y organización en capas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
2
1
¿Qué ha pasado durante la ideación ?
Un breve workshop de requerimientos
Identificada la mayoría de actores, objetivos y casos
de usos
Escrita en formato breve la mayoría de casos de
uso; 10-20% de casos de usos escrito en formato
detallado
Primera versión de Visión y Especificaciones
Complementarias
Identificados los requerimientos no funcionales de
mayor riesgo
Plan de la primera iteración de la elaboración
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
3
Elaboración
Consiste en 2 o más iteraciones
Cada iteración de 1 á 6 semanas (timeboxed)
Durante la elaboración
Implementación y test de la arquitectura sw
básica (core) y de mayor riesgo
Identificación y estabilización de la mayoría de
requerimientos
Mayoría de riesgos solucionados o mitigados
Volbank
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
4
2
Artefactos iniciados en la elaboración
Modelo de dominio
Representa los conceptos del dominio
Modelo de diseño
Documento
arquitectura sw
Conjunto de diagramas que describen el
diseño lógico. Incluye diagrama de
clases sw, diagramas de interacción
(secuencia o colaboración),
organización en package, etc.
Resume los problemas arquitecturales
clave y sus soluciones en el diseño
Modelo de datos
Incluye esquemas de DB
Descripción UI, etc. Descripción interfaz usuario, modelos
usabilidad,etc.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
5
Lección 2
Segunda fase: Elaboración (1a iteración)
Disciplina: Modelación de negocio
Disciplina: Requerimientos
Modelo de dominio
Diagrama de secuencia de sistema
Contrato de operaciones
Disciplina: Diseño
Arquitectura lógica y organización en capas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
6
3
Relaciones entre artefactos UP
Modelo de dominio
Modelado
de negocio
Perfil
ofrece
...
Tiempo
...
...
cantidad
Objetos de dominio,
Atributos y asociaciones
que cambian estado
Clases conceptuales –
términos, conceptos,
atributos, asociaciones
Elaboración de
términos en el modelo
de dominio
Modelo de casos de uso
Requerimientos
Depositar Tiempo
1.El Voluntario
inserta….
2. El sistema
actualiza …
3….
Operación:
InsertaTiempo(..)
Pre-condiciones:
….
Post-condiciones:
…..
Glosario
Contratos de operaciones
Texto de casos de uso
Las clases conceptuales en el modelo
de dominio inspiran los nombres de
las clases sw del modelo de diseño
Modelo de diseño
:SecciónUsuario
Diseño
InsertaTiempo
(desde,a,horas)
:ArchivoTiempos
:Perfil
SalvaTiempoPerfil(idperfil, desde,a,horas): t
InsertaTiempo(t)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
7
Modelo de dominio
Representación visual de clases conceptuales,
objetos reales del dominio (no objetos software!)
Disciplina de modelado de negocio
Conjunto de diagramas de clases UML,
incluyen:
Especialización del “Business Object Model”
Objetos de dominio/clases conceptuales
Asociaciones entre clases
Atributos de clases conceptuales
NO operaciones/métodos
Es un diccionario visual
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
8
4
Reducción del gap de representación en la
modelacón O.O
Modelo de Dominio UP
Representación de conceptos de dominio
Perfil
Un Perfil en el modelo de
dominio es un concepto, pero
un Perfil en el modelo de
diseño es una clase sw.
No son la misma cosas, pero
el primero ha inspirado el
nombre y definición del
Segundo, reduciendo el hueco
de representación.
Ofrece
nombre
dirección
CAP
e-mail
*
.
Tiempo
desde
á
totalHoras
Inspira
objectos y
nombres en
Perfil
nombre
dirección
CAP
e-mail
…..
Tiempo
*
Ofrece{list}
InsertaTiempo(t: Tiempo): void
.....
desde
á
totalHoras
….
setTotalHoras(horas: int): void
....
Modelo de Diseño UP
El analista sw toma inspiración del dominio
del mundo real para crear clases Sw.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
9
Simona Bernardi
Como crear un modelo de dominio
Limitados por los requerimientos definidos
en la iteración actual:
1. Encontrar las clases conceptuales
2. Dibujarlas como clases en un diagrama de clase
UML
3. Añadir asociaciones
4. Añadir atributos
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
10
5
Como encontrar clases conceptuales
Reuso/modificación de modelos ya
existentes (patrones de análisis)
Uso de listas de categorías
Análisis lingüístico
El “mapping” nombre-clase no es automático
La palabras en lenguaje natural son ambiguas
Fuentes: casos de uso en formato detallado
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
11
Simona Bernardi
Ejemplo: modelo de dominio Volbank
(parcial)
Organización
Voluntarios
Combinación
Perfil
Tiempo
Pedido
Habilidad
Voluntario
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
12
6
Asociaciones
Añadir asociaciones
Para relaciones que necesitan ser recordadas
Derivadas por la lista de asociaciones comunes
Evitar añadir demasiadas asociaciones
Caracterizar una asociación con
Nombre significativo siguiendo la pauta
NombreClase-FraseVerbal-NombreClase
Multiplicidades y dirección de lectura (o
navegavilidad)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
13
Simona Bernardi
Ejemplo: modelo de dominio Volbank
(parcial)
Organización
Voluntarios
Establece
*
Compuesta-por
Ofrece
Perfil
*
Combinación
1..*
Tiempo
*
Compuesta-por
1..* Necesita
*
Pertenece-a
Pedido
*
Incluye
1..*
Habilidad
Necesita
Voluntario
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
14
7
Atributos
Añadir atributos que
Caracterizar un atributo con
Son tipos de datos “primitivos” (boolean, date, number,
character, string,etc)
Son tipos enumerativos
Origen: derivado/no derivado
Tipo de dato
Introducir nuevas clases para nuevos tipo de datos
Datos compuestos por secciones separadas (ej. nombre,
número teléfono)
Cuando hay operaciones asociadas a los datos, como
validación/parsing (ej. número seguridad social)
Cantidades con unidad (ej. total a pagar está caracterizado por
una unidad de moneda)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
15
Simona Bernardi
Ejemplo: modelo de dominio Volbank
(parcial)
Organización
Voluntarios
Establece
*
Compuesta-por
*
Combinación
*
Compuesta-por
confirmada:Boolean
Perfil
nombre:String
dirección: String
CP: String
teléfono: String
e-mail:String
*
Pertenece-a
Ofrece
1..*
Tiempo
1..*Necesita
desde: Date
á: Date
totalHoras:Int
Incluye
1..*
Habilidad
Pedido
*
Necesita
código: String
descripción: String
Voluntario
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
16
8
Verificación del modelo de dominio
Verificar las clases introducidas
Verificar las asociaciones
Alternativas clases/atributos
Clases descripción
Independencia de asociaciones diferentes que
involucran las mismas clases
Verificar los atributos
No introducir atributos para referirse a otras
clases (usar asociaciones en este caso)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
17
Simona Bernardi
Clases descripción
Contienen información que describen otros
objetos
Item
Peor
description
price
serial number
itemID
ProductDescription
description
price
itemID
Describes
1
*
Item
Mejor
serial number
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
18
9
Independencia de asociaciones que
involucran mismas clases
Vuelo
*
1
Vuela-á
Aereopuerto
Vuela-de
1
*
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
19
Simona Bernardi
Relacionar clases con asociaciones, no
atributos
Peor
Cajero
Cajero
Mejor
No es un atributo “tipo de dato”
nombre
registroCorriente
1
Usa
nombre
1
Registro
número
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
20
10
Modelo de dominio en UP
Disciplina
Artefacto
Iteraciones Æ
Ideac.
Elabor.
Constr.
(I1)
(E1..Ei)
(C1..Cj) (T1..Tk)
Modelado de negocio
Modelo de dominio
Requerimientos
Modelo casos de uso
In.
Refin.
Visión
In.
Refin.
Especif. Complementarias
In.
Refin.
Glosario
In.
Refin.
Reglas de dominio
In.
Refin.
Trans.
Inicio
(y Fin)
Diseño
Modelo de diseño
Inicio
Doc. Arqu. SW
Inicio
Modelo de datos
Inicio
Refin.
Refin.
Recordar: evitar el “pensamiento en cascada”,
dedicar no más de un par de horas para el
modelado del dominio en cada iteración
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
21
Lección 2
Segunda fase: Elaboración (1a iteración)
Disciplina: Modelado de negocio
Disciplina: Requerimientos
Modelo de dominio
Diagrama de secuencia de sistema
Contrato de operaciones
Disciplina: Diseño
Arquitectura lógica y organización en capas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
22
11
Relaciones entre artefactos UP
Modelo de dominio
Perfil
Modelado de
negocio
Tiempo
ofrece
...
...
...
cantidad
Vision
Modelo de casos de uso
Requerimientos
Voluntario
Depositar Tiempo
1.El Voluntario
inserta….
2. El sistema
actualiza …
3….
Nombres de
casos de uso
Depositar
tiempo
Diagrama de casos de uso
Operación:
InsertaTiempo(..)
Pre-condiciones:
….
Post-condiciones:
…..
Glosario
Detalles sobre
parámetros,
return values
Texto de casos de uso
Eventos
de sistema
Especificaciones
suplementares
:Sistema
:Voluntario
Operaciones
InsertaTiempo()
sistema
Diagrama de
secuencia de sistema
Contratos de operaciones
Eventos iniciales
:SecciónUsuario
InsertaTiempo
(desde,a,horas)
Diseño
Modelo de diseño :ArchivoTiempos
:Perfil
SalvaTiempoPerfil(idperfil, desde,a,horas): t
InsertaTiempo(t)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
23
Diagrama de Secuencia de Sistema
Es un artefacto que representa los eventos de input
y output del sistema
Disciplina: Requerimientos
Se usa un diagrama de secuencia UML con
No mencionados explicitamente en el UP “original”
Actores
El sistema “caja negra”
Dibujar un DSS para cada caso de uso
Para el escenario principal
Para escenarios alternativos complejos
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
24
12
DSS Volbank
Combinar ofertas y pedidos
(Escenario principal):
1. La Organización Voluntarios
empieza el proceso de combinación
2. el Sistema ejecuta las
combinaciones…
3. el Sistema mostra las
combinaciones encontradas
4. La Organización Voluntarions envía
a todos los Voluntarios…
5. El Voluntario acepta el trabajo….
6. La Organización actualiza el estado
de las combinaciones aceptadas...
7. La Organización Voluntarios envía
los detalles del Voluntario al
Necesitado..
8. El Necesitado acepta la
combinación encontrada
9. la Organización Voluntarios
actualiza el estado de la
combinación “con éxito”
10.la Organización Voluntarios
actualiza los tiempos de las ofertas
y pedidos de las partes interesadas
de la combinación con éxito (e
Organización
:
Voluntarios
:Sistema
EjecutaCombinación()
MostraCombinaciones
loop
[Para cada combinación]
SetConfirmaVoluntario(respuesta)
Combinación aceptada
SetConfirmaNecesitado(respuesta)
Combinación con exíto
ActualizaTiempos(de,á,horas)
Tiempos actualizados
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
25
Lección 2
Segunda fase: Elaboración (1a iteración)
Disciplina: Modelado de negocio
Disciplina: Requerimientos
Modelo de dominio
Diagrama de secuencia de sistema
Contrato de operaciones
Disciplina: Diseño
Arquitectura lógica y organización en capas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
26
13
Relaciones entre artefactos UP
Modelo de dominio
Perfil
Modelado de
negocio
Tiempo
ofrece
...
...
...
cantidad
Vision
Modelo de casos de uso
Requerimientos
Objectos de
dominio
atributos y
asociaciones que
sufren cambios
Voluntario
Depositar Tiempo
1.El Voluntario
inserta….
2. El sistema
actualiza …
3….
Nombres de
casos de uso
Depositar
tiempo
Ideas para
post-cond
Diagrama de casos de uso
Operación:
InsertaTiempo(..)
Pre-condiciones:
….
Post-condiciones:
…..
Glosario
Requerimientos que
tienen que ser
satisfechos por el sw
Texto de casos de uso
Eventos
de sistema
Especificaciones
suplementares
:Sistema
:Voluntario
Operaciones
InsertaTiempo()
sistema
Contratos de operaciones
Diagrama de
secuencia de sistema
:SecciónUsuario
Eventos iniciales
InsertaTiempo
(desde,a,horas)
Modelo de diseño :ArchivoTiempos
:Perfil
SalvaTiempoPerfil(idperfil, desde,a,horas): t
Diseño
InsertaTiempo(t)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
27
Contratos de operaciones
Son descripciones textuales, con pre-condiciones y
post-condiciones, de los cambios en los objetos del
modelo de dominio como consecuencia de una
operación de sistema
Operación de sistema: operación ofrecida por el
sistema (“caja negra”) en su interfaz pública
Disciplina: Requerimientos
No mencionados explícitamente en UP “original”
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
28
14
Operación de sistema
Organización
:
Voluntarios
:Sistema
EjecutaCombinación()
MostraCombinaciones
loop
[Para cada combinación]
SetConfirmaVoluntario(respuesta)
Combinación aceptada
SetConfirmaNecesitado(respuesta)
Estos eventos de sistema de input
son llamadas a operaciones de
sistema
El evento de sistema
EjecutaCombinación
llama a una operación de sistema
de nombre EjecutaCombinación….
Combinación con éxito
ActualizaTiempos(de,á,horas)
Tiempos actualizados
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
29
Secciones de un contrato
Operación
Nombre y parámetros de la operación
Referencias
Casos de uso donde se puede verificar
Pre-condición
Hipótesis (no triviales) significativas
sobre el estado del sistema/objetos del
modelo de dominio antes de la
ejecución de la operación
Postcondición
El estado de objetos del modelo de
dominio después haber completado
la operación (creación instancias y
link, modificaciones atributos).
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
30
15
Como crear y escribir contratos (I)
Identificar las operaciones de sistemas en los
DSS
Crear un contrato para cada operación de
sistema compleja
Escribir las post-condiciones usando las
siguientes categorías
Creación/cancelación de instancias
Modificación atributos
Creación/cancelación asociaciones (link)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
31
Simona Bernardi
Operaciones Volbank
Contrato C11
Operación: SetConfirmaVoluntario(boolean Respuesta)
Referencia: UC “Combinar ofertas y pedidos”
Organización
:
Voluntarios
Pre-condiciones:
Una combinación c ha sido seleccionada
El estado de c es “no confirmado”
MostraCombinaciones
loop [Para cada combinación]
La Organización ha recibido respuesta por el
Voluntario en relación a la combinación c
SetConfirmaVoluntario(respuesta)
Combinación aceptada
Post-condiciones:
:Sistema
EjecutaCombinación()
El estado de c está actualizado: “confirmado” si la
respuesta es positiva, “rechazado” si la respuesta es
negativa
SetConfirmaNecesitado(respuesta)
Combinación con éxito
ActualizaTiempos(de,á,horas)
Tiempos actualizados
Combinación
confirmada:Boolean
¿ Habrá que actualizar la
clase de dominio “Combinación” ?
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
32
16
Como crear y escribir contratos (II)
¿ Hay que escribir un contrato para cada operación
encontrada en el DSS ?
¿ Si se descubren nuevas clases, asociaciones,
atributos, se pueden añadir en el modelo de
dominio ?
No es necesario: consideramos sólo las más complejas
Claro! El proceso UP es incremental
¿ Las post-condiciones tienen que ser en cada
momento lo más completas posibles ?
No es necesario: el proceso UP es iterativo e incremental
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
33
DSS y contratos Volbank
Ejercicios para casa
Modificar el DSS presentado en clase (caso de uso “Combinar
ofertas y pedidos”) para incluir los escenarios alternativos
Escribir los contratos para las siguientes operaciones de
sistemas
(5a) El Voluntario no está disponible para la combinación
encontrada
(8a) El Necesitado no está disponible para la combinación
encontrada
SetConfirmaNecesitado(boolean respuesta)
ActualizaTiempos(date de, date á, integer horas)
Modificar/añadir atributos apropiados a la clase de dominio
“Combinación”
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
34
17
Lección 2
Segunda fase: Elaboración (1a iteración)
Disciplina: Modelado de negocio
Disciplina: Requerimientos
Modelo de dominio
Diagrama de secuencia de sistema
Contrato de operaciones
Disciplina: Diseño
Arquitectura lógica y organización en capas
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
35
Simona Bernardi
Transición al diseño: artefactos
Modelo de dominio
Modelado de
negocio
Requerimientos
*
*
Modelo casos de uso Especificaciones
complementarias
-
Vision
Glosario
Modelo de diseño
La arquitectura lógica depende de los
vínculos y requeriminentos non funcionales
capturados en las especificaciones
suplementares
:SecciónUsuario
Diseño
UI
Dominio
Servicios
Técnicos
Diagrama de package
de la arquitectura lógica
(vista estática)
:ArchivoTiempos
InsertaTiempo
(desde,a,horas) SalvaTiempoPerfil
(idperfil, desde,a,horas): t
SecciónUsuario
ArchivoTiempos
InsertaTiempo(…)
SalvaTiempoPerfil(…):..
Diagrama de interación
(vista dinámica)
Diagrama de clase
(vista estática)
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
36
18
Arquitectura lógica y capas
Macro-organización de clases software en
packages (o namespace), subsistemas y capas
Lógica: no hay decisiones sobre el desarrollo de
los elementos sw a través de procesos/nodos
físicos (parte de la arquitectura de desarrollo)
Capa: grupo de clases sw, packages,
subsistemas con responsabilidad compartida
sobre un aspecto importante del sistema
Capas típicas
Interfaz usuario
Lógica de la aplicación y objetos del dominio
Servicios técnicos
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
37
Simona Bernardi
Layers pattern
GUI windows, report,
HTML,XML,XSLT,Javascript,…
Handles presentation layer requests,
Workflow, session state, ....
UI
c(Presentation,View)
Application
c (Workflow,Process,
Mediation,App.Controller)
Handles application layer requests,
Implementation of domain rules,
domain services
Very general low-level business
services used in many business
domain, currency converter
Dependencia
Domain
(Business,Appl.Logic,Model)
c
(relatively) High level technical
services and frameworks,
persistence, security
c
Low-level technical services, utilities,
frameworks, data structure, threads,
math, file, DB, network I/O
c
Business Infrastructure
(Low-level Business Services)
Technical Services
(Technical Infrastructure,
High-level Technical Services)
Más específico
de la aplicación
Foundation
(Core services, Basic Services,
Low-level Technical Services/Infrastructure)
Amplitud de aplicabilidad
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
38
19
Relación entre Domain Layer y Modelo de
Dominio
Modelo de Dominio UP
Representación de conceptos de dominio
Perfil
Un Perfil en el modelo de
dominio es un concepto, pero
un Perfil en el modelo de
diseño es una clase sw.
No son la misma cosas, pero
el primero ha inspirado el
nombre y definición del
Segundo, reduciendo el hueco
de representación.
Ofrece
nombre
dirección
CAP
e-mail
*
.
Tiempo
desde
á
totalHoras
Inspira
objetos y
nombres en
Perfil
nombre
dirección
CAP
e-mail
…..
Tiempo
*
Ofrece{list}
InsertaTiempo(t: Tiempo): void
.....
desde
á
totalHoras
….
setTotalHoras(horas: int): void
....
Domain Layer de la arquitectura en el Modelo de Diseño UP
El analista sw toma inspiración del dominio del mundo real para
crear clases Sw.
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
39
Principio separación modelo-vista (I)
No conectar o acoplar objectos no-UI con objetos
UI
No encapsular la lógica de la aplicación en los
métodos de los objetos UI
Las ventanas pertenecen a una aplicación particular,
mientras los objetos no-UI puede ser reusados en nueva
aplicaciones o relacionados a nuevas interfaces
Los objetos UI inicializan elementos UI, reciben eventos
UI y delegan pedidos de la lógica de la aplicación en
objetos no-UI (objetos del dominio)
Modelo=Domain Layer, Vista= UI Layer
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
40
20
Operaciones de sistema y arquitectura en
Clase ventana GUI en
capas
Java swing
UI
Organización
Voluntario
Swing
Sistema
...
JFrameProcesa
Combinaciones
EjecutaCombinación()
SetConfirmaVoluntario()
SetConfirmaNecesitado()
EjecutaCombinación()
Organización
Voluntario
MostraCombinación
EjecutaCombinación()
SetConfirmaVoluntario()
SetConfirmaNecesitado()
loop
SetConfirmaVoluntario
(repuesta)
Combinación aceptada
SetConfirmaNecesitado
(repuesta)
....
Dominio
...
SesiónCombinación
EjecutaCombinación()
SetConfirmaVoluntario()
SetConfirmaNecesitado()
…
Las operaciones de sistema modeladas en el DSS representan
llamadas de operaciones de la capa Aplicación o Dominio por la capa UI
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
41
Principio separación modelo-vista (II)
Permite definir modelos con cohesión, haciendo hincapié
en los procesos de dominio antes que en la interfaz
usuario
Permite separar el desarrollo de la capa de dominio y de
la capa UI
Minimiza el impacto del cambio de requerimientos (del
dominio) en la capa UI
Permite conectar nuevas vistas a la misma capa de
dominio
Permite tener vistas simultáneas y múltiples del mismo
modelo de dominio
Permite ejecutar la capa de dominio en manera
independiente de la capa UI
Ingeniería del Software II
Departamento de Informática e Ingeniería de Sistemas (Univ.
Zaragoza)
Simona Bernardi
42
21
