Metodologias de modelización r. fernandez

Rodolfo Fernández González Metodología de Modelización
Unidad Docente de Lógica y Filosofía de la Ciencia 1
METODOLOGIAS DE MODELIZACION
Rodolfo Fernández González

MODELIZACIÓN
- La construcción de hipótesis teóricas o modelos computa-
cionales es un “arte” sometido a reglas
- Modelizar: formalizar un fenómeno natural, organizacional o
técnico para disponer de:
- una descripción rigurosa
- un punto de partida preciso para la contrastación de
hipótesis
- un núcleo para el desarrollo de una aplicación informática
- Hay diversos estilos de formalización:
- explícitamente matemático:
- cuantitativo: Análisis matemático, Cálculo de
Probabilidades
- cualitativo: Algebra, Lógica
- computacional:
- es implícitamente matemático
- puede suponer o no una previa formalización
matemática
- diversas estrategias:
- OMT (Object Modelling Tool)
Rumbaugh, J. et al. (1991) Object-oriented
modeling and design. Prentice-Hall
- KADS

MODELOS
- Un modelo es una abstracción o esquematización de algo para
facilitar su comprensión.
- Abstracción o esquematización:
- omisión de detalles no esenciales del sistema real que
reduce su complejidad y facilita su comprensión.
- 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
adecuación, no corrección.

FASES DE LA MODELIZACION
- Análisis
- Diseño
- Implementación

FASE DE ANÁLISIS
- Construcción de modelos de la situación real que identifique las
propiedades relevantes
- Lo que interesa es comprender el problema
- Modelos de análisis: abstracciones concisas y precisas de lo que
debe hacer el sistema, no de cómo lo hará
- Los objetos de los modelos son conceptos del dominio del
problema, independientes de la implementación.

FASE DE DISEÑO
2.1. Diseño del sistema
- Decisiones de alto nivel sobre la arquitectura global
- Identificación de subsistemas
- Decisiones de optimización del rendimiento
- Estrategias de resolución
- Asignación inicial de recursos
2.2. Diseño de los objetos
- Construcción de los modelos de diseño a partir de los
modelos de análisis
- Detalles de implementación impuestos por las
estrategias de resolución
- Identificación de las estructuras de datos y de los
algoritmos necesarios para:
- implementar cada clase
- optimizar el rendimiento

FASE DE IMPLEMENTACIÓN
- Codificación de los modelos de diseño en un lenguaje de
programación
- Ingeniería del software:
- ajuste al diseño
- flexibilidad
- extensibilidad

TIPOLOGÍA DE MODELOS
- En cada fase, la modelización implica la construcción o
refinamiento de tres modelos distintos:
- Modelo de objetos
- Modelo dinámico
- Modelo funcional

MODELO DE OBJETOS
-Describe la estructura estática 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 jerárquicamente. Esa ordenación hace que
puedan compartir estructuras y comportamientos.
- Es el modelo fundamental, porque describe qué es lo que cambia
o se transforma, antes de describir cuándo o cómo lo hace.
- Proporciona la estructura básica en la que se integran los demás
modelos
- Descripción de los datos
- Es importante para cualquier problema que manipule estructuras
de datos no triviales

MODELO DINÁMICO
- Describe los aspectos del sistema que cambian en el tiempo, las
interacciones entre los objetos del sistema
- Secuenciación de operaciones:
- sucesos que inician o terminan cambios,
- secuencias de sucesos,
- estados que definen el contexto de los sucesos,
- organización 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
- Descripción de los aspectos de “control”

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
computación de los valores de salida a partir de los valores
de entrada
- Descripción de la “función” del sistema

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 dinámico y funcional.
- Distintas modalidades descriptivas de los componentes
dinámicos del sistema:
M. de objetos M. dinámico M. funcional
operaciones sucesos funciones
acciones
- Los tres modelos evolucionan juntos durante las distintas fases
del proceso de modelización
- A veces, los límites no están 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 específicas, adecuadas al dominio del
problema

Modelización 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 identificación de los objetos depende del problema: puede
haber más de una representación 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 económicos, pero ...)
- cada objeto “conoce” su clase. Esta es una propiedad implícita
del objeto
- la agrupación de objetos en clase es una abstracción que nos
permite:
- generalizar el conocimiento de lo individual
- simplificar la complejidad
- utilizar menos recursos (descriptivos, de almacenamiento
de información)

Diagramas para objetos:
- Clases
- Objetos o instancias
Rumbaugh Coad/Yourdon

Atributos
- Características poseídas 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 relación entre objetos
- Se representan en las clases bajo una línea 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, sólo se representan los valores:
(Persona) (Persona)
Juan Pérez Juan Pérez
27 años 27 años
Rumbaugh Coad/Yourdon

OPERACIONES
- Operación: Función o transformación que puede aplicarse a - o
que puede ser aplicada por- objetos de una clase
- Cada operación tiene como argumento implícito un objeto.
- La conducta de la operación depende de la clase de su
objeto
- el objeto “sabe” la especificación adecuada de su
operación
- polimorfismo: la misma operación:
- puede aplicarse a muchas clases distintas
- adopta en cada clase una forma distinta

MÉTODOS
Un Método es la especificación (implementación) de una
operación para una clase dada
- Si una operación tiene métodos para varias clases, es importante
que todos ellos tengan la misma signatura:
- lista de argumentos (entre paréntesis)
- tipo de cada argumento (precedido de :)
- tipo del valor resultante (precedido de :)
- Representación:
Persona
nombre :cadena
edad :entero
comprar
- Resulta útil durante la modelización 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 más argumentos que los de su objeto
pueden considerarse como atributos derivados
- Esto lleva a distinguir entre:
- atributos básicos o primitivos, y
- atributos derivados
- Al conjunto de las operaciones y de los métodos se les denomina
“servicios”

ENLACES Y ASOCIACIONES
- Un enlace es una conexión física o conceptual entre dos
instancias de objetos
- Formalmente es una relación, es decir, una lista ordenada de
objetos
- Un enlace es una instancia de una asociación
- Una asociación es un grupo de enlaces que comparten:
- la misma estructura
- la misma semántica
- Todos los enlaces de una asociación conectan objetos de las
mismas clases
- Suelen identificarse con los verbos del enunciado del problema
- Las asociaciones suelen ser bidireccionales:
- el nombre de la asociación binaria suele identificar una
dirección dada, la dirección “hacia delante”
- a esa asociación le corresponde otra asociación “inversa”
- las dos direcciones tienen el mismo significado, hacen
referencia a la misma asociación subyacente
- la implementación no tiene por qué ser bidireccional
- No deben representarse como “punteros” (atributos de un objeto
que tienen como valor otro objeto): la asociación no es parte de
ningún 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 información en clases

REPRESENTACION DE ASOCIACIONES
- Diagrama de una clase de asociaciones
País capital Ciudad
nombre nombre
Diagrama de instancias:
(País) capital (Ciudad)
España Madrid
(País) capital (Ciudad)
Francia París
- cada enlace puede etiquetarse con el nombre de la asociación
- Normalmente, las clases se ordenan para su lectura de izquierda
a derecha

N-ARIEDAD DE LAS ASOCIACIONES
- Las asociaciones pueden ser binarias, ternarias o de orden
superior
- La mayoría son binarias
- Las ternarias también pueden diagramarse:
Proyecto Lenguaje
Persona
- El nombre de la asociación puede escribirse como etiqueta junto
a la correspondiente salida del rombo de conexión

MULTIPLICIDAD DE LAS RELACIONES
- Sólo la consideraremos para las asociaciones binarias
- Podemos especificar cuántas instancias de una clase pueden
relacionarse con cada instancia de otra clase:
- Relaciones uno-a-uno (país-capital)
- Relaciones uno-a-muchos
- Relaciones muchos-a-muchos
- ...
- Es un aspecto de la modelización cuyo estudio puede dejarse
para las últimas fases
- Su consideración suele ayudar a elicitar supuestos ocultos

REPRESENTACIÓN 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 más):
Ejemplo: una persona puede tener 0 o más coches:
Persona Coche
posee
- opcionalidad (cero o uno):
Ejemplo: una persona puede tener o no un marcapasos:
Persona Marcap..
posee

REPRESENTACIÓN DE LA CARDINALIDAD
DE LAS RELACIONES (2)
- Cuando es necesario, se utilizan etiquetas numéricas:
- “1+” : uno o más
- “3-5” : de 3 a 5
- “2, 4, 18” : 2, 4 o 18
- Si los objetos del extremo con multiplicidad “muchos” de una
asociación deben tener un orden explícito, se indicará añadiendo
la etiqueta “{ordenado}”
- Cualificador: atributo especial que reduce la multiplicidad
efectiva de una asociación
- es una forma de asociación ternaria
- se expresa como una etiqueta dentro de un pequeño
recuadro adosado al extremo del multiplicidad “muchos”

ATRIBUTOS DE LOS ENLACES
- Son propiedades de los enlaces de una asociación
- Cada atributo de enlace tiene un valor para cada enlace
accesible-por
Fichero Usuario
tipo de permiso
(leer/escribir/ejecutar)
Persona trabaja para Empresa
nombre nombre
DNI CIF
dirección dirección
puesto
salario
- Los atributos “puesto” y “salario” podrían asociarse a la clase
“Persona” (la clase con multiplicidad “muchos”), lo que no sería
posible en relaciones “muchos-a-muchos”

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
asociación cambia
equipo
portero año
tiros parados
goles encajados

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, además,
nombre y operaciones
- Resulta útil modelizar una asociación como una clase si los
enlaces:
- pueden participar en asociaciones con otros objetos y/o
- están sujetos a operaciones
equipo
usuario máquina
autorización
prioridad
privilegios
abrir sesión

ROLES
- Cada extremo de una asociación 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 compañía
persona contratante
trabaja-para
- Su uso es opcional, y puede utilizarse además de, o en vez de, el
nombre de la asociación
- Es obligatorio utilizarlos si la asociación se da entre dos objetos
de la misma clase
- Es aconsejable para distinguir dos asociaciones entre el mismo
par de clases

AGREGACIÓN
- forma especial de asociación
- relación “parte-todo” o “es-parte-de”
- los objetos que representan los componentes se asocian con un
objeto que representa todo el compuesto
- propiedades:
- transitividad
- antisimetría
- propagación a algunas partes de algunas propiedades del
compuesto
- Representación:
documento <> •párrafo<> •oración

GENERALIZACIÓN Y HERENCIA
- Recursos para compartir semejanzas entre clases, manteniendo
las diferencias
- Generalización: Relación entre una clase y una versión menos
refinada de ella
- Es una relación “is-a”
- la relación inversa es la de especialización
- la clase más 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 características de su
superclase
- Generalización, especialización 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 añaden sus propios atributos y operaciones a los
heredados de sus antecesoras
- Los nodos terminales del arbol jerárquico son las instancias
(objetos) de las subclases más 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 operación, aunque le vengan suministrados por sus
superclases:
- los valores por defecto de los atributos
- los métodos de las operaciones
- Normalmente, nunca se modifican las signaturas.

REPRESENTACIÓN DE LA GENERALIZACIÓN
- triángulo que conecta una superclase con sus subclases:
Motor
tipo de energía
Eléctrico Combustión Vapor
tipo de combustible
Gasolina Gasoil
- la etiqueta junto a cada triángulo es un discriminador que indica
qué propiedad de un objeto está siendo abstraída por la relación
de generalización

MÓDULOS
- Un módulo es un agrupamiento de clases, asociaciones y
generalizaciones
- Se especifican o definen en función del problema a modelizar
- Cada modelo de objetos puede dividirse en módulos para
facilitar su manipulación y comprensión
- Los nombres de clases y de asociaciones deben ser únicos dentro
de cada módulo y, en la medida de lo posible, también dentro del
modelo de objetos completo
- Los módulos se interconectan haciendo referencias a la misma
clase
- Es conveniente que haya menos enlaces intermódulo que
intramódulo
- Cada módulo tiene un nombre asignado

HOJAS
- Cada módulo se representa en una hoja separada
- Si el módulo es complejo, puede dividirse en una serie de hojas,
cada una de las cuales se numera, indicando el módulo al que
pertenece.
- Cada asociación o generalización 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 código
encerrado en un círculo, y situado junto al símbolo de una clase:
A
A
Hoja 1 Módulo 3 Hoja 2 Módulo 3

Modelización Dinámica
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, 514-
530
Hopcroft, J. E., Ullman, J. D. (1979): Introduction to Automata
Theory, Languages and Computation, Addison-Wesley
Reisig, W. (1985), Petri Nets: An Introduction, Springer

MODELIZACIÓN DINÁMICA
- 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 estímulos externos, sin
tener en cuenta qué hacen las operaciones, sobre qué operan, y
cómo están implementadas
- Conceptos dinámicos fundamentales:
- sucesos (events): estímulos externos
- estados (conjunto de valores de objetos)
- Los programas no interactivos tienen un modelo dinámico
trivial, ya que su objetivo consiste en computar una función
- Diagrama de estados:
- red de estados y eventos que representa transiciones de
estados a lo largo del tiempo
- representación gráfica de las máquinas de estado finito
- Hay un diagrama de estados por cada clase que tenga un
comportamiento dinámico relevante. No todas las clases lo
necesitan
- Cada máquina 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

SUCESOS
- Algo que tiene lugar en un instante temporal determinado
- Cada suceso es único y no tiene duración
- Pueden estar causalmente relacionados entre sí, o no (sucesos
concurrentes)
- Si no están causalmente relacionados entre sí, su ordenación es
irrelevante
- Constituyen una transmisión de información unidireccional de
un objeto a otro
- El envío de un suceso desde un objeto a otro no incluye
necesariamente una réplica
- La réplica sería 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 común
- Esta estructura es jerárquica, igual que la de las clases de objetos
- Casi todas las clases de sucesos tienen atributos que indican la
información que transportan (se representan entre paréntesis a
continuación de la etiqueta del suceso)
- Pueden representarse como operaciones sobre el modelo de
objetos

ESCENARIOS
- Un escenario es una secuencia de sucesos que tiene lugar
durante una ejecución dada
- Su alcance puede variar:
- Todos los sucesos del sistema
- Sólo los sucesos generados por determinados objetos del
sistema
- Puede ser un registro de una ejecución o un experimento mental
sobre un modelo propuesto
- Después de describir un escenario, hay que identificar al emisor
y receptor de cada suceso
- La construcción de diagramas de estado comienza por la
identificación de escenarios

EJEMPLO DE ESCENARIO
Ej. de diagrama de seguimiento (traza) de eventos: Llamada
telefónica
Persona que llama Línea telefónica Persona llamada
levanta el receptor
comienza el tono de marcar
marca el 1er número
termina el tono de marcar
marca el 2º número
...
marca el último número
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 teléf con
... ...
cuelga
cuelga el teléfono
fin de la conexión fin
- El tiempo avanza de arriba abajo
- Sólo se representa la secuencia, no los intervalos reales
- Se pueden enviar sucesos concurrentes
- Se pueden enviar más de un suceso seguido

ESTADOS
- Un estado es una abstracción 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, sólo
los relevantes
- La granularidad de los estados depende del problema
- El estado especifica cuál será la respuesta del objeto a los
sucesos de entrada
- La respuesta de un objeto a un suceso puede variar
cuantitativamente en función 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 acción 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
están escondidos por los sucesivos
- El estado tiene una duración, y a veces se asocia con una
actividad continua

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 condición determinada
- En el caso más 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
- Especificación del estado:
- nombre
- descripción
- secuencia de sucesos que produce el estado
- condiciones que caracterizan el estado
- sucesos aceptados por el estado:
- suceso
- acción
- estado siguiente
- En la medida en que un enlace puede ser considerado como un
objeto, puede tener un estado.

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
- Transición: cambio de estado causado por un suceso
- Grafo dirigido cuyos nodos son estados y los arcos están
etiquetados con los sucesos que causan la transición, 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 función de cuáles sean los
valores de sus atributos
- Cada objeto es independiente de los demás, y procede a su
propio ritmo
- El modelo dinámico es un conjunto de diagramas de estado que
interactúan entre sí mediante sucesos compartidos

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)[condición]/acción
Estado1 Estado 2
hacer: Actividad1 hacer:Actividad2
- Ejemplo simple: Ajedrez
Init
• Juegan blancas jaque-mate Blancas ganan
mueven mueven ahogo
negras blancas ahogo Tablas
Juegan negras jaque-mate Negras ganan

CONDICIONES
- Son funciones booleanas de valores de objetos
- Una condición es válida durante un intervalo
- Un estado es definible en términos de una condición
- Las condiciones pueden utilizarse como “guardas” sobre
transiciones
- Una transición guardada dispara si su suceso ocurre
- Una condición guardada sobre una transición se expresa
como una expresión booleana encerrada entre corchetes
detrás 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]

OPERACIONES
- No basta con describir patrones de sucesos
- Una descripción 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 duración
- 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
- Representación:
“hacer:”
- Acciones:
- operaciones instantáneas
- asociadas con un suceso
- su estructura interna no es relevante a efectos de la
modelización del control
- también pueden representar operaciones internas de
control:
- establecer atributos
- generar otros sucesos (p.ej., incrementar un
contador)
- diagramación:
- precedido de /
- a continuación de la condición de guarda

DIAGRAMAS DE ESTADO ANIDADOS
- Las máquinas de estados se estructuran igual que los objetos:
- Generalización:
- expansión de las actividades anidadas
- se añaden detalles a las actividades que antes se
describieron a alto nivel
- los estados y los sucesos se colocan en jerarquías de
generalización, con herencia de estructura y
comportamiento (igual que la herencia de atributos y
operaciones en clases)
- Agregación:
- un estado se puede partir en componentes
ortogonales, con interacción limitada entre ellos
- equivale a la concurrencia de estados
- Con problemas complejos, la única forma práctica 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 transacción se aplica a
muchos estados

EJEMPLO DE DIAGRAMA DE ESTADO
- Máquina 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] [cambio > 0]
hacer: dispensar producto hacer: dar cambio

EJEMPLO DE DIAGRAMA DE ESTADO (2)
- La actividad “dispensar producto” puede expandirse en el
siguiente subdiagrama:
liberada liberado
hacer: liberar columna hacer: liberar paquete
- Los sucesos, como “seleccionar producto” también pueden
expandirse:
introd. dígito selecc. producto
hacer: borrar hacer: añadir
producto dígito confirmar
borrar

GENERALIZACIÓN DE ESTADOS
- Los estados pueden tener subestados que heredan las
transiciones de sus superestados
- Cualquier transición o acción que se aplica a un estado, se aplica
a todos sus subestados, a menos que éstos tengan una transición
específica
- 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
GENERALIZACIÓN DE SUCESOS
- Los sucesos pueden estar organizados en una jerarquía de
generalización, con herencia de los atributos de los sucesos

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 acción,
no se utiliza
- Siempre que se entra en un estado, mediante una transición de
entrada, se ejecuta antes la acción de entrada
- Siempre que se sale de un estado, mediante una transición de
salida, se ejecuta antes la acción de salida
- Si hay varias operaciones sobre un estado, se ejecutan en el
siguiente orden:
- acciones sobre la transición de entrada
- acciones de entrada
- actividades “hacer” (pueden ser interrumpidas por
sucesos que causen transiciones a otro estado)
- acciones de salida (también se ejecuta si se interrumpe
una actividad “hacer”)
- acciones sobre la transición de salida
- Se utilizan si un estado tiene varias transiciones de
entrada/salida , y todas causan la misma acción

ACCIONES INTERNAS
- Un suceso puede hacer que se ejecute una acción sin que cambie
el estado
- Si se produce el suceso, su acción 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
TRANSICIÓN AUTOMÁTICA
- Transiciones lambda: transiciones que se disparan cuando se
completa una actividad secuencial
- Se representan mediante una flecha sin etiqueta de suceso
- Cada transición está condicionada
ENVÍO DE SUCESOS
- Un objeto puede realizar la acción de enviar un suceso (con sus
atributos) a otro objeto
- Se representa mediante una línea de puntos desde una flecha de
transición a otro objeto o clase de objetos (o a una transición del
diagrama de estados de ese objeto)
- Si un estado puede aceptar sucesos de más de un objeto, el orden
en que se reciben puede afectar al estado resultante (la “condición
de carrera”)

CONCURRENCIA
- Cada objeto tiene su propio estado, y su propio diagrama de
estados
- La concurrencia por agregación de estados es la combinación de
los estados de todos los diagramas componentes
- Una transición 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 combinación de
los estados de cada subdiagrama
SINCRONIZACIÓN 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
- Representación: se subdivide el estado con líneas de puntos, en
cada una de las cuales se coloca una actividad “hacer”
concurrentes. Las flechas se bifurcan para mostrar la concurrencia

Modelización Funcional
Rumbaugh, 91;
Yourdon, E. (1989), Modern Structured Analysis, Yourdon Press
De Marco (1979), Structured Analysis and Systems Specification,
Prentice Hall
- Descripción de la computación: Qué hace el sistema
(Mod. dinámica: cuándo hace el sistema lo que hace)
(Mod. de objetos: a quién hace el sistema lo que hace)
- Describe cómo se derivan los valores de salida de los de entrada,
sin tener el cuenta el orden de la computación
- 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 dinámico
- 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

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 información 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

DFDS ANIDADOS
- Visión de la descomposición funcional del sistema en unidades
funcionales
- La estructura de anidamiento forma un árbol
- El nivel más bajo es el de las funciones primitivas

PROCESOS
- Los procesos de nivel más 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 sólo indica los posibles caminos
funcionales, no los que tienen lugar realmente en función de la
dinámica del sistema (esto aparece en el modelo dinámico)
- Tienen una o más entradas y una o más salidas
- sus entradas y salidas están etiquetadas con su papel en la
computación o el tipo de dato
- Sólo muestra el patrón de entradas y salidas. La computación
hay que especificarla
- Un proceso de alto nivel puede expandirse en todo un DFD de
nivel más bajo
- Los procesos se implementan como métodos de operaciones
sobre clases de objetos

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

ACTORES
- Objeto activo que produce o consume valores
- Están 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 dinámico
ALMACENES DE DATOS
- Objeto pasivo que almacena datos
- Responde a peticiones de almacenamiento y recuperación de
datos
- Incluye añadir, modificar o borrar elementos
FLUJOS DE CONTROL
- A veces se incluyen en el modelo funcional
- Se representa como una línea de puntos desde un proceso que
controla a otro controlado
- Puede etiquetarse con el valor de control

ESPECIFICACIÓN DE OPERACIONES
- Los procesos se implementarán como operaciones sobre objetos
- Cada operación puede especificarse de distintas formas:
- función matemática
- tabla de valores de entrada/salida para conjuntos finitos
pequeños (enumeración)
- ecuaciones que especifican el output en términos del
input
- precondiciones y postcondiciones (definición axiomática)
- tablas de decisión
- cálculo de predicados
- pseudocódigo
- lenguaje natural
- La especificación incluye:
- nombre de la función
- una signatura: la interfase a la operación
- los argumentos que exige, su número, orden y tipos
(entrada)
- los valores que devuelve (número, orden y tipos) (salida)
La signatura de todos los métodos que implementan
una operación debe coincidir
- una transformación que define el efecto de una operación:
- valores de salida como funciones de los valores de
entrada
- efectos colaterales en los objetos sobre los que opera
- restricciones

ESPECIFICACIÓN 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 análisis
- en el diseño se distinguen las públicas de las privadas
- Operaciones no triviales:
- queries:
- no tiene efectos colaterales sobre el estado externa-
mente visible de un objeto
- instantáneas
- son atributos derivados
- acciones:
- tienen efectos colaterales en los objetos
- no tienen duración
- actualizan los atributos básicos y de los enlaces
- definibles en términos de estados anterior y posterior
- se derivan de los procesos en el modelo funcional
- actividades
- operaciones con duración
- sólo tienen sentido para los actores
- suelen corresponder a un diagrama de estado en el
modelo dinámico

ESPECIFICACIÓN DE OPERACIONES (3)
- Puede haber valores internos no visibles desde fuera, que son
privados de la operación y quizás de la clase de objetos
- El estado del objeto puede dividirse entre información
externamente visible e información interna privada

RESTRICCIONES
- Una restricción expresa la relación entre:
- dos objetos al mismo tiempo
- diferentes valores del mismo objeto en tiempos distintos
- Puede expresarse como:
- una función total (un valor viene definido completamente
por otro)
- una función 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

Modelo funcional Modelo de objetos Modelo dinámico
- lo que el sistema -quién hace: los objetos
tiene que hacer
- procesos - operaciones - secuencia de
ejecución
- actores - objetos
- almacenes - objetos
- flujos de datos - valores

Análisis
--------------------------------------------------------------------------------
-
Bibliografía
Shlaer, S. (1988), Object-Oriented Systems Analysis, Yourdon
Press
--------------------------------------------------------------------------------
-
- Primer paso: Formulación del problema
- Requerimientos obligatorios
- Requerimientos opcionales
- Alcance del problema
- Contexto
- Supuestos
- Requerimientos de eficiencia
- Previsión de extensiones futuras
- Protocolos de interacción con sistemas externos
- Modelización de objetos:
- identificar objetos y clases
- entidades físicas
- conceptos
- denotados por nombres
- depurar los objetos y clases
- eliminar las clases redundantes, manteniendo la
descripción más rica
- eliminar las clases irrelevantes
- precisar o eliminar las clases vagas, confusas o
demasiado amplias
- la modelización de un elemento como clase o
atributo depende de cada caso

- la modelización de un elemento como clase o como
operación 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 definición de una
clase u objeto
- alcance dentro del problema
- supuestos o restricciones de su uso
- descripción 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 físico, comunicación, acciones
dirigidas, propiedad, satisfacción de condiciones,
...
- la distinción 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
diseño, pero se marcan con líneas de puntos
- - en la medida de lo posible, clases, atributos y
asociaciones deberían representar información
independiente
- nombres claros y descriptivos (qué, y no cómo o
por qué)
- papel que una clase en una asociación desempeña
desde el punto de vista de la otra clase
- cualificador: nombre más contexto de uso
- multiplicidad: menos importante durante el
análisis

- 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 búsqueda 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
más 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
asociación con el mismo significado, intentar
generalizar las clases asociadas
- top-down: refinar las clases formando subclases
especializadas: adjetivos del nombre de la clase

- 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 módulos
- dividir los diagramas en hojas
- módulo: conjunto de clases (una o más hojas) que
contiene un subconjunto lógico del modelo total
- organización de módulos:
- organización en estrella
- módulo central que contiene la estructura global
de las clases de alto nivel
- otros módulos expanden cada clase de alto nivel
en una jerarquía de generalización, y añaden
asoociaciones a clases adicionales de bajo nivel
- Modelización dinámica
- Preparación de escenarios
- escenario: secuencia de sucesos
- cada suceso tiene un actor (sistema,
experimentador) y unos parámetros
- parámetros del suceso: la información
intercambiada (puede ser simplemente el hecho de
que el suceso ha ocurrido)
- diálogos típicos entre:
- experimentador y modelo
- usuario y sistema
- primero diálogos “normales”, y después los
“especiales” (entradas sin valor, con máximos o
mínimos, incompletas, etc.) y las condiciones de
error (valores no válidos, etc.)
- abortar operaciones o retornar a puntos anteriores
- Frecuente distinción entre:

- lógica de la aplicación (lo que interesa en el
modelo dinámico)
- 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 envían 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
dinámico no trivial
- cada escenario o traza de sucesos corresponde a un
camino en el diagrama de estados
- Operativa de construcción:
- Tomamos los diagramas de traza de sucesos que
afectan a la clase que estamos modelizando.
- Tomamos una traza que corresponde a una
interacción típica, y sólo tenemos en cuenta los
sucesos que afectan a un solo objeto.
- Colocamos los sucesos en un camino cuyos arcos
están 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

- Revisar los bucles. Favorecerlos, y revisar sus
salidas
- insertar otros escenarios en el diagrama de
estados
- Después de los sucesos normales, los límites o
especiales, y los de error
- Si hay interacciones complejas con entradas
independientes, podemos construir el modelo
dinámico utilizando diagramas de estado anidados.
- Comprobar los sucesos entre objetos para verificar la
consistencia
- Modelización funcional
- Identificar los valores de entrada y salida
- son los parámetros 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 atrás hacia delante: normalmente es más
difícil 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 descripción declarativa: especificación
de las relaciones entre entrada y salida y entre los
valores de salida: no implica una implementación
- si es más fácil que la declarativa, descripción
procedural: especificación de un algoritmo
- identificar las restricciones
- dependencias funcionales entre objetos no
relacionados mediante una dependencia de entrada-
salida

- 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 optimización
- valores que hay que maximizar, minimizar, u
optimizar
- si hay criterios de optimización en conflicto, indicar
los criterios de decisión.
- Especificación de operaciones
- del modelo de objetos
- lectura y escritura de valores de los atributos y
enlaces de asociación
- de los sucesos
- cada suceso enviado a un objeto corresponde a una
operación sobre él
- de las acciones de estado y de las actividades
- de las funciones
- cada función corresponde a una operación sobre uno
o más objetos
- las funciones (excepto las de acceso) se organizan
en operaciones sobre objetos
- genéricas
- operaciones que no dependen de un sistema
concreto ni están sujetas a un orden de ejecución
determinado, pero que son significativas por sí
mismas
- simplificación de operaciones: eliminar redundancias y
variaciones. Utilizar la herencia para reducir el número de
operaciones distintas. Introducir nuevas superclases.
- Iteración del Análisis

--------------------------------------------------------------------------------
-

Diseño del sistema
--------------------------------------------------------------------------------
-
Bibliografía:
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:
- organización global del sistema en componentes llamados
subsistemas
- Organización del sistema en subsistemas
- Cada subsistema contiene aspectos del sistema que
comparten alguna propiedad común o funcionalidad
semejante
- Un subsistema no es un objeto ni una función, sino un
empaquetamiento de clases, asociaciones, operaciones,
sucesos y restricciones que están 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 algún objetivo común, p. ej., cálculo
aritmético, procesamiento de entrada/salida, etc.
- las operaciones internas de cada subsistema pueden ser
diseñadas independientemente de las de los demás
- El diseño del sistema debe ser tal que la mayor parte de
las interacciones se produzcan dentro de cada subsistema.
- cada subsistema puede descomponerse en subsistemas
más pequeños. Los subsistemas de nivel más bajo se
llaman “módulos”
- La relación entre subsistemas puede ser:
- cliente-servidor

- el cliente llama al servidor, que realiza algún
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 demás. A
cada comunicación no le sigue necesariamente
una respuesta inmediata. Cada subsistema
debe conocer el interfase de los demás. Dada
la posible existencia de bucles, su dificultad es
mayor.
- La descomposición de sistemas en subsistemas puede
organizarse como una secuencia de capas horizontales o
de particiones verticales. También pueden adoptarse
enfoques híbridos
- Capas
- Un sistema de capas (layered system) es un conjunto
de niveles tal que cada uno de ellos está construido
en términos de los que se encuentran por debajo de
él, y constituye la base para la construcción de los
que se encuentran por encima de él
- El nivel superior es el sistema deseado y viene
especificado en la formulación 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
- filosofía 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 términos del nivel
inmediatamente inferior. Reduce las
dependencias entre niveles y los cambios son

más fáciles, puesto que el interfase sólo 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 información. Los
cambios de un subsistema pueden afectar a
cualquier otro sistema superior. Menos robustez.
- Particiones
- Divisiones del sistema en subsistemas
independientes y débilmente acoplados, cada uno de
los cuales proporciona un servicio específico
- el conocimiento de los demás es superficial, y las
dependencias son mínimas
- Topologías del sistema
- tras la identificación de los subsistemas del nivel
superior, se construye un DFD que muestra el flujo
de información entre los subsistemas
- secuencia, estrella, ...
- Identificar las concurrencias inherentes
- una hebra de control es un camino a través de un conjunto
de diagramas de estado sólo está activo un objeto a la vez.
- Una hebra permanece en un diagrama de estado hasta que
un objeto envía 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 envía un evento y
continúa la ejecución
- En cada hebra de control, sólo 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 cuáles tienen una actividad que es
mutuamente excluyente

- si los sucesos no están 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 información entre ellos
- Asignar subsistemas a los procesadores y las tareas
- Para cada subsistema, se evalúan los requerimientos de
rendimiento y los recursos necesarios
- Se escoge la implementación hard o soft para cada
subsistema
- Se asignan subsistemas soft a los procesadores para
satisfacer los requerimientos y minimizar la
comunicación interprocesadores
- Se establece la conectividad de las unidades físicas que
implementan los subsistemas
- Se asignan tareas a los procesadores, teniendo en cuenta
localización física, tiempo de respuesta o carga de
computación
- Se determina la conectividad física: topología de
conexión física, topología 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 conexión
(ancho de banda, latencia), y los mecanismos de
interacción (síncronos, asíncronos o de bloqueo) y
protocolos de conexión
- Elegir un enfoque para la gestión de los almacenes de
datos

- los almacenes de datos internos y externos constituyen
líneas de separación 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 visualización,
nombres lógicos, bases de datos compartidas, etc.
- cada recurso debe ser poseído por un objeto guardíán que
controla su uso, total o parcial, mediante el uso de
bloqueos (locks)
- Escoger la implementación de control en el software
- en el análisis, 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
- fácil implementación si hay
alternancia regular de sucesos de
entrada/salida
- malo para las entradas asíncronas,
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 estás asignados a
sucesos, y el dispatcher los llama
cuando ocurre el suceso (callback)
- los procedimientos devuelven control
al dispatcher

- más difícil de implementar, pero más
flexible
- X-Windows
- concurrente (sist....)
- ejecución concurrente de tareas
- sucesos almacenados en una cola
- resolución de conflictos de planificación entre
tareas
- Ada
- Control interno
- flujo de control dentro de un proceso
- sólo existe en la implementación. Tipos:
- llamadas a procedimientos
- llamadas cuasi-concurrentes entre tareas
(corutinas, procesos lighweight ). Tiene
varios espacios de direccionamiento y
múltiples pilas de llamada, pero sólo puede
estar activa una hebra de control a la vez
- llamadas concurrentes entre tareas
- Otros:
- programación basada en reglas, programación
lógica...
- no control explícito, sino especificación
declarativa con reglas de evaluación
implícitas, quizás no declarativas
- Manejar las condiciones límite
- inicialización: constantes, parámetros, variables globales,
tareas, objetos guardianes, jerarquía de clases
- terminación: liberación 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 rápido
- Estructuras arquitectónicas habituales
- Transformación batch

- la transformación de datos de todo un conjuntode
entrada se ejecuta una sola vez
- transformación secuencial desde la entrada hasta la
salida
- ej.: compilación
cód. fuente list. tokens árbol gr.
An. léxico An. gramatical
An. semántico
(parsing)
arbol
gr. ampliado
cód. objeto cód. optimiz. código
Form. c. obj . Optimización
Generac. cód .
- su modelo de estados es trivial
- lo más importante es el modelo funcional, que
especifica cómo los valores de entrada se
transforman en los de salida
- metodologías de DFD y descomposición funcional
- etapas:
- partir la transformación 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
débilmente con los de las fases contigüas
- expandir cada fase hasta que las operaciones sean
fácilmente implementables
- optimizar el diagrama final
- Transformación continua
- la transformación de datos se ejecuta de forma
continuada a medida que las entradas van
cambiando

- etapas :
- diseñar 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
- ergonomía del diálogo con el usuario
- etapas:
- separar los objetos del interfase de los que
definen la semántica de la aplicación
- si es posible, utilizar objetos predefinidos para
interactuar con agentes externos
- utilizar el modelo dinámico como estructura del
programa. Mejor, control guiado por sucesos.
- separar los sucesos físicos de los lógicos
(múltiples sucesos físicos)
- especificar completamente las funciones de la
aplicación que son invocadas por el interfase
- Simulación dinámica
- sistema que simula objetos cambiantes del mundo
real
- muchos objetos distintos que se actualizan
continuamente
- etapas:

- identificar actores, objetos activos del mundo
real, en el modelo de objetos. Los actores tienen
atributos que se actualizan periódicamente
- 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
parámetros. Estos atributos hay que actualizarlos
periódicamente utilizando técnicas de
aproximación numérica para minimizar los
errores de cálculo
- normalmente, la simulación 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 transacción (unidades de
transacción)
- diseñar el control de la concurrencia para las
transacciones
--------------------------------------------------------------------------------
-

Diseño 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.
--------------------------------------------------------------------------------
-
- Transformación de la estructura lógica del modelo de análisis
en una organización física de un programa
- Papel central del modelo de objetos en el diseño
- 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 dinámico y los
procesos del modelo funcional se convierten en
operaciones asociadas a las clase del modelo de objetos
- Si asociamos una operación con los sucesos que un objeto
recibe, el algoritmo que implementa la operación depende
del estado del objeto
- el código que implementa el algoritmo debe contener una
sentencia CASE que especifique el estado
- Si tenemos un par de sucesos que representan una acción
sobre otro objeto y la devolución del resultado de la
acción, podemos representarlos como una operación
- una acción o actividad puede expandirse en un DFD
completo del modelo funcional
- los procesos en el cuerpo del DFD representan el
cuerpo de una operación
- los flujos son los valores intermedios

- 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 operación:
- 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 versión 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 operación de clase (constructor) sobre la
clase de salida
- si el proceso tiene una entrada de o una salida
a un almacén o un actor, entonces éstos son los
objetivos
- Diseñar algoritmos para implementar las operaciones
- Elegir algoritmos que minimicen el coste de
implementación de las operaciones
- en muchos casos, la especificación del modelo
funcional ya constituye un algoritmo suficiente
- Se necesitan algoritmos:
- para implementar funciones para las que no se ha
dado una especificación procedural (sólo
restricciones declarativas)
- para optimizar funciones definidas mediante un
algoritmo sencillo pero poco eficiente
- Criterios de elección:
- Complejidad computacional: ¿cómo crece la
demanda de tiempo o de espacio de memoria
respecto al número de valores de entrada?
- Facilidad de implementación y de
comprensibilidad

- Flexibilidad
- Ajuste al modelo de objetos
- Seleccionar estructuras de datos apropiadas a los
algoritmos
- instancias de clases contenedoras
- estructuras de datos genéricas dadas como librerías:
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 operación es el objeto cambiado, no
el meramente preguntado
- el objetivo de la operación es el objeto alrededor del
cual se agrupan en estrella las clases y asociaciones
que intervienen en la operación
- por defecto, si es sólo un objeto el que interviene,
decidir qué objeto realiza la operación en el mundo
real
- Optimizar los caminos de acceso a los datos
- Añadir asociaciones redundantes para minimizar los
costes de acceso y maximizar la conveniencia
- reordenar más eficientemente la computación
- Almacenamiento de atributos derivados para evitar la
recomputación de expresiones complicadas. Su valor se
puede actualizar de tres formas:
- actualización explícita
- recomputación periódica
- valores activos
- Implementar el control de las interacciones externas
- Para implementar el modelo dinámico de acuerdo con la
estrategia básica decidida durante el diseño del sistema se
puede:

- Definir implícitamente el estado del programa mediante
la asignación de control dentro de él (Sistema guiado por
procedimientos: enfoque tradicional): Transferencia de
control a una sentencia o rutina en función de la entrada
recibida: Técnica de conversión:
- 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 atrás que salgan del
camino principal y que se junten después con él. Se
convertirán en bucles en el programa. Si hay varios
caminos hacia atrás 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 excepción. Se convertirán 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 máquina de
estados (sistema guiado por sucesos)
- Motor de transiciones que permite ejecutar una
máquina de estados representada por una tabla de
transiciones y acciones
- YACC o LEX (parsers) proporcionan máquinas de
estado explícitas
- 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 operación heredada
- número de argumentos de las operaciones
- nombres de los atributos

- Abstraer la conducta común de grupos de clases
- crear superclases con los rasgos compartidos
- Utilizar la delegación para compartir la conducta cuando
la herencia es semánticamente inválida
- un objeto puede invocar selectivamente funciones
de otra clase
- Diseñar las asociaciones
- estrategia para implementar las asociaciones
- global o para cada asociación
- si algunas asociaciones se atraviesan en una sola
dirección, su implementación se puede simplificar, como
puntero (atributo que contiene la referencia de un objeto)
o conjunto de punteros (dependiendo de su
multiplicidad). Si la asociación apunta a “muchos”
ordenados, podemos utilizar una lista en vez de un
conjunto. Una asociación cualificada con multiplidad
“uno” puede implementarse como un objeto diccionario
(conjunto de pares de valores que hacen corresponder
valores de selección 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
dirección, en ambas, o como un objeto asociación
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 dirección), dependiendo de la frecuencia de uso
de las asociaciones, de si los accesos superan a las
actualizaciones
- Si una asociación tiene enlaces, se implementa como una
clase distinta, en la que cada instancia representa un
enlace y sus atributos
- Determinar la representación de objetos: fácil. Tipos primitivos
o combinaciones de grupos relacionados.
- Empaquetar las clases y asociaciones en Módulos
- Ocultar la información interna

- definición del interfase público de cada clase al
mayor nivel de abstracción posible
- decidir qué atributos de la clase serán accesibles
desde fuera o no (private)
- limitar el alcance de los métodos y operaciones
- evitar el acceso mediante asociaciones no
conectadas a la clase actual
- evitar aplicar un método al resultado de otro método
- asegurar la coherencia de las entidades
- una entidad, operación o módulo es coherente si
está organizado sobre un plan consistente y todas
sus partes se ordenan a un fin común. Separar los
métodos estratégicos (policy) de los métodos que
implementan algoritmos (implementation meth.)
- construir los módulos físicos
- Documentar las decisiones de diseño: documento de diseño
--------------------------------------------------------------------------------
-
Implementación
- 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
- métodos coherentes: una sola función o un solo grupo de
funciones relacionadas
- métodos pequeños
- métodos consistentes: los métodos 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

- separar la estrategia de la computación básica
- uniformidad: escribir métodos para todas las combinaciones
de entrada, y no sólo para las previstas
- generalizar el método lo más posible
- evitar las dependencias contextuales
- subrutinas
- factorización de las diferencias
- delegación
- encapsulamiento de código externo dentro de una operación
o clase
- extensibilidad
- encapsular las clases
- ocultar las estructuras de datos
- evitar el acceso remoto a enlaces o métodos
- evitar sentencias case sobre el tipo de objeto, sino
métodos. Las case se utilizan para comprobar atributos
internos de un objeto
- distinguir las operaciones públicas de las privadas
- robustez
- optimizar el programa sólo después de que funcione
- validar los argumentos
- evitar límites predefinidos
- incluir en el programa instrumentos de depuración y
monitorización del rendimiento
- programación en equipo
- no comenzar prematuramente la programación
- mantener los métodos inteligibles
- hacer los métodos legibles
- utilizar exactamente los mismos nombres que en el
modelo de objetos
- escoger cuidadosamente los nombres, siguiendo una
pauta uniforme
- usar metodologías de programación, o crearlas
- documentar las clases y métodos
- empaquetar en módulos.

Metodologias de modelización r. fernandez

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (9)

Similar a Metodologias de modelización r. fernandez

Similar a Metodologias de modelización r. fernandez (20)

Más de Wilfredy Inciarte

Más de Wilfredy Inciarte (20)

Último

Último (20)

Metodologias de modelización r. fernandez