Arquitetura de Software

Slides:



Advertisements
Apresentações semelhantes
Sistemas Distribuídos
Advertisements

ISO Processos do Ciclo de Vida do Software
UML Visões – Parte 2.
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Métricas de Software Prof.ª Adriana dos Santos Caparróz Carvalho.
(Unified Modeling Language)
Identificando requisitos
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
Processo inclui: Todas as principais atividades do processo
Engenharia de Software
Objetivos e princípios da OO
Metodologias Equipe do Curso de ES para SMA {lucena, furtado, choren,
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
1 Comunicação Inter-Processos -> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)
Análise Estruturada O mais amplamente usado dos métodos de modelagem de requisitos Modelos que retratam fluxo e o conteúdo da informação (dados e controle)
Objetos Distribuídos Padrão CORBA
Análise e Projeto de Sistemas
Introdução Visão Geral do Método.
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
Princípios e Conceitos de Software(v2)
Introdução a Arquitetura Orientada a serviços
Middleware e Sistemas Distribuídos
Fundamentos de Engenharia de SW
Arquitetura de software
Sistemas Distribuídos
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Prof. Kelly E. Medeiros Bacharel em Sistemas de Informação
Análise e Projeto de Sistemas
Metodologias para construção de SMA
Estilos de Arquitetura- uma outra visão
Engenharia de Software
Projeto de Banco de Dados
Metodologias (Parte II) Viviane Torres da Silva
SISTEMAS OPERACIONAIS I
Arquitetura de Software Visão Geral. Introdução  Um ponto crítico no projeto e na construção de todo o sistema de software é sua arquitetura: isto é,
O Processo Unificado (UP)
Tecgraf PUC-Rio Setembro de 2013 Introdução ao Openbus.
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Campus de Caraguatatuba Aula 2: Introdução a Tecnologia de BD
Engenharia de Software
RUP - Cap. 4 – Processo Centrado na Arquitetura
Laboratório de Programação
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Métodos Formais.
Padrões de Interação com o Usuário
Requisitos de Software
Integração de Ferramentas CASE
Desenvolvimento de Software Dirigido a Modelos
Introdução à Arquitetura de Software Virgínia C. C. de Paula - DIMAp/UFRN - DI/UFPE Nelson Souto Rosa - DI/UFPE Paulo R. F. Cunha - DI/UFPE.
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
CIn-UFPE1 Modelagem de Arquitetura com UML. CIn-UFPE2 Arquitetura de software n “Uma arquitetura de software deve conter: a definição dos elementos de.
1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG Março Rogério Dourado
Análise e Projeto de Sistemas Unified Modeling Language Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores.
Arquitetura de Software Projetos de Interface
Análise e Projeto de Sistemas
Estilos Arquiteturais
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
Versão 1 - julho/2013 Tecgraf PUC-Rio Novembro de 2013 Introdução ao OpenBus.
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
Interações entre objetos
TÉCNICAS DE ESTIMATIVAS
/ de Julho de UFPE - Universidade Federal de Pernambuco CIn - Centro de Informática Pós-Graduação em Ciência da Computação Tópicos Avançados.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/41 Análise e Projeto de Sistemas Arquitetura de Software.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Arquitetura de Software Universidade Federal de Pernambuco Centro de Informática Recife - Brazil

Introdução Raízes da disciplina Dijkstra, 1968 Parnas, 1970 - 1972 particionamento estruturação não só a programação Parnas, 1970 - 1972 famílias de programas economia no desenvolvimento e na manutenção

Introdução Raízes da disciplina DeRemmer, 1975 programming-in-the-large : programação da estrutura comum em sistemas distribuídos programming-in-the-small: programação das “funções” do sistema uso comum (C, Pascal)

Introdução Idéias fundamentais da Arquitetura de Software Estrutura é o ponto chave Reusabilidade de elementos de “grande escala” A orientação a objetos reusa elementos de “pequena escala”

Introdução Motivação problemas aumento do tamanho dos softwares aumento na complexidade dos softwares A importância da Arquitetura de Software para os projetistas de software nos anos 90 é comparável a importância das estruturas de dados para os programadores nos anos 60

Introdução Vantagens sistemas podem ser construídos rapidamente reusando-se ou gerando-se grandes componentes desenvolvidos independentemente predizer qualidades (desempenho, mantenabilidadde) do sistema a partir de sua arquitetura, sem um projeto ou um código detalhado

Introdução Vantagens comunicação decisões de projeto nas fases iniciais restrições sobre a implementação predizer atributos de qualidade base para treinos de iniciantes visão do sistema e das mudanças transferência de conhecimento linhas de produtos

Princípios Termo Disciplina  área emergente da ES  aborda as questões ligadas à estrutura do software Estrutura do software  várias definições  nenhuma aceita como padrão  semelhanças no núcleo das definições e diferenças nas características adicionais

Princípios Definição 1 “Uma arquitetura de software deve conter: a definição dos elementos de projeto que compõe o software; a descrição das interações entre estes elementos; os padrões de composição dos elementos; e um conjunto de restrições sobre estes padrões.”

Princípios Definição 2 “A descrição da arquitetura de software é um passo intermediário entre a análise de requisitos e o projeto. Esta descrição consiste de elementos arquiteturais, as interações entre estes elementos, e as restrições sobre estes elementos e sobre as suas interações.”

Princípios Definição 3 “Uma arquitetura de software é um conjunto de componentes genéricos junto com uma descrição de propriedades, regras de como estes componentes podem interagir, e estilo de interação destes componentes.”

Princípios “Arquitetura de software é a estrutura de Definição 4 “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.”

Princípios Modelos Perry & Wolf, 1992 elementos formas rationale processamento, armazenamento, interação formas propriedades dos elementos rationale restrições de composição dos elementos

Princípios Modelos Shaw & Garlan, 1996 Componentes Conectores Configuração

Princípios Componentes modela a computação e o armazenamento de informações desenvolvido independentemente exemplos de componentes cliente servidor aplicação inteira

Princípios Conectores modela as interações entre os componentes desenvolvido independentemente exemplos de conectores protocolos de comunicação

Princípios Configuração topologia composição conjunto de componentes combinados usando-se os conectores grafo de componentes e conectores ligados, descrevendo uma estrutura arquitetural

Princípios Visão de uma Arquitetura de Software Java C++ C Componente Configuração C++ Java C Componente Conector

Princípios Componentes e formas de interação Componentes Tipos de interação  Módulos Chamada de procedimento Dados compartilhados  Objetos Invocação de método  Filtros Fluxo de dados ( pipe )  Processos Passagem de mensagem, RPC  Arquivo de dados Leitura e escrita  Base de dados Consulta

Princípios Módulos Chamada de Procedimento Módulo

Princípios Objetos Objeto Invocação de método

Princípios Programas e funções Programa Principal funções Chamada de função

Princípios Software X Hardware Arquitetura de Hardware Arquitetura de Software  número pequeno de elementos de projeto  mudança de escala com a replicação dos  ênfase na organização e configuração  grande número de elementos de projeto  mudança de escala com a adição de novos  ênfase na organização e configuração

Princípios Software X Redes de Computadores Arquitetura de Rede Arquitetura de Software  nós  conexões  poucas topologias  componentes  conectores  muitas topologias

Princípios Software X Arquitetura de Construção Arquitetura de Software  visões enfatizando diferentes aspectos da construção  restrição sobre os elementos de projeto e a composição  estreita relação entre o estilo arquitetural e os princípios de engenharia  a relação entre o estilo e o material utilizado para a construção é fundamental  visões para diferentes e usuários  estilos arquiteturais  princípios de engenharia e estilo arquitetural  implementação ( algoritmos e estrutura de dados que satisfazem a arquitetura )

Princípios Sobre Arquitetura de Software descrição mais abstrata no ciclo de vida do software suprime detalhes da implementação Arquitetura de Software sempre existiu, mas era implícita

Princípios Sobre Arquitetura de Software separação de interesses funcionalidade interação Arquitetura de Software separa claramente a funcionalidade (componentes) da interação (conectores)

Funcionalidade+interação Princípios Sobre Arquitetura de Software Funcionalidade+interação interação Funcionalidade

Princípios Sobre Arquitetura de Software define aspectos estruturais importantes fornece uma base para as outras fases de desenvolvimento do software a arquitetura é normalmente descrita usando-se linhas e caixas de diagramas acompanhados por uma descrição textual

Princípios Desenvolvimento de software  Desenvolvimento tradicional  Desenvolvimento baseado em arquitetura Análise de requisitos Arquitetura Análise do domínio Desenvolver / escolher a arquitetura Representação da arquitetura Análise e avaliação da arquitetura Projeto Implementação

Princípios Arquitetura X Projeto Projeto  componentes e conectores  restrições sobre componentes e conectores  composição de componentes  procedimentos e interfaces  algoritmos e estruturas de dados  composição procedural

Princípios Por que definir uma Arquitetura? reuso de elementos de projeto permitindo maior rapidez na construção do software definindo-se uma arquitetura é possível predizer algumas características do software

Princípios Por que definir uma Arquitetura? facilita a comunicação entre os desenvolvedores do software permite um entendimento maior da evolução do software

Princípios Por que definir uma Arquitetura? possibilidade de análise da descrição da arquitetura nas fases iniciais do desenvolvimento consistência da configuração, componentes e conectores propriedades não funcionais conformidade com um determinado estilo

Estilos Arquiteturais Termo padrão organizacional padrão arquitetural padrão idiomático padrão de organização estrutural idioma arquitetural

Estilos Arquiteturais Termo “Um estilo arquitetural consiste de um vocabulário de elementos de projeto, um conjunto de regras de configuração, uma interpretação semântica da composição dos elementos, e um conjunto de análises que podem ser executadas sobre um sistema construído em um determinado estilo.”

Estilos Arquiteturais Termo Vocabulário idioma de projeto restringe os elementos arquiteturais que podem ser utilizados em uma descrição de arquitetura elementos arquiteturais: componentes , conectores

Estilos Arquiteturais Regras de Configuração restrições topólogicas restrigem as composições dos elementos arquiteturais proibição de ciclos no estilo Fipe-filter relacionamento n-para-1 no estilo Cliente-servidor

Estilos Arquiteturais Análise verificação de propriedades ausência de impasses em um estilo Cliente-servidor

Estilos Arquiteturais Sobre estilo arquitetural uso ad hoc “Camelot é baseado no modelo Cliente-servidor e usa RPC para comunicação remota e local dos clientes e servidores”

Estilos Arquiteturais Sobre estilo arquitetural define uma família e não apenas um sistema explora os pontos comuns entre famílias de sistemas e ignora detalhes específicos a construção de compiladores é o primeiro exemplo do uso de estilos

Estilos Arquiteturais Sobre estilo arquitetural a descrição da arquitetura é uma instância de um estilo exemplos Cliente-servidor Pipe-filter Objetos Invocação implícita Camadas, repositórios

Estilos Arquiteturais Arquitetura de software Request-reply Cliente Servidor Cliente Estilo Cliente-servidor Cliente

Estilos Arquiteturais Arquitetura de software Filtro Pipe Estilo Pipe-Filter Filtro Filtro

Estilos Arquiteturais Arquitetura de software Filtro Pipe Estilo Pipe-Filter Filtro Filtro

Estilos Arquiteturais Por que definir estilos reuso de projetos reuso de código o uso de estruturas convencionais facilita o entendimento da arquitetura “cliente-servidor”

Estilos Arquiteturais Por que definir estilos a restrição do espaço de projeto permite análises mais especializadas para os estilos “menos é mais”

Linguagem de Descrição de Arquitetura ADL - Architecture Description Language O que podemos esperar de uma linguagem para descrição de arquitetura de software? ênfase em estruturas de alto nível em oposição a detalhes de implementação

Linguagem de Descrição de Arquitetura Composição divisão hierárquica de um sistema complexo em partes menores Abstração explicitar a estrutura de mais alto nível Reusabilidade componentes, conectores e padrões de arquitetura

Linguagem de Descrição de Arquitetura Configuração separação da descrição de estruturas compostas da descrição dos elementos dessas composições Análise permite verificar propriedades dos sistemas, especialmente referentes a Arquiteturas Dinâmicas

Linguagem de Descrição de Arquitetura Heterogeneidade habilidade para combinar diferentes padrões arquiteturais em um mesmo sistema possibilidade de combinar componentes escritos em linguagens diferentes

Linguagem de Descrição de Arquitetura habilidade para representar componentes (primitivos ou compostos) habilidade para representar conectores abstração e encapsulamento tipos e checagem de tipos permitir a construção de ferramentas de análise

Linguagem de Descrição de Arquitetura abstração de componentes abstração de comunicação integridade de comunicação a comunicação é limitada a componentes conectados arquiteturalmente a outros habilidade de modelar arquiteturas

Linguagem de Descrição de Arquitetura Modelagem de componentes conceitos diferentes em cada ADL MetaH um programa C2 uma aplicação inteira (componentes hierárquicos) Wright componente

Linguagem de Descrição de Arquitetura Modelagem de componentes interfaces de componentes pontos de interação com o ambiente externo permitem a percepção da semântica dos componentes serviços oferecidos portas de comunicação

Linguagem de Descrição de Arquitetura Modelagem de componentes componentes como tipos para serem reusados uso explícito de parametrização ACME, Darwin e Rapide

Linguagem de Descrição de Arquitetura Modelagem de componentes restrições podem ser definidas por uma linguagem específica componentes podem evoluir subtipagem de componentes refinamento

Linguagem de Descrição de Arquitetura Modelagem de componentes especificação de propriedades não-funcionais permite simulação do comportamento em tempo de execução análise dos componentes verificação de restrições auxilia no gerenciamento do projeto

Linguagem de Descrição de Arquitetura Modelagem de conectores não necessariamente corresponde a uma unidade de compilação em uma implementação podem ser modelados explicitamente possuem interface própria

Linguagem de Descrição de Arquitetura Modelagem de conectores podem ser modelados como entidades de primeira classe tipos ou instâncias estabelecer restrições de uso via interface suportar evolução

Linguagem de Descrição de Arquitetura Modelagem de configurações a estrutura de um sistema deve, idealmente, permitir que a especificação da configuração seja compreendida sem se conhecer detalhes internos dos componentes e os conectores

Linguagem de Descrição de Arquitetura Modelagem de configurações descrição de configurações permite estimar aspectos concorrentes e distribuídos de uma arquitetura ADLs podem modelar evolução e dinamismo das configurações

Linguagem de Descrição de Arquitetura Modelagem de configurações suporte à composição hierárquica é fundamental em uma ADL em algumas ADLs uma configuração é modelada simplesmente como um componente composto Darwin, UniCon, CL

Linguagem de Descrição de Arquitetura Modelagem de configurações heterogeneidade uma configuração deve idealmente lidar com componentes e conectores programados em diversas linguagens

Linguagem de Descrição de Arquitetura Modelagem de configurações a especificação de restrições é fundamental para descrever dependências entre componentes e conectores Uma ADL deve permitir refinamento da arquitetura

Linguagem de Descrição de Arquitetura Modelagem de configurações devem suportar especificação e desenvolvimento de sistemas que possam sofrer alterações durante sua execução. C2 Darwin Rapide ZCL Wright

Linguagem de Descrição de Arquitetura Exemplo - Sistema de Monitoramento de Pacientes O sistema de monitoramento de pacientes consiste de medições periódicas ou por solicitação de pulso, temperatura e pressão através de sensores colocados no paciente. Tais sensores disparam um alarme sempre que qualquer das medições atingirem valores não adequados.

Linguagem de Descrição de Arquitetura Exemplo Hospital alarme alarme Enfermeira Paciente estado estado

Linguagem de Descrição de Arquitetura Exemplo - CL system hospital begin use task enfermeira, paciente; create cama from paciente; create cuidado from enfermeira ; link cama.alarme to cuidado.alarme; link cuidado.estado to cama.estado; activate cuidado, cama; end.

Linguagem de Descrição de Arquitetura Wright Componentes interface (portas) computação (comportamento) Conectores Role (comportamento de um único participante) Glue (comportamento completo) Configuração componentes + conectores

Linguagem de Descrição de Arquitetura Exemplo - pipe-filter Este sistema lê um conjunto caracteres e transforma-os em caracteres maiúsculos

Linguagem de Descrição de Arquitetura Exemplo - pipe-filter UpperCase input output Merge left right Split left right

Linguagem de Descrição de Arquitetura Exemplo - pipe-filter Component SplitFilter port input [entrada de dados] port left [porta de saída para o UpperCase] port right [porta de saída para o Merge] computation [lê dados e envia-os para as portas de saída] left right Split

Linguagem de Descrição de Arquitetura Exemplo - pipe-filter Connector Pipe role Source [envia dados repetidamente] role Sink [recebe dados repetidamente] glue right [Sink recebe dados na mesma ordem que foram enviados por Source] UpperCase input output

Linguagem de Descrição de Arquitetura Configuration Capitalise Component UpperCase ... Component MergeFilter ... Component SplitFilter ... Connector Pipe ... Instances Split : SplitFilter Upper: UpperCase Marge: MergeFilter P1, P2, P3 : Pipe Attachments Split.left as P1.Source Upper.input as P1.Sink Split.right as P2.Source Merge.right as P2.Sink Upper.output as P3.Source Merge.left as P3.Sink End Capitalise. Componentes Conector Instanciação Configuração

Linguagem de Descrição de Arquitetura Exemplo - incluindo comportamento A B out in {a} C {a,c} {b,c} A||C||B

Linguagem de Descrição de Arquitetura Configuration ABC Component A-Type Port Out =a Out   Computation = Out.a  Computation  Component B-Type Port In = c  In  Computation = In.c  b  Computation  Connector C-Type Role Origin = a  Origin  Role Target = c  Target  Glue Origin = Origin.a  Target.c  Glue  Instances A : A-Type B : B-Type C : C-Type Attachments A.Out as C.Origin B.In as C.Target End ABC.