PDF Universidad Tecnológica De La Mixteca - Utm

Diagrama de secuencia para el Escenario 11: Gestión de conexión para establecer una conexión serie multipunto con el perfil de puerto serie en modo servidor 210 Figura 6.40. Máquina de estados para seleccionar el modo de funcionamiento 213 Figura 6.43 Máquina de estados dentro del subsistema de Configuración de Nodo 213 Figura 6.44.

ÍNDICE

INTRODUCCIÓN Y

DEFINICIÓN DEL PROBLEMA

• IMPORTANCIA DEL PROBLEMA
• JUSTIFICACIÓN
• NECESIDAD DE UNA METODOLOGÍA DE DESARROLLO PARA SE
• BENEFICIOS DE UNA METODOLOGÍA PARA LA MEJORA DEL PROCESO DE DISEÑO DE SE
• DELIMITACIONES DEL TRABAJO
• LIMITACIONES DEL TRABAJO
• HIPÓTESIS
• OBJETIVOS DEL TRABAJO
• APROXIMACIÓN A LA SOLUCIÓN
• Capa de soporte. Proporciona la ayuda para alcanzar la calidad esperada por el establecimiento de actividades para la configuración y la dirección de contratos y medición continua de ellos
• ESTRUCTURA DE LA TESIS
• PUBLICACIONES GENERADAS

Desafortunadamente, las metodologías de desarrollo de software disponibles (adaptadas al desarrollo de SE) no tienen en cuenta las necesidades específicas de este tipo de sistemas [Srinivasan, Dobrin & Lundqvist, 2009]. La metodología tendrá como objetivo mejorar la calidad del producto final y la productividad en el desarrollo de Sistemas Embebidos.

EL CONTEXTO DE LOS SISTEMAS EMPOTRADOS Y

LA CALIDAD DEL PRODUCTO

DEFINICIÓN FORMAL DE SISTEMA EMPOTRADO

• EL PROCESADOR
• MICROPROCESADOR
• MICROCONTROLADORES
• MEMORIA
• ENTRADAS Y SALIDAS

Para el desarrollo de las SE es necesario considerar todos los aspectos de hardware y software; Los componentes de hardware más importantes se analizarán a continuación. Según [Ball, 2002], determinar los requisitos de memoria también es una parte esencial del diseño de ES.

CLASIFICACIÓN Y CARACTERÍSTICAS DE LOS SISTEMAS EMPOTRADOS

EVOLUCIÓN Y VISIÓN GENERAL DE LA SITUACIÓN ACTUAL DE LOS SISTEMAS EMPOTRADOS

Esta división del desarrollo en dos corrientes independientes de software y hardware ocurre en paralelo, y el resultado de la integración puede convertirse en un punto crítico de falla [Srinivasan, Dobrin, & and Lundqvist, 2009]. Se han utilizado modelos de Ingeniería de Sistemas para describir el ciclo de diseño de ES [Noergaard, 2005].

RETOS EN EL DISEÑO DE SISTEMAS EMPOTRADOS

Bajo consumo de energía y alto rendimiento: el componente de software debe poder utilizar eficazmente las optimizaciones que el componente de hardware pone a disposición de los diseñadores de SE para reducir el consumo de energía del sistema y aumentar su rendimiento. IBM Software Group afirma que el 80% de los costos de desarrollo se gastan en identificar y corregir errores.

PROPUESTAS ACTUALES PARA EL DESARROLLO DE SISTEMAS EMPOTRADOS En la actualidad se han desarrollado diferentes investigaciones en el dominio de los SE

• EMBEDDED SOFTWARE COMPONENT MODEL (ESCM)
• OBJETIVO
• ESTRUCTURA
• SAVE INTEGRATED DEVELOPMENT ENVIRONMENT (SAVE-IDE)
• OBJETIVO
• ESTRUCTURA
• RESOURCE MODEL FOR EMBEDDED SYSTEMS (REMES)
• OBJETIVO
• ESTRUCTURA
• RAPID OBJECT-ORIENTED PROCESS FOR EMBEDDED SYSTEMS (ROPES) ROPES (Rapid Object-Oriented Process for Embedded Systems) se propone como un
• OBJETIVO
• ESTRUCTURA

REMES tiene como objetivo describir el comportamiento racional de los recursos que interactúan entre componentes integrados. Análisis de requisitos: consiste en la especificación de caja negra de los requisitos funcionales y no funcionales del sistema.

Diseño: optimiza al modelo de análisis, además de que se llevan a cabo los diseños de la arquitectura, de los mecanismos y del esquema detallado; el diseño define una única solución

Traducción: comprende la generación de código ejecutable a partir del diseño del sistema, implica tanto el código de la aplicación como el necesario para la verificación independiente de

• MODEL-DRIVEN DESIGN OF EMBEDDED SYSTEMS (ModES)
• OBJETIVO
• ESTRUCTURA
• SIMPLIFIED PARALLEL PROCESSES (SPP)
• OBJETIVO
• ESTRUCTURA
• PRODUCT FOCUSED SOFTWARE PROCESS IMPROVEMENT
• OBJETIVO
• ESTRUCTURA
• PRINCIPALES HALLAZGOS SOBRE LAS PROPUESTAS PARA EL DESARROLLO DE SISTEMAS EMPOTRADOS

La importancia de la ingeniería de requisitos en la mejora de procesos de software centrados en productos se debe al impacto que tienen los requisitos en la calidad del producto. Dentro de la tesis, la Ingeniería de Procesos es “el diseño de un proceso medible para el desarrollo de un producto específico que toma en cuenta la especificación de calidad del producto.

Ámbito de aplicación: este criterio se estableció para delimitar el uso de las metodologías, pues aunque se seleccionaron metodologías con características propias para SE, algunas de

Los métodos analizados son producto de los esfuerzos de la industria y de instituciones académicas cuyo objetivo es incorporar la formalidad en el "proceso" de diseño de SE.

Basado en: de acuerdo al estudio exploratorio realizado, las metodologías actuales proporcionan soluciones orientadas principalmente al uso de Componentes (C), Herramientas (H) o a

Puntos a favor: especifica la mejora real y/o beneficios que ofrece la metodología respecto al diseño de los SE

Puntos en contra: especifica los inconvenientes de la metodología en el dominio de los SE

Se centra exclusivamente en el desarrollo de software integrado y no considera el desarrollo de hardware. Falta de modelado del comportamiento de los componentes internos y externos, así como de los recursos de ES.

MEJORA AL PROCESO SOFTWARE

CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

• VENTAJAS DE CMMI-DEV V1.2
• DESVENTAJAS DE CMMI-DEV V1.2

Los modelos de la constelación CMMI-DEV incluyen prácticas que incluyen gestión de proyectos, gestión de procesos, ingeniería de sistemas, ingeniería de hardware, etc. A través de las áreas de procesos se enfatizan prácticas importantes como: Gestión de Requisitos, Ingeniería de Procesos, Análisis de Decisiones.

ISO/IEC 15504:2004

• PROPÓSITO DE LA NORMA ISO/IEC 15504:2004
• ESTRUCTURA Y DISEÑO DE LA NORMA ISO/IEC 15504:2004
• VENTAJAS DE LA NORMA ISO/IEC 15504:2004
• DESVENTAJAS DE LA NORMA ISO/IEC 15504:2004

Proporciona un modelo que es totalmente compatible con aquella parte del estándar que incluye un conjunto de indicadores que facilitan el cálculo del desempeño del proceso. Dimensión de Capacidad: El desempeño de los procesos seleccionados se analiza frente al perfil de madurez.

SIX SIGMA

• PROPÓSITO DE SIX SIGMA
• ESTRUCTURA Y DISEÑO DE SIX SIGMA
• DESVENTAJAS DE SIX SIGMA

La metodología Six Sigma se basa en lo que se conoce como DMAIC (Definir, Medir, Analizar, Mejorar y Controlar). Los esfuerzos de Six Sigma se dirigen a tres áreas principales: mejorar la satisfacción del cliente, reducir el tiempo del ciclo y reducir los defectos.

BOOTSTRAP

• PROPÓSITO DE BOOTSTRAP
• VENTAJAS DE BOOTSTRAP
• DESVENTAJAS DE BOOTSTRAP

Brindar soporte para la evaluación de la capacidad del proceso utilizando un conjunto de prácticas de ingeniería de software. Apoya la creación y aplicación de un plan de mejora que genere resultados aceptables y confiables para que las acciones del plan de mejora permitan el logro de las metas de la organización.

MÉTODOS ÁGILES

• PROGRAMACIÓN EXTREMA
• PROPÓSITO DE LOS MÉTODOS ÁGILES
• VENTAJAS DE LOS MÉTODOS ÁGILES
• DESVENTAJAS DE LOS MÉTODOS ÁGILES

Las mejores arquitecturas, requisitos y planes provienen de equipos autoorganizados. Un representante de los usuarios finales del sistema (cliente) debe estar disponible para el equipo de XP en todo momento.

COMPARACIÓN EMPÍRICA SOBRE LOS MODELOS Y ESTÁNDARES DE REFERENCIA PARA MEJORAR LA CALIDAD DE LOS PRODUCTOS DE DESARROLLO

Con este criterio se puede determinar el impacto de la aplicación del modelo o estándar en el costo del desarrollo de la SE. Aplica a SE: para determinar si existe historial de que el modelo o estándar haya sido utilizado en el desarrollo de Sistemas Embebidos.

INTRODUCCIÓN A LA SOLUCIÓN

PROPUESTA FORMAL DE SOLUCIÓN

Se han encontrado varios ejemplos en la literatura que involucran la reutilización de componentes para el desarrollo de SE (por ejemplo, ESCM [Li et al., 2009] y Save-IDE [Sentilles et al., 2009]). Mejora del proceso del programa: los métodos desarrollados bajo el enfoque SPI parecen adecuados para el desarrollo de la ES, pero su uso no se ha convertido en una práctica organizada.

PLANTEAMIENTO FORMAL DE LA HIPÓTESIS

• COMPONENTES DE LA METODOLOGÍA PARA EL DISEÑO DE SISTEMAS EMPOTRADOS BAJO EL ENFOQUE DE MEJORA DEL PROCESO SOFTWARE

La metodología se estructura en ocho fases con 16 áreas de proceso compuestas por actividades más específicas. Las áreas de proceso en la metodología son un grupo de prácticas relacionadas que, cuando se implementan colectivamente, cumplen con un conjunto de objetivos que se consideran importantes para lograr mejoras en esa área.

METODOLOGÍA PARA EL DISEÑO DE SISTEMAS EMPOTRADOS BAJO EL

SOFTWARE

PLANIFICACIÓN

El propósito de la planificación es establecer y mantener planes de trabajo que definan las actividades del proyecto. Las estimaciones de los parámetros de diseño deben tener una base que infunda confianza en que cualquier plan basado en estas estimaciones podrá respaldar los objetivos del proyecto.

Analizar las actividades del plan de proyecto de SPIES (Artefacto PRY) para entenderlas y comprender el desarrollo del mismo

Identificar tiempos estimados para las tareas del plan, y asegurar la asignación de responsabilidades y el calendario del proyecto

Identificar el producto y componentes del producto que serán desarrollados externamente (Artefacto STR)

Identificar los componentes que serán reutilizados (Artefacto STR)

Determinar la estrategia de desarrollo para el proyecto (Artefacto STR)

Utilizar métodos apropiados para determinar los parámetros de los productos y tareas que serán usados para estimar el tiempo y esfuerzo necesario del proyecto

Estimar los atributos de los productos (Artefacto TAM) y tareas (Artefacto PRY)

Recoger los datos históricos que serán usados para transformar los parámetros de los productos y tareas en estimaciones de horas/trabajo y costo

Al estimar el esfuerzo y el costo, se deben considerar las necesidades de recursos de infraestructura del entorno de desarrollo, el entorno de prueba, el entorno de producción, el entorno de destino o cualquier combinación adecuada de estos. Recursos informáticos críticos (memoria, capacidad de disco y red, periféricos, canales de comunicación y su capacidad).

Estimar costo y esfuerzo usando modelos y/o datos históricos

• DESARROLLAR EL PLAN DEL PROYECTO

La infraestructura de apoyo incluye la necesidad de recursos desde una perspectiva de desarrollo de productos y sostenibilidad. Identificar los hitos que deben cumplirse antes de que comience un evento proporciona flexibilidad en el tiempo de finalización, una comprensión compartida de lo que se espera, una mejor descripción general del estado del proyecto y un estado más preciso de las tareas del proyecto.

Identificar los hitos importantes

Identificar las suposiciones sobre el calendario

Identificar las dependencias entre tareas

Definir el presupuesto y calendario (Artefacto SCHE)

Definir actividades e hitos del calendario para respaldar la precisión en la medición del progreso.

Establecer criterios de acción correctiva

Documentar los riesgos (Artefacto RIE ) 3. Revisar los riesgos cuando sea necesario

Identificar el conocimiento y las habilidades necesarias para ejecutar el proyecto

Evaluar el conocimiento y las habilidades disponibles

Seleccionar los mecanismos para proporcionar el conocimiento y las habilidades necesarias

Incorporar los mecanismos seleccionados en el plan del proyecto

• ESPECIFICACIÓN DE REQUISITOS
• DESARROLLAR LOS REQUISITOS DEL CLIENTE

El objetivo de la Especificación de Requisitos es elaborar y analizar los requisitos del cliente, del producto y de los componentes del producto. Las necesidades del producto (del cliente o especificación escrita) son la base para determinar sus requisitos.

Preparar el entorno de trabajo para la Introducción Funcional (Artefacto DCUF)

SPIES utiliza la técnica de casos de uso para definir qué debe hacer un producto y cómo se comportará.

Crear un nuevo DCU en el paquete de Análisis

Rhapsody agrega automáticamente la categoría Diagramas de casos de uso y el nombre del diagrama al navegador y abre una nueva área de dibujo. Antes de obtener la DCU de la Introducción Funcional, es necesario identificar los requisitos del sistema, incluidos los actores, los principales casos de uso y las relaciones entre ellos.

Dibujar la Caja Límite y los Actores

Dibujar los casos de uso

Con el botón izquierdo del mouse, presione el ícono Caso de uso en la barra de dibujo. A diferencia de los actores, los casos de uso no corresponden al código que se generará.

Definir las propiedades de los casos de uso

Haga clic izquierdo en el área de dibujo para insertar el caso de uso en el cuadro delimitador y asígnele un nombre relacionado con la función a la que se refiere. Esta actividad deberá repetirse según la cantidad de casos de uso que desee implementar.

Asociar los actores con los casos de uso

Dibujar las generalizaciones

Documentar los modelos y diagramas

Transforme las necesidades, expectativas, limitaciones e interfaces de los participantes del proyecto en requisitos del sistema. La trazabilidad de requisitos es la capacidad de describir y rastrear la vida útil de un requisito en ambas direcciones (hacia adelante y hacia atrás).

Agregar los requisitos al modelo

El modelado de requisitos permitirá la trazabilidad de los requisitos sin el uso de una herramienta de gestión de requisitos especializada. METODOLOGÍA PARA EL DISEÑO DE SE BAJO el método SPI Es necesario utilizar una notación simple que permita distinguir los requisitos a medida que crece el análisis y descripción de los mismos.

Agregar los elementos del requisito

SPIES recomienda utilizar una notación simple que comience con la palabra "Req". (indicando así que es un requisito) continuar con una numeración que distinga entre componente y requisito. Es decir, el Req.1.1 indicaría que es el requisito 1 (número a la derecha del punto decimal) del componente 1 (número a la izquierda del punto decimal).

Dibujar las dependencias entre los requisitos

Definir el estereotipo de las dependencias

Definir los diagramas de requisitos (Artefacto DREQ)

Los requisitos del sistema se refinan y producen para desarrollar requisitos de productos y componentes de productos. Los requisitos del sistema se analizan junto con el desarrollo del concepto operativo para derivar conjuntos de requisitos más detallados y precisos denominados "requisitos de productos y componentes del producto".

Desarrollar los requisitos en los términos técnicos necesarios para el diseño del sistema y sus componentes

Estos requisitos abordan las necesidades asociadas con cada fase del ciclo de vida del producto. Desarrollar los requisitos en los términos técnicos necesarios para el diseño del sistema y sus componentes.

Derivar los requisitos resultantes de las decisiones de diseño

Los requisitos se revisan con el diagrama de requisitos de bajo nivel, la estrategia de desarrollo (Artifact STR) y se refina el concepto de producto preferido. Los requisitos arquitectónicos expresan los puntos de calidad y rendimiento que son críticos para el éxito del producto.

Asignar los requisitos para cada componente del producto (Artefacto ASIREQ)

Identificar las interfaces tanto externas como internas al sistema

Desarrollar los requisitos para las interfaces identificadas

• ANALIZAR Y VALIDAR LOS REQUISITOS

Los análisis examinan los requisitos desde diferentes perspectivas (viabilidad, costo y riesgo) y pueden utilizar diferentes abstracciones (funcionales, diagramas de flujo de datos, relaciones entre entidades y estados). Los escenarios pueden incluir secuencias operativas que son expresiones de requisitos del sistema en lugar de conceptos operativos.

Desarrollar los conceptos operativos y los escenarios que incluyan funcionalidad, rendimiento y soporte según sea apropiado

METODOLOGÍA PARA EL DISEÑO SE BAJO EL ENFOQUE SPI Se realizan análisis para determinar el impacto que tendrá el entorno operativo previsto sobre la capacidad de satisfacer las necesidades, expectativas, limitaciones e interfaces del sistema.

Definir el entorno en el cual funcionarán el producto o los componentes del producto, incluyendo límites y restricciones

Revisar los conceptos operativos y los escenarios para refinar y descubrir los requisitos

Analizar y establecer la funcionalidad requerida por los usuarios finales

Dividir los requisitos en grupos, en base a los criterios establecidos (funcional, no funcional, seguridad, no importante)

Asignar los requisitos funcionales a los componentes o funciones del sistema

Analizar los requisitos (Artefacto ASIREQ) para determinar si éstos satisfacen los objetivos de los requisitos de nivel más alto

Analizar los requisitos para asegurarse de que son completos, factibles, realizables y verificables

Documentar las modificaciones para resolver los defectos encontrados

Explorar la adecuación y la completitud de los requisitos desarrollando la representación del sistema a través de simulaciones, y obteniendo retroalimentación sobre ellos ya sea

• DISEÑAR LA ARQUITECTURA DEL SISTEMA

La mayoría de los casos que involucran sistemas complejos utilizan un modelo de arquitectura en capas. Estos requisitos (producto y componentes) sirven como base para diseñar la arquitectura de software y hardware.

Establecer la configuración del diagrama de estructura 5.3. Diseñar los diagramas de estructura

Los diagramas de estructura muestran el flujo de información entre los componentes del sistema y la definición de la interfaz a través de los puertos. Diseñar diagramas de estructura que muestren el desglose del sistema especificado por los requisitos y su jerarquía.

Definir objetos como subsistemas

Un objeto es una entidad con límites bien definidos y una identidad que encapsula estado y comportamiento. En lenguajes orientados a objetos como C++, una clase es una plantilla para crear instancias (objetos) que comparten los mismos atributos, operaciones y métodos.

Modificar la visualización de los subsistemas

Establecer estereotipos para el resto de los objetos

En el grupo Visualización de imágenes, seleccione la opción Habilitar visualización de imágenes y seleccione la opción Usar imagen asociada. Haga clic derecho en un actor y seleccione la opción Configuración de pantalla en el menú contextual.

Dibujar los puertos

En la misma pantalla General, en Tipo, seleccione el nombre del actor asociado con el diseño de la lista. Todos los pasos anteriores deberán repetirse para todos los actores que estuvieron representados en el modelo.

Especificar los atributos de los puertos

Rhapsody agrega automáticamente los puertos creados al explorador (bajo sus respectivos objetos).

Dibujar los flujos

Especificar los ítems de los flujos

En el menú Elementos de flujo, en la pestaña General, debe proporcionar un nombre para el elemento. Es necesario repetir estos pasos para todos los elementos de flujo que desee ingresar.

Especificar los contratos de los puertos

El cambio en la forma de los flujos a menudo se debe a aspectos de visualización en el modelo; Para cambiar el estilo de la línea, seleccione el flujo y presione el botón derecho del mouse, elija Forma de línea y elija la mejor opción que se adapte a la distribución de sus elementos en el modelo.

Organizar el paquete de subsistemas

En el explorador de Rhapsody, haga clic derecho en el paquete del subsistema y seleccione Agregar nuevo > Paquete. Será necesario repetir estos pasos según la cantidad de subsistemas en los que se dividirá la funcionalidad completa del sistema.

Organizar los elementos entre paquetes

• CREAR LA ARQUITECTURA DE LOS SUBSISTEMAS

Al nombrar los subsistemas se debe respetar la notación Nombre_Subsistema, donde Nombre suele ser una abreviatura de un nombre más largo (por ejemplo, para el subsistema (Gestión de Conexión) el subsistema tendrá el nombre GC_Subsistema. METODOLOGÍA PARA EL DISEÑO DE SE BAJO EL ENFOQUE SPI Estos Los diagramas muestran el tipo de objetos en el sistema, los atributos y operaciones que pertenecen a estos objetos y las relaciones estáticas que pueden existir entre las clases (tipos).

Establecer la configuración del diagrama del modelo de objetos

Establecer la configuración del diagrama del modelo de objetos

Dibujar el resto de los objetos

• GENERAR EL CÓDIGO Y COMPILAR EL MODELO4. Dibujar los vínculos entre los objetos

Con el botón izquierdo del ratón, haga clic en el icono Enlace en la barra de dibujo. Haga doble clic en el componente predeterminado con el botón izquierdo del mouse para modificar sus propiedades.

Establecer las características del componente

Crear una configuración para el componente de validación

Generar el código fuente

La configuración activa se muestra en el menú desplegable Selección de código en la barra de herramientas del proyecto. En Rhapsody Explorer, haga clic derecho en la opción de depuración y seleccione Establecer como activo.

Construir el modelo

• CREAR LOS DIAGRAMAS DE SECUENCIA

En niveles inferiores de abstracción y para implementación, los diagramas muestran la comunicación entre clases y objetos. Diseñar diagramas de secuencia que identifiquen los flujos de comunicación entre los componentes de la arquitectura propuesta.

Configurar un nuevo diagrama de secuencia

• DISEÑAR LOS DIAGRAMAS DE SECUENCIA

METODOLOGÍA PARA EL DISEÑO SE UTILIZANDO EL ENFOQUE SPI Los diagramas de secuencia se pueden utilizar en diferentes niveles de abstracción. En niveles superiores de abstracción, los diagramas muestran las interacciones entre actores, casos de uso y objetos.

Dibujar las líneas de los actores

Dibujar los roles clasificadores

Dibujar los mensajes

Rhapsody crea el rol de clasificación con el nombre del rol en el panel Nombres. Rhapsody también agregará los mensajes a la categoría Eventos para cada subsistema relacionado en el gráfico.

Dibujar una ocurrencia de interacción

Dado que crea un diagrama de secuencia en modo de diseño, cada vez que se agrega un nuevo mensaje, Rhapsody le preguntará si desea crear ese mensaje.

Dibujar los intervalos de tiempo

METODOLOGÍA DE DISEÑO SIGUIENDO EL ENFOQUE SPI Rhapsody dibuja dos líneas horizontales (en los puntos inicial y final) y dos puntas de flecha en el medio para mostrar el tiempo transcurrido entre los puntos.

Establecer las características de tipo y retorno de los mensajes

Configurar las propiedades para la animación de los diagramas de secuencia

• VALIDAR LOS DIAGRAMAS DE SECUENCIA

En el explorador de Rhapsody, haga clic derecho en la configuración definida (Depurar de forma predeterminada) para abrir la ventana de propiedades.

Regenerar el código y compilar el modelo

Iniciar la animación

Animar el diagrama de secuencia

En el cuadro de diálogo Abrir diagrama de secuencia, expanda el paquete SubsystemsPkg y seleccione el diagrama que se animará. Haga clic izquierdo en el icono Animación en la barra de tareas.

Salir de la animación

• CREAR LOS DIAGRAMAS DE ACTIVIDADES
• DISEÑAR LOS DIAGRAMAS DE ACTIVIDADES

METODOLOGÍA DE DISEÑO SEGÚN ENFOQUE SPI Es decir, es posible observar la comunicación en la ejecución del sistema y luego comparar la secuencia de mensajes con diagramas de secuencia no animados y observar si el modelo se comporta correctamente.

Configurar un nuevo diagrama de actividades

Dibujar las swimlanes

Dibujar los elementos de acción

Es necesario presionar OK para guardar los cambios y salir de editar las propiedades de la acción. Es necesario presionar OK para guardar los cambios y salir de editar las propiedades de visualización.

Dibujar el flujo de inicio

La descripción de los elementos de acción es muy importante para la documentación del sistema. Repita todos los pasos anteriores para agregar tantos elementos de acción al modelo como sea necesario.

Dibujar las subactividades

METODOLOGÍA PARA DISEÑAR SIGUIENDO EL ENFOQUE SPI Simplemente presionando Enter moverá el flujo a una nueva línea para capturar el texto dentro de la acción. Para guardar los cambios y salir de la edición de las propiedades de la subactividad, presione OK.

Dibujar los estados de envío

Con el botón izquierdo del mouse, haga clic dentro del carril donde se agregará la subactividad. En la pestaña General, en el campo Nombre, ingrese el nombre deseado para la subactividad.

Dibujar las transiciones

Dibuja una transición entre las actividades, como se muestra en la actividad 7, pero teniendo en cuenta que el origen y el destino son la misma actividad.

Especificar acciones sobre una transición

Crear los diagramas de subactividades

• VALIDAR LOS DIAGRAMAS DE ACTIVIDADES

Luego de realizar la actividad 5, es necesario crear el diagrama dentro de la subactividad siguiendo todos los pasos anteriores. Con el botón derecho del mouse, haga clic en el subdiagrama dibujado anteriormente y seleccione Abrir subdiagrama de actividad.

Regenerar el código y compilar el modelo

Como se mencionó anteriormente, se recomienda detenerlo y validarlo periódicamente a medida que el modelo se vuelve más complejo y proporcionar depuración a nivel de diseño a través de una animación. Dibuje los elementos de acción, flujos iniciales, estados de despacho y transiciones necesarios para el nuevo subdiagrama.

Iniciar la animación

Animar el diagrama de actividades

Salir de la animación

• CREAR LOS DIAGRAMAS DE MÁQUINA DE ESTADO
• DISEÑAR LOS DIAGRAMAS DE MÁQUINA DE ESTADOS

METODOLOGÍA PARA EL DISEÑO DE SE BAJO ENFOQUE SPI Un diagrama de máquina de estados es un modelo de comportamiento de un sistema con entradas y salidas donde las salidas dependen no sólo de las señales de entrada actuales sino también de las anteriores.

Configurar un nuevo diagrama de máquina de estados

Dibujar los estados

Dibujar los estados anidados

Será necesario repetir estas actividades según la cantidad de estados que desee presentar en el diagrama anidado.

Dibujar el conector de inicio

Dibujar los estados de envío

• VALIDAR LOS DIAGRAMAS DE MÁQUINA DE ESTADOS
• GESTIÓN DE CONTRATOS
• ESTABLECER CONTRATOS PARA LOS PUERTOS Figura 5.9. Interfaces de un puerto

Haga clic izquierdo en el icono de Transición que se encuentra en la barra de dibujo. Haga clic izquierdo en el icono Animación en la barra de tareas.

Con el botón derecho del mouse, presionar sobre el puerto y seleccionar Features

METODOLOGÍA DE DISEÑO SPI Normalmente, cualquier conjunto ordenado de actividades es una estructura orientada a procesos que proporciona un esquema para identificar y organizar unidades lógicas de trabajo a gestionar. La estructura de trabajo SPIES proporciona un mecanismo de referencia y organización para la asignación de esfuerzos, cronogramas y responsabilidades, y se utiliza como marco fundamental para planificar, organizar y controlar el trabajo realizado en el proyecto.

En la pestaña General, desde la lista desplegable de Contrato, seleccione el contrato tipo In para aquellos puertos que sean del tipo Provided, o Out para aquellos puertos que

Es necesario repetir los pasos para establecer, siempre y cuando sea necesario, las interfaces en los puertos

• INVERTIR LOS CONTRATOS

Con el botón derecho del mouse, presionar sobre el puerto al que se desee aplicar el cambio de contrato y seleccionar Features

En la pestaña General, en el grupo Attributes, seleccione la opción Reversed

Es necesario presionar OK para guardar todos los cambios realizados al puerto

RESULTADOS EXPERIMENTALES

SISTEMA ROADRUNNER

• ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA ROADRUNNER
• DIAGRAMA DE CASOS DE USO DEL SISTEMA ROADRUNNER
• DIAGRAMA DE REQUISITOS DEL SISTEMA ROADRUNNER
• DIAGRAMAS DE ESCTUCTURA DEL SISTEMA ROADRUNNER
• DIAGRAMAS DE SECUENCIA DEL SISTEMA ROADRUNNER
• DIAGRAMAS DE MÁQUINAS DE ESTADO DEL SISTEMA ROADRUNNER Las máquinas de estado definen el comportamiento de los actores (casos de uso o clases),
• ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA THE COYOTE UNMANNED AIR VEHICLE SYSTEM

Nombre del requisito: El sistema aéreo no tripulado Coyote (CUAVS) es un sistema de reconocimiento de alcance medio en un entorno hostil con capacidad de ataque limitada. Nombre del requisito: El CUAV tendrá instalado un paracaídas de rescate de emergencia.