eng de software [em foco]

Serviços Web - O Paradigma RESTful

noreply@blogger.com (Otavio Ferreira) — Fri, 16 Jan 2009 20:18:00 +0000

Existem muitas definições para o termo Serviços Web. Para motivar nossa discussão, vamos nos basear inicialmente na definição publicada pelo W3C, como segue: “Um serviço web é um sistema de software projetado para suportar a interação entre máquinas de forma interoperável em uma rede de computadores. Este serviço possui uma interface descrita em um formato processável por máquina (especificamente o WSDL). Outros sistemas interagem com o serviço web de acordo com esta interface, utilizando mensagens SOAP, tipicamente enviadas via HTTP com uma serialização em XML”.

Tal definição é perfeitamente realizável e amplamente adotada. Grandes empresas como Microsoft e IBM participaram ativamente do desenvolvimento desta abordagem através do lançamento de produtos e publicação de artigos. O problema existente nesta definição é que ela trata de um grupo específico de tecnologias, mais precisamente o protocolo SOAP e as linguagens WSDL e XML.

Segundo Leonard Richardson e Sam Ruby em seu livro “RESTful Web Services”, existem na verdade três grupos de serviços web, distintos em termos de arquitetura e tecnologias adotadas. São eles: Serviços RESTful, Serviços RPC, e Serviços REST-RPC. Cada grupo deve responder duas questões relativas à sua arquitetura:

Qual a ação a ser executada?
Qual o escopo de execução desta ação?

Serviços RESTful são os mais fiéis ao HTTP, pois utilizam todo o potencial oferecido por este protocolo. A ação a ser executada é definida pelo método HTTP (também conhecido como verbo HTTP). O protocolo oferece cinco métodos principais: GET, HEAD, POST, PUT, e DELETE. Todos os métodos são aplicados em recursos, ou seja, nos objetos gerenciados pelo serviço. Por este motivo, uma arquitetura RESTful é dita orientada a recurso.

O método GET trata da recuperação real de recursos, ao passo que HEAD retorna apenas os cabeçalhos (ou meta-dados) que descrevem os recursos afetados pela requisição HTTP.

Já os métodos POST e PUT tratam da inserção e atualização de recursos. A especificação HTTP é um tanto abrangente na comparação entre estes dois métodos. Alguns serviços web utilizam PUT para inserção, enquanto outros utilizam POST. A discussão é polêmica realmente. Após rever a especificação oficial, entendo que POST deve ser utilizado para a inserção de recursos aninhados. De acordo com esta interpretação, o método PUT seria usado tanto para a inserção, quanto para a atualização de recursos completos/independentes. Independentemente da sua interpretação, seja coerente na utilização destes métodos quando for criar seus próprios serviços, e documente suas decisões. Caso você esteja apenas consumindo serviços já disponíveis na Internet, tenha o cuidado de verificar qual a interpretação do provedor deste serviço.

Por fim, o método DELETE deve ser enviado para a remoção do recurso. Alguns serviços preferem executar uma técnica conhecida como soft-delete, onde o recurso não é efetivamente removido da base, mas apenas inativado. Outros preferem executar o hard-delete, o que faz com que o recurso nunca mais possa ser acessado, pois já não existe na base. Novamente, a especificação do serviço deve cobrir esta decisão.

Agora, sobre a definição do escopo de execução do método, o paradigma RESTful defende a utilização da URI presente na requisição HTTP para este fim. Nesta abordagem, a URI contém não apenas o caminho do serviço em questão, mas também qualquer parâmetro necessário para identificação única do recurso a ser afetado.

Observe o primeiro exemplo a seguir, onde uma aplicação cliente envia uma mensagem HTTP utilizando o método GET, e uma URI que identifica a foto de número 123. Neste cenário fictício, gallery.com seria uma aplicação de gerenciamento de fotos, que oferece uma API pública de acordo com os princípios RESTful. Neste momento, a aplicação quer recuperar/obter a foto armazenada em gallery.com.

GET /photo/123 HTTP /1.1
Host: gallery.com

No segundo exemplo, a requisição HTTP enviada utiliza o método DELETE, o que significa que a foto 123 será removida da base em gallery.com.

DELETE /photo/123 HTTP /1.1
Host: gallery.com

Note que apenas o método HTTP foi alterado, enquanto que a URI permaneceu intacta. Esta é uma característica marcante dos serviços RESTful. Aquela URI sempre identifica o mesmo recurso, ou seja, a foto 123. Este é o escopo de execução. Já o método HTTP apenas diz qual a ação a ser executada (recuperação no primeiro exemplo, e deleção no segundo).

Portanto, podemos perceber que é tranquilamente possível a criação de serviços web sem a utilização do SOAP, protocolo utilizado na definição publicada pelo W3C. Na realidade, diversas empresas emergentes já oferecem interfaces RESTful para que outras empresas/aplicações possam se conectar a elas.

Como visto neste post, o paradigma RESTful utiliza apenas o HTTP, protocolo padrão da Web, e sem o qual a Web não existiria como a conhecemos hoje. Na prática, os desenvolvedores rapidamente percebem que o protocolo REST é mais leve e portável que o SOAP.

Nos próximos posts, pretendo tratar das outras duas arquiteturas para serviços web: Serviços RPC (SOAP como principal exemplo) e Serviços REST-RPC. Até lá!

Engenharia de Software com Processos Ágeis – Desenvolvimento de Aplicações para a Internet

noreply@blogger.com (Otavio Ferreira) — Fri, 12 Dec 2008 21:44:00 +0000

Olá pessoal, já faz algum tempo que não escrevo por aqui, e desta vez eu gostaria apenas de divulgar um novo projeto.

Venho trabalhando com um grupo de professores da PUC - São Paulo, e recentemente criamos um curso de especialização que será oferecido pela própria Universidade. Trata-se de um curso inovador na área de Ciência da Computação, que agrega conceitos de Engenharia de Software, Orientação a Objetos, Internet, e Processos Ágeis.

O curso acaba de ser lançado sob o nome "Engenharia de Software com Processos Ágeis – Desenvolvimento de Aplicações para a Internet". Oito módulos serão oferecidos, sendo que cada um será completamente independente dos demais, não havendo pré-requisito entre eles. Isto fará com que o aluno possa trilhar um caminho de acordo com suas necessidades. Adicionalmente, não será necessário que o aluno se inscreva em todos os módulos, somente nos que julgar adequado ao seu perfil. Este formato é realmente novo e flexível.

Segue a lista de módulos:

Processos Ágeis
Engenharia de Requisitos
Desenho Lógico com Objetos
Implementação de Aplicações para a Internet
Programação com Objetos para Internet
Análise com Objetos
Desenho Físico com Objetos
Teste de Aplicações para Internet

Uma descrição mais detalhada pode ser encontrada no site da Coordenadoria Geral de Especialização, Aperfeiçoamento e Extensão da PUC-SP.

Atalho: http://tinyurl.com/eng-sw-puc/

Qualquer dúvida, por favor entre em contato, ou escreva um comentário neste post. Forte abraço!

Crítica Rápida ao Active Record

noreply@blogger.com (Otavio Ferreira) — Fri, 16 May 2008 21:21:00 +0000

Resumidamente, Active Record é um padrão encontrado em alguns projetos de software que armazenam dados em bases relacionais. Neste padrão, uma tabela é "encapsulada" por uma classe, portanto cada instância desta classe estará diretamente acoplada à uma linha da tabela.

Crítica: Caso a classe em questão seja um conceito do domínio, obviamente suas instâncias serão objetos de negócio. Ao aplicarmos o padrão Active Record, criamos uma dependência a partir negócio para a tecnologia!

No post Inversão de Dependências, apresento pelo menos quatro consequências geradas por esta dependência. Discussão polêmica... ;-) Comentários?

Abraços!

Inversão de Dependências

noreply@blogger.com (Otavio Ferreira) — Fri, 02 May 2008 14:40:00 +0000

A forte dependência entre classes (ou componentes) é o principal vilão de uma boa arquitetura de software! Evidentemente, não existe uma arquitetura completamente desacoplada, pois desta forma os objetos não poderíam trocar mensagens uns com os outros. A idéia é minimizar a existência destas dependências, e inserir no modelo apenas dependências bem planejadas. Particularmente, costumo chamar estas dependências bem planejadas de dependências saudáveis, afinal de contas, trazem muitos benefícios para o sistema como um todo.

No post Princípios Fundamentais do Processo Unificado, apresento o conceito Processo Centrado em Arquitetura. Resumidamente, o processo de desenvolvimento é guiado pela evolução da arquitetura, e o arquiteto preocupa-se em estabelecer um alto grau de modularidade para facilitar a expansão e a manutenção do sistema. Com módulos bem planejados, e dependências saudáveis entre eles, minimizamos três propriedades internas indesejáveis: Rigidez, Fragilidade, e Imobilidade. Vale a pena dar um pulo naquele post para entender cada uma destas três propriedades.

OK, vamos ao que realmente interessa: Como modelar apenas dependências saudáveis? Resposta bate-pronto: Utilizando interfaces para a inversão de dependências! Interface é uma definição parcial de algum conceito do domínio tratado por sua arquitetura. Certamente é a maior aliada do arquiteto de software! Vamos apelar para a UML para entender como inverter dependências.

O esquema acima poderia ser parte integrante da arquitetura de um comércio eletrônico, onde pedidos são armezenados na base de dados. É natural pensar que um objeto da classe Pedido envie mensagens para um objeto da classe MSSQL. Entretando, a dependência existente a partir de Pedido para MSSQL é indesejável. Algumas consequências podem ser observadas:

O negócio passa a depender da tecnologia. Como sabemos, a tecnologia está em constante evolução, e cada mudança tecnológica potencialmente provoca uma mudança nas classes de negócio, como a classe Pedido neste exemplo. Regras de negócio tendem a ser mais estáveis ao longo do tempo.

A arquitetura assume que, invariavelmente, o armazenamento dos dados será realizado por um banco de dados. É importante lembrarmos que o armezenamento baseado no sistema de arquivos vem ganhando algum destaque, e mostra bom desempenho.

Caso a classe de acesso aos dados tenha sido desenvolvida para trabalhar com um banco de dados específico (MSSQL neste exemplo), então a classe de negócio deverá ser constantemente modificada para cobrir eventuais novos provedores de dados (MySQL por exemplo).

Cria um acoplamento que dificulta testes unitários.

Como alternativa, poderíamos fazer com que a classe Pedido dependesse de uma interface que teria por objetivo prímário desacoplar o negócio das questões de armezenamento e recuperação dos dados.

Repare que, neste momento, a dependência é invertida, e todos os pontos negativos citados são removidos da arquitetura! Porém, o objeto de negócio ainda precisa enviar a mensagem para o objeto que manipula a base de dados. Como realizar isso nesta nova arquitetura? Simples! Interfaces não existem em tempo de execução, apenas objetos. Desta forma, o lugar da interface é ocupado pelo objeto de alguma classe que realiza esta interface. Podemos ter uma classe para MSSQL, outra para MySQL, uma terceira para FileSystem, e assim por diante.

Visualizar a inversão de dependência é ainda mais fácil quando tratamos com componentes, e não classes, como segue.

No próximo diagrama a dependência é invertida com o advento da interface.

A notação caixa-preta torna tudo ainda mais evidente, como segue:

E, novamente, a inversão da dependência:

É isso aí pessoal, espero ter colaborado com mais essa! Até a próxima, abraços!

Pacote de posts sobre o Processo Unificado

noreply@blogger.com (Otavio Ferreira) — Tue, 05 Jun 2007 18:46:00 +0000

Meu esforço inicial neste canal de comunicação foi apresentar o Processo Unificado, um framework de apoio ao desenvolvimento de software. Foram apresentadas as cinco disciplinas e as quatro fases do processo.

Na realidade seria possível escrever posts mais detalhados e amplos, mas acredito que não seria o mais adequado para um canal deste tipo. A idéia principal é incentivar a leitura e o debate dos tópicos que formam este processo.

Pacote de posts:

Processos Iterativos de desenvolvimento de software
Princípios Fundamentais do Processo Unificado
A estrutura do Processo Unificado
A disciplina de Requisitos
A disciplina de Análise
A disciplina de Projeto
A disciplina de Implementação
A disciplina de Teste
A fase de Concepção
A fase de Elaboração
A fase de Construção
A fase de Transição

A partir de agora, discutiremos outros temas, como modelagem orientada a objetos! Espero que tenha contribuido, um abraço!

A fase de Transição

noreply@blogger.com (Otavio Ferreira) — Tue, 05 Jun 2007 18:43:00 +0000

Consiste basicamente em entregar uma versão operacional do sistema ao cliente.

Deve-se preparar uma divulgação e uma documentação de usabilidade para o usuário final; ajustar o software no ambiente e, por fim, ministrar treinamentos que sejam necessários.

Como as disciplinas atravessam a fase

As cinco disciplinas podem ocorrer nesta fase, mas o Processo Unificado não se refere especificamente a este tópico. No momento em que o sistema atingir este ponto, ele funcionará comprovadamente.

Avaliação

A avaliação desta fase consiste basicamente em observar se os clientes não tiveram dificuldades na instalação e na usabilidade básica do sistema.

Nesta altura, o Plano de Projeto e os seis principais modelos devem estar finalizados. A documentação completa do processo de desenvolvimento deve ser armazenada e utilizada como base caso um novo ciclo seja necessário.

A fase de Construção

noreply@blogger.com (Otavio Ferreira) — Fri, 01 Jun 2007 20:24:00 +0000

Neste momento do ciclo de vida pode-se dizer que apenas questões técnicas são tratadas. A modelagem, a codificação e os testes dos componentes marcam esta fase.

É a fase onde o Modelo de Implementação e o Modelo de Teste tendem a ser bastante trabalhados, consequentemente, é o momento onde os desenvolvedores e os testadores mais atuam.

É comum que o Modelo de Casos de Uso, o Modelo de Análise, o Modelo de Projeto e o Modelo de Instalação estejam concluídos, apesar de ainda serem refinados nesta fase com eventuais detalhes.

Terá sucesso e poderá ser considerada concluída quando se atinge uma maturidade considerável nos artefatos das disciplinas de Implementação e Teste.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Construção em termos de tarefas:

Requisitos: Esta disciplina freqüentemente não é trabalhada nesta fase, os requisitos devem estar claros para todos na equipe.

Análise: Esta disciplina também é pouco trabalhada nesta fase, a arquitetura candidata já cedeu espaço para uma mais sólida.

Projeto: Refinar os artefatos relativos à arquitetura e à instalação do sistema.

Implementação: Modelar e codificar os componentes.

Teste: Verificar os componentes através dos diversos tipos de teste.

Avaliação

Existe apenas uma questão ao final desta fase: O sistema está pronto para ser entregue aos clientes? Caso a resposta seja negativa, será necessário adicionar uma iteração para os ajustes finais.

A fase de Elaboração

noreply@blogger.com (Otavio Ferreira) — Thu, 31 May 2007 20:46:00 +0000

O núcleo desta fase é a busca por uma boa arquitetura. No post "Princípios Fundamentais do Processo Unificado" fica clara a preocupação deste processo em prover meios para alcançar altos graus de manutenibilidade, flexibilidade, expansibilidade e reuso.

Esta fase também é marcada pelo gradativo afastamento dos clientes e, conseqüentemente, pela gradativa aproximação de questões mais técnicas.

Lembrando que são as disciplinas que possuem artefatos associados e não as fases, é perfeitamente comum que alguns documentos produzidos com bastante intensidade na fase de Concepção sejam refinados nesta fase, como é o caso do documento de Requisitos Não-Funcionais, pertencente à disciplina de Requisitos.

Porém, de forma mais intensa que a disciplina de Requisitos, as disciplinas de Análise e Projeto são as mais evidentes. Ao longo da fase, espera-se que uma arquitetura candidata seja substituída gradativamente por uma arquitetura mais concreta, ou seja, uma fundação sólida para o sistema.

Como as disciplinas atravessam a fase

Os parágrafos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Concepção em termos de tarefas.

Requisitos: Refinar os artefatos referentes aos requisitos funcionais e não-funcionais.

Análise: Refinar os artefatos relativos à arquitetura candidata.

Projeto: É a principal disciplina desta fase. As tarefas-chave são criar uma arquitetura sólida, tendo como base os diagramas produzidos na disciplina de Análise, e estruturar o cenário da instalação do sistema em componentes de hardware.

Implementação: Iniciar, ainda que superficialmente, a modelagem de componentização de acordo como o que foi produzido na disciplina de Projeto.

Teste: Necessária somente se algum componente tiver sido implementado, o que é pouco provável.

Avaliação

Existem algumas questões que auxiliam na avaliação da fase quando se imagina que está concluída:

Todos entendem e concordam com os requisitos detalhados?

Existe uma base arquitetônica sólida que possa evoluir à medida que os requisitos são explorados e mais funcionalidades são adicionadas no sistema?

As estimativas de tempo e custo foram cumpridas?

Se as respostas satisfizerem à maioria dos interessados, a fase pode ser considerada concluída com êxito. Caso contrário, talvez o melhor seja acrescentar mais uma iteração a esta fase para aparar arestas e finalizar o que estiver pendente.

A fase de Concepção

noreply@blogger.com (Otavio Ferreira) — Wed, 30 May 2007 02:33:00 +0000

Esta fase é caracterizada pela presença do cliente em entrevistas para que a equipe de desenvolvimento compreenda o domínio. Com base nesta compreensão, são identificados e selecionados os requisitos funcionais, em forma de casos de uso, e os requisitos não-funcionais.

A Concepção deve ser uma fase esclarecedora. Neste momento é fundamental o foco nas metas e nas necessidades dos usuários.

Terá sucesso e poderá ser considerada concluída quando se atinge uma maturidade considerável nos artefatos da disciplina de Requisitos. Desta forma, espera-se que esteja claro qual o sistema a ser construído.

Como as disciplinas atravessam a fase

Os pontos a seguir apresentam uma breve descrição de como cada uma das disciplinas atravessa a fase de Concepção em termos de tarefas.

Requisitos: É a principal disciplina desta fase. As tarefas-chave são chegar a um acordo entre os interessados sobre o contexto do sistema, conforme expresso no Modelo de Domínio, e identificar os requisitos funcionais e não-funcionais.

Análise: Elaborar, mesmo que de forma breve, uma arquitetura candidata.

Projeto: Iniciar um esforço mental de unificação dos diagramas relativos à arquitetura candidata.

Implementação: Frequentemente, nenhuma tarefa relativa a esta disciplina é realizada, a não ser que seja necessário criar um protótipo para satisfazer eventuais preocupações dos clientes.

Teste: Esta disciplina só será relevante para verificar um possível protótipo que tenha sido criado na disciplina de Implementação.

Avaliação

Existem algumas questões que auxiliam na avaliação da fase quando se imagina que está concluída:

Está claro o que está dentro e o que está fora do sistema?

Os requisitos foram compreendidos e todos concordam com eles?

Existe um esforço inicial de elaboração de uma arquitetura candidata?

As estimativas de tempo e custo foram cumpridas?

A disciplina de Teste

noreply@blogger.com (Otavio Ferreira) — Wed, 04 Apr 2007 01:02:00 +0000

O objetivo fundamental é verificar a qualidade do sistema. Esta disciplina ganha intensidade ao longo da fase de Construção e tende a perder esta intensidade apenas no início da fase de Transição. Ou seja, implementação e teste não devem ser atividades serializadas. Equipes de desenvolvimento e teste podem trabalhar de forma paralela. Em geral é isso o que acontece entre as demais disciplinas também, mas está explicitamente descrito neste post para que alguns paradigmas tradicionais, como este que envolve implementação e teste, sejam esquecidos.

Apenas um artefato é produzido nesta disciplina:

Modelo de Teste

O Engenheiro de Teste é um profissional especializado em metodologias para este fim. No exterior, esta é uma posição de muito prestígio em uma equipe de desenvolvimento, com plano de carreira bem definido e alta remuneração. É o profissional que efetivamente autoriza a publicação de um determinado sistema.

Infelizmente, esta realidade não é percebida em nosso país...

A disciplina de Implementação

noreply@blogger.com (Otavio Ferreira) — Tue, 03 Apr 2007 01:33:00 +0000

O objetivo fundamental nesta disciplina é construir uma versão operacional do sistema a ser entregue aos clientes. Caso o projeto encontre-se no primeiro ciclo, é comum que esta versão do sistema seja beta, ou seja, será disponibilizada para avaliação.

Quando esta disciplina aumenta sua intensidade, o projeto provavelmente está na fase de Construção e as discussões passam a ser puramente técnicas. Neste estágio a arquitetura é desenhada em termos de componentes.

A criação do código-fonte também é uma atividade desta disciplina.

Dois artefatos são produzidos durante esta disciplina. São eles:

Modelo de Implementação

Figura 1: Principal elemento dos diagramas de componentes da UML: componente.

Este modelo pode ser considerado correto quando contem todos os componentes necessários para realizar as funcionalidades especificadas pelos casos de uso e os requisitos não-funcionais.

Códio-fonte

É a realização tecnológica dos modelos na linguagem de programação escolhida.

É importante que um padrão de codificação seja seguido e o código comentado para facilitar a leitura em futuras manutenções. Os modelos e o código devem sempre estar sincronizados, refletindo as mais recentes atualizações.

A disciplina de Projeto

noreply@blogger.com (Otavio Ferreira) — Thu, 28 Sep 2006 21:10:00 +0000

Esta disciplina é a principal responsável pela elaboração da arquitetura. Ela utiliza-se dos artefatos produzidos na fase de Análise como base para a elaboração de uma arquitetura baseada em classes de projeto, ou classes concretas. Em geral procura-se unificar os diagramas e não mais manter um para cada caso de uso. Neste estágio é preciso ter uma idéia mais ampla da arquitetura como um todo, inclusive no que diz respeito a questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

A disciplina de Projeto é fundamental em uma metodologia centrada em arquitetura. Realizar bem as tarefas neste momento pode garantir um bom tempo de resposta nas atualizações do software futuramente.

Questões como distribuição de objetos e utilização de frameworks também são consideradas.

Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionados e se complementam.

Dois artefatos são produzidos durante esta disciplina. São eles:

Modelo de Projeto:

Modelo de Instalação:

A disciplina de Análise

noreply@blogger.com (Otavio Ferreira) — Mon, 11 Sep 2006 23:16:00 +0000

É comum dizer que esta disciplina do Processo Unificado tem como foco principal realizar o primeiro “corte” na arquitetura. Em geral, cada caso de uso selecionado é analisado em termos de classes de análise. Ou seja, temos uma primeira representação estática dos casos de uso, uma arquitetura candidata.

Por ainda não serem classes de projeto (ou concretas), esta estrutura estática sofrerá alterações em iterações futuras. Mas, de certa forma, o processo de desenvolvimento começa a se distanciar dos clientes e a ganhar um foco mais técnico. Este fato está ilustrado na figura 1 do post “A estrutura do Processo Unificado”. Nela podemos perceber que enquanto a curva da Análise vai se intensificando, a curva dos Requisitos perde intensidade. Neste momento, provavelmente o processo encontra-se no inicio da fase de Elaboração.

Um artefato principal é produzido durante esta disciplina:

Modelo de Análise

Figura 1: Objetos de Jacobson.

A disciplina de Requisitos

noreply@blogger.com (Otavio Ferreira) — Mon, 28 Aug 2006 16:00:00 +0000

O foco desta disciplina do Processo Unificado é trabalhar para construir o sistema certo. No inicio do primeiro ciclo de um projeto, ainda não se sabe exatamente qual o sistema a ser construído. O domínio é obscuro e a descrição dos requisitos pelos clientes pode vir acompanhada de ambigüidades, contradições e redundâncias.

A Engenharia de Requisitos, um dos braços da Engenharia de Software, é uma ciência destinada exclusivamente à compreensão das metas e das necessidades dos clientes em um projeto de desenvolvimento de software. As práticas, técnicas e ferramentas providas por esta ciência são grandes aliadas para um bom trabalho nesta disciplina.

Grupos como “The Requirements Engineering Specialist Group”, conferências internacionais e periódicos acadêmicos nos dão idéia da amplitude da Engenharia de Requisitos. Neste artigo vamos nos reter a discutir as atividades básicas executadas na disciplina. Em artigos futuros poderemos nos aprofundar neste tema tão complexo.

Um ponto interessante é perceber que ciências sociais, ciência cognitiva e relacionamento interpessoal são características importantes em um Engenheiro de Requisitos. Neste momento do processo, existe uma forte interação deste profissional com o cliente e é preciso preparo para identificar as ambigüidades, as contradições e as redundâncias que eventualmente aparecem.

Quatro artefatos são produzidos durante esta disciplina. São eles:

Modelo de Domínio:

Modelo de Casos de Uso:

Requisitos Não-Funcionais:

Functionality: Requisitos funcionais.

Usability: Requisitos de usabilidade, como recursos de ajuda e acessibilidade.

Reliability: Requisitos de confiabilidade, como capacidade de recuperação após falha.

Performance: Requisitos de desempenho, como tempo de resposta e disponibilidade.

Supportability: Requisitos de suporte, como facilidade de manutenção/configuração e internacionalização.

Referências:

A estrutura do Processo Unificado

noreply@blogger.com (Otavio Ferreira) — Tue, 15 Aug 2006 22:06:00 +0000

Em artigos anteriores, apresentei o conceito que define o paradigma do Processo Iterativo e os princípios fundamentais que definem uma de suas realizações mais evidentes, o Processo Unificado.

Mas como o UP (do original, em inglês, Unified Process) é estruturado?

Figura 1: Intensidade de cada uma das disciplinas no decorrer das fases em um ciclo.

Pois bem, a vida de um sistema de software é composta por uma série de ciclos. Ao final de cada ciclo, uma versão operacional do sistema é entregue aos interessados. Conforme ilustrado pela figura 1, um ciclo ainda é dividido em quatro fases: Concepção, Elaboração, Construção e Transição.

Resumidamente:

A Concepção é a fase onde os objetivos do ciclo de vida são identificados. Esta fase diz o que deve ser feito. O domínio é analisado e os requisitos (funcionais e não-funcionais) são compreendidos e selecionados.

A Elaboração é responsável pela arquitetura do sistema que será distribuído ao final do clico de vida. Esta fase diz como deve ser feito. É importante reforçar que a arquitetura deve suportar todos os requisitos selecionados. Lembre-se que um dos princípios fundamentais do UP é o fato deste ser Centrado em Arquitetura, ou seja, a Elaboração tende a ser uma fase crucial, recheada de desafios e questões complexas.

Na Construção, como o próprio nome sugere, o sistema é implementado de acordo com o que foi elaborado na fase anterior. Questões puramente técnicas como o encapsulamento de classes lógicas em componentes físicos marcam a fase. O sistema deve possuir a capacidade operacional adequada.

Por fim, a Transição é marcada pela liberação do produto aos interessados. O projeto deve ser preparado para possíveis ciclos futuros.

Cada fase é composta por uma seqüência de iterações. Tipicamente, a Concepção é composta de uma única iteração e a Transição de no máximo duas. Porém, as fases de Elaboração e de Construção contam com um número maior de iterações.

Uma característica marcante, também ilustrada na figura 1, é o fato de todas as iterações, e conseqüentemente todas as fases, serem atravessadas por todas as disciplinas, com maior ou menor intensidade.

São exatamente as disciplinas que possuem artefatos associados. Artefatos são documentos textuais ou diagramas da UML que facilitam a compreensão do sistema e a comunicação entre os envolvidos. Ou seja, é possível que um artefato de compreensão do domínio seja incrementado em mais de uma fase, mesmo sabendo que o entendimento do domínio é um dos principais objetivos da fase de Concepção.

A maioria dos artefatos produzidos ao longo dos ciclos pertence a um dos seis modelos apresentados na figura 2. Os modelos, contendo todos os seus artefatos, formam a documentação completa do processo de desenvolvimento. Esta documentação deve ser disponibilizada aos envolvidos a cada novo ciclo.

Um modelo por si só também pode ser considerado um artefato, porém, que possui outros artefatos internos, como diagramas completos e textos estruturados. Podemos qualificar um modelo como um agrupamento lógico semanticamente fechado.

Figura 2: Os seis modelos básicos do Processo Unificado.

Mesmo tendo mencionado que uma documentação que compreenda estes seis modelos é tida como completa, podemos adicionar outros documentos que sejam considerados relevantes.

Exemplos de documentos complementares:

Modelo de Domínio

Documento de requisitos não-funcionais

Referências

Princípios Fundamentais do Processo Unificado

noreply@blogger.com (Otavio Ferreira) — Thu, 10 Aug 2006 20:07:00 +0000

O Processo Unificado, uma realização do Processo Iterativo de Desenvolvimento de Software, possui três princípios fundamentais.

A estabilização e a consagração deste processo no mercado devem-se, principalmente, a estes princípios. São eles:

Dirigido por Casos de Uso

Para compreender o conceito "Caso de Uso", é importante conhecer o conceito "Ator". Um ator pode ser entendido com uma pessoa ou uma entidade não-humana que interage com o sistema, mas está fora dele. O exemplo mais comum de ator é o próprio usuário, porém, bancos de dados e outros sistemas também podem ser considerados atores.

Pois bem, um caso de uso é uma seqüência de ações executadas por atores e pelo sistema, a fim de satisfazer metas e necessidades destes atores.

Os casos de uso compõem a força condutora de todo o processo de desenvolvimento, desde a captação inicial de requisitos até a aceitação do código-fonte, por várias razões:

Primeiramente por serem expressos sob a perspectiva do usuário, em textos descritivos na língua local do cliente. Os textos devem ser intuitivos e óbvios para o leitor.

Outro ponto fundamental é que permitem uma compreensão direta dos requisitos do sistema. Os casos de uso não devem apresentar ambigüidades, redundâncias ou contradições. Devem especificar um contrato a ser aceito e seguido pelos integrantes da equipe de desenvolvimento e pelos clientes.

Permitem também um alto grau de rastreamento de requisitos nos diversos modelos que são desenvolvidos posteriormente. Manter os casos de uso à mão durante todo o processo por ser decisivo para o aceite da solução.

Por fim, os casos de uso facilitam a distribuição de tarefas e a alocação de trabalho.

Centrado em Arquitetura

A arquitetura é a organização fundamental do sistema como um todo. Possui elementos estáticos e dinâmicos que explicitam exatamente como cada componente é construído e como este se relaciona com os demais.

Uma boa arquitetura deve prover um alto grau de manutenibilidade. Este fato é fundamental para que a equipe de desenvolvimento possa atender as demandas que surgem em um intervalo de tempo cada vez menor, principalmente após a adoção da Internet como canal de comunicação primário.

Inúmeras corporações modelam seus negócios de acordo com a tecnologia disponível, inviabilizando a inovação, mutação e, em alguns casos, até o crescimento do negócio. Segundo constatado por Paul Strassmann em 1997, na realidade uma situação inversa deveria ser empregada, onde as seguintes características sustentariam a ideal postura de um departamento de Tecnologia da Informação em uma organização: deveria agregar real valor ao plano de negócios, não deveria resistir às mudanças e deveria combater qualquer tipo de resistência a elas, pois são necessárias.

Partindo deste ponto de vista, é essencial que o software se adapte ao modelo de negócios estipulado em uma corporação. Porém, como modelos de negócios são mutáveis, a arquitetura do software em questão deve ser flexível o suficiente para acompanhar tais mudanças e expansível o suficiente para permitir o crescimento.

Um alto grau de modularidade pode ser um grande aliado no alcance de altos graus de manutenibilidade, flexibilidade e expansibilidade.

Um módulo pode ser entendido como uma porção de código encapsulada, coesa e fracamente acoplada. Já o grau de modularidade estima a coerência de utilização de módulos na arquitetura de um sistema, obedecendo cinco critérios e seis princípios, descritos por Bertrand Meyer em 1988, exibidos nas listagens abaixo:

Critérios:

Decomposição: Capacidade de dividir o problema inicial em subproblemas, ou módulos, isolados.

Composição: Capacidade de reutilização dos módulos na construção de novos sistemas, possivelmente em ambientes ligeiramente diferentes.

Entendimento: Capacidade de compreensão dos módulos de forma individual por um leitor humano.

Continuidade: Capacidade de alteração dos módulos sem impacto nos demais, mantendo a arquitetura e as relações.

Proteção: Capacidade de suporte a condições anormais dos módulos, limitando o escopo de um erro ao próprio módulo e protegendo o restante do sistema.

Princípios:

Unidade modular sintática: Um módulo deve corresponder a uma unidade sintática da linguagem.

Poucas interfaces: Um módulo deve se comunicar com a menor quantidade de módulos possível, evitando recursão.

Interfaces pequenas: Um módulo deve trocar a menor quantidade de informações possível com outro.

Interfaces explícitas: A comunicação entre dois módulos deve ser explícita e clara.

Informações ocultas: Os dados de um módulo devem ser privados, com raras exceções de dados públicos.

Aberto e fechado: Aberto para pequenas alterações (sem impacto nas interfaces) e fechado, sugerindo sua completude e disponibilidade de uso.

Ainda tendo em vista o grau de modularidade, uma arquitetura deve ser elaborada considerando diversos níveis de abstração. Quanto menor a abstração de um componente, maior será seu potencial de reuso. Esta característica fundamental pode ser alcançada através da utilização de frameworks, um conjunto de classes abstratas e concretas com alto grau de especialização.

Reunindo todo este conhecimento, somos capazes de minimizar a existência de três propriedades internas indesejáveis na arquitetura:

Rigidez: A manutenção em um determinado ponto do sistema obriga ao desenvolvedor ajustar outras localidades diretamente relacionadas, gerando uma cadeia de manutenção. Suas conseqüências são conhecidas como “efeito dominó”.

Fragilidade: A manutenção em um determinado ponto do sistema gera problemas em outro ponto não relacionado, muitas vezes distante do local da alteração. Suas conseqüências são conhecidas como “efeito borboleta-maremoto”, nomenclatura extraída da Teoria do Caos. Esta teoria defende que o simples bater de asas de uma borboleta em um extremo do mundo, pode ser o estopim de um tornado no outro extremo.

Imobilidade: Ao tentar reutilizar um componente já desenvolvido, classes não pertencentes a este impossibilitam a ação, dado o forte acoplamento existente. Suas conseqüências são conhecidas como “efeito banana-gorila”.

Iterativo e Incremental

Cada projeto é dividido em iterações. Cada iteração pode ser considerada um miniprojeto de curta duração que tem por objetivo oferecer uma melhora incremental ao sistema.

São benefícios desta forma de organização:

É um progresso lógico para que uma arquitetura robusta seja alcançada. Durante as iterações iniciais, uma arquitetura candidata é proposta. Sua evolução será uma fundação sólida para o restante do sistema.

Em contraste com metodologias que seguem o paradigma do Processo Cascata, onde todos os requisitos são levantados no inicio e nunca mais revisados, o Processo Unificado prevê a negociação progressiva de requisitos, priorizando aqueles que representam riscos mais significativos ao projeto.

Possibilita maior flexibilidade para que mudanças ocorram no plano de atuação da equipe de desenvolvimento. Uma avaliação ao final de uma iteração permite isolar um eventual problema identificado e lidar com ele em uma escalada reduzida, sem propagar seus efeitos.

Caso o incremento de uma iteração seja um componente ou módulo, este é integrado aos demais existentes. Uma integração muitas vezes representa a conquista de mais um requisito. A evolução do trabalho torna-se mais evidente aos interessados.

Por fim, a natureza iterativa permite que novos integrantes da equipe de desenvolvimento iniciem suas atividades sem que sejam submetidos a treinamentos extensos que cubram todo o projeto.

Processos Iterativos de desenvolvimento de software

noreply@blogger.com (Otavio Ferreira) — Mon, 31 Jul 2006 21:43:00 +0000

Contextualização

A Crise do Software é realidade desde meados da década de 70. Clientes insatisfeitos, atrasos nos prazos, custo infinito e produto final com baixa qualidade são apenas algumas características que marcam esta crise.

Apesar da evolução tecnológica e das iniciativas de intelectuais como Barry Boehm na década de 80 e Gustav Karner na década de 90, que propuseram métodos de estimativas, atualmente permanecem raros os exemplos de projetos de software desenvolvidos fora dos padrões da crise descrita.

No combate ao cenário caótico, tornam-se necessárias a criação e a adoção de metodologias que auxiliem os projetos de desenvolvimento. Desta forma, é possível gerenciar a crise. Algumas tentativas foram propostas.

Na década de 80 surgiu um tipo de processo conhecido como Processo Cascata (do original, em inglês, Waterfall Process). É constituído basicamente por cinco fases seqüenciais: descoberta de requisitos, desenho, implementação, teste e implantação. Com sua utilização, percebeu-se que o processo não atendia completamente as necessidades dos profissionais. A constante mudança de requisitos, a divisão inflexível das atividades e a rigidez imposta colaboraram para o fracasso do processo.

Já no início da década de 90, um tipo de processo conhecido como Processo Espiral surgiu como uma boa solução aos problemas identificados no Processo Cascata, pois protótipos são construídos a cada ciclo e refinados nas fases seguintes. Este processo permite que as fases sejam definidas de acordo com objetivos do projeto. Porém, a má adequação ao paradigma de orientação a objetos determinou o fracasso deste processo. O modo procedimental de criação de software já não era suficiente na resolução de problemas complexos ou, pelo menos, extensos.

A solução definitiva, consolidada no final dos anos 90, foi a criação de um tipo de processo conhecido como Processo Iterativo. Neste, a cada iteração os modelos são refinados e, ao final de cada ciclo, um protótipo é entregue aos stakeholders, os interessados no projeto.

O paradigma do Processo Iterativo e suas realizações

O Processo Iterativo define um paradigma, ou seja, uma forma de pensar. Este não pode ser considerado um processo completo de desenvolvimento de software, pois não discrimina as atividades necessárias para que este objetivo seja alcançado.

Uma realização desta forma de pensar é o Processo Unificado (UP), que se encaixa na definição geral de um processo completo: um conjunto de atividades executadas para transformar um conjunto de requisitos em um sistema de software. Entretanto o Processo Unificado também é uma estrutura genérica de processo que pode ser customizada adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos recursos disponíveis para um projeto. Também pode sofrer alterações de acordo com a filosofia da empresa que o emprega. O Processo Unificado da Rational (RUP), por exemplo, é uma versão especializada do Processo Unificado que adiciona elementos a sua estrutura genérica. Surgiu dos esforços de Ivar Jacobson, Grady Booch e James Rumbaugh em 1998 na Rational, recentemente adquirida pela IBM.

O Microsoft Solutions Framework (MSF), que também se encaixa na definição geral de um processo completo, já é uma outra realização do paradigma do Processo Iterativo. Surgiu da vasta experiência em desenvolvimento de software adquirida pela Microsoft ao longo de sua existência. Uma vantagem evidente na utilização desta metodologia é alcançada para as equipes que utilizam ou utilizarão o Visual Studio 2005 Team System, pois esta ferramenta possui dois methodology templates que podem ser adequados de acordo com as necessidades ou utilizados como fundação na criação de uma versão especializada do processo.

Conclusão

Apesar de existirem esforços e iniciativas na unificação dos processos completos de desenvolvimento de software, o que realmente aconteceu foi o estabelecimento de um paradigma como sendo o mais correto no gerenciamento da crise do software.

Note que eu utilizei a palavra “gerenciamento” e não “solução”. Este tipo de crise não pode ser extinta, ela existe toda a vez que uma equipe não se baseia em uma metodologia comprovadamente eficaz (cenário ainda muito comum no mercado brasileiro). O termo “gerenciamento” refere-se à possibilidade de medir, de forma controlada e adaptativa, o tempo e o custo de um projeto.

Realmente a unificação apenas do paradigma me parece mais correta do que a unificação dos processos completos, dado que cada empresa possui sua filosofia e o processo ocorre internamente. O mesmo não acontece com as linguagens de modelagem, que foram unificadas na UML para que as empresas possam compartilhar modelos e componentes.

Já que a adoção de uma metodologia é necessária, selecione aquela que se encaixe melhor no projeto e nos recursos disponíveis. Considere também a ferramenta de desenvolvimento utilizada como fator de decisão. Por fim, tenha em mente que a criação de uma metodologia também é bem-vinda, contanto que siga o paradigma iterativo.

Novo canal de discussão para Engenharia de Software!

noreply@blogger.com (Otavio Ferreira) — Sat, 29 Jul 2006 17:19:00 +0000

A primeira postagem, como não poderia deixar de ser para um Engenheiro de Software, é um típico "Hello, World!".

A idéia deste canal é promover a democratização, a discussão e a difusão dos conceitos que formam a Engenharia de Software.

Fiquem à vontade...

Um abraço a todos, Otávio Ferreira.