Checklist para o primeiro trabalho

Como a anotação do código utilizando cenários ficou um pouco confusa nos trabalhos, aí vão alguns itens pra vcs checarem se estão corretos no trabalho entregue:

1. Eu melhorei os cenários do enunciado?
2. Eu incluí todos os cenários que eu implementei para lembrar a senha?
3. Meus episódios estão corretos e em uma ordem lógica?
4. Eu incluí as restrições nos episódios pertinentes?
5. Meus episódios estão numerados corretamente, na forma Episódio 2-05 (cenário 2, episódio 5) ?
6. Eu aperfeiçoei o léxico do enunciado?
7. Meu léxico está mínimo e suficiente?
8. Minhas variáveis, funções e os meus arquivos estão nomeados de acordo com o léxico?

O checklist é apenas um guia para vcs. Lembrem-se de seguir os conceitos de circularidade e do vocabulário mínimo tanto no léxico quanto nos cenários. Quanto ao uso de um trabalho-base por alguns alunos (reuso), temos mais dois itens para o checklist:

1. Eu citei o trabalho que utilizei como base?
2. Eu realmente contribuí com o trabalho, ou seja, evoluí o trabalho-base?

Até a próxima.

Micro-Arquiteturas

Em sala, vimos o conceito de Micro-Arquiteturas, que são pequenas estruturas aplicadas em um ponto do projeto visando a solução de um problema local. Focamos, principalmente, em Padrões de Projeto (Design Patterns). Os Padrões de Projeto são soluções recorrentes para problemas encontrados no projeto de sistemas orientados a objeto. Erich Gamma publicou um livro em conjunto com outros autores que consiste em um catálogo de 23 Padrões de Projeto, com o título Design Patterns (um dos mais citados da área de Engenharia de Software).

Os padrões podem ser divididos em sub-categorias: Padrões de CriaçãoPadrões EstruturaisPadrões Comportamentais

Vimos em sala um padrão estrutural, Facade, e dois padrões comportamentais, Observer e Strategy. O padrão Facade é um padrão estrutural que visa ocultar os detalhes de um processo criando uma classe de fachada, ou seja, a classe cliente apenas chama um método da classe fachada e essa classe é que se encarrega de executar esse processo.

O padrão Observer é um padrão comportamental para a comunicação de classes que precisam atualizar suas informações com outras classes. Finalmente, o padrão Strategy é um padrão comportamental que permite a flexibilização do algoritmo de execução de um processo. É muito interessante observar como um padrão Strategy pode facilitar a implementação de um processo definido por uma tabela de decisão.

Uma questão interessante levantada em classe foi se o padrão Observer é sempre útil. A resposta pode ser vista aqui. Como o Professor Júlio observou, todos os padrões possuem contra-indicações, ou efeitos colaterais. Os mais comuns deles são o aumento da complexidade do projeto e a explosão do número de classes do sistema, quando os padrões são utilizados indiscriminadamente. Além de catalogar diversos padrões em seu livro, Gamma também definiu um modelo padrão para o catálogo de padrões. Obviamente, os padrões de projeto não se resumem apenas aos 23 padrões do livro, já que diversos pesquisadores propuseram novos padrões, e os catalogaram. O catálogo de um Padrão de Projeto deve ser feito observando os seguintes itens:

• Intenção

• Nome alternativo

• Motivação

• Aplicabilidade

• Estrutura

• Participantes

• Colaborações

• Conseqüências

• Implementação

• Exemplo de Código

• Usos Conhecidos

• Padrões Relacionados

Espero que a idéia tenha ficado mais clara.

Até a próxima, pessoal.

Usefull Links

Hi, folks! Here are some useful links:

PES – Undergraduate course page

CEL – Application page - Versão Base

CEL – Application page - Versão AJAX

Previous collaborative works by other classes (2002-2006)

Please take, at least, a glance at these pages ok? Good clicking.

Reference Bibliography

Sommerville, I. “Software Engineering”, 8th edition. Addison Wesley, 2006, 864 pages.

Buy at Amazon

Sommerville, I. “Engenharia de Software”, 6a. edição. Pearson Education do Brasil, São Paulo, 2003, 606 páginas.

Compre no Submarino

Good reading!