Introd SI

Introduccin a la
Ingeniera Software
L. Marnez & P.J. Snchez Sistemas Informticos Ingeniera Informtica Universidad de Jan 2
Ingeniera Software
Sistemas Software son complejos
Imposibles de entender por una sola persona
Muchos proyectos nunca se terminan: "vaporware"

1968 Definicin:
Ingeniera Software significa la construccin de software de calidad
con un presupuesto limitado y una fecha de entrega
Definicin ms actual:
Ingeniera Software significa la construccin de software de calidad
con un presupuesto limitado y una fecha de entrega en contextos de
cambio continuo
Enfasis es en ambos, en el software y en la ingeniera

Actividades de la Ingeniera Software
Obtencin de Requerimientos
Propsito del Sistema
Resultado: sistema descrito en trminos de:
Actores: entidades que interactan con el sistema
Casos de Uso: Secuencias de eventos generales (Actor-Sistema)
Anlisis:
Modelo del sistema correcto, completo, consistente, claro y verificable
Transforman los casos de uso en un modelo (objeto)
Diseo:
Se definen los objetivos del proyecto
Subsistemas
Estrategias
Sistema: Hardware, Software
Datos: almacenamiento, flujo de datos, etc
Implementacin
Traduccin: MODELO a CODIGO FUENTE

Modelado con UML
Introduccin

Qu es el modelado?
Qu es el modelado UML?
Diagramas de Casos de Uso
Diagramas de Clase
Diagramas de Secuencia
Diagramas de Estado
Diagramas de Actividad
Sistemas, Modelos y Vistas
Un sistema es un conjunto organizado en partes que se
comunican y diseado con un propsito especfico
Descomposicin en elementos
Subsistemas, clases, objetos,
Un modelo es una abstraccin que describe un sistema o una
parte de un sistema
Maneja la complejidad del sistema
Diferentes niveles de complejidad
Una vista muestra aspectos seleccionados de un modelo
Subconjunto del modelo
Una notacin es un conjunto de reglas grficas o texto para
representar vistas
Sistemas, Modelos y Vistas
System
View 1
Model 2
View 2
View 3
Model 1
Avin

SimuladorVuelo

Modelo a escala
Esquema
Cableado
Elctrico
Modelos, Vistas, y Sistemas (UML)
Vista
* *
Mostrado con Descrito por
Sistema Modelo
simladorDeVuelo:Modelo modeloAEscala:Modelo
Esquema:Vista
avin:Sistema
sistDeCombust:Vista cableadoElect:Vista
Conceptos y Fenmenos
Fenmeno: Un objeto del mundo real tal y como es percibido,
por ejemplo:
La clase a la que atiendes
Mi reloj negro
Concepto: Abstraccin que describe las propiedades que son
comunes a los fenmenos, por ejemplo :
Clases de Sistemas Informticos
Relojes Negros
Un concepto tiene 3 componentes:
Su Nombre lo distingue de otros conceptos
Su Propsito o las propiedades que determinan si un fenmeno es
miembro de un concepto
Sus Miembros que son los fenmenos que forman parte del concepto
Abstraccin: Clasificacin de fenmenos en conceptos
Modelado: proceso de crear abstracciones para responder
preguntas sobre un conjunto de fenmenos ignorando detalles
irrelevantes
Miembros Nombre
Reloj
Propsito
Dispositivo que
mide el tiempo
Conceptos y Fenmenos
Conceptos en el Software: Tipo e Instancia
Tipo:
Una abstraccin en el contexto de los lenguajes de programacin
Nombre: int, Propsito: entero, Miembros: 0,-1, 1, 2,-2,...
Instancia:
Miembro de un tipo especfico
La relacin entre Tipo e Instancia es similar a la existente entre concepto y
fenmeno
Clase:
Una abstraccin en el contexto de los leng. de programacin OO
Dominio de Aplicacin (Anlisis de Requerimientos):
Entorno en el cul opera el sistema
Dominio de la Solucin (Diseo de Sistemas, Diseo de Objetos):
Tecnologas disponibles para construir el sistema
Por qu el modelado?

El modelado desarrolla abstracciones

Simple vs conjunto de fenmenos
Actividad de los Ingenieros Software
Diseo de un sistema
Abstraccin: conceptos del dominio de aplicacin
Ocultar datos irrelevantes
Modelo ms simple que el sistema
Por qu el modelado software?
El Software es ya de por si una abstraccion: Por qu modelado
software?

El Software es cada vez mayor
NT 5.0 ~ 40 millones de lneas de cdigo
Un nico programador no puede manejar esta cantidad de cdigo
El cdigo no es directamente inteligible por los desarrolladores
que no participaron en el desarrollo
Se necesitan representaciones simples para sistemas complejos
El modelado es un medio para manejar la complejidad
Qu es el UML?
UML (Unified Modeling Language)
Un estndar para modelar software orientado a objetos.
Resulta de la convergencia de otros mtodos de modelado como:
OMT (James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)
Referencia: The Unified Modeling Language User Guide,
Addison Wesley, 1999.
Herramientas CASE que lo soportan
Rational ROSE
Visual Paradigm
...
UML. Primer vistazo
Diagramas de Casos de Uso
Describe el funcionamiento del sistema desde el punto de vista del
usuario.
Diagramas de clase
Describen la estructura esttica del sistema: Objetos, Atributos, y
asociaciones.
Diagramas de Secuencia
Describen el comportamiento dinmico entre actores u objetos y el
sistema.
Diagramas de Estado
Describen el comportamiento de un objeto individual.
Diagramas de Actividad
Modelan el comportamiento dinmico de un sistema: flujo de trabajo.
UML Primer vistazo : Diagramas de Casos de Uso
UsuarioReloj
Relojero
ConsultarHora
AjustarHora
CAmbiarBatera
Actor
Caso de Uso
Paquete
Reloj Simple
Diagrama de Caso de Uso que representa la funcionalidad de un
Sistema desde el punto de vista de los usuarios
UML Primer vistazo : Diagramas de Clase
Bateria
carga()
1
2
Hora
ahora()
BotonOprimible
estado
oprimir()
soltar()
1
1
1
1
1
2
parpadeoIdx
parpadeoSeconds()
parpadeoMinutes()
parpadeoHours()
stopParpadeo()
refresh()
Pantalla
Reloj Simple
Clase
Asociacin
Multiplicidad
Atributos
Operaciones
Diagramas de Clase representan la estructura del Sistema
UML Primer vistazo : Diagrama de Secuencia
Representan el comportamiento del sistema como interacciones
Activacin
Objeto
Mensaje
button1&2Pressed
UML Primer vistazo : Diagramas de Estado
Estado
Estado Inicial
Estado Final
Transicion
Evento
UML Primer vistazo : Diagramas de Actividad
Accin
Activacin
Handle
Incident
Document
Incident
Archive
Incident
UML Primer vistazo : Notacin Bsica
Rectngulos: clases o instancias
Ovalos u ovoides: son funciones o casos de uso
Las instancias se notan con su nombre subrayado
miReloj:RelojSimple
bJuan:Bombero
Tipos (clases) se escriben sin subrayar su nombre
RelojSimple
Bombero
Los diagramas son grafos
Los nodos representan entidades
Los arcos representan relaciones entre entidades
UML Segundo Vistazo: Diagramas de Casos de Uso
Se utiliza en el anlisis de requisitos para
representar el comportamiento externo

Actores representan un papel, es decir,
un tipo de usuario del sistema
Casos de Uso representan la
funcionalidad del sistema
El modelo de casos de uso es el
conjunto de todos los casos de uso. Es
una descripcin completa de la
funcionalidad del sistema y su entorno
(Frontera del sistema)
Pasajero
CompraDeTicket
UML Segundo Vistazo: Diagramas de Casos de Uso
Diagrama Frontera
Actores
Un actor modela una entidad externa que se
comunica con el sistema:
Usuario
Sistema externo
Entorno fsico
Un actor tiene un nombre nico y una
descripcin opcional.
Ejemplos:
Pasajero: persona que viaja en un tren
GPS satlite: provee al sistema con coordenadas
GPS
Pasajero
Caso de Uso
Un caso de uso representa una clase de
funcionalidad dada por el sistema como
un flujo de eventos.

Un caso de uso consiste:
Nombre nico
Actores que participan
Condiciones de entrada
Flujo de eventos
Condiciones de salida
Requerimientos especiales
CompraDeTicket
Ejemplo Caso de Uso
Nombre: CompraDeTicket

Actor participante: Pasajero

Condicin de entrada:
Pasajero esperando en frente
del dispensador de tickets.
Pasajero tiene suficiente
dinero para comprar ticket.

Condicin de salida:
Pasajero tiene ticket.
Flujo de eventos:
1. Pasajero selecciona el n de
zona a la que quiere viajar.
2. El dispensador muestra el
precio de dicho ticket.
3. Pasajero paga al menos la
cantidad indicada.
4. Dispensador devuelve cambio.
5. Dispensador da el ticket.

Falta algo?
Excepciones!
Escenario de un Caso de Uso
Un caso de uso es una abstraccin que
representa todos los posibles escenarios
que involucran la funcionalidad que se
describe.

Descripcin de un escenario:
Nombre es una nica instancia
Instancias de los actores que participan
Flujo de eventos: escenario paso a paso

CompraTicketSolMoncloa
La Relacin <<extend>>
Las relaciones <<extend>> representan
casos invocados excepcionalmente o rara
vez.
Los flujos de eventos excepcionales son
indicados fuera del flujo de evento principal
por claridad.
Los casos de uso representando casos de uso
excepcionales pueden extender ms de un
caso de uso.
La direccin de una relacin <<extend>>
es hacia el caso de uso extendido
Condicin inicial (inicio extend)
Pasajero
CompraTicket
TiempoExcediddo
<<extend>>
SinCambio
<<extend>>
FueraDeServicio
<<extend>>
Cancelar
<<extend>>
Pasajero
CompraBilleteSimple
CompraMultiTarjeta
SinCambio
<<extend>>
Cancelar
<<extend>>
<<include>>
CobrarDinero
<<include>>
La Relacin <<include>>
Una relacin <<include>>
representa un comportamiento
comn del caso de uso.
Un <<include>> representa un
comportamiento que es reusado,
no por ser una excepcin.
La direccin de una relacin
<<include>> es hacia el caso
de uso (al contrario de las
relaciones <<extend>>).
Flujo de eventos (inicio include)
Diagramas de Clase
Los diagramas de clase representan la estructura del sistema.
Se utilizan
Durante el anlisis de requerimientos para modelar los conceptos del
dominio del problema
Durante el diseo del sistema para modelar los subsistemas e interfaces
Durante el diseo de objetos para modelar clases.

Enumeracin obtenerZonas()
Precio obtenerPrecio(Zona)
PrecioHorario
*
*
Viaje
zona:Zona
precio:Precio
Clases entidad, frontera y control
Entidad
Informacin persistente rastreada por el sistema
Frontera
Interaccin entre actores y el sistema
Control
Tareas realizadas por el usuario y soportadas por el sistema
Clases
Una clase representa un concepto.
Una clase encapsula un estado (atributos) y comportamiento
(operaciones).
Cada atributo tiene un tipo.
Cada operacin tiene identidad.
El nombre de clase es la nica informacin obligatoria.
precioDeZona
obtenerZonas()
obtenerPrecio()
PrecioHorario
Tabla precioDeZona
Enumeracion obtenerZonas()
PrecioHorario
Nombre
Atributos
Operaciones
Identidad
PrecioHorario
Clases Abstractas
Disminuir Complejidad.
No implementan operaciones.
valor:Valor
obtenerev()

Evaluacion
valor
obtenerev(){abstract}
Evaluacion {abstract}
Instancias
Una instancia representa un fenmeno.
El nombre de la instancia est subrayado y puede contener la
clase de la que es instancia.
Los atributos se representan con sus valores.
precioDeZona = {
{1, .20},
{2, .40},
{3, .60}}
tarifa_1974:PrecioHorario
Actor vs. Instancias
Cul es la diferencia entre un actor y una clase y una instancia?
Actor:
Entidad fuera del sistema a ser modelada, interacta con el sistema
(Piloto)
Clase:
Una abstraccin que modela una entidad en el dominio del
problema (solucin), es modelada dentro del sistema (Cabina)
Objeto:
Una instancia especfica de una clase (Jose, el inspector).
Asociaciones
Las asociaciones notan relaciones entre clases.
Una asociacin es una relacin estructural entre iguales.
La multiplicidad de una asociacin indica cuantos objetos de
una clase se pueden corresponder con objetos de otra.

Enumeracin obtenerZonas()

PrecioHorario
*
precio
zona
Viaje
*
Asociaciones 1-a-1 y 1-a-Muchos
Asociacin 1-a-1
Asociacin 1-a-muchos
*
dibujar()
Polgono
x:Integer
y:Integer
Punto
1
Tienecapital
nombre:String
Pas
nombre:String
Ciudad
1 1
Nombre
Asociaciones Muchos-a-Muchos
Trabaja
nombre:String
Persona
nombre:String
Empresa
1..*
1..*
Nombre
Patrn Empleado
Roles o
Papeles
Asociacin muchos-a-muchos
Dependencia
Una dependencia es una relacin de uso que declara que un
cambio en la especificacin de un elemento puede afectar a
otro elemento que la utiliza
Indicar que una clase utiliza a otra como argumento.
Agregacin
Una agregacin es un caso especial de asociacin que denota
una jerarqua consiste en.
El agregado es la clase padre, los componentes son las clases
hijo.
*
Nacin
Nacin
1
*
Estado
Regin
1
?
Espaa Estado
Autonmico
Espaa Nacin de
Naciones
Agregacin
Una agregacin es relacin todo/parte no entre iguales
Es una relacin del tipo tiene-un un objeto del todo tiene
objetos de la parte.
*
Nacin
Nacin
1
*
Estado
Regin
1
Espaa Estado
Autonmico
Espaa Nacin de
Naciones
Composicin
Un diamante relleno denota una composicin, una agregacin
fuerte donde los componentes no pueden existir sin el agregado.
3
ExpendedorTicket
BotnDeZona
1
*
Universidad
Departamento
1
Profesor
*
1
Generalizacin
Anlisis: Clases similares estructuralmente y comportamiento:
Modelarlas de forma independiente
Extraer caractersticas comunes de estructura y comportamiento
Las relaciones de generalizacin muestran herencia entre clases.
Las clases hijo heredan los atributos y operaciones de la clase padre.
La generalizacin simplifica el modelo eliminando redundancia (clases
abstractas).
Botn
BotnDeZona BotnCancelar
Actividades de anlisis
Identificacin de objetos:
Entidad
Frontera
Control
Identificacin de las asociaciones entre objetos.
Identificacin de atributos de objetos.
Modelado de las relaciones de generalizacin
Modelado de interacciones entre objetos (diag. de secuencia).
Modelado de comportamiento no trivial.
Cmo encontrar clases entidad?
Anlisis del lenguaje natural (heurstica de Abbott [1983]):

Parte del habla Componente del Modelo Ejemplos
Sustantivo propio Objeto Alicia
Sustantivo comn Clase OficialCampo
Verbo de accin Operacin Crea, enva,
Verbo de ser Herencia Es un tipo de,
Verbo de tener Agregacin Tiene, consiste en
Verbo modal Restricciones Debe ser
Adjetivo Atributo Descripcin del incidente
Ventajas e Inconvenientes
Ventajas
Est enfocado en los trminos del usuario
Lista inicial de candidatos
Inconvenientes
El modelo depende del estilo de escritura
El lenguaje natural es impreciso
Ms nombres que clases relevantes
Soluciones
Volver a rehacer las especificaciones segn se avanza
Complementar la heurstica

Complementar la heurstica de Abbott
Mejora de la Heurstica de Abbott
Trminos que desarrolladores o usuarios necesitan
Nombres recurrentes
Entidades del mundo real
Actividades del mundo real
Casos de uso
Fuentes o destino de datos
Siempre hay que usar los trminos del usuario
Resultados
Nombre
Descripcin breve de objetos
Actividad iterativa (hasta anlisis estable)
Ejemplo
Nombre del caso de uso: InformarEmergencia
Actores:
Condicin Inicial:
Oficial de Campo, Gestor
1.El OficialCampo activa la funcin InformarEmergencia de su terminal.
Flujo de eventos: 2. FRIEND responde presentando un formulario al oficial que incluye un men de
tipo de emergencia, campos para ubicacin, descripcin del incidente, peticin de
recursos y materiales peligrosos.
3. El OficialCampo rellena el formulario. El OficialCampo tambin describe
respuestas posibles y solicita recursos especficos. Una vez relleno lo enva
oprimiendo el botn EnviarInforme y en ese momento se le notifica al Gestor.
4. El Gestor revisa la informacin y crea un Incidente en la base de datos llamando
al caso de uso AbrirIncidente. El Gestor selecciona una respuesta asignando recursos
al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo del
informe de emergencia enviando un FRIENDgrama al OficialCampo.
Condicin de Salida: 5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
Cmo encontrar clases entidad?
Anlisis del lenguaje natural (heurstica de Abbott [1983]):

Parte del habla Componente del Modelo Ejemplos
Sustantivo propio Objeto Alicia
Sustantivo comn Clase OficialCampo
Verbo de accin Operacin Crea, enva,
Verbo de ser Herencia Es un tipo de,
Verbo de tener Agregacin Tiene, consiste en
Verbo modal Restricciones Debe ser
Adjetivo Atributo Descripcin del incidente
Clases entidad caso de uso InformarEmergencia
OficialCampo
Es un oficial de polica o bombero que est
trabajando. Un OficialCampo puede asignarse,
como mucho, a un Incidente.
InformeDeEmergencia
Es el informe inicial acerca de un Incidente que
hace un OficialCampo hacia un Gestor. Un
InformeDeEmergencia activa la creacin de un
Incidente por parte del Gestor. Y est compuesto
de un nivel de emergencia, un tipo, una ubicacin
y una descripcin.
Gestor
Es un oficial de polica que administra Incidente.
Abre, documenta y cierra un Incidente en
respuesta a InformeDeEmergencia. Los
Gestores se identifican con n de id.
Incidente
Es una situacin que requiere atencin de un
OficialCampo. Son informados por
OficialCampo.
Clases frontera
Identificar formularios y ventanas

Identificar noticias y mensajes

No hay que modelar los aspectos visuales de la
interfaz

Siempre hay que usar los trminos del usuario para
describir las interfaces.
Ejemplo
Actores:
Condicin Inicial:
Clases frontera caso de uso InformarEmergencia
NoticiaAcuseDeRecibo
Noticia usada para desplegar el acuse del
Gestor hacia el OficialCampo
BotnInformeDeEmergencia
Botn usado por el OficialCampo para iniciar
el caso de uso InformarEmergencia
FormularioInformeDeEmergencia
Formulario usado para dar los datos de
InformeDeEmergencia. Tiene todos los
campos para especificar todos los atributos de
un informe de emergencia y un botn para
enviarlo cuando est relleno. Se le presenta al
OficialCampo en la EstacinOficialCampo.
FormularioIncidente
Formulario usado para la creacin de Incidente.
Se le presenta al Gestor en la
EstacinDespachador cuando se recibe un
InformeDeEmergencia.
Clases de control
Una clase por caso de uso
Si es complejo se puede dividir

Por actor en el caso de uso

La vida del objeto corresponde con la secuencia del
caso de uso.
Definir bien las condiciones de entrada y salida
Ejemplo
Actores:
Condicin Inicial:
Clases control caso de uso InformarEmergencia
ControlInformarEmergencia
Se crea una instancia cuando el OficialCampo
selecciona el botn InformarEmergencia.
Luego crea un FormularioInformeEmergencia,
recopila la informacin, crea un
InformeDeEmergencia y se lo pasa al Gestor.
Espera un acuse de recibo y crea una
NoticiaAcuseRecibo y se la presenta al
OficialCampo.
ControlAdministrarEmergencia
Se crea una instancia cuando se recibe un
InformeDeEmergencia. Crea un formulario
FormularioIncidente y se lo presenta al Gestor.
Una vez que Gestor ha creado un Incidente, le
ha asignado Recursos y ha enviado un acuse de
recibo, enva el acuse de recibo a la
EstacinOficialCampo.
Identificacin de asociaciones
Ventajas
Clarifica el modelo
Casos frontera asociados a los vnculos (excepciones)
Heurstica
Examine las frases verbales
Nombre con precisin a las asociaciones y papeles
Use clarificadores para nombres y atributos principales
Elimine asociaciones que puedan derivarse de otras asociaciones
Poner la multiplicidad cuando se alcance una estabilidad con las
asociaciones
No poner un exceso de asociaciones.
Ejemplo caso de uso InformarEmergencia
Relaciones de Generalizacin
Eliminan redundancias en el modelo

Si dos o ms clases comparten atributos

Modelar de forma explicita similitudes o especificar
comportamientos
Clases abstractas
Identificacin de atributos
Examine las frases posesivas

Un estado almacenado como atributo clase entidad

Describa cada atributo

Si un atributo es un objeto entonces ponerlo como asociacin

No realizar una especificacin excesiva hasta que el modelo sea
estable
Diagramas de Secuencia UML
Modelan aspectos dinmicos de los sistemas
Une los Casos de Uso con los Objetos
Describen interacciones
Objetos y sus relaciones
Mensajes que intercambian
Ordenan temporalmente los mensajes
Se usa en el anlisis de requerimientos
Para refinar descripciones de casos de uso
Para encontrar objetos adicionales
Se usa en el diseo del sistema
Para refinar interfaces
Object Object Object
Lifeline (active)
messages
Request(query)
Reply(result)
Request(query)
Request(query)
Request(query)
Reply(result)
Reply(result)
Reply(result)
Las Objetos se representan con columnas
Los Mensajes son flechas
Las Activaciones o foco de control son
pequeos rectngulos
Las lneas de vida son lineas punteadas
elegirZona()
cogerCambio()
cogerTicket()
insertarDinero()
Pasajero
ExpendedorTickets
Diagrama de Secuencia en UML
obj1: Fr_CU_X
2: busca(d)
obj2: Control_X
3: getAtributoY()
obj3: Clase_X
return v
....
....
....
1: escribe d
y solicita
OBJETOS
PASO DE MENSAJES
Actor
Los objetos se pueden crear con el mtodo CREATE
(comienza su lnea de vida y foco de control mientras
ejecutan cosas) y se pueden destruir con el mtodo
DESTROY (se termina su lnea de vida)
create()
hazX()
: C3
hazY()
destroy()
: C2
: C1
Una llamada a un mtodo puede devolver un valor (mensaje
return valor en lnea con puntos suspensivos).
Generalmente slo se pondr en el diagrama de secuencia
cuando proporcione informacin interesante
obj2: Control_X
getAtributoY()
obj3: Clase_X
return v
....
Heurstica para diagramas de secuencia
La 1 columna representa al actor que inicia el caso de uso
La 2 representa el Objeto frontera (que usa el actor para iniciar el caso de uso)
La 3 representa el Objeto control que maneja el resto del caso de uso
Los objetos control son creados por objetos frontera
Que inician casos de uso
Los objetos frontera son creados por objetos control
Los objetos entidad son accedidos
Objetos control
Objetos frontera
Los objetos entidad nunca tienen acceso a los objetos frontera y
control
Diagramas de Secuencia: Observaciones
Un diagrama de secuencia UML representa el comportamiento
en trminos de interacciones.

Complementan los diagramas de clase que representan la
estructura del sistema.

Son costosos y difciles de construir pero el tiempo invertido
suele valer la pena.

Realizarlos slo diagramas de secuencia para partes del sistema
complejas o mal definidas

Diagramas de Estado
Son un complemento a la descripcin de una clase
Un estado es una condicin/es que satisface un objeto
Muestran:
Todos los estados posibles que pueden tener los objetos de una clase
Y qu eventos causan un cambio de estado
Cambio de estado se denomina Transicin
Estos diagramas se realizan slo para aquellas clases que:
Tienen una serie de estados bien definidos
Comportamiento de la clase es afectado y cambiado por estados diferentes
Pueden dibujarse para el sistema en su totalidad (no recomendable)
Se utilizan para
Identificar atributos de objetos
Hacer explcito el atributo/s que tienen impacto en el comportamiento de obj.

Diagramas de Estado

State 1
State 2 State 3
State n
condition
action
Diagramas de Estado
Reserva de asientos en un vuelo

Disponible Bloqueado
Vendido
Bloquear
Tiempo excedido
Desbloquear
Vendido
Diagramas de actividad
Estos diagramas muestran el flujo de control dentro del sistema

Solicitar
Producto
Recibir
Pedido
Pagar
Factura
Procesar
Pedido
Facturar al
Cliente
Cerrar Pedido
Extraer
Artculos
Enviar Pedido
Asignar Tareas
Replanificar
Seleccionar
Trabajos
[Hay Materiales]
Diagramas de actividad
Un diagrama de actividad es un caso especial de diagrama de
estados en los que los estados son actividades (funciones)
Dos tipos de estados:
Estado de Accin:
No puede descomponerse ms
Sucede instantneamente con respecto al nivel de abstraccin usado en
el modelo
Estado de Actividad:
Puede descomponerse an ms
La actividad se modela con otro diagrama de actividad

Diagramas de Actividad: Modelando Concurrencia
Sincronizacin de mltiples actividades
Divisin del flujo de control en mltiples hilos
Sincronizacin
/Unin
Divisin
Archivar
Incidencia
Abrir
Incidencia
Documentar
Incidencia
Destinar
Recursos
Coordinar
Recursos
Resumen
El UML provee una amplia variedad de notaciones para
representar distintos aspectos del desarrollo de software
Potente, pero lenguaje complejo
Puede ser mal utilizado para generar modelos ilegibles
Puede ser malinterpretado cuanso se usan demasiadas
caractersticas exticas

Nuestro objetivo es centrarnos slo en unas cuantas notaciones:
Modelo Funcional: diagramas de casos de uso
Modelo de Objetos: diagramas de clase
Modelo Dinmico: diagramas de secuencia (estado y actividad)

Introd SI

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Introd SI

Загружено:

Авторское право:

Доступные форматы

Introduccin a la

Вам также может понравиться