Projeto de Software Orientado a Objetos

Professora: Aline Vasconcelos

Cefet Campos

aline.vasconcelos@terra.com.br

2

Roteiro

Da Análise para o Projeto Atividades do Projeto OO Atribuição de Responsabilidades às Classes Diagramas de Seqüência

 

3

Da Análise para o Projeto Durante a Análise, o foco do desenvolvimento estava na investigação e representação do

conhecimento sobre o problema, enfocando questões do tipo: “O que?”, “Quais?”: Que funcionalidades o sistema deve oferecer?

Quais são os conceitos do domínio?

Na fase de Projeto, o foco passa a ser no “Como?”, onde se busca uma solução computacional para o problema especificado. Nesta fase, as seguintes questões devem ser respondidas:

Como implementar as funcionalidades definidas?

Como atender aos atributos de qualidade (desempenho, portabilidade, etc.) do sistema?

Que tecnologia/plataforma é mais adequada para atender aos requisitos do sistema?

 

4

Projeto de Software

Primeira das três atividades que compõem o núcleo técnico do desenvolvimento de software:

=> projeto, codificação e testes.

Enquanto na Análise trabalhamos no “espaço problema” (ou no domínio do problema), no Projeto trabalhamos no “espaço solução” (ou domínio da solução).

 

5

Projeto de Software Orientado a Objetos: Atividades

Atribuição de Responsabilidades às Classes Definição da Arquitetura da Aplicação

Seleção da Tecnologia/Plataforma a ser utilizada na Implementação do Sistema

Projeto das Interfaces do Sistema

• Interfaces Gráficas de Usuário – GUI

• Interfaces com Sistemas e Dispositivos Externos

 

6

Projeto de Software Orientado a Objetos: Atividades

Projeto de Banco de Dados• Para Bancos de Dados Relacionais, esta atividade requer o

mapeamento do Diagrama de Classes para o Modelo Relacional (Mapeamento Objeto-Relacional)

Refinamento do Diagrama de Classes de Alto Nível (Modelo Conceitual) em um Diagrama de Classes de Projeto, acrescentando-se características de projeto (como navegabilidade, métodos, tipos de atributos, etc.) e classes técnicas (classes de interface, persistência, etc.)

 

7

Atribuição de Responsabilidades às Classes

Iniciaremos o Projeto OO pela elaboração dos Diagramas de Interação, o que requer uma adequada atribuição de Responsabilidades às Classes do Software.

Segundo LARMAN (2000):

– Os diagramas de interação são um dos mais importantes artefatos criados no projeto OO.

– A atribuição habilidosa de responsabilidades é muito importante.

 

8

Responsabilidades O que é Responsabilidade?

– Um contrato ou obrigação de um tipo ou classe.

Responsabilidades definem o comportamento do objeto!

Há basicamente dois tipos de Responsabilidades:– Fazer

• O objeto faz algo ele próprio. • O objeto inicia ações em outros objetos. • O objeto controla e coordena atividades em outros objetos.

– Conhecer• O objeto conhece e gerencia os seus dados privados encapsulados. • O objeto conhece objetos relacionados. • O objeto conhece coisas que ele pode derivar ou calcular.

 

9

Atribuição de Responsabilidades às Classes

– A atribuição de responsabilidades influencia na manutenibilidade e reusabilidade de uma classe.

– Responsabilidades bem distribuídas => Classes Coesas => Classes com Baixo Acoplamento

Avaliação da Modularidade em Projeto:– Acoplamento: grau de interdependência entre dois módulos. Deve ser baixo!– Coesão: grau de relacionamento entre as tarefas realizadas por um módulo.

Deve ser alto!

 

10

Diagramas de Interação: Reflete as interações, ou seja, trocas de

mensagens, entre objetos;

Enquanto o Diagrama de Classes é estático, o de Interação é dinâmico: reflete as ações executadas no sistema;

Casos de uso são traduzidos através dos diagramas de Interação . Nos diagramas de Interação é que são mostradas as operações que o sistema executa para realizar o caso de uso.

11

Diagramas de Modelagem Dinâmica:

A UML apresenta Diagramas para a Modelagem de Aspectos Dinâmicos de um Sistema. São eles:

Diagramas de Interação: Seqüência e Colaboração;

Diagrama de Estado;

Diagramas de Atividades.

12

Interações:

Uma interação é uma especificação comportamental que mostra trocas de mensagens entre objetos para a execução de uma tarefa , como a realização de um caso de uso, por exemplo.

Mensagens representam chamadas de método. Dentro do código de uma operação há uma chamada para a execução de outra operação.

13

Envio de Mensagem: Deve ser mostrada como uma seta do

objeto que contém a operação chamadora (sender ou emissor) para o objeto que contém a operação chamada(receiver ou receptor).

Obter o Título()

14

Diagramas de Interação:

A UML apresenta dois tipos de Diagramas de Interação: Diagrama de Seqüência e Diagrama de Colaboração.

Diagramas de Seqüência enfatizam a ordenação temporal das mensagens.

Diagramas de Colaboração enfatizam a organização espacial dos objetos que enviam e recebem mensagens.

15

Caso de Uso: Informar Total de Pedido

Fluxo de Eventos Principal:1. O Caixa solicita ao sistema o total de um pedido

já registrado.

2. O sistema calcula o total do pedido, calculando o total de cada item e somando.

3. Para calcular o total de cada item, o sistema multiplica a quantidade vendida do item pelo preço do produto.

4. O sistema apresenta o total na tela.

: Caixa

umaguiPedido : GUIPedido

umItem : ItemPedido

umProduto : Produto

umPedido : Pedido

1: obterTotalPedido( )

2: calcularTotal( )

3: calcularTotalItem( )*4: getPreco( )

Exemplo de Diagrama de Seqüência:

17

Notação do Diagrama de Seqüência:

A ordem das mensagens é mostrada da parte superior à parte inferior do diagrama, na vertical.

Os objetos são mostrados no topo do diagrama na horizontal.

A Linha Vertical é chamada de linha de vida do objeto. Ela representa a vida do objeto durante a interação.

18

Notação do Diagrama de Seqüência:

Mensagens são representadas por flechas entre as linhas de vida de dois objetos. Apresentam a assinatura do método ou operação chamada.

Obs.: a assinatura engloba o nome do método, os parâmetros recebidos com seus tipos, o tipo de retornoe a visibilidade.Ex: Na Classe Pedido:

public double calcularTotal(); public static double calcularTotal(int ano);

19

Notação do Diagrama de Seqüência:

Uma autochamada (“mensagem para self”) representa uma mensagem que um objeto envia para si mesmo, remetendo a seta de mensagem de volta para a mesma linha de vida.

Ex: : Pedido : ItemPedido

1. 1.1.

20

Notação do Diagrama de Seqüência:

Caixa de ativação mostra o tempo de ativação do objeto para a execução de uma operação. Para uma interação procedimental, isto indicaria que o procedimento é o que está na vez na pilha do processador.

Ex: : Pedido : ItemPedido : Produto

1. 1.1.

2. 2.1.

21

Notação do Diagrama de Seqüência:

Condição de guarda (ou somente condição): indica uma condição para o envio de uma mensagem. A mensagem é enviada somente se a condição for verdadeira. Representada entre colchetes.

Um asterisco representa um marcador de iteração, que mostra que a mensagem é enviada várias vezes para múltiplos objetos receptores. É possível ainda escrever: *[para todos os itens de pedido]

: Caixa

umaguiPedido : GUIPedido

umItem : ItemPedido

umProduto : Produto

umPedido : Pedido

1. obterTotalPedido( )

1.1. calcularTotal( )

1.1.1. calcularTotalItem( )*1.1.1.1. getPreco( )

[pedido está pronto]

Exemplo de Diagrama de Seqüência com Condição e Iteração:

23

Notação do Diagrama de Seqüência:

Retorno são representados através de linhas tracejadas. Somente deve ser representado para acrescentar clareza ao diagrama.

Objetos são representados na parte superior do Diagrama. Escreve-se o objeto: nome da classe, tudo sublinhado. – Ex:

obj1: C1

24

Notação do Diagrama de Seqüência:

Criação de objetos podem ser representadas colocando-se a seta que contém a mensagem de criação apontando para o objeto diretamente. – Representação:

obj2: C2

obj1: C1

Criar()

25

Notação do Diagrama de Seqüência :

Destruição de Objetos: representada através de um x.

obj2: C2obj1: C1

op1()

destruir()

26

Condição com Ramificação

Condicional: uma condicional é indicada dividindo uma seta de mensagem em dois objetivos paralelos e, tal como em máquinas de estado finitas, em qualquer ponto de ramificação as expressões condicionais não devem ser ambíguas.

obj1: C1 obj2: C2 obj3: C3

[x > 0]op1()

[x < = 0] op2()