Arquitetura de Software Introdução Por quê? O que? Como? Onde? e Quem? Thober Detofeno, Msc....

Preview:

Citation preview

Arquitetura de SoftwareIntrodução

Por quê? O que? Como? Onde? e Quem?

Thober Detofeno, Msc.Udesc2015

Resumo• Arquitetura de software é o caminho para:

– conectar as metas de negócios ao que iremos construir– obter alinhamento– organizar a atividade de produção de código– envolver as diferentes competências de um time

• Arquitetura está muito ligada à vantagem competitiva• Arquitetura não se obtém facilmente:

– é um trabalho de design não trivial– cada um tem um papel a desempenhar na sua criação– é melhor construída por um time pequeno de “arquitetos”

dedicados que dirigem o processo e tomas as decisões

Arquitetura funciona como o “plano de vôo” do desenvolvimento. Ela deve facilitar o alcance da estratégia de negócio – torna-se a implementação técnica da estratégia de negócio.

Suponha o seguinte• O Garten Shopping pretende construir uma nova

área. Vários aspectos do novo negócio foram levantados pelos executivos. É chegado o momento de traçar os planos e prazos da nova construção. Eles pretendem uma construção rápida, pois vários lojistas estão à espera. Os construtores foram divididos em times. Ao time mais experiente foi entregue a tarefa de traçar a arquitetura do novo shopping. Cada parte da arquitetura foi entregue a um dos time para construção.

• O que foi obtido ao final?

Nós iremos construir um shopping?

Time 1Lado Leste

Time 2Link A

Time 3Link B Tim

e 4

Circular

Time 5

Lado Sul

Aqui um exemplo de uma arquitetura base e seus requisitos. É só construir ela!

Requisitos:• estilo típico• praça da alimentação central• ...

Certo. Mas nós não entregamos modelos...

• No negócio software, nós entregamos código, e temos um certo desconforto em trabalhar com modelos.

• Porém, se olhamos para o negócio da construção civil, eles entregam “prédios” e não plantas e, não iniciam um novo projeto complexo sem começar por desenhos de tais estruturas físicas.

Nós construímos o shopping!

Construir uma arquitetura de software é similar...

• Na construção civil é lugar comum – sente-se a necessidade de plantas antes de se iniciar uma nova construção.

• Existem vários aspectos que se relacionam com integridade, integração entre equipes, consistência nos detalhes.

• Um plano de atividades é gerado, definindo uma sequência clara, incluindo aspectos de sua estrutura: entradas de luz, tolerância a ventos fortes, (em alguns casos) suportar movimentação de equipamentos pesados. Ou seja, existem condições típicas e atípicas a serem consideradas.

• O que resulta de uma arquitetura incompleta?

Adaptações na arquitetura...

É muito fácil obter um “sistema espaguete”!

...as adaptações podem levar ao caos!

• Tudo começa com as primeiras decisões de cortes ou extensões na arquitetura, com a justificativa de melhor atender aos requisitos. Aumenta o número de ajustes e o acoplamento cresce a ponto de não se poder mais isolar os componentes.

• É assim que um sistema deve evoluir?

É a desintegração do sistema, não sua evolução!

Seria um problema do negócio Software?

• Um sistema típico de software é perecível, resultado de:

• incertezas– no comportamento do

sistema– nas próximas release

• baixa qualidade– difícil rastrear falhas– difícil consertar bugs

• difícil alterar– duro atender às mudanças– custa mais, leva mais

tempo

• Baixo reuso– difícil isolar blocos para

reuso– blocos são muito

específicos (orientados)• problemas éticos• perda de market share

– o concorrente é melhor– não há retorno

A Arquitetura faz a diferença!

• Uma arquitetura é algo mais que um “rascunho desenhado” do sistema

• A arquitetura é alinhada a...

Conceitos chaves

• Decomposição do sistema– Como eu quebro o sistema em partes?– Tenho todas as partes necessárias?– As partes se encaixam?

• Trade-offs de interesse– Aspectos de qualidade mais abrangentes ou

propriedades específicas do sistema– Relação entre os atributos de qualidade

• Integridade do sistema

Decomposição da arquitetura: as partes se encaixam?

• Ao atribuir essa tarefa para o melhor “engenheiro” do time, que entende de:– Motor– Transmissão– Suspensão– Etc

• Podemos construir o melhor carro?

Arquitetura deve ter foco nas “propriedades mais críticas primeiro”

• Ideia chave: a integridade do sistema não pode ser alcançada de forma bottom-up

• Você irá precisar de uma visão mais abrangente do sistema– Analise os trade-offs existentes para

assegurar que as propriedades críticas do sistema continuam sendo atendidas quando você o decompõe em partes

– Projete os mecanismos da arquitetura que endereçam as propriedades do sistema

Ou seja...• Se temos em mãos uma dada aplicação, todas as

decisões que podem ser tomadas por projetistas de componentes ou desenvolvedores devem ser atribuídas a eles e não surgir como parte da arquitetura. Se o escopo da arquitetura é uma linha de produtos, então toda decisão referente a um dado produto deve constar, pelo menos, na arquitetura do produto se não for possível constar na arquitetura da linha de produtos.

• Qualquer decisão deve focar no impacto sobre o sistema – decisões arquiteturais devem focar nas propriedades de alto impacto nas áreas que estão altamente alinhadas com a estratégia do negócio.

Escopo das decisões arquiteturais: Exemplo do Reuso

• Quando focamos num dado produto, todas as decisões são orientadas para atender às demandas do respectivo cliente – o que torna tais componentes menos adequados para outros produtos.

• Ao construir arquiteturas devemos analisar os trade-offs de forma mais ampla, adequando-os aos sistemas globalmente. Decisões sobre propriedades individuais devem ser consideradas como parte da arquitetura do sistema como um todo.

Prioridades do sistema

• A atenção deve estar voltada para as áreas de alta prioridade e para os trade-offs entre elas:– o negócio (estratégias, competências e recursos)– o mercado (clientes, concorrentes e parceiros)– tecnologia (desafios e oportunidades)– riscos (investimentos em tecnologias e sistemas

legados)– desafios ao sucesso do sistema (desenvolvimento em

si e do negócio)

Arquitetura de Software: Conceitos chaves

• Decomposição do sistema

• Trade-offs entre propriedades

• Integridade do sistema

• Alinhamento com o negócio– Com a estratégia do

negócio– Com o ambiente do

negócio• Legado• Cultura

• Evolução do sistema– Vida longa!– Esquema para a estratégia

de implementação– Lidar com as mudanças,

inevitáveis!

Não esqueça!• Decisão bottom-up Estratégia bottom-up

– Pode ser um caminho muito arriscado! Nesse caso a estratégia real do negócio irá ser resultante das decisões dos desenvolvedores...

• Estratégia top-down: Estratégia do negócio Estratégia da arquitetura Estratégia da implementação– A estratégia do negócio é quem dirige a arquitetura, que é

traduzida tecnicamente para suportar toda a evolução do desenvolvimento.

Por quê isto é tão importante?

• Permite que sejamos– Mais produtivos– Mais criativos– Mais orientados por nossa estratégia

• De forma que podemos ser– Mais flexíveis, dando retorno ágil

• aos ajustes necessários (mudanças)• fazendo mais

– Ser um player dominante no mercado– Estar no negócio, mesmo 5 anos mais tarde

O que é uma arquitetura? (definição formal)

• “arquitetura é a estrutura do sistema, que compreende:– componentes ou partes da implementação– as propriedades visíveis externamente

desses componentes, e– as relações entre eles.”

Arquitetura: componentes e relações

• Componentes– Blocos (alto nível) do sistema– Suporta

• Modularidade• Separação de papéis

– Colaboração entre componentes• Prover serviços (funcionalidades)• Num dado nível de serviço (qualidades)

– Interface entre componentes• Provê encapsulação, com pontos de acesso restritos

– Especificação dos componentes• Define propriedades visíveis externamente• Provê guias de utilização

Propriedades visíveis externamente: o propósito das interfaces

• Interfaces– Define os pontos de acesso aos componentes– Facilita o plug-and-play entre componentes

• ameniza restrições entre clientes e provedores• Serve como um contrato entre provedores de componentes

e clientes– Define externamente propriedades visíveis

• Uma interface bem definida– Facilita o entendimento e compreensão do

comportamento do componente e como ele é usado– Aumenta a produtividade do desenvolvedor

• Foca na montagem e ligação entre componentes através de suas interfaces

Visões da arquitetura

• Clientes diferentes apresentam diferentes informações sobre suas necessidades

Stakeholders da arquitetura• Gerentes• Arquitetos• Desenvolvedores• QA• Suporte• Marketing• Usuários• Tomadores de decisão (mercado)• Administradores de sistemas

Processo de construção de uma arquitetura: Objetivos

• Criar uma arquitetura:– BOA, tecnicamente válida e bem

documentada– CORRETA, satisfaz aos requisitos dos

stakeholders– De SUCESSO, como as utilizadas na

construção civil

Arquitetura

Arquitetura

• Resumindo, a arquitetura é também determinada pelo contexto (eventualmente dirigido por questões não-técnicas)

• Diferentes stakeholders podem julgar como principais diferentes conjuntos de decisões

Camadas

Camadas

Camadas

Recommended