• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Arquitetura de software - Introdução

on

  • 1,056 views

 

Statistics

Views

Total Views
1,056
Views on SlideShare
1,056
Embed Views
0

Actions

Likes
0
Downloads
35
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Arquitetura de software - Introdução Arquitetura de software - Introdução Presentation Transcript

    • Arquitetura de Software Visão Geral
    • Introdução
      • Emerge a partir dos anos 80 como o principal meio de estudo para a infra-estruturas de grandes sistemas de software.
        • Inicialmente a pesquisa visava a pratica da construção do software e agora a área oferece uma notação mais concreta para ajudar no desenvlvimento e projeto de software com alto grau de complexidade.
    • Introdução
      • Um ponto crítico no projeto e na construção de todo o sistema de software é sua arquitetura: isto é, sua organização bruta como uma coleção de componentes de interação.
      • Uma boa arquitetura pode permitir que um sistema satisfaça às exigências chaves em áreas como: o desempenho, a confiabilidade, a portabilidade, a escalabilidade, e a sua interoperabilidade.
      • Uma arquitetura má pode ser desastrosa.
    • Introdução
      • No Passado, a arquitetura recebeu uma crescente atenção como uma sub-área importante da Engenharia de Software. Os especialistas pregam que uma boa arquitetura é um fator crítico de sucesso para o projeto e o desenvolvimento do sistema. Começaram a reconhecer o valor de fazer escolhas arquiteturais explícitas.
    • Introdução
      • Apesar da existência de livros, artigos e ferramentas, a Arquitetura de Software todavia ainda está em uma fase pouco madura.
      • Histórico: FASES
    • Fase1- Pesquisa básica: 1985-1994
      • Nesta fase os projetistas descreviam suas estruturas utilizando-se de diagrams compostos de caixa-e-setas e notas informais . Experientes projetistas reconheciam a fragilidade da metodologia utilizada de forma ad hoc . Estas estruturas algumas vezes eram chamadas de arquitetura embora nem sempre tivessem o seu processo realizado de forma sistemática .
      • Em meados dos anos 80, várias ideias se firmaram tais como: ocultamento da informação, tipos abstratos de dados, orientação a objetos e herança. Estas técnicas contribuiram para a ideia de considerar softwares como caixas pretas. A orientação a objetos foi importante na fixaçao deste conceito.
      • Outras qualidades como dependabilidade e manutenibilidade foram discutidas.
    • Fase1- Pesquisa básica: 1985-1994
      • Desenvolvedores iniciavam a exploração das ideias de especialização do software para problemas específicos . Alguns trabalhos focaram em estruturas de software para produtos particulares com: aviação, osciloscópios e controle de misseis.
      • Paralelamente, iniciaram a catalogação de soluções estruturais comuns a diversas áreas e a ideia de arquitetura tomou forma. Estruturas como pipe-filter, repositórios, invocação implícita, processos cooperativos ajudaram a identificar arquiteturas para classes de problemas específicos e desta forma permitir uma melhor formalização da solução.
    • Fase2: Formalização do conceito: 1992-1996
      • Modelos básicos foram elaborados e explorados largaente através da descrição de linguagens de arquiteturas, recentemente formalizadas e classificadas. A idéia principal estava centrada nas estruturas do software que eram comumente encontradas em outros sistemas. Os estudos nesta época ajudaram a organizar os princípios das boas práticas.
      • As Principais linguagens de descrição de arquiteturas (ADLs) eram:
        • Aesop (explorava propriedades específicas de estilos arquiteturais),
        • C2 (explorava o poder de estilos baseados em eventos),
        • Darwin (projeto e especificação de sistemas distribuidos),
        • Meta-H (projetos de contrloes em tempo real para aviação),
        • Rapide (simulação e analise de sistemas com comportamento dinamico),
        • UniCon (uso de conectores), e
        • Wright (interação entre componentes).
      • O importante desta fase foi a conscientização do conceito de visão arquitetural como um conceito de trabalho.
    • Fase3: Development and extension phase: 1995-2000
      • Durante esta fase, ocorre a troca do foco para a unificação e refinamento dos conceitos iniciais. O refinamento das taxonomias dos elementos arquiteturais e linguagens também ocorreu.
      • Ocorre uma maturidade dos institutos de pesquisa, pesquisadores e desenvolvedores. O IEEE - Transactions on Software Engineering, em 1995 lança um número especial no tema software architecture .
    • Fase4: Aumento do uso interno do conceito e exploraçaõ:1996-2003
      • O coneito estilos arquiteturais , nesta fase, passou a ser conhecido como padrões arquiteturais .
      • Avaliação e análise de arquiteturas tomam corpo como tópicos de pesquisa.
      • Trabalha-se na ideia de construção de ferramentas case para automatizar o processo de contrução de arquiteturas.
    • Fase5: Aumento do uso externo do conceito e exploraçaõ:1998-present
      • Ocorre a maturidade do conceito e com isso a sua externalização (industria, governo, etc).
      • Uso da UML como um padrão para a descrição de arquiteturas, junto com o pacote da Rational.
    • Fase6: Popularização: 2000-present
      • A popularização foi caracterizada pela produção qualificada, suporte,comercialização e marketing de produtos para a comunidade interna e externa.
      • Padrões arquiteturias foram fortemente utilizados com a explosão da W orld W ide W eb e web-based e-commerce. Tecnologias como N-tier client-server architectures , agent-based architectures , e Service- Oriented Architectures ajudaram na fixação e uso do conceito.
    •  
    • Arquitetura de Software, porquê é importante?
      • Comunicação da equipe.
      • Antecipação dos aspectos de decisões de infra-estrutura.
      • Transferênicia da abstração de um sistema de software para outro.
      • Importante veículo de comunicação com os Stakeholder .
    • Definições
      • Sistema de Computação
      • UML 1.3 : A system is a collection of connected units that are organized to accomplish a specific purpose. A system can be described by one or more models, possibly from different viewpoints.
      • IEEE Std. 610.12-1990: A system is a collection of components organized to accomplish a specific function or set of functions.
      • Arquitetura de software
      • UML 1.3: Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.
      • Bass, Clements, and Kazman. Software Architecture in Practice , Addison-Wesley 1997:
      • 'The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
      © http://www.bredemeyer.com
    • Definições
      • Garlan and Perry, guest editorial to the IEEE Transactions on Software Engineering , April 1995:
      • Software architecture is "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time."
      • Dewayne E. Perry and Alexander L. Wolf. " Foundations for the Study of Software Architecture ''. ACM SIGSOFT Software Engineering Notes , 17:4, October 1992:
      • "... software architecture is a set of architectural (or, if you will, design) elements that have a particular form.
      • We distinguish three different classes of architectural element: - processing elements; - data elements; and - connecting elements.“
      • IEEE Std. 610.12-1990:
      • Architecture is the organizational structure of a system.
      © http://www.bredemeyer.com
    • Definições
      • Apesar de existirem numerosas definições sobre arquitetura do software, no núcleo de tudo está a noção de que a arquitetura de um sistema descreve sua estrutura bruta .
      • Esta estrutura ilumina as decisões de projeto de alto nível, incluindo coisas como:
        • o sistema é composto das peças de interação, onde estão os principais caminhos de interação
        • Adicionalmente, uma descrição arquitetural inclui informação suficiente para permitir a análise de alto nível e crítica do sistema .
    • Podemos fazer melhor que isto! ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Motivação
    • O papel da Arquitetura de Software
    • Quais requisitos são importante na elaboração deu ma Arquitetura?
    • Fatores que influenciam a Arquitetura
      • Arquitetura de software é influenciada por:
        • Todos os usuários do sistema;
        • Fatores Técnicos e Organizacional da empresa;
        • Experiência do Arquiteto de Software.
    •  
    • Fatores que influenciam a Arquitetura
      • Desenvolvimento da Organização
        • Aspectos de Negócios
          • Investir em, ou amortizar a infra-estrutura?
          • Reduzir o custo de instalação.
          • Investir em novos funcionários ou não?
        • Aspectos Organizacionais
          • Manter o modelo de negócios usado atualmente?
    • Ambiente Técnico
      • Hoje a organização utiliza:
        • Modelo de banco de dados XYZ,
        • Web Browser para difundir as informações entre plataformas.
        • Isto ainda será verdade para daqui há 10 anos?
    • Experiência do Arquiteto
      • Experiências com projetos de sucesso,
        • Implica em replicar o modelo!
      • Experiência com projetos desastrosos
        • Implica em desenvolver regras para evitar tal situação!
    •  
    • O que é Arquitetura de Software?
    • Ciclo de vida
      • O clico de vida da arquitetura de software compreende:
      • Criar a arquitetura
        • Usando padroes arquiteturais, design patterns e experiências passadas
      • Avaliar a Arquitetura
      • Refinar, atualizar e refatorar a arquitetura dentro do ciclo de vida do produto
      • Usar a arquitetura como um guia para a implementação
      • Tentar enfatizar a arquitetura durante a implementação
      ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Visões diferentes para cada público!
    • O que você e o seu gerente entendem disto?
    • O que você e o seu gerente entendem disto?
    • Visões diferentes para cada público!
    • Arquitetura de Software: Visões
      • Sistemas são compostos de várias estruturas:
      • Unidades de código, suas decomposições e dependências;
      • Processos e suas interações;
      • Como o software é masterizado no hardware;
      • e outros
      • Uma View é uma representaçao destas estruturas, isto é, a representação de um conjunto de elementos e seus relacionamentos
    • Visões
      • Um arquiteto pode considerar 4 visões:
      • Como estruturar como um código de unidades?
        • Usando módulos
      • Como é estruturado o conjunto de elementos em tempo de execução?
        • Usando visão de Runtime
      • Como os artefatos são organizados no sistema e como ocorre o deployment?
        • Usar visão de Deployment
      • Qual a estrutura de dados do repositorio?
        • Modelo de dados
    • Visões
      • Arquitetura Conceitual
      • Diagramas arquiteturais, especificação informal de componentes
      • Foco: identificação e alocação de responsabilidades entre componentes
      • Arquitetura Lógica
      • Atualiza os diagramas arquiteturais (apresentando as interfaces), especificação interface, especificação de componentes e guias de utilização
      • Foco: design da interação, mecanismos e protocolos de conexão; provimento de info contextual para os usuários dos componentes
      • Arquitetura Execução
      • Visão do Processo (via Diagramas de Colaboração)
      • Foco: informa como se dará o comportamento do componente em tempo de execução, threads; como eles se comunicam; como os recursos físicos são alocados.
      Visão global do sistema
      • Esquema para os desenvolv:
      • preciso
      • Sem ambigui-dade
      © http://www.bredemeyer.com
    • Decisões Arquiteturais
    • Modulo Views
      • Mostra estruturas do sistema em termos de unidades de código.
      • Elementos: módulos, unidades de código que implementam alguma funcionalidade
      • Relacionamentos:
        • A é parte de B: relação todo-parte entre módulos
        • A depende de B: relação de dependência entre os módulos
        • A é B: relação de especialização/generalização entre módulos ou realização de interfaces
    • UML: relação entre módulos ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Módulo View: alto nível ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Módulo View: alto nível ©2006 JavaOneSM Conference | Session TS-4619 | 2
      • Para que o Module Views é bom?
    • Para que um Module Views é bom?
      • Auxilia na :
      • Construção - blueprints (modelo, boas praticas) para o código fonte.
      • Treinamento de novos desenvolvedores.
      • Analise de mudancas e seus impactos.
      • Visão de custos, atribuição de tarefas, tracking.
    • Runtime Views
      • Mostra as estruturas do sistema em execução.
      • Elementos:
      • Componentes que estão presentes em tempo de execução (processos, threads, componentes EJBtm, servlets, DLLs, objetos, etc).
        • Dispositivos de armazenamento.
      • Relacções:
      • mecanismos de interação baseados em tecnologias.
        • Arquiteto deve diferenciar: Chamadas locais de remotas.
        • Invocação síncrona de assíncorna.
    • Runtime Views: notação informal
    • Runtime Views: com UML 2.0 Componentes (como subtipos de classes) Portas (as quais podem ter multiplas instancias) Interfaces externas e internas (opcionalmente conectadas por meio de portas) Assembly conector Estruturas internas das classes Conector de delegação ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Runtime Views: com SOA ©2006 JavaOneSM Conference | Session TS-4619 | 2
      • Para que o Runtime Views é bom?
    • Para que um Runtime Views é bom?
      • Ajuda a clarificar:
      • Como os componentes interagem em tempo de execução.
      • Quais os componentes que estão duplicados.
      • Como o sistema trabalha.
      • Análise de propriedades em tempo de execução.
      • Análise de critérios de performance.
      • Análise de critérios de segurança.
      • Análise de critérios de confiabilidade.
      ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views
      • Mostra duas relevantes estruturas:
      • 1. Infra-estruturas de Hardware do ambiente de produção.
      • 2. Estruturas de diretórios e arquivos do sistema para execução.
      • Elementos:
      • Nodos de processamento e comunicação (sevidores, routers).
      • Diretórios e arquivos
      • Relacionamentos:
      • Mecanismos de interação entre canais de comunicação e Estruturas de diretórios.
      ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views: Infraestrutura de Hardware: notação informal ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views: Infraestrutura de Hardware usando UML 2.0 ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views: Infraestrutura de Hardware ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views: Deployment Files : notação informal ©2006 JavaOneSM Conference | Session TS-4619 | 2
    • Deployment Views: Deployment Files : notação UML 2.0 ©2006 JavaOneSM Conference | Session TS-4619 | 2
      • Para que a visão de Deployment é boa?
    • Para que a visão de Deployment Views é boa?
      • Ajuda a clarificar:
      • Definição de regras para deployment e procedimentos operacionais
      • Auditoria de falhas em tempo de execução
      • Planificação de aquisição de novos equipamentos
      • Analise de:
      • Disponibilidade
      • Performace ( throughput , largura de banda)
      • Segurança
      • Confiabilidade
      • Treinamento e melhoria de comunicação com os stakeholder
    • Data Model Views
      • Mostra as estruturas dos repositórios de dados
      • Elementos:
      • Entidades (elementos persistentes).
      • Relacionamentos:
      • 1:1, 1:n e n:n.
      • Generalização / Especialização.
      • Agregação.
    • Data Model: ER
    • Data Model: UML 2.0
      • Para que a visão de Data Model é boa?
    • Para que a visão de Data Model é boa?
      • Ajuda a clarificar:
      • Blueprint para Sistemas Gerenciadores de Banco de Dados.
      • Referência para todos os módulos que manipulam dados.
      • Database tuning.
      • Para melhorar a performance e modificabilidade do SGBD.
      • Para diminuir redundância.
      • Para aumentar a consistência.
      • O Arquiteto
    • The Matrix Reloaded Architect
    • The Matrix Reloaded Architect
      • The Architect - Hello, Neo.
      • Neo - Who are you?
      • The Architect - I am the Architect . I created the matrix . I've been waiting for you. You have many questions, and although the process has altered your consciousness, you remain irrevocably human. Ergo, some of my answers you will understand, and some of them you will not. Concordantly, while your first question may be the most pertinent, you may or may not realize it is also the most irrelevant.
      • Neo - Why am I here?
      • The Architect - Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix. You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden assiduously avoided, it is not unexpected, and thus not beyond a measure of control. Which has led you, inexorably, here.
      • Quais as competências de um arquiteto de software?
    • Áreas de competências
      • Tecnológica
      • Estratégias de negócios
      • Política organizacional
      • Consultoria organizacional / Treinamento
    • Áreas de competências
    • Arquiteto: habilidades desejadas
      • Compreensão profunda do domínio e tecnologias pertinentes.
      • Entendimento de aspectos técnicos para desenvolver sistema com sucesso.
      • Uso de técnicas de elicitação, técnicas de
      • modelagem e métodos de desenvolvimento.
      • Entendimento das estratégias de negócios da
      • instituição onde atua.
      • Conhecimento de produtos, processos e
      • estratégias de concorrentes.
      http://www.unibratec.com.br/revistacientifica/n1_artigos/n1_silvafilho.pdf
    • Arquiteto: tarefas atribuídas
      • Modelagem.
      • Análise de compromissos/viabilidade.
      • Prototipação, simulação, realização de experimentos.
      • Análise de tendências de tecnologias.
      • Atuar como mentor de arquitetos novatos
      http://www.unibratec.com.br/revistacientifica/n1_artigos/n1_silvafilho.pdf
    • Arquiteto de software: Competências
      • Who Needs an Architect?
      • http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
      • The Role of the Architect
      • http://www.bredemeyer.com/pdf_files/role.pdf
      • Architecture Competence
      • http://www.sei.cmu.edu/architecture/research/competence/index.cfm
      • On Identifying the Skills Needed for Software Architects
      • http://delivery.acm.org/10.1145/1380000/1373309/p1-downey.pdf?key1=1373309&key2=5267377621&coll=GUIDE&dl=GUIDE&CFID=80511111&CFTOKEN=97235781
      • The Duties, Skills, and Knowledge of Software Architects
      • http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect200701.cfm
      • Enterprise Solution Architects and Leadership
      • http://blogs.msdn.com/gabriel_morgan/archive/2009/01/17/enterprise-solution-architects-and-leadership.aspx