Apostila UML-UFPR PDF

Andrey Ricardo Pimentel
Projeto de Software Usando a UML

Apostila para Curso de Projeto de Sistemas Orientado a Objetos Usando a UML.
julho de 2007
Sumrio
AULA 1 PROCESSO DE SOFTWARE..........................................................................................5 1.1. Apresentao........................................................................................................................5 1.2. Introduo............................................................................................................................5 1.3. UML.....................................................................................................................................5 1.4. Crise do software.................................................................................................................6 1.5. Processo e Notao..............................................................................................................6 1.6. O poder da tecnologia de Objetos........................................................................................6 1.7. Anlise e projeto...................................................................................................................7 1.8. Desenvolvimento Iterativo e Incremental............................................................................7 1.9. Processo Unificado..............................................................................................................7 1.10. Atividade............................................................................................................................9 AULA 2 LEVANTAMENTO DE REQUISITOS..........................................................................10 2.1. Apresentao......................................................................................................................10 2.2. Levantamento de Requisitos..............................................................................................10 2.3. Atividade............................................................................................................................11 AULA 3 CASOS DE USO............................................................................................................13 3.1. Apresentao......................................................................................................................13 3.2. Comportamento do Sistema...............................................................................................13 3.3. Atores.................................................................................................................................13 3.4. Casos de Uso......................................................................................................................14 3.5. DIAGRAMAS DE CASO DE USO..................................................................................15 3.6. Atividade............................................................................................................................16 AULA 4 ESPECIFICAO DE CASOS DE USO......................................................................17 4.1. Apresentao......................................................................................................................17 4.2. A Especificao de um caso de Uso...................................................................................17 4.3. Atividade............................................................................................................................18 AULA 5 RELACIONAMENTOS ENTRE CASOS DE USO......................................................19 5.1. Apresentao......................................................................................................................19 5.2. Relacionamentos entre casos de uso..................................................................................19 5.3. Relacionamento <<include>>............................................................................................19 5.4. Relacionamento <<extend>>.............................................................................................19 5.5. Generalizaes...................................................................................................................20 5.6. Atividade............................................................................................................................21 AULA 6 IDENTIFICAO DE CLASSES USANDO O MVC..................................................22 6.1. Apresentao......................................................................................................................22 6.2. Descobrindo Classes..........................................................................................................22 6.3. Classes Entidade................................................................................................................22 6.4. Classes Limite....................................................................................................................22 6.5. Classes Controle.................................................................................................................23 6.6. Objetos e Classes no problema do Sistema de Matrcula (MATRI)..................................23 6.7. Atividade............................................................................................................................24 AULA 7 IDENTIFICAO DAS RESPONSABILIDADES DAS CLASSES ..........................25 7.1. Apresentao......................................................................................................................25 7.2. Cartes CRC......................................................................................................................25 7.3. Atividade............................................................................................................................26 AULA 8 IDENTIFICAO DE ATRIBUTOS E OPERAES DE UMA CLASSE................27
3 8.1. Apresentao......................................................................................................................27 8.2. O que uma operao?......................................................................................................27 8.3. O que um Atributo?.........................................................................................................29 8.4. Encapsulamento.................................................................................................................29 8.5. Atividade............................................................................................................................31 AULA 9 ASSOCIAES ENTRE CLASSES.............................................................................32 9.1. Apresentao......................................................................................................................32 9.2. Associaes........................................................................................................................32 9.3. Multiplicidade para Associaes........................................................................................33 9.4. Atividade............................................................................................................................34 AULA 10 AGREGAES E ASSOCIAES............................................................................36 10.1. Apresentao....................................................................................................................36 10.2. Agregao.........................................................................................................................36 10.3. Associaes Reflexivas....................................................................................................37 10.4. Classes de Ligao...........................................................................................................38 10.5. Encontrando Associaes e Agregaes..........................................................................39 10.6. Atividade..........................................................................................................................39 AULA 11 HERANA...................................................................................................................40 11.1. Apresentao....................................................................................................................40 11.2. Generalizao...................................................................................................................40 11.3. Herana Mltipla..............................................................................................................42 11.4. Atividade..........................................................................................................................43 AULA 12 INTERFACES E PACOTES.........................................................................................44 12.1. Apresentao....................................................................................................................44 12.2. Interfaces..........................................................................................................................44 12.3. Pacotes.............................................................................................................................45 12.4. Atividade..........................................................................................................................47 AULA 13 MODELO DE CLASSES, IMPLEMENTAO E MODELO RELACIONAL.........48 13.1. Apresentao....................................................................................................................48 13.2. Mapeando diagramas de Classe para cdigo em java......................................................48 13.3. Mapeando Classes para Modelo RElacional....................................................................50 13.4. Atividade..........................................................................................................................52 AULA 14 DIAGRAMAS DE INTERAO................................................................................53 14.1. Apresentao....................................................................................................................53 14.2. Diagramas de interao....................................................................................................53 14.3. Atividade..........................................................................................................................55 AULA 15 DIAGRAMAS DE SEQNCIA................................................................................56 15.1. Apresentao....................................................................................................................56 15.2. DESENVOLVIMENTO...................................................................................................56 15.3. Atividade..........................................................................................................................58 AULA 16 DIAGRAMAS DE ESTADOS.....................................................................................59 16.1. Apresentao....................................................................................................................59 16.2. Diagramas de Estados:.....................................................................................................59 16.3. Atividade..........................................................................................................................61 AULA 17 DIAGRAMAS DE COMPONENTES E DE IMPLANTAO..................................62 17.1. Apresentao....................................................................................................................62 17.2. Diagramas de Componentes.............................................................................................62 17.3. Diagramas de Implantao...............................................................................................63 17.4. Atividade..........................................................................................................................64
4 17.5. BIBLIOGRAFIA BSICA..............................................................................................64
AULA 1 PROCESSO DE SOFTWARE

1.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de processo de desenvolvimento de software, processo e notao, crise de software, anlise e projeto, desenvolvimento iterativo e incremental e do Processo Unificado.
1.2. INTRODUO
O desenvolvimento orientado a objetos comeou em 1967 com a linguagem Simula-67 e desde ento surgiram linguagens orientadas a objetos como Smalltalk e C++ entre outras. Nos anos 80 comearam a surgir metodologias de desenvolvimento orientadas a objetos para tirar vantagens deste paradigma. Entre 1989 e 1994 surgiram quase 50 mtodos de desenvolvimento orientados a objetos, fenmeno que foi chamado a guerra dos mtodos. Entre as mais importantes estavam: o mtodo de G. Booch, a Object Modeling Technique (OMT) de J. Rumbaugh, o mtodo de Shlaer e Mellor e o mtodo Objectory de I. Jacobson. I. Jacobson introduziu a modelagem de casos de uso em 1987 e criou o primeiro processo de desenvolvimento de software que utiliza casos de uso, chamado Objectory. Cada mtodo possua uma notao prpria, o que gerou uma infinidade de tipos de diagramas e notaes. Isto causava problemas de comunicao, treinamento de pessoal e portabilidade. Um esforo de unificao comeou em 1994 quando J. Rumbaugh e, logo aps, I. Jacobson, juntaram-se a G. Booch, na empresa Rational Software Corporation. O primeiro grande resultado desse esforo foi a criao da Unified Modeling Language (UML), apresentada, na sua verso 1.0, em 1997.
1.3. UML
A UML uma linguagem criada para visualizar, especificar, construir e documentar os artefatos de um sistema de software. A UML adotada, desde 1997, como padro internacional pelo OMG (Object Management Group). A UML prov um conjunto de diagramas e seus componentes, todos com notao e comportamento (semntica) bem definidos. A UML descreve 13 diagramas que so apresentados na figura abaixo.
1.4. CRISE DO SOFTWARE

No comeo os sistemas computacionais, tinham um custo de hardware muitas vezes maior que o custo do software. O software tinha um carter "descartvel". Com a diminuio dos custos do hardware e o aumento da complexidade do software, o custo do software comeou a ser notado. Com isso o software deixou de ser descartvel. Aumentaram as preocupaes com manuteno e evoluo dos softwares das empresas. Qualidade de software passou a ser fundamental. Fazer software deixou de ser arte para ser engenharia. Surgiram processos de desenvolvimento
1.5. PROCESSO E NOTAO

Processo de desenvolvimento de software pode ser definido como uma seqncia de etapas para a construo do software. Por exemplo: Especificao de requisitos, anlise, projeto, implementao, testes e implantao. Cada etapa tem objetivos bem definidos e gera um conjunto de artefatos. Artefatos so os produtos gerados em cada etapa. Por exemplo: uma etapa de anlise pode gerar os diagramas de caso de uso. Milestones so pontos do processo onde os artefatos da etapa devem ser sincronizados e validados. Por exemplo: o diagrama de classe deve ser sincronizado com o diagrama de seqncia. Notao a linguagem, grfica ou textual, usada na elaborao dos artefatos. UML uma linguagem de modelagem.
1.6. O PODER DA TECNOLOGIA DE OBJETOS

Amento da Coeso entre os mdulo e diminuio do Acoplamento Aumento da reutilizao de cdigo Facilita a criao de bibliotecas de classe da empresa Reduo do tempo de desenvolvimento dos projetos
7
Reduo do nmero de linhas de cdigo dos projetos
1.7. ANLISE E PROJETO

Anlise a descrio do problema a ser implementado Na anlise voc descreve os objetos e classes que existem no problema, suas relaes e como eles se comportam durante os eventos que existem no problema a ser implementado. Projeto a descrio da soluo adotada na implementao. No projeto voc descreve como os objetos que voc descreveu na anlise vo se comportar na soluo que voc criou. Tambm so criados novos objetos, relaes e comportamentos para facilitar e melhorar o sistema que vai ser construdo. No projeto, tambm descrita a arquitetura do sistema, sua base da dados, entre outros. O limite entre anlise e projeto no muito bem definido.
1.8. DESENVOLVIMENTO ITERATIVO E INCREMENTAL

O desenvolvimento de sistemas seguindo o Processo Unificado : Iterativo e incremental Guiado por casos de uso (use cases) Baseado na arquitetura do sistema
1.9. PROCESSO UNIFICADO

Outro grande resultado deste esforo de unificao de metodologias foi a criao, pela Rational, de um processo de desenvolvimento que usa a UML em seus modelos, chamado Processo Unificado. O Processo Unificado evoluiu do processo Rational Objectory, sendo inicialmente chamado de Rational Unified Process (RUP). O Processo Unificado, apesar de no ser um padro, amplamente adotado, sendo considerado como um modelo de processo de desenvolvimento de software orientado a objetos. O ciclo de vida de um sistema consiste de quatro fases, divididas em iteraes:

Concepo (define o escopo do projeto) Elaborao (define os requisitos e a arquitetura)
Construo (desenvolve o sistema) Transio (implanta o sistema)
Cada fase dividida em iteraes e cada iterao planejada realiza uma seqncia de atividades (de elicitao de requisitos, anlise e projeto, implementao, etc.) distintas geralmente resulta em uma verso executvel do sistema avaliada segundo critrios de sucesso previamente definidos
O Processo Unificado guiado por casos de uso Os casos de uso no servem apenas para definir os requisitos do sistema Vrias atividades do Processo Unificado so guiadas pelos casos de uso: planejamento das iteraes criao e validao do modelo de projeto planejamento da integrao do sistema definio dos casos de teste O Processo Unificado baseado na arquitetura do sistema Arquitetura a viso geral do sistema em termos dos seus subsistemas e como estes se relacionam A arquitetura prototipada e definida logo nas primeiras iteraes O desenvolvimento consiste em complementar a arquitetura A arquitetura serve para definir a organizao da equipe de desenvolvimento e identificar oportunidades de reuso Fluxos de atividades Atividades passos entradas e sadas guias (de ferramentas ou no), templates Responsveis (papel e perfil, no pessoa) Artefatos
1.10. ATIVIDADE
1) 2) 3) 4) 5) 6) Qual a diferena entre processo e notao? Qual a diferena entre anlise e projeto de sistemas de software? Cite algumas caractersticas da orientao a objetos. Quais so as caractersticas do processo unificado? Quais so e o que feito em cada uma das fases do processo unificado? O que arquitetura do sistema?
10
AULA 2 LEVANTAMENTO DE REQUISITOS

2.1. APRESENTAO
Nesta aula sero apresentados e discutidos os conceitos de concepo e especificao de um projeto de um sistema de software.
2.2. LEVANTAMENTO DE REQUISITOS

A atividade de levantamento de requisitos corresponde etapa de compreenso do problema. O levantamento de requisitos fornece o mecanismo adequado para entender o que o cliente deseja, analisando suas necessidade, e determinando se elas so possveis. Dificuldades no levantamento de requisitos:

Problemas de escopo: o limite do sistema mal definido ou o cliente especifica detalhes tcnicos que atrapalham a especificao. Problemas de entendimento: Os clientes ou usurios no esto certos do que necessrio para o sistema, no tm conhecimento sobre o domnio do problema, no tm conhecimento sobre as limitaes tcnicas ou omitem detalhes tcnicos. Problemas de volatilidade: Os requisitos mudam ao longo do tempo.
Durante o levantamento de requisitos a equipe tenta entender o domnio que deve ser automatizado pelo sistema de software. O levantamento de requisitos um estudo exploratrio das necessidades dos clientes, usurios e stakeholders (pessoas que so afetadas pelo sistema). O produto do levantamento de requisitos o documento de requisitos. Neste documento, os requisitos so categorizados em: requisitos funcionais, requisitos no funcionais e requisitos normativos. Os requisitos funcionais representam as necessidades que o sistema deve prover. Por exemplo:

O sistema deve permitir que o professor lance as notas de um aluno, O sistema deve permitir que o cliente se cadastre para receber emails, O sistema deve permitir que o gerente de vendas visualize o relatrio de vendas por regio.
Os requisitos no funcionais representam caractersticas de qualidade que o sistema deve ter e que no esto relacionadas com suas funcionalidades. Alguns tipos de requisitos funcionais so:
11

Confiabilidade: tempo mdio entre falhas, recuperao de falhas ou nmero de erros por milhares de linhas de cdigo. Desempenho: tempo de resposta esperado para cada funcionalidade do sistema. Portabilidade: restries sobre as plataformas de hardware ou software nas quais o sistema ser implementado e o grau de portabilidade para outras plataformas. Segurana: limitaes sobre segurana do sistema em relao a acessos no autorizados. Usabilidade: requisitos sobre facilidade de uso, idiomas, acessibilidades especiais, necessidade ou no de treinamento.
Os requisitos normativos representam restries impostas sobre o desenvolvimento do sistema como: adequaes a custos, prazos, plataforma, aspectos legais, alm de regras de negcio e polticas de funcionamento. O documento de requisitos serve como um termo de acordo entre o cliente e a equipe de desenvolvedores. Ele servir de base para as atividades de desenvolvimento e para validaes posteriores. O documento de requisitos estabelece o escopo do sistema, ou seja, o que faz parte do sistema e o que no faz parte do sistema.
2.3. ATIVIDADE
1)Faa uma especificao de requisitos para o sistema descrito abaixo: Sistema de Matrcula em cursos de Universidade O processo de designao de professores para cursos e a matrcula de estudantes uma experincia frustrante e que consome muito tempo. Depois que os professores da Universidade decidem em quais cursos eles vo lecionar no semestre, a Secretaria alimenta essa informao no sistema em computador. Um relatrio batch impresso para os professores indicando em quais cursos eles lecionaro. Um catlogo de cursos impresso e distribudo para os estudantes. Atualmente, os alunos preenchem formulrios de matrcula que indicam suas escolhas de cursos e retornam os formulrios para a Secretaria. A carga tpica de um estudante de quatro cursos. Os funcionrios da Secretaria alimentam os dados dos formulrios dos estudantes no sistema de computador no mainframe. Uma vez que o currculo para o semestre foi alimentado no sistema, um job batch executado durante a noite para inscrever os estudantes nos cursos. Na maioria das vezes os estudantes obtm sua primeira escolha; entretanto, naqueles casos em que h um conflito, a Secretaria conversa com cada estudante para obter escolhas adicionais. Quando todos os estudantes tiverem sido inscritos com sucesso nos cursos, um relatrio dos currculos dos estudantes encaminhado para eles para verificao. A maioria dos registros dos estudantes so processados durante uma semana, mas alguns casos excepcionais demoram at duas semanas para serem solucionados. Quando o perodo inicial de matrcula concludo, os professores recebem uma lista de estudantes para cada curso que devem lecionar. O novo sistema vai permitir, no incio de cada semestre, que os estudantes possam solicitar um catlogo de cursos contendo uma lista dos cursos oferecidos no semestre. Informaes sobre cada curso, tais como professor, departamento e pr-requisitos estaro includas para ajudar os estudantes a tomarem suas decises. O novo sistema vai permitir aos estudantes selecionarem quatro dos cursos oferecidos para o semestre. Alm disso, cada estudante indicar duas escolhas alternativas para
12
caso um curso oferecido seja cancelado ou no tenha vagas suficientes. Nenhum curso poder ter mais de dez ou menos do que trs alunos. Um curso com menos de trs alunos ser cancelado. Uma vez concludo o processo de matrcula de um estudante, o sistema de matrcula envia informao para o sistema de faturamento de forma que o aluno possa receber as faturas para o semestre. Professores devem poder acessar o sistema online para indicar quais cursos eles lecionaro e para ver que estudantes se inscreveram em suas ofertas de curso. Para cada semestre, h um perodo de tempo no qual os estudantes podem mudar sua grade horria. Os estudantes devem poder acessar o sistema durante este perodo para adicionar ou retirar cursos.
13
AULA 3 CASOS DE USO

3.1. APRESENTAO
Nesta aula sero discutidos de comportamento do sistema, como definir casos de uso e atores e como utilizar o diagrama de casos de uso para mostrar os atores, os casos de uso e suas interaes.
3.2. COMPORTAMENTO DO SISTEMA

O comportamento do sistema em desenvolvimento, que o que funcionalmente deve ser fornecido pelo sistema, documentado em um Modelo de Caso de Uso que ilustra as funes pretendidas do sistema (casos de uso), suas vizinhanas (atores) e relacionamentos entre os casos de uso e atores (diagramas de casos de uso). O papel mais importante de um modelo de caso de uso o de comunicao. Ele prov um veculo usado pelo cliente ou usurios finais e os desenvolvedores, para discutir a funcionalidade e o comportamento do sistema. O modelo de caso de uso iniciado na Fase de Concepo com a identificao dos atores e casos de uso principais do sistema. O modelo ento amadurecido na Fase de Elaborao informao mais detalhada adicionada aos casos de uso identificados, e casos de uso adicionais so introduzidos medida que forem necessrios.
3.3. ATORES
Atores no so parte do sistema - eles representam algo ou algum que deve interagir com o sistema. Um ator pode:

Somente fornecer informaes para o sistema Somente receber informaes do sistema Fornecer e receber informaes para e do sistema
Tipicamente, estes atores so encontrados na definio do problema e em conversas com clientes e especialistas no domnio do problema. As seguintes perguntas podem ser usadas para auxiliar na identificao dos atores de um sistema:

Quem est interessado numa certa necessidade? Onde na organizao o sistema usado? Quem se beneficiar do uso do sistema? Quem suprir o sistema com esta informao, usar esta informao e remover esta informao? Quem dar o suporte e manter o sistema? O sistema usa um recurso externo? Uma pessoa desempenha diferentes papis? Vrias pessoas desempenham o mesmo papel? O sistema interage com um sistema legado?
14
Na UML, um ator representado como um homem palito, como mostrado na figura abaixo.
Notao UML para um Ator O que constitui um bom ator? Devemos tomar cuidado quando identificamos um ator para o sistema. Esta identificao feita de uma maneira iterativa - a primeira lista de atores para um sistema raramente constitui a lista final. Por exemplo: um novo estudante um ator diferente de um estudante que est retornando? Suponha que voc inicialmente responda afirmativamente a esta questo. O prximo passo identificar como o ator interage com o sistema. Se o novo estudante usa o sistema de forma diferente de um estudante que retorna, eles so atores diferentes. Se eles usam o sistema da mesma forma, eles so o mesmo ator. Atores no Sistema de Matrcula - MATRI Respondendo s perguntas anteriores, identificaremos diversos atores. Um deles Professor. Documentao de Atores Uma breve descrio para cada ator deveria ser adicionada ao modelo. A descrio deveria identificar o papel que o ator desempenha na interao com o sistema. Exemplo: Professor - uma pessoa que certificada para lecionar na universidade
3.4. CASOS DE USO

Casos de Uso modelam um dilogo entre um ator e o sistema. Eles representam a funcionalidade fornecida pelo sistema; isto , que capacidades sero providas para o ator pelo sistema. A coleo de casos de uso para um sistema constitui todos os caminhos definidos nos quais o sistema pode ser usado. A definio formal para um caso de uso :
Um caso de uso uma seqncia de transaes executadas por um sistema, que produz um resultado mensurvel de valores para um ator em particular.
As seguintes perguntas devem ser usadas para auxiliar na identificao dos casos de uso para um sistema: Quais so as tarefas de cada ator? Algum ator criar, armazenar, mudar, remover ou ler informao do sistema? Que casos de uso criaro, armazenaro, mudaro, removero ou lero esta informao? Algum ator precisar informar o sistema a respeito de mudanas externas repentinas? Algum ator necessita ser informado a respeito de certas ocorrncias no sistema? Que casos de uso suportaro ou mantero o sistema? Todas as necessidades funcionais podem ser executadas pelos dos casos de uso? Na UML, um caso de uso representado como uma figura oval, como mostrado na figura abaixo.
15
Notao para caso de uso O que Constitui um Bom Caso de Uso? Ao longo dos anos tem havido muita discusso sobre o que um bom caso de uso. Um problema freqentemente encontrado o nvel de detalhe dos casos de uso. Isto , quo grande (ou quo pequeno) ele deveria ser? No h uma resposta certa. Uma boa regra aplicvel : Um caso de uso tipicamente representa uma pea maior de funcionalidade que est completa do incio ao fim. Um caso de uso deve fornecer algo de valor para um ator. Outro problema como empacotar funcionalidade que diferente mas que aparentemente deveria permanecer junta. Por exemplo, a Secretaria deve incluir cursos, eliminar cursos e modificar cursos. Trs casos de uso ou um nico? Aqui novamente, deveria ser feito um caso de uso - a manuteno de currculo, j que a funcionalidade iniciada pelo mesmo ator (a Secretaria) e trata com as mesmas entidades no sistema (o currculo).
3.5. DIAGRAMAS DE CASO DE USO

Um diagrama de caso de uso uma viso grfica de alguns ou todos os atores, casos de usos e seus relacionamentos identificados para um sistema. Cada sistema normalmente tem um Diagrama de Caso de Uso principal, o qual uma representao da fronteira do sistema (atores) e a maior funcionalidade fornecida pelo sistema (casos de uso). Outros diagramas de casos de uso podem ser criados quando necessrio. Alguns exemplos so: um diagrama que mostre todos os casos de uso para um ator selecionado; um diagrama mostrando todos os casos de uso a serem implementados em uma iterao; um diagrama mostrando um caso de uso e todos os seus relacionamentos com outros casos de uso e atores.
Exemplo de diagrama de casos de uso Casos de Uso no Sistema Matrcula - MATRI As seguintes necessidades devem ser tratadas pelo sistema:
O ator estudante precisa usar o sistema para registrar-se em cursos
16

Depois que o processo de seleo estiver completo, o sistema de Faturamento deve ser suprido com informaes de fatura O ator Professor precisa usar o sistema para selecionar os cursos para lecionar por um semestre e deve estar habilitado a receber uma lista de cursos do sistema A Secretaria responsvel pela gerao do catlogo de curso para um semestre e, pela manuteno de todas as informaes a respeito do currculo, dos estudantes e dos professores.
Baseado nestas necessidades, diversos casos de usos podem ser identificados, como o "Matricula em um curso".
3.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito acima, desenvolva as seguintes atividades: 1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e atores (coloque tudo no diagrama de casos de uso) 2)Faa uma breve descrio para os atores e os casos de uso que forem identificados (mximo 2 frases)
17
AULA 4 ESPECIFICAO DE CASOS DE USO

4.1. APRESENTAO
Nesta aula ser apresenta e discutida a especificao dos caso de uso
4.2. A ESPECIFICAO DE UM CASO DE USO

Cada caso de uso tambm documentado com uma Especificao de Caso de Uso. Uma Especificao dos casos de uso um documento que tem por objeto descrever o comportamento do casos de uso. Este comportamento descrito basicamente atravs do fluxo principal de eventos. O fluxo de eventos para um caso de uso uma descrio dos eventos necessrios para atingir o comportamento esperado do caso de uso. O fluxo de eventos escrito em termos do que o sistema deveria fazer, no como o sistema o faz. Isto , escrito na linguagem do domnio, no em termos de implementao. Especificao de Caso de Uso deveria incluir: Quando e como o caso de uso inicia e termina Que interao o caso de uso tem com os atores Que dados so necessrios para o caso de uso A seqncia normal de eventos para o caso de uso
A Especificao de Caso de Uso criada tipicamente na Fase de Elaborao numa maneira iterativa. Inicialmente, somente uma breve descrio dos passos necessrios para executar o fluxo normal do caso de uso (isto , que funcionalidade fornecida pelo caso de uso) escrita. medida que a anlise progride, os passos so preenchidos a fim de se adicionar mais detalhes. Finalmente, os fluxos de exceo so adicionados ao caso de uso. Cada projeto deveria usar um template padro para a criao da documentao do fluxo de eventos. til o seguinte template: 1Nome do Caso de Uso 2Breve descrio 3Fluxo de eventos 3.1Fluxo bsico 3.1.1< Primeiro evento do fluxo bsico> 3.1.2< Primeiro evento do fluxo bsico> 3.2Fluxos alternativos 3.2.1< Primeiro fluxo alternativo> 3.2.2< Outro fluxo alternativo> 4Requisitos Especiais 4.1< primeiro requisito especial > 5Pr-condies 5.1< pr-condio um > 6Ps-condies 6.1< ps-condio um > 7Pontos de Extenso
18
Uma amostra do documento de Fluxo de Eventos para o Caso de Uso Selecionar Cursos para Lecionar mostrada a seguir: Especificao do Caso de Uso Cadastrar Usurio 1 Nome do Caso de Uso Cadastrar Usurio 2 Breve descrio Cadastra um usurio no sistema, com todos os dados, inclusive uma fotografia. 3 Fluxo de eventos 3.1Fluxo bsico 3.1.1 O caso de uso comea quando o ator seleciona a opo cadastrar usurio. O sistema mostra a tela de cadastro de usurio com os seguintes campos em branco: nome, "endereo", RG, CPF, telefone, email. 3.1.2 O ator preenche os campos e seleciona a opo cadastrar. O sistema mostra uma tela para fazer o upload da fotografia. 3.1.3 O ator indica o nome e o caminho do arquivo com a sua fotografia e seleciona importar. O sistema mostra uma tela com todos os dados e a fotografia do cliente. 3.1.4 O ator seleciona a opo cadastrar e o sistema cadastra o novo usurio, mostra uma mensagem de sucesso na operao e mostra a tela inicial do sistema. 3.2 Fluxos alternativos 3.2.1< Primeiro fluxo alternativo> Caso o ator no tenha preenchido um dos campos dos dados do usurio, o sistema avisa o erro e retorna para a tela de cadastro dos dados do usurio com os dados j preenchidos. 3.2.2< segundo fluxo alternativo> Caso o usurio no importe um arquivo com a foto, o sistema mostra a tela de confirmao sem a fotografia e uma mensagem de aviso. 3.2.3< Terceiro fluxo alternativo> Caso o ator tenha cadastrado um usurio com o mesmo CPF, o sistema avisa o erro e retorna para a tela de cadastro dos dados do usurio com os dados j preenchidos. 4 Requisitos Especiais No se aplica 5 Pr-condies < pr-condio um > O ator deve estar logado no sistema. Nenhum outro usurio com o mesmo CPF dever ter sido cadastrado. 6 Ps-condies < ps-condio um > Um usurio novo cadastrado. 7 Pontos de Extenso No se aplica.
4.3. ATIVIDADE
1)Baseando-se na descrio dos sistema de matrculas (MATRI), descrito nas unidades anteriores, selecione 3 dos casos de uso identificados e faa a especificao de casos de uso para cada um deles
19
AULA 5 RELACIONAMENTOS ENTRE CASOS DE USO

5.1. APRESENTAO
Nesta aula ser apresentado e discutido como utilizar o diagrama de casos de uso para mostrar os atores, os casos de uso e suas interaes.
5.2. RELACIONAMENTOS ENTRE CASOS DE USO

Um relacionamento de associao pode existir entre um ator e um caso de uso. Esse tipo de associao normalmente chamado como uma Associao de Comunicao, desde que ela represente uma comunicao entre um ator e um caso de uso. Uma associao representada como uma linha que liga os elementos a serem relacionados. A navegao em somente uma direo pode ser representada pela adio de uma seta que indica a direo na linha da associao. No pode existir no modelo um caso de uso iniciado por dois atores. Existem somente 3 tipos de relacionamentos entre os casos de uso: <<include>>, <<extend>> e a generalizao.
5.3. RELACIONAMENTO <<INCLUDE>>

Muitos casos de uso podem compartilhar pedaos de pequenas funcionalidades. Esta funcionalidade colocada em separado em outro caso de uso ao invs de ser documentada em cada caso de uso que precisa dela. Relacionamentos de <<include>> so criados entre um novo caso de uso e qualquer outro caso de uso que utilize esta funcionalidade. Por exemplo, os casos de uso remover cliente e alterar cliente precisam pesquisar o cliente a ser removido ou alterado. Essa funcionalidade pode ser colocada em um caso de uso chamado de pesquisar cliente, o qual ento includo por outros casos de uso quando necessrio.
Figura relacionamento <<include>>
5.4. RELACIONAMENTO <<EXTEND>>

Um relacionamento de "extend" usado para mostrar: comportamento opcional, comportamento que somente executado sobre determinadas condies, como o disparo de
20
um alarme, muitos diferentes caminhos que podem ser executados de acordo com uma seleo feita por um ator. Por exemplo, um caso de uso que monitora o fluxo de pacotes em uma esteira de transporte pode acionar um caso de uso de Disparo de Alarme se os pacotes empilharem. At este momento, nenhum <<extend>> foi identificado para o Sistema de Matrcula (MATRI).
Figura relacionamento <<extend>> Um relacionamento extend de um caso de uso A para um caso de uso B indica que o caso de uso B pode ser aumentado (de acordo com condies especificadas na extenso) por um comportamanto especificado pelo caso de uso A. O comportamento inserido no local definido pelo ponto de extenso em B o qual referenciado pelo relacionamento extend. No caso de uso A, o comportamento a ser inserido deve ser marcado com um rtulo.
5.5. GENERALIZAES
Uma generalizao entre um caso de uso C e um caso de uso D indica que C uma especializao de D. Este relacionamento representado por uma seta de generalizao partindo de D para C. Pode ser representado, tambm, um tipo de relacionamento entre atores. Este relacionamento o de generalizao. Uma generalizao de um ator A para um ator B indica que A pode se comunicar com os mesmos casos de uso que B.
Siga a seguinte regra: Utilize <<extend>> quando estiver descrevendo uma variao do comportamento normal de um caso de uso; Utilize <<include>> para permitir a reutilizao de um determinado comportamento de um caso de uso por outros casos de uso.
21
5.6. ATIVIDADE
Baseando-se na descrio dos sistema de matrculas (MATRI), descrito na unidade anterior, desenvolva as seguintes atividades: 1)Encontre os casos de uso, os atores, e os relacionamentos entre os casos de uso e atores (coloque tudo no diagrama de casos de uso)
22
AULA 6 IDENTIFICAO DE CLASSES USANDO O MVC

6.1. APRESENTAO
Nesta aula ser visto como identificar Classes de um sistema usando o Padro Modelo-VisoControlador.
6.2. DESCOBRINDO CLASSES

No existe um livro de receitas que ensine como descobrir classes. O RUP (Rational Unified Process) sugere que as classes sejam descobertas no desenvolvimento do sistema, procurando as classes de limite, controle e entidade. Estes trs esteretipos ajustam-se, ponto de vista model-view-controler e permitem ao analista particionar o sistema separando a viso do domnio do controle necessrio pelo sistema. Tendo como base, que a anlise e o projeto do processo so interativos, a lista de classes ir mudar ao longo do tempo. O conjunto inicial de classes provavelmente no ser o conjunto de classes que sero efetivamente implementadas. Para ns, o termo candidato para uma classe freqentemente usado para descrever o primeiro conjunto de classes descobertas para o sistema.
6.3. CLASSES ENTIDADE

Uma classe entidade modela informao e comportamento associado que geralmente tem uma vida longa. Este tipo de classe pode refletir uma entidade do mundo real, ou ela pode ser necessria para executar uma tarefa interna do sistema. Elas so tipicamente independentes do meio em que esto; isso , elas no preciso saber como as classes que esto no limite se comunicam com o sistema. Muitas vezes, elas so aplicaes independentes, isso significa que muitas delas podero ser utilizadas por mais de uma sistema. O primeiro passo examinar as responsabilidades documentadas no fluxo de eventos para o caso de uso identificado (i.e., o que o sistema deve fazer). Classes entidade so normalmente utilizadas pelo sistema para definir alguma responsabilidade. Os nomes e as frases usadas para descrever a responsabilidade podem ser um bom ponto de partida. A lista inicial de nomes deve ser filtrada, pois ela pode conter nomes que esto fora do domnio do problema, nomes que so somente expresso de linguagem, nomes que so redundantes, e nomes que so descries da estrutura da classe. Classes entidade so normalmente encontradas na Fase de Elaborao. Elas so freqentemente chamadas de classes de domnio, desde que elas usualmente tratam com abstraes de entidades do mundo real.
6.4. CLASSES LIMITE

Classes Limite cuidam da comunicao entre meio com o qual o sistema interage e o sistema propriamente dito. Elas fornecem a interface para um usurio ou para um outro sistema (i.e., a interface para um ator). Elas constituem a parte do sistema que dependem do meio em que elas esto. Classes limite so utilizadas para modelar as interfaces do sistema.
23
Cada par ator/cenrio examinado para descobrir as classes limite. As classes limites escolhidas na Fase de Elaborao do desenvolvimento so tipicamente de alto nvel. Por exemplo, voc pode modelar uma janela mas no modela cada caixa de dilogo e botes. Neste ponto, voc est documentando os requerimentos da interface com o usurio, no implementando a interface. Os requerimentos das interfaces com o usurio tendem a ser muito vagos - os termos amigveis e flexveis so muito utilizados. Mas amigvel, tem significados diferentes para pessoas diferentes. Neste caso as tcnicas de prototipagem podem ser muito teis. O cliente pode dar uma olhada e sentir o sistema e realmente entender o que o termo amigvel significa. O "o que" ento compreendido assim como a estrutura e o comportamento da Classe Limite. Durante o projeto, essas classes so refinadas para levar em considerao os mecanismos da interface escolhida. Classes Limite so tambm adicionadas para facilitar a comunicao com outros sistemas. Durante o projeto, estas classes so refinadas para levar em considerao o protocolo de comunicao escolhido.
6.5. CLASSES CONTROLE

Classes Controle modelam uma seqncia de comportamento especfico a um ou mais casos de uso. Classes Controle coordenam os eventos necessrios para a realizao do comportamento especificado em um caso de uso. Voc pode pensar que uma Classe Controle como "rodando" ou "executando" o caso de uso - ela representa a dinmica do caso de uso. Estas classes normalmente so classes dependentes da aplicao. Logo nos primeiros estgios da fase de Elaborao, uma Classe Controle adicionada para cada par Ator/Caso de Uso. A Classe Controle responsvel pelo fluxo de eventos do caso de uso. O uso de Classes Controle muito subjetivo. Muitos autores sentem que o uso de Classes Controle resultam no comportamento sendo separado dos dados. Isso pode acontecer se a Classe Controle no foi escolhida prudentemente. Se uma Classe Controle est fazendo mais do estabelecer uma seqncia, ento ela est fazendo coisas demais. Por exemplo, no sistema de matrculas, um estudante seleciona um curso ofertado, se o curso ofertado est disponvel, o estudante matriculado nele. Quem sabe como matricular um estudante - a Classe Controle ou a OfertaCurso? A resposta correta , OfertaCurso. A Classe Controle sabe quando o estudante deveria ser matriculado, o curso ofertado sabe como matricular o estudante. Uma pssima Classe Controle no saberia s quando matricular o estudante mas como matricular o estudante. A adio de uma Classe Controle para cada par Ator/Caso de Uso somente um comeo enquanto a anlise e o projeto continuam, as Classes Controle podem ser eliminadas, explodidas ou combinadas.
6.6. OBJETOS E CLASSES NO PROBLEMA DO SISTEMA DE MATRCULA (MATRI)

Vamos dar uma olhada no cenrio Adicionando uma Oferta de Curso para Lecionar, o qual um dos subfluxos do caso de uso Selecionar Cursos para Ministrar (ver apostila anterior, sobre Comportamento do Sistema). A principal definio especificada neste cenrio a habilidade do professor selecionar um curso ofertado para lecionar em um dado semestre. Embora ns estejamos olhando este processo passo a passo, muitos desses passos podem ocorrer ao mesmo tempo no mundo real.
24
Identificando Classes Limite Este caso de uso interage somente com o ator Professor. A ao especificada neste cenrio somente uma das definidas no caso de uso (o caso de uso tambm afirma que o Professor pode modificar, excluir, rever e imprimir a seleo). Isto significa que alguma coisa no sistema deve prover ao Professor a capacidade de selecionar a sua opo. Uma classe contm todas as opes disponveis ao Professor como est registrado no caso de uso, para satisfazer a especificao feita. Esta classe chamada OpesCursoProfessor. Adicionalmente podemos identificar uma classe que faa a adio de um novo Curso Ofertado para o Professor. Esta classe chamada AdicionaOfertaCurso. Identificando Classes Entidade Este cenrio est relacionado com Cursos, com as Ofertas de Curso e com o Relacionamento do Curso com o Professor. Ns podemos identificar trs classes entidade: Curso, OfertaCurso e InformaoProfessor. Identificando Classes de Controle Iremos adicionar uma classe de controle para manusear o fluxo de eventos para o caso de uso. Esta classe chamada ControleCursoProfessor. As classes identificadas foram adicionadas ao modelo.
6.7. ATIVIDADE
Baseando-se no modelo de Caso de Uso abaixo, tente levantar as classes para o sistema de Matrcula (MATRI).
25
AULA 7 IDENTIFICAO DAS RESPONSABILIDADES DAS CLASSES

7.1. APRESENTAO
Nesta aula ser visto como identificar as classes de um sistema usando os cartes CRC
7.2. CARTES CRC

Uma forma para modelar um problema em classes e objetos a forma proposta no artigo "A Laboratory For Teaching Object-Oriented Thinking", por ser simples e fcil de ser aplicada. So os Cartes Classe-Responsabilidade-Colaboradores (CRC). Os cartes CRC foram usados por algumas metodologias de desenvolvimento como a apresentada por Wirfs-Brock, Wilkerson e Wiener no livro "Designing Object-Oriented Software". baseada nos trs atributos principais de um objeto na fase de projeto: nome da classe, suas responsabilidades e seus colaboradores. O nome da classe deve descrever o objeto no contexto geral do ambiente. Deve-se tomar um certo cuidado e gastar um pouco de tempo para escolher o conjunto certo de palavras para descrever o objeto. As responsabilidades devem identificar os problemas a serem resolvidos e no as solues. Identificando-se os problemas fica fcil escolher entre as solues possveis. Novamente deve-se tomar cuidado com o conjunto de palavras usadas. As frases devem ser curtas e concisas. Os colaboradores de um objeto so os objetos para os quais este ir enviar mensagens a fim de satisfazer as suas responsabilidades. Para facilitar a modelagem, Cunningham inventou os cartes Classe-ResponsabilidadesColaboradores (CRC). Esses cartes servem, tambm, como meio de documentao do projeto. Os cartes CRC so pedaos de papel grosso medindo 10x15cm e contm o nome da classe, as responsabilidades e os colaboradores, como na figura.
26
A disposio espacial dos cartes importante. Quando duas classes so mtuas colaboradoras, seus cartes devem ser colocados levemente sobrepostos. Quando uma classe colaboradora de outras classes (a classe usada pelas outras), seu carto deve ficar abaixo dos cartes das outras classes. Se h uma relao de herana, dever haver uma sobreposio quase completa dos cartes. A disposio dos cartes importante, pois em projetos ainda incompletos possvel notar a localizao de uma classe antes da mesma ter sido projetada. Para achar as classes, sua responsabilidades e seus colaboradores deve-se seguir as seguintes etapas: 1. Definio das classes e das estruturas de dados de cada classe; 2. Definio das responsabilidades de cada classe; 3. Definio dos colaboradores de cada classe; O que so classes e como defini-las Num problema a ser resolvido, as diversas classes podem ser identificadas como as entidades que existem no problema, por exemplo, aluno, turma, professor, etc... So classes, tambm, as estruturas de dados utilizadas para resolver o problema, bem como os dispositivos(fsicos e virtuais) a serem acessados. Por exemplo: interface, arquivo, controlador de tempo, etc... O que so responsabilidades e como defini-las As responsabilidades so definidas como sendo os problemas que as classes devem resolver. So, a grosso modo, as funes das classes. Por exemplo: colocar um registro no arquivo, dar presena ao aluno, cobrar mensalidade, etc... As responsabilidades so os problemas a serem resolvidos. A maneira de resolve-los vo ser os mtodos das classes(implementao). O que so colaboradores e como defini-los Os colaboradores so as classes que ajudam uma classe a resolver as suas responsabilidades. So as classes que vo prestar servios classe. A classe que est sendo analisada solicita servios a outras classes e estas, por sua vez, prestam estes servios, ajudando a resolver os problemas.
7.3. ATIVIDADE
1. modelar o problema de controle de uma pizzaria de entrega em domiclio. O cliente pede uma ou mais pizzas, refrigerantes ou cervejas. O atendente anota o pedido no sistema. Cada pizza pode ser (mdia, grande ou enorme). Cada pizza pode ter no mximo 3 sabores. O atendente anota os dados do cilente e a forma de pagamento (inclusive o troco necessrio). O atendente anota o cdigo do entregador e o tempo de entrega. O gerente cadastra os sabores de pizzas existentes, os dados dos entregadores e visualizaos relatrios de vendas(por sabor, regio) e tempo de entrega.
27
AULA 8 IDENTIFICAO DE ATRIBUTOS E OPERAES DE UMA CLASSE

8.1. APRESENTAO
Nesta aula ser visto como identificar os atributos e as operaes das classes do sistema
8.2. O QUE UMA OPERAO?

Uma classe incorpora um conjunto de responsabilidades que definem o comportamento dos objetos na classe As responsabilidades de uma classe so executadas por suas operaes No necessariamente um mapeamento um-para-um Responsabilidade da classe Produto -- fornecer preo Operaes para esta responsabilidade Buscar informao de um banco de dados Calcular o preo Uma operao um servio que pode ser requisitado por um objeto para obter um dado comportamento
Operaes Dependem do Domnio
Liste todas as operaes relevantes ao domnio do problema As operaes de uma classe Pessoa sero diferentes dependendo de 'quem est perguntando'
Perspectiva do Bancrio receber emprstimo anexar conta receber linhaDeCrdito

Nomeando Operaes
Perspectiva do Mdico examinar tomarRemdio irParaHospital receberConta
As operaes devem ser nomeadas para indicar seus resultados, no os passos por trs da operao. Exemplos: calcularSaldo() Nome pobre Indica que o saldo deve ser calculado - isto uma deciso de implementao/otimizao obterSaldo() Bem nomeado Indica apenas o resultado
Nomeando Operaes As operaes devem ser nomeadas do ponto de vista do fornecedor e no do cliente Em um posto de gasolina, a gasolina vem da bomba
28
Uma operao para que a bomba tenha esta responsabilidade -- como deveria ser chamada? Bons nomes -- distribuir(), darGasolina() Nome ruim -- receberGasolina() A bomba d a gasolina -- ela no recebe a gasolina
O que uma Operao Primitiva? Uma operao primitiva uma operao que pode ser implementada apenas usando o que intrnseco, interno a classe Todas as operaes de uma classe so tipicamente primitivas Exemplos: Adicione um item a um conjunto -- operao primitiva Adicione quatro itens a um conjunto -- no primitiva Pode ser implementada com mltiplas chamadas a operao adicione um item a um conjunto
Assinatura da Operao A assinatura da operao consiste de : Lista de argumentos opcional Classe de retorno Durante a anlise NO OBRIGATRIO preencher a assinatura de operaes Esta informao pode ser adiada para fase de projeto Mostrando Operaes Operaes so mostradas no terceiro compartimento da classe
Descobrindo Operaes nos Diagramas de Interao

As mensagens mostradas nos diagramas de seqncia e/ou colaborao so usualmente operaes da classe receptora As mensagens so traduzidas em operaes e adicionadas ao diagrama de classes
um curso GerenteDe Matricula um curso
GerenteDe Matricula
get prerequisito
getPrerequisito():ListaDeCurso
29
8.3. O QUE UM ATRIBUTO?

Um atributo uma caracterstica de uma classe Atributos no tem comportamento -- eles no so objetos Nomes de atributos so substantivos simples ou frases substantivas Os nomes devem ser nicos dentro da classe Cada atributo deve ter uma definio clara e concisa Bons atributos para a classe Estudante: Nome -- primeiro e ltimo nome CampoEstudo -- principal campo de estudo Atributos ruins -- cursosSelecionados Isto um relacionamento e no um atributo
Mostrando Atributos
Atributos so mostrados no segundo compartimento da classe
Como Descobrir Atributos? Muitos atributos so descobertos no texto da descrio do fluxo de eventos para os casos de uso Procure substantivos que no foram considerados bons candidatos para classes Outros so descobertos quando a definio da classe criada Experincia no domnio tambm pode prover bons atributos Exibindo Atributos e Operaes

Atributos e/ou operaes podem ser mostrados dentro de uma classe Diagramas de classes adicionais podem ser criados para exibir atributos e operaes Os relacionamentos no costumam ser exibidos nestes diagramas de classes
8.4. ENCAPSULAMENTO
Uma maneira de visualizar uma classe a que consiste de duas partes: a interface e a implementao A interface pode ser vista e usada por outros objetos (clientes) A implementao escondida dos clientes Esconder os detalhes da implementao de um objeto chamado encapsulamento ou "information hiding" Encapsulamento oferece dois tipos de proteo. Protege:
30

O estado interno de um objeto de ser corrompido por seus clientes O cdigo cliente de mudanas na implementao dos objetos
Exemplo: Encapsulamento Valores de atributos podem ser alterados apenas pelas operaes providas pelo objeto
saque
mudeNomeProprietrio
depsito
nmeroConta nomeBanco nomeProprietrio saldo geraTransao
So criadas operaes para mostrar os valores de atributos requisitados por clientes O estado do objeto no pode ser modificado diretamente por clientes
getSaldo
Benefcios do Encapsulamento

O cdigo cliente pode usar a interface para uma operao O cdigo cliente no pode tirar vantagem da implementao de uma operao A implementao pode mudar, por exemplo, para:

Corrigir um erro (bug) Aumentar performance Refletir uma mudana no plano de ao
O cdigo cliente no ser afetado pelas mudanas na implementao, assim reduzindo o "efeito ondulao" (ripple effect) no qual uma correo em uma operao fora correes correspondentes numa operao cliente, o qual por sua vez, causa mudanas em um cliente do cliente... A manuteno mais fcil e menos custosa
31
8.5. ATIVIDADE
1) modelar o problema de controle de uma pizzaria de entrega em domiclio. O cliente pede uma ou mais pizzas. O atendente anota o pedido no sistema. Cada pizza pode ser (mdia, grande ou enorme). Cada pizza tem apenas 1 (um sabor). O atendente anota os dados do cilente e o pedido. A tela acima a usada para anotar o pedido.
32
AULA 9 ASSOCIAES ENTRE CLASSES

9.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so associaes entre classes e como us-las. Iremos abordar aspectos como: associaes, nomes, papeis, multiplicidade, qualificadores, navegabilidade e associaes reflexivas.
9.2. ASSOCIAES
A Necessidade de Relacionamentos Todos os sistemas abrangem muitas classes e objetos Objetos atuam no comportamento de um sistema colaborando entre eles A Colaborao realizada atravs de relacionamentos Ocorrem dois tipos importantes de relacionamentos durante a anlise Associao e Generalizao Associaes Uma associao uma conexo semntica bi-direcional entre classes Isto implica na existncia de uma ligao (link) entre os objetos das classes associadas Associaes so representadas no diagrama de classes por uma linha ligando as classes associadas. Em um link os dados podem fluir em ambas as direes
Navegao Uma associao um relacionamento bi-direcional Dada uma instncia de GerentelDeMatrcula h um objeto Curso associado Dada uma instncia de Curso h um objeto OficialDeMatrcula associado
Dando Nomes s Associaes Para tornar seu significado mais claro, uma associao pode receber um nome O nome representado como uma etiqueta (label) colocada ao longo da linha de associao, no meio da linha, entre os cones das classes Um nome de associao geralmente um verbo ou uma frase verbal
33
Definindo Papis Um papel denota o propsito ou capacidade em que uma classe se associa com outra Nomes de papis so tipicamente substantivos ou frases substantivas Um nome de papel colocado ao longo da linha de associao, prximo da classe referenciada Um ou ambos os lados da associao podem ter nomes de papis
Associaes Mltiplas Pode existir mais de uma associao entre duas classes Se houver mais de uma associao entre duas classes, elas DEVEM ser nomeadas
Associaes mltiplas devem ser questionadas
9.3. MULTIPLICIDADE PARA ASSOCIAES

Multiplicidade o nmero de instncias de uma classe relacionada a UMA instncia da outra classe Para cada associao, devem ser tomadas duas decises de multiplicidade : uma para cada lado da associao Por exemplo, na conexo entre Pessoa, atuando no papel de professor, e Curso

Para cada instncia de Pessoa, muitos (i.e., zero ou mais) Cursos podem ser ministrados Para cada instncia de Curso, exatamente uma Pessoa o professor
34 Muitos Exatamente Um Zero or mais Um ou Mais Zero or um Intervalo Especfico
* 1 0..* 1..* 0..1 2..4
Indicadores de Multiplicidade Cada lado de uma associao contem um indicador de multiplicidade Indica o nmero de objetos que participam no relacionamento Exemplo: Multiplicidade
Decises de Multiplicidade expem muitas suposies, antes ocultas, sobre o problema sendo modelado Um professor pode estar indisponvel?
Um curso pode ter dois professores?
Qualificadores Um qualificador um atributo de uma classe que pode ser usado para reduzir a multiplicidade da associao
Departamento
EmpregadoID
Professor
1
Restries
Uma restrio expressa alguma condio que deve ser preservada Uma restrio mostrada entre chaves.
9.4. ATIVIDADE
1. Faa um Diagrama de Classes do subsistema de Operao de Trem, sem utilizar herana e considerando o seguinte:

Um trem pode ser de carga, passageiros ou ambos e pode ser movido por um ou mais vages com fora motriz. Um vago com fora motriz possui um determinado tipo de motor, com potncia especfica. O trem de passageiros pode possuir vrias portas por vago, que devem abrir e fechar automaticamente, ao chegar na estao e antes de partir, respectivamente. A capacidade de passageiros de um trem deve estar registrada em quantidade, e a
35

capacidade de cada vago de carga em metros cbicos. Cada trem possui uma rota que deve ser seguida durante a viagem. A data de incio de trabalho de cada vago deve ser registrada. A velocidade do trem deve ser controlada automaticamente. Ao arrancar ele dever estar ganhando velocidade, e ao logo da viagem dever manter outra velocidade e estando a uma determinada distncia da estao dever reduzir a velocidade para parar. Os segmentos de trilho iniciam e terminam em um determinado quilmetro. A localizao do trem numa ferrovia deve ser possvel.
36
AULA 10 AGREGAES E ASSOCIAES

10.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so agregaes entre classes e como us-las. Iremos abordar aspectos como: agregaes, composies, associaes reflexivas, classes de ligao e as diferenas entre associaes e agregaes.
10.2. AGREGAO
Agregao uma forma especializada de associao na qual o todo est relacionado a sua(s) parte(s). Agregao conhecida como parte-de ou relacionamento de contedo. Uma agregao representada como uma associao com um losango perto da classe que denota a agregao (todo). A multiplicidade representada da mesma maneira que nas outras associaes
<<limite>> FormularioDeMatrcula 1
Testes de Agregao

<<limite>> FormularioDeHorrio 1
A frase parte de usada para descrever o relacionamento? Uma Porta parte de um Carro Algumas operaes no todo so automaticamente aplicadas nas partes? Mova o Carro, Mova a Porta Alguns valores de atributos so propagados do todo para algumas ou todas as suas partes? O Carro azul, a Porta azul H uma assimetria intrnseca no relacionamento onde uma classe subordinada a outra? Uma Porta parte de um Carro, um Carro NO parte de uma Porta
Tipos de Agregao Existem dois tipos de agregao: Agregao propriamente dita, ou tambm chamada agregao por referncia Conhecida como relacionamento tem-um(a) Envolve partes componentes que existem independentemente de seus agregados Exemplo: A rea X da empresa tem os empregados A, B e C
Area 1 0..*
Empregado
Visualizando o conceito de agregao, o agregado contm uma referncia aos seus
37
componentes
Composio, ou tambm chamada agregao por valor Conhecida como relacionamento contm um(a) Especifica que as partes componentes s tem um dono Especifica que o composto possui suas partes componentes Especifica que as partes componentes existem, ou vivem e morrem com seu composto proprietrio Exemplo: Um automvel possui de 2 a 5 portas
Automovel 1
Porta 2..5
Visualizando o conceito de composio, o composto contm os seus componentes
Associao ou Agregao ? Se dois objetos so estreitamente ligados por um relacionamento parte-todo O relacionamento uma agregao Se dois objetos so usualmente considerados independentes, mesmo que eles estejam freqentemente ligados O relacionamento uma associao
10.3. ASSOCIAES REFLEXIVAS
Em uma associao reflexiva, objetos de uma mesma classe so relacionados Indica que mltiplos objetos da mesma classe colaboram juntos de algum modo Curso 0..*
Pr-requisito
0..*
Um curso pode ter muitos pr-requisitos Um curso pode ser um pr-requisito para muitos outros cursos Agregados tambm podem ser reflexivos Problema clssico de lista de materiais Isto indica um relacionamento recursivo
ParteDeProduto
0..*
38
Um objeto ParteDeProduto composto de zero ou mais objetos ParteDeProduto
10.4. CLASSES DE LIGAO

Ns desejamos rastrear todas as notas que um estudante teve em todos os cursos que fez O relacionamento entre Estudante e Curso um relacionamento muitos-para-muitos Onde colocamos o atributo nota? Estudante
0..* 3-10
Curso
O atributo nota no pode ser colocado em Curso porque h (potencialmente) muitas ligaes para muitos objetos Estudante O atributo nota no pode ser colocado na classe Estudante porque h (potencialmente) muitas ligaes para muitos objetos Curso Portanto, o atributo realmente pertence a uma ligao particular Estudante-Curso Uma classe de ligao usada para conter a informao da ligao Desenhando Classes de Ligao Crie uma classe de ligao usando um cone de classe Conecte a classe na linha da associao usando uma linha tracejada A classe de ligao pode incluir propriedades mltiplas da associao Apenas uma classe de ligao permitida por associao
Estudante
1..* 3-10
Boletim
Curso
Classes de Ligao e Multiplicidade Classes de Ligao so freqentemente usadas em associaes muitos-para-muitos Se a multiplicidade em um os lados de uma associao para-um O atributo pode ser colocado dentro da classe no lado muitos do relacionamento OU Uma classe de ligao ainda pode ser usada
39
Estudante nota
1 3-10
Curso
Estudante
1 3-10
nota
Curso
10.5. ENCONTRANDO ASSOCIAES E AGREGAES

Associao ou Agregao ? FormularioDeMatrcula e FormularioDeHorario so estreitamente ligados -- uma FormularioDeHorario parte daFormularioDeMatricula
<<limite>>
<<limite>>
FormularioDeMatrcula 1 FormularioDeHorario e GerenteDeMatrcula so independentes 1
FormularioDeHorario 1
1 GerenteDeMatrcula
10.6. ATIVIDADE
Faa um Diagrama de Classes para um problema com as seguintes caractersticas:

Existem medicamentos aprovados para uso clnico, pelo rgo governamental apropriado. Esses medicamentos so fabricados por firmas capacitadas para tanto, que atribuem aos medicamentos um nome de medicamento do fabricante, alm do nome genrico que os mesmos j possuem. Nem todos os medicamentos podem ser fabricados por todas as empresas. A data em que uma empresa foi outorgada para fabricar um medicamento indica o incio da permisso para fabricao. Cada fabricante pode produzir muitos lotes do medicamento, que tem data de fabricao e validade. O modelo deve estar apto a responder por quem um medicamento (ex.: cido acetilsaliclico) foi fabricado, em que lote(s) e com que nmero de permisso.
40
AULA 11 HERANA
11.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so generalizaes entre classes e como us-las. Iremos abordar aspectos como: generalizao, hierarquia, notao, subclasse, superclasse, especializao, e herana mltipla.
11.2. GENERALIZAO

Generalizao define um relacionamento entre classes onde uma classe compartilha a estrutura e/ou comportamento de uma ou mais classes Generalizao define uma hierarquia de abstraes na qual uma subclasse herda de uma ou mais superclasses Com herana simples, a subclasse herda de apenas uma superclasse Com herana mltipla, a subclasse herda de mais de uma superclasse Generalizao um relacionamento " um" ou "tipo de"
Desenhando uma Hierarquia de Herana

InfoRegistroUsurio Superclasse
Relacionamento de Generalizao
InfoEstudante Subclasse
Consideraes sobre generalizao Como um relacionamento de generalizao no se refere a objetos individuais O relacionamento no nomeado Multiplicidade no tem sentido Teoricamente, no h limite no nmero de nveis em uma hierarquia Na prtica, os nveis precisam ser bem limitados Hierarquias tpicas em C++ tem 3 a 5 nveis Hierarquias em Smalltalk podem ser um pouco maiores O que Herdado? Uma subclasse herda de seus pais: Atributos Operaes Relacionamentos Uma subclasse pode: Incluir atributos, operaes e relacionamentos adicionais
41
Redefinir as operaes herdadas (use com cautela!)
Herdando Atributos Atributos so definidos no nvel mais alto da hierarquia de herana na qual eles so aplicveis Subclasses de uma classe herdam todos os atributos Cada subclasse pode adicionar novos atributos
VeculoTerrestre peso nmeroLicena Um caminho tem trs atributos: peso nmeroLicena tonelagem
Carro
Caminho tonelagem
Herdando Operaes Operaes so definidas no nvel mais alto da hierarquia de herana na qual elas so aplicveis Subclasses de uma classe herdam todas as operaes Cada subclasse pode aumentar ou redefinir operaes herdadas Herdando Relacionamentos Relacionamentos tambm so herdados e devem ser definidos no nvel mais alto da hierarquia de herana na qual eles so aplicveis Subclasses de uma classe herdam todos os relacionamentos Cada subclasse pode tambm possuir relacionamentos adicionais Generalizao de Classes Generalizao proporciona a capacidade de criar superclasses que reunem estrutura e/ou comportamento comum a vrias subclasses Procedimento de generalizao Identificar similaridades de estrutura/comportamento entre vrias classes Criar uma superclasse para reunir a estrutura/comportamento comum As classes originais passam a ser subclasses da nova superclasse Superclasses so mais abstratas que suas subclasses Exemplo de Generalizao
42
Bens
ContaBancria
Seguro
Imveis
Poupana
ContaCorrente
Aes
Bnus
Especializao de Classes A especializao proporciona a capacidade de criar subclasses que representam refinamentos nos quais a estrutura e/ou comportamento da superclasse so adicionados ou modificados Procedimento de Especializao Notar que algumas instncias apresentam estrutura ou comportamento especializado Criar subclasses para agrupar instncias de acordo com sua especializao Subclasses so menos abstratas que suas superclasses Hierarquias de Herana Tanto generalizao quanto especializao so usadas no desenvolvimento de uma hierarquia de herana Durante a anlise, so estabelecidas hierarquias de herana entre abstraes chaves (i.e., classes) se necessrio Durante o projeto, as hierarquias de herana so refinadas para: Aumentar reutilizao Incorporar classes de implementao Incorporar bibliotecas de classes disponveis
11.3. HERANA MLTIPLA

CoisaQueVoa herana mltipla Animal
Avio
Helicptero
Pssaro
Lobo
Cavalo
Conceitos de Herana Mltipla

Conceitualmente necessrio para modelar o mundo real de forma precisa Na prtica, isto pode gerar dificuldades na implementao Nem todas as linguagens de programao orientadas a objetos suportam herana mltipla diretamente
43
Cada ambiente/linguagem de programao escolhe maneiras de resolver estas dificuldades Encontrando generalizao importante avaliar todas as classes para encontrar possveis generalizaes Procure por comportamento comum (operaes) e estado comum (atributos) nas classes Tcnica de adio Adicione novas operaes/atributos na(s) subclasse(s) Tcnica de modificao Redefina operaes Deve ser feito com cuidado para no alterar a semntica Generalizao versus Agregao Generalizao e agregao so geralmente confundidas Generalizao representa um relacionamento "-um" ou "tipo-de" Agregao representa um relacionamento "tem-um"
Generalizao Palavra chave um Agregao Palavra chave tem um
Relaciona objetos da mesma superclasse Representado por uma seta
Relaciona objetos de classes diferentes
Representado por um losango
11.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de publicaes em uma biblioteca, considerando o seguinte:

A biblioteca pertence a uma empresa e somente os funcionrios da empresa esto aptos a reservar ou emprestar publicaes. A biblioteca tem acesso aos dados cadastrais dos funcionrios. Uma publicao pode ser um livro, uma revista, um jornal, etc. A biblioteca pode possuir vrios exemplares de uma mesma publicao. Qualquer tipo de publicao pode ser emprestada ou reservada. No h nmero limite de reservas por publicao. Quando uma publicao for devolvida e para ela existirem reservas, o primeiro da fila deve ser avisado. A reserva expira um dia aps o aviso da disponibilidade da publicao ao interessado. Caso o mesmo no venha a emprestar a publicao, ela ser considerada disponvel e o prximo da fila deve ser avisado. Uma reserva pode ser excluda a pedido do usurio. Emprstimos de publicaes no devolvidas 2 dias aps o prazo sero consideradas irregulares e um funcionrio da biblioteca deve resgatar o livro.
44
AULA 12 INTERFACES E PACOTES

12.1. APRESENTAO
Nesta aula iremos abordar e exercitar o que so Intefaces e pacotes.
12.2. INTERFACES
Uma Interface uma coleo de operaes utilizadas para especificar um servio de uma classe ou componente. As interfaces so empregadas para visualizar, especificar, construir e documentar a coeso interna do sistema. Escolhendo as interfaces corretas, voc pode selecionar componentes padro, bibliotecas e frameworks para a implementao destas interfaces, sem precisar constru-las. medida que descobrir implementaes melhores, voc pode substituir as antigas sem perturbar seus usurios Declarando a interface, voc pode estabelecer o comportamento desejado de uma abstrao independente de qualquer implementao desta interface. Notao:
Relacionamentos:
A relao entre Alvo e Observador uma relao de dependncia, enquanto que a relao entre Observador e Rastreador uma relao de realizao. Uma relao de realizao indica que a classe Rastreador implementa a interface Observador.
45
12.3. PACOTES
Se um sistema contm somente poucas classes, voc pode gerenci-las facilmente. Mas, a maioria dos sistemas so compostos por muitas classes, neste caso ento necessrio um mecanismo para agrupa-las, para obter uma melhor facilidade de uso, manuteno e reutilizao. Neste caso onde o conceito de packages til. Um package na viso lgica de um modelo uma coleo de packages e/ou classes relacionados. Agrupando classes em packages, ns podemos ter uma viso de mais alto nvel do modelo (i.e., os packages), ou podemos nos aprofundar no modelo, dando uma olhada no que est contido no package. Cada package contm uma interface que implementada por um conjunto de classes pblicas - aquelas classes com as quais os outros packages falam. O resto das classes em um package so classes de implementao - classes, que no se comunicam com as classes de outros packages. Se um sistema complexo, packages podem ser criados logo no incio da Fase de Elaborao para facilitar a comunicao. Para sistemas simples, as classes descobertas na anlise podem ser agrupadas em um package - o prprio sistema. No decorrer do processo de anlise e projeto, o conceito de package ser utilizado para agrupar as classes que so necessrias para realizar as decises arquiteturais tomadas para o sistema. Na UML, packages so representados como pastas. Criando Packages O prximo passo agrupar as classes em packages. Neste ponto, ns temos identificadas seis classes: Curso, OfertaCurso, InformaoProfessor, OpesCursoProfessor, AdicionaOfertaCurso e ControleCursoProfessor. Elas caem em trs grupos lgicos - coisas nicas para a universidade, coisas que contm informaes sobre pessoas e coisas que so parte das interfaces com os atores. Ns podemos identificar os packages: Interfaces, ServicoUniversidade e InformacaoPessoa. As classes so realocadas para os packages identificados. Os packages com suas classes so mostrados abaixo. O principal diagrama de classes na viso lgica do modelo normalmente uma figura dos packages do sistema. Cada package tambm tem o seu prprio diagrama principal, o qual normalmente mostra as classes pblicas do package. Outros diagramas podem ser criados de acordo com a necessidade. Alguns dos usos tpicos de outros diagramas so: Viso de todas as classes de implementao do package; Viso da estrutura e comportamento de uma ou mais classes; Viso da hierarquia de herana. Um exemplo do diagrama de classe principal do sistema de matrcula mostrado na figura abaixo.
46
O diagrama de classe principal (Main) para o package ServicoUniversidade mostrado na figura. Note que a classe OfertaCurso no est no diagrama. Esta uma classe de implementao e foi decidido no mostr-la no diagrama principal do package.
Quando mais packages e classes so adicionados ao modelo, diagramas adicionais podem ser criados quando necessrios. Um package na viso lgica do modelo uma coleo packages e/ou classes relacionadas. Agrupando classes em packages, ns podemos olhar ao mais alto nvel de viso do modelo (i.e., os packages), ou ns podemos ir fundo no modelo olhando o que est contido dentro dos packages. Relacionamentos entre Pacotes Pacotes so relacionados entre si usando um relacionamento de dependncia Se uma classe em um pacote conversa com uma classe em outro pacote ento um relacionamento de dependncia adicionado ao nvel de pacote Diagramas de Cenrio e diagramas de classe so avaliados para determinar relacionamentos entre pacotes
47
Interfaces Controle
Artefatos Universitrios
12.4. ATIVIDADE
Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de publicaes em uma biblioteca, considerando o seguinte:

48
AULA 13 MODELO DE CLASSES, IMPLEMENTAO E MODELO RELACIONAL

13.1. APRESENTAO
Nesta aula iremos abordar e exercitar que o modelo de classes tem com a codificao em java e com o modelo relacional.
13.2. MAPEANDO DIAGRAMAS DE CLASSE PARA CDIGO EM JAVA

Implementar um sistema baseado em um modelo, depende primeiro do paradigma usado na construo do modelo e no paradigma da linguagem escolhida para o desenvolvimento. possvel construir um sistema a partir de um modelo orientado a objetos usando uma linguagem estruturada e vice-versa. Mas, para isso teremos que fazer diversas adaptaes. No nosso caso iremos apresentar a implementao usando a linguagem Java. Implementando classes simples:
Este o cdigo em java para a classe descrita pelo diagrama acima.

class Produto { private String nome; private String descricao; protected double preco; public void setNome(String umNome) {} public String getNome() {return null;} static public Vector getAll() {return null;} }
Implementando associaes: Para implementar uma associao precisamos colocar um atributo de referncia. Em qual classe ser colocado este atributo, depende da multiplicidade da associao. Estes atributos ou classes que so criados para este fim no devem ser colocados no diagrama de classes. No caso 1 para muitos podemos colocar todo o objeto com multiplicidade 1 como atributo do objeto com multiplicidade muitos:
49
public class ItemdePedido { private int quantidade; private EspecificacaoProduto produto; }
ou, se o objeto tiver um cdigo gerado automaticamente na base de dados, apenas o cdigo do objeto com multiplicidade 1 como atributo do objeto com multiplicidade muitos:
public class ItemDePedido { private int quantidade; private int codProduto; }
No caso de muitos para muitos:
Existe a necessidade da criao de uma classe para a associao:

public class Matricula { private Aluno aluno; private Turma turma; }
Agregaes:
Uma agregao pode ser implementada usando um objeto para colees do Java como java.util.Vector. Este objeto colocado como atributo da classe que agrega e contm objetos da classe agregada;
public class Pedido { private Date data; private String codPedido; private boolean completo;
50
private Vector todosItens; }
13.3. MAPEANDO CLASSES PARA MODELO RELACIONAL

Associao 1:N Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe respectiva tabela. A figura abaixo ilustra a situao tratada: Associao M:N Define-se uma tabela por classe acrescentando-se os atributos identificadores de cada classe respectiva tabela. Neste caso, necessria a criao de uma tabela auxiliar para indicar as associaes entre os objetos. A figura abaixo ilustra a situao tratada:
Associao muitos para muitos
Associao um para muitos Herana Identificam-se quatro formas para o mapeamento das heranas. So elas:
51
Uma tabela por classe Uma nica tabela
Uso de tabelas apenas para classes especficas
Mista
52
13.4. ATIVIDADE
1) Construa um Diagrama de Classes inicial para controlar emprstimos e reservas de publicaes em uma biblioteca, considerando o seguinte:

2) Crie o cdigo Java para trs das classes identificadas acima, que possuas relacionamento. 3) Crie o script SQL de criao dessas 3 classes.
53
AULA 14 DIAGRAMAS DE INTERAO

14.1. APRESENTAO
Nesta aula vamos apresentar os diagramas de seqncia e comunicao
14.2. DIAGRAMAS DE INTERAO

Os diagramas de Interao, compostos por: Diagramas de Seqncia e Diagramas de Comunicao. DIAGRAMA DE SEQNCIA:

O prximo passo identificar os objetos envolvidos nele, formando assim diagramas de seqncia. Mostra como os objetos se interagem atravs do tempo em um determinado cenrio. As linhas verticais so objetos e no classes. Podem existir eventos simultneos. Podem existir eventos reflexivos.
PASSOS: 1. 2. 3. 4. Identifique os "principais objetivos do seu sistema". Descreva o cenrio. Identifique os objeto origem e o objeto destino. Construa o Diagrama.
Exemplo de um diagrama seqncia na UML:

sd exemplo01 :IntUsuario Usuario Cliente:= mostraTelaCadCliente() formulrio cliente dados Cliente setNome(nome) setCNPJ(cnpj) :CtrlCadCliente :Cliente
Os diagramas de seqncia podem representar vrios aspectos da interao entre 2 objetos: a) Dois tipos de mensagens: mensagens sncronas (esperam um retorno): chamadas de mtodo; chamadas de criao de objetos; chamadas de destruio de objetos.
54
retorno de mensagem;
mensagens assncronas (no esperam um retorno) b)Comandos de deciso (if, if else): podem ser representados na mensagem ou atravs de um fragmento combinado (UML 2.0)
sd exemplo04 :ClasseA :ClasseB :ClasseC
numero:= verificaNome(nome) [numero = 0]: codigoNulo:= geracodigoNulo() alt [numero <= 3] [numero >3] setNome(nome)
codigo:= calculaCodigo(nome)
nome:= getNome()
c) Repeties (loops): representados direto na mensagem ou atravs de fragmentos combinados (UML 2.0) d) Chamadas a outros diagramas de seqncia (UML 2.0)
sd exemplo05 :CtrlPedido :TicketBD :Conta
criar ( )
:Pedido
recuperar status de cliente existente
loop [proximo item]
reservar(contagem,date)
alt [disponvel]
adicionar(assentos)
[no disponvel]
rejeitar() debitar(custo)
Alguns aspectos dependentes da linguagem para expressar a mensagem, podem ser
55
omitidos na fase de anlise. e)Podemos especificar objetos que so criados em tempo de execuo do sistema. f) Podemos tambm expressar mensagens reflexivas. g) Tambm podemos expressar noo de tempo de transmisso de mensagem. DIAGRAMA DE COMUNICAO: - Vieram a substituir os diagramas de colaborao na UML 2.0 - Mesmo comportamento do diagrama de rastreamento de eventos, porm com uma outra viso. - Algumas ferramentas CASE fazem a transformao automtica. - a mesma coisa "escrita" de outra forma.
14.3. ATIVIDADE
construa o diagrama de seqncia para os seguintes enunciados: 2.2. Fluxo de Eventos 2.2.1. Fluxo bsico 1. O caso de uso comea quando o funcionrio seleciona a opo manter dados do ponto. O sistema mostra uma lista com os ltimos registro de ponto e as opes "alterar " e "inserir". 2. Se o funcionrio seleciona a opo "incluir", o sub-fluxo incluir ponto executado; Se o funcionrio seleciona a opo "alterar", o sub-fluxo alterar ponto executado; 2.2.2. Subfluxo inserir ponto 1. O sistema mostra uma tela com os campos do ponto, que so: "hora de incio", "hora de trmino", "data", "nmero do projeto". 2. O funcionrio preenche os campos. O sistema mostra os dados preenchidos e pede confirmao 3. O funcionrio confirma a incluso. O sistema mostra uma mensagem de sucesso. 2.2.3. Subfluxo alterar ponto 1. O sistema mostra uma lista com os ltimos registro de ponto. 2. O funcionrio seleciona o ponto a ser alterado. O sistema mostra uma tela com os dados do ponto, que so: "hora de incio", "hora de trmino", "data", "nmero do projeto". 3. O funcionrio altera os dados necessrios. O sistema mostra os dados alterados e pede confirmao 4. O funcionrio confirma a alterao. O sistema mostra uma mensagem de sucesso.
56
AULA 15 DIAGRAMAS DE SEQNCIA

15.1. APRESENTAO
Construindo e implementando diagramas de sequncia em java com jsp e servlet de controle
15.2. DESENVOLVIMENTO
Dicas para a identificao de classes que participam do caso de uso:

Para cada ator que participa do caso de uso, identifique pelo menos uma classe <<limite>>; Para cada caso de uso identifique uma classes <<controle>>; Para cada grupo de informaes manipulado no caso de uso, identifique uma classe <<entidade>>.
Para o caso de uso cadastrar produto identificamos as seguintes classes: <<limite>> IntAdministrador Repositorio <<controle>> CtlrCadastrarProduto <<entidade>> Produto
Agora vamos desenhar o diagrama com base nos eventos. 2.2. Fluxo de Eventos 2.2.1. Fluxo bsico 1. O caso de uso comea quando o administrador seleciona a opo cadastrar produto. O sistema mostra um formulrio com os campos para os dados do produto.
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
3. O Administrador seleciona confirmar. O sistema grava as informaes do produto na base e mostra

uma tela confirmando o sucesso da operao. Primeiro vamos colocar as instncias (objetos) das classes identificadas acima no diagrama:
limite :IntAdministrador controle :CtrlCadastrarProduto entidade :Produto limite :Repositorio
:Administrador
:SGBD
Agora vamos colocar as mensagens relativas ao primeiro evento do fluxo bsico:
57
1. O caso de uso comea quando o administrador seleciona a opo cadastrar produto. O sistema mostra um formulrio com os campos para os dados do produto.
:Administrador
limite :IntAdministrador
controle :CtrlCadastrarProduto
entidade :Produto
limite :Repositorio
:SGBD
opcao:= mostraMenu() menu cadastrar produto produto:= telaCadastroProduto() tela cadastro produto
Agora vamos colocar as mensagens relativas ao segundo evento do fluxo bsico:
2. O Administrador preenche os dados do produto e seleciona a opo gravar produto. O sistema mostra
uma tela com os dados preenchidos do produto e pede confirmao;
:Administrador
:SGBD
opcao:= mostraMenu() menu cadastrar produto produto:= telaCadastroProduto() tela cadastro produto dados do produto setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto) dados do produto dadosProduto:= getDados()
Agora vamos colocar as mensagens relativas ao segundo evento do fluxo bsico: 3. O Administrador seleciona confirmar. O sistema grava as informaes do produto na base e mostra uma tela confirmando o sucesso da operao.
58
:Administrador
:SGBD
opcao:= mostraMenu() menu cadastrar produto produto:= telaCadastroProduto() tela cadastro produto dados do produto setDados(valor,codigo,descricao,nome)
confirmacao:= pedeConfirmacao(produto) dados do produto confirmacao gravou:= gravaProduto(produto) dadosProduto:= getDados() alt [gravou] mostraMensagem(mensagemSucesso) Produto gravado insere dados dadosProduto:= getDados()
15.3. ATIVIDADE
1. Construa o digrama de seqncia, e implemente o caso de uso alterar Produto para o mesmo sistema.
59
AULA 16 DIAGRAMAS DE ESTADOS

16.1. APRESENTAO
Vimos e estudamos os diagramas de casos de uso, diagramas de classes e diagramas de interao. Em continuao vamos apresentar, a partir desta aula, os diagramas de estados.
16.2. DIAGRAMAS DE ESTADOS:

So diagramas que representam os estados que um objeto pode assumir e as mudanas de um estado para outro. So compostos basicamente por: Estados e Transies: Estados: Condio ou situao na vida do objeto Notao:
Um Estado pode ter: aes de entrada/saida transies internas subestados Transies Representam a mudana de um estado para outro
As transies podem ter: Estado Origem
60

Estado Destino Evento Condies de proteo Aes
Exemplo: Um diagrama que representa os estados de um pedido em uma empresa que fabrica itens sob medida. O pedido aberto. Uma vez efetuada a venda, o pedido passa a para a produo. Terminada a produo, o pedido passa para a entrega e, uma vez entregue ele concludo. O pedido s pode ser cancelado enquanto est aberto ou em produo.
Subestados:
61
16.3. ATIVIDADE
1) Fazer um diagrama de estados para representar os diferentes estados de um funcionrio em uma empresa. 2) Fazer um diagrama de estado para representar os diferentes estados de uma fita de vdeo em uma vdeo-locadora.
62
AULA 17 DIAGRAMAS DE COMPONENTES E DE IMPLANTAO

17.1. APRESENTAO
Diagramas de componentes e de Implantao
17.2. DIAGRAMAS DE COMPONENTES

Mostram as dependncias entre os componentes do sistema. Componentes: "Arquivos" que o sistema necessita para funcionar. Notao:
As dependencias entre os arquivos so representadas como no exemplo:
Os componentes podem ser arquivos de propriedades, arquivos fonte, arquivos html, jsp e at mesmo bibliotecas que precisam ser instaladas.
63
17.3. DIAGRAMAS DE IMPLANTAO

So diagramas que representam a arquitetura de hardware e software do sistema Ns: representam as mquinas e o software que roda em cada uma Notao:
Ligaes: representam as conexes fsicas entre as mquinas:
64
Exemplo:
17.4. ATIVIDADE
Faa um diagrama de implantao para o problema do sistema de Matrculas
65
BIBLIOGRAFIA BSICA
BECK, K; CUNNINGHAM, W.. A laboratory for teaching Object-Oriented thinking. Anais do International Conference on Object-Oriented Programming, Systems, Languages and Applications OOPLSA89. New Orleans, EUA: 1989. BEZZERRA, E.. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro, Brasil: Campus, 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.. The Unified Modeling Language user guide. 2a. ed.Westford, Massachusets, EUA: Addison-Wesley, 2005. JACOBSON, I.; BOOCH, G.; RUMBAUGH, J.. The Unified Software Development Process. Reading, Massachusetts, EUA: Addison-Wesley, 1999. LARMAN, C.. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3a. ed. New Jersey, EUA: Addison-Wesley Professional, 2004. OMG. Unified Modeling Language - Superstructure specification Verso 2.0. OBJECT MANAGEMENT GROUP: Nedham, Massachusets, EUA, 2005 PRESSMAN, R. S.. Software Engineering: a practitioner's approach. 6a. ed .New York, EUA: McGraw-Hill, 2005. RUMBAUGH, J.; JACOBSON, I.; BOOCH, G.. The unified modeling language reference manual. 2a. ed. Reading, Massachusetts, EUA: Addison-Wesley, 2004.

Apostila UML-UFPR PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila UML-UFPR PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila UML-UFPR PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Andrey Ricardo Pimentel

Projeto de Software Usando a UML

4 17.5. BIBLIOGRAFIA BSICA..............................................................................................64

AULA 1 PROCESSO DE SOFTWARE

1.4. CRISE DO SOFTWARE

1.5. PROCESSO E NOTAO

1.6. O PODER DA TECNOLOGIA DE OBJETOS

1.7. ANLISE E PROJETO

1.8. DESENVOLVIMENTO ITERATIVO E INCREMENTAL

1.9. PROCESSO UNIFICADO

Concepo (define o escopo do projeto) Elaborao (define os requisitos e a arquitetura)

Construo (desenvolve o sistema) Transio (implanta o sistema)

AULA 2 LEVANTAMENTO DE REQUISITOS

2.2. LEVANTAMENTO DE REQUISITOS

AULA 3 CASOS DE USO

3.2. COMPORTAMENTO DO SISTEMA

3.4. CASOS DE USO

3.5. DIAGRAMAS DE CASO DE USO

O ator estudante precisa usar o sistema para registrar-se em cursos

AULA 4 ESPECIFICAO DE CASOS DE USO

4.2. A ESPECIFICAO DE UM CASO DE USO

AULA 5 RELACIONAMENTOS ENTRE CASOS DE USO

5.2. RELACIONAMENTOS ENTRE CASOS DE USO

5.3. RELACIONAMENTO <<INCLUDE>>

Figura relacionamento <<include>>

5.4. RELACIONAMENTO <<EXTEND>>

AULA 6 IDENTIFICAO DE CLASSES USANDO O MVC

6.2. DESCOBRINDO CLASSES

6.3. CLASSES ENTIDADE

6.4. CLASSES LIMITE

6.5. CLASSES CONTROLE

6.6. OBJETOS E CLASSES NO PROBLEMA DO SISTEMA DE MATRCULA (MATRI)

AULA 7 IDENTIFICAO DAS RESPONSABILIDADES DAS CLASSES

7.2. CARTES CRC

AULA 8 IDENTIFICAO DE ATRIBUTOS E OPERAES DE UMA CLASSE

8.2. O QUE UMA OPERAO?

Operaes Dependem do Domnio

Perspectiva do Bancrio receber emprstimo anexar conta receber linhaDeCrdito

Perspectiva do Mdico examinar tomarRemdio irParaHospital receberConta

Descobrindo Operaes nos Diagramas de Interao

8.3. O QUE UM ATRIBUTO?

Atributos so mostrados no segundo compartimento da classe

nmeroConta nomeBanco nomeProprietrio saldo geraTransao

Corrigir um erro (bug) Aumentar performance Refletir uma mudana no plano de ao

AULA 9 ASSOCIAES ENTRE CLASSES

Associaes mltiplas devem ser questionadas

9.3. MULTIPLICIDADE PARA ASSOCIAES

34 Muitos Exatamente Um Zero or mais Um ou Mais Zero or um Intervalo Especfico

* 1 0..* 1..* 0..1 2..4

Um curso pode ter dois professores?

AULA 10 AGREGAES E ASSOCIAES

Visualizando o conceito de agregao, o agregado contm uma referncia aos seus

Visualizando o conceito de composio, o composto contm os seus componentes

10.3. ASSOCIAES REFLEXIVAS

10.4. CLASSES DE LIGAO

10.5. ENCONTRANDO ASSOCIAES E AGREGAES

FormularioDeMatrcula 1 FormularioDeHorario e GerenteDeMatrcula so independentes 1

Desenhando uma Hierarquia de Herana

Redefinir as operaes herdadas (use com cautela!)