Nos aplicativos criados no dia-a-dia pelos desenvolvedores sempre temos que lidar com a criação de objetos. Apesar do assunto parecer simples e inofensivo, existem diversas armadilhas que podem aparecer e levar a sérios problemas de performance que podem comprometer a aplicação.

Uma situação frequente e apropriada é a reutilização de um objeto individual ao invés de criarmos um novo objeto funcionalmente equivalente sempre que este se torna necessário. Além da reutilização ser mais elegante, ela é extremamente mais rápida.

Para começar com um exemplo que apesar de ser simples é bastante claro, é interessante primeiramente olharmos com bastante atenção o código abaixo:

Listagem 1: Criando uma String utilizando seu construtor

String s = new String("Qualquer coisa");

Essa simples instrução cria uma nova instância de String sempre que ela é executada, mas nenhuma dessas criações de objetos é realmente necessária. O valor da instância dessa String é o argumento passado pelo construtor.

É interessante notar que se esse tipo de utilização ocorrer dentro de um loop, teremos centenas ou milhões de instâncias de Strings sendo criadas, o que pode comprometer consideravelmente a performance de uma aplicação.

A melhor forma de criar uma String nestas condições seria utilizar uma simples inicialização por atribuição direta:

Listagem 2: Criando uma String de forma explicita

String s = "Qualquer coisa";

Essa versão usa apenas uma instância de String sempre que ela for executada, ao invés de criar uma nova instância. Outra situação importante é que esse mesmo objeto será reutilizado por qualquer outro código que estiver sendo executado na mesma máquina virtual (Java Virtual Machine - JVM) que tiver esse mesmo literal String "Qualquer coisa".

Nas próximas seções veremos outras formas de evitarmos a criação desnecessária de objetos em Java através dos métodos de fabricação estáticos ou através da utilização de tipos primitivos.

Evitando a criação de instâncias desnecessárias com métodos de fabricação estáticos

Uma dica geral para evitar a criação de instâncias de objetos desnecessárias é usarmos os métodos de fabricação estáticos ao invés de utilizar os construtores das classes. Por exemplo

O Eclipse é uma plataforma de desenvolvimento de software livre baseada em Java. Toda sua estrutura e serviços são disponibilizados por meio de plug-ins, alguns deles já estão disponíveis nas versões para download do Eclipse e atendem a maioria das necessidades dos desenvolvedores.

O Projeto Eclipse foi originalmente criado pela IBM em meados de novembro de 2001 e suportado por um consórcio de fornecedores de software. A Eclipse Foundation foi criada em janeiro de 2004 como uma organização sem fins lucrativos independente para atuar como organizadora da comunidade Eclipse, que é mantida pelos seus associados e hospeda os projetos do Eclipse e também ajuda a cultivar uma comunidade de software livre, além de vários de seus produtos e serviços complementares. Foi criada para permitir o surgimento de uma comunidade ao redor do Eclipse independente de fornecedor, transparente e aberta. Hoje, a comunidade do Eclipse é composta por pessoas e organizações de uma seção transversal do segmento de mercado de software.

A Eclipse Foundation gerencia e dirige o desenvolvimento contínuo do Eclipse. A fundação fornece serviços para a comunidade, mas não emprega os desenvolvedores de software livre (denominados committers), que realmente trabalham nos projetos Eclipse. Os committers do Eclipse são normalmente empregados pelas organizações ou são desenvolvedores independentes que trabalham como voluntários em um projeto de software livre.

O Eclipse também é chamado de IDE (Integrated Development Enviroment) utilizado para codificar, testar e fazer deploy dos seus projetos numa máquina de desenvolvimento. IDEs são muito úteis e ajudam muito os desenvolvedores, fornecendo no seu ambiente de desenvolvimento editores de código integrados, compiladores, depuradores e ferramentas de publicação (deploy). São muito utilizados nos meios corporativos e acadêmicos, se destacando principalmente em corporações de desenvolvimento de software.

As ferramentas mais populares para os desenvolvedores Java são o Eclipse e o Netbeans. Cada uma tem suas vantagens e desvantagens. Neste artigo vamos explorar as capacidades do Eclipse para desenvolvimento e publicação (deploy) de uma aplicação web no servidor de aplicação web Apache Tomcat.

Instalação

Para instalar o Eclipse, primeiramente devemos fazer o download do mesmo através do site www.eclipse.org/downloads/.

Após isso, basta descompactar o Eclipse em qualquer pasta e o ambiente de desenvolvimento já está pronto para ser utilizado.

Criando um Projeto Web

Para criar um projeto web é muito simples, basta seguir os passos seguintes:

1 – Primeiramente vá no menu “File” no canto superior do IDE, selecione “New Project”. Será exibida a janela "New Project" que é um Wizard (tela passo a passo) para que possamos criar um projeto no Eclipse.

Figura 1: Tela da Janela New Project

O servidor Apache Tomcat é um container Web de código fonte aberto baseado em Java que foi criado para executar aplicações Web que utilizam tecnologias Servlets e JSPs. O servidor Tomcat foi criado inicialmente como um subprojeto da Apache-Jakarta, no entanto, devido a sua alta popularidade, acabou sendo designado para um projeto separado da Apache, sendo assim mantido por um grupo de voluntários da comunidade de código aberto do Java.Apache Tomcat é um servidor bastante estável com todas as características que um container comercial de aplicações web possui.Atualmente as versões que ainda recebem suporte são 5.5x, 6.0x e 7.0x. Versões anteriores a 5.5 ainda encontram-se disponíveis para download no site da Apache, porém estão arquivadas e não possuem mais suporte. Por isso, recomenda-se que os usuários adquiram as últimas versões disponíveis.

Compatibilidade do Tomcat

A compatibilidade do servidor Tomcat com a JVM instalada também deve ser verificada. Além disso, também há outras compatibilidades que devem ser verificadas. A tabela abaixo mostra a versão do Tomcat e a versão de outras APIs e da JVM que são compatíveis.

Um conjunto de caracteres é uma variedade de letras e símbolos usado em um sistema de escrita. Palavras e frases no texto são criados a partir de caracteres. Por exemplo, o conjunto de caracteres ASCII abrange letras e símbolos para textos em inglês, o ISO-8859-6 abrange letras e símbolos necessários para muitas línguas com base na caligrafia árabe, e o conjunto de caracteres Unicode contém caracteres para a maioria das línguas. Já um caractere pode incluir letras latinas ou ideogramas chineses, por exemplo.

Caracteres podem ser agrupados em um conjunto de caracteres. Os caracteres em um conjunto são armazenados como um ou mais bytes em um computador. Cada byte ou sequência de bytes representa um determinado caractere. Uma codificação de caracteres é a chave que mapeia um byte em especial ou uma sequência de bytes de caracteres que a fonte transforma em texto. Esse byte ou sequência de bytes que representa um caractere é chamado de codepoint.

Portanto, todos caracteres são armazenados em computadores utilizando-se códigos, muito semelhantes às cifras utilizadas na espionagem. Uma codificação de caracteres é uma chave que permite destravar o código. Sem essas chaves, os dados não possuem qualquer informação.

O termo charset é usado para referir-se ao que são as codificações de caracteres. O W3C recomenda utilizarmos sempre o termo charset ao invés de usarmos o termo codificação de caracteres.

Existem muitas codificações de caracteres diferentes. Se a codificação errada for aplicada aos bytes na memória, o resultado será um texto ilegível. Portanto, é importante classificar corretamente a codificação de caracteres usada para que as pessoas consigam ler o conteúdo.

Exemplos de Codificação

Para dar um exemplo de como funciona a codificação de caracteres, podemos imaginar o conjunto de códigos de caracteres denominado ISO 8859-1, também conhecido como Latin1, onde o valor decimal de codepoint para a letra "é" é representado por 233. No entanto, na codificação ISO 8859-5 este mesmo codepoint representa outro caractere.

Nas referências bibliográficas estão disponíveis algumas tabelas de codificação de caracteres com o código em decimal, octal ou hexadecimal e o seu valor representado.

Ajustando a Codificação no Ambiente de Desenvolvimento

A codificação de caracteres também pode afetar o desenvolvedor e o seu ambiente de desenvolvimento. Dependendo da codificação de caractere configurada no ambiente e o tipo de documento que o desenvolvedor está editando, podemos ter uma discrepância, na qual, se o ambiente de desenvolvimento não conseguir interpretar os dados no arquivo sendo editado, teremos como resultado alguns quadrados ou símbolos estranhos no lugar do caractere esperado.

Para que isso não ocorra, vamos seguir alguns passos no ambiente de desenvolvimento Eclipse para que possamos ajustar a codificação de caracteres. A versão utilizada é a última até o momento da escrita deste artigo, ou seja, Eclipse Juno.

Primeiramente vá até o menu "Window" e em seguida selecione a opção "Preferences".

Na tela aberta, vá na opção "General" no canto esquerdo da tela e selecione a opção "Workspace". Após clicar sobre a opção "Workspace", podemos verificar ao final da tela o fieldset "Text file encoding". No canto esquerdo deste fieldset temos um combo com as opções de codificação de caracteres. Escolha a opção que melhor se encaixa no tipo de arquivo que você irá abrir. Na tela abaixo temos a demonstração desta tela.

1. Introdução

Existem classes que são criadas apenas para abrigar métodos e campos estáticos. Esse tipo de classe ganhou má reputação ultimamente porque os programadores simplesmente abusam demais desse tipo de abordagem. No entanto, essas classes ainda podem ser bastante úteis quando precisamos agrupar métodos relacionados em valores primitivos ou matrizes, como ocorre na API no Java em java.lang.Math e java.util.Arrays. Abaixo podemos verificar alguns códigos encontrados dentro de java.lang.Math e java.util.Arrays:

Listagem 1: Exemplo de implementação da classe Math em Java

public final class Math {

	private Math() {}

	public static final double E = 2.7182818284590452354;
	public static final double PI = 3.14159265358979323846;

	public static double sin(double a) {
		return StrictMath.sin(a);
	}

	public static double cos(double a) {
		return StrictMath.cos(a);
	}

	public static double tan(double a) {
		return StrictMath.tan(a);
	}

	public static double toRadians(double angdeg) {
		return angdeg / 180.0 * PI;
	}

	public static double toDegrees(double angrad) { 		
		return angrad * 180.0 / PI;
	}

	public static double log10(double a) {
		return StrictMath.log10(a);
	}

	public static double sqrt(double a) { 
		return StrictMath.sqrt(a);
	}
}

Para o código fonte completo da classe Math, confira em [1] nas referências bibliográficas.

Listagem 2: Exemplo de implementação da classe Arrays em java

package java.util;

import java.lang.reflect;

public class Arrays {
	private Arrays() {}

	public static void sort(int[] a) {
		DualPivotQuicksort.sort(a);
	}

	public static void sort(int[] a, int fromIndex, int toIndex) {
		rangeCheck(a.length, fromIndex, toIndex);
		DualPivotQuicksort.sort(a, fromIndex, toIndex - 1);
	}

	public static void sort(long[] a) {
		DualPivotQuicksort.sort(a);
	}

	public static void sort(long[] a, int fromIndex, int toIndex) {
		rangeCheck(a.length, fromIndex, toIndex);
		DualPivotQuicksort.sort(a, fromIndex, toIndex - 1);
	}

	public static void sort(short[] a) {
		DualPivotQuicksort.sort(a);
	}

	public static void sort(char[] a) {
		DualPivotQuicksort.sort(a);
	}

	public static void fill(char[] a, char val) {
		for (int i = 0, len = a.length; i < len; i++)
			a[i] = val;
	}
	
	public static void fill(char[] a, int fromIndex, int toIndex, char val) {
		rangeCheck(a.length, fromIndex, toIndex);

1. Introdução

Um Singleton é um padrão de projeto bastante conhecido pela maioria dos programadores, trata-se de uma classe que é instanciada apenas uma vez. Os Singletons normalmente são componentes únicos do sistema, como por exemplo, um gerenciador de janela num sistema operacional ou o sistema de arquivos. Em ambos os exemplos, tanto o gerenciador de janelas quanto o gerenciador de arquivos são um componente único que gerencia tudo em volta do sistema que se refere tanto às janelas quanto ao sistema de arquivos. Para um melhor esclarecimento, consulte os outros artigos a respeito do assunto que estão disponibilizados no portal.

2. Abordagens para criar um Singleton

Existem algumas abordagens para criar um Singleton. A primeira delas é uma abordagem bastante antiga onde temos a classe com um construtor privado e exportamos um membro estático público para dar acesso à instância exclusiva. O exemplo abaixo demonstra como isso é de fato feito em Java:

Listagem 1: Exemplo de implementação de um Singleton.

public class GerenciadorDeJanelas {
  public static final GerenciadorDeJanelas INSTANCE = new GerenciadorDeJanelas();

  private GerenciadorDeJanelas() {
  }
}

O construtor privado é chamado apenas uma única vez para inicializar o campo final estático INSTANCE. Como não temos um construtor público ou protegido, temos a garantia de que existirá apenas uma instância para a classe GerenciadorDeJanelas.

Para burlar isso e criar uma segunda instância dessa classe, um cliente poderia chamar o construtor privado reflexivamente com a ajuda do método AcessibleObject.setAcessible. Para defender-se deste ataque, o construtor teria que ser modificado para lançar uma exceção caso fosse solicitado a criar uma segunda instância.

Outra abordagem para implementar um Singleton é através de um método de fabricação estático. Por exemplo:

Listagem 2: Exemplo de implementação de um Singleton com um método de fabricação estático

public class GerenciadorDeJanelas {
  private static final GerenciadorDeJanelas INSTANCE = new GerenciadorDeJanelas();

Figura 1: Guia PMBoK

1. Introdução

O Guia PMBoK é um guia de conhecimentos em gerenciamento de projetos. O Guia PMBoK possui diversos processos, ferramentas e técnicas úteis para a gerencia de qualquer projeto. O guia PMBoK possui informações consensuais que foram identificados por profissionais da área e que se forem usados nos projetos aumentam as chances de sucesso nesses projetos, todos os padrões contidos no guia foram testados e aprovados na prática por diversos profissionais.

Neste artigo será apresentada uma das áreas de conhecimento do guia PMBoK. Esta área de conhecimento é ainda divida em seis processos. Nas seções seguintes será mostrado o que é essa área e o que é o processo de desenvolvimento do termo de abertura do projeto.

2. Conceitos

A área de conhecimento Gerenciamento da Integração do Projeto possui diversos processos e atividades dentro de cada um dos processos responsáveis por identificar, definir, combinar, unificar e coordenar as outras diversas atividades e processos de gerenciamento de projetos abordados no guia PMBoK. Portanto, este processo é um integrador, ou ainda um consolidador, ou articulador, que são vitais para gerenciar expectativas dos clientes e atender aos requisitos do projeto.

Veremos no decorrer do artigo quais são os processos dessa área de conhecimento e qual a responsabilidade de cada um desses processos.

3. Processos

Existem seis processos de gerenciamento da integração, são eles:

• Desenvolver o termo de abertura do projeto: Desenvolve-se um documento formal autorizando um projeto ou uma fase e documenta-se os requisitos iniciais com as partes interessadas.
• Desenvolver o plano de gerenciamento do projeto: Documenta-se todas as ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares que são criados em outros processos em outras área de conhecimento.
• Orientar e Gerenciar a Execução do Projeto: Realiza-se o trabalho definido no plano de gerenciamento do projeto.
• Monitorar e Controlar o Trabalho do Projeto: É feito um acompanhamento e regulação no projeto com o intuito de averiguar se os objetivos previamente definidos no plano de gerenciamento do projeto estão sendo satisfeitos.
• Realizar o Controle Integrado das Mudanças: Revisa-se toda e qualquer solicitação de mudança e após isso é definida a aprovação ou não das mudanças solicitadas.
• Encerrar o Projeto ou Fase: Finaliza-se todas as atividades de todos os grupos de processos ou área de conhecimento para finalizar formalmente um projeto ou uma fase.

Na próxima seção analisaremos um dos processos descritos acima, que é o processo de desenvolver o termo de abertura do projeto e será possível entender melhor o que requer este processo.

3.1. Desenvolver o Termo de Abertura do Projeto

Neste processo é onde formalmente autoriza-se o início de um projeto ou fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas. Vale ressaltar que uma fase é uma forma como os projetos podem ser divididos. Um projeto de desenvolvimento de um software pode ser dividido em quatro fases: Fase de Requisitos, onde coleta-se os requisitos do software junto com o cliente; Fase de Implementação, onde os desenvolvedores implementam os requisitos dos clientes e geram o produto; Fase de Teste, onde é verificado e validado o software desenvolvido; e Fase de Implantação, onde coloca-se o software em produção no ambiente de trabalho do cliente.

No termo de abertura do projeto identifica-se quem será o gerente responsável por gerenciar o projeto. Todos os projetos são autorizados por um patrocinador, ou um escritório de projetos, por exemplo, sempre por alguém externo. Este patrocinador é o res

1. Introdução

O Guia PMBoK é um guia de boas práticas. O Guia PMBoK possui diversos processos, ferramentas e técnicas úteis para a gerencia de qualquer projeto. O guia não determina como será gerenciado um projeto, ele apenas dá boas práticas, deixando livre para o gerente de projeto e a equipe escolherem aquilo que melhor se adapte ao seu projeto. Além disso, o PMBoK identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos. Ou seja, o guia possui informações consensuais que foram identificados por profissionais da área e que se forem usados nos projetos, aumentam as chances de sucesso nesses projetos.

Neste artigo será mostrada uma forma de como os processos do guia PMBoK podem ser organizados. Os processos sãp organizados por áreas de conhecimento e podem ser organizados em nove áreas que serão melhores detalhados nas seções seguintes.

Figura 1: Guia PMBoK

2. Áreas de Conhecimento

Uma área de conhecimento é definida por seus requisitos de conhecimentos e descrita em termos dos processos que a compõem, suas práticas, entradas, saídas, ferramentas e técnicas.

Existem nove áreas de conhecimento, são elas: Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicações, Riscos e Aquisições.

Veremos abaixo o objetivo de cada área e quais são os seus processos.

2.1. Área de Conhecimento - Integração

Esta área de conhecimento descreve os processos que integram elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos.

Os processos dessa área são:

• Desenvolver o Termo de Abertura do Projeto.
• Desenvolver o Plano de Gerenciamento de Projeto.
• Orientar e Gerenciar a Execução do Projeto.
• Monitorar e Controlar o Trabalho do Projeto.
• Realizar o Controle Integrado de Mudanças.
• Encerrar o Projeto ou Fase.

2.2. Área de Conhecimento - Escopo

Esta área descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário e apenas o trabalho necessário, para que seja concluído com sucesso.

Existem três processos de planejamento (três primeiros) e dois processos de controle e monitoramento (dois últimos). Os processos de planejamento criam um plano para o gerenciamento de escopo. Os processos de controle e monitoramento controlam se que o escopo está sendo cumprido conforme foi definido nos processos de planejamento e a verificação confirma com o cliente que está tudo correto.

Os processos dessa área são:

• Coletar Requisitos.
• Definir o Escopo.
• Cria a EAP.
• Verificar o Escopo.
• Controlar o Escopo.

2.3. Área de Conhecimento - Tempo

Está área descreve os processos relativos ao término do projeto no prazo correto. Os cinco primeiros processos são de planejamento e apenas o último é de controle. Os processos de planejamento definem as atividades que vão para o cronograma, a ordem de precedência das atividades, determinam o tipo e a quantidade de recursos necessários, o tempo necessário para concluir as atividades, associam as atividades às datas do cronograma e por fim verificam se o andamento dos trabalhos está de acordo com o cronograma.

Os processos dessa área são:

• Definir Atividades.
• Sequenciar as Atividades.
• Estimar os Recursos da Atividade.
• Estimar as Durações da Atividade.
• Desenvolver o Cronograma.
• Controlar o Cronograma.

4.4. Área de Conhecimento - Custo

Esta área descreve os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que o projeto termine dentro do orçamento aprovado.

Os primeiro

1. Introdução

O gerenciamento de projetos tem três conceitos bastante importantes para os profissionais que desejam se aventurar nesta área, são eles: quem é o PMI (Project Management Institute), o que é o PMBoK (Project Management Base of Knowledment) e, por fim, o que é o PMP (Project Management Professional).

O PMI é uma antiga e bastante importante instituição que deu origem tanto ao PMBoK quanto ao PMP. O Guia PMBoK é um guia de boas práticas. Verificamos que ele é apenas um guia e não uma metodologia, não é algo “amarrado”. Nele são apresentados diversos processos e ferramentas, mas não se usa tudo, e sim conforme a necessidade do projeto. O guia não determina como será gerenciado um projeto, ele apenas sugere boas práticas. A equipe determina quais processos são apropriados, ou seja, há processos que em determinado projeto são inapropriados. O PMP é uma certificação criada pelo PMI para atestar o conhecimento e a experiência dos gerentes de projetos a fim de credenciá-los como um gerente de projetos apto a exercer a profissão.

2. PMI

Figura 1: Logomarca do PMI

O PMI é uma associação sem fins lucrativos bastante antiga fundada em 1969, com sede na Pensilvânia nos Estados Unidos, que tem como objetivo reunir profissionais da área de gerenciamento de projetos para trocarem experiências e conhecimentos, identificar e reunir boas práticas de gerenciamento de projetos, estabelecer uma ética na profissão e certificar profissionais da área.

Essa importante organização está presente em mais de 185 países com mais de 600 mil membros afiliados.

3. PMBoK

PMBoK é um guia que oferece uma visão geral sobre o gerenciamento de projetos. Por se tratar de um guia, não encontramos informações ou descrições completas nele e sim explicações bastante vagas, por isso muitas vezes é um pouco complicado entender o guia PMBoK. Outra característica importante é que o PMBoK oferece um vocabulário comum que foi identificado pelos profissionais da área. Esse vocabulário comum ajuda bastante na comunicação entre os profissionais da área que, conhecendo uma terminologia, podem referenciá-la sempre que for necessário, sem precisarmos entrar em maiores detalhes. Além disso, o PMBoK identific

1. Introdução

O Guia PMBoK é um guia de boas práticas. Verificamos que ele é apenas um guia e não uma metodologia, não é algo amarrado. O Guia PMBoK possui diversos processos, ferramentas e técnicas, porém não se usa tudo e sim aquilo que é realmente necessário num projeto. O guia não determina como será gerenciado um projeto, ele apenas dá boas práticas. A equipe determina quais processos são apropriados, ou seja, há processos que em determinado projeto são inapropriados. Além disso, o PMBoK identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos. Ou seja, o guia possui informações consensuais que foram identificados por profissionais da área e que se forem usados nos projetos aumentam as chances de sucesso nesses projetos.

Neste artigo será mostrada uma forma de como os processos do guia PMBoK podem ser organizados. Os processos organizados por grupos podem ser organizados em cinco grandes grupos que serão mais detalhados nas seções seguintes.

2. Processos de Gerenciamento

O PMBoK possui o conhecimento que um gerente de projetos precisa para gerenciar melhor os seus projetos. Portanto, o PMBoK possui processos para gerenciar os projetos, esses processos fazem parte de todo o ciclo de vida de um projeto, desde a iniciação do projeto, passando pelo planejamento, execução, controle até o encerramento do projeto. Assim, o PMBoK ajuda o gerente de projetos a cuidar de todos os passos no gerenciamento de um projeto.

Figura 1: Grupos de Processos de Gerenciamento

Na figura 1 podemos verificar que existem cinco grandes grupos de processos de gerenciamento que são: Processos de Iniciação, Processos de Planejamento, Processos de Execução, Processos de Monitoramento e Controle e Processos de Encerramento. Todos os processos de gerenciamento se encontram dentro de um desses grupos de processos, ou seja, um processo pode ser de Iniciação, Planejamento, Execução, Monitoramento e Controle ou Encerramento.

Figura 2: Processos de gerenciamento de projetos

No gráfico acima podemos verificar a interação entre os processos. Por exemplo, na figura acima observa-se que os processos de iniciação interagem com os processos de planejamento, os processos de planejamento interagem com os processos de execução e assim por diante. Isso significa, por exemplo, que temos processos de iniciação que geram saídas para os processos de planejamento. Processos de uma mesma área também podem gerar saídas para serem entradas para processos da mesma área. Portanto, os processos de alguma forma se relacionam uns com os outros.

A aplicação dos processos também pode ser iterativa, ou seja, na medida em que o projeto vai se desenvolvendo alterações vão sendo feitas nos processos. Às vezes inclusive o planejamento do projeto precisa ser alterado devido alguma mudança requerida pelo cliente e isso teria como efeito revisitar os processos de planejamento, tendo como saída um novo planejamento do projeto. Assim, verificamos que os mesmo processos são abordados novamente, isso nos remete a essa iteratividade nos processos.

É interessante notar que em todos os processos de gerenciamento do guia é preciso sempre considerar os Ativos de Processos e

1. Introdução

Diferentes organizações possuem diferentes formas de organizar os seus projetos. Algumas empresas podem se organizar por projetos e oferecer autonomia a um gerente de projeto, outras preferem se organizar funcionalmente. Um projeto também pode ser dividido em fases na qual envolve um foco diferente para cada uma das fases. Todo projeto também possui um ciclo de vida e partes interessadas na execução de um projeto.

Esses conceitos serão mais detalhados e analisados no restante do artigo.

Figura 1: Organização de projetos

2. Fases de um Projeto

Uma fase é uma divisão do projeto onde um controle adicional é necessário sobre uma entrega importante. O inicio e o término de uma fase devem ser efetuados formalmente, assim como ocorre com um projeto. Cada fase tem um foco diferente e envolve diferentes organizações e conjuntos de habilidades. Portanto, cada fase tem um objetivo e deve retornar um resultado bem claro que determina se realmente chegamos ao final da fase.

As fases muitas vezes são sequenciais e, neste caso, geram uma entrega para a fase seguinte. As fases podem ser sobrepostas, ou seja, as fases podem ter inicio antes do termino da anterior ou podem ser iterativas em que apenas uma fase está planejada a qualquer momento e o planejamento da próxima fase é feita à medida que o trabalho avança.

3. Ciclo de Vida de Projeto e Ciclo de Vida de Produto

O ciclo de vida de um projeto é composto por suas fases, que geralmente são sequenciais, mas também podem ser sobrepostas. O nome e a quantidade de fases necessárias normalmente dependem de muitos fatores como as necessidades de gerenciamento e controle do projeto, da área de aplicação, etc.

Por exemplo, poderíamos ter quatro fases para o desenvolvimento de um software: Fase 1 chamada de Requisitos onde coleta-se os requisitos de um produto, Fase 2 chamada de Construção onde constrói-se o produto de acordo com os requisitos coletados na Fase 1, Fase 3 chamada de Testes onde testamos se o produto atende as exigências do cliente e não possui erros, Fase 4 chamada de Implantação onde coloca-se o software em operação no cliente após o encerramento da Fase 3 de Teste do produto. Dependendo da organização essas fases poderiam ter dife

1. Introdução

O gerenciamento de projetos possui alguns conceitos bastante importantes para que possamos ter um bom entendimento da área. Saber as diferenças entre projetos e operações e como eles podem estar relacionados a programas e portfólios, o que são processos e como eles estão incluídos no gerenciamento de projetos, além de saber qual é o papel do gerente de projetos torna-se crucial para aqueles que querem começar a entender a área de gerenciamento de projetos.

No restante do artigo será apresentado a definição e exemplos dos principais conceitos iniciais da parte de gerenciamento de projetos.

2. Projeto e Operação Continuada

Projeto é um esforço temporário empreendido para criar um produto, serviço, ou resultado exclusivo. Um projeto tem data para terminar, diferente de operações continuadas. Além disso, um projeto é exclusivo, ou seja, alguma coisa que não foi feita antes. Por exemplo, prédios feitos por construtoras são diferentes um dos outros e exigem requisitos diferentes. Um projeto pode envolver de uma a várias pessoas. Apesar de parecer estranho um projeto envolver uma única pessoa, isso é possível como, por exemplo, um projeto de vida de uma pessoa para emagrecer. Este é um projeto pessoal que envolve apenas uma pessoa. Projetos mais complexos evidentemente podem envolver muito mais que apenas uma pessoa.

Um projeto normalmente começa quando pelo menos um dos cinco eventos ocorre: demandas de mercado (inovações para fazer frente aos concorrentes), necessidades dos clientes, avanço tecnológico (surgimento de novas tecnologias impulsionam seu avanço para não ficar para trás), requisitos legais (lançamento de novas leis), estratégia organizacional (lançamento de novos produtos no mercado). O projeto termina quando os objetivos foram atingidos ou quando fica claro que os objetivos não serão ou não poderão ser atingidos (por falta de recursos, por exemplo), ou ainda quando o projeto não for mais necessário (não existe mais demanda ou necessidade para este produto).

Operações continuadas são esforços contínuos que sempre geram o mesmo resultado e não possuem hora nem data para acabar. Por exemplo, a contabilidade de uma organização é algo continuo que sempre gera o mesmo resultado e se mantém até o término da empresa. Outro exemplo seria o gerenciamento de incidentes de uma empresa de TI e a fabricação de carros.

Para contrastarmos os dois conceitos fundamentais da área de gerenciamento de projetos, podemos pensar num projeto de um novo carro de uma empresa. O projeto para o novo carro seria um esforço temporário para gerar um modelo do carro, um protótipo para testar com clientes potenciais. Após isso pronto, o carro poderia ser entregue a operação para que ele possa ser fabricado. Outro exemplo seria a criação de um novo site, no entanto, a sua atualização ou manutenção seria uma operação.

No entanto, projetos e operações possuem coisas em comum, como: ambos são realizados por pessoas, limitados por restrições incluindo de recursos, são planejados, executados, monitorados e controlados e por fim eles são realizados para atingir objetivos organizacionais.

3. Programa e Portfólio

Programa é um grupo de projetos relacionados gerenciados de modo coordenado para capitalização de benefícios maiores do que seriam obtidos se os projetos fossem gerenciados individualmente. Por exemplo, um veiculo lançador de

1. Introdução

Um programa Java segue uma linha tradicional de tradução e execução, assim como a linguagem C também faz. No entanto, Java foi inventado com objetivos diferentes como: funcionar o mais rapidamente possível e em qualquer plataforma, mesmo que para isso tenhamos um declínio no tempo de execução.

A figura abaixo mostra as etapas seguidas nos processos de tradução e execução dos programas Java.

Figura 1: Etapas de Tradução para programas Java

A primeira diferença que podemos notar para o processo de tradução e execução das linguagens de programação é que no Java temos que ao invés de compilar para a linguagem de montagem assembly de um computador destino, tem-se uma compilação para instruções fáceis de interpretar: bytecode Java. Esse conjunto de instruções é muito próximo da linguagem Java. Assim essa etapa de compilação torna-se um tanto trivial, de forma que não se tem nem mesmo uma fase de otimização que normalmente é feita por qualquer compilador. Todos os programas Java são distribuídos na forma binária desses bytecodes. Portanto, o bytecode é um formato de código intermediário entre o código fonte escrito pelo programador em linguagem Java e o código de máquina que o computador consegue executar.

Deve-se ressaltar que um programador Java não precisa codificar em bytecodes e nem mesmo ser um perfeito entendedor desse código para se tornar um bom programador, da mesma forma que um programador C não precisa conhecer linguagem de montagem assembly para entender uma linguagem C. Mesmo que existam montadores que permitem a escrita de bytecodes diretamente, eles raramente são utilizados. Atualmente existem diversos compiladores que transformam códigos em linguagem Java para bytecodes como o javac da Sun, Jikes da IBM, GCJ da GNU, entre diversos outros.

No restante do artigo verificaremos melhor como funciona cada uma das etapas do processo de tradução até a execução de um programa Java.

2. Java Virtual Machine

A Java Virtual Machine ou JVM é um interpretador Java que carrega e executa os aplicativos Java que estão em bytecodes, convertendo esses bytecodes em código executável de máquina. Um interpretador nada mais é do que um programa que simula um conjunto de instruções. Dessa forma, não temos uma etapa de montagem separada. A JVM também possui outras

Introdução

Todos os programas passam por quatro etapas de transformação desde o código-fonte armazenado no computador até a etapa que este código será executado na máquina. A Figura 1 abaixo mostra essas etapas de tradução, alguns sistemas combinam essas etapas, porém essas são consideradas as quatro etapas lógicas pelas quais os programas passam.

Figura 1: Etapas de Tradução de uma Linguagem de Programação

Basicamente o processo de tradução e execução de uma linguagem de alto nível começa com um programa em linguagem de alto nível sendo compilado para um programa em assembly, e após essa operação ele é montado, através de um montador, em um módulo objeto em linguagem de máquina. O próximo processo fica por conta do link-editor que combina vários módulos com as rotinas de biblioteca para resolver todas as referências. Para finalizar, o Loader é encarregado de colocar o código de máquina nos locais apropriados da memória, para ser executado pelo processador. Vale salientar que em alguns sistemas pode acontecer de algumas etapas serem puladas ou combinadas para agilizar o processo. Por exemplo, alguns compiladores poderiam produzir o módulo objeto diretamente ou loaders poderiam ser utilizados juntos com o link-editor. Para a identificação correta dos arquivos, o Linux e Unix utilizam os sufixos “.java” para arquivos em Java, “.s” para os arquivos em assembly, “.o” para os arquivos objetos, “.so” para rotinas de bibliotecas link-editadas estaticamente e “.out” para os arquivos executáveis. Já os sistemas Windows utilizam os sufixos “.java” para arquivos em Java, “.asm” para os arquivos em assembly, “.obj” para os arquivos objetos, “.lib” e “.dll” para rotinas de bibliotecas link-editadas estaticamente e “.exe” para os arquivos executáveis.

No restante do artigo verificaremos cada uma dessas etapas e posteriormente finalizaremos o assunto em outro artigo mostrando como o Java entra nesse processo, no entanto primeiramente precisaremos entender como funcionam as etapas básicas no processo de tradução.

Compilador

Um compilador basicamente transforma um programa “.java” ou “.c” em um programa assembly que é a forma simbólica de como a máquina entende. Os programas em alto nível como C e Java utilizam muito menos código do que o assembly, isso aumenta significativamente a produtividade do programador. Isso ocorre porque o assembly possui um número reduzido de instruções que precisam ser combinadas para realizar o que uma única instrução em código alto nível realiza.

No meio da década de 70 os sistemas operacionais e montadores eram todos escritos em assembly, poi

Introdução

Os Padrões de Projeto também conhecidos como Design Patterns (em inglês) são soluções já encontradas, testadas e comprovadas e que podemos aplicar aos projetos sem ter que reinventar a roda. Diversos Padrões de Projeto já foram catalogados e são um conjunto de boas práticas que devemos seguir e utilizar em projetos de software orientados a objetos.

Padrões de Projetos basicamente descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução (contexto) e suas consequências.

Além disso, os Padrões de Projeto também definem um vocabulário comum que facilita a comunicação, documentação e aprendizado dos sistemas de software.

Os padrões de projetos são classificados como:

• Criacionais – definem a criação de objetos;
• Estruturais – definem a composição de classes e objetos;
• Comportamentais – definem a interação entre classes e objetos.

Neste artigo veremos mais sobre o Padrão de projeto Iterator que é utilizado em diversos projetos e na API do Java.

Funcionamento

O Padrão de Projeto Iterator tem como objetivo encapsular uma iteração. O Padrão de Projeto Iterator depende de uma interface chamada Iterator, conforme pode ser vista abaixo:

Figura 1: Exemplo da Interface Iterator

O método hasNext() determina se existem mais elementos para serem iterados. O método next() retorna o próximo objeto da iteração.

Depois que já possuímos a interface podemos implementar iteradores para qualquer tipo de coleção de objetos sejam matrizes, listas, hashtables, etc. Para cada coleção de objetos que queira-se encapsular a iteração cria-se uma implementação para a interface Iterator definida acima. Por exemplo para encapsular uma iteração para um menu teríamos a classe abaixo:

Figura 2: Exemplo de Implementação da Interface Iterator

Um método que poderia fazer parte do nosso diagrama é o “remove” para remover objetos da coleção, no entanto, este é um método opcional, não precisamos necessariamente fornecer recursos de remoção.

O Padrão Iterator é definido como: “O Padrão Iterator fornece uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor a sua representação subjacente”. Portanto, temos que o padrão Iterator permite acessarmos um a um os elementos de um agregado mesmo sem saber como eles estão sendo representados, assim torna-se irrelevante se a coleção de objetos está num ArrayList, HashTable ou que quer que seja. Além disso, o Padrão Iterator assume a responsabilidade de acessar sequencialmente os elementos e transfere essa tarefa para o objeto Iterador, dessa forma o objeto agregador tem a sua interface e implementação simplificadas, não sendo mais o responsável pela iteração.

Exemplo de Implementação

Segue abaixo um exemplo de implementação em Java utilizando o Padrão Iter

Introdução

A ideia inicial de padrão de projeto surgiu em 1977 com Christopher Alexander na área de Arquitetura (prédios e cidades). Seus livros e suas ideias foram usados de inspiração para os desenvolvedores de software. Além da arquitetura e do desenvolvimento de software, outras áreas como a Química e as áreas da Engenharia também possuem catálogos de soluções para problemas recorrentes.

Na área do desenvolvimento de software existe um catálogo de soluções desde 1995 com o livro "Design Patterns - Elements of Reusable Object-Oriented Software". Seus idealizadores foram Gamma, Helm, Johnson e Vlissides. Nesse livro são descritos diversos Padrões de Projetos.

Com o catálogo de Padrões de Projetos passamos a ter um vocabulário em comum, soluções descritas e com nomes descritivos, entre diversas outras vantagens.

Padrões de Projetos normalmente possuem Nome, Problema, Solução e Consequências/Forças.

Neste artigo veremos mais sobre o Padrão de projeto Template Method que é utilizado em diversos projetos e API's do Java.

Funcionamento

O Padrão de Projeto Template Method define os passos de um algoritmo e permite que a implementação de um ou mais desses passos seja fornecida por subclasses. Assim, o Template Method protege o algoritmo e fornece métodos abstratos para que as subclasses possam implementá-los.

A definição oficial do padrão Template Method é: “O Padrão Template Method define o esqueleto de um algoritmo dentro de um método, transferindo alguns de seus passos para as subclasses. O Template Method permite que as subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do próprio algoritmo”.

Portanto, o padrão Template Method basicamente oferece um método que define um algoritmo (uma sequência de passos) que pode, por sua vez, ser definido como abstrato para posteriormente ser implementado por uma subclasse. Pode-se notar que a estrutura do algoritmo fica inalterada mesmo com as subclasses fazendo parte da implementação.

O Diagrama de classe abaixo mostra mais detalhes sobre o funcionamento do padrão Template Method.

Figura 1: Diagrama de classe do Padrão Template Method

No diagrama de classe acima temos a classe AbstractClass

Introdução

Padrões de Projetos fazem parte da tecnologia avançada de orientação a objetos e estão sendo incorporados por ferramentas de análise orientada a objetos, bem como livros, artigos, cursos e seminários. Grupos de estudo sobre padrões são abundantes e sugerem que as pessoas aprendam Padrões de Projetos somente depois de terem dominado práticas básicas de orientação a objetos. Os Padrões de Projeto são modelos de como resolver o problema do qual trata, podendo ser usados em diferentes situações.

Os Padrões de Projetos para software orientado a objetos estão documentados no livro "Design Patterns: Elements of Reusable Object-Oriented Software" que contém um catálogo com 23 padrões de projetos (Design Patterns) orientados a software. A ideia dos autores do livro era documentar problemas recorrentes que aconteciam nos softwares aplicando a ideia de padrões de projeto a projetos de softwares, descrevendo uma estrutura para catalogar e descrever padrões de projeto, catalogar 23 padrões, entre outros.

Neste artigo será descrito o Padrão de Projeto Facade o qual será mais detalhado nas seções subsequentes do artigo.

Funcionamento

O Padrão de Projeto Facade oculta toda a complexidade de uma ou mais classes através de uma Facade (Fachada). A intenção desse Padrão de Projeto é simplificar uma interface. Existem outros dois Padrões de Projetos (Decorator e Adapter) já discutidos em outros artigos que possuem similaridades com o Padrão Facade, porém existem diferenças em relação a este padrão, como será visto mais adiante.

Com o Padrão Facade podemos simplificar a utilização de um subsistema complexo apenas implementando uma classe que fornece uma interface única e mais razoável, porém se desejássemos acessar as funcionalidades de baixo nível do sistema isso seria perfeitamente possível. É importante ressaltar que o padrão Facade não “encapsula” as interfaces do sistema, o padrão Facade apenas fornece uma interface simplificada para acessar as suas funcionalidades. Imagine que existe um sistema com diversas classes contendo diversos métodos e tenhamos que agrupar todas essas classes chamando diversos métodos para realizar uma determinada operação. Tendo uma Facade precisaríamos apenas construir um método que agrupe todas essas classes e chame todos esses métodos. Assim, quando usuário quiser fazer essa operação ele chamaria apenas a Facade que realizaria essa operação, simplificando muito todo o processo com uma simples interface. Vale ressaltar que

Introdução

Grandes especialistas nunca começam resolvendo problemas a partir do zero ou de princípios elementares, mas sim através de soluções comprovadas e que são utilizadas nos mais diversos projetos por diferentes especialistas. Um Padrão de Projeto descreve uma solução geral reutilizável para um problema recorrente no desenvolvimento de sistemas de software orientados a objetos. Os Padrões de Projeto não são códigos prontos ou soluções específicas de um determinado contexto ou domínio e sim um modelo de como resolver o problema do qual trata, que pode ser usada em diferentes situações.

Os Padrões de Projetos para software orientado a objetos estão documentados no livro "Design Patterns: Elements of Reusable Object-Oriented Software" que contém um catálogo com 23 padrões de projetos (Design Patterns) orientados a software. A ideia dos autores do livro era documentar problemas recorrentes que aconteciam nos softwares. Hoje diversos outros livros foram escritos para resolver problemas recorrentes em software, porém esse ainda continua sendo o livro usado por todos os desenvolvedores como o catalogo oficial.

Neste artigo será descrito o Padrão de Projeto Adapter o qual será mais detalhado nas seções subsequentes do artigo.

Funcionamento

O padrão Adapter é muito utilizado quando precisamos encaixar uma nova biblioteca de classes, adquirida de um fornecedor, em um sistema de software já existente, porém essas bibliotecas de classe do novo fornecedor são diferentes das bibliotecas de classes do fornecedor antigo. Como não temos o código do novo fornecedor e também não podemos alterá-la, o que pode ser feito é criar uma classe que faça essa adaptação, ou seja, ela é responsável por adaptar a interface do novo fornecedor ao formato que o sistema espera. O Adapter é muito utilizado para compatibilizar o seu sistema a outros frameworks ou APIs.

Portanto, o adaptador é um intermediador que recebe solicitações do cliente e converte essas solicitações num formato que o fornecedor entenda. O adaptador converte uma interface para outra, porém, também poderíamos ter um caso em que precisaríamos adaptar mais de uma classe, nesse caso entra em cena outro padrão de projeto chamado Facade (Fachada) que é discutido em outro artigo. Se a interface do fornecedor mudar novamente apenas o Adaptador necessitará ser modificado sem alterar o

Introdução

Padrão de Projeto descreve uma solução geral reutilizável para um problema recorrente no desenvolvimento de sistemas de software orientados a objetos. Padrões de Projeto não são códigos prontos e sim modelos de como resolver o problema do qual se trata, que também pode ser usado em muitas situações diferentes.

A origem dos Padrões de Projetos surgiu no trabalho de um arquiteto chamado Christopher Alexander que escreveu dois livros de bastante sucesso onde ele exemplificava o uso e descrevia seu raciocínio para documentar os padrões para a arquitetura (como portas, janelas, etc). Um grupo de quatro profissionais baseou-se em Christopher Alexander e escreveram o livro "Design Patterns: Elements of Reusable Object-Oriented Software" que continha um catálogo com 23 padrões de projetos (Design Patterns) orientados a software. A ideia dos autores do livro era documentar problemas recorrentes que aconteciam nos softwares.

Os Design Patterns são uma coleção de padrões de projeto de software que contém soluções para problemas conhecidos e recorrentes no desenvolvimento de software descrevendo uma solução comprovada para soluciona-los. Os Padrões de Projetos descritos pelos autores do livro Design Patterns são organizados em três famílias: Padrões de criação que são relacionados à criação de objetos, Padrões estruturais que tratam das associações entre classes e objetos e Padrões comportamentais que tratam das interações e divisões de responsabilidades entre as classes ou objetos.

Neste artigo será descrito o Padrão de Projeto Command na qual será mais detalhado nas seções subsequentes do artigo.

Funcionamento

O padrão Command nos diz como criar “objetos de comando” que encapsula uma solicitação para fazer algo em um objeto específico.

Basicamente todos os objetos de Comando implementam a mesma interface, que consiste em um único método normalmente chamado de execute(). Segue abaixo um exemplo desta implementação.

Listagem 1: Exemplo de implementação da interface do Padrão Command

public interface Command {

	public void execute();

}

O Padrão Command tem como definição encapsular uma solicitação como um objeto, o que lhe permite parametrizar outros objetos com diferentes solicitações, enfileirar ou registrar solicitações e implementar recursos de cancelamento de operações.

Analisando a definição do Padrão Command acima, observa-se que ele cita primeiramente o encapsulamento de uma solicitação, ou seja, o método execute() é o responsável por encapsular essa solicitação a um o

Introdução

Os Design Patterns (Padrões de Projetos) são arquiteturas testadas para construir softwares orientados a objetos flexíveis e sustentáveis. Os padrões ajudam a reduzir substancialmente a complexidade do processo de design.

Padrões de Projetos tem sua origem no trabalho de um arquiteto chamado Christopher Alexander que escreveu dois livros de bastante sucesso onde ele exemplificava o uso e descrevia seu raciocínio para documentar os padrões para a arquitetura. Porém em 1995 um grupo de quatro profissionais basearam-se em Christopher Alexander e escreveram o livro "Design Patterns: Elements of Reusable Object-Oriented Software" [Gamma95] que continha um catálogo com 23 padrões de projetos (Design Patterns) orientados a software. A idéia dos autores do livro era documentar problemas recorrentes que acontecia nos softwares.

Os Design Patterns são uma coleção de padrões de projeto de software que contém soluções para problemas conhecidos e recorrentes no desenvolvimento de software descrevendo uma solução comprovada para um problema de projeto recorrente. A Documentação desses padrões permite o reuso e o compartilhamento dessas informações sobre a melhor maneira de se resolver um problema de projeto de software.

Neste artigo será descrito um importante Padrão de Projeto muito utilizado pelos desenvolvedores de software que é o Singleton na qual será mais detalhado nas seções subseqüentes do artigo.

Funcionamento

O padrão Singleton permite criar objetos únicos para os quais há apenas uma instância. Este padrão oferece um ponto de acesso global, assim como uma variável global, porém sem as desvantagens das variáveis globais. Para entendermos e usarmos bem o padrão de Projeto Singleton é necessário apenas dominar bem as variáveis e métodos de classe estáticos além dos modificadores de acesso.

O Padrão Singleton tem como definição garantir que uma classe tenha apenas uma instância de si mesma e que forneça um ponto global de acesso a ela. Ou seja, uma classe gerencia a própria instância dela além de evitar que qualquer outra classe crie uma instância dela. Para criar a instancia tem-se que passar pela classe obrigatoriamente, nenhuma outra classe pode instanciar ela. O Padrão Singleton também oferece um ponto global de acesso a sua instância. A própria classe sempre vai oferecer a própria instância dela e caso não tenha ainda uma instância, então ela mesma cria e retorna essa nova instância criada.