CURSO BÁSICO DE UML (UNIFIED MODELING LANGUAGE)

Autor: João Carlos da Silva Jr 17/06/2002

Conteúdo do curso

1. Introdução 2. Uso da UML 3. Diagramas

a. Use Case b. Sequência c. Atividades d. Classes

4. Ferramenta MS-VISIO 5. Estudo de caso / Diagramas 6. Conclusões

1. Introdução

Pode-se dizer que a UML surgiu para resolver um grande problema no desenvolvimento de software, a falta de uma notação padronizada e eficaz que abranja qualquer tipo de aplicação. Cada simbologia existente possui seus próprios conceitos, gráficos e terminologias resultando em uma grande confusão.

A 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 orientado 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.

Vale a pena dizer que a UML é muito mais que a padronização de uma notação, é o desenvolvimento de novos conceitos. Por essa razão entender UML não é apenas aprender a ler uma simbologia, mas significa aprender a modelar orientado a objetos.

A idéia deste curso é capacitar as pessoas a conhecer a notação UML, assimilar alguns conceitos importantes na modelagem orientada a objetos, aprender a “ler”1 os diagramas e conhecer uma das inúmeras ferramentas de modelagem de sistemas, no nosso curso será o Microsoft Visio.

Não é intuito deste curso ensinar como modelar sistemas de informação e nem todos os diagramas e métodos da UML. Para esse tipo de aprendizado aconselho um estudo mais detalhado através de livros especializados, alguns estão citados na bibliografia.

1 Ler no sentido de saber identificar processos e regras de negócios. Ser capaz de identificar atributos e funções.

2. Uso da UML A UML é utilizada em diversos tipos de sistemas, ela abrange todas as fases desde a especificação de requisitos até a fase de testes.

Mas qual o objetivo da UML? O objetivo da UML é descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos.

Vamos trabalhar em função de Sistemas de Informação2. É claro que pode-se utilizar a UML para sistemas distribuidos, sistemas técnicos, sistemas real-time, sistemas de negócios entre outros, ou seja, a UML suporta a modelagem de qualquer tipo de sistema.

2 São sistemas os quais temos que 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.

3. Diagramas a. Use Case Por muitos anos as pessoas utilizavam interações para ajudá-las a

compreender o sistema, sempre de modo informal e nunca documentados.Até que Ivar Jacobson conseguisse tornar os casos de uso como elemento primário no desenvolvimento e no planejamento do projeto. Antes de explicar o que é um caso de uso, é necessário entender o conceito de cenário.

Cenário é uma sequência de passos que descreve uma interação entre um usuário e um sistema. Para melhor entedimento, vou descrever um cenário: Compra via Internet O cliente navega pelo site e adiciona itens desejados ao carrinho de compras. Quando o cliente deseja finalizar a compra, descreve login/senha, endereço de entrega, fornece as informações do cartão de crédito e confirma a compra. O sistema verifica a autorização do cartão de crédito, autoriza a compra e envia um email informando ao cliente o status da compra. Dizemos que esse cenário é uma alternativa que pode acontecer. Vale a pena dizer, que a autorização do cartão pode falhar, o usuário pode não conseguir logar-se no sistema. Desse modo temos cenário alternativos. Isso quer dizer que um caso de uso, é um conjunto de cenários ligados por um objetivo comum de um usuário. Normalmente quando modelamos sistemas, definimos um caso de uso principal e outros que serão os alternativos. No nosso exemplo, teriamos: Realizar compra, como sendo o caso de uso bem-sucedido; Falha na autorização e Falha na autentificação do usuário como os casos de uso alternativos. Uma prática comum entre os analistas é descrever um cenário principal como sendo uma sequencia de passos numerados e as alternativas como variações naquela sequencia, como ilustrado na Figura 1-1.

COMPRA VIA WEB 1. O Cliente navega pelo site e seleciona itens a serem comprados 2. O Cliente vai para o check out 3. O Cliente preenche usuário e senha 4. O Cliente preenche formulário de entrega 5. O Sistema apresenta as informações sobre o pedido (Valor, Impostos, Frete) 6. O Cliente preenche as informações do Cartão de Crédito 7. O Sistema autoriza a venda 8. O Sistema confirma a venda 9. O Sistema envia confirmação para o cliente via email Alternativa: FALHA NA AUTORIZAÇÃO No item 7, o sistema falha na autorização da compra por crédito Envia notificação para o cliente via email Alternativa: FALHA NA AUTENTIFICAÇÃO No item 3, o sistema recusa usuário e senha Permite ao cliente submeter as informações por mais 2 vezes Se ultrapassar limite bloquear conta

Figura 1-1: Exemplo de texto de Caso de Uso

Quando falamos de caso de uso, precisamos entender três conceitos que serão vistos a seguir. Ator: É um papel que um usuário desempenha em relação ao sistema. Um ator pode desempenhar vários casos de uso; um caso de uso pode ter vários atores. Os atores não precisam ser humanos, o ator pode ser um sistema externo que necessita de alguma informação do sistema atual. Associação entre Casos de Uso: Além das associações entre atores e casos de uso, você pode ilustrar vários tipos de associações entre casos de uso. Destacam-se três tipos de associações, que são: Inclusão (USES) – Ocorre quando há uma parte do comportamento que é semelhante em mais de um caso de uso. Ou seja, quando um caso de uso, “usa” o outro. Não pode ser usado se apenas um outro caso de uso o dispara. Nem justifica o uso para modelar sequência. Generalização – Quando tem um que é semelhante a outro, mas faz um pouco mais. Extensão (EXTENDS) – Quando você estiver descrevendo uma variação em comportamento normal. Ou seja, um caso de uso, “estende” o outro, quando o segundo acrescenta novos comportamentos ao primeiro já modelado.

Apresentei diversos conceitos e não respondi uma pergunta essencial. Quando devemos utilizar casos de uso?

Sempre. Definir casos de uso é uma tarefa básica na elaboração e planejamento de sistemas. Uma maneria interessante de identificar casos de uso é fazer uma modelagem conceitual com usuários.

Vale a pena dizer que casos de uso, representam uma visão externa do sistema. Não espere nenhuma correlação entre eles e classes do sistema.

NOTAÇÃO:

Diagrama Use Case: Um diagrama use case é composto:

Ator: é um papel que um usuário desempenha em relação ao sistema. O nome do ator deve ser um sujeito Linha de comunicação: Não é necessário identificar a comunicação entre atores e casos de uso, mas é uma boa prática Casos de uso: O nome do caso de uso deve ser um verbo que facilite a identificação da funcionalidade do mesmo. Veja o exemplo abaixo:

Gerente

Usuario

EmprestandoMaterial

CadastrandoMaterial

Cadastrar usuário

Pesquisando Livro

Emprestandomaterial

Sistema de Biblioteca - Para fins didáticos

<<uses>>Implica em

b. Sequência

O diagrama de sequência é uma ferramenta que deve ser utilizada sempre em função dos casos de uso. Um diagrama de sequência captura o comportamento de um único caso de uso, ou seja, mostra a interação entre os objetos ao longo do tempo, apresentando os objetos que participam da interação e a sequência das mensagens trocadas.

NOTAÇÃO: O diagrama é composto por: Objeto: É uma caixa na parte superior de uma linha tracejada verticalmente.

A linha vertical é chamada de linha da vida do objeto, e representa a vida do objeto durante a interação. Mensagem: É representada por uma flecha entre as linhas de vida de dois objetos. Cada mensagem deve ter um nome, é comum incluir os argumentos e algumas informações de controle.

Veja o exemplo abaixo:

c. Atividades

Utilizado para descrever a sequência de atividades, utilizando comportamento condicional e paralelo. È composto por:

Início: Representado por um círculo preenchido. Estado de Atividade ou Atividade: Representado por um retângulo com

bordas arredondadas. Atividade é um estado de estar fazendo algo. Desvio(Branch): Representado por um losango. Intercalação(Merge): Também representado por um losango, é utilizada

para marcar o final de um comportamento condicional iniciado por um desvio, ou seja, tem múltiplas entradas e uma única saída.

Separação(Fork): Representado por um traço horizontal, quando temos comportamento paralelo, ou seja, temos uma entrada e várias transições de saída que são executadas em paralelo.

Junção(Joins): Representado por um traço horizontal, utilizamos para completar a separação, ou seja, quando temos um processamento paralelo, precisamos sincronizar.

Veja o exemplo abaixo:

d. Classes

Sem sombra de dúvidas, o diagrama mais importante da documentação, onde podemos encontrar as informações sobre métodos, atributos, nome das funções e como serão integradas. Um diagrama de classes bem modelado é fundamental para auxiliar o desenvolvedor.

NOTAÇÃO: Classe: No modelo de classe trabalhamos com um único elemento um

retângulo dividido em 3 partes, a primeira divisão é utilizada para o nome da classe, a segunda divisão colocamos as informações de atributos e a última divisão é utilizada para identificar os métodos. É importante apresentar o conceito de instância, isto é, cada objeto é uma instância de sua classe. Cada instância tem seus próprios valores de atributos, compartilha os nomes dos atributos e os métodos com os outros objetos da mesma classe.

É importante entender a diferença entre classe e objeto(instância), veja abaixo:

Outro conceito importante que temos que ver é o de estereótipos: Estereótipo (s.m) – (2) Lugar comum, clichê, chavão. Veremos agora, os estereótipos de uma classe, são eles: Entidade ou Negócio (Entity): São classes de objetos que refletem

entidades do mundo real, ou seja, pertence ao domínio do problema. Fronteira ou Interface (Boundary): São classes de objetos que permitem a

comunicação entre o mundo externo e o sistema. Controle (Control): São classes que modelam a sequência de controle

específica de um caso de uso do sistema, ou seja, controlam a execução dos eventos necessários para um caso de uso.

Com isso, temos que aprender “Como identificar as classes?” As classes de negócio são identificadas a partir das definições dos casos

de uso obtidos na fase de Especificação de requisitos. Vale a pena dizer, que é comum encontrar as mesmas classes em diferentes funções no negócio.

No decorrer da modelagem, você encontrará a necessidade de associar as classes, por exemplo:

Não podemos deixar da falar do conceito de HERANÇA. Usamos o

conceito de herança quando queremos representar uma classe “filha” que herda todas as características da classe “pai”, agregando alguns atributos que são particulares. A Classificação não é trivial. Deve-se tomar muito cuidado.

Outro tipo de associação é a agregação. A agregação faz-se necessário quando duas classes associadas tem um sentido próprio e separadas continuam existindo como unidade autônoma, podendo até se associar com outras instâncias. A agregação é representada por um losango sem preenchimento. Imagine as seguintes classes (Telefone, Aparelho e Assinante), podemos ilustrar a agregação entre a classe aparelho e telefone. Duas classes indepententes, mas que juntas tem um sentido próprio.

É sabido que toda regra tem exceção e não seria diferente na UML. Existe um caso particular de agregação, quando duas classes só possuem sentido quando estão associadas. Chamamos esse tipo de associação com forte depedência de composição.

Isto implica em se uma instância da classe deixar de existir, todas as outras associadas por composição, deixarão de existir também. O símbolo que representa a composição é um losango preenchido.

Veja o exemplo de composição:

Em resumo, o diagrama de classes é composto por objetos (instâncias), que podem ser de negócios, interfaces ou de controle, e os mesmos são associados por herança, agregação ou composição.

4. A ferramenta MS-VISIO O Microsoft VISIO é uma ferramenta para diagramação de sistemas de tecnologia da informação. Essa ferramenta possui diversos modelos e suporta diversas metodologias de desenvolvimento de software. A versão que utilizamos é o VISIO2000 Professional. Não é necessário explicar o funcionamento da ferramenta, toda ferramenta de diagramação de sistemas, são intuitivas desde que o usuário conheça os conceitos da metodologia UML. Antes de iniciar o trabalho, abra um novo documento, escolha o software UML. O MS VISIO irá preparar o ambiente para documentar UML. Os detalhes da ferramenta, uso e dicas serão explicados durante o curso.

5. Estudo de caso / Diagramas A idéia deste treinamento é introduzir os principais conceitos da UML. Espero que tenha conseguido atingir o objetivo. Uma ferramenta importante para medir o aprendizado são os estudo de caso. Irei propor a seguir um estudo de caso e diagramar o mesmo. Ao final deste tópico peço que vocês façam o mesmo. Tente diagramar o estudo de caso. Certamente teremos diversas propostas para o sistema. O estudo de caso:

A Number One Idiomas é uma escola de inglês, localizada em São Paulo/SP, atua no mercado desde 1985 com método próprio. Hoje a escola está com 900 alunos na unidade SP. Com o sucesso do curso de inglês, a escola começou a lecionar Espanhol e Alemão. Hoje, 2002, a Number One está com 1600 alunos, com possibilidade de crescimento em função dos novos cursos. A escola não utiliza sistema para controlar os alunos, apenas planilhas e documentos, com o crescimento este tipo de controle está ficando difícil e ineficaz.

A necessidade: A Number One deseja um sistema de informação para controlar o cadastro

de alunos, manter controle de pagamentos, histórico de notas e faltas, relatórios de aproveitamento dos alunos, relatórios de inadimplentes e de fácil utilização.

Problemas: Atualmente os dados dos alunos estão armazenados em fichas, o controle

de pagamento é feito por uma planilha do excel, existe outra planilha onde estão registradas as notas/faltas. Existe apenas um funcionário responsável pelas informações e o mesmo responde por outras funções dentro da escola.

A escola tem 4 equipamentos com a seguinte configuração: Processador HD Memória RAM Sistema Operacional

486 4.2 GB 32MB Windows 95 486 4.2 GB 32MB Windows95

Pentium II 10 GB 64 MB Windows 98 Pentium III 40 GB 64MB Windows 98

A escola Number One está iniciando uma fase de franquias e está em processo de abertura de duas unidades no interior de São Paulo. Devido ao fato o cliente quer um sistema que permita o uso em rede.

O que espero? Proposta de solução utilizando metodologia UML - Diagrama use case - Descrição dos use case - Diagrama de sequência de um caso de uso - Diagrama de atividades - Diagrama de classes Diagramas devem ser feitos com a ferramenta MS VISIO. Tempo gasto para modelar cada diagrama. Conclusões.

7. Conclusões

Preparar este treinamento foi um desafio muito grande para mim. Fazer os diagramas, entender a metodologia UML para mim tinha um significado. Mas como transmitir o conhecimento adquirido com livros, universidade e vida prática. É difícil sentar na frente de um editor de texto e começar a escrever, o que é o seu trabalho? Como dever ser feito? Foi uma experiência que ajudou-me a aprimorar os conceitos e o mais importante a possibilidade de agregar novos valores.

Este curso básico foi elaborado em função das experiências que adquiri em empresas anteriores e principalmente em função do projeto Banco1.net

O material utilizado como referência foi: Apresentação “Engenharia de Software”, professor Ivan Granja, mestre da

PUC – Campinas Livro UML Essencial, Kendall Scott, editora Bookman Minha intenção com este treinamento foi capacitar desenvolvedores a

entender o que é UML, como ler documentações em UML, e introduzir os pré-requisitos necessários para um aprendizado mais detalhado sobre a UML. Espero que eu tenha conseguido de forma clara, expor os conceitos e técnicas da modelagem UML. Gostaria de deixar claro que este treinamento engloba apenas o básico da modelagem, existem outros diagramas e outras técnicas que podem ser assimilados através de leitura especializada.

Estou a disposição para esclarecer dúvidas e maiores informações através do email: joao@atenacriacao.com.br