Muito se fala em classes, objetos, herança, poliformismo, abstração e outros conceitos relacionados ao desenvolvimento orientado a objetos, mas o objetivo desse artigo não é explicar cada um desses conceitos, e sim mostrar o que deve ser feito até chegarmos à fase de construção, ou seja, a análise orientada o objetos (AOO).

Para realizar um projeto, de fato, orientado a objetos é necessário mudar a forma de se pensar, partindo da fase de análise do projeto, que se tornou a mais importante. Hoje em dia não podemos partir direto para fase de desenvolvimento, sem antes passar pela análise, é inevitável. As duas fases devem ser simultâneas.

Estarei apresentando uma metodologia muito eficaz para auxiliar os analistas que querem se aprofundar nos projetos orientados a objeto, essa metodologia é conhecida como processo unificado (RUP). O RUP adota as seguintes premissas básicas:

• Uso de iterações para evitar o impacto de mudanças no projeto,
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

O processo unificado consiste em quatro fases básicas:

• Concepção – visão geral e entendimento da necessidade do projeto,
• Elaboração – especificação e abordagem dos pontos de maior risco,
• Construção – desenvolvimento principal do sistema,
• Transição – ajustes e implantação do sistema

A fase de Concepção tem um foco nos riscos de negócios ou requisitos que possam inviabilizar o projeto. Esta fase é mais importante em projetos novos e mais simples em projetos de melhoria de sistemas já existentes. Porém, o foco é sempre na garantia que o projeto é viável e vale a pena ser feito.

Nesta fase, realiza-se uma das principais tarefas do projeto, que é o levantamento de requisitos. Esse processo é realizado para definir “o porquê” da criação do sistema, é muito difícil de projetar uma boa solução para um problema que não tem uma explicação bem definida. Existem algumas técnicas para auxiliar no levantamento de requisitos, como por exemplo, observação in-loco, entrevista com o cliente e JAD (Joint Application Development). Os requisitos são divididos em dois:

• Requisitos funcionais – são aqueles que detalham o que deve ser feito no sistema. A partir deles o analista segue com as outras etapas do processo unificado.
• Requisitos não-funcionais – detalham como o sistema deve ser feito, por exemplo, facilidades de uso, tempo de resposta, equipamentos, etc. Esses tipos de requisitos podem inviabilizar o desenvolvimento do projeto, por isso são muito importantes.

É muito importante destacar que, nesta fase, nem todos os requisitos foram definidos, mesmo porque o objetivo dessa fase não é esse, e sim testar a viabilidade do sistema. Com os testes devidamente feitos e a certeza da realização do projeto, devemos seguir para a outra etapa, ainda dentro da fase de concepção do processo unificado, que é o desenvolvimento dos casos de uso de alto nível. Essa fase é muito importante também, aqui que devemos especificar os processos que foram encontrados nos requisitos funcionais.

Os casos de uso de alto nível devem conter uma descrição geral dos processos considerados primordiais para a realização do projeto, não podendo se delongar muito. Eu recomendo que eles não ultrapassem seis linhas, sempre levando em consideração a grandiosidade do projeto.

A última etapa da fase de concepção é o escalonamento dos casos de uso, o que seria isso? Com todos os casos de uso de alto nível prontos, precisamos definir a prioridade de desenvolvimento para cada um deles. São levados em consideração dois fatores nesse momento, o grau de importância e o grau de complexidade de desenvolvimento.

Com essa etapa devidamente definida, concluímos a fase de concepção. Claro que esta é uma visão superficial do processo unificado. Essa fase que define também se o projeto vai ser ou não desenvolvido, não podendo ultrapassar 5% do tempo total estimado. Se a concepção demorar mais do que algumas semanas para ser definida, existe algo de errado.

A próxima fase é a de elaboração que será apenas para o projeto do sistema, buscando complementar o levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário.
Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta.

Quando entramos nessas fases devemos seguir um ciclo iterativo que parte do princípio da especificação dos casos de uso, começando sempre daquele que foi designado o de maior importância na etapa de escalonamento. Nessa etapa são desenvolvidos os primeiros casos de uso expandido da lista, um de cada vez. Pelo próprio nome já podemos ver que eles vão fazer um detalhamento bem completo dos casos de uso de alto nível encontrados na fase de concepção.

Figura 1 - Diagrama de caso de uso

No mínimo, cada caso de uso deve ter um fluxo principal de sucesso, ou seqüência típica de eventos, um exemplo desse tipo de caso de uso:

1. O usuário entra com seu nome e email.
2. O sistema verifica a informação de identificação.

Os casos de uso também podem conter fluxos alternativos ou secundários que contém exceções do tema principal, alternativas ou eventuais erros que possam acontecer.
Seguindo com nosso ciclo iterativo, partimos para o modelo conceitual. A primeira impressão que temos ao ver um modelo conceitual é pensar que ele é idêntico ao modelo entidade-relacionamento utilizado na camada de persistência dos dados, mas essa visão está errada. O modelo conceitual está mais para um diagrama de classes do que para um modelo ER.

Figura 2 - Modelo Conceitual

A próxima etapa é o diagrama de seqüência dos eventos do sistema, essa etapa tem como objetivo principal especificar a seqüência de iterações dos atores com o sistema, e definir as operações que são necessárias. Esse diagrama é feito com base nos casos de uso expandidos, a partir deles iremos encontrar as operações e respostas do sistema. As operações poderão se transformar, mais adiante, nos métodos das classes e as respostas, o retorno desses métodos.

Temos ainda a etapa dos contratos, aqui já estamos bem perto da construção do processo. Nessa etapa, as operações são bem detalhadas, contendo suas responsabilidades, pré-condições e pós-condições, essas últimas descrevem as definições de instâncias de objetos, associações formadas e modificações de atributos. Vejamos um exemplo de contrato:

Nome da operação: adicionarCliente(idCliente, nomeCliente)
Responsabilidade: Cadastrar um novo cliente
Pós-Condições:

• Uma instância do Cliente foi criada.
• Cliente.nome recebeu o nome passado como parâmetro.
• Cliente.id recebeu o id passado como parâmetro.
• A instância Cliente foi associada ao sistema.

Podemos ver que nos aproximamos muito da programação, o nome da operação provavelmente será um método da classe Cliente, idCliente e nomeCliente serão propriedades da classe. Ao analisarmos as pós-condições vimos à definição de instâncias de objeto, modificações de atributos e a associação. A última linha das pós-condições tem como objetivo indicar que o objeto vai ser enviado para a camada de persistência, na qual são realizadas todas as operações necessárias para gravação na fonte de dados.

Com tudo isso definido, partimos para a construção do processo, programamos, programamos, programamos, testamos, testamos, testamos e finalizamos uma etapa de cada vez, entrando em loop, espero eu loop finito.

É bom lembrar que tudo que foi falado relaciona-se com a análise orientada a objetos, e dá uma visão superficial. Tentarei escrever um artigo explicando mais sobre a parte de desenvolvimento de um sistema orientado a objetos.

Não poderia terminar sem citar um dos maiores conhecedores da análise orientada a objetos, Craig Larman possui um livro considerado o melhor sobre o assunto: “Utilizando UML e Padrões” da editora Bookman, que vai muito além dos diagramas UML, explicando desde conceitos RUP até o desenvolvimento iterativo. Eu recomendo.

Espero que tenham gostado, e peço desculpa por qualquer erro encontrado, pois esse é meu primeiro artigo, aceito sugestões e críticas construtivas. Até a próxima.

This entry was posted on Wednesday, November 28th, 2007 at 10:34 am and is filed under Análise de Sistemas, Desenvolvimento Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.