UML
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ÃOGERAL
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ÃOGERAL
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 DESOFTWARE
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 DESOFTWARE
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
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ÇÃOHISTÓRICA DAMODELAGEM
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ÇÃOHISTÓRICA DAMODELAGEM
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 DEUMLD
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 DEUML
O
PROCESSO DE DESENVOLVIMENTO DE
SOFTWARE
Compreende
as atividades
necessárias
para definir,
desenvolver,
testar e manter
um produto
(sistema) de
software.
Tentativas de
lidar com a
complexidade
e de minimizar
os problemas
envolvidos no
desenvolvimen
to de 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.
O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
A
TIVIDADES 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.
MECANISMOSGERAIS
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.
MECANISMOSGERAIS
F
ERRAMENTAS
C
ASE
Sistemas de software que são utilizados
para dar suporte ao desenvolvimento são normalmente chamados de ferramentas CASE.
MECANISMOSGERAIS
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.
MECANISMOSGERAIS
N
OTAS
E
XPLICATIVAS
São utilizadas para definir informação que comenta ou esclarece alguma parte do diagrama.
E
TIQUETAS
V
ALORADAS
( T
AGGED
V
ALUES
)
MECANISMOSGERAIS
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.
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
R
ESTRIÇÕES
E O
CL
OCL é um acrónimo de Object Constraint
Language (ou Linguagem para Especificação de Restrições em Objetos, em português). É uma linguagem declarativa para descrever as regras que se aplicam aos
modelos UML desenvolvida na IBM e que agora é parte do padrão UML. OCL, inicialmente, era apenas uma extensão de UML para especificações formais de modelos.
MECANISMOS GERAIS
R
ESTRIÇÕES
E O
CL
A linguagem OCL é uma linguagem de texto
precisa que possibilita a expressão de restrições em um modelo orientado a objeto que não possam ser especificadas através dos diagramas.
OCL, por fornecer expressões livres das
ambiguidades das linguagens naturais e menos difíceis que os métodos formais tradicionais, complementa os modelos UML.
MECANISMOS GERAIS
P
ACOTES
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.
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 sequencia 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.
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.
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.
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.
