nz/ea/as/20011 especificaciones de software nancy zambrano eleonora acosta amelia soriano

NZ/EA/AS/2001 1

Especificaciones de softwareEspecificaciones de software

Nancy ZambranoEleonora AcostaAmelia Soriano

NZ/EA/AS/20012

¿Que significa especificar?¿Que significa especificar?

NZ/EA/AS/20013

Usuario Implementador

Propósito de las especificacionesPropósito de las especificaciones

NZ/EA/AS/20014

Características deseables en la Características deseables en la especificaciónespecificación

Comprensibles No ambíguas Consistentes Completas Incrementables Validables Formales Cualidades

de unaespecificación

NZ/EA/AS/20015

Clasificación de las EspecificacionesClasificación de las Especificaciones

1 Informales: basadas en lenguaje natural

2 Formateadas: basadas en Reglas

3 Semi-formales: basadas en notaciones rigurosas (diagramas ER, diagramas UML)

4 Formales: basadas en formalismos matemáticos (especificaciones algebraicas)

NZ/EA/AS/20016

Especificaciones InformalesEspecificaciones Informales

Una especificación informal se refiere a una descripción en

lenguaje natural

Ejemplo: especificar la operación pop del tipo Stack

pop: {mediante esta operación se elimina el elemento del tope de una pila}

NZ/EA/AS/20017

Especificaciones FormateadasEspecificaciones Formateadas

Una especificación formateada se basa en reglas

Ejemplo: la operación push del tipo Stack

procedure push(mod S:Stack, X: Elem) post: S’= agregar a S el elemento X

NZ/EA/AS/20018

Especificaciones semiformalesEspecificaciones semiformales

Una especificación es semiformal si está escrita en un lenguaje que tiene

una sintaxis precisa

S

S’= S+X

push

X

NZ/EA/AS/20019

Especificaciones FormalesEspecificaciones Formales

Una especificación es formal si está escrita en un lenguaje que tiene una

sintaxis precisa y una semántica fundamentada formalmente.

Ejemplo: la operación pop del tipo Stack

pop: pop(push(x,p)) = p

NZ/EA/AS/2001 10

Lenguaje de Modelación UnificadoLenguaje de Modelación Unificado

UnifiedModelingLanguage

NZ/EA/AS/Abril2001

NZ/EA/AS/200111

UMLUML

Un lenguaje para especificar, visualizar y construir artefactos de sistemas de

software

Artefacto: un modelo o pieza de información

producido en el proceso de desarrollo

de software

NZ/EA/AS/200112

AntecedentesAntecedentes

Proliferación de métodos OO

Diferencias de notaciones A

B

AAB

A

NZ/EA/AS/200113

Puntos de convergenciaPuntos de convergencia

Coincidencias

Unificación de conceptos y notaciones

Búsqueda de estándares

Lenguaje de Modelación

NZ/EA/AS/200114

Lineas de convergenciaLineas de convergencia

BoochRumbaugh-OMT-

Jacobson-OOSE-

UML 0.9 y 0.91Junio y Octubre 1996

1995

1997

UML 1.3Junio 1999

1999

www.rational.com

1996

UML 1.0Enero 1997

Colaboradores:

Digital Equipment Corp, HP, TI, IntelliCorp, Rational Software, Computing, MCI Systemhouse, Microsoft, Oracle, Unisys, IBM, ICON, i-Logix.

1998

NZ/EA/AS/200115

Lenguaje de modelacionLenguaje de modelacion

Para expresar mediante diagramas gráficos diferentes vistas o perspectivas de un sistema en análisis o en desarrollo

sistema

1..* 0..*

Vista estática del sistema

Diagrama de Clases

NZ/EA/AS/200116

Lenguaje de modelacionLenguaje de modelacion

Para expresar mediante diagramas gráficos diferentes vistas o perspectivas de un sistema en análisis o en desarrollo

sistema ConectandoTlf.Disponible

levantar auricular/esperar tono

llamador cuelga/desconectar

Esperando

Hablando

receptor cuelga

receptor responde

Marcando

Sonandohacer/sonar tono

‘ring’

Ocupadohacer/sonar

tono ‘ocupado’

TonoLibrehacer/sonar tono ‘libre’

Timeouthacer/sonar

mensaje

Invalidohacer/sonar

mensaje

Tlf.Activo

# teléfono

15 seg.15 seg.

marcar dígito(n) [incompleto]

marcar dígito(n) [valido] /conectar

ocupado

conectado

receptor contesta/conversación

marcar dígito (n)

marcar dígito (n)

Vista de máquina de estado del sistemaDiagrama de estado

NZ/EA/AS/200117

Las vistas en UMLLas vistas en UML

Estas vistas presentan el sistema desde diferentes perspectivas

Para su descripción, se seleccionan los diagramas más apropiados (depende de la aplicación)

Son válidas para diferentes enfoques (no necesariamente OO)

NZ/EA/AS/200118

ÁreaEstructural

Área Dinámica

Área deGestión del Modelo

máquina de estados, actividad, interacción

gestión del modelo

estática, implementación,casos de uso, despliegue

Área deExtensión de UML

Vistas por Vistas por áreaárea

UnUnaa vistavista es una descripción completa de un es una descripción completa de un sistema desde una perspectiva particular.sistema desde una perspectiva particular.

Vistas y diagramas deVistas y diagramas de UML UML

todas

NZ/EA/AS/200119

ÁreaEstructural

Área Dinámica



gestión del modelo




Una vistaUna vista es una descripción completa de un es una descripción completa de un sistema desde una perspectiva particular.sistema desde una perspectiva particular.


todas

Vista LógicaModela los conceptos

del dominio de la aplicación, internos creados

Componentes principales:CLASES y sus RELACIONES

NZ/EA/AS/200120

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista LógicaModela la funcionalidad del sistema

como lo perciben los usuarios externos

NZ/EA/AS/200121

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista FísicaModela los componentes de un sistema

y sus dependencias

NZ/EA/AS/200122

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista FísicaRepresenta la disposición de

instancias de componentes de ejecución

en instancias de nodos

NZ/EA/AS/200123

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista Lógica que modela los

comportamientos posibles de un objeto de una clase

usando estados

NZ/EA/AS/200124

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista Lógica que muestra las actividades,

su secuenciamiento y coordinación

NZ/EA/AS/200125

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista Lógica que describe secuencias de intercambios

de mensajes entre los roles que implementan el

comportamiento del sistema

NZ/EA/AS/200126

ÁreaEstructural

Área Dinámica



gestión del modelo






todas

Vista Lógica que modela la administración del

modelo del sistema en sí mismo

NZ/EA/AS/200127

Use CaseDiagramsUse Case

DiagramsDiagrama de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagrama de Actividad

ComponentDiagramsComponent

DiagramsDiagrama deComponentes


DiagramsDiagrama de Secuencia


Diagrams Diagrama de Estados

StateDiagramsState

DiagramsDiagrama de Clases

Diagrama de Colaboración

Diagramas

StateDiagramsState

DiagramsDiagrama de Objeto

DiagramasDiagramas


DiagramsDiagrama de Despliegue

NZ/EA/AS/200128



StateDiagramsState


Diagramas

StateDiagramsState


Vista de Casos de Uso

Vista Estática

VistasVistas y Diagramas y Diagramas Área EstructuralÁrea Estructural






Vista de Despliegue

Vista deImplementación

NZ/EA/AS/200129








Diagramas

Vista de Máquina de Estados

Vista de Interacción

Vista de Actividad

VistasVistas y Diagramas y Diagramas Área DinámicaÁrea Dinámica

NZ/EA/AS/200130

StateDiagramsState


Diagramas

Vista de Gestión del Modelo

VistasVistas y Diagramas y Diagramas Área Gestión del ModeloÁrea Gestión del Modelo

NZ/EA/AS/200131









StateDiagramsState



Diagramas

StateDiagramsState


Casos de Uso

EstáticaMáquina de Estados

Interacción

Actividad

VistasVistas y Diagramas y Diagramas Extensión de UMLExtensión de UML

Gestión del Modelo





Vista de Despliegue


NZ/EA/AS/200132

Vistas y DiagramasVistas y Diagramas

Extraído de “El Lenguaje Unificado de Modelado. Manual de Referencia”. Rumbaugh, Jacobson, Booch. Addison Wesley 2000

NZ/EA/AS/200133

Construcciones generalesConstrucciones generales

Iconos

Formas 2D

strings

Caminos (path)

es parte de

La notación UML

NZ/EA/AS/200134

Construcciones generalesConstrucciones generales

Notas

Paquete

Dependencia

Estereotipo

Esto es...

<<interfaz>>

La notación UML

NZ/EA/AS/200135



Diagramas




StateDiagramsState


StateDiagramsState


Estática





Vista de Despliegue


NZ/EA/AS/200136



Diagramas




Vista LógicaModela la funcionalidad

del sistema como lo perciben los

usuarios externos

StateDiagramsState


StateDiagramsState


Estática





Vista de Despliegue


NZ/EA/AS/200137



NZ/EA/AS/200138


Diagramas de Casos de Uso

Representa las funcionalidades

del sistema a partir de las interacciones del usuario

NZ/EA/AS/200139

Diagrama de casos de usoDiagrama de casos de uso

Especifica el comportamiento de un sistema

Describe la secuencia de acciones que dan un resultado observable a un actor

Captura el comportamiento del sistema (el qué) omitiendo la implementación del comportamiento (el cómo)

Identifica las funcionalidades visibles al usuario

NZ/EA/AS/200140



NZ/EA/AS/200141

Diagrama de Casos de Uso: Diagrama de Casos de Uso: ComponentesComponentes

Actor: entidad externa que interactúa con el sistema activando los casos de uso

Caso de uso: secuencia de transacciones iniciadas por un actor y que constituye una funcionalidad del sistema

La notación UML

A

B

ActoresCasos de uso

usuario2

usuario1

NZ/EA/AS/200142

Diagrama de casos de uso: RelacionesDiagrama de casos de uso: Relaciones

Relaciones entre actores y casos de uso:

Relaciones entre casos de uso:

Relaciones entre actores:

Relaciones entre actores y casos de uso Asociación

Relaciones entre casos de uso: Extensión (<<extend>>) Generalización Inclusión (<<include>>)

Relaciones entre actores: Generalización

NZ/EA/AS/200143

Diagrama de casos de uso: Diagrama de casos de uso: Relaciones entre Relaciones entre Actores y CActores y Casos de asos de UUsoso

AsociaciónRelaciona la participaciónde

un actor en

un caso de uso

Ir al cine

Actor

Caso de uso

NZ/EA/AS/200144

Diagrama de Casos de UsoDiagrama de Casos de Uso

En la relación de Asociación puede indicarse la cardinalidad

La notación UML

Ir al cine

ActorCaso de uso

1 *

NZ/EA/AS/200145

Diagrama de Casos de Uso: Diagrama de Casos de Uso: ComponentesComponentes

La notación UML

nombre del caso de uso

número del caso de uso

nombre del sistema

Nombre del actor

Nombre del actor

Participación de un actor en un caso de uso

nombre del caso de uso

número del caso de uso

NZ/EA/AS/200146

Casos de Uso: DescripciónCasos de Uso: DescripciónLa notación UML

Caso de uso: <<número>>

Nombre: <<identificador del caso de uso>>

Actor: << lista de actores>>

Descripción: << Breve descripción>>

Precondición: <<precondición>>

Curso básico:<< Breve descripción curso normal>>

Curso alterno :<< Breve descripción curso excepcional>>

Postcondición: <<postcondición>>

NZ/EA/AS/200147

Diagrama de Diagrama de CCasos de asos de UUso: so: Relaciones entre Relaciones entre CCasos de asos de UUsoso

Extensión (<<extend>>)

Generalización

Inclusión (<<include>>)

Relación que define uncurso alterno opcional(dependiendo de una

condición)de otro caso de uso

NZ/EA/AS/200148

Diagrama de Casos de Uso: Diagrama de Casos de Uso: Relación Relación extendextend

La notación UML

Ir al cine

Comprar cotufa

<<extend>>tengo dinero

Relaciones extend:

el caso de uso Ir al cine puedepuede incluir el comportamiento especificado en el caso de uso Comprar cotufa

NZ/EA/AS/200149

Diagrama de Casos de Uso: Diagrama de Casos de Uso: Relación Relación extend (extension points)extend (extension points)

La notación UML

Comprar cotufa

<<extend>>tengo dinero Extension points:

el caso de uso podrá ejecutarse una vez alcanzado el (los) extension point(s) indicado(s)

Ir al cineExtension points

requerimientos adicionales:despues de entrar al cine

NZ/EA/AS/200150

Diagrama de Casos de Uso: Relación Diagrama de Casos de Uso: Relación extendextend

Es una asociación que describe un curso alterno opcional (la extensión) de otro caso de uso (base).

¿Cuándo usarla? En partes opcionales de un caso de uso Cursos alternativos que raramente ocurren Cursos separados que son ejecutados bajo

ciertas condiciones En situaciones donde se puede seleccionar

una entre diferentes alternativas

La notación UML

NZ/EA/AS/200151

Diagrama de casos de uso: Diagrama de casos de uso: Relaciones entre Relaciones entre CCasos de asos de UUsoso

Extend

Generalización

Include

Relación que define un caso de uso

como una generalización de otro caso de uso

NZ/EA/AS/200152

Relaciones entre Relaciones entre CCasos de asos de UUsoso : : GeneralizaciónGeneralización

Relación Generalización:

el caso de uso divertirse es una generalización del caso de uso ir al cine

La notación UML

Ir alcine

divertirse

NZ/EA/AS/200153

Diagrama de casos de uso: Diagrama de casos de uso: Relaciones entre Relaciones entre CCasos de asos de UUsoso

Extend

Generalización

IncludeRelación que define una instancia de un

caso de uso como un cursoobligatorio en otro

caso de uso

NZ/EA/AS/200154

Relaciones entre Relaciones entre CCasos de asos de UUsoso: : includeinclude

Relación include:

el caso de uso Ir al cine siempresiempre incluye el comportamiento especificado en el caso de uso Comprar entrada

La notación UML

<<include>>Comprar entrada

Comprar cotufa

<<extend>>tengo dinero

Ir al cineExtension points

requerimientos adicionales:despues de entrar al cine

1 *

NZ/EA/AS/200155

Relaciones entre Relaciones entre CCasos de asos de UUsoso: : includeinclude

Es una asociación que relaciona cursos fuertemente acoplados que conforman el curso completo del caso de uso base

¿Cuándo usarla? Para particionar un caso de uso complejo

en los casos de usos constitutivos Cuando se quiere separar una

funcionalidad en un caso de uso

La notación UML

NZ/EA/AS/200156

Relaciones entre Relaciones entre CCasos de asos de UUsoso: : Comparación include/extendComparación include/extend

Diferentes intenciones Include

permite extraer un comportamiento común o aislar funcionalidades

en general los actores no están relacionados con el caso de uso aislado

Extend permite extraer variantes de un curso normal el actor está relacionado con el caso de uso

base

NZ/EA/AS/200157

Relaciones entre Relaciones entre CCasos de asos de UUsoso: : Reacomode e Indique las relacionesReacomode e Indique las relaciones

responder

exámen

ir al baño

colocar identificación

al exámen

pediraclaratoria

solicitar

exámen

Realizar la Prueba

leer

exámen

entregar

exámen

estudianteUtilizar

calculadora

buscar Calificación

NZ/EA/AS/200158

Relaciones entre Relaciones entre CCasos de asos de UUsoso: : Reacomode e Indique las relacionesReacomode e Indique las relaciones

responder

exámen

ir al baño

colocar identificación

al exámen

pediraclaratoria

solicitar

exámen

Realizar la Prueba

leer

exámen

entregar

exámen estudiante

Utilizar

calculadora

Buscar Calificación

<<include>><<include>>

<<include>>

<<include>>

<<include>>

<<extend>>

<<extend>><<extend>>

NZ/EA/AS/200159

Diagrama de casos de uso: Diagrama de casos de uso: Relaciones entre actoresRelaciones entre actores

Generalización

Un actor es una instancia de otro actor

NZ/EA/AS/200160

Relaciones entre actoresRelaciones entre actores: Generalización: Generalización

estudiantepersona

Relación de Generalización:

una persona es una generalización de un estudiante

NZ/EA/AS/200161



Diagramas




Vista Lógica en la que se identifican

clases, objetos e interrelaciones

entre ellos

StateDiagramsState


StateDiagramsState


Estática





Vista de Despliegue


NZ/EA/AS/200162



NZ/EA/AS/200163

Describe la estructura estática del modelo del sistema, en particular, las clases, tipos, interfaces y objetos, su estructura interna y las relaciones entre ellos.

Diagrama de clasesDiagrama de clasesLa notación UML

Item

Icon Container

NZ/EA/AS/200164

ClaseClase

Descriptor de un conjunto de objetos con estructura similar, mismo comportamiento y relaciones

Representa un concepto en el systema que se modela

La notación UML

Rectángulo

p1: Punto p2: Punto

<<constructor>> Rectángulo(p1:p2Punto) <<query>> área( ): Real aspecto( ): Real (...) <<update>> mover (delta:Punto) escala (radio: Real)

Rectángulo

nombre

atributos

métodos

NZ/EA/AS/200165

ObjetoObjeto

Entidad con identidad única que encapsula estado y comportamiento

La notación UML

triángulo: Polígono

centro = (0,0) vértices = ((0,0),(4,0),(4,3)) color-borde = negro color-relleno = blanco

triángulo

:Polígono


NZ/EA/AS/200166

Identifique todos los elementosIdentifique todos los elementosLa notación UML

Polígono

centro: Punto vértices: Conj-Punto color-borde = Color color-relleno = Color

........ <<constructor>> Polígono(p1,p2,p3:Punto) <<query>> área( ): Real aspecto( ): Real (...) <<update>> mover (delta:Punto) escala (radio: Real)


centro = (0,0) vértices = ((0,0),(4,0),(4,3)) color-borde = negro color-relleno = blanco

NZ/EA/AS/200167

Clase: EstereotiposClase: Estereotipos

La notación UML

Un símbolo de clase puede contener o no un estereotipo.

Estereotipos:

<<type>><<implementationClass>><<interface>><<utility>>

<<type>>Tipo de dato

<<implementationClass>>Imp. tipo de dato

<<interface>>Int. tipo de dato

Clase

<<utility>>Funciones

NZ/EA/AS/200168

Type e ImplementationClassType e ImplementationClass

<<type>>Tipo de dato

Un type provee una especificación del comportamiento visible de una clase

Una implementationClass provee la

realización concreta de un

tipo

La notación UML

<<implementationClass>>Itd

Relación de Realización.

NZ/EA/AS/200169

• un type permite especificar los objetos abstractos y el comportamiento de las operaciones externas

Type, ImplementationClass y Type, ImplementationClass y Relación de RealizaciónRelación de Realización

La notación UML

• una implementationClass es un descriptor de objetos con estados concretos y métodos.

• una relación de Realización implica que la implementationClass provee al menos todas las operaciones del Type.

NZ/EA/AS/200170

una interface permite especificar las operaciones visibles externamente de una clase, componente, subsistema, etc. sin indicar la estructura interna

InterfacesInterfaces

La notación UML

<<interface>>Comparable

esIgual(String): BooleanHash():Integer

NZ/EA/AS/200171

Clases ParametrizadasClases ParametrizadasLa notación UML

atributos

métodos

...

...

nombre

parámetros

Es un descriptor para una clase con uno o más parámetros formales no acotados.

Define una familia de clases, cada una de las cuales viene dada por la asociación de valores actuales a los parámetros

NZ/EA/AS/200172


atributos

métodos

...

...

nombre

parámetros

Forma de los parámetros:

nombre: tipo = valor por defecto

nombre

NZ/EA/AS/200173


Rectángulo

p1: Punto p2: Punto

<<constructor>> Rectángulo(p1:p2Punto) <<query>> área( ): Real aspecto( ): Real (...) <<update>> mover (delta:Punto) escala (radio: Real)

nombre

atributos

métodos

parámetros

Punto

Rectángulo <CoorPolares> RectánguloCC

<<bind>> (CoorCartesianas)

NZ/EA/AS/200174

UtilitariosUtilitariosLa notación UML

<<utility>>Math

Seno(Ángulo): RealCoseno(Ángulo): RealRaiz2(Real): RealAleatorio():Real

Agrupa variables globales y procedimientos en forma de una declaración de clase.

Los atributos y operacionesde un utility se interpretan como atributos globales y operaciones.

NZ/EA/AS/200175

RelacionesRelaciones

Conexión semántica entre elementos del modelo asociación

binaria agregación composición

generalización dependencia

La notación UML

NZ/EA/AS/200176

Asociaciones binariasAsociaciones binarias

Conexión semántica bidireccional entre elementos, con un nombre (nombre de la relación vinculada al comportamiento específico) y un rol (nombre del extremo de una asociación)

La notación UML

dirige

jefe

*

0..1Compañía Persona

1 1..*emplea

Trabaja para

empleado

NZ/EA/AS/200177

RolesRoles

Una asociación tiene roles

El Rol tiene dirección en la asociación

El Rol es explicitamente etiquetado

Adapado de Univ. Calgary

Pedido

Fecha¿Es prepagado?Número Costo

despacho( )

1

*

CantidadPrecio¿Satisfecho?

Pedido de producto

Línea de producto

NZ/EA/AS/200178

MultiplicidadMultiplicidad

Indica cuántos objetos pueden participar en la relación

Pedido

Fecha¿Es prepagado?Número Precio

despacho( )

Clientenombredirección

credito( )

1*

Adaptado de Univ. Calgary

NZ/EA/AS/200179

Nombre del rolNombre del rol

Rol = identifica el extremo de la asociación

El nombre del rol es obligatorio para asociaciones entre objetos de la misma clase

NombreDirección

CompañíaTrabaja para

NombreCédula de IdentidadDirección

Persona

empresa empleado

NombreCédula de IdentidadDirección

PersonaGerente de Ventas

Supervisa Vendedor

Adapado de Univ. Calgary

NZ/EA/AS/200180

Sumario: notación básica para Sumario: notación básica para asociacionesasociaciones

Clase B Clase BNombre de la Asociación

rol_Arol_B

Pedido ItemContiene

Incluído enConstituído de


Ejemplo:

NZ/EA/AS/200181

Clase AsociaciónClase Asociación

Se utiliza cuando los atributos no pertenecen a las clases sino a la asociación

PrioridadDerechos de Acceso

UsuarioAutorizado en

Estación de Trabajo

Autorización

Inicio de sesión

Directorio

Tomado de Univ. Calgary

NZ/EA/AS/200182

Composición / agregaciónComposición / agregación(todo/partes)(todo/partes)

Gráficocolor

textura

1

1

Composición

Polígono Punto

13..*

Agregación

La notación UML

NZ/EA/AS/200183

Composición: diferentes formas de Composición: diferentes formas de expresarlaexpresarla

La notación UML

Slider

Scrollbar 2

1

Window

Panel

Header

body 1

1

title 1

1

Window

scrollbar[2]:Slidertitle: Headerbody: Panel

Window

scrollbar:Slider

title: Header

body: Panel

2

1

1

NZ/EA/AS/200184

Asociación n-ariaAsociación n-aria

Vuelo Asiento

Persona

asientovuelo

pasajero

reservación

La notación UML

NZ/EA/AS/200185

GeneralizaciónGeneralización

Relación entre un elemento más general y un elemento más específico

Especifica una relación de herencia

Una superclase se define a través de una relación de generalización

La notación UML

NZ/EA/AS/200186

HerenciaHerencia

Una clase B hereda de una clase A si adquiere las propiedades (estructura y comportamiento) definidas en la clase A

A es una superclase de la clase B

B es una subclase de la clase A

A

B

<<hereda>>

La notación UML

NZ/EA/AS/200187

EspecializaciónEspecialización

Dada una clase, se crea otra clase (subclase) que especializa la clase dada, agregando las diferencias (adición, supresión o redefinición de propiedades)

Vehículo

Carro MotoGrúa

La notación UML

NZ/EA/AS/200188

GeneralizaciónGeneralización

Se crea una clase (superclase), que generaliza las propiedades comunes de varias clases

Carro MotoGrúa

Vehículo

La notación UML

NZ/EA/AS/200189

Vehículo

VehículoPropulsiónViento

VehículoPropulsiónMotor

Vehículoterrestre

VehículoAcuático

Velero

Herencia múltipleHerencia múltipleLa notación UML

NZ/EA/AS/200190

Dependencias entre clasesDependencias entre clases

Relación unidireccional semántica entre 2 (o más) elementos del modelo y existe cuándo cambios en la definición de un elemento causa cambios en el otro

<<fuente>> <<destino>>

Indica que un cambio en el fuente requiere un cambio en el destino

La notación UML

NZ/EA/AS/200191

Dependencias entre clasesDependencias entre clases

Clase B ClaseD

OperaciónZ( )

Clase A

ClaseC<<usa>>

<<instancia>>

La notación UML

<<importa>>

<<refina>>

Meta: minimizar dependencias

NZ/EA/AS/200192

Diagrama de ClasesDiagrama de Clases

Elementos del modelo

Vistas del modelo

Diagrama Proyección+placement:ListOfPoint+ style: Uninterpreted

1..* 0..*

proyección

Diagrama de Estado

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Actividad

Diagrama de Objetos

(…)

La notación UML

NZ/EA/AS/200193

Presenta una imagen del sistema en un instante de tiempo (un ejemplo del sistema).

Recuerde que los ejemplos de sistemas, no son definiciones de sistemas.

Diagrama de objetosDiagrama de objetosLa notación UML

NZ/EA/AS/200194

Diagrama de objetosDiagrama de objetosLa notación UML


punto 1: Punto

x = 0.0y= 1.0

punto 2: Punto

x = 3.0y= 1.0

punto 3: Punto

x = 3.0y= 5.0

Polígono Punto

13..*

es posible obtener el diagrama de objetos correspondiente al objeto triángulo

A partir de la definición, por agregación, de la Clase Polígono,

NZ/EA/AS/200195





Diagramas




Vista de Despliegue



Vista FísicaModela los componentes

de un sistemay sus dependencias


StateDiagramsState


StateDiagramsState


Estática

NZ/EA/AS/200196



NZ/EA/AS/200197

Diagrama de Diagrama de ComponentesComponentes

Nombre del componente

Componente

dependencia de utilización

dependencia de realización


Componente con interfaces

nombre de la interfaz


Componente estereotipado


<<estereotipo>>Nombre del componente

NZ/EA/AS/200198





Diagramas




Vista de Despliegue



Vista FísicaRepresenta la disposición

de instancias de componentes de ejecución

en instancias de nodos


StateDiagramsState


StateDiagramsState


Estática

NZ/EA/AS/200199



NZ/EA/AS/2001100

Diagrama Diagrama de Desplieguede Despliegue

• Nivel de Descriptor

Nombre del nodo


#

multiplicidad

nodo

Asociación de comunicación

Nombre del nodo

Nombre

#

Nombre

dependencia

NZ/EA/AS/2001101

Diagrama Diagrama de Desplieguede Despliegue

• Nivel de Instancia

nombre de la instancia: Tipo del nodo

instancia de nodo

enlace de comunicación

nombre de la instancia: Nombre del nodo

NZ/EA/AS/2001102








Diagramas



Vista de Actividad


Vista Lógica modela la evolución o

comportamiento posibles de un objeto.

(los cambios de estado del objeto en su tiempo

de vida)

NZ/EA/AS/2001103



NZ/EA/AS/2001104

Diagrama de EstadoDiagrama de Estado

Muestra el comportamiento de un objeto: cómo cambia su estado en respuesta a los mensajes que recibe

Antecedentes:

Diagramas de Transición de estados Diagramas de Harel

La notación UML

NZ/EA/AS/2001105


Estado: condición/situación durante el tiempo de vida de un objeto

Transición de estado: relación que indica un cambio de estado

Evento: genera una transición de estado atómico y no-interrumpible

Accion: atómica y no-interrumpible

parado

arrancado

apagar motor

Adaptado de la Univ. Calgary

Arranca[gasolina disponible]/conectar

no mas gasolina

NZ/EA/AS/2001106

Notación del EstadoNotación del Estado

Acciones Entry/Exit entry: una acción que es ejecutada en la

entrada al estado exit: una acción que es ejecutada en la

salida del estado

do: una actividad que se está ejecutando mientras permanece en un estado interrumpible

on: una acción que se ejecuta como resultado de un evento específico


Nombre del Estado

Variable(s) del Estado

entry: acción de entradado: actividadon: evento-A:acción-Aexit: acción de salida

NZ/EA/AS/2001107

estado-A estado-BEvento(argumentos)[condicion]/accion

Transición de estadosTransición de estados


Evento:

ocurrencia significativa que tiene una localización en el tiempo y el espacio

disparan (triggers) la transición (señales, llamadas, límites de tiempo, cambio en estado)

Condiciones de Guarda:

se evalúan para determinar la transición Cuando el guardia evalúa a verdad, una sola transición es elegible Guardias de transición a la salida de un estado son mutuamente

exclusivos

Acción: cómputo atómico ejecutable

NZ/EA/AS/2001108

Notacion de diagramas de estadoNotacion de diagramas de estado

Inicio eventos triggers no son permitidos son permitidas condiciones de bifurcación no puede permanecer en el estado inicial

Fin el fin de estado del nivel del tope termina

una máquina de estado

Estado inicial estado-BEvento(atributo)


NZ/EA/AS/2001109

RecomendacionesRecomendaciones

No se requiere un diagrama de estado para cada clase

Los diagramas de estado no deben ser muy complejos

Los diagramas de estado son a menudo usados para describir interfaces de usuario y objetos control

NZ/EA/AS/2001110


llamador cuelga/desconectar

Conectando

marcar dígito(n) [valido] /conectar

15 seg. Timeouthacer/sonar

mensaje

Tlf.Disponible

levantar auricular/esperar tono

Tlf.Activo

# teléfono

15 seg.

Hablandoreceptor contesta/conversación

marcar dígito(n) [incompleto]

Esperando

receptor cuelga

receptor responde

TonoLibrehacer/sonar tono ‘libre’

conectado

Sonandohacer/sonar tono

‘ring’

Invalidohacer/sonar

mensaje

marcar dígito (n)

Ocupadohacer/sonar

tono ‘ocupado’

ocupado

La notación UML

Marcandomarcar dígito (n)

NZ/EA/AS/2001111








Diagramas



Vista de Actividad


Vista Lógica muestra las actividades,

su secuenciamiento y coordinación.

Describe el flujo detrabajo

NZ/EA/AS/2001112



NZ/EA/AS/2001113

Diagramas de ActividadDiagramas de Actividad

• Describe el aspecto dinámico de un trabajo

• Describe • procesamiento

paralelo• workflows

• Muestra el flujo de actividad en actividad


A ctiv ity

A ctiv ity A ctiv ity

A ctiv ity

A ctiv ity

[condition 1]

[condition 2]

[synchronization condition]

Actividad Actividad

Actividad Actividad

Actividad

[condición 1]

[condición 2]

[condición de sincronización]

NZ/EA/AS/2001114

Diagrama de Actividad- EjemploDiagrama de Actividad- Ejemplo


Inicio

Colocar café en el filtro Colocar agua en

el depósito

Poner el filtro en la máquina

Prender la máquina

NZ/EA/AS/2001115

Diagrama de ActividadDiagrama de Actividad

Buscar Bebida

Prender la maquina

[no hay café]

Abrir refresco

[refresco encontrado]

[no hay refresco]

La notación UML

Colocar filtro en la maquina

BeberServir café

LuzOut

PrepararCafe

^Cafetera.On

Colocar café en filtro

Colocar agua en el depósito

Buscar taza

[café encontrado]

NZ/EA/AS/2001116








Diagramas



Vista de Actividad


Vista Lógica describe seuencias de intercambios

de mensajes entre los roles que implementan el

comportamiento del sistema

NZ/EA/AS/2001117








Diagramas



Vista de Actividad


Un Diagrama de Secuenciadescribe la interación

entre los objetos ordenadaen el tiempo

NZ/EA/AS/2001118



NZ/EA/AS/2001119

Diagrama de SecuenciaDiagrama de Secuencia

Muestra los objetos que participan en una interacción

el intercambio de mensajes

su ordenamiento en el tiempo

Captura el comportamiento dinámico

Describe todos los escenarios (forma genérica) o un escenario particular (una instancia)

NZ/EA/AS/2001120

Diagrama de SecuenciaDiagrama de SecuenciaLa notación UML

ob1:C1 ob2 :C1ob3Actor:

operacionevento

op(parámetros)

op(parámetros)

op(parámetros)

Línea de vida

Mensaje

Activación

NZ/EA/AS/2001121

Diagrama de SecuenciaDiagrama de Secuencia

ob1:C1

ob3:C3 ob4:C4

ob2:C2

La notación UML

op( )

[x>0] op1(x )

[x<0] op2(x )

op3(w ) op3(z )

op4( )

recursión

condicional

destrucción

creación

NZ/EA/AS/2001122

Diagrama de SecuenciaDiagrama de SecuenciaLa notación UML

receptorLíneatelefónica

Llamador

enrutar

Levantar auricularActiva tono

Marcar números

Tono de “ring”

parar tono

Suena el teléfono

Responde el teléfono

Para el “ring”conversación

a

b

c

d

d’

{b-a< 1seg)

{c-b< 1seg)

{d’- d < 1seg)

NZ/EA/AS/2001123

Diagrama de Secuencia- EjemploDiagrama de Secuencia- Ejemplo


course form :CourseForm

theManager :CurriculumManager

aCourse :Course: Registrar

1 : set course info

2 : process3 : add course

4 : new course

NZ/EA/AS/2001124

Utilidad de los diagramas de secuenciaUtilidad de los diagramas de secuencia

Maneja la comunicación entre el sistema y el mundo exterior captura requerimientos de la interfaz de

usuario no muestra como la interfaz será

implementada

Son un medio para clarificar escenarios

NZ/EA/AS/2001125








Diagramas



Vista de Actividad


Un Diagrama de Colaboracióndescribe la interación

entre los objetos, numerando

la secuencia de mensajes

NZ/EA/AS/2001126



NZ/EA/AS/2001127

Los diagramas de secuencia y de colaboración:

- son diagramas de interacción

- utilizan la misma información

(objetos y las relaciones existentes entre ellos)

- enfatizan diferentes aspectos y son mostrados de diferente manera

Diagrama de ColaboraciónDiagrama de Colaboración

NZ/EA/AS/2001128

Diagramas de interacciónDiagramas de interacciónLa notación UML

ob1:C1 ob2 :C1ob3Actor:

operaciónevento

op(parámetros)

op(parámetros)

op(parámetros)

Diagrama de Secuencia

ob1:C1 ob2

:C1ob3

Actor:

2. operación1. evento

5. op(parámetros)

4. op(parámetro)

3. op(parámetros)


NZ/EA/AS/2001129

Diagramas de InteracciónDiagramas de Interacción

course form :CourseForm

theManager :CurriculumManager

aCourse :Course: Registrar

1 : set course info

2 : process3 : add course

4 : new course

Secuencia

: Registrar

course form : CourseForm

theManager : CurriculumManager

aCourse : Course

4 : new course

3 : add course

1 : set course info2 : process

Colaboración

NZ/EA/AS/2001130

Diagramas de ColaboraciónDiagramas de Colaboración

descripción de la estructura estática - objetos y relaciones - (Contexto de la colaboración)

descripción de la secuencia de mensajes intercambiados entre los objetos para cumplir una tarea (interacciones de la colaboración)

Describe comportamiento estático

Describe comportamiento dinámico

NZ/EA/AS/2001131

Diagrama de ColaboraciónDiagrama de Colaboración

Colaboración parametrizada (construcción de diseño que puede ser

usada en diferentes aplicaciones)

PATRONES DE DISEÑO

NZ/EA/AS/2001132

StateDiagramsState


Diagramas

Vista de Gestión del Modelo

VistasVistas y Diagramas y Diagramas Área Gestión del ModeloÁrea Gestión del Modelo

Vista Lógica que modela la administración del

modelo en sí mismo

NZ/EA/AS/2001133



NZ/EA/AS/2001134

Administración del modeloAdministración del modelo

Paquetes

Subsistemas

ModeloLos paquetes permiten agrupar elementos del

modelo

NZ/EA/AS/2001135


Paquetes

Subsistemas

Modelo

Un subsistema representa una unidad de comportamiento

en el sistema físico

NZ/EA/AS/2001136


Paquetes

Subsistemas

Modelo

Un modelo es una abstraccióndel sistema físico.

Describe el sistema desde un punto de vista y a un

cierto nivel de abstracción

NZ/EA/AS/2001137


Paquetes

Subsistemas

ModeloLos paquetes permiten agrupar elementos del

modelo

NZ/EA/AS/2001138

PPaqueteaquetessEl paquete es una agrupación de elementos del modeloUn paquete puede: - estar incluído dentro de otro paquete, - contener otra clase de elementos del modelo.

Los paquetes tienen elementos propios y son la base para - el control de la configuración, - el almacenamiento - el control de acceso.

Cada elemento pertenece a un único paquete.

NZ/EA/AS/2001139

PaquetePaquetes: Notacións: Notación

Nombre

contenido

Nombre

NZ/EA/AS/2001140

PaquetePaquetes: Notacións: Notación

Controlador

Editor

Elementos del Dominio

Elementos del Diagrama

NZ/EA/AS/2001141

Relaciones entre pRelaciones entre paqueteaquetess

Los paquetes pueden hacer referencia a otros paquetes mediante el uso de uno de los estereotipos: <<import>> y <<access>>

MotifCore Motif<<import>>

NZ/EA/AS/2001142

Visibilidad de elementos del pVisibilidad de elementos del paqueteaquete

La visibilidad de los elementos del paquete fuera de éste se indica precediendo un símbolo al nombre del elemento: + para todo público - privado # protegido

+ Nombre

NZ/EA/AS/2001143

PaquetesPaquetes

Encapsulación

Mostrar dependencias entre paquetes

Meta del diseño a gran escala: minimizar dependencias facilita anticipación al cambio

Fuente: Univ. Calgary

NZ/EA/AS/2001144


Dar a las clases del paquetes sólo visibilidad en el paquete

Definir una clase pública que provea el comportamiento público del paquete

Delegar las operaciones públicas a las clases apropiadas del paquete


NZ/EA/AS/2001145


Tratar de evitar ciclos en la estructura de dependencias

Si hay muchas dependencias analizar la modularización del sistema

Construir un diagrama de paquetes cuando el diagrama de clases del sistema no sea legible en una página


NZ/EA/AS/2001146


Paquetes

Subsistemas

Modelo

Un subsistema representa una unidad de comportamiento

en el sistema físico

NZ/EA/AS/2001147

SubsistemasSubsistemas

Un subsistema ofrece interfaces y tiene operaciones. Su contenido puede separarse en: - elementos de especificación - elementos de implementación.

La especificación de un subsistema está compuesta por operaciones en el subsistema, así como elementos tales como diagramas de casos de uso, de estado, ...

NZ/EA/AS/2001148


Nombre

Elementos de Especificación

Elementos de Implementación

Nombre

Oper1(...): Tipo1

use case 1

Relación de implementación

NZ/EA/AS/2001149


SS1

SS2 SS3

NZ/EA/AS/2001150


Paquetes

Subsistemas

Modelo

Un modelo es una abstraccióndel sistema físico.

Describe el sistema desde un punto de vista y a un

cierto nivel de abstracción

NZ/EA/AS/2001151

ModeloModelo

Es una abstracción de un sistema físico

Presenta el sistema físico a un cierto nivel de abstracción y desde un punto de vista específico

Los elementos de un modelo se organizan en una jerarquía de paquetes / subsistemas

NZ/EA/AS/2001152

ModeloModelo

Nombre

contenido

Nombre

NZ/EA/AS/2001153

ModeloModelo

Diseño

System Model

Análisis

NZ/EA/AS/2001154

Modelos y SubsistemasModelos y Subsistemas

SS1

SS2 SS3

NZ/EA/AS/2001155

Modelos y SubsistemasModelos y Subsistemas

SS1

SS2 SS3

NZ/EA/AS/2001156

VistasVistas y Diagramas y Diagramas Área Extensión de UMLÁrea Extensión de UML









StateDiagramsState



Diagramas

StateDiagramsState


Casos de Uso

EstáticaMáquina de Estados

Interacción

Actividad

Gestión del Modelo





Vista de Despliegue


NZ/EA/AS/2001157


Construcciones Principales:

Restricciones Estereotipos Valores etiquetados

NZ/EA/AS/2001158




Declaración textual de una

relación semántica

NZ/EA/AS/2001159




Nueva clase de elemento del modelo, ideada por el analista y

basada en un tipo de elemento del modelo

NZ/EA/AS/2001160




Porción de información con nombre, Unida a cualquier elemento del modelo

NZ/EA/AS/2001 161

Especificaciones formalesEspecificaciones formales

Especificaciones algebraicas

Próxima clase

nz/ea/as/20011 especificaciones de software nancy zambrano eleonora acosta amelia soriano

Documents

diagramas grficos

diagramas umlformales

operacin pop

lenguaje naturalformateadas

lenguaje naturalejemplo

descripcin completa

diagramas ms apropiados

operacin push