Boas Vindas para turma 04
Olá Pessoal
Gostaria de dar boas vindas aos alunos da turma 04 do curso de Pós Graduação Em Engenharia de Software Centrada em Métodos Ágeis.
Agora estamos com uma ementa atualizada. Adicionamos ao curso novas as disciplinas:
- Engenharia de Software Ágil – que trata de processos ágeis como XP, FDD, Lean e Crystal
- Práticas Ágeis de Desenvolvimento de Software – que é a parte prática da disciplina de Engenharia de Software Ágil, onde os alunos poderão praticar as práticas de XP
- Integração e Delpoy contínuo
- ALM – Gerenciamento do ciclo de vida da aplicação
Novamente amos aproveitar este espaço para compartilhar práticas, conhecimento e assuntos pertinentes ao curso, com foco na transparência e agilidade
Abraço a Todos!
Edgard Davidson, coordenador do curso.
Olá Pessoal
Gostaria de dar boas vindas aos alunos da turma 03 do curso de Pós Graduação Em Engenharia de Software Centrada em Métodos Ágeis.
Reforço que o curso é puxado, que todos os professores são orientados a nivelar a turma por cima, com objetivo de manter o curso em um nível alto. Desejo também boa sorte e bons estudos à todos. Tenho certeza que ao longo deste ano vocês agregarão muito conhecimento.
Novamente amos aproveitar este espaço para compartilhar práticas, conhecimento e assuntos pertinentes ao curso, com foco na transparência e agilidade
Abraço a Todos!
Edgard Davidson, coordenador do curso.
DEPLOY CONTÍNUO COM GIT E HEROKU
Por: Florindo Silote / Rodrigo Vespúcio
Para a automatização de deploy podemos utilizar diferentes mecanismos. A escolha da forma a ser utilizada depende diretamente de fatores como facilidade de uso, custo e suporte da comunidade.
Neste sentido, o professor Daniel Lopes nos propôs uma avaliação sobre as diferentes formas de deploy, a fim de identificar qual seria mais interessante para o nosso cenário, que consiste na criação de uma aplicação Rails desenvolvida em conjunto pelos alunos da turma de Especialização em Engenharia de Software Centrada em Métodos Ágeis.
Foram avaliados três mecanismos para automatização de deploy: Capistrano, Hooks de Git e Heroku.
SAP – Stablility and Abstract Principle – Princípio da Abstração e Estabilidade
Por:
Cláudio Xavier
Samuel Lopes
SAP – Stablility and Abstract Principle
Princípio da Abstração e Estabilidade.
Pacotes que são maximamente ESTÁVEIS devem ser maximamente ABSTRATOS. PACOTES instáveis DEVEM SER CONCRETOS. A abstração de um pacote deve ser PROPORCIONAL a sua estabilidade.
Introdução
Este princípio é mais apropriado para aplicações que excedem 50.000 linhas de código e exige uma equipe de engenheiros para escrever. Este artigo descreve um conjunto de princípios e métricas que podem ser usados para medir a qualidade de um design (projeto) orientado a objeto em termos de interdependência entre os pacotes.
CCP – Common Closure Principle
Por:
Wemerson
Romilton
Common Closure Principle (CCP)
“classes que mudam juntas, permanecem juntas”
Common Closure Principle (CCP) é um princípio design de pacotes cujo foco é a manutenabilidade do código. A abordagem foi proposta por Robert Martin, é uma generalização do Single Responsibility Principle (SRP). Para o SRP uma classe deve ter apenas um motivo para ser alterada, se mais de um tipo de mudança no sistema afeta a classe provavelmente ela pode ser dividia em mais de uma, ou seja, ela representa conceitos demais. O mesmo se aplica para pacotes. Um pacote deve seguir o Open-Closed Principle (OCP), se proteger de mudanças e ao mesmo tempo estar aberto à extensão.
ADP – Acyclic Dependencies Principle – Princípio da Dependência Acíclica
por
Adriano Wallace
Kamila Alves
ADP – Acyclic Dependencies Principle – Princípio da Dependência Acíclica
É um dos princípios da arquitetura de pacotes, que define que a dependência (acoplamento) entre pacotes ou componentes não devem formar ciclos. Por exemplo, o pacote W depende do pacote Y, que depende do pacote X. Se o pacote X depende igualmente do pacote Y, então teremos um ciclo.
Figura 1 - Representação de um ciclo.
REP – Reuse release equivalence principle – Princípio da Equivalência de Reuso/Versão
Por:
Davidson Marques
Jarison Araújo
Princípio da Equivalência de Reuso/Versão (REP)
“A unidade de reuso é a unidade da versão. Apenas componentes que possuem um sistema de rastreamento de versão podem ter reuso efetivo. Esta unidade é o pacote.”
Código não deve ser reutilizado, copiando-o de uma classe e colá-lo em outra. Nem mesmo uma classe deve ser copiada de seu pacote original para dentro do seu projeto. Fazendo isso você não obterá benefício nenhum quando o autor original corrigir erros no código, acrescentar recursos ou melhorar seus métodos. Se ele modificar algo, você terá que descobrir o que mudou e alterar na sua cópia. Com o tempo, seu código se distanciará do original e com o tempo, poderá até mesmo se tornar irreconhecível.
Em vez disso, o código deve ser reutilizado, incluindo a biblioteca (pacote) liberada pelo autor original. O autor original mantém a responsabilidade pela manutenção, você não deve nem precisar conhecer o código fonte.
Para que esta reuso seja mesmo eficaz, o autor original deve manter um sistema de controle de versões e identificar com números ou nomes de alguma maneira para que os clientes destes pacotes possam perceber as diferentes versões.
