Projeto de Software - Universidade Federal do Paraná · processo de projeto para que sobre tempo suficiente no final para ... Revisar o diagrama através de regras de projeto e acrescentar

Projeto de Software

Silvia Regina Vergilio - UFPR

1) Objetivos

Modelos de representação do domínio (análise)

⇓ Técnicas e princípios

Detalhe suficiente para permitir a realização física do sistema (implementação)

2) Importância Fase na qual a qualidade é criada

e poderá ser efetivamente avaliada.

Servirá como fundamento para as fases de codificação, teste e manutenção.

2) Importância

2) Importância

“ ... tentamos resolver o problema passando rapidamente pelo processo de projeto para que sobre tempo suficiente no final para detectar e corrigir defeitos que foram introduzidos porque dedicamos pouco tempo ao projeto.”

3) Fundamentos (Princípios)

1. Refinamento (análogo ao princípio do particionamento) – decomposição

2. Arquitetura do software: um problema P pode ser solucionado por muitas estruturas candidatas


________________


3) Fundamentos (Princípios) Módulo que controla um módulo:

superior Módulo controlado por outro:

subordinado Largura – abertura (amplitude) da

estrutura Profundidade – número de níveis

de controle

3) Fundamentos (Princípios) Fan-out: número de módulos

controlados por um dado módulo Fan-in: número de módulos que

controlam um dado módulo

Visibilidade – conjunto de componentes invocados ou utilizados até mesmo indiretamente

Conectividade: conjunto de componentes diretamente invocados ou utilizados


3. Modularidade: característica do software que permite a sua inteligibilidade, permite dividí-lo em componentes menores, chamados módulos.

3) Fundamentos (Princípios)3. Modularidade: Leva a um esforço menor

para resolver problemas C(x)=complexidade do problema E(x)=esforço para resolver o problemaC(P1) > C(P2) E(P1) > E(P2)C(P1+P2) >C(P1)+C(P2) E(P1+P2)>E(P1) + E(P2)

Como saber se eu dividi o suficiente?

3) Fundamentos (Princípios)4. Abstração – diferentes níveis

5. Ocultamento da Informação: princípio que diz que módulos devem ser especificados e projetados de modo que a informação (dados ou procedimento) nele contida seja inacessível a outros módulos que não tenham necessidade daquela informação

3) Fundamentos (Princípios) Coesão e Acoplamento

Baseadas nos princípios de um bom projeto: (Yourdon, Constantine e Myers)

Coesão: medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica

Acoplamento: mede o grau de interdependência entre módulos

3) Fundamentos (Princípios) Coesão e Acoplamento

3) Fundamentos (Princípios) Coesão (Deve ser alta) coincidente: o módulo realiza funções

não relacionadas

lógica: as funções estão relacionadas logicamente

temporal: o módulo realiza mais que uma função que devem ocorrer no mesmo intervalo de tempo

3) Fundamentos (Princípios) Coesão procedimental: o módulo realiza mais que

uma função, de tal forma que elas estão relacionadas a um procedimento geral

comunicacional: o módulo realiza funções que manipulam a mesma estrutura de dados

funcional: o módulo realiza uma única função bem definida

3) Fundamentos (Princípios) Acoplamento (Deve ser baixo) acoplamento por conteúdo: x faz

referência direta ao interior de y

acoplamento por common: x e y referenciam variáveis globais

acoplamento por controle: x e y se comunicam por parâmetros sendo que um deles é um flag que controla o comportamento de um dos módulos

3) Fundamentos (Princípios) Acoplamento acoplamento por carimbo ``stamp'': x e

y se comunicam por parâmetros, sendo um deles, uma estrutura de dados

acoplamento por dados: x e y se comunicam por parâmetros

sem acoplamento: não existe dependência

3. Tipos de MódulosQuanto ao tempo de incorporação macro – incluído em tempo de

compilação subrotina ou procedimento –

geração da seqüência de chamadas pelo compilador e posterior ligação.

ligação dinâmica – em tempo de execução.

3. Tipos de Módulos

Quanto aos mecanismos de ativação referência – chamada de sub-

programa interrupção – programa em

execução é interrompido para execução de outro módulo


Quanto ao padrão de execução módulos convencionais – um ponto

de entrada e um de saída, execução sequencial e completa

módulos reentrantes – não possui dados locais, mais de um ponto de entrada, usado simultaneamente por mais de uma tarefa (compartilhados)


Quanto ao relacionamento com outros módulos

módulo sequencial – referenciados e executados sem interrupção

módulo incremental (corotinas) – pode ser interrompido antes do seu término e posteriormente reiniciado


Quanto ao relacionamento com outros módulos

módulo paralelo (conrotinas) – executados simultaneamente com outros módulos em ambientes concorrentes

4) Principais Atividades Projeto da Arquitetura

do sistema do controle dos módulos

Projeto dos Dados Projeto dos Procedimentos Projeto da Interface com outros

Elementos do Sistema Projeto da Interface com o Usuário

5) Passos Projeto Geral ou Preliminar:

fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos

Projeto Detalhado: refinamento visando à codificação e especificação dos programas

6) Modelos de Projeto GeralOs modelos de projeto geral devem: especificar a decomposição do sistema

em sub-sistemas (modelo da arquitetura do sistema)

mostrar o relacionamento entre os sub-sistemas (modelo de controle do sistema)

decompor os sub-sistemas em módulos (modelo da arquitetura dos módulos)

7) Modelo da Arquitetura do Sistema Descreve o sistema como um

conjunto de sub-sistemas que fornecem um conjunto de serviços específicos.

Modelos que descrevem como eles compartilham dados, como eles estão distribuídos e como é a interface entre eles.

7) Modelo da Arquitetura do Sistema –Modelo Centralizado Supõe a existência de uma base

de dados central à qual todos os subsistemas têm acesso

7) Modelo da Arquitetura do Sistema –Modelo Centralizado

7) Modelo da Arquitetura do Sistema –Modelo Distribuído Cada sub-sistema mantém sua própria

base de dados Dados são trocados através dos sub-

sistemas através de mensagens mais eficiente para gde quantidade de dados maior facilidade para integrar um novo sub-

sistema permite diferentes políticas de backup,

recuperação, etc

7) Modelo da Arquitetura do Sistema –Modelo Distribuído Problemas

distribuir informações pode provocar redundância e inconsistência

esquemas eficientes de comunicação são necessários, recuperação, etc

Modelo de arquitetura cliente-servidor: O modelo + conhecido

7) Modelo da Arquitetura do Sistema– Cliente-Servidor Mostra como se dá a distribuição dos

serviços através dos sub-sistemas Composto de:

um conjunto de servidores: oferecem serviços específicos. Ex: servidores de impressão, compilação, etc.

um conjunto de clientes: que utilizam os serviços (podem ser várias instâncias de um mesmo cliente)

uma rede de comunicação A arquitetura três-camadas: + utilizada

7) Modelo da Arquitetura do Sistema– Cliente-Servidor

7) Modelo da Arquitetura do Sistema– Cliente-Servidor

8) Modelo de Controle do Sistema

Especificam as relações de controle entre os sub-sistemas

Controle centralizado: um sub-sistema é responsável por controlar, iniciar e parar os outros sistemas

Controle baseado em eventos: Cada sub-sistema pode responder a eventos externos ou originados no próprio sistema

8) Modelo de Controle do Sistema Controle Centralizado

Exemplo1:

Exemplo2:

--------------------------------------------------------

8) Modelo de Controle do Sistema - Baseado em Eventos

8) Modelo de Controle do Sistema - Baseado em Eventos

9) Diagrama de Pacotes da UML

Um pacote é um conjunto de elementos agrupados. Esses elementos podem ser classes, diagramas, ou até mesmo outros pacotes.

9) Diagrama de Pacotes da UML

9) Diagrama de Pacotes da UML – Modelo Três Camadas

Apresentação: janelas, relatórios Aplicação: registrar vendas, autorizar

pagamentos Armazenamento: BD

1. Pode-se separar a camanda da aplicação em diferentes componentes a serem reutilizados

2. Diferentes equipes para o desenvolvimento3. Camadas distribuídas em um sistema

cliente servidor aumentam desempenho

9) Diagrama de Pacotes da UML – Modelo Três Camadas

9) Diagrama de Pacotes da UML – Camada do Domínio

9) Diagrama de Pacotes da UML – Exemplo

9) Diagrama de Pacotes da UML – Padrões para construirPadrão Domínio-Apresentação

Separados (Modelo-Visão Separados)

Problema: Separar apresentação da camada do domínio para aumentar reuso e diminuir impacto de mudanças.

Solução: As classes da apresentação não mantêm dados, apenas realizam E/S, acoplamento mínimo de objetos do domínio com janelas da apresentação.

9) Diagrama de Pacotes da UML – Padrões para construir

10) Modelo da Arquitetura dos Módulos Especifica a decomposição de cada sub-

sistema em módulos Orientados a funções: os sub-sistemas são

decompostos em módulos funcionais que recebem dados e transformam estes dados em saída (ex:diagrama hierárquico de funções)

Orientado a objetos: os sub-sistemas são decompostos em um conjunto de objetos que se comunicam para resolver o problema (ex:diagramas de interação -UML)

11) Diagrama Hierárquico de Funções - DHF É obtido a partir do DFD e representa

como os módulos (processos/bolhas) são organizados a fim de compor a solução

Também representa controle – hierarquia

11) Diagrama Hierárquico de Funções - DHF

11) Diagrama Hierárquico de Funções - DHF

11) Diagrama Hierárquico de Funções(DHF) Como construir

São três passos1. Identificar a categoria do fluxo de

informação transformação ou transação

2. Revisar DFD´s e mapeá-los para o DHF

3. Revisar o diagrama através de regras de projeto e acrescentar se necessário módulos de tratamento de erros e excessão

11) Diagrama Hierárquico de Funções(DHF) Como construir

1. Identificando o Fluxo – Fluxo de Transformação

11) Diagrama Hierárquico de Funções(DHF) Como construir1.Identificando o Fluxo – Fluxo de Transação

11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transformação

11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transformação

11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transação

11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transação

11) Diagrama Hierárquico de Funções(DHF) Como construir3. Revisar a estrutura – Regras de Projeto1. Reduzir acoplamento e aumentar coesão explosão de módulos

implosão de módulos

11) Diagrama Hierárquico de Funções(DHF) Como construir2. Minimizar estruturas com fan-in e fan-out,

aumentando fan-in à medida que a profundidade aumenta – estrutura oval

3. Manter o escopo do efeito de um módulo dentro do escopo de controle do módulo

4. Reduzir complexidade das interfaces entre os módulos

5. Evitar módulos muito restritivos – portabilidade

6. Utilizar ED as menos complexas possíveis

12) Diagramas de Interação Ilustram como objetos interagem

via mensagens e como realizam tarefas com o objetivo de cumprir as pós-condições dos contratos. Diagramas de Colaboração – grafo

ou rede Diagramas de Sequências – traços

de eventos

12) Diagramas de Interação

12) Diagramas de Interação

12.1) Diagrama de Colaboração - Notação



12.1) Diagrama de Colaboração – Notação











12.2) Diagrama de Colaboração e Outros Modelos

12.3) Diagrama de Colaboração –Como Construir Atribuir responsabilidades: parte difícil

e importante Auxílio: uso de ``patterns'' que são

diretrizes e princípios a serem aplicados Criar um diagrama para cada operação

do sistema; para cada msg de operação do sistema, fazer um diagrama com ela sendo a msg inicial

12.3) Diagrama de Colaboração –Como Construir Se o diagrama ficar complexo, divida-o em

diagramas menores Usando responsabilidades e pós condições

dos contratos e, a descrição de caso de uso como ponto inicial, projete objetos interagindo para completar as tarefas.

Métodos: cumprem as responsabilidades.

12.3) Diagrama de Colaboração –Como Construir Responsabilidades: Contrato ou obrigação

de uma classe: saber: saber sobre os seus dados, sobre objetos

relacionados, sobre coisas que ele pode calcular ou derivar. fazer: iniciar ações entre outros objetos, controlar e

coordenar atividades em outros objetos

Aplique padrões para fazer um bom projeto e para estabelecer os métodos e operações de cada objeto.

12.4) Diagrama de Colaboração –Padrões GraspPadrões: contêm descrições de um problema

e uma solução que pode ser utilizada em diferentes contextos.

Codificam idéias e heurísticas existentes para atribuir responsabilidades a objetos.

Padrões GRASP básicos: especialista, criador, alta coesão, baixo acoplamento, controle.

12.4) Diagrama de Colaboração –Padrões Grasp1. Padrão Especialista (Expert) Solução: Atribua uma responsabilidade a

uma classe que possui a informação necessária para cumprí-la.

Problema: Quem deveria ser responsável por calcular o total-geral de uma venda? a classe Venda possui a informação para isso

12.4) Diagrama de Colaboração –Padrões Grasp

Classe Responsabilidade

Venda sabe total geral da venda

Item de Venda sabe sub-total de cada item

Especificação do Produto

sabe preço do produto



12.4) Diagrama de Colaboração –Padrões Grasp2. Padrão Criador (Creator) Solução: Atribua à classe B a responsa-

bilidade de criar uma instância da classe A se:

1. B agrega objetos de A 2. B contém A 3. B armazena instâncias de A 4. B usa objetos de A 5. B possui informação necessária a criação

de A (B é um especialista para criar A)


2. Padrão Criador (Creator) Problema: Quem deveria ser

responsável por criar a instância da classe Item de Venda? classe Venda agrega muitos objetos da classe Itens de Venda


12.4) Diagrama de Colaboração –Padrões Grasp3. Padrão Baixo Acoplamento e Padrão

Alta Coesão (Low Coupling e High Cohesion)

Solução: Atribua responsabilidades para garantir baixo acoplamento (mede a independência da classe em relação a outras) e alta coesão (medida de relacionamento entre as responsabilidades de uma classe)

12.4) Diagrama de Colaboração –Padrões GraspProblema: Para evitar que a classe seja:

1. constantemente afetada por mudanças em outras classes

2. difícil de compreeder quando isolada 3. difícil de ser reusada sem as outras classes 4. difícil de manter

que classe poderia criar uma instância da classe Pagato?


12.4) Diagrama de Colaboração –Padrões Grasp4. Padrão Controle (Controller) Solução: Atribua responsabilidades para

lidar com mensagens de eventos do sistema a uma classe que:

1. represente o sistema como um todo 2. represente a organização 3. represente algo ativo no mundo real

envolvido na tarefa (por exemplo o papel de uma pessoa)

4. represente um controlador artificial dos eventos de sistema de um caso de uso

12.4) Diagrama de Colaboração –Padrões GraspProblema: Quem deveria ser responsável

por lidar com um evento do sistema? um controlador é um objeto de

interface responsável por gerenciar um evento do sistema, definindo métodos para operações do sistema

Quem deveria ser o controlador para eventos do sistema tais como entrarItem e Vendafim?


12.4) Diagrama de Colaboração –Padrões Grasp4. Padrão Controle Use o mesmo controlador para todos os

eventos do sistema no mesmo caso de uso Classes do tipo janela, applet, aplicações,

documento não deveriam realizar tarefas associadas a eventos do sistema. Elas apenas recebem e delegam os eventos ao controlador

Um evento do sistema é gerado por um ator

12.4) Diagrama de Colaboração –Padrões Grasp Um controlador não deve ter muitos

atributos e nem manter informação sobre o domínio do problema

Um controlador não deve realizar muitas tarefas, apenas delegá-las

Um bom projeto deve dar vida aos objetos, atribuindo-lhes responsabilidades, até mesmo se eles forem seres inanimados

A camada de apresentação (interface com o usuário) não deve tratar eventos do sistema

12.4) Diagrama de Colaboração –Padrões Grasp5. Padrão Comando Problema: Aplicações que recebem msg de

um sistema externo (não existe interface com o usuário). Ex: sistemas de telecomunicações

Solução: definir uma classe para cada comando, com o método executar. O controlador criará uma instância da classe correspondente a msg do evento do sistema e enviará a mensagem executar à classe comando.



12.4) Diagrama de Colaboração Como Construir utilize as responsabilidades e pós-

condições dos contratos e use casos de usos como ponto de partida

escolha a classe que controlará o sistema, aplicar padrão controle

para cada operação existe um contrato, uma operação vai ser uma mensagem.

12.4) Diagrama de Colaboração Como Construir separação do modelo de visão: não é

responsabilidade dos objetos do domínío se comunicarem com o usuário (ignorar responsabilidades de apresentação dos dados no display, mas toda informação do domínio de objetos tem que ser mostrada)

para um objeto enviar uma msg a outro é necessário visibilidade: habilidade de um objeto ver ou fazer referência a outro objeto

12.4) Diagrama de Colaboração – Como Construir

12.5) Diagrama de Colaboração - Visibilidade Habilidade de um objeto A ver ou fazer

referência a um outro objeto B. Para A enviar uma msg para B, B deve ser visível a A. por atributo: B é um atributo de A por parâmetro: B é um parâmetro de um

método de A localmente declarada: B é um objeto local de

um método de A; uma instância local é criada, ou ele será um valor de retorno

global: B é visível globalmente; usa-se uma variável global para armazenar uma instância - pouco recomendada

12.5) Diagrama de Colaboração - Visibilidade

12.5) Diagrama de Colaboração - Visibilidade

12.6) Diagrama de Colaboração - Exemplos






12.7) Diagrama de Colaboração - InicializandoComo se realizam as operações iniciais da

aplicação? Cria-se um caso de uso startUp. Seu diagrama de colaboração deve ser criado por

último, representando o que acontece quando o objeto inicial do problema é criado.

Quem deveria ser o objeto inicial do sistema? classe representando toda a informação lógica do

sistema classe representando a organização usar Padrões Alta Coesão e Baixo Acoplamento

12.7) Diagrama de Colaboração - Inicializando


12.7) Diagrama de Colaboração - Inicializando Conectando a camada de

apresentação com a do domínio Uma operação de startUp pode ser:

uma mensagem ``create'' para o objeto inicial;

se o objeto inicial é o controlador, uma mensagem ``run'' para um objeto inicial é enviada.


Se uma interface do usuário estiver envolvida ela é responsável por iniciar a criação do objeto inicial e outros associados.

Objetos da camada de apresentação não devem ter responsabilidades lógicas. Das nossas escolhas resultarão extensibilidade, claridade e manutenibilidade


13) Diagrama de Classes Modelo Conceitual Estendido

acréscimo de métodos, tipos dos atributos, visibilidade e navegabilidade, inclui a visão de projeto além da

visão de domínio

13) Diagrama de Classes – Como construir identificar todas as classes participantes

da solução através dos diagramas de colaboração

desenhar o diagrama copiar os atributos adicionar os métodos dos diagramas de

interação adicionar tipos de atributos, parâmetro

e retornos de métodos.

13) Diagrama de Classes – Como construir adicionar as associações necessárias a

visibilidade adicionar navegabilidade que indica a

direção de visibilidade por atributo adicionar setas pontilhadas indicando

visibilidade que não é por atributo Métodos ``create'' e de acessos aos

atributos podem ser omitidos. Os tipos podem ou não ser mostrados;

classes podem ser detalhadas ao máximo

13) Diagrama de Classes – Exemplos



14) Modelos de Projeto Detalhado O projeto detalhado concentra-se no

aprimoramento ou refinamento Gera representações/especificações das

estruturas de dados e representações algorítimicas

Utiliza ferramentas Gráficas : fluxogramas, cartas NS, diagramas de ação Tabulares : tabelas de decisão. Linguagens : pseudocódigo PDL (“Program Design

Language“)

14) Ferramentas de Projeto Detalhado - Fluxograma

Proc 1

Proc 2

cond

Parteelse

Partethen

cond Proc

F

V

sequência ifthenelse (condição) dowhile (repetição)

processamento controle condição

processamento controle condição

14) Ferramentas de Projeto Detalhado - Fluxograma

. . .

C1

C2

Cn

Proc1

Proc2

Proc n

Proc

CONDF

V

CASE (Seleção)

REPEAT UNTIL (Repetição)

14) Ferramentas de Projeto Detalhado – Fluxograma Ex.

F V

F V

1° Proc.

ELSE THEN

ELSETHEN

V

Próximo Proc.

Proc. ... 2 saídas

14) Ferramentas de Projeto Detalhado – Fluxograma• Fácil de entender e projetar;

• Problema : existência de “jump”, permite a violação dos princípios de programação estruturada.

14) Ferramentas de Projeto Detalhado – Cartas NS

sequência ifthenelse dowhile repeatuntil

Proc1

Proc2...

F Cond V

Parte ELSE

ParteTHEN

COND

PROCCOND

PROC


case (seleção) repetição infinita delimitação

CondValor Valor . . . Valor

proc1 proc2 Proc n. . . PROC

DO FOREVER

PROC

BEGIN

END


a bx1F

Case xi, i = 2,3,4 fx2 x3 x4

x5

c d e

g

h

i

x7

x6

x8j

V

V

14) Ferramentas de Projeto Detalhado – Cartas NS• Vantagens Cartaz NS :

escopo da iteração e do ifthenelse é bem definido e visível. transferências arbitrárias são impossíveis. escopo das variáveis é obvio. estruturas completas podem caber dentro de um programa. codificação é direta. pode servir como um guia para testes (ramos testados). serve como documentação.

• Desvantagens : problemas de espaço e estruturas rígidas.

14) Ferramentas de Projeto Detalhado Tabelas de Decisão

IF

ANDANDAND

THENAND

Condições

Ações

Regra dedecisão

Canhotos\Entradas RD1 RD2 RD3 RD4C1C2C3C4A1A2

14) Ferramentas de Projeto Detalhado Tabelas de DecisãoEx.: Tabela de linhas de Entrada Limitada

Condições : “S” a condição deve ser satisfeita

“N” a condição não deve ser satisfeita “ ” a condição é irrelevante

Ações : “X” a ação correspondente deve ser executada

“ “ a ação correspondente deve ser ignorada

14) Ferramentas de Projeto Detalhado Tabelas de Decisão

Rd1 RD2 RD3 RD4Limite de Crédito Satisfatório 5 N N NCrédito na Praça Favorável - S N NLiberação Especial Aprovada - - S NAprovar Pedido x x x -Rejeitar Pedido - - - x

14) Ferramentas de Projeto Detalhado Tabelas de DecisãoAs tabelas podem ser facilmente

automatizadas Facilidade para reduzir redundâncias; Verificar dependências e contradições. Não mostra laços. Não existe correspondência direta entre

tabela e algoritmo.

14) Ferramentas de Projeto Detalhado - Pseudocódigo• Linguagem natural + sintaxe de linguagens de

programação.• Palavras chaves para estruturação, declaração

de dados e modularização.• Sintaxe livre para descrever processamento.

Podese declarar dados e interfaces entre módulos.

Tradução para o programa é direta. Exitem muitas ferramentas disponíveis.

Pode ser ambíguo.

14) Ferramentas de Projeto Detalhado – ComparaçãoPara comparação, utilizar:

• possibilidades de representar modularidade;• simplicidade; • facilidade de edição; • facilidade de automação; • manutenção; • representação de dados;• conversão para código; • testabilidade e lógica.

Documents

Projeto de Software - Universidade Federal do Paraná · processo de projeto para que sobre tempo suficiente no final para ... Revisar o diagrama através de regras de projeto e acrescentar