quinta-feira, setembro 28, 2006

A disciplina de Projeto

Esta disciplina é a principal responsável pela elaboração da arquitetura. Ela utiliza-se dos artefatos produzidos na fase de Análise como base para a elaboração de uma arquitetura baseada em classes de projeto, ou classes concretas. Em geral procura-se unificar os diagramas e não mais manter um para cada caso de uso. Neste estágio é preciso ter uma idéia mais ampla da arquitetura como um todo, inclusive no que diz respeito a questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

A disciplina de Projeto é fundamental em uma metodologia centrada em arquitetura. Realizar bem as tarefas neste momento pode garantir um bom tempo de resposta nas atualizações do software futuramente.

Questões como distribuição de objetos e utilização de frameworks também são consideradas.

Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionados e se complementam.

Dois artefatos são produzidos durante esta disciplina. São eles:

  • Modelo de Projeto:


  • Este modelo é formado por pacotes de projeto. Cada pacote representa um agrupamento lógico de diagramas estáticos, como o diagrama de classes, e dinâmicos, como o diagrama de seqüência e o diagrama de objetos.

    Os diagramas estáticos são responsáveis por discriminar os relacionamentos entre as classes de projeto. Deve-se buscar um baixo acoplamento.

    Já os diagramas dinâmicos exibem como cada uma das classes de projeto se comporta em tempo de execução. Técnicas como a Inversão de Dependência só podem ser visualizadas em diagramas deste tipo.

  • Modelo de Instalação:


  • Define a organização física do sistema em termos de nós computacionais, os quais são peças de hardware que representam um recurso, como um servidor, uma estação de trabalho ou algum outro software.

    Os componentes que formam a arquitetura residem nos nós computacionais. A listagem dos componentes deve ser apresentada no interior de cada nó.

    O principal artefato deste modelo é o diagrama de instalação da UML, que discrimina como os nós se relacionam. Os diagramas podem ser agrupados logicamente em pacotes, denominados pacotes de instalação.

    Outro objetivo deste modelo é apresentar ao cliente qual a infra-estrutura necessária para a correta execução do software. Este tipo de informação, quando entregue ao final da fase de Elaboração, faz que o cliente tenha tempo para preparar o ambiente.

4 comentários:

Ítalo disse...

Qual a relação entre **fases** e **atividades** no UP? Quando você vincula a "fase de análise" como predecessora da "fase de projeto", isto não caracteriza um processo Waterfall?

Otavio Ferreira disse...

Olá Italo!

Suas perguntas são muito importantes para a compreensão do processo.

Para nos auxiliar na troca de idéias, extraí um trecho do post A estrutura do Processo Unificado:

"Uma característica marcante, também ilustrada na figura 1, é o fato de todas as iterações, e conseqüentemente todas as fases, serem atravessadas por todas as disciplinas, com maior ou menor intensidade.

São exatamente as disciplinas que possuem artefatos associados. Artefatos são documentos textuais ou diagramas da UML que facilitam a compreensão do sistema e a comunicação entre os envolvidos. Ou seja, é possível que um artefato de compreensão do domínio seja incrementado em mais de uma fase, mesmo sabendo que o entendimento do domínio é um dos principais objetivos da fase de Concepção."


Desta forma, acredito que podemos dizer que as atividades estão mais relacionadas com as disciplinas do que com as fases propriamente ditas. São atividades de elaboração dos artefatos pertencentes a cada uma dessas disciplinas.

No post Pacote de posts sobre o Processo Unificado, existe um link para cada disciplina do processo. Acessando os links, podemos ver uma breve descrição dos artefatos produzidos em cada uma das fases.

Agora, sobre a segunda pergunta, extraí um trecho do post A disciplina de Projeto:

"Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionadas e se complementam."

De acordo com este ponto de vista, podemos considerar estas disciplinas como integrantes de um mesmo esforço no processo. Ao mesmo tempo que conduzimos a análise, surgem classes e questões de projeto que são modeladas.

No post Processos Iterativos de desenvolvimento de software, existe um comparativo com o paradigma do Processo Waterfall. Mas, resumidamente, podemos extrair este trecho:

"A constante mudança de requisitos, a divisão inflexível das atividades e a rigidez imposta colaboraram para o fracasso do processo."

No Processo Unificado, não existe tal rigidez na transição de fases, pois as disciplinas permanecem com certo grau de intensidade, cortando as fases.

Obrigado por sua valiosa contribição para esta troca de idéias sobre o Processo Unificado.

Um abraço!

Ítalo disse...

Posso entender que não faz sentido estabelecer uma ordem na execução das atividades de análise e de desenho, portanto?

Otavio Ferreira disse...

Olá Italo!

Acredito que esta afirmação seja muito forte para a relação entre as disciplins de Análise e Projeto.

Existe um processo criativo intenso na elaboração de uma arquitetura. Um modelo com considerável maturidade é fruto de uma série de iterações e refinamentos.

A disciplina de Análise nos permite identificar objetos mais abstrados. São Objetos de Jacobson, que discriminam quais são objetos de fronteira, controle ou entidade.

Este primeiro corte facilita o refinamento existente na disciplina de Projeto. O projeto já considera questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

Mas é importante perceber que não existe um divisão rídiga entre as disciplinas, são complementares. A Análise facilita a primeira identificação dos objetos e, durante sua evolução, naturalmente surgem questões mais técnicas de projeto.

Você compartilha desta visão?

É isso ai. Forte abraço!

 
> blogblogs.com.br