|
|
Olá pessoal!
O título deste post pode ser interpretado sob duas perspectivas. Uma possível interpretação é “O que um arquiteto faz em seu dia-a-dia?”. Outra poderia ser “O que forma um arquiteto?”. Ambas as interpretações estão corretas e a resposta para ambas as questões é a mesma: Quality Attributes. Continue lendo e entenda o motivo.
 Neste post inicio uma série em que abordarei um assunto de extrema importância dentro de arquitetura de software: atributos de qualidade. Sob este nome o tema pode parecer um pouco obscuro, porém, pode se tornar familiar sob outra definição: requisitos não-funcionais.
O conteúdo deste e dos demais posts desta série é baseado principalmente no livro Software Architecture in Practice – Second Edition, já mencionado em posts anteriores, no conteúdo do curso Software Architecture Principles and Practices, ministrado pelo Software Engeneering Institute (SEI), sendo complementado por outros materiais.
O que são atributos de qualidade?
É possível dizer que atributos de qualidade são considerados em praticamente todos os esforços de desenvolvimento de sistemas. Muito provavelmente você (e eu também) considera atributos de qualidade em suas demandas de forma inconsciente. E para provar esta teoria, um exemplo de um sistema que não leva em consideração atributos de qualidade, seria um sistema estruturado de forma monolítica, sem nenhuma estrutura de organização interna. Quantas vezes você considerou esta abordagem nos sistemas que projetou?
Desta forma, percebemos que um sistema não tem como requisito apenas funcionalidades que deve prover (requisitos funcionais). Time-to-market (um atributo de qualidade voltado ao negócio) e modificabilidade são frequentemente atributos de qualidade (ou requisitos não funcionais) que levam a estruturação de um sistema em módulos, de forma que ele possa ser construído em paralelo por mais de uma pessoa (time-to-market), ao mesmo tempo atribuindo responsabilidades de forma coerente (low coupling e high coesion), o que possibilita maior facilidade em modificações futuras (modificabilidade). Estes, portanto, são os motivos que nos levam a não projetar um sistema monolítico: atributos de qualidade.
O mesmo vale quando falamos da opção pela utilização de um padrão MVC, por exemplo. Essa escolha tem (ou pelo menos deveria ter) como motivação não apenas o fato de se estar seguindo uma tendência recente. O padrão MVC possibilita a que um sistema tenha atributos de qualidade como modificabilidade, já que é estruturado em camadas com responsabilidades bem definidas (separation of concerns), permitindo, por exemplo, que alterações no design da aplicação (tela) não necessariamente afetem a lógica de programação, e vice-versa. Testabilidade é outro atributo de qualidade decorrente da utilização deste padrão, já que possibilita a execução de testes unitários na camada de apresentação, por exemplo. Ambos, modificabilidade e testabilidade, trazem como beneficio para o negócio atributos como um baixo time-to-market, já que manutenções evolutivas serão implementadas mais rapidamente, e maior disponibilidade (availability), já que a aplicação de testes unitários tende a reduzir o número de bugs de um sistema, tornando-o mais estável (disponível) para o usuário final.
Podemos entender então que atributos de qualidade são requisitos não-funcionais, ou seja, que não dizem respeito ao que o sistema deve prover em termos de funcionalidade, mas sim, em termos de qualidade. Existem diversas categorias de atributos de qualidade e diversos assuntos relacionados. Availability, modifyability, performance, security, testabiliy, usability, scalability, extensibility, reliability, são exemplos de atributos de qualidade. Existem também alguns conceitos mais difundidos que levam em consideração um subconjunto de atributos de qualidade específicos. Por exemplo:
· FURPS: functionality, usability, reliability, performance, supportability;
· ACID: atomicity, consistency, isolation, durability;
· ISO/IEC 9126: functionality, reliability, usability, efficiency, maintainability;
Por que atributos de qualidade são importantes?
No livro Software Architecture in Practice – Second Edition, é dado um exelente exemplo da importância dos atributos de qualidade:
“Sistemas são frequentemente substituídos ou redesenhados não porque suas funcionalidades são deficientes – as substituições geralmente são idênticas em termos de funcionalidades – mas porque eles são difíceis de manter, portar, escalar, ou porque são muito lentos, ou porque foram comprometidos por hackers” (minha tradução).
E apesar de tal importância, muito frequentemente apenas as funcionalidades são observadas em um ciclo de desenvolvimento de software. Especificações comumente não tratam de atributos de qualidade de forma satisfatória, apesar do fato de que tal detalhamento ser de total interesse dos representantes de negócios de uma organização (veja imagem ao lado – provida pelo SEI). E é ai que o papel do arquiteto torna-se importante dentro de um projeto. É do arquiteto a responsabilidade de delinear os atributos de qualidade de um sistema, caso eles não estejam especificados, de entendê-los, especificá-los segundo o conceito SMART e, posteriormente, de endereça-los através de praticas e padrões arquiteturais (veremos este assunto em detalhes mais adiante).
Por enquanto ficaremos por aqui. Nos próximos posts veremos como analisar, registrar e endereçar atributos de qualidade através de táticas arquiteturais. Depois, partiremos para questões especificas de alguns atributos de qualidade mais relevantes, como por exemplo, availability, performance, security, modifiability e testability. Até lá!
 Olá pessoal!
Neste post gostaria de compartilhar um resumo do conteúdo de um podcast que ouvi recentemente, cujo tema principal era justamente o título deste post: “Who gets to be a software architect”. Acredito que o assunto seja bastante relevante, pois tem sido tema de diversas discussões em diversas comunidades, demonstrando que ainda há pouca maturidade e falta de consenso no mercado.
O podcast foi disponibilizado pelo Oracle Technology Network, no canal ArchBeat, que trata de assuntos relacionados à arquitetura. Para quem ainda não conhece, vale a pena conferir. O canal aborda assuntos diversos relacionados à arquitetura, tecnologias e tendências, como SOA, Cloud Computing, Governança, Enterprise Architecture, Business Architecture, etc.
O podcast consistiu em uma panel discussion, composta por quatro participantes de peso, além do Bob Rhubart, host dos podcasts deste canal. São eles:
- Ron Batra: Oracle ACE Director, Diretor de desenvolvimento de produtos cloud computing na AT&T;
- Brian Huff: Oracle ACE Director, Chief Software Architect na Bezzotech, Inc.;
- Randy Stafford: Membro do Oracle’s A-Team – um grupo de arquitetos que trabalham em um grupo de desenvolvimento Oracle Middleware;
- Eric Stephens: Enterprise Architecture Director, na Oracle;
A seguir consta o link para mais detalhes do podcast, onde também pode ser baixado o áudio: https://blogs.oracle.com/archbeat/entry/show_notes_who_gets_to_be_a_so.
Separei o conteúdo da discussão em alguns temas, que podem ser conferidos a seguir. Procurei manter o conteúdo fiel ao que foi discutido no podcast, sem incluir opiniões pessoais e sem alterar o sentido ou opinião dos participantes.
O que separa o papel de um desenvolvedor do papel de um arquiteto
Arquitetos caminham na direção de uma liderança técnica, enquanto desenvolvedores estão mais focados em tarefas de codificação. Arquitetos produzem especificações técnicas, diagramas arquiteturais, mas não focam em bits e bytes o tempo todo. O arquiteto estrutura o que deve ser construído. Ao mesmo tempo, arquitetos devem saber programar seu design. Os melhores arquitetos iniciaram sua carreira como desenvolvedores e posteriormente assumiram novas responsabilidades gradualmente.
O fato de estar longe da codificação não exime do arquiteto a responsabilidade de se manter atualizado, contribuindo para o desenvolvimento, o que aumenta sua credibilidade perante o time.
Alguns soft skills diferenciam arquitetos de desenvolvedores. Arquitetos devem saber influenciar, devem ter visão, liderança, devem saber trabalhar com times diversos, comunicar decisões arquiteturais / design.
“The developers are the ones who build skyscrapers, while the architect is someone who designs the city, while enterprise architects are the city planners.“
Diferentes papeis dentro do tema “Arquitetura”
Alguns exemplos de diferentes papeis dentro do tema arquitetura foram citados, demonstrando que ao contrário do que comumente é entendido, não existe apenas o papel do Arquiteto de Aplicações / Sistemas:
- Infrastructure Architects: focam em detalhes de arquitetura de infraestrutura. Cluster, load balancing, firewalls, virtualização, servidores, etc, são temas recorrentes no seu dia-a-dia;
- Integration Architects: SOA, EAI e padrões relacionados são suas principais preocupações;
- Enterprise Architects: Conhecem o mapa de projetos / sistemas / frentes de negócios da corporação, estabelecem roadmaps de tecnologia e lidam com aspectos técnicos e também não-técnicos da organização.
- Application Architect: Trabalham no nível de projetos. Em geral estabelecem e comunicam visões arquiteturais, que compreendem decisões de design de um projeto.
O título de “Arquiteto” deve ser reservado para aqueles que possuem certificações?
Em geral, certificações mais técnicas focam em um produto ou framework especifico. Neste sentido, um profissional certificado será um excelente profissional para implementação de uma solução e-business, ou para identificar um determinado problema em uma base de dados ou aplicação java. Tais habilidades são extremamente valiosas para desenvolvedores / implementadores de solução, que em geral, procuram certificações para se distinguirem ou se destacarem.
Existem também organizações e certificações voltadas para as diversas segmentações dentro de arquitetura (infrastructure, information, business) e também voltadas à arquitetura corporativa (Enterprise Architecture). O IASA – International Association for Software Architects é uma organização que provê um mapa de carreira com cursos voltados para arquitetos e certificações relacionadas – veja imagem ao lado. O SEI – Software Engineering Institute também provê excelentes materiais e cursos relacionados à arquitetura de software. A Oracle também possui uma certificação voltada a Enterprise Architecture, chamada Oracle Enterprise Architecture Designation, além do Open Group, com o TOGAF.
Para arquitetos, além da competência técnica, habilidades de comunicação são cruciais. Normalmente, um arquiteto deverá passar sua visão para CIO, CTO, CEO, fornecedores, desenvolvedores, etc. Neste sentido, uma certificação não garante que o arquiteto seja competente o suficiente para realizar seu trabalho, já que é muito difícil certificar habilidades comunicacionais. Em geral, o que é levado em consideração na contratação de um arquiteto são suas experiências anteriores bem-sucedidas.
“The person (arquiteto) should have the ability to transcend one technology to the concept.”
Excelentes desenvolvedores podem se tornar arquitetos?
Se você é um excelente vendedor, não significa que você se tornará um excelente gerente de vendas. O mesmo vale para desenvolvedores e arquitetos. Algumas pessoas possuem profundos conhecimentos em bancos de dados, conhecem todas os truques para que o banco de dados ou o java faça exatamtente o que querem, e a forma mais rápida para resolver um problema em um sistema existente. Outras pessoas se dão muito bem quando trabalham em cima de requisitos difusos ou não claros.
É uma questão de mudança de ferramentas. Enquanto que para o desenvolvedor a principal ferramenta de comunicação é o teclado, para o arquiteto sua principal ferramenta deve ser o quadro branco e apresentações power point. Alguns desenvolvedores não gostam de se expor e não há nada de errado nisso. O mais importante é estar fazendo aquilo que se sente bem.
A discussão encerrou com o tema “hot-button issues” (más práticas), comummente cometidas por arquitetos.
- Decisões “make or buy” devem ser bem pensadas. Por vezes, arquitetos ou pessoas com tal responsabilidade (CIO) decidem por manter e investir em uma ferramenta desenvolvida “in-house”, enquanto que comprar um pacote de mercado e investir em sua implantação pode trazer uma melhor relação custo/beneficio a longo prazo.
- Um arquiteto não deve optar por tecnologias apenas por possuir conhecimento prévio. O benefício maior para a organização deve ser levado em consideração;
- Um arquiteto nunca deve misturar diversas visões em apenas um diagrama. É comum encontrar componentes de infraestrutura, fluxo de dados, aplicações, regras e camadas de negócios no mesmo diagrama. Diferentes áreas de conhecimento devem ser representadas em diferentes visões / diagramas.
- Excelentes comunicadores que não sabem desenvolver seu design não necessariamente são bons arquitetos.
- Utilizar tecnologias apenas porque todos estão usando, ou utilizar tecnologias recém-lançadas, cedendo ao apelo comercial, não necessariamente é a melhor solução. Arquitetos devem saber selecionar as tecnologias mais apropriadas para o problema em questão, e que melhor se adequem ao cenário da organização.
Olá pessoal!
Neste artigo veremos os demais padrões GRASP não abordados no anterior. São eles:
Controller – Determina que deve haver uma classe ou camada responsável por receber e tratar eventos da camada de interface com o usuário, delegando as ações para as camadas inferiores, de forma que ela funcione como intermediadora. O padrão também diz que pode ser criada uma controller para cada caso de uso. Ou seja, as funcionalidades providas pela interface, que dizem respeito a determinados casos de uso são delegadas para as controllers correspondentes. O objetivo com a controller é desacoplar (veja Low Coupling) a camada de interface com o usuário – que deve focar em apresentação, estilos, design, etc. – da implementação em si, desta forma aumentando a coesão (veja High Coesion), já que cada camada atenderá apenas a responsabilidades específicas e bem definidas.
Pure Fabrication – Determina que assuntos não diretamente relacionados ao domínio da aplicação devem ser tratados por classes apartadas, denominadas "invenção pura". Ou seja, aquilo que para o domínio da aplicação não faça sentido é considerado e apartado como uma "invenção". Um exemplo desta situação é o encapsulamento de funcionalidades e particularidades para acesso a um banco de dados (componentes que encapsulam o driver de acesso a banco de dados, como por exemplo, o ADO .NET), em classes específicas que possam ser reutilizadas dentre as demais classes que precisam da mesma funcionalidade. Classes utilitárias e diversas funcionalidades providas por frameworks em geral são consideradas invenções puras. Este padrão ajuda no aumento da coesão (veja High Coesion), uma vez que define que as classes de domínio não contenham funcionalidades que vão além das suas reais responsabilidades. Desta forma, o reuso também é favorecido, já que as invenções puras são extraídas do domínio, de forma que possam ser reutilizadas.
Polymorphism – O polimorfismo prega que operações polimórficas sejam utilizadas ao invés de decisões. Para ilustrar este conceito nada melhor que um exemplo. Considere uma classe Pessoa, com os atributos Nome, NumeroCpf, NumeroCnpj e Tipo (Fisica ou Juridica). Neste modelo, todas as classes que precisem obter o documento da pessoa muito provavelmente implementarão um IF com base no atributo Tipo e considerarão ou o NumeroCpf ou o NumeroCnpj como o documento. Segundo o padrão, criar uma operação polimórfica significa criar uma interface Pessoa com o atributo Nome e uma operação ObterDocumento e duas classes que implementam esta interface: PessoaFisica (NumeroCpf) e PessoaJuridica (NumeroCnpj). Cada classe fará sua própria implementação da operação ObterDocument o, de forma que os demais utilizadores não tenham mais que se preocupar com a regra para obtenção do documento com base no tipo da pessoa. Um benefício desta abordagem é que caso seja necessário adicionar um terceiro tipo de pessoa (PessoaEstrangeira), o impacto seria menor para as classes dependentes, já que a operação polimórfica é a mesma (ObterDocumento).
Indirection – Determina que o sistema não conheça e que não esteja acoplado (veja Low Coupling) às implementações reais e especificas de determinados assuntos. Projetar para indireção pode envolver a criação de camadas que encapsulam determinadas funcionalidades ou que desacoplem outras camadas. O padrão Controller é um exemplo de indireção, já que com ele a user interface não depende diretamente das camadas inferiores (model, por exemplo), e vice-versa. Existem diversas formas de se aplicar a indireção. Além do MVC, outro exemplo de aplicação deste conceito é a Injeção de Dependência, onde as implementações dependem de interfaces que são realizadas em objetos concretos apenas em tempo de execução. Diversos design-patterns também se beneficiam deste conceito, por exemplo: Abstract Factory, Facade, Adapter, Strategy, Proxy, etc. Um exemplo simples e recorrente de indireção é o que o Visual Studio faz quando adicionamos uma referência para um serviço em um projeto. Por traz dos panos são criadas classes Proxy que encapsulam toda a complexidade envolvida no processo de chamar um serviço através do protocolo utilizado (SOAP, p. ex.), serializar e deserializar objetos de transferência, tratar seu retorno, etc. Todo o restante do sistema que utiliza o objeto Proxy criado se quer sabe o que está por traz dele, de forma que se o protocolo de comunicação for alterado, por exemplo, nada será afetado além do Proxy.
Protected Variations – A variação protegida é uma forma de indireção. A diferença é que neste caso o principal objetivo é proteger o sistema ou uma classe de variações previstas ou que tenham grandes possibilidades de ocorrer. Um exemplo deste tipo de situação é quando utilizamos componentes ou serviços de terceiros1 ou mesmo quando precisamos integrar com APIs de pacotes de aplicações. Em todas estas situações a ideia é proteger seu sistema ou sua classe da possibilidade de alteração na interface do componente, do serviço ou da API. As mesmas abordagens e padrões utilizados para a indireção também se aplicam à variação protegida. Conceitos e padrões de EAI (Enterprise Application Integration) e SOA (Service Oriented Architecture) também apoiam a indireção e a variação protegida de uma forma mais ampla.
 Olá pessoal
Neste post vamos conhecer alguns conceitos de programação orientada a objetos (POO) que nos ajudam a pensar em como estruturar projetos orientados a objetos. Ambos os conceitos abordados neste post estão descritos no livro “Utilizando UML e Padrões – Uma introdução à Análise e ao Projeto Orientado a Objetos e ao Desenvolvimento Iterativo” de Craig Larman – Livro muito bom que trata em detalhes de diversos assuntos bastante pertinentes no nosso dia-a-dia: processos de desenvolvimento iterativos, incrementais e ágeis, papéis e responsabilidades, artefatos, UML, conceitos de programação orientada a objetos, RDD, padrões GRASP, design-patterns (GOF) e outros.
Vamos começar então pelo RDD. Segundo o livro, RDD é uma metáfora geral que nos leva a raciocinar sobre projetos de software orientados a objetos, sob o ponto de vista de responsabilidades. Por responsabilidades, entende-se o que nossas classes de objetos ou mesmo componentes de software devem fazer e saber. Em um modelo de classes o fazer é realizado por métodos e o saber por atributos. Outro conceito envolvido no RDD é o de colaboração. Uma vez definidas as responsabilidades, há de se definir como seus objetos colaboração para que o objetivo seja atingido.
Já o GRASP define nove padrões ou princípios voltados à atribuição de responsabilidades, que apoiam o RDD. Analisando estes conceitos e os padrões GRASP, que veremos em detalhe mais a frente, podemos concluir que ambos apenas endereçam questões básicas de orientação a objetos. E o objetivo é justamente esse. Tanto RDD quanto GRASP servem como uma ferramenta para apoiar no domínio de conceitos básicos de programação orientada a objetos. E quando falamos de conceitos básicos, logo veremos que diversos tópicos abordados fundamentam outros padrões mais específicos, como por exemplo, MVC e os design-patterns do GOF. Isso é interessante, porque para entender estes padrões mais específicos temos que ter os conceitos básicos bem fundamentados. Outro ponto importante é que alguns padrões não se restringe apenas ao mundo de orientação a objetos. Alguns conceitos empregados nos padrões High Coesion, High Coupling, Indirection e Protected Variation são altamente pertinentes e recorrentes em arquiitetura de software. Vamos então aos padrões GRASP.
Creator – Este padrão determina quem é responsável por criar quem. Uma das possibilidades a considerar, por exemplo, é que uma classe A deve ser responsável por criar uma classe B caso a classe A tenha uma relação de composição com a classe B. Outra possibilidade citada por este padrão é que a classe A pode ser responsável por criar a classe B caso ela tenha consigo informações suficientes para a inicialização da classe B ou caso use B de maneira muito próxima. Considere, por exemplo, uma relação entre uma classe NotaFiscal e Item, que usualmente denota uma relação de composição. Ou seja, uma nota fiscal é composta por itens de forma que não faça sentido sua existência sem eles. Neste exemplo, a responsabilidade por criar instâncias da classe Item seria da classe NotaFiscal, que poderia fazê-lo através de uma operação “IncluirItem”.
Information Expert – Determina a qual classe deve ser atribuída a responsabilidade de prover uma nova funcionalidade. O padrão diz que a classe que possuir mais informações a respeito da funcionalidade em questão deve ser a responsável por provê-la. Considerando o exemplo anterior (NotaFiscal – Item), caso precisássemos saber a quantidade de itens de uma nota ou o valor total do itens quem deveria ser a classe responsável? A classe NotaFiscal é a classe que tem mais informações sobre seus Itens, já que ela é composta por Itens, logo, as operações ObterQuantidaDeItens e ObterValorTotal é uma responsabilidade da classe NotaFiscal. Note que tanto este quanto o padrão Creator são bem básicos e definem conceitos bastante triviais. O que é importante observar é que ambos definem regras gerais que estão por traz do que fazemos por “intuição” no dia-a-dia.
High Coesion – A alta coesão diz respeito à criação de classes que tratem de assuntos focados e bem definidos. Uma classe não coesa é aquela que trata de diversos assuntos distintos, tornando-se difícil de entender, manter, testar, evoluir e reutilizar. A alta coesão também suporta o baixo acoplamento (veja Low Coupling).
Low Coupling – O baixo acoplamento diz respeito à redução de dependência entre classes de forma que uma necessidade de mudança tenha menor impacto nos objetos dependentes. Projetar para baixo acoplamento envolve a utilização de conceitos de alta coesão (veja High Coesion), pois, classes mais coesas são menos dependentes entre si. Imagine, por exemplo, uma classe que contenha implementações de diversos assuntos diferentes – não coesa. Todos os demais módulos do sistema que dependam dos assuntos contidos nesta classe dependerão de uma mesma classe, de forma que alterações em qualquer um dos assuntos abordados proporcionem maior risco para todos os demais. Projetar para baixo acoplamento também envolve utilização de conceitos de encapsulamento. Encapsular significa esconder do mundo externo particularidades, implementações e informações que não digam respeito diretamente ao negócio / domínio, ou que sejam sujeitas a mudanças. Uma vez que tais informações sejam escondidas atrás de propriedades ou operações, por exemplo, as demais classes não serão afetadas quando houver alterações – ou seja, terão baixo acoplamento. O baixo acoplamento também pode ser atingido através de técnicas utilizadas para indireção (veja Indirection) e variação protegida (veja Protected Variation).
Por enquanto é só. No próximo artigo devo trazer os demais padrões GRASP: Controller, Pure Fabrication, Polymorphism, Indirection e Protected Variation. Até lá.
 Olá Pessoal!
Neste post gostaria de compartilhar um trecho do livro “The Rational Unified Process: An Introduction (3rd Edition)” de Philippe Kruchten, disponível no capítulo 5 (An Architecture-Centric Process), página 84. O texto fala sobre uma definição de Arquitetura, que é um tema bastante pertinente, diante das várias abordagens e interpretações existentes no mercado para o escopo de atuação de uma área de arquitetura ou de um arquiteto.
Basicamente o texto fala que arquitetura presa pela estrutura de um sistema, sua decomposição em elementos, subsistemas e suas interfaces, juntamente com comportamento e colaboração entre elementos. Requisitos não funcionais (ou atributos de qualidade) também fazem parte da lista de itens que a arquitetura de um sistema deve contemplar, como por exemplo, performance, reuso, escalabilidade, resiliência, etc. Outro ponto importante mencionado é que arquitetura engloba não apenas aspectos técnicos, mas também econômicos e sociológicos. Podemos entender como aspectos econômicos os recursos e limite de orçamento disponível em um projeto. Por sociológicos, as pessoas envolvidas e como a arquitetura do sistema pode os afetar, sejam eles desenvolvedores, designers, gerentes de projetos, ou mesmo usuários.
Confira o trecho a seguir.
Many definitions of architecture have been proposed. The Rational Unified Process defines architecture as follows.
Architecture encompasses significant decisions about the following:
- The organization of a software system
- The selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaboration among these elements
- The composition of these elements into progressively larger subsystems
- The architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition
Software architecture is concerned with not only structure and behavior but also context: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics.
This definition is long, but it attempts to capture the richness, the complexity, and the multiple dimensions of the concept. We can elaborate on some of the points.
Architecture is part of design: it is about making decisions about how the system will be built. But it is not all of the design. It stops at the major elements—the elements that have a pervasive and long-lasting effect on the qualities of the system, namely, its evolvability and its performance.
Architecture is about structure and about organization, but it is not limited to structure. It also deals with behavior: what happens at the joints, at the seams, and across the interfaces.
Architecture not only looks inward but also looks at the “fit” of the system in two contexts: the operational context (its end users) and the development context (the organization that develops the system). And it encompasses not only a system’s technical aspects but also its economic and sociological aspects.
Architecture also addresses “soft” issues such as style and aesthetics. Can an architecture be pleasing? Yes, to the educated eye it can be. Issues of aesthetics have their place in making a design uniform, easy to understand, and easy to evolve, with minimal surprises for the designers.
Olá pessoal!
Neste post vou falar sobre mais um tópico bastante interessante do livro Software Architecture in Practice – Second Edition, já citado em um post anterior. Desta vez o tema é “o que faz uma boa arquitetura”. Segundo o livro, diferentes arquitetos em diferentes organizações projetam diferentes arquiteturas, de forma que seja complicado definir qual é a mais correta. A ideia geral do tópico é que a arquitetura mais apropriada é aquela que melhor atende aos propósitos definidos para o sistema, sendo que não há uma fórmula única. Diferentes tipos de arquiteturas atendem a diferentes tipos de demandas. Uma arquitetura distribuída, baseada em estrutura client-server pode ser adequada para uma companhia de grande porte do setor financeiro, porém, a mesma solução pode ser completamente inapropriada para uma aplicação voltada à aviação, ou a um compilador, ou ainda a um jogo de vídeo game. E como não há uma fórmula, o tópico estabelece algumas “regras de ouro”, que podem ser usadas em todos os tipos de demandas. As recomendações são classificadas em relacionadas ao processo e ao produto (ou estrutural). Vejamos a seguir:
 Recomendações relacionadas ao processo
- A arquitetura deve ser produto de apenas um arquiteto ou de um grupo pequeno, com um líder identificado. Acredito que esta dica esteja relacionada ao anti-pattern Design by Committee, em que a opinião de muitas pessoas é levada em consideração, atendendo seus egos ao invés das reais necessidades, resultando em uma arquitetura pouco eficiente.
- O arquiteto ou time de arquitetos deve ter uma lista de requisitos funcionais, bem como uma lista priorizada do que é definido como atributos de qualidade (devo falar mais sobre este assunto em um próximo post), que são, por exemplo, escalabilidade, performance, segurança, facilidade de manutenção, etc.
- Uma arquitetura deve ser bem documentada, de forma que ao menos uma visão estática e uma dinâmica sejam produzidas. Uma visão estática pode ser um diagrama de componentes ou de implantação da UML. Já a dinâmica pode ser obtida com os diagramas de sequência ou comunicação, por exemplo, também da UML.
- Uma vez documentada, a arquitetura deve ser bem conhecida por todos os stakeholders (clientes / áreas de negócios solicitantes, analistas, desenvolvedores, líderes de projetos, gerentes de projetos, etc.), que por sua vez devem se envolver ativamente na sua revisão.
- Uma arquitetura deve ser analisada através da medição de atributos quantitativos (por exemplo, throughput máximo) e avaliada formalmente quanto aos atributos de qualidade que deve atender, antes que seja tarde para que alterações sejam feitas.
- Uma arquitetura deve ter como resultado um sistema “esqueleto” (estrutura inicial em camadas, serviços, projetos, soluções, etc.) em que caminhos de comunicação sejam testados com funcionalidades mínimas. Uma vez estabelecida, esta estrutura pode ser usada para o crescimento incremental do sistema.
- Uma arquitetura também deve ter como resultado documentações de soluções para áreas de contenção específicas, como por exemplo, utilização de rede, processador, etc.
Recomendações relacionadas ao produto / estrutura
- Uma arquitetura deve ter como característica a definição de módulos cujas responsabilidades funcionais devem ser alocadas de acordo com os conceitos information hiding e separation of concerns.
- Cada módulo deve ter interfaces bem definidas, que encapsulem ou escondam aspectos sujeitos a mudanças. Estas interfaces devem permitir que times de desenvolvimento trabalhem de forma independente entre si (achei este item redundante com relação ao anterior, mas deixei para ficar aderente ao livro).
- Arquitetos devem se preocupar e devem buscar o atendimento de atributos de qualidade. É comum que arquitetos se preocupem apenas com os requisitos funcionais, deixando questões importantes aparecerem apenas quando o sistema entra em produção. Existem táticas específicas para atender requisitos de qualidade. Também falarei sobre este assunto em detalhes em próximos posts.
- Uma arquitetura nunca deve depender de versões específicas de produtos comerciais. Se a integração com produtos comerciais for necessária, deve-se projetar a arquitetura para que mudanças futuras para um produto diferente ou para uma nova versão sejam feitas de forma trivial e pouco custosa (camadas de indireção podem ser usadas neste sentido).
- Módulos que consomem dados devem ser separados de módulos que produzem dados, visando prover maior facilidade de manutenção, uma vez que as mudanças normalmente ocorrem ou no lado consumidor ou no lado fornecedor do dado.
- Para sistemas com processamento paralelo, a arquitetura deve prover processos ou tarefas bem definidas que não necessariamente espelham a decomposição estrutural dos módulos.
- Ainda com relação a processamento paralelo, cada processo ou tarefa deve ser escrito de forma que a atribuição para um processador específico seja facilmente alterada, preferencialmente em tempo de execução.
- A arquitetura deve dispor de um número pequeno de padrões de interação. Ou seja, em geral, o sistema deve fazer as mesmas coisas da mesma forma, provendo maior facilidade de entendimento e leitura do código, melhorando e facilitando modificações futuras.
A maioria destas recomendações são seguidas de forma intuitiva, ou mesmo são embasadas por diferentes estudos ou experiências que levam a estas conclusões. É interessante ter esta consolidação de boas práticas para utilizá-las como um guia a ser lembrado em cada novo projeto de arquitetura. Nos próximos posts devo falar mais sobre assuntos específicos tratados de forma incipiente neste. Até lá.
Olá pessoal!
O tema deste post é bastante recorrente no nosso dia-a-dia. Prazos curtos, recursos e custos limitados, expectativa por qualidade do resultado final e requisitos bastante ousados. A regra para esta situação é simples: you can’t have it all (você não pode ter tudo). Isso é o que diz Mark Richards no livro 97 Things Every Software Architect Should Know, já citado em outros artigos deste blog anteriormente. E para ilustrar este cenário, Mark  conta a história do navio Vasa, que também pode ser encontrada no livro Software Architecture in Practice – Second Edition, de Len Bass, Paul Clements e Rick Kazman, onde são mostradas opções que podem evitar o problema que veremos a seguir.
A história se passa em 1620, quando Suécia e Polônia estavam em guerra. Objetivando a vitória, o rei da Suécia encomendou um navio fora dos padrões da época, o Vasa. Capacidade para trezentos soldados e sessenta e quatro armas pesadas distribuídas em dois decks eram os requisitos do navio. Tal capacidade de transporte de pessoas e capacidade de fogo era algo completamente sem precedentes. Para atender tal demanda um projetista de navios renomado foi chamado: Henrik Hybertsson. Apesar da sua reputação impecável e vasta experiência no ramo, este era um projeto extremamente desafiador para Henrik, pois, ele nunca tinha projetado um navio deste porte antes. Sua especialidade era navios de guerra comuns, de apenas um deck de armamento. Para piorar o cenário, além dos requisitos de performance, segurança, confiabilidade e funcionalidade, Henrik tinha que lidar com restrições de custo e tempo. Oito anos após a encomenda o Vasa finalmente foi entregue de acordo com as especificações, estando pronto para sua primeira viagem. Após navegar por trinta metros o Vasa disparou seus canhões em saudação e afundou logo em seguida. Investigações concluíram que o navio havia sido bem construído, porém, não havia sido bem projetado.
A conclusão desta história no livro Software Architecture in Practice – Second Edition é que apesar de passados quase quatrocentos anos do corrido, o que é denominado “Architecture Business Cycle” é bem ilustrado: os objetivos da organização (do Rei no contexto da guerra) delineiam os requisitos (poder de fogo e transporte de soldados), que delineiam a arquitetura (dois decks de armamento, setenta metros de comprimento) que por sua vez delineia um sistema (o navio que naufragou). No livro são então apresentadas três opções que devem ser consideradas quando falamos de projetos de arquitetura de sistemas reais:
- A verificação de estudos de caso de arquiteturas bem sucedidas que atendam a requisitos semelhantes;
- A utilização de métodos para avaliar uma arquitetura antes que qualquer sistema tenha sido construído a partir dela, de forma a mitigar os riscos associados aos requisitos sem precedentes (veremos mais detalhes a seguir);
- A utilização de técnicas incrementais para o estabelecimento da arquitetura, de forma a descobrir problemas de design antes que seja muito tarde.
Para Mark, no livro 97 Things Every Software Architect Should Know, tentar cumprir todo e qualquer requisito pode levar a criação de uma arquitetura que essencialmente não faça nada de forma satisfatória. Foi o caso do Vasa, que acabou ficando desproporcional para atender as capacidades de armamento e transporte requeridas. Mark cita ainda exemplos de requisitos normalmente mutuamente exclusivos: performance versus alta interoperabilidade, reuso e diversas camadas de uma arquitetura SOA. Mark recomenda então a utilização de técnicas para o que é conhecido como “Tradeoff Analysis”.
Tradeoff é uma situação que envolve perda de qualidade ou aspecto em algo em prol do ganho de outra qualidade ou aspecto. Considere o seguinte exemplo, ao guardar dados em memória podemos ter ganhos de performance associados ao acesso rápido, porém, teremos maior consumo de memória pela aplicação e possibilidade de trabalhar com dados desatualizados, já que a fonte original não estaria sendo consultada diretamente. O objetivo de uma análise de tradeoffs é ajudar na escolha de uma arquitetura adequada para um sistema pela descoberta de tradeoffs e pontos sensíveis. Duas técnicas são citadas para este objetivo: ATAM (Architectural Tradeoff Analysis Method) e CBAM (Cost Benefit Analysis Method). Ambas estão descritas no livro Software Architecture in Practice – Second Edition e também no site do SEI (Software Engineering Institute).
Olá pessoal!
Neste post finalizo uma pequena série de três posts sobre os processos de desenvolvimento de software mais populares da atualidade: o RUP e o Scrum. Caso você não tenha lido os dois posts anteriores, recomendo que o faça: RUP / Scrum. Neste post registro minha opinião / sentimento pessoal quanto a tais processos e como enxergo as discussões que têm surgido atualmente no mercado e na comunidade de desenvolvimento de software. Ressalto então que o está descrito excepcionalmente neste post não foi embasado por nenhuma literatura ou trabalho científico, tratando-se, portanto, de uma análise empírica pessoal. Com este post gostaria de abrir uma discussão, convidando-o a opinar sobre o assunto, postando seu comentário.
 É fato que não é tarefa simples suportar um processo demorado por conta de levantamentos de negócios, seguido por um levantamento de requisitos e produção de documentações ostensivas. Com as cobranças constantes por entregas mais rápidas, os clientes vêm maior valor no produto entregue do que em um escopo bem fechado e documentado. Muitos profissionais de TI também não enxergam este valor ou deixam de enxergar com o passar do tempo, quando percebem que manter toda uma documentação produzida não é trivial ou mesmo quando são cobrados frequentemente por fins sem necessariamente justificar os meios. Além disso, existem também outros problemas que são enfrentados na maioria dos projetos, como por exemplo, a não aderência do produto entregue às reais necessidades do usuário, frequentes mudanças de escopo no decorrer do desenvolvimento, demora na entrega dos primeiros resultados e/ ou atraso na entrega do produto completo, o que taxa a área de TI como uma área muito demorada.
Eis que surge então a resposta para todos os problemas. Um processo que não define nenhuma documentação e/ou passo de modelagem e que vem a endossar esta prática que antes era apenas uma ideia ou fruto das pressões mencionadas. Um processo que privilegia os produtos entregues ante as documentações ostensivas, que proporciona entrega de resultados rápidos para o cliente, que não impõe a existência de muitos papéis específicos, sendo desta forma facilmente incorporado por qualquer time de desenvolvimento. Eis que surge o Scrum.
Diversas consultorias surgem então para explorar este que é vendido como a bala de prata, a bola da vez. Outras consultorias que vendiam outros tipos de treinamento passam a se adaptar à nova onda, para não perder market share. Completando o cenário, diversos Scrum Masters se formam e passam a influenciar comunidades, que passam a levar as ideias ágeis para suas empresas, como solução para seus problemas. Não que isso seja privilégio do Scrum. Acredito que o mesmo tenha acontecido com o RUP anteriormente e com diversas outras siglas e acrônimos que vão e vem no nosso mercado o tempo todo. Com toda essa catequização, o RUP passa a se consolidar então como um processo burocrático, antiquado, e que não atende às expectativas dos clientes.
O que não é lembrado por muitos, no entanto, é que o RUP também é um processo iterativo e incremental assim como o Scrum, de forma que com ele também é possível fazer entregas rápidas, coletando feedbacks logo no inicio do projeto, assim mitigando os riscos antecipadamente. Nada impede também que o RUP seja customizado para cada realidade. Existe, por exemplo, o RUP for small projects, que traz um apanhado mais enxuto com relação à sua versão original. Outra possibilidade ainda é criação do seu próprio processo, selecionando um conjunto de artefatos, papéis e conceitos do RUP que façam sentido para a sua organização.
Já outro ponto nas metodologias ágeis que muitas vezes é mal interpretado é quanto à ausência de especificações e/ou documentações. O manifesto ágil não diz que nenhuma documentação ou especificação deve ser feita. Ele diz apenas que o software funcionando é mais prioritário do que uma documentação abrangente. No livro “Utilizando UML e Padrões”, Craig Larman fala sobre uma abordagem de modelagem que ele chama de “modelagem ágil e desenho leve UML”. Nesta abordagem os diagramas UML são desenhados para proporcionar entendimento e comunicação ao invés de documentação. Além disso, os diagramas são feitos em quadros brancos ou folhas de aderência, de forma que eles sejam posteriormente digitalizados através de fotos e programas específicos.
Pessoalmente acredito que um levantamento inicial de requisitos e que diagramas de casos de uso ajudam bastante no entendimento e na concepção inicial de um projeto, bem como na visualização do seu tamanho e escopo. Além disso, diversos diagramas da UML também agregam com visões que são importantes para a maioria dos projetos, como por exemplo, as dependências entre componentes, a modularidade e separação de responsabilidades, demostradas pelo diagrama de componentes e a distribuição dos mesmos dentre os diversos nodes de uma arquitetura distribuída, demonstrada por um diagrama de implantação.
Qual é então o processo mais adequado para cada organização? Acredito que ambos os processos e suas variantes ou customizações podem atender às necessidades de diferentes tipos de organizações, dependendo da sua cultura, necessidade e porte. Empresas que optam pelo RUP, por sua customização ou por um processo baseado nele, normalmente possuem cultura séria / rígida, onde constantes auditorias exigem documentos e práticas registradas, possuindo também uma estrutura de profissionais robusta. Já as organizações que possuem cultura descontraída e que optam ou que só podem ter times pequenos que atendam responsabilidades específicas, normalmente melhor se adaptam ao Scrum e aos demais processos e conceitos ágeis.
E você, o que acha? A sua empresa adota um destes processos de forma satisfatória?
Olá pessoal!
Continuando a série rápida sobre engenharia de software, neste post falo um pouco sobre o Scrum. O objetivo desta série, como mencionado no post anterior, é traçar um paralelo entre os processos de desenvolvimento de sistemas mais populares: RUP e o Scrum. Caso você não tenha lido o post anterior, onde falei sobre o RUP, clique aqui.
Assim como o RUP, o Scrum também é um processo de desenvolvimento de sistemas iterativo e incremental, porém, é voltado ao que se chama de desenvolvimento ágil de software, que por sua vez é fundamentado pelo manifesto ágil. O manifesto ágil foi concebido por dezessete pessoas de extrema influência na área de engenharia de software, sendo que dentre eles destacam-se: Martin Fowler, Alistair Cockburne Kent Beck. Quatro valores fundamentais formam a base do manifesto ágil:
- Os indivíduos e suas interações acima de procedimentos e ferramentas;
- O funcionamento do software acima de documentação abrangente;
- A colaboração dos clientes acima da negociação de contratos;
- A capacidade de resposta à mudanças acima de um plano pré-estabelecido;
Percebe-se então uma grande diferença entre os valores que formam a base do RUP e os do Scrum, sendo que uma das principais é o fato de que as documentações permeiam o RUP de ponta a ponta enquanto que no Scrum, em sua essência, pouca ou nenhuma documentação é produzida. Além disso, outra grande diferença, como bem lembrado pelo colega Alessandro Brito em uma discussão, é que o Scrum não define o que fazer em cada situação, o que o classifica como um processo não prescribente.
Vamos então a alguns detalhes. No Scrum, todo o conjunto de requisitos do usuário é conhecido como Product Backlog. Nele há a introdução do conceito de Sprint, que se refere a uma iteração de implementação completa de um ou mais itens do Product Backlog, que são entregues e validados pelo cliente ao seu término. O conjunto de itens selecionados para implementação em uma sprint é denominado Sprint Backlog. As sprints normalmente têm duração de duas a quatro semanas, de forma que o cliente tenha contato com as primeiras funcionalidades do sistema logo no inicio do seu desenvolvimento – o que é bem característico de processos iterativos e incrementais, assim como o RUP. Veja na figura a seguir a ilustração do processo descrito.
No Scrum também é empregado o que se chama de Daily Mettings, onde todos os participantes do time de desenvolvimento do projeto participam de uma breve reunião, apontando os seus progressos e/ou seus impeditivos, de forma que os riscos possam ser mitigados logo no momento em que surgem. Além disso, são também realizadas reuniões de planejamento das próximas sprints e de retrospectivas das sprints finalizadas, onde são verificadas as lições aprendidas, de forma que eventuais problemas não se repitam ao longo do projeto.
Situados ambos os processos, surgem algumas questões, como por exemplo: qual processo é mais adequado para a minha empresa ou para o meu time de desenvolvimento e quais são as tendências atuais? Estas são questões que abordarei no próximo post, onde finalizarei esta pequena série. Até lá!
Olá pessoal!
Neste série rápida relacionada à engenharia de software vou descrever brevemente dois processos de desenvolvimento de software. Um é o RUP (que vem perdendo espaço para as novas tendências “ágeis”) e o outro é a bola da vez, o Scrum. Ao término, devo traçar uma conclusão com relação aos dois processos e às atuais tendências.
Neste post em específico começarei pelo RUP. O RUP é um processo de desenvolvimento de software concebido inicialmente por uma organização denominada Rational (que utilizou como base um processo anterior denominado UP – Unified Process) e adquirido posteriormente pela IBM, tendo seu nome alterado para IRUP (IBM Rational Unified Process).
O processo consiste em uma abordagem iterativa e incremental, onde são definidas entregas sucessivas ao longo da execução do projeto. Tal modelo se opõe a abordagem tradicional cascata (waterfall), onde a entrega ocorre apenas ao término do projeto. Seis melhores práticas formam a base deste processo:
- Desenvolvimento iterativo;
- Gerenciamento de requisitos;
- Uso de arquitetura baseada em componentes;
- Modelagem visual;
- Verificação da qualidade;
- Controle de mudanças;
Dentre diversas definições, o estabelecimento de papéis (funções) e artefatos (itens que são produzidos ao longo do projeto) fazem parte do RUP, definindo claramente, desta forma, as atribuições em um time e os itens que são entregues por ele. O RUP propõe uma abordagem com quatro fases e nove disciplinas, conforme pode ser observado na figura a seguir (conhecida popularmente como “Gráfico das Baleias”).
Como benefícios de uma abordagem iterativa e incremental espera-se:
- Redução de custos com retrabalho e aumento da aderência do produto entregue às necessidades do usuário: À medida que pequenas partes do produto são entregues, o cliente tem a oportunidade de avaliar e fornecer um feedback à equipe de desenvolvimento, de forma que o produto final seja mais aderente aos seus requisitos.
- Aceleração do tempo de desenvolvimento do projeto como um todo: devido ao fato de que a equipe trabalha de forma mais eficiente quando se busca resultados de escopo pequeno e claro.
O RUP é comumente utilizado em grandes organizações, pois, em sua forma original (sem customizações), implica na produção de diversas documentações – o que o faz levar a fama de “burocrático” – e na existência de conhecimentos específicos (atribuições de alguns papeis) que nem sempre são viáveis em organizações menores. Para suprir estas deficiências, ou excessos, existe uma versão simplificada do RUP denominada “RUP for Small Projects”. Existem ainda organizações que criam seu próprio processo de desenvolvimento utilizando-se de práticas, conceitos e até mesmo artefatos definidos pelo RUP. Estes processos, no entanto, são mais aderentes às suas necessidades e as suas realidades.
Ultimamente pouco se tem ouvido falar a respeito do RUP, pois, como mencionado anteriormente, a moda agora é “ser ágil”. Até o próximo post, onde falarei sobre o Scrum!
|
|
