package roseindia.tutorial.hibernate;

import java.util.Iterator;
import java.util.List;

import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;

public class HibernateHQLMaxFunction {

/**
* evertongomede@gmail.com
*/
public static void main(String[] args) {
// TODO Auto-generated method stub

Session sess = null;
try {
SessionFactory fact = new Configuration().configure().buildSessionFactory();
sess = fact.openSession();
String SQL_QUERY = "select max(c.id)from Cliente c";
Query query = sess.createQuery(SQL_QUERY);
List list = query.list();
System.out.println("Max : " + list.get(0));
sess.close();
}
catch(Exception e){
System.out.println(e.getMessage());
}
}
}

Mais uma coisa legal do grupo de UML

"É muito comum o pessoal classificar como retrabalho alguns refinamentos comuns. É interessante ressaltar que a maneira como um software é produzido necessita de um processo empírico por ser de natureza criativa. Antes de prosseguir, precisa estar claro que o desenvolvimento de software é uma atividade criativa, se vcs não concordam podemos discutir aqui.

Determinados processos são prescritivos, isto é, possuem pontos observáveis que a cada passo podem ser verificáveis como válidos. A construção de uma ponte segue um processo prescritivo. Uma linha de montagem de um produto é um processo prescritivo. A forma que um cartório funciona é um processo prescritivo. Uma característica importante dos processos prescritivos é que se caso o produto final não atenda o nível de qualidade que você espera o custo é muito alto para reconstruir esse produto novamente ou para reparar a falha. Como exemplo, se um carro ao final da linha de produção foi montado de maneira errada é praticamente impossível recolocá-lo na linha para que seja produzido da maneira certa. É mais barato jogar o carro no lixo e corrigir a linha de produção.

O software não possui passos intermediários que possam ser verificáveis como válidos. Quando você captura requisitos você não tem certeza que eles solucionarão o negócio, quando você elege uma arquitetura não tem certeza se ela será suficiente, quando você codifica soma-se a essas incertezas aspectos técnicos e também com relação ao futuro. Nós só conseguimos reduzir essa incerteza quando o usuário olha a aplicação. Por conta disso, chegamos à declaração abaixo:

DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZA

Com relação a retrabalhos, imagine que você capturou requisitos com relação a tela de pedidos e com a entidade de pedidos. Você modelou e implementou de acordo com o que você definiu como objetivos da sua iteração. Você mostra a tela para o usuário, ele gostou do que viu, mas ainda falta algumas coisas que podem fazer parte da próxima iteração. O fato de você ter que mexer na tela novamente ou na entidade não significa
necessariamente retrabalho e sim refinamentos. O que mostra o andamento do projeto é o cumprimento desses objetivos e não o número de telas implementadas. Se depois, na 20 iteração, algum conceito de negócio necessite de mais ajustes na entidade pedido também não será retrabalho, simplesmente é o software amadurecendo. Não considero ter que mexer em coisas já implementadas como retrabalho, principalmente se o processo é
ágil. Nós trabalhamos dessa maneira porque o PRODUTO SOFTWARE nos permite que o tratemos dessa forma. O custo para ajustar os conceitos no SOFTWARE não segue o padrão de um produto de processo prescritivo. A tecnologia nos permite construir o software dessa maneira. Isso nos leva a outro conceito:

SOFTWARE = IDÉIA

Idéias são coisas que amadurecem. É bem raro uma maçã cair na sua cabeça e de uma hora para outra você ter a idéia completa de como resolver com um software o caos aéreo no Brasil. O software assim como uma campanha publicitária, ou uma ação de marketing, ou um novo produto, é algo que floresce com a participação de muitas pessoas e chega a maturidade em constante inspeção e adaptação."

RODRIGO YOSHIMA

Um grupo de cientistas colocou cinco macacos numa
jaula. No meio, uma escada e sobre ela um cacho de
bananas. Quando um macaco subia na escada para pegar
as bananas, jogavam um jato de água fria nos que
estavam no chão. Depois de certo tempo, quando um
macaco ia subir a escada os outros o pegavam e enchiam
de pancada. Com mais algum tempo, nenhum macaco subia
mais a escada, apesar da tentação das bananas.

Então substituíram um dos macacos por um novo.

A primeira coisa que ele fez foi subir a escada, dela
sendo retirado pelos outros, que o surraram.
Depois de algumas surras, o novo integrante do grupo
não subia mais a escada. Um segundo foi substituído
e o mesmo ocorreu, tendo o primeiro substituto
participado com entusiasmo na surra ao novato.
Um terceiro foi trocado e o mesmo ocorreu. Um quarto
e afinal o ultimo dos veteranos foi substituído.

Os cientistas então ficaram com um grupo de cinco
macacos que mesmo nunca tendo tomado um banho frio,
continuavam batendo naquele que tentasse pegar as
bananas. Se possível fosse perguntar a algum deles
porque eles batiam em quem tentasse subir a escada,
com certeza a resposta seria:

"Não sei, mas as coisas sempre foram assim por aqui".

(fonte: João Barcellos)

Outra coisa bacana do fórum de UML:

"Amigos(as),

Pergunta da sexta-feira para discussão e reflexão.

Muito se fala hoje sobre processo prescritivo x processo empírico.
Pessoalmente tenho tido algumas experiências positivas em dar maior
liberdade para a equipe criar soluções com pouca intervenção ou
imposição de autoridade.

Com tudo isso, levo umas dúvidas para discussão. Na opinião do grupo,
qual o valor de se ter um processo descrito "todo bonitinho" com guias
de trabalho, modelos, templates, papéis, fluxos de trabalho? Qual o
nível de liberdade que podemos dar à equipe sobre o processo? O
processo perde valor se determinado projeto não tem aderência mínima?

O que vale mais: uma equipe culta em boas práticas ou um processo
detalhadamente descrito? É trabalho do processo ensinar a equipe?

Abraços e bom final de semana!

Rodrigo Yoshima
ASPERCOM"

O Processo de Desenvolvimento de Software

Um processo de desenvolvimento de software

• Uma linguagem de modelagem não é suficiente
• Precisamos também de um processo de desenvolvimento
  • Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento
• O que é um processo de desenvolvimento?
  • Define quem faz o que, quando e como, para atingir um certo alvo
• Veremos os detalhes de processos concretos em outras disciplinas
  • Aqui, só uma introdução
• As grandes fases de qualquer processo de desenvolvimento
  • Planejamento e elaboração
    • Planejamento, definição de requisitos, construção de protótipos (opcional)
  • Construção do sistema (inclui codificação e testes)
  • Implantação (colocar em produção, treinar usuários, ...)

A Fase de Planejamento e Elaboração

1. Criar relatório inicial de investigação (para construir o business case)
2. Levantar requisitos funcionais e não funcionais
3. Construir glossário (ao longo da fase)
4. Definir modelo conceitual inicial (análise inicial)
5. Projetar arquitetura
6. Priorizar a funcionalidade e distribuí-la entre as iterações

Detalhes sobre o levantamento de requisitos

• Requisitos são "cortes" no espaço de solução
• Entendimento do que o usuário quer
• O resultado é uma promessa para o cliente
• Não só requisitos funcionais, mas também:
  • Facilidade de uso necessária
  • Quem utilizará o produto
  • Hardware e software alvo para o produto
  • Qualidade/robustez
  • Desempenho
  • Segurança
  • Compatibilidade com outros produtos/versões e necessidades de migração
  • Necessidades de internacionalização do produto
  • Suporte
  • Preço da solução
  • Documentação necessária
  • Uso de padrões
  • Aspectos legais
  • Integração com outros produtos
  • Packaging
  • etc.
• Não se fala "como" as coisas serão feitas
• "Use cases" descrevem cenários de funcionalidade desejada
  • Também chamados de "User Stories", pois é o usuário que decide o que deve ser feito

Detalhes sobre a fase de Construção

• Hoje, é considerado errado ter um processo que gere um "big bang!"
  • Não se deve ter o software inteiro funcionando por inteiro no primeiro release
  • O risco é grande demais!
• Um processo de desenvolvimento deve ser:
  • Iterativo (ter várias iterações no tempo)
  • Incremental (gerar novas versões incrementadas a cada release)
  • Uma iteração dura entre 2 semanas e 2 meses
• Motivos:
  • Sempre tem algo para entregar para o cliente apressado (a última iteração)
  • Os requisitos mudam com tempo e um processo iterativo mantém freqüentes contatos com o cliente o que ajuda a manter os requisitos sincronizados
  • Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
  • Para evitar isso:

• O que é feito a cada iteração?
  • Análise (refinamento de requisitos, refinamento do modelo conceitual)
  • Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
  • Implementação (codificação e testes)
  • Transição para produto (documentação, instalação, ...)

Detalhes sobre a análise

• A análise gera um modelo para entender o domínio do problema
• Análise também trata em alto nível de como uma solução possível pode ser montada para atender aos requisitos
  • Acaba gerando uma especificação, mas sempre do ponto de vista do usuário e tratando apenas do domínio do problema
• Não trata de detalhes de implementação
• Objetos tratados são sempre do domínio do problema (business objects)
• Muitos diagramas UML podem ser usados
  • O modelo é para o cliente e não para o programador
• Atividades típicas durante a análise

1. Refinar use cases
2. Refinar modelo conceitual
3. Refinar glossário
4. Definir diagramas de seqüência (opcional)
5. Definir contratos de operação (opcional)
6. Definir diagramas de estado (opcional)

Detalhes sobre o projeto (design)

• O projeto é uma extensão do modelo de análise visando sua implementação num computador
• Novos objetos aparecem, mas não são do domínio do problema
• O resultado é para o programador ver, não o cliente
• Objetos da análise são (geralmente) mantidos e são embutidos numa infra-estrutura técnica
  • As classes técnicas ajudam os business objects a:
    • Serem persistentes
    • Se comunicarem
    • Se apresentarem na interface do usuário
    • Terem desempenho aceitável (usando caches ou threads, por exemplo)
• As atividades de projeto incluem:
  • Fase de refinamento da arquitetura (high-level design)
    • Definição de pacotes (módulos), interfaces entre pacotes
    • Decisão sobre uso/criação de bibliotecas e/ou componentes
    • Falaremos disso em detalhes adiante
  • Fase de projeto detalhado (low-level design)
    • Atribuição de responsabilidades entre os objetos
    • Construção de diagramas de classes
      • Pode incluir documentação javadoc (ideal)
    • Construção de diagramas de interação (opcional)
    • Levantamento de necessidades de concorrência
    • Considerações de tratamento de falhas
    • Detalhamento do formato de saída (interface com usuário, relatórios, transações enviadas para outros sistemas, ...)
    • Definição do esquema do BD
    • Mapeamento de objetos para tabelas se o BD for relacional
  • Advertência: se você usar Test-Driven Development, então o design é feito bolando testes e escrevendo o software ao mesmo tempo
    • Neste caso, fazer diagramas ou Javadoc antes de codificar não funciona

Detalhes sobre a implementação

• Escrita do código
• Relativamente simples se o projeto tiver sido bem feito
• Programadores devem normalmente seguir regras de codificação da empresa
• Atividades incluem code reviews
• Não se deve chegar a esta fase cedo demais!
  • Mais cedo você agarra o teclado, mais vai demorar a terminar!
• Poucos novos diagramas nesta fase

Detalhes sobre os testes

• Inclui várias fases de testes
• Testes feitos pelo próprio programador durante a programação
  • Unit test: teste de classes individuais (ou de grupos de classes relacionadas)
  • Functional test: teste de funções inteiras (item de menu, p. ex.)
  • Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding
• Testes feitos por equipes independentes de teste
  • System test: testa a integração entre todos os componentes do produto
  • Alpha test: teste de produto inteiro dentro de casa
  • Beta test: teste de produto inteiro fora de casa
• Testes devem ser automatizados

Outra coisa bacana a respeito de casos de uso que li no forum de UML. Segue o post na integra.

"Assino em baixo da resposta do nosso amigo MT...

Outra coisa importante (e que discutimos na minha aula de ontem) é que não é só na "fase" de levantamento que todos os requisitos são descobertos, ou melhor, não é só da equipe de requisitos a responsabilidade por todos os requisitos. Por exemplo, veja a narrativa a seguir:

Caso de Uso: Consultar Pedido - Versão: 1.2

Ator: Vendedor

1. O Ator inicia o caso de uso selecionando "Consultar Pedido";
2. O Sistema oferece a interface de consulta para pedidos;
3. O Ator informa o número do pedido desejado [A1];
4. O Sistema exibe os dados do pedido [A2];
Fluxo Alternativo A1 ? Consultar por Cliente
3. O Ator informa um cliente;
3.1. O Sistema exibe uma lista de pedidos do cliente selecionado em ordem cronológica decrescente;
3.2. O Ator seleciona um pedido do cliente; volta ao fluxo básico;


No passo 3 do fluxo básico, se o ator informar um número de pedido que não existe, o sistema deverá mostrar uma mensagem "Pedido Inexistente". Porém, esse tipo de "anomalia" não precisa estar necessariamente no caso de uso. Costumo dizer que esse requisito fica por responsabilidade do seu "caprichoso" programador.Algumas pessoas questionam sobre o teste desse "pedido inexistente". Mais
uma vez, não fica a cargo de quem escreveu o caso de uso captar todas as possibilidades e validações para que o teste seja 100%. Se o caso de uso sempre tiver que ter todos os requisitos, todos eles teriam mais de 20 páginas. O teste desse "pedido inexistente" também fica a cargo do seu "atencioso" tester. Um bom tester capta esse tipo de erro.Toda a equipe é responsável pelos requisitos. Os requisitos do caso de uso
são aqueles importantes para o negócio. Se algum desenvolvedor não for "caprichoso" e alguma vez falar "Não está no caso de uso então não vou implementar!", mande ele embora. A mesma coisa vale para o tester.
Valeu?!?!


Rodrigo Yoshima
ASPERCOM
Curso UML e Requisitos em São Paulo
www.aspercom.com."