Sistema de Estacionamento em Linguagem C

Prévia do material em texto

1
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
SISTEMA PARA 
ESTACIONAMENTO DE VEÍCULOS EM LINGUAGEM C
Unip Interativa Três Corações
2014
2
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
SISTEMA PARA 
ESTACIONAMENTO DE VEÍCULOS EM LINGUAGEM C
Curso: Sup. Tec. Em Análise e Desenvolvimento de Sistemas
Semestre: 2º Semestre de 2014
Unip Interativa Três Corações
2014
RESUMO
O Projeto Integrado Multidisciplinar IV do Custo Superior em Tecnologia de Análise e
Desenvolvimento de Sistemas da Universidade Paulista - UNIP, traz o desafio de fazer uma
análise e o desenvolvimento de um sistema para Estacionamento de Veículos utilizando a
linguagem de programação C. Se espera que mesmo se tratando de um projeto acadêmico, onde
existem dificuldades, riscos e incertezas, realizar a entrega de um projeto, de acordo com as
exigências do mercado de trabalho na qual proporcione ao cliente uma ferramenta que consiga
atender às necessidades do mesmo.
3
Palavras-chaves: Sistemas, estacionamento, veículo, linguagem de programação, software.
ABSTRACT 
The Integrated Multidisciplinary Project IV of the Higher Cost Technology Analysis and Systems
Development Universidade Paulista - UNIP, brings the challenge of making an analysis and the
development of a system for parking of vehicles using the C programming language is expected
that even the case of an academic project, where there are difficulties, risks and uncertainties,
make delivery of a project, in accordance with there quirements of the labor market in which the
client provides a tool that can meet the needs of the same.
4
Keywords: systems, parking, vehicle, programming language, software.
SUMÁRIO
1- INTRODUÇÃO ....................................................................................................................... 6
1.1 OBJETIVOS GERAIS ........................................................................................................... 6
1.2 OBJETIVOS ESPECÍFICOS ................................................................................................. 6
2-REFERENCIAL TEÓRICO ..................................................................................................... 7
2.1 LINGUAGEM DE PROGRAMAÇAO .................................................................................. 7
2.2 ENGENHARIA DE SOFTWARE .......................................................................................... 7
5
2.3 MODELOS DE PROCESSOS DE SOFTWARE ................................................................... 8
2.4 METODOLOGIAS ÁGEIS ..................................................................................................... 9
3- CRONOGRAMA ..................................................................................................................... 10
4- COMUNICAÇÃO E ANÁLISE .............................................................................................. 10
5- QUESTIONÁRIO DE REQUISITOS ..................................................................................... 11
6- MODELO DE CONTEXTO .................................................................................................... 11
7- LISTA DE EVENTOS ............................................................................................................. 12
8- DIAGRAMA DE CONTEXTO ............................................................................................... 12
9- MODELO FUNCIONAL ......................................................................................................... 13
10- ATIVIDADES DESENVOLVIDAS ..................................................................................... 15
10.1 DEV. C ++ ............................................................................................................................ 15
10.2 INICIANDO O CÓDIGO ..................................................................................................... 16
10.2.1 CRIANDO O ARQUIVO “MAIN. C” .............................................................................. 20
11- TESTES DE SOFTWARE ..................................................................................................... 21
12- CONCLUSÃO ....................................................................................................................... 25
13- REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................26
1 INTRODUÇÃO
O projeto em questão trata do desenvolvimento de software elaborado, visando à
utilização da linguagem de programação C, a engenharia de software e técnicas de programação
estudadas usando a ferramenta de desenvolvimento DEV C++. 
O sistema conterá uma tabela de tarifação com um determinado valor para a primeira
hora e outro valor somado para as demais horas, registro de entrada e saída de veículos, no
projeto estará incluso uma tela de consulta de vagas no estacionamento caso estiver cheio não
6
haverá como o sistema registrar nova entrada até a saída de um veículo, liberando assim uma
vaga. 
Quando o veículo der saída, o sistema emitirá um recibo com a data e hora de entrada
e de saída junto com o valor a ser pago, somando o valor primeira hora com o valor das demais
horas, quando houver, terá também um controle informativo do fechamento caixa e de todas
movimentações do dia e o saldo do fechamento. 
O uso de software específico para esse fim colaborará para o controle de entrada e
saída de veículos, controle de vagas e do fluxo caixa do estacionamento e para o fechamento do
caixa ao final do dia, assim reduzindo os gastos com recursos materiais e poupando os
funcionários de preenchimento dos documentos manualmente, que poderão usar seus recursos
para impressão do documento definitivo sem rasuras.
1.1 Objetivos Gerais
Fazer a análise e o desenvolvimento de um sistema de Estacionamento de Veículo.
1.2 Objetivos Específicos
 Pesquisar o ramo de estacionamento de veículos para levantamento de processos e
atividades.
 Utilizar o modelo sequencial linear (cascata).
 Aplicar técnicas de Gerenciamento de Projetos para gestão das atividades.
 Elaborar um projeto de software de estacionamento de veículos.
2 REFERENCIAL TEÓRICO
Neste tópico serão apresentadas as disciplinas em estudo para realização do
desenvolvimento do projeto.
2.1 Linguagem de programação C
Foi inventada e implementada por Dennis Ritchie que utilizava o sistema operacional
UNIX. A linguagem C também é conhecida como uma linguagem de médio nível para
computadores por combinar elementos de linguagem de alto nível com funcionalidade da
linguagem assembly. 
7
A Linguagem C permite a manipulação de bits, bytes e endereços (os elementos
básicos com os quais o computador funciona), embora C não seja rigorosamente uma linguagem
estrutura em blocos, mas, normalmente é reconhecida como linguagem estruturada. Uma
linguagem estruturada permite muitas possibilidades na programação, suporta diversas
construções de laços (loops) como while, do-while e for. O principal componente estrutural de C
é a função, que são blocos de construção em que toda a atividade do programa ocorre.
Inicialmente, C era usada na programação de sistema, à medida que C cresceu em
popularidade, muitos programadores começaram a usá-la para programar todas as tarefas.
Existem várias implementações de C, mas para garantir compatibilidade entre estas
implementações foi criado um padrão ANSI para C. ANSI é a abreviatura de American National
Standard Institute, trata-se de um instituto americano que se encarregada formulação de normas
em diversos setores técnicos, incluindo os relativos aos computadores.
2.2 Engenharia de software
O termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO
Science Committee. Sua criação surgiu numa tentativa de contornar a crise do software e dar um
tratamento de engenharia ao desenvolvimento de sistemas de software complexos. 
Tendo como principais objetivos:
a) A qualidade do software;
b) Produtividade no desenvolvimento, operação e manutenção do software;
c) Permitir que os profissionais tivessem controle sobre o desenvolvimento de
software dentro de custos, prazos e níveis de qualidade desejável.
Segundo Friedrich Ludwig Bauer (1969, p. 231), Engenharia de Software é a criação
e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica,
que seja confiável e que trabalhe em máquinas reais. 
PRESSMAN (2002) ressalva que a engenharia de software é uma tecnologia em
camadas (Ferramentas, Métodos, Processo, Foco na qualidade) e a organização devem se apoiar
num compromisso de qualidade.
8
SOMMERVILLE (2003) conceitua Engenharia de Software como uma disciplina da
engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais
de especificação do sistema até sua manutenção, depois que o mesmo entrou em operação.
O próprio significado de engenharia já traz os conceitos de criação, construção,
análise, desenvolvimento e manutenção. A Engenharia de Software se concentra nos aspectos
práticos da produção de um sistema de software.
2.3 Modelos de Processos de Software
Para SOMMERVILLE (2003), um modelo de processo de software é uma descrição
simplificada ou uma representação abstrata de um processo de software, que é apresentada a
partir de uma perspectiva específica.
PRESSMAN (2002) denomina modelos da estrutura dos processos classificando-as
em etapas denominadas ciclos de vida. Os modelos de ciclo de vida do software podem ocorrer
em sequência ou sobrepostas e executadas interativamente, dependendo do modelo adotado para
a construção do software. Podem ser decompostas em unidades menores, como etapas, atividades
ou tarefas, a fim de permitir um maior controle e visibilidade da execução do projeto de software.
Os principais ciclos de vida de software são: modelo codifica-remenda, cascata,
incremental, Rapid Application Development (RAD), evolucionários, prototipagem, espiral e
especializado.
Nosso projeto baseia-se no modelo cascata, que é um modelo de desenvolvimento
bem definido, no qual os processos são executados de forma sequencial. SOMMERVILLE (2003)
cita que os principais estágios do modelo cascata retratam as atividades de desenvolvimento
fundamentais, que são: análise e definição de requisito; projeto de sistemas e de software;
implementação e teste de unidades; integração e teste de sistemas; operação e manutenção.
2.4 Metodologias Ágeis 
Segundo LARMAN (2007) método de desenvolvimento ágil usualmente aplica
desenvolvimento iterativo e evolutivo de tempo limitado, empregam planejamento adaptativo,
9
promovem entrega, incrementam e incluem valores e práticas que encorajam agilidade, resposta
rápida e flexível à modificação.
Os métodos ágeis surgiram na década de 1990 e têm sido apontados como uma
alternativa aos modelos clássicos ou tradicionais para o desenvolvimento de software.
Método ágil de software é um conjunto de atividades, métodos ou processos de
desenvolvimento de software. Outra definição muito comentada seria: o desenvolvimento ágil, tal
como qualquer processo de software tradicional, fornece uma estrutura conceitual e um conjunto
de prática para projetos de software (COSTA, 2013; AMBLER, 2004).
A história dos métodos ágeis se inicia no começo de 2001, quando membros
proeminentes da comunidade de software se reuniram em Snowbird (The Lodgeat Snowbirdski
Resort, Utah) e adotaram o nome método ágeis. 
De acordo com Pressman (2006), nasceu o Manifesto Ágil, documento que reúne os
princípios e as práticas desse paradigma de desenvolvimento.
Entre os principais métodos ágeis estão: Extremme Programming (XP), Scrum,
Iconix, Feature Drive Development (FDD), Adaptative Software Development (ASD), Dynamic
Systems Development Method (DSDM), Crystal, Test Driven Development (TDD) e Modelagem
Ágil (MA).
3 CRONOGRAMA
Atividades Desenvolvidas DATA NUMERO
DE DIAS
Introdução do PIM 24/10/2014 a 27/10/2014 4
Referencial Teórico
28/10/2014 a 03/11/2014
7
Metodologia, Descrição da 
Tecnologia
04/11/2014 a 08/11/2014 5
Levantamento de Requisitos 09/11/2014 a 11/11/2014 3
Revisão Parcial do PIM 12/11/2014 1
10
Desenvolvimento da 
Aplicação (implementação)
09/11/2014 a 16/11/2014 7
Testes e Validação 17/11/2014 1
Revisão Final 17/11/2014 1
4 Comunicação e Análise
A fase de análise consiste em gerar a documentação que será utilizada no momento da
codificação do software. Nesta etapa, serão levantados os requisitos do sistema a ser
desenvolvido bem como o modelo de contexto e o modelo funcional.
Análise de Requisitos: a técnica utilizada para levantamento de requisitos foi a
aplicação de um questionário que contempla os requisitos funcionais e não funcionais do
software a ser desenvolvido. 
Requisitos funcionais: são as funcionalidades que o sistema deve contemplar e que
estão de acordo com as necessidades do cliente.
Requisitos não funcionais: São as características de qualidade que o software precisa
apresentar.
Abaixo está o questionário e as respostas que serão analisadas e irão compor a
estrutura do modelo de contexto e funcional.
5 Questionário de requisitos
a) Quais são os requisitos funcionais do software a ser implementado?
RF01 O software deverá contemplar uma tabela de tarifação com um determinado valor para a
primeira hora e outro valor para as demais horas.
RF02 Emitir um recibo com a data e hora de entrada e a placa do veículo.
RF03 Emitir um recibo com a data e hora de entrada, a data e hora de saída, a placa do veículo e
o valor a ser pago.
RF04 Informar se há vagas disponíveis.
RF05 informar as movimentações diárias.
RF06 informar o saldo do fechamento diário.
11
b) Quais são os requisitos não funcionais do software a ser implementado?
RNF01 Legibilidade
RNF02 Organização e Comentário do Código fonte
RNF03 Acurácia
RNF04 Completude
RNF05 Telas do Programa
RNF06 Linguagem C
RNF07 IDE Dev C++
Com a lista de requisitos e utilizando análise estruturada, será gerada a modelagem do sistema
começando pelo modelo de contexto.
6 Modelo de Contexto
A análise estruturada consiste em sistematizar o processo de especificação de
sistemas bem como obter a visão lógica ou conceitual do software.
Nesta análise, vamos nos concentrar em identificar os elementos básicos que
descrevem o sistema sem nos preocuparmos com implementação. Neste caso as funções,
entidades externas, fluxos de dados e depósito de dados.
O modelo de contexto utiliza-se de dois documentos, a lista de eventos e o diagrama 
de contexto.
7 Lista de Eventos
A tabela abaixo foi construída de acordo com a lista de requisitos:
Estímulo Resposta Evento
Consultar vaga Disponibilidade de
vagas.
Cliente solicita vaga no estacionamento
Carro estacionado Recibo de Entrada Sistema emite recibo de data e hora de entrada e
placa do veiculo
Saída do
estacionamento
Recibo de saída
com valor a ser
pago
Sistema emite recibo de data e hora de saída,
Placa do veículo e valor a ser pago
Pagamento Recibo de saída Cliente efetua pagamento
12
A lista deeventos relaciona os eventos que ocorrem, os estímulos causados pelo
evento no software e as respostas dadas pelo sistema.
8 Diagrama de contexto
Para construirmos o diagrama é necessário identificar as fontes externas, o sistema
que estamos desenvolvendo e o fluxo de dados entre eles.
Para o nosso sistema temos:
1) Entidade Externa: Cliente
2) Fluxo de Dados:
Cliente - Sistema: Pagamento
Sistema – Cliente: Recibo entrada
Sistema – Cliente: Recibo saída e valor a ser pago
3) Sistema: Sistema de Estacionamento
Com essas informações foi gerado o diagrama abaixo:
9 Modelo Funcional
13
Nesta etapa da análise será feito o mapeamento das funções essenciais do sistema e a
partir da lista gerada, o digrama de fluxo de dados.
As funções essenciais são construídas a partir da lista de eventos que estão presentes
no modelo de contexto. As funções essenciais fornecem uma resposta completa para cada evento
presente no modelo de contexto.
Estímulo Resposta Evento Função essencial
Consultar vaga Disponibilidade de 
vagas.
Cliente solicita vaga 
no estacionamento
Mostrar vagas 
disponíveis
Carro estacionado Recibo de Entrada Sistema emite recibo 
de data e hora de 
entrada e placa do 
veiculo
Emitir recibo de 
entrada
Saída do 
estacionamento
Recibo de saída 
com valor a ser 
pago
Sistema emite recibo 
de data e hora de 
saída, Placa do 
veículo e valor a ser 
pago
Emitir recibo de saída 
com valor a ser pago
Pagamento Recibo de saída Cliente efetua 
pagamento
Processar pagamento
Com a lista de funções essenciais, passamos a identificar os depósitos de dados,
locais onde os dados são armazenados e utilizados para atualizar e recuperar funções utilizadas
pelo sistema.
A partir da lista das funções essenciais do sistema, será construído o diagrama de
fluxo de dados (DFD) que nada mais é do que uma representação da interação das funções como
o seu ambiente externo.
14
Simbologia
 Entidade Externa
 Processos
 Depósito de Dados
 Fluxo de Dados
15
O diagrama de fluxo de dados acima contempla o nível 0 e servirá como modelo para
a etapa de codificação do sistema.
10 ATIVIDADES DESENVOLVIDAS
10.1 DEV C++
O programa para controle de estacionamento foi desenvolvido usando a Linguagem C
e implementada usando o compilador gratuito Dev C++. 
O projeto foi dividido em dois arquivos: “main.c” e “genHeader.h”. O primeiro
arquivo contém a implementação do sistema em si e o segundo é um arquivo de cabeçalho com
algumas regras de negócio e funcionalidades desenvolvidas pelo grupo.
Abaixo segue uma tabela com uma breve descrição dos arquivos de cabeçalho (.h)
dos dois arquivos. Os headers possuem funções específicas já previamente programadas para uso
do programador em nível de aplicação.
Arquivo (.h) Descrição
stdio Possui funcionalidades básicas de E/S de um programa.
stdlib Permite o uso de funções para controle de memória, geração de 
números aleatórios, busca em arquivos etc.
windows Permite acesso a macros e funções da Win32 API
time Usada para manipulação do tempo
genHeader Possui as demais headers necessárias para o funcionamento do 
sistema, bem como várias funções implementadas pelo grupo 
para contemplar as regras de negócio do sistema.
10.2 Iniciando o código
Esta etapa foi a codificação das Regras de Negócio da aplicação, que consistiu na
criação do arquivo de cabeçalho “genHeader” (acrônimo de General Header). A ideia deste
arquivo seria de implementar algumas funcionalidades que tornariam a interação com o sistema
mais atraente, como a mudança do esquema de cores do fundo da tela e da fonte, por exemplo. 
 void stSeq(char text[], long tempo) : Apresentar uma string com mudança de cor
- Funciona somente em Ambiente Windows
16
Função para mudar a cor da tela
Além disso, possui algumas funções que se fizeram necessárias tais como: Geração
de um ID para cada veículo:
 int Gera_ID(): Gera um número aleatório para identificação única do registro.
Função Gera ID
Contadores que indicam quantos veículos já estacionaram e quantos estão
estacionados no momento.
17
 int veiculos_Estacionados (cliente cli[], int maxTam): Calcular o total de veiculos
no estacionamento no momento corrente
 int veiculos_Ja_Estacionados (cliente cli[], int maxTam): Calcular o total de
veiculos no estacionamento no momento corrente.
Função de identificação de veículos estacionados e função de identificação de veículo que já estacionou
anteriormente
Outra função criada foi a de calcular o valor a ser pago pelo cliente, de acordo com o
tempo em que ficou estacionado e o valor da hora que será aplicado. 
 float calcValoresTotais (cliente cli[], int id_veic, char str_Placa[], int maxTam,
float vlrUnitHora): Calcular a hora total baseada na diferença entre hora de saída e entrada e
minutos de entrada e saída e retornar o valor total a ser pago, de acordo com o valor unitário
informado como parâmetro de entrada . A busca pelo cliente se dá por duas formas: pelo
id_veiculo (long) ou pela nro_placa (char 8) caso a busca seja pelo id_veiculo, o parâmetro da
placa recebe uma literal (“NONE_VAL”) que indica que não deve realizar a busca pela placa e
sim pelo id_veiculo, caso contrário, o parâmetro para o id_veiculo receberá 0(zero), indicando
assim que a busca se faz pela placa.
18
Cálculo do valor das horas
Também foi criada uma função para limpar o console de forma a não depender do
comando cls.
 void clrsrcW():
19
Função limpa console
Foi utilizada uma estrutura (struct) para melhor descrever em termos de
implementação o cliente/veículo. Segue a estrutura desenvolvida:
//Estrutura de dados que representa um cliente/veiculo
typedef struct {
long id_veiculo; //identificacao numerica do veiculo
long hrEntrada, //hora na qual o cliente estacionou
minEntrada, //minuto no qual o cliente estacionou
hrSaida, //hora na qual saiu o cliente
minSaida, //minuto no qual saiu o cliente
status_veiculo; // 1- Estacionado 0 - Saiu
char nro_placa[9]; //Identificar a placa do veiculo
}cliente;
20
10.2.1 Criando o arquivo “main.c”
Esta segunda etapa consistiu na implementação do arquivo “main.c”, no qual toda a
E/S é realizada e também é enviado dados para as funções contidas no “genHeader.h”. 
Basicamente o sistema consiste em uma série de menus e submenus que auxiliam o
usuário a realizar as operações que fazem parte da Análise de Requisitos, assim sendo, o sistema
realiza a inserção dos valores unitários da primeira hora e da segunda hora, registra entradas e
saídas e calcula o valor a ser pago. 
Para os vários menus e submenus, foram usados vários laços condicionais através do
comando “do {....} while() combinado com comandos “switch” para tratar cada processo
necessário para o funcionamento do sistema. Para percorrer os registros, foram utilizados laços de
repetição com flags para paradas. Estes flags se fazem necessários para que exista um critério de
parada, caso o registro a ser buscado seja encontrado, de modo a não percorrer todo o vetor que
contém os registros.
Para armazenar em tempo de execução os registros, foi criado um vetor do tipo
cliente, que é uma estrutura que é composta por variáveis que são necessárias e que se encontram
descritas anteriormente na 1ª Etapa, o limite deste vetor se baseia na capacidade máxima do
estacionamento, sendo este valor alimentado na variável “maxCapac” logo no início da execução
do programa.
O sistema possui uma listagem dos veículosque estão estacionados e dos que saíram,
bastando acessar as opções relativas a entradas ou saídas, respectivamente. Para esta listagem
foram usados laços de repetição.
Parte do código fonte do arquivo main.c
11 Testes de software 
21
A técnica utilizada para testar o software foi a funcional. Esta técnica consiste em
verificar se os requisitos levantados na análise funcionam conforme especificado. Também
conhecida como teste de caixa preta, e feito a inserção de dados e o esperado é que na saída,
tenhamos os resultados de como foi projetado os requisitos. De acordo com a fase de análise
abaixo estão elencados os requisitos para que possamos iniciar os testes.
RF01 O software deverá contemplar uma tabela de tarifação com um determinado
valor para a primeira hora e outro valor para as demais horas.
Dados inseridos:
Valor da Primeira Hora: 3.00
Valor das demais Horas: 1.00
Ao inserir os dados acima o sistema mostra a tabela de tarifação como mostra a figura abaixo.
RF02 Emitir um recibo com a data e hora de entrada e a placa do veículo.
Dados inseridos:
Placa do Veiculo: AAA-2222
Hora de entrada: 12
Minuto de entrada: 30
22
Ao inserir os dados acima o sistema mostra o recibo de entrada como mostra a figura abaixo.
RF03 Emitir um recibo com a data e hora de entrada, a data e hora de saída, a placa 
do veículo e o valor a ser pago.
Dados inseridos:
Placa do Veículo: AAA-2222
Hora de saída: 15
Minuto de entrada: 40
23
Ao inserir os dados acima o sistema mostra o recibo de saída e o valor a ser pago como mostra a 
figura abaixo.
RF04 Informar se há vagas disponíveis.
No menu de registros de entrada e saída, é possível verificar a quantidade de carros
estacionados e as saídas. Sabendo a quantidade de carros estacionados, é possível saber o número
de vagas disponíveis.
RF05 informar as movimentações diárias.
Selecionando o menu entrada/saída de clientes temos as opções registrar entrada e
saída de veículos. Dentro das opções é possível ver todos os registros de entrada do dia e saída.
RF06 informar o saldo do fechamento diário.
24
Ao selecionar o item fluxo de caixa na tela inicial, podemos verificar o saldo inicial e
o saldo atual do caixa conforme tela abaixo:
Feito o código fonte do arquivo main.c, juntamente com o código fonte do arquivo
genHeader.h chegou-se ao fim do projeto sistema de estacionamento.
25
12 CONCLUSÃO
O desenvolvimento de sistemas utilizando os princípios da engenharia de software mostra
um panorama de todas as etapas do projeto, permitindo a inserção de pontos de controle onde é
necessário, melhorando a qualidade do que se está projetando. O ciclo de vida cascata auxilia
planejar, fazer a análise, codificar e testar o software. As técnicas de programação auxiliam na
etapa de análise para visualização da lógica das funções antes mesmo da codificação, garantindo
assim um refinamento no funcionamento do sistema e alinhado ao mesmo como os requisitos
para o seu desenvolvimento.
26
13 REFERÊNCIAS BIBLIOGRÁFICAS
1. Martin, James & Odell, James J. Análise e Projeto Orientados a Objetos: Markon Books 1995.
2. PRESSMAN, R. S. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2002.
3. SOMMERVILLE, I. Engenharia de Software. Addison Wesley, 2003.
4. Meyer, Bertrand Pbject-Oriented Software Construction 2ª edição: Prentic Hall PTR 1997.
5. Qualidade Software Seleção de Textos: Ana Regina Cavalcanti da Rocha & Kival Chaves
Weber 1996.
6. Rezende, Denis Alcides Engenharia de Software Empresarial: Brasport 1997.
7. Martin, James Engenharia da Informação: Campus; 1991.
8. Kleppe, Anneke & Warmer, Jos & Bast, Wim MDA Explained – The Model Driven
Architecture: Practice and Promise: Addison-Wesley 2003
9. Pressman, Roger S. Engenharia de Software 5ª edição: McGraw-Hill 2002.
10. KETIS, D. Terceirizando a documentação de sistemas. Developers’ CIO Magazine: 1999.
11. Miller, Joaquin & Mukerji, Jishnu Model Driven Architecture (MDA): 2001
12. Miller, Joaquin & Mukerji, Jishnu MDA Guide Version 1.0.1: 2003
13. Costa, Marco Arquitectura de Sistemas de Informação em UML.
14. Siegel, Jon & OMG Staff Strategy Group Developing in OMG’s Model- Driven Architecture:
2001.
15. Common Warehouse Metamodel (CWM) Specification: 2001
16. Meta Object Facility (MOF) Specification: 2000
17. Chaves, Rafael Alves Aspectos e MDA Criando modelos executáveis baseados em aspectos:
2004
18. http://www.starlink.rl.ac.uk/star/docs/sgp42.htx/node25.html
19. http://www.telehealthlab.com/about/inter.asp
20. http://www-vis.lbl.gov/Events/DOEworkshop-98/document.html
21. http://www.pr.gov.br/batebyte/edicoes/2002/bb123/armazenamento.htm
22. http://www.omg.org
23. http://www.componentsource.com
24. http://www.compuware.pt/pressroom/news/2003/2003040801.htm
27
25. http://www.compuware.com/products/optimalj/default.htm
26. http://www.itweb.com.br/itlab/artigo.asp?id=41448
27. http://www.andromda.org
28. http://www-306.ibm.com/software/rational
	11 Testes de software