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