Transcript Document

Modelado de Sistemas
Embebidos
Andrés Djordjalian <[email protected]>
Seminario de Sistemas Embebidos
Facultad de Ingeniería de la U.B.A.
00:38
1 de 32
Modelado de Sistemas Embebidos
 Temario
1.
2.
3.
4.
5.
6.
¿Qué es el modelado?
Modelos de computación
Tendencias
UML
Desarrollo basado en modelos
Herramientas
 La presentación tiene actividades

Para eso, vayan formando grupos
•
•
00:38
de 3 o 4 personas.
Vean quién vive más cerca de FIUBA
– Esa persona va a hacer las anotaciones y ser el o la vocero
del grupo, cuando discutamos entre todos las conclusiones.
» Los demás pueden explicarle y hacer comentarios
cuando discutamos, pero sin sacarle el laburo.
2 de 32
¿Qué es un Modelo?
 Es la descripción del funcionamiento o la estructura de
un sistema, o de alguna de sus partes, en un nivel alto
de abstracción
 Pueden emplearse en los requerimientos, en la definición de la
arquitectura o en el diseño detallado
 Lo forman uno o más artifacts
 Que pueden estar en pizarrón (whiteboard), papel, o en un archivo
de computadora.
 Los modelos generalmente están expresados en
lenguajes cercanos al problema
 Frecuentemente son gráficos o matemáticos
 Ejemplos: escribir un código Matlab, diagramar en
Simulink o en un diagrama de estados.
00:38
3 de 32
El Modelado Sirve Para:
 Organizar y comunicar ideas eficientemente.
 …al pensar un diseño, hacerlo en equipo, y documentar
 Encontrar defectos temprano
 …si es que se puede ejecutar o chequear formalmente
• A veces se dice simular en lugar de ejecutar
• Las técnicas de chequeo formal intentan demostrar que es correcto,
como se demuestra un teorema
 Implementar un sistema embebido
 …si contamos con herramientas de MDD
• MDD=Model-Driven Development
– (vamos a verlo más adelante)
 Representar el entorno
de un sistema embebido,
para verificarlo
 Ej., simulación de “hardware
in the loop” (HIL, ver figura)
Fuente: embedded.com
00:38
4 de 32
Lenguajes de Modelado
 Son lenguajes artificiales para construir modelos

Ejemplos: El lenguaje del MATLAB o la notación típica de una
máquina de estados finitos
 Propósitos:



Evitar malentendidos
Habilitar el uso de herramientas y su interoperabilidad
Facilitar modos eficientes de expresar ideas
 Muchos de estos lenguajes son gráficos
 Algunos son de propósito general y otros son
domain-specific

…o sea, especiales para determinados problemas
 Los hay abiertos, otros son propietarios
 Frecuentemente emplean modelos de computación.
00:38
5 de 32
Modelos de Computación
 Son definiciones abstractas de máquinas capaces de
computar
 Ejemplo: una máquina de estados finitos (FSM)
 Algunos lenguajes de
modelado incluyen, por
ejemplo diagramas de
estado
 Ej: los StateCharts de UML, o la
extensión Stateflow de Simulink
 A veces les incorporan
elementos nuevos y/o una
sintaxis particular
• Más adelante vamos a verlo
para el caso de los StateCharts
00:38
6 de 32
Ejemplos de Modelos de Computación
Modelo de Flujo de Datos
 Representación gráfica de cómo se mueven los datos
entre los distintos procesos o componentes
 Como la que se usa en DSP
 También se le dice Data-Flow Diagram (DFD)
 Puede ser en tiempo discreto o continuo
00:38
7 de 32
Ejemplos de Modelos de Computación
Redes de Petri
 Sirven para representar sistemas con concurrencia y
necesidades de sincronización
 Ej., porque compiten por recursos
Fuente: ARP Manual; LCMI/UFSC (Brazil)
00:38
8 de 32
Ejemplos de Modelos de Computación
Redes de Petri
(Otro ejemplo de Red
de Petri)
Fuente: http://www.jfsowa.com
00:38
9 de 32
Utilización de Lenguajes de Modelado
en la Industria
 2006 State of the
Embedded Market
Survey: Encuesta a
1217 suscriptos a
publicaciones sobre
embebidos y
visitantes a
conferencias.
 Preguntas: “My
current embedded
project uses…” y “My
next embedded
project is likely to
use…”
00:38
10 de 32
Survey Says: Agilists are Modeling
92,7
85,5
Whiteboard Sketching
Init. Agile Req. Modeling
66,7
77,7
77,2
68,2
Init. Agile Arch. Modeling
Paper Modeling
53,4
CASE Tool Modeling
31,8
0
% Finding it Useful
20
40
65,9
47
60
80
100
% Applying Technique
Copyright 2007 Scott W. Ambler <http://www.ambysoft.com/surveys/>
00:38
11 de 32
Unified Modeling Language (UML)
 Lenguaje de modelado estándar en la industria del
software
 Desarrollado por Rumbaugh and Booch, dos especialistas en
orientación a objetos.
 Lanzado en 1996. La versión actual es la 2 (2005).
• La subversión más reciente es la 2.2.
 Emplea muchos símbolos que ya se usaban comúnmente desde
antes.
 Está basado en orientación a objetos pero también puede
aprovecharse con otros paradigmas.
 Dada su influencia, hay lenguajes de modelado
ajenos al software, y domain-specific, que se basan
en UML
 Ej.: Systems Modeling Language (SysML)
 Tiene mecanismos de extensión
 Además, usarlo flexiblemente es una práctica frecuente, en
lugar de respetar estrictamente la norma.
 Con estos mecanismos se creó un profile de UML ejecutable
(i.e., que se puede simular) llamado Exectuable UML o xUML.
00:38
12 de 32
Diagramas del UML
2.0
“Unified Modeling Language”;Wikipedia;
disponible el 29/11/08 en
<http://en.wikipedia.org/wiki/Unified_
Modeling_Language>
00:38
13 de 32
Diagrama de Secuencia
Diagramas del UML 2
 Muestran las
comunicaciones
entre varios
objetos, a lo
largo del
tiempo
 La línea
punteada se
hace rectángulo
cuando el
objeto está
“activo”
Fuente: http://www.conceptdraw.com/en/products/cd5/ap_uml_tool.php
00:38
14 de 32
Diagrama de Secuencia
Actividad
 Describir, mediante un
diagrama de secuencia, la
comunicación entre un
microcontrolador y un
periférico, en donde el
primero le manda un byte
‘A’ al segundo, seguido de
un byte ‘B’
 La sincronización se
realiza mediante dos
señales (conexiones)
unidireccionales:
 ‘req’ (request)
• De la MCU al periférico
Fuente: http://www.conceptdraw.com/en/products/cd5/ap_uml_tool.php
 ‘ack’ (acknowledge)
• Del periférico a la MCU
 La conexión restante es
‘data’ (de 8 bits)
00:38
15 de 32
Diagramas del UML 2
Diagrama de Casos de Uso
 En inglés: Use
case diagram
 Muestra a los
usuarios del
sistema (o sea,
actores), sus
objetivos al
utilizarlo (o
sea, casos de
uso), y las
relaciones
entre los casos
de uso
 Un actor no
necesariamente
es una persona
00:38
ArgoUML User Manual, A. Ramirez et al. ; disponible el 29/11/08 en <http://argoumlstats.tigris.org/documentation/printablehtml/manual/argomanual.html>
16 de 32
Diagrama de Casos de Uso
Actividad
 Relaciones:
 A <<include>> B
• cuando el caso de
uso A incluye al B
 A <<extend>> B
• cuando A es un
adicional que se
usa en casos
particulares de B
 A, línea con flecha
sin llenar, B
• cuando A es un
tipo de B
 Ver ejemplos en la
figura
Fuente: http://www.conceptdraw.com/en/products/cd5/ap_uml_tool.php
00:38
17 de 32
Diagramas del UML 2
StateCharts
 Son
diagramas
de estados,
mejorados
FSM
+
Jerarquía
Concurrencia
StateCharts
00:38
18 de 32
Diagrama de
Actividad
Diagramas del UML 2
 Mezcla de los viejos
diagramas de flujo
con concurrencia
basada en tokens,
estilo redes de
Petri.
 Ojo, es un diagrama
de flujo de control, no
de datos
Real-Time Design Patterns: Robust Scalable
Architecture for Real-Time Systems; p. 28; B.P.
Douglass; Addison Wesley; 2002
00:38
19 de 32
Diagrama de Clases
Diagramas del UML 2
“Image:Composite UML class diagram.svg”; Wikipedia; disponible el 29/11/08 en
<http://commons.wikimedia.org/wiki/Image:Composite_UML_class_diagram.svg>
00:38
20 de 32
Diagramas del UML 2
Diagrama de Temporización
 O timing diagram
 Como los que se usan en digitales
El diagrama se tomó de este
libro, que ofrece un resumen
detallado (160 páginas) del
UML 2
00:38
21 de 32
Diagramas del UML 2
Otros Diagramas
 Componentes, Paquetes, Instalación
 Para mostrar particiones lógicas y físicas del sistema.
 Comunicaciones, Repaso de Interacciones
 Alternativas al diagrama de secuencia, para mostrar
interacciones entre objetos.
 Objetos
 Similar al de clases pero muestra objetos.
 Estructura Compuesta
 Similar al de clases, incorpora jerarquías y categorizaciones.
00:38
22 de 32
Desarrollo Basado en Modelos
 Significa que modelos ejecutables sean el “código
fuente” principal de los desarrollos.
 Se lo llama Model-Driven Architecture (MDA) o ModelDriven Development (MDD)
 “There are many views and opinions about what MDA is and is
not.” (Alan Brown, Staff, IBM)
 Tratan la provisión de herramientas basadas en
modelos, para creación, transformación, testeo,
análisis, simulación, ing. inversa, etc.
 Ejemplo de MDD para aplicaciones embebidas generales:
Telelogic Rhapsody (de IBM)
 A este tipo de herramientas antes se las categorizaba
como CASE (Computer-Aided Software Engineering)
 El término CASE fue tan abusado que ahora se lo utiliza poco.
00:38
23 de 32
Simulink®
 Es un entorno para modelado (gráfico) de los fabricantes de Matlab
 Pueden embeberse código Matlab en un modelo Simulink, y viceversa.
• También puede embeberse código en C, Fortran o Ada
 Puede usarse Matlab para analizar la salida de un modelo Simulink
 Los modelos son ejecutables
 O sea que sirven para detectar y corregir fallas, temprano
• Además de ser útiles para diseñar y documentar
 Trabaja con diagramas de flujo de datos, en tiempo discreto o continuo
00:38
 Por lo tanto, es especialmente útil para DSP y control
24 de 32
Stateflow® (para Simulink)
 Es un plug-in para poder incluir statecharts en los
modelos que se diseñan con el Simulink
00:38
25 de 32
Real-Time Workshop® (para Simulink)
 Plug-in que “compila” el modelo en código C o C++
para microcontroladores

Con llamadas al sistema operativo que se elija, o a ninguno
 Genera código para
1. Inicialización
2. Implementación de los algoritmos del modelo
3. Instrumentación (para ajustar parámetros y “data logging”)
 Video de demo en:
http://www.mathworks.co.jp/products/demos/rtw/introduction/index.html
 Está pensado también para simulación de tipo
hardware in the loop (HIL)

O sea, simular el entorno que interactúa con un sistema embebido
26 de 32
00:38
Fuente: embedded.com
Telelogic Rhapsody® (IBM)
00:38
27 de 32
Metodología Asociada al Rhapsody
 Harmony Process
 De I-Logix, que
fue adquirida
por Telelogic,
que fue
adquirida por
IBM
 Emplea UML, y
modelo de ciclo
de vida que
combina espiral
yV
00:38
28 de 32
NI LabVIEW®
00:38
29 de 32
Mejores Prácticas del Agile Modeling
 “Initial Requirements Modeling”
 En la iteración 0, después del release plan, se empieza modelando el
entorno y un planteamiento general de los requerimientos
fundamentales del sistema y la interfaz al usuario
 “Initial Architecture Modeling”
 En la iteración 0 se modela también, en líneas generales, la
arquitectura pretendida, para empezar a identificar los módulos a
desarrollar
 “Just Barely Good Enough” (JBGE) artifacts
 No pasarse con el esfuerzo puesto en un modelo o documento
• Ej.: si sólo lo queremos para entendernos con un colega, no hace falta
pasarlo en la PC
• Ej.: si sólo necesitamos analizar una parte, no hace falta modelar todo
 “Model Storming”
 Cuando surge un problema para pensar, se hace una reunión rápida,
se piensa entre todos usando modelos (generalmente sobre un
pizarrón), y después cada uno sigue con lo suyo
 Aprovechar el modelado, también, para
 La automatización de las pruebas de aceptación
 Usarlo como documentación, reduciendo la documentación ad hoc y
dejándola para el final
• “La documentación es el diseño”
 Para ver más: http://www.agilemodeling.com
00:38
30 de 32
Survey Says: Agilists are Modeling
Copyright 2007 Scott W. Ambler <http://www.ambysoft.com/surveys/>
00:38
31 de 32
Para Terminar
 El propósito de estas clases, es que
 Incluyan lenguajes de modelado entre los que usan
profesionalmente
• Para sumarlo al castellano, el lenguaje matemático, C, etc.
 Identifiquen situaciones en donde son útiles
• Ej. Para plantear problemas confiablemente, comunicarse con
colegas y clientes, documentar, debuggear temprano, simulación de
HIL, MDD, etc.
 Facilitar la profundización de estos temas
 ¿Preguntas? ¿Comentarios?
 Hay un video con una demo del Telelogic Rhapsody
 “RhapsodyCDemo.wmv”; Telelogic (IBM)
 Hay una presentación con una introducción al
LabView de National Instruments
 “LabVIEW Introduction.ppt”; National Instruments
 ¡Gracias!
00:38
32 de 32