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 [...]]]> 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 ObterDocumento, 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 terceiros¹ 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.

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 [...]]]> 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á.

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 [...]]]> 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.

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 é [...]]]> 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á.

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 [...]]]> 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).

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 [...]]]> 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?

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, [...]]]> 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á!

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 [...]]]> 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!

Neste post gostaria de deixar registrada uma recomendação para quem quer começar a estudar o ASP .NET MVC 3.0 e que de quebra também quer aprender algumas novidades do Visual Studio 2010. Trata-se de um tutorial criado por Scott Hanselman no site ASP .NET (www.asp.net): Getting Started with MVC3, que traz um passo-a-passo para a [...]]]> Olá pessoal!

Neste post gostaria de deixar registrada uma recomendação para quem quer começar a estudar o ASP .NET MVC 3.0 e que de quebra também quer aprender algumas novidades do Visual Studio 2010. Trata-se de um tutorial criado por Scott Hanselman no site ASP .NET (www.asp.net): Getting Started with MVC3, que traz um passo-a-passo para a criação do seu primeiro site MVC. O tutorial é bastante detalhado e contém diversos screenshots, tornando-se fácil de ser seguido por estudantes e profissionais de qualquer nível. Vejam só quantos assuntos bacanas são abordados:

• O próprio ASP .NET MVC 3.0: O tutorial traz uma aplicação de listagem de filmes, onde é possível verificar a lista de filmes disponíveis na base de dados, incluir um novo filme, alterar, excluir e visualizar detalhes de um filme existente. Durante a criação desta aplicação, diversos conceitos do ASP .NET MVC são explorados, como por exemplo, a criação de Views e Controllers. o funcionamento e a composição das URL’s em uma aplicação MVC, dentre outros. Após concluir o tutorial você terá uma aplicação ASP .NET MVC que realiza todas as operações básicas em um banco de dados, já servindo como um bom exemplo para as suas necessidades futuras.
• Razor: Veja na prática como funciona este novo view engine do ASP .NET MVC 3.0, onde é possível escrever os códigos das suas views na sua linguagem de preferência (C#/VB.NET), contando com o intellisense do Visual Studio 2010 e com a possibilidade de realizar testes unitários em views.
• NuGet: O NuGet é uma ferramenta de gerenciamento de pacotes que é adicionada ao Visual Studio 2010 com a instalação do ASP .NET MVC 3.0. Com ele é possível pesquisar e instalar bibliotecas de terceiros em suas aplicações .NET de forma bastante simplificada. Para mais informações sobre o Nuget, visite seu site no codeplex.
• Entity Framework, Code-First e POCO: O tutorial mostra como baixar o pacote EFCodeFirst através do Nuget, porém, atualmente já é possível baixar a última versão do Entity Framework que já contém o Code-First embutido. A ideia com o Code-First é que ao invés de criarmos modelos de dados e tabelas baseados neles, nós devemos primeiro modelar e criar as classes do nosso sistema, ou seja, partindo para o código primeiro, de forma que as estruturas em banco de dados sejam criadas por ele em tempo de execução. As classes criadas são realmente simples (também conhecidas como POCO, de Plain Old CLR Objects), de forma que sejam necessárias apenas propriedades correspondentes aos seus atributos para que todo o trabalho seja feito.
• Validação de dados com DataAnnotations: Veja como é simples implementar validação em seu sistema, bastando para isso a decoração das suas classes de modelo de dados com atributos de validação. Ou seja, o framework se encarrega de gerar os códigos necessários para validação no client, de forma que sua aplicação não gere requisições desnecessárias ao servidor e ainda responda rapidamente. Tudo isso com pouquíssimas linhas de código!

Não perca tempo para beneficiar-se destas tecnologias que tornam os nossos códigos mais bem escritos e que nos proporcionam cada vez mais produtividade! Até o próximo post.

Em fevereiro de 2011 foi publicado mais um artigo que escrevi para a revista .net Magazine, em sua edição de número oitenta e dois. Com o título “AppFabric Caching Services – Funcionalidades, instalação, configuração e utilização” o artigo complementa um outro artigo publicado anteriormente na edição sessenta e nove (veja o post aqui), onde falei [...]]]> Olá pessoal,

Em fevereiro de 2011 foi publicado mais um artigo que escrevi para a revista .net Magazine, em sua edição de número oitenta e dois. Com o título “AppFabric Caching Services – Funcionalidades, instalação, configuração e utilização” o artigo complementa um outro artigo publicado anteriormente na edição sessenta e nove (veja o post aqui), onde falei sobre Aspect Oriented Programming e Cache. Nesta edição o artigo estende o componente para cache abordado anteriormente, incluindo agora a utilização do AppFabric Caching Services, que é a tecnologia mais recente disponibilizada pela Microsoft para cache de dados.

Como o próprio título já anuncia, o artigo fala sobre as funcionalidades e características do AppFabric – incluindo também uma introdução sobre o Hosting Services – sua instalação e configuração em um ambiente local e a utilização do seu módulo de cache (Caching Services), através de um componente facilmente plugável, que utiliza as API’s providas junto com o pacote de instalação do AppFabric.

A sua versão digital pode ser vista através do link a seguir e a versão impressa encontra-se nas bancas de jornais no mês de fevereiro de 2011.

http://www.devmedia.com.br/post-19319-AppFabric-Caching-Services.html

Obs: O artigo passou por um processo de edição feito pela revista, onde diversas alterações foram realizadas com relação a versão original enviada. Infelizmente, nesta edição alguns erros foram introduzidos e algumas passagens não ficaram de uma forma didática, em minha opinião.