Gostaria muito de publicar este artigo e se possível complementá-lo com outro em que faço a modelagem de um controle de tráfego aéreo espeficando os conceitos de tempo real explicados neste artigo.
Este artigo tem como objetivo apresentar a modelagem de sistemas de tempo real na linguagem UML. Analisa-se que os sistemas de tempo real são complexos porque possuem interação com o ambiente o que os torna algumas vezes imprevisíveis. Possuem também restrições relativas à segurança e desempenho, além de terem de retornar respostas não somente corretas, mas também em um momento hábil de acordo com os requisitos do software. Os sistemas de tempo real são considerados críticos e, por terem alto custo de falhas, precisam prevê-las ou tratá-las a tempo.
A modelagem desses sistemas tem como meta criar modelos a partir das características desses sistemas, ignorando particularidades menos importantes, e minimizar erros de desenvolvimento, cortando custos. Para isso, serão apresentados perfis que servem de extensão aos mecanismos da UML, além das funcionalidades da versão 2.0 que unidas tornam a modelagem desses sistemas ainda mais poderosa.
Introdução
Atualmente, a modelagem dos sistemas de tempo real é muito importante, dado o grande número de aplicações nas áreas comercial, industrial, militar, educacional, médica e cultural e, também, ao fato de serem sistemas complexos e de existirem em número muito pequeno os modelos que abrangem grande parte dos aspectos de tempo real.
A UML (Unified Modeling Language) é uma linguagem orientada ao paradigma de programação orientada a objetos e apesar dessa linguagem não ter sido desenvolvida especialmente para o paradigma dos sistemas de tempo real, vários estudos foram realizados para a sua adequação. È através de extensões da linguagem UML que é possível modelar sistemas com restrições temporais e, por isso, o artigo apresenta três perfis sobre mecanismos de tempo real, além da versão 2.0 da UML.
Os sistemas de tempo real têm como principal recurso o tempo. Tempo esse que não pode ser medido, mas pode ser avaliado. Esses sistemas precisam responder a estímulos do meio dentro de um prazo-limite. Como não é possível o controle sobre o ambiente externo surge ai a complexidade dos sistemas de tempo real. O aumento da complexidade desses sistemas levou a um crescimento do número de funcionalidades disponíveis para aplicações de tempo real.
A grande importância da modelagem é o fato de economizar custos na medida em que erros podem ser eliminados ainda na fase de projeto do sistema. Como exemplo, erros nos sistemas embarcados que muitas vezes possuem hardware sob medida e quando mal analisados teriam como conseqüência prejuízos financeiros e de não cumprimento de prazos. É evidente que a fase de modelagem não substitui os testes e análises ao sistema real.
Para modelagem de sistemas de tempo real, é necessário modelar a infra-estrutura física do sistema, como processador e redes de comunicação e o relacionamento destes com o software. Também é preciso modelar o comportamento do sistema que tem como fundamento o acontecimento de eventos. Além disso, é necessário modelar a estrutura do sistema de tempo real já que o mesmo é intolerante às falhas.
A modelagem de sistemas de tempo real não dispensa a fase de análise dos modelos e precisa de complementação de informações relativas aos recursos do sistema.
A linguagem UML é utilizada para especificar, construir, documentar e visualizar toda a fase de modelagem dos sistemas e será apresentado o seu histórico sobre desenvolvimento de sistemas de tempo real no tópico a seguir.
Histórico
Linguagens de modelagem orientadas a objeto começaram a aparecer entre meados de 1970 e 1980. Nesse período, várias metodologias foram experimentadas para análise orientada a objeto. Entre 1989 e 1994, o número de linguagens de modelagem passou de menos de 10 para mais de 50. Mesmo assim, muitos usuários ainda tinham algumas dificuldades com essas linguagens. Em meados de 1990, novos métodos, porém, utilizando técnicas já existentes melhoradas, foram aparecendo.
Em 1998, a OMG (Object Management Group) criou um grupo para estudar a aplicação da UML para sistemas de tempo real. Desse trabalho surgiu em 2003 uma versão da UML chamada Profile for Schedulability Performance and Time Specification (SPT) com objetivo de definir uma maneira de utilizar as funcionalidades da UML para modelar conceitos e práticas de sistemas de tempo real, ou seja, escalonabilidade e desempenho. Detalhes do perfil SPT serão apresentados nos tópicos seguintes.
Modelagem de Sistemas de Tempo Real
A seguir serão apresentadas as funcionalidades da versão 2.0 da UML e as extensões para modelagem de sistemas de tempo real.
UML 2.0
Segundo Becker (2003) a UML 2.0 incorpora mecanismos novos que valorizam a modelagem dos sistemas de tempo real, já que estes sistemas interagem com o ambiente, são não-determinísticos e altamente concorrentes. Com a UML 2.0 é possível construir modelos a partir da composição hierárquica. Também de acordo com Maeunier et al. (2003) é possível modelar a dependência entre hardware e software acrescentando características do processador.
A UML 2.0 suporta modelagem de concorrência, faz uso de objetos ativos e estados de concorrência. Para isso foram adicionados novos diagramas e um modelo de tempo. O modelo de tempo é dotado de conceitos que são utilizados nos diagramas comportamentais para representar o relacionamento com o tempo. Os conceitos podem ser instantes de eventos, duração e periocidade. Os novos diagramas são: diagrama de estrutura, diagrama de composição, diagrama de comunicação, diagrama de tempo e uma revisão do diagrama de interação.
Com o diagrama temporal ou Timing Diagram é possível visualizar o impacto do tempo em um ou mais objetos e, as condições e os efeitos do tempo nos estados dos objetos. Por outro lado, o diagrama de estados permite verificar as alterações do estado de um objeto.
Aos diagramas de colaboração e de seqüência foram acrescentadas novas funcionalidades como a possibilidade de agrupar interações, permitindo a analise de períodos críticos.
Para melhor compreensão, os diagramas da UML 2.0 são divididos em diagramas de estrutura e diagramas de comportamento. Os diagramas de estrutura são formados por diagrama de pacotes (Package Diagram), diagrama de objeto (Object Diagram), diagrama de classes (Class Diagram), diagrama de desenvolvimento (Deployment Diagram), diagrama de componente (Component Diagram) e diagrama de composição da estrutura (Composite Structure Diagram). Os diagramas de comportamento são formados por diagramas de atividade (Activity Diagram), diagrama de interação (Interaction Diagram), diagrama de caso de uso (Use Case Diagram), e diagrama de estado (State Machine Diagram). Além disso, o diagrama de interação possui ramificações que são os digramas de tempo, (Timing Diagram), diagrama de comunicação (Communication Diagram), diagrama de colaboração (Collaboration Diagram) e diagrama de seqüência (Sequence Diagram).
Conceitos arquitetônicos em UML
A melhoria na arquitetura foi uma das mais importantes inovações da UML 2.0 no que diz respeito à modelagem de sistemas complexos. É possível descrever seu comportamento como uma colaboração de comportamentos de instâncias de outras classes contidas dentro de uma classe. Os conceitos que descrevem esta estrutura interna são Partes, Conectores e Portas.
Partes
O conceito de parte em UML 2.0 torna possível descrever a estrutura interna de uma classe. Uma parte é um conjunto de instâncias de outras classes. A parte faz uso do conceito de encapsulamento e podem ter multiplicidades no formato [n..m], onde o n especifica quantas instâncias podem ser criadas dentro de uma classe e, m significa quantas instâncias no máximo podem ser criadas.
Portas
Uma porta é um ponto de interação de uma classe. Pode ser o seu endereçamento e utiliza-se de meios que sinalizam isso. Uma porta também pode ser uma interface que especifica operações e sinais oferecidos por uma classe. Além disso, é através das portas que ocorre a comunicação com o ambiente externo podendo enviar e receber operações através das portas e também dispor operações por elas.
As portas possuem um atributo de comportamento (isBehavior) que especifica se os pedidos que chegam a esta porta são recebidos por uma máquina de estado do objeto ou por qualquer parte que este objeto possua. Tais portas são chamadas de portas de comportamento. A máquina de estados dirigirá sinais que são enviados à porta de comportamento.
Conectores
Um conector especifica um vínculo (uma instância de uma associação) que habilita a comunicação entre duas ou mais partes. Em contraste com as associações que especificam vínculos entre instâncias de classes, os conectores especificam ligações somente entre partes. Os conectores podem ficar presos a portas ou presos diretamente em uma parte.
Conectores e portas são conceitos excelentes porque causam mais efeito ao reuso de tipos e assim encorajam o uso de componentes.
Extensões UML para sistemas de tempo real
Para modelar sistema de tempo real é necessário aplicar os conceitos de UML às especificações de sistemas de tempo real. O suporte aos mecanismos de tempo real é possível utilizando-se de perfis que incorporam as especificações ou dos avanços na versão 2.0 da UML.
Além dos diagramas e das funcionalidades da UML 2.0 já apresentados, para este artigo, foram escolhidos três perfis por serem os mais utilizados em aplicações de tempo real. São eles:
- Perfil SPT: Schedulability Performance and Time Specification, criado pela OMG.
- ROOM: Real-Time Object Modeling, criado pela IBM e a Rational.
- QoS: Quality of Service, foi adotado pela OMG.
Perfil UML/SPT
Perfil em UML é a indicação de estereótipos, propriedades e restrições que especializam e configuram a UML para um determinado conjunto de aplicações. Porém, não há adição de novos conceitos.
Como apresentado na seção histórico, o perfil SPT (Profile for Schedulability Performance and Time Specification) foi criado em 2003 como uma forma de modelar conceitos de tempo real em UML. A modelagem desses conceitos implica na modelagem da relação comportamento versus o tempo e na modelagem de recursos e serviços. De forma simples, a UML/SPT é um framework para modelar qualidade de serviços, recursos, tempo e conceitos de concorrência, especificados a seguir:
- Recursos: para denotar características e padrões comuns aos métodos de análise.
- Tempo: modelagem de definição de tempo contínuo e tempo discreto (pode fazer uso de relógios e de timers).
- Análise de escalonabilidade: permite implementar métodos de análise de escalonamento.
- Análise de desempenho: permite analisar o desempenho do sistema enquanto modelo.
Análises quantitativas (escalonamento e performance) podem ser aplicadas neste perfil que também provê ao usuário um conjunto de estereótipos e propriedades.
A estrutura da UML/SPT é composta de sub perfis:
- O General Resource Model (GRM) é um pacote de UML/SPT. É dividido em três pacotes:
- RTresourceModeling: para os conceitos básicos de qualidade de serviço e recursos.
- RTconcurrencyModeling: para modelagem de concorrência.
- RTtimeModeling: para modelagem de mecanismos de tempo.
- A Analysis Modeling define sub perfis de análise e inclui:
- PAprofile: para análise de desempenho.
- SAprofile: para análise de escalonamento.
Para modelagem de tempo, o sub perfil RTtimeModeling define um modelo para representação do tempo. Este perfil é formado um conjunto de estereótipos e propriedades associadas ao modelo que aplicam em UML elementos para especificar valores de tempo como o <<RTtime>>, mecanismos de relacionamento de tempo como <<RTclock>>, <<RTtimer>>, <<RTtimeout>> ou restrições temporais como <<RTdelay>> e <<RTintervale>>.
Modelagem de comportamento
Em UML/SPT a modelagem de conceitos de tempo real se aplica aos diagramas de colaboração, seqüência, estados e atividade. A seguir uma abordagem sobre eles:
- Diagrama de Colaboração: segundo Silva e Videira (2001) este diagrama mostra uma interação organizada espacialmente, independente da dimensão do tempo, mostrando as relações entre objetos que desempenham diferentes papéis funcionais. A seqüência temporal de interações e atividades concorrentes é representada com o recurso a números seqüenciais.
- Diagrama de Seqüência: um diagrama de seqüência tem duas dimensões, uma vertical que representa o tempo, e outra horizontal que representa os diferentes objetos. Ele mostra interações de objetos organizadas em uma seqüência de tempo e de mensagens trocadas, mas não trata associações entre objetos, como no Diagrama de Colaboração.
- Diagrama de Estados: também de acordo com Silva e Videira (2001) este diagrama representa os possíveis estados de um objeto e as transições entre eles, assim como as atividades efetuadas em cada estado do objeto. Uma transição é desencadeada por um evento ou por uma passagem de tempo.
- Diagrama de atividades: este é um caso especial de diagramas de estado porque representa todos os estados nos quais todas as transições são disparadas pela finalização das ações em estados anteriores. Estes diagramas são usados em situações onde todos ou a maioria dos eventos representam à conclusão de ações geradas internamente.
Perfil UML/QoS
O perfil UML para modelagem de qualidade de serviço, características e mecanismos de tolerância a falhas (UML/QoS) foi adotado pela OMG em 2004. Este perfil permite capturar conceitos, variedades de exigências e propriedades de qualidades de serviços.
A UML/QoS é relevante para modelagem de sistemas de tempo real porque complementa o perfil UML/SPT apresentado anteriormente. Porém, enquanto a UML/SPT foi definida para unir desempenho e análise de escalonamento, a UML/QoS permite definir qualquer conjunto de qualidade de exigências de serviço e suporta qualquer análise específica sobre segurança de sistemas críticos de tempo real.
O uso de diagramas para modelagem também é uma característica de UML que propõe um procedimento com três passos:
- Definição de características de QoS: as definições de características de qualidade de serviço levam, através de especializações, a um catálogo de características de QoS. Este catálogo é organizado em categorias de: Performance, Dependência, Segurança, Integridade, Processamento, Latência, Eficiência, Demanda, Credibilidade e Disponibilidade. Posteriormente, adapta-se o contexto de tempo real nas características de QoS que são modelos de classes que possuem parâmetros.
- Definição de qualidade de modelo: as características de QoS poderiam ser nomeadas como valores atuais. Faz-se isso através de características de qualidade de classes e ligações do modelo. O modelo UML que contem as informações de ligações e as classes é chamado de Modelo de Qualidade.
- O último passo é a notação de modelos UML usando a qualidade de serviços exigidos.
Perfil UML-RT
A modelagem de sistemas usando uma Linguagem de Modelagem Orientada a Objeto (ROOM) foi combinada com a UML para tempo real (UML-RT) para direcionar o desenvolvimento de sistemas complexos de tempo real como os de telecomunicação, defesa, controle automático entre outros.
A UML para tempo real ou UML for REAL-TIME combina UML, funções de modelagem e conceitos de ROOM para criar uma solução completa para os sistemas complexos de tempo real.
As funções de modelagem fazem referência aos padrões de comunicação estruturais entre componentes de software. Na UML 1.1, o diagrama de colaboração, esquematiza a base de padrões de desenvolvimento estruturais, e tornou-se a primeira classe que modela entidades.
ObjecTime Limited (ObjecTime) era um sócio da UML 1.1 e contribuiu para adequar o ROOM aos padrões da UML.
ROOM é uma linguagem de modelagem visual com semântica formal, desenvolvida pela ObjecTime. Ela foi aperfeiçoada para especificação, visualização, documentação e automatização da construção de sistemas complexos, dirigidos por eventos, e para sistemas distribuídos.
A UML for Real-Time (UML-RT) é um modelo padrão, co-desenvolvido pela ObjecTime e a Rational Corporation de uma junção de conceitos da UML 1.1 e de formalismos originalmente implantados pela ObjecTime que definiram o ROOM. ObjecTime Developer é uma ferramenta de automatização de software que provê ao modelo capacidades de execução, e gera código automático para as aplicações.
A UML-RT também pode ser entendida como um perfil real-time desenvolvido pela Rational e utiliza-se de mecanismos de extensão da UML para capturar os conceitos definidos pelo ROOM. Contrária aos perfis UML/SPT e UML/QoS, a UML-RT é uma linguagem própria que não dá suporte a tempo e restrições temporais. Ela é suportada por uma ferramenta CASE chamada de RationalRT , que permite como mencionado anteriormente, a geração de código automático e a ligação do código com a execução.
Com a UML-RT é possível modelar estrutura e comportamento que serão definidas a seguir.
Modelagem de estrutura
A Modelagem de estrutura ou Structure Modeling na UML-RT possui entidades chamadas de cápsulas (capsules) que fazem comunicação entre objetos ativos. As cápsulas interagem enviando e recebendo mensagens através de interfaces chamadas portas (ports). Além disso, as cápsulas podem ter uma estrutura interna composta de outras cápsulas que se comunicam. Esta hierarquia permite a modelagem de sistemas complexos.
Na UML-RT, uma cápsula no diagrama de colaboração é equivalente para o ROOM ao ator no diagrama de estrutura.
Modelagem de comportamento
Na Modelagem de comportamento ou Behavior Modeling o comportamento é modelado por uma extensão de máquinas de estados finitos, e é visualizada utilizando os diagramas de estado em UML. As máquinas de estado são hierárquicas desde que um estado possa ser decomposto em outras máquinas de estado. Uma recepção de mensagem ativa uma transição em uma máquina de estados. Ações podem ser associadas com transições ou entradas e saídas de um determinado estado.
No ROOM a representação de um ator pode ser utilizada usando o ROOMChart. Na UML-RT a implementação de uma cápsula poder ser representada usando uma hierarquia equivalente a máquinas de estado.
ROOM X SPT X UML 2.0
Aplicações com requisitos temporais são cada vez mais comuns, portanto, analisar e modelar sistemas com parâmetros de qualidade e verificação de tempo é muito importante. Por isso, foram apresentados perfis que unem a UML a especificações de tempo real e podem ser analisados de acordo com suas vantagens e desvantagens.
ROOM – Vantagens x Desvantagens
As vantagens do perfil ROOM enquadram o fato de que o modelo de comunicação dos eventos é baseado em troca de mensagens, a comunicação com o ambiente externo acontece somente trocando mensagens que são guardadas ou retomadas em portas e não há compartilhamento de variáveis globais. Além de que este modelo de troca de mensagem permite a execução concorrente e distribuída dos atores em ROOM (muito utilizado em sistemas distribuídos) e a comunicação das mensagens pode ser síncrona ou assíncrona.
Apesar disso, o perfil ROOM não é um padrão, é muito especializado (principalmente para sistemas embarcados) e é desenvolvido somente por duas empresas (IBM e RATIONAL).
SPT – Vantagens x Desvantagens
O avanço na área por padronizar a modelagem de requisitos temporais usando a UML, apresentando um alto grau de generalização e com a intenção de não se concentrar em uma dada metodologia ou tecnologia são as vantagens do perfil SPT, que ainda possui algumas desvantagens como concentrar muitos mecanismos de programação suportados nos sistemas operacionais de tempo real e tornar complexa a modelagem de muitos requisitos temporais. Além de carecer de elementos que simplifiquem as especificações de requisitos, e não diretamente a forma como estes são programados.
UML 2.0 – Vantagens x Desvantagens
A UML 2.0 apresenta-se como um padrão mundial que agrega conceitos como portas, protocolos e conectores (ROOM), e o uso de restrições temporais, ainda adicionou um novo diagrama, chamado digrama de tempo – (SPT). Entretanto, ela não diferencia tempo discreto de contínuo e é genérica demais.
Conclusão
Segundo os conceitos de UML e perfis apresentados neste artigo é possível verificar que a modelagem de sistemas de tempo real é bastante complexa porque precisa de muitas complementações durante a construção do modelo. Devido à complexidade visualiza-se por toda a fase de modelagem a importância de cada característica do perfil que se utiliza.
A fim de comparar os perfis, compreende-se que na UML 2.0 foi acrescentado o modelo de tempo, tão importante devido às restrições temporais e também as melhorias nos diagramas já existentes. Porém, ainda falta o detalhamento encontrado no perfil SPT que o torna uma opção viável dentre os perfis apresentados. Ainda assim, outra opção é utilizar o ROOM que possui suporte da ferramenta RATIONALRT e torna o trabalho menos complexo.
Nos dias atuais, os sistemas de tempo real encontram-se em acelerado desenvolvimento, principalmente os softwares embarcados. Embora a UML seja um padrão e a versão 2.0 tenha se mostrado abrangente dentro da aérea de tempo real, ainda é necessário fazer uso dos perfis para modelagem de escalonamento e de qualidade.
A elaboração de um modelo a partir dos conceitos apresentados nos três perfis é a solução mais evidente no quis diz respeito à utilização de todos os requisitos necessários possíveis a construção do sistema e a redução no número de falhas durante a construção do projeto, já que os sistemas de tempo real são intolerantes a elas.
Bibliografia
- BECKER, L.Um Método para Abordar todo o Ciclo de Desenvolvimento de Aplicações Tempo Real, 2003, Tese de doutorado – Programa de Pós-Graduação em Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre.
- MAEUNIER, J.; LIPPERT, F.; JADHAV, R.; RT Modelling with UML for safety critical applications: ESTUDO DE CASO.
- SILVA, A.; VIDEIRA, C.; UML, Metodologias e Ferramentas CASE. Lisboa: Centro Atlântico, 2005.
