ANP Diagramas UML Profº Henrique Vila Nova Unibratec CTD – 2º Período

ANPDiagramas UML

Profº Henrique Vila NovaUnibratecCTD – 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 “Use-Case"Visão LógicaVisão de ComponentesVisão de ConcorrênciaVisão de Organização

VisãoDiagramaModelo deElementos

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 de Use-Case

Visão Lógica

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.

Bono : Produto

Java : Turma

Estrutura : Turma

Coca Cola : Produto

Maria : Pessoa

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)

Turma

quantidadeAlunoscodigoprofessorquantidadeAlunosMatriculados

adicionarAluno()retirarAluno()

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.

Turma

quantidadeAlunos : intcodigo : Stringprofessor : PessoaquantidadeAlunosMatriculados : int

adicionarAluno()retirarAluno()

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

entry/ fazer depósito inicialdo/ inserir lista de clientesexit/ informar limite disponibilizado

Exemplo de uma Conta :

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.

ContaPoupanca

dataAniversario

calcularJuros()

ContaCorrente

limite

aumentarLimite()

Conta

codigotitularsaldo

adicionarValor()retirarValor()

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çãoEnfermeiro

aplicarInjecao()fazerCurativo()

Profissional Saúde

examinarPaciente()

Medico

realizarCirugia()

Fisioterapeuta

realizarFis ioterapia()

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.

Daniel : Enfermeiro

Dr. Luis : Medico

Dr. Paulo : Medico

fazerCurativo( )

aplicarInjecao( )Diagrama de Seqüência

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”Estrutura

adicionarValor()retirarValor()

mostrarValores()Pilha

adicionarValor()retirarValor()mostrarValores()

Fila

adicionarValor()retirarValor()mostrarValores()

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 UsoDiagramas de ClassesDiagramas de ObjetosDiagramas de EstadoDiagramas de AtividadeDiagramas de SeqüênciaDiagramas de ColaboraçãoDiagramas de ComponentesDiagramas 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çãoAtividade

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.

Retirar Valor Conta

Adicionar Valor Conta

ClienteAluno

Matricular Aluno

Sistema de Matricula Sistema Bancário

ator Caso de usoator 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 usopassivo: 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 é iniciadoO fluxo de mensagens entre atores e casos de usoFluxo 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çõesGeneralização: acrescenta comportamento a casos de

usos baseExtensão: acrescenta comportamento a casos de usos

base, explicando os pontos de extensão


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.


Sistema deMatricula <<extend>>

Aluno

Matricular Alunos Novos

Matricular Aluno Transferido

Matricular Aluno

Pontos de Extensão:Nota no testeFaculdadeAnterior

Sistema Bancário


Só pode teruma conta corrente

Adicionar Valor Conta

Cliente Identificar Conta

<<include>>

Retirar Valor Conta

<<include>>

Cadastar Cliente

Funcionário Banco Verificar Cliente

Verificar Tipo de Conta

Criar Conta

<<include>>

<<include>>

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 Classes1) 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.

Alguns atributos dizem respeito a associações e não a classes.Estes se transformam em classesde Associação.

Cliente Conta

1..*1

Possui

1 1..*

Arquivo Pessoa

0..*0..*

acessivel por

0..*0..*

Autorização

nomeArquivocodigoPessoadataAcesso

permitirAcesso()modificarPermissao()


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.

Uma associação recursiva representa uma associação entre objetos da mesma classe.

Pedido

* 1* 1

Cliente

No

ProximoNo : No0..1

1aponta para

0..1

1

NoDuplo

ProximoNo : NoDuploAnteriorNo : NoDuplo

0..2

1aponta para

0..2

1


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

0..1

cod

1 0..11

cod

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)

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.

Estojo Lapis

*1

contém

*1

AlunoTurma

* *

contém

**

Sistema Linguagem

11

contém

11

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.

JTextField JTextArea JButton

Formulario

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 CalculadoraUsa

1 1

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.

Conta Corrente

Conta Poupanca

Cliente Conta

*1 *1

Banco

0..*

1

0..*

1

0..*

1

0..*

1

Operacao

0..*

1

0..*

1

Diagramas de Classes

Classe deAssociação

Agregações

Associaçãobidirecional

Generalização

SistemaBancário

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

Ana : Cliente

001B1 : Conta Poupanca

001A : Conta Corrente

Um cliente pode ter apenas 1 conta corrente.

001B2 : 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çãoDiagramas de Atividades

Além destes diagramas, o modelo dinâmico pode ser descrito com auxílio dos Diagramas de Estado.

Também chamados de Diagramas de Interação

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

Estado inicial de uma Conta

Estado f inal de uma conta bancária

Abrindo

entry/ vincular a Clienteentry/ definir l imi te

Fechando

entry / zerar saldoexit/ desv incular cliente da conta

Operando

do/ adicionar Valor Conta (depósitos)do/ retirar Valor Conta (retiradas)exi t/ informar Saldo

FIM

ef etuar operação( t ipo da operacao )[ saldo+limite >0 ]

solicitar encerramento da conta pelo cliente

INÍCIO

solicitar criação conta corrente

encerrar conta[ saldo=limite ]

ef etuar operação( t ipo operacao ) / saldo=0

Evento Ação de Transição

Argumentos

Condição de Guarda

Estado

Atividade

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.


Decisões e condições, como execução paralela, também podem ser mostrados neste diagrama.

Mostra o fluxo seqüencial das atividades.

Efetuar a retirada do valor solicitado

[ valor < (saldo +limite) ]

Mostrar mensagem de erro "Saldo insuficiente"

[ valor > (lim ite + saldo) ]

FIM

INÍCIOexecutarRetirada

Calcular Saldo Atual

( valor )

Impirmir recibo Retirada ( saldo )

FIM

Atividade

Desvio

Condição de Guarda


Atividade

Separação(execuções

em paralelo)

INÍCIO

Vincular nova Conta a um Cliente Cadastrado

Recebe Informações do Depósito

Tornar nova Conta Poupanca Operacional

Atualiza saldo da Conta

FIM

adicionar valor em uma nova conta poupanca()

Junção(junta as execuçõesem 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.


Caso de Uso Cadastrar Cliente

: FormularioCliente : Banco : Cliente

cadastrarCliente( )

verificaSeExisteCliente( )

Cria novo cliente


Caso de Uso Retirar Valor

Conta

: FormularioOperacaoConta

: Banco : Cliente : Conta

executarOperacao( )

verificaSeExisteCliente( )

efetuarOperacao( )

Se existir cliente

retirarValor( )

Se existir saldo

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.


: FormularioOperacaoConta

: Banco

: Cliente : Conta

2: verificaSeExisteCliente( )

Se existir cliente

1: executarOperacao( )

3: efetuarOperacao( )

4: adicionarValor( )

Caso de Uso Adicionar Valor

Conta


Caso de Uso Criar Conta

<Conta Corrente>

: FormularioConta

: Banco

2: verificaSeExisteCliente( )

: Cliente

4: criarContaCorrente( )

: Conta Corrente

1: solicitarAnaliseCriarConta(String, String)

3: verificarExistenciaContaCorrente( )

5: definirLim ite( )

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.)


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.


ContaCorrente

<<object>>Cliente<<object>>

Banco<<Application>>

FormularioCadastramento

DataAcessObject

PackageGuiBanco

PackageNegóciosBanco

PackageAcessoDadosBanco

FormularioOperacoes

Nível de Interface

Nível de Négocios

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 software2) 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)

Cliente B

Cliente A

Servidor Banco

TCP/IP

TCP/IP

Classs de Acesso (Applet)

Classes da Aplicação

Servidor DadosSQL - TCP/IP

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.

Documents

ANP Diagramas UML Profº Henrique Vila Nova Unibratec CTD – 2º Período