MÉTODO DE OBJETIVOS PARA INTEGRAÇÃO DE PONTOS DE VISTA EM ENGENHARIA DE REQUISITOS DE COMÉRCIO ELETRÔNICO

Texto

(1)UNIVERSIDADE FEDERAL DO MARANHÃO CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA DE ELETRICIDADE. OZÉAS RODRIGUES LOBATO FILHO. MÉTODO DE OBJETIVOS PARA INTEGRAÇÃO DE PONTOS DE VISTA EM ENGENHARIA DE REQUISITOS DE COMÉRCIO ELETRÔNICO. São Luís 2004.

(2) OZÉAS RODRIGUES LOBATO FILHO. MÉTODO DE OBJETIVOS PARA INTEGRAÇÃO DE PONTOS DE VISTA EM ENGENHARIA DE REQUISITOS DE COMÉRCIO ELETRÔNICO. Dissertação apresentada ao curso de Mestrado em Engenharia de Eletricidade da Universidade Federal do Maranhão como parte dos requisitos para obtenção do título de Mestre em Ciências da Computação. Orientador: Prof. Dr. Zair Abdelouahab. Co-Orientador: Prof. Dr. Edson Nascimento.. São Luís 2004.

(3) Lobato Filho, Ozéas Rodrigues. Método de objetivos para integração de pontos de vista em Engenharia de Requisitos de Comércio Eletrônico / Ozéas Rodrigues Lobato Filho. – São Luís, 2004. 121f.: il. Dissertação (Mestrado em Engenharia de Eletricidade) – Centro de Ciências Exatas e Tecnológicas, Universidade Federal do Maranhão, 2004. 1. Engenharia de Requisitos. 2. Comércio Eletrônico. I. Título. CDU. 004.41.

(4) OZÉAS RODRIGUES LOBATO FILHO. MÉTODO DE OBJETIVOS PARA INTEGRAÇÃO DE PONTOS DE VISTA EM ENGENHARIA DE REQUISITOS DE COMÉRCIO ELETRÔNICO Dissertação apresentada ao curso de Mestrado em Engenharia de Eletricidade da Universidade Federal do Maranhão como parte dos requisitos para obtenção do Título de Mestre em Ciências da Computação.. Aprovada em. /. / 2.004. BANCA EXAMINADORA ______________________________________ Prof. Dr. Zair Abdelouahab (Orientador) ______________________________________ Prof. Dr. Edson Nascimento (Orientador) ______________________________________ Prof. Dr. Aristófanes Corrêa (Membro da Banca Examinadora ) ______________________________________ Prof. Dr. Paulo Romero (Membro da Banca Examinadora ).

(5) A meus pais, Ozéas Lobato (in memoriam) e Maria Graça, lembrança viva dos valores que me legaram. A Diva pela dedicação de todos esses anos. A. minha. esposa,. Sylvia,. pelo. apoio,. compreensão, companheirismo e incentivo. Aos meus irmãos Diana, Célia, Francisca, Augusto, Neusa e Antônio Neto. Aos queridos sobrinhos Ozéas Neto, Rebeca, Hellen, Ricardo, Amanda, Davi e Higo..

(6) AGRADECIMENTOS. Primeiramente a Deus, por ter me dado tudo que eu realmente precisava. À minha mãe, Maria Graça pela audácia e arte de colocar a educação como prioridade em nossas vidas sem deixarmos a vida de lado... Ao Prof. Dr. Zair Abdelouahab pelo empenho, paciência e dedicação na orientação dos trabalhos realizados. Para mim exemplo de homem, professor e AMIGO. Aos grandes professores da minha vida estudantil até aqui. Lourival (Ensino Fundamental), Marcelino e Ednaldo (Ensino Médio) e Abimael (Ensino Superior) pelos incentivos e exemplos. Ao Prof. Dr. Othon Bastos pelo incentivo e colaboração desde o início do mestrado. À FAPEMA pelo apoio e contribuição dada durante todo o desenvolvimento do trabalho aqui apresentado. Ao Amigo, tanto quanto um irmão, Alfredo pelos inoportunos trabalhos por mim causados. Ao Amigo e cunhado, Hugo Sampaio pela paciência e importante ajuda na finalização do trabalho aqui apresentado. Aos meus colegas e amigos da Pós-Graduação, cujo convívio foi um grande aprendizado. Em especial a Samyr Béliche, por ter colaborado significativamente para o desenvolvimento deste trabalho. A todos que acreditaram e que de uma forma ou de outra disseram ao menos uma vez uma palavra de incentivo..

(7) “If you don’t understand the user’s requirements, it doesn’t matter how you code it.”. Ed Yourdon..

(8) RESUMO. Este trabalho relata a importância de se utilizar pontos de vista em e-business definindo alguns conceitos relacionados. Mostra um estudo comparativo entre os métodos existentes que trabalham com pontos de vistas trazendo suas vantagens, desvantagens, diferenças de enfoques. Em seguida apresenta um método para integração de pontos de vista em e-business baseados em cenários, citando seu framework que também pertencerá ao método aqui proposto. Um dos focos desse método de cenários é demonstrar antes de qualquer desenvolvimento da idéia em comércio eletrônico sua viabilidade técnica e comercial. O objetivo deste trabalho é propor um método para integração de pontos de vista baseado em objetivos visando reduzir o tempo de compreensão da idéia por parte dos usuários e simplificar a construção dos Mapas de Caso de Uso (UCMs). Ponto este importantíssimo na produção de idéias inovadoras para o comércio eletrônico. Como os objetivos são de alto nível de abstração, na maioria das vezes facilitam e agilizam o entendimento, confiabilidade e prova ou não rapidamente sua viabilidade técnica e econômica a todos os envolvidos utilizando uma ferramenta semiautomática também implementada. Além disso, mostra como este método de objetivos é empregado na elicitação e análise de requisitos de comércio eletrônico. Um estudo de caso de comércio eletrônico em publicidade eletrônica é usado para ilustrar o método. Palavras chaves: Casos de uso. Cenários. Comércio eletrônico. Elicitação. Modelagem. Objetivos. Ponto de vista. Requisitos..

(9) ABSTRACT. In this work, we cited the existent methods for viewpoint together with a comparative study among them, we identify the types of requirements viewpoints that the existing methods are using. Soon after we present one method that is based on value for viewpoint in e-business, mentioning its framework which we incorporate in our method in e-business to show the technical and commercial viability of the idea. We will show that needs and interests of several stakeholders types that can be expressed through different viewpoint models. We propose an extension of Use Case Maps (UCMs) for e-business together with the Goal based Requirements Analysis Method (GBRAM), as a method of Requirements Engineering to reach the integration of the necessary point of view. Besides, It is showing that the method of objectives is used in the elicitation and analysis of e-business requirements. A case study of commerce in electronic publicity is used to illustrate our method.. Key words: Case Stady. Scenerio. e-Commerce. Elicitation. Modelling. Goal. Viewpoint. Requirements..

(10) LISTA DE FIGURAS. Figura 2.1. - Notação SADT ................................................................................................. 25. Figura 2.2. - Hierarquia de Classes de Pontos de Vista ....................................................... 30. Figura 2.3. - O Framework do e3-Value ............................................................................... 34. Figura 2.4. - Principais construtores do Modelo de Valor ................................................... 36. Figura 2.5. - Principais construtores do UCM ..................................................................... 39. Figura 2.6. - Interface do UCMnav ...................................................................................... 43. Figura 2.7. - Comparativo entre Métodos Existentes .......................................................... 44. Figura 2.8. - O Método GBRAM ......................................................................................... 45. Figura 3.1. - O Método Obje3-Value ................................................................................... 52. Figura 3.2. - O Método GBRAM alterado para Obje3-Value .............................................. 52. Figura 3.3. - Exemplo Modelo de Valor .............................................................................. 54. Figura 3.4. - Exemplo de UCM no Ponto de Vista de Valor Comercial ............................. 55. Figura 3.5. - Tabela de Custo/Lucro no ponto de vista de valor do ator Cliente ................. 56. Figura 3.6. - Tabela de Custo/Lucro no ponto de vista de valor do ator Fábrica ................. 57. Figura 3.7. - Tabela de Custo/Lucro no ponto de vista de valor do ator SERASA ............. 57. Figura 3.8. - Exemplo de UCM no Ponto de Vista de Processso Comercial ...................... 58. Figura 3.9. - Tabela de Custo/Lucro no ponto de vista de processo do ator Cliente ........... 59. Figura 3.10 - Tabela de Custo/Lucro no ponto de vista de processo do ator Cliente ........... 59 Figura 3.11 - Tabela de Custo/Lucro no ponto de vista de processo do ator SERASA ....... 60 Figura 3.12 - Exemplo de UCM no Ponto de Vista de Arquitetura do Sistema ................... 61 Figura 3.13 - Tabela de Custo/Lucro no ponto de vista de arquitetura do ator Cliente ........ 62 Figura 3.14 - Tabela de Custo/Lucro no ponto de vista de arquitetura do ator Fábrica ....... 63 Figura 3.15 - Tabela de Custo/Lucro no ponto de vista de arquitetura do ator SERASA .... 63.

(11) Figura 4.1. - Modelo de Valor Comercial ............................................................................ 69. Figura 4.2. - UCM do Valor Comercial ............................................................................... 72. Figura 4.3. - Cadastro de Atores envolvidos no Estudo de Caso ......................................... 73. Figura 4.4. - Parte 1 do cadastro de Atributos ..................................................................... 73. Figura 4.5. - Parte 2 do cadastro de Atributos ..................................................................... 74. Figura 4.6. - Cadastramento de Objetivos ........................................................................... 74. Figura 4.7. - Lista de todos os Objetivos Cadastrados ......................................................... 75. Figura 4.8. - Tab. Custo/lucro para Pesquisador no obj. Publicar Anúncio na FAP ........... 76. Figura 4.9. - Tab. Custo/lucro para FAP no obj. Publicar Anúncio na FAP ....................... 77. Figura 4.10 - Tab. Custo/lucro para FAP Remoto no obj. Publicar Anúncio em FAP ......... 77 Figura 4.11 - Tab. Custo/lucro para ator Pesquisador no obj. Ler Anúncio em FAP ........... 78 Figura 4.12 - Tab. Custo/lucro para ator FAP no obj. Ler Anúncio ..................................... 79 Figura 4.13 - Tab. Custo/lucro para ator Associação no obj. Ler Anúncio .......................... 79 Figura 4.14 - Tab. Custo/lucro para Pesquisador no obj. Pub. Anúncio em FAP Remoto.... 80 Figura 4.15 - Tab. Custo/lucro para ator FAP no obj. Pub. Anúncio em FAP Remoto ....... 80 Figura 4.16 - Tab. Custo/lucro para Associação no obj. Pub. Anúncio em FAP Remoto..... 81 Figura 4.17 - Tab. Custo/lucro p/ FAP Remoto no obj. Pub. Anúncio em FAP Remoto ..... 81 Figura 4.18 - UCM do Processo Comercial .......................................................................... 82 Figura 4.19 - Tab. Custo/lucro para Pesquisador no obj. Publicar Anúncio em FAP .......... 83 Figura 4.20 - Tab. Custo/lucro para FAP no obj. Publicar Anúncio em FAP ...................... 84 Figura 4.21 - Tab. Custo/lucro para ator FAP Remoto no obj. Pub. Anúncio em FAP ....... 85 Figura 4.22 - Tab. Custo/lucro para Pesquisador no obj. Ler Anúncio ................................ 85 Figura 4.23 - Tab. Custo/lucro para FAP no obj. Ler Anúncio ............................................ 86 Figura 4.24 - Tab. Custo/lucro para ator Associação no obj. Ler Anúncio .......................... 86 Figura 4.25 - Tab. Custo/lucro para Pesquisador no obj. Pub. Anúncio em FAP Remoto ... 87.

(12) Figura 4.26 - Tab. Custo/lucro para ator FAP no obj. Pub. Anúncio em FAP Remoto ....... 87 Figura 4.27 - Tab. Custo/lucro para ator FAP no obj. Pub. Anúncio em FAP Remoto ........ 88 Figura 4.28 - Tab. Custo/lucro para Associação no obj. Pub. Anúncio em FAP Remoto..... 88 Figura 4.29 - UCM da Arquitetura do Sistema Descentralizada .......................................... 89 Figura 4.30 - UCM da Arquitetura do Sistema Centralizada ................................................ 90 Figura 4.31 - Tab. Custo/lucro para ator FAP no obj. Publicar Anúncio em FAP ............... 92 Figura 4.32 - Tab. Custo/lucro para ator FAP Remoto obj. Pub. Anúncio em FAP ............ 92 Figura 4.33 - Tab. Custo/lucro para Associação no obj. Publicar Anúncio em FAP ........... 93 Figura 4.34 - Tab. Custo/lucro para ator FAP no obj. Ler Anúncio ..................................... 93 Figura 4.35 - Tab. Custo/lucro para ator FAP Remoto no obj. Ler Anúncio ....................... 94 Figura 4.36 - Tab. Custo/lucro para associação no obj. Ler Anúncio ................................... 94 Figura 4.37 - Tab. Custo/lucro para ator FAP no obj. Pub. Anúncio em FAP remoto ......... 95 Figura 4.38 - Tab. Custo/lucro para ator FAP no obj. Pub. Anúncio em FAP Remoto ....... 95 Figura 4.39 - Tab. Custo/lucro para Associação no obj. Pub. Anúncio em FAP Remoto..... 96 Figura 4.40 - Relatório Final da Idéia do Ponto de Vista de Valor no Objetivo 1 ............... 97 Figura 4.41 - Relatório Final da Idéia do Ponto de Vista de Valor no Objetivo 2 ............... 98 Figura 4.42 - Relatório Final da Idéia do Ponto de Vista de Valor no Objetivo 3 ............... 99 Figura 5.1. - O Método Obje3-Value ................................................................................. 100. Figura 5.2. - Interface da Ferramenta .................................................................................. 101. Figura 5.3. - Análise de uma Nova Idéia ............................................................................ 102. Figura 5.4. - Árvore do Obje3-Value .................................................................................. 102. Figura 5.5. - Cadastro de Atores ......................................................................................... 103. Figura 5.6. - Cadastro de Atributos ..................................................................................... 103. Figura 5.7. - Alteração do Cadastro de Atores .................................................................... 104. Figura 5.8. - Cadastro de Objetivos .................................................................................... 104.

(13) Figura 5.9. - Mapas dos Objetivos ...................................................................................... 105. Figura 5.10 - Tabela de Custo / Lucro dos Atores ............................................................... 105 Figura 5.11 - Mapas de Caso de Uso dos Objetivos ............................................................ 106 Figura 5.12 - Construção da Tabela de Custo / Lucro ......................................................... 106 Figura 5.13 - Lista Completa dos Objetivos Cadastrados .................................................... 107 Figura 5.14 - Relatório Final ................................................................................................ 107 Figura 5.15 - Link da Ferramenta Obje3-Value com a Ferramenta UCMnav....................... 108.

(14) LISTA DE SIGLAS. CORE. - Controlled Requirements Expression. CNO. - Conjunto de Objetivos Não Operacionais. DRS. - Documento de Requisitos de Software. E. R.. - Engenharia de Requisitos. FAP´s. - Free ad papers. GBRAM. - Goal-Based Requirements Analysis Method. O1. - Caminho do objetivo 1, podendo ter 2, 3 e etc.. SADT. - Structured Analysis and Design Technique. UML. - Unified Modeling Language. UCMnav. - Use Case Map Navigator. UCM´s. - Use Case Maps. VOSE. - Viewpoint-oriented System Engineering. VORD. - Viewpoint-oriented Requirements Definition. P.V.. - Ponto de Vista.

(15) SUMÁRIO. LISTA DE FIGURAS .......................................................................................................... 08 LISTA DE SIGLAS ............................................................................................................. 12 1 INTRODUÇÃO ................................................................................................................. 16 2 ENGENHARIA DE REQUISITOS ................................................................................. 21 2.1 Pontos de Vista ................................................................................................................ 22 2.1.1 Tipos de pontos de vista ................................................................................................ 23 2.1.2 Métodos de pontos de vista ........................................................................................... 24 2.1.2.1 Técnica de Análise e Projeto Estruturado (SADT) ..................................................... 24 2.1.2.2 Expressão de Requisitos Controlados (CORE) .......................................................... 25 2.1.2.3 Construção de Sistema Orientados a Pontos de Vista (VOSE) ................................... 26 2.1.2.4 Definição de Requisitos Orientados a Pontos de Vista (VORD) ................................ 27 2.1.2.5 Validação de Requisitos Orientados a Pontos de Vistas ............................................ 31 2.1.2.6 Métodos de Cenários para Integração de Pontos de Vistas em e-Business na E.R. ... 32 a) O Framework do método de cenários para integração de p.v. em e-business......... 33 b) Mapas de Caso de Uso (UCM) ............................................................................... 39 c) Navegador de Mapas de Caso de Uso (UCMnav) ................................................... 42 2.1.3 Quadro comparativo entre os métodos existentes ......................................................... 44 2.1.4 - O Método GBRAM .................................................................................................... 45.

(16) 3 O MÉTODO PROPOSTO (OBJE3-VALUE) ................................................................. 51 3.1 Objetivos e UCM ............................................................................................................ 51 3.2 Fases do Método Proposto ............................................................................................. 51 3.2.1 Adaptações no método GBRAM para o método de objetivos ....................................... 52 3.2.2 Pontos de vista do e3-Value ........................................................................................... 53 3.2.2.1 Ponto de Vista do Valor Comercial ............................................................................ 54 a) Modelo do Valor Comercial .......................................................................................... 54 b) Construção do UCM com objetivos .............................................................................. 55 c) Tabela de custo/lucro para ponto de vista de valor comercial ..................................... 56 3.2.2.2 Ponto de Vista do Processo Comercial ....................................................................... 58 a) Construção do UCM com objetivos .............................................................................. 58 b) Tabela de custo/lucro para ponto do processo comercial ............................................ 59 3.2.2.3 Ponto de Vista da Arquitetura do Sistema .................................................................. 60 a) Construção do UCM com objetivos .............................................................................. 61 b) Tabela de custo/lucro para ponto de vista de valor ...................................................... 62 3.3 e3-Value com Objetivos .................................................................................................. 64 4 ESTUDO DE CASO .......................................................................................................... 67 4.1 Uma idéia inicial através de comércio eletrônico ........................................................ 67 4.2 Objetivos da idéia de comércio eletrônico .................................................................... 68 4.3 Pontos de Vista do e3-Value no estudo de caso ............................................................ 69 4.3.1 Ponto de Vista do Valor Comercial ................................................................................ 69 4.3.1.1 Modelo de Valor Comercial ........................................................................................ 69 4.3.1.2 UCM do Valor Comercial ........................................................................................... 72 4.3.1.3 Objetivos do Valor Comercial ..................................................................................... 72.

(17) 4.3.2 Ponto de Vista do Processo Comercial ........................................................................... 82 4.3.2.1 Modelo do processo Comercial e UCM do Processo Comercial ................................ 82 4.3.2.2 Objetivos do Processo Comercial ................................................................................ 83 4.3.3 Ponto de Vista da Arquitetura do Sistema ...................................................................... 89 4.3.3.1 Modelo da Arquitetura do Sistema .............................................................................. 89 4.3.3.2 Objetivo da Arquitetura do Sistema ............................................................................ 91 5 IMPLEMENTAÇÃO DA FERRAMENTA .................................................................. 100 5.1 Fases e Estratégias Implementadas .............................................................................. 100 6 CONCLUSÕES ................................................................................................................ 109 6.1 Conclusões ...................................................................................................................... 109 6.2 Trabalhos Futuros ......................................................................................................... 111 REFERÊNCIAS ................................................................................................................. 112 GLOSSÁRIO ...................................................................................................................... 115.

(18) 16. CAPÍTULO 1 - INTRODUÇÃO Durante os últimos anos muitas e idéias inovadoras para comércio eletrônico têm surgido tornando inadequadas as metodologias de elicitação e modelagem de requisitos existentes e fazendo necessária a criação de novas metodologias para elicitação de requisitos [1]. Por considerar a fase de definição de requisitos como sendo uma das fases mais críticas do ciclo de vida de um sistema é que vários pesquisadores estudam essa área visando uma maior compreensão sobre os requisitos de um software, pois sabem que as utilizações de requisitos inadequadas consistem em produção de sistemas que não atendem às necessidades dos usuários, aumentam os custos, as insatisfações, desentendimentos e etc. [2]. Neste trabalho são utilizados conceitos como os de cenários, objetivos, pontos de vista e comércio eletrônico (e-business). Cenários são descrições comportamentais de um sistema e seu ambiente. Eles oferecem uma maneira natural para descrever circunstâncias escondidas ou aspectos necessários a uma resolução adicional que poderia ser negligenciada. Já os objetivos são as metas de alto nível do negócio, organização ou sistema. Os pontos de vista consistem na importante análise de diferentes opiniões e aspectos de um sistema feito por diferentes stakeholders como meio de organizar e estruturar a atividade de Engenharia de Requisitos (E.R.). Chamamos de stakeholders a “alguém que reivindica um interesse na empresa ou sistema”. Os pontos de vista são importantíssimos no desenvolvimento de sistemas complexos que incorporam diversas tecnologias (software, hardware, etc.) [3]. Com a expansão da utilização da internet por parte das empresas como meio para concretizarem seus negócios vem se desenvolvendo uma nova modalidade de comércio, o ecommerce e conseqüentemente o e-business que é muito mais amplo. Dentre as vantagens de negócios fechados pela internet estão: facilidade de uso, conforto, economia de despesas, tempo e um nível muito inferior de burocracias [4]..

(19) 17. Mesmo com essas vantagens que servem de atrativos para os stakeholders muitos empreendimentos faliram, pois não obtiveram o lucro esperado pela falta de uma proposição de valor adequada [5]. É freqüente a visão, que um modelo de comércio eletrônico é semelhante a um modelo de processo, e assim pode ser especificado usando UML, por exemplo. Em [6] mostra que isto é um engano e que o modelo comercial não é sobre processos, mas sobre valores trocados entre atores. Com o aumento da utilização da internet para negociação e fechamento de negócios surge também na Engenharia de Requisitos a necessidade de novos métodos para elicitação e modelagem de requisitos adequados para e-business. Em virtude dessa necessidade da Engenharia de Requisitos que Jaap Gordijn tem desenvolvido uma metodologia utilizando cenários para uma rápida análise e integração de pontos de vista dessas inovadoras idéias [7]. Tais idéias são inovadoras por revelarem novas proposições de valor econômico, contudo desconhecido para o mercado. E o que é uma proposição de valor? É algo oferecido por uma parte para consideração ou aceitação por outra parte [1]. Quanto mais inovadoras forem as idéias para comércio eletrônico, menor será o tempo disponibilizado por exigência do mercado para elaboração e desenvolvimento de seus projetos de sistemas. Por isso são necessárias metodologias cada vez melhores que buscam um desenvolvimento dessas inovadoras idéias com rapidez e eficiência. No entanto não é suficiente um desenvolvimento rápido desses sistemas se eles não conseguem também mostrar na mesma velocidade aos stakeholders que essas idéias são viáveis técnica e comercialmente e que ofereçam também proteção nas propriedades digitais [8]. Vê-se aqui também como em [7] a necessidade de fazer duas perguntas inicialmente para se verificar a viabilidade comercial e técnica do sistema eletrônico respectivamente. Somente com respostas positivas às perguntas é que vale a pena estudar o sistema a fundo..

(20) 18. As perguntas são as seguintes: 1. A idéia de comércio eletrônico é esperada ser lucrativo para cada ator envolvido? 2. Os suportes dos sistemas de informações dos comércios eletrônicos são tecnicamente possíveis? Tal como a abordagem de cenários, em [7], esta também é baseada em requisitos de vários pontos de vistas como em [3], [9] e [10] para uma avaliação rápida das viabilidades técnica e comercial. A Separação de Interesses sem dúvida alguma, princípio famoso em tecnologia da informação, não poderia deixar de ser explorado também neste método porque separa stakeholders especialistas em seus pontos de vistas e conseqüentemente haverá uma visão mais completa de cada um desses pontos o que será melhor para uma integração (soma) e complementação do sistema. Existem outros métodos que também utilizam pontos de vista como exemplo, o SADT [11], o CORE [12], o VORD [13], a Validação de Requisitos Orientados a Pontos de Vistas [14] e o Método de Cenários [7], no entanto, somente o Método de Cenários [7] é adequado para inovadoras idéias em e-business. Tais idéias são inovadoras, porque revelam novas proposições de valor econômico desconhecido do mercado. Uma proposição de valor é algo oferecido por uma parte para consideração ou aceitação por outra parte [1] e [15]. E o Método de Cenários [7] é o único, até o momento, que trabalha com o ponto de vista de valor. O ponto de vista de valor é importantíssimo quando se tratando de aplicações em ebusiness. Utilizamos objetivos por ser de mais alto nível que cenários e na maioria das vezes de mais fácil compreensão..

(21) 19. A intenção nossa com o método de objetivos (Obje3-Value) é facilitar a compreensão de novas aplicações em e-business, por conceito de objetivo ser de mais alto nível e na maioria das vezes de mais fácil compreensão. É óbvio, que facilitando a compreensão também reduzirá o tempo gasto na compreensão da idéia. A preocupação com a redução de tempo é uma preocupação crescente em informática, pois cada vez mais será disposto um tempo menor para o desenvolvimento de uma idéia dada a velocidade dos avanços tecnológicos sob pena de ficarem obsoletos antes mesmo da implementação. Visando um outro método para integração de pontos de vista que é proposto neste trabalho Método de Objetivos, baseado na junção de três outros métodos. Este novo Método de Objetivos pode ser ampliado com gráficos de características e soluções [16] e [17]. As bases do método de objetivos são os métodos GBRAM [2], e3-Value [7] e Mapas de Caso de Uso (UCM´s) que aparecem em [18], [19], [20], [21] e [22] para comércio eletrônico, como um método de Engenharia de Requisitos para alcançar a integração de ponto de vista necessária. A abordagem de vários pontos de vistas de stakeholders é parte do método e3-Value [5], [7], [21], [23] e [24], anteriormente baseado em cenários só que agora será elevado seu nível para objetivos de inovadores sistemas de informação em e-business. Utilizou-se o método GBRAM para elicitar e modelar um conjunto de objetivos não operacionais. Este trabalho baseia-se em um método de cenários proposto por Jaap Gordijn, em [7] e desenvolve um método de objetivos para integração de pontos de vista em e-business com algumas vantagens a mais com intuito de simplificar, facilitar a compreensão da idéia analisada. O Método de Objetivo proposto visa diminuir conflitos tendo em vista que é utilizado para a elicitação desses objetivos o método GBRAM visto que em sua fase de análise de objetivos verifica os possíveis obstáculos do mesmo..

(22) 20. O interesse por objetivos possui vários motivos, dentre eles: 1- Por ser de mais alto nível, logo sendo normalmente de mais fácil compreensão que cenários; 2- Por não se preocupar com gráfico muito detalhado que a nosso ver é desnecessário para um entendimento geral da idéia. Neste método são colocadas tabelas de Custo/lucro para cada ator envolvido visando com isto justificar a viabilidade comercial e técnica da inovadora idéia em comércio eletrônico. Segundo Jaap Gordijn em [7], essas tabelas não são tão precisas e não servem como previsão de lucros esperados, pois inicialmente são estimadas pela experiência dos especialistas do ponto de vista. O resto deste trabalho é organizado da seguinte forma. No Capítulo 2 são introduzidos os conceitos de pontos de vista, o framework e3-Value, o Método de Análise de Requisitos Baseado em Objetivos (GBRAM) e os Mapas de Caso de Uso (UCM´s). No Capítulo 3, será explicado o Método de Objetivos proposto. No Capítulo 4, é feito um estudo de caso visando demonstrar o método. O Capítulo 5 mostra a implementação de uma ferramenta semiautomática. No Capítulo 6 são expostas as conclusões e trabalhos futuros..

(23) 21. CAPÍTULO 2 - ENGENHARIA DE REQUISITOS O objetivo deste capítulo é descrever os conceitos de requisitos, pontos de vista e classifica pontos de vista em direto e indireto explicando a importância de cada um. Ainda neste capítulo é colocado o método GBRAM e um quadro comparativo entre os métodos que trabalham com ponto de vista. Segundo, o IEEE Standart Glossary of Software Engineering Terminology de 1997 (IEEE97) define-se requisito como uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo. Daí conclui-se que requisitos de software são derivados de necessidades que usuários têm em resolver algum problema. E o domínio do problema se trata de uma determinada parte do sistema real na qual o usuário está interessado, a parte relevante para seu problema específico. A Engenharia de Requisitos vem sendo considerada crucial no desenvolvimento de software, por tratar não apenas de conhecimentos técnicos, mas também gerenciais, organizacionais, econômicos, sociais e estar intimamente relacionada com a qualidade de software. Por estes motivos, a Engenharia de Requisitos é muito estudada com o objetivo de melhorar a elicitação de requisitos e obter requisitos mais confiáveis. O modelo de processo mais comum da Engenharia de Requisitos divide as atividades em quatro grupos: 1-Elicitação de requisitos; 2-Negociação e análises de requisitos; 3Documentação de requisitos e 4-Validação de requisitos. O surgimento de muitos métodos preocupados em melhorar a elicitação de requisitos foi fruto de vários estudos na área de Engenharia de Requisitos, como por exemplo: Pontos de vistas [3], e3-Value [25] e Mapas de Caso de Uso (UCM) que serão utilizados neste trabalho juntamente com o método GBRAM para elicitação e modelagem de um conjunto de objetivo e avaliações de novas idéias..

(24) 22. 2.1 - Ponto de vista. O método de ponto de vista consiste na comparação de diferentes enfoques a uma mesma situação e no apoio parcial do processo de negociação necessário a conciliação das diferentes opiniões. Pontos de vista são análises feitas por especialistas envolvidos no processo com preocupações e interesses diferentes visando uma solução única e que satisfaça a todos [3] e [26]. As primeiras idéias sobre pontos de vistas foram introduzidas no método SADT (Structured Analysis and Design Technique) [12], [13] por volta dos anos 70. A idéia de se analisar por pontos de vista é algo de muito interessante, pois o entendimento de um problema pode ser tanto melhor quanto maior o número de fontes de informação que forem utilizadas para descrevê-lo, possibilitando uma resposta satisfatória para todos. Pontos de vistas são importantíssimos no desenvolvimento de sistemas complexos que incorporam diversas tecnologias (software, hardware, etc.). Parece-nos incoerente falar dos atuais métodos para integração de pontos de vista sem mencionar seus antecessores. Citaremos alguns a seguir: 1. SADT – Técnica de Análise de Projeto Estruturado [11]; 2. CORE – Expressão de Requisitos Controlados [12]; 3. VOSE – Construção de Sistemas Orientados a Pontos de Vista [27]; 4. VORD – Definição de Requisitos Orientados a Pontos de Vista [13]; 5. Validação de Requisitos Orientados a Pontos de Vista [14]; 6. Método de Cenários para Integração de Pontos de Vista em e-Business na E.R.[7]. Todos os métodos relacionados anteriormente são orientados a pontos de vista, mas é óbvio que apresentam diferenças. Cada método possui suas vantagens e desvantagens dependendo.

(25) 23. da razão para qual foi desenvolvido e para qual será aplicada. É correto dizer que todos esses métodos são orientados a pontos de vista, no entanto alguns deles adotam uma conceituação diferente para ponto de vista. •. Os pontos de vista em Técnica de Análise de Projeto Estruturado (SADT) são fontes ou sumidouros (destinos) de dados. Pontos de vista assumem o papel de fontes ou sumidouros (destinos) de dados que correspondem aos clientes recebendo serviços do sistema e enviando-lhe dados e informações de controle;. •. Os pontos de vista em Expressão de Requisitos Controlados (CORE) representam processos;. •. Os pontos de vista em Construção de Sistemas Orientados a Pontos de Vista (VOSE) representam papéis e responsabilidades;. •. Os pontos de vista em Definição de Requisitos Orientados a Pontos de Vista (VORD) representam serviços;. •. Os pontos de vista em Validação de Requisitos Orientados a Pontos de Vista representam papéis;. •. E finalmente para Método de Cenários para Integração de Pontos de Vista em e-Business na E.R. representam necessidades e interesses.. 2.1.1 – Tipos de pontos de vistas. Tais métodos, além de apresentarem diferentes conceitos para ponto de vista, apresentam também diferenças no tipo de ponto de vista. Os métodos orientados a pontos de vista são classificados em dois grupos: Pontos de Vista Direto e Pontos de Vista Indireto..

(26) 24. Os Pontos de Vista Direto referem-se a requisitos de stakeholders envolvidos diretamente com o uso do sistema, enquanto que Pontos de vista indiretos relacionam-se com requisitos oriundos de stakeholders com algum interesse no sistema, porém não envolvidos diretamente com seu uso. Os Pontos de Vista Indiretos produzem requisitos que impõe força para serviços oferecidos no ponto de vista direto gerando os requisitos não funcionais. Os requisitos não funcionais são quem freqüentemente representa a força que decide sobre a continuidade do sistema ou grandes alterações a que devem ser submetidos os sistemas antes de entrar em operação, logo o processo de Engenharia de Requisitos estará incompleto caso sejam desconhecidos os pontos de vistas indiretos [13]. Tomando como base os conceitos de ponto de vista de VORD, classificamos em direto ou indireto os pontos de vista utilizados nos outros métodos. Todos os métodos (SADT, CORE, VOSE, VORD, Leite, e Método de Cenários) utilizam o ponto de vista direto, no entanto o ponto de vista indireto é somente usado em VORD, CORE e Método Cenários.. 2.1.2 – Métodos de Pontos de Vistas. 2.1.2.1 - Técnica de Análise e de Projeto Estruturado (SADT). O método SADT - desenvolvido por Ross em 1985 - é baseado no modelo dataflow que vê o sistema como um conjunto de interações de atividades. A notação de retângulos representando a atividade do sistema e um conjunto de quatro setas, cada uma com o significado semântico diferente [11]. Conforme Figura 2.1. Este método adota apenas o ponto de vista direto que representam operadores/usuários ou subsistemas que interagem com o sistema sendo analisado, logo correspondem a clientes.

(27) 25. recebendo serviços (Inputs) e enviando (Outputs) dados de informações de controle submetido a um dado mecanismo de controle. Controle. Inputs. ATIVIDADE. Outputs. Mecanismo Figura 2.1 - Notação SADT. O método SADT é composto de um conjunto de diagramas hierárquicos cada um composto de um conjunto de caixas e setas. Cada nível de hierarquia inferior é documentado separadamente e apresentado o refinamento para seu nível hierárquico superior. A caixa retangular representa a atividade do sistema junto ao conjunto de inputs (entradas) e outputs (saídas) constituem o ponto de partida para a decomposição funcional. Este método vê o sistema como um conjunto de atividades interagindo e não possui uma definição explícita de ponto de vista. No método SADT são considerados como fonte e destinos de dados.. 2.1.2.2 - Expressão de Requisitos Controlados ( CORE ). O método CORE foi desenvolvido na British Aerospace, no final dos anos 70 por um projetista de sistema (Mullery, 1979). O método CORE é baseada na decomposição funcional e permite explicitamente os pontos de vista formular requisitos. CORE tem sido extensivamente usada na indústria aeroespacial européia e define pontos de vistas em dois.

(28) 26. níveis. O ponto de vista direto é o primeiro nível que compreende todas as entidades que interagem ou afetam diretamente o sistema pretendido de algum modo. O ponto de vista indireto é o segundo nível distingue entre: a). Definindo pontos de vista – que são subprocessos do sistema;. b). Limitando pontos de vista – entidade interagindo indiretamente com o sistema pretendido.. Em CORE, pontos de vista são representados por processos e classificados em direto e indireto. Os pontos de vista indiretos são entidades recebendo e fornecendo informações aos processos que neste método são conceituados como pontos de vista indireto.. 2.1.2.3 - Engenharia de Sistemas Orientados a Pontos de Vistas ( VOSE ). O método VOSE foi desenvolvido no Imperial College, em Londres no início dos anos 90 por Finkelstein, Nuseibeh et al. O VOSE foi concebido como um framework integrando para desenvolvimento de métodos em sistema composto. O método VOSE foi definido como um dos que envolve a combinação de diferentes tecnologias e requer o trabalho de peritos nas diferentes áreas de aplicação, cada um com diferentes focos de interesses no sistema [27]. Em VOSE, pontos de vista são papéis e responsabilidades, por isso usa pontos de vista para separação de atividade e conhecimentos dos participantes considerados no sistema. Cada ponto de vista é definido como um ator (ou papel) e seu ponto de vista do sistema é representado através de seu conhecimento parcial do sistema (suas responsabilidades) [13]. Estas informações são organizadas em um ponto de vista e representadas através de um esquema de cinco slots: style, domain, specification, workplan e workrecord..

(29) 27. Style. – composto do esquema e da notação utilizados para expressar a visão de um ponto de vista sobre o sistema;. Domain. – que define a parte do “mundo” representada pelo style;. Specification – composto de declarações expressas no style do ponto de vista para descrever domínios específicos; Workplan. – que descreve o processo através do qual a especificação pode ser construída e verificada;. Workrecord. – no qual o histórico e o estágio atual de desenvolvimento são lançados.. O método VOSE consiste de um método para organizar a integração ou múltiplas representações dos sistemas. No método VOSE, os pontos de vista são definidos como papéis e responsabilidade e sua forma de elicitação de requisitos não é comentada.. 2.1.2.4 - Definição de Requisitos Orientados a Pontos de Vistas (VORD). O método VORD foi proposto por Sommerville e Kotonya em 1996. Foi desenvolvido primeiramente para especificar sistemas interativos, mas pode também ser usada para especificar outras classes de sistemas. Para VORD o ponto de vista é conceituado como serviço e está dividido em duas categorias: Direto e Indireto. A principal preocupação do método foi dirigir alguns pontos que os autores consideravam importantes no método de desenvolvimento para supor o processo de Engenharia de Requisitos [13]..

(30) 28. Dentre eles destacam-se: a.. A necessidade de uma notação ordenada para permitir consistência e integridade na checagem;. b.. O método tinha que ser adequada para comunicação, especialmente com o usuário final, não requerendo um treinamento formal;. c.. O método deveria prover um suporte para desenvolver um requisito facilitando: •. A organização de estruturas de conhecimentos adquiridos durante a elicitação;. •. Separação de interesses de um modo que facilite para o leitor identificar na especificação a parte de maior interesse para eles.. d.. O método tinha que suportar a definição do desenvolvimento onde o sistema está sendo disposto;. e.. O método tinha que freqüentemente suportar a administração de naturezas múltiplas dos requisitos, fazendo fáceis cópias com temporária inconsistência e prestativas trocas sem a necessidade de reescrever todo o conjunto de requisitos;. f.. O método deveria suportar a integração das diferentes abordagens e tipos de requisitos uma vez sabendo que: •. Uma única técnica ou um método não tem habilidade para articular todos os requisitos do sistema, nem tão pouco os desenvolvedores de perspectivas ou usuários de perspectivas;. •. Requisitos não funcionais tendem a relacionar para um ou mais requisitos funcionais e os expressando separadamente esconde estas.

(31) 29. relações. Por outro lado, expressando-os juntos fica difícil distinguir dentre os considerados funcionais e não funcionais. O VORD foi primeiramente especificado como sistema interativo e resolução de ponto de vista. Já mencionado a importância que o VORD tem ao utilizar a classificação dos pontos de vistas em direto e indireto. O VORD é utilizado desde o levantamento inicial dos requisitos até a modelagem detalhada do sistema. O trabalho concentra-se nos três primeiros passos interativos do método: 1.. Identificação e estruturação de pontos de vista;. 2.. Documentação dos pontos de vista;. 3.. Análise e especificação dos pontos de vista.. Os autores enfatizam que o controle poderia ser representado como um processo distribuído em camadas, através de vários níveis de ambientes, culminando com o sistema como provedor de serviço no nível mais baixo. Os autores não acreditam na análise semântica automatizada. O método VORD auxilia a análise de requisitos e tem como limitações: 1.. A ausência de suporte para análise de interação entre pontos de vista e interações internas aos pontos de vistas;. 2.. A ausência de suporte às questões de controle associadas à concorrência;. 3.. A ausência de suporte ao tratamento do fluxo de tempo, além de considerá-lo como uma restrição aos serviços dos pontos de vistas;. 4.. Aplicação difícil para sistemas não orientados a serviços, isto é, sistemas interagindo com seu ambiente para fornecer-lhes serviços..

(32) 30. Ainda: a.. O vínculo dos pontos de vista às perspectivas do usuário, possibilitando uma separação eficiente entre as necessidades do usuário final e os requisitos de projetos (ao nível de sistema);. b.. A noção de pontos de vistas indiretos é de grande importância, pois se associa às pessoas de grande influência na estrutura organizacional, como pode ser visto na Figura 2.2;. c.. A identificação de pontos de vista como serviços é importante, pois permite a criação de uma estrutura básica com o encapsulamento de diversos aspectos relevantes dentro de um mesmo ponto de vista;. d.. A interação de diversas notações, formais e informais, facilita e melhora a comunicação entre os participantes do processo de requisitos (Engenheiros de Software, Usuários, Clientes e etc.).. Ponto de Vista. Direto. Operador. Indireto. Sistema. Engenharia. Manutenção. Normas. Normativo. Organização. Cliente. Figura 2.2-Hierarquia de Classes de Pontos de Vista. Ambiente. Política.

(33) 31. O formalismo para representar os relacionamentos entre os pontos de vista a serem identificados nos sistemas pode ser bom por usar uma linguagem natural que os engenheiros já usam há tempos e pode ser ruim, pois pode dá ilusão do entendimento do problema.. 2.1.2.5 - Validação de Requisitos Orientados a Pontos de Vistas. O método é proposto por Leite e Freeman em 1991. O objetivo principal do método se refere à validação de requisitos no contexto da atividade de elicitação de fatos, antes do processo atingir a atividade de construção do modelo, constituindo-se em um processo de validação bem no início do processo de Engenharia de Requisitos. Esta é uma abordagem relativamente formal, pois baseadas em templates, que pretende automatizar o processo de identificação de falhas de inconsistência presentes no sistema de especificação de requisitos. Isto define um Framework, ou seja, um padrão de arquitetura para aquele domínio, baseado em pontos de vista que suportam a identificação automatizada e classificação dos problemas de consistência, especialmente integridade e correção. O método focaliza no apoio a resolução dos conflitos, nas análises e acordos com certo grau de formalismo. Neste método dois processos são considerados relevantes: elicitação e modelagem de requisitos, entre essas duas atividades, existem a validação de requisitos, inseridas nos subprocessos de validações de fatos e comunicação. O método não prevê influência de fatores organizacionais na composição dos pontos de vista, pois adota o conceito de pontos de vista direto. Leite [24] classifica pontos de vista como: 1-Opiniões; 2-Especificações e 3-Serviços..

(34) 32. 1.. Opiniões – Além de unir as áreas de ciências sociais e Engenharia de Requisitos. Pelo lado da Engenharia de Requisitos, há necessidade de idéias para ajudar o desenvolvimento de ferramentas, técnicas e métodos e usar estratégias sociais viáveis considerando influência de diferentes pessoas. Por outro lado, podemos ser criticados pelo trabalho executado em Engenharia de Requisitos por considerar idéias de pessoas das áreas de ciências sociais;. 2.. Especificações – usado na elaboração de abordagens sistemáticas para os problemas de Engenharia de Requisitos. Muitos métodos têm sido propostos e cada um dedica-se a um problema específico no processo de Engenharia de Requisitos;. 3.. Serviços – São vistos como pontos de vista providos pelo sistema para cada um dos diferentes tipos de agentes.. Não há suporte específico para requisitos não funcionais, tratando requisitos em geral como repositórios de papéis, organizados através de diferentes pontos. Isto pode ser especialmente importante na negociação em que os conflitos terão de ser resolvidos. O método dá importância especial ao desenvolvimento de um vocabulário comum no “universo de discurso”.. 2.1.2.6 - Método de Cenários para Integração de Pontos de Vistas em e-Business na Engenharia de Requisitos. O método é proposto por Jaap Gordijn, Hans de Bruin e Hans Akkermans da Vrije Universiteit – Vuture.net em 2001. O método em questão é uma extensão de outro método chamado Mapas de Caso de Uso (UCMs) para comércio eletrônico de Engenharia.

(35) 33. de Requisitos juntamente com o framework e3-value. O método de Cenários é um método de Engenharia de Requisitos para elicitar, organizar, estruturar e integrar pontos de vistas [7]. Mapas de Caso de Uso (UCMs) apresentam uma notação baseada em cenários para descrever, como são entrelaçados uma estrutura organizacional de um sistema complexo e o comportamento emergente de um sistema. A notação não é uma técnica de especificação de comportamento no sentido comum, mas uma notação para ajudar uma pessoa a visualizar, pensar, e explicar o comportamento global de um sistema complexo. O comportamento do sistema que nos interessa emerge dos esforços individuais coordenados pelos próprios componentes semi-independentes (freqüentemente concorrentes) que operam sem a ajuda de qualquer algoritmo ou plano central. Os componentes têm que lidar com a possibilidade de fracasso de outros componentes e comunicação entre componentes. Estes podem ser software, hardware, podem ser distribuídos, como objeto, threads, monitores, processos, pacotes etc. Um Mapa de Caso de Uso (UCM) é uma notação visual a ser usada por pessoas para entender o comportamento de um sistema em um alto nível de abstração. O método é uma abordagem baseada em cenários que explica as relações causa-efeito percorrendo caminhos através de um sistema.. a) O Framework do Método de Cenários para Integração de Pontos de Vista em eBusiness.. O desenvolvimento de uma aplicação de comércio eletrônico é mais um processo de criação de requisitos que de elicitação devido à natureza das aplicações modernas [1], [12]. Visando facilitar a separação de interesses, a criação de requisitos deve ser fundamentada em pontos de vistas de importantes e diferentes grupos de stakeholders envolvidos no sistema..

(36) 34. Características principais. 1.. Reconhece a importância do valor econômico, logo, analisa a criação, troca e consumo de objetos economicamente valiosos;. 2.. Fundada no princípio de Engenharia de Requisitos de vários pontos de vista e modelagem conceitual semiformal que utiliza templates.. Os três pontos de vistas. A Figura 2.3 ilustra o framework e3-Value, onde se percebe que a simulação do lucro total de aplicações em e-business somente é obtido após a avaliação de três pontos de vista deste framework.. Avaliação do Valor Comercial Avaliação do Processo Comercial Avaliação da Arquitetura do Sistema Total Lucro Figura 2.3- O Framework do e3-Value.

(37) 35. Ponto de vista do valor comercial. No ponto de vista do valor comercial é descrito um novo e inovador modelo de negociar em termos de valores trocados entre atores. Captura “o que” está fazendo o negócio e “com quem”, mas não diz “como” é feito. O “como” já é parte do ponto de vista do processo comercial que será descrito na próxima seção.. Ponto de vista do processo comercial. O ponto de vista do processo comercial focaliza na operacionalização do ponto de vista de valor comercial em termos de processo de negócio. Para representar o ponto de vista de processo comercial, várias técnicas existentes são satisfatórias. Neste trabalho será utilizada a modelagem de processo de Ould [30] a mesma utilizada na ferramenta para construção de Mapas de Caso de Uso (UCMnav).. Ponto de vista da arquitetura do sistema. Focaliza o sistema de informação que habilita ou apóia os processos de comércio. Para nosso propósito, uma arquitetura de sistema se encontrará no estágio primário de desenvolvimento para avaliar a viabilidade técnica e comercial de uma idéia. Uma vez que a viabilidade foi demonstrada pelo ponto de vista comercial e da arquitetura de sistema, esta pode ser elaborada em seguida..

(38) 36. Construtores do Modelo de Valor do e3-Value. Para construção do Modelo de Valor Comercial são necessários seus construtores que serão listados e conceituados a seguir. Por razões de brevidade, para saber mais leia [5], [23] e [24]. A Figura 2.4 mostra os principais construtores. Atividade de Valor. Executa 1...n. 0...1 Atribuído. 1...n. Entrada. 1. 1...n Troca de Valor. Atribuído. Interface de Valor. Contribuição de Valor Contém. 1...n. Entre 0...n. 1...n. Saída. 1...n. 2...n. 1 Ator. Porta de Valor. 1...n Oferece/Requisita 0...n. 0...n. Objeto de Valor. Figura 2.4 - Principais Construtores do Modelo de Valor.. A Figura 2.4 mostra os construtores do modelo de valor comercial e também as relações entre eles como por exemplo, ator e atividade de valor. Conforme a Figura 2.4, um ator é capaz de executar 1 (uma) ou mais atividades de valor, no entanto, a atividade de valor só poderá ser executada por um ator. Os principais construtores são: Ator - Um ator é percebido em seu ambiente como uma entidade independentemente econômica como uma companhia ou uma pessoa. Todos os atores são capazes de executar uma ou mais atividades de valor que somam valores para eles ou para outros. Atividade de valor – Uma atividade de valor é executada por um ator e representa um processo que soma valor e reproduz objetos de valor. Objeto de valor – um objeto de valor é o que produzido ou consumido por uma atividade de valor pode ser um serviço, produto ou ainda uma experiência do consumidor..

(39) 37. Porta de valor – uma porta de valor é um conector que interconecta atores ou atividades de valor baseado em componente. Como analogia poderíamos pensar em uma tomada elétrica de parede, tem duas portas. Interface de valor – uma interface de valor representa um serviço de comércio oferecido ou solicitado de uma atividade de valor. Possui uma ou mais portas de valor, e modelo das contribuições de um ato ou atividade de valor para seu ambiente. Troca de valor – uma troca de valor representa o comércio de um objeto de valor entre portas de valor. Contribuição de valor – uma contribuição de valor consiste em um conjunto de trocas de valores. Considerando que trocas de valor conectam portas de valor, contribuição de valor conecta interfaces de valor de atores. Após a construção do modelo de valor, é hora de construir os mapas de caso de uso (UCM) usando os objetivos para cada ponto de vista discutindo com seus stakeholders. Por último serão construídas as tabelas de custo/lucro que servem para analisar a viabilidade econômica e técnica da inovadora idéia.. Construção de tabelas de rentabilidade.. Uma tabela de rentabilidade é colocada para cada ator envolvido em diferentes pontos de vista e objetivos. De acordo com [7], a tabela pode seguir os passos: 1.Para cada ator faça uma lista de valores entrando; Analisando o objetivo podemos construir uma lista de valores in e out do ator. 2.Remova os valores neutros “in” e “out”; Alguns grupos de objetos de valores, que entram e saem de um ator, que são difíceis de se quantificar são considerados valores neutros e devem ser evitados..

(40) 38. 3.Calcule o valor restante dos objetos de valor; O restante dos objetos de valor é expresso em unidades monetárias. É simples quando avaliando um objeto de valor pago em dinheiro, no entanto quando outros objetos são avaliados como o valor de um possível contato para o pesquisador isto se torna mais complicado, e envolve diferentes qualidades e dimensões de valor. 4.Calcule a rentabilidade dos caminhos do objetivo; A rentabilidade de cada objetivo é calculada somando todos os objetos que entraram no ator e subtraindo todos os que saíram durante a realização daquele objetivo. 5.Calcule a probabilidade dos caminhos do objetivo; Esta probabilidade de ocorrência de objetivos é baseada em experiências e estimações feitas previamente por especialistas da área. 6.Calcule a rentabilidade esperada de um caminho do objetivo; A rentabilidade de cada caminho do objetivo é encontrada através da multiplicação da rentabilidade do caminho do objetivo pela sua probabilidade. 7.Calcule a rentabilidade esperada de um objetivo. Para finalizar nós totalizamos a rentabilidade esperada de cada caminho de objetivo no objetivo. Ao preencher a Tabela, obteremos assim uma primeira impressão da rentabilidade da idéia comercial. No entanto, tem que ser desenvolvida uma visão global da rentabilidade..

(41) 39. b) Mapas de Caso de Uso (UCM). O UCM é uma notação que ajuda visualizar uma idéia e explicar em alto nível um comportamento de um sistema complexo. O UCM é uma notação visual usada para entender o comportamento de um sistema em alto nível de abstração [19]. Segundo [7] e [18], a notação de UCM básica é muito simples, e consiste de quatro elementos básicos: pontos de começo, responsabilidades, componentes e pontos de término. O termo componente deveria ser interpretado em sentido amplo: Pode ser um componente de software, mas também pode ser representado por ator humano ou um sistema de hardware. A seguir, a Figura 2.5 apresenta um exemplo simples de Mapas de Caso de Uso para ilustrar seus elementos básicos e alguns de seus construtores com funções diversas. Um caminho de cenário é executado como um resultado da recepção de um estímulo externo. Imagine agora que um ponteiro (mão) na Figura 2.5, seja colocado no ponto início. Ponto Final. Ponto Início. Responsabilidades Componentes Sim. (a) OR-join. (b) OR-fork. Não ) Identificadas supostas rotas permissíveis.. Figura 2.5 – Principais construtores do UCM. Agora, considere um caminho através do sistema de objetos para explicar uma seqüência de acontecimento. O UCM captura essas seqüências. Além dos elementos de caminhos principais, existem ainda muitos outros elementos. Citaremos alguns desses a seguir..

(42) 40. Elementos principais dos caminhos: Pontos de Início. - Círculos cheios representam as pré-condições ou causas. Significam o início do caminho de cenário quando um estímulo é recebido;. Responsabilidades - São cruzes representando ações, tarefas ou funções a serem executadas; Pontos Finais. - São barras representando as pós-condições ou resultados alcançados. Significam o fim do caminho de cenário.. Componentes. - São as entidades ou os objetos que compõem o sistema.. Outros elementos: And Fork. -Indica que o único caminho está dividida em muitas ramificações concorrentes;. And Join. -Indica que vários caminhos concorrentes sincronizamse em um único caminho;. Stub. -É um elemento de decomposição em mapas de caso de uso, onde um sub-mapa pode ser definido; Stub static – único sub-mapa Stub dynamic – muitos mapas. Local de Espera. -É um ponto de sincronização onde um cenário espera até que um determinado evento seja atingido;. Local de Espera Temporizado. -É um ponto que pode ter um tempo de espera (timeout) definido enquanto a ação é tomada;.

(43) 41. Setas Dinâmicas. -São pequenas setas que apontam para o caminho indicando o componente do software entrando ou saindo do caminho;. Seta Move-Fica. -É uma seta com uma barra perpendicular que indica que está copiando o componente do software e movimentando para dentro ou para fora do caminho;. Criação,. -As setas com sinais positivos e negativos são para. Destruição de. criação. e. setas. respectivamente.. destruição. dos. componentes. Dentre esses, normalmente o construtor mais freqüente é o AND que pode ser AND-join e que é usado para sincronizar várias atividades em caminho de cenários paralelos e o ANDfork para separá-los. Na construção dos mapas, também são usados os elementos do Software. Time. - Um componente genérico que pode ser de qualquer tipo e estruturalmente conter qualquer componente;. Objeto. - Um componente de baixo nível que não pode conter outro componente, ou seja, subcomponentes;. Processo. - Um componente ativo que tem seu próprio thread de controle. Pode conter objetos passivos;. Pool. - Uma área de armazenamento para operacionalizar componentes dinâmicos inativos. O conteúdo dos Pools deve ser movido dos slots para tornarem-se visíveis e ativos;. Agente. - Componente de software similar a representação do agente de software;.

(44) 42. Stack. - Uma pilha de componentes indica um conjunto de operacionalidades. idênticas,. mas. em. componentes. separados. Slot. - Um slot é um tipo particular de componente que indica um local de um componente dinâmico. É representado através do esboço tracejado do componente.. Foram citados alguns dos elementos dos caminhos e de software utilizados na construção dos UCM. Para conhecer mais é interessante ler [18] e [20].. c) Navegador de Mapas de Caso de Uso (UCMnav). Visando a construção de Mapas de Caso de Uso foi desenvolvida por Andrew Miga na Caleton University em 1998 uma ferramenta chamada de UCMnav. O aspecto mais importante do trabalho de [19] foi desenvolvido uma ferramenta capaz de manusear Mapas de Caso de Uso em projetos de sistemas e fazer uma representação da estrutura e comportamento do sistema usando cenários. A construção de mapas de caso de uso utilizando esta ferramenta tem como uma das principais vantagens a visualização real e maior entendimento do processo ou idéia a ser implementada. Na Figura 2.6 é colocado a interface do UCMnav..

(45) 43. Figura 2.6 - Interface do UCMnav. Informações sobre esta ferramenta podem ser encontradas em [28] (versão de maio de 2003)..

(46) 44. 2.1.3 – Quadro Comparativo entre métodos existentes.. Foi construído um quadro para simplificar e comparar os métodos citados anteriormente. QUADRO COMPARATIVO Método. Conceito de Ponto de vista. SADT. Fontes e destinos de dados. CORE. Processos. VOSE. Papéis e responsabilidades. VORD. Serviços. Tipo de Ponto de Vista. Baseado. Vantagem. Desvantagem. Modelo Data-flow. Direto Direto e Indireto Direto. Direto e Indireto. Leite. Papéis. Direto. Método de Cenário. Necessidades e interesses. Direto e Indireto. *Não tem explícita a definição *Oferece pouco de ponto de vista, podendo ser suporte ao um usuário, por exemplo; tratamento de não funcionais; Decomposição *Permite explicitamente o ponto *O conceito restrito Funcional de vista formular os requisitos. de ponto de vista como processo. Template 5 *Coleções de pontos de vistas *Oferece pouco slots: relatados; suporte ao Style,Domain, *Coleções de domínios de tratamento de não Specification, problemas hipotéticos podem ter funcionais; template com styles. Workplan e Worrecord. *A identificação de ponto de vista como serviço é importante, *Aplicação difícil pois permite a criação de uma para sistemas não estrutura básica de orientados a Orientado a encapsulamentos de diversos serviços; Serviço aspectos semelhantes dentro de um mesmo ponto de vista; *Não oferece *A noção de ponto de vista suporte à análise de indireto é de grande importância interação entre e devido requisitos não funcionais; dentro dos pontos *O vínculo dos pontos de vistas de vistas. às perspectivas do usuário possibilitam uma separação entre necessidades do usuário final e os requisitos do projeto.. Heurística. pouco *Enfoca a resolução de conflitos *Oferece de maneira pouco formal; suporte aos tratamentos de não *Definição de uma linguagem funcionais; comum VWPl; *Não prevê a *Evita tantos recuos no processo influência de fatos de desenvolvimento de software organizacionais na já que são validados antes da composição do modelagem. ponto de vista.. *A notação de UCM é muito Mapas de Caso simples; de Uso (UCM´s) *Por ser um método que ajuda na integração de pontos de vista em e-business; *Explora mecanismos separação de interesses.. *Os caminhos de cenários não indicam ordenação de tempo;. *Não se preocupam com o custo de de mensagens do servidor.. Figura 2.7 – Quadro Comparativo entre os Métodos Existentes.

(47) 45. 2.1.4 - O MÉTODO GBRAM O Método GBRAM foi escolhido primeiramente por ser um método de elicitação e modelagem de requisitos e também por possuir uma subfase de organização dos objetivos. Por essa subfase de organização facilitar o ponto de vista de valor como também o ponto de vista de processo, pois já são conhecidos à ordem dos processos e/ou sub-objetivos a serem utilizados para alcançar os objetivos maiores [2]. Conforme [2] e [29], é apresentado o GBRAM que pressupõe que os objetivos não tenham sido previamente documentados ou explicitamente elicitados a partir dos stakeholders. Assim, o analista deve trabalhar a partir de todas as fontes de informação disponíveis, como declarações textuais de necessidades, fontes adicionais de informação como transcrição de entrevista com os stakeholders visando determinar um conjunto de objetivos desejado. O GBRAM descrito na Figura 2.7 envolve duas fases: a fase de análise de objetivos e a fase de refinamentos de objetivos, produzindo como saída o DRS (Documento de Requisito de Software) que provê uma comunicação confiável entre stakeholders, além de suportar a evolução e validação de requisitos.. Entradas. Análise do objetivo. Transcrip Diag. fluxos de dados Requerimentos. Explorar. Identificar. Políticas. Organizar. Fatos de entrevistas Declaraç. Textuais. Refinar. DRS Saída. Operacionalizar. Elaborar. Refinamento do objetivo Figura 2.8 - O Método GBRAM..