uml

UML18 de abril de 2007

Sumário

I Sobre essa Apostila 3

II Informações Básicas 5

III UML 10

1 O que é UML 11

2 Plano de ensino 122.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Introdução 153.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Conceitos Iniciais 174.1 Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Diagramas Estruturais 185.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Diagramas de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4 Diagrama de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.5 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.6 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.6.1 Diagrama de Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.6.2 Diagrama de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF

6 Diagramas Comportamentais 246.1 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 Diagrama de Seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.5 Diagrama de Colaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.6 Diagrama de Gráfico de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.7 Diagramas de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2

Parte I

Sobre essa Apostila

3


Conteúdo

O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-ternet, disponíveis em diversos sites ou originalmente produzido no CDTC em http://www.cdtc.org.br.

O formato original deste material bem como sua atualização está disponível dentro da licençaGNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção demesmo nome, tendo inclusive uma versão traduzida (não oficial).

A revisão e alteração vem sendo realizada pelo CDTC ([email protected]) desde outubrode 2006. Críticas e sugestões construtivas são bem-vindas a qualquer tempo.

Autores

A autoria deste é de responsabilidade de Beatriz Marília Ferreira Ribeiro ([email protected]).

O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento, quevem sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto comoutros parceiros institucionais, atuando em conjunto com as universidades federais brasileirasque tem produzido e utilizado Software Livre, apoiando inclusive a comunidade Free Softwarejunto a outras entidades no país.

Informações adicionais podem ser obtidas através do email [email protected], ou dahome page da entidade, através da URL http://www.cdtc.org.br.

Garantias

O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizamdireta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.

Licença

Copyright ©2006, Instituto Nacional de Tecnologia da Informação ([email protected]) .

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.1 or any later version published bythe Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-TILA. A copy of the license is included in the section entitled GNU Free DocumentationLicense.

4

Parte II

Informações Básicas

5


Sobre o CDTC

Objetivo Geral

O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito dodesenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.

Objetivo Específico

Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário ede código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre osservidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercadonacional a adotar novos modelos de negócio da tecnologia da informação e de novos negóciosde comunicação com base em software não-proprietário e de código fonte aberto, oferecendotreinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar comoincentivadores e defensores de produtos de software não proprietários e código fonte aberto, ofe-recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento deprodutos de software não proprietários e de seu código fonte livre, articulando redes de terceiros(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-dutos de software livre.

Guia do aluno

Neste guia, você terá reunidas uma série de informações importantes para que você comeceseu curso. São elas:

• Licenças para cópia de material disponível

• Os 10 mandamentos do aluno de Educação a Distância

• Como participar dos foruns e da wikipédia

• Primeiros passos

É muito importante que você entre em contato com TODAS estas informações, seguindo oroteiro acima.

Licença

Copyright ©2006, Instituto Nacional de Tecnologia da Informação ([email protected]).

6


É dada permissão para copiar, distribuir e/ou modificar este documento sob os termosda Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posteriorpúblicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSAAPOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-mentação Livre GNU".

Os 10 mandamentos do aluno de educação online

• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado épré-requisito para a participação nos cursos a distância.

• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-tica é necessário para poder executar as tarefas.

• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,dos colegas e dos professores.

• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seuscolegas de turma respeitando-os e fazendo ser respeitado pelo mesmo.

• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisãoe a sua recuperação de materiais.

• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações erealizá-las em tempo real.

• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre.

• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagense descobertas.

• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente éponto - chave na comunicação pela Internet.

• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual nãocontrola a sua dedicação, mas reflete os resultados do seu esforço e da sua colaboração.

Como participar dos fóruns e Wikipédia

Você tem um problema e precisa de ajuda?

Podemos te ajudar de 2 formas:

A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:

. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informaçõesque sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a

7


todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação queinteresse ao grupo, favor postá-la aqui.Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico docurso. É recomendado que você faça uso do Forum de dúvidas gerais que lhe dá recursos maisefetivos para esta prática.

. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativopara solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadasa todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podemajudar.Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com aformalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópicoé recomendável ver se a sua pergunta já foi feita por outro participante.

A segunda forma se dá pelas Wikis:

. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podemser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece umótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, porpessoas de todas as partes do mundo. Acesse-a em português pelos links:

• Página principal da Wiki - http://pt.wikipedia.org/wiki/

Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!

Primeiros Passos

Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:

• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;

• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar dasferramentas básicas do mesmo;

• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;

• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.

Perfil do Tutor

Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.

O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivosvalores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita asidéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.

8


A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutorou instrutor:

• fornece explicações claras acerca do que ele espera, e do estilo de classificação que iráutilizar;

• gosta que lhe façam perguntas adicionais;

• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-que motivo a classificação foi ou não foi atribuída’;

• tece comentários completos e construtivos, mas de forma agradável (em contraste com umreparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, deameaça e de nervossismo’)

• dá uma ajuda complementar para encorajar um estudante em dificuldade;

• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;

• ajuda o estudante a alcançar os seus objetivos;

• é flexível quando necessário;

• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,talvez numa fase menos interessante para o tutor);

• escreve todas as correções de forma legível e com um nível de pormenorização adequado;

• acima de tudo, devolve os trabalhos rapidamente;

9

Parte III

UML

10

Capítulo 1

O que é UML

A UML (Unified Modeling Language) é uma linguagem de modelagem livre que permite quedesenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Ela foicriada para padronizar a forma de especificação de projetos de desenvolvimento de software.Utiliza-se UML para documentação, especificação, construção e visualização de sistemas.

11

Capítulo 2

Plano de ensino

2.1 Objetivo

Capacitar o usuário para o uso autônomo da linguagem UML.

2.2 Público Alvo

Pessoas envolvidas em qualquer etapa de tarefas de desenvolvimento de software.

2.3 Pré-requisitos

Os usuários deverão ser, necessariamente, funcionários públicos e ter conhecimentos básicospara operar um computador e de lógica de programação.

2.4 Descrição

O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodlecomo ferramenta de aprendizagem. O curso tem duração de uma semana e possui um conjuntode atividades (lições, fóruns, glossários, questionários e outros) que deverão ser executadas deacordo com as instruções fornecidas. O material didático está disponível on-line de acordo comas datas pré-estabelecidas em cada tópico.

2.5 Metodologia

O curso está dividido da seguinte maneira:

Duração Descrição do Módulo1 semana Lição 1 - Introdução

Lição 2 - Conceitos IniciaisLição 3 - Diagramas EstruturaisLição 4 - Diagramas Comportamentais

12


Todo o material está no formato de lições, e estará disponível ao longo do curso. As liçõespoderão ser acessadas quantas vezes forem necessárias. Aconselhamos a leitura de "Ambien-tação do Moodle", para que você conheça o produto de Ensino a Distância, evitando dificuldadesadvindas do "desconhecimento"sobre o mesmo.

Ao final de cada semana do curso será disponibilizada a prova referente ao módulo estudadoanteriormente que também conterá perguntas sobre os textos indicados. Utilize o material decada semana e os exemplos disponibilizados para se preparar para prova.

Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deve serdisponibilizada no fórum ou enviada por e-mail. Diariamente os monitores darão respostas eesclarecimentos.

2.6 Programa

O curso de UML oferecerá o seguinte conteúdo:

• Conceitos iniciais

• Diagramas estruturais

• Diagramas comportamentais

2.7 Avaliação

Toda a avaliação será feita on-line.Aspectos a serem considerados na avaliação:

• Iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;

• Capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.

Instrumentos de avaliação:

• Participação ativa nas atividades programadas.

• Avaliação ao final do curso.

• O participante fará várias avaliações referente ao conteúdo do curso. Para a aprovação eobtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordocom a fórmula abaixo:

• Nota Final = ((ML x 7) + (AF x 3)) / 10 = Média aritmética das lições

• AF = Avaliações

2.8 Bibliografia

• Site oficial: http://www.uml.org/

• Wikipedia: http://pt.wikipedia.org/wiki/UML

13


• Manual do Umbrello UML Modeller: http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-basics.html

• http://inf.unisul.br/ osmarjr/download/

• http://www.ucb.br/ucbtic/mgcti/paginapessoalprof/Nicolas/Disciplinas/UML/node8.html

• osé Carlos Macoratti: http://www.macoratti.net/vb_uml2.htm

14

Capítulo 3

Introdução

3.1 Introdução

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária deterceira geração, dou seja, uma linguagem projetada para ser facilmente entendida por pessoas,com suporte a nomes e variáveis. A UML não é um método de desenvolvimento, o que significaque ela não diz para você o que fazer primeiro e em seguida ou como desenhar seu sistema, masela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho emdiagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados,isto é, semântica. É uma notação independente de processos, embora o RUP (Rational UnifiedProcess) tenha sido especificamente desenvolvido utilizando a UML.

É importante distinguir entre um modelo UML e um diagrama (ou conjunto de diagramas) deUML, o último é uma representação gráfica da informação do primeiro, mas o primeiro pode existirindependentemente. O XMI (XML Metadata Interchange) na sua versão corrente disponibilizatroca de modelos mas não de diagramas.

A UML (Unified Modeling Language) é uma linguagem para especificação, documentação,visualização e desenvolvimento de sistemas orientados a objetos. Sintetiza os principais méto-dos existentes, sendo considerada uma das linguagens mais expressivas para modelagem desistemas orientados a objetos. Por meio de seus diagramas é possível representar sistemas desoftwares sob diversas perspectivas de visualização. Facilita a comunicação de todas as pessoasenvolvidas no processo de desenvolvimento de um sistema - gerentes, coordenadores, analistas,desenvolvedores - por apresentar um vocabulário de fácil entendimento.

3.2 História

A UML tem origem na compilação das "melhores práticas de engenharia"que provaram tersucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch,OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comume largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelarsistemas concorrentes e distribuídos.

A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os aus-pícios do Object Management Group (OMG). O OMG pediu informação acerca de metodologiasorientadas a objetos que pudessem criar uma linguagem rigorosa de modelização de software.Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.

15


Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh sejuntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido umano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado(como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo doprojeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996,a versão 0.9 da UML.

16

Capítulo 4

Conceitos Iniciais

4.1 Diagramas

Um diagrama é uma representação gráfica de um sistema sob determinada visão. Existemdiversos motivos para utilizá-los. Eles são úteis na documentação, tornando a manutenção maisfácil, ajudam a compreender melhor os requisitos de um sistema antes de implementá-lo, simpli-ficam o entendimento de sistemas comlpexos usando a técnica de dividir para conquistar.

Os diversos diagramas da UML podem ser divididos em dois grandes grupos, os diagramasestruturais e os comportamentais. Nas duas lições seguintes você aprenderá um pouco sobrecada um desses diagramas.

Estruturais:

• Diagrama de classes

• Diagrama de componentes

• Diagrama de objetos

• Diagrama de artefatos

• Diagrama de implantação

Comportamentais

• Diagrama de casos de uso

• Diagrama de seqüência

• Diagrama de colaboração

• Diagrama de gráfico de estados

• Diagrama de atividades

4.2 Programas

Para facilitar a tarefa de modelagem é preferível que você utilize um programa específico paradesenhar diagramas em UML. Existem muitos programas livres que fazem isto, entre eles estão oJude, que pode ser baixado no endereço http://jude.change-vision.com/jude-web/download/index.html,e o Umbrello, que pode ser instalado com o comando "apt-get install umbrello".

17

Capítulo 5

Diagramas Estruturais

5.1 Classes

Na lógica de programação orientada a objetos uma classe é uma abstração de um conjuntode objetos com as mesmas características (atributos, operações, relacionamentos e semântica).Uma classe define os atributos de seus objetos e métodos.

Os atributos são elementos das classes semelhantes as variáveis da lógica de programaçãoestruturada. Cada atributo representa uma propriedade do item que está sendo modelado. Paracada atributo é definido um intervalo de valores possíveis. Por exemplo, a classe funcionário podeter os atributos nome, endereço, telefone, número de identidade, salário, cargo.

Na UML, os Atributos são mostrados como tendo o seu nome, pelo menos, e poderão mostrartambém o seu tipo, o seu valor inicial e outras propriedades. Os atributos também poderão sermostrados com a sua visibilidade:

• + Representa atributos públicos

• # Representa atributos protegidos

• - Representa atributos privados

Veja a seguir a representação de uma classe com seus atributos na linguagem UML:

Além de atributos as classes têm métodos. Um método é uma operação que pode ser exe-cutada sobre os objetos de uma classe. São os métodos que executam todas as funcionalidadesdo programa, como fazer cálculos, exibir mensagens, gerar relatórios, etc.

As operações (métodos) são também mostradas contendo pelo menos o seu nome e poderãotambém mostrar os seus parâmetros e tipos de valor devolvidos. As operações podem, assimcomo os Atributos, mostrar a sua visibilidade:

18


• + Corresponde a operações públicas

• # Corresponde a operações protegidas

• - Corresponde a operações privadas

A próxima figura mostra a representação em UML para uma classe com as operações latir, mordere comer.

5.2 Relacionamentos

RelacionamentosAlém de identificar as classes do seu sistema será preciso representar os relacionamentos

que existem entre elas. Há três tipos de relacionamentos: dependências, generalizações e asso-ciações.

DependênciaUma dependência é um relacionamento em que um item usa dados e serviços de outro item.

Representa-se uma dependência em UML com uma linha tracejada apontando do item que de-pende de alguma informação para o que a fornece. Generalização

Uma generalização é um relacionamento entre itens gerais e itens mais específicos. Essetipo de relacionamento indica que objetos da classe específica podem ser utilizados em qualquerlugar onde a classe geral ocorra. A classe específica, que pode ser chamada de filha, herda todasas características da classe geral, ou classe mãe. Isto é, a filha tem todos os atributos e todos osmétodos da classe geral. Ela pode ter também atributos e métodos próprios, que não estão naclasse mãe. Na UMl representa-se uma generalização com uma linha que aponta da filha para amãe.

19


AssociaçãoUma associação representa uma relação entre classes e dá a semântica e a estrutura comum

para vários tipos de "ligações"entre os objetos.As associações são o mecanismo que permite aos objetos comunicarem uns com os outros.

Descreve a ligação entre as diferentes classes (a ligação entre os objetos em si é chamada deligação do objeto.

As associações podem ter um papel que indica o objetivo da associação e pode ser unidi-reccionais ou bidireccionais (indica se os dois objetos que participam na relação poderão enviarmensagens um para o outro, ou se só um deles é que conhece o outro). Cada extremo daassociação também tem um valor de multiplicidade, que define quantos objetos desse lado daassociação poderão se relacionar com um objeto do outro lado.

No UML, as associações são representadas como linhas que ligam as classes que participamna relação e poderá também mostrar o papel e a multiplicidade de cada um dos participantes.A multiplicidade é mostrada como um intervalo [mín..máx] de valores não-negativos ou com umasterisco (*) no lado do máximo que representa o infinito.

AgregaçãoAs agregações são um tipo especial de associações nas quais as duas classes participantes

não têm um estado igual, mas têm uma relação "do ’todo’ para as partes". Uma agregação dizcomo é que a classe que têm o papel do ’todo’ é composta (ou tem) as outras classes, quetêm o papel das partes. Para as agregações, a classe que atua como o ’todo’ tem sempre umamultiplicidade de um.

No UML, as agregações são representadas por uma associação com um losango do lado do’todo’.

ComposiçãoAs composições são associações que representam agregações muito fortes. Isto significa que

as composições formam também relações do ’todo’ para as partes, mas a relação é tão forte queas partes não podem existir por si só. Elas só existem dentro do todo e se o todo for destruído,as partes desaparecem também.

No UML, as Composições são representadas por um losango a cheio do lado do ’todo’.

20


5.3 Diagramas de classes

Os Diagramas de Classes mostram as diferentes classes que compõem um sistema e comoelas se relacionam umas com as outras. Os Diagramas de Classes são apontados normalmentecomo "estáticos"porque mostram as classes, em conjunto com os seus métodos e atributos, assimcomo as relações estáticas entre elas, quais as classes que "conhecem"outras classes ou que"fazem parte"de outra classe, mas não mostram as chamadas de métodos entre elas.

Diagramas de Classe podem conter diversos outros itens além das classes:

InterfacesInterfaces são classes abstratas que significam instâncias que não podem ser diretamente

criadas delas. Elas podem conter operações mas não podem conter atributos. Classes podemderivar de interfaces (através da realização de uma associação) e instâncias podem então serfeitas destes diagramas.

Tipos de dadosTipos de dados são primitivos uma vez que são tipicamente construídos numa linguagem de

programação. Exemplos comuns são inteiros e lógicos. Eles não podem ser relacionados à clas-ses mas classes podem se relacionar com eles.

EnumeraçõesEnumerações são uma lista simples de valores. Um exemplo típico é uma enumeração para

dias da semana. As opções de uma enumeração são chamadas Literais de Enumeração. Comotipos de dados, elas não podem ter relacionamentos para classes mas classes podem relacionar-se com elas.

PacotesPacotes representam um espaço de nomes numa linguagem de programação. Num diagrama

eles são usados para representar partes de um sistema que contém mais de uma classe, talvezcentenas de classes. Veja na figura a seguir um exemplo de um diagrama de classes:

5.4 Diagrama de Objetos

ObjetosOs objetos são instanciações de classes. Enquanto as classes são abstrações, os objetos

existem no mundo real. Um objeto representa uma entidade que pode ser física, conceitual ou desoftware. É uma abstração de algo que possui fronteira definida e significado para a aplicação.

21


Na UML a representação de um objeto é quase igual a de uma classe. A única diferença é que onome dos objetos aparecem sublinhados, como na figura a seguir. Se você quiser pode escrevero nome da classe depois do nome do objeto para que fique mais claro a que classe ele pertence.

Diagrama de ObjetosO diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma

notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados dasclasses. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento desua execução.

A mesma notação do diagrama de classes é utilizada com duas exceções: os objetos sãoescritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas.Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles sãomuito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compre-ensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração,onde a colaboração dinâmica entre os objetos do sistema são mostrados.

5.5 Diagrama de Componentes

Componente de Software é o termo utilizado para descrever o elemento de software que en-capsula uma série de funcionalidades. Um componente é uma unidade independente, que podeser utilizado com outros componentes para formar um sistema mais complexo. Em progamaçãoorientada a objetos um componente é o objeto que implementa uma interface e é autônomo emrelação a outros componentes do sistema. Na UML existem cinco estereótipos de componentes:executável, biblioteca, tabela, documento e arquivo. A figura abaixo mostra a representação deum componente na UML:

Um diagrama de componentes ilustra os componentes de software e os relacionamenos en-tre eles, representando a estrutura do código gerado. O diagrama de componentes não mostrainstâncias de componentes, mostra apenas componentes como tipos. As instâncias de com-ponentes são mostradas no diagrama de execução. As dependências entre componentes sãorepresentadas por uma linha tracejada apontando para o componente que fornece a informaçãoda qual o outro precisa, assim como no diagrama de classes.

O diagrama de componentes é utilizado para:

22


• Modelar os componentes do código-fonte, do código executável do software.

• Organizar o código fonte, mostrando as dependências entre os diferentes arquivos fontede modo que fique claro quais arquivos precisarão ser recompilados quando for feita umamodificação em algum deles.

• Destacar a função de cada módulo para facilitar a sua reutilização.

• Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sis-tema e seus relacionamentos.

5.6 Diagrama de Componentes

5.6.1 Diagrama de Artefatos

Um artefato é o produto de uma ou mais atividades dentro do contexto do desenvolvimentode um sistema. Pode ser um documento de texto, código fonte, um programa executável, umabiblioteca, etc.

O diagrama de artefatos mostra a organização dos artefatos do sistema e o relacionamentoentre eles. Geralmente os diagramas de artefatos são utilizados para a modelagem de um dosseguintes itens:

• Código fonte

• Versões executáveis

• Bancos de dados físicos

• Sistemas adaptáveis

5.6.2 Diagrama de Implantação

O diagrama de implantação mostra a organização do hardware do sistema. Ele é utilizado paraa representação de sistemas distribuídos (sistemas que utilizam vários computadores ligados emrede), mostrando quais processos serão executados em cada máquina. Neste diagrama cadamáquina é chamada de nó. Pode-se dizer que os diagramas de implatação são diagramas declasses que mostram os nós do sitema e os artefatos que existem neles.

23

Capítulo 6

Diagramas Comportamentais

6.1 Atores

Os atores representam os usuários do sistema, eles podem ser pessoas, dispositivo de hard-ware ou outro sistema. Por exemplo, em uma escola pode haver os atores aluno, professor, dire-tor, coordenador, representante de turma, etc. Também podem ser atores o sistema de cobrançasque envia emails aos pais, o sistema de cálculo das notas, etc. Cada ator tem determinados pa-péis dentro do sistema.

Atores não representam as pessoa físicas ou sistemas, mas sua regra. Isto significa quequando uma pessoa interage com o sistema de diferentes maneiras (assumindo diferentes regras)ela será representada por diversos atores. Por exemplo um pessoa que fornece suporte ao clientepor telefone e recebe ordens do cliente para o sistema pode ser representado por um ator da"Equipe de Suporte"e um ator "Representante de Vendas"

Na figura abaixo é mostrada a representação de atores na UML.

6.2 Casos de Uso

Um caso de uso descreve uma funcionalidade provida pelo sistema, um grupo de atividadesnum sistema que produz um resultado concreto e tangível. Casos de Uso são descrições de inte-rações típicas entre os usuários de um sistema e o sistema propriamente dito. Eles representama interface externa do sistema e especificam um conjunto de exigências do que o sistema devefazer (lembre-se: somente o quê, não como).

O conjunto de casos de uso representa todas as funções do sistema. Ele não deve fazer nadaalém do que é descrito nos casos de uso, ou melhor, não deve haver nenhuma funcionalidadeque não é descrita pelos casos de uso.

24


Quando trabalhar com Casos de Uso, é importante lembrar-se de algumas regras simples:

• Cada Caso de Uso está relacionado com no mínimo um ator

• Cada Caso de Uso possui um iniciador (isto é um ator)

• Cada Caso de Uso liga-se a um resultado relevante (um resultado com "valor de negócio")

Casos de Uso também podem ter relacionamentos com outros Casos de Uso. Os três tiposmais comuns de relacionamento entre Casos de Uso são:

• «inclui-se» que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso

• «estende» que especifica que em determinadas situações, ou em algum ponto (chamadoum ponto de extensão) um Caso de Uso será estendido por outro.

• Generalização especifica que um Caso de Uso herda as características do "Super"Caso deUso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herançaentre classes.

Na UML os casos de uso são representados por elipses.

Descrição do Caso de UsoDescrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente tomam a

forma de uma nota ou um documento que é de alguma maneira ligado ao Caso de Uso, e explanao processo ou atividades que tomarão lugar no Caso de Uso.

6.3 Diagrama de Casos de Uso

O diagrama de casos de uso ilustra os comportamentos que o programa terá quando estiverpronto. Ele descreve relacionamentos e dependências entre um grupo de Caso de Uso e osAtores participantes no processo.

Quando há uma comunicação entre um ator e um caso de uso ela é representada por umrelacionamento. Um caso de uso pode se relacionar com vários atores. Por exemplo, o caso deuso matricula de alunos pode ter os atores aluno e sistema de matrículas. Em UML representa-se um relacionamento com uma linha reta. Se esta linha não apontar para nenhuma direçãoadimite-se que a comunicação parte do ator. Se você quiser indicar um relacionamento em quea iniciativa parte do processo basta usar uma seta na apontando do caso de uso para o ator. Onome dado aos casos de uso é muito importante para que a interpretação do diagrama seja fácile rápida. É aconselhável que se utilize um padrão para estes nomes. Como casos de uso sãoprocessos de preferência use verbos para seus nomes.

25


6.4 Diagrama de Seqüência

Um diagrama de seqüência mostra a seqüência dos processos (mais especificamente de men-sagens passadas entre os objetos) num sistema. Ele é usado para representar o comportamentodas operações, métodos (procedimentos ou funções) entre objetos de um cenário. Um cenário éuma forma de ocorrência de um caso de uso. Este diagrama é construído a partir do Diagramade Casos de Usos. Primeiro, se define qual o papel do sistema (Uses Case), depois, é definidocomo o software realizará seu papel(Seqüência de operações).

Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram emalgum comportamento ao longo do tempo. Ele registra o comportamento de um único caso deuso. Ele exibe os objetos e as mensagens passadas entre esses objetos no caso de uso. Umdesign pode ter uma grande quantidade de métodos em classes diferentes. Isso torna difícildeterminar a seqüência global do comportamento. Esse diagrama é simples e lógico, a fim detornar óbvios a seqüência e o fluxo de controle. Geralmente para cada caso de uso é feito umdiagrama de seqüência mostrando a operação normal do sistema para este caso de uso e depoissão feitos outros diagramas mostrando as seqüências alternativas e o tratamento de erros.

Em Diagramas de Seqüência objetos são representados através de linhas verticais tracejadas,com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo,de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com aoperação e os nomes dos parâmetros.

Mensagens pode ser síncronas, o tipo normal de mensagem de chamada onde o controle épassado para o objeto chamado até o método ter terminado sua execução, ou assíncronas ondeo controle é passado diretamente para o objeto chamado. Mensagens síncronas possuem uma

26


caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.A figura seguinte mostra um exemplo de um diagrama de seqüência:

6.5 Diagrama de Colaboração

Diagramas de Colaboração mostram as interações que ocorrem entre os objetos participantesnuma situação específica. Isto é mais ou menos a mesma informação mostrada pelos Diagra-mas de Seqüência, mas neste a ênfase é colocada em como as interações ocorrem no tempo,enquanto os Diagramas de Colaboração colocam os relacionamentos entre os objetos e sua to-pologia em destaque.

Em Diagramas de Colaboração as mensagens enviadas de um objeto para outro são repre-sentadas por setas, mostrando o nome da mensagem, parâmetros, e a seqüência da mensagem.Diagramas de Colaboração são especialmente indicados para mostrar um fluxo ou situação es-pecífica do programa e são um dos melhores tipos de diagrama para rapidamente demonstrar ouexplanar um processo na lógica do programa.

27


6.6 Diagrama de Gráfico de Estados

EstadosEstados são os blocos construídos dos Diagramas de Estado. Um Estado pertence a exata-

mente uma classe e representa um resumo dos valores dos atributos que uma classe pode tomar.Um Estado UML descreve o estado interno de um objeto para uma classe em particular

Observe que nem toda mudança em um dos atributos de um objeto pode ser representadapor um Estado mas somente aquelas mudanças que podem afetar significativamente o trabalhodo objeto

Existem dois tipos especiais de Estados: Inicial e Final. Eles são especiais porque nenhumevento pode fazer com que um Objeto retorne para seu estado Inicial, e da mesma maneira ne-nhum evento pode tirar um Objeto de seu estado Final uma vez que ele já o tenha alcançado.

Diagrama de EstadosDiagramas de Estado mostram os diferentes estados de um Objeto durante sua vida, e o

estímulo que faz com que o Objeto mude seu estado.Diagramas de Estado veem Objetos como máquinas de estado ou automatismos finitos que

podem ser um de um conjunto de estados finitos e que podem mudar seu estado através de umde um conjunto finito de estímulos. Por exemplo um tipo de Objeto ServidorRede pode estar emum dos seguintes estados durante sua vida:

• Pronto

• Ouvindo

• Trabalhando

28


• Parado

e os eventos que podem fazer com que o Objeto mude de estado são

• Objeto é criado

• Objeto recebe mensagem ouvir

• Um Cliente solicita uma conexão através da rede

• Um Cliente termina um pedido

• O pedido é executado e terminado

• Objeto recebe mensagem parar

• etc

6.7 Diagramas de atividades

AtividadeUma Atividade é um passo simples num processo. Uma Atividade é um estado no sistema

com atividade interna e, pelo menos, uma transição de saída. Atividades podem também ter maisde uma transição de saída se elas possuem condições diferentes.

29


Atividades podem formar hierarquias, isto significa que uma Atividade pode ser composta pordiversas Atividades em "detalhe", na qual as transições de entrada e saída devem corresponderàs transições de entrada e saída do diagrama de detalhe.

Diagrama de AtividadeO Diagrama de Atividade descreve a seqüência de atividades num sistema com a ajuda as Ati-

vidades. Diagramas de Atividade são uma forma especial de Diagramas de Estado, que somente(ou principalmente) contém Atividades.

Diagramas de Atividade são similares as Diagramas de Fluxo de procedimentos, com a dife-rença de que todas as Atividades são claramente anexas aos Objetos.

Diagramas de Atividade são sempre associados a um Classe, uma Operação ou um Caso deUso.

Diagramas de Atividade suportam Atividades seqüenciais bem como paralelas. A execuçãoparalela é representada pelos ícones Forquilha/Esperar, e para as Atividades executadas emparalelo, não é importante a ordem na qual elas se executam (elas podem ser executadas aomesmo tempo ou uma após a outra).

30

uml

Documents