Introduccion A SysML

NobleProg
Modelado de Sistemas
con SysML
NobleProg® Limited 2017

All Rights Reserved
Introducción al Curso
Este curso se ofrece en dos variantes para proporcionar una
comprensión práctica de cómo los sistemas pueden ser
modelados, utilizando la versión más reciente (1.4) del Sistema
de Modelado de Sistemas (SysML) de OMG. La notación y la
semántica subyacente de SysML se explican de una manera que
permite a los estudiantes aplicar lo que aprenden, a cualquier
método o herramienta de modelado de sistema adecuado.
All Rights Reserved
NobleProg
Acerca de tu Instructor

All Rights Reserved
NobleProg
Agenda Día 1
• Introducción al modelado de sistemas
• Construcciones comunes y transversales
• Diagramas de Requisitos
• Diagramas de Actividad

All Rights Reserved
NobleProg
Introducción al modelado
de sistemas
¿Qué es un modelo de sistema?

All Rights Reserved
NobleProg
¿Qué es un Sistema?
Un Sistema es un conjunto de elementos que se relacionan entre
sí y con su entorno para alcanzar un propósito (meta, objetivo o
ideal) común.

All Rights Reserved
NobleProg
¿Qué es un Modelo?
Un modelo es una descripción simplificada (abstracción) de un
sistema objeto de estudio realizado por un observador, en el que
intenta describir, en lo que sea relevante al objetivo del estudio,
los elementos del sistema, las relaciones entre éstos y las
relaciones entre el sistema y elementos de su medioambiente.

All Rights Reserved
NobleProg
Metamodelo de un Sistema

All Rights Reserved
NobleProg
Modelar un Sistema
I. El objetivo o propósito del sistema.
II. Los elementos relevantes del sistema, tanto del procesador

como del mecanismo de control.
III. Las interrelaciones relevantes de los elementos del sistema.

All Rights Reserved
NobleProg
Modelar un Sistema
IV. Los elementos relevantes del medioambiente del sistema.
V. Las relaciones relevantes de elementos del sistema con los

de su medioambiente: entradas y salidas.
VI. Subsistema de control del sistema (retroalimentación).
VII. Los atributos emergentes relevantes del sistema

(Propiedades del sistema como un todo).
All Rights Reserved
NobleProg
Modelo céntrico vs
documento centrado

All Rights Reserved
NobleProg
Documento Centrado Modelo Céntrico
• Se enfoca en la especificación. • Requiere comprender el
• Uso de herramientas de elección y comportamiento del sistema.
administrativas. • Se deben relacionar los requisitos
• Informes de calidad y trazabilidad con las funciones.
• Medida de integridad • Completa todas las vistas del

modelo.
• La estructura de especificación es
un modelo funcional estático. • La especificación es incidental.

All Rights Reserved
NobleProg
¿Qué es SysML?
SysML (System Modeling Language) es un lenguaje de
modelado de dominio específico para aplicaciones de sistemas
de ingeniería. Soporta la especificación, análisis, diseño,
verificación y validación de un amplio rango de sistemas y
sistemas de sistemas. SysML obtiene sus raíces del Lenguaje de
modelado unificado (UML).

All Rights Reserved
NobleProg
SysML y UML

All Rights Reserved
NobleProg
Relación SysML y UML

All Rights Reserved
NobleProg
Diagramas de UML

All Rights Reserved
NobleProg
Diagramas de SysML

All Rights Reserved
NobleProg
Ventajas sobre UML
• SysML expresa mejor que UML la semántica de la ingeniería de

sistemas. SysML reduce la predilección por el software propia
de UML y agrega dos diagramas para la administración de
requisitos y análisis de desempeño: diagramas de Requisitos y
diagramas Paramétricos, respectivamente.

All Rights Reserved
NobleProg
Ventajas sobre UML
• SysML es más pequeño y sencillo de aprender que UML.

SysML remueve varias construcciones centradas en el
software, si lo medimos en diagramas todo el lenguaje es más
pequeño: 9 diagramas de SysML vs. 14 diagramas de UML.

All Rights Reserved
NobleProg
Los cuatro pilares de SysML

All Rights Reserved
NobleProg
1. Requisitos
SysML permite a los modeladores definir y especificar los
requisitos de un sistema. SysML admite y puede adaptar la
especificación de requisitos independientemente del nivel de
detalle necesario para el sistema dado, lo que fortalece su
aplicabilidad en una amplia gama de sistemas.

All Rights Reserved
NobleProg
1. Requisitos
Permite a los usuarios refinar y modelar hasta el nivel de detalle
más bajo que necesitan para los requisitos de su sistema de
interés. Por ejemplo, SysML se puede usar para modelar incluso
los componentes de nivel de diseño individuales y los casos de
prueba para un sistema.

All Rights Reserved
NobleProg
2. Estructura
2.1. Jerarquía del Sistema
Hay tres tipos de diagramas para describir la arquitectura

estructural, incluidos el Diagrama de Definición de Bloques
(BDD), el Diagrama de Bloques Internos (IBD) y el Diagrama de
paquetes.

All Rights Reserved
NobleProg
Ejemplo de diagrama de definición de bloques de un refrigerador

All Rights Reserved
NobleProg
2. Estructura
2.2. Estructura Interna
Para los ingenieros de sistemas es fundamental tener la capacidad de

mostrar y comunicar las conexiones internas entre los elementos en
una arquitectura estructural. Con el uso de SysML se puede abordar
este desafío a través de la definición de la vista interna de un bloque
con el Diagrama de Bloques Internos (IBD).

All Rights Reserved
NobleProg
Ejemplo de Diagrama de Bloques Internos de componentes de un refrigerador

All Rights Reserved
NobleProg
3. Comportamiento
El modelado de comportamiento enfatiza el comportamiento del

sistema o un elemento en su dominio para incluir las entradas y
salidas, la secuencia y las condiciones para coordinar otro
comportamiento.

All Rights Reserved
NobleProg
a. Diagrama de Casos de Uso
El diagrama de casos de uso, como su nombre lo indica,
especifica una descripción de una misión o parte interesada que
el sistema tratará. Proporciona los medios para describir la
funcionalidad básica en términos de usos / objetivos del sistema
por parte de los actores.

All Rights Reserved
NobleProg
b. Diagrama de Actividad
Se centran en el uso de elementos de actividad y acciones para
definir y describir el comportamiento del flujo funcional de un
sistema.

All Rights Reserved
NobleProg
c. Diagrama de Máquina de Estado
Se usan normalmente para representar el ciclo de vida de un bloque y
para respaldar el comportamiento del sistema basado en eventos. Los
principales elementos definidos son los estados, que se utilizan para
describir la condición relativa del sistema durante un escenario de
misión. Se pueden usar para hacer la transición de un sistema
durante una simulación de comportamiento de un estado a otro,
donde cambia el comportamiento invocado.
All Rights Reserved
NobleProg
4. Parámetros
Los Diagramas Paramétricos son el aspecto del modelado que
trata con la definición de restricciones para dar a los parámetros
del sistema o propiedades de valor un significado adicional en el
modelo. Los Diagramas Paramétricos son el aspecto del
modelado que trata con la definición de restricciones para dar a
los parámetros del sistema o propiedades de valor un significado
adicional en el modelo.
All Rights Reserved
NobleProg
Ejemplo de diagrama paramétrico simple que muestra la unidad de
almacenamiento y las propiedades de valor necesarias vinculadas a
un análisis para calcular el volumen de un refrigerador.

All Rights Reserved
NobleProg
Construcciones comunes y
transversales
Perfiles y estereotipos

All Rights Reserved
NobleProg
Perfiles y estereotipos
Un perfil es un tipo de paquete que contiene un conjunto de
estereotipos.
Un estereotipo define un nuevo tipo de elemento de modelo

agregando propiedades, restricciones o semántica a un tipo de
elemento de modelo existente.

All Rights Reserved
NobleProg
Cuando crea un perfil, un paquete de estereotipos, está, en
efecto, definiendo un nuevo lenguaje de modelado que es una
extensión de un lenguaje de modelado existente.
Luego puede aplicar un perfil a un paquete, modelo o biblioteca

de modelos. Esto significa que el paquete puede contener los
nuevos tipos de elementos de modelo que existen en el lenguaje
de modelado definido por ese perfil.

All Rights Reserved
NobleProg
El diagrama del paquete, muestra
que el modelo de Confiabilidad
Markov aplica el perfil
SysML4Modelica. Esto indica que
el modelo Markov de
confiabilidad puede contener los
nuevos tipos de elementos de
modelo definidos en el lenguaje
de modelado SysML4Modelica.

All Rights Reserved
NobleProg
Marcos de diagrama
El marco es un rectángulo que se requiere para los diagramas
SysML. El marco debe designar un elemento de modelo que sea
el espacio de nombres predeterminado para los elementos de
modelo incluidos en el marco.

All Rights Reserved
NobleProg
Los siguientes son algunos de los elementos de modelo
designados asociados con los diferentes tipos de diagramas.
• Diagrama de actividad - actividad
• Diagrama de definición de bloque: bloque, paquete o bloque de

restricción
• Diagrama de bloques interno - bloque o bloque de restricción
• Diagrama de paquete - paquete o modelo

All Rights Reserved
NobleProg
• Diagrama paramétrico - bloque o bloque de restricción
• Diagrama de requisitos - paquete o requisito
• Diagrama de secuencia - interacción
• Diagrama de la máquina de estados - máquina de estados
• Diagrama de caso de uso – paquete

All Rights Reserved
NobleProg
El marco puede incluir elementos de borde asociados con el elemento del
modelo designado, como:
• •Puertos para bloques,
• Puntos de entrada / salida en máquinas de estado,
• Puertas en las interacciones,
• Parámetros para las actividades, y
• Parámetros de restricción para bloques de restricción.

All Rights Reserved
NobleProg
Comentarios
Los comentarios pueden
asociarse con cualquier
elemento del modelo y son
muy útiles como un medio
informal para documentar el
modelo.

All Rights Reserved
NobleProg
Asignaciones
Asignación es el término utilizado por los ingenieros de sistemas
para denotar la asociación cruzada organizada (mapeo) de
elementos dentro de las diversas estructuras o jerarquías de un
modelo de usuario. El concepto de "asignación" requiere
flexibilidad adecuada para la especificación abstracta del
sistema, en lugar de un método restringido particular de diseño
del sistema o software.
All Rights Reserved
NobleProg
Representando la asignación en
diagramas
Nombre del Nodo Sintaxis Concreta Referencia de
Sintaxis Abstracta
Asignación de propiedades SysML::Allocation:
derivadas mostradas en el Allocate
compartimiento de un
Bloque.

comentario.

All Rights Reserved
NobleProg
Nombre del Nodo Sintaxis Concreta Referencia de
Sintaxis Abstracta
Las propiedades derivadas de la SysML::Allocation:
asignación se muestran en el Allocate
compartimento de la parte en
el diagrama de bloques interno.
compartimiento de Acción en el
Diagrama de Actividad.
Partición de la actividad de SysML::Allocation:
asignación Allocate
ActivityPartition
Asignación (general) SysML::Allocation:
Allocate
All Rights Reserved
NobleProg
Diagramas de requisitos

All Rights Reserved
NobleProg
Diagramas de requisitos
Este diagrama se utiliza para representar visualmente los
requisitos del sistema y también muestra explícitamente los
distintos tipos de relación entre los requisitos. Se puede utilizar
para crear trazabilidad entre los requisitos del modelo. La
trazabilidad garantiza a las partes interesadas del negocio que el
sistema desarrollado respalda sus requisitos originales.

All Rights Reserved
NobleProg
¿Qué es un requisito?
Un requisito es una “condición o capacidad que necesita el
usuario para resolver un problema o conseguir un objetivo
determinado”. También se aplica a las condiciones que debe
cumplir o poseer un sistema o uno de sus componentes para
satisfacer un contrato, una norma o una especificación.

All Rights Reserved
NobleProg
Modelado de los requisitos atómicos
Un requisito atómico describe MEJORES REQUISITOS
completamente una sola función, • Permite concentrarse en una
característica, necesidad o característica a la vez.
capacidad, incluida toda la • El cambio de requisitos se puede

medir fácilmente
información, detalles, límites y
• Fácilmente relacionado con el análisis
características.
de casos de uso individuales.
Algunas ventajas son: • Permite una clasificación de
importancia clara

All Rights Reserved
NobleProg
MEJOR DESARROLLO MEJOR GESTIÓN
• Cada requerimiento por separado • Bases para un acuerdo claro con

es implementable y comprobable. el cliente
• Las pruebas pasarán o fallarán • Puede ser utilizado para contratos
• Fácil de identificar cambios en el claros y estructura de pago
alcance del proyecto o programa • Se puede asignar valor a cada

requerimiento.

All Rights Reserved
NobleProg
El diagrama de requisitos
muestra cinco requisitos.
Tres de ellos, Hohmann Transfer,
Thruster Burn y Altimetry,
representan requisitos atómicos.
Los otros dos, Especificación de
requisitos de misión y
Especificación de requisitos del
sistema DellSat-77, representan
especificaciones de requisitos
completos.
All Rights Reserved
NobleProg
Trazabilidad de requisitos
La trazabilidad de los requisitos se refiere a la capacidad de
describir y seguir la vida útil de un requisito, tanto en sentido
hacia adelante como hacia atrás (es decir, desde sus orígenes, a
través de su desarrollo y especificación, hasta su posterior
despliegue y uso, y durante todos los períodos de refinamiento
continuo), e iteración en cualquiera de estas fases.

All Rights Reserved
NobleProg
Matriz de trazabilidad de requerimientos
La forma más común de garantizar que haya una trazabilidad

completa de los requisitos es mediante una Matriz de
Trazabilidad de los Requisitos (RTM). La matriz de trazabilidad
se utiliza para verificar que todos los requisitos declarados y
derivados estén asociados con los elementos de diseño,
componentes del sistema, módulos y otros entregables del
proyecto correspondientes.
All Rights Reserved
NobleProg
Diagramas de actividad

All Rights Reserved
NobleProg
Modelado de la lógica basada en el flujo
El diagrama de actividad describe los flujos de control, entrada y

salida entre las acciones. Representa el sistema empresarial y los
flujos de trabajo operacional. Captura acciones y muestra sus
resultados.
Normalmente se usa para el modelado de procesos de negocios y se

usa en situaciones donde todos o la mayoría de los eventos
representan la finalización de acciones generadas internamente.

All Rights Reserved
NobleProg
Acciones vs actividades
Una acción es un tipo de nodo que puede existir dentro de una
actividad; es un nodo que modela una unidad básica de
funcionalidad dentro de la actividad.
Una acción representa alguna forma de procesamiento o

transformación que ocurrirá cuando la actividad se ejecute
durante la operación del sistema.

All Rights Reserved
NobleProg
La notación para una acción básica es un rectángulo de esquinas
redondeadas. Puede introducir cualquier descripción de comportamiento
que desee en una acción; su descripción se muestra como una cadena
dentro del ángulo redondo en un diagrama de actividad. La mayoría de
las veces, los modeladores de sistemas escriben acciones como frases
verbales expresadas en un idioma natural.

All Rights Reserved
NobleProg
Como alternativa a los lenguajes naturales, puede usar lenguajes
formales (como C, Java, Verilog o Modelica) para una acción en
una actividad.
SysML llama a tal declaración una expresión opaca.

All Rights Reserved
NobleProg
Una actividad útil y significativa
siempre consiste en más de
una acción. Conecta las
acciones en una actividad
utilizando bordes que definen
secuencias ordenadas (y en
ocasiones concurrentes).

All Rights Reserved
NobleProg
Comprensión del flujo de token
"Token flow" es un concepto abstracto. Los tokens no son
elementos del modelo. No los crea en el modelo de su sistema y
no los muestra en los diagramas de actividad. La idea de tokens
es inherente al significado que SysML define para actividades,
nodos y bordes.

All Rights Reserved
NobleProg
¿Qué representa un token?
TOKEN DE OBJETO TOKEN DE CONTROL
Un token de objeto representa una Un token de control simplemente

instancia de un bloque, tipo de valor o indica qué acción en una actividad
señal que ha creado en algún lugar de está actualmente habilitada en un
su jerarquía de modelo (para definir un momento particular durante una
tipo de materia, energía o datos). ejecución de la actividad.
Puede haber múltiples tokens de Podría haber múltiples tokens de
objetos que fluyen a través de una control que fluyen a través de una sola
única ejecución de una actividad. ejecución de una actividad.

All Rights Reserved
NobleProg
Flujo de control vs flujo de objetos
OBJECT FLOWS
Un flujo de objetos es el tipo de borde que transporta tokens de

objetos. Utiliza flujos de objetos para transmitir que las instancias
de materia, energía o datos fluyen a través de una actividad de
un nodo a otro cuando la actividad se ejecuta durante la
operación del sistema.

All Rights Reserved
NobleProg
La notación para un flujo de objetos
es una línea sólida con una punta de
flecha abierta. Además de un nodo
de objeto, puede tener un nodo de
decisión, un nodo de combinación,
un nodo de fork o un nodo de unión
en un extremo de un flujo de objetos
para dirigir el flujo de los tokens de
objetos.
Este extracto muestra siete

ejemplos de flujos de objetos.
All Rights Reserved
NobleProg
Transmiten que las acciones en este fragmento de actividad
requieren objetos como entradas y producen objetos como
salidas.
Debe asegurarse de que los nodos de objetos en los extremos

de un flujo de objetos tengan tipos compatibles; el token de
objeto producido como una salida en el extremo de la cola debe
ser aceptable como una entrada en el extremo de la punta de
flecha. Puede satisfacer esta restricción de una de estas dos
maneras:

All Rights Reserved
NobleProg
• Los tipos pueden ser idénticos.

All Rights Reserved
NobleProg
• El tipo ascendente puede ser un subtipo
del tipo descendente.

All Rights Reserved
NobleProg
Flujo de control vs flujo de objetos
CONTROL FLOWS
Un flujo de control es el tipo de borde que transporta tokens de control. Y la

llegada de un token de control permite una acción que está a la espera de
una.
Por lo tanto, utiliza los flujos de control para transmitir las restricciones de
secuencia entre un conjunto de acciones cuando el objeto que fluye en su
actividad no transmite por sí mismos la secuencia deseada.

All Rights Reserved
NobleProg
Este extracto muestra siete ejemplos de flujos de control, que conectan los nodos en la actividad
para definir una secuencia ordenada entre ellos. Cuatro de los nodos son acciones: dos acciones
de comportamiento de llamada, una acción de tiempo de espera y una acción de evento de
aceptación. Cuando una acción se completa, ofrece un token de control en su flujo de control
saliente, y eso permite que comience la siguiente acción en la secuencia.

All Rights Reserved
NobleProg
Modelando las decisiones

All Rights Reserved
NobleProg
Modelando la concurrencia
• Sincronización de
múltiples
actividades.
• Dividiendo el flujo
de control en
múltiples hilos.

All Rights Reserved
NobleProg
Swimlanes y responsabilidad
Las acciones y subactividades se pueden organizar en
Swimlanes en los diagramas de Actividad. Los swimlanes se
utilizan para organizar la responsabilidad de las acciones y
subactividades de acuerdo con la clase. Los swimlanes limitan y
proporcionan una vista de los comportamientos invocados en las
actividades. Consisten en una o más particiones y pueden ser
verticales u horizontales.
All Rights Reserved
NobleProg
Un diagrama de actividad se puede dividir visualmente en Swimlanes, cada uno separado de los
Swimlanes vecinos mediante líneas continuas verticales u horizontales en ambos lados.
Cada Swimlane representa una responsabilidad de parte de la actividad general, y

eventualmente puede ser implementado por uno o más objetos. Cada acción está asignada a un
Swimlane.
Las transiciones pueden cruzar carriles. El enrutamiento de una ruta de transición es no esencial.

All Rights Reserved
NobleProg

Introduccion A SysML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introduccion A SysML

Enviado por

Direitos autorais:

Formatos disponíveis

NobleProg

NobleProg® Limited 2017

NobleProg® Limited 2017

• Introducción al modelado de sistemas

• Construcciones comunes y transversales

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

II. Los elementos relevantes del sistema, tanto del procesador

III. Las interrelaciones relevantes de los elementos del sistema.

NobleProg® Limited 2017

V. Las relaciones relevantes de elementos del sistema con los

VI. Subsistema de control del sistema (retroalimentación).

VII. Los atributos emergentes relevantes del sistema

NobleProg® Limited 2017

• Se enfoca en la especificación. • Requiere comprender el

• Uso de herramientas de elección y comportamiento del sistema.

administrativas. • Se deben relacionar los requisitos

• Informes de calidad y trazabilidad con las funciones.

• Medida de integridad • Completa todas las vistas del

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

• SysML expresa mejor que UML la semántica de la ingeniería de

NobleProg® Limited 2017

• SysML es más pequeño y sencillo de aprender que UML.

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

Hay tres tipos de diagramas para describir la arquitectura

NobleProg® Limited 2017

NobleProg® Limited 2017

Para los ingenieros de sistemas es fundamental tener la capacidad de

NobleProg® Limited 2017

NobleProg® Limited 2017

El modelado de comportamiento enfatiza el comportamiento del

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

Un estereotipo define un nuevo tipo de elemento de modelo

NobleProg® Limited 2017

Luego puede aplicar un perfil a un paquete, modelo o biblioteca

NobleProg® Limited 2017

NobleProg® Limited 2017

NobleProg® Limited 2017

• Diagrama de actividad - actividad

• Diagrama de definición de bloque: bloque, paquete o bloque de

• Diagrama de bloques interno - bloque o bloque de restricción

• Diagrama de paquete - paquete o modelo

• Diagrama de requisitos - paquete o requisito

• Diagrama de secuencia - interacción

• Diagrama de la máquina de estados - máquina de estados

• Diagrama de caso de uso – paquete

NobleProg® Limited 2017

• •Puertos para bloques,