Uma Metodologia de Desenvolvimento de Sistemas de Informações em Empresas de Pequeno e Médio Porte

Transcrição

1 Uma Metodologia de Desenvolvimento de Sistemas de Informações em Empresas de Pequeno e Médio Porte Autoria: Denis Silveira, Eber Schmitz Resumo: Este artigo apresenta uma Metodologia Rápida de Desenvolvimento de Software Orientado a Objetos (MRDS) para uso em empresas de pequeno e médio porte. As metodologias existentes no mercado são muito complexas envolvendo um grande número de fases e de tipos diferentes de documentos. Como conseqüência o esforço de implantação destas metodologias acaba não sendo compatível com o porte da empresa. O resultado final é que as empresas ficam sem usar metodologia alguma. A MRDS se propõe a resolver este problema, abrangendo as fases do desenvolvimento que vão desde da modelagem de processos de negócio até o projeto detalhado das classes. Com uma abordagem minimalista, a MRDS reduz ao mínimo o número de passos e, conseqüentemente, o número de documentos a serem produzidos. Todo o esforço de modelagem é concentrado na produção de modelos que sejam utilizados diretamente na geração do código fonte do sistema. Como conseqüência, a MRDS é uma metodologia com um custo muito baixo tanto para sua implantação como para sua utilização. Palavras chave: Metodologia, UML, Engenharia de Software, Orientação a Objetos, Arquitetura de Software, Modelagem de Negócio, Engenharia de Requisitos, CASE; 1 Introdução No decorrer do tempo, o papel das tecnologias de informação nas organizações vem sofrendo diversas alterações. Atualmente, as tecnologias de informação encontram-se na origem de mudanças significativas ao nível dos modelos de negócios das empresas, e constituem um elemento fundamental para a obtenção das vantagens estratégicas e competitivas (Cruz, 1998). Por isso, a respectiva implementada nas organizações devem ser cuidadosamente planejada e estruturada, de modo a garantir o alinhamento com os objetivos estratégicos do negócio. A crescente complexidade dos sistemas de informação e a dificuldade de representação da sua estrutura aos diversos interessados (gerentes, usuários, analistas, etc.), motivou durante a década de 80 e inicio da década de 90 um conjunto de esforços no sentido de formalizar e unificar a respectiva apresentação, de modo a permitir controlar e guiar o processo de construção de um sistema. Uma metodologia é um agregado de técnicas e ferramentas que tem por objetivo padronizar o processo de desenvolvimento de sistemas em uma empresa (Ghezzi, Jazayeri e Mandrioli, 1991). Uma metodologia para desenvolvimento de sistemas especifica a seqüência de passos e a serem seguidos durante o desenvolvimento de um sistema de informação. A cada um destes passos, associa-se um conjunto de atividades, seus produtos e as regras de verificação que garantem a passagem para a próxima fase (Pressman, 2001). Os produtos das diferentes fases de uma metodologia são especificações que descrevem, com um certo grau de abstração, o sistema de informação que está sendo desenvolvido. Esta especificação abstrata é chamada de modelo. Utilizamos modelos na construção de sistemas 1

2 complexos, porque em geral não conseguimos compreender o sistema em sua totalidade. Um modelo é uma descrição da realidade que ressalta alguns aspectos em detrimento de outros. Cada tipo de modelo utiliza uma notação precisa e um conjunto de regras sintáticas e semânticas (Schmitz e Silveira, 2000). Os modelos de sistema de informação podem ser classificados, de acordo com seu estilo, em: baseado em fluxo de dados, relacionais e orientado a objetos. A orientação a objeto, na década de 90 se afirmou como o estilo de projeto mais utilizado no desenvolvimento de software (Booch, 1994) (Coad e Yourdon, 1991) (Jacobson et al., 1992) (Rumbaugh et al., 1994) (Schmitz e Silveira, 2000). As grandes vantagens deste estilo de projeto são: uma melhor representação do mundo real devido ao mapeamento simples que existe entre os objetos computacionais e os do mundo real, um mecanismo simples para a modularização e a possibilidade de construção de componentes extensíveis. A adoção da UML (Unified Modeling Language) (Booch, Jacobson e Rumbaugh, 1999) pela OMG (Object Management Group) em 1997 como padrão para a descrição de modelos de sistemas orientados a objeto, trouxe como conseqüência um crescimento do uso da UML, em detrimento das outras, como linguagem de modelagem de sistemas orientados a objetos. A UML solucionou o problema da escolha da linguagem usada no modelo, mas trouxe consigo uma notação muito extensa, que cresce desde a análise até o projeto. Certos elementos da notação (por exemplo, classes, associações, agregações e herança) são introduzidos durante a análise. Outros elementos da notação (por exemplo, indicadores de restrição de implementação) são introduzidos durante o projeto (Quatrani, 1998). O uso de uma linguagem de modelagem tão complexa e extensível quanto a UML requer um suporte de ferramentas CASE (Computer Aided Software Engineering). Mesmo que os primeiros esboços de um modelo sejam feitos manualmente, a tarefa de manter, sincronizar e fornecer consistência em um certo número de diagramas torna-se bastante difícil sem o uso de uma ferramenta. 2 Problemas na Adoção de uma Metodologia A aplicação de uma metodologia de desenvolvimento de um sistema de informação orientado a objetos encontra diversos problemas, entre os quais, o mais importante é a mudança dos padrões de trabalho da equipe de desenvolvimento. Do ponto de vista mais restrito, da gerencia do processo de desenvolvimento, duas questões importantes aparecem quando uma organização resolver adotar uma metodologia de desenvolvimento de sistemas: Qual metodologia utilizar? As metodologias que cobrem a orientação a objetos ou são muito detalhadas e não podem ser usadas em empresas de pequeno porte, ou então, se apresentam de uma maneira muito didática e não tocam nos verdadeiros problemas que os profissionais vão encontrar na prática; e Qual ferramenta de suporte adotar? A complexidade do processo de desenvolvimento de um sistema exige o uso de ferramentas automatizadas. Essas ferramentas, além de serem inviáveis para uma empresa de pequeno porte, devido o seu custo, são bastante sofisticadas o que implica num tempo maior no processo de aprendizado. 2

3 2.1 Metodologias A potencialidade vista no desenvolvimento de sistemas utilizando a orientação a objetos ocasionou, no decorrer dessa década, a publicação de uma grande quantidade de metodologias (Booch, 1994) (Coad e Yourdon, 1991) (Jacobson et al., 1992) (Rumbaugh et al., 1994) (Shlaer e Mellor, 1990) (Schmitz e Silveira, 2000). Hoje a que mais se destaca é a abordagem adotada no RUP (Rational Unified Process) (Jacobson, Booch e Rumbaugh, 1999), que especifica uma forma de desenvolvimento cíclico para o sistema. O RUP é uma metodologia (ou processo) iterativa, onde cada iteração representa um ciclo completo de desenvolvimento, desde a captação de requisitos na análise até a implementação e a realização de testes, resultando numa versão executável do sistema. Por sua vez, as iterações são agrupadas em fases. Uma fase é o período de tempo entre dois marcos de progresso, onde objetivos são alcançados, artefatos são concluídos e decisões são tomadas em relação à passagem para a fase seguinte. O RUP define as seguintes fases: Concepção: estabelece os requisitos para o projeto; Elaboração: estabelece um plano de projeto e uma arquitetura sólida; Construção: desenvolve o sistema; e Transição: fornece o sistema a seus usuários finais. A passagem pelas quatro fases é chamada de ciclo de desenvolvimento e resulta na geração de um sistema. A geração segue os seguintes fluxos de trabalho: Modelagem de negócio: descreve a estrutura e a dinâmica da empresa; Requisitos: descreve o método baseado em casos de uso para identificar requisitos. Análise e projeto: descreve as várias visões da arquitetura; Implementação: fase destinada a codificação e testes de unidades; Testes: descrevem os casos de testes, procedimentos e medidas para acompanhamento dos erros; Entrega: abrange a configuração do sistema; Gerenciamento de configuração: controla as modificações e mantém a integridade dos artefatos do projeto; Gerenciamento de projeto: descreve as várias estratégias para o trabalho como um processo iterativo; e Ambiente: abrange a infra-estrutura necessária para o desenvolvimento. A adoção do RUP em um treinamento numa empresa de médio e pequeno porte de desenvolvimento de sistemas apresenta os seguintes problemas: Complexidade: o processo, que consiste de fluxos e fases, é confuso para os iniciantes; Tempo de aprendizado: num período normal de curso de treinamento (2 meses) fica difícil fazer trabalhos práticos que exercitem todos os passos desta metodologia; e Práticas das empresas: existe uma grande distância entre as práticas do RUP e as práticas de desenvolvimento de sistemas nas empresas, fazendo com que o 3

4 2.2 Ferramentas iniciante tenha dificuldades para aplicar alguma parte de seu conhecimento no seu trabalho. Um CASE é um conjunto de técnicas e ferramentas automatizadas que auxiliam os projetistas de sistemas no desenvolvimento de aplicações, com o objetivo de diminuir o respectivo esforço e complexidade, de melhorar o controle do projeto, de aplicar sistematicamente um processo uniformizado e de automatizar algumas atividades como a verificação de consistências entre os modelos (Pressman, 2001). Existe um grande número de ferramentas CASE disponíveis no mercado. Entre elas, o Rational Rose (Rational, 1998) (Quatrani, 1998) é uma ferramenta CASE muito poderosa e bastante completa e que dá suporte às atividades do RUP. Por outro lado, as ferramentas, existentes no mercado, colocam alguns problemas aos gerentes das organizações. São eles: Custo: seus preços estão fora do alcance da maioria das pequenas empresas; Língua: um grande número de ferramentas operam em inglês, colocando mais uma barreira no processo de aprendizado; e Recursos computacionais: o uso eficiente de algumas ferramentas requer uma máquina com razoável poder computacional. 2.3 Arquitetura de Software Quando o tamanho e a complexidade de um sistema aumenta, a importância relativa da estrutura global do sistema se torna mais importante do que os aspectos mais localizados, tais como, a escolha dos algoritmos e das estruturas de dados usadas no processamento. A arquitetura de software se preocupa com estes aspectos mais gerais, que no nosso caso são, os diferentes tipos de componentes de software e suas formas de interação (Garlan et al., 1997). A arquitetura de software estuda um conjunto de aspectos estruturais que envolvem: a forma de organizar o sistema como um conjunto de componentes interconectados; as estruturas de controle responsáveis pela forma de sequenciamento do programa; os protocolos para comunicação, sincronismo e acesso a dados entre estes componentes; a alocação de funcionalidade a cada um dos componentes; a distribuição física destes componentes; estudos de desempenho e escalabilidade; e formas de evolução. Embora a definição de sua arquitetura seja um aspecto crítico para qualquer sistema complexo, ainda não existe uma definição que seja aceita universalmente. A definição do que é a arquitetura de um sistema pode variar de acordo com o tamanho do projeto, o tempo disponível, os objetivos, o nível de risco e inovação, o número de pessoas envolvidas, sua proximidade, suas habilidades para comunicação e resolução de conflitos. 4

5 Na prática, a definição da arquitetura de um sistema deve cumprir dois papéis (Garlan et al., 1997): 1. fornecer um nível de abstração no qual os projetistas podem argumentar sobre o comportamento do sistema: funcionalidade, desempenho, confiabilidade, e etc; e 2. fornecer uma "consciência" para a evolução do sistema, indicando quais aspectos do sistema podem ser facilmente alterados sem comprometer a integridade do sistema. Em outras palavras, o desenvolvimento da arquitetura de um software é análogo à criação da arquitetura de um prédio. Em ambos os casos, os arquitetos estão usando uma descrição simplificada para tornar possível a discussão de assuntos mais gerais, sem se preocupar, neste momento, com os problemas de construção dos componentes do sistema. 3 A Metodologia Rápida de Desenvolvimento de Sistemas Um dos objetivos da MRDS é diminuir a quantidade de documentos produzidos na construção de um sistema de qualidade (ver figura 1). Desse modo, dividimos o processo de desenvolvimento em três fases. A primeira define o Modelo de Processos. Esta fase descreve os processos tais como eles possam ser entendidos, e otimizados dentro da organização. A segunda é a definição do Modelo de Requisitos. Essa fase tem por objetivo definir os requisitos do sistema, ou seja, responder a seguinte pergunta: qual as funcionalidades esperadas pelo sistema? Não é escopo desse artigo definir como obter um bom modelo de requisitos. Entretanto, o modelo de requisitos é fundamental para se chegar a um bom projeto. A terceira fase, chamada de Modelo de Análise e Projeto, tem como objetivo transformar o Modelo de Requisitos na definição dos módulos componentes do sistema. Nessa fase fazemos uso de uma arquitetura padrão. A arquitetura padrão utilizada não especificará uma solução particular em detrimentos de outra, mas guiará o projetista a uma forma de estruturar suas decisões que o levará a um resultado positivo. 3.1 Modelo de Processos Um sistema de informação é um conjunto integrado de recursos (humanos e tecnológico) cujo objetivo é satisfazer adequadamente a totalidade das necessidades de informação de uma organização e os respectivos processos de negócio (Stair, 1998). Um processo de negócio pretende representar uma seqüência de atividades, que processam vários inputs e produzem vários outputs e que possuem objetivos (Gonçalves, 2000). Desse modo, um processo descreve uma seqüência de passos ou atividades que podem ser expressas em ações por um indivíduo, um grupo ou um sistema de informação (isto é, algum ator ou agente). O Diagrama de Atividades, definido na UML, foi escolhido para a modelagem de processos. Ele ilustra uma seqüência de atividades, manuais ou automatizadas, necessárias à execução de um processo (Booch, Jacobson e Rumbaugh, 1999). Entre as suas características, destaca-se a possibilidade de representação de atividades paralelas, diferenciando-o de um mero fluxograma. No Modelo de Processos as atividades são passos de processamento dentro de um processo transformando objetos e requerendo recursos para sua execução. Atividades podem ser agrupadas dentro de um processo de domínio em sub-processos. Atividades possuem entradas e saídas que 5

6 devem ser descritos no formato de objetos. Após especificação detalhada das atividades, são determinados os requisitos necessários para sua execução. Os produtos dessa fase envolvem diversos elementos, dos quais destacamos os principais abaixo: processos: são coleções de atividades; atividades: são as tarefas (trabalhos) a serem realizados. Uma atividade requer recursos para realizar um script; artefatos: são produtos produzidos ou consumidos por atividades durante a sua realização; recursos: representam tudo que é necessário para a execução da atividade. Um recurso humano, especificamente, desempenha um papel na execução das atividades do processo; transição: é o encadeamento entre duas atividades; e desvio: é um condicional para a transição entre duas ou mais atividades. 3.2 Modelo de Requisitos O objetivo da fase de Modelagem de Requisitos é especificar as funcionalidades de um sistema a ser desenvolvidos (Schmitz e Silveira, 2000). Um requisito é uma especificação de uma determinada ação ou determinada condição que o sistema deverá satisfazer. Os produtos dessa fase são: Modelo de Use Cases Pacotes com use cases: modelos que mostram os atores e os use cases com as suas relações. Cada use case será acompanhado da suas descrição textual. Essa descrição segue ao modelo utilizado em (Schmitz e Silveira, 2000); Maquete Interfaces gráficas: as maquetes devem especificar todos os componentes de interface (telas, botões, campos, etc.) que são utilizados pelo sistema; Modelo de Domínio Classes de Domínio: As classes de objetos que devem ser documentadas; O roteiro a ser seguido na construção do Modelo de Requisitos segue os seguintes passos: 1. Definir o escopo do sistema: Essa definição deverá ser retirada através dos Diagramas de Atividades; 2. Criar uma versão preliminar do Modelo de Domínio, ou seja, as classes do domínio do problema, definindo quais as entidades e suas definições. Este modelo será melhorado e corrigido a medida que os Use Cases forem sendo detalhados. 3. Executar iterativamente as seguintes etapas: Listar os casos de uso e os atores que interarem com o sistema; Acrescentar a cada um dos Use Cases; uma maquete da interface; e 6

7 uma definição para o Use Case.; Estruturar os casos de uso; definir as extensões para os casos (relação extends); e definir os casos que podem ser colocados em evidência e reaproveitados (relação uses); Definir os pacotes de Use Cases; 4. Verificar o modelo para tirar os possíveis erros de consistência entre as maquetes, descrição dos use cases e a Modelagem de Processos. 3.3 Modelo de Análise e Projeto O objetivo desta fase é produzir um plano que permita a construção do sistema. Essa fase é composta pelos Modelos Estático e Dinâmico. O Modelo Estático é composto por um conjunto de diagramas de classes. O Modelo Dinâmico é composto por um conjunto de diagramas de seqüência e de estados. Esta etapa deve ser feita de forma iterativa pelo projetista, o que significa que ele não deve esperar obter o modelo final na primeira vez, mas sim, que terá de executar estes passos repetidamente até obter um modelo completo e consistente. A figura 3 mostra o esquema da interação das fases da MRDS. O roteiro para a construção deste modelo é: 1. Para cada pacote de use cases, definido no Modelo de Requisitos, deverá ser definido um diagrama de classes. Esse diagrama de classes deverá mostrar os relacionamentos entre as classes de domínio, interface e controle. Na próxima seção apresentaremos com mais detalhes essas classes. 2. Para cada pacote de use cases, definido no Modelo te Requisitos, deverá ser definido um diagrama de seqüência. Este passo pode ser tornado de rotina se lembrarmos que as interações entre o objeto de controle e os objetos de interface ou de domínio seguem alguns padrões definidos em (Schmitz e Silveira, 2000); A criação dos diagramas de seqüência é um passo fundamental para a definição da implementação dos casos de uso do sistema. Ao definir os serviços que cada um dos objetos participantes do caso deve prover para a execução do mesmo, o projetista vai refinando as definições das classes do sistema, previamente, definidos no Modelo de Domínio. 3. Criar um diagrama de transição de estados para as classes de domínio, interface e controle que tenham ciclos de vida não-triviais; 4. Examinar novamente os diagramas de classes para verificar se algumas relações de herança podem ser descobertas; e 5. Verificar os modelos para tira os eventuais erros de consistência entre os modelos definidos. 7

8 Figura 1 Visão Geral da MRDS 3.4 A Arquitetura Padronizada da MRDS Um dos grandes desafios das metodologias de desenvolvimento de software é resolver o problema de transformação do modelo de requisitos na especificação dos módulos constituintes do sistema. Esta atividade, conhecida como projeto, é intrinsecamente complexa, pois para cada modelo de requisitos temos uma infinidade de maneiras de definir os módulos que irão compor a implementação. Uma das maneiras de atacar este problema é definindo uma arquitetura de software para o sistema (Shaw e Garlan, 1996) (Garlan et al., 1997). A arquitetura padrão da MRDS define uma infraestrutura para a construção de sistemas orientados a objetos. O objetivo principal dessa arquitetura padrão é prover um ambiente confiável e de fácil manutenção, onde aplicações possam cooperar e evoluir de acordo com a necessidade da organização. A adoção dessa arquitetura padrão faz com que o projetista possa concentrar o seu esforço na solução dos problemas de projeto relevantes ao sistema em desenvolvimento que são: (1) quais as classes que comporão o sistema? (2) quais os serviços que cada uma delas deve prover? 8

9 O estilo de arquitetura de software orientado a objetos fornece outras abstrações para projetos de software. Na sua forma mais simples, os objetos permitem encapsular dados e comportamentos em componentes que apresentam uma interface explícita para outros componentes. Neste estilo é possível definir uma interação entre um grupo de objetos, que virão a formar um componente mais complexo. Sendo assim, a arquitetura utilizada pela MRDS definir três aspectos importantes para os objetos de um sistema (Schmitz e Silveira, 2000): 1. os mecanismos utilizados para o armazenamento de dados; São os objetos que persistem as informações do sistema. Estes objetos correspondem aos objetos do domínio do problema, que são identificados no modelo de Requisitos. 2. os mecanismos utilizados para a interface com o usuário; São os objetos encarregados da interação entre usuários e sistema. Transformam eventos externos em sinais internos e eventos internos em sinais para o mundo externo; 3. os mecanismos utilizados para o controle do sistema. são os objetos encarregados do sequenciamento entre os objetos de interface com os objetos de domínio. Figura 2 - Estrutura das classes da Arquitetura Padrão 4. Experiências e Conclusões A MRDS vem sendo desenvolvida desde Neste período ela vem sendo aprimorada pelo uso, tanto em turmas de graduação como em projetos de empresas de pequeno e médio porte. A adoção de uma metodologia de desenvolvimento de sistemas em empresas de pequeno e médio porte encontra como obstáculos: (1) o custo da implantação, (2) o impacto do uso da metodologia na produtividade dos profissionais da empresa. A MRDS permite atacar estes dois problemas da seguinte maneira: Custo: a MRDS reduz o tempo gasto no ensino da metodologia devido a sua simplicidade; e Impacto: o foco da MRDS é na utilização dos modelos que são diretamente empregados na geração de código-fonte. Desta maneira, o tempo de modelagem é efetivamente tempo de projeto e (indiretamente) de codificação. De acordo com as constatações em resultados práticos, verificamos que a utilização da MRDS auxiliou na construção de Sistemas de Informação, fornecendo conceitos e vocabulário comuns para o tratamento deste tipo de sistema, apresentando as vantagens esperadas, mas 9

10 não garanti, por si só, o sucesso do desenvolvimento do projeto, ficando este diretamente relacionado à existência e à qualidade do Modelo de Requisitos e à execução do projeto. Embora a arquitetura padrão tenha se mostrado útil para os desenvolvedores, explicando as entidades envolvidas na arquitetura, suas responsabilidades, e os aspectos de comunicação entre elas, encontramos um problema que é o surgimento de entidades que não se adequam a nenhum dos objetos disponíveis na arquitetura padrão, ou que apresentam características mistas, como por exemplo, objetos de interfaces que fazem parte do domínio do problema. O surgimento destas entidades, que fogem à semântica apresentada, mostra que a arquitetura padrão deverá ser acrescida de outras arquiteturas que solucionem tal problema. Exemplos de arquiteturas são mostrados em (Buschman et al., 1996). A MRDS apresentou uma solução para o desenvolvimento de Sistemas de Informação. Esta solução mostrou cumprir os objetivos desejados, e isto foi verificado pelos projetos reais para os quais esta metodologia foi aplicada. Referências Bibliográficas Booch, G. Object-Oriented Analysis and Design with Applications, 2 nd ed. Benjamin Cummings, Redwood City, Calif., Booch, G., Jacobson, I., Rumbaugh, J. The Unified Modeling Language Reference Manual, Addison Wesley Object Technology Series Buschman, F., et al., Pattern-Oriented Software Architecture, A System of Patterns, John Wiley & Sons, Coad, P., Yourdon, E., Object-Oriented Analysis 2 a Edition, Prentice Hall, Inc., Cruz, T., Sistemas de Informações Gerenciais Tecnologia da Informação e a Empresa do Século XXI, Editora Atlas, Garlan et al., Architectural Styles, Design Patterns, and Objects, IEEE Software, pp.43-52, Jan/Fev Ghezzi, C., Jazayeri, M., Mandrioli, D., Fundamentals of Software, Engineering, Prentice Hall, Inc., Gonçalves, J. E. L., As Empresas são Grandes Coleções de Processos, RAE - Revista de Administração de Empresas, Jan/Mar, V.40, n.1, 2000; Jacobson et al., Object-Oriented Software Engineering A Use Case Driven Approach, Addison Wesley, Jacobson, I., Booch, G., Rumbaugh, J, The Unified Software Development Process, 1 a Edition Addison Wesley Object Technology Series Quatrani, T., Visual Modeling with Rational Rose and UML, Addison Wesley, Pressman, R. S., Software Engineering A Practitioner's Approach, 5 a Edition, McGraw-Hill series in computer science, 2001; Rational Software Corporation, Rational Rose 98 Extensibility User Guide, Publications Department, 1998; Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall,

11 Rational Software Corporation, Rational Rose 98 Extensibility User Guide, Publications Department, Schmitz, E., Silveira, D., Desenvolvimento de Sistemas Orientado a Objetos, BRASPORT, ISBN X Shaw, M., Garlan, D., Software Architecture, Prentice-hall, 1996; Shlaer, S., Mellor, S., Análise de Sistemas Orientada para Objetos, Makron Books, Silveira, D., FAST CASE: Uma Ferramenta para o Desenvolvimento Visual de Sistemas Orientados a Objetos, Tese de Mestrado, IM/NCE/UFRJ, Stair, R., Princípios de Sistemas de Informação Uma Abordagem Gerencial, Segunda Edição, Editora LTC, 1998; 11