De Arte a Ciência: Regras para o Desenho de Software

Transcrição

1 De Arte a Ciência: Regras para o Desenho de Software Neste artigo é apresentado um conjunto de regras de desenho um padrão de desenho universal associado ao princípio fundamental e aos requisitos axiomáticos. O padrão de desenho universal apresenta quatro tipos de elementos de design que, em conjunto, podem descrever todo um sistema de software numa única visão. Cada tipo de elemento de desenho tem a ver com um e apenas com um dos seguintes quatro aspectos da operação do sistema: estruturas de dados e operações primitivas, interfaces externas (hardware), algoritmos de sistema, fluxo de dados e sequência de acções Porque precisamos de regras de desenho Um princípio fundamental é uma lei fundamental estabelecida ou uma verdade largamente aceite que rege um campo específico da ciência ou da engenharia. Para a área da construção, por exemplo, a lei da gravidade é um princípio fundamental. Na primeira parte deste artigo propusemos que o desenvolvimento de software também tem um princípio fundamental: o software corre em hardware e interage com hardware hardware esse que tem uma velocidade finita. Apesar dos princípios fundamentais serem a base de todo o raciocínio científico, fornecem pouca ajuda prática a um engenheiro que tem pela frente um trabalho de desenho. Normalmente, são demasiado abstractos ou demasiado pesados para serem implementados directamente. Mesmo assim, os princípios fundamentais incluem requisitos axiomáticos requisitos que se aplicam a todos os sistemas que foram e serão criados. Na área da construção, por exemplo, a ideia de que o edifício deve suportar a força da gravidade constitui um requisito axiomático. Obviamente, todos os edifícios têm que satisfazer este requisito. O desenvolvimento de software também tem requisitos axiomáticos, como vimos na primeira parte deste artigo. O software tem que obter dados de uma ou mais interfaces externas (hardware). O software tem que disponibilizar dados para uma ou mais interfaces externas (hardware). O software tem que manter dados internos para serem utilizados e actualizados a cada ciclo de execução. O software tem que transformar os dados de entrada em dados de saída (utilizando possivelmente os dados internos).

2 O software tem que efectuar transformações de dados tão rapidamente quanto possível. A partir dos seus requisitos axiomáticos, todas as disciplinas tradicionais da engenharia têm derivado um conjunto de regras de desenho. Na área da construção civil, por exemplo, uma regra de desenho é a que se segue: uma parede mestra (destinada a suportar peso) tem que estar sempre posicionada por cima de uma parede mestra. O propósito desta regra de desenho consiste em ajudar os engenheiros a criar arquitecturas que satisfaçam os requisitos axiomáticos. Se um desenho arquitectural obedecer a todas as regras de desenho, então os engenheiros saberão a priori que satisfaz os requisitos axiomáticos e, consequentemente, será consistente com os princípios fundamentais da disciplina. As regras de desenho permitem que os engenheiros demonstrem facilmente a qualidade de uma arquitectura antes de iniciarem os trabalhos de construção. É necessário, portanto, encontrar as regras de desenho do desenvolvimento de software que estão associadas aos cinco requisitos axiomáticos apresentados atrás. O padrão de desenho universal As regras de desenho assumem várias formas. Podem ser muito explícitas, como uma lista de declarações imperativas do tipo o especialista em desenvolvimento de software deve, mas também podem ser mais subtis, como um conjunto de elementos de desenho predefinidos incluídos numa linguagem de desenho. Se uma linguagem de desenho incluir classes, por exemplo, então uma regra de desenho implícita será utilize classes para o desenho de software. A maior parte dos métodos de desenho de software disponibilizam, tanto um conjunto de elementos de desenho predefinidos, como regras narrativas sobre a forma como utilizar esses elementos de desenho. Comecemos pelos elementos de desenho. Convém ter em conta que as linguagens de desenho existentes, como a Unified Modeling Language (UML) não disponibilizam muita ajuda. A UML, por exemplo, é um sistema de notação ad hoc, sem princípios fundamentais subjacentes e sem requisitos axiomáticos. Os elementos de desenho foram escolhidos devido ao seu grande poder expressivo e porque a experiência e erro provaram a sua utilidade. Não estes os elementos de desenho de que estamos à procura. Em vez disso, precisamos dos elementos de desenho mais restritivos possível elementos que forcem os especialistas em desenvolvimento de software a criar arquitecturas que satisfaçam os nossos requisitos axiomáticos i. Os seguintes quatro tipos de elementos de desenho inserem-se nesta descrição. Entidade de dados As entidades de dados representam os dados entrados e saídos do sistema de software, assim como os dados internos. Servidor I/O Os servidores de I/O encapsulam as interfaces externas (hardware) com as quais interage o software. Os servidores de I/O também podem ser servidores puros de entrada ou de saída. Servidor de transformação Os servidores de transformação efectuam a transformação de dados de entrada em dados de saída, ao mesmo tempo que actualizam possivelmente os dados internos. Gestor de fluxo de dados Os gestures de fluxos de dados obtêm dados de entrada dos servidores de I/O, invocam os servidores de transformação (que transformam os dados de entrada em dados de saída) e disponibilizam dados de saída aos servidores de I/O. Os gestores de fluxos de dados também detêm os dados internos.

3 Os requisitos axiomáticos 1 a 4 implicam claramente a presença de entidades de dados, servidores de I/O e servidores de transformação. Mas para que queremos os gestores de fluxos de dados? A resposta é que os gestores de fluxos de dados tornam o fluxo de execução explícito. Isto, por sua vez, permite que um especialista em desenvolvimento de software mostre que uma arquitectura satisfaz o requisito axiomático 5: o software efectua a transformação de dados tão rápido quanto possível. Sem gestores de fluxos de dados por exemplo, com os outros elementos de desenho a enviarem mensagens uns para os outros o fluxo de execução tornarse-ia rapidamente impossível de acompanhar e, consequentemente, o tempo de execução seria imprevisível. Figura 1. Um desenho de arquitectura simples. A Figura 1 é um exemplo de um desenho arquitectural muito simples, utilizando os elementos de desenho apresentados atrás. Um desenho mais complexo poderá ter múltiplos gestores de fluxos de dados, múltiplos servidores de I/O e múltiplos servidores de transformação. Cada gestor de fluxo de dados poderá obter entradas a partir de vários servidores de I/O em diferentes pontos e disponibilizar saídas para diferentes servidores de I/O. Além disso, poderão existir bases de dados internas ou serviços abstractos representados por servidores I/O. Cada tipo de elemento de desenho tem uma natureza distinta e uma responsabilidade distinta dentro de um sistema de software. As propriedades e as responsabilidades sobrepõem-se muito pouco e os elementos de desenho do padrão de desenho universal complementam-se bem uns aos outros. Apresentamos de seguida uma lista de regras narrativas que descrevem mais detalhadamente como é que os elementos de desenho do padrão universal de desenho devem ser utilizados e implementados. Entidade de dados Cada entidade de dados é um objecto passivo de uma classe sem estado. As entidades de dados podem ser construídas a partir de entidades de dados mais básicas, através de agregação e herança. As operações primitivas de uma entidade

4 de dados são implementadas como métodos da sua classe. As operações primitivas de uma entidade de dados nunca invocam operações de um servidor de transformação ou um servidor de I/O. Servidor I/O Externamente, os servidores de I/O são elementos de sistema passivos. Não despacham dados de entrada, nem actuam noutros elementos de sistema. Os servidores de I/O têm uma interface externa bastante uniforme, baseada apenas nas operações Get, Put e Wait (e combinações). Internamente, a maior parte dos servidores de I/O têm uma sequência independente de controlo e mantêm o estado global para responder a eventos de hardware e a pedidos de clientes (gestor de fluxo de dados). Os servidores de I/O têm a capacidade de manter em buffer dados de entrada e dados de saída. Quando um gestor de fluxos de dados invoca uma operação de servidor de I/O, o servidor de I/O recupera tipicamente os dados de entrada do um buffer e guarda os dados de saída num buffer. No entanto, os algoritmos através dos quais um servidor de I/O gere os seus buffers de dados têm que ser simples. Um servidor de I/O nunca invoca directamente operações de servidor de transformação. Servidor de transformação Os servidores de transformação são elementos de sistema passivos e sem estado. Cada servidor de transformação implementa uma operação de transformação de dados, que é regida por um algoritmo sequencial e determinista. O algoritmo pode ser arbitrariamente complexo, mas tem que depender apenas dos argumentos da operação de transformação de dados. Em conjunto, os servidores de transformação implementam todos os aspectos algorítmicos de um sistema de software. Quando um gestor de fluxos de dados invoca uma operação de transformação, todos os dados de entrada são explicitamente passados para dentro, todos os dados de saída são explicitamente passados para fora e qualquer dado interno é explicitamente passado para dentro e para fora. Um servidor de transformação pode actualizar os dados internos apenas através dos argumentos da sua operação de transformação, mas pode não manter nenhum estado global. Um servidor de transformação nunca obtém dados de entrada directamente de um servidor de I/O, nem disponibiliza dados de saída directamente para um servidor de I/O. Gestor de fluxo de dados Os gestores de fluxos de dados são os elementos activos de um sistema. Cada um representa um fluxo independente de controlo. Os gestores de fluxos de dados são o meio através do qual um especialista em desenvolvimento de software deve implementar concorrência dentro de um sistema (excepto para os drivers de hardware). Actuam nos servidores de I/O e nos servidores de transformação através da invocação das suas operações. Um gestor de fluxo de dados efectua todas as suas acções o mais rapidamente possível. Convém sublinhar que para um gestor de fluxos de dados, esperar por entrada constitui uma acção ii. Os gestores de fluxos de dados asseguram que os fluxos de dados e os fluxos de controlo andam sempre de mão dada. Os dados são enviados e, eventualmente, retornam sempre que um gestor de fluxo de dados invoca o funcionamento de um servidor de I/O ou de um servidor de transformação. Um gestor de fluxos de dados obtém sempre dados de entrada e disponibiliza dados de saída. Nunca são enviados dados para um gestor de fluxos de dados, nem recebidos dele. Como resultado, os gestores de fluxos de dados segmentam os elementos de processamento (servidores de I/O e servidores de transformação) de um sistema e fazem com que os fluxos de dados e os fluxos de controlo sejam previsíveis e acompanháveis. Dividir para conquistar O padrão de desenho universal tem uma característica chave que o distingue de qualquer outro método de desenho ou linguagem de modelação: divide estritamente as preocupações operacionais pelos seus quatro tipos de elementos de desenho.

5 Desta forma, elimina qualquer necessidade de visualizações diferentes de um desenho. Com o padrão de desenho universal, todos os aspectos de um sistema de software podem ser representados numa única visualização. No entanto, nessa visualização cada tipo de elemento de desenho está preocupado com um e só um aspecto do funcionamento do sistema. As entidades de dados estão preocupadas apenas com estruturas de dados e operações primitivas nessas estruturas de dados. Uma entidade de dados é um objecto inteiramente passivo dado puro iii insensível a algoritmos de sistema, interfaces externas, ou sequências de acções. Os servidores de I/O estão preocupados apenas com a encapsulação e o serviço de interfaces externas (hardware). Um servidor de I/O pode estar preocupado com o tempo de I/O, mas não com o agendamento ou com a activação de outras acções de sistema. Os servidores de I/O não efectuam qualquer tarefa algorítmica relativamente aos dados de entrada ou de saída com que lidam. Os servidores de transformação estão preocupados apenas com os algoritmos do sistema. Um servidor de transformação nunca tem que se preocupar com a origem ou com o destino dos dados. Todas as operações de um servidor de transformação são sequenciais e determinísticas. Os servidores de transformação não estão preocupados com a representação dos dados, interfaces externas, ou sequências de acções. Os gestores de fluxos de dados estão preocupados apenas com os fluxos de dados e com as sequências de acções. Sabem quais as acções que o sistema precisa de realizar e em que sequência, mas não estão preocupados com os detalhes dessas acções os algoritmos e as interfaces externas (hardware). Apesar dos gestores de fluxos de dados deterem os dados internos, não estão preocupados com a sua representação. Outras abordagens de desenho esquecem normalmente os elementos de desenho que estão preocupados com múltiplos aspectos do funcionamento do sistema e que, consequentemente, têm um elevado nível de complexidade interna. Por exemplo, um desenho baseado na identificação de objectos no espaço do problema esquece frequentemente alguns elementos de desenho que estão preocupados com todos os quatro aspectos do funcionamento do sistema: estruturas de dados, interfaces externas, algoritmos e acções do sistema. Tentar tudo em conjunto Poderemos perguntar-nos como é que o padrão de desenho universal se relaciona com linguagens de desenho estabelecidas como a UML, o paradigma orientado por objectos, ou as modernas linguagens de programação. Não estamos a propor que devemos voltar as costas à orientação por objectos e restaurar a modelação de fluxo de dados. Também não estamos a dizer que devemos abandonar a UML e as abordagens baseadas em componentes. O que queremos dizer é que precisamos de utilizar essas abordagens de forma mais judiciosa. Convém recordar que cada tipo de elemento de desenho do padrão de desenho universal está preocupado apenas com um aspecto específico do funcionamento do sistema. Como tal, é perfeitamente razoável utilizar diferentes linguagens de desenho ou ferramentas de modelação para descrever cada tipo de elemento de desenho. Uma determinada linguagem de desenho ou ferramenta de modelação pode ser adequada para expressar alguns aspectos do funcionamento do sistema, mas não todos. De forma similar, uma linguagem de programação diferente pode ser mais apropriada para a implementação de cada tipo de elemento de desenho. As entidades de dados podem ser modeladas muito bem com linguagens de desenho orientadas por objectos, como a UML. Todas estas linguagens de desenho são perfeitamente capazes de representar classes, operações primitivas e relações entre classes. As entidades de dados são melhor

6 implementadas numa linguagem de programação orientada por objectos. Os servidores de I/O são melhor modelados com código estrutura de linguagem de alto nível. Tirando a UML/RT, nenhuma linguagem de desenho ou ferramenta de modelação visual chegou tão perto da descrição adequada dos aspectos de baixo nível relacionados com o hardware, com os quais um servidor de I/O tem de lidar. A Ada seria a linguagem de programação a escolher, tanto para o desenho, como para a implementação. Para descrever a arquitectura de um servidor de transformação, os gráficos de fluxos podem ser perfeitamente adequados. Na realidade, uma operação de servidor de transformação não é nada mais do que um algoritmo. Qualquer meio para descrever um algoritmo é, portanto, adequado para descrever a arquitectura de um servidor de transformação. Os servidores de transformação são melhor implementados numa linguagem de programação estruturada. Os fluxos de dados e os aspectos de interacção de objectos dos gestores de fluxos de dados podem ser modelados com praticamente qualquer linguagem de desenho. A sequência de acções efectuadas por um gestor de fluxos de dados é melhor modelada com código estrutura de linguagem de alto nível. Qualquer linguagem de programação estruturada é adequada para a implementação de um gestor de fluxo de dados. Seria interessante ter uma linguagem de desenho ou uma ferramenta de modelação que pudesse descrever visualmente a arquitectura de todo um sistema incluindo todos os tipos de elementos de desenho de uma forma uniforme. Apesar de não existir actualmente uma linguagem de desenho ou ferramenta de modelação desse tipo, existe uma linguagem de implementação que se adequa surpreendentemente bem aos elementos do padrão de desenho universal. Trata-se da linguagem Ada95 iv. Por sua vez, a popular linguagem orientada por objectos C++ apresenta fracos desempenhos quando se trata de implementar gestores de fluxos de dados e servidores de I/O. O padrão de desenho universal inspirou-se claramente nos aspectos de sistema em tempo real. Contudo, as aplicações batch sequenciais também aparecem no padrão de desenho universal como um interessante caso especial. Uma aplicação batch sequencial pode ser modelada com um servidor de transformação e qualquer número de entidades de dados, mas sem servidores de I/O ou gestores de fluxos de dados. Quanto implementamos um programa simples, estamos a implementar realmente uma transformação de dados. O programa pega em alguns dados de entrada (ficheiros de entrada), produz alguns dados de saída (ficheiros de saída) e computa dados de saída a partir de dados de entrada de acordo com um algoritmo determinístico. É exactamente isto que faz um servidor de transformação. Evidentemente, os servidores de I/O e possivelmente os gestores de fluxos de dados também estão presentes quando executamos o programa simples. No entanto, não estão representados explicitamente no desenho estão escondidos dentro do sistema operativo. Isto pode explicar porque razão as abordagens de desenho que são adequadas para as aplicações sequenciais orientação por objectos e gráficos de fluxos, por exemplo apresentam fracos desempenhos para sistemas em tempo real. Na verdade, podem funcionar bem para sistemas em tempo real se forem aplicadas apenas para os tipos certos de elementos de desenho, nomeadamente servidores de transformação e entidades de dados. A orientação por objectos e os gráficos de fluxos são, no entanto, inadequados para o desenho de gestores de fluxos de dados e de servidores de I/O. Conclusão A identificação e compreensão do princípio fundamental do desenvolvimento de software permitiu-nos definir um conjunto de regras de desenho universais o

7 padrão de desenho universal onde se devem basear todas as arquitecturas de software. Ao utilizar o padrão de desenho universal, um especialista em desenvolvimento de software deverá ser capaz de demonstrar que uma arquitectura de software é boa, sem efectuar quaisquer testes. Isto faz com que o desenho e a implementação de software seja uma actividade de engenharia previsível e repetível. Em especial, aprendemos que: O ambiente de hardware de um sistema de software não é uma limitação, mas antes uma força orientadora fundamental da arquitectura e desenho de software. É impossível criar arquitecturas de qualidade sem ter em conta o ambiente de hardware nas fases iniciais de desenho. As interacções de hardware não são uma questão de deployment e não podem ser adiadas ou ignoradas durante o desenho arquitectural. A alto nível, qualquer sistema de software pode ser modelado com quatro tipos de elementos de desenho que representam diferentes aspectos do funcionamento do sistema: estruturas de dados e operações primitivas, interfaces externas (hardware), algoritmos de sistema, fluxos de dados e sequências de acções. Nenhuma das linguagens de desenho e das ferramentas de modelação actualmente em utilização é adequada para desenvolver e representar todo um sistema de software. Existe, no entanto, uma linguagem de programação suficientemente poderosa e versátil para implementar todos os elementos e aspectos de um sistema de software. Estamos a falar da linguagem Ada. O padrão de desenho universal é verdadeiramente universal. Aplica-se a software de todos os domínios e pode ser utilizado independentemente do método de desenho ou da linguagem de modelação utilizados pelos especialistas em desenvolvimento. O estudo do padrão de desenho universal fornece uma ideia aprofundada sobre a natureza do software e do desenho de software. Baseado no artigo From Craft to Science: Rules for Software Design Part II, de Koni Buhrer, engenheiro de software na Rational Software. Tel: (+351) / 2 Fax: (+351) tim@engenharia-software.com Internet: i A restrição da liberdade de um especialista em desenvolvimento de software seria uma ideia assustadora se o desenvolvimento de software se destinasse a permanecer uma arte ninguém quer limitar um artista. Mas se o desenvolvimento de software pretende ser uma disciplina da engenharia, então a restrição da liberdade de quem desenvolve já será uma necessidade. ii Isto pode parecer estranho, pelo que merece uma explicação. Em muitos sistemas de software que processam dados em tempo real, um servidor de entrada envia um sinal para um elemento de processamento de dados quando chegam os dados de entrada. Consequentemente, invoca o elemento de processamento de dados. O padrão de desenho universal não permite que os servidores sejam proactivos desta forma. Um gestor de fluxos de dados procede sempre através do pedido de dados de entrada ao servidor. Se o gestor de fluxos de dados quiser esperar pela chegada dos dados, então essa espera pelos dados torna-se a sua acção. Evidentemente, num nível muito baixo, um thread de servidor de I/O pode enviar um sinal para um thread de gestor de fluxos de dados para implementar a conclusão da acção

8 esperar por entrada. No entanto, não nos devemos preocupar com este tipo de detalhes de implementação no desenho arquitectural. iii A famosa excepção a esta regra sãos os ficheiros. Um objecto ficheiro tem uma interface de hardware embebida escondida. É aceitável utilizar tais entidades de dados em aplicações sequenciais. Mas em sistemas em tempo real, as entidades de dados com interfaces de hardware embebidas escondidas têm que ser estritamente evitadas. iv De facto, a linguagem Ada adequa-se tão bem que não posso acreditar que seja pura coincidência. Gostaria de perguntar aos criadores da Ada se tinham o padrão de desenho universal em mente quando criaram a linguagem Ada.