Ouvir rádio online com a tela do celular desligada

agosto 7th, 2018

Por razões de economia de bateria, um aplicativo Android que faz um streaming de uma rádio online pode parar de funcionar após uns 5 minutos sem interação no celular.

Para continuar ouvindo a rádio, mesmo com a tela do celular desligado, você pode alterar uma configuração do seu celular para que o Android não desligue a aplicação. Segue abaixo o passo a passo de como fazer:

 

1 – Acesse as configurações do seu celular

 

 

2- Clica em Bateria

3 -Após abrir a tela de baterias localize o menu superior a direita, (os 3 pontinhos) e abra a opção Otimização de bateria

4- Nesta tela altere a opção de Sem otimização para Todos os apps.  E localize a aplicação da rádio. No exemplo abaixo Nativa 87,9 FM. E altere a opção para Não otimizar. E logo após concluído.

 

Com esta opção selecionada, a aplicação não entrará mais em modo de hibernação para economizar bateria, e você poderá ouvir a sua rádio sem interrupção com a tela do seu celular desligada.

Posted in Android | Comments Closed

Java Efetivo – Effective Java (Joshua Bloch)

fevereiro 7th, 2016

Java Efetivo

Criar e destruir objetos

Item 1: Considere métodos criadores estáticos ao invés de construtores

  • Diferente de construtores eles tem um nome
  • Não é obrigado a sempre criar um novo objeto com new, cada vez que é chamado.
  • Pode retornar um objeto de qualquer subtipo do tipo de retorno. Ex.: Retornar uma interface com classes não publicas (API Collections); Service Provider Framework, JDBC.
  • Reduz a verbosidade da criação de instancias de tipos parametrizados. (Na versão Java SE 7 não é mais necessário).
  • Classes sem construtores public ou protected não podem ser instanciadas com subclasses.
  • Na sua leitura ele não é tão fácil de distinguir quanto por construtores. Deve-se ter maior atenção no seu JavaDoc e atenção nos nomes dos métodos,

Item 2: Considere Builders quando se encontrar com muitos parâmetros de construção. Ex:

 

NutritionFacts cocaCola = new NutritionFacts.Builder(240,8).caloris(100).sodium(35).carbohydrate(27).build();

 

Item 3: Reforce a padrão Singleton com um construtor privado ou o tipo enum.

Item 4: Reforce objetos não instanciáveis com um construtor privado.

Item 5: Evite a criação de objetos desnecessários.

public Boolean isBabyBoomer() {

//Unnecessary allocation of expensive object

Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone(“GMT”));

}

public class Person {

private static final Date BOOM_START;

static {

Calendar gmtCal = Calendar.getInstance();

BOOM_START = gmCal.getTime();

}

}

}

Item 6: Elimine a referência a objetos obsoletos, não utilizados.

Item 7: Evite finalizers

Métodos Comuns a todos os objetos

Item 8: Sobrescreva o método equals da maneira correta.

Item 9: Sempre sobrescreva o método hashCode quando sobrescrever equals.

Item 10: Sempre sobrescreva o método toString.

Item 11: Sobrescrever o método clone com muito cuidado e quando for estritamente necessário.

Item 12: Considere implementar a interface Comparable

Classes e Interfaces

Item 13: Minimize o acesso a classes e membros

As vezes não há necessidade de criar todas as classes como pública, ex. As classes do pacote das coleções, muitas classes utilizadas não são públicas.

Item 14: Em classes públicas utilize métodos e não campos públicos.

Item 15: Minimize a mutabilidade.

Item 16: Previra a composição ao invés da herança

Principalmente se herdar de classes de outra package

Item 17: Projete e documente para herança ou então proíba-a.

Item 18 – Prefira interfaces ao invés de classes abstratas.

Como a linguagem não permite herança de mais de uma classe isso pode se tornar uma limitação e além disso através de interfaces uma classe pode ser de vários tipos, chamado mixin.

Pode ser fazer uma combinação entre intrefaces e suas implementações em classes abstratas.

Item 19 – O uso de interfaces somente para definir tipos

O uso de interfaces para definir constantes é um péssimo exemplo de uso. A sugestão para definir constantes é utilizar uma classe estática utilitária, além de import estáticos para facilitar a programação.

Item 20 – Preferível utilizar uma hierarquia de classes do que classes que contenha um atributo que definam seu tipo, tagged classes

Item 21 – Utilizar funcion objects para representar strategies

Item 22 – Prefira membros de classes estáticas ao invés de não-estática.

Se declarar um membro de classe que não precise acessar a classe pai, sempre declarar como estática.

Generics

Item 23 – Não utilize tipos “crus” em códigos novos

Preferir a utilização de código utilizando generics como a classe List<E>.

Item 24 – Elimine os “unchecked warnings”

Evitar utilizar a sua anotação e se não for possível comentar e utilizar no mínimo escopo possível como numa variável local. Evitar no método e nunca utilizar no nível de classe.

Item 25 – Prefira listas ao invés arrays

Arrays são covariantes e listas não, isso garante segurança nos tipos de dados utilizados em tempo de compilação.

Item 26 – Prefira tipos genéricos

Tipos genéricos evitam exceção por tipo de classe quando se utilizam cast para forçar troca de tipo.

Item 27 – Prefira métodos genéricos

Para evitar o uso de cast no retorno do método. Aumenta a segurança do código, deixa mais claro e mais enxuto.

Item 28 – Utilize bounded wildcards para incrementar a flexibilidade da API

Ex: public método(<?extends E> param)

Utilizar a PECS – Producer extends, consumer super

Não utilizar wildcards para retorno. Pois o código de cliente também terá que utilizar.

Item 29 – Considere contêineres heterogêneos com tipos seguros

Ao invés de utilizar como nas classes de coleções, que fixam um tipo específico para sua utilização, ex: List<String> pode-se utilizar uma nova estratégia que define o tipo que será utilizado como parâmetro com a classe Class. Ex:

Pode-se ter um tipo como DatabaseRow representando uma linha da tabela (o contêiner no caso) e um tipo genérico representando a sua chave Column<T>. É um design mais sofisticado para não fixar o parâmetro fixo da classe contêiner.

Enums e Annotations

Item 30 – Utilize enum ao invés de constantes int

Muito mais legível e prático.

Item 31 – Utilizar campos de instância ao invés de ordinais

Melhor utilizar um atributo definido num enum, do que a sua ordem para representar alguma regra no programa.

Item 32 – Utilize EnumSet ao invés de campos de bits (bit fields)

Aliando a melhor funcionalidade de utilizar Enum aliada a funcionalidade de bit fields, não há necessidade de utilizar campos de bit fields.

Item 33 – Utilize EnumMap ao invés de indexação ordinal

Ao invés de utilizar o valor ordinal do Enum para um índice de array, por exemplo. Deve-se utilizar a estrutura de dados EnumMap.

Item 34 – Emule enums extensíveis com interfaces.

Pode-se criar uma interface para que um Enum implemente e assim trabalhar utilizando esta interface.

Item 35 – Prefira anotações ao invés de padrões de nomes

Utilizando reflexão podemos buscar uma definição utilizando uma anotação para verificação ao invés de utilizar uma padrão de nomes. Ex.:

@Test no métodos ao invés de testFuncio() como padrão de nome

Item 36 – Sempre utilizar s a anotação @Override

Evita BUGs no código, pois em tempo de compilação verifica-se que deve se sobrescrever o método em questão.

Item 37 – Utilize interfaces marcadoras para definição de tipos

Mesmo não tendo métodos uma interface pode ser utilizada para definir um tipo, chamada de interface de marcadora. Em outros casos pode-se utilizar uma anotação de marcação. Mas sempre quando se refere-se a um tipo deve se utilizar um interface de marcação.

Métodos

Item 38 – Valide os parâmetros

Item 39 – Faça cópias de segurança quando necessário

Faça uma cópia defensiva para cada parâmetro mutável que o construtor possui.

Item 40 – Design assinaturas dos métodos cuidadosamente

– Escolha do nome do método bem feita

– Não exagera no número de métodos, por exemplo, numa interface.

– Evitar uma longa lista de parâmetros

– Melhor utilizar interfaces do que classes para parâmetros que se refiram a tipos.

– Prefira uma enum com dois tipos do um boolean como parâmetro

Item 41 – Utilize sobrecarga de metódos, overloanding, com cuidado.

Overloading, sobrecarga de métodos é decidido em tempo de compilação. Já o overriding que é a sobrescrita dos métodos nas classes filhas é feito em tempo de execução.

Dica: nunca tenha dois métodos de sobrecarga com o mesmo número de parâmetros, somente se eles tenham exatamente o esmo comportamento.

Item 42 – Utilize varargs com cuidado.

Utilizar somente em casos em que necessite passar um número variável de parâmetros.

Item 43 – Retorne arrays ou coleções vazias ao invés de null.

A classe cliente não precisar utilizar dois testes para saber se a coleção esta vazia.

Item 44 – Faça documentação de todas as APIs expostos, ou seja, estão como publico.

Programação em Geral

Item 45 – Minimize o escopo das variáveis locais. Só instancie uma variável local quando for utilizá-la.

Item 46 – Preferia for-each loops do que os loops tradicionais. A não ser que o tenha que trabalhar sobre a coleção em questão como remoção.

Item 47 – Conheça e use as bibliotecas padrões do java, ao invés de criar as suas

Item 48 – Evite utilizar double e float para resultados exatos. Como valores financeiros. Até 9 dígitos utilize int, até 18 long e após isso BigDecimal.

Item 49 – Prefira tipos primitivos ao invés das classes wrapper de primitivos. Muito cuidado para utilizar comparações com entre wrapper.

Item 50 – Evite Strings onde outros tipos são mais apropriados.

Item 51 – Evite a concatenação de strings, utilize StringBuilder.

Item 52 – Referencie objetos pelas suas interfaces.

Item 53 – Prefira interfaces pra reflexão.

Item 54 – Utilize métodos nativos com cuidado.

Item 55 – Otimize cuidadosamente

Não sacrifique a arquitetura em função de performance.

Posted in Java EE, Java SE | Comments Closed

JSF View Acion

novembro 12th, 2015

 

When to use f:viewAction / preRenderView versus PostConstruct?

http://stackoverflow.com/questions/9844526/when-to-use-fviewaction-prerenderview-versus-postconstruct

Posted in Java EE | Comments Closed

unindexed foreign key columns

maio 7th, 2015

O Hibernate não gera índices para as colunas de chaves estrangeiras, nos banco de dados Oracle e Postgres. No mysql por ser obrigatório ter índice na chave estrangeira o hibernate gera.

Referências

http://stackoverflow.com/questions/2970193/getting-hibernate-to-generate-indexes-on-foreign-keys

http://blog.pdark.de/2009/12/15/finding-unindexed-foreign-key-columns/

Posted in Java EE | Comments Closed

Solução para o Brasil

março 17th, 2015

1) Reforma política
2) Descentralização do governo
3) Fim do fórum privilegiado de políticos

Posted in Pessoal | Comments Closed

Fotos da Família Becker Gois

janeiro 3rd, 2015

Algumas fotos que digitalizei, só clicar nelas para ver em tamanho maior.

 

015 014 013 012 011 010 009 008 007 006 005 004 003 002 001

Tags:
Posted in Pessoal | Comments Closed

Para refletir

outubro 22nd, 2014

Esse texto não é de minha autoria, mas reflete perfeitamente a minha opinião. E sem dúvida foi o mais sensato que li em toda a campanha eleitoral.

“Há muitas mensagens circulando contra e a favor de cada candidato.
Resolvi fazer a minha. Não me lembro de ter me engajado em uma campanha eleitoral. Sempre votei consciente, mas nunca fui para militância.
Hoje, tenho um filho que herdara o mundo que estamos construindo. Isso me obriga a ser mais ativo.
Parto de duas premissas:

I) todo homem, por menor parcela de poder que detenha, tende a dela abusar (Maquiavel);

II) não há uma só pessoa boa sem defeito, a qualidade está na supremacia dos benefícios em relação aos defeitos.

Por isso, não me iludo em pretender encontrar a perfeição em Aécio. Porém, estou convencido que suas qualidades positivas superam as negativas.
Por outro lado, também não nego os benefícios que o PT trouxe ao Brasil. Porém, está evidente que ultrapassou qualquer limite do razoável.
A ambição pelo poder destruiu o discurso da ética, da democracia, da nova forma de governar. Tudo isso, a tal ponto, que ofuscou completamente qualquer avanço que tenha feito.
Nada do que fizera justifica as mazelas que trouxe.
O projeto, está evidente, é de poder e não de Estado.
As instituições públicas estão aparelhadas por petistas e seus aliados, em prejuízo da escolha de pessoas técnicas, a meritocracia.
A corrupção, com o fim claro de abastecer o esquema, foi institucionalizada.
Contra o jogo democrático, se ataca a honra dos adversários e se propalam mentiras, com um cinismo sem precedentes. Frauda-se, assim, o próprio jogo democrático, à medida que, confunde-se o eleitorado de forma orquestrada.
O presidente Lula e a presidente Dilma, de forma vexatória, negam a prática do mensalão e todos os outros episódios de corrupção. Isso é gravíssimo. As pessoas mais influentes do sistema presidencialista atribuem normalidade a crimes graves. Essa é uma mensagem desastrosa para toda sociedade, sobretudo aos menos esclarecidos.
A cúpula do PT, que ainda define nossos destinos, está presa e é tratada, por eles, como injustiçados.
Não fossem os votos do beneficiários do Bolsa família, das ong’s, do MST, todos sustentados pelos que trabalham, a Dilma teria perdido no primeiro turno.
Esse ponto merece atenção especial. Para tanto, invoco o pensamento de dois grandes sábios: Aristóteles e Luiz Gonzaga.
O primeiro, 400 anos antes de Cristo, chamou a atenção para o risco do sistema democrático se transformar na ditadura da plebe, o que já está acontecendo, pelo populismo e pelo terror com as ameaças de suspensão do bolsa família. Ou seja, por pouco nossa democracia não existe apenas no papel, enquanto, de fato, somos governados por uma ditadura disfarçada.
Já Luiz Lua Gonzaga, antevendo tudo isso, há mais de cinquenta anos, afirmou: Seu dotô o nordestino tem muita gratidão, pela ajuda do sulista nessa seca do sertão, mas dotô uma esmola a um homem que é são, ou lhe mata de vergonha ou vicia o cidadão.
Hoje estamos assistindo a formação de uma sociedade de viciados pela esmola do Estado, sem o menor estímulo de evoluir para o mercado de trabalho. Se contentando a viver à margem da dignidade humana.
E muitos outros argumentos poderia elencar. Para não ficar enfadonho, limito-me a esses.
Por tudo isso, resolvi me engajar nessa luta, pela alternância de poder e sugerir a cada amigo uma reflexão sobre qual país queremos para nossos filhos.
Se pensar como eu, divulgue, tente conquistar pelo menos 45 votos para Aécio.
Se ele nos decepcionar, na próxima a gente muda de novo. ”
Repassem se concordar com TUDO!

Tags:
Posted in Pessoal | Comments Closed

ALM na Prática – Redmine

agosto 17th, 2013

ALM (Application Lifecycle Management)

Dentresas ferramentas open sources utilzadas para alicar ALM
Redmine – Gestão de projetos, requisitos e bugs
Maven – Builder, construtor padrão da aplicação, independente de IDE
Nexus – Gestão de componenetes de software, não apenas de tela mais de negócio. Modularidade das aplicações e retulização.
Jenkins – Builder da aplicação, agendador de validação do builder, testes automatizados e inspeção de código integrado com o sonar.
Sonar – Inspeção de código, checkstyle, findbugs, etc. Chamado e integrado pelo Jenkins

Este artigo vai demostrar a utilização da ferramenta Redmine com foco na sua integração com o SVN, e ver como é bacana o desenvolvedor através do comentário do commit vincular suas atividades a uma Issue (Tarefa) e até mesmo apontar o número de horas trabalhadas nesta tarefa.

Uma descrição mais completa da ferramenta pode ser obtida no site http://www.redmine.org/

 

Esta é a tela inicial do Redmine.

001-redmine-inicio

 

 

Tudo no Redmine é organizado por projetos, ou seja, um projeto é bem independente do outro, talvez até por isso uma das primeiras coisas a se fazer quando entra na ferramenta é escolher um projeto.

No projeto há várias opções e a tela inicial (visão geral) já da uma visão de quantas tarefas estão abertas e fechadas para este projeto, tempo trabalhado

002-redmine-projeto

 

 

Em atividades mostra tudo o que foi trabalhado no projeto, entre tarefas abertas, fechadas alteradas e commits com seus comentários no SVN

003-redmine-atividades

 

 

Em tarefas mostra… as tarefas to projeto. Lembrando que a customização dos filtros de pesquisa no Redmine são extremamente flexíveis e pode até mesmo salvar uma consulta feita.

004-redmine-tarefas

 

 

Com base nas tarefas do projeto, e das datas informadas nelas, pode-se obter um gráfico de Gantt.

005-redmine-gantt

 

 

Há um calendário para melhor visualização das atividades e seus prazos do projeto.

006-redmine-calendario

 

 

E aqui o mais legal, a visão do repositório. É possível ver as alterações realizadas no fonte, comparações entre versões do fonte e os comentários nos commits.

007-redmine-repositorio

 

Lembrando que estes são as opções que vem na instalação padrão do Redmine, há um número vasto de plugins que podem ser instalados, como plugin http://www.redmine.org/plugins que podem complementar algumas funções e relatórios.

Como falei o Redmine deixa tudo personalizado por projeto, e por isso ele tem as suas opções em configurações. Lá podemos escolher quais os membros, categorias de tarefas, o repositório do projeto e quais as atividades para registro de horas estão habilitas para o projeto.

008-redmine-configuracoes

 

 

Todas as opções globais, são feitas na Administração, lá pode se criar os projetos, cadastras usuários, grupos, perfis, configurar o modo de autenticação como apontando para um servidor LDAP (geralmente MS AD) da empresa, os tipos de tarefas, as situações de tarefas.

 

009-redmine-administracao

010-redmine-admin-tipos-tarefa

011-redmine-admin-situacao-tarefas

 

 

E na configuração de repositórios nas configurações globais do Redmine, observa-se quais os clients estão instalados no servidor, no caso estão os git client e svn client. É necessários instalar as versões clients para que o Redmine possa acessar os repositórios de fontes.

012-redmine-admin-repositorio-1

 

 

Aqui pode se configurar as PALAVRAS DE REFERÊNCIA que encontradas no comentário do SVN automaticamente tem se uma atividade no redmine, como por exemplo se digitarmos no comentário:

refs #10 comentário do svn

Este comentário vai automaticamente ser vinculado à atividade 10.  Assim como fixes pode fechar a atividade

fixes #10 atividade fechada.

E também pode-se habilitar o registro de horas pelo comentário do svn. Observa-se  que pode ser definir qual a atividade padrão para registros de horas. Além de para qual situação a atividade é alterada quando encontrar a palava fixes.

013-redmine-admin-repositorio-2

 

 

Aqui é a referência no site oficial do redmine.

014-redmine-rastreabilidade-time-track-COMMIT-1

 

Agora vamos há um exemplo.

Primeiro criamos uma atividade no Redmine. Com um tempo estimado de 2 horas.

015-redmine-tarefa-DES-01

 

Quando o programador fazer o commit, ele pode associar a uma tarefa. Exemplo:

“refs #1 @1h30”

 

onde @1h30 vai informar que o programador trabalhou 1h30 nesta atividade.

016-redmine-rastreabilidade-time-track-COMMIT-2

 

 

E no menu atividades observa-se esta atividade do SVN.

017-redmine-rastreabilidade-time-track-COMMIT-3

 

 

E na tarefa, pode-se ver que ela já adicionou esta 1h30 de trabalho no registro de horas.

018-redmine-rastreabilidade-time-track-COMMIT-4

 

 

E a visão das atividades realizadas no código fonte que estão no repositório pelo redmine.

019-redmine-rastreabilidade-time-track-COMMIT-5

 

 

Agora vamos apontar para fechar a atividade.

“closes #1 @0:15”

020-redmine-rastreabilidade-time-track-COMMIT-6

 

 

Não esquecer de habilitar o registro de horas e para qual atividade será registrado as horas na configuração do Redmine.

021-redmine-rastreabilidade-time-track-COMMIT-7

 

 

Agora o comentário do svn irá encerrar a atividade, além de registrar 15 minutos de trabalho

“closes #1 @0h15”

022-redmine-rastreabilidade-time-track-COMMIT-8

 

 

E nas Atividades do projeto, visualiza-se tudo o que foi trabalhando no projeto, atente-se ao vínculo para SVN.

023-redmine-rastreabilidade-time-track-COMMIT-9

 

 

E a tarefa automaticamente fechada, somente pelo comentário do SVN.

024-redmine-rastreabilidade-time-track-COMMIT-10

 

E na visualização da tarefa observa-se todas as ações realizadas nesta tarefa como a alteração da situação e o registro de horas. Tudo isso feito apenas pelo desenvolvedor pelo comentário no SVN!

025-redmine-rastreabilidade-time-track-COMMIT-11

 

 

O registro de horas…

026-redmine-rastreabilidade-time-track-COMMIT-12

 

E para finalizar o envio automático do email para os envolvidos no projeto.

027-redmine-rastreabilidade-time-track-COMMIT-13

 

Posted in ALM | Comments Closed

Supero Way*

maio 25th, 2013

*Nome sugerido pode mudar

É o modo de desenvolver softwares utilizando frameworks e soluções open-sources. Abrange todo o ciclo de desenvolvimento de um software com objetivos claros de produtividade e qualidade.

 

GOALS
– Não é uma definição de regras e imposição do modo de desenvolver softwares
– Evita atividades manuais com copy/paste para desenvolver novas funcionalidades
– Ferramentas conhecidas e amplamente utilizadas pela comunidade open-source
– Automatização e geração de código limpo e sem lixo para CRUD e é facilmente customizável.
– O projeto gerado é um full complice java EE 6, ou seja, é o PADRÃO para aplicações java corporativas.
– O desenvolvedor tem o foco em atender o cliente e na solução do negócio e não na infraestrutura e na integração de várias tecnologias
É composto de:

IDE
Eclipse + JBoss Tools ou Jboss Developer Studio
Ferramenta Forge com scaffold, ou seja, geração de telas e operações CRUD.

JavaEE 6 PURO!
Isto é (JPA2, EJB3, CDI1.0, JAX-RS, JAX-WS, JSF2)
JPA2 – Persistência em banco de dados.
EJB3 – Regras de negócios, operações transasionais, segurança, pool de recursos
CDI1 – Inversão de controle, contexto e injeção de dependência.

JAX-RS – Web services RESTfull

JAX-WS – Web services SOAP
JSF2 – Apresentação com JSF
Primefaces – Extensão do JSF, biblioteca com vários componentes
JQuery-Mobile – Camada de apresentação para o navegador de móbiles.

ALM (Application Lifecycle Management)
Redmine – Gestão de projetos, requisitos e bugs
Maven – Builder, construtor padrão da aplicação, independente de IDE
Nexus – Gestão de componenetes de software, não apenas de tela mais de negócio. Modularidade das aplicações e retulização.
Jenkins – Builder da aplicação, agendador de validação do builder, testes automatizados e inspeção de código integrado com o sonar.
Sonar – Inspeção de código, checkstyle, findbugs, etc. Chamado e integrado pelo Jenkins

Testes
Junit + Arquiliam

 

Posted in ALM, Análise e Projetos de Sistemas, Java EE, Java SE | Comments Closed

Análise e Projeto de Sistemas Orientados a Objetos

março 30th, 2013

No ano de 2006 elaborei meu trabalho de conclusão de curso sobre este tópico de Análise e Projeto de Sistemas Orientado a Objetos, pode ser acessado aqui ( a partir do capítulo 5 é que se inicia a parte de engenharia de software) . É um assunto pouco comentado, e até mesmo um pouco polêmico, pois é muitas vezes confundido com uma parte de documentação chata no desenvolvimento de software.

Mas muito pelo contrário, é uma fase fundamental para o sucesso na entrega do software. Pois é neste momentos que como já diz no título, analisamos e projetamos o futuro software, tentamos mapear o máximo possível das possibilidades nas regras é onde o usuário já tem uma ideia da carinha do sistema e também tudo que ele vai abranger nesta primeira entrega do software, ou seja, a importantíssima definição do escopo do projeto.

Neste ano de 2006, pesquisei bastante, li vários livros para ter um bom embasamento teórico na escrita do TCC e consequentemente aprendi várias técnicas para a análise e a elaboração de um bom projeto de software. É muito melhor pensar antes de executar, dominar um pouco, não tudo da linguagem UML também é fundamental para documentar esta fase de estudo, análise, reuniões, prototipagem e entendimento do negócio e suas regras que o futuro software irá atender.

A metodologia RUP (Rational Unified Process), também chamado de UP (Unified Process), Processo Unificado, que está fortemente associado à notação UML, é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsível. A figura 1 exibi uma visão geral dos processos envolvido no RUP.

Figura 1 – RUP, visão geral (RUP, 2003)

Figura 1 – RUP, visão geral (RUP, 2003).

O RUP comporta, em suas recomendações, as antigas fases de estudo de viabilidade, análise de requisitos, análise de domínio, e o projeto em múltiplas camadas (WAZLAWICK, 2004).

O ciclo de vida de software do RUP é dividido em quatro fases sequenciais (Figura 2), cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais.

Figura 2 – As fases e os marcos de um projeto RUP (RUP, 2003)

Figura 2 – As fases e os marcos de um projeto RUP (RUP, 2003)

 

WAZLAWICK, 2004 defini da seguinte forma as seguintes etapas.

– A fase de iniciação ou concepção incorpora o estudo de viabili­dade e uma parte da análise de requisitos.

– A fase de elaboração incorpora a maior parte da análise de requisitos, a análise de domínio e projeto.

– A fase de construção corresponde à programação e testes,

– e a fase de transição consiste na instalação e manutenção do sistema

A seguir defino melhor cada etapa do processo:

Fase de Iniciação ou Concepção

A fase de concepção, (inception), deve ser a primeira do pro­cesso de desenvolvimento de software, na qual se procura levantar os princi­pais requisitos e compreender o sistema de forma abrangente (WAZLAWICK, 2004).

Esta fase inicial indica o nascimento da idéia sobre um novo software. Pode consistir da discussão sobre um problema que ocorre na em­presa ou nos clientes e que eventualmente poderia ser resolvido ou minimizado com o desenvolvimento de um sistema informatizado (QUADROS, 2002).

Nesta etapa, não é realizado nenhum tipo de estudo aprofun­dado sobre o sistema, no entanto, podem ser feitas algumas projeções grossei­ras que permitam inferir, ainda que com pouca precisão QUADROS (2002): Quanto tempo o software levaria para ser desenvolvido? Quanto o software custaria para ser desenvolvido? Quais benefícios o projeto traria para a em­presa ou para o cliente?

Segundo RUP (2003)  os principais objetivos da fase de concepção incluem:

a)    Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.

b)    Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design.

c)    Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos.

d)    Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir).

e)    Estimar riscos em potencial (as origens de imprevistos).

f)  Preparar o ambiente de suporte para o projeto.

 

A fase de concepção é onde se buscam as primeiras informações sobre o sistema a ser desenvolvido e contem as seguintes atividades:

  • Levantamento de requisitos
  • Organização dos requisitos.

A etapa de levantamento de requisitos corresponde a buscar junto ao usuário, seus sistemas e documentos, todas as informações possíveis sobre as funções que o sistema deve executar e as restrições sob as quais o sistema deve operar. O produto desta etapa será o documento de requisitos, primeiro componente do anteprojeto de software (WAZLAWICK, 2004).

A etapa de organização dos requisitos serve para estruturar os requisitos para que possam ser abordados nos ciclos de desenvolvimento. Grande parte dos requisitos será acomodada em processos de negócio conhecidos como casos de uso. Outros requisitos poderão ser associados a operações simples (como cadastros), outros ainda serão meramente consultas. Os casos de uso, cadastros e consultas serão abordados nos diferentes ciclos, priorizando-se os elementos mais críticos (normalmente casos de uso), e deixando-se para o final os mais elementares (cadastros e consultas) (WAZLAWICK, 2004).

 

Esta etapa é a de definição do escopo do projeto. Ao final desta, tem-se o primeiro Marco (milestone), o Lifecycle Objective Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

  • Sumário Executivo ou Documento de Visão Geral do Sistema, incluindo requerimento, recursos principais e restrições.
  • Glossário do projeto, explicando os termos peculiares ao desenvolvimento do mesmo (opcional).
  • Caso de uso inicial (descrito utilizando a UML).
  • Levantamento dos requisitos.
  • Um ou mais protótipos.

 

Fase de Elaboração

No início da elaboração, o profissional tem uma vaga idéia dos requisitos que o software deverá atender. Nesta fase, o profissional deverá investigar a fundo os obstáculos (riscos) que o projeto pode encontrar. Tais riscos como: Riscos de requisitos, riscos tecnológicos, riscos de habilidades, riscos políticos (QUADROS, 2002).

Além da análise dos riscos, a elaboração é marcada pela definição detalhada do escopo e dos requerimentos do software a ser desenvolvido. Esta definição dos requerimentos deve ser formalizada por escrito através de um documento denominado Documento de Levantamento e Especificação de Requerimentos de Usuário (DLERU). O DLERU deve ser submetido ao usuário/cliente sempre que possível para que ele seja avaliado (QUADROS, 2002).

A meta da fase de elaboração é criar a baseline (a base de sustentação) para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura (RUP, 2003).

 

A fase de elaboração se inicia com uma sub-fase análise e prossegue com uma sub-fase de projeto. A sub-fase de análise em si comporta três atividades distintas realizadas na seguinte ordem (WAZLAWICK, 2004):

  • Expansão dos casos de uso e determinação dos eventos de sistema.
  • Construção do modelo conceitual.
  • Elaboração dos contratos de operações de sistema.

 

A expansão dos casos de uso corresponde ao aprofundamento da análise de requisitos. Já a modelagem conceitual corresponde à análise de domínio em seus aspectos estáticos. Por fim, a elaboração dos contratos corresponde à especificação funcional dos aspectos dinâmicos da análise de domínio (WAZLAWICK, 2004).

A subfase de projeto pode se dividir em diversas tarefas com objetivos distintos WAZLAWICK (2004). As tarefas serão:

  • Projeto da camada de domínio.
  • Projeto da camada de interface.
  • Projeto da camada de persistência.

 

O projeto da camada de domínio compõe-se basicamente de duas atividades: definir os diagramas de colaboração e elaborar o diagrama de classes de projeto (WAZLAWICK, 2004).

O projeto da camada de interface mostra como manter a independência entre a camada de domínio e a interface do software. O projeto da camada de persistência mostra como implementar um sistema de persistência que automatiza o salvamento e a recuperação de dados em disco (WAZLAWICK, 2004).

 

O objetivo dessa etapa é analisar o domínio do problema, estabelecer uma fundação, desenvolver o plano de projeto e eliminar os elementos de maior risco do projeto. Ao final dela, tem-se o segundo Marco (milestone), o Lifecycle Architecture Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

  • Um caso de uso praticamente pronto com uma descrição completa dos atores e cenários de uso.
  • Descrição das operações e consultas de sistema.
  • Modelagem Conceitual
  • Os Contratos de operações e consultas de sistema.

 

Fase de Construção

A construção é a fase do processo cujo final é marcado pela disponibilização do produto de software (um arquivo executável ou uma página Web, por exemplo) para os clientes ou usuários (QUADROS, 2002).

Durante essa etapa, os profissionais estarão primeiramente modelando o software utilizando alguma notação, tais como a definida pela UML. Após a modelagem, a fase de construção é marcada pela codificação do software, onde os desenvolvedores estarão fazendo uso de alguma ferramenta de programação, bem como criando as estruturas de apoio, tais como o banco de dados com suas tabelas e outros elementos (QUADROS, 2002).

A fase de construção é também composta pela homologação que consiste na realização de testes de garantia de qualidade como o produto antes do envio para o cliente. A documentação do produto encerra essa fase do processo de desenvolvimento, juntamente com a disponibilização de todo o conjunto do produto para o cliente (software, manuais de treinamento e referência). A vantagem desta abordagem está em se permitir definir deadlines (limites) intermediários pra os vários subprojetos, impedindo que os problemas e os atrasos se evidenciem apenas no final do projeto (QUADROS, 2002).

A meta da etapa de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição (RUP, 2003).

Ao final desta etapa, temos o terceiro Marco (milestone), o Initial Operational Capability Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

  • O produto (software) completamente operacional.
  • Os manuais do produto.

O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta (RUP, 2003).

 

Fase de Transição

Nesta fase, o produto já foi entregue e são feitas as manutenções corretivas e as otimizações de pequeno porte (que não envolvam uma completa reconstrução do software) (QUADROS, 2002).

O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto (RUP, 2003).

No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado (RUP, 2003).

A Fase de Transição entra quando uma baseline estiver desenvolvida o suficiente para ser implantada no domínio do usuário final. Isso normalmente requer que algum subconjunto usável do sistema tenha sido concluído com nível de qualidade aceitável e documentação do usuário, de modo que a transição para o usuário forneça resultados positivos para todas as partes (RUP, 2003).

Com base na análise feita neste Marco, a empresa poderá decidir finalmente pela disponibilização do produto para os clientes. Ao final do projeto, deve ser feita também uma revisão do cronograma físico-financeiro de forma a avaliar a adequação final do projeto com relação ao planejamento inicial. A fase de transição poderá, dependendo do feedback dos usuários, coincidir com o início de um novo ciclo de desenvolvimento (QUADROS, 2002).

 

Referências

QUADROS, Moacir. Gerência de Projetos de Software. Técnicas e Ferramentas. São Paulo: Visual Books, 2002.

RUP. Rational Unified Process.  2003. Disponível em <http://www.wthreex.com/rup>.Acessado em: 24/04/2006.

WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Ed Campus Ltda, 2004.

 

Tags: , , , , ,
Posted in Análise e Projetos de Sistemas | Comments Closed

« Older Entries