02 MSA Material 02

Rodolfo Fernndez Gonzlez
Metodologa de Modelizacin
METODOLOGIAS DE MODELIZACION
Unidad Docente de Lgica y Filosofa de la Ciencia
MODELIZACIN
- La construccin de hiptesis tericas o modelos computacionales es un arte sometido a reglas
- Modelizar: formalizar un fenmeno natural, organizacional o
tcnico para disponer de:
- una descripcin rigurosa
- un punto de partida preciso para la contrastacin de
hiptesis
- un ncleo para el desarrollo de una aplicacin informtica
- Hay diversos estilos de formalizacin:
- explcitamente matemtico:
- cuantitativo: Anlisis matemtico, Clculo de
Probabilidades
- cualitativo: Algebra, Lgica
- computacional:
- es implcitamente matemtico
- puede suponer o no una previa formalizacin
matemtica
- diversas estrategias:
- OMT (Object Modelling Tool)
Rumbaugh, J. et al. (1991) Object-oriented
modeling and design. Prentice-Hall
- KADS
MODELOS
- Un modelo es una abstraccin o esquematizacin de algo para
facilitar su comprensin.
- Abstraccin o esquematizacin:
- omisin de detalles no esenciales del sistema real que
reduce su complejidad y facilita su comprensin.
- lo que se considera relevante viene dado por el objetivo del
modelo
- un mismo sistema puede ser objeto de distintas
modelizaciones, cada una en virtud de un objetivo distinto
- todas las abstracciones son incompletas. Se busca
adecuacin, no correccin.
FASES DE LA MODELIZACION
- Anlisis
- Diseo
- Implementacin
FASE DE ANLISIS
- Construccin de modelos de la situacin real que identifique las
propiedades relevantes
- Lo que interesa es comprender el problema
- Modelos de anlisis: abstracciones concisas y precisas de lo que
debe hacer el sistema, no de cmo lo har
- Los objetos de los modelos son conceptos del dominio del
problema, independientes de la implementacin.
FASE DE DISEO
2.1. Diseo del sistema
- Decisiones de alto nivel sobre la arquitectura global
- Identificacin de subsistemas
- Decisiones de optimizacin del rendimiento
- Estrategias de resolucin
- Asignacin inicial de recursos
2.2. Diseo de los objetos
- Construccin de los modelos de diseo a partir de los
modelos de anlisis
- Detalles de implementacin impuestos por las
estrategias de resolucin
- Identificacin de las estructuras de datos y de los
algoritmos necesarios para:
- implementar cada clase
- optimizar el rendimiento
FASE DE IMPLEMENTACIN
- Codificacin de los modelos de diseo en un lenguaje de
programacin
- Ingeniera del software:
- ajuste al diseo
- flexibilidad
- extensibilidad
TIPOLOGA DE MODELOS
- En cada fase, la modelizacin implica la construccin o
refinamiento de tres modelos distintos:
- Modelo de objetos
- Modelo dinmico
- Modelo funcional
MODELO DE OBJETOS
-Describe la estructura esttica de los objetos de un sistema, sus
relaciones mutuas, sus atributos y sus operaciones
- Se formula utilizando un diagrama de objetos:
- Diagrama de objetos: grafos cuyos nodos son clases de
objetos, y cuyos arcos son relaciones entre clases
- Las clases se ordenan jerrquicamente. Esa ordenacin hace que
puedan compartir estructuras y comportamientos.
- Es el modelo fundamental, porque describe qu es lo que cambia
o se transforma, antes de describir cundo o cmo lo hace.
- Proporciona la estructura bsica en la que se integran los dems
modelos
- Descripcin de los datos
- Es importante para cualquier problema que manipule estructuras
de datos no triviales
MODELO DINMICO
- Describe los aspectos del sistema que cambian en el tiempo, las
interacciones entre los objetos del sistema
- Secuenciacin de operaciones:
- sucesos que inician o terminan cambios,
- secuencias de sucesos,
- estados que definen el contexto de los sucesos,
- organizacin de sucesos y estados
- Se formula mediante un diagrama de estados:
- Un diagrama de estados es un grafo cuyos nodos son
estados, y cuyos arcos son transiciones entre estados
causadas por sucesos.
- Describe la secuencia de sucesos y estados admisibles en
una clase de objetos
- Descripcin de los aspectos de control
10
MODELO FUNCIONAL
- Describe las transformaciones de datos que tienen lugar en el
sistema
- Funciones, restricciones, dependencias funcionales
- Lo que el sistema hace
- Se formula mediante diagramas de flujo:
- Un diagrama de flujo es un grafo cuyos nodos son
procesos y cuyos arcos son flujos de datos.
- Representa las dependencias entre valores, y la
computacin de los valores de salida a partir de los valores
de entrada
- Descripcin de la funcin del sistema
11
RELACIONES ENTRE LOS MODELOS

- Los tres tipos de modelos son ortogonales entre s: describen tres
aspectos distintos del sistema, pero estrechamente relacionados
entre s:
- El modelo de objetos describe las estructuras de datos
sobre las que operan los modelos dinmico y funcional.
- Distintas modalidades descriptivas de los componentes
dinmicos del sistema:
M. de objetos
M. dinmico
M. funcional
operaciones
sucesos
acciones
funciones
- Los tres modelos evolucionan juntos durante las distintas fases

del proceso de modelizacin
- A veces, los lmites no estn claros entre los tres modelos
- A veces, los modelos no pueden captar todo lo que es relevante.
En esos casos se puede recurrir:
- al lenguaje natural
- a notaciones especficas, adecuadas al dominio del
problema
12
Modelizacin de objetos
(Rumbaugh, 87, 91; Loomis, 87)
Objetos
- Un objeto (o instancia -de objeto-) es un concepto o entidad, que
constituye un elemento bien definido del dominio del problema
- La identificacin de los objetos depende del problema: puede
haber ms de una representacin en el mismo dominio
- Los objetos se distinguen entre s no por sus atributos, sino por
su identidad
Clases
- Una clase (de objetos) es un grupo de objetos que comparten:
- propiedades (atributos)
- comportamiento (operaciones)
- relaciones con otros objetos
- significado (p. ej., un cuadro y un caballo pueden ser
considerados como bienes econmicos, pero ...)
- cada objeto conoce su clase. Esta es una propiedad implcita
del objeto
- la agrupacin de objetos en clase es una abstraccin que nos
permite:
- generalizar el conocimiento de lo individual
- simplificar la complejidad
- utilizar menos recursos (descriptivos, de almacenamiento
de informacin)
13
Diagramas para objetos:

- Clases
- Objetos o instancias
Rumbaugh
Coad/Yourdon
14
Atributos
- Caractersticas posedas por los objetos de la misma clase
- Cada instancia tiene un valor por cada atributo
- Diferentes instancias pueden tener el mismo o distinto valor
- Los valores de los atributos no son objetos, no tienen identidad
- Si un valor de un atributo de un objeto1 exige a su vez ser
modelizado como objeto2, se modelizar como tal, y se
asociar con objeto1 mediante una relacin entre objetos
- Se representan en las clases bajo una lnea horizontal
- Cada atributo puede tener asociado
- su tipo (precedido por :)
- su valor por defecto (precedido por =)
Persona
nombre :cadena
edad :entero
En el caso de las clases, slo se representan los valores:
(Persona)
(Persona)
Juan Prez
27 aos
Juan Prez
27 aos
Rumbaugh
Coad/Yourdon
15
OPERACIONES
- Operacin: Funcin o transformacin que puede aplicarse a - o
que puede ser aplicada por- objetos de una clase
- Cada operacin tiene como argumento implcito un objeto.
- La conducta de la operacin depende de la clase de su
objeto
- el objeto sabe la especificacin adecuada de su
operacin
- polimorfismo: la misma operacin:
- puede aplicarse a muchas clases distintas
- adopta en cada clase una forma distinta
16
MTODOS
Un Mtodo es la especificacin (implementacin) de una
operacin para una clase dada
- Si una operacin tiene mtodos para varias clases, es importante
que todos ellos tengan la misma signatura:
- lista de argumentos (entre parntesis)
- tipo de cada argumento (precedido de :)
- tipo del valor resultante (precedido de :)
- Representacin:
Persona
nombre :cadena
edad :entero
comprar
- Resulta til durante la modelizacin distinguir las operaciones
que tienen efectos colaterales de aquellas que se limitan a calcular
un valor sin modificar otros objetos (queries)
- Las queries que no tienen ms argumentos que los de su objeto
pueden considerarse como atributos derivados
- Esto lleva a distinguir entre:
- atributos bsicos o primitivos, y
- atributos derivados
- Al conjunto de las operaciones y de los mtodos se les denomina
servicios
17
ENLACES Y ASOCIACIONES
- Un enlace es una conexin fsica o conceptual entre dos
instancias de objetos
- Formalmente es una relacin, es decir, una lista ordenada de
objetos
- Un enlace es una instancia de una asociacin
- Una asociacin es un grupo de enlaces que comparten:
- la misma estructura
- la misma semntica
- Todos los enlaces de una asociacin conectan objetos de las
mismas clases
- Suelen identificarse con los verbos del enunciado del problema
- Las asociaciones suelen ser bidireccionales:
- el nombre de la asociacin binaria suele identificar una
direccin dada, la direccin hacia delante
- a esa asociacin le corresponde otra asociacin inversa
- las dos direcciones tienen el mismo significado, hacen
referencia a la misma asociacin subyacente
- la implementacin no tiene por qu ser bidireccional
- No deben representarse como punteros (atributos de un objeto
que tienen como valor otro objeto): la asociacin no es parte de
ningn objeto, sino que depende de los dos
- Todas las conexiones entre clases deben modelizarse como
asociaciones
- Por su naturaleza, las asociaciones violan el encapsulamiento de
la informacin en clases
18
REPRESENTACION DE ASOCIACIONES
- Diagrama de una clase de asociaciones
Pas
capital
nombre
Ciudad
nombre
Diagrama de instancias:
(Pas)
Espaa
(Pas)
capital
capital
Francia
(Ciudad)
Madrid
(Ciudad)
Pars
- cada enlace puede etiquetarse con el nombre de la asociacin

- Normalmente, las clases se ordenan para su lectura de izquierda
a derecha
19
N-ARIEDAD DE LAS ASOCIACIONES

- Las asociaciones pueden ser binarias, ternarias o de orden
superior
- La mayora son binarias
- Las ternarias tambin pueden diagramarse:
Proyecto
Lenguaje
Persona
- El nombre de la asociacin puede escribirse como etiqueta junto

a la correspondiente salida del rombo de conexin
20
MULTIPLICIDAD DE LAS RELACIONES

- Slo la consideraremos para las asociaciones binarias
- Podemos especificar cuntas instancias de una clase pueden
relacionarse con cada instancia de otra clase:
- Relaciones uno-a-uno (pas-capital)
- Relaciones uno-a-muchos
- Relaciones muchos-a-muchos
- ...
- Es un aspecto de la modelizacin cuyo estudio puede dejarse
para las ltimas fases
- Su consideracin suele ayudar a elicitar supuestos ocultos
21
REPRESENTACIN DE LA CARDINALIDAD
DE LAS RELACIONES
- Se utilizan terminadores sobre el conector para especificar
valores habituales de la multiplicidad:
- uno-a-uno: sin marca
- muchos (cero o ms):
Ejemplo: una persona puede tener 0 o ms coches:
Persona
Coche
posee
- opcionalidad (cero o uno):

Ejemplo: una persona puede tener o no un marcapasos:
Persona
Marcap..
posee
22
REPRESENTACIN DE LA CARDINALIDAD
DE LAS RELACIONES (2)
- Cuando es necesario, se utilizan etiquetas numricas:
- 1+ : uno o ms
- 3-5 : de 3 a 5
- 2, 4, 18 : 2, 4 o 18
- Si los objetos del extremo con multiplicidad muchos de una
asociacin deben tener un orden explcito, se indicar aadiendo
la etiqueta {ordenado}
- Cualificador: atributo especial que reduce la multiplicidad
efectiva de una asociacin
- es una forma de asociacin ternaria
- se expresa como una etiqueta dentro de un pequeo
recuadro adosado al extremo del multiplicidad muchos
23
ATRIBUTOS DE LOS ENLACES

- Son propiedades de los enlaces de una asociacin
- Cada atributo de enlace tiene un valor para cada enlace
accesible-por
Fichero
Usuario
tipo de permiso
(leer/escribir/ejecutar)
Persona
nombre
DNI
direccin
trabaja para
Empresa
nombre
CIF
direccin
puesto
salario
- Los atributos puesto y salario podran asociarse a la clase
Persona (la clase con multiplicidad muchos), lo que no sera
posible en relaciones muchos-a-muchos
24
ATRIBUTOS DE LOS ENLACES (2)

- Si se incluyen estos atributos en una clase de objetos, la
flexibilidad se reduce si, posteriormente, la multiplicidad de la
asociacin cambia
equipo
portero
ao
tiros parados
goles encajados
25
CLASES DE ASOCIACIONES
- Cada enlace puede considerarse como una instancia de una clase
de asociaciones
- El diagrama de los atributos de los enlaces puede tener, adems,
nombre y operaciones
- Resulta til modelizar una asociacin como una clase si los
enlaces:
- pueden participar en asociaciones con otros objetos y/o
- estn sujetos a operaciones
equipo
usuario
mquina
autorizacin
prioridad
privilegios
abrir sesin
26
ROLES
- Cada extremo de una asociacin es un rol
- Cada rol tiene un nombre que identifica el objeto o conjunto de
objetos asociado con el objeto o conjunto de objetos del otro
extremo
empleado compaa
persona
contratante
trabaja-para
- Su uso es opcional, y puede utilizarse adems de, o en vez de, el

nombre de la asociacin
- Es obligatorio utilizarlos si la asociacin se da entre dos objetos
de la misma clase
- Es aconsejable para distinguir dos asociaciones entre el mismo
par de clases
27
AGREGACIN
- forma especial de asociacin
- relacin parte-todo o es-parte-de
- los objetos que representan los componentes se asocian con un
objeto que representa todo el compuesto
- propiedades:
- transitividad
- antisimetra
- propagacin a algunas partes de algunas propiedades del
compuesto
- Representacin:
documento <>
prrafo<>
oracin
28
GENERALIZACIN Y HERENCIA
- Recursos para compartir semejanzas entre clases, manteniendo
las diferencias
- Generalizacin: Relacin entre una clase y una versin menos
refinada de ella
- Es una relacin is-a
- la relacin inversa es la de especializacin
- la clase ms general es la superclase y la menos general la
subclase
- Asignamos a la superclase los atributos y operaciones comunes
al grupo de sus subclases
- Decimos que cada subclase hereda las caractersticas de su
superclase
- Generalizacin, especializacin y herencia son relaciones y
procesos transitivos
- una clase es antecesora de otra si es una de sus superclases
- una clase es sucesora de otra si es una de sus subclases
- Las subclases aaden sus propios atributos y operaciones a los
heredados de sus antecesoras
- Los nodos terminales del arbol jerrquico son las instancias
(objetos) de las subclases ms bajas del rbol. Estas instancias
heredan todos los atributos y operaciones de sus clases
antecesoras.
- En ocasiones, una subclase puede especificar un valor de un
atributo o una operacin, aunque le vengan suministrados por sus
superclases:
- los valores por defecto de los atributos
- los mtodos de las operaciones
- Normalmente, nunca se modifican las signaturas.
29
REPRESENTACIN DE LA GENERALIZACIN
- tringulo que conecta una superclase con sus subclases:
Motor
tipo de energa
Elctrico
Combustin
Vapor
tipo de combustible
Gasolina
Gasoil
- la etiqueta junto a cada tringulo es un discriminador que indica

qu propiedad de un objeto est siendo abstrada por la relacin
de generalizacin
30
MDULOS
- Un mdulo es un agrupamiento de clases, asociaciones y
generalizaciones
- Se especifican o definen en funcin del problema a modelizar
- Cada modelo de objetos puede dividirse en mdulos para
facilitar su manipulacin y comprensin
- Los nombres de clases y de asociaciones deben ser nicos dentro
de cada mdulo y, en la medida de lo posible, tambin dentro del
modelo de objetos completo
- Los mdulos se interconectan haciendo referencias a la misma
clase
- Es conveniente que haya menos enlaces intermdulo que
intramdulo
- Cada mdulo tiene un nombre asignado
31
HOJAS
- Cada mdulo se representa en una hoja separada
- Si el mdulo es complejo, puede dividirse en una serie de hojas,
cada una de las cuales se numera, indicando el mdulo al que
pertenece.
- Cada asociacin o generalizacin aparece en una sola hoja
- Las clases pueden aparecer en varias hojas
- Para conectar las hojas entre s se utilizan copias de las mismas
clases. Las hojas hacen referencia a otras mediante un cdigo
encerrado en un crculo, y situado junto al smbolo de una clase:
A
A
Hoja 1
Mdulo 3
Hoja 2
Mdulo 3
32
Modelizacin Dinmica
Referencias:
Rumbaugh, 91
D. Harel(1987) Statecharts: a visual formalism for complex
systems, Sc. of Comp. Prog. 8, 321-274
D. Harel (1988) On visual formalisms, Comm. ACM, 31, 5, 514530
Hopcroft, J. E., Ullman, J. D. (1979): Introduction to Automata
Theory, Languages and Computation, Addison-Wesley
Reisig, W. (1985), Petri Nets: An Introduction, Springer
33
MODELIZACIN DINMICA
- Cambios de los objetos y sus relaciones en el tiempo
- Control: aspecto de un sistema que describe la secuencia de
operaciones que tiene lugar en respuesta a estmulos externos, sin
tener en cuenta qu hacen las operaciones, sobre qu operan, y
cmo estn implementadas
- Conceptos dinmicos fundamentales:
- sucesos (events): estmulos externos
- estados (conjunto de valores de objetos)
- Los programas no interactivos tienen un modelo dinmico
trivial, ya que su objetivo consiste en computar una funcin
- Diagrama de estados:
- red de estados y eventos que representa transiciones de
estados a lo largo del tiempo
- representacin grfica de las mquinas de estado finito
- Hay un diagrama de estados por cada clase que tenga un
comportamiento dinmico relevante. No todas las clases lo
necesitan
- Cada mquina de estados se ejecuta concurrentemente, y puede
cambiar de estado de forma independiente
- Los diversos diagramas de estado de cada clase se combinan
mediante sucesos compartidos. Hay que comprobar la
consistencia
34
SUCESOS
- Algo que tiene lugar en un instante temporal determinado
- Cada suceso es nico y no tiene duracin
- Pueden estar causalmente relacionados entre s, o no (sucesos
concurrentes)
- Si no estn causalmente relacionados entre s, su ordenacin es
irrelevante
- Constituyen una transmisin de informacin unidireccional de
un objeto a otro
- El envo de un suceso desde un objeto a otro no incluye
necesariamente una rplica
- La rplica sera otro suceso
- No es como la llamada a una subrutina
- La granularidad de los sucesos depende del problema
- Clases de sucesos que indican que existe una estructura y una
conducta comn
- Esta estructura es jerrquica, igual que la de las clases de objetos
- Casi todas las clases de sucesos tienen atributos que indican la
informacin que transportan (se representan entre parntesis a
continuacin de la etiqueta del suceso)
- Pueden representarse como operaciones sobre el modelo de
objetos
35
ESCENARIOS
- Un escenario es una secuencia de sucesos que tiene lugar
durante una ejecucin dada
- Su alcance puede variar:
- Todos los sucesos del sistema
- Slo los sucesos generados por determinados objetos del
sistema
- Puede ser un registro de una ejecucin o un experimento mental
sobre un modelo propuesto
- Despus de describir un escenario, hay que identificar al emisor
y receptor de cada suceso
- La construccin de diagramas de estado comienza por la
identificacin de escenarios
36
EJEMPLO DE ESCENARIO
Ej. de diagrama de seguimiento (traza) de eventos: Llamada
telefnica
Persona que llama
Lnea telefnica
Persona llamada
levanta el receptor
comienza el tono de marcar
marca el 1er nmero
termina el tono de marcar
marca el 2 nmero
...
marca el ltimo nmero
suena el tono de llamada el timbre de llamada suena
leva el rec
el tono de llamada se para el timbre de llamada se para
telefonos conectados
telf con
...
...
cuelga
cuelga el telfono
fin de la conexin
fin
- El tiempo avanza de arriba abajo
- Slo se representa la secuencia, no los intervalos reales
- Se pueden enviar sucesos concurrentes
- Se pueden enviar ms de un suceso seguido
37
ESTADOS
- Un estado es una abstraccin de los valores de los atributos y de
los enlaces de un objeto
- En un estado se agrupa un conjunto de valores de acuerdo con
propiedades que afectan al comportamiento de alto nivel del
objeto
- No tienen que especificarse todos los atributos del objeto, slo
los relevantes
- La granularidad de los estados depende del problema
- El estado especifica cul ser la respuesta del objeto a los
sucesos de entrada
- La respuesta de un objeto a un suceso puede variar
cuantitativamente en funcin de los valores de sus atributos, pero
es cualitativamente la misma para todos los valores dentro del
mismo estado, y puede ser cualitativamente diferente para valores
en diferentes estados
- La respuesta de un objeto a un suceso puede incluir una accin o
un cambio de estado del objeto
- El estado representa el intervalo entre dos sucesos recibidos por
un objeto
- El estado depende de la secuencia de sucesos que ha recibido
anteriormente, aunque en muchos casos los sucesos anteriores
estn escondidos por los sucesivos
- El estado tiene una duracin, y a veces se asocia con una
actividad continua
38
ESTADOS (2)
- Mientras que un suceso separa dos estados, un estado separa dos
sucesos
- A veces se asocia un estado con el valor de un objeto que
satisface una condicin determinada
- En el caso ms simple, cada valor de un atributo define un
estado distinto
- Al definir estados, ignoramos los atributos que no afectan al
comportamiento del objeto, y colocamos en un solo estado todas
las combinaciones de valores de atributos y enlaces que
responden de la misma forma a los sucesos
- Especificacin del estado:
- nombre
- descripcin
- secuencia de sucesos que produce el estado
- condiciones que caracterizan el estado
- sucesos aceptados por el estado:
- suceso
- accin
- estado siguiente
- En la medida en que un enlace puede ser considerado como un
objeto, puede tener un estado.
39
DIAGRAMAS DE ESTADO
- Describe el comportamiento de una clase de objetos
- Puesto que todas las instancias de una clase comparten el
mismo comportamiento, todas comparten el mismo diagrama
de estado
- Relacionan estados y sucesos
- El estado siguiente depende del suceso y del estado actual
- Transicin: cambio de estado causado por un suceso
- Grafo dirigido cuyos nodos son estados y los arcos estn
etiquetados con los sucesos que causan la transicin, sus
(atributos), las [condiciones], y las /acciones
- Camino: secuencia de sucesos (o estados)
- Cada estado no explicita totalmente todos los valores del objeto
- Cada instancia estar en un estado, en funcin de cules sean los
valores de sus atributos
- Cada objeto es independiente de los dems, y procede a su
propio ritmo
- El modelo dinmico es un conjunto de diagramas de estado que
interactan entre s mediante sucesos compartidos
40
DIAGRAMAS DE ESTADO (2)

- los diagramas pueden representar:
- ciclos de vida abiertos:
- puede ser considerado como una diagrama de estado
subrutina, que puede ser referenciado en varios lugares de
un diagrama de de nivel superior
- tiene estado inicial () y estado final (~), que
pueden estar etiquetados
- el estado inicial se establece cuando el objeto se crea
- cuando se entra en el estado final, el objeto se
destruye
- bucles cerrados
- Forma general:
suceso1(atributos)[condicin]/accin
Estado1
Estado 2
hacer: Actividad1
hacer:Actividad2
- Ejemplo simple: Ajedrez

Init
Juegan blancas
mueven
negras
mueven
blancas
Juegan negras
jaque-mate
ahogo
ahogo
jaque-mate
~ Blancas ganan
~ Tablas
~ Negras ganan
41
CONDICIONES
- Son funciones booleanas de valores de objetos
- Una condicin es vlida durante un intervalo
- Un estado es definible en trminos de una condicin
- Las condiciones pueden utilizarse como guardas sobre
transiciones
- Una transicin guardada dispara si su suceso ocurre
- Una condicin guardada sobre una transicin se expresa
como una expresin booleana encerrada entre corchetes
detrs del nombre del suceso
- Ejemplo:
tiempo [coches en izq N/S]
abrir recto N/S
abrir giro izq. N/S

tiempo[no hay coches izq. E/W]
tiempo
tiempo
tiempo[no hay coches izq. E/W]
abrir giro izq. E/W
abrir recto E/W

tiempo [coches en E/W]
42
OPERACIONES
- No basta con describir patrones de sucesos
- Una descripcin conductual de un objeto debe incluir lo que el
objeto hace para responder a los sucesos (operaciones asociadas a
los estados o a las transiciones)
- Actividades:
- operaciones con duracin
- asociadas a un estado
- operaciones continuas (visualizar algo) o secuenciales
- la actividad comienza cuando se entra en un estado, y
termina cuando un suceso hace salir de l
- Representacin:
hacer:
- Acciones:
- operaciones instantneas
- asociadas con un suceso
- su estructura interna no es relevante a efectos de la
modelizacin del control
- tambin pueden representar operaciones internas de
control:
- establecer atributos
- generar otros sucesos (p.ej., incrementar un
contador)
- diagramacin:
- precedido de /
- a continuacin de la condicin de guarda
43
DIAGRAMAS DE ESTADO ANIDADOS

- Las mquinas de estados se estructuran igual que los objetos:
- Generalizacin:
- expansin de las actividades anidadas
- se aaden detalles a las actividades que antes se
describieron a alto nivel
- los estados y los sucesos se colocan en jerarquas de
generalizacin, con herencia de estructura y
comportamiento (igual que la herencia de atributos y
operaciones en clases)
- Agregacin:
- un estado se puede partir en componentes
ortogonales, con interaccin limitada entre ellos
- equivale a la concurrencia de estados
- Con problemas complejos, la nica forma prctica de trabajar
consiste en anidar diagramas
- Las actividades anidadas son diagramas de estado con
transiciones de entrada y salida, igual que las subrutinas
- Se usan estados anidados si la misma transaccin se aplica a
muchos estados
44
EJEMPLO DE DIAGRAMA DE ESTADO

- Mquina expendedora:
introd. monedas/contar
Inactivo
Recoger monedas
introd. monedas/sumar
a contador
cancelar/devolver monedas
[agotado]
seleccionar prod.
[cambio < 0]
hacer: comprobar exist. y
calcular cambio
[cambio=0]
hacer: dispensar producto
[cambio > 0]
hacer: dar cambio
45
EJEMPLO DE DIAGRAMA DE ESTADO (2)

- La actividad dispensar producto puede expandirse en el
siguiente subdiagrama:
z
liberada
liberado
hacer: liberar columna
hacer: liberar paquete
~
- Los sucesos, como seleccionar producto tambin pueden

expandirse:
introd. dgito
hacer: borrar
producto
selecc. producto
hacer: aadir
~
dgito
confirmar
borrar
46
GENERALIZACIN DE ESTADOS
- Los estados pueden tener subestados que heredan las
transiciones de sus superestados
- Cualquier transicin o accin que se aplica a un estado, se aplica
a todos sus subestados, a menos que stos tengan una transicin
especfica
- Los superestados se diagraman mediante una caja redondeada
grande, que contiene todos sus subestados (Harel: contornos)
- Puede haber transiciones de un subestado a otro que est fuera
del contorno
GENERALIZACIN DE SUCESOS
- Los sucesos pueden estar organizados en una jerarqua de
generalizacin, con herencia de los atributos de los sucesos
47
ACCIONES DE ENTRADA Y SALIDA

- En vez de mostrar acciones sobre las transiciones, podemos
asociar las acciones con la entrada o la salida de un estado
- Si todas las transiciones en un estado realizan la misma accin,
no se utiliza
- Siempre que se entra en un estado, mediante una transicin de
entrada, se ejecuta antes la accin de entrada
- Siempre que se sale de un estado, mediante una transicin de
salida, se ejecuta antes la accin de salida
- Si hay varias operaciones sobre un estado, se ejecutan en el
siguiente orden:
- acciones sobre la transicin de entrada
- acciones de entrada
- actividades hacer (pueden ser interrumpidas por
sucesos que causen transiciones a otro estado)
- acciones de salida (tambin se ejecuta si se interrumpe
una actividad hacer)
- acciones sobre la transicin de salida
- Se utilizan si un estado tiene varias transiciones de
entrada/salida , y todas causan la misma accin
48
ACCIONES INTERNAS
- Un suceso puede hacer que se ejecute una accin sin que cambie
el estado
- Si se produce el suceso, su accin se ejecuta, pero no las
acciones de entrad y salida para el estado
- Diferencia con las autotransiciones: stas hacen que se ejecuten
las acciones de entrada y salida
TRANSICIN AUTOMTICA
- Transiciones lambda: transiciones que se disparan cuando se
completa una actividad secuencial
- Se representan mediante una flecha sin etiqueta de suceso
- Cada transicin est condicionada
ENVO DE SUCESOS
- Un objeto puede realizar la accin de enviar un suceso (con sus
atributos) a otro objeto
- Se representa mediante una lnea de puntos desde una flecha de
transicin a otro objeto o clase de objetos (o a una transicin del
diagrama de estados de ese objeto)
- Si un estado puede aceptar sucesos de ms de un objeto, el orden
en que se reciben puede afectar al estado resultante (la condicin
de carrera)
49
CONCURRENCIA
- Cada objeto tiene su propio estado, y su propio diagrama de
estados
- La concurrencia por agregacin de estados es la combinacin de
los estados de todos los diagramas componentes
- Una transicin condicionada de un objeto puede depender de
que otro est en un estado determinado
- Puede darse concurrencia dentro del estado de un objeto si ste
puede dividirse en subconjuntos de atributos o enlaces, cada uno
con su propio subdiagrama
- En este caso, el estado del objeto ser la combinacin de
los estados de cada subdiagrama
SINCRONIZACIN DE ACTIVIDADES CONCURRENTES
- A veces un objeto debe realizar varias actividades a la vez, y
todas ellas deben acabar antes de que el objeto pueda pasar a otro
estado
- Representacin: se subdivide el estado con lneas de puntos, en
cada una de las cuales se coloca una actividad hacer
concurrentes. Las flechas se bifurcan para mostrar la concurrencia
50
Modelizacin Funcional
Rumbaugh, 91;
Yourdon, E. (1989), Modern Structured Analysis, Yourdon Press
De Marco (1979), Structured Analysis and Systems Specification,
Prentice Hall
- Descripcin de la computacin: Qu hace el sistema
(Mod. dinmica: cundo hace el sistema lo que hace)
(Mod. de objetos: a quin hace el sistema lo que hace)
- Describe cmo se derivan los valores de salida de los de entrada,
sin tener el cuenta el orden de la computacin
- Conjunto de diagramas de flujo de datos (DFDs), cuyos
elementos son:
-entradas extenas
- operaciones
- almacenes internos
- salidas externas
- Incluye restricciones entre valores
- Especifica el significado de:
- las operaciones del modelo de objetos
- las acciones del modelo dinmico
- las restricciones del modelo de objetos
- Este modelo funcional es el principal modelo de los programas
no interactivos
- Las BDs tienen un modelo funcional trivial
51
DFDs
- Conjunto de DFDs que especifican el significado de operaciones
y restricciones
- El DFD muestra las relaciones funcionales entre los valores
computados
- muestra el flujo origen-proceso-destino
- ignora la informacin de control (tiempo, decisiones entre
caminos alternativos)
- Contiene:
- procesos: que transforman datos:
- flujos de datos, que mueven datos
- actores: objetos que producen y/o consumen datos
- almacenes de datos: guardan datos pasivamente
- Cada elemento lleva una etiqueta descriptiva
52
DFDS ANIDADOS
- Visin de la descomposicin funcional del sistema en unidades
funcionales
- La estructura de anidamiento forma un rbol
- El nivel ms bajo es el de las funciones primitivas
53
PROCESOS
- Los procesos de nivel ms bajo son funciones puras sin efectos
colaterales
- Un DFD entero es un proceso de alto nivel
- Puede tener efectos colaterales si incluye componentes no
funcionales (almacenes de datos u objetos externos)
- El modelo funcional slo indica los posibles caminos
funcionales, no los que tienen lugar realmente en funcin de la
dinmica del sistema (esto aparece en el modelo dinmico)
- Tienen una o ms entradas y una o ms salidas
- sus entradas y salidas estn etiquetadas con su papel en la
computacin o el tipo de dato
- Slo muestra el patrn de entradas y salidas. La computacin
hay que especificarla
- Un proceso de alto nivel puede expandirse en todo un DFD de
nivel ms bajo
- Los procesos se implementan como mtodos de operaciones
sobre clases de objetos
54
FLUJOS DE DATOS
- Conectan la salida de un objeto o proceso con la entrada de otro
objeto o proceso
- Representa un valor en un punto del proceso
- Los de entrada/salida pueden estar conectados a objetos o no (si
el diagrama es un fragmento del diagrama total)
- El mismo valor puede dirigirse a componentes distintos
- A veces, un valor agregado se descompone en sus componentes,
y cada uno se dirige a un lugar distinto. En este caso, cada flecha
componente se etiqueta
55
ACTORES
- Objeto activo que produce o consume valores
- Estn asociados a las entradas o salidas de un DFD
(terminadores)
- Ej.: el usuario de un programa
- Las acciones de los actores no se representan en el DFD, sino en
el modelo dinmico
ALMACENES DE DATOS
- Objeto pasivo que almacena datos
- Responde a peticiones de almacenamiento y recuperacin de
datos
- Incluye aadir, modificar o borrar elementos
FLUJOS DE CONTROL
- A veces se incluyen en el modelo funcional
- Se representa como una lnea de puntos desde un proceso que
controla a otro controlado
- Puede etiquetarse con el valor de control
56
ESPECIFICACIN DE OPERACIONES
- Los procesos se implementarn como operaciones sobre objetos
- Cada operacin puede especificarse de distintas formas:
- funcin matemtica
- tabla de valores de entrada/salida para conjuntos finitos
pequeos (enumeracin)
- ecuaciones que especifican el output en trminos del
input
- precondiciones y postcondiciones (definicin axiomtica)
- tablas de decisin
- clculo de predicados
- pseudocdigo
- lenguaje natural
- La especificacin incluye:
- nombre de la funcin
- una signatura: la interfase a la operacin
- los argumentos que exige, su nmero, orden y tipos
(entrada)
- los valores que devuelve (nmero, orden y tipos) (salida)
La signatura de todos los mtodos que implementan
una operacin debe coincidir
- una transformacin que define el efecto de una operacin:
- valores de salida como funciones de los valores de
entrada
- efectos colaterales en los objetos sobre los que opera
- restricciones
57
ESPECIFICACIN DE OPERACIONES (2)

Tipos de transformaciones:
- Operaciones de acceso (triviales):
- leen o escriben atributos o enlaces de un objeto
- se derivan de los atributos y asociaciones de una clase del
modelo de objetos
- no se especifican en la fase de anlisis
- en el diseo se distinguen las pblicas de las privadas
- Operaciones no triviales:
- queries:
- no tiene efectos colaterales sobre el estado externamente visible de un objeto
- instantneas
- son atributos derivados
- acciones:
- tienen efectos colaterales en los objetos
- no tienen duracin
- actualizan los atributos bsicos y de los enlaces
- definibles en trminos de estados anterior y posterior
- se derivan de los procesos en el modelo funcional
- actividades
- operaciones con duracin
- slo tienen sentido para los actores
- suelen corresponder a un diagrama de estado en el
modelo dinmico
58
ESPECIFICACIN DE OPERACIONES (3)

- Puede haber valores internos no visibles desde fuera, que son
privados de la operacin y quizs de la clase de objetos
- El estado del objeto puede dividirse entre informacin
externamente visible e informacin interna privada
59
RESTRICCIONES
- Una restriccin expresa la relacin entre:
- dos objetos al mismo tiempo
- diferentes valores del mismo objeto en tiempos distintos
- Puede expresarse como:
- una funcin total (un valor viene definido completamente
por otro)
- una funcin parcial (un valor est restringido por otro,
pero no est completamente definido por l)
- Hay restricciones en los tres tipos de modelos
- Invariantes: restricciones entre valores de un objeto
independientes del tiempo
60
Modelo funcional
Modelo de objetos
- lo que el sistema
tiene que hacer
- procesos
-quin hace: los objetos

- operaciones
- actores
- almacenes
- flujos de datos
- objetos
- objetos
- valores
Modelo dinmico
- secuencia de
ejecucin
61
Anlisis
-------------------------------------------------------------------------------Bibliografa
Shlaer, S. (1988), Object-Oriented Systems Analysis, Yourdon
Press
-------------------------------------------------------------------------------- Primer paso: Formulacin del problema
- Requerimientos obligatorios
- Requerimientos opcionales
- Alcance del problema
- Contexto
- Supuestos
- Requerimientos de eficiencia
- Previsin de extensiones futuras
- Protocolos de interaccin con sistemas externos
- Modelizacin de objetos:
- identificar objetos y clases
- entidades fsicas
- conceptos
- denotados por nombres
- depurar los objetos y clases
- eliminar las clases redundantes, manteniendo la
descripcin ms rica
- eliminar las clases irrelevantes
- precisar o eliminar las clases vagas, confusas o
demasiado amplias
- la modelizacin de un elemento como clase o
atributo depende de cada caso
62
- la modelizacin de un elemento como clase o como

operacin depende de cada caso
- el nombre de una clase debe reflejar su naturaleza, y
no su papel
- preparar diccionario de datos
- cada entrada corresponde a la definicin de una
clase u objeto
- alcance dentro del problema
- supuestos o restricciones de su uso
- descripcin de asociaciones, atributos y operaciones
- identificar asociaciones entre objetos (incluyendo
agregaciones)
- en vez de referir atributos a clases, utilizar
asociaciones
- asociaciones se expresan como verbos de
posicionamiento fsico, comunicacin, acciones
dirigidas, propiedad, satisfaccin de condiciones,
...
- la distincin entre asociaciones y agregaciones no es
muy importante ahora
- depurar las asociaciones incorrectas:
- normalmente las asociaciones son binarias
- - redundancias: algunas asociaciones pueden ser
definidas a partir de otras (asociaciones
dependientes)
- - pueden mantenerse para mayor facilidad del
diseo, pero se marcan con lneas de puntos
- - en la medida de lo posible, clases, atributos y
asociaciones deberan representar informacin
independiente
- nombres claros y descriptivos (qu, y no cmo o
por qu)
- papel que una clase en una asociacin desempea
desde el punto de vista de la otra clase
- cualificador: nombre ms contexto de uso
- multiplicidad: menos importante durante el
anlisis
63
- identificar atributos y enlaces

- propiedades de objetos individuales
- no son objetos
- nombres seguidos de frases posesivas (el color de
mi coche)
- adjetivos
- no llevar demasiado lejos la bsqueda de atributos
- omitir o identificar los atributos derivados (edad, de
fecha de nacimiento y fecha actual)
- depurar los atributos
- si la existencia independiente de una entidad es
ms importante que su valor, entonces es un
objeto
- si el valor de un atributo depende de un contexto
determinado, entonces el atributo es un
cualificador
- a veces los nombres se modelizan mejor como
cualificadores que como atributos de los objetos.
- Si no dependen del contexto, y pueden no ser
nicos, son atributos
- si una propiedad depende de la presencia de un
enlace, entonces la propiedad es un atributo del
enlace, y no del objeto relacionado
- si un atributo describe el estado interno de un
objeto que es invisible desde fuera de ese objeto,
entonces eliminarlo
- eliminar los atributos menos importantes
- organizar y simplificar clases de objetos utilizando la
herencia
- bottom up: generalizar aspectos comunes de las
clases, formando superclases
- si aparece repetidamente el mismo nombre de
asociacin con el mismo significado, intentar
generalizar las clases asociadas
- top-down: refinar las clases formando subclases
especializadas: adjetivos del nombre de la clase
64
- verificar la existencia de caminos de acceso para las

queries
- iterar y refinar el modelo
- objetos que faltan
- clases innecesarias
- asociaciones que faltan
- asociaciones innecesarias
- asociaciones incorrectas
- atributos incorrectos
- agrupar las clases en mdulos
- dividir los diagramas en hojas
- mdulo: conjunto de clases (una o ms hojas) que
contiene un subconjunto lgico del modelo total
- organizacin de mdulos:
- organizacin en estrella
- mdulo central que contiene la estructura global
de las clases de alto nivel
- otros mdulos expanden cada clase de alto nivel
en una jerarqua de generalizacin, y aaden
asoociaciones a clases adicionales de bajo nivel
- Modelizacin dinmica
- Preparacin de escenarios
- escenario: secuencia de sucesos
- cada suceso tiene un actor (sistema,
experimentador) y unos parmetros
- parmetros del suceso: la informacin
intercambiada (puede ser simplemente el hecho de
que el suceso ha ocurrido)
- dilogos tpicos entre:
- experimentador y modelo
- usuario y sistema
- primero dilogos normales, y despus los
especiales (entradas sin valor, con mximos o
mnimos, incompletas, etc.) y las condiciones de
error (valores no vlidos, etc.)
- abortar operaciones o retornar a puntos anteriores
- Frecuente distincin entre:
65
- lgica de la aplicacin (lo que interesa en el

modelo dinmico)
- interfase de usuario
- Identificar los sucesos entre objetos
- agrupar bajo el mismo nombre los sucesos que
tengan el mismo efecto en el flujo de control.
- asignar cada tipo de suceso a las clases de objetos
que lo envan y lo reciben (como suceso de entrada
y de salida)
- Preparar una traza de sucesos para cada escenario
- cada columna (objeto) de la traza identifica los
sucesos que afectan a un objeto determinado
- un diagrama de flujo de sucesos muestra los sucesos
entre clases, sin tener en cuenta su secuencia:
- Construir un diagrama de estados
- para cada clase de objetos con comportamiento
dinmico no trivial
- cada escenario o traza de sucesos corresponde a un
camino en el diagrama de estados
- Operativa de construccin:
- Tomamos los diagramas de traza de sucesos que
afectan a la clase que estamos modelizando.
- Tomamos una traza que corresponde a una
interaccin tpica, y slo tenemos en cuenta los
sucesos que afectan a un solo objeto.
- Colocamos los sucesos en un camino cuyos arcos
estn etiquetados con los sucesos de entrada y
salida que encontramos en una columna de la
traza.
- El intervalo entre dos sucesos es un estado.
- Dar un nombre (significativo, si es posible) a
cada estado.
- El diagrama inicial ser una secuencia de sucesos
y estados.
- Si el escenario puede repetirse indefinidamente,
cerrar el camino en el diagrama de estados
66
- Revisar los bucles. Favorecerlos, y revisar sus

salidas
- insertar otros escenarios en el diagrama de
estados
- Despus de los sucesos normales, los lmites o
especiales, y los de error
- Si hay interacciones complejas con entradas
independientes, podemos construir el modelo
dinmico utilizando diagramas de estado anidados.
- Comprobar los sucesos entre objetos para verificar la
consistencia
- Modelizacin funcional
- Identificar los valores de entrada y salida
- son los parmetros de los sucesos entre el sistema y
el mundo externo
- Construir DFDs que muestren las dependencias
funcionales
- normalmente se construye por capas o niveles
- recoger valores
- computar valores
- generar salida
- proceder de atrs hacia delante: normalmente es ms
difcil identificar todos los usos de una entrada que
identificar todas las fuentes de una salida
- expandir los procesos no triviales en DFDs de bajo
nivel
- Describir las funciones en el lenguaje adecuado
- preferible la descripcin declarativa: especificacin
de las relaciones entre entrada y salida y entre los
valores de salida: no implica una implementacin
- si es ms fcil que la declarativa, descripcin
procedural: especificacin de un algoritmo
- identificar las restricciones
- dependencias funcionales entre objetos no
relacionados mediante una dependencia de entradasalida
67
- restricciones entre dos objetos al mismo tiempo,

entre instancias del mismo objeto en tiempos
distintos (un invariante) o entre instancias de
objetos distintos en tiempos distintos
- las precondiciones sobre las funciones son
restricciones que deben satisfacer los valores de
entrada, y las postcondiciones son restricciones que
deben satisfacer los valores de salida
- hay que especificar los tiempo o condiciones en los
que valen las restricciones
- Especificar los criterios de optimizacin
- valores que hay que maximizar, minimizar, u
optimizar
- si hay criterios de optimizacin en conflicto, indicar
los criterios de decisin.
- Especificacin de operaciones
- del modelo de objetos
- lectura y escritura de valores de los atributos y
enlaces de asociacin
- de los sucesos
- cada suceso enviado a un objeto corresponde a una
operacin sobre l
- de las acciones de estado y de las actividades
- de las funciones
- cada funcin corresponde a una operacin sobre uno
o ms objetos
- las funciones (excepto las de acceso) se organizan
en operaciones sobre objetos
- genricas
- operaciones que no dependen de un sistema
concreto ni estn sujetas a un orden de ejecucin
determinado, pero que son significativas por s
mismas
- simplificacin de operaciones: eliminar redundancias y
variaciones. Utilizar la herencia para reducir el nmero de
operaciones distintas. Introducir nuevas superclases.
- Iteracin del Anlisis
68
--------------------------------------------------------------------------------
69
Diseo del sistema

-------------------------------------------------------------------------------Bibliografa:
Yourdon, E., Constantine, L. (1989): Structured Design, Prentice
Hall
Page-Jones, M. (1988): The Practical Guide to Structured Systems
Design, Prentice Hall
-------------------------------------------------------------------------------- arquitectura del sistema:
- organizacin global del sistema en componentes llamados
subsistemas
- Organizacin del sistema en subsistemas
- Cada subsistema contiene aspectos del sistema que
comparten alguna propiedad comn o funcionalidad
semejante
- Un subsistema no es un objeto ni una funcin, sino un
empaquetamiento de clases, asociaciones, operaciones,
sucesos y restricciones que estn interrelacionados y que
tienen un interfase bien definido con otros subsistemas
- normalmente un subsistema se identifica con los
servicios que proporciona
- un servicio es un grupo de funciones relacionadas que
comparten algn objetivo comn, p. ej., clculo
aritmtico, procesamiento de entrada/salida, etc.
- las operaciones internas de cada subsistema pueden ser
diseadas independientemente de las de los dems
- El diseo del sistema debe ser tal que la mayor parte de
las interacciones se produzcan dentro de cada subsistema.
- cada subsistema puede descomponerse en subsistemas
ms pequeos. Los subsistemas de nivel ms bajo se
llaman mdulos
- La relacin entre subsistemas puede ser:
- cliente-servidor
70
- el cliente llama al servidor, que realiza algn

servicio y devuelve el resultado. El cliente
conoce el interfase del servidor, pero no a la
inversa
- entre iguales (peer-to-peer)
- cada subsistema puede llamar a los dems. A
cada comunicacin no le sigue necesariamente
una respuesta inmediata. Cada subsistema
debe conocer el interfase de los dems. Dada
la posible existencia de bucles, su dificultad es
mayor.
- La descomposicin de sistemas en subsistemas puede
organizarse como una secuencia de capas horizontales o
de particiones verticales. Tambin pueden adoptarse
enfoques hbridos
- Capas
- Un sistema de capas (layered system) es un conjunto
de niveles tal que cada uno de ellos est construido
en trminos de los que se encuentran por debajo de
l, y constituye la base para la construccin de los
que se encuentran por encima de l
- El nivel superior es el sistema deseado y viene
especificado en la formulacin del problema. El
nivel inferior son los recursos disponibles. Los
niveles intermedios se introducen:
- para eliminar el salto conceptual entre los
niveles
- para aumentar la portabilidad del sistema
- filosofa cliente-servidor: cada capa conoce los
servicios proporcionados por capas inferiores, pero
no a la inversa
- dos arquitecturas alternativas:
- cerrada: cada nivel est construido
exclusivamente en trminos del nivel
inmediatamente inferior. Reduce las
dependencias entre niveles y los cambios son
71
ms fciles, puesto que el interfase slo afecta al

nivel siguiente.
- abierta: cada nivel puede utilizar cualquier otro
nivel inferior. Reduce la necesidad de redefinir
operaciones en cada nivel, pero no respeta el
principio del ocultamiento de informacin. Los
cambios de un subsistema pueden afectar a
cualquier otro sistema superior. Menos robustez.
- Particiones
- Divisiones del sistema en subsistemas
independientes y dbilmente acoplados, cada uno de
los cuales proporciona un servicio especfico
- el conocimiento de los dems es superficial, y las
dependencias son mnimas
- Topologas del sistema
- tras la identificacin de los subsistemas del nivel
superior, se construye un DFD que muestra el flujo
de informacin entre los subsistemas
- secuencia, estrella, ...
- Identificar las concurrencias inherentes
- una hebra de control es un camino a travs de un conjunto
de diagramas de estado slo est activo un objeto a la vez.
- Una hebra permanece en un diagrama de estado hasta que
un objeto enva un suceso a otro objeto y queda a la
espera de otro suceso. La hebra pasa al receptor del
suceso hasta que, en su caso, sta vuelve al objeto
original. La hebra se parte si el objeto enva un evento y
contina la ejecucin
- En cada hebra de control, slo est activo un objeto a la
vez. Se implementan como tareas.
- dos objetos son inherentemente concurrentes si pueden
recibir sucesos al mismo tiempo sin interactuar
- hay que identificar qu objetos deben estar activos de
forma concurrente, y cules tienen una actividad que es
mutuamente excluyente
72
- si los sucesos no estn sincronizados, no pueden

colocarse en la misma hebra (thread) de control (tarea).
Si su actividad es mutuamente excluyente, pueden
colocarse en la misma tarea.
- los sistemas operativos multitarea pueden manejar
subsistemas inherentemente concurrentes. No es
necesario asignarlos a diferentes unidades hardware
- aunque todos los objetos son conceptualmente
concurrentes, muchos son interdependientes
- muchos objetos pueden colocarse en la misma hebra de
control, examinando los diagramas de estado de cada
objeto y el intercambio de informacin entre ellos
- Asignar subsistemas a los procesadores y las tareas
- Para cada subsistema, se evalan los requerimientos de
rendimiento y los recursos necesarios
- Se escoge la implementacin hard o soft para cada
subsistema
- Se asignan subsistemas soft a los procesadores para
satisfacer los requerimientos y minimizar la
comunicacin interprocesadores
- Se establece la conectividad de las unidades fsicas que
implementan los subsistemas
- Se asignan tareas a los procesadores, teniendo en cuenta
localizacin fsica, tiempo de respuesta o carga de
computacin
- Se determina la conectividad fsica: topologa de
conexin fsica, topologa de las unidades repetidas,
teniendo en cuenta las pautas de entrada de datos y el
algoritmo paralelo para procesarlos (secuencia lineal,
matriz, rbol, estrella)
- Se decide la forma y tipo de los canales de conexin
(ancho de banda, latencia), y los mecanismos de
interaccin (sncronos, asncronos o de bloqueo) y
protocolos de conexin
- Elegir un enfoque para la gestin de los almacenes de
datos
73
- los almacenes de datos internos y externos constituyen

lneas de separacin entre subsistemas con interfases bien
definidos
- el uso de bases de datos tiene ventajas e inconvenientes
- Manejar el acceso a los recursos globales
- dispositivos, espacio de almacenamiento o visualizacin,
nombres lgicos, bases de datos compartidas, etc.
- cada recurso debe ser posedo por un objeto guardn que
controla su uso, total o parcial, mediante el uso de
bloqueos (locks)
- Escoger la implementacin de control en el software
- en el anlisis, las interacciones aparecen como sucesos
entre objetos
- dos tipos de control:
- externo: flujo de sucesos externamente visibles
entre los objetos
- tipos de control de sucesos externos:
- secuencial
- guiado por procedimientos (sist. ...)
- el procedimiento pide una entrada y
queda a la espera de recibirla
- fcil implementacin si hay
alternancia regular de sucesos de
entrada/salida
- malo para las entradas asncronas,
sistemas de control, interfases de
usuario flexibles
- C++
- guiados por sucesos (sist. ...)
- el lenguaje dispone de un dispatcher o
monitor que proporciona el control
- los procedimientos ests asignados a
sucesos, y el dispatcher los llama
cuando ocurre el suceso (callback)
- los procedimientos devuelven control
al dispatcher
74
- ms difcil de implementar, pero ms

flexible
- X-Windows
- concurrente (sist....)
- ejecucin concurrente de tareas
- sucesos almacenados en una cola
- resolucin de conflictos de planificacin entre
tareas
- Ada
- Control interno
- flujo de control dentro de un proceso
- slo existe en la implementacin. Tipos:
- llamadas a procedimientos
- llamadas cuasi-concurrentes entre tareas
(corutinas, procesos lighweight ). Tiene
varios espacios de direccionamiento y
mltiples pilas de llamada, pero slo puede
estar activa una hebra de control a la vez
- llamadas concurrentes entre tareas
- Otros:
- programacin basada en reglas, programacin
lgica...
- no control explcito, sino especificacin
declarativa con reglas de evaluacin
implcitas, quizs no declarativas
- Manejar las condiciones lmite
- inicializacin: constantes, parmetros, variables globales,
tareas, objetos guardianes, jerarqua de clases
- terminacin: liberacin de recursos
- fallo: errores del programa (bugs), errores de entrada,
agotamiento de recursos, fallo externo
- Establecer las prioridades
- elegir entre objetivos deseables pero incompatibles
- prototipaje rpido
- Estructuras arquitectnicas habituales
- Transformacin batch
75
- la transformacin de datos de todo un conjuntode

entrada se ejecuta una sola vez
- transformacin secuencial desde la entrada hasta la
salida
- ej.: compilacin
cd. fuente
An. lxico
list. tokens
rbol gr.
An. gramatical
An. semntico
(parsing)
arbol
gr. ampliado
cd. objeto
cd. optimiz.
cdigo
Form. c. obj .
Optimizacin
Generac. cd .
- su modelo de estados es trivial
- lo ms importante es el modelo funcional, que
especifica cmo los valores de entrada se
transforman en los de salida
- metodologas de DFD y descomposicin funcional
- etapas:
- partir la transformacin en fases
- diagrama del sistema: DFD
- definir clases intermedias para los flujos entre
cada para de fases sucesivas. Cada conjunto de
clases forma un modelo de objetos, acoplado
dbilmente con los de las fases contigas
- expandir cada fase hasta que las operaciones sean
fcilmente
implementables
- optimizar el diagrama final
- Transformacin continua
- la transformacin de datos se ejecuta de forma
continuada a medida que las entradas van
cambiando
76
- etapas :
- disear el DFD
- definir objetos intermedios
- propagar los efectos intermedios de cada cambio
como actualizaciones incrementales a lo largo de
toda la secuencia
- optimizar la secuencia
- Interfase interactivo
- sistema dominado por interacciones externas
- ergonoma del dilogo con el usuario
- etapas:
- separar los objetos del interfase de los que
definen la semntica de la aplicacin
- si es posible, utilizar objetos predefinidos para
interactuar con agentes externos
- utilizar el modelo dinmico como estructura del
programa. Mejor, control guiado por sucesos.
- separar los sucesos fsicos de los lgicos
(mltiples sucesos fsicos)
- especificar completamente las funciones de la
aplicacin que son invocadas por el interfase
- Simulacin dinmica
- sistema que simula objetos cambiantes del mundo
real
- muchos objetos distintos que se actualizan
continuamente
- etapas:
78
- identificar actores, objetos activos del mundo

real, en el modelo de objetos. Los actores tienen
atributos que se actualizan peridicamente
- identificar sucesos discretos: interacciones
discretas con el objeto. Pueden implementarse
como operaciones sobre el objeto
- identificar dependencias continuas. Los atributos
del mundo real pueden depender de otros o variar
continuamente respecto al tiempo u otros
parmetros. Estos atributos hay que actualizarlos
peridicamente utilizando tcnicas de
aproximacin numrica para minimizar los
errores de clculo
- normalmente, la simulacin se ejecuta sobre un
escalamiento temporal dado. Los procesos
continuos se aproximan mediante pasos discretos
- Sistema de Tiempo real
- sistema dominado por restricciones temporales
estrictas
- determinar el escenario del peor caso
- Gestor de Transacciones
- sistema que almacena y actualiza datos, incluyendo
normalmente acceso concurrente desde distintos
lugares
- etapas:
- establecer las correspondencias entre el modelo
de objetos y la base de datos
- determinar los recursos que no pueden
compartirse (unidades de concurrencia)
- determinar los recursos a los que debe accederse
a la vez durante la transaccin (unidades de
transaccin)
- disear el control de la concurrencia para las
transacciones
--------------------------------------------------------------------------------
79
Diseo de objetos
-------------------------------------------------------------------------------Aho, A., Hopcroft, J., Ullman, J. (1975), The Design and Analysis
of Computer Algorithms, Addison-Wesley
Sedgewick, R. (1983), Algorithms, Addison-Wesley
Gonnet, G. H. (1984), Handbook of Algorithms and Data
Structures, Addison-Wesley
Ullman, J. (1988) Principles of Database and Knowledge-Based
Systems, Comp. Sc. Press
Meyer, B. (1988), Object-Oriented Software Construction,
Prentice Hall Int.
-------------------------------------------------------------------------------- Transformacin de la estructura lgica del modelo de anlisis
en una organizacin fsica de un programa
- Papel central del modelo de objetos en el diseo
- Combinar los tres modelos para obtener las operaciones sobre
clases
- el modelo de objetos puede no mostrar las operaciones
- las acciones y actividades del modelo dinmico y los
procesos del modelo funcional se convierten en
operaciones asociadas a las clase del modelo de objetos
- Si asociamos una operacin con los sucesos que un objeto
recibe, el algoritmo que implementa la operacin depende
del estado del objeto
- el cdigo que implementa el algoritmo debe contener una
sentencia CASE que especifique el estado
- Si tenemos un par de sucesos que representan una accin
sobre otro objeto y la devolucin del resultado de la
accin, podemos representarlos como una operacin
- una accin o actividad puede expandirse en un DFD
completo del modelo funcional
- los procesos en el cuerpo del DFD representan el
cuerpo de una operacin
- los flujos son los valores intermedios
80
- hay que convertir la estructura del grafo en una

secuencia lineal de pasos de un algoritmo
- los procesos del DFD constituyen suboperaciones.
Algunas pueden ser operaciones sobre el objeto
original o sobre otros. Para saber a qu objeto se
dirige una operacin:
- si el proceso extrae un valor de un flujo de
entrada, entonces el objetivo es el flujo de
entrada
- si tiene flujos de entrad y salida del mismo
tipo, y el de salida es una versin actualizada
del de entrada, entonces el objetivo es el flujo
de entrada/salida
- si el proceso construye un valor de salida a
partir de varios de entrada, entonces tenemos
una operacin de clase (constructor) sobre la
clase de salida
- si el proceso tiene una entrada de o una salida
a un almacn o un actor, entonces stos son los
objetivos
- Disear algoritmos para implementar las operaciones
- Elegir algoritmos que minimicen el coste de
implementacin de las operaciones
- en muchos casos, la especificacin del modelo
funcional ya constituye un algoritmo suficiente
- Se necesitan algoritmos:
- para implementar funciones para las que no se ha
dado una especificacin procedural (slo
restricciones declarativas)
- para optimizar funciones definidas mediante un
algoritmo sencillo pero poco eficiente
- Criterios de eleccin:
- Complejidad computacional: cmo crece la
demanda de tiempo o de espacio de memoria
respecto al nmero de valores de entrada?
- Facilidad de implementacin y de
comprensibilidad
81
- Flexibilidad
- Ajuste al modelo de objetos
- Seleccionar estructuras de datos apropiadas a los
algoritmos
- instancias de clases contenedoras
- estructuras de datos genricas dadas como libreras:
matrices, listas, colas, pilas, conjuntos, bags,
diccionarios, asociaciones, rboles, colas de
prioridad, rboles, binarios, ...
- Si es necesario, definir nuevas clases y operaciones
internas
- Asignar la responsabilidad de las operaciones a las clases
adecuadas
- mejor a la clase objetivo que a la iniciadora
- el objetivo de la operacin es el objeto cambiado, no
el meramente preguntado
- el objetivo de la operacin es el objeto alrededor del
cual se agrupan en estrella las clases y asociaciones
que intervienen en la operacin
- por defecto, si es slo un objeto el que interviene,
decidir qu objeto realiza la operacin en el mundo
real
- Optimizar los caminos de acceso a los datos
- Aadir asociaciones redundantes para minimizar los
costes de acceso y maximizar la conveniencia
- reordenar ms eficientemente la computacin
- Almacenamiento de atributos derivados para evitar la
recomputacin de expresiones complicadas. Su valor se
puede actualizar de tres formas:
- actualizacin explcita
- recomputacin peridica
- valores activos
- Implementar el control de las interacciones externas
- Para implementar el modelo dinmico de acuerdo con la
estrategia bsica decidida durante el diseo del sistema se
puede:
82
- Definir implcitamente el estado del programa mediante

la asignacin de control dentro de l (Sistema guiado por
procedimientos: enfoque tradicional): Transferencia de
control a una sentencia o rutina en funcin de la entrada
recibida: Tcnica de conversin:
- identificar el camino de control principal o normal.
Construir una secuencia lineal de sentencias que
corresponden a los estados de ese camino
- Identificar los caminos alternativos y convertirlos en
sentencias condicionales
- Identificar caminos hacia atrs que salgan del
camino principal y que se junten despus con l. Se
convertirn en bucles en el programa. Si hay varios
caminos hacia atrs que no se cruzan, se convierten
en bucles anidados en el programa. Los que se
cruzan no se anidan, pueden implementarse
excepcionalmente con gotos.
- los estados y transiciones que queden corresponden
a condiciones de excepcin. Se convertirn en
subrutinas de error, manejo de excepciones
soportado por el lenguaje, o definiciones o
comprobaciones de los flags de estado
- Implementar directamente un mecanismo de mquina de
estados (sistema guiado por sucesos)
- Motor de transiciones que permite ejecutar una
mquina de estados representada por una tabla de
transiciones y acciones
- YACC o LEX (parsers) proporcionan mquinas de
estado explcitas
- Implementar los objetos como tareas concurrentes
- Ajustar la estructura de clases para aumentar la herencia
- Reordenar las clases y operaciones
- ligeras modificaciones de las operaciones y de las
clases pueden permitirnos aumentar la herencia
mediante una sola operacin heredada
- nmero de argumentos de las operaciones
- nombres de los atributos
83
- Abstraer la conducta comn de grupos de clases

- crear superclases con los rasgos compartidos
- Utilizar la delegacin para compartir la conducta cuando
la herencia es semnticamente invlida
- un objeto puede invocar selectivamente funciones
de otra clase
- Disear las asociaciones
- estrategia para implementar las asociaciones
- global o para cada asociacin
- si algunas asociaciones se atraviesan en una sola
direccin, su implementacin se puede simplificar, como
puntero (atributo que contiene la referencia de un objeto)
o conjunto de punteros (dependiendo de su
multiplicidad). Si la asociacin apunta a muchos
ordenados, podemos utilizar una lista en vez de un
conjunto. Una asociacin cualificada con multiplidad
uno puede implementarse como un objeto diccionario
(conjunto de pares de valores que hacen corresponder
valores de seleccin con valores objetivo). Los
diccionarios se pueden implementar mediante hashing.
Con multiplicidad muchos, diccionarios de conjuntos
de objetos
- las asociaciones bidireccionales: como atributos en una
direccin, en ambas, o como un objeto asociacin
distinto de las dos clases (conjunto de pares de objetos
asociados, o triplas para las asociaciones cualificadas, que
se implementan mediante dos objetos diccionario, uno
para cada direccin), dependiendo de la frecuencia de uso
de las asociaciones, de si los accesos superan a las
actualizaciones
- Si una asociacin tiene enlaces, se implementa como una
clase distinta, en la que cada instancia representa un
enlace y sus atributos
- Determinar la representacin de objetos: fcil. Tipos primitivos
o combinaciones de grupos relacionados.
- Empaquetar las clases y asociaciones en Mdulos
- Ocultar la informacin interna
84
- definicin del interfase pblico de cada clase al

mayor nivel de abstraccin posible
- decidir qu atributos de la clase sern accesibles
desde fuera o no (private)
- limitar el alcance de los mtodos y operaciones
- evitar el acceso mediante asociaciones no
conectadas a la clase actual
- evitar aplicar un mtodo al resultado de otro mtodo
- asegurar la coherencia de las entidades
- una entidad, operacin o mdulo es coherente si
est organizado sobre un plan consistente y todas
sus partes se ordenan a un fin comn. Separar los
mtodos estratgicos (policy) de los mtodos que
implementan algoritmos (implementation meth.)
- construir los mdulos fsicos
- Documentar las decisiones de diseo: documento de diseo
-------------------------------------------------------------------------------Implementacin
- Dijkstra, E. W. (1976): A Discipline of Programming, Prentice
Hall
- Kernighan, B. W., Plauger, P. J. (1978), The Elements of
Programming Style, McGraw-Hill
-------------------------------------------------------------------------------- Reusabilidad
- mtodos coherentes: una sola funcin o un solo grupo de
funciones relacionadas
- mtodos pequeos
- mtodos consistentes: los mtodos semejantes deben utilizar
los mismos nombres, condiciones, orden de los argumentos,
tipos de datos, valores devueltos y condiciones de error.
Deben tener una estructura paralela
85
- separar la estrategia de la computacin bsica

- uniformidad: escribir mtodos para todas las combinaciones
de entrada, y no slo para las previstas
- generalizar el mtodo lo ms posible
- evitar las dependencias contextuales
- subrutinas
- factorizacin de las diferencias
- delegacin
- encapsulamiento de cdigo externo dentro de una operacin
o clase
- extensibilidad
- encapsular las clases
- ocultar las estructuras de datos
- evitar el acceso remoto a enlaces o mtodos
- evitar sentencias case sobre el tipo de objeto, sino
mtodos. Las case se utilizan para comprobar atributos
internos de un objeto
- distinguir las operaciones pblicas de las privadas
- robustez
- optimizar el programa slo despus de que funcione
- validar los argumentos
- evitar lmites predefinidos
- incluir en el programa instrumentos de depuracin y
monitorizacin del rendimiento
- programacin en equipo
- no comenzar prematuramente la programacin
- mantener los mtodos inteligibles
- hacer los mtodos legibles
- utilizar exactamente los mismos nombres que en el
modelo de objetos
- escoger cuidadosamente los nombres, siguiendo una
pauta uniforme
- usar metodologas de programacin, o crearlas
- documentar las clases y mtodos
- empaquetar en mdulos.
86

02 MSA Material 02

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

02 MSA Material 02

Hochgeladen von

Copyright:

Verfügbare Formate

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

RELACIONES ENTRE LOS MODELOS

- Los tres modelos evolucionan juntos durante las distintas fases

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Diagramas para objetos:

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

En el caso de las clases, slo se representan los valores:

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

- cada enlace puede etiquetarse con el nombre de la asociacin

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

N-ARIEDAD DE LAS ASOCIACIONES

- El nombre de la asociacin puede escribirse como etiqueta junto

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

MULTIPLICIDAD DE LAS RELACIONES

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

- opcionalidad (cero o uno):

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

ATRIBUTOS DE LOS ENLACES

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

ATRIBUTOS DE LOS ENLACES (2)

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez

Unidad Docente de Lgica y Filosofa de la Ciencia

Rodolfo Fernndez Gonzlez