01-STR-COMET - Parte 1

Unidad 3
1
Electiva I (STR )- UCSE
Una metodología puede definirse como:
"Una versión ampliada del ciclo de vida completo

del desarrollo de sistemas, que incluyen tareas
o pasos para cada fase, funciones desempeñadas
en cada tarea, productos resultantes, normas de
calidad y técnicas de desarrollo que se utilizan en
cada tarea".
Whitten, J. ; Bentley, L. ; Barlow, V. Análisis y Diseño de Sistemas de Información. 3ª ed.,

Madrid. McGraw-Hill. 2003. pp146-160
2
Requisitos que debe reunir un
método de diseño de S.T.R.
Modelización estructural: para modelar el
dominio del problema, límite (hard y soft) del
sistema total, interfaz entre los componentes de
hard y soft, y límite del soft del sistema.
Modelización dinámica (de comportamiento):
para modelar la secuencia de interacciones
entre el sistema y los artefactos de software a
nivel de requisitos, análisis y diseño.
Máquinas de estado: Para reaccionar a los
eventos externos según lo determinado por las
entradas y el estado actual del sistema.
3
Requisitos que debe reunir un
método de diseño de S.T.R.
Concurrencia: para manejar múltiples secuencias y cargas
impredecibles mediante el modelado de actividades que se
ejecutan en paralelo con otras.
Arquitectura de software basada en componentes: para

proporcionar una arquitectura que consiste de componentes
orientados a objetos concurrentes y conectores, tal que tales
componentes pueden desplegarse a diferentes nodos en un
ambiente distribuido.
Análisis de rendimiento de diseño de Tiempo Real: para

analizar el rendimiento del sistema de TR antes de su
implementación y proporcionar una determinación temprana
de si el sistema alcanzará sus objetivos de rendimiento.
4
Clasificación de los métodos
de diseño.
5
En los últimos años se han desarrollado
diversas metodologías de aplicación
específica del diseño de STR, entre ellas se
pueden encontrar:
ROOM/UML-RT
HRT-HOOD
OOHARTS
SiMOO-RT
ACCORD/UML
Octopus/UML
ROPES
COMET
6
Diseño de Aplicaciones de
Tiempo Real usando COMET
7
COMET
Concurrent Object Modeling and
architectural design mEThod.
Dr. Hassan Gomaa. George Mason

University.
“Designing Concurrent Distributed and

Real-Time Applications with UML”.
Addison-Wesley (1998).
8
Modelo de Ciclo de vida en
COMET
Modelado Fase de Modelado de Requisito en donde los requisitos funcionales del
sistema se especifican mediante actores y casos de uso.
Estructural En la Fase de Análisis, se refinan los requisitos para describir los objetos que
Usuario del Sistema intervienen y sus interacciones, a través de diagramas de clase (modelo
estructural) y mediante colaboraciones y/o diagramas de estado
(comportamiento dinámico).
Modelado de En la Fase de Diseño, se desarrolla la arquitectura del software.
Requisitos En la Fase de Construcción se lleva a implementación, el diseño del
comportamiento estático y dinámico del sistema.
Modelado Durante la Fase de Integración se integran los módulos de software creados.
Finalmente, sobre la arquitectura de tareas obtenida en la fase de diseño, se lleva a
del Análisis cabo el Testeo (la validación) temporal del sistema, a través de un análisis de
planificación o un análisis de secuencias de eventos.
Modelado
del Diseño
Construcción de
software incremental
Integración de
software incremental
Prototipo Testeo del

incremental sistema Cliente
9
COMET
Utiliza la notación UML para describir
los sistemas.
Se basa en conceptos como:

Ocultamiento de Información
Clases
Herencia
Tareas Concurrentes
10
COMET
Estrategia de diseño.
Sistema = conjunto de objetos pasivos y

activos + interfaces entre ellos.
Provee heurísticas y criterios para

descomponer un sistema en subsistemas
+ objetos que los constituyen.
11
COMET
Es cíclico, iterativo y gira alrededor de los casos
de uso.
Los requisitos funcionales del sistema se

definen en términos de actores y casos de uso.
Cada caso de uso define una secuencia de

interacciones entre uno o más actores y el
sistema.
Un caso de uso se puede ver a distintos

niveles de detalle.
12
COMET
En el 1.Modelo Estructural del sistema se
enfoca en el modelado estático del sistema total
(hard, soft, y personas, sin considerar la
funcionalidad) para una mejor comprensión del
mismo.
En el 2.Modelo de Requisitos los requisitos

funcionales del sistema se definen en términos
de actores y casos de uso.
En el 3.Modelo de Análisis el caso de uso se

refina para describir objetos que participan en el
caso de uso y sus interacciones.
En el 4.Modelo de Diseño se desarrolla la

arquitectura del sistema fijando aspectos de
distribución, concurrencia.
13
1.Modelo Estructural del
Sistema
Modelado estructural del dominio del problema: involucra
el modelado estático de las entidades del mundo real,
incluyendo otros sistemas, usuarios, entidades físicas, y
entidades de información; y determinando las relaciones
entre ellos.
Modelado estructural del contexto del sistema: involucra
la determinación explícita del límite entre el sistema y el
medio externo (usuarios y otros sistemas son externos,
hard y soft son parte del sistema).
Modelado del límite hard/soft: Este paso involucra la
descomposición del sistema total en componentes de
hard y soft, y se determinan las interfaces.
Modelado del contexto del software del sistema:
determina el límite del sistema software, en particular
cómo el soft se vincula con los componentes de hard, que
son externos al sistema soft.
14
2. Modelo de Requisitos
Se desarrolla una descripción narrativa
de cada caso de uso.
Cada caso de uso es visto como una
caja negra.
Si los requisitos no se entienden se
puede utilizar un prototipo desechable.
Se identifican requisitos no funcionales
(de calidad, temporales)
Objetivo: definición de los requisitos
funcionales del sistema
15
3.Modelo de Análisis
Se desarrollan modelos estáticos y
dinámicos del sistema.
Los modelos estáticos definen las
relaciones estructurales entre las
clases del dominio del problema.
Los modelos dinámicos se desarrollan
refinando los casos de uso, por medio
de DTE.
conocimiento del dominio del
Objetivo: problema
16
4. Modelo de Diseño
Se desarrolla la arquitectura del sistema.
Del dominio del problema se pasa al

dominio de la solución.
En el modelo de diseño considera la

concurrencia del sistema.
17
Construcción de Software
incremental
Después del diseño arquitectónico se
construye el Soft de manera
incremental.
En cada incremento se construye un

subsistema.
18
Integración de Softwar
incremental
Se hacen pruebas de integración
incrementales basándose en los casos de uso.
Pruebas incrementales de caja blanca en las

que se testean las interfaces entre los objetos
que participan en cada caso de uso.
Cada incremento del soft conforma un

prototipo incremental.
19
Testeo del Sistema
Incluye el chequeo funcional y no
funcional del sistema.
Es una prueba de caja negra.
20
1. FASE DE
MODELADO
ESTRUCTURAL DEL
SISTEMA
21
Modelado Estático
El modelo estático capta los aspectos
estructurales de un problema mediante
clases del mundo real.
El modelado estático es el proceso.
El diagrama de clases es la notación.
22
Modelado Estructural del
dominio del Problema
Entidades del Mundo Real:
Entidades físicas:
Objetos tangibles del
Mundo real
Usuario Humano:
Persona que interactúa
con el sistema
proporcionando entradas
y/o recibiendo salidas.
Observador humano:
Persona que mira las
salidas del sistema pero no
interactúa directamente
con el sistema (no provee
ninguna entrada).
Sistema relevante:
Sistema que se va a
desarrollar o cualquier otro
sistema que posee
interface con este.
Entidad de Información:
Es una entidad de dato
conceptual que es
persistente.
23
Modelado Estático del
Contexto del Sistema
El Contexto del Sistema representa su interfaz
con el exterior.
UML no proporciona diagrama específico pero un

D. de clases o uno de colaboración son válidos.
Puede derivarse:
A partir de las clases externas al sistema y los dispositivos
I/O asociados.
o bien
A partir de los casos de uso considerando actores y
dispositivos que usan para interactuar con el sistema.
24
Modelado Estructural del
contexto del sistema
Diagrama de Contexto del
sistema: Se deben identificar
las entidades externas
Entidad Externa física:
Objetos tangibles del
Mundo real que el sistema
debe detectar o controlar
Usuario Externo:
Persona que interactúa
con el sistema
proporcionando entradas
y/o recibiendo salidas.
Observador Externo:
Persona que mira las
salidas del sistema pero
no interactúa
directamente con el
sistema (no provee
ninguna entrada).
Sistema externo:
Sistema que posee
interface con el sistema.
25
Contexto del Software del
Sistema
El sistema: una clase agregada y
estereotipada como «system».
El entorno: clases externas con las que el
sistema tiene un interfaz.
Estereotipos para las clases externas:

 «external input device»
 «external output device»
 «external I/O device»
 «external user»
 «external timer»
 «external system»
26
Categorización de Clases
Externas
La categorización: es una clasificación estratégica: una
decisión para organizar clases.
Categorizar las clases de esta manera ayuda a
comprender mejor el sistema.
En UML, los estereotipos se utilizan para distinguir entre
los distintos tipos de clases.
Un estereotipo es una subclase de un elemento de
modelado existente (por ejemplo, una aplicación o clase
externa) que se utiliza para representar una distinción de
uso (por ejemplo, el tipo de aplicación o clase externa).
En la notación UML, un estereotipo está encerrado por «»
como ejemplo: «entidad».
27
Categorización de Clases
Externas
Las clases externas se clasifican en función de sus características en el entorno externo, como «sistema externo» o
«usuario externo»
<< External device>>se clasifica además de la siguiente manera:■ external input device: Un dispositivo que solo
proporciona entrada al sistema, por ejemplo, un sensor■ external output device: Un dispositivo que solo recibe salida del
sistema, por ejemplo, un actuador■ external input/output device :Dispositivo que proporciona entrada al sistema y recibe
salida del sistema, por ejemplo, un lector de tarjetas de cajero automático
28
desde las clases externas
Un usuario externo interactuando con
el sistema vía dispositivos I/O standard
se muestra como un «external user».
Si el usuario interactúa a través de

dispositivos I/O específicos de la
aplicación, entonces estos dispositivos
se representan como clases dispositivo
I/O.
29
desde las clases externas
Un «external timer» se usa si la
aplicación necesita eventos externos
para iniciar ciertas acciones en el
sistema.
Un «external system» se necesita

cuando el sistema se conecta a otros
sistemas para enviar o recibir datos.
30
desde actores y clases
externas
Derivar las clases externas a partir de los actores
necesita entender las características de estos y cómo
interactúan con el sistema.
Relación entre actores y clases externas:
Un actor dispositivo I/O equivale a una clase externa dispositivo I/O.
Un actor sistema externo equivale a una clase sistema externa.
Un actor timer se conecta al sistema vía una clase timer externa que
provee eventos temporales al sistema.
Un actor ser humano si se conecta a través de un dispositivo standard
entonces la clase externa es el usuario. Si es a través de interfaces no
standard entonces figuran estos como dispositivos externos.
31
Ej. de Contexto del
Software del Sistema
Diagrama de clases de contexto del sistema bancario

32
2. FASE DE CAPTURA
DE REQUISITOS EN
COMET
33
Resultados a obtener en :
Captura de requisitos:
Diagramas de Casos de Uso.
Documentación de cada diagrama.
34
Modelado de
Casos de Uso
35
Modelado de Casos de Uso
Los requisitos funcionales se definen en
términos de actores y casos de uso.
Un actor participa en un caso de uso.
Un caso de uso define una secuencia
de interacciones entre uno o más
actores y el sistema.
El modelo de casos de uso incorpora a
actores y casos de uso.
36
Actores
Actor: uno o más usuarios que
interactúan con el sistema.
Puede ser un dispositivo externo I/O o

un timer.
En sistemas empotrados los actores

son sólo sensores y actuadores.
37
Actores
El actor esta representado por un humano aún
cuando éste interactúa mediante dispositivos
periféricos.
Ej. de un actor dispositivo I/O que interactúa vía un
sensor.
38
Actores
Un actor puede ser también un timer que
periódicamente manda eventos al sistema.
En aplicaciones de tiempo real es aconsejable tener a

los timer como externos al sistema.
39
Actores
Un sistema externo también puede

participar como actor (primario o
secundario) en un caso de uso.
40
Identificando casos de uso
Secuencia de eventos iniciada por un
actor donde se especifica la interacción
entre éste y el sistema.
No se busca la descomposición
funcional del sistema sino secuencias
de eventos que proporcionan un
resultado a algún actor.
41
Relaciones entre casos de
uso
Cuando los casos de uso se hacen
complejos pueden definirse dependencias
entre ellos.
en UML se distinguen tres relaciones de

dependencia:
Incluye.
Extiende.
Generaliza.
La generalización no se usa en COMET.
42
Ejemplo de Caso de Uso
Por ejemplo, el cliente ATM interactúa
con 3 casos de uso que son distintos
pues proveen resultados distintos:
43
Documentando casos de
uso
Nombre del cdu: único.
Resumen: una o dos frases.
Dependencias: de otros casos de uso
(opcional).
Actores: que participan.
Precondiciones: ciertas antes del cdu.
Descripción: secuencia de pasos. El
sistema es visto como una caja negra.
44
Documentando casos de
uso
Alternativas: narrativa de las

alternativas a la secuencia principal.
Postcondiciones: ciertas tras terminar.
Cuestiones adicionales: planteadas

por discusión con los usuarios reales.
45
Ej. Sacar dinero de un
cajero
Nombre del cdu: sacar dinero.
Resumen: El cliente saca una cantidad
específica de dinero del cajero de su
cuenta bancaria.
Dependencias: ninguna.
Actores: Cliente.
Precondiciones: El cajero está listo
con el mensaje de bienvenida.
46
cajero
Descripción:
El cliente inserta la tarjeta en el lector del cajero.
Si la tarjeta es reconocida se lee el número de la
misma.
El sistema pide la clave al cliente.
El cliente introduce la clave (PIN).
El sistema verifica la fecha de caducidad y si es
robada o extraviada.
Si es válida el sistema comprueba la clave introducida
con la que lleva la tarjeta escrita.
Si el PIN es válido el sistema ve qué cuentas están
disponibles para dicha tarjeta.
El sistema muestra las cuentas disponibles y le solicita
al cliente elija entre “sacar dinero”, “consultar saldo”
y “transferencia”………
47
cajero
Alternativas:
Si el sistema no reconoce la tarjeta entonces es devuelta.
Si la tarjeta ha caducado es confiscada.
Si la tarjeta está extraviada o robada es confiscada.
Si el PIN no es correcto se vuelve a pedir.
Si se introduce el PIN tres veces mal la tarjeta es
confiscada.
Si el sistema determina que no hay suficiente dinero
entonces muestra un mensaje y devuelve la tarjeta.
Si el cajero no tiene dinero se muestra un mensaje, se
devuelve la tarjeta y se apaga el cajero.
Si el cliente introduce “cancelar” se cancela la transacción
y se devuelve la tarjeta.
48
3. FASE DE ANÁLISIS
EN COMET
49
MODELOS DEL ANÁLISIS
Modelado Estático:
Define las relaciones estructurales entre las clases
del dominio del problema. Se utilizan criterios de
estructuración en objetos para determinar los
objetos que serán considerados para el modelo de
análisis.
Modelado Dinámico:
Permite determinar la reacción dinámica del
sistema a diferentes secuencias de eventos
externos.
50
ACTIVIDADES DEL
ANÁLISIS
Modelado Estático:
Es una vista estructural del sistema.
Clases + atributos + relaciones entre clases.
Se modelan clases del dominio del problema
clases reales!
Modelado Máquina de Estados o DTE:

La vista dependiente del estado se define usando
diagrama de estados jerárquicos.
51
ACTIVIDADES DEL
ANÁLISIS
Estructuración de objetos:
Se determinan los Objetos de cada caso de uso.
Se proporcionan criterios de estructuración de
Objetos para ayudar a determinar los objetos
software del sistema
Modelado Dinámico:
Los casos de uso se refinan para mostrar las
interacciones entre ellos.
La interacción entre los objetos de los casos de
uso se refleja en diagramas de interacción.
52
Resultados a Obtener en
la fase:
Análisis:
Diagramas de Clases del Análisis.
Imprescindible cuando hay dispositivos y
sistemas externos!.
Diagramas de Interacción (Colaboración o
Secuencia).
Diagramas de Transición de Estados.
53
Estructuración
en
Clases y Objetos
54
Introducción
Objetivo: determinar los objetos software del

sistema en el dominio del problema.
Descomponer un problema en objetos no tiene una

única solución.
Depende del analista, de la naturaleza del problema,

...
Si los objetos están en la misma clase o en una clase

diferente depende de la naturaleza del problema.
55
Categorización de las clases
de la Aplicación
La categorización clasifica las clases
atendiendo a grupos facilitando el
entendimiento del sistema y su
reutilización.
El número de clases por categoría

depende del ámbito de la aplicación.
56
Categorización de las clases
de la Aplicación
Las clases de aplicaciones se clasifican de acuerdo a la función en la

aplicación, como por ejemplo la clase «entidad» 57
Criterios
Categorizar objetos y clases de software de
acuerdo a los roles que juegan en la
aplicación.
Las cuatro categorías anteriores pueden

ampliarse dependiendo del sistema pero
son comunes a todos.
58
Clases Externas y Clases
Interfaz
El sistema se muestra
como un paquete.
Las clases interfaz

quedan dentro de dicho
paquete.
Las clases interfaz se

conectan uno-a-uno con
las clases externas.
Las clases interfaz se

determinan fácilmente
partiendo de las clases
externas del diagrama de
contexto del sistema.
59
PARTE 2
continuará con la
fase de Análisis
60

01-STR-COMET - Parte 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01-STR-COMET - Parte 1

Cargado por

Copyright:

Formatos disponibles

Unidad 3

"Una versión ampliada del ciclo de vida completo

Whitten, J. ; Bentley, L. ; Barlow, V. Análisis y Diseño de Sistemas de Información. 3ª ed.,

Arquitectura de software basada en componentes: para

Análisis de rendimiento de diseño de Tiempo Real: para

Dr. Hassan Gomaa. George Mason

“Designing Concurrent Distributed and

Prototipo Testeo del

Se basa en conceptos como:

Sistema = conjunto de objetos pasivos y

Provee heurísticas y criterios para

Los requisitos funcionales del sistema se

Cada caso de uso define una secuencia de

Un caso de uso se puede ver a distintos

En el 2.Modelo de Requisitos los requisitos

En el 3.Modelo de Análisis el caso de uso se

En el 4.Modelo de Diseño se desarrolla la

Del dominio del problema se pasa al

En el modelo de diseño considera la

En cada incremento se construye un

Pruebas incrementales de caja blanca en las

Cada incremento del soft conforma un

Es una prueba de caja negra.

El modelado estático es el proceso.

El diagrama de clases es la notación.

UML no proporciona diagrama específico pero un

Estereotipos para las clases externas:

Si el usuario interactúa a través de

Un «external system» se necesita

Diagrama de clases de contexto del sistema bancario

Puede ser un dispositivo externo I/O o

En sistemas empotrados los actores

En aplicaciones de tiempo real es aconsejable tener a

Un sistema externo también puede

en UML se distinguen tres relaciones de

Alternativas: narrativa de las

Postcondiciones: ciertas tras terminar.

Cuestiones adicionales: planteadas

Modelado Máquina de Estados o DTE:

Objetivo: determinar los objetos software del

Descomponer un problema en objetos no tiene una

Depende del analista, de la naturaleza del problema,

Si los objetos están en la misma clase o en una clase

El número de clases por categoría

Las clases de aplicaciones se clasifican de acuerdo a la función en la

Las cuatro categorías anteriores pueden

Las clases interfaz

Las clases interfaz se

Las clases interfaz se

También podría gustarte