UNIVERSIDAD NACIONAL JORGE BASADRE GROHMANN TACNA

FACULTAD DE INGENIERA

ESCUELA PROFESIONAL DE INGENIERA EN INFORMTICA Y SISTEMAS

UML vs SysML

PRESENTADO POR:
Mara Fernanda Zevallos Gmez (2015-119031)
Jakelyn Sintecala Mulluni (2015-119005)
Lizeth Sanca Padilla (2015-119023)

AO:
Tercero

DOCENTE:
Ing. Gianfranco A. Mlaga

TACNA- PER
2017

1
 NDICE

NDICE DE FIGURAS .............................................................................................................. 4

INTRODUCCIN ..................................................................................................................... 5

CAPTULO I .............................................................................................................................. 6

1.1 OBJETIVOS ..................................................................................................................... 6

1.1.1 Objetivo General: ....................................................................................................... 6

1.1.2 Objetivos Especficos: ............................................................................................... 6

CAPTULO II ............................................................................................................................ 7

2.1 MARCO TERICO ......................................................................................................... 7

CAPTULO III ........................................................................................................................... 9

3.1. UML ................................................................................................................................ 9

3.1.1. Definicin ................................................................................................................. 9

3.1.2. Objetivos ................................................................................................................. 10

3.1.3. Historia .................................................................................................................... 10

3.1.4. Por qu utilizar UML? .......................................................................................... 11

3.1.5. Caractersticas ......................................................................................................... 11

3.1.6. Vistas y diagramas del UML ................................................................................. 12

3.1.7. Proceso unificado de desarrollo de software (The unified Software Development

Process) ............................................................................................................................. 14

3.1.8. Ventajas................................................................................................................... 15

3.1.9. Inconvenientes ........................................................................................................ 16

3.2. SysML .......................................................................................................................... 17

3.2.1. Resumen .................................................................................................................. 17

3.2.2. Origen ..................................................................................................................... 18

3.2.3. Caractersticas ......................................................................................................... 18

3.2.4. Ventajas sobre UML ............................................................................................... 18

2
 3.2.5. Desventajas ............................................................................................................. 19

3.2.6. Estructura de diagramas .......................................................................................... 19

3.3. UML VS SYSML .......................................................................................................... 27

CAPTULO IV ......................................................................................................................... 30

4.1 CONCLUSIONES ..................................................................................................... 30

CAPTULO V .......................................................................................................................... 31

5.1 REFERENCIAS /BIBLIOGRFICAS .......................................................................... 31

3
 NDICE DE FIGURAS
Figura 1. Evolucin de UML......10
Figura 2: Vistas de un software y sus respectivos diagramas.13
Figura 3: Proceso iterativo e incremental...15
Figura 4: UML y SysML........17
Figura 5: Jerarqua de diagramas........20
Figura 6: Ejemplo de diagrama de definicin de bloques...20
Figura 7: Ejemplo de diagrama interno de bloques....21
Figura 8: Ejemplo de diagrama de paquetes...22
Figura 9: Ejemplo de diagrama de requerimientos....22
Figura 10: Ejemplo de diagrama paramtrico....23
Figura 11: Ejemplo de diagrama de actividades.24
Figura 12: Ejemplo de diagramas de casos de uso.....25
Figura 13: Diagramas de estado......26
Figura 14: Ejemplo de diagramas de secuencia......27
Figura 15: Relacin entre SysML y UML......27

4
 INTRODUCCIN

En la actualidad, pensar en un desarrollo de software sin pasar por una etapa de modelado es

imposible. La utilizacin de modelos es una metodologa aceptada y recomendada no solo

acadmicamente sino tambin en el mbito profesional.

Los modelos actuales que representan sistemas de software son creados a travs de lenguajes

de modelado. Como los lenguajes de programacin, estos tambin tienen una sintaxis (la

forma de los elementos del lenguaje) y una semntica (el significado de esos elementos)

definida, adems existen muchos lenguajes de modelado cada uno con diferentes propsitos.

Los lenguajes de modelado son la herramienta que utilizamos para construir nuestros modelos

de sistema.

En la presente monografa analizaremos sobre los lenguajes UML (Lenguaje unificado de

modelado) y SysML (Lenguaje de modelado de sistemas).

5
 CAPTULO I

1.1 OBJETIVOS

1.1.1 Objetivo General:

Analizar los lenguajes de modelado UML y SysML.

1.1.2 Objetivos Especficos:

Dar a conocer cmo funcionan los lenguajes de modelado.
Mencionar las principales caractersticas de los lenguajes de modelado.
Mencionar los tipos de diagramas de los lenguajes modelados UML y
SysML.

6
 CAPTULO II

2.1 MARCO TERICO

Proceso

Un proceso es un conjunto de actividades planificadas que implican la participacin de

un nmero de personas y de recursos materiales coordinados para conseguir un
objetivo previamente identificado. Se estudia la forma en que el servicio disea,
gestiona y mejora sus procesos (acciones) para apoyar su poltica y estrategia al igual
que satisfacer plenamente a sus clientes y otros grupos de inters.(Castillo, 2014,
p.15).

Herramienta

"Se refiere a un instrumento o cierta ayuda tangible para realizar una tarea. Puede
entenderse como un paquete software que soporta una o ms tcnicas. La variedad de
oferta de este tipo de herramientas fue grandsima en sus orgenes, como revelaban
estudios sobre el tema, como el de Gartner"(Gonzles, p.18).

Modelo

Un modelo es una representacin de una realidad compleja. Modelar es desarrollar una

descripcin lo ms exacta posible de un sistema y de las actividades llevadas a cabo en
l. Cuando un proceso es modelado, con ayuda de una representacin grfica
(diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes
entre distintas actividades, analizar cada actividad, definir los puntos de contacto con
otros procesos, as como identificar los subprocesos comprendidos. Al mismo tiempo,
los problemas existentes pueden ponerse de manifiesto claramente dando la
oportunidad para iniciar acciones de mejora. (Brunello y Rocha, 2010, p.2).

Diagrama

"Es establecer una representacin visual de los procesos y subprocesos, lo que permite
obtener una informacin preliminar sobre la amplitud de los mismos, sus
interrelaciones, sus tiempos y sus actividades."(Brunello y Rocha, 2010, p.2).

RUP

7
 El proceso unificado Rational (RUP), es un ejemplo de un modelo de proceso
moderno que proviene del trabajo de UML y el asociado Proceso Unificado de
Desarrollo de Software. El RUP es un modelo en fases que identifica cuatro fases
diferentes en el proceso de software. (Sommerville, 2005, p. 76).
BDD
Base de datos distribuidas (BDD) es un conjunto de dos o ms sistemas de base de
datos no necesariamente homogneos, lgicamente interrelacionados e integrados e
integrados mediante una red de ordenadores, caracterizando un sistema distribuido.
(Bentez y Arias, 2017, p. 95).
Sistema
Define a los sistemas como el conjunto de elementos organizados que se encuentran
en interaccin los cuales buscan una meta o metas comunes operando para ellos sobre
una informacin y sobre una energa o materias u organismo en referencia temporal
para producir como salida la informacin o energa, materia u organismo. (Kendall y
Kendall, 1998).

8
 CAPTULO III

3.1. UML

3.1.1. Definicin
UML son las siglas de Unified Modeling Language o Lenguaje Unificado de
Modelado. Se trata de un estndar que se ha adoptado a nivel internacional por
numerosos organismos y empresas para crear esquemas, diagramas y
documentacin relativa a los desarrollos de software. Impulsado por el Object
Management Group

UML es una abreviacin para Lenguaje Unificado de Modelado, cada una de estas
palabras habla sobre un aspecto importante del UML (Sinan, 2003):

Lenguaje: Un lenguaje nos permite comunicarnos acerca de un sujeto. En el

desarrollo de un sistema, el sujeto incluye los requerimientos y el sistema. Sin
un lenguaje, es difcil para los miembros de un equipo comunicarse y colaborar
satisfactoriamente en el desarrollo del sistema.
Modelo: Un modelo es la representacin de un sujeto. Un modelo captura un
conjunto de ideas conocidas como abstracciones acerca de este sujeto. Sin un
modelo, es muy difcil para los miembros de un equipo tener un entendimiento
comn de los requerimientos y del sistema, y para ellos considerar el impacto
de cambios que ocurre mientras el sistema est siendo desarrollado. Es
importante destacar que un modelo UML describe lo que supuestamente har
un sistema, pero no dice como implementar dicho sistema.
Unificado: El trmino unificado se refiere al hecho de que el Object
Management Group (OMG), una organizacin de estandarizacin reconocida
por la industria, y Rational Software Corporation crearon el UML para traer
juntos los sistemas de informacin y las mejores prcticas de ingeniera en la
industria y tecnologa. Estas prcticas involucran tcnicas de aplicacin que
nos permite desarrollar sistemas ms exitosos.

Es un lenguaje de modelado visual de propsito general orientado a objetos. UML

es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas
para permitir una comunicacin. En este caso, este lenguaje se centra en la
representacin grfica de un sistema.

9
3.1.2. Objetivos
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

Visualizar: UML permite expresar de una forma grfica un sistema de forma

que otro lo puede entender.
Especificar: UML permite especificar cules son las caractersticas de un
sistema antes de su construccin. Es construir modelos precisos, no ambiguos y
completos.
Construir: A partir de los modelos especificados se pueden construir los
sistemas diseados.
Documentar: Los propios elementos grficos sirven como documentacin del
sistema desarrollado que pueden servir para su futura revisin

3.1.3. Historia
El lenguaje UML comenz a gestarse en octubre de 1994, cuando Rumbaugh se
uni a la compaa Rational fundada por Booch (dos respetados investigadores en
el rea de metodologa del software). El objetivo de ambos era unificar dos mtodos
que haban desarrollado: el mtodo Booch y el OMT (Object Modelling Tool ). El
primer borrador apareci en octubre de 1995. En esa misma poca otro reputado
investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas tres
personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la
colaboracin de otras empresas para que aportaran sus ideas. Todas estas
colaboraciones condujeron a la definicin de la primera versin de UML.

Figura 1: Evolucin de UML

10
 Esta primera versin se ofreci a un grupo de trabajo para convertirlo en 1997 en
un estndar del OMG (Object Management Group). Este grupo, que gestiona
estndares relacionados con la tecnologa orientada a objetos (metodologas, bases
de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una
nueva versin de UML (la 1.1), que fue adoptada por el OMG como estndar en
noviembre de 1997.

Desde aquella versin ha habido varias revisiones que gestiona la OMG Revision
Task Force.

3.1.4. Por qu utilizar UML?

Hoy en da, es necesario contar con un plan de desarrollo bien estructurado y
organizado, donde todas las personas involucradas tales como desarrolladores
(quienes realizan el cdigo de un sistema), usuarios (quienes utilizan el producto
final) y clientes (quienes pagan por el desarrollo) entiendan lo que har el sistema
que se va a desarrollar. En este sentido, un sistema elaborado bajo el concepto
UML debe ser exacto, consistente, fcil de comunicar a otros, fcil de cambiar y
entendible. Por lo anterior expuesto, la importancia y la ventaja de utilizar UML
radica en que an cuando los usuarios y clientes no conozcan de programacin,
sern capaces de entender los diagramas de especificaciones elaborados bajo este
concepto que sern entregados a los desarrolladores. Este modelo sirve para
impulsar el desarrollo del software del sistema. Si bien es cierto que el UML es un
lenguaje entendible por todas las personas involucradas, entonces tanto clientes
como usuarios podrn hacer modificaciones a las especificaciones presentadas
hasta lograr que stas cumplan con todas sus necesidades. Otra ventaja del UML es
que el modelo describe lo que supuestamente har un sistema, pero no dice como
implementar dicho sistema, es decir, es independiente del lenguaje de programacin
utilizado.

3.1.5. Caractersticas
UML ofrece vocabulario y reglas:
Para crear y leer modelos bien formados
Que constituyen los planos de un sistema software.

11
 UML es independiente del Proceso de desarrollo. Un uso ptimo se consigue
en procesos dirigidos por casos de uso, centrados en la arquitectura, iterativos e
incrementales
Proceso Unificado de Desarrollo (RUP) :
El modelo UML de un sistema consiste en:
Un conjunto de elementos de modelado que definen la estructura, el
comportamiento y la funcionalidad del sistema y que se agrupan en una
base de datos nica.
La presentacin de esos conceptos a travs de mltiples diagramas con el
fin de introducirlos, editarlos, y hacerlos comprensibles.
Los diagramas pueden agruparse en vistas, cada una enfocada a un aspecto
particular del sistema.
La gestin de un modelo UML requiere una herramienta especfica que
mantenga la consistencia del modelo.
Cubre las diferentes vistas de la arquitectura de un sistema mientras evoluciona
a travs del ciclo de vida del desarrollo de software
Vistas Software (estticas, dinmicas, etc.)
Flexibilidad para admitir cambios no previstos durante el diseo o el rediseo.
La capacidad de diagramacin, al permitir especificar visualmente roles,
actores, procesos, relaciones, entre otros, identificados en un sistema de
informacin.
Los diferentes tipos de diagramas que soporta la herramienta ofrece ilustrar
estructuras y comportamientos organizacionales.

3.1.6. Vistas y diagramas del UML

En la construccin del software usando UML, existen cinco vistas para visualizar,
especificar, construir y documentar la arquitectura del software. UML permite
representar cada vista mediante un grupo de diagramas.

Vista de casos de uso: Muestra la funcionalidad del sistema desde el punto de

vista de un actor externo que interacta con l.
Vista de diseo: Muestra la funcionalidad del diseo dentro del sistema en
trminos de la estructura esttica y comportamiento dinmico del sistema.

12
 Vista de procesos: Muestra la concurrencia del sistema, comunicacin y
sincronizacin.
Vista de implementacin: Muestra la organizacin de los componentes de
cdigo.
Vista de implantacin: Muestra la implantacin del sistema en la arquitectura
fsica.

En UML se definen nueve diagramas, los cuales se pueden mezclar en cada vista.

Diagrama de casos de uso.

Diagrama de clases.
Diagrama de objetos.
Diagrama de secuencia.
Diagrama de colaboracin.
Diagrama de estados.
Diagrama de actividades.
Diagrama de componentes.
Diagrama de despliegue.

Figura 2: Vistas de un software y sus respectivos diagramas

La finalidad de los diagramas es presentar diversas perspectivas de un Sistema, a

los cuales se les conoce como Modelo. El modelo UML describe lo que
supuestamente har un Sistema, pero no dice cmo implementar dicho sistema.
13
3.1.7. Proceso unificado de desarrollo de software (The unified Software
Development Process)
Un proceso de desarrollo de software es un mtodo de organizar las actividades
relacionadas con la creacin, presentacin y mantenimientos de los sistemas de
software.
Aunque UML es bastante independiente del proceso de desarrollo que se siga, los
mismos creadores de UML (Jacobson,Boch y Rumbaugh) han propuesto su propia
metodologa de desarrollo, denominada el Proceso Unificado de Desarrollo.
El Proceso Unificado est basado en componentes, lo cual quiere decir que el
sistema software en construccin est formado por componentes software
interconectados a travs de interfaces bien definidos.
Adems, el Proceso Unificado utiliza el UML para expresar grficamente todos
los esquemas de un sistema software.
Pero, realmente, los aspectos que definen este Proceso Unificado son tres:
Dirigido por los casos de uso: acciones realizadas (interaccin) entre los
usuarios y el sistema.
Se centrada en el diseo de una arquitectura central, la cual gua el proceso de
construccin de software
Utiliza un desarrollo iterativo e incremental
Las iteraciones son controladas sobre los diferentes pasos del proceso
Es incremental porque en cada iteracin el software se va ampliando y
mejorando
Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento
secuencial de un sistema a travs de mltiples ciclos de desarrollo, anlisis,
diseo, implementacin y pruebas. El desarrollo iterativo e incremental genera:
Reduccin de los riesgos basndose en una retroalimentacin temprana
Mayor flexibilidad para manejar cambios nuevos o modificaciones a los
mismo
La complejidad nunca resulta abrumadora
Se produce retroalimentacin en una edad temprana, porque la
implementacin se efecta rpidamente con una parte pequea del sistema

14
 Figura 3: Proceso iterativo e incremental

3.1.8. Ventajas
Es estndar => Facilita la comunicacin
Est basado en metamodelo con una semntica bien definida
Se basa en una notacin grfica concisa y fcil de aprender y utilizar
Se puede utilizar para modelar sistemas software en diversos dominios:
Sistemas de informacin empresariales, Sistemas WEB, sistemas crticos
y de tiempo real, etc.
Incluso en sistemas que no son software
Es fcilmente extensible
Captura las partes esenciales del sistema, a travs de una abstraccin y se
plasma en una notacin grfica, esto se conoce como modelado visual.
Maneja a travs del modelado visual, la complejidad de los sistemas al analizar
o disear.
Modelar sistemas (y no slo de software) utilizando conceptos orientados a
objetos.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin
crtica.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.

15
 La formalidad, la extensibilidad, la difusin y la enorme cantidad de
herramientas de soporte existentes para el UML, lo imponen como el estndar
ms adecuado

3.1.9. Inconvenientes
Est fuertemente enfocado al software y los ingenieros de sistemas estn
buscando un lenguaje de modelado que permita especificar sistemas complejos
que incluyan no slo componentes de software (por ejemplo, hardware,
informacin, procesos, personal e instalaciones).
UML no es una metodologa
Falta integracin con respecto de otras tcnicas tales como patrones de diseo,
interfaces de usuario, documentacin, etc.
UML no es un mtodo de desarrollo por lo que es independiente del ciclo de
desarrollo
UML no se presta con facilidad al diseo de sistemas distribuidos.
UML es excesivamente complejo (y no est del todo libre del ambigedades):
el 80% de los problemas pueden modelarse usando alrededor del 20% de UML

El tiempo: Para que funcione correctamente, los diagramas UML deben estar
sincronizados con el cdigo de software que requiere tiempo para establecer y
mantener, y aade trabajo a un proyecto de desarrollo de software. Las
pequeas empresas y desarrolladores independientes podran no ser capaces de
manejar la cantidad aadida de trabajo necesario para sincronizar el cdigo.
No siempre est claro quin se beneficia de un diagrama UML. De acuerdo con
un artculo publicado en el sitio web de Software Eiffel, UML no es ventajoso
para los desarrolladores de software, sobre todo porque los desarrolladores de
software trabajan con cdigo, no imgenes o diagramas. Un diagrama UML
puede ser beneficioso para proyectar los administradores o directivos para
ilustrar cmo una herramienta de software va a funcionar, pero puede ser ms
fcil dibujar el diagrama en una pizarra o un pedazo de papel, en lugar de
tomar el tiempo para aprender el lenguaje UML.
Demasiado nfasis en el diseo

16
 UML pone mucho nfasis en el diseo, lo cual puede ser problemtico para
algunos desarrolladores y empresas. En cuanto a un mbito de aplicacin de
software : un diagrama UML puede conducir a los participantes del proyecto
de software a sobre-analizar los problemas, as las personas pierden el
enfoque al pasar demasiado tiempo y atencin en las caractersticas del
software.

3.2. SysML

3.2.1. Resumen
Es un lenguaje de modelado especfico en el campo de la ingeniera de sistemas.
Permite la especificacin, anlisis, diseo, verificacin y validacin de muchos
sistemas y sistemas-de-sistemas. Originalmente, SysML ha sido desarrollado como
parte de una especificacin de proyecto de cdigo abierto, e incluye una licencia de
cdigo abierto para la distribucin y uso.

ste se basa en UML e implica el modelado de bloques en lugar de modelar clases,

proporcionando as un vocabulario ms adecuado para la Ingeniera de Sistemas.
Un bloque abarca software, hardware, datos, procesos, personal e instalaciones.

SysML reutiliza un subconjunto de UML2 (UML4SysML) y define sus propias

extensiones. Por lo tanto, incluye nueve diagramas en lugar de los trece diagramas
de UML2, por lo que es un lenguaje ms pequeo que es ms fcil de aprender y
aplicar.

Figura 4: UML y SysML

17
3.2.2. Origen
En septiembre de 2001, el Grupo de Gestin de Objetos (OMG), junto con
INCOSE, fundaron el Grupo de Inters Especial de Dominios de Ingeniera de
Sistemas (SE DSIG) para desarrollar una extensin estandarizada de UML. De
acuerdo con el proceso de normalizacin de OMG, una solicitud de informacin
(RFI) fue publicado en febrero de 2002 para obtener informacin sobre los
requisitos de la extensin UML. En marzo de 2003, se formul una Solicitud de
Propuesta (RFP) titulada "UML for Systems Engineering" para describir un marco
aproximado e invitar a presentar propuestas especficas.

En mayo de 2003 se cre un grupo de trabajo con el nombre SysML Partners. En

verano 2005, el grupo se dividi en dos (SysML Partners y SysML Submission
Team) debido a disputas. En noviembre de 2005, los dos grupos presentaron
especificaciones SysML competidoras a OMG. Esto caus cierta confusin.

A principios de 2006, los grupos de trabajo se renen nuevamente (SysML Merge

Team). Finalmente, hubo una especificacin comn al final de todo el proceso,
evitando un voto crucial.

A finales de abril de 2006, SysML fue aceptado como un estndar. OMG public
SysMLTM Versin 1.0 como un estndar oficial en septiembre de 2007.

3.2.3. Caractersticas
Compatible con los nueve tipos de diagramas SysML.
Hipervnculos a diagramas, documentos o pginas web.
Subproyectos compartidos para trabajar en equipo.
Asigne elementos a diferentes capas del diagrama, que se pueden ver u ocultar.
Nmero ilimitado de operaciones de deshacer/rehacer.
Intercambio de modelos mediante el estndar XMI.
Diagramas SysML integrados en el modelado UML.
Documentacin automatizada de diagramas y elementos SysML.

3.2.4. Ventajas sobre UML

La semntica de SysML es ms rico y ms flexible: SysML impone menos
restricciones relacionadas con la visin centrada en el software UML, y aade
dos nuevos tipos de diagramas: Diagrama de los requisitos se puede utilizar

18
 para la gestin de requisitos, mientras que diagrama paramtrico puede ser
usado para anlisis de rendimiento y el anlisis cuantitativo. Con estas mejoras,
SysML es capaz de modelar una amplia gama de sistemas, incluyendo tanto
hardware de software, informacin, procesos, personal, o equipo.
SysML es un lenguaje UML ms pequeo por lo que es fcil de aprender y
usar. SysML elimina muchos conceptos de UML demasiado atadas a su visin
centrada en el software. Todo el lenguaje SysML es ms pequeo, tanto en
nmero de tipos de diagramas y nmero de conceptos totales.
SysML gestionar mejor notaciones tabulares. Se proporciona tablas de
beneficios flexibles que soportan la asignacin de los requisitos, la asignacin
funcional, y la asignacin estructural, lo que facilita la automatizacin de la
verificacin y validacin.
Los conceptos SysML para ampliar las capacidades de UML y estn
arquitectnicamente alineados con el estndar IEEE-Std-1471-2000.
Es una metodologa asociada a UML, con lo cual se presume de fcil
aprendizaje para aquellos que conozcan esta metodologa.
Existen sistemas especficos en el mercado que estn adaptados a esta
metodologa, como los mencionados anteriormente Enterprise Architect,
Visual Paradigm, entre otros.

3.2.5. Desventajas
Si bien este enfoque es una adaptacin de UML y es fcil de ser interpretado
por un ingeniero de software, no est claro si podra ser comprendido
fcilmente por un usuario final (gerente, usuario de la aplicacin), por lo que
no sera muy eficiente utilizar este mtodo para la captura de conocimiento y
su posterior validacin.
Hereda muchos de los problemas asociados con UML, como una notacin
compleja y semntica imprecisa.

3.2.6. Estructura de diagramas

19
 Figura 5: Jerarqua de diagramas

3.2.6.1. Diagramas de estructura

Diagrama de definicin de bloques (Block Definition Diagram)
Muestra la estructura del sistema como componentes junto con sus
propiedades, operaciones y relaciones. til para anlisis y diseo de
sistemas.
Proporciona una representacin en caja negra de un bloque de sistema, es
decir, bloque principal, junto con la jerarqua de sus bloques compuestos;
puede incluir bloques de cualquier tipo incluyendo software, hardware, etc.
En comparacin con UML2, el BDD SysML redefine el diagrama de clases
reemplazando clases con bloques e introduciendo puertos de flujo.

Figura 6: Ejemplo de diagrama de definicin de bloques

20
 Diagrama interno de bloques (Internal Block Diagram)
Muestra la estructura interna de componentes, incluyendo sus partes y
conectores. til para anlisis y diseo de sistemas.
Proporciona el cuadro blanco o la vista interna de un bloque del sistema y
suele ser instanciado desde el Diagrama de Definicin de Bloques (BDD)
para representar el ensamblaje final de todos los bloques dentro del bloque
principal del sistema.
Los bloques compuestos del BDD se instancian en el IBD como partes.
Estas piezas se montan a travs de conectores, conectndolos directamente
o a travs de sus puertos (puertos estndar con interfaces expuestas y / o
puertos de flujo).
En comparacin con UML2, el SysML IBD redefine el diagrama de
estructura compuesta por bloques de soporte y puertos de flujo.

Figura 7: Ejemplo de diagrama interno de bloques

Diagrama de paquetes (Package Diagram)

Muestra como un modelo se organiza en paquetes, vistas y puntos de vista.
til para manejo de modelos.
Generalmente se agrupan los elementos del mismo tipo en un paquete,
aunque la organizacin depende de los autores del modelado, ya que se
pueden agrupar por diagramas, etc.
Sincroniza la organizacin del sistema que se est diseando.

21
 Figura 8: Ejemplo de diagrama de paquetes

3.2.6.2. Diagrama de requerimientos (Requirement Diagram)

Muestra los requerimientos del sistema y sus relaciones con otros elementos.
til para ingeniera de requerimientos.

El estereotipo requirement representa un requerimiento basado en texto.

Este tipo de diagrama modela una jerarqua de requerimientos y tambin no

est presente en UML 2.X pero se recomienda su uso para el desarrollo de
Software.

Figura 9: Ejemplo de diagrama de requerimientos

22
3.2.6.3. Diagrama paramtrico (Parametric Diagram)
Muestra restricciones paramtricas entre elementos estructurales. til para
anlisis cuantitativo y de rendimiento.
El diagrama paramtrico est destinado a soportar el anlisis del sistema
(rendimiento, fiabilidad, etc.) mediante la definicin de bloques de
restricciones. Un bloque de restriccin expresa una ecuacin matemtica y sus
parmetros, algunos de los cuales pueden corresponder a las propiedades del
bloque del sistema.

Para empezar, de manera similar al proceso de creacin de un BDD para

definir un bloque antes de crear el IBD, las restricciones de bloques se definen
en un diagrama de clases. Una vez hecho esto, se puede crear un diagrama
paramtrico:

Las restricciones de bloques se instancian como propiedades de restriccin

y heredan los parmetros de la restriccin de bloque (nota: no hay concepto
de entrada y salida en estos parmetros de restriccin)
Las propiedades del sistema se agregan y pueden asociarse con propiedades
de bloque.
Los conectores se utilizan para vincular todas las propiedades de los
sistemas y propiedades de restriccin.

Figura 10: Ejemplo de diagrama paramtrico

3.2.6.4. Diagramas de comportamiento

Diagrama de actividades (Activity Diagram)

23
 Muestra el comportamiento y el flujo de datos. til para anlisis funcional.
Son la versin moderna de los diagramas de flujo; representa etapas de un
proceso, a menudo haciendo uso de "pines de entrada y salida" que
corresponden respectivamente al tipo de elemento requerido como entrada
de una actividad o accin, y el elemento generado como una salida.
Si una accin o actividad corresponde a una operacin de bloque, es
posible asegurar que los tipos de entrada y salida de esta actividad sean
consistentes con la firma de operacin de bloque.
Todas las definiciones de diagramas de actividad utilizadas en UML
tambin se aplican a SysML.
SysML ha aadido un par de extensiones:
Con UML, el control slo puede permitir que se inicien las acciones.
SysML extiende el control para apoyar.
Desactivacin de acciones que ya se estn ejecutando.
Definicin del caudal: continuo o discreto.
Definicin de la tasa y probabilidad en los flujos de control o de
objetos.

Figura 11: Ejemplo de diagrama de actividades

Diagrama de casos de uso (Use Case Diagram)

24
 Muestra los requerimientos funcionales del sistema como transacciones que
son significativas a los usuarios. til para especificar requerimientos
funcionales. Describe la utilizacin del sistema por otros sistemas, dispositivos
o usuarios.
Las mismas tcnicas de modelado UML se aplican a SysML, donde los
diagramas de casos de uso pretenden identificar a los actores y utilizar los
casos desde una perspectiva de usabilidad, es decir, interacciones actor /
sistema.

Figura 12: Ejemplo de diagramas de casos de uso

Diagrama de Estados (State Machine Diagram)
Muestra el comportamiento del sistema como secuencias de estados que un
componente o interaccin experimenta en respuesta a eventos. til para diseo
y simulacin de sistemas. Genera cdigo rpidamente.
Proporcionan una manera de definir un ciclo de vida de bloque que todas las
instancias deben cumplir. Un ciclo de vida define todos los estados posibles
para un bloque y los eventos y condiciones que definen las transiciones de
estado.
Solamente los bloques complejos, o importantes desde una perspectiva
empresarial, deben tener un diagrama de estado.
Todas las definiciones de diagramas de estado utilizadas en UML tambin se
aplican a SysML.

25
 stm HSUVOperationalStates

Off keyOff/

start[in neutral]/start engine shutOff/stop engine Nominal

states only

Operate

Idle

accelerate/
when (speed = 0)

releaseBrake/

Accelerating/
Braking
Cruising

engageBrake/

Figura 13: Diagramas de estado

Diagrama de secuencia (Sequence Diagram)

Muestra el comportamiento del sistema como interacciones entre componentes.
til para anlisis y diseo de sistemas.
Un diagrama de secuencia representa los elementos involucrados en un
escenario o una interaccin, y los mensajes que se intercambian en un orden
cronolgico.
Los elementos en un diagrama de secuencia estn representados por una vida.
Estas vidas pueden ser instancias genricas o instancias de bloques definidos
en el modelo.
Todas las definiciones del diagrama de secuencia utilizadas en UML tambin
se aplican a SysML: mensajes sncronos / asincrnicos, operadores (por
ejemplo, alt, loop, opt, par), referencias a otros diagramas de secuencia, etc.

26
 Figura 14: Ejemplo de diagramas de secuencia

3.3. UML VS SYSML

SysML se basa en UML 2, es una extensin suya.

Figura 15: Relacin entre SysML y UML

A continuacin veremos algunas similitudes y diferencias entre ambos modelos:

Criterios UML SYSML

Significado UML son las siglas de SysML System Modelling
Unified Modeling Languageo Lenguaje de
LanguageoLenguaje Modelado de Sistemas.
Unificado de Modelado.

Enfoque UML est fuertemente SysML est enfocado en

enfocado al software. especificar sistemas
complejos que incluyan

27
 componentes de software,
hardware, informacin,
procesos, personal e
instalaciones.

Diagramas UML 2.0 soporta 13 SysML soporta 9 diagramas:

diagramas divididos en dos
Diagrama de Estructura
grupos generales:
Diagrama de
Diagramas de Modelado definicin de bloques
Estructurado Diagrama interno de
Diagramas de bloques
paquetes Diagrama de
Diagramas paquetes
estructurales o de Diagrama de
clases Requerimientos
Diagramas de objetos Diagrama Paramtrico
Diagramas de Diagrama de
estructuras Comportamiento
compuestas Diagrama de
Diagramas de actividades
componentes Diagrama de casos de
diagramas de uso
despliegue Diagrama de estados
Diagramas de Modelado Diagrama de
de Comportamiento secuencia
Diagramas de
comportamiento
Diagramas de Casos de
Uso
Diagramas de
actividades
Diagramas de mquina
de estados
Diagramas de
comunicaciones
Diagramas de
secuencia
Diagramas de tiempos
Diagramas de
descripcin de la
interaccin

28
 Metodologa UML no es una metodologa SysML no impone una
metodologa o mtodo de
trabajo, es una notacin
estndar.

Semntica UML prescribe una notacinComparado con UML, la

estndar y semnticas
semntica de SysML es ms
esenciales para el modelado
rico y ms flexible. SysML
de un sistema orientado a impone menos restricciones
objetos. relacionadas con la visin
centrada en el software
Carencia de una semntica
UML.
precisa

Objetivos Visualizar: UML permite Conocer y analizar el

expresar de una forma problema a ser resuelto,
grfica un sistema de los objetivos del sistema
forma que otro lo puede y las medidas de la
entender. efectividad.
Especificar: UML permite Dividir el diseo del
especificar cules son las sistema en componentes
caractersticas de un que satisfacen los
sistema antes de su requerimientos del
construccin. Es construir sistema.
modelos precisos, no Evaluar y seleccionar
ambiguos y completos. soluciones preferidas que
Construir: A partir de los cumplan con los
modelos especificados se requerimientos del
pueden construir los sistema y proporcionen el
sistemas diseados. ptimo balance.
Documentar: Los propios Supervisar los
elementos grficos sirven requerimientos de los
como documentacin del componentes y la
sistema desarrollado que verificacin de los
pueden servir para su resultados.
futura revisin

ltima versin UML 2.5 SYSML 1.4

29
 CAPTULO IV

4.1 CONCLUSIONES

Los lenguajes de modelado tienen diferentes objetivos: UML es un lenguaje que tiene

como funcin visualizar, especificar, construir y documentar, en cambio SysML es un

lenguaje que soporta la especificacin, anlisis, diseo, verificacin y validacin de un

amplio rango de sistemas.

Las caractersticas de los lenguajes de modelado nos ayudan a ver las diferencias entre

ambos lenguajes, para as poder ver cul de los dos lenguajes es mejor.

Mencionado los tipos de diagramas, llegamos en conclusin que ciertos tipos de

diagramas de SysML son iguales a los diagramas de UML, ya que OMG tom como

base a UML para el desarrollo de SysML.

30
 CAPTULO V

5.1 REFERENCIAS /BIBLIOGRFICAS

Benitez M. y Arias A. (2017) Curso de Introduccin a la Administracin de Bases de

Datos. IT Campus Academy
Brunnello, M; Rocha, M. (2010); Modelado de Procesos, (Actualizacin 2011).
Cceres, E. A. (2014). Anlisis y Diseo de Sistemas de Informacin.
Castillo, J. (2014).Seleccin y contratacin de personal.
Fernndez Snchez, J. L. Los Modelos en la Ingeniera de Sistemas. Recuperado de
https://www.altova.com/es/umodel/sysml.html
Finance, G. (2010). SysML modelling language explained. Recuperado de
http://ayudamosconocer.com/significados/letra-s/sysml.php
Garimella, K, Lees, M., & Williams, B. (2008). BPM (Gerencia de procesos de
negocio). Introduccin a BPM.
Ghione, B. S. (2010). Fundamentos de visualizacin de requerimientos de
software (Doctoral dissertation, Facultad de Informtica).
Gonzlez, M., Parra, C., Framin, J., & Nieto, J. Implantacin del reconocimiento de
voz en la ugc de endocrinologa y nutricin: modelado y simulacin.
Kendall y Kendall(1998).Anlisis y Diseo de Sistemas.4ta edicin Prentice Hall

OMG, O. (2012). Systems modeling language (omg sysml).Recuperado de

http://www.authorstream.com/Presentation/ediondo69-262461-sysml-education-ppt-
powerpoint/
Schmuller, J. (2003). Aprendiendo UML en 24 Horas. Pearson Education.
Sommerville , I.(2005) Ingeniera de Software. Editorial Pearson
Weilkiens, T. (2011). Systems engineering with SysML/UML: modeling, analysis,
design. Morgan Kaufmann.

31