UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un...

UML

José Vargas Mery

Diagramas UML

UML ofrece cinco grupos diferentes de diagramas para modelar un sistema– Casos de Uso– Estructura– Estado– Comportamiento– Implementación

Diagramas UML

Diagramas de

Casos de UsoDiagramas

de Clases

Diagramas

de Objetos

Diagramas de Colaboración

Diagramas de Secuencia

Diagramas de Estados

Diagramas de Actividades

Diagramas de Despliegue

Diagramas de Componentes

Modelo del

Sistema

Diagramas UML

Casos de Uso– Diagramas de Casos

de Uso

Estructura– Diagramas de Clases– Diagramas de Objetos

Estado– Diagramas de Estados– Diagramas de

Actividades

Comportamiento– Diagramas de

Secuencia– Diagramas de

Colaboración

Implementación– Diagramas de

Componentes– Diagramas de

Despliegue

Actividades Generales del análisis Orientado Objeto

1. Modelar las funciones del sistema.2. Encontrar e identificar los objetos del

negocio.3. Organizar los objetos e identificar sus

relaciones.4. Modelar el comportamiento de los objetos.

Modelación de Casos de Uso

Modelación de las funciones de un sistema en términos de los eventos del negocio, quién los inicia, y cómo responde el sistema a ellos.

Caso de Uso

Secuencia de pasos o actividades relacionadas por su comportamiento (un escenario), tanto automatizadas como manuales, que tienen como fin completar una única tarea del negocio.

Notación en UML

Comprar productos

Actor

Representa cualquier cosa que necesita interactuar con el sistema para intercambiar información.

Un actor es un usuario del sistema, un rol, que puede ser tanto una persona como un sistema externo.

En un caso de uso, hay un actor que inicia la acción y, posiblemente, otros actores participantes.

Notación en UML Cajero

Casos de Uso - ejemplo El siguiente caso de uso de alto nivel describe el

proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta.

Caso de uso: Comprar productos

Actores: Cliente, Cajero

Tipo: Primario

Descripción: Un Cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los artículos comprados.

Cursos de Eventos

Curso normal de los eventos– Describe en detalles la interacción entre los

actores y el sistema.– Un aspecto esencial es que explica la

secuencia más común de los eventos; no incluye situaciones alternativas.

Curso alternativo de los eventos– Describe importantes opciones o excepciones

que pueden presentarse en relación con el curso normal.

– Si son complejas, se pueden expandir y convertir en otros casos de uso.

Curso Normal de Eventos

Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja TPDV (Terminalde Punto de Ventas) con productos que

desea comprar.2. El Cajero registra la identificación de cada

producto.Si hay varios productos de una misma

categoría, el Cajero también puede introducirla cantidad.

3. Determina el precio del producto eincorpora a la transacción actual lainformación correspondiente.

Se presentan la descripción y el precio delproducto actual.

4. Al terminar de introducir los productos, elCajero indica al TPDV que se concluyó lacaptura de productos.

5. Calcula y presenta el total de la venta.

6. El Cajero indica el total al Cliente.

Curso Normal de Eventos

7. El Cliente efectúa el pago en efectivo – el“efectivo ofrecido” – posiblemente mayor

que el total de la venta.8. El Cajero registra la cantidad de efectivo

recibida.9. Muestra al cliente la diferencia. Genera un

recibo.10. El Cajero deposita el efectivo recibido yextrae el cambio de pago.El Cajero le da al Cliente el cambio y el

recibo impreso.

11. Registra la venta concluida.

12. El Cliente se marcha con los artículoscomprados.

Cursos alternativos· Línea 2: introducción del identificador inválido. Indicar error.· Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.

Casos de Uso – Eventos Temporales

Evento temporal– Es un evento del sistema que es gatillado

por el paso del tiempo.– El actor del caso de uso de un evento

temporal es el tiempo.

Beneficios de la Modelación de Casos de Uso

Base para identificar objetos y sus relaciones y responsabilidades de alto nivel.

Visualizar el comportamiento del sistema desde el punto de vista de una persona externa.

Herramienta eficaz para validar requisitos. Herramienta eficaz de comunicación. Base para un plan de prueba. Base para un manual de usuario.

Proceso de Modelación de Casos de Uso

Paso 1: Identificar Actores y Casos de Uso Paso 2: Construir un Diagrama de Casos de

Uso Paso 3: Documentar el Curso Normal del Caso

de Uso Paso 4: Definir Caso de Uso de Análisis

MemberServicesSystem

MarketingDepartment

PotentialMember

ClubMember

Warehouse

AccountsReceivable

PastMember

MemberServices

various Inquiry Reponses

various Sales Reports

variousPromotion Reports

Subscription Offer

Member Order

New Subscription

Promotion

Subscription Renewal

Resubscription Offervarious MemberReports

various Subscription Reports

Subscription ProgramNew Promotion

Revised Packing Order

MemberCreditStatus

Diagrama de Contexto – Sistema de Servicio al Cliente

ActorPotentialMemberClubMemberClubMemberClubMemberClubMemberClubMemberPastMemberMarketing

Marketing

Marketing

Time

Time

Time

Time

Time

Use Case NameSUBMIT NEWSUBSCRIPTIONPLACE NEW MEMBERORDERMAKE ACCOUNT INQUIRY

MAKE PURCHASE INQUIRY

MAINTAIN MEMBER ORDER

SUBMIT CHANGE OFADDRESSSUBMITRESUBSCRIPTIONSUBMIT NEW MEMBERSUBSCRIPTION PROGRAMSUBMIT PAST MEMBERRESUBSCRIPTIONPROGRAMSUBMIT NEW PROMOTION

GENERATE QUARTERLYPROMOTION ANALYSISGENERATE QUARTERLYSALES ANALYSISGENERATE QUARTERLYMEMBERSHIP ANALYSISGENERATE ANNUAL SALESANALYSISGENERATE ANNUALMEMBERSHIP ANALYSIS

Use Case DescriptionPotential member joins the club by subscribing. (“Take anu 12 CDs for one penny and agree to buy 4 more at regular club prices within two years.”)Club member places order.

Club member wants to examine his or her account history.(90-day time limit)Club member inquires about his/her purchase history.(three-year time limit)Club member wants to revise an order or cancel an order.

Club member changes address.(including e-mail and privacy code)Past member rejoins the club by resubscribing.

Marketing establishes a new membership resubscription plan to entice new members.Marketing establishes a new membership resubscription plan to lure back former members.

Marketing initiates a promotion.(Note: A promotion features specific titles, usually new, that company is trying to sell at a special price. These promotions are integrated into a catalog sent (or communicated) to all members.)Print quarterly promotion analysis report.

Print annual sales analysis report.

Print annual membership analysis report.

Print annual sales analysis report.

Print annual membership analysis report.

Paso 1:Identificar Actores y Casos de Usos

Paso 2:Construir un Diagrama de Casos de Usos

Paso 3:Documentar curso normal del caso de uso

Paso 3:Documentar curso normal del caso de uso

Referencia a los requerimientos con los cuales está relacionado.

El curso común del evento que describe los pasos principales del caso del uso, desde cuando comienza hasta cuando termina la interacción con el actor.

Cursos alternativos que describen excepciones al curso común del evento.

Precondición que describe el estado en que debe estar el sistema para que se ejecute el caso del uso.

Poscondición que describe el estado en que queda el sistema después de que se ejecuta el caso del uso.

Supuestos, que incluye cualquier tópico no relacionado con el comportamiento del caso de uso, tales como rendimiento o seguridad, que está asociado al caso de uso. En general, son aspectos que son difíciles de modelar dentro del curso de eventos del caso de uso.

1

2

3

4

5

6

Tipos de Casos de Usos

Caso de Uso de Extensión– Amplía la funcionalidad (curso normal) de un

cierto caso de uso.– Un caso de uso de extensión puede ser

invocado solamente por el caso del uso que está ampliando.

Caso de Uso Abstracto– Contiene los cursos normales que son

comunes a dos o más casos de uso originales.– Un caso de uso abstracto reduce redundancia

y promueve la reutilización.

Representación usando la notación de UML

Generar Orden deDespacho

Calcular Subtotal eImpuestos Pedido

Completar PedidoCliente Nuevo

Revisar Dirección

Solicitar Cambiode Dirección

«extends» «extends»

«uses»

«uses»

Casos de Uso – Relaciones

UML define tres tipos de relación en los Diagramas de Casos de Uso

Comunicación

ActorCaso de Uso


Inclusión– Una instancia del Caso de Uso origen

incluye también el comportamiento descrito por el Caso de Uso destino

<<include>> es equivalente a <<uses>>

Caso de Uso Origen Caso de Uso Destino

<<include>>


Extensión– El Caso de Uso origen extiende el

comportamiento del Caso de Uso destino

Caso de Uso Origen Caso de Uso Destino

<<extend>>

Paso 4:Definir Caso de Uso de Análisis

Actividades Generales del Análisis Orientado Objeto




Encontrar e Identificar Objetos del Negocio Paso 1: Encontrar objetos potenciales

– Subrayar (o destacar) los sustantivos del caso de uso

Paso 2: Seleccionar los objetos propuestos– Quitar los sustantivos que representan:

• Sinónimos• Sustantivos fuera del alcance del sistema• Sustantivos que son roles que no tienen un

comportamiento único o que son externos• Sustantivos confusos que necesitan ser

reenfocados• Sustantivos que son en realidad acciones o

cualidades

Caso de uso con Sustantivos Subrayados

Objetos Potenciales

Extraídos desde el caso de uso

Análisis de Objetos Potenciales

POTENTIAL OBJECT LISTAccounts Receivable DepartmentAmount Due Club Member Credit Card InformationCredit Problem NoticeCredit Status File Marketing DepartmentMember AddressMember OrderMember Phone NumberMember Services DepartmentMember Services SystemOrder Order Confirmation NoticeOrder Sales TaxOrder Status Order SubtotalOrdered ProductOrdered Product InformationOrdered Product QuantityPast Member Payments Potential MemberProduct Product InventoryProduct NumberStreet Address Transaction Warehouse Warehouse Packing Order

POTENTIAL OBJECT LISTAccounts Receivable DepartmentAmount Due Club Member Credit Card InformationCredit Problem NoticeCredit Status File Marketing DepartmentMember AddressMember OrderMember Phone NumberMember Services DepartmentMember Services SystemOrder Order Confirmation NoticeOrder Sales TaxOrder Status Order SubtotalOrdered ProductOrdered Product InformationOrdered Product QuantityPast Member Payments Potential MemberProduct Product InventoryProduct NumberStreet Address Transaction Warehouse Warehouse Packing Order

Not relevant for current project Attribute of “MEMBER ORDER” Type of “MEMBER”

Attribute of “MEMBER”

Potential Interface item to be addressed in object-oriented design Attribute of “MEMBER” Not relevant for current project Not relevant for current project Attribute of “MEMBER” “MEMBER ORDER”


Not relevant for current project


Another name for “MEMBER ORDER”

Potential Interface item to be addressed in object-oriented design Attribute of “MEMBER ORDER”

Attribute of “MEMBER ORDER”

Attribute of “MEMBER ORDER”

“MEMBER ORDERED PRODUCT”

Unclear noun

Attribute of “MEMBER ORDERED PRODUCT” Type of “MEMBER” Type of “TRANSACTION”

Type of “MEMBER”

“PRODUCT”

Attribute of “PRODUCT”

Attribute of “PRODUCT”


“TRANSACTION”


Potential Interface item to be addressed in object-oriented design

REASONxx

xxxxxx

xxxxxxxx

xx

xxx

xx

/

////

/

/

/

Resultadosdel Análisis

PROPOSED OBJECT LISTCLUB MEMBER

MEMBER ORDERMEMBER ORDERED PRODUCTPAST MEMBERPAYMENTPOTENTIAL MEMBERPRODUCTTRANSACTION

AGREEMENTAUDIO TITLE

MERCHANDISE

GAME TITLEPROMOTION

RETURNTITLEVIDEO TITLE

-- PLUS --

Actividades Generales delAnálisis Orientado Objeto




Diagramas que muestran la estructura del sistema

Diagrama de clases– Muestra las clases de objetos de las que

está compuesto el sistema, así como las relaciones que existen entre ellos.

Diagrama de objetos– Similar al anterior, pero muestra instancias

individuales de cada clases.

Objetos, Atributos, e Instancias

Objeto– Es algo (persona, lugar, cosa, o evento) que

es visto, tocado, o percibido de alguna manera, y sobre el cual los usuarios almacenan datos y le asocian un cierto comportamiento.

Atributos– Datos que representan características de

interés de un objeto. Instancia

– Una instancia (o instancia de un objeto) está formada por los valores para cada uno de los atributos que describen un objeto específico.

Objetos, Atributos, e Instancias

412209: Customer

customer number = 412209last name = Bentleyfirst name = Lonniehome phone = 317-463-9593street = 2625 Darwin Dr.city = West Lafayettestate = Indianazip code = 47906etc.

0256101329: Book

ISBN = 0256101329type = textbooktitle = Systems Analysis & Design Methodscopyright = 1996

0256102219: Book

ISBN = 0256102219type = workbooktitle = Projects and Cases to Accompany SADMcopyright = 1996

(a)

(b)

Método

Se entiende por comportamiento a todo aquello que el objeto pueda hacer y que corresponde a funciones que actúan sobre los datos (atributos) del objeto.

En el contexto de orientación a objetos, se utiliza el concepto de método (o servicio) para referirse al comportamiento de un objeto.

Encapsulación

Es la agrupación de varios elementos en una unidad.

Los atributos y métodos se encapsulan en el objeto. La única forma de acceder a los atributos de un objeto es a través de sus métodos.

Clases de Objetos

Es un conjunto de objetos que tienen en común los mismos atributos y el mismo comportamiento.

Las clases también se denominan clases de objetos.

Open()Close()

ISBNtypetitlecopyright

Book Customer

customer numberlast namefirst namehome phonestreetcitystatezip codeetc.

changeAddress()

Herencia

Describe el mecanismo mediante el cual los atributos y/o métodos definidos para una clase de objetos puede ser heredado o reutilizado por otra clase de objetos.

Generalización/Especialización– Es una técnica donde los atributos y

métodos que son comunes a varios tipos de clases de objetos se agrupan en su propia clase, llamada supertipo. Los atributos y métodos de la clase de objetos supertipo son heredados a las clases de objetos originales.

Supertipos y Subtipos

Clase Supertipo– Es una clase de objetos cuyas instancias

almacenan atributos que son comunes a una o más clases subtipos.

Clase Subtipo– Es una clase de objetos cuyas instancias

heredan algunos atributos comunes de una clase supertipo, y luego agregan otros atributos que son únicos para las instancias del subtipo.

Supertipos y Subtipos

Clase Persona(supertipo)

Clase Alumno(subtipo)

Clase Profesor(subtipo)

Alumno A Alumno B Alumno C Profesor A Profesor B

Generalización/Especialización en UML

walk()jump()talk()sleep()eat()etc.()

last namefirst namebirth dategender

Person

enroll()displayGPA()

GPAclassification

Student

lecture()

rank

Teacher

Puntas de flechas indican relación degeneralización/especialización

Relaciones entre clases de objetos

Es una asociación natural de negocios que existe entre una o más clases de objetos.

0..*Customer Order

Places

Multiplicidad

Define como varias instancias de una clase de objetos puede ser asociada con una sola instancia de otra clase de objetos.

Multiplicity Multiplicity

Works for

0..1Has

0..*Makes

UML Notation

Association with Multiplicity Association Meaning

Exactly 1

1

or

leave blank

DepartmentEmployee1Works for

DepartmentEmployee

An employee works for one and only one department.

Zero or one 0..1 SpouseEmployeeAn employee has either one or no

spouse.

Zero or more

0..*

or

*

PaymentCustomer

PaymentCustomerMakes *

A customer can make no payment

up to many payments.

One or more 1..* CourseUniversityOffers 1..* A university

offers at least 1 course up to

many courses.

Specific range 7..9 GameTeam

7..9Has

scheduled A team has either 7, 8, or 9 games

scheduled

Notación de Multiplicidad en UML

Book

Cover Table of Contents

Chapter Index

Page

Paragraph

Word

1 1..*0..1 0..1

1..*

0..*

1..*

Diamante sólido indica relación de agregacióncompuesta

Ejemplo en UML de una relación de agregación compuesta

Team

Player

0..*

0..*Diamante hueco indicauna relación deagregación compartida

Ejemplo en UML de una relación de agregación compartida

Mensaje

Customeradd ordermodify orderdelete orderdisplay statusetc.

order numberorder dateorder statusetc.

Order

display order statusof order 23161

MENSAJESOLICITADO

(contiene nombre del método solicitado y los atributos requeridos por la clase ORDER)

Se pasa un mensaje cuando un objeto invoca uno o más métodos de otro objeto para requerir información o producir una acción.

Construcción de un Diagrama de Clases

Paso 1: Identificar Asociaciones y Multiplicidad– Subrayar (o destacar) los sustantivos del

caso de uso Paso 2: Identificar relaciones de

Generalización /Especialización Paso 3: Identificar relaciones de Agregación Paso 4: Preparar el diagrama de Clases

<<actor>>Club Member

Member-Date-Of-Last-OrderMember-Daytime-Phone-NumberMember-Credit-Card-Expire-DateMember-Credit-Card-NumberMember-Credit-Card-TypeMember-Balance-DueMember-Bonus-Balance-AvailableAudio-Category-PreferenceAudio-Media-PreferenceDate-EnrolledEmail-AddressGame-Category-PreferenceGame-Media-PreferenceNumber-Of-Credits-EarnedPrivacy-CodeVideo-Category-PreferenceVideo-Media-Preference

persistent

Member Order

Order-NumberOrder-Creation-DateOrder-Fill-DateShipping-Address-NameShipping-Street-AddressShipping-CityShipping-StateShipping-Zip-CodeShipping-InstructionsOrder-Sub-TotalOrder-Sales-TaxOrder-Shipping-MethodOrder-Shipping-&-Handling-CostOrder-StatusOrder-Prepaid-AmountOrder-Prepayment-Method

persistent

ProductProduct-NumberUPC-Quantity-In-StockProduct-TypeSuggested-Retail-PriceDefault-Unit-PriceCurrent-Special-Unit-PriceCurrent-Month-Units-SoldCurrent-Year-Units-SoldTotal-Lifetime-Units-Sold

persistent

Video Title

ProducerDirectorVideo-CategoryVideo-Sub-CategoryClosed-CaptionedLanguageRunning-TimeVideo-Media-TypeVideo-EncodingScreen-AspectMPA-Rating-Code

persistent

Audio Tilte

ArtistAudio-CategoryAudio-Sub-CategoryNumber-Of-Units-In-PackageAudio-Media-CodeContent-Advisory-Code

persistent

Transaction

Transaction-Reference-NumberTransaction-DateTransaction-TypeTransaction-DescriptionTransation-Amount

persistent

MemberMember-NumberMember-NameMember-StatusMember-Street-AddressMember-PO-BoxMember-CityMember-StateMember-Zip-Code

persistent

Agreement

Agreement-NumberAgreement-Expire-DateAgreement-Active-DateFulfillment-PeriodRequired-Number-Of-Credits

persistent

Game Title

ManufacturerGame-CategoryGame-Sub-CategoryGame-PlatformGame-Media-TypeNumber-Of-PlayersParent-Advisory-Code

persistent

Title

Title-Of-WorkTitle-CoverCatalog-DescriptionCopyright-DateEntertainment-CompanyCredit-Value

persistent

Member Ordered Product

Quantity-OrderedQuantity-ShippedQuantity-BackorderedPurchase-Unit-PriceCredits-Earned

persistent

Merchandise

Merchandise-NameMerchandise-DescriptionMerchandise-TypeUnit-of-Measure

persistent

Promotion

Promotion-NumberPromotion-Release-DatePromotion-StatusPromotion-Type

persistent

<<actor>>Potential Member

persistent

<<actor>>Past Member

Expiration-Date

persistent

Return

persistent

1..*

1binds

1

0..*

Conducts

1

0..*

Haspurchased

0..10..*

Generates0..*

1..*

Features

1

0..*Sold as

0..*

1

Places

1

1..*

Sells

Diagrama de Clases del Sistema de Servicio a Clientes

Actividades Generales del Análisis Orientado Objeto



relaciones.4. Modelar el comportamiento de los

objetos.

Diagramas que describen el estado de los objetos

Diagramas de Estados– Los diagramas de estados se utilizan para

modelar el comportamiento dinámico de un objeto particular.

– Ilustran el ciclo de vida de un objeto – los varios estados que un objeto puede asumir y los eventos que causan la transición del objeto de un estado a otro.

estado"PRE-LANZAMIENTO"

estado“VUELO"

“Despegue"

Ejemplo de Estados de un Objeto

Posibles “estados” del Trasbordador Espacial

Diagrama de estados

Modela el ciclo de vida de un solo objeto. Representa los diversos estados que un objeto

puede tener, los eventos que hacen que el objeto cambie de estado en el tiempo, y las reglas que gobiernan la transición del objeto entre los estados.

Especifica de qué estado de un objeto es posible la transición a otro estado.

Los diagramas de estados no son requeridos para todos los objetos. Típicamente, un diagrama de estados se construye solamente para aquellos objetos que tienen estados claramente identificables y un comportamiento complejo.

Diagrama de estados – teléfono

Ocioso Activo

descolgar auricular

colgar auricular

Estado

Estado inicial

TransiciónEvento

Diagrama de estados – casos de uso

Una aplicación útil de este tipo de diagramas consiste en describir la secuencia permitida de eventos externos que reconoce y maneja un sistema dentro del contexto de un caso de uso.

Es útil para describir el orden legal de los eventos externos.

Diagrama de estados – casos de uso

Ejemplos:– En el caso Comprar Productos de la

aplicación del punto de venta, no está permitido efectuar la operación efectuarPagoConTarjeta mientras no haya ocurrido el evento terminarVenta.

– En el caso Procesar Documento en un procesador de texto, no está permitido efectuar la operación Guardar en Archivo mientras no haya ocurrido el evento Crear Archivo Nuevo o Abrir Archivo.

Diagrama de estados – comprar productos

EnEsperadelaVenta

EnEsperadelPago

efectuarPago

Evento del sistema(externo)

IntroduciendoProductosintroducirProducto

terminarVenta

introducirProducto

Order Shipped

Order Released Order Filled

Order Invoiced

PendingIn Process

Order Backordered

Order ClosedMember Order final

state

Member Order finalstate

Member Order initial state

Order pending awaiting payment or additional member information

Order rejected based on Member's past history

Member order archived after 90 days

Invoice sent to member for payment

Response received from memberOrder released

to the warehouse

Order shipped to club member

Order filled by the warehouse

Not all product available

Final payment received

Order submitted

Product received

Diagrama de estadosdel Sistema de Servicio a Clientes

Diagramas que describen el estado de los objetos

Diagramas de Actividades– Los diagramas de actividades se utilizan

para representar gráficamente el flujo secuencial de actividades de un proceso de negocios o un caso de uso.

– También pueden ser utilizados para modelar las acciones que serán realizadas cuando una operación se está ejecutando así como los resultados de dichas acciones.

Input Request Route to Manager

Evaluate Need

Check Budget

[need][budget]

[no need] [no budget

DisapproveRequest

ApproveRequest

Route to Purchasing Agent

Diagrama de Actividades

Diagramas que describen el comportamiento de los objetos

Diagramas de Secuencia– Los diagramas de secuencia representan

gráficamente cómo los objetos interactúan entre sí vía mensajes en la ejecución un caso de uso.

– Ilustran cómo se envían y reciben los mensajes entre los objetos y en qué secuencia.

Eventos y operaciones del sistema

Evento del sistema– Es un hecho externo que un actor realiza y

produce una entrada al sistema.

Operación del sistema– Es una acción que el sistema ejecuta en

respuesta a una evento del sistema.

Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito y no en el nivel del medio físico de entrada o de elementos de la interfaz.

Eventos y operaciones del sistema (2)

Ejemplo:– Cuando un cajero genera un evento

introducirProducto, causa la ejecución de la operación introducirProducto.

El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo y la operación es la repuesta (lo mismo sucede con los mensajes y los métodos).

Registro de las operaciones de un sistema

Para determinar el conjunto de operaciones requeridas del sistema se identifican sus eventos.

Cuando se utilizan parámetros, las operaciones son las siguientes: – IntroducirProducto(CUP, Cantidad) – TerminarVenta()– EfectuarPago(monto)

Diagrama de Secuencia – Comprar Productos

Identificar eventos del sistema:– Primero debemos determinar los actores

que interactúan directamente con el sistema de software.

– El cliente interactúa con el cajero, pero no directamente con el sistema TPDV; esto sólo lo hace el cajero.

– Por tanto, el cliente no es un generador de eventos del sistema, sólo el cajero lo es.

Diagrama de Secuencia – Comprar Productos Curso normal de los eventos en el caso

Comprar Productos

: Cajero

:Sistema

1: introducir Producto(CUP, cantidad)

2: terminarVenta()

3: efectuarPago(monto)

Sistema como caja negra

Evento del sistemaInicia una operación de sistema

Actor

Diagrama de Secuencia

También mejora la claridad si el nombre de un evento del sistema comienza con un verbo (agregar, introducir, terminar, efectuar), ya que recalca que los eventos están orientados a comandos.

– Así, terminarVenta es preferible a OprimaTeclaEnter porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia respecto a las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.


En cuanto a expresar las operaciones en el nivel de propósito, se debe tratar de alcanzar el nivel más alto o la meta final para asignar nombre a la operación. Por ejemplo, respecto a la operación que captura el pago:– IntroducirImporteOfrecido(monto) – deficiente– IntroducirPago(monto) – mejor– EfectuarPago –mejor aún

a Producta Member

Ordera Member

Ordered Productan Order Processor

a Club Member

display member information

validate item

create item

enter item (product number)

select new order

update address (address)

verify member (member number)



Los diagramas de secuencia se utilizan para modelar la lógica de los escenarios de uso.– Un escenario de uso es la descripción de una

manera potencial en que se utilizará el sistema.

Los diagramas de secuencia modelan de una manera visual el flujo de la lógica dentro de un sistema, permitiendo tanto documentar como validar la lógica subyacente.

Se utilizan tanto para el análisis como para el diseño.


La lógica de un escenario de uso puede describir:

– Un caso de uso; la lógica descrita por el curso normal de los eventos o una porción de éste, más unos o más escenarios alternativos.

– Parte de un caso de uso, quizás un curso alternativo.

– Un conjunto de paso con la lógica contenida en varios casos de uso.

• Por ejemplo, un alumno se inscribe en la universidad y además se inscribe inmediatamente en tres cursos.

Elementos de un Diagrama de Secuencia

Los rectángulos en la parte superior del diagrama representan objetos, clases, actores, o casos de uso.

Objetos y Clases– Dado que es posible enviar mensajes tanto a objetos

como a clases, tiene sentido incluir tanto a objetos como a clases en los diagramas de secuencia.• Los objetos responden a los mensajes a través de

la llamada a una operación.• Las clases lo hacen a través de la llamada a una

operación estática.

Actores– Los actores inician y tienen una participación activa en

los escenarios de uso.


Para los objetos, clases y actores se utilizan etiquetas estándar en el formato UML:

Objetos: “nombre:NombreDeLaClase”– Donde “nombre” es opcional (los objetos a

los que no se les da un nombre en el diagrama se llaman objetos anónimos).

Clases: “NombreDeLaClase”

Actores: “NombreActor”


Ejemplo:

Cliente


Las líneas discontinuas que cuelgan de los rectángulos se llaman líneas de vida del objeto, y representan la vida del objeto durante el escenario que está siendo modelado.

Los rectángulos largos y finos en las líneas de vida son rectángulos de invocación a métodos, e indican que operación se debe ejecutar en el objeto/clase que está recibiendo el mensaje.


La "X" en la parte inferior de un rectángulo de invocación es una convención de UML para indicar que un objeto ha sido eliminado de la memoria, típicamente como resultado de recibir un mensaje con el estereotipo <<destroy>>.

Los mensajes se indican como flechas etiquetadas– Cuando el emisor y el receptor de un mensaje es un

objeto o una clase, la etiqueta corresponde al método que se invocará como respuesta al mensaje.

– Si el emisor o el receptor es un actor humano entonces el mensaje se etiqueta con un texto breve que describe la información que está siendo comunicada.

Diagramas que describen el comportamiento de los objetos

Diagramas de Colaboración– Los diagramas de colaboración son

similares a los diagramas de secuencia, pero no se centran en la sincronización o "secuencia" de mensajes, si no que presentan la interacción (o colaboración) entre los objetos en un formato de red.

Diagrama de Colaboración

El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales.

Un paso esencial en esta fase es la asignación de responsabilidades entre los objetos y mostrar como interactúan a través de mensajes.

El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos.

Diagrama de Colaboración – juego de dados

La figura muestra gráficamente los elementos esenciales del juego, enviando mensajes a las instancias de las clases Jugador y Dado.

:Jugador d1:Dadojugar()

1:r1:= lanzar()

d2:Dado2:r2:= lanzar()

Diagramas de Colaboración y de Secuencia

Los diagramas de colaboración describen las interacciones entre los objetos en un formato de grafo o red:

Los diagramas de secuencia describen las interacciones en una especie de formato de cerca o muro:

Instancia1 : ClaseA Instancia2 : ClaseB

1: mensaje2() 2: mensaje3()mensaje1()

Instancia1 :ClaseA

Instancia2 :ClaseB

mensaje2()

mensaje3()

mensaje1()

Diagramas que describen la implementación de los objetos

Diagramas de Componentes– Los diagramas componentes se utilizan para

representar gráficamente la arquitectura física del sistema. Pueden ser utilizados para demostrar cómo el código de programación se divide en módulos (o componentes).

Client Source Code

Comment

(client.exe)

Drawing Library

Comment

(drawing.dll)dependency

Diagrama de Componentes

Diagramas que describen la implementación de los objetos

Diagramas de Despliegue– Los diagramas del despliegue describen la

arquitectura física del hardware y software en el sistema. Representan las componentes de software, los procesadores, y los dispositivos que forman la arquitectura del sistema.

Application Server - Compaq PIII 500

Client WorkstationHP Kayak XU-400

Database Server - Compaq PIII 500

SAP R/3Comment

Client Source CodeComment

(client.exe)

Oracle 8Comment

TCP/IP

TCP/IP

Diagrama de Despliegue

UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un...

Documents

Transcript of UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un...