tema 1: introducción a la ingeniería del softwareis... · incluye conceptos semánticos,...

Ingeniería del Software de Gestión www.kybele.es

Tema 4b:Introducción a UML

Marcos López SanzIngeniería del Software de Gestión


Índice

Introducción a UML

Generalidades y evolución histórica

Mecanismos de extensión

Vistas y diagramas

Ciclo de vida en el PUD


UML

Unified Modeling Language (Lenguaje unificado de modelado)

Mitos sobre UML

UML es un lenguaje de programación

Aprender UML es aprender el paradigma de objetos.

UML es una metodología de desarrollo.

UML es solo para modelos de objetos

http://www.uml.org/


Características Generales

Lenguaje

Características generales: Incluye conceptos semánticos, notación y reglas de creación

de diferentes tipos de diagramas

Permite capturar información acerca de la estructura estática y el comportamiento dinámico de un sistema

Lenguaje de modelado visual de propósito general usado para: Especificar Modelos precisos, no ambiguos, completos Visualizar Representar y comunicar ideas Construir Trasladar a un lenguaje de programación Documentar Los artefactos construidos durante un proyecto de

desarrollo de un sistema software


Características Generales

Unificado

Lenguaje = sintaxis + semántica

Unificado a través de:

Métodos y notaciones históricas integradas

Usado en múltiples etapas del ciclo de desarrollo (de requerimientos a implementación)

Gran diversidad de dominios de aplicación

Amplia variedad de lenguajes y plataformas de implementación representables

Aplicable en diferentes procesos de desarrollo


Características GeneralesModelado

¿Qué es un modelo? Una abstracción que representa algún aspecto de la realidad Una representación en algún medio que captura los aspectos

importantes del sistema modelado desde un determinado punto de vista

Un modelo de un sistema software es realizado en un lenguaje de modelado

Propósito de los modelos Capturar y precisar requerimientos de un dominio de

conocimiento, que sea comprensible por todos los stakeholdersdel proyecto.

Pensar sobre un diseño de un sistema. Capturar decisiones de diseño de un sistema. Explorar posibles soluciones a un problema económicamente. Generar productos de trabajo útiles. Documentar.

E = M * C2


Breve evolución histórica

Evolución: Oct. 1994: G. Booch y J. Rumbaugh se unen en Rational. Intentan unificar

OMT (Object Modeling Tool) y Booch (método) Oct. 1995: I. Jacobson se une a Rational Unified Method v0.8 Nov. 1997: OMG (Object Management Group) aprueba UML (v1.1) 2003: versión 1.5 de UML Oct. 2004: versión 2.0 de UML 2005: convertido en estándar

ISO/IEC 19501:2005 Information technology — Open Distributed Processing —Unified Modeling Language (UML) Version 1.4.2.

Cambios entre versiones: Refinamiento y extensión de modelos Ampliación de semántica Cambio en las restricciones de uso de elementos en modelos

http://es.wikipedia.org/wiki/IEC


Breve evolución histórica


Influencias


Participantes en UML 1.0

Rational Software

Grady Booch, Jim Rumbaugh y IvarJacobson

Digital Equipment

Hewlett-Packard

i-Logix

David Harel

IBM

ICON Computing

Desmond D’Souza

Intellicorp and James Martin & co.

James Odell

MCI Systemhouse

Microsoft

ObjecTime

Oracle Corp.

Platinium Technology

Sterling Software

Taskon

Texas Instruments

Unisys


Vistas de UML

¿Qué es una vista? Una vista es un subconjunto de construcciones de modelado

que se enfocan en un aspecto particular del sistema

Proyección del sistema completo en un modelo

Cada vista cuenta con uno o más diagramas representativos

Las vistas pueden agruparse en tres áreas: Estructural

Comportamiento dinámico

Gestión del modelo


Describe los elementos del sistema (clasificadores) y sus relaciones Clasificadores más comunes:

Clases Casos de Uso Componentes Nodos

Vistas y diagramas asociados: Vista Estática

Diagrama de clases Diagrama de objetos

Vista de Casos de uso Diagrama de casos de uso

Vista de Implementación Diagrama de componentes Diagrama de despliegue

Vistas de UMLClasificación estructural


Vistas de UMLComportamiento dinámico

Describe el comportamiento del sistema a través del tiempo

Vistas y diagramas asociados: Vista de Interacción: modela como interactúan los objetos

para realizar una funcionalidad del sistema Diagrama de colaboración

Diagrama de secuencia

Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de transición de estados

Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades


Vistas de UMLGestión del modelo

Describe la organización de los modelos en unidades jerárquicas

Permite manejar la complejidad mediante la identificación de agrupaciones de clasificadores

Elementos utilizados:Paquetes

Subsistemas

Modelos



Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos:

Extienden la semántica del elemento sobre el que se aplica Permite representar una variación de un elemento existente que posee otra

intención, o distinción de uso Puede indicarse textualmente (entre << y >>) o gráficamente

Valores etiquetados Extiende las propiedades de un elemento de UML, permitiendo añadir nueva

información en la especificación del elemento Cadenas con el nombre de la etiqueta, un signo igual y un valor

Restricciones Notación matemática formal OCL Lenguaje de programación o pseudocódigo



Ejemplo


Áreas, vistas y diagramas



Otra clasificación (UML 1.5) Diagramas estáticos (o estructurales *)

Diagramas de clases

Diagramas de objetos

Diagramas de componentes

Diagramas de despliegue

Diagramas dinámicos (o de comportamiento)

Diagramas de casos de uso*

Diagramas de secuencia

Diagramas de colaboración

Diagramas de estados

Diagramas de actividades



Otra clasificación (UML 2.0)


Vista estática

Propósito:

Capturar la estructura del sistema en base a elementos (clasificadores) que lo definen

Es la base sobre la que se construyen las otras vistas

Diagramas:

Diagrama de Clases

Diagrama de Objetos


Vista estáticaElementos

Clasificador es un concepto discreto en el modelo que tiene identidad, estado,

comportamiento, y relaciones

Tipos de Clasificadores Elementos del Sistema:

Clase Interfaz Tipos de datos

Conceptos de Comportamiento: Caso de Uso

Cosas del entorno: Actor

Estructuras de implementación: Componente Nodo Subsistema


Vista estáticaElementos

Clase Conjunto de objetos con estructura, comportamiento, relaciones, y

semántica común.

Objeto = estructura + operaciones + estado interno + identidad Un objeto es una instancia de una clase.

Ejemplos algo físico → Avión algo del negocio → Pedido un concepto lógico → Horario algo de la aplicación → Window, Botón, Menú algo del comportamiento → Tarea, Proceso


Diagrama de clases

El diagrama de clases representa la vista estática de un sistema software

Los elementos que aparecen en este diagrama son aquellos conceptos que tienen significado dentro de una aplicación

Elementos principales de este diagrama: Clasificadores: elementos que describen cosas Relaciones entre clasificadores

La definición de cada concepto del mundo real se identifica con una clase de este diagrama


Diagrama de clases:Clase

Clase: se representa en un rectángulo con tres compartimientos

nombre de la clase

atributos de la clase

operaciones de la clase

#Patrullar()

-Entrenar()

+MostrarCondecoraciones()

-Num_Placa : int

-Nombre

-Apellidos

+Apodo

-AñosServicio : int = 0

-Condecoraciones

-Puntería

-Experiencia

Policia Nombre de la clase

Atributos

Operaciones

Tipos de los atributos

Valor inicial

{<10} Restricción sobre el valor


Diagrama de clases:Visibilidad

Determina el nivel de encapsulamiento de los elementos de una clase (-) Privado: Los atributos/operaciones son visibles solo desde la propia

clase.

(#) Los atributos/operaciones protegidos están visibles para la propia clase y para las clases derivadas de la original

(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio deencapsulación)

Visibilidad+ público# protegido- privado


Diagrama de clases:Relaciones entre clasificadores

Las posibles relaciones entre clasificadores son: Asociación (conocimiento)

Agregación / Composición

Generalización

Dependencia

Realización

Enlace: Instancia de una asociación

Lista ordenada de referencias a objetos


Diagrama de clases:Relaciones entre clases

Asociación:

Conexión semántica entre instancias de clases

Proporciona una conexión para el envio de mensajes

#Patrullar()

-Entrenar()


-Num_Placa : int

+Apodo

-Puntería

-Experiencia

Policia

#Robar()

-Escapar()

+MostrarHistorial()

-IDLadron : int

+Apodo

-Tipo : int = 0

-Encarcelaciones

-Puntería

Ladrón

-perseguidor

1..*

-delincuente

1..*

Persigue4

Multiplicidad

Multiplicidad0..1 N..M0..* 3..*1..* 2..51 3..4, 6..**

Nombre de la relación

Dirección de lectura de la relación

Navegabilidad (uni/bi-direccional)roles


Diagrama de clases: Asociación: casos especiales

Asociación como clase (clase de asociación)

Asociación calificada

Asociación ordenada

Restricción

Teatro Obra

-Fecha

-Hora

Presentacion

* *

Presentacion EntradaNum_Butaca

1 1..*

Presentacion Diapositiva

1

{ordered}

1..*

CuentaPersona

1

*

or

Empresa

*

*


Diagrama de clases:

Relaciones entre clases

Agregación: relación entre un todo y sus partes

Lógica: la parte puede pertenecer a varios agregados

Física (o composición): las partes sólo existen asociadas al compuesto (acceso a través de él)

Universidad Estudiante1..* 1..*

Universidad Departamento1 1..*


Diagrama de clases:


Consideraciones sobre la composiciónUna composición es una forma de asociación más fuerte

en la cual el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación

La composición implica tres cosas: Dependencia existencial. El elemento dependiente

desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo

Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene

Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto


Dependencia: Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia

Diagrama de clases:


#Robar()

-Escapar()

+MostrarHistorial()

-IDLadron : int

+Apodo

-Tipo : int = 0

-Encarcelaciones

-Puntería

Ladrón

+usar()

+aprenderUso()

-material

-fuerza

Herramienta«uses»

Mecanismos de extensión de UML

• Estereotipos <<excepción>>• Valores etiquetados {versión=3.1}• Restricción {edad>18}

Estereotipo


Diagrama de clases:


Generalización:

Relación taxonómica entre una descripción general y otra más específica que la extiende

Relación “es un tipo de”

Representación del concepto de herencia

#Patrullar()

-Entrenar()


-Num_Placa : int

+Apodo

-Puntería

-Experiencia

Policia

-Origen

+Especialidad

Criminalista

+Riesgo

-Pistola

Patrullero


Diagrama de clases:


Realización: Es una relación que implica que la parte realizante cumple con una serie

de especificaciones propuestas por la clase realizada

Situaciones de aplicación: Interfaces y las clases y componentes que lo implementan

Casos de uso y colaboraciones que lo realizan

#Patrullar()

-Entrenar()


-Num_Placa : int

+Apodo

-Puntería

-Experiencia

Policia

«interfaz»

MiembroSeguridad


Diagrama de clases:Interfaces

Describen un protocolo de comportamiento sin especificar su implementación.

Contienen operaciones pero no atributos.

Una interfaz puede ser implementada por varias clases


Diagramas de Clases vs.Diagramas de Objetos

Ambos pertenecen a dos vistas complementarias del modelo Diagrama de Clases: muestra la abstracción de una parte del dominio

Diagrama de Objetos: representa una situación concreta del dominio

Banco Cliente

*1

Cuenta

*11 * 1 *

unBanco : Banco

cliente01 : Cliente

cliente02 : Cliente

cta0101 : Cuenta

cta0201 : Cuenta

cta0202 : Cuenta


Ejercicio

Se desea modelar el sistema de control de un reproductor de MP3 que tiene las siguientes características:

Un reproductor tiene una marca y modelo determinado. Las operaciones que permite este aparato son: escuchar música (de la memoria), escuchar la radio o configurar el dispositivo

El módulo de memoria permite: conocer la capacidad de la memoria, el número de canciones almacenadas, seleccionar una canción (aleatoriamente o por su título) y borrar una canción

De cada canción se conoce su título, intérprete, duración, tamaño que ocupa, y tipo de compresión (en kbps)

El módulo de radio permite: seleccionar un dial concreto (preseleccionado o manualmente), cambiar de AM a FM y viceversa y preseleccionar emisoras.

Cada emisora se caracteriza por estar en una banda (AM/FM), por un número de frecuencia y por una cobertura

El módulo para la configuración del equipo permite: modificar el brillo y colores del display, consultar el estado de la batería y modificar la ecualización del sonido.

Diseñar el diagrama de clases UML correspondiente a estas especificaciones


Vista de Casos de Uso

Diagramas de casos de uso: Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve desde

el exterior Visión de “caja negra” del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades

discretas: los casos de uso.

Concepto introducido por I.Jacobson en OOSE (ObjectOriented Software Engineering)

Diagramas de Casos de Uso: Actores + Caso de uso


Diagrama de Casos de UsoActor

Representa algo que interactúa con el sistema

Puede ser humano u otro sistema (externo)

Reside fuera del sistema sirve para describir el entorno del sistema

Describe un “rol” que asume un usuario

La misma persona física puede asumir distintos roles

Ejemplos: Cliente del Banco

Cajero

Pasarela bancaria

Sistema de sensores Cliente del Banco


Diagrama de Casos de UsoCaso de uso

Secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor

Describe una “forma” de utilizar el sistema o una “razón” por la que el usuario interactúa con el sistema

Funciones: Capturan requisitos funcionales del sistema Estructuran los modelos de objetos en vistas manejables

Un caso de uso puede tener varios caminos de acción o “escenarios”

Los casos de uso sirven como hilo conductor del proceso de desarrollo (en el PUD)


Diagrama de Casos de UsoEjemplo

Cajero automático (CA)

AdministraciónOperador

(f rom Actors)

Extracción

(from Extraccion)

TransferenciaCliente

(f rom Actors)

Depósito

Sistema Central(f rom Actors)


Diagrama de Casos de UsoDescripción textual (flujo de eventos)

CU Extracción – Camino Estándar

1 Un mensaje de bienvenida está en espera en la pantalla del CA.

2 El cliente inserta su tarjeta en el CA.

3 El CA lee el codigo de la banda magnética y verifica que sea aceptable.

4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN.

5 El cliente ingresa su código PIN.

6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar.

7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario

solicitando los datos de la cuenta del cliente.

8 Los datos de la cuenta recibidos se despliegan en la pantalla.

9 El cliente selecciona una cuenta y el monto a extraer.

10 El CA envia al sistema bancario el requerimiento de extracción.

11 El CA preparan los billetes a ser dispensados.

12 El CA imprime el comprobante del movimiento.

13 Los billetes son dispensados al cliente.


Diagrama de Casos de UsoDescripción textual (completa)

RF- <id del requisito> <nombre del requisito funcional>

Versión <numero de versión y fecha>

Autores <autor>

Fuentes <fuente de la versión actual>

Objetivos asociados <nombre del objetivo>

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}

Precondición <precondición del caso de uso>

Paso Acción 1 {El <actor> , El sistema} <acción realizada por el

actor o sistema>, se realiza el caso de uso < caso de uso RF-x>

2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>

3

4

5

6

Secuencia Normal

n

Postcondición <postcondición del caso de uso>

Paso Acción 1 Si <condición de excepción>,{el <actor> , el

sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}

2

Excepciones

3

Rendimiento Paso Cota de tiempo

1 n segundos

2 n segundos

Frecuencia esperada <nº de veces> veces / <unidad de tiempo>

Importancia {sin importancia, importante, vital}

Urgencia {puede esperar, hay presión, inmediatamente}

Comentarios <comentarios adicionales>


Diagrama de Casos de UsoRelaciones

Inclusión

Secuencias comunes a varios casos de uso

Procesar Tarjeta

Extracción Transferencia Depósito

<<include>>

<<include>>

<<include>>



Extensión:

Partes opcionales de un caso de uso

Extracción

Estadística

Extracción

Monitoreo

Extracción

<<extend>> <<extend>>



Generalización:

Distintas variantes de un caso de uso. (“es un tipo de”)

Extracción

Extracción Pesos Extracción Dólares


Diagrama de Casos de UsoEjemplo

«»

«»

Hacer Pedido

<<extend>>

«»

«»

Silicitar

Catálogo

«»

«»

Suministro de

datos de

clientes

<<include>>

«»

«»

Pedir Producto

<<include>>

«»

«»

Pagar

<<include>>

«»

«»

Pagar al

contado

«»

«»

Acordar

Crédito


Vista de Interacción

Representa como interactúan cooperativamente los objetos para implementar el comportamiento definido por los casos de uso

Colaboración Interacción entre un conjunto de objetos para implementar un

comportamiento del sistema. Una colaboración <<realiza>> la funcionalidad definida en un

casos de uso

Interacción Una interacción es un conjunto de mensajes que se intercambian

dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación)


Vista de InteracciónDiagramas de Secuencia

Énfasis en la secuencia cronológica de los mensajes

: Encargado:WInPréstamos :Socio :Video :Préstamo

prestar(video, socio)

verificar situación socio

verificar situación video

registrar préstamo

entregar recibo


Vista de InteracciónDiagramas de Colaboración

Énfasis en la distribución física y relaciones de los objetos

: Encargado

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo


Vista de Máquina de Estados

Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida: Autómatas finitos con estados y transiciones

Cada objeto se trata en forma aislada, el que se comunica con el resto del mundo detectando eventos y respondiendo a ellos.

Es útil modelar solo para objetos con comportamiento estado-dependiente

Uso de Diagramas de Transición de Estados (DTE)


Diagramas de Transición de Estados

Cada objeto está en un estado en cierto instante El estado describe un período de tiempo caracterizado por:

Conjunto de valores de atributos y relaciones del objeto Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad

El estado en el que se encuentra un objeto determina su comportamiento

Cada objeto sigue el comportamiento descrito en el diagrama de transición de estados asociado a su clase

La transición entre estados es instantánea y se debe a la ocurrencia de un evento


Estados y Transiciones


A B

Evento [condición] / Acción

El evento se considera instantáneo



Ejemplo: Pila (TAD)

Pila

Vacía

Pila no vacía

ni llena

Pila

llena

evento (cond)

acción

push

borrar pila

crear pila pop

error

pop (size > 1)

push (size+1 <> full)

borrar pila

borrar pila

push (size+1 = full)

push

error

pop

pop (size = 1)


Diagramas de Transición de EstadosEventos

Acontecimiento significativo que tiene localización en tiempo y espacio

No tiene duración. Instantáneo

Tipo de eventos Señal: comunicación asíncrona entre objetos

Llamada: invocación sincrónica de método del objeto que recibe el evento

Cambio: satisfacción de una condición lógica que depende de valores de un atributo

Tiempo: instante absoluto, o lapso transcurrido

Pueden modelarse con clases y jerarquías


Diagramas de Transición de EstadosEventos


Diagramas de Transición de EstadosAcciones

Una acción es un cómputo atómico y breve:

una sentencia de asignación

una operación aritmética

el envío de una señal a otro objeto

la invocación de una operación propia

asignación de valores de retorno

creación o destrucción de objetos

una secuencia de acciones simples

Acciones específicas de entrada, salida, durante, un estado o por un evento

estado A

entry: acción por entrar

exit: acción por salir

do: acción mientras en estado

on evento: acción


Diagramas de Transición de EstadosEstados Compuestos


Vista de Actividades

Variante de la máquina de estados para modelar flujos de trabajo

Utilización de diagramas de actividad Caso particular de los diagramas de estado

Los estados representan estados de actividad no de un objeto


Diagrama de ActividadesElementos


Diagrama de ActividadesCalles y flujo de objetos


Vista de Implementación

Tipo de vista “física”

Modela el empaquetado físico del sistema en unidades reutilizables llamadas “componentes” Componente una unidad física de implementación con interfaces

definidas pensada para ser utilizada como parte reemplazable del sistema.

Cada componente implementa una o más clases del diseño

Incluyen código fuente, binario, o ejecutable

Los componentes se vinculan por relaciones de dependencia

Se utilizan diagramas de componentes


Diagrama de Componentes (UML 1.5)


Vista de Despliegue

Modela la disposición física de los recursos de ejecución computacional

Nodo: es un objeto físico de ejecución que representa un recurso computacional. Pueden tener estereotipos (CPU, memorias, disco duro, etc.)

Las asociaciones entre nodos representan líneas de comunicación.

Se representa con diagramas de despliegue


Diagrama de Despliegue


Diagrama de Despliegue

Cliente

APP

Server

DB Server

**

**

* Web Browser

* Servlets

* JSP

* JDBC


Vista de Gestión

La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes

Paquete: es una unidad de organización del modelo

Los paquetes ofrecen un mecanismo general para la organización de los modelos / subsistemas agrupando elementos de modelado

Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc.

Los paquetes también pueden contener otros paquetes


Vista de Gestión

Todos los elementos del modelo deben pertenecer a un paquete

Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.)

Por subsistema

Por etapa del ciclo de desarrollo.

Una buena organización refleja la arquitectura de alto nivel del sistema.


Vista de Gestión

Modelo vs. Subsistema

Un modelo es un paquete que abarca una descripción completa de una vista particular de un sistema. Proporciona una descripción cerrada de un sistema a partir de un punto de vista. P. ej.: modelo de análisis, de diseño, de implementación

Un subsistema es un paquete que tiene piezas separadas de especificación y de realización. Representa una partición del sistema P. ej.: subsistema de transacciones, de gestión de datos


Vista de Gestión

Dependencias de acceso / importación: Todas las clases no son necesariamente visibles desde el exterior del

paquete, es decir, un paquete encapsula a la vez que agrupa

El operador “::” permite designar una clase definida en un contexto distinto del actual


Vista de Gestión

Dependencias de acceso / importación: La dependencia de acceso no modifica el espacio de nombres del cliente.

Solo concede permiso para establecer referencias

La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos


4+1 vistas de P. Kruchten

Vista Lógica

Vista de Procesos

Vista de Distribución

Vista deRealización

Vista de los Casos de Uso


Ciclo de Vida en el PUD


Bibliografía

Título Autor ISBN

El Lenguaje Unificado de Modelado

Manual de Referencia

James Rumbaugh 8478290370

El Lenguaje Unificado de Modelado

Guía del Usuario

Grady Booch 8478290281

UML Gota a gota Martin Fowler 9684443641

UML y Patrones Craig Larman 8420534382

http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml






tema 1: introducción a la ingeniería del softwareis... · incluye conceptos semánticos,...

Documents