Apostila Para Curso de UML

UML:Unified Modeling Language

I

Sumário

1. Introdução................................................................................1-1Objetivos................................................................................................................................1-2Conectando os estudos....................................................................................................1-3Desenvolvimento de software orientado a objetos...............................................1-5UML – A unificação dos métodos e criação de um novo padrão.......................1-6Uso da UML............................................................................................................................1-8Fases do Desenvolvimento de um Sistema..............................................................1-9Análise de Requisitos......................................................................................................1-10Análise...................................................................................................................................1-11Design (Projeto).................................................................................................................1-12Programação.......................................................................................................................1-13Testes....................................................................................................................................1-14Exercícios.............................................................................................................................1-15

2. Diagrama de Use Case...............................................................2-1Objetivos................................................................................................................................2-2Definição de Use Case......................................................................................................2-3O Levantamento de Requisitos.....................................................................................2-4O Use Case............................................................................................................................2-6Atores......................................................................................................................................2-9Relacionamentos entre casos de uso e atores......................................................2-14Associação...........................................................................................................................2-15Generalização.....................................................................................................................2-16Extensão (extends)..........................................................................................................2-18Inclusão (Include)..............................................................................................................2-20Modelando requisitos com casos de uso.................................................................2-22Casos de uso e pacotes..................................................................................................2-24Quando Utilizar Casos de Uso......................................................................................2-26Exemplos de descrição textual....................................................................................2-27Exercícios.............................................................................................................................2-29

3. Diagrama de Atividades............................................................3-1Objetivos................................................................................................................................3-2Definição do diagrama......................................................................................................3-3Elementos do diagrama...................................................................................................3-4Atividade................................................................................................................................3-5Início do diagrama..............................................................................................................3-6Fim do diagrama.................................................................................................................3-7Transições..............................................................................................................................3-8Desvios....................................................................................................................................3-9Separação e União...........................................................................................................3-12Estado de subatividade..................................................................................................3-15Concorrência Dinâmica...................................................................................................3-16Raias (Swimlanes)............................................................................................................3-17Quando Utilizar Diagramas de Atividades...............................................................3-18Exercícios.............................................................................................................................3-20

4. Diagrama de Classes.................................................................4-1

II

Objetivos................................................................................................................................4-2Introdução..............................................................................................................................4-3Perspectivas..........................................................................................................................4-5Criando Diagramas de Classe........................................................................................4-7Compartimento do Nome da Classe..........................................................................4-10Atributos...............................................................................................................................4-11Operações............................................................................................................................4-15Relacionamentos...............................................................................................................4-18Associação...........................................................................................................................4-19Nome da associação........................................................................................................4-20Multiplicidade.....................................................................................................................4-21Papel (role)..........................................................................................................................4-22Navegabilidade..................................................................................................................4-23Herança/Generalização...................................................................................................4-24Dependência.......................................................................................................................4-28Agregação............................................................................................................................4-29Composição.........................................................................................................................4-31Pacotes de classes e colaborações no sistema.....................................................4-32Pacotes..................................................................................................................................4-33Colaborações......................................................................................................................4-36Quando Utilizar Diagramas de Pacotes e Colaborações....................................4-37Multiplicidade.....................................................................................................................4-38Escopo...................................................................................................................................4-40Classes de Associação....................................................................................................4-42Associação Xor (ou exclusiva).....................................................................................4-44Estereótipo..........................................................................................................................4-45Interfaces e Classes Abstratas.....................................................................................4-47Objetos de Referência e Objetos de Valor..............................................................4-50Objetos de referência......................................................................................................4-51Objeto de Valor..................................................................................................................4-52Coleções para Pontas de Associações de Valores Múltiplos............................4-53Frozen....................................................................................................................................4-54Visibilidade..........................................................................................................................4-55Quando Utilizar Diagramas de Classes.....................................................................4-58Exercícios.............................................................................................................................4-59

5. Diagrama de Estados................................................................5-1Objetivos................................................................................................................................5-2O que é um Diagrama de Estados?.............................................................................5-3Estado......................................................................................................................................5-4Estado Inicial e Estado Final...........................................................................................5-7Transições..............................................................................................................................5-8Estado composto...............................................................................................................5-11Quando Utilizar Diagramas de Estados....................................................................5-12Exercícios.............................................................................................................................5-13

6. Diagrama de Objetos.................................................................6-1Objetivos................................................................................................................................6-2O que é um diagrama de objetos?...............................................................................6-3Criando diagramas de objetos.......................................................................................6-4

III

Quando utilizar diagrama de objetos?........................................................................6-8Exercícios...............................................................................................................................6-9

7. Diagrama de Interação..............................................................7-1Objetivos................................................................................................................................7-2O que é um diagrama de Interação?...........................................................................7-3Diagrama de seqüências..................................................................................................7-5Diagrama de colaboração..............................................................................................7-11Modelando diagramas de seqüências.......................................................................7-14Quando Utilizar Diagramas de Interação.................................................................7-17Exercícios.............................................................................................................................7-18

8. Diagramas Físicos.....................................................................8-1Objetivos................................................................................................................................8-2O que são diagramas físicos?.........................................................................................8-3Diagrama de Componentes............................................................................................8-4Componente.........................................................................................................................8-5Diagrama de Implantação...............................................................................................8-6Nó..............................................................................................................................................8-7Combinando Componentes com Diagramas de Utilização.................................8-8Quando Utilizar Diagramas Físicos.............................................................................8-10Exercícios.............................................................................................................................8-11

9. Apêndice: Extensibilidade da UML.............................................9-1Mecanismos de extensibilidade da UML....................................................................9-2Estereótipos..........................................................................................................................9-3Restrições..............................................................................................................................9-7Glossário.................................................................................................................................9-8

IV

UML

1

2

UML: Unified Modeling Language

1.1. IntroduçãoIntrodução

1

Introdução

Objetivos

Conhecer a UML

Conhecer os principais métodos que originaram a UML

Descrever onde pode ser utilizada a UML

Conhecer as fases de um processo de construção de software

2

Introdução

Conectando os estudos

No curso anterior estudamos os conceitos de orientação a objetos e vimos como a tecnologia de objetos está organizada. Estudamos vários conceitos importantes dentre eles o conceito de classe, objeto, herança, polimorfismo e alguns relacionamentos entre as classes. Foi dado ênfase no estudo da orientação a objetos e deixado para este curso que você está iniciando o estudo de como podemos modelar um sistema utilizando uma linguagem de modelagem de sistemas voltada para a tecnologia de objetos. Não iremos utilizar diagramas de fluxo de dados (DFDs) para fazer a modelagem de sistemas orientados a objetos, a pesar de algumas pessoas tentarem utilizar, uma vez que para a tecnologia de objetos existe outra técnica específica.

O grande problema do desenvolvimento de novos sistemas utilizando a orientação a objetos nas fases de análise de requisitos, análise de sistemas e design é que não existe uma notação padronizada e realmente eficaz que abranja qualquer tipo de aplicação que se deseje. Cada simbologia existente possui seus próprios conceitos, gráficos e terminologias, resultando numa grande confusão, especialmente para aqueles que querem utilizar a orientação a objetos não só sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajudá-los a construir e manter sistemas cada vez mais eficazes.

Quando a "Unified Modeling Language" (UML) foi lançada, muitos desenvolvedores da área da orientação a objetos ficaram entusiasmados já que essa padronização proposta pela UML era o tipo de força que eles sempre esperaram.

A UML é muito mais que a padronização de uma notação. É também o desenvolvimento de novos conceitos não normalmente usados. Por isso e muitas outras razões, o bom entendimento da UML não é apenas aprender a simbologia e o seu significado, mas também significa aprender a modelar orientado a objetos no estado da arte.

UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson que são conhecidos como "os três amigos". Eles possuem um extenso conhecimento na área de modelagem orientado a objetos já que as três mais conceituadas metodologias de modelagem orientada a objetos foram eles que desenvolveram e a UML é a junção do que havia de melhor nestas três metodologias adicionado novos conceitos e visões da linguagem. Veremos características de cada uma destas metodologias no desenvolver deste curso.

Veremos neste curso como a UML aborda o caráter estático e dinâmico do sistema a ser analisado levando em consideração, já no período de modelagem, todas as futuras características do sistema em relação a

3

Introdução

utilização de "packages" próprios da linguagem a ser utilizada, utilização do banco de dados bem como as diversas especificações do sistema a ser desenvolvido de acordo com as métricas finais do sistema.

Não é intuito deste curso definir e explicar os significados de classes, objetos, relacionamentos, mensagens e outras entidades comuns da orientação a objetos, e sim apresentarmos como essas entidades são criadas, simbolizadas, organizadas e como serão utilizadas dentro de um desenvolvimento utilizando a UML. Os conceitos como já comentado foram tratados no curso de Orientação a Objetos o qual recomendamos que seja feito antes deste.

4

Introdução

Desenvolvimento de software orientado a objetos

Os conceitos da orientação a objetos têm sido discutidos há muito tempo, desde o lançamento da primeira linguagem orientada a objetos, a SIMULA. Vários "papas" da engenharia de software mundial como Peter Coad, Edward Yourdon e Roger Pressman abordaram extensamente a análise orientada a objetos como realmente um grande avanço no desenvolvimento de sistemas. Mas mesmo assim, eles citam que não existe (ou que não existia no momento de suas publicações) uma linguagem que possibilitasse o desenvolvimento de qualquer software utilizando a análise orientada a objetos.

Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em suas publicações foram que:

A orientação a objetos é uma tecnologia para a produção de modelos que especifiquem o domínio do problema de um sistema.

Quando construídos corretamente, sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e provêm a oportunidade de criar e implementar componentes totalmente reutilizáveis.

Modelos orientados a objetos são implementados convenientemente utilizando uma linguagem de programação orientada a objetos. A engenharia de software orientada a objetos é muito mais que utilizar mecanismos de sua linguagem de programação, é saber utilizar da melhor forma possível todas as técnicas da modelagem orientada a objetos.

A orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovada e usada em inúmeros projetos para construção de diferentes tipos de sistemas.

A orientação a objetos requer um método que integre o processo de desenvolvimento e a linguagem de modelagem com a construção de técnicas e ferramentas adequadas.

5

Introdução

UML – A unificação dos métodos e criação de um novo padrão

A UML é uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistência, fácil de se comunicar com outras aplicações, simples de ser atualizado e compreensível.

Existem várias metodologias de modelagem orientada a objetos que até o surgimento da UML causavam uma guerra entre a comunidade de desenvolvedores orientado a objetos. A UML acabou com esta guerra trazendo as melhores idéias de cada uma destas metodologias, e mostrando como deveria ser a migração de cada uma para a UML.

Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90:

Booch – O método de Grady Booch para desenvolvimento orientado a objetos está disponível em muitas versões. Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas. O Método de Booch trazia uma simbologia complexa de ser desenhada a mão, continha também o processo pelo qual sistemas são analisados por macro e micro visões.

OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é um método desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O método é especialmente voltado para o teste dos modelos, baseado nas especificações da análise de requisitos do sistema. O modelo total do sistema baseado no método OMT é composto pela junção dos modelos de objetos, funcional e use-cases.

OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson. O método OOSE é a visão de Jacobson de um método orientado a objetos, já o Objectory é usado para a construção de sistemas tão diversos quanto eles forem. Ambos os métodos são baseados na utilização de use-cases, que definem os requisitos iniciais do sistema, vistos por um ator externo. O método Objectory também foi adaptado para a engenharia de negócios, onde é usado para modelar e melhorar os processos envolvidos no funcionamento de empresas.

Cada um destes métodos possui sua própria notação (seus próprios símbolos para representar modelos orientados a objetos), processos (que

6

Introdução

atividades são desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas notações e processos).

Diante desta diversidade de conceitos, "os três amigos", Grady Booch, James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram inúmeras versões preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idéias que melhoraram ainda mais a linguagem.

Os objetivos da UML são:

A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a objetos

Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis

Criar uma linguagem de modelagem usável tanto pelo homem quanto pela máquina

A UML está destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indústrias. Ela está totalmente baseada em conceitos e padrões extensivamente testados provenientes das metodologias existentes anteriormente, e também é muito bem documentada com toda a especificação da semântica da linguagem representada em meta-modelos. Atualmente as empresas de desenvolvimento de software utilizam muito esta linguagem, podemos afirmar tranqüilamente que esta é a linguagem de modelagem de dados e processos mais utilizada por empresas que trabalham com linguagens orientadas a objeto.

7

Introdução

Uso da UML

A UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer característica de um sistema em um de seus diagramas e é também aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a finalização com a fase de testes.

O objetivo da UML é descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum é para criar modelos de sistemas de software, mas a UML também é usada para representar sistemas mecânicos sem nenhum software. Aqui estão alguns tipos diferentes de sistemas com suas características mais comuns:

Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os usuários. Manter grandes quantidades de dados com relacionamentos complexos, que são guardados em bancos de dados relacionais ou orientados a objetos.

Sistemas Técnicos: Manter e controlar equipamentos técnicos como de telecomunicações, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programação de software de que os sistemas de informação. Sistemas Técnicos são geralmente sistemas real-time.

Sistemas Real-Time Integrados: Executados em simples peças de hardware integrado a telefones celulares, carros, alarmes etc. Estes sistemas implementam programação de baixo nível e requerem suporte real-time.

Sistemas Distribuídos: Distribuídos em máquinas onde os dados são transferidos facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação sincronizados para garantir a integridade dos dados e geralmente são construídos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.

Sistemas de Software: Definem uma infra-estrutura técnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e ações de usuários que executam ações de baixo nível no hardware, ao mesmo tempo que disponibilizam interfaces genéricas de uso de outros softwares.

Sistemas de Negócios: descreve os objetivos, especificações (pessoas, computadores etc.), as regras (leis, estratégias de negócios etc.), e o atual trabalho desempenhado nos processos do negócio.

8

Introdução

É importante perceber que a maioria dos sistemas não possuem apenas uma destas características acima relacionadas, mas várias delas ao mesmo tempo. Sistemas de informações de hoje, por exemplo, podem ter tanto características distribuídas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.

9

Introdução

Fases do Desenvolvimento de um Sistema

Atualmente existem muitos processos para desenvolvimento de software criados por empresas e pesquisadores. Nós iremos aqui mostrar algumas fazes do desenvolvimento de software, para isto dividimos o ciclo de desenvolvimento em cinco fases: análise de requisitos, análise, design (projeto), programação e testes. Estas cinco fases não devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e desempenho. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML.

10

Introdução

Análise de Requisitos

Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". Através do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem, funções estas chamadas de "use-cases". Os atores externos e os "use-cases" são modelados com relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Cada "use-case" modelado é descrito através de um texto, e este especifica os requerimentos do ator externo que utilizará este "use-case". O diagrama de "use-cases" mostrará o que os atores externos, ou seja, os usuários do futuro sistema deverão esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta será implementada. A análise de requisitos também pode ser desenvolvida baseada em processos de negócios, e não apenas para sistemas de software.

11

Introdução

Análise

A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas através de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colaborações entre classes também são mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaborações são criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes neste diagrama.

12

Introdução

Design (Projeto)

Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes serão adicionadas para prover uma infra-estrutura técnica: a interface do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros. As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova infra-estrutura técnica tornando possível alterar tanto o domínio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificações para a fase de programação do sistema.

13

Introdução

Programação

Na fase de programação, as classes provenientes do design são convertidas para o código da linguagem orientada a objetos escolhida (a utilização de linguagens procedurais é extremamente não recomendada). Dependendo da capacidade da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da criação de modelos de análise e design em UML, é melhor evitar traduzi-los mentalmente em código. Nas fases anteriores, os modelos criados são o significado do entendimento e da estrutura do sistema, então, no momento da geração do código onde o analista conclua antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. A programação é uma fase separada e distinta onde os modelos criados são convertidos em código.

14

Introdução

Testes

Um sistema normalmente é rodado em testes de unidade, integração, e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos. Os testes de aceitação observam o sistema como uma "caixa preta" e verificam se o sistema está funcionando como o especificado nos primeiros diagramas de "use-cases".

O sistema será testado pelo usuário final o qual verificará se os resultados mostrados estão realmente de acordo com as necessidades levantadas durante a fase de requisitos.

15

Introdução

Exercícios

1. Cite e descreva, brevemente, os principais métodos que deram origem a UML bem como os seus autores.

2. Que tipos de sistemas podem fazer uso da UML?

3. Quais são as fases do desenvolvimento de software? Quais são as principais atividades de cada uma destas fases?

16

Introdução

Espaço para anotações

17


2.2. Diagrama de Use CaseDiagrama de Use Case

1

Diagrama de Use Case

Objetivos

Entender o diagrama de use case

Conhecer os elementos que fazem parte deste diagrama

Aprender a modelar um diagrama de use case para um sistema

Conhecer os tipos de relacionamentos possíveis entre os elementos do use case

Saber quando e como utilizar use case

2


Definição de Use Case

Neste capítulo iremos estudar um dos diagramas centrais da UML, o diagrama de Use Case (Casos de Uso). Este é um diagrama fundamental para a modelagem de sistemas orientados a objeto quando utilizamos UML. A maior dificuldade em modelarmos um sistema não está nos diagramas que temos que desenhar, no código que devemos criar ou nas bases de dados que devemos projetar. Na realidade está nos requisitos que devemos gerenciar.

Os requisitos que um sistema possui muitas vezes são complexos, não estou falando aqui de requisitos simples, como o usuário pedir "Faça um programa que permita a leitura de uma seqüência de números e informe a média e o desvio padrão desse conjunto". Temos na verdade que lidar com dezenas de páginas de "desejos do usuário". Sim, o usuário deseja que o sistema realize determinadas tarefas, deseja que o sistema realize seus sonhos e muitas vezes deseja que ele faça milagres. A espectativa dos usuários quanto aos sistemas é sempre muito grande, eles imaginam que o mesmo possa realizar todas as coisas que eles precisam e que irá resolver todos os seus problemas. Acham no sistema a solução para os seus problemas. Sabemos que isto não é verdade e que algumas tarefas não podemos modelar e passar par dentro do software.

Pois é com essa expectativa humana que temos que lidar. Temos que entender o que o usuário quer, e muito mais importante, demonstrar que realmente entendemos seus desejos. A grande pedra do desenvolvimento de sistemas começa exatamente neste ponto. Como era difícil validar com o usuário o que havia sido levantado! Como era difícil transportar para modelos e códigos aquelas dezenas de linhas em linguagem natural! Precisamos documentar todos os desejos dos usuários para depois podermos tentar realizá-los.

A Língua Portuguesa, assim como outras, é ambígua, por natureza. Portanto, necessitamos de um padrão que permita o uso de linguagem natural, mas em um formato que reduza as ambiguidades. Além disso, que permita com facilidade converter essa estrutura para os diagramas e implementações do sistema. Para isto então temos os diagramas de Caso de Uso na UML.

3


O Levantamento de Requisitos

A UML e a modelagem de casos de usos não interfere nas técnicas usadas pelos desenvolvedores para o levantamento de requisitos. Pelo contrário, o caso de uso torna-se o "braço direito" do desenvolvedor, auxiliando-o a validar os requisitos extraídos junto ao usuário.

O levantamento de requisitos de um sistema não é uma tarefa fácil, mas também não é impossível. O problema reside no fato de que estamos lidando com um ser humano que expressa suas idéias, geralmente fora de ordem e sem muita explicação. É difícil encontrarmos o usuário que nos forneça a “receita de bolo” pronta para desenvolver seu sistema. Normalmente ele tem muitos problemas, muitas idéias de como solucioná-los e uma idéia bem distorcida do que um sistema de computação pode fazer por ele. E a partir daí nossa tarefa é bem simples: pegar todo esse emaranhado e transformar primeiramente numa documentação inteligível para ambas as partes e depois no sistema dos sonhos dele! Claro que estou brincando, não é tão simples assim todo este processo e muitas vezes nós passamos por inúmeras discuções onde precisamos mostrar que algumas coisas que o usuário está querendo fazer de uma determinada forma não será possível e que para poder atingir o mesmo objetivo devemos seguir outro caminho.

Sabemos que os problemas existem, mas com as técnicas, ferramentas e paradigma adequados, tudo pode correr tranqüilamente. Temos que ter em mente que o usuário não é o nosso inimigo, pelo contrário, se conseguirmos estabelecer com ele uma comunicação sem ruídos, certamente a validação ocorrerá sem problemas e o nosso software conseguirá então satisfazer os desejos do usuário.

Durante este processo de levantamento de requisitos através de conversas com os usuários é preciso mostrar para o usuário que devemos formar um time para alcançarmos o mesmo objetivo. É importante que durante este processo haja muita troca de informações entre os usuários e analistas. Esta troca de informações é que irá garantir o sucesso desta etapa de levantamento de requisitos.

Vamos pensar: se o usuário despeja sobre nós analistas uma centena de conceitos e procedimentos a respeito da sua área de negócios e apenas "engolimos" esses conceitos sem analisá-los, o que ocorrerá? Provavelmente estaremos implementando a nossa impressão sobre o assunto e não a realidade do problema. Toda informação, por mais singela, deve ser analisada quanto a sua inconsistência e/ou ambiguidade. Para que você entenda o que quero transmitir, vamos fazer um teste.

4


Suponhamos o seguinte dialogo entre usuário e analista:

Desenvolvedor:

O quo o senhor espera desse sistema?

Usuario:

Eu tenho uma loja de peças. Gostaria que o meu PV fosse interligado com meu estoque e eu pudesse a qualquer momento alterar valores dos FP's. Posso oferecer descontos a alguns tipos de clientes, mas preciso autorizar essa operação. No fim do mês quero um relatório dos produtos que mais venderam. Preciso também saber a estatística de vendas por forma de pagamento. De tempos em tempos deve aparecer na tela do sistema uma promoção relâmpago que de um brinde ao cliente. Preciso que o sistema controle os pedidos também.

O que você identificaria de ambíguo ou não compreensível nessa descrição do usuário? Várias coisas, não?! Pois bem, cabe ao analista buscar o esclarecimento desses itens. Podemos então começar perguntando a esse usuário:

O que 6 PV e FP?Que tipos de clientes podem receber descontos?Como seria feita esta autorização de desconto e por quem?Que quantidade de produtos deve aparecer no relatório dos que mais venderam?A estatística leva em conta que período (semanal, quinzenal, mensal, etc)?Quanto tempo significa "de tempos em tempos"?Quais pedidos precisam ser controlados: os dos clientes ou os feitos aos fornecedores?

Provavelmente, as respostas a essas perguntas levarão a novas dúvidas, que precisarão ser esclarecidas. Percebemos, então, que uma postura correta dos participantes associada a boas técnicas de levantamento de requisitos (por exemplo: entrevistas e brainstorming (Consiste em uma ou várias reuniões nas quais os participantes sugerem idéias, sem que as mesmas sejam criticadas. Numa segunda fase, as idéias passam por uma revisão e organização). Todavia, precisamos expressar esses requisitos de uma forma que não seja para o desenvolvedor um texto extenso e pouco estruturado e para o usuário não sejam seqüências de comandos sem o menor sentido. É agora que a modelagem de casos de uso nos ajuda, unindo usuários e desenvolvedores.

5


6


O Use Case

Um caso de uso (Use Case) descreve uma seqüência de ações que representam um cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com atores. Vamos esmiuçar essa definição para conseguir entende-la.

Uma vez que o desenvolvedor levante os requisitos com o usuário, há a necessidade de documentá-los, não só para entendimento e validação de ambas as partes, como para servir de base não ambígua para toda a equipe de desenvolvimento. A documentação dos requisitos evita que informações importantes se percam, sendo descobertas apenas ao apresentar o produto final ao usuário. Em desenvolvimento de sistemas não funciona amarrar uma fitinha no dedo, para não esquecer de um requisito importante!

Utilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor é separar as funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto de ações que tenham um objetivo bem definido.

Suponhamos, num sistema de vendas de uma loja de roupa, que sejam tarefas distintas e bem definidas: consultar informações sobre um produto, efetuar reserva, emitir comprovante de reserva, efetuar venda, emitir nota fiscal, realizar fechamento diário do caixa, etc. Cada uma destas tarefas possui um conjunto de ações que precisam ser executadas para que o objetivo da tarefa seja alcançado. No caso de efetuar venda, é preciso informar a identificação da vendedora, a identificação do produto, quantidade vendida, etc. Ao pensarmos nessas ações realizadas numa rotina sem problemas, estamos lidando com um cenário perfeito, que será o nosso cenário principal.

O cenário principal descreve uma seqüência de ações que serão executadas considerando que nada de errado ocorrerá durante a execução da seqüência.

Vejamos no exemplo abaixo o trecho do caso de uso "Emitir Saldo em um terminal de caixa eletrônico":

Cenário Principal

1. O sistema realiza a leitura do cartão magnético do correntista;2. O sistema solicita a digitação da senha. O correntista digita a senha;3. O sistema valida a senha;4. O correntista seleciona a opção de saldo;

7


5. O sistema questiona o tipo de saldo: conta corrente, poupança e aplicações;6. O sistema processa e mostra o saldo solicitado pelo cliente.

No exemplo acima, temos um cenário perfeito, no qual nada ocorre de errado. Todavia, o mundo não é perfeito, muito menos as transações de um sistema. Então, como podemos representar as exceções? Podemos represetá-las com os cenários alternativos. Por exemplo: considerando o cenário principal da emissão de saldo em um Caixa Eletrônico, poderiamos modelar os cenários alternativos descritos abaixo.

Alternativa: Problemas na leitura do cartão magnético

1ª) Se o sistema não conseguir ler os dados do cartão magnético, tentar nova leitura por, no máximo, mais duas vezes. Caso persista o problema, encerrar o caso de uso (ao dizermos que haverá o encerramento do caso de uso. Estamos afirmando que a rotina não pode prosseguir pelo motivo relatado. Logicamente que numa implementação, o fluxo retornará ao seu início (nesse caso, a leitura de um próximo cartão magnético).

Alternativa: Senha Inválida

3ª) Se a senha digitada pelo correntista não for igual a senha cadastrada no sistema, informar ao mesmo e solicitar nova digitação. Esse processo pode ser repetido por no máximo três tentativas (incluindo a primeira). Após a terceira tentativa, a conta do usuário deverá ser bloqueada e o caso de uso encerrado. Include Bloquear Conta (o include corresponde a um dos tipos de relacionamentos entre os diagramas de caso de uso e será explocado mais adiante nesta apostila).

Alternativa: Conta Inexistente

6ª) Se o correntista não possuir o tipo de conta selecionada, informar ao mesmo e encerrar o caso de uso.

Nos exemplos acima as alternativas são apresentadas como subitens do cenário principal (ítens 1, 3 e 6). Esse procedimento facilita a associação da alternativa com o fluxo principal. O caso de uso deve descrever uma rotina bem definida do sistema e deve ser totalmente compreensível tanto para a equipe de desenvolvimento quanto para os clientes que detém o conhecimento do domínio do sistema.

O caso de uso, por expressar os requisitos do sistema - nada mais do que a essência deste -, é utilizado durante todo o processo de desenvolvimento. Os requisitos além de serem a base para a criação dos modelos de análise,

8


projeto e implementação, também são usados como base para a criação de testes do sistema. Podemos dizer que o modelo de casos de uso será central para todas as demais etapas do desenvolvimento do sistema. Este diagrama será sempre utilizado na construção dos demais, sendo muito importante estar bem definido expressando os desejos do cliente.

Já entendemos porque o caso de uso é uma seqüência de ações, o que é um cenário principal e o que é um cenário alternativo. Esta faltando apenas saber o que são interações com atores.

Ao modelarmos um sistema, necessitamos saber até que ponto devemos nos preocupar. Estes pontos-limites são a fronteira do sistema (system boundary).

Por exemplo: um sistema de controle de vendas emitirá em algum momento o faturamento semanal ou mensal de cada vendedor para o Departamento Pessoal. Todavia, não é responsabilidade do sistema o que o Departamento Pessoal fará com essa informação.

Os sistemas recebem e enviam informações para o mundo externo através de suas fronteiras, também conhecidas como interface do sistema. Logicamente que essas informações não podem cair num "buraco negro", na saída, nem surgem por mágica, na entrada. Alguém ou algo deve ser responsável por enviar e/ou receber informações do sistema.

Vejamos a representação gráfica do caso de uso:

Um caso de uso é representado por uma elipse contendo o seu nome. O nome do caso de uso também pode ser colocado abaixo da elipse, que pode conter ou não compartimentos referentes a pontos de extensão (estes serão apresentados mais tarde no curso).

Figura 2-1: Representação básica de um use case

9


10


Atores

Na modelagem de casos de uso, esse papel externo é exercido por um ator (actor). Na realidade, esse ator, que pode ser tanto uma pessoa, como um grupo ou ainda um sistema, representa um conjunto de papéis. Um caso de uso pode se relacionar com mais de um ator.

Um ator representa um conjunto de papéis exercido por um usuário do sistema ao interagir com um determinado caso de uso.

Um ator é, portanto, um papel que um usuário desempenha em relação ao sistema. Quando você lidar com atores, é importante pensar nos papeis em vez de pensar nas pessoas ou em cargos. Os atores desempenham os casos de uso. Um único ator pode desempenhar muitos casos de uso; um caso de uso pode ter reciprocamente vários atores desempenhando-o. Na prática, considero que os atores são mais úteis quando se está propondo os casos de uso. Em face de um grande sistema, freqüêntemente pode ser difícil propor uma lista de casos de uso. Nestas situações, é mais fácil chegar primeiro a lista de atores, e, então, tentar estabelecer os casos de uso para cada ator.

Os atores não precisam ser humanos, embora sejam representados como bonecos humanos nos diagramas de caso de uso. Um ator também pode ser um sistema externo que necessita de alguma informação do sistema atual. Existem diversas variações no que as pessoas mostram como atores. Algumas pessoas mostram cada sistema externo ou agente humano no diagrama de caso de uso; outras preferem mostrar o ativador do caso de uso. Prefiro expor o agente que obtém valor do caso de uso, o qual algumas pessoas chamam de ator básico. Entretanto, não levo isso muito longe. Contento-me em ver o sistema de contabilidade obtendo valor, sem tentar identificar o agente humano que obtém o valor do sistema de contabilidade - isso transmitiria modelagem ao próprio sistema de contabilidade. Dito isto, você deve sempre contrapor casos de uso com atores do sistema, descubra quais são os objetivos reais do usuário e considere maneiras alternativas para atingir estes objetivos.

Vejamos a representação gráfica de um ator:

O ícone estereótipo padrão para um ator é a figura de um "stick man", contendo seu nome abaixo da figura. Outra representação consiste num retângulo de classe, com o estereótipo << actor >>. E, ainda, é permitido ao desenvolvedor utilizar outros ícones que identifiquem mais precisamente o tipo de ator.

11


Figura 2-2: Representação de atores

Quando estou trabalhando com atores e casos de uso, não me preocupo muito sobre qual é a associação exata entre eles. Na maioria das vezes, estou realmente interessado nos casos de uso; os agentes são simplesmente um meio de chegar lá. A medida que tenho todos os casos de uso, não me preocupo com os detalhes dos agentes.

Existem algumas situações nas quais vale a pena descobrir os agentes mais tarde.

O sistema pode precisar configuração para vários tipos de usuários. Neste caso, cada tipo de usuário é um ator e os casos de uso lhe mostram o que cada ator precisa fazer.

Identificar quem deseja casos de uso pode ajudá-lo a negociar prioridades entre vários atores.

Alguns casos de uso não têm ligações claras com atores específicos. Considere uma empresa de serviço público. Evidentemente, um dos seus casos de uso é “Enviar Contas”. Entretanto, não é fácil identificar um ator associado. Nenhum papel de usuário em especial necessita uma conta. A conta é enviada para o cliente, mas ele não se importaria se isso não acontecesse. O melhor palpite para ator aqui é o Departamento de Cobrança, no sentido que este obtém valor deste caso de uso. Mas o Departamento de Cobranca, não está, geralmente, envolvido neste caso de uso.

12


Esteja ciente de que alguns casos de uso não aparecem como resultado do processo de considerá-los para cada ator. Se isso acontecer, não se preocupe muito. O importante é compreender casos de uso e os objetivos dos usuários que eles atingem.

Uma boa fonte para identificar os casos de uso são os eventos externos. Considere todos os eventos do mundo externo para os quais você quer reagir. Um dado evento pode causar uma reação no sistema que não envolve usuários, ou pode causar principalmente reação dos usuários. A identificação dos acontecimentos para os quais o sistema necessita reagir vai lhe ajudar a identificar os casos de uso.

Como exemplo vamos considerar a representação da figura abaixo. Num determinado sistema acadêmico, a rotina de atualizar a freqüência dos alunos pode ser executada por quem? Pelos funcionários da Secretaria, pelo próprio Professor ou pelo Sistema de Avaliação on-line. Esses papéis são representados por Atores.

Essa comunicação sistema-ator (e vice-versa) consiste da interação entre sistema e atores.

Figura 2-3: Atores interagindo com o caso de uso

É responsabilidade do caso de uso demonstrar com quais atores o sistema interage. Essa identificação na fase de análise fornece ao projetista, no futuro, base para a criação dos perfis de acesso ao sistema.

13


O caso de uso especifica como alcançar a realização de um procedimento sem relacionar detalhes de implementação. Portanto, mostramos o que executar sem definir a forma como é feito.

Veja os exemplos.

Considere o seguinte trecho de caso de uso:

"... O cliente seleciona na lista o produto desejado..."

Essa pequena descrição nos diz que existe uma lista contendo os produtos disponíveis para esta operação. Todavia, a descrição não diz se essa lista será representada por um grid, uma listbox, uma combobox ou algum outro tipo de componentes. Não represente nas alternativas validações que por default já são feitas em qualquer sistema.

Por exemplo: num campo data qualquer, checar se a entrada do usuário é uma data válida no calendário (por exemplo: 14/01/2004).

Entretanto, deve-se expressar validações que se refiram as regras de negócio.

Por exemplo: o campo data de rescisão de contrato deve estar dentro do mês corrente. Esta é uma regra de negócio que deve aparecer no caso de uso.

Exemplo de um caso de uso com cenários principais e alternativos.

Caso de Uso: Reserva em um Restaurante

Ator: Atendimento ao clienteCenário Principal

1. O cliente informa ao atendente a data da reserva, que é repassada ao sis-tema;2. O sistema mostra o mapa do salão do restaurante, indicando as mesas já reservadas e as que estão livres. O sistema calcula e exibe o número de reservas ainda disponíveis.3. Um ou vários lugares disponíveis é (são) escolhido(s) para reserva.4. O sistema solicita o CPF do cliente, para identificação do mesmo no sistema. O sistema pesquisa o cliente e mostra nome e telefones de contato, para confirmação.5. Após confirmação, a reserva é efetuada em nome do cliente.

Cenários Alternativos

Alternativa: Data não disponfvel para reserva

14


1ª) O sistema verifica se para a data informada é possível efetuar reservas. Caso negativo, uma nova data deve ser solicitada.

Alternativa: Reservas esgotadas

1ª) O sistema verifica se para o dia informado, as reservas estão esgotadas. O sistema deve possibilitar que seja informada nova data ou que se encerre a solicitação de reserva.

Alternativa: Cliente não cadastrado

4ª) Se o cliente não for cadastrado: Extend Cadastrar Cliente de Reserva (Extend é um tipo de relacionamento que explicarei mais adiante).

Não existe um padrão da UML que determine uma forma única de se escrever casos de uso. As ações podem ser descritas em parágrafos ou através de enumerações, identificadas (por letras ou números) ou não. Outra forma é criar um texto com seções de pré e pós-condições. É possível, ainda, escrever o caso de uso como um pseudocódigo. O importante é que cada caso de uso deve relacionar o suficiente para seu entendimento e que seja compreensível para todos os envolvidos no processo de desenvolvimento.

15


Relacionamentos entre casos de uso e atores

Os casos de uso representam conjuntos bem definidos de funcionalidades do sistema, que não podem trabalhar sozinhas no contexto do sistema. Portanto, esses casos de uso precisam se relacionar com outros casos de uso e com atores que enviarão e receberão mensagens destes.

Relacionamentos entre casos de uso: generalização/herança, extensão e inclusão.

Relacionamentos entre atores: generalização/herança

Relacionamentos entre atores e casos de uso: associação

16


Associação

Representa a interação do ator com o caso de uso, ou seja, a comunicação entre atores e casos de uso, por meio do envio e recebimento de mensagens.

As associações entre casos de uso são sempre binárias, ou seja, envolvem apenas dois elementos. Representam o único relacionamento possível entre atores e casos de uso.

Por exemplo: O ator Correntista envia e recebe mensagens do Caso de Uso Calcular Empréstimo Pessoal, por um relacionamento de associação.

Figura 2-4: Relacionamento de associação entre atores e use caseA representação gráfica de uma associação corresponde a uma linha sólida, ligando o caso de uso ao ator e vice-versa.

17


Generalização

Ocorre entre casos de uso ou entre atores. É considerado quando temos dois elementos semelhantes, mas com um deles realizando algo a mais. Costuma ser comparado ao relacionamento de extensão, com uma variação do comportamento normal sendo descrita sem muito rigor. Segue o mesmo conceito da orientação a objetos. Podemos dizer também que este relacionamento é conhecido como herança.

Vejamos a representação deste relacionamento:

Um relacionamento de generalização é representado graficamente pela seta de generalização, que corresponde a uma linha sólida com uma única seta fechada, mas não preenchida em uma das pontas. A seta parte do caso de uso mais específico em direção ao mais genérico.

Por exemplo: num caso de uso no qual C2 herda de C1, significa dizer que temos C1como um caso de uso mais genérico e C2 mais específico.

Figura 2-5: Generalização entre casos de uso

18


Por exemplo: podemos criar um ator generico Aluno e especializá-lo nos atores Aluno Matriculado e Aluno Ouvinte.

Figura 2-6: Gerneralização entre atores

19


Extensão (extends)

Um relacionamento de extensão entre casos de uso indica que um deles terá seu procedimento acrescido, em um ponto de extensão, de outro caso de uso, identificado como base. Os pontos de extensão são rótulos que aparecem nos cenários do caso de uso base. É permitido colocar diversos pontos de extensão num mesmo caso de uso, inclusive repetir um mesmo ponto de extensão. No corpo do caso de uso representamos a extensão com o termo Extend seguido do ponto de extensão.

Figura 2-7: Relacionamento de extensão (extend)

Por exemplo:

Cenário Principal...5. Escolher forma de pagamento.6. Se cliente VIP, calcular desconto especial. Extend (desconto ClienteVip)....

Você deve estar se perguntando: Como e quando usar um relacionamento de extensão? Um caso de uso de extensão é muito utilizado para:

• expressar rotinas de exceção ou para expressar o desmembramento de um caso de uso (quando um cenário alternativo possui um fluxo grande ou que mereça uma atenção especial);

• separar um comportamento obrigatório de outro opcional;

• separar um trecho do caso de uso que será executado apenas em determinadas condições;

20


• separar trechos que dependam da interação com um determinado ator. Por exemplo: no cadastro de uma venda, a rotina de desconto só pode ser executada pelo gerente. Essa rotina pode ser transferida para um caso de uso de extensão.

Vejamos a representação gráfica:

Um relacionamento de extensão é representado graficamente por uma seta tracejada com a ponta aberta, que parte do caso de uso estendido e contém o estereótipo <<extend>>. Junto deste texto é possível colocar rótulos correspondentes aos pontos de extensão.

Figura 2-8: Relacionaemnto de extensão e inclusão (visto abaixo)

21


Inclusão (Include)

Indica que um deles terá seu procedimento copiado num local especificado no outro caso de uso, identificado como base. Você deve estar se perguntando: Quando uso um relacionamento de inclusão? Quando existem cenários cujas ações servem a mais de um caso de uso. Por exemplo: validar matrícula é útil para casos de uso como renovar matrícula de aluno, emitir histórico escolar, lançar notas de provas, entre outros.

Textualmente, um relacionamento de inclusão, dentro da descrição de um caso de uso base, é representado com o termo Include seguido de seu nome.

Por exemplo:

Cenário Principal

1. O aluno digita sua matrícula. O sistema verifica se a matrícula é válida e ativa. Include (Validar Matrícula). (...)

Mais do que evitar a cópia de trechos idênticos, ganhamos tempo de modelagem e também de implementação ao trabalhar com casos de uso de inclusão. Perceba ainda que teremos um ganho significativo quando depois formos fazer a manutenção do sistema.

Veja a representação gráfica deste tipo de relacionamento:

Um relacionamento de inclusão é representado graficamente por uma seta tracejada com a ponta aberta (este é o símbolo da dependência também), que parte do caso de uso base e contém o estereótipo <<include>>.

22


Figura 2-9: Relacionamento de inclusão

Abaixo você tem outro exemplo de um relacionamento de inclusão, onde um instrutor pode atualizar material didático porém esta atividade irá incluir outra onde deverá ser definido e registrado uma data para entrega deste material.

Figura 2-10: Relacionamento de inclusão entre use cases

23


Modelando requisitos com casos de uso

Não existe uma ordem prédefinida que determine quais diagramas devem ser modelados primeiramente. A ordem é determinada pela preferência do desenvolvedor e/ou processo que esteja sendo usado. Sabemos que a UML é independente de processo. Desta forma, o objetivo deste curso não é apresentar um processo formal para trabalhar com a UML. Entretanto, presencio a ansiedade vivida por quem inicia a aprendizagem da UML em conhecer a "ordem dos fatos". Assim, procurarei, em tópicos como este, orientar sobre um determinado caminho dos muitos que vocês podem escolher. Pelo menos é um pontapeé inicial!

Alguns desenvolvedores iniciam a modelagem do sistema pela criação das classes, outros pelos casos de uso. Se este for o caso, é importante tomar cuidado com os nomes e os verbos utilizados, pois estes transformar-se-ão em objetos, atributos e métodos. Outros desenvolvedores começam desenvolvendo o diagrama de casos de uso para fazer o levantamento dos requisitos do sistema, depois ustilizam alguns diagramas de atividades para expressar atividades que já existem e que deverão ser consideradas quando for elaborado o sistema e somente depois deste diagrama partem para a definição das classes através do diagrama de classes. Aconselho seguir sempre esta última abordagem pois é melhor levantarmos todos os requisitos do sistema e documentá-los assim como descobrir e também documentar as principais atividades do sistema antes de començar a modelar as classes. O modelo de classes está bem focado na estrutura interna do software a ser desenvolvido e quando estamos levantando requisitos bem como as atividades não estamos ainda preocupados com isto. Neste curso iremos adotar esta abordagem.

Todos os casos de uso possuem nomes que os identificam e diferenciam dos demais. Segundo a UML corresponde a uma seqüência de caracteres (letras, números e a maioria dos sinais de pontuação), exceto os dois-pontos, que são usados no nome do caminho (com o nome de seu pacote).

Normalmente são breves expressões representando a essência do que você está modelando. Pode-se iniciar a modelagem a partir da descoberta de uma lista de casos de uso ou uma lista de atores. Certo é que a partir de um deles é possível chegar ao outro.

Veja por exemplo:

Dado um caso de uso descobrimos seus atores a partir de vários questionamentos. Um deles seria: "Quais atores são responsáveis por esse caso de uso?"

24


Dado um ator, descobrimos casos de uso a partir de vários questionamentos. Alguns deles seriam: "Quais casos de uso são responsabilidades desse ator?" "Os atores precisam interagir com quais casos de uso?"

Antes de identificar o ator é importante identificar seus papéis. Uma vez identificados os casos de uso, devemos nos concentrar em descrever os cenários principais. A partir dos cenários principais, identificamos e descrevemos os cenários alternativos. É comum durante a descrição percebermos a necessidade de cenários comuns a outros casos de uso. Estamos comecando a descobrir os casos de inclusão. Da mesma forma, casos de uso muito extensos, seja quanto ao cenário principal ou quanto aos cenários alternativos, devem ser divididos em casos de extensão.

Os casos de uso possuem um enfoque conceitual dentro da modelagem em UML. A implementação de um caso de uso ocorre através dos diagramas de interação (estes serão estudados mais adiante no curso)

25


Casos de uso e pacotes

Em sistemas de media/alta complexidade é comum termos dezenas de casos de uso. Nesse caso, a representação de todos eles em um único diagrama é uma tarefa impossível. A fim de minimizar a visualização e, principalmente, organizar esses casos de uso considerando uma mesma abordagem conceitual, podemos trabalhar com pacotes. Um pacote corresponde a um agrupamento de qualquer elemento de modelo, como casos de uso, classes, estados, outros pacotes, etc.

Graficamente, o pacote é representado como um grande retângulo com um pequeno retângulo como uma aba posicionada no topo do seu lado esquerdo - algo como o ícone que representa uma pasta. O nome do pacote deve ser exibido na aba caso seu conteúdo seja mostrado. Caso contrário, o nome do pacote deve vir no seu interior.

Figura 2-11: Representação de pacote exibindo os casos de uso

Quando desejamos fazer referenda a um elemento que pertença a algum pacote, devemos usar a nomenclatura <nome do pacote> seguido de :: e <nome do elemento>.

pacote:: elemento

26


Por exemplo:

Controle Acadêmico:: Cadastrar Aluno

Os elementos de um pacote devem ter nomes distintos dentro do mesmo pacote. Todavia, é possível termos elementos com o mesmo nome desde que residentes em pacotes diferentes.

Figura 2-12: Representação de um pacote sem os casos de uso

27


Quando Utilizar Casos de Uso

Muitas vezes nos perguntamos quando usar isto tudo, inicialmente pode parecer um pouco burocrátivo e não necessário este processo todo, mas veremos ao passar do tempo que ele é fundamental para uma boa análise.

Não consigo imaginar, no momento, uma situação na qual não utilizaria casos de uso. Eles são uma ferramenta essencial na captura de requisitos e no planejamento e controle de um projeto iterativo. A captura de casos de uso é uma das tarefas básicas na fase de elaboração.

A maioria dos seus casos de uso será gerada durante está fase do projeto, mas você descobrirá mais a medida que avança. Fique alerta a eles o tempo todo. Cada caso de uso é um requisito em potencial, e até que você tenha capturado um requisito, você não pode planejar como lidar com ele.

Algumas pessoas, primeiro, listam e discutem os casos de uso, então fazem um pouco de modelagem. Também descobri que, fazendo modelagem conceitual com os usuários, ajuda a revelar casos de uso. Portanto, tendemos a fazer casos de uso e modelagem conceitual ao mesmo tempo.

E importante lembrar que casos de uso representam uma visão externa do sistema. Como tal, não espere nenhuma correlação entre eles e classes dentro do sistema.

Quantos casos de uso você deve ter? Não existe uma resposta exata para isto. Depende do tamanho do sistema e também dependerá da equipe e tipo de sistema que está sendo feito. Lembre-se que você terá vários cenários e que em cada cenário podem existir vários casos de uso e um caso de uso pode ter casos alternativos. Com isto você já viu que o número de casos de uso será medido pelo seu bom senso de modelagem e que você deverá fazer quantos achar necessário para levantar todos os requisitos. Não tem um número e nem uma fórmula para calcular isto.

28


Exemplos de descrição textual

Abaixo você tem dois exemplos de descrição textual para use-cases.

Use Case: Criar repositório para material

Atores: - Gerente

Cenário principal de Sucesso ( Perfeito ):

1 - Gerente fornece usuário e senha para login2 - Sistema valida usuário e senha3 - Sistema redireciona Gerente para sua página home4 - Gerente seleciona no menu a opção para criar repositório5 - Sistema redireciona o Gerente para uma tela de criação do repositório6 - Gerente seleciona em uma lista o curso para o qual quer criar repositório7 - Gerente seleciona em uma lista de instrutores habilitados o responsável pelo material8 - Gerente informa data prevista de entrega para o material9 - Gerente confirma a criação do repositório10 - Sistema valida os dados da interface fornecidos pelo Gerente11 - Sistema envia email para o Instrutor comunicando que o repositório foi criado

Cenários alternativos ( Exceções ):

2a: Sistema não consegue validar usuário e senha:1 - Sistema avisa o Gerente através de uma mensagem na tela e solicita

novamente o login e senha para novamente validar. Validar no máximo 3 vezes o usuário e senha. Se não for possível validar então bloquear a conta deste usuário.

10a: Erro ao validar dados da tela, falta preencher campos ou as informações estão em formato incorreto.

1 - Sistema sinaliza o campo com problema e solicita correção.

29


Use Case: Entrega do material didático

Atores: - Instrutor

Cenário principal de Sucesso ( Perfeito ):

1 - Instrutor acessa o sistema com seu usuário e senha2 - Sistema valida o usuário do Instrutor e redireciona para uma página home3 - Instrutor seleciona o link para envio do material didático no menú do sistema4 - Instrutor fornece os arquivos que fazem parte do material didático em um formulário para seleção de arquivos5 - Sistema recebe os arquivos e os salva no repositório do banco de dados6 - Sistema confirma para o Instrutor de que o envio foi feito com sucesso7 - Sistema envia uma confirmação por email para o Instrutor informando da entrega8 - Sistema envia um aviso por email para o Gerente de que o material foi entregue

Cenários alternativos ( Exceções ):

2a: Sistema não consegue validar usuário e senha:1 - Sistema avisa o Instrutor através de uma mensagem na tela e solicita

novamente o login e senha para novamente validar. Validar no máximo 3 vezes o usuário e senha. Se não for possível validar então bloquear a conta deste usuário.

4a: Sistema detecta a falta de um ítem do material didatico. 1 - Sistema avisa qual ítem (apostila, slides, setup, instruções) falta e solicita ao Instrutor para fornecer este item. Se não houver este ítem o Instrutor deve sinalizar selecionando uma opção

30


Exercícios

1 – Brevemente descreba quais são os objetivos bem como em qual momento devemos utilizar o diagrama de use case.

2 – O texto abaixo é um descritivo para um sistema de controle de material didático em uma empresa de treinamento. Você deve ler o texto e montar um diagrama de use case que represente as funcionalidades bem como os papéis/atores que podem executar cada uma delas. Não se preocupe ainda com classes, estas serão levantadas e modeladas mais adiante. Dica: Não se detenha inicialmente nos tipos de relacionamentos entre os elementos, concentre-se nos use cases e no ator que pode executa-los, deixe para no final uma segunda passade de olhos para identificar possíveis relacionamentos.

Descrição do sistema:

Objetivo:

Desenvolver um sistema para controle de material didático dos cursos realizados em uma empresa de treinamento.

Perfis de usuários:

Gerente de Treinamento, Instrutores, Assistente Administrativo e Responsável pelo Suporte ao Treinamento.

Telas do sistema:

1) Criação do repositório para o material didático;2) Instrutor fornece a data prevista para entrega do material didático;3) Instrutor entrega material didático via o sistema;4) Instrutor solicita alteração do material didático;5) Manutenção do repositório: alteração do responsável pelo mesmo;6) Bloquear acesso de um usuário ao sistema.

Descrição da necessidade:

Fazem uso deste sistema instrutor, assistente administrativo, responsável pelo suporte ao treinamento e o gerente de treinamento da empresa. Os grupos de usuários devem acessar o mesmo a fim de alimentar e buscar informações sobre o material didático dos treinamentos. O gerente de

31


treinamento deve acessar o sistema (com usuário e senha) a fim de criar um repositório para o material didático de um determinado curso, o qual deverá ser fornecido por um instrutor. Todo curso da empresa terá um material didático e um instrutor responsável por ele. O material didático é composto por: arquivo texto compactado da apostila, arquivo compactado com os slides do curso, arquivo compactado com uma documentação relatando o tipo de equipamentos necessários para realizar o curso, softwares necessários bem como o procedimento de instalação dos mesmos nos respectivos equipamentos, arquivo compactado com o setup do curso (arquivos, scripts, imagens e informações de como deve ser instalado este setup em cada estação de trabalho dos alunos). A criação de um repositório para o material didático de um curso será feita pelo gerente de forma que o instrutor possa acessar o sistema e enviar os arquivos que compõe este material didático. Existe uma checagem automática do sistema no momento que o instrutor está enviando os dados do material didático para que o mesmo forneça ao menos o arquivo da apostila, os slides do curso e o documento de configuração do ambiente contendo os equipamentos e procedimentos necessários para instalação dos softwares. Caso o instrutor não forneça estes três arquivos mencionados acima, será avisado pelo sistema na hora do envio e o procedimento será cancelado. Aqueles itens que não fizerem parte do material didático de um curso devem ser marcados na hora de submeter o material pelo instrutor como não existente para aquele curso. O instrutor ao acessar o sistema visualizará uma lista de cursos dos quais ele é o responsável pelo material didático, bem como um indicativo de quais itens deste material didático já foram entregues e quais ainda faltam. Uma vez submetido, caso seja necessário atualizar ou alterar algum dos itens do material, o instrutor deverá solicitar ao gerente que libere o acesso para alteração do mesmo, uma vez que logo após os arquivos serem enviados o material didático será bloqueado para alteração e isto será possível somente através da liberação do gerente. Quando for feita esta solicitação para alteração do material didático, o instrutor deverá fornecer uma nova data prevista de entrega do mesmo, bem como deverá ser informado o motivo da alteração. O motivo será julgado pelo gerente que irá decidir se libera ou não o acesso ao material. Isto é feito por questão de segurança e também para controle de versões de apostilas a fim de evitar que pequenas alterações gerem uma nova versão sem necessidade. Todo o material que for entregue provocará um arquivamento a título de histórico da versão anterior do mesmo, bem como irá disparar um aviso ao assistente administrativo de que o material deve ser substituído na gráfica para impressão. Neste módulo de interação com o usuário o sistema também deve permitir que o instrutor possa sugerir nomes de cursos a serem montados sendo que estes serão recebidos e avaliados pelo gerente de treinamento. No momento de criação do repositório para o material didático deverá ser definida uma data prevista para entrega do material. Uma vez fornecida a data o instrutor não mais poderá alterá-la. O sistema deverá possuir um mecanismo de alertas para que o instrutor seja lembrado com 15 e 5 dias de antecedência da entrega do material didático do curso. Sempre no momento de criação de um repositório para material didático de um curso, o instrutor deve ser alertado pelo sistema de que o mesmo foi criado.

32


O gerente de treinamentos deverá acessar o sistema e terá a sua disposição as seguintes funções: criar repositório para o material didático de um determinado curso, adicionar instrutor, assistente administrativo e responsável pelo suporte ao sistema, liberar acesso ao material didático para um determinado instrutor, definir o modelo de material didático para os cursos, transferir a propriedade de um material didático de curso de um instrutor para o outro, verificar materiais didáticos de cursos que foram entregues pelos instrutores, emitir relatórios diversos (listados mais abaixo) e bloquear acesso de um instrutor ao sistema.

Funções disponíveis para o gerente do sistema:

Criar repositório para setup: cada curso possui um material didático e o sistema deverá permitir ao gerente criar o repositório para o mesmo, remover ou trocar a propriedade deste material didático. O material didático é composto por uma série de elementos citados anteriormente e que devem ser fornecidos pelo instrutor quando o mesmo acessar o sistema para enviar o material.

Manter instrutores, assistente administrativo e responsável pelo suporte aos laboratórios no sistema: deverá ser possível criar, deletar e alterar contas destes perfis. Os usuários podem querer atualizar o seu endereço de e-mail ou telefone.

Enviar modelo de material didático para o instrutor: o sistema deverá ser capaz de permitir com que o gerente possa liberar o material didático de modelo do curso para o instrutor fazer o download do mesmo.

Definir o modelo de material didático para os cursos: o gerente pode adicionar ao sistema um modelo de material didático para os cursos da empresa.

Verificar materiais didáticos entregues: ao acessar o sistema o gerente irá visualizar os últimos materiais didáticos de cursos que foram submetidos pelos instrutores os quais necessitam ser revisados para uma possível aprovação. Logo após a ação do gerente o sistema deve mandar um e-mail para o instrutor informando se o mesmo foi ou não aprovado. Caso não tenha sido aprovado consta no e-mail o motivo da rejeição.

Emitir relatórios: o gerente pode emitir os seguintes relatórios:1. listagem de cursos com o material didático aprovado;2. listagem de cursos com o material didático não aprovado e

que estejam sendo aguardados;3. listagem de instrutores com os seus respectivos cursos;4. listagem dos últimos materiais didáticos alterados em lista

cronológica inversa.

33


Bloquear acesso de um usuário: poderá ser bloqueado o acesso de um usuário (instrutor, assistente administrativo ou responsável pelo suporte ao treinamento) ao sistema, a fim de garantir segurança do mesmo. Isto deve acontecer mais freqüentemente para instrutores pois estes tem mais rotatividade.

No momento de cadastro de um instrutor devem ser fornecido os seguintes dados do mesmo: nome completo, telefones de contato, e-mail, área de atuação. Os mesmos dados devem ser fornecidos quando for cadastrado os demais perfis do sistema.

34



35


3.3. Diagrama de AtividadesDiagrama de Atividades

1

Diagrama de Atividades

Objetivos

Compreender o diagrama de atividades


Aprender como desenvolver um diagrama de atividades

Saber quando utilizar o diagrama de atividades

2


Definição do diagrama

Conforme escrevi no capítulo anterior, acredito que este diagrama pode ser utilizado logo depois de fazermos uso do diagrama de casos de uso. Nem sempre você fará um diagrama de atividades, isto irá depender da análise que você está fazendo, se você de fato julgar necessário representar alguma atividade que esteja envolvida no sistema e que irá lhe ajudar a entender e documentar alguma parte importante, este diagrama será útil.

Diagramas de atividades são uma das partes mais inesperadas de UML. Ao contrário da maioria das outras técnicas da UML, diagramas de atividades não têm origens claras nos trabalhos anteriores dos três amigos. Ao contrário, o diagrama de atividades combina idéias de várias técnicas: os diagramas de eventos de Jim Odell, técnicas de modelagem de estado SDL, modelagem de workflow e redes de Petri. Estes diagramas são particularmente úteis em conexão com workflow e na descrição de comportamento que tem muito processamento em paralelo.

Um diagrama de atividades é um caso especial do diagrama de estados no qual todos (ou pelo menos a maioria) os estados são ações ou subatividades e no qual todas (ou pelo menos a maioria) as transições são disparadas pela conclusão de ações ou subatividaes nos estados de origem. Este diagrama tem por propósito focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um período de tempo.

3


Elementos do diagrama

Neste item iremos estudar os elementos que compõe o diagrama de atividades para depois construir um diagrama. Os elementos são simples e fáceis de representar. Você perceberá que muitos deles são parecidos com aqueles que você estava acostumado a utilizar nos fluxogramas.

4


Atividade

Na figura abaixo se pode ver o símbolo de uma atividade, este símbolo é o estado de atividade, ou simplesmente atividade. Uma atividade é um estado de estar fazendo algo: tanto um processo de mundo real, tal como datilografar uma carta, ou a execução de uma rotina de software, tal como um método em uma classe.

Figura 3-1: Representação da atividade

O diagrama de atividades descreve a seqüência de atividades, com suporte para comportamento condicional e paralelo. Um diagrama de atividades é uma variante de um diagrama de estados no qual a maioria, se não todos, dos estados é estado de atividade. Portanto, muito da terminologia segue a mesma terminologia de diagrama de estados.

5


Início do diagrama

O início do diagrama de atividades é marcado com um sinal de um círculo preenchido. Este símbolo é o mesmo para o diagrama de estados. Veja abaixo o símbolo gráfico:

Figura 3-2: Representação gráfica do início do diagrama de atividades

6


Fim do diagrama

Assim como para indicar o início do diagrama de atividades há um símbolo para indicar o fim deste diagrama e este símbolo é utilizado tanto para o diagrama de atividades como para o diagrama de estados. A representação é um cículo preenchido com um circulo contornando o mesmo. Veja abaixo o símbolo gráfico:

Figura 3-3: Representação gráfica do fim do diagrama de atividades

7


Transições

Para ligar as atividades e indicar a seqüência utilizamos flexas que representam as transições entre as atividades bem como a transição entre o início e a primeira atividade, bem como das atividades para o fim do diagrama. Veja abaixo a representação gráfica juntamente com outros itens do diagrama.

Figura 3-4: Representação gráfica das transições no diagrama de atividades

8


Desvios

Comportamento condicional é delineado por desvios (branches) e intercalações (merges).

Um desvio (branch) é uma transição de entrada única e várias transições de saída guardadas. Somente uma transição de saída pode ser tomada, de modo que os guardas devem ser mutuamente exclusivos. A utilização de [else] como um guarda indica que a transição "else" deverá ser usada se todos os outros guardas do desvio forem falsos. Veja na figura abaixo a representação gráfica de um desvio (branch):

Figura 3-5: Representação gráfica de um desvio (branch)

9


Uma intercalação (merge) tem múltiplas transições de entrada e uma única saída. Um merge marca o final de um comportamento condicional iniciado por um branch. Veja abaixo a representação gráfica:

Figura 3-6: Representação gráfica de uma intercalação (merge)

Você não precisa mostrar explicitamente o losango para desvios e intercalações. Um estado de atividade, como qualquer estado, pode ter múltiplas transições de saída guardadas e múltiplas transições de entrada. Use o losango se você quiser deixar claros os desvios e as intercalates em um diagrama.

Abaixo temos outro exemplo de um diagrama de atividades completo para representar a atividade de entrega de um material didático.

10


Figura 3-7: Diagrama de atividades para entrega de um material didático

11


Separação e União

Comportamento paralelo é indicado por separação (Forks) e uniões (Joins). Iremos agora ver este tipo de elemento pertencente ao diagrama de atividades.

Uma separação (Fork) tem uma transição de entrada e várias transições de saída. Quando uma transição de entrada é acionada (triggered), todas as transições de saída são executadas em paralelo. Veja o diagrama abaixo:

Figura 3-8: Representação de Fork e Join

O diagrama mostra que as atividades de “Carregar texto” e “Exibindo texto” podem ocorrer em paralelo. Essencialmente, isso significa que a seqüência entre elas é irrelevante. Essas atividades também podem ser executadas intercaladamente. Por exemplo, uma parte do texto é carregada e então é exibida, depois carrega-se outra parte do texto a a exibe. Também estas atividades podem acontecer em paralelo, de forma que as duas serão executadas exatamente ao mesmo tempo, mas sabemos que para este

12


exemplo dado acima isto não é possível. Não podemos carregar e ao mesmo tempo exibir as informações.

O diagrama de atividades permite que você escolha a ordem em que faz as coisas. Em outras palavras, ele simplesmente determina as regras essenciais de seqüência que você deve seguir. Esta é a diferença-chave entre um diagrama de atividades e um fluxograma: os fluxogramas são normalmente limitados a processos sequenciais, enquanto que os diagramas de atividades podem lidar com processos paralelos.

Isso é importante para modelagem de negócios. Os negócios tem, frequentemente, processos não necessariamente seqüenciais. Uma técnica como esta que encoraja comportamento paralelo é valiosa nestas situações porque ela encoraja as pessoas a se afastarem de seqüencias desnecessarias nos seus comportamentos e a identificar oportunidades para fazer coisas em paralelo. Isso pode melhorar a eficiência e o retorno de processos de negócio.

Os diagramas de atividades também são úteis para programas concorrentes, uma vez que você pode projetar graficamente quais caminhos (threads) você tem e quando eles precisam ser sincronizados. Quando você tem comportamento paralelo, precisa sincronizar. Não podemos liberar a edição do arquivo até que ele seja completamente carregado. Mostramos isso com a união (join) antes da atividade “Liberar edição do arquivo”.

Com a união (join), a transição seguinte é efetuada somente quando todos os estados nas transições de entrada tenham completado suas atividades.

Separação e união devem se completar. No caso mais simples, isso significa que toda vez que você tiver uma separação, deve ter uma união que una os threads iniciadas por aquelas separações. (Esta regra vem do fato de que um diagrama de atividades é, atualmente, uma forma de diagrama de estados).

Entretanto, existem várias extenções para esta regra.

Um thread que sai de uma separação pode abrir-se em uma nova separação, com os novos threads juntando-se antes de alcançar a união da primeira separação.

Se um thread saindo de uma separação vai direto para outra separação, você pode remover a segunda separação e somente ter os threads da segunda separação saindo da primeira separação. De modo semelhante, se uma união vai direto para uma outra união, você pode eliminar a primeira união e ter as threads indo direto para a segunda. Isso é uma forma de simplificar o diagrama; ela tem o mesmo significado semântico como se as separações e uniões extras estivessem lá.

13


Existe uma exceção para a regra de que todos os estados de entrada em uma união devem ter terminado suas atividades, antes que a união possa ser efetuada. Você pode acrescentar uma condição para um thread saindo de uma separação. O resultado é um thread condicional. Durante a execução, se a condição de um thread condicional for falsa, este thread e considerado completado no que diz respeito a união. Veja na figura abaixo um exemplo:

Figura 3-9: Representação de uma thread que pode não ser realizada

14


Estado de subatividade

Um estado de subatividade indica que quando este é iniciado, o gráfico de atividade aninhado a ele é executado como um gráfico de atividade independente. O estado de subatividade não é finalizado até que o estado final do gráfico aninhado seja alcançado, ou quando eventos disparadores ocorrem em transições vindas de fora do estado de subatividade. Visto que estados em gráficos de atividade não tem normalmente eventos disparadores, estados de subatividade são normalmente finalizados quando seus gráficos aninhados são terminados. Um gráfico de atividade simples pode ser invocado por muitos estados de subatividades.

Um estado de subatividade é mostrado graficamente da mesmo forma que um estado de ação, adicionando apenas um ícone no canto direito inferior representado um diagrama de atividades aninhado. O nome da subatividade é colocado dentro da figura. A subatividade não necessita ser única dentro do diagrama.

Figura 3-10: Representação de um estado de subatividade

15


Concorrência Dinâmica

Concorrência dinâmica permite que você mostre interações sem que tenha que construir um ciclo (loop). Na figura abaixo, a atividade gravar arquivo é executada uma vez para cada arquivo recebido. O marcador de multiplicidade (*) indica que a atividade é executada muitas vezes. A transição para Bloquear material didático é executado somente quando todos os arquivos tiverem sido gravados.

Figura 3-11: Representação de uma atividade concorrente

16


Raias (Swimlanes)

Os diagramas de atividades dizem o que acontece, mas não dizem quem faz o que. Em programação, isso significa que o diagrama não representa qual classe é responsavel para cada atividade.

Em modelagem de domíno, isso significa que o diagrama não representa que pessoas ou departamentos são responsáveis por cada atividade. Uma solução, aqui, é rotular cada atividade com a classe ou pessoa responsável. Isso funciona, mas não oferece a mesma clareza que os diagramas de interação (estudaremos mais tarde) para mostrar a comunicação entre objetos.

Raias são uma solução para isso. Para usar raias, você deve organizar seus diagramas de atividades em zonas verticais separadas por linhas. Cada zona representa as responsabilidades de uma classe especifica ou, um departamento específico.

As raias são úteis porque elas combinam a descrição de lógica do diagrama de atividades com a descrição de responsabilidade do diagrama de interação. Entretanto, elas podem ser difíceis de serem projetadas em um diagrama complexo. Veja abaixo a representação das rais.

Figura 3-12: Diagrama de atividade com raias

17


Quando Utilizar Diagramas de Atividades

Como a maioria das técnicas de modelagem comportamental, os diagramas de atividades tem qualidades e fraquezas definidas, por isso a melhor maneira de usá-los é em combinação com outras técnicas.

A maior qualidade dos diagramas de atividades está no fato de que eles suportam e encorajam comportamento paralelo. Isso os torna uma grande ferramenta para modelagem de workflow, e, em princípio, para programação concorrente. A maior desvantagem destes diagramas é que eles não deixam muito claras as ligações entre ações e objetos.

Você pode definir uma ligação para um objeto rotulando uma atividade com um nome de objeto ou usando raias que dividem um diagrama de atividades em base em responsabilidades, mas isso não tem a clareza simples de diagramas de interação (estudaremos estes diagramas mais adiante no curso). Por esta razão, algumas pessoas sentem que diagramas de atividades não são orientados a objetos e, portanto, são maus.

A técnica pode ser muito útil nas seguintes situações:

Analisando um caso de uso. Neste estágio, não estou interessado em alocar ações aos objetos; eu preciso simplesmente compreender que ações precisam acontecer e quais são as dependências comportamentais.

Compreendendo o workflow. Mesmo antes de iniciar os casos de uso, acredito que os diagramas de atividades são muito úteis para compreensão de um processo de negócio. Posso, facilmente, projetar estes diagramas junto com especialistas do negócio para compreender como o negócio funciona e como ele pode mudar.

Descrevendo um algoritmo seqüencial complicado. Neste caso, um diagrama de atividades não é nada mais do que um flowchart em notação UML. Os prós e contras comuns de flowcharts se aplicam aqui.

Lidando com aplicações de processamento paralelo. Este tipo de diagrama, como já foi mostrado pode ser utilizado para demonstrar atividades que devem ou podem acontecer em paralelo.

18


Não use diagramas de atividades nas seguintes situações:

Tentando ver como os objetos colaboram. Um diagrama de interação é mais simples e lhe dá uma visão mais clara das colaborações.

Tentando ver como um objeto se comporta durante o sen ciclo de vida. Use um diagrama de estados para isso (Estudaremos mais adiante no curso).

19


Exercícios

Utilizando a ferramenta para modelagem de diagramas UML faça:

1 – Para o diagrama de atividades da figura 18 monte um diagrama de atividades com raias destacando assim quais são os papeis que executam determinada atividade

2 – Construa um diagrama de atividades para descrever o processo de solicitação de autorização para uma revisão no material didático.

20



21


22


4.4. Diagrama de ClassesDiagrama de Classes

1

Diagrama de Classes

Objetivos


Estudar os tipos de associações que fazem parte deste diagrama

Saber utilizar o escopo e visibilidade para os atributos e operações

Aprender quando se deve utilizar este diagrama

Modelar um diagrama de classes

2

Diagrama de Classes

Introdução

Depois de termos estudado dois diagramas pertencentes à UML e que podem nos auxiliar no levantamento de requisitos bem como na descrição das principais atividades envolvidas no processo do software, vamos agora estudar o diagrama de classes. Este é um diagrama muito importante para a modelagem oriendada a objetos utilizando UML. Posso dizer que é obrigatória a sua modelagem em função do mesmo demostrar os componentes que fazem parte do software destacando as suas operações e atributos.

A técnica de diagrama de classes tornou-se realmente central nas metodologias orientadas a objetos. Praticamente, cada metodologia incluiu algumas variações nesta técnica. O diagrama de classes não é somente amplamente usado, mas também o receptáculo para o maior escopo de conceitos de modelagem. Embora os elementos básicos sejam necessários para todos, os conceitos avançados são utilizados com menos freqüência.

Um diagrama de classes descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. Há dois tipos principais de relacionamento estático:

associações (por exemplo, um cliente pode alugar vários vídeos)subtipos (uma enfermeira é um tipo de pessoa)

Diagramas de classes também mostram atributos e operações de uma classe e as restrições à maneira com que os objetos são conectados. Veja abaixo um exemplo de diagrama de classes que iremos estudar detalhadamente neste curso.

3

Diagrama de Classes

4

Diagrama de Classes

Figura 4-1: Representação típica de um diagrama de classes

5

Diagrama de Classes

Perspectivas

Antes de começar a descrever diagrama de classes, temos que mencionar uma sutileza importante no modo com que as pessoas os utilizam. Esta sutileza não é comumente documentada, mas tem um impacto na maneira que você deve interpretar um diagrama, pois se refere muito ao que você está descrevendo com o modelo.

Existem três perspectivas que você pode usar quando projetar diagramas de classes ou, de fato, qualquer modelo, mas esta classificação é mais perceptível em conexão com diagramas de classes.

Conceitual: Se tomar a perspectiva conceitual, você projeta um diagrama que representa os conceitos no domínio que está sendo estudado. Estes conceitos serão naturalmente relacionados às classes que vão executá-los, mas freqüentemente não existe um mapeamento direto. Na verdade, um modelo conceitual deve ser projetado com pouca ou nenhuma preocupação com o software que poderá implementá-lo, portanto ele pode ser considerado independente de linguagem.

Especificação: Agora estamos examinando o software, mas estamos analisando as suas interfaces, não a sua implementação. O desenvolvimento orientado a objeto põe muita ênfase na diferença entre interface e implementação, mas isto é freqüentemente negligenciado na prática porque a noção de classe em uma linguagem OO combina interface com implementação. É uma pena, porque a chave para uma programação OO eficaz é programar para uma interface de classe em vez de fazê-lo para sua implementação. Você ouve com freqüência a palavra "tipo" para falar sobre uma interface de uma classe; um tipo pode ter muitas classes que o implementam e uma classe pode implementar muitos tipos.

Implementação: Nesta visão, realmente, temos classes e estamos pondo a implementação às claras. Esta é, provavelmente, a perspectiva usada com mais freqüência, mas, de várias formas, a perspectiva de especificação é freqüentemente a melhor para ser usada.

A compreensão das diversas perspectivas é crucial tanto para desenhar como para ler diagramas de classes. Infelizmente, as linhas entre as perspectivas não são rígidas, e a maioria dos modeladores não se preocupa em ter suas perspectivas classificadas quando eles estão modelando. Embora

6

Diagrama de Classes

acredite que isso freqüentemente não afeta muito a perspectiva conceitual e a perspectiva de especificação, é muito importante separar a perspectiva de especificação e a perspectiva de implementação.

A perspectiva não é parte da UML formal, mas é considerada extremamente valiosa na modelagem e na revisão de modelos. UML pode ser usada com todas as três perspectivas. Ligando classes com um estereótipo (Iremos estudar mais adiante), você pode dar uma indicação da perspectiva. Você marca classes como <<classe de implementação>> para mostrar a perspectiva de implementação, e com <<tipo>> para as perspectivas de especificação e conceitual.

7

Diagrama de Classes

Criando Diagramas de Classe

O diagrama de classes é a estrela principal de um sistema orientado a objetos. Nesse diagrama é possível modelar detalhes das classes e seus relacionamentos. Também são visíveis outros elementos como interfaces e pacotes.

Diagramas de classes podem ser organizados dentro de pacotes, assim como um pacote (iremos estudar pacotes mais tarde) pode ser representado por um ou mais diagramas de classes.

As classes são declaradas no diagrama de classes mas são usadas em muitos outros diagramas. Uma classe é representada como um retângulo subdividido em três compartimentos, separados por linhas horizontais que nessa ordem armazenam:

o nome da classe e outras propriedades gerais da mesma, incluindo estereótipos;lista de atributos;Lista de operações.

Essa divisão corresponde à notação básica dos diagramas de classes. Entretanto, compartimentos adicionais (não definidos pela UML) podem ser incluídos e usados como extensões das ferramentas de modelagem, com o intuito de exibir outras informações do modelo, como por exemplo: regras de negócio, responsabilidades, exceções, etc. A maior parte desses compartimentos exibem apenas uma lista de strings, entretanto são possíveis outros formatos definidos pelas ferramentas.

Figura 4-2: Representação de classe

8

Diagrama de Classes

As normas de estilo da UML determinam que:

o nome da classe seja centralizado e negritadopara todas as linguagens que distinguem entre caracteres minúsculos e maiúsculos, escrever as iniciais dos nomes das classes em maiúsculas, inclusive as primeiras letras de nomes compostos

Exemplo: AlunoUniversitario, PessoaFisica, Funcionário, Gerente, Carro, Curso, Instrutor

os atributos e operações devem ser escritos com formatação normal e alinhados à esquerdaos nomes de atributos e operações devem iniciar com letra minúscula, entretanto as iniciais das palavras compostas seguintes devem iniciar com letra maiúscula

Exemplo: reajustarSalario, matricular, dataNascimento

Como extensão de ferramentas, o negrito pode ser usado para marcar listas especiais de elementos.

As normas de estilo da UML são importantes para a padronização da notação da linguagem. Entretanto, às vezes, é comum compatibilizarmos as normas de estilo da UML com as normas da linguagem com a qual estamos trabalhando.

A linguagem java, por exemplo, segue o padrão de nomes de classes e atributos especificado na UML. Os nomes de métodos são somente modificados de forma a termos a palavra get e set na frente de alguns deles. Isto é dependente da linguagem de programação e por isto não será estudado neste curso.

Se necessário, compartimentos podem ser nomeados, cujos nomes devem ser representados com uma fonte diferente, centralizados no topo do compartimento.

Figura 4-3: Classe com seus compartimentos nomeados

9

Diagrama de Classes

A UML permite que em algumas visualizações os detalhes sejam omitidos, isto é, é possível mostrar:

apenas o nome da classe ouo nome da classe e seus atributos ouo nome da classe e suas operações

O nome da classe é obrigatório não podemos representar uma classe sem nome, mas perceba que podemos representar sem atributos e operações.

A grande maioria dos processos de modelagem recomendará que, no primeiro diagrama de classes desenhado, não façamos o registro de todos os detalhes das classes. Na realidade, a identificação das classes e seu detalhamento ocorre gradativamente. No processo de desenvolvimento, deve-se levar em conta que a versão do diagrama usada na fase de projeto estará mais completa.

10

Diagrama de Classes

Compartimento do Nome da Classe

O compartimento de nome mostra o nome da classe e outras propriedades divididas em três seções, contendo as informações conforme descritas a seguir:

Estereótipos podem ser escritos em estilo normal dentro de guillemets (<< >>) acima do nome da classe, e/ou um ícone estereótipo pode ser colocando no canto superior direito do compartimento. Exemplo: <<type>>;O nome da classe aparece em seguida, centralizado e em negrito (única informação obrigatória);Uma lista de strings indicando propriedades como atributos a nível de classe e valores de etiqueta são mostrados abaixo do nome da classe, entre chaves.

Exemplo: { versão = 1.2 }

Figura 4-4: Classe com informações no compartimento de nome

11

Diagrama de Classes

Atributos

Ao definirmos atributos não informamos apenas seu nome ou tipo de dados. Podemos determinar, também, seu valor inicial, visibilidade e outras características. A única informação obrigatória é o próprio nome do atributo, mas conforme a modelagem é refinada, outras características do atributo tornam-se importantes para o projeto.

A sintaxe default para a definição de atributos é:

visibilidade nome: tipo [ multiplicidade ordering] = valor-inicial {string-propriedade}

A visibilidade pode ser representada pelas palavras-chaves public, protected, private ou package (ou por seus ícones +, #, -, ~).

Por exemplo:

private senha: String + tamanho: int

O tipo do atributo pode corresponder ao nome de uma classe ou ser um tipo dependente da linguagem de programação a ser adotada (String acima é uma classe pois está com a primeira letra maiúscula, já int é um tipo pertencente a linguagem java). Na maior parte das vezes os atributos corresponderão a tipos básicos (int, float, boolean). Mas, também podemos associar tipos definidos pela linguagem de implementação, como por exemplo Date, Vector, String em Java.

Outra forma de definir o tipo de um atributo é associá-lo a tipos não-básicos, como uma classe. Por exemplo: um livro pertence a uma editora. Este relacionamento pode aparecer de duas formas: a primeira consiste numa associação entre as classes Livro e Editora; a segunda seria colocar um atributo editora do tipo classe Editora, na classe Livro. Esta última forma permite um mapeamento direto para as bases de dados, ou seja, é mais usada na fase de projeto.

Por exemplo:

editora: Editora

12

Diagrama de Classes

A multiplicidade pode ser omitida se corresponder a exatamente 1 (1..1). Em outros casos pode ser representada dentro de colchetes.

Por exemplo:

telefones: String [0..5]filhos: Filhos [0..*]

O primeiro exemplo nos diz que uma determinada classe não tem valor para o atributo telefone ou tem até cinco valores. No segundo exemplo, temos que uma determinada classe tem de um a três filhos.

A propriedade ordering é relevante se o limite superior da multiplicidade for superior a 1. Nesse caso, o atributo pode assumir os valores: unordered (valor também assumido quando a propriedade está ausente) ou ordered, respectivamente significando que não possuem ou que possuem ordenação. Por exemplo: vamos supor uma classe CorredorFormula1 que possua um atributo campeonatos que contenha a lista de temporadas (anos) nos quais ele foi campeão da Fórmula1. Esse atributo poderia ser modelado da seguinte forma:

campeonatos: integer [0..* ordering]

que indicaria que um piloto pode nunca ter sido campeão ou já ter sido campeão de vários (*) campeonatos, sendo que essa lista de anos deve aparecer ordenada cronologicamente.

O valor-inicial determina o valor inicial do atributo no momento em que o objeto é instanciado.

Por exemplo:

salario: float = 1350.40nota1: float = 0

A string-propriedade indica valores de propriedades que se aplicam ao atributo, como:

changeable: o valor do atributo pode ser modificado, sem restrições. Corresponde ao default, se nenhuma propriedade for informada.addOnly: no caso de multiplicidades superiores a 1, indica que podem ser incluídas novas instâncias, porém estas não podem ser alteradas ou excluídas.frozen: após o instanciamento do objeto, o valor do atributo não poderá ser modificado.

13

Diagrama de Classes

Por exemplo:

identificacaoCliente: int {frozen }feriasGozadas: String [0..*] {addOnly}

No último caso, o atributo feriasGozadas armazena a lista de períodos de férias já gozadas pelo funcionário. Mas uma vez cadastrada essa informação, não deve ser possível alterá-la.

O escopo (visto anteriormente) default corresponde a um atributo de instância. Para representar um atributo de classe deve-se sublinhar o nome e o tipo do atributo.

Por exemplo:

Figura 4-5: Classe com um atributo de classe

Temos, ainda, a representação de atributo derivado. Um atributo derivado é aquele cujo valor é computado a partir de outro(s) atributo(s). Por ser um valor sempre gerado não teria necessidade de aparecer em forma de atributo. Todavia sua exibição no diagrama é feita com o intuito de melhorar o entendimento do modelo ou por propósitos de projeto.

Indica-se graficamente que um atributo é derivado inserindo-se uma barra (/) à frente do nome do atributo.

Veja por exemplo: a classe BoletimEscolar possui, entre outros, os atributos: nota1 e nota2. Sabemos que a média é calculada pela divisão por dois do resultado da soma das notas 1 e 2. Então, para obter a média, basta que tenhamos as notas 1 e 2. Todavia, deixar essa informação implícita pode levar a falhas no entendimento do modelo. Assim, modela-se o atributo média, mas determinando que sua atualização é feita por uma operação de cálculo e não por uma atribuição, como ocorre com os outros atributos. Veja o exemplo na figura abaixo:

14

Diagrama de Classes

Figura 4-6: Classe com atributo derivado

Podemos especificar a forma de cálculo de um atributo derivado, fazendo uso de uma nota ligada ao nome do atributo. Veja o exemplo abaixo:

Figura 4-7: Descrição para atributo derivado

15

Diagrama de Classes

Operações

Da mesma forma que ocorre com os atributos, a modelagem das operações não se limita a seu nome e parâmetros. A única informação obrigatória é o próprio nome da operação, mas conforme a modelagem é refinada, outras características da operação tornam-se importantes para o projeto.

A sintaxe default para a definição de operações é:

visibilidade nome (lista-de-parâmetros): tipo-de-retorno {string-propriedade}

A visibilidade pode ser representada pelas palavras-chaves public, protected private ou package (ou por seus ícones +, #, -, ~).

Por exemplo:

private obterSenha: String+ modificarTamanho (t: int)

A lista-de-parâmetros corresponde a uma lista de parâmetros separada por vírgula, no qual cada parâmetro deve obedecer a seguinte sintaxe:

escopo-parâmetro nome: tipo = valor-default

O escopo-parâmetro pode assumir os valores:

in: o parâmetro é apenas de entrada, não aceitando modificação.out: parâmetro apenas de saída, não aceitando leitura.inout: parâmetro de entrada e saída. Aceita leitura e modificação (default no caso do escopo ser omitido).

O tipo do parâmetro também é dependente da linguagem de programação. No caso da linguagem Java todo os parâmetros que forem do tipo primitivo (exemplo: int, float, boolean, etc.) terão escopo in e todos aqueles que forem do tipo composto (exemplo: String, Date, Vector, etc.) serão do tipo inout. Não há, no java, mapeamento para o escopo out.

O valor-default indica um valor que será considerado, caso nenhum valor seja passado para o parâmetro.

Por exemplo:

calcularMedia(tipo: TipoMedia = Aritmética)

16

Diagrama de Classes

O tipo-de-retorno da operação é dependente da linguagem de programação a ser adotada. Se nenhum retorno for especificado, estamos declarando uma operação que não possui retorno (estes conceitos são análogos a funções e procedimentos). Existem linguagens com o Java que mesmo quando uma operação não possui retorno nos precisamos indicar o retorno como sendo void.

O escopo default corresponde a uma operação de instância. Para representar uma operação de classe deve-se sublinhar o nome e o tipo de retomo da operação. Por exemplo, a operação emitirListaFrequencia() possui escopo de classe:

Figura 4-8: Operações com escopo de classe

A string-propriedade indica valores de propriedades que se aplicam à operação. As semânticas de concorrência (usadas em processos e threads) de uma operação são especificadas por uma propriedade no formato:

{concorrência = nome}

O nome da concorrência pode assumir os seguintes valores: sequential, guarded, concurrent. Vejamos, então, as propriedades usadas:

query: indica que a execução da operação não modifica o estado do objeto. Por exemplo: ao chamarmos a operação emitirListaFrequencia(), não realizamos qualquer alteração nos dados armazenados. Isto já não ocorre com a operação reajustarMensalidade que poderíamos ter na classe.sequential: a chamada para um objeto precisa ocorrer imediatamente, de forma completa e perfeita. Se ocorrerem chamadas simultâneas, a semântica e integridade do sistema não podem ser garantidas.guarded: múltiplas chamadas de threads concorrentes podem ocorrer simultaneamente para um objeto, mas somente é permitida a uma delas iniciar. As outras são bloqueadas até que a execução da primeira operação esteja completa. Essa responsabilidade pertence ao projetista do sistema, que deve assegurar que deadlocks não ocorram devido a blocos simultâneos.

17

Diagrama de Classes

concurrent: múltiplas chamadas de threads concorrentes podem ocorrer simultaneamente para um objeto. Todas precisam ser executadas concorrentemente, mantendo correta sua semântica.

Existe uma diferença entre operação e método que necessita ser relembrada. Uma operação corresponde à definição conceitual do serviço de uma classe, enquanto que o método corresponde à implementação da operação.

Por default, uma operação é considerada como não-abstrata, o que significa que obrigatoriamente deve ter um método que a implemente. Para indicar que a classe não implementa a operação, esta deve ser marcada como {abstract} (iremos estudar mais adiante as classes abstratas) ou a assinatura da operação ser escrita em itálico.

O corpo de um método pode ser mostrado no diagrama de classes por meio de uma nota ligada à operação. Especificações formais, expressas em qualquer linguagem, devem ser colocadas entre chaves. Desta forma na nota iremos colocar o código entre chaves. Perceba que este tipo de situação não é comum, e na maioria dos diagramas você não irá encontrar isto.

Outro conceito importante é quanto à assinatura da operação, que é composta do nome da operação, seus parâmetros e o tipo de retorno (se existir).

Quando não temos o interesse de demonstrar todas as operações iremos colocar no final da região das operações na representação da classe três pontinhos, mostrando que há mais operações porém estas não estão sendo mostradas.

18

Diagrama de Classes

Relacionamentos

As classes dentro do contexto da modelagem de um sistema, na sua maioria, não trabalham sozinhas. Pelo contrário, elas colaboram umas com as outras por meio de relacionamentos. No diagrama de classes temos os relacionamentos de associação, generalização e dependência. Como variação do relacionamento de associação, ainda é possível modelar relacionamentos de agregação e composição.

19

Diagrama de Classes

Associação

A associação é um relacionamento que conecta duas (associação binária) ou mais classes (associação ternária ou de ordem-n), demonstrando a colaboração entre as instâncias de classe.

A associação binária conecta exatamente duas classes, sendo possível a associação de uma classe com ela própria. Por exemplo: uma empresa possui diversos funcionários. Essa é uma associação entre as classes Empresa e Funcionário. De outra forma, um funcionário tem um chefe que também é um funcionário, portanto temos uma associação da classe Funcionário com ela própria. Veja a figura abaixo:

Figura 4-9: Associação entre classes

A associação binaria é representada grafícamente por uma linha sólida que liga uma classe a outra ou uma classe a ela própria.

Em UML, a associação pode ser de três tipos diferentes: associação simples; agregação por composição; agregação compartilhada. Visto que a construção de agregação pode ter diferentes significados dependendo da área de aplicação, a UML fornece um significado mais preciso para duas dessas construções (associação e agregação por composição) e deixa a agregação compartilhada mais livremente definida no meio das outras. Mais adiante veremos os conceitos de agregação e composição.

Uma associação pode conter adornos que melhoram, em alguns casos, a compreensão do modelo. Adornos são um tipo de esteriótipos (Veja sobre os tipos de adorno no apêndice). Todos esses adornos são opcionais e só devem ser usados quando sua função for plenamente atendida, para não poluir visualmente o diagrama de classes. Eles devem ajudar a modelagem, não complicá-la!

20

Diagrama de Classes

Nome da associação

É mostrado próximo à linha do relacionamento, todavia não se deve colocá-lo próximo às extremidades, pois estas posições pertencem aos nomes de papéis.

O nome da associação pode ser acompanhado de um pequeno triângulo preenchido indicando a direção na qual o nome deve ser lido. No exemplo abaixo o triângulo expressa a leitura da associação como "aluno cursa curso".

.Figura 4-10: Associação com nome

Para associações binárias, na sua maioria, não é preciso nomear as associações, pois elas já são auto-explicativas. O nome de associação é mais usado quando possa haver dúvidas sobre o tipo de associação ou nas associações que envolvem uma única classe. Já nas associações n-árias seu uso é mais freqüente. Veja na figura abaixo que usamos o nome pré-requisito para esclarecer o relacionamento: "Um curso é pré-requisito de outro curso".

Figura4-11: Nome para associação

21

Diagrama de Classes

Multiplicidade

Colocada nas extremidades do caminho da associação, identifica o número de instâncias de uma classe que pode se relacionar com outra. A mulplicidade especificada em uma extremidade determina que essa é a quantidade de instâncias da classe oposta que se relacionará na associação. Apesar de ser opcional, só deve ser omitida nas primeiras visões do diagrama. Uma vez que a modelagem avance, determinadas informações são relevantes para o projeto. Uma delas é a multiplicidade.

Por exemplo: Vamos considerar um curso que possa ter no máximo 10 alunos. Para representar este relacionamento iremos colocar as seguintes multiplicidades na associação:

Figura 4-12: Multiplicidade na associação

Se fossemos ler o relacionamento acima diríamos que um aluno pode estar matriculado em pelo menos um curso ou mais, não havendo limite de cursos. E ainda podemos dizer que um curso contém no máximo 10 alunos.

Se a multiplicidade da associação for superior a um, então os elementos relacionados podem ser ordenados ou não. Se não incluirmos nenhum adorno na associação, estaremos determinando que os elementos não são ordenados. Para determinar a ordenação deve-se incluir a string {ordered}. Essa declaração não especifica como a ordenação é realizada ou mantida. Essa é uma responsabilidade das operações que agem sobre as instâncias, demonstra somente que é ordenado os objetos dentro da coleção que irá conter os mesmos. Geralmente essa especificação é feita no projeto.

22

Diagrama de Classes

Papel (role)

Colocada nas extremidades do caminho da associação, indica o papel representado pela classe na associação (veja figura abaixo). Esse nome é colocado na extremidade do caminho da associação, próximo à classe a que se refere. De uma forma geral, o nome da classe já identifica o papel dela na associação, como por exemplo: Curso e Aluno. Todavia, quando temos classes que podem exercer vários papéis, a transparência diminui. Assim, o nome do papel passa a ser importante.

Figura 4-13: Papel execido pela classe no relacionamento

23

Diagrama de Classes

Navegabilidade

Uma seta pode ser colocada na extremidade de uma associação indicando que a navegação é determinada na direção para onde partiu a seta. As setas podem ser omitidas, colocadas em apenas uma das extremidades ou em ambas. A navegabilidade quando é omitida indica que a mesma é desconhecida ou bidirecional.

Se temos a classe Aluno e Curso sem navegabilidade, podemos dizer que a partir de aluno podemos saber o curso dele, e por outro lado, a partir de um determinado curso podemos saber quais são os alunos matriculados. Se indicássemos uma navegabilidade direcionada ao aluno, estaríamos dizendo que a partir de um aluno não deve ser implementada uma forma de saber seu curso. Claro que essa não é uma situação perfeita, pois é claro que precisamos saber o curso de um aluno. A "via de mão dupla" é mais comum na grande maioria dos relacionamentos de associação. Veja a figura abaixo uma situação onde o curso sabe quais são os alunos que tem nele mas os alunos não sabem a quais cursos eles pertencem.

Figura4-14: Associação com navegabilidade

Sabemos que um aluno precisa saber em quais cursos ele está matriculado, então não iremos em uamsituação real modelar com navegabilidade somente de Curso para Aluno, mas sim com navegabilidade para os dois lados. Quando a navegabilidade for para os dois lados, não precisamos colocar flexas nas extremidades da associação.

24

Diagrama de Classes

Herança/Generalização

Vamos recordar dos conceitos de orientação a objetos que você aprendeu no curso anterior: a generalização entre classes envolve elementos mais genéricos e outros mais específicos.

O relacionamento de generalização entre classes é mostrado graficamente como uma seta fechada e vazada, com seu corpo sólido, que parte da classe específica em direção à classe mais genérica. Veja abaixo a representação:

Figura 4-15: Primeira forma de relacionamento de Herança/Generalização entre as classes

25

Diagrama de Classes

Outra forma de representar a Herança/Gerneralização é mostrada abaixo:

Figura 4-16: Segunda forma de relacionamento de Herança/Generalização entre as classes

Restrições predefinidas podem ser usadas para indicar restrições semânticas entre as classes filhas. Essas restrições são colocadas entre chaves, separadas por vírgula e posicionadas próximas à seta do relacionamento. Uma forma alternativa consiste em colocar uma linha tracejada atravessando as linhas de relacionamento as quais se referem à restrição. A restrição, então, é colocada próxima à linha tracejada.

Duas restrições predefinidas para generalização são:

Completo (complete) - todas as subclasses de uma superclasse já foram especificadas (dentro do contexto do sistema), mesmo que algumas tenham sido omitidas no diagrama. Não é permitida nenhuma especialização adicional. Por exemplo:

Superclasse: PessoaSubclasses: Física e Jurídica

No caso da superclasse Pessoa, todas as subclasses já foram definidas e se outras subclasses fossem possíveis, não seriam permitidas suas inclusões.

Superclasse: FuncionárioSubclasses: Vendedor / Auxiliar Administrativo / Gerente

No foco do sistema, estes são os únicos funcionários existentes na empresa.

26

Diagrama de Classes

Figura 4-17: Representação de uma associação “completo”

Incompleto (incomplete) - determina que nem todas as subclasses possíveis foram especificadas no modelo, mas que essas inclusões ainda são permitidas. Por exemplo:

Modelando os animais de um zoológico. Mamífero e Ave não são os únicos animais, mas no momento a modelagem se restringiu a eles.

Superclasse: AnimalSubclasses: Mamífero / Ave

Supondo o contexto de um sistema acadêmico, percebemos que outras subclasses da Classe Pessoa podem surgir no futuro, como: Funcionário Administrativo, Monitor, etc.

Superclasse: PessoaSubclasses: Aluno e Professor

27

Diagrama de Classes

Figura 4-18: Incompleto

Para representar o polimorfismo, reescrevemos a operação na subclasse, ou seja, estamos redefinindo a operação. No exemplo da figura abaixo demonstramos o relacionamento entre as classes Funcionário, Professor e Vendedor. A classe Funcionário possui a operação calcularSalario() que realiza seu cálculo a partir de um salário base. No caso de Professor, a operação também existe, porém com um método (implementação) diferente - o cálculo é feito sobre hora-aula. O mesmo ocorre com o vendedor que possui um salário base mais uma comissão sobre as vendas. Desta forma, redefinimos as operações, permitindo que os métodos sejam implementados de maneiras diferentes.

Figura 4-19: Polimorfismo redefinindo uma operação

28

Diagrama de Classes

Dependência

O relacionamento de dependência entre duas classes indica que uma mudança na interface de uma delas pode causar mudanças na outra.

Existem vários fatores que levam à dependência entre classes. Vejamos alguns deles:

troca de mensagens entre classes (uma classe chama operações de outra)

Por exemplo: a classe ProdutoDB é uma classe que possui as operações para manutenção de produtos em uma tabela de produtos no banco de dados. Ela necessita da classe Conexao para para fazer este acesso ao banco de forma que a mesma irá chamar os métodos de abrir conexão, inserir, alterar, etc. que estão escritos em Conexao. Mudanças na interface dessa classe pode afetar a classe ProdutoDB. Assim, dizemos que a classe ProdutoDB é dependente da classe Conexao.

Figura 4-20: Relacionamento de dependência

uma classe tem como atributo outra classe

Por exemplo: uma classe Imóvel possui o atributo Proprietário que é uma instância da classe Proprietário.

Na assinatura de uma operação, uma classe aparece como parâmetro.

Por exemplo: Na classe Gôndola de um supermercado, vamos supor a existência da operação ReporProduto (produto_reposicao: Produto). Essa operação recebe por parâmetro uma instância da classe Produto.

Não representamos sempre todas as dependências, pois essas características citadas anteriormente já expressam o relacionamento.

29

Diagrama de Classes

Representamos o relacionamento de dependência apenas em casos que a mesma é implícita.

30

Diagrama de Classes

Agregação

A agregação corresponde a um caso particular da associação (apenas associações binárias), utilizada para expressar um relacionamento "todo-parte". A agregação representa uma propriedade fraca, pois uma classe "parte" pode estar contida em outras agregações.

Vamos primeiro discutir a agregação: quando definimos um relacionamento de associação, estabelecemos uma ligação entre as classes, mantendo a independência de vida das mesmas. No contexto de um Sistema Acadêmico, ao acabar com uma associação entre as classes Curso e Professor, as classes envolvidas continuam a ter vida própria, com pleno significado. Eu pergunto "o que é um curso dentro de um Sistema Acadêmico?" ou pergunto "O que é um professor dentro de um Sistema Acadêmico?". As respostas provavelmente serão objetivas e explicativas. Mais do que isso, curso pode ser definido sem depender da existência do professor e da mesma forma professor pode ser conceituado sem depender da existência do curso.

Agora, vamos pensar em uma página da Web. Uma página é composta (ou não) de imagens. Uma imagem também é parte de um diretório do Site. E se eu perguntasse "O que é uma imagem dentro de um Site?". Você poderia começar respondendo "é uma figura que ilustra uma página" ou "é uma figura que serve de link em uma página", etc.

Veja que a figura tem um significado que para ser completo está dependente de outro elemento. É como um verbo transitivo direto ou indireto. Se eu digo "você acorda", estou me referindo a um verbo intransitivo (que não pede complemento). Quem acorda, acorda e ponto final. Já se digo: "eu chamo", fica faltando alguma coisa. Quem chama, chama alguém. Paralelamente, uma imagem é uma imagem de alguém (ou algo). A página Web representa o todo enquanto que a imagem representa a parte. Portanto, nesse caso, podemos modelar o relacionamento entre Página Web e Imagem como uma agregação. Lembrem-se sempre de que o contexto interfere diretamente no tipo de relacionamento. Uma imagem não fará sempre parte de uma agregação - depende do contexto no qual ela está envolvida.

A representação gráfica da agregação consiste em se colocar um diamante aberto junto à classe agregadora.

31

Diagrama de Classes

Figura 4-21: Relacionamento de agregação

O relacionamento de agregação mostra que um objeto pode estar sendo referenciado por dois ou mais outros objetos. Na figura acima imagine que um objeto da classe PaginaWeb “morra” (não seja mais utilizado e pode ser coletado da memória pelos gerenciadores de memória das linguagens), desta forma o objeto imagem deve continuar lá e não será removido junto com a PaginaWeb.

32

Diagrama de Classes

Composição

A composição (ou agregação por composição) é uma variação mais poderosa da agregação. Passamos a interpretar o relacionamento como um objeto composto de partes. A diferença consiste no fato de que a classe parte pertence só e somente só à classe todo, em um determinado momento, não podendo fazer parte de outro relacionamento de composição. A classe composta é responsável pela criação e destruição de suas partes. Entende-se, assim, que uma vez que a classe composta deixe de existir, todas as suas partes morrem juntas. Observe que é justamento o contrário do relacionamenro de agregação mostrado acima onde as “partes” continuam a existir.

Ao definirmos uma classe como parte de uma composição, indicamos que no relacionamento essa classe perdeu sua identidade, pois é parte incorporada da outra classe.

Seguindo o exemplo do relacionamento de agregação, vamos pensar em um frame que representa uma tela de uma aplicação. Imagine que dentro desta tela temos um botão de pesquisar, perceba que este botão só estará dentro desta janela não irá estar presente em outras janelas (pelo menos o mesmo botão). Quando a janela for fechada (morrer) o botão será também morto, ou seja irá junto com a janela por fazer parte da estrutura da mesma. Temos, portanto, uma agregação mais forte: uma composição.Graficamente, é representada por um diamante preenchido junto à classe composta.

Figura 4-22: Relacionamento de composição

33

Diagrama de Classes

Pacotes de classes e colaborações no sistema

Uma das questões mais antigas nas metodologias de software é: como você quebra um sistema grande em sistemas pequenos? Fazemos esta pergunta porque à medida que os sistemas crescem, se torna difícil compreendê-los, bem como as mudanças que neles fazemos.

Métodos estruturados usam decomposição funcional, no qual todo o sistema foi mapeado como uma função e quebrado em sub-subfunções, que foram posteriormente quebradas em sub-subfunções e assim por diante. As funções eram como os casos de uso em um sistema orientado a objeto no qual as funções representavam algo que o sistema fazia como um todo.

Aquela era uma época em que o processo e os dados eram separados. Então, além da decomposição funcional, havia também a estrutura de dados. Isso assumiria um segundo plano, embora algumas técnicas de Engenharia de Informação agrupassem registros de dados em áreas de interesse e produzissem matrizes para mostrar como as funções e os registros de dados interagiam.

E deste ponto de vista que vemos a maior mudança que a orientação a objetos tem trazido. A separação entre processo e dados já era, a decomposição funcional já era, mas a velha questão ainda continua.

Uma idéia é agrupar as classes em unidades de nível mais alto. Esta idéia, aplicada de forma bastante livre, aparece em muitas metodologias orientadas a objetos. Em UML, este mecanismo de agrupamento é chamado pacote (package).

34

Diagrama de Classes

Pacotes

A idéia de um pacote pode ser aplicada a qualquer elemento do modelo, não somente a classes. Sem alguma heurística para agrupar as classes, o agrupamento se torna arbitrário. A dependência é a heurística que considero mais útil e mais enfatizada em UML.

Usamos o termo diagrama de pacotes para um diagrama que mostra pacotes de classes e as dependências entre eles. De modo restrito, um diagrama de pacotes é simplesmente um diagrama de classes que mostra apenas pacotes e dependências. Utilizamos muito estes diagramas, por isso chamamos de diagramas de pacotes, mas você deve lembrar que este é um termo não oficia, não um nome oficial de diagramas da UML

.Existe dependência entre dois elementos se mudanças na definição de

um elemento possam causar mudanças ao outro. Nas classes, as dependências existem por várias razões: uma classe manda uma mensagem para outra; uma classe tem outra como parte de seus dados; uma classe menciona uma outra como um parâmetro para uma operação. Se uma classe muda a sua interface, qualquer mensagem que ela mande pode não ser mais válida.

De forma ideal, apenas mudanças na interface de uma classe devem afetar qualquer outra. A arte de projetar em grande escala envolve minimização de dependências; desta forma, os efeitos da mudança são reduzidos, e o sistema requer menos esforço para mudar.

UML tem muitas variedades de dependência, cada uma com estereótipos e semântica particulares. É mais fácil começar com a dependência não-estereotipada e usar as dependências mais particulares somente se necessário.

35

Diagrama de Classes

Na figura abaixo você pode ver alguns pacotes e suas dependências.

Figura 4-23: Diagrama de pacotes

Há dependência entre dois pacotes se houver qualquer dependência entre quaisquer duas classes nos pacotes. Por exemplo, veja que o pacote “Gerenciador de Conexões com Banco de Dados” é um pacote muito utilizado pelos demais, todos ous outrs pacotes dependem dele. Desta forma uma alteração em classes deste pacote deve ser feito com muito cuidado pois pode projudicar as classes nos demais pacotes.

36

Diagrama de Classes

É possível também representar um relacionamento de generalização/herança entre os pacotes. Este tipo de relacionamento normalmente é utilizado quando temos um conjunto de classes em um pacote que são abstratas e devem ser utilizadas para que possamos criar outras classes a fim de as mesmas executarem algo. Imagine o exemplo dado anteriormente onde tínhamos um pacote com classes para conectar com o banco de dados, todas as classes que estavam naque pacote eram abrastratas e nós precisamos espcializar as mesmas e criar classes para fazer aquilo que nós de fato queremos fazer: conectar com oracle, postgreSQl, etc. Veja abaixo então como ficaria esta representação:

Figura 4-24: Diagrama de pacotes com generalização

37

Diagrama de Classes

Colaborações

Além de conter classes, um pacote pode conter colaborações. Uma colaboração é um nome dado à interação entre duas ou mais classes. Tipicamente, isso é uma interação, como descrito no diagrama de interação (este diagrama será vistomais adiante no curso). Vejamos uma pequena colaboração abaixo:

Figura 4-25: Colaboração entre classe para agendar um curso

Esta colaboração pode mostrar a implementação de uma operação ou a realização de um caso de uso. Você pode modelar a colaboração antes de decidir que operação a chama. Uma colaboração pode ser descrita com mais de um diagrama de interação, com cada um mostrando um caminho diferente. Você também pode mostrar um diagrama de classes para mostrar as classes que participam na colaboração conforme a figura acima.

38

Diagrama de Classes

Quando Utilizar Diagramas de Pacotes e Colaborações

Os pacotes são ferramentas vitais para projetos grandes. Utilize pacotes sempre que um diagrama de classes que compreenda todo o sistema não for mais legível numa única folha de papel tamanho A4.

Os pacotes são particularmente úteis para testes. Embora normalmente se escreve alguns testes em um fundamento de classe-por-classe, prefira fazer teste de unidade em um fundamento de pacote-por-pacote. Cada pacote deve ter uma ou mais classes de teste que testem o comportamento do pacote.

Considere colaborações úteis sempre que você quer se referir a uma interação particular ou mostrar uma pequena parte do diagrama de classes focando um objetivo final para uma relação entre classes.

39

Diagrama de Classes

Multiplicidade

Indica uma faixa de cardinalidade permitida a um elemento, isto é, a quantidade de instâncias possíveis em um relacionamento.

Por exemplo:

Numa classe Pessoa com o atributo cônjuge podemos afirmar (na nossa atual legislação) que sua multiplicidade é de no mínimo zero e no máximo um cônjuge (levando em conta o cônjuge atual).

Considerando uma classe Curso que se relacione com uma classe Aluno, podemos afirmar que para cada instância de Curso há um relacionamento com no mínimo zero e no máximo vários alunos; e para cada instância de Aluno há um relacionamento com no mínimo zero (a-luno está com a matrícula trancada) e no máximo vários cursos.

A multiplicidade consiste num subconjunto de um conjunto infinito de números inteiros não-negativos. A especificação da multiplicidade é mostrada como uma string compreendida numa seqüência de intervalos inteiros separados por vírgula, no qual um intervalo representa uma faixa de inteiros no formato:

limite-inferior.. limite-superior

Se a multiplicidade contiver um asterisco (*), significa que temos uma faixa infinita de números inteiros não-negativos. É equivalente a 0..* (zero ou mais). As multiplicidades mais comuns são:

• 0..1 (valor opcional)• 1 ou 1..1 (exatamente um)• * ou 0..* (qualquer valor inteiro não-negativo)• 1..* (qualquer valor inteiro positivo)

Exemplos de multiplicidades:

"1", "*", "0..1", "1..*", "1..5", "3, 5..7, 10..12"

Algumas normas de estilo devem ser usadas para multiplicidade, como:

os intervalos devem ser mostrados em ordem crescente.

Exemplo: Adequado: 2..5, 8, 10..15 Inadequado: 10..15, 2..5, 8

40

Diagrama de Classes

dois intervalos contíguos devem ser combinados num intervalo simples.

Exemplo: Adequado: 3..8 Inadequado: 3..5, 6..8

Figura4-26: Multiplicidade entre classes

41

Diagrama de Classes

Escopo

Vamos supor o objeto Funcionário com o atributo salário. Agora vejamos a seguinte situação: na empresa fictícia XYZ Ltda, instanciamos dois objetos a partir de uma classe Funcionário identificando-os como objetoP e objetoA, os quais representarão os funcionários Pedro e Augusto, respectivamente. Pedro recebe R$ 500,00 de salário enquanto que Augusto recebe R$ 2000,00. Se quisermos saber os salários desses funcionários, podemos nos referenciar da seguinte forma:

objetoP.salario e objetoA.salario

Veja que dependemos da individualidade do objeto para obtermos os salários corretos. Estamos diante do conceito de escopo de instância, que também pode ocorrer com as operações. Vamos levar em conta a operação gerarContraCheque. O resultado dessa operação será diferente para as seguintes chamadas:

objetoP. gerarContraCheque() e objetoA.gerarContraCheque()

A diferença será dada em função dos objetos terem salários diferentes, um possui R$ 500,00 e o outro R$ 2000,00. O contra-cheque gerado na primeira chamada apresentará os dados funcionais do funcionário Pedro, incluindo a demonstração de seus proventos e descontos. Já na segunda chamada, o contra-cheque apresentará os dados funcionais e demonstração de proventos e descontos do funcionário Augusto.

Isso significa que, ao definirmos o escopo de um atributo ou operação como sendo de instância, estamos dizendo que eles estão ligados à identidade do objeto, ou seja, pertencerão ao objeto.

Agora vamos pensar numa outra situação: vamos supor que os funcionários dessa empresa não possam ganhar menos que um determinado piso salarial, independente de seu cargo. Nesse caso, eu pergunto: piso salarial é um atributo que modifica seu valor se o funcionário for o Pedro, Augusto ou qualquer outro da empresa? Não. Isso significa dizer que esse atributo não está ligado à identidade do objeto e sim à coleção (conjunto) de funcionários da empresa. Está ligado à classe Funcionário. Dessa forma, supondo que a classe Funcionario seja identificada como Funcionario, a referência a esse atributo seria feita da seguinte forma:

42

Diagrama de Classes

Funcionario.pisoSalarial

Obteríamos o mesmo resultado, acessando objetoP.pisoSalarial ou objetoA.pisoSalarial. A diferença é que no primeiro caso, não é preciso instanciar um objeto. Imaginem criar um objeto só para saber o valor de um atributo público!

O mesmo ocorreria com uma operação chamada emitirFolhaPagamento. O resultado dessa operação é a folha de pagamento mensal contendo todos os funcionários. Desta forma não importa chamá-la a partir de um único funcionário, pois seu processamento será sempre sobre o conjunto de funcionários, independente de quem ou quantos sejam.

Funcionario.emitirFolhaPagamento()

Estes dois últimos casos ilustram o conceito de escopo de classe. Assim é comum dizermos que estamos definindo um atributo de classe ou uma operação de classe.

A UML determina que o escopo de classe seja representado sublinhando-se o elemento. Você pode encontrar representações diferentes em algumas ferramentas, como por exemplo colocar à frente do elemento, um sinal de dólar ($) - notação usada em versões mais antigas.

Figura 4-27: Operações com escopo de classe

43

Diagrama de Classes

Classes de Associação

Classes de associação permitem que você acrescente atributos, operações e outras características às associações, como mostrado na figura abaixo.

Figura 4-28: Representação de uma classe de associação

Você pode ver pelo diagrama que uma Pessoa pode trabalhar para uma única Companhia. Suponhamos que necessitamos manter informação sobre o período de tempo que cada funcionário trabalha para cada Companhia.

Podemos fazer isso adicionando o atributo dataInicio à associação. Poderíamos acrescentar este atributo à classe Pessoa. Mas é realmente um fato sobre a relação da Pessoa com a companhia, que mudará caso a pessoa mude de empregador.

A figura abaixo mostra uma outra maneira para representar esta informação: faça de Emprego uma classe plena (observe como as multiplicidades foram movidas correspondentemente). Neste caso, cada uma das classes na associação original tem uma ponta de associação de valor único em relação à classe Emprego. A ponta "Empregador" agora é derivada, embora eu não tenha que mostrá-lo.

44

Diagrama de Classes

Figura 4-29: Representação de uma classe de associação com emprego sendo classe plena

No diagrama acima podemos ver que uma pessoa pode trabalhar em uma ou nenhuma empresa, sendo que esta empresa possui várias pessoas trabalhando nela. A ponta empregador mostra que na pessoa teremos um atributo empregador quando houver uma associação de pessoa também com Empredo. Pereba que a empresa esta ligada a um emprego e este emprego (que é único) pode ser exercido por uma pessoa, que por sua vez pode também não estar liagada a emprego nenhum sendo que não estará então ligada também a empresa.

45

Diagrama de Classes

Associação Xor (ou exclusiva)

Uma restrição Xor (ou exclusiva) indica que, dentre as várias associações envolvidas nessa restrição, somente uma delas pode ocorrer por vez.

Por exemplo: suponha a classe Contrato que se relacione com a Classe Contratante. Podemos ter um contratante do tipo Pessoa Física, assim como um contratante do tipo Pessoa Jurídica, gerando duas associações:

Classe Contrato com a classe Pessoa Física Classe Contrato com a classe Pessoa Jurídica

Entretanto, não podemos permitir que ambas as associações ocorram ao mesmo tempo. Não seria possível num mesmo contrato termos um contratante que fosse ao mesmo tempo Pessoas Física e Jurídica.

Representamos graficamente esta restrição por meio de uma linha tracejada ligando as associações envolvidas. Essa linha é identificada com a string {xor}. Veja a figura abaixo que ilustra esta associação:

Figura 4-30: Representação de {xor}

46

Diagrama de Classes

Estereótipo

Um estereótipo é um mecanismo de extensibilidade da UML que representa uma subclasse de um elemento já existente com o mesmo formato porém com objetivos diferentes e bem definidos. Geralmente, quando necessitamos distinguir um uso específico para um elemento, utilizamos estereótipos.

O estereótipo possui a mesma representação gráfica do elemento, sendo colocado seu nome entre guillemets (<<>>) acima ou em frente do nome do elemento que está sendo descrito pelo estereótipo. Se múltiplos estereótipos são definidos para o mesmo elemento de modelo, então, eles são colocados verticalmente um abaixo do outro. Por exemplo: <<utility>>

Um outro exemplo disso é a interface. A interface de UML é uma classe que tem somente operações públicas sem métodos nem atributos. Isso corresponde a interfaces em Java, COM e CORBA. Uma vez que este é um tipo especial de classe, ele é definido como um estereótipo de classe. Utilizamos também estereótipos para classes abstratas. Veja abaixo as figuras:

Figura 4-31: Utilização de estereótipos em classes

Notas

É um símbolo gráfico contendo informação textual. É utilizado para especificar vários tipos de informações sobre os modelos, como: restrições, comentários, corpos de métodos e valores de etiquetas. Veja abaixo a presentação de uma nota:

47

Diagrama de Classes

Figura 4-32: Representação de uma nota

As notas são os elementos mais utilizados para melhorar e enriquecer os seus diagramas com informações. Elas podem ser utilizadas em qualquer diagrama e irão nos ajudar a explicar partes dos diagramas que os elementos do mesmo utilizados pela UML não conseguem deixar claro.

48

Diagrama de Classes

Interfaces e Classes Abstratas

Uma das grandes qualidades do desenvolvimento orientado a objetos é que você pode variar as interfaces de classes, independentemente da implantação. Muito da força do desenvolvimento orientado a objetos vem desta propriedade. Entretanto, poucas pessoas fazem bom uso disso.

As linguagens de programação usam uma construção única, a classe, que contém tanto a interface quanto a implementação. Quando você faz subclassificação, você herda as duas. Raramente, faz-se uso de interface como uma construção separada, o que é uma pena.

Uma interface pura, como em Java, é uma classe sem implementação e, portanto, tem declarações de operações mas não corpos de métodos e não tem campos. As interfaces são, freqüentemente, declaradas através de classes abstratas. Tais classes podem oferecer alguma implementação, mas, com freqüência, elas são usadas basicamente para declarar uma interface. O ponto é que a subclassificação - ou outro mecanismo- proverá a implementação, mas os clientes nunca verão a implementação, somente a interface.

O editor de texto representado na figura abaixo é um exemplo típico disso. Para permitir que o editor seja independente da plataforma, definimos uma classe Janela abstrata independente de plataforma. Esta classe não tem corpos de métodos; ela apenas define uma interface para utilização pelo editor de texto. Subclasses específicas de plataforma podem ser usadas conforme o desejado.

49

Diagrama de Classes

Figura 4-33: Representação de uma classe abstrata

Se você tem uma classe ou um método abstrato, a convenção de UML é de colocar em itálico o nome do item abstrato. Você também pode usar a restrição {abstract}. Uso {abstract} em quadros brancos porque não posso escrever um texto em itálico. Os editores permitem usar itálico, mas acredito que o uso do estereótipo deixa mais claro.

Classes abstratas podem possuir operações com implementação, a pesar de se diferenciarem por terem operações sem implementação. Muitas vezes consideramos a classe abstrata como uma classe inacabada e que que não pode ser acabada porque a implementação do que falta é dependente de alguém, como por exemplo na figura acima, dependente de uma plataforma. Normalmente as classes abstratas representam estruturas das quais não iremos criar objetos mas sim servirão de moldes para a padronização de outras classes, as classes filhas.

Uma interface é muito parecida com uma classe abstrata, porém ela se difere por ser uma estrutura voltada para a representação de comportamentos, onde os comportamentos serão as operações. Uma interface não possui operações com implementação, elas tem somente a assinatura das mesmas declaradas. A interface será implementada por classes e a relação entre elas será conhecida como realização. Veja abaixo a representação de uma interface com algumas operações:

50

Diagrama de Classes

Figura 4-34: Representação de uma interface

Abaixo temos uma JanelaWindows que está implementando o comportamento de uma interface WindowListener. Este interface define todos os comportamentos que uma janela pode ter. Se a JanelaWindows implementar estes comportamentos então será obrigado termos na mesma todas as operações descritas na interface. A classe que implementar esta interface poderá tratar ações que acontecem em uma janela, ou seja os comportamentos da interface WindowListener.

Figura 4-35: Relacionamento de realização entre uma classe e uma interface

51

Diagrama de Classes

Objetos de Referência e Objetos de Valor

Uma das coisas comuns dita sobre objetos é que eles têm identidade. Isso é verdade, mas não é tão simples assim. Na prática, você percebe que a identidade é importante para objetos de referência, mas não tão importante para objetos de valor.

52

Diagrama de Classes

Objetos de referência

São coisas como Clientes, geralmente as classes das linguagens. Aqui, a identidade é muito importante, porque você geralmente quer que somente um objeto de software designe um cliente no mundo real. Um objeto que faz referência a um objeto-Cliente fará isso através de uma referência ou ponteiro; todos os objetos que se referem a este Cliente vão se referir ao mesmo objeto de software. Desta forma, modificações em um Cliente ficam disponíveis para todos os usuários do Cliente.

Se você tem duas referências para um Cliente e quer ver se são as mesmas, você, normalmente, compara suas identidades. Cópias podem ser proibidas; se são permitidas, elas tendem a ser feitas raramente, talvez para propósitos de arquivamento ou para replicação na rede. Se cópias forem feitas, você necessita decidir como sincronizar as atualizações do objeto.

53

Diagrama de Classes

Objeto de Valor

São coisas como datas, ou tipos primitivos das linguagens. Você tem, geralmente, múltiplos objetos de valor representando o mesmo objeto do mundo real. Por exemplo, é normal ter centenas de objetos que designam 29-Jul-2004. Estas são todas cópias intercambiáveis. Novas datas são freqüentemente criadas e destruídas.

Se você tem duas datas e quer ver se elas são a mesma, você não examina as suas identidades, mas sim os valores que elas armazenam. Isso significa, geralmente, que você tem que escrever um operador de teste de igualdade, que para datas fará testes no ano, mês e dia (ou qualquer outra forma de representação interna). Normalmente, cada objeto que faz referência a 29-Jul-2004 tem o seu próprio objeto data dedicado a isso, mas você também pode compartilhar datas.

Objetos de valor devem ser imutáveis (congelados; veja "Frozen" mais adiante). Em outras palavras, você não deve ser capaz de pegar um objeto data de 29-Jul-2004 e mudá-lo para ser 31-Jul-2004. Em vez disso, você deve criar um novo objeto 31-Jul-2004 e ligá-lo ao primeiro objeto. A razão é que se a data fosse compartilhada, você atualizaria a data de outro objeto de um modo imprevisível.

Antigamente, a diferença entre objetos de referência e objetos de valor era mais clara. Objetos de valor eram os valores básicos (built-in) de um sistema de tipos. Agora, você pode estender o sistema de tipos com suas próprias classes, por isso esta questão requer mais reflexão. Em UML, atributos são geralmente usados para objetos de valor e associações são usadas para objetos de referência. Você também pode usar composição para objetos de valor.

A distinção entre objetos de valor e de referência seja útil para modelos conceituais. Isso pode causar confusão com multiplicidades. Se representar uma ligação para um objeto de valor com uma associação, normalmente marcamos a multiplicidade da ponta do usuário de um dado valor como "*", a não ser que exista uma regra de unicidade, tal como um número de seqüência.

54

Diagrama de Classes

Coleções para Pontas de Associações de Valores Múltiplos

Uma ponta de valor múltiplo é uma cujo limite superior de multiplicidade é maior que 1 (por exemplo, "*"). Uma convenção usual é que pontas de valores múltiplos sejam consideradas como conjuntos. Não há ordem para os objetos-alvo, e nenhum objeto aparece no conjunto mais de uma vez. Entretanto, você pode mudar estas suposições anexando uma restrição.

A restrição {ordered} implica que há uma seqüência de ordem para os objetos-alvo - isto é, objetos-alvo formam uma lista. Eles podem aparecer somente uma vez na lista.

Uso a restrição {bag} para indicar que objetos-alvo podem aparecer mais de uma vez, mas sem ordem. Também a restrição {hierarchy} para indicar que eles formam uma hierarquia.

55

Diagrama de Classes

Frozen

Frozen (Congelado) é uma restrição que UML define como aplicável a um atributo ou a uma ponta de associação, mas considero-o útil também para classes.

Em uma ponta de associação ou atributo, Frozen indica que o valor daquela ponta de associação ou atributo não pode mudar durante o tempo de vida do objeto-fonte. O valor deve ser estabelecido na criação do objeto e não pode mudar jamais. O valor inicial pode ser nulo. Certamente, se isso é verdade quando o objeto for construído, isso será verdade durante toda a vida do objeto. Isso indica que existe um argumento para este valor em um construtor e não existe operação que atualize este valor.

Quando aplicado a uma classe, congelado indica que todas as pontas de associação e todos os atributos associados com aquela classe são congelados.

Congelado não é o mesmo que Read-Only (somente-de-leitura). Read-Only indica que um valor não pode ser mudado diretamente, mas pode mudar devido a uma mudança em algum outro valor. Por exemplo, se uma pessoa tem uma data de nascimento e uma idade, a idade pode ser somente-de-leitura, mas não pode ser congelada.

Frozen quando colocado na assinatura de uma classe indica que esta classe não pode ter filhos, ou seja não poderá ser classe pai em uma relação de generalização/herança. Já quando colocamos frozen em uma assinatura de uma operação estamos dizendo que esta operação não poderá ser sobreescrita, ou seja ela não poderá ser redefinida na classe filha da classe que a contém.

56

Diagrama de Classes

Visibilidade

A visibilidade é um daqueles assuntos que é simples em princípio, mas tem complexas sutilezas. A idéia básica é que qualquer classe tem elementos públicos e elementos particulares. Os elementos públicos podem ser usados por qualquer outra classe; os elementos particulares podem ser usados somente pela classe proprietária. Entretanto, cada linguagem tem suas próprias regras. Embora muitas linguagens usem termos como public ("público"), private ("particular") e protected ("protegido"), eles têm significados diferentes em linguagens diferentes. Estas diferenças são pequenas, mas causam confusão, principalmente para alguns de nós que utilizamos mais de uma linguagem.

UML tenta abordar o tema sem entrar em terrível confusão. Essencialmente, dentro de UML, você pode rotular qualquer atributo ou operação com um indicador de visibilidade. Você pode usar qualquer marcador que quiser, e seu significado é dependente da linguagem. Entretanto, UML fornece quatro (bastante difíceis de lembrar) abreviações para visibilidade; + (público), - (privado), # (protegido) e ~ (pacote)

Para compreender realmente algumas diferenças comuns que existem entre modelos, você necessita compreender os enfoques que linguagens diferentes usam em relação à visibilidade. Com C++, que é a base para o uso-padrão de UML, temos os três primeiros mostrados abaixo, porém a maioria das linguagens possui o pacote também.

PUBLIC é visível em qualquer lugar no programa e pode ser acessado por qualquer objeto no sistema.PRIVADO pode ser usado somente pela classe que o define.PROTEGIDO pode ser usado somente por (a) uma classe que o define ou (b) uma subclasse daquela classe.PACOTE pode ser utilizado pela classe que o define e por outras classes que estivrem no mesmo pacote.

Considere uma classe Cliente que tem uma subclasse Cliente Pessoa-Física. Considere também o objeto Martin, que é uma instância de Cliente Pessoa-Física. Martin pode usar qualquer membro público de qualquer objeto no sistema. Martin também pode usar qualquer membro particular da classe Cliente Pessoa-Física. Martin não pode usar membros particulares definidos dentro de Clientes; pode, entretanto, usar membros protegidos de Cliente e membros protegidos de Cliente Pessoa-Física.

Agora, examinemos Smalltalk. Dentro desta linguagem, todas as variáveis de instância são particulares, e todas as operações são públicas.

57

Diagrama de Classes

Entretanto, particular não significa a mesma coisa em Smalltalk que em C++. Em um sistema Smalltalk, Martin pode acessar qualquer variável de instância dentro do seu próprio objeto se aquela variável de instância estiver definida dentro de Cliente ou Cliente Pessoa-Física. Então, de certa forma, particular em Smalltalk é semelhante a protegido em C++.Ah, mas isso seria simples demais...

Vamos voltar para C++. Digamos que eu tenha uma outra instância de Cliente Pessoa-Física chamada Kendall. Kendall pode acessar qualquer membro de Martin que tenha sido definido como parte cia classe Cliente Pessoa-Física, seja público, particular ou protegido. Kendall também pode acessar qualquer membro público ou protegido de Martin que tenha sido definido em Cliente. Entretanto, em Smalltalk, Kendall não pode acessar as variáveis de instância particulares de Martin - somente as operações públicas de Martin.

Em C++, você pode acessar membros de outros objetos de sua própria classe da mesma forma que acessa os seus próprios membros. Em Smalltalk, não faz diferença se um outro objeto é da mesma classe ou não; você pode somente acessar as partes públicas de um outro objeto.

Java é semelhante a C++; ela oferece acesso livre a membros de outros objetos de uma mesma classe. Ela também acrescenta um novo nível de visibilidade, chamado pacote. Um membro com visibilidade de package (pacote) pode ser acessado somente por instâncias de outras classes dentro do mesmo pacote.

Permanecendo em nosso tema, para garantir que as coisas não são tão simples, Java redefine levemente visibilidade protegida. Em Java, um membro protegido pode ser acessado por subclasses, mas também por qualquer outra classe do mesmo pacote da classe proprietária. Isso significa que, em Java, protegido é mais público que pacote. Java também permite que classes sejam marcadas: como públicas ou de pacote. Os membros públicos de uma classe pública podem ser usados por qualquer classe que importa o pacote em que a classe pertence. Uma classe de pacote pode ser usada somente por outras classes do mesmo pacote.

C++ acrescenta um penduricalho adicional. Um método ou classe de C++ pode se tornar um amigo ("friend") de uma classe. Um amigo tem acesso completo a todos os membros de uma classe - portanto, a frase (de mau-gosto) "em C++, amigos tocam as partes particulares dos outros".

Quando você estiver usando visibilidade, use as regras da linguagem na qual está trabalhando. Quando você está examinando um modelo UML de qualquer outra origem, seja cuidadoso com o significado dos marcadores de visibilidade, e esteja ciente de como estes significados podem mudar de linguagem para linguagem.

58

Diagrama de Classes

As visibilidades geralmente mudam quando você começa a trabalhar com código. Então, não fique amarrado a elas no início do projeto. Veja abaixo uma classe com a visibilidade para seus atributos:

Figura4-36: Representação da visibilidade para atributos de uma classe

Na Orientação a Objetos lembre-se que o recomendado é ter os atributos de uma classe sempre privados, desta forma teríamos sempre o sinal de “-” na frente de cada um doa atributos.

59

Diagrama de Classes

Quando Utilizar Diagramas de Classes

Diagramas de classes são a base de quase todas as metodologias OO, portanto você irá utilizá-los o tempo todo. Este capítulo cobre os conceitos básicos; neste capítulo do curso discutimos muitos conceitos avançados.

O problema com diagramas de classes é que eles são muito ricos e podem ser complexos de se usar. Você tem aqui algumas dicas.

Não tente utilizar todas as notações que você dispõe. Comece com os recursos mais simples: classes, associações, atributos, generalização e restrições. Introduza outras notações mais avançadas vistas neste capítulo somente se necessitar.

Ajuste a perspectiva na qual você está desenhando os modelos para o estágio do projeto.

1- Se você estiver fazendo análise, desenhe modelos conceituais.2- Quando você estiver trabalhando com software, concentre-se nos

modelos de especificação.3- Desenhe modelos de implementação somente quando você estiver

ilustrando uma particular técnica de implementação.

Não desenhe modelos para tudo; em vez disso, concentre-se nas áreas principais. É melhor ter poucos diagramas que você usa e mantém atualizados do que ter muitos modelos esquecidos e obsoletos.

O maior perigo com diagrama de classes é que você pode ficar detido em detalhes de implementação muito facilmente. Para combater isso, concentre-se nas perspectivas conceituais e de especificação.

60

Diagrama de Classes

Exercícios

Utilizando a ferramenta de modelagem de diagramas UML faça:

1 – Para o texto descritivo do sistema apresentado no exercício do capítulo 1 (capítulo sobre use cases) elabore um diagrama de classes que possa representar as classes envolvidas no sistema mostrando as suas assiciações. Tente utilizar ao máximo a notação para representação dos elementos do diagrama de classes estudada no capítulo.

2 – Reflita e discuta com o instrutor e colegas quais são os benefícios da construção de um diagrama de classes para a modelagem de sistemas orientados a objeto.

61

Diagrama de Classes


62


5.5. Diagrama de EstadosDiagrama de Estados

1

Diagrama de Estados

Objetivos

Aprender o que é e como pode ser utilizado diagramas de estados

Conhecer os elementos que fazem parte deste tipo de diagrama

Saber quando devemos utilizar diagramas de classes

2

Diagrama de Estados

O que é um Diagrama de Estados?

O diagrama de gráfico de estados descreve o comportamento de objetos como reação a eventos discretos (como por exemplo sinais e invocação de operações), por meio de seqüências de estados e ações que ocorrem durante a sua vida.

Um diagrama de gráfico de estados tem por objetivo mostrar uma máquina de estado. Uma máquina de estado consiste num comportamento que especifica a seqüência de estados que um objeto atravessa durante sua vida, em resposta a eventos, junto com suas responsabilidades e ações.

3

Diagrama de Estados

Estado

Um estado é uma condição ou situação existente na vida de um objeto durante a qual o estado satisfaz alguma condição, executa alguma atividade ou espera por algum evento.

Um estado é representado graficamente como um retângulo com cantos arredondados. O nome do estado é colocado no centro do mesmo, caso ele não esteja subdividido em compartimentos. Veja na figura abaixo a representação de um estado:

Figura 5-1: Representação de estados

Um estado pode ser opcionalmente subdividido em compartimentos separados cada qual por uma linha horizontal. São eles:

Compartimento de nome: armazena o nome do estado, como uma string. É possível desenharmos estados sem nomes. Estes são estados anônimos, distintos em si.

Compartimento de transições internas: este compartimento armazena uma lista de ações ou atividades internas que são executadas enquanto o objeto se apresenta no estado em foco.

Essas transições internas são representadas por expressões que identificam as circunstâncias sobre as quais a ação associada será invocada. A ação associada ao tipo de transição externa pode fazer uso de quaisquer atributos e links, que estão no escopo do objeto proprietário. Uma transição interna não modifica o estado do objeto.

Por exemplo: quando um objeto OperacaoBancaria entra no estado de "Liberando dinheiro de saque", ele pode chamar uma ação que bloqueie na conta do correntista o valor designado para saque. Na saída desse estado, ele pode chamar a ação de debitar o valor da conta. Durante o estado, estará sendo executada a operação de contagemCedulas().

4

Diagrama de Estados

Existem algumas palavras reservadas que representam as transições internas. Veja quais são e seus significados:

entry: identifica uma ação que é executada na entrada do estado. exit: identifica uma ação que é executada na saída do estado.do: identifica uma atividade em andamento, ou seja, que é executada continuamente durante o tempo em que o objeto permanece nesse estado.include: usado para identificar a invocação de uma submáquina, cujo nome está ligado à expressão.

As expressões citadas identificam, cada qual, o evento que dispara a expressão correspondente associada.

O formato geral para qualquer item da lista é:

nome-do-evento (lista de parâmetros separada por vírgula ) [ condição-de-guarda ] / expressão-ação

Cada nome de evento pode aparecer mais de uma vez por estado se as condições de guarda forem diferentes. Os parâmetros do evento e as condições de guarda são opcionais.

Figura 5-2: Compartimento de transições internas

Vou utilizar em seguida um exemplo do nosso mundo real para que vocês possam abstrair mais facilmente o conceito de estados.

Vamos pensar na vida de uma pessoa do nascimento até a terceira idade. Veja, de forma sucinta, como seria parte do nosso diagrama de estados.

Para assumirmos o primeiro estado de nossa existência, precisamos do evento nascer. Já nascemos como bebé e a primeira ação que temos é reconhecer nossa mãe, pelo toque, voz e/ou cheiro. Durante esse período inicial, o bebé, além de dormir e mamar, também desenvolve suas habilidades - principalmente motoras: aprende a sentar, engatinhar, falar e andar. Só que ao final dessa fase, quando ele já tem uma personalidade bem formada, já

5

Diagrama de Estados

podemos considerar nosso bebé como uma pequenina criança. Nesse período no "estado de criança", recebemos muitos estímulos e executamos muitas ações. Mas pelo foco que quero dar nesse primeiro exemplo, coloquei como atividade principal: brincar. Até que chega a dita puberdade, que transforma nossas crianças em adolescentes. Na saída do estado de criança, algumas atitudes são tomadas: se criança do sexo feminino, abandonar as bonecas; se do sexo masculino, abandonar os carrinhos (ou as “bolinhas de gude”).

Já ao entrar na fase de adolescência, a primeira ação de nossa "pós-criança" é estabelecer seu território: o quarto deles, as coisas deles, os direitos deles, etc. No estado de adolescente há várias coisas que podem ser feitas, mas decidi colocar a operação namorar. Em determinado momento da vida (que não sei precisar qual e não sei se alguém consegue determinar), o adolescente passa para o estado adulto. Ou, então, por uma precipitação da sua ação principal (namorar), casa-se sem se tornar adulto.

Figura 5-3: Exemplo de um diagrama de estados descrevendo nossa evolução

Durante sua permanência no estado adulto, essa pessoa exerce a ação Trabalhar . Finalizarei o exemplo com uma separação do estado Adulto (como solteiro) para um estado de Casado.

6

Diagrama de Estados

Estado Inicial e Estado Final

Um estado inicial é um tipo de estado que indica o local de início na máquina de estados ou em um subestado. É representado graficamente como um círculo preenchido.

Figura 5-4: Exemplo de estado inicial

Um estado final é um tipo de estado que indica que a máquina de estados ou um estado composto concluiu sua execução. É representado graficamente como ura círculo envolvendo um pequeno círculo preenchido.

Figura 5-5: Exemplo de estado final

7

Diagrama de Estados

Transições

Uma transição é um relacionamento entre dois estados indicando que houve uma mudança de estado e determinadas ações serão executadas, quando um evento específico ocorrer, garantindo que condições foram satisfeitas. A transição é disparada quando ocorre a mudança de estado.

É representada graficamente como uma linha sólida na qual o estado de partida é identificado como estado de origem e o estado-alvo é o estado de destino. A linha da transição finaliza com uma seta. Pode ser identificada por uma string que possui o seguinte formato:

assinatura-do-evento [ condição-de-guarda ] / expressão-ação

A assinatura-do-evento descreve um evento com seus argumentos, no seguinte formato:

nome-do-evento (lista de parâmetros separada por vírgula )

Exemplo: ChecarEstoque(produto)

Figura 5-6 – Diagrama de estados para uma fila de impressão

A condição de guarda é uma expressão booleana que determina, quando verdadeira, o início da transição. Pode ser escrita com parâmetros do evento disparador ou ainda atributos e links do objeto proprietário da máquina de estados. Só é avaliada depois que o evento de ativação ocorre. É possível termos várias transições a partir do mesmo estado de origem, identificadas com o mesmo evento, diferenciando apenas na sua condição de guarda.

Exemplo: [estoqueAtual <= estoqueMinimo]

A expressão-ação somente é executada no início da transição, se esta ocorrer. Pode ser escrita com operações, atributos e links do objeto

8

Diagrama de Estados

proprietário da máquina de estados, parâmetros do evento disparador ou qualquer outro elemento visível no mesmo escopo.

Exemplo: DataPagamento:= DataPagamento + 3

Veja por exemplo a figura abaixo. O objeto está no estado Aguardando Nota, até que o evento Nota lançada ocorra. Nesse momento, temos duas possibilidades para o mesmo evento. A primeira é representada na transição para o estado Atualizando Média, que só será iniciada se a sua condição de guarda for satisfeita, ou seja, que nota >= 0. Outra possibilidade ocorre na transição para o estado Habilitando Segunda Chamada, que só terá início se a condição de guarda nota = "FT" for verdadeira, ou seja, se não tiver havido nota pois o aluno faltou.

Figura 5-7: Diagrama de Estados com condição nas transições

Um evento é a especificação de um tipo de ocorrência observável. Para propósitos práticos em diagramas de estado, ele é uma ocorrência que pode disparar uma transição de estado. Eventos podem ser processados um de cada vez. Se um evento não disparar uma transição, esta é descartada. Eventos podem ser de vários tipos (não necessariamente mutuamente exclusivos):

Quando uma condição (descrita por uma expressão booleana) tem seu valor modificado de falso para verdadeiro;Quando há recepção de um sinal explícito de um objeto para outro;Quando há recepção da chamada de uma operação implementada como uma transição por um objeto;Quando a passagem de um período de tempo específico depois da ocor-rência de outro evento representa um evento de tempo. Pode ser repre-sentado pela palavra chave after seguida pela expressão a ser avaliada (ex: after 10 minutos). Outra palavra-chave que pode ser usada é when (ex: when (dataAdmissao >= 01/01/1987)).

9

Diagrama de Estados

Figura 5-8: Diagrama para fila de impressão com eventos internos

10

Diagrama de Estados

Estado composto

Um estado composto é um estado que possui uma decomposição gráfica em dois ou mais subestados concorrentes (sobrepostos) ou sequenciais (disjuntos).Cada região de um estado pode possuir estados inicial e final.

Uma transição para um estado composto representa uma transição para o estado inicial do referido estado composto. Uma transição para um estado final representa a conclusão da atividade na região do estado composto. Vamos supor um sistema de avaliação no qual o aluno responda as questões de sua prova on-line. Vamos pensar para esse sistema em um objeto Prova (veja figura abaixo). Durante a vida deste objeto, no momento que o aluno responde às questões, o objeto estará passando do estado Aguardando Escolha de Questão para Aguardando Resposta de Questão e assim por diante. Todavia, em paralelo com essas respostas, temos o estado Checando Término da Prova, que ocorre quando o tempo decorrido de prova se iguala ao valor do atributo tempoProva. Neste caso, estamos diante de subestados concorrentes, nos quais os estados ocorrem simultaneamente.

Figura 5-9: Diagrama de Estados concorrentes

11

Diagrama de Estados

Quando Utilizar Diagramas de Estados

Diagramas de estados são bons para descrever o comportamento de um objeto, através de vários casos de uso. Esses diagramas não são muito bons para descrever um comportamento que envolve vários objetos em colaboração. Para tal, é útil combinar diagramas de estados com outras técnicas.

Por exemplo, diagramas de interação (vistos mais adiante neste curso) são bons para descrever o comportamento de vários objetos em um único caso de uso, e diagramas de atividades (visto anteriormente) são bons para mostrar a seqüência geral de ações para vários objetos e casos de uso.

Nem todo mundo considera que os diagramas de estados sejam naturais. Fique atento ao modo que as pessoas trabalham com eles. Pode ser que sua equipe não considere diagramas de estados úteis para seu tipo de trabalho. Isso não é um grande problema; como sempre, você deve lembrar de usar uma combinação das técnicas que funcionam para você.

Se você utilizar diagramas de estados, não tente projetá-los para cada classe no sistema. Embora este método seja frequentemente usado por perfeccionistas de muita formalidade, ele é quase sempre um desperdício de trabalho. Use diagramas de estados somente para aquelas classes que exibem comportamento interessante, para as quais a construção do diagrama de estados ajude a compreender o que está acontecendo. Muitas pessoas acreditam que Interface de Usuários e objetos de controle têm o tipo de comportamento que é útil descrever com diagramas de estados.

12

Diagrama de Estados

Exercícios

1 – Em quais situações você julga importante a criação de diagramas de estados?

2 – Utilize a ferramenta de modelagem UML para criar um ou mais diagramas de Estados para as classes que você julgar que necessitam no seu diagrama de classes. Concentre-se nos esdados das classes e deixe para pensar depois as operações (entry/do/exit).

13

Diagrama de Estados


14


6.6. Diagrama de ObjetosDiagrama de Objetos

1

Diagrama de Objetos

Objetivos

Conhecer o diagrama de objetos

Reconhecer os elementos do diagrama de objetos

Montar um diagrama de objetos

Saber quando utilizar este tipo de diagrama

2

Diagrama de Objetos

O que é um diagrama de objetos?

Este diagrama poderia tranquilamente ser abordado como um item do capítulo de diagrama de classes, já que representa a instância desse diagrama num determinado ponto do tempo. Por suas características, ele merece um pouco mais de atenção. Se pensarmos naqueles sistemas cujos requisitos são fonte de dúvidas, certamente você achará que esse diagrama lhe fornece muito mais produtividade do que aparenta. Para instâncias de uma classe Aluno, talvez esse diagrama seja desnecessário, mas será que teríamos o mesmo pensamento no caso de classes envolvendo um ambiente industrial? Vejamos agora este diagrama em detalhes, o mesmo é um diagrama simples e não frequentemente utilizado.

3

Diagrama de Objetos

Criando diagramas de objetos

Um diagrama de objetos consiste numa instância do diagrama de classes, no qual para cada classe ternos um objeto (sua instância) em um determinado ponto do tempo. Você deve estar perguntando: e para que isso me serviria? Primeiramente, muitas vezes estamos naqueles dias em que a criatividade custa para vir ou simplesmente o relacionamento entre classes não está claro suficiente para que possamos realizar a modelagem do diagrama. Uma vez que criamos um diagrama de objetos, passamos a trabalhar com dados reais, que numa visão direta lhe dizem muito mais do que a simples estrutura de uma classe. Essa visão não só esclarece o relacionamento entre as classes, como pode levar ao esclarecimento de dúvidas de domínio.

Os diagramas de objetos são muito úteis para facilitar a modelagem de estruturas complexas de dados. O diagrama de objetos pode também auxiliar o desenvolvedor no momento de identificar problemas na execução de uma aplicação. Durante o debugging, pode-se parar a execução e paralelamente mapear, num diagrama de objetos, os objetos que estão sendo manipulados, expandindo seus relacionamentos e alguns objetos vizinhos.

Se levarmos em conta todos os objetos e relacionamentos possíveis dentro de um diagrama, teremos milhares de objetos. Logicamente é impossível exibirmos tudo. Desta forma, deve-se mostrar no diagrama de objetos somente um conjunto de objetos que tenham relevância dentro da modelagem. Esse conjunto procura se basear em colaborações. A partir de um determinado objeto, percorrem-se os relacionamentos existentes, congelando-se um determinado estado do objeto. Fowler, no seu livro UML Distilled - A BriefGuide to the Standard Object, afirma que podemos considerar um diagrama de objetos como um diagrama de colaboração (visto anteriormente) sem mensagens, uma vez que estamos representando os objetos ligados uns aos outros para realizar determinada tarefa.

As ferramentas não necessitam possuir uma implementação separada para diagramas de objetos. É possível apenas adotar um diagrama de classes que mostre objetos no lugar das classes. Para chamar a atenção para características importantes, pode-se trabalhar com anotações e cores diferenciadas no diagrama.

A representação gráfica de um objeto é similar à de uma classe. Consiste num retângulo com dois compartimentos. O primeiro mostra o nome do objeto e o segundo mostra os atributos, um em cada linha, com seus valores. Veja a figura abaixo:

4

Diagrama de Objetos

Figura 6-1: Representação de um objetoO nome do objeto deve ser sublinhado, na seguinte notação: nome do

objeto: nome da classePor exemplo: uml: Curso

É possível ainda omitir o nome do objeto (preservando os dois pontos), representando um objeto anônimo ou omitir o nome da classe (juntamente com os dois pontos). Em qualquer um desses casos, mantém-se o sublinhado. É mais comum representarmos somente o tipo do objeto não se preocupando com o nome do mesmo. Veja a figura abaixo:

Figura 6-2: Representações possíveis para um objeto

Quanto aos atributos, estes são exibidos na notação:

nome do atributo: tipo = valor

O tipo, se for citado, deve ser o mesmo definido na classe. Desta forma, ele pode ser omitido sem prejuízo da compreensão do diagrama.

Figura 6-3: Representações de um objeto com atributos e valores

5

Diagrama de Objetos

Atributos cujos valores não sejam relevantes para a modelagem podem ser omitidos. É possível também representar atributos cujos valores mudam durante um processamento. Nesse caso, representa-se essa mudança por meio de uma lista de valores.

O relacionamento entre os objetos é feito através de links. Um link é a instância de uma associação. Um nome de papel pode ser mostrado ao final de cada link. Da mesma ferma, um nome de associação pode ser mostrado próximo à linha. Multiplicidades não podem ser mostradas para links, pois estes já são instâncias de associações. Os adornos de associação como agregação, composição e navegação, assim como qualifícadores, podem ser mostrados na terminação dos links. Os diagramas de objetos podem também conter: notas, restrições e pacotes.

Vamos considerar o diagrama de classes da figura abaixo. A partir deste diagrama vamos montar um diagrama de objetos, mostrando mais explicitamente as multiplicidades que podem ser representadas por objetos.

6

Diagrama de Objetos

Figura 6-4: Diagrama de classes base para o diagrama de objetos

Abaixo podemos ver um diagrama de objetos para este diagrama de classes. Note que o diagrama de objetos mostra claramente a multiplicidade que pode acontecer entre um Instrutor e MaterialDidatico, bem como a possibilidade de haver mais de uma versão para o material didático que é mostrado na associação entre Curso e MaterialDidatico. Note ainda que cada associação entre o MaterialDidatico e o Arquivo resultou na criação de um objeto ligado a MaterialDidatico.

7

Diagrama de Objetos

Figura 6-5: Diagrama de objetos para o diagrama de classes

8

Diagrama de Objetos

Quando utilizar diagrama de objetos?

Como já falamos na parte introdutória deste capítulo, o diagrama de objetos será utilizado nas seguintes situações:

1 – Durante o debugging, pode-se parar a execução e paralelamente mapear, num diagrama de objetos, os objetos que estão sendo manipulados, expandindo seus relacionamentos e alguns objetos vizinhos

2 – Mostrar as multiplicidades do diagrama de classes de forma mais clara ligando os objetos

3 – Muitas vezes estamos naqueles dias em que a criatividade custa para vir ou simplesmente o relacionamento entre classes não está claro suficiente para que possamos realizar a modelagem do diagrama. Um diagrama de objetos irá nos ajudar nestes relacionamentos

4 – Montar uma diagrama de objetos com valores e enviar para o programador fazer testes no sistema com objetos com aqueles dados

9

Diagrama de Objetos

Exercícios

1 – Qual a finalidade dos diagramas de objetos?

2 – Para o diagrama de classes que você construiu nos exercícios do capítulo de classes faça agora um diagrama de objeto para algumas regiões que você julgar importantes do mesmo.

10

Diagrama de Objetos


11


7.7. Diagrama de InteraçãoDiagrama de Interação

1

Diagrama de Interação

Objetivos

Conhecer o diagrama de interação

Reconhecer os elementos do diagrama de interação

Estudar diagramas de colaboração

Estudar diagramas de seqüência

Saber quando utilizar estes diagramas

2


O que é um diagrama de Interação?

Antes de iniciarmos o estudo sobre os diagramas de interação, seria importante definirmos o que é uma interação. Mais do que isso, acho pertinente esclarecermos quaisquer dúvidas sobre interação e iteração.

Definição, segundo o Dicionário Aurélio:

interação. [De inter- + nção.] S. f. L Ação que se exerce mutuamente entre duas ou mais coisas, ou duas ou mais pessoas; ação recíproca: "Nesse fenômeno de interação de linguagem popular e linguagem poética o fato que nos parece mais curioso é o do aproveitamento, no curso da vida de cada um, .... de expressões usadas por poetas" (Valdemar Cavalcanti, Jornal Literário, p. 199); "É evidente que a obra de arte resulta da interação de fatores subjetivos e objetivos, veiculados através do meio social. " (Euríalo Canabrava, Estética da Crítica, p. 29)

iteração. [Do lat. iteratione.] S. f. L Ato de iterar; repetição. 2. Álg. Inform. Processo de resolução (de uma equação, de um problema) mediante uma seqüência finita de operações em que o objeto de cada uma é o resultado da que a precede.

Isto posto, interação corresponde a um conjunto de mensagens trocadas entre objetos, com o objetivo de alcançar um determinado

propósito, respeitando-se o contexto do sistema.

Já iteração corresponde, em uma abordagem mais complexa, às fases que se repetem, nas quais a entrada de uma fase corresponde à saída da sua antecessora. Em uma abordagem mais simples, corresponde a um processo de repetição.

Um diagrama de interação mostra as interações por meio de uma visão dinâmica do sistema. Pode representar um sistema, subsistema, operação, classe ou cenário de um caso de uso, sendo essa última representação a mais frequente. Um diagrama de interação é formado, basicamente, por objetos, relacionamentos e mensagens. Os diagramas de interação se apresentam de duas formas:

diagramas de seqüências diagramas de colaboração

Esses diagramas possuem cada qual alguns aspectos que os diferenciam. O diagrama de seqüências enfatiza a seqüência de mensagens dentro de uma linha de tempo, enquanto que o de colaboração enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com o tempo determinado para cada interação.

3


Traçando um paralelo: suponha que no Restaurante A sei que o garçom leva dez minutos até trazer meu pedido e levo vinte minutos comendo. Espero mais cinco minutos pela conta e outros cinco minutos pelo troco. Devo lembrar que a conta só é trazida depois que termino minha refeição. Quando vou ao Restaurante B, não preciso me preocupar com o tempo. Assim, não olho toda a hora para o relógio. Sei que faço um pedido ao garçom, ele atende meu pedido, recebo a conta, pago, pego o troco e vou embora. Só não dá para afirmar se a conta chega antes de terminar a minha refeição ou não.Assim, o Restaurante A seria similar ao diagrama de seqüências, no qual as mensagens são trocadas entre os objetos (nesse caso: cliente e garçom), com demonstração do tempo de processamento (não necessariamente com valor definido (10 minutos). O Restaurante B seria similar ao Diagrama de Colaboração, no qual as mensagens são passadas de um objeto a outro sem indicar o tempo de processamento de cada uma.

É interessante ressaltar que esses diagramas apresentam formas diferentes de modelar os mesmos elementos. É como se ordenássemos uma mesma lista de duas maneiras distintas. Apesar da visão ser diferente, estamos lidando com os mesmos dados.

4


Diagrama de seqüências

Para melhor ilustrar a interação de um Diagrama de Seqüências, vamos imaginar um processo X qualquer de uma empresa, na qual trabalham os funcionários Antônio, João e Carlos. Num dado instante, o Gerente da empresa solicita ao Antônio que prepare um relatório de comissões para um determinado mês. Entretanto, para que o Antônio consiga preparar esse relatório, ele precisa do total de cada vendedor, obtido no mês em foco, e essa informação quem tem é o João. Então, Antônio passa um e-mail para o João pedindo essa informação.

João quando recebe essa mensagem (eletrônica) inicia os procedimentos necessários para relacionar as vendas de cada vendedor. Todavia, ele só possui em mãos a matrícula de cada vendedor e seu total vendido. Mas ele pode conseguir o nome de cada vendedor com o Carlos. Assim, João passa um e-mail para o Carlos, enviando no corpo da mensagem a lista de matrículas que ele possui, solicitando que seu colega diga a quem pertence.

Carlos, ao receber a mensagem, procura em suas fichas os nomes dos vendedores. De posse desses nomes, ele responde ao e-mail de João, acrescentando os nomes dos vendedores. João, ao receber a resposta de Carlos, responde a mensagem original de Antônio, acrescentando no corpo da mensagem a lista de vendedores (com matrícula e nome) acompanhada dos totais de vendas de cada um.

Antônio, feliz da vida pois a equipe é bem entrosada, abre a mensagem de resposta, pega as informações recebidas e coloca em seu relatório. Nada como uma empresa que funciona! Guardadas as devidas proporções, se trocarmos os funcionários Antônio, João e Carlos pelas responsabilidades que eles possuem, temos a encenação da troca de mensagens entre objetos em um diagrama de seqüências.

Antônio é um captador e transmissor de informações; será nossa tela de Relatório. João é responsável por controlar as vendas do mês; será nosso objeto Vendas. Carlos é responsável por controlar o cadastro dos vendedores; será nosso objeto vendedor.

A representação gráfica de um diagrama de seqüências é baseada em duas dimensões. A primeira dimensão é vertical e representa as mensagens trocadas no decorrer de um tempo de vida (eixo Y). A segunda dimensão é horizontal e representa os objetos participantes das interações (eixo X). As mensagens correspondem a chamadas de serviços dos objetos, ou seja, a chamadas de suas operações.

Assim, estabelecemos uma interação que corresponde à representação de um elemento do modelo (por exemplo: Diagrama de Seqüências para o

5


caso de uso Cadastro de Funcionário) e para tal relacionamos os objetos envolvidos e desenhamos cada chamada de operação como o disparo de uma mensagem, partindo do objeto chamador para o objeto executor da operação.

Figura 6-6: Exemplo simplificado de troca de mensagens

A representação dos objetos em um diagrama de seqüências é feita com um retângulo alinhado no topo do diagrama, partindo dele uma linha vertical tracejada denominada linha de vida, que é desenhada até o fim do diagrama. A linha de vida representará a vida deste objeto dentro de um determinado período de tempo.

6


Figura 6-7: Diagrama de seqüência para cálculo de preço do produto

Um objeto, que já existe quando a transação do diagrama tem início, é mostrado alinhado ao topo do diagrama, de forma a ficar acima da primeira seta de mensagem. Por outro lado, um objeto que continuará a existir, mesmo após a finalização da transação do diagrama, tem sua linha de vida estendida para além da última seta de mensagem.

A criação ou destruição de um objeto dentro do período de tempo total representado pelo diagrama são mostradas desenhando-se o início ou fim da linha de vida do objeto no ponto determinado pela criação ou destruição. No caso da criação, a seta que representa essa mensagem é desenhada de forma a apontar sua cabeça para o símbolo do objeto. No caso da destruição, a seta que carrega essa mensagem é direcionada a um grande "X" colocado no fim da linha de vida. As mensagens de criação e destruição podem ser estereotipadas com <<create>> e <<destroy>>, respectivamente.

Abaixo você tem um exemplo de um diagrama de seqüência para mostrar de forma simplificada o agendamento de um curso. Observe as criações de objetos, bem como as chamadas e retornos de métodos. Note que as expressões entre “[ ..]” representam condições que serão explicadas mais adiante.

7


Figura 6-8: Diagrama de seqüência com mensagens de retorno

8


Figura 6-9: Diagrama de Seqüência com a criação e retorno dos objetos

9


As mensagens são enviadas de um objeto a outro, por meio de setas que partem de uma linha de vida para outra. Essas setas são identificadas com o nome da operação que está sendo chamada. As mensagens podem carregar a solicitação de um processamento, a comunicação de um evento ou outras informações relevantes para o cumprimento de responsabilidades. A seqüência de mensagens pode ser numerada, mas seu uso é desnecessário nesse tipo de diagrama. Na figura acima você pode ver as mensagens numeradas sendo que os números ajudam no entendimento da ordem das mensagens.

Ao alcançar o outro lado, a seta dá início à ativação, que corresponde ao período de tempo durante o qual um determinado procedimento de um objeto está sendo executado. Essa ativação é mostrada graficamente como um retângulo fino e comprido, que tem sua parte superior alinhada ao final da seta ativadora e se estende até o fim do processamento, que pode ter uma representação extra com uma mensagem de retorno. A mensagem de retorno não é obrigatória. Os retornos são dados por uma linha pontilhada com uma sea na ponte partindo do receptor da mensagem para quem a chamou.

A seta de mensagem, além do nome da operação, também pode conter uma condição e/ou uma expressão de iteração (seqüência repetida de mensagens). Textos de identificação como restrições de tempo, descrições de ações durante uma ativação, entre outros, também podem ser mostrados na margem esquerda do diagrama ou perto dos elementos que eles identificam.

Condições são colocadas dentro de colchetes e determinam que a mensagem só será disparada se a condição for verdadeira. Por exemplo:

[instrutorOk] agendarCurso()

A iteração representa o envio da mesma mensagem diversas vezes para o mesmo objeto, sendo comum no tratamento de coleções de objetos. Vamos supor que tenho que chamar a operação calculaMedia() dos alunos da turma. Marcando a iteração para a mensagem calculaMedia(), indicamos que ela deve ser chamada várias vezes. A representação da iteração é feita dentro de colchetes, incluindo antes do colchete inicial o símbolo (*) – A notação de condição e iteração é a mesma para o diagrama de iteração. O texto dentro dos colchetes indica a condição que determinará quantas vezes a mensagem será passada. Por exemplo:

*[para cada aluno da turma] calcularMedia()*[para cada instrutor] instrutorOk := disponivel(data)

10


No caso de chamada recursiva (um objeto passa mensagem para si próprio), o segundo símbolo de ativação é desenhado levemente à direita do primeiro, dando a impressão de que estão empilhados. Essa chamada recursiva é denominada auto-chamada.

Num fluxo de controle procedural, a mensagem de retorno pode ser omitida, pois fica implícito que, ao final da ativação, o retomo ocorrerá, ou seja, assume-se que toda mensagem de chamada faz par com uma mensagem de retorno. Para fluxos de controle não-procedurais (como mensagens de processamento paralelo), mensagens de retorno devem ser mostradas explicitamente.

Na arrumação dos objetos, deve-se colocar como o primeiro objeto exatamente aquele que dá início à interação.

No diagrama de seqüências também representamos uma ramificação para condições ou concorrências, que é mostrada por múltiplas setas partindo de um ponto simples, sendo cada ramo identificado por uma condição. Dependendo de como as condições são mutuamente exclusivas, essa construção pode representar condicionalidade ou concorrência. Veja a figura abaixo:

Figura 6-10: Exemplo de ramificação de mensagens

11


Diagrama de colaboração

Os objetos são distribuídos no diagrama de colaboração na ordem similar à do diagrama de seqüências, obedecendo à seqüência de mensagens. A colaboração entre objetos é representada por uma ligação simples acompanhada de uma numeração sequencial e de outras informações como condições e iterações.

Em virtude da forma como um diagrama de colaboração é apresentado, identificamos a seqüência temporal das mensagens por meio de seqüências numéricas. A autochamada do diagrama de seqüências é identificado como autodelegação no diagrama de colaboração e representado como um arco ligado ao objeto.

Na figura abaixo, a primeira mensagem é a chamada do método obterGrade() para o objeto cursoX. O código deste método para ser concluído necessita de informações das disciplinas do referido curso e das turmas ativas. Então, para cada disciplina é chamado o método obterInfDisciplina() do objeto disc1. O objeto disc1, por sua vez, necessita de informações dos pré-requisitos das disciplinas. Então, passa uma mensagem para si mesmo, chamando o método obterPreRequisito(). O objeto cursoX, depois que recebe a resposta de sua mensagem n° 2, chama o método obterTurmasAtivas() que pertence ao objeto turma 1. Repare que uma grande diferença entre o Diagrama de Colaboração e o de Seqüências é exatamente o que ocorre com o objeto cursoX. Não fica explícito no diagrama as mensagens de retorno e o momento em que isso ocorre.

Figura 6-11: Diagrama de colaboração

12


Figura 6-12: Diagrama de colaboracão para o diagrama de classes

Figura 6-13: Diagrama de colaboracão com mensagens sequenciais

13


Figura 6-14: Diagrama de colaboracão com mensagens sequenciais aninhadas

14


Modelando diagramas de seqüências

O Diagrama de Seqüências é totalmente adequado para a identificação de operações de classes. Normalmente, durante o desenho dos diagramas, vamos percebendo as mensagens necessárias, e se elas não existirem como operações de classe, poderão ser incluídas neste momento.

O diagrama pode ser desenhado de forma gradativa, no qual a cada mensagem surgida, verifica-se a existência de um objeto instanciado ou não, procedendo sua criação, se necessário.

Condições são recursos interessantes no diagrama de seqüências, mas seu uso para separar cenários totalmente distintos pode dificultar a compreensão do diagrama.

O uso mais frequente para o diagrama de seqüências é o de representar cenários de um caso de uso. Vamos considerar o diagrama de classes da figura abaixo:

Figura 6-15 - Diagrama de Classes para exemplificação do Diagrama de Seqüências

Esse diagrama de classes refere-se a um Controle das vendas efetuadas por um conjunto de vendedores de uma loja de R$ 1,99. Nesse caso, não controlamos os produtos vendidos. Para tanto, vamos pensar no Caso de Uso Registrar vendas.

15


Registrar vendas

Objetivo: permite cadastrar as vendas efetuadas pêlos vendedoresAtor: Assistente de gerênciaCenário Principal1. O sistema prepara uma lista dos vendedores cadastrados na loja.2. O usuário informa o número da venda.3. O usuário informa, ainda:

3.1. a data da venda;3.2. o valor da venda;

4. O usuário seleciona o vendedor que efetuou a venda, a partir da lista já montada pelo sistema.5. O sistema efetua a gravação da venda.

Cenário AlternativoVenda já cadastrada2a. Se o número da venda já estiver cadastrado, informar ao usuário, mostrar as informações da venda na tela e entrar em modo de alteração dos dados.

A partir desses elementos, montamos o diagrama de seqüência com os objetos envolvidos no caso de uso mais o ator. Analisando o caso de uso percebemos a presença da Classe Venda com seus atributos e da Classe Vendedor, pois ninguém melhor do que ela para nos dizer quem são os vendedores ativos.

Vejamos a figura abaixo que apresenta o diagrama de seqüências que representa este caso de uso. Começamos o diagrama de seqüências com o ator Assistente de Gerência. Em seguida poderíamos colocar a instância da classe principal (Venda) ou fazer uso de uma instância de tela. Como o usuário, ao usar a classe, o faz via uma tela. Desta forma, desenhamos os objetos que representam instâncias da tela de cadastramento, da classe venda e da classe vendedor.

16


Figura 6-16: Exemplo de um diagrama de seqüências a partir de uma descrição de caso de uso

Conforme dito no caso de uso, a primeira ação é do sistema, obter uma lista de vendedores ativos. Assim, a instância de tela passa uma mensagem para o objeto da classe Vendedor, solicitando esta lista de vendedores. Depois de receber a resposta, o controle passa para o ator, que informa: o número da venda. O sistema, antes de permitir que o ator prossiga seu cadastro, verifica se a venda já foi cadastrada anteriormente, por meio do envio de uma mensagem de busca à classe Venda. Sendo positivo, o sistema mostrará os dados na tela, mas essa operação não precisa ser representada no diagrama de seqüências, já que foi devidamente detalhada no caso de uso. O ator informa a data e o valor. Em seguida, seleciona na lista montada o vendedor que efetuou a venda. Nada mais tendo para informar, cabe ao sistema (Logicamente que o sistema aguarda a confirmação do usuário para efetuar a gravação. Mas essa mensagem não precisa ser mostrada) efetuar a gravação da mesma, passando uma mensagem para a classe Venda.

17


Quando Utilizar Diagramas de Interação

Você deve utilizar diagramas de interação quando quiser observar o comportamento de vários objetos dentro de um único caso de uso. Esses diagramas de interação são bons para mostrar as colaborações entre objetos; eles não são tão bons para uma definição precisa de comportamento.

Se você quer observar o comportamento de um simples objeto através de muitos casos de uso, use um diagrama de estados. Se você quer observar o comportamento através de muitos casos de uso ou de muitas trilhas de execução (threads), considere um diagrama de atividades.

18


Exercícios

1 – Quais as principais diferenças entre diagrama de seqüência e diagrama de colaboração?

2 – Construa um diagrama de seqüência para representar o processo de entrega de um material didático

3 – Para o diagrama de seqüência da figura 69 faça um diagrama de colaboração

19



20


21


8.8. Diagramas FísicosDiagramas Físicos

1

Diagramas Físicos

Objetivos

Conhecer os diagramas físicos de componentes e implantação

Reconhecer os elementos destes diagramas

Saber quando utilizar estes diagramas

2

Diagramas Físicos

O que são diagramas físicos?

Diagramas de Físicos mostram aspectos de implementação física, incluindo a estrutura de componentes e a estrutura do sistema em tempo de execução (run-time)

Eles são expressos de duas formas:

Diagrama de ComponentesDiagrama de Implantação

O Diagrama de Componentes mostra a estrutura de componentes, incluindo os classificadores que eles especificam e os artefatos que eles implementam.

O Diagrama de Implantação mostra a estrutura de nós nos quais os componentes são implantados.

Esses diagramas também podem ser aplicados na modelagem de negócios, no qual os componentes representam artefatos e procedimentos de negócios e os nós de implantação representam a organização de unidades e recursos (humanos e outros) do negócio.

Vamos ver agora com mais detalhes estes diagramas, começaremos pelo diagrama de componentes.

3

Diagramas Físicos

Diagrama de Componentes

Um diagrama de componentes mostra as dependências entre componentes de software, incluindo os classificadores que eles especificam (isto é, classes de implementação) e os artefatos que eles implementam (isto é, arquivos de códigos-fonte, arquivos de código binário, arquivos executáveis, scripts).

Um diagrama de componentes representa o tipo e não a instância. Para mostrar instâncias de componentes, utilize um diagrama de implantação.

Um diagrama de componentes é um gráfico de componentes conectados por relacionamentos de dependência. Componentes podem ser conectados a outros componentes por compartimentos físicos representando relacionamentos de composição.

Classificadores que especificam componentes podem ser conectados a eles por compartimentos físicos ou por um relacionamento estereotipado <<reside>>. Outros-sim, artefatos que especificam componentes podem ser conectados a eles por compartimentos físicos ou por um relacionamento estereotipado <<implement>>.

Um diagrama contendo tipos de componente pode ser usado para mostrar dependências estáticas, como as dependências de compilação entre programas, que são mostradas como setas tracejadas (de dependência) de um componente cliente para um componente fornecedor que depende dele de alguma maneira.

Embora um componente não tenha suas próprias propriedades (isto é, atributos, operações), ele age como um container para outros classificadores que são definidos com propriedades. Componentes, tipicamente, expõem um conjunto de interfaces que representam os serviços providos pêlos elementos que neles residem. O diagrama pode mostrar essas interfaces e a chamada de dependências entre componentes, usando setas tracejadas dos componentes para as interfaces em outros componentes.

4

Diagramas Físicos

Componente

Um componente representa um módulo físico, implementável e substituível, que corresponde à parte de um sistema. Um componente encapsula a implementação e exibe um conjunto de interfaces.

Um componente corresponde às interfaces que ele expõe, interfaces essas que representam serviços providos pêlos elementos que residem no componente. Um componente pode ser implementado por um ou mais artefatos, tais como: arquivos binários, arquivos executáveis ou arquivos de script.

São tipos de componentes: os necessários para a execução de um sistema (.exe, .dll, etc), arquivos de código fonte, arquivos de dados, tabelas, etc.

É mostrado graficamente como um retângulo grande contendo dois pequenos retângulos sobrepostos, partindo de seu interior para o lado de fora do retângulo principal.

Figura 8-1 Representação gráfica de um componente

5

Diagramas Físicos

Diagrama de Implantação

Diagramas de implantação mostram a configuração de elementos de processamento em tempo de execução e os componentes de software, processos e objetos que são executados sobre eles. Instâncias de componentes de software representam manifestações em tempo de execução de unidades de código de software.

Para modelagem de negócios, os elementos de processamento em tempo de execução incluem trabalhadores e unidades organizacionais, e os componentes de software incluem procedimentos e documentos usados pêlos trabalhadores e unidades organizacionais.

Um diagrama de implantação é um gráfico de nós conectados por associações de comunicação. Os nós podem conter instâncias de componentes. Isto indica que o componente é executado dentro do nó.

Componentes podem conter instâncias de classificadores, que indicam que a instância reside no componente. Componentes são conectados a outros componentes por setas tracejadas de dependência (possivelmente por meio de interfaces). Isto indica que um componente usa os serviços de outros componentes. Um estereótipo pode ser usado para indicar uma dependência precisa, se necessário.

6

Diagramas Físicos

Nó

Um nó é um objeto físico que representa um recurso de processamento, frequentemente possuindo capacidade de processamento. Os nós incluem dispositivos de computação mas também recursos humanos ou recursos de processamento mecânico. Os nós podem ser representados como tipos e como instâncias.

Um nó é mostrado graficamente como uma figura que parece uma visão tridimensional de um cubo. Um nó possui um tipo-nó.

Uma instância de nó tem um nome e um nome de tipo. O nó pode ter um nome sublinhado, mostrado dentro ou abaixo dele. O nome do nó tem a sintaxe:

Nome : tipo-do-nó

As normas de apresentação do nó com seu tipo são similares à apresentação de objetos. Setas tracejadas com a palavra-chave <<deploy>> mostram a capacidade de um tipo-nó suportar um tipo-componente. Alternativamente, isto pode ser mostrado por símbolos de componentes aninhados dentro de símbolos de nó.

Instâncias de componentes e objetos podem estar contidos dentro de símbolos de instâncias de nós. Isto indica que os itens residem nas instâncias dos nós.

Nós podem ser conectados por associações para outros nós, por meio de um caminho de comunicação. A associação pode ter um estereótipo para indicar a natureza do caminho de comunicação (por exemplo: o tipo de canal ou rede). Veja abaixo a representação gráfica:

Figura 8-2: Rerpesentação gráfica de um Nó

7

Diagramas Físicos

Combinando Componentes com Diagramas de Utilização

Embora possa projetar em separado o diagrama de utilização e o diagrama de componentes, você também pode colocar o diagrama de componentes no diagrama de utilização, como na figura abaixo. Você pode fazer isso para mostrar quais componentes funcionam em que nós.

Figura 8-3: Componentes e nós juntos em um diagrama físico

8

Diagramas Físicos

As pessoas, projetam, frequentemente, estes tipos de diagramas com símbolos que se parecem com os vários elementos. Por exemplo, elas usam ícones especiais para servidores, PC e bancos de dados. Isso é válido em UML: você pode tratar cada ícone como um estereótipo de um elemento de diagrama apropriado. Geralmente, tais ícones facilitam a compreensão do diagrama, embora eles se tornem confusos se você mostrar nós e componentes juntos.

A arquitetura mostrada acima é de uma aplicação que estará armazenada em um J2EE Server central o qual será acessado via web pelos seus usuários. Nele terá uma página HTML com o link para rodar a aplicação. O usuário deverá pela primeira vez acessar esta página e clicar no link para que a aplicação seja baixada e instalada automaticamente pelo Java Web Start na máquina. Durante a instalação o Java Web Start irá perguntar se o usuário deseja criar um atalho no desktop do seu micro para futuramente rodar a aplicação. Desta forma as próximas execuções do software podem ser feitas clicando no ícone localizado no desktop, da mesma forma como as demais aplicações são executadas. Após ter sido baixado e instalado o programa passará a estar acessível para o usuário localmente na máquina. Não mais o usuário precisará esperar o download da aplicação para poder utilizá-la. O programa será armazenado localmente em uma espécie de cache do Java Web Start fazendo com que nas próximas execuções ele já esteja disponível e não precise ser baixado novamente. Caso seja atualizado algum módulo do sistema esta atualização deverá ser colocada no servidor J2EE central, onde antes de cada execução, se houver rede, o Java Web Start irá procurar por atualizações do software a fim de manter sempre o mesmo atualizado para o cliente. Caso haja alguma atualização esta será feita de forma transparente para o usuário.

Problema: Demanda máquinas mais robustas no lado do cliente; Requer a instalação do JRE no cliente.

Benefícios: Pode funcionar mesmo que não haja rede; Emissão de relatórios mais fácil.

9

Diagramas Físicos

Quando Utilizar Diagramas Físicos

A maioria das pessoas projeta este tipo de informação informalmente, mas as pessoas estão gradualmente formalizando os diagramas para se adaptarem a UML. Projeta-se estes diagramas sempre que preciso mostrar informação física que é diferente da informação lógica associada.

10

Diagramas Físicos

Exercícios

1 – Qual a finalidade do diagrama de componentes e do diagrama de implantação?

2 – Para o sistema acima monte um diagrama de componentes em conjunto com um diagrama de implantação consideranco que o sistema deverá ser em n-camadas. Para isto escolha uma tecnologia que você gostaria de implantar o mesmo e coloque os componentes de software necessários para rodar o mesmo.

11

Diagramas Físicos


12


9.9. Apêndice 1: ExtensibilidadeApêndice 1: Extensibilidade da UMLda UML

1

Apêndice: Extensibilidade da UML

Mecanismos de extensibilidade da UML

A UML é uma linguagem-padrão para a modelagem de sistemas orientados a objetos. Apesar de sua padronização predefinida, a UML oferece notações de extensão que permitem a ampliação de como podemos expressar nossos modelos. Basicamente, podemos encontrar duas formas de extensão da UML:

EstereótiposRestrições

2


Estereótipos

Os estereótipos são utilizados para a classificação de novos elementos na UML. O estereótipo é utilizado para a criação de classificações de elementos que não foram definidos como padrão, e deve ser utilizado para o tratamento de problemas específicos de modelagem. Os estereótipos são formados por palavras entre ângulos duplos “<<estereótipo>>". Segue uma lista de estereótipos predefinidos, que foram extraídos a partir do uso comum destes. Essa lista segue a seguinte classificação:

• Estereótipos para relacionamentos de dependências.• Estereótipos para classes.• Estereótipos para eventos e mensagens.• Estereótipos para componentes.• Estereótipos para relacionamentos de generalização.• Estereótipos para restrições.• Estereótipos para comentários.

Estereótipos para relacionamentos de dependências

<<access>>Especifica que o conteúdo público do pacote de destino está acessível ao espaço do nome do pacote de origem.

<<bind>>Especifica que a origem instância o template de destino, utilizando os parâmetros reais dados.

<<call>>Especifica que a operação de origem invoca a operação de destino.

<<derived>>Especifica que o elemento-origem é derivado do elemento-destino. Isso significa que o elemento-origem não é uma instância do elemento-destino, mas é uma instância de um outro elemento que é um subtipo ou uma subclasse do elemento-destino.

<<extend>>Especifica que um caso de uso tem um comportamento estendido a partir de um caso de uso-base.

<<friend>>Especifica que o elemento-origem tem visibilidade especial no elemento destino.

3


<<import>>Especifica que o conteúdo público do pacote-destino pode ser recebido e acessado por um pacote-origem.

<<include>>Especifica que comportamentos comuns a mais de um caso de uso devem ser captura em outro caso de uso que será utilizado pêlos casos de uso que lhe deram origem.

<<instanceof>>Especifica que o objeto de origem é uma instância do classificador de destino.

<<instantiate>>Especifica que as operações na classe de origem criam instâncias da classe de destino.

<<refine>>Especifica que a origem é um grau mais alto de abstração que o destino.

<<send>>Especifica que a operação de origem envia o evento destino.

<<trace>>Especifica que o destino é um antecessor histórico da origem.

Estereótipos para classes

<<actor>>Especifica um elemento que interage externamente com o sistema.

<<exception>>Especifica um evento que pode ser ativado ou capturado por uma operação de classe.

<<implementationClass>>Especifica a implementação de uma classe em uma linguagem de programação.

<<interface>>Coleção de operações que pode ser utilizado para definir os serviços que uma classe pode oferecer a outras.

<<powertype>>Especifica um classificador cujas instâncias de suas classes estão envolvidas em um relacionamento de generalização.

4


<<process>>Especifica um classificador cujas instâncias representam um fluxo pesado.

<<signal>>Especifica um estímulo assíncrono comunicado entre instâncias.<<stereotype>>Especifica que o classificador é um estereótipo que pode ser aplicado a outros elementos.

<<thread>>Especifica um classificador cujas instâncias representam um fluxo leve.

<<type>>Especifica uma classe abstraia que é utilizada somente para determinar a estrutura e o comportamento de um conjunto de objetos.

<<utility>>Especifica classes cujos atributos e operações são todos escopo de classes.

Estereótipos para eventos e mensagens

<<becomes>>Especifica que o objeto-destino é o mesmo objeto que o de origem, mas em um ponto adiante no tempo e com possíveis valores, estados ou papéis diferentes.

<<copy>>Especifica que o objeto de destino é uma cópia exata do objeto-origem, mas é independente.

<<create>>Especifica que o objeto-destino é criado pelo evento ou pela mensagem enviada pelo objeto-origem.

<<destroy>>Especifica que o objeto-destino é destruído pelo evento ou pela mensagem enviada pelo objeto-origem.

Estereótipos para componentes

<<table>>Especifica um componente que representa uma tabela de banco de dados no sistema.

5


<<documents>>Especifica um componente que representa um documento do sistema.

<<executable>>Especifica um componente que representa um componente que poderá ser executado no sistema.

<<file>>Especifica um componente que representa códigos-fonte ou dados.

<<library>>Especifica um componente que representa uma biblioteca de objetos.

Estereótipos para relacionamentos de generalização

<<implementation>>Especifica que o filho herda a implementação do pai, mas não a torna pública, nem oferece suporte para suas interfaces, violando dessa forma a característica de permitir substituições.

Estereótipos para restrições

<<invariant>>Especifica uma restrição que sempre precisa ser mantida para o elemento que está associado.

<<precondition>>Especifica uma condição que deve ser verdadeira antes da invocação de uma operação.

<<poscondition>>Especifica uma condição que deve ser verdadeira após o término da execução de uma operação.

Estereótipos para comentários

<<requirement>>Especifica uma característica ou comportamento desejado para um sistema.

<<responsability>>Responsabilidade ou obrigações que um elemento é encarregado de cumprir.

6


Restrições

As restrições ampliam o vocabulário dos elementos na UML, permitindo modificar ou acrescentar novas regras aos elementos do modelo. Por exemplo, por uma questão de regra de negócio, todos os clientes do tipo pessoa física devem ter obrigatoriamente o salário informado. Podemos expressar essa restrição como no exemplo a seguir. As regras devem ser expressa entre chaves {}.{ PessoaFisica.salário > O } Exemplo de uma restrição simples

Alguns padrões para restrição

A UML também define como padrão algumas restrições. Aqui segue uma lista com esses padrões com o elemento a qual se aplica.

Restrições para generalização

{complete}Especifica que todos os subtipos de um supertipo já foram especificados, não permitindo filhos adicionais.

{incomplete}Especifica que nem todos os subtipos de um supertipo foram totalmente especificados, permitindo filhos adicionais.

{overllaping}Especifica que subtipos de um supertipo podem ter mais de um filho como tipo.

Restrições para instâncias

{destroyed}Especifica que a instância deve ser destruída antes da conclusão da interação da qual ela faz parte.

{new}Especifica que a instância deve ser criada durante a execução da interação da qual ela faz parte.

{transient}Especifica que a instância deve ser criada durante a execução da interação da qual ela faz parte, mas é destruída antes da conclusão da execução.

7


Glossário

abstraçãoCaracterística essencial de uma entidade que a diferencia de todos os outros tipos.

agregaçãoTipo de associação na qual um todo é relacionado com suas partes (relacionamento todo/parte).

agregadaClasse que representa o "todo" no relacionamento de agregação.

arquiteturaArquitetura de sistemas é um conjunto de decisões sobre artefatos e elementos que formaram o sistema. A arquitetura deve abranger como será construído o sistema, seus elementos estruturais e comportamentais, suas colaborações, etc.

artefatoConjunto de informações utilizado ou realizado por um processo de desenvolvimento de sistemas de software.

assinaturaNome, parâmetros e valores de retomo de uma operação.

associaçãoAssociação descrê vê relacionamentos entre objetos. Cada associação tem duas pontas, onde em cada ponta está ligado um objeto.

atividadeEstado de execução de alguma coisa. Pode ser, por exemplo, a execução de um método em uma classe, uma rotina de trabalho, etc.

atorPapel desempenhado por qualquer usuário de um caso de uso, ou seja, o ator é quem solicita os serviços disponíveis em casos de uso.

atributoAtributo é uma propriedade de classe. Representa as características próprias de uma abstração.

autochamadaMensagem que um objeto envia para si mesmo.

característica comportamentalCaracterística dinâmica de um elemento, como uma operação ou um método.

8


característica estruturalCaracterística estrutural (estática) de um elemento.

cardinalidadeNúmero de elementos existentes em um conjunto.

caso de usoDocumento que descreve os cenários pretendidos para um sistema, com o objetivo de atender as necessidades do usuário.

classeAbstração de um conjunto de objetos que compartilham os mesmos atributos, operações e relacionamentos.

colaboraçãoNome dado à interação entre duas ou mais classes, com o objetivo de fornecer algum comportamento cooperativo.

componenteParte física de um sistema, que representa elementos lógicos para a realização de uma ou mais interfaces.

comportamentoResultados produzidos por eventos e métodos.

composiçãoForma de agregação, em que o objeto-parte pode pertencer somente ao objeto-todo. Além disso, geralmente o objeto-todo vive e morre com suas partes, isto é, acontece uma remoção em cascata

containerObjeto que existe para conter outros objetos e que proporciona operações para acessar ou interagir com seu conteúdo.

delegaçãoHabilidade de um objeto enviar uma mensagem a um outro objeto como resposta a uma mensagem recebida.

dependênciaRelacionamento entre dois itens, em que a alteração do item independente pode alterar a semântica do item dependente.

destinatárioObjeto que manipula a instância de uma mensagem passada pelo objeto emissor.

diagramaRepresentação gráfica de um conjunto de elementos do sistema, que permite a visualização do sistema sob diferentes perspectivas.

9


diagrama de atividadesRepresenta um fluxo de controle de atividades, que ocorrem no processo de um sistema, oferecendo suporte para comportamentos condicionais e paralelos

diagrama de casos de usoRepresenta um conjunto de cenários identificados, que seja útil aos usuários de um sistema.

diagrama de classesRepresenta o modelo da estrutura de um sistema orientado a objetos, demonstrando as classes, os tipos e os relacionamentos.

diagrama de colaboraçãoUm dos diagramas de interação que dá ênfase à organização estrutural dos objetos que colaboram entre si.

diagrama de componentesRepresenta os componentes que farão parte dos sistemas em construção, demonstrando as dependências entre esses componentes.

diagrama de gráficos de estadosRepresenta os estados possíveis de um objeto em particular. São demonstrados os estados de um objeto, eventos, transições e atividades.

diagrama de implantaçãoRepresenta a configuração e a arquitetura de um sistema a que estarão ligados seus respectivos componentes, podendo ser representada também a arquitetura física de hardwares, processadores, etc.

diagrama de objetosRepresenta a modelagem de instâncias das classes de um sistema em determinado ponto e momento de execução.

diagrama de seqüênciaUm dos diagramas de interação que dá ênfase à ordenação sequencial em que os comportamentos acontecem.

encapsulamentoMecanismo usado para ocultar os dados, a estrutura interna e os detalhes de implementação de um objeto. Toda a interação com um conjunto de objetos é feita de uma interface pública constituída de operações.

estadoSituação vivida por um objeto, pela qual esse objeto deve responder algo aos eventos gerados.

estereótipoExtensão do vocabulário da UML que permite a criação de novos tipos de blocos de construção, para atender necessidades específicas de um modelo.

10


estímuloEvento gerado no sistema que necessita de resultados.

eventoOcorrência de um estímulo gerado para o objeto, capaz de fazer a mudança de seu estado atual.

exportarTornar visível um elemento fora do espaço do nome que o contém.

expressãoSeqüência de caracteres que tem como resultado um valor.

expressão booleanaTem como resultado um valor booleano.

filhaSubclasse.

foco de controleIndicador do período de duração pelo qual os objetos estão cooperando para realizar um comportamento.

generalizaçãoÉ a capacidade de se criar superclasses que encapsulam a estrutura e o comportamento comum a várias subclasses.

herançaMecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento de elementos mais gerais.

herança múltiplaUma variação da generalização, em que uma subclasse pode herdar a estrutura e o comportamento de mais de uma superclasse.

hierarquia de classesRepresenta descrições das relações de herança entre classes.

implementaçãoRealização concreta do contrato declarado por uma interface ou a definição de como algo é construído ou computado.

incompletoModelagem de um elemento em que faltam certas partes.

instânciaManisfestação concreta de alguma abstração, uma entidade à qual um conjunto de operações pode ser aplicado e que tem um estado para armazenar o efeito das operações.

11


integridadeRelacionamento consistente e apropriado entre dois ou mais elementos.

interaçãoConjunto de objetos que interagem por meio da troca de mensagens, para a realização de um comportamento.

linha de vida do objetoRepresenta a existência de um objeto em uma interação.

mãeSuperclasse.

máquina de estadosSeqüência de estados pela qual um objeto passa durante seu tempo de vida.

mecanismos de extensabilidadeUm dos mecanismos que permite a extensão da UML de maneira organizada.

mensagemMeio de comunicação entre objetos que contêm informações à espera de atividades que acontecerão.

métodoImplementação de uma operação para uma classe.

modeloSimplificação da realidade, criado com a finalidade de proporcionar uma melhor compreensão do sistema que será gerado.

multiplicidadeIndicação de quantos objetos podem participar de um dado relacionamento.

nóElemento físico existente em tempo de execução que representa um recurso computacional.

notaRepresenta comentários, observações e esclarecimentos que se podem utilizar para qualquer elemento da UML.

objetoSinónimo de instância de classe, sendo uma manifestação concreta de uma abstração com uma identidade que encapsula estados e comportamentos.

objeto persistenteObjeto que sobrevive após o término de execução de um processo ou um thread.

12


objeto transienteObjeto que sobrevive somente até o término de execução de um processo ou um thread.operaçãoProcedimento de chamada em um objeto.

operação polimórficaUma mesma operação que é implementada de maneira diferente por dois ou mais tipos.

orientado a casos de usoProcesso pelo qual os casos de uso são utilizados como artefatos primários para o estabelecimento do comportamento desejado do sistema, para verificar e validar a arquitetura de um sistema.

pacotesOrganizam os modelos criados na UML.

paiSuperclasse.

papelComportamento de uma entidade que participa de determinado contexto no sistema.

parâmetroEspecificação de uma variável que pode ser alterada, passada ou retornada.

polimorfismoConceito segundo o qual dois ou mais tipos de objetos podem responder à mesma mensagem de maneiras diferentes, usando operações polimórficas.

pós-condiçãoAlgo que necessita ser verdadeiro após a chamada de uma operação.

pré-condiçãoAlgo que necessita ser verdadeiro antes da chamada de uma operação.

privadoMecanismo de escopo usado para restringir o acesso a atributos e operações de uma classe, de maneira que outros objetos não possa utilizá-los.

produtoArtefatos de desenvolvimento, como códigos, modelos, documentação gerada, etc.

propriedadeCaracterística de um elemento da UML.

público

13


Mecanismo de escopo usado para tornar atributos e operações de classes acessíveis a outros objetos.

raia de nataçãoOrganiza as atividades representadas em diagramas de atividades. Essa organização consiste em criar grupos que são responsáveis pelas atividades ocorridas.

realizaçãoRelacionamento entre itens, no qual um item implementa comportamentos especificados por outros.

receptorObjeto ao qual é enviada uma mensagem.

refinamentoRelacionamento que representa a especificação completa de algo já especificado em determinado nível de detalhe.

relacionamentosConexão semântica entre elementos.

responsabilidadeContrato ou obrigação em um tipo ou de uma classe.

restriçãoExtensão da semântica de um elemento da UML, permitindo criar ou modificar regras já existentes.

solicitaçãoEspecificação de um estímulo enviado a um objeto.

subclasseElemento que recebe por herança a estrutura e os comportamentos de uma superclasse.

superclasseElemento que contém a estrutura e o comportamento generalizado de outras classes (as subclasses).

threadFluxo leve de controle que pode ser executado concorrentemente com outros threads no mesmo processo.

tipoEstereótipo de uma classe, utilizado para especificar um domínio de objetos, com as operações que podem ser aplicadas aos objetos.

transição

14


Relacionamento entre dois estados, em que o objeto no seu estado atual deve realizar atividades para passar para um outro estado, desde que as atividades tenham sido cumpridas.

UML (Unified Modeling Language)Linguagem de modelagem unificada para visualização, especificação, construção e documentação de artefatos de sistemas de software.

valor atribuídoExtensão das propriedades de um elemento da UML, que permite a criação de novas informações na especificação desse elemento.

versãoUm conjunto de artefatos de software, relativamente completos e consistentes que serão entregues.

visãoProjeção em um modelo, vista a partir de determinada perspectiva ou ponto de vista, que omite as entidades que não são relevantes para essa visão.

visão dinâmicaAspectos de um sistemaque dão ênfase a comportamentos.

visão estáticaAspectos de um sistema que dão ênfase à estrutura.

visibilidadeEspecificação de como uma característica ou um comportamento especificado para uma classe podem ser vistos por outros objetos de classe.

15


10.10. Apendice 2: DiagramasApendice 2: Diagramas UML dos exercicíciosUML dos exercicícios

1


2


3


4


5


6


7


8


9


10

Documents

Apostila Para Curso de UML