arquitetura de software - introdução

Arquitetura de SoftwareVisã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çõesSistema 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çõesGarlan 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 vidaO 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 outros

Uma 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• 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 globaldo sistema

Esquema para os desenvolv:•preciso•Sem ambigui-dade

© 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 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.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 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 ViewsMostra 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 ArchitectThe 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 demodelagem e métodos de desenvolvimento. Entendimento das estratégias de negócios dainstituição onde atua. Conhecimento de produtos, processos eestraté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.pdf

The Role of the Architecthttp://www.bredemeyer.com/pdf_files/role.pdf

Architecture Competencehttp://www.sei.cmu.edu/architecture/research/competence/index.cfm

On 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=97235781

The Duties, Skills, and Knowledge of Software Architectshttp://www.sei.cmu.edu/library/abstracts/news-at-sei/architect200701.cfm

Enterprise Solution Architects and Leadershiphttp://blogs.msdn.com/gabriel_morgan/archive/2009/01/17/enterprise-solution-

architects-and-leadership.aspx