Baixe o app para aproveitar ainda mais
Prévia do material em texto
ENGENHARIA DE SOFTWARE PARA SI II Análise, Projeto e Arquitetura de Software Profa. Dra. Adicinéia Aparecida de Oliveira 2015/2 Roteiro Análise e Projeto. Introdução à Arquitetura de Software. Estilos arquitetônicos. Tipos de arquitetura. Motivação “A parte mais árdua na construção de um sistema de software é decidir o que construir. Nenhuma outra parte do trabalho compromete mais o sistema se for feito de forma imprópria. Nenhuma outra parte é mais difícil de corrigir a posteriori”. F. P. Brooks Jr, “No Silver Bullet: Essence and Accidents in Software Engineering”, IEEE Computer. “Se tivesse seis horas para cortar uma árvore, gastaria as primeiras quatro afiando o machado.” A. Lincoln Introdução Metodologias de desenvolvimento de sistemas Metodologia Dissertação sobre a maneira de se utilizar um conjunto de métodos para atingir um objetivo, de modo que se evite a subjetividade na execução do trabalho. Método Procedimento (conjunto de técnicas) a ser adotado para se atingir um objetivo. Técnica Modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domínio de um problema. (faz uso de uma notação). Notação Conjunto de caracteres, símbolos e sinais formando um sistema convencionado de representação. Conceitos Análise Descoberta (elicitação), modelagem, estudo ... de algo que já existe no mundo real. Projeto Concepção detalhada de algo que ainda não existe, com o objetivo de construir esse algo. Termo com dois significados. Inglês: design (cf. project). Português: projeto ou desenho (cf. projeto (atividade) e projeto (resultado da atividade). Análise e Projeto Análise — “o quê” Investigação do problema e dos requisitos Requisitos Casos de uso Restrições Vocabulário Projeto — “como” Descrição de uma solução lógica Objetos Arquitetura Instalação & Operação Interface do usuário Termos “Análise” e “Projeto” não são fixos, mas usados ao longo de um contínuo. Significados variam de metodologia para metodologia. Distinção é útil na prática, mas debater definições rígidas não é construtivo. Conflito de terminologias Mais orientado a análise Mais orientado a projeto Objetivos da Análise Especificação de requisitos mais precisa. Descrita usando linguagem de desenvolvedores. Proporciona maior entendimento, facilidade de mudanças e manutenções. Primeiro passo para o modelo de projeto. Primeiras interações da fase de elaboração. Princípios de Análise 1. O domínio da informação de um problema precisa ser representado e entendido (Domínio da informação). 2. As funções a serem desenvolvidas pelo software devem ser definidas (Modelagem Funcional). O comportamento do software precisa ser representado (Modelagem Comportamental). 3. Os modelos que mostram informação, função e comportamento devem ser particionados (Particionamento). 4. O processo de análise deve ir da informação essencial até o detalhe de implementação (Visão Essencial e de Implementação). Modelagem Modelos Funcionais- o software transforma a informação, assim precisa realizar 3 funções: entrada, processamento e saída. Modelos Comportamentais – são formados pela característica de estímulo/resposta (estado que o sistema está) Para que servem? auxilia o analista no entendimento da informação, função e comportamento de um sistema; é o foco para as revisões completeza, consistência e precisão das especificações; base para o projeto (essência mapeada para a implementação). Modelagem de sistemas Modelo funcional Perspectiva das funções do sistema Modelo de dados Perspectiva dos dados do sistema Modelo de controle Perspectiva dos controles de estados do sistema Modelo de Análise Objetivos: descrever o que o cliente deseja; estabelecer uma base para a criação de um projeto de software; definir um conjunto de requisitos que pode ser validado quando o software for construído. Metodologias de desenvolvimento de sistemas Uma boa metodologia deve definir: As fases de trabalho a serem adotadas (ciclo de vida). Quem faz o quê, quando e como. O papel dos técnicos, dos usuários e dos gerentes. Pontos de controle e verificação. Níveis de qualidade. Um conjunto de padrões pré-estabelecidos. Evitar o problema dos “donos do sistema”. As técnicas é que devem ser estáveis e não os técnicos. Metodologias de desenvolvimento de sistemas A metodologia deve definir quais as fases do trabalho. Para cada fase, quais as técnicas: Análise estruturada, análise essencial, análise OO, análise OA... Para cada técnica, quais as ferramentas: DFD, DER, DTE, Diagrama de contexto... Para cada ferramenta, quais modelos: Modelo funcional, modelo de dados, modelo de controle... Modelagem de sistemas Classificação importância dos modelos na especificação do sistema: Centrado nas funções Maior preocupação nas funções. Centrado nos dados Maior preocupação nos dados e seus relacionamento. Centrado nos controles Maior preocupação nos controles do sistema. Nos sistemas de informações administrativos as principais perspectivas estão nos dados e nas funções. Abordagens da análise Método Estruturado; Método Essencial; Método Orientado a Objetos; Método Orientado a Agentes; Método Orientado a Aspectos... Metodologias Metodologias Estruturada e Essencial x OO Nos métodos de análise estruturada e essencial, o comportamento do sistema e seus dados são considerados separadamente. Na orientação a objetos, comportamento e dados são integrados, encapsulando detalhes internos de um objeto. Estruturada e Essencial x OO Projeto do Software Inicia a conversão da especificação em um sistema executável, projetando um Software a implementará. Define: a Arquitetura a Interface os Componentes as Estruturas de Dados os Algoritmos Projeto de Software Primeira das 3 atividades técnicas: projeto, geração de código e teste. O projeto é o lugar onde a qualidade é fomentada durante o processo de desenvolvimento. Transforma a informação do modelo de domínio (análise) em estruturas que requerem ser implementadas no software. Projeto de software Segundo SWEBOK – É o processo de definição da arquitetura, dos componentes, da interface e de outras características dos componentes do sistema e do resultado esperado, para resolver o problema identificado na fase de requisitos. Como será feito! Projeto de software A essência do projeto de software é tomar decisões sobre a organização lógica do software. Grandes sistemas – vários subsistemas. O processo inicial de projeto identificar esses subsistemas e estabelecer um framework para o controle e a comunicação de subsistemas – projeto de arquitetura. Importância do Projeto O projeto fornece representações do software que podem ser avaliadas quanto à qualidade. É a única maneira pela qual pode-se traduzir com precisão os requisitos de um cliente num produto de software acabado. Requisitos críticos O estilo e a estrutura específicos escolhidos para uma aplicação podem, depender dos RNF do sistema. Desempenho. Proteção. Segurança. Disponibilidade. Facilidade de manutenção. Obviamente há conflitos potenciais entre algumas dessas arquiteturas. Resumindo... Uma especificaçãode requisitos pode ser satisfeita por vários projetos. Um projeto pode ser satisfeito por várias implementações. Algo que não é especificado ou projetado, é satisfeito por qualquer implementação! Decisões de projeto de arquitetura Existe uma arquitetura genérica? Como o sistema será distribuído ao longo de vários processadores? Qual ou quais estilos de arquitetura são apropriados para o sistema? Qual será a abordagem fundamental usada para estruturar o sistema? Como as unidades estruturais de um sistema são decompostos em módulos? Qual estratégia será usada para controlar a operação das unidades no sistema? Como o projeto de arquitetura será avaliado? Como a arquitetura do sistema deve ser documentada? Produto do projeto de arquitetura Documento de projeto de arquitetura que pode incluir várias representações gráficas do sistema junto com texto descritivo associado. Pode incluir: Um modelo estático de estrutura. Um modelo dinâmico de processo. Um modelo de interface. Modelos de relacionamentos. Um modelo de distribuição. Arquitetura O termo arquitetura é utilizado aqui para descrever os atributos de um sistema da forma como é visto pelo programador, isto é, sua estrutura conceitual e seu comportamento funcional, ao contrário da organização do fluxo de dados e controles, do projeto lógico e da implementação física. IBM SYSTEMS JOURNAL, 1964 Arquiteturas de Software “Descobrimos que compreender a arquitetura de software é a chave do desenvolvimento de muitas soluções de software importantes.” Peters, 1991 São consideradas no início de um processo de projeto de software. Esta etapa começa com a seleção das arquiteturas e dos elementos arquitetônicos. Concepções errôneas sobre a arquitetura… Arquitetura é somente um papel. Arquitetura e projeto são as mesmas coisas. É minha tecnologia preferida. Arquitetura não pode ser medida ou validada. Arquitetura é simplesmente a estrutura. Arquitetura é uma arte. O que é arquitetura de software? “Consiste de elementos arquiteturais, as interações entre estes elementos, e as restrições sobre estes elementos e sobre as suas interações.” [Perry 92] O que é arquitetura de software? “Arquitetura de software é a estrutura de um programa ou um sistema, seus relacionamentos e os princípios que guiam o seu projeto e a sua evolução no tempo.” [Garlan 95] O que é arquitetura de software? Estabelece o contexto para o design e implementação. Decisões arquiteturais são as mais significantes. CÓDIGO IMPLEMENTAÇÃO DESIGN ARQUITETURA O que é arquitetura de software? Arquitetura também envolve… Funcionalidade. Usabilidade. Desempenho. Reuso. Facilidade de compreensão. Restrições. Equilíbrio de fatores econômicos e tecnológicos. Qual a importância? 1) Integridade e Qualidade. 2) Controle da Complexidade. 3) Previsibilidade. 4) Testabilidade. 5) Reuso. 6) Comunicação. 7) Organização e Gerência de Projetos. 8) Evitar ou Reduzir custos. Visões da Arquitetura Visões da Arquitetura Múltiplas realidades, múltiplos interessados com visões distintas e que precisam de visualizações diferentes. Exemplos de Stakeholders interessados: Usuário Final. Gerente de Projeto. Desenvolvedor. Arquiteto. Testador. Outros Sistemas. Visões da Arquitetura Visão de Implementação Visão Lógica Visão de Distribuição Visão de Processos Visão de Casos de Uso Analista de Sistemas Funcionalidade Programadores Arquiteto Escalabilidade, Performance, Eficiência Topologia, Implantação, comunicação Arquiteto Estrutura, componentes Arquiteto Visões da Arquitetura Visão Lógica Retrato estático dos relacionamentos existentes entre as entidades do sistema. Foca nas funcionalidades e abstrações chaves. Pode possuir duas ou mais abstrações: Modelo conceitual; Esquema de banco de dados. Utiliza da UML: Diagrama de pacotes (partições maiores); Diagrama de classes (elementos significativos); Diagramas de Interação. Visões da Arquitetura Visão de Processos: Descreve aspectos de sincronização e concorrência. Descrição dos processos concorrentes. Foca em performance, escalabilidade e eficiência. Utiliza da UML: Diagrama de classes usando os esteriótipos <<process>> e <<threads>>. Diagramas de Atividades e Interação. Visões da Arquitetura Visão de Implementação Foca nos componentes que serão utilizados e no ambiente de desenvolvimento. Utiliza da UML: Diagrama de classes (detalhado). Diagrama de componentes. Visões da Arquitetura Visão de Distribuição: Topologia dos sistemas de hardware onde o sistema executa. Distribuição dos componentes. Verificação da disponibilidade, confiabilidade e desempenho. Utiliza da UML: Diagrama de Implantação. Diagrama de componentes. Visões da Arquitetura Visão de Casos de Uso Descreve o comportamento do sistema sobre a ótica dos usuários. Utiliza da UML: Diagrama de Caso de Uso. Diagrama de Atividades. Diagrama de Estados. Visões da Arquitetura Nem todos os sistema requerem todas as visões… Pequeno programa (ignora implementação). Única máquina (ignora distribuição). Outros requerem visões adicionais… Visão dos Dados. Visão de Segurança. Como definir a arquitetura? Definindo quais padrões utilizar… Estilo Arquitetural Padrões de Design Idiomas Elementos Arquitetônicos Processamento – Estruturas de software que transformam as entradas em saídas necessárias. Dados – Informações utilizadas no processamento ou informações a serem transformadas pelos elementos de processamento. Conexão – Elementos que são o amálgama que une as diferentes partes de uma arquitetura. Processo do Projeto Deve fornecer uma estrutura interna clara para o software seja: Relativamente simples; Flexível; Extensível; Portável; e, Reutilizável. Estilos Arquitetônicos Um estilo arquitetônico se caracteriza por: Tipos de componentes Elementos de processamento utilizados para transformar dados. Tipos de conectores Caminhos de controle e de dados entre os componentes. Restrições Quanto ao processamento, dados e formas permitidas para se unirem os componentes eletronicamente. Modelos e estilos (Sommerville) Modelos de Arquitetura: Modelo de estrutura. Modelo de controle. Modelo de decomposição. Modelos Organizacionais: Modelos de repositórios. Modelos cliente-servidor. Modelos de máquina abstrata. Estilos de Decomposição: Orientada a objetos. Orientada a funções. Modelos de Controle: Controle centralizado. Controle baseado em eventos. Arquiteturas de Referência Modelos genéricos. Modelos de referência Tipos de Arquiteturas Fluxo de Dados. Chamada e Retorno. Independente do Processo. Máquina Virtual. Repositório – Centrado nos Dados. Específica para o domínio. Estilos Arquiteturais Fluxo de Dados Batch (Sequencial) – Processamento em lotes. Pipes and Filters (Tubos e Filtros). Controle de Processo. Criptógráfico. Chamada Retorno Programa Principal/Subrotina. Invocação Remota de Procedimento – Orientada a procedimentos. Camadas (Layered). Orientadaa objetos. Estilos Arquiteturais Independente do processo ou Componentes Independentes Processos de comunicação. Sistema de evento-ação - Baseados em Eventos. Sistema distribuído. Processos paralelos. Agente. Estilos Arquiteturais Máquina Virtual Interpretadores. Sistemas inteligentes. Sistema baseado em Regras. Máquina Abstrata. Química (MAC). Centrado nos Dados Repositório – Banco de Dados. Quadro Negro. Hipertexto. Arquivístico. Estilos Arquiteturais Específica para o Domínio Xadrez (Deep Blue da IBM). Dama (Chinook). Orientada à Genética. Orientada a redes neurais. Estilos Arquiteturais Fluxo de Dados O sistema realiza uma série de transformações sucessivas sobre uma cadeia de dados. A meta é reuso e modificabilidade. Estilos Arquiteturais Fluxo de Dados > Batch Programas independentes executados em sequência. Dado transmitido por completo entre um programa e outro. Jar JavaJavac class{ } Arquivos fonte A$n3* 3N4*# Bytecode 000 1001 1001 Arquivo Jar executandoEmpacotandoCompilando Estilos Arquiteturais Fluxo de Dados > Pipes and Filters Código fonte Analisador Léxico Analisador Sintático Analisador Semântico Gerador de código intermediário Otimizador Intel backend MIPS backend SPARC backend tokens Árvore sintática Árvore sintática c/ semântica ExecutávelExecutável otimizado Estilos Arquiteturais Fluxo de Dados > Pipes and Filters Trasnformação sequencial dos dados, efetuados por vários componentes (filtros) em sucessão. Os filtros realizam o processamento dos dados de entrada. Pipes conectam os filtros, transmitido os dados de saída de um filtro para as entradas de outro. Estilos Arquiteturais Fluxo de Dados > Pipes and Filters Dificuldade para interatividade e cooperação entre os filtros. Baixa performance Melhorada através de buffers ou paralelização do sistema. Estilos Arquiteturais Chamada Retorno Criam sistemas modificáveis e escaláveis. Maior parte dos sistemas utilizam essa abordagem. Estilos Arquiteturais Chamada Retorno > Programa Principal/Subrotina Programa principal Subrotina 3Subrotina 1 Subrotina 2 Estilos Arquiteturais Chamada Retorno > Programa Principal/Subrotina Reutilização de subrotinas. Desenvolvimento independente de subrotinas. Estilos Arquiteturais Chamada Retorno > Invocação Remota de Procedimento Programa principal Subrotina 1 Subrotina 2 192.168.10.11 Subrotina 3 192.168.10.8 Estilos Arquiteturais Chamada Retorno > Invocação Remota de Procedimento Subrotinas executam em outras máquinas conectadas a rede. Estilos Arquiteturais Chamada Retorno > Camadas (Layered) Aplicação Apresentação Sessão Transporte Rede Dados Física Apresentação Negócio Armazenamento ISO-OSI Clássica 3 camadas Estilos Arquiteturais Chamada Retorno > Camadas (Layered) Camadas se comunicam apenas com as camadas adjacentes. Alterações locais não são propagadas. Estilos Arquiteturais Componentes Independentes > Comunicação de Processos Baseado na comunicação via troca de mensagens entre processos. Em geral via rede. Cliente – Servidor. Ponto-a-Ponto. Estilos Arquiteturais Componentes Independentes > Comunicação de Processos > Cliente Servidor Clientes Servidor Aplicação: Internet Estilos Arquiteturais Componentes Independentes > Comunicação de Processos > Cliente Servidor Alta dependência do servidor pode ser um grande problema. Estilos Arquiteturais Componentes Independentes > Comunicação de Processos > Ponto-a-Ponto Não há distinção entre nós. Cada nó é cliente e servidor ao mesmo tempo. Cada nó mantém seus próprios dados e endereços conhecidos. Estilos Arquiteturais Componentes Independentes > Baseados em Eventos Produtores e consumidores independentes. Procedimentos disparados via mudança de estado. Escalabilidade no número de interessados. menuDown onMouseOver onMouseClick onMousePressed onMouseReleased onKeyUp Estilos Arquiteturais Máquina Virtual > Interpretador Simular funcoinalidade não-nativa para obter portabilidade. public class Oi{ ... } Arquivo “Oi.java” Compilador Java “javac.exe” Êþº¾ 1 � � � <init>� �()V� �Code� �LineNumberTable� �main� �([Ljava/lang/String;)... Arquivo “Oi.class” bytecode Máquina Virtual Máquina Virtual Máquina Virtual Máquina Virtual Máquina Virtual INTERPRETA Estilos Arquiteturais Máquina Virtual > Baseado em Regras Conjunto de regras sobre um estado. Definição do estado atual com base em dados de entrada. Regras alteram o estado. Estilos Arquiteturais Máquina Virtual > Baseado em Regras Exemplo: Prolog, Sistemas Especialistas. SE “HORA=21:00” ENTÃO “AÇÃO=LANCHE” SE “HORA=22:00” ENTÃO “AÇÃO=LIBERAR” SE “HORA<19:00” ENTÃO “AÇÃO=ESPERAR” SE “HORA=19:00” ENTÃO “AÇÃO=COMEÇAR” HORA = ? AÇÃO = ? Máquina de inferência HORA=18:00 Base de Regras Memória de trabalho Estilos Arquiteturais Centrado nos Dados > Repositório Clientes operam sobre os dados. Integridade dos dados. Maior escalabilidade para incluir novos clientes. Dados compartilhados Cliente 1 Cliente 2 Cliente 3 Cliente n Estado atual consistente Estilos Arquiteturais Centrado nos Dados > Quadro Negro 2 x (3+2)2 + 3 - 6 = ? Sei somar! Sei multiplicar! Sei subtrair! Sei exponencial! + -x Controlador Estilos Arquiteturais Centrado nos Dados > Quadro Negro Quadro Negro Ap 4 Ap 5 Ap n Ap 3 Ap 2 Ap 1 Controlador Estilos Arquiteturais Centrado nos Dados > Quadro Negro Sistemas complexos Resolução distribuída de problemas. Aplicações independentes Escalabilidade. Grande problema se ocorrer falhas no quadro negro. Bastante utilizada no paradigma de agentes. Arquiteturas de referência Os modelos de arquitetura podem ser específicos para algum domínio de aplicação. Existe dois tipos de modelos de domínio específico Modelos genéricos que são abstrações de uma série de sistemas reais que englobam as caracterísiticas principais desses sistemas. Abordados no Capítulo 13. Modelos de referência são mais abstratos, é um modelo idealizado. Fornece um meio de informação sobre essa classe de sistema e sobre comparação de arquiteturas diferentes. Os modelos genéricos são geralmente modelos bottom- up. Os modelos de referência são modelos top-down. Arquiteturas de referência Os modelos de referência são derivados de um estudo de domínio de aplicação ao invés de sistemas existentes. Pode ser usado como base para a implementação de sistemas, ou comparar sistemas diferentes. Atua como um padrão contra o qual os sistemas podem ser avaliados. O modelo OSI é um modelo de camadas para sistemas de comunicação. Modelo de referência OSI Modelo CASE de referência Serviços de repositório de dados Armazenamento e gerenciamento de itens de dados. Serviços de integração de dados Gerenciamento de grupos de entidades. Serviços de gerenciamento de tarefas Definição e aprovação de modelos de processo. Serviços de mensagens Comunicação ferramenta-ferramenta e ferramenta-ambiente. Serviços de interface de usuário Desenvolvimento de interfacede usuário. O modelo de referência ECMA Modelos de arquitetura Modelos diferentes de arquitetura podem ser produzidos durante o processo de projeto. Cada modelo apresenta perspectivas diferentes sobre a arquitetura. Atributos de arquitetura Desempenho Localizar operações críticas e minimizar comunicações. Proteção Usar uma arquitetura em camadas com itens críticos nas camadas mais internas. Segurança Isolar componentes críticos de segurança Disponibilidade Incluir componentes redundantes na arquitetura. Facilidade de manutenção Usar componentes substituíveis e de baixa granulariade. Pontos-chave A arquitetura de software é o framework fundamental para a estruturação de sistema. Decisões de projeto de arquitetura incluem decisões sobre o tipo de aplicação, a distribuição e os estilos de arquitetura a serem usados. Modelos diferentes de arquitetura, tais como um modelo de estrutura, um modelo de controle e um modelo de decomposição podem ser desenvolvidos. Modelos organizacionais de um sistema incluem modelos de repositório, modelos cliente-servidor e modelos de máquina abstrata. Pontos-chave Modelos de decomposição modular incluem modelos de objetos e modelos de pipelining. Modelos de controle incluem modelos de controle centralizado e dirigidos a eventos. Arquiteturas de referência podem ser usadas para comunicar arquiteturas de domínio específico, avaliar e comparar projetos de arquitetura. Referências BEZERRA, E. Princípios de Análise e Projeto com UML. Novatec, 2007. PRESSMAN, R. Engenharia de Software. McGraw Hill, 2006. SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.
Compartilhar