Capitulo 3 - EvoLucAo Das METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE Tépicos = Introdugao " A Programacio como Fonte de Inovacio " Desenvolvimento Ad-Hoc * As Metodologias Estruturadas " As Metodologias Orientadas por Objectos " Outras Abordagens " Comparacio de Metodologias = Conclusio = Exercicios 3.1 Introdugao No inicio dos anos 60, Edsget Dijkstra afirmou que qualquer pedaco de cddigo é essencialmente uma série de instrugdes de natureza matemitica, € como tal é possivel provar a sua cotteccio [Dijkstra65]. Posteriormente, em 1969 no artigo intitulado Structured Programmming [(Dij 1269], ele realcou a importincia da prevencio de erros, para além de utilizar pela primeira vez a expressio “programacio estruturada”.56 CENTRO ATLANTICO~ UML, METODOLOGIAS E FERRAMENTAS CASE - VoL. | Como ja referimos no Capitulo 1, a expresso engenharia de software foi pela primeira vez aplicada cm 1967 numa conferéncia da NATO, ¢ em 1971, Niklaus Wirth publicou o artigo “Program Development by Stepwise Refinement” [Wirth71], com base no trabalho de Edsger Dijkstra ¢ C. Bohm [Bohm66], defendendo a ideia da construgio de programas de forma incremental, a custa de unidades mais clementares. Em 1972, David Parnas publicou 0 seu célebre artigo sobre encapsulamento dé informagio [Parnas72], no qual reforcava a ideia de Wirth relativamente 4 importincia de dividir um programa em unidades mais clementares, cada uma delas apenas disponibilizando um conjunto de funcionalidades, mas “escondendo” a respectiva implementacio. Todos estes exemplos reforcam a importincia de conceitos propostos desde finais da década de 600 principios da década de 70 e que tiveram impacto na actividade € téenicas de programacio utilizadas. No entanto, jd em finais dos anos 60 se reconhecia que este esforgo nao seria suficiente, e que era preciso rentabilizar 0 trabalho do programador através de medidas com impacto em Areas que nao apenas a programacio. Larry Constantine tentou identificar mecanismos que possibilitassem que a concepgio inadequada de software fosse evitada desde o inicio, aquando da identificagio de requisitos. Em conjunto com Wayne Stevens ¢ Glen Myers propos © conceito de Composite Design, renomeado para “desenho estruturado” [Stevens74], que procurava representar sob a forma de diagramas as accdes de um programa que posteriormente seriam codificadas, Esta foi uma das primeiras iniciativas no sentido de definir um processo mais consistente e abrangente, aplicado a todo © ciclo de desenvolvimento de software cujos conceitos foram introduzidos no Capitulo 2. O objectivo deste capitulo é apresentar, de forma resumida, a evohugio histérica dos processos de desenvolvimento de software, de forma a enquadrar ¢ compreender a importincia dos esforcos recentes em torno do paradigma da orientagio por objectos e em particular da linguagem UML. Apresentamos ¢ discutimos com particular relevancia os processos que adoptam uma abordagem estruturada (Seccio 3.4) ¢ orientada por objectos (ecco 3.5). 3.2 A Programacao como Fonte de Inovagao Até muito recentemente os principais saltos qualitativos em termos de conceitos com impacto significativo nas Areas abrangidas pela engenharia de software iniciaram-se sempre pela area das linguagens de programacio.CAPITULO 3— EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 57 Métodos orientados por objectos Métodos algoritmicos Linguagens Orientadas por objectos Linguagens estruturada eS 4G Linguagens maquina, assembly 1 4 hs i t t t t t t F + + + 1960 1970 1980 1980 2000. ® Figura 3.1: Visio bistérica dos métadas de desenvolvimento de software. ‘A Figura 3.1 ilustra a evolucao das principais técnicas e abordagens que ao longo do tempo tém ocupado lugar de destaque ao nivel da progtamacio, consoante o grau de complexidade ¢ da dimensio do software. De acordo com estes parimetros, podemos identificar quatro fases principais. Num primeiro momento surgitam as linguagens de baixo nivel, muito proximas da tecnologia ¢ fortemente condicionadas por cla, na qual se incluem as linguagens méquina, em que as instrugdes cram meras sequéncias de bits. A primeira iniciativa no sentido de elevar a actividade de programacio surgiu com 0 aparecimento das linguagens assembly, que utilizavam mneménicas como forma de substituir 0 édigo maquina. A primeira alteragio com impacto deu-se com o apatecimento das primeiras linguagens simbélicas (Fortran, Algol, Cobol), numa tentativa de aproximar mais a8 técnicas de programacio do proceso de raciocinio humano. As_primeiras linguagens etam utilizadas sobretudo para célculos cientificos ¢ de engenharia (Fortran), mas gradualmente foram ganhando peso as linguagens para aplicagdes comerciais (Cobol). Eram linguagens eminentemente imperativas, em que as instrugdes diziam o que se fazia. No entanto, a inexisténcia de regras sintacticas ¢ semanticas possibilitava a construcio de programas dificeis de compreender. Data desta altura a expressio “cédigo esparguete”, que resultou da utilizacio abusiva da instrugio GOTO, ¢ que resulta dos inimeros saltos que um programa poderia aptesentar! Esta segunda fase decorreu principalmente durante os anos 1960/70, € caracterizou-se pelo desenvolvimento de aplicagdes razoavelmente simples ¢ de58 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE ~ VoL. | pequena dimensio, mas em que as ferramentas de apoio eram ainda relativamente incipientes, ¢ os métodos de desenvolvimento eram essencialmente algoritmicos. ‘A tetceira fase, que se iniciou durante os anos 70, foi caractetizada pelo desenvolvimento de sistemas de maior dimensio com base em. linguagens estruturadas de mais alto nivel (por exemplo, Pascal, C, 4GL), que eram suportadas por métodos estruturados. Os programas construidos com recurso As linguagens estruturadas apresentavam uma organizacio em blocos de cédigo, constituidos 4 custa de construgées simples (isto sequéncias, seleccdes e repetigdes). O aumento da complexidade ¢ dimensio dos programas causou graves problemas nas técnicas de programacio, pois os programas cram constitufdos por uma sequéncia de blocos de instrugdes, todos localizados fisicamente no mesmo ficheiro, 0 que nfo facilitava a decomposicio do problema noutros mais elementares nem suportava adequadamente 0 trabalho em equipa. O outro grande problema residia na utilizacio abusiva dos dados globais a um programa, que possibilitevam que todas as instrugées de um programa acedessem a esses dados, tornando dificil perceber quem manipulava que informacio, e dificultando a vetificagio da consisténcia do sistema. Com o aparecimento da linguagem Simula [BirtWhistle79] em finais dos anos 60, foi possfvel definir uma associagio forte entre dados e cédigo. De forma a impossibilitar estes acessos, os tedticos propuseram o conceito de tipo de dados abstracto, cuja principal coneretizacio pritica ocorreu na linguagem Ada [Ansi83]. Estes novos tipos de dados permitem “esconder” totalmente partes da sua implementagao (quer ao nivel dos dados, quet do cédigo), € disponibilizam para 0 exterior 6 que se designa por interface. Igualmente nesse sentido, a linguagem Modula-2 (definida pelo mesmo autor da linguagem Pascal, Niklaus Wirth, ¢ descrita de forma acessivel em [Walmsley90)) introduziu © conceito de médulo, enquanto bloco de cédigo no qual um programa se poderia decompor. A ideia era agrupar num médulo dados ¢ cédigo, que estivessem relacionados de forma a limitar as interacedes entre médulos a invocagio de fungdes. No entanto eta ainda possivel acedet do exterior aos dados declarados dentro de um médulo. A. evolucio dos conceitos referidos nos dois parigrafos anteriores em termos de abstracgio e de encapsulamento da informagio conduziu naturalmente ao aparecimento das linguagens orientadas por objectos (por cxemplo, Smalltalk, C++, Java, Object Pascal). A principal distingio entre os objectos e os tipos de dados abstractos é que os primeiros suportam a nogio de heranca, 0 que nio se vetifica nos segundos (ver Seccio 3.5). Nesta fase, 0 desenvolvimento de softwareCaPiTULo 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 59 € ainda mais complexo ¢ de maior dimensio, 0 que exige o suporte por parte de tecnologias avangadas como sejam frameworks aplicacionais, framevorks de middleware, componentes de software ¢ utilizacio de ambientes de desenvolvi- mento. Na Figuta 3.2 é apresentado um modelo simplificado que demonstra a visibilidade dos dados e como estes se encontram relacionados com o cédigo, relativamente a cada um dos conceitos acima referidos: (1) programa, (2) médulo, (3) tipos de dados abstractos ¢ (4) objectos. Programa eat patos) backsd (Dados) (Dados) | (1) poe] Figura 3.2: A evolugio dos conceitos de abstracgiio nas linguagens de programagii. Na Figura 3.3 pode ser observado um diagrama que resume a evolugio das linguagens de progtamacio nos tltimos 40 anos, e onde apenas representamos as linguagens mais significativas para as abordagens de desenvolvimento discutidas neste livto, Por isso, nao € feita qualquer referéncia a outros tipos de linguagens como sejam as relacionadas com inteligéncia astificial (por exemplo, Prolog) ou com processamento simbélico (por exemplo, Lisp).60 CENTRO ATLANTICO —UML, METODOLOGIAS E FERRAMENTAS CASE VoL. | 4 Primeiras me orion Lingeagens rae Linguagens Linguagens Precursoras 0-0 0-0 Figura 3.3:.A evolugao das linguagens de programagio. Se ao nivel das linguagens a evolucdo ao longo do tempo tem sido significativa, o mesmo aconteceu em tetmos de outros conceitos da engenharia de software, o que vamos analisar de seguida. 3.3 O Desenvolvimento Ad-Hoc Em face das potencialidades limitadas disponibilizadas ao nivel das linguagens de programacio, ¢ dos restantes componentes de suporte tecnolégico (computadores, sistemas operativos, tecnologias de armazenamento de informacio), as primeiras aplicagdes foram construidas sem a utilizagio de uma metodologia de desenvolvimento formal, correspondendo ao que normalmente se designa por “programar ¢ cortigit” (do inglés “build and fix”). A atengio estava concentrada na programagio € na resolugdo das diversas restrigdes de natureza técnica, nomeada- mente nas capacidades limitadas do hardware da altura. As profissdes na area deCaPiTULo 3 — EvoLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 61 informatica eram, por exceléncia, a do programador que desenvolvia e testava os programas ¢ a do operador que os executava. Neste perfodo, muitas organiz ces implementaram sistemas em ambientes pro- prietirios, tipo mainfiame, utilizando a linguagem Cobol para programar, ¢ ficheiros para o armazenamento da informagio; estes desenvolvimentos eram catacterizados por: = Envolvimento limitado dos utilizadores. = [dentificacio de requisitos efectuada de forma inadequada. = Fraca utilizagio de técnicas de anilise ¢ desenho, que quando muito tinham uma perspectiva ad-hoc ¢ eram de natuteza empitica. = Inexisténcia de ferramentas de apoio a todo o proceso. = Tatefas de desenvolvimento muito demoradas. = Sistemas de acesso a informagio pouco flexiveis. Esta preocupagio fortemente tecnoldgica implicou que frequentemente os requisitos dos utilizadores fossem selegados para segundo plano, o que na altura nao constitufa um problema demasiado grave, uma vez que as aplicagdes eram simples, limitando-se a substituir (de forma limitada) tatefas realizadas manual mente por processos automaticos. A medida que a complexidade aumentou, tal situagio tornou-se cada vez mais problemitica, 0 que foi também agravado por outras situacdes: * Os informiticos eram reconhecidamente bons programadores, mas raramente tinham a preocupacio de compreender 0 negécio ¢ de utilizar um discurso € express6es aceites ¢ compreendidas por pessoas niio técnicas. As relagdes interpessoais nfio eram as melhores ¢ ainda hoje vivemos as consequéncias desses primeiros tempos. = Nao eram aplicados técnicas ou mecanismos de controlo € de gestio de pro- jecto, ¢ por isso estes ultrapassavam frequentemente custos ¢ prazos estima- dos. = A fraca qualidade do produto final implicava correcgdes frequentes, 0 que justificava o significativo peso relativo das tatefas de manutengio ¢ a conse- quente diminuigio do tempo disponivel para o desenvolvimento de novas solucdes (infelizmente esta continua a ser uma realidade dos nosso dias). Apesar destes problemas todos, 0 ritmo de adopgio de sistemas informiticos foi crescendo, 0 que s6 veio reforcar a necessidade de rever a abordagem de desen- volvimento seguida de modo a introduzir ¢ aplicar um proceso sistematizado e formalizado de desenvolvimento.Conceito Conceito 62 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | 3.4 As Metodologias Estruturadas Durante os anos 70 ¢ 80 assistiu-se a um importante salto qualitativo com a introdugio de um conjunto de metodologias que se baseavam essencialmente em técnicas estruturadas de decomposicio funcional. Estas metodologias tinham por objective formalizar o processo de identificacio de requisitos, de modo a reduzir as possibilidades de ma interpretacio dos mesmos, ¢ introduzir técnicas baseadas nas melhores priticas no proceso de anélise e desenho. A designacio de metodologias estruturadas deriva da aplicaciio de um conjunto de principios semelhante ao utilizado pelas linguagens de programagio com 0 mesmo nome, nomeadamente o principio da decomposicao funcional. 3.4.1 Contexto e Motivacao Foi neste contexto que apareceram pela primeira vez 0s conceitos de ciclo de vida ¢ de metodologia de desenvolvimento de software, com a respectiva sequéncia de fases e actividades, com entradas e saidas, regras, intervenientes, técnicas, notacdes, ferramentas, documentagio, técnicas de gestio, etc., com o objectivo de prestar mais atengio ao processo global, e menos 4 programacio. A maioria destas metodologias adoptaram 0 modelo em cascata, apresentado na Secgio 2.6 deste livro, em que cada actividade tem que ser finalizada antes que a actividade seguinte possa ser iniciada. As metodologias estruturadas tradicionais estavam essencialmente orientadas segundo uma de duas abordagens: (1) uma mais orientada para a decomposigéo funcional do sistema ¢ a identificagio dos respectivos processos; (2) outra mais centrada nos conceitos ¢ nos dados das organizagdes. Estas duas perspectivas so normalmente designadas por anilise funcional e andlise orginica. Na andllise funcional, funcdcs, algoritmos e actividades sio a preocupacio central do engenhciro de software, colocando o énfase nas funcionalidades que o sistema deve realizar ¢ numa fase posterior na definicio de como essas funcionalidades serio implementadas. Esta abordagem é também consequéncia da estrutura que as linguagens de programagio tradicionais “impunham” aos programas, com base na definigio de blocos de cédigo que petmitiam algum nivel de autonomia e de encapsulamento de informacio. No entanto, a possibilidade dos dados serem globalmente visiveis ¢ manipulados por todo o programa reduzia significativamente essas caracteristicas. Esta estrutura era pouco flexivel, no sentido da incorporagéo de novas funcionalidades ¢ da correccao de ertos de implementagio, uma vez que alteragdes num determinadoCAPITULO 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 63 ponto do programa poderiam produzit consequéncias indesejiveis ¢ nio facilmente identifica veis noutros pontos do programa. Na anilise organica, a atengio concentra-se nos dados, sendo os conccitos ¢ as entidades manipuladas no negécio os elementos mais importantes para o desenvolvimento do sistema. Esta preocupagio incide sobretudo na compreensio € no agrupamento de dados comuns, ¢ na identificagao de relagdes entre esses grupos de informacio (veja-se por exemplo a Figura 3.9 ¢ a discussio da Seccio 3.7.1 relativamente a este assunto). A ideia é que mesmo quando uma aplicacio muda, os conceitos principais devem permanecer ¢ continuar a ser utilizados, sem alteragdes significativas. A anélise de dados envolve a tecolha, validacio ¢ classificacio das entidades, atributos ¢ relacdes existentes num determinado dominio do problema. 3.4.2 Conceitos Basicos As metodologias estruturadas introduziram um conjunto de conceitos, a maioria dos quais concretizados em diversos diagramas, dos quais destacamos os seguintes: * © conceito Processo (de negécio) é uma sequéncia de actividades, que processam varias entradas ¢ produzem varias saidas. Cada processo pode ser subdividido em processos mais elementates até se atingit um nivel que niio € possfvel decompor mais. * Fluxo de Informagao representa toda a circulacdo (c o respective suporte) de informacio que ocorre numa organizacio de forma a executar os processos de negocio. Repositério de dados representa o conjunto de conceitos sobre os quais a organizacio pretende reter informacio para utilizagao futura. = Entidade representa todos 0s conceitos de negécio, entidades fisicas ou abs- tractas, internas ou externas 4 organizagio, que sio relevantes para 0 desem- penho adequado da funcio da organizacio. = Estado de uma entidade é representado pelo conjunto de valores que os atributos da entidade podem assumir. = Evento é um acontecimento que é desencadeado internamente ou externa- mente ao sistema, ou pode representar simplesmente a passagem de tempo, € que despoleta uma mudanca de estado. Os trés primeiros conceitos sio exclusives das abordagens orientadas a processos, enquanto os trés tiltimos (mas sobretudo 0 quarto) sio comuns aos métodos orien- tados a processos e aos dados.64 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | E relativamente ficil a identificagio destes conceitos numa situacdo concreta. O problema ¢ conseguir obter uma descri¢io (isto é, um enunciado) bem organizada € objectiva dessa situacdo. Apresenta-se de seguida um enunciado que descteve 0 funcionamento da gestio de compras numa empresa, € nele sio identificados os principais processos que ocorrem (e que se encontram sublinhados). Este exemplo sera utilizado na Seccao 3.4.3 para se clarificar as notacGes mais frequentes nestas metodologias. xemplo 3.1: Descrigéo do problema da gestao de compras (pers- pectiva funcional). Gestio de compras de materiais de uma empresa. Sempre que algum funciondrio tem necessidade de comprar bens para as suas actividades, preenche uma tequisicdo, onde identifica os bens em questo (com base a consulta de uma lista anteriormente disponibilizada a todos os funcionétios), a qual envia para o seu director, Este, depois de analisar o pedido, pode ou nao autorizar o mesmo. Neste segundo caso, © requisitante recebe uma notificacio, e o proceso para. No caso do pedido ser aprovado, o requisitante preenche uma encomenda que envia para 0 fornecedor por ele seleccionado. A entrada dos bens ocorre sempre no armazém, onde é confetido o material recebido com a guia de remessa que 0 acompanha, bem como a(s) encomenda(s) que Ihe deram origem (uma encomenda pode ser satisfeita de varias vezes). Apés a iltima entrega, que completa a encomenda, a empresa confere a factura que entretanto Ihe foi sido enviada, relaciona-a com as encomendas respectivas, e se tudo estiver correcto, é emitido um meio de pagamento ao fornecedor (poder ser em cheque ou por transferéncia bancatia). No enunciado anterior encontram-se destacados os processos de negdcio referidos, Este conceito de processo de negécio é, notmalmente, o mais relevante no caso das metodologias estruturadas: os processos sio os primeiros a ser identificados ¢ conduzem toda a andlise ¢ especificagio postetior.CAPITULO 3— EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 65 or 3.4.3 Técnicas e Notagdes mais Utilizadas ‘As metodologias estruturadas propuseram diversos tipos de notacdes, sendo de destacar as seguintes representacdes grificas € niio-grificas: Diagramas de fluxo de dados (data flav diagram): sio especificagées orienta- das 208 processos, em que se identificam graficamente processos, entidades externas, fluxos de informacdo ¢ reposit6rios de dados. So os principais dia- gramas utilizados na modelagio de processos. Estes diagramas podem ser construidos em varios niveis, uma vez que existe a possibilidade de especificar um processo através de um diagrama de maior detalhe. O diagrama de fluxo de dados de primeito nivel é nalgumas metodologias designado por diagrama de contexto, Diagramas entidade associagao (entity relationship diagram): so especificacbes gréficas que representam as relacdes estaticas de um sistema, designadamente as entidades, com os seus atributos, ¢ a forma como estas se encontram asso- ciadas. Diagrama de transigao de estados (state transition diagram): € uma representa- io grafica dos estados em que um sistema ou uma entidade se pode encontrar ao longo da sua existéncia, ¢ dos eventos que desencadeiam as transigdes entre estados. Diagrama do ciclo de vida de entidade (en/ity le qe): consiste numa versio adaptada de um diagrama de estados, em que 0 objectivo ¢ descrever a evolu- io de uma entidade ao longo da sua existéncia, designadamente as operagdes de criagao, alteragdes significativas ¢ climinagao do. sistema. Dicionacios de dados: sfio repositérios de definigdes de todos os elementos € conceitos utilizados e manipulados pela organizagio e respectivos sistemas de informaco e que incluem entre outros os dados, ficheiros, processos ¢ entida- des. Matrizes entidade-processo; so matrizes que demonstram as relagdes exis- tentes entre as entidades ¢ os processos, isto 6, permitem identificar que enti- dades intervém em que processos. Fluxogramas: diagramas que expressam os passos de execugio de algoritmos € processamentos realizados no sistema, B ainda de referir a técnica da Normalizagio, que consiste num processo de construgio do esquema de uma base de dados a partir da lista de entidades e dos nd oY a GF respectivos atributos, aplicando um conjunto de regras designadas por formas normais do modelo relacional, cuja preocupacio é climinar redundancias na66 CENTRO ATLANTICO — UML, METODOLOGIAS FERRAMENTAS CASE ~ VoL. | estrutura de dados ¢ garantir a integridade da infotmacao. Para mais detalhe aconselhamos 0 leitor interessado a consultar [Silberschatz98]. © clevado niimero de metodologias disponiveis no mercado fez com que a simbologia utilizada variasse normalmente conforme a metodologia adoptada. Por exemplo, na Figura 3.4 podemos obsetvar como o mesmo conceito “processo” é reptesentado por simbolos grificos distintos, conforme as metodologias de Yourdon e SSADM. Figura 3.4: “Processo” representado diferentemente segundo as notaries de Yourdon ¢ SSADM. A Figura 3.5 ilustra como o emunciado da gestio de compras pode set representado através de um diagrama de fluxo de dados segundo a notagio de Yourdon. Nele podemos observar os processos (representados por ovais), as enti- dades intetvenientes (rectiingulos), os repositérios de dados (rectingulos abertos lateralmente) ¢ os fluxos de informacio (sctas). informacéo Repositério de dados rls Pagamento Figura 3.5: Diagrama de fluxo de dados do problema de gestio de compras.CaPiTULo 3—EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 67 Na figura anterior, poderiamos representar alguns processos com um nivel de detalhe superior, ¢ pata isso jé dispomos de informacao no enunciado. Por ico (1.1), 0 respective detalhe poderia incluir, e por esta ordem, a detec¢io da necessidade, a consulta & lista de exemplo, no caso do proceso registo da req bens disponiveis, © preenchimento da requisicio, e o envio para o director. Esta informagio seria também adequadamente representada por um diagrama de fluxo de dados, de nivel mais detalhado. Outro tipo de diagrama muito utilizado na literatura é 0 diagrama entidade associagao (entity relationship diagram), que apresenta a visio estitica do sistema, identificando as entidades sobre as quais interessa guardar informagio, bem como © respectivo relacionamento. Na Figura 3.6 apresentamos 0 que poderia ser um diagtama deste tipo para o caso do problema da gestao de compras. Qualquer teligio expressa num diagrama entidade associago pode ser sempre analisada na perspectiva de ambas as entidades intervenientes, ¢ implica a sua caracterizagio segundo dois conceitos adicionais: a cardinalidade (niimero maximo de ocorréncias de cada uma na relagio) ¢ modularidade (nimeto minimo de ocorréncias de cada uma, o que nos permite identificar quais sio obrigatérias ou opcionais). Por exemplo, na relacdo entre “requisigGes” e “encomendas” do exemplo anterior, a cardinalidade desta relagao, representada pelos simbolos mais proximos de cada rectingulo, lé-se “uma requisicio pode set satisfeita por varias encomendas”; a modularidade pode set lida “podemos ter uma requisi¢io que nao dé origem a nenhuma encomenda” (€ 0 caso em que 0 director nao aprova o pedido). | Empregado it] Requisicaéo - Encomenda S{————}1] Factura Legenda | 2 paticipacde de entidase na relagdo ¢ opcionel 4. epertcnacto da eniade naréacto 6 otigatna a 9 numero de ecorréncias da entidade na ralacao pode ser superior @ 1 Pagamento Signitica que um pagamento pode ser feito por cheque ou por transferéncia ; Cheque ‘Transferencia Figura 3.6: Diagrama entidade associagao para o exemplo da gestao de compras.68 CENTRO ATLANTICO— UML, METODOLOGIAS & FERRAMENTAS CASE — Vol. | Estes diagtamas melhoraram o tigor da especificacio, uma vez que foram definidas algumas regras as quais € necessitio obedecer na sua claboracio. Adicionalmente, a representagio grafica dos conceitos facilitou a sua compreensao por todos os intevenientes no processo (utilizadores ¢ informéticos). No entanto, continuam a aptesentar algum grau de subjectividade, até porque normalmente prevéem a utilizacio de descrigdes em linguagem natural para complementar a modelagio efectuada. Além disto, a utilizagao de alguns termos ¢ simbolos j muito proximos da tecnologia dificultou por vezes a compreensio dos diagramas por parte de participantes nao técnicos. Os diagramas até agora apresentados inchiem-se no grupo das notagdes semi- formais, uma vez que tinham um conjunto de regras associadas, e que deviam ser aplicadas na sua elaboracio. No entanto, nio era possivel através destes diagramas garantir ¢ demonsttar a correccio, face as funcionalidades identificadas. No sentido de resolver este tipo de problema, foram propostas notagdes formais, que se caracterizam por adoptar conceitos muito proximos da matematica, com o rigor ¢ formalismo correspondentes, sendo deste modo possivel demonstrat a correcgao da especificagio, o que é relevante num mimero restrito, mas importante, de dominios de aplicagio como seja a medicina, industria militar ou a acrondutica. Algumas notacdes mais conhecidas so: * Redes de Petri: diagramas particularmente adequados para a representagio de sistemas com problemas de concorréncia € com restricGes a nivel de sincroni- zacio; utiliza conceitos como transicdes, funcées de input ¢ de output [Leveson87]. = Linguagem Z: linguagem de especificagdo formal, com simbologia € concei- tos matemiticos e légica de primeira ordem (conjuntos, tipos de dados, cons- tantes, definigdes de estado, estado i icial, operacdes) [Spivey88}. Sai fora do aimbito deste livro aprofundar a aplicagio das técnicas teferidas. Para o leitor mais interessado aconselhamos a leitura da bibliografia tecomendada, 3.4.4 Principais Metodologias Foi referido no Capitulo 2 que o nimero de metodologias propostas para 0 desenvolvimento de software atingiu um niimero demasiado clevado, 0 que torna virtmalmente impossivel a sua apresentagio em qualquer livro. Por isso, enumeramos de seguida algumas das metodologias estruturadas que maior relevincia ¢ divulgacio tiveram. Para além destas, existiram outros contributos importantes que no incluimos aqui por nfo apresentarem uma_perspectiva integrada de todo o processo de desenvolvimento, mas apenas sugerirem notagdesCaPiTULO 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 69 ou técnicas de modelacio. E 0 caso, por exemplo, das propostas de Tom DeMarco [DeMarco78] e de Meiler Page-Jones [Page-Jones80]. SSADM A metodologia mais largamente divulgada e adoptada foi o SSADM (Structured Systems Analysis and Design Methodology), proposta em 1981 por Learmonth, alvo de sucessivas revis Ges, a ultima das quais em meados da década de 90, com o aparecimento da versio 4+ [Weaver98]. Durante muito tempo (¢ ainda hoje) foi considerada a metodologia de referéncia e ensinada em diversos cursos universita- tios. No Reino Unido, foi durante muito tempo obrigatéria a sua utilizacio em todos os projectos relacionados com o desenvolvimento de sistemas de informa- fo a nivel governamental. © SSADM propde a modelagio de um sistema segundo trés_perspectivas complementares: (1) a sua funcionalidade; (2) a sua estrutura; ¢ (3) a sua evolugio ao longo do tempo. A primeira é representada através de diagramas de fluxo de dados (DFID), a segunda é obtida através de diagramas de entidade associacio (DEA) e a terceira pelos diagramas de ciclos de vida de entidades. Estas trés visGes so integradas; por exemplo, os DED sio comparados com os DEA, de forma a garantir que cada entidade referida num DBA é criada por algum proceso representado num DED. E uma metodologia concebida sobretudo para a andlise e desenho do sistema, nao contemplando as tarefas relacionadas com a implementagio, testes e instalagao do mesmo. Integra diversas notagdes orientadas quer para a modelacao dos processos quer dos dados. A sequéncia de actividades envolve: = A tealizacio de um estudo de viabilidade, de modo a avaliar até que ponto o sistema tem custos aceitaveis. = A anilise de requisitos do negécio. = A especificagio dos mesmos requisitos. = A especificagao légica do sistema, de modo a determinar a forma como os requisitos identificados sio implementados. =O desenho fisico do sistema. Para o leitor mais interessado aconselhamos uma leitura da referéncia anterior- mente indicada.70 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | STRADIS Stradis (Structured analysis, design and implementation of information systems) foi uma metodologia desenvolvida por Gane e Sarson em finais da década de 70 [Gane82], baseada na filosofia de decomposigio funcional ip-down, e € suportada essencialmente pela utilizacio de diagramas de fluxos de dados. Yourdon Systems Method Yourdon Systems Method, € uma metodologia proposta por Edward Yourdon, revista em 1993 ¢ descrita com algumas actualizacdes em [Yourdon99]; é semelhante a Stradis pois recorre muito 4 decomposicio funcional, mas também atribui uma importincia significativa 4 estrutura dos dados. Engenharia de Informagao A “Engenharia de Informagao”, proposta pot James Martin em 1989 [Martin89], integra muitos dos conceitos, melhores priticas, modelos e técnicas das metodologias estruturadas ¢ do desenvolvimento de software dos anos 80 numa abordagem coerente que envolve vatias actividades do processo de desenvolvi- mento de software. As suas raizes estiio no trabalho originalmente desenvolvido pela IBM na sua metodologia Business Systems Planning. ‘Ao conttétio das outras, a Engenharia da Informagio tem uma preocupacio estratégica com a definigio dos sistemas de informagio, 0 que & expresso nos diferentes estigios de evolucio do processo, designadamente: (1) planeamento es- tratégico dos sistemas de informagio; (2) anilise de areas do negécio; (3) desenbo de sistemas ¢ (4) implementagio. 3.5 Metodologias Orientadas por Objectos As técnicas e metodologias estruturadas descritas na seccio anterior apresentaram varios problemas, entre os quais podemos destacar: = iio conseguem lidar adequadamente com o problema da complexidade € do tamanho crescente dos sistemas. "Nao resolvem o problema da crescente actividade de manutencio do software. * Vetifica-se com frequéncia a ma compteensio dos requisitos do utilizador, por parte dos intervenientes técnicos. = Permanece a dificuldade de lidar com alteragées aos requisitos. = A integragio e reutilizacio de médulos e componentes do sistema nao é facil.‘CapiTuLo 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 71 = Os erros de concepsio sio descobertos tardiamente. "A qualidade do software € baixa ¢ 0 seu desempenho inadequado. = Nao ¢ facil identificar quem fez. o qué, quando e porqué. A aplicagio de diversas das melhores praticas actuais de engenbaria de software (ver Seccio 2.4) veio solucionar algumas destas questdes ¢ esteve na origem do conceito da orientacio por objectos. No entanto, é importante reforcar a ideia de que em muitos casos essas melhores praticas podem ser seguidas independente- mente de se utilizarem métodos estruturados ou orientados pot objectos. A orientagio por objectos, se bem que em tetmos priticos tenha sido primeiramente concretizada ao nivel das linguagens de programagio, nio tem impacto apenas a esse nivel. O conceito da ofientagio por objectos (OO ou O- O, do inglés object-oriented) baseia-se de facto numa nova forma de analisar o mundo. A abordagem seguida “reproduz” a forma como o set humano se apercebe ¢ expressa a realidade que o rodeia. Ele classifica ¢ subdivide 0 mundo em diferentes objectos, com base nas diferencas ¢ semelhangas existentes ao nivel das caracteristicas e comportamento dos mesmos objectos. As técnicas orientadas por objectos identificam ¢ definem cada objecto de modo a reutilizé-lo, da mesma forma que 0 ser humano acumula conhecimento com base no previamente adquitido. Nas abordagens orientadas por objectos, a perspectiva de modelagio dos sistemas muda, uma vez que 0 mesmo conceito base é utilizado a0 longo de todas as fases do processo, promovendo a reutilizagio ¢ o encapsulamento da informagio, ¢ facilitando a manutencio. As metodologias orientadas por objectos so por isso encaradas como uma das mais recentes propostas para resolver os problemas do desenvolvimento de software, uma vez que sio abordagens mais naturais que as baseadas em processos e dados, e 0s conceitos basicos so simples e reproduzem o mundo real. A definigio exacta do que se entende por orientagio por objectos tem motivado lnrgas discusses ao longo das titimas duas décadas, ¢ recomendamos a leitura de algumas referencias ({Betard93], [Taylor90], [Stroustrup88] ¢ [Booch86]) para um melhor esclarecimento sobre este assunto. No entanto, pensamos que uma das vis6es mais simplificadas até hoje apresentada, e que expressa adequadamente o conceito foi elaborada por Coad ¢ Yourdon em 1991 [Coad91}, ao indicar que o patadigma da otientacdo por objectos resulta da convergéncia de quatro outros conceitos, que serio definides em seccdes mais a frente: objectos, classificagio, heranga ¢ comunicacao por mensagens.72 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | 3.5.1 Contexto e Motivacao As raizes da engenharia de software orientada por objectos podem ser encontradas no trabalho inicialmente desenvolvido na linguagem Simula [BirtWhistle79] em finais dos anos 60, que como o nome indica, estava particularmente vocacionada para a implementacdo de sistemas de simulacao. Desde 0 inicio dos anos 70 que trés ideias independentes ganharam importancia, com 0 objectivo de facilitar todo © processo de desenvolvimento de software, € que em iiltima anélise esto na base da estrurura de conccitos do paradigma da otientago por objectos, Estamos a referir-nos aos conceitos de encapsulamento de informagio, de reutilizacio de cédigo ¢ da visio do mundo (¢ posterior modelacio) segundo um conjunto de objectos, ¢ nio segundo uma perspectiva funcional. Estes conceitos est3o na base da primeira linguagem classificada como verdadeiramente suportando este paradigma, a linguagem Smalltalk [Goldberg89], ios PARC da Xerox, Até meados da década de 80, a maioria das iniciativas relacionadas com o paradigma da orientacio por objectos concebida nos laborati situava-se ao nivel da programagio. ‘Tal como descrito no seu livro “Object-Oriented Analysis” [Coad91], Peter Coad ¢ Edward Yourdon identificam as motivagdes principais para a realizagio de actividades de anélise segundo o paradigma da otientagio por objectos: = Poder tratar dominios de problemas mais complexos. " _ Melhorar a interacco entre o analista ¢ especialista do problema. = Aumentar a consisténcia interna dos resultados da anilise. " Representar explicitamente aspectos comuns a diversos conceitos. " Construir especificacdes capazes de resistir a mudanga. = Reutilizar resultados da andlise. * Conceber uma representagio consistente para a anélise e desenho. 3.5.2 Conceitos Basicos As abordagens orientadas por objectos so muito ricas em termos da terminologia utilizada. Podemos distinguir essencialmente dois grandes grupos de conceitos: (1) os principios, que constituem um conjunto de ideias base de todo 0 patadigma, e alguns deles sio mesmo os requisitos necessirios para um sistema ser considerado orientado por objectos; (2) ¢ as restantes nogées base, comuns a todos os sistemas orientados por objectos.Lt CapiTULO 3 — EVOLUCAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 73 Principios Orientadores do Paradigma No grupo dos principios orientadores e que definem o paradigma podemos incluir ‘os seguintes conceitos: Encapsulamento da informagio é o proceso de “esconder” os detalhes de um objecto que no contribuem para as suas caracteristicas essenciais nem para a disponibilizacdo de funcionalidades para © seu exterior. Pode ainda ser encarado como a localizagao de funcionalidades numa tinica abstraccio auto- contida, que esconde a respectiva implementacao e decisdes de desenho, atra- vés da disponibilizagao de uma interface publica. O conjunto de operagdes que sio acessiveis do exterior constitu a interface do objecto. Esta catacteristica permite a criacio de objectos estiveis ¢ reutilizéveis, reproduzindo o mundo real de forma correcta. { Heranga representa a definicao de relagées entre classes através da qual uma subclasse partilha, acrescenta ou redefine operagdes e atributos a partit de uma ‘ou mais superclasses; uma subclasse é uma especializagio de uma ou mais superclasses. I. uma forma de aumentar a reutilizaco do que é comum, per- mitindo adicionalmente acrescentar detalhes especificos. Este termo aparece associado as nocées de generalizacio e de especializagao. Polimorfismo é a capacidade de “esconder” varias implementagGes distintas através de uma tinica interface. Outra forma de definir esta propriedade é dizer que ela representa a capacidade de objectos diferentes responderem de forma diferente 4 mesma mensagem. ‘Tal é concretizado pelo facto de uma operagio aceitar argumentos de tipos diferentes ou mesmo desconhecidos. E utilizada em situacdes em que uma operacio é partilhada na maior parte dos casos, mas em que pelo menos uma subclasse necessita de uma versio especifica. Abstracgao é a representagio concisa de um objecto ou ideia mais complexa, incidindo sobre as caracteristicas essenciais do objecto. As abordagens tradi- cionais conctetizam esta ideia pelas abstraccdes funcionais (processos), enquanto os métodos orientados por objectos utilizam objectos. Os quatro principios anteriores so considetados necessitios € suficientes para considerar uma linguagem como sendo orientada por objectos (OO); aquelas que no suportam as nogées de heranca ¢/ou polimorfismo sio normalmente desig- nadas pot baseadas em objectos. Para além destes, existe ainda outras nogdes importantes: Modularidade € 2 decomposicio ldgica € fisica de conceitos em unidades mais clementares, de forma a facilitar a aplicacao dos principios da engenharia de software. Concorréncia é a propriedade que distingue um objecto activo de outro niio activo.Conceito Conceito 74 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE ~ VOL. | = Persisténcia é a propriedade de um objecto através da qual a sua existéncia perdura no tempo ¢/ou no espago. Outros Conceitos Chave do Paradigma da Orientagao por Objectos Para além dos principios que funcionam como as grandes linhas orientadoras do paradigma da orientag’o por objectos, existem outros conceitos que sio fundamentais para a boa compreenstio do mesmo, nomeadamente 0s cosiceitos de objecto e class , pata além de outros que estio directamente relacionados com estes. © conceito basico é obviamente 0 de objecto, para o qual nio existe uma definigdo tinica. Pelo contrério, praticamente cada metodologia e respective autor apresentam definicdes préprias, como se pode observar de seguida: = Firesmith [Firesmith96]: um objecto pode ser definido como uma abstraccao de software que modela todos os aspectos relevantes de uma tinica entidade conceptual ou tangivel, que pertence ao dominio da solucio. = Object Management Group (htip:/ /mum.omgorg): um objecto é uma coisa, criada como uma instancia de um tipo de objectos. Cada objecto tem uma identidade nica distinta ¢ independente de quaisquer das suas caracteristicas. Cada objecto tem uma ou mais operagdes. = Booch [Booch94}: algo ao qual se pode fazer qualquer coisa; tem estado, com- portamento ¢ identidade. = Berard [Berard93]: objectos so as entidades reais ou conceptuais que podem ser encontradas no mundo que nos rodeia. * Coad € Yourdon [Coad91]: uma abstraccio de qualquer coisa no dominio de um problema, reflectindo a capacidade do sistema de manter informacio sobre cle ¢ de interagir com ele; é um encapsulamento de valores de atributos ¢ dos seus servigos exclusivos. * Rumbaugh [Rumbaugh91]: um objecto é um conceito, abstraccio ou coisa com fronteiras bem definidas ¢ com significado para o problema em questio; promove a reutilizacZo ¢ funciona como uma base conereta para a respectiva implementac&o em software. "= Shlaer ¢ Mellor [Shlaer88]; um objecto é uma abstraccio de um conjunto de coisas do mundo real de tal forma que todos os elementos do conjunto (ins- tancias) tém as mesmas caracteristicas ¢ respeitam as mesmas regras e politicas. Resumidamente, e de forma a integrar estas diversas definigdes, podemos dizer que um objecto representa uma entidade fisica, conceptual ou apenas necessdtia para a representagdo em computador (por exemplo, estruturas deConceito Conceito Conceito CapituLo 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 75 dados); um objecto pode ser um conceito, uma abstraccio ou uma entidade, com fronteiras bem definidas e que tem um significado no contexto de um problema ¢ respectiva solugio; um objecto tem estado, comportamento e identidade. Alguns autores enumeram as fontes onde pesquisar os possiveis candidatos a objectos, independentemente do problema a solucionar: = Shlaer ¢ Mellor propdem como origem de objectos, as entidades e coisas tangf- veis, fungdes de pessoas, organizacées, incidentes, eventos, interacsdes, especi- ficagies, = Coad ¢ Yourdon defendem que os objectos representam estruturas, outros sistemas, dispositivos, coisas ou acontecimentos memorizados, fungdes desempenhadas, procedimentos operacionais, locais geograficos, unidades organizacionais. Os atributos sio propriedades nomeadas de um objecto que indicam os valores possiveis que esse atributo pode assumir ao longo do tempo; o estado de um objecto € definido pelo valor dos seus atributos, © comportamento de um objecto é definido como 0 conjunto de acgdes que um objecto pode realizar de forma independente. Normalmente existem dois termos para referir os mecanismos utilizados pata implementar este conceito: ao nivel da andlise os tetmos mais utilizados 10 0 de operagao ou servigo, enquanto 0 termo método se tefere normalmente a implementacdo de uma operago a0 nivel da progtamacio. A maioria das operagdes realizadas responde a perguntas ou alteram 0 estado do objecto. Na pritica, implementam um servico ¢/ou funcionalidade que pode set requerido por qualquer objecto que faca parte do universo do problema. Para melhor compreendermos os conceitos de estado ¢ de comportamento, utilizemos 0 exemplo de uma conta bancétia, Neste caso, 0 seu estado é determinado pelos valores assumidos pelos atributos que sio necessirios para a Pe q caracterizar - titular, saldo - enquanto que o scu comportamento é determinado pelos servicos que disponibiliza para outros objectos interagirem com cla, nomeadamente depositar dinheiro, levantar dinheiro e consultar o saldo da conta. As classes sio desctigées de grupos de objectos com propriedades (atributos), comportamento (operacées) e relagdes comuns. E uma das concretizagées do conceito abstrac¢ao no paradigma da orientagao por objectos. Uma classe pode ser vista como template para um determinado objecto € todos os que lhe sio semelhantes, ou como uma fabrica, que produz tantos objectos idénticos quanto necessitio.76 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | Em geral, os attibutos petmitem identificar a classe, definir as caracteristicas especiais da classe, definir 0 estado da classe, reter alguma informacio sobre a classe e identificar 0 comportamento do objecto. Para especificar detalhadamente um atributo deve-se identificar 0 dominio dos seus valores, as unidades de medida, © valor por omissio, o valor inicial, as condigGes de leitura ¢ escrita ¢ eventuais condigées relacionadas com outros atributos do objecto ou da classe. Dado um enunciado de um problema, a anilise orientada por objectos procura identificar os objectos concretos € as respectivas classes, a partir de todos os substantivos que dele sejam extraidos. O seu objectivo tltimo seré sempre identificar: = Um conjunto de classes que representem totalmente o dominio do problema. + Osatributos de cada classe. "A interface e os servicos de cada classe. = As diversas relacdes entre classes. * — Objectos concretos que seja necessario particularizar. Cada metodologia propée diferentes formas de chegat a esta informacio, e normalmente referem alguns critérios, Por exemplo, [Coad91] indica um conjunto de questdes a colocar, de modo a averiguar se um substantivo do enunciado constitui um objecto ou classe: * A informacio sobre 0 objecto tem que ser retida de modo a que o sistema fun- cione adequadamente? = O objecto realiza operagGes que alteram atributos de outros objectos? * O objecto tem mais do que um atributo? = Outros objectos aparentemente idénticos disponibilizam operagdes idénticas? * 0 objecto produz ou consome informagio essencial para o funcionamento do sistema? Noutras situagées, sio indicadas checklists de circunsténcias em que um potencial objecto no 0 deve ser, por exemplo: * - Objectos ou classes com apenas um atributo. "Classes com apenas um objecto. Objectos ou classes sem servicos apliciveis, ou que nfo produzem um resul- tado visivel para o problema em anilise. Objectos ou classes que nao sejam relevantes para a solugio do problema. Objectos ou classes que de facto correspondem a atributos de outros objectos.CapiTULO 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 77 Se considerarmos novamente o enunciado do exemplo da gestio de compras, podemos verificar que a nossa pesquisa passa a incidir sobre outras palavras (substantivos em vez de verbos), devido 4 mudanga de paradigma e aos conceitos base fundamentais que lhes esto subjacentes (objectos em vez de processos). Exemplo 3.2: Descrigéo do problema da gestao de compras (pers- pectiva orientada por objectos). Pensemos no caso da gestio de compras de matetiais de uma empresa. Sempre que algum funciondrio tem necessidade de comprar bens para as suas actividades, este preenche uma requisicio onde identifica os bens em questio (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionarios), a qual envia para 0 seu director. Este, depois de analisar 0 pedido, pode ou niio autorizar o mesmo. Neste segundo caso, 0 requisitante recebe uma notificacio, ¢ 0 processo para. No caso do pedido ser aprovado, o requisitante preenche uma encomenda que envia para o fornecedor por ele seleccionado. A entrada dos bens ocorre sempre no armazém, onde é conferido o material recebido com a guia de remessa que o acompanha, bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser s isfeita de varias vezes). Apés a Uiltima entrega, que completa a encomenda, a empresa confere a factura que entretanto lhe foi enviada, relaciona-a com as encomendas respectivas, ¢ se tudo estiver correcto, é emitido um meio de pagamento ao fornecedor (podera ser em cheque ou por transferéncia bancéria). As operagées realizadas por objectos podem ser identificadas pela pesquisa no enunciado do problema de verbos associados a cada objecto. Essas operagdes podem ser agrupadas nas seguintes categorias: * Modificadores: operacio que altera 0 estado de um objecto. * Sclectores: operaciio que acede ao estado de um objecto. " Tteradores: operagio que permite que todas as partes de um objecto sejam acedidas segundo uma ordem bem definida. * Constrator: cria um objecto ¢/ou inicializa 0 seu estado. = Destrutor: liberta o estado de um objecto ou destréi-o Qs objectos funcionam como caixas negras, porque “escondem” os detalhes da sua implementagio aos objectos que a utilizam; o acesso aos objectos é efectuado através da interface por eles disponibilizada, composta por operagdes ¢ por78 CENTRO ATLANTICO — UML, METODOLOGIAS £ FERRAMENTAS CASE - VoL. | attibutos. Os objectos comunicam entre si por mensagens, que no sio mais do que a invocagio de um método com o mesmo nome, no contexto do objecto receptor da mensagem. Mensagern X todo X Resposta Objecto A Objecto B Figura 3.7: Modelo de comumicagito entre objectas por mensagens. Na ‘pritica, este modelo traduz-se na invocagio de uma fungio, tal como nas abordagens tradicionais; a diferenca é que esta invocagio é realizada no contexto de um objecto, 0 que significa que tem em conta o seu estado, representado pelos valores que os seus atributos assumem. Por isso, o mesmo método executado com os mesmos parimetros sobre objectos diferentes, mas ambos instincias da mesma classe, pode produzit resultados diferentes, como se verifica no exemplo seguinte. Exemplo 3.3: Invocagéo do mesmo método no contexto de objec- tos diferentes. Classe classeA { public: int x; int y; int soma() { return (x + y ) 7} classeA a; classeA b; 10 20; BG a.x ay b. x buy =.8); a.soma => obtem-se o valor 30 b.soma => obtem-se o valor 13CapiTuLo 3— EvoLugAo DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 79 Fiste conceito de comunicagio por mensagens pode ser visto de forma tio abstracta que mesmo a soma de dois niimeros pode ser encarada como uma operagao de envio de uma mensagem a um objecto. Por exemplo na operacio 3 + 4, 3 & 0 objecto receptor da mensagem, que € formada pelo selector + (que identifica 0 método a invocat no objecto receptor) € pelo objecto argumento 4, Uma mensagem é sempre formada por um selector ¢ opcionalmente por um conjunto de parametros. ‘A interface é 0 conjunto de operagdes ¢ atributos disponibilizados pot uma classe, que consoante a visibilidade se pode dividir em trés partes: péblica (visivel para todos os objectos do sistema); protegida (s6 visivel pelos objectos pertencentes ais snas subclasses); privada (faz parte da interface mas no é visivel para nenhuma Conceito outra classe do sistema, sé esta disponivel na implementagio da propria classe). Sai et eee eel Classe Conta private metodocontat protected metodoconta20. | ‘Troca de mensagens public metocloconta30) Relacdo de heranca Pode aceder ao metodocontas Classe Conta Particular public metodeparticular’ 10 as private metodoparticular22 () public metodoconta3Q) protected metodoconta2() Figura 3.8: Visibilidade de métodos da interface. Entre as diversas classes de um sistema podem ser estabelecidas diferentes tipos de relagde! * Associagao: representam telagdes estruturaisentre objectos de classes diferen- tes, € cuja informacio tem que ser preservada durante algum tempo; nas situa- es em que apresenta uma semintica expressa pelo verbo ter; podem-se sub- dividir em: = Agregagao: é a conhecida relacio entre o todo € as partes (whole-parf); um exemplo possivel é a relacao “uma empresa tem empregados”.80 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | — Composigao: forma de agregacao em que a relagiio de pertenca é forte e com tempos coincidentes; o objecto agregador € responsével pela eriacao © destrui¢io do objecto que entra na sua composicio; “o corpo humano tem uma pera” é uma expresso que concretiza esta relacio. = Dependénci: relaco em que uma mudanga de estado num objecto (ocorrida pela recepedo de uma mensagem) pode implicar 0 envio de uma mensagem a outro objecto; por exemplo, um automével, para andar, precisa de se abastecer na bomba de gasolina. * Generalizagao/Especializagao: relagdes entre classes que partilham a estru- tura € comportamento; implementam 0 conceito de heranca, que pode ser simples (uma classe tem apenas uma superclasse) ou miltipla (ama classe pode ter varias superclasses); esta relacio é expressa pelo verbo ser, como no caso “um cio € um animal”. Algumas abordagens orientadas por objectos procuram defini conceitos que permitem agrupar classes; por exemplo, Wirfs-Brock considerou que um sub- sistema é um conjunto de classes (ou de outros sub-sistemas) que colaboram entre si para realizar um conjunto de responsabilidades. Nao existem na pritica, mas permitem a criacio de entidades conceptuais titeis. Coad ¢ Yourdon definem o conceito dé assunto (subjec) de forma idéntica. No caso do UML, utiliza-se 0 conceito de pacote com um fim idéntico. O principal objectivo deste tipo de conceitos € facilitar a compreensio da globalidade do sistema, ao agrupar outros conceitos relacionados. 3.5.3 Técnicas e Notagdes mais Utilizadas A proliferagio das metodologias que tinharh como base os conceitos da orientagio por objectos levou ao aparecimento de diversas notacées ¢ técnicas de modelacio, que muitas vezes sio partilhadas entre varias delas, Os recentes esforgos de unificagao permitiram que algumas dessas técnicas se tenham destacado. As principais notagdes utilizadas estado praticamente todas presentes na linguagem de modelagio UML, pelo que serio apresentadas detalhadamente nos capitulos que constituem a Parte 2 deste livro. Resumidamente, indicamos de seguida as principais notacdes a considerar: = Diagrama de casos de utilizagao "= Diagrama de classes * CRC (Class-Relationship-Collaboration) cards = Diagtama de pacotesCarituLo 3 EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 81 = Diagrama de estados = Diagramas de interacgao = Diagrama de actividade * Diagrama de eventos * Diagrama de contexto * Diagrama de fluxo de dados. Independentemente dos nomes dos diagramas utilizados por cada metodologia, cada uma apresenta notagdes para modelar a visio estitica do sistema (a estrutura dos objectos, relagdes de agregago e de especializacio, ¢ a comunicagio entre objectos) € outras notagdes para os conceitos dindmicos (interacgdes, mudangas de estado, sequéncias de acces e mecanismos de temporizacio). 3.5.4 Principais Metodologias ‘Ao longo das décadas de 1980 e de 1990 surgiram intimeras propostas de metodologias, sobretudo concentradas nas tarefas de anélise e desenho, utilizando os conceitos relacionados com o paradigma da orientagio por objectos. Sem pretendermos ser exaustivos, enumeramos de seguida algumas das metodologias mais significativas, quer pela sua utilizago, quer pela televancia dos conceitos abordados. Método de Booch O método Booch [Booch94], proposto originalmente pot Grady Booch em 1991, baseia-se na ideia da repetigao de actividades de um processo de desenvolvimento de modo a refinar © modelo em sucessivas iterages. As suas principais actividades estio orientadas para a identificagio de classes € objectos @ respectivas caracteristicas e para a determinagio das relagdes entre classes. OMT (Object Modelling Technique) O OMT foi proposto por James Rumbaugh em 1991 [Rumbaugh91], ¢ concentrou as suas propostas na anilise ¢ desenho de software, as quais aplicou técnicas orientadas por objectos. A sua metodologia apresentava essencialmente trés mode- los principais: estatico ou de objectos (onde se representavam classes, objectos, a hierarquia ¢ outras telagdes), dinimico (apresentava 0 comportamento dos objectos e do sistema global) ¢ funcional (diagrama de fluxo de informacio no sistema semelhante aos diagramas de fluxos de dados).82 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE - Vol. | OOSE (Object Oriented Software Engineering) © OOSE foi proposto por Ivar Jacobson em 1992 [Jacobson92], resulta da evolugio da metodologia Odjectory (também do mesmo autor) e¢ a sua maior contribuicao foi a introdugio da nogio de caso de utilizacio que funciona como uma desctigio da interaccio entre o utilizador ¢ 0 sistema. OOAD (Object Oriented Analysis and Design) © OOAD foi proposto por Peter Coad ¢ Edward Yourdon em 1991 [Coad91] apresentava como uma das suas principais vantagens o facto de ser muito simples (ao nivel dos conceitos, actividades ¢ diagramas) 0 que 0 tornava um dos mais ficeis de compreender. As suas principais actividades relacionadas com a anilise sio no fundo aquilo que todos nés esperariamos realizar num proceso que aplicasse as nogdes da orientacio por objectos: * Identificar objectos utilizando critérios simples (substantivos). * Definir uma estrutura de relacdes generalizagao-especificagio. * Definir uma estrutura de relacdes de associagio (whole-part). * Identificar assuntos (subsistemas). * Definir os attibutos. " Definir os servicos. Método de Wirfs-Brock A metodologia de Wirfs-Brock nao efectua uma distingéo clara entre anilise € desenho, ¢ a sua principal contribuigao foi a definicio de um diagrama designado por CRC cards (Class-Responsibility-Colaboration) que procura identificar as classes do sistema, a sua interface € as relagdes entre elas. As principais actividades consistem em avaliar a especificagio do cliente; extrair classes candidatas a partir da anilise da especificagio; identificar grupos de classes (superclasses); definir atribuir responsabilidades para cada classe; identificar relagdes entre classes; identificar colaboragées entre classes com base nas tesponsabilidades; e construir representacdes hicrirquicas das classes. Para além destas-metodologias, sem diivida alguma que aquela que actualmente é mais relévante é a proposta pela Rational (e que na realidade se baseia em muitos dos conceitos aqui referidos) e que é apresentada em detalhe no volume 2. Outras que vale a pena mencionar sio a de Shlaer e Mellor [Shlacr88], a de Edward Berard [Berard93) ¢ a de James Martin [Martin92].CAPITULO 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 83 3.6 Outras Abordagens Apesar dos beneficios que se reconhecem na utilizagio de metodologias (indepen- dentemente do paradigma utilizado), clas nao esto isentas de criticas ¢ de aspectos menos positivos: = Complexidade nos conceitos, técnicas ¢ aplicagio. = Desconhecimento global da metodologia € falta de competéncias dos informa- ticos para a sua execucio com qualidade. = Ferramentas que suportam a metodologia dificeis de utilizar. " Constatagio da auséncia de melhorias significativas no processo ¢ produto final = Concentracio na andlise da situagio actual, e menor importincia aos objecti- vos futuros. = Tempo que decorre até & disponibilizagio dos resultados finais. * Rigidez na aplicaciio dos métodos e conceitos. 3.6.1 Metodologias Ageis Como teaccio a esta situagio, um novo grupo de metodologias comegou a aparecer nos tltimos anos, que implicam um nivel de formalismo muito menor. Muitas delas advogam a nio tealizagio de actividades de anilise ¢ desenho, € a ptoducio de menos documentacio por comparacio com as metodologias estruturadas ou orientadas por objectos. Defendem que a principal documentacio de um sistema é, ou deveria ser, 0 cédigo fonte das aplicacdes desenvolvidas. Comungam entre si a ideia de que as principais actividades a realizar ao longo de todo o processo de desenvolvimento sio encialmente a programacio e os testes. Estes métodos sio bastante adaptaveis, também como forma de responder ade- quadamente Aquilo que consideram ser a evolucio imprevisivel dos requisitos a0 longo do tempo. Concentram-se na satisfacdo das necessidades das pessoas (infor- miticos ¢ utilizadores) ¢ nto na definigio de processos. Partilham a ideia do desenvolvimento iterative tipico das abordagens orientadas por objectos, ¢ tefor- cam a importincia da actividade de testes. Este conjunto de ideias base comuns fez com que fossem designados por metodologias geis ou lightweight (leve ou simplificado). Sio na sua maidria desconhecidas do grande publico informatio, apesar de algumas delas ja estarem a set aplicadas ha varios anos, Algumas referéncias felevantes nesta area s abordagens XP - Fixcireme Programming [Beck99], Feature Driven Development (Coad99] © Scrum [SchwaberO4]. Por vezes, mais do que verdadeiras metodologias io. as84 CENTRO ATLANTICO— UML, METODOLOGIAS & FERRAMENTAS CASE ~ VoL. | completas de desenvolvimento de sistemas de informa: (©. propostas para melhorar partes do mesmo processo, como é 0 caso do Test Driven Development [Astels03], concentrado em priticas relacionadas com as actividades de teste. ‘Tal como referido por Fowler [Fowler00], em determinadas circunstincias estes métodos sio particularmente aconselhiveis, sobretudo se estivermos a falar de sistemas pequenos ou com requisitos incertos ou voliteis, em que os programadores sto responsaveis, experientes ¢ se encontram motivados ¢ em que 0 clientes sio igualmente participativos ¢ responsaveis, ou ainda quando a equipa de desenvolvimento & relativamente reduzida e estivel. Noutras situagdes sera preferivel um processo mais formal, nomeadamente sempre que 0 projecto exigir a alocacio de equipas de maior dimensio, ou existir um contrato com Ambito precos fixos, ou em que o risco seja elevado e 0 proceso de controlo do projecto deva ser reforgado. 3.6.2 MDA, Desenvolvimento Baseado em Modelos Recentemente, a organizacio OMG (htp://mwm.omgor), tesponsdvel pela uniformizagio do UML, propés também a norma MDA -(Arquitectura Orientada por Modelos) [Frankel03], que introduz a nogio de Model Driven Development, isto &, do desenvolvimento orientado por modelos. A ideia basica consiste em valorizar 0 papel das actividades de modelacio e dos modelos que sio construfdos em diversas fases do processo de desenvolvimento, passando estes a ser os elementos centrais de todo o processo, e garantindo a consisténcia do processo de desenvolvimento. E identificado um conjunto de técnicas ¢ de ferramentas que suportam as actividades de modelagio, independentemente de quaisquer tecnologias utilizadas na implementagio do software. A MDA é suportada fortemente pela utilizacio do UML, uma vez que se propde construir, em primeiro lugar, um modelo UML designado por PIM (Platform Independent Model, ou Modelo Independente da Plataforma), que é independente de qualquer plataforma tecnolégica, ¢ que pode posteriormente ser mapeado para modelos com especificadades relacionadas. com diferentes _plataformas tecnolégicas, designados por PSM (Plafform Specific Model, ou Modelo Especifico da Plataforma). Esta caracteristica permite perservar os investimentos da organizacio, uma vez que possibilita a mudanga da tecnologia de suporte ao negécio (representada pelo PSM), mantendo as regras € os processos de negécio (descritos pelo PIM). Outra ideia fundamental é a de que, a partir do PSM, 0 cédigo do sistema seja gerado automaticamente, Ha mesmo quem defenda que este cédigo nio deve ser perceptivel a quem esti a construir o sistema; os tinicos artefactos visiveis seriam os modelos, ficando a ideia de que nio é 0 cédigo que é executadoCAPITULO 3— EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 85 mas sim os prdprios modelos, tal como é defendido pela abordagem Executable UML [Mellor03]. Mais informagio sobre a MDA pode ser encontrada em btip:/ /wnm.omg.org/ mda. % 3.7 Comparagao de Metodologias ‘A comparagio das diversas metodologias actualmente existentes é uma tarefa complexa devido a um conjunto de dificuldades que se colocam ¢ das quais pode- mos destacar as seguintes: = Nao existem metodologias iguais e portanto em qualquer comparacio estare- mos sempre a compatar conccitos por vezes nfio compariveis. = Muitas metodologias so influenciadas ou particulatmente concebidas para serem utilizadas com linguagens de programacio especificas. io onde nao existem os * Muitas metodologias assumem um contexto de aplica problemas que no mundo real tém que enfrentar. = A abrangéncia das metodologias varia fortemente; algumas apenas descrevem um processo, outras incluem técnicas e notagdes. = A comparacio entre metodologias tem que considerar obrigatoriamente ape- nas um subconjunto das mesmas, ¢ um subconjunto de funcionalidades. "A propria definicio do conceito metodologia pode ser limitativa. Hoje em dia reconhece-se a vantagem clara do ponto de vista conceptual das abotdagens orientadas por objectos face as estruturadas, pois apresentam: = Um tinico paradigma consistente ao longo de todo o processo, mais préximo do processo cognitive humano. = Facilitam a reutilizagio nao apenas do cédigo mas também da arquitectura global do sistema, 0 que potencia o aumento de produtividade dos informati- cos. * Apresentam modelos que reflectem’mais adequadamente 0 mundo teal. = Nio existe sepatagio entre dados ¢ processos, 0 conceito unificador agrega as duas vis6es. "Os detalhes de implementacao sio escondidos do exterior pela aplicagio de técnicas de encapsulamento da informagio. = A facilidade de realizagio das tarefas de manutengao é maior, em resultado das diversas caracteristicas anteriormente enumeradas. = O sistema construido é consequentemente mais estavel,86 CENTRO ATLANTICO ~ UML, METODOLOGIAS & FERRAMENTAS CASE ~ VOL. I Estas abordagens tém contudo os seus problemas, pois reconhece-se que nem sempre € facil encontrar os objectos ¢ classes apropriados no dominio do problema, uma vez que a maioria dos informéticos continua a pensar em termos funcionais. Para além disso, s6 mais recentemente comecaram a surgit no mercado ferramentas de apoio ao process de desenvolvimento segundo o paradigma da orientacdo por objectos. Comparamos de seguida alguns aspectos concretos em como as abordagens orientadas por objectos se revelam mais adequadas que as estruturadas. 3.7.1 Gestao de Requisitos e Facilidade de Manutengao A figura 3.9 ilustra a ‘diferenca entre os paradigmas de desenvolvimento estruturado ¢ do desenvolvimento otientado por objectos. No desenvolvimento estruturado, o sistema consiste num conjunto de dados que sfio usados (em leitura ¢/ou escrita) por inimeras funcdes, de forma mais ou menos independente. O sistema corresponde a uma malha arbitraria de intimeras interdependéncias entre fungdes e dados. No desenvolvimento orientado por objectos, dados ¢ fangdes so agregados conjuntamente numa entidade logica (0 objecto) que providencia uma interface bem definida para outros objectos comunicarem com ele. O sistema cotresponde a uma malha de interdependéncias entre objectos. Frgientos de Codigo 7 ? aa al Uma ateracao nos dados pode imphicar a atterag3o_ tmpacio restric na alteragdo Oe dados @ codigo de intmeras fragmentos de cddiga. Manutengio mais facil, reutlizagio, etc. Figura 3.9: Desenvolvimento estruturado versus desenvolvimento orientado por objectos. E evidente que as abordagens orientadas por objectos facilitam significativamente a gestio das alteracdes de requisitos. Imagine- se as implicagdes que a alteragio da estrutura dos dados implica em ambas as abordagens. Na abordagem estruturada, seria necessirio adaptar consistentemente todas as fungdes que acedessem & estrutura de dados envolvida, e, na pior das situagdes, a todas as funcdes que Ges. dependessem funcionalmente dessas primeiras func Por outio lado, nas abordagens orientadas por objectos, apenas seria necessario alterar a estrutura de dados que supostamente era definida no contexto interno deCAPITULO 3 — EVOLUQAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 87 um determinado objecto. Caso essa alteragio nio implicasse a alteracio da intetface providenciada pelo objecto, nao haveria mais nada a fazer! 3.7.2 Representacao da Realidade Nas abordagens otientadas por objectos, as entidades do mundo real séo tepresentadas directamente por objectos: um carro é um objecto do tipo “carro”, uma conta bancétia é um objecto do tipo “conta bancéria”, etc. Tal como as entidades do mundo real, os objectos apresentam dados e comportamento, bem como identidade prépria. antacianicatia (Classe: hicial que descreve & also lgeneriidade cas cortas banc ates. mem Conta | 2 | ScalewarJurost) > _ oo Classes ft specializadas criadas fara suportar diferentes métdos de 5 fealcto de jus ae es ContaBancanaReguiar t “ContaBaneanaimestinenta ‘SCalcular Juros() ‘Scalcular Juros)) Figura 3.10: Especialixagio de contas bancarias na abordagem OO. Nas abordagens estruturadas, uma conta bancéria pode ser representada através de um ou mais médulos com funcées especificas que acedem a varias estruturas de dados de forma independente. Nestas abordagens, 0 foco é na definigéo do modelo de dados da conta banciria (isto é, no desenho da base de dados que suporta contas bancérias) ou, alternativamente, na definicao dos processos/ fungdes que acedem e manipulam contas bancérias. Por isso, neste tipo de abordagem, nao é facil explicitar especializagdes ou generalizagées correspondentes a conceitos inerentes a entidades do mundo real que existam ou que venham a existir. Por exemplo, nao é trivial na abordagem estruturada introduzir-se posteriormente a nogao de contas bancizias especializadas, o que é simples na abordagem orien- tada por objectos, tal como é representado na Figura 3.10.88 CENTRO ATLANTICO — UML, METODOLOGIAS & FERRAMENTAS CASE = Vol. | 3.7.3 Outros Aspectos O desenvolvimento de software segundo uma abordagem orientada por objectos aptesenta outras vantagens comparativamente com a abordagem estruturada, resu- midamente: * Providencia blocos de construgio de alto nivel que reduzem os custos de desenvolvimento, pela promocio da reutilizagio ¢ encapsulamento de soft ware. Este facto permite reduzit as interdependéncias ¢ facilitar a manutengio posterior. = Facilita a transferéncia de conhecimento através da adopgio de “padrdes de desenho”, reduzindo 0 custo de aprendizagem. * Providencia um /ramenork (aplicacional ou de middleware) para facilitar a exten- sio do sistema, reduzindo o custo de novas versdes. * Reduz o custo de alteragio do sistema, em resposta 3 expectativas € requisi- tos dos utilizadores Todavia, ¢ ainda que actualmente esta abordagem possa jf ser considerada estabe- Iecida ¢ madura, implica alguns cuidados na sua aplicacio, pelo facto de levantar algumas questdes: = Exige uma nova forma de “pensar” o proceso de desenvolvimento. = A orientacao por objectos deve ser utilizada em todas as fases do ciclo de vida do. software. Por exemplo, nao tem muito sentido usar-se uma linguagem orientada por objectos a seguir a um ciclo de anilise ¢ desenho tradicional, ou vice-versa. * A gestio da empresa ou do projecto tem de “comprar” a mudanga para a filosofia otientada por objectos, em particular tem de definir os objectivos comerciais para a mudanga. Por exemplo, redugdo dos custos de manutengio do software, = A migracio para a orientagio por objectos tem de ser devidamente planeada para garantir a sua eficacia, Apesar das vantagens sublinhadas da abordagem da orientagio por objectos no desenvolvimento de software, niio se deve concluir que esta é “sempre” mais adequada que a aproximacéo estruturada. Ha varias situagdes em que é mais correcto seguir uma metodologia estruturada. Por exemplo, se a linguagem de programacao utilizada pela organizacio for Cobol, RPG ou C ¢ o ambiente de desenvolvimento for estruturado, entio fard mais sentido aplicar metodologias estruturadas ao longo de todas as fases do projecto. Caso contratio, correr-se-ia 0 erro (€ no perigol) de se realizar uma modelaco com base em conceitos orientadosCapiTuLo 3— EVoLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 89 por objectos e depois ter de se recriar, ao nivel do desenho (ou pior, ao nivel da codificacio!) um modelo completamente distinto do primeiro. Apesar de ser natural ¢ 6bvio que é mais consistente a utilizagio do mesmo paradigma ao longo de todo o ciclo, do ponto de vista tedrico nada impede que se utilizem métodos de anilise estruturada, seguidos de uma implementacio numa linguagem orientada por objectos; o inverso pode também acontecer, isto é, a utilizacio de uma lin- guagem tradicional na sequéncia de uma andlise orientada por objectos. 3.8 Conclusao Este capitulo conclui a primeira parte do livro, na qual se deu uma visio dos problemas da Engenharia de Software (Capitulo 1), a definigio de conceitos € abordagens genéticas a0 desenvolvimento de software (Capitulo 2) e uma visio resumida do caminho que foi seguido até A data em termos de evolugio dos conceitos e das metodologias priticas (Capitulo 3). Neste tltimo capitulo procurémos transmitir a ideia de que as abordagens orientadas por objectos apresentam vantagens significativas, mas que a proliferagio de notagdes e metodologias, bem como o conhecimento especializado que é necessario para aplicar com sucesso esta nova forma de encarar ¢ modelar o mundo exterior, colocam desafios significativos constituem problemas importantes que sao necessarios controlar. E precisamente com esse objectivo que o resto do livro se concentra na linguagem de modelacio UML, € nos processos de desenvolvimento a ela associados, quer porque esta é de facto uma iniciativa unificadora ao nivel das notagdes, quer porque é necessaria a sua divulgagio de forma a que mais informéticos adquiram os conhecimentos necessétios para a sua correcta utilizacio. FE preciso estar atento as iniciativas metodoldgicas mais recentes, nomeadamente Aquelas que propdem uma simplificagio do proceso de desenvolvimento ao nivel de actividades, notagdes e documentagio produzida. Muitas dessas abordagens recorrem ao UML para as actividades de modelagio que realizam, o que mais uma vez reforca o facto do UML ser uma norma de facto.90 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | 3.9 Exercicios Fx.16. Imagine que é © responsivel de uma biblioteca cujos livros podem set requisitados por diversos leitores previamente registados, mediante a apre- sentagio de uma guia de requisigdo. Esta indica 0 prazo de devolugio, ao fim do qual o leitor tem que devolver o livro, preeachendo uma guia de entrega. Para os livtos muito solicitados poderio existir varias cépias na biblioteca, se necessitio, poderio ser adquiridas mais. Para tal, o responstivel da biblio- teca poder requisitar mais c6pias através de uma requisicio, que seta autori- zada pela diteccio, de modo a que 0 responsavel da biblioteca possa enco- mendar esses livros junto de um fornecedor, proceder ao respectivo paga- mento e dar entrada dos livros na biblioteca. Ex.17, Se tivesse que efectuar a anélise deste caso segundo uma abordagem estruturada, que tipo de informagao do enunciado seria mais televante? E. se a abordagem utilizada fosse orientada por objectos? Justifique sua resposta Ex.18, Efectue a modelagio da estrutura estitica do sistema pelo diagrama estrututado que achar mais conveniente, justificando a sua resposta. Ex.19. Efectue a modelacio da estrutura estitica do sistema utilizando um dia- grama relacionado com abordagens orientadas por objectos. Ex.20. Imagine que é o responsivel pela gestfio de informacio sobre alunos de uma universidade, sendo para isso relevante reproduzir no sistema de infor- macio as acgdes que normalmente ocorrem ao longo do ano na universi- dade: matriculas de alunos num ano lectivo ¢ em cadciras; inscrigées nas aulas priticas; inserigées em exames; pagamentos de propinas; consultas de notas atribuidas; pedidos de certificados. Ex.21, Se tivesse que modelar o sistema anteriormente descrito, indique qual (ow quais) 0(6) diagrama(s) que utilizaria se aplicasse uma abordagem estruturada © qual (ou quais) utilizaria se aplicasse uma abordagem orientada por objec- tos, justificando a sua resposta. Fx.22. Bfectue a modelagio dos conceitos aqui representados pelos diagramas estruturados que achar convenientes, justificando a sua resposta. Ex.23. Efectue a modelagio dos conceitos aqui representados pelos diagtamas relacionados com abordagens orientadas por objectos que achar convenien tes, justificando a sua resposta.CaPiTULo 3 — EVOLUGAO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 91 Ex.24. Quais as principais alteragdes que ocorteram no processo de desenvolvi- mento de software com a introdugio das abordagens estruturadas? Ex.25. Uma das criticas que normalmente se aponta 4s metodologias estrutura- das é de defenderem conceitos tedticos que se afastam da realidade pratica. Indique alguns exemplos deste desfasamento. Fx.26. Compare os conceitos utilizados nos principais diagramas utilizados nas abordagens estruturadas e nas abordagens orientadas por objectos, para modelar a dinamica de um sistema. Ex.27. As abordagens orientadas por objectos, particularmente na tarefa de implementacio, sio particularmente adequadas para a implementagio de processos iterativos. Justifique esta afirmagao. Ex.28, As metodologias estruturadas esto tipicamente divididas em duas catego- rias principais, consoante a importéncia que atribuem as principais técnicas de modelaco utilizadas. Indique quais so essas categorias, ¢ quais as princi- pais caracteristicas de cada uma deles. Ex.29. Porque € que as metodologias de desenvolvimento de software estrututa- das tém este nome? Quais as motivagSes que levaram a sua defini¢ao e apli- cacao? Ex.30. Algumas das novas metodologias defendem o fim das actividades de an4- lise no processo de. desenvolvimento de software. Expresse a sua opiniio, justificando-a.