As Metodologias de Desenvolvimento de Sistemas devem usar gráficos para representar os elementos dos sistemas. Os gráficos devem revelar dados [Tufte 1992]. De facto, quanto mais complexos forem os dados, mais fácil se torna comunicar e apresentar dados através da visualização gráfica. O poder da imagem é mesmo esse.
Em primeira instância, a Modelação é uma forma de estudar ou equacionar um problema representando-o em modelos. Modelos são abstracções que nos permitem lidar com a complexidade de um determinado problema ou conjunto de problemas. São representações simplificadas da realidade [Booch 1999]. Fornecem a ideia ou estrutura geral da realidade em análise, filtrando detalhes não essenciais e permitindo interpretar mais facilmente o problema em causa [Quatrani 2000].
Com certeza que, para os vários elementos que integram uma equipa de projecto, será mais fácil analisar um problema e perspectivar as respectivas soluções através de um modelo que lhes permita visualizar a ideia global do sistema e as relações entre as partes que o compõem, sem haver necessidade de aprofundar detalhes específicos de cada uma dessas partes, do que através de um vasto conjunto de linhas de código.
Os modelos assumem-se, então, como elementos essenciais à compreensão de problemas, para além de facilitarem e promoverem a comunicação com qualquer elemento da equipa de projecto (analistas, projectistas, programadores, designers e, claro, utilizadores do sistema). Consequentemente, os modelos contribuem para a minimização dos riscos associados ao processo de desenvolvimento.
Os modelos podem ser vistos como [Huckvale 1993]:
Capít ulo I V
95 • Um meio para discussão, uma vez que permitem a partilha de conhecimento entre diferentes
grupos de intervenientes. Uma boa técnica de Modelação, com sintaxe e semântica legíveis, ajuda-nos a colocar as questões certas sobre o mundo real e a identificar rapidamente os aspectos relevantes a discutir por técnicos ou não técnicos.
• Um meio para comunicar um processo a outros, uma vez que facilitam a comunicação entre todos os intervenientes incluídos ou não na equipa de desenvolvimento.
• Uma base para a análise. A análise de um modelo pode revelar pontos fracos nos processos, por exemplo, acções que adicionam pouco valor ou são potenciais focos de problemas. O modelo pode ainda ser usado para explorar os efeitos da mudança, recorrendo a ferramentas adequadas de animação e simulação.
• Uma base para projectar novos processos.
• Uma linha de referência para a melhoria contínua dos processos. Sugestões para a mudança podem ser expressas como alterações ao modelo e da sua análise podem ser sugeridas métricas para avaliar o seu desempenho.
• Uma forma de minimizar os riscos associados a custos e prazos do projecto, uma vez que as previsões se baseiam em critérios mais realistas.
• Uma base para controlar os processos. Um modelo suficientemente formal pode ser automatizado. Ora, a execução do sistema modelado pode ser controlada pelo próprio modelo, tal como um Workflow Management System.
A adopção de modelos no desenvolvimento de sistemas de software permite atingir quatro objectivos principais [Booch 1999]:
• Visualizar o sistema no tempo (presente, passado e futuro);
• Especificar a estrutura, a arquitectura e o comportamento do sistema; • Conduzir e controlar o processo de construção do sistema;
• Documentar as decisões tomadas.
Em última instância, os modelos são a forma de organizar, visualizar e interpretar sistemas complexos, com vista a documentá-los desde a Análise ao Projecto.
Um modelo é representado por esquemas usando linguagem textual ou gráfica. Se a representação do esquema for gráfica, designa-se usualmente por diagrama. Como exemplos, temos as Árvores de Decisão, que usam uma linguagem textual, enquanto que os Diagramas de Casos de Utilização e os Diagramas Entidades-Relacionamentos usam uma linguagem gráfica.
96
A Modelação permite uma melhor análise do problema e identificação dos requisitos, um Projecto do Sistema mais limpos e a elaboração de um sistema de fácil manutenção.
Para tal, a Modelação deve basear-se em três componentes que se integram com vista à construção de um modelo de sucesso: Notação, Técnica e Ferramenta (ver figura 33).
A Notação assume-se como a linguagem universal que todos os elementos de uma equipa de projecto devem entender. Por um lado, esta componente permite comunicar ideias e decisões que de outra forma não seriam óbvias para todos os elementos da equipa de projecto. Por outro, oferece semânticas capazes de transmitir as mais importantes decisões estratégicas e tácticas. Note-se que a notação deve ser suficientemente poderosa para favorecer a interiorização do modelo por parte dos intervenientes no Planeamento, Desenvolvimento e Exploração do Sistema.
Mas, não adianta aprender a Notação se não a soubermos aplicar (Técnica). Por sua vez, não adianta ter apreendido a Técnica e a Notação se não for possível documentar coerentemente o trabalho inerente à Modelação e actualizá-lo sempre que necessário através de uma Ferramenta adequada. Afinal, para que uma equipa multidisciplinar consiga desenvolver um projecto colaborativamente, deverá falar a mesma linguagem, isto é, cada elemento deverá interpretar o modelo ou as partes que lhe dizem respeito tal como qualquer outro elemento. Como já foi referido, um modelo deverá ser o elo de ligação entre analistas, programadores, operadores de dados e utilizadores finais.
FERRA MEN TA N O TAÇ ÃO TÉCNICA MODELO
Figura 33 – Componentes de um Modelo: Técnica, Notação e Ferramenta
Qualquer Ferramenta deve oferecer uma Notação bastante forte, introduzindo determinados elementos da notação à medida que se evolui da Análise para o Projecto do Sistema.
Mas, o que faz com que um modelo seja bom?
Para que um modelo seja bem sucedido é conveniente que a Técnica de Modelação utilizada apresente as seguintes características [Huckvale 1993]:
97 • os modelos devem ser de preferência gráficos (diagramas) em vez de textuais, desde que
sejam construídos por forma a facilitar a compreensão e manipulação dos mesmos;
• os objectos e relações representadas no modelo devem ser intuitivamente familiares, por forma a que as pessoas possam entendê-lo e utilizá-lo sem grandes exigências de formação nas Técnicas de Modelação;
• a Notação da Modelação deve ter sintaxe e semântica formais para facilitar a sua análise e a construção de ferramentas de suporte;
• o modelo deve permitir lidar com a complexidade.
Com vista a lidar com a complexidade da realidade em estudo, um bom modelo deverá permitir: a divisão do sistema em partes (para facilitar a compreensão do sistema, o modelo deverá permitir a representação de cada um dos vários subsistemas que o compõem); diferentes níveis de detalhe (os modelos devem permitir uma visão do geral para o específico, ou seja, a partir da visão global do sistema que oferece menor detalhe, o modelo deverá permitir aumentar gradualmente o nível de detalhe); diferentes formas de representar ou projectar (o modelo deverá oferecer diferentes maneiras de visualizar a mesma coisa, ou seja, permitir visualizar dados, funcionalidades, processos, interfaces, etc.).
Os modelos, consoante a quem se destinam, são um meio de mostrar o essencial dos problemas complexos. Estes admitem, como abstracções do mundo real, objectos e relações de interesse. As abstracções mais relevantes foram classificadas em quatro perspectivas [Curtis 1992]:
• Funcional: representa quais as actividades realizadas e quais os fluxos de dados que as interligam;
• Organizacional: representa onde e por quem as actividades são realizadas e quais os mecanismos de comunicação e de armazenamento;
• Comportamental: representa quando é que as actividades são realizadas, a sua sequência, os resultados da sua realização, as interacções, as tomadas de decisão e as condições para o seu desencadeamento;
• Informacional: representa as entidades de dados envolvidas no processo, incluindo a sua estrutura e inter-relacionamentos.
As tradicionais Técnicas de Modelação de Processamento de Dados - DP Modelling
Techniques, com a inerente ênfase nos dados, não são as melhores na captura de elementos de
interesse na Modelação de Processos. Algumas das técnicas mais usadas para a Modelação são os DFDs (Diagrama de Fluxo de Dados) e DERs (Diagrama ou Modelos de Entidades-
98
Relações); no entanto, estas técnicas apenas oferecem as perspectivas funcional e informacional. Contudo, é possível usar diversas Técnicas de Modelação para cobrir todas as perspectivas, mas será necessário integrá-las de forma coerente.
É através do processo que é gerado valor para o cliente ou utilizador final. Por conseguinte, são os processos, dos quais o cliente se apercebe e recebe o resultado (produto ou serviço), que devem ser objecto de intervenção [Sousa 1997].
Actualmente, as diversas metodologias ou métodos podem ser classificados em: metodologias convencionais, ou Abordagens Estruturadas, e metodologias contemporâneas, ou Abordagens Orientadas por Objectos. Para a modelação e em conformidade com a evolução dos métodos de desenvolvimento de sistemas, têm surgido técnicas e ferramentas características de cada metodologia [Rezende 1999], [Silva 2001]:
• Análise Tradicional: Fluxogramas;
• Análise Estruturada: Diagramas de Fluxo de Dados; • Análise Orientada por Objectos: Diagramas de Objectos.
As primeiras aplicações informáticas foram fruto de actividades não planeadas e baseadas na programação, uma vez que o seu desenvolvimento não era orientado por metodologias. Por um lado, tínhamos o programador que construía as aplicações e, por outro, o operador que as usava.
A ênfase era atribuída às preocupações tecnológicas em detrimento dos requisitos dos utilizadores, uma vez que a construção de aplicações tinha como finalidade principal automatizar processos manuais (que teoricamente estariam correctos). Mas, à medida que a complexidade aumentava, a situação tornava-se mais problemática, exigindo actividades de Análise e Projecto do Sistema antes da sua Construção propriamente dita. O enfoque das primeiras abordagens de desenvolvimento baseava-se na utilização da técnica dos fluxogramas. Posteriormente, surgiram as técnicas de PERT e CPM para apoiar o planeamento da actividade de programação. Mas, os projectos continuavam a falhar devido à fraca importância atribuída a questões como a gestão e satisfação das necessidades e requisitos dos utilizadores, a motivação e envolvimento dos elementos da equipa e dos utilizadores e o comprometimento da gestão de topo.
Nas décadas de 70 e 80 surgiram diversas metodologias que derivaram da aplicação do princípio da decomposição funcional entre outros princípios semelhantes aos utilizados pelas Linguagens de Programação Estruturadas. O conjunto destas metodologias ficou conhecido por Metodologias Estruturadas.
99 O aparecimento das Linguagens Orientadas por Objectos e as limitações das Metodologias Estruturadas, nomeadamente no que diz respeito à manutenção, qualidade e complexidade dos sistemas, impulsionaram o aparecimento de novas formas de analisar a realidade. Surgiram, assim, as Metodologias Orientadas por Objectos.
É fundamental que dispunhamos de Técnicas de Modelação que permitam a concepção e representação através de modelos de processos, modelos necessários para descrever, comunicar, analisar e identificar todos os aspectos dos processos educativos. Não obstante, um modelo representa apenas uma visão ou um cenário da realidade ou sistema. Qualquer actividade de Modelação deverá permitir a produção de vários modelos, cada um mostrando uma visão diferente, mas complementar, do sistema por forma a facilitar a compreensão do sistema em geral e das suas partes em particular.
As Técnicas de Análise Orientada por Objectos vieram contribuir significativamente para a resolução deste problema.
No entanto, independentemente dos processos de desenvolvimento virem a ser guiados por Metodologias Estruturadas ou por Metodologias Orientadas por Objectos, podem ser enunciados quatro princípios básicos para a escolha dos modelos [Booch 1999]:
• A escolha dos modelos deve depender do modo como se pretende encarar o problema e, consequentemente, da forma como a solução pretende ser obtida.
• O modelo deve poder lidar com a complexidade e, por conseguinte, poder ser expresso em diferentes níveis de precisão ou abstracção.
• O modelo deve reflectir a realidade, quer se trate de um modelo que pretenda descrever “o que o sistema faz”, quer se trate de um modelo que visa detalhar “como é que o sistema faz”. • Não deve existir um modelo único, uma vez que um conjunto de modelos diferentes, mas
complementares, representa melhor a complexidade de um sistema.
A escolha dos modelos depende da visão daquele que deles necessita. Um administrador de base de dados, cujo comportamento tende a dar mais importância ao armazenamento de dados e aos comportamentos que o despoletam, atribuirá mais ênfase aos modelos ou Diagramas Entidade-Relacionamento. Um analista da Análise Estruturada, cuja atitude focará o fluxo de dados de um processo para outro, provavelmente usará modelos tais como Diagramas de Fluxo de Dados ou outros mais centrados em algoritmos. Mas, se o sistema for encarado numa perspectiva baseada em objectos, provavelmente será obtida uma visão do sistema cuja arquitectura estará centrada em diversas classes e padrões de interacção que determinarão como essas classes funcionarão em conjunto. Muito embora a perspectiva
100
orientada a objectos se assuma como a melhor solução de Modelação, uma vez que permite a criação de estruturas mais flexíveis, a verdade é que qualquer uma das visões expostas poderá estar correcta e conduzir com sucesso o desenvolvimento de um sistema.
As metodologias ou abordagens mais tradicionais (incluindo a abordagem estruturada) do Desenvolvimento de Sistemas adoptam modelos na perspectiva do algoritmo. A desvantagem deste tipo de visão reside no facto dos sistemas terem tendência para a instabilidade, isto é, à medida que os requisitos do sistema se alterem e o sistema cresça, tornar-se-á difícil proceder à manutenção sistemática de sistemas construídos a partir de modelos centrados em algoritmos [Booch 1999].
As metodologias ou abordagens mais contemporâneas do Desenvolvimento de Sistemas adoptam modelos na perspectiva orientada a objectos, onde o principal bloco de construção de todos os sistemas de software é o objecto ou a classe.