Sgmoo: Sistema Gestor de Métodos Orientados A Objetos Baseado em Conhecimento

Universidade de Braslia
Instituto de Cincias Exatas Departamento de Cincia da Computao
SGMOO: SISTEMA GESTOR DE MTODOS ORIENTADOS A OBJETOS BASEADO EM CONHECIMENTO
por
Gilene do Esprito Santo Borges
Dissertao submetida ao Departamento de Cincia da Computao como requisito parcial para obteno do grau de Mestre em Cincia da Computao
Orientadora Prof(a). Dr(a). Maria Elenita Menezes Nascimento
Braslia, Dezembro de 1998.
SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________
BORGES, Gilene do Esprito Santo SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento / Gilene do Esprito Santo Borges: UnB, Cincia da Computao, 1998. p. 236 : il. Dissertao (mestrado) - Universidade de Braslia, curso de ps-graduao em Cincia da Computao, Braslia, 1998. Orientadora: Dra. Maria Elenita Menezes Nascimento 1. Orientao a objetos 2. Mtodos de desenvolvimento 3. Funes de crena
ii
Aos meus pais Gil e Leny, aos meus irmos Cleide e Everton, ao meu amigo e amado Alexandre M. Gomes, ao meu amigo e tutor Fbio Bianchi Campos e s minhas amigas Jussely Costa, Renata P. Oliveira e Viviane Meireles.
iii
A tarefa da equipe de desenvolvimento de software projetar a iluso de simplicidade.

Grady Booch (Booch, 1992) iv
Quero agradecer a Deus pela proteo e orientao que me so sempre concedidos. minha orientadora, Dra. Maria Elenita Menezes Nascimento, pelas crticas, pela orientao e tambm pelo incentivo que me foram to preciosos. Ao colega e amigo M.Sc. Fbio Bianchi Campos pela grande pacincia e inestimvel disponibilidade em poder me esclarecer dvidas a cerca dos aspectos tcnicos de Engenharia de Software. Ao prof. Dr. Wagner Teixeira da Silva e colega M.Sc. Raquel Regis A. Carvalho pelo carinho com que sempre sanaram minhas dvidas sobre a teoria de funo de crena. Aos meus pais Gil e Leny e irmos Cleide e Everton pela ajuda, compreenso e coragem, que mesmo de longe souberam me dar. Ao meu grande amigo e amado Alexandre Mesquita Gomes pelo seu carinho, pacincia e apoio que me foram to preciosos, possibilitando-me concluir este trabalho com tranqilidade e perseverana. Aos meus tios Manoel e Luceny Soares e primos que me acolheram em sua casa, me proporcionando uma tranqilidade inestimvel. Igualmente, aos meus tios Edilson e Lucely Moura que acolheram em sua casa no incio desta batalha. Aos colegas de mestrado que, de uma forma ou de outra, me auxiliaram na realizao deste trabalho, em especial M.Sc. Renata Peluso de Oliveira, Jos Roberto Valentin, M.Sc. Lellis Maral Mesquita, Andr Luiz Moura, M.Sc. Estevam Rafael Hruschka Jnior, dja de Jesus Rgo e Hlio Berch Pereira (in memorian). s minhas duas amigas, Jussely Costa e Viviane Meireles, que sempre estiveram do meu lado me incentivando e me passando a certeza de que tudo daria certo. Jamais esquecerei que foi voc, Jussely, quem me encorajou a iniciar essa batalha. Aos meus professores de graduao, Joilson dos Reis Brito e Ronaldo Del Fiaco, pelo incentivo atravs de recomendaes. Aos professores do departamento que muito contriburam atravs de crticas e sugestes, especialmente ao Dr. Francisco de Assis Cartaxo Pinheiro, Dra. Alba Cristina de Melo e Dr. Antnio Nuno de C. Santa Rosa. Aos funcionrios da UnB, em especial aos do departamento do CIC: Rosa, Marinalva, Mrcia, Sandra, Cida, Pablo e Celso. empresa Hewlett Packard Laboratories, que gentilmente enviou-me artigos de suma importncia para minha pesquisa. Ao depto. de Cincias Matemticas e de Computao da USP - So Carlos, pela inestimvel ajuda com artigo e sugestes, que foram de grande valia a minha pesquisa. Aos meus amigos virtuais: Carlos Eduardo de Barros Paes (PUC - SP), Dr. Guilhermo Bustos Reinoso (Chile), Ismar Frango Silveira (ITA - SP), Leandro Pompermaier (UFRGS - Rio Grande do Sul), M.Sc. Rejane Moreira da Costa (USP - So Carlos) e M.Sc. Ricardo Pereira e Silva (UFRGS RS), que foram muito atenciosos; enviando de longe monografias, referncias, artigos e sites para que eu pudesse compreender melhor o assunto. A CAPES pela disponibilizao de uma bolsa de estudos.
"#! #! "

v
Atualmente esto disponveis diferentes mtodos para desenvolvimento de software. No entanto, estratgias apropriadas para seleo dos mtodos mais adequados dependem das caractersticas da aplicao a ser desenvolvida. Uma estratgia apropriada aquela que prov um sistema de alta qualidade e com bons resultados a custos mnimos de manuteno. O objetivo dessa pesquisa envolve a seleo de mtodos orientados a objetos mais adequados para um projeto de desenvolvimento de software. Para que essa seleo seja possvel, a partir de um estudo comparativo, ser identificado um conjunto de caractersticas desses mtodos. Uma associao entre essas caractersticas e as do sistema ser feita, possibilitando a escolha dos mtodos mais adequados. O resultado obtido ser uma associao bem fundamentada, que poder ser utilizada como guia em qualquer desenvolvimento de sistema possibilitando uma qualidade e rendimento superiores aos encontrados atualmente, devido ao fato de se utilizar o mtodo mais adequado ao desenvolvimento. Entretanto, esse guia no garante o sucesso do desenvolvimento, o qual dever ser medido tambm por outros aspectos, como: qualificao e tamanho da equipe de desenvolvimento, alteraes de requisitos, etc. Um prottipo foi desenvolvido a fim de validar o estudo, utilizando a teoria de funo de crena para combinar evidncias, favorecendo um mtodo ou subconjunto desses. Estas evidncias so mapeadas atravs das caractersticas dos sistemas existentes e combinadas com as caractersticas dos mtodos. Com este trabalho, esperamos suportar os gerentes de desenvolvimento, alm de conscientiz-los de que a escolha de um nico mtodo para o desenvolvimento de vrios tipos de sistemas, no a soluo de todos os problemas nessa rea. Cada sistema possui suas prprias caractersticas e exigem uma escolha adequada para que o produto final apresente qualidade.

vi
Different methods are currently available for software development. However, appropriate strategies to choice more suitable methods depend upon the characteristics of the application to be developed. A suitable strategy is one, which provides a system with high quality and good results with minimum maintenance costs. The goal of this research covers the object-oriented methods selection more appropriate to a project of software development. For this selection to be possible, from a comparative study, a set of characteristics of methods will be identified. An association among these characteristics and characteristics of systems will be made, making it possible to choose the methods more indicated to this development. The obtained result will be a well based association, which could be used as guide in any system development, allowing a better quality and efficiency than the systems found nowadays, due to use the method more adapted to the development. However, this guide does not guarantee the success of the development, which must be considered others aspects like qualification and proportion of development team, requirements alteration, etc. A prototype was developed in order to validate the study, using the belief functions theory to combine evidences that benefit one method or a subgroup of them. These evidences are mapped through the characteristics of existent systems, combined together with the characteristics of the methods. It is intended of this research to support the managers and developers and to be aware that a fixed method choice or a set of them is not the solution to all kinds of systems. Each system has its own characteristics and demands the right choice of the method in order for the final product to present quality.

vii
Resumo.......................................................................................................................................................... vi Abstract. ....................................................................................................................................................... vii Lista de Figuras............................................................................................................................................ x
Lista de Tabelas........................................................................................................................................... xiv
Captulo 1 - Introduo................................................................................................................................ 1.1 - Motivao da pesquisa.......................................................................................................... 1.2 - Objetivos................................................................................................................................ 1.3 - Delimitao do estudo........................................................................................................... 1.4 - Metodologia........................................................................................................................... 1.5 - Organizao do trabalho...................................................................................................... Captulo 2 - Reviso bibliogrfica............................................................................................................... 2.1 - Conceitos de modelagem de sistemas................................................................................... 2.2 - Conceitos de orientao a objetos........................................................................................ 2.3 - Definio de framework....................................................................................................... 2.4 - Consideraes finais............................................................................................................. Captulo 3 - Mtodos orientados a objetos.................................................................................................. 3.1 - Escolha dos mtodos............................................................................................................. 3.2 - Contextualizao.................................................................................................................. 3.3 - OOSE.................................................................................................................................... 3.4 - OMT...................................................................................................................................... 3.5 - OOAD................................................................................................................................... 3.6 - OOA-OOD............................................................................................................................ 3.7 - Fusion................................................................................................................................... 3.8 - Consideraes finais............................................................................................................. Captulo 4 - Comparao dos mtodos orientados a objetos...................................................................... 4.1 - Comparao entre os mtodos ............................................................................................. 4.2 - Cobertura dos mtodos ........................................................................................................ 4.3 - Consideraes finais ............................................................................................................
Captulo 5 - Proposta de um sistema de apoio a deciso utilizando de teoria de funo de crena......... 88 5.1 - Teoria de funo de crena.................................................................................................. 88 5.2 - Algoritmo adotado - Regra de Dempster............................................................................. 90 5.3 - Detalhamento da proposta................................................................................................... 93 5.4 - As questes e o mapeamento das crenas............................................................................ 94 5.5 - Consideraes finais............................................................................................................ 104
!
1 1 2 3 3 4 6 6 10 21 23 24 24 27 28 37 47 55 64 72 73 73 85 86
viii
Captulo 6 - SGMOO: o prottipo.............................................................................................................. 6.1 - Descrio do uso do prottipo............................................................................................ 6.2 - Arquitetura de implementao do SGMOO........................................................................ 6.3 - Descrio da base de conhecimento................................................................................... 6.4 - Apresentao das telas........................................................................................................ 6.5 - Descrio dos casos reais................................................................................................... 6.6 - Resultados obtidos pela anlise do SGMOO...................................................................... 6.7 - Consideraes finais...........................................................................................................
105 105 106 108 110 113 115 117
Captulo 7 - Concluso.............................................................................................................................. 119 7.1 - Viso geral............................................................................................................................ 119 7.2 - Contribuies ao conhecimento............................................................................................ 122 7.3 - Propostas para trabalhos futuros......................................................................................... 123 7.4 - Consideraes finais............................................................................................................. 124 Referncias bibliogrficas......................................................................................................................... 125 Apndice A - Resumo da notao utilizada pelos mtodos...................................................................... A.1 - Notao do mtodo OOSE................................................................................................... A.2 - Notao do mtodo OMT..................................................................................................... A.3 - Notao do mtodo OOAD.................................................................................................. A.4 - Notao do mtodo OOA-OOD........................................................................................... A.5 - Notao do mtodo Fusion.................................................................................................. Apndice B - Requisitos do sistema de biblioteca.................................................................................... B.1 Objetivos do documento...................................................................................................... B.2 Glossrio bsico.................................................................................................................. B.3 Descrio............................................................................................................................. B.4 Identificao do sistema e dos agentes externos................................................................. B.5 Funcionalidades e restries genricas do sistema............................................................ B.6 Interfaces entre os agentes externos e o sistema................................................................. B.7 Identificao dos elementos de informao........................................................................ B.8 Aspectos gerais sobre o sistema.......................................................................................... 130 130 131 138 141 143 149 149 149 150 151 151 153 153 155
Apndice C - Modelagem do sistema pelos mtodos............................................................................... 157 C.1 - Modelagem em OOSE......................................................................................................... 158 C.2 - Modelagem em OMT.......................................................................................................... 174 C.3 - Modelagem em OOAD........................................................................................................ 183 C.4 - Modelagem em OOA-OOD................................................................................................. 193 C.5 - Modelagem em Fusion........................................................................................................ 202 C.6 - Dicionrio de dados do sistema......................................................................................... 213 Apndice D - Linguagem de Modelagem Unificada - UML.................................................................. 218 D.1 - Aspectos da notao........................................................................................................... 218 D.2 - Consideraes finais ......................................................................................................... 221
ix
Figura 2.1 - Atributo de ligao (Rumbaugh, 1994).....................................................................................10 Figura 2.2 - Agregao*..............................................................................................................................11 Figura 2.3 - Ilustrao dos conceitos bsicos de dinmica*..........................................................................12 Figura 2.4 - Ilustrao dos conceitos bsicos de funcionalidade...................................................................13 Figura 2.5 - Classe parametrizada ...............................................................................................................14 Figura 2.6 - Associao ternria*................................................................................................................14 Figura 2.7 - Inexistncia de associao ternria* .........................................................................................15 Figura 2.8 - Associao qualificada*...........................................................................................................15 Figura 2.9 - Agregao recursiva (Rumbaugh, 1994)..................................................................................16 Figura 2.10 - Agregao Fsica e no Fsica* /(Booch, 1994) ......................................................................16 Figura 2.11 - Operao polimrfica.............................................................................................................17 Figura 2.12 - Polimorfismo mltiplo ...........................................................................................................18 Figura 2.13 - Aes sobre transies (Rumbaugh, 1994) ............................................................................18 Figura 2.14 - Aes sobre a entrada em estados (Rumbaugh, 1994)............................................................19 Figura 2.15 - Ilustrao dos conceitos de tipos de sincronizao* ................................................................20 Figura 2.16 - Um cenrio para emprstimo*................................................................................................21 Figura 2.17 - Parte do diagrama de interao para emprstimo* ..................................................................22 Figura 2.18 - Framework adotado para descrio dos mtodos ...................................................................23 Figura 3.1 - Fases do mtodo OOSE ...........................................................................................................28 Figura 3.2 - Parte do modelo use case .........................................................................................................29 Figura 3.3 - Descrio do use case - emprestar obra ....................................................................................30 Figura 3.4 - Tipos de relacionamentos entre use cases .................................................................................30 Figura 3.5 - Parte do modelo de objetos do domnio....................................................................................31 Figura 3.6 - Descrio de interface..............................................................................................................31 Figura 3.7 - Parte do modelo de anlise para o use case - emprestar obra.....................................................32 Figura 3.8 - Modelagem dos atributos do objeto entidade - ficha_ttulo .......................................................33 Figura 3.9 - Descrio do objeto de controle - concluidor de emprstimo ....................................................33 Figura 3.10 - Parte do modelo de projeto.....................................................................................................34 Figura 3.11 - Parte do diagrama de interao para o use case - emprestar obra.............................................34 Figura 3.12 - Parte do grafo de transio de estado do objeto: Obra.............................................................35 Figura 3.13 - OMT - Object Modeling Technique (Coleman, 1996) ...........................................................38 Figura 3.14 - Parte do diagrama de classes ..................................................................................................39 Figura 3.15 - Parte do diagrama de instncias..............................................................................................39 Figura 3.16 - Cenrios - a) Normal e b) Refinado ........................................................................................40 Figura 3.17 - Parte do diagrama de eventos .................................................................................................41 Figura 3.18 - Parte do diagrama de fluxo de eventos....................................................................................41 Figura 3.19 - Parte do diagrama de estado para a classe obra.......................................................................42 Figura 3.20 - DFD para uma retirada bancria (Rumbaugh, 1994) ...............................................................43 Figura 3.21 - Parte do diagrama de classe....................................................................................................45 Figura 3.22 - Micro processo (Booch, 1994) ..............................................................................................48 Figura 3.23 - Macro processo (Booch, 1994)..............................................................................................48 Figura 3.24 - Parte do diagrama de interao - cenrio emprestar obra ........................................................50 Figura 3.25 - Parte do diagrama de classe....................................................................................................50 Figura 3.26 - Diagrama de mdulos para o subsistema emprstimo .............................................................52

x
Figura 3.27 - Parte do diagrama de processo ...............................................................................................53 Figura 3.28 - Parte do diagrama de transio de estado................................................................................54 Figura 3.29 - Modelo multinveis - anlise (Coad, 1992) .............................................................................57 Figura 3.30 - Parte do modelo de anlise - nvel classe&objeto....................................................................57 Figura 3.31 - Parte do modelo de anlise - nvel classe&objeto, assunto e atributo.......................................58 Figura 3.32 - Parte do modelo de anlise - completo....................................................................................58 Figura 3.33 - Diagrama de estado do objeto obra.........................................................................................59 Figura 3.34 - Diagrama de servio - verif_senha_usu (senha) ......................................................................59 Figura 3.35 - Especificao da classe ficha_controle ...................................................................................60 Figura 3.36 - Modelo multicamadas, multicomponentes - projeto (Coad, 1993)...........................................61 Figura 3.37 - Modelo de projeto - componente interao humana ................................................................61 Figura 3.38 - Modelo de projeto - componente gerenciamento de tarefas.....................................................62 Figura 3.39 - Modelo de projeto - especificao de tarefas ..........................................................................62 Figura 3.40 - Exemplificao da cardinalidade............................................................................................64 Figura 3.41 - Mtodo Fusion (Coleman, 1996) ............................................................................................64 Figura 3.42 - Composio do mtodo Fusion (Coleman, 1996)....................................................................65 Figura 3.43 - Parte do modelo de objetos ....................................................................................................66 Figura 3.44 - Parte do modelo de objeto do sistema.....................................................................................67 Figura 3.45 - Modelo ciclo-de-vida incompleto...........................................................................................68 Figura 3.46 - Esquema de operao - dados_reserva....................................................................................68 Figura 3.47 - Diagrama de tempo - cenrio emprstimo...............................................................................69 Figura 3.48 - Grafo de interao de objeto - operao solicita_emprstimo.................................................70 Figura 3.49 - Descrio da classe ficha_tombo............................................................................................71 Figura 4.1 - Critrio para nivelamento.........................................................................................................73 Figura 4.2 - Cobertura dos mtodos.............................................................................................................85 Figura 5.1 - Crena bsica em A..................................................................................................................89 Figura 5.2 - Algoritmo em linguagem natural do algoritmo especializado da soma ortogonal.......................91 Figura 5.3 - Mapeamento das funes de crena m1 e m2 ...........................................................................92 Figura 5.4 - Vetor m1 antes da normalizao...............................................................................................92 Figura 5.5 - Vetor m1 aps normalizao....................................................................................................92 Figura 6.1 - Interao entre os dois tipos de usurios e o SGMOO.............................................................105 Figura 6.2 - Quadro de graduao dos mtodos em cada fase do desenvolvimento.....................................106 Figura 6.3 - Arquitetura do prottipo.........................................................................................................107 Figura 6.4 - Relacionamentos das tabelas da base de conhecimento...........................................................110 Figura 6.5 - Tela inicial do prottipo.........................................................................................................110 Figura 6.6 - Formulrio de menu de navegao para o especialista ............................................................111 Figura 6.7 - Formulrio para entrada das perguntas ...................................................................................111 Figura 6.8 - Formulrio para entrada das crenas.......................................................................................111 Figura 6.9 - Formulrio I de apresentao do questionrio.........................................................................112 Figura 6.10 - Formulrio II de apresentao do questionrio......................................................................112 Figura 6.11 - Formulrio de apresentao da explanao da pergunta ........................................................113 Figura 6.12 - Formulrio para incio do algoritmo .....................................................................................113 Figura 6.13 - Resultado apresentado pelo SGMOO para o sistema de contabilidade ..................................115 Figura 6.14 - Resultado apresentado pelo SGMOO para o sistema de biblioteca ........................................115 Figura 6.15 - Resultado apresentado pelo SGMOO para o sistema de passagens areas .............................116 Figura 6.16 - Resultado apresentado pelo SGMOO para o sistema industrial .............................................117 Figura 7.1 - Possvel realimentao do prottipo .......................................................................................122 Figura A.1 - Notao utilizada no modelo de requisitos (Jacobson, 1992)..................................................130 Figura A.2 - Notao utilizada no modelo de anlise (Jacobson, 1992)......................................................131 Figura A.3 - Notao utilizada na fase de projeto (Jacobson, 1992) ...........................................................131
xi
Figura A.4 - Notao utilizada no modelo de objetos (Rumbaugh, 1994)...................................................132 Figura A.5 - Notao utilizada no modelo de objetos - cont. (Rumbaugh, 1994) ........................................133 Figura A.6 - Notao utilizada no modelo de objetos - conceitos avanados (Rumbaugh, 1994) ................134 Figura A.7 - Notao utilizada no modelo de objetos - conceitos avanados - cont. (Rumbaugh, 1994)......135 Figura A.8 - Notao utilizada no modelo dinmico (Rumbaugh, 1994) ....................................................136 Figura A.9 - Notao utilizada no modelo dinmico - cont. (Rumbaugh, 1994) .........................................137 Figura A.10 - Notao utilizada no modelo funcional (Rumbaugh, 1994) ..................................................138 Figura A.11 - Notao utilizada no diagrama de classes (Booch, 1994) .....................................................139 Figura A.12 - Notao utilizada no diagrama de transio de estados (Booch, 1994) .................................140 Figura A.13 - Notao utilizada no diagrama de objetos (Booch, 1994).....................................................140 Figura A.14 - Notao utilizada no diagrama de interao (Booch, 1994)..................................................140 Figura A.15 - Notao utilizada no diagrama de mdulo (Booch, 1994) ....................................................141 Figura A.16 - Notao utilizada no diagrama de processo (Booch, 1994) ..................................................141 Figura A.17 - Notao utilizada no diagrama de estado do objeto (Coad, 1992).........................................141 Figura A.18 - Notao utilizada no diagrama de servio (Coad, 1992).......................................................142 Figura A.19 - Notao utilizada na especificao classe&objeto (Coad, 1992)...........................................142 Figura A.20 - Notao utilizada no modelo de anlise (Coad, 1992)..........................................................143 Figura A.21 - Notao utilizada no modelo de objetos (Coleman, 1996)....................................................144 Figura A.22 - Notao utilizada no modelo de interfaces (Coleman, 1996) ................................................145 Figura A.23 - Notao utilizada nos grafos de interao de objetos (Coleman, 1996).................................145 Figura A.24 - Notao utilizada nos grafos de interao de objetos - cont. (Coleman, 1996) ......................146 Figura A.25 - Notao utilizada nos grafos de visibilidade (Coleman, 1996) .............................................147 Figura A.26 - Notao utilizada na descrio de classes (Coleman, 1996) .................................................148 Figura B.1 - Definio da ficha_tombo .....................................................................................................154 Figura B.2 - Definio da ficha_emprstimo .............................................................................................154 Figura B.3 - Descrio da ficha_ttulo.......................................................................................................155 Figura B.4 - Descrio da ficha_Usurio...................................................................................................155 Figura C.1 - Modelo use case - delimitao do sistema..............................................................................158 Figura C.2 - Descries dos use cases - curso bsico ................................................................................159 Figura C.3 - Modelo do domnio do problema...........................................................................................160 Figura C.4 - Modelo de interface...............................................................................................................161 Figura C.5 - Modelo de anlise - use case: emprestar obra.........................................................................162 Figura C.6 - Modelo de anlise - use case: reservar obra ...........................................................................163 Figura C.7 - Descries do papel e das responsabilidades dos objetos........................................................164 Figura C.8 - Representao dos atributos dos objetos entidade ..................................................................165 Figura C.9 - Modelo de projeto - use case: emprestar obra ........................................................................166 Figura C.10 - Diagrama de interao - use case: emprestar obra (curso bsico)..........................................167 Figura C.11 - Diagrama de interao - use case: reservar obra (curso bsico).............................................168 Figura C.12 - Diagrama de interao - use case: emprestar obra (curso alternativo) ...................................169 Figura C.13 - Diagrama de interao - use case: reservar obra (curso alternativo) ......................................170 Figura C.14 - Grafo de transio de estado - objeto ficha_controle ............................................................171 Figura C.15 - Fluxograma da reserva ........................................................................................................172 Figura C.16 - Resumo grfico dos modelos/diagramas gerados pelo OOSE...............................................173 Figura C.17 - Diagrama de classes - anlise...............................................................................................174 Figura C.18 - Diagrama de instncias........................................................................................................175 Figura C.19 - Diagrama de interface..........................................................................................................175 Figura C.20 - Dicionrio de dados.............................................................................................................176 Figura C.21 - Cenrio normal do sistema de biblioteca..............................................................................177 Figura C.22 - Cenrio especial do sistema de biblioteca ............................................................................177 Figura C.23 - Diagrama de eventos para o cenrio do sistema de biblioteca...............................................178 Figura C.24 - Diagrama de fluxo de eventos do sistema de biblioteca........................................................179 Figura C.25 - Diagrama de estado - classe: obra........................................................................................180 Figura C.26 - Diagrama de valores de entrada e sada................................................................................180
xii
Figura C.27 - Diagrama de classes - projeto ..............................................................................................181 Figura C.28 - Resumo grfico dos modelos/diagramas gerados pelo OMT - anlise...................................182 Figura C.29 - Resumo grfico dos modelos/diagramas gerados pelo OMT - projeto ..................................183 Figura C.30 - Diagrama de classes ............................................................................................................184 Figura C.31 - Diagrama de transio de estado de obra .............................................................................185 Figura C.32 - Diagrama de objetos............................................................................................................186 Figura C.33 - Diagrama de objetos - cont. .................................................................................................187 Figura C.34 - Diagrama de objetos - cont. .................................................................................................188 Figura C.35 - Diagrama de objetos - cont. .................................................................................................189 Figura C.36 - Diagrama de interao.........................................................................................................190 Figura C.37 - Diagrama de mdulo - alto nvel..........................................................................................191 Figura C.38 - Diagrama de mdulo - baixo nvel.......................................................................................191 Figura C.39 - Diagrama de processo..........................................................................................................192 Figura C.40 - Resumo grfico dos modelos/diagramas gerados pelo OOAD..............................................193 Figura C.41 - Modelo de anlise - classe&objeto, atributo e servio ..........................................................194 Figura C.42 - Modelo de anlise - completo ..............................................................................................195 Figura C.43 - Diagrama de estado do objeto..............................................................................................196 Figura C.44 - Diagrama de servio de duas operaes ...............................................................................197 Figura C.45 - Especificao de classes ......................................................................................................198 Figura C.46 - Modelo de projeto - C.I.H. expandido..................................................................................199 Figura C.47 - Modelo de projeto - C.G.T. expandido.................................................................................200 Figura C.48 - Resumo grfico dos modelos/diagramas gerados pelo OOA-OOD - anlise .........................201 Figura C.49 - Resumo grfico dos modelos/diagramas gerados pelo OOA-OOD - projeto .........................202 Figura C.50 - Modelo de objetos ...............................................................................................................204 Figura C.51 - Modelo de objeto do sistema ...............................................................................................205 Figura C.52 - Modelo ciclo-de-vida (incompleto)......................................................................................206 Figura C.53 - Descrio dos cenrios - emprstimo/reserva.......................................................................207 Figura C.54 - Diagrama de tempo - cenrios emprstimo/reserva ..............................................................208 Figura C.55 - Esquema das operaes solicita_emprstimo/dados_reserva ................................................209 Figura C.56 - Grafo de interao de objeto - solicita_emprstimo..............................................................210 Figura C.57 - Grafo de interao de objeto - dados_reserva.......................................................................211 Figura C.58 - Descrio de classes ............................................................................................................211 Figura C.59 - Resumo grfico dos modelos/diagramas gerados pelo Fusion - anlise.................................212 Figura C.60 - Resumo grfico dos modelos/diagramas gerados pelo Fusion - projeto.................................213 Figura D.1 - Entradas da UML (Quatrani, 1998) .......................................................................................220 Figura D.2 - Processo de criao e padronizao da UML (baseado em (Rational, 1997a))........................221
xiii
Tabela 3.1 - Maturidade dos mtodos bsicos orientados a objetos ..............................................................25 Tabela 3.2 - Ferramentas CASE que suportam mtodos orientados a objetos ...............................................26 Tabela 3.3 - Mtodos integradores ..............................................................................................................27 Tabela 4.1 - Descrio explicativa dos aspectos capturados pelos mtodos ..................................................74 Tabela 4.2 - Fase e modelos/diagramas onde os aspectos so capturados pelos mtodos ..............................75 Tabela 4.3 - Nvel de modelagem................................................................................................................76 Tabela 4.4 - Identificao dos requisitos......................................................................................................76 Tabela 4.5 - Identificao de eventos ..........................................................................................................77 Tabela 4.6 - Interface do sistema.................................................................................................................77 Tabela 4.7 - Estrutura de classes .................................................................................................................77 Tabela 4.8 - Estrutura de objetos .................................................................................................................78 Tabela 4.9 - Descrio de classes ................................................................................................................78 Tabela 4.10 - Troca de mensagens ..............................................................................................................78 Tabela 4.11 - Relacionamentos ...................................................................................................................79 Tabela 4.12 - Estrutura de agregao...........................................................................................................79 Tabela 4.13 - Estrutura de herana ..............................................................................................................79 Tabela 4.14 - Modelagem de estados...........................................................................................................80 Tabela 4.15 - Aspectos funcionais...............................................................................................................80 Tabela 4.16 - Identificao de funcionalidades ............................................................................................80 Tabela 4.17 - Criao de subsistemas ..........................................................................................................81 Tabela 4.18 - Alocao de subsistemas .......................................................................................................81 Tabela 4.19 - Estabelecer prioridades ..........................................................................................................81 Tabela 4.20 - Detalhamento de operaes ...................................................................................................81 Tabela 4.21 - Tratamento de concorrncia...................................................................................................82 Tabela 4.22 - Foco - anlise de requisitos....................................................................................................82 Tabela 4.23 - Foco - anlise ........................................................................................................................82 Tabela 4.24 - Foco - projeto ........................................................................................................................83 Tabela 4.25 - Abordagem - dados................................................................................................................83 Tabela 4.26 - Abordagem - comportamental................................................................................................83 Tabela 4.27 - Resumo dos nveis de modelagem recebidos pelos mtodos para cada aspecto capturado .......84 Tabela 5.1 - Tabela modelo para apresentao das questes ........................................................................94 Tabela 5.2 - Questo 1 - Anlise de requisitos .............................................................................................95 Tabela 5.3 - Valores obtidos para a questo 1..............................................................................................96 Tabela 5.4 - Questo 2 - Anlise de requisitos .............................................................................................96 Tabela 5.5 - Valores obtidos para a questo 2..............................................................................................97 Tabela 5.6 - Questo 3 - Anlise de requisitos .............................................................................................97 Tabela 5.7 - Questo 4 - Anlise .................................................................................................................97 Tabela 5.8 - Questo 5 - Anlise .................................................................................................................98 Tabela 5.9 - Questo 6 - Anlise .................................................................................................................98 Tabela 5.10 - Questo 7 - Anlise ...............................................................................................................98 Tabela 5.11 - Questo 8 - Anlise ...............................................................................................................99 Tabela 5.12 - Questo 9 - Anlise ...............................................................................................................99 Tabela 5.13 - Questo 10 - Anlise............................................................................................................100 Tabela 5.14 - Questo 11 - Anlise............................................................................................................100

xiv
Tabela 5.15 - Questo 12 - Projeto ............................................................................................................101 Tabela 5.16 - Questo 13 - Projeto ............................................................................................................101 Tabela 5.17 - Questo 14 - Projeto ............................................................................................................101 Tabela 5.18 - Questo 15 - Projeto ............................................................................................................102 Tabela 5.19 - Questo 16 - Projeto ............................................................................................................102 Tabela 5.20 - Questo 17 - Projeto ............................................................................................................102 Tabela 5.21 - Questo 18 - Projeto ............................................................................................................102 Tabela 5.22 - Questo 19 - Projeto ............................................................................................................103 Tabela 5.23 - Questo 20 - Projeto ............................................................................................................103 Tabela 5.24 - Questo 21 - Projeto ............................................................................................................103 Tabela 5.25 - Questo 22 - Projeto ............................................................................................................104 Tabela 6.1 - Crena...................................................................................................................................108 Tabela 6.2 - Fase.......................................................................................................................................108 Tabela 6.3 - Mtodo..................................................................................................................................109 Tabela 6.4 - Pergunta ................................................................................................................................109 Tabela 6.5 - Resposta................................................................................................................................109 Tabela 6.6 - Respostas das questes para cada sistema ..............................................................................114 Tabela C.1 - Dicionrio de dados - grafo de interao, mtodos e eventos .................................................202 Tabela C.2 - Dicionrio de dados - classes, atributos, operaes e associaes...........................................203 Tabela C.3 - Classes, associaes e descries gerais do sistema de biblioteca ..........................................214 Tabela C.4 - Atributos das classes e descries gerais do sistema de biblioteca..........................................215 Tabela C.5 - Operaes das classes e descries gerais do sistema de biblioteca........................................216 Tabela C.6 - Eventos que afetam o sistema e descries gerais do sistema de biblioteca ............................217
xv
Quando se iniciaram os primeiros desenvolvimentos de softwares no eram utilizados tcnicas ou passos determinados, porque os tipos de sistemas a serem automatizados eram bastante simples, devido capacidade de hardware ser baixa. No poderiam ser desenvolvidos sistemas complexos, visto que no teriam onde ser executados. Com o passar do tempo, especificamente nas dcadas de 60 e 70, o hardware teve uma grande evoluo, juntamente com a evoluo das redes, dos bancos de dados, dos sistemas operacionais e de linguagens de programao, que possibilitaram o desenvolvimento de sistemas mais complexos. Essa evoluo trouxe consigo, tambm, vrios problemas na rea de engenharia de software, conhecida como "crise do software". Desses problemas os mais conhecidos so: baixa produtividade, qualidade abaixo do adequado, prazos e custos estabelecidos, mas no cumpridos, falta de tempo na coleta de requisitos, alto custo na fase de manuteno, etc. Essa crise surge porque sistemas mais complexos so desenvolvidos sem padres, orientao ou gerncia. Desde a identificao da crise do software, pesquisadores vm propondo alternativas de soluo com o propsito de minimizar os problemas que afetam o desenvolvimento de software. Dentre essas alternativas de soluo destacam-se as seguintes: (i) criao de modelos de processo, que ajudam a definir estgios no desenvolvimento e a transio entre esses estgios; (ii) criao de mtodos que especificam como fazer o desenvolvimento, quais diagramas utilizar e quais modelos gerar; (iii) desenvolvimento de ferramentas CASE para automatizar a criao de diagramas e modelos, deixando todo o sistema coerente; (iv) criao de linguagens de programao; (v) mtricas para melhor gerenciar o processo de desenvolvimento e (vi) criao de ferramentas grficas que auxiliam na criao de diagramas, dentre outros. Apesar da existncia de inmeras ferramentas, pode-se notar que a insatisfao e desconfiana dos usurios ainda persistem, possivelmente devido falta de qualidade, elevado tempo despendido, tanto no desenvolvimento quanto na correo e falta de planejamento. Apesar de o gerente de desenvolvimento dispor de uma enorme quantidade de mtodos, tais como: mtodos formais, mtodos estruturados e mtodos orientados a objetos1, a crise ainda persiste.
1
Dentre esses ltimos, pode-se notar ainda a combinao das melhores caractersticas de dois ou trs mtodos gerando outros mtodos, chamados mtodos integradores.

Introduo
)(9C#AB'@2773532)(&'%$#! $ 98 6 (4 10 "
Captulo 1 - Introduo ________________________________________________________________________________________________
O que se tem verificado que a escolha de um mtodo no apropriado ao desenvolvimento poder acarretar conseqncias indesejveis, tais como: dificuldade na aplicao do mtodo, aumentando o prazo de entrega e custos estimados, e como conseqncia um desenvolvimento que poder gerar um produto sem qualidade e de difcil manuteno. A dificuldade em se escolher um mtodo adequado para o desenvolvimento de um dado sistema e os riscos de uma escolha errada, geram os vrios problemas citados anteriormente. Diante desses problemas, sentimo-nos motivadas a: (i) estudar alguns dos principais mtodos orientados a objetos, pois um assunto que necessita de pesquisas2 e (ii) identificar para quais tipos de sistema eles seriam mais indicados. A escolha de um mtodo para o desenvolvimento de um sistema depende, como j dito, das caractersticas do sistema a ser desenvolvido, dentre outros aspectos, tais como: conhecimento/treinamento da equipe de desenvolvimento em relao ao mtodo, tempo disponvel para o desenvolvimento. Entretanto, estes aspectos no so abordados neste trabalho, porque ele trata somente da parte tcnica da escolha de um mtodo. Afirma-se, portanto, que a parte gerencial muito importante e influi bastante na escolha do mtodo. A seguir, sero apresentados o objetivo geral e os objetivos especficos deste trabalho.
O objetivo geral deste trabalho auxiliar os desenvolvedores de sistema a escolher o mtodo orientado a objetos mais indicado para o desenvolvimento de um determinado domnio de aplicao. Os objetivos especficos so: 1) Estudar e comparar os mtodos orientados a objetos atravs da comparao entre os mtodos ser possvel determinar quais so os que melhor modelam determinado aspecto, depois de um estudo aprofundado de cada um dos mtodos; 2) Estudar uma tcnica de Inteligncia Artificial, que possibilite identificar quais so os mtodos mais indicados para um determinado domnio de aplicao; 3) Desenvolver um prottipo para implementar a proposta, possibilitando a manuteno da base de dados (fases, mtodos, perguntas e funes de crena) e interface entre o prottipo e o engenheiro de software para aplicao do questionrio; 4) Agregar os resultados desse trabalho em um contexto mais amplo, o SMM, trata-se de um modelo desenvolvido por Nascimento. O SMM - Software Management Model tem o propsito de integrar aspectos gerenciais e tcnicos em um nico modelo (Nascimento, 1992). Os resultados deste trabalho seriam adicionados na subfuno do SMM denominada Building Strategy (construindo estratgia), mais especificamente em
A escolha dos mtodos orientados a objetos se fortalece pelo fato de que trabalho semelhante j foi desenvolvido para os mtodos estruturados (Nascimento, 1990).

2
Technical Environment Selection, onde os mtodos so escolhidos. Atualmente, somente alguns mtodos estruturados esto disponveis.
Essa pesquisa est centrada no estudo de cinco mtodos orientados a objetos. O objetivo identificar, atravs da descrio dos mtodos e da comparao entre eles, alguns elementos essenciais ao desenvolvimento orientado a objeto, tais como conceitos bsicos, tipos de abordagens, foco dos mtodos, etc. Essa identificao busca facilitar a incluso de novos mtodos orientados a objetos ao trabalho, pois estes sero estudados tendo como base/guia estes elementos essenciais. importante ressaltar que a possibilidade de incluso um aspecto importante porque no limita a pesquisa realizada, uma vez que os mtodos orientados a objetos esto em plena evoluo. Os novos mtodos que iro surgir podero ser bastante completos. Isso poder levar as equipes que desejam um desenvolvimento rpido e simples a adotar mtodos mais simples. Os mtodos criados at os dias de hoje podem no cobrir todos os aspectos necessrios em um desenvolvimento, mas continuaro a ser utilizados no desenvolvimento dos tipos de sistemas para os quais eles tm sido aplicados, pois esses tipos de sistemas e suas caractersticas continuaro a existir. Muitas vezes, no haver necessidade de mtodos completos, e sim daqueles que atendam modelagem necessria. A seguir, ser apresentada a metodologia adotada para o desenvolvimento do trabalho.
! " & % ! ! '$#$"# 14231!'0) ! " !

Nesta seo, descrita a metodologia adotada para o desenvolvimento deste trabalho. 1) Escolha dos mtodos que foi feita a partir de critrios definidos, apresentados com uma descrio na seo 3.1. 2) Estudo preliminar dos mtodos foi realizado em uma monografia (Borges, 1997), que serviu como background para este trabalho. Nela, foi feito um estudo dos mtodos orientados a objetos, resultado do primeiro contato com o assunto, sem fazer um detalhamento sobre eles. 3) Estudo aprofundado dos mtodos, descrevendo os diagramas e modelos que o mtodo gera, separado por fase de desenvolvimento, a transio entre as fases, a aplicabilidade de cada mtodo e seus pontos positivos e negativos. A partir deste estudo, pde-se definir os aspectos modelados pelos mtodos. 4) Modelagem de partes de um sistema, que se tornou necessria, pois com isto pde-se ressaltar as caractersticas e deficincias de cada mtodo. So modeladas somente as partes mais interessantes para cada tipo de modelo e no o sistema completo, pois o tempo limitado e a modelagem deveria ser feita seguindo todos os mtodos. O sistema escolhido a automao de uma biblioteca, detalhes so encontrados na seo 3.2 e apndices B e C. 3
5) Comparao entre os mtodos, onde se identifica um conjunto de aspectos que os mtodos modelam, tais como: identificao de requisitos, modelagem de estados, tratamento de concorrncia, etc. Assim, possvel reconhecer para quais aspectos os mtodos oferecem melhor modelagem, o que permite identificar qual mtodo mais indicado para o desenvolvimento de um determinado sistema. 6) Identificao das questes, realizada com base no trabalho de Nascimento (Nascimento, 1990) e com ajuda de engenheiros de software experientes. Atravs das respostas possvel identificar as caractersticas do sistema a ser desenvolvido. 7) Estudo da teoria de Dempster e Shafer, ou teoria de funo de crena, para compreender a nova rea e seus conceitos, e aplicar um algoritmo que possibilita identificar o mtodo mais indicado baseando-se em crenas definidas pelo especialista em mtodos, ou seja, algum que tenha estudado profundamente um mtodo ou vrios. 8) Desenvolvimento e anlise do prottipo, implementado em Visual Basic for Application, por oferecer fcil manuseio e rpido desenvolvimento. A anlise ser feita a partir de simulao de casos reais aplicados anlise do prottipo. A seguir ser descrita a organizao do trabalho, sua diviso em captulos e apndices.
Este trabalho est dividido em sete captulos e quatro apndices. O primeiro captulo apresentou a descrio do problema que motivou essa pesquisa, os objetivos do trabalho, a delimitao do estudo e a metodologia a ser utilizada para o seu desenvolvimento. O captulo 2 apresenta uma reviso bibliogrfica dos principais conceitos sobre modelagem de sistemas e conceitos bsicos e avanados de orientao a objetos. Apresenta tambm um framework, que ser utilizado para nivelar os mtodos e possibilitar uma comparao entre eles. O captulo 3 descreve como foi realizada a escolha dos mtodos orientados a objetos para estudo, apresenta a contextualizao do sistema de biblioteca utilizado para ressaltar os pontos positivos e negativos dos mtodos e a descrio dos mtodos com base no framework definido no captulo 2. O captulo 4 expe uma comparao entre mtodos orientados a objetos com a descrio de vrias tabelas e a cobertura que os mtodos possuem em cada fase do desenvolvimento de um sistema. O captulo 5 apresenta a tcnica de Inteligncia Artificial utilizada para desenvolver o prottipo, a teoria de funo de crena e o algoritmo soma ortogonal de Dempster e Shafer, bem como um questionrio. O captulo 6 descreve o desenvolvimento do prottipo, sua arquitetura, descrio da base de dados, suas telas e uma anlise dos resultados obtidos mediante aplicao de alguns casos.
312)'&%#" 0 ( $ !
4
O captulo 7 apresenta as concluses, com consideraes finais, contribuies ao conhecimento fornecidas a partir do desenvolvimento da pesquisa e as propostas para trabalhos futuros. Como dito anteriormente, o trabalho composto ainda de quatro apndices. O apndice A apresenta o resumo da notao utilizada pelos mtodos estudados neste trabalho, facilitando a busca do significado de cada notao utilizada na modelagem do sistema. O apndice B descreve os requisitos do sistema de biblioteca utilizado para modelagem seguindo diretrizes dos cinco mtodos estudados, possibilitando uma melhor crtica em relao a eles. O apndice C apresenta os modelos gerados de acordo com cada mtodo e partes dos modelos so apresentadas no captulo 3 para melhor explicao do mtodo. O apndice D apresenta um resumo sobre a Linguagem de Modelagem Unificada (UML), abordando aspectos relevantes sobre esse novo padro, definido pela OMG - Object Management Group.
Reviso bibliogrfica
Este captulo apresenta os conceitos sobre modelagem de sistemas e mtodos orientados a objetos. O objetivo fornecer a base conceitual do assunto tratado no trabalho. Ser apresentado ainda um framework que ser utilizado para nivelar os mtodos possibilitando compar-los.
No incio da computao no eram necessrios modelos de processo nem mtodos para o
desenvolvimento de software, porque os sistemas eram simples devido s vrias restries de hardware e software existentes quela poca. Com o passar dos anos, nas dcadas de 60 e 70, as configuraes de hardware, a interligao de computadores atravs de redes, os tipos de sistemas operacionais e banco de dados e os recursos das linguagens tiveram um desenvolvimento significativo, possibilitando a automao de sistemas mais complexos. Assim, surgiu a necessidade da utilizao dos mtodos e modelos de processo no desenvolvimento de software, os quais permitem um melhor controle do processo e da equipe de desenvolvimento, permitindo que o sistema seja desenvolvido com mais qualidade e produtividade (Booch, 1994). Esta seo objetiva descrever os conceitos sobre modelos de processo, fases de desenvolvimento, mtodos, notao, modelo, dimenso e diagramas. Os modelos de processo definem a seqncia das fases associadas ao desenvolvimento e a evoluo de um software e define, tambm, as regras para finalizar uma fase e passar para a prxima (Nascimento, 1990). Um modelo de processo se preocupa com "o que fazer depois?" e "por quanto tempo ns devemos continuar a faze-lo?" (Nascimento, 1990). Alguns modelos de processo so: waterfall, prototipao, espiral e transformacional. Cada um dos modelos de processo aplica diferentes fases para o desenvolvimento, assim, o gerente de desenvolvimento deve conhec-los para escolher o mais adequado ao tipo de sistema. Um resumo desses modelos de processo pode ser encontrado em (Nascimento, 1990) e (Borges, 1997). Os modelos de processo estabelecem a seqncia de utilizao das fases do processo de desenvolvimento, e estas fases so: i) anlise, que define o que o sistema deve fazer e permite compreender o domnio do problema; ii) projeto, que define como ser implementada a soluo desejada; iii) implementao, tambm chamada de etapa de codificao, quando ocorre a traduo do que est definido no projeto em cdigo executvel; iv) teste, quando se verifica se o sistema tem consistncia em suas partes e como um todo, encontrando e corrigindo os erros; v) manuteno, 6
2A 7 0 2 '4 ' @'4 7 '4 2 ( % #" 3PI1')B2H(G6F7)ECDBA)6"98653"10 )'$&$!
Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________
ocorre depois que o sistema j foi entregue, quando necessrio corrigir erros descobertos durante a operao ou melhorar a performance. Aps a escolha do modelo de processo, que orienta o desenvolvedor atravs das fases de desenvolvimento, so escolhidos um ou mais mtodos para este desenvolvimento. O modelo de processo, como dito, estabelece as fases para o desenvolvimento e o mtodo estabelece as tcnicas a serem aplicadas e os modelos/diagramas a serem elaborados em cada uma dessas fases. Geralmente, os mtodos possuem caractersticas que se adaptam melhor a determinados modelos de processo; por isso, a escolha conjunta dos dois se torna necessria. Um mtodo um processo no qual so produzidos vrios modelos, os quais ilustram, atravs de uma notao, diferentes dimenses de um sistema em desenvolvimento. Segundo (Rumbaugh, 1994), uma metodologia de engenharia de software um processo para a produo organizada de software, com utilizao de uma coleo de tcnicas predefinidas e convenes notacionais. Uma metodologia costuma ser apresentada como uma srie de etapas, com tcnicas e notao associada a cada etapa. importante notar que a palavra metodologia muitas vezes utilizada por alguns autores como tendo o mesmo significado da palavra mtodo, como mostrado acima, embora no seja apropriado, pois metodologia o estudo dos mtodos. Entretanto, os termos mtodo e metodologia so largamente utilizados como sinnimos. Os mtodos podem ser classificados sob dois aspectos: i) quanto a abordagem, onde se observa a orientao indicada pelo mtodo, o aspecto que o metodologista coloca como mais importante: os dados, o comportamento, etc.; ii) quanto ao foco, que determina qual a fase do desenvolvimento que o mtodo fornece maior enfoque, por apresentar mais detalhadamente os modelos, tcnicas, diagramas e a ordem de execuo, que melhor especificam a fase. A abordagem de um mtodo pode ser: i) orientada a dados, onde a preocupao est nas estruturas de dados, nas informaes armazenadas; ii) orientado a eventos, onde o sistema modelado tendo em vista os eventos que ocorrem no ambiente e as respostas que ele deve fornecer; ou iii) comportamental, onde se modela a dinmica e as operaes do sistema. O mtodo pode ter como foco a etapa de identificao dos requisitos, a fase de anlise ou a fase de projeto. O que se tem notado que geralmente, um mtodo tem um foco bastante particular, adotando um dos que foram expostos acima. Depois de exposto o conceito de mtodo, ainda se observa a necessidade de detalhar alguns pontos de sua definio como: notao, modelos e dimenses. A notao um sistema de representao que criada e utilizada pelos autores. Usualmente os autores criam uma notao especfica para cada elemento, que representado pelos modelos de seu mtodo. Por exemplo: uma notao para classe, uma para objeto, etc.; criando assim, a notao dos modelos do mtodo. Somente com uma notao bem definida que um membro da equipe de desenvolvimento conseguir expressar todas as solues criadas em sua mente, possibilitando que outras pessoas entendam e critiquem. Entretanto, em muitos casos no 7
ser utilizada toda a notao criada pelo metodologista, que geralmente bastante detalhada, porque somente parte dela j ser suficiente modelagem requerida. Como cada autor cria sua prpria notao, s vezes, o estudo ou mesmo uso de vrios mtodos em conjunto gera uma certa confuso. Por exemplo, o que a notao de uma linha com um crculo preenchido na extremidade significa agregao em um mtodo, pode significar multiplicidade em outro. Sendo assim, uma notao padro, a UML - Unified Modeling Language, foi definida por Grady Booch, Ivar Jacobson e James Rumbaugh e apresentada a OMG - Object Management Group, que a qualificou como um padro de notao em novembro de 1997. Esta notao padro descrita com mais detalhes no apndice D. Um modelo considerado uma abstrao de certos elementos da realidade e os relacionamentos entre eles, a fim de construir uma representao (usualmente em escala menor) que permite o estudo desta realidade (Nascimento, 1992). Um modelo enfatiza um aspecto da realidade, sendo assim, um mtodo se utiliza de vrios modelos para modelar completamente um sistema, visto que os modelos esto em diferentes nveis de abstraes. O uso desses modelos por um determinado mtodo, no impede que outro mtodo utilize alguns desses mesmos modelos (Silva, 1996). Os modelos so gerados com o propsito de facilitar a compreenso dos problemas e a comunicao entre os membros de uma equipe de desenvolvimento. Os modelos possibilitam tambm que o analista compreenda o domnio do problema. Os modelos construdos na fase de anlise so chamados de modelos de anlise, e na fase de projeto so chamados de modelos de projeto. Os modelos em cada fase possuem diferentes objetivos e caractersticas. Os modelos de anlise so modelos bastante abstratos, que tem como objetivo retratar os requisitos e as funcionalidades do sistema. Um analista, quando gera modelos de anlise, deve compreender o domnio do problema e com a ajuda do usurio, deve modelar a realidade deste domnio, baseando-se nos requisitos do usurio. Estes modelos representam o que o sistema e o que ele deve fazer. Os modelos de projeto so extenses dos modelos de anlise, que incorporam detalhes de nveis inferiores, possibilitando a implementao do sistema. Estes modelos so menos abstratos e tem como objetivo retratar o sistema idealizado na fase de anlise em um sistema real, baseando-se em condies reais de configurao de hardware, tipo de rede de computadores, banco de dados, sistema operacional e linguagem de programao, que sero utilizados para a concretizao do sistema em desenvolvimento. A transio dos modelos de anlise para os de projeto, no uma tarefa simples, e muitas vezes confusa. Neste sentido Jacobson (Jacobson, 1992) acrescenta: A transio do modelo de anlise para o modelo de projeto deve ser feita quando as conseqncias do ambiente de implementao comearem a aparecer. Cada um dos modelos que so criados abrange uma dimenso do sistema e isso fundamental, pois seria bastante confuso tentar expressar todas as dimenses de um sistema em um nico modelo, mesmo que este fosse feito em nveis. A dimenso de um modelo uma viso 8
particular de algum aspecto do sistema, por exemplo, o modelo esttico modela a dimenso de estrutura do modelo, e assim por diante. Cada modelo, ento, modela somente uma dimenso detalhando-a ao mximo. Os modelos de anlise so: o modelo esttico ou modelo lgico, o modelo dinmico, o modelo funcional e o modelo de interface. O modelo esttico ou modelo lgico representa as definies de dados e comportamentos existentes em um sistema. Neste modelo tambm so definidos todos os relacionamentos entre dados e comportamentos, bem como, os tipos de associao - herana e agregao. O modelo apresenta uma viso completa da parte esttica de um sistema, que construdo baseando-se principalmente no domnio do problema. Entretanto, o modelo esttico pode variar de acordo com cada mtodo, como veremos no captulo 3. O modelo dinmico mostra toda a parte dinmica de um sistema, ou seja, a seqncia de eventos, de operaes e de controle (as condies impostas), as aes que o sistema deve executar e seus possveis estados juntamente com suas transies. Este modelo deixa claro como todos esses elementos se relacionam e suas seqncias. O modelo funcional descreve as transformaes de informaes e o fluxo destas pelo sistema, sem definir seqncia. apresentado onde so buscados os dados para transformao e onde so armazenados ou para onde so enviados - para outra transformao ou para fora do sistema, como resposta a um evento. Os modelos de interface representam as diversas formas de interface entre o sistema e o usurio. Estes modelos definem as telas de entrada e sada de dados, as janelas e os relatrios do sistema. O uso do modelo de processo prototipao, para a definio de alguns requisitos ainda no estabelecidos, gera estes modelos antecipadamente para que o usurio possa opinar e criticar. Um dos modelos de projeto o modelo fsico, que mostra a alocao de objetos em mdulos e a estrutura destes e de subsistemas. Apresenta tambm, alocao de tarefas a processadores, dispositivos utilizados e conexes efetuadas. Este modelo descreve o software concreto e a composio do hardware para a implementao do sistema. Um modelo pode necessitar de vrios diagramas para representar toda a informao que deve estar contida nele. Um diagrama seleciona, organiza e mostra informao para realar as partes que mais interessam sobre um assunto e suprimir as menos importantes. Um diagrama no necessita mostrar todas as partes de uma s vez, e se isso acontecer ele ser muito confuso (Rumbaugh, 1994). Como dito anteriormente, um modelo representa somente uma dimenso do sistema, entretanto, esta dimenso pode ter mais de um tipo de diagrama para represent-la totalmente. Depois de todas essas definies que formam a base da modelagem de um sistema, so descritos os conceitos de orientao a objetos que tambm so muito importantes para o contexto do trabalho.
Nesta seo sero descritos os conceitos bsicos e os conceitos avanados, utilizados pelos mtodos orientados a objetos, de uma maneira bem sintetizada. Maiores detalhes so encontrados nas seguintes referncias: (Rumbaugh, 1994), (Jacobson, 1992), (Coad, 1992), (Coad, 1993) e (Booch, 1994). Vale observar que quando for apresentado um conceito bsico ou conceito avanado seguido de uma figura para ilustrao, tentaremos apresentar parte de algum modelo ou diagrama gerado a partir da modelagem do sistema de biblioteca. Neste caso, ao final do nome da figura ser identificado um asterisco (*), indicando que o modelo completo se encontra no apndice C.
2.2.1
Em orientao a objetos identificamos os elementos que compem o domnio do sistema pelas suas caractersticas, os atributos, e pelas operaes, as funes ou transformaes que sero aplicadas pelo elemento definido. Uma classe armazena as definies dos atributos e das operaes de um elemento. D-se o nome de encapsulamento a capacidade de uma classe proteger seus atributos, permitindo que somente suas operaes alterem seus valores. Cada classe pode ter vrias instncias, chamadas objetos. Uma classe pode ser abstrata ou concreta. Somente a classe concreta uma classe instancivel, sendo que a classe abstrata no possui instncias diretas, mas cujas classes descendentes sim. A classe abstrata somente usada para a associao de herana. Uma associao um relacionamento indicando uma conexo semntica entre duas classes (Booch, 1994). Uma ligao uma instncia de uma associao. Alguns autores aceitam a associao entre mais de duas classes, como veremos na seo 2.2.4. Uma associao pode possuir um atributo, chamado atributo de ligao, que no pode ser nem atributo de uma classe nem de outra isoladamente, sem perda de informao. Figura 2.1 apresenta um exemplo onde o atributo de ligao permisso de acesso. Este atributo no pode ser colocado na classe Usurio, pois um usurio ter diferentes permisses para diferentes arquivos, e nem pode ser colocado na classe Arquivo, porque um arquivo ser acessado de maneira diferente por vrios usurios.
Acessvel por
4 3 & 0 & " )6521)()'%#$#!

Conceitos bsicos - modelagem esttica
Arquivo Usurio
permisso de acesso
Figura 2.1 - Atributo de ligao (Rumbaugh, 1994)
10
Herana ou generalizao e especializao um tipo de associao entre classes, onde todos os atributos e operaes definidos na superclasse (a classe mais genericamente definida) so compartilhados pela classe mais especializada, a subclasse. Na subclasse possvel ser feita a definio de mais atributos e operaes e, tambm, a redefinio das operaes que foram herdados pela superclasse. Pode-se ter herana simples onde a subclasse herda os atributos e operaes de uma nica superclasse e a herana mltipla onde a subclasse, chamada de classe de juno, herda os atributos e operaes de duas ou mais superclasses (Rumbaugh, 1994). Outro tipo de associao a agregao ou todo-parte, onde uma classe representa o todo e uma ou mais classes representam as partes deste todo. Um agregado (o todo) possui partes, que, por sua vez, podem ter partes (Rumbaugh, 1994). Um exemplo ilustrado na figura 2.2, onde a classe Obra composta por Ficha_tombo.
Obra nome_obra autor Ficha_tombo nr_tombo dt_devoluo
Figura 2.2 - Agregao*
Terminada a base conceitual da modelagem esttica, segue a apresentao da modelagem dinmica.
2.2.2
Conceitos bsicos - modelagem dinmica
Os conceitos bsicos da dinmica dos objetos so: estado, evento, ao, transio e condio, descritos a seguir. Um estado a situao atual de um objeto definido pelos valores dos atributos deste objeto. Na figura 2.3, os estados do objeto Ficha_controle so: Disponvel, Emprestado e Extraviado. O objeto pode assumir todos os estados durante sua existncia e somente um de cada vez. Eventos so estmulos internos que acontecem entre objetos, ou externos que so aqueles que vem de fora do sistema, estimulando o sistema a produzir alguma resposta ou mudana de estado. Na figura 2.3, um evento externo solicita_emprstimo ou devolver_obra e um estmulo interno cria_ficha ou destri_ficha. A reao de um objeto a um evento pode constituir-se de uma ao ou transio. A ao uma operao instantnea associada a um evento. Transio a modificao de estado causada pelo evento que depende do estado corrente e do evento. Na figura 2.3, o evento solicita_emprstimo causa uma transio, uma modificao do estado de Disponvel para o de Emprestado. importante lembrar que um evento pode gerar mais de uma transio, porque a transio depende do estado atual do objeto. 11
cria_ficha (nr_tombo,' ',d)
devolver obra
Disponvel
solicita_emprstimo (nr_tombo, nr_cadastro) [usurio_apto e tombo_disponvel]
Emprestado
empr_perde_obra (nr-tombo) func_perde_obra (nr_tombo) empr_encontra_obra (nr-tombo) func_encontra_obra (nr-tombo) destri_ficha (nr_tombo)
Extraviado
Figura 2.3 - Ilustrao dos conceitos bsicos de dinmica*
Uma condio uma funo booleana de valores de objetos vlida dentro de um intervalo de tempo. Somente se a condio for verdadeira, que a transio poder ser executada. Um exemplo de condio Usurio apto e tombo disponvel, ilustrado na figura 2.3. Neste caso, as duas condies devem ser satisfeitas. Se uma condio for usada como guarda nas transies, possibilita que as transies guardadas disparem quando seu evento ocorrer, mas somente se a condio de guarda for verdadeira (Rumbaugh, 1994). Observando a figura 2.3, a transio do estado Disponvel para Emprestado uma transio guardada, pois as condies - usurio_apto e tombo_disponvel devem ser verdadeiras para que a transio ocorra. Estes so os conceitos bsicos da modelagem dinmica, sero descritos a seguir os da modelagem funcional.
2.2.3
Conceitos bsicos - modelagem funcional
A modelagem funcional possui conceitos bsicos que esto ligados ao diagrama de fluxo de dados, so eles: i) processos que transformam os valores de dados e que so as operaes das classes; ii) o fluxo de dados que interliga a sada de um objeto entrada de outro, transportando valores de dados; iii) atores que so as extremidades dos fluxos de dados, tanto como origens ou como destinos de dados, eles so objetos ativos3 que consomem ou produzem valores; iv) depsito
3
Um objeto ativo pode executar aes internas sem ter recebido um estmulo externo.
12
de dados um objeto passivo4 que armazena dados para o futuro e v) fluxo de controle um valor booleano que afeta como um processo avaliado. A figura 2.4 ilustra a sinttica de todos os conceitos abordados acima.
Ator 1
fluxo de dado 2 fluxo de dado 1
Depsito de dados 1
fluxo de dado 4
Processo 1
fluxo de controle 1
Processo 2 Depsito de dados 2 Ator 2

fluxo de dado 5 fluxo de dado 3
Figura 2.4 - Ilustrao dos conceitos bsicos de funcionalidade
Nas prximas sees sero descritos os conceitos avanados de orientao a objetos da parte esttica e dinmica, requerendo um completo entendimento das sees anteriores.
2.2.4
Conceitos avanados modelagem esttica
(Booch, 1994) descreve alguns tipos especiais de classe como classe parametrizada e metaclasse. Devido a sua importncia, seus conceitos so descritos a seguir. Metaclasse uma classe cujas instncias so classes (Booch, 1994). Estas instncias so chamadas de metaobjetos, visto que no so objetos do mundo real, suas instncias que sero objetos. Uma metaclasse possui seus atributos de classe que descrevem um valor comum a toda uma classe de objetos, e suas operaes de classe que so operaes sobre a prpria classe, geralmente para criao de novas instncias de classes. Classe parametrizada ou classe genrica uma classe utilizada como modelo para a criao de uma famlia de classes diferenciadas apenas pelos seus parmetros. A classe parametrizada Pilha - tipo, ilustrada na figura 2.5, deve ser instanciada com um valor para o parmetro tipo, surgindo assim, a classe Pilha - int e a classe Pilha - string. A partir dessas classes instanciadas que ser possvel a instanciao de objetos reais. Tanto a classe paramtrica como a metaclasse so classes cujas instncias, tambm, so classes. A diferena bsica que as instncias da classe parametrizada possuem os mesmos atributos e operaes e so de tipos diferentes. As instncias da metaclasse compartilham valores de atributos comuns entre si. Todos os dois tipos de classe se preocupam com o reuso, o primeiro ao nvel de definies e o segundo ao nvel de valores.
4
Um objeto passivo, ao contrrio do objeto ativo, no possui aes, esttico.
13
tipo Pilha pilha: tipo pop(tipo) push(tipo)
int Pilha pilha: int pop(int) push(int)
string Pilha pilha: string pop(string) push(string)
Figura 2.5 - Classe parametrizada
Existem tipos de associaes mais especializadas como: associao ternria, associao qualificada, classe agregada, herana por extenso, herana por restrio, agregao fixa, agregao varivel, agregao recursiva, agregao fsica e agregao no fsica. Estes conceitos no so difundidos em todos os livros de mtodos orientados a objetos, mas so descritos por serem de muita importncia, especializando os conceitos j apresentados. As associaes podem ser: i) binrias, so as mais comuns; ii) ternrias, so mais difceis de serem modeladas, mais ainda podem ser encontradas em muitos modelos; ou iii) de ordem mais elevada, que acontecem com menor ou quase nenhuma freqncia. A associao ternria ou de ordem mais elevada uma unidade atmica e no pode ser subdividida em associaes binrias sem perder informao (Rumbaugh, 1994). A figura 2.6 apresenta um exemplo de associao ternria, onde o Funcionrio cadastra a Ficha_usurio com os dados informados pelo Usurio. A figura 2.7 tenta apresentar a mesma idia, mas sem a forte semntica apresentada pela figura 2.6.
Funcionrio nome_fun endereco_fun senha_fun operador cadastra Usurio nome_usu
Class name Ficha_usuario nome_usu endereco_usu cota_emprestimo cota_emprestada divida_total senha_usu
Figura 2.6 - Associao ternria*
Analisando a figura 2.7, no possvel identificar claramente o relacionamento ternrio, pois no modelo completo claramente observa-se os relacionamentos binrios entre Funcionrio e Ficha_usurio e entre esta e Usurio, mas o relacionamento ternrio ficaria obscuro.
14
cadastra Ficha_usurio 1..N Funcionrio
comunica com Usurio 1..N
Figura 2.7 - Inexistncia de associao ternria*
Associao qualificada estabelecida quando se utiliza de um qualificador para reduzir a multiplicidade de uma associao. Na Figura 2.8 temos que o Cadastro_ttulos uma agregao de muitas Ficha_ttulo, para simplificar colocado um qualificador, o cod_cadastral, que identifica unicamente as fichas, reduzindo a multiplicidade da associao.
Cadastro_titulos total_titulos cod_cadastral Ficha_titulo nome_obra autor qtdd_tombos
Figura 2.8 - Associao qualificada*
Classe agregada uma classe criada a partir de outras classes, atravs da herana mltipla, herdando todos seus atributos e operaes e no adiciona nenhum atributo ou operao prprios da classe criada. A herana por extenso acontece quando uma subclasse herda todos atributos e operaes da superclasse e novos atributos e/ou novas operaes so adicionadas subclasse. J a herana por restrio acontece quando a subclasse herda todos os atributos e operaes da superclasse, mas restringe alguns desses, ou atributos e/ou operaes. Esta restrio pode acontecer para que a subclasse no possua certos atributos ou para modificar as operaes herdadas. Rumbaugh afirma que a restrio (ou cancelamento) das operaes pode acontecer devido a quatro razes: 1) cancelamento para extenso - a nova operao igual operao herdada, mas acrescenta alguns detalhes de comportamento, afetando novos atributos da subclasse. 2) cancelamento para restrio - a nova operao pode ter os tipos de argumentos reduzidos, restringindo a interface, o que pode ser necessrio para manter a operao herdada dentro da subclasse. 3) cancelamento para otimizao - a nova operao deve ter a mesma interface e apresentar os mesmos resultados que o antigo, mas sua representao interna e seu algoritmo podem ser completamente diferentes.
15
4) cancelamento por convenincia - as novas operaes substituem as operaes inconvenientes que foram herdadas utilizando o mesmo nome de operao, mas especificando comportamentos diferentes. A associao de agregao pode ser classificada em fixa, varivel e recursiva. A agregao fixa ocorre quando o agregado possui a quantidade das partes fixa, foi apresentado um exemplo na figura 2.2, onde a classe Obra possui uma Ficha_tombo. A agregao varivel ocorre quando o agregado tem um nmero de nveis finito, entretanto a quantidade de suas partes varivel. A agregao recursiva ocorre quando o agregado recursivo contm, direta ou indiretamente, uma instncia do mesmo tipo do agregado, um exemplo deste conceito ilustrado pela figura 2.9, onde um Bloco pode ser um Comando simples ou um Comando composto, e a recurso acontece porque o Comando composto pode conter vrios Blocos.
Bloco
Comando composto
Comando simples
Figura 2.9 - Agrega o recursiva (Rumbaugh, 1994)
Uma agregao pode ser fsica ou no. A agregao no fsica ocorre quando as partes da agregao no existem fisicamente. A figura 2.10 ilustra um exemplo onde o Acionista possui Aes, mas estas aes no so partes fsicas do acionista. A agregao fsica indica que as partes da agregao existem fisicamente, como no exemplo da figura 2.10, onde uma Ficha_tombo uma parte fsica que est agregado a Obra fsica (Booch, 1994).
Obra
Ficha_ tombo
Acionista
1..N
Ao
Agregao fsica
Agregao no fsica
Figura 2.10 - Agrega o Fsica e n o Fsica* /(Booch, 1994)

Uma agregao fsica pode ser por valor ou por referncia. Na agregao por valor o tempo de vida do agregado (a classe que representa o todo) e de suas partes esto intimamente conectados. Quando o agregado instanciado, so instanciadas tambm as partes deste agregado, e quando a instncia do agregado destruda, as instncias das partes tambm so. Na agregao por 16
referncia, diferentemente da agregao por valor, os tempos de vida do agregado e de suas partes no esto mais ligados, o que permite a criao e destruio das instncias independente uma das outras (Booch, 1994). A figura 2.10 apresenta um exemplo de agregao por valor, a existncia de Ficha_tombo est ligada existncia de Obra. (Booch, 1994) ainda acrescenta: agregao por valor no pode ser recursiva (que , ambos os objetos no podem fisicamente ser partes um do outro), embora agregao por referncia possa (cada objeto pode manter um ponteiro para o outro). Um conceito muito importante o de polimorfismo. Existem dois tipos: polimorfismo nico ou polimorfismo e o polimorfismo mltiplo. Polimorfismo uma forma de dizer que o mesmo mtodo pode fazer coisas diferentes dependendo da classe onde ele implementado... Objetos de classes diferentes recebem a mesma mensagem e reagem de formas diferentes. O objeto que enviou a mensagem no sabe a diferena, o receptor interpreta a mensagem e prov o comportamento adequado (Orfali, 1996). A figura 2.11 apresenta um exemplo de polimorfismo nico. As duas classes derivadas da superclasse Figura, Quadrado e Crculo implementam de forma diferente a mesma operao desenhar. Neste caso, diz-se que esta operao uma operao polimrfica5, pois seu comportamento pode ser implementado de forma diferente nas classes Quadrado, Crculo e Figura. Sendo assim, a mesma operao desenhar se comportar de forma distinta preservando, porm, o mesmo nome e parmetros.
Figura desenhar(borda, interno) Quadrado desenhar(borda, interno) Crculo desenhar(borda, interno)
Figura 2.11 - Opera o polimrfica
A operao desenhar, ilustrada pela figura 2.12, exemplifica o conceito de polimorfismo mltiplo. Alm da existncia da primeira operao desenhar, ilustrada na figura 2.11, criado uma nova operao, que difere da anterior pela quantidade e/ou tipo de parmetros. Todas as duas operaes so implementadas pelas subclasses e pela superclasse. Desta forma, a operao desenhar poder apresentar seis comportamentos diferentes. Aps explanao dos conceitos avanados da modelagem esttica, seguem os conceitos avanados da modelagem dinmica.
Operao polimrfica o mesmo que mtodo polimrfico, neste trabalho referimos a operao e no a mtodo, por referenciarmos mtodos aos mtodos de desenvolvimento de sistemas e no para definir o comportamento dos objetos.
17
Figura desenhar(borda, interno) desenhar(borda, interno, pos) Quadrado desenhar(borda, interno) desenhar(borda, interno, pos) Crculo desenhar(borda, interno) desenhar(borda, interno, pos)
Figura 2.12 - Polimorfismo mltiplo
2.2.5
Conceitos avanados - modelagem dinmica
Os conceitos bsicos da parte dinmica apresentados na seo 2.2.2 podem ser especializados. Nesta seo so conceituados o superestado e subestado, aes de entrada e de sada, aes internas, atividade e transio automtica. Um estado chamado de superestado quando este possui subestados. Os subestados herdam as transies de seus superestados. Assim, qualquer transio que se aplique a um estado aplica-se a todos os seus subestados, a menos que seja cancelada por uma transio equivalente no subestado (Rumbaugh, 1994). As aes de entrada e de sada de um objeto so utilizadas geralmente, quando todas as transies em um estado executam a mesma ao, melhorando o aspecto visual, pois as duas notaes6 no possuem diferenas semnticas.
apertar / motor p/ cima
Abrindo
porta aberta / motor desliga
Fechada
apertar / motor p/ cima
Abrir
porta fechada / motor desligado
Fechando
apertar / motor p/ baixo
Figura 2.13 - Aes sobre transies (Rumbaugh, 1994)
A figura 2.13 apresenta aes sobre transies, note que o estado Abrindo recebe todas as transies geradas pelo evento apertar. Estas transies tm a ao em comum motor p/ cima, deste modo, pode-se simplificar o modelo, colocando esta ao comum como ao de entrada para o estado Abrindo, como ilustrado pela figura 2.14.
As notaes que se refere so as aes sobre transies e aes de entrada e sada representadas dentro do estado.
18
apertar
Abrindo entrada / motor p/ cima
porta aberta
Fechada entrada / motor desligado
apertar
Abrir entrada / motor desligado
porta fechada
Fechando entrada / motor p/ baixo
apertar
Figura 2.14 - A es sobre a entrada em estados (Rumbaugh, 1994)
Entretanto, se todas as transies de sada de um estado possurem a mesma ao, a simplificao do modelo seria criar uma ao de sada para este estado. As aes internas so aes que so executadas sem causar uma mudana de estado. Portanto, as aes internas esto ligadas ao acontecimento de um evento onde as aes de entrada e de sada do estado no so executadas. Atividade um tipo de ao que contnua e seqencial, leva um tempo para executar e est associada a um estado. Quando um objeto mudar para um estado que possui uma atividade, esta inicia-se sendo finalizada aps um intervalo de tempo ou quando houver uma transio de estado. Existe a possibilidade de um estado ter o nico propsito de executar uma atividade e quando esta atividade termina, uma transio para outro estado disparada, a qual recebe o nome de transio automtica. (Rumbaugh, 1994) deixa claro a ordem de execuo das operaes: se forem especificadas mltiplas operaes em um estado, elas sero executadas na seguinte ordem: aes de transio que chega, aes de entrada, atividades faa, aes de sada e aes da transio que sai. Outros aspectos a serem levados em conta o problema da sincronizao das mensagens enviadas entre os objetos e a visibilidade entre esses objetos. Estes conceitos so descritos a seguir. Objetos interagem atravs do intercmbio de mensagens. Um objeto pode enviar uma mensagem para um ou mais objetos, os quais podem receb-lo concorrentemente, ento, diferentes operaes podem ter diferentes tipos de sincronizao, sendo necessrio o estudo dos tipos possveis (Booch, 1994): i) sem concorrncia - nico fluxo de controle; ii) sncrono - o cliente espera at o servidor aceitar a mensagem, ficando bloqueado enquanto o servidor no aceitar a mensagem; iii) balking - igual ao sncrono, exceto pelo fato de que o cliente abandonar a operao se o servidor no estiver imediatamente pronto para receber a mensagem; iv) timeout - o cliente abandonar a solicitao, continuando sua seqncia de execuo normal se o servidor no atender dentro do tempo estipulado; 19
v) assncrono - o cliente envia mensagem para a fila e continua sua execuo, independente da aceitao ou no da mensagem pelo servidor.
2: so li c it ( n r , c a _ s e r v i o od, s enha )
Applet de emprstimo
pon 1 : d is
ib il iz a
_serv
i o
Decodificadorsocket
L
Coordenadoremprstimo
k mp_o 39: e
L
ha , sen , cod 3: (nr 4: ve r if (nr, s _usu enha )
16: verif_obra (cod)
29: nr_tombo
Concluidoremprstimo
mp tu a r _ e it a _ e fe , s t = E ) : s o li c d 30 r, co mbo, n ( n r _ to
15: ve r if _ u s
u_ok
Verificadorusurio
Verificadorobra
Figura 2.15 - Ilustra o dos conceitos de tipos de sincroniza o*

A figura 2.15 ilustra parte de um modelo de projeto onde modelada a concorrncia. A operao 1: disponibiliza_servio sncrona, espera at que Decodificador-socket esteja pronto para receber. A operao 2: solicita_servio do tipo timeout e tentar a conexo com Decodificadorsocket por um tempo determinado. Atravs da operao 3: nr, cod, senha so passados valores que sero verificados pelo Coordenador-emprstimo. A operao 4: verif_usu uma operao sem concorrncia que possibilita Verificador-usurio validar o usurio. A operao 30: efetuaemprstimo(nr-tombo, nr, cod, st = E) uma operao assncrona que enviada ao servidor independente de sua fila de espera. Para que os objetos possam enviar mensagens para outros objetos necessrio fazer a definio da visibilidade de cada objeto. Existem quatro maneiras diferentes (Booch, 1994): i) global (G) quando o objeto servidor global para o objeto cliente; ii) iii) parmetro (P) quando o objeto servidor um parmetro para alguma operao do objeto cliente; campo (F) quando o objeto servidor uma parte do objeto cliente;
20
iv)
local (L) quando o objeto servidor um objeto localmente declarado no escopo do
diagrama de objeto. Outro conceito importante neste contexto o de cenrio. Segundo (Rumbaugh, 1994), cenrio uma seqncia de eventos que ocorrem durante uma determinada execuo de um sistema. A abrangncia de um cenrio pode variar, ele pode incluir todos os eventos do sistema ou somente aqueles que influenciam ou que so gerados por certos objetos do sistema. Um exemplo de um cenrio com a seqncia de eventos para um emprstimo ilustrado na figura 2.16.
Usurio_cadastrado solicita emprstimo ao funcionrio. Funcionrio solicita nr_cadastro ao usurio_cadastrado. Usurio_cadastrado informa seu nr_cadastro. Funcionrio verifica nr_cadastro em ficha_usurio. Funcionrio verifica se usurio_cadastrado tem dvida em ficha_usurio. Funcionrio verifica se usurio excedeu cota_emprstimo em ficha_usurio. Funcionrio verifica se usurio deve tombo em ficha_emprstimo. Funcionrio solicita cd_cadastral ao usurio_cadastrado. Usurio_cadastrado fornece cd_cadastral. Funcionrio verifica se existe ttulo. Funcionrio verifica algum tombo disponvel. Funcionrio verifica se tombo est reservado. Funcionrio verifica se emprestante = reservante. Funcionrio solicita senha a usurio_cadastrado. Usurio_cadastrado fornece senha. Funcionrio verifica senha em ficha_usurio. Funcionrio preenche ficha_emprstimo. Funcionrio atualiza ficha_controle. Funcionrio atualiza ficha_tombo. Funcionrio atualiza ficha_usurio com cota_emprestada + 1. Funcionrio entrega obra ao usurio_cadastrado.
Figura 2.16 - Um cenrio para emprstimo*
Diagrama de interao um diagrama utilizado para descrever seqencialmente a comunicao entre os objetos. uma maneira grfica de representar o que est descrito no cenrio. A figura 2.17 apresenta parte do diagrama de interao para emprstimo, onde se tm objetos na parte de cima do diagrama, uma descrio de cada mensagem no lado esquerdo e a troca de mensagens entre os objetos em seqncia. Na prxima seo ser descrito o framework utilizado para descrever os mtodos.
Nesta seo ser definido o framework utilizado no captulo 3 para descrever os mtodos orientados a objetos sob os mesmos aspectos. O framework composto pela descrio, caractersticas, fases, transio entre as fases, aplicabilidade, pontos positivos e negativos, explicados abaixo. Descrio - apresenta os autores dos mtodos, a evoluo do mtodo (se existente) e uma breve descrio do mtodo. Caractersticas - descreve a abordagem adotada, a fase do desenvolvimento que dado maior enfoque e alguma caracterstica pertinente ao mtodo, que o destaque dos outros. 21
3 # ) & # 4210('%$"!
Fronteira Emprestante Emprestador Ficha_ Ficha_ Fichrio_ Ficha_ ttulo reservas usuarios emprstimo Cadastro_ Ficha_ tem_ Ficha_ ttulos controle reserva usurio
Solicita emprstimo de obra Solicita nmero de cadastro Verifica se usurio est habilitado a tomar obra emprestada Se usurio habilitado Solicita cdigo cadastral da obra desejada Verifica se obra disponvel para emprstimo
Se tombo disponvel . . .
Figura 2.17 - Parte do diagrama de intera o para emprstimo*
Fases - os modelos so descritos em relao a dimenso em cada fase do desenvolvimento7: anlise (anlise de requisitos, tambm), projeto e outras, se o mtodo eventualmente modelar. Para cada fase so apresentadas as dimenses dos modelos: esttica, dinmica, funcional e de interface. Os modelos e diagramas de cada mtodo so descritos resumidamente, apresentando suas caractersticas semnticas e sintticas e referncias a parte dos modelos e diagramas gerados como estudo so
fornecidas, os quais esto por completo no apndice C. Transio entre as fases - descreve como se estabelece a evoluo entre as fases que o mtodo aborda proporcionando uma melhor compreenso do mtodo. Posteriormente so descritos a Aplicabilidade, os Pontos positivos e os Pontos negativos de cada mtodo. O framework adotado ilustrado pela figura 2.18 apresentada a seguir.
O destaque maior est para a anlise e projeto, pois todos os mtodos modelam essas fases. A sub-fase da anlise, a anlise de requisitos ser abordada separadamente, e comentrios sobre outras fases modeladas sero feitos.
22
Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________ 1. Descrio 2. Caractersticas 3. Fases a) Anlise de requisitos b) Anlise c) Projeto d) Outras 4. Transio entre as fases 5. Aplicabilidade 6. Pontos positivos 7. Pontos negativos
Figura 2.18 - Framework adotado para descri o dos mtodos
bsicos de orientao a objetos, bem como os conceitos avanados, utilizados pelos mtodos, visando esclarecer a base conceitual em que est fundamentado este trabalho, facilitando a compreenso do que ser abordado nos prximos captulos. Foi apresentado ainda um framework para possibilitar a descrio dos mtodos orientados a objetos, realizada no prximo captulo. importante ressaltar que muitas vezes, a diferente nomeao para o mesmo conceito entre os diversos mtodos gera confuso e dificuldade para o aprendizado do mesmo. Uma padronizao neste sentido facilitaria o estudo e a compreenso.
$ ! ('&%#"
Neste captulo foram apresentados os conceitos de modelagem de sistemas, os conceitos 23
Mtodos orientados a objetos

Neste captulo pretende-se discorrer sobre aspectos relacionados aos mtodos orientados a objetos, tendo como base o framework definido no captulo anterior. Nas sees subsequentes so apresentados: i) os critrios que foram utilizados para se fazer a escolha dos mtodos tratados neste trabalho, ii) a contextualizao do sistema utilizado como exemplo para modelagem, antes que se inicie a descrio dos mtodos, realizada nas cinco sees posteriores e iii) as consideraes finais.
(Nascimento, 1990) realizou trabalho semelhante a este descrevendo os mtodos estruturados. Deste modo, optou-se por pesquisar os mtodos orientados a objetos. Alm disso, pode-se adicionar um mdulo ao trabalho de (Nascimento, 1992) com essa pesquisa. Inicialmente identificou-se os mtodos orientados a objetos mais divulgados e citados em bibliografias e trabalhos comparativos, tais como: (Silva, 1996), (Andersson, 1995), (Brinkkemper, 1995) e (Marques), os quais so listados na primeira coluna da tabela 3.1. Na primeira linha da tabela 3.1, temos as caractersticas: 1) cobertura do mtodo, identificando quais fases do ciclo de desenvolvimento (anlise de requisitos (Req.), anlise (An.), projeto (Proj.), implementao (Impl.), teste (Teste) e manuteno (Man.)), que cada mtodo aborda. Como no possvel estudar todos os mtodos, so escolhidos os que cobrem, principalmente, anlise e projeto; 2) ferramenta genrica, seis ferramentas CASE mais divulgadas, em revistas, como: Object Magazine - (Patterns, 1997) -, Byte - (Business, 1996) -, Software Development (Choosing, 1995) - e Dr. Dobb's Journal - (Microkernels, 1994), (Cross, 1995) e (Encryption, 1997) - e no meio profissional (em sites da Internet), foram analisadas, obtendo os mtodos para os quais havia suporte. Isto significa que o mtodo bem divulgado e aceito como eficiente. As ferramentas CASE se encontram na tabela 3.2; 3) foi verificado se o mtodo faz parte de algum mtodo integrador, assim verifica-se que o mtodo aceito por outro metodologista, confirmando sua eficincia. Os mtodos integradores observados se encontram na tabela 3.3.
!$2 7 5 !$ 0 & ! '4@$)986'4231)('$%"#

24
Captulo 3 - Mtodos orientados a objetos ______________________________________________________________________________________________________________________________________________ Tabela 3.1 Maturidade dos mtodos bsicos orientados a objetos
Mtodo Autor(es) Req. Proj. Impl. Teste Man. An. Proj. Impl. An. Proj. Impl. 5 3 3
Cobertura do mtodo
Ferramenta genrica
Parte de mtodos integradores -
Total
1-2-3-4-5-6 1-2-3 1-3-5-6 1 1-3-4 1-3-6
4 3 2
13,5 11 2 6 4 4 3,5 10
Req+. An. Proj. Impl. Req. An. Proj. Impl. Man. An. Proj. An. Proj. An. Proj. Impl. An. Req+. An. Proj. Impl. Req. An. Proj. Impl. Teste
Designing Object Oriented Software R. Wirfs-Brock et.al. Entity Relationship Object Oriented Specification Research Group Methodology for Object-Oriented Software Engineering of Systems B. Henderson-Sellers & J. M. Edwards Object Modelling Technique J. Rumbaugh et. al. Object Oriented Analysis and Design G. Booch Object Oriented Analysis and Design J. Martin & J. Odell Object-Oriented Analysis - Object-Oriented Design P. Coad & E. Yourdon Object Oriented Information Engineering J. Martin & J. Odell Object Oriented System Analysis S. Shlaer & S. Mellor Object-Oriented System Development D. Champeaux et. al. Object Oriented Software Engineering I. Jacobson et. al.
Captulo 3 - Mtodos orientados a objetos ________________________________________________________________________________________________
Para cada uma das caractersticas foram atribudos pontos da seguinte maneira: 1) cobertura do mtodo: 1 ponto para cada fase, (Req+8 , 0,5); 2) ferramenta genrica: 1 ponto para cada ferramenta que aborda o mtodo; 3) parte de mtodos integradores: 1 ponto para cada mtodo integrador, para o qual o mtodo faa parte. De acordo com a pontuao definida anteriormente, somando-se as trs colunas internas na tabela 3.1, obtm-se um total de pontos de cada mtodo, identificado na coluna Total, onde pode-se notar que os mtodos mais pontuados so: (13,5) - Object Modelling Technique - James Rumbaugh et. al. (11) - Object Oriented Analysis and Design - Grady Booch (10) - Object Oriented Software Engineering - Ivar Jacobson et. al. (6) - Object-Oriented Analysis - Object-Oriented Design - Peter Coad & Edward Yourdon. importante ressaltar que esta pontuao no define o mtodo com a maior pontuao como o melhor mtodo. Existem vrios aspectos como: modelos criados, notao oferecida, tratamento das fases do desenvolvimento e a transio entre elas; que so os que devem ser levados em considerao na escolha de um mtodo. E este o estudo que feito neste trabalho. A tabela 3.2, como dito anteriormente, apresenta as seis ferramentas CASE mais amplamente divulgadas. Na primeira coluna desta tabela tem-se o nome das ferramentas CASE, na segunda coluna encontram-se os fabricantes de cada uma das ferramentas, seguido pelo endereo na Internet, onde podem ser encontradas informaes sobre a ferramenta.
Tabela 3.2 Ferramentas CASE que suportam mtodos orientados a objetos
Nr. 1 2 3 4 5 6
Ferramenta CASE Paradigm Plus Rational Rose System Architect ObjectTeam Together Select Perspective
Nome do fabricante Platinum Technology Rational Software Corporation Popkin Software & Systems, Inc. Cayenne Software, Inc. Object International, Inc. SELECT Software Tools
Endereo Internet http://www.platinum.com http://www.rational.com http://www.popkin.com http://www.cayennesoft.com http://www.oi.com http://www.pmp.co.uk
A tabela 3.3 apresenta os mtodos integradores, que so: Catalysis, Fusion, Syntropy e Objectory/Unified Method. A primeira coluna dessa tabela mostra o nome do mtodo integrador e seu(s) autor(es), e na segunda coluna os mtodos utilizados para compor o mtodo integrador. Por exemplo: o mtodo Fusion agrega os mtodos OMT, OOD, mtodos formais e a tcnica CRC. O mtodo Fusion que de segunda gerao tambm foi escolhido, por ser um mtodo j divulgado e bem estabelecido, sendo tambm considerado um mtodo utilizado para compor outro
8
A fase que contm um sinal + seguido, significa que o mtodo referencia a fase fornecendo poucas explicaes ou detalhamentos de como o gerente do desenvolvimento deve proceder naquela fase.
26
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________
mtodo: o Catalysis. Diferentemente ao mtodo Rational Objectory Method - Jacobson, Rumbaugh e Booch, que ainda se encontra em fase de desenvolvimento. Assim, o mtodo Fusion acrescentado lista de mtodos anteriormente mencionada, para fechar o grupo de mtodos que sero alvo deste estudo.
Tabela 3.3 Mtodos integradores
Mtodo integrador Autor(es) Catalysis D. D'Souza & A. Wills Fusion D. Coleman et.al. Syntropy Syntropy User Group Rational Objectory Method I. Jacobson - J. Rumbaugh - G. Booch
Mtodos utilizados OOSE (Jacobson) / OMT (Rumbaugh) / Fusion (Coleman) OMT (Rumbaugh) / OOD (Booch) / Tcnica CRC (Wirfs-Brock) / Mtodos Formais OMT (Rumbaugh) / OOAD (Booch) OOSE (Jacobson) / OMT (Rumbaugh) / OOAD (Booch)
Aps a exposio dos critrios utilizados para a escolha dos mtodos, apresentada a contextualizao tentando esclarecer alguns pontos importantes.
Nas sees que se seguem, os mtodos orientados a objetos sero descritos, tendo como nivelador o framework definido no captulo anterior. Para que seus conceitos e caractersticas, bem como suas vantagens e desvantagens sejam identificados com clareza, ser utilizado a modelagem de um sistema de biblioteca9, o qual ter suas partes mais significativas10 modeladas, para melhor esclarecimento e comparao dos mtodos. Essa modelagem tem o objetivo maior de fornecer aos pesquisadores, uma melhor compreenso dos modelos e diagramas utilizados pelos mtodos. Isto permitir um maior embasamento para que possa ser feita a comparao entre os mtodos no captulo 4. O levantamento de requisitos do sistema de biblioteca se encontra no apndice B Requisitos do sistema de biblioteca. Todos os modelos e diagramas gerados durante o estudo dos mtodos se encontram no apndice C em sees separadas por mtodos. Eles so utilizados como exemplos nas prximas sees para ilustrar conceitos e diagramas dos mtodos.
O sistema de biblioteca ser, tambm, modelado por duas alunas de graduao deste departamento, sob orientao do prof. Dr. Wagner Teixeira da Silva. Este trabalho de graduao tem como objetivo a modelagem completa do sistema, o qual dever ser implementado. Portanto, um trabalho diferente deste, pois aqui sero modeladas partes do sistema utilizando todos os mtodos estudados neste trabalho e, no abordar parte de implementao. A nica semelhana a utilizao do mesmo sistema, que ainda, possivelmente, conter requisitos diferentes. 10 Partes mais significativas, quer dizer, por exemplo, que quando o modelo dinmico do modelo OMT (Rumbaugh) tiver que ser feito, ser escolhido somente a parte mais dinmica do sistema. Nos grafos de transio de estado do mtodo OOSE (Jacobson), ser modelado o objeto com maior mudana de estados.
' % $#! (&"

27
As sees que se seguem descrevem os mtodos orientados a objetos abordados neste trabalho, tendo como base o framework definido na seo 2.4 do captulo anterior. Ele apresenta os seguintes itens: descrio, caractersticas, fases (anlise de requisitos, anlise, projeto e outras), transio entre as fases, aplicabilidade, pontos positivos e negativos.
3.3.1
OOSE - Object Oriented Software Engineering um mtodo orientado a objeto desenvolvido por Ivar Jacobson, Magnus Christerson, Patrik Jonsson e Gunnar vergaard em 1992. O mtodo OOSE o mais abrangente dentre os que so abordados neste trabalho, pois fornece todo um conjunto de modelos e diagramas, que permitem a modelagem do sistema durante as seguintes fases: anlise de requisitos, anlise, projeto, implementao e teste. As duas primeiras fases so agrupadas e tratadas pelo subprocesso Anlise, as duas fases seguintes esto sob controle do subprocesso Construo e a ltima fase, sob o controle do subprocesso Teste, como mostra a figura 3.1.
Anlise
Anlise de Requisitos
Estes subprocessos geram cinco modelos diferentes: modelo de requisitos, modelo de anlise, modelo de projeto, modelo de implementao e modelo de teste. Os requisitos do sistema servem como base para o primeiro subprocesso anlise. Ao final do processo, obter-se- um sistema desenvolvido e testado. O subprocesso Construo utiliza um repositrio chamado Componentes, para o reuso de cdigos fontes de partes de projetos j desenvolvidos. Um componente uma unidade padro construda em uma organizao, que usada para desenvolver aplicaes (Jacobson, 1992). necessrio que ele seja bem testado, eficiente e bem documentado, alm de possuir uma interface bem projetada. Um componente pode ser um white-box (caixa branca) ou um black-box (caixa 28
89%%A@897 76#530(%&%# ! '$ " '$ ' " 4 2 1 ) ' $ "
Descrio
Construo
Implementao Teste de Unidade
Teste
Teste de Integrao Teste do Sistema
Anlise
Projeto
re qui si tos
Modelo de requisitos Modelo de anlise
Modelo de projeto Modelo de implementao
Modelo de teste
Componentes
Figura 3.1 - Fases do mtodo OOSE
preta), os quais estaro prontos para serem reutilizados. Entretanto, a diferena bsica entre whitebox e black-box se encontra no fato de que o cdigo fonte da primeira pode ser modificado, aumentado ou diminudo para adaptar ao propsito de uma parte do projeto em questo. E o cdigo fonte do segundo no pode ser de forma alguma alterado, devendo ser reutilizado como foi projetado, mas os parmetros passados ao componente podem representar o contedo necessrio para satisfazer uma determinada implementao.
3.3.2
Caractersticas
A abordagem desse mtodo orientada a comportamento, tendo como caracterstica marcante a identificao das funcionalidades do sistema, na forma de use cases (casos de uso). Eles conduzem todo o desenvolvimento do sistema, o que permite uma coerncia entre os modelos gerados nas diversas fases, pois todos estaro centrados em refin-los. Apesar do mtodo possuir uma larga abrangncia das fases do ciclo do desenvolvimento, fornecendo um vasto conjunto de modelos e diagramas, seu foco est na fase de anlise, especificamente na anlise de requisitos, quando so gerados vrios modelos: modelo de objetos do domnio, modelo use case e modelo de interfaces, que sero descritos com mais detalhes na seo 3.4.3.
3.3.3
Fases
a) Anlise de Requisitos Durante a anlise de requisitos desenvolvem-se trs modelos: i) modelo use case e as descries de cada use case; ii) o modelo de objetos do domnio; e iii) o modelo de interface. O modelo use case gerado para especificar as funcionalidades do sistema a partir da perspectiva do usurio. O modelo desenvolvido em duas fases: o primeiro modelo desenvolvido retrata o curso bsico, a seqncia ideal sem ocorrncia de erros. O segundo modelo, que representa a evoluo do primeiro, descreve os cursos alternativos, as variaes do curso bsico e a ocorrncia de erros. A figura 3.2 apresenta uma parte do modelo use case bsico, onde contm trs use case (Cadastrar usurio, Emprestar obra e Cancelar reserva) e os atores que interagem com eles (Usurio, Cadastrador, Emprestador e Emprestante).
Usurio Cadastrar usurio
Cancelar reserva
Emprestador
Emprestar obra Cadastrador Emprestante
Figura 3.2 - Parte do modelo use case
29
Para cada use case necessrio que se faa uma descrio sobre suas entradas, restries, validaes e sadas. A figura 3.3 apresenta a descrio do use case Emprestar obra.
O funcionrio (emprestador) solicita emprstimo de obra ao sistema. O sistema solicita ao emprestador o nmero de cadastro do emprestante, para verificar se o mesmo est apto a fazer emprstimo. Esta verificao feita observando se o emprestante j excedeu o limite mximo para emprstimo, se possui alguma dvida pendente e se est com alguma obra emprestada cuja data de devoluo j esteja vencida. Se o usurio estiver apto, o sistema solicita a obra e o usurio fornece o seu cdigo cadastral. O sistema verifica se o cdigo cadastral vlido, e verificado, tambm, se existe algum tombo daquela obra disponvel, se existir, verifica se existe reserva para o tombo. Se existir reserva, observar se o reservante o mesmo usurio que o emprestante, se for, o tombo liberado, se no for, o tombo no pode ser liberado e toda verificao feita para outro tombo. Se algum tombo for liberado, solicitado ao emprestante sua senha, que verificada na ficha do usurio. Se a senha estiver correta, o sistema preenche a ficha de emprstimo e atualiza a ficha de controle do tombo, a ficha de usurio e a ficha de tombo. O emprestador libera a obra ao solicitante.
Figura 3.3 - Descri o do use case - emprestar obra
A figura 3.4 apresenta dois tipos de relacionamentos entre use cases: a) relao de extenso e b) relao de uso.
Emprestar obra sol_ver_senha
extends
uses
uses
Cancelar reserva a) Relao de extenso
Cadastrar obra
Emprestar obra
b) Relao de uso
Figura 3.4 - Tipos de relacionamentos entre use cases
A figura 3.4.a) modela o use case Emprestar obra, que inteiramente independente. Em alguns casos, o use case Cancelar reserva ativado estendendo o use case Emprestar obra, isto modela o caso onde o emprestante possui uma reserva. A relao de extenso utilizada para modelar: i) partes opcionais de use cases, ii) cursos complexos e alternativos, iii) sub-cursos separados, que so executados somente em certos casos, como no caso da figura 3.4.a) e iv) situao onde vrios use cases podem ser inseridos em um use case especial. A figura 3.4.b) modela os use cases Cadastrar obra e Emprestar obra, tendo uma relao de uso com sol_ver_senha (solicita e verifica senha). O objetivo obter procedimentos comuns existentes entre dois ou mais use cases para criar um use case comum, que ser utilizado pelos outros use cases. O modelo de objetos do domnio serve como base comum de entendimento entre todas as pessoas envolvidas no desenvolvimento - analistas, projetistas, especialistas do domnio e usurios . Este modelo engloba os objetos do domnio e os relacionamentos entre eles. 30
Objetos do domnio so aqueles objetos identificados no domnio da aplicao, no fazendo parte os objetos de implementao. A figura 3.5 apresenta parte do modelo de objetos do domnio do sistema de biblioteca. Os objetos do domnio so: Acervo_obras, Obra, Ficha_controle, Cadastro_ttulos, Ficha_ttulo, Ficha_tombo e Ficha_emprstimo. Os relacionamentos so unidirecionais e os que so nomeados consiste-de so um tipo especial chamado de agregao. Pode-se verificar que todos os objetos pertencem ao domnio de uma biblioteca.
Acervo_obras Ficha_controle
consistede [1..N]
rete 1] m[
Obra
consistede [1..N] Ficha_titulo
tem [1..N]
is te -d e [1 ]
retem [0..1] Cadastro_titulos Ficha_tombo
Ficha_emprestimo
Figura 3.5 - Parte do modelo de objetos do domnio
O prximo passo desenvolver o modelo de interface, que criado com as descries de interface, que contero especificaes detalhadas da interface do sistema. Entretanto, o mtodo no apresenta um diagrama mais formal, mas deixa claro que as descries devem estar consistentes, retratando a mesma idia que o desenvolvedor e o usurio tm do sistema. Como sugere os exemplos do livro (Jacobson, 1992), estas descries mostram as telas referentes a cada use case. A figura 3.6 apresenta um exemplo de descrio de interface durante a realizao de um emprstimo, a qual deve acompanhar o use case Emprestar obra.
Figura 3.6 - Descri o de interface
31
co ns
consistede [0..N]
b) Anlise Na anlise desenvolve-se um modelo esttico, o modelo de anlise, que baseado no modelo de requisitos. O modelo de anlise descreve o sistema usando trs tipos de objetos: objeto entidade, objeto de controle e objeto de interface, que garantem a robustez do sistema. O objetivo distribuir o comportamento especificado nas descries de use case entre os trs tipos de objetos do modelo de anlise, sendo que um use case trabalhado por vez. Os objetos entidade so objetos do domnio, os objetos de interface e de controle so uma inveno de objetos que so definidos pelos outros mtodos na fase de projeto. Deste modo, h uma antecipao na definio destes objetos. O mtodo classifica os objetos em trs tipos: objeto entidade onde se armazena toda informao do sistema por um longo tempo, objeto de interface que modela os procedimentos de interface entre o sistema e o usurio e objeto de controle que modela as vrias operaes necessrias (recuperao, atualizao, incluso), realizadas sobre os objetos entidades, retornando resultados aos objetos de interface. A figura 3.7 ilustra os trs tipos de objetos mencionados.
Fichrio_ usurios
Tela de emprstimo
Verificador usurio apto
Ficha_ emprstimo
Ficha_ usurio
Figura 3.7 - Parte do modelo de anlise para o use case - emprestar obra
O objeto Tela de emprstimo um objeto de interface, obtendo dados do usurio e apresentando a ele os resultados (as mensagens) das verificaes necessrias para se fazer o emprstimo. O objeto Verificador usurio apto um objeto de controle que acessa vrios objetos entidade para concluir sua tarefa de verificar se o usurio est apto a fazer emprstimo. Os objetos entidade acessados por este objeto de controle so: fichrio_usurios, ficha_usurio e ficha_emprstimo, que armazenam os dados. Os objetos entidade so exatamente os objetos do domnio identificados durante o desenvolvimento do modelo de objetos do domnio na sub-fase de anlise de requisitos. Assim, os objetos de controle e objetos de interface so considerados extra-domnio, ou seja, so inventados pelo analista, o objetivo facilitar futuras evolues e manutenes no sistema, pois assim o sistema se torna robusto e estvel. (Jacobson, 1992) argumenta, que as mudanas mais comuns em um sistema so de sua funcionalidade ou de sua interface. As modificaes de interface afetam os objetos de interface, entretanto as modificaes de funcionalidade podem afetar os trs tipos de objeto: o objeto de interface quando as funcionalidades esto relacionadas a interface, o objeto entidade quando a 32
funcionalidade est encapsulada no objeto, ou o objeto de controle quando a funcionalidade entre os objetos. Entretanto, segundo (Jacobson, 1992), a maioria das modificaes no afetam os objetos entidade. Juntamente com a identificao dos objetos pode ser feita a identificao dos atributos dos objetos entidades, e modelar como mostra a figura 3.8. Abaixo da representao para os atributos coloca-se qual o seu tipo, e no relacionamento entre o objeto e o atributo coloca-se o nome e a cardinalidade do atributo.
1] tral [
c cod_
adas
string
no me _o br a [1]
a u to r [1 ]
string
Ficha_titulo
qtdd
_tom
bos[
1]
string
numrico
Figura 3.8 - Modelagem dos atributos do objeto entidade - ficha_ttulo
Aps a identificao de todos os objetos no modelo de anlise, so feitas as descries de cada um deles. O mtodo no apresenta um procedimento a ser seguido. A figura 3.9 apresenta a descrio de um objeto de controle, o Concluidor de emprstimo.
Objeto de controle: Concluidor de emprstimo 1o. 2o. 3o. 4o. Adiciona 1 a cota_emprestada no objeto ficha_usurio. Altera o status_obra no objeto ficha_controle. Altera objeto ficha_emprstimo. Altera dt_devoluo no objeto ficha_tombo.
Figura 3.9 - Descri o do objeto de controle - concluidor de emprstimo
As descries contm o que cada objeto faz de acordo com o seguinte: i) ii) objeto entidade: quais dados armazena e quais mtodos oferece; objeto de controle: acessar outros objetos fazendo verificaes ou buscando dados (objetos entidade) ou devolvendo o controle (objetos de interface);
iii) objeto de interface: solicitar verificaes e mostrar dados aos usurios. Depois que todos os modelos estiverem prontos e todos os objetos definidos necessrio a identificao de subsistemas, para que se possa reduzir a complexidade. Um subsistema pode ser composto por outro subsistema, como a idia de recurso, at que se obtenha unidades atmicas. O objetivo ter um forte acoplamento funcional dentro do subsistema e um fraco acoplamento entre os subsistemas, caracterizando que a identificao do subsistema est correta. 33
c) Projeto Na fase de projeto desenvolvido um modelo esttico, denominado modelo de projeto. Este modelo refina o modelo de anlise, definindo a interface dos objetos e tambm a semntica das operaes e decidindo sobre aspectos do ambiente de implementao atual. Como exemplo pode-se citar: banco de dados a ser utilizado, verificar se a linguagem de programao suporta tudo que foi modelado na anlise (especialmente associao de herana), dividir os blocos para distribu-los no computador. A figura 3.10 apresenta parte do modelo de projeto referente a parte do modelo de anlise apresentado na figura 3.7, onde foi feita somente a passagem da anlise para o projeto sem consideraes do ambiente atual.
Fichrio_ usurios
Tela de emprstimo
Ficha_ usurio Ficha_ emprstimo
Figura 3.10 - Parte do modelo de projeto
Durante o projeto, a modelagem dinmica representa a comunicao entre os objetos envio de mensagens - que pertencem a determinado use case, gerando o diagrama de interao. Portanto, tem-se um diagrama de interao para cada use case identificado.
Tela emprstimo Fronteira Verificador usurio apto Fichrio_ usuarios Ficha_ emprstimo
Ficha_ usurio
Solicita emprstimo de obra Solicita e informa nmero de cadastro

loc_usu(nr_cadastro)
Verifica se usurio est apto a fazer emprstimo
verif_lim_empr verif_divida verif_dt_dev ok
Usurio apto
Figura 3.11 - Parte do diagrama de intera o para o use case - emprestar obra
34
Atravs da figura 3.11 pode-se observar a descrio textual das mensagens e sinais do lado esquerdo e os objetos (de controle, de interface e entidade) na parte superior do diagrama. Os sinais, que ocorrem entre processos, esto representados por tudo que acontece entre a fronteira do sistema e o objeto de interface Tela de emprstimo, e entre esse e o objeto de controle Verificador de usurio apto. O restante so as mensagens entre o objeto de controle e os objetos entidade, que ocorrem dentro do processo. Os nomes que vo acima das mensagens so as operaes a serem ativadas e entre parnteses seus parmetros. Aps a criao dos diagramas de interao para todos os use cases, possvel identificar as operaes de cada objeto atravs desses diagramas. Por exemplo, para o diagrama da figura 3.11, o objeto Ficha_usurio tem as operaes verif_lim_empr e verif_dvida. Alm do diagrama de interao, ainda na fase de projeto, so criados os grafos de transio de estado. Eles fornecem uma descrio simplificada dos blocos, que menos dependente da linguagem de programao escolhida, o que aumenta o entendimento do bloco, porque no necessrio descer ao nvel do cdigo. (Jacobson, 1992) sugere quatro formas diferentes para se desenvolver os grafos: duas formas grficas simples e comuns (utilizadas por outros autores), uma forma descritiva e uma forma grfica detalhada, que adotada para exemplos do livro. Um exemplo apresentado pela figura 3.12.
Obra
Criar
Disponvel
Solicita emprest.
Solicita uso
Emprestado
usurio apto e tombo disponvel
__
Devolve emprest.
N
__
Disponvel
Figura 3.12 - Parte do grafo de transi o de estado do objeto: Obra
O objeto Obra criado e passa para o estado Disponvel. Se algum usurio solicitar o uso, ento a obra volta ao estado Disponvel. Se um usurio solicita emprstimo, feita verificao de usurio e tombo. Se o usurio no estiver apto ou o tombo no estiver disponvel, ento a Obra 35
continua no estado Disponvel. Se o usurio estiver apto e o tombo estiver disponvel, ento a Obra passa ao estado Emprestado. Quando a Obra devolvida, o objeto passa ao estado Disponvel. d) Outras Este mtodo, como j mencionado, aborda as fases de implementao e teste, que no sero levadas em considerao para o estudo nem comparao por no ser comum em todos os mtodos. A fase de implementao a transformao do modelo de projeto em linguagem de programao (cdigos fontes) e durante a fase de teste, tem-se trs etapas: o teste de unidades para verificar se as funes e procedimentos esto corretos, o teste de integrao para testar se as diferentes unidades esto trabalhando juntas com sucesso e o teste de sistema para verificar se o sistema funciona como um todo.
3.3.4
Transio entre as fases
(Jacobson, 1992) argumenta que: A transio do modelo de anlise para o modelo de projeto deve ser feita quando as conseqncias do ambiente de implementao comearem a aparecer. Embora essa transio no seja clara, muitas vezes, o analista deve observar quando os aspectos do ambiente de implementao comeam a influenciar a anlise, tais como: "a linguagem no implementa este recurso!", ou ainda, "o hardware no suporta essa implementao!"; neste caso deve-se iniciar o projeto. importante notar que o mtodo OOSE sugere que os objetos da anlise se tornem objetos de projetos (blocos) e, consequentemente, de cdigo fonte. Assim, existir a rastreabilidade entre os modelos facilitando uma futura manuteno.
3.3.5
Aplicabilidade
O mtodo pode ser aplicado para o desenvolvimento de sistemas tcnicos e administrativos, reutilizando descries e componentes j definidos. Ele tambm apresenta caractersticas favorveis a sistemas que necessitem da participao de usurios e especialistas do domnio no detalhamento dos requisitos, devido a utilizao de use cases, atores e diagramas de interao. O mtodo indicado para sistemas com o enfoque principal em suas funcionalidades, onde o modelo use case ser de grande utilidade, por ter todo o processo baseado nessas funcionalidades e possuir sinttica e semntica rica para modelagem. Alm disso, o mtodo pode ser utilizado no desenvolvimento de sistemas reais de grande porte, por isso indicado para ser usado por uma equipe de desenvolvimento e no por um nico desenvolvedor. um mtodo abrangente com sinttica e semntica bem especfica em cada fase do desenvolvimento, sendo que as equipes devem ter treinamento em anlise de requisitos, anlise, projeto e programao.
36
3.3.6
Pontos positivos
A utilizao de trs tipos de objetos facilita evolues e modificaes futuras no sistema, pois o sistema se torna robusto e estvel tendo poucas modificaes nos objetos do domnio. Outro ponto que vale destacar, refere-se ao diagrama de interao, que possui descries textuais no lado esquerdo ao grfico, facilitando sua compreenso. Existe tambm, a distino entre uma mensagem, enviada dentro de um processo, e um sinal enviado entre dois processos. O interessante do grafo de transio de estado que, alm de se perceber os estados possveis do objeto, tambm pode-se ver claramente as aes executadas nas transies de estados e as condies para as transies.
3.3.7
Pontos negativos
A notao de atributos utilizada pelo mtodo , sem dvida, algo que aumenta a complexidade do modelo. No sendo vivel a visualizao de todos os atributos dos objetos em um mesmo modelo, porque torna-se difcil a visualizao do modelo como um todo. O mtodo OOSE muito extenso, englobando anlise (incluindo anlise de requisitos), projeto, implementao e teste. Isso na verdade, pode se tornar um ponto negativo ou positivo, dependendo do desenvolvimento. Ser um ponto negativo, quando se tem: um sistema muito simples, uma equipe de desenvolvimento inexperiente ou um nico desenvolvedor. Ser um ponto positivo, quando se tem um sistema muito grande e complexo, necessitando ser bem especificado e documentado. O mtodo no prescritivo, ou seja, no fornece passos a serem seguidos para facilitar o seu uso. Alm disso, necessrio muito estudo para se compreender os conceitos adotados e os objetivos de cada modelo. Um ponto no muito claro, diz respeito a utilizao da palavra objeto para discriminar tanto o conceito de objeto como o de classe. Existem partes da descrio do mtodo em que difcil perceber quando o autor se refere a classe, a uma instncia (um objeto) ou as instncias da classe (referindo a todos os objetos instanciados de uma classe).
3.4.1
OMT - Object Modeling Technique um mtodo orientado a objeto, desenvolvido por James Rumbaugh, Michael Blaha, Willian Premerlani, Frederick Eddy e Willian Lorensen em 1991. As bases para a notao do OMT foram desenvolvidas a mais de 10 anos (antes de 1988) com Mary Loomis e Ashwin Shah da Corporao Calma (Rational, 1997). Esse mtodo aborda as fases de anlise, projeto e implementao, como mostra a figura 3.13. A fase de anlise produz trs modelos: modelo de objetos, modelo dinmico e modelo 37
9 7 0 3 1 (& " 8(654' 20)'%$!# !

Descrio
funcional. A fase de projeto dividida em projeto de objeto e projeto do sistema, que estende os modelos de anlise com detalhes de projeto.
Modelo de Objetos Modelo Dinmico Modelo Funcional
Anlise
Projeto
Projeto do Sistema Projeto de Objetos
Implementao
Figura 3.13 - OMT - Object Modeling Technique (Coleman, 1996)
3.4.2
Caractersticas
A abordagem utilizada pelo mtodo a orientada a dados, pois no incio do desenvolvimento o mtodo se preocupa, principalmente, com a identificao dos atributos das classes, s se preocupando com as operaes na fase de projeto. O foco desse mtodo est na fase de anlise, onde se obtm um grande conjunto de modelos e diagramas e uma seqncia de passos a serem seguidos, que facilitam a modelagem nesta fase. (Rumbaugh, 1994) apresenta os conceitos de orientao a objetos com timas explicaes e bastante exemplificaes, o que facilita o estudo dos leigos na rea de orientao a objetos.
3.4.3
Fases
a) Anlise de requisitos Este mtodo no possui modelos e/ou diagramas para a modelagem da anlise de requisitos, devido ao fato de que os requisitos devem ser informados pelo usurio sem assistncia do mtodo. b) Anlise A modelagem esttica na anlise feita atravs do modelo de objetos, que representado graficamente pelo diagrama de objetos. Este diagrama apresenta a notao grfica para modelagem 38
de objetos e os relacionamentos entre eles. O diagrama de classes e o diagrama de instncias so tipos de modelo de objetos. O primeiro modela as classes do domnio do problema e o segundo descreve como os objetos se relacionam. Portanto, um dado diagrama de classes pode gerar um conjunto infinito de diagramas de instncias (Rumbaugh, 1994), o que depende da quantidade de instncias de cada classe. A figura 3.14 ilustra um exemplo de parte do diagrama de classes desenvolvido para o sistema de biblioteca. Este diagrama descreve as classes (ex.: Ficha_ttulo), os relacionamentos simples (ex.: tem), agregao, herana, cardinalidade, os atributos, restries e ordenaes.
Obra nome_obra autor 1+ tem Ficha_ttulo nome_obra autor qtdd_tombos
tem Ficha_tombo nr_tombo dt_devoluo
1+ Ficha_controle nr_tombo cod_emprestante status_tombo
Figura 3.14 - Parte do diagrama de classes
A figura 3.15 apresenta o diagrama de instncias referente ao diagrama de classes, ilustrado pela figura 3.14. No diagrama de instncias modelado alm dos valores dos objetos, a quantidade de objetos de um relacionamento com cardinalidade 1+ (expresso no diagrama de classes). Por exemplo, vrias Obras iguais possuem uma Ficha_ttulo.
(Obra) Engenharia de Software Pressman (Obra) Engenharia de Software Pressman
tem
tem
(Ficha_tombo) 15691 -
(Ficha_ttulo) 1569 Engenharia de Software Pressman 2
(Ficha_tombo) 15692 16/03/1998
tem
(Ficha_controle) 15691 D
(Ficha_controle) 15692 Joo E
tem
Figura 3.15 - Parte do diagrama de instncias
39
No diagrama de instncias so colocados todos os relacionamentos existentes entre os objetos, ou seja, entre as instncias das classes que foram definidas no diagrama de classes. Pode-se obter um diagrama bastante complexo dependendo da estrutura das classes, pois uma classe, geralmente, possui vrias instncias. Ainda durante a anlise necessrio a criao de um dicionrio de dados, onde todas as classes so descritas quanto a sua abrangncia no problema, suas restries e seu uso. Alm disso, as associaes, os atributos e as operaes tambm so descritos, entretanto, o mtodo no apresenta um modelo a ser seguido. Durante a fase de anlise so criados quatro diagramas para se fazer a modelagem dinmica, so eles: cenrios, diagramas de eventos, diagrama de fluxo de eventos e diagrama de estado. Primeiro, so desenvolvidos os cenrios contendo a seqncia de eventos, que so intercambiados entre o sistema e um agente externo, descrita de forma textual. Os primeiros cenrios so desenvolvidos abrangendo os casos normais, depois h um refinamento, acrescentando, gradualmente, omisso e repetio de dados, e depois os erros e valores invlidos. A figura 3.16.a) apresenta um cenrio relatando uma seqncia normal para o emprstimo de obras, e a figura 3.16.b) ilustra a seqncia do emprstimo com um certo refinamento, apresentando valores invlidos e mensagens de erro.
Funcionrio solicita emprstimo. SB solicita nr_cadastro; usurio_cadastrado informa nr_cadastro. SB solicita cod_cadastral da obra; o usurio_cadastrado informa cod_cadastral da obra. SB solicita senha do usurio; usurio_cadastrado informa senha. SB libera obra.
a) Normal
Funcionrio solicita emprstimo. SB solicita nr_cadastro; usurio_cadastrado informa nr_cadastro. nr_cadastro invlido. usurio no est permitido a fazer emprstimo. SB solicita cod_cadastral da obra; o usurio_cadastrado informa cod_cadastral da obra. cod_cadastral invlido. tombo no disponvel. SB solicita senha do usurio; usurio_cadastrado informa senha. senha invlida. SB libera obra.
b) Refinado
Figura 3.16 - Cenrios - a) Normal e b) Refinado
Os cenrios so representados graficamente atravs dos diagramas de eventos, onde os objetos so representados por uma linha vertical e os eventos por setas que interligam esses objetos do emissor para o receptor. Este diagrama, assim como o cenrio, preocupa-se com a seqncia dos eventos. A figura 3.17 ilustra parte do diagrama de eventos do sistema de biblioteca, que refere-se a figura 3.16. 40
Usurio_ cadastrado
solicita nr_cadastro informa nr_cadastro
Sistema Biblioteca
solicita emprstimo
Funcionrio
nr_cadastro invlido usurio no est permitido a fazer emprstimo solicita cod_cadastral informa cod_cadastral cod_cadastral invlido tombo no disponvel solicita senha do usurio informa senha do usurio senha invlida libera obra
Figura 3.17 - Parte do diagrama de eventos
Todos os eventos de todos os diagramas de eventos so agrupados em um diagrama chamado diagrama de fluxo de eventos, ilustrado pela figura 3.18, o qual no se preocupa com a seqncia. Seu objetivo visualizar todos os eventos existentes entre os sistema e os agentes externos.
Usurio_ cadastrado
informa nr_cadastro informa cod_cadastral informa senha do usurio
Sistema Biblioteca
solicita nr_cadastro nr_cadastro invlido usurio no est permitido a fazer emprstimo solicita cod_cadastral cod_cadastral invlido tombo no disponvel solicita senha do usurio senha invlida libera obra
solicita emprstimo
Funcionrio
Figura 3.18 - Parte do diagrama de fluxo de eventos
41
Em seguida, para cada classe que possuir um comportamento dinmico significativo, ser construdo um diagrama de estados, que modela os estados possveis que os objetos de uma classe pode ter e os eventos, condies, aes e atividades que se relacionam ao estado. A figura 3.19 apresenta parte do diagrama de estado para a classe Obra. um diagrama bastante completo em comparao aos outros mtodos. Ele apresenta, alm dos estados, os seguintes itens: i) transies, eventos e condies, ii) as aes nas transies, os atributos de cada evento e as aes internas de entrada, de sada e os eventos que ocorrem dentro do estado sem mudana de estado, iii) as atividades tambm podem ser expressas dentro do estado.
solicita_uso (nr_tombo) solicita_emprstimo (nr_tombo, nr_cadastro, senha_usu) [usurio_apto e tombo_disponvel] / cota_emprestada + 1 cria_ficha (nr_tombo,' ',d)
Disponvel entrada / atu_status('D')
devolve_emprestimo(nr_tombo) / cota_emprestada + 1 empr_perde_obra (nr-tombo)
Emprestado entrada / atu_status('E')
func_encontra_obra (nr_tombo)
func_perde_obra (nr_tombo)
Extraviado entrada / atu_status('X')

destroi_ficha (nr_tombo)
empr_encontra_obra (nr_tombo)
Figura 3.19 - Parte do diagrama de estado para a classe obra
Durante a anlise, no que tange a modelagem funcional so utilizados um diagrama para mostrar os valores de entrada e de sada do sistema, um diagrama de fluxo de dados (DFD) e as descries destas funes. O primeiro DFD mostra os valores de entrada e de sada do sistema, os quais so parmetros dos eventos existentes entre o sistema e o mundo externo. um diagrama simples, que parece at ser redundante se for observado o diagrama de eventos, j que os eventos neles identificados, so seguidos por seus parmetros. Posteriormente, so construdos os DFD's em nveis, sendo que o DFD de nvel mais alto o mais genrico. O objetivo mostrar a origem dos valores de dados, sua transformao pelos processos e seus destinos (os objetos). Este diagrama no mostra deciso ou seqncia de operaes. Com os DFD's prontos, necessria a descrio de cada uma das funes. (Rumbaugh,1994) sugere vrias maneiras para descrever as funes: linguagem natural, equaes matemticas, pseudocdigo, tabela de decises ou alguma outra forma. 42
Vale destacar que houve tentativas de modelagem de um diagrama de fluxo de dados (DFD) para parte do sistema de biblioteca, no havendo sucesso, pois o sistema possui pouca transformao de dados. Entretanto, atravs da figura 3.20 pode-se ter uma idia de um DFD.
verificar
senha codificada senha OK
Conta
saldo
senha valor
Cliente
dinheiro
atualizar
Figura 3.20 - DFD para uma retirada bancria (Rumbaugh, 1994)
A figura 3.20 descreve a retirada de dinheiro de um banco, mediante a verificao de senha, informada pelo cliente e a atualizao do saldo decrementado de acordo com o valor solicitado pelo cliente. Este processo s ser executado se a senha estiver correta. Somente durante a anlise h modelagem de interface, que possui duas partes: interface com o usurio e lgica da aplicao. A primeira parte modela as telas de interface com o usurio sem se preocupar com a lgica. O objetivo verificar que nada importante ficou esquecido. A segunda parte modela a dinmica, a seqncia de interao entre o usurio e as telas e a seqncia entre as telas. Os trs modelos so elaborados abrangendo trs vises do sistema. Nem sempre haver necessidade ou condies de se obter os trs modelos, pois isso depender do sistema que se est modelando. No caso do exemplo da biblioteca, foi til a criao dos modelos de objetos e dinmico, j no sendo possvel a criao do modelo funcional. c) Projeto Durante o projeto do sistema que possui oito etapas, a modelagem funcional est presente na primeira etapa do projeto. A modelagem dinmica feita durante a segunda, a terceira, a quinta, a sexta e a stima etapas, e a modelagem esttica feita pela quarta e oitava etapas, devendo ser todas documentadas. Entretanto, o mtodo no fornece diretrizes para se fazer essa documentao. O mtodo tambm no oferece modelos grficos nem textuais para se modelar o projeto do sistema. O projeto do sistema inicia-se com a subdiviso do sistema em subsistemas sendo cada um desses composto por elementos que possuem as mesmas caractersticas: funcionalidade, localizao fsica ou execuo em mesmo hardware. O fluxo de informaes existente entre os subsistemas so apresentados em um DFD. importante notar que esse fluxo de informaes deve ser baixo, pois se houver muita dependncia entre os subsistemas, provavelmente eles formam um nico subsistema.
43
Os subsistemas para o sistema de biblioteca poderiam ser: emprstimos, reservas, pesquisas, cadastros e emisso de relatrios. A segunda etapa do projeto do sistema identifica as concorrncias inerentes, que ocorre quando dois objetos recebem eventos ao mesmo tempo sem interagirem. (Rumbaugh, 1994) indica o modelo dinmico - o diagrama de estados - como base para essa identificao. A terceira etapa do projeto do sistema a alocao dos subsistemas aos processadores, verificando quatro itens: i) decidir se sero necessrios vrios processadores, ii) decidir se a implementao ser em hardware ou em software, iii) alocar os subsistemas aos processadores, observando a satisfao das necessidades de desempenho e a diminuio da comunicao interprocessadores e iv) organizar a conectividade fsica desses processadores. A quarta etapa do projeto do sistema consiste em decidir sobre armazenamento dos dados, se ser utilizado um SGBD (Sistema Gerenciador de Banco de Dados) ou arquivos simples. Os autores do mtodo discutem as vantagens e desvantagens de se usar um ou outro. A quinta etapa do projeto do sistema consiste em identificar recursos como: unidades fsicas, espao, nomes lgicos e acesso a dados compartilhados e determinar mecanismos para controlar o acesso a eles. A sexta etapa do projeto do sistema trata da escolha de uma implementao de controle de software. Existem dois tipos de controle: externo e interno. O controle seqencial baseado em procedimento, seqencial baseado em eventos ou concorrente so tipos de controle externo. E os controles internos so: chamadas de procedimentos, chamadas intertarefas quase concorrentes e chamadas intertarefas concorrentes. Os autores advertem que os subsistemas podem ser implementados de maneiras diferentes, entretanto, o projetista, geralmente, adota uma nica. A stima etapa do projeto do sistema consiste em tratar as condies extremas do sistema, tais como: inicializao (de constantes, parmetros, variveis globais, objetos, etc.), trmino (liberar recursos externos) e falhas (tratar qualquer trmino inesperado do processamento do sistema). A oitava etapa do projeto do sistema consiste em estabelecer prioridades em relao a vrios aspectos: memria, tempo, espao, hardware, software, eficincia e manutenibilidade. O objetivo fazer um balanceamento adequado entre esses aspectos a fim de obter uma arquitetura consistente, sem desperdcios. s vezes, um aspecto pode ser sacrificado a fim de valorizar outro. O projeto de objetos possui oito etapas, a modelagem esttica est presente da primeira a terceira etapa e a modelagem dinmica auxilia da quarta a ltima etapa. Estas etapas devem ser documentadas, contudo, o mtodo no fornece diretrizes para se fazer essa documentao. O projeto de objetos inicia-se com a identificao das operaes das classes para atualizao do diagrama de classes, que foi transportado da anlise para o projeto de objetos. Esta identificao feita com a ajuda das aes e atividades do modelo dinmico - diagrama de estados e dos processos do modelo funcional. A figura 3.21 ilustra o diagrama de classes referente ao da anlise representado pela figura 3.14, com o acrscimo das operaes colocadas na parte inferior da classe, por exemplo: obter_qtdd_tombos ( ) da classe Ficha_tombo e obter_nr_tombo ( ) da classe Ficha_tombo. 44
Obra nome_obra autor 1+
tem
Ficha_ttulo nome_obra autor qtdd_tombos obter_qtdd_tombos( )
tem 1+ Ficha_tombo nr_tombo dt_devoluo atu_dt(data) obter_nr_tombo( ) Ficha_controle nr_tombo cod_emprestante status_tombo obter_status_tombo( ) atu_status(st) obter_nr_tombo( )
Figura 3.21 - Parte do diagrama de classe
O projeto de objetos prossegue com a definio de cada operao do modelo funcional na forma de um algoritmo. Para tanto, levado em considerao: i) a escolha do algoritmo que minimize o custo da implementao das operaes, ou seja, verificado a necessidade de um algoritmo complexo ou simples e sua eficincia, ii) a escolha da estrutura de dados para a implementao do algoritmo, iii) definio de classes e operaes internas, que acontece quando se faz a especificao das operaes, pois novas classes podem ser necessrias para o armazenamento de resultados intermedirios e novas operaes podem surgir da decomposio das operaes de alto nvel e iv) atribuir as operaes aos objetos alvos verdadeiros, pois muitas vezes, uma operao pode afetar mais de um objeto. A terceira etapa do projeto de objetos consiste em otimizar o projeto, obtendo um equilbrio entre a eficincia e a clareza. As diretrizes so: acrescentar associaes redundantes com a criao de ndices; reorganizar a ordem de execuo de um algoritmo para melhorar a eficincia e armazenar atributos derivados do processamento de outros atributos para evitar o reprocessamento, que devem ser atualizados sempre que os atributos base forem alterados. A quarta etapa do projeto de objetos trata da implementao do controle, ou seja, da implementao do modelo dinmico definido na anlise, definindo se ser utilizado um sistema baseado em procedimento, um sistema baseado em eventos ou tarefas concorrentes. Nesta etapa acrescenta-se detalhes ao que foi definido no projeto do sistema. A quinta etapa do projeto de objetos faz o ajustamento de herana, observando: i) as operaes idnticas entre as classes e que podem ser colocadas em uma classe comum ii) os comportamentos comuns para coloc-los em uma superclasse, deixando as especialidades para a subclasse, com isso a superclasse poder ser reaproveitada em outros projetos e iii) a utilizao da delegao ao invs da herana, para evitar o uso incorreto desta quando uma subclasse no uma forma da superclasse em todos os aspectos. 45
A sexta etapa do projeto de objetos consiste em formular uma estratgia para a implementao das associaes, se elas sero bidirecionais ou com apenas uma direo, o que a torna mais simples. Contudo, importante verificar se os requisitos no sero alterados, necessitando que a implementao seja bidirecional. Vrias estratgias, que podem ser encontradas em (Rumbaugh, 1994). A stima etapa do projeto de objetos trata da representao de objetos, porque embora as classes tenham sido modeladas a nvel de outras classes, tudo deve ser implementado em termos de tipos de dados primitivos: inteiros, strings, tipos enumerados. A oitava etapa do projeto de objetos consiste em fazer o empacotamento fsico (de programas), observando: i) ocultamento de informaes (de atributos e alguns mtodos) para determinar a visibilidade dos mtodos; ii) coerncia de entidades para verificar se as entidades no modelam vrios propsitos ao mesmo tempo, fazendo separao entre a implementao (execuo de algoritmos) e a poltica (tomada de decises), o que aumenta o reuso; e iii) construo de mdulos para facilitar o trabalho em equipes e para que futuras modificaes afetem poucos mdulos, deste modo, as classes de um mdulo devem estar ligadas e terem o mesmo propsito.
3.4.4
O mtodo inicia-se com os clientes e talvez os desenvolvedores gerando o enunciado do problema, que pode ser inconsistente, incompleto e informal. Por isso, a anlise do sistema realizada tentando tornar esse enunciado em verdadeiros requisitos. Os autores do mtodo sugerem que ao terminar a modelagem do sistema, nas trs dimenses apresentadas - esttica, dinmica e funcional -, seja feita uma checagem entre os modelos para excluir erros e inconsistncias refazendo, se necessrio, alguns desses modelos para torn-los corretos. Quando estiverem corretos, os requisitos sero atualizados e/ou redefinidos e isto ser discutido com o cliente para verificar se o que se deseja.
3.4.5
Aplicabilidade
O mtodo OMT uma boa opo para analistas experientes em modelagem com mtodos estruturados de anlise (sem muita experincia em programao), pois o seu enfoque na abstrao do domnio do problema e no na implementao. Isso facilita o trabalho dos analistas com vrias opes de representao das associaes entre objetos. Esse mtodo no uma boa opo para programadores que estejam aprendendo a modelar, porque o seu enfoque no direcionado s linguagens de implementao, mas sim s abstraes de alto nvel. Os programadores tendem a querer mapear as representaes de anlise para algo no domnio de implementao, mas os modelos de anlise no tm este objetivo, gerando alguma confuso nos primeiros projetos.
46
3.4.6
Pontos positivos
O mtodo OMT possui uma tima explanao sobre os conceitos de orientao a objetos. Isso auxilia bastante a compreenso do mtodo. O mtodo tambm possui uma extensa notao para a anlise com riqueza sinttica e semntica, que facilita a modelagem de uma variedade de sistemas. Trs representaes permitem que o modelo de objetos se torne mais claro quanto as associaes entre as classes, so eles: atributos de ligao, associao ternria e qualificao (j explicados no captulo 2). Durante a fase de anlise, o mtodo bastante prescritivo, o que facilita o desenvolvimento dos modelos e diagramas, que permitem uma boa abstrao do que o sistema deve fazer, porque oferece uma seqncia de passos bem definidos.
3.4.7
Pontos negativos
Deveria haver alguma modelagem para auxiliar os desenvolvedores na identificao dos requisitos do sistema juntamente com os usurios. Durante a fase de projeto, o mtodo OMT deixa muito a desejar, por no possuir a mesma riqueza sinttica e semntica utilizada na anlise. So fornecidas apenas sugestes, passos a serem seguidos, de como evoluir os modelos de anlise para os de projeto, contudo, no h exemplificaes do que est sendo sugerido, o que dificulta o estudo e aplicao do mesmo. O diagrama de instncia bastante simples comparado ao que os outros mtodos oferecem.
3.5.1
OOAD - Object Oriented Analysis and Design - Anlise e Projeto Orientado a Objeto, um mtodo orientado a objeto desenvolvido por Grady Booch. Esse mtodo foi inicialmente criado somente com o micro processo, recebendo o nome de OOD (Object Oriented Design), sendo apresentado em (Booch, 1991). Em (Booch, 1994), ele incorpora ao seu mtodo o macro processo e o renomeia para OOAD. Assim, o mtodo OOAD composto pelo macro processo e pelo micro processo. O micro processo a descrio das atividades dirias de um nico desenvolvedor ou pequeno grupo de desenvolvedores de software. A figura 3.22 ilustra o micro processo que abrange quatro atividades descritas abaixo. a) identificao de classes e objetos para estabelecer os limites do problema, identificando as classes e objetos do domnio do problema, esta uma fase de descobrimento. b) identificao da semntica das classes e objetos para estabelecer os atributos e as operaes da cada abstrao identificada anteriormente, fazendo uma distribuio adequada.
'DC 9BA0@2(986 531 )(%&%# ! $ 7 ' 7$ 7 4 2 ' 0 ' $ "

Descrio
47
c) identificao dos relacionamentos entre classes e objetos para definir os limites das abstraes e reconhecer os colaboradores de cada abstrao identificada nas fases anteriores. d) implementao de classes e objetos para representar cada abstrao e mecanismos concretamente de maneira mais eficiente.
Identificao de classes e objetos
Implementao de classes e objetos
Identificao da semntica das classes e objetos
Identificao dos relacionamentos entre classes e objetos
Figura 3.22 - Micro processo (Booch, 1994)
O macro processo serve como uma estrutura de controle para o micro processo. A principal preocupao do macro processo com o gerenciamento tcnico da equipe de desenvolvimento e com prticas bsicas tais como: gerncia de configurao, garantia de qualidade, ensaios de cdigo e documentao. As fases do macro processo so: conceitualizao, anlise, projeto, evoluo e manuteno. A figura 3.23 ilustra a abordagem adotada pelo mtodo, que consiste em aplicar as atividades do micro processo dentro de cada fase do macro processo, permitindo o refinamento dos modelos a cada fase. A filosofia bsica do macro processo o desenvolvimento incremental (Booch, 1994).
Anlise Conceitualizao
Projeto
Manuteno Evoluo
Figura 3.23 - Macro processo (Booch, 1994)
48
3.5.2
Caractersticas
O mtodo adota a abordagem orientada a comportamento, onde a preocupao bsica est com as operaes do sistema. A primeira verso do mtodo fazia meno somente a modelos de projeto. Na segunda verso houve amadurecimento dos modelos de projeto e incluso dos modelos de anlise. Assim, seu foco est na fase de projeto pela riqueza sinttica e semntica. Para todos os diagramas sugeridos pelo mtodo - diagrama de classe, diagrama de objeto, diagrama de interao, diagrama de transio de estado, diagrama de mdulo e diagrama de processo -, descritos na prxima sesso, deve ser feita uma especificao de forma textual podendo seguir o modelo que sugerido pelo mtodo em (Booch, 1994).
3.5.3
Fases
a) Anlise de requisitos A anlise de requisitos denominada por (Booch, 1994) de conceitualizao e tem o propsito de estabelecer o ncleo dos requisitos do sistema. Nem todos os projetos requerem esta fase. No apresentada nenhuma modelagem para essa fase, todavia uma prototipao indicada para fazer levantamento dos requisitos do sistema. Especialmente se o sistema for de grande escala, pois melhor descobrir o quanto antes que as funcionalidades, performance, tamanho e complexidade esto erradas, do que em fases futuras quando o impacto tcnico e financeiro maior. b) Anlise Na anlise a identificao de classes e objetos aplicada para descobrir as abstraes que formam o vocabulrio do domnio do problema, para comear a restringi-lo, decidindo o que e o que no de interesse. A identificao da semntica das classes e objetos aplicada para alocar as responsabilidades a diferentes procedimentos do sistema. A identificao dos relacionamentos entre classes e objetos aplicada para especificar associaes entre classes e objetos (incluindo certos relacionamentos importantes de herana e agregao), as quais especificam alguma dependncia semntica entre duas abstraes e alguma habilidade de navegar de uma entidade para outra. A implementao de classes e objetos aplicada para fornecer um refinamento de abstraes existentes o suficiente para revelar novas classes e objetos no prximo nvel de abstrao. Nesta fase, desenvolvem-se os cenrios que capturam as descries das funes do sistema. So desenvolvidos os cenrios bsicos para ilustrar os procedimentos principais e cenrios secundrios para mostrar procedimentos sob condies especiais. A modelagem de um cenrio foi incorporada ao mtodo tendo como base as definies feitas por (Jacobson, 1992) no que diz respeito as descries de um use case, portanto um exemplo pode ser encontrado na figura 3.3.
49
Como complementao aos cenrios, so desenvolvidos os diagramas de objeto, que apresentam os objetos que colaboram para realizar um determinado cenrio e a interao entre eles atravs da passagem de mensagens. Como este diagrama ser acrescido de detalhes na fase de projeto, sua descrio mais detalhada e uma exemplificao encontram-se no item c) dessa seo. Os cenrios podem ser representados pelo diagramas de interao, assim como pelos diagramas de objetos. Todavia, estes so mais abrangentes do que aqueles. A vantagem de se construir o diagrama de interao, que com ele mais fcil de compreender a passagem e a seqncia de mensagens entre os objetos. Se este diagrama se tornar muito complexo, pode-se incluir scripts (descries) do lado esquerdo do diagrama, descrevendo de forma textual a interao entre os objetos. A figura 3.24 apresenta parte do diagrama de interao para o cenrio emprestar obra. Os objetos esto na parte superior da figura, as descries na parte esquerda e as mensagens esto entre os objetos.
: Fichrio_ usuarios : Verificador_ usurio : Ficha_ emprstimo
: Ficha_ usurio
Verifica se usurio est apto a fazer emprstimo
verif_lim_empr verif_divida verif_dt_dev
Figura 3.24 - Parte do diagrama de intera o - cenrio emprestar obra
Adicionalmente, so includos diagramas de classes apresentando as classes que formam o domnio do problema e seus relacionamentos - os dois componentes essenciais deste diagrama -. um diagrama esttico e bastante rico em notao, porque vrios aspectos podem ser modelados, tais como: metaclasse, classe parametrizada, contedo fsico, restries, chaves, papis, atributos de associao e notas, alm dos essenciais citados anteriormente.
Ficha-ttulo nome_obra autor qttd_tombos
Obra nome_obra autor
tem 1..N
Ficha-tombo | | dt_devolucao atu_dt (data ) obter_nr_tombo ( )
tem
Ficha-controle | | cod_emprestante 1..N [ nr_tombo ] | | status_tombo | | atu_status (st )
Figura 3.25 - Parte do diagrama de classe
50
Esta ficha deve informar o estado do livro e o cdigo do emprestante, quando for o caso.
A figura 3.25 apresenta parte do diagrama de classe para o sistema de biblioteca, que modela as classes, uma nota para descrever algo importante, seus relacionamentos simples e de agregao com contedo fsico por valor. Isso significa, por exemplo, que se a Ficha_ttulo for excluda todas as Ficha_controle referente quela sero excludas tambm. c) Projeto No projeto a identificao de classes e objetos serve para descobrir abstraes que so elementos da soluo. A identificao da semntica das classes e objetos serve para conseguir uma separao clara de relaes entre as partes da soluo. A identificao dos relacionamentos entre classes e objetos serve para especificar colaboraes que formam os mecanismos de nossa arquitetura e para agrupar as classes de mais alto nvel em categorias e mdulos dentro de subsistemas. A implementao de classes e objetos aplicada para criar representaes tangveis das abstraes no suporte de sucessivos refinamentos de verses executveis no macro processo. O propsito do projeto criar uma arquitetura, baseando-se no procedimento que o modelo de anlise requer, para desenvolver a implementao e para estabelecer uma poltica ttica comum que deve ser usada para disparar elementos comuns do sistema. O projeto arquitetural s pode comear quando a equipe de desenvolvimento tem um entendimento razovel dos requisitos do sistema. O projeto focaliza a estrutura tanto esttica como dinmica. Anlise mais aprofundada pode ocorrer durante a fase de projeto, principalmente para explorar reas de incerteza a respeito do comportamento desejado do sistema. Contudo, o projeto serve, principalmente, para criar o esqueleto concreto sobre o qual todo o resto da implementao se projeta. Durante o projeto feita uma descrio da arquitetura, utilizando os diagramas de classes e os diagramas de objetos para mostrar as estruturas das classes e dos objetos, respectivamente, destacando o agrupamento das classes em categorias de classes (arquitetura lgica), e dos mdulos aos subsistemas (arquitetura fsica). O diagrama de objetos proposto por (Booch, 1994) o mais completo do que os propostos pelos demais mtodos aqui estudados (por ex.: OMT - diagrama de instncias). Este diagrama, alm de apresentar os objetos das classes e seus relacionamentos, modela a visibilidade entre os objetos e a sincronizao das mensagens intercambiadas entre os objetos. Os diagramas de objetos so constitudos dos objetos e seus relacionamentos, e so utilizados para complementar os cenrios. Estes diagramas apresentam a situao do sistema em determinados momentos. A composio destes diagramas tambm pode incluir a representao de papis, chaves, restries, fluxo de dado, visibilidade entre os objetos, identificao de objetos ativos ou seqenciais, sincronizao e seqncia de mensagens em segundos, possibilitando visualizar maiores detalhes.
51
Dois objetos esto sincronizados quando um objeto (objeto ativo11) passa uma mensagem para outro objeto (objeto passivo12) atravs de um relacionamento (ligao). A sincronizao pode ser de trs tipos: seqencial, guardada e sncrona (Booch, 1994). i) seqencial - nico objeto ativo; ii) guardada - vrios objetos ativos, onde eles se comunicam para garantir excluso mtua; iii) sncrona - vrios objetos ativos, onde o objeto passivo garante a excluso mtua. Parte do diagrama de objetos para o sistema de biblioteca ilustrado pela figura 2.15. A concorrncia mapeada de cinco maneiras: sem concorrncia, sncrono, balking, timeout e assncrono, descritos com mais detalhes na seo 2.2.5. Os diagramas de mdulos so compostos por mdulos e suas dependncias e mostram como classe e objetos so alocados para mdulos no projeto fsico do sistema. As dependncias entre os mdulos se referem a compilao dos programas, e o nico relacionamento existente entre os mdulos. Estes mdulos podem ser o programa principal, as especificaes, programas secundrios e subsistemas. Este diagrama pode acrescentar ainda tipos de mdulos particulares da linguagem a ser utilizada, se necessrio.
Subsistema - Emprstimo
Ficha_ usu.h Fichario_ usu.h Ficha_ emp.h Ficha_ tom.h Ficha_ res.h Item_ res.h Ficha_ con.h Ficha_ tit.h Cadastro_ tt.h
emprestimo.cpp
Ficha_ usu.cpp
Fichario_ usu.cpp
Ficha_ emp.cpp
Ficha_ tom.cpp
Ficha_ res.cpp
Item_ res.cpp
Ficha_ con.cpp
Ficha_ tit.cpp
Cadastro_ tt.cpp
Figura 3.26 - Diagrama de mdulos para o subsistema emprstimo
A figura 3.26 ilustra o diagrama de mdulos para o subsistema Emprstimo, onde Emprestimo.cpp um programa fonte que utiliza os arquivos de especificao (.h13), listados na
11 12
Objeto ativo o objeto que solicita uma chamada de uma operao de outro objeto (objeto passivo). Objeto passivo o objeto que executar a operao que foi solicitada pelo objeto ativo.
52
parte superior da figura, e outros programas fontes (.cpp) que contm implementao das operaes. Os diagramas de processo que capturam os aspectos fsicos so compostos pelos processadores (hardware capaz de executar programas), os dispositivos (hardware incapaz de executar programas, ex.: modem, impressora, terminal) e suas conexes, os quais formam a plataforma de execuo do sistema. Segundo (Booch, 1994), pode-se incorporar ao diagrama: i) uma representao alternativa dos processadores e dispositivos, facilitando que o usurio final do sistema compreenda melhor o aspecto fsico, ii) uma representao para agrupar processadores, dispositivos e conexes, simplificando o diagrama e iii) determinar escalonamento de processos, especificando como: executivo ou manual e preemptivo, no preemptivo e cclico. Maiores detalhes ver (Booch, 1994) e (Tanenbaum, 1995). Apesar das sugestes de (Booch, 1994), no especificado pelo mtodo uma modelagem ou notao para a captura dos itens ii) e iii). A figura 3.27 ilustra parte do diagrama de processo para o sistema de biblioteca, com os relacionamentos entre os processadores, com seus processos listados abaixo de cada um e um dispositivo (a impressora) com representao alternativa.
Terminais para usurios externos
Terminal cliente PC web-browser applets dos casos
Terminal cliente Risc web-browser applets dos casos
Terminal cliente Mac web-browser applets dos casos
Acesso via internet Servidor central(Risc) Terminais cliente (p/ funcionrios) OODBMS Sub. Conexes Sub(s). casos servidor applets
Impressora
Figura 3.27 - Parte do diagrama de processo
Os diagramas de transio de estado so utilizados para mostrar os vrios estados dos objetos de uma classe, os eventos que causam as transies de um estado para outro e as aes que resultam dessa mudana. Estes diagramas s so utilizados para modelar os objetos que possuem um comportamento dinmico expressivo. A figura 3.28 apresenta parte do diagrama de transio de estado para o objeto Ficha_controle. O estado inicial o Disponvel e o objeto destrudo depois de estar no estado Extraviado. A transio entre os estados nomeada pelo evento seguido ou no de uma ao.
13
As extenses .h e .cpp so designao para arquivos de especificao e de programa fonte, respectivamente, desenvolvidos em linguagem C++.
53
solicita_uso / atu_status('D')
solicita_emprstimo / cota_emprestada + 1 e atu_status('E')
cria_ficha / atu_status('D')
Disponvel
devolve_emprestimo / cota_emprestada + 1 e atu_status('D')
Emprestado
func_perde_obra / atu_status('X') func_encontra_obra / atu_status('D')
empr_perde_obra / atu_status('X')
Extraviado
destroi_ficha
empr_ encontra_obra / atu_status('E')
Figura 3.28 - Parte do diagrama de transi o de estado
d) Outras Vale observar que no faz parte do escopo do trabalho a anlise das fases de evoluo e manuteno, embora elas sejam aqui descritas para oferecer ao leitor uma viso completa do mtodo. O propsito da fase de evoluo produzir uma implementao atravs de sucessivos refinamentos da arquitetura do sistema, conduzindo a produo do sistema. O propsito da fase manuteno gerenciar o sistema gerado pela evoluo, fornecendo uma continuao da fase anterior. De fato, mudanas mais localizadas so feitas ao sistema, como adicionar novos requisitos e eliminar erros protelados. O objetivo de continuar a evoluo do sistema, seus produtos so idnticos aqueles da fase anterior, com uma adio: uma lista (punch list) de novas tarefas, que serve como veculo para coletar erros e aumentar requisitos, tanto que eles podem ser priorizados para futuras verses.
3.5.4

(Booch, 1994) destaca: Faa a conceitualizao somente quando os riscos do projeto
forem relativamente altos ou quando for necessrio inventar um vnculo inicial entre o cliente e a organizao de desenvolvimento; seno, passe diretamente para a anlise. No possvel nem desejado realizar a anlise completa antes de permitir que o projeto comece (Booch, 1994). Neste sentido, o projeto se inicia to logo se tenha um modelo de anlise razoavelmente completo. A proposta desse mtodo a aplicao das fases repetidas vezes, onde a transio de uma fase para a prxima no exige que a anterior tenha sido totalmente concluda. Com esse enfoque, os modelos vo sendo aperfeioados e detalhados a cada fase e a cada interao. 54
3.5.5
Aplicabilidade
No um mtodo prescritivo, como os mtodos OOA-OOD (Coad/Yourdon) e OMT (Rumbaugh), sendo portanto difcil a sua aplicao por equipes inexperientes. um mtodo bom para equipes de programadores experientes (em linguagens O.O.), que julguem no ser necessria a elaborao de modelos de requisitos e anlise e visualizam o projeto de uma forma interativa com a implementao. Analistas podem ter certa dificuldade no aprendizado, por se tratar de um mtodo direcionado para a implementao, apesar de apresentar outras fases. Aplicvel para organizaes que pretendem construir uma famlia de programas e quelas que tem um investimento significante de capital, devido a repetio do macro processo depois que o produto liberado (Booch, 1994).
3.5.6
Pontos positivos
O mtodo possui uma boa descrio e exemplificao dos conceitos de orientao a objetos realizados de maneira bastante didtica. Apresenta tambm conceitos avanados e seus respectivos elementos notacionais no encontrados em outros mtodos. O modelo de objetos do OOAD, alm de modelar os objetos e seus relacionamentos, como apresentado pelos outros mtodos, o nico que aborda a sincronizao e a seqncia de troca de mensagem entre os objetos. O mtodo apresenta dois diagramas no descritos pelos outros mtodos: o diagrama de processo e o diagrama de mdulo, os quais adicionam detalhes de projeto. Assim, um mtodo que oferece bastante modelagem e descrio sobre o projeto.
3.5.7
Pontos negativos
O mtodo OOAD poderia ser mais prescritivo para facilitar sua compreenso e seu uso, tendo em vista que possui conceitos nicos, quer dizer, no encontrados nos outros mtodos aqui estudados. Alm disso, uma modelagem para a anlise de requisitos seria til para que se pudesse utiliz-lo como nico mtodo em todo desenvolvimento. Os autores fazem referncias a conceitos e diagramas utilizados e/ou definidos por outros autores, que descrevem outros mtodos, tais como OOSE e OMT. Estes diagramas e conceitos, entretanto, no so explicados nem descritos no livro de Booch (Booch, 1994), o que dificulta a utilizao do mtodo por falta de explicaes e pela necessidade de buscar outras fontes para que se tenha um esclarecimento.
3.6.1
OOA-OOD (Object Oriented Analysis and Object Oriented Design) - Anlise e Projeto Orientado a Objetos um mtodo orientado a objetos desenvolvido por Peter Coad e Edward 55
)GF EDC"1#0'('B $" A0@8 75)3 "10'(&' $" &9 2 ) & % # ! 9& 9 6 4 2 # ) % # !
Descrio
Yourdon em 1991 e 1992, tratando das fases de anlise e projeto. O mtodo apresentado em (Coad, 1992) cobrindo a fase de anlise e em (Coad, 1993) cobrindo a fase de projeto. O mtodo OOA-OOD tem seu desenvolvimento baseado em um modelo multicamadas na anlise, que se expande para o projeto como o modelo multicamadas e multicomponentes. O modelo multicamadas apresenta as camadas de classe e objetos, assunto, estrutura, atributo e servio. O modelo multicomponentes retrata os componentes: domnio do problema, interao humana, gerenciamento de dados e gerenciamento de tarefas. Uma melhor descrio se encontra nas sees a seguir.
3.6.2
Caractersticas
O mtodo adota a abordagem orientada a dados, a modelagem de uma classe implica no conhecimento prvio de seus atributos e servios (Silveira, 1995). A preocupao bsica est com os dados e suas estruturas armazenados pelo sistema. O foco do mtodo tanto na anlise quanto no projeto, entretanto esse mtodo no apresenta modelos ricos em notao. Caracteriza-se por ser o mtodo mais prescritivo em relao aos mtodos aqui apresentados, indicando com detalhes todas as atividades que devem ser executadas e os seus subprodutos. Foi um dos primeiros mtodos orientados a objetos a serem desenvolvidos (Fichman, 1992). Desta forma, tornou-se uma referncia para a criao dos outros mtodos, os quais puderam melhorar os pontos deficientes do mtodo base, assim como aperfeioar o mtodo como um todo. Durante a explanao do mtodo em (Coad, 1992) e (Coad, 1993), os autores sugerem o reuso, insistindo que o desenvolvedor faa uma busca em projetos anteriormente desenvolvidos. Eles indicam que o mtodo tanto pode ser utilizado com o modelo de cascata (waterfall), como com o espiral ou com o incremental, que depender do enfoque a ser dado.
3.6.3
Fases
a) Anlise de requisitos Os autores no oferecem modelagem (modelo ou diagrama) para captura e/ou identificao dos requisitos, porm, deixam claro a necessidade da criao de um documento que relata os requisitos, e que de preferncia, se compreenda o domnio do problema antes de iniciar o desenvolvimento. b) Anlise Durante a fase de anlise criado o modelo de anlise, tambm chamado de modelo multinveis ou multicamadas, porque acrescido de detalhes a cada nvel. Os nveis so: assunto, classe&objeto, estrutura, atributo e servio, ilustrada pela figura 3.29. Eles no possuem seqncia definida, ficando a critrio de cada analista a seqncia para construo do modelo.
56
Camada de Assunto Camada de Classe&Objeto Camada de Estrutura Camada de Atributo Camada de Servio
Figura 3.29 - Modelo multinveis - anlise (Coad, 1992)
No nvel de assunto procura-se agrupar as classes&objetos formando assuntos (subsistemas), que facilitam a compreenso do sistema como um todo. No nvel de classe&objeto14 identifica-se as classes e os objetos do domnio do problema. No nvel de estrutura faz-se o relacionamento entre as classes com a estrutura de generalizao-especializao (herana - simples ou mltipla) ou com a estrutura todo-parte (agregao). No nvel de atributo identifica-se primeiramente, os dados (informaes de estado) de cada objeto que so pertinentes ao domnio do problema e depois as conexes de ocorrncia existentes entre os objetos, para que cada objeto possa cumprir suas responsabilidades (Coad, 1991), ou seja, possa realizar todas as suas tarefas. Se necessrio, pode ser feita a descrio de cada atributo em uma ou duas linhas sendo que restries podem ser especificadas. No nvel de servio define-se, primeiramente, as operaes (os servios) de cada classe e depois as conexes de mensagem que modelam a dependncia de processamento de um objeto, indicando quais servios ele necessita. A figura 3.30 apresenta uma parte do modelo multicamadas para o sistema de biblioteca, para o nvel de classe&objeto. Neste nvel s h a identificao das classes, que na figura so seis: Ficha_tombo, Ficha_ttulo, Obra, Ficha_controle, Ficha_reservas e Item_reserva.
Ficha_tombo Ficha_ttulo Obra
Ficha_controle
Ficha_reservas
Item_reserva
Figura 3.30 - Parte do modelo de anlise - nvel classe&objeto
A figura 3.31 apresenta a mesma parte do modelo de anlise, ilustrado pela figura 3.30, com a adio dos nveis de atributo e assunto. Nestes nveis, acrescenta-se a identificao dos
14
Classe&objeto representado graficamente (como mostra a figura A.20 do apndice A), modelando a classe e os objetos dessa classe. Assim, pode-se mapear explicitamente um objeto para outro, uma classe para outra, ou um objeto para uma classe.
57
atributos de cada classe, expressos na parte central de cada classe, o assunto ao qual as classes pertencem e as conexes de ocorrncia com as devidas cardinalidades.
1
Ficha_tombo nr_tombo dt_devoluo Obra nome_obra autor Ficha_reservas qtdd_reservas
1 tem 1 Ficha_controle nr_tombo cod_emprestante status_tombo
1 tem 1,m Ficha_ttulo Item_reserva dti_reserva dtf_reserva cod_reservante
cod_cadastral nome_obra autor qtdd_tombos
Figura 3.31 - Parte do modelo de an lise - nvel classe&objeto, assunto e atributo
A figura 3.32 apresenta parte do modelo de anlise abrangendo todos os nveis. Inclui-se a identificao dos servios (operaes) na parte inferior das classes, as conexes de mensagem entre as classes&objetos e os relacionamentos de generalizao-especializao e todo-parte.
1
Obra 1 nome_obra autor 1 tem 1 1,m 1 qtdd_reservas Ficha_tombo nr_tombo dt_devoluo atu_dt (data) obter_nr_tombo ( ) 1 1 Ficha_controle nr_tombo cod_emprestante status_tombo atu_status (st) atu_qtdd (vlr) 0,m tem 1,m cod_cadastral nome_obra autor qtdd_tombos 1 Ficha_ttulo
1 Ficha_reservas
1 Item_reserva dti_reserva dtf_reserva cod_reservante obter_res (data) verif_res (data)
Figura 3.32 - Parte do modelo de an lise - completo
58
Durante a anlise criado o diagrama de estado do objeto que modela os estados de um objeto, apresentando apenas notao para o estado (retngulo) e para as transies (setas), sendo mais simples que os apresentados pelos outros mtodos, como mostra a figura 3.33.
Estado = Disponvel
Estado = Emprestado
Estado = Extraviado
Estado = Restaurao
Figura 3.33 - Diagrama de estado do objeto obra
Atravs da figura 3.33 nota-se que o objeto Obra possui quatro estados e as possibilidades de transio entre estes estados. O estado Disponvel o estado inicial pois h seta direcionada a ele que no parte de outro estado.
Verifica se a senha informada pelo usurio igual a de sua ficha
Enquanto senha incorreta e desejar verificao
Obter senha
sim
senha = senha_usu
no
retornar mensagem senha vlida
retornar mensagem senha invlida
Figura 3.34 - Diagrama de servio - verif_senha_usu (senha)
Outro diagrama desenvolvido na anlise o diagrama de servio, utilizado para especificar todos os servios do modelo a nvel de algoritmo, possuindo bloco de texto, condio, loop e conector. A figura 3.34 ilustra o diagrama do servio verif_senha_usu (senha) do objeto 59
Ficha_usurio, possuindo quatro blocos de texto (retngulos), uma condio - senha = senha_usu -, seis conectores e um loop que realizar enquanto a senha for incorreta e desejar a verificao. A sada do servio uma mensagem, ou indicando que a senha no confere ou que a senha est correta. Ao final da criao do modelo de anlise e dos outros dois diagramas apresentados (diagrama de estado do objeto e diagrama de servio), deve-se fazer uma especificao de cada classe, podendo seguir o modelo sugerido pelos autores.
especificao Ficha_controle atributo nr_tombo: nmero do tombo atributo cod_emprestante: cdigo do emprestante que deve ser um nr_cadastro em Usurio_cadastrado atributo status_tombo: define status do tombo (Emprestado / Disponvel / eXtraviado / Restaurao) Entradaexterna . Dados recebidos: status e cdigo do emprestante . Dados verificados: verifica se o cod_emprestante = nr_cadastro Sadaexterna . Controle de emprstimo: diminui / acrescenta valor a cota_emprestada DiagramadeEstadodeObjeto
Estado = Disponvel
Estado = Emprestado
Estado = Extraviado
Estado = Restaurao
Especificaes adicionais . O status_tombo refere ao estado da Obra (tombo) para o qual a ficha mantm relao. servio atu_status (sada: mensagem)
Atualiza status do tombo
Enquanto situao <> E / D / X / R e desejar atualizar Obter situao a ser atualizada retornar mensagem atualizao executada situao = E / D / X / R retornar mensagem situao no aceitvel
sim
no
Figura 3.35 - Especifica o da classe ficha_controle
A figura 3.35 apresenta a especificao da classe Ficha_controle, que apresenta trs atributos, entrada e sada externa, diagrama de estado do objeto, especificaes adicionais e um servio com seu diagrama de servio. 60
c) Projeto Durante a fase de projeto criado o modelo de projeto tambm chamado de modelo multicamadas e multicomponentes. A figura 3.36 ilustra o modelo de projeto que possui quatro componentes: domnio do problema, interao humana, gerenciamento de tarefas e gerenciamento de dados.
Camada de Assunto Camada de Classe&Objeto Camada de Estrutura Camada de Atributo Camada de Servio
Componente de Domnio do Problema
Componente de Interao Humana
Componente de Componente de Gerenciamento Gerenciamento de Tarefas de Dados
Figura 3.36 - Modelo multicamadas, multicomponentes - projeto (Coad, 1993)
O modelo de anlise apresenta cinco camadas/nveis e se encaixa no modelo de projeto no componente domnio do problema, que ser acrescido de detalhes de projeto como por exemplo: acomodar nveis de herana, melhorar performance, reutilizar classes de projeto e programao, etc., sendo chamado, a partir disso, de modelo de projeto, utilizando a mesma notao da anlise. No projeto, a modelagem de interface feita com a especificao detalhada e o desenho de telas e relatrios no componente interao humana. Deste modo, ser possvel visualizar como uma pessoa comandar o sistema e como o sistema apresentar as informaes.
Janela
cabealho altura largura maximizar minimizar reduzir montar_janela 1,m 1
Boto Help
help(tela)
1,m
Janela seleo
Janela entrada
1,m 1,m
Boto Back
voltar(tela)
Boto OK Janela principal

ok
Boto Cancel
cancel
1,m 1,m 1
Boto empr.
Janela Emprst
1
Janela reserva
Boto reserva
Janela entrada senha
Figura 3.37 - Modelo de projeto - componente intera o humana
61
A figura 3.37 mostra parte do modelo de projeto para o componente interao humana, que especifica a composio e apresentao das telas do sistema. Uma ilustrao semelhante a tela original pode ser desenhada, com o objetivo de certificar sua validade junto ao usurio. Durante a criao do componente gerenciamento de tarefa necessrio identificar as tarefas dirigidas por tempo e por evento, a prioridade de cada tarefa, as tarefas crticas, a tarefa que coordenar as outras e descrever cada uma delas.
Coordenador emprstimo
1,m 1,m
1,m 1 1
Verificar usurio
Verificar obra
Concluir emprstimo
Figura 3.38 - Modelo de projeto - componente gerenciamento de tarefas
A figura 3.38 ilustra parte do modelo de projeto para o componente gerenciamento de tarefas para a tarefa realizar emprstimo. Uma tarefa coordenadora foi identificada, Coordenador de emprstimo, para coordenar trs tarefas necessrias para se efetuar um emprstimo, so elas: verificar usurio, verificar obra e concluir emprstimo.
Nome: Verificar obra Descrio: Esta tarefa responsvel por fazer verificaes relativas a obra Prioridade: Mdia Servios includos: . Cadastro_ttulos.loc_ficha (cod_cadastral) . Ficha_ttulo.obter_qtdd_tombos . Ficha_controle.obter_status_tombo . Ficha_reservas.loc_res (cod_cadastral) . Item_reserva.verif_tombo_res (nr_tombo) . Item_reserva.verif_cod_reserv (nr_cadastro) Coordenada por: . controlada por tempo Comunica via: . envia valores (nr_tombo) a outra tarefa (Concluir emprstimo)
Figura 3.39 - Modelo de projeto - especifica o de tarefas
Para todas as tarefas identificadas necessrio fazer uma descrio sobre cada uma. A figura 3.39 apresenta a descrio para a tarefa Verificar obra, seguindo modelo sugerido pelos 62
autores do mtodo, que relata nome, descrio, prioridade, servios includos, coordenada por evento / tempo e sua comunicao (de quem recebe e para quem envia os valores). Durante o desenvolvimento do componente denominado gerenciamento de dados, necessrio definir o layout (arquivo simples, relacional ou baseado em objeto) dos dados e tambm projetar os servios correspondentes a fim de que os objetos possam ser armazenados.
3.6.4
A passagem da anlise para o projeto significa uma expanso progressiva do modelo. Durante a anlise, o objetivo modelar o domnio do problema e as responsabilidades do sistema. Durante o projeto, o objetivo expandir o modelo de anlise com aspectos de implementao, adicionando os componentes: interao humana, gerenciamento de tarefas e gerenciamento de dados. Desta forma, toda semntica e sinttica utilizada na anlise utilizada no projeto tambm, permitindo uma melhor compreenso do desenvolvimento e evitando uma transformao de notao entre as fases.
3.6.5
Aplicabilidade
uma boa opo para equipes iniciantes em tecnologia de objetos, pois sua notao simples e suficiente para boa parte dos projetos que tenham enfoque nos dados armazenados pelo sistema e sem muita dinmica. O mtodo aplicvel a grandes equipes de desenvolvimento, utilizando a anlise e depois o projeto. Sendo til, tambm, s pequenas equipes e onde se utilize a prototipao, fazendo uma intercalao entre a anlise e o projeto, um pouco de cada durante todo o desenvolvimento (Coad, 1992).
3.6.6
Pontos positivos
O mtodo possui a representao grfica para classe&objeto que permite alm do mapeamento entre classes e entre objetos, o mapeamento explcito de um objeto para uma classe, o que no encontrado nos outros mtodos, possibilitando a diferenciao entre a classe abstrata e a concreta. O mesmo esquema notacional aplicado anlise e ao projeto, acrescentando cada vez mais detalhes ao modelo, o que facilita o entendimento do sistema durante seu desenvolvimento, pois no possui notaes diferentes para o mesmo aspecto somente por estar em fases distintas. A notao diferenciada para mensagens permite uma rpida visualizao da troca de mensagens entre os objetos. importante para no misturar com os outros relacionamentos.
3.6.7
Pontos negativos
A cardinalidade apresentada pelo mtodo diferente da utilizada pelos outros mtodos,
dificultando o entendimento do modelo, pois ela se apresenta invertida. A figura 3.40 apresenta um 63
exemplo, onde o Acervo possui uma ou mais (1,N) Obras; a figura da esquerda est modelada pelo mtodo OMT (utilizada tambm pelos demais mtodos) e a da direita pelo mtodo OOA-OOD.
Acervo 1 1, N
Obra
Acervo 1.. N 1
Obra
OMT
OOA-OOD
Figura 3.40 - Exemplifica o da cardinalidade
O mtodo OOA-OOD oferece pouca modelagem para o desenvolvimento de um sistema. A parte esttica apresenta poucos modelos e a notao utilizada neste modelos muito restrita. A parte dinmica representada juntamente com a esttica, no apresentando notao suficiente, falta modelos especficos para a modelagem, tais como: cenrios ou diagramas de eventos.
3.7.1
Fusion um mtodo orientado a objeto, desenvolvido por Derek Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, Helena Gilchrist, Fiona Hayes e Paul Jeremaes em 1994. O mtodo est descrito no livro Object-Oriented Development: the fusion method e sua traduo para o portugus em (Coleman, 1996).
Documento de requisitos

Descrio
ANLISE Modelo de objetos Modelo de interfaces D I C I O N R I O D E D A D O S Grafo de interao de objeto Decomposio de subsistema Grafos de visibilidade PROJETO Descries de classe Grafos de herana IMPLEMENTAO Programa
Figura 3.41 - Mtodo Fusion (Coleman, 1996)
64
O Fusion aborda as fases de anlise, projeto e implementao, deixando claro que a captura de requisitos ser executada por um usurio, que deve fornecer o documento inicial de requisitos (Coleman, 1996), portanto o Fusion no faz modelagem da anlise de requisitos. A figura 3.4115 ilustra o processo desse mtodo.
3.7.2
Caractersticas
O mtodo possui abordagem orientada a dados, onde a preocupao principal a identificao dos dados armazenados pelo sistema. Isso caracterizado pela descrio dos primeiros modelos a serem criados no incio do desenvolvimento, onde no h meno s operaes do sistema. O foco est tanto na fase de anlise, quanto na fase de projeto, pois o Fusion est baseado em mtodos com foco nestas fases, mtodo OMT e mtodo OOAD, respectivamente. (Coleman, 1996) classifica seu mtodo como sendo de segunda gerao e diz: ele integra e amplia tcnicas existentes. Como o prprio nome sugere Fuso, do ingls Fusion, o mtodo integra aspectos positivos de trs mtodos: OMT, Booch e mtodos formais e a tcnica CRC - Classe Responsabilidade Colaborador16. Esta integrao ilustrada pela figura 3.42.
OMT
Anlise mod. de objetos e processos
CRC
Projeto interao de objetos
FUSION
Implementao pr-condies e ps-condies Projeto grafos de visibilidade
MTODOS FORMAIS
OOD
Figura 3.42 - Composi o do mtodo Fusion ( Coleman, 1996)
Para a composio do Fusion adotou-se: i) o modelo de objetos baseado no mesmo modelo aplicado ao mtodo OMT, ii) modelo de operaes com influncia dos DFD's do mtodo OMT, iii) a interao de objetos baseado na tcnica CRC, iv) as pr-condies e ps-condies dos mtodos formais e v) os grafos de visibilidade do mtodo OOD (primeira verso do mtodo OOAD).
3.7.3
Fases
a) Anlise de requisitos No h modelagem para a anlise de requisitos, a fase de anlise ter como base um documento de requisitos definido pelo usurio.
15
A figura original (Coleman, 1996) - verso traduzida - pg.: 311, l-se 'Documento de requisitos', onde na figura 3.41 l-se 'Grafo de interao de objeto'. Deve haver um erro grfico na figura citada. 16 CRC uma tcnica exploratria e no um mtodo completo, que foi projetada originalmente para ensinar os conceitos bsicos do projeto orientado a objeto (Coleman, 1996).
65
b) Anlise Durante a modelagem esttica so construdos os seguintes modelos: modelo de objetos, o modelo de objetos do sistema e, em paralelo, um dicionrio de dados. A figura 3.43 ilustra parte do modelo de objetos construdo para o sistema de biblioteca, baseando no documento de requisitos, onde sero modeladas as classes (ex.: Acervo_obras, Cadastro_ttulos, Item_reserva, Funcionrio, etc.), seus relacionamentos (ex.: tem, atualizao e consulta), agregao (modelada como uma classe dentro da outra, ex.: o relacionamento entre Acervo_obras e Obra), atributos (ex.: qtdd_obras, autor, nr_tombo) e cardinalidade (ex.: 1, +, *).
Cadastro_ttulos Acervo_obras qtdd_ttulos qtdd_obras
Obra nome_obra autor Ficha_tombo nr_tombo dt_devoluo tem
*
+
1 tem 1 cod_cadastral nome_obra autor qtdd_tombos
Ficha_ttulo
Ficha_reservas qtdd_reservas
+
1
Ficha_controle nr_tombo cod_emprestante status_tombo
Item_reserva dti_reserva dtf_reserva cod_reservante
*
1 atualizao atualizao 1
*
Funcionrio
consulta
nome_fun endereo_fun senha_fun
Figura 3.43 - Parte do modelo de objetos
Com base no modelo de objetos desenvolve-se o dicionrio de dados, que ser atualizado durante todo o desenvolvimento. Esse dicionrio deve conter todas as definies necessrias para o entendimento do sistema que est sendo modelado devendo servir para fazer a verificao de consistncia entre os modelos. Para delimitar a fronteira do sistema e identificar as classes e relacionamentos que sero implementados, criado o modelo de objeto do sistema, onde se faz uma separao entre as classes e relacionamentos que pertencem ao sistema e ao ambiente. A figura 3.44 ilustra parte do modelo de objeto do sistema para o sistema de biblioteca, onde as classes que pertencem ao sistema esto modeladas dentro do retngulo tracejado e do lado de fora o ambiente modelado. 66
*
+
1 tem cod_cadastral 1 nome_obra autor qtdd_tombos
Ficha_ttulo
Ficha_controle
nr_tombo 1 cod_emprestante status_tombo
*
1 1
atualizao atualizao
*
Funcionrio
consulta
Figura 3.44 - Parte do modelo de objeto do sistema
A modelagem dinmica do sistema feita desenvolvendo-se o modelo de interface e seus componentes. O modelo de interface17 modela o comportamento do sistema, identificando eventos e estados. O modelo de interface utiliza o modelo de ciclo-de-vida e o modelo de operaes para capturar aspectos diferentes deste comportamento. No existe uma ordem para o desenvolvimento, entretanto sugerido que primeiro se faa o modelo ciclo-de-vida, porque ele pode auxiliar na construo do outro modelo. O modelo ciclo-de-vida descreve o comportamento do sistema de maneira mais ampla, mostrando como o sistema se comunica com os agentes desde sua criao at seu trmino, ou seja, define as seqncias permissveis de interao entre eles. Este modelo excelente para capturar, alm da ordenao, repetio e alternao dependentes das operaes do sistema. O modelo ciclode-vida composto por vrias expresses ciclo-de-vida que generalizam os cenrios, ou seja, definem um conjunto de cenrios. A figura 3.45 mostra o exemplo de um modelo de ciclo-de-vida incompleto, que se tornaria completo com a definio de todas as expresses ciclo-de-vida de todos os cenrios do sistema.
17
interessante observar, que a interface do sistema, sugerida pelo mtodo, composta pelo conjunto de operaes que o sistema pode responder (operao do sistema, ou eventos de entrada), e pelos eventos que este sistema pode gerar (eventos ou eventos de sada).
67
lifecicle S i s t e m a _ b i b l i o t e c a : I n i c i a o . ( E m p r s t i m o | | R e s e r v a | | P a g a m e n t o | | Devoluo || Pesquisa)* Iniciao = solicita_cadastro. #tipo_cadastro. tipo_cadastro. (dados_func | dados_usu | dados_obra) Emprstimo = solicita_emprstimo. #solicita_dados_emp. dados_emprstimo. #obra_liberada Reserva = (f_solicita_reserva | u_solicita_reserva). #solicita_dados_res. dados_reserva. (#f_reserva_efetuada | #u_reserva_efetuada) Pagamento = . . . Devoluo = . . . Pesquisa = . . .
Figura 3.45 - Modelo ciclo-de-vida incompleto
A expresso ciclo-de-vida Reserva se inicia com o evento de solicitao de reserva pelo funcionrio f_solicita_reserva ou pelo usurio u_solicita_reserva, seguido pela solicitao do sistema dos dados da reserva #solicita_dados_res, pelo envio dos dados pelo usurio dados_reserva e, finalmente, pelo envio da mensagem reserva efetuada ao solicitante #f_reserva_efetuada ou #u_reserva_efetuada.
Operation: dados_reserva Description: Usurio_cadastrado fornece dados para que a reserva seja efetuada. Reads: supplied cod_cadastral, supplied data_reserva, supplied senha; supplied nr_cadastro; qtdd_tombos, nr_tombo, status_tombo, dt_devoluo, qtdd_reserva, dt_reserva, cod_reservante.
Changes: incrementar 1 em qtdd_reservas, criao de uma nova reserva com os dados j informados pelo usurio Sends: usurio_cadastrado: {reserva_efetuada}
A s s u m e s : a qtdd_tombos deve ser maior que 0, ento para todos os nr_tombos obtm-se o status_tombo. Se estiver emprestado, verifica-se se a dt_devoluo for menor que a data_reserva, concluir reserva, seno procura outro tombo. Se estiver disponvel, verifica existncia de reserva. Se no existir reserva, concluir reserva, seno verifica se o nr_cadastro for diferente de cod_reservante, concluir reserva, seno reserva no pode ser feita. Antes de concluir reserva verificar se a senha_usu igual a senha. Result: -
Figura 3.46 - Esquema de opera o - dados_reserva
68
O segundo modelo de interfaces, o modelo de operaes, composto por esquemas de operaes. Um exemplo de um esquema para a operao dados_reserva apresentado pela figura 3.46. Para a operao dados_reserva so necessrios o cod_cadastral, a data_reserva, a senha e o nr_cadastro como parmetros e o restante indicado na clusula Reads obtido pelo sistema. A qtdd_reservas ser alterada, um novo item_reserva ser criado e o usurio_cadastrado receber uma mensagem (reserva_efetuada). A clusula Assumes descreve as condies sob as quais uma operao do sistema pode ser ativada. A clusula Results descreve como o estado do sistema ser alterado por uma operao do sistema e quais os eventos que sero enviados aos agentes. Ao final, todas as operaes do sistema devem ser descritas de forma mais detalhada, sendo utilizado um esquema para cada operao. Neste esquema so informados: nome, descrio, nome de itens a serem acessados pela operao, nome de itens a serem acessados e modificados, nome de todos os eventos e agentes que a operao possa enviar, lista de pr-condies e pscondies. Este esquema o que melhor captura os comportamentos condicionados pelos eventos do sistema. Alm desses modelos, podem ser utilizados os cenrios e os diagramas de tempo para deixar bem claro a comunicao entre os agentes e o sistema. Os cenrios so criados para cada funo do sistema, por exemplo: fazer emprstimo ou fazer reserva. Estes cenrios mostram os agentes (entidades externas) e a seqncia de informaes envolvidas entre estes e o sistema de uma forma textual. Este cenrio idntico aos cenrios descritos pelos mtodos OOSE e OOAD. Cada cenrio representado graficamente pelos diagramas de tempo, onde as operaes e os eventos so colocados ordenadamente em relao ao tempo, facilitando a visualizao dinmica do sistema. Um cenrio poder possuir mais de um diagrama de tempo para que a modelagem de caminhos alternativos possa ser feita. A figura 3.47 ilustra o diagrama de tempo para o cenrio de emprstimo, que foi ilustrado na figura 3.3 na seo 3.4. Este diagrama semelhante ao diagrama de eventos do OMT, porque mostra a interao dos agentes com o sistema, no detalhando a interao dentro do sistema. Tendo identificado os eventos, os agentes e as operaes entre eles, estes devem ser acrescentados ao dicionrio de dados, informando nome, categoria, agente (para o primeiro e o terceiro) e uma descrio.
Usurio_ cadastrado
Tempo solicita_emprstimo (nr_cadastro) solicita_dados_emp dados_emprestimo obra_liberada
Sistema Biblioteca
Funcionrio
Figura 3.47 - Diagrama de tempo - cen rio emprstimo
69
c) Projeto Ao passar para a fase de projeto, o primeiro modelo que desenvolvido o grafo de interao de objetos para cada operao do sistema, tendo como base os esquemas de operaes presentes no modelo de operao. O propsito especificar como a funcionalidade do sistema ser implementada pelos objetos contidos no sistema. Cada grafo de interao de objetos possui um texto descritivo, assim como cada operao identificada no grafo, os quais se encontram no dicionrio de dados. A figura 3.48 ilustra um exemplo de grafo de interao de objeto para a operao solicita_emprstimo. A operao solicita_emprstimo tem como parmetro o nr_cadastro e o objeto f da classe Fichrio_usurios como controlador. Este objeto acessa o objeto fu da classe Ficha_usurio, o objeto fe da classe Ficha_emprstimo e o objeto uc da classe Usurio_cadastrado, nesta ordem.
solicita_emprstimo (nr_cadastro) (1) loc_ficha (nr_cadastro) (2) verif_cota ( ) (3) verif_dvida ( ) (4) verif_dt_dev ( )
f: Fichrio_ usurios
fu: Ficha_ usurio
fe: Ficha_ emprstimo
(5) solicita_dados_emp ( )
uc: Usurio_ cadastrado
Figura 3.48 - Grafo de intera o de objeto - opera o solicita_emprstimo

Estes grafos definem as seqncias de mensagens entre os objetos, que so utilizados para realizar a operao. A construo desses grafos forma a primeira fase do projeto onde considerado que todos os objetos so visveis entre si. Depois de gerado todos os grafos de interao de objeto, necessrio que sejam modeladas as estruturas de visibilidade entre as classes, determinando os objetos clientes e os servidores do sistema, pois nem todos os objetos so visveis por todos os outros. Esse detalhamento realizado sobre os grafos de interao, utilizando notao apropriada. Posteriormente, so desenvolvidos os grafos de herana com base nos seguintes itens: i) modelo de objetos do sistema, com as estruturas generalizao e especializao identificadas na anlise, ii) os grafos de interao de objeto e as descries de classes, obtendo as operaes comuns para gerar classes abstratas e iii) os grafos de visibilidade, fornecendo estruturas que possuam referncias em comum, facilitando a identificao de classes abstratas. O exemplo de biblioteca no possui este modelo por no haver herana entre as classes modeladas.
70
Aps a modelagem do projeto, utilizando-se dos grafos e diagramas descritos, so desenvolvidas as descries de todas as classes do sistema. As descries de classe modelam: atributos de dados, as operaes e seus parmetros, atributos de objetos e informaes sobre herana, obtidos atravs do modelo de objetos e dicionrio de dados, grafos de interao de objetos, grafos de visibilidade e grafos de herana, respectivamente. As descries de classe compem a base para o incio da codificao, pois renem informaes sobre as operaes e suas referncias. Um exemplo de descrio de classe ilustrado pela figura 3.49 para a classe Ficha_tombo.
class Ficha_tombo attribute nr_tombo : int attribute dt_devoluo : data method atu_dt (data) method obter_nr_tombo ( ) endclass
Figura 3.49 - Descri o da classe ficha_tombo
d) Outras O mtodo aborda a fase de implementao que a traduo do que foi definido nas descries de classe e nos grafos de visibilidade. O detalhamento na fase de projeto facilita a implementao do sistema.
3.7.4
A transio da fase de anlise para o projeto, segundo os autores, possvel quando os modelos de anlise estiverem bons (completos e consistentes) o suficiente para serem utilizados no projeto. A fase de projeto no necessita de modelos perfeitamente corretos, alguns erros triviais so permissveis. Assim, os modelos de anlise devem ser verificados para certificar de que esto completos, capturando todas as abstraes significativas do domnio do problema, e consistentes, significando que no h contradies entre os modelos.
3.7.5
Aplicabilidade
Este mtodo no indicado para equipes iniciantes em orientao a objetos, pois um mtodo de ampla cobertura, tornando-se um mtodo de aprendizado demorado. Tambm no um mtodo indicado para projetos de baixa complexidade, que podero fazer uso de mtodos mais simples, como por exemplo do mtodo OOA-OOD. o mtodo ideal para desenvolvedores que j utilizaram na prtica mtodos mais simples, e desejam evoluir para um mtodo mais completo. Segundo (Coleman, 1996), o Fusion pode ser aplicado na reengenharia de sistemas existentes, alm do desenvolvimento de novos sistemas. O mtodo tambm pode ser aplicado a tipos particulares de sistemas concorrentes. 71
3.7.6
Pontos positivos
O mtodo composto por partes (diagramas/modelos) de mtodos que possuem pontos positivos, melhorando as partes que no obtiveram sucesso, ou que no modelavam o desejado de maneira mais precisa. A criao dos grafos de interao e das descries de classe, por possuir riqueza semntica e de detalhes, facilita a fase de implementao. Outro ponto positivo a descrio de um framework para o dicionrio de dados, pois este tem um papel muito importante na verificao dos modelos do sistema.
3.7.7
Pontos negativos
O mtodo Fusion no apresenta nenhum mecanismo para representao dos estados
possveis dos objetos, o que nos outros mtodos possvel atravs dos diagramas de estados. Em alguns tipos de aplicaes este tipo de representao faz falta, pois os estados de objetos individuais podem ser bastante significativos.
Neste captulo foi apresentado o processo utilizado para escolher os mtodos orientados a objetos, observando a cobertura do mtodo em relao as fases de desenvolvimento, ferramentas CASE que oferece suporte para cada mtodo e se o mtodo faz parte de algum mtodo integrador. A segunda parte procurou contextualizar o sistema utilizado como exemplo durante a descrio dos mtodos, que foi feita na fase seguinte com a identificao de vrios aspectos, tais como: descrio, caractersticas, abrangncia das fases do desenvolvimento, transio entre as fases, aplicabilidade, pontos positivos e negativos; os quais possibilitam uma comparao entre os mtodos, que realizada no prximo captulo.
% " 0)('&$#!
72
Comparao entre os mtodos orientados a objetos

Neste captulo so apresentadas algumas tabelas que renem vrios aspectos capturados pelos mtodos orientados a objetos. Estes aspectos foram identificados com ajuda da modelagem do sistema de biblioteca e que facilita a comparao entre os mtodos. A cobertura oferecida pelos mtodos em cada fase do desenvolvimento resumida em uma figura, que comentada e, posteriormente, as consideraes finais referentes ao captulo so descritas.
A tabela 4.1 apresenta uma descrio explicativa dos aspectos capturados pelos mtodos, que foram utilizados para verificar quais deles os mtodos abordavam, permitindo compar-los. A tabela 4.2 apresenta para cada mtodo a fase do desenvolvimento e os modelos ou diagramas onde cada aspecto da tabela 4.1 descrito. Por exemplo, o aspecto identificao dos requisitos modelado pelo OOSE na fase de Anlise, mais especificamente durante a Anlise de requisitos, pelo modelo use case. Com o objetivo de comparar os mtodos foi estabelecido o seguinte critrio: o mtodo que possuir um modelo com maior quantidade de elementos semnticos, ou seja, maior abrangncia dentro do que o modelo prope, recebe modelagem com nvel MXIMO e os demais mtodos sero avaliados tendo como parmetro o mtodo de nvel MXIMO. Por exemplo, se o mtodo OOSE possuir 10 elementos ponderados e recebe 100 % (MXIMO), o mtodo OOA-OOD com 6 elementos ponderados recebe 60 %. O critrio representa uma regra de trs simples, 10 est para 100, assim como 6 est para X, ento X = (6 x 100) / 10 => X = 60 %, como mostra a figura 4.1.
Figura 4.1 - Critrio para nivelamento
C"I 9 $ C 5 9 7 " 2(0( & $" DP"HFGED"B1A0@8564311%)'%#!

10 - 100 6 X X = 6 x 100 10 X = 60 %
73
Captulo 4 - Comparao entre os mtodos orientados a objetos _________________________________________________________________________________________________________________________________________________ Tabela 4.1 Descrio explicativa dos aspectos capturados pelos mtodos
Aspectos capturados Identificao de requisitos Identificao de eventos Interface do sistema Estrutura de classes Estrutura de objetos Descrio de classes Identificao de atributos Identificao de operaes Troca de mensagens Relacionamentos
Estrutura de agregao Estrutura de herana Modelagem de estados
Descrio explicativa Modelagem dos requisitos do sistema, identificados pelo usurio ou pelo analista e confirmados pelo usurio. Modelagem da interao que o usurio ter com o sistema. Envio e recebimento de dados ao sistema. Modelagem das telas e relatrios que aparecem como interface entre o sistema e o usurio; descries e/ou grficos. Identificao das classes do sistema e os relacionamentos entre elas. Identificao dos objetos do sistema e os relacionamentos entre eles. Resumo abrangendo todas as caractersticas das classes, tais como: objetivo, atributos e operaes, associaes e restries. Identificao dos atributos de cada classe. Identificao das operaes de cada classe. Modelagem da troca de mensagens entre os objetos do sistema. Aborda os relacionamentos existentes de acordo com cada mtodo e seus acompanhamentos que melhor os definem (papel, qualificador, etc). Modelagem do relacionamento de agregao entre as classes. Modelagem do relacionamento de herana entre as classes. Modelagem dos estados que os objetos de cada classe pode assumir, como os eventos, transies, aes, condies e atividades. Identificao de funes do sistema. (Nvel mais baixo de abstrao) Identificao de funcionalidades do sistema. (Nvel mais alto de abstrao) Identificao de subsistemas, para facilitar o entendimento do sistema como um todo. Alocao de subsistemas a processadores. Modelagem das prioridades que os processos tem em relao a utilizao do processador. Modelagem do detalhamento das operaes, na forma de algoritmo, apresentando parmetros de entrada e sada e repetio. Modelagem da concorrncia entre os objetos, quando dois objetos executam operaes ao mesmo tempo. Apresenta o foco que o mtodo oferece a fase, com a apresentao dos modelos definidos, e assim, acredita-se apresentar uma boa documentao na fase em que possui foco.
Aspectos funcionais Identificao de funcionalidades Criao de subsistemas Alocao de subsistemas Estabelecer prioridades Detalhamento de operaes Tratamento de concorrncia Foco - Anlise de requisitos Foco - Anlise Foco - Projeto Abordagem - Dados Abordagem - Comportamental
Define a abordagem que o mtodo possui, se orientada a dados ou orientada ao comportamento; de acordo com a indicao do que deve ser feito primeiro no desenvolvimento.
Captulo 4 - Comparao entre os mtodos orientados a objetos _________________________________________________________________________________________________________________________________________________ Tabela 4.2 Fase e modelos/diagramas onde os aspectos so capturados pelos mtodos
OMT MTODOS OOAD OOA-OOD Fusion -
Aspectos capturados Identificao dos requisitos
Identificao de eventos
Interface do sistema
Anlise Cenrio (textual) / Diagr. de tempo -
Estrutura de classes
Estrutura de objetos
Descrio de classes
Identificao de atributos
Identificao de operaes
Troca de mensagens
Relacionamentos
Estrutura de agregao
Estrutura de herana
Modelagem de estados
Anlise Modelo de objetos Projeto Grafo interao de objetos Projeto Descries de classes Anlise Modelo de objetos Projeto Grafo interao de objetos Projeto Grafo interao de objetos Anlise Modelo de objetos Anlise Modelo de objeto Projeto Grafos de herana -
Aspectos funcionais
OOSE Anlise (Anlise requis.) Modelo use case Projeto Descr. Use case / Diagrama de interao Anlise (Anlise requis.) Descries interface / Modelo Anlise Anlise (Anlise requis.) Modelo domnio do problema Anlise Modelo de anlise Anlise Descrio de objeto Anlise Modelo de anlise Projeto Diagrama de interao Projeto Diagrama de interao Anlise (Anlise requis.) Modelo domnio do problema Anlise Modelo domnio problema Anlise Modelo domnio problema Projeto Grafo transio de estado Anlise Cenrio (textual) / Diagr, interao Anlise Cenrio (textual) Anlise Diagrama de classes Anlise Diagrama de objetos Anlise Especificaes (textual) Anlise Diagrama de classes Anlise Diagrama de classes Anlise Diagr. objetos / Diagr. interao Anlise Diagrama de classes Anlise Diagrama de classes Anlise Diagrama de classes Projeto Diagrama transio de estado Projeto Mod. Proj. - Interao Humana Anlise Mod. Anlise - classe&objetos Anlise Mod. Anlise - classe&objetos Anlise Especificao de classes Anlise Mod. Anlise - atributos Anlise Mod. Anlise - servios Anlise Mod. Anlise - servios Anlise Mod. Anlise - classe&objetos Anlise Mod. Anlise - estrutura Anlise Mod. Anlise - estrutura Anlise Diagrama de estado do objeto -
Identificao de funcionalidades
Criao de subsistemas
Anlise Modelo de operaes Anlise Cenrios (textual) Anlise Mod. Anlise - assunto -
Alocao de subsistemas
Estabelecer prioridades
Anlise (Anlise requis.) Modelo use case / Descrio Anlise Modelo de anlise Projeto -
Anlise Cenrios (textual) Projeto Diagrama de mdulos Projeto Diagrama de processo -
Detalhamento de operaes
Tratamento de concorrncia
Projeto Diagrama de interao -
Projeto Mod. Proj. - Gerenciam. Tarefas Anlise Diagrama de servio Anlise Especificao de operao Projeto Diagrama de objetos -
Anlise Modelo de operaes -
Foco - Anlise de requisitos
Anlise Cenrio (textual) / Diagr. de eventos Anlise Telas e suas seqncias Anlise Diagrama de classes Anlise Diagrama de instncia Anlise Dicionrio de dados Anlise Diagrama de classes Projeto de objetos Diagrama de classes Anlise Diagrama de instncia Anlise Diagrama de classes Anlise Diagrama de classes Anlise Diagrama de classes Anlise Diagrama de estados Anlise Diagrama de fluxo de dados Anlise Cenrio (textual) / Diagr. de eventos Projeto de sistema Diagrama de fluxo de dados Projeto de sistema Projeto de sistema Projeto de objetos Algoritmos Projeto de sistema -
Foco - Anlise
Foco - Projeto
Abordagem - dados
Anlise de requisitos modelos tabela 4.22 Anlise modelos tabela 4.23 Projeto modelos tabela 4.24 -
Anlise modelos tabela 4.23 Projeto modelos tabela 4.24 Anlise tabela 4.26
Abordagem - comportamental
Anlise tabela 4.26
Anlise modelos tabela 4.23 Projeto modelos tabela 4.24 Anlise tabela 4.25 -
75
A tabela 4.3 apresenta o nvel de modelagem e as faixas adotadas para comparar os mtodos. A modelagem com nvel MXIMO engloba de 75 a 100 % de aproveitamento, o nvel MDIO ALTO inclui os mtodos com 50 a 74.9 %, o nvel MDIO BAIXO engloba os mtodos com 25 a 49.9 % e o nvel MNIMO inclui os mtodos com 0.1 a 24.9 % de modelagem, todos em relao ao mtodo com nvel MXIMO. O nvel inexistente designado ao mtodo que no possui modelagem.
Tabela 4.3 Nvel de modelagem
Nvel MXIMO MDIO ALTO MDIO BAIXO MNIMO - (inexistente)
Valor 75 100 % 50 74.9 % 25 49.9 % 0.1 24.9 % 0
O critrio apresentado pela figura 4.3 possibilita verificar mais intuitivamente a comparao realizada entre os mtodos, que ilustrada pela tabela 4.27. A seguir cada um dos aspectos identificados na tabela 4.2 sero detalhados quanto aos elementos notacionais oferecidos pelos mtodos e comentados quanto ao nvel recebido segundo o critrio estabelecido anteriormente. importante ressaltar que os elementos notacionais oferecidos devem ser bem explicados pelos autores em seus livros fundamentais. A avaliao no feita somente sobre a notao, mas tambm sobre o detalhamento conceitual oferecido. Este ltimo o mais importante, tendo em vista, que normalmente a notao a ser utilizada de agora em diante ser a UML (detalhes no apndice D). Outro aspecto importante que os elementos notacionais apresentados em cada tabela obter peso (1) ou peso (2). O peso (2) indica que o elemento ser mais utilizado no desenvolvimento de sistemas de complexidade mdia, tendo em vista o aspecto em questo. O peso (1) refere-se ao elemento adicional oferecido pelo mtodo, o qual ser utilizado para detalhar ainda mais a modelagem, portanto, nem sempre ser necessrio.
Tabela 4.4 Identificao dos requisitos OOAD _ -
OOSE (2) use case (2) atores (2) descrio 6 - 100 %
OMT _ -
OOA-OOD _ -
Fusion _ -
Pela anlise da tabela 4.4, observa-se que o mtodo OOSE o nico que apresenta modelagem para a identificao dos requisitos, com o modelo use case e descrio de cada use case, recebendo nvel MXIMO. Enquanto que os outros mtodos apenas indicam a necessidade de um documento textual ou o uso de prototipao sem apresentar modelagem. 76
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.5 Identificao de eventos OOAD (2) descr. use case
OOSE (2) descr. use case (1) tempo (2) objetos (2) sinal (1) borda (1) script 9 - 100 %
OMT (2) cenrio (1) tempo (1) agente externo (2) eventos (1) sistema 7 - 77.8 %
OOA-OOD _
Fusion (2) cenrio (1) tempo (1) agentes (2) eventos (1) sistema 7 - 77.8 %
2 - 22.2 %
O mtodo OOA-OOD no possui modelagem e o mtodo OOAD refere aos modelos do mtodo OOSE. Assim, os demais mtodos apresentam modelagem de nvel MXIMO para a identificao de eventos, conforme mostra a tabela 4.5, porque permitem a visualizao imediata dos eventos.
Tabela 4.6 Interface do sistema OOAD OOA-OOD (2) desenho das telas (2) desenho das telas (2) estrutura classes 2 - 40 % 4 - 80 %
OOSE (2) desenho das telas (2) descr. interface (1) objetos interface 5 - 100 %
OMT (2) desenho das telas (2) fluxo de informao e controle 4 - 80 %
Fusion _ -
A tabela 4.6 apresenta a interface do sistema, onde o mtodo Fusion no modela nem faz referncia ao aspecto. Os demais mtodos modelam telas e fazem descries, onde OOSE apresenta o objeto de interface peculiar a ele. Os mtodos OOAD e OOA-OOD sugerem o uso de prototipao para auxiliar o trabalho. Os mtodos OOSE, OMT e OOA-OOD recebem nvel MXIMO e o mtodo OOAD recebe nvel MDIO BAIXO.
Tabela 4.7 Estrutura de classes OOAD (2) classe (2) atributo (2) operao (1) notas (2) restries (2) propriedades (1) contr. exportao (1) classe parametriz. (1) categoria classe (1) metaclasse (1) aninhamento class 16 - 100 %
OOSE (2) objeto entidade (2) atributo (1) objeto interface (1) objeto controle (1) tipo de atributo (1) cardinalidade atr.
OMT (2) classe (2) atributo (2) operao (2) restries (1) ordenao
OOA-OOD (2) classe (2) atributo (2) operao (2) classe&objeto
Fusion (2) classe (2) atributo (2) cardinalidade
8 - 50 %
9 - 56.3 %
8 - 50 %
6 - 37.5 %
Atravs da tabela 4.7, observa-se que o mtodo OOAD possui maior quantidade de elementos notacionais recebendo nvel MXIMO para a estrutura de classes, por ser o mais completo. Os mtodos OOSE, OMT e OOA-OOD recebem nvel MDIO ALTO porque possui menos elementos. O mtodo Fusion possui modelagem MNIMA.
77
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.8 Estrutura de objetos OOAD OOA-OOD (2) objetos (2) objetos (2) relacionamentos (2) relacionamentos (1) chave (2) restrio (2) visibilidade (1) notas 10 100 % 4 - 40 %
OOSE (2) objetos interface (2) objetos controle (2) objetos entidade (2) relacionamentos 8 - 80 %
OMT (2) objetos (2) relacionamentos (1) valores atributos
Fusion (2) objetos (2) relacionamentos (1) valores (1) coleo objetos (2) visibilidade 8 - 80 %
5 - 50 %
Para a estrutura de objetos, os mtodos OOSE, OOAD e Fusion tm nvel MXIMO, pois so mais abrangentes neste aspecto como mostra a tabela 4.8. O mtodo OOSE possui uma abordagem bastante diferente dos outros mtodos com a criao de vrios tipos de objetos. O mtodo OMT recebe nvel MDIO ALTO e o mtodo OOA-OOD possui fraca modelagem e obtm nvel MDIO BAIXO.
Tabela 4.9 Descrio de classes OOAD OOA-OOD (2) texto descritivo (1) notas (2) atributos (2) atributos (2) operaes (2) operaes (1) restries (1) especificaes (1) mquina estados adicionais (1) contr. exportao (1) diagrama estado (1) cardinalidade (1) entrada externa (1) parmetros (1) sada externa (1) persistncia (1) requisit. memria (1) concorrncia (1) requisitos tempo 13 - 100 % 11 - 84.6 %
OOSE OMT (2) desc. obj entidade (2) texto descritivo (2) desc. obj controle (2) desc. obj interface
Fusion (2) superclasse (2) atributos (2) operaes (1) tipo de atributo (1) mutabilidade (const / var) (1) parmetros
6 - 46.2 %
2 - 15.4 %
9 - 69.2 %
Atravs da anlise da tabela 4.9, para a descrio de classes, nota-se que o mtodo OOAD e OOA-OOD apresentam nvel MXIMO, por oferecerem bons modelos para descrever as classes. O mtodo Fusion apresenta um modelo mais simples e recebe nvel MDIO ALTO. Nvel MNIMO para o mtodo OOSE e nvel MNIMO para o mtodo OMT porque apenas menciona o nome que dado ao modelo, onde se descreve as classes, sem apresentar nenhuma definio formal.
Tabela 4.10 Troca de mensagens OOAD OOA-OOD (2) mensagens (2) mensagens (2) objetos (2) objetos (1) seqncia (1) descrio (1) parmetros (2) sincronizao 9 - 100 % 4 - 44.4 %
OOSE (2) mensagens (2) objetos (1) seqncia (1) descrio (1) parmetros 7 - 77.8 %
OMT (2) relacionamentos (2) objetos
4 - 44.4 %
Fusion (2) mensagens (2) objetos (1) seqncia (1) retornos (1) parmetros (1) restrio 8 - 88.9 %
Os mtodos OOSE, OOAD e Fusion possuem nvel MXIMO para a troca de mensagens, como mostra a tabela 4.10, por modelarem o aspecto com bons elementos de notao, os demais mtodos modelam as mensagens sem nenhum detalhe e recebem nvel MDIO BAIXO. 78
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.11 Relacionamentos OOAD OOA-OOD (2) cardinalidade (2) cardinalidade (1) rel. instanciao (2) relacionamentos (1) papel (2) atrib. associao (1) chave (2) restrio (1) relac. associao (1) relac. metaclasse (1) relacion. usa (1) relacion. tem 13 100 % 4 - 30.8 %
OOSE (2) cardinalidade (2) relacionamentos (2) relacion. extends (2) relacion. uses
OMT (2) cardinalidade (2) relacionamentos (1) papel (2) atributo ligao (1) chave candidata (2) restrio (2) assoc. ternria (1) qualificador 13 - 100 %
Fusion (2) cardinalidade (2) relacionamentos (1) papel (2) atrib. relacionam. (1) marcador totalidd (2) relac. visibilidade
8 - 61.5 %
10 - 76.9 %
A tabela 4.11 apresenta os elementos notacionais oferecidos pelos mtodos para modelagem dos relacionamentos. Os mtodos OMT e OOAD modelam com nvel MXIMO. Os mtodos OOSE e Fusion possuem menos elementos e recebem nvel MDIO ALTO. O mtodo OOA-OOD recebe nvel MDIO BAIXO devido a fraca modelagem.
Tabela 4.12 Estrutura de agregao OOAD OOA-OOD (2) classe (2) classe (2) agregao (2) agregao (1) contedo p/ valor (1) contedo p/ refer. 6 100 % 4 - 66.7 %
OOSE (2) objeto (2) agregao 4 - 66.7 %
OMT (2) classe (2) agregao 4 - 66.7 %
Fusion (2) classe (2) agregao 4 - 66.7 %
Pela anlise da tabela 4.12, o mtodo OOAD possui nvel MXIMO por apresentar melhor modelagem ao aspecto de agregao, com dois elementos a mais que os demais mtodos no oferecem, os quais recebem nvel MDIO ALTO.
Tabela 4.13 Estrutura de herana OOAD OOA-OOD (2) classe (2) classe (2) herana (2) herana (2) herana mltipla (2) herana mltipla
OOSE (2) classe (2) herana (2) herana mltipla
6 - 66.7 %
OMT (2) classe (2) herana (2) herana mltipla (1) classe disjunta (1) classe no disj. (1) discriminador 9 - 100 %
Fusion (2) classe (2) herana (2) herana mltipla (1) classe disjunta (1) classe no disj. 8 - 88.9 %
6 - 66.7 %
6 - 66.7 %
Para a estrutura de herana, apresentada pela tabela 4.13, os mtodos OMT e Fusion destacam-se com vrios elementos semnticos recebendo nvel MXIMO, os demais mtodos apresentam modelos mais simples e obtm nvel MDIO ALTO. A tabela 4.14 apresenta a modelagem de estados, onde os mtodos OOSE, OMT e OOAD possuem nvel MXIMO, em que o primeiro apresenta um modelo bastante diferente dos dois ltimos. O mtodo OOAD apresenta modelo idntico ao OMT, mas modela menos aspectos
79
referentes ao estado dos objetos. O mtodo OOA-OOD obtm nvel MDIO BAIXO porque modela somente os estados e suas transies. O mtodo Fusion no apresenta modelagem.
Tabela 4.14 Modelagem de estados OOAD OOA-OOD (2) estado (2) estado (2) incio (2) incio (2) transio (2) transio (2) fim (2) evento (2) guarda (condio) (2) atividade (1) ao de entrada (1) ao de sada (1) histria (1) super-estado 18 - 90 % 6 - 30 %
OOSE (2) estado (2) incio (1) rtulo (2) destruir objeto (2) enviar mensagem (2) deciso (cond.) (1) receber mensag. (1) retorno mensag. (1) enviar sinal (1) receber sinal (2) executar tarefa 17 - 85 %
OMT (2) estado (2) incio (2) transio (2) fim (2) evento (2) condio (2) atividade (1) ao de transio (1) ao de entrada (1) ao de sada (1) super-estado (1) sincronizar contr. (1) concorr. diagrama 20 - 100 %
Fusion _
A tabela 4.15 apresenta aspectos funcionais, onde os mtodos OMT e Fusion so os nicos a apresentar modelagem funcional e bem detalhada, obtendo nvel MXIMO.
Tabela 4.15 Aspectos funcionais OOAD _
OOSE _
OMT (1) descrio (2) processos (2) atores (2) fluxo de dados (2) fluxo de controle (2) depsito de dados 11 - 100 %
OOA-OOD _
Fusion (1) descrio (2) leitura de valor (2) alterao de valor (2) comunic. agente (1) pr-condies (1) ps-condies 9 - 81.8 %
A identificao de funcionalidades, apresentada pela tabela 4.16, mostra que os mtodos OOSE, OMT e Fusion modelam este aspecto com mais elementos notacionais que os demais. O mtodo OOAD recebe nvel MNIMO e o mtodo OOA-OOD no apresenta modelagem.
Tabela 4.16 Identificao de funcionalidades OMT OOAD OOA-OOD (1) descrio (1) descrio _ (2) agentes externos (2) sistema (2) interao 7 - 100 % 1 - 14.3 % -
OOSE (1) descr. use cases (2) use case (2) atores (2) interao 7 - 100 %
Fusion (1) descrio (2) agentes externos (2) sistema (2) interao 7 - 100 %
Para a criao de subsistemas, apresentada pela tabela 4.17, com exceo do mtodo Fusion, que no possui modelagem, todos os mtodos subdividem sistemas complexos e grandes para sua simplificao.
80
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.17 Criao de subsistemas OOAD OOA-OOD (2) subsistemas (2) assunto 2 - 100 % 2 - 100 %
OOSE (2) subsistemas 2 - 100 %
OMT (2) processo 2 - 100 %
Fusion _ -
A tabela 4.18 apresenta a alocao de subsistemas, onde observa-se que o mtodo OOAD o nico a oferecer modelagem. Entretanto os mtodos OOSE e OMT descrevem sobre o assunto.
Tabela 4.18 Alocao de subsistemas OOAD (2) processador (2) processos 4 - 100 %
OOSE _ -
OMT _ -
OOA-OOD _ -
Fusion _ -
Somente o mtodo OOA-OOD apresenta modelagem para estabelecer prioridades, apresentada pela tabela 4.19, obtendo nvel MXIMO. Entretanto o mtodo OMT, assim como os demais mtodos, faz descrio da necessidade de se modelar sem apresentar modelos.
Tabela 4.19 Estabelecer prioridades OOAD OOA-OOD _ (2) descrio (2) estrutura classes 4 - 100 %
OOSE _ -
OMT _ -
Fusion _ -
A tabela 4.20 apresenta o detalhamento de operaes, observa-se que os mtodos OOSE, OOAD e Fusion recebem nvel MXIMO, porque apresentam bons esquemas para detalhar as operaes. O mtodo OOA-OOD recebe nvel MDIO ALTO porque apesar de ter uma boa modelagem, esta no to abrangente quanto a dos outros mtodos. O mtodo OMT possui nvel MDIO BAIXO porque descreve o assunto sugerindo a utilizao de algoritmos.
Tabela 4.20 Detalhamento de operaes OOAD OOA-OOD (2) descrio (2) bloco (descrio) (2) operao (2) operao (2) argumentos (1) loop (1) pr-condies (2) condio (1) ps-condies (1) sequncia (1) controle export. (2) concorrncia (1) tempo complexidade 12 - 100 % 8 - 66.7 %
OOSE (2) descrio (2) operao (2) parmetros (2) condio (1) objetos (1) loop
OMT (2) descrio (2) operao
10 - 83.3 %
4 - 33.3 %
Fusion (2) descrio (2) operao (2) parmetros (1) pr-condio (1) ps-condio (1) vlr. acessados (1) vlr. modificados (1) vlr. enviados usuario 11 - 91.7 %
Sobre o tratamento de concorrncia, apresentado pela tabela 4.21, observa-se que o mtodo OOAD possui excelente modelagem e recebe nvel MXIMO. Os demais mtodos no apresentam modelagem, todavia o mtodo OMT discorre sobre o assunto.
81
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.21 Tratamento de concorrncia OOAD OOA-OOD (2) mensag. sncrona _ (2) mensag. simples (2) mensag. balking (2) mensag. c/ tempo (2) mens. assncrona 10 - 100 % -
OOSE _
OMT _
Fusion _
O mtodo OOSE o nico a possuir foco na anlise de requisitos, com vrios modelos oferecidos, como pode-se observar na tabela 4.22.
Tabela 4.22 Foco - anlise de requisitos OOAD OOA-OOD _ _
OOSE (2) modelo use case (2) descr. use case (2) modelo domnio problema (2) modelo interface 8 - 100 %
OMT _
Fusion _
O foco na fase de anlise dado somente pelos mtodos OMT e Fusion, que oferecem vrios modelos. Os mtodos OOSE, OOAD e OOA-OOD apresentam poucos modelos e recebem nvel MDIO BAIXO, como apresenta a tabela 4.23.
Tabela 4.23 Foco - anlise OOSE OMT OOAD (2) modelo de anlise (2) diagr. de classes (2) diagr. de classes (2) descrio objetos (1) diagr. instncias (2) diagr. de objetos (1) diagrama p/ (1) diagr. de interface (2) diagr. interao detalhar atributo (1) dicionrio dados (1) cenrios (2) diagr. de eventos (1) diag. fluxo evento (2) diagr. de estados (1) diagr. valores de entrada e sada (2) diagr. fluxo dados (1) descr. funes 5 - 33.3 % 15 - 100 % 6 - 40 %
OOA-OOD (2) modelo de anlise (2) diagr. de servios (1) diagr. estado obj. (2) especif. classes
Fusion (1) dicionrio dados (2) modelo de objetos (2) mod. obj. sistema (1) modelo interface (2) mod. ciclo-d-vida (2) diagr. de tempo (1) esquema operao
7 - 46.7 %
11 - 73.3 %
Como mostra a tabela 4.24, o foco na fase de projeto melhor abordado pelos mtodos OOAD com refinamento dos dois primeiros modelos e criao de outros trs e OOA-OOD com o modelo de projeto dividido em quatro componentes, recebendo nvel MXIMO. O mtodo OOSE com trs modelos recebe nvel MDIO ALTO. O mtodo Fusion com dois modelos recebe nvel MDIO BAIXO e o mtodo OMT oferece somente o refinamento do diagrama de classes com adio das operaes. 82
Captulo 4 - Comparao entre os mtodos orientados a objetos ________________________________________________________________________________________________ Tabela 4.24 Foco - projeto OOAD (1) diagr. de classes (2) diagr. de objetos (2) diagr. transio estado (2) diagr. mdulos (2) diagr. processos 9 - 100 %
OOSE OMT (2) modelo de projeto (1) diagr. de classes (2) diagr. interao use case (2) grafo transio estado 6 - 66.7 % 1 - 11.1 %
OOA-OOD Fusion (1) mod. projeto CDP (2) grafo inter. obj. (2) mod. projeto CIH (2) descr. de classe (2) mod. projeto CGT (2) mod. proj. CGD 7 - 77.8 % 4 - 44.4 %
A tabela 4.25 retrata o qu e como os mtodos, no caso OMT, OOA-OOD e Fusion, modelam, que os caracterizam com enfoque orientado a dados. Todos os mencionados acima tem como preocupao primeira, a identificao de classes e objetos, dos atributos e dos relacionamentos. Somente depois que se identifica as operaes, importante notar que o OMT s faz essa identificao na fase de projeto.
Tabela 4.25 Abordagem - dados OOAD OOA-OOD Fusion _ (2) id. classe&objetos (2) ident. classe/obj. (2) ident. estruturas (2) ident. atributos (2) ident. atributos (2) ident. relacionam. 6 - 100 % 6 - 100 %
OOSE _ -
OMT (2) ident. classe/obj. (2) ident. associaes (2) ident. atributos 6 - 100 %
Os mtodos OOSE e OOAD possuem uma abordagem comportamental, como pode ser observado pela tabela 4.26. Estes mtodos primeiramente, procuram identificar as funcionalidades do sistema, descrev-las, para posteriormente identificar classes, atributos e relacionamentos, com base nas funcionalidades definidas.
Tabela 4.26 Abordagem - comportamental OOAD OOA-OOD (2) diagrama objetos _ (2) mquina estados
OOSE (2) modelo use cases (1) descr. use cases (2) descr. interface (2) modelo domnio problema 7 - 100 %
OMT _
Fusion _
4 - 57.1 %
Observe que os aspectos identificao de atributos e identificao de operaes da tabela 4.2, no sero descritos separadamente como os demais, porque a modelagem de nvel MXIMO para todos os mtodos, para os dois aspectos citados acima, pois todos os mtodos apresentam notao e captura desses itens com o mesmo detalhe. A tabela 4.27 apresenta o nvel de modelagem de um mtodo em relao aos outros para cada um dos aspectos descritos, sumariando o que foi apresentado pelas tabelas 4.4 at 4.26. A seguir apresentada a cobertura que cada mtodo possui em relao as fases do desenvolvimento.
83
Captulo 4 - Comparao entre os mtodos orientados a objetos _________________________________________________________________________________________________________________________________________________
Tabela 4.27 Resumo dos nveis de modelagem recebidos pelos mtodos para cada aspecto capturado
Aspectos capturados Identificao de requisitos Identificao de eventos Interface do sistema Estrutura de classes Estrutura de objetos Descrio de classes Troca de mensagens Relacionamentos Estrutura de agregao Estrutura de herana Modelagem de estados Aspectos funcionais Ident. de funcionalidades Criao de subsistemas Alocao de subsistemas Estabelecer prioridades Detalhamento operaes Tratamento concorrncia Foco - anlise requisitos Foco - anlise Foco - projeto Abordagem - dados Abord. - comportamental MXIMO MXIMO MDIO ALTO MDIO ALTO MNIMO MDIO BAIXO MXIMO MDIO ALTO MXIMO MXIMO MXIMO MXIMO MXIMO MDIO BAIXO MXIMO MNIMO MXIMO MNIMO MDIO BAIXO MXIMO MXIMO MXIMO MXIMO MXIMO MXIMO MDIO ALTO MXIMO MNIMO MXIMO MXIMO MXIMO MXIMO MDIO BAIXO MXIMO MDIO ALTO MXIMO MDIO ALTO MDIO BAIXO MXIMO MDIO BAIXO MDIO BAIXO MDIO ALTO MDIO ALTO MDIO BAIXO MXIMO MXIMO MDIO ALTO MDIO BAIXO MXIMO MXIMO -
OOSE MXIMO
OMT -
MTODOS OOAD OOA-OOD -
Fusion MXIMO MNIMO MXIMO MDIO ALTO MXIMO MDIO ALTO MDIO ALTO MXIMO MXIMO MXIMO MXIMO MDIO ALTO MDIO BAIXO MXIMO -
MXIMO MXIMO MDIO ALTO MXIMO MDIO BAIXO MXIMO MDIO ALTO MDIO ALTO MDIO ALTO MXIMO MXIMO MXIMO MXIMO MXIMO MDIO BAIXO MDIO ALTO MXIMO
e 3.7, cobrem diferentes fases do desenvolvimento, que ilustrado pela figura 4.2. Esta figura apresenta as fases do desenvolvimento de software tendo como base o modelo cascata (Pressman, 1995). O objetivo destacar a cobertura que o mtodo oferece em cada uma das fases. Isto foi possvel depois do estudo e comparao dos mtodos.
O primeiro item da legenda, MXIMO, reflete que o mtodo faz uma descrio da fase, apresenta muitos elementos de notao e oferece exemplos conforme a descrio na literatura proposta (Jacobson, 1992), (Rumbaugh, 1994), (Booch, 1994), (Coad, 1992) e (Coad, 1993) e (Coleman, 1996). O segundo item, MDIO, indica que h descrio da fase, apresentando modelos com poucos elementos de notao. O terceiro item, MNIMO, revela que o mtodo somente descreve a fase sem apresentar modelos ou exemplos. O quarto item, NENHUMA, indica que o mtodo no menciona a fase, no h descrio, exemplificao ou modelos. Pela figura 4.2 pode-se notar que na fase de anlise de requisitos, o mtodo OOSE apresenta cobertura MXIMA com vrios modelos. O mtodo OOAD descreve a fase e os demais no possuem modelagem. Todos os mtodos tem cobertura MXIMA na fase de anlise, com exceo de OOA-OOD, que oferece pouca notao. Na fase de projeto, os mtodos OOSE, OOAD e Fusion se destacam com cobertura MXIMA. O mtodo OMT cobre a fase com descrio de passos e o mtodo OOA-OOD cobre com pouca notao. Todos os mtodos descrevem a fase de implementao. Com exceo do mtodo OOSE, que descreve a fase de teste e do mtodo OOAD, que descreve a fase de manuteno, os outros mtodos no mencionam estas duas ltimas fases.
" # " '('%&$!

Os cinco mtodos orientados a objetos apresentados no captulo 3, sees 3.3, 3.4, 3.5, 3.6
\ Fases \ Mtodos OOSE OMT OOAD OOAOOD FUSION Anlise de Requisitos Anlise Projeto Implementao Teste Manuteno Legenda:
MXIMA MDIA MNIMA NENHUMA
Figura 4.2 - Cobertura dos mtodos
85
Um critrio foi definido para possibilitar a comparao entre os mtodos. Verifica-se que cada mtodo possui uma melhor modelagem em determinados aspectos. Assim, refora-se a afirmao de que no existe um mtodo melhor, mas sim um mtodo mais adequado ao desenvolvimento de um determinado domnio de aplicao, que possua caractersticas mais apropriadas quele mtodo. Com a finalidade de fazer um resumo, foi apresentado a cobertura que os mtodos possuem em relao a cada fase do desenvolvimento. Atravs do estudo completo dos mtodos, pode-se retirar algumas concluses enumeradas separadamente pelos mtodos como segue. 1. Mtodo OOSE: i) o nico a oferecer modelagem e orientao sobre a identificao dos requisitos, os demais partem do princpio de que os requisitos esto bem definidos e devidamente documentados; ii) A modelagem sugerida define que alguns modelos sero feitos na sub-fase de anlise de requisitos, e que alguns modelos de projeto, geralmente definidos pelos outros mtodos nesta fase, so feitos na fase de anlise, assim, obtm-se um tempo precioso que pode ser despendido durante a fase de projeto. 2. Mtodo OMT: i) Possui modelos abrangentes na fase de anlise, onde o sistema visto por trs diferentes dimenses: esttico, dinmico e funcional; onde os demais s apresentam os dois primeiros. Entretanto, um mtodo com praticamente nenhuma modelagem na fase de projeto; ii) um mtodo prescritivo, porque informa exatamente qual a seqncia de passos a seguir para gerar os modelos . 3. Mtodo OOAD: i) Sua primeira verso continha somente a fase de projeto, em 1991. Posteriormente, foi incorporado a fase de anlise. Isso justifica sua forte modelagem em projeto; ii) Oferece modelos de projeto que capturam aspectos que os outros mtodos no mencionam, como visibilidade e concorrncia; iii) Direciona para o uso de tcnicas de outros metodologistas como: CRC - Classe Responsabilidade Colaborador18 - Wirfs-Brock, e cenrios e use cases - Jacobson. 4. Mtodo OOA-OOD: i) Foi um dos primeiros mtodos orientados a objetos a ser desenvolvido (entre as dcadas de 80 e 90) (Fichman, 1992), se tornando uma referncia para a criao dos outros mtodos, os
18
A tcnica CRC uma tcnica exploratria e no um mtodo completo, que foi projetada originalmente para ensinar os conceitos bsicos do projeto orientado a objeto (Coleman, 1996).
% " )('&$#!
86
quais puderam melhorar os pontos deficientes do mtodo base, assim como aperfeioar o mtodo como um todo; ii) Apresenta os modelos multicamadas (anlise) e multicomponentes (projeto), onde este ltimo conter camadas, quer dizer, durante o projeto faz-se o refinamento do modelo de anlise; iii) um mtodo bastante simples e prescritivo, sendo indicado para desenvolvedores inexperientes. 5. Mtodo Fusion: i) um mtodo integrador, porque rene elementos de anlise do OMT (modelo de objetos e caractersticas de DFD), de projeto do Booch (visibilidade), tcnica CRC e as pr e ps condies dos mtodos formais, alm de apresentar outros modelos interessantes; ii) bastante completo, mas no oferece cobertura a todos os aspectos. Com base na comparao feita entre os mtodos, o captulo 5 apresenta as questes a serem apresentadas ao engenheiro de software, a teoria de funo de crena, o algoritmo utilizado e todos os detalhes pertinentes.
87
Proposta de um sistema de apoio a deciso utilizando teoria de funo de crena

Neste captulo apresentada uma proposta de um sistema, que tem como objetivo auxiliar o engenheiro de software a decidir qual mtodo orientado a objetos o mais adequado no desenvolvimento de um determinado domnio de aplicao. Para alcanar esse objetivo, o sistema de apoio a deciso (SAD) gera um questionrio que respondido pelo engenheiro de software tendo como base o sistema a ser desenvolvido. O SAD faz uma anlise sobre as respostas obtidas e fornece uma pontuao aos mtodos, entre 0-100, em cada fase do desenvolvimento19. Esta anlise realizada com a ajuda da teoria de funo de crena definida na prxima seo.
Como a teoria de funo de crena utilizada neste trabalho, so descritos seus principais conceitos para melhor compreenso do assunto, visto que esta teoria comumente no utilizada na engenharia de software. As fontes de consulta para descrio dos conceitos foram (Carvalho, 1996), onde se apresenta uma aplicao da teoria; e (Silva, 1991), onde se obtm um vasto detalhamento sobre o assunto. A teoria de Dempster e Shafer ou teoria da evidncia, mais conhecida como teoria de funo de crena definida em termos de domnios discretos finitos, conhecidos como quadro de discernimento e denotado por . Um quadro de discernimento () ou quadro um conjunto finito de proposies, mutuamente exclusivas, das quais a nica verdadeira desconhecida. Neste trabalho o quadro utilizado definido como: = { a, b, c, d, e } onde: a = mtodo OOSE - Jacobson et. al.; b = mtodo OMT - Rumbaugh et. al.; c = mtodo OOAD - Booch; d = mtodo OOA-OOD - Coad & Yourdon; e = mtodo Fusion - Coleman et. al..
19
Os mtodos tratados so os mesmos abordados no captulo 3. As fases de desenvolvimento so as limitadas pelo estudo dos mtodos: anlise de requisitos, anlise e projeto.
(8 !% !0 # 8 6 2 !0 & #! "96'"'AB17@"974531)('%$$"

88
Captulo 5 - Proposta de um sistema de apoio a deciso utilizando teoria de funo de crena ________________________________________________________________________________________________

Um subconjunto

de pode ser visto como uma disjuno das proposies que lhe
pertencem. Desta forma, tambm uma proposio com as seguintes propriedades: Se p e p a proposio verdadeira, ento tambm uma proposio verdadeira; Se um subconjunto de e ento . A funo de Cr: 2 [0,1] satisfaz as seguintes condies: Cr () = 0 Cr () = 1 Para cada subconjunto de , o nmero Cr( ) pode ser interpretado como o grau de crena de que a proposio verdadeira est em . A funo de crena Cr pode ser expressa por uma funo de densidade de probabilidade Pr da seguinte forma: Seja um subconjunto de e um subconjunto aleatrio de , , ento: Cr ( ) = Pr [ ] = { Pr[ = ] | } Cr ( ) a probabilidade de ser um subconjunto de . Para cada funo de crena Cr h uma nica funo m : 2 [0,1], chamada massa bsica de crena, ou massa de crena (m), tal que m distribui a massa de crena unitria entre os

subconjuntos de . Assim, m( ) = Pr ( associado a Cr. Suas propriedades so: m() = 0 { m( ) | } = 1

), para todo
, onde
o conjunto aleatrio
A quantidade m( ) chamada de crena bsica em e mede a crena que atribuda exatamente a e a nenhum de seus subconjuntos prprios. A funo m( ) pode ser vista como a probabilidade do mtodo a ser exatamente igual a . A funo de crena Cr pode ser obtida de sua massa bsica de crena m pela equao:

Cr ( ) = { m( ) |
}, para todo
.c .e .d
.b
Funo de crena (Cr) Cr ( ) = 0.3 Cr ( ) = 0.25 Cr ( ) = 0.6 Cr () = 1.0

= { ,
, ,
A figura 5.1 ilustra um exemplo sobre a massa bsica de crena e funo de crena. Pela figura observa-se que a massa de crena em de 0.3 e em de 0.25. A funo de crena em 89

Figura 5.1 - Crena b sica em
.a
Massa bsica de crena (m) m ( ) = 0.3 m ( ) = 0.25 m ( ) = 0.35 m () = 0.1

de soma as massas de crena de e , porque subconjunto de . Assim, a funo de crena no o somatrio de todas as massas de crena de seus subconjuntos. Ao conjunto = { | e m( ) > 0 } dado o nome de conjunto focal de Cr e seus elementos so chamados elementos focais de Cr. Apesar da teoria possibilitar trabalhar com todos os subconjuntos de um dado , neste trabalho ser aplicado a crena em subconjuntos atmicos de e no prprio . Isto , cada subconjunto contm apenas um elemento, um mtodo. A seguir apresentado o algoritmo utilizado para combinar as funes de crena, ele conhecido como Regra de Dempster ou soma ortogonal.
Visando obter a combinao das funes de crena definidas, ser utilizada regra de Dempster ou regra para formao da soma ortogonal. Sejam Cr1 e Cr2 duas funes de crena sobre o Seja K-1 = { m1(
Se K-1 > 0 e Cr1 e Cr2 so suportadas por evidncias independentes, ento elas so combinveis e a massa bsica de crena m da funo resultante representada por m( ) = K x { m1( 1) x m2( 2) | 1 1, } 2 2, 1 2 = Donde se conclui que a soma ortogonal Cr = Cr1 Cr2 tem um conjunto focal = { 1 2 | 1 1, 2 2, 1 2 }
As funes de crena definidas neste trabalho so chamadas bayesianas, porque todos os elementos focais so atmicos, exceto . Deste modo, o algoritmo a ser utilizado uma especializao da soma ortogonal, sendo definido em linguagem natural e ilustrado pela figura 5.2. O algoritmo definido na figura 5.2 combina duas funes de crena bayesianas, onde m1 e m2 so vetores que armazenam uma funo de crena cada. Estas funes so retiradas do arquivo AFC que armazena todas as funes de crena. O algoritmo combina as funes de crena de uma mesma fase. Quer dizer que ao final, obter-se- a crena nos mtodos mais indicados para cada fase (anlise de requisitos, anlise e projeto). A matriz mf armazena a funo de crena final para cada fase do desenvolvimento. O procedimento Normaliza faz a normalizao da funo de crena final de cada fase e executado antes dos valores serem armazenados em mf. importante ressaltar que a normalizao necessria para redistribuir a massa contida em subconjuntos vazios. Isso deve-se a definio m() = 0.
90
1)
x m2(
2)
1,
2,
'7BA3$9 876542)0%(#'&#$" 3 @ ! 3 % # 3 1 % !
continuam com os mesmos valores atribudos a suas massas de crenas, mas a funo de crena
Principal: SomaOrtogonal incio // definio das incgnitas utilizadas AFC { arquivo de funes de crena } m1, m2 { vetor local de 6 posies } mf { matriz global de 6 linhas e 3 colunas } i, fa, fg { variveis globais de controle - indice, fase atual, fase guardada} // execuo do algoritmo m1 proximafuncao(AFC) fg faseatual enquanto AFC final faa m2 proximafuncao(AFC) fa faseatual se fa fg ento Normaliza(m1) ArmazenaFase(mf, m1) m1 m2 fg fa seno para i de 1 at 5 faa 1 m1[i] m1[i] * m2[i] + m1[i] * m2[0] + m1[0] * m2[i] fim para m1[0] m1[0] * m2[0] 2 fim se; fim enquanto Normaliza(m1) ArmazenaFase(mf, m1) fim. Procedimento: Normaliza (vetor) incio SM 0; para i de 0 at 5 faa SM SM + m1[i] fim para para i de 0 at 5 faa m1[i] m1[i] / SM fim para fim. Procedimento: Armazena (matriz por referncia, vetor) incio para i de 0 at 5 faa matriz[i,fa] m1[i] fim para fim.
Figura 5.2 - Algoritmo em linguagem natural do algoritmo especializado da soma ortogonal

91
Visando uma melhor compreenso do algoritmo adotado, segue um rastreamento para duas funes de crena. Sejam m1 e m2 o mapeamento de duas funes de crena: Funo de crena m1 Funo de crena m2 m1 () = 0 m2 () = 0.14 m1 ({a}) = 0.23 m1 ({b}) = 0.18 m1 ({c}) = 0.28 m1 ({d}) = 0.18 m1 ({e}) = 0.13 m2 ({a}) = 0.27 m2 ({b}) = 0.17 m2 ({c}) = 0.21 m2 ({d}) = 0 m2 ({e}) = 0.21
Antes de executar a linha indicada pelo nmero 1 na figura 5.2, os valores dos vetores m1 e m2 encontram-se como apresentados pela figura 5.3, seguindo o mapeamento definido anteriormente.
0 m1 m2 0 0.14 {a} 1 0.23 0.27 {b} 2 0.18 0.17 {c} 3 0.28 0.21 {d} 4 0.18 0 {e} 5

0.13 0.21
= { {a}, {b}, {c}, {d}, {e} } = { {a}, {b}, {c}, {e}, }
Figura 5.3 - Mapeamento das fun es de crena m1 e m2
Aps a combinao das duas funes, o vetor m1 apresenta-se como ilustrado pela figura 5.4, aps a execuo da linha indicada pelo nmero 2 na figura 5.2.
0 m1 0 {a} 1 {b} 2 {c} 3 {d} 4 {e} 5 = { {a}, {b}, {c}, {d}, {e} }
0.0943 0.0558 0.0980 0.0252 0.0455
Figura 5.4 - Vetor m1 antes da normaliza o
Aps a normalizao realizada pelo procedimento Normaliza(vetor), apresentado pela figura 5.2, o vetor m1 encontra-se com os valores como ilustrado pela figura 5.5.
0 m1 0 {a} 1 0.30 {b} 2 0.17 {c} 3 0.31 {d} 4 0.08 {e} 5 0.14 = { {a}, {b}, {c}, {d}, {e} }
Figura 5.5 - Vetor m1 aps normaliza o
92
Se houvessem mais evidncias, o resultado obtido na figura 5.5 seria combinado com a prxima evidncia, e assim por diante; como definido pelo algoritmo. Com o conhecimento da funo de crena e do algoritmo, a prxima seo explica com mais detalhes a proposta do sistema de apoio a deciso.
(Nascimento, 1990). Esta proposta tem como objetivo indicar o mtodo estruturado, o modelo de processo e a abordagem mais indicados no desenvolvimento de um sistema especfico. Para tanto, apresentado um questionrio com o objetivo de identificar quais so as caractersticas do sistema a ser desenvolvido. Tambm neste trabalho utilizado uma tcnica de Inteligncia Artificial, mais especificamente, um sistema especialista20 para auxiliar no processo de indicao do mtodo, modelo de processo e abordagem mais apropriados. A proposta descrita no presente trabalho tem como objetivo apresentar uma pontuao dos mtodos orientados a objetos que indica os mais adequados ao desenvolvimento de um determinado domnio de aplicao. Ser, ento, utilizada a teoria de funo de crena para ajudar nesta indicao. No captulo 3, foram descritos cinco mtodos orientados a objetos e, paralelamente, desenvolvida a modelagem de partes de um sistema de biblioteca. Essa modelagem facilitou o estudo dos mtodos e da identificao de seus pontos positivos e negativos. Aps finalizao deste estudo foi possvel relacionar os aspectos modelados pelos mtodos, realizado no captulo 4. Para cada aspecto foram relatados os elementos notacionais oferecidos e definidos por cada mtodo, expressos em tabelas. Essas tabelas identificam os mtodos que melhor modelam cada aspecto. Neste captulo so apresentadas as questes definidas com base no trabalho citado anteriormente (Nascimento, 1990) e com ajuda de engenheiros de software com grande experincia no desenvolvimento de sistemas. Estas questes possibilitam identificar as caractersticas do sistema a ser desenvolvido. Muitas vezes uma caracterstica do sistema exige que o mtodo modele mais de um dos aspectos definidos no captulo 4. Por exemplo, se houver muito desconhecimento sobre os requisitos do sistema, o mtodo deve modelar a identificao dos requisitos e das funcionalidades e ter o foco em anlise de requisitos. Deste modo, cada questo definida neste trabalho, geralmente, faz o mapeamento para mais de um aspecto capturado pelo mtodo. A prxima seo apresenta todas as questes e os aspectos relacionados e o mapeamento das evidncias (caractersticas) aos mtodos.
20
Um sistema especialista soluciona problemas que normalmente so solucionados por "especialistas" humanos (Rich, 1994). No trabalho em questo so utilizadas regras de produo, que expressam certeza sobre determinadas evidncias. Deste modo, pode-se obter o conhecimento armazenado, segundo regras definidas pelo especialista. Maiores detalhes (Nascimento, 1990).
1 " % ' % )&0")(&#$"!

A proposta realizada neste trabalho teve como fonte inspiradora a proposta de Nascimento 93
Esta seo apresenta 22 questes que compem o questionrio. Cada uma do tipo que exige resposta Sim ou No, ou do tipo que exige um grau entre zero e 100, que determina a porcentagem de conhecimento sobre o assunto abordado pela pergunta. Cada questo se encontra em tabela separada, que segue o modelo definido pela tabela 5.1.
Tabela 5.1 Tabela modelo para apresentao das questes
A D
B - descrio da questo; C - indica o tipo da questo: SN, quando a questo exigir resposta do tipo Sim/No; GR, quando for solicitado ao usurio informar o grau de conhecimento; D - relao dos aspectos capturados e respectivas tabelas do captulo 4, que so utilizadas como parmetro para determinar os graus de crena nos mtodos - peso, nmero da tabela, descrio do aspecto -; E - nmero da prxima pergunta se a resposta for SIM ou grau g > 0 %; F - nmero da prxima pergunta se a resposta for NO, grau g = 0 % ou no responder a questo; G - mapeamento para os mtodos; H - observaes sobre a pergunta, que engloba uma explicao para auxiliar o engenheiro de software a responder a pergunta, quando houver necessidade. As seguintes observaes so de grande relevncia para melhor entendimento dos critrios adotados: 1. No h dvida ou incerteza quanto as respostas oferecidas pelo engenheiro de software, que tem como base o sistema que ele pretende desenvolver; 2. Uma nica caracterstica ou questo no determina um mtodo ou subconjunto destes, pois todos os mtodos podem ser usados em qualquer desenvolvimento, entretanto, o SAD sugere os mtodos que oferecem melhor modelagem e suporte conceitual para desenvolver aquele tipo de sistema; 3. Quando o tipo de resposta for SN (Sim/No), atribui-se grau 100 para Sim e grau zero para No; 4. O mapeamento dado pela seguinte frmula:
! 5 ' 43 ! ) ' 2%6((210(&%!$" #!

B E G H A tabela 5.1 define cada uma das clulas utilizadas, como segue: A - nmero da questo; F C m( ) = { m2 ( ) + (m1 ( ) - m2 ( )) * g / 100 | 94 {{a},{b},{c},{d},{e},}}

onde:
m1 ( ) o mapeamento mximo para
m2 ( ) o mapeamento mnimo para ; g o grau informado. 5. O engenheiro de software no obrigado a responder a pergunta. Se ele no responder, o mapeamento definido questo ser desconsiderado e a prxima questo apresentada. Antes da apresentao das questes, necessrio uma explanao sobre a relao das questes com os aspectos capturados pelos mtodos e o mapeamento para os mtodos. Existem dois casos: no primeiro, todos os mtodos oferecem modelagem em pelo menos um aspecto definido para a questo. No segundo caso, um ou mais mtodos no modelam todos os aspectos definidos para a questo. Isto necessita de um mapeamento para o elemento para que o mtodo no seja excludo, como descrito anteriormente. Outro ponto importante que dentre o conjunto de tabelas relacionadas para modelagem de uma determinada caracterstica, pode existir casos onde algumas tabelas so mais importantes, recebendo peso 2. Caso contrrio, a tabela recebe peso 1 e quer dizer que a modelagem desse aspecto menos importante para a caracterstica em questo. Cada questo apresentada em uma tabela, seguindo o modelo definido na tabela 5.1. A questo 1 se encaixa no primeiro caso e refere-se a sete tabelas, conforme a seguinte descrio: peso 2, tabela 4.7 - Estrutura de classes; peso 1, tabela 4.9 - Descrio de classes; peso 2, tabela 4.11 - Relacionamentos; peso 1, tabela 4.12 - Estrutura de agregao; peso 1, tabela 4.13 Estrutura de herana; peso 2, tabela 4.22 - Foco - anlise de requisitos e peso 2, tabela 4.23 - Foco anlise, conforme indica clula D da tabela 5.2.
Tabela 5.2 Questo 1 - Anlise de requisitos
1 Qual o grau estimado de desconhecimento do domnio do problema? GR (2) 4.7 - Estrutura de classes 2 2 (1) 4.9 - Descrio de classes m({a}) = 0.21 * g / 100 m({d}) = 0.15 * g / 100 (2) 4.11 - Relacionamentos m({b}) = 0.22 * g / 100 m({e}) = 0.19 * g / 100 (1) 4.12 - Estrutura de agregao m({c}) = 0.23 * g / 100 m() = 1 - g / 100 (1) 4.13 - Estrutura de herana (2) 4.22 - Foco - anlise de requisitos (2) 4.23 - Foco - anlise
Informe se a equipe tem conhecimento sobre o tipo de sistema que se quer desenvolver, ou j desenvolveu sistema semelhantes ou idnticos, ou ainda, se tem algum membro da equipe que conhece o domnio do problema.
A relao entre essa questo e os aspectos mencionados, deve-se ao fato de que, se no existe conhecimento sobre o domnio do problema, ento necessrio que se tenha boa anlise, foco em anlise de requisitos e em anlise, detalhando-a bastante com estrutura de classes e seus relacionamentos. As estruturas de agregaes e de heranas e as classes tambm so importantes. Tudo isso facilita a verificao da corretude da modelagem sobre o domnio. Para obter um mapeamento da questo aos mtodos, primeiro obtm-se uma mdia dos valores encontrados nas tabelas relacionadas do captulo 4, como mostra a tabela 5.3 na linha nove, 95
levando-se em considerao os pesos de cada tabela. Cada valor mdio dividido pela soma de todos os valores mdios, obtendo as massas de crena de cada mtodo entre zero e um e soma um.
Tabela 5.3 Valores obtidos para a questo 1
Tabela 4.7 (2) 4.9 (1) 4.11 (2) 4.12 (1) 4.13 (1) 4.22 (2) 4.23 (2) Mdia Equivalente a 1
OOSE 50 46.2 61.5 66.7 66.7 100 33.3 60.84 0.21
OMT 56.3 15.4 100 66.7 100 100 63.15 0.22
OOAD 100 100 100 100 66.7 40 67.88 0.23
OOA-OOD 50 84.6 30.8 66.7 66.7 46.7 43 0.15
Fusion 37.5 69.2 76.9 66.7 88.9 73.3 54.56 0.19
As massas de crena obtidas so:
m({a}) = 0.21 m({b}) = 0.22 m({c}) = 0.23
m({d}) = 0.15 m({e}) = 0.19 m() = 0
Seguindo a frmula definida anteriormente (seo 5.4, item 4), o mapeamento se apresenta como descrito na clula G da tabela 5.2.
2 Qual o grau estimado de desconhecimento sobre os requisitos do sistema? GR (2) 4.4 - Identificao de requisitos 3 3 m({a}) = 0.55 * g / 100 m({d}) = 0 (2) 4.16 - Identificao de funcionalidades m({b}) = 0.18 * g / 100 m({e}) = 0.18 * g / 100 (2) 4.22 - Foco - anlise de requisitos

m({c}) = 0.03 * g / 100 m() = 1 - 0.94 * g / 100 Indique 0, se o usurio tem certeza do que o sistema deve fazer, quais suas funcionalidades, entradas e sadas. Indique 100, se o usurio se sente inseguro e no consegue dizer exatamente o que o sistema deve fazer, ou seja, quando o usurio no sabe absolutamente nada.
A questo 2 baseia-se nas tabelas 4.4, 4.16 e 4.22. Quando os requisitos do sistema no esto definidos interessante adotar um mtodo que ajude na identificao dos requisitos e das funcionalidades do sistema, e que possua foco em anlise de requisitos. Assim a tarefa se torna mais fcil e rpida porque so apresentados os passos a serem seguidos para sua realizao. Esta questo pertence ao segundo caso. O processo de obteno das mdias o mesmo definido para a questo 1 e os valores so baseados nas tabelas descritas na clula D da tabela 5.4. Segundo definido anteriormente, no permitido o mapeamento somente para os mtodos que apresentam modelagem para este aspecto. Desta forma, adicionado soma das mdias o valor dez, que representa um pequeno grau para o mapeamento do conjunto . O que permite a no excluso do mtodo. Os valores so descritos pela tabela 5.5.
96
Captulo 5 - Proposta de um sistema de apoio a deciso utilizando teoria de funo de crena ________________________________________________________________________________________________ Tabela 5.5 Valores obtidos para a questo 2
Tabela 4.4 (2) 4.16 (2) 4.22 (2) Mdia Equivalente a 1
OOSE 100 100 100 100 0.55
OMT 100 33.33 0.18
OOAD 14.3 4.77 0.03
OOA-OOD -
Fusion 100 33.33 0.18
As massas de crena obtidas so:
m({a}) = 0.55 m({d}) = 0 m({b}) = 0.18 m({e}) = 0.18 m({c}) = 0.03 m() = 0.06 O restante das questes obedecem a um desses dois critrios, que pode ser verificado pelo mapeamento obtido.
3 O tempo de vida til estimado para o sistema maior que um ano? SN (2) 4.22 - Foco - anlise de requisitos 4 4 m({a}) = 0.29 * g / 100 m({d}) = 0.18 * g / 100 (2) 4.23 - Foco - anlise m({b}) = 0.16 * g / 100 m({e}) = 0.17 * g / 100 (2) 4.24 - Foco - projeto
m({c}) = 0.20 * g / 100 m() = 1 - g / 100 Qual o tempo que se pretende utilizar o sistema, ou seja, o tempo que o sistema vai servir aos usurios. Exemplos: Menos de 1 ano: um sistema que se executa as inscries em um evento, ter uma vida curta, pois finalizado o evento no haver mais necessidade de utiliz-lo. Mais de 1 ano: um sistema bancrio tem vida longa, porque desenvolvido para atender aos usurios por um tempo maior. Os procedimentos utilizados no se modificam como retirar extrato/saldo, transferncia entre contas, pagamentos, saques, etc.
Caso o sistema a ser desenvolvido deva possuir o tempo de vida til maior que um ano, significa que o mesmo deve ser bem documentado para que a manuteno seja mais rpida, alm do mais, sistemas com tempo de vida til muita grande tendem a possuir maior rotatividade na equipe. Ento, escolhe-se preferencialmente um mtodo com foco em todas as seguintes fases do desenvolvimento: anlise de requisitos, anlise e projeto, pois assim possuir uma documentao adequada do sistema.
Tabela 5.7 Questo 4 - Anlise
4 Qual a porcentagem estimada do sistema que ser reutilizada de sistemas j desenvolvidos? GR (2) 4.10 - Troca de mensagens 5 5 m({a}) = 0.21 * g / 100 m({d}) = 0.17 * g / 100 (2) 4.17 - Criao de subsistemas
m({b}) = 0.17 * g / 100 m({c}) = 0.23 * g / 100 m({e}) = 0.22 * g / 100 m() = 1 - g / 100
Se durante o desenvolvimento de um sistema forem reutilizadas partes de sistemas j desenvolvidos, interessante que o sistema a desenvolver e os j desenvolvidos tenham diviso em subsistemas, porque isso facilita o reuso. Alm de que a troca de mensagens muito importante 97
para a comunicao entre os subsistemas. Se o sistema a ser reutilizado no tiver sido desenvolvido com idia de reuso, a prtica do mesmo se torna invivel.
5 O sistema todo ou parte dele ser reutilizado no desenvolvimento de outros sistemas? SN (2) 4.17 - Criao de subsistemas 6 6 m({a}) = 0.19 * g / 100 m({d}) = 0.22 * g / 100 (1) 4.18 - Alocao de subsistemas m({b}) = 0.20 * g / 100 m({e}) = 0.11 * g / 100 (2) 4.23 - Foco - anlise m({c}) = 0.28 * g / 100 m() = 1 - g / 100 (2) 4.24 - Foco - projeto
Se j existe a inteno de reusar o sistema em outros desenvolvimentos, a tarefa se tornar mais simples se o sistema possuir uma boa documentao para a anlise e o projeto, contendo diviso do sistema em subsistemas. importante tambm ter definido a alocao de subsistemas para processadores.
6 Qual o grau estimado de interao entre o usurio e o sistema? (2) 4.6 - Interface do sistema 7
GR 8
m({a}) = 0.32 * g / 100 m({d}) = 0.26 * g / 100 m({b}) = 0.26 * g / 100 m({e}) = 0 m({c}) = 0.13 * g / 100 m() = 1 - 0.97 * g / 100 Informe proporcionalmente o tempo que o usurio ir interagir com o sistema atravs de entrada e recuperao de dados. Exemplos: Grau de intensidade 10 40 %: um sistema de ajuste de temperatura tem baixa interao com o usurio, porque somente necessrio o nivelamento da temperatura desejada. Grau de intensidade 50 70 %: um sistema de folha de pagamento tem uma mdia interao, porque a entrada e recuperao de dados mais pesada acontece uma vez por ms. Grau de intensidade 80 100 %: um sistema de controle bancrio, tem alta interao, porque o usurio enquanto utiliza o sistema est entrando com dados (senha, valores) ou selecionando opes.
Quando o sistema deve possuir muita interao com o usurio, o mtodo deve sugerir modelagem para a interface do sistema para que esta interao seja o mais prximo possvel da que foi idealizada pelo solicitador do sistema, referncia tabela 5.9.
7 A interface com os usurios ter padro Windows? (2) 4.5 - Identificao de eventos 8 m({a}) = 0.28 * g / 100 (2) 4.10 - Troca de mensagens
m({b}) = 0.19 * g / 100 m({c}) = 0.19 * g / 100
SN 8
m({d}) = 0.08 * g / 100 m({e}) = 0.26 * g / 100 m() = 1 - g / 100
98
A interface tendo o padro Windows, o mtodo deve oferecer modelagem para identificao de eventos, j que este tipo de sistema utiliza-se de janelas e botes e troca de mensagens entre os objetos definidos para interface, referncia tabela 5.10.
8 Qual o grau estimado de intensidade (entre 0 e 100%) para a entrada de dados? GR (2) 4.6 - Interface do sistema 9 9 m({a}) = 0.27 * g / 100 m({d}) = 0.19 * g / 100 (2) 4.10 - Troca de mensagens m({b}) = 0.19 * g / 100 m({e}) = 0.14 * g / 100 Identificao de atributos
m({c}) = 0.21 * g / 100 m() = 1 - g / 100 A pergunta quer saber se antes de obter uma resposta do sistema, existe muita entrada de dados. A resposta deve ser dada em porcentagem. Exemplos: Grau de intensidade 80 - 100%: um sistema como o do IRRF antigo, em que os dados de entrada eram digitados, antes de se obter um resultado considerado de grande volume. Grau de intensidade 50 - 70%: um sistema de controle de estoque cuja empresa recebe as mercadorias diariamente, apresenta uma grande entrada de dados. Grau de intensidade 10 - 40%: 1) um sistema de controle de estoque cuja entrada de dados ocorre mensalmente, em um dia determinado; 2) um sistema de folha de pagamento onde a entrada de dados tambm realizada mensalmente.
Quando existe muita entrada de dados, o sistema deve ser desenvolvido observando principalmente a interface do sistema, a identificao de atributos, porque muitos desses dados sero armazenados e a troca de mensagens para que os objetos possam se comunicar corretamente.
Em relao ao sistema como um todo, qual a porcentagem estimada de clculos (0% - GR 100%) que devem ser executados? (2) 4.15 - Aspectos funcionais 10 10
m({a}) = 0 m({d}) = 0.43 * g / 100 m({b}) = 0.52 * g / 100 m({e}) = 0 m({c}) = 0 m() = 1 - 0.95 * g / 100 Informe se o sistema far clculos com uso de matrizes, funes trigonomtricas, ou outros clculos do gnero. Exemplos: Porcentagem entre 80 - 100%: um sistema cientfico exige grande volume de clculos. Porcentagem entre 50 - 70%: um sistema de folha de pagamento apresenta muitos clculos, mas eles so simples. Porcentagem entre 10 - 40%: um sistema de controle de estoque apresenta pouqussimos clculos.
Quando o sistema possui muita transformao de dados, como clculos, o mtodo deve oferecer modelos que abrangem os aspectos funcionais para possibilitar a modelagem das funes que modificam os valores. Quando os dados armazenados pelo sistema so bastante importantes, o seu desenvolvimento deve possuir abordagem orientada a dados, onde a preocupao se focaliza na identificao e descrio desses dados, ou seja, na descrio das classes.
99
Captulo 5 - Proposta de um sistema de apoio a deciso utilizando teoria de funo de crena ________________________________________________________________________________________________ Tabela 5.13 Questo 10 - Anlise
10 Qual o grau estimado de importncia dos dados no sistema? (2) 4.9 - Descrio de classe 11 m({a}) = 0.08 * g / 100 (2) 4.25 - Abordagem - dados
GR 11
m({d}) = 0.30 * g / 100 m({e}) = 0.27 * g / 100 m() = 1 - g / 100
m({b}) = 0.19 * g / 100 m({c}) = 0.16 * g / 100 No caso de perda dos dados, informe qual o grau de prejuzo para o sistema. Exemplos: Grau entre 80 - 100%: um sistema que controla uma caldeira, apresenta nos dados a garantia de que no haver uma exploso ou perda do material, pois sero informados os valores mximo e mnimo permitidos. O mesmo se verifica para um sistema bancrio, onde as operaes no podero ser refeitas. Os dados nestes casos so importantssimos. Grau entre 50 - 70%: um sistema de folha de pagamento apresenta resultados a partir dos dados entrados. Se houver perda dos mesmos, eles tero que ser reentrados com um esforo considervel. O mesmo se verifica em um sistema de controle de estoque. Grau entre 10 - 40%: um sistema que apresenta a estrutura de um shopping, como suas lojas e caminho a seguir, no possui alteraes nos dados (durante a interface com o usurio). Se caso os dados forem perdidos podem ser obtidos de um backup sem problema algum, porque no ser necessrio reentrada de dados. Os dados neste caso, tm importncia mnima.
Um sistema que pode sofrer manutenes quanto a modificaes de requisitos durante a vida til, deve ser desenvolvido sobre a orientao de um mtodo que oferea modelagem detalhada de classes e objetos, criao e alocao de subsistemas, bem como possuir um enfoque em anlise de requisitos e anlise. Tudo isso permitir uma manuteno mais rpida, simples e segura.
11 Pode haver mudanas na definio do sistema durante sua vida til? SN (2) 4.7 - Estrutura de classes 12 12 m({a}) = 0.22 * g / 100 m({d}) = 0.16 * g / 100 (2) 4.8 - Estrutura de objetos m({b}) = 0.21 * g / 100 m({e}) = 0.14 * g / 100 (2) 4.17 - Criao de subsistemas m({c}) = 0.27 * g / 100 m() = 1 - g / 100 (1) 4.18 - Alocao de subsistemas (1) 4.22 - Foco - anlise de requisitos (2) 4.23 - Foco - anlise
Informe se j existe a inteno de modificar ou incluir alguma funcionalidade ou estrutura ao sistema. Exemplo: um sistema bancrio apresenta grandes mudanas devido aos valores das taxas que variam ou das modificaes nas leis.
Quando o sistema faz controle de equipamentos e/ou mquinas, o mtodo deve oferecer uma abordagem comportamental, preocupando-se principalmente com as operaes necessrias; o detalhamento das operaes e a troca de mensagens. A modelagem de estados tambm se torna importante para que compreenda o sistema melhor e possa model-lo de forma mais correta, porque o controle se baseia nos estados dos objetos.
100
Captulo 5 - Proposta de um sistema de apoio a deciso utilizando teoria de funo de crena ________________________________________________________________________________________________ Tabela 5.15 Questo 12 - Projeto
12 O sistema faz controle de mquinas e equipamentos em processos industriais? SN (2) 4.10 - Troca de mensagens 13 13 m({a}) = 0.30 * g / 100 m({d}) = 0.11 * g / 100 (2) 4.14 - Modelagem de estado m({b}) = 0.16 * g / 100 m({e}) = 0.13 * g / 100 (1) 4.20 - Detalhamento de operaes m({c}) = 0.30 * g / 100 m() = 1 - g / 100 (2) 4.26 - Abordagem - comportamental
Se o controle de tempo real fizer parte do sistema e imprescindvel estabelecer as prioridades dos objetos, assim como, tratar a concorrncia existente entre os objetos. Abrangendo esses dois pontos o sistema possuir condies de apresentar as respostas necessrias em tempo hbil.
Tabela 5.16 Questo 13 - Projeto
13 O sistema deve fazer controle de tempo real? (2) 4.19 - Estabelecer prioridades (2) 4.21 - Tratamento de concorrncia
SN 14
m({a}) = 0 m({b}) = 0 m({c}) = 0.45 * g / 100
14
m({d}) = 0.45 * g / 100 m({e}) = 0 m() = 1 - 0.9 * g / 100
Um sistema com armazenamento distribudo deve ter uma estrutura de objetos e troca de mensagens bem modeladas, porque existiro muitos objetos e consequentemente muitas mensagens entre eles, para que o sistema atenda a um evento buscando respostas nas vrias partes distribudas do banco de dados. Alm disso, um mtodo que tenha abordagem orientada a dados pode auxiliar na modelagem dos dados.
14 O armazenamento de dados ser distribudo? (2) 4.8 - Estrutura de objetos (2) 4.10 - Troca de mensagens (1) 4.25 - Abordagem - dados
SN 15
m({a}) = 0.18 * g / 100 m({b}) = 0.17 * g / 100 m({c}) = 0.23 * g / 100
15
m({d}) = 0.16 * g / 100 m({e}) = 0.26 * g / 100 m() = 1 - g / 100
Informe se o banco de dados estar dividido em vrias CPU's. Exemplo: um sistema bancrio poder ter sua base de dados distribuda pelas cidades, de acordo com os clientes de cada uma. Assim, teria um banco de dados em Braslia para todos os clientes desta cidade, e assim por diante. Obs.: O sistema estar distribudo, mas no estar isolado, porque se um cliente de Anpolis tentar retirar dinheiro em Braslia ser perfeitamente possvel.
Se a arquitetura do sistema para o acesso aos dados de clientes remotos com mais de um servidor, necessrio a modelagem da estrutura dos objetos, a troca de mensagens entre eles e o tratamento de concorrncia, alm de identificar os subsistemas e aloc-los aos processadores apropriados. Esta completa modelagem permite que o acesso aos dados seja distribudo, pois ser feito um controle apropriado. 101
15
A arquitetura a ser utilizada para o acesso aos dados de clientes remotos com mais de um SN servidor? (2) 4.8 - Estrutura de objetos 16 17 m({a}) = 0.20 * g / 100 m({d}) = 0.14 * g / 100 (2) 4.10 - Troca de mensagens m({b}) = 0.15 * g / 100 m({e}) = 0.13 * g / 100 (2) 4.17 - Criao de subsistemas m({c}) = 0.38 * g / 100 m() = 1 - g / 100 (2) 4.18 - Alocao de subsistemas (2) 4.21 - Tratamento de concorrncia
O desenvolvimento de um protocolo aborda a modelagem de estado e troca de mensagens e requer uma abordagem comportamental. Estes aspectos detalham a comunicao e verificao existente em um protocolo.
16
O sistema necessitar do desenvolvimento de protocolos entre clientes e servidores ou entre SN servidores? (2) 4.10 - Troca de mensagens 20 20 m({a}) = 0.29 * g / 100 m({d}) = 0.10 * g / 100 (2) 4.14 - Modelagem de estados m({b}) = 0.20 * g / 100 m({e}) = 0.12 * g / 100 (1) 4.26 - Abordagem - comportamental
m({c}) = 0.29 * g / 100 m() = 1 - g / 100
Se a arquitetura para o acesso aos dados de clientes remotos com um nico servidor, a modelagem deve cobrir a estrutura de objetos, troca de mensagens e tratamento de concorrncia. Como ser utilizado somente um servidor, no torna-se necessrio a modelagem de subsistemas e sua alocao a processadores, com a nfase definida para questo 15.
17 Ento, a arquitetura para o acesso aos dados de clientes remotos com servidor central? SN (2) 4.8 - Estrutura de objetos 18 19 m({a}) = 0.20 * g / 100 m({d}) = 0.10 * g / 100 (2) 4.10 - Troca de mensagens m({b}) = 0.12 * g / 100 m({e}) = 0.21 * g / 100 (2) 4.21 - Tratamento de concorrncia
m({c}) = 0.37 * g / 100 m() = 1 - g / 100
Se houver a necessidade do desenvolvimento de protocolos entre os clientes e o servidor, os mesmos aspectos cobertos para a questo 16 devem tambm ser modelados aqui.
18 O sistema necessitar do desenvolvimento de protocolos entre clientes e servidor? SN (2) 4.10 - Troca de mensagens 20 20 m({a}) = 0.29 * g / 100 m({d}) = 0.10 * g / 100 (2) 4.14 - Modelagem estados m({b}) = 0.20 * g / 100 m({e}) = 0.12 * g / 100 (1) 4.26 - Abordagem - comportamental
m({c}) = 0.29 * g / 100 m() = 1 - g / 100
O uso de clientes e servidor locais para o acesso aos dados requer uma modelagem igual a abordada para a questo 17, sendo descrita na tabela 5.22.
102
19 Para o acesso aos dados, a arquitetura utilizada ser de clientes e servidor local? SN (2) 4.8 - Estrutura de objetos 20 20 m({a}) = 0.20 * g / 100 m({d}) = 0.10 * g / 100 (2) 4.10 - Troca de mensagens m({b}) = 0.12 * g / 100 m({e}) = 0.21 * g / 100 (2) 4.21 - Tratamento de concorrncia
m({c}) = 0.37 * g / 100 m() = 1 - g / 100
Quanto maior for o grau de pesquisa no conjunto de dados, maior ser a necessidade de uma modelagem completa da estrutura de objetos e do tratamento de concorrncia, definindo se haver vrios acessos simultneos ao mesmo objeto ou no (tanto aos atributos quanto s operaes). A troca de mensagens tambm deve ser modelada.
20 Informe o grau estimado de pesquisa realizada no conjunto de dados armazenados. GR (2) 4.8 - Estrutura de objetos 21 21 m({a}) = 0.19 * g / 100 m({d}) = 0.10 * g / 100 (1) 4.10 - Troca de mensagens m({b}) = 0.12 * g / 100 m({e}) = 0.20 * g / 100 (2) 4.21 - Tratamento de concorrncia
m({c}) = 0.39 * g / 100 m() = 1 - g / 100 Indique se haver necessidade de acesso ao banco de dados. Exemplos: Grau 0%: um sistema que controla temperatura de um caldeiro no apresenta quase nenhum acesso, pois os dados so obtidos por entidades externas. Grau ente 10 - 50%: um sistema de folha de pagamento baseia-se em clculos sobre os dados armazenados, mas no h pesquisa nos dados e, sim, uma busca desses valores. Grau entre 60 - 100%: um sistema de controle de biblioteca baseia-se fundamentalmente em verificaes na base de dados, porque requer verificaes sobre emprstimos, reservas, quantidade emprestada a um determinado usurio, etc.
Se o banco de dados orientado a objetos ser utilizado pelo sistema, ento a modelagem deve ser detalhada na estrutura de classes e dos objetos, onde se modela os relacionamentos e a visibilidade, e no tratamento de concorrncia, modelando a concorrncia entre os objetos.
21 Pretende-se utilizar Banco de Dados Orientados a Objetos? SN (1) 4.7 - Estrutura de classes 0 22 m({a}) = 0.18 * g / 100 m({d}) = 0.11 * g / 100 (2) 4.8 - Estrutura de objetos m({b}) = 0.13 * g / 100 m({e}) = 0.17 * g / 100 (2) 4.21 - Tratamento de concorrncia
m({c}) = 0.41 * g / 100 m() = 1 - g / 100
Se o banco de dados relacional que ser utilizado, ento a modelagem sobre os relacionamento deve ser enfatizada, assim como a abordagem orientada a dados. Estes so os pontos fortes em um sistema relacional, o relacionamento dos dados armazenados.
103
22 Ento, pretende-se utilizar Banco de Dados Relacional? (2) 4.11 - Relacionamentos 0 m({a}) = 0.09 * g / 100 (2) 4.25 - Abordagem - dados
m({b}) = 0.30 * g / 100 m({c}) = 0.15 * g / 100
SN 0
m({d}) = 0.20 * g / 100 m({e}) = 0.26 * g / 100 m() = 1 - g / 100
As perguntas apresentadas avaliam a parte tcnica de um desenvolvimento, ento, para uma completa viso seria necessrio ainda a avaliao da parte gerencial, que no abordada neste trabalho. Como complemento dessa abordagem, poderia ser aplicado a teoria de funo de perda, que determina a perda associada a todos os casos onde o SAD sugere um mtodo e o engenheiro de software adota outro. Ao final adotado o mtodo que oferece menor perda. Com a proposta definida, o prximo captulo descreve o prottipo desenvolvido, que implementa a proposta.
# '&%$"!
104
SGMOO: o prottipo
O Sistema Gestor de Mtodos Orientados a Objetos - SGMOO um prottipo que fornece a indicao dos mtodos mais adequados ao desenvolvimento de um determinado sistema, mediante respostas obtidas atravs do questionrio gerado pelo prottipo. O SGMOO uma implementao da proposta definida no captulo anterior. O presente captulo apresenta o desenvolvimento do SGMOO, sua arquitetura de implementao, que apresenta o seu funcionamento em alto nvel de abstrao, descrio da base de conhecimento, ou seja, como os dados so armazenados e como eles se relacionam, as telas desenvolvidas durante a implementao, os resultados obtidos pela aplicao de quatro simulaes de casos reais e as consideraes finais. So aplicados ao SGMOO simulaes de casos reais porque a busca por descries de casos reais em empresas de desenvolvimento ou organizaes, seria um trabalho muito dispendioso de tempo.
O objetivo principal do SGMOO21 apresentar a interface do sistema para os dois tipos de usurios, como descritos a seguir, e a implementao do algoritmo de Dempster e Shafer (seo 5.2). A criao de um sistema completo abrangendo todos os detalhes no se caracteriza uma meta. A figura 6.1 apresenta um esquema de interao entre os dois tipos de usurios e o SGMOO, apresentando interface para o especialista em mtodos e para o engenheiro de software, separadamente.
Graduar os mtodos Engenheiro de software
Figura 6.1 - Intera o entre os dois tipos de usu rios e o SGMOO

21
O SGMOO foi desenvolvido em Visual Basic for Application. Esta linguagem oferece fcil manuseamento e rpido desenvolvimento.
3 C C ' @ 5 # 35 32 ) #! A@ F)ED3$BA396&37864$01('(&%$"

Atualizar os dados Especialista em mtodos
105
Captulo 6 - SGMOO: o prottipo ________________________________________________________________________________________________
O especialista em mtodos atualizar os dados necessrios para a graduao dos mtodos, como: os mtodos disponveis, as questes para o questionrio, as fases de desenvolvimento oferecidas e o mapeamento das funes de crena. A qualquer momento esta atualizao ser possvel. Visando graduar os mtodos, o SGMOO gera um questionrio disponvel para o engenheiro de software, que fornece as respostas tendo como base o sistema que ele pretende desenvolver. Com as respostas, que caracterizam as evidncias (definidas no captulo 5), aplica-se o algoritmo de Dempster e Shafer (figura 5.2) sobre os mapeamentos das funes de crena. O resultado ser um quadro com a graduao da aplicabilidade de cada mtodo em cada fase do desenvolvimento do sistema em questo e, tambm, o mtodo mais graduado em todas as fases podendo ser utilizado em todo o desenvolvimento. Este quadro ilustrado pela figura 6.2. Resultado
An. Req. Todos OOSE - Jacobson et. al. OMT - Rumbaugh et. al. OOAD - Booch OOA-OOD - Coad & Yourdon Fusion - Coleman et. al. 0,00 31,30 15,90 19,30 16,70 16,70 Anlise 0,00 28,60 28,60 28,60 14,30 0,00 Projeto 0,00 13,10 5,30 64,70 3,70 13,10 Geral 0,00 23,08 4,73 70,41 1,78 0,00
Figura 6.2 - Quadro de gradua o dos mtodos em cada fase do desenvolvimento
Neste quadro esto relacionados todos os mtodos e suas crenas, que definem o quanto o mtodo apropriado para o desenvolvimento de um sistema em uma dada fase e o mtodo que pode ser utilizado em todas as fases (Geral)22. A arquitetura de implementao do SGMOO apresentada a seguir.
22
Este resultado geral a combinao dos resultados obtidos para cada fase, de acordo com o algoritmo de Dempster e Shafer seo 5.2.
A #AB@8#"#532!0!)'%$"#! 9 7 6 6 4 1 % ( &
A figura 6.3 apresenta a arquitetura do prottipo composta por trs mdulos: 1. servios para o engenheiro que apresenta o questionrio, obtm e armazena as respostas, faz a combinao das funes de crena e envia ao engenheiro de software a graduao de cada mtodo, separadamente, por fases; 2. base de conhecimento que armazena as fases, os mtodos, as questes e as funes de crenas definidas pelo especialista, bem como um arquivo temporrio das respostas obtidas do engenheiro de software;
106
3. servios para o especialista que permite o especialista em mtodos fazer manutenes na base de conhecimento, com incluses, excluses e alteraes. A base de conhecimento armazena as fases, os mtodos e as questes identificadas atravs de entrevistas com engenheiros de software, que possuem larga experincia no desenvolvimento de diversos domnios da aplicao, considerando os aspectos relevantes no desenvolvimento. Tambm armazena um arquivo temporrio das respostas obtidas atravs do questionrio e as funes de crena definidas pelo especialista mediante um estudo aprofundado dos mtodos.
Servios para o engenheiro
fases Apresentar o questionrio questionrio Engenheiro de software Obter respostas respostas
Base de conhecimento
fases Fases
Servios para o especialista

Manter fases
questes questes Questes Manter questes Especialista em mtodos
questes
Interface do usurio
mtodos Armazenar respostas Mtodos mtodos Combinar funes de crena resultado Apresentar quadro
Manter mtodos
Interface do especialista
Respostas resposta funes de crena Funes de crena
funes de crena
Manter funes de crena
Figura 6.3 - Arquitetura do prottipo
Somente o especialista em mtodos poder fazer manutenes na base de conhecimento atravs do mdulo servios para o especialista. A interao entre o engenheiro de software e o sistema ser atravs do mdulo servios para o engenheiro. Este mdulo inclui os seguintes servios: a) apresentar o questionrio para o engenheiro de software, com base nas perguntas definidas pelo especialista, que so separadas por fases, mas que so transparentes ao engenheiro de software, b) obter as respostas do questionrio, possibilitando determinar, alm das caractersticas do sistema, a prxima pergunta, dependente da resposta anterior, c) armazenar as respostas temporariamente para posterior servio de combinar as funes de crena, para apresentar o quadro ao engenheiro de software. O resultado obtido uma associao bem fundamentada, que pode ser utilizada como guia no desenvolvimento de qualquer sistema, gerando uma qualidade e rendimento superior aos 107
encontrados atualmente, devido ao fato de se utilizar o mtodo mais adequado ao domnio da aplicao. Entretanto, esse guia no garante o sucesso do desenvolvimento, o qual ser medido tambm por outros aspectos, como: tamanho e treinamento da equipe de desenvolvimento, alteraes de requisitos, etc. Uma das principais propriedades do prottipo prover permisso de futuras incluses ou modificaes na base de conhecimento, com informaes sobre novas fases, questes, mtodos e funes de crena, seja pelo aperfeioamento do estudo feito ou pelo estudo de novos mtodos. A seguir so apresentados detalhes da base de conhecimento, sua estrutura e seus relacionamentos.
A base de conhecimento composta por cinco tabelas: Crena, Fase, Mtodo, Pergunta e Resposta (o arquivo temporrio). O nome dos campos23, os tipos de dados e uma descrio para cada tabela, citada anteriormente, so relacionados pelas tabelas 6.1 a 6.5. A tabela 6.1 armazena os mapeamentos das crenas nos mtodos para cada tipo de resposta de cada pergunta. Se o mapeamento for mximo recebe cdigo 1, se for mnimo recebe cdigo 2. O valor da crena varia entre 0 e 1, como j definido no captulo 5.
Tabela 6.1 Crena
Nome do campo codperg codcren codmeto vlrcren
A tabela 6.2 armazena as fases que so relacionadas na apresentao do quadro de graduao. Neste trabalho, so abordadas somente as fases de anlise de requisitos, anlise e projeto.
Tabela 6.2 Fase
Nome do campo codfase desfase
A tabela 6.3 armazena os mtodos que o SGMOO utiliza e para os quais pode-se fazer mapeamentos. Este trabalho aborda cinco mtodos cujos cdigos so assim descritos: 0 - Todos; 3 - OOAD;
23
Os campos que apresentam uma chave, indicam que fazem parte da chave primria da tabela.
3 ' ( ' " # " 421&0)&&%%$!

Tipo de dados Nmero Nmero Nmero Nmero Descrio Cdigo da pergunta Cdigo da crena (1 ou 2) Mtodo Valor da crena
Tipo de dados Nmero Texto
Descrio Cdigo da fase Descrio da fase
1 - OOSE; 4 - OOA-OOD;
2 - OMT; 5 - Fusion.
108
Captulo 6 - SGMOO: o prottipo ________________________________________________________________________________________________ Tabela 6.3 Mtodo
Nome do campo codmeto desmeto
Tipo de dados Nmero Texto
Descrio Cdigo do mtodo Descrio do mtodo
A tabela 6.4 relaciona as perguntas que formam o questionrio. As perguntas podem ser do tipo Sim ou No ou para informar o grau. Ao final de cada resposta feita uma prxima pergunta. Na maioria das vezes isso independente da resposta, ou seja, a prxima pergunta nica; mas em outras so consideradas determinantes, quando a prxima pergunta depende da resposta anterior. A observao da pergunta como uma ajuda para que o engenheiro de software possa compreender melhor o que est sendo questionado. Cada pergunta pertence a uma determinada fase, o que tornase transparente atravs do questionrio, somente o especialista em mtodos tem conhecimento.
Tabela 6.4 Pergunta
Nome do campo codperg desperg tipperg propergS propergN obsperg codfase

Tipo de dados Nmero Texto Texto Nmero Nmero Texto Nmero
Descrio Cdigo da pergunta Descrio da pergunta Tipo da pergunta (SN - Sim/No, GR - Informar o grau) Prxima pergunta (100% ou outra <> 0% - Sim) Prxima pergunta (0% - No - No informado) Observao da pergunta Cdigo da fase
A tabela 6.5 armazena informaes sobre as respostas obtidas atravs do questionrio, armazenando o grau informado para a pergunta e qual a pergunta anterior, para correo de eventual erro na resposta anterior.
Tabela 6.5 Resposta
Nome do campo codperg graresp anterior codcren
Tipo de dados Nmero Nmero Nmero Nmero
Descrio Cdigo da pergunta Grau da resposta Pergunta anterior Cdigo da crena
A figura 6.4 apresenta os relacionamentos entre as tabelas descritas anteriormente. Cada pergunta pode ter uma resposta informada pelo engenheiro. importante observar que a pergunta deve pertencer a uma fase, podendo ter vrias crenas para cada resposta e dois altorelacionamentos. Isto ocorre porque a pergunta seguinte depende da resposta informada. Cada crena mapeada somente para um mtodo.
109
Figura 6.4 - Relacionamentos das tabelas da base de conhecimento
Nesta seo so apresentadas as telas mais importantes do prottipo, seguindo uma rpida explanao sobre cada uma. A figura 6.5 apresenta a tela inicial do prottipo onde define qual a categoria do usurio a utilizar o sistema, pode ser o engenheiro de software representado pelo boto da esquerda ou o especialista representado pelo boto da direita. O boto na parte inferior permite sair do sistema.
A figura 6.6 apresenta o formulrio de menu de navegao para o especialista em mtodos, onde ele poder modificar os formulrios listados no menu ou fazer incluso/alterao de perguntas e crenas. A ltima opo do menu retorna a tela inicial. 110
$ # '0)('&%!"!
Figura 6.5 - Tela inicial do prottipo
As prximas trs figuras so apresentadas ao especialista em mtodos.
Figura 6.6 - Formul rio de menu de navega o para o especialista
A figura 6.7 apresenta o formulrio para entrada das perguntas - ou questes - a serem utilizadas no questionrio. Cada pergunta pertence a uma fase, tem um tipo (GR/SN) e um campo de observao, que funciona como uma explicao da pergunta para auxiliar o engenheiro de software a responder o questionrio.
Figura 6.7 - Formul rio para entrada das perguntas
A figura 6.8 apresenta o formulrio para entrada das crenas definidas para cada resposta (mximo/mnimo). Uma crena definida para um nvel e para um mtodo atribuindo seu valor.
Figura 6.8 - Formul rio para entrada das crenas
111
As prximas quatro figuras so apresentadas ao engenheiro de software. A figura 6.9 ilustra o formulrio para apresentao do questionrio quando o tipo de pergunta para informar o grau.
Figura 6.9 - Formul rio I de apresenta o do question rio

A figura 6.10 apresenta um segundo formulrio para apresentao do questionrio quando o tipo de pergunta SN (sim/no).
Figura 6.10 - Formul rio II de apresenta o do question rio

Para ambos os formulrios (figura 6.9 e 6.10) esto definidos dois aspectos: i) um boto de help, ilustrado na figura 6.10, que ser acionado se estiver definido na tabela de Perguntas a necessidade de explicao e ii) o usurio poder prosseguir com a prxima pergunta ou voltar para corrigir eventual resposta informada incorretamente, atravs dos botes ilustrados na parte inferior de ambas figuras. A figura 6.11 apresenta a explanao da pergunta quando definida no campo 'observao' da tabela Pergunta.
112
Figura 6.11 - Formul rio de apresenta o da explana o da pergunta

A figura 6.12 ilustra o formulrio apresentado ao engenheiro de software assim que o questionrio todo respondido. Posteriormente, so combinadas as funes de crena com base nas respostas obtidas.
Figura 6.12 - Formul rio para incio do algoritmo
ajuda de engenheiros de software que tm grande experincia no desenvolvimento de sistemas, porque a aplicao de casos reais engloba entrevistas com diversos usurios; alm do mais o objetivo principal deste trabalho no fazer uma vasta validao sobre o prottipo. Os casos so: i) sistema de contabilidade, ii) sistema de controle de biblioteca, iii) sistema de controle de passagens areas e iv) sistema de controle industrial. A seguir so apresentadas uma breve descrio das funcionalidades dos sistemas utilizados para simulao e suas caractersticas. Sistema de contabilidade - sistema contbil de uma empresa que registra as notas fiscais de produtos vendidos e/ou adquiridos, atualizao de patrimnio ativo e passivo, elaborao de balanos e balancetes e controle de caixa. A interao entre o usurio e o sistema mdia, assim 113
$ "$%""#"!
Sero aplicados a simulao de quatro casos reais. Estes casos foram identificados com a
como a pesquisa realizada nos dados armazenados, a entrada de dados deste tipo de sistema alta, com uso considervel de clculos, os dados tm importncia mdia. Sistema de controle de biblioteca - sistema para controlar cadastro de funcionrios, usurios e obras, emprstimos, reservas, devolues, pagamento de multas, envio de obras para restaurao e manter relatrios dirios para melhor controle. A interao entre o usurio e o sistema baixa, assim como a entrada de dados no sistema, possui pouqussimos clculos, os dados so muito importantes e a pesquisa realizada nos dados armazenados bastante alta. Sistema de controle de passagens areas - sistema para controlar reservas, cancelamentos e venda de passagens areas, controle de embarque, pagamentos efetuados e a efetuar. A interao entre o usurio e o sistema mdia, assim como a entrada de dados no sistema, possui pouqussimos clculos, os dados so extremamente importantes e a pesquisa realizada nos dados armazenados relevante. Sistema de controle industrial - sistema que controla um processo qumico, em que vrias substncias so combinadas e feito um controle de temperatura e de outras variveis como: PH, concentrao de O2, etc. Quase no h interao entre o usurio e o sistema e nem entrada de dados no sistema, possui bastante clculos, os dados tm importncia mnima, assim como a pesquisa realizada nos dados armazenados. O sistema no ser do tipo cliente-servidor. Caractersticas gerais sobre os sistemas so: i) todos os sistemas com exceo do sistema industrial ter padro Windows e poder ter mudanas na sua definio durante sua vida til; ii) somente o sistema industrial far controle de mquinas e equipamentos e tempo real. A tabela 6.6 apresenta as respostas obtidas sobre as questes para cada um dos sistemas descritos acima.
Tabela 6.6 Respostas das questes para cada sistema
Questo 1 Questo 2 Questo 3 Questo 4 Questo 5 Questo 6 Questo 7 Questo 8 Questo 9 Questo 10 Questo 11 Questo 12 Questo 13 Questo 14 Questo 15 Questo 16 Questo 17 Questo 18 Questo 19 Questo 20 Questo 21 Questo 22
Contabilidade 30 % 20 % Sim 90 % Sim 60 % Sim 80 % 60 % 50 % Sim No No No No No Sim 50 % Sim -
Biblioteca 10 % 0% Sim 50 % Sim 40 % Sim 30 % 10 % 90 % Sim No No No No Sim Sim 90 % Sim -
Passagens areas 70 % 50 % Sim 10 % No 50 % Sim 50 % 10 % 100 % Sim No No Sim Sim No 70 % Sim -
Industrial 50 % 80 % Sim 0% No 10 % No 10 % 70 % 30 % No Sim Sim No No No No 10 % No Sim
114
A figura 6.13 apresenta o resultado obtido pela anlise do SGMOO para o sistema de contabilidade. Resultado
Os seguintes aspectos podem ser identificados: Para modelar a anlise, o SGMOO indicou o uso de qualquer um dos seguintes mtodos: OOSE, OMT ou OOAD, no indicando o mtodo Fusion. O empate deve-se ao fato de que o mtodo deve modelar subsistemas, devido ao alto reuso, a interface e possibilitar uma boa documentao. Interessante observar que para a fase de anlise, o mtodo Fusion apresenta modelagem mais deficiente do que os mtodos para quase todos os aspectos24, por isso no houve pontuao. A figura 6.14 apresenta o resultado obtido pela anlise do SGMOO para o sistema de biblioteca. Resultado
24
Referncias so as tabelas 5.7 a 5.14.
9 9 5 '@7863421)'&%#" " 0 ( $ !

Figura 6.13 Resultado apresentado pelo SGMOO para o sistema de contabilidade Figura 6.14 Resultado apresentado pelo SGMOO para o sistema de biblioteca
115
Os seguintes aspectos podem ser identificados: O mtodo OOAD foi o mais indicado para ser utilizado tanto na anlise quanto no projeto. O sistema no requer clculos, alta entrada de dados e a interao baixa. Necessita ser bem documentado e ter modelagem apropriada para reuso e mudana de requisitos. Por isso, o mtodo OOAD o mais indicado para anlise. Se o engenheiro no optar pelo mtodo OOAD, pode-se decidir entre os mtodos OOSE e OMT que tecnicamente esto empatados. A figura 6.15 apresenta o resultado obtido pela anlise do SGMOO para o sistema de passagens areas. Resultado
Figura 6.15 Resultado apresentado pelo SGMOO para o sistema de passagens areas
Os seguintes aspectos podem ser identificados: Para o desenvolvimento desse sistema pode-se escolher entre os mtodos OMT, OOAD e Fusion para a fase de anlise, que praticamente esto empatados na graduao. So mtodos que apresentam boa documentao para essa fase. O sistema no ser desenvolvido tendo o reuso como meta e nem apresenta muitos clculos, tem sua principal preocupao nos dados e na interao. Importante observar que para a modelagem do sistema na anlise, praticamente pode-se utilizar qualquer um dos mtodos. Isso deve-se ao fato de cada mtodo modelar melhor determinados aspectos. Entretanto, o SGMOO indica o mtodo que tenha melhor modelagem em todos os aspectos. A figura 6.16 apresenta o resultado obtido pela anlise do SGMOO para o sistema industrial. Os seguintes aspectos podem ser identificados: Para modelagem desse sistema na fase de anlise no so indicados os mtodos OOSE, OOAD e Fusion. O principal nesse sistema a modelagem dos clculos e a importncia dos dados, onde necessrio ter uma boa descrio das classes. Deste modo, os mtodos mais indicados so OMT e Fusion. 116
Interessante observar que o mtodo OOA-OOD foi bem graduado para a fase de projeto, pelo fato de que poucas caractersticas para o projeto so informadas e uma delas - estabelecer prioridades - modelada unicamente por esse mtodo. Apesar do mtodo OOA-OOD no ter obtido pontuao como OOAD para a fase de projeto, o engenheiro de software pode pensar em utilizar o mtodo OOA-OOD na anlise e no projeto, principalmente se a equipe de desenvolvimento for inexperiente com orientao a objetos. Resultado
Figura 6.16 Resultado apresentado pelo SGMOO para o sistema industrial
Analisando os resultados obtidos observa-se os seguintes pontos genricos: O mtodo OOSE foi o mais indicado para a fase de anlise de requisitos em todos os quatro casos. Isto deve-se ao fato desse mtodo oferecer uma modelagem abrangente para essa fase e haver necessidade de iniciar o desenvolvimento por essa fase; O mtodo OOAD foi o mais indicado para a fase de projeto tambm para os quatro casos. Este mtodo possui ampla modelagem nessa fase; O mtodo OOAD tambm foi o mais indicado para ser utilizado durante todo o desenvolvimento de todos os casos. Isto deve-se ao fato de que este mtodo possui alta graduao na fase de projeto. Um ponto j identificado que pode ser melhorado: Para o sistema de contabilidade, o SGMOO no deveria graduar o mtodo OOAD to distante dos demais para a fase de projeto, pelo fato do sistema no apresentar caractersticas de projeto e dinmica muito relevantes - tempo real, sistema distribudo, desenvolver protocolo -. Deste modo, outros mtodos poderiam ser utilizados.
O SGMOO pode auxiliar bastante o engenheiro de software a tomar a deciso de escolher qual mtodo orientado a objetos mais indicado para o desenvolvimento de determinado sistema. 117
# ('&%$"!
Os resultados obtidos atravs das simulaes de casos reais so aceitveis e, em muitos aspectos, refletem o estudo realizado. Entretanto, os resultados fornecidos deveriam ser aplicados em um desenvolvimento real, permitindo ao especialista em mtodos uma anlise ao final do desenvolvimento para melhorar o SGMOO, o mapeamento das crenas ou os aspectos que devem ser modelados para cada caracterstica de um sistema. O prximo captulo apresenta as concluses finais deste trabalho.
118
O captulo final deste trabalho divido em duas sees. A primeira descreve uma viso geral dos objetivos, desenvolvimento e contribuies ao conhecimento. A segunda destaca os trabalhos futuros que podem ser desenvolvidos como extenso ou complementao deste.
Esta seo faz uma reviso resumida do trabalho como um todo e apresenta as
contribuies ao conhecimento.
7.1.1
Reviso
Como j mencionado, o objetivo principal dessa pesquisa foi elaborar uma proposta para auxiliar os desenvolvedores de sistema a escolher o mtodo orientado a objetos mais indicado para o desenvolvimento de um determinado domnio de aplicao. Para alcan-lo, foi necessrio o estudo sobre os conceitos de modelagem e orientao a objetos, bem como dos mtodos orientados a objetos. Paralelamente ao estudo e descrio dos mtodos, foi desenvolvida a modelagem de partes de um sistema de biblioteca segundo as diretrizes de cada um dos mtodos. O objetivo da modelagem no foi ser completa, mas ajudar a identificar pontos positivos e negativos dos mtodos. Em seqncia, os mtodos foram comparados com base nos elementos notacionais e explicaes conceituais oferecidas sobre alguns aspectos de um desenvolvimento. Estes aspectos foram identificados com o auxlio de engenheiros de software experientes em desenvolvimento e no trabalho de Nascimento (Nascimento, 1990). Com o auxlio desses mesmos engenheiros foi selecionado um conjunto de questes que possibilita a identificao das caractersticas de um sistema. Cada caracterstica informa que o mtodo deve possuir modelagem para certos aspectos. Desta forma, cada caracterstica foi relacionada a um ou mais dos aspectos referenciados anteriormente. Estas questes so respondidas pelo engenheiro de software, que tem como base o sistema que ele pretende desenvolver. Ainda visando alcanar o objetivo traado, foi estudado a tcnica de Inteligncia Artificial denominada teoria de funo de crena. Com esta teoria pode-se fazer o mapeamento das funes de crena aos mtodos para cada caracterstica do sistema. Posteriormente, a combinao destas funes indica o mtodo mais apropriado para cada fase do desenvolvimento do sistema em questo. 119

Conclus
6532 0 ) 74411('&%$ # "!
Captulo 7 - Concluso ________________________________________________________________________________________________
7.1.2
Mtodos orientados a objetos
Pelo estudo realizado pode-se concluir que o mtodo OOSE o nico a oferecer ampla modelagem para anlise de requisitos, os demais iniciam pela fase de anlise. Este mtodo realiza tarefas na fase de anlise de requisitos que os outros mtodos executam na anlise, realizando durante a anlise algumas tarefas do projeto, tornando assim seu projeto bem detalhado. No um mtodo prescritivo mas bastante completo e complexo, por isso indicado para equipes de desenvolvimento com mais de dois componentes e que possuam treinamento em todas as fases de um desenvolvimento. indicado para sistemas que necessitem de especialistas do domnio porque oferece modelagem para facilitar esta tarefa e para sistemas tcnicos e administrativos porque nestes tipos de sistemas pode se utilizar o reuso de componentes com maior facilidade, por no se distinguirem tanto um dos outros mesmo em organizaes diferentes. O mtodo OMT modela o sistema atravs de trs diferentes dimenses: esttica, dinmica e funcional, os outros se preocupam somente com as duas primeiras. A dimenso funcional bastante criticada entre os metodologistas que trabalham com orientao a objetos, mas que pode ser muito til para modelar sistemas com muita transformao de dados. O mtodo no apresenta praticamente nenhuma modelagem para a fase de projeto. um mtodo bastante prescritivo, explicando o que se deve fazer durante o desenvolvimento. indicado para equipes que tenham experincia em anlise. Caso a experincia seja em projeto pode ocorrer dificuldades tendo em vista que o mtodo direciona o desenvolvimento para a abstrao do problema. Sistemas com muita modelagem de dados e que possuam muitos clculos podem utilizar-se desse mtodo. O mtodo OOAD sofreu uma extenso da primeira verso. Primeiramente foram definidos modelos para a fase de projeto, posteriormente incorporou-se modelos para a fase de anlise. O projeto aborda aspectos que no so modelados pelos demais mtodos, como visibilidade e concorrncia (com exceo do mtodo Fusion). Utiliza-se tcnicas e diagramas definidos por outros metodologistas como CRC e use cases. No um mtodo prescritivo e bastante complexo, sendo portanto indicado para equipes experientes. Indicado para sistemas de tempo real, ou que possuam muita concorrncia ou que tenha a arquitetura distribuda. O mtodo OOA-OOD foi um dos primeiros mtodos orientados a objetos a serem desenvolvidos servindo de base para os que vieram posteriormente. O mtodo sugere o refinamento dos modelos de anlise (multicamadas) durante o projeto (modelo multicomponentes). um mtodo prescritivo, que se preocupa com o reuso de sistemas e bastante simples. indicado para desenvolvedores inexperientes, tambm para grandes equipes (anlise depois projeto) ou para pequenas (intercalao entre anlise e projeto). Deve ser utilizado para desenvolvimento de sistemas simples devido a pouca notao oferecida. O mtodo Fusion caracteriza-se por ser um mtodo integrador, reunindo elementos dos mtodos OMT, OOAD, formais e da tcnica CRC, complementando com modelos prprios. um mtodo quase completo, porque falta a cobertura para alguns aspectos. No um mtodo prescritivo e de ampla cobertura, por isso indicado para equipe que j possuem experincia em 120
desenvolvimento orientado a objetos. Pode ser aplicado em sistemas concorrentes por oferecer notao para a modelagem.
7.1.3
Conceitos e notao
Alguns conceitos apresentados pelos mtodos, apesar de se referirem ao mesmo contedo so nomeados diferentemente, o que pode gerar uma certa confuso quando se estuda mais de um mtodo. Uma soluo que poderia ser adotada, seria uma padronizao da nomeao dos conceitos, assim como aconteceu com a notao empregada, o que facilitaria o estudo de vrios mtodos. Problema semelhante ocorre com a notao empregada pelos autores dos mtodos. Alguns conceitos so graficamente representados de diferentes formas. Exemplo: um tringulo ligando duas classes, indica herana para o mtodo OMT, o que j significa agregao para o mtodo OOAOOD. Para o mtodo Fusion, a agregao representada quando se coloca uma classe dentro da outra e para o mtodo OOAD, a agregao uma linha com um crculo preenchido no lado da classe que agrega; onde este mesmo smbolo utilizado pelo mtodo OMT para definir cardinalidade de 0 ou mais em um relacionamento. Este tipo de problema exige ateno redobrada do desenvolvedor. Tentando solucionar esse problema, Grady Booch, Ivar Jacobson e James Rumbaugh, com ajuda de um conjunto de metodologistas e organizaes, definiram uma linguagem padro de notao chamada UML Unified Modeling Language, que foi adotada como padro pela OMG. Maiores detalhes podem ser obtidos no apndice D. A UML, como uma notao padro, tem o propsito de unificar as notaes existentes para a modelagem orientada a objetos, facilitando a comunicao entre analistas e projetistas que utilizem mtodos diferentes, e consequentemente notaes diferentes, em seus desenvolvimentos. Alm de facilitar a compreenso de todos os modelos, pois os modelos da estrutura esttica de um sistema, por exemplo, possuiro a mesma sinttica e semntica. importante ressaltar que a UML no um mtodo porque no oferece diretrizes de como conduzir o desenvolvimento. Ela uma notao padro que pode substituir as notaes definidas pelos autores dos mtodos. Por exemplo, pode-se utilizar o mtodo OMT com a notao UML em um determinado desenvolvimento.
7.1.4
Funo de crena
A busca pela interao entre duas reas do conhecimento muito importante e necessria, porque uma pode complementar a outra, como foi aplicado neste caso, onde a rea de Inteligncia Artificial auxiliou a rea de Engenharia de Software. A teoria de funo de crena com o algoritmo de Dempster e Shafer, soma ortogonal, permitiu a identificao do mtodo mais indicado atravs da combinao entre as vrias evidncias, identificadas pelas respostas fornecidas diante das perguntas apresentadas. A partir das vrias
121
evidncias que podem indicar mtodos diferentes, obtm-se uma evidncia que expressa o conhecimento atual. A funo de perda poderia ser tambm incorporada ao trabalho, possibilitando uma completa deciso sobre qual mtodo ser adotado, pois assim poderia sugerir o mtodo e calcular qual seria a perda se fosse utilizado um mtodo diferente. Neste sentido seria adotado o que oferecesse menor perda. Entretanto, este trabalho se props a sugerir um mtodo onde a deciso final ficaria a cargo do engenheiro de software, usurio do prottipo. Isto se deve ao fato do SGMOO no levar em conta aspectos gerenciais que so bastante relevantes em um desenvolvimento.
7.1.5
SGMOO
O SGMOO alcana seu objetivo inicial de implementar a proposta definida neste trabalho.
Ele apresenta interfaces separadas para cada tipo de usurio, possibilitando a indicao do mtodo mais apropriado no desenvolvimento de um sistema especfico e o aperfeioamento das crenas definidas, incluses/alteraes de questes, mtodos e fases. Para aperfeioar o SGMOO deve haver uma realimentao do prottipo. Isso se torna possvel atravs do acompanhamento do especialista em um desenvolvimento com os mtodos sugeridos pelo prottipo para o sistema em questo. Isto permitir verificar a eficincia para futuras modificaes na base de dados ou no aperfeioamento do modelo proposto, como ilustra a figura 7.1.
perguntas respostas mtodos
Prottipo
Desenvolvimento
Engenheiro de software
realimenta acompanha
Especialista em mtodos
Figura 7.1 - Possvel realimenta o do prottipo
O presente trabalho contribui com a rea de Engenharia de Software, principalmente, auxiliando no desenvolvimento de aplicaes. Ele oferece um estudo aprofundado de cinco mtodos orientados a objetos e a comparao entre eles, que permite ao engenheiro de software uma viso geral e detalhada desses mtodos. Quando o engenheiro de software tem que decidir sobre qual mtodo utilizar no desenvolvimento de um sistema especfico, ele possui duas sadas: i) escolher um mtodo 122
# 34231)'($%$! ' # 0 & # "
aleatoriamente, podendo ocasionar uma escolha errada ou ii) estudar todos os possveis mtodos para escolher o mais adequado. Neste sentido o SGMOO busca auxili-lo nessa tarefa dispendiosa de tempo. Nos ltimos anos muitas pesquisas vm sendo realizadas a cerca dos mtodos orientados a objetos e suas comparaes (Brinkkemper, 1995), (Fichman, 1992), (Marques), (Reinoso, 1994) e (Silveira, 1995). O presente trabalho tambm realizou uma comparao. Entretanto, os primeiros trabalhos comparam os mtodos a nvel de modelos e diagramas. Neste trabalho a comparao realizada a nvel dos elementos notacionais desses diagramas e base conceitual oferecida pelos mtodos. Diferentemente destes primeiros trabalhos (Nascimento, 1990) props o agrupamento de duas grandes reas do conhecimento (Engenharia de Software e Inteligncia Artificial). Foram comparados mtodos estruturados e utilizado sistemas especialistas. Da mesma forma, este trabalho agrupa essas duas reas, comparando mtodos orientados a objetos e utilizando teoria de funo de crena. A principal razo pela escolha da teoria de funo de crena deve-se ao fato de que est possui um suporte terico para tratamento de incerteza.
210()'%$" ( & # !
Tendo em vista o tempo limitado para desenvolver e concluir a dissertao, alguns aspectos do trabalho podem ser acrescentados ou aperfeioados, como: i) acrescentar novos mtodos orientados a objetos, atravs de um estudo aprofundado e de sua comparao com os outros, para permitir ao engenheiro de software uma viso mais abrangente dos mtodos; ii) iii) acrescentar novas perguntas devido ao surgimento de novos domnios de aplicao, onde necessita englobar suas caractersticas; acrescentar ao mapeamento de crenas os aspectos da parte gerencial de um desenvolvimento como quantidade de pessoal na equipe, conhecimento que a equipe possui sobre os mtodos a serem utilizados e mesmo sobre o domnio do problema, etc.; devido a incluso de novos mtodos e/ou perguntas necessrio, tambm, a incluso de funes de crena referentes ao mapeamento das respostas aos mtodos; incluso de funes de perda que viabilizam identificar qual a perda que se tem quando o prottipo sugere um mtodo, mas o usurio opta por outro; e, assim, decidir pelo mtodo que oferea menor perda; detalhar o critrio adotado de ponderao entre os elementos notacionais, ou seja, aumentar a faixa dos pesos, ao invs de somente 1 e 2. Isto possibilita uma melhor ponderao entre os elementos; sistematizar integrao com o SMM, para que este considere a escolha de mtodos orientados a objetos. O presente trabalho ser, ento, adicionado a subfuno 123
iv) v)
vi)
vii)
Building Strategy em Technical Environment Selection, onde os mtodos so escolhidos. Maiores detalhes (Nascimento, 1992). viii) realizar uma realimentao do SGMOO para aperfeioar a proposta. Outras idias ainda podem ser extradas deste trabalho, como: i) a proposta de um novo mtodo, porque com um estudo aprofundado pode-se ter o conhecimento suficiente para saber escolher as melhores partes de um mtodo que se aplicar a determinado domnio de aplicao; desenvolvimento de um produto final, tendo como base a arquitetura definida para o SGMOO, apresentada neste trabalho. Isso auxiliaria o engenheiro de software na tarefa de escolha de um mtodo, permitindo ganho de tempo e um produto final com mais qualidade.
$ " ('&%#!
ii)
Espera-se que o estudo e o prottipo tragam os seguintes resultados concretos: a) suporte os gerentes e desenvolvedores, atravs da utilizao de processos mais confiveis que reflitam ganho de qualidade no processo de desenvolvimento e consequentemente dos produtos gerados; b) conscientizao de que a escolha de um mtodo ou um conjunto deles no a soluo para todos os tipos de sistemas, uma vez que cada sistema possui suas prprias caractersticas, exigindo assim, uma escolha mais adequada de mtodos garantindo a qualidade do produto final. interessante notar que embora possam ser desenvolvidos mtodos abrangentes, os primeiros mtodos (primeira gerao) continuaro a ser utilizados, porque modelam bem determinados domnios de aplicao. A escolha do mtodo no ser somente devido ao que o mtodo oferece, mas tambm ser levado em considerao outros aspectos, como o tamanho e conhecimento da equipe de desenvolvimento. Neste sentido, acredita-se no ter muita necessidade a padronizao de um mtodo, porque mesmo com algumas falhas os primeiros mtodos sero utilizados. Entretanto, uma padronizao poderia ser feita em relao aos conceitos utilizados, pois enorme a quantidade de nomes atribudos ao mesmo conceito pelos mtodos, assim como foi feito a padronizao para a notao (UML), maiores detalhes apndice D. Finalmente, pode-se tomar como base os argumentos de (Fowler, 1997): Eu no acredito que se possa ter um nico processo para o desenvolvimento de software. Vrios fatores associados com o desenvolvimento de software induz em diferentes tipos de processos. Estes fatores incluem o tipo de software que est sendo desenvolvido (tempo-real, sistema de informao, produto para desktop), a escala (nico desenvolvedor, equipe de desenvolvimento pequena, equipe com 100 ou mais membros) e assim por diante.
124
ANDERSSON, M. Uses Cases in Object-Oriented Analysis. Sweden, Lund University. 1995. <http://www.efd.lth.se/~d87man/EXJOBB/Title_Abstract_Preface.html>. BAKKER, G. OMT Object Model: Notation, Concepts and Constructs. 1996.
<http://www.comp.mq.edu.au/courses/comp331/OMT/notation.html>. BIENVENU, M. Systems Design in ObjecTime. Byte, v.20, n.12, p.189-190, dez.1995. BOOCH, G. Object Oriented Design with Applications. California: The Benjamin/Cummings Publishing Company, Inc., 1991. ______ Object Oriented Analysis and Design with Applications. 2.ed. Canad: Addison Wesley, 1994. ______ Object Solutions: Managing the Object Oriented Project. Menlo Park: Addison-Wesley, 1996. ______ Quality Software and the UML. Object Magazine, Canad, v.7, n.1, p.78-80, mar.1997. BORGES, G. do E. S., NASCIMENTO, M. E. M. Uma avaliao de mtodos orientados a objetos e modelos de processo. Braslia: UnB, 1997. ______ Sistema baseado em conhecimento para selecionar mtodos de desenvolvimento de software orientados a objeto. In: 50a. Reunio Anual da SBPC - Sociedade Brasileira para o Progresso da Cincia, 1998a. Natal: UFRN, 1998. p.1054-1055. ______ SGMOO: Sistema Gestor de Mtodos Orientados a Objetos baseado em conhecimento. In: III Workshop de Teses em Engenharia de Software, 1998. Maring: 1998b. BRINKKEMPER, S., HONG, S., BULTHUIS, A., GOOR, G. v.d. Object Oriented Analysis and Design Methods a Comparative Review. Enschede: University of Twente. 1995. <http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/ oodoc/oo.html>. Business on the Net. BYTE, USA, v.21, n.8, ago.1996. CAMARO, P. C. B. Cientficos, 1993. Glossrio de Informtica. Rio de Janeiro: LTC - Livros Tcnicos e
CAMPOS, F. B. Sistematizando o Processo de Desenvolvimento de Software - Uma abordagem Orientada ao Reuso. Braslia: UnB, 1997.

125
Bibliografia ________________________________________________________________________________________________
CAPRETZ, L. F., LEE, P. A. Object Oriented Design: guidelines and techniques, Information and Software Technology, v.35, n.4, abr.1993. CARVALHO, R. R. A. Funo de Crena como Ferramenta para Selecionar Diagnsticos em Raciocnio Baseado em Casos. Braslia: UnB, 1996. CHOOSING REUSABLE COMPONENTS. Software Development, USA, v.3, n.4, abr.1995. COAD, P., YOURDON, E. Anlise Baseada em Objetos. Traduo por CT Informtica. Rio de Janeiro: Editora Campus, 1992. ______ Projeto Baseado em Objetos. Traduo por Vandenberg Dantas de Souza. Rio de Janeiro: Editora Campus, 1993. COLEMAN, D. et alii. Desenvolvimento Orientado a objetos: o mtodo Fusion. Traduo por Geraldo Costa Filho. Rio de Janeiro: Editora Campus, 1996. CROSS - PLATAFORM DEVELOPMENT. Dr. Dobb's Journal. Canad: v.20, n.228, issue 3, mar.1995. DATE, C. J. Introduo a Sistema de Banco de Dados. Traduo por Hlio Auto Gouveia. Rio de Janeiro: Editora Campus, 1989. DICK, K. Trajectory Analysis: ODBMS Vendors. USA: <http://www.odbmsfacts.com./trajectory/ trajintr.html>. ENCRYPTION, ERROR CORRECTION, & COMPRESSION. Dr. Dobb's Journal. Canad: v.22, issue 1, jan.1997. FICHMAN, R. G. KEMERER, C. F. Object-Oriented and Conventional Analysis and Design Methodologies - Comparison and Critique. IEEE Computer, Massachusetts, v.25, n.10, out.1992. FOWLER, M., SCOTT, K. UML Distilled - Applying the Standard Object Modeling Language. USA: Addison Wesley Longman, Inc., 1997. HAINES, J. Persistent Object Stores Applications. nov.1995. <http://demos.anu.edu.au/jason/ thesis/thesis/www> HODGSON, J. Software Engineering Process Models. 1995. <http://www.sju.edu/~jhodson/se/ models.html> HUMPHREY, W. S. Managing Software Process. Canad: Addison-Wesley, 1989. JACOBSON, I. Object-Oriented Software Engineering: A use case driven approach. USA: ACM Press, 1992. KAN, S. H. Metrics and Models in Software Quality Engineering. Massachusetts: AddisonWesley, 1995. 126
Bibliografia ________________________________________________________________________________________________
KEYES, J. Software Engineering Productivity Handbook. USA: McGraw Hill, 1993. KHOSHAFIAN, S. Banco de Dados Orientado a Objeto. Traduo por Tryte Informtica. Rio de Janeiro: Infobook, 1994. KIM, W. Introduction to object-oriented databases. Cambridge: The MIT Press, 1990. KITCHENHAM, B. A. Evaluating Software Engineering Methods and Tool - Part 1: The Evaluation Context and Evaluation Methods. ACM SIGSOFT - Software Engineering Notes, Inglaterra, v.21, n.1, p.11-15, jan.1996a. ______ Evaluating Software Engineering Methods and Tool - Part 2: Selecting an Appropriate Evaluation Method - Technical Criteria. ACM SIGSOFT - Software Engineering Notes, Inglaterra, v.21, n.2, p.11-15, mar.1996b. ______ Evaluating Software Engineering Methods and Tool - Part 3: Selecting an Appropriate Evaluation Method - Pratical Issues. ACM SIGSOFT - Software Engineering Notes, Inglaterra, v.21, n.4, p.9-12, jul.1996c. MARQUES, A. F. D. M. R. Descrio de Metodologias de Anlise orientadas a Objetos. Braga: Universidade do Minho. <http://alfa.di.uminho.pt/~mesafm/ analiOO.html> MARTIN, J. Princpio da Anlise e Projeto baseado em Objetos. Traduo por Cristina Bazn. Rio de Janeiro: Editora Campus, 1994. McCLURE, S. Object Database vs. Object-Relational Databases. International Data Corporation: ago.1997. <http://www.cai.com/products/jasmine/analyst/idc/ 14821E.htm> McFARLAND, G., RUDMIK, A. Object-Oriented Database Management Systems - A Critical Review. Technology Assessment: set.1993. <http://www.dacs.com/techs/OODBMS/ oodbms.toc.html> McGEE, M. D. e BOYCE, J. Microsoft Access for Windows - Step by Step. Washington: Microsoft Press, 1993. MICROKERNELS AND OPERATING SYSTEMS. Dr. Dobb's Journal. Canad: v.19, n.214, issue 5, mai.1994. MONTGOMERY, S. L. Information Engineering: analysis, design and implementation. Cambridge: Academic Press, 1994. NASCIMENTO, A. R. C. An Expert System to Advise on Information System Development Approaches. Manchester: UMIST, 1990. NASCIMENTO, M. E. M. SMM (Software Management Model): A Multidimensional and Integrative Software Development Management Model. Manchester: UMIST, 1992.
127
Bibliografia ________________________________________________________________________________________________
NASCIMENTO, M. E. M. e NASCIMENTO, A. R. C. Um modelo orientado a multi-mtodos, multi-tcnicas e multi-ferramentas para o desenvolvimento de software. In: Textos em Cincia da Computao, 1993. p.11-20. ODMG. <http://www.odmg.org/> OLIVEIRA, W. V. Fundamentos de Metodologia Cientfica. Braslia: UnB, 1997. OODB. <http://www.mb2.tu-chemmitz.de/oodb/oodb2.html> ORFALI, Robert et.alii. The Essential Distributed Objects Survival Guide. USA: Wiley Computer Publishing, 1996. PATTERNS. Object Magazine, USA, v.7, n.1, mar.1997. PEREIRA, C. E. Mtodos de Anlise de Sistemas de Tempo Real usando Tcnicas de Orientao a Objetos. In: X Simpsio Brasileiro de Engenharia de Software, 1996. So Carlos: Departamento de Cincias de Computao e Estatstica, 1996. PERRY, G. M. Access 2 for Windows - Tcnicas de Programao. Traduo por Jorge Chedid. Rio de Janeiro: Axcel Books, 1994. PRESSMAN, R. S. Engenharia de Software. Traduo por Jos Carlos Barbosa dos Santos. 3. ed. So Paulo: Makron Books, 1992. QUATRANI, T. Visual Modeling with Rational Rose and UML. USA: Addison Wesley Longman, Inc., 1998. RATIONAL SOFTWARE CORPORATION. UML past, present and future. 1997a. <http://www.rational.com/uml/html/summary/summary5.html> ______ UML Frequently Asked Questions (FAQs). 1997b. <http://www.rational.com/uml/ faq.html>. ______ UML Proposal to the Object Management Group, in response to the AO&D Task Force's RFP - 1. Version 1.1. v.1.1, set.1997c. <http://www.rational.com/uml/> REINOSO, G. B., HEUSER C. A. Aplicao comparativa de Tcnicas de Anlise Orientada a Objetos. Porto Alegre: UFRGS, 1994. T.I. n.416. ______ Comparando o Processo de Modelagem de Tcnicas de Anlise Orientada a Objetos. In: VIII Simpsio Brasileiro de Engenharia de Software, 1994. Curitiba: Centro Internacional de Tecnologia de Software, 1994. RICH, E. e KNIGHT, K. Inteligncia Artificial. Traduo por Maria Cludia Santos Ribeiro Ratto. 2. ed. So Paulo: Makron Books, 1994. RODRIGUES, S. R., MONARD, M. C.
a
Sistemas baseados em conhecimento - Conceitos fundamentais e aplicaes. In: 1 Jornada USP - SUCESU-SP de Informtica e Telecomunicaes, 1993. So Paulo: ICMSC, 1993. 128
Bibliografia ________________________________________________________________________________________________
RUMBAUGH, J. et alii. Modelagem e Projetos baseados em Objetos. Traduo por Dalton Conde de Alencar. Rio de Janeiro: Editora Campus, 1994. SHLAER, S., MELLOR, S. J. Anlise de Sistemas Orientada para Objetos. Traduo por Anna Terzi Giova. So Paulo: Editora McGraw-Hill, 1990. SILVA, R. P., PRICE, R. T. Avaliao de metodologias de anlise e projeto orientadas a objetos voltadas ao desenvolvimento de aplicaes, sob a tica de sua utilizao no desenvolvimento de frameworks orientados a objetos. Porto Alegre: UFRGS, 1996. SILVA, W. T. Algoritmos para Raciocnio Evidencial usando Funes de Crena. Rio de Janeiro: PUC-RJ, 1991. SILVEIRA, I. F. Anlise de Sistemas Orientada a Objetos: Um Estudo Comparativo das Metodologias de Wirfs-Brock e de Coad/Yourdon. Porto Alegre: UFRGS, 1995. SOMMERVILLE, I. Software Engineering. 4. ed. USA: Addison-Wesley, 1992. TANENBAUM A. S. Sistemas Operacionais Modernos. Traduo por Nery Machado Filho. Rio de Janeiro: Prentice Hall do Brasil, 1995. THAYER, R. H. Tutorial: Software Engineering Project Management. Los Alamitos: IEEE Computer Society Press, 1988.
WEISS, S. M., KULIKOWSKI, C. A. Guia prtico para projetar Sistemas Especialistas. Traduo por Carlos Octrio Pavel. Rio de Janeiro: LTC - Livros Tcnicos e Cientficos Editora S. A., 1988. YONG, C. S. Banco de Dados - Organizao, sistemas, administrao. 5. ed. So Paulo: Editora Atlas, 1988.
129
Este apndice apresenta o resumo da notao utilizada pelos mtodos orientados a objetos descritos neste trabalho, com o objetivo de facilitar a compreenso da sinttica e da semntica dos modelos e diagramas gerados a partir da modelagem do sistema utilizado como exemplo. Deste modo, o leitor no necessitar buscar os livros fundamentais dos mtodos para obter o resumo da notao dos mesmos.
As figuras de A.1 - A.3 apresentam a notao utilizada pelo mtodo OOSE durante as fases de requisitos, anlise e projeto.
Ator: Use Case: Herana:
Nome do ator
Extenso:
Nome do use case1
Nome do use case2
Figura A.1 - Nota o utilizada no modelo de requisitos (Jacobson, 1992)

Resumo da nota

utilizada pelos mtodos
1CB9#@%)8")6745%2310)'&%#! A 9 "2 $ " " ( $"
Nome do use case
Usa:
Nome do use case1
Nome do use case2
130
Apndice A - Resumo da notao utilizada pelos mtodos ________________________________________________________________________________________________
Objetos:
Subsistema:
Entidade
Interface
Controle
Obj. 1
Atributo:
Obj. 2
atributo [1] tipo
Entidade
Obj. 3
Figura A.2 - Nota o utilizada no modelo de an lise (Jacobson, 1992)

Blocos:
Blocos no diagrama:
objeto
Borda do sistema:
mensagem
Operao:
Tempo:
sinal
Grafos de transio de estado:

Incio Enviar mensagem Receber mensagem Retorno da mensagem Enviar sinal Deciso
Estado
Receber sinal
destruir objeto
-refere-se ao estado anterior
Executar tarefa
Rtulo
Figura A.3 - Nota o utilizada na fase de projeto (Jacobson, 1992)
As figuras de A.4 - A.10 apresenta a notao utilizada pelo mtodo OMT no modelo de objetos (modelagem comum e avanada), modelo dinmico e modelo funcional; ambos na fase de anlise. 131
) ' % 0(&$"#!
Apndice A - Resumo da notao utilizada pelos mtodos ________________________________________________________________________________________________ Classe:

Nome da Classe Nome da Classe atributo operao Classe-1
Associao: Nome da Associao papel-1 papel-2
Classe-2
Generalizao (Herana):
Associao qualificada: Nome da Associao papel-2
Superclasse
Classe-1
qualificador
Classe-2
papel-1
Subclasse-1
Subclasse-2
Agregao:
Classe Equipamento
Agregao (forma alternativa):

Classe Equipamento
Classe-Pea-1
Classe-Pea-2
Classe-Pea-1
Classe-Pea-2
Figura A.4 - Nota o utilizada no modelo de objetos (Rumbaugh, 1994)
132
Multiplicidade de Associaes:
Classe
Ordenao: {ordenado}
Classe
Exatamente um Muitos (zero ou mais) Opcional (zero ou um)
Classe
Instncias de objetos:
Classe
(Nome da Classe)
1+
(Nome da Classe) nome_de_atributo = valor
Classe
Um ou mais Numericamente especificado
1-2,4
Classe
Relacionamento de instncias:
Atributo de ligao:
Nome da associao
(Nome da Classe)
Nome da classe
Classe-1
Classe-2
Associao ternria:
atributo de ligao Classe-1 papel-1 nome papel-2 Classe-2
papel-3 Classe-3
Figura A.5 - Nota o utilizada no modelo de objetos - cont. (Rumbaugh, 1994)
133
Operao abstrata:
Superclasse operao {abstrata} A operao abstrata na superclasse.
Associao como classe:

Classe-1 Classe-2
Nome da associao As subclasses devem proporcionar implementaes concretas da operao. atributo de ligao ... operao de ligao ...
Subclasse-1 operao
Subclasse-2 operao
Propriedades da generalizao:
Superclasse
Superclasse
Existem mais subclasses
As subclasses pertecem a uma comunidade que se sobrepe (no-disjunta)
Subclasse-1
Subclasse-2
...
Subclasse-1
Subclasse-2
Herana mltipla:
Superclasse-1
Superclasse-2
Superclasse
discriminador
O discriminador um atributo cujo valor faz a distino entre as subclasses.
...
Subclasse
...
Subclasse-1
Subclasse-2
Figura A.6 - Nota o utilizada no modelo de objetos - conceitos avanados (Rumbaugh,
1994)
134
Atributos de classe e operaes de classe:

Nome da classe $atributo $operao
Atributo derivado:
Nome da classe
Classe derivada:
Nome da classe
/atributo
Restries em objetos: Propagao de operaes:

Classe-1 Classe-1 operao Classe-2 atributo-1 atributo-2 operao { atributo-1 >= 0 }
operao
Associaes derivadas:
Restries entre associaes: A1
Classe-1
Classe-2
Classe-1
{subconjunto}
Classe-2
A2
Figura A.7 - Nota o utilizada no modelo de objetos - conceitos avanados - cont.
(Rumbaugh, 1994)
135
Apndice A - Resumo da notao utilizada pelos mtodos ________________________________________________________________________________________________ Evento causa transio entre estados:
Estado-1 evento Estado-2
Evento com atributo:

evento (atributo)
Estado-1
Estado-2
Estados Inicial e Final:

Estado intermedirio
Ao em uma transio:
Estado-1 evento / ao Estado-2
Estado inicial
Transio guardada:
Estado-1 evento [guarda] Estado-2
Evento de sada em uma transio:

Estado-1 evento 1 / evento 2 Estado-2
Aes e atividade enquanto em um estado:

Nome do Estado entrada / ao-entrada faa: atividade-A evento-1 / ao-1 ... sada / ao-sada
Enviando um evento p/ outro objeto:

Estado-1 evento 1 evento 2 Estado-2
Classe-3
Figura A.8 - Nota o utilizada no modelo dinmico (Rumbaugh, 1994)
136
Generalizao de estados (Aninhamento): Super-estado

evento 1
Sub-estado-1 Sub-estado-2
evento 3
evento 2
Subdiagramas concorrentes: Super-estado
Sub-estado-1
Sub-estado-3
evento 1
Sub-estado-2
Sub-estado-4
evento 2
Subdiviso do controle: Super-estado
Sincronizao do controle:
Sub-estado-1
evento 1
Sub-estado-3
evento 0 evento 2
Sub-estado-2 Sub-estado-4
evento 3 evento 4
Figura A.9 - Nota o utilizada no modelo dinmico - cont. (Rumbaugh, 1994)
137
Apndice A - Resumo da notao utilizada pelos mtodos ________________________________________________________________________________________________ Processo: Fluxo de dados entre processos:
nome do processo
processo-1
processo-2
Depsito de dados ou objeto arquivo:

Nome do depsito de dados
Fluxo de dados que resulta em um depsito de dados:

Nome do depsito de dados
Objetos atores (como origem ou destino de dados):

d1 nome do processo d2
Fluxo de controle: resultado booleano
Ator-1
Ator-2
processo-1
processo-2
Acesso a valor de depsito de dados:

Depsito de dados
d1
Atualizao de valor de depsito de dados:

Depsito de dados
d1
processo
processo
Acesso e atualizao de valor de depsito de dados:

Depsito de dados d1
Composio de valor de dado: Duplicao de valor de dado: Decomposio de valor de dado:
d1 composto d2
d1
processo
composto
d1 d2
Figura A.10 - Nota o utilizada no modelo funcional (Rumbaugh, 1994)
de anlise e projeto.
( & $ ''$%#!"

As figuras de A.11 - A.16 apresentam a notao utilizada pelo mtodo OOAD para a fase 138
Apndice A - Resumo da notao utilizada pelos mtodos ________________________________________________________________________________________________ Relacionamentos das classes:
Nome da utilidade da classe atributos operaes() {constraints }
Classes:
Nome da classe atributos operaes() {constraints }
Nome da categoria classes
associao herana tem
argumentos formais Nome da classe parametrizada
argumentos atuais Nome da classe instanciada Nome da metaclasse
usa instanciao metaclasse
Adornos dos relacionamentos: rtulo papel [chave] {constraint} cardinalidade
Adornos do contedo:
por valor classe atribuda por referncia
Cardinalidade:
1 N 0. 1. 0. 3. 1.
. . . . .
N N 1 7 3, 7
Exatamente um Nmero ilimitado (zero ou mais) Zero ou mais Um ou mais Zero ou mais Limite especificado Limite especificado ou nmero exato
Propriedades:
A S
Controle de exportao:
F V
classe abstrata classe esttica
classe amiga classe virtual
pblico protegido Anotaes:
privado implementao
Aninhamento:
Nome da classe
texto
Classe aninhada
Figura A.11 - Nota o utilizada no diagrama de classes (Booch, 1994)
139
Estado:
Nome aes
Transio de estado:
evento [guarda] / ao
Histria:
H
Superestado
Aninhamento:
Estado-1
Estado-1
Estado-1
Figura A.12 - Nota o utilizada no diagrama de transi o de estados (Booch, 1994)

Objeto:
Sincronizao: simples sncrono
Link:
ordem: mensagem objeto / valor papel [chave] {constraint}
Visibilidade:
G P F L
global parmetro campo local
Nome do objeto atributos
balking timeout assncrono
Figura A.13 - Nota o utilizada no diagrama de objetos (Booch, 1994)
objeto-1 evento
objeto-2
objeto-3
objeto-4
operao( )
script
operao( ) operao( ) evento
Figura A.14 - Nota o utilizada no diagrama de intera o (Booch, 1994)

140
Programa principal
Nome do mdulo
Especificao nome
Corpo nome
Subsistema
Nome do subsistema
Dependncia
Figura A.15 - Nota o utilizada no diagrama de mdulo (Booch, 1994)
Processador
Dispositivo
Conexo
rtulo
nome
nome
processo 1 processo 2 ... processo n
Figura A.16 - Nota o utilizada no diagrama de processo (Booch, 1994)
As figuras de A.17 - A.20 apresentam a notao utilizada pelo mtodo OOA-OOD, na fase de anlise.
1 $ ( & $ 2$0)'$%#!"

Diagrama de Estado do Objeto: Transio Estado
Figura A.17 - Nota o utilizada no diagrama de estado do objeto ( Coad, 1992)
141
Condio (se; precondio; acionador, finalizador) Loop (enquanto; fazer; repetir; acionador / finalizador)
Bloco de texto C o n e c t o r (conectado ao topo do prximo smbolo)
Figura A.18 - Nota o utilizada no diagrama de servio ( Coad, 1992)
Especificao de Classe&Objeto: especificao atributo atributo Entrada externa Sada externa Diagrama de Estado de Objeto Especificaes adicionais notas servio <nome & Diagrama de Servio> servio <nome & Diagrama de Servio> e, na medida do necessrio, Cdigos de acompanhamento Cdigos de estado aplicveis Requisitos de tempo Requisitos de memria
Figura A.19 - Nota o utilizada na especifica o classe&objeto ( Coad, 1992)

142
1
Classe&Objeto:
Nome da Classe&objeto atributos servios servios
1
Classe:
Nome da classe atributos
Estrutura Gen-Espec:
Generalizao
Estrutura Todo-Parte:
Todo
1, m 1 Especializao 1 Especializao 2 Parte 1
1, m 1 Parte 2
Conexo de ocorrncia:
Nome da Classe&objeto1 Nome da Classe&objeto2 1, m
Conexo de Mensagem:
Emissor Receptor
Figura A.20 - Nota o utilizada no modelo de an lise ( Coad, 1992)

As figuras de A.21 - A.26 apresentam a notao utilizada pelo mtodo Fusion, nos modelos e grafos.
1 (& $ 0)'%# !"

143
Classe:
Nome da classe atributo
Relacionamento:
Classe-1 papel-1 C N o m e papel-2 atributo C Classe-2
Agregao:
Classe agregada atributo Classe-1 C Classe-2
Cardinalidade (C): zero ou mais (default)
*
+ N N..M
zero ou mais um ou mais valor numrico intervalo numrico
Generalizao (herana por subtipos):

Superclasse Superclasse
As subclassses podem se sobrepor (nodisjuntas)
As subclasses geram parties da Superclasse
Subclasse
Subclasse
Subclasse
Subclasse
Fronteira do modelo de objetos do sistema:
Marcador de totalidade:
Todos os membros participam
Figura A.21 - Nota o utilizada no modelo de objetos ( Coleman, 1996)
144
Modelo Ciclo-de-vida:
lifecicle [Nome:] Expresso_Regular (NomeLocal = Expresso_Regular)* Expresses_Regulares: Nome Concatenao Alternncia Repetio Zero ou mais Uma ou mais Opcional Intercalao Agrupamento
Qualquer nome de evento (operao), nome local ou evento de sada x.y x|y x* x+ [x] || (x)
Modelo de Operao:
Operation: Description: Reads: C hanges: Sends: Assumes: Result: identificador da operao <texto> Descrio da operao <valores fornecidos> <componentes do estado> <valores fornecidos> <componentes do estado> <comunicao com agente> <asseres> (pr-condies) <asseres> (ps-condies)
Figura A.22 - Nota o utilizada no modelo de interfaces ( Coleman, 1996)
Objeto:
Valor retornado por uma mensagem: operao_do_sistema ( Nome: Classe obj-1: Classe-1 ) obj-2: Classe-2
n = nome_ da_mensagem ( ) : Tipo
Passagem de Mensagens aos objetos: Criao dinmica de objetos: operao_do_sistema ( obj-1: Classe-1 nome_da_ mensagem (lista de parmetros) ) operao_do_sistema ( obj-2: Classe-2 obj-1: Classe-1 ) obj-2: Classe-2
criar ( )
Figura A.23 - Nota o utilizada nos grafos de intera o de objetos ( Coleman, 1996)

145
Coleo de objetos:
Nome_da_coleo: Classe dos objetos
Passagem de mensagens para objetos da coleo: operao_do_sistema ( )

obj-1: Classe-1
nome_da_mensagem (lista de parmetros) [predicado de seleo; predicado de parada)
obj-2: Classe-2
Sequenciamento de informaes: operao_do_sistema ( )

obj-1: Classe-1
(1) nome_da_mensagem_a ( )
obj-2: Classe-2
(1.1) nome_da_mensagem_b ( ) (2) nome_da_mensagem_c ( )

obj-3: Classe-3 obj-4: Classe-4
Figura A.24 - Nota o utilizada nos grafos de intera o de objetos - cont. ( Coleman, 1996)

146
Classe (cliente):
Setas de referncia de visibilidade: referncia permanente
Objeto servidor:
Nome da classe
Nome: classe
referncia dinmica Servidor com tempo de vida desvinculado: Coleo de objetos servidores:
col nome: classe dos objetos
Nome da classe
obj-1: Classe-1
Servidor com tempo de vida vinculado:

Nome da classe
Objeto servidor constante:

constant nome: Classe
obj-1: Classe-1
Objeto criado dinamicamente:

new nome: Classe
Referncia exclusiva ao objeto servidor:
Nome da classe
obj-1: Classe-1
Coleo de objetos servidores:
Nome da classe
obj-1: Classe-1
Figura A.25 - Nota o utilizada nos grafos de visibilidade ( Coleman, 1996)
147
Descrio de classe: classe <NomeDaClasse> [ isa <NomesDasSuperClasses> ] // para cada atributo attribute [Mutabilidade] <nome_do_atrib> : [Compartilhamento] [Vinculao] <Tipo> . . // para cada mtodo [method] <nome_do_mtodo> <lista_de_argumentos> [:<Tipo>] . . endclass
Figura A.26 - Nota o utilizada na descri o de classes ( Coleman, 1996)

148
Requisitos do sistema de biblioteca

Este apndice apresenta os requisitos do sistema de biblioteca facilitando a compreenso do sistema que serviu de exemplo para a modelagem, seguindo os cinco mtodos orientados a objetos: OOSE, OMT, OOAD, OOA-OOD e Fusion. um sistema de biblioteca simples que controla cadastros (de obras, usurios e funcionrios), emprstimos, reservas, cobranas, pagamentos (de dvidas) e emisso de relatrios, bem como aplicao de verificaes para emprstimo e reserva.
Levantar os requisitos necessrios a um sistema de automao dos procedimentos relacionados ao emprstimo de livros e demais publicaes em uma biblioteca genrica. Este documento deve definir as funes e interfaces desejadas para os sistemas que venham a se basear nesta especificao. Deve ser descrito o que se deseja do sistema, que ser a referncia para as fases posteriores no processo de desenvolvimento. Os conceitos e termos utilizados devem ser o mais prximos possveis do domnio do problema (biblioteca). No devem ser utilizados nesta fase termos muito tcnicos pertencentes ao domnio de implementao. O documento final deve ser compreensvel por especialistas da rea de bibliotecas, de modo que possa ser criticado e aperfeioado. Este documento visa uma especificao genrica para o problema de automao de emprstimos em bibliotecas. Detalhes de uma implementao especfica sero considerados na fase de Levantamento de Requisitos Especficos (LRE). Ao final deste documento as seguintes questes devem estar claramente respondidas: i) quais funes o sistema deve executar?, ii) quais interfaces so necessrias?, iii) quais informaes o sistema armazena, produz e consome?, iv) quais as restries que se aplicam ao sistema? e v) Quais os relacionamentos entre os agentes externos e o sistema?
Segue uma lista dos conceitos bsicos utilizados no documento: Acervo: conjunto de obras da biblioteca; Cadastro: informaes organizadas na forma de um conjunto de registros de estrutura
definida. Intranet: rede interna organizao baseada nos protocolos e servios TCP-IP; 149
5HGFE'D7A0@974543120(%&#$" ! ) CB 58 58 6 )' 5 6V# W 6 XATU17YT51FXVUU67T5RSQ PI
ISBN: codificao classificatria internacional atribuda a livros; ISSN: codificao internacional atribuda a peridicos; Obra: referncia genrica a livros, peridicos, teses ou qualquer outro documento sob a guarda da biblioteca; Tombo: nmero de registro sequencial atribudo a uma obra quando a mesma cadastrada na biblioteca.
O cadastramento de obras e o controle de emprstimos so as atividades principais de qualquer biblioteca. A medida que o volume de obras em uma biblioteca aumenta e o nmero de usurios tambm, as atividades de controle deste acervo vo se tornando intensas, dificultando a administrao da biblioteca. Os usurios tambm enfrentam problemas, pois tm dificuldade em localizar as obras desejadas, tendo que muitas vezes se deslocar at a biblioteca e descobrir que a obra desejada no est no cadastro ou est emprestada para outro usurio. So muitos os sistemas informatizados existentes que tratam deste problema, sendo na sua maioria sistemas de grande porte que suportam grandes bibliotecas. A proposta deste projeto de um sistema que suporte tanto pequenas como grandes bibliotecas. O sistema dever ser capaz de ser instalado em microcomputadores (para uma pequena biblioteca), em estaes de maior capacidade (para uma biblioteca mdia), e em estaes de alta capacidade (para uma grande biblioteca). Portanto o sistema proposto dever ser portvel para diferentes plataformas de hardware/sistema-operacional. O sistema dever permitir aos usurios que tiverem acesso rede Internet, acesso a funcionalidades bsicas como: pesquisa s obras, reservas, etc., sem a necessidade de se deslocarem at a biblioteca. Alm da portabilidade, o sistema dever ter projeto modular que permita uma configurao simples para pequenas bibliotecas e configuraes mais complexas para grandes bibliotecas. A biblioteca pode manter em seu acervo os seguintes tipos de obras: (i) Impressos (papel): livros, teses, monografias, peridicos, enciclopdias, dicionrios; (ii) Mdia digital (disquetes e CDs): softwares educacionais, utilitrios, enciclopdias, e etc.. (iii) Mdia visual (fitas de vdeo e DVDs ): cursos dirigidos, programas educacionais, etc. (iv) Publicaes na forma de arquivos digitais25 pblicos: teses, monografias, artigos tcnicos, etc. Os sistemas desenvolvidos para esta rea devero dar suporte aos procedimentos de controle do acervo de livros/publicaes das instituies e s operaes bsicas a serem executadas pelos operadores e usurios do sistema.
25
So arquivos digitais de textos (por exemplo: um documento gerado pelo WORD no formato .doc) que podem ser copiados para consulta e pesquisa sem a necessidade do procedimento de emprstimo.

150
O sistema informatizado composto por um conjunto de equipamentos centrais, equipamentos remotos, mdulos de software, mdulos de dados e documentos. O equipamento central armazenar os mdulos de informaes que contero todas as informaes relativas ao acervo e aos emprstimos de livros, unicamente acessvel pelo pessoal de suporte tcnico. Os equipamentos remotos sero os terminais que permitiro o acesso dos usurios e operadores ao sistema. Podero estar distribudos pela biblioteca ou departamento (Intranet), ou em qualquer lugar por meio da Internet. Os mdulos de software implementaro as funcionalidades do sistema podendo estar associados ao equipamento central ou aos equipamentos remotos. Os documentos componentes do sistema so desde os documentos de projeto at os manuais de operao e manuteno do sistema. Os agentes do sistema so os agentes humanos que interagem com o sistema, so os operadores, usurios, administradores e pessoal de suporte. Os operadores so os funcionrios da biblioteca responsveis pelas funes rotineiras como emprstimo de livros, cobrana de multas, cadastramento de usurios, cadastramento de livros, reservas e outros. Os usurios so o pblico em geral que tiver acesso biblioteca para fazer consultas e no local da biblioteca utilizar as obras. O pblico em geral no pode retirar as obras da biblioteca na forma de emprstimo. Os usurios cadastrados podem fazer reservas e emprstimos. Os administradores so as pessoas que gerenciam a biblioteca e tero acesso a dados globais como: quantidade de livros emprestados, ndices de atraso na devoluo, ndice de perdas de livros, livros mais solicitados, reas mais solicitadas, etc. Pessoal de suporte so os profissionais de informtica que faro o acompanhamento do sistema durante sua vida til, administrao dos bancos de dados, configuraes de redes, manutenes e evolues no sistema.
As funcionalidades e as restries genricas do sistema so divididas nos seguintes itens: i) funcionalidades disponveis aos usurios, ii) restries impostas aos usurios que desejem fazer reservas, iii) restries impostas s obras a serem reservadas, iv) funcionalidades disponveis aos operadores, v) restries impostas aos usurios que desejem fazer emprstimo, vi) restries impostas s obras a serem emprestadas; vii) funcionalidades disponveis aos administradores e viii) funcionalidades disponveis ao pessoal de suporte.
1 ' 2 0)'($84 @7R' "FP ' I8' %%04GF @%4D ' A S 5 Q ! A A H $ E
4$@B@8' 7643&2 0)(&%# " ' A 9 5 ' $ 1 ' ' $ $ !

151
C 0
i) Funcionalidades disponveis aos usurios 1. 2. 3. 4. Navegar pelo tutorial da biblioteca e manual de uso do sistema; Verificar a disponibilidade de determinada obra no acervo da biblioteca; Verificar a lista de obras disponveis por determinado autor ou assunto (palavra chave); Verificar a disponibilidade para emprstimo de uma obra especfica;
5. Visualizar a ficha de resumo de determinada obra; 6. Acessar o documento digital (arquivo de texto) de determinada obra quando disponvel (teses, monografias e etc.); 7. Impresso da ficha cadastral da obra; 8. Observao: as funcionalidades disponveis aos usurios podero ser acessadas por meio de terminais colocados na biblioteca para este fim ou por meio de microcomputadores pessoais interligados Internet. ii) Restries impostas aos usurios que desejem fazer reservas: 1. Ser um usurio cadastrado; 2. No estar devendo nenhuma obra e nenhuma multa. iii) Restries impostas as obras a serem reservadas 1. s ser efetuada a reserva se houver disponibilidade de ttulos daquela obra no perodo desejado. iv) Funcionalidades disponveis aos operadores 1. Emprestar obras para usurios cadastrados; 2. Receber retorno de obra/tombo emprestado; 3. Cobrar multa por atraso na devoluo; 4. Imprimir recibo da multa, lista de obras que esto emprestadas a determinado usurio ou ficha de identificao do tombo/obra 5. Cadastrar novo usurio, nova obra/tombo ou novo tombo de obra j cadastrada; 6. Excluir usurio, obras ou tombo do cadastro; 7. Fazer reserva de obras/tombo; 8. Gerar lista de usurios devedores de obras/tombos; 9. Gerar arquivos texto para cobranas de obras/tombos emprestados no devolvidos; 10. Observao: as funcionalidades disponveis aos operadores sero executadas em terminais localizados na prpria biblioteca, no estando disponveis via Internet, mas apenas na Intranet da biblioteca. v) Restries impostas aos usurios que desejem fazer emprstimo 1. Ser um usurio cadastrado; 2. No estar devendo nenhuma obra e nenhuma multa; 3. No ter excedido cota de emprstimo. 152
vi) Restries impostas as obras a serem emprestadas 1. Nmero de obras reservadas menor que nmero de tombos disponveis; 2. Obra/tombo no estar em restaurao; 3. Observao: o fato de uma obra ter sido reservada no implica necessariamente que a mesma ser emprestada. As condies de emprstimo sero checadas no momento do emprstimo. vii) Funcionalidades disponveis aos administradores 1. Estatsticas bsicas do movimento de emprstimos: obras mais solicitadas, obras extraviadas, obras em restaurao, total de emprstimos (dirio, semanal, mensal e anual). 2. Estatsticas de atrasos e multas: tempo mdio de atraso nas devolues, listagem dos usurios atrasados. 3. Listagens de controle: listagem do cadastro de usurios, listagem do cadastro de obras. 4. Observao: as funcionalidades de administrao sero acessveis em equipamento remoto (Intranet) e as listagens sero geradas na impressora matricial conectada ao equipamento central. viii) Funcionalidades disponveis ao pessoal de suporte 1. Relatrios de gerenciamento do sistema: logs de falhas ocorridas em acessos aos dados, logs de falhas de comunicao (Intranet e Internet), disponibilidade de disco rgido livre no equipamento central, disponibilidade de memria livre (mdia) no equipamento central, tempo mdio das consultas locais, tempo mdio das consultas remotas. Funes de manuteno: back-ups das bases de dados, restaurao das bases de dados. Observao: estas funcionalidades estaro disponveis apenas no equipamento central.
2. 3.
A interface grfica entre os agentes e o sistema ser baseada em telas grficas, orientadas por cones, caixas de seleo e menus do tipo Pull-Down. Dever ter a capacidade de ser visualizada em estaes Risc/Unix ou em PCs/Windows, com acessos ao equipamento central atravs da Intranet da biblioteca ou atravs da Internet.
As principais informaes do sistema devem ser organizadas na forma de um conjunto de fichrios. Cada fichrio conter informao especficas, como por exemplo: fichrio de obras catalogadas na biblioteca, fichrio de usurios registrados, fichrio de funcionrios registrados e outros que forem necessrios. 153
7 4 $ 86!532"&$110"!)(&%!#"! ' $ $C8PI2"&$HB!"&FE!!B46A D 7 $ 4 @ 7 G $ @ $ D C 4 @
95
As informaes em uma biblioteca normalmente so organizadas na forma de fichas com diversos tipos de dados, que passam a ser descritos a seguir. i) Fichas de identificao de obras Estas fichas so as fichas coladas nas contracapas traseiras das obras com a identificao da mesma. A figura B.1 ilustra o mnimo de informao que deve constar desta ficha. As obras iguais tero a mesma catalogao mas nmeros de tombo diferentes.
Obra: (nome da obra) Autor: (Autor ou autores da obra) Nmero do tombo: (numerao seqencial atribuda as Obras cadastradas) Data para devoluo: (data em que deve ser efetuada a devoluo do tombo) Catalogao bibliogrfica: (nmero de identificao nica atribudo a Obra, em funo da rea, assunto, etc.)
Figura B.1 - Defini o da ficha_tombo
ii) Fichas de controle de emprstimo So as fichas destacveis presentes na contracapa traseira das obras antes de serem emprestadas. Esta ficha utilizada como documento que comprova o emprstimo, retirada do tombo no ato do emprstimo e retornando ao mesmo aps a devoluo. Elas contm a mesma informao das fichas de identificao de obras, com o acrscimo de dois itens para anotaes, como ilustrado pela figura B.2.
Obra: (nome da obra) Autor: (Autor ou autores da obra) Nmero do tombo: (numerao seqencial atribuda as Obras cadastradas) Data para devoluo: (data em que deve ser efetuada a devoluo do tombo) Catalogao bibliogrfica: (nmero de identificao nica atribudo a Obra, em funo da rea, assunto, etc.) Cdigo identificador do emprestante: (nmero cadastral do solicitante do emprstimo) Campo para assinatura do emprestante
Figura B.2 - Defini o da ficha_emprstimo
O sistema automatizado deve oferecer uma alternativa ao uso das fichas, atravs de senhas e assinaturas digitais, mantendo a confiabilidade do sistema de fichas. O sistema deve ser implementado de modo a permitir o uso simultneo das fichas e assinatura digital, at que se tenha confiana total no novo sistema. iii) Fichas de catalogao de obras Estas fichas permitem os usurios procurar pela obra desejada, elas so nicas para cada cdigo de catalogao bibliogrfica, ou seja, uma mesma ficha pode corresponder a vrios tombos de mesma catalogao. Estas fichas contm as informaes ilustradas pela figura B.3. 154
Captulo 3 - Mtodos orientados a objetos ________________________________________________________________________________________________ Ttulo da Obra: Autor: Edio: Local da edio: Ano:
Volume: Editora: Nmero de pginas:
Figura B.3 - Descri o da ficha_ttulo
Observaes: a medida que o sistema automatizado for entrando em operao no ser mais necessrio o uso destas fichas na forma de papel, sendo possvel a sua visualizao pelo sistema e a sua impresso caso desejado. Alguns tipos especficos de obras podero ter necessidade de alguma informao adicional, podendo ser criadas fichas especiais para tal. iv) Ficha de cadastro de usurio Esta ficha contm os dados individuais de cada usurio cadastrado no sistema, tais como dados pessoais e relativos a emprstimo, como ilustrado pela figura B.4.
Nmero no cadastro: (nmero de cadastro gerado pelo sistema) Nome completo do usurio: Nome para o sistema: (nome com 8 caracteres) R.G.: Endereo: Telefone: CEP: E-mail: Cota para emprstimo: (quantidade de obras emprestadas) Cota emprestada: (quantidade de obras que podem ser emprestadas) Dvida total: (valor total que o usurio deve, relativo a devolues de emprstimos atrasadas) Tipo: (o tipo de usurio determina a quantidade de dias para o emprstimo) Senha: (senha informada pelo usurio para verificaes posteriores)
Figura B.4 - Descri o da ficha_Usu rio

i) Capacidade O sistema dever ter capacidade para na sua configurao mnima armazenar informaes de 1.000 (mil) obras e ter at 250 (duzentos e cinquenta) usurios cadastrados. Na sua configurao mxima 1.000.000 (um milho) de obras e 25.000 (vinte e cinco mil) usurios. A fase de Levantamento de Requisitos Especficos (LRE) que dever definir a faixa de capacidade para cada projeto (biblioteca) especfico. A fase de Definio da Arquitetura de Implementao (DAI) dever 155
# 4 ! ( $ # 5""%$3210)'&%"!"
levar em conta a escalabilidade do sistema, permitindo a evoluo do sistema para equipamentos de maior capacidade sem a necessidade de alteraes de software. Portanto os mdulos de software produzidos para este sistema devero ser portveis para diferentes plataformas de hardware/sistema-operacional. ii) Desempenho Desconsiderando a possibilidade de consultas simultneas em uma Intranet com baixo trfego, o tempo mdio de consultas e pesquisas no deve ultrapassar os 10 segundos. Com o crescimento da base de obras cadastradas este tempo de pesquisa tender a crescer e quando atingir os 10 segundos seria um indicativo da necessidade de evoluo da plataforma de hardware. iii) Procedimentos contra perdas de informaes O sistema dever ter procedimentos automatizados que permitam a recuperao de todas as informaes do sistema no caso de ocorrerem as seguintes falhas: perda parcial do disco rgido, perda total do disco rgido e problema de CPU. Para atingir tal nvel de confiabilidade dever ser feito pelo menos uma cpia diria (por exemplo em fita DAT) de todas os emprstimos e devolues efetuados no dia e de todos os cadastramentos feitos. Tambm dever ser feita periodicamente uma cpia de todo o cadastro e do estado dos emprstimos. Para evitar a possibilidade de perdas entre as cpias dirias, devero ser feitas cpias contnuas de todas as transaes que alterem as informaes do sistema em um dispositivo magntico (disquete ou Zip-Drive) de maneira que a qualquer momento que ocorra uma falha haja possibilidade de recuperao das operaes realizadas no dia. iv) Tratamento de erros Todos o erros ocorridos no sistema devero ser armazenados em arquivos de LOG, com identificao do mdulo causador, tipo do erro e a hora de ocorrncia com o objetivo de facilitar a identificao de problemas de software e hardware que estejam restringindo as funcionalidades do sistema. Estes arquivos tero um procedimento de back-up individualizado, sendo eliminados do disco rgido quando copiados. v) Restries gerais do sistema O sistema no se aplica a quaisquer outras necessidades de uma biblioteca que no estejam diretamente relacionadas guarda e emprstimo de obras. O acesso via Internet implicar ao usurio ter instalado em seu computador um software navegador atualizado para permitir as consultas remotas. O tempo de consulta via Internet no determinstico, pois uma srie de fatores, fora do controle da biblioteca, podem influenciar. No haver possibilidade de cadastro de usurios via Internet, o cadastramento dever ser feito pessoalmente pelo usurio na biblioteca, com a apresentao dos documentos necessrios. 156
Modelagem do sistema pelos mtodos

Neste apndice se encontram todos os modelos e/ou diagramas criados para o sistema de biblioteca (descrito no apndice B), durante o estudo de cada um dos mtodos. O objetivo deste apndice apresentar os modelos e diagramas sugeridos por cada mtodo, tentando apresentar todos os seus aspectos para melhor ilustr-los. Eventualmente, isso no ser possvel devido ao exemplo utilizado, visto que um mtodo aborda vrias dimenses de um sistema, alguma desta dimenso pode no ser aplicvel ao exemplo. importante ressaltar que nem todos os requisitos do sistema (apndice B) foram modelados, haja visto que a modelagem completa do sistema demandaria um tempo precioso e seria desnecessrio, pois o objetivo dessa modelagem facilitar o estudo e comparao dos mtodos. Neste sentido o enfoque foi dado a parte de emprstimo e reserva, que so as que oferecem mais dimenses a serem tratadas. As sees a seguir apresentam os modelos separados por mtodos da seguinte maneira:
C.2 - Modelagem em OOSE; C.3 - Modelagem em OMT; C.4 - Modelagem em OOAD; C.5 - Modelagem em OOA-OOD;
C.6 - Modelagem em Fusion. A seo C.7 descreve o dicionrio de dados para o sistema, abordando todas as classes, atributos, operaes, associaes e eventos, referentes aos modelos apresentados nas sees anteriores.

157
158
' % " " &$# !

Usurio Reservar Obra Cadastrar Usurio Reservador Cadastrar Obra Pesquisar obra Pesquisador Cadastrador Cadastrar Funcionrio Pagar dvida Emprestar Obra Devolver Obra Cobrador Funcionrio Devedor Emprestador Emprestante
Figura C.1 - Modelo use case - delimita o do sistema
Use Case: Emprestar obra O funcionrio (emprestador) solicita emprstimo de obra ao sistema. O sistema solicita ao emprestador o nmero de cadastro do emprestante, para verificar se o mesmo est apto a fazer emprstimo. Esta verificao feita observando se o emprestante j excedeu o limite mximo para emprstimo, se possui alguma dvida pendente e se est com alguma obra emprestada cuja data de devoluo j esteja vencida. Se o usurio estiver apto, o sistema solicita e o usurio fornece o cdigo cadastral da obra. Verifica se o cdigo cadastral vlido, e verificado, tambm, se existe algum tombo daquela obra disponvel, se existir, verifica se existe reserva para o tombo. Se existir reserva, observar se o reservante o mesmo usurio que o emprestante, se for, o tombo liberado, se no for, o tombo no pode ser liberado e toda verificao feita para outro tombo. Se existir solicitado ao emprestante sua senha, que verificada na ficha do usurio. Se a senha estiver correta, o sistema preenche a ficha de emprstimo e atualiza a ficha de controle do tombo, a ficha de usurio e a ficha de tombo. O emprestador libera a obra.
Use Case: Reservar obra O reservador (funcionrio ou usurio) solicita reserva ao sistema. O sistema solicita ao reservador o nmero de cadastro do usurio. verificado se o usurio est apto a fazer reserva, verificando se no possui dvida e se no est com alguma obra emprestada cuja data de devoluo j esteja vencida. Se o usurio estiver apto, o sistema solicita e o usurio faz a entrada do cdigo cadastral da obra e a data para reserva. Verifica-se se o cdigo cadastral vlido; verificado, tambm, se existe algum tombo daquela obra disponvel na data e se no existe reserva na data para o usurio (para validar a inexistncia de mais de uma reserva para o mesmo usurio na mesma data). Se existir o tombo referido acima, o usurio entra com sua senha, que verificada com a senha do cadastro do usurio. Se a senha estiver correta, a reserva efetuada, atualizando a ficha de reserva e o item de reserva.
Figura C.2 - Descri es dos use cases - curso b sico

159
Acervo_ obras
Usurio utiliza [1] Ficha_controle
pesquisa [1]
consistede [1..N]
[1]
registra [0..N] consistede [1..N] Item_reserva tem [0..1] Usurio_ cadastrado
m rete
Obra Ficha_ttulo tem [1..N]

is te -d
c o n s is te
-d e [1 ] .
-de iste ons ..N] c [0
retem [0..1]
Ficha_emprstimo
co ns
consistede [0..N] Ficha_reserva Cadastro_ titulos

se co m ic un 1] a[
Ficha_tombo atualiza [1]
e [1 ]
tem [1] atualiza [1] consulta [1]
Funcionrio
a c e s s a [1 ]
Fichrio_ usurios
c o n s is te -d e [0 .. N ]
consiste-de [0..N] Ficha_usurio
Figura C.3 - Modelo do domnio do problema
160
Solicitao de emprstimo 1. Entre com o nmero de cadastro: 2. Entre com o cdigo cadastral: 3. Entre com a senha: Emprstimo efetuado !!!
Help
OK
Cancel
Quando o usurio solicitar emprstimo, a tela So licitao de emprstimo aparecer, solicitando o nmero do cadastro do usurio. Ento, sero feitas verificaes internas referente ao usurio. Se durante estas verificaes for encontrado algum problema para o emprstimo, uma mensagem de erro ser mostrada; se no, ser solicitado o cdigo cadastral da obra que se deseja fazer o emprstimo. Ento, verificaes internas referente a obra desejada sero feitas. Se estas verificaes no tiverem sucesso, uma mensagem de erro ser mostrada; se no, a senha do usurio ser solicitada. Ento, a senha ser verificada. Se a senha estiver incorreta, aparecer uma mensagem de erro; se no, a tela Emprstimo efetuado ser apresentada. O b o t o Help (ajuda) serve para explicar tudo que estiver na tela: dados, botes, processamento. O boto OK serve i) para iniciar processamentos internos de verificaes referentes aos dados informados pelo usurio e deve ser clicado aps o dado solicitado ter sido informado; ou ii) para finalizar o emprstimo. O boto Cancel (cancela) serva para cancelar o emprstimo.
Figura C.4 - Modelo de interface
161
Fichrio_ usurios Ficha_ usurio Ficha_ emprstimo
Verificador de obra Cadastro_ ttulos
Tela de emprstimo
Verificador de tombo disponvel
Ficha_ ttulo
tem_ reserva
Verificador de senha
Ficha_ usurio
Ficha_ controle
Ficha_ reservas
Ficha_ emprstimo Concluidor do emprstimo
Ficha_ tombo
Figura C.5 - Modelo de an lise - use case: emprestar obra
162
Fichrio_ usurios Ficha_ usurio
Verificador de obra Tela de reserva Cadastro_ ttulos Ficha_ emprstimo
Verificador de reservas na data
Ficha_ tombo
Ficha_ controle Verificador de senha Ficha_ usurio Item_reserva Ficha_ reserva Concluidor da reserva
Ficha_ ttulo
Figura C.6 - Modelo de an lise - use case: reservar obra
163
Objeto de interface: Tela de reserva 1o. Pede-se o cdigo do usurio e aciona o objeto verificador de usurio apto. Se no estiver apto: mensagem de erro. 2o. Pede-se o cdigo cadastral da obra e aciona o objeto verificador de tombo. Se no existir: mensagem de erro. 3o. Pede-se a data para reserva e aciona o objeto verificador de reservas na data. Se no existir espao para mais reservas: mensagem de erro. 4o. Pede-se a senha do usurio e aciona o objeto verificador de senha. Se senha no estiver correta: mensagem de erro. 5o. Aciona o objeto concluidor da reserva. -----------------------------------------------------Objeto de controle: Verificador de usurio apto 1o. Localiza-se o cdigo do usurio no objeto fichrio_usurios. Se no localizado: mensagem de erro. 2o. Verifica a dvida_total e cota_emprstimos do objeto ficha_usurio. Se possui dvidas ou cota_emprestada ultrapassou cota_emprstimo: mensagem de erro. 3o. Verifica dt_devoluo do objeto ficha_emprstimo. Se possui emprstimo vencido: mensagem de erro. -----------------------------------------------------Objeto de controle: Concluidor de emprstimo 1o. 2o. 3o. 4o. Adiciona 1 a cota_emprestada no objeto ficha_usurio. Altera o status_obra no objeto ficha_controle. Altera objeto ficha_emprstimo. Altera dt_devoluo no objeto ficha_tombo.
Figura C.7 - Descri es do papel e das responsabilidades dos objetos
164
Acervo_obras qttd_obras[1] consistede [1..N] numrico
qtdd_ttulos [1]
Obra
n ra [1 ] ome_ob
string
au to r [1 ]
string tem [1..N]
consistede [0..N]
numrico Cadastro_titulos
ca cod_
dastr
] al [1
string
consistede [1]
no me _o br a [1]
a u to r [1 ]
string
Ficha_titulo
qtdd
_tom
bos[
1]
string
n r_ to m
b o [1 ]
numrico string
dt _d ev ol u
Ficha_tombo
o [1 ]
data
Figura C.8 - Representa o dos atributos dos objetos entidade
165
Fichrio_ usurios
Ficha_ usurio Ficha_ emprstimo Verificador de obra
Cadastro_ ttulos
Tela de emprstimo
Verificador de tombo disponvel
Ficha_ ttulo
Item_ reserva
Verificador de senha
Ficha_ usurio Ficha_ controle
Ficha_ reservas
Ficha_ emprstimo Concluidor do emprstimo Ficha_ tombo
Figura C.9 - Modelo de projeto - use case: emprestar obra
166
Tela Ficha_ Ficha_ Ficha_ Fichrio_ Ficha_ emprest. tombo ttulo reservas usuarios emprstimo Verif. Cadastro_ Ficha_ tem_ Ficha_ usurio Fronteira ttulos controle reserva usurio apto
Solicita emprstimo de obra Solicita e informa nmero de cadastro Verifica se usurio est apto a fazer emprstimo
loc_usu(nr_cadastro) verif_lim_empr verif_divida verif_dt_dev ok Verif. obra loc_ficha(cod_cadastral)
Se usurio apto Solicita e informa cdigo cadastral da obra Se obra disponvel
ok Verif. obra disp.
Verifica se obra disponvel para emprstimo
obter_qtdd_tombos obter_status_tombo loc_res(cod_cadastral) verif_tombo_res(nr_tombo) ok verif_cod_reserv(nr_cadastro)
Se tombo disponvel Solicita e informa senha do usurio Se senha OK

Verif. senha verif_senha_usu(senha) ok Concluidor emprst.
Preenche ficha de emprstimo Atualiza ficha de contr. Atualiza ficha de usuar. Atualiza ficha de tombo Libera obra
ok ok
preenche(nr, dt, cod) atu_status('E') soma_cota(1) atu_dt(data)
Figura C.10 - Diagrama de intera o - use case: emprestar obra (curso b sico)

167
Tela reserva Fronteira
Fichrio_ Ficha_ Cadastro_ Ficha_ Item_ usurio emprstimo ttulos controle reserva Verif. Ficha_ Ficha_ Ficha_ Ficha_ usurio usurio ttulo tombo reservas apto
Solicita reserva de obra Solicita e informa nmero de cadastro

Verifica se usurio est apto a fazer reserva Se usurio apto Solicita e informa cd. cadastral da obra e data da reserva Verifica existncia da obra
ok
verif_ divida verif_dt_dev
Verif. tombo loc_ficha(cod_cadastral) ok Verif. reservas na data
Verifica se tombo disponvel e sem nenhuma reserva na data para o reservante
obter_qtdd_tombos obter_nr_tombo obter_status_tombo verif_dt_dev obter_qtdd_reserva obter_res(data) verif_cod_reserv(nr_cadastro)
Se tombo disponvel Solicita e informa senha do usurio Se senha OK
ok
Verif. senha verif_senha_usu(senha) ok Concluidor emprst.
Atualiza ficha de reserva Atualiza item de reserva

ok
atu_qtdd(vlr) preenche(dti, dtf, cod) ok
Reserva efetuada
Figura C.11 - Diagrama de intera o - use case: reservar obra (curso b sico)

168
Tela Ficha_ Ficha_ Ficha_ Fichrio_ Ficha_ emprest. tombo ttulo reservas usuarios emprstimo Verif. Cadastro_ Ficha_ tem_ Ficha_ usurio Fronteira ttulos controle reserva usurio apto Solicita emprstimo de obra Solicita e informa nmero de cadastro Verifica existncia de usurio Verifica limite de emprstimo Verifica existncia de dvida Verifica emprstimo c/ data vencida Algum controle acima invlido, cancelar. Se usurio apto Solicita e informa cdigo cadastral da obra Verifica existncia de ttulo Ttulo inexistente, cancelar. Se obra existente er ok Verif. obra disp. Obter qtdd_tombos Faa enqto tombo no disponvel ou no existir mais tombos p/ cod_cadastral Se tombo disponvel na data Localiza reservas Se tombo reservado na data Se reservante = emprestante tombo disponvel seno, tombo disponvel Fim faa Se tombo disponvel Solicita e informa senha do usurio Verifica se senha est correta Senha incorreta, cancelar Se senha correta Verif. senha verif_senha_usu(senha) er ok Concluidor emprst. Preenche ficha de emprstimo Atualiza ficha de controle Atualiza ficha de usurio Atualiza ficha de tombo Libera obra ok ok preenche(nr, dt, cod) atu_status('E') soma_cota(1) atu_dt (data) ok ok er obter_qtdd_tombos er ok Verif. obra loc_ficha(cod_cadastral) loc_usu(nr_cadastro) verif_lim_empr verif_divida verif_dt_dev
obter_status_tombo loc_res(cod_cadastral) verif_tombo_res(nr_tombo) verif_cod_reserv(nr_cadastro)
Figura C.12 - Diagrama de intera o - use case: emprestar obra (curso alternativo)
169

Tela reserva Fronteira Solicita reserva de obra Solicita e informa nr_cadastro Verifica existncia do usurio Verifica existncia de dvida Verifica emprstimo c/ data vencida Algum controle acima invlido, cancelar. Se usurio apto Solicita e informa cd. cadastral Verifica existncia de ttulo Ttulo inexistente, cancelar Se obra existente Solicita e informa data da reserva Obter qtdd_tombos / tv = 1 Faa enqto tiver nr_tombo p/ obra Obter prximo nr_tombo Se status_tombo = 'E' Se dt_devoluo > = dt_reserva qes = qes + 1 tv = tv + 1 Fim faa Se tv = qtdd_tombos Obtem qtdd_reservas / qr = 0 Faa enqto existir reserva p/ obra Obter reserva na data Se cod_reservante <> nr_cadastro qr = qr + 1 seno reservante j possui reserva, cancelar Fim faa Se qt <> (qr + qes) Solicita e informa senha do usurio Verifica se senha est correta Senha incorreta, cancelar Se senha correta Concluidor emprst. Atualiza ficha de reserva Atualiza item de reserva ok Reserva efetuada ok atu_qtdd(vlr) preenche(dti, dtf, cod) Verif. senha verif_senha_usu(senha) er ok er ok obter_res(data) verif_cod_reserv(nr_cadastro) obter_qtdd_reserva obter_nr_tombo obter_status_tombo verif_dt_dev er ok Verif. reservas na data obter_qtdd_tombos er ok Verif. obra loc_ficha(cod_cadastral) loc_usu(nr_cadastro) verif_ divida verif_dt_dev Fichrio_ Ficha_ Cadastro_ Ficha_ Item_ usurio emprstimo ttulos controle reserva Verif. Ficha_ Ficha_ Ficha_ Ficha_ usurio usurio ttulo tombo reservas apto
Figura C.13 - Diagrama de intera o - use case: reservar obra (curso alternativo)
170
Obra
Criar
Disponvel
Enviar restaurar
Func. perde obra
Solicita emprest.
Solicita uso
Restaurao
Livro restaurado
usurio apto e tombo disponvel
__
Perde obra
S Emprestado
Emprest. perde obra
Disponvel
Devolve emprest.
Extraviado
Disponvel
Encontrar obra
Func. encontra obra
Emprest. encontra obra
Destroi ficha
Restaurao
Disponvel
Emprestado
Figura C.14 - Grafo de transi o de estado - objeto ficha_controle
171
acessa ficha_ttulos
verifica qtd. de tombos (qt)
NO FAZER RESERVA
tombos verificados = 1 (tv) FAZER RESERVA

N
qtd. emprestimo a somar = 0 (qes)
tv > qt
N
S S
qt = qd
obter prximo nr_tombo
qd = qr + qes
N S
verifica ficha_controle
tem reserva tv = tv + 1 tombo emprestado

S N
qr = qr + 1
N
obter emprestado_para
S
acessa ficha_usurio
cod_reservante = nr_cadastro
verifica dt_devoluo obter reserva na data dt_devoluo >= dt-reserva

S N
qtdd. reserva = 0 (qr)
qes = qes + 1
qt = tv
acessa ficha_reservas
Figura C.15 - Fluxograma da reserva
172
OOSE
Anlise
Construo
Teste
Modelo de requisitos
Modelo de anlise Modelo de projeto Modelo de implement. Teste de unidade Grafos de transio de estado
Modelo de teste
Teste do sistema
Teste de integrao Descr. use case Descr. interface Identificao de subsistemas
Mod. use case
Mod. domnio do problema Modelo para cada use case
Descrio das responsabilidades dos objetos
Figura C.16 - Resumo gr fico dos modelos/diagramas gerados pelo OOSE
173
cod_cadastral
1+ Ficha_controle nr_tombo cod_emprestante status_tombo qtdd_reservas
ope rador
cadastra
est registrado
Ficha_usurio Ficha_reservas nome_usu endereo_usu cota_emprstimo cota_emprestada dvida_total senha_usu tipo_usu
est anotado
{cota_emprestada < = cota_emprstimo}
Ficha_emprstimo nr_tombo dt_devoluo cod_emprestante
retem
Figura C.17 - Diagrama de classes - an lise
174
nr_cadastro
'%$!"! & #
utiliza
Acervo_obras qtdd_obras Cadastro_ttulos qtdd_ttulos nome_usu
pesquisa
Usurio
1+ Obra nome_obra autor 1+
tem
c o n s u l t a
a t u a l i z a
tipo de usurio
Ficha_ttulo nome_obra autor qtdd_tombos Ficha_tombo nr_tombo dt_devoluo
tem
Usurio_ cadastrado se comunica nr_cadastro com endereo_usu Fichrio_usurios emprestante reservador
Funcionrio
t e m
qtdd_usu_cadastr. qtdd_professores qtdd_alunos
atualiza
acessa
(Obra) Engenharia de Software Pressman
tem
tem
(Obra) Engenharia de Software Pressman
(Ficha_ttulo) 1569 Engenharia de Software Pressman 2 (Ficha_tombo) 15691 (Ficha_controle) 15691 D (Ficha_controle) 15692 Joo E (Ficha_tombo) 15692 16/03/1998
tem
tem
Figura C.18 - Diagrama de instncias
Figura C.19 - Diagrama de interface
175
Classes - ACERVO_OBRAS: possui informaes totalizadoras das OBRAS. - CADASTRO_TTULOS: contm informaes totalizadoras sobre FICHA_TTULO. - FICHA_CONTROLE: cada tombo possui a sua. Armazena o status de cada tombo (D - Disponvel, E Emprestado, R - Restaurao) e cdigo do emprestante. - FICHA_EMPRSTIMO: armazena informaes sobre emprstimo de um determinado usurio. Esta ficha ou estar junto a OBRA ou junto a FICHA_USURIO, quando o tombo estiver emprestado. - FICHA_RESERVAS: possui informaes totalizadoras de reservas e vrios ITEM_RESERVA por obra. - FICHA_TTULO: armazena informaes sobre os ttulos das obras, possui vrias FICHA_CONTROLE e vrias FICHA_RESERVAS e se relaciona com FICHA_TOMBO. Poder existir mais de uma OBRA para cada FICHA_TTULO. - FICHA_TOMBO: fixado a cada tombo, possui data de devoluo. Funcionrio atualiza esta ficha quando o emprstimo efetuado. - FICHA_USURIO: contm informaes sobre o usurio, tais como: dvida, cota mxima para emprstimo, cota emprestada, senha e tipo de usurio (P - Professor, A - Aluno). Possui vrias FICHA_EMPRSTIMO, quando o usurio possuir algum emprstimo. S permitido o emprstimo se a cota emprestada for menor ou igual a cota de emprstimo. - FICHRIO_USURIOS: contm informaes totalizadoras sobre FICHA_USURIO, tais como quantidade de usurio, quantidade de professores e quantidade de alunos. - FUNCIONRIO: armazena informaes gerais dos funcionrios (operadores, administradores e pessoal de suporte). Os funcionrios atualizam os dados, gerenciam o sistema e controlam problemas de mal funcionamento. - ITEM_RESERVA: armazena informaes sobre as reservas, como: data inicial, data final e cdigo do reservante. - OBRA: armazena dados gerais sobre as obras. Cada OBRA contm uma FICHA_TOMBO, que fica colada a ela, tem associadas a ela, uma FICHA_CONTROLE e uma FICHA_TTULO. Tambm possui uma FICHA_EMPRSTIMO, quando a obra no est emprestada. a obra fsica, o tombo. - USURIO: possui informaes sobre usurios, que no esto cadastrados. So usurios que simplesmente utilizam ou fazem pesquisa ao ACERVO. - USURIO_CADASTRADO: possui informaes sobre usurios cadastrados no sistema e que podem reservar, emprestar, devolver. Cada usurio cadastrado tem uma FICHA_USURIO. Ele pode estar anotado como emprestante em FICHA_CONTROLE ou como reservante em ITEM_RESERVA. Atributos autor: nome do autor da obra. cod_cadastral: cdigo cadastral da obra. Obras com o mesmo ttulo, possuem o mesmo cod_cadastral. dt_devoluo: data da devoluo da obra. nome_usu: nome do usurio. nr_cadastro: nmero do cadastro do usurio. nr_tombo: nmero do tombo. Obras com o mesmo ttulo, possuem nr_tombo diferentes. qtdd_obras: quantidade de obras no acervo. senha_usu: senha do usurio. Operaes obter_status_tombo( ): verifica o status do tombo e o retorna. verif_cod_reserv(nr_cadastro): com o nr_cadastro do usurio verificado se ele igual ao cod_reservante para saber se o reservante j possui alguma reserva. loc_usu(nr_cadastro): localiza o usurio no fichrio do usurios atravs do nr_cadastro para saber se ele est cadastrado como usurio cadastrado. Associaes est anotado: um usurio pode estar anotado em um item de reserva, quando o usurio faz uma reserva. pesquisa: um usurio pode fazer uma pesquisa no cadastro de ttulos. utiliza: um usurio pode utilizar o acervo de obras. atualiza: o funcionrio atualiza a ficha de tombo, quando um emprstimo efetuado.
Figura C.20 - Dicion rio de dados
176
Funcionrio solicita cadastro. SB solicita escolha do cadastro; funcionrio escolhe o cadastro. SB solicita dados para cadastro; funcionrio / usurio informa dados para cadastro. SB solicita senha do funcionrio / usurio; funcionrio / usurio informa senha. SB registra o cadastro. Funcionrio solicita relatrios. SB solicita a escolha do relatrio; funcionrio escolhe o relatrio. SB solicita datas inicial e final; funcionrio informa datas. SB emite o relatrio. Funcionrio solicita emprstimo. SB solicita nr_cadastro; usurio_cadastrado informa nr_cadastro. SB solicita cod_cadastral da obra; o usurio_cadastrado informa cod_cadastral da obra. SB solicita senha do usurio; usurio_cadastrado informa senha. SB libera obra.
Usurio_cadastrado / Funcionrio solicita reserva. SB solicita data para reserva; o usurio_cadastrado informa data para reserva. SB informa que reserva foi efetuada.
Figura C.21 - Cen rio normal do sistema de biblioteca
Funcionrio solicita cadastro. SB solicita escolha do cadastro; funcionrio escolhe o cadastro. SB solicita dados para cadastro; funcionrio / usurio informa dados para cadastro. SB solicita senha do funcionrio / usurio; funcionrio / usurio informa senha. senha invlida. SB registra o cadastro. Funcionrio solicita relatrios. SB solicita a escolha do relatrio; funcionrio escolhe o relatrio. SB solicita datas inicial e final; funcionrio informa datas. Data invlida. SB emite o relatrio. Funcionrio solicita emprstimo. SB solicita nr_cadastro; usurio_cadastrado informa nr_cadastro. nr_cadastro invlido. usurio no est permitido a fazer emprstimo. SB solicita cod_cadastral da obra; o usurio_cadastrado informa cod_cadastral da obra. cod_cadastral invlido. tombo no disponvel. SB solicita senha do usurio; usurio_cadastrado informa senha. senha invlida. SB libera obra. Usurio_cadastrado / Funcionrio solicita reserva. SB solicita data para reserva; o usurio_cadastrado informa data para reserva. tombo no disponvel na data. reservante j possui reserva. SB informa que reserva foi efetuada.
Figura C.22 - Cen rio especial do sistema de biblioteca
177
Usurio_ cadastrado
Sistema Biblioteca
solicita cadastro
Funcionrio
solicita escolha do cadastro informa escolha do cadastro solicita dados para o cadastro informa dados informa dados solicita senha do funcionrio informa senha do funcionrio senha invlida registra cadastro solicita relatrios solicita escolha do relatrio informa escolha do relatrio solicita datas inicial e final informa datas inicial e final data invlida emite relatrio solicita emprstimo solicita nr_cadastro informa nr_cadastro nr_cadastro invlido usurio no est permitido a fazer emprstimo solicita cod_cadastral informa cod_cadastral cod_cadastral invlido tombo no disponvel solicita senha do usurio informa senha do usurio senha invlida libera obra solicita reserva solicita reserva solicita data para reserva informa data para reserva tombo no disponvel na data reservante j possui reserva informa reserva efetuada
Figura C.23 - Diagrama de eventos para o cen rio do sistema de biblioteca
178
Usurio_ cadastrado
solicita nr_cadastro nr_cadastro invlido usurio no est permitido a fazer emprstimo solicita cod_cadastral cod_cadastral invlido tombo no disponvel solicita senha do usurio senha invlida libera obra solicita data para reserva tombo no disponvel na data reservante j possui reserva informa reserva efetuada
informa informa informa informa solicita informa
dados nr_cadastro cod_cadastral senha do usurio reserva data para reserva
Sistema Biblioteca
solicita escolha do cadastro solicita dados para o cadastro solicita senha do funcionrio senha invlida registra cadastro solicita escolha do relatrio solicita datas inicial e final data invlida emite relatrio solicita cadastro informa escolha do cadastro informa dados informa senha do funcionrio solicita relatrios informa escolha do relatrio informa datas inicial e final solicita emprstimo solicita reserva
Funcionrio
Figura C.24 - Diagrama de fluxo de eventos do sistema de biblioteca
179
solicita_uso (nr_tombo)
solicita_emprstimo (nr_tombo, nr_cadastro, senha_usu) [usurio_apto e tombo_disponvel] / cota_emprestada + 1
cria_ficha (nr_tombo,' ',d)
Disponvel entrada / atu_status('D')
devolve_emprestimo(nr_tombo) / cota_emprestada + 1
Emprestado entrada / atu_status('E')
obra_ restaurada enviar_ restaurao func_encontra_obra (nr_tombo) encontra_obra (nr_tombo)
empr_perde_obra (nr_tombo) func_perde_obra (nr_tombo)
Restaurao entrada / atu_status('R')
Extraviado entrada / atu_status('X')
empr_ encontra_obra (nr_tombo)
perde_obra (nr_tombo)
destroi_ficha (nr_tombo)
Figura C.25 - Diagrama de estado - classe: obra
Funcionrio
escolha do cadastro, dados, senha, escolha do relatrio, datas inicial e final
mensagens
Sistema Biblioteca
Usurio_ cadastrado
nr_cadastro, cod_cadastral, senha, data para reserva
Figura C.26 - Diagrama de valores de entrada e sada
180
Captulo 3 - Mtodos orientados a objetos ________________________________________________________________________________________________ utiliza

Acervo_obras qtdd_obras Cadastro_ttulos qtdd_ttulos loc_ficha(cod_cadastral) nome_usu cod_cadastral
pesquisa
Usurio
1+ Obra nome_obra autor 1+
tem
Ficha_ttulo nome_obra autor qtdd_tombos
c o n s u l t a
a t u a l i z a
tipo de usurio
tem
Usurio_ cadastrado se comunica nr_cadastro com endereo_usu Fichrio_usurios
obter_qtdd_tombos( ) Ficha_tombo
emprestante
reservador
nr_tombo dt_devoluo atu_dt(data) obter_nr_tombo( )
Funcionrio
t e m
qtdd_usu_cadastr. qtdd_professores qtdd_alunos loc_usu(nr_cadastro) nr_cadastro
atualiza
acessa ope rador
cadastra
1+ Ficha_controle nr_tombo cod_emprestante status_tombo obter_status_tombo( ) atu_status(st) obter_nr_tombo( )
est registrado
Ficha_reservas qtdd_reservas loc_res(cod_cadastral) obter_qtdd_reserva( ) atu_qtdd(vlr)
Ficha_usurio nome_usu endereo_usu cota_emprstimo cota_emprestada dvida_total senha_usu tipo_usu
Item_reserva dti_reserva dtf_reserva cod_reservante verif_cod_reserv(nr_cadastro) obter_res(data) preenche(dti, dtf, cod) verif_tombo_res(nr_tombo)
est anotado
soma_cota(qtdd) verif_lim_empr( ) verif_dvida( ) verif_senha_usu(senha)
{cota_emprestada < = cota_emprstimo}

Ficha_emprstimo nr_tombo dt_devoluo cod_emprestante verif_dt_dev( ) preenche(nr, dt, cod)
retm
Figura C.27 - Diagrama de classes - projeto
181
OMT
Anlise
Projeto
Implementao
Modelo de Objetos
Modelo Dinmico
Modelo Funcional
complementa 1+ Dicionrios de Dados Diagrama de Objetos Diagrama de valores de entrada e sada Descrio de Funes
Diagrama Fuxo de Dados Diagrama de Classes 1+ Diagrama de Instncias
1+ Cenrios Formatos de Interface Diagrama de Eventos Diagrama Fluxo de Eventos
1+ Diagrama de Estados
texto modela
grfico
Figura C.28 - Resumo gr fico dos modelos/diagramas gerados pelo OMT - an lise

182
OMT
Anlise
Projeto
Implementao
Projeto de sistemas
Projeto de Objetos
Subdivir o Sistema em Subsistemas Identificar as Concorrncias Alocar Subsistemas a Processadores Gerenciar o Depsito de Dados Manipular Recursos Globais Escolher a Implementao de Controle do Software Manipular as Condies Extremas Estrutura Arquitetnica
Obter Operaes Projetar Algoritmos para Implementar Operaes Otimizar Caminhos de Acesso Implementar Controle para Interaes Externas Ajustar a Estrutura de Classe para Aumentar Herana Projetar Associaes Determinar a representao de objetos Empacotar Classes e Associaes em Mdulos
Figura C.29 - Resumo gr fico dos modelos/diagramas gerados pelo OMT - projeto
( & # # ''%$!"!
183
utiliza Acervo_obras qtdd_obras Cadastro-ttulos qtdd_ttulos loc_ficha (cod_ cadastral) 1..N [ cod_cadastral ] Obra nome_obra autor 0..N 1..N tem Ficha-ttulo nome_obra autor qttd_tombos obter_qtdd_tombos ( ) c o n s u l t a a t u a l i z a pesquisa Usurio nome_usu
1..N
comunica com 0..1 Emprestante
Usurio-cadastrado nr_cadastro endereco_usu
[ nr_tombo ] Ficha-tombo | | dt_devolucao atu_dt (data) obter_nr_tombo ( )
Funcionrio nome_fun endereco_fun senha_fun atualiza 0..N
ac
Reservador
es
sa
0..N Fichrio-usuarios qtdd_usu_cadast. qtdd_professores qtdd_alunos loc_usu (nr_cadastro)
tem
[ nr_tombo ] 1..N
est registrado
Ficha-controle cod_emprestante status_tombo 0..N atu_status (st ) { status_tombo = 'E ' e cod_emprestante <> nulo}
[ nr cadastro ] 0..N
Ficha-reserva qtdd_reservas atu_qtdd (vlr ) loc_res (cod_cadastral) obter_qtdd_reserva ( ) est anotado
0..N Item-reserva dti_reserva dtf_reserva cod_reservante obter_res (data ) verif_res (data ) verif_tombo_res (nr) verif_cod_reserv (nr) retm { cod_emprestante = nulo } 0..1 0..N
Ficha-usurio nome_usu | | cota_emprestimo cota_emprestada divida_total | | senha_usu tipo_usu verif_divida ( ) verif_lim_empr ( ) verif_senha_usu (senha ) soma_cota (qtdd ) { cota_emprestada < = cota_emprstimo }
Ficha-emprstimo nr_tombo dt_devolucao cod_emprestante verif_dt_dev ( ) preenche (nr, dt, cod )
{ cod_emprestante <> nulo } 0..N
Figura C.30 - Diagrama de classes
184
te m
cad ast ra
solicita_uso / atu_status('D') solicita_emprstimo / cota_emprestada + 1 e atu_status('E')
cria_ficha / atu_status('D')
Disponvel
devolve_emprestimo / cota_emprestada + 1 e atu_status('D') empr_perde_obra / atu_status('X')
Emprestado
obra_ restaurada / atu_status('D')
enviar_ restaurao / atu_status('R') func_encontra_obra / atu_status('D') encontra_obra / atu_status('R')
func_perde_obra / atu_status('X')
Restaurao
empr_ encontra_obra / atu_status('E') Extraviado
perde_obra / atu_status('X') destroi_ficha
Figura C.31 - Diagrama de transi o de estado de obra
185
Applet de emprstimo
e r v i 41: s o_ok
2: so (nr licita , co _s e d, sen rvio ha)
Codificadorsocket
L
pon 1 : d is
ib il iz a
_s
e r v i o
Decodificadorsocket
L
40:
, , cod 3: (nr
senha
mp_ 39: e
L
ok
4: ve r if _ (nr, s usu enha )
29: nr_tombo
Concluidoremprstimo
r_emp e fe tu a li c it a _ o d , s t = E ) 30: so , nr, c bo n r _ to m
15: ve r if _ u
su_ok
Verificadorusurio
Verificadorobra
Figura C.32 - Diagrama de objetos
186
32:
he_o preenc
k
dt, cod )
Concluidoremprstimo
[cod_cadastral]
pr ch een r_ e (n t
o, omb
ok
34
tus
Fichaemprstimo
:s
('
ta
31:
s_
tu
')
30: solicita_efetuar_emp (nr_tombo, nr, cod, st = E )
39: emp_ok
38 :a
sta
tu
37
tu_
_o
35: soma_cota (1)
:a
:a
36: soma_ok
tu _d
33
t( da ta )
[nr_tombo]
Fichacontrole
Fichatombo Fichausurio
Figura C.33 - Diagrama de objetos - cont.
187
29: nr_tombo
27:
k cod_o
Verificadorobra
26: nr_
veri
25:
f_co
veri
d_re
18:
f_to
serv
mbo
(nr)
_res
(nr)
[cod_cadastral]
f loc_ 17:
Cadastrottulos
icha
(cod
td
)
s( )
tom
bo
28:
cod
_ok
20
tom
Itemreserva
:q
bo
22
d_
21
:s
qtd
:o
ta
23: loc_res (cod)
bt
r_
tu
er
24: loc_ok
bte
_s ta
:o
tu
19
s_ to m bo ()
[nr_tombo]
Fichattulo
Fichacontrole Fichareserva
188
4: verif_usu (nr, senha)
Verificadorusurio
t_ f_d de v
15: verif_usu_ok
6:
usu
11
e :v
ri
_ok
5:
8: lim_ok
loc
[nr_cadastro]
Fichausurio
14: senha_ok
189
9: verif_divida
13: verif_senha_usu (senha)
10: divida_ok
Fichaemprstimo
12
:d
t_d
ev
7: verif_lim_empr
k _o
_us
u( nr)
Fichriousurios
: Verificador_: Concluidor_ usurio emprstimo
: Ficha_ ttulo
: Ficha_ reservas
: Fichrio_ : Ficha_ usuarios emprstimo : Item_ reserva : Ficha_ usurio : Ficha_ tombo
: Verificador_ : Cadastro_ obra ttulos loc_usu(nr_cadastro)
: Ficha_ controle
Verifica se usurio est apto a fazer emprstimo Se usurio apto
verif_lim_empr verif_divida verif_dt_dev loc_ficha(cod_cadastral)
Verifica se existe obra Se obra existente

obter_qtdd_tombos
Verifica se tombo disponvel para emprstimo
obter_status_tombo loc_res(cod_cadastral) verif_tombo_res(nr_tombo) verif_cod_reserv(nr_cadastro) verif_senha_usu(senha)
Se tombo disponvel Verifica senha do usurio Se senha OK Preenche ficha de emprstimo Atualiza ficha de controle Atualiza ficha de usuario Atualiza ficha de tombo
preenche(nr, dt, cod) atu_status('E') soma_cota(1) atu_dt(data)
Figura C.36 - Diagrama de intera o
190
Subsistemas
Biblioteca.cpp Cadastro Reserva
Relatrios
Emprstimo
Pagamento
Pesquisa
Devoluo
Figura C.37 - Diagrama de mdulo - alto nvel
Subsistema - Emprstimo
Ficha_ usu.h Fichario_ usu.h Ficha_ emp.h Ficha_ tom.h Ficha_ res.h Item_ res.h Ficha_ con.h Ficha_ tit.h Cadastro_ tt.h
emprestimo.cpp
Ficha_ usu.cpp
Fichario_ usu.cpp
Ficha_ emp.cpp
Ficha_ tom.cpp
Ficha_ res.cpp
Item_ res.cpp
Ficha_ con.cpp
Ficha_ tit.cpp
Cadastro_ tt.cpp
Figura C.38 - Diagrama de mdulo - baixo nvel
191
Terminais para usurios externos
Terminal cliente PC
web-browser applets dos casos
Terminal cliente Risc

Terminal cliente Mac

Acesso via internet
Terminais cliente (para funcionrios)
Servidor central(Risc)
OODBMS Sub. Conexes Sub. casos servidor applets
Impressora
Acesso via intranet
Terminal cliente PC (para usurios)
Terminal cliente PC
Terminal cliente Risc (para professores)
Terminais da biblioteca e departamentos

Figura C.39 - Diagrama de processo
192
OOAD
Conceitualizao
IdCO IdSCO IdRCO ImCO
Projeto
Anlise
Evoluo
Manuteno
Legenda
Ident. de classes e objetos Ident. da semntica Ident. dos relacionamentos Implem. de classes e objetos
Figura C.40 - Resumo gr fico dos modelos/diagramas gerados pelo OOAD
2%#0)'%$!"! 1 # ( & # #
193
Acervo_obras qtdd_obras
0,1
utiliza Cadastro_ttulos pesquisa qtdd_ttulos comunica com
Usurio nome_usu
loc_ficha (cod_ cadastral) Obra 0,1 1 nome_obra autor 1,m Ficha_ttulo cod_cadastral nome_obra autor qtdd_tombos Ficha_tombo nr_tombo dt_devoluo atu_dt (nr_tombo) obter_nr_tombo ( ) c o n s u l t a a t u a l i z a 1 tem
Usurio_ cadastrado comunica com nr_cadastro endereo_usu
0,m 0,m atualiza Funcionrio nome_fun endereo_fun senha_fun
1 Fichrio_usurios qtdd_usu_cadast qtdd_professores qtdd_alunos
acessa
tem 1
Ficha_controle nr_tombo cod_emprestante status_tombo atu_status (st) cadastra Ficha_reservas qtdd_reservas atu_qtdd (vlr)
0,1 est registrado
tem Ficha_usurio nr_cadastro nome_usu cota_emprestimo cota_emprestada divida_total senha_usu tipo_usu ( ) verif_divida ( ) verif_senha_usu (senha) soma_cota (qtdd)
Item_reserva dti_reserva dtf_reserva cod_reservante obter_res (data) verif_res (data)
Ficha_ emprstimo 1 est anotado nr_tombo dt_devolucao cod_emprestante 1 verif_dt_dev ( ) preenche (nr, dt, cod)
retm
Figura C.41 - Modelo de an lise - classe&objeto, atributo e servio
194
Acervo_obras 0,1 qtdd_obras 0,m 1,m
utiliza Cadastro_ttulos
1
1
Usurio nome_usu
pesquisa qtdd_ttulos comunica com
loc_ficha (cod_ cadastral) 1 1 tem 1,m 1
0,1
Obra nome_obra autor
2 1
Ficha_ttulo c o n s u l t a a t u a l i z a Usurio_ cadastrado comunica com nr_cadastro endereo_usu
1 1 Ficha_tombo nr_tombo dt_devoluo atu_dt (data) obter_nr_tombo ( )
cod_cadastral nome_obra autor qtdd_tombos obter_ qtdd_tombos ( ) 1,m 1
1
0,m atualiza Funcionrio nome_fun endereo_fun senha_fun 0,m 1 Fichrio_ usurios acessa qtdd_usu_cadast qtdd_professores qtdd_alunos
1 Ficha_controle tem 1 nr_tombo cod_emprestante status_tombo atu_status (st) 1 Ficha_reservas qtdd_reservas atu_qtdd (vlr) loc_res (cod_cadastral) 0,m 1 Item_reserva dti_reserva dtf_reserva cod_reservante obter_res (data) preenche(dti, dtf, cod) retm 1 1 Ficha_ emprstimo 1 est anotado nr_tombo dt_devolucao cod_emprestante verif_dt_dev ( ) preenche (nr, dt, cod) cadastra 0,1 est registrado
tem 1
0,m 1 Ficha_usurio
nr_cadastro nome_usu cota_emprestimo cota_emprestada divida_total senha_usu tipo_usu verif_divida ( ) verif_senha_usu (senha) soma_cota (qtdd) verif_lim_empr ( ) 0,m
Figura C.42 - Modelo de an lise - completo
195
Estado = Disponvel
Estado = Emprestado
Estado = Extraviado
Estado = Restaurao
Figura C.43 - Diagrama de estado do objeto
196
verif_senha
Verifica se a senha informada pelo usurio igual a de sua ficha
Enquanto senha incorreta e desejar verificao
Obter senha
sim
senha = senha_usu
no
retornar mensagem senha vlida
retornar mensagem senha invlida
atu_status
Atualiza status do tombo
Enquanto situao <> E / D / X / R e desejar atualizar
Obter situao a ser atualizada
sim
situao = E / D / X / R
no
retornar mensagem atualizao executada
retornar mensagem situao no aceitvel
Figura C.44 - Diagrama de servio de duas opera es
197
especificao Ficha_controle atributo nr_tombo: nmero do tombo atributo cod_emprestante: cdigo do emprestante que deve ser um nr_cadastro em Usurio_cadastrado atributo status_tombo: define status do tombo (Emprestado / Disponvel / eXtraviado / Restaurao) Entradaexterna . Dados recebidos: status e cdigo do emprestante . Dados verificados: verifica se o cod_emprestante = nr_cadastro Sadaexterna . Controle de emprstimo: diminui / acrescenta valor a cota_emprestada DiagramadeEstadodeObjeto
Estado = Disponvel
Estado = Emprestado
Estado = Extraviado
Estado = Restaurao
Especificaes adicionais . O status_tombo refere ao estado da Obra (tombo) para o qual a ficha mantm relao. servio atu_status (sada: mensagem)
Atualiza status do tombo Enquanto situao <> E / D / X / R e desejar atualizar Obter situao a ser atualizada retornar mensagem atualizao executada retornar mensagem situao no aceitvel
sim
situao = E / D / X / R
no
Figura C.45 - Especifica o de classes
198
Janela
cabealho altura largura maximizar minimizar reduzir montar_janela 1,m 1
Boto Help
help(tela)
1,m
Janela seleo
Janela entrada
1,m 1,m
Boto Back
voltar(tela) 1,m
Boto OK
ok
Boto Cancel
cancel
Janela principal
1,m 1
Boto emprest
1
Janela Emprst Janela entrada senha
Janela reserva
Boto reserva
Figura C.46 - Modelo de projeto - C.I.H. expandido
199
Coordenador emprstimo
1,m 1,m
1,m 1 1
Verificar usurio
Verificar obra
Concluir emprstimo
Nome: Verificar usurio Descrio: Esta tarefa responsvel por fazer verificaes relativas ao usurio Prioridade: Mdia Servios includos: . Fichrio_usurios. loc_usu (nr_cadastro) . Ficha_usurio.verif_lim_empr . Ficha_usurio.verif_divida . Ficha_emprstimo.verif_dt_dev . Ficha_usurio.verif_senha_usu (senha) Coordenada por: . controlada por eventos por evento de interao Comunica via: . recebe valores de interao humana
Nome: Concluir emprstimo Descrio: Esta tarefa responsvel por concluir o emprstimo Prioridade: Alta Servios includos: . Ficha_emprstimo.preenche (nr, dt, cod) . Ficha_controle.atu_status ('E') . Ficha_usurio.soma_cota (1) . Ficha_tombo.atu_dt (nr_tombo) Coordenada por: . controlada por tempo Comunica via: . recebe valores (nr-tombo) de outra tarefa (Verifica obra)
Nome: Verificar obra Descrio: Esta tarefa responsvel por fazer verificaes relativas a obra Prioridade: Mdia Servios includos: . Cadastro_ttulos.loc_ficha (cod_cadastral) . Ficha_ttulo.obter_qtdd_tombos . Ficha_controle.obter_status_tombo . Ficha_reservas.loc_res (cod_cadastral) . Item_reserva.verif_tombo_res (nr_tombo) . Item_reserva.verif_cod_reserv (nr_cadastro) Coordenada por: . controlada por tempo Comunica via: . envia valores (nr_tombo) a outra tarefa (Concluir emprstimo)
Nome: Coordenador de emprstimo Descrio: Tarefa responsvel por controlar outras tarefas para efetuar um emprstimo Prioridade: Baixa Servios includos: . coordenar Coordenada por: . controlada por evento por evento de interao Comunica via: . recebe valores atravs da interao humana . envia valores para tarefas sub-coordenadas e para a interao humana
Figura C.47 - Modelo de projeto - C.G.T. expandido
200
1,m 1,m
Modelo de Anlise
1,m 1,m
1,m
1
Identificar Classe&objetos
1
Identificar Estruturas
1
Identificar Assuntos
1
Identificar Atributos
1
Identificar Servios
0,m
0,m
0,m
1,m 1,m
1,m
A
1 Todo-parte 1 GeneralizaoEspecializao 1 Ident. Conexo de ocorrncia
Especificao classe&objeto
1 Diagr. de Estado do Objeto
1 Ident. Conexo de Mensagens Diagr. de Servios
A - define atributos B - define servios e conexes de mensagens
Figura C.48 - Resumo gr fico dos modelos/diagramas gerados pelo OOA-OOD - an lise

201
1,m 1,m
Modelo de Projeto
1,m 1,m
1
Componente Domnio do Problema
1
Componente Interao Humana
1
Componente Gerenciador de Tarefas
1
Componente Gerenciador de Dados
Figura C.49 - Resumo gr fico dos modelos/diagramas gerados pelo OOA-OOD - projeto
Nome dados_reserva
verif_res u_solicita_ reserva
0 & $ " 1)'(%# !

Tabela C.1 Dicionrio de dados - grafo de interao, mtodos e eventos
Categoria Agente Argumentos grafo de usurio_ cod_cadastral, interao cadastrado data_reserva, senha, nr_cadastro mtodo evento data_reserva
usurio_ nr_cadastro cadastrado
Descrio O USURIO_CADASTRADO fornece dados para que a reserva seja efetuada, antes disso vrias situaes so verificadas, dentre elas: tombos que esto disponveis ou emprestados e senha do usurio. Classe: ITEM_RESERVA. Verifica se na data_reserva no possui uma reserva. USURIO_CADASTRADO faz solicitao de reserva.
Tabela C.2
202
Captulo 3 - Mtodos orientados a objetos ________________________________________________________________________________________________ Dicionrio de dados - classes, atributos, operaes e associaes
Nome
Acervo_obras Cadastro_ttulos Fichrio_usurios
Categoria Descrio
classe classe classe possui informaes totalizadoras das OBRAS. contm informaes totalizadoras sobre FICHA_TTULO. contm informaes totalizadoras sobre FICHA_USURIO, tais como quantidade de usurio, quantidade de professores e quantidade de alunos. armazena informaes gerais dos funcionrios (operadores, administradores e pessoal de suporte). Os funcionrios atualizam os dados, gerenciam o sistema e controlam problemas de mal funcionamento. possui informaes sobre usurios, que no esto cadastrados. So usurios que simplesmente utilizam ou fazem pesquisa ao ACERVO. possui informaes sobre usurios cadastrados no sistema e que podem reservar, emprestar, devolver. Cada usurio cadastrado tem uma FICHA_USURIO. Ele pode estar anotado como emprestante em FICHA_CONTROLE ou como reservante em ITEM_RESERVA. nmero do tombo. Obras com o mesmo ttulo, possuem nr_tombo diferentes. quantidade de obras no acervo. senha do usurio. verifica o status do tombo e o retorna. com o nr_cadastro do usurio verificado se ele igual ao cod_reservante para saber se o reservante j possui alguma reserva. localiza o usurio no fichrio do usurios atravs do nr_cadastro para saber se ele est cadastrado como usurio cadastrado. um usurio pode estar anotado em um item de reserva, quando o usurio faz uma reserva. um usurio pode fazer uma pesquisa no cadastro de ttulos. um usurio pode utilizar o acervo de obras. o funcionrio atualiza a ficha de tombo, quando um emprstimo efetuado.
Funcionrio
classe
Usurio Usurio_cadastrado
classe classe
nr_tombo qtdd_obras senha_usu obter_status_tombo verif_cod_reserv loc_usu est_anotado pesquisa utiliza atualiza
atributo atributo atributo operao operao operao associao associao associao associao
203
+
1
*
+
Ficha_ttulo
+
1
*
atualizao atualizao
1 1
utilizao pesquisa
consulta Fichrio_usurios
*
Usurio nome_usu
* * * * *
acessa Funcionrio nome_fun endereo_fun senha_fun 1 qtdd_usu_cadastr. qtdd_professores qtdd_alunos
* *
Ficha_usurio nr_cadastro nome_usu endereo_usu cota_emprstimo cota_emprestada dvida_total senha_usu tipo_usu
operador 1
cadastra Usurio_ cadastrado nr_cadastro endereo_usu
comunicao 1 0..1 est registrado est anotado tem retm
0..1 emprestante 1 reservador 1
Figura C.50 - Modelo de objetos
204
*
+
Ficha_ttulo
+
1
*
1 1 1 1
*
1
pesquisa utilizao atualizao atualizao consulta Fichrio_usurios
*
Usurio nome_usu
* * Funcionrio
nome_fun endereo_fun senha_fun 1
* *
acessa
qtdd_usu_cadastr. qtdd_professores qtdd_alunos
* *
Ficha_usurio
1 operador cadastra
nr_cadastro nome_usu endereo_usu cota_emprstimo cota_emprestada 1 dvida_total senha_usu tipo_usu 1
0..1 Usurio_ cadastrado nr_cadastro endereo_usu
comunicao est registrado est anotado
0..1 emprestante 1 reservador 1
tem
retm
Figura C.51 - Modelo de objeto do sistema
205
lifecicle
Sistema_biblioteca: Iniciao. (Emprstimo || Reserva || Pagamento || Devoluo || Pesquisa)*
Iniciao = solicita_cadastro. #tipo_cadastro. tipo_cadastro. (dados_func | dados_usu | dados_obra) Emprstimo = solicita_emprstimo. #solicita_dados_emp. dados_emprstimo. #obra_liberada Reserva = (f_solicita_reserva | u_solicita_reserva). #solicita_dados_res. dados_reserva. #reserva_efetuada Pagamento = . . . Devoluo = . . . Pesquisa = . . .
Figura C.52 - Modelo ciclo-de-vida (incompleto)
206
Cenrio para um emprstimo

Descrio O funcionrio (emprestador) solicita emprstimo de obra ao sistema. O sistema solicita ao emprestador o nmero de cadastro do emprestante, para verificar se o mesmo est apto a fazer emprstimo. Esta verificao feita observando se o emprestante j excedeu o limite mximo para emprstimo, se possui alguma dvida pendente e se est com alguma obra emprestada cuja data de devoluo j esteja vencida. Se o usurio estiver apto, o sistema solicita e o usurio fornece o cdigo cadastral da obra. Verifica se o cdigo cadastral vlido, e verificado, tambm, se existe algum tombo daquela obra disponvel, se existir, verifica se existe reserva para o tombo. Se existir reserva, observar se o reservante o mesmo usurio que o emprestante, se for, o tombo liberado, se no for, o tombo no pode ser liberado e toda verificao feita para outro tombo. Se existir solicitado ao emprestante sua senha, que verificada na ficha do usurio. Se a senha estiver correta, o sistema preenche a ficha de emprstimo e atualiza a ficha de controle do tombo, a ficha de usurio e a ficha de tombo. O emprestador libera a obra.
Cenrio para uma reserva

Descrio O reservador (funcionrio ou usurio) solicita reserva ao sistema. O sistema solicita ao reservador o nmero de cadastro do usurio. verificado se o usurio est apto a fazer reserva, verificando se no possui dvida e se no est com alguma obra emprestada cuja data de devoluo j esteja vencida. Se o usurio estiver apto, o sistema solicita e o usurio faz a entrada do cdigo cadastral da obra e a data para reserva. Verifica-se se o cdigo cadastral vlido; verificado, tambm, se existe algum tombo daquela obra disponvel na data e se no existe reserva na data para o usurio (para validar a inexistncia de mais de uma reserva para o mesmo usurio na mesma data). Se existir o tombo referido acima, o usurio entra com sua senha, que verificada com a senha do cadastro do usurio. Se a senha estiver correta, a reserva efetuada, atualizando a ficha de reserva e o item de reserva.
Figura C.53 - Descri o dos cen rios - emprstimo/reserva

207
Diagrama de tempo para o cenrio de emprstimo

Usurio_ cadastrado
Tempo solicita_emprstimo (nr_cadastro)
Sistema Biblioteca
Funcionrio
solicita_dados_emp dados_emprestimo obra_liberada
Diagrama de tempo para o cenrio de reserva

Usurio_ cadastrado
Tempo f_solicita_reserva (nr_cadastro)
Sistema Biblioteca
Funcionrio
u_solicita_ reserva (nr_cadastro) solicita_dados_res dados_reserva (cod_cadastral, data_reserva, senha) reserva_efetuada
Figura C.54 - Diagrama de tempo - cen rios emprstimo/reserva
208
O p e r a t i o n : solicita_emprstimo Description: Funcionrio solicita um emprstimo de obra para um usurio.
R e a d s : supplied nr_cadastro; cota_emprstimo, cota_emprestada, dvida_total, dt_devoluo Changes: S e n d s : usurio_cadastrado: {solicita_dados_emp} A s s u m e s : A cota_emprstimo deve ser maior que cota_emprestada e a d v i d a _ t o t a l deve ser igual a 0 e a dt_devoluo no deve ter sido ultrapassada, ou seja a dt_devoluo no pode ser menor que a data atual do sistema. Result: A cota_emprstimo deve ser maior ou igual a cota_emprestada.
O p e r a t i o n : dados_reserva Description: Usurio_cadastrado fornece dados para que a reserva seja efetuada.
R e a d s : supplied cod_cadastral, supplied data_reserva, supplied senha; supplied nr_cadastro; qtdd_tombos, nr_tombo, status_tombo, dt_devoluo, qtdd_reserva, dt_reserva, cod_reservante. C h a n g e s : incrementar 1 em qtdd_reservas, criao de uma nova reserva com os dados j informados pelo usurio S e n d s : usurio_cadastrado: {reserva_efetuada} Assumes : a qtdd_tombos deve ser maior que 0, ento para todos os nr_tombos obtm-se o status_tombo. Se estiver emprestado, verifica-se se a dt_devoluo for menor que a data_reserva, concluir reserva, seno procura outro tombo. Se estiver disponvel, verifica existncia de reserva. Se no existir reserva, concluir reserva, seno verifica se o nr_cadastro for diferente de cod_reservante, concluir reserva, seno reserva no pode ser feita. Antes de concluir reserva verificar se a senha_usu igual a senha. Result: Figura C.55 - Esquema das opera es solicita_emprstimo/dados_reserva
209
solicita_emprstimo (nr_cadastro) (1) loc_ficha (nr_cadastro)
f: Fichrio_ usurios
(2) verif_cota ( )
fu: Ficha_ usurio
(3) verif_dvida ( ) (4) verif_dt_dev ( )
fe: Ficha_ emprstimo
(5) solicita_dados_emp ( )
uc: Usurio_ cadastrado
Figura C.56 - Grafo de intera o de objeto - solicita_emprstimo
210
dados_reserva (cod_cadastral, data_reserva, senha, nr_cadastro) ct: Cadastro_ ttulos (1) verif_qtdd_tombos ( ) ft: Ficha_ ttulos
(2) obter_status ( ) [ tombos referentes a cod_cadastral ] (3) verif_dt_devol (data_reserva) : Bool [ status_tombo = 'E' ]
fc: Ficha_ controle
ft: Ficha_ tombo
(3' ) verif_qtdd_res ( ) : Bool [ status_tombo = 'D' ]
fr: Ficha_ reserva
(5) criar ( ) [ Bool = True ]
(3'.2) verif_reservante (nr_cadastro) : Bool [ Bool = True ]
(3'.1) verif_res (data_reserva) : Bool
new i: Item_reserva
(6) preenche_res (dti, dtf, nr) (4) verif_senha_usu (senha) : Bool [ Bool = True ]
fu: Ficha_ usurio
Figura C.57 - Grafo de intera o de objeto - dados_reserva
class Ficha_controle attribute nr_tombo : int attribute cod_emprestante : int attribute status_tombo : char method atu_status (st) endclass class Ficha_tombo attribute nr_tombo : int attribute dt_devoluo : data method atu_dt (data) method obter_nr_tombo ( ) endclass
Figura C.58 - Descri o de classes
211
Fusion Anlise
Modelo de objetos Modelo de objeto do sistema Modelo de interface Modelo ciclo-de-vida Modelo de operaes 1 + Cenrio 1 +
Projeto
Implementao
+ Esquema
referncia
+ Diagrama de tempo
atualizao
Dicionrio de Dados
Figura C.59 - Resumo gr fico dos modelos/diagramas gerados pelo Fusion - an lise

212
Fusion Anlise
+
Grafos de Interao de Objetos
Projeto
Grafos de Visibilidade
Implementao
Descries de Classes
Grafos de Herana
atualizao
Dicionrio de Dados
Figura C.60 - Resumo gr fico dos modelos/diagramas gerados pelo Fusion - projeto
Nesta seo apresentado o dicionrio de dados do sistema, que d suporte aos modelos relacionados nas ltimas cinco sees. A tabela C.3 apresenta as classes, as associaes entre as classes e a descrio de cada item mencionado. A tabela C.4 apresenta os atributos de cada uma das classes e uma breve descrio. A tabela C.5 apresenta as operaes de cada uma das classes, a classe a que pertence, os argumentos necessrios e uma descrio de cada classe. A tabela C.6 apresenta os eventos existem entre o sistema e os agentes externos, os agentes externos que criam o evento, os argumentos necessrios e a descrio dos eventos.
54321'0)($!&!$" % # ' ! ' % # !

Tabela C.3
213
Captulo 3 - Mtodos orientados a objetos ________________________________________________________________________________________________ Classes, associaes e descries gerais do sistema de biblioteca
Nome acervo_obras cadastro_ttulos ficha_controle
Categoria Classe Classe Classe
ficha_emprstimo Classe
ficha_reservas ficha_ttulo ficha_tombo ficha_usurio fichrio_usurios funcionrio
Classe Classe Classe Classe Classe Classe
item_reserva obra usurio usurio_ cadastrado
Classe Classe Classe Classe
acessa atualiza atualiza cadastra comunica com consulta est_anotado est_registrado pesquisa retm tem tem tem
Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa o Associa
Descrio possui informaes totalizadoras das obras. contm informaes totalizadoras sobre ficha de ttulo. possui informaes sobre o status do tombo e eventualmente do cdigo do emprestante. contm informaes sobre o emprstimo de um tombo. Quando a obra estiver emprestada, esta ficha se encontrar junto a ficha de usurios, caso contrrio, junto a obra fsica. armazena informaes sobre a quantidade de reservas de determinado tombo. possui informaes sobre a obra e a quantidade de tombos existente. contm informaes sobre a data para devoluo de um tombo. Esta ficha se encontra fisicamente prxima a obra. possui informaes sobre usurios. contm informaes totalizadoras sobre ficha de usurio, tais como quantidade de usurio, e de professores e quantidade de alunos. armazena informaes gerais dos funcionrios (operadores, administradores e pessoal de suporte). Os funcionrios atualizam os dados, gerenciam o sistema e controlam problemas de mal funcionamento. possui informaes sobre os itens da reserva de um determinado ttulo. contm informaes sobre as obras fsicas. possui informaes sobre usurios, que no esto cadastrados. So usurios que simplesmente utilizam ou fazem pesquisa ao ACERVO. possui informaes sobre usurios cadastrados no sistema e que podem reservar, emprestar, devolver. Cada usurio cadastrado tem uma FICHA_USURIO. Ele pode estar anotado como emprestante em FICHA_CONTROLE ou como reservante em ITEM_RESERVA. o funcionrio pode acessar o fichrio de usurios. o funcionrio atualiza a ficha de tombo, quando um emprstimo efetuado com a dt_devoluo. o funcionrio pode atualizar dados no cadastro de ttulos. o funcionrio como operador cadastra novo usurio com dados informados pelo usurio. o funcionrio e o usurio cadastrado se comunicam ao solicitar emprstimo, reserva, devoluo, fazer cobrana de ttulo, etc.. o funcionrio pode consultar o cadastro de ttulos. um usurio como reservante pode estar anotado em um item de reserva, quando o usurio faz uma reserva. um usurio como emprestante estar registrado na ficha de controle do tombo se tiver feito emprstimo deste tombo. um usurio pode fazer uma pesquisa no cadastro de ttulos. uma obra pode (obra est disponvel) ou no reter (obra est emprestada) a ficha de emprstimo. uma ficha de ttulo refere-se a uma ou mais obras. uma obra tem uma ficha de controle. o usurio cadastrado tem uma ficha de usurio, criada no ato do
214
utiliza
o Associa o
cadastramento. um usurio pode utilizar o acervo de obras, para consulta no local.
Tabela C.4 Atributos das classes e descries gerais do sistema de biblioteca
autor cod_emprestante cod_reservante cota_emprestada cota_emprstimo dvida_total dt_devoluo dtf_reserva dti_reserva endereo_fun endereo_usu nome_fun nome_obra nome_usu nr_cadastro nr_tombo qtdd_alunos qtdd_obras qtdd_professores qtdd_reservas qtdd_ttulos qtdd_usu_cadast. qttd_tombos senha_fun senha_usu status_tombo tipo_usu
Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo Atributo
nome do autor da obra. cdigo do emprestante, que deve ter um nr_cadastro equivalente em FICHA_USURIO. cdigo do reservante, que deve ter um nr_cadastro equivalente em FICHA_USURIO. cota de livros que j foram emprestados para o usurio. Esta cota no deve exceder a cota_emprstimo. cota de livros que podem ser emprestados para o usurio. divida total do usurio. Se possuir divida no possvel fazer emprstimo nem reserva. data de devoluo do tombo emprestado. data final da reserva. data de incio da reserva. endereo do funcionrio para futuros contatos. endereo do usurio para futuros contatos. nome do funcionrio no cadastro. nome da obra no cadastro. nome do usurio no cadastro. nmero do cadastro do usurio. nmero do tombo. Obras com o mesmo ttulo, possuem nr_tombo diferentes. quantidade de alunos cadastrados como usurios. quantidade de obras no acervo. quantidade de professores cadastrados como usurio. quantidade de reservas de uma determinada obra. quantidade de ttulos disponveis no acervo. quantidade de usurios cadastrados. quantidade de tombos de uma determinada obra. senha do funcionrio. senha do usurio. status do tombo - Emprestado / Disponvel / eXtraviado. Tipo do usurio - professor / aluno.
215
Tabela C.5 Operaes das classes e descries gerais do sistema de biblioteca
Nome atu_dt atu_qtdd atu_status
Categoria Classe Operao Ficha_ tombo Operao Ficha_ reserva Operao Ficha_ controle Operao Operao Cadastro_ ttulos Fichrio_ usurios Ficha_ reservas Ficha_ reservas Ficha_ ttulo Ficha_ controle Ficha_ tombo Item_reserv a Ficha_ controle Item_reserv a Ficha_ emprstimo Ficha_ usurio Item_ reserva Item_reserv a Ficha_ usurio Ficha_ usurio Ficha_ usurio Ficha_
Argumentos data
loc_ficha loc_usu
loc-res obter_ qtdd_reserva obter_ qtdd_tombos obter_ nr_tombo obter_nr_ tombo obter_res
Operao Operao Operao Operao Operao Operao
Descrio atualiza dt_devoluo com data, quando o emprstimo efetuado. vlr atualiza qtdd_reservas com +1, se houve reserva e -1 se excluiu reserva. st atualiza status do tombo, quando seu estado atual se modifica, ou seja, quando emprestado, reservado ou devolvido. cod_cadastral localiza a ficha com o cod_cadastral em ficha de ttulo para saber se existe. nr_cadastro localiza o usurio no fichrio do usurios atravs do nr_cadastro para saber se ele est cadastrado como usurio cadastrado. cod_cadastral localiza reserva em Item reserva para determinado codigo_cadastral. obtem valor contido em qtdd_reservas buscar valor qtdd_tombos armazenado no atributo
data
obtem o primeiro tombo de determinado cod_cadstral. verifica se existe reserva na data informada. verifica o status do tombo e o retorna.
obter_status_ Operao tombo preenche Operao preenche Operao
dti, dtf, cod nr, dt, cod
soma_cota
Operao
qtdd
verif_ tombo_res verif_ cod_reserv verif_ lim_empr verif_ senha_usu verif_dvida verif_dt_dev
Operao Operao
nr_tombo nr_cadastro
Operao Operao Operao Operao
senha
cria nova reserva com os dados informados, data inicial, data final e cod do reservante. atualiza ficha de emprstimo com os dados informados: nr do tombo, data de devoluo e cod. do emprestante. adiciona ou diminui a cota_emprestada a qtdd_tombos emprestada ou devolvida, respectivamente. verifica se h tombo reservado para determinado cod-cadastral. com o nr_cadastro do usurio verificado se ele igual ao cod_reservante para saber se o reservante j possui alguma reserva. verifica se possvel fazer emprstimo, ou seja, se cota_emprestada < cota_emprstimo. verifica se a senha informada igual a senha cadastrada. verifica se o usurio possui alguma dvida verifica qual a data de devoluo de
216
emprstimo verif_res Operao Item_reserv a data
determinado tombo para saber se usurio no deve algum tombo.
Tabela C.6 Eventos que afetam o sistema e descries gerais do sistema de biblioteca
Nome dados_ emprstimo dados_reserva
f_solicita_ emprstimo solicita_ emprstimo u_solicita_ reserva
Categoria Agente Argumentos Descrio Evento Usurio_ cod_cadastral Usurio cadastrado informa qual o cod cadastrado cadastral da obra que ele deseja obter emprestada. Evento Usurio_ cod_cadastral, O usurio cadastrado fornece dados para que a cadastrado data_reserva, reserva seja efetuada, antes disso vrias senha situaes so verificadas, dentre elas: tombos que esto disponveis ou emprestados e senha do usurio. Evento Funcion- nr_cadastro Funcionrio faz solicitao de reserva para rio usurio que informou seu nr_cadastro. Evento Funcion- nr_cadastro Funcionrio solicita emprstimo para usuario rio mediante nr_cadastro. Evento Usurio_ nr_cadastro Usurio cadastrado faz solicitao de reserva. cadastrado
217
Unified Modeling Language - UML

UML Unified Modeling Language uma notao e no um mtodo, que foi proposta por Grady Booch, Ivar Jacobson e James Rumbaugh com ajuda de em conjunto de metodologistas e organizaes. Esta linguagem foi adotada como padro de notao pela OMG26. Esta notao foi padronizada em setembro de 1997, quando este trabalho se encontrava em fase avanada de desenvolvimento. um assunto de extrema relevncia ao contexto deste trabalho, por ter uma estreita ligao com o mesmo, pois uma notao, especialmente esta que foi padronizada, pode ser utilizada juntamente com qualquer mtodo. Este apndice relata o propsito de uma notao, as idias que formam a UML e o processo de sua criao e padronizao.
Um mtodo composto pela notao e pelo processo, segundo (Fowler, 1997), o mais importante dos dois a notao, pois quando duas pessoas desejam discutir o projeto, no necessrio saberem o processo e sim a notao. Segundo (Quatrani, 1998), trs facetas: notao, processo e ferramenta so necessrios para que um projeto seja bem sucedido. O projeto ir falhar se: 1) souber a notao, mas no souber utilizar o processo, 2) tiver um timo processo e no conseguir comunic-lo atravs de uma notao e 3) no houver uma boa documentao (ferramenta). O processo deve ser aquele que melhor se adeqe ao desenvolvimento de um determinado sistema. Uma boa ferramenta deve ser escolhida para documentar de maneira segura, fornecendo pequenos testes e verificaes para que se possa obter um desenvolvimento mais rpido. Uma notao geralmente acompanha o processo, porque o metodologista engloba em sua notao aspectos que iro capturar / modelar o que foi definido pelo processo. Entretanto, pode-se utilizar uma notao que no a definida pelo metodologista, assim a escolha de uma notao envolve vrios aspectos como: conhecimento da mesma e seu propsito. Para um bom aproveitamento necessrio verificar qual notao melhor se adequa ao propsito - sistemas complexos / simples, sistemas grandes / pequenos -, qual notao melhor modela o problema e
26
OMG - Object Management Group um grupo com mais de 800 scios, dentre vendedores e desenvolvedores de software e usurios finais, podemos citar: American Airlines, Canon, Hewlett-Packard, Sun Microsystems e Unisys Corporation. OMG foi fundada em maio de 1989 com a misso de promover a teoria e a prtica da tecnologia de objetos para o desenvolvimento de sistemas distribudos. Maiores detalhes http:// www.omg.org.
2 B 02 64 0 ' # DC16A@9785# 231()$&%$" !

218
verificar sua compatibilidade com o processo. Depois observa-se o conhecimento da equipe de desenvolvimento em relao a notao, que muito importante para diminuio de prazos e aumento de qualidade. Existe uma tendncia em se representar os modelos de um desenvolvimento de sistemas atravs da UML, pois alm de ser uma notao bastante abrangente uma notao padro. Todos os envolvidos neste projeto de desenvolvimento analistas, projetistas, especialistas do domnio compreendero mais rapidamente o que est sendo modelado. No haver perda de tempo com a adaptao notao, desde que os elementos representados nos modelos (classes, objetos, relacionamentos, etc.) estejam de acordo com a UML. A UML uma linguagem para especificar, visualizar, construir e documentar os artefatos de um sistema de software, como tambm para modelagem de sistemas onde no haver gerao de software (Rational, 1997b). A UML tenta codificar as melhores prticas que os autores (Rumbaugh, Jacobson e Booch) e outros metodologistas encontraram em projetos orientados a objetos em todo o mundo (Booch, 1997). A UML como uma notao padro tem o propsito de unificar as notaes existentes para a modelagem orientada a objeto, especialmente as desenvolvidas por James Rumbaugh, Grady Booch e Ivar Jacobson. Esse padro facilita a comunicao entre analistas e projetistas que utilizem em seus desenvolvimentos mtodos diferentes e, provavelmente, notaes diferentes. Alm disso, facilita a compreenso dos modelos, por exemplo, os modelos da estrutura esttica de um sistema possuiro a mesma sinttica e semntica. Dentro da mesma organizao pode-se utilizar mtodos diferentes para desenvolver tipos diferentes de sistema, deste modo cada equipe de desenvolvimento teria um treinamento em uma notao. Com a adoo da UML, a locao de um membro de uma equipe ao desenvolvimento de outro projeto ou organizao que utilizem outros mtodos no acarretar em dispensar tempo e dinheiro no treinamento deste membro em outra notao, somente no processo utilizado. Muitos mtodos juntamente com suas notaes foram criados durante as dcadas de 70 a 90 (Quatrani, 1998) (Fowler, 1997). Cada um deles tentava impor-se no mercado com seu foco em determinada fase do desenvolvimento ou com uma notao mais abrangente. Alguns autores (Rational, 1997a) (Quatrani, 1998) nomeiam este perodo de method wars guerra dos mtodos. A guerra das notaes est finalizada com o advento da UML, mas a guerra dos mtodos ainda continuar, pois o uso de cada mtodo depende do tipo e das caractersticas do sistema que est sendo desenvolvido. A UML representa a unificao das notaes dos mtodos OMT James Rumbaugh, OOAD Grady Booch e OOSE Ivar Jacobson, como dito anteriormente, alm de outras boas idias de outros metodologistas como mostrado pela figura D.1. A figura D.1 apresenta os componentes da UML e seus respectivos fornecedores, alm das notaes de Rumbaugh, Booch e Jacobson, algumas tcnicas e diagramas serviram como entrada: classificao de Odell, pr e ps condies de Meyer, ciclo de vida dos objetos de Shlaer-Mellor, diagramas de estado de Harel, estruturas, padres e notas de Gamma et. al., responsabilidades de 219
Wirfs-Brock, classes singleton de Embly e descrio de operao e numerao de mensagem do mtodo Fusion.
Rumbaugh Booch Odell

Classificao
Jacobson Meyer
Shlaer-Mellor
Ciclo de vida dos objetos
UML
Pr e Ps condies
Harel
Diagramas de estado
Gamma et al.
Estruturas, padres e notas
Wirfs-Brock
Responsabilidades
Embly
Classes singleton
Fusion
Descrio de operao, numerao de mensagem
Figura D.1 - Entradas da UML (Quatrani, 1998)
O desenvolvimento da UML como mostra a figura D.2, iniciou-se quando James Rumbaugh e Grady Booch resolveram unificar suas notaes em outubro de 1994. A primeira verso 0.8, chamada de Mtodo Unificado, foi liberada ao pblico como rascunho em outubro de 1995. Como Rumbaugh e Booch adotaram os use cases de Jacobson, nada mais natural que o advento do metodologista Ivar Jacobson ao grupo. Com a chegada das idias de Jacobson e as crticas do pblico surgiram as verses 0.9 e 0.91 liberadas em junho de 1996 e outubro de 1996, respectivamente (Quatrani, 1998) (Fowler, 1997) (Booch, 1997). Enquanto a comunidade em geral continuava a realimentar o processo de criao com crticas, a Rational solicita um RFP27 Request for Proposal para tentar padronizar sua notao. A Rational, ento, estabeleceu ligaes com vrias organizaes que ajudaram na definio da verso 1.0 da UML. Dentre as organizaes, podem ser citadas: Sterling Software, Hewlett-Packard, iLogix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI e Unisys. Esta verso foi enviada a OMG como resposta inicial RFP em janeiro de 1997. Em setembro de 1997, a verso 1.1 foi enviada a OMG como reposta final RFP, onde as seguintes organizaes se juntaram ao grupo contribuindo com suas idias: IBM, ObjecTime, Platinum Technology, Petch, Taskon, Reich Technologies e SofTeam (Rational, 1997c).
27
RFP - Request For Proposal distribudo por uma Task Force de um dos comits de tecnologia OMG e um pedido explcito para os membros da OMG para submeter propostas para avaliao da tecnologia e sua adoo.
220
verso 1.1
setembro / 1997
verso 1.0
janeiro / 1997
verso 0.91
percia das organizaes
outubro / 1996
verso 0.9
junho / 1996
retorno do pblico
verso 0.8
OOSE
outubro / 1995
OOAD
OMT
outubro / 1994
Figura D.2 - Processo de cria o e padroniza o da UML (baseado em ( Rational, 1997a))

Cada uma dessas organizaes contriburam com a UML focalizando interesses prprios, pois perceberam que a UML seria estratgica para seus negcios, como por exemplo: HP, observando seu mtodo Fusion; Microsoft, preocupada com seus padres ActiveX e COM. Maiores detalhes ver (Rational, 1997a).
Uma linguagem de modelagem padronizada para o desenvolvimento sob o paradigma de orientao a objetos, vem acabar com a guerra das notaes e facilitar a comunicao entre analistas e projetistas de vrios domnios. A Rational continuar a liderar a definio da UML e manter suas revises que eventualmente a OMG solicitar (Rational, 1997b). Rumbaugh, Booch e Jacobson continuam trabalhando na tentativa de unificar seus mtodos que est sendo chamado de Rational Objectory Process. O objetivo fornecer uma estrutura para o processo que capturar elementos comuns, permitindo que as pessoas usem tcnicas que so mais apropriadas para seus projetos (Fowler, 1997).
& # ! 0)('%$"
221

Sgmoo: Sistema Gestor de Métodos Orientados A Objetos Baseado em Conhecimento

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sgmoo: Sistema Gestor de Métodos Orientados A Objetos Baseado em Conhecimento

Hochgeladen von

Copyright:

Verfügbare Formate

Universidade de Braslia

Instituto de Cincias Exatas Departamento de Cincia da Computao

SGMOO: SISTEMA GESTOR DE MTODOS ORIENTADOS A OBJETOS BASEADO EM CONHECIMENTO

Gilene do Esprito Santo Borges

Orientadora Prof(a). Dr(a). Maria Elenita Menezes Nascimento

Braslia, Dezembro de 1998.

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

A tarefa da equipe de desenvolvimento de software projetar a iluso de simplicidade.

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

"#!   #!  "  

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

Lista de Tabelas........................................................................................................................................... xiv

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

105 105 106 108 110 113 115 117

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

SGMOO: Sistema Gestor de Mtodos Orientados a Objetos Baseado em Conhecimento ________________________________________________________________________________________________

)(9C#AB'@2773532)(&'%$#!  $ 98 6 (4 10 " 

Captulo 1 - Introduo ________________________________________________________________________________________________

Captulo 1 - Introduo ________________________________________________________________________________________________

! " & % ! ! '$#$"#    14231!'0)  ! " !

Captulo 1 - Introduo ________________________________________________________________________________________________

Captulo 1 - Introduo ________________________________________________________________________________________________

No incio da computao no eram necessrios modelos de processo nem mtodos para o

   2A 7 0 2 '4 ' @'4 7 '4 2 ( % #"  3PI1')B2H(G6F7)ECDBA)6"98653"10 )'$&$!  

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

   4 3 & 0 &  "     )6521)()'%#$#! 

Figura 2.1 - Atributo de ligao (Rumbaugh, 1994)

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

Figura 2.2 - Agregao*

Terminada a base conceitual da modelagem esttica, segue a apresentao da modelagem dinmica.

Conceitos bsicos - modelagem dinmica

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

cria_ficha (nr_tombo,' ',d)

Figura 2.3 - Ilustrao dos conceitos bsicos de dinmica*

Conceitos bsicos - modelagem funcional

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

Processo 2 Depsito de dados 2 Ator 2

Figura 2.4 - Ilustrao dos conceitos bsicos de funcionalidade

Conceitos avanados modelagem esttica

Um objeto passivo, ao contrrio do objeto ativo, no possui aes, esttico.

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

tipo Pilha pilha: tipo pop(tipo) push(tipo)

int Pilha pilha: int pop(int) push(int)

string Pilha pilha: string pop(string) push(string)

Figura 2.5 - Classe parametrizada

Class name Ficha_usuario nome_usu endereco_usu cota_emprestimo cota_emprestada divida_total senha_usu

Figura 2.6 - Associao ternria*

Captulo 2 - Reviso bibliogrfica ________________________________________________________________________________________________

cadastra Ficha_usurio 1..N Funcionrio

comunica com Usurio 1..N

Figura 2.7 - Inexistncia de associao ternria*

Figura 2.8 - Associao qualificada*

"#! #! "

)(9C#AB'@2773532)(&'%$#! $ 98 6 (4 10 "

! " & % ! ! '$#$"# 14231!'0) ! " !

2A 7 0 2 '4 ' @'4 7 '4 2 ( % #" 3PI1')B2H(G6F7)ECDBA)6"98653"10 )'$&$!

4 3 & 0 & " )6521)()'%#$#!

3 # ) & # 4210('%$"!

!$2 7 5 !$ 0 & ! '4@$)986'4231)('$%"#

' % $#! (&"