Viso geral

Apresentao da disciplina:

Na construo de projetos de desenvolvimento

de software, existem as tcnicas de orientao a
objetos e seus diagramas. Para sua modelagem,
pode-se contar com padres e ferramentas.
Portanto, a abordagem desse curso ser em
torno do padro UML (Unified Modeling
Language), e para a elaborao de seus
diagramas ser utilizada a ferramenta case Jude.

Objetivo da Disciplina

Apresentar os conceitos da modelagem orientada

a objetos, utilizando o padro UML (Unified
Modeling Language).

Contedo Programtico:

Tema: Conceitos Fundamentais de

Orientao a Objetos e Modelagem - 25/11
a 15/12/2010.

Profa. Simone Sawasaki Tanaka

Unidade I

Introduo a UML;

Diagrama de Caso de Uso.

Unidade II

Especificao de Caso de Uso.

No primeiro tema, ser abordada a Introduo ao

processo de desenvolvimento, aos mtodos
orientados a objeto e a UML. Para a prtica de
atividades dos Diagramas de Caso de Uso, ser
 Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 1

Curso de Extenso - Uml(unified Modeling Language) na Prtica 1

Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 2

Tema: Conceitos Fundamentais de Orientao a Objetos e Modelagem

Ol, caros alunos!

Somos as professoras Polyanna Gomes e Simone Sawasaki Tanaka

Vamos trabalhar juntos no curso de extenso UML na prtica. Neste

curso, vamos estudar sobre os diagramas da UML e coloc-los em
prtica utilizando para isso a ferramenta Jude.

Vamos l!

WEB-AULA 1
Jude
Para iniciar a nossa aula, vamos aprender um pouco sobre a
ferramenta Jude.

Este tutorial visa apresentar as funcionalidades bsicas do Jude, uma

ferramenta case muito utilizada, que auxilia na modelagem de
projetos, provendo funcionalidades como criao de todos os
diagramas da UML 1.4 e 2.0, assim como Engenharia Reversa, entre
outras.

Voc pode procurar outras ferramentas livres, como o ArgoUML (veja

a definio no wikipedia) e at mesmo fazer download do ArgoUML
clicando no link http://www.baixaki.com.br/download/argo-uml-for-
windows.htm.

Definio

Se voc for pesquisar sobre JUDE no Wikipdia, encontrar uma

definio de um filme... Nada a ver com que estamos estudando.

A frase retirada de jude products, 2009: A experincia nos diz que

usurios desejam uma ferramenta amigvel e leve, construda no
conceito de utilizvel a partir do momento em que instalada. Ns
criamos essa uma ferramenta assim para tornar sua experincia de
modelagem rpida e fcil.

Afinal, como classificar ou definir Jude? Bom,JUDE (Java and UML

Developers' Environment) uma ferramenta case utilizada para a
modelagem de dados atravs da UML. Com ela, possvel realizar a
edio e impresso de diagramas da UML 1.4 e 2.0, gerando tambm
classes Java e fazendo engenharia reversa das classes para UML,
entre outras funcionalidades. Ela foi desenvolvida utilizando a
tecnologia Java, com o objetivo de ser uma ferramenta leve, rpida,
objetiva e intuitiva.

Se voc quiser explorar ainda mais essa ferramenta, acesse o

link: jude-web.

Fazendo download e instalando o Jude (Astah)

Vamos dar continuidade aos nossos estudos. J aprendemos um

pouco sobre a ferramenta e agora vamos verificar como se faz o
download.

Downloads

Para efetuar o download da ferramenta Jude, voc pode utilizar o link

abaixo.

Segue abaixo o link para download das verses mais atuais no site
Jude:

JUDE Professional 5.4 JUDE Community 5.4

https://members.change-
vision.com/members/files/astah_community

Instalao

J fizeram o download? Agora vamos iniciar a instalao da

ferramenta. Vamos trabalhar?

Existem duas formas de se instalar a IDE Jude, que so relativas

extenso do arquivo selecionado para download do site.

A primeira, caso tenha sido selecionado o arquivo .zip, basta

descompactar todo o contedo do arquivo em um diretrio e clicar no
executvel Jude (arquivo com extenso .bat). Segue abaixo:
 Figura 1 Imagem com as verses disponveis para download.

Figura 2 Pgina para download do JUDE

A segunda forma de instalao atravs do arquivo executvel que o

site fornece via download. Aps baixar o arquivo (Primeira opo da
figura 1), siga os passos abaixo (para instalao em Windows XP):

2. Selecionar English e clique em

1. Selecione Executar.
next;
 Figura 3 - Confirmao de desbloqueio do Firewall Figura 4 -
Seleo de Idiomas

Curso de Extenso - Uml(unified Modeling Language) na Prtica 2

Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 3

3. Selecione I accept the agreement e logo aps, clique em next.

4. Caso no haja diretrio, digite no campo o seguinte caminho:

C:\Arquivos de Programas\JUDE Community. Ento, clique em next.

Figura 5 - Contrato de licena do Jude Figura 6 - Seleo

do diretrio de instalao.

5. Clique em next
6. Selecione a opo For all
 users.

Figura 7 - Diretrio do Jude no menu iniciar Figura 8 -

Tarefas adicionais de instalao.

7. Clique em Install. 8. Clique em Finish

Figura 9 - Resumo da instalao Figura 10 -

Finalizao da Instalao

Seguidos esses passos, o Jude estar instalado no seu computador.

Aps a instalao adicionado um atalho para o Jude na rea de
trabalho, que abre um arquivo com extenso bat, responsvel por
abrir o jar (executvel de programas criados em Java) do JUDE.
 Conhecendo a IDE

J fizemos o download e instalamos a ferramenta. Chegou a hora de

conhecer a ferramenta.

Vamos fazer uma breve apresentao da IDE do Jude.

Esto preparados! Vamos l.

Figura 11 IDE Jude

Funcionalidades: Essa a rea do programa que prov acesso s

funcionalidades deste, nesta rea est contida a barra de menus: que
apresenta ao usurio os recursos da ferramenta e a barra de itens,
que serve como atalho para as funcionalidades mais usadas.

Arquitetura: Tambm chamada Visualizao da estrutura de

diretrios ou Structure tree view, apresenta como os arquivos esto
organizados no projeto, mostrando o nvel hierrquico de pastas e
diretrios.

Propriedades: utilizada para exibir e editar as propriedades dos

elementos do projeto.
Editor: O Editor Grfico utilizado para editar diagramas e modelos,
possibilitando que sejam abertos vrios diagramas ou documentos
simultaneamente.

Curso de Extenso - Uml(unified Modeling Language) na Prtica 3

Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 4

Legal! J estudamos um pouco sobre a ferramenta. Falta

colocar a mo na massa e comear
a utilizar a ferramenta.

Iniciando nosso Projeto

Existem trs formas de se criar um projeto no Jude, uma utilizando

a barra de menus, outra utilizando o atalho que se localiza na barra
de atalhos, e por ltimo, utilizando a combinao das telas CTRL + N.

Figura 12 - Criando um projeto no JUDE. Figura 13 -

Criando um projeto no JUDE.

Ao criar um projeto, precisamos salv-lo em algum diretrio, para

isso, siga os passos abaixo:

1. Clique no menu File, e selecione a opo Save (esta

funcionalidade tambm possui as trs formas de acesso,
usando a combinao de teclas, menu e atalho na barra de
atalhos).
 2. Ser apresentada uma tela onde deve ser informado o local
onde o projeto ser salvo e o nome do projeto. Crie uma pasta
chamada Project na sua rea de Trabalho (Desktop), e nomeie
o projeto para locadora.

Figura 14 Salvando um projeto no JUDE.

Criando a arquitetura do projeto

Antes de criar a arquitetura de nosso projeto, devemos aprender

alguns conceitos importantes, referentes ao Jude e o tipo de
Modelagem utilizado por ele, assim como, alguns conceitos da UML
que sero muito utilizados.

Package:

Um package, ou diretrio, uma pasta onde so armazenados

determinados tipos de informaes existentes no Jude, tais
informaes podem ser classes Java, diagramas, casos de uso,
atores, interfaces, entre outros.

Use cases:

Os casos de uso, representados por uma elipse no Jude, so um

recurso da UML utilizado para expressar uma ao, comportamento
ou condio que um software deve atender.

Ator:

Um ator representa um papel que um ser humano, um dispositivo de

hardware ou at outro sistema desempenha com o sistema.

Classe:

uma entidade capaz de possuir caractersticas e comportamentos

(atributos e mtodos respectivamente), assim como um conjunto de
objetos.

Diagrama de caso de uso:

Um diagrama de caso de uso descreve os cenrios ou, a relao entre

os atores e os casos de uso de um determinado sistema.

Diagrama de classes:

Os diagramas de classe descrevem a estrutura de um sistema,

apresentando a hierarquia de classes e a cardinalidade entre elas.

Para criar nosso primeiro package, clique com o boto direito do

mouse sobre a pasta locadora, e selecione a opo Create Model, e
em seguida, clique em Add Package. Ser criada uma pasta, ento
necessrio determinar um nome para ela, ele se chamar model, e
o primeiro passo das etapas de arquitetura abaixo.

Figura 15 - Criao de um package Figura 16 -

Renomeando o package

Para que nosso projeto possa ser bem estruturado, segue abaixo a
arquitetura de pastas:

1. Criar um package chamado model que ir representar o modelo

de nossa aplicao, ou, a interpretao do domnio do nosso
 problema.

2. Criar um package chamado Logical View dentro do package

model. O Use Case View ser utilizado para armazenar
componentes e diagramas referentes nossa arquitetura de
projetos e de sistema, apresentando as classes e a
cardinalidade entre elas. Posteriormente armazenaremos
tambm as realizaes de caso de uso, apresentando a
rastreabilidade entre casos de uso de projeto e casos de uso de
sistema.

3. No package Logical View criar o package Classes, que ser

utilizado para armazenar as classes do projeto.

4. Criar um package chamado Use case View no package model,

onde sero armazenados os atores e casos de uso do sistema,
assim como o diagrama de casos de uso que apresenta os
cenrios do software.

5. Dentro de Use Case View criar dois packages: Actors (package

que ir conter os atores do nosso sistema) e Use Cases (pasta
em que estaro contidos os casos de uso).

Figura 17 Arquitetura do projeto

Aps definirmos nossa arquitetura, podemos dar incio a criao do

diagrama de casos de uso da Locadora, pois, o mesmo possui todas
as informaes necessrias para que sejam criados nossos prximos
diagramas.

No decorrer da nossa aula, ser abordada a utilizao da ferramenta

focada cada diagrama.

Curso de Extenso - Uml(unified Modeling Language) na Prtica 4

Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 5

WEB-AULA 2
Diagrama de Casos de Uso no Jude
Criando nosso primeiro diagrama, o diagrama de caso de uso, um
dos mais simples de se fazer, porm, um dos mais difceis de abstrair,
e com um grande peso no projeto, pois, se algo der errado aqui, o
erro se replicar em cascata com o decorrer do projeto. Para criar o
diagrama de caso de uso, clique com o boto direito sobre o package
Use Case View e selecione a opo Create Diagram, e em seguida
clique em Add Use Case Diagram. O Mesmo processo se aplica ao
diagrama de classe, porm, a opo selecionada deve ser
AddControlar Class Diagram.

J fizeram isso! Cuidado para no se perder... Vamos continuar.

 Figura 18 Criao dos diagramas.

Figura 19 Criao do diagrama de Caso de Uso

Criado o diagrama de caso de uso, precisamos criar os componentes

que iro representar os cenrios do sistema, so eles os atores e os
casos de uso. Para se criar um ator, clique na pasta Actors com o
boto direito do mouse, selecione a opo Create Model, e em
seguida, selecione Actor. Para criar um caso de uso siga os mesmos
passos, porm, no menu Create model, necessrio que a opo use
case seja selecionada.
 Figura 20 Criando um ator.

Figura 21 Criando um caso de uso.

Associando os itens criados ao diagrama de caso de uso: Aps criar

os itens e o diagrama de caso de uso, vamos associar os dois, basta
arrastar primeiramente os casos de uso para o centro do diagrama e
logo aps arrastar tambm os Atores.

Curso de Extenso - Uml(unified Modeling Language) na Prtica 5

 Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 6

Criando as classes

O processo de criao de classes to simples quanto o de Caso de

uso. Basta selecionar a pasta classes e clicar com o boto direito do
mouse sobre ela, selecione no menu que ir aparecer a opo Create
model, e logo em seguida Add Class.

Figura 22- Adicionando classes ao projeto

Criando o diagrama de classes: Para que seja criado o diagrama de

classe, necessrio seguir os seguintes passos: clique com o boto
direito do mouse sobre a pasta Logical View e selecione a opo
Create Diagram, aps isso, escolha Class diagram.
 Figura 23- Criao do diagrama de classes

Diagrama de Atividades

Componentes

Figura 24: Barra de atalhos para o diagrama de atividades

1. InitialNode: Indica o incio do diagrama.

2. ActivityFinal: indica um dos finais do diagrama de atividades.

3. Partition (Vertical): Subdivises do diagrama utilizadas para

organizao das atividades executadas pelos atores
(responsabilidades), tambm chamada de swimlanes.

4. Action: Aes ou atividades executadas pelos atores.

5. ControlFlow / ObjectFlow: indica o fluxo de controle das
atividades, apresentando a ordem lgica dos acontecimentos no
diagrama.

6. Decision Node & Merge Node: componente do diagrama de

atividades utilizado para representar estruturas condicionais
(IF), ao utilizar esse componente, deve ser informado deciso
a ser tomada, e em seguida, o diagrama sofre uma ramificao,
onde, um dos lados apresenta o resultado caso a condio seja
satisfeita, e o outro caso no.

Figura 25: Decision Flow e elementos utilizados no diagrama de

atividades.

Diagrama de Sequncia

Componentes

Figura 26: Barra de atalhos para o diagrama de seqncia

1. LifeLine: Linha de vida, esse componente utilizado quando

existe a necessidade de adio de objetos ao diagrama de
atividades, ele cria uma nova entidade no diagrama, capaz de
se comunicar com os outros objetos deste.
 2. Message: tambm chamada de mensagem sncrona, esse tipo
de mensagem utilizada quando existe necessidade de
sincronismo entre as mensagens enviadas pelos objetos, ou
seja, caso o objeto um tenha enviado uma mensagem para o
objeto dois, o objeto um no poder enviar outra mensagem
at que o objeto dois envie uma resposta em relao primeira
mensagem.

3. Asynchronous Message: Mensagens assncronas so

mensagens enviadas pelos objetos, onde no existe a
necessidade de um retorno aps o envio da mensagem.

4. Note: Utilizado para adicionar blocos de textos ou informaes

referentes ao diagrama, ou a partes dele.

5. Reply Message: Componente do Jude utilizado para indicar a

resposta, feedback ou retorno de uma mensagem.

Observaes Importantes:

Por apresentar o fluxo de envio de mensagens entre os

objetos, esse diagrama composto basicamente por um ator e
por classes, que representam tais objetos.

Diagrama de Estados

Componentes

Figura 27: Barra de atalhos para o diagrama de estados.

1. Initial PseudoState: indica o incio do diagrama de estados de

uma determinada classe ou iterao.

2. State: caracterstica de uma classe ou iterao, durante seu

ciclo de vida, de acordo com as mensagens que este recebe ou
envia.
 3. FinalState: indica o final do diagrama.

4. Transition: evento que ocorre gerando a mudana de estados

no diagrama.

Observaes importantes sobre o diagrama de estados:

Assim como o digrama de atividades, o diagrama de estados

deve possuir somente um incio, sendo que, para que haja mais
de um incio nesse diagrama, necessrio que haja subestados,
em que dentro de cada subestado aparea um novo diagrama,
com incio e fim bem definidos.

Agora que j estudamos um pouco sobre a ferramenta, vamos

iniciar o nosso estudo sobre a UML
(Unified Modeling Language)

Curso de Extenso - Uml(unified Modeling Language) na Prtica 6

Wa - Uml na Prtica - Unidade 1 - Conceitos Fundamentais de Orientao a Objetos e Modelagem 7

Introduo UML

A UML uma linguagem de modelagem utilizada para criar um

vocabulrio comum entre os envolvidos em um determinado projeto
de software, ela propicia uma viso mais ampla sobre o escopo do
sistema, assim como sua arquitetura, objetos, classes, componentes,
implantao, workflow, entre outras.

Quando a "Unified Modeling Language" (UML) foi lanada, muitos

desenvolvedores da rea da orientao a objetos ficaram
entusiasmados j que essa padronizao proposta pela UML era o tipo
de fora que eles sempre esperaram, at mesmo por que antes do
surgimento da UML existiam muitos mtodos orientados a Objetos,
sendo que nenhum deles era completo o suficiente.

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 orientadas a objetos foram eles que desenvolveram. A
UML a juno do que havia de melhor nestas trs metodologias
adicionado novos conceitos e vises da linguagem.

Histrico

Vamos conhecer um pouco da histria da UML, como ela

 surgiu, e quem teve a idia de criar a UML.

Segundo UML, 2009, A UML comeou a ser definida a partir de uma

tentativa de Jim Rumbaugh e Grady Booch de combinar dois mtodos
populares de modelagem orientada a objeto: Booch e OMT (Object
Modeling Language). Mais tarde, Ivar Jacobson, o criador do mtodo
Objectory, uniu-se aos dois (formando os famosos trs amigos), para
a concepo da primeira verso da linguagem UML (Unified Modeling
Language).

Os esforos para a criao da UML tiveram incio em outubro de

1994, quando Rumbaugh se juntou a Booch na Rational. Com o
objetivo de unificar os mtodos Booch e OMT, decorrido um ano de
trabalho, foi lanado, em outubro de 1995, o esboo da verso 0.8 do
Unified Process - Processo Unificado (como era conhecido). Nesta
mesma poca, Jacobson se associou Rational e o escopo do projeto
da UML foi expandido para incorporar o mtodo OOSE. Nasceu ento,
em junho de 1996, a verso 0.9 da UML.

A UML proporciona alguma vantagem ou benefcio para quem

a usa?

Segundo Richards e Castilho (2009): A finalidade da UML

oferecer uma notao de modelagem independente de
linguagem e de plataforma. As ferramentas UML so to
versteis quanto a UML bsica. A UML simplesmente uma
linguagem de modelagem e independente de qualquer
linguagem de codificao. Portanto, assim como a UML pode
ser convertida em uma linguagem de codificao, uma
linguagem de codificao pode ser convertida em UML.

Saiba mais: acesse o site oficial para saber mais sobre a UML

http://www.uml.org/

VIDEO < -HERE

VIDEO < -HERE

WEB-AULA 1
Definio
Alguns consideram esse diagrama como sendo o mais fcil de todos
os diagramas da UML, j outros dizem o contrrio, apresentando
como justificativa o fato de um erro nesse diagrama causar srios
problemas no projeto como um todo.

Como o diagrama de casos de uso utilizado para anlise e

levantamento de requisitos, ele considerado como o diagrama mais
informal da UML, mesmo sendo utilizado como fonte de consulta
durante todo o processo de modelagem como base para outros
diagramas.

Esse diagrama apresenta uma linguagem simples e de fcil

compreenso para os envolvidos no processo de desenvolvimento,
para que estes possam ter conhecimento sobre o comportamento do
sistema.

Componentes

Logo abaixo sero citados alguns os componentes que compem esse

diagrama:

Ator: um ator (representado por um boneco, precedido do

seu nome) pode ser definido como um dos envolvidos no
projeto, que interage com o sistema. Um ator pode ser uma
pessoa, um usurio do sistema, um hardware ou um sistema
computacional.

Caso de Uso: um caso de uso (representado por uma elipse)

pode ser definido como uma ao ou necessidade que o sistema
deve atender, na viso do desenvolvedor de sistemas, um caso
de uso pode ser encarado como um mtodo ou um conjunto de
mtodos com um objetivo em comum.

Associao: representa a conversa entre ator e caso de uso,

atravs do envio e recebimento de mensagens (invocao de
mtodos).

Associao Unidirecional: indica uma associao entre ator e

caso de uso onde o ator somente solicita uma ao sem esperar
resposta, ou vice versa.

Associao Bidirecional: indica uma associao de envio e

 recebimento de mensagens entre ator e caso de uso.

VIDEO < -HERE

Include: um include um recurso utilizado para representar
que um dos componentes do diagrama de casos de uso
possuir alguns de seus comportamentos copiados em outro
caso de uso. Geralmente isso acontece, quando o cenrio
desses casos de uso estabelece aes que podem ser utilizadas
por mais de um caso de uso. As implementaes impostas por
esse componente so obrigatrias.

Extend: a extenso entre casos de uso pode ser encarada

como uma herana, onde existe um caso de uso filho que ir
herdar as caractersticas de um caso de uso pai, sendo que
este caso de uso filho se torna um caso de uso pai mais
especializado, por conter as operaes realizadas pelo pai,
juntamente com suas aes especficas. Esse recurso utilizado
para expressar rotinas de exceo e para descrever cenrios
opcionais de um Caso de Uso. As implementaes impostas por
esse componente so opcionais.

Generalizao: comparada extenso, a generalizao indica

que elementos de um sistema possuem caractersticas
parecidas, porm, um dos elementos mais especializado em
relao ao outro.

VIDEO < -HERE

So muitos os conceitos envolvidos quando falamos do
diagrama de caso de uso. Para saber um pouco mais, vocs
podero acessar o link:

http://pt.wikipedia.org/wiki/Diagrama_de_Caso_de_Uso

VIDEO < -HERE

VIDEO < -HERE
VIDEO < -HERE
 Especificao do caso de Uso Documentando o Caso de Uso

Especificao de requisitos de software

Desenvolver um sistema de software uma atividade que requer um

conjunto de habilidades com objetivo de entender as necessidades do
usurio e/ou cliente, analis-las, document-las num documento de
requisitos, desenvolver o projeto, implementar e testar o software.
Perceba que um engenheiro de software um profissional que possui
um conjunto de competncias e comum especializar-se em
alguma(s) dela(s). As atividades iniciais so importantes, j que
definem quais funcionalidades o sistema deve prover. Portanto, faz-se
necessrio descrever os requisitos de software com objetivo de
facilitar as etapas seguintes (projeto e implementao).

Note que um documento de requisitos de software precisa ser claro,

consistente e completo, pois ele servir de referncia aos
desenvolvedores, gerente de projeto e engenheiros de software
(responsveis pelos testes e manuteno do sistema). Requisitos bem
documentados consideram no apenas consistncia, completude e
clareza, mas tambm a evoluo dos requisitos e, portanto,
caractersticas do sistema de software. Dentro deste contexto, este
texto trata da especificao de casos de uso para detalhamento dos
requisitos de software.

Especificao de requisitos de software

A especificao de requisitos de um sistema de software descreve as

necessidades de usurios do sistema e, mais especificamente,
descreve o conjunto de funcionalidades que o sistema deve fornecer.
a partir desta especificao que o projeto de software
desenvolvido para, em seguida, ser implementado. Quaisquer
problemas como, por exemplo, de inconsistncia ou ambigidade,
resultar em possveis erros que precisaro ser corrigidos em alguma
etapa futura do processo de desenvolvimento.

Adicionalmente ao objetivo acima, uma especificao de requisitos

tem ainda outro objetivo, talvez at mais importante: comunicar de
maneira efetiva quais funcionalidades o sistema deve prover (ou
ainda, o que no ir prover). Perceba que a especificao de
requisitos ir apoiar a comunicao entre usurios (clientes),
projetistas, programadores, testadores.

O interesse o de especificar as funcionalidades ou requisitos

funcionais de um sistema. Nesse sentido, o sistema ir prover uma
determinada funcionalidade quando solicitado ou quando uma
condio for alcanada. Dessa forma, o que se tem uma interao
entre a funcionalidade (caracterizada pelo caso de uso) e um ator,
que pode ser um usurio (humano), um componente de software ou
algum hardware (ou dispositivo). Num exemplo simples do
conhecimento do leitor, tem-se a funcionalidade login de um sistema
web, a qual serve para autenticar o login e senha de usurios e
permitir acesso a determinada aplicao. Para essa funcionalidade, ou
caso de uso, h uma interao entre usurio e o caso de uso login.
Para tanto, um conjunto de passos usado para descrever o fluxo de
eventos da interao entre essas duas entidades. A seguir, a
especificao de casos de uso apresentada e exemplificada.

WEB-AULA 2
Especificao de casos de uso
Caso de uso uma tcnica de especificao que descreve uma
seqncia de aes que o sistema deve realizar para produzir uma
resposta para um ator. Na realidade, tem-se uma seqncia da
interao entre caso de uso e ator. O caso de uso detalha o que um
sistema deve fazer, descrevendo como uma determinada
funcionalidade utilizada por um ator.

Cabe destacar que um caso de uso compreende duas partes: o

diagrama de caso de uso e o caso de uso propriamente dito. O
diagrama de caso de uso um dos treze diagramas da UML (unified
modeling language) enquanto que o caso de uso consiste de um
template (ou modelo), conforme apresentado na logo abaixo, que
serve para detalhar a seqncia de passos de execuo do caso de
uso.

Os casos de uso servem para especificar as interaes existentes

entre o sistema em desenvolvimento e atores (ou entidades externas
ao sistema). Os atores compreendem usurios, estmulos externos
gerados por dispositivos eletrnicos ou outros sistemas
computacionais. Os atores podem ser considerados como entidades
externas ao sistema, j que esto fora da fronteira do sistema, e so
responsveis por gerar eventos para iniciar interao com o caso de
uso.

Outra recomendao evitar uso de termos especficos de

implementao, procurando manter o nvel de detalhamento
compreensvel ao usurio. preciso considerar que os casos de uso
devem levar em conta o vocabulrio do usurio. Alm disso, um
cenrio uma instancia de um caso de uso e, portanto, um caso de
uso pode conter um ou mais cenrios, conforme apresentado na
seo seguinte.

VIDEO < -HERE

Exemplificando a especificao de casos de uso

Casos de uso servem para especificar o comportamento de um

sistema de software ou parte dele, isto , descrevem um conjunto de
aes que produzem algum resultado. Note que o objetivo do caso de
uso especificar o o que e no o como um determinado sistema
realiza um objetivo. Um exemplo de diagrama de caso de uso
mostrado na Figura 28.

Figura 28. Exemplo de um caso de uso.

A figura contm um ator (cliente) e um caso de uso (validarcliente)

com o qual o ator interage. Note que podemos ter interaes entre
atores e casos de uso, cujo objetivo alcanar a meta do caso de uso
(realizando sua funcionalidade). Essas interaes ocorrem atravs da
troca de mensagens onde os atores se comunicam com o(s) caso(s)
de uso. O fluxo que descreve as aes (i.e. mensagens) trocadas
entre atores e caso de uso denominado de fluxo principal e compe
o ncleo do documento da especificao de casos de uso.

Esse documento contm um conjunto de informaes que so de

interesse do cliente, gerente de projeto, gerente de negcios a
programadores, analistas e engenheiros de testes. Nesse sentido, o
engenheiro de software, ao elaborar esse documento, busca um
compromisso de comunicar bem o conjunto de passos de cada caso
uso do sistema, bem como prover detalhes com suficiente clareza e
consistncia para pblico alvo, ou seja, os programadores e
engenheiros de testes (responsveis pela implementao do sistema
e elaborao e execuo de plano de testes, respectivamente).

A tabela 1 apresenta uma relao dos itens consideradas

imprescindveis em um documento de especificao de casos de uso.
A relao de itens destacados na tabela 1 no pressupe a inteno
de ser completo, mas de apontar os itens considerados como mais
importantes num documento da especificao de casos de uso para
uma empresa.
 Tabela 1. Relao de itens de um documento de requisitos.

Finalizando a especificao de caso de uso, lembrem-se de que os

requisitos compreendem a essncia de um sistema de software j que
eles definem as funcionalidades que o sistema deve fornecer e sob
quais condies o sistema deve operar. Portanto, de suma
importncia documentar de maneira adequada o conjunto de
requisitos para que as etapas seguintes do processo de
desenvolvimento de software aconteam de modo satisfatrio.

Assim, com o documento de requisitos em mos, um engenheiro de

software deve detalhar o conjunto de requisitos e, para tanto, ele faz
uso de um modelo de documento de especificao de casos de uso
para elaborar esse documento. A necessidade de trabalhar com um
modelo (ou template) fundamental para comunicar bem as
funcionalidades do sistema a ser desenvolvido para, por exemplo, o
arquiteto de software, gerente de projeto, programadores e
engenheiros de testes, os quais iro consultar as informaes
contidas nesse documento.

VIDEO < -HERE

VIDEO < -HERE

WEB-AULA 1
Diagrama de Atividades
O diagrama de atividades, geralmente apresentado como parte da
descrio funcional de um sistema, devido ao fato de especificar
processos lgicos (atividades do sistema e dos fluxos de dados ou
decises). Esse diagrama pode ser usado para:

Descrever atividades e fluxos de dados ou decises entre

atividades

Fornecer ampla visualizao de processos comerciais

Descrever as atividades que ocorrem em um caso de uso

No diagrama de atividades so apresentadas as relaes entre cada

atividade de um determinado processo, onde podem ser vistas as
 relaes de dependncia entre essas atividades, e quem so os
responsveis pelas suas execues.

Antigamente, ambientes comerciais utilizavam fluxogramas para

expressar comportamentos e modelar processos (decises), e esse
recurso apresentava-se como uma tcnica simples e fcil.

O diagrama de atividades juntamente com os casos de uso,

utilizado para representar as atividades que devem ser realizadas por
um ator para que aquele caso de uso tenha seus objetivos
alcanados, ou seja, como se d a interao entre sistema e ator,
para que os objetivos do caso de uso sejam alcanados.

Quando utilizar o diagrama?

Duas caractersticas que podem ser percebidas no diagrama de

atividades so:

Ele suporta e encoraja comportamento paralelo.

No so muito bem definidas as ligaes entre aes e objetos.

As situaes onde cabvel a utilizao do diagrama de atividades

so:

Ao analisar um caso de uso.

Utilizar para a compreenso do workflow

Caso haja necessidade de descrever um algoritmo seqencial

complicado

Quando possumos aplicaes com processamento paralelo.

WEB-AULA 2
Componentes do diagrama de atividades
Inicio

Todo diagrama de atividade inicia-se com o smbolo de inicio.

A notao de inicio representada por um circulo preenchido.
O diagrama de atividades no possui mais de um incio.

Fim
O diagrama de atividades utiliza a notao de um circulo preenchido
com um circulo vazado na sua extremidade.
Diferente do incio, o diagrama de atividades pode ter vrios fins.

Ateno! Nunca deixar as atividades sozinhas. Utilize a notao de

FIM para representar que aquela atividade terminou.

Atividades

Uma atividade (representada por um retngulo arredondado no diagrama de

atividades) representa uma ao ou uma etapa em um processo onde, algo
est sendo realizado. Ela pode indicar uma transao com banco
de dados, manipular informaes, gerar relatrios ou componentes de um
sistema, gerar um clculo enfim, indica uma ao que o sistema ir executar.
Segue abaixo a notao de atividade:

Transies

Transies indicam que uma atividade foi concluda, ou seja, a

passagem de uma atividade para a outra. Na UML elas so representadas
por uma seta, que parte de uma atividade inicial (a que foi finalizada) rumo
nova atividade que ser executada.
 VIDEO < -HERE

Uma condio de guarda restringe o uso de uma transio de acordo co

uma caracterstica especfica que existir para que a transio ocorra, ou
caso uma necessidade (condio de guarda) no seja atendida, a
transio no ocorrer. A representao da condio de guarda se d da
seguinte forma, colocada a condio dentro de colchetes, sobre a set
transio, e j se sabe, que caso aquela condio seja satisfeita, a trans
ocorrer.

Decises
No diagrama de atividades o cone para representao da estrutura de de
o losango, assim como nos fluxogramas. Podem ser avaliados quaisqu
tipos de deciso, desde os mais simples como testes lgicos de verdadei
Quando uma deciso dessas colocada no diagrama de atividades, duas
sadas so necessrias para representao: uma indica a ao que ser
tomada caso a condio verdadeira seja satisfeita e a outra indica ativid
que ser realizada se a condio falsa for satisfeita.Uma observao
importante que quando temos uma estrutura de deciso no diagrama
de atividades, as suas sadas (condio verdadeira ou falsa) podem atra
de uma transio apontar para outra estrutura de deciso, at que uma
atividade seja realizada, ou seja, apresentado o fim do workflow.
 Ponto de Merge

O cone do losango, utilizado na representao acima para indicar uma

estrutura condicional tambm utilizado como ponto de merge, onde,
mais de uma transio de atividade direcionada para ele e a partir del
somente um caminho seguido. Isso quer dizer que, posso ter vrias
atividades que sero executadas e aps sua execuo todas possuiro
mesmo destino (gerar um log, por exemplo), e para isso utilizamos o m

Concorrncia
A concorrncia pode ser definida como um processo de utilizao de
threads. Algumas vezes, em softwares necessrio que aes sejam
executadas em paralelo, para que, uma prxima atividade do fluxo de
trabalho s seja executada quando todos os threads forem finalizados.
A esse processo de diviso de uma atividade em vrias outras que oco
simultaneamente damos o nome de bifurcao ou diviso de controle
A barra de sincronizao utilizada para iniciar os threads tambm util
ao fim da execuo dos mesmos, unindo-os em um nico foco de control
 indicando que a prxima ao do workflow pode ser executada, e a
partir dela somente uma transio executada. Ao processo de trmin
execuo dos threads ou unio das mesmas em um nico foco de
controle d-se o nome de merge ou barra de sincronizao.

Vdeo <- here

SwimLane

SwimLane, tambm chamadas de Raias nada mais so que divises

do diagrama de atividade onde so colocados os papis responsveis
por executar determinadas atividades.

As raias organizam o diagrama de atividade para representar a

responsabilidades da atividade.

Caractersticas das raias:

As atividades nunca faro parte de duas raias, a atividade

pertence a apenas uma raia.

A transio poder passar entre uma raia e outra.

Cada raia tem um nome nico

Para compreender as raias, vamos imaginar uma situao muito
comum nos dias atuais, o saque em um terminal de auto-
atendimento.

Quando voc chega a um terminal de auto-atendimento, voc insere

o carto do banco, informa a senha e o banco autoriza o seu acesso.

Neste caso, temos duas responsabilidades, que voc cliente e o

banco.

Segue abaixo um exemplo de saque de dinheiro no terminal de auto-

atendimento.

Temos duas raias, o Cliente (que somos ns) e o Banco.

Percebe-se que as atividades no ficam entre as raias, e sim cada

atividade em sua respectiva raia, porm as transies podem cruzar
entre uma raia e outra.
 Vdeo <- here, 1

Vdeo <- here, 2

WEB-AULA 1
Porque fazer o diagrama de classes?
Em primeiro lugar, porque esse diagrama possibilita a modelagem de
qualquer objeto, sistema, situao ou projeto seja ele tcnico ou
comercial. O diagrama de classes um dos principais diagramas
responsveis pela gerao de cdigo, pois atravs dele, conseguimos
visualizar um sistema de uma forma mais ampla.

Segundo Pender, 2004 podemos considerar que o diagrama de

classes est no centro do processo de modelagem de objetos. Pois ele
fornece recursos que possibilitam identificar todas as regras que
conduzem a definio e ao uso de objetos.

O que uma classe?

Uma classe representa um conjunto de objetos, caractersticas e

comportamentos. A ela so atribudos objetos com caractersticas
semelhantes, sendo que, ela define o comportamento de seus objetos
atravs de mtodos (aes), e quais estados ele so capazes de
conter, atravs de atributo (caractersticas). Exemplo de classe:
Pessoas, Carro, Casa, Animal, Geladeira, enfim, qualquer coisa ou
pessoa pode ser abstrada em uma classe no mundo da programao
orientada a objetos. As classes so o alicerce do diagrama de classes.

Atributos: os atributos em uma classe representam as

caractersticas dessa classe, ou os tipos de informao
manipulados por ela. Por exemplo, uma classe do tipo pessoa
poderia ter atributos como idade (nmeros inteiros), ou nome
(literal), ou ainda endereo, enfim, informaes que a torne
diferente das outras pessoas.

Mtodos: mtodos so aes ou comportamentos realizados

pela classe, atravs deles podemos alterar os atributos das
classes, realizar transaes em banco de dados, enfim, eles
determinam as funcionalidades que o sistema possui, exemplos
de mtodos para a classe pessoa seriam andar(), falar(),
correr(), gritar(), pular(), enfim, aes que uma pessoa fosse
capaz de executar.

Vdeo <- here, 03



Padres para nomenclatura de classes

Quando vamos atribuir um nome a uma determinada classe alguns

padres devem ser seguidos, uns por restries das linguagens de
programao, outros por motivos de qualidade e outros ainda
adquiridos pela experincia em desenvolvimento de software passada
de gerao em gerao por desenvolvedores, abaixo sero citadas
algumas regras:

Todo o nome de classe deve comear com uma letra em caixa

alta (maiscula) seguido do restante das letras em caixa baixa
(minsculas).

O nome da classe deve estar relacionado ao tipo de informao

que ela manipula.

Quando houver nomes de classes, como ser humano, a regra

a seguinte:

o Cada nome iniciado com letra maiscula seguido das

letras minsculas.

o Por padro, nomes compostos formam uma nica palavra

o Exemplos de classes com nomes compostos:

SerHumano

AntVirus

HotDog

Nomes de classes no podem comear com nmeros (porm

podem conter nmeros).

Por uma questo de organizao, no aconselhvel acentuar

nomes de classes; a linguagem Java, por exemplo, no acusar
nenhum erro, e ir compilar a classe gerando o arquivo com
extenso class.

Visibilidade dos atributos das classes

A visibilidade das classes, assim como a dos atributos indica o nvel

de acesso delas em relao aos outros componentes ou classes que
compem o projeto de software ao qual essa classe pertena, so
eles:

+ Acesso Pblico (Public): quando atribudo este tipo de

visibilidade a uma classe, essa classe se torna acessvel ou
visvel a todas as classes e componentes do sistema. Quando
atribumos esse nvel de visibilidade aos mtodos ou atributos
da classe, os mesmos tambm adquirem visibilidade completa
em nvel de sistema e so acessados atravs da instncia de
um objeto desta classe.

# Acesso Protegido (Protected): a visibilidade protegida torna

os atributos e mtodos da classe visveis e utilizveis somente
por subclasses da classe protegida, assim como a prpria
classe. Nesse caso, Qualquer classe que no herde as
caractersticas da classe que possui os mtodos e atributos
protected no conseguir acess-los, e muito menos alterar
seus valores.

Acesso Privado (Private): esse tipo de acesso (o mais restrito),

garante que atributos e operaes possuam seus valores e
estados alterados somente pela classe no qual eles residem,
ou seja, restringe o acesso aos atributos e mtodos da classe
somente prpria classe (Visvel apenas dentro do namespace
que possui).

Acesso Esttico (Static): atravs dos outros tipos de visibilidade

de atributos e mtodos, podemos notar que para a utilizao de
um mtodo ou atributo, podemos seguir dois caminhos. No
primeiro, instanciamos um objeto da classe que desejamos
utilizar os mtodos ou atributos e aps realizar a instncia da
forma que desejarmos, j a segunda, podemos utilizar a
herana e manipular atributos de uma classe pai
(especializados em uma classe filha) atravs da instncia da
prpria classe filha. A principal desvantagem dos mtodos e
atributos estticos que, devido ao fato de ele no estar
vinculado a nenhuma instncia de classe em particular (como
citado acima), ele no pode utilizar os atributos e/ou mtodos
que no sejam estticos.

Vdeo <- here, 04

 Vdeo <- here, 05

WEB-AULA 2
Padres para nomenclatura de mtodos e atributos
Com relao a padronizao para nomenclatura de mtodos e atributos de
classe ou variveis, vale ressaltar a regra das letras minsculas e
maisculas. A assinatura de um mtodo se difere da assinatura de uma
classe em alguns aspectos:

Em primeiro lugar, nomes de mtodos devem comear com letras

minsculas.

os verbos utilizados para nomear os mtodos devem estar no imperativo (ar,

er, ir).

assim como os nomes de classes, nomes de mtodos devem indicar

comportamentos executados pelos prprios mtodos.

para nomes compostos utiliza-se a mesma regra de nomenclatura de

classes.

Esteretipo

O esteretipo indica como uma classe utilizada pelo projeto. Ele no faz
parte do nome da classe, e possui sua definio entre dois sinais de menor
(<<) e maior (>>).Eles so mecanismos de extensibilidade da UML que
permitem classificar elementos que possuem semelhanas. Os smbolos
utilizados para sua representao geralmente so colocados aps o
elemento que esta sendo estereotipado, e em seu interior est a descrio
atribuda ao elemento.

Associao
 Relacionamento normal: s vezes necessrio estabelecer um
relacionamento entre classes, para que uma saiba os comportamentos da
outra.

Generalizao: a capacidade de uma classe ou objeto herdar todas as

caractersticas de uma super classe ou classe pai, com isso, essa classe,
chamada sub-classe torna-se uma super-classe mais especializada, pois
possui caractersticas e comportamentos herdados de sua classe pai, e ainda
possui as caractersticas e comportamentos especficos dessa classe.

Agregao: um tipo de associao entre classes onde relacionamos o todo

com suas partes. Esse tipo de associao tambm conhecido como
relao de contedo, e indica que uma das classes contidas no
relacionamento uma parte ou est contida em outras classes. Em outras
palavras, a agregao pode ser definida como um objeto contendo
referncias para outros objetos, a agregao utilizada para dar nfase
detalhes de uma futura implementao. Atravs da uml, a agregao
representada da seguinte forma:

Composio: um tipo de uma agregao onde uma classe vive e compe

a outra. E caso haja a destruio do objeto da classe que contm, as demais
classes da agregao de destrudas tambm, pois fazem parte uns dos
outros

Tipos de classe

Associativa: uma classe interligada uma associao ao invs

de estar ligada a outras classes (se comparada ao banco de
dados indicaria o relacionamento N x N).

Classe concreta: tambm chamada de classe, uma classe que

possui mtodos e atributos e pode ser utilizada por outras
classes do sistema.
 Classe abstrata: so classes mais especializadas que
possibilitam herana de suas caractersticas por outras classes
do sistema. Objetos desse tipo de classe no podem ser
instanciados.
Vdeo <- here, 06

Vdeo <- here, 07

Vdeo <- here, 08

Os diagramas de objetos so bem semelhantes ao diagrama de
classe. Mostram uma fotografia de um sistema em execuo. Mostra
os objetos, com os valores de seus atributos e as ligaes entre eles.

Vdeo <- here, 08

O Diagrama de Objetos fornece uma viso dos valores armazenados

pelos objetos de um Diagrama de Classes em um determinado
momento da execuo de um processo

Permite um maior entendimento do problema e teis para a

modelagem de estruturas de dados complexas, focando apenas uma
parte dos objetos.

O Diagrama de Objetos no mostra a evoluo do sistema com o

tempo. Representam a estrutura do sistema em um dado momento.
Exibe um comportamento esttico de instncias encontrado em
diagramas de classe.

comum colocar um diagrama de classes junto com um diagrama de

objetos para facilitar a identificao dos objetos

Vdeo <- here, 09

WEB-AULA 1
Qual o objetivo do diagrama de Objetos?
Diagramas de objetos so usados quando no se consegue entender o
resultado que ser obtido pelo diagrama de classe e para mostrar o
instanciamento de uma classe na memria.
Vdeo <- here, 10

ornar)
A notao do diagrama de objeto semelhante ao diagrama de classe. Se
visto rapidamente, voc poder confundi-lo com o diagrama de classe.

Vdeo <- here, 11

WEB-AULA 1
Pacote
Um pacote pode estar dentro de outros pacotes. Esses podem estar em
qualquer diagrama na UML, porm eles so mais comuns em diagramas
de caso de uso para ajuda na abstrao do domnio do problema. No
diagrama de classe para organizar as classes construdas em sistemas
mdios e grandes.

O nome do pacote pode ser colocado na orelha se o pacote mostrar

membros internos ou na pasta principal se no for o caso.

Um pacote pode ser estereotipado. Quando isso acontece listado

dentro de divisas acima do nome. Tambm o pacote pode ser abstrato o
que indicado pela a palavra abstrato incluindo as chaves colocadas
abaixo do nome.
Um pacote simplesmente um mecanismo de agrupamento geral onde
colocado as definies de classes, definies Caso de Uso, definies de
estado relacionamento entre classificadores e os diagramas em que os
classificadores podem ser representados. Dentro de um pacote teremos
varias classes Java, alm disso, ele ser tambm um arquivo com
extenso .jar, um mdulo executvel em Java. Se caso no estiver
usando Java, deve-se procurar um forma de encapsular suas classes
para dar um significado a seus pacotes, por exemplo, um arquivo com
extenso .dll um conjunto de classes.

Um pacote pode conter outros pacotes dentro dele. Tambm um pacote

pode conter vrios diagramas de todo e qualquer tipo UML.

Para iniciarmos, a incluso das classes em pacotes teremos que j ter

terminado de analisar um subsistema de caso de uso. Para sistemas
grandes, talvez seja necessrio iniciar o empacotamento de outra forma,
talvez grande reas ou optar por subdividir um grande mdulo em
outros pequenos. De qualquer forma, o empacotamento sempre deve
ser efetuado.

No existe conceito para pacotes grande ou pequeno, a quantidade de

classe que estaro dentro deles depende do domnio do problema que
est enfrentando.

Para escolhermos quais as classes que iremos colocar dentro do pacote

precisamos de uma boa habilidade com projetos. Dois princpios so
teis. Principio do Fechamento Comum e o Princpio da Reutilizao
Comum. O Principio do Fechamento Comum as classes devem precisar
de alterao por motivos semelhantes. J o Principio da Reutilizao
Comum todas as classes devem ser reutilizadas juntas. Muito dos
motivos do agrupamento das classes esto relacionadas as dependncias
entre os pacotes.

Vdeo <- here, 12

Dependncias do Pacote

Num diagrama de pacote mostra pacotes e suas dependncias. As

dependncias entre os pacotes resumem as dependncias entre seus
contedos.

A UML tem variedades de dependncias, cada uma com uma semntica

e um esteretipo em particular.

Quanto mais dependncias entram em um pacote, mais estvel a

interface do pacote precisa ser, qualquer alterao na sua interface ser
propagada para todos os pacotes que depende delas.

Normalmente quando modela, monta os relacionamentos entre o

classificador em um pacote e outro classificador de pacote diferente.
Para modelar voc precisa acessar ou importar/ mesclar o classificador
a partir do segundo pacote.

Vdeo <- here, 13

WEB-AULA 2
Mesclando e importando
Na UML 1.x permite que voc especifique um relacionamento Import
ente os pacotes, fazendo com que voc traga uma cpia de um
classificador de outro pacote para o pacote em que est
trabalhando. A cpia nova do classificador importado pertence ao
pacote para onde voc importou enquanto tiver a verso original do
pacote original. Na UML 2.x o relacionamento Import est includo
no relacionamento Merge. Merge leva em conta o fato que voc
precisa resolver conflitos de nome ao importar alguns
classificadores, isto , especifica como lidar com uma situao onde
voc mescla uma classe chamada Carro de outro pacote sendo que
no seu pacote j possui uma classe chamada Carro com o seu
prprio conjunto de classe.

Utilizando o Merge ganhamos vantagem no trabalho. Enquanto voc

e outros modelam elementos mltiplos com o mesmo nome onde
significa a mesma coisa, o Merge permite que voc especifique e
sejam mesclados no pacote em que voc est trabalhando.

Um relacionamento Merge entre dois pacotes desenhado como

uma linha de dependncia, ou seja, uma seta tracejada com uma
ponta de seta aberta rotulado com o esteretipo merge.
 Quando exclumos um pacote, estamos excluindo todos os
elementos contidos por ele no qual ele possua, incluindo pacotes
aninhados e seus elementos possudos. O relacionamento Access
que esto visitando outros pacotes no excludo por ele existirem
no pacote que possui. Os elementos que foram mesclados de um
pacote externo iro existir em seu pacote original. Todos os
elementos do pacote excludo que atravs de relacionamentos
Access ou Merge que esto sendo usados em outros pacotes, so
excludos desses pacotes.

WEB-AULA 1
DIAGRAMA DE SEQUNCIA
Antes de criarmos o diagrama de sequncia, teremos que criar alguns
componentes que fazem parte dele, e esses so: atores e classes. Para esse
diagrama importante que, ao criar as classes, j sejam definidos seus
mtodos, pois, o diagrama utiliza-se destes para o controle no envio das
mensagens.
 Vdeo <- here, 14

Vamos utilizar como exemplo apenas um dos casos de uso do sistema, o Controlar
Veculo. Esse caso de uso tem a finalidade de incluir, excluir, carregar, alterar, listar
e consultar os dados referentes aos veculos da empresa, e, esse caso de uso
executado pelo vendedor da loja. Ento, vamos dar incio ao nosso diagrama:

1 Passo: Na pasta atores, clicar com o boto direito do mouse, selecione o menu
Create Model, e logo aps selecione a opo Add Actor. Um novo ator ser
adicionado a pasta, e, o nome dele deve ser alterado para Vendedor.

Adicionando atores ao projeto

2 Passo: Criao das classes. Na pasta classes, clicar com o boto direito do
mouse, selecione o menu Create Model, e logo aps selecione a opo Add class.
Com isso iremos criar a primeira classe do nosso diagrama. Para a representao
do diagrama de sequncia do caso de uso controlar veculo, so necessrias duas
classes: Veiculo e Diferenciais. (Sem acento, e com as iniciais maisculas).
Adicionando classes ao projeto

3 Passo: Adicionar mtodos das classes. Para que possamos criar o diagrama de
sequncia necessrio que os mtodos de cada classe estejam definidos. Para
adicionar um mtodo a uma classe, existem duas formas:

Clicar com o boto direito do mouse sobre a classe (na estrutura do

projeto: arquitetura), selecionar o menu Create Model, e em seguida selecionar a
opo Add Operation.

Clicar com o boto esquerdo do mouse sobre a classe, e em seguida, no

menu de propriedades da classe, selecionar a aba operation. Em operation clicar
em Add.

Adicionar os seguintes mtodos s classes: incluir(),excluir(), alterar(),

listar(), consultar().

Ento devemos informar o nome do mtodo e seu tipo de retorno.

 Adicionando mtodos classe - 1 Adicionando mtodos classe - 2

4 Passo: Adicionar o ator e as classes ao diagrama criado.

Para adicionar ator e classes ao diagrama, basta clicar sobre
os mesmos com o boto esquerdo do mouse e arrast-los para
a rea destinada ao diagrama, colocando-os de acordo com a
sua precedncia (nvel hierrquico de classes). Aps adicionar
um componente ao diagrama, apresentada sua LifeLine,
como veremos na figura abaixo.

LifeLine, adicionando classes e atores ao diagrama

5 Passo: Adicionar formulrio (front-end) com o ator. No
diagrama de sequncia devemos adicionar uma nova classe, que
serve para processar as solicitaes do usurio, e notific-lo de
acordo com as mensagens recebidas das outras classes (respostas).
Essa classe geralmente tem o nome form, pois representa um
formulrio onde o ator, ao solicitar algo do sistema, ativa um fluxo
de envio e recebimento de mensagens pelas classes do mesmo.

Criar Lifelline - Form Lifelline - Form

6 Passo: Estabelecer a comunicao entre os objetos. Aqui estabelecemos

como se dar o envio das mensagens entre os objetos do sistema, utilizando-
se dos tipos de mensagens (assncrona e sncrona). Para adicionar uma
mensagem sncrona, clique sobre o boto message, ento, selecione o objeto
que ir enviar a mensagem e o objeto que a ir receber.

Vdeo <- here, 15

Adicionando mensagem sncrona Adicionando retorno de mensagem

7 Passo: Estabelecendo as mensagens enviadas e recebidas. Ao clicar

com o boto direito do mouse sobre as setas de mensagens, podemos
visualizar suas propriedades. Atravs das propriedades das mensagens
podemos atribuir vrias caractersticas mensagem que est sendo
enviada, tal como, tipo de retorno, parmetros da mensagem, tipo de
mensagem, entre outros. A propriedade operation apresenta os mtodos
que a mensagem pode enviar, para alterar o valor, basta selecionar uma
das opes fornecidas nessa lista.

Vdeo <- here, 16

Observao: Os mtodos dessa lista esto definidos na classe (aps o hfen).

Propriedades de uma mensagem

8 Passo: estabelecendo as mensagens de retorno. Existem casos, onde

necessrio estabelecer uma mensagem de retorno, quando um objeto
invoca um mtodo de uma determinada classe. Por exemplo, ao invocar o
mtodo listar da classe veculo, o sistema deve retornar uma lista
(ArrayList, List) com os veculos que a empresa possui. Contudo,
mensagens de retorno podem conter vrios contedos, que vo desde
arrays e objetos, at mensagens que aparecero para os usurios. Para
adicionar uma mensagem de retorno, verifique, em primeiro lugar, se a
comunicao entre os objetos est sendo realizada de forma sncrona,
caso no esteja, habilite essa opo nas propriedades da seta. Logo aps
certificar-se, clique sobre o boto Reply message, ento selecione o objeto
que ira enviar e receber a resposta, ento, na aba e propriedades
 Retorno de mensagens

Diagrama de sequncia completo

 Diagrama de sequncia completo.

Vdeo <- here, 17

WEB-AULA 2
Diagrama de Estados
Para criar um diagrama de estados, devemos observar o
comportamento dos objetos durante o ciclo de vida do software e as
mensagens enviadas e recebidas por cada um. Para representao do
modelo, iremos fazer o diagrama de estados da classe veculo. Muito
bem, em primeiro lugar, precisamos saber:
 Quais os possveis estados para o veculo.

Qual o vnculo entre os estados.

Nosso veculo pode conter cinco estados, so eles:

Disponvel, Alugado, Em Manuteno, Reservado, Sem reparo.

Ateno Assim como o digrama de atividades, o diagrama de estados

deve possuir somente um incio, sendo que, para que haja mais de um
incio nesse diagrama, necessrio que haja subestados, em que dentro
de cada sub-estado surja um novo diagrama, com incio e fim bem
definidos.

Vdeo <- here, 18

Criando o diagrama de estados

1 Passo: Definir o incio do diagrama. Para isso clique com o boto

direito do mouse sobre a opo Initial PseudoState, ento clique na rea
do diagrama. Ser definido nosso ponto inicial no diagrama.

2 Passo: Criar os states. Para adicionar os states ao diagrama, basta

clicar com o boto direito do mouse sobre o item states e clicar na rea do
diagrama. Aps adicionar o state ao diagrama, necessrio dar um nome
a ele, que ser a representao do seu estado atual.

3 Passo: Estabelecer a comunicao dos states. Para que os estados de

um objeto possam mudar no decorrer do tempo, necessrio que hajam
modificaes causadas pelo envio de mensagens de outros objetos ou por
alguns acontecimentos.

Vdeo <- here, 19

A representao no diagrama de estados para a mudana de um estado

A para um estado B se d atravs do componente Transition. Com este
componente, eu seleciono o estado inicial do objeto, informo o evento
ou acontecimento que ir alterar o seu estado, e seleciono o estado que
o objeto possuir aps a execuo do evento. A explicao
representada na figura abaixo.
Para utilizar esse componente, siga os seguintes passos:

Selecione o componente state na barra de ferramentas

Selecione o estado inicial do objeto,

E em seguida, selecione o estado final do mesmo.

Para informar o que alterou o estado selecionado, clique com o boto

esquerdo do mouse sobre a seta (state), e, nas opes, informe no
campo Guard a descrio do evento que alterou o estado.

Vdeo <- here, 20

Diagrama de Estados Completo.

Vdeo <- here, 21

WEB-AULA 1
DIAGRAMA DE COMPONENTES
Componentes so conceitos rapidamente confusos na UML, pois tanto
classes quanto componentes podem ser usados para modelar a mesma
coisa.

Na UML 2.0 mudou-se a definio da metaclasse Component. Agora ela

uma subclasse de Class em vez de Classifer. Como uma sublcasse de
Classifer, um componente no poderia ter atributos ou mtodos prprios.

A finalidade de um componente explicar os artefatos que soa usados

para implementar a expresso de projeto lgico nos diagramas Caso de
Uso e Classe.

O aninhamento dos elementos de um componente dentro foi definido de

modo tanto indistinto por meio de ModelElement. ModelElement, uma
classe bsica para praticamente qualquer elemento de diagrama UML.
Incluindo associaes, classes, objetos, mensagem e outros.

Vdeo <- here, 22

Criando Componente

A mudana observvel no diagrama de componente o cone

componente. Na Figura abaixo mostrado o cone antigo e o novo cone.
A UML optou por usar um retngulo simples com o esteretipo
component ou como mostrado na Figura, um cone retngulo onde
possui um adorno no canto superior direito do smbolo do componente
como uma abreviao para o esteretipo conforme figura.

Diferena na UML 1.x com a 2.0

Modelando dependncias

No incio da modelagem no temos todos os detalhes da interface para

os componentes. s vezes, poderemos ignorar esses detalhes a fim de
se concentrar na finalidade de cada componente e seus relacionamentos
bsicos. Bem, de qualquer forma o foco passa a entender as
dependncias bsicas. Na Figura abaixo mostrado um conjunto de
componentes em um nvel de viso geral. A interface no aparece no
diagrama. E sim, somente dependncias.

Curso de Extenso - Uml(unified Modeling Language) na Prtica

Modelando realizao de componente

A UML 2.0 inclui um conceito de realizao. A realizao se refere a

qualquer implementao de um requisito. Componente uma abstrao,
uma representao de um requisito para o software fsico. A realizao
uma entidade concreta que transforma o requisito em uma realidade ou
realiza o requisito. Um componente pode estar associado a qualquer
quantidade de realizaes.

A realizao pode ser referir a um classificador. O classificador uma

superclasse que descreve qualquer coisa que representa um conjunto de
instncias e pode conter recursos. Eles incluem classes, interfaces,
comportamentos e tipos de dados e no esto limitados.

A especificao UML oferece dois esteretipos padro para o componente.

O realization e o specification que definem se o componente usado
como uma especificao pura ou como uma implementao.

Um componente realization define um ou mais conjuntos de

classificadores de implementao. J o componente specification se
refere a um ou mais classificadores de especificao.

Na Figura abaixo, a realizao para o componente pedidos so classes

Pedido e ItemLinha. O componente pedido implementado pela
instanciao das classes de pedido e item de linha.
 Modelando interface

Vdeo <- here, 22

Modelar interface de componente um recurso fundamental. a

capacidade de definir interfaces. preciso expor alguns meios para
que os componentes se comuniquem com outros componentes. A UML
2.0 aplica os conceitos de interface e porta a componentes e a classes.

As interfaces podem ser de dois tipos, as exigidas e fornecidas. As

exigidas os componentes podem definir componentes. Por exemplo, o
componente pedido pode oferecer capacidade de incluir itens de linha
ao pedido, cancelar o pedido e pagar pelo pedido. O inicio do projeto
do componente define a implementao dos comportamentos. A
interface define como outro componente precisa pedir acesso a um
servio fornecido.

A fornecida quando o componente precisa da ajuda de outros

componentes e precisa definir exatamente o que ele precisa. Por
exemplo, o pedido precisa ser capaz de descobrir se um desconto se
aplica aos itens comprados no pedido. Mas em si o pedido no tem
recursos para responder a essa pergunta e por isso ele define uma
interface indicando o tipo de ajuda exigida.

Nas Figuras abaixo ilustra o componente pedido com interfaces

fornecidas a esquerda para acrescentar itens de linha ao pedido,
cancelar o pedido e pagar pelo pedido. Uma interface exigida a direita
 para aplicar o desconto.

A UML 2.0 admite o uso de classes para descrever as interfaces tendo

em vista que as interfaces podem ser mais complicadas do que os
exemplos. O uso de classe permite acrescentar as assinaturas de
interface explicitamente no diagrama.

A UML 2.0 oferece um meio de representar toda a informao definida

at aqui para um componente, incluindo interfaces, realizaes e
artefatos. Isso possvel, pois o componente agora um tipo de
classe. Uma classe pode ter compartimentos e recursos.

Vdeo <- here, 23

WEB-AULA 2
Diagrama de Implantao
O diagrama de implantao onde modela toda a infra-estrutura do
ambiente externo.
Normalmente mostrado servidores neste diagrama. Este recurso
chamado de ns.
Cada n uma maquina fsica que encerra em um ou vrios
componentes.
A Figura abaixo mostra um exemplo de diagrama de implantao.

Diagrama de Implantao

Os Diagramas de Implantao so valiosos porque eles modelam a

plataforma de

hardware para um sistema e identificam as capacidades do hardware

que afetam o planejamento do desempenho e a configurao do
software.

Vdeo <- here, 23

O Diagrama de Implantao modela a arquitetura de hardware
identificando os processadores. Os processadores normalmente so
computadores ou equipamento. Tambm podem ser pessoas que
realizam processamento manual.

ltimo Vdeo <- here, 24

 isso ai pessoal! Estamos finalizando nossa aula.
Esperamos que vocs tenham aproveitado. Abraos.