Modelagem de Sistemas Orientada a Objeto Com UML

Slides:



Advertisements
Apresentações semelhantes
Especificações de Casos de Uso e Regras de Negócio
Advertisements

Análise e Projeto Orientado a Objetos
Análise e Desenvolvimento de Sistemas
Requisitos de Software
Engenharia de Software
APSOO Aula 03.
APSOO Aula 05.
UML Modelando um sistema.
UML Visões – Parte 2.
(Unified Modeling Language)
Diagrama de Classes.
Análise e Projeto de Sistemas I
DIAGRAMA DE ESTADOS DIAGRAMA ESTADO TRANSIÇÃO ENTRE ESTADOS.
Linguagens de Modelagem para SMA
UML Diagrama de Classes elementos básicos. Contexto Os diagramas de classes fazem parte do da visão estática da UML. Os elemento desta visão são conceitos.
Projeto de Software Orientado a Objetos
Modelo de Arquitetura Diagrama de Componentes
Modelagem de Sistemas de Informação
Modelagem de Interações
Diagrama de Estados.
Diagramas de Sequência e Comunicação
Especificação de Requisitos de Software com Casos de Uso
Análise de Sistemas Análise e Projeto Prof. Jeime Nunes Site:
Introdução UML, Diagrama de Classes e Comunicação/Colabaração
Diagramas de Colaboração e Componentes
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB 12. Estados Objetivo: compreender a notação do diagrama de estados.
Arquitetura Orientado a Serviços
Análise e Projeto de Sistemas
Fase de Elaboração: Fluxo de Análise Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
MODELO ESSENCIAL Modelo Ambiental
Diagramas de Atividade
UNIDADE 2 UML MODELAGEM TEMPORAL
Fase de Concepção (Início, Planejamento)
Educação Profissional Técnica de Nível Médio Curso Técnico de Informática Disciplina: Interpretação de Projetos de Software Professor: Cheli dos S. Mendes.
Modelagem de processos de negócio com Diagrama de Atividades
Modelagem de processos de negócio com Diagrama de Atividades
UML - Unified Modeling Language
Análise Orientada Objeto
Analisar Caso de Uso 10/04/ /04/2017 Analisar caso de uso
Unified Modeling Language Professor Mário Dantas A NÁLISE O RIENTADA A O BJETOS Nov/2010.
Diagramas de Estado.
Laboratório de Programação
Revisão 2º Bimestre Engenharia de Software I
Diagrama de Colaboração. Diagramas de Interação Expressam informações bastante similares porém de maneira diferente Diagrama de seqüência: – Interação.
Análise e Projeto de Sistemas
Modelando Sistemas em UML
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
Abr-17 Analisar Caso de Uso Analisar caso de uso.
UML INTRODUÇÃO CEÇA MORAES 14/04/2017.
Tarciane Andrade Análise de Casos de Uso Tarciane Andrade
Modelo de Análise e Projeto
Análise de Casos de Uso Rafael Duarte Alexandre Mota [rmd,
Engenharia de Software e Sistemas
UML Statechart CIn-UFPE.
Análise e Projeto de Sistemas
A linguagem unificada de modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
CIn-UFPE1 UML Uma linguagem unificada de modelagem Visão Geral.
Professora: Kelly de Paula Cunha
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Engenharia de Software com o RUP - Workflow de Requisitos
Interações entre objetos
Fundamentos de Engenharia de SW Diagramas da UML Usados no Projeto de Software.
UML (Unified Modeling Language) A linguagem unificada de modelagem
Analisar Caso de Uso. Copyright © 2006 Qualiti. Todos os direitos reservados. Qualiti Software Processes Análise e Projeto OO com UML e Padrões| 2 Objetivos.
Diagrama de atividade.
Analisar Caso de Uso. Copyright © 2002 Qualiti. Todos os direitos reservados. Qualiti Software Processes Analisar caso de uso | 2 Objetivos deste módulo.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
Análise e Design de Software Site:
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Transcrição da apresentação:

Modelagem de Sistemas Orientada a Objeto Com UML

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.

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

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 e-mail 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.

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.

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)

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.

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

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.

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.

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

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.

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.

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]

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

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

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.

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

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

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.

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

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?

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.

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.

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.