Princípios Fundamentais do Processo Unificado

O Processo Unificado, uma realização do Processo Iterativo de Desenvolvimento de Software, possui três princípios fundamentais.

A estabilização e a consagração deste processo no mercado devem-se, principalmente, a estes princípios. São eles:

Dirigido por Casos de Uso

Para compreender o conceito "Caso de Uso", é importante conhecer o conceito "Ator". Um ator pode ser entendido com uma pessoa ou uma entidade não-humana que interage com o sistema, mas está fora dele. O exemplo mais comum de ator é o próprio usuário, porém, bancos de dados e outros sistemas também podem ser considerados atores.

Pois bem, um caso de uso é uma seqüência de ações executadas por atores e pelo sistema, a fim de satisfazer metas e necessidades destes atores.

Os casos de uso compõem a força condutora de todo o processo de desenvolvimento, desde a captação inicial de requisitos até a aceitação do código-fonte, por várias razões:

• Primeiramente por serem expressos sob a perspectiva do usuário, em textos descritivos na língua local do cliente. Os textos devem ser intuitivos e óbvios para o leitor.


• Outro ponto fundamental é que permitem uma compreensão direta dos requisitos do sistema. Os casos de uso não devem apresentar ambigüidades, redundâncias ou contradições. Devem especificar um contrato a ser aceito e seguido pelos integrantes da equipe de desenvolvimento e pelos clientes.


• Permitem também um alto grau de rastreamento de requisitos nos diversos modelos que são desenvolvidos posteriormente. Manter os casos de uso à mão durante todo o processo por ser decisivo para o aceite da solução.


• Por fim, os casos de uso facilitam a distribuição de tarefas e a alocação de trabalho.

Centrado em Arquitetura

A arquitetura é a organização fundamental do sistema como um todo. Possui elementos estáticos e dinâmicos que explicitam exatamente como cada componente é construído e como este se relaciona com os demais.

Uma boa arquitetura deve prover um alto grau de manutenibilidade. Este fato é fundamental para que a equipe de desenvolvimento possa atender as demandas que surgem em um intervalo de tempo cada vez menor, principalmente após a adoção da Internet como canal de comunicação primário.

Inúmeras corporações modelam seus negócios de acordo com a tecnologia disponível, inviabilizando a inovação, mutação e, em alguns casos, até o crescimento do negócio. Segundo constatado por Paul Strassmann em 1997, na realidade uma situação inversa deveria ser empregada, onde as seguintes características sustentariam a ideal postura de um departamento de Tecnologia da Informação em uma organização: deveria agregar real valor ao plano de negócios, não deveria resistir às mudanças e deveria combater qualquer tipo de resistência a elas, pois são necessárias.

Partindo deste ponto de vista, é essencial que o software se adapte ao modelo de negócios estipulado em uma corporação. Porém, como modelos de negócios são mutáveis, a arquitetura do software em questão deve ser flexível o suficiente para acompanhar tais mudanças e expansível o suficiente para permitir o crescimento.

Um alto grau de modularidade pode ser um grande aliado no alcance de altos graus de manutenibilidade, flexibilidade e expansibilidade.

Um módulo pode ser entendido como uma porção de código encapsulada, coesa e fracamente acoplada. Já o grau de modularidade estima a coerência de utilização de módulos na arquitetura de um sistema, obedecendo cinco critérios e seis princípios, descritos por Bertrand Meyer em 1988, exibidos nas listagens abaixo:

• Critérios:




• Decomposição: Capacidade de dividir o problema inicial em subproblemas, ou módulos, isolados.


• Composição: Capacidade de reutilização dos módulos na construção de novos sistemas, possivelmente em ambientes ligeiramente diferentes.


• Entendimento: Capacidade de compreensão dos módulos de forma individual por um leitor humano.


• Continuidade: Capacidade de alteração dos módulos sem impacto nos demais, mantendo a arquitetura e as relações.


• Proteção: Capacidade de suporte a condições anormais dos módulos, limitando o escopo de um erro ao próprio módulo e protegendo o restante do sistema.




• Princípios:




• Unidade modular sintática: Um módulo deve corresponder a uma unidade sintática da linguagem.


• Poucas interfaces: Um módulo deve se comunicar com a menor quantidade de módulos possível, evitando recursão.


• Interfaces pequenas: Um módulo deve trocar a menor quantidade de informações possível com outro.


• Interfaces explícitas: A comunicação entre dois módulos deve ser explícita e clara.


• Informações ocultas: Os dados de um módulo devem ser privados, com raras exceções de dados públicos.


• Aberto e fechado: Aberto para pequenas alterações (sem impacto nas interfaces) e fechado, sugerindo sua completude e disponibilidade de uso.

Ainda tendo em vista o grau de modularidade, uma arquitetura deve ser elaborada considerando diversos níveis de abstração. Quanto menor a abstração de um componente, maior será seu potencial de reuso. Esta característica fundamental pode ser alcançada através da utilização de frameworks, um conjunto de classes abstratas e concretas com alto grau de especialização.

Reunindo todo este conhecimento, somos capazes de minimizar a existência de três propriedades internas indesejáveis na arquitetura:

• Rigidez: A manutenção em um determinado ponto do sistema obriga ao desenvolvedor ajustar outras localidades diretamente relacionadas, gerando uma cadeia de manutenção. Suas conseqüências são conhecidas como “efeito dominó”.


• Fragilidade: A manutenção em um determinado ponto do sistema gera problemas em outro ponto não relacionado, muitas vezes distante do local da alteração. Suas conseqüências são conhecidas como “efeito borboleta-maremoto”, nomenclatura extraída da Teoria do Caos. Esta teoria defende que o simples bater de asas de uma borboleta em um extremo do mundo, pode ser o estopim de um tornado no outro extremo.


• Imobilidade: Ao tentar reutilizar um componente já desenvolvido, classes não pertencentes a este impossibilitam a ação, dado o forte acoplamento existente. Suas conseqüências são conhecidas como “efeito banana-gorila”.

Iterativo e Incremental

Cada projeto é dividido em iterações. Cada iteração pode ser considerada um miniprojeto de curta duração que tem por objetivo oferecer uma melhora incremental ao sistema.

São benefícios desta forma de organização:

• É um progresso lógico para que uma arquitetura robusta seja alcançada. Durante as iterações iniciais, uma arquitetura candidata é proposta. Sua evolução será uma fundação sólida para o restante do sistema.


• Em contraste com metodologias que seguem o paradigma do Processo Cascata, onde todos os requisitos são levantados no inicio e nunca mais revisados, o Processo Unificado prevê a negociação progressiva de requisitos, priorizando aqueles que representam riscos mais significativos ao projeto.


• Possibilita maior flexibilidade para que mudanças ocorram no plano de atuação da equipe de desenvolvimento. Uma avaliação ao final de uma iteração permite isolar um eventual problema identificado e lidar com ele em uma escalada reduzida, sem propagar seus efeitos.


• Caso o incremento de uma iteração seja um componente ou módulo, este é integrado aos demais existentes. Uma integração muitas vezes representa a conquista de mais um requisito. A evolução do trabalho torna-se mais evidente aos interessados.


• Por fim, a natureza iterativa permite que novos integrantes da equipe de desenvolvimento iniciem suas atividades sem que sejam submetidos a treinamentos extensos que cubram todo o projeto.