Post on 06-Nov-2018
UMLUNIFIED MODELING LANGUAGE
LINGUAGEM DE MODELAGEM UNIFICADA
UML - Introdução
• Não é uma linguagem de programação
• É uma linguagem de modelagem e projeto
• É uma linguagem padrão para modelagem orientada a objetos.
• Não é um processo de desenvolvimento de software
UML – Histórico
• Surgiu da união de 3 métodos de modelagem• Método de Booch
• Método OMT (Object Modeling Technique) de Jacobson
• Método OOSE (Object-Oriented Software Engineering) de Raumbaugh
• 1995 – União do método de Booch com o OMT
• 1996 – Os três se uniram
• 1997 – A OMG (Object Management Group) adotou o UML como linguagem padrão
• 2005 – Lançada a versão 2.0 da linguagem
UML - Documentação
• www.omg.org
• www.uml.org
UML - Objetivos
• Modelar sistemas usando os conceitos da programação orientada a objetos.
• Construir uma ligação dos métodos conceituais à prática e execução de um projeto.
• Criar uma linguagem de modelagem utilizável tanto pelo homem quanto pela máquina.
UML – Por que modelar software
Qual construção você prefere?
UML – Por que modelar software
• A utilização da UML pode fazer a diferença entre o barraco e o arranha-céus.
• Você quer um sistema barraco ou um sistema arranha-céus.
• A UML é comumente aceita como a documentação oficial de um projeto.
UML - Usos
• É utilizada nos mais diversos tipos de sistemas
• A utilidade mais comum é criar modelos de sistemas de softwares
• Consegue traduzir qualquer característica de um sistema em seus diagramas
UML - Fases de desenvolvimento
Existem 5 fases no desenvolvimento do software
• Análise de requisitos
• Análise
• Design (Projeto)
• Programação
• Testes
Análise de requisitos
• Capturar as intenções e necessidades dos usuários
• Elaboração dos casos de uso (use cases)• Listar as entidades externas - atores externos, tudo aquilo que vai interagir
com o sistema• Cada caso de uso modelado é definido por um texto que especifica os
requerimentos do ator externo que o utilizará
• O conjunto destas informações determinarão as funcionalidades do sistemas. Nesta fase não é necessário se preocupar em como implementar estas funcionalidades (ex: qual linguagem utlizar)
• DIAGRAMA DE CASOS DE USO
Análise de requisitos
• determina "o que" o software deve fazer e se é realmente possível desenvolver o software solicitado
• entrevistas para entender o processo a ser informatizado
• nesta fase a comunicação é muito importante• REQUISITOS FUNCIONAIS - funcionalidades do software
• REQUISITOS NÃO FUNCIONAIS - restrições, condições, consistência, validações
• Ex: Um sistema de banco• Abrir nova conta corrente -> requisito funcional
• Determinar que somente maiores de 18 anos podem abrir contas - requisitos não funcionais
Análise
• Explica as primeiras abstrações e detalhamentos (classes e objetos)
• Modelagem das classes
• Conexão e relacionamento entre as classes
DIAGRAMA DE CLASSES
Design (projeto)
• O resultado da análise é detalhado em soluções técnicas• Interface do usuário
• Interface de periféricos
• acesso ao banco de dados
• comunicação com outros sistemas
• outros
• As classes das funções modeladas na fase anterior se juntam com esta nova infraestrutura.
Design (projeto)
• PROTOTIPAÇÃO• A etapa de análise de requisitos deve obrigatoriamente produzir um protótipo
que pode ser desenvolvido em ferramentas RAD
• Mostrar para o cliente como o software funcionará
Design (projeto)
• Prazos e Custos• Difíceis de estabelecer
• Geralmente se adiciona alguns meses ao prazo de conclusão do projeto
Programação
• As classes da fase de Design, são convertidas na linguagem de programação escolhida
• Os modelos criados são convertidos em códigos
Programação
• Procura estabelecer "como" o sistema fará o que foi determinado na fase de análise
• Selecionar a linguagem de programação
• o SGBD a ser utilizado
• A Interface final
Testes
• Testes unitários (executado pelo desenvolvedor)• Cada classe, métodos e atributos estão funcionando de acordo com o que foi
projetado anteriormente
• Testes de integração• Verificar se as classes e componentes estão cooperando como especificado
nos modelos do projeto
• Testes de aprovação• Teste feito pelo usuário final para verificar se o sistema está funcionando de
acordo com os requisitos levantados no início do projeto
Desenvolvendo uma UML
• Visões • 5 tipos de visões• Mostram os diferentes aspectos do sistema modelado
• Modelos de elementos• Tratam os elementos do sistema como classes, objetos e estados conforme as
definições comuns da POO
• Mecanismos gerais• Notas e comentários necessários para explicar melhor o funcionamento do
sistema
• Diagramas• 13 tipos de diagramas
Visões
Visão de casos de uso
Visão de componentes
Visão lógica
Visão de organização
Visão de concorrência
Visões
• Visão de casos de uso - descreve a funcionalidade do sistema do ponto de vista de como os atores externos interagem com o sistema.
• Visão lógica - descreve como a funcionalidade do sistema que será implementada. É elaborada principalmente pelos desenvolvedores. A visão lógica observa e estuda o sistema internamente. Ela descreve e detalha a estrutura estática do sistema (classes, objetos e relacionamentos) e as colaborações dinâmicas quando os objetos enviarem informações uns para os outros.
• Visão de componentes - é uma descrição de como os módulos e suas dependências e como serão implementados. É principalmente executado por desenvolvedores e consiste nos diagramas de componentes.
• Visão de concorrência - trata de verificar o desempenho do sistema e como será implementado.
• Visão de organização - mostra a infraestrutura do sistema, servidores, redes, periféricos e como eles se conectam entre si.
Diagramas
• Diagrama casos de uso;
• Diagrama de classes;
• Diagrama de Objetos;
• Diagrama de Estados;
• Diagrama de colaboração;
• Diagrama de atividades;
• Diagrama de Componente;
• Diagrama de Execução;
Diagrama de casos de uso
• Atores
cliente
usuário
funcionárioSistemaIntegrado
Diagrama de casos de uso
• Casos de uso (Use Cases)
Abrir conta
Cadastrar
Concluir Pedido
Realizar Login
Concluir Pedido
Visualizar Carrinho
cliente
funcionário
Diagrama de Classes
Cliente
Nome: StringEndereço: StringTelefone: StringCPF: StringUsuário: StringSenha: String
InserirExcluir Editar
Produto
Nome: StringTipo: StringPart Number: Int
InserirExcluir Editar
Pedido
Cód Pedido: intCód Produto: intQuantidade: int
DIagrama de Classes
• Demonstra a estrutura estática das classes de um sistema onde estas representam os objetos que são gerenciados pela aplicação modelada.
Classes se relacionam com outras de diversas maneiras
associação (conectadas entre si)dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), generalização (uma classe é mais genérica que a outra)módulos (classes agrupadas por características similares)
DIagrama de Classes
• Ex:Cliente Site
Produto Pedido
navega
escolhe
faz
Diagrama de objetos
Cliente
Fulano de TalRua Doze555-555511999888-98fulano123456
InserirExcluir Editar
Produto
Smartphone111222333
InserirExcluir Editar
Pedido
000001002222100
Diagrama de Objetos
• Exibe os objetos que foram instanciados pelas classes do diagrama de classes
• É como se fosse o perfil do sistema em um determinado momento de sua execução
Diagrama de Objetos
• Ex:
João da Silva:Cliente ComprasMil:Site
Monitor :Produto 123456789:Pedido
Diagrama de Componentes
• Mostra o sistema pelo lado funcional
• Descreve os componentes do software e suas inter-dependências
• É a implementação da arquitetura física (código fonte) que é gerada da arquitetura lógica (classes, objetos, etc)
Diagrama de Componentes
• Ex:
Impressora
Térmica
Leitora
de
Cartões
Dispensadora
de
Notas
Controladora
de
Operaçôes
Teclado
Encriptado
Rede
Externa
Controladora
de
Operaçôes
Leitora
de
Cartões
Diagrama de Implantação
• Exibe a arquitetura física de hardware e software de um sistema
• Exibe a infraestrutura da solução do sistema• servidores,periféricos, redes, desktops.
• Exibe os sistemas operacionais, os aplicativos envolvidos, como por exemplo SQL, IIS, JBOSS e em quais servidores eles são executados.
Diagrama de Implantação
• Ex:Web Server
DataBase
Server
Application
Server
Desktop
Operator
Diagrama de Módulos
• Descreve os pacotes ou partes do sistema
• Os módulos são produzidos através do agrupamento de suas classes
• Os módulos podem possuir dependências uns dos outros
Diagrama de Módulos
Módulo
de
Consulta
Módulo
de
Cadastro
Módulo
de
Locações
Módulo
Financeiro
Módulo
de
Gerenciamento
de
Clientes
Módulo
de
Relatórios
Diagrama de Estrutura Composta
• Descrição dos relacionamentos entre os elementos
• Utilizado para descrever a
colaboração interna de classes
interfaces e componentes
para especificar uma
funcionalidade
Servidor
Aplicação Relatório
Instalação
INSTALAÇÃO
Diagrama de Estados
• Mostra todos os estados possíveis em que uma classe ou objeto podem se encontrar
• Capturam o ciclo de vida do objeto
• Notação....
Diagrama de Estados
No térreo Subindo
Descendo Estacionado
Indo para o
térreo
Chegar
Subir
Chegar no
andar
Subir
Chegar
Descer
Diagrama de Atividade
• Capturam as ações e seus resultados
• Evidenciam os métodos dos objetos
• Os estados no diagrama de atividade mudam para um próximo passo quando uma ação é executada (sem ser necessário especificar nenhum evento como no diagrama de estado)
• Exibe o fluxo sequencial das atividades e é normalmente utilizado para demonstrar as atividades executadas por uma operação específica no sistema.
Diagrama de Atividade
Imprimir (arquivo)
Desktop
CorporativoFila de Arquivos
Servidor
de ImpressãoImpressora
Ocupada
Livre
Diagrama de Sequência
• Mostra a colaboração dinâmica entre vários objetos do sistema
• Mostra a interação entre objetos em um determinado ponto da execução do sistema
• Útil para mostrar a execução simultânea de objetos do sistema mostrando a concorrência de processos
Diagrama de Sequência
Desktop
Servidor de Impressão Impressora Fila
Imprimir
LivreOcupada
Diagrama de Interatividade
• Diagrama de interatividade pode ser visto como um diagrama de atividade em que as atividades são substituídas por pequenos diagramas de sequência ou como diagramas de sequência que utilizam, de forma complementar, a notação do diagrama de atividades para exibir o controle do fluxo de execução.
Nestes diagramas, sequências formam um fluxo de atividades, mostrando como elas trabalham em uma sequência de eventos.
DIagrama de Colaboração
• Exibe a colaboração dinâmica entre os objetos
• Normalmente pode-se optar entre utilizar o diagrama de colaboração ou o diagrama de sequência.
Diagrama de Colaboração
Exibir msg:
Sem papel
Exibir msg:
Imprimindo
Criar arquivo para
imprimir
Remover a msg.
Imprimir
Sem papel
Papel OK
Diagrama de Tempo
• Mostra o comportamento e interação dos objetos em relação ao tempo
• É um método alternativo do diagrama de sequência porém mais completo
• É a fusão entre os diagramas de sequência e estado
Diagrama de Tempo
Cartão Cartão sendo inserido
Cartão inserido
Cartão sendo lido
Cartão lido
t0 t1 t3 t4t2