See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/267336815

Reutilizando padrões de projeto para desenvolvimento de software embarcado

de tempo real

Conference Paper · November 2008

DOI: 10.13140/2.1.5057.5366

CITATION READS

1 297

5 authors, including:

Gabriel Moreira Denis Montini

27 PUBLICATIONS   174 CITATIONS   
Instituto Tecnologico de Aeronautica
38 PUBLICATIONS   81 CITATIONS   
SEE PROFILE
SEE PROFILE

Daniela America da Silva Luiz Alberto Vieira Dias

Instituto Tecnologico de Aeronautica Instituto Tecnologico de Aeronautica
31 PUBLICATIONS   26 CITATIONS    214 PUBLICATIONS   434 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

17th International Conference on Information Technology : New Generations (ITNG 2020) View project

15th International Conference on Information Technology : New Generations (ITNG 2018) View project

All content following this page was uploaded by Adilson Marques da Cunha on 26 October 2014.

The user has requested enhancement of the downloaded file.

 Reutilizando padrões de projeto para desenvolvimento de software
embarcado de tempo real

BSc. Gabriel de Souza Pereira Moreira (ITA) gabrielspmoreira@yahoo.com.br

MSc. Denis Ávila Montini (ITA) denisavilamontini@yahoo.com.br
MIT. Daniela América da Silva (ITA) das. america@gmail.com
PhD. Luiz Alberto Vieira Dias (ITA) vdias@ita.br
Dsc. Adilson Marques da Cunha (ITA) cunha@ita.br

Resumo: Este artigo descreve a reutilização de componentes de software em C++ em um

ambiente IBM-Rational Rose Real Time (RRRT). Nele, refina-se um processo de
desenvolvimento de software, reutilizando-se um padrão de projeto (design pattern). A sua
principal contribuição encontra-se na definição de um processo para construção de uma
Plataforma de Registros de Dados (Plataform DaTa Logger – P-DTL). A utilização de design
pattern em um Ambiente Integrado de Engenharia de Software Ajudada por Computador
(Integraded Computer Aided Software Engineering Enviroment - I-CASE-E) para a definição
de um processo industrial visou reaproveitamentos sistêmicos futuros. As diretrizes do
Processo Unificado da Rational (Rational Unified Process – RUP) ajudaram aos alunos de
Graduação e Pós-graduação do Instituto Tecnológica da Aeronáutica (ITA), no segundo
semestre de 2007, a criar um cenário fértil para a aplicação prática dos conceitos de design
pattern. Um Componente de Software de Computador (Computer Software Component – CSC)
foi construído com atributos e métodos genéricos para viabilizar sua reutilização. A partir de
um relatório de qualidade, os mesmo alunos integrantes do Grupo de Pesquisa em Engenharia
de Software (GPES) aprimoraram o trabalho anteriormente realizado em sala de aula e
propuseram um design pattern específico para o gerenciamento da entrada e saída de dados.

Palavras-chave: Fábrica de software, Células de Manufatura, Ambiente de Ferramentas I-

CASE-E, Design Pattern, Reutilização de Componentes e Rational Rose Real Time.

1. Introdução
No segundo semestre de 2007, os integrantes do Grupo de Pesquisa em Engenharia de
Software (GPES) utilizaram o LABoratório de Desenvolvimento TECnológico da Fundação
Casimiro Montenegro Filho (LAB TEC da FCMF) do Instituto Tecnológico de Aeronáutica
(ITA) para desenvolver um software embarcado de tempo real.
O software desenvolvido utilizou uma metodologia de Aprendizado Baseado em
Problemas (Problem Based Learning - PBL) [CUNHA, 2007], o processo unificado da IBM
Rational (Rational Unified Process - RUP), o Ambiente Integrado de Engenharia de Software
Ajudada por Computador (Integraded Computer Aided Software Engineering Enviroment - I-
CASE-E) - Rational Rose Real Time (RRRT) [RATIONAL, 2003] e um padrão de projeto
(design pattern) [CHRIS, 1977] [GoF, 1995] [GAMMA, 2005] [SELIC, 2006].
Este trabalho enfoca a definição de um processo de reutilização de padrões de projeto
para o desenvolvimento de software embarcado de tempo real. O RUP foi customizado em
pontos chave para a elaboração de um design pattern. Um estudo de caso, envolvendo uma
Plataforma de Registros de Dados (Plataform DaTa Logger – P-DTL), foi desenvolvido,
prototipado e experimentado sob a forma de um Gerenciador de Entradas e Saídas (IO
Manager), utilizando o compilador Microsoft Visual C ++.
A utilização de ambientes integrados de ferramentas CASE representa significativos

1
investimentos iniciais de desenvolvimento, envolvendo aquisição de licenças, equipamentos,
treinamentos e capacitações.
A concepção de um novo modelo “W” de processo de desenvolvimento de software
representa a principal contribuição deste artigo. Este modelo “W” envolve a identificação,
catalogação e reutilização de um padrão de projeto e uma posterior quantificação de ganhos de
produtividade e qualidade, obtidos a partir de reutilizações de software, durante o processo de
desenvolvimento.
2. Cenário
A pesquisa reportada neste artigo aplicou a metodologia PBL, visando restringir o
escopo de reutilização dos padrões de projeto para o desenvolvimento de software durante a
análise do Ciclo de Vida de Desenvolvimento de Sistemas (Systems Development Life Cycle -
SDLC) apresentado na Figura 03.
Ao se estudar um SDLC voltado para software embarcado de tempo real, em um
ambiente acadêmico, adotou-se a seguinte nomenclatura. No mais alto nível, encontra-se o
Sistema de Software de Computador (SSC), dividido em Itens de Configuração de Software
de Computador (ICSC), em Componentes de Software de Computador (CSC), e por último,
em Unidades de Software de Computador (USC), todos representados na Figura 01.

LEGENDA: SSC - Sistema de Software de Computador.

CSCI - Itens de Configuração de Software de Computador.
CSC - Componentes de Software de Computador.
USC - Unidades de Software de Computador.

FIGURA 01 – Estratégia para obtenção do Sistema de Software de Computador do Projeto VANT-EC-SAME.

Fonte: Cunha (2007).
Neste artigo, aborda-se apenas um CSC, a Plataforma de Registros de Dados
(Plataform Data Logger – P-DTL), composta por três USCs: a USC P-GED (Plataforma da
Unidade de GErenciamento de Dados); a USC P-ARM (Plataforma da Unidade de
ARMazenamento de Dados), e USC P-REC (Plataforma da Unidade de RECuperação de
Dados) do Projeto de um Veículo Aéreo Não Tripulado associado a uma Estação de Controle e
a um Satélite Artificial para Monitoramento Ecológico (VANT-EC-SAME), [CUNHA,
2007].

3. I-CASE-E, OO, UML e Reutilização de Design Patterns

O ambiente integrado de ferramentas CASE IBM-RRRT, utilizando a Linguagem de

Modelagem Unificada (Unified Modeling Language – UML) [OMG, 2007], pôde ser utilizado
para implementar o paradigma de Orientação a Objetos (OO), propiciando a geração de
componentes em C++ em um projeto de design patterns. A utilização da UML propicia uma
linguagem visual para modelagem, construção e documentação de artefatos usuais em sistemas

2
complexos de software OO [GAMMA, 2005].
Para avaliar o uso de design patterns foi necessário analisar o processo RUP existente,
porque a reutilização de padrões é um tipo de fenômeno não natural e busca o refinamento do
processo endereçando uma pesquisa tecnológica específica para este fim.
3.1 Orientação a Objetos e UML-RT utilizados no RRRT
Para refletir especificidades técnicas de implementação de codificação, alguns
conceitos tradicionais de OO [BOOCH, 1999] [BUDD, 2002] como classes e pacotes para
software de tempo real para design patterns, foram melhorados a partir da UML tradicional
para Tempo Real (Unified Modeling Language Real Time - UML-RT).
Entendem-se, nesta abordagem, por Sistemas de Tempo Real os sistemas que precisam
de sinais e dados em determinados intervalos de tempo para ter seu uso aceito. A UML para
Tempo Real (UML-RT) foi desenvolvida de acordo com a norma IEC Std 61499 e introduzida
para ajustar a modelagem UML clássica para Sistemas Tempo Real [SELIC, 2006].
Entre os principais aspectos de adaptação da UML [OMG, 2007] para UML-RT,
focalizou-se neste trabalho os conceitos de adaptação da OO tradicional, a fim de que essa
abordagem possa ser implementada no sistema de Tempo-Real do RRRT. Essa linha de
pesquisa da UML-RT focou na definição de um conjunto de construtores que incluíram
cápsulas, conectores e portas para construir componentes que possam ter uma menor agregação
entre outros elementos do sistema [SELIC, 2006].
O Rational Unified Process(RUP) representa um produto cuja função é descrever um
processo completo e padronizado de Engenharia de Software, a fim de prover uma abordagem
disciplinada para a atribuição de tarefas e responsabilidades, dentro de uma visão organizada
de construção de softwares desenvolvidos pela IBM-Rational [JACOBSON, 1999].

A linha base sugerida pelo RUP para artefatos contém documentos de modelagem de
sistemas que referenciam a UML, e por extensão, a UML-RT. Para exemplificar a composição
formada pelo RUP e pela UML, na Figura 02 apresenta-se a relação entre o um processo
unificado (Unified Process - UP) e a linguagem UML [SELIC, 2006].

FIGURA 02 – Relacionamento entre o processo UP e os diagramas da UML. Fonte: Cunha (2007).

O RUP define um conjunto de artefatos de software, organizados pelo processo UP,

necessários para a realização de projetos de software utilizando as melhores práticas de
Engenharia de Software [RATIONAL, 2005]. O RRRT é uma ferramenta de modelagem
visual para Tempo-Real que dispõe de mecanismos para apoiar processos, metodologia,
padrões comuns e frameworks como o RUP.
A combinação da geração de código pelo RRRT, partindo de uma modelagem visual da
UML-RT no UP, consiste em uma forma de framework de tempo-real. Esta abstração originou-

3
se de uma modelagem universal com UML-RT, possibilitando a geração de códigos-fonte
compatíveis com diferentes linguagens, sistemas operacionais e compiladores [SELIC, 1994].
A ferramenta gera código para implementar o modelo de sistema projetado [GAMMA,
2005]. Os componentes gerados pelo RRRT incluem pacotes, classes passivas (com padrões de
classes orientadas a objeto), cápsulas (classes ativas com portas e conectores) e classes de
protocolo [RATIONAL, 2003].
A organização das atividades focou centralmente nos meta-modelos dos diagramas de
classe e de pacote. Esses meta-modelos serviram para definir o teste de conceito do
componente com a utilização dos diagramas de Casos de Uso, de Classe, de Seqüência, de
Estrutura e de Estados. A efetividade da OO foi traduzida pela modelagem UML-RT na
criação de códigos-fonte de programa em C++. Esses programas mostraram-se funcionais para
o ambiente RRRT, permitindo a aplicação do conceito de reutilização dos diagramas criados.
3.2 O Framework da Ferramenta I-CASE-E RRRT
A construção de componentes de software para sistemas de tempo real foi realizada por
intermédio da utilização de um framework. A abordagem de reutilização foi a top-down,
permitindo-se selecionar características genéricas, hipoteticamente adaptáveis a outros
componentes semanticamente similares.
Um framework é uma coleção de classes colaborativas que provêm funcionalidades
específicas. Segundo James Booch, a utilização de frameworks favorece a reutilização da
orientação a objetos [BOOCH, 1999], a fim de que os desenvolvedores possam customizá-los
para novas aplicações.
O fundamento empregado na reutilização foi o de que um framework precisa ser
genérico para um intervalo semanticamente conhecido [GAMMA, 2005]. O efeito da aplicação
do conceito de um projeto de design patterns, utilizando-se a ferramenta I-CASE-E RRRT,
visa obter um padrão de arquitetura de componente. Esse componente tem que ser modelado
segundo a UML-RT para um processo RUP adaptado [RATIONAL, 2003].
O modelo de processo adaptado e sugerido foi obtido pela observação do ponto mais
conveniente do processo para a construção e reutilização dos design patterns. Utilizou-se
conceitos já existentes como o modelo “V”, oriundo de Linhas de Produção de Células de
Manufatura [Montini, 2005], para o SDLC adaptado à reutilização de componentes. O
processo pode ser representado pelo modelo “W” proposto, mostrado na Figura 03.

FIGURA 03 – O Metamodelo “W” de Reutilização de Componentes. Fonte: Autores.

4
 O processo foi obtido com a customização do UP [TCS, 2006]. Neste modelo, as fases
de “um” a “cinco” identificam os Requisitos de Negócios, Financeiros, Funcionais, Não
Funcionais e Detalhados, representados pelos seus diagramas e, mais especificamente, pelos
casos de uso do sistema modelado.
O SDLC estudado constituiu-se de doze Fases. Os conceitos de framework aplicados a
reutilização, ocorreram entre as Fases cinco e sete, conforme mostrado na Figura 03.
O modelo “W” foi organizado em três Visões: Semântica, Lógica e Física, todas
fundamentadas em diferentes conceitos. A primeira Visão do modelo “W”, a Semântica, define
um processo para a pesquisa de design patterns construídos. A sua reutilização se dá através de
um conjunto de procedimentos para definir os pontos específicos de customização do
componente analisado. A Visão Lógica agrupa e documenta os requisitos decorrente das cinco
primeiras Fases do projeto. Ela endereça os aspectos de reutilização e potencialização do uso,
por meio de generalizações das necessidades e funcionalidades. A Visão Física implementa a
construção, a adaptação e os testes de componentes em uma linguagem de computação.
3.3. Reutilização de Componentes
A utilização de conceitos específicos da OO, da UML-RT, do RUP e das ferramentas
RRRT e Microsoft C++ constituiu-se no fundamento básico para o projeto de reutilização de
componente de software [BOOCH, 1999] [BUDD, 2002] [SELIC, 2006].
O uso de design patterns, de forma disciplinada para a geração de códigos, e a sua
descrição de reutilização foi proposta por Budd [BUDD, 2002]. Com base nas diretrizes
apontadas Budd nessas pesquisas, organizou-se quais produtos de software e atividades são
necessários para sua possível reutilização.
As principais diretrizes propostas para a reutilização foram definidas por um conjunto
de características fundamentais ao funcionamento do modelo de reutilização, construído a
partir da definição dos seguintes aspectos descritos no Quadro 01.

QUADRO 01 – Diretrizes para a reutilização design patterns

- Requisitos Genéricos de sistemas são definidos por características mínimas de ambiente, ceteris paribus1,
em Objetivo, Contexto e Estrutura fundamental.
- Funcionalidades Genéricas.
- Classes e Tipificação de Protocolo de Comunicação.
- Definição de um Procedimento de Customização.
- Definição de Teste e Homologação.
Fonte: Autores.

Para que se reuse um software é preciso remodelá-lo e torná-lo genérico pela utilização
de pesquisas com os diagramas de classes. A produção de código reusável exigiu um
tratamento de customização, a fim de criar um design pattern mais elaborado e de alcance
generalizado.
A adaptação de um componente não é uma atividade inovadora. A hipótese testada foi a
de quão rápido e de melhor qualidade é um componente, quanto à reutilização é melhorada
com serviços pré-definidos e genéricos.
Semanticamente, quanto maior similaridade existir entre os Casos de Uso e as Classes
dos componentes envolvidos na análise, mais rápida será a identificação e redefinição do
design pattern. Sendo assim, quanto mais especializado for o componente construído, menor

1
Nota dos Autores: Ceteris paribus é uma expressão do Latim que pode ser traduzida por "todo o mais é constante" ou "mantidas inalteradas
todas as outras coisas". A condição ceteris paribus, é usada na economia para fazer uma análise de mercado da influência de um fator sobre
outro, sem que as demais variáveis sofram alterações. Por exemplo: Um aumento de preço de um determinado produto causa uma redução na
demanda, "ceteris paribus", pois, se a renda do consumidor aumentar tanto quanto o preço do produto em questão, a demanda se manterá
estável.

5
será a sua possibilidade de reutilização. Por outro lado, quanto mais genérico ele for, maior
será a sua reprogramação.
Esta hipótese de contribuição foi verificada com um teste sobre o relacionamento
semântico na reutilização. O framework UP foi utilizado pela UML-RT do ambiente de
ferramentas I-CASE-E RRRT. Este padrão foi customizado para um processo de
desenvolvimento de componentes com características adaptáveis e projetadas para permitir
esses benefícios aos desenvolvedores.

4. O Projeto de design pattern

O GPES propôs o design pattern identificado pela tipologia do Grupo de Pesquisas
Gang of Four, GoF, que representa uma das famílias de padrões sugeridos, dentre os vários
disponíveis e implementáveis para diversas linguagens de programação orientada a objetos. O
design pattern projetado nesta pesquisa acumula características genéricas de classes, através de
atributos e métodos [GAMMA, 2005].
Os autores do GoF propuseram inicialmente as seguintes famílias de padrões: de
Criação, Estruturais, Comportamentais e General Responsibility Assignment Software Patterns
(GRASP) [GoF, 1995]. O ponto de partida para a escolha do padrão foi a identificação do seu
tipo a ser utilizado para a seleção de uma nova entidade.
Entre as famílias de padrões conhecidas, o conceito selecionado para o projeto
desenvolvido foi o da família de padrão de “Criação” com o subtipo de “Prototipação”. Para
o estudo do fenômeno da reutilização e customização de design patterns, foi necessário
converter o padrão criado de uma família de padrões para outra família mais adequada para a
sua reutilização e customização.
O critério de seleção foi o da associações entre classes e objetos representado pela
família de padrões de Criação [RATIONAL, 2003]. O design pattern criado pela equipe foi
catalogado como IO Manager e se enquadra na categoria de padrões Comportamentais, pois
descreve a modelagem de interações e divisões de responsabilidades entre as classes ou
objetos.
4.1 O processo de identificação do design pattern
O processo de identificação começou com uma pesquisa sobre os design patterns já
existentes e suas categorias. Destacaram-se entre eles os padrões catalogados pelo GoF [GoF,
1995], a fim de modelar o design pattern IO Manager, conforme as boas práticas de padrões de
projeto [MESZAROS, 1996].
A operação de “clonagem”, ou seja reutilização, de um programa retirado de um projeto
para a transformação em um protótipo genérico, design patterns Creation Prototype, foi a
hipótese inicialmente testada. A redução do escopo restringiu as características específicas de
software e hardware necessárias para a criação de um dispositivo comercial funcionalmente
completo.
O componente escolhido para o teste foi o CSC P-DTL, Data Logger, que compõe o
CSCI PCDs - Plataforma de Coletas de Dados. As restrições desejadas para o design pattern
foram baseadas na exigência de Quality of Services, QoS, isto é, na necessidade de se
estruturar os seguintes serviços reutilizáveis para uma Estação de Controle exercendo três
macro-funcionalidades de processamento: a Entrada, a Saída (Input/Output, I/O) e o
Gerenciamento dos Dados.
A modelagem dos diagramas de casos de uso organizou a aplicabilidade do pattern no
framework RRRT [RATIONAL, 2003], visando validar as suas exigências. O estabelecimento
do patterns Data Logger pela comunicação entre as classes previstas na modelagem de

6
sistemas de computador/software tem sido uma solução utilizada há pelo menos três décadas.

FIGURA 04 – Relacionamento entre elementos do design pattern Fonte: MESZAROS (1996).

O Data Logger permite o controle das transações realizadas entre os seus objetos
dependentes de acionamento e o controle de armazenagem e recuperação de dados,
programado ou por meio de acessos externos. Um esquema Data Logger é ilustrado na Figura
04.
5. A reutilização do design pattern Estruturais
A aplicabilidade do padrão de projeto IO Manager em Componentes de Gerenciamento
de Entrada e Saída de Dados veio do Projeto VANT-EC-SAME, e só foi possível através do
detalhamento técnico do padrão descrito e registrado em uma Ficha Catalográfica. O padrão de
frameworks encontra-se baseado na exigência do QoS para se estruturar um servidor para a
reutilização de componenetes catalogados.
A Ficha Catalográfica contém dados e a modelagem UML-RT proposta para atender as
três funcionalidades da CSC P-DTL, Data Logger, representado pela Figura 05. Esta Ficha
Catalográfica visa organizar as informações para facilitar a localização e recuperação dos
padrões cadastrados e implementados pelo framework.

FIGURA 05 – Ilustração do componente original P-DTL. Fonte: Autores.

5.1 O processo de identificação e descrição de design pattern para a reutilização
O processo do RUP é genérico e encontrou-se oportunidades de melhoria nos seus
procedimentos para a realização dos processos de identificação, elaboração e reutilização do

7
design pattern. Em um processo definido como genérico pode-se não estabelecer os papéis e
responsabilidades para as atividades especializadas.
Uma vez identificada a oportunidade de melhoria, acrescentou-se a Fase 6 da Figura 03
ao modelo “V” original. O Quadro 04 apresenta esta modificação no modelo “V”, passo a
passo, transformando-o em um modelo “W”. O detalhamento a seguir descreve o conjunto de
atividades complementares realizadas para a reutilização do design pattern, caracterizando a
principal contribuição deste artigo.
Quadro 04 – Pattern Process - Atividades para a aplicação do processo reutilização de design pattern.
Procedimento de Reutilização
Atividades Ações Objetivos
1. Identificação do 1. Analisar as equivalências semânticas dos 1. Para cada tipo de requisito, apresenta-se uma matriz que lista os
negócio. requisitos Negócios, Financeiros, componentes que contenham pelo menos um dos requisitos em um
Funcionais, Não Funcionais e Detalhados. eixo e todos os atributos no outro eixo.
2. Criar as Matrizes de Atributos de
Requisitos.
2. Seleção de 1. Pesquisar na biblioteca de componentes os 1. Definição dos critérios de escolha dos componentes rastreados.
componentes requisitos identificados. Para cada tipo de requisito, apresenta uma matriz que lista os
candidatos na 2. Analisar as Matrizes de Rastreabilidade de requisitos em um eixo e todos os itens rastreados no outro eixo.
biblioteca. Requisitos.
3. Teste de 1. Análise da documentação e infra-estrutura 1. Verificação e Validação do Projeto de Teste do componente.
componentes. de teste.
4. Planejamento da 1. Detalhar os pontos de customização para o 1. Mapeamento da árvore de rastreabilidade, através uma visualização
customização e planejamento. gráfica, dos pontos de customização e os relacionamentos de
iteração. 2. Árvore de Rastreabilidade de Requisitos. Rastreabilidade afetados.
5. Distribuição de 1. Disponibilizar para a equipe da 1. Utilização de uma ferramenta de gerenciamento de requisitos para
componentes para documentação do componente e os pontos manter as informações de repositório.
customização. de customização.
6. Processo de 1. Dimensionar e executar e customização do 1. Atualização do Plano de Projeto – A atividade de estimativa de
Customização. componente. software consiste na identificação dos atributos que devem ser re-
documentados nos produtos, no Plano de Gerenciamento de
Requisitos.
2. Envio do componente para a Customização: O “Revisor do Projeto”
determina se a equipe de projeto já reuniu os itens necessários para
a construção. A principal meta é determinar se o plano de trabalho é
suficiente para a produção. Os outros passos das atividades de
revisão permanecem iguais, visto que são condizentes com o
Pattern Process.
7. Identificação de 1. Proposta de um novo padrão à biblioteca. 1. Especificação do motivo da Seleção: A equipe técnica do projeto
um padrão de que produziu os artefatos reúne todas as características genéricas da
projeto candidato. modelagem e arquitetura do componente para que um padrão possa
ser apresentado aos revisores.
2. Seleção dos componentes na biblioteca para a revisão: A equipe
deve informar ao “Revisor do Projeto” quando eles estarão prontos
para a revisão e quais são os alvos da revisão.
8. Catalogação do 1. Realizar o processo de catálogo de padrão 1. Elaboração da ficha catalográfica do padrão de projeto, no qual seja
padrão de projeto. de projeto. descrita sua motivação, aplicabilidade, estrutura, ganhos na
reutilização e exemplos de implementação.
2. Armazenamento da ficha catalográfica em uma biblioteca de dados
e informações sobre requisitos, atributos e dependências de projeto.
9. Finalização do 1. Revisar a documentação. 1. Revisão e validação os passos e documentações anteriores.
Projeto de
reutilização.
Fonte: Autores.
A adaptação do RUP para a utilização do pattern process mostrada no Quadro 04
representou uma forma original e adaptativa de se resolver a implementação da verificação
para a validação de um componente já construído, de forma integrada. A implementação de
uma Revisão Técnica, conhecida como Inspeção Final, Final Inspection, FI, foi realizada ao
final de cada Fase do SDLC do Projeto, seguindo-se o conceito do Modelo Entry Task Verify
and eXit (ETVX) [RADICE, 1988].

8
6. Análise de produtividade da reutilização do design pattern
Uma análise de produtividade foi realizada utilizando-se a técnica de estimativa de
esforços por Pontos de Casos de Uso, Use Case Points UCP, sempre com os mesmos critérios,
conforme mostrado na Figura 06. Uma estimativa foi realizada, logo no início do Projeto,
prevendo-se qual seria o esforço necessário para o desenvolvimento do CSC P-DTL.
Considerando-se apenas um grupo de três desenvolvedores, com baixa disponibilidade mensal,
por ser um Projeto Acadêmico. Neste caso, chegou-se a uma estimativa de esforços para o seu
desenvolvimento total igual a 5,5 meses.

Figura 06 - Estimativa de desenvolvimento do P-DTL usando UCP. Fonte: Autores.

O tempo efetivo de desenvolvimento do protótipo do CSC P-DTL, durante o

andamento da disciplina CE-235 – Sistemas Embarcados de Tempo Real, mostrou-se bem
próximo do tempo estimado. Os três desenvolvedores dedicaram cerca de 600 horas de
trabalho para a elaboração de: levantamento de requisitos, modelagem de Casos de Uso,
diagramas de Sequência, modelagem de Classes, Máquinas de Estados das Cápsulas e
codificação em C++ diretamente no ambiente de ferramentas. Dessas 600 horas, considerando-
se apenas a Fase de Construção do RUP, foram dedicadas cerca de 300 horas para a efetiva
modelagem, implementação e testes do protótipo.
Foram utilizadas cerca de 50 horas para a generalização do componente como resultado
da utilização do processo de verificação para a validação das características funcionais dos dois
componentes de entrada e saída de dados. Em ambos CSCs P-DTL e P-COM, foram aplicados
o mesmo processo construtivo, reutilizando-se o design pattern IO Manager. Ao final dos
processos de implementação, foram comparados os seus tempos de desenvolvimento da
mesma Fase de Construção.
Para uma base de cálculo, foram utilizados os apontamentos de horas realizados nos
Projetos de componentes P-DTL e P-COM, segundo a condição ceteris paribus. A seguir,
apresenta-se uma tabulação dos dados, demostrando-se os ganhos de produtividade na Fase de
Construção com a reutilização do design pattern IO Manager.

9
Tabela 01 – Aferição dos tempos de construção dos componentes P-DTL e P-COM e de reconstrução utilizando o
IO Manager.

SDLC Componente Tempo da Construção Tempo de Construção utilizando Ganho de

Original (CE-235) o design pattern IO Manager na Produtividade
FCMF
Ciclo completo P-DTL - Data Logger PCD 300 h 50 h 85%
Ciclo completo P-COM - Comunicações do PCD 230 h 40 h 82%

Fonte: Autores.
Tabela 02 – Análise do Estudo de Caso do Projeto do CSC P-DTL.

Projeto do P-DTL realizado na FCMF,

Projeto do P-DTL realizado durante a CE-235
Fases do SDLC utilizando o design pattern IO Manager
Horas Percentual Horas Percentual
Demais Fases 250 42% 250 83%
Construção 350 58% 50 17%
Total do projeto 600 100% 300 100%
Fonte: Autores.
A análise dos dados coletados reunidos nas Tabelas 01 e 02, com os ganhos da
reutilização do design pattern IO Manager, dentro da dimensão de esforço em horas
trabalhadas permitiu concluir que:

1 – O esforço em horas do Projeto do CSC P-DTL ficou 50 % menor com a reutilização do

design pattern IO Manager;
2 - Na Fase de Construção do CSC P-DTL, o ganho com a reutilização foi 86 % maior, em
relação à estimativa inicial da Fase de Construção e
3 - A proporção da Fase de Construção foi reduzida, de 58 % para 17%, em relação ao tempo
total do Projeto do CSC P-DTL.
7. Conclusão
Esse artigo apresentou a implementação de um framework baseado em um processo
especialista para identificação, catalogação e reutilização de padrões de projeto para sistema de
tempo real, baseado na (Unified Modeling Language Real Time - UML-RT). A reutilização de
padrões de projeto para desenvolvimento de software embarcado de tempo real utilizou o
Aprendizado Baseada em Problemas (Problem Based Learning - PBL) [CUNHA, 2007] para a
definição da linha pesquisada. O resultado da pesquisa foi a elaboração do processo “W”,
derivado de um processo definido, para a construção de um design patterns.

Segundo o último levantamento do projeto VANT-EC-SAME, foram geradas pela

ferramenta CASE Rational Rose Real Time (RRRT) 15.096 linhas de código em C++,
distribuídos em 56 arquivos, com a utilização de modelagem visual, evidenciando o reuso de
programas, com um mínimo de codificação manual. A utilização de um framework de RRRT
para construção de componentes foi uma atividade planejada e os seus pré-requisitos
conhecidos, definidos e respeitados. A despreocupação com os pré-requisitos de reutilização de
componentes genéricos e design pattern pode representar desperdícios de custo e tempo, ao
longo dos projetos.

A proposição de design pattern necessitou de conhecimentos específicos não só na

modelagem UML-RT. O conhecimento técnico na linguagem de programação escolhida foi
fundamental, pois o desconhecimento impactou no plano de teste, na capacidade de abstração,
na catalogação e na seleção do design pattern na biblioteca. A reutilização do design pattern
IO Manager, no Modelo de Processo “W”, necessitou que os aspectos técnicos fossem

10
respeitados. O domínio dos conceitos de UML-RT como Portas, Classes Estáticas e Dinâmicas
foram fundamentais para a efetividade da operação.

O uso de conceitos como a criação de uma da ficha catalográfica foi fundamental para o
arquivamento e teste do design pattern e para a organização da UML-RT e do Rational Unified
Process - RUP. Os ganhos obtidos foram demonstrados no estudo de caso. O uso de diversas
tecnologias aninhadas em uma linha de produção de software embarcado de tempo real
[MONTINI, 2005] viabilizou economicamente a reutilização do IO Manager no projeto I-
CASE-E.

8. Recomendações e sugestões
Esta pesquisa desenvolveu alternativas para melhorar aspectos de implementação
tecnológica I-CASE-E em Fábricas de Software para maximização de uso de design pattern.
Recomenda-se a reutilização sistemática do conceito de Ficha-Catalográfica, em larga escala
de componentes software. A extensão desses processos e métodos propostos ficam a critério de
grupos de pesquisa interessados no conceito de reutilização de software. Sugere-se a utilização
dos conceitos de Modelo W, design pattern e Ficha-Catalográfica em Linhas de Produção de
Células de Manufatura [MONTINI, 2005] [MONTINI, 2005a] especializadas em ferramentas
I-CASE-E. O modelo “W” deve ser revisitado, refinado e customizado para cada nova Linha
de Produção. Sugere-se ainda que, a aplicação deste Modelo em Fábricas de Software
[MONTINI, 2006a] [MONTINI, 2006b] [MONTINI, 2006c] [MONTINI, 2006d] [MONTINI,
2007] [MONTINI, 2008] vise ganhos de escala na produção de software embarcados e de
tempo real.

9. Agradecimentos
A manutenção de uma infra-estrutura para pesquisa em Engenharia de Software é um
ponto crucial. Institutos e Grupos de Pesquisas como o ITA e o GPES vêm contribuindo para o
avanço de trabalhos especializados. O acompanhamento das tendências atuais, por meio da
aplicação de conceitos de software embarcado de tempo real, representa alternativas para o
preparo e a implementação de novas tecnologias. Projetos pedagógicos envolvendo PBL, bem
como parcerias com empresas do setor de produtivo, como a TCS – Tata Consultancy
Services, mostrados neste artigo, já vêm representando relevantes trocas de experiências
profissionais e acadêmicas no mundo moderno.

10. Referências
[BOOCH,1999] Booch, G., “Object-oriented analysis and design with applications”, Benjamin/Cummings,
1999.
[BUDD, 2002] Budd, T., “An Introduction to Object Oriented Programming”, Addison Wesley 3rd Ed,
2002.
[CHRIS, 1977] Christopher, Alexander. A Pattern Language. Estados Unidos da América: Oxford
University Press, 1977.
[CUNHA, 2007] Cunha, A., “CE-235 Real-time Embedded Systems Lecture Notes”, Brazilian Aeronautics
Institute of Technology – ITA. Disponível em : http://www.ita.br/~cunha, Acesso em:
Dezembro de 2007.
[JACOBSON, 1999] Jacobson, I., and Rumbaugh, J., “The Unified Software Development Process”, Addison
Wesley Logman, 1999.
[GAMMA, 2005] Gamma, E., Helm, R., Johnson, R., Vlissides J, “Design Patterns”, Addison-Wesley,
2005.
[GoF, 1995] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements
of Reusable Object-Oriented Software. 1.ed. Estados Unidos da América: Addison-
Wesley, 1995. ISBN 0201633612.

11
 [MESZAROS, 1996] Meszaros, Gerard and Jim Doble. Metapatterns: A pattern language for pattern writing.
The 3rd Pattern Languages of Programming conference, Monticello, Illinois, September
1996. Disponível em: http://hillside.net/patterns/writing/patternwritingpaper.htm, Acesso
em: Dezembro de 2007.
[MONTINI, 2005] Montini, Denis Ávila, Modelo de indicadores de risco para o orçamento de componentes
de software para célula de manufatura. / Denis Ávila Montini.360p.Dissertação
(Mestrado) em Engenharia de Produção – Universidade Paulista - (2005).
[MONTINI, 2005a] Montini, Denis Ávila; Spinola, Mauro de Mesquita; Sacomano, José Benedito;
Nascimento, Marcos Ribeiro Do; BATTAGLIA, Danilo. Aplicação do Modelo PSP
Manual e amparado por ferramenta CASE em um estudo de caso de Fábrica de Software
Brasileira. Simpósio, Hotel Serra Azul - Gramado, RS, 2005.
[MONTINI, 2006a] Montini, Denis Ávila; Albuquerque, Antonio Roberto Pereira Leite de; Nascimento,
Marcos Ribeiro Do. Strategy for the use of the model of personal software process for the
establishment of measurement and analysis for obtain CMMI level 2 in a study of case of
a brazilian software factory. In: ASEE - 5th ASEE Global Colloquium on Engineering
Education, Rio de Janeiro, 2006.
[MONTINI, 2006b] Montini, B Denis Ávila; Spinola, Mauro de Mesquita; Sacomano, José Benedito;
Nascimento, Marcos Ribeiro do; Battaglia, Danilo. Application of model PSP manual and
supported by tool in a study of case of brazilian plant of software. Revista produção on
line, Florianópolis - SC - Brasil, 2006.
[MONTINI, 2006d] Montini, Denis Ávila; Sekhar, Chandra; Negry, Tatiana Tavares; Nascimento, Marcos;
Battaglia, Danilo. Strategy for the use of the model of personal software process for the
establishment of measurement and analysis for obtain CMMI level 2 in a study of case of
a brazilian software factory. In: Montivideu: TACTICS Iberoamerica 2006.
[MONTINI, 2007] Montini, Denis Ávila; Moreira, Gabriel de Souza; Vieira, Luiz Alberto; Battaglia, Danilo;
Gnatiuc, Carlos Eduardo; Cunha, Adilson Marques da; In: TACTICS Iberoamerica 2007.
Estudo de caso de uma estratégia de integração de middleware para um serviço SOA de
gerenciamento e controle de fábrica de software: TCS – Tata Consultancy Services –
Intranet website de Base de Conhecimento Corportativa KnowMax: TACTICS
Iberoamerica 2007, Brasil, São Paulo, SP 25-26/Outubro/2007.
[MONTINI, 2008] Montini, Denis Ávila; Moreira, Gabriel de Souza; Vieira, Luiz Alberto; Battaglia, Danilo;
Gnatiuc, Carlos Eduardo; Cunha, Adilson Marques da; In: Global TACTiCS 4th Global
Conference, Study of case of a strategy of middleware integration for SOA service of
administration and control of factory of software: TCS – Tata Consultancy Services –
Intranet website Corporative Knowledge Data Base KnowMax: Global TACTiCS 4th
Global Conference, Índia, Kerala, Thiruvananthapuram. 16-19/janeiro/2008.
[OMG, 2007] OMG, “UML”. Dispoível em: http://www.omg.org/gettingstarted/what_is_uml.htm.
Acesso em: Dezembro 2007.
[RADICE, 1988] Radice E Philips, 1988, Special Report CMU/SEI-94-SR-3 - Exemplo de representação de
processo em ETVX – Disponível no sítio WEB em 17/06/2007: www.seicmu.edu/pub/
docments /94.reports/pdf/sr03. 94. pdf
[RATIONAL, 2003] Rational Software Corporation, “DEV470 - Mastering Rational Rose Real Time - Student
Material”, Volume 1, 2003. Disponível em: http://www-
128.ibm.com/com/developerworks/
rational/library/content/03July/1000/1155/_umlmodeling.pdf. Acesso em: Dezembro
2007.
[RATIONAL, 2005] Rational Software Corporation, “Rational Unified Process”. Disponível em: http://www-
128.ibm.com/developerworks/ rational/library/may05/brown/index.html. Acesso em:
Dezembro 2007.
[SELIC, 1994] Seliec, B., Gullekson, G., and Ward, P., “Real-Time Object-Oriented Modeling”, John
Wiley & Sons, 1994.
[SELIC, 2006] Selic, B., and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems”.
Disponível em: http://www-128.ibm. Acesso em: Outubro de 2006.
[TCS, 2006] TCS, Tata Consultancy Services, “Operational Process for Iterative Development (Unified
Process) Version 1.0”, Integrated Quality Management System IQMS, Air India Building
Mumbai, India Outubro de 2006.

12
View publication stats