ditditUPM
© DIT-UPM, 2005
Ingeniería del softwareTema 16: Diseño de sistemas con UML
DepartamentoDepartamento de de IngenierIngenierííaa de de SistemasSistemas TelemTelemááticosticos
Juan Carlos Yelmo García
ditditUPM 2
© DIT-UPM, 2005
ContenidosContenidosIntroducción y objetivosRepaso de conceptos de diseñoPatrones de asignación de responsabilidadesEl modelo de diseñoPatrones básicos de diseñoEl modelo de implementaciónDiseño e implementación en el Proceso Unificado
ditditUPM 3
© DIT-UPM, 2005
ObjetivosObjetivos
Conocer los principios bConocer los principios báásicos de disesicos de diseñño de o de sistemas softwaresistemas softwareConocer y saber utilizar UML en el diseConocer y saber utilizar UML en el diseñño de o de sistemas softwaresistemas softwareConocer las disciplinas, iteraciones y artefactos del Conocer las disciplinas, iteraciones y artefactos del modelo de proceso unificado directamente modelo de proceso unificado directamente relacionadas con el diserelacionadas con el diseññoo
ditditUPM 4
© DIT-UPM, 2005
El proceso de diseEl proceso de diseññooEn general, y con independencia de metodologEn general, y con independencia de metodologíías, as, notaciones y campos de aplicacinotaciones y campos de aplicacióón; el disen; el diseñño implica o implica utilizar una estrategia de reducciutilizar una estrategia de reduccióón de complejidad n de complejidad basada en reducir el problema a resolver por basada en reducir el problema a resolver por participarticióónny y descomposicidescomposicióónn en en subproblemassubproblemas cuya complejidad cuya complejidad resulte manejable (resulte manejable (modularidadmodularidad))Resueltos todos los Resueltos todos los subproblemassubproblemas, hay que , hay que integrarintegrarlas soluciones parciales para obtener la solucilas soluciones parciales para obtener la solucióón del n del problema globalproblema globalTanto la descomposiciTanto la descomposicióón del sistema, como la n del sistema, como la posterior integraciposterior integracióón de soluciones parciales, suelen n de soluciones parciales, suelen constar de varias fases o nivelesconstar de varias fases o niveles
ditditUPM 5
© DIT-UPM, 2005
Fases del proceso de diseFases del proceso de diseññoo
Diseño de arquitecturaDiseño de
arquitecturaDiseño
detalladoDiseño
detalladoEspecificaciónde requisitosdel software
Diseño dearquitectura
Diseño decomponentes
•Subsistemas•Interfaces•Interacciones•Control•Componentes
•Componentes•Interfaces•Módulos•Datos•Procedimientos•Algoritmos
ditditUPM 6
© DIT-UPM, 2005
Calidad de diseCalidad de diseññooCalidad desde la perspectiva del mantenimiento y la Calidad desde la perspectiva del mantenimiento y la reutilizacireutilizacióónn
Independencia funcionalIndependencia funcionalAlta cohesiAlta cohesióón en cada componenten en cada componenteBajo acoplamiento entre componentesBajo acoplamiento entre componentes
LegibilidadLegibilidadEsquema de nombradoEsquema de nombradoDocumentaciDocumentacióón completa y actualizadan completa y actualizadaSimplicidadSimplicidad
AdaptabilidadAdaptabilidadPrevisiPrevisióón y n y genericidadgenericidadAutomatizaciAutomatizacióón del acceso a documentacin del acceso a documentacióónnAutomatizaciAutomatizacióón del control de cambiosn del control de cambios
ditditUPM 7
© DIT-UPM, 2005
AnAnáálisis lisis vsvs DiseDiseññooEn un modelo de proceso iterativo, las iteraciones En un modelo de proceso iterativo, las iteraciones iniciales son una transiciiniciales son una transicióón constante entre actividades n constante entre actividades de ande anáálisis y diselisis y diseññooAl final de la fase de elaboraciAl final de la fase de elaboracióón se consideran n se consideran completos y estables la mayor parte de los requisitoscompletos y estables la mayor parte de los requisitosEl principal artefacto de la disciplina de diseEl principal artefacto de la disciplina de diseñño es el o es el modelo de disemodelo de diseñño:o:
Diagramas de clases de diseDiagramas de clases de diseñño (derivados en principio o (derivados en principio del modelo de dominio)del modelo de dominio)Diagramas de interacciDiagramas de interaccióónn
El enfoque GRASP: aplicaciEl enfoque GRASP: aplicacióón sistemn sistemáática de tica de principios bprincipios báásicos de disesicos de diseñño y patrones de asignacio y patrones de asignacióón n de responsabilidadesde responsabilidades
ditditUPM 8
© DIT-UPM, 2005
Modelo de DiseModelo de Diseññoo
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
UP Design Model
The object developer has taken inspiration from the real-world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
1 1
1 1
inspires objects
and names in
conceptual classes
designclasses
1: makePayment(cashTendered)
1.1: create(cashTendered)
: Register :Sale
:Payment
makePayment(cashTendered)
creation indicated with a "create" message
direction of message
first message
instance
first internal message
link line
parameter
ditditUPM 9
© DIT-UPM, 2005
ResponsabilidadesResponsabilidadesUna responsabilidad es un contrato u obligaciUna responsabilidad es un contrato u obligacióón de n de una clase en el contexto de un modelouna clase en el contexto de un modeloAtributos y operaciones son las caracterAtributos y operaciones son las caracteríísticas de sticas de la clase a travla clase a travéés de las cuales las s de las cuales las responsabilidades se llevan a cabo responsabilidades se llevan a cabo La responsabilidad global del modelo debe La responsabilidad global del modelo debe repartirse de forma equilibrada entre sus clasesrepartirse de forma equilibrada entre sus clasesAlgunos mAlgunos méétodos de disetodos de diseñño se basan en la o se basan en la asignaciasignacióón de responsabilidades a clases: e.g. n de responsabilidades a clases: e.g. CRC, GRASP, CRC, GRASP, ……
ditditUPM 10
© DIT-UPM, 2005
ResponsabilidadesResponsabilidadesLos objetos de un sistema tienen Los objetos de un sistema tienen responsabilidad u obligaciones de dos tipos:responsabilidad u obligaciones de dos tipos:Lo que deben Lo que deben hacerhacer
Realizar acciones y actividades: crear un objeto, Realizar acciones y actividades: crear un objeto, realizar un crealizar un cáálculo, lculo, ……Iniciar acciones en otros objetosIniciar acciones en otros objetosControlar y coordinar acciones en otros objetosControlar y coordinar acciones en otros objetos
Lo que deben Lo que deben conocerconocerLos datos que encapsulanLos datos que encapsulanLos objetos relacionadosLos objetos relacionadosLa informaciLa informacióón que pueden derivar y calcularn que pueden derivar y calcular
ditditUPM 11
© DIT-UPM, 2005
ContenidosContenidosIntroducción y objetivosRepaso de conceptos de diseñoPatrones de asignación de responsabilidadesEl modelo de diseñoPatrones básicos de diseñoEl modelo de implementaciónDiseño e implementación en el Proceso Unificado
ditditUPM 12
© DIT-UPM, 2005
Patrones de disePatrones de diseññooDescripciDescripcióón de un problema recurrente en el contexto n de un problema recurrente en el contexto del disedel diseñño OO y su solucio OO y su solucióón en tn en téérminos de clases, rminos de clases, instancias, colaboraciones y distribuciinstancias, colaboraciones y distribucióón de n de responsabilidadesresponsabilidadesEl patrEl patróón incluye recomendaciones de aplicacin incluye recomendaciones de aplicacióón en n en nuevos contextos y discusiones sobre consecuencias, nuevos contextos y discusiones sobre consecuencias, efectos colaterales y soluciones de compromisoefectos colaterales y soluciones de compromisoElementos bElementos báásicos de la descripcisicos de la descripcióón de un patrn de un patróónn
NombreNombreProblemaProblemaSoluciSolucióónnDiscusiDiscusióón sobre su aplicacin sobre su aplicacióónn
ditditUPM 13
© DIT-UPM, 2005
Patrones GRASPPatrones GRASPSe parte del modelo de dominio y se utilizan los Se parte del modelo de dominio y se utilizan los diagramas de interaccidiagramas de interaccióón como mecanismo bn como mecanismo báásico de sico de asignaciasignacióón de responsabilidadesn de responsabilidadesEl proceso de asignaciEl proceso de asignacióón de responsabilidades se n de responsabilidades se completa durante la actividad de programacicompleta durante la actividad de programacióónnGRASP: Patrones bGRASP: Patrones báásicos de asignacisicos de asignacióón de n de responsabilidades y aplicaciresponsabilidades y aplicacióón de principios bn de principios báásicos de sicos de disediseññooSe trata de principios sencillos y fundamentalesSe trata de principios sencillos y fundamentales
ExpertoExpertoCreadorCreadorBajo acoplamientoBajo acoplamientoAlta cohesiAlta cohesióónnControladorControlador
ditditUPM 14
© DIT-UPM, 2005
PatrPatróón Experton ExpertoProblema: Principio bProblema: Principio báásico de asignacisico de asignacióón de n de responsabilidadesresponsabilidadesSoluciSolucióón: Las responsabilidades deben asignarse a las n: Las responsabilidades deben asignarse a las clases que tienen la informaciclases que tienen la informacióón necesaria para n necesaria para llevarlas a cabollevarlas a caboEjemplo (TPV): Ejemplo (TPV): ¿¿QuQuéé clase debe conocer la suma total clase debe conocer la suma total de una venta?de una venta?
Es necesario conocer los artEs necesario conocer los artíículos de la venta y su culos de la venta y su cantidad y preciocantidad y precio
DiscusiDiscusióón: Aplicacin: Aplicacióón del principio de n del principio de encapsulaciencapsulacióónn. . Generalmente se requiere la interacciGeneralmente se requiere la interaccióón entre objetos n entre objetos que tienen informacique tienen informacióón parcialn parcial
ditditUPM 15
© DIT-UPM, 2005
PatrPatróón Experton Experto
Sale
datetime
SalesLineItem
quantity
ProductSpecification
descriptionpriceitemID
Described-by*
Contains
1..*
1
1
Sale
datetime
getTotal()
SalesLineItem
quantity
getSubtotal()
ProductSpecification
descriptionpriceitemID
getPrice()New method
:ProductSpecification
1.1: p := getPrice()
1 *: st := getSubtotal(): Salet := getTotal()
*:SalesLineItem
:SalesLineItem
ditditUPM 16
© DIT-UPM, 2005
PatrPatróón Creadorn CreadorProblema: Determinar la responsabilidad de creaciProblema: Determinar la responsabilidad de creacióón n de objetosde objetosSoluciSolucióón: La creacin: La creacióón de objetos de la clase A es n de objetos de la clase A es responsabilidad de la clase B si:responsabilidad de la clase B si:
B agrega o contiene objetos AB agrega o contiene objetos AB registra la creaciB registra la creacióón de objetos An de objetos AB utiliza con frecuencia objetos AB utiliza con frecuencia objetos AB tiene los datos de inicializaciB tiene los datos de inicializacióón de objetos An de objetos A
Ejemplo (TPV): Ejemplo (TPV): ¿¿QuQuéé clase debe crear instancias de clase debe crear instancias de SaleslineItemSaleslineItem??DiscusiDiscusióón: En ocasiones el proceso de creacin: En ocasiones el proceso de creacióón es n es complejo y se requiere la introduccicomplejo y se requiere la introduccióón de una clase n de una clase FactorFactorííaa ((GoFGoF) encargada de la creaci) encargada de la creacióón de objetosn de objetos
ditditUPM 17
© DIT-UPM, 2005
PatrPatróón Creadorn Creador
Sale
datetime
SalesLineItem
quantity
ProductSpecification
descriptionpriceitemID
Described-by*
Contains
1..*
1
1
: Register : Sale
makeLineItem(quantity): SalesLineItemcreate(quantity)
ditditUPM 18
© DIT-UPM, 2005
PatrPatróón Bajo Acoplamienton Bajo AcoplamientoProblema: Principio bProblema: Principio báásico para la obtencisico para la obtencióón de n de sistemas sistemas manteniblesmantenibles y reutilizablesy reutilizablesSoluciSolucióón: Las responsabilidades deben asignarse de n: Las responsabilidades deben asignarse de forma que se mantenga bajo el nivel de acoplamiento forma que se mantenga bajo el nivel de acoplamiento entre componentes del sistema. Una clase entre componentes del sistema. Una clase fuertemente acoplada: fuertemente acoplada:
Necesita cambios cuando cambian las clases Necesita cambios cuando cambian las clases relacionadasrelacionadasEs mEs máás difs difíícil de entender de forma aisladacil de entender de forma aisladaEs mEs máás difs difíícil de reutilizar porque requiere otras clases cil de reutilizar porque requiere otras clases de las que dependede las que depende
Ejemplo (TPV): Crear Ejemplo (TPV): Crear PaymentPayment y asociarlo a y asociarlo a SaleSaleDiscusiDiscusióón: El problema es el acoplamiento con n: El problema es el acoplamiento con componentes inestablescomponentes inestables
ditditUPM 19
© DIT-UPM, 2005
PatrPatróón Bajo Acoplamienton Bajo Acoplamiento
: Register : Sale
addPayment( p )
p : Paymentcreate()makePayment()
: Register : Sale
makePayment() : Paymentcreate()
makePayment()
ditditUPM 20
© DIT-UPM, 2005
PatrPatróón Alta Cohesin Alta CohesióónnProblema: Principio bProblema: Principio báásico para la obtencisico para la obtencióón de n de sistemas sistemas manteniblesmantenibles y reutilizablesy reutilizablesSoluciSolucióón: Las responsabilidades asignadas a n: Las responsabilidades asignadas a una clase no han de ser muchas y tienen que una clase no han de ser muchas y tienen que estar fuertemente relacionadasestar fuertemente relacionadasEjemplo (TPV): Crear Ejemplo (TPV): Crear PaymentPayment y asociarlo a y asociarlo a SaleSaleDiscusiDiscusióón: Las clases deben colaborar con n: Las clases deben colaborar con otras clases y delegar parte de la otras clases y delegar parte de la responsabilidad en tareas complejasresponsabilidad en tareas complejas
ditditUPM 21
© DIT-UPM, 2005
PatrPatróón Controladorn ControladorProblema: Determinar la responsabilidad en el manejo Problema: Determinar la responsabilidad en el manejo de eventos (operaciones) del sistemade eventos (operaciones) del sistemaSoluciSolucióón: Utilizar una clase controladora (n: Utilizar una clase controladora (fafaççadeade) que ) que represente al sistema o componente. Alternativamente, represente al sistema o componente. Alternativamente, utilizar una clase controladora por cada caso de usoutilizar una clase controladora por cada caso de usoEjemplo (TPV): Manejo de eventos del sistemaEjemplo (TPV): Manejo de eventos del sistemaDiscusiDiscusióón:n:
Evento del sistema: evento generado por un actor y Evento del sistema: evento generado por un actor y asociado a una operaciasociado a una operacióón del sisteman del sistemaLos eventos del sistema se identifican en la disciplina de Los eventos del sistema se identifican en la disciplina de ananáálisis (SSD)lisis (SSD)Las clases de interfaz pueden recibir este tipo de Las clases de interfaz pueden recibir este tipo de eventos, pero no realizan las tareas asociadas, sino que eventos, pero no realizan las tareas asociadas, sino que se los pasan a las clases controladoras, quienes se los pasan a las clases controladoras, quienes delegardelegaráán la realizacin la realizacióón en las clases apropiadasn en las clases apropiadas
ditditUPM 22
© DIT-UPM, 2005
PatrPatróón Controladorn ControladorRegister
...
endSale()enterItem()makeNewSale()makePayment()
makeNewReturn()enterReturnItem(). . .
System
endSale()enterItem()makeNewSale()makePayment()
makeNewReturn()enterReturnItem(). . .
system operations discovered during system behavior analysis
allocation of system operations during design, using one facade controller
ProcessSaleHandler
...
endSale()enterItem()makeNewSale()makePayment()
System
endSale()enterItem()makeNewSale()makePayment()
enterReturnItem()makeNewReturn(). . .
allocation of system operations during design, using several use case controllers
HandleReturnsHandler
...
enterReturnItem()makeNewReturn(). . .
ditditUPM 23
© DIT-UPM, 2005
PatrPatróón Controladorn Controlador
actionPerformed( actionEvent )
:Register
: Cashier
:SaleJFrame
presses button
1: enterItem(itemID, qty)
:Sale1.1: makeLineItem(itemID, qty)
Interface Layer
Domain Layer
system event message
controller
ditditUPM 24
© DIT-UPM, 2005
ContenidosContenidosIntroducción y objetivosRepaso de conceptos de diseñoPatrones de asignación de responsabilidadesEl modelo de diseñoPatrones básicos de diseñoEl modelo de implementaciónDiseño e implementación en el Proceso Unificado
ditditUPM 25
© DIT-UPM, 2005
El modelo de diseEl modelo de diseññooConjunto de diagramas de clases y escenarios Conjunto de diagramas de clases y escenarios de interaccide interaccióón (colaboraciones) como n (colaboraciones) como realizacirealizacióón de los casos de uson de los casos de uso
Los casos de uso permiten identificar eventos Los casos de uso permiten identificar eventos del sistema. del sistema. ÉÉstos se muestran en los stos se muestran en los SSDSSD’’ssLos eventos del sistema son eventos iniciadores Los eventos del sistema son eventos iniciadores en diagramas de interaccien diagramas de interaccióón que muestran la n que muestran la realizacirealizacióón de un caso de uson de un caso de usoLos diagramas de interacciLos diagramas de interaccióón muestran n muestran colaboraciones entre objetos de disecolaboraciones entre objetos de diseñño, o, inicialmente derivados del modelo de dominioinicialmente derivados del modelo de dominio
ditditUPM 26
© DIT-UPM, 2005
Eventos de sistema en el TPVEventos de sistema en el TPV
:RegisterenterItem()
:RegisterendSale()
:RegistermakePayment()
1: ???()
1: ???()
1: ???()
:RegistermakeNewSale() 1: ???()
ditditUPM 27
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: makeNewSalemakeNewSale
:Register
makeNewSale()
:Salecreate()
Register creates a Sale by Creator
create() :SalesLineItem
by Creator, Sale creates an empty multiobject (such as a List) which will eventually hold SalesLineItem instances
CAUTION:This is not a SalesLineItem instance. This is a collection object (such as a List) that can hold SalesLineitem objects.
by Creator and Controller
this activation is implied to be within the constructor of the Sale instance
ditditUPM 28
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: enterItementerItem
2: makeLineItem(spec, qty)enterItem(id, qty)
1: spec := getSpecification(id) 2.1: create(spec, qty)
1.1: spec := find(id)
:Register :Sale
:ProductCatalog
sl: SalesLineItem
SalesLineItem:SalesLineItem:Product
Specification
2.2: add(sl)
by Expert
by Controller
This find message is to the Map object (the multiobject), not to a ProductSpecification.
CAUTION:This is a multiobject collection (such as a Map), not a ProductSpecification. It may contain many ProductSpecifications.
CAUTION:This is a multiobject collection (such as a List), not a SalesLineItem. It may contain many SalesLineItems.
by Creator
add the newly created SalesLineItem instance to the multiobject (e.g., List)
ditditUPM 29
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: endSaleendSale
:RegisterendSale() s : Sale1: becomeComplete()
{public void becomeComplete( ){ isComplete = true;}} { s.isComplete = true }
a constraint implementation in a note box
observe the outer braces around the method signifying a constraint within a note box
a constraint that doesn't define the algorithm, but specifies what must hold as true
// a notecreated by Craig
ditditUPM 30
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: makePaymentmakePayment
:Saletot := getTotal() 1 *: st := getSubtotal()
:ProductSpecification
1.1: pr := getPrice()
: SalesLineItem*
{ st = aSLI.quantity * aSLI.prodSpec.price }
// observe the seudo code style here{public void getTotal(){ int tot = 0; for each SalesLineItem, sli tot = tot + sli.getSubtotal(); return tot}}
Note the semi-formal style of the constraint. "aSLI" is not formally defined, but most developers will reasonably understand this to mean an instance of SalesLineItem. Likewise with the expression aSLI.prodSpec.price.
The point is that the constraint language can be informal, to support quick and easy writing, if desired.
ditditUPM 31
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: makePaymentmakePayment
1: makePayment(cashTendered)
1.1: create(cashTendered)
:Register s :Sale
:Payment
makePayment(cashTendered)
:Store
2: addSale(s)
completedSales: SalecompletedSales: Sale
2.1: add(s)
by Expert
note that the Sale instance is named's' so that it can be referenced as a parameter in messages 2 and 2.1
ditditUPM 32
© DIT-UPM, 2005
Colaboraciones en el TPV: Colaboraciones en el TPV: makePaymentmakePayment
:Sale pmt: Payment1: amt := getAmount() bal := getBalance() 2: t := getTotal()
{ bal = pmt.amount - self.total }
Note the use of "self" in the constraint. The formal OCL uses the special variable "self" for "this" (in Java and C++). "self" in this constraint implies the instance of the Sale.
Although official OCL is not being used, this style is borrowing from it.
A constraint can be in any formal or informal language.
ditditUPM 33
© DIT-UPM, 2005
Colaboraciones en el TPV: inicializaciColaboraciones en el TPV: inicializacióónn
:Store :Register
pc:ProductCatalog
create() 2: create(pc)
1: create()
1.2: loadProdSpecs() :Product
Specification
1.1: create()
1.2.2*: add(ps)
1.2.1*: create(id, price, description)
ps:ProductSpecification
the * in sequence number indicates the message occurs in a repeating section
pass a reference to the ProductCatalog to the Register, so that it has permanent visibility to it
by Creator create an empty multiobject (e.g., a Map), not a ProductSpecification
ditditUPM 34
© DIT-UPM, 2005
Diagrama de clases de diseDiagrama de clases de diseññooDiagrama que ilustra la especificaciDiagrama que ilustra la especificacióón de clases e n de clases e interfaces software: interfaces software:
Clases, asociaciones, atributos, mClases, asociaciones, atributos, méétodostodosInterfacesInterfacesNavegabilidadNavegabilidadDependenciasDependencias
Se elabora en paralelo con la realizaciSe elabora en paralelo con la realizacióón de los casos n de los casos de uso (diagramas de interaccide uso (diagramas de interaccióón)n)Inicialmente las clases de diseInicialmente las clases de diseñño se inspiran en las o se inspiran en las clases del modelo de dominio que intervienen en la clases del modelo de dominio que intervienen en la realizacirealizacióón de los casos de uso, aunque no todas las n de los casos de uso, aunque no todas las clases de dominio estclases de dominio estáán presentes en el modelo de n presentes en el modelo de disediseñño y viceversao y viceversa
ditditUPM 35
© DIT-UPM, 2005
DCD: mDCD: méétodostodosLos mLos méétodos se identifican a partir de los todos se identifican a partir de los mensajes en los diagramas de interaccimensajes en los diagramas de interaccióónn
No se suelen incluir mNo se suelen incluir méétodos constructores ni todos constructores ni mméétodos de consulta y modificacitodos de consulta y modificacióón de atributosn de atributos
Un mensaje a un Un mensaje a un multiobjetomultiobjeto se interpreta como se interpreta como un mensaje dirigido al contenedor o colecciun mensaje dirigido al contenedor o coleccióón, n, no a cada uno de los objetosno a cada uno de los objetosSe aSe aññade informaciade informacióón de tipo para los atributos, n de tipo para los atributos, parparáámetros y valores de retornometros y valores de retorno
ditditUPM 36
© DIT-UPM, 2005
Clases de diseClases de diseññoo
SalesLineItem
quantity : Integer
getSubtotal() : Money
ProductCatalog
...
getSpecification(id: ItemID) : ProductSpecification
ProductSpecification
description : Textprice : MoneyitemID : ItemID
...
Store
address : Addressname : Text
addSale(s : Sale)
Payment
amount : Money
...
Register
...
endSale()enterItem(id : ItemID, qty : Integer)makeNewSale()makePayment(cashTendered : Money)
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem(spec : ProdSpecification , qty : Integer)makePayment(cashTendered : Money)getTotal() : Money
Return type of method void; no return value
ditditUPM 37
© DIT-UPM, 2005
DCD: asociaciones y navegabilidadDCD: asociaciones y navegabilidadNavegabilidad: propiedad (punta de flecha) asociada al Navegabilidad: propiedad (punta de flecha) asociada al rol en el extremo de una asociacirol en el extremo de una asociacióón que implica n que implica visibilidad unidireccional entre objetos a travvisibilidad unidireccional entre objetos a travéés de la s de la asociaciasociacióónnEn la implementaciEn la implementacióón se traduce en la existencia de un n se traduce en la existencia de un atributo en la clase origen que es una referencia a una atributo en la clase origen que es una referencia a una instancia de la clase destinoinstancia de la clase destinoLa navegabilidad se deduce de los diagramas de La navegabilidad se deduce de los diagramas de interacciinteraccióón como realizacin como realizacióón de los casos de uson de los casos de usoEn el DCD las asociaciones representan necesidad de En el DCD las asociaciones representan necesidad de interacciinteraccióón y visibilidad, mientras que en el modelo de n y visibilidad, mientras que en el modelo de dominio representan relaciones estructurales entre dominio representan relaciones estructurales entre abstraccionesabstraccionesEn el DCD pueden aparecer asociaciones no En el DCD pueden aparecer asociaciones no presentes en el modelo de dominiopresentes en el modelo de dominio
ditditUPM 38
© DIT-UPM, 2005
Modelo de diseModelo de diseñño en el TPVo en el TPV
SalesLineItem
quantity : Integer
getSubtotal()
ProductCatalog
...
getSpecification(...)
ProductSpecification
description : Textprice : MoneyitemID: ItemID
...
Store
address : Addressname : Text
addSale(...)
Payment
amount : Money
...
Contains
1..*
Contains1..*
Register
...
endSale()enterItem(...)makeNewSale()makePayment(...)
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem(...)makePayment(...)getTotal()
Captures
Houses
Uses
Looks-in
Paid-by
Describes
1 1
1
1 1
1
11
1
1
1
1
1
*
A dependency of Register knowing about ProductSpecification.
Recommended when there is parameter, global or locally declared visibility.
Logs-completed4 *
1
ditditUPM 39
© DIT-UPM, 2005
ContenidosContenidosIntroducción y objetivosRepaso de conceptos de diseñoPatrones de asignación de responsabilidadesEl modelo de diseñoPatrones básicos de diseñoEl modelo de implementaciónDiseño e implementación en el Proceso Unificado
ditditUPM 40
© DIT-UPM, 2005
Patrones bPatrones báásicos de disesicos de diseññooEl trabajo de referencia sobre utilizaciEl trabajo de referencia sobre utilizacióón de patrones n de patrones se publicse publicóó en un libro cuyos autores son conocidos en un libro cuyos autores son conocidos como como TheThe Gan Gan ofof FourFour ((GoFGoF))
““DesignDesign PatternsPatterns: : ElementsElements ofof ReusableReusable ObjectObject--OrientedOrientedSoftware", Software", ErichErich Gamma, Richard Gamma, Richard HelmHelm, , RalphRalph JohnsonJohnson, , andand JohnJohn VlissidesVlissides. . AddisonAddison--WesleyWesley, 1995., 1995.
El libro contiene la descripciEl libro contiene la descripcióón de 23 patrones n de 23 patrones clasificados en patrones de creaciclasificados en patrones de creacióón, estructurales y n, estructurales y de comportamientode comportamientoLa idea inicial fue propuesta por La idea inicial fue propuesta por kentkent BeckBeck y y WardWardCunninghamCunningham en 1987, basada a su vez en una en 1987, basada a su vez en una propuesta de un lenguaje de patrones en arquitectura propuesta de un lenguaje de patrones en arquitectura de 1977 (Alexander, de 1977 (Alexander, IshikawaIshikawa, , SiversteinSiverstein))
ditditUPM 41
© DIT-UPM, 2005
Ejemplos de patrones Ejemplos de patrones GoFGoFAdaptador: AdaptaciAdaptador: Adaptacióón de clases o interfaces mediante n de clases o interfaces mediante un objeto intermediario para conseguir compatibilidad un objeto intermediario para conseguir compatibilidad (estructural)(estructural)FactorFactoríía: Delegacia: Delegacióón de la creacin de la creacióón de objetos en un n de objetos en un objeto factorobjeto factoríía cuando la la cuando la lóógica de gica de instanciaciinstanciacióónn es es compleja (creacicompleja (creacióón)n)SingletonSingleton: Clase de la que s: Clase de la que sóólo puede generarse una lo puede generarse una instancia. Para casos en que se necesita un punto de instancia. Para casos en que se necesita un punto de acceso a un servicio acceso a un servicio úúnico y global (creacinico y global (creacióón)n)Estrategia: SelecciEstrategia: Seleccióón dinn dináámica entre un conjunto de mica entre un conjunto de algoritmos relacionados. El algoritmo a utilizar puede algoritmos relacionados. El algoritmo a utilizar puede seleccionarse sobre la marcha dependiendo de seleccionarse sobre la marcha dependiendo de determinadas condiciones (comportamiento). determinadas condiciones (comportamiento).
ditditUPM 42
© DIT-UPM, 2005
ContenidosContenidosIntroducción y objetivosRepaso de conceptos de diseñoPatrones de asignación de responsabilidadesEl modelo de diseñoPatrones básicos de diseñoEl modelo de implementaciónDiseño e implementación en el Proceso Unificado
ditditUPM 43
© DIT-UPM, 2005
El modelo de implementaciEl modelo de implementacióónnEn principio, el modelo de diseEn principio, el modelo de diseñño contiene el detalle o contiene el detalle suficiente para generar csuficiente para generar cóódigo a partir de las clases de digo a partir de las clases de nivel de dominionivel de dominioLa actividad de diseLa actividad de diseñño se realiza en buena medida o se realiza en buena medida durante la implementacidurante la implementacióón. Sin embargo, la n. Sin embargo, la elaboracielaboracióón de un disen de un diseñño visual con UML es un buen o visual con UML es un buen punto de partida para la programacipunto de partida para la programacióónnInicialmente podemos generar cInicialmente podemos generar cóódigo a partir del digo a partir del modelo de disemodelo de diseñño, completarlo manualmente y o, completarlo manualmente y probarlo . En la siguiente iteraciprobarlo . En la siguiente iteracióón se hace ingeniern se hace ingenieríía a inversa del cinversa del cóódigo para refinar el modelo de disedigo para refinar el modelo de diseñño y o y volver a generar cvolver a generar cóódigo y asdigo y asíí sucesivamente: sucesivamente: roundround--triptrip engineeringengineering
ditditUPM 44
© DIT-UPM, 2005
RoundRound--triptrip engineeringengineering
RequirementsAnalysis
Design
Implementationand Testing
Iterative Cycles of Development
RequirementsAnalysis
Design
Implementationand Testing
RequirementsAnalysis
Design
Implementationand Testing
Time
ditditUPM 45
© DIT-UPM, 2005
GeneraciGeneracióón de cn de cóódigodigoEs posible generar cEs posible generar cóódigo a partir del DCDdigo a partir del DCD
Se generan clases e interfaces a partir del DCD con Se generan clases e interfaces a partir del DCD con atributos y las signaturas de los matributos y las signaturas de los méétodostodosSe aSe aññaden atributos de referencia a otros objetos a partir aden atributos de referencia a otros objetos a partir de asociaciones con navegabilidad y nombres de rolesde asociaciones con navegabilidad y nombres de rolesLa mensajes especificados en los diagramas de La mensajes especificados en los diagramas de interacciinteraccióón permiten generar algunas invocaciones de n permiten generar algunas invocaciones de los mlos méétodos correspondientestodos correspondientesSe incluyen contenedores o colecciones para la Se incluyen contenedores o colecciones para la multiplicidad multiplicidad ““muchosmuchos”” de las agregacionesde las agregacionesSe genera cSe genera cóódigo comenzando por las clases menos digo comenzando por las clases menos acopladasacopladasSe completa el cSe completa el cóódigo y se disedigo y se diseññan pruebas unitariasan pruebas unitarias
ditditUPM 46
© DIT-UPM, 2005
GeneraciGeneracióón de cn de cóódigodigo
SalesLineItem
quantity : Integer
getSubtotal() : Money
ProductSpecification
description : Textprice : MoneyitemID : ItemID
...
Described-by
public class SalesLineItem{private int quantity;
private ProductSpecification productSpec;
public SalesLineItem(ProductSpecification spec, int qty) {... }
public Money getSubtotal() { ... }}
* 1
Simple attribute
Reference attribute
ditditUPM 47
© DIT-UPM, 2005
GeneraciGeneracióón de cn de cóódigodigo
ProductCatalog
...
getSpecification(...)
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem(...)makePayment(...)getTotal()
Captures
Looks-in
Register
...
endSale()enterItem(id: ItemID, qty : Integer)makeNewSale()makePayment(cashTendered : Money)
public class Register{private ProductCatalog catalog;private Sale sale;
public Register(ProductCatalog pc) {...}
public void endSale() {...}public void enterItem(ItemID id, int qty) {...}public void makeNewSale() {...}public void makePayment(Money cashTendered) {...}}
1
11
1
2: makeLineItem(spec, qty)enterItem(id, qty)
1: spec := getSpecification(id)
:Register :Sale
:ProductCatalog
{ ProductSpecification spec = catalog.getSpecification(id); sale.makeLineItem(spec, qty);}
ditditUPM 48
© DIT-UPM, 2005
GeneraciGeneracióón de cn de cóódigodigo
SalesLineItem
quantity : Integer
getSubtotal()
ProductCatalog
...
getSpecification(...)
ProductSpecification
description : Textprice : MoneyitemID : ItemID
...
Store
address : Addressname : Text
addSale(...)
Payment
amount : Money
...
Contains
1..*
Contains1..*
Register
...
endSale()enterItem(...)makeNewSale()makePayment(...)
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem(...)makePayment(...)getTotal()
Captures
Houses
Uses
Looks-in
Paid-by
Describes
1 1
1
1 1
1
11
1
1
1
1
1
*
Logs-completed4 *
1
1
23
4
56
7
ditditUPM 49
© DIT-UPM, 2005
DiseDiseñño e implementacio e implementacióón en el UPn en el UPDisciplina Artefacto Inicio
I1Elaboración
E1…EnConstrucción
C1…CnTransición
T1…Tn
Modeladode negocio
Modelode dominio
RequisitosModelo de
Casos de UsoVisión
EspecificaciónComplementaria
Prototipos
cccop
rrr
c, r
c, r
Diseño Modelo de Diseño
Documento deArquitectura
Modelo de Datos
c, r
c
r
r
c, r
Implementación Modelo deImplementación c r r
Top Related