Projeto de Software. Silvia Regina Vergilio - UFPR

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)

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) Fundamentos (Princípios) 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 problema C(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

(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ódulos Quanto 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 subprograma interrupção programa em execução é interrompido para execução de outro módulo

3. Tipos de Módulos 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)

3. Tipos de Módulos 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

3. Tipos de Módulos 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 Geral Os modelos de projeto geral devem: especificar a decomposição do sistema em sub-sistemas (modelo da arquitetura do sistema) mostrar o relacionamento entre os subsistemas (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 subsistemas através de mensagens mais eficiente para gde quantidade de dados maior facilidade para integrar um novo subsistema 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 clienteservidor: O modelo + conhecido

7) Modelo da Arquitetura do Sistema ClienteServidor 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 ClienteServidor

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

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. 2. 3. Pode-se separar a camanda da aplicação em diferentes componentes a serem reutilizados Diferentes equipes para o desenvolvimento 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 construir Padrã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 subsistema 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) Como construir São três passos 1. 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 construir 1.Identificando o Fluxo Fluxo de Transação

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

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

11) Diagrama Hierárquico de Funções(DHF) Como construir 3. Revisar a estrutura Regras de Projeto 1. Reduzir acoplamento e aumentar explosão de módulos coesão implosão de módulos

11) Diagrama Hierárquico de Funções(DHF) Como construir 2. 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.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 Grasp Padrõ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 Grasp 1. 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 sabe total geral da Venda venda sabe sub-total de Item de Venda cada item Especificação do sabe preço do Produto produto

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

12.4) Diagrama de Colaboração Padrões Grasp 2. Padrão Criador (Creator) Solução: Atribua à classe B a responsabilidade de criar uma instância da classe A se: 1. 2. 3. 4. 5. B agrega objetos de A B contém A B armazena instâncias de A B usa objetos de A B possui informação necessária a criação de A (B é um especialista para criar A)

12.4) Diagrama de Colaboração Padrões Grasp 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 Grasp 3. 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 Grasp Problema: Para evitar que a classe seja: 1. 2. 3. 4. constantemente afetada por mudanças em outras classes difícil de compreeder quando isolada difícil de ser reusada sem as outras classes difícil de manter que classe poderia criar uma instância da classe Pagato?

12.4) Diagrama de Colaboração Padrões Grasp 4. Padrão Controle (Controller) Solução: Atribua responsabilidades para lidar com mensagens de eventos do sistema a uma classe que: 1. 2. 3. 4. represente o sistema como um todo represente a organização represente algo ativo no mundo real envolvido na tarefa (por exemplo o papel de uma pessoa) represente um controlador artificial dos eventos de sistema de um caso de uso

12.4) Diagrama de Colaboração Padrões Grasp Problema: 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 Grasp 4. 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 Grasp 5. 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óscondiçõ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.6) Diagrama de Colaboração - Exemplos

12.7) Diagrama de Colaboração - Inicializando Como 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.

12.7) Diagrama de Colaboração - Inicializando 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

12.7) Diagrama de Colaboração - Inicializando

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 N S, diagramas de ação Tabulares : tabelas de decisão. Linguagens : pseudo código PDL ( Program Design Language )

14) Ferramentas de Projeto Detalhado Fluxograma processamento controle cond cond Proc 1 Parte else condição Parte then V F Proc 2 sequência processamento if then else (condição) controle do while (repetição) condição Proc

14) Ferramentas de Projeto Detalhado Fluxograma C1 Proc1 Proc C2 Proc2... Cn Proc n COND F V REPEAT UNTIL (Repetição) CASE (Seleção)

14) Ferramentas de Projeto Detalhado Fluxograma Ex. 1 Proc. Próximo Proc. F F ELSE V V THEN ELSE V THEN 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 Proc1 Proc2... if then else F Cond Parte ELSE V Parte THEN do while COND repeat until PROC PROC COND

14) Ferramentas de Projeto Detalhado Cartas NS case (seleção) repetição infinita DO FOREVER Valor Cond Valor... Valor proc1 proc2 Proc n... PROC delimitação BEGIN PROC END

14) Ferramentas de Projeto Detalhado Cartas NS a b x1 F Case xi, i = 2,3,4 x3 x2 V f x6 x4 V x5 g c d i e h x7 x8 j

14) Ferramentas de Projeto Detalhado Cartas NS Vantagens Cartaz N S : escopo da iteração e do if then else é 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 Condições IF AND AND AND THEN AND Ações Canhotos\Entradas C1 C2 C3 C4 A1 A2 RD1 RD2 RD3 RD4 Regra de decisão

14) Ferramentas de Projeto Detalhado Tabelas de Decisão Ex.: 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 Limite de Crédito Satisfatório Crédito na Praça Favorável Liberação Especial Aprovada Aprovar Pedido Rejeitar Pedido Rd1 5 x - RD2 N S x - RD3 N N S x - RD4 N N N x

14) Ferramentas de Projeto Detalhado Tabelas de Decisão As 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. Pode se 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ção Para 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.