ARQUITETURA E DESENHO

Transcrição

1 ARQUITETURA E DESENHO DE SOFTWARE CMP 1063 Prof. Me. Fábio Assunção Parte 2

2

3 DESENHO DE SOFTWARE Espaço do problema Espaço da solução. Interpretação não literal. Orientação à escrita. Orientação à diagramação.

4 DESENHO DE SOFTWARE Abrange: 1) Desenho conceitual: o que o sistema faz. Voltado para o usuário. Documento de requisitos, descrevendo as funcionalidades. 2) Desenho técnico: como o sistema faz. Voltado para os desenvolvedores. Fluxos de dados, descrevendo os algoritmos.

5 DESENHO DE SOFTWARE QUALIDADE 1) Independência Modularização. Inputs e outputs de componentes. Medição de independência: Coesão intra-componente. Uso total dos dados internos. Encapsulamento respeitado. Ligação extra-componente. Fortemente ligados. Fracamente ligados. Desligados.

6 DESENHO DE SOFTWARE QUALIDADE TIPOS DE LIGAÇÕES Ligação de conteúdo. Um componente conhece a estrutura interna/conteúdo de outro. Ligação de partilha. Conjunto de dados compartilhados. Ex.: Variável global. Ligação de controle. Um componente passa parâmetros que controlam a lógica de outro(s). Ligação de estrutura. Uma estrutura de dados fornece a interface entre componentes, gerando dependência. Ligação de dados. Tipos de dados simples são passados entre componentes.

7 DESENHO DE SOFTWARE QUALIDADE 2) Adaptabilidade. Evolução. Redesenho. Ligações fracas. Abstrações estáveis. Coesão (self-contained).

8 DESENHO DE SOFTWARE QUALIDADE 3) Inteligibilidade (entendimento). Coesão e ligação dos componentes. Nomenclatura dos componentes. Documentação. Correlação entre o espaço do problema e da solução.

9 DESENHO DE SOFTWARE ESTILOS ARQUITETURAIS (OU ESTILOS DE DESENHO) Camadas. Repositórios. Pipes e filtros. Desenho funcional. Desenho com objetos.

10 DESENHO DE SOFTWARE ESTILOS ARQUITETURAIS (OU ESTILOS DE DESENHO) Para a arquitetura de software: Componentes do mesmo. Interação entre estes componentes. Estilo arquitetural define o estilo do padrão a ser utilizado no desenho. Descreve os tipos dos componentes. Descreve a complexidade dos componentes. Descreve a orientação da linguagem (escrita, diagramas, etc). Descreve os conectores. Descreve as possibilidades de combinação destes conectores e componentes.

11 ESTILOS DE DESENHO CAMADAS

12 ESTILOS DE DESENHO CAMADAS Hierarquia entre as camadas. cliente, fornecedor Vantagens: Desenvolvimento incremental. Evolução facilitada. Reutilização. Desvantagens Estruturação Desempenho

13 ESTILOS DE DESENHO REPOSITÓRIOS

14 ESTILOS DE DESENHO REPOSITÓRIOS Inventário partilhado de dados Base de dados. Vantagens: Arquitetura aberta. Desvantagens: Dependência dos dados.

15 ESTILOS DE DESENHO PIPES E FILTROS

16 ESTILOS DE DESENHO PIPES E FILTROS Fluxo de dados = pipes. Transformação de dados = filtros. Vantagens: Controle de inputs e outputs. Desvantagens: Detalhamento interno.

17 ESTILOS DE DESENHO DESENHO FUNCIONAL Decomposição do sistema em um conjunto de funções. Estado global partilhado Estado local dura enquanto a função estiver em execução. Detalhes dos algoritmos nas funções, mas o estado não. Alterações em cadeia (estado).

18 ESTILOS DE DESENHO DESENHO COM OBJETOS Encapsulamento. Abstração. Modularidade. Primitivas da Orientação à Objetos. Classes, objetos, mensagens, herança, etc. Reutilização. Extensibilidade. Alterações.

19 DESENHO DE SOFTWARE DECOMPOSIÇÃO

20 DESENHO DE SOFTWARE DECOMPOSIÇÃO Descreve os dados de sistema (e como são transitados). Descreve funcionalidades (em alto nível). Detalha e agrupa informações (hierarquicamente).

21 DESENHO DE SOFTWARE DECOMPOSIÇÃO Funcional: atual estado do software é compartilhado, com manipulação colaborativa entre as funcionalidades que o geraram. Com objetos: interação entre um conjunto de objetos que encapsulam a informação que manipulam.

22 PADRÕES DE DESENHO Primitivas. Regras. Princípios. Recomendações. Padrões. Resultados favoráveis. Reutilização de soluções que evoluíram ao longo do tempo.

23 PADRÕES DE DESENHO Descrição da essência de soluções bem sucedidas. Contextualização das problemáticas emergentes. Esquema pré-definido de implementação, que prioriza a reutilização por meio de um vocabulário e conhecimento comum. Ou seja, são blocos do desenvolvimento de uma arquitetura, o que facilita, também, sua documentação.

24 PADRÕES DE DESENHO PROXY Fornece um representante proxy para um objeto. Controlar de acesso (in e out). Objeto real, ocultado, realiza o trabalho. Trabalho on demand. Referências. Exemplo: proxy de imagens.

25 PADRÕES DE DESENHO PROTÓTIPO DE PRIMEIRA PASSAGEM/EXPANSÃO Resolver inicialmente o problema. Resultados parciais. Inviabilidade de alteração e refinamento de requisitos. Aplicação de herança, visando melhoria ao invés de reconstrução. Sujeição à expansão/alteração. Próximo passo natural.

26 PADRÕES DE DESENHO CONSOLIDAÇÃO DE PROTÓTIPO Desenho melhorado de acordo com a evolução do sistema. Herança é exaustivamente utilizada na prototipagem/extensão. Funcionalidade limitada pelo escopo. Fatorar parte de uma classe em uma nova classe. Encurtar referências. Criar independência (acabar com a herança). Agregação/Composição de classes.

27 PADRÕES DE DESENHO CONSOLIDAÇÃO DE PROTÓTIPO Suponha que A é uma subclasse de B: Adicionar uma instância de B como variável de instância de A. Mudar as referências para as variáveis e funções herdadas de B por referências para a variável de instância de A. Retirar a relação de herança entre A e B.

28 PADRÕES DE DESENHO CONSOLIDAÇÃO DE PROTÓTIPO Hierarquia de classes: Topo: superclasses abstratas. Subclasses: especializações. Redução do tamanho, mantendo a funcionalidade. Reduz a ocorrência de erros de derivação.... mas, podem haver problemas de inconsistência.

29 PADRÕES DE DESENHO CONSOLIDAÇÃO DE PROTÓTIPO Suponha-se que as classes A e B partilham uma abstração: Determinar o comportamento comum entre A e B. Fazer uma nova classe C, a fim de torna-la a superclasse de A e B. Se preciso, promover alterações pontuais em A e B, dentro de sua abstração comum, de modo que seja a mesma. Remanejar a implementação comum para C e apagar de A e B.

30 PADRÕES DE DESENHO DESENHO COLABORATIVO

31 PADRÕES DE DESENHO DESENHO COLABORATIVO Trabalho colaborativo dentro do time. Quem é mais adequado? Como documentar? Como coordenar? Vantagem: Otimização de tempo. Maximação do conhecimento. Reutilização. Desvantagem: Experiência pessoal desequilibra. Conformidade e padronização.

32 APERFEIÇOAMENTO DE DESENHO Desenho por contrato. Protótipos de desenho.

33 APERFEIÇOAMENTO DE DESENHO DESENHO POR CONTRATO Garantir que o desenho condiz com a especificação. Contrato: 1) Pré-condições. Obrigações mútuas. 2) Pós-condições. Benefícios. 3) Invariantes. Restrições de coerência. Favorecem aspectos como documentação, desenvolvimento modularizado, reutilização, etc.

34 APERFEIÇOAMENTO DE DESENHO PROTÓTIPO DE DESENHO Oferece a possibilidade de verificar se o problema será resolvido por via do desenho proposto. Foco sobre algum aspecto duvidoso no desenho. Descartáveis, na maioria das vezes.

35 DESENHO DE SOFTWARE REVISÃO DO DESENHO 1) Revisão Conceitual Usuário. 2) Revisão Crítica Desenvolvedores (toda a equipe). 3) Revisão da Desenho do Programa. Programadores.

36 DESENHO DO SOFTWARE REVISÃO DE DESENHO Durante o processo de revisão, algumas perguntas surgem, como: É a solução do problema? É intuitivo e de fácil entendimento? É modular, bem estruturado? É portável? É reutilizável? É fácil de expandir, alterar? É fácil de se testar?

37 VALIDAÇÃO E VERIFICAÇÃO Validação: certificação de que o desenho atende aos requisitos especificados pelo usuário. Estou fazendo o produto correto? Verificação: certificação de que o desenho agrega as qualidades de desenho requeridas. Estou fazendo o produto da maneira correta?

38 MÉTRICAS DE DESENHO MEDIÇÃO DE INSTABILIDADE DE MÓDULOS Avalia a ligação entre a ligação/dependência de classes dentro e fora do módulo. LFD Ligação Fora/Dentro. LDF Ligação Dentro/Fora. I Instabilidade. I = LFD / (LFD + LDF). I = 0 indica estabilidade. I = 1 indica instabilidade.

39 MÉTRICAS DE DESENHO MEDIÇÃO DE INSTABILIDADE DE MÓDULOS Módulos estáveis devem ser muito abstratos. Módulos instáveis devem ser muito concretos. Módulos devem ser abertos à extensão e fechados à modificação. Abstração: A = Total de classes abstratas / total de classes. Dentro do módulo.

40 MÉTRICAS DE DESENHO COMPARAÇÃO DE DESENHO Construir vários desenhos, cada qual focado em uma solução, para a mesma problemática. Isto é, diferentes estilos arquiteturais. Comparação, geralmente por meio de tabela gerada pela avaliação de atributos contemplados por cada desenho, mostra qual solução (ou junção de soluções) é a mais adequada. Atribuição de pesos às comparações permitem traçar um perfil matemático (quantificado) das prioridades contempladas por cada arquitetura.

41 PADRÃO ARQUITETURAL MVC MVC = Modelo, Vista e Controlador. Modelo: contém o núcleo da funcionalidade dos dados. Vista: fornece informações ao usuário. Controlador: trata as entradas do usuário. Paralelo: entrada, processamento e saída. controlador, modelo e visão.

42 PADRÃO ARQUITETURAL MVC CONTROLADOR Gerencia as entradas de dados oferecidas pelos dispositivos de entrada. Realiza a intepretação e o mapeamento dos dados de entrada em instruções que são repassadas ao modelo.

43 PADRÃO ARQUITETURAL MVC MODELO Gerencia uma ou mais estruturas e/ou elementos de dados. Assim, responde e altera estados no sistema de software, acionando a visão. O modelo abriga a lógica da solução proposta pela arquitetura.

44 PADRÃO ARQUITETURAL MVC VISÃO Gerencia o display e a apresentação dos dados e/ou estado ao usuário. Utiliza combinações gráficas. Recebe instruções do controle e informações do modelo. Feedback.

45 PADRÃO ARQUITETURAL MVC

46 PADRÃO ARQUITETURAL MVC PROBLEMA Interface com o usuários muito sujeita à alterações por parte do mesmo. Pluralidade no uso por diferentes usuários. Para resolver, seria necessário que... Diferentes telas mostram a mesma informações de formas diferentes. O atual estado do software reflete diretamente as alterações solicitadas e promovidas. Isto é, em tempo de execução.

47 PADRÃO ARQUITETURAL MVC SOLUÇÃO A devida separação entre modelo, vista e controlador permite diferentes vistas do mesmo modelo. Já vimos algo assim em métrica de desenho, quando falamos sobre comparação de desenho, certo?