UML UML apresentada como um conjunto de diagramas com suas finalidades, porm sem nenhuma ligao ou seqncia definida

a pela linguagem, o que no orienta o processo de desenvolvimento. O desenvolvimento orientado a objetos, que se apresenta de forma mais natural, onde as responsabilidades so divididas entre objetos que se relacionam e se comunicam. Exemplo: Agncia bancria. Em um sistema orientado a objetos, o cliente teria alm dos dados (nome, CPF, endereo, etc.) operaes como: retirar dinheiro, pagar conta, depositar dinheiro, etc., que so tpicas de um cliente. J o caixa, alm dos dados, realizaria operaes como: fazer pagamento, verificar saldo, etc. E cliente teria um relacionamento com o caixa da agncia para executar as operaes. Caso quisssemos criar, por exemplo, um cliente especial, deveramos atualizar somente o cliente e no seria necessrio alterar todo o programa, ou seja, as informaes esto isoladas em cada parte. 1. Classe, objetos e Instncia Classe representa um conjunto de objetos com caractersticas similares. Objeto uma instanciao da classe, ou seja, um objeto o que existe, de fato, enquanto a classe um conceito abstrato. 2. Atributos e operaes Atributos onde so armazenados os dados do objeto. Operaes (mtodos) o conjunto de objetos. Representao da classe 1 2 3 (1)NOME DA CLASSE (2)ATRIBUTOS (3)MTODOS

3. Relacionamento 3.1. Herana: a classe filha (vaca) herda os atributos da classe me.

3.2.

Agregao, composio e dependncia

Composio ocorre quando uma classe composta por outra, de tal forma que a parte que compe no existe, se no existir o todo,ou seja, a parte no vive sem o todo.

Agregao semelhante a composio, porm a parte vive sem o todo, ou seja, se no existir o todo, a parte continuar existindo. Exemplo:

Dependncia quando uma classe depende da outra, porm isso ocorre esporadicamente durante a vida dos objetos. o exemplo da vaca e da vacina que ela recebe do veterinrio. Existe um relacionamento de dependncia entre a vaca e a vacina.

3.3. Multiplicidade No relacionamento entre duas classes existe uma determinada multiplicidade, que dever atender aos requisitos do sistema.

4. Polimorfismo a propriedade que indica que uma operao pode, apesar de ter o mesmo nome, executar aes diferentes. Existem dois tipos de polimorfismo: o esttico e o dinmico.

4.1. Polimorfismo esttico

Ao chamar a operao ajustaData, a operao exata que ir ser executada depender dos parmetros que sero passados. A vantagem desse uso que a classe pode atender a vrios usurios da classe e cada um pode enxerg-la de maneira diferente. 4.2. Polimorfismo Dinmico

A classe FormaGeomtrica possui uma operao chamada Desenhar, porm, como desenhar uma forma geomtrica se no sabemos exatamente como ela ? Esta operao chamada de operao abstrata (o que faz com que a classe FormaGeomtrica seja chamada de classe abstrata), ou seja, serve como referncia, porm no implementada; a implementao desse mtodo fica a cargo da classe filha (Retngulo e Crculo). 5. Capturando requisitos A meta da modelagem desenvolver o diagrama de classes do projeto, ou seja, desenvolver toda a modelagem onde ser desenvolvido o cdigo que executar as funes do sistema. O diagrama de classes do projeto composto pelas classes com seus atributos e operaes e pelos relacionamentos entre elas. 5.1. Como capturar os requisitos? Requisito o nome dado a todo tipo de necessidade que se identifica para um sistema e normalmente obtido atravs de entrevistas com clientes ou algum que conhea a necessidade dos usurios. A obteno dos requisitos no uma tarefa trivial, uma vez que quem os fornecer muitas vezes no sabe exatamente como o sistema dever funcionar, ou seja, sabe qual o problema, mas no tem idia de como a soluo e por essas e outras razes que se deve dedicar uma ateno muito grande para obter os requisitos. , normalmente, durante a obteno de requisitos que os responsveis pelo desenvolvimento interagem com os problemas e necessidades do cliente e acabam conhecendo e aprendendo sobre o negcio no que o sistema est envolvido, o que fundamental. No se deve deixar nenhum tipo de requisito de fora do levantamento, por mais que parea

impossvel de realiz-lo no momento. Esta avaliao deve ser feita em outro momento e nestes casos deve ser negociado para que estes requisitos se transformem em requisitos futuros, obvio que isto s possvel, caso estes requisitos no sejam prioritrios. Nesses casos, deve-se deixar claro que este requisito ter um impacto muito grande no desenvolvimento do projeto, devendo ter grande influncia no prazo de entrega do sistema. Uma forma de facilitar a especificao de requisitos dividi-los nos seguintes tipos: - Requisito funcional: Um requisito que especifica uma ao que o sistema dever ser capaz de realizar, sem levar em considerao restries fsicas como, por exemplo, um requisito que especifica o comportamento das entradas e sadas do sistema. - Requisito no-funcional: pode incluir requisitos legais ou referentes a algum regulamento, a aplicao de padres e tambm os atributos de qualidade do sistema a ser construdo. Adicionalmente, outros requisitos, tais como: o sistema operacional a ser utilizado, requisitos de compatibilidade e restries de projeto, tambm devero ser capturados nesse item. 5.2. Os riscos e prioridades associados a requisitos Uma atividade muito importante na especificao de requisitos determinar qual prioridade o cliente associa a cada um dos requisitos levantados. Em geral o cliente tem a tendncia de dizer que todos os requisitos so de altssima prioridade, porm isto nem sempre verdade. No se pode dizer sim a tudo que o cliente pede, deve-se ser bastante claro ao mostrar as dificuldades de se desenvolver um sistema. As prioridades iro facilitar na conduo do projeto e na determinao de quais atividades sero realizadas e a que tempo. Os nveis de prioridade devem ser divididos da seguinte forma: Altssima Alta Mdia Baixa Baixssima A determinao do conjunto Prioridade/Risco ir orientar o desenvolvimento, ou seja, assim que possvel deve-se baixar o nvel dos riscos associados aos requisitos de maior prioridade. Um das maneiras de se fazer isto o desenvolvimento de prottipos que possam permitir que o risco seja reduzido ou negociar com o cliente uma nova forma de atender ao requisito. importante que isto ocorra durante o incio do projeto, de modo que todos os riscos estejam no nvel baixo ou baixssimo antes da fase de construo. Deve-se ter em mente que o sucesso do projeto se baseia em levantar e especificar, da forma mais precisa possvel, os requisitos e, em seguida, determinar uma estratgia que permita no prazo mais curto possvel reduzir o nvel dos riscos associados aos requisitos. Considerando um sistema que atender um caixa de um banco podemos citar como requisito: 1) Sacar dinheiro O sistema dever permitir que o usurio saque dinheiro do caixa eletrnico. Esta atividade responsvel pelo ciclo que se inicia quando o usurio solicita o saque de dinheiro e se encerra, no fluxo timo, quando o usurio recebe em dinheiro o valor solicitado e o documento de comprovao de saque. Descrio do risco A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio. Risco Altssimo Prioridade Altssima

2) Movimentar valores entre contas O sistema dever permitir movimentar valores entre contas do mesmo usurio. Descrio do risco Risco A implementao depende da definio da forma de Altssimo comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio.

Prioridade Altssima

5.3. Gerenciamento de requisitos O gerenciamento de requisitos uma atividade que permite monitorar as necessidades apresentadas pelo cliente e o andamento da soluo destas necessidades do ponto de vista de projeto. impossvel congelar os requisitos do cliente, uma vez que cada passo e conforme o sistema vai sendo construdo vai tambm se tornando mais claro como o sistema deve funcionar e que caractersticas tecnolgicas o sistema deve ter. Assim, o cliente vai sentindo a necessidade de novos recursos a serem implementados. 5.4. Como transformar requisitos em casos de uso Uma vez especificados os requisitos inicia-se o processo de especificao dos casos de uso que foi introduzido por Ivar Jacobson e que veremos com mais detalhes a seguir. Atores Um ator qualquer pessoa ou sistema externo (SE) que tenha interao com o sistema que est em desenvolvimento.

A identificao dos atores o primeiro passo para a criao dos casos de uso, pois o ator representa uma classe fora do sistema que se envolve de alguma forma com o mesmo. O uso do conceito classe importante porque o ator no um objeto, ou seja, no uma pessoa ou sistema externo em particular que ir utilizar o sistema, sim o papel que essa pessoa (ou sistema externo) especifica ou conjunto de pessoas representam para o sistema. Um ator pode ser representados atravs de um diagrama de especializao (ou generalizao) como utilizamos com classes. Neste exemplo, estamos identificando alguns dos possveis atores do caixa eletrnico de banco. Um ator o cliente do banco, porm temos neste caso trs tipos diferentes de atores que derivam do ator genrico cliente do banco. So eles: Cliente VIP Cliente Especial Cliente Padro Estes clientes possuem papis comuns, porm em funo da forma de atendimento, existem caractersticas que so especficas para cada tipo de cliente do banco e, por conseqncia, do caixa eletrnico.

O primeiro passo para a identificao de atores realizado entre o analista e o cliente, que identificam os usurios e os organizam em categorias (classes) de atores. Dois critrios so importantes para identificar um ator: Deve ser possvel identificar pelo menos um usurio que represente o ator candidato, pois

isso ajuda a encontrar somente os atores relevantes e ignorar os atores imaginrios. Deve existir um mnimo de sobreposio de papis entre os diferentes atores que se relacionam com o sistema. No devem existir dois atores com papis semelhantes em relao ao sistema. Se isto ocorrer, devemos combin-los em um ator ou tentar utilizar a generalizao. 6. Caso de uso Pode ser definido como um conjunto de funcionalidades de um sistema, representado por fluxos de eventos iniciados por um ator e apresentado um resultado de valor a um ator. Aps identificarmos os atores do sistema, devemos iniciar a identificao dos casos de uso, de modo a transformar os requisitos do sistema passados pelo cliente em algo que possa ser entendido pelo desenvolvedor. Esta passagem representa o elo entre o processo de desenvolvimento e as necessidades do cliente. A identificao dos casos de uso com base nos requisitos no uma tarefa trivial, uma vez que cada sistema necessariamente diferente do outro, porm representa um avano do ponto de vista do processo de desenvolvimento. Como o processo de desenvolvimento incremental, ou seja, o analista ter a oportunidade de passar outras vezes por este trabalho, e existe sempre a possibilidade de correo e maior detalhamento dos casos de uso. Para identificarmos um caso de uso, devemos seguir os passos: 1) Analisar e agrupar todos os requisitos do ponto de vista das funcionalidades (requisitos funcionais) do sistema a ser desenvolvido. 2) Uma vez agrupados, determinar quais atores interagem com este caso de uso. 3) Descrever o fluxo timo para este caso de uso, ou seja, o fluxo onde nada de errado acontece e a entrada do ator levar ao resultado sem erros ou problemas. 4) Descrever os fluxos alternativos para este caso de uso, ou seja, quando e onde algo pode dar errado. 5) Partes de um caso de uso podem aparecer em outros casos de uso. Por exemplo, o caso de uso para identificar o login do usurio analisando nome e senha. Desta forma importante dividir o caso de uso em partes para no repetir a descrio. Existem trs tipos de relacionamentos entre os casos de uso, que so: a. Herana: Os casos de uso podem herdar o comportamento do caso de uso do qual deriva. b. Incluso: o caso de uso que includo sempre executado, ou seja, o fluxo de eventos deste caso de uso sempre acessado. c. Extenso: o caso de uso estende o comportamento do caso de uso, sendo que o fluxo de eventos do caso de uso pode ser ou no acessado. Considerando os atores do caixa eletrnico, sabemos que um caso de uso Sacar dinheiro, portanto podemos descrev-la da seguinte forma: Caso de Uso Sacar dinheiro Descrio: Este caso de uso responsvel pelo ciclo que se inicia quando o usurio solicita ao caixa eletrnico o saque do dinheiro e se encerra, no fluxo timo, quando o usurio recebe o dinheiro e o documento comprovante de saque. Pr-condio: o usurio solicitar o saque de dinheiro Ps-condio: o usurio recebe o dinheiro solicitado Fluxo timo 1. O usurio solicita o saque de dinheiro. 2. O terminal pede que ele passe o carto. 3. O usurio passa o carto solicitado pelo terminal. 4. O terminal l os dados do carto. 5. O terminal verifica se o carto vlido. 6. O terminal solicita a senha. 7. A senha digitada pelo usurio. 8. O terminal avalia a senha. 9. O terminal solicita que o usurio informe a quantia a ser sacada.

10. Usurio digita a quantia a ser sacada. 11. verificada a conta do usurio para saber se a mesma tem saldo para tal saque. 12. Terminal imprime recibo de saque. 13. Terminal libera o valor solicitado. 14. O sistema volta para o estado inicial para a execuo de outros servios para o mesmo ou para outros usurios. Fluxos alternativos Carto invlido ou passado de forma incorreta pelo leitor. 1- O usurio passa o carto solicitado pelo terminal. 2- O terminal l os dados do carto. 3- O terminal verifica se o carto vlido. 4- O terminal determina que o carto invlido. 5- O terminal solicita que o usurio passe o carto novamente. 6- Retorna ao passo 3 do fluxo timo. Senha incorreta 1- A senha digitada pelo usurio. 2- O terminal avalia a senha. 3- O terminal verifica que a senha no vlida e solicita que o usurio digite novamente a senha. 4- Retorna ao passo 7 do fluxo timo e aps terceira tentativa, o sistema informa que no poder mais executar qualquer operao com o carto at que comparea em uma agencia bancria para realizar o desbloqueio. Saldo insuficiente 1- Usurio digita a quantia a ser sacada. 2- verificada a conta do usurio para saber se a mesma tem saldo para tal saque. 3- No h saldo suficiente para a finalizao do saque. 4- solicitado um novo valor de acordo com o saldo do usurio. 5- Volta ao passo 10 do fluxo timo. 7. Diagrama de Caso de uso o diagrama que permite representar o relacionamento entre atores e casos de uso.

A criao de caso de uso de derivao ou incluso permite fragmentar um caso de uso e deve ser feito em duas situaes: - O fluxo de eventos utilizado por outro caso de uso ou - O fluxo de eventos muito complexo e ir dificultar o detalhamento em uma nica classe. Como dito anteriormente, alm da derivao, os casos de uso podem ser divididos por incluso e extenso que sero detalhados a seguir. Incluso A incluso representa um fluxo de eventos que se repete em outros casos de uso. Desta forma possvel criar um caso de uso uma nica vez e inclu-lo nos outros que tenham o mesmo fluxo de eventos. Um exemplo o fluxo de eventos que avalia a senha do usurio do caixa eletrnico. Este

caso de uso ser utilizado por outros casos de uso do sistema e sempre ser necessrio execut-lo.

Figura 1 - Caso de uso includo Desta forma, o fluxo de eventos de Verificar senha ser independente do caso de uso Sacar dinheiro, porm includo nesta e se chama Validar usurio. Caso de Uso Validar usurio Descrio: Este caso de uso responsvel por validar os dados de nome e senha do usurio. Pr-condio: o usurio solicitar servio do sistema Ps-condio: o usurio validado Fluxo timo 1. O usurio inicia um servio do sistema. 2. O terminal solicita a senha. 3. A senha digitada pelo usurio. 4. Senha avaliada. Se vlida, encerra com resposta afirmativa. 5. Verifica que a senha no vlida e solicita que o usurio digite novamente a senha. 6. Volta ao passo 2 desse fluxo e aps a terceira tentativa, o sistema informa que no poder mais executar qualquer operao com o carto at que comparea em uma agencia bancria para realizar o desbloqueio. Extenso Quando um fluxo de eventos faz parte de um caso de uso, mas nem sempre este fluxo executado, pode-se retir-lo do caso de uso e coloc-lo como uma extenso do caso de uso. Como ocorre para a incluso deve-se separar o caso de uso caso o fluxo de eventos se repita em outro caso de uso. Por exemplo, o fluxo de eventos Saldo insuficiente, que no executada quando existe saldo na conta do usurio.

Caso de Uso Saldo insuficiente Fluxo timo 1. No h recursos suficientes para finalizao do saque. 2. solicitado ao usurio um valor inferior ao digitado de acordo com seu saldo. 3. A nova quantia digitada pelo usurio.

4. verificada a quantia de recursos na conta do usurio 5. Se valor correto, retorna uma resposta positiva e finaliza o caso de uso. 6. Seno volta ao passo 2 do fluxo. Generalizao (Herana) A derivao entre casos de uso semelhante a derivao em classes, ou seja, o caso de uso filho herda as propriedades do caso de uso pai. Por exemplo, imagine que tenhamos dois tipos de validao do usurio. Uma seria atravs da senha e outra atravs de identificao das impresses digitais do usurio. Neste caso, temos o caso de uso Validar usurio dividida em duas, como mostrado a seguir.

Exerccio Construa um modelo de casos de uso para a seguinte situao fictcia: "Estamos criando um servio de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes so considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor".

8. Classe de Anlise 8.1. Classes de fronteira Responsveis pela comunicao entre o caso de uso e o ator. Normalmente esto associados a janelas, formulrios, interfaces de comunicao, interface de impressora, sensores...

Fronteira

Exemplo de caso de uso Sacar dinheiro: Classes de fronteira: Janela de interface com usurio, que ser responsvel por obter e enviar informaes para o usurio.

Janela de interface com usurio

8.2. Classes de entidade: Utilizadas para modelar informaes que so duradouras e persistem durante a execuo do sistema. So informaes e comportamentos associados a conceitos como objetos ou eventos da vida real. Representao das classes de entidade:

Entidade Ex.: Sacar dinheiro. Usurio, que responsvel por armazenar as informaes do usurio durante o processo de saque de dinheiro no caixa eletrnico. Carto, que responsvel por armazenar as informaes da conta e do carto do usurio durante o processo de saque.

Usurio

Conta

8.3. Classes de Controle: Representam a coordenao, seqenciamento, transaes e controle entre objetos do caso de uso, isto , todo o controle do caso de uso ser encapsulado nas classes de controle. Tambm utilizada para representar a lgica de negcio, que representa o comportamento do caso de uso e que no representa uma informao persistente. A parte dinmica do sistema ser modelada nas classes de controle. Normalmente, a classe de controle recebe mensagens das classes de fronteira e distribuem as tarefas e informaes para outras classes de entidade ou de fronteira e normalmente retornam informaes para a classe de fronteira que mandou a primeira mensagem.

Exemplo de realizao do caso de uso Sacar dinheiro

9. Classes de Projeto A quantidade de classes que deve existir em um projeto depende da complexidade do projeto e, em especial, do caso de uso que se est desenvolvendo. Podemos dizer que: Muitas classes simples significam que: Encapsulam um pouco de toda a inteligncia do sistema. So fortes candidatas a serem reutilizadas. So mais fceis de serem implementadas Poucas classes complexas significam que: Encapsulam boa parte da inteligncia do sistema. So mais difceis de serem reutilizadas. So mais difceis de serem implementadas. Uma classe deve possuir um propsito bem definido e deve ser responsvel por fazer uma coisa e faz-la bem. 9.1. Critrios para implementar as classes de entidade As classes de entidade representam o conhecimento e/ou dados do sistema e, portanto, devem conter os mtodos e atributos que representem este comportamento. Estas classes executam a maioria dos comportamentos dos casos de uso. importante ressaltar que as classes de entidade so responsveis pelos dados e por qualquer outra informao relativa a estes dados; e que no necessariamente estes dados esto relacionados ao banco de dados que representa, na verdade, uma forma de dar persistncia a esses dados. Em alguns casos de uso, talvez seja mais prudente que os comportamentos das classes de entidade sejam incorporados as classes de controle. Critrios para implementar as classes de controle Antes da implementao de uma classe de controle, deve-se primeiro avaliar se a classe de controle realmente necessria, uma vez que a distribuio do controle pode no ser complexo suficiente para determinar a existncia de uma classe de controle especfica. 9.2. Operaes Uma caracterstica muito importante de uma operao o nome que deve ser apropriado, indicando a finalidade e levar em conta a perspectiva do cliente da classe, ser consistente e relativo responsabilidade da operao. Deve-se tambm definir claramente a assinatura da operao. Por assinatura da operao, entende-se os tipos dos parmetros (inteiro, string, etc.) e os prprios parmetros que so passados operao, alm do nome e do tipo de retorno da operao. Deve-se definir se os parmetros so opcionais ou no. As operaes possuem visibilidade que permitem reforar o encapsulamento na classe e podem ser de trs tipos:

+ pblica: so operaes que podem ser acessadas por operaes de outras classes e que representam a interface da classe com as classes clientes (+ o smbolo da UML para operaes pblicas). # protegida: so operaes que podem ser acessadas pelas operaes da prpria classe e pelas classes derivadas (especializao) (# o smbolo da UML para operaes protegidas). - privada: so operaes que podem ser acessadas somente pelas operaes da prpria classe sendo totalmente encapsuladas (- o smbolo da UML para operaes privadas). Uma vez determinadas as operaes, deve-se definir os mtodos, ou seja, deve-se descrever e implementar o corpo de uma operao. A palavra mtodo muitas vezes utilizada no mesmo sentido de operao (o que a princpio no faz muita diferena), mas mtodo a construo da operao. 9.3. Atributos Os atributos possuem uma representao determinada por um nome, um tipo e um valor padro (opcional). importante na representao dos atributos seguir normas que facilitem a identificao. Os atributos, assim como as operaes, possuem visibilidade que so: + pblicos: so atributos que podem ser acessados por operaes de outras classes. No recomendado o uso de atributos pblicos, porque isto ir degradar consideravelmente o encapsulamento da classe. # protegidos: so atributos que podem ser acessados pelas operaes da prpria classe e pelas classes filhas - privados: so atributos que podem ser acessados somente pelas operaes da prpria classe, sendo totalmente encapsulados. 9.4. Relacionamento entre as classes Toda classe possui relacionamento. Os relacionamentos sempre so feitos atravs da parte pblica da classe, para ser mais exato, pelas operaes (mtodos) pblicas, uma vez que no devem existir atributos pblicos. 9.4.1. Dependncia (Ver explicao detalhada dada na aula) A dependncia se caracteriza por uma relao leve entre dois objetos, ou seja, a relao no estrutural. Um relacionamento de dependncia pode ser implementado como: Uma varivel local a uma operao Um parmetro por referncia Uma classe utilitria 9.4.2. Associao Conforme conceito visto anteriormente, uma associao um relacionamento duradouro e pode ser dividido em composio e agregao. importante determinar qual a navegabilidade, ou seja, que classe conhece a outra ou se as duas classes se conhecem, ou seja, podem acessar os servios uma da outra e a multiplicidade que determina quantos objetos de uma classe est associada a outra classe. Outra caracterstica importante determinar se necessrio o desenvolvimento de uma classe de associao que ser responsvel pelo relacionamento. 9.4.2.1. Composio e Agregao Conceitos definidos no incio desta apostila. 9.4.2.2. Classes de associao Uma classe de associao contm as propriedades do relacionamento, existindo uma instncia por relacionamento. A classe de associao sugerida quando se tem uma associao mltipla para composio ou agregao. Existem basicamente trs tipos de multiplicidade:

1 para 1 (1..1) 1 para muitos (1..*) Muitos para muitos (*..*)

9.4.3. Generalizao Uma classe pode compartilhar a estrutura e/ou o comportamento de outra classe e este compartilhamento chamado generalizao, que tambm conhecido como um tipo de ou um, ou seja, quando ao descrever a classe se utilizar esta expresso, provavelmente existir um relacionamento de generalizao entre as classes.

Observaes

Nas associaes entre classes alm da multiplicidade podem ser adicionadas a navegabilidade, o nome do relacionamento e os papis desempenhados neste relacionamento. Exemplos:

Navegabilidade Nome do relacionamento

Exemplo 2:

Papel

Papel