Metodología COMET

Modelo de Ciclo de Vida en COMET

Modelado
Estructural
Usuario
del Sistema
Modelado de
Requerimientos
Modelado del
Análisis
Modelado
del Diseño
Construcción de
software incremental
Integración de
software incremental
Prototipo Testeo del
Cliente
incremental sistema
1. Modelado Estructural
Se enfoca en el modelado estructural estático del sistema en su totalidad (hardware, software,
personas) sin considerar cómo la funcionalidad es distribuida en el hardware y el software.

Modelo Estructural Modelo Estructural Modelado del

del Dominio del del Contexto del Límite
Problema Sistema Hardware/Software

Modelado de
Modelado de
Contexto de
Implementación
Sistema Software
1.1. Modelo Estructural del Dominio del
Problema
Involucra modelar entidades del mundo real (sistemas, usuarios, entidades físicas, entidades de
información) y relaciones entre ellas.
Para el modelado se emplea SysML (System Modelling Language) y Marte (perfil UML para
soportar conceptos de sistemas de tiempo real)
SysML usa diagramas de bloque para representar el sistema en términos de bloques. Los
bloques representan elementos estructurales (hardware, software, personas). Emplea el
estereotipo <<block>>.
Estereotipos provistos por Marte: <<External Input Device>>, <<External Output Device>>,
<<System>>, <<External Timer>>, <<External User>>, <<External System>>
1.1. Modelo Estructural del Dominio del
Problema
1.2. Modelo Estructural del Contexto del
Sistema
Involucra definir los límites entre el sistema en su totalidad (hardware y software) y el ambiente
externo.
Usuarios y sistemas externos son externos al sistema.
Entidades hardware y software son internos al sistema.
1.3. Modelado del Límite
Hardware/Software
Consiste en descomponer el sistema en componentes de hardware y software.
Por cada componente hardware se define su interfaz con el sistema software.
1.4. Modelado de Contexto del Sistema
Software
Consiste en determinar el límite del sistema software, en particular cómo el software se vincula
con los componentes de hardware, que son externos al sistema software.
1.5. Modelado de Implementación
Muestra la implementación de los componentes del sistema (hardware y software),
particularmente su alojamiento en nodos físicos.
2. Modelado de Requerimientos
Consiste en definir los requerimientos funcionales y no funcionales empleando casos de uso.
La descripción de los casos de uso reflejan la visión de comportamiento del sistema.
Las relaciones entre casos de uso proporcionan una visión estructural.
Casos de Uso
Casos de uso son una herramienta para descubrir y registrar los requisitos. Describen historias
de uso del sistema produciendo un resultado observable de valor para un actor particular
◦ Breve: resumen conciso de un párrafo, normalmente del escenario principal con éxito.
◦ Informal: formato de un párrafo en un estilo informal. Múltiples párrafos que comprenden varios
escenarios.
◦ Completo: Mayor elaboración. Se describen con detalle todos los pasos y variaciones, y hay secciones
de apoyo como precondiciones y garantías de éxito (postcondiciones). Para este caso tenemos la
variación de dos columnas.

Escenario es una secuencia específica de acciones e interacciones entre los actores y el sistema
objeto de estudio.
◦ Escenario Principal: es una descripción del camino de éxito típico que satisface los intereses del
personal involucrado.
◦ Escenario Alternativo: son bifurcaciones del escenario principal de éxito.
Plantilla de Caso de Uso
Caso de uso: nombre
Actores: Actor1, Actor2, …
Precondición: Se define la precondición a cumplir
Escenario de Éxito
1
2…
Escenarios Alternativos
2a
2b
Requerimiento no funcional
Poscondiciones: Se define la poscondición.
3. Modelado de Análisis
Consiste en desarrollar modelos estáticos y dinámicos del sistema.
El modelo estático define relaciones estructurales entre las clases del dominio del problema.
Se desarrollan los diagramas de clase.
Modelado dinámico
◦ Diagramas de Interacción. Muestra la realización de los casos de uso mostrando los objetos que
participan en cada caso de uso y cómo interactúan entre ellos (Diagramas de secuencia y diagramas de
comunicación)
◦ Diagramas de Transición de Estados. Se emplean para modelar situaciones dependientes de estados.
Objetos Activos y Pasivos
Objetos Activos: Objetos autónomos que se ejecutan independientemente de otros objetos,
tienen su propio hilo de control, son concurrentes, pueden iniciar acciones que afectan a otros
objetos.
Objetos Pasivos: No tienen su propio hilo de control, tienen operaciones que son ejecutadas
por objetos activos, pueden iniciar acciones en otros objetos pasivos. Una operación de un
objeto pasivo una vez que es invocada por un objeto concurrente, es ejecutada en el hilo de
control del objeto concurrente.
Diagrama de clases
4. Modelado del Diseño
Los diagramas de interacción basados en casos de uso se integran para producir un diagrama de
comunicación integrado.
Se diseña una arquitectura de software concurrente (basada en un patrón de control
centralizado) al aplicar criterios de estructuración en tareas.
Se deben tomar decisiones sobre la característica de los mensajes intercambiados entre las
tareas (sincrónicos o asincrónicos)
Se abordan detalles respecto a la sincronización entre tareas.
Analizar el rendimiento del diseño del sistema software.
Diseñar una arquitectura software basada en componentes.
Escribir pseudocódigo de los componentes.
Comunicación entre tareas
Diagrama de Comunicación Integrado
Arquitectura de software
Diagrama de comunicación concurrente
Diagrama de comunicación concurrente
Diagrama de comunicación concurrente
Diseño Basado en Componentes
Puerto e Interfaces Requeridas para los
Componentes de Entrada
Puertos e Interfaces Provistas por los
Componentes de Salida
Puertos e Interfaces del Componente de
Control Principal