UML

Prévia do material em texto

UNIVAP - UNIVERSIDADE DO VALE DO PARAÍBA 
FCC – Faculdade de Ciência da Computação 
Curso de Ciência da Computação 
 
 
 
 
 
 
 
 
 
 
 
ESTUDO DA LINGUAGEM UML APLICADO A UM 
SISTEMA DE COMÉRCIO ELETRÔNICO 
 
 
 
 
 
 
 
 
 
 
Kelly Cristina Noguti 
Patrícia Rezende Roxael 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
São José dos Campos – SP, Dezembro de 2004 
Relatório de Trabalho de Conclusão de Curso Apresentado à Faculdade de Ciência da 
Computação da Universidade do Vale do Paraíba como parte dos requisitos para obtenção 
do Título de Bacharel em Ciência da Computação. 
 
 
 
 
 
ESTUDO DA LINGUAGEM UML APLICADO A UM 
SISTEMA DE COMÉRCIO ELETRÔNICO 
 
 
 
 
 
 
 
Kelly Cristina Noguti 
Patrícia Rezende Roxael 
 
 
 
 
 
Relatório aprovado em versão final pelos abaixo assinados: 
 
 
 
 
_____________________________ 
Prof. Dr. Lineu F. Stege Mialaret 
Orientador Acadêmico 
 
 
 
 
 
____________________________ 
Prof. Dr. Márcio Magini 
Coordenador da Disciplina de TCC 
 
 
 
 
 
São José dos Campos – SP, Dezembro de 2004 
Agradecimentos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Agradecemos aos nossos professores, 
amigos e colegas e em especial aos 
nossos familiares que quando tudo 
parecia difícil sempre tiveram uma 
palavra e uma atitude de apoio. 
 
Dedicatória 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dedicamos este trabalho a todos os 
nossos familiares por todos esses anos 
de apoio e em especial aos nossos pais 
que muitas vezes renunciaram aos seus 
sonhos para que os nossos pudessem ser 
realizados. 
Sumário 
 
Índice de Figuras................................................................................. ..................................i 
Índice de Tabelas............................................................................................................ ......ii 
Lista de Símbolos, Acrogramas e Abreviações........................................... ........................iii 
Resumo....................................................................................................................... .........iv 
 
1 Introdução........................................................................................................................5 
1.1 UML e Orientação a Objetos.....................................................................................5 
1.2 Definição do Problema............................................................................. .................6 
1.3 Solução Adotada........................................................................................................6 
1.4 Estrutura do Documento............................................................................................6 
2 Introdução a UML.......................................................................................................... .7 
 2.1 UML – Unifield Modeling Language........................................................................7 
 2.2 Objetivos da UML.....................................................................................................8 
 2.3 Utilização da UML....................................................................................................9 
 2.4 Desenvolvimento de Software Orientado a Objeto...................................................9 
 2.5 Vantagens da Orientação a Objeto...........................................................................10 
 2.6 Linguagem de Programação Orientada a Objeto.....................................................10 
 2.7 Visões de Sistema....................................................................................................11 
 2.7.1 Visão use-case.................................................................................................12 
 2.7.2 Visão Lógica...................................................................................................12 
 2.7.3 Visão de Componente............................ .........................................................12 
 2.7.4 Visão de Concorrência....................................................................................12 
 2.7.5 Visão de Organização.................................... .................................................13 
 2.8 Modelagem de Dados.............................................................................................13 
 2.9 Orientação a Objeto................................................................................................13 
 2.10 Análise e Projeto Orientado a Objeto...................................................................14 
 2.10.1 Projeto..........................................................................................................15 
 2.11 Programação Orientada a Objeto..........................................................................16 
 2.11.1 Classes.........................................................................................................16 
 2.11.2 Objetos.........................................................................................................17 
 2.11.3 Pacotes.........................................................................................................17 
 2.11.4 Um processo para utilizar UML..................................................................18 
 2.11.5 Fases de Desenvolvimento de um Sistema em UML..................................19 
 2.11.6 O Futuro da UML........................................................................................20 
3 Diagramas.................................................................................................................. .....21 
 3.1 Diagramas em UML................................................................................................21 
 3.2 Diagrama de Caso de Uso........................................................................................21 
 3.3 Diagrama de Interação.............................................................................................22 
 3.4 Diagrama de Seqüência...........................................................................................22 
 3.5 Diagrama de Colaboração........................................................................................22 
 3.6 Diagrama de Classe..................................................................................................22 
 3.7 Diagrama de Estado.................................................................................................23 
 3.8 Diagrama de Atividade............................................................................................23 
 3.9 Diagrama de Componente.......................................................................................23 
 3.10 Diagrama de Execução..........................................................................................24 
 3.11 Relacionamentos................. ...................................................................................24 
4 Ferramentas Case........................................................................................................... .25 
 4.1 Conceito....................................................................................................................25 
 4.2 Vantagens................................................................................................................ ..25 
5 Ferramenta Utilizada.......................................................................................................265.1 System Architect.......................................................................................................26 
 5.2 Análise e Projeto no System Architect.....................................................................27 
 5.3 System Architect e Engenharia de Software.............................................................27 
 5.4 Desenvolvimento em Equipe......................... ...........................................................28 
 5.5 Reutilização............................................................................................................. ..28 
 5.6 Interface com o usuário............................... ..............................................................28 
6 Introdução a Linguagem ASP.........................................................................................30 
 6.1 ASP............................................................ ...............................................................30 
 6.2 Aplicações de Cliente- Servidor...............................................................................30 
 6.3 Pré- Requisitos para funcionamento de uma página em ASP........ ...........................31 
 6.4 Os forms e ASP.........................................................................................................31 
 6.5 Os parâmetros da Tag Form......................................................................................31 
 6.6 Rotinas de Script.......................................................................................................3 2 
 6.7 Visual Basic Script....................................................................................................32 
 6.8 Java Script.............................................................................................................. ...33 
 6.9 ODBC Open DataBase Connectivity......................................................... ...............33 
 6.10 Desenvolvendo Aplicações Web............................................................................34 
 6.11 ADO ActiveXDataObject.......................................................................................35 
7 Modelagem do Protótipo................................................................................................37 
 7.1 Protótipo................................................................................................................ ...37 
 7.2 Análise de Requisitos...............................................................................................38 
 7.3 Requisitos do usuário................................................................................................38 
 7.4 Requisitos de software..............................................................................................39 
 7.5 Casos de Uso............................................................................................................. 41 
 7.6 Diagrama de Classe...................................................................................................44 
 7.7 Diagrama de Componente.........................................................................................45 
 7.8 Diagrama de Estado..................................................................................................46 
 7.9 Diagrama de Atividade.............................................................................................48 
 7.10 Diagrama de Colaboração......................................................................................49 
 7.11 Projeto................................................................................................................. ...49 
 7.11.1 Programação.................................................................................................50 
 7.11.2 Testes...........................................................................................................50 
 7.12 Banco de Dados de Desenvolvimento....................................................................50 
 7.13 Comunicação de Dados...........................................................................................51 
8 Desenvolvimento do Sistema.......... ................................................................................54 
 8.1 Music Online............................................................................................................. 54 
 8.2 Módulos do Sistema..................................................................................................55 
 8.3 Interface do Sistema..................................................................................................55 
9 Conclusão........................................................................................................................60 
Referências Bibliográficas.................................................................................................61 
 
 
Índice de Figuras 
 
 
Figura 2.1 – Contribuições para a UML.................................................................................7 
Figura 2.2 – Visões de Sistema.............................................................................................12 
Figura 2.3 – Programação OO é o encapsulamento de dados e funções..............................13 
Figura 2.4 - Objetos reúnem dados e funções.......................................................................14 
Figura 2.5 – Investigação e analise do problema..................................................................15 
Figura 2.6 – Projeto e Solução..............................................................................................15 
Figura 2.7 – Representação de uma classe em UML................................... .........................16 
Figura 2.8 – Representação de objeto em UML...................................................................17 
Figura 2.9 – Representação de pacote de acordo com a UML.............................................18 
Figura 3.1 – Tipos de diagramas em UML...........................................................................21 
Figura 3.2 – Diagrama de caso de uso..................................................................................22 
Figura 5.1 – Ferramenta System Architect...........................................................................27 
Figura 5.2 – System Architect..............................................................................................29 
Figura 6.1 – Como funciona uma página em ASP................................................................32 
Figura 6.2 – Banco de Dados ODBC....................................................................................34 
Figura 6.3 – ActiveXDataObject...................................... ....................................................35 
Figura 6.4 – Acessando Banco de Dados..............................................................................36 
Figura 7.1 – Caso de Uso do Cliente................................................ ....................................42 
Figura 7.2 – Caso de Uso do Administrador........................................................................43 
Figura 7.3 – Diagrama de Classe...................................................................... ....................45 
Figura 7.4 – Diagrama de Componente................................................................................46 
Figura 7.5 – Diagrama de Estado.................................................................................... ......47 
Figura 7.6 – Diagrama de Atividade.....................................................................................48 
Figura 7.7 – Diagrama de Colaboração...............................................................................49 
Figura 7.8 – Software de um servidorde comércio eletrônico.............................................51 
Figura 7.9 – Esquema de compras........................................................................................52 
Figura 8.1 – Tela principal do sistema..................................................................................56 
Figura 8.2 – Carrinho de compras........................................................................................57 
Figura 8.3 – Cadastro de Cliente...........................................................................................58 
Figura 8.4 – Login do usuário...............................................................................................59 
 
 
 
 
 
 
 
 
 
 
 
 
 
Índice de Tabelas 
 
Tabela 7.1 – Tabela de Comparação.................................................................................41 
Tabela 7.2 – Tabela de Descrição do Caso de Uso...........................................................43 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Lista de Símbolos, Acrogramas e Abreviações 
 
 
UML Unifield Modeling Language 
SA System Architect 
ASP Active Server Pages 
SQL Structured Query Language 
HTML Hyper Text Markup Language 
CASE Computer Aided Software Engineering 
OO Orientação a Objeto 
POO Programação Orientada a Objeto 
OMT Object Modeling Technique 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Resumo 
 
Este relatório propõe o estudo da linguagem UML – Unifield Modeling Language, e 
a implementação de um sistema de comércio eletrônico a fim de verificar a aplicabilidade e 
as vantagens do uso desta linguagem, para que se possa criar uma metodologia de 
desenvolvimento de sistema que englobe todas as fases do processo, obtendo os requisitos 
do usuário, requisitos de software e o projeto detalhado. O protótipo será implementado 
utilizando as ferramentas System Architect para modelagem em UML e a linguagem ASP 
para desenvolvimento do sistema de comércio eletrônico. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 1 
 
 
Introdução 
 
1.1 UML e Orientação à Objetos 
 
A complexidade crescente dos projetos de software, como o de sistema de comércio 
eletrônico e a necessidade de ferramentas rápidas para desenvolvê -los requerem novos 
métodos de análise e modelagem. Por isso, a UML vem para oferecer um conjunto de 
métodos e ferramentas para desenvolvimento desses sistemas complexos, pois sendo um 
sistema de comércio eletrônico a sua aplicação é em tempo real, isto é, a relação entre o 
cliente e o sistema, o cliente com um pedido de compra e o sistema com geração do 
produto. Tudo isso precisa ser mostrado para um melhor entendimento e análise do sistema 
por qualquer desenvolvedor. 
Um grande problema no desenvolvimento de novos sistemas utilizando a orientação 
a objetos era o fato de não existir uma notação padronizada e realmente eficaz que pudesse 
abranger qualquer tipo de aplicação. 
Cada metodologia possuía suas próprias notações ( símbolos usados para projetar 
modelos orientados a objetos) , processos e ferramentas. Isso fazia com que a escolha do 
método a ser utilizado se tornasse uma decisão extremamente importante levando a 
discussões e debates sobre qual método usar. 
A UML desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson é a 
padronização dessas metodologias de desenvolvimento de sistemas baseados na orientação 
a objetos. A UML incorpora as noções do desenvolvimento de software totalmente visual, 
baseando-se em diagramas que são modelados e classificados em visões de abstração. 
O desenvolvimento de sistemas de software são suportados por métodos de análise e 
projeto que modelam esse sistema de modo a fornecer para toda a equipe envolvida 
(cliente, analista, programador, etc) uma compreensão única no sistema. 
 
 
 
 
 
1.2 Definição do Problema 
Neste trabalho, definiu-se o problema identificado em “Como desenvolver um 
Sistema de Comércio Eletrônico utilizando uma ferramenta que implemente a linguagem 
UML a fim de exemplificar e avaliar a aplicabilidade e as vantagens dessa linguagem. 
 
1.3 Solução Adotada 
 
Adotou-se como solução o uso da ferramenta System Architect, que dentre uma de 
suas características permite gerar classes e atributos a partir de diagramas, oferecendo 
suporte para diversas metodologias e ambientes de desenvolvimento. 
 
 
1.4 Estrutura do Documento 
 
Este documento está organizado da seguinte forma: 
No Capítulo 2 são introduzidos conceitos sobre a linguagem UML e o paradigma de 
Orientação a Objetos. 
No Capítulo 3 é apresentado o desenvolvimento dos diagramas em UML e as suas 
funcionalidades. 
No Capítulo 4 é são introduzidos conceitos básicos sobre Ferramentas Case. 
No Capítulo 5 apresenta as ferramentas utilizadas no desenvolvimento do sistema. 
No Capítulo 6 é apresentado uma introdução a Linguagem ASP. 
No Capítulo 7 é apresentado a modelagem do protótipo. 
No Capítulo 8 é apresentado o desenvolvimento do sistema. 
No Capítulo 9 é apresentado a conclusão do trabalho. 
 
 
 
 
 
 
 
Capítulo 2 
 
 
Introdução à UML 
 
2.1 UML – Unifield Modeling Language 
 
A UML – Unified Modeling Language desenvolvida por Grady Booch, James 
Rumbaugh e Ivar Jacobson é a padronização de metodologias de desenvolvimento de 
sistemas baseados na orientação a objetos. A UML incorpora as noções do 
desenvolvimento de software totalmente visual. Ela se baseia em diagramas que são 
modelados e classificados em visões de abstração. 
O desenvolvimento de sistemas de software são suportados por m étodos de análise e 
projeto que modelam esse sistema de modo a fornecer para toda a equipe envolvida ( 
cliente, analista, programador, etc) uma compreensão única do projeto. 
A figura 2.1 ilustra as contribuições de vários métodos para a UML 
 
Figura 2.1 – Contribuições para a UML 
 
 
2.2 Objetivos da UML 
 
A UML é uma tentativa de padronizar a modelagem orientada a objetos de uma 
forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente , com 
consistência fácil de se comunicar com outras aplicações, simples de ser atualizado e 
compreensível. 
Os objetivos da UML são: 
 Fornecer uma linguagem visual concisa para a modelagem, visando a implementação de 
um padrão para representar modelos de negócios, suportando uma linguage m de 
modelagem padrão que possa ser usada amplamente para modelagem de negócios. Uma 
linguagem de modelagem visual apresenta três benefícios principais: 
1) Visualização: permite antever o produto final, utilizando relacionamentos existentes 
entre os diversos componentes da aplicação; 
2) Gerenciamento de complexidade: permite estudar e compreender a estrutura do 
sistema, bem como identificar as oportunidades de reutilização de componentes, 
cada aspecto do sistema é projetado a parte e representado utilizando um mo delo 
específico; 
3) Comunicação: utilização de símbolos padrões, tornando-se possível uma 
comunicação direta entre os participantes do projeto, com relação aos detalhes de 
comportamento do sistema; 
 Estabelecer uma união fazendo com que métodos conceituais se jam também 
executáveis ; 
 Criar uma linguagem de modelagem utilizada pelo homem e a máquina ; 
 Fornecer mecanismos de extensibilidade e de especialização para apoiar conceitos 
essenciais, adaptando-se conforme as necessidades que venham a tona para domínios 
específicos, não exigindo que conceitos essenciais comuns sejam redefinidos ou 
reimplantados para cada área individualmente. Assim, os mecanismos de extensão vão 
apoiar divergências do caso comum em ligar de ser exigida implementação de novos 
conceitos essenciais; 
 Prover uma base formal para entender a linguagem de modelagem, fornecer uma 
definiçãoformal do formato estático do m odelo, usando um metamodelo de diagramas 
de classes; 
O objetivo da UML é descrever qualquer tipo de sistema em termos de diagramas 
orientados a objetos. O uso mais comum é para criar modelos de sistemas de software 
usada para representar sistemas mecânicos sem nenhum software como: 
a) sistemas de informação; 
b) sistemas técnicos; 
c) sistemas de tempo real integrados; 
d) sistemas distribuídos; 
e) sistemas de software e 
f) sistemas de negócios; 
 
2.3 Utilização da UML 
 
A UML pode ser usada para: 
- mostrar as principais funções e fronteiras de um sistema utilizando atores e casos de 
uso; 
- ilustrar a realização de casos de uso com diagramas de iteração; 
- representar uma estrutura estática de um sistema utilizando diagramas de estado; 
- revelar a arquitetura de implementação física com diagramas de comportamento; 
- estender sua funcionalidade através de estereótipos; 
 
2.4 Desenvolvimento de Software Orientado a Objeto 
 
O conceito de orientação a objetos já vem sido discutido há muito tempo, desde o 
lançamento da primeira linguagem orientada a objetos, a Simula. Desde então surgiram 
várias metodologias orientadas a objetos, sendo que cada uma delas possuía seus próprios 
conceitos, gráficos e metodologias. 
Algumas informações sobre OO: 
 A orientação a objetos é uma tecnologia para produção de modelos que especifiquem o 
domínio do problema do sistema; 
 Sistema orientados a objetos são flexíveis à mudanças, possuem estruturas bem 
conhecidas e provêm a oportunidade de criar e implementar componentes totalmente 
reutilizáveis; 
 Modelos orientados a objetos são implementados utilizando uma linguagem de 
programação orientada a objetos. A Engenharia de software é muito mais que utilizar 
mecanismos de sua linguagem de programação, é saber utilizar, todas as técnicas da 
modelagem orientada a objetos. 
 A orientação a objetos requer um método que integre o processo de desenvolvimento e 
a linguagem de modelagem com a construção de técnicas e fe rramentas adequadas. 
 
2.5 Vantagens da Orientação a Objeto 
 
Algumas vantagens em utilizar orientação à objetos: 
- O uso de objetos na modelagem torna mais fácil descrever as estruturas e o 
comportamento existente no mundo real. Essa proximidade faz com que clien tes 
possam ser identificados mais diretamente com os problemas nos modelos. 
- O encapsulamento do conhecimento em componentes isola o comportamento, o que 
permite que as alterações nos requisitos estando isoladas não afetem o sistema. 
- O encapsulamento permite ainda que os com ponentes possam ser desenvolvidos por 
fornecedores diferentes. 
- A reutilização do encapsulamento no desenvolvimento do software reduz custos e 
prazos permitindo que o mesmo seja implementado em outros projetos. 
 
2.6 Linguagem de Programação Orientada a Objeto 
 
Em geral, uma linguagem deve possuir quatro elementos para suportar a 
programação orientada à objetos: 
- Proteção de dados: essa característica é importante afim de assegurar a confiabilidade e 
capacidade de modificação de um sistema. O estado de um módulo deve estar contido 
em vários locais visíveis somente no escopo, e os dados manipulados por um conjunto 
de procedimentos. 
- Abstração de dados: mecanismo que utiliza a proteção de dados. O desenvolvedor 
define o tipo consistindo de uma representação interna junto com um conjunto de 
procedimentos para acessar o dado. Tanto a proteção quanto a abstração aumentam a 
confiabilidade e facilitam a separação de procedimentos e representação; 
- Coesão dinâmica: é o processo em que o m ódulo chamador re cebe o endereço de uma 
rotina e associa uma mensagem ao objeto com os métodos para executar a mensagem; 
- Hereditariedade: é uma maneira de reaproveitar classes. A herança permite com que 
criemos uma classe tomando outra como base reutilizando campos e métodos não - 
privados da classe –base. O mecanismo de herança é o mais apropriado para criar 
relações é-um-tipo-de entre classes. Na hierarquia, a classe superior é chamada de 
superclasse enquanto a subordinada é denominada de subclasse. 
 
2.7 Visões de Sistema 
 
O desenvolvimento de sistemas complexos de software requer, para visualização 
das tarefas várias perspectivas. Cada equipe de trabalho (analistas, programadores, 
escritores, técnicos) e usuário final, observa o sistema de uma maneira diferente durante o 
processo de desenvolvimento, podendo trazer suas próprias contribuições ao projeto. 
Um sistema é composto por diversos aspectos: funcional que é a sua estrutura 
estática e suas interações dinâmicas e não funcional que são requisitos de tempo, 
confiabilidade e desenvolvimento e aspectos organizacionais como organização do trabalho 
e mapeamento dos módulos de código. 
Cada visão é descrita por um número de diagramas que contém informações que 
dão ênfase aos aspectos particulares do sistema. Existe em alguns c asos uma certa 
sobreposição entre os diagramas, podendo uma visão fazer parte de uma ou mais visões. 
 A figura 2.2 apresenta as cinco visões de sistemas. [2] 
 
 
 
Visão de Componentes
Visão de Use-case
Visão Lógica
Visão de Organização Visão de Concorrência
 
Figura 2.2 - Visões de Sistema 
 
2.7.1 Visão Use-Case 
 
Descreve a funcionalidade do sistema desempenhada pelo atores externos do 
sistema (usuários). A visão Use-Case é central, já que seu conteúdo é base do 
desenvolvimento das outras visões do sistema. 
 
 
2.7.2 Visão Lógica 
 
 A visão lógica observa e estuda o sistema internamente, é feita principalmente pelos 
analistas e desenvolvedores. Descreve como a funcionalidade do sistema será 
implementada e especifica a estrutura estática do sistema (classes, objetos e 
relacionamentos). 
 
2.7.3 Visão de Componentes 
É a descrição da implementação dos módulos e suas dependências, é principalmente 
executado por desenvolvedores, e consiste nos componentes do diagrama. 
 
2.7.4 Visão de Concorrência 
A visão de concorrência trata a divisão do sistema em processos e processadores, é 
suportada pelos diagramas dinâmicos, que são os diagramas de estado, seqüência, 
colaboração e atividade, e pelos diagramas de im plementação, que são os diagramas de 
componente e execução. 
 
2.7.5 Visão de Organização 
Mostra a organização física do sistema, os computadores, os periféricos e como eles 
se conectam entre si, esta visão será representada pelo diagrama de execução. 
 
2.8 Modelagem de Dados 
O destaque é voltado para estrutura da informação que é tratada pelo sistema. O 
princípio dessa modelagem é que o sistema de informações processa a informação. Dá-se 
maior ênfase em qual informação é processada. 
A figura 2.3 ilustra que a programação orientada à objetos é o encapsulamento de 
dados e funções. 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 2.3 – Programação OO é o encapsulamento de dados e funções 
 
2.9 Orientação a Objetos 
Enfoca a busca da estrutura do problema do problema e não apenas a informação. 
Identifica em objetos, os elementos importantes do domínio do problema, que guardam 
dados e possuem funções que podem operar seus dados. A maior importância é encontrar 
os elementos do problema que possuem todas essas propriedades. 
 A figura 2.4 ilustra que objetos reúnem dados e funções. 
 
 
 
Funções 
Funções 
Funções 
Dados 
Dados 
 
 
 
 
 
 x 
 
 objeto 
 
 . 
 
 
 f(x) 
 
 
 Figura 2.4 – Objetos reúnem dados e funções 
 
2.10 Análise e Projetos Orientados a Objeto 
Nas décadas de 50 e 60 com enormes computadores e pouca capacidade de 
processamento, desenvolvedores tinham que aproveitar ao máximo todo o bit que o 
hardware disponibilizava. Já na década seguinte computadores transistores foram surgindo 
utilizando agora válvulas. 
Precursores da análise orientada àobjeto defendiam que programas de computador 
deveriam ser estruturados de acordo com o problema a ser resolvido. O termo orientação à 
objeto sugere abstrações do mundo real e trechos de programas de computadores ou objeto. 
Um grande fator da orientação à objetos é a reusabilidade. As técnicas de orientação 
à objetos nos permitem reutilizar códigos, reutilizar requisitos, interface de us uário e 
arquitetura, ou seja, todos os componentes de engenharia de software. 
Analisar é obter as necessidades de um sistema e o que este precisa para satisfazer 
as necessidades do usuário. Analisar não é definir como o sistema será desenvolvido, mas 
sim investigar o problema. 
A análise orientada à objetos tem dois propósitos. O primeiro é formalizar uma 
visão do mundo real dentro do sistema a ser desenvolvido, estabelecendo os objetos que 
serão as principais estruturas do sistema. Em segundo, formalizar um conjunto de objetos 
na execução do sistema que está sendo especificado, conforme ilustra a figura 2.5. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 2.5 – Investigação e análise do problema 
 
2.10.1 Projeto 
O projeto orientado a objeto é visto como processo de especificações das partes, ou 
seja, instruções, regras, recomendações, etc. Utilizamos estes processos para implementar o 
sistema em um ambiente específico, para obter a solução do problema , conforme mostra a 
figura 2.6. 
 
 
 
 
 
 
 
 
 
 
 Figura 2.6 - Projeto e solução 
 
Durante o projeto é dado ênfase na elaboração dos elementos lógicos [Larman, 
2000]. Sendo implementados em uma linguagem de programação orientada a objeto s, que 
possuem atributos e métodos. 
 
 
 
Análise 
Investigação do 
problema 
Projeto 
Solução do 
problema 
 
2.11 Programação Orientada a Objetos 
Programação orientada à objetos ou POO é um paradigma de programação de 
computadores onde se usam classes e objetos, para representar e processar dados usando 
programas de computadores. 
 
2.11.1 Classes 
Uma classe é a descrição de um tipo e objeto, onde descreve as propriedades e 
comportamentos daquele objeto. Todos os objetos são instâncias de classes. 
No sistema de software, existem classes que representam entidades de software num 
sistema operacional como arquivos, programas executáveis e janelas. 
Em UML as classes são representadas por um retângulo dividida em três partes: 
nome, atributo e métodos. 
Atributo: é dado lógico de um objeto de domínio, representa alguma propriedade do 
item que está sendo modelado. 
Métodos: são implementados para cumprir responsabilidades solicitadas por 
qualquer objeto. A figura 2.7 representa uma classe de acordo c om a UML. 
 
Nome da classe 
 
 
 Atributos 
 
 Métodos 
 
 
 
 
 
 Figura 2.7 – representação de uma classe em UML 
 
 
 
Cliente 
-nome 
-Endereço 
-RG 
-Comprar 
-Pagar 
 
2.11.2 Objetos 
 
Um objeto ou instância é uma materialização da classe e assim pode ser usado para 
representar dados e executar operações. Para que os objetos ou instâncias possam ser 
manipulados é necessária a criação de referências a estes objetos, que são as variáveis do 
tipo das classes. A figura 2.8 ilustra a representação de objeto de acordo com a UML. 
 
 
 
Personalizado: Tipo_CD 
ID_CD: 
Nome: 
ID_Musico: 
ID_Gravadora: 
ID_Estilo 
 
Montar(); 
Gravar(): 
 
 
 Figura 2.8 – Representação de objeto em UML 
 
 
2.11.3 Pacotes 
Os pacotes são agrupamentos de classes, com o qual podemos criar grupos de 
classes que mantém uma relação entre si. 
Os pacotes são utilizados para organizar os elementos de modelagem em conjuntos 
maiores que possam ser manipulados como grupos. 
Cada pacote pode conter classes, interfaces, componentes, casos de uso e até mesmo 
outros pacotes. Caso ele for destruído tudo o que estiver contido nele também será 
destruído. 
A figura 2.9 representa um exemplo de pacote, já que ele é representado como uma 
pasta. 
 
 
. 
 
 
 
 
 
 
 
 
 
 
 Figura 2.9 – Representação de pacote de acordo com a UML 
 
2.11.4 Um processo para utilizar UML 
 
 A UML contém notações e regras que tornam possível expressar modelos 
orientados à objetos, mas não prescreve como o trabalho tem que ser feito, ou seja, não 
possui um processo de como o trabalho tem que ser desenvolvido. 
 Para usar a UML com sucesso é necessário adotar algum tipo de método de 
desenvolvimento, especialmente em sistema de grande porte onde a organização de tarefas 
é essencial. A utilização de um processo de desenvolvimento torna mais eficiente calcular o 
progresso do projeto, controlar e melhorar o trabalho. 
 Um processo de desenvolvimento descreve “o que fazer”, “como fazer”, “quando 
fazer”, e “porque deve ser feito”. Este também descreve um número de atividades que 
devem ser executadas em uma certa ordem. Quando são definidas e relacionadas as 
atividades de um processo, um objetivo específico é alcançado. 
Em seu uso normal, a palavra “processo” significa uma relação de ativ idades que 
devem ser executadas em uma certa ordem sem importar o objetivo, regras ou material a 
ser usado. No processo de desenvolvimento da engenharia de software, é necessário saber o 
objetivo final do processo, definir regras a serem seguidas e adotar um método fixo de 
desenvolvimento. 
Um método (processo) tradicional de desenvolvimento orientado a objetos é 
dividido em análise de requisitos, análise, design (projeto), implementação, e testes. A 
análise de requisitos captura as necessidades básicas func ionais e não-funcionais do sistema 
 CD 
que deve ser desenvolvido. A análise modela o problema principal (classes, objetos) e cria 
um modelo ideal do sistema sem levar em conta requisitos técnicos do sistema. O design 
expande e adapta os modelos da análise para um ambiente técnico, onde as soluções 
técnicas são trabalhadas em detalhes. A implementação consiste em codificar em 
linguagem de programação e banco de dados os m odelos criados. E as atividades de testes 
devem testar o sistema em diferentes níveis, verif icando se o mesmo corresponde as 
expectativas do usuário. 
 
2.11.5 Fases do Desenvolvimento de um Sistema em UML 
Existem cinco fases no desenvolvimento de sistemas de software: análise de 
requisitos, análise, design (projeto), programação e testes. Estas cinco fases não devem ser 
executadas na ordem descrita , mas concomitantemente de forma que problemas detectados 
numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma 
que o resultado global gere um produto de alta qualidade e performance. 
 Análise de requisitos: Esta fase captura as intenções e necessidades dos usuários do 
sistema a ser desenvolvido através do uso de funções chamadas “use -cases”. 
 Análise: A fase de análise está preocupada com as primeiras abstrações (classes e 
objetos) e mecanismos que estarão presentes no domínio do problema. 
 Design: Na fase de design, o resultado da análise é expandido em soluções técnicas. 
Novas classes serão adicionadas para prover uma infra -estrutura técnica: a interface do 
usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros 
sistemas, dentre outros. 
 Programação: Na fase de programação, as classes provenientes do design são 
convertidas para o código da linguagem orientada a objetos escolhida (a utilização de 
linguagens procedurais é extremamente não recomendada). Dependendo da capacidade 
da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. 
 Testes: O sistema será testado pelo usuário final e verificará se os resultadosmostrados 
estão realmente de acordo com as intenções do usuário final. 
 
 
 
 
2.11.6 O Futuro da UML 
Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros 
aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado 
em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a 
linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser 
definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir 
a sua estrutura interna. 
A UML será a base para muitas ferramentas de desenvolvimento, incluindo 
modelagem visual, simulações e ambientes de desenvolvimento. Em breve ferramentas de 
integração e padrões de implementação baseados em UML estarão disponíveis para 
qualquer um. A UML integrou muitas idéias adversas, e esta integração vai acelerar o uso 
do desenvolvimento de softwares orientados a objetos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 3 
 
Diagramas 
 
3.1 Diagramas em UML 
Os diagramas em UML são representações gráficas que contém nós c onectados por 
caminhos. A informação está na topologia. Podem ser construídos vários diagramas que 
sumarizam a informação derivada de diagramas e modelos fundamentais. A figura 3.1 
representa os tipos de diagramas da UML. 
 
Figura 3.1 – Tipos de Diagramas da UML [3] 
 
3.2 Diagramas de Caso de Uso 
Os diagramas de casos de uso são padrões de comportamentos de um determinado 
ator em relação ao sistema. Os casos de uso representam a funcionalidade que o sistema 
deve prover para satisfazer as necessidades do ator. A figura 3.2 ilustra um diagrama de 
caso de uso em UML. 
 
 
 
 
 
 
 
 
 
 
 
 Figura 3.2 – Diagrama de Caso de Uso 
 
 
3.3 Diagrama de Interação 
 
O diagrama de interação ilustra as interações de mensagens entre instâncias e 
classes no modelo de classes. Existem dois tipos de diagramas de interação: Diagrama de 
Seqüência e Diagrama de Colaboração. 
 
3.4 Diagrama de Seqüência 
 
Mostra a interação entre objetos de um sistema. Um diagrama de seqüência captura 
o comportamento de um único caso de uso. Apresenta os objetos e as mensagens que são 
passadas entre esses objetos dentro do caso de uso. 
 
3.5 Diagrama de Colaboração 
Mostra a interação dinâmica de um caso de uso. É organizada em torno de objetos e 
vínculos m útuos de maneira que sejam evidenciados por números de sequência a ordem de 
mensagens. 
 
3.6 Diagrama de Classe 
São os diagramas mais importantes na modelagem orientada a objetos e representam 
a essência da UML. Um diagrama de classe mostra um conjunto de classes, interfaces, 
colaborações e seus relacionamentos, fornecendo uma visão estática do sistema. 
Os diagramas de classes são importantes não só para visualização, especificação e 
documentação de modelos estruturais, mas também para a construção de sistemas 
executáveis por intermédio da engenharia de produção de software. 
 Num diagrama de classe pode conter: 
- classes, associações e atributos; 
- interfaces (com operações e constantes) 
- métodos 
- informações sobre o tipo de atributos. 
 
3.7 Diagrama de Estado 
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. 
Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens 
recebidas, timer, erros, e condições sendo satisfeitas) afetam estes estados ao pa ssar do 
tempo. 
 
3.8 Diagrama de Atividade 
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho 
executado na implementação de uma operação (método), e suas atividades numa instância 
de um objeto. 
 
3.9 Diagrama de Componente 
O diagrama de componente e de execução são diagramas que mostram o sistema 
por um lado funcional, expondo as relações entre seus componentes e a organização de 
seus módulos durante sua execução. 
Componentes são tipos, mas apenas componentes executáveis podem ter instâncias. 
Um diagrama de componente mostra apenas componentes como tipos. Para mostrar 
instâncias de componentes, deve ser usado um diagrama de execução, onde as instâncias 
executáveis são alocadas em nodes. 
 
 
 
3.10 Diagrama de Execução 
O diagrama de execução mostra a arquitetura física do hardware e do software no 
sistema. Pode mostrar os atuais computadores e periféricos, juntamente com as conexões 
que eles estabelecem entre si e pode mostrar também os tipos de conexões entre eles. 
O diagrama de execução é composto por componentes, que possuem a mesma 
simbologia dos componentes do diagrama de componentes, nodes, que significam objetos 
físicos que fazem parte do sistema, podendo ser uma máquina cliente numa LAN, uma 
máquina servidora, uma impressora, um roteador, etc., e conexões entre estes nodes e 
componentes que juntos compõem toda a arquitetura física do sistema 
 
3.11 Relacionamentos 
Ao construir um modelo orientado a objetos, constata -se, que em sua maioria as 
classes colaboram entre si. Portanto, é necessário identificar como esses itens se 
relacionam. 
Em UML, os relacionamentos são representados por caminhos com diferentes tipos 
de linhas diferenciando os relacionamentos e também possui um nome , próximo da linha 
que o representa. 
Para expressar a multiplicidade do relacionamento entre as classes, utiliza -se 
intervalos que indicam em que proporção as classes se relacionam. 
Os relacionamentos podem ser divididos em: 
 Dependência: é um relacionamento entre elementos, um independente e outro 
dependente. Uma modificação é um elemento independente afetará diretamente 
elementos dependentes do anterior. Refinamento é um relacionamento entre duas 
descrições de uma mesma entidade, mas em níveis diferentes de abstração. 
 Associação: Uma associação representa que duas classes possuem uma ligação (link) 
entre elas, significando, por exemplo, que elas “conhecem uma a outra”. 
 Generalização: Uma generalização é um relacionamento de um elemento mais geral e 
outro mais específico. O elemento mais específico pode conter apenas informações 
adicionais. 
 
 
 
Capítulo 4 
 
Ferramentas Case 
 
 
4.1 Conceito 
O termo CASE ( Computer Aided Software Engineering) significa Engenharia de 
Software auxiliada por computador. 
Uma Ferramenta Case é um software que auxilia no ciclo de desenvolvimento de 
um sistema desde a fase de análise até a fase de testes, auxiliando também na manutenção 
do sistema. 
As Ferramentas Case apóiam na utilização de metodologias e métodos, armazenam 
informações em sua base de dados, possibilitando a comunicação com o usuário, a 
aprovação das definições de processos, fluxo de informações e atributos de entidades, não 
esquecendo de nenhum passo da metodologia usada, proporcionando alto nível de 
documentação. 
 
4.2 Vantagens 
Citamos algumas vantagens na utilização de Ferramentas Case: 
 Maior qualidade dos produtos finais, pois as ferramentas case diminuem a possibilidade 
de erros; 
 Produtividade pois ajuda na realização de algumas tarefas e até mesmo realiza algumas 
automaticamente; 
 Eliminação de trabalho que não agrega valor ao produto final; 
 Facilidade para mudanças, permitindo que sejam mudados dados e diagramas ajudando 
o desenvolvedor a tentar satisfazer o usuário. 
 Menos programação; 
 Melhor documentação, pois armazenam dados e diagramas, contribuindo para uma 
melhor documentação do sistema. 
 
Capítulo 5 
 
Ferramenta Utilizada 
 
5.1 System Architect 
O System Architect é uma evolução das ferramentas CASE (Computer Aided 
Engineering), 
O System Architect, SA, abrange o que se chama de modelagem corporativa, 
incorporando: Mapeamento e Modelagem do Negócio dos seus processos, Tecnologia, 
Organização, Componentes e Objetos, Dados, Aplicações e Localização. A figura 4.1 
ilustra a ferramentaSystem Architect. [5] 
O SA possui o que há de mais completo em termos de ferramenta case: 
 Viabiliza técnicas de levantamento de requisitos de usuário; 
 Ampla abordagem em análise Orientada a Objeto, Essencial e Estruturada; 
 Modelagem de dados e implementação física em Banco de Dados; 
 Possibilidade de utilização de framework ou criação de novos; 
 Ferramenta customizável; 
A figura 5.1 ilustra a ferramenta System Architect.[5]. 
Figura 5.1 – A Ferramenta System Architect 
 
5.2 Análise e Projeto no System Architect 
Pode-se ver as técnicas de análise e projeto orientados a objetos no S ystem 
Architect. A UML é uma das técnicas de análise e projeto originada das técnicas OMT, 
Bush e Use Case e tende ser um método padrão quando se fala em orientação a objetos. 
Além da variabilidade de técnicas, o System Architect permite gerar classes e 
atributos a partir de diagramas hierárquicos de processos lógicos, assim como gerar 
operações ao mesmo tempo, e também relacionamentos, a partir de modelos de dados e de 
negócios. [5] 
 
5.3 System Architect e Engenharia de Software 
A Engenharia de Software,é o ramo da informática que trata de gerenciar o processo 
de desenvolvimento do software desde a primeira análise, quando será, avaliado quais 
funcionalidades terá o software até eventuais manutenções depois de o produto ser entregue 
ao usuário final. 
Uma ferramenta CASE como o System Architect apoia todo o ciclo de vida de do 
software, podendo ser utilizada em todas as fases de desenvolvimento do 
projeto,facilitando o trabalho tanto de analistas quanto de desenvolvedores. 
 
5.4 Desenvolvimento em equipe 
O System Architect permite ao desenvolvedor especificar os relacionamentos entre 
quaisquer objetos, que podem ser exibidos via websites gerados pela própria ferramenta e 
acessados por software de navegação (Browser) via intranet, por exemplo. 
 
5.5 Reutilização 
O SA permite reutilizar itens de dados diagramas, detalhes de requisitos, modelos 
de processo, permitindo que todas as técnicas de modelagem possam ser usadas com o 
mesmo repositório, possibilitando ao desenvolvedor utilizar diferentes técnicas, formando a 
metodologia própria. 
 
5.6 Interface com o usuário 
A interface do usuário com o System Architect é apresentada conforme ilustra a 
figura 5.2 
 
 
Figura 5.2 – System Architect 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 6 
 
Introdução a Linguagem ASP 
 
6.1 ASP 
ASP é um tecnologia da Microsoft que disponibiliza um conjunto de componentes 
para o desenvolvimento de páginas Web dinâmicas. Tais páginas consistem em arquivos de 
extensão *.asp no formato texto(ASCII) que contém combinações de scripts e tags HTML. 
Os códigos de programação existentes em página ASP são executados no servidor e 
este retornando ao cliente respostas em HTML padrão - o que faz com que as aplicações 
ASP possam ser acessadas em qualquer browser. 
Um servidor Web que suporta ASP funciona da seguinte forma: 
 Cliente solicita página *.asp 
 Servidor abre a página e lê seu conteúdo 
 Se encontra tags HTML, envia direto ao cliente 
 Se encontra comandos de script: 
 Para o envio 
 Processa os comandos 
 Envia o resultado HTML ao cliente. 
Entre os recursos que podem ser implementados com ASP, podemos citar: 
 Programação com Visual Basic Script e Java Script 
 Acesso a banco de dados 
 Envio de e-mail 
 
6.2 Aplicações de Cliente – Servidor 
Consiste na divisão de processos entre estações clientes e servidores, com a 
finalidade de buscar melhor performance, menor tempo de resposta e maior facilidade de 
manutenção. 
 
 
 
 
6.3 Pré-requisitos para funcionamento de uma página em ASP 
Páginas ASP necessitam ser hospedadas no servidor da Web da Microsoft: o 
Internet Information Server(IIS). Este servidor deve ser instalado na máquina onde será 
desejado a execução da página ASP. 
 
6.4 Os forms e ASP 
A relação entre form HTML e ASP é muito importante porque a partir de 
formulários podemos disparar ações, e é nesta ação que iremos “chamar” uma página ASP. 
Com isso podemos consistir os campos, passar parâmetros de uma página para outra. 
A sintaxe para utilizar um form no HTML é a seguinte: 
 
<FORM ACTION= NOME_ARQUIVO.ASP NAME= NOME_DO_FORM METHOD = 
METODO> 
</FORM> 
 
6.5 Os parâmetros da Tag Form 
 Os parâmetros da Tag Form são: 
 ACTION : neste item , você deve especificar o diretório e nome do arquivo ASP a ser 
disparado. 
 NAME: especifique um nome para seu formulário. Item não obrigatório. 
 METHOD: define como seus dados serão enviados para o servidor. Existem os 
métodos GET e POST. 
 Get: utilizando este método, os dados que estão sendo enviados serão mostrados pelo 
browser. 
 Post: este método não exibe no browser os dados que estão enviados. 
A figura 6.1 ilustra o funcionamento de um página em ASP 
 
Figura 6.1 – Como funciona uma página em ASP [7] 
Entre os recursos que podem ser implementados com ASP, podemos citar 
programação com : 
- Vb script e Java Script. 
 
6.6 Rotinas de Script 
Script é um programa escrito numa determinada linguagem de programação que não 
necessita ser compilado para ser posteriormente executado. Scripts são interpretados, ou 
seja, seus comandos são lidos em tempo de execução por um Script Engine, processados e 
seus resultados passados para a saída padrão da aplicação(monitor de vídeo, impressora, 
sevidor web etc).[7 ] 
Toda a funcionalidade e “Inteligência” de uma página ASP é controlada através de 
comandos de Script. Teoricamente, o ASP pode utilizar qualquer Script 
Engine(interpretador), mas na prática a Microsoft só disponibiliza dois: 
 Visual Basic Script (VBScript) - default 
 MS Java Script(JScript) 
 
6.7 Visual Basic Scripts 
VBScript é uma linguagem criada a partir do Visual Basic, mas com algumas 
limitações (por motivos de segurança) além de ser interpretada e não compilad a. Dentre 
outros pontos, permite a manipulação de strings, datas, numéricos e objetos Active X do 
servidor. Ela é a linguagem de script mais utilizada para desenvolvimento de páginas ASP 
É a linguagem Script default (padrão). Quando o código for rodar é ne cessário que 
esteja entre tags <% %>. Baseada nas funcionalidades do Visual Basic é uma linguagem 
leve que é nativamente executada pelo internet explorer. 
 
6.8 Java Script 
É uma linguagem que permite colocar lógica em páginas HTML. Os parágrafos de 
lógica do Java Script podem estar “soltos” ou presos a ocorrências de eventos. Os 
comandos Java Script são sensíveis ao tipo de letra (maiúsculas / minúsculas) em sua 
sintaxe. 
 
6.9 ODBC – Open DataBase Connectivity 
O ODBC(Open DataBase Connectivity) é o meio mais conhecido para acessar um 
banco de dados em ambiente Windows. Utilizando o ODBC, desenvolvedores não 
precisam se preocupar com as particularidades dos bancos de dados que irão acessar e 
trabalhar. 
Quando um banco de dados é acessado através do ODBC, este banco 
necessariamente tem que estar registrado como uma origem de dados ODBC. Registrando 
o banco de dados como uma origem, a aplicação apenas precisa saber o nome desta origem 
de dados. A localização do banco não faz a diferença, nem mesmo o tipo de ba nco de 
dados. 
A figura 6.2 ilustra a arquitetura de aplicativo/ driver no W indows é a seguinte: 
 
Figura 6.2 – Banco de Dados ODBC 
 
Existem três tipos de origem de dados: System DSN, User DSN e File DSN. O 
System DSN é utilizado quando vários usuários de um sistema podem acessar a base. O 
User DSN é utilizado quando um usuário específico pode ter acesso, e o File DSN é uma 
descrição do banco. Geralmente , a opção para criar uma origem de dados é o System DSN, 
pois uma aplicação na maioria das vezes, é acessada por vários usuários. [7 ] 
 
6.10 Desenvolvendo Aplicações Web 
 
 
Em uma aplicação cliente/servidor, a aplicaçãocliente mantém uma conexão com a 
aplicação servidor, consultando-o periodicamente para verificar se a conexão está aberta. 
Se o servidor estiver fora do ar, a aplicação cliente não conseguirá a conexão e então 
tomará as medidas apropriadas ( se esta estiver preparada para isso) como por exemplo, 
enviar uma mensagem de erro para o usuário. A figura 6.3 ilustra o ActiveXDataObjec t. 
 
 
 
 
Figura 6.3: ActiveXDataObject 
 
6.11 ADO ActiveXDataObject 
 
È uma coleção de objetos utilizados para recuperação, alteração , inclusão e 
exclusão de registros em banco de dados ODBC e OLE DB e é instalado com o IIS. 
O ADO é escrito em páginas ASP e executado no servidor Web, e retorna as 
informações dos bancos de dados em formato HTML. A página retornada pode ser 
visualizada por qualquer browser em qualquer plataforma, pois o código é todo executado 
pelo servidor. 
Esta coleção de objetos constitui um a camada entre a página Web e o banco de 
dados.[7] 
A figura 6.4 ilustra a comunicação do ADO com um banco de dados ODBC. 
 
 
 
Figura 6.4: Acessando banco de dados 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 7 
 
 
Modelagem do Protótipo 
 
7.1 Protótipo 
 
Antes de construir um software que represente um sistema real, deve -se ter um 
amplo conhecimento do domínio deste sistema, ou seja, deve -se analisá-lo. A análise será 
bastante proveitosa se resultar na construção de modelos, pois eles permitem que se tenha 
uma interação com o problema e conseqüentemente o seu inteiro conhecimento. [1] 
A modelagem não só servirá para entender o sistema e visualizar como ele deverá 
ser ou se comportar, mas também seus modelos serão os guias na implementação do projeto 
e serão usados para a documentação do resultado final. 
Os modelos permitem que erros sejam visualizados antes da codificação do 
software, por isso reduzem os riscos de implementação. 
A primeira fase na construção de um sistema é a sua compreensão, que será mais 
facilmente concebida se for auxiliada por modelos. Mas é importante evidenciar que nunca 
existirá um só modelo que represente a totalidade de um sistema. Na verdade a modelagem 
consiste na produção de um conjunto de modelos que se inter -relacionam e individualmente 
representam o sistema sob determinadas perspectivas. 
Segundo Furlan (1998), os diagramas da UML possuem uma notação padrão e 
bastante compreensível que permite abstrair certos aspectos do sistema, ficando, assim, 
fácil de entendê-lo através de suas partes. Ao final da modelagem essas partes se 
completam e representam o sistema em sua totalidade. [1] 
O conjunto de modelos resultante de uma modelagem é a proposta de uma solução 
para o problema que deu origem à necessidade de se construir um sistema. Essa proposta 
poderá ser viável ou não. Assim, o modelo deverá ser estudado até se chegar a uma 
conclusão aceitável. Durante esse estudo o modelo poderá sofrer algumas alterações a fim 
de corresponder aos requisitos do sistema. 
 
 
 
 
7.2 Análise de Requisitos 
 
Esta fase captura as intenções e necessidades dos usuários do sistema a ser 
desenvolvido através de funções denom inadas “use -cases”[Barros,2001]. O princípio 
básico da análise de requisitos é identificar e documentar o que realmente é necessário, 
comunicando a todos os envolvidos no projeto da forma mais clara possível para que os 
riscos sejam identificados sem correr riscos de imprevistos. 
O que será desenvolvido: um sistema de comércio eletrônico para venda e compra 
de cd’s musicais. O cliente acessa no site escolhe o cd do seu gosto e compra usando como 
forma de pagamento o cartão de crédito, depósito ou via sedex à cobrar tendo que para isso 
fazer um cadastro para que o produto seja entregue e também para que informações 
enviadas pelo cliente sejam verdadeiras, será feito testes de validação como verificação de 
cartões de crédito, do número dos documentos. A ferramenta utilizada System Architect 
será responsável por gerar os diagramas e casos de uso para que esses também sejam 
utilizados para leitura do programa pelos desenvolvedores ou outros usuários. 
 
7.3 Requisitos do usuário 
 
RU01:Deverá ser criada uma loja virtual de vendas de cd’s de coleções musicais. 
 
RU02: Um usuário ao entrar no site pode procurar os cd’s de várias formas. 
 
RU03: Caso o cliente queira fazer uma compra, primeiro será feito seu cadastro. 
 
RU04: O cliente só receberá o produto mediante pagamento efetuado. 
 
RU05: O produto só será entregue no endereço cadastrado pelo cliente. 
 
RU06: O cliente poderá remover os itens selecionados caso não q ueira completar a 
compra. 
 
RU07: Poderá o cliente fazer o cadastro mesmo não fazendo compra naquela data 
da visita. 
 
RU08: O cliente cadastrado terá um login e senha sendo usado sempre quando 
visitar o site e quiser fazer uma compra. 
 
RU09: Deve existir a opção para mais compras. 
 
RU10: Deve existir a opção de consultas de todos os itens já selecionados pelo 
cliente. 
 
RU11: Todos os dados cadastrados (cd’s, produtos) deverão ser armazenados num 
banco de dados. 
 
RU12: Deverá ser feito o cálculo do frete para entrega em todo país. 
 
7.4 Requisitos de Software 
RS01: As páginas da loja serão feitas em ASP(Active Server Page) por ser uma 
linguagem dinâmica e tipo cliente-servidor. 
 
RS02: O banco de dados utilizado neste sistema é o Microsoft Access. 
 
RS03: A loja virual terá uma página para busca dos cd’s. O cliente poderá buscar 
por vários estilos musicais como: popular, sertanejo etc. 
 
RS04: Uma página para cadastro do cliente onde além dos seus dados principais( 
nome, endereço) ele cadastrará seu login e senha onde poderá usar toda vez que vier 
a visitar o site. 
 
RS05: O cliente pode escolher outro endereço para entrega desde que este também 
esteja cadastrado. 
 
RS06: O site terá uma página onde serão listados todos os produtos selecionados 
pelo cliente ficando a critério do mesmo finalizar a compra, remover os produtos ou 
ainda continuar comprando. 
 
RS07: Uma página para o cliente deixar sua dúvida. 
 
RS08: Uma página Login para o cliente fazer seu cadastro mesmo não fazendo 
nenhuma compra naquela data da visita. 
 
RS09: Os pagamentos poderão ser feitos através de cartões de crédito, sedex à 
cobrar e depósito bancário. 
 
RS10: O site conta com uma função para validar os cartões de crédito. 
 
RS11: Para veracidade da compra o site conta ainda com uma função para validação 
de documento ( CPF) dos clientes que vierem a fazer cadastros. 
 
RS12: Quando o cliente for finalizar a compra , deverá ser feito o cálculo do frete 
(para qualquer região do país) e ser exibido na tela o preço total já com o valor calculado. 
 
 RS13: Esse sistema funciona em qualquer computador que tenha sistema 
operacional W indows com acesso a internet. 
 
A tabela 7.1 mostra os requisitos de usuário sendo atendidos pelos requisitos de 
software. 
 
 
Tabela 7.1 - Tabela de comparação 
 
 
7.5 Casos de Uso 
 
Para modelagem do sistema foram usados o s seguintes diagramas: caso de uso, 
diagrama de classe, de atividade, de colaboração, de componente e de estado por cada um 
representar aspectos importantes no sistema em questão. A figura 7.1 ilustra o diagrama de 
caso do cliente, a figura 7.2 ilustra o diagrama de caso de uso do administrador. 
Requisitos de usuário (RU) Requisitos de software (RS) Situação 
RU01 RS01 OK 
RU02 RS03 OK 
RU03 RS04 OK 
RU04 RS08 OK 
RU05 RS05 OK 
RU06 RS06 OK 
RU07 RS08 OK 
RU08 RS08 OK 
RU09 RS06 OK 
RU10 RS04 OK 
RU11 RS12 OK 
Figura 7.1 – Caso de Uso do Cliente 
 
 
As associações com setas tracejadas representam dependências, ou seja, o caso de 
uso de onde parte a seta depende do outro caso de uso para onde se destina a seta. Por 
exemplo, o caso de uso "Realizar venda de CD " [F ig 7.1] depende funcionalmentedo caso 
de uso "Validar cliente" [Fig 7.1]. Este por sua vez depende do caso de uso "Cadastrar 
cliente" [Fig 7.1]. Isso funciona da seguinte maneira: quando se está realizando uma 
compra o cliente informa seus dados, assim o caso de uso "Validar cliente" irá verificar na 
base de dados se o cliente já está cadastrado para permitir a venda, se ele não estiver 
cadastrado o caso de uso "Cadastrar cliente" entra em ação para realizar o cada stro. 
 
Cliente
Exibir lista de CD e suas músicas
Cancelar Venda
Cadastrar cl iente
Real izar venda de CD
Validar cl iente
Figura 7.2 – Caso de uso do administrador 
 
 
A tabela 7.2 mostra a descrição do caso de uso. 
SISTEMA NA WEB PARA VENDA 
CASO DE USO FUNÇÃO 
 - Cadastrar cliente Fazer o cadastro de clientes para que ele 
possa efetuar uma compra; 
 - Exibir lista de cd Exibe todos os cd’s disponíveis para compra 
 - Realizar venda de cd Permite ao cliente comprar o cd 
 - Validar cliente Antes de efetivar a compra , verifica-se se o 
cliente está cadastrado, caso contrário ativa o 
“Login” e solicita que o cadastro seja feito 
primeiramente. 
ÁREA ADMINISTRATIVA 
 - Manipular preços dos cd’s à venda - Para inserir, excluir ou alterar preço de 
Administrador
Manipular dados de clientes Manipular dados de preço de
CD e frete
Manipular dados de CDs
Manipular dados de vendas
a entregar
Manipular dados de vendas
realizadas
algum cd à venda. 
 - Manipular dados de clientes - Insere, altera ,exclui ou pesquisa dados de 
clientes cadastrados. 
 - Manipular mensagens de dúvidas - Gerencia as mensagens enviadas pelos 
clientes. 
 - Produtos mais vendidos - Manipula os cd’s mais vendidos no site 
Tabela 7.2 – Descrição do caso de uso 
 
7.6 Diagrama de Classe 
 
O diagrama de classes permite a visualização estática dos objetos que compõem o 
projeto. 
A figura 7.3 ilustra o diagrama de classe do sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 7.3 – Diagrama de Classe 
 
 
7.7 Diagrama de Componente 
 
O diagrama de componentes é importante para que possamos visualizar a 
organização do código do sistema, pois com ele é possível identificar todos os seus 
componentes e as relações de dependências entre eles. 
Para este modelo foram colocados os com ponentes dentro de seus respectivos 
pacotes, ou seja, os retângulos grandes são a representação de um pacote (diretório) dentro 
do qual há os componentes (arquivos) que são partes do software como, por exemplo, 
alguns scripts *.vbScript, o executável default.asp e a DLL libpq.dll. 
Cliente
- Cod_cliente
- Nome
- CPF
- Logradouro
- Número
- Bai rro
- UF
- Cep
- Fone
- E-mail
Inserir ()
Excluir ()
Pesqui sar ()
Alterar ()
CD
- Cod_CD
- Titulo
- Estilo
- Preco
Inserir ()
Alterar ()
Excluir ()
Pesqui sar ()
Venda
- Cod_venda
- Data
- Valor
Nova Venda ()
Pesqui sar ()
Cancelar ()
Item venda
- Cod_item_venda
- Quantidade
- Tipo_cd
Inserir ()
Excluir ()
Pesqui sar ()
*
1
1
*
1
*
Uma característica do diagrama de componente é que são formados por classes 
relacionadas e quando estas estão isoladas o componente se comporta como objeto 
encapsulado, tornando-se dependente destas. 
A figura 7.4 ilustra o diagrama de componentes do sistema. 
Figura 7.4 – Diagrama de Componente 
 
7.8 Diagrama de Estado 
 
O diagrama de estado mostra os estados que um objeto pode possuir e como os eventos 
(mensagens recebidas, timer, erros, e condições sendo satisfeitas) afetam estes estados ao 
passar do tempo. 
A figura 7.5 ilustra o diagrama de estado do sistema. 
 
 
 
 
Catálogo CDs
Compra
Validar cadastro de
cliente
Cancelar compra
IndexCadastro_cl iente
Conexão
Web Music
Libpq
Função
CD
Pacote: Admini strativo
Pacote: Includes
Pacote: Imagens
Pacote: Página
 
Figura 7.5 – Diagrama de Estado 
 
 
Registrar
encerramento da
compra
Cancela pedido de
nova compra
Anal isando pedido
nova compra
Pedido de compra
não pode ser
atendido
Registrando nova
compra
Registrando nova
compra
Fim
Fim
Pedido nova compra
Nova compra regi strada
Registra novo
pedido de compra
Registrando
nova compra
Compra cancelada
Cancelando pedido
de nova compra
Nova compra não
pode ser efetuada
Verificando se todos
os dados para a nova
compra estão OK
Início
Diagrama de Estado
7.9 Diagrama de Atividade 
 
O diagrama de atividade captura ações e seus resultados. Eles focam o trabalho 
executado na implementação de uma operação (método), e suas atividades numa instância 
de um objeto. 
 A figura 7.6 ilustra o diagrama de atividade do sistema. 
 
Figura 7.6 – Diagrama de Atividade 
 
 
Não
Não
Não
Verifica
cartão
crédito
Comprar
CD
Pesqui sar
CD
Acessar
loja
OK
OK
OK
Início
Fim
Diagrama de Atividade
Sim
Sim
Sim
7.10 Diagrama de Colaboração 
 
O diagrama de Colaboração mostra os vínculos entre as classes pelos quais fluem as 
mensagens. Havendo um vínculo, as classes podem colaborar uma com as outras 
 porque há um caminho por onde a mensagem pode ser enviada. 
 A figura 7.7 ilustra o diagrama de colaboração do sistema. 
Figura 7.7 – Diagrama de Colaboração 
 
7.11 Projeto 
 
Nesta fase parte-se para as soluções técnicas, através dos resultados obtidos na fase 
de análise. Juntando as classes da fase de análise com a nova infra -estrutura pode-se alterar 
tanto o domínio principal do problema quanto a infra -estrutura. 
Com a elaboração do projeto obtém -se detalhadamente as especificações para dar 
início a fase de programação. 
 
 
 
 
 
Servidor Web
PC Qualquer
Administrador
Página
ImagensIncludes
 
7.11.1 Programação 
Para que uma fase de programação possa ter um bom desempenho, necessita -se de 
um projeto bem elaborado, e então converter as classes da fase do projeto para o código da 
linguagem escolhida. 
 
7.11.2 Testes 
Na fase de teste é executado um programa com a intenção de descobrir erros. Testa -
se cada rotina ou processo detalhadamente , bem como a integração de todos os processos 
e a aceitação. Os testes de integração são feitos usando classes para verificar se estas estão 
colaborando mutuamente conforme especificado nos m odelos. Nos testes de aceitação é 
verificado se os sistemas estão de acordo com os diagramas de “use -cases”. [8] 
As rotinas também são testadas pelos programadores, usuários e por fim usuário 
final que verificará se os resultados apresentados estão de acordo com as intenções do 
início do projeto. 
 
7.12 Banco de Dados de Desenvolvimento 
Para armazenamento dos dados da página(produtos , preços, compras) e também 
dos clientes (nome, endereço) é necessário um banco de dados. O banco de dados usado 
para desenvolvimento do sistema será o Microsoft Access. 
Foi criado no Access um banco de dados de uma empresa fictícia, cuja função é 
mostrar de forma didática a integração de um sistema virtual de vendas com ferramentas 
case. A figura 7.8 ilustra um software de servidor de comércio eletrônico 
 
 
 
 
 
 
Figura 7.8 – Software de um servidor de comércio eletrônico 
 
 
 
7.13 Comunicação de Dados 
 
O comércio eletrônico pode ser dividido em várias fases distintas: 
 
1. Envio do pedido: 
1.1. Envia pedido ao lojista com as informações referentes aos produtos selecionados e o 
valor da compra 
1.2. Envia pedido ao banco com as informações do cartão para pagamento e o valor a ser 
pago; 
2. Verificação dos certificados digitais do comprador e do lojista; 
3. Envio da confirmação do pedido para o lojista; 
4. Confirmação do pedido efetuado enviado por e_mail; 
5. Requisição de pagamento feita pelo lojista para o banco; 
6. Efetuação do pagamento do lojista 
 A figura 7.9 ilustra um exemplo de um esquema de compras. 
 
 
Figura 7.9 – Esquema de compras 
 
 
As fases iniciais de desenvolvimento de um software são as mais conflitantes. 
Semprehá falta de entendimento entre os membros da equipe de desenvolvimento e entre a 
equipe e os usuários (clientes) do sistema. Isso se deve na maioria das vezes a falta de um 
vocabulário de comunicação entre as partes. Por exemplo, quase sempre os próprios 
clientes ou usuários do sistema têm dificuldades em explicar seus requisitos. Por isso, 
existe a necessidade de uma notação padrão que atue nas fases de análise de requisitos e 
modelagem do sistema. Como notação, é proposto a utilização da UML que já é, de fato, 
um padrão formalizado pela OMG (Object Management Group) e tem, a cada dia que 
passa, um incremento na comunidade de seus adeptos. É também grande a quantidade de 
ferramentas CASE que dão suporte aos diagramas da UML. Isso facilita a sua aplicação em 
desenvolvimentos de projetos, pois o uso da UML auxiliado por uma CASE eleva a 
velocidade de produção do software, diminui os riscos e também garante uma maior 
qualidade do produto final. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo 8 
 
 
Desenvolvimento do Sistema 
 
8.1 Music Online 
 
O objetivo deste trabalho é testar e mostrar as vantagens e aplicabilidades da 
ferramenta case junto à um sistema de comércio eletrônico. Para isso será desenvolvido 
um sistema de vendas de cd’s pela internet. 
O Music Online é um site simples para venda de cd de coleções de músicas de 
vários estilos musicais: pop, rock, música popular, sertanejo e samba. As vendas são 
realizadas através de uma página na web. Na página o cliente poderá "navegar" pelos 
CD’s colocados à venda. Para comprar ele deverá cadastrar -se como cliente fornecendo 
seu nome, e-mail, RG,CPF, endereço e também cadastrando um login e senha para 
posteriores visitas. Para que garantir a veracidade dos dados inseridos pelo cliente o site 
MusicOnline conta com uma função para validação de CPF. As vendas são efetuada s em 
várias formas: depósito bancário, sedex à cobrar ou com cartão de crédito que para isso o 
site conta com uma função de validação de cartões. Os produtos vendidos são entregues 
na residência do cliente ou em outro endereço qualquer determinado por ele no ato da 
compra. Os CDs de músicas comuns têm preços já determinados. 
O Music Online conta com seguintes serviços: o cliente acessa o site , procura pelo 
cd preferido ou verifica todos à venda , se quiser comprar algum seleciona o carrinho de 
compras ou pode obter maiores detalhes sobre o produto clicando no botão mais detalhes. 
Então será mostrado outra página para que o cliente realize o seu cadastro. A partir dessa 
fase será mostrado a página exibindo o produto selecionado por ele para compra. Na 
mesma página o cliente pode escolher se quer continuar com a compra, adicionando mais 
produtos ou remover os já selecionados ou então finalizar. 
O cliente tem ainda as páginas para enviar suas mensagens, dúvidas etc e para isso 
não é necessário o cadastro. Ele poderá fazer seu cadastro no site também sem que seja 
necessário realizar uma compra, podendo também verificar quais são os cd’s mais 
vendidos ou enviar uma oferta do site à um amigo se desejar. 
 
 
8.2 Módulos do Sistema 
O site será desenvolvido em ambiente Windows 2000/XP e como servidor web 
estaremos utilizando o Internet Information Service. 
Os formulários e arquivos ASP e HTML serão construídos usando o FrontPage. As 
páginas do site Music Online serão criadas usando as linguagens : HTML,ASP, JavaScript, 
VBScript e para gerenciar os dados estaremos usando a tecnologia ADO. 
 
8.3 Interface do Sistema 
 
É apresentado alguns exemplos de telas de interface do Music Online. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A Figura 8.1 ilustra a tela inicial do Music Online 
 
 
 
 
 
Figura 8.1 – Tela Principal do Sistema 
 
 
 
 
 
 
 
 
 
 
A Figura 8.2 ilustra a tela Carrinho de Compras 
 
 
 
 
 Figura 8.2 – Carrinho de Compras 
 
 
 
 
 
 
 
 
 
 
 
A figura 8.3 ilustra a tela Registro de Clientes do Music Online 
 
 
 
 
 
Figura 8.3 – Cadastro de Cliente 
 
 
 
 
 
 
A Figura 8.4 ilustra a tela de login do cliente no Music Online 
 
 
 
 
 
 Figura 8.4 – Login do usuário 
 
 
 
 
 
 
 
 
 
Capítulo 9 
 
 
Conclusão 
 
Este trabalho apresentou um estudo da linguagem UML e sua aplicação no 
desenvolvimento de um sistema de comércio eletrônico MusicOnline. 
As técnicas de modelagem passam constantemente por atualizações, correções e 
extensões para diversas áreas de aplicação. Apenas a atualização teórica não é suficien te: a 
prática da modelagem é necessária para a apreensão dos conceitos.[1] 
Concluído o estudo sobre UML, foi iniciada a fase de modelagem do sistema 
aplicando agora o estudo adquirido. 
Quanto ao processo de aprendizagem da UML, apesar das dificuldades enco ntradas 
com o manuseio da ferramenta System Architect, a UML tornou-se menos complexa 
devido a sua fácil notação. 
Após o estudo da ferramenta CASE System Architect, utilizamos a mesma no apoio 
e validação da metodologia. Esta ferramenta mostrou-se bastante complexa e eficaz, pois 
possui uma documentação interativa e automática dos processos de modelagem, permitindo 
até mesmo gerar o código fonte através dos modelos. 
Com o desenvolvimento do protótipo utilizando esta metodologia, podemos 
concluir que os objetivos foram alcançados, tendo em vista que esta atendeu a todas as 
fases de desenvolvimento do protótipo. 
 
 
 
 
 
 
 
 
 
 
Referências Bibliográficas 
 
 
[1] Oliveira, Fábia Luciene . Trabalho de Conclusão de Curso: Análise e Implementação 
de um software de gerenciamento de frota baseado na linguagem UML , Univap - São 
José dos Campos – SP, 2000. 
 
[2] Zindel Deboni,José Eduardo. Apostila Modelagem orientada a objetos com a UML 
 
[3] A Importância de utilizar UML para modelar sistemas: Caso de uso. Disponível 
em: <http://www.cefetsp.br/edu/sinergia/6p10c.html> Data acesso: 18/06//04 
 
[4] Booch,G.,Rumbaugh,J.,Jacobson,I.,UML Guia do usuário. Editora Campus Ltda., 
2000. 
 
[5] Informativo sobre System Architect . Disponível em : <http://www.choose.com.br> 
Data acesso: 02/07/04 
 
[6] Mialaret, Lineu F.S. POOII. Disponível em: www1.univap.br/~lineu 
 
 [7] Active Server Page . Disponível em: 
<www14.brinkster.com/carlosband/introducao.htm> 
Data acesso: 15/07/04 
 
[8] Tutorial da ferramenta Case UML . Disponível em: 
http://diogenesln.vilabol.uol.com.br/listex2_diag_uml.htm 
Data acesso: 23/11/04 
 
 
 
http://www.cefetsp.br/edu/sinergia/6p10c.html%3e
http://www.choose.com.br/
http://diogenesln.vilabol.uol.com.br/listex2_diag_uml.htm