CURSO BSICO DE UML (UNIFIED MODELING LANGUAGE)

Autor: Joo Carlos da Silva Jr

17/06/2002

Contedo do curso

1. Introduo 2. Uso da UML 3. Diagramas a. Use Case b. Sequncia c. Atividades d. Classes 4. Ferramenta MS-VISIO 5. Estudo de caso / Diagramas 6. Concluses

1. Introduo Pode-se dizer que a UML surgiu para resolver um grande problema no desenvolvimento de software, a falta de uma notao padronizada e eficaz que abranja qualquer tipo de aplicao. Cada simbologia existente possui seus prprios conceitos, grficos e terminologias resultando em uma grande confuso. A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos como "os trs amigos". Eles possuem um extenso conhecimento na rea de modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem orientado a objetos foram eles que desenvolveram e a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. Vale a pena dizer que a UML muito mais que a padronizao de uma notao, o desenvolvimento de novos conceitos. Por essa razo entender UML no apenas aprender a ler uma simbologia, mas significa aprender a modelar orientado a objetos. A idia deste curso capacitar as pessoas a conhecer a notao UML, assimilar alguns conceitos importantes na modelagem orientada a objetos, aprender a 1 os diagramas e conhecer uma das inmeras ferramentas de ler modelagem de sistemas, no nosso curso ser o Microsoft Visio. No intuito deste curso ensinar como modelar sistemas de informao e nem todos os diagramas e mtodos da UML. Para esse tipo de aprendizado aconselho um estudo mais detalhado atravs de livros especializados, alguns esto citados na bibliografia.

Ler no sentido de saber identificar processos e regras de negcios. Ser capaz de identificar atributos e funes.

2. Uso da UML A UML utilizada em diversos tipos de sistemas, ela abrange todas as fases desde a especificao 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 funo de Sistemas de Informao2. claro que pode-se utilizar a UML para sistemas distribuidos, sistemas tcnicos, sistemas real-time, sistemas de negcios entre outros, ou seja, a UML suporta a modelagem de qualquer tipo de sistema.

So sistemas os quais temos que armazenar, pesquisar, editar e mostrar informaes para os usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so guardados em bancos de dados relacionais ou orientados a objetos.

3. Diagramas a. Use Case Por muitos anos as pessoas utilizavam interaes 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 primrio no desenvolvimento e no planejamento do projeto. Antes de explicar o que um caso de uso, necessrio entender o conceito de cenrio. Cenrio uma sequncia de passos que descreve uma interao entre um usurio e um sistema. Para melhor entedimento, vou descrever um cenrio: 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, endereo de entrega, fornece as informaes do carto de crdito e confirma a compra. O sistema verifica a autorizao do carto de crdito, autoriza a compra e envia um email informando ao cliente o status da compra. Dizemos que esse cenrio uma alternativa que pode acontecer. Vale a pena dizer, que a autorizao do carto pode falhar, o usurio pode no conseguir logar-se no sistema. Desse modo temos cenrio alternativos. Isso quer dizer que um caso de uso, um conjunto de cenrios ligados por um objetivo comum de um usurio. Normalmente quando modelamos sistemas, definimos um caso de uso principal e outros que sero os alternativos. No nosso exemplo, teriamos: Realizar compra, como sendo o caso de uso bem-sucedido; Falha na autorizao e Falha na autentificao do usurio como os casos de uso alternativos. Uma prtica comum entre os analistas descrever um cenrio principal como sendo uma sequencia de passos numerados e as alternativas como variaes 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 usurio e senha 4. O Cliente preenche formulrio de entrega 5. O Sistema apresenta as informaes sobre o pedido (Valor, Impostos, Frete) 6. O Cliente preenche as informaes do Carto de Crdito 7. O Sistema autoriza a venda 8. O Sistema confirma a venda 9. O Sistema envia confirmao para o cliente via email Alternativa: FALHA NA AUTORIZAO No item 7, o sistema falha na autorizao da compra por crdito Envia notificao para o cliente via email Alternativa: FALHA NA AUTENTIFICAO No item 3, o sistema recusa usurio e senha Permite ao cliente submeter as informaes 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 trs conceitos que sero vistos a seguir. Ator: um papel que um usurio desempenha em relao ao sistema. Um ator pode desempenhar vrios casos de uso; um caso de uso pode ter vrios atores. Os atores no precisam ser humanos, o ator pode ser um sistema externo que necessita de alguma informao do sistema atual. Associao entre Casos de Uso: Alm das associaes entre atores e casos de uso, voc pode ilustrar vrios tipos de associaes entre casos de uso. Destacam-se trs tipos de associaes, que so: Incluso (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. No pode ser usado se apenas um outro caso de uso o dispara. Nem justifica o uso para modelar sequncia. Generalizao Quando tem um que semelhante a outro, mas faz um pouco mais. Extenso (EXTENDS) Quando voc estiver descrevendo uma variao em comportamento normal. Ou seja, um caso de uso, estendeo outro, quando o segundo acrescenta novos comportamentos ao primeiro j modelado. Apresentei diversos conceitos e no respondi uma pergunta essencial. Quando devemos utilizar casos de uso? Sempre. Definir casos de uso uma tarefa bsica na elaborao e planejamento de sistemas. Uma maneria interessante de identificar casos de uso fazer uma modelagem conceitual com usurios. Vale a pena dizer que casos de uso, representam uma viso externa do sistema. No espere nenhuma correlao entre eles e classes do sistema.
NOTAO:

Diagrama Use Case: Um diagrama use case composto: Ator: um papel que um usurio desempenha em relao ao sistema. O nome do ator deve ser um sujeito Linha de comunicao: No necessrio identificar a comunicao entre atores e casos de uso, mas uma boa prtica Casos de uso: O nome do caso de uso deve ser um verbo que facilite a identificao da funcionalidade do mesmo. Veja o exemplo abaixo:

Sistema de Biblioteca - Para fins didticos

Usuario

Pesquisando Livro

Emprestando material

<<uses>> Implica em

Cadastrando Material

Gerente

Cadastrar usurio

Emprestando Material

b. Sequncia O diagrama de sequncia uma ferramenta que deve ser utilizada sempre em funo dos casos de uso. Um diagrama de sequncia captura o comportamento de um nico caso de uso, ou seja, mostra a interao entre os objetos ao longo do tempo, apresentando os objetos que participam da interao e a sequncia das mensagens trocadas.
NOTAO:

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 interao. 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 informaes de controle. Veja o exemplo abaixo:

c. Atividades Utilizado para descrever a sequncia de atividades, utilizando comportamento condicional e paralelo. composto por: Incio: Representado por um crculo preenchido. Estado de Atividade ou Atividade: Representado por um retngulo com bordas arredondadas. Atividade um estado de estar fazendo algo. Desvio(Branch): Representado por um losango. Intercalao(Merge): Tambm representado por um losango, utilizada para marcar o final de um comportamento condicional iniciado por um desvio, ou seja, tem mltiplas entradas e uma nica sada. Separao(Fork): Representado por um trao horizontal, quando temos comportamento paralelo, ou seja, temos uma entrada e vrias transies de sada que so executadas em paralelo. Juno(Joins): Representado por um trao horizontal, utilizamos para completar a separao, ou seja, quando temos um processamento paralelo, precisamos sincronizar. Veja o exemplo abaixo:

d. Classes Sem sombra de dvidas, o diagrama mais importante da documentao, onde podemos encontrar as informaes sobre mtodos, atributos, nome das funes e como sero integradas. Um diagrama de classes bem modelado fundamental para auxiliar o desenvolvedor.
NOTAO:

Classe: No modelo de classe trabalhamos com um nico elemento um retngulo dividido em 3 partes, a primeira diviso utilizada para o nome da classe, a segunda diviso colocamos as informaes de atributos e a ltima diviso utilizada para identificar os mtodos. importante apresentar o conceito de instncia, isto , cada objeto uma instncia de sua classe. Cada instncia tem seus prprios valores de atributos, compartilha os nomes dos atributos e os mtodos com os outros objetos da mesma classe. importante entender a diferena entre classe e objeto(instncia), veja abaixo:

Outro conceito importante que temos que ver o de esteretipos: Esteretipo (s.m) (2) Lugar comum, clich, chavo. Veremos agora, os esteretipos de uma classe, so eles: Entidade ou Negcio (Entity): So classes de objetos que refletem entidades do mundo real, ou seja, pertence ao domnio do problema. Fronteira ou Interface (Boundary): So classes de objetos que permitem a comunicao entre o mundo externo e o sistema. Controle (Control): So classes que modelam a sequncia de controle especfica de um caso de uso do sistema, ou seja, controlam a execuo dos eventos necessrios para um caso de uso. Com isso, temos que aprender Como identificar as classes? As classes de negcio so identificadas a partir das definies dos casos de uso obtidos na fase de Especificao de requisitos. Vale a pena dizer, que comum encontrar as mesmas classes em diferentes funes no negcio.

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

No podemos deixar da falar do conceito de HERANA. Usamos o conceito de herana quando queremos representar uma classe filha que herda todas as caractersticas da classe , agregando alguns atributos que pai so particulares. A Classificao no trivial. Deve-se tomar muito cuidado. Outro tipo de associao a agregao. A agregao faz-se necessrio quando duas classes associadas tem um sentido prprio e separadas continuam existindo como unidade autnoma, podendo at se associar com outras instncias. A agregao representada por um losango sem preenchimento. Imagine as seguintes classes (Telefone, Aparelho e Assinante), podemos ilustrar a agregao entre a classe aparelho e telefone. Duas classes indepententes, mas que juntas tem um sentido prprio. sabido que toda regra tem exceo e no seria diferente na UML. Existe um caso particular de agregao, quando duas classes s possuem sentido quando esto associadas. Chamamos esse tipo de associao com forte depedncia de composio. Isto implica em se uma instncia da classe deixar de existir, todas as outras associadas por composio, deixaro de existir tambm. O smbolo que representa a composio um losango preenchido. Veja o exemplo de composio:

Em resumo, o diagrama de classes composto por objetos (instncias), que podem ser de negcios, interfaces ou de controle, e os mesmos so associados por herana, agregao ou composio.

4. A ferramenta MS-VISIO O Microsoft VISIO uma ferramenta para diagramao de sistemas de tecnologia da informao. Essa ferramenta possui diversos modelos e suporta diversas metodologias de desenvolvimento de software. A verso que utilizamos o VISIO2000 Professional. No necessrio explicar o funcionamento da ferramenta, toda ferramenta de diagramao de sistemas, so intuitivas desde que o usurio conhea 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 sero explicados durante o curso.

5. Estudo de caso / Diagramas A idia deste treinamento introduzir os principais conceitos da UML. Espero que tenha conseguido atingir o objetivo. Uma ferramenta importante para medir o aprendizado so os estudo de caso. Irei propor a seguir um estudo de caso e diagramar o mesmo. Ao final deste tpico peo que vocs faam 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 ingls, localizada em So Paulo/SP, atua no mercado desde 1985 com mtodo prprio. Hoje a escola est com 900 alunos na unidade SP. Com o sucesso do curso de ingls, a escola comeou a lecionar Espanhol e Alemo. Hoje, 2002, a Number One est com 1600 alunos, com possibilidade de crescimento em funo dos novos cursos. A escola no utiliza sistema para controlar os alunos, apenas planilhas e documentos, com o crescimento este tipo de controle est ficando difcil e ineficaz. A necessidade: A Number One deseja um sistema de informao para controlar o cadastro de alunos, manter controle de pagamentos, histrico de notas e faltas, relatrios de aproveitamento dos alunos, relatrios de inadimplentes e de fcil utilizao. Problemas: Atualmente os dados dos alunos esto armazenados em fichas, o controle de pagamento feito por uma planilha do excel, existe outra planilha onde esto registradas as notas/faltas. Existe apenas um funcionrio responsvel pelas informaes e o mesmo responde por outras funes dentro da escola. A escola tem 4 equipamentos com a seguinte configurao:
Processador 486 486 Pentium II Pentium III HD 4.2 GB 4.2 GB 10 GB 40 GB Memria RAM 32MB 32MB 64 MB 64MB Sistema Operacional Windows 95 Windows95 Windows 98 Windows 98

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

O que espero? Proposta de soluo utilizando metodologia UML - Diagrama use case - Descrio dos use case - Diagrama de sequncia 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. Concluses.

7. Concluses 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 prtica. difcil sentar na frente de um editor de texto e comear a escrever, o que o seu trabalho? Como dever ser feito? Foi uma experincia que ajudoume a aprimorar os conceitos e o mais importante a possibilidade de agregar novos valores. Este curso bsico foi elaborado em funo das experincias que adquiri em empresas anteriores e principalmente em funo do projeto Banco1.net O material utilizado como referncia foi: Apresentao Engenharia de Software professor Ivan Granja, mestre da , PUC Campinas Livro UML Essencial, Kendall Scott, editora Bookman Minha inteno com este treinamento foi capacitar desenvolvedores a entender o que UML, como ler documentaes em UML, e introduzir os prrequisitos necessrios para um aprendizado mais detalhado sobre a UML. Espero que eu tenha conseguido de forma clara, expor os conceitos e tcnicas da modelagem UML. Gostaria de deixar claro que este treinamento engloba apenas o bsico da modelagem, existem outros diagramas e outras tcnicas que podem ser assimilados atravs de leitura especializada. Estou a disposio para esclarecer dvidas e maiores informaes atravs do email: joao@atenacriacao.com.br