Uma Metodologia Rpida para o Ensino de Desenvolvimento Visual de Software Orientado a Objetos

Denis S. Silveira denis@cos.ufrj.br Programa de Engenharia de Sistemas e Computao COPPE/Sistemas Universidade Federal do Rio de Janeiro Caixa Postal 68.511, CEP:21.945-970 Rio de Janeiro, RJ Brasil Eber A. Schmitz eber@nce.ufrj.br Ncleo de Computao Eletrnica Instituto de Matemtica Universidade Federal do Rio de Janeiro Caixa Postal 2324, CEP:20001-970 Rio de Janeiro, RJ Brasil

Resumo
Este artigo apresenta o estgio atual do projeto de uma Metodologia Rpida de Desenvolvimento de Sistemas para uso no ensino de graduao. A motivao para o nosso trabalho vem da ausncia tanto de uma metodologia como de uma ferramenta simples e de acesso livre, que possam ser utilizadas no ensino das tcnicas de anlise e projeto orientado a objetos. O projeto tem como objetivo a construo de uma Metodologia Rpida para o desenvolvimento visual de sistemas orientado a objetos utilizando uma ferramenta CASE que seja distribuda gratuitamente aos estudantes. A metodologia abrange as fases do desenvolvimento que vo desde a captura de requisitos at o projeto detalhado das classes. A ferramenta prov todas as funcionalidades necessrias para a construo do modelo de requisitos como os modelos de anlise e projeto, que incluem o suporte criao de modelos tanto estticos como dinmicos. Palavras-chave: Metodologia, Ensino de Graduao, CASE, UML, Engenharia de Software, Orientao a Objetos, Arquitetura de Software, Engenharia de Requisitos

1. Introduo
Uma construo complexa, tanto do ponto de vista da engenharia como da arquitetura, na grande maioria das vezes centrada em modelos. Utilizamos modelos na construo de sistemas complexos, porque em geral no conseguimos compreender um sistema em sua totalidade. Um modelo uma descrio da realidade que ressalta alguns aspectos em detrimento de outros. Cada tipo de modelo utiliza uma notao precisa e um conjunto de regras sintticas e semnticas. Os modelos de sistema de informao podem ser classificados de acordo com seu estilo em: baseado em fluxo de dados, relacionais e orientado a objetos. A orientao a objeto, na dcada de 90 se afirmou como o estilo de projeto mais utilizado no desenvolvimento de software [01] [03] [05] [09] [11]. As grandes vantagens deste estilo de projeto so: uma melhor representao do mundo real devido ao mapeamento simples que existe entre os objetos computacionais e os do mundo real, um mecanismo simples para a modularizao e a possibilidade de construo de componentes extensveis.

A adoo da UML (Unified Modeling Language) [02] pela OMG (Object Management Group organizao formada pela maioria das empresas de software no mundo, e que trata da padronizao das tcnicas orientadas a objeto) em 1997 como padro para a descrio de modelos de sistemas orientados a objeto, trouxe como conseqncia 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 notao muito extensa, que cresce desde a anlise at o projeto. Certos elementos da notao (por exemplo, classes, associaes, agregaes, herana) so introduzidos durante a anlise. Outros elementos da notao (por exemplo, indicadores de restrio de implementao) so introduzidos durante o projeto [08]. O uso de uma linguagem de modelagem to complexa e extensvel quanto a UML requer um suporte de ferramentas CASE. Mesmo que os primeiros esboos de um modelo sejam feitos manualmente, a tarefa de manter, sincronizar e fornecer consistncia em um certo nmero de diagramas torna-se bastante difcil sem o uso de uma ferramenta. Um dos objetivos nesse projeto prover uma ferramenta simples, confivel, consistente e extensvel que disponibilizasse uma forma de comunicao com outros sistemas. Como toda ferramenta CASE deve permanecer associada a uma metodologia, decidimos escolher uma Metodologia Rpida para desenvolvimento de sistema orientado a objetos [10]. Essa escolha foi feita devido as seguintes caractersticas da metodologia: simplicidade e facilidade de aprendizado.

2. Problemas no Ensino de Desenvolvimento de Software Orientado a Objetos

O ensino de desenvolvimento de sistemas orientado a objetos encontra diversos problemas. O professor tem que resolver as seguintes questes: Qual metodologia utilizar? As metodologias que cobrem a orientao a objetos so muito detalhadas e no pode ser usada em um curso de graduao, ou ento, se apresentam de uma maneira muito didtica e no tocam nos verdadeiros problemas que os alunos vo encontrar na prtica; e Qual ferramenta adotar? A complexidade do processo de desenvolvimento de software exige o uso de ferramentas automatizadas. Essas ferramentas, alm de serem inviveis para as universidades, devido o seu custo, so bastante sofisticadas o que implica num tempo maior no processo de aprendizado.

2.1 Metodologias
A potencialidade vista no desenvolvimento de software utilizando a orientao a objetos ocasionou, no decorrer dessa dcada, a publicao de uma grande quantidade de metodologias [01] [03] [05] [06] [09] [11]. Hoje a que mais se destaca a abordagem adotada no Rational Unified Process (RUP) [06], que especifica uma forma de desenvolvimento cclico para o sistema.

O RUP um processo iterativo, onde cada iterao representa um ciclo completo de desenvolvimento, desde a captao de requisitos na anlise at a implementao e a realizao de testes, resultando numa verso executvel do sistema. Por sua vez, as iteraes so agrupadas em fases. Uma fase o perodo de tempo entre dois marcos de progresso, onde objetivos so alcanados, artefatos so concludos e decises so tomadas em relao passagem para a fase seguinte. O RUP define as seguintes fases: Concepo: estabelece os requisitos para o projeto; Elaborao: estabelece um plano de projeto e uma arquitetura slida; Construo: desenvolve o sistema; e Transio: fornece o sistema a seus usurios finais.

A passagem pelas quatro fases chamada de ciclo de desenvolvimento e resulta na gerao de um software. A gerao segue os seguintes fluxos de trabalho: Modelagem de negcio: descreve a estrutura e a dinmica da empresa; Requisitos: descreve o mtodo baseado em casos de uso para identificar requisitos. Anlise e projeto: descreve as vrias vises da arquitetura; Implementao: fase destina a codificao e testes de unidades; Testes: descrevem os casos de testes, procedimentos e medidas para acompanhamento dos erros; Entrega: abrange a configurao do sistema; Gerenciamento de configurao: controla as modificaes e mantm a integridade dos artefatos do projeto; Gerenciamento de projeto: descreve a s vrias estratgias para o trabalho como um processo iterativo; e Ambiente: abrange a infra-estrutura necessria para o desenvolvimento.

A adoo do RUP num curso de graduao em desenvolvimento de sistemas apresenta os seguintes problemas: Complexidade: o processo, que consiste de fluxos e fases, confuso para os iniciantes; Compatibilidade acadmica: num perodo normal de curso (4 meses) fica difcil fazer trabalhos prticos que exercitem todos os passos desta metodologia; e Prticas das empresas: existe uma grande distncia entre as prticas do RUP e as prticas de desenvolvimento de sistemas nas empresas, fazendo com que o aluno tenha dificuldades para aplicar alguma parte de seu conhecimento no seu trabalho.

2.2 Ferramentas
Existe um grande nmero d e ferramentas CASE disponveis no mercado. Entre elas, o Rational Rose [Web01] [08] uma ferramenta CASE muito poderosa e bastante completa e que d suporte s atividades do RUP. Por outro lado, todas estas ferramentas colocam alguns problemas ao professor: Custo: emboras estas ferramentas tenham verses acadmicas, seus preos esto fora do alcance da maioria das universidades da Amrica Latina e impedindo que os alunos possam instala-lo em suas casas; Lngua: todas as ferramentas operam em ingls, colocando mais uma barreira para o processo de aprendizado; e Recursos computacionais: o uso eficiente destas ferramentas requer uma mquina com razovel poder computacional.

A grande motivao para o nosso trabalho vem, exatamente, da ausncia de uma metodologia e uma ferramenta simples e de baixo custo, que possa ser utilizada para proporcionar uma melhor qualidade de ensino das tcnicas de anlise e projeto orientados a objetos. Dessa forma apresentamos a Metodologia Rpida [10] e o FAST CASE [12] [Web02], nome dado ferramenta, que foi projetado para ser uma ferramenta de um uso simples, eficiente e de fcil compreenso. Alm de ser completamente aderente a Metodologia Rpida.

3. A Metodologia Rpida
A Metodologia Rpida fornece diretrizes sobre os passos a serem tomados nos diversos estgios de desenvolvimento de software. A fim de torna-la didtica definimos uma arquitetura padro que define uma infraestrutura para a construo de sistema orientado a objetos. O objetivo principal dessa arquitetura padro prover um ambiente confivel e de fcil manuteno, onde aplicaes possam cooperar e evoluir de acordo com a necessidade do aluno. A adoo dessa arquitetura padro faz com que o aluno se prenda a outras questes, como por exemplo, qual a razo de executara este passo, por que ele deve ser feito nesta ordem? e assim por diante. Em suma, o estudante consegue perceber mais o significado ( o qu) e a importncia ( por qu) das tarefas que so executadas durante as fases (requisitos, anlise e projeto) do processo de desenvolvimento apresentado na Metodologia Rpida.

3.1 Arquitetura Padro

Quando o tamanho e a complexidade de um sistema aumenta, a importncia 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 so, os diferentes tipos de componentes de software e suas formas de interao [04].

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 responsveis pela forma de sequenciamento do programa; os protocolos para comunicao, sincronismo e acesso a dados entre estes componentes; a alocao de funcionalidade a cada um dos componentes; a distribuio fsica destes componentes; estudos de desempenho e escalabilidade; e formas de evoluo.

Embora a definio de sua arquitetura seja um aspecto crtico para qualquer software complexo, ainda no existe uma definio que seja aceita universalmente. A definio do que a arquitetura de um sistema pode variar de acordo com o tamanho do projeto, o tempo disponvel, os objetivos, o nvel de risco e inovao, o nmero de pessoas envolvidas, sua proximidade, suas habilidades para comunicao e resoluo de conflitos [07]. Na prtica, a definio da arquitetura de um software cumpre dois papis [04]: 1. fornecer um nvel de abstrao no qual os projetistas podem argumentar sobre o comportamento do sistema: funcionalidade, desempenho, confiabilidade, e etc; e 2. fornecer uma "conscincia" para a evoluo 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 anlogo criao da arquitetura de um prdio. Em ambos os casos, os arquitetos esto usando uma descrio simplificada para t ornar possvel a discusso de assuntos mais gerais, sem se preocupar, neste momento, com os problemas de construo dos componentes do sistema. A definio das formas de interao entre os componentes de uma arquitetura fornece uma grande variedade de alternativas para os projetistas de sistema. Estas formas de interao variam desde construes muito simples como as chamadas de procedimentos ou o uso de variveis compartilhadas at formas muito mais complexas tais como as interaes cliente-servidor e protocolos de acesso a bancos de dados. As propriedades globais das especificaes de arquitetura normalmente descrevem vises gerais do comportamento do sistema. Os problemas so tratados no nvel de sistema, como por exemplo, a forma de recuperao de falhas no sistema. O estilo de arquitetura de software orientado a objetos fornece outras abstraes para projetos de software. Na sua forma mais simples, os objetos permitem encapsular dados e comportamentos em componentes que apresentam uma interface explcita para outros componentes. Neste estilo possvel definir uma interao entre um grupo de objetos, que viro a formar um componente mais complexo. Sendo assim, a arquitetura utilizada pela Metodologia Rpida definir trs aspectos importantes para os objetos de um sistema [10]:

1. os mecanismos utilizados para o armazenamento de dados; 2. os mecanismos utilizados para a interface com o usurio; e 3. os mecanismos utilizados para o controle do sistema.

3.2 Modelo de Requisitos

A estrutura do Modelo de Requisitos mostrada na figura 1. Cada uma das caixas representa um ou mais documentos que devem ser apresentados no final da fase. O diagrama indica que o Modelo de Requisitos composto de: Modelo de Casos de Uso, uma Maquete e um Glossrio. Por sua vez, o Modelo de Casos de Uso composto de diagramas de caso de uso, cada um destes contm uma descrio para o caso de uso.

Figura 1 Estrutura do Modelo de Requisitos O roteiro a ser seguida na construo do modelo de Requisitos segue os seguintes passos : 1. Definir o escopo do sistema: isto pode ser feito inicialmente atravs de um documento inicial de requisitos, na forma de texto; 2. Executar iterativamente as seguintes etapas: Listar os casos de uso e seus atores; Descobrir e definir as entidades do domnio do problema; Acrescentar a cada um dos Casos de Uso; uma maquete da interface; e uma definio para o caso de uso; Estruturar os casos de uso; Definir as extenses para os casos (relao extends); e

 Definir os casos que podem ser colocados em evidncia e reaproveitados (relao uses); Definir os pacotes de casos de uso; e

3. Verificar o modelo.

3.3 Modelo de Anlise e Projeto

O objetivo desta fase produzir um plano que permita a construo do sistema. Num projeto de construo civil, esta fase corresponderia s plantas detalhadas da construo da casa. Em termos de software, a planta do sistema a especificao de suas classes componentes. Esta " planta" chamada de Modelo de Anlise e Projeto. O Modelo de Anlise e Projeto composto pelos Modelos: Esttico e Dinmico. O Modelo Esttico composto por um conjunto de diagramas de classes. O Modelo Dinmico composto por conjuntos de diagramas de seqncia e de estados.

Figura 2 Estrutura do Modelo de Anlise e Projeto Nessa fase o trabalho feito de uma forma iterativa pelo aluno, o que significa que ele no 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. O roteiro para a construo deste modelo : 1. Criar um diagrama com o modelo de classes do domnio do problema; 2. Criar um diagrama com o modelo de classes de cada um dos pacotes de casos de uso. Este modelo deve conter as classes de domnio (com os respectivos gerentes), interface e controle envolvidos no pacote de casos de uso. Coloque em cada uma delas as respectivas listas de

servios padronizados. Se forem classes de interface, obtenha informaes sobre as propriedades e servios a partir da maquete. Se for uma classe de controle obtenha informaes a partir d o diagrama de transio de estados que representa o pacote de casos de uso; 3. Fazer um diagrama de seqncia para cada pacote de casos de uso. Este passo, pode ser tornado de rotina se lembrarmos que as interaes entre o objeto de controle e os objetos de interface ou de domnio seguem alguns padres [10]; 4. Criar um diagrama de transio de estados para as classes de domnio, interface e controle que tenham ciclos de vida no-triviais; 5. Examinar novamente os diagramas de classes para verificar se algumas relaes de herana podem ser descobertas; e 6. Verificar o modelo.

4. Experincias e Concluses
A Metodologia Rpida vem sendo desenvolvida desde 1997. Neste perodo ela vem sendo aprimorada pelo uso em turmas de graduao em duas universidades na cidade do Rio de Janeiro. Por outro lado, o desenvolvimento da ferramenta FAST CASE, que acompanha o Metodologia Rpida, foi o resultado de uma tese de mestrado utilizando a Metodologia Rpida. A observao dos resultados obtidos com os alunos nos permite tirar as seguintes concluses: a forma simplificada usada pela Metodologia Rpida plenamente adequada para ser usada em um semestre acadmico; o fato de termos uma ferramenta CASE que pode ser livremente distribuda aos alunos implica que os alunos podem desenvolver trabalhos prticos que a nica maneira de realmente aprender o assunto; e o uso de uma arquitetura padronizada simplifica o problema de ensino das tcnicas de projeto, reduzindo o escopo das discusses a temas especficos. Permitindo que os alunos realmente compreendam os problemas de projeto que de outra forma seriam tratados de forma puramente conceitual.

5. Perspectivas Futuras
A ferramenta FAST CASE, distribuda junto com a Metodologia Rpida, apresenta uma arquitetura extensvel, o que possibilita o desenvolvimento independente de novas ferramentas CASE para serem acopladas ao FAST CASE. Neste momento, estamos desenvolvendo, utilizando a Metodologia Rpida, com nossos alunos de graduao os seguintes projetos: um gerador de programas Delphi que vai ler os dados em um nvel mais alto de abstrao (modelo de requisitos, modelos esttico e dinmico) e gerar um esqueleto de programa, de acordo com a arquitetura padro da linguagem;

um gerador de scripts de banco de dados, que vai converter os dados do modelo esttico (diagrama de classes) em scripts de banco de dados (de diversos fabricantes comerciais) de acordo com a arquitetura padro da Metodologia Rpida; e um programa para re-engenharia de software, que ter como objetivo principal recuperar informaes de projeto ( modelo esttico) a partir do cdigo fonte (em delphi), visando a obteno de sua representao em um nvel mais alto de abstrao.

Referncias Bibliogrficas
[01] Booch, G. Object-Oriented Analysis and Design with Applications, 2nd ed. Benjamin Cummings, Redwood City, Calif., 1994. [02] Booch, G., Jacobson, I., Rumbaugh, J. The Unified Modeling Language Reference Manual, Addison Wesley Object Technology Series 1999. [03] Coad, P., Yourdon, E., Object-Oriented Analysis 2a Edition, Prentice Hall, Inc., 1991. [04] Garlan et al., Architectural Styles, Design Patterns, and Objects, IEEE Software, 1997, pp.43-52. Jan/Fev

[05] Jacobson et al., Object-Oriented Software Engineering A Use Case Driven Approach, Addison Wesley, 1992. [06] Jacobson, I., Booch, G., Rumbaugh, J, The Unified Software Development Process, 1a Edition Addison Wesley Object Technology Series 1999. [07] Kerth, N. L., Cunningham, W., Using Patterns to Improve Our Architectural Vision, IEEE Software, Jan/Fev 1997, pp.53-59. [08] Quatrani, T., Visual Modeling with Rational Rose and UML, Addison Wesley, 1998. [09] Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall, 1994. [10] Schmitz, E., Silveira, D., Desenvolvimento de Sistemas Orientado a Objetos, BRASPORT, http://www.brasport.com.br, ISBN 85-7452-039-X 2000. [11] Shlaer, S., Mellor, S., Anlise de Sistemas Orientada para Objetos, Makron Books, 1990. [12] Silveira, D., FAST CASE Uma Ferramenta Visual para o Desenvolvimento Visual de Sistemas Orientado a Objetos, Tese de Mestrado, IM/NCE/UFRJ, 1999.

Webliografias
[Web01] [Web02] http://www.rational.com http://www.nce.ufrj.br/fastcase