Modelagem De Sistemas

Curso

Gestão da Informação Modelagem de Sistemas de Informaç Informação

1. Arquiteturas de Sistemas de Informações 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, 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 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 clienteservidor 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.

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

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).

• Modelos 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.

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 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).

mat_aluno 1

22

nome Cecília Ortiz Rezende

cod_turma

sala

periodo

1

8

Manhã

2

5

Noite

endereco Rua dos Ipês, 37

2

Abílio José Dias

Avenida Presidente Jânio Quadros, 357

3

Renata Oliveira Franco

Rua Nove de Julho, 45

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 colunas que compõem estas tabelas. Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o seguinte: Aluno(mat_aluno, nome, endereco) Turma (cod_turma, sala, periodo) É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema.

Estimativa do tamanho do database; Criaç Criação de Espaç Espaços de Tabelas; Criaç Criação de Tabelas; Definiç Definição de campos chaves e restriç restrições; Definiç Definição de índices e estruturas especiais para os acessos; Consideraç Considerações sobre carga de tabelas; Aspectos de performance; Consideraç Considerações sobre desenvolvimento de aplicaç aplicações.

Modelo Fisico Nessa etapa serão desenhadas as estruturas lógicas do modelo Dimensional, com as definições de tabelas fatos e tabelas dimensão, relacionamentos, indexação, atributos de tabelas e implantação de regras. Nesse momento a equipe projetista deverá considerar o uso do SGBD Relacional da instalação como depósito das informações do armazém de dados, ou o uso de um SGBD Dimensional, caso essa seja a opção. Terminada a fase de especificação das estruturas dimensionais, no plano conceitual, passamos a definir as tabelas dentro do ambiente de gerência de Banco de Dados até atingir o estágio 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 no acesso às estruturas relacionais ou dimencionais. No seu planejamento procure preocupar com os seguintes itens para um bom desempenho da sua aplicação:

25

Observaç Observações relevantes no projeto fí físico: Atentar para o tamanho limite de linhas para cada SGBD, tanto para para o nú número de colunas permitido quanto para o tamanho em bytes; Atente para a definiç definição default de valores nulos para campos, evitando a sua 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; 26

27

9

Bancos de Dados Orientados a Objetos e RelacionalRelacional-objeto XML (SBDB Tamino) 2002 Modelo UML 1998

SGBD´s universais: Modelos OO/OR Ontos, O2, Postgres

1994

1990

Protótipos: Adaplex, Exodus, SDM 1986

• Arquitetura de Banco de Dados Exemplo de criaç criação de tabelas no MS SQL Server

SQL

CREATE TABLE [dbo ].[DEPARTAMENTO] ( [numero] [numeric ](18, 0) NOT [dbo].[DEPARTAMENTO] [numeric](18, NULL , [nome] [char [char]] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [localizacao [localizacao]] [char [char]] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL ) ON [PRIMARY] GO

Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma linguagem de pesquisa declarativa para banco de dados relacional (bases de dados relacionais). Muitas das características originais do SQL foram inspiradas na álgebra relacional. 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 segue outra coisa". SQL é uma brincadeira com o nome da primeira linguagem de consulta QUEL. Embora o SQL tenha sido originalmente criado pela IBM, rapidamente surgiram 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 foi realizada pela American National Standards Institute (ANSI) em 1986 e ISO em 1987.

DB2 1982 Modelo ER 1978 INGRES, MUMPS, ORACLE 1974 Sistema R (Relacional), DATACOM, ADABAS 1970 IDMS Rede 1966 IMS Hierárquico 1962

TOTAL Rede limitado

1958 Pré-SGBD: Estruturas de Acesso suportadas

pelo SO

28

29

30

10

Exemplo

O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL-92. Foi revisto novamente em 1999 e 2003 para se tornar SQL:1999 (SQL3) e SQL:2003, respectivamente. O SQL:1999 usa expressões regulares de emparelhamento, queries recursivas e gatilhos (triggers). Também foi feita uma adição controversa de tipos não-escalados e algumas características de orientação a objeto. O SQL:2003 introduz características relacionadas ao XML, sequências padronizadas e colunas com valores de auto-generalização (inclusive colunas-identidade). Tal como dito anteriormente, o SQL, embora padronizado pela ANSI e ISO, possui muitas variações e extensões produzidos pelos diferentes fabricantes de sistemas gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de plataforma para plataforma sem mudanças estruturais principais. Outra aproximação é permitir para código de idioma processual ser embutido e interagir com o banco de dados. Por exemplo, o Oracle e outros incluem Java na base de dados, enquanto o PostgreSQL permite que funções sejam escritas em Perl, Tcl, ou C, entre outras linguagens. 31

Table 'T' C 1

C 2

1 2 C 1

C 2

1

a

2

b

C 1

C 2

1

a

2

b

Query Select * from T

Result C 1

C 2

a

1

a

b

2

b

Select C1 from T

COMMIT envia todos os dados das mudanças permanentemente. ROLLBACK faz com que as mudanças nos dados existentes desde que o último COMMIT ou ROLLBACK sejam descartadas. COMMIT e ROLLBACK interagem com áreas de controle como transação e locação. Ambos terminam qualquer transação aberta e liberam qualquer cadeado ligado a dados. Na ausência de um BEGIN WORK ou uma declaração semelhante, a semântica de SQL é dependente da implementação.

C 1 1 2

Select * from T where C1=1

C 1

C 2

1

a

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 proprietárias no DDL.

DCL - Linguagem de Controle de Dados O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de Dados). DCL controla os aspectos de autorização de dados e licenças de usuários para controlar quem tem acesso para ver ou manipular dados dentro do banco de dados. Duas palavras-chaves da DCL: GRANT - autoriza ao usuário executar ou setar operações. REVOKE - remove ou restringe a capacidade de um usuário de executar operações. outros comandos DCL: ALTER PASSWORD CREATE SYNONYM

Os comandos básicos da DDL são: CREATE cria um objeto (uma Tabela, por exemplo) dentro do base de dados. DROP apaga um objeto do banco de dados. Alguns sistemas de banco de dados usam o comando ALTER, que permite ao usuário alterar um objeto, por exemplo, adicionando uma coluna a uma tabela existente.. outros comandos DDL: ALTER TABLE CREATE INDEX ALTER INDEX DROP INDEX CREATE VIEW DROP VIEW 34

DQL - Linguagem de Consulta de Dados Embora tenha apenas um comando a DQL é a parte da SQL mais utilizada. O comando SELECT é composta de várias cláusulas e opções, possibilitando elaborar consultas das mais simples as mais elaboradas. Exemplos: SELECT nome FROM pessoas; SELECT aP.codigo, aP.nome, aP.data_nascimento, aO.nome, aO.local FROM pessoas aP, objetos aO, WHERE aP.codigo = aO.codigo_pessoa and aP.codigo = ( SELECT codigo_pessoa FROM catalogo WHERE cod_catalogo = 5 );

35

36

12

Palavras-chaves em SQL

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'.

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.

37

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 ??? Automatizar produção de software

•UML – Alguns Conceitos

Adicionar qualidade e reduzir custos

Idealizada em 1997 para diagramação de design de software (Rational Rose). UML é uma linguagem para especificação, visualização, construção e documentação de software.

Gerenciar a complexidade de sistemas quando estes crescem em escopo e escala Resolver problemas de arquitetura: Distribuição física Concorrência Segurança Tolerância a falhas Etc.

Tecnicamente dizendo, a UML (Unified Modeling Language) é a junção das três mais conceituadas linguagens de modelagem orientados a objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh). Utilizada para modelagem de software 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

•Quando usar Geralmente utilizados no início dos projetos por dar uma visão dos requisitos do sistema. •Como usar Identifica os passos do ator para efetuar aquela ação no sistema e gera os casos de uso.


Diagrama de Caso de Uso Principais Componentes

– Ator – usuá usuário ou outro sistema que interage com o sistema em questão (agentes externos ao sistema). sistema). – Caso de Uso – representa uma ação de um Ator no sistema

Diagramas Estruturais • Diagrama de Classe • Diagrama de Pacotes • Diagrama de Componentes


Exemplo O cliente quer efetuar uma compra por telefone e deve seguir os seguintes passos: passos:

Diagramas de Implementação • Diagrama de Classes • Diagrama de Componentes • Diagrama de Implantação

– – – – – 67

68

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 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, bem como caracteristicas (atributos) atributos) e métodos. todos. Podem representar objetos do sistema, sistema, se tornando Diagrama de Objetos.
Quando usar – Usado em qualquer sistema orientado a objetos – DeveDeve-se usar para descrever as classes do sistema e a relaç relação entre eles
Como usar – É um dos diagramas mais difí difíceis – Tentar desenhar as classes com seus atributos e métodos – Procurar ver como os objetos interagem entre si. si. 70

Representa Classes e interfaces do sistema e seus relacionamentos, relacionamentos, bem como caracteristicas (atributos) atributos) e métodos. todos. Podem representar objetos do sistema, sistema, se tornando Diagrama de Objetos.
Quando usar – Usado em qualquer sistema orientado a objetos – DeveDeve-se usar para descrever as classes do sistema e a relaç relação entre eles
Como usar – É um dos diagramas mais difí difíceis – Tentar desenhar as classes com seus atributos e métodos – Procurar ver como os objetos interagem entre si. si. 71

72

24




Tipos de composições: – Associação – Generalização / Herança – Agregação – Interfaces / Realizações – Visibilidade




Diagrama de classes para representar a relaç relação entre: entre: Meio de transporte, transporte, Carro, Carro, Barco e Avião. Avião.


Diagrama de Estado Usado para representar todas as possibilidades de estado de um determinado objeto Cada diagrama representa os estados de objetos de uma única 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

• Arquitetura de Aplicações


Resumindo :


Como usar – Identifica os estados do objeto e as condiç condições para a transiç transição entre eles. eles. – Começ Começa com o estado inicial do objeto (quando este é criado). criado).

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 decisões sobre a arquitetura lógica, física e também decidir quais tecnologias e a infraestrutura usada para estas funcionalidades. Para tomar estas decisões 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.

Hoje em dia não se fala de OOP(Programaç OOP(Programação Orientada e Objetos), Objetos), sem citar UML.

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 o serviço ficou em operação. Ou seja,

• Arquitetura de Organização SLA é um documento formal, negociado entre as partes, na contratação de um serviço de TI ou Telecomunicações. O SLA é colocado geralmente como anexo do contrato e tem por objetivo especificar os requisitos mínimos aceitáveis para o serviço proposto. O não cumprimento do SLA implica em penalidades, estipuladas no contrato, para o provedor do serviço. Um SLA pode cobrir itens como qualidade do serviço, critérios de cobrança, provisionamento, processo de atendimento e relatórios fornecidos ao cliente. Um SLA deve conter parâmetros objetivos e mensuráveis os quais o provedor de serviços se compromete a atender. Este tutorial terá por foco a apresentação dos parâmetro típicos de um SLA utilizado na contratação de serviços de telecomunicações como o aluguel de uma linha dedicada de dados TDM ou um circuito virtual através de uma rede de comutação de pacotes.

Os requisitos típicos que devem fazer parte de um SLA para um serviço de telecomunicações são: Disponibilidade do Serviços Compromissos com tempos e prazos Requisitos de desempenho EX Um serviço de telecomunicações é um serviço de provimento contínuo e ininterrupto 24 horas por dia e sete dias por semana. Desta forma a disponibilidade do serviço passa a ser um parâmetro chave de um SLA para serviços de telecomunicações. A Indisponibilidade de um serviço é definida como o percentual do tempo em que o serviço ficou fora de operação. Por exemplo, a indisponibilidade anual de um serviço que ficou fora de operação por um dia durante o ano é de 1/365 = 0,27%.

Disponibilidade = 1- Indisponibilidade No exemplo acima a Disponibilidade é 99,73%. A tabela a seguir apresenta alguns valores de Disponibilidade Anual em função do tempo que um serviço ficou indisponível no ano. Uma tabela mais completa pode ser encontrada na seção de referência rápida do Teleco. Disponibilidade A (%)

Tempo indisponível em um ano

99,9999999

0,03seg

99,999999

0,32seg

99,99999

3,15seg

99,9999

31,54seg

99,999

5,26min

99,99

52,56min

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 indisponibilidade conforme o nível de degradação, como exemplificado na tabela a seguir.

Fator de Degradação do Serviço

Tipo de Falha Serviço totalmente indisponível Taxa de erros estabelecido

20%

acima

1 do

Velocidade menor que 50% do requisito

0,9 0,6

Tipicamente o SLA estabelece também uma série de tempos, como: Tempo para recuperar uma falha, ou tempo máximo de indisponibilidade. Tempo para provisionamento do serviço. Normalmente, o SLA exige também que o prestador de serviço tenha um centro de atendimento funcionando 24 horas por dia e 7 dias por semana, um sistema de acompanhamento de problemas (Trouble ticket) e relatórios mensais para acompanhamento do desempenho e disponibilidade do serviço. Finalmente, o SLA deve representar um acordo entre as partes onde prevaleça o bom senso. A ausência de um SLA, ou SLA frouxo torna difícil cobrar qualidade de serviço de um provedor. Por outro lado um SLA muito rigoroso pode levar a um alto custo do serviço ou ao provedor fazer promessas que não conseguirá depois cumprir.

Software Produzido

•Análise - o quê o sistema deve fazer.

Documento de Especificação •Projeto - Utiliza o documento de especificação e define como o comportamento especificado será obtido

Documento de Arquitetura •Implementação - Utiliza uma linguagem de programação

Código 93

31

Necessidade de Manutenç Manutenção no Software

• Sistemas sem documentação • Dificuldade de manutenção

•O quê fazer ???

• Erros gerando outros erros • Código duplicado

Será possível ???? Na construção civil, ok E com sistemas de software?

•Quem poderá 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 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 documentação e manutenção de software. -Pequena introdução à Engenharia de Software Para entender o que vai seguir, você precisa saber o que é a engenharia 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 complexidade que o sistemas de software atingem hoje, não é mais possível de ir programando sem preparação nenhuma. É preciso pensar muito antes (levantamento dos requisitos, análise, projeto, ...) e documentar todo o que se faz e diz. Isso parece (até é) muito chato, mas é 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 de uma empresa...

Engenharia Reversa o gic Ló lo e d Mo

Reengenharia 97

(1) Melhore o entendimento do software (2) Prepare ou melhore o software em si, sua manutenção, seu reuso e sua extensão Chikofsky e Cross definem reengenharia: “o exame e a alteração de um sistema para reconstituí-lo de uma nova forma, seguida pela sua implementação “ Sinônimos de Reengenharia: melhoramento, renovação, modernização, engenharia de re-desenvolvimento, engenharia de reuso

99

33

-Vamos fazer Engenharia Reversa Para escapar dessa tarefa considerada até útil mas certamente não digna de se gastar muito tempo e dinheiro com ela, muitos gerentes pensam o seguinte: "Não vamos perder tempo com essas frescuras. 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 resposta a esta idéia poderia ser de rir se não fosse trágico (estou relatando aqui casos reais). Todas essas regras chatas de desenvolvimento e documentação não foram criadas por pessoas 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...

Processo de Reengenharia Conhecimento do Usuário

Sistema Legado (código fonte) Eng. de Software

-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 mundo usaria a tal de engenharia reversa. Segundo, se um sistema foi 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 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 n-ésima correção de bug que introduziu mais problemas do que ela resolveu (ou quando um gerente prudente está vendo que isso poderia acontecer mais rapidamente que ele queria)...

ReDocumentação Engenharia Reversa

+

Recuperação do Projeto

= Reengenharia Documentação?

101

34

Requisitos (restrições, objetivos, regras do negócio) Engenharia Avante

Engenharia Avante

Engenharia Reversa

Engenharia Reversa Projeto Recuperado

Projeto Recuperado

Reestruturação

Reengenharia (Renovação)

Quando uma pessoa compra um software, seja pela internet ou em CD-ROM, ele está gravado como um arquivo binário. O arquivo binário é gerado a partir do código-fonte, que é escrito pelo programador em uma linguagem mais acessível que o código de máquina. Esse arquivo pode ser compreendido pelo chip do computador e executado. De fato, ele é tudo o que o computador precisa para executar o programa. Porém o código binário é difícil - quase impossível - de ser compreendido por seres humanos. Essa peculiaridade da programação de computadores é que permite, no mundo atual da informática, a preservação do direito autoral sobre software: se você faz um programa e o vende na forma de arquivos binários, 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, é mantido sob domínio da empresa. Isto funciona assim para a grande maioria dos usuários comuns de computadores.

Implementação

Projeto

Reestruturação

Reengenharia (Renovação)

Reengenharia:: Sem mudança de funcionalidade, mesmo paradigma com Mudança de Linguagem de Programação

Sistema Existente

Já existia

Recuperado do código legado

Modelo Lógico

Reestruturação

Linguagem Escolhida

Relacionamento entre os termos 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 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. Nos EUA e Europa a briga envolve grandes companhias, como a Microsoft e comunidades de programadores de software livre unidos pela internet. 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

Reengenharia com Mudança de Orientação

Orientada a Procedimentos

Orientada a Objetos 108

36

• O inter-relacionamento das Arquiteturas

37

38

• Arquitetura de tecnologia

• Arquitetura de tecnologia O que são Ferramentas CASE?

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.

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