Por que utilizar rotas?
Rotas são um recurso importante e valioso no desenvolvimento web, pois seu uso poderá poupar tempo no desenvolvimento além de deixar a url mais ‘amigável’ ao usuário.

Exemplo:
Vamos considerar um catálogo de produtos onde a url de acesso a informações de um determinado produto seja:

http://www.dominio.com.br/produtos/busca/idproduto/1234

Onde temos:
controlador: produtos
método/action: busca
parâmetro: idproduto = 1234

Seria mais interessante se utilizássemos a url abaixo para acessar as mesmas informações:

http://www.dominio.com.br/produto/1234

Vou mostrar a rota que atenda a configuração mencionada.
O código abaixo deve ser inserido no seu arquivo de bootstrap antes do método dispatch() da instância de Zend_Controller_Front:

Toda vez que for informado “../produto/valorvariavel”, será invocado o método/action busca do controlador produtos passando o valor da variável.

Captura-se o variável com o código abaixo:

Bom é isso… Até a próxima!

Hoje, grande parte das empresas, seja ela micro, média ou grande possui um banco de dados e este em muitas vezes auxilia os gestores na tomada de decisões. Para que as informações desses bancos de dados sejam geradas com qualidade é necessário que o banco seja projetado afim de evitar redundâncias e garantir a consistência. É aí que entra a normalização de dados, já que é sua característica garantir a consistência e ‘eliminar’ redundâncias.

Para normalizarmos um banco, precisamos aplicar algumas regras que são conhecidas como formas normais, definidas originalmente por Edgar F. Codd – 1FN, 2FN e 3FN. Muitos especialistas afirmam que um banco de dados que utilize a definição de Codd estará livre de inconsistências e redundâncias. Abaixo descrevo cada uma das formas normais:

1ª forma normal: uma tabela se encontra na 1FN quando todos os seus atributos possuem apenas valores atômicos, ou seja, indivisíveis. Por exemplo um atributo Endereço com valor ‘Rua Principal, 5 – Capital – São Paulo’ não está normalizado, pois há várias informações em um mesmo campo. A normalização aqui se dá criando novos atributos, como por exemplo: logradouro, número, bairro, cidade, uf.

2ª forma normal: uma tabela se encontra na 2FN quando a mesma está na 1FN e todos os atributos que não dependam integralmente da chave primária sejam colocados em uma nova tabela. Exemplificando, uma tabela de Cliente(cod_cliente, nome, sobrenome, logradouro, numero, bairro) não está na 2FN, porque logradouro, numero e bairro não dependem da PK cod_cliente. Para que esta esteja na 2FN é necessária a criação de um nova tabela, denominada Endereço(cod_endereco, logradouro, numero, bairro) e que a PK cod_endereco desta tabela seja chave estrangeira na tabela Cliente – relacionamento.

3ª forma normal: uma tabela está na 3FN se estiver na 2FN e que não tenha nenhum atributo que dependa de outro atributo que não seja a chave primária. Por exemplo uma tabela Aluno(cod_aluno, nome, cod_curso, nome_curso) não está na 3FN porque nome_curso não depende da PK e sim do atributo cod_curso. Aqui temos que criar uma nova tabela, Curso(cod_curso, nome_curso) e relacionar esta com a tabela Aluno.

Existem outras formas de normalização além destas formas normais definidas por Codd.

Bom, como escrevi no começo, foi apenas uma pincelada. Fiquem à vontade para comentar. Até a próxima!

O que é CASE?

Ferramentas CASE assistem gerentes e profissionais em toda a atividade associada com o processo de software, automatizam as atividades de gestão de projetos, gerenciam todos os produtos de trabalho produzidos ao longo do processo e assistem os engenheiros  de software em seu trabalho de análise.

Características:

- coleção de ferramentas úteis que ajudarão em cada passo da construção de um produto;

- uma disposição organizada, permitindo que as ferramentas sejam encontradas rapidamente e usadas eficientemente;

- hábil artesão que saiba usar as ferramentas de um modo efetivo.

Ferramentas CASE para soluções pontuais podem fornecer um substancial benefício individual, mas uma equipe de software precisa de ferramentas que se comuniquem umas com as outras. As ferramentas integradas ajudam a equipe a desenvolver, organizar e controlar produtos de trabalho.

Para melhor apreciar onde ferramentas CASE podem ser aplicadas no processo de engenharia de software, é necessário criar uma taxonomia das ferramentas.

Ferramentas de engenharia de processo de negócio – Modela os requisitos de informação estratégica de uma organização, fornecem um ‘metamodelo’ onde sistemas específicos são derivados. O objetivo principal é representar os objetos de dados de negócio, seus relacionamentos e como esses objetos de dados fluem entre diferentes áreas de negócio.

Ferramentas de modelagem e gestão de processo – Usadas para representar os elementos principais de um processo, de modo que possa ser melhor entendido. Elas fornecem ligações para outras ferramentas que suportam as atividades de processo definidas.

Ferramentas de planejamento de projeto – Focaliza estimativa de custo e esforço de projetos de software, e realização de cronogramas de projetos.

Ferramentas de análise de risco – Sua função é identificar riscos em potencial e desenvolver um plano para amenizá-los, monitorá-los e geri-los. Permite ao gerente de projeto construir uma tabela de risco, fornecendo diretrizes detalhadas na identificação e análise de riscos.

Ferramentas de gestão de projeto – São extensões de ferramentas de planejamento de projetos. Monitora cronograma e plano do projeto.

Ferramentas de rastreamento de requisitos – Combina a avaliação humano-interativa de texto com um sistema de gestão de base de dados que armazena e categoriza cada requisito do sistema.

Ferramentas de métricas e gestão – Focalizam as características do processo e do produto.

Ferramentas de documentação – Procuram melhorar a produtividade, uma vez que o desenvolvimento de software gasta de 20 a 30% de todo o esforço em documentação.

Ferramentas de software básico – O objetivo destas ferramentas é acomodar um software de sistema de redes de alta qualidade, serviços de gestão de objetos, suporte de componentes distribuídos, email, quadros de boletins e outras possibilidades de comunicação.

Ferramentas de gestão de base de dados – Serve como fundação para o estabelecimento de uma base de dados CASE(repositório).

Ferramentas de gestão de configuração de software – Assistem nas cinco principais tarefas de SCM – identificação, controle de versão, controle de modificação, auditoria e listagem de categorias.

Ferramentas de análise e projeto – Permite ao engenheiro de software criar modelos do sistema a ser construído.

Ferramentas PRO/SIM – São ferramentas de prototipação e simulação e fornecem ao engenheiro de software a capacidade de prever o comportamento de um sistema em tempo real.

Ferramentas de projetos e de desenvolvimento de interfaces – ‘Estojo’ de ferramentas de componentes de software.

Ferramentas de prototipação – Ferramentas utilizadas na quarta geração.

Ferramentas de programação – Compiladores, editores, depuradores, IDE.

Ferramentas de desenvolvimento da web – Ferramentas que assistem a geração de texto, gráficos, formulários, scripts, applets e outros elementos de uma página web.

Ferramentas de integração e teste – Aquisição de dados: adquire dados usados durante o teste. Medição estática: analisa o código-fonte. Medição estática: analisa o código-fonte durante a execução. Simulação: simula funções do hardware e componentes externos. Gestão de testes: assiste no planejamento, desenvolvimento e controle. Cruzamento funcional: cruza fronteiras das categorias precedentes.

Ferramentas de teste cliente/servidor – Exercita a interface gráfica com o usuário e os requisitos de comunicação na rede para cliente/servidor.

Ferramentas de reengenharia – Conjunto de atividades de manutenção que absorve um significativa porcentagem de todo o esforço relacionado à software.

Bom, por hoje é isso. O próximo artigo será sobre Ambientes CASE, onde temos o I-CASE. Embora seja mais uma referência, fiquem à vontade para comentar e caso encontrem algum erro, peço por gentileza me informar.

Até mais.

Referência Bibliográfica

PRESSMAN,  Roger S. Engenharia de Software. Rio de Janeiro. McGraw-Hill, 2002

Bom, mas o que é Orientação a objetos?

“Orientação a Objetos é um termo geral que inclui qualquer estilo de desenvolvimento que seja baseado no conceito de ‘objeto’ – uma entidade que exibe características e comportamentos. Visão do mundo em ‘objetos’.”

Ela é a abstração, por meio do software, de objetos do mundo real. O foco da POO não é executar uma sequência de procedimentos. Aqui os objetos interagem entre si(passagem de mensagem/chamada de método) orientando o fluxo do programa.

Para uma melhor compreensão, vamos entender alguns conceitos básicos:

Classe é a definição da estrutura de um objeto. Nela são definidos os atributos(variáveis internas do objeto) e os métodos(comportamento do objeto). É a partir das classes que os objetos são criados. Um exemplo prático é o projeto de um carro, onde não temos o carro propriamente dito, e sim a definição das características(cor, modelo, peso) e comportamentos(aceleração, velocidade).

Objeto é uma instância de classe. Pegando o exemplo da classe, cada carro fabricado seria um objeto.

“Um objeto é uma construção de software que encapsula estado e comportamento. Os objetos permitem que você modele seu software em termos reais e abstrações.”

Herança é o mecanismo de uma classe(subclasse) estender a definição de uma outra classe(superclasse). Por exemplo, a subclasse homem herda da superclasse mamífero.

Polimorfismo é a capacidade de um método(comportamento) ser implementado de diversas maneiras nas subclasses. Por exemplo, imagine o método locomoção da superclasse mamífero: a implementação para a subclasse homem é diferente da subclasse morcego.

Encapsulamento consiste na proteção dos atributos de um objeto, ou seja, não permite que um atributo seja acessado diretamente. Quanto maior o encapsulamento, menor é o acoplamento entre as classes. Isso garante a reusabilidade , recurso importante para orientação à objetos e desenvolvimento de software.

Atributos são variáveis internas do objeto e seus valores definem o estado do mesmo.

Método é o comportamento que o objeto tem. Quando encapsulados, os atributos são alterados através dos métodos. Temos os métodos construtores que são chamados durante a instanciação do objeto; métodos acessadores(em Java são os getters) usados para retornar o valor dos atributos e o métodos mutantes(em Java são os setters) usados para alterar o valor dos atributos.

Bom, é isso. Aqui dei apenas um pontapé inicial sobre Orientação a Objetos. Fiquem à vontade  para comentar, sugerir e criticar, pois, acredito que é dessa maneira que conseguimos ampliar o nosso conhecimento. Qualquer dúvida me mande um e-mail que responderei com grande prazer.

Até a próxima…

Referência Bibliografica

Sintes, Anthony. Aprenda Programação Orientada a Objetos em 21 Dias. São Paulo. Pearson Education do Brasil, 2002.

Queremos também, com uma abordagem simples e prática, mostrar como é possível otimizar recursos e gerenciar a informação, de forma que esta possa auxiliar na tomada de decisões, através do uso de sistemas de informações gerenciais.