Transcript ANP Diagramas UML

ANP
Diagramas UML
Profº Henrique Vila Nova
Unibratec
CTD – 2º Período
Bibliografia

Booch, G., Rumbaugh, J. e Jacobson, I., The Unified Modeling
language User Guide, Addison-Wesley, 1999.
O que é UML ?
 UML é uma linguagem de modelagem, não uma metodologia (ou
método). A linguagem de modelagem é a notação (principalmente
gráfica) utilizada em metodologias para expressar os projetos.
 Metodologia é composta de:
uma linguagem de modelagem e
um processo, que descreve os passos a serem seguidos na
elaboração de um sistema.
 A linguagem de modelagem é a parte chave para a comunicação entre
as partes envolvidas em um projeto.
Os participantes devem ser capazes de entender a linguagem de
modelagem e não o processo utilizado no desenvolvimento do projeto.
Histórico
 Existiam várias metodologia de modelagem OO a disposição da
comunidade de desenvolvedores OO. Entre elas :
Método de Booch - do Booch,
Técnica de Modelagem de Objetos (OMT) - do Rumbaugh,
OOSE/Objectory - do Ivar Jacobson
 Estes três resolveram criar uma linguagem de modelagem unificada.
 A UML reúne as melhores idéias de cada uma das metodologias.
UML passou por um processo de padronização pela OMG (Object
Management Group) e é agora um padrão OMG.
 Os “três amigos” também desenvolveram um processo unificado, que
eles chamaram de RUP (Rational Unified Process). Não é necessário
utilizar RUP para usar UML
Vantagens de UML
1) Independência de metodologia de desenvolvimento.
2) Padrão aberto e não proprietário.
3) Aplicável a todas as fases do ciclo de desenvolvimento.
4) Independência de linguagem de implementação.
5) Integração das melhores práticas de modelagem.
6) Suporte à conceitos de alto nível.
7) Usada para modelagem de Softwares OO mas também aplicadas em
sistemas mecânicos e processos em geral da organização.
8) Facilidade para visualizar, especificar, construir e documentar
sistemas grandes e complexos.
O que é possível fazer com a UML
1) Explicitar as fronteiras do sistema e suas principais funcionalidades
(casos de uso e atores);
2) Ilustrar a realização dos casos de usos (diagramas de interação);
3) Representar as estruturas estáticas do sistema (diagramas de
classes).
4) Modelar o comportamento dos objetos (diagramas de transição de
estados);
5) Mostrar a arquitetura física da implementação (diagramas de
componentes)
6) Capturar a topologia de hardware do sistema (diagrama de
implantação)
A notação UML
 Visões - Mostram diferentes aspectos do sistema. Cada visão
mostrará aspectos particulares do sistema dando enfoque a ângulos e
níveis de abstrações diferentes. Visão não é um gráfico, mas uma
abstração consistindo em uma série de diagramas.
 Modelo de Elementos - Os conceitos usados nos diagramas são
modelos de elementos que representam definições comuns da orientação a
objetos.
 Mecanismos Gerais - Inclui comentários suplementares, informações,
ou semântica sobre os elementos que compõem os modelos.
 Diagramas - São os gráficos que descrevem o conteúdo em uma visão.
UML possui nove tipo de diagramas que são usados em combinação para
prover todas as visões do sistema.
Visões
 Um sistema é composto por diversos aspectos:
Funcional – Sua estrutura estática e suas interações dinâmicas.
Não Funcional – requisitos de tempo, confiabilidade,
desenvolvimento, etc.
Organizacionais - organização do trabalho, mapeamento dos
módulos de código, etc.
 Cada visão é descrita por um número de diagramas que contém
informações que dão ênfase aos aspectos particulares do sistema.
 Existem em alguns casos uma certa sobreposição entre os diagramas
o que significa que um destes pode fazer parte de mais de uma visão.
Visões
Os diagramas que compõem as visões contém os modelos de elementos do
sistema.
As visões que compõem um sistema são:
Visão
Visão
Visão
Visão
Visão
“Use-Case"
Lógica
de Componentes
de Concorrência
de Organização
Visão
Diagrama
Modelo de
Elementos
Visão “Use-Case"
 Descreve a funcionalidade do sistema desempenhada pelos atores
externos do sistema.
 Visão central, base do desenvolvimento das outras visões do sistema.
 Essa visão é montada sobre:
Diagramas de Use-Case e
Diagramas de Atividade (eventualmente)
Visão Lógica
 Em contraste com a visão “use-case”, a visão lógica observa e estuda
o sistema internamente.
 Descreve e especifica a estrutura estática do sistema (classes,
objetos, e relacionamentos) e as colaborações dinâmicas quando os
objetos enviarem mensagens uns para os outros para realizarem as
funções do sistema.
 A estrutura estática :
Diagramas de Classes e Objetos.
 A modelagem dinâmica :
Diagrama de Seqüência, Colaboração e
Diagramas de Estado, Atividade.
Visão de Componentes
 É uma descrição da implementação dos módulos e suas dependências.
 É principalmente executado por desenvolvedores, e consiste nos
componentes dos diagramas.
 Captura as informações do modelo físico de implementação, tais como
arquivos de programas e sub-sistemas.
Visão de concorrência
 Trata a divisão do sistema em processos e processadores.
 Permite observar se o sistema possui execuções paralelas, e se existe
gerenciamento de eventos assíncronos.
 Uma vez dividido o sistema em linhas de execução de processos
concorrentes (threads), esta visão de concorrência deverá mostrar como
se dá a comunicação e a concorrência destas threads.
 A visão de concorrência é suportada :
Diagramas Dinâmicos, que são os diagramas de estado,
seqüência, colaboração e atividade,
Diagramas de Implementação, que são os diagramas de
componente e execução.
Visão de Organização
Mostra a organização física do sistema, os computadores, os
periféricos e como eles se conectam entre si.
Esta visão será executada pelos desenvolvedores, integradores e
testadores, e será representada pelo diagrama de execução.
Visão de
Componentes
Visão de
Organização
Visão Lógica
Visão de
Use-Case
Visão de
Concorrência
Modelos de Elementos
 Os conceitos usados nos diagramas são chamados de modelos de
elementos.
 Um modelo de elemento é definido com sua semântica e possui
representação gráfica que é mostrada nos diagramas da UML.
 Um elemento pode existir em diversos tipos de diagramas, mas existem
regras que definem que elementos podem ser mostrados em que tipos de
diagramas.
 Alguns exemplos de modelos de elementos são as classes, objetos,
estados, pacotes e componentes. Os relacionamentos também são modelos
de elementos.
Objeto
 Um objeto é uma entidade independente que armazena dados,
encapsula serviços, troca mensagens com outros objetos e é
modelado para executar as funções do sistema.
Java :
Turma
Estrutura :
Turma
Maria :
Pessoa
Bono :
Produto
Coca Cola :
Produto
Luis :
Pessoa
Classe
 Uma classe é uma descrição de um conjunto de objetos que
compartilham os mesmos atributos (características) , operações,
relacionamentos e semântica.
 Todos os objetos são instâncias de classes, onde a classe descreve
as propriedades e comportamentos daquele objeto.
Nome da Classe
Atributos da Classe
Operações da Classe
(Métodos)
Classe
Atributos da Classe
Operações da Classe
(Métodos)
 Atributos são propriedades de uma classe, que descreve um
intervalo de valores que as instâncias podem apresentar. Uma classe
pode ter qualquer número de atributos ou nenhum.
 Operações correspondem aos processos que a classe pode realizar.
Estado de um Objeto
 Todos os objetos possuem um estado resultante de atividades
executadas pelo objeto. Este estado é determinado pelos valores dos
atributos e ligações com outros objetos.
 Um objeto muda de estado quando acontece algo e o fato de acontecer
alguma coisa com o objeto é chamado de evento.
 Através da análise da mudança de estados dos tipos de objetos de um
sistema podemos prever os possíveis comportamentos dos objetos de
acordo com os eventos que o mesmo possa sofrer.
 Deve ser construído um Diagrama de Estados para cada classe cujos
objetos apresentem algum comportamento dinâmico significante.
Estado de um Objeto
 A modificação de estado causada por um evento é chamada transição.
 Um estado tem :
1) Nome do Evento: mostra o nome do evento. Geralmente descreve o que o
estado realiza.
2) Atividades: lista os eventos e ações. Dividido em três eventos : Entrar,
Fazer e Sair.
Abrindo
Exemplo de uma Conta :
entry/ fazer depósito inicial
do/ inserir lista de clientes
exit/ informar limite disponibilizado
Herança
 Herança é a capacidade de uma classe definir o seu comportamento e
sua estrutura aproveitando definições de outra classe, normalmente
conhecida como classe base ou classe pai.
Note que as subclasses herdam tudo o
que a classe pai possui e acrescenta as
suas características particulares.
Especialização e Generalização
 Através do mecanismo de herança é possível definir classes
genéricas que agreguem um conjunto de definições comuns a um grande
número de objetos (Generalização).
 A partir destas especificações genéricas pode-se construir novas
classes, mais específicas, que acrescentem novas características e
comportamentos aos já existentes (Especialização).
Generalização
Especialização
Mensagens
 São estímulos enviados aos objetos solicitando que alguma operação
seja realizada por um dado objeto.
 Nome da mensagem
 Parâmetros
 A mensagem especifica O QUE deve ser feito.
 O comportamento de um objeto é dado pelo conjunto de mensagens
que ele pode responder.
Dr. Paulo :
Medico
Diagrama de
Seqüência
Dr. Luis :
Medico
Daniel :
Enfermeiro
aplicarInjecao( )
fazerCurativo( )
Interfaces
 As interfaces são estritamente modelos de comportamento.
 As interfaces não podem ser instanciadas pois não produzem
objetos.
 A relação existente entre as classes que implementam uma
Interface e a Interface é uma relação do tipo “implementa os métodos
de”. Não precisa ter significado semântico.
Relação “implementa os métodos de”
Mecanismos Gerais - Ornamentos e Notas
 Especificação de multiplicidade de relacionamentos são ornamentos.
Também é um ornamento separar tipo de uma instância da classe.
 Nem tudo pode ser definido em uma linguagem de modelagem. Para
permitir adicionar informações a um modelo, UML provê a capacidade
de adicionar Notas.
 Uma Nota pode ser colocada em qualquer lugar em um diagrama, e
pode conter qualquer tipo de informação
Diagramas
 Em UML os modelos são desenvolvidos a partir de blocos tais como:
classes, interfaces, colaborações, dependências, generalizações,
associações, etc. Os diagramas são os meios utilizados para visualização
de blocos de construção.
 Os diagramas utilizados pela UML são compostos por nove tipos:
Diagramas de Casos de Uso
Diagramas de Classes
Diagramas de Objetos
Diagramas de Estado
Diagramas de Atividade
Diagramas de Seqüência
Diagramas de Colaboração
Diagramas de Componentes
Diagramas de Execução
Diagramas
 O modelo funcional
Diagramas de Casos de Uso
 O modelo estático
Diagramas de Classes e Diagramas de Objetos
 O modelo dinâmico
Diagramas:
de Estado,
Sequencia,
Colaboração
Atividade
 Arquitetura Física do Sistema
Diagramas de Componentes e Diagrama de Execução
Diagramas de Casos de Uso
 Este tipo de diagrama ilustra um conjunto de casos de uso para um
sistema, os atores e a relação entre os atores e os casos de usos.
 O modelo de caso de uso consiste de atores e casos de uso.
Sistema de Matricula
Sistema Bancário
Adicionar Valor Conta
Aluno
Matricular Aluno
Cliente
Retirar Valor Conta
ator
Caso de uso
ator
Casos de uso
Atores
 Atores representam usuários ou sistemas que interagem com o
sistema modelado.
 Um ator é um tipo (uma classe), não uma instância.
 Um ator se comunica com o sistema através de mensagens, embora
estas mensagens não estejam especificadas.
 Um ator pode ser:
primário: usa funções principais do sistema
secundário: usa as funções que mantém o sistema
(gerenciamento)
ativo: inicia um caso de uso
passivo: nunca inicia, mas apenas participa do caso de uso
Casos de Uso
 Casos de Uso são cenários que o sistema percorre em resposta ao
estímulo de um ator.
 Casos de Uso são descritos por um texto contendo:
Objetivo do Caso de Uso e Como o caso de Uso é iniciado
O fluxo de mensagens entre atores e casos de uso
Fluxo alternativo (execuções alternativas)
Como o caso de uso termina e retorna um valor para o ator
 Três tipos de relacionamentos entre os casos de uso:
Inclusão: quando deseja evitar a repetição de ações
Generalização: acrescenta comportamento a casos de usos base
Extensão: acrescenta comportamento a casos de usos base,
explicando os pontos de extensão
Diagramas de Casos de Uso
 Diagramas de Caso de Uso determinam as funções que deverão ser
suportadas pelo sistema modelado.
 Os diagramas dão uma visão geral mas as descrições dos casos de
uso são tipicamente textuais.
 Não existe preocupação com implementação de cada uma das funções
pois o propósito é determinar somente a funcionalidade que será
oferecida.
 Ferramenta útil na captura de requisitos e no planejamento. Esta
captura é uma das tarefas básicas necessárias para construção do
sistema.
Diagramas de Casos de Uso
Sistema de
Matricula
<<extend>>
Aluno
Matricular Aluno
Matricular Alunos
Novos
Matricular Aluno
Transferido
Pontos de Extensão:
Nota no teste
FaculdadeAnterior
Diagramas de Casos de Uso
<<include>>
Cadastar Cliente
Funcionário
Banco
Sistema
Bancário
Verificar Cliente
Só pode ter
uma conta
corrente
Criar Conta
<<include>>
Verificar Tipo de Conta
<<include>>
Retirar Valor Conta
Cliente
Identificar Conta
<<include>>
Adicionar Valor Conta
Diagramas de Classes
 Descreve as classes do sistema, seus atributos, operações e
relacionamentos. Representa a visão estática do sistema.
 Um sistema pode possuir alguns diagramas de classes. Neste caso,
uma classe pode participar em vários diagramas.
 Existem três perspectivas para projetar diagramas.
Conceitual : Representa os conceitos do mundo real. Sem
preocupação quanto aos aspectos de implementação.
Especificação: Aspetos de interface, não de implementação.
Implementação: Temos realmente as classes e as definições de
implementação.
Relacionamento entre Classes
1) Associação
 Associações e ligações são os mecanismos para estabelecer
relacionamentos entre objetos e classes. Uma associação descreve um
conjunto de ligações potenciais.
Possui
Cliente
1
Conta
1..*
 Alguns atributos dizem respeito
a associações e não a classes.
Estes se transformam em classes
de Associação.
Relacionamento entre Classes
1) Associação
 Embora associações sejam bidirecionais por padrão, é freqüentemente
desejável limitar sua “navegação” em uma única direção. Se a navegação
for limitada, uma seta é adicionada para indicar a direção na qual a
associação pode ser percorrida.
Pedido
Cliente
*
1
 Uma associação recursiva representa uma associação entre objetos da
mesma classe.
Relacionamento entre Classes
1) Associação
Associações qualificadas são usadas com associações de um para vários
(1..*) ou vários para vários (*..*). O “qualificador” (identificador da
associação qualificada) especifica como um determinado objeto no final da
associação "n" é identificado, e pode ser visto como um tipo de chave para
separar todos os objetos na associação.
O qualificador permite reduzir a multiplicidade da associação para 1.
 O identificador é desenhado como uma pequena caixa no final da
associação junto à classe de onde a navegação deve ser feita.
Cliente
ContaCorrente
cod
1
0..1
2) Agregação
 Uma agregação é um relacionamento do tipo “parte de”, nos quais objetos
representando os componentes são associados com objetos representando
uma montagem.
 Agregação é uma forma de associação com alguma semântica adicional. É
transitiva (se A é parte de B e B parte de C, então A é parte de C)
contém
Sistema
1
Linguagem
1
 Agregação Compartilhada é um tipo especial de agregação que ocorre
quando uma das classes é uma parte, ou está contida na outra, mas esta
parte pode estar contida na outra várias vezes em um mesmo momento.
contém
Estojo
1
Lapis
*
contém
Turma
*
Aluno
*
3) Composição
 É uma forma mais forte de agregação. Na composição, o objeto parte
pode pertencer somente a um todo e espera-se que as partes vivam e
morram com o todo.
 Se o objeto da classe que contém for destruído, as classes da
composição serão destruídas juntamente.
Formulario
JTextField
JTextArea
JButton
JComboBox
4) Dependência
 Forma mais fraca de relacionamento, onde uma classe (o cliente)
depende de outra classe (o servidor) para um serviço específico.
 Uma mudança no elemento independente irá afetar o modelo
dependente.
 Uma relação de dependência é simbolizada por uma linha tracejada
com uma seta no final de um dos lados do relacionamento.
Declaracao Imposto
1
Usa
1
Calculadora
4) Dependência
 Existe um relacionamento de dependência entre duas classes quando:
• um objeto da classe servidora é passado como parâmetro de um
método da classe cliente ou,
• um objeto da classe servidora é declarado localmente em um método
da classe cliente ou,
• um objeto global da classe servidora é acessado pela classe.
 Um dos objetivos do desenvolvimento é manter as dependências ao
mínimo.
 Manter a interface das classes evita problemas de dependências.
Diagramas de Classes
Sistema
Bancário
Agregações
Banco
1
1
Cliente
1
Conta Poupanca
0..*
Conta
0..*
1
Generalização
*
Conta Corrente
Associação
bidirecional
Operacao
0..*
Classe de
Associação
Diagramas de Objetos
 O diagrama de Objetos fazem a modelagem de instâncias de itens
contidos em diagramas de classes.
 Mostra um conjunto de objetos e seus relacionamentos em um
determinado ponto do tempo.
 É uma variação do diagrama de classes e utiliza quase a mesma
notação. A diferença é que os objetos são escritos com seus nomes
sublinhados e todas as instâncias num relacionamento são mostradas.
 Envolve a modelagem do sistema em um determinado ponto.
 Pode-se considerar o diagrama de objetos como um diagrama de
colaboração sem mensagens.
Diagramas de Objetos
Um cliente pode ter
apenas 1 conta corrente.
Ana : Cliente
001B2 : Conta Poupanca
001A : Conta Corrente
001B1 : Conta Poupanca
Diagramas de Interação
 Diagramas de interação descrevem como os casos de uso são
realizados através das interações entre objetos.
 Dinâmica do sistema : forma pela qual os objetos se comunicam no
sistema e alteram seus estados durante o tempo de vida do sistema.
 A comunicação entre um conjunto de objetos, com o propósito de
executar alguma função, é chamada interação. Pode ser descrita pelos:
Diagramas de Seqüência
Diagramas de Colaboração
Também chamados
Diagramas de Atividades
de Diagramas de Interação
 Além destes diagramas, o modelo dinâmico pode ser descrito com
auxílio dos Diagramas de Estado.
Diagramas de Estado
 Mostra todos os estados possíveis nos quais objetos de uma certa
classe podem se encontrar e mostra quais os eventos que provocam
mudanças entre estes estados.
 Não são escritos para todas as classes de um sistema, mas apenas
para aquelas que possuem um número de estados conhecidos.
 É um complemento para a descrição das classes.
 Os estados representam as condições dos objetos em um
determinado momento. Os eventos representam incidentes que causam a
mudança de um estado para outro. As linhas de transição descrevem o
movimento de um estado para o outro.
Diagramas de Estado
Condição de Guarda
Estado
INÍCIO
Estado inicial
de uma
Conta
ef etuar operação( tipo da operacao )[ saldo+limite >0 ]
Argumentos
solicitar criação conta corrente
Abrindo
Operando
ef etuar operação( tipo operacao ) / saldo=0
entry/ vincular a Cliente
entry/ definir limite
do/ adicionar Valor Conta (depósitos)
do/ retirar Valor Conta (retiradas)
exit/ informar Saldo
Evento
Atividade
Estado f inal
de uma conta
bancária
Ação de
Transição
solicitar encerramento da conta pelo cliente
Fechando
FI
M
encerrar conta[ saldo=limite ]
entry / zerar saldo
exit/ desv incular cliente da conta
Diagramas de Atividades
 Diagramas de atividades capturam ações e seus resultados, com foco
no trabalho executado na implementação de uma operação (método) e
suas atividades numa instância de um objeto.
 É uma variação do diagrama de estado onde todos os estados têm uma
ação interna e nenhuma transição tem um evento de entrada.
 Os estados no diagrama de atividade mudam para um próximo estágio
quando uma ação é executada, sem ser necessário especificar eventos
como no diagrama de estados.
 Representa o que acontece mas não quem faz. Não diz que classe é
responsável por cada atividade. Através do uso de divisores (Swimlanes)
podemos separar as atividades de acordo com as classes responsáveis.
Diagramas de Atividades
 Decisões e condições, como execução paralela, também podem ser
mostrados neste diagrama.
Atividade
 Mostra o fluxo seqüencial das atividades.
FIM
Mostrar mensagem de
erro "Saldo insuficiente"
executarRetirada
INÍCIO
[ valor > (limite + saldo) ]
[ valor < (saldo +limite) ]
Desvio
Efetuar a retirada
do valor solicitado
( valor )
FIM
Impirmir recibo
Retirada
Calcular Saldo
Atual
( saldo )
Condição
de Guarda
Diagramas de Atividades
INÍCIO
adicionar valor em uma nova conta poupanca()
Separação
(execuções
em paralelo)
Recebe Informações do
Depósito
Vincular nova Conta a um
Cliente Cadastrado
Atividade
Atualiza saldo
da Conta
Tornar nova Conta
Poupanca Operacional
FIM
Junção
(junta as
execuções
em paralelo)
Diagramas de Seqüência
 Mostra a colaboração dinâmica entre os vários objetos de um sistema.
 Tipicamente, captura o comportamento de um único caso de uso.
 A partir deste diagrama podemos perceber a seqüência de mensagens
enviadas entre os objetos.
 Descrição :
Consiste em um número de objetos mostrado em linhas verticais.
O tempo é visualizado no sentido vertical de cima para baixo e as
mensagens enviadas por cada objeto são simbolizadas por setas.
Diagramas de Seqüência
: FormularioCliente
: Banco
: Cliente
cadastrarCliente( )
Caso de Uso
Cadastrar Cliente
verificaSeExisteCliente( )
Cria novo
cliente
Diagramas de Seqüência
:
FormularioOperacaoConta
: Banco
: Cliente
: Conta
executarOperacao( )
verificaSeExisteCliente( )
Caso de Uso
Retirar Valor
Conta
Se existir
cliente
Se existir
saldo
efetuarOperacao( )
retirarValor( )
Diagramas de Colaboração
 Um diagrama de colaboração mostra de maneira semelhante ao diagrama
de seqüência, a colaboração dinâmica entre os objetos.
 Além de mostrar a troca de mensagens entre os objetos, percebe-se
também os objetos com os seus relacionamentos.
 Se a ênfase do diagrama for o decorrer do tempo:
diagrama de seqüência
Se a ênfase for o contexto do sistema:
diagrama de colaboração.
 As setas de mensagens são desenhadas entre os objetos para mostrar o
fluxo de mensagens entre eles. As mensagens nomeadas mostram a ordem
em que as mensagens são enviadas.
Diagramas de Colaboração
: FormularioOperacaoConta
2: verificaSeExisteCliente( )
1: executarOperacao( )
Caso de Uso
Adicionar Valor
Conta
: Banco
Se existir
cliente
3: efetuarOperacao( )
: Conta
: Cliente
4: adicionarValor( )
Diagramas de Colaboração
: FormularioConta
2: verificaSeExisteCliente( )
4: criarContaCorrente( )
1: solicitarAnaliseCriarConta(String, String)
Caso de Uso
Criar Conta
<Conta Corrente>
5: definirLimite( )
: Banco
3: verificarExistenciaContaCorrente( )
: Cliente
: Conta
Corrente
Diagramas de Componentes
 Diagramas de Componentes são usados para modelar os aspectos
físicos de um sistema. Descreve os componentes de software e suas
dependências, representando a estrutura do código gerado.
 Componentes são a implementação, na arquitetura física, dos conceitos
e da funcionalidade definidos na arquitetura lógica (classes, objetos e
seus relacionamentos).
 Um componente, tipicamente, é uma versão física de elementos
lógicos, como classes e interfaces. Pode ser utilizado para
representar bibliotecas, objetos COM, Java Beans, código fonte,
esquemas de banco de dados, etc.
 Componentes podem ser executadas em nós (processadores,
dispositivos, etc.)
Diagramas de Componentes
 Um diagrama de componentes mostra apenas componentes como tipos. A
dependência entre componentes é mostrada por uma linha tracejada,
simbolizando que um componente precisa do outro.
 O diagrama de componentes é composto por :
1. Componentes.
2. Pacotes de componentes - representa os grupos de componentes
relacionados.
3. Interfaces - define os métodos visíveis de uma classe ou
componente.
4. Relacionamento de dependência - Exibe quando um componente usa
serviços de outro componente.
Diagramas de Componentes
Nível de
Interface
PackageGuiBanco
Formulario
Operacoes
FormularioCad
astramento
<<Application>>
Banco
PackageNegóciosBanco
<<object>>
ContaCorre
nte
Nível de
Négocios
<<object>>
Cliente
PackageAcessoDadosBanco
DataAcess
Object
Nível de
Dados
Diagramas de Implantação (Utilização/Execução)
 Diagrama de Implentação mostra as relações físicas entre componentes
de software e hardware no sistema implementado.
 É composto de:
1) Componentes de software
2) Nós, objetos físicos que fazem parte do sistema, tais como máquinas
servidoras, máquinas clientes em uma LAN, impressoras, roteadores.
3) Conexões entre nós e componentes que, juntos, compõem toda a
arquitetura física do sistema.
 Mostra a arquitetura do sistema em tempo de execução composta de
seus processadores, dispositivos e componentes de software.
Diagramas de Implantação (Utilização/Execução)
Classs de
Acesso
(Applet)
Classes da
Aplicação
Cliente
A
TCP/IP
TCP/IP
Cliente
B
Servidor
Banco
SQL - TCP/IP
Servidor
Dados
Resumo
A Arquitetura Lógica de um sistema contém a lógica da aplicação. Em
UML os diagramas usados para descrever a arquitetura lógica são:
Os Diagramas de Casos de uso representam uma visão externa
do sistema.
Os Diagramas de Classes mostram a estrutura estática do
sistema.
O Diagrama de Objetos as instâncias dos objetos e seus
relacionamentos em um dado momento.
Diagramas de interação descrevem como os casos de uso são
realizados através das interações entre objetos. Se a ênfase desejada
for o decorrer do tempo usa-se Diagrama de Sequência. Se a ênfase for
o contexto do sistema usa-se o Diagrama de Colaboração.
Resumo
O Diagrama de Estado mostra os estados possíveis de objetos de
uma certa classe e os eventos que provocam tais mudanças.
O Diagrama de Atividades descreve a sequencia de atividades,
com suporte para comportamento condicional e paralelo.
A Arquitetura Física de um sistema apresenta uma descrição dos
componentes de software e hardware. Em UML os diagramas usados para
descrever a arquitetura física são:
O Diagrama de Componentes contém os componentes de
software.
O Diagrama de Implantação mostra a arquitetura em tempo de
execução, ou seja, os computadores, dispositivos etc.