SlideShare una empresa de Scribd logo
1 de 40
Descargar para leer sin conexión
Modelagem de Sistemas de
Informação
Aula 07 – Introdução a UML
Unified Modeling Language
Livros
A linguagem UML
• UML (Unified Modeling Language) – Linguagem de Modelagem
Unificada
• É uma linguagem de modelagem (visual), não uma linguagem de
programação
• É uma linguagem de modelagem não proprietária
• Permite a utilização de diagramas padronizados para especificação e
visualização de um sistema
De onde surgiu?
• Da união de três metodologias de modelagem:
• Método de Booch, de Grady Booch;
• Método OMT (Object Modeling Technique) de Ivar Jacobson;
• Método OOSE (Object Oriented Software Engineering) de James Rumbaugh.
• Os “três amigos”.
UML
“Fundadores” da UML
De onde surgiu?
• A primeira versão foi lançada em 1996
• Em 1997 a UML foi adotada pela a OMG (Object Management Group
– Grupo de gerenciamento de Objetos) como linguagem padrão de
modelagem.
O que é modelagem?
• Atividade de construir modelos que expliquem as características ou
comportamentos de um sistema.
• A UML pode ser usada com todos os processos durante o ciclo de
desenvolvimento do projeto
• Análise de requisitos;
• Análise de sistema;
• Design;
• Programação e
• Testes.
Por que usar UML?
• Desenvolver o modelo de uma aplicação antes de construí-la, é tão
essencial quanto ter uma planta para a construção de uma casa.
• Analisar o projeto sobre vários aspectos;
• Diminui a possibilidade de erros.
• Bons modelos são essenciais para a comunicação entre os times de
projetos e para assegurar a beleza arquitetural.
• Facilita a programação;
• Todo o time entende a modelagem, facilitando assim a manutenção.
• Ter um rigoroso padrão de linguagem de modelagem é um fator essencial
para o sucesso de um projeto.
• Sistemas são dinâmicos;
E onde fica a modelagem?
Análise de requisitos Modelagem
ImplementaçãoTestes
Manutenção
Modelos
• Tipos de Modelagens
• Estrutural
• Diagrama de Classes
• Diagramas de Objetos
• Diagrama de Caso de Uso
• Diagrama de Componentes
• Comportamental
• Diagrama de Estados
• Diagrama de Atividades
• Diagrama de Colaboração
• Diagrama de Sequência
Modelos
Ferramentas CASE
• Auxiliam na construção e gerenciamento de
diagramas UML
• Enterprise Architect
• Rational Rose
• MS Visio
• PowerDesign
• ArgoUML
• Jude
• Poseidon
Diagrama de Casos de Uso
Diagrama de Casos de Uso
• Segundo Ivar Jacobson, podemos dizer que um caso de uso é um
"documento narrativo que descreve a sequência de eventos de um
ator que usa um sistema para completar um processo“.
• Um caso de uso representa uma unidade discreta da interação entre
um usuário (humano ou máquina) e o sistema.
Diagrama de Casos de Uso
• Dentre todos os diagramas da UML, é o mais abstrato e, portanto o
mais flexível e informal.
• Geralmente é modelado no início da modelagem do sistema, ainda
nas etapas de levantamento e análise de requisitos.
Diagrama de Casos de Uso
• Tem por objetivo apresentar uma visão externa geral das funções e
serviços que o sistema deverá oferecer ao usuário.
• Sem se preocupar como essas funções serão implementadas.
• Um caso de uso descreve, as operações que o sistema deve cumprir
para cada usuário.
• Irá existir um caso de uso para casa tarefa que o sistema deve executar.
Componentes do Diagrama de Casos
de Uso
• O Diagrama de Casos de Uso concentra-se em dois itens principais:
• Atores
• Casos de Uso
Atores
• Casos de Uso descrevem interações entre o sistema e os atores.
• Os atores representam os papéis desempenhados pelos diversos
usuários que poderão de alguma forma interagir com o sistema.
Atores
• Atores são representados por símbolos de “bonecos magros”,
contendo uma breve descrição logo abaixo do seu símbolo que
identifica qual o papel que o ator em questão assume dentro do
diagrama.
• Exemplo:
Cliente
Casos de Uso
• Os Casos de Uso referem-se aos serviços, tarefas ou funções que
podem ser utilizadas de alguma maneira pelos usuários do sistema.
Por exemplo:
• Cadastrar uma venda;
• Solicitar um saque de uma conta bancária;
Representação dos Casos de Uso
• Os casos de uso são representados por elipses contendo dentro de si
um texto descrevendo a que serviço o Caso de Uso se refere.
Cadastro de Clientes
Documentação de Casos de Uso
• Costuma descrever por meio de uma linguagem bastante simples, a
função em linhas gerais do Caso de Uso.
• Quais atores interagem com o mesmo;
• Quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso
de Uso execute sua função;
• Quais parâmetros devem ser fornecidos e quais restrições e validações o Caso
de Uso deve possuir.
Documentação de Casos de Uso
• Não existe um formato específico.
• Descrição passo a passo;
• Através de tabelas;
• Pseudo-código;
• Até mesmo através de uma linguagem de programação, mesmo que fuja
bastante do objetivo principal do Diagrama de Casos de Uso.
Nome do Caso de Uso Abertura de Conta
Ator Principal Cliente
Atores Secundários Funcionário
Resumo Este caso de Uso, descreve as etapas percorridas
por um cliente para abrir uma conta corrente.
Pré-Condições O pedido do cliente precisa ser aprovado
Pré-Condições É necessário um depósito inicial
Ações do Ator Ações do Sistema
1. Solicitar a abertura da conta
2. Consultar cliente por seu CPF
3. Se for necessário Gravar ou atualizar o cadastro
do Cliente
4. Avaliar o pedido
5. Aprovar ou Reprovar o pedido
6. Escolher uma Senha para a conta
7. Abrir a conta
8. Informar o valor do depósito
9.Registrar o depósito
10. Solicitar o cartão da compra
Retirar dinheiro no Caixa Eletrônico
• O Cliente introduz o cartão no caixa eletrônico;
• O Sistema disponibiliza várias opções;
• O Cliente aperta o botão saque;
• O Cliente escolhe o tipo de conta:
• Poupança;
• Conta Corrente.
• O Cliente entra com o valor do saque;
• Em seguida o cliente informa a senha;
• O sistema verifica a senha e saldo em seu Banco de dados;
• O Caixa eletrônico libera o dinheiro para o usuário.
Associações
• As associações representam as interações ou relacionamentos entre:
• Os Atores que fazem parte do Diagrama;
• Os Atores e os Casos de Uso e
• Os Casos de Uso com outros Casos de Uso.
• Os relacionamentos entre os Casos de Uso, recebem um nome
especial.
• Inclusão;
• Extensão e
• Generalização.
Associações
• Uma associação entre um Caso de Uso e um Ator demonstra que o
Ator utiliza-se de alguma maneira, da função do sistema representada
pelo Caso de Uso,
• Seja requisitando a execução daquela função;
• Seja recebendo o resultado produzido por ela a pedido de outro Ator.
Associações
• A Associação entre um Ator e um Caso de Uso é representada por
uma reta ligando o Ator ao Caso de Uso
• pode ocorrer nas extremidades da reta o uso de setas, indicando a
navegabilidade da Associação, demonstrando assim o sentido em que
as informações trafegam.
• Quando a informação é transmitida nos dois sentidos, a reta passa a não
possuir setas.
Associações
Cliente
Consulta de Veículos
Verifica veículos
Vistoriador
Corretor
Especialização / Generalização
• Acontece quando dois ou mais Casos de uso possui
características semelhantes, apresentando pequenas
diferenças entre si.
• Dessa forma é importante definir um Caso de Uso
Geral que descreve as características compartilhadas
por todos os Casos de Uso em questão e então
relacioná-los.
Exemplos de Especialização / Generalização
Inclusão
• Costuma ser utilizada quando existe um serviço, situação ou rotina
comum a mais de um Caso de Uso.
• Os relacionamentos de Inclusão indicam uma obrigatoriedade, ou
seja, quando um determinado Caso de Uso possui um
relacionamento de Inclusão com outro, a execução do primeiro obriga
também a execução do segundo.
Inclusão
• Uma Associação de Inclusão é representada por uma reta tracejada
com uma seta em uma das extremidades que aponta para o Caso de
Uso incluído.
• Possuir a expressão “include”, entre dois sinais de menor (<) e dois sinais de
maior (>).
Inclusão
Extensão
• Descreve cenários opcionais de um Caso de Uso.
• Os Casos de uso estendidos descrevem cenários que somente acontecerão
em uma situação específica, se uma determinada situação for satisfeita.
• Dessa forma as Associações de Extensão necessita de um teste determinar se
o Caso de Uso estendido será executado ou não.
Extensão
• Em sua representação gráfica, é muito semelhante às associações de
Inclusão.
• Possuir a expressão “extend”, entre dois sinais de menor (<) e dois sinais de
maior (>).
Extensão
Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07

Más contenido relacionado

La actualidad más candente

Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
elliando dias
 
Engenharia Requisitos
Engenharia RequisitosEngenharia Requisitos
Engenharia Requisitos
elliando dias
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
Luís Fernando Richter
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
Glauber Aquino
 

La actualidad más candente (20)

Análise de sistemas análise de requisitos
Análise de sistemas   análise de requisitosAnálise de sistemas   análise de requisitos
Análise de sistemas análise de requisitos
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de Requisitos
 
Aula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de RequisitosAula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de Requisitos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Engenharia Requisitos
Engenharia RequisitosEngenharia Requisitos
Engenharia Requisitos
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Modelagem de Sistemas de Informação 03
Modelagem de Sistemas de Informação 03Modelagem de Sistemas de Informação 03
Modelagem de Sistemas de Informação 03
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
 
Analise sistemas 03
Analise sistemas 03Analise sistemas 03
Analise sistemas 03
 
Engenharia de software i 3 - processos de engenharia de requisitos
Engenharia de software i   3 - processos de engenharia de requisitosEngenharia de software i   3 - processos de engenharia de requisitos
Engenharia de software i 3 - processos de engenharia de requisitos
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 

Similar a Modelagem de Sistemas de Informação 07

Diagramas de casos de uso
Diagramas de casos de usoDiagramas de casos de uso
Diagramas de casos de uso
Sergio Chaves
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
Frank Lira
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
Frank Lira
 

Similar a Modelagem de Sistemas de Informação 07 (20)

UML
UMLUML
UML
 
Parte6 casos de uso
Parte6   casos de usoParte6   casos de uso
Parte6 casos de uso
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
 
Aula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de ProjetoAula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de Projeto
 
REA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLREA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UML
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdfAula 05 - Caso de Uso.pdf
Aula 05 - Caso de Uso.pdf
 
Aula 05 .pdf
Aula 05 .pdfAula 05 .pdf
Aula 05 .pdf
 
UML1.pdf
UML1.pdfUML1.pdf
UML1.pdf
 
Use Case Diagram.pptx
Use Case Diagram.pptxUse Case Diagram.pptx
Use Case Diagram.pptx
 
Aps caso uso
Aps caso usoAps caso uso
Aps caso uso
 
4 casos-de-uso
4 casos-de-uso4 casos-de-uso
4 casos-de-uso
 
Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1
 
aula02_uml.pdf
aula02_uml.pdfaula02_uml.pdf
aula02_uml.pdf
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
 
Aula 6 -_casos_de_uso
Aula 6 -_casos_de_usoAula 6 -_casos_de_uso
Aula 6 -_casos_de_uso
 
Diagramas de casos de uso
Diagramas de casos de usoDiagramas de casos de uso
Diagramas de casos de uso
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
 

Más de Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT

Más de Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT (20)

Curso DNA Básico Thetahealing
Curso DNA Básico ThetahealingCurso DNA Básico Thetahealing
Curso DNA Básico Thetahealing
 
Atendimento ThetaHealing
Atendimento ThetaHealingAtendimento ThetaHealing
Atendimento ThetaHealing
 
Modelagem de Sistemas de Informação 13 maquina_estados
Modelagem de Sistemas de Informação 13 maquina_estadosModelagem de Sistemas de Informação 13 maquina_estados
Modelagem de Sistemas de Informação 13 maquina_estados
 
Análise de Sistemas Orientado a Objetos - 11 - maquina_estados
Análise de Sistemas Orientado a Objetos - 11 - maquina_estadosAnálise de Sistemas Orientado a Objetos - 11 - maquina_estados
Análise de Sistemas Orientado a Objetos - 11 - maquina_estados
 
Modelagem de Sistemas de Informação 12 pacotes
Modelagem de Sistemas de Informação 12 pacotesModelagem de Sistemas de Informação 12 pacotes
Modelagem de Sistemas de Informação 12 pacotes
 
Análise de Sistemas Orientado a Objetos - 10 - pacotes
Análise de Sistemas Orientado a Objetos -  10 - pacotesAnálise de Sistemas Orientado a Objetos -  10 - pacotes
Análise de Sistemas Orientado a Objetos - 10 - pacotes
 
Modelagem de Sistemas de Informação 11 Colaboração
Modelagem de Sistemas de Informação 11 ColaboraçãoModelagem de Sistemas de Informação 11 Colaboração
Modelagem de Sistemas de Informação 11 Colaboração
 
Análise de Sistemas Orientado a Objetos - 09 - colaboracao
Análise de Sistemas Orientado a Objetos - 09 - colaboracaoAnálise de Sistemas Orientado a Objetos - 09 - colaboracao
Análise de Sistemas Orientado a Objetos - 09 - colaboracao
 
Modelagem de Sistemas de Informação 10 Diagrama de Sequência
Modelagem de Sistemas de Informação 10 Diagrama de SequênciaModelagem de Sistemas de Informação 10 Diagrama de Sequência
Modelagem de Sistemas de Informação 10 Diagrama de Sequência
 
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de SequênciaAnálise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
Análise de Sistemas Orientado a Objetos - 08 - Diagrama de Sequência
 
Análise de Sistemas Orientado a Objetos - 07 ISO 9126
Análise de Sistemas Orientado a Objetos - 07 ISO 9126Análise de Sistemas Orientado a Objetos - 07 ISO 9126
Análise de Sistemas Orientado a Objetos - 07 ISO 9126
 
Modelagem de Sistemas de Informação 09 ISO 9126
Modelagem de Sistemas de Informação 09 ISO 9126Modelagem de Sistemas de Informação 09 ISO 9126
Modelagem de Sistemas de Informação 09 ISO 9126
 
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de ClassesModelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
 
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de ClassesAnálise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
Análise de Sistemas Orientado a Objetos - 06 - Diagrama de Classes
 
Modelagem de Sistemas de Informação 06
Modelagem de Sistemas de Informação 06Modelagem de Sistemas de Informação 06
Modelagem de Sistemas de Informação 06
 
Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05Modelagem de Sistemas de Informação 05
Modelagem de Sistemas de Informação 05
 
Modelagem de Sistema de Informação 02
Modelagem de Sistema de Informação 02Modelagem de Sistema de Informação 02
Modelagem de Sistema de Informação 02
 
Modelagem de Sistemas de Informação 01
Modelagem de Sistemas de Informação 01Modelagem de Sistemas de Informação 01
Modelagem de Sistemas de Informação 01
 
Análise de Sistemas Orientado a Objetos - 04
Análise de Sistemas Orientado a Objetos - 04Análise de Sistemas Orientado a Objetos - 04
Análise de Sistemas Orientado a Objetos - 04
 
Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03
 

Último

Assessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdfAssessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdf
Natalia Granato
 

Último (6)

ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docxATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
Padrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemploPadrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemplo
 
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docxATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
 
Assessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdfAssessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdf
 
Boas práticas de programação com Object Calisthenics
Boas práticas de programação com Object CalisthenicsBoas práticas de programação com Object Calisthenics
Boas práticas de programação com Object Calisthenics
 

Modelagem de Sistemas de Informação 07

  • 1. Modelagem de Sistemas de Informação Aula 07 – Introdução a UML Unified Modeling Language
  • 3. A linguagem UML • UML (Unified Modeling Language) – Linguagem de Modelagem Unificada • É uma linguagem de modelagem (visual), não uma linguagem de programação • É uma linguagem de modelagem não proprietária • Permite a utilização de diagramas padronizados para especificação e visualização de um sistema
  • 4. De onde surgiu? • Da união de três metodologias de modelagem: • Método de Booch, de Grady Booch; • Método OMT (Object Modeling Technique) de Ivar Jacobson; • Método OOSE (Object Oriented Software Engineering) de James Rumbaugh. • Os “três amigos”.
  • 6. De onde surgiu? • A primeira versão foi lançada em 1996 • Em 1997 a UML foi adotada pela a OMG (Object Management Group – Grupo de gerenciamento de Objetos) como linguagem padrão de modelagem.
  • 7. O que é modelagem? • Atividade de construir modelos que expliquem as características ou comportamentos de um sistema. • A UML pode ser usada com todos os processos durante o ciclo de desenvolvimento do projeto • Análise de requisitos; • Análise de sistema; • Design; • Programação e • Testes.
  • 8. Por que usar UML? • Desenvolver o modelo de uma aplicação antes de construí-la, é tão essencial quanto ter uma planta para a construção de uma casa. • Analisar o projeto sobre vários aspectos; • Diminui a possibilidade de erros. • Bons modelos são essenciais para a comunicação entre os times de projetos e para assegurar a beleza arquitetural. • Facilita a programação; • Todo o time entende a modelagem, facilitando assim a manutenção. • Ter um rigoroso padrão de linguagem de modelagem é um fator essencial para o sucesso de um projeto. • Sistemas são dinâmicos;
  • 9. E onde fica a modelagem? Análise de requisitos Modelagem ImplementaçãoTestes Manutenção
  • 10. Modelos • Tipos de Modelagens • Estrutural • Diagrama de Classes • Diagramas de Objetos • Diagrama de Caso de Uso • Diagrama de Componentes • Comportamental • Diagrama de Estados • Diagrama de Atividades • Diagrama de Colaboração • Diagrama de Sequência
  • 12. Ferramentas CASE • Auxiliam na construção e gerenciamento de diagramas UML • Enterprise Architect • Rational Rose • MS Visio • PowerDesign • ArgoUML • Jude • Poseidon
  • 14. Diagrama de Casos de Uso • Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo“. • Um caso de uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema.
  • 15. Diagrama de Casos de Uso • Dentre todos os diagramas da UML, é o mais abstrato e, portanto o mais flexível e informal. • Geralmente é modelado no início da modelagem do sistema, ainda nas etapas de levantamento e análise de requisitos.
  • 16. Diagrama de Casos de Uso • Tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer ao usuário. • Sem se preocupar como essas funções serão implementadas. • Um caso de uso descreve, as operações que o sistema deve cumprir para cada usuário. • Irá existir um caso de uso para casa tarefa que o sistema deve executar.
  • 17. Componentes do Diagrama de Casos de Uso • O Diagrama de Casos de Uso concentra-se em dois itens principais: • Atores • Casos de Uso
  • 18. Atores • Casos de Uso descrevem interações entre o sistema e os atores. • Os atores representam os papéis desempenhados pelos diversos usuários que poderão de alguma forma interagir com o sistema.
  • 19. Atores • Atores são representados por símbolos de “bonecos magros”, contendo uma breve descrição logo abaixo do seu símbolo que identifica qual o papel que o ator em questão assume dentro do diagrama. • Exemplo: Cliente
  • 20. Casos de Uso • Os Casos de Uso referem-se aos serviços, tarefas ou funções que podem ser utilizadas de alguma maneira pelos usuários do sistema. Por exemplo: • Cadastrar uma venda; • Solicitar um saque de uma conta bancária;
  • 21. Representação dos Casos de Uso • Os casos de uso são representados por elipses contendo dentro de si um texto descrevendo a que serviço o Caso de Uso se refere. Cadastro de Clientes
  • 22. Documentação de Casos de Uso • Costuma descrever por meio de uma linguagem bastante simples, a função em linhas gerais do Caso de Uso. • Quais atores interagem com o mesmo; • Quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função; • Quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir.
  • 23. Documentação de Casos de Uso • Não existe um formato específico. • Descrição passo a passo; • Através de tabelas; • Pseudo-código; • Até mesmo através de uma linguagem de programação, mesmo que fuja bastante do objetivo principal do Diagrama de Casos de Uso.
  • 24. Nome do Caso de Uso Abertura de Conta Ator Principal Cliente Atores Secundários Funcionário Resumo Este caso de Uso, descreve as etapas percorridas por um cliente para abrir uma conta corrente. Pré-Condições O pedido do cliente precisa ser aprovado Pré-Condições É necessário um depósito inicial Ações do Ator Ações do Sistema 1. Solicitar a abertura da conta 2. Consultar cliente por seu CPF 3. Se for necessário Gravar ou atualizar o cadastro do Cliente 4. Avaliar o pedido 5. Aprovar ou Reprovar o pedido 6. Escolher uma Senha para a conta 7. Abrir a conta 8. Informar o valor do depósito 9.Registrar o depósito 10. Solicitar o cartão da compra
  • 25. Retirar dinheiro no Caixa Eletrônico • O Cliente introduz o cartão no caixa eletrônico; • O Sistema disponibiliza várias opções; • O Cliente aperta o botão saque; • O Cliente escolhe o tipo de conta: • Poupança; • Conta Corrente. • O Cliente entra com o valor do saque; • Em seguida o cliente informa a senha; • O sistema verifica a senha e saldo em seu Banco de dados; • O Caixa eletrônico libera o dinheiro para o usuário.
  • 26. Associações • As associações representam as interações ou relacionamentos entre: • Os Atores que fazem parte do Diagrama; • Os Atores e os Casos de Uso e • Os Casos de Uso com outros Casos de Uso. • Os relacionamentos entre os Casos de Uso, recebem um nome especial. • Inclusão; • Extensão e • Generalização.
  • 27. Associações • Uma associação entre um Caso de Uso e um Ator demonstra que o Ator utiliza-se de alguma maneira, da função do sistema representada pelo Caso de Uso, • Seja requisitando a execução daquela função; • Seja recebendo o resultado produzido por ela a pedido de outro Ator.
  • 28. Associações • A Associação entre um Ator e um Caso de Uso é representada por uma reta ligando o Ator ao Caso de Uso • pode ocorrer nas extremidades da reta o uso de setas, indicando a navegabilidade da Associação, demonstrando assim o sentido em que as informações trafegam. • Quando a informação é transmitida nos dois sentidos, a reta passa a não possuir setas.
  • 30. Especialização / Generalização • Acontece quando dois ou mais Casos de uso possui características semelhantes, apresentando pequenas diferenças entre si. • Dessa forma é importante definir um Caso de Uso Geral que descreve as características compartilhadas por todos os Casos de Uso em questão e então relacioná-los.
  • 31. Exemplos de Especialização / Generalização
  • 32. Inclusão • Costuma ser utilizada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso. • Os relacionamentos de Inclusão indicam uma obrigatoriedade, ou seja, quando um determinado Caso de Uso possui um relacionamento de Inclusão com outro, a execução do primeiro obriga também a execução do segundo.
  • 33. Inclusão • Uma Associação de Inclusão é representada por uma reta tracejada com uma seta em uma das extremidades que aponta para o Caso de Uso incluído. • Possuir a expressão “include”, entre dois sinais de menor (<) e dois sinais de maior (>).
  • 35. Extensão • Descreve cenários opcionais de um Caso de Uso. • Os Casos de uso estendidos descrevem cenários que somente acontecerão em uma situação específica, se uma determinada situação for satisfeita. • Dessa forma as Associações de Extensão necessita de um teste determinar se o Caso de Uso estendido será executado ou não.
  • 36. Extensão • Em sua representação gráfica, é muito semelhante às associações de Inclusão. • Possuir a expressão “extend”, entre dois sinais de menor (<) e dois sinais de maior (>).