Capítulo 2: Estudio del Estado del Arte
2. NOTACIÓN UML
UML (Unified Modeling Language o Lenguaje de Modelado Unificado) es una notación muy utilizada para el análisis y el diseño software. Considerado durante muchos años un estándar de facto, en 2005 fue aceptado por la ISO como un estándar (ISO/IEC 19501:2005) en su versión UML 1.4.2. Actualmente la última versión es UML 2.0, que incorpora algunas mejoras sobre el estándar.
La generalización en el uso de UML se debe a diversos factores, entre los que se puede destacar:
UML permite modelar sistemas con un nivel de abstracción elevado, pero reflejando bien cómo debe ser el producto final, ya que se puede modelar el sistema desde diversas perspectivas, gracias a los trece tipos de diagramas de UML 2.0, que se describirán detalladamente más adelante. UML no está ligado a una metodología concreta, es decir,
independientemente de la metodología que se utilice para su análisis y diseño, los resultados se pueden representar UML.
Existen numerosas herramientas tanto comerciales como de libre distribución en el mercado para el modelado en UML. También es posible transferir un modelo determinado a otra herramienta utilizando el estándar XML, que se tratará en profundidad en el apartado [4. XML Y XMI].
UML extiende su funcionalidad con perfiles, algunos de ellos aceptados formalmente por la OMG3, como: Perfil UML para Mecanismos y Características para modelar la calidad de servicio y tolerancia a fallos - UML Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms-; Perfil UML para planificabilidad, rendimiento y tiempo - UML Profile for Schedulability, Performance and Time-; Perfil UML para el Sistema en un Chip - UML Profile for
3 OMG: Object Management Group. Es una organización de la industria
informática sin fines de lucro que se encarga de mantener y regular las especificaciones de UML, entre otras especificaciones ligadas con la orientación a objetos.
System on a Chip- for Systems Engineering
Se puede encontrar toda l siguiente dirección:
En este proyecto se destaca seguridad software
ya que será uno de los pilares para el desarrollo del perfil “Safety UML” que se realiza e implementa en este proyecto.
2.1.
DIAGRAMAS UML
Como ya se ha mencionado anteriormente, existen trece tipos de diagramas en UML 2.0.
estructura y diagramas d
- (SoC); Perfil UML para la Ingeniería de Siste for Systems Engineering- (SysML)y Perfil UML Testing.
Se puede encontrar toda la información referente a estos perfiles en la siguiente dirección: http://www.uml.org/#UMLProfiles
En este proyecto se destaca un nuevo perfil, no estandarizado, relativo a la seguridad software. Se dedicará un apartado a describir este perfil de seguridad, ya que será uno de los pilares para el desarrollo del perfil “Safety UML” que se realiza e implementa en este proyecto.
DIAGRAMAS UML
Como ya se ha mencionado anteriormente, existen trece tipos de iagramas en UML 2.0. Estos diagramas se dividen en dos tipos: diagramas de
a y diagramas de comportamiento. (Ilustración 4)
Ilustración 4: Tipos de diagramas UML
Perfil UML para la Ingeniería de Sistemas - UML Profile
a información referente a estos perfiles en la
no estandarizado, relativo a la este perfil de seguridad, ya que será uno de los pilares para el desarrollo del perfil “Safety UML” que se
Como ya se ha mencionado anteriormente, existen trece tipos de tipos: diagramas de
Capítulo 2: Estudio del Estado del Arte
A continuación se van a describir brevemente los tipos de diagramas UML mostrados en la figura, y en detalle el diagrama de clases, por tener éste particular relevancia en este proyecto.[BOOC99]
Diagrama de clases. Muestra un conjunto de clases y sus relaciones.
Proporciona una perspectiva estática del sistema, mostrando su diseño estructural. Un diagrama de clases se compone de clases y relaciones. Una clase se representa mediante una figura rectangular dividida en tres áreas: nombre, atributos y métodos. Una relación define la interrelación entre dos clases. Existen varios tipos de relaciones entre clases:
Herencia. Esta relación indica que una subclase hereda los métodos y atributos de sus superclase.
Agregación. Esta relación indica que una clase está compuesta de instancias de otras clases.
Asociación. Esta relación permite que las clases colaboren entre sí.
Dependencia o instanciación. Esta relación representa la dependencia entre una clase instanciada con otra clase.
Diagrama de estructura compuesta. Muestra la estructura interna de una clase, incluyendo sus puntos de interacción con otras clases. Diagrama de componentes. Muestra los componentes de la
implementación de un sistema y las relaciones entre ellos.
Diagrama de despliegue. Muestra los nodos de procesamientos y
componentes.
Diagrama de objetos. Muestra un conjunto de objetos y las
relaciones entre ellos en un momento determinado.
Diagrama de paquetes. Muestra cómo las clases del modelo están
Diagrama de actividad. Muestra el orden en el que se van realizando
las tareas dentro de un sistema, es decir, el flujo de control de las actividades.
Diagrama de casos de uso. Muestra la interacción entre los usuarios
y el sistema modelado.
Diagrama de estados. También recibe el nombre de máquina de
estados. Muestra los diferentes estados por los que puede pasar un objeto.
Diagrama de secuencia. Muestra la secuencia de mensajes entre
objetos en un escenario o para un caso de uso concreto.
Diagrama global de interacción. Es una variante de un diagrama de
actividad. Muestra el flujo de control de todo el sistema en su conjunto.
Diagrama de comunicación. Muestra la organización estructural de
los objetos que intercambian mensajes.
Diagrama de tiempos. Muestra el cambio en el estado de un objeto a
través del tiempo en respuesta a eventos externos [WWW01].
2.2. PERFIL DE SEGURIDAD DE UML (UML PROFILE SAFETY)
El perfil de safety es un perfil UML que propone un método para extender la notación UML, introduciendo requisitos de seguridad en los estereotipos de los diagramas de clase con el objetivo de poder generar informes de seguridad de manera automática para certificaciones de la norma aeronáutica RTCA DO- 178B.[RTCA92].
El enfoque que propone este perfil coincide con el objetivo que se persigue en este proyecto, ya que permite incluir información de seguridad durante el propio modelado del sistema.
Si bien el alcance de este proyecto no se centra en la norma aeronáutica como ocurre en este perfil propuesto, la idea de integración de los requisitos de seguridad en el propio modelado del sistema sí encaja con los objetivos del
Capítulo 2: Estudio del Estado del Arte
proyecto. Algunas de las coincidencias más importantes entre este perfil propuesto y el objetivo del proyecto son las que se listan a continuación:
El perfil de safety permite reducir el gap entre ingenieros de seguridad e ingenieros software. La importancia de reducir esta distancia es clara, y aporta numerosas ventajas. Las tareas de un ingeniero software y un ingeniero de seguridad son diferentes. Los ingenieros de seguridad no son desarrolladores y los ingenieros software no suelen tener una formación rigurosa en seguridad software, por eso es tan importante que exista una buena comunicación entre ellos, que se consigue mediante esta extensión de la notación UML.
El perfil de safety extiende la notación UML incorporando requisitos de seguridad. En el módulo software que se desarrolla como parte de este proyecto, esto puede resultar muy ventajoso, ya que esta información incluida como parte del modelo UML, traducido a estándar XML, podrá ser utilizada posteriormente con diversos fines, entre ellos la generación de informes de seguridad.
En el capítulo siguiente, capítulo 3, se describirá con más detalle y profundidad este perfil, por ser la línea elegida como base para el desarrollo de este proyecto.