ESI UML Intro

Prévia do material em texto

Introdução a UML
Prof. Wilson M Yonezawa
UNESP – FC – Bauru
Depto. Computação
yonezawa@fc.unesp.br
Engenharia Software I
O que são modelos???
• Uma simplificação da realidade
• Oferece um desenho de um sistema em um 
determinado nível de abstração
• Exemplos de modelos:
– Modelo planetário
– Modelo atômico
– Modelo de um sistema de transporte coletivo
– Modelo de um sistema operacional
– Modelo de um sistema de gerenciamento de 
alunos
• Porque é uma forma de entendermos melhor
o sistema que precisamos construir
• Para representar o que será construído
• Para observar analisar o que será construído
• Para comunicar o que será construído
Por que criamos modelos?
• Ajuda a visualizar um sistema como ele é ou
como desejamos que seja
• Permite especificar a estrutura ou o
comportamento de um sistema
• Na construção de um guia para a construção
do sistema
• Na documentação das decisões tomadas no
projeto
Como os modelos auxiliam a E.S?
Princípios da modelagem
• “A escolha dos modelos a serem criados tem profunda
influência sobre a maneira como um determinado
problema é atacado e como uma solução é definida”
• “Cada modelo poderá ser expresso em diferentes níveis
de precisão”
• “Os melhores modelos estão relacionados à realidade”
• “Nenhum modelo único é suficiente. Qualquer sistema
não-trivial será melhor investigado por meio de um
pequeno conjunto de modelos quase independentes”
• Origem:
– Desenvolvida inicialmente no final de 1994
por Grady Booch e James Rumbaugh
– Ivar Jacobson, juntou-se ao grupo e iniciou
o trabalho de unificação das metodologias
Booch, OMT (Object Modeling Technique) e
OOSE (Object-Oriented Software Engi-
neering) em 1995.
UML – Unified Modeling Language
• “UML é uma linguagem padrão para
elaboração da estrutura de projetos de
software”
• “UML é adequada a modelagem de sistemas”
• “UML é apenas uma linguagem e, portanto, é
somente uma parte de um método para o
desenvolvimento de software”.
Booch, Rumbauch, Jacobson
UML – Unified Modeling Language
UML – Unified Modeling Language
• Linguagem para a elaboração da estrutura 
de projetos de software 
• Linguagem para:
Visualização,
Especificação
Construção 
Documentação 
• Representação gráfica com base na O.O.
• Cria modelos
• Negócios
• Requisitos
• Software
Conceitos - Orientação a objetos
• Classe e Objetos
• Abstração
• Encapsulamento
• Herança
• Polimorfismo
• Comunicação por mensagens
UML para visualizar
• UML permite elaborar modelos explícitos que
facilitam a comunicação
• UML utiliza um conjunto de símbolos que
permite comunicar ideias sem ambiguidade
Ex.: Um modelo escrito por um
desenvolvedor pode ser interpretado por
outro desenvolvedor
• Especificar é construir modelos precisos,
sem ambiguidades e completos
• UML atende as decisões importantes em
termos de análise, projeto e implementação
de sistemas de software
UML para especificar
• Modelos gerados em UML podem ser
conectados a várias linguagens de
programação
– Do modelo (UML) para o código-fonte
• É possível mapear modelos UML em
linguagens de programação e vice-versa
(engenharia reversa, mas nem sempre é
possível).
– Do código-fonte para o modelo (UML)
UML para construir
• Auxilia na documentação de artefatos de
software como: requisitos, arquitetura e projeto
• UML proporciona uma linguagem para
expressão de requisitos e para a realização de
testes
• UML auxilia na modelagem das atividades de
planejamento do projeto e gerenciamento de
versões
UML para documentar
Blocos de construção da UML
• Itens
– Estruturais
– Comportamentais
– Agrupamento
– Anotacionais
• Relacionamentos
 Dependência
 Associação
 Generalização
 Realização
• Diagramas
 Classes
 Objetos
 Casos de Uso
 Sequência
 Gráficos de estados
 Comunicação
 Atividades
 Componentes
 Implantação
UML - Diagramas
Diagramas UML
• Diagramas são os meios utilizados para a
visualização dos blocos de construção da UML
• São representações gráficas de um conjunto de
elementos
• Permitem visualizar o sistema sob diferentes
perspectivas
Visões complementares
• Visão do caso de uso
• Visão do projeto
• Visão do processo
• Visão da implementação
• Visão da implantação
Visões e formas
• Estruturais (itens estáticos)
• Comportamentais (itens dinâmicos)
• Em conjunto, as diferentes visões
captam as decisões importantes
• Individualmente, cada visão permite
voltar atenção para uma perspectiva do
sistema
Uso dos diagramas
• Para especificar modelos a partir dos quais
será construído um sistema executável
• Para reconstruir modelos a partir de partes
de um sistema executável (engenharia
reversa)
Como criar diagramas?
• De forma incremental:
• Ampliando os diagramas uma parte de
cada vez
• De forma iterativa:
• Repetindo o processo de projetar uma
pequena parte e construí-la
Estática e dinâmica
• Partes estáticas do sistema:
• Diagrama de Classes
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Implantação
• Partes dinâmicas do sistema:
• Diagrama de Casos de Uso
• Diagrama de Sequências
• Diagrama de Comunicação
• Diagrama de Gráfico de estados
• Diagrama de Atividades
Diagramas estruturais
• São organizados em função dos principais
grupos de itens encontrados na
modelagem de um sistema
Diagrama de classes: Classes, interfaces e colaborações
Diagrama de objetos: Objetos
Diagrama de componentes: Componentes
Diagrama de implementação: Nós
Diagramas comportamentais
Diagrama de caso de uso Organiza os comportamentos 
do sistema
Diagrama de sequência Foco na ordem temporal das 
mensagens enviadas e 
recebidas pelos objetos
Diagrama de comunicação Foco na organização estrutural 
dos objetos que enviam e 
recebem mensagens
Diagrama de gráfico de 
estados
Foco no estado de mudanças 
de um sistema orientado por 
eventos
Diagrama de atividades Foco no fluxo de controle entre 
objetos
Utilizando os diagramas
• Decida quais visões são necessárias para
expressar da melhor maneira a arquitetura do
sistema
• Para cada visão, decida quais artefatos devem ser
criados para capturar detalhes desta visão
• Decida quais diagramas deverão ser colocados
sob algum tipo de controle formal ou semiformal
Visão de caso de uso Diagrama de caso de uso
Visão de projeto Diagrama de classes
Diagrama de interação
Visão de processo Nenhum diagrama é necessário
Visão de implementação Nenhum diagrama é necessário
Visão de implantação Nenhum diagrama é necessário
Exemplo: Uma aplicação simples, executada em um 
único equipamento
Utilizando os diagramas
Diagrama de Caso de Uso
• Mostra atores (pessoas ou outros usuários do
sistema), casos de uso (os cenários onde eles
usam o sistema) e seus relacionamentos
• Descreve as interações típicas entre os
usuários de um sistema e o sistema
propriamente dito
• Representa a interface externa do sistema e
especifica o conjunto de exigências de o que o
sistema deve fazer
• O que são atores?
– Ator é uma entidade externa (fora do sistema)
que interage com o sistema participando de
um Caso de Uso
• Atores não representam as pessoa física ou
sistemas, mas sua regra
• Descrição do Caso de Uso são narrativas de
texto do Caso de Uso (em geral em forma de
Notas ou documentos)
Diagrama de Caso de Uso
Diagrama de Caso de Uso
• Em um caso de uso existe sempre no mínimo um
ator
• Existe sempre um iniciador num caso de uso
• Um caso de uso está sempre ligado a um
resultado relevante
• Caso de Uso podem estar relacionado a outros
casos de uso
• Tipos de relacionamentos:
– <<inclui-se>>: Um caso de uso toma lugar
dentro deoutro caso de uso
– <<estende>>: Um caso de uso é estendido
por outro caso de uso
– Generalização: Um caso de uso “herda”
características de um caso de uso de nível
superior
Diagrama de Caso de Uso
Utiliza linha
telefônica
Assinante
Acessar Internet
Efetua chamada de
voz
«extends»
«extends»
*
*
Sistema de Telefonia Fixa
Provedor Internet
*
*
Diagrama de Caso de Uso
Fonte: http://docs.kde.org/
Diagrama de Caso de Uso
• Mostra a troca de mensagens (isto é chamada de
método) entre diversos objetos, numa situação
específica e delimitada no tempo
• Coloca ênfase especial na ordem e nos
momentos nos quais mensagens para os objetos
são enviadas
Diagrama de Sequência
:ReceberPedido :AnalisarPedido
Actor1
enviarPedido
solicitarAnalise
confirmarPedido
Observar as regras de negócio no
 tratamento de pedido de clientes 
sem crédito.
Diagrama de Sequência
Diagrama de Sequência
Fonte: http://docs.kde.org/
Diagrama de Comunicação
• Mostra interação entre objetos sem muita
preocupação com a sequência das ações
• Indicado para mostrar um fluxo de um
programa
• Adequado para explanar um processo na
lógica do programa.
Diagrama de Comunicação
Diagrama de Gráfico de Estado
• Modela o comportamento de um objeto individual
• Especifica as sequências de estados pelos quais
um objeto passa durante seu tempo de vida em
resposta a eventos e suas respostas aos eventos
Iniciando servidor
Esperando conexão Desligando servidor
Atendendo conexão
Estado inicial
Estado final
Transição
Estado
Objeto: Servidor 
Diagrama de Gráfico de Estados
Partes de um estado
Nome do estado
Ações de entrada/saída
Transições internas
Subestados
Eventos adiados
Transição
Relaciona dois estados
Evento de ativação
Diagrama de Gráfico de Estado
Fonte: http://docs.kde.org/
Diagrama de Gráfico de Estado
• Gráfico de fluxo que mostra o fluxo de
controle de uma atividade para a outra (visão
lógica)
• Modelagem seqüencial de um processo
computacional
• Uma atividade é uma execução não atômica
em andamento em uma máquina de estados
Diagrama de Atividades
Diagrama de Atividades
Identificar Cliente
Cadastrar Cliente
Consultar Referências Fazer Orçamentos
Analisar Orçamento :Orçamento : <unspecified>
Bifurcação concorrente
União concorrente
Fluxo de objeto
Estado final
Estado inicial
Ramificação sequencial
Estado de ação
Estado de atividade
Classes
• Classe é uma descrição de um conjunto de
objetos que compartilham os mesmos
atributos, operações, relacionamentos e
semântica
• Termos e conceitos:
– Nomes da classe
– Atributos
– Operações
– Responsabilidade
• Classes são descritas por substantivos (ex:
Cliente, SensorTemperatura, Motor,
Computador, Carro)
• Atributos são propriedades nomeadas de uma
classe (ex: nome, endereço, dataNascimento)
• Operações são implementações de serviços que
pode ser solicitado por algum objeto da classe
para modificar o comportamento.
Classes
• O nome da operação é um verbo que representa
algum comportamento da classe correspondente
(ex: move, isEmpty)
• É possível especificar uma operação indicando
sua assinatura com o nome, o tipo e valor padrão
dos parâmetros, assim com o tipo a ser
retornado
– Ex: configurarSensor(limiteMinimo: int):
boolean
Classes
Estereótipos
Classes
Responsabilidade: É 
um contrato ou 
obrigação da classe.
Exemplo: 
Efetuar matricula todos 
semestre
• Cancelar disciplina 
sempre que desistir da 
mesma
Classes
Classes e responsabilidades
• Modelar classes é especificar responsabilidades
dos itens
• Uma classe pode ter qualquer número de
responsabilidades (pelo menos uma
responsabilidade é necessária)
• As responsabilidades de uma classe podem ser
traduzidas num conjunto de atributos e
operações ao longo do processo de modelagem
Como identificar “Classes”?
• Levantar o vocabulário do sistema ou do
problema
• Identifique as principais abstrações no
problema
• Identifique as responsabilidades do sistema
• Classes não trabalham sozinhas
• Classes colaboram/comunicam-se umas com as
outras
• Três tipos básicos de relacionamento:
• Dependências
• Generalizações
• Associações
• Ex:
• Construir uma casa, carro ou
computador
• Quais as dependências,
generalizações e associações
existentes nesta tarefa?
Relacionamentos
Relacionamentos
+open()
+close()
+move()
+display()
+handleEvent()
-style
-posX
-posY
Window
MessageBox DialogBox Control
Event
* *
dependência
generalização
associação
Relacionamentos – Generalização
Forma
PolygonoCírculoRetangulo
Relacionamentos – Dependência
Relacionamentos – Associação
Papéis
Multiplicidade • Nome
• Papel
• Multiplicidade
• Agregação
Relacionamentos – Agregação
Empresa
1
*
Departamento
Todo
Parte
Composição
Janela
1
*
Moldura
Referências
• Allardice, S. Foundations of Programming Object-Oriented Design,
Disponível online em: www.lynda.com, acessado em setembro/2016.
• Booch, G.; Rumbauch, J.; Jacobson I. UML Guia do Usuário, Editora
Campus, 2006.
• http://www.tutorialspoint.com/uml/
• https://umbrello.kde.org/
• http://www.omg.org/spec/UML/