Modelagem_UML_overview

Prévia do material em texto

1
Modelagem Orientada a Objetos
com UML (Overview)
Prof. Edson dos Santos Cordeiro
2
Introdução...
?A UML (Unified Modeling Language) é uma
linguagem para especificação, construção,
visualização e documentação de sistemas de
software.
?A notação UML é uma união de sintaxe gráfica
de vários métodos.
?O resultado é uma única, comum e ampla
linguagem de modelagem utilizável por
desenvolvedores de software orientado a objetos.
3
Introdução...
?Os esforços são concentrados em um
metamodelo comum, que unifica as semânticas,
e em uma notação comum que fornece uma
interpretação humana destas semânticas.
?O uso do termo metamodelo se justifica
considerando que se trata de uma linguagem
para especificar modelos.
?Este metamodelo fornece uma declaração única
e comum da sintaxe e semântica dos elementos
da UML.
4
Introdução...
?Todos os métodos abordam a modelagem de
sistemas (OO) com competência, porém, existem
pontos fracos e fortes em cada método.
?A existência de muitos métodos OO gera alguns
problemas:
?diferenças casuais e desnecessárias entre os métodos
confundindo os usuários (analista, projetistas, etc.);
? falta de um padrão estável, maduro, “completo” que
permita a modelagem de sistemas e produção de
ferramentas com recursos mais úteis.
5
Introdução...
?“A UML é apenas uma linguagem e, portanto, é
somente uma parte de um método para
desenvolvimento de software.
?UML é independente do processo, apesar de ser
perfeitamente utilizada em processo orientado a
casos de uso, centrado na arquitetura,
interativo e incremental”.
6
Introdução...
?O que é uma linguagem?
?Definição de linguagem: tudo quanto serve para
expressar idéias, sentimentos, modos de
comportamentos, ... Todo o sistema de signos que
serve de meio de comunicação entre indivíduos...
(Aurélio, 1986).
?Linguagem de modelagem (no contexto da
informática) disponibiliza uma série de
representações (notações) e regras que permitem o
projeto de sistemas no âmbito conceitual e físico.
?Linguagem de modelagem é um meio pelo qual pode-
se abstrair e projetar sistemas de informação e
consequentemente promover a compreensão de suas
diversas estruturas.
7
Introdução...
?A UML é uma linguagem destinada a:
?Visualizar
?Especificar
?Construir
?Documentar
8
Introdução...
domínio
Modelo de análise Modelo de projeto
?UML aborda:
9
Introdução...
?A UML é uma integração de técnicas de diversos
métodos (OOSE, OMT E BOOCH).
?OOSE: abordagem orientada a use case que
fornece excelente suporte para especificação de
requisitos.
?OMT: é especialmente expressivo para a análise
de sistemas de informação, contribuiu com o
Diagrama de Classes e Diagrama de Estados.
?BOOCH: utiliza a idéia de Diagrama de Estados,
Diagrama de Classes, Diagrama de Objetos.
10
Introdução...
?O método Fusion também colaborou com o
Grafo de Interação de Objetos.
?O Statecharts de Harel, contribuiu para a
criação do Diagrama de Atividades.
UML
OMT
(Rumbaugh)
OOSE
(Jacobson)
? Diagrama de Estados
? Diagrama de Classes
? Diagrama de Objetos
 (Diagrama de Colaboração)
? Diagrama de Processos
(Diagrama de Deployment)
? Diagrama de Módulos
 (Diagrama de Componentes)
? Diagrama Use Cases
? Subsistema (Package)
? Diagrama de Classes
? Diagrama de Estados
BOOCH
FUSION
(Coleman)
Statecharts
(Harel)
? Grafo de Interação
 de Objetos
? Diagrama de Statecharts
 (Diagrama de Atividades)
11
Processo de Desenvolvimento em UML
?O Processo de Desenvolvimento de Software com
a UML está estruturado, segundo o tempo, em
quatro fases:
?Concepção: especifica da visão do sistema;
?Elaboração: planejamento das atividades necessárias
e dos recursos requeridos e a especificação do
sistema e design da sua arquitetura;
?Construção: desenvolvimento do produto como uma
série de interações incrementais;
?Transição: fornecimento do produto para o usuário
(fabricação, distribuição e treinamento).
12
Visões do Sistema: Rose...
?A ferramenta ROSE, que implementa a UML,
especifica o sistema segundo quatro visões:
?Use Case View: descreve o sistema como um
conjunto de transações do ponto de vista dos atores
externos. Esta visão é inicialmente criada na fase de
concepção do ciclo de vida e direciona o resto do
processo.
?Logical View: contém a coleção de packages, classes
e relacionamentos. Esta visão é inicialmente criada
na fase de elaboração e refinada na fase de
construção.
13
Visões do Sistema: Rose
?Component View: contém módulos e subsistemas.
Esta visão é inicialmente criada na fase de elaboração
e refinada na fase de construção.
?Deployment View: contém a parte física do sistema e
a conexão entre estas partes. Esta visão é criada na
fase de elaboração do processo.
14
Principais Técnicas...
?Use Case View
?Diagrama de Use Case;
?Descrição do Use Case;
?Diagrama de Seqüência;
?Diagrama de Colaboração.
?Logical View
?Diagrama de Classes;
?Diagrama de Estados.
?Component View
?Diagrama de Componentes.
?Deployment View
?Diagrama Deployment.
15
Visões
Use Case View
Logical View
16
Diagrama de Use Case - DCU
?Tipicamente usado para especificar ou
caracterizar a funcionalidade e o
comportamento de um sistema de aplicação,
interagindo com um ou mais atores externos.
?Os use cases são desenvolvidos de acordo com
os eventos que ocorrem entre os agentes
externos e o sistema.
17
DCU - Casos de Uso
?O que são requisitos:
? “Requisitos são uma descrição das necessidades ou desejos
para um produto.
?O objetivo básico para a fase de requisitos é identificar e
documentar o que é realmente necessário, em uma forma que
comunica claramente essa informação ao cliente e aos
membros da equipe de desenvolvimento.
?O desafio é definir os requisitos de maneira não ambígua, de
modo que os riscos sejam identificados e não aconteçam
surpresas quando o produto for finalmente liberado”
18
DCU - Casos de Uso
?Defina o que o sistema deverá fazer (Requisitos
Funcionais):
?Calcular valor total (soma dos itens) da nota fiscal;
?Emitir recibo após a efetivação da venda;
?Entrada e baixa automática de estoque;
?Enviar e-mail para clientes aniversariantes;
?Emitir diariamente relação de clientes devedores;
?Fazer backup dos arquivos após o expediente;
?...
19
DCU - Casos de Uso
Ref. Função
R1.1 Registrar a venda em andamento - itens comprados.
R1.3 Capturar a informação do item adquirido através de
código de barra ou entrada do código manual.
R1.2 Calcular venda: valor itens, imposto, desconto.
Funções básicas do sistema:
R1.4 Efetuar a baixa do item após completar a venda.
R1.5 Registrar as vendas completadas.
R1.6 Fazer “log in” com id e senha para usar o sistema.
R1.7 Prover um mecanismo de armazenamento.
R1.8 Exibir a descrição e o preço do item registrado.
20
DCU - Casos de Uso
Ref. Função
R2.1 Tratar pagamento em dinheiro, capturar a
quantidade recebida e calcular troco.
Funções de pagamento
R2.2 Tratar pagamento com crédito, capturar informação
através de leitora de cartão ou manual.
R2.3 Tratar pagamento com cheque, capturar número da
conta e cheque através de entrada manual.
R2.4 Registrar o pagamento de prestações em contas a
receber mediante autorização do setor de crédito.
21
DCU - Casos de Uso
?“Um caso de uso é um documento narrativo que
descreve a seqüência de eventos de um ator (um
agente externo) que usa um sistema para
completar um processo”.
?Casos de uso ilustram as “relações” que o
sistema manterá com agentes externos.
?Agentes externos podem ser pessoas, outros
sistemas, etc.
22
DCU - Casos de Uso
?As “relações” definem as ações que o agente externo
exigirá do sistema a ser desenvolvido e,
consequentemente, o comportamento (resposta) que
o sistema deverá emitir.
?Casos de uso não podem ser enquadrados como
especificação de requisitos (funções e atributos) do
sistema e sim como ilustrações de situações
(contextos) da realidade onde o sistema será
implantado. Não existe um formato ideal de caso de
uso.
23
DCU - Casos de Uso: Exemplo
Caso de uso: nome do caso de uso.
Atores: lista de atores (agentesexternos).
Descrição: descrição, seqüencial, dos eventos do caso de uso.
Caso de uso: Comprar itens.
Atores: cliente, caixa.
Descrição:um cliente chega a um ponto de pagamento, com os itens
que deseja comprar. O caixa registra os itens de compra e recebe o
pagamento. Ao término, o cliente deixa a loja com os itens.
24
DCU - Casos de Uso
?A seqüência típica de eventos (seqüência mais
comum) é parte importante do caso de uso
expandido.
?Sua finalidade é demonstrar de forma detalhada
uma narrativa da interação (“diálogo”) entre o
sistema e o agente (ator) obedecendo a seqüência
em que ocorrem.
Agente Sistema
Solicitação 1
Resposta solicitação 1
Solicitação 2
Resposta solicitação 2
25
DCU - Casos de Uso
1. Este caso começa quando um cliente chega a
um ponto de pagamento com vários itens que
deseja comprar.
2. O caixa registra o identificador de cada item.
Se houver mais de um exemplar do mesmo
item, o caixa entra com a quantidade.
4. Ao término da entrada de itens, o caixa indica
ao Terminal que a entrada de itens está
completa.
6. O caixa informa ao cliente o total da venda.
7. O cliente paga em dinheiro. Possivelmente o
valor é maior que o total da venda.
8. O caixa registra o pagamento recebido.
10. O caixa deposita o dinheiro e retira o troco. O
troco e recibo são entregues ao cliente.
12. O cliente sai com os itens comprados.
3. Determina o preço do item e acrescenta a
informação sobre o item à transação
corrente de venda. A descrição e o preço
do item corrente são exibidos.
5. Calcula e apresenta o total da venda
corrente.
9. Exibe o valor do troco a ser devolvido.
11. Registra a venda completada.
Ação do agente (ator) Resposta do sistema
26
DCU - Casos de Uso: Seqüência Alternativa
?Linha 2: identificador inválido fornecido. Indicar erro.
?Linha 7: o cliente não tem dinheiro suficiente. Cancela a
transação da venda.
27
DCU - Casos de Uso: Modelo (sugestão)
- Caso de uso: <nome do caso de uso>
- Seção: <nome da seção>
Caso de uso: <nome do caso de uso>
Atores: <atores envolvidos>
Finalidade: <finalidade do caso de uso>
Visão geral: <caso de uso de alto nível>
- Seqüência típica de eventos
Ação do ator Resposta do sistema
... ...
- Seqüência alternativa
<Número da linha>:<Descrição da exceção>
28
DCU - Casos de Uso
?O caso de uso pode ser descrito em qualquer
editor de texto (Notepad, Winword, Bloco de
Notas etc);
?É possível associar um documento, por
exemplo, um arquivo texto contendo um caso de
uso a um modelo na Rational Rose.
29
DCU - Casos de Uso
30
Diagrama de Use Case
?Os agentes externos e qualquer outro sistema
que possa interagir com o sistema que está
sendo modelado são chamados de atores.
?Um ator modela um tipo de objeto que interage
diretamente com o sistema. Cada ator deve ter
um nome, como AtorCliente.
AtorCliente
<<Actor>>
31
Diagrama de Use Case
?Um ator pode:
?apenas fornecer informações ao sistema;
?apenas receber informações do sistema;
?fornecer e receber informações do sistema.
?Perguntas para identificar um ator:
?quem se beneficiará do uso do sistema?
?quem utilizará o sistema?
?quem suportará e manterá o sistema?
?uma pessoa representa vários papéis?
?quem fornecerá informações ao sistema?
?Quem receberá informações do sistema?
32
Diagrama de Use Case
?Criar um ator no Rational Rose:
?Crie os atores: estudante, professor e funcionário.
33
Diagrama de Use Case
?A construção dos diagramas de casos de uso
pode iniciar-se através dos casos de uso
definidos na etapa anterior.
?Os diagramas de casos de uso demonstram as
funções que o sistema desempenhará (casos de
uso) e os agentes envolvidos neste processo.
----------------------------------------------------------------
Casos de uso Diagrama de Casos de uso
----------------------------------------------------------------
34
Diagrama de Use Case
?Um use case é uma seqüência de transações
realizadas pelo sistema em resposta ao disparo
de um evento.
?Um use case modela a diálogo entre um ator e o
sistema.
?Nomes de use cases freqüentemente iniciam com um
verbo.
?Um use case é mostrado como uma elipse contendo
um nome como CadastrarCliente.
CadastrarCliente
35
Diagrama de Use Case
?Criar um use case no Rational Rose:
?crie os uses case: matricular aluno, manter
informações do professor e aluno.
36
Exemplo de Use Case e Atores
37
Exemplo de Use Case e Atores
Fronteira
Comprar itens
Log in
(iniciar uso)
Reembolsar
itens compradosCaixa Cliente
Atores (agentes)
Casos de uso
38
Diagrama de Use Case
?Relacionamentos permitidos nos use cases:
Relacionamento De um Use Case para
Associação Um ou mais atores
Generalização Um use case
39
Construindo o DCU
1. Após as funções o do sistema terem sido listadas
(requisitos funcionais), identifique atores e casos de
uso.
2. Escreva todos os casos de uso em um formato de
alto nível.
3. Desenhe um diagrama de caso de uso.
4. Relacione os casos de uso e ilustre os
relacionamentos no diagrama de casos de uso.
40
Visões
Use Case View
Logical View
41
Diagrama de Classes
?Um Diagrama de Classes é uma representação
gráfica para descrições genéricas do sistema.
Pode ser usado na:
?Análise: Mostrar regras e responsabilidades comuns
de entidades que fornecem o comportamento do
sistema e,
?Projeto: Capturar a estrutura das classes que
formam a arquitetura do sistema.
?Uma classe captura a estrutura e o
comportamento comum de um conjunto de
objetos.
42
Diagrama de Classes
?Alguns elementos modelados no diagrama de
classes:
?Atributos: Informações do objeto da classe.
?Operações: Serviços fornecidos pela classe.
?Visibilidade (atributos e operações):
?public: os elementos são acessíveis por todas as classes;
?private: os elementos são acessíveis somente pela própria
classe e classes friends (C++);
?protected: os elementos são acessíveis somente pela própria
classe, subclasses ou pelas classes friends (C++); e
? implemented: os elementos são acessíveis somente pela
própria classe.
43
Diagrama de Classes
?Criar uma classe no Rational Rose:
?crie as classes: Disciplina, Turma e Sala
44
Diagrama de Classes
Descrição
Carga horária
Disciplina
setDescricao
setCargaHoraria
getDescricao
getCargaHoraria
Nome da classe
Atributos
Operações
45
Diagrama de Classes
?Definindo os atributos no Rational Rose:
?crie os atributos descrição e carga horária para a
classe disciplina.
46
Diagrama de Classes
?Definindo as operações no Rational Rose:
?crie as operações get e set Descrição e get e set Carga
horária.
47
Diagrama de Classes
?Definindo a visibilidade dos atributos:
48
Diagrama de Classes
?Relacionamentos:
?Os relacionamentos, entre classes, existentes na UML
são:
?Generalização;
?Dependência;
?Associação e,
?Agregação.
49
Diagrama de Classes
?Generalização (Herança):
?Um relacionamento de generalização entre classes
mostra que a subclasse compartilha a estrutura e/ou
comportamento definido em uma ou mais
superclasses. Representa o relacionamento “é-um(a)”
entre as classes.
superclasse
subclasse
50
Diagrama de Classes
?Dependência:
?Um relacionamento de dependência entre duas
classes mostra que a classe cliente depende da classe
servidora, para sua existência.
Funcionário Dependente
51
Diagrama de Classes
?Associação:
?Um relacionamento de associação representa uma
conexão semântica entre duas classes e é o
relacionamento mais utilizado. Pode ser bidirecional
ou unidirecional e é representado por uma linha
ligando as classes
Fornecedor Pedido
Cliente Pedido
Associação unidirecional
52
Diagrama de Classes
?Agregação:
?Um relacionamento de agregação é uma forma
especial de associação, que é usada para mostrar que
um tipo de objeto é composto de outro objeto. Um
relacionamento de agregação é também chamado de
“todo-parte”.
Classe TodoClasse Parte
53
Diagrama de Classes
?A agregação pode ser implementada na UML
como agregação por referência ou por valor:
?Valor: A agregação por valor indica que o tempo de
vida das partes são dependentes do tempo de vida do
todo. Quando a agregaçãoé por valor, o “objeto todo”
declara uma instância atual do “objeto parte” dentro
do corpo do próprio “objeto todo” (losango cheio).
?Referência (default): significa que o “objeto todo”
mantém um ponteiro ou uma referência para suas
partes (losango vazio).
54
Diagrama de Classes
?Exemplo de agregação por referência e por valor.
Aluno
Curso
DetalhePedido
Pedido
Referência Valor
55
Diagrama de Classes
?A multiplicidade especifica o número de
instâncias de uma classe em relação a outra em
uma associação.
?0..1 Zero ou uma instância.
?1 Somente uma instância.
?0..* Zero ou mais instâncias.
?* (Default) número mínimo e máximo de 
instâncias são ilimitados.
?1..* Uma ou mais instâncias.
56
Diagrama de Classes
?<literal>..* Número exato ou mais instâncias.
?<literal> O número exato de instâncias.
?<literal>..<literal> Faixa de instâncias especificadas.
?<literal>..<literal>,<literal> Número exato de
instâncias ou o número de instâncias estará na faixa
especificada.
?<literal>..<literal>, <literal>.. <literal> Número
de instâncias estará em uma das faixas especificadas.
<literal> é qualquer inteiro maior ou igual a 1
57
Bibliografia
?Larman, Graig. Utilizando UML e padrões.
Bookman, 2000.
?Booch, G.; Rumbaugh, J.; Jacobson I. UML:
guia do usuário. Campus, 2000.
?Prado, A. F. Projeto Orientado a Objetos.
UFSCar.
?Quatrani, Terry. Modelagem visual com Rational
Rose 2000 e UML. Ciência Moderna, 2001.