software modular
Para criar sistemas flexíveis, evolutivos e escaláveis, devemos ter modularidade, ou seja, a propriedade que nos permite criar um sistema bottom-up (de baixo para cima).
Primeiro você precisa ter os módulos, então você precisa de um "arquivo" de módulos. Eles devem então ser intercambiáveis, ou seja, deve ser possível substituir um módulo por outro equivalente, e isso é feito permitindo a troca de informações entre os módulos por meio de interfaces definidas: a interação dos componentes não deve variar com a variação dos módulos .
O software modular descobre um novo paradigma de integração entre componentes com o desenvolvimento de mashups (aplicação web híbrida), ou seja, criar algo a partir de diferentes fontes, por exemplo usando APIs inicialmente criadas para finalidades diferentes, mas depois combinadas para produzir um novo produto.
Quão simples devem ser os módulos em um sistema modular?
Os formulários devem ser o mais simples possível. Cada empresa pode lidar com as relações mais complicadas (por exemplo, gestão de pessoal) de uma forma muito diferente, mas as funcionalidades elementares permanecem as mesmas (por exemplo, folha de pagamento). Módulos pequenos permitem mais reutilização, menos tempo de desenvolvimento e evolução constante (por exemplo, se você separar a interface do usuário, você precisa garantir que ela seja consistente, por exemplo, você precisa ser capaz de copiar e colar independentemente do sistema para o qual IU é construída).
O problema que se coloca é, claramente, como conseguir a interação entre os módulos. Um sistema grande possibilitava ter muitas informações ligadas entre si dentro do próprio sistema, também permitia que as informações relativas fossem gerenciadas de forma única
para acessar permissões, enquanto com i dar eles estão dispersos e os mecanismos de autenticação podem ser diversos.
Essa decomposição nos dá, ao mesmo tempo, muita liberdade: i dar podemos colocá-los onde quisermos, distribuindo-os como quisermos.
A integração de todos os componentes, banco de dados, módulos e interfaces, não ocorre no vácuo, mas ocorre em uma plataforma: é ela que nos permite realizar a integração, portanto é necessário definir bem esta plataforma.
O que permite a criação de sistemas modulares é acima de tudo um padrão sobre o tipo de informação que é trocada pelos módulos: deve haver uma correspondência nos possíveis fluxos de comunicação entre os módulos. Podemos ter vários sistemas de escrita intercambiáveis se tivermos um único padrão de documento, mas até agora aconteceu exatamente o oposto: um sistema de escrita predominante com um grande número de formatos de documentos. Esta situação tem duas desvantagens:
- se o padrão estiver associado a um sistema, esse sistema tende a se tornar universal,
- isso tende a favorecer o fechamento do mercado, porque existe um padrão que ninguém mais consegue gerar, então o mais difundido automaticamente se torna o mais forte.
A agenda é um exemplo de aplicação transversal face a todas as outras aplicações, porque tem de haver uma agenda, pelo que faz sentido geri-la ao nível do sistema, e não ao nível da aplicação. O sistema é a plataforma na qual executamos aplicativos, através da qual os fazemos comunicar. Isso nos permite separar o dar de aplicativos. Isso simplifica muito a criação do sistema de informação: podemos mesclar o dar de duas empresas com mais facilidade ou usar aplicativos diferentes para acessar o mesmo dar.
A fusão de sistemas de informação é fundamental para o processo de fusão de empresas. Ter formulários simples facilita a troca de informações do que adotar formulários complexos.
A modularidade muitas vezes já está presente segundo um ponto de vista externo: o do usuário. Na verdade, ele vê o sistema uma peça de cada vez, ou seja, ele vê apenas a peça que usa e a percebe como um módulo separado do resto. A modularidade aparente é o primeiro passo rumo à modularidade real.
Isso nos permite criar interações e serviços novos e intercomponentes. A interface do sistema torna-se dependente do ambiente do usuário: o sistema responde quando o usuário precisa, então o tempo de espera torna-se essencial para medir a eficácia do sistema.
É importante que a interface seja pensada a partir do usuário, do que ele faz: o usuário se acostuma com os procedimentos, mesmo que sejam ferraginosos e carentes de lógica.
Finalmente, a plataforma deve ter consciência de ser uma plataforma: não só deve permitir a execução de módulos, mas também deve conter todas aquelas funções que podem ser transversais (eg agenda, e-mail) que podem ser acessadas com primitivas do sistema ( assim como com copiar e colar). Para o sistema, estes podem ser vistos como
- aplicações normais, mas são imprescindíveis para poder juntar os componentes.
- Plataforma = sistema + serviços transversais.
A plataforma não é o sistema e não o substitui, principalmente se você tiver sistemas diferentes (Windows, Linux, Mac…), em que o middleware assume, mostrando vários sistemas como se fossem um só.
Portanto, os sistemas modulares devem ter pelo menos 4 características:
- os módulos devem ser simples;
- os módulos devem ser intercambiáveis;
- você precisa de uma plataforma repleta de serviços necessários para a integração;
- a interface deve ser projetada para satisfazer o usuário do aplicativo.
Todas estas características estão ligadas à evolução: os módulos permitem evoluções separadas e permitem a evolução do sistema. A plataforma e a interface devem, por sua vez, ser capazes de evoluir de acordo com protocolos e procedimentos.
Compartilhar:
Saiba mais na Agência Web Online
Inscreva-se para receber os artigos mais recentes por e-mail.
