Introduo

Viso Geral do Mtodo

Processo Unificado - UP
A motivao para o uso da abordagem de Craig Larman ao Processo Unificado deve-se ao fato de que este um processo bastante conciso e eficiente para anlise e projeto de sistemas orientados a objetos. Neste mtodo, cada artefato (documento ou diagrama) tem uma razo muito clara para existir e as conexes entre os diferentes artefatos so muito precisas.

Migrao
H vantagens em mudar o processo de desenvolvimento de sistemas das empresas?

Questo da Ferramenta
Comprar um martelo no transforma voc em um arquiteto!

UML
Unified Modeling Language Language. Conhecer uma linguagem no implica na habilidade de saber us-la para produzir artefatos teis. Escrever bons projetos como escrever poesia. No basta conhecer a linguagem. preciso dominar certas tcnicas de escrita.

Software Deselegante
O software deselegante aquele software feito sem uma estrutura clara. O software deselegante aquele do qual no se consegue reusar partes e que no se consegue entender como funciona sem uma boa carga de documentao (e muitas vezes nem assim). tambm aquele no qual uma pequena modificao em uma de suas caractersticas pode causar um no funcionamento generalizado.

Software Elegante
O software elegante o software cuja estrutura intrinsecamente mais fcil de compreender, que autodocumentado e pode ser compreendido em nvel macro ou em detalhes. Ele mais fcil de modificar: quando alguma de suas caractersticas mudada, ele continua funcionando.

Solues para prover elegncia

Design Patterns - lies aprendidas ao longo dos anos em diferentes projetos.

Atividades do Desenvolvimento

Anlise Projeto Implementao Teste

Anlise
A anlise enfatiza a investigao do problema. O objetivo da anlise levar o analista a investigar e a descobrir. Para que esta etapa seja realizada em menos tempo e de forma mais precisa, deve-se ter um bom mtodo de trabalho.

Anlise
Pode-se dizer que o resultado da anlise o enunciado do problema, e que o projeto ser a sua resoluo. Problemas mal enunciados podem at ser resolvidos, mas a soluo no corresponder s expectativas.

Anlise
A qualidade do processo de anlise importante porque um erro de concepo resolvido na fase de anlise tem um custo; na fase de projeto tem um custo maior; na fase de implementao maior ainda, e na fase de implantao do sistema tem um custo relativamente astronmico.

Projeto
A fase de projeto enfatiza a proposta de uma soluo que atenda os requisitos da anlise. Ento, se a analise uma investigao para tentar descobrir o que o cliente quer, o projeto consiste em propor uma soluo com base no conhecimento adquirido na anlise.

Implementao
A utilizao de tcnicas sistemticas nas fases de anlise e projeto faz com que o processo de gerao de cdigo possa ser automatizado. Neste caso, cabe ao programador dominar as caractersticas especficas das linguagens, ferramentas, frameworks e estruturas de dados para adaptar o cdigo gerado aos requisitos indicados quando necessrio.

Testes
A fase de testes envolve os testes de unidade, feitos pelo programador, para verificar se os componentes gerados atendem especificao do projetista, e aos testes de caso de uso, normalmente efetuados por um analista experiente, que visam verificar a adequao do sistema aos requisitos inicialmente levantados.

As quatro Fases do Processo Unificado

A fase de concepo incorpora o estudo de viabilidade e uma parte da anlise de requisitos. A fase de elaborao incorpora a maior parte da anlise de requisitos, a anlise de domnio e o projeto. A fase de construo corresponde programao e testes. A fase de transio consiste na instalao e manuteno do sistema.

Ciclo de Vida
Construo Concepo Transio Elaborao

Concepo
Anlise de Requisitos Esboo de Modelo Conceitual Listagem de Casos de Uso Escopo do Sistema Cronograma de Desenvolvimento e Desembolso

Anlise de Requisitos
A anlise de requisitos fundamental para o desenvolvimento de sistemas, pois trata justamente de descobrir o que o cliente quer com o sistema. A anlise de requisitos est associada ao processo de descobrir quais so as operaes que o sistema deve realizar e quais so as restries que existem sobre estas operaes.

Requisitos
Funcionais o que o sistema deve fazer No-funcionais restries sobre como o sistema deve desempenhar suas funes

Exemplo
Registrar o emprstimo de uma fita um requisito funcional. Estabelecer que o tempo de emprstimo da fita no pode ser superior a 48 horas uma restrio, ou requisito no funcional.

Erro comum
Deve ficar claro ao analista que requisitos so coisas que o cliente ou usurio solicitam, e no coisas que ele, como analista, planejou.

Elaborao
Anlise de Domnio
Modelagem de Interao (casos de uso expandidos) Modelagem Conceitual Modelagem Funcional (contratos)

Projeto
Modelagem Dinmica (diagramas de comunicao) Arquitetura do Sistema
Camadas de Domnio, Interface e Persistncia

Anlise de Domnio
A anlise de domnio est relacionada descoberta das informaes que so gerenciadas no sistema, ou seja, representao e transformao da informao.

Exemplo
No sistema de informaes de uma videolocadora as informaes descobertas na anlise de domnio possivelmente seriam relativas aos clientes, s fitas, aos emprstimos, aos pagamentos, etc.

Tipos de Informao
As informaes tm dois aspectos que so analisados: esttico (ou estrutural) e o funcional. O modelo esttico representado no diagrama conhecido como modelo conceitual. O modelo funcional pode ser representado atravs dos contratos de operaes de sistema.

Projeto
Pode-se dizer que o ncleo de um projeto orientado a objetos consiste de um diagrama de classes. Mas como que se constri um diagrama de classes? Construindo o modelo conceitual e adicionando mtodos nas classes? No!

Modelo Conceitual
Elementos:
Classes: fceis de identificar Atributos: tomar cuidado para no confundir com associaes Associaes: tomar cuidado para no confundir com operaes

Mtodos no pertencem ao modelo conceitual e so mais difceis de determinar

Modelo Dinmico (projeto)

Quais so os mtodos que devem ficar em cada classe? O uso de diagramas de comunicao e padres de projeto pode permitir uma forma muito mais eficiente e eficaz de descobrir o local adequado para implementar cada mtodo.

Exemplo da dificuldade com mtodos

Tendncia a associar muitos mtodos a uma classe que representa uma entidade ativa no mundo real, como, por exemplo, o funcionrio. Assim, a classe Funcionario teria, segundo esta concepo, os mtodos para criar uma locao, cadastrar uma fita, cobrar uma conta, etc. No limite, esta classe acabaria desempenhando todas as funes do sistema, enquanto que as outras classes nada fariam. Certamente esta soluo concentradora no nem um pouco elegante.

Exemplo de soluo concentradora a partir de pseudo-cdigo

Emprestar uma fita a um cliente corrente

Pseudocdigo concentrador
Classe VideoLocadora fitas, clientes : Conjunto; clienteCorrente : Cliente; Mtodo emprestaFita(fCodigo: String) fita : Fita; emprestimoCorrente : Emprestimo; item : ItemDeEmprestimo; fita := fitas.get(fCodigo); emprestimoCorrente := clienteCorrente.getEmprestimoCorrente(); item := ItemDeEmprestimo.new(); item.associaFita(fita); emprestimoCorrente.associaItem(item); Fim Mtodo; Fim Classe.

Uma diagrama de colaborao para o mesmo problema

Resulta em cdigo mais elegante

Classe VideoLocadora fitas : Conjunto ; clienteCorrente : Cliente; Metodo emprestaFita(fCodigo : String); fita : Fita; fita := this.getFita(fCodigo); clienteCorrente.empresta(fita) Fim Metodo; Fim Classe. Classe Cliente emprestimoCorrente : Emprestimo; Metodo empresta(fita : Fita); emprestimoCorrente.adiciona(fita); Fim Metodo; Fim Classe. Classe Emprestimo itens : Conjunto; Metodo adiciona(fita : Fita); item : ItemDeEmprestimo; item := ItemDeEmprestimo.new(); self.associaItem(item); item.associaFita(fita); Fim Metodo; Fim Classe.

Orientao a objetos no apenas diagrama de classes

Quando uma ou duas classes fazem tudo, e as outras so meras pacientes desse processo, no existe propriamente orientao a objetos, mas uma estrutura concentradora. Seria prefervel fazer um projeto estruturado bem feito do que um projeto orientado a objetos desta forma.

OO no simulao
Muitos projetistas cometem o erro de acreditar que um sistema orientado a objetos uma simulao do mundo real. Mas isso no normalmente verdade. O sistema representa as informaes do mundo real e no as coisas propriamente ditas Os mtodos, no correspondem a aes do mundo real, mas sim realizao interna de contratos de operaes externas (ou operaes de sistema). Por este motivo que os mtodos internos so citados apenas na fase de projeto e sequer aparecem na fase de anlise.