Sistema de Informao

Valdir Nascimento dos Santos

POSSVEL A GERAO AUTOMTICA DE CDIGOS PARA A CONSTRUO DE SISTEMAS DE INFORMAO A PARTIR DO USO DA UML?

Salvador 2011

Valdir Nascimento dos Santos

POSSVEL A GERAO AUTOMTICA DE CDIGOS PARA A CONSTRUO DE SISTEMAS DE INFORMAO A PARTIR DO USO DA UML?

Projeto de Pesquisa da disciplina Projeto Especifico 1 do curso de Sistemas de Informao requisito Pacheco EAD da UNIFACS, na como para dos aprovao Santos e disciplina, Elvas

orientado pelos professores: Marcos Antonio Tatiana Gonalves.

Salvador 2011

SUMRIO Pginas 1. APRESENTAO ...................................................................................... 4 2. INTRODUO ............................................................................................5 2.1. O PROBLEMA ..........................................................................................6 2.2. OBJETIVOS ..............................................................................................6 2.2.1. Objetivo Geral ........................................................................................7 2.2.2. Objetivos Especficos .............................................................................8 3. JUSTIFICATIVA ............................................................................................9 4. FUNDAMENTAO TEORICA....................................................................10 4.1 Programao Orientada a Objetos X Programao Estruturada ..............10 4.2 Programao gil e UML...........................................................................12 4.3 Documentao de sistemas desenvolvidos...............................................14 4.4 Agilidade com UML....................................................................................15 5. METODOLOGIA........................................................................................17 6. CRONOGRAMA........................................................................................19 7. REFERNCIAS.........................................................................................20

1. APRESENTAO Este documento faz parte de um processo de pesquisa, que ter incio com este projeto e mais adiante culminar em um trabalho que ser de fundamental importncia na vida de muitos acadmicos e profissionais da rea de projetos e programao que se dividem entre os que vm na UML um ferramenta poderosa no auxlio ao entendimento de um problema e na projeo de solues, e os que acham que ela sirva apenas para tomar tempo e atrasar o servio proposto. Em um momento da histria que humanidade vive sob lema: Time is Money, perder tempo pode significar perca de espao no mercado global, e a UML pode ser a chave para resolver questes entre ser gil e ao mesmo tempo ter qualidade no desenvolvimento de software para sistemas de informao, desde os mais simples aos mais robustos, unindo entendimento do problema e codificao de alta qualidade em uma nica ferramenta.

2. INTRODUO Com o advento do POO (Programao Orientada a Objetos), muitas questes surgiram em torno das melhores prticas para o desenvolvimento de software. Os programadores mais puritanos criaram uma ojeriza em torno do assunto, pois davase a entender que os adeptos deste tipo de programao teriam preguia de escrever cdigos longos e repetitivos e tudo ficou ainda pior com o surgimento das ferramentas RAD (Rapid Aplication Development), que auxiliam na montagem de uma interface com simples arrastar ou clicar elementos em um form e por traz dele surgi a codificao destes elementos (Button, Label, Edit, etc.) tornando mais rpido a codificao de determinadas partes de um sistema. Falando de ferramentas RAD bom salientar que, com o seu surgimento, outras confuses foram observadas. No difcil, por exemplo, neo-programadores dizerem que ao arrastar e soltar botes em um form seria orientao a objeto, desde quando este paradigma mais complexo e mostra um conjunto de tcnicas bem elaboradas fazendo com que elementos do mundo real fossem reproduzidos com alta abstrao se tornando um objeto programvel que pode se comunicar com outro objeto dentro de um mesmo sistema, independente que haja uma interface bem elaborada ou no. O fato que o OO chegou para revolucionar a forma de conceber a programao e o desenvolvimento de sistemas. Muitos programadores tiveram que se adaptar a este novo paradigma, algo que nem sempre fcil, pois nem todo mundo aberto a mudanas, principalmente quando esta feita de modo radical, substituindo o modo de ver, pensar e resolver o problema. A UML - Unified Modeling Language uma linguagem para modelar problemas e solues orientado a objetos, que ganhou espao entre programadores por sua facilidade de comunicao e compreenso. Ela faz uso de todos os conceitos da OO, tornando o processo de descoberta de erros relacionados produo de software, mas fcil, pois possui um alto poder de abstrao dividindo o problema em etapas e aproveitando o que de fato interessa para o que est sendo analisado. Consome certo tempo para a sua total elaborao, consenso entre muitos programadores que, se no for encontrado outras utilidades para esta ferramenta, seu potencial poder perder sentido diante da agilidade que os projetos atuais requerem. 5

2.1. O PROBLEMA Mas o que chama a ateno o desenvolvimento comercial e tecnolgico. As exigncias do mercado tambm mudaram radicalmente, tornando-se inevitvel o aprimoramento das tcnicas de desenvolvimento para que seja garantida ao usurio final do software, a qualidade aliada velocidade com que os mesmos possam estar disponveis e prontos para uso. No mundo em que sair sempre na frente tudo, o tempo tem que ser prioridade, mas os desenvolvedores sabem que no adianta pressa sem perfeio. Ento, como aliar esses dois elementos? A UML uma linguagem grfica padro para a elaborao da estrutura de projetos complexos de software. Ela pode ser empregada para visualizar, especificar, construir e documentar os artefatos de sistemas de software. Porm, o que se questiona sobre esta ferramenta que: ser ela mesma til? Em que tipo de projeto ela deve ser empregada? Ser que possvel lhe atribuir outras funes alm de modelagem de problemas? Atualmente com uso da reengenharia possvel obter o esqueleto de cdigos a partir dos diagramas de classe, mas ser mesmo possvel construir cdigos robustos de forma dinamizar o trabalho de codificao de um sistema avanado utilizando esta tcnica sem perder tempo e eficincia? 2.2. OBJETIVO 2.2.1 Objetivo Geral Apresentar algumas tcnicas que vem sendo utilizadas no mundo da programao com uso de conhecimentos da engenharia do software, que tem revolucionado a forma de gerenciar e desenvolver projetos e mostrar de forma objetiva como a UML pode contribuir para um desenvolvimento mais rpido de cdigos robustos de software sem abrir mo de uma boa documentao dos projetos voltados para a produo de sistemas de informao.

2.2.2 Objetivos Especficos a) Demonstrar o porqu da programao orientada a objetos tem dado melhores retornos aos programadores do que a programao estruturada; b) Demonstrar as vantagens e desvantagens da programao gil ou leve comparando-as com a UML; c) Mostrar o quanto pode ser decisivo manter uma boa documentao dos projetos realizados para a produo de software; d) Demonstrar de que forma possvel utilizar a UML para produzir cdigos bem elaborados para sistemas de informao atravs do processo de reengenharia;

3. JUSTIFICATIVA Quando se quer que as coisas possuam qualidade e sejam extremamente eficientes, imprescindvel que se monte um projeto do que se deseja fazer, pois este dar um norte, apontar a direo a ser percorrida por uma equipe para que se alcance a excelncia e, to imprescindvel quanto um projeto a boa comunicao entre todos os envolvidos na busca de solues para o alcance de seu objeto. Aps anos de estudos percebeu-se na modelagem um elemento forte para melhorar a compreenso do problema e o entendimento entre analistas e programadores, a fim de diminuir erros no desenvolvimento de softwares. Em projetos bem elaborados existe equilbrio entre as principais restries de negcios, que : tempo, qualidade e custos. Devido a estes fatores aliados ao nmero crescente de analistas e programadores que vm na UML um entrave no fator tempo, principalmente nos dias atuais onde o cumprimento de prazos e metas visto como extremamente fundamental para que haja sucesso nos negcios, que se torna importante discutir e apresentar solues para que o trabalho desses profissionais, possa se tornar mais gil sem a necessidade de abrir mo de uma boa documentao do projeto desenvolvido e dos processos utilizados na produo do software. Pouco se discute sobre a possibilidade de se modelar problemas e desta modelagem se produzir automaticamente cdigo final executvel e que possuam flexibilidade para mudanas pontuais. Neste sentido, este trabalho se torna pertinente, pois ir buscar fundamentos que contribuam para entender como a UML poder ser usada com mais eficincia no desenvolvimento de sistemas orientados a objetos. Existem enumeras publicaes sobre a programao gil (XP e outros) e nestas publicaes so mostradas maneiras de integrar a equipe responsvel pela anlise e desenvolvimento de sistemas, e eles afirmam que pelos processos utilizados para tal, a comunicao quase que perfeita e pouco ou nada utilizado da UML pelos motivos j mencionados. Mas, para os que no aderem esse tipo de programao e preferem manter uma documentao detalhada para futuros projetos ou at mesmo para facilitar a manuteno do sistema, podendo compreender o passo a passo do seu desenvolvimento, j que os sistemas atuais so cada vez mais complexos e, portanto, precisam ser compreendidos parte por parte para no 8

se perder no meio da anlise de centenas ou milhares de linhas de cdigo, o que fazer? Esse grupo de profissionais, tambm precisam se adequar aos padres dos novos tempos e sabem que tem que ter agilidade e compromisso com a qualidade. Se eles no aderem a esta programao gil e no abrem mo de uma boa modelagem visual, nada mais justo de que eles possam ter na UML este ponto de equilbrio entre agilidade e documentao farta que garanta a qualidade do servio, a manutenibilidade do sistema e a sua entrega em pleno cumprimento de prazos. Portanto, contribuir com os estudos que no param de avanar na engenharia do software, descobrindo como tirar melhor proveito das ferramentas existentes, sem, no entanto, se fechar para novas ferramentas que surgem neste campo, uma proposta valiosa para ser discutida e avaliada neste trabalho. Por fim, se tcnicos e universitrios, que comeam a entrar no mercado da anlise e da programao, no tiverem noo do que a UML representa no s em comunicao visual e produo de artefatos, mas tambm em termos de programao, certamente esta importante ferramenta cair em desuso, o que j se observa em diversas obras que tratam sobre anlise e projeto de sistemas de informao, onde muitas delas abordam superficialmente a utilidade da UML e do mas nfase em outros processos de desenvolvimento de software, que tem sua importncia, mas tambm suas deficincias. Se este documento conseguir ao menos, clarear a idia deste tema, j ter prestado grande contribuio ao universo acadmico.

4. FUNDAMENTAO TERICA A utilidade da UML vem sendo discutida exaustivamente nas redes sociais, nos fruns de discusso e em ambientes acadmicos. No momento em que novas metodologias de desenvolvimento de software vem surgindo como a metodologia gil, analistas e desenvolvedores se dividem em torno da idia do ser ou no ser til o uso da UML e os pontos positivos e negativos desta ferramenta, no web blog de Miguel Alho(2008), programador web e especialista em projetos na rea de sistema de informao, ele apresenta um texto com o seguinte ttulo: A morte da UML...?, onde o mesmo se surpreende com o nmero de pessoas que consideram a UML intil. No mesmo artigo, apresentado um site americano, que traz um artigo intitulado de: 13 razes para a descida da UML na escurido onde possvel visualizar o nmero imenso de opinies contra e a favor da UML. A princpio, este trabalho pode parecer querer fazer um contraponto entre a metodologia gil e a UML, porm no esta a ideia, pelo contrrio, as duas ferramentas de desenvolvimento e compreenso de software podem se completar a depender da ocasio. Apenas sero abordados mtodos que podem influir na agilidade, qualidade e boa documentao no processo de construo de software. O professor e Dr. Raul Sidnei Wazlawick, em seu livro Anlise e projeto de Sistemas de Informao Orientados a Objetos, diz o seguinte sobre isso:
Pode-se at dizer que o mtodo seria inspirado em Extreme Programming ou XP, no qual, em vez de usar uma linguagem de programao (como Java ou PHP), utilizam-se diagramas e outros artefatos. Dentro desta proposta, diagramas e artefatos s fazem sentido se contriburem diretamente para a gerao automtica de cdigo. No so usados, portanto, como mera documentao, mas como programao em nvel muito alto. (WAZLAWICK,

2010, P. 1).

4.1 Programao Orientada a Objetos X Programao Estruturada A programao orientada a objetos quem d inicio a toda esta discusso quanto aos melhores mtodos e ferramentas para desenvolvimento de software de qualidade e com agilidade. Antes dela a discusso sempre esteve em torno das melhores prticas de produo de software sem levar em conta o tempo de entrega do produto. 10

No mdulo Programao II da Universidade Federal de Pernambuco, escrito pelo professor Fernando Antnio Mota Trinta, mostra que cada paradigma de programao uma evoluo do outro, embora tenha havido uma quebra ainda mais profunda do mesmo, quando houve tal evoluo das linguagem de montagem, imperativa para a linguagem procedural e desta para o paradigma estrutural. Mota Trinta (2010) ainda mostra que apesar da quebra de paradigma entre o estrutural e a orientao a objetos, existem entre eles grandes semelhanas:

Figura 01 Paradigma orientado a objeto VS Paradigma Estruturado extrado de (Trinta, 2010).

Apesar das semelhanas, existem tambm diferenas que acabam fazendo com que a orientao a objetos seja superior programao estruturada: Na programao estruturada, a reusabilidade limitada a trechos de
algoritmos representados por meio de sub-rotinas. Na programao orientada a objeto possvel reutilizar todo um mdulo, no caso o objeto, com seus mtodos e seus atributos. Em geral, a programao orientada a objetos ainda apresenta como vantagens: cdigo mais lgico, e melhor encapsulado, uma maior facilidade de manuteno e extenso do cdigo, um melhor reaproveitamento de cdigo, dentre outros. (TRINTA,

2010, p. 19).

Ainda baseado em TRINTA (2010) e suas fontes de pesquisa, no se pode confrontar diretamente esses dois principais paradigmas de programao, pois um herdeiro do outro:
A programao orientada ao objeto (object-oriented programming) pode ser considerada como uma extenso quase natural da programao modular. Apesar de seus conceitos j terem sido estabelecidos desde a dcada de 70, apenas em meados da dcada de 90 que este paradigma comeou a ganhar maior destaque na comunidade de desenvolvimento de sistemas. (TRINTA,

2010, p. 22). 11

Ao longo do desenvolvimento deste trabalho, poder ser percebido que apesar das vantagens e desvantagens de cada paradigma, o sucesso no desenvolvimento de software no depende exclusivamente do paradigma escolhido, mas sim de outros fatores que s vezes passam despercebidos de muitos gerentes de projetos, com afirma Alberto Silva e Carlos Videira em seu livro UML Metodologias e ferramentas CASE (2001):
Em qualquer desenvolvimento de sistemas de informao necessrio definir a interveno e conjugar corretamente as interaes entre as pessoas, o processo aplicado, as caractersticas do produto e o projeto que orienta as atividades a desenvolver. o que Roger Pressman apelida dos "quatro P's associados ao desenvolvimento de software [Pressman00]. S pessoas (informticos, gestores e utilizadores) motivadas e comprometidas com o projeto garantem o respectivo sucesso; s um processo com tcnicas e regras bem definidas permite atingir os objetivos propostos; s compreendendo as necessidades reais dos utilizadores se pode produzir um produto de qualidade; s com um projeto credvel e controlado possvel cumprir prazos e custos propostos. Independentemente do mtodo utilizado, estas devero ser sempre preocupaes comuns a todas as implementaes de software. (SILVA e

VIDEIRA, 2001, p. 30).

4.2 Programao gil e UML Como a engenharia do software, ainda uma cincia considerada em desenvolvimento, existem muitas propostas (metodologias) para melhorar o desempenho do desenvolvimento de sistemas computacionais, porm algumas tm surgido com muita fora e desprezando elementos como a UML, considerados positivos em dias anteriores, mas at onde seria correto desprez-los?
Como reao a esta situao, um novo grupo de metodologias comeou a aparecer nos ltimos anos, que implicam um nvel de formalismo muito menor. Muitas delas advogam a no realizao de atividades de anlise e desenho, e a produo de muito menos documentao por comparao com as metodologias estruturadas ou orientadas por objetos. Defendem que a principal documentao de um sistema , ou deveria ser, o cdigo fonte das aplicaes desenvolvidas. Comungam entre si a idia de que as principais atividades a realizar ao longo de todo o processo de desenvolvimento so essencialmente a programao e os testes. (SILVA

e VI-

DEIRA, 2001, p. 101)

12

Neste tipo de abordagem est includa a metodologia gil como a XP - Extreme Programming, Scrum, Feature Driven Development e DSDM - Dynamic System Development Method. Este mtodo tem suas vantagens quando utilizado em projetos de menor porte onde existam pessoa bastante comprometidas com o desenvolvimento do sistema e profissionais experientes, j em outros momentos como a necessidade de se reforar o controle de projetos, ser prefervel utilizar com mas nfase uma metodologia que contemple uma melhor documentao do sistema com o uso da UML, o que afirma Silva e Vieira (2001). A comparao das diversas metodologias atualmente existentes
uma tarefa complexa devido a um conjunto de dificuldades que se colocam e das quais podemos destacar as seguintes: No existem metodologias iguais e portanto em qualquer comparao estaremos sempre a comparar conceitos por vezes no comparveis. Muitas metodologias so influenciadas ou particularmente concebidas para serem utilizadas com linguagens de programao especficas. Muitas metodologias assumem um contexto de aplicao onde no existem os problemas que no mundo real tm que enfrentar. A abrangncia das metodologias varia fortemente; algumas apenas descrevem um processo, outras incluem tcnicas e notaes. A comparao entre metodologias tem que considerar obrigatoriamente apenas um subconjunto das mesmas, e um subconjunto de funcionalidades. (SILVA e

VIDEIRA, 2001, p. 102)

Muita gente acha que UML uma metodologia, porem bom salientar o que Wazlawick (2010) revela em sua obra, quando ele afirma que a letra mais importante da sigla UML o L, pois a UML no uma metodologia mais sim uma linguagem com todas as notaes que possam caracteriz-la:
Semntica e notao para tratar um grande nmero de tpicos atuais de modelao. Semntico para tratar tpicos de modelao futura, relacionados em particular com a tecnologia de componentes, computao distribuda, frameworks e Internet. Mecanismos de extenso de modo a permitir que futuras aproximaes e notaes de modelao possam continuar a ser desenvolvidas sobre o UML. Semntica e sintaxe para facilitar a troca de modelos entre ferramentas distintas. (SILVA e

VIDEIRA, 2001, p. 118). 13

4.3 Documentao de sistemas desenvolvidos Todo cincia produz documentos detalhados de seus experimentos, para que durante o ciclo de desenvolvimento da teoria pesquisada, o cientista no venha se perder em meio a tantos estudos e experincias. Aps tudo devidamente preparado e no havendo mais questes a serem debatidas ou momentaneamente no havendo nada que possa contestar a afirmao apresentada pelo pesquisador (cientista), os documentos produzidos serviro como base para novas pesquisas ou continuidade da mesma em busca de aprimoramento do que j fora produzido. Da mesma forma, ocorre com a produo de softwares. Sem uma ampla documentao do que est sendo produzido, ser possvel o aprimoramento ou a manuteno do sistema se esse for deveras complexo? Em busca desta resposta, que no fcil de encontrar, devido a pouca importncia dada por muitos autores e acadmicos, um artigo escrito por um especialista no assunto, traz informaes brilhantes sobre isto. Marcos Rocha, Gerente de TIC (Tecnologia da Informao e Comunicao) da Knowtec, aborda este assunto. Entre outras coisas ele diz: Mas ento, por que mesmo documentar? A principal questo em relao a isso est relacionada prpria natureza dos softwares, que tm algumas caractersticas predominantes: complexo, pode ser desenvolvido por vrias pessoas; Pode ser desenvolvido para atender determinadas necessidades, ou Est em constante evoluo, sempre recebendo modificaes; Ser utilizado por pessoas que no necessariamente o desenvolveA partir dessas caractersticas, percebemos ento que a documentao de software existe principalmente para: Registrar quais so os processos que ele executa; Registrar como o sistema foi desenvolvido, que outros programadoRegistrar como o processo de desenvolvimento ocorreu, para que os

para automatizar determinados processos;

ram e que, na maioria das vezes, no so especialistas em tecnologia.

res possam entend-lo e realizar modificaes; prximos projetos sejam melhores;

(ROCHA, Marcos. O dilema da documentao no processo de desenvolvimento de software. Disponvel em: <http://www.baguete.com.br/artigos/577/marcus-rocha/10/03/2009/odilema-da-documentacao-no-processo-de-desenvolvimento-de-softw>. Acesso em: 10 mar. 2009).
Registrar como o sistema deve ser utilizado pelos seus usurios.

14

4.4 Agilidade com UML Muitos fatores podem definir que um projeto de produo de software tenha sido um sucesso, mas os principais deles so a qualidade, o tempo de entrega e o custo final do produto. Desses fatores citados, talvez o de maior relevncia para muitos desenvolvedores est relacionado agilidade na produo do sistema com nfase na codificao e no teste. Sobre isso levantado uma questo: Como UML pode contribuir para a qualidade e agilidade na produo de um dito sistema? Ser mesmo a UML um perca de tempo? Em uma entrevista concedida Revista Viso gil, Ian Roughley, Lder no desenvolvimento do framework Struts2, se contrape UML, embora ele admita que de quando em vez, utilize a UML, mesmo que sendo de modo descartvel.
Por exemplo, se todas as propriedades de uma classe Java so fornecidas em um diagrama de classe UML no documento de design, ento todas as vezes que uma mudana for feita no cdigo, o diagrama precisa ser gerado novamente e o documento de design precisa ser modificado. Isso acrescenta um esforo a mais significativo para implementar funcionalidades e corrigir bugs. Se o trabalho est sendo executado em um ambiente muito rgido, esta abordagem pode no ser possvel.

(VISO

GIL, 2011, P. 26). Na viso de quem j experimentou e estuda o assunto, encontra-se algumas discordncias no que fora afirmado na entrevista, e em outros pontos apresentado solues, para o exemplo citado por Ian onde ele julga como problema. Existe no mercado uma gama de ferramentas construdas com a finalidade de agilizar o processo de produo e modelagem de sistemas. Essas ferramentas so nomeadas de CASE. A sigla CASE ( Computer-Aided Software Engineering) significa Engenharia de Software Auxiliada por Computador e usada para designar os produtos que auxiliam no projeto e desenvolvimento de um software. Um produto classificado como uma Ferramenta CASE quando este oferece documentao, automao e racionalizao do projeto de software e de sua implementao. Dentre as classes de Ferramentas CASE, pode-se destacar os geradores automticos de aplicaes e as ferramentas de modelagem, projeto e implementao de bancos de dados. Existem ferramentas CASE que so confundidas como linguagem de programao, o caso do Delphi que um RAD que compila a linguagem object pascal. Existem muitos conceitos associados a uma ferramenta CASE, porm, h trs que possvel des15

tacar para exemplificar as possibilidades de se manter o foco na UML sem abrir mo da agilidade:
A aplicao do princpio "concept to code" significa na prtica que deveria ser possvel a partir da especificao dos requisitos de um problema, definir e implementar a respectiva soluo. De forma a garantir a correo e a minimizao da interveno humana, o ideal seria efetuar as fases posteriores de forma automtica. A este processo chamamos Forward Engineering. No entanto, em outros casos interessante ter a possibilidade de efetuar o percurso inverso, isto , a partir de cdigo previamente existente, produzir os modelos de desenho e de anlise correspondentes. A este ciclo designamos por Reverse Engineering, e ao conjunto dos dois por Round-Trip Engineering. (SILVA e

VIDEIRA, 2001, p. 416).

Baseado no mtodo de Larman, Wazlawick (2010) afirma que possvel utilizar a UML para produzir software de qualidade a partir da UML e ainda demonstra a construo de um sistema utilizando a UML associada OCL Object Constraint Language. O Visual Studio (2010) em seu site oficial fala o seguinte:
A partir de um modelo UML, voc pode gerar cdigo de programa, esquemas, documentos, recursos e outros artefatos de qualquer tipo. Um mtodo conveniente para gerar arquivos de texto de um modelo UML usar modelos de texto. Elas permitem que voc incorpore o cdigo de programa dentro do texto que voc deseja gerar. Padres. Muitas vezes, os desenvolvedores na Contoso, Ltd criar sites e projetar o esquema de navegao usando diagramas de classe UML. Cada pgina da Web representada por uma classe e associaes representam os links de navegao. Os desenvolvedores geram muito do cdigo de um site do modelo. Cada pgina da Web corresponde a vrias classes e as entradas do arquivo de recurso. Este mtodo tem os benefcios que a construo de cada pgina est de acordo com um padro nico, tornando mais confivel e flexvel do que o cdigo escritas mo. O padro nos modelos de gerao, enquanto o modelo usado para capturar os aspectos de variveis.

(VISUAL STU-

DIO 2010. Microsoft. Gerar arquivos a partir de um modelo UML. Disponvel em: <http://msdn.microsoft.com/ptbr/library/ee329480.aspx>. Acesso em: 01 out. 2011).

16

Silva e Videira (2001) afirmam que as ferramentas CASE auxiliaram as metodologias e as notaes orientadas a objetos como a UML, e estas serviram para a especificao de software. Para isso muitos desenvolvedores tero que compreender melhor o paradigma orientao a objetos e a UML, como afirma Wazlawick (2010), que conclui o pensamento dizendo que: comprar um martelo no transforma voc em um arquiteto: pode ser necessrio, mas no suficiente. 5. METODOLOGIA A pesquisa a ser realizada neste trabalho pode ser classificada por objetivo, ela exploratria, descritiva e explicativa. Isto porque ela deve se concentra no desdobramento do objetivo principal, elucidando e descrevendo o passo a passo do desenvolvimento de sistemas de informao com rapidez e qualidade e explicando como isso feito e trazendo sempre na medida do possvel, sugestes que pouco foram exploradas, mas que podem apontar novos caminhos para o universo acadmico de desenvolvimento gil. Quanto metodologia o trabalho em mos faz a opo pelo mtodo indutivo e comparativo. Esta opo se justifica porque os mtodos escolhidos permitem que a pesquisa parta de pontos de vista comuns, trazido por vrios desenvolvedores em suas observaes particulares e as mesmas devero conduzir a um conhecimento mais amplo a cerca do assunto tratado por autores renomados cujos anos de experincia e estudos, credenciam afirmar muitas destas observaes como verdadeiras e experimentadas. O mtodo comparativo se aplicar na busca da compreenso de vrios mtodos utilizados para a produo de sistemas de informao com tempo mnimo respeitado e com qualidade, comparando com a idia abordada por alguns autores que no abrem mo da utilizao da UML para modelar problemas, mas tambm para gerar cdigos complexos com qualidade. Espera-se com a utilizao das duas metodologias, que, para alguns autores se completam, estabelecer parmetros que produzam tanto novos conhecimentos no campo desta pesquisa, quanto o esclarecimento de conhecimentos j produzido por outros autores, mas que no foram trabalhado na medida em que prope este projeto. Enquanto procedimento, este trabalho realizar-se- por meio de observao direta e indireta, porque se torna necessrio buscar a origem da informao, como 17

ela fora produzida e ao mesmo tempo importante conhecer a opinio de quem consome este conhecimento produzido, assim, a partir da experincia das pessoas que utilizam as tcnicas mencionadas neste projeto e dos comentrios feitos a partir das fontes diretas, possvel compreender melhor o assunto que ser abordado nesta pesquisa. Por tanto, este trabalho utilizar-se- de pesquisas bibliogrficas em livros de autores consagrados, de estudiosos do assunto, sites que trabalham com o contedo do qual se prope este projeto, resultados de entrevistas divulgadas em revistas especializadas alm da leitura e documentao de informaes pertinentes ao assunto extradas de artigos de outros autores acadmicos. Estas ferramentas permitiram e permitiro com a busca de novas fontes, que fossem reunidas vrias informaes a cerca do assunto que do bases consistentes para o levantamento do problema e para a sua soluo. A partir destas ferramentas o autor envereda pelo universo impreciso e desconhecido da pesquisa com uma idia fundamentada, mas que pode sofrer mutaes no decorrer do desenvolvimento do trabalho ao adquirir novos conhecimentos sobre o tema, sem, contudo, perder de vista os limites e o interesse da questo principal que norteia esta obra. O material documentado, bem como, as respectivas anlises ser organizado em relatrio de pesquisa componente do estudo monogrfico que se pretende construir. Para o desenvolvimento deste Trabalho, sero definidas as seguintes etapas, no necessariamente nesta ordem: Estudo da UML; Conceitos sobre esta linguagem; Estudo da metodologia gil e das metodologias que a antecede; Estudo e definio de ferramentas CASE; Concluso sobre as melhores prticas para o desenvolvimento de softwares sem abrir mo da UML, a possibilidade ou impossibilidade de sua aplicao;

18

6. CRONOGRAMA ETAPAS Levantamento bibliogrfico Fichamento de textos Coleta de fontes Anlise de fontes Organizao do roteiro Redao do trabalho Reviso / redao final / entrega Ms/1 Ms/2 X X X X X X X X X X X X X X X X X X Ms/3 Ms/4 Ms/5 Ms/6

19

7. REFERNCIAS ALHO, Miguel. A morte do UML?? Disponvel em: <http://miguelalho.com/?p=650>. Acesso em: 01 out. 2011. PIMENTEL, Manoel. Entrevista com Ian Roughley:: Lder no desenvolvimento do framework Struts2. Revista Viso gil: Edio Eletronica para Dowload, Www.visaoagil.com, n. 5, p.23-26, 08 set. 2011. Mensal. PRESSMAN, Roger S.. Engenharia de Software: Traduo Jos Carlos Barbosa dos Santos. 3 ed. So Paulo: Makron Boks, 1995. ROCHA, Marcos. O dilema da documentao no processo de desenvol-vimento de software. Disponvel em: <http://www.baguete.com.br/artigos/577/marcus-rocha/ 10/03/2009/o-dilema-da-documentacao-no-processo-de-desenvolvimento-de-softw>. Acesso em: 10 mar. 2009. SILVA, Alberto Manuel Rodrigues da; VIDEIRA, Carlos Alberto Escaleira. UML, Metodologias e Ferramentas CASE: Linguagem de Modelao UML, Metodologias e Ferramentas CASE. 1 ed. Lisbo: Centro Atlntico, 2001. TRINTA, Fernando Antonio Mota. Mdulo Programao II. Recife: Ufrpe, 2010. 1 v. VISUAL STUDIO 2010. Microsoft. Gerar arquivos a partir de um modelo UML. Disponvel em: <http://msdn.microsoft.com/pt-br/library/ee329480.aspx>. Acesso em: 01 out. 2011. WASLAWICK, Raul Sidnei. Analise e Projeto de Sistema de Informao Orientado a Objetos. 2 edio Rio de Janeiro: Campus, 2011.

20