• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Arquitetura de Software Visão Geral
 

Arquitetura de Software Visão Geral

on

  • 3,045 views

Arquitetura de Software Visão Geral

Arquitetura de Software Visão Geral

Statistics

Views

Total Views
3,045
Views on SlideShare
3,045
Embed Views
0

Actions

Likes
1
Downloads
53
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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 Visão Geral Arquitetura de Software Visão Geral 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 World Wide Web 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   
    • 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õesSistemas 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 outrosUma View é uma representaçao destas estruturas, isto é, a  representação de um conjunto de elementos e seus  relacionamentos   
    • VisõesUm 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 Visão global • Diagramas arquiteturais, especificação informal de  do sistema componentes • Foco: identificação e alocação de responsabilidades entre  componentes Arquitetura Lógica Esquema  • Atualiza os diagramas arquiteturais (apresentando as  para os  interfaces), especificação interface, especificação de  desenvolv: componentes e guias de utilização •preciso • Foco: design da interação, mecanismos e protocolos de  conexão; provimento de info contextual para os usuários dos  •Sem  componentes ambigui­ dade 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. © http://www.bredemeyer.com
    • Decisões Arquiteturais   
    • Modulo ViewsMostra 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 ViewsMostra 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.0Componentes (como subtipos de classes)Portas (as quais podem ter multiplas instancias)Interfaces externas e internas (opcionalmente conectadas por meio de portas)Assembly conectorEstruturas internas das classesConector 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 ViewsMostra 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 arquivosRelacionamentos: 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 equipamentosAnalise de: Disponibilidade Performace (throughput, largura de banda) Segurança Confiabilidade Treinamento e melhoria de comunicação com os stakeholder    
    • Data Model ViewsMostra as estruturas dos repositórios de dadosElementos: 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 ArchitectThe Architect ­ Hello, Neo.Neo ­ Who are you?The Architect ­ I am the Architect. I created the matrix. Ive 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ênciasWho Needs an Architect?http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdfThe Role of the Architecthttp://www.bredemeyer.com/pdf_files/role.pdfArchitecture Competencehttp://www.sei.cmu.edu/architecture/research/competence/index.cfmOn Identifying the Skills Needed for Software Architectshttp://delivery.acm.org/10.1145/1380000/1373309/p1­downey.pdf? key1=1373309&key2=5267377621&coll=GUIDE&dl=GUIDE&CFID=80511111&CFTOKEN=97235781The Duties, Skills, and Knowledge of Software Architectshttp://www.sei.cmu.edu/library/abstracts/news­at­sei/architect200701.cfmEnterprise Solution Architects and Leadershiphttp://blogs.msdn.com/gabriel_morgan/archive/2009/01/17/enterprise­solution­architects­and­ leadership.aspx