SUMRIO

1.0 1.1 1.2 PROCESSO RUP................................................................................................................................................4 CICLO DE VIDA DE DESENVOLVIMENTO DE SISTEMAS..........................................................................4 CONCEITOS BSICOS.......................................................................................................................................5 1.2.1 MODELOS ..................................................................................................................................................5 1.2.2 WORKER ....................................................................................................................................................5 1.2.3 FASES..........................................................................................................................................................5 1.2.4 DISCIPLINAS .............................................................................................................................................5 CICLO DE VIDA..................................................................................................................................................5 1.3.1 FASEAMENTO ...........................................................................................................................................6 DEFINIO DAS FASES.........................................................................................................................................7 1.4.1 ITERAO..................................................................................................................................................7 1.4.1.1 OBJETIVOS .............................................................................................................................................7 1.4.2 CONCEPO..............................................................................................................................................7 1.4.2.1 OBJETIVOS .............................................................................................................................................7 1.4.2.2 RESULTADOS.........................................................................................................................................8 1.4.3 ELABORAO...........................................................................................................................................8 1.4.4 CONSTRUO...........................................................................................................................................9 1.4.4.1 RESULTADOS.........................................................................................................................................9 1.4.5 TRANSIO.............................................................................................................................................10 CICLOS E RELEASES.......................................................................................................................................10 O NEGCIO .....................................................................................................................................................10 RELAO USURIO X ANALISTA ...............................................................................................................10 RISCOS POTENCIAIS DO DESENVOLVIMENTO ........................................................................................11 2.2.1 DINMICA DA EMPRESA......................................................................................................................11 2.2.2 INTERAO ANALISTA X APLICAO .............................................................................................11 2.2.3 PROCEDIMENTOS CONFLITANTES ....................................................................................................11 DEFINIES BSICAS....................................................................................................................................12 2.3.1 ESCOPO ....................................................................................................................................................12 2.3.2 AMBIENTE ...............................................................................................................................................12 LEVANTAMENTO DE REQUISITOS..........................................................................................................12 REQUISITOS .....................................................................................................................................................12 3.1.1 CARACTERSTICAS INVESTIGVEIS.................................................................................................12 3.1.2 TIPOS DE REQUISITOS...........................................................................................................................13 ARTEFATO DE REQUISITOS ........................................................................................................................13 3.2.1 OBJETIVO................................................................................................................................................14 3.2.2 COMPOSIO DOCUMENTO DE VISO.........................................................................................14 3.2.3 DESCRIO DOS TPICOS ..................................................................................................................14 APLICAO DE UML....................................................................................................................................16 DIAGRAMA DE CASO DE USO ......................................................................................................................16 4.1.1 ELEMENTOS BSICOS..........................................................................................................................16 4.1.1.1 CASOS DE USO ............................................................................................................................16 4.1.1.2 ATOR .............................................................................................................................................17 4.1.2 INCLUSO................................................................................................................................................17 4.1.3 EXTENSO...............................................................................................................................................17 4.1.4 GENERALIZAO-CASO DE USO .......................................................................................................18 4.1.5 GENERALIZAO DE ATOR ................................................................................................................18 DEFINIO DAS ITERAES .................................................................................................................................19 4.2.1 PLANEJAR ITERAES .................................................................................................................................19 CONCLUSO ....................................................................................................................................................20 EXEMPLO .............................................................................................................................................................20

1.3 1.4

INF0346 Anlise e Projeto de Sistema OO

1.5 2.0 2.1 2.2

NOTAS DE AULA

2.3

3.0 3.1 3.2

ELABORADO POR: CLAUDIA ABREU PAES

4.0 4.1

Rio de Janeiro
2007

4.2 4.3 4.4

- 2-

4.5

DIAGRAMA DE CLASSE.................................................................................................................................22 4.5.1 ELEMENTOS BSICOS...........................................................................................................................22 4.5.2 REPRESENTAO ..................................................................................................................................23 4.5.3 ASSOCIAO ..........................................................................................................................................23 4.5.4 PAPEL DO RELACIONAMENTO ...........................................................................................................24 4.5.5 MULTIPLICIDADE ..................................................................................................................................24 4.5.6 AUTO-ASSOCIAO ..............................................................................................................................25 4.5.7 NAVEGABILIDADE ................................................................................................................................25 4.5.8 AGREGAO...........................................................................................................................................26 4.5.9 GENERALIZAO ..................................................................................................................................27 4.5.10 ESPECIALIZAO ................................................................................................................................28 4.5.11 RESTRIES PARA GENERALIZAO/ESPECIALIZAO..........................................................29 4.5.12 CLASSES DE ASSOCIAO ................................................................................................................30 PROJETO DE SISTEMA ................................................................................................................................31 5.1 DESCRIO DE CASO DE USO................................................................................................................31 5.1.1 DESCRIO NO EXPANDIDA ......................................................................................................32 5.1.2 CASO DE USO EXPANDIDO.............................................................................................................32 5.2 DIAGRAMAS DE INTERAO.................................................................................................................34 5.2.1 DIAGRAMA DE SEQNCIA...........................................................................................................35 5.2.1.1 COMPONENTES......................................................................................................................36 5.2.2 DIAGRAMA DE COLABORAO ...................................................................................................40 5.2.2.1 COMPONENTES......................................................................................................................40 5.3 DIAGRAMA DE ESTADO ..........................................................................................................................41 5.3.1 SIMBOLOGIA .....................................................................................................................................41 5.3.2 SUPERESTADO ..................................................................................................................................43 5.3.3 AUTOTRANSIO ............................................................................................................................44 5.3.4 DIAGRAMAS CONCORRENTES .....................................................................................................45

1.0 PROCESSO RUP

um processo de desenvolvimento no qual o software no implementado em um instante no fim do projeto, mas , ao contrrio, desenvolvido e implementado em partes. RUP (Rational Unified Process) um processo de Engenharia de Software, desenvolvido pelos trs amigos (Jacobson, Booch e Rumbaugh, 1999). um produto que captura as melhores prticas de desenvolvimento de software: Desenvolver software interativo; Gerenciar requisitos; Usar arquiteturas baseadas em componentes; Modelar o software visualmente; Verificar a qualidade do software continuamente; Controlar mudanas no software; O desenvolvimento realizado em pequenos passos: Um pouco de planejamento; Um pouco de especificao, projeto e implementao; Um pouco de integrao e teste; Ajustes entre as iteraes;

5.0

6.0

IMPLEMENTAO........................................................................................................................................46 6.1 DIAGRAMA DE COMPONENTES.............................................................................................................46 6.1.1 ELEMENTOS DA NOTAO............................................................................................................46 6.2 DIAGRAMA DE IMPLANTAO .............................................................................................................47

7.0

BIBLIOGRAFIA...............................................................................................................................................49

BENEFCIOS Identificao de riscos adiantada; Preparao do sistema para requisitos que mudam; Integrao contnua (facilita testes) e aprendizado facilitado;

1.1 CICLO DE VIDA DE DESENVOLVIMENTO DE SISTEMAS

O ciclo de vida de desenvolvimento de um sistema ou software representa as etapas pelas quais se devem passar e quais os documentos que devem ser gerados desde o conhecimento do problema at a sua soluo instalada num computador. Podemos ter tipos de ciclos de vida diferentes para prototipagem rpida, prototipagem evolutiva, desenvolvimento convencional ou orientado a objetos. Porm a abordagem a ser utilizada a mesma: o conhecimento do problema, representao conceitual da soluo e a representao de como a soluo ser implementada atravs do uso de um computador.

- 3-

- 4-

1.2 CONCEITOS BSICOS 1.2.1 MODELOS

1.3.1 FASEAMENTO
FASES DISCIPLINAS REQUISITOS ANLISE PROJETO IMPLEMENTAO TESTE CONCEPO ELABORAO CONSTRUO TRANSIO

So abstraes que facilitam a compreenso e a comunicao; Modelos so formados de ARTEFATOS, que so diagramas e documentos que os descrevem;

1.2.2 WORKER
a representao de uma pessoa ou grupo no processo de software. PAPEL DOS WOKWERS Analista: identifica os casos de uso e atores; Descrever casos de uso; Arquiteto: prioriza os casos de uso e seleciona os relevantes para propor a arquitetura candidata; Desenvolvedor: implementa o prottipo; Engenheiro de testes: planeja testes;

MARCOS TEMPO

ESCPO

ARQUITETURA

OPERAO

RELEASE

1.2.3 FASES

Representa o conjunto de disciplinas para atingir objetivos dentro do ciclo de vida, ao longo do tempo.

1.2.4 DISCIPLINAS
Representa os procedimentos que agrupam atividades de engenharia de software por sua natureza para cada fase.
- 6-

1.3 CICLO DE VIDA

O ciclo de vida utilizado no processo RUP o Ciclo de Vida Iterativo e Incremental. Caracteriza-se por repetir o ciclo de vida para cada iterao e ao final incrementar a produo com uma nova verso do software.

- 5-

1.4 Definio das FASES 1.4.1 ITERAO 1.4.1.1 OBJETIVOS

ARTEFATOS Diagrama de caso de uso inicial; Diagrama de classe inicial; Diagrama de atividade; PONTO DE CONTROLE Ao final da CONCEPO o marco definido quando o escpo conhecido e bem fundamentado.

Padro comum que caracteriza todas iteraes de todas as fases; Inclui os cinco workflows bsicos: requisitos, anlise, projeto, implementao, e teste Inclui tambm planejamento e avaliao; Durante todo o ciclo de vida do desenvolvimento de software existem vrias seqncias de atividades sendo executadas; Buscar o equilbrio e sincronizar as diferentes seqncias de atividades; Em cada Iterao devemos trabalhar nas atividades certas; ITERAO

1.4.2.2 RESULTADOS

primeira verso do modelo de negcio (descreve o contexto do sistema); primeira verso dos modelos de use-case; primeira verso da arquitetura candidata; prottipo demostrando o uso do sistema; lista de riscos e suas prioridade; planejamento geral das demais fases; primeira verso do business case (estimativas e retorno);

1.4.3 ELABORAO
CONCEPO ELABORAO CONSTRUO TRANSIO

1.4.2 CONCEPO 1.4.2.1 OBJETIVOS

Definir necessidades reais dos patrocinadores; Delimitar claramente o escopo do projeto; Formular a arquitetura candidata; Levantamento de principais funcionalidades; A partir de um subconjunto chave de requisitos propor uma arquitetura; Planejamento: viso do projeto, estudo de viabilidade e anlise de riscos; O patrocinador concorda com a realizao de uma sria anlise de projeto;

OBJETIVOS Capturar quase todos use cases; Estabelecer uma arquitetura slida para guiar as fases de construo e transio; Monitorar riscos e seu impacto no caso de negcio; Refinar plano de projeto. Planejamento: tarefas (por prioridade e risco de desenvolvimento) x diviso de responsabilidades x prazos individuais e durao de suas interaes; montando a equipe; modificando o ambiente de implementao; estabelecer critrio de avaliao; Estender os requisitos; Escolher Casos de Uso para participar da interao; ATIVIDADES Definio das iteraes: tempo, tarefas e prioridades; Definio dos pares; ARTEFATOS Diagrama Diagrama Diagrama Diagrama de de de de caso de uso completo; classe completo; sequncia; estado;

ATIVIDADES Definio do problema; Definio dos requisitos; Prazos/ mtricas; Cronograma;

- 7 -

- 8 -

PONTO DE CONTROLE Ao final da ELABORAO o marco definido quando a ARQUITETURA est completa e o conjunto de requisitos foi definido.

1.4.5 TRANSIO

1.4.4 CONSTRUO

OBJETIVOS Completar as realizaes dos use cases, projetar as classes e subsistemas, implement-los como componentes, fazendo testes individuais ou em builds; O plano pode ser modificado por dois fatores: Gap possvel entre elaborao e construo; Finanas e cronograma podem ser alterados; Alocao de recursos - Aumento significativo de pessoas; Definio do critrio de avaliao; 4 atividades principais em paralelo: 5 workflows principais Planejar iteraes Business case (acompanhamento) Avaliao ATIVIDADES Codificao; Testes Sincronizao de artefatos; Medio e feedback; RESULTADOS Programas; Resultado de testes; Aprovao usurio; Manual de usurio preliminar; PONTO DE CONTROLE Ao final da CONSTRUO o marco a primeira verso beta.

OBJETIVOS Atingir a capacidade final de operao: Modificar o produto para aliviar problemas no detectados nas fases anteriores; Corrigir defeitos; Garantir que o produto est pronto para ser entregue ao usurio; Realizar treinamentos; ATIVIDADES Criao do ambiente de produo e cliente; Treinamento; RESULTADOS Verso implementada; Avaliao do plano; PONTO DE CONTROLE Ao final da TRANSIO o marco mais um release do produto.

1.5 CICLOS E RELEASES

A toda gerao de um novo release deve-se: Comparar progresso real com o planejado, acompanhando cronograma, oramento e esforo; Atualizar o documento se necessrio; Revisar o que foi executado, com o critrio de avaliao; Determinar se o processo est pronto para a prxima iterao;

2.0 O NEGCIO
2.1 RELAO USURIO x ANALISTA 9 Dificuldade do usurio em expressar necessidades; 9 Pouca participao do usurio no processo de concepo; 9 Analista tende a buscar uma soluo imediata; 9 Analista utiliza tcnicas e termos de uma tecnologia que o usurio desconhece; 9 Bloqueio do usurio quanto a nova proposta de trabalho; 9 A especificao do novo sistema um documento volumoso e difcil de ser interpretado pelo usurio; 9 Usurios e Analistas tm diferentes pontos de vista do problema (por terem diferentes formaes);

1.4.4.1 RESULTADOS
Plano de projeto para a transio. Software executvel - build final da construo. Todos os artefatos (modelos). Descrio da arquitetura mantida e atualizada. Business case, com mudanas refletidas. Manual de usurio preliminar.

- 9 -

- 10 -

2.2 RISCOS POTENCIAIS DO DESENVOLVIMENTO 2.2.1 DINMICA DA EMPRESA 9 Os problemas mudam 9 Turn-over no projeto em representantes do usurio equipe do projeto 2.2.2 INTERAO ANALISTA x APLICAO 9 Entendimento do domnio da aplicao O conhecimento do domnio da aplicao o conhecimento geral onde o sistema ser aplicado. 9 Entendimento do problema Os detalhes dos problemas especficos do problema do cliente onde o sistema ser aplicado deve ser entendido. 9 Entendimento do negcio Voc deve entender como os sistemas interagem e contribuem de forma geral com os objetivos de negcio. 9 Entendimento das necessidades e limitaes dos stakeholders do sistema Voc deve entender, em detalhe, as necessidades especficas das pessoas que requerem suporte do sistema no seu trabalho. 2.2.3 PROCEDIMENTOS CONFLITANTES 9 nfase nos processos em detrimento dos dados; 9 A documentao incompleta, imprecisa, e composta de narrativas e redundncias que levam a: intensificao da comunicao verbal; dependncia de esclarecimentos do autor; dificuldade de atualizao; 9 A documentao perde aderncia com a realidade pois, geralmente, elaborada ou complementada a posteriori; 9 Os sistemas dependem das pessoas envolvidas; 9 A evoluo da tecnologia no convenientemente absorvida; 9 Tentativa de reduo do tempo de desenvolvimento adicionando mais recursos; 9 A realidade no estruturada clientes sem registro de atraso de pagamento, ou em atraso at 30 dias mas que compram na loja h mais de um ano sem atraso, ou tenham mais de 30 dias de atraso mas que j tenham comprado mais de trs vezes sem atraso.... 9 Ausncia de uma especificao completa e consistente; 9 Inexistncia de uma ferramenta para identificar e registrar as necessidades do usurio; 9 O analista se preocupa mais com o computador e a tecnologia do que com a aplicao;

2.3 DEFINIES BSICAS 2.3.1 ESCOPO Estabelecer os limites do projeto: o que fazer e o que no fazer. 2.3.2 AMBIENTE o conjunto de elementos e suas propriedades relevantes que no fazem parte do sistema, mas que podem provocar mudanas no seu estado.

LEGISLAO(*)
FOLHA DE PAGAMENTO (**)

EMPRESA (**)
(*) AMBIENTE (**) SISTEMA

3.0 LEVANTAMENTO DE REQUISITOS

3.1 REQUISITOS So capacidades e condies s quais o sistema ou, o projeto deve atender. (JBR99) EXEMPLOS Regras de negcio Caractersticas operacionais Definio estratgica de comportamento 3.1.1 CARACTERSTICAS INVESTIGVEIS Funcionalidade O que o software dever fazer? Interfaces Externas Como o software interage com as pessoas, governo, com o hardware do sistema, com outros sistemas e outros produtos? Desempenho Quais a velocidade de processamento, o tempo de resposta e outros parmetros de desempenho requeridos pela natureza da aplicao? Outros atributos Quais as consideraes sobre confiabilidade que devem ser observadas? Restries impostas pela aplicao Existem limites a serem obedecidos como linguagem de implementao, limites de recursos?

- 11 -

- 12 -

3.1.2 TIPOS DE REQUISITOS Os requisitos so caracterizados pelo modelo modelo FURPS+> Funcionalidade, Usabilidade, Confiabilidade (Reliability), Desempenho (Performance) e Suportabilidade, Requisitos funcionais Esto relacionados aos procedimentos realizados pelos usurios quanto ao seu comportamento. Exemplo: regras de negcio, clculos, ; No Funcionais Esto relacionados s caractersticas desejveis do software quanto Usabilidade, Confiabilidade, Desempenho e Suportabilidade. Usabilidade Est relacionado a facilidade de uso, que gera maior produtividade, rpido aprendizado, memorizao de operaes e menor ndice de erros. Confiabilidade Est relacionado ao nvel de confiana que o sistema oferece, quanto a: estabilidade de execuo; rotinas de recuperao em casos de falha; rotinas de segurana para preservar a integridade, confidencialidade e autenticidade. Desempenho Relacionado a eficincia de execuo dos procedimentos. Suportabilidade Relacionado a capacidade de suprir regulamentaes internas na construo para gerar facilidade de manuteno. 3.2 ARTEFATO DE REQUISITOS

3.2.1 OBJETIVO Produzir um documento claro e fiel s informaes estudadas que servir para: Checar junto ao usurio o entendimento dos requisitos; Registrar o trabalho desenvolvido; Dar apoio a gerncia de mudanas; Obter aprovao e autorizao para continuidade do projeto. 3.2.2 COMPOSIO DOCUMENTO DE VISO O documento dever registrar: 1. O Negcio 1.1. Descrio 1.2. Justificativa do desenvolvimento 1.3. Abrangncia 2. A operao 2.1. Atores e seus papis 2.2. Cenrios e funcionalidades 2.3. Restries 3. Implementao Escolhida 4. Representao 4.1. Modelo Funcional 4.2. Modelo de Dados 3.2.3 DESCRIO DOS TPICOS 1. O Negcio 1.1. Descrio Redigir uma apresentao dos procedimentos que o negcio em questo realiza, tentando citar as dificuldades, melhorias e impactos que sero causados com a implantao do novo sistema. 1.2. Justificativa do desenvolvimento Apresentar a motivao existente para o desenvolvimento do novo sistema. 1.3. Abrangncia Definir o escopo de desenvolvimento, apresentando o limite de estudo. O limite definido dar suporte a todo planejamento de execuo das tarefas, garantindo prazos de entrega do produto. 2. A operao 2.1. Ator e Papel Ator (pessoas ou sistemas) Identificar quem ou o que ir usar e/ou operar o sistema, apresentando uma descrio e suas necessidades em relao ao sistema;

So vrios os artefatos gerados pela atividade de levantamento de requisitos e podemos citar como principais o documento de viso e o glossrio. O documento de viso tem como objetivo registrar as informaes obtidas durante o levantamento e um documento utilizado tambm para obter a aprovao do usurio e autorizao para dar prosseguimento ao desenvolvimento do projeto. O glossrio utilizado para registrar a definio dos termos utilizados com freqncia na abrangncia do projeto e especfico ao assunto abordado. A documentao do sistema deve ser elaborada com informaes precisas e fidedignas, pois registra os procedimentos do software e garante sua utilizao aps a implantao quando da mudana de requisitos.

- 13 -

- 14 -

Papel O que o ator desempenhar ao interagir com o sistema e que normalmente define o nome do ator para a modelagem e a importncia do ator no sistema. Identificao dos Atores Ator Papel Insumos (recebidos/enviados) Informaes enviadas <nome <relao / e/ou recebidas pelo ator importncia do do ator com o ator> sistema> ... Representar todos os atores Representante <utilizar sempre que o ator no assuma responsabilidade , embora interaja>

Operacional: trata-se de procedimentos operacionais indicados pelo ambiente/usurio; Ex.: - A carga dos dados se dar pelos prprios funcionrios da empresa; - O sistema dever ser mapeado com definio de permisses de funes. 3. Implementao Escolhida Descrever a alternativa de soluo adotada para implementao do sistema, indicando os recursos de hardware e software utilizados. 4. Representao Neste tpico so includos todos os modelos propostos pela UML que do suporte ao desenvolvimento do software em questo.

2.2. Cenrios e funcionalidades Representar todos os cenrios e suas funcionalidades, relacionados a atuao dos atores. Cenrio: Funcionalidades <descrever de forma sucinta> ... relacionar as funcionalidades do cenrio 2.3. Restries Relacionar as condicionantes estabelecidas pelo usurio e/ou ambiente que ser instalado o software. A restrio poder ser: Funcional: trata-se de uma regra de negcio. Ex.: - O mdulo 11 dever ser utilizado para gerao e verificao de dgito verificador. Tecnolgica: trata-se de uma definio prvia tecnolgica, em funo de estratgia da empresa ou recursos j disponveis. Ex.: - Utilizao de banco de dados Oracle; - Desenvolvimento em ambiente WEB. Atores envolvidos <fazer citao dos atores envolvidos>

4.0 APLICAO DE UML

UML (Unified Modeling Language) uma linguagem de modelagem que ir se associar ao processo para formar o mtodo.

4.1 DIAGRAMA DE CASO DE USO

9 o conjunto de cenrios amarrados por um objetivo comum. 9 Descreve a funcionalidade do sistema percebida por atores externos. 9 Utilizados para apresentar todos procedimentos a partir de um evento, independente da complexidade das respostas; 9 Representar o que realmente ser implementado; 9 Facilidade de comunicao com o usurio devido a linguagem utilizada;

4.1.1

ELEMENTOS BSICOS

4.1.1.1 CASOS DE USO

uma seqncia de passos que descreve uma interao entre um ATOR e o sistema. Casos de uso ocorrem quando um usurio realiza uma seqncia relacionada ao comportamento de transaes em um dilogo com o sistema, portanto, a arte est em identificar o que os usurios buscam cumprir em termos de atividades de negcio e no as funes que o sistema deve ter.

Nome Caso de Uso

- 15 -

- 16 -

4.1.1.2 ATOR

<ESTENDE> CADASTRAR PEDIDO

O mundo externo representado por atores que desempenham papis. Um ator um agente que interage com o sistema, um tipo de usurio ou categoria com papel definido, podendo incluir pessoas, mquinas, dispositivos ou outros sistemas.

REQUISITAR CATLOGO DO PEDIDO

4.1.4
NOME ATOR
O ator comunica-se com o sistema atravs do envio e recebimento de mensagens, sendo que um caso de uso sempre iniciado a partir do momento que um ator envia sua mensagem (estmulo).

Ocorre quando existe um conjunto de procedimentos semelhante em mais de um caso de uso, mas com alguns detalhes a mais.

GENERALIZAO-CASO DE USO

INSCREVER GRADUAO

ASSOCIADO

CONSULTA MDICA CREDENCIADO

ATENDENTE
INSCREVER PS - GRADUAO

INSCREVER ALUNO

4.1.2

Ocorre quando existe um conjunto de procedimentos semelhante em mais de um caso de uso e no so acionados por ator;

INCLUSO

4.1.5
CADASTRAR CLIENTE <USA> CALCULAR DGITO

Pode-se ter casos de uso especficos para cada especializao;

GENERALIZAO DE ATOR

4.1.3

EXTENSO

VENDEDOR

Ocorre quando existe um conjunto de procedimentos de exceo e casos especiais ligados ao Caso de Uso. Os atores tem um relacionamento ao caso de uso que est sendo estendido, sendo assumido que determinado ator realizar o caso de uso bsico e todas as suas extenses.

CONTRATADO
- 17 - 18 -

EFETIVO

4.2 Definio das Iteraes

O primeiro passo para definir as iteraes ordenar os requisitos e analisar prioridades para poder conhecer a ordem das iteraes. A anlise deve ser aplicada baseada em 3 fatores: risco, precedncia/cobertura e criticalidade. Risco: inclui complexidade tcnica, incerteza de esforo (treinamento), problemas polticos, usabilidade e novas tecnologias. Precedncia/Cobertura: inclui as partes do projeto necessrias para criar a arquitetura de software; Criticalidade: refere-se a funo de negcio de alto valor, ou seja, funes primrias para os cenrios de sucesso; Passos para determinar a ordem: 1. Relacionar os casos de uso; 2. Definir uma escala de atribuio de valor para medir risco, precedncia e criticalidade; 3. Definir um peso diferenciado para podermos diferenciar o valor dos elementos; 4. Calcular o valor de cada caso de uso, segundo a frmula: TotalParcial= (Risco*pesoRisco) + (Precedncia*pesoPrecedncia) + (Criticalidade * PesoCriticalidade); 5. Determinar a seqncia, onde a 1 iterao considerada para o valor maior;

4.3 CONCLUSO

Para obter sucesso em nosso desenvolvimento necessrio utilizarmos modelos adequados a: 9 critrios de qualidade 9 baixa manutenibilidade 9 grande iteratividade 9 boa performance 9 economia 9 segurana 9 disponibilidade 9 estabilidade

4.4 Exemplo
De acordo com o estudo de caso abaixo, defina a seqncia de execuo das iteraes. EMPRESA ALUGAR A Alugar uma empresa de locao de automveis. Possui uma grande frota de carros de passeio para atender seus clientes. Cada carro possui as suas descries e situaes de uso cadastrados em uma ficha. Todo semestre, o gerente de locao informa a administrao a renovao de sua frota, ou seja, as incluses ou excluses dos carros, para o devido cadastramento. O cliente que deseja alugar um carro, vai a administrao da Alugar, informa os dados pessoais e dados do carro alugado. O funcionrio da administrao verifica a disponibilidade do carro e se o cliente no est na lista negra da empresa. Com estas autorizaes e elaborado um contrato, em 2 vias, seguindo uma para o cliente e uma para a administrao, para futuro controle de devoluo. No contrato constam os dados pessoais do cliente e os dados do carro. Mensalmente, verificado se os carros foram devidamente entregues, ou seja, se os contratos esto vencidos. Se isto ocorrer, sero relacionados em uma lista negra, o nmero do contrato e o nome do cliente. Na devoluo do carro, o cliente informa o nmero do contrato e realiza o pagamento. dada baixa no contrato e entregue ao cliente um recibo de quitao de aluguel. Mensalmente, so emitidos 2 relatrios para gerncia realizar controle sobre a movimentao de suas frotas e contratos: Relatrio de posio dos carros da empresa; Relatrio de contratados; Para elaborao do plano devero ser considerados os seguintes requisitos no funcionais:

4.2.1

Planejar Iteraes

Aps determinar a ordem de realizao, deve-se planejar as iteraes. Segundo Larman, no se deve planejar todas as iteraes em um s planejamento, pois as necessidades mudam com freqncia e pode haver perda de tempo. Considerar no planejamento: 9 Nmero e nome da Iterao; 9 Objetivo; 9 Data Incio e Data Fim; 9 Equipe;

- 19 -

- 20 -

9 os casos de uso relacionados locao e devoluo so de grande interesse do usurio, pois tratam do objetivo principal do sistema; 9 Os veculos, quando cadastrados, devem ser fotografados, assim como os locatrios; 9 o caso de uso referente a gerao de contrato deve seguir regras definidas pela empresa, pois assegura legalmente o procedimento; obs.: Para desenvolvimento do trabalho dever ser considerado os riscos e impactos no negcio, viabilizando a priorizao dos casos de uso.

Consideraes: 9 Quando ocorrer de ter totais parciais iguais, devemos avaliar se a escala atribuda no est incorreta. Caso esteja correta, cabe ao analista decidir pela ordem; 9 As iteraes podero conter apenas parte dos requisitos, pois princpio do processo unificado realimentar o produto ao invs de blocos inteiro para planejar e executar;

4.5 DIAGRAMA DE CLASSE 4.5.1 ELEMENTOS BSICOS

OBJETO Em termos formais, um objeto uma unidade real ou abstrata, individualizada e identificvel que modela um conceito presente na realidade humana, ocupando espao fsico (mundo fsico) ou lgico (na memria). Um objeto uma pessoa, um lugar, uma coisa, enfim a base para todos os outros conceitos de orientao a objeto. CLASSE Classe a representao de um conjunto de coisas reais ou abstratas que so reconhecidas como sendo do mesmo tipo por compartilhar as mesmas caractersticas de atributos, operaes, relaes e semntica. Usando a terminologia da UML, a parte de dados de um objeto definida por um conjunto de atributos e a poro funcional definida por um conjunto de operaes.
Escala (0-10)

Casos de Uso Cadastrar Situao Alugar Carro Devolver Carro Cadastrar Frota Emitir relao de Posio de Carros Emitir relao de Contratados Cadastrar cliente Emitir contrato Emitir Recibo de Quitao Receber Pagamento Verificar Posio de Carro

Peso 3 2 1

Resultados Ordem 7 4 5 1 10 11 2 8 9 6 3

Risco Precedncia Criticalidade Total Parcial 1 1 6 12 5 10 5 4 23 0 0 0 0 4 4 20 0 3 3 0 2 2 2 4 3 0 4 13

DIAGRAMAS DE CLASSES Descreve os tipos de objetos no sistema e os vrios tipos de relacionamento esttico que existem entre eles: Associaes e Subtipos. Diagramas de classes tambm mostram atributos e operaes de uma classe e as restries maneira com que os objetos so conectados. COMO IDENTIFICAR 9 Possui vida prpria; 9 Possui mais de um atributo; 9 Deseja-se acompanhar existncia; Suas Anotaes

- 21 -

- 22 -

4.5.2

REPRESENTAO
NOME CLASSE um servio de classe ou comportamento resultante de um procedimento algortmico denominado OPERAO. Os nomes das operaes so muito importantes: uma operao deve possuir um nome que indique o seu resultado e no os passos executados na obteno desse resultado.

4.5.4

Identifica a ponta da associao;

PAPEL DO RELACIONAMENTO
ASSOCIAO PAPEL
ANOTA

ATRIBUTO a menor unidade que em si possui significncia prpria e interrelacionada com o conceito lgico da classe qual pertence. Apresenta um princpio de atomicidade, em outras palavras, do armazenamento de valores em clulas.

PEDIDOS

CARDAPIO

ITENS
NUMERO QTDE

NUMERO DT PEDIDO GARON MESA CADASTRAR() FECHARCONTA()

ITEM DESCRIO PREO UNIDADE VENDA

PONTA DE ASSOCIAO

ATUALIZAR()

TOTALIZAR()

4.5.5

Identifica quantos objetos participam da associao;

MULTIPLICIDADE

4.5.3

Representa relaes conceituais entre as classes.

ASSOCIAO

PEDIDOS

ASSOCIAO PAPEL
ANOTA

CARDAPIO

PEDIDOS

ASSOCIAO

CARDAPIO

NUMERO DT PEDIDO GARON MESA CADASTRAR() FECHARCONTA()

ITEM DESCRIO PREO UNIDADE VENDA

NUMERO DT PEDIDO GARON MESA CADASTRAR() FECHARCONTA()

0-N

1-N MULTIPLICIDADE PONTA DE ASSOCIAO

ITEM DESCRIO PREO UNIDADE VENDA

ATUALIZAR()

ATUALIZAR()

0 - PODE NO TER OCORRNCIA n - NUMERAL QUE REPRESENTA O MNIMO DE OCORRNCIA N - INFINITO LIMITE INFERIOR 0-N LIMITE SUPERIOR

- 23 -

- 24 -

4.5.6

Identifica objetos de mesma classe que participam da associao. Tambm chamada de ASSOCIAO UNRIA.

AUTO-ASSOCIAO

4.5.8

Indica quando o objeto de uma classe faz parte de outra; AGREGAO DE REFERNCIA (COMPE) Quando o objeto todo mantm um ponteiro ou uma referncia para suas partes. CLIENTE

AGREGAO

DISCIPLINA
CDIGO DESCRIO NUM_CREDITOS 0-N PR-REQUISITO CADASTRAR () 0-N

ESTADO CIVIL

CDIGO DESCRIO

0-N

CDIGO NOME NASCIMENTO

CADASTRAR ()

CADASTRAR ()

4.5.7

Indica a responsabilidade de identificao dos objetos das classes associadas;

NAVEGABILIDADE
ASSOCIAO

AGREGAO DE VALOR (ESTAR INSERIDO EM) Quando o objeto parte no criado a menos que o objeto todo ao qual esto agregados seja criado. Eliminando o todo implica em eliminar suas partes. COTAS CONTRATOS

PEDIDOS

PAPEL
ANOTA

GARON

NUMERO DT PEDIDO GARON MESA CADASTRAR() FECHARCONTA()

CDIGO NOME ADMISSO

NUMERO DT VENCIMENTO DT PAGAMENTO VALOR

0-N

CDIGO DATA VALOR

NAVEGABILIDADE UM PEDIDO TEM COMO RESPONSABILIDADE IDENTIFICAR O GARON

CADASTRAR() CADASTRAR () CADASTRAR ()

- 25 -

- 26 -

4.5.9

Uma superclasse criada para representar a essncia da idia sobre subclasses expressando os modos diferentes que tais essncias so percebidas. Indica que uma classe mais geral, a superclasse, tem atributos, operaes e associaes comuns que so compartilhados por classes mais especializadas, as subclasses. PESSOAS CDIGO NOME IDENTIDADE CNPJ CADASTRAR ()

GENERALIZAO

4.5.10

Uma superclasse criada para representar a essncia da idia sobre subclasses expressando os modos diferentes que tais essncias so percebidas. Indica que uma classe mais geral, a superclasse, tem atributos, operaes e associaes comuns que so compartilhados por classes mais especializadas, as subclasses, mas as subclasses possuem atributos individuais que as qualificam separadamente e, os tipos de um objeto so representados em classes distintas; PESSOAS CDIGO NOME

ESPECIALIZAO

SUPERCLASSE

SUPERCLASSE

CADASTRAR ()

FSICA

JURDICA SUBCLASSES FSICA IDENTIDADE JURDICA CNPJ SUBCLASSES

Suas Anotaes Suas Anotaes

- 27 -

- 28 -

4.5.11

RESTRIES PARA GENERALIZAO/ESPECIALIZAO

PESSOAS CDIGO NOME RESTRIO {Completo}: N conhecido {incompleto}: N no conhecido CADASTRAR () {COMPLETO, DISJUNO} {disjuno}: B,C,...,N so mutuamente exclusivos {sobreposio}: B,C,...,N podem ocorrer simultaneamente

4.5.12

Uma classe de associao um elemento de modelagem que tem associao e propriedades de classe, podendo ser vista tanto como uma associao que tem propriedades de classe como uma classe que tem propriedades de associao. Utilizadas para acrescentar atributos, operaes e outras caractersticas a uma associao; PEDIDOS NUMERO DT PEDIDO GARON MESA 1-N CARDAPIO 0-N ITEM DESCRIO PREO UNIDADE VENDA ATUALIZAR()

CLASSES DE ASSOCIAO

{SOMENTE ITENS DISPONVEIS EM CADASTRAR() CARDPIO} FECHARCONTA ITENS NUMERO QTDE TOTALIZAR()

FSICA IDENTIDADE

JURDICA CNPJ

RESTRIO

Suas Anotaes

Suas Anotaes

- 29 -

- 30 -

5.0 PROJETO DE SISTEMA

5.1 DESCRIO DE CASO DE USO
A UML no impe um modelo para a especificao de casos de uso, at porque ela no utiliza modelos textuais. No entanto, necessrio descrever o funcionamento de cada caso de uso. Alguns processos para UML j definem um padro de especificao, no entanto, independente disto, cada especificao deve ter pelo menos, o fluxo normal de funcionamento e os fluxos alternativos. CARACTERSTICAS 9 Representar a funcionalidade lgica; 9 Especificar passo-a-passo, sendo de responsabilidade do ator ou sistema; CONSIDERAES 9 O ltimo passo deve ser do sistema; 9 Manter padro de verbos e adjetivos utilizados; 9 No so utilizadas repeties e condies; 9 Um passo no deve ter mais do que uma linha; 9 Detalhar com um quadro de comentrio; possvel descrever de duas formas: Expandido e no expandido. Utilizamos um cabealho padro para documentar as informaes bsicas do caso de uso para as duas formas de descrio, contendo as seguintes informaes: DESCRIO CASO DE USO NOME: <nome do caso de uso> OBJETIVO: <objetivo do caso de uso> PR-CONDIO: <condies necessrias para realizao do requisito> PS-CONDIO: <ambiente resultado, aps realizao do requisito> DESCRIO: <detalhamento do requisito. O nvel de detalhe depender da forma utilizada: Expandido e No-expandido.>

5.1.1

DESCRIO NO EXPANDIDA

CARACTERSTICAS Relacionar e apresentar uma descrio sucinta do requisito; Deve ser utilizada quando o caso de uso no tiver muita complexidade; EXEMPLO DESCRIO CASO DE USO NOME: ALUGAR CARRO OBJETIVO: Cadastrar aluguel de veculo. PR-CONDIO: Veculo deve estar cadastrado. PS-CONDIO: Contrato com situao em aberto. DESCRIO: Caso de uso deve receber os dados de cliente, que dever escolher o veculo desejado e informar data de incio e fim de aluguel, cadastrar aluguel e atualizar posio de situao de veculo.

5.1.2

CASO DE USO EXPANDIDO

CURSO NORMAL 9 Representa a seqncia principal dos procedimentos; CURSO ALTERNATIVO 9 Representa a exceo e condies alternativas; EXEMPLO DESCRIO CASO DE USO NOME: ALUGAR CARRO DESCRIO: Vendedor cadastra aluguel de carro e efetiva contrato. CURSO NORMAL 1. Sistema Apresenta Tela De Aluguel. 2. Vendedor Informa Automvel e Perodo De Aluguel. 3. Sistema Verifica Disponibilidade Em CONTRATOS. 4. Vendedor Informa Cliente. 5. Sistema Verifica Incluso Em LISTA NEGRA. 6. Sistema Inclui CONTRATOS. 7. Sistema Apresenta Mensagem Para Emisso De Contrato. 8. Sistema grava ALUGUEL. 9. Sistema Encerra Caso De Uso.

- 31 -

- 32 -

CURSO ALTERNATIVO 3. Sistema Verifica Disponibilidade Em CONTRATOS. 3.1. No h disponibilidade de liberar carro no perodo desejado 3.1.1. Sistema apresenta mensagem de informao 3.1.2. Sistema desvia para item 1. 5. Sistema Verifica Incluso Em LISTA NEGRA. 5.1. Cliente est includo em LISTA NEGRA 5.1.1. Sistema apresenta mensagem de informao. 5.1.2. Sistema desvia para item 1. 7. Sistema Apresenta Mensagem Para Emisso De Contrato. 7.1 Vendedor deseja emitir (resposta = S) 7.1.1 Sistema estende para <EMITIR CONTRATO> 7.2 Vendedor no deseja emitir (resposta = N) 7.2.1 Sistema apresenta mensagem de informao Contrato dever ser emitido. 7.3 Sistema desvia para item 1.

5.2 DIAGRAMAS DE INTERAO

Apresenta a relao entre os objetos e as mensagens necessrias para representar o comportamento de um nico caso de uso. Para especificar uma interao, necessrio definir um contexto de caso de uso e estabelecer os objetos que interagem e seus relacionamentos. Diagrama de interao deve ser usado quando se deseja visualizar o comportamento de vrios objetos dentro de um nico caso de uso, a partir das mensagens que so passadas entre eles. Desenvolvedores diferentes tm preferncias prprias ao escolher o tipo de diagrama de interao a ser utilizado. Diagramas de interao so apresentados sob duas formas na UML: 9 DIAGRAMA DE SEQUENCIA;

janela de entrada de pedido

1: preparar um pedido

2: preparar

um item de pedido

3: [verificao == verdadeiro] remover um item de estoque

4: atualizar pedido um item de entrega

:FORM

:CARDPIO

INFORMA DATA VALIDADE

INFORMA 9 NOVO DIAGRAMA ITEMDE COLABORAO; INCLUIR

LER APRESENTAR LISTA DE ITENS

- 33 -

- 34 -

5.2.1 DIAGRAMA DE SEQNCIA

Tempo (top-down)

Apresenta objetos e classes envolvidas no cenrio e a seqncia de mensagens trocadas entre os objetos;

5.2.1.1 COMPONENTES
ATOR 9 Representa o ator interagindo com o cenrio que ser representado;

Um objeto

Condio de guarda Mensagem sncrona [se novo] criar mensagem

OBJETO 9 Representa os objetos do sistema: formulrios e classes; desenhado como um retngulo ao topo de uma linha vertical tracejada projetada para baixo. LINHA DE VIDA Um objeto desenhado como uma linha pontilhada vertical chamada linha de vida do objeto, que representa sua existncia em um momento particular. MENSAGEM Objetos necessitam comunicar-se entre si e isso ocorre atravs de fluxo de mensagens. Objetos remetentes enviam mensagens para objetos destinatrios, pedindo processamento, comunicando um evento ou qualquer outra informao que se tornar necessria no modelo para cumprir determinadas responsabilidades. A ordem na qual estas mensagens acontecem (fluxo de tempo) mostrada de maneira top-down, ou seja, do topo da pgina para baixo. Cada mensagem etiquetada no mnimo com o seu nome, mas tambm pode incluir argumentos e informaes de controle.

um novo objeto

objeto autodelegao

ativao

retornar excluir Smbolo de excluso

linha de vida

- 35 -

um item de pedido

um item de estoque

Verificar ( ) Retorno

- 36 -

Em um diagrama de seqncia, uma condicional indicada dividindo uma seta de mensagem em dois objetivos paralelos e, tal como em mquinas de estado finitas, em qualquer ponto de ramificao as expresses condicionais no devem ser ambguas.

Quando mensagem enviada vrias vezes para mltiplos objetos receptores: uma coleo;

pedido

Linha de pedido
[item vlido] * Verificar ( )

objeto 1

objeto 2

Objeto 3

[X>0]

ATIVAO a execuo de uma ao, agrupando vrios procedimentos. Uma ativao determina a janela de tempo na qual um objeto est executando diretamente uma ao ou atravs de um procedimento subordinado.

[X<=0]

*NOME DA
MENSAGEM ()

CONDIO DE GUARDA Uma mensagem tambm pode ser etiquetada com uma condio de guarda, isto , uma expresso booleana colocada em uma transio de estado. A mensagem enviada somente se condio verdadeira; Suas Anotaes

pedido

Linha de pedido [pedido vlido] Verificar ( )

ITERAO

- 37 -

- 38 -

AUTODELEGAO Autodelegao ou chamada reflexiva uma tcnica utilizada em algoritmos para mostrar que uma operao chama a si prpria.

5.2.2 DIAGRAMA DE COLABORAO

Um comportamento implementado por conjuntos de objetos que trocam mensagens para realizar um propsito em uma interao global. Uma colaborao anexada a um tipo, uma operao ou um caso de uso para descrever seus efeitos externos - isso no uma implementao mas uma especificao que descreve mudanas no ambiente externo causadas pelo elemento.

autodelegao
Em chamadas reflexivas para um objeto com uma ativao existente, o segundo smbolo de ativao desenhado ligeiramente direita do primeiro de forma que paream visualmente empilhados (podem ser aninhadas chamadas reflexivas a uma profundidade arbitrria). Suas Anotaes

Ao contrrio de um Diagrama de seqncia, um Diagrama de Colaborao mostra os relacionamentos entre os objetos, mas no trata o tempo como uma dimenso separada.

5.2.2.1 COMPONENTES
1: evento Objeto1: nome da classe Nome do ator: Classe do ator 2: operao

3: operao (lista de parmetros)

Objeto2

4: operao (lista de parmetros) Objeto3: nome da classe 5: operao (lista de parmetros) Fluxo de Objeto

: nome da classe

OBJETOS Representados como cones; MENSAGENS Representadas por setas; CONDICIONAL indicada com uma condio de guarda entre colchetes, ou seja, exibe uma condio que deve ser satisfeita para causar disparo de uma transio associada.

- 39 -

- 40 -

5.3 DIAGRAMA DE ESTADO

Diagrama de transio de estado (DTE) uma tcnica que descreve os estados possveis em que um objeto pode se encontrar e o que muda como resultado de eventos que o atingem. Demonstrado para uma classe nica mostrando o comportamento ao longo do tempo de vida de um nico objeto.

EXEMPLO

AGUARDANDO
ITENS NO RECEBIDOS ITENS RECEBIDOS

5.3.1 SIMBOLOGIA
DEFINE A SITUAO DO OBJETO AO FIM DA AO. O NOME DEVE VIR COM O VERBO DE AO NO GERNDIO. Ex.: Cotando Material.

INCIO

EVENTO O NOME DA TRANSIO. PARA ATRIBUIR NOMES A EVENTOS, EMPREGAMOS VERBOS NO PARTICPIO. EX: PEDIDO GERADO.

VALIDANDO
ITENS DISPONVEIS

EXPEDINDO

ESTADO

EVENTO [GUARDA] /AO GUARDA

UMA CONDIO LGICA. UMA TRANSIO GUARDADA OCORRE SOMENTE SE A GUARDA FOR VERDADE. AO ASSOCIADA COM TRANSIES E CONSIDERADA COMO PROCESSOS DE CURTA DURAO E NO PODEM SER INTERROMPIDOS.

CANCELADO

ATIVIDADE
ASSOCIADAS A ESTADOS, PODEM LEVAR MAIS TEMPO E PODEM SER INTERROMPID AS POR ALGUM EVENTO.

Suas Anotaes

FIM

- 41 -

- 42 -

5.3.2 SUPERESTADO
ATIVO

5.3.3 AUTOTRANSIO

Quando houver uma transio que retorna ao mesmo estado.

Quando um conjunto de atividades define ao final o mesmo estado.

AGUARDANDO
ITENS RECEBIDOS

ITENS NO RECEBIDOS

VALIDANDO
ITENS DISPONVEIS

EXPEDINDO

[NEM TODOS OS ITENS VERIFICADOS] /PEGAR PRXIMO ITEM

ESTADO ATIVIDADE

Suas Anotaes

CANCELADO

- 43 -

- 44 -

5.3.4 DIAGRAMAS CONCORRENTES

6.0 IMPLEMENTAO
A arquitetura fsica descreve a decomposio do hardware e software que cercam a implementao de um sistema. Na UML, aspectos de implementao fsica so modelados atravs de diagramas de implementao.
CANCELADO

Quando um objeto de uma mesma classe pode ter mais de um estado ao mesmo tempo para que ao final tenha um s estado. DEPTO VENDAS

ATIVO
AGUARDANDO ITENS NO RECEBIDOS

ITENS RECEBIDOS ITENS DISPONVEIS EXPEDINDO

6.1 DIAGRAMA DE COMPONENTES

Componentes modelam coisas fsicas que podem residir em um n, como: executveis, bibliotecas, tabelas, arquivos e documentos. Assim como na anlise, para a implementao de um software necessrio estabelecer qual a modelagem fsica do sistema executvel.
ENTREGUE

VALIDANDO

Um diagrama de componentes mostra as dependncias entre componentes de software, incluindo componentes de cdigo fonte, componentes de cdigo binrio e componentes executveis. Um diagrama de componente um grafo de componentes conectado por relacionamentos de dependncia.

AUTORIZANDO

AUTORIZADO

6.1.1 ELEMENTOS DA NOTAO

DEPTO FINANCEIRO

COMPONENTE
- 45 -

INTERFACE

DEPENDNCIA

EXEMPLO
ALUNOS

LANAMENTO DE NOTAS

PROFESSORES

TURMAS

- 46 -

6.2 DIAGRAMA DE IMPLANTAO

EXEMPLO <<HTTP>> <<ODBC>>

Os diagramas de implantao so utilizados para a modelagem da viso esttica de funcionamento de um sistema. Essa viso direcionada para a distribuio, entrega e instalao das partes que formam o sistema fsico. So utilizados para visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribudos. Envolvem a topologia do sistema, descrevendo a estrutura de hardware. Esses diagramas mostram a configurao de ns de processamento em tempo de execuo e os componentes que neles existem. Componentes que no existem em tempo de execuo no aparecem nestes diagramas. So diagramas teis tambm para a engenharia reversa. N Um diagrama de implantao um grafo de ns conectados por associaes de comunicao. Um n um objeto fsico que representa um recurso computacional. Ns geralmente inclumos computadores como processadores, e dispositivos, como impressoras, leitoras de carto, dispositivos de comunicao, etc.
<<LAN>> Cliente:Browser

Servidor de Aplicao

Banco de Dados

LANAMENTO DE NOTAS

ALUNO SGBD

PROFESSORES

PERSISTNCIA

TURMA

Impressora

Pentium 466 MMX

PC do Bob: Pentium 466 MMX

- 48 -

<<printer>>

<<router>>

HP LaserJet 5MP

Cisco Router X2000

- 47 -

7.0 BIBLIOGRAFIA
Engenharia de Software Roger S. Pressman 5 edio ISBN: 85-86804-25-8 junho de 2002 UML Essencial, 2 edio, M. Fowler e K. Scott, Bookman, 2000. Utilizando UML e Padres: Larman, Graig Bookman, 2000 Jakob Nielsen -Homepage: Usabilidade (Editora Campus) 2004.e Projetando Websites (Editora Campus) 2003; MINASI, M. - Segredos de Projeto de Interface Grfica com o Usurio, Rio de Janeiro: Infobook, 1997.MICROSOFT Co.- The Windows Interface Guidelines for Software Design, Redmond: Microsoft Press, 1996. Software Project Management in Practice, Pankaj Jalote, Addison Wesley, 2002. Anlise e Projeto Orientados a Objeto: Martin, James & Odell, J. J. Markon Books 1995

- 49 -