A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Modelagem de Sistemas Orientada a Objeto Com UML

Apresentações semelhantes


Apresentação em tema: "Modelagem de Sistemas Orientada a Objeto Com UML"— Transcrição da apresentação:

1 Modelagem de Sistemas Orientada a Objeto Com UML

2 Diagramas da UML Diagramas de casos de uso Diagramas de estrutura
Diagramas, descrições e modelos de objetos. Diagramas de estrutura Diagramas de classe e de objeto. Diagramas de interação Diagramas sequenciais e de colaboração. Diagramas de estado Diagramas de mudanças de estado e de atividades. Diagramas de implementação Diagramas de pacotes, de componentes e de desdobramento.

3 Relação entre os diferentes diagramas da UML
Diagramas de estado Diagramas de implementação Especificação de Requisitos Diagramas de classe Diagrama de caso de uso Cartões CRC Diagramas de interação

4 Especificação de Requisitos
Cenários descrevem passo a passo exemplos específicos de uso do sistema. Os nomes e verbos utilizados na construção do cenário frequentemente definem classes e operações, respectivamente. Ex.: O cliente navega no catálogo de itens e adiciona itens desejados à sua cesta de compras. Quando o cliente deseja pagar, descreve o endereço de entrega, fornece as informações do cartão de crédito e confirma a venda. O sistema verifica a autorização do cartão de crédito e confirma a venda imediatamente e envia um logo a seguir. O exemplo de cenário mostrado é uma das possíveis alternativas que pode m acontecer. Por exemplo, se a autorização do cartão de crédito falhar, teremos outro cenário. Um caso de uso, então, é um conjunto de cenários amarrados por um objetivo comum. No exemplo temos o caso de uso Compras com uma compra bem sucedida e uma falha da autorização do cartão de crédito, como dois cenários do caso de uso.

5 Diagrama de casos de uso
Diagrama de caso de uso define processos genéricos que o sistema deve estar capacitado para realizar e as interações entre os processos e sistemas externos ou pessoas (atores). As descrições dos casos de uso definem cenários genéricos.

6 Cartão CRC Cartões de Classes, Responsabilidades e Colaboradores proporcionam aos usuários e desenvolvedores um modo para identificar classes, atributos e mensagens, trabalhando com cenários. Nome da classe Descrição da função da classe Atributos Nome da classe Responsabilidades: são operações e conhecimento que o sistema mantém. Uma responsabilidade é usualmente apresentada com uma frase curta. Deve incluir um verbo. Ex.: submeter um pedido; verificar se um determinado item está no estoque; verificar o limite de crédito de um cliente; conhecer quais clientes tem limite de crédito acima de $10.000,00. Colaboradores: são outras classes usadas para cumprir uma responsabilidade específica. Ex.: um vendedor precisaria colaborar com a classe “autorização” para verificar o limite de crédito do cliente. Cada responsabilidade pode estar associada de nenhuma a vários colaboradores. Um mesmo colaborador pode ser associado com mais de uma responsabilidade. Como os atributos descrevem valores que um objeto de uma classe pode ter e armazenar, então, a classe “autorização” deverá incluir o atributo limite de crédito do cliente. Super classes Subclasses Responsabilidades Colaboradores (operações) (associações entre classes)

7 Cartão CRC Exemplos Vendedor Pessoa que submete pedidos de clientes.
Documento (eletrônico) submetido por um vendedor contendo informações sobre o cliente e os itens desejados. Cliente Uma empresa ou indivíduo que busca comprar algum produto e/ou obter crédito. Sistema de contabilidade Fonte de informações sobre a disponibilidade de crédito de clientes potenciais. Inventário Fonte de informações sobre a disponibilidade de itens dos produtos oferecidos, prazo de entrega, ... Responsabilidades: são operações e conhecimento que o sistema mantém. Uma responsabilidade é usualmente apresentada com uma frase curta. Deve incluir um verbo. Ex.: submeter um pedido; verificar se um determinado item está no estoque; verificar o limite de crédito de um cliente; conhecer quais clientes tem limite de crédito acima de $10.000,00. Colaboradores: são outras classes usadas para cumprir uma responsabilidade específica. Ex.: um vendedor precisaria colaborar com a classe “autorização” para verificar o limite de crédito do cliente. Cada responsabilidade pode estar associada de nenhuma a vários colaboradores. Um mesmo colaborador pode ser associado com mais de uma responsabilidade. Como os atributos descrevem valores que um objeto de uma classe pode ter e armazenar, então, a classe “autorização” deverá incluir o atributo limite de crédito do cliente.

8 Modelo de Objetos Ideais
O modelo de objetos ideais, criado por Jacobson (OOSE, Object Oriented Software Engineering), define três tipos de classes de acordo com a abrangência de cada uma (classes de interface; classes de entidade, classes de controle).

9 Diagramas de estrutura Diagramas de classe (1)
O diagrama de classe descreve as classes, suas associações com outras classes (responsabilidades) e relacionamento de herança.

10 Diagramas de estrutura Diagramas de classe (2)
O diagrama de classe pode descrever de forma mais complexa os atributos e as operações das classes.

11 Diagramas de estrutura Diagramas de objetos
O diagrama de objetos é usado para explorar problemas específicos em determinadas classes.

12 Diagramas de interação
O diagrama de interação é um modelo que descreve como grupos de objetos colaboram em algum comportamento. O diagrama de interação captura o comportamento de um único caso de uso. Exibe vários objetos e as mensagens que são trocas entre eles em um caso de uso. Existem dois tipos de diagramas de interação: diagramas de sequência e diagramas de colaboração.

13 Diagramas de interação Diagrama de sequência
O diagrama de sequência mostra o fluxo de mensagens (eventos) entre objetos. Proporciona um modo formal para especificar um cenário. Os objetos são mostrados como caixas na parte superior de uma linha tracejada. A barra vertical é chamada de linha da vida do objeto e representa a vida do objeto durante a interação. Cada mensagem é representada por um vetor entre as linhas de vida de dois objetos. A ordem na qual as mensagens ocorrem é mostrada da parte superior à parte inferior do diagrama. Existem ainda as autochamadas, uma mensagem que o objeto chama para si mesmo.

14 Janela entrada de Pedido
Diagrama de sequência Janela entrada de Pedido Um Pedido Uma Linha de Pedido prepare() *prepare() temEstoque:= verificar() [temEstoque] retirar() precisaReposição:= precisaRepor() Um item de reposição Um item de entrega [temEstoquenovo] [precisaReposição]

15 Diagramas de interação Diagrama de colaboração
O diagrama de colaboração é uma combinação de objetos e sequência de diagramas. Ele mostra o fluxo de eventos entre objetos. Os objetos são representados por retângulos com seus nomes (de objeto ou classe). Se apropriado, coloca-se também os atributos associados. Linhas conectam os objetos (mensagens), com denominações indicando as operações (cada operação é precedida por um número sequencial para indicar a ordem de execução. Um vetor após ou ao lado do nome da operação indica a direção do fluxo (a operação sempre é executada onde reside, o vetor aponta a origem da operação).

16 Diagrama de colaboração
:Janela de Entrada de Pedido :Pedido linhaMacau:LinhaDePedido :ItemDeEntrega estoqueMacau: ItemDeEstoque :ItemDeReposição 1:prepare() 2*[para todas as linhas do pedido] :prepare() 7:[temEstoque]:novo 6:[precisaReposição]:novo 3:temEstoque: +verificar() 4:[temEstoque]:= remover() 5:precisaReposição:= precisaRepor

17 Diagramas de estado Estado se refere a um conjunto de valores quer descrevem um objeto num determinado instante. Em outras palavras, um objeto é determinado pelos valores associados aos seus atributos. Diagramas de estado são chamados também de diagramas de transição de estado. Exibe em detalhes o comportamento de um objeto. O diagrama de estado mostra todos os valores (estados) que o atributo de um objeto pode assumir quando mensagens (eventos) são processadas. Diagramas de estado são mais úteis para classes cujas instâncias são muito dinâmicas. O motor (objeto) está funcionando (estado). A fatura (objeto) está paga (estado). Fernanda (objeto) está trabalhando (estado). O veículo (objeto) está parado (estado). Ver notação para super-estado e para subestado simultâneo e subestado sequencial.

18 Pedido não pode ser atendido no memento
Diagramas de estado (1) Registrando pedido Alterando pedido Cancelando pedido Analisando pedido Aprovando pedido Colocando pedido Atendendo pedido Pedido enviado Alteração de pedido Cancelamento de pedido Pedido para análise Pedido para aprovação Pedido será cancelado Pedido cancelado Pedido atendido Pedido não pode ser atendido no memento Pedido já pode ser atendido Pedido será atendido

19 Diagramas de estado (2) Subestado simultâneo
Selecionando itens de carga Preparando despacho de mercadoria Emitindo romaneio Montando carga Itens selecionados Carga montada Romaneio emitido Subestado sequencial Analisando crédito Fechamento do negócio Negociando condição Analisando itens de compra Crédito Ok Negócio fechado Itens analisados

20 Diagramas de atividades
O diagrama de atividades mostra todas as atividades que provocam mudanças de valores em um objeto. Diagramas de atividades são usados para capturar o fluxo de trabalho (“workflow”) ou a sequência de decisão em um processo. Na UML, atividades são chamadas de estados, então, o diagrama de atividades está associado ao diagrama de estado. Num diagrama de atividade, os estados são normalmente atividades limitadas no tempo. Eventos geralmente estão associados às transições. Diagrama de estado focaliza os eventos que ocorrem para um determinado objeto. Diagrama de atividades podem ser usados para modelar todo um processo de negócio ou proporcionar uma visão global do que está acontecendo dentro de um caso de uso. Atividades podem representar um conjunto (ou módulo) de diferentes classes. Uma atividade descreve o desempenho de uma tarefa e não está diretamente relacionada a objetos.

21 Diagrama de atividades
Receber pedido Receber pagamento Preencher pedido Enviar fatura Entregar urgente Entregar normal Fechar pedido Desvio/Decisão Intercalação Separação Junção

22 Diagramas de implementação
Diagramas de implementação mostram decisões sobre o design e a arquitetura do sistema. Existem três tipos: Diagramas de pacotes: permitem que os desenvolvedores mostrem como as classes podem ser subdivididas em módulos. São diagramas lógicos e não necessariamente implicam em uma divisão física das classes. Diagramas de componentes: são usados para mostrar os módulos físicos que um desenvolvedor deve utilizar. Diagramas de desdobramento: permitem que os desenvolvedores modelem a plataforma física e a rede que será utilizadas pela aplicação. A arquitetura física do sistema deve responder às seguintes questões: a) Quais computadores e outros dispositivos de hardware estão envolvidos no processamento do sistema e como estão conectados entre si? b) Em quais computadores as classes e seus respectivos objetos estão fisicamente localizados? c) Quais são as dependências entre diferentes arquivos de código? d) Se um arquivo específico é alterado, quais outros arquivos têm de ser recompilados?

23 Diagrama de pacotes IU Processamento Mala Direta de Pedido AWT
Aplicação AWT Mala Direta Pedidos Clientes O diagrama de pacotes mostra os pacotes de classes e as dependências entre eles. Existe dependência entre dois elementos se mudanças na definição de um elemento pode causar mudanças ao outro. De modo restrito, um diagrama de pacotes é simplesmente um diagrama de classes que mostra apenas pacotes e dependências. Nas classes as dependências são marcadas por: troca de mensagens de uma classe para outra, uma classe tendo outra como parte integrante de seus dados, uma classe fazendo menção a uma outra como um parâmetro de operação.

24 Diagrama de componentes
Cobrança.exe Registro.exe Curso.dll Pessoa.exe Curso.cls Curso_ Oferecido.cls Aluno.cls Professor.cls Diagrama de componentes mostra os módulos existentes do software integrados ao sistema final. Frequentemente, são os mesmos que aparecem no diagrama de pacotes. Mostra os vários componentes em um sistema e suas dependências. Um componente representa um módulo físico do código. As dependências mostram como mudanças em um componente pode causar mudanças em outros componentes.

25 Diagrama de desdobramento
Notebook Vendedor Pacote 1 Módulo de Vendas Cliente Sistema de Vendas Servidor Internet Pacote 2 Gestão de Vendas Pacote 3 Interface para banco de dados Várias plataformas (Intel/Windows; Apple/MacOS) Sistema de contabilidade Sistema de inventário Rede corporativa Novell Network/SQL SUN Solaris/UNIX Diagrama de desdobramento mostra a plataforma existente (nós) e as conexões de rede (“links”) usadas pela aplicação. Em outras palavras, mostra as relações físicas entre os componentes de software e hardware do sistema. É também chamado de diagrama de utilização.


Carregar ppt "Modelagem de Sistemas Orientada a Objeto Com UML"

Apresentações semelhantes


Anúncios Google