UML

 Instituto Federal da Bahia

 Alunos: Fabiano Souza e Luana Menezes

 Orientador: Antonio Carlos

 Disciplina: Introdução a Computação

 ADS.1
V ISÃO G ERAL

 A Unified Modelling Language (UML) é uma

linguagem ou notação de diagramas para
especificar, visualizar e documentar modelos de
'software' orientados por objetos.

 A UML não é uma metodologia de

desenvolvimento!

 Basicamente, a UML permite que

desenvolvedores visualizem os produtos de seus
trabalhos em diagramas padronizados.

VISÃO GERAL
V ISÃO G ERAL

 O UML é controlado pelo Object Management

Group (OMG) que é padrão da indústria para
descrever graficamente o 'software'.

 É importante distinguir entre um modelo UML e

um diagrama (ou conjunto de diagramas) de
UML.

VISÃO GERAL
M ODELAGEM DE S OFTWARE

 É a atividade de construir modelos que

expliquem as características ou o
comportamento de um software ou de um
sistema de software.

 Frequentemente a modelagem de software usa

algum tipo de notação gráfica e são apoiados
pelo uso de Ferramentas CASE.

 A modelagem de software normalmente utiliza a

construção de modelos gráficos.

MODELAGEM DE SOFTWARE
M ODELAGEM DE S OFTWARE

 Programas procedurais (não orientados a objeto)

utilizam fluxogramas.

 Programas orientados a objeto normalmente

usam a linguagem gráfica UML.

MODELAGEM DE SOFTWARE
O RIENTAÇÃO À OBJETOS

 A orientação a objetos, também conhecida

como Programação Orientada a Objetos (POO),
é um paradigma de análise, projeto e
programação de sistemas de software baseado
na composição e interação entre diversas
unidades de software chamadas de objetos.

 Classe / Atributo / Método/ Construtor

ORIENTAÇÃO À OBJETOS
E VOLUÇÃO H ISTÓRICA DA M ODELAGEM

 Décadas de 1950/60 – Sistemas de Softwares

bastantes simples.

 Década de 1970 – Grande expansão do mercado

computacional, computadores mais avançados e
acessíveis.

 Década de 1980 – Surge a necessidade de

interfaces mais sofisticadas, o que originou a
produção de sistemas de softwares mais
complexos. Surge a análise estruturada.

EVOLUÇÃO HISTÓRICA DA MODELAGEM

E VOLUÇÃO H ISTÓRICA

 Início da Década de 1990 – Este é o período que

surge um novo paradigma de modelagem, a
Análise orientada à objetos.

 Fim da Década de 1990 – O paradigma da Análise

orientada à objetos atinge sua maturidade. Surge
a Linguagem de Modelagem Unificada (UML).

EVOLUÇÃO HISTÓRICA DA MODELAGEM

D IAGRAMAS DA UML

 Diagramas Estruturais:

 ->Diagrama de Classes

 ->Diagrama de Objetos

 ->Diagramas de componentes

 ->Diagrama de instalação

 ->Diagrama de pacotes

 ->Diagrama de estruturas

DIAGRAMAS DE UML
D IAGRAMAS DA UML

 Diagramas comportamentais
 ->Diagrama de caso de uso

 ->Diagrama de transição de estado

 ->Diagrama de atividade

 Diagramas de Interação
 ->Diagrama de sequência

 ->Diagrama de interatividade

 ->Diagrama de comunicação

 ->Diagrama de tempo

DIAGRAMAS DE UML
O PROCESSO DE DESENVOLVIMENTO DE
SOFTWARE

 Compreende  Tentativas de
as atividades lidar com a
necessárias complexidade
para definir, e de minimizar
desenvolver, os problemas
testar e manter envolvidos no
um produto desenvolvimen
(sistema) de to de software.
software.

O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

D ADOS LEVANTADOS

 Porcentagem de projetos que terminam dentro

do prazo estimado: 10%

 Porcentagem de projetos que são

descontinuados antes de chegarem ao fim: 25%

 Porcentagem de projetos acima do custo

esperado: 60%

 Atraso médio nos projetos: um ano.

Chaos Report (1994)

O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

 ATIVIDADES DE UM PROCESSO DE
DESENVOLVIMENTO

 Análise (ou levantamento) de requisitos

 Análise

 Design (Projeto)

 Programação (Implementação)

 Testes

 Implantação

O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

P ROTOTIPAGEM

 Um protótipo é um esboço de alguma parte do

sistema.
 A prototipagem é uma técnica complementar à
análise de requisitos.
 Objetivo: assegurar que os requisitos do sistema
tenham sido bem entendidos.
 A construção de protótipos utiliza ambientes
com facilidades para a construção da interface
gráfica.

MECANISMOS GERAIS
P ROTOTIPAGEM

 A prototipagem NÃO é um substituto à

construção de modelos do sistema.

 A prototipagem é uma técnica

complementar à construção dos
modelos do sistema.
 Mesmo com o uso de protótipos,
os modelos do sistema devem ser
construídos.

MECANISMOS GERAIS
F ERRAMENTAS C ASE

 Sistemas de software que são utilizados

para dar suporte ao desenvolvimento são
normalmente chamados de ferramentas
CASE.

MECANISMOS GERAIS
E STERIÓTIPOS

 Mecanismo de extensão de UML. Quando você

precisa modelar algo que não existe em UML,
mas sabe que existe algo semelhante.

MECANISMOS GERAIS
N OTAS E XPLICATIVAS

 São utilizadas para definir informação que

comenta ou esclarece alguma parte do diagrama.

MECANISMOS GERAIS
E TIQUETAS VALORADAS ( TAGGED
VALUES )
Um valor etiquetado é uma combinação de um tag e um valor que
fornece informações complementares que é anexado a um
elemento do modelo. Um valor de tag pode ser usada para
adicionar propriedades para todos os elementos do modelo e pode
ser aplicado a um elemento de modelo ou um estereótipo.

MECANISMOS GERAIS
 R ESTRIÇÕES E O CL

 Restrições: Permitem estender ou alterar a

semântica natural de um elemento gráfico.

 OCL : A OCL é uma linguagem de expressões para

especificar restrições sobre modelos orientados a
objetos ou outros artefatos da linguagem UML. É
uma linguagem precisa, textual e formal. Uma
das suas principais características é que seu uso
não exige um forte conhecimento matemático
para sua manipulação.

MECANISMOS GERAIS
PACOTES

 Pacote é um mecanismo de propósito geral para

organizar elementos de modelo em grupos.

MECANISMOS GERAIS
 M ODELAGEM DE CASOS DE USO

 Representação das funcionalidades

externamente observáveis do sistema e dos
elementos externos ao sistema que interagem
com ele.

 É importante, pois direciona diversas tarefas

posteriores do processo de desenvolvimento de
um sistema de software.

MODELAGEM DE CASOS DE USO

C ASOS DE USO – U SE C ASE

Um caso de uso representa quem

faz o que (interage) com o sistema,
sem considerar o comportamento
interno do sistema.

Um conjunto de cenários, onde cada

cenário é uma sequência de passos
a qual descreve uma interação entre
um usuário (atores) e o sistema.

MODELAGEM DE CASOS DE USO

 D IAGRAMA DE CASOS DE USO

 Corresponde a uma visão externa de alto nível do

sistema.

 Representa graficamente os atores, os casos de

uso e o relacionamento entre esses elementos.

MODELAGEM DE CASOS DE USO

MODELAGEM DE CASOS DE USO
D IAGRAMA DE C LASSE

 Diagramas de Classe mostram as diferentes

classes que fazem um sistema e como elas se
relacionam. Os Diagramas de Classe são
chamados diagramas “estáticos” porque
mostram as classes, com seus métodos e
atributos bem como os relacionamentos
estáticos entre elas: quais classes “conhecem” ou
quais classes “são parte” de outras classes, mas
não mostram a troca de mensagens entre elas.
DIAGRAMA DE CLASSE

Associação : São relacionamentos estruturais entre instâncias e

especificam que objetos de uma classe estão ligados a objetos
de outras classes.
DIAGRAMA DE CLASSE
Associação : São relacionamentos estruturais entre instâncias e especificam que objetos de uma
classe estão ligados a objetos de outras classes.

Generalização (herança : simples ou composta) - Relacionamento entre um elemento mais geral e

um mais específico. Onde o elemento mais específico herda as propriedades e métodos do elemento
mais geral.

Dependência - São relacionamentos de utilização no qual uma mudança na especificação de um

elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que
os objetos de uma classe usam serviços dos objetos de outra classe.

Agregação Regular - tipo de associação ( é parte de , todo/parte) onde o objeto parte é um atributo do
todo ; onde os objetos partes somente são criados se o todo ao qual estão agregados seja criado.
Pedidos é composto por itens de pedidos.

Composição - Relacionamento entre um elemento ( o todo) e outros elementos (as partes) onde
as parte só podem pertencer ao todo e são criadas e destruídas com ele.
D IAGRAMA DE C LASSE
 Atributos
 Na UML, atributos são mostrados com pelo menos seu nome, e podem também
mostrar seu tipo, valor inicial e outras propriedades. Atributos podem também
ser exibidos com sua visibilidade:

 + indica atributos públicos

 # indica atributos protegidos

 - indica atributos privados

 Operações
 Operações (métodos) também são exibidos com pelo menos seu nome, e podem
também mostrar seus parâmetros e valores de retorno. Operações podem, como
os Atributos, mostras sua visibilidade:

 + indica operações públicas

 # indica operações protegidas

 - indica operações privadas

D IAGRAMA DE C LASSE
D IAGRAMA DE INTERATIVIDADE

 Diagramas de interatividade são variações de

“Diagrama de atividade". Nele, sequências
formam um fluxo de atividades, mostrando como
elas trabalham em uma sequência de eventos.
 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 Diagrama de Sequência que
usam, de forma complementar, a notação do
Diagrama de Atividades para mostrar controle de
fluxo.
D IAGRAMA DE INTERATIVIDADE

O Umbrello UML Modeller mostrando um Diagrama de Atividade.

D IAGRAMA DE I NTERATIVIDADE

 Diagramas de Atividade são similares as

Diagramas de Fluxo de procedimentos, com a
diferença de que todas as Atividades são
claramente anexas aos Objetos.

 Diagramas de Atividade são sempre associados a

um Classe, uma Operação ou um Caso de Uso.
 UML x LINGUAGEM
ESTRUTURADA
Animal[] listaDeAnimais = new Animal[100]; // Criamos um array
com 100 posições que armazena objetos do tipo Animal.

listaDeAnimais[0] = new Cachorro("Frodo"); // Criamos um

novo objeto do tipo Cachorro com o nome Frodo e
armazenamos no array

listaDeAnimais[1] = new Gato("Alan"); // Criamos um novo

objeto do tipo Gato com o nome Alan e armazenamos no array

Classe Animal {
método fale() {
imprimaNaTela(" Eu sou mudo! ");
}
}
B IBLIOGRAFIA
Bezerra, Eduardo - Princípios de análise e projeto
de sistemas com UML/Eduardo Bezerra – Rio de
Janeiro: Elsevier ,2007

http://docs.kde.org/