Curso

1. Arquiteturas de Sistemas de Informações

Gestão da Informação
Na década de 1970, já era grande o movimento em torno da importância de
Administração de Dados Corporativos. O dado persistente passa a ser visto
como recurso, e portanto, patrimônio da organização.
Com a evolução tecnológica, este tema ganhou proporção ainda maior,
Modelagem de Sistemas de suscitando a idéia de Gerência de Conhecimento, e o conceito de Capitalização
do Conhecimento. Este trabalho apresenta uma introdução a este tema
Informaç
Informação buscando uma integração de conceitos e a formulação de uma cultura
organizada sobre estes assuntos.
Uma característica altamente relevante no uso dos Computadores é que
basicamente eles operam sobre elementos de Dados. Seja em aplicações
científicas, militares, ou em áreas de negócio específicas, um determinado
conjunto de dados está sempre sofrendo operações de modo a produzir novos
dados e oferecer aos seus usuários serviços e informação.
Dados são representações de fatos e conceitos que se supõe existentes no
mundo Real ou no mundo Ideal. Informação pode ser entendido como uma
inferência possível a partir de um conjunto de dados inter-relacionados e que
permitem uma decisão ou ação conseqüente tanto por humanos como por
máquinas.

By Prof. José
José Antonio S. Monteiro

1
Um Serviço, neste contexto, pode ser a elaboração de dados para
apresentação, como Gráficos estatísticos ou o acionamento e/ou
monitoramento de outras máquinas, como lançamento de mísseis,
acionamento de braço mecânico, etc.
Devido a essa característica, durante algum tempo, os centros de utilização de
computadores foram designados como CPD (Centro de Processamento de
Dados), o que denota uma conotação com processos automatizados
manipulando Dados. De um modo geral ainda, a aplicação de Computadores
está situada no contexto chamado de (Tecnologia da Informação). No Brasil, o
termo Informática ganhou grande popularidade por ocasião da disseminação
de uso de computadores motivada em grande parte pela evolução da
tecnologia de redes, a explosão do consumo de microcomputadores e do salto
tecnológico experimentado pela indústria de software oportunizada
principalmente por este nicho de mercado.
Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de
prever o volume de informações armazenadas a curto, médio e longo
prazo. Os projetos devem ter uma grande capacidade de adaptação para
os três casos mencionados;
Deve-se ter generalidade e alto grau de abstração de dados, possibilitando
confiabilidade e eficiência no armazenamento dos dados e permitindo a
utilização de diferentes tipos de gerenciadores de dados através de
linguagens de consultas padronizadas;
Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar
aprendizado suave ao usuário, no intuito de minimizar o esforço cognitvo;
Implementação de um projeto de interface compatível com múltiplas
plataformas (UNIX, Windows NT, Windows Workgroup, etc);
Independência de Implementação da Interface em relação aos SGBDs que
darão condições às operações de armazenamento de informações
(ORACLE, SYSBASE, INFORMIX, PADRÃO XBASE, etc).
Conversão e mapeamento da diferença semântica entre os paradigmas
utilizados no desenvolvimento de interfaces (Imperativo (ou procedural),
Orientado a Objeto, Orientado a evento), servidores de dados (Relacional)
e programação dos aplicativos (Imperativo, Orientado a Objetos).
Arquiteturas
As primeiras arquiteturas usavam mainframes para executar o processamento
principal e de todas as funções do sistema, incluindo os programas
aplicativos, programas de interface com o usuário, bem como a
funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos
usuários fazia acesso aos sistemas via terminais que não possuíam poder
de processamento, apenas a capacidade de visualização. Todos os
processamentos eram feitos remotamente, apenas as informações a serem
visualizadas e os controles eram enviados do mainframe para os terminais
de visualização, conectados a ele por redes de comunicação. Como os
preços do hardware foram decrescendo, muitos usuários trocaram seus
terminais por computadores pessoais (PC) e estações de trabalho.
2
No começo os SGBDs usavam esses computadores da mesma maneira que
usavam os terminais, ou seja, o SGBD era centralizado e toda sua
funcionalidade, execução de programas aplicativos e processamento da
interface do usuário
eram executados em apenas uma máquina. Gradualmente, os SGBDs
começaram a explorar a disponibilidade do poder de processamento no
lado do usuário, o que levou à arquitetura cliente-servidor.
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de
computação onde um grande número de PCs, estações de trabalho,
servidores de arquivos, impressoras, servidores de banco de dados e
outros equipamentos são conectados juntos por uma rede. A idéia é definir
servidores especializados, tais como servidor de arquivos, que mantém os
arquivos de máquinas clientes, ou servidores de impressão que podem
estar conectados a várias impressoras; assim, quando se desejar imprimir
algo, todas as requisições de impressão são enviadas a este servidor. As
máquinas clientes disponibilizam para o usuário as interfaces apropriadas
para utilizar esses servidores, bem como poder de processamento para
executar aplicações locais. Esta arquitetura se tornou muito popular por
algumas razões.
• Arquitetura de Dados
Sendo os dados elementos fundamentais, por se constituírem em unidades
atômicas que ao serem combinadas e contextualizadas, produzem
informação, tem sido crucial o estudo e desenvolvimento de mecanismos para
tratamento adequado sob vários pontos de vista, tais como: Persistência,
Estrutura, Ciclo de Vida, Qualidade, Modelagem, etc.
Surgiu com muita ênfase a função de Administrador de Dados, como uma
atividade abrangente de gestão dos dados corporativos como sendo recursos
fundamentais de uma organização. A abrangência da AD (Administração de
Dados) era definida como instrumento de gestão de todos os dados da
organização (não apenas dados em formato “machine readable” mantidos em
mídia conveniente aos processos automatizados). O que tornava seu escopo,
em essência, muito próximo ao que hoje se refere uma grande parte do
contexto de que trata a Gestão de Conhecimento Corporativo.
Com o passar dos tempos, as organizações que investiram em AD colheram
muitos benefícios, porém esta função até os dias de hoje encontra muitas
dificuldades de sucesso. As atividades funcionais que persistem mais
facilmente nas organizações são aquelas associadas com objetivos de
Administração de Banco de Dados, porque são mais operacionais,
dependente de conhecimento técnico específico de SGBD (Sistemas
Gerenciadores de Banco de Dados) e necessárias ao suporte para
funcionamento do SGBD, e a manutenção da disponibilidade dos bancos de
dados. As outras funções, associadas com a inteligência na gestão dos dados,
para torná-los ativos corporativos e matéria-prima para decisões estratégicas
tem sido negligenciadas. Como tudo que é abandonado à própria sorte, um
ente acaba isolado ou diluído, num sistema onde a interação entre entes exige
identidade para que o ente possa existir, então o definhamento é inevitável.
Além dos aspectos culturais, que implicam num entendimento diversificado
sobre temas comuns, os problemas políticos tem sido a principal causa dos
problemas de AD nas organizações .
3
O principal deles, a falta de vontade política dos escalões superiores de uma
instituição para a AD, advém tanto da pobreza de visão como da pressão interna
advinda de conflitos por poder nas hierarquia da Organização que obviamente está
sujeito a atitudes tipicamente humanas, como os aforismos: "Se não for
importante, porque implantar? e se for importante, é obvio que deveria ser minha
atribuição". Além disso, os benefícios da AD devem se fazer sentir por toda a
organização, de modo que todas as áreas passam a capitalizar os efeitos desses
benefícios. Isto faz com que ao desempenhar sua missão, a AD não objetiva
visibilidade para si, mas para os efeitos de sua ação. Assim, passa a ser visto
apenas como um custo, ou quando muito, como um investimento. Com o tempo, a
missão de AD, neste cenário, passa a depender mais do heroísmo de seus
agentes e vai definhando até que apenas manutenções inadiáveis são as únicas
ações possíveis.
Na maioria das vezes sem perceber, a organização vai ficando a mercê dos
fornecedores de tecnologia e dos modismos ditados pela indústria e pela mídia. As
decisões sobre investimentos em tecnologia para tratamento de dados são
tomadas sem a participação de um agente de AD, algumas vezes porque este não
existe formalmente, outras porque não está em nível adequado na estrutura da
organização para participar destas discussões.
Primeiro, a facilidade de implementação dada à clara separação das
funcionalidades e dos servidores. Segundo, um servidor é inteligentemente
utilizado porque as tarefas mais simples são delegadas às máquinas clientes mais
baratas. Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar,
ao invés de usar a interface do servidor. Desta maneira, a arquitetura cliente-
servidor foi incorporada aos SGBDs comerciais. Diferentes técnicas foram
propostas para se implementar essa arquitetura, sendo que a mais adotada pelos
Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é
a inclusão da
funcionalidade de um SGBD centralizado no lado do servidor. As consultas e a
funcionalidade transacional permanecem no servidor, sendo que este é chamado
de servidor de consulta ou servidor de transação. É assim que um servidor SQL é
fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a
interface do usuário e as funções de interface usando uma linguagem de
programação. O cliente pode também se referir a um dicionário de dados o qual
inclui informações sobre a distribuição dos dados em vários servidores SQL, bem
como os módulos para a decomposição de uma consulta global em um número de
consultas locais que podem ser executadas em vários sítios.
Comumente o servidor SQL também é chamado de back-end machine e o cliente
de front-end machine. Como SQL provê uma linguagem padrão para o SGBDRs,
esta criou o ponto de divisão lógica entre o cliente e o servidor.
Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas
mais diversas direções.
Resumo das arquiteturas de SGBDs
Plataformas centralizadas: Na arquitetura centralizada, existe um computador
com grande capacidade de processamento, o qual é o hospedeiro do SGBD e
emuladores para os vários aplicativos. Esta arquitetura tem como principal
vantagem a de permitir que muitos usuários manipulem grande volume de dados.
Sua principal desvantagem está no seu alto custo, pois exige ambiente especial
para mainframes e soluções centralizadas.
Sistemas de Computador Pessoal - PC: Os computadores pessoais trabalham
em sistema stand-alone, ou seja, fazem seus processamentos sozinhos. No
começo esse processamento era bastante limitado, porém, com a evolução do
hardware, tem-se hoje PCs com grande capacidade de processamento. Eles
utilizam o padrão Xbase e quando se trata de SGBDs, funcionam como
hospedeiros e terminais.
4
Desta maneira, possuem um único aplicativo a ser executado na máquina. A
principal vantagem desta arquitetura é a simplicidade.
Banco de Dados Cliente-Servidor: Na arquitetura Cliente-Servidor, o cliente
(front_end) executa as tarefas do aplicativo, ou seja, fornece a interface do usuário
(tela, e processamento de entrada e saída). O servidor (back_end) executa as
consultas no DBMS e retorna os resultados ao cliente. Apesar de ser uma
arquitetura bastante popular, são necessárias soluções sofisticadas de software
que possibilitem: o tratamento de transações, as confirmações de transações
(commits), desfazer transações (rollbacks), linguagens de consultas (stored
procedures) e gatilhos
(triggers). A principal vantagem desta arquitetura é a divisão do processamento
entre dois sistemas, o que reduz o tráfego de dados na rede.
Banco de Dados Distribuídos (N camadas): Nesta arquitetura, a informação está
distribuída em diversos servidores. Como exemplo, observe a abaixo. Cada
servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos
aplicativos são feitas para qualquer servidor indistintamente.
Arquitetura Distribuída N camadas
Caso a informação solicitada seja mantida por outro servidor ou servidores, o
sistema encarrega-se de obter a informação necessária, de maneira transparente
para o aplicativo, que passa a atuar consultando a rede, independente de conhecer
seus servidores. Exemplos típicos são as bases de dados corporativas, em que o
volume de informação é muito grande e, por isso, deve ser distribuído em diversos
servidores. Porém, não é dependente de aspectos lógicos de carga de acesso aos
dados, ou base de dados fracamente acopladas, em que uma informação
solicitada vai sendo coletada numa propagação da consulta numa cadeia de
servidores. A característica básica é a existência de diversos programas aplicativos
consultando a rede para acessar os dados necessários, porém, sem o
conhecimento explícito de quais servidores dispõem desses dados.
Arquitetura Distribuída N camadas
Abstração de dados
Um SGBD é composto de uma coleção de arquivos inter-relacionados e de um
conjunto de programas que permitem aos usuários fazer o acesso a estes arquivos
e modificar os mesmos.
5
O grande objetivo de um sistema de banco de dados é prover os usuários com
uma visão abstrata dos dados. Isto é, o sistema omite certos detalhes de como os
dados são armazenados e mantidos. Entretanto, para que o sistema possa ser
utilizado, os dados devem ser buscados de forma eficiente. Este conceito tem
direcionado o projeto de estrutura de dados complexas para a representação de
dados em um banco de dados. Uma vez que muitos dos usuários de banco de
dados não são treinados para computação, a complexidade está escondida deles
através de diversos níveis de abstração que simplificam a interação do usuário
com o sistema.
Nível físico: o nível mais baixo de abstração descreve como os dados estão
realmente armazenados. No nível físico, complexas estruturas de dados de baixo
nível são descritas em detalhes;
Nível conceitual: o próximo nível de abstração descreve quais dados estão
armazenados de fato no banco de dados e as relações que existem entre eles.
Aqui o banco de dados inteiro é descrito em termos de um pequeno número de
estruturas relativamente simples. Embora as implementações de estruturas
simples no nível conceitual possa envolver complexas estruturas de nível físico, o
usuário do nível conceitual não precisa preocupar-se com isso.
O nível conceitual de abstração é usado por administradores de banco de dados,
que podem decidir quais informações devem ser mantidas no BD;
Nível de visões: o mais alto nível de abstração descreve apenas parte do banco
de dados. Apesar do uso de estruturas mais simples do que no nível conceitual,
alguma complexidade perdura devido ao grande tamanho do banco de dados.
Muitos usuários do sistema de banco de dados não estarão interessados em todas
as informações. Em vez disso precisam de apenas uma parte do banco de dados.
O nível de abstração das visões de dados é definido para simplificar esta interação
com o sistema, que pode fornecer muitas visões para o mesmo banco de dados.
Segue ilustração da arquitetura e referente abstração de dados envolvida.
Uma analogia com o conceito de tipos de dados em linguagens de programação
pode esclarecer a distinção entre os níveis de abstração. A maioria das linguagens
de programação de alto nível tem suporte para a noção de um tipo de registro. Por
exemplo, numa linguagem como Pascal podemos declarar um registro assim:
type cliente = record
nome: string; rua: string; cidade: string; end;
Isto define um novo registro chamado cliente com três campos. Cada campo tem
um nome e um tipo associado a ele. Um banco privado pode ter diversos tipos de
registros incluindo:
contas, com campos número e saldo;
funcionário, com campos nome e salário.
No nível físico, um registro cliente, conta ou funcionário pode ser descrito como um
bloco de posições de armazenamento consecutivas (por exemplo, palavras ou
bytes). No nível conceitual, cada registro destes é descrito por uma definição de
tipo, ilustrado anteriormente e o inter-relacionamento entre esses tipos de registros
é definido. Finalmente, no nível de visões, diversas visões do banco de dados são
definidas, por exemplo: os contadores de um banco vêem apenas a parte do banco
de dados que possui informações sobre contas dos clientes. Eles não podem ter
acesso a informações que se referem a salários dos funcionários.
6
Independência de dados
Vimos três níveis de abstração pelos quais o banco de dados pode ser visto. A
habilidade de modificar a definição de um esquema em um nível sem afetar a
definição de esquema num nível mais alto é chamada de independência de dados.
Existem dois níveis de independência dos dados:
Independência física de dados: é a habilidade de modificar o esquema físico
sem a necessidade de reescrever os programas aplicativos. As modificações no
nível físico são ocasionalmente necessárias para melhorar o desempenho;
Independência lógica de dados: é a habilidade de modificar o esquema
conceitual sem a necessidade de reescrever os programas aplicativos. As
modificações no nível conceitual são necessárias quando a estrutura lógica do
banco de dados é alterada (por exemplo, a adição de contas de bolsas de mercado
num sistema bancário).
A independência lógica dos dados é mais difícil de ser alcançada do que a
independência física, porém os programas são bastante dependentes da estrutura
lógica dos dados que eles acessam.
O conceito de independência dos dados é similar em muitos aspectos ao conceito
de tipos abstratos de dados em modernas linguagens de programação. Ambos
escondem detalhes de implementação do usuário. Isto permite ao usuário
concentrar-se na estrutura geral em vez de detalhes de baixo nível de
implementação.
• Modelos
Modelo Lógico
Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de
SGBD que será usado. Não podemos confundir com o Software que será
usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é
relacional, orientado a objetos, hierárquico, etc.
Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os
dados são organizados em tabelas (Quadro 1).
21
7
 • Modelos Turma
Aluno
Modelo Lógico cod_turma sala periodo
Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de mat_aluno nome endereco
SGBD que será usado. Não podemos confundir com o Software que será
usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é
1 8 Manhã
relacional, orientado a objetos, hierárquico, etc. 1 Cecília Ortiz Rezende Rua dos Ipês, 37
Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os
dados são organizados em tabelas (Quadro 1). 2 5 Noite
Avenida Presidente Jânio
2 Abílio José Dias
Quadros, 357

3 Renata Oliveira Franco Rua Nove de Julho, 45

22 23 24

8
Quadro 1. Exemplo de tabelas em um SGBD relacional.
O modelo lógico do BD relacional deve definir quais as tabelas e o nome das Modelo Fisico Estimativa do tamanho do database;
colunas que compõem estas tabelas. Criaç
Criação de Espaç
Espaços de Tabelas;
Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o Nessa etapa serão desenhadas as estruturas lógicas do modelo Dimensional, Criaç
Criação de Tabelas;
seguinte: com as definições de tabelas fatos e tabelas dimensão, relacionamentos, Definiç
Definição de campos chaves e restriç
restrições;
Aluno(mat_aluno, nome, endereco) indexação, atributos de tabelas e implantação de regras. Nesse momento a Definiç
Definição de índices e estruturas especiais para os acessos;
Turma (cod_turma, sala, periodo) equipe projetista deverá considerar o uso do SGBD Relacional da instalação Consideraç
Considerações sobre carga de tabelas;
É importante salientar que os detalhes internos de armazenamento, por como depósito das informações do armazém de dados, ou o uso de um SGBD Aspectos de performance;
exemplo, não são descritos no modelo lógico, pois estas informações fazem Dimensional, caso essa seja a opção. Terminada a fase de especificação das Consideraç
Considerações sobre desenvolvimento de aplicaç
aplicações.
parte do modelo físico, que nada mais é que a tradução do modelo lógico para estruturas dimensionais, no plano conceitual, passamos a definir as tabelas
a linguagem do software escolhido para implementar o sistema. dentro do ambiente de gerência de Banco de Dados até atingir o estágio físico Observaç
Observações relevantes no projeto fí
físico:
do projeto de modelagem de dados. Vários aspectos relacionados ao projeto
físico de Banco de Dados deverão ser considerados para garantir performance Atentar para o tamanho limite de linhas para cada SGBD, tanto para para o nú
número
no acesso às estruturas relacionais ou dimencionais. de colunas permitido quanto para o tamanho em bytes;
No seu planejamento procure preocupar com os seguintes itens para um bom Atente para a definiç
definição default de valores nulos para campos, evitando a sua
desempenho da sua aplicação: definiç
definição (nulo) em campos da tabela principal;
A definiç
definição da restriç
restrição de chave primá
primária (unique
(unique not null)
null) forç
forçará
ará a unicidade
da linha (não haverá
haverá duplicaç
duplicações), não permitindo valores nulos, e definirá
definirá a
criaç
criação automá
automática de um índice;
25 26 27

9
Bancos de Dados Orientados a Objetos e Relacional-
Relacional-objeto
XML (SBDB Tamino) 2002 • Arquitetura de Banco de Dados
Modelo UML Exemplo de criaç
criação de tabelas no MS SQL Server SQL
1998
SGBD´s universais: Modelos OO/OR
1994 CREATE TABLE [dbo[dbo].[DEPARTAMENTO]
].[DEPARTAMENTO] ( [numero] [numeric
[numeric](18,
](18, 0) NOT Structured Query Language, ou Linguagem de Consulta Estruturada ou
Ontos, O2, Postgres NULL , [nome] [char
[char]] (10) COLLATE SQL_Latin1_General_CP850_CI_AI SQL, é uma linguagem de pesquisa declarativa para banco de dados relacional
1990
NOT NULL , [localizacao
[localizacao]] [char
[char]] (10) COLLATE (bases de dados relacionais). Muitas das características originais do SQL foram
Protótipos: Adaplex, Exodus, SDM 1986 SQL_Latin1_General_CP850_CI_AI NULL ) ON [PRIMARY] GO inspiradas na álgebra relacional.
DB2 1982 SQL é normalmente pronunciado em português como "esse-quê-ele", porém sua
pronúcia correta deveria se "síquel", do inglês "sequel", ou "alguma coisa que
Modelo ER 1978 INGRES, MUMPS, ORACLE segue outra coisa". SQL é uma brincadeira com o nome da primeira linguagem
de consulta QUEL.
1974 Sistema R (Relacional), DATACOM, ADABAS
Embora o SQL tenha sido originalmente criado pela IBM, rapidamente surgiram
1970 IDMS Rede vários "dialectos" desenvolvidos por outros produtores. Essa expansão levou à
necessidade de ser criado e adaptado um padrão para a linguagem. Esta tarefa
1966 IMS Hierárquico
foi realizada pela American National Standards Institute (ANSI) em 1986 e ISO
1962 TOTAL Rede limitado em 1987.
1958 Pré-SGBD: Estruturas de Acesso suportadas
pelo SO 28 29 30

10
 Exemplo Table 'T' Query Result
COMMIT envia todos os dados das mudanças permanentemente.
C C Select * from T C C ROLLBACK faz com que as mudanças nos dados existentes desde que o último
O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL-92. Foi 1 2 COMMIT ou ROLLBACK sejam descartadas.
1 2
revisto novamente em 1999 e 2003 para se tornar SQL:1999 (SQL3) e COMMIT e ROLLBACK interagem com áreas de controle como transação e
1 a 1 a
SQL:2003, respectivamente. O SQL:1999 usa expressões regulares de locação. Ambos terminam qualquer transação aberta e liberam qualquer cadeado
emparelhamento, queries recursivas e gatilhos (triggers). Também foi feita uma 2 b 2 b ligado a dados. Na ausência de um BEGIN WORK ou uma declaração
adição controversa de tipos não-escalados e algumas características de semelhante, a semântica de SQL é dependente da implementação.
C C Select C1 from T C
orientação a objeto. O SQL:2003 introduz características relacionadas ao XML,
sequências padronizadas e colunas com valores de auto-generalização 1 2 1
(inclusive colunas-identidade). 1 a 1
Tal como dito anteriormente, o SQL, embora padronizado pela ANSI e ISO, 2 b 2
possui muitas variações e extensões produzidos pelos diferentes fabricantes de
sistemas gerenciadores de bases de dados. Tipicamente a linguagem pode ser C C Select * from T where C1=1 C C
migrada de plataforma para plataforma sem mudanças estruturais principais. 1 2 1 2
Outra aproximação é permitir para código de idioma processual ser embutido e 1 a
interagir com o banco de dados. Por exemplo, o Oracle e outros incluem Java na 1 a
base de dados, enquanto o PostgreSQL permite que funções sejam escritas em 2 b
Perl, Tcl, ou C, entre outras linguagens.

31 32 33

11
DDL - Linguagem de Definição de Dados
O segundo grupo é a DDL (Data Definition Language - Linguagem de Definição
de Dados). Uma DDL permite ao usuário definir tabelas novas e elementos
associados. A maioria dos bancos de dados de SQL comerciais tem extensões DCL - Linguagem de Controle de Dados DQL - Linguagem de Consulta de Dados
proprietárias no DDL. O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de Embora tenha apenas um comando a DQL é a parte da SQL mais utilizada. O
Dados). DCL controla os aspectos de autorização de dados e licenças de comando SELECT é composta de várias cláusulas e opções, possibilitando
Os comandos básicos da DDL são: usuários para controlar quem tem acesso para ver ou manipular dados dentro elaborar consultas das mais simples as mais elaboradas.
CREATE cria um objeto (uma Tabela, por exemplo) dentro do base de dados. do banco de dados.
DROP apaga um objeto do banco de dados. Duas palavras-chaves da DCL: Exemplos:
GRANT - autoriza ao usuário executar ou setar operações. SELECT nome FROM pessoas;
Alguns sistemas de banco de dados usam o comando ALTER, que permite ao REVOKE - remove ou restringe a capacidade de um usuário de executar SELECT aP.codigo, aP.nome, aP.data_nascimento, aO.nome, aO.local FROM
usuário alterar um objeto, por exemplo, adicionando uma coluna a uma tabela operações. pessoas aP, objetos aO, WHERE aP.codigo = aO.codigo_pessoa
existente.. outros comandos DCL: and aP.codigo = ( SELECT codigo_pessoa FROM catalogo WHERE
outros comandos DDL: ALTER PASSWORD cod_catalogo = 5 );
ALTER TABLE CREATE SYNONYM
CREATE INDEX
ALTER INDEX
DROP INDEX
CREATE VIEW
DROP VIEW
34 35 36

12
Entrando um dado para uma tabela T, a query Select * from T resultará em
todos os elementos de todas as filas da tabela.
Com a mesma tabela, a query Select C1 from T resultará nos elementos da
coluna C1 de todas as filas da tabela.
E a query Select * from T where C1=1 resultarão em todos os elementos de
todas as filas onde o valor de coluna C1 é '1'.
37
Palavras-chaves em SQL
DML - Linguagem de Manipulação de Dados
Primeiro há os elementos da DML (Data Manipulation Language - Linguagem de
Manipulação de Dados). A DML é um subconjunto da linguagem usada para
selecionar, inserir, atualizar e apagar dados.
SELECT é o comumente mais usado do DML, comanda e permite ao usuário
especificar uma query como uma descrição do resultado desejado. A questão não
especifica como os resultados deveriam ser localizados.
INSERT é usada para somar uma fila (formalmente uma tupla) a uma tabela
existente.
UPDATE para mudar os valores de dados em uma fila de tabela existente.
DELETE permite remover filas existentes de uma tabela. BEGIN WORK (ou
START TRANSACTION, dependendo do dialeto SQL) pode ser usado para
marcar o começo de uma transação de banco de dados que pode ser completada
ou não.
38 39
13
40 41 42

14
43 44 45

15
46 47 48

16
49 50 51

17
52 53 54

18
55 56 57

19
58 59 60

20
 •TENDENCIAS

Com relação a Banco de dados, o mercado mundial aponta para os

bancos que suportem modelos que sejam flexiveis.
Estes modelos devem interagir com os modelos atuais(relacionais) e com
os novos modelos(Multi Dimensionais).
O Oracle e Microsoft estão correndo atrás destas tecnologias, sendo que
no Oracle 10G já existe recursos que suportam dimensionamento, o
SqlServer 2005, segundo fontes da própria Microsoft terá internamento
todo um tratamento especial para DW e BI.

61 62 63

21
 Porquê usar UML ???

•UML – Alguns Conceitos Automatizar produção de software

Adicionar qualidade e reduzir custos

Idealizada em 1997 para diagramação de design de software (Rational
Rose). Gerenciar a complexidade de sistemas quando estes crescem em escopo
UML é uma linguagem para especificação, visualização, construção e e escala
documentação de software.
Resolver problemas de arquitetura:
Tecnicamente dizendo, a UML (Unified Modeling Language) é a junção Distribuição física
das três mais conceituadas linguagens de modelagem orientados a Concorrência
objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh). Segurança
Tolerância a falhas
Utilizada para modelagem de software Etc.

Visa gerar uma visão intermediária entre o cliente, o analista, o

programador e demais envolvidos no desenvolvimento do software

64 65 66

22
• Diagramas de Comportamento
• Diagrama de Caso de Uso
• Diagrama de Atividades
• Diagramas de Interação
• Diagrama de Estado
• Diagramas Estruturais
• Diagrama de Classe
• Diagrama de Pacotes
• Diagrama de Componentes
• Diagramas de Implementação
• Diagrama de Classes
• Diagrama de Componentes
• Diagrama de Implantação
67
•Quando usar

Diagrama de Caso de Uso Geralmente utilizados no início dos projetos por dar uma visão dos
Principais Componentes requisitos do sistema.
– Ator – usuá
usuário ou outro sistema que interage com o •Como usar
sistema em questão (agentes externos ao sistema).
sistema). Identifica os passos do ator para efetuar aquela ação no sistema e
– Caso de Uso – representa uma ação de um Ator no gera os casos de uso.
sistema

Exemplo
O cliente quer efetuar uma compra por telefone e deve seguir os
seguintes passos:
passos:
– Procurar produto no catá
catálogo
– Ligar para o representante
– Saber quais as formas de transporte
– Saber as formas de pagamento
– Confirmar a compra e pegar o número do pedido para
acompanhamento
68 69
23

Diagrama de Classe
Diagrama de Classe

Um dos diagramas mais utilizados.

utilizados. Um dos diagramas mais utilizados.
utilizados.

Representa Classes e interfaces do sistema e seus relacionamentos,

relacionamentos, Representa Classes e interfaces do sistema e seus relacionamentos,
relacionamentos,
bem como caracteristicas (atributos)
atributos) e métodos.
todos. bem como caracteristicas (atributos)
atributos) e métodos.
todos.
Podem representar objetos do sistema,
sistema, se tornando Diagrama de Podem representar objetos do sistema,
sistema, se tornando Diagrama de
Objetos. Objetos.

Quando usar
Quando usar
– Usado em qualquer sistema orientado a objetos – Usado em qualquer sistema orientado a objetos
– Deve-
Deve-se usar para descrever as classes do sistema e a – Deve-
Deve-se usar para descrever as classes do sistema e a
relaç
relação entre eles relaç
relação entre eles

Como usar
Como usar
– É um dos diagramas mais difídifíceis – É um dos diagramas mais difí difíceis
– Tentar desenhar as classes com seus atributos e métodos – Tentar desenhar as classes com seus atributos e métodos
– Procurar ver como os objetos interagem entre si.
si. – Procurar ver como os objetos interagem entre si.
si.

70 71 72

24

Tipos de composições:

Diagrama de classes para representar a relaç
relação entre:
entre: Meio de
– Associação transporte,
transporte, Carro,
Carro, Barco e Avião.
Avião.
Diagrama de Estado
– Generalização / Herança
– Agregação Usado para representar todas as possibilidades de estado de um
determinado objeto
– Interfaces / Realizações
Cada diagrama representa os estados de objetos de uma única
– Visibilidade classe.
Pode ser usado em conjunto com outros diagramas como: Diagrama
de Interação e Diagrama de Atividade.

Quando usar

É usado quando desejamos saber o comportamento do objeto

em vários Casos de uso do sistema.
Deve ser usado quando é necessário ter
Conhecimento do comportamento do objeto em todo o sistema

73 74 75

25

Como usar
Resumindo : • Arquitetura de Aplicações
– Identifica os estados do objeto e as condiç
condições para a transiç
transição
entre eles.
eles. O uml é uma ferramenta muito importante,
importante, pois permite conceituar um
sistema,
sistema, quer seja ele computacional ou não.
não. Para se realizar um projeto baseado em aplicações distribuídas é preciso tomar
– Começ
Começa com o estado inicial do objeto (quando este é criado).
criado). decisões sobre a arquitetura lógica, física e também decidir quais tecnologias e
Hoje em dia não se fala de OOP(Programaç
OOP(Programação Orientada e Objetos),
Objetos), a infraestrutura usada para estas funcionalidades. Para tomar estas decisões
sem citar UML. eficientemente, devemos conhecer bem os processos de negócio que as
aplicações estarão realizando (requerimentos funcionais), e os níveis de
escalabilidade, disponibilidade, segurança e sustentabilidade (requerimentos
operacionais).
Os componentes que realizam funções similares são organizados e agrupados
dentro de camadas específicas. Um bom entendimento dos diferentes tipos de
componentes que são comumente utilizados em aplicações distribuídas ajudará
a projetar soluções melhores.
Para um projeto com aplicações distribuídas, é preciso decidir como acessar e
representar os dados de negócio associados com sua aplicação. Maneira de
expor, persistir e passar dados entre as camadas da aplicação.

76 77

26
Arquitetura da Aplicação
1 - Prover a interação do usuário com as aplicações do sistema. Os
componentes de interface são implementados usando WebForms (asp.net),
controles de validação e formatação de dados e controles customizados.
2 - Interface que oferece suporte à comunicação e disponibilizacão da regra de
negócio como serviço.
3 - Gerencia a troca de mensagens e transações entre instâncias de objetos,
além de controlar o fluxo de processos de negócios que envolvem seqüências
especificas.
4 - Implementa e Executa a lógica do negócio da aplicação (Regras de
Negócio).
5 - Organização e definição dos dados que serão passados entre componentes,
essas entidades são representados por estruturas de dados utilizando Datasets,
Datareaders, XML, entre outros.
6 - Encapsula a lógica de acesso a dados (CRUD).
7 - Disponibiliza funcionalidades da aplicação para serviços externos
(WebServices).
8 - Componente genérico utilizado para acesso a dados. Gerencia conexões,
executa comandos, otimiza o acesso a dados e cache.
9,10,11 - Componentes para gerência de exceções, comunicação com serviços e
aplicações, autenticação e autorização.
A arquitetura apresentada acima está sendo utilizada para o desenvolvimento do
Sistema de Ouvidoria e Informações do Governo do Distrito Federal pela
CODEPLAN, o sistema abrangerá todos os órgãos do GDF.
27
 • Arquitetura de Tecnologia
A metodologia de desenvolvimento adotada (PDS_UML) no decorrer de todo o
ciclo do projeto utiliza a UML como linguagem universal para execução de
todas as fases, atividades e produtos inerentes ao processo, de modo a
formalizar a sua especificação.
O método, baseado no RUP, está estruturado em macroatividades (tarefas)
definidas que são executadas iterativamente até a conclusão de cada
processo. Cada macroatividade irá gerar um produto (artefato de saída) que
será utilizado pela macroatividade subseqüente.
Maiores informações sobre a arquitetura descrita, assim como padrões e
práticas estarão disponíveis no DNAUG - Dot Net Architect User Group, um
grupo de usuários intencionados a discutir e disseminar a tecnologia.
Visão geral do Framework .Net
A plataforma .Net é um conjunto de tecnologias que foi projetado para mudar
o conceito de desenvolvimento de aplicações para internet. A plataforma .Net
contempla o desenvolvimento de aplicações escaláveis e distribuídas,
fornecendo novas possibilidades para construir aplicações baseadas em Web
Services suportando a infra-estrutura da internet, incluindo HTTP, XML e
SOAP.
A plataforma .Net basicamente inclui:
.Net Framework;
.Net Building Block Services;
Visual Studio .Net
.Net Enterprises Services(2003 family)
A .NET framework consiste de duas partes principais: a CLR - Common
Language Runtime e a .NET Framework class library. A primeira é a
responsável pela independência de linguagem de programação e a segunda
disponibiliza os principais recursos de programação, além de incluir os três
principais componentes: ASP.NET, Windows Forms e o ADO.NET.
28
 A Disponibilidade de um serviço é definida como o percentual do tempo em que
• Arquitetura de Organização o serviço ficou em operação. Ou seja,
SLA é um documento formal, negociado entre as partes, na contratação de um Os requisitos típicos que devem fazer parte de um SLA para um serviço de
serviço de TI ou Telecomunicações. O SLA é colocado geralmente como telecomunicações são: Disponibilidade = 1- Indisponibilidade
anexo do contrato e tem por objetivo especificar os requisitos mínimos Disponibilidade do Serviços
aceitáveis para o serviço proposto. O não cumprimento do SLA implica em Compromissos com tempos e prazos No exemplo acima a Disponibilidade é 99,73%.
penalidades, estipuladas no contrato, para o provedor do serviço. Requisitos de desempenho
EX A tabela a seguir apresenta alguns valores de Disponibilidade Anual em função
Um SLA pode cobrir itens como qualidade do serviço, critérios de cobrança, Um serviço de telecomunicações é um serviço de provimento contínuo e do tempo que um serviço ficou indisponível no ano. Uma tabela mais completa
provisionamento, processo de atendimento e relatórios fornecidos ao cliente. ininterrupto 24 horas por dia e sete dias por semana. Desta forma a pode ser encontrada na seção de referência rápida do Teleco.
disponibilidade do serviço passa a ser um parâmetro chave de um SLA para
Disponibilidade A (%) Tempo indisponível em um ano
Um SLA deve conter parâmetros objetivos e mensuráveis os quais o provedor serviços de telecomunicações.
99,9999999 0,03seg
de serviços se compromete a atender. 99,999999 0,32seg
A Indisponibilidade de um serviço é definida como o percentual do tempo
99,99999 3,15seg
Este tutorial terá por foco a apresentação dos parâmetro típicos de um SLA em que o serviço ficou fora de operação. Por exemplo, a indisponibilidade
99,9999 31,54seg
utilizado na contratação de serviços de telecomunicações como o aluguel de anual de um serviço que ficou fora de operação por um dia durante o ano é
99,999 5,26min
uma linha dedicada de dados TDM ou um circuito virtual através de uma rede de 1/365 = 0,27%.
99,99 52,56min
de comutação de pacotes. 99,9 8,76hrs
99,0 3,65dias
90 36,50dias

29
A tabela anterior mostra o impacto que um nove a mais na disponibilidade de
um serviço provoca na redução do tempo em que ele está indisponível no ano.
É preciso no entanto balancear a exigência de disponibilidade no SLA com o
custo do serviço. O aumento da disponibilidade é conseguido com o aumento
dos níveis de redundância e eliminação de pontos de falha simples, o que
torna mais caro o serviço.
A disponibilidade de um serviço é estimada a partir da disponibilidade das
suas partes. A disponibilidade de um serviço que consiste de partes em série é
dada pelo produto da disponibilidade das partes.
Exemplo
Contratação de um circuito de longa distância entre São Paulo e Rio de
Janeiro composto de:
Acesso local SP + Circuito longa distância + Acesso local RJ
Se cada um dos circuitos tiver uma disponibilidade 99,9% a disponibilidade do
serviço será:
99,9% x 99,9% x 99,9% = 99,7%
Ou seja, se um circuito de longa distância com 99,9% de disponibilidade
implicava em ficar 8,76 horas fora de operação em um ano, ao se considerar o
serviço completo com os acessos a disponibilidade caiu para 99,7% e o tempo
de indisponibilidade em um ano aumentou para 26,28 horas. Na seção anterior
tratou-se da disponibilidade de um serviço considerando-se o tempo que ele
está em operação ou não. É preciso no entanto definir o serviço e a quais
requisitos mínimos ele deve atender para ser considerado operacional. Estes
requisitos envolvem principalmente a especificação, conforme o caso, de
parâmetros como:
Velocidade (Taxa de bits)
Taxa de erros
Atraso (no caso de redes de pacotes)
A decisão se um sistema está operacional ou não, o que caracteriza uma
indisponibilidade do sistema, envolve uma zona cinzenta em que o serviço não
atende a todos os requisitos de desempenho mas ainda está em condições de
ser utilizado pelo cliente. É importante, portanto, definir níveis de degradação do
serviço e parâmetros de disponibilidade para estes níveis de degradação.
Os enlaces rádios, por exemplo, têm definido em norma objetivos de
disponibilidade do enlace associadas a várias taxas de erro e garantindo uma
disponibilidade final ao enlace de 99,995%. O que alguns provedores de serviço
não consideram no entanto é que a disponibilidade do serviço para o cliente
deve envolver a disponibilidade do enlace e a disponibilidade dos equipamentos
rádio nas duas pontas e que formam uma associação série com a
disponibilidade do enlace.
Estas considerações são de maior importância ainda quando o serviço
contratado é uma rede com vários pontos de acesso e a falha de um deles pode
não ser considerada uma indisponibilidade do serviço como um todo e sim um
serviço com nível de desempenho degradado.
30
 Uma das maneiras de se levar em conta no SLA níveis de degradação é
estabelecer um fator de degradação do serviço para multiplicar o tempo de
Tipicamente o SLA estabelece também uma série de tempos, como:
Software Produzido
indisponibilidade conforme o nível de degradação, como exemplificado na tabela a
Tempo para recuperar uma falha, ou tempo máximo de indisponibilidade. •Análise - o quê o sistema deve fazer.
Tempo para provisionamento do serviço.
seguir.
Normalmente, o SLA exige também que o prestador de serviço tenha um centro de Documento de Especificação
atendimento funcionando 24 horas por dia e 7 dias por semana, um sistema de
Tipo de Falha
Fator de Degradação do Serviço acompanhamento de problemas (Trouble ticket) e relatórios mensais para •Projeto - Utiliza o documento de especificação
acompanhamento do desempenho e disponibilidade do serviço.
Serviço totalmente indisponível 1
e define como o comportamento especificado
Finalmente, o SLA deve representar um acordo entre as partes onde prevaleça o será obtido
Taxa de erros 20% acima do
0,9 bom senso. A ausência de um SLA, ou SLA frouxo torna difícil cobrar qualidade de
estabelecido serviço de um provedor. Por outro lado um SLA muito rigoroso pode levar a um alto Documento de Arquitetura
custo do serviço ou ao provedor fazer promessas que não conseguirá depois
Velocidade menor que 50% do requisito 0,6
cumprir.
•Implementação - Utiliza uma linguagem de
programação
Código
93

31
• Sistemas sem documentação Necessidade de Manutenç
Manutenção no
Será possível ????
• Dificuldade de manutenção Software
• Erros gerando outros erros •O quê fazer ???
Na construção civil, ok
• Código duplicado E com sistemas de
•Quem poderá software?
me ajudar ????

•Cadê o programador ????

•O quê será que ele quis
fazer aqui?????
94 95 96

32
 Engenharia Reversa de Sistema

Muitas pessoas têm uma visão idealizada e encantada do que é a Engenharia (1) Melhore o entendimento do software
Engenharia Reversa Reversa e o que ela pode fazer. Para muitos quando se fala de Engenharia
Reversa, se pensa numa coisa mágica que vai resolver todos os problemas de (2) Prepare ou melhore o software em si, sua manutenção,
o
gic documentação e manutenção de software.
seu reuso e sua extensão
Ló -Pequena introdução à Engenharia de Software
e lo Para entender o que vai seguir, você precisa saber o que é a engenharia
d Chikofsky e Cross definem reengenharia:
Mo de software e como se desenvolve (ou por ser exato como deveria se
desenvolver) um sistema hoje em dia. Saiba então que com a “o exame e a alteração de um sistema para reconstituí-lo de
complexidade que o sistemas de software atingem hoje, não é mais
possível de ir programando sem preparação nenhuma. É preciso pensar uma nova forma, seguida pela sua implementação “
muito antes (levantamento dos requisitos, análise, projeto, ...) e
documentar todo o que se faz e diz. Isso parece (até é) muito chato, mas é Sinônimos de Reengenharia: melhoramento, renovação,
imprescindível para não cair em problemas muito mais chatos depois.
Quem conhece isso sabe que pode ser a diferença entre a vida e a morte
modernização, engenharia de re-desenvolvimento,
Reengenharia de uma empresa... engenharia de reuso

97 99

33
-Vamos fazer Engenharia Reversa
Processo de Reengenharia
Para escapar dessa tarefa considerada até útil mas certamente não
digna de se gastar muito tempo e dinheiro com ela, muitos gerentes Conhecimento
pensam o seguinte: "Não vamos perder tempo com essas frescuras. do Usuário
Vamos lá desenvolvendo, mão à obra. Depois a gente faz Engenharia
Reversa e reconstrói toda essa documentação!". Os inglofones têm uma
expressão para isso: "Famous last words"*. O famoso jeitinho brasileiro
entra em ação e vamos dispensar todas as regras desses gringos. A Sistema Legado Engenharia
resposta a esta idéia poderia ser de rir se não fosse trágico (estou (código fonte)
relatando aqui casos reais). Todas essas regras chatas de
Eng. de
desenvolvimento e documentação não foram criadas por pessoas
Software
ociosas a procura de um passa tempo. Elas existem porque
comprovadamente permitem de obter, não melhores resultados, mas
resultados, ponto. E quem não faz pode se preparar para um futuro
carregado...
Reengenharia
Documentação?
-Não tem mágica
Não tem mágica, a engenharia reversa não vai criar de repente um monte de
modelos que vão permitir entender aquele sistema facilmente. Primeiro, se
fosse tão fácil de criar a documentação de um sistema, ninguém faria, tudo
Re- mundo usaria a tal de engenharia reversa. Segundo, se um sistema foi
Documentação desenvolvido sem nenhuma documentação, a probabilidade é que ele vai
estar tão mal estruturado que nenhuma força humana vai conseguir extrair
alguma coisa coerente dele. Terceiro, a engenharia reversa é um trabalho
Reversa muito complexo e muito trabalhoso, muito mais do que desenvolver
corretamente com toda a documentação que precisa um sistema. Só se
+ recorre à ela no caso de desespero, quando não dá mais para agüentar uma
Recuperação do
n-ésima correção de bug que introduziu mais problemas do que ela resolveu
Projeto
(ou quando um gerente prudente está vendo que isso poderia acontecer
mais rapidamente que ele queria)...
=
101
34
Requisitos Quando uma pessoa compra um software, seja pela internet ou em CD-ROM, Reengenharia:: Sem mudança de funcionalidade,
(restrições, Implementação ele está gravado como um arquivo binário. O arquivo binário é gerado a partir mesmo paradigma com Mudança de Linguagem
objetivos, Projeto do código-fonte, que é escrito pelo programador em uma linguagem mais
regras do negócio) acessível que o código de máquina. Esse arquivo pode ser compreendido pelo de Programação
Engenharia Engenharia chip do computador e executado. De fato, ele é tudo o que o computador
Avante Avante precisa para executar o programa.
Porém o código binário é difícil - quase impossível - de ser compreendido por
Engenharia Engenharia
seres humanos. Essa peculiaridade da programação de computadores é que
Sistema Existente
Reversa Reversa
permite, no mundo atual da informática, a preservação do direito autoral sobre
Projeto software: se você faz um programa e o vende na forma de arquivos binários,
Projeto Recuperado
Recuperado ninguém conseguirá abrir-los e ver como o programa funciona. Com isso, o
código em que se escreveu o programa, conhecido como código-fonte, é Já existia Recuperado do
mantido sob domínio da empresa. código legado
Isto funciona assim para a grande maioria dos usuários comuns de
Reengenharia Reengenharia Modelo Lógico
(Renovação) computadores.
Reestruturação Reestruturação (Renovação) Reestruturação

Relacionamento entre os termos

Linguagem
Escolhida
103 105

35
Mas uma minoria de programadores e engenheiros de computação consegue
abrir arquivos binários e modificar programas através da técnica conhecida como
"engenharia reversa".
Resumidamente, a engenharia reversa é uma tentativa de aprender como um
software funciona estudando-o em uma linguagem computacional "primitiva"
(muito próxima à linguagem binária da máquina) conhecida como assembly, ou
assembler. O assembly pode ser entendido como uma tradução quase literal de
cada uma das pequenas instruções que compõem um programa de computador.
É detalhado e enfadonho, se comparado às linguagens modernas mais
abstratas, como o C++ ou o Pascal.
É possível fazer a conversão entre o binário e o Assembler. Isso gera um código
difícil de compreender, mas não impossível. Se você quiser ver um exemplo
disso em tempo real, use o programa Debug, disponível no MS-DOS.
No entanto, há dois aspectos que tornam a engenharia reversa problemática: o
primeiro é que ela é proibida em alguns países, por ser entendida como violação
de direitos autorais.
O outro problema é mais sutil: um programa é uma tradução, para o
computador, de fórmulas matemáticas conhecidas como algoritmos, cujo
patenteamento é discutível, como se fosse possível também patentear a lei Reengenharia com Mudança de Orientação
da gravitação de Newton, que é igualmente uma fórmula matemática. Ou
ainda a fórmula de Báskara, que resolve equações do segundo grau. Um
software é um conjunto de algoritmos escritos em uma forma que o
computador entende e executa como instruções, aplicando-as aos dados
que o usuário fornece. Orientada a
Nos EUA e Europa a briga envolve grandes companhias, como a Microsoft
e comunidades de programadores de software livre unidos pela internet.
Procedimentos
Destas, uma das mais atuantes é a do Linux, forte na Europa, onde há
muita resistência aos produtos Microsoft, e a Free Software Foundation que
existe desde 1985, distribuindo software livre, sistemas operacionais
inteiros, totalmente gratuitos
Orientada a Objetos
108
36
• O inter-relacionamento das Arquiteturas

37
38
 • Arquitetura de tecnologia
Segundo Terry, para um projeto bem sucedido é necessário conhecer bem
três coisas: Notação, Processo e Ferramenta. Você pode saber uma
notação, mas se não souber usar (Processar), terá falha; Você pode ter um
ótimo processo, mas se não souber comunicar (Notação), terá falha e
finalmente se não souber documentar seu trabalho (Ferramenta), terá
falha.Nos artigos anteriores apresentei a notação, depois desta breve
introdução vamos falar sobre ferramentas.
• Arquitetura de tecnologia
O que são Ferramentas CASE?
A sigla CASE significa “Computer-Aided Software Engineering”. Traduzindo
para um bom português: “Engenharia de Software Auxiliada por
Computador”.
Uma ferramenta CASE é um aplicativo que auxilia os profissionais envolvidos
na tarefa de produzir sistemas. O tipo de “ajuda” que a ferramenta fornece,
depende exclusivamente da proposta do fabricante. Por este motivo, as
ferramentas se dividem em três categorias. São elas:
1. Lower CASE - ferramentas de codificação (front-end);
2. Upper CASE - ferramentas de análise, projeto e implementação;
3. Integrated CASE - união de Upper e Lower CASE.
39
Um dos componentes indispensáveis de uma ferramenta CASE é a
modelagem visual, ou seja, a possibilidade de representar, através de modelos
gráficos, o que está sendo definido. No nosso caso, análise orientada a
objetos através da UML.
Como escolher a ferramenta?
Antes de iniciar este tópico, gostaria de esclarecer que, a abordagem deste
artigo é puramente técnica. Não vamos levar em consideração os fatores:
Preço e Licença. Também não vou comparar as principais ferramentas do
mercado. Entendo que esta decisão deve ficar a critério do leitor, depois de
realizar muita pesquisa no mercado.
O primeiro passo é saber qual será o uso da ferramenta na sua empresa. Isto
é, ferramenta para codificação ou ferramenta para análise. Como existem
inúmeras tarefas no desenvolvimento e várias ferramentas no mercado,
responder esta pergunta não será uma atividade fácil.
Outro fator importante é que a ferramenta deve ser aderente ao conceitos
(análise estruturada ou orientação a objetos, por exemplo) de trabalho na sua
empresa.Como estes conceitos e técnicas evoluem no tempo. È importante
que a ferramenta escolhida suporte várias técnicas ou esteja preparada para
evoluir (UPGRADE).
Vale a pena lembrar que, as perguntas abaixo são muito importantes na escolha
da ferramenta:
01. O time de desenvolvimento está preparado tecnicamente para trabalhar com
ferramentas case?
02. Preciso capacitar os recursos de minha empresa?
03. A metodologia de desenvolvimento em minha empresa está “amadurecida”?
Na prática, as ferramentas existentes no mercado possuem as características
colocadas acima, destaco os seguintes pontos:
- Desenvolvidas sobre uma arquitetura inteligente (customizável);
- Possuem "facilitadores" para auxiliar nas tarefas repetitivas;
- Verificação da consistência através de regras específicas;
- Geração de relatórios para acompanhamento do trabalho;
- Interfaces com outros aplicativos de desenvolvimento.
Em resumo, as ferramentas CASE automatizam uma grande variedade de tarefas:
Geração de documentação,Testes, Engenharia Reversa, Geração de código,
Geração de Relatórios entre outras atividades. Por este motivo, também são
conhecidas como “Ferramentas de Produtividade”.
Escolher a melhor ferramenta não é uma tarefa simples. Cada empresa tem
necessidades e problemas específicos a serem resolvidos.
Ferramentas????
“Uma ferramenta CASE não é a solução para todos os problemas da
organização. A organização deve ter certeza de estar pronta para a nova
ferramenta. Desta forma uma ferramenta só deveria ser selecionada após a
definição do processo de desenvolvimento, dos métodos e de ter sido utilizada
num projeto piloto.” (Reid).
Visite o site de algumas ferramentas importantes no mercado. Você poderá
encontrar detalhes e características que atendam a sua empresa.
Rational Rose
System Architect
Enterprise Architect
Microsoft VISIO
40
BIBLIOGRAFIA
-Rosângela Penteado
Departamento de Computação
Universidade Federal de São Carlos

-www.ime.usp.br

-Melissa Lemos
Departamento de Computação
Puc Rio
-Carlos Henrique C. Negrão
-www.juliano.com.br

121

41