UML parte 7

Prévia do material em texto

ivaldir 
Modelagem de 
Sistemas 
Introdução a UML 
Histórico 
 1950/60 – Sistemas ad hoc 
 1970 – Programação estruturada 
 1980 – Análise estruturada moderna 
 1990 – Análise Orientada a Objetos 
 Shaler, Mellor, Booch, Jacobson, Rumbaugh 
Histórico – Técnicas de 
modelagem OO 
Ano Autor (Técnica) 
1990 Shaler & Mellor 
1991 Coad & Yourdon (OOAD – Object-oriented Analysis and Design) 
1993 Grady Booch (Booch Method) 
1993 Ivar Jacobson (OOSE – Object Oriented Software Engineering) 
1995 James Rumbaugh et al (OMT – Object Modeling Technique) 
1996 Wirfs-Brock (Responsability Driven Design) 
1996 Surge a UML como a melhor candidata de notações, diagramas e 
formas de representação 
 
 
UML BOOCH OMT 
OOSE 
 Diagrama de Estados 
 Diagrama de Objetos 
 (Colaboração) 
 Diagrama de Processo 
 (Desenvolvimento) 
 Diagrama de Módulos 
 (Componentes) 
 Use Case 
 Subsistemas (Package) 
 Diagrama de Interações 
 MiniEspecificação 
 Diagrama de Estados 
 Diagrama de Classes 
ivaldir 
UML 
 Linguagem Gráfica de Modelagem para: 
 Visualizar 
 Especificar 
 Construir 
 Documentar 
 Comunicar 
 
 É independente de linguagens de programação 
Mais detalhes, acesse: www.uml.org 
 
 
ivaldir 
Notação UML 
 Principais autores : Grady Booch, James 
Rumbaugh, Ivar Jacobson 
 
 Notação da UML é uma união das diversas 
notações preexistentes com alguns elementos 
removidos e outros adicionados com o objetivo de 
torna-la mais expressiva. 
ivaldir 
Principais Diagramas 
Caso de Uso 
Classes 
Objetos 
Sequencia 
Colaboração 
Estados 
Atividades 
Componentes 
Pacotes 
 Visões de um sistema 
 Um sistema complexo pode ser examinado a partir de 
diversas perspectivas. 
 
 Autores da UML definem 5 visões: 
 Visão de Casos de uso: Visão externa do sistema que define 
a interação entre o sistema e agentes externos. 
 Visão de Projeto: Caracterísiticas estruturais e 
comportamentais do sistema. 
 Visão de Implementação: gerenciamento de versões 
construídas pelo agrupamento de módulos e subsistemas. 
 Visão de Implantação: Distribuição física do sistema. 
 Visão de Processo: Caracterísiticas de concorrência, 
sincronização e desempenho do sistema. 
UML – Linguagem de Modelagem 
Unificada 
Definição 
 Um caso de uso representa uma possível utilização do sistema por um 
ator, que pode ser uma pessoa, dispositivo físico, mecanismo ou 
subsistema que interage com o sistema alvo, utilizando algum de seus 
serviços.. 
 Exemplos de atores: 
 Funcionário de um banco. 
 Sensor de fumaça 
 Subsistema de autorização de crédito 
Definição 
 Um caso de uso é um documento textual que narra a interação entre o 
sistema e os atores envolvidos, para atingir um ou mais objetivos. 
 São também chamados de histórias de uso. 
 Os casos de uso dependem de que se tenha um entendimento ao menos 
parcial dos requisitos do sistema. 
 Deve estar relacionado a um processo bem definido, com começo, meio e 
fim. 
Casos de Uso 
Exemplos: 
 Emprestar livros 
 Vender produtos 
 Incluir ordem de serviço 
Casos de Uso 
 Muitas vezes é utilizado como um contrato entre desenvolvedor e cliente. 
 Pode ser feito com base no documento de requisitos, ou pode ser feito 
como forma de captar os requisitos, para depois escrever o documento de 
requisitos. 
Como identificar os atores? 
 Observar atentamente quem são os atores que supostamente serão os 
responsáveis, direta ou indiretamente, pela interação com o sistema. 
 Ator principal: interagem diretamente com o sistema computacional. 
 Ator secundário: interage com outros atores. 
Como identificar os atores? 
 Exemplo: 
 Ao emprestar um livro, o Atendente é quem opera o computador e 
realiza a transação, portanto é o ator principal. 
 Já o Leitor, interage com o atendente, sendo um ator secundário. 
Como identificar os casos de uso? 
 Analisar cada requisito do sistema em busca dos grandes eventos que 
ocorrem no mundo real e que dão origem a uma interação entre um ator e 
o sistema. 
Como identificar os casos de uso? 
 Exemplo: Biblioteca 
 R1. Para usar os serviços de uma biblioteca, os leitores deverão estar 
registrados e possuir um cartão com número de identificação e foto. 
 R2. O sistema deve permitir que um leitor apto empreste um ou mais livros, 
por um período de tempo que varia de 1 semana a 6 meses, dependendo 
do tipo de leitor (1 semana para estudante de graduação, 15 dias para 
estudantes de pós-graduação e 6 meses para docentes). 
Como identificar os casos de uso? 
 R3. O leitor está apto a emprestar livros se não possuir em seu poder livros 
com data de devolução vencida (menor do que a data atual) e desde que o 
número de livros emprestados não ultrapasse o número máximo permitido, 
que depende do tipo de leitor (6 livros para estudantes de graduação, 10 
livros para estudantes de pós-graduação e 15 livros para docentes). 
Como identificar os casos de uso? 
 De acordo com esses 3 requisitos, dois casos de uso candidatos são: 
 Emprestar Livro 
 Incluir Leitor 
 Um requisito pode referir-se a mais de um caso de uso. Um caso de uso 
pode referir-se a mais de um requisito. 
Requisitos X Casos de Uso 
Requisitos Casos de Uso 
R1, R2, R3 Emprestar livro 
Um leitor empresta um ou mais livros por um período 
de tempo que depende do tipo de leitor. 
R1, R3, R4 Devolver Livro 
Um leitor devolve um livro que estava em seu poder, 
tornando-o novamente disponível para empréstimo. 
Notação UML - Atores 
O ator é representado por um identificador com letra inicial maiúscula e por 
um “homem palito”, embora os atores possam ser pessoas, sistemas de 
computadores e dispositivos elétricos e mecânicos. 
 
 Leitor 
Notação UML – Casos de Uso 
Emprestar livro 
Emprestar Livro 
Notação UML para Diagramas de Casos 
de Uso 
Casos de Usos são narrativas em texto, amplamente utilizados para descobrir e 
registrar requisitos. 
 
Exemplo: 
Informalmente, casos de uso são narrativas em texto de algum ator usando um 
sistema para atingir objetivos. 
 
Processar Venda: um cliente chega em um ponto de pagamento com itens 
que deseja adquirir. O caixa usa o sistema PDV para registrar cada item 
comprado. O Sistema apresenta um total parcial e detalhes de linhas de item. 
O cliente entra os dados sobre o pagamento, que são validados e, em seguida, 
registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe um 
recibo do sistema e sai com itens comprados. 
Caso de Uso 
O que são Atores? 
Ator é algo com comportamento, tal como uma pessoa( identificada por seu 
papel) um sistema de computador ou um caixa e etc. 
 
 
Ator é algo que interage com o sistema, mas sobre o qual não se tem controle. 
Ele está fora da influência do sistema. Os atores têm um papel externo e são 
quem iniciam (e quem respondem) aos casos de uso. Por exemplo: fazem o 
pedido num restaurante, comem, bebem ou pagam. 
 
Tipicamente, um Ator representa um papel que um ser humano, um outro 
processo, um outro sistema, ou até um dispositivo de hardware, desempenha ao 
interagir com o sistema. 
O que são Cenários? 
É uma seqüência específica de ações e interações entre atores e o sistema; 
É também chamado de instância de caso de uso. È uma história particular de 
uso de um sistema ou um caminho através do caso de uso; 
 
Exemplo: 
 
O cenário de efetuar com sucesso a compra de itens em dinheiro, ou cenário 
de não consumara compra de itens por causa da recusa de uma autorização 
de crédito. 
 
Em termos informais , então, um caso de uso é uma coleção de cenários 
relacionados de sucesso e fracasso, que descrevem um ator usando um 
sistema como meio para atingir um objetivo. 
 
 
Introdução – Casos de Uso 
 Os casos de uso: 
 Descrevem como os usuários interagem com o sistema 
(as funcionalidades do sistema) 
 Facilitam a organização dos requisitos de um sistema 
 Dão uma visão externa do sistema 
 O conjunto de casos de uso deve ser capaz de comunicar a 
funcionalidade e o comportamento do sistema para o cliente 
 Descrevem o que o sistema faz, mas NÃO especificam como 
isso deve ser feito 
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Elementos do diagrama: 
 
 Atores 
 Casos de uso 
 Relacionamentos 
 Associação 
 Generalização 
 Dependência: Extensão e Inclusão 
 
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Elementos do diagrama 
 
 Atores 
 Casos de uso 
 Relacionamentos 
 Associação 
 Generalização 
 Dependência: Extensão e Inclusão 
 
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Atores 
 Representam os papéis desempenhados por 
elementos externos ao sistema 
 Elementos que interagem com o sistema 
 
 
Notação: 
 
Secretária
(from Use Case View)
Diretor
(from Use Case View)
Sistema de 
Relatórios
(from Use Case View)
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Elementos do diagrama 
 
 Atores 
 Casos de uso 
 Relacionamentos 
 Associação 
 Generalização 
 Dependência: Extensão e Inclusão (ESSE 
CONCEITO SERÁ DETALHADO NAS PRÓXIMAS 
AULAS) 
 
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Relacionamento de associação 
 Indica que há uma interação (comunicação) entre 
um caso de uso e um ator 
 Um ator pode se comunicar com vários casos de uso 
 
Dicas: 
 NÃO use setas nas associações 
 
Notação: 
 Ator
(from Use Case View)
Caso de Uso
(from Use Case View)
interação
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Elementos do diagrama 
 
 Atores 
 Casos de uso 
 Relacionamentos 
 Associação 
 Generalização 
 Dependência: Extensão e Inclusão 
 
Fonte: www.les.inf.puc-rio.br 
Elementos – Diagrama de 
Casos de Uso 
 Relacionamento de generalização 
Generalização de atores 
 Quando dois ou mais atores podem se comunicar 
com o mesmo conjunto de casos de uso 
 Um filho (herdeiro) pode se comunicar com todos 
os casos de uso que seu pai se comunica. 
 
Dica: coloque os herdeiros embaixo 
 
Notação: 
 
Fonte: www.les.inf.puc-rio.br 
Descrição de Casos de Uso 
 Descrição Informal 
 Contém o nome do caso de uso e 
uma descrição textual de sua funcionalidade 
 
 
 
Fonte: www.les.inf.puc-rio.br 
Descrição de Casos de Uso 
 Descrição Típica 
 Contém: 
 Identificação do ator que iniciou o caso de uso 
 Pré-requisitos (se houver) do caso de uso 
 Descrição textual do: 
 Fluxo normal 
 Fluxos alternativos (se houver) 
 
Fonte: www.les.inf.puc-rio.br 
Seção do caso de uso 
Código 
Caso de uso 
Ator principal 
Pré-condições 
Cenário principal 
Cenários alternativos 
Requisitos especiais 
Pós-condições 
Exemplo da forma “completa” 
( exemplo 1) 
 Exemplo 1: 
Fonte: www.les.inf.puc-rio.br 
Descrição de Casos de Uso 
Descrição Detalhada/completa ( exemplo 1) 
 Contém: 
 Código/Nome 
 Descrição 
 Atores 
 Pré-condições 
 Pós-condições 
 Fluxo básico 
 Fluxos alternativos 
 Fluxos de exceção 
 Estruturas de dados 
 Regras de negócio 
 Observações 
Exemplo 2: 
Exemplo 2 (cont.): 
Exemplo 2 (cont.) 
 © LES/PUC-Rio 
Ferramentas de Modelagem 
 Jude 
 Together 
 IBM Rational Rose 
ivaldir 
Modelagem de 
Sistemas 
Introdução a UML