Ingeniería del software Tema 16: Diseño de sistemas con UML

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


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()



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



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


makeNewReturn()enterReturnItem(). . .

system operations discovered during system behavior analysis

allocation of system operations during design, using one facade controller

ProcessSaleHandler

...


System


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


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


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


: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


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(...)


description : Textprice : MoneyitemID: ItemID

...

Store


addSale(...)

Payment

amount : Money

...

Contains

1..*

Contains1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale


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 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 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


Design



Design


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



...

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


ProductCatalog

...


Sale



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


SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...




...

Store


addSale(...)

Payment

amount : Money

...

Contains

1..*

Contains1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale



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

Ingeniería del software Tema 16: Diseño de sistemas con UML

Documents

Transcript of Ingeniería del software Tema 16: Diseño de sistemas con UML