Home

Info Cases: Um Modelo Integrado de Requisitos - Introdução

1. Figura 5 2 Composi o dos fluxos da aplica o Restaurante Os estudos experimentais realizados com ICs Cap tulo 6 t m indicado que os usu rios ap s um breve treinamento passam a trabalhar confortavelmente com as express es produzidas nessa linguagem Segundo LAUESEN 2002 p gina 60 e seguintes essas express es s o excelentes para os modeladores e aceit veis para muitos usu rios que mesmo sem um forma o espec fica em tecnologia da informa o acham essas express es mais f ceis de compreender do que modelos E R Ainda 68 segundo ele as express es n o t m a riqueza sem ntica de um bom dicion rio de dados mas as duas t cnicas se complementam No Dicion rio de Itens Elementares DI para cada item elementar presente na interface informacional de um UC s o informados seu Nome Descri o Tipo e Dom nio Tabela 5 1 A informa o de Dom nio apresenta os valores que o item pode assumir Uma forma estendida do dicion rio incluiria ainda os campos Unidade e Precis o aplic veis aos itens com valores em uma determinada unidade de medida exemplo o item de informa o p unit teria Unidade Real e Precis o centavos A experi ncia tem evidenciado que o DI desempenha um papel muito importante na especifica o informacional dos UCs pois necess rio definir com precis o a sem ntica de cada item de informa o nela presente Assim
2. 6 1 4 Considera es sobre os Estudos Precursores A experi ncia did tica com a MIC mostrou que a t cnica pode ser ensinada sem maiores dificuldades e que mesmo profissionais fora da rea da computa o s o capazes de ler e elaborar modelos simples utilizando a t cnica O Estudo 1 SIMEL funcionou como uma prova de conceito mostrando que a t cnica pode ser utilizada para sistemas de porte m dio a grande O Estudo 2 uniformidade dos MDs revelou o potencial da MIC para resolver o problema das diferen as entre MDs produzidos por diferentes modeladores para um mesmo sistema Esses resultados favor veis incentivaram o prosseguimento da pesquisa e a realiza o de novos estudos experimentais agora mais formais e objetivando o teste das hip teses constru das ao longo do trabalho de tese 6 2 Estudo 1 EXP 1 ICs Granularidade e Cobertura Funcional 6 2 1 Defini o Planejamento e Execu o Este foi o primeiro quasi experimento realizado com a MIC ainda em uma vers o preliminar atual Nela o conceito de estado firme ou est vel se o 5 2 ainda n o havia sido estabelecido O particionamento do sistema em ICs utilizava exclusivamente o conceito de eventos aut nomos que no entanto inclu a tacitamente o conceito de estado firme Estudo experimental controlado mas com escolha n o aleat ria mas por conveni ncia dos participantes 116 O estudo teve por objetivo testar
3. sta classes Hem nome ciasseltem String Array lt Ciasse em ita servcas noma servico Sting Array lt Servico gt ita iem cobrancalconsuta nome String Array lt tem_cobranca gt ista_parcelasRecebimento at inicio Date dt fim Date boleto boolean nota boolean po rec Sting oCliente Cliente aClasseltem Classe_item Array lt Parcela_recebimento gt lista dispSanvicas cianta Ciente estado Sting paga porOcor boolean dia_vene int Avray lt Disp senvicos gt Percentual_comissao pere_comissAVista Percentual pare comissAPrazo Percentual minimo Currency v_maxima Currency dt Inicio Date t_corrente Date Percentual comissao Taxa indicafnome indico Sting Vl perendica Currency mesAno indica Sting Taxa indice pere comissAVista Currency pere_comissAPrazo Currency vi minima Currency vi maximo Currency dl inicio Date afim Date Tat comente Date Ap ndice 5 Planilha de Evolu o dos Modelos EC 3 Identifica o do s elemento s envolvido s na Tipo de An lise manuten o manuten o MUC MD 1 Modelo de Implementa o 09 06 08 Atributo dt corrente classes Inclus o As regras n o determinaram a persist ncia deste atributo Contudo Contrato Percentual comissao Despesa Tipo Al foi adicionado por motivos de seguran a Disp servicos Parcela despesa Por que a regra
4. 177 MCMENAMIM S M PALMER J F 1991 An lise Essencial de Sistemas 1 ed S o Paulo McGraw Hill MEYER B 1997 Object Oriented Software Construction on ed New Jersey Prentice Hall PTR MYLOPOULOS J CHUNG L YU E 1999 From Object Oriented To Goal Oriented Requirements Analysis Communications of the ACM v 42 n 1 January pp 31 37 NEILL C J LAPLANTE P A 2003 Requirements Engineering The State of the Practice IEEE Software v 20 n 6 November December pp 40 45 O REILLY 2008 SAFARI Books Online O Reilly Media Inc Disponivel em lt http safari oreilly com home gt Acesso em Novembro 2008 OMG 2008 UML 2 0 Specification Object Management Group Disponivel em lt http www uml org gt Acesso em Dezembro 2008 PENDER T 2003 UML Bible 1 ed Indianapolis Indiana USA Wiley Publishing Inc PINHEIRO F A C 2004 Requirements Traceability In Perspectives on Software Requirements Dordrecht The Netherlands Kluwer Academic Publishers pp 91 113 QUALIS 2008 Qualis Coordena o de Aperfei oamento de Pessoal de Nivel Superior CAPES Brasil Dispon vel em lt http www capes gov br avaliacao qualis gt Acesso em Novembro 2008 ROBERTSON S ROBERTSON J 1999 Mastering the Requirements Process 1 ed London Addison Wesley ROBERTSON S ROBERTSON J 2006 Mastering the Requirements Process gnd ed New J
5. recomend vel um treinamento mais prolongado e com um maior n mero de exemplos Para an lise das uniformidades algumas corre es nos modelos de alguns participantes foram necess rias No modelo do participante P2 foram encontrados dois erros referentes interpreta o das regras O primeiro erro foi o fato do mesmo ter aplicado a regra R4d sendo que ele j tinha aplicado a regra R4a desta maneira gerando opera es cujo nome come a com cadastrar que n o deveriam estar no modelo Al m do erro de aplica o da regra R4d o participante P2 n o aplicou a regra de consist ncia que verifica a utilidade de dados dos fluxos Isto resultou em um n mero pequeno de atributos o que foi percebido pelos experimentadores Por se tratarem de erros prim rios resultantes de falta de aten o na aplica o das regras o participante P2 fez a revis o do modelo corrigindo a aplica o da regra R4d e fazendo a verifica o correspondente regra de consist ncia O participante P3 introduziu a opera o Financeiro na classe do sistema sendo que a mesma foi retirada pelo pr prio participante durante a entrevista pois ficou claro para ele que essa opera o n o gerada por quaisquer das regras de deriva o Tamb m durante a entrevista o participante P1 percebeu que tinha aplicado a regra para deriva o de associa es de forma equivocada e eliminou algumas das associa es entre classes que tinha cria
6. A2 Inclus o de opera o construtora em classe de associa o An lise As regras n o determinam isso entretanto parece que as classes de associa o tamb m deveriam ter a sua opera o construtora Portanto temos uma incompletude omiss o na vis o MD do MIC Solu o Alterar a regra R4a para tamb m indicar a cria o de uma opera o construtora para cada classe de associa o existente no MD N mero de ocorr ncias 2 A3 Inclus o de atributo derivado com base na implementa o An lise a inclus o teve motiva o com base em requisitos de projeto e implementa o e portanto n o justific vel com base no MIC Conseqiientemente n o configura uma situa o de omiss o na vis o MD do MIC N mero de ocorr ncias 1 A4 Altera o do tipo do elemento do MD de atributo para opera o An lise falha na aplica o das regras decorrente principalmente de uma subespecifica o do dicion rio de itens elementares DI que deve dizer como se obt m a informa o Portanto a modifica o n o pode ser justificada com base no MIC e portanto ela n o configura uma situa o de inconsist ncia da vis o MD do MIC N mero de ocorr ncias 1 Compara o entre o par dos primeiros modelos de implementa o e o par dos modelos intermedi rios de implementa o Bl Introdu o de um identificador id cliente no fluxo de entrada de um IC e a correspondente associa o no MD An lise omiss o equ
7. es a ser detalhado na se o 5 3 Retomando a defini o apresentada na se o 4 3 4 um estado est vel do sistema um estado persistente alcan ado ao t rmino da execu o do processo subjacente a um UC representando o alcance de um objetivo de ator e significando a elimina o de qualquer necessidade de volta rollback a um estado anterior Por estado persistente entendemos um estado cujas informa es componentes persistem entre ativa es subsequentes do sistema causadas por eventos provenientes do seu ambiente Para esclarecer esse conceito de estado est vel consideremos um sistema do tipo ponto de venda PDV por exemplo aquele normalmente utilizado nos caixas de supermercados Um sistema desse tipo certamente incluir a fun o de registro dos itens adquiridos por um cliente bem como a de registro do pagamento efetuado pela compra Suponhamos inicialmente que o modelo de UCs do sistema inclua um UC distinto para cada uma dessas fun es O primeiro UC registrar itens n o deixa o sistema em um estado est vel pois se a compra n o for paga o registro da mesma precisa ser desfeito j que os itens voltam para a prateleira do supermercado ou seja 61 necess rio retornar o sistema ao estado anterior ao do registro Tal situa o n o ocorreria se um nico UC fosse respons vel por desempenhar ambas as fun es registro e pagamento pois o sistema estaria em um estado est vel ao t rmino do
8. o 5 2 e 2 Especificar com rigor formal a troca de informa es entre o sistema e seu ambiente se o 5 3 Os UCs assim obtidos foram distinguidos pelo nome de info cases ICs O NIO especializa o crit rio normalmente utilizado na MUC para a escolha dos UCs do sistema o UC ter valor para um stakeholder e principalmente constitui uma interpreta o mais precisa para esse crit rio considerado excessivamente subjetivo por v rios autores As duas provid ncias acima relacionadas fazem com que o modelo resultante de info cases MIC seja capaz de capturar ao mesmo tempo tanto informa es de 111 comportamento quanto informa es estruturais e de estado em um mesmo arcabou o conceitual constituindo assim um modelo integrado para a especifica o de requisitos Com isso poss vel obter um MD a partir do MIC como uma vis o extra da deste Conforme mostrou a se o 5 4 poss vel identificar um conjunto de regras e heur sticas para orientar e automatizar boa parte desse processo de extra o sobre a b c d e Para caracterizar a solu o constru da as se es deste cap tulo cont m an lises A qualidade das especifica es obtidas focando sua usabilidade legibilidade completude consist ncia rastreabilidade e manutenibilidade se o 5 5 1 A aplicabilidade da t cnica concluindo que a mesma se destina a sistemas de informa o se o 5 5 2 A rela
9. o aguardando retirada A notifica o cont m pelo menos as seguintes informa es identificador do livro t tulo do livro autor principal do livro primeiro autor pela ordem de apresenta o no livro data limite para a retirada do livro a data do pr ximo dia til seguinte a data do retorno do livro 2 O caso de uso retoma o passo seguinte ao da interrup o Sub fluxos Nao ha P s condi es N o h Pontos de Extens o P blicos N o h Requisitos Especiais N o h Cen rios Cen rio Livro sem reserva de empr stimo Fluxos b sico Cen rio Livro com reserva de empr stimo Fluxos b sico Trata exist ncia de reserva ativa Informa es Adicionais N o h Figura 2 2 Exemplo de descri o de um UC 13 2 3 Abordagens de Modelagem com Casos de Uso Muitos s o os formatos distintos j empregados na descri o de UCs COCKBURN 2005 contou 18 dezoito Eles variam desde a vers o textual livre em linguagem natural passando por formatos estruturados BITTNER SPENCE 2002 at propostas mais formais que sacrificam a facilidade de leitura pela precis o na comunica o do seu conte do menos comuns OMG 2008 As abordagens formais s o menos empregadas pois os UCs devem ser utilizados na comunica o com os stakeholders A linguagem natural propicia um entendimento universal e a contribui o dos stakeholders na concep o e valida o
10. o e maturidade 7 2 Principais Contribui es e Contrapartida A principal contribui o deste trabalho de tese foi a nosso ver a constru o de uma t cnica para modelagem de requisitos de sistemas de informa o com potencial para resolver alguns problemas existentes na t cnica tradicional e muito popular de casos de uso UCs potencial esse argumentado em bases te ricas e evidenciado em uma s rie de estudos experimentais realizados Sendo uma especializa o dos UCs a nova t cnica mant m v rios pontos fortes dos mesmos ao mesmo tempo em que inova propondo um crit rio mais objetivo para a escolha dos casos de uso de um sistema Essa provid ncia al m de resolver um problema reconhecido na literatura ou seja a excessiva subjetividade e ambigiiidade do crit rio tradicional baseado no valor do caso de uso para algum stakeholder possibilita um tratamento harmonioso entre o modelo de casos de uso e o modelo de dom nio do sistema onde este ltimo pode ser visto como uma vis o extra da do primeiro Al m disso a nova t cnica permitiu a defini o de um conjunto de regras e heur sticas capaz de fazer essa extra o de forma semi autom tica Assim evita se o problema da consist ncia entre modelos e promove se a uniformiza o dos MDs obtidos por diferentes modeladores para um mesmo sistema Al m dessa contribui o geral em termos mais espec ficos e pontuais podemos tamb m apontar outras contribui e
11. saldol_diaFF dt ref Date caixa boolean contasB Array lt Conta_bancaria gt Currency totAPagar_diaFF dt ref Dale caia boolean conlasB Array lt Conta bancaria Currency totARec_diaFF dt ref Date caixa boolean conta Array lt Conta banearia Currency saldoF_diaFF dt ref Date caixa boolean contasB Array lt Conta bancaria Currency balanca diaFF d ref Date Curency saldol perFF dt inie Date dt fim Date caixa boolean contasB Array lt Conta bancaria gt Currency totAPagar_perFF dt inic Date dt fim Date caa boolean contas Aray lt Conta bancaria Currency totARec_perFF dt inic Date dt fim Date caixa boolean contasB Aray lt Conta_bancaria gt Currency saidoF_perFF dt ini Date dt fim Date caixa boolean contasB Array lt Conta Bancarias Currency balanco_perFF dt inic Dat dt fim Date Currency vi recebido Currency ai receb Date vi desconto Currency ai venc Date vi parcela Currency obs parcela String boleto boolean nota boolean dt provPare Date bancaria void T Parcela_recebimento Eto cane e De Curar Tomah lerdo ce e gana cata ve Br Cos eds VARecDia caixas d ref Date Currency paga porOcir boolean reagan saldoFDia_caixan t ref Date Currency vl Mama Cury so caixas bancos d ini Date d fm Date dt comento Date cai
12. Acesso em Novembro 2008 JURISTO N MORENO A M LOPEZ M 2000 How to Use Linguistic Instruments for Object Oriented Analysis JEEE Software May June pp 80 89 JURISTO N MORENO A 2006 Basics of Software Engineering Experimentation Universidad Polit cnica de Madrid Spain KARKKAINEN T NURMINEN M SUOMINEN P et al 2008 UCOT Semiautomatic Generation of Conceptual Models from Use Case Descriptions In The IASTED Intl Conf on Software Engineering SE 2008 Innsbriick Austria February KNUTH D 1964 Backus Normal Form vs Backus Naur Form Communications of the ACM v 7 n 12 pp 735 736 KOSTERS G SIX H W WINTER M 2001 Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications Requirements Engineering Journal v 6 pp 3 17 KULAK D GUINEY E 2003 Use Cases Requirements in Context z ed Addison Wesley Professional 2003 LAMSWEERDE 1992 A The Meeting Scheduler System Problem Statement Universit Catholique de Louvain 176 LAMSWEERDE A 2001 Goal Oriented Requirements Engineering A Guided Tour In 5 IEEE Intl Symposium on Requirements Engineering RE 01 pp 249 262 Toronto Canada August LARMAN C 2004 Applying UML and Patterns An Introduction to Object Oriented Analysis and Design and Iterative Development 3 ed Prentice Hall LAUESEN 2002 S Software Re
13. COPPE UFRJ INFO CASES UM MODELO INTEGRADO DE REQUISITOS COM CASOS DE USO Michel Heluey Fortuna Tese de Doutorado apresentada ao Programa de P s gradua o em Engenharia de Sistemas e Computa o COPPE da Universidade Federal do Rio de Janeiro como parte dos requisitos necess rios obten o do t tulo de Doutor em Engenharia de Sistemas e Computa o Orientador es Cl udia Maria Lima Werner Marcos Roberto da Silva Borges Rio de Janeiro Dezembro de 2008 INFO CASES UM MODELO INTEGRADO DE REQUISITOS COM CASOS DE USO Michel Heluey Fortuna TESE SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ COIMBRA DE P S GRADUA O E PESQUISA DE ENGENHARIA COPPE DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESS RIOS PARA A OBTEN O DO GRAU DE DOUTOR EM CI NCIAS EM ENGENHARIA DE SISTEMAS E COMPUTA O Aprovada por Prof Cl udia Maria Lima Werner D Sc Prof Marcos Roberto da Silva Borges Ph D Prof Ana Regina Cavalcanti da Rocha D Sc Prof Guilherme Horta Travassos D Sc Prof J lio Cesar Sampaio do Prado Leite Ph D Prof Renata Mendes de Araujo D Sc RIO DE JANEIRO RJ BRASIL DEZEMBRO DE 2008 Fortuna Michel Heluey Info Cases Um Modelo Integrado de Requisitos com Casos de Uso Michel Heluey Fortuna Rio de Janeiro UFRJ COPPE 2008 XIV 200 p il 29 7 cm Orientadores Claudia Maria Lima Werner Marcos Rober
14. O tratamento da consist ncia e completude do DC em rela o ao MUC feito em parte pelo processo construtivo e em parte atrav s de verifica o uma vez obtido o DC N o est claro at que ponto a simples utiliza o de um gloss rio capaz de reduzir a ambigiiidade das descri es em linguagem natural a ponto de garantir um n vel satisfat rio de consist ncia Os stakeholders n o participam diretamente na elicita o e valida o das abstra es representadas no DC 36 No artigo um dos principais pontos que fica sem esclarecimento o grau necess rio de envolvimento dos analistas e stakeholders na verifica o e na valida o dos modelos Leitura Baseada em Perspectiva A Vis o do Projetista Orientada a Objetos MAFRA et al 2006 Os autores prop em uma t cnica denominada OO PBR Object Oriented Perspective Based Reading que tem por objetivo revisar um documento de requisitos segundo o ponto de vista ou perspectiva do projetista do sistema Essa t cnica fornece um conjunto de quest es que devem ser respondidas com base no documento de requisitos escrito em linguagem natural livre medida que o revisor percorre as etapas de constru o de um MD Dificuldades encontradas na constru o do MD podem significar a presen a de um defeito no documento de requisitos Portanto o processo visa apoiar a compreens o do documento de requisitos e a detec o de defeitos nele A t cnica prop e 3 formul rios
15. Portanto acreditamos que os livros levantados guardam sintonia com o que est sendo utilizado em diversos cursos de ERq pelo mundo afora ao mesmo tempo em que refletem o que h de mais novo no mercado editorial de literatura t cnica nessa rea De um total de 30 livros inicialmente selecionados 12 foram adquiridos ou obtidos em bibliotecas Os crit rios utilizados para essa escolha inclu ram a especificidade do livro em Engenharia de Requisitos b indica o do livro por parte dos pesquisadores monitorados c n mero de revis es e grau de excel ncia n mero de estrelas atribu do pelos revisores no site da Amazon e d ranking de venda do livro na Amazon Mais recentemente obtivemos o acesso online a v rios outros livros atrav s do servi o SAFARI O REILLY 2008 A despeito das limita es inerentes a se tomar apenas uma amostra do vasto material dispon vel na literatura sobre ERq acreditamos que os recursos obtidos com os levantamentos realizados d o uma vis o representativa do estado da arte e da pr tica da ERq e em especial da utiliza o do MUC e do MD no contexto da modelagem de requisitos 3 3 2 Propostas da Literatura Cient fica Nesta se o s o revistos alguns trabalhos cient ficos que tratam da utiliza o do MUC e do MD no processo de desenvolvimento de software e em especial na elicita o e modelagem de requisitos Os trabalhos foram selecionados dentre aqueles levantados segundo a metodo
16. e modificar requisitos LAMSWEERDE 2001 Um objetivo goal de sistema algo que deve ser obtido ou atingido e pode ser formulado em diferentes n veis de abstra o Cobrem tanto caracter sticas funcionais quanto n o funcionais Diferentemente de requisitos um objetivo pode em geral requerer a colabora o de v rios agentes para ser alcan ado Os objetivos devem ser refinados em sub objetivos que possam ser atribu dos a agentes individuais do software ou do ambiente Objetivos terminais se tornam requisitos no primeiro caso e hip teses no segundo Objetivos s o considerados importantes como um crit rio preciso de completude e pertin ncia de requisitos como um mecanismo natural para estruturar requisitos e como facilitador da detec o e resolu o de conflitos entre requisitos T m sido apresentadas evid ncias de que o conceito de objetivo est entre as for as motrizes b sicas para um processo de desenvolvimento sistem tico de requisitos LAMSWEERDE 2001 ERq com Casos de Uso O conceito de caso de uso originalmente elaborado por Jacobson JACOBSON 1987 JACOBSON et al 1992 foi incorporado na UML Unified Modeling Language OMG 2008 em 1996 para suprir uma lacuna at ent o existente neste padr o a falta de elementos essenciais que fossem centrados no usu rio Casos de uso representam como os usu rios ou atores interagem com o sistema PENDER 2003 Eles podem ser decompostos e reuti
17. is 44 3 4 1 O Problema da Inconsist ncia entre MDS ssessi insira teens sines 45 3 4 2 Quest es de Investiga o Lado al cast DO E a 46 345 Objetivo da Tse onre tinan ei qd AS DL ai 48 4 Causas dos Problemas e Enfoque de Solu o 49 AA InirOQUC O sas ais oi A OS 49 4 2 Causas dos Problemas eaae ia a RR a a 50 4 3 Enfoque d Solu o ss na asa ened Ron nes 53 4 3 1 Deduzindo um Enfoque de Solu o eee 53 4 3 2 A Solu o como um Modelo Integrado de Requisitos 55 4 3 3 Como Capturar Elementos do MD durante a MUC i 55 4 3 4 Restringindo o Espa o de Busca das Abstra es tis 57 ADIs GADO AD chris ta a ca lethal ait Salen ctr B81 O Rd ctu O US 2 58 44 Hipotese Gerala ren gd entr ad AL eoreasseer e E O A ES 59 5 A Solu o Info Cases sssssccccececscccccccccsccccccccccecececceccececececececececesesese 60 Sd CINOdU O as o ADS ASAS E 60 5 2 O Nivel Informacional de Objetivos s senl ess agrrteasandoiso safra sora dana tola 61 5 3 Interface Informacional dos Info Cases erre 66 5 4 Deriva o da Vis o MD do Modelo Integrado as 70 5 4 1 Categorias de Regras de Deriva o e o Papel dos Padr es Sintaticos 70 5 4 2 As Regras de Deriva o e seus Padr es Sint ticos 71 5 5 An lise da SOMCA0 saias ae sree o a Ti wens eos 83 5 5
18. o com a An lise Essencial pela influ ncia que ela teve na concep o inicial do NIO se o 5 5 3 A rela o com a Modelagem de Requisitos Orientada a Objetivos uma vez que os ICs tamb m representam objetivos dos stakeholders se o 5 5 4 O grau de automatismo poss vel na aplica o das regras de deriva o da vis o MD do MIC bem com a completude do MD produzido com elas se o 5 5 5 e Dois trabalhos extra dos da literatura mais diretamente relacionados com a solu o proposta nesta tese um deles porque tamb m adota um modelo integrado e o outro porque tamb m ataca o problema da inconsist ncia entre MDs se o 5 6 Essas e outras an lises te ricas contidas no presente cap tulo lan aram luz sobre as propriedades da solu o proposta e forneceram indicios de que vale a pena avaliar a mesma atrav s de estudos O pr ximo cap tulo 6 descreve os estudos realizados para avaliar experimentalmente a solu o proposta 112 6 Estudos Experimentais com o Modelo Integrado Este cap tulo descreve os estudos experimentais realizados com a modelagem de ICs MIC visando aprofundar a sua compreens o aperfei o la e testar a hip tese geral da tese se o 4 4 Inicialmente s o relatados os estudos precursores se o 6 1 realizados antes da aprova o da proposta desta tese Eles incluem experimenta o did tica e individual se o 6 1 1 e dois estudos de observa o um real
19. que define o MD como um dos artefatos que podem ser criados na fase de modelagem do neg cio Segundo ele os UCs estabelecem limites para o desenvolvimento do MD S o sugeridas tr s estrat gias para encontrar as classes do MD 1 Reutiliza o ou modifica o de modelos existentes 2 Utiliza o de listas de categorias de conceitos que s o listas pr elaboradas de conceitos relevantes em um dado dom nio e 3 Identifica o de nomes ou termos na descri o dos UCs e em outros documentos Com rela o a essa ltima estrat gia o autor alerta para a impossibilidade de um mapeamento mec nico nome classe e para os riscos decorrentes da ambigiiidade da linguagem natural O autor n o recomenda a inclus o de responsabilidades ou m todos no modelo de dom nio por considerar que essas s o no es relacionadas a software enquanto que o modelo de dom nio descreve apenas conceitos do mundo real e n o objetos de software A considera o das responsabilidades e m todos deve ficar segundo ele para a fase de projeto Entretanto ele ressalva que o termo modelo de dom nio pode assumir outro significado o da camada de dom nio de objetos de software isto a camada de objetos de software abaixo da camada de apresenta o ou da interface com o usu rio Essa camada de dom nio composta de objetos que representam coisas no espa o de dom nio do problema com m todos relacionados l gica de neg cio o
20. 66 Dicion rio de itens elementares de informa o A utiliza o de um gloss rio ou dicion rio de dados j uma pr tica comumente recomendada na modelagem com UCs BITTNER SPENCE 2002 Portanto basta acrescentar a especifica o da composi o dos fluxos da interface informacional ao texto da especifica o tradicional dos UCs se o 2 2 para se obter o modelo integrado proposto nesta tese A linguagem adotada para descrever a composi o dos fluxos da interface informacional praticamente a mesma utilizada anteriormente pela An lise Estruturada de sistemas YOURDON 1990 MAFFEO 1992 para especificar fluxos e dep sitos de dados Uma refer ncia mais recente para esse tipo de linguagem LAUESEN 2002 Ela utiliza um pequeno conjunto de s mbolos para a constru o de express es de dados O Ap ndice 1 desta tese descreve formalmente a sintaxe dessa linguagem em BNF GORN 1960 enquanto que a sua sem ntica descrita informalmente a seguir Os sinais gt e indicam respectivamente fluxo de entrada e fluxo de sa da de informa es do ponto de vista do sistema Uma informa o ou item em um fluxo pode ser elementar indivis vel ou composto agregado de outros itens elementares ou compostos Os itens compostos tamb m s o chamados de pacotes e indicados pelo s mbolo E Os itens elementares podem ser itens informados ou derivados Itens informados ou de entrada s o aqu
21. EC 1 se o 6 1 2 e outro n o EC 2 se o 6 1 3 Ap s a aprova o da proposta da tese foram realizados mais tr s estudos O primeiro deles um quasi experimento EXP 1 se o 6 2 investigou a granularidade e a cobertura funcional do MIC O segundo deles outro quasi experimento EXP 2 se o 6 3 tratou da granularidade e uniformidade dos MDs obtidos na modelagem com ICs e o esfor o demandado nessa modelagem Por fim o ltimo estudo um estudo de caso real EC 3 se o 6 4 testou as regras de deriva o e a adequa o dos MDs por elas produzidos O cap tulo termina com uma an lise sobre a cobertura dos estudos na valida o da hip tese da tese se o 6 5 6 1 Estudos Precursores Mesmo antes do fechamento de uma proposta de tese alguns estudos investigativos j haviam sido realizados Tais estudos se prestaram mais explora o e desenvolvimento da t cnica do que valida o formal de hip teses Eles tiveram um papel importante na prova de conceitos e na compreens o triagem e amadurecimento das id ias Os primeiros estudos foram individuais ou executados por alunos se o 6 1 1 Posteriormente empreendeu se um estudo que diferentemente dos demais foi um estudo de caso real se o 6 1 2 Por ltimo um estudo com profissionais serviu como investiga o preliminar sobre a uniformidade de MDs se o 6 1 3 Na poca desses estudos a MIC se encontrava em uma vers o preliminar na qu
22. MCMENAMIM PALMER 1991 Hoje com a dissemina o dos sistemas distribu dos dever amos acrescentar um canal de comunica o perfeito Dados armazenados produzidos pelo sistema ou capturados do mundo exterior necess rios execu o das atividades fundamentais do sistema MCMENAMIM PALMER 1991 pp 29 89 topologia podem ser considerados equivalentes Entretanto existem outras caracter sticas espec ficas de cada particionamento que os diferenciam Os eventos aut nomos da MIC s o basicamente os eventos da AE Ambos s o gerados pelo ambiente do sistema modelado e ambos pressup em certa independ ncia de ordem entre os eventos embora na MIC essa independ ncia seja especificada de uma forma mais precisa a saber o AE eventos diferentes podem ocorrer em qualquer seqii ncia MCMENAMIM PALMER 1991 pp 86 o MIC nenhuma suposi o geral pode ser embutida no sistema sobre o evento que antecede a um evento aut nomo A AE considera que a resposta do sistema a um evento deve deixar o sistema inativo Na MIC esse conceito ganha uma interpreta o precisa e um significado especial a resposta do sistema a um evento aut nomo deve deixar o sistema em um estado est vel ou seja um estado no qual inexiste qualquer necessidade de retorno rollback a um estado anterior mesmo se nenhum outro evento ocorrer A introdu o do conceito de estado est vel possibilitou a transforma o da MUC em um modelo integrado
23. O ator informa ao sistema sua necessidade de cadastrar um item de despesa 2 O sistema solicita as informa es necess rias de um item de despesa gt item despesa nome descri o 3 O sistema cadastra o item de despesa e emite uma mensagem de sucesso id item despesa 4 O caso de uso termina 187 Ap ndice 4 MD do SisConf EC 3 188 JUDE Evaluation ne J oaj Jo Fornecedor Parcela despesa Contato ee nome_contato Sting nome fomec Sting s vi pago Currency Tepi mec Sting oa Jo apago Date T enpi fomec Sting Arca empresa vi desconto Currency email contato Sting ogra fomec Sting Rasa at venc Date cargo contato Sting bairro Tomec String Tai Su vi parcla Currency cep fome Sting Area empresa aAresEmpPai Area empresa nome areaEmp Sng Area empresa dt prewenc Date Contatofnome contato Sting ll conalo String tel2_contato Sing email contato String cargo contato String Contato pe pres hag pe E estado fomec Sting 1 obs pagto Sting at inativ Date at corrente Date Fomecedor defnition i
24. O relacionamento use associa um ator e um UC Ele representa a comunica o do ator com o UC O relacionamento include inclus o fornece uma maneira de extrair se es comuns a duas ou mais descri es de UCs para transform la em um UC separado que pode ser referenciado pelos UCs de origem Ou seja o UC de origem deixar de ter aquela se o de descri o e no seu lugar conter uma refer ncia ao UC que passa a estar inclu do Operacionalmente isso significa que durante a realiza o do UC de origem ser inserido o comportamento especificado pelo UC inclu do Uma vez 10 conclu da a execu o do UC inclu do o controle retorna para o UC de origem no ponto seguinte ao da chamada O UC inclu do n o necessita de qualquer conhecimento sobre os UCs que o incluem O relacionamento extend extens o utilizado em situa es em que comportamento opcional ou de exce o deve ser inserido em um UC pr existente O prop sito original da extens o foi prover um mecanismo para especificar op es que poderiam ser acrescentadas a um produto ou servi o a partir de uma configura o b sica do mesmo como por exemplo a contrata o de um servi o de caixa postal ou de identifica o de chamadas para ser acrescentado a um servi o b sico de telefonia A caracter stica definidora de um UC de extens o que ele n o requer mudan as no UC que ele estende Isso significa que o UC estendido deve poder ser executado se
25. adequabilidade entre dois modelos enunciado por GLINZ 2000 Para ele um modelo adequando em rela o a outro modelo se 1 N o existirem contradi es entre as informa es presentes em cada modelo e 2 Nenhum dos modelos est parcialmente incompleto em rela o ao outro Ainda segundo GLINZ 2000 um modelo est parcialmente incompleto em rela o ao outro quando uma informa o nele requer uma informa o correspondente no outro a qual entretanto n o est presente nesse outro modelo Uma avalia o sobre o incremento no esfor o de modelagem resultante da solu o proposta neste trabalho de tese poder ser obtida comparando o tempo gasto na modelagem de um sistema utilizando a abordagem aqui proposta com o tempo gasto na modelagem do mesmo sistema utilizando a abordagem tradicional da AOO 59 5 A Solu o Info Cases 5 1 Introdu o Nosso objetivo no presente cap tulo mostrar como produzir como resultado de uma modelagem com UCs ligeiramente adaptada um artefato modelo de requisitos que incorpore rela es formais entre o MUC e o MD de forma a resolver os problemas apontados na se o 4 1 relativos utiliza o desses dois modelos na fase de requisitos A especializa o dos casos de uso UCs proposta nesta tese denominada info cases ICs Conforme antevimos na se o 4 3 3 as rela es formais estar o presentes na especifica o dos fluxos de informa o trocados e
26. ambigiiidades e omiss es 165 7 Conclus o Este cap tulo conclui o trabalho de tese A se o 7 1 apresenta uma vis o geral sum rio dos principais resultados obtidos a se o 7 2 lista as contribui es do trabalho e discute a principal contrapartida exigida a se o 7 3 apresenta as limita es da solu o proposta por fim a se o 7 4 apresenta reas e quest es para pesquisas ou projetos futuros vislumbradas durante a elabora o da tese 7 1 Vis o Geral do Trabalho Esta tese fez uma revis o da modelagem com casos de uso MUC levantando e analisando problemas apontados na sua utiliza o Entre eles dificuldades enfrentadas pelo modelador na utiliza o do modelo de classes de objetos de dom nio em conjunto com o modelo de UCs durante a fase de levantamento e modelagem de requisitos Um dos efeitos dessas dificuldades se manifesta na discrep ncia entre MDs produzidos independentemente por diferentes modeladores para um mesmo sistema A partir da an lise das poss veis causas das dificuldades foi proposta uma t cnica de modelagem denominada info cases ICs voltada para sistemas de informa o que pode ser considerada uma especializa o da t cnica de UCs Ela foi constru da com base principalmente em duas provid ncias 1 Defini o de um novo crit rio para o particionamento do sistema em UCs que estabelece um n vel espec fico de abstra o para isso Esse n vel foi denominado
27. capaz de capturar al m do comportamento externo j coberto pelo UC tradicional elementos estruturais e de comportamento interno e assim permitir a defini o de um conjunto de regras para derivar um MD como uma vis o do modelo integrado Na AE tal expediente n o existe Outra vantagem introduzida com a MIC a sinergia entre os crit rios de estados est veis e de eventos aut nomos Enquanto o primeiro possibilita uma triagem dos estados considerados na modelagem de dom nio estados persistentes e est veis o segundo evita que alguns desses estados passem despercebidos devido a uma decomposi o insuficiente do sistema nos seus UCs O MIC tamb m introduz atrav s do crit rio de todo IC levar ao alcance de um objetivo de algum stakeholder uma mudan a no significado dos processos oriundos do particionamento do sistema Eles deixam de ser meras atividades do sistema e passam a representar objetivos dos stakeholders De cara isso resulta em uma simplifica o importante para a elicita o dos requisitos do sistema os processos correspondentes s atividades custodiais s o desconsiderados pois n o representam objetivos dos stakeholders Essas atividades embora importantes na an lise de um sistema n o s o 90 relevantes para a especifica o dos seus requisitos Al m disso conforme vimos na se o 5 4 Deriva o da Vis o MD do Modelo Integrado poss vel determinar a informa o a ser persistida e o mom
28. experimentador que tirou as conclus es apresentadas na pr xima se o 6 4 4 6 4 4 Apura o e An lise da Evolu o dos Modelos Os dados coletados pelo analista sobre a evolu o dos modelos MIC e MD desde sua deriva o atrav s das regras at o t rmino da implementa o da primeira vers o do sistema foram analisados pelo experimentador para avaliar a adequa o da vis o MD do MIC produzida pela regras de deriva o Primeiramente o experimentador Essa evolu o est descrita na Se o 6 4 4 mais adiante 153 categorizou cada modifica o registrada analisou se uma das situa es prejudiciais adequa o do MD ocorreu Se o 6 4 1 e consolidou os resultados para extrair deles algumas conclus es conforme apresentado a seguir Compara o entre o par de modelos gerados pelas regras e o par dos primeiros modelos de implementa o Al Inclus o de atributos no MD na expectativa das pr ximas vers es evolutivas do sistema An lise O MIC constru do na perspectiva do modelo m nimo de requisitos ou seja apenas aquelas informa es necess rias s mudan as de estado do sistema e seu ambiente previstas nos ICs geram atributos ou opera es no MD A inclus o n o justific vel com base no MIC pois a funcionalidade correspondente n o foi nele especificada Portanto n o configura uma situa o comprometedora da adequa o da vis o MD do MIC N mero de ocorr ncias 7
29. maturidade dos mesmos por exemplo medindo o tempo de inser o deles no mercado de trabalho Outra sugest o redesenhar o estudo para que ambos os grupos utilizem as duas t cnicas Conforme ressaltado na introdu o deste estudo se o 6 2 1 o conceito de estado est vel ou firme ainda n o havia sido estabelecido por ocasi o da realiza o do estudo embora ele estivesse de certa forma embutido no conceito de evento aut nomo A separa o posterior dos dois conceitos decorreu de uma maior compreens o do que estava envolvido na pr tica de ICs tendo representado a explicita o de um 126 conhecimento t cito A partir da o ensino de como particionar um sistema em ICs ficou mais objetivo facilitando o trabalho do instrutor Como consequ ncia pode se esperar uma melhor assimila o por parte dos alunos Por isso bastante prov vel que uma replica o do estudo contando agora com esse novo elemento produza resultados ainda mais favor veis sua hip tese 6 3 Estudo 2 EXP 2 MD Granularidade Uniformidade e Esfor o Este estudo experimental foi desenvolvido no contexto de um trabalho de conclus o do curso de gradua o em Ci ncia da Computa o GON ALVES 2008a GON ALVES 2008b da Universidade Federal de Juiz de Fora UFJF sob a orienta o do autor da presente tese Esta se o apresenta um resumo do estudo em n vel de detalhe compat vel com o espa o dispon vel nesta monograf
30. ncia desse fen meno Tabela 6 11 Abstra es nos modelos de dom nio MDs Participantes Abstra esno Abstra es no Abstra es l Pi Pj modelo de Pi modelo de Pj coincidentes Unif Aj Ai Aj Ai P1 P2 12 9 8 0 6153 ao L 1 10 0 7692 P23 o 9 6 0 6000 eae de 9 7 0 4667 eo o 8 6 0 4000 Poe 2 8 5 0 4167 A compara o da uniformidade de abstra o entre os modelos de classes de cada grupo ou seja obtidos com uma mesma t cnica foi feita a seguir comparando se as m dias uatcs e Hua ucs Na se o 6 3 3 vimos que Unif A Unif A Unif A s HUoa ics i 3 i 3e Unif A Unif A Unif A 3 Hua vcs onde Unif A representa a uniformidade de abstra es entre os modelos produzidos pelos participantes i e j que aplicaram a mesma t cnica ou seja pertenceram ao mesmo grupo experimental sendo dada pela f rmula se o 6 3 1 A Unif A f ni ij A A A Assim com base nos valores da tabela 6 11 tem se 8 10 6 Luas 12 9 8 12 11 10 74 9 6 0 6153 0 7692 0 6 06615 Ua ICs mONO 3 3 Co e 13 8 6 9 8 5 _ 0 4667 0 4 0 4167 uses 0 4278 3 3 142 Portanto a uniformidade de abstra es entre MDs produzidos pelo grupo que utilizou ICs foi em m dia aproximadamente 55 maior do que entre os MDs obtidos com a t cnica tradicional de UCs Al m disso refor am esse resul
31. o 4 2 causa C3 Por isso caberia investigar um novo crit rio de particionamento menos subjetivo e capaz de gerar particionamentos uniformes Outros requisitos a serem satisfeitos pelo novo crit rio seriam o Ser uma especializa o do crit rio de valor de forma que todo UC elicitado corresponda a um objetivo a ser alcan ado por algum ator Isso necess rio para que a solu o de modelagem resultante possa ser vista como uma especializa o da t cnica de UCs o Gerar UCs em um nico n vel de abstra o Esse requisito visa combater a dificuldade dos modeladores para trabalhar apenas com UCs no n vel do sistema e para encontrar n veis apropriados de abstra o se o 3 4 1 o Gerar um conjunto de UCs que represente um particionamento funcional completo do sistema ou seja capaz de realizar toda a funcionalidade desejada para o sistema o Favorecer a determina o de uma vis o do MD a partir dos fluxos de informa o de cada UC A determina o desse novo crit rio come ou pela tentativa de atender o ltimo dos requisitos acima listados favorecer a determina o de uma vis o do MD a partir dos fluxos Ao longo da investiga o percebemos que se o particionamento do sistema em UCs for feito de forma que o conte do dos fluxos exprima principalmente informa es a serem persistidas entre estados est veis do sistema ent o poss vel estabelecer rastros formais entre os fluxos e os elementos constituinte
32. o que procuramos Tratar a causa Cl significa elicitar e especificar no mbito da MUC informa es formalmente identific veis sobre as abstra es de dom nio seus relacionamentos e representa o em atributos e possivelmente opera es que constituir o o MD O tratamento da causa C3 envolve construir uma orienta o precisa sobre os n veis de abstra o a considerar durante a MUC que promova uma redu o no espa o de busca de abstra es de dom nio a incorporar ao MD al m de uniformizar o n vel das mesmas Portanto como solu o para os problemas apontados disponibilizamos uma variante da MUC que incorpora as seguintes caracter sticas 1 Capacidade de capturar e especificar durante a modelagem com UCs informa es formalmente identific veis a partir das quais se possa derivar 53 automaticamente boa parte de um MD adequado para o sistema a ser constru do Maior orienta o sobre n veis de abstra o a serem utilizados na escolha dos UCs e das abstra es de dom nio para o MD Al m dessas caracter sticas a solu o proposta deve ainda atender os seguintes requisitos 3 CAUSAS DOS PROBLEMAS Legenda Tratamento direto Os elementos para a constru o do MD devem ser extra dos diretamente dos stakeholders de forma a evitar os efeitos das causas C2 e C4 pela minimiza o da interven o do modelador e da necessidade dos stakeholders terem de validar diretamente
33. rela o ao outro quando ele cont m todas as informa es que s o requeridas pelas informa es presentes no outro modelo Na t cnica de ICs boa parte dessa completude alcan ada por constru o ou seja decorre da deriva o do MD a partir das regras descritas na se o 5 4 2 conforme an lise realizada mais adiante se o 5 5 5 Outra avalia o desse aspecto de qualidade foi feita no cap tulo 6 dessa vez experimentalmente atrav s do Estudo 3 EC 3 se o 6 4 resultando em evid ncias de que o MD gerado com as regras adequado consistente e completo em rela o ao MIC Das 25 altera es sofridas pelo MD originalmente obtido pela aplica o das regras de deriva o ao longo do projeto e implementa o do sistema apenas 3 visaram corrigir situa es de incompletude omiss o no MD em rela o ao MIC Tabela 6 18 Duas dessas situa es resultaram de uma imprevis o da regra R4a respons vel pela inclus o de opera es construtoras nas classes e a outra situa o decorreu de uma omiss o da t cnica que deveria orientar o modelador a considerar a exist ncia impl cita 85 no MIC de consultas do tipo retrieve na hora de aplicar a regra R3a respons vel pela persist ncia de itens informados na entrada Conseqtientemente as devidas a es corretivas foram tomadas para que tais situa es n o voltem a acontecer A consist ncia outro aspecto de qualidade refor ado na t cnica de ICs
34. um para anotar as informa es relevantes constru o do MD outro para documentar as funcionalidades do sistema e mais outro para o registro dos problemas encontrados no documento de requisitos O MD resultante deve ser encarado como um modelo preliminar a ser eventualmente aperfei oado nas etapas subseqiientes de an lise do sistema A extra o de elementos para compor o MD feita com base em uma an lise ling stica simples onde nomes s o mapeados para classes ou atributos e verbos presentes em frases que envolvem classes em relacionamentos entre classes inclusive de heran a Al m disso existem diretrizes para obten o da multiplicidade das associa es e das funcionalidades do sistema An lise O trabalho reconhece a import ncia do MD para a compreens o dos requisitos de um sistema A obten o de elementos que comp em o MD feita com base em an lise ling stica de um documento escrito em linguagem natural livre o que acarreta uma maior depend ncia do modelador revisor pela necessidade de interpretar o documento e prejudica a automatiza o do processo Entretanto isso justific vel tendo em vista que o principal objetivo da t cnica a detec o de defeitos em especifica es de requisitos e n o a constru o do MD 8 N o necessariamente um MUC 3T A Tabela 3 1 agrega a informa o sobre a cobertura das propostas apresentadas no que diz respeito identifica o de ra
35. vel a esse intento E o que procuramos mostrar a seguir O diagrama de UCs de um sistema representa um particionamento funcional do mesmo onde cada UC pode ser visto como um processo o processo subjacente ao UC Uma vez que os UCs s o ativados por eventos externos provenientes dos atores esses 7 F ENS 19 processos s se comunicam atrav s de mem ria compartilhada Figura 5 1 2 Embora essa figura utilize a nota o gr fica de DFD o particionamento proposto nesta se o nada tem a ver com o particionamento preconizado na An lise Estruturada YOURDON 1990 63 UC 4 1 1 Processo 2 gt _ 7 C Processo 4 gt ce Figura 5 1 Topologia dos processos subjacentes aos UCs Analisando essa configura o de processos e seus fluxos de dados podemos concluir que se uma informa o entra em um processo ou UC e necess ria em outro processo UC ela dever fazer parte da mem ria compartilhada pelos processos para poder ser transmitida de um para o outro Igualmente se uma informa o produzida por um processo e necess ria em outro processo se n o puder ser reconstitu da nesse outro processo ela tamb m dever estar inclu da na mem ria compartilhada Ou seja qualquer informa o de entrada ou de sa da que deva ser transmitida entre processos deve ser inclu da na mem ria compartilhada Conforme vimos acima os tr s crit rios propostos produzem um pa
36. voco do modelador pois o identificador j tinha feito parte de uma vers o anterior do mesmo IC tendo sido 154 retirado sem justificativa v lida Portanto trata se de uma modifica o n o justific vel com base no MIC n o configurando uma situa o de omiss o da vis o MD do MIC N mero de ocorr ncias 1 B2 Inclus o de um atributo para um item de informa o que entra em um IC mas n o tem utiliza o especificada nele e nem em nenhum outro IC An lise itens nessa situa o podem significar duas coisas Primeiro que o item n o necess rio ao desempenho de nenhuma fun o do sistema e portanto j que o MD produzido pelas regras uma vis o minimalista do dom nio do sistema ou seja considera apenas a parte do dom nio que interessa ou necess ria para o desempenho das fun es do sistema o item n o precisa figurar em nenhum dos dois modelos MIC e MD Ou ent o pode significar que o item utilizado em um tipo de consulta que n o modelada ou melhor que fica impl cita no MIC S o consultas para a recupera o de informa es atributos de um objeto do dom nio tamb m conhecidas como opera es Retrieve segundo a nomenclatura CRUD Create Retrieve Update Delete Esse tipo de consulta n o tem o seu pr prio IC no MIC porque pode ser facilmente derivada a partir do IC que cria o objeto IC correspondente opera o Create Portanto nesse segundo caso existe uma omiss
37. 1 5 Requisitos na Modelagem de Sistemas Buscar uma defini o simples e consensual para requisito de sistema ou simplesmente requisito n o tarefa f cil A diversidade de defini es indica n o existir um entendimento claro n o amb guo sobre esse termo SODHI SODHI 2003 Para se ter uma id ia de qu o amplo pode ser o significado de requisito tomemos a defini o de SOMMERVILLE e SAWYER 1997 segundo a qual requisitos s o o Uma especifica o do que deve ser implementado o Descri es de como o sistema deve se comportar o Propriedade ou atributo que o sistema deve possuir o Restri o sobre o processo de desenvolvimento ou sobre o sistema E usual a classifica o de requisitos nos n veis de neg cio de usu rio ou de sistema Os requisitos de sistema s o ainda comumente subdivididos em funcionais e n o funcionais Requisitos devem ser completos corretos necess rios prioriz veis n o amb guos verific veis e poss veis Entretanto n o f cil conseguir tudo isso Os seguintes problemas ocorrem com fregi ncia na modelagem de requisitos SOMMERVILLE SAWYER 1997 o Os requisitos n o refletem as reais necessidades do cliente do sistema o S o inconsistentes ou incompletos o Sai caro fazer mudan as nos requisitos ap s eles terem sido acordados o S o mal entendidos entre os usu rios analistas e desenvolvedores 1 6 A Engenharia de Requisitos A Engenhar
38. 1 Qualidade das Especifica es Obtidas 0 cee eeeecceesceceteceteeeeeeeeseeeeaeens 83 5 5 2 Aplicabilidade do Modelo Integrado eceecceeceeseesseeeteceeeeeeeeeeseeeaeens 87 5 5 3 An lise Essencial Uma Id ia Precursora eeeeeeceesceseceseeneeeseeeeeeseenaes 89 5 5 4 O MIC ea An lise de Requisitos Orientada a Objetivos 92 5 5 5 Grau de Automatismo das Regras e Completude do MD Derivado 93 5 6 Trabalhos Mais Diretamente Relacionados ci ie 107 MO OProjeto ADORA ca a ad fi Sa 108 5 6 2 An lise Prop sito Alividade sacas an sus iaaiaa dao a TUS cega eeaADo end 110 5 7 Considera es Finais test seme sccsctvaesci DSL dad aaa ee 111 6 Estudos Experimentais com o Modelo Integrado 113 6 1 Estudos Precursores sem ra peida caia aca eine a a at era 113 6 1 1 Experimenta o Did tica e Individual 114 6 1 2 Estudo Precursor 1 EC 1 SIMEL c e ieeerremeeeera 114 6 1 3 Estudo Precursor 2 EC 2 1 Estudo da Uniformidade dos MDs 115 IX 6 1 4 Considera es sobre os Estudos Precursores ccccccsccecsseeesseeeesseeees 116 6 2 Estudo 1 EXP 1 ICs Granularidade e Cobertura Funcional 116 6 2 1 Defini o Planejamento e Execu o cccceeereereeecerereererereerssereranos 116 6 2 2 An lise Estat stica dos Dados Apurados cccecccecsseeseeeteceteeeeneeea
39. 220 HAY D C 2003 Requirements Analysis From Business Views to Architecture 1 ed New Jersey Prentice Hall PTR HENDERSON SELLERS B 1996 Object Oriented Metrics Measures of Complexity New Jersey Prentice Hall PTR IEEE IREC 2007 Intl Conferences on Requirements Engineering Disponivel em lt http www requirements engineering org gt Acesso em Dezembro de 2007 JACOBSON I 1987 Object Oriented Development in an Industrial Environment In ACM SIGPLAN Intl Conf on Object Oriented Programming Systems Languages and Applications OOPSLA 87 pp 183 191 Orlando Florida USA October JACOBSON I CHRISTERSON M OVERGAARD G 1992 Object Oriented Software Engineering A User Case Driven Approach 1 ed New York Addison Wesley 175 JACOBSON I ERICSSON M JACOBSON A 1994 The Object Advantage Business Process Reengineering with Object Technology 1 ed Wokingham England Addison Wesley ACM Press JACOBSON I BOOCH G RUMBAUGH J 1999 The Unified Software Development Process Addison Wesley Object Techonolgy Series JACOBSON I 2004 Use cases Yesterday today and tomorrow Software and Systems Modeling Journal v 3 pp 210 220 JACOBSON I NG P W 2004 Aspect Oriented Software Development with Use Cases 1 ed Addison Wesley Professional JUDE 2008 Change Vision Inc Tokyo Japan Disponivel em lt http www change vision com gt
40. Cada grupo utilizou apenas uma das t cnicas avaliadas neste estudo Os participantes que formaram o grupo A que utilizou ICs foram designados pelos n meros 1 2 e 3 J os participantes do grupo B que utilizou a t cnica tradicional de UCs foram designados pelos n meros 4 5 e 6 Os participantes do Grupo B UCs n o deveriam ter qualquer conhecimento em ICs para evitar uma interfer ncia indesejada nos resultados do estudo Como duas das pessoas selecionadas j tinham algum conhecimento em ICs elas foram alocadas no Grupo A ICs Devido ao n mero reduzido de participantes 6 era importante balancear os grupos ou seja faz los do 129 mesmo tamanho Para isso foi escolhido mais um participante para completar a composi o do Grupo A ICs A escolha foi feita com base no question rio de caracteriza o dos participantes Ap ndice 3 cujas respostas est o resumidas na Tabela 6 7 O principal crit rio utilizado nessa escolha foi o de fazer o Grupo B o mais homog neo poss vel Tabela 6 7 Caracteriza o dos participantes do estudo Esp Protsin nop Dominio Comito me Especializa o 0 5 anos Gradua o nte copo E Cp Ps 05anos MesrandoCOPPE 35 18 N o N o Academical UE N o PS 0 5anos Especilizando 03 02 N o N o Academica LE N o Gradua o A Tabela 6 7 apresenta para cada participante o tempo decorrido desde a formatura na gradua o F
41. IC obr IC6 Tipo Cl Faltou perceber durante a elabora o do MUC que essa informa o Controlar era necess ria na sa da do relat rio deste IC recebimentos vi aRecebe Opera o vl aReceber Inclus o Esse item foi adicionado no MUC devido a necessidade de sua r IC6 Currency classe Parcela recebimento Tipo C2 utiliza o no relat rio do IC6 Com a aplica o das regras R4b Controlar foi obtida uma opera o no MD recebimentos nome conta Exclus oTipo Essas informa es foram exclu das do MUC devido a falta de to C3 espa o na folha de emiss o do relat rio Entretanto elas foram tel vela mantidas no MD pois posteriormente pode se desejar criar um Ema ea a relat rio em que as informa es estar o presentes obs parcel a obs receb IC6 Controlar recebimentos Opera o Inclus o Opera o adicionada devido a necessidade de se ter uma listagem lista contratos estado Tipo C4 de todos os contratos existentes de um cliente N o foi determinada String Array lt Contrato gt partir das regras classe Cliente Para refleti la no MUC seria criado um IC para listar os contratos de um cliente para um estado escolhido ATIVO e INATIVO Opera o Inclus o Opera o criada devido a necessidade de se coletar do m dulo nr ocorItem nome servico Tipo C5 PCMSO o n mero de ocorr ncias de um determinado item de String nome itemCobr String int classe Cliente cobran a associ
42. MD em rela o ao MIC no que diz respeito a esse tipo de opera o A introdu o de opera o espec fica e exclusivamente dedicada ao c lculo do valor do item derivado se justifica pela proximidade sem ntica com o MIC e pela alta coes o que tal opera o apresenta Toda opera o presente no MD de um sistema deve ser vis vel e significativa do ponto de vista dos stakeholders o caso das opera es produzidas pela regra R4b Ent o caso uma opera o de c lculo de uma informa o elementar presente no MD n o corresponda a um item derivado n o persistido presente no MIC essa opera o seria desnecess ria para a especifica o da funcionalidade do sistema Portanto ela tamb m n o precisaria aparecer no MD Regra R4c fluxos de sa da Todo fluxo de sa da presente em IC cujo processamento n o produz mudan a de estado no sistema ou seja n o possui identificador gerado nem item persistido ou atributo de estado e n o altera o valor de algum item persistido tipicamente ICs de consulta e que n o se resuma a apenas um nico item n o lt og 49 F A 3 persistido d origem a uma opera o para produzir o fluxo Procedimento Designar uma opera o para cada fluxo de sa da de IC de consulta e que n o constitu do de apenas um item n o persistido atribuindo lhe um nome derivado do nome do fluxo Supondo que o MIC reflita corretamente os requisitos do sistema 4 J tratado na re
43. MIC lt gt MD R3a persist ncia itens sis gee 50 1 MICSMD informados de entrada R3b persist ncia itens dec ee 33 0 MICOMD informados de sa da R3c persist ncia itens derivados sim semi 33 0 MICSMD R3d aloca o de atributos cria o A n o semi 50 3 MIC MD de classe de associa o R3e atributos de estado sim auto 100 MIC gt MD R4a opera es construtoras sim auto 100 MIC gt MD a semi 100 R4b opera es itens derivados sim auto 50 0 MICMD R4c opera es de fluxo sim semi ne 0 MIC MD R4d opera es de mudan a de sel wee 25 0 MICSMD estado 20 R4e aloca o de opera es n o semi 66 7 MICMD Legenda Det A regra deterministica Aut A regra automatizavel Grau Grau de automatismo em valores percentuais PSint Numero de padr es sint ticos associados regra Compl Completude relativa entre os MIC e o MD resultante da aplica o da regra MICSMD O MIC completo em rela o ao MD mas n o vice versa MIC lt gt MD Ambos os modelos s o completos em rela o ao outro 5 6 1 O Projeto ADORA ADORA GLINZ et al 2002 GLINZ 2008 um acr nimo para Analysis and Description of Requirements and Architecture Trata se de um m todo de modelagem OO para software voltado principalmente para a especifica o de requisitos e tamb m para o projeto l gico da arquitetura de um sistem
44. SP 0 3426 11 0 1957 _ 0 2731 E agora com base nos valores da tabela 6 16 e desconsiderando as opera es construtoras tem se lugs 0 3510 0 5079 0 4689 Lava 0 3485 0 1979 0 2640 Portanto a uniformidade representacional entre MDs produzidos pelo grupo que utilizou ICs foi em m dia aproximadamente 95 maior do que entre os modelos obtidos com a t cnica tradicional de UCs ou 78 se forem desconsideradas as opera es construtoras 6 3 10 Considera es sobre o Estudo 2 O estudo produziu algumas evid ncias comparativas sobre o esfor o empregado em cada t cnica e sobre a granularidade e uniformidade dos MDs constru dos utilizando ICs e UCs Quanto ao esfor o empregado em cada t cnica o estudo indica que ele maior na t cnica de ICs sendo a diferen a da ordem de 24 em m dia Quanto granularidade o estudo indica que os MDs constru dos a partir de ICs apresentam menor granularidade do que os MDs constru dos a partir de UCs sendo essa diferen a em m dia de 8 148 Quanto uniformidade dos MDs produzidos com cada t cnica o estudo indica que os MDs constru dos a partir de ICs s o mais uniformes entre si do que os obtidos a partir dos UCs Isso foi verificado no n vel sem ntico conceitual pela compara o das abstra es existentes nos modelos de classes bem como no n vel representacional pela compara o dos atributos associa es e opera es envol
45. UC Consideremos agora um sistema de gerenciamento de restaurante com fun es similares a de registrar pratos e bebidas itens de consumo de uma refei o e a de registrar o pagamento da refei o No caso desse sistema dois UCs cada um desempenhando uma das fun es seria aceit vel do ponto de vista do crit rio de estados est veis Isso porque o registro dos itens de consumo de uma refei o deve ser mantido o 16 no sistema mesmo que a refei o nao seja paga Esse exemplo com o sistema Restaurante levanta uma quest o e se tivesse sido modelado com apenas 1 UC em vez de 2 Certamente um UC que desempenhasse as duas funcionalidades registrar itens e pagar a refei o tamb m deixaria o sistema em um estado est vel Entretanto teriamos perdido um estado est vel aquele que vigora ao t rmino da execu o do primeiro UC registrar itens Portanto se desejarmos garantir um particionamento completo ou seja capaz de explicitar todos os estados est veis do sistema precisamos de algo mais como crit rio de particionamento Para perceber o que falta basta analisar a diferen a entre as solu es que adotam um nico UC para os sistemas considerados Ambos UCs o do sistema PDV e o do sistema Restaurante necessitam de dois eventos externos para serem ativados e completar sua execu o mas existe uma diferen a entre os eventos que disparam a segunda parte do UC aquela respons vel pelo pagament
46. UC distinto daquele em que o item entrou no sistema deve ser persistido caso contr rio n o deve ser persistido E a Sone 72 R3b Determina o de persist ncia item calculado Para todo item elementar n o identificador de sa da e calculado cujo valor originalmente calculado for necess rio em outro UC se houver chance desse valor n o poder ser reproduzido nesse outro UC ele deve ser persistido sen o ele n o precisa ser persistido Durante o desenvolvimento do estudo percebemos a necessidade de considerar tamb m a persist ncia de itens informados presentes no fluxo de sa da de um IC que representem informa o hist rica n o pass vel de ser restaurada no IC Isso deu origem 71 gt O mesmo que informado 72 O mesmo que derivado 160 a uma nova regra que por quest es de organiza o recebeu a denomina o de R3b passando a regra R3b acima a se denominar R3c R3b Persist ncia item informado na sa da valor hist rico Todo item elementar n o identificador e informado presente no fluxo de sa da de um IC mS he aren SA a representando informa o hist rica cujo valor n o pode em geral ser restaurado nesse IC precisa ser persistido caso contr rio n o deve ser persistido cm eng 74 Regra para cria o de classes de associa o Na vers o anterior do conjunto das regras n o havia uma regra expl cita para a determina o das classes de associa es
47. a deriva o de elementos do projeto da interface H C Por exemplo os ICs s o naturalmente mapeados para op es do menu principal do sistema Identificadores se o 5 3 presentes nos fluxos de entrada dos ICs s o normalmente mapeados em combo boxes para sele o de um objeto A composi o dos fluxos de informa es e a ordem em que os itens de informa o aparecem neles orientam o projetista da interface H C na disposi o de informa es nas janelas ou telas do sistema A agrega o de itens em pacotes se o 5 3 pode indicar a oportunidade de se agregar os elementos de uma janela em pain is Elementos de retroalimenta o feedback ao usu rio podem ser derivados a partir da interface informacional dos ICs Elementos do di logo H C s o mais adequadamente subdivididos entre as diversas janelas do sistema com a ajuda dos objetivos organizacionais item 1 acima pois tais objetivos capturam as seq ncias de ICs que ocorrer o mais freq entemente quando o sistema estiver em uso Essas e outras possibilidades deveriam ser investigadas em detalhe luz dos principios e melhores pr ticas do projeto de interface H C 4 A MIC e Model driven Architecture MDA Segundo BERRISFORD 2004 duas quest es relacionadas a requisitos precisam ser respondidas para se construir um modelo que possa ser transformado em um sistema de processamento de dados 1 que unidades de trabalho os atores do sistema invocam ou requerem e 2 qu
48. a dificuldade para se encontrar as classes certas JACOBSON et al 1994 Das propostas analisadas apenas a de ROBERTSON ROBERTSON 2006 sugere explicitamente a an lise dos fluxos de informa es entre o processo de neg cio work e seu ambiente como forma de obten o das classes comum considerar que o modelo de dom nio composto apenas das classes seus atributos e associa es ficando a identifica o das opera es e outros elementos para a fase de an lise A despeito disso h pouca orienta o sobre como obter os atributos das classes e as associa es entre elas na fase de requisitos Para a obten o das opera es responsabilidades usualmente recomendam partir da descri o dos UCs e elaborar um diagrama de colabora o para cada um deles Sobre a verifica o da consist ncia entre o MUC e o MD Em geral a verifica o da consist ncia entre o MUC e o MD na fase de requisitos n o tratada pelos autores da literatura t cnica E prov vel que isso se deva escassez e imprecis o das rela es ou rastros identificados entre elementos dos dois modelos nessa fase Sobre a valida o do MD Pouco dito sobre a valida o do MD na fase de requisitos pelos autores estudados LAUESEN 2002 afirma que alguns usu rios n o s o capazes de aprender esse tipo de modelo e HAY 2003 sugere parafrasear o MD em linguagem natural visando torn lo mais acess vel aos stakeholders 3 4 Quest e
49. a m o de um modelo intermedi rio denominado diagrama UC Entity que mostra as entidades envolvidas em cada UC e permite a an lise da colabora o entre elas para o alcance do objetivo do UC Essas entidades se tornam as classes do MD Aos atores e stakeholders s o feitas perguntas pr estabelecidas para guiar a maior parte das etapas do processo de constru o que cobre a identifica o das classes entidades atributos features das entidades associa es refer ncias entre entidades e opera es resultantes da an lise da colabora o das entidades An lise A proposta oferece uma cobertura abrangente dos elementos do MD a custa do grande envolvimento dos analistas e stakeholders na interpreta o dos UCs nenhum rastro formal identificado entre os elementos do MUC e do MD o que impossibilita sua automatiza o Os autores inovam de certa forma ao deixarem de lado a descri o dos UCs e considerarem apenas nos objetivos dos UCs Talvez por isso n o tratem da valida o do MD obtido Entretanto tamb m n o apresentam evid ncias suficientes da efetividade dessa abordagem A consist ncia entre os dois modelos feita pela an lise da colabora o das entidades classes na realiza o dos UCs via diagramas UC Entity 7 Algo que desempenha um papel para o alcance do objetivo do UC 35 UCDA Use Case Driven Development Assistant Tool for Class Model Generation SUBRAMANIAM et
50. adotada para a granularidade visou mais cumprir um requisito formal do estudo ter uma hip tese formalmente enunciada do que propriamente testar uma teoria Como o particionamento pelo crit rio da t cnica tradicional de UCs muito vago e subjetivo fica praticamente imposs vel tom lo como base de compara o Portanto o objetivo desta parte do estudo foi apenas conhecer um pouco mais sobre os particionamentos produzidos por cada t cnica Em geral considera se que o aluno de um curso noturno possui perfil distinto do aluno de um curso diurno Por exemplo alunos de cursos noturnos muitas vezes trabalham durante o dia e em decorr ncia tem menos tempo para se dedicar aos estudos Isso pode justificar a decis o de alocar a t cnica de ICs para a turma noturna por corresponder a uma situa o menos favor vel hip tese do estudo Entretanto esse mesmo perfil tamb m pode significar que alunos de cursos noturnos possuem maior maturidade e experi ncia de trabalho at porque comum se observar alunos de mais idade neles Sob essa tica a aloca o da t cnica de ICs turma noturna pode ter favorecido a valida o da hip tese A caracteriza o dos participantes realizada no escopo deste estudo apenas mostrou que as turmas eram homog neas quanto experi ncia pr via nas t cnicas e no dom nio do sistema Por isso uma sugest o para novos estudos similares avaliar tamb m o rendimento acad mico dos alunos e a
51. al 2004 Os autores prop em derivar o diagrama de classes DC a partir dos UCs Para isso empregam an lise ling stica sobre dois documentos produzidos na fase de requisitos O primeiro deles um documento preliminar de requisitos escrito em linguagem natural irrestrita o segundo composto das descri es de UCs escritas em uma linguagem natural controlada produzidas a partir do documento preliminar com o auxilio da ferramenta proposta UCDA A solu o proposta capaz de sugerir v rios elementos do DC para confirma o pelo modelador objetos classes associa es mensagens entre objetos e responsabilidades a partir das mensagens Gra as identifica o das mensagens passadas entre objetos a ferramenta tamb m capaz de gerar diagramas de colabora o Na obten o dos objetos e das mensagens utilizado um gloss rio como forma de aumentar a consist ncia do DC gerado An lise O diagrama de classes DC derivado a partir dos UCs sem participa o ativa dos stakeholders Portanto h uma preval ncia do MUC sobre o DC na fase de requisitos A proposta cobre v rios elementos do DC gra as sofisticada an lise ling stica realizada automaticamente a partir da descri o em linguagem natural controlada dos UCs Para isso exige dos analistas e stakeholders a capacita o na utiliza o dessa linguagem Al m disso os elementos gerados precisam em geral ser validados por eles
52. banco d re Date Currency o Om 04 04 Caixa oao 1 aa ka Classe item fome caba Sting Profissional voce o saldo Currency o T nome_classetom Sing at inicio Date dt corrente Date Contrato 1 F Classe temaCiasseliomPai Classe tem nome classalem Sting Classe tem E E Trama indios Surg Caixalnome caixa Sing oResp Profissional voce ul saldo Currency dl inci Date dl corente Date Caixa dt corrente Date saldo inic dt ref Date Currency dt inicio Date saldo_fim dt_ref Date Currency Tat cancel Date ws o sat fii ot correntaGancal Date motivo cancel Sting at a Disp servicos obs cancel Sting ix juro Percentual carta boolean ma Percentual Contralodnome indico Sing dt_corrente Date Contato dt inicio Date contrat boolean dt termino Date cancelar_contr dt_cancel Date motivo cancel String obs cancel String carta boolean dt correnteCancel Date void a dia venc int Disp senicos temGobr valorados Array lt olemiGobranta em cobranca vlilemCobr Curency im ra int paga_porOcor boolean gt oCliente Ciente Contato Contrato oVendedor Profissional voce e Juros Percentual multa Percentual Tal parcelas it dados par Array lt al_venc Date parcsa Curency obs parcela Sing nota boolean boleto boclean gt Inicio Dat dt termino Date obs_dapSew String di comente Date dia_venc int Disp servicos Dip servicos temGobr valorados A
53. cada participante na elabora o dos modelos Exceto no quesito Experi ncia Profissional vide Tabela 6 7 se o 6 3 2 139 Tabela 6 9 Esfor o de cada participante Participante T cnica Esfor o Pi horas P1 ICs 7 21 po ICs P3 ICs 6 40 P4 UCs 5 35 P5 UCs 5 35 P6 UCs 5 50 A compara o do esfor o foi feita a seguir comparando se as m dias Me ics e Lle ucs Na se o 6 3 3 vimos que E E E Heos e E E E 2 o onde E representa o n mero de horas gastas pelo participante i Assim com base nos valores de E da Tabela 6 9 tem se 7 21 6 40 14 01 Leics 7 7 7 00 5 35 5 35 5 50 17 00 He vcs 3 3 5 40 Portanto a t cnica de ICs demandou em m dia aproximadamente 01h46min 24 a mais de esfor o para a elabora o dos modelos do que a t cnica de UCs Granularidade A Tabela 6 10 mostra os dados coletados sobre a granularidade dos modelos de classes obtidos pelos participantes com a utiliza o de cada uma das t cnicas investigadas Desconsiderado vide se o 6 3 8 140 Tabela 6 10 N mero de classes por participante Participante T cnica Granularidade P N de Classes C Pl ICs 12 P2 ICs 7 P3 ICs 9 P4 UCs 13 P5 UCs 9 P6 UCs 8 A compara o da granularidade dos modelos de classes foi feita a seguir comparando se as m dias L lt 1cse c
54. classe Atributos cpf fornec Inclus o As regras n o determinaram a persist ncia destes atributos cnpj fornec lograd fornec TipoAl Contudo eles foram adicionados pois posteriormente pode se bairro fornec cep fornec cidade fornec estado fornec classe Fornecedor desejar criar um relat rio de fornecedores Por que a regra n o determinou a persist ncia Porque essa informa o n o ser usada na vers o atual do sistema 191 Identifica o do s elemento s envolvido s na Tipo de An lise manuten o manuten o MUC MD e sim em uma vers o posterior Atributos tell banco tel2 banco Inclus o As regras n o determinaram a persist ncia destes atributos e nome ge FERE classe E Tipo Al Contudo eles foram adicionados pois posteriormente pode se Conta bancaria desejar criar um relat rio de contas banc rias Por que a regra n o determinou a persist ncia Porque essa informa o n o ser usada na vers o atual do sistema e sim em uma vers o posterior 2 Mode lo de Implementa o 17 06 08 id cliente Associa o entre as classes Cliente e Inclus o Faltou perceber durante a elabora o do MUC que essa informa o IC7 Cadastrar Contrato Tipo B1 era necess ria para relacionar um contrato a um cliente espec fico contrato no momento do cadastramento do primeiro Sem essa informa o os contratos estariam soltos depois de cad
55. cnica aceit vel Al m disso essa sobrecarga dever ser substancialmente reduzido quando estiver dispon vel uma ferramenta computacional adequada para apoiar a utiliza o da MIC automatizando boa parte da aplica o das regras de deriva o O estudo EXP 1 Se o 6 2 n o contribuiu diretamente no teste das hip teses em quest o embora tenha sido importante para a avalia o do particionamento do sistema por eventos aut nomos atrav s dos resultados obtidos sobre cobertura funcional Outros estudos poderiam ser feitos como por exemplo um para obter resultados estatisticamente significantes para a hip tese H3 uniformidade entre MDs A maior dificuldade conseguir um n mero suficiente de participantes para isso a n o ser que 164 se utilize estudantes Nesse caso a contrapartida pode ser abrir m o de uma aplicabilidade mais geral para os resultados a serem obtidos amea a validade externa Tamb m seria interessante um estudo que procurasse avaliar comparativamente UCs e ICs diretamente Tr s quest es a serem investigadas em tal estudo seriam por exemplo 1 qual das duas t cnicas UCs ou ICs produz modelos mais uniformes 2 qual das duas t cnicas produz modelos que demandam menos revis es durante o processo de valida o perante os stakeholders 3 qual das duas t cnicas produz modelos menos sujeitos a modifica es ao longo do desenvolvimento do sistema para se corrigir inconsist ncias
56. computar o valor de um item derivado n o persistido An lise n o seria necess rio incluir manualmente essa opera o se a regra R4b tivesse sido aplicada uma vez que ela faz exatamente isso Portanto n o se pode considerar como uma omiss o da vis o MD obtida pelas regras N mero de ocorr ncias 1 Conclus o A Tabela 6 18 resume o n mero de modifica es ocorridas no MD segundo o efeito sobre a adequa o desse modelo 156 Tabela 6 18 Nr de modifica es segundo o efeito sobre a adequa o do MD Efeito da modifica o Situa o Contagem N o afetam 22 Afetam Omiss o A2 B2 3 Afetam Inconsist ncia 0 Total 25 Pelos resultados apresentados na Tabela 6 18 vemos que apenas 3 modifica es afetam a adequa o da vis o MD do MIC obtida pelas regras de deriva o Essas modifica es A2 e B2 visaram corrigir situa es de omiss o no modelo que as regras n o foram capazes de evitar Consequentemente com base nas conclus es tiradas da an lise levada a cabo para as modifica es em quest o duas provid ncias se fizeram necess rias 1 alterar o enunciado da regra R4a respons vel pela cria o de opera es construtoras nas classes para que a mesma passe a indicar a cria o de uma opera o construtora para cada classe de associa o existente no MD e 2 incluir a orienta o de que o modelador deve considerar a exist ncia impl cita no MIC de consult
57. da consist ncia desses modelos Ambos os processos exigem um alto n vel de interven o do modelador A disparidade inconsist ncia dos MDs obtidos por diferentes modeladores a partir do MUC de um sistema SVETINOVIC et al 2005 O alto risco de uma valida o n o efetiva do MD pelos stakeholders decorrente da dificuldade dos mesmos para compreender e utilizar esse tipo de modelo LAUESEN 2002 e da indu o que eles sofrem para aceitar as abstra es escolhidas pelo modelador Acreditamos que os problemas n o s o independentes entre si Uma solu o para P1 provavelmente afetar de forma favor vel P2 e P3 Mais especificamente Rela o P1 P2 O aumento da cobertura autom tica na obten o do MD a partir do MUC P1 significar um decr scimo no n mero de elementos do MD que s oescolhidos pelo modelador sem uma maior participa o dos stakeholders Essa diminui o da interven o do modelador dever resultar em MDs mais uniformes entre si quando elaborados por diferentes modeladores P2 Rela o P1 P3 Com uma menor interven o do modelador P1 os stakeholders estar o menos sujeitos a serem induzidos a aceitar as abstra es criadas pelo modelador P3 A Figura 4 1 d uma vis o esquem tica desses problemas e dos relacionamentos entre eles No restante deste cap tulo identificamos e analisamos as causas dos problemas apontados se o 4 2 e a partir delas derivamos alguns princ pios
58. de requisitos d um panorama geral do estado da arte e da pr tica dessa utiliza o discute o problema alvo da tese e detalha os objetivos deste trabalho O Cap tulo 4 retoma o problema alvo para identificar e analisar suas causas Com base nessa an lise prop e um caminho para responder as quest es colocadas no cap tulo anterior e para construir uma solu o para o problema Termina apresentando uma lista de requisitos para a solu o e a hip tese geral da tese O Cap tulo 5 apresenta exemplifica e analisa a solu o proposta Em especial apresenta um conjunto de regras e heur sticas para a deriva o de MD a partir do MUC A an lise da solu o envolve a qualidade das especifica es produzidas a aplicabilidade da nova t cnica a sua rela o com outras t cnicas existentes o grau de automatismo das regras e a completude dos MDs delas derivados Tamb m s o discutidos dois trabalhos descritos na literatura mais diretamente relacionados com a solu o proposta O Cap tulo 6 descreve os estudos experimentais realizados ao longo do trabalho para avaliar a hip tese enunciada no Cap tulo 4 Esses estudos tamb m comparam a t cnica proposta nesta tese com a t cnica tradicional de UCs S o descritos tr s experimentos e dois estudos de caso al m de estudos preliminares O Cap tulo 7 fecha o corpo da tese apresentando suas conclus es principais contribui es limita es e trabalhos futuros
59. de N vel Informacional de Objetivos NIO 2 Ado o de uma linguagem semiformal para a descri o dos fluxos de informa o trocados entre o sistema e seus atores durante a realiza o dos UCs do NIO A especializa o dos UCs em ICs abriu a possibilidade de extrair do modelo de ICs MIC um modelo de dom nio MD adequado de forma semi autom tica Assim pode se ver o MIC como um modelo integrado de requisitos onde elementos comportamentais dos UCs e estruturais do MD s o capturados conjuntamente utilizando um mesmo arcabou o conceitual Foram enunciadas regras e heur sticas associadas para derivar um MD a partir dos ICs e uma s rie de estudos experimentais 76 ro Segundo crit rios definidos na tese 166 foram executados para explorar as hip teses do trabalho e produzir evid ncias de sua validade Al m de an lises te ricas que corroboraram as hip teses enunciadas na tese estudos experimentais produziram evid ncias favor veis s mesmas entre elas a de que a MIC induz uma maior uniformidade entre os MDs produzidos por diferentes modeladores para um mesmo sistema Embora seja desej vel a realiza o de novos estudos experimentais para refor ar as evid ncias obtidas consideramos que os j conclu dos produzem um corpo de evid ncias significativo que credencia a MIC como uma t cnica promissora o suficiente para motivar outros projetos visando explorar o seu uso e propiciar sua evolu
60. distribu do aos participantes Ap ndice 3 Alguns modelos produzidos pelos participantes n o continham todas as funcionalidades e dados que foram citados no sum rio bem como ocorreu a adi o de funcionalidades e dados que n o estavam no sum rio Em vista disso sugere se que futuros estudos incorporem mecanismos de uniformiza o da assimila o do conhecimento sobre o sistema e seu dom nio como por exemplo uma din mica de grupo O participante P2 n o conseguiu entregar os modelos na data prevista Talvez o treinamento ministrado n o tenha sido suficiente para que ele tivesse a mesma desenvoltura que os dois outros participantes do seu grupo Ele completou os modelos nos dias subsequentes sem ter contato com os demais colegas do seu grupo e sob supervis o dos experimentadores Em vista disso o tempo gasto pelo participante P2 na elabora o dos modelos n o foi considerado no c lculo da m dia dos esfor os do grupo A 6l O participante P1 reside em outra cidade Isso causou a demora na marca o das entrevistas 137 Ocorreram d vidas durante o treinamento e ao longo da constru o dos modelos tanto por participantes do grupo A como por participantes do grupo B Foi tomado muito cuidado nas respostas para n o interferir no resultado do estudo Estas eram d vidas referentes ao dom nio do sistema e ao uso das t cnicas correspondentes utilizadas no estudo Para tentar amenizar esse problema em futuros estudos
61. do MD por pessoas n o acostumadas a essa t cnica de modelagem problem tica O stakeholder t pico n o se sente a vontade para ler e interpretar um MD LAUESEN 2002 Ele parece se ressentir do alto n vel de abstra o e da linguagem formal utilizados nesse modelo A sa da a nosso ver apenas parcial parafrasear o MD em linguagem natural e com isso conseguir pontualmente que os stakeholders exprimam sua avalia o sobre os aspectos modelados Entretanto persiste outra preocupa o ainda maior sobre a possibilidade de uma valida o efetiva do MD pelos stakeholders O modelador n o a fonte mais confi vel para escolher as abstra es de dominio relevantes para o sistema Em geral ele n o det m ou domina o conhecimento necess rio para elicitar com seguran a essas abstra es Da a necessidade de valida o pelos stakeholders Mas uma coisa extrair dos stakeholders as abstra es que eles utilizam ou julgam mais relevantes e outra coisa apresentar a eles um modelo pronto contendo as abstra es identificadas pelo modelador e pedir que eles as validem Mesmo contando com o esfor o e boa vontade deles ao serem apresentados a um MD pr existente elaborado pelo modelador poss vel que eles sejam induzidos a aceitar as abstra es l representadas e abram m o facilmente talvez at inconscientemente das suas pr prias abstra es utilizadas no dia a dia do neg cio Isso ainda mais preo
62. dos UCs Nessa linha pode se utilizar formatos mais ou menos estruturados dependendo principalmente do est gio em que se encontra a defini o dos requisitos Inicialmente um formato menos estruturado pode facilitar o emprego de UCs na representa o ligeira de requisitos elaborada em paralelo com o processo de elicita o depois uma forma estruturada talvez seja mais adequada como instrumento de modelagem apurada an lise e documenta o dos requisitos obtidos Mas as propostas existentes de MUCs n o variam apenas no formato Elas se diferenciam tamb m quanto ao conte do e n vel de abstra o da descri o dos UCs De imediato uma varia o de conte do aparece nas formas estruturadas de descri o onde elementos que comp em a estrutura de algumas propostas de UCs est o ausentes em outras Outra varia o de conte do menos facilmente percebida decorre dos diferentes n veis de abstra o adotados na descri o do principal elemento dos UCs os fluxos de comportamento S o principalmente varia es ao longo de duas dimens es descritivas a do comportamento e a da informa o Todas as propostas de UCs colocam em primeiro plano o comportamento embora variando em grau de detalhamento Existem propostas de UCs que detalham todo o comportamento interno e externo enquanto outras se limitam a registrar o comportamento externo ou seja o comportamento observ vel do ponto de vista dos usu rios que interage
63. e requisitos que nortearam a busca de uma solu o para os problemas se o 4 3 Finalizando o cap tulo enunciada a hip tese geral deste trabalho de tese se o 4 4 49 Necessidade maior de valida o agrava gera Baixa cobertura autom tica p deriva o do MD ou Grande depend ncia da interpreta o do modelador para deriva o do MD a partir do MUC ou para a verifica o da consist ncia dual de p verifica o da consist ncia dos modelos P1 entre esses modelos Inconsist ncia eee entre MD s P2 contribui ae Valida o n o cair e efetiva do MD P3 contribui Figura 4 1 Problemas alvo 4 2 Causas dos Problemas A seguir s o apresentadas e discutidas as 4 causas principais dos problemas identificados na se o anterior A Figura 4 2 mostra a rela o entre os problemas e suas causas C1 Pobreza do MUC como fonte de informa es teis determina o do MD O MUC pobre em subsidios para a elabora o do MD Ou melhor ele pobre em elementos formais a partir dos quais se possa obter de forma segura e determinada um MD ainda que preliminar As informa es relevantes para o MD quando existem ficam escondidas nas descri es em linguagem natural dos UCs N o h durante a elabora o dos UCs uma preocupa o especifica com a captura e especifica o de elementos formalmente identific veis que possam dete
64. esses est mulos Entretanto quando essas rea es dependem da hist ria de est mulos e rea es anteriores isto da informa o 109 armazenada grifo nosso uma especifica o precisa das rea es apenas com cen rios se torna imposs vel Os objetos especificam a estrutura fun es e comportamento que s o necess rios para especificar adequadamente nos cen rios as rea es GLINZ et al 2002 ADORA difere da MIC em diversos aspectos Primeiro por buscar uma integra o mais abrangente envolvendo elementos estruturais comportamentais funcionais de intera o com os usu rios e de contexto de um sistema objetivando a gera o de diversas vis es em diferentes n veis de abstra o Em vez disso a MIC foca principalmente estrutura e comportamento Enquanto a MIC aplic vel a sistemas de informa o ADORA se presta a outros tipos de sistemas tamb m Mas a principal diferen a reside no fato de ADORA n o utilizar o MUC como base do modelo integrado como faz a MIC Neste sentido ADORA se distancia da UML enquanto o MIC pode ser considerado uma especializa o de um de seus modelos o MUC Al m disso em ADORA elementos dos diversos modelos s o explicitamente graficamente representados no modelo integrado enquanto que na MIC a nica manifesta o mais vis vel do MD no modelo integrado a presen a dos itens identificadores aqueles com nome iniciado por id os demais elementos do MD p
65. id ia de um modelo integrado No campo da especifica o OO de requisitos ele e seu grupo est o desenvolvendo uma linguagem e uma ferramenta denominada ADORA baseada em um modelo integrado GLINZ et al 2002 GLINZ 2008 Levando em conta os requisitos identificados para a solu o almejada neste trabalho de tese acreditamos que um modelo integrado para requisitos constru do a partir do MUC seja o caminho natural Tal modelo deve capturar tanto o comportamento externo do sistema interagindo com seus atores vis o da MUC quanto as estruturas classes de apoio seus relacionamentos informa es de estado e comportamento interno do sistema vis o do MD 4 3 3 Como Capturar Elementos do MD durante a MUC Cabe ent o a pergunta como fazer a integra o das duas t cnicas de modelagem MUC e MD em um mesmo arcabou o conceitual de forma a obter um modelo integrado Ou ainda de forma mais concreta como capturar as abstra es de dom nio e outros 55 elementos relevantes para o MD diretamente dos stakeholders durante a elabora o dos UCs Acreditamos que a chave para conseguir isso est em aproveitar um recurso de certa forma pouco utilizado na MUC os fluxos de informa o trocados entre os atores e o sistema durante a execu o de cada UC Conforme visto anteriormente na se o 2 3 Abordagens de Modelagem com UCs a maioria das propostas de modelagem de requisitos com UCs d pouca ou nenhuma aten o
66. l 29 66 Identificar fun es mais complexo elas n o s o concretas tang veis e est veis e em geral muitos s o os UCs a modelar Em contraste modelos 26 conceituais de dados consistem de objetos mais concretos tang veis e est veis mais f ceis de identificar e definir existem apenas alguns poucos construtores basicamente classes atributos e relacionamentos e em geral h apenas um diagrama a criar 2 Os analistas s o obrigados a considerar ao mesmo tempo aspectos funcionais e estruturais descri es de UCs incluem todos os tipos de intera es J se come arem pela modelagem conceitual de dados eles podem se limitar a aspectos relativos aos dados classes depois ent o ao fazerem a modelagem funcional as classes j estar o definidas e portanto as tarefas mais complexas se tornam mais f ceis Outra estrat gia seria desenvolver ambos os modelos em paralelo de forma interativa Na literatura existem propostas de elabora o dos dois modelos em paralelo JACOBSON et al 1994 GLINZ 2000 CONSTANTINE 2001 GLINZ 2000 por exemplo descreve uma abordagem para elabora o dos dois modelos em paralelo com foco na consist ncia entre eles Uma curiosidade em 1987 quando Jacobson prop s inicialmente o modelo de UCs segundo ele pr prio JACOBSON 2004 esse modelo incluia objetos de dominio entity domain objects para mostrar como os UCs podiam acess los E esses o
67. lise Estruturada Moderna Editora Campus YU E 1997 Towards Modelling and Reasoning Support for Early Phase Requirements Engineering In 3rd IEEE Int Symp on Requirements Engineering RE 97 Washington D C USA pp 226 235 January 180 Ap ndice 1 Sintaxe da Ling da Int Informacional de ICs A linguagem para a especifica o dos fluxos de informa o que constituem a interface informacional dos ICs tem a seguinte sintaxe formal em BNF Backus Naur Form GORN 1960 KNUTH 1964 lt Fluxo de dados gt lt Fluxo de entrada gt lt Fluxo de sa da gt lt Fluxo de entrada gt lt Nome de item elementar gt lt Nome de fluxo gt lt Express o de dados gt lt Fluxo de sa da gt lt Nome de item elementar gt lt Nome de fluxo gt lt Express o de dados gt lt Nome de item elementar gt lt Nome comum gt lt Nome de identificador gt lt Nome de fluxo gt lt Nome comum gt lt Pacote de dados gt E lt Nome de pacote gt lt Express o de dados gt lt Express o de dados gt lt Nome de item elementar gt lt Nome de pacote gt lt Express o de dados gt lt Express o de dados gt lt Express o de dados gt lt Express o de dados gt lt Limite inferior de repeti o gt lt Express o de dados gt lt Limite superior de repeti o gt lt Express o de dados gt lt Express o de dados gt lt
68. mesma forma sugere buscar os fatos do dominio para identificar os atributos das entidades e seus inter relacionamentos Para a valida o do modelo de dados ele sugere um parafraseamento utilizando a linguagem natural Use Case Modeling BITTNER SPENCE 2002 Os autores afirmam que o modelo de dom nio s deve ser criado se existirem relacionamentos relevantes entre os conceitos descritos no gloss rio o que acreditamos ocorrer para qualquer sistema n o trivial Nada dizem sobre como identificar as classes de dom nio ou seus atributos opera es relacionamentos etc Tamb m n o discutem a quest o da consist ncia entre os modelos e sobre a valida o do modelo de dom nio Senten as relacionando termos do dom nio 41 Use Cases Requirements in Context 2a edi o KULAK GUINEY 2003 Segundo o autor o nome das classes vem dos nomes que aparecem na descri o dos UCs Do conjunto assim obtido de classes candidatas devem ser removidos os nomes redundantes irrelevantes e que designam atributos de outras classes Nada diz sobre como obter as opera es das classes associa es entre elas e demais elementos do MD Tamb m nada dito sobre como verificar a consist ncia entre o MUC e o MD ou como validar o MD Applying UML and Patterns An Introduction to Object Oriented Analysis and Design and Interactive Development 3a edi o LARMAN 2004 O autor adota o Unified Process UP
69. mesmo sistema conforme observaram SVETINOVIC et al 2005 C3 Fraca orienta o sobre a busca no amplo espa o de abstra es do dom nio O espa o de abstra es de qualquer dom nio n o trivial muito amplo e pode ser observado sob diferentes n veis de abstra o Isso certamente traz dificuldades ao modelador na hora de escolher as abstra es que compor o o MD O MUC por n o prover elementos facilmente mape veis para o MD vide C1 n o um bom ponto de partida E para agravar o modelador n o disp e de uma orienta o precisa sobre os n veis de abstra o a considerar na elicita o dos UCs O nico crit rio geralmente recomendado para isso todo UC ter valor para pelo menos um stakeholder Infelizmente como observa ROBERTSON e ROBERTSON 2006 esse um crit rio por demais subjetivo Nesse contexto as observa es de SVETINOVIC et al 2005 sobre MDs produzidos por diferentes modeladores para um mesmo sistema MDs drasticamente diferentes focando subconjuntos de conceitos muitos distintos e com v rios conceitos em diferentes n veis de abstra o parecem nos uma constata o dos efeitos dessas defici ncias da MUC potencializados pela amplitude do espa o de abstra es do dom nio C4 Dificuldade dos stakeholders para utilizar o MD Conforme discutido na se o 3 4 2 o MD n o um modelo amig vel ao stakeholder t pico Ele normalmente n o se sente a vontade para ler e interpretar
70. n o identificador e de entrada em um IC utilizado direta ou indiretamente no c lculo obten o de um item de sa da desse IC Grau de automatismo 2 4 50 An lise de completude ap s a regra R3c Regra R3b Persist ncia item informado na sa da valor hist rico Todo item elementar n o identificador e informado presente no fluxo de sa da de um IC 2 dubai AB E a representando informa o hist rica cujo valor n o pode em geral ser restaurado nesse IC precisa ser persistido caso contr rio n o deve ser persistido Procedimento para aplica o da regra Em cada IC cada item elementar n o identificador e informado presente no fluxo de sa da do IC deve ser analisado pelo modelador para verificar se o valor que ele representa uma informa o hist rica n o pass vel de restaura o em geral naquele IC Se este for o caso o item constitui nova informa o que precisa ser persistida como atributo de alguma classe a ser determinada vide regra R3d e portanto deve ser marcado como tal caso contr rio se o item n o informa o hist rica ou sendo seu valor pode ser restaurado no IC ele n o deve ser marcado como um item a persistir Regra semi automatiz vel A es automatiz veis 1 Determina o dos itens elementares n o identificadores e de sa da em cada IC A es n o automatiz veis 1 Verifica o da condi o de um item elementar n o id
71. ncia interna de cada modelo bem como a consist ncia entre modelos Diferentemente da atividade de modelagem onde se lan a m o principalmente de abstra o na an lise ocorre acr scimo de detalhe muitas vezes pela reelabora o de um modelo j existente em n vel de detalhamento maior ou pela elabora o de novos modelos para capturar outras dimens es do sistema ou simplesmente para detalhar uma parte do mesmo que carece de uma melhor compreens o S o exemplos de t cnicas empregadas na atividade de an lise de requisitos Cen rios Diagrama de Atividades e Diagrama de Estados e Transi es Por fim na atividade de valida o de requisitos os modelos e especifica es produzidos s o discutidos pelos analistas e stakeholders para verificar se eles atendem os anseios desses ltimos Um exemplo de t cnica de valida o de requisitos a inspe o realizada atrav s de reuni es colaborativas WIEGERS 2003 1 7 A Pesquisa em Engenharia de Requisitos Um levantamento dos t picos de interesse divulgados no programa das confer ncias internacionais do IEEE sobre ERq IEEE ICRE 2007 de 2001 a 2007 evidenciou v rios t picos de pesquisa em ERq Dentre eles destacamos os seguintes de interesse mais direto para esta tese ERq Orientada a Objetivos A ERq Orientada a Objetivos Goal oriented Requirements Engineering utiliza objetivos para descobrir elaborar estruturar especificar analisar negociar documentar
72. o projeto da interface com o usu rio e na estrutura o do manual do usu rio Por fim eles tamb m se inserem na modelagem de neg cio uma vez que s o capazes de capturar processos de neg cio JACOBSON 2004 Portanto diferentemente do que acontece quando os requisitos s o modelados na forma de uma LRqs o artefato central do desenvolvimento o caso de uso e n o um artefato de an lise ou de projeto Essa promo o do artefato de requisitos significa o encurtamento da dist ncia representacional entre ele e os demais artefatos produzidos nas fases posteriores do desenvolvimento Embora isso n o dispense o tratamento espec fico usualmente dado 19 para se garantir uma adequada produ o captura e extra o de rastros PINHEIRO 2004 o rastreamento de requisitos entre os artefatos tende a ficar facilitado A despeito das vantagens acima apresentadas da modelagem de requisitos utilizando UCs preciso reconhecer que muitas vezes os desenvolvedores por exemplo em f bricas de software recebem uma LRgs pronta e antes de mais nada precisam valid la Embora essa valida o possa ser feita elaborando se o modelo de UCs do sistema pretendido isso custoso principalmente se a qualidade da LRgs for baixa Nesse caso preciso uma valida o preliminar e expedita dessa lista que pode ser feita por exemplo atrav s de um processo de revis o ou inspe o HE et al 2008 A partir da durante a modelagem co
73. o MD respectivamente As caracter sticas favor veis da MUC se o 2 4 1 devem ser mantidas Ou seja a modelagem proposta deve tamb m ser amig vel aos stakeholders e estar centrada neles e em seu julgamento de valor Ali s essas caracter sticas s o imprescind veis para possibilitar a captura diretamente dos stakeholders dos elementos necess rios deriva o do MD item 1 acima N o deve haver um aumento excessivo no esfor o de modelagem em compara o ao esfor o empregado na MUC A figura 4 3 resume esquematicamente a discuss o acima REQUISITOS DA SOLU O A MUC fornece poucos Ri Capturar durante a MUC j subs dios para a obten o do elementos formalmente MD identific veis para D ES Sn e a pai Dia E icin 6 Ei siado EERE RERI EI AEREE Paa EERTE constru o do MD EEEE E E Dificuldades dos Prover maior orienta o stakeholders comio MD 7 serem utilizados na MUC Fraca orienta o sobre a busca no espa o de R3 Promovera participa o elicita o dos elementos do Os modeladores s o l MD Manter as caracter sticas e eae te e Bo gp RO TE compreens o do dominio benef cios da MUC do sistema Ter custo esfor o adicional de modelagem aceit vel Tratamento indireto r s A Figura 4 3 Requisitos da solu o 54 4 3 2 A Solu o como um Modelo Integrado de Requisitos
74. o crit rio para o particionamento de um sistema em ICs baseado nos eventos aut nomos em compara o ao crit rio baseado no valor do UC para algum stakeholder utilizado na modelagem tradicional com UCs BITTNER SPENCE 2002 Mais especificamente o estudo visou avaliar comparativamente a cobertura funcional e a granularidade dos particionamentos obtidos com cada um desses crit rios Seguindo o esquema GQM WOHLIN et al 2000 a defini o do estudo Analisar os modelos de requisitos funcionais obtidos atrav s do particionamento pelo crit rio de eventos aut nomos utilizado na MIC e pelo crit rio tradicional baseado no valor do UC para algum stakeholder utilizado na MUC com o prop sito de caracterizar com respeito cobertura funcional n mero de fun es cobertas pelo modelo e granularidade n mero de casos de uso do modelo do ponto de vista do engenheiro de requisitos no contexto de estudantes do 4 per odo do curso de gradua o em Ci ncia da Computa o da UFJF aplicando crit rios de particionamento para modelar requisitos funcionais para um mesmo sistema de informa o como exerc cio em sala de aula M tricas Para os fins do estudo a cobertura funcional de um particionamento foi medida pelo n mero de fun es cobertas pelos UCs presentes no particionamento dentre uma lista de fun es extra das de uma especifica o preliminar do sistema texto em linguagem natural que serviu de ponto de p
75. o identificadores e de sa da em cada IC tamb m necess ria em R3b R3c 2 Atribui o de nome opera o produzida mesmo nome do item ou o nome ce 99 obtido pela elimina o do caracter e ado o do formato camel case para manter a legibilidade do nome Exemplo multa diaria ou multaDiaria A es n o automatiz veis 1 Verifica o da condi o de um item n o identificador e de sa da ser derivado no IC resultado reutiliz vel de R3c 47 Itens derivados persistidos n o geram opera es j que eles est o dispon veis como atributos na interface das classes 102 2 Verifica o de que um item derivado n o precisa ser persistido resultado reutiliz vel de R3c Grau de automatismo 2 2 100 ou 2 4 50 no caso n o sejam reutilizados os resultados das a es n o automatiz veis 1 e 2 obtidos com a aplica o da regra R3c An lise de completude Cada item derivado n o persistido representa uma propriedade de algum objeto cujo valor pass vel de ser derivado calculado a partir do valor de outras propriedades nos momentos em que ele necess rio Do ponto de vista do MD isso requer que alguma opera o da classe do objeto implemente o comportamento correspondente ao c lculo do valor da propriedade A regra R4b prop e que se introduza uma opera o espec fica na classe do objeto exclusivamente para o c lculo do seu valor e assim garante a completude do
76. o recomend vel que a Descri o de um item inclua n o apenas a sua defini o denota o mas tamb m como utilizado conota o LEITE OLIVEIRA 1995 Tabela 5 1 Dicion rio de itens elementares de informa o do UC 3 parcial Ator Cliente UC 3 Pedir a nota Nome Descri o Tipo Dominio id pedido Identificador do pedido da nota a emitir Nr Natural quant item Quantidade consumida de um item Nr Natural vl item Valor do consumo de um item Pre o unit rio x Moeda quantidade consumida do item cat item Categoria do item de consumo Texto prato bebida A visibilidade dos nomes de fluxos pacotes e itens elementares est limitada ao pr prio IC onde o nome aparece exceto para os nomes de itens identificadores aqueles com nome iniciado por id que s o vis veis em todos os ICs A decis o de restringir a visibilidade do nome de um item n o identificador ao IC onde ele aparece se justifica pela necessidade de permitir ao modelador flexibilidade e agilidade na hora de especificar a interface informacional dos ICs J como itens identificadores ocorrem em muito menor n mero do que os itens n o identificadores o benef cio de se ter apenas um nome designando a mesma abstra o ao longo de toda a especifica o mais relevante Daqui para frente utilizaremos o termo info case IC para designar um UC pertencente ao NIO com interface informacional especificad
77. o ser utilizado em IC algum nem mesmo no IC em que entrou no sistema IC 7 O grau de acerto do padr o sint tico foi de 11 19 58 Regra R3b Persist ncia item informado na sa da valor hist rico Todo item elementar n o identificador e informado presente no fluxo de sa da de um IC representando informa o hist rica cujo valor n o pode em geral ser restaurado nesse IC precisa ser persistido caso contr rio n o deve ser persistido No sistema Restaurante Figura 5 2 os itens elementares n o identificadores nome item e p item s o informados no IC 7 Atualizar o card pio e est o presentes como informa o hist rica no fluxo de sa da do IC 11 Solicitar rela o de notas penduradas Portanto esses itens precisam ser persistidos Eles representam informa o hist rica no IC 11 porque entre a abertura de um pedido IC 1 e a consulta da respectiva nota pendurada IC 11 um item de consumo pode ter seu nome e pre o unit rio alterados via IC 7 Regra R3c Persist ncia item derivado valor hist rico Todo item elementar n o identificador e derivado presente no fluxo de sa da em um TC representando informa o hist rica cujo valor n o pode ser restaurado nesse IC precisa ser persistido caso contr rio n o deve ser persistido No sistema Restaurante Figura 5 2 a condi o para a aplica o desta regra n o ocorre Embora os itens elementares n o identificadores e deri
78. os participantes trabalharam independentemente embora juntos em uma mesma sala Foram evitadas trocas de informa o que pudessem influenciar o resultado de cada um na obten o do MD O objetivo era ter tr s MDs obtidos independentemente por cada um dos participantes a partir da mesma especifica o de ICs Cada participante aplicou manualmente cada uma das regras na ordem da sua apresenta o construindo diretamente o MD com o apoio da ferramenta JUDE JUDE 2008 A aplica o das regras de deriva o ocupou aproximadamente 5 manh s de trabalho Uma id ia do porte dos MDs produzidos pode ser tirada pela contagem dos elementos presentes no MD do experimentador 25 classes 32 associa es entre classes 6 Logo ap s o t rmino da primeira etapa o outro analista da empresa que tinha participado da elabora o da MIC deixou a empresa 152 4 classes de associa o 81 atributos e 96 opera es de classe O Ap ndice 4 apresenta o MD final vers o obtida pela evolu o do MD inicialmente produzido pelas regras 66 durante o processo de implementa o do sistema A participa o do experimentador na primeira etapa do estudo elabora o do MIC e deriva o do MD foi crucial para que o mesmo pudesse acompanhar minuciosamente e registrar tudo que acontecia durante os trabalhos o que seria muito importante na hora de interpretar os dados coletados Uma vez conclu da a deriva o da vis o MD do MIC
79. que ele indicasse no MIC o identificador de um objeto dessa classe toda vez que o item de informa o for comunicado entre estados firmes do sistema Regra R3e Atributo de estado Para cada IC com interface informacional constitu da apenas de fluxo de entrada contendo exclusivamente um nico identificador deve ser introduzido um atributo de estado em uma das classes alcan adas por esse identificador Procedimento para aplica o da regra autom tico Regra automatiz vel A es automatiz veis 1 Verifica o da condi o do IC possuir apenas fluxo de entrada constitu do exclusivamente de um nico identificador Grau de automatismo 1 100 An lise de completude N o necessariamente todo IC que introduz informa o de estado a persistir ser mapeado pela regra R3d por n o se encaixar na condi o de aplica o dessa regra Portanto em geral o MD n o estar completo em rela o ao MIC no que diz respeito a atributos de estado Regra R4a construtoras Toda classe recebe uma opera o construtora Procedimento Designar uma opera o construtora para cada classe existente no MD determinada pela regra R1 Regra automatiz vel A es automatiz veis 1 Determina o das classes existentes no MD 2 Designa o de uma opera o construtora para cada classe 3 Nomea o da opera o construtora mesmo nome da classe Grau de automatiza o 1 100 101 An lis
80. se o 5 3 o tipo adequado de sistema para aplica o do modelo integrado o relacionamento dele com duas outras abordagens de an lise de requisitos de sistemas e 60 o grau de automatismo das regras e a completude dos MDs delas resultantes A se o 5 6 discute dois trabalhos mais diretamente relacionados extra dos da literatura Em seguida a se o 5 7 fecha o cap tulo apresentando algumas considera es finais 5 2 O N vel Informacional de Objetivos O objetivo dessa se o definir e caracterizar um novo crit rio para a elicita o dos UCs de um sistema que atenda aos requisitos identificados na se o 4 3 4 1 Ser uma especializa o do crit rio de valor tradicionalmente utilizado na MUC 2 Gerar UCs em um nico n vel de abstra o 3 Gerar um conjunto de UCs que represente um particionamento funcional completo do sistema e 4 Favorecer a determina o de uma vis o do MD a partir da interface informacional dos UCs Conforme colocado na se o 4 3 4 se o particionamento do sistema em UCs for tal que o conte do da interface informacional dos UCs exprima as informa es a serem persistidas entre estados est veis do sistema ent o poss vel perceber rela es formais entre os fluxos e os elementos constituintes do MD Obviamente para isso ser necess rio adotar um formalismo na especifica o da interface informacional dos UCs na medida necess ria representa o formal dessas rela
81. system particularly during the system requirements definition phase For example the level of automation achieved in proposals to generate the domain model from use cases or to verify the consistency between them is low or depends on the interpretation of the modeler Moreover it has already been seen that different modelers working independently produce very different domain models based on use cases of the same system This work analyzes these problems and proposes a specialization of the use case model to serve as an integrated requirements model from which a domain model can be derived Semi formal rules are presented to demonstrate this capacity as well as results of experimental studies carried out to assess the proposed model vii Sum rio Lista de PUD UE AS saciescavasncsasessenndstancnatosondsoxasanssaasessonekavaeenetevecssnestaveuschessesocsde xii Lista de TADeAS usas sadia rir ra ala xiii Lista de Siglas e A Dreviatlir as ccsscscasssscccaseccsedscsesasssosasacsecesssscncesssesecacees Xiv Des Dia Gr OG CAO stay sscseisesstsosscisessisessessserssesesse seison EE APRE Ds ARES a SEER e CR A 1 dl gt SGT ACB Os heo aeea ad ad Do lb caste ab l 12 O Problema sssini huka aa a aa a Aa a o aae 2 1 3 Objetivo e Enfoque da Sonics sons ics ede ieee a sai 3 N O Organiza o SR O O A aa a eas hae 3 1 5 Requisitos na Modelagem de Sistemas ie Aussies as etnies 4 1 6 A Engenharia de REGU IST OS aotdias ia asa IRS 5 1 7 A Pesquisa
82. todo o processo de software Os meios mais freqiientemente utilizados na elicita o s o entrevista reuni es facilitadas prot tipos e observa o direta O resultado da elicita o deve ser representado de alguma forma Isso feito na atividade de modelagem de requisitos onde as informa es elicitadas s o filtradas e utilizadas na elabora o de modelos Inicialmente essa modelagem se restringia a uma lista mais ou menos organizada dos requisitos do sistema Entretanto embora de f cil leitura e altamente flex vel essa t cnica abstrai em demasia a estrutura esperada para o sistema almejado dificultando uma verifica o da sua completude e consist ncia internas bem como da consist ncia em rela o aos outros modelos subsequentes de an lise Por isso h v rios anos a literatura especializada tem dado destaque a outro modelo o modelo de casos de uso PENDER 2003 que captura os requisitos do sistema ao modelar o comportamento e a intera o entre ele e seus atores Al m disso v rios autores t m sugerido a elabora o em paralelo de um modelo de classes de dominio visando uma maior explicita o e compreens o dos conceitos do dominio do sistema atrav s de uma primeira classifica o e estrutura o dos mesmos Na atividade de an lise de requisitos os modelos produzidos s o analisados para aperfei oar a classifica o e a estrutura o de conceitos e para verificar a completude e a consist
83. ucs Na se o 6 3 3 vimos que 5 Los Cit C C i 3 He vcs oe Cs onde C representa o n mero de classes existentes no modelo do participante i Assim com base nos valores de C da Tabela 6 10 tem se Hoos H z 93333 ligas La Portanto a t cnica de ICs produziu em m dia modelos com menos classes do que a t cnica tradicional de UCs aproximadamente 8 menos classes Uniformidade A Tabela 6 11 mostra os dados coletados sobre as abstra es considerando se os MDs dos participantes de um mesmo grupo tomados aos pares Uma abstra o representada por uma nica classe em um modelo pode corresponder a mais de uma classe em outro modelo Isso foi observado na compara o do modelo de P1 com os modelos dos demais participantes do grupo Por exemplo na compara o P1 P2 ficou evidente que a abstra o representada pela classe Pagamento no modelo de P2 est especializada nas classes Despesas e Cr dito Banc rio no modelo de P1 Com isso a contagem de abstra es no modelo de P2 em compara o 141 99 66 com o modelo de P1 considerou a classe Pagamento coincidindo duas vezes uma com a classe Despesas e outra com a classe Cr dito Banc rio Algo an logo ocorreu na compara o do modelo de P1 com o modelo de P3 Os n meros em negrito na Tabela 6 4 destacam a varia o na contagem de abstra es dos modelos de P2 e P3 na compara o com o modelo de P1 em decorr
84. um MD LAUESEN 2002 Isso constitui um s rio risco efetividade da valida o direta do MD pelos stakeholders 52 4 3 Enfoque de Solu o 4 3 1 Deduzindo um Enfoque de Solu o Uma poss vel solu o para os problemas indicados na se o 4 1 deve atacar as causas identificadas na se o anterior 4 2 Entretanto n o atacamos diretamente a causa C2 Defici ncia de conhecimento compreens o do dom nio pelos modeladores e a causa C4 Dificuldade dos stakeholders para utilizar o MD pois as provid ncias necess rias ao tratamento direto dessas causas extrapolam o tipo de solu o buscada nesta tese que a proposi o de uma forma diferente de modelagem de requisitos que possa resolver pelo menos em parte os problemas apontados na se o 4 1 No que diz respeito s causas C2 e C4 o que foi feito ao construir a solu o desejada tentar evitar ou reduzir os efeitos delas Por exemplo evitamos ou reduzimos os efeitos de C2 transferindo para os stakeholders a decis o sobre a escolha das abstra es e outros elementos que dever o compor o MD J os efeitos de C4 podem ser reduzidos se por exemplo diminu mos a necessidade dos stakeholders validarem diretamente o MD Passemos agora s causas Cl Pobreza do MUC como fonte de informa es teis determina o do MD e C3 Fraca orienta o sobre a busca no amplo espa o de abstra es do dom nio Essas causas s o atacadas diretamente pela solu
85. uma das classes alcan adas por esse identificador No MD do sistema Restaurante Figura 5 2 os atributos cancelado e pendurado foram introduzidos na classe Pedido classe alcan ada por id pedido pela utiliza o dessa regra nos ICs 2 Cancelar pedido e 5 Pendurar a nota respectivamente Opera es das Classes As opera es a serem inclu das no modelo de classes de dom nio dever o possibilitar a Realizar as mudan as de estado no sistema pela cria o e altera o de objetos regras 4a e 4d e b Realizar as mudan as de estado no ambiente do sistema pela produ o das sa das previstas na interface informacional representadas pelos itens derivados n o persistidos e fluxos de sa da regras 4b e 4c Regra R4a construtoras Toda classe recebe uma opera o construtora No sistema Restaurante essa regra determinou 5 opera es construtoras Pedido IC 1 Cliente IC 6 Item IC 7 Mesa IC 10 e Pedido Item nas respectivas classes hom nimas Regra R4b itens derivados Todo item derivado n o persistido produz uma E 32 opera o para calcular o seu valor No sistema Restaurante opera es v consumo vl realiz receita pend receita txServ receita total e vl pend as 5 primeiras provenientes do IC 9 e a Os itens calculados persistidos n o geram opera es pois est o dispon veis na interface da classe como atributos Itens derivados persi
86. 103 A compara o da uniformidade de atributos entre os modelos de classes de cada grupo ou seja obtidos com uma mesma t cnica foi feita a seguir comparando se as m dias uat ics e Luat ucs Na se o 6 3 3 vimos que Unmif At Unif At Unif At 3 gt Huarics T 144 Unif At Unif At Unif At 3 Luatucs onde Unif At representa a uniformidade de atributos entre os modelos produzidos pelos participantes i e j que aplicaram a mesma t cnica ou seja pertenceram ao mesmo grupo experimental sendo dada pela f rmula se o 6 3 1 At At At At Unif At Assim com base nos valores da Tabela 6 13 tem se 15 16 10 Hunics 28 24 15 38 24 16 24 14 10 a 0 4054 0 3478 0 3571 _ 9 479 3 3 ee en E E Z9 _ 0 3333 0 4186 0 3103 Uua ucs 34 22 14 28433 18 24 14 9 03541 Portanto a uniformidade de atributos entre MDs produzidos pelo grupo que utilizou ICs foi em m dia aproximadamente 5 maior do que entre os MDs obtidos com a t cnica tradicional de UCs A Tabela 6 14 mostra os dados coletados sobre as opera es considerando se as classes que representam abstra es coincidentes entre os modelos dos participantes de um mesmo grupo tomados aos pares Tabela 6 14 Opera es nos modelos de dom nio MDs Pares Opera es no Opera es no Opera es Pi Pj modelo de Pi model
87. 3 3 Formula o das Hip teses Devido ao pequeno n mero de participantes n o foram aplicados m todos estat sticos para a an lise dos dados coletados Mesmo assim procurou se utilizar na formula o das hip teses o mesmo formalismo normalmente requerido para a aplica o de tais m todos Com isso se no futuro o estudo for repetido com mais participantes a formula o adequada das hip teses j estar pronta Esfor o Hip tese Nula H E N o h diferen a no esfor o empregado para a obten o do MD a partir de ICs em rela o ao esfor o empregado na obten o do MD a partir de UCs Hip tese Alternativa H E O esfor o empregado para a obten o do MD a partir dos ICs maior do que o esfor o para se obter o MD a partir dos UCs Formalmente Ho E ur ics LUa vcs e Hi E e ics gt He ucs onde pics a m dia dos esfor os despendidos na obten o do MD a partir dos ICs e ur ucs a m dia dos esfor os despendidos na obten o do MD a partir dos UCs Os participantes 1 2 e 3 aplicaram ICs e os participantes 4 5 e 6 aplicaram UCs As m dias acima podem ser representadas pelas f rmulas a seguir onde E o n mero de horas gasto para obten o do MD pelo participante 1 E E E HE Ics 5 e 3 r iora ERa 3 Granularidade Hip tese Nula H G N o h diferen a na granularidade dos MDs produzidos com ICs em rela o queles produzidos utilizando UCs Hip tese Alternat
88. 84 Barcelona Spain September FORTUNA M H WERNER C M L BORGES M R S 2008b Info Cases Integrating Use Cases and Domain Models RT ES 719 08 COPPE UFRJ GLINZ M 2000 A Lightweight Approach to Consistency of Scenarios and Class Models In 4th IEEE Intl Conference on Requirements Engineering pp 49 58 Schaumburg IL USA June GLINZ M BERNER S JOOS S 2002 Object Oriented Modeling with ADORA Information Systems v 27 n 6 pp 425 444 174 GLINZ M 2008 ADORA Project Dispon vel em lt http www ifi uzh ch rerg research projects adora gt Acesso em Novembro GON ALVES V P 2008a Um Estudo Experimental em Modelagem de Requisitos de Sistemas de Informa o Monografia de Conclus o do Curso de Ci ncia da Computa o Universidade Federal de Juiz de Fora UFJF Juiz de Fora Brasil Fevereiro GON ALVES V P 2008b Empacotamento do Estudo Experimental sobre Modelagem de Requisitos de Sistemas de Informa o Suplemento da Monografia de Conclus o do Curso de Ci ncia da Computa o Universidade Federal de Juiz de Fora UFJF Juiz de Fora Brasil Fevereiro GORN S 1961 Specification Languages for Mechanical Languages and Their Processors A Baker s Dozen Commmunication of the ACM v 4 n 12 pp 532 542 GRUBER T R 1993 A Translation Approach to Portable Ontology Specifications Knowledge Acquisition v 5 n 2 pp 199
89. Aqui podemos considerar a consist ncia intermodelos entre o MIC e MD e a consist ncia interna dentro de cada modelo A consist ncia entre o MIC e MD est resolvida em parte pela caracter stica de modelo integrado da solu o alcan ada neste trabalho O mesmo pode ser dito com rela o consist ncia interna do MD j que ele resulta em grande parte da aplica o das regras de deriva o que n o produzem elementos inconsistentes entre si Resta ent o considerar a consist ncia interna do MIC Ela tamb m refor ada pois a especifica o semiformal da interface informacional dos ICs permite uma verifica o de completude funcional em um n vel de detalhe e precis o maiores do que no MUC possibilitando na descoberta de lacunas e omiss es que normalmente na MUC passariam despercebidas Por exemplo toda informa o que entra em um IC deve ser utilizada no processamento desse IC ou de outro qualquer caso contr rio a informa o n o precisa entrar no sistema ou ent o est faltando especificar sua utiliza o O estudo experimental EC 3 se o 6 4 tamb m produziu evid ncias da consist ncia do MD gerado a partir do MIC Das 25 altera es sofridas pelo MD originalmente obtido pela aplica o das regras ao longo das etapas de projeto e implementa o do sistema objeto do estudo nenhuma visou corrigir uma situa o de inconsist ncia do MD em rela o ao MIC Tabela 6 18 Outro aspecto de qualidade a c
90. Cs prov em condi es limites para uma modelagem de dom nio adequada Software Requirements Styles and Techniques LAUESEN 2002 Este autor afirma que a an lise da informa o de dom nio produz um modelo capaz de sobreviver implementa o do sistema com pequenas modifica es Entretanto pouco ou nada acrescenta sobre esse modelo a n o ser que a especifica o de opera es no 10 A atividade de neg cio para a qual o usu rio deseja o apoio do sistema 40 n vel de dom nio resulta em v rias opera es que n o podem ser aproveitadas posteriormente na fase de projeto Quanto valida o do modelo de dom nio o autor considera que alguns usu rios n o s o capazes de aprender o modelo E R e que modelos orientados a objetos n o s o para valida o pelos usu rios eles consideram esses modelos n o intuitivos estranhos Requirements Analysis From Business Views to Architecture HAY 2003 O autor d um destaque especial ao modelo de dom nio ao afirmar que fundamentalmente as regras de neg cio dizem respeito aos dados elas restrigem que dados podem ou devem ser criados no decorrer das opera es de neg cio Segundo ele a elicita o e defini o das regras de neg cio devem ser realizadas em conjun o com o desenvolvimento de um modelo de dados Sobre a identifica o de classes entidades o autor sugere procurar os termos Sas EA Ee 1 utilizados no vocabul rio do dom nio Da
91. ERq atrav s dos seguintes diret rios dispon veis na Web Google IEEE Conferences ACM IFIP DB and LP Conferences and Workshops All Conferences Directory e Qualis CAPES Dos 60 eventos examinados 35 foram selecionados com base na sua classifica o CAPES Qualis QUALIS 2008 para o levantamento peri dico de artigos de interesse V rios desses eventos s o confer ncias que promovem diversos workshops onde s o publicados trabalhos em ERq Esses workshops tamb m s o considerados nos levantamentos Peri dicos A busca por peri dicos que publicam trabalhos em ERq foi empreendida a partir dos sites de grandes editores de peri dicos cient ficos em computa o EEE Computer Society ACM Springer Elsevier John Wiley IEE e World Scientific Al m disso utilizamos tamb m o diret rio Google e a lista de publica es de pesquisadores em ERg dispon veis nas respectivas home pages Para o acompanhamento atrav s de levantamentos realizados frequentemente foram selecionados 27 peri dicos com base na especificidade do peri dico em Engenharia de Requisitos classifica o CAPES Qualis QUALIS 2008 e fator de impacto CITESEER 2003 Pesquisadores Outra fonte de pesquisa utilizada nos levantamentos foi a home page de pesquisadores da Engenharia de Requisitos e reas afins Um dos objetivos foi conhecer o trabalho dos principais pesquisadores em ERq Al m disso v rios recursos adicionais est o dispon veis a partir de
92. Foi preparado um question rio para a caracteriza o dos participantes cobrindo o tempo transcorrido desde a formatura deles na gradua o o seu perfil acad mico experi ncia profissional conhecimento anterior no dom nio do sistema pr tica de modelagem nesse dom nio conhecimento e experi ncia anteriores em UCs e ICs entre outras coisas Este question rio pode ser visto no Ap ndice 3 O estudo foi realizado na empresa em que trabalhava o autor do trabalho de conclus o de curso e p de contar com a infra estrutura l existente O treinamento foi ministrado em sala pr pria com computador datashow e quadro branco Durante a execu o do estudo propriamente dito cada grupo ocupou uma sala distinta com um computador para cada participante Os participantes utilizaram a ferramenta Visual Paradigm VP 2007 previamente instalada nos computadores para a elabora o do modelo de requisitos UCs ou ICs e do respectivo MD do sistema 6 3 6 An lise pr via da Validade Durante o planejamento do estudo foi feita uma an lise visando detectar e debelar poss veis amea as validade do mesmo Nesta se o apresentado o resultado dessa an lise para cada tipo de validade interna de constru o de conclus o e externa Outra quest o considerada foi que uma prioridade deveria ser atribu da a cada tipo de validade tendo em vista que muitas vezes um expediente para favorecer um tipo de validade pode prejudicar o
93. L Para explorar o comportamento da MIR em um sistema real e de maior porte foi empreendido o estudo de observa o relatado nesta se o Esse estudo de caso envolveu uma equipe com 1 engenheiro de requisitos 4 analistas programadores e 4 especialistas de dom nio no desenvolvimento de um sistema web multiusu rio para apoiar as atividades de uma empresa de medicina e engenharia de seguran a do trabalho O sistema SIMEL SIstema de MEdicina e Engenharia Empresarial foi desenvolvido pelos analistas em PHP e MySQL diretamente a partir do modelo informacional elaborado pelo engenheiro com o apoio e valida o dos especialistas constitu do de 30 objetivos informacionais totalizando 40 p ginas de especifica es O desenvolvimento demandou 4 meses de trabalho Consultas informais aos desenvolvedores especialistas e stakeholders realizadas durante o estudo e ap s o seu t rmino evidenciaram uma impress o positiva dos mesmos sobre a MIR e o sistema desenvolvido Alguns aspectos que valorizam os resultados obtidos s o a Nenhum dos analistas tinha conhecimento e experi ncia anteriores na MIR e no Realizados pelo autor desta tese 5 Aproximadamente 45 tabelas 100 000 linhas de c digo escrito gerado 114 dominio da aplica o b Os analistas trabalharam os 3 primeiros meses praticamente sem contato presencial com o engenheiro de requisitos sendo a comunica o realizada por escrito via um software do tipo ins
94. N et al 1992 afirmam que o MD serve de suporte para o desenvolvimento do modelo de requisitos sendo uma de suas partes juntamente com o MUC Segundo eles o MD ajuda a desenvolver uma terminologia comum a ser utilizada nos UCs o JACOBSON et al 1994 afirmam que para se obter um bom resultado necess rio trabalhar interativamente entre os dois modelos o LAUESEN 2002 d a entender a import ncia de se modelar a informa o est tica do dom nio do sistema desde os primeiros momentos do levantamento de requisitos ao afirmar que a an lise da informa o do dom nio produz um modelo que pode sobreviver implementa o do sistema com poucas modifica es e que o mesmo n o se aplica modelagem das fun es do sistema 25 BITTNER SPENCE 2002 afirmam que o modelo de dom nio s deve ser criado se existirem relacionamentos relevantes entre os conceitos descritos no gloss rio Em nossa opini o este o caso para qualquer sistema n o trivial Portanto os autores confirmam mesmo que indiretamente a necessidade de se elaborar o modelo de dom nio em paralelo com o modelo de UCs Para HAY 2003 regras de neg cio s o sobre dados elas restringem que dados podem ou devem ser criados no curso de uma opera o de neg cio A descoberta e a defini o de regras de neg cio devem ser realizadas em conjun o com o desenvolvimento de um modelo de dados ROBERTSON ROBERTSON 2006 consideram um papel explorat rio pa
95. Nome de pacote gt lt Nome comum gt lt Nome comum gt lt Caracter gt lt Caracter gt lt Nome comum gt lt Nome de identificador gt id lt Nome comum gt lt Caracter gt lt Letra gt lt Digito gt lt Letra gt A a B b Clc lt Digito gt 0 1 2 3 4 5 6 7 8 9 181 Ap ndice 2 Tabelas do Sistema SIMEL EC 1 1 1 cod_usuario PK nome_usuario login senha id fonteGeradora PK id caract risco FK fonte geradora via penetracao controles existe meio propagacao tempo exposicao ruido max unid exposicao tipo exposicao id ser PK id emp FK dt inicSery espec serv coord mel nome coord crm coord unid mel nome contato descr contato email2 fax dt correntelnicio dt termSen mot_termSer dt correnteTermino id contato PK id emp FK nomeContato descrContato telContato celContato emailContato faxContato id plano pemso PK id emp FK tem mapaRiscos orientacoes prazo consultas valCli dem acordoPrazo dem perCli outra perCompl outra just perCli cod ativ co PK descr_ativEco grisco_ativEco id_setor PK id_emp FK nome ambiente setorExt unidEstab setorP ai nr trabSetor excluido id_emp PK cnpj razao fantasia estab unidEstab1 unidEstab2 nome cei lograd nrLograd complEnd bairro cidade estado cep site inserEst onae nrTrab ativBasica nome resp tel resp cont ppra setores mov trab id setor PFK id movTr
96. Para GLINZ 2000 uma modelagem que emprega mais de uma t cnica pode ser realizada tanto como uma cole o de modelos distintos quanto como um nico modelo integrado com diferentes vis es Em uma cole o de modelos cada modelo tratado criado mantido e usado separadamente Segundo ele embora a separa o entre os modelos pare a inicialmente facilitar a utiliza o dos mesmos tal facilidade obtida custa da qualidade da modelagem como um todo pois a consist ncia entre os modelos dif cil de ser alcan ada Por outro lado um modelo integrado prov um nico arcabou o conceitual capaz de comportar todas as informa es que necessitam ser capturadas E atrav s do mecanismo de gera o de vis es o modelador pode ainda trabalhar em um aspecto isolado de um dos modelos cobertos na integra o Portanto trabalhar com um modelo integrado confort vel para o modelador Ainda segundo o autor por defini o em um modelo integrado n o existe qualquer sobreposi o conceitual as vis es podem se sobrepor mas elas s o geradas a partir de uma nica base comum As regras de consist ncias s o constru das uma vez por todas dentro do pr prio modelo sendo portanto parte integrante dele O autor ainda menciona que praticamente todas as abordagens de modelagem OO est o na categoria de cole o de modelos sendo a UML o exemplo mais proeminente Segundo ele a Engenharia da Informa o MARTIN 1990 est baseada na
97. Tipo de An lise manuten o manuten o MUC MD obs cancel e carta classe Tipo Al Contudo eles foram adicionados pois posteriormente pode se Contrato desejar criar um relat rio de contratos cancelados Por que a regra n o determinou a persist ncia Porque essa informa o n o ser usada na vers o atual do sistema e sim em uma vers o posterior IC23 Atributo dt fim classe Inclus o As regras n o determinaram a persist ncia deste atributo mas ele Consultar Percentual comissao Tipo A3 foi adicionado comiss es de por proporcionar uma facilidade maior de implementa o visto que vendedores se dt fim estiver preenchida ser poss vel saber que o percentual de 09 06 08 comiss o n o mais v lido poss vel obter esta informa o no momento em que se informa um novo percentual de comiss o A Obs Os data de fim do percentual de comiss o vigente at ent o dt fim valores de ser a data de in cio do novo percentual de comiss o dt in cio comiss o s o subtra da de um dia calculados Por que a regra n o determinou a persist ncia com base no Porque esta informa o n o foi especificada nos IC s valor hist rico do percentual Atributos vl despevl prevDesp Modifica o Os atributos vl desp e vl prevDesp foram substitu dos pelas classe Despesa Tipo A4 opera es vl desp Currency e vl prevDesp Currency respectivamente Por que a regra n o determinou que eles fossem opera es Po
98. a Apesar de todos os participantes pertencerem popula o alvo do estudo a saber os profissionais formados em Ci ncia da Computa o pela UFJF a impossibilidade de se aplicar o princ pio da aleatoriedade na sele o da amostra populacional bem como o tamanho reduzido dela levantam d vidas sobre a capacidade dessa amostra em representar essa popula o alvo 6 3 7 Execu o do Estudo Nesta se o s o relatados alguns detalhes relativos execu o do estudo A Tabela 6 8 mostra o cronograma realizado na etapa de execu o do estudo A execu o do estudo ocupou um dia e meio tendo iniciado com o treinamento de UCs para ambos os grupos Treinamento UC Inicial Em seguida enquanto o Grupo B UCs iniciava a modelagem do sistema com UCs Estudo Fase 1 o Grupo A ICs era treinado nos elementos espec ficos da modelagem com ICs Treinamento UC 135 Suplemento para na seqii ncia modelar o sistema com ICs Cada grupo acabou gastando aproximadamente o mesmo tempo nessa modelagem Posteriormente seguiu se outra etapa de treinamento desta vez para a obten o do MD a partir dos UCs Treinamento MUC MD no caso do Grupo B ou a partir dos ICs Treinamento MIC MD no caso do Grupo A Assim como no treinamento anterior os participantes receberam um kit contendo o material instrucional de apoio Conclu do esse treinamento os grupos passaram Fase 2 do estudo a elabora o do MD O G
99. a es e possivelmente outros elementos relevantes para an lise do dom nio a partir dos fluxos de informa o teremos descoberto uma forma de obter uma vis o do MD do sistema trabalhando dentro do arcabou o conceitual da MUC e em um n vel menor de abstra o adequado a uma participa o efetiva dos stakeholders o n vel das trocas de informa o entre eles e o sistema Esse o caminho que trilhamos no presente trabalho de tese Por exemplo atrav s de uma linguagem com sintaxe formal e sem ntica semiformal sem comprometer substancialmente a sua valida o pelos stakeholders 14 Em rela o ao praticado no MD 56 4 3 4 Restringindo o Espa o de Busca das Abstra es Cada poss vel particionamento do sistema em UCs produz um conjunto diferente de fluxos de informa o Ent o uma pergunta pertinente que influ ncia isso pode ter na determina o dos elementos do MD a partir dos fluxos Haveria um particionamento particularmente favor vel determina o desses elementos O crit rio tradicionalmente utilizado para guiar a elicita o dos UCs o UC ter valor para pelo menos um stakeholder muito subjetivo ROBERTSON ROBERTSON 2006 dando muita liberdade ao modelador para a escolha do particionamento que julga adequado Acreditamos que o excesso de liberdade acaba por levar a particionamentos e MDs muito discrepantes entre si produzidos por diferentes modeladores para um mesmo sistema se
100. a o a atributos Isso significa que a orienta o metodol gica fornecida por cada t cnica para a obten o das opera es das classes tende a ser decisiva do ponto de vista da uniformidade dos MDs produzidos a partir dela Conforme discutido no cap tulo 4 falta orienta o metodol gica precisa para a obten o das opera es a partir dos UCs Uma conseq ncia imediata disso que a determina o das opera es das classes fica a depender sobremaneira da interpreta o do modelador o que por sua vez promove a discrep ncia entre os MDs obtidos por diferentes modeladores para um mesmo sistema J na MIC a situa o diferente H uma orienta o precisa para a 6t Por exemplo nome endere o pessoa de contato telefone e o e mail de um credor 149 obten o das opera es dada pelas quatro regras que permitem derivar os diversos tipos de opera es a partir dos ICs se o 5 4 2 Essas regras s o determin sticas ou seja constituem um mapeamento funcional do MIC no MD a cada aplica o de uma regra uma opera o identificada univocamente Al m disso essa aplica o pode ser feita com um n vel m dio de automatismo de 75 se o 5 5 5 Portanto trata se de uma situa o bastante distinta daquela que acontece na modelagem tradicional com UCs Os resultados obtidos nesse estudo devem ser considerados luz das amea as descritas na se o 6 3 8 especialmente as diferen as entre os gru
101. a o da regra R4a realize toda a mudan a de estado requerida e n o exista sa da a produzir 6 4 7 Considera es sobre o Estudo 3 Este estudo de caso realizado em ambiente real permitiu observar que as regras de deriva o da vis o MD de um MIC s o capazes de gerar MDs adequados e propiciar a implementa o de sistemas alinhados s necessidade dos stakeholders O estudo utilizou uma vers o das regras anterior quela apresentada na Se o 5 4 2 que se mostrou deficiente em algumas situa es encontradas durante a sua aplica o Em decorr ncia ajustes foram feitos para eliminar as defici ncias detectadas 6 5 Considera es Finais Esta se o analisa a valida o da hip tese geral da tese e em particular a contribui o dos estudos experimentais para essa valida o Segundo a defini o dada na Se o 6 4 1 162 A hip tese geral da tese enunciada no final do Cap tulo 4 A MIR permite a deriva o semi autom tica de um MD adequado e promove uma maior uniformidade entre os MDs obtidos por diferentes modeladores para um mesmo sistema Isso mantendo as principais vantagens alegadas para a MUC se o 2 4 1 e sem exigir um aumento excessivo do esfor o de modelagem Visando uma an lise mais pormenorizada podemos decompor a hip tese geral em 5 hip teses para valida o conjuntamente H1 H2 H3 H4 H5 A MIC permite a deriva o semi aut
102. a Tanto pode ser aplicado para sistemas de controle industriais quanto para sistemas de informa o inclusive sistemas distribu dos Segundo GLINZ et al 2002 tr s das principais id ias em que se baseia ADORA s o 1 Usar um modelo integrado em vez de uma cole o de modelos Diferentemente da abordagem de cole o de modelos adotada pela UML e 51 r as as ah 4 Se forem desconsiderados resultados previamente obtidos para as a es n o automatiz veis envolvidas na aplica o da regra 108 outros um modelo ADORA integra v rios aspectos de modelagem estrutura dados comportamento intera es com os usu rios etc em um nico modelo coerente Isso permitiu criar uma forte no o de consist ncia e forneceu a base necess ria para o desenvolvimento de mecanismos de verifica o de consist ncia poderosos implementados em ferramentas Al m disso um modelo integrado torna mais sistem tico a constru o de modelos reduz redund ncia e simplifica a verifica o da completude Visualizar modelos em contexto pela apresenta o dos detalhes de um modelo juntamente com uma abstra o do contexto que o envolve A utiliza o de um modelo integrado n o significa que tudo deve ser mostrado em um nico diagrama o que afogaria o leitor em um mar de informa es Os diagramas efetivamente exibidos s o vis es do modelo integrado apresentando apenas as informa es associadas a um aspecto de mode
103. a das regras R4b R4c ou R4d a um IC deve ser alocada em uma das classes alcan adas pelos identificadores presentes na interface informacional do IC ou na classe que representa o sistema Procedimento Para alocar uma opera o resultante da aplica o da regra R4b R4c ou R4d a um IC deve se considerar a lista das classes alcan veis pelos identificadores presentes na interface informacional do IC Se n o existirem identificadores a opera o deve ser alocada na classe que representa o sistema caso contr rio o modelador dever decidir em que classe ser feita aloca o da opera o Regra semi automatiz vel no caso geral A es automatiz veis 1 Determina o dos identificadores presentes na interface informacional de um IC 2 Obten o da lista de classes alcan veis por um identificador 5 Para manter a coes o das demais classes 106 A es n o automatiz veis 1 Determina o da classe a alocar a opera o se a lista de classes candidatas n o for vazia Grau de automatismo 2 3 66 no caso geral mas na situa o especial em que n o existe identificador na interface informacional do IC a aplica o da regra pode ser feita de forma completamente autom tica alocar na classe que representa o sistema An lise de completude Toda opera o identificada a partir do MIC precisa estar alocada a uma das classes do MD A regra R4e atende esse requisito garantindo a complet
104. a esses fluxos e alguns autores apontam isso como uma defici ncia A an lise a seguir procura evidenciar a import ncia desses fluxos para responder a quest o colocada As pessoas no mbito de uma organiza o desempenham suas atividades profissionais trocando informa es entre si Essas informa es est o estruturadas em abstra es do dom nio do neg cio da organiza o Um sistema computacional de informa o introduzido para apoiar a realiza o dessas atividades atrav s da intera o com seus atores constitui um novo comunicador no ambiente organizacional Na verdade um comunicador privilegiado pois em grande escala centraliza a comunica o passando a ser um elemento intermedi rio na troca de informa es entre os atores Uma vez que deve se comunicar com seus atores o sistema tamb m precisa lan ar m o das abstra es de dom nio adequadas para que essa comunica o seja efetiva Sendo um sistema computacional essas abstra es estar o nele formalmente representadas Portanto acreditamos que se os fluxos de informa o que modelam essa comunica o forem especificados com um m nimo de rigor formal eles estar o de alguma forma refletindo essas abstra es atrav s do seu conte do e estrutura o Cabe nos ent o descobrir um meio de aproveitar a composi o e estrutura o dos fluxos de informa o assim modelados para chegar s abstra es que eles refletem Se pudermos extrair abstr
105. a est resumido no cap tulo anterior se o 2 4 2 Dentre os problemas listados na se o 2 4 2 escolhemos aquele designado por transi o dif cil do MUC para o MD do sistema como alvo da pesquisa nesta tese pelos seguintes motivos 1 Dentre os problemas levantados na MUC esse um dos mais evidentes a partir da literatura que trata desses modelos 2 Qualquer avan o que se puder obter na utiliza o conjunta dos dois modelos ser relevante dada a popularidade do modelo de UCs na fase de requisitos NEILL LAPLANTE 2003 KULAK GUINEY 2003 e um consenso cada vez maior de que o MD um complemento importante para o MUC nessa fase O restante deste cap tulo tenta caracterizar melhor o problema considerado nesta tese Primeiro s o consideradas duas quest es relacionadas utiliza o dos dois modelos na fase de requisitos se o 3 2 Em seguida descrevemos um levantamento abrangente realizado na literatura cient fica e t cnica sobre os modelos S o apresentadas e comentadas algumas propostas que a nosso ver fornecem um panorama representativo da pesquisa e da t cnica de utiliza o desses dois modelos se o 3 3 Por fim e com base no que foi levantado selecionamos algumas quest es de investiga o e detalhamos o objetivo a ser buscado nesta tese se o 3 4 5 Assim como o problema da diversidade de abordagens para a MUC que tamb m bastante evidente 24 3 2 O MUC eo MD
106. a graficamente os UCs seus atores e os canais de comunica o entre os atores e os UCs e b uma descri o em linguagem natural de cada caso de uso Essa descri o foca a intera o que deve ocorrer entre o sistema e seus atores quando um UC executado Os atores e outros usu rios do futuro sistema coletivamente designados como stakeholders tendem a perceber o modelo de casos de uso MUC como familiar KULAK GUINEY 2003 O diagrama de casos de uso simples e os atores se v em l representados al m disso a descri o dos UCs foca um aspecto muito concreto para eles a intera o com o sistema descrevendo a em uma linguagem acess vel Essas caracter sticas certamente contribuiram para a ampla difus o da t cnica Entretanto UCs tamb m t m problemas A come ar pela diversidade de formatos para a descri o dos UCs que tende a confundir os modeladores COCKBURN 2005 relacionou 18 dezoito formatos distintos E a varia o n o s no formato mas tamb m no conte do e no n vel de abstra o das descri es Outro problema que o crit rio normalmente utilizado para particionar o sistema em UCs muito subjetivo ROBERTSON ROBERTSON 2006 fornecendo pouca orienta o para os modeladores na escolha dos casos de uso Estes e outros problemas da t cnica de UCs t m sido debatidos pela comunidade cient fica de Engenharia de Requisitos A motiva o para o estudo que resultou nesta tese veio
107. a na linguagem descrita nesta se o Principalmente se o modelador n o puder contar com uma ferramenta computacional de apoio e se o sistema modelado for de grande porte 69 5 4 Deriva o da Vis o MD do Modelo Integrado O objetivo desta se o apresentar um conjunto de regras para a deriva o da vis o do MD a partir do modelo integrado constru do com os ICs Essas regras constituem uma evid ncia da integra o alcan ada S o tamb m apresentados padr es sint ticos detect veis na especifica o da interface informacional dos ICs que servem como heur sticas capazes de apoiar o emprego ou complementar os resultados das regras Esta se o est subdividia em duas subse es A subse o 5 4 1 apresenta uma categoriza o para as regras e discute a rela o entre elas e os padr es sint ticos indicando o papel exato de cada um na deriva o do MD A se o 5 4 2 apresenta as regras e os respectivos padr es sint ticos separados pelo tipo de elemento do MD que visam derivar classes associa es atributos e opera es e ilustra a aplica o das regras ao sistema de ger ncia de restaurante cuja interface informacional encontra se especificada na Figura 5 2 se o 5 3 No final mostrado o MD resultante Figura 5 3 5 4 1 Categorias de Regras de Deriva o e o Papel dos Padr es Sint ticos A se o seguinte 5 4 2 apresenta as regras para a deriva o da vis o de objetos do
108. a t cnica e profissional sobre UCs apresenta diversos enfoques e propostas diferentes e algumas vezes conflitantes para a modelagem de requisitos de sistemas com UCs Portanto o leque de op es para o analista grande e isso se torna um problema na medida em que falta orienta o clara sobre quais as vantagens e desvantagens de cada abordagem bem como crit rios para a escolha da abordagem mais adequada a uma dada situa o de modelagem em particular 2 5 Considera es Finais Este cap tulo fez um breve resumo da modelagem de requisitos de sistemas com UCs MUC para em seguida apresentar e analisar algumas de suas vantagens e problemas apontados na literatura A t cnica de UCs muito flex vel podendo ser aplicada aos mais diversos tipos de sistemas Al m disso ela veio ao encontro da necessidade de fazer dos stakeholders de um sistema a desenvolver co participantes mais ativos do processo de defini o dos requisitos do sistema Pode se dizer tamb m que ela cont m uma certa dose de subjetividade Por exemplo o crit rio de todo UC ter valor para algum stakeholder utilizado para a escolha dos UCs de um sistema considerado excessivamente subjetivo o que ter valor Parte da popularidade da t cnica de UCs talvez se deva exatamente a essa combina o de flexibilidade e subjetividade pois cada autor se sente livre para adapt la a seu gosto Prova disso s o as diversas abordagens para a modela
109. ab PFK id profmel PK id categoria FK nome profmel regelas profmel assina ppra assina ltcat assina pemso a id cons PK id situacaoTrab FK id movTrab FK motivo consulta dt emissao prazo lim 182 funcao setor id_setor PFK id_funcao PFK id_setor PFK id_trabEmp PFK id caract risco PK id profmel FK id_setor FK id_funcao FK id agente de risco FK cnpj prestador cei prestador insalubridade norma insal anexoNR15_insa periculosidade anexoNR16_peri lt razaoSocial pres dt caract nome acomp funcao acomp ctsp acomp cat prestador nr expRisco resp MEL resp cliente nome resp obs caract descr ambiente reg classe id funcao PK id_emp FK nrTrab funcaoPai excluido id_movTrab PK id_trabEmp FK dt_movTrab dt_corrente id_funcao FK id_situacaoTrab PK id_trabEmp FK sit_trab dt_ref dt_corrente motivo afast tipo aposent 2 1 id agente de risco PFK id exame PFK period exame id agente de risco PK id tipo agente FK nome agente agente anexo13 unid med precisao tipo agente id tipo agente PK tipo agente Pd agente asfixSimples absorcao_pele DE dl tecnica aval quantificavel valor teto agente nocivo id caract risco PFK id_ativ PFK descr_moveis descr equips id prod PFK id agente de risco PFK faixa concentracao id ativ PK id funcao FK descr
110. ado a um servi o no IC27 Informar parcelas de valores vari veis N o haver problemas com esse m todo pois 194 Identifica o do s elemento s envolvido s na Tipo de Analise manuten o manuten o MUC MD pode ser colocado que ele foi obtido partir da regra R4b Opera o Inclus o Opera o adicionada devido a necessidade de se ter uma listagem lista caixas nome caixa de todos os caixas existentes N o foi determinada partir das String Array lt Caixa gt classe regras Sistema financeiro Opera o Inclus o Opera o adicionada devido a necessidade de se ter uma listagem lista conta bancaria cons co Tipo C4 de todas as contas banc rias existentes N o foi determinada nta String cons banco partir das regras String Array lt Conta bancaria gt classe Sistema financeiro Opera o Inclus o Opera o adicionada devido a necessidade de se ter uma listagem lista classes item nome clas Tipo C4 de todas as classes de itens existentes N o foi determinada partir seItem String das regras Array lt Classe item gt classe Sistema_financeiro Opera o Inclus o Opera o adicionada devido a necessidade de se ter uma listagem lista servicos nome servico Tipo C4 de todos os servi os existentes N o foi determinada partir das String Array lt Servico gt classe regras Sistema financeiro Opera o Inclus o Opera o adicionada de
111. ado aos alunos mostrou a falta de conhecimento e experi ncia pr vios dos mesmos na modelagem com UCs e ICs O question rio tamb m mostrou que o n vel de conhecimento sobre a aplica o a ser modelada um sistema de biblioteca era o mesmo em ambas as turmas Design Instrumenta o e Execu o O estudo um quasi experimento com contexto multi test within object 1 objeto e mais de 1 participante e do tipo padr o um fator com dois tratamentos WOHLIN et al 2000 O fator o crit rio utilizado no particionamento do sistema objeto do estudo e os dois tratamentos para esse fator s o o crit rio de eventos aut nomos para ICs e o crit rio de valor para UCs Foram feitas duas rodadas trials uma em cada turma A turma diurna utilizou o crit rio de valor enquanto que a noturna utilizou o crit rio dos eventos aut nomos Portanto n o se utilizou o princ pio da aleatoriedade para a aloca o dos tratamentos aos participantes e o estudo ficou desbalanceado turma diurna com 20 alunos e turma noturna com 15 Entretanto essa divis o n o foi feita apenas por conveni ncia mas principalmente visou refor ar a validade interna dos resultados por tornar mais improv vel a troca de informa es entre alunos alocados a tratamentos distintos N o Do qual o autor desta tese professor 118 houve necessidade de blocagem dos participantes j que na caracteriza o dos mesmos n o se evidenciaram difere
112. adores deve ser analisado pelo modelador para decidir sobre a cria o ou n o no MD de uma associa o entre as classes nomeadas por esses identificadores Regra semi automatiz vel A es automatiz veis 1 Determina o dos pares n o ordenados de identificadores na interface informacional II dos ICs A es n o automatiz veis 1 Decis o sobre a cria o ou n o de uma associa o entre classes no MD para um par de ocorr ncias dos identificadores correspondentes em um IC 2 Verifica o da condi o de um identificador estar sendo gerado no IC onde ele ocorre no fluxo de sa da Entretanto esta a o j foi executada durante a aplica o da regra R1 sendo seus resultados pass veis de serem reutilizados aqui Grau de automatismo 1 2 50 ou 1 3 33 caso n o seja reutilizado o resultado da a o n o automatiz vel 2 obtido com a aplica o da regra R1 An lise de completude O MIC indica atrav s da ocorr ncia de mais de um identificador na II de um IC a poss vel exist ncia de associa es entre inst ncias de abstra es objetos de dom nio referenciadas pelos identificadores Pela aplica o da regra R2 todas as associa es entre objetos elicitadas no MIC s o mapeadas para associa o entre abstra es classes no MD Portanto o MD completo em rela o ao MIC com respeito a associa es entre classes Por outro lado como todas as associa es no MD s o o
113. adores em fluxos de entrada e de identificadores gerados em fluxos de sa da pois n o podem exprimir nada al m do que j se encontra registrado no estado interno do sistema O mesmo tipo de racioc nio permite concluir que nos fluxos de sa da apenas os identificadores gerados contribuem para a determina o de associa es entre classes Regra R2 Determina o de associa es As associa es entre classes est o entre aquelas indicadas pelos pares n o ordenados de identificadores presentes na interface informacional de cada IC para fluxos de sa da basta considerar identificadores gerados Em princ pio cada poss vel par de identificadores da interface informacional de um IC pode indicar uma associa o a incluir no MD No sistema Restaurante por exemplo os pares lt id pedido id mesa gt e lt id pedido id item gt obtidos do IC 1 Abrir pedido e o par lt id pedido id cliente gt presente nos ICs 3 Pedir a nota e 5 Pendurar a nota determinam as associa es Pedido Mesa Pedido Item e Pedido Cliente respectivamente 2 Segundo defini o dada no in cio desta se o 2 Para se ter associa es in ditas 73 Padr o sint tico R2 P1 identificadores em fluxos distintos Presen a de identificador es no fluxo de entrada e de identificador es gerado s no fluxo de sa da do IC Heur stica sugere associa o Para cada par lt id id2 gt que possa ser formado com id sendo um id
114. agem encontradas na literatura se o 2 3 Depois s o apresentados e analisados os principais problemas e vantagens da modelagem com UCs se o 2 4 e por fim algumas considera es adicionais fecham o cap tulo se o 2 5 2 1 Defini o A especifica o da OMG Object Management Group para a UML Unified Modeling Language OMG 2008 define caso de uso use case UC como um conjunto de a es realizadas por um sistema o qual produz um resultado observ vel que tipicamente de valor para um ou mais atores ou outros stakeholders do sistema Al m disso acrescenta que a cada UC especifica algum comportamento possivelmente com variantes incluindo comportamento de exce o e de manipula o de erro que o sistema pode realizar em colabora o com um ou mais atores e b esse comportamento envolvendo intera es entre os atores e o sistema pode resultar em mudan as no estado do sistema e comunica o com o seu ambiente Atores s o pap is desempenhados pelos usu rios e outros sistemas que interagem com o sistema em quest o aquele ao qual se aplica o UC Os atores representam entidades externas a esse sistema Cada UC especifica uma parte da funcionalidade que o sistema fornece a seus usu rios Al m disso UCs tamb m expressam requisitos que o sistema espera do seu ambiente pois definem como os atores devem interagir com o sistema de forma que esse sistema possa prover seus servi os A execu o de
115. al os crit rios para o particionamento do sistema em ICs n o haviam sido ainda totalmente explicitados embora eles fossem aplicados intuitivamente Igualmente os termos info case IC e modelagem com ICs MIC ainda n o existiam no seu lugar eram utilizados os termos objetivo informacional e Modelagem Informacional de Requisitos MIR Isso explica a utiliza o desses ltimos nas tr s pr ximas se es 113 6 1 1 Experimenta o Did tica e Individual Em suas primeiras vers es a MIR foi utilizada por alunos de gradua o em Administra o de Empresas da Universidade Federal de Juiz de Fora UFJF Os alunos eram introduzidos t cnica e desenvolviam o modelo informacional de uma aplica o Em seguida derivavam e implementavam em MS Access o modelo E R associado e constru am consultas SQL que eram executadas para concretizar algumas das sa das especificadas no modelo informacional Tamb m desde as primeiras vers es a MIR foi aplicada em v rios estudos individuais para a modelagem de sistemas de pequeno porte em v rios dom nios tais como ger ncia de bar restaurante v deo locadora biblioteca hotel agendamento de a es e acompanhamento de projetos agendamento de reuni es LAMSWEERDE 1992 medicina e seguran a do trabalho dentre outros Alguns dos modelos produzidos foram implementados em sistemas que durante certo tempo eram utilizados rotineiramente 6 1 2 Estudo Precursor 1 EC 1 SIME
116. am no projeto Entretanto se o ambiente de implementa o tiver pouco efeito sobre esse modelo pode se j definir as opera es nele Prop em ent o a elabora o de diagramas de intera o para a partir da descri o dos UCs obter as opera es Os autores pouco ou nada dizem sobre a obten o dos atributos das classes das associa es entre elas e demais elementos do MD na fase de requisitos Os autores tamb m silenciam sobre como verificar a consist ncia entre os dois modelos e como validar o MD The Object Advantage Business Process Reengineering with Object Technology JACOBSON et al 1994 Segundo os autores o melhor trabalhar interativamente entre os dois modelos Eles afirmam que encontrar objetos f cil o dif cil encontrar os objetos certos E sugerem identificar para cada UC os objetos necess rios sua execu o pois dessa forma maiores ser o as chances de se evitar objetos desnecess rios Igualmente passando por todos os UCs onde um objeto desempenha um papel ser poss vel identificar as responsabilidades do objeto no sistema Para eles a identifica o das associa es est ticas entre as classes fica para uma etapa posterior 39 Os autores n o discutem como verificar a consist ncia entre o MUC e o MD e como validar o MD Mastering the Requirements Process 2a edi o ROBERTSON ROBERTSON 2006 Os autores sugerem a utiliza o de um modelo de dados explo
117. amas de colabora o entre elas para a realiza o dos UCs Os autores nada dizem sobre como verificar a consist ncia entre o MUC e o MD nem como validar o MD Considera es Finais sobre as Propostas da Literatura T cnica Sobre o papel do MD e do MUC A maioria dos autores considera o MD como um modelo de apoio para a fase de requisitos Em geral recomendam a elabora o em paralelo e de forma interativa do MUC e do MD Entretanto os autores que adotam o Unified Process UP como por exemplo LARMAN 2004 costumam indicar a elabora o do MD em uma fase anterior que denominam de modelagem do neg cio para depois servir de subs dio elabora o dos UCs Para muitos autores o MUC tem um papel importante na elabora o do MD estabelecendo o contexto do sistema e 43 orientando assim o modelador na busca pelos conceitos relevantes Ou seja ele estabelece os limites do espa o de busca evitando que conceitos desnecess rios para o sistema em quest o sejam elicitados Sobre a rela o rastros entre elementos do MUC e do MD Normalmente os autores sugerem aten o aos termos nomes verbos etc utilizados pelos stakeholders e presentes na descri o dos UCs como forma de descobrir candidatos a classes do modelo de dom nio bem como seus atributos e associa es LARMAN 2004 acrescenta outra sugest o utilizar listas de conceitos e de associa es comuns a um dom nio Alguns autores reconhecem
118. ar vide regra R3d se n o o item n o precisa ser persistido e portanto n o gera um atributo de classe no MD Al m disso deve se realizar a seguinte verifica o de consist ncia do MIC se um item n o identificador e informado n o for persistido ele deve estar sendo utilizado dentro do pr prio IC onde entra seja aparecendo no fluxo de sa da ou sendo utilizado no c lculo de algum item de sa da deste IC direta ou indiretamente Caso contr rio pelo menos em uma vis o minimalista existe uma inconsist ncia no MIC pois uma informa o que entra no sistema n o utilizada para nada no mesmo Regra semi automatiz vel A es automatiz veis 1 Determina o dos itens elementares n o identificadores e de entrada em cada IC 2 Verifica o de que um item aparece tanto no fluxo de entrada quanto no fluxo de sa da de um IC pois a cada IC est associado um nico espa o de nomes para os itens que l aparecem A es n o automatiz veis 1 Verifica o da condi o do item ser necess rio em um IC distinto daquele que est sendo considerado onde o item aparece como entrada 41 A roe A r E J que estamos buscando um MD m nimo ou seja um MD que prov apenas o que estritamente necess rio ao suporte da funcionalidade descrita no MIC 42 r r r Como informa o de sa da no fluxo de sa da ou no c lculo de outro item 96 2 Verifica o de que um item elementar
119. ara uma data ou per odo escolhido Recebimentos realizados e a realizar de todos os clientes ou de um espec fico correspondente a um determinado servi o ou a todos eles Os recebimentos atrasados fora do prazo acordado dever o estar destacados para uma eventual cobran a ao cliente da a import ncia de manter informa es de contato com o cliente endere o pessoa de contato telefone e mail Recebimentos fora do prazo est o sujeitos a multa e juros conforme estipulado no contrato ou atrav s de acordo Pagamentos realizados e a realizar para todos os credores ou para um espec fico e associados a um determinado item de despesa ou a todos eles Os pagamentos atrasados fora do prazo acordado dever o estar destacados para que possam ser priorizados e ou renegociados da a import ncia de manter informa es de contato com o credor endere o pessoa de contato telefone e mail Dever o ser apresentadas informa es que permitam ou facilitem o pagamento tais como nome do credor forma de pagamento valor a pagar pessoa de contato endere o do banco ag ncia ou do estabelecimento onde efetuar o pagamento etc Montante a receber e montante a pagar bem como saldo inicial e final dispon vel em suas contas banc rias e no caixa dia a dia dentro do per odo escolhido 186 Exemplos de ICs produzidos Ator Funcion rio da Empresa IC1 Cadastrar Conta O ator informa ao sistema sua necessidade de cada
120. artida para os particionamentos A granularidade de um particionamento foi medida pelo n mero de UCs inclu dos no particionamento Vari veis e Hip tese A nica vari vel independente fator do estudo o crit rio utilizado para particionar o sistema objeto Dois tratamentos foram considerados para essa vari vel o crit rio de eventos aut nomos para o particionamento em ICs e o crit rio de valor para o particionamento em UCs O estudo possui duas vari veis dependentes granularidade 117 e cobertura funcional dos particionamentos ambas com medidas tomadas em escala do tipo raz o A hip tese testada no estudo que o crit rio de eventos aut nomos produz particionamentos com maior cobertura funcional e de gr o mais fino mais ICs Participantes Participaram do estudo alunos da disciplina de modelagem de sistemas do 2 ano do curso de gradua o em Ci ncia da Computa o da Universidade Federal de Juiz de Fora UFJF totalizando 35 alunos distribu dos em duas turmas uma diurna e outra noturna 20 e 15 respectivamente Essa sele o de participantes n o seguiu o princ pio ideal da amostragem aleat ria sendo feita por conveni ncia para aproveitar a oportunidade do oferecimento da disciplina Esses participantes constitu ram uma amostra da popula o alvo do estudo que a dos estudantes do curso de gradua o em Ci ncia da Computa o da UFJF Um question rio de caracteriza o aplic
121. as amostras para a vari vel Cobertura normal logo ser utilizado o teste param trico T para duas amostras independentes O Teste T pode ter duas express es diferentes em fun o das vari ncias poderem ou n o ser assumidas como iguais conclus o que se retira diretamente do n vel de signific ncia do Teste de Levene Desta forma tem se outro teste de hip teses a ser considerado a um n vel de signific ncia de 5 sendo Ea hn E A 2 2 HO As vari ncias s o iguais 0 T cnical O T cnica SA PS i 2 54 H1 As vari ncias s o diferentes 0 Tecnica O T cnica A Tabela 6 3 apresenta a sa da do teste de Levene do SPSS considerando a vari vel Cobertura no SPSS Analyze Compare Means Independent Samples T Test Tabela 6 3 Testes de amostras independentes para a vari vel Cobertura Independent Samples Test Levene s Test for Equality of Variances t test for Equality of Means 95 Confidence Interval of the Mean Std Error Difference Difference Difference cobertura Equal variances assumed Equal variances not assumed Atrav s da Tabela 6 3 pelas colunas do Teste de Levene para Igualdade de Vari ncias verifica se pela primeira linha dos resultados que as amostras possuem vari ncias iguais uma vez que a signific ncia Sig maior que 0 05 Portanto considerando um n vel de signific ncia de 5 n o h ind cios para se rejeitar a hip tese nula Por fim satisfe
122. as do tipo retrieve na hora de interpretar a regra R3a persist ncia de itens informados na entrada Al m desses ajustes nas regras outros tamb m foram feitos a partir de observa es e an lises realizadas pelos participantes do estudo sobre os MDs produzidos por cada um deles Esses outros ajustes est o descritos na Se o 6 4 6 A pr xima se o analisa os testes de aceita o do sistema realizados pelos stakeholders 6 4 5 An lise dos Testes de Aceita o De nada adiantaria ter um MD adequado na tica dos desenvolvedores se o sistema resultante da implementa o se revelasse muito fora das expectativas dos stakeholders Em vista disso foram organizados e executados testes de aceita o do sistema Esses testes lan aram luz sobre a capacidade do MIC e do MD gerado a partir dele para propiciar um sistema afinado com os anseios dos stakeholders Os principais stakeholders envolvidos com o sistema foram solicitados a testar uma primeira vers o do mesmo aproximadamente 60 de todo o sistema Eles puderam executar o sistema e conferir os resultados com o que tinha sido especificado nos ICs Os testes foram realizados IC a IC organizados em sequ ncias mais prov veis 157 de ocorrer no dia a dia da utiliza o do sistema segundo a tica dos stakeholders Foram 3 dias de testes sob a supervis o do experimentador com os problemas encontrados sendo anotados em uma planilha Ap ndice 6 A Tabela 6 19 r
123. astrados O id cliente constava no IC7 na especifica o resultante da aplica o das regras Saber do William porque ele posteriormente retirou este id dt inicio Atributo dt inicio classe Contrato Inclus o Esta informa o foi adicionada visando a facilitar a visualiza o IC7 Cadastrar E Tipo B2 dos contratos cadastrados para um dado cliente Tamb m est contrato previsto a inclus o desta informa o num relat rio de contratos cancelados a ser criado posteriormente Desde j existe uma consulta no sistema que permite o usu rio visualizar os dados do contrato inclusive a data de in cio IC do tipo Retrieve dia venc Atributo dia venc classe Inclus o Faltou perceber durante a elabora o do MUC que essa informa o IC25 Disp servicos Tipo B3 era necess ria para determinar a data do vencimento de cada uma Cadastrar das parcelas de valores vari veis a serem recebidas por uma disponibiliza disponibiliza o de servi os 192 Identifica o do s elemento s envolvido s na Tipo de An lise manuten o manuten o MUC MD o de servi os a cliente e IC28 Efetivar disponibiliza o de servi os a cliente Opera o descr mov String Inclus o Esta opera o foi colocada nesta classe al m da classe classe Disp servicos Tipo B4 Parcela recebimento pois quando o IC1 Informar Recebimento Perguntar ao William o porque da cria o desta opera o n o encontrei a Justificat
124. autores tamb m consideram que o modelo de UCs e o modelo de classes de dom nio devem ser utilizados de forma complementar durante a fase de requisitos Eles assumem que um modelo de classes preliminar obtido de forma independente do modelo de UCs e prop em um m todo para o casamento apropriado proper coupling dos dois modelos Embora n o esteja explicitamente definido no artigo um casamento apropriado parece corresponder capacidade do modelo de classes atender os UCs ou mais precisamente capacidade das inst ncias das classes executarem os UCs O m todo proposto pelos autores introduz um modelo intermedi rio activity graphs AG s para especificar de forma mais precisa o comportamento descrito nos 32 UCs Um AG uma varia o de uma m quina de estados onde os estados representam a realiza o de a es ou subatividades e as transi es s o disparadas pela conclus o das a es ou subatividades Segundo os autores a granularidade e a sem ntica dos AG s permitem estabelecer uma rela o rastre vel e um ajuste transparente seamless entre os dois modelos S o estabelecidos rastros formais entre as a es dos AG s e as opera es das classes A valida o dos UCs feita com base nos AG s enriquecidos com cen rios e constela es de objetos de dom nio Em conseqii ncia o modelo de classes verificado em rela o ao modelo validado de UCs Segundo os autores ao se va
125. bj possibilita a an lise tanto de objetivos funcionais hard goals quanto de n o funcionais soft goals o MIC assim como a MUC foca basicamente objetivos funcionais A rela o da MOObj com o MIC de complementaridade enquanto a MOObj est voltada principalmente para early requirements o MIC assim com a MUC trata late requirements Uma conclus o an loga apresentada em MYLOPOULOS et al 1999 a An lise Orientada a Objetivos e a An lise Orientada a Objetos devem ser vistas como complementares a primeira focando os est gios iniciais early stages da an lise de requisitos e a racionaliza o do processo de desenvolvimento e a segunda focando os est gios posteriores late stages da an lise de requisitos O MIC pode ser visto como um passo intermedi rio uma ponte entre a modelagem organizacional realizada via MOObj e a AOO An lise Orientada a Objetos Se por um lado suas caracter sticas restritivas objetivos de atores hard goals e NIO n o est o voltadas para o tratamento espec fico de por exemplo requisitos n o funcionais e conflitos bem contemplados na MOObj por outro lado s o exatamente essas restri es que fazem o MIC ser mais facilmente integr vel AOO possibilitando a deriva o semi autom tica de um MD 92 Nem sempre necess rio realizar modelagem organizacional embora isso fique cada vez mais comum devido complexidade e rapidez de evolu o dos sistema
126. bjetos possuiam dados e opera es 3 3 O Estado da Arte e da Pr tica da Utiliza o dos Modelos Nesta se o procuramos dar um panorama do estado da arte e da pr tica da utiliza o do MUC e do MD na fase de requisitos Inicialmente se o 3 3 1 descrevemos a metodologia utilizada no levantamento da literatura Em seguida apresentamos e comentamos algumas propostas contidas em artigos se o 3 3 2 e em livros se o 3 3 3 que respectivamente e em conjunto consideramos representativos do estado da arte e da pr tica da utiliza o dos modelos 3 3 1 Metodologia de Levantamento da Literatura Os levantamentos de material de interesse na literatura foram feitos de forma criteriosa conforme descrito a seguir visando entre outras coisas possibilitar um julgamento mais claro sobre a abrang ncia dos mesmos O resultado ao longo de dois anos foi a coleta de mais de 2000 refer ncias e em muitos casos do texto completo de artigos livros relat rios t cnicos teses disserta es apresenta es e notas de aulas em ERq 27 As fontes levantadas inclu ram eventos basicamente confer ncias e workshops peri dicos editores de livros home pages de pesquisadores e diret rios e servi os de busca na Web A seguir detalhamos as principais fontes utilizadas nos levantamentos Eventos Foram feitas v rias buscas por eventos confer ncia workshops etc que divulgam trabalhos em Engenharia de Requisitos
127. btidas via regra R2 n o haver uma associa o no MD sem que ocorra pelo menos um par correspondente de identificadores na II de algum IC do MIC Assim o MIC tamb m completo em rela o ao MD O fato do MD s conter associa es produzidas pela regra R2 pode ser justificado como segue Se para uma associa o entre classes no MD os identificadores Pois os demais n o contribuem para a descoberta de associa es in ditas ou seja que n o possam ser geradas a partir das demais ocorr ncias de identificadores na II dos ICs 95 das classes n o aparecerem juntos na II de nenhum dos ICs significa que a especifica o da funcionalidade do sistema prescinde de qualquer associa o entre os objetos dessas classes e portanto que pelo menos numa vis o minimalista a associa o no MD sup rflua Regra R3a Persist ncia item informado na entrada Todo item elementar n o identificador e informado presente no fluxo de entrada de um IC e necess rio em outro IC precisa ser persistido caso contr rio se n o for necess rio em outro IC n o deve seal ser persistido Procedimento para aplica o da regra Em cada IC cada item elementar n o identificador e informado no IC deve ser analisado pelo modelador para verificar se o valor de entrada que ele representa necess rio utilizado em algum outro IC Se for deve ser marcado como um item a persistir como atributo de alguma classe a determin
128. cada turma 20 e 15 tornou se interessante a aplica o de m todos estat sticos para avaliar a signific ncia estat stica dos resultados validade de conclus o 6 2 2 An lise Estat stica dos Dados Apurados A an lise a seguir segue os preceitos apresentados em ARA JO et al 2006 Nela T cnica 1 representa o crit rio usual de valor de um UC para algum stakeholder enquanto que T cnica 2 representa o crit rio de eventos aut nomos Como cada participante utilizou apenas uma das duas t cnicas as amostras s o consideradas independentes um dos pressupostos para a aplica o de testes param tricos e de alguns testes n o param tricos An lise Estat stica para a Vari vel Cobertura A primeira considera o a ser feita ao conjunto de dados relativa normalidade e homocedasticidade vari ncia constante das amostras utilizadas WOHLIN et al 2000 Uma an lise visual inicial da distribui o eficiente para o conhecimento do comportamento das amostras A Figura 6 1 apresenta um diagrama box plot destas amostras em rela o vari vel Cobertura no SPSS op o Graphs Boxplot A an lise desta figura n o apresenta outliers Outra conclus o que se pode tirar da Figura 6 1 a aparente grande variabilidade entre as duas amostras Al m disso a T cnica 2 parece apresentar maiores valores para cobertura Para analisar corretamente esta quest o deve se executar um teste estat stico apropriad
129. celar pedirNota in cliente Cliente pendurarNota in cliente Cliente pagarNota in dtPagto Date Mesa in nrMesa Byte Cliente nome_cliente String tel_cliente String Cliente in nomeCli String in telCli String vl_pendCli in dtinicio Date in dtFim Date Currency Restaurante vl_consumo in dtlnicio Date in dtFim Date Currency consumo_dia in dtEmissao Date in dtConsumo Date receita realiz in dtinicio Date in dtFim Date Currency receita pend in dtlnicio Date in dtFim Date Currency receita txServ in dtlnicio Date in dtFim Date Currency receita total in dtInicio Date in dtFim Date Currency receita in dtEmissao Date in dtlnicio Date in dtFim Date vl_pend in dtlnicio Date in dtFim Date Currency penduras in dtEmissao Date in dtlnicio Date in dtFim Date Figura 5 3 Vis o do MD do sistema Restaurante Devido semelhan a entre os produtos das duas modelagens de se esperar que o modelo proposto herde muito das qualidades do modelo de UCs Portanto a an lise a seguir se concentrar nos aspectos de qualidade que a nosso ver s o impactados pela solu o proposta Como o MIC basicamente acrescenta algo a especifica o da interface informacional dos UCs ao MUC clara a necessidade de avaliarmos o impacto disso 84 sobre a usabilidade e a legibilidade do MIC Algum impacto certamente h po
130. cesso desse n vel gera pelo menos um processo cuja ativa o se d por um evento n o aut nomo um evento anteriormente subassumido pelo evento aut nomo disparador do processo decomposto ou uma chamada s ncrona proveniente de algum processo resultante da decomposi o o O resultado da composi o funcional de dois ou mais processos desse n vel gera um processo que para executar completamente precisa de mais de um evento aut nomo Para facilitar a refer ncia a esse n vel de abstra o especial passaremos a denomin lo de N vel Informacional de Objetivos NIO O qualificador informacional lembra o papel especial da interface informacional dos UCs desse n vel 65 5 3 Interface Informacional dos Info Cases No cap tulo anterior se o 4 3 3 antevimos a possibilidade de ter a especifica o da interface informacional dos UCs refletindo formalmente as abstra es de dom nio que ir o constituir a vis o MD do modelo integrado de requisitos Para isso foram apontadas duas provid ncias necess rias l Determinar os UCs em um nivel de abstra o tal que suas interfaces informacionais exprimam informa es a serem persistidas entre estados est veis do sistema e 2 Especificar as interfaces informacionais desses UCs utilizando um formalismo capaz de permitir a captura de rastros formalmente detect veis para a deriva o autom tica de elementos do MD A primeira das provid ncias acima foi tomada co
131. completude parcial de um modelo em rela o ao outro Por incompletude parcial ele entende a situa o em que a presen a de uma informa o em um modelo requer a presen a de informa o correspondente no outro modelo a qual no entanto est faltando nesse modelo S o identificadas tr s situa es em que elementos de um modelo requerem elementos no outro modelo rastros semiformais entre elementos dos dois modelos o Est mulos em um UC que n o se destinam imediatamente a produzir uma resposta tipicamente produzir o uma mudan a de estado a qual requer uma opera o ou transi o de estado correspondente no modelo de classes 30 o Uma resposta em um UC que necessite dados que o est mulo desse UC n o prov requer dados armazenados Esses dados juntamente com as opera es adequadas de acesso devem estar representadas no modelo de classes o Toda opera o no modelo de classes que n o referenciada por outra opera o nesse modelo tipicamente usada pelo UC para processar um est mulo ou produzir uma resposta A principal id ia na proposta estabelecer a consist ncia entre os dois modelos atrav s de uma inspe o manual sistem tica conjugada com as seguintes provid ncias para apoiar e simplificar essa tarefa o Minimiza o de sobreposi es entre os modelos o Introdu o sistem tica de refer ncias cruzadas entre os modelos e o Defini o de um conjunto de regras de constru o e ve
132. correspondente A es n o automatiz veis 1 Escolha da classe dentre aquelas alcan adas para alocar o item 2 Escolha de uma associa o entre as classes alcan adas para cria o da classe de associa o correspondente Grau de automatismo 2 4 50 An lise de completude Os identificadores presentes na interface informacional de um IC restringem a aloca o dos itens a persistir presentes nessa interface s classes por eles alcan adas A regra R3d traduz essa restri o garantindo assim que o MD seja completo em rela o ao MIC no que diz respeito aloca o dos itens a persistir como atributos das classes do MD Por outro lado como toda aloca o de itens de informa o a persistir no MD feita via regra R3d o MIC tamb m estar completo em rela o ao MD Se um item de informa o puder ser melhor alocado pelo modelador de forma ad hoc em uma classe do MD que n o seja uma das classes alcan adas pelos identificadores presentes na interface informacional onde o item aparece o que isso significaria Se ele est no MD porque ele precisou ser comunicado entre estados 100 firmes do sistema e isso s poss vel no MIC utilizando o identificador do objeto que o cont m como atributo Portanto se o modelador fizer isso ele estar introduzindo uma contradi o entre os dois modelos Ou seja se o modelador resolve colocar o atributo em uma classe a mesma motiva o deveria fazer com
133. cu o dos processos Al m disso como esses estados s o sempre est veis tais itens de informa o de estado devem aparecer como atributos das classes de dom nio do sistema Disso resultam as tr s regras a seguir Regra R3a Persist ncia item informado na entrada Todo item elementar n o identificador e informado presente no fluxo de entrada de um IC e necess rio em outro IC precisa ser persistido caso contr rio se n o for necess rio em outro IC n o 26 deve ser persistido Estados consistentes que podem persistir indefinidamente se o 5 2 J que estamos buscando um MD m nimo ou seja um MD que prov apenas o que estritamente necess rio ao suporte da funcionalidade descrita no MIC 76 Padr o sint tico R3a P1 Itens elementares n o identificadores hom nimos ocorrendo em ICs distintos com pelo menos um deles no fluxo de entrada de um IC e outro no fluxo de sa da de outro IC Heur stica O item elementar de entrada em um IC necess rio em outro IC e portanto deve ser persistido No sistema Restaurante Figura 5 2 por exemplo o item elementar dt pedido entra no IC 1 fluxo de entrada pedido e reutilizado consultado nos ICs 3 e 11 Portanto precisa ser persistido Por outro lado v entregue e descr item n o precisam ser persistidos o primeiro porque utilizado apenas no pr prio IC em que entrou IC 4 para o c lculo do troco e o segundo por n
134. cupante se considerarmos os resultados obtidos por SVETINOVIC et al 2005 que mostram uma grande varia o entre os MDs obtidos por diferentes modeladores para um mesmo sistema Qual dos MDs deveria ser validado Conseqiientemente h um s rio risco de que tal valida o n o seja efetiva 2 Enquanto o MUC funcional o MD orientado a objetos e empregam n veis de formaliza o distintos 47 b c Em vista do exposto vemos ind cios de que em geral O modelo de UCs pobre como fonte de informa es teis determina o de um MD Os modeladores n o t m o conhecimento necess rio para tomar uma decis o segura sobre as abstra es a serem escolhidas O espa o de abstra es de um dominio muito amplo e portanto sem uma orienta o para limitar a busca nesse espa o diferentes modeladores tendem a chegar a conjuntos mais ou menos disjuntos de abstra es ao tentarem obter um MD Das an lises e discuss es anteriores podemos identificar v rias quest es cuja investiga o relevante para aperfei oar o papel complementar do MUC e do MD na modelagem de requisitos Ql Q2 Q3 Q4 Q5 Como aumentar a cobertura de elementos do MD deriv veis automaticamente a partir do MUC Como reduzir no MD obtido a partir do MUC a depend ncia da interpreta o do modelador Como minimizar os riscos apontados para uma valida o efetiva do MD Como aumentar o grau de formaliza
135. da percep o emp rica de outro problema pelo autor desta tese UCs enfatizam a modelagem dos aspectos comportamentais da intera o dos atores com o sistema deixando em segundo plano o tratamento da informa o trocada entre eles No contexto de sistemas de informa o onde antes de tudo o que interessa saber que informa o o sistema precisa receber e que informa o se espera que ele seja capaz de prover o esfor o empregado em Pessoas ou outros sistemas que interagem com os UCs 1 especifica es predominantemente comportamentais sem a devida aten o informa o envolvida na intera o n o resulta em uma boa rela o custo benef cio 1 2 O Problema No escopo desta tese estaremos utilizando o termo modelo de dom nio MD no sentido indicado por LARMAN 2004 modelo de classes de objetos que constituem a camada de dom nio do sistema ou seja de objetos de software que representam coisas do espa o de dom nio do problema com m todos relacionados l gica da aplica o ou l gica de dom nio O problema atacado nesta tese n o aquele que motivou inicialmente os estudos e a pesquisa sobre UCs embora guarde rela o com ele O problema alvo da tese ocorre durante a utiliza o conjunta do modelo de casos de uso MUC e do modelo de dom nio do sistema MD durante a fase de levantamento e modelagem de requisitos de um sistema de informa es segundo o paradigma da Orienta o a Objet
136. dades surgidas ao longo do processo de especifica o A dificuldade observada mais frequentemente em quase todas as especifica es se localiza na an lise de dom nio OO mais especificamente na 1 Identifica o de conceitos do dominio do sistema e na 2 Atribui o da funcionalidade do sistema a esses conceitos Em particular foi observada a falta de conceitos e responsabilidades e equ vocos na atribui o de responsabilidades aos conceitos Al m de ocorrer mais frequentemente os autores afirmam que essa dificuldade tende a ficar sem solu o Tamb m foram observadas dificuldades para trabalhar apenas com UCs no n vel do sistema e para encontrar n veis apropriados de abstra o Como resultado os modelos de dom nio produzidos por diferentes grupos para um mesmo sistema resultam drasticamente diferentes provavelmente por terem os grupos considerados conjuntos muito distintos de conceitos e com um grande n mero de conceitos em n veis diferentes de abstra o Os autores consideram essa uma forma particular de inconsist ncia dos modelos de dom nio O estudo levado a cabo pelos autores SVETINOVIC et al 2005 traz evid ncias de que essa dificuldade se manifesta tanto em sistemas grandes como em sistemas pequenos Al m disso segundo os autores a dificuldade n o est nos estudantes nem na sua incapacidade de compreender a orienta o a objetos mas nas 45 limita es das t cnicas correntes d
137. do com ela Por fim como a sele o dos participantes n o p de ser aleat ria mas simplesmente aproveitou a disponibilidade de algumas poucas pessoas era praticamente inevit vel a ocorr ncia de fatores potencialmente perturbadores da validade interna dos resultados do estudo As respostas dos participantes ao question rio de caracteriza o Tabela 6 7 se o 6 3 2 apontaram as seguintes diferen as entre os grupos do estudo l O Grupo B UCs mais homog neo do que o Grupo A ICs O ideal seria ter ambos os grupos igualmente homog neos nos quesitos levantados j que o estudo compara a uniformidade dos MDs produzidos pelos dois grupos variando apenas a t cnica empregada por cada um Dessa forma se reduziria o 138 risco de outros fatores al m da t cnica empregada influenciarem os resultados Entretanto devido sele o por conveni ncia dos participantes apenas o Grupo B resultou quase homog neo Considerando os quesitos utilizados na caracteriza o dos participantes tempo transcorrido desde a formatura n vel de escolaridade conhecimento e experi ncia pr vios no dom nio e na modelagem de sistema similares entre outros razo vel supor que quanto mais homog neo um grupo maiores s o as chances dele produzir MDs mais uniformes entre si Assim o fato do Grupo B UCs ser mais homog neo que o Grupo A ICs representa uma situa o desfavor vel hip tese do estudo ou seja a se considerar ap
138. e an lise orientada a objetos pelo menos em sua aplica o engenharia de requisitos Os autores concluem que simplesmente n o h garantias de consist ncia entre os MDs produzidos por diferentes analistas para um mesmo sistema e que n o poss vel prever que diferen as existir o ou mesmo entender porque essas diferen as acontecem A ampla varia o entre os modelos de dom nio produzidos por diferentes analistas para o mesmo sistema levanta um questionamento sobre o benef cio de se aplicar AOO Eles consideram ainda que preciso confrontar essa quest o e descobrir meios de reduzir ou controlar essa varia o e que apesar de dif cil essencial estabelecer rela es significativas entre os artefatos envolvidos UCs e o MD Motivado por esses resultados Svetinovic desenvolveu uma tese de doutorado cujo objetivo foi encontrar uma solu o para esse problema SVETINOVIC 2005 SVETINOVIC 2006 Como veremos na pr xima se o tamb m faz parte da presente tese investigar uma solu o distinta para o mesmo problema 3 4 2 Quest es de Investiga o A se o 3 2 1 defendeu que trabalhar com os dois modelos na fase de requisitos uma necessidade pois ambos capturam informa es complementares teis para as fases subseqiientes do desenvolvimento do sistema Mas como os modelos modelam um mesmo objeto o sistema e n o s o completamente ortogonais surge a quest o da consist ncia entre eles A an
139. e dados precisam ser persistidos em uma estrutura de dados coerente para que aquelas unidades de trabalho possam ser 170 realizadas A MIC tem respostas para ambas os ICs e o MD deles derivado respectivamente Portanto parece ser promissor investigar as rela es entre a MIC e o que est sendo desenvolvido no contexto de MDA MDD S MUC e MIC Sobreposi o na especifica o de comportamento A MUC foca principalmente a especifica o do comportamento do sistema e seus atores S o v rios os tipos de comportamento inclu dos nos formatos mais completos de descri o dos UCs ativa o dos UCs pelos atores entrada de dados pelos atores produ o de sa das pelo sistema solicita o de interven o aos atores fornecimento de informa es sobre o estado do sistema aos atores retroalimenta o para as interven es dos atores manipula o interna armazenamento e recupera o de informa es da mem ria persistente in cio e t rmino de procedimentos pelo sistema e tomada ou confirma o de decis es pelos atores A MIC acrescentou um significado especial para os UCs decorrente da ado o do NIO e a especifica o semiformal dos fluxos de informa o trocados entre o sistema e seus atores Essa especifica o dos fluxos para UCs do NIO traduz n o apenas especifica o de dados e suas estruturas mas tamb m especifica o dos tr s primeiros tipos de comportamento citados acima que coletivamente designam
140. e de completude Cada ocorr ncia de identificador gerado no MIC representa um objeto criado a partir da classe por ele identificada Isso exige no MD a exist ncia de opera es nas respectivas classes para construir esses objetos A regra R4a providencia essas opera es Entretanto comum a necessidade de se sobrecarregar a opera o construtora em decorr ncia das diversas formas de se inicializar um objeto de uma classe No MIC isso normalmente indicado pela presen a de itens de informa o condicionais no fluxo de entrada de ICs que tem identificador gerado no fluxo de sa da Portanto em geral o MD n o estar completo em rela o ao MIC no que diz respeito a opera es construtoras Acrescentar uma opera o construtora em uma das classes do MD sem que haja alguma informa o condicional especificada no MIC significaria poder inicializar um objeto dessa classe de uma maneira n o prevista no MIC e portanto essa opera o seria desnecess ria ao desempenho da funcionalidade do sistema Regra R4b itens derivados Todo item derivado n o persistido produz uma opera o 47 para calcular o seu valor Procedimento Designar uma opera o para cada item n o identificador derivado e n o persistido presente na interface informacional dos ICs atribuindo lhe um nome derivado do nome do item Regra semi automatiz vel A es automatiz veis 1 Determina o dos nomes de itens elementares n
141. ecifica o do DI 21 Empresa 1177 disp de servi o PCMSO Coord PCMSO cadastrado A gera o de nota n o gera uma nota para essa disponibiliza o 3 ERRO DE IMPLEMENTA O 198 Ap ndice 7 Question rio dos Desenvolvedores EC 3 Desenvolvedores William Fernandes e Bruno Oliveira Data 22 08 2008 1 Como foi organizada a implementa o do sistema Qual o papel da especifica o de ICs II DI OO nessa organiza o As seqii ncias admiss veis SA s dos OO s foram tomadas como base inicial para ordenar a implementa o do sistema Ap s ter sido decidido quais SA s seriam implementadas estabeleceu se a ordem de implementa o delas com base na depend ncia dos IC s nelas contidos Por exemplo a sequ ncia admiss vel de Cancelamento de Contrato continha os IC s de Cadastramento de Contrato e de Cancelamento de Contrato Por sua vez o primeiro IC estava contido em outra SA chamada de Inclus o de Contrato que era constitu da pelos IC s de Cadastramento de Cliente e Cadastramento de Contrato Ent o estabeleceu se que a ltima SA devia ser implementada antes da primeira Com a ordem de implementa o das SA s estabelecida montou se um cronograma de desenvolvimento com os IC s a serem implementados 2 Em que etapa se encontra a implementa o Quantificar J foram implementados onze IC s num total de quatorze acordados para a primeira vers o do Si
142. ees 120 6 2 3 Considera es sobre o Estudo 1 oo ecccceccsscccesscecesececsseceesseeeeseeeesseeees 126 6 3 Estudo 2 EXP 2 MD Granularidade Uniformidade e Esfor o 127 6 3 1 Objetivos Quest es e M tricas 2 0 ecccsscceteceeeceeeceeeeceseceeseceeeeeeeeensaes 127 6 3 2 Sele o de Participantes iicacisy2sievencssesees scans teen ee iess 129 6 3 3 Formula o das Hip teses ssmamestacisaasiassaraesisreesanisaaaso cesiatasintiasassarao 131 6 34 Design do Estudos ea sena nro SUA a an A aai 133 O55 ASAE ACA lata arado a 133 6 3 6 An lise pr via da Validade aspas maiinte boi aaa ias prado 134 0 57 Execucao do Estado same bas ada 135 6 3 8 An lise de Amea as A Ca 137 6 3 9 Verifica o das HIpOveses o ei soe cleus Stes ears a oves Sa Neue ta 139 6 3 10 Considera es sobre o Estudo 2 cccccccccssscccssscecssececsseceesseeeesseeeesseeees 148 6 4 Estudo 3 EC 3 Adequa o do MD e ereeereeeeeeerana 150 6 4 1 Objetivos e Quest es de Investiga o i eee 150 6 4 2 O Sistema Utilizado no Estudo e reereracea 151 6 4 3 Sele o de Participantes Prepara o e Execu o 151 6 4 4 Apura o e An lise da Evolu o dos Modelos s 153 6 4 5 An lise dos Testes de Aceita o cccccecssecessseceesseceesseceeseecesseeeesseeeees 157 6 4 6 Outros Ajustes das Regras de Deriva o sessessesesss
143. ela o ao MIC com respeito ao comportamento de sa da em ICs de consulta O que a regra R4c faz propor a introdu o de uma nova opera o capaz de orquestrar a produ o e providenciar a exibi o do fluxo de sa da Isso se justifica para aproximar o MD ao MIC o qual tem nos fluxos de sa da dos ICs de consulta um elemento altamente vis vel aos stakeholders Por outro lado uma opera o representada por um procedimento cujo nico resultado o efeito colateral de produzir uma sa da que n o se restringe a um nico item derivado n o persistido requer no MIC a presen a de um fluxo de sa da composto por tais itens Se essas opera es forem exatamente aquela geradas pela aplica o da regra 104 R4c isso estar garantido e portanto o MIC ser completo em rela o ao MD no que diz respeito s opera es desse tipo Regra R4d mudan a de estado Todo IC que causa mudan a no estado do sistema produz uma opera o para realizar essa mudan a e para produzir o fluxo de sa da se existir a menos que uma opera o construtora resultante da aplica o da regra R4a realize toda a mudan a de estado requerida e n o exista sa da a produzir Procedimento Para cada IC que atenda as condi es enunciadas na regra verificar se existe opera o construtora resultante da aplica o da regra R4a ao IC caso exista verificar se essa opera o faz toda a mudan a de estado causada pelo IC e se n o existe
144. ela o ao MIC quando ele cont m todas as informa es que s o requeridas por informa es presentes no MIC Esta defini o se baseia naquela dada por GLINZ 2000 se o 4 4 Defini o an loga pode ser dada para a completude do MIC em rela o ao MD Regra R1 Determina o de classes Cada identificador gerado d origem a uma classe de objetos Procedimento para aplica o da regra Obter o conjunto dos identificadores gerados presentes nos ICs O MD conter uma classe para cada um desses identificadores nomeada com a parte do nome do identificador que segue ao id 93 Regra semi automatiz vel A es automatiz veis 1 Determina o da condi o de um item ser identificador s o aqueles itens elementares cujo nome se inicia com a seqii ncia de caracteres id 2 Nomea o da classe correspondente a um identificador parte do nome do identificador seguinte sequ ncia de caracteres id A es n o automatiz veis 1 Verifica o da condi o de um identificador estar sendo gerado no IC Grau de automatismo 2 3 67 An lise de completude Todo identificador presente no MIC representa um objeto que prov informa es de entrada na forma de atributos ou derivadas na forma de opera es necess rias ao desempenho da funcionalidade do sistema que est sendo modelado Como ICs s o UCs no N vel Informacional de Objetivos NIO se o 5 2 tais objetos correspondem a abstra
145. eles cujo valor prov m diretamente de uma entrada itens presentes no fluxo de entrada de algum IC enquanto que os itens derivados ou calculados n o prov m diretamente de uma entrada mas t m o seu valor derivado calculado pelo sistema a partir de outros itens informados ou derivados Um tipo especial de item derivado s o os itens identificadores Eles se destacam pelo nome iniciado por id por exemplo id cliente e representam abstra es do dom nio da aplica o identificadas durante a modelagem de requisitos A nota o utilizada para descrever a composi o de um fluxo ou pacote a seguinte significa composi o nix m Significa de n a m ocorr ncias ou repeti es de x utilizado para agrupar itens significa ou e delimita itens condicionais ou seja que nem sempre estar o presentes podem n o ser pertinentes dependendo do contexto 67 ATOR Cliente IC 1 Abrir pedido gt pedido dt pedido id mesa itens ped Z itens ped fid item quant item id pedido ATOR Cliente IC 2 Cancelar pedido gt cancela ped id pedido ATOR Cliente IC 3 Pedir a nota gt solicitacao nota id pedido id cliente nota id pedido nr mesa dt pedido itens nota vl nota nome cliente tel cliente itens nota fid item cat item nome item p unit quant item vl item ATOR Cliente IC 4 Pagar a nota gt paga
146. elo menos um deles no fluxo de entrada de um IC e outro no fluxo de sa da de outro IC Isso uma heur stica porque o modelador n o est obrigado a utilizar o mesmo nome toda vez que se referir a uma mesma informa o em ICs distintos apesar disso ser recomend vel vide se o 5 3 A vantagem dos padr es sint ticos decorre do fato de que o seu reconhecimento e quase sempre o emprego da respectiva heur stica pode ser automatizado Cada padr o sint tico est apresentado na pr xima se o logo ap s a apresenta o da regra qual se aplica 5 4 2 As Regras de Deriva o e seus Padr es Sint ticos A apresenta o das regras est dividida em 4 se es uma para cada tipo de elemento do modelo de classes que elas ajudam a determinar classes associa es atributos e opera es Para boa parte das regras n o determin sticas e ou n o automatiz veis foi 71 poss vel identificar um ou mais padr es sint ticos e respectivas heur sticas capazes de apoiar a aplica o dessas regras Tais padr es heur sticas est o descritos logo ap s a apresenta o da regra que os originou A especifica o dos fluxos da interface informacional do sistema Restaurante Figura 5 2 utilizada para exemplificar a aplica o das regras Ainda a t tulo de exemplifica o para o sistema Restaurante quando uma regra possui padr o sint tico heur stica de apoio tamb m apresentado o percentual do n mer
147. em Engenharia de Requisitos 6 Diz Casos de USO asia ansaarca marta seta nita ues tania aaa Da nda anda sds ca qua so taa ienes de 9 Dis DENMI OS sal as O e RS as ad 9 2 22 O Modelo de Casos de Uso MUC cccccesssccesseecesscecesececsseeecsseeeeseesesseeees 10 2 3 Abordagens de Modelagem com Casos de US0 ccceesceesseesteceteeeteeeeeeenseees 14 2 4 An lise da Modelagem de Requisitos com UCS ceececccesseeeseceeeeeeeeeseeeeesees 16 241 Vantagens da MUC ass hee sees Ud ais a A aa isa 16 242A Problemas daMUC esmaga ss ia RN eats 20 2 5 Considera es Finais siga ss seeiade preta innia O ada Sea a sas 22 3 Os Problemas AIVO casas sosssaspeacvaetearpbssvassosontaaesennsetdesevosauiidecannosasodes 24 Sed gt Introdu o ss sen SD AD RAND a 24 3 2 O MUC eo MD na Fase de Requisitos cisaiccsccssncdsscdarcciateedecobecesuscduandveceeds 25 3 2 1 Por que Utilizar o MUC e o MD na Fase de Requisitos 25 3 2 2 Qual deve ser a ordem de elabora o dos modelos cceesseeeeseeeeees 26 3 3 O Estado da Arte e da Pr tica da Utiliza o dos Modelos 27 3 3 1 Metodologia de Levantamento da Literatura 27 3 3 2 Propostas da Literatura Cient fica c ee eecceeceeseeesseeeeeceeeeeeeeeeeeesaeens 29 3 3 3 Propostas da Literatura T cnica s nsesenssesseeseosseessesressesreserssressrssressesse 38 3 4 Quest es de Investiga o e Objetivo da Tese
148. em outro subsistema 1 12 OK 1 10 F 1 servico Tornar o id_classeItem condicional pois o usu rio nem sempre tem como classificar o servi o no momento do seu cadastramento 5 REQUISITO REGRA DE NEG CIO N O ESPECIFICADO NO DI 1 I25 F disp serv A sele o do contrato se for o caso deveria mostrar o cliente nome bem como as datas de in cio e de cadastramento do contrato para facilitar a escolha do mesmo 1 PROBLEMA DA INTERFACE COM O USU RIO 1 25 F 1 disp serv N o permite escolher previs o em vez de real AINDA N O IMPLEMENTADO n o foi considerado como problema 1 125 P 1 servicos Permite cadastrar mais de uma vez um mesmo item de cobran a para um mesmo servi o 4 ERRO DE IMPLEMENTA O propiciado pela subespecifica o do DI 1 25 F 1 dt termino Aceita menor do que dt inicio 3 ERRO DE IMPLEMENTA O 1 25 F 1 dt termino Est obrigando entrar com uma data isso mesmo PENDENTE DE AN LISE PELOS STAKEHOLDERS 24 EP per_ger A gera o de nota deve buscar todas os recebimentos por ocorr ncia que ainda n o foram considerados na emiss o anterior at a data fim informada para evitar que algum recebimento passe sem ser cobrado 5 REQUISITO REGRA DE NEG CIO N O ESPECIFICADO NO DI 1 125 F id profMel O vendedor agora pode ser um parceiro exemplo escrit rio de advocacia fora da empresa que pode inclusive n o ser um cliente 6 MANUTENCAO EVOLUTIVA 1 25 F d
149. embora ela j fosse conhecida pelo autor desta tese Essa situa o foi corrigida com a modifica o da regra anterior para aloca o dos itens a persistir nas classes Essa regra passou tamb m a determinar a cria o de classes de associa o R3d Aloca o de atributo Cria o de classe de associa o Cada item a persistir presente na interface informacional de um IC deve ser alocado como atributo de uma das classes alcan adas pelos identificadores presentes nessa mesma interface Caso nenhuma dessas classes comporte o item ele deve ser alocado em uma nova classe de associa o criada para esse fim correspondente a uma associa o existente entre as classes alcan adas Opera es construtoras para classes de associa o A implementa o do sistema modelado no estudo de caso fez com que se percebesse uma omiss o da regra que trata da introdu o de opera es construtoras nas classes no que diz respeito s classes de associa o A vers o anterior dessa regra era R4a Todo identificador gerado produz uma opera o construtora na classe identificada por esse identificador Para que a regra passasse tamb m a indicar a inclus o de uma opera o construtora nas classes de associa o ela foi alterada para R4a construtoras Toda classe recebe uma opera o construtora Informa o relativa a um estado anterior do sistema que possivelmente n o mais vigora com o mesmo valor no estado a
150. empr stimo em tempo h bil Controlar o saldo em caixa bem como o saldo e a movimenta o de suas contas banc rias Controlar as despesas efetuadas pagamentos por credor e item de despesa O objetivo ter uma gest o permanente do quanto se gasta com cada credor e em cada item de despesa buscando maximizar os benef cios obtidos com os recursos gastos face as metas da empresa A quita o pode ser feita de uma s vez ou dividida em parcelas nas respectivas datas de vencimento acordadas Controlar os recebimentos de clientes por servi o prestado A empresa tem um leque atual de servi os que disponibiliza a seus clientes que pode mudar ao longo do tempo A maioria dos clientes tem contrato com a empresa estipulando os servi os contratados e o valor a ser pago pelo conjunto dos servi os Mesmo clientes sem contrato podem usufruir os servi os da empresa pagando o valor padr o desses servi os ou um valor especial decorrente de negocia o caso a caso A quita o pode ser feita de uma s vez ou dividido em parcelas nas respectivas datas de vencimento acordadas Os contratos t m renova o autom tica a cada 1 ano contado da data da contrata o podendo ser renegociados ou cancelados a qualquer instante mediante solicita o pr via do cliente com pelo menos 2 meses de anteced ncia preciso manter um hist rico das renova es e renegocia es de contratos A empresa deve poder consultar a qualquer instante p
151. enas esse fator o Grupo B UCs tenderia a produzir MDs mais uniformes entre si do que o Grupo A ICs 2 O Grupo B UCs tem maior n vel de escolaridade De uma maneira geral razo vel supor que quanto maior o n vel de escolaridade dos participantes maior o seu conhecimento e dom nio da t cnica utilizada e portanto mais capacitados estariam para produzir MDs mais uniformes entre si Conseq entemente podemos considerar essa diferen a como sendo desfavor vel hip tese do estudo ou seja a se considerar apenas esse fator o Grupo B UCs tenderia a produzir MDs mais uniformes entre si do que o Grupo A ICs 3 O Grupo A ICs tem mais tempo de exerc cio profissional Em contraposi o s duas diferen as anteriores o maior tempo de exercicio profissional que alguns dos participantes do Grupo A ICs t m em rela o aos participantes do Grupo B UCs tende a favorecer a hip tese do estudo o Grupo A ser capaz de produzir MDs mais uniformes entre si Isso porque em princ pio os participantes do Grupo A teriam maior maturidade e dom nio da t cnica empregada Dado o reduzido n mero de participantes em cada grupo 3 n o foi possivel utilizar o principio geral de blocagem para isolar essas diferen as e ter uma avalia o experimental da sua influ ncia nos resultados do estudo 6 3 9 Verifica o das Hip teses Esfor o A Tabela 6 9 mostra os dados coletados sobre o esfor o n mero de horas empregado por
152. endo um identificador gerado presente no fluxo de sa da do UC e id um identificador presente no fluxo de entrada determina uma associa o entre as classes identificadas por id e id No caso de mais de um identificador gerado as associa es correspondentes a pares que compartilham o mesmo id tendem a ser redundantes As multiplicidades dessas associa es podem ser parcialmente obtidas pela regra R2a M abaixo R2b Determina o de associa es identificadores no mesmo fluxo Se o identificador idz estiver no escopo de uma repeti o os limites inferior e superior da multiplicidade no lado da classe identificada por id gt ser o respectivamente o n mero m nimo e m ximo de repeti es especificados no modelo informacional ou 0 e na falta dessa especifica o Caso contr rio o limite superior da multiplicidade ser 1 e o limite inferior 0 se id for condicional ou 1 se id n o for condicional A multiplicidade no lado da classe identificada por id n o fica determinada Nova vers o R2 Determina o de associa es As associa es entre classes est o entre aquelas indicadas pelos pares n o ordenados de identificadores presentes na interface informacional de cada IC para fluxos de sa da basta considerar identificadores gerados 70 IA Isto se id estiver entre s 159 Justificativa Em sua utiliza o no presente estudo a regra R2a produziu associa es equ
153. enta um diagrama box plot destas amostras em rela o vari vel Granularidade No SPSS op o Graphs Boxplot A an lise desta figura n o apresenta outliers Outra conclus o que se pode tirar desta figura a aparente igualdade de variabilidade entre as duas amostras Apesar disso a T cnica 2 aparenta maior granularidade Para analisar corretamente esta quest o deve se executar um teste estat stico apropriado que neste caso ser o Teste de Levene que ser feito mais adiante O Teste T para duas amostras independentes exige que as amostras sigam uma distribui o normal Desta forma tem se um primeiro teste de hip teses a ser feito considerando um n vel de signific ncia de 5 sendo HO A distribui o normal H1 A distribui o n o normal 123 granularidade 3 tecnica Figura 6 2 Diagrama Box Plot para a vari vel Granularidade A Tabela 6 5 apresenta a sa da dos testes de normalidade do SPSS considerando a vari vel Granularidade No SPSS Analyze Descriptive Statistics Explore Tabela 6 5 Testes de Normalidade para a vari vel Granularidade Tests of Normality E ER it tecnica Statistic Statistic granularidade 214 Sia 7 908 151 15 200 15 This is a lower bound of the true significance a Lilliefors Significance Correction Pelo resultado do Teste de Shapiro Wilk observa se que ambas as amostras possuem o valor de significancia Sig superi
154. ente fator podendo receber dois valores tratamentos Neste quasi experimento o fator qual t cnica foi utilizada para elaborar o modelo de requisitos e o respectivo diagrama de classes e os tratamentos s o as duas t cnicas utilizadas para isso a t cnica tradicional baseada em UCs e a t cnica que emprega ICs descritas nos cap tulos 2 e 5 respectivamente Conforme relatado anteriormente os participantes foram divididos em dois grupos cada um com tr s indiv duos totalizando seis participantes Cada um destes grupos ficou respons vel pela aplica o de uma das t cnicas O n mero igual de participantes em cada grupo atende ao princ pio do balanceamento na organiza o do estudo 6 3 5 Instrumenta o Para a produ o dos MDs muito importante que os participantes tenham conhecimento do dom nio do sistema a ser modelado Para isso todos os participantes receberam um sum rio das principais fun es do sistema a modelar Ap ndice 3 Durante a execu o do estudo as d vidas que surgiram foram esclarecidas pelos experimentadores a todos os participantes 133 Cada grupo de participantes recebeu um kit contendo todo o material de apoio e um treinamento espec fico para a t cnica a ser aplicada por eles O material foi entregue alguns dias antes da realiza o do estudo para que os participantes pudessem se familiarizar com ele e o treinamento foi ministrado imediatamente antes do in cio do estudo
155. entificador e de sa da ser informado em contraposi o a ser derivado 2 Verifica o da condi o de um item informado presente no fluxo de sa da de um IC representar uma informa o hist rica n o restaur vel nesse IC Grau de automatismo 1 3 33 An lise de completude ap s a regra R3c Informa o relativa a um estado anterior do sistema que possivelmente n o mais vigora com o mesmo valor no estado atual 97 Regra R3c Persist ncia item derivado valor hist rico Todo item elementar n o identificador e derivado presente no fluxo de sa da em um IC representando informa o hist rica cujo valor n o pode ser restaurado nesse IC precisa ser persistido caso contr rio n o deve ser persistido Procedimento para aplica o da regra Para cada item elementar n o identificador e derivado presente no fluxo de sa da de um IC o modelador deve verificar se o valor que ele representa uma informa o hist rica n o pass vel de restaura o em geral naquele IC Se esse for o caso o item constitui informa o que precisa ser persistida como atributo de alguma classe a ser determinada vide regra R3d e portanto deve ser marcado como tal caso contr rio se o item n o informa o hist rica ou sendo seu valor pode ser restaurado no IC ele n o dever ser marcado como um item a persistir Regra semi automatiz vel A es automatiz veis 1 Determina o dos
156. entificador gerado fluxo de sa da e id um identificador no fluxo de entrada criar uma associa o entre as classes identificadas por id e id2 No caso de mais de um identificador gerado as associa es correspondentes a pares que compartilham o mesmo id tendem a ser redundantes Padr o sint tico R2 P2 Ocorr ncia de R2 P1 e o identificador id est no mw 23 escopo de uma repeti o Heur stica sugere multiplicidade Os limites inferior e superior da multiplicidade no lado da classe identificada por id s o respectivamente o n mero m nimo e maximo de repeti es especificados no modelo informacional ou 0 e na falta dessa especifica o multiplicidade do lado da classe identificada por id n o sugerida Padr o sint tico R2 P3 Ocorr ncia de R2 P1 e o identificador id n o est no escopo de uma repeti o Heur stica sugere multiplicidade O limite superior da multiplicidade no lado da classe identificada por id ser 1 e o limite inferior 0 se idz for condicional ou 1 se id nao for condicional multiplicidade do lado da classe identificada por id n o sugerida No sistema Restaurante Figura 5 2 o padr o sint tico R2 P1 ocorre no IC 1 com a presen a dos identificadores id mesa e id item no fluxo de entrada e do identificador gerado id pedido no fluxo de sa da Assim podem ser formados os pares lt id pedido id mesa gt e lt id pedido id item gt o que sug
157. ento em que isso deve ocorrer unicamente a partir dos processos elicitados segundo os crit rios da MIC Portanto vemos que o NIO N vel Informacional de Objetivos se o 5 2 n o exatamente o n vel das atividades essenciais da AE mas uma simplifica o abstra o deste Essa simplifica o significativa pois segundo a avalia o dos pr prios criadores da AE as atividades custodiais ocorrem muito mais frequentemente do que as atividades fundamentais puras MCMENAMIM PALMER 1991 pp 83 Essa e outras diferen as entre o MIC e a AE como por exemplo a possibilidade de decompor as atividades essenciais decorrem do escopo distinto de cada uma o MIC proposto visa a modelagem de requisitos e a an lise do sistema no n vel do dom nio de aplica o enquanto a AE foca principalmente a an lise do sistema nos n veis l gico e f sico MCMENAMIM e PALMER 1991 pp 85 apontam vantagens importantes para o particionamento que prop em o Fornece resultados razoavelmente uniformes independentemente de quem particiona o sistema o Resulta em uma modelagem concisa n mero relativamente pequeno de processos o A interface entre os processos tende a ser m nima e o Resulta em processos fi is ess ncia do sistema sem interdepend ncia temporal artificial MAFFEO 1992 pp 301 acrescenta ainda as seguintes vantagens desse particionamento o Minimiza os riscos de paralisia por an lise comum na estrat
158. ents Just Don t Get It In 13th IEEE Intl Conference on Requirements Engineering RE 05 pp 189 198 Paris France September SVETINOVIC D BERRY D M GODFREY M 2006 Increasing Quality of Conceptual Models Is Object Oriented Analysis That Simple In The Role of Abstraction in Software Engineering Workshop 28th Intl Conference on Software Engineering ROA ICSE Shangai China September SVETINOVIC D 2006 Increasing the Semantic Similarity of Object Oriented Domain Models by Performing Behavioral Analysis First PhD Thesis Universtiy of Waterloo Ontario Canada September 179 WALDEN K NERSON J M 1995 Seamless Object Oriented Software Architecture Analysis and Design of Reliable Systems 1 ed New York Prentice Hall WIEGERS K E 2003 Software Requirements oe ed Redmond Washington Microsoft Press WING J M 1988 A Study of 12 Specifications of the Library Problem IEEE Software v 5 n 4 pp 66 76 WIRFS BROCK R WILKERSON B WIENER L 1990 Designing Object Oriented Software Englewood Cliffs NJ Prentice Hall WOHLIN C RUNESON P HOST M et al 2000 Experimentation in Software Engineering An Introduction London UK Kluwer Academic Publishers WUsCaM 2006 Intl Workshop on Open Issues in Industrial Use Case Modeling Dispon vel em lt http www ie infuc3m es uml2004 ws6 gt Acesso em Julho 2006 YOURDON E 1990 An
159. ere pela heur stica associada a introdu o das associa es Pedido Mesa e Pedido Item respectivamente grau de acerto 2 2 100 Com rela o s multiplicidades a aplica o dos padr es sint ticos acima produz os seguintes resultados grau de acerto 2 2 100 a Na associa o Pedido Mesa como id mesa id n o est no escopo de repeti o e n o condicional a heur stica associada ao padr o sint tico R2 P3 sugere a multiplicidade 1 1 no lado da classe Mesa e 23 IA E Isto se id estiver entre s 74 b Na associa o Pedido Item como id item id2 est no escopo de repeti o com limite inferior 1 e limite superior n o especificado a heur stica associada ao padr o sint tico R2 P2 sugere a multiplicidade 1 no lado da classe Item Padr o sint tico R2 P4 identificadores no mesmo fluxo Presen a de identificadores dois ou mais somente em um dos fluxos do IC considerando para fluxo de sa da apenas identificadores gerados Heur stica sugere associa o Todo par de identificadores determina uma associa o entre as classes por eles identificadas Em fluxos com mais de dois identificadores algumas dessas associa es tendem a ser redundantes Padr o sint tico R2 P5 Ocorr ncia de R2 P4 identificadores da associa o no fluxo de entrada do IC com um deles digamos id no escopo de uma repeti o em rela o ao outro id Heur stica s
160. ermanecem impl citos e embutidos em elementos do MUC podendo ser recuperados a partir desses gra as a uma nova disciplina adotada na elabora o do MUC a ado o do NIO juntamente com a especifica o semiformal da interface informacional dos ICs 5 6 2 An lise Prop sito Atividade SVETINOVIC 2006 tamb m atacou o problema da inconsist ncia entre MDs obtidos por diferentes modeladores para um mesmo sistema Ele prop s uma altera o no processo tradicional da AOO que observa apenas conceitos para adotar uma abordagem focada em atividades onde se busca o conceito que respons vel por uma atividade em particular obtendo se assim a valida o do conceito atrav s de uma an lise atividade prop sito O resultado um conjunto de artefatos intermedi rios mais restringidos do que o MD capazes de influenciar o resultado da decomposi o conceitual e conseguir que MDs produzidos por diferentes modeladores para um mesmo sistema sejam mais consistentes entre si O autor considera que uma combina o de an lise baseada em objetivo e de modelagem baseada em estado seja suficiente como t cnicas de base para a an lise prop sito atividade 110 Portanto a sua estrat gia avan ar na an lise antes de tentar uma decomposi o conceitual para com isso restringir o grau de liberdade na escolha das classes conceitos de dom nio e na atribui o das responsabilidades s classes A nosso ve
161. ersey Addison Wesley Professional SHOVAL P YAMPOLSKY A LAST M 2006 Class Diagrams and Use Cases Experimental Examination of the Preferred Order of Modeling In 71th Intl Workshop on Exploring Modeling Methods in System Analysis and Design EMMSAD 06 Luxembourg 5 6 June 178 SODHI J SODHI P 2003 Managing IT Systems Requirements I ed Management Concepts SOMMERVILLE I SAWYER P 1997 Requirements Engineering A Good Practice Guide 1 ed England Jonh Wiley amp Sons Ltd SPSS 2008 Software de An lises Estat sticas SPSS Brasil Dispon vel em lt http www spss com br gt Acesso em Novembro 2008 SUBRAMANIAM K LIU D FAR B H et al 2004 UCDA Use Case Driven Development Assistant Tool for Class Model Generation In 76th Intl Conf on Software Engineering amp Knowledge Engineering SEKE 2004 pp 324 329 Banff Alberta Canada June SUTCLIFFE A 2003 Scenario Based Requirements Engineering In th IEEE Intl Requirements Engineering Conference IREC Monterey Bay California September SVETINOVIC D 2005 Improving the Consistency of the Conceptual Models Through the Activity Purpose Analysis In 3th IEEE Intl Conference on Requirements Engineering RE 05 Doctoral Symposium Paris France September SVETINOVIC D BERRY D M GODFREY M 2005 Concept Identification in Object Oriented Domain Analysis Why Some Stud
162. es feita com base nas informa es de tipo e dom nio do item correspondente constantes no dicion rio de itens elementares Por exemplo a partir da interface informacional Figura 5 2 e do dicion rio do IC 3 Tabela 5 1 chega se s especifica es pedirNota in cliente Cliente e vi nota Currency A Figura 5 3 mostra o resultado da aplica o das regras discutidas nessa se o interface informacional do sistema Restaurante se o 5 3 5 5 An lise da Solu o 5 5 1 Qualidade das Especifica es Obtidas O MIC proposto basicamente igual ao artefato produzido na MUC exceto pela inser o de um conjunto de express es de dados para especificar a interface informacional de cada UC constru das utilizando a linguagem semiformal apresentada na se o 5 3 Na presente se o vamos examinar os efeitos dessa diferen a sobre a qualidade da especifica o de requisitos resultante 83 nome item String pc unit Currency cat item String Item in nomeltem String in pcUnit Currency in catltem String quant item in dtConsumo Date unsigned short Aos Pedido ltem nome item String A pc item Currency quant item Byte are Pedidoltem in nomeltem String in pcltem Currency in quantltem Byte Pedido pendurado bool Pedido in dtPedido Date in mesa Mesa in itensPed Object troco in viEntregue Currency Currency vl_nota Currency can
163. es de dom nio a serem persistidas nos estados est veis do sistema e portanto devem aparecer como classes no MD do sistema A regra R1 garante isso e consequentemente o MD dela resultante completo em rela o ao MIC Por outro lado como todas as classes do MD s o obtidas via regra R1 n o haver uma classe no MD sem que exista um identificador correspondente no MIC Assim o MIC tamb m completo em rela o ao MD Outra constata o que pode ser feita a de que o MD s precisa conter classes produzidas pela regra R1 Se uma classe no MD n o possui um identificador correspondente no MIC ent o nenhuma informa o informada ou derivada poderia ser recuperada dos objetos dessa classe entre estados est veis do sistema pois para isso necess rio existir um identificador para o objeto no MIC Conseqiientemente ou os objetos da classe s o transientes n o precisam ser persistidos ou n o s o necess rios ao desempenho da funcionalidade do sistema Em ambos os casos a classe n o precisa fazer parte do MD pelo menos em uma vis o minimalista Regra R2 Determina o de associa es As associa es entre classes est o entre aquelas indicadas pelos pares n o ordenados de identificadores presentes na interface 94 informacional de cada IC para fluxos de sa da basta considerar identificadores gerados Procedimento para aplica o da regra Em cada IC cada par n o ordenado de identific
164. essidades dos seus stakeholders por n o implementar algumas fun es imprescind veis a eles Se uma especifica o de requisitos inconsistente ent o ela possui pelo menos dois requisitos que n o podem ser satisfeitos ao mesmo tempo qualquer que seja a implementa o do sistema Trata se de uma falha da especifica o que se n o resolvida pode igualmente impedir o sistema de satisfazer seus stakeholders 17 No caso de uma LRgs extensa dif cil avaliar se ela consistente e completa Tamb m dif cil para os stakeholders se certificarem de que seus objetivos de neg cio ser o efetivamente apoiados pelo sistema especificado na LRgs LAUESEN 2002 A raiz dessas dificuldades est na estrutura o inexistente ou inadequada que esta abordagem de especifica o promove Diferentemente na modelagem com UCs MUC os requisitos s o estruturados segundo os usu rios atores do futuro sistema e principalmente em torno dos objetivos desses atores e demais stakeholders Cada UC mostra como o sistema dever interagir com os atores para alcan ar um objetivo de algum stakeholder Enquanto que para a LRgs o fundamental responder o que os usu rios desejam que o sistema fa a para a MUC quem vai usar o sistema quais s o seus objetivos ao fazer isso e quais os cen rios t picos dessa utiliza o WIEGERS 2003 LARMAN 2004 A visibilidade dada aos objetivos dos stakeholders e a estrutura o dos requisi
165. estaurante pelo padr o R4e P5 O grau de acerto proporcionado pelos padr es sint ticos foi de 3 3 100 No sistema Restaurante as opera es determinadas pela regra R4d s o assim alocadas nas classes opera es cancelar IC 2 pedirNota IC 3 pagarNota IC 82 4 e pendurarNota IC 5 alocadas na classe Pedido pelo padr o R4e P7 O grau de acerto dos padr es sint ticos foi de 4 4 100 A classe que representa o sistema pode ser vista como um reposit rio de opera es a serem transferidas para classes de controle JACOBSON et al 1992 a serem introduzidas em uma fase posterior da an lise do sistema Todas as demais classes do MD tendem a ter alta coes o sem ntica HENDERSON SELLERS 1996 j que elas correspondem a abstra es utilizadas pelos stakeholders no seu dia a dia de trabalho Pelo mesmo motivo o acoplamento entre classes tende a refletir as rela es que existem entre as abstra es do dom nio do sistema A visibilidade das opera es deve ser p blica para os atores autorizados a desempenhar os ICs correspondentes uma vez que elas se originam diretamente do modelo de requisitos do sistema As opera es determinadas pelos itens derivados n o persistidos regra R4b retornam o valor calculado para o item Os argumentos das opera es podem ser obtidos a partir dos itens presentes no fluxo de entrada dos ICs A especifica o tipo e valor inicial dos argumentos das opera
166. esume os resultados encontrados Dos sete tipos de problemas encontrados no teste de aceita o realizado pelos stakeholders Tabela 6 19 apenas tr s deles est o mais diretamente relacionados com a especifica o do sistema atrav s de ICs 4 Erro de implementa o propiciado pela subespecifica o do DIS 5 Requisito n o implementado propiciado pela subespecifica o do DI e 7 Novo requisito n o apontado inicialmente pelos stakeholders Isso porque a MIC n o tem a pretens o de especificar em detalhe a interface com o usu rio problemas 1 e 2 n o pode ser culpada por erros de implementa o problema 3 e nem pela evolu o natural do sistema e seu ambiente problema 6 O total de ocorr ncias dos problemas 4 5 e 7 foi de 12 50 do total Entretanto acreditamos que o n mero de ocorr ncias dos problemas 4 e 5 poderia ser bem menor se os itens elementares de informa o tivessem sido melhor descritos no DI n o s sua denota o mas tamb m sua conota o LEITE OLIVEIRA 1995 Igualmente achamos que alguns novos requisitos poderiam ter sido elicitados desde o in cio caso os usu rios e stakeholders estivessem mais familiarizados com a t cnica e a nota o empregada na MIC Tabela 6 19 Apura o dos problemas no teste de aceita o do sistema Tipo de problema encontrado Contagem 1 Problema na interface com o usu rio 4 2 Novo requisito da interface com
167. everia ser implementado 9 Descreva o ambiente de implementa o a ambiente de desenvolvimento b linguagem de programa o c banco de dados d Outros a O ambiente de desenvolvimento utilizado o Dreamweaver b As linguagens de programa o utilizadas s o PHP e JavaScript c O banco de dados utilizado o MySQL d Est sendo utilizado AJAX para deixar as p ginas mais din micas e CSS para padronizar o estilo das p ginas 200
168. fluxo de sa da nele Se este n o for o caso ou seja se n o existir opera o construtora no IC ou se ela n o produzir toda a mudan a de estado causada pelo IC ou ainda se existir sa da a produzir designar uma opera o para realizar ou completar a mudan a e produzir a sa da se existir atribuindo lhe um nome derivado do nome do IC sugest o justaposi o da primeira palavra que normalmente um verbo no infinitivo com uma ou mais das palavras seguintes utilizando formata o camel case para manter a legibilidade Exemplo pagarNota Regra semi automatiz vel A es automatiz veis 1 Verifica o de que um IC possui fluxo de sa da A es n o automatiz veis 1 Verifica o de que um IC causa mudan a de estado no sistema 2 Verifica o da exist ncia de opera o construtora gerada pela aplica o da regra R4a ao IC resultado reutiliz vel da regra R4a 3 Verifica o de que uma opera o construtora derivada pela regra R4a aplicada ao IC produz uma dada mudan a de estado no sistema 4 Atribui o de nome opera o produzida Grau de automatismo 1 4 25 ou 1 5 20 no caso de n o se aproveitar resultados obtidos com a aplica o de outras regras An lise de completude A necessidade de efetuar uma mudan a de estado no sistema ainda n o coberta por qualquer opera o presente no MD exige a introdu o nesse modelo de uma nova 105 ope
169. formidade de opera es entre os modelos de classes de cada grupo ou seja obtidos com uma mesma t cnica foi feita a seguir comparando se as m dias lyo ics e Huo ucs Na se o 6 3 3 vimos que UnifO Unif O Unif O Hoo ics 3 e Unif O Unif O Unif O 5 i e Luo ucs onde Unif O representa a uniformidade de opera es entre os modelos produzidos pelos participantes i e j que aplicaram a mesma t cnica ou seja pertenceram ao mesmo grupo experimental sendo dada pela f rmula se o 6 3 1 O Unif O TH O 0p 0 9 Primeiramente com base nos valores da Tabela 6 14 tem se 9 14 11 Uuocs 13 12 9 Litls 5413 11 y Soe 0 6949 146 7 5 2 Loves 27 16 7 22 14 14 2 e 0 0769 _ 0 1367 E agora com base nos valores da Tabela 6 15 que desconsidera as opera es construtoras tem se 3 6 6 Lyoscs 2 7 3 7 7 6 10 8 6 is HET OS END Lisie 3 3 7 2 I 2 Lyo ucs 24 16 7 17 tsa 14 12 2 SA e 0 0833 0 1092 Portanto a uniformidade de opera es entre MDs produzidos pelo grupo que utilizou ICs foi 408 maior do que entre os MDs obtidos com a t cnica tradicional de UCs ou 365 se forem desconsideradas as opera es construtoras Por fim a tabela 6 16 consolida os dados sobre a uniformidade de associa es atributos opera es e representacional considerando se os modelos dos participantes de um mesmo gr
170. gem com UCs ligeiramente distintas entre si publicadas na literatura Mas essas caracter sticas dos UCs tamb m parecem estar na ra z de alguns dos problemas apontados na t cnica como por exemplo interfer ncias indevidas no projeto da interface H C e a fraca contribui o 22 para a a obten o a partir do MUC de um MD consistente e completo em rela o ao MUC Os pr ximos dois cap tulos 3 e 4 aprofundam essas quest es o que permitiu no cap tulo 5 a proposi o de uma especializa o do UC equipada para resolver alguns dos seus problemas e obtida trilhando exatamente o caminho sugerido acima ou seja menor flexibilidade e maior precis o 23 3 Os Problemas Alvo 3 1 Introdu o O contexto considerado nesta tese o do desenvolvimento de sistemas de informa o segundo o paradigma da orienta o a objetos Nesse contexto o modelo de UCs MUC e o modelo de classes de objetos de dom nio MD s o largamente utilizados Em nossa experi ncia anterior na utiliza o desses modelos pudemos perceber algumas dificuldades associadas modelagem de requisitos com UCs bem como dificuldades para utiliza o conjunta de ambos os modelos de forma complementar na fase de elicita o e modelagem de requisitos Isso motivou uma pesquisa de trabalhos publicados na literatura especializada buscando verificar se as mesmas dificuldades eram reportadas por outros autores O resultado dessa primeira pesquis
171. gia de particionamento estritamente top down o Facilita a manuten o do sistema e Favorece o reuso de modelos reuso da ess ncia de sistemas Pela rela o acima identificada entre os particionamentos das duas abordagens AE e MIC acreditamos que as mesmas vantagens da AE podem ser esperadas e mesmo potencializadas no MIC proposto 91 5 5 4 O MIC e a An lise de Requisitos Orientada a Objetivos Na Modelagem de requisitos Orientada a Objetivos MOObj LAMSWEERDE 2001 os objetivos devem ser decompostos at o n vel em que eles possam ser atribu dos a um agente individual seja do sistema requisitos ou do ambiente do sistema suposi es No MIC os objetivos tamb m correspondem a objetivos de um agente individual Entretanto o MIC abstrai os objetivos de agentes do sistema capturando apenas os objetivos dos atores ou seja apenas os objetivos dos agentes do ambiente que interagem com o sistema Outra restri o do MIC o n vel de abstra o em que os objetivos dos atores s o considerados o NIO se o 5 2 Como um objetivo do NIO tamb m atribu do a um ator individual primeira vista parece que o NIO coincide com o n vel m nimo de abstra o adotado na MOObj Entretanto se considerarmos que um objetivo informacional pode subassumir v rios outros objetivos se o 5 2 vemos que a MOObj pode em princ pio incluir objetivos de nivel inferior ao NIO Outra diferen a que enquanto a MOO
172. gra R4b 103 Regra semi automatiz vel A es automatiz veis 1 Determina o dos fluxos de sa da e de seus nomes 2 Verifica o de que um fluxo de sa da constitu do de apenas um item de informa o 3 Atribui o de nome opera o produzida mesmo nome do fluxo ou o nome ce 39 obtido pela elimina o do caracter e ado o do formato camel case para manter a legibilidade Exemplo consumo_diario ou consumoDiario A es n o automatiz veis 1 Verifica o de que o processamento de um IC n o produz mudan a de estado no sistema IC de consulta 2 Verifica o de que um item elementar de informa o n o persistido resultado reutiliz vel de R3a R3b ou R3c Grau de automatismo 3 4 75 ou 3 5 60 no caso de n o se aproveitar resultados obtidos com a aplica o de outras regras An lise de completude Toda sa da representa comportamento que do ponto de vista do MD dever ser desempenhado por uma ou mais de suas opera es Em principio o MD j possui opera es para a produ o ou recupera o do valor dos itens elementares presentes nos fluxos de sa da do MIC itens informados ou derivados e persistidos podem ter seu valor recuperado pelas opera es impl citas de acesso tipo get enquanto itens derivados n o persistidos podem ter seu valor calculado pelas opera es geradas pela regra R4b Portanto a rigor o MD j se encontra completo em r
173. ia Abril a ser publicado 173 DE LA VARA J L FORTUNA M H WERNER C M L et al 2009b A Requirements Engineering Approach for Data Modelling of Process Aware Information Systems In 2th International Conference on Business Information Systems BIS 09 Poznan Poland April to be published DE LANDTSHEER R LETIER E van LAMSWEERDE A 2003 Deriving Tabular Event Based Specifications from Goal Oriented Requirements Models Requirements Engineering v 9 n 2 pp 104 120 DIJKSTRA E W 1968 Go To Statement Considered Harmful Communications of the ACM v 11 n 3 March pp 147 148 DOBING B PARSONS J 2000 Understanding the Role of Use Cases in UML A Review and Research Agenda Journal of Database Management Idea Group Publ v 11 n 4 pp 28 36 FORTUNA M H BORGES M R S 2005 Modelagem Informacional de Requisitos In VIII Workshop on Requirements Engineering WER 2005 pp 269 280 Porto Portugal June FORTUNA M H WERNER C M L BORGES M R S 2007 Um Modelo Integrado de Requisitos com Casos de Uso In X Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes de Software IDEAS 07 Isla de Margarita Venezuela pp 313 326 Maio FORTUNA M H WERNER C M L BORGES M R S 2008a Info Cases Integrating Use Cases and Domain Models In XVI IEEE Intl Conference on Requirements Engineering RE 08 pp 81
174. ia maiores detalhes podem ser obtidos nas refer ncias acima indicadas incluindo todo o material utilizado e produzido durante o estudo ou seja o seu empacotamento 6 3 1 Objetivos Quest es e M tricas Um dos objetivos do estudo foi comparar as duas t cnicas ICs e UCs quanto granularidade e a uniformidade dos MDs por elas produzidos no contexto do desenvolvimento de um sistema de informa o por profissionais graduados em Ci ncia da Computa o pela UFJF Outro objetivo foi comparar o esfor o empregado em cada t cnica para a obten o do MD O esfor o medido pelo n mero de horas gasto por cada participante para obten o do MD A granularidade de um MD medida pelo n mero de classes que o modelo possui ou seja quanto maior o n mero de classes maior a granularidade do modelo J a uniformidade entre MDs expressa o grau de semelhan a entre eles Para uma avalia o abrangente da uniformidade entre MDs foram considerados dois tipos de uniformidade o Uniformidade de abstra es baseada na compara o das abstra es de dom nio existentes em cada modelo a n vel puramente sem ntico e o Uniformidade representacional baseada na compara o de atributos associa es e opera es utilizadas para representar cada abstra o presente nos modelos 127 A uniformidade de abstra es entre dois MDs calculada como a raz o entre o n mero de abstra es coincidentes nos dois model
175. ia de Requisitos ERq uma subarea da Engenharia de Software e cobre todas as atividades envolvidas com o descobrimento elicita o documenta o e manuten o de um conjunto de requisitos para um sistema baseado em computador WIEGERS 2003 Seu dom nio pode ser dividido em desenvolvimento e ger ncia de requisitos O processo de desenvolvimento de requisitos ilustrado na Figura 1 1 ROCCO 2002 apud M KNIGHT 2004 Informa es elicitadas Universo de Informa es Elicita o Modelagem Especifica o as Valida o de Requisitos eee Representa es Representa es validadas Figura 1 1 O Desenvolvimento de Requisitos O pessoal que participa diretamente nas atividades de desenvolvimento da ERq pode ser subdividido nas seguintes categorias que admitem sobreposi o o Cliente que se beneficia direta ou indiretamente do sistema o Usu rio quem usa o sistema o Analista de requisitos respons vel t cnico o Desenvolvedores respons veis pela implementa o dos requisitos no sistema O termo stakeholder tem sido utilizado para designar qualquer pessoa ou organismo capaz de influir direta ou indiretamente sobre os requisitos A atividade de elicita o de requisitos respons vel por juntar negociar e compreender os requisitos comumente considerada a parte mais dif cil cr tica sujeita a erros e dependente de comunica o e colabora o de
176. ica o do estado de um objeto ou de uma associa o entre objetos ocorre nos ICs cuja interface informacional cont m algum item de informa o a persistir ltima configura o relacionada acima Entretanto qualquer IC pode produzir mudan a de estado em um objeto ou associa o entre objetos mesmo inexistindo um item a persistir na sua interface informacional Isso porque a simples ocorr ncia do evento disparador do IC pode implicar a mudan a Obviamente essa mudan a tamb m implementada via um atributo do objeto ou da associa o que pode ser um atributo criado anteriormente para persistir um item da interface ou um atributo especialmente criado para refletir a mudan a Esse ltimo tipo de atributo ser distinguido dos demais atributos ordin rios pela denomina o atributo de estado 79 Portanto diferentemente dos atributos ordin rios que correspondem diretamente a itens de dados a persistir presentes nos fluxos de entrada e de sa da dos ICs os atributos de estado n o aparecem na interface informacional dos objetivos Apesar disso ainda poss vel extrair dessa interface alguma indica o sobre a necessidade de introduzir esse tipo especial de atributo conforme evidencia a regra enunciada a seguir Regra R3e Atributo de estado Para cada IC com interface informacional constitu da apenas de fluxo de entrada contendo exclusivamente um nico identificador deve ser introduzido um atributo de estado em
177. icadores gerados em um IC IC com fluxo de sa da composto apenas por identificadores Heur stica Os identificadores s o gerados no IC No sistema Restaurante Figura 5 2 id pedido identificador gerado no IC 1 Abrir pedido determina a classe Pedido As demais classes determinadas dessa forma 72 s o Cliente id cliente IC 6 Item id item IC 7 e Mesa id mesa IC 10 O grau de acerto da heur stica foi neste caso de 4 4 100 Associa es entre Classes e suas Multiplicidades Os relacionamentos entre os diversos objetos manipulados pelo sistema estar o representados na interface informacional II dos ICs uma vez que eles devem ser necessariamente informados pelos atores ao sistema Por exemplo no sistema Restaurante o relacionamento entre um pedido e a mesa no qual ele feito precisa ser informado ao sistema Como os objetos s o representados por seus identificadores os relacionamentos entre objetos estar o representados pela ocorr ncia de dois ou mais identificadores na interface informacional de cada IC Entretanto enquanto todos os identificadores presentes nos fluxos de entrada devem ser considerados na determina o das associa es nem todos aqueles existentes nos fluxos de sa da s o relevantes Por exemplo fluxos de sa da que n o incluam identificadores gerados n o determinam associa es in ditas ou seja associa es que n o possam ser determinadas pela presen a de identific
178. id funcao PFK id_ativ PFK id_trabEmp PK id_emp FK id funcao FK unid emp nome trab nome mae cd nome pai eek trab_nit Poe trab_cbo a oe ci trab org xp ci trab dt nascTrab sexo trab dt admTrab ctps trab dt cadastro turno trab folga trab regime revez descr cargo dt refSit id disc PK id agente de risco FK discriminante lim tolerancia niv acao dose agente de risco exame clinico id exame cl nico PFK id agente de risco PFK obs agente id prod PK nome prod estado prod id prod PFK id exame cl nico PFK obs prod id laudo PK id exame clinico FK especialidade laudo dt laudo nome medico crm medico conclusao laudo just laudo encaminha laudo progr exames id progr exames PK id medico FK dia semana in cio consultas termino consultas local consultas 183 produto quimico a pressao_arterial id_exame PFK id_exame_clinico PFK perexame just_per_exame recom prest recom trab causa pend obs pedido just exame id exame clinico PK id medico FK id trabEmp FK motivo consulta ectoscopia hpp_hma hist prof hist familiar freq card deficiencia exposto risco c obs riscos dif ppra descr dif sit trab doenca prof afastado nr diasAfast emitir cat orientacao per cons just perCons dt consulta clinico pend alter clinica antigo id medico PK nome med cpf med cr
179. iente informa o com maior variety Essas caracter sticas exploram ao m ximo a capacidade modeladora da MIC tanto no particionamento funcional do sistema em processos quanto na deriva o de um modelo de classes de objetos n o trivial Os sistemas interativos de informa o s o portanto o principal alvo para aplica o da modelagem informacional de requisitos A linha divis ria entre os sistemas de controle e os sistemas de informa o n o necessariamente t o precisa como d a entender a Figura 5 4 Muitas vezes um sistema 37 Normalmente pode se estabelecer um mapeamento entre uma informa o de controle e a a o correspondente a ser tomada pelo receptor da informa o 88 de controle tamb m possui partes que podem ser caracterizadas como sendo subsistemas de informa o por comunicarem ao seu ambiente informa es com alta variety destinadas a atores humanos que com ele interagem 5 5 3 An lise Essencial Uma Id ia Precursora O modelo de info cases MIC proposto se baseia no particionamento da funcionalidade do sistema induzido pelos crit rios apresentados na se o 5 2 A topologia do particionamento do sistema em processos segundo esses crit rios Figura 5 1 se o 5 2 a mesma topologia que caracteriza o particionamento do sistema nas atividades essenciais da An lise Essencial AE de Sistemas MCMENAMIM PALMER 1991 Nessa topologia os processos s se comunicam atrav s de
180. if A Unif A Unif A 3 Ri Unif A Unif A t Unif A 3 Hua ics Hua ucs Uniformidade de atributos Hip tese Nula H Uat N o h diferen a na uniformidade de atributos dos MDs produzidos com ICs em rela o aos MDs produzidos com UCs Hip tese Alternativa H U A uniformidade de atributos dos MDs produzidos com ICs maior do que a uniformidade de atributos dos MDs produzidos com UCs Formalmente Ho Uat uat ics Huat ucs Hi Uat Huarics gt Huat ucs onde puat Ics Uua ucs s o as m dias das uniformidades de atributos entre pares distintos de 132 MDs obtidos com ICs e com UCs respectivamente pares resultantes da combina o dois a dois dos modelos de cada grupo Para o estudo em quest o onde os participantes 1 2 e 3 aplicaram ICs e os participantes 4 5 e 6 aplicaram UCs as m dias acima podem ser representadas pelas f rmulas a seguir Unif At Unif At Unif At e LHuat ICs 3 5 Unif At Unif At Unif At Uua Ucs gt 3 E As hip teses para uniformidade de associa es Ho U e H U uniformidade de opera es Ho U e H U e uniformidade representacional Ho U e H U bem como a computa o das respectivas m dias s o definidas de forma an loga 6 3 4 Design do Estudo Trata se de um quasi experimento do tipo um fator com dois tratamentos WOHLIN et al 2000 ou seja uma nica vari vel independ
181. ificadores da associa o gerados no fluxo de sa da do IC com um deles digamos id no escopo de uma repeti o em rela o ao outro id Heur stica sugere multiplicidade Os limites inferior e superior da multiplicidade no lado da classe identificada por id s o respectivamente o n mero 663699 m nimo e maximo de repeti es especificados ou respectivamente 0 e na falta dessa especifica o A multiplicidade do lado de id ser 0 1 ou 1 1 caso id seja condicional ou n o respectivamente Padr o sint tico R2 P8 Ocorr ncia de R2 P4 identificadores da associa o gerados no fluxo de sa da do IC com nenhum deles no escopo de uma repeti o em rela o ao outro Heur stica sugere multiplicidade Os limites inferiores das multiplicidades s o 0 ou 1 dependendo do identificador correspondente ser condicional ou n o respectivamente os limites superiores n o s o sugeridos Os padr es sint ticos R2 P7 e R2 P8 n o ocorrem no sistema Restaurante Atributos das Classes A ativa o de ICs depende da iniciativa de algum ator e portanto nenhuma suposi o geral pode ser embutida no sistema sobre a co exist ncia no tempo dos processos subjacentes aos ICs Consegiientemente todo item de informa o a ser comunicado entre esses processos deve ser considerado informa o de estado ou seja informa o persistida nos estados do sistema alcan ados pela exe
182. irem Esta regra tamb m tem o papel de apontar as classes de associa o que devem fazer parte do MD Regra R3d Aloca o de atributo Cria o de classe de associa o Cada item a persistir presente na interface informacional de um IC deve ser alocado como atributo de uma das classes alcan adas pelos identificadores presentes nessa mesma interface Caso nenhuma dessas classes comporte o item ele deve ser alocado em uma nova classe de associa o criada para esse fim correspondente a uma associa o existente entre as classes alcan adas Padr o sint tico R3d Pl O item a persistir est juntamente com um identificador no escopo de uma repeti o em rela o a outro identificador Heur stica Alocar o item como atributo da classe de associa o determinada por esses identificadores Padr o sint tico R3d P2 O item a persistir est no fluxo de entrada e o IC tem fluxo de sa da com um ou mais identificadores gerados Heur stica Alocar o item como atributo de uma das classes identificadas pelos identificadores gerados Pela multiplica o de um pelo outro 3 Representam uma associa o entre objetos de duas outras classes n o necessariamente distintas Exemplo a classe Pedido Item vide Figura 5 3 78 Padr o sint tico R3d P3 O IC n o tem identificador gerado e o item a persistir est em um fluxo com apenas um identificador Heur stica Alocar o item como um atributo de uma das classes a
183. is agora os usu rios e stakeholders devem ler e compreender uma especifica o escrita em uma linguagem semiformal Entretanto acreditamos que esse impacto pequeno se comparado aos benef cios da utiliza o do MIC A experimenta o com o MIC relatada no cap tulo 6 demonstrou que mesmo pessoas sem maior conhecimento em computa o s o capazes de assimilar e usar mediante um breve treinamento essa linguagem e as especifica es dela resultantes LAUESEN 2002 a considera uma linguagem aceit vel para muitos usu rios e afirma que mesmo aqueles sem forma o espec fica em tecnologia da informa o acham as especifica es produzidas mais f ceis de compreender do que modelos E R Por ltimo existe a possibilidade de parafrasear automaticamente as descri es formais em linguagem natural tornando as acess veis a leitores menos afeitos a formalismos Outro aspecto a considerar a completude dos modelos produzidos com a t cnica de ICs o modelo de ICs MIC e o MD dele derivado Sendo um modelo de requisitos o MIC pode ser considerado a primeira representa o dos requisitos dos stakeholders para o sistema e portanto inexiste uma especifica o anterior em rela o a qual se possa apurar a completude externa do MIC No caso do MD podemos avaliar a sua completude em rela o ao MIC Para isso podemos utilizar a seguinte defini o adaptada de GLINZ 2000 se o 4 4 um modelo est parcialmente completo em
184. ise da opera o anterior Sistema financeiro Atributo parc_vlVariavel classe Inclus o Esta informa o precisou ser adicionada devido a necessidade de se Parcela recebimento N o entendi De onde veio essa necessidade Como refleti la no MUC saber a quais itens de cobranga valorados uma parcela de recebimento esta associada Caso ela seja uma parcela de valores vari veis sabe se que ela esta associada a itens de cobran a valorados pagos por ocorr ncia Caso contr rio existe associa o com itens de cobran a valorados pagos por seus valores globais n o pagos por ocorr ncia No IC25 Cadastrar disponibiliza o de servi os a cliente e IC28 Efetivar disponibiliza o de servi os a cliente as parcelas geradas n o s o parcelas de valores vari veis enquanto que no IC27 Informar parcelas de valores vari veis elas s o 196 Ap ndice 6 Planilha dos Testes de Aceita o EC 3 TESTES DE ACEITA O DO SISTEMA 14 10 2008 OO IC E P Nome A Observa es Elem l 9 F cliente O cadastramento de contatos deveria ser feito na mesma tela do cadastramento de cliente 1 PROBLEMA DA INTERFACE COM O USU RIO 1 Ap s o cadastramento de um cliente empregador pessoa fisica a consulta n o mostrou ele a Regina acha que isso se d antes do cliente ter um servi o cadastrado o que acontece hoje no sistema 3 ERRO DE IMPLEMENTA O ou
185. istema por decis o justificada do modelador com base no MIC um elemento que apesar de tratado pelas regras n o p de ser obtido atrav s delas Se isso acontecer ent o existe uma incompletude omiss o na vis o MD do MIC 150 2 O MD ter um elemento obtido com a aplica o das regras exclu do ou alterado ao longo do desenvolvimento do sistema por decis o justificada do modelador com base no MIC Se isso acontecer existe uma inconsist ncia na vis o MD do MIC Portanto por essa defini o para se ter uma avalia o sobre a adequa o da vis o MD do MIC ser preciso registrar e analisar toda altera o que o MD venha a sofrer desde a sua deriva o utilizando as regras logo ap s a elabora o do MIC at o t rmino do processo de implementa o do sistema Se a altera o puder ser enquadrada em uma das duas situa es acima ent o ela indica a exist ncia de uma incompletude situa o 1 ou inconsist ncia situa o 2 da vis o MD e nesse caso o passo seguinte dever ser analisar o que levou ocorr ncia da situa o indesejada e propor altera es nas regras de forma a evitar que a situa o volte a acontecer 6 4 2 O Sistema Utilizado no Estudo O sistema utilizado no estudo um sistema para o controle financeiro da empresa envolvendo recebimentos de clientes por servi os prestados e pagamentos a fornecedores dos diversos recursos demandados pela empresa O sistema permite controlar ca
186. itens elementares n o identificadores e de sa da em cada IC A es n o automatiz veis 1 Verifica o da condi o de um item elementar n o identificador e de sa da ser derivado em contraposi o a ser informado 2 Verifica o da condi o de um item derivado em um IC representar uma informa o hist rica n o restaur vel nesse IC Grau de automatismo 1 3 33 An lise de completude regras R3a R3b e R3c Todo item elementar n o identificador presente no MIC informado ou derivado cuja persist ncia seja necess ria entre estados firmes do sistema ser mapeado pelas regras R3a R3b ou R3c em um atributo de classe no MD e portanto o MD estar completo em rela o ao MIC no que diz respeito aos atributos provenientes da persist ncia desses itens elementares Por outro lado como todo atributo ordin rio resulta do mapeamento de itens elementares n o identificadores sejam itens informados regras R3a e R3b ou itens Atributo que n o de estado regra R3e 98 derivados regra R3c o MIC tamb m estar completo em rela o ao MD no que diz respeito a esses atributos O fato do MD s conter atributos ordin rios provenientes da aplica o das regras R3a R3b e R3c pode ser justificado como segue Se um atributo ordin rio presente no MD n o resultar da aplica o das regras R3a R3b ou R3c porque as tr s condi es seguintes ocorrem a O item de informa o corre
187. ito o pressuposto de normalidade e uma vez que as vari ncias s o iguais pode se proceder a an lise de compara o das m dias das duas amostras gerando um novo teste de hip teses a um n vel de signific ncia de 5 sendo HO As m dias s o iguais Lr cnical HT cnica H1 As m dias s o diferentes Lr cnical MT cnica2 122 Retornando Tabela 6 3 percebe se na primeira linha que corresponde confirma o de que as vari ncias das amostras s o iguais que a signific ncia do Teste T Sig 2 tailed inferior a 0 05 e desta forma rejeita se a hip tese nula concluindo se que as m dias s o diferentes a um n vel de signific ncia de 5 A Tabela 6 4 apresenta o complemento da an lise do Teste T mostrando o valor das m dias A m dia da vari vel cobertura foi de 12 93 fun es cobertas no crit rio de eventos aut nomos contra 10 35 fun es cobertas no crit rio de valor Conclui se portanto que o crit rio dos eventos aut nomos produz cobertura funcional maior aproximadamente 25 maior do que o crit rio de valor a um n vel de signific ncia de 5 Al m disso a cobertura variou menos no crit rio dos eventos aut nomos menor desvio padr o Tabela 6 4 Complemento da an lise do Teste T Group Statistics Std Error tecnica Mean Std Deviation Mean cobertura 1 20 10 35 2 961 662 2 15 12 93 2 314 097 An lise Estat stica para a Vari vel Granularidade A Figura 6 2 apres
188. iva H G A granularidade dos MDs obtidos utilizando ICs menor do que a granularidade dos MDs obtidos utilizando UCs Formalmente Ho G Uc ics Ua ucs e Hi G uc ics lt Uc ucs onde UGics a m dia das granularidades dos MDs obtidos com ICs e ua ucs a m dia das granularidade dos MDs obtidos com UCs Para o estudo em quest o onde os participantes 1 2 e 3 aplicaram ICs e os participantes 4 5 e 6 aplicaram UCs as m dias acima podem ser representadas pelas 131 f rmulas a seguir onde C o n mero de classes existentes no MD produzido pelo participante 1 Hc ICs Ses E S Es Ho ucs e y Uniformidade de abstra es Hip tese Nula H U N o h diferen a na uniformidade de abstra es dos MDs produzidos com ICs em rela o aos MDs produzidos com UCs Hip tese Alternativa H U A uniformidade de abstra es dos MDs produzidos com ICs maior do que a uniformidade de abstra es dos MDs produzidos com UCs Formalmente Ho Ua Lua ics Hua ucs Hi Ua Hua iCs gt Mua ucs onde puya ics Hua ucs s o as m dias das uniformidades de abstra es entre pares distintos de MDs obtidos com ICs e com UCs respectivamente pares resultantes da combina o dois a dois dos modelos de cada grupo Para o estudo em quest o onde os participantes 1 2 e 3 aplicaram ICs e os participantes 4 5 e 6 aplicaram UCs as m dias acima podem ser representadas pelas f rmulas a seguir Un
189. iva nos diagramas Jude cujo nome inclui a data de 09 06 08 estava sendo implementado viu se a necessidade do usu rio visualizar nesse momento os servi os associados a uma disponibiliza o de servi os Entretanto este m todo ainda foi mantido na classe Parcela recebimento pois as parcelas de recebimento podem n o estar associadas a todos os itens de cobran a valorados da disponibiliza o de servi os Por exemplo as parcelas geradas partir do IC27 Informar parcelas de valores vari veis estar o associadas apenas aos itens de cobran a valorados que s o pagos por ocorr ncia da disponibiliza o de servi os J as parcelas geradas no IC25 Cadastrar disponibiliza o de servi os a cliente e no IC28 Efetivar disponibiliza o de servi os a cliente estar o associadas somente aos itens de cobran a valorados que n o s o pagos por ocorr ncia da disponibiliza o de servi os No IC1 a escolha de uma parcela de recebimento feita pelo usu rio escolhendo inicialmente a disponibiliza o de servi os correspondente o que vem acompanhado da listagem dos servi os associados aos itens de cobran a obtida com a opera o descr mov 193 Identifica o do s elemento s envolvido s na manuten o Tipo de manuten o An lise MUC MD 3 Mode lo de Implementa o 01 09 08 nome _itemC Inclus o Esse item j estava no MD partir de outro
190. ivocadas a partir de alguns ICs com mais de um identificador gerado no fluxo de sa da Al m disso ambas as regras R2a e R2b prev em a possibilidade de gera o de associa es redundantes no caso de mais de dois identificadores gerados ou no fluxo de entrada respectivamente Em vista disso decidimos elaborar uma vers o menos deterministica para a regra capaz de evitar os erros da vers o anterior e de possibilitar com base no particionamento do sistema em ICs se o 5 2 uma argumenta o segura sobre a sua validade se o 5 4 2 Entretanto o conhecimento embutido na regra R2a foi mantido na forma de heur stica aplic vel quando ocorrer na interface informacional de um IC o padr o sint tico nela previsto se o 5 4 2 Multiplicidade das associa es As tr s regras de multiplicidade que vigoravam anteriormente estavam baseadas na vers o anterior das regras de cria o de associa es R2a e R2b vide acima Quando essas ltimas foram transformadas em heur sticas as regras de multiplicidade tamb m passaram a ter esse status mantendo o mesmo conte do Determina o da persist ncia de itens de informa o Anteriormente ao estudo as duas regras a seguir determinavam a persist ncia dos itens elementares de informa o informados ou derivados respectivamente R3a Determina o de persist ncia item de entrada Todo item elementar n o identificador e de entrada que for necess rio em um
191. ixa e bancos e produz um fluxo financeiro para um per odo escolhido Faz a ger ncia dos servi os prestados a cada cliente relacionando os com contratos firmados com eles Gera notas fiscais e boletos para pagamento pelos clientes dos servi os prestados e calcula a comiss o devida a vendedores Outra fun o do sistema gerar a previs o de receitas e pagamentos para o pr ximo ano de forma que os gerentes possam estabelecer com a devida anteced ncia metas a serem cumpridas para a obten o dos resultados financeiros desejados O MIC do sistema cont m 29 ICs perfazendo 39 p ginas de especifica o At o momento em que esta tese estava sendo escrita novembro 08 j tinham sido implementados 15 ICs em aproximadamente 9 500 linhas de c digo PHP representando algo em torno de 60 do sistema 6 4 3 Sele o de Participantes Prepara o e Execu o Os participantes do estudo constitu ram duas equipes uma para cada etapa do desenvolvimento do sistema A primeira equipe equipe 1 foi a respons vel pela elabora o dos ICs e aplica o das regras de deriva o para obten o da vis o MD do MIC Ela foi formada por tr s profissionais dois deles analistas de sistemas 151 pertencentes ao quadro da empresa e mais o autor desta tese daqui em diante tamb m referido como experimentador Um dos analistas da empresa graduado em Ci ncia da Computa o e o outro estava em fase final de conclus o do mesmo curs
192. l do MD correspondente a um AG 33 escondidas ou impl citas sobre a interface do usu rio a ser projetada posteriormente Tais suposi es s o decis es prematuras de projeto que ficam embutidas nos requisitos dificultando a modifica o ou a adapta o das mesmas durante a fase de projeto da interface do usu rio EUCs foram concebidos para evitar esse problema O termo essencial indica a inten o de capturar apenas a ess ncia do sistema atrav s de descri es idealizadas abstratas livres de tecnologia Os autores prop em uma t cnica inspirada em CRC class responsibility collaborator BECK CUNNINGHAM 1989 para a distribui o das responsabilidades do sistema entre classes de objetos realizando assim uma an lise OO preliminar do sistema a partir dos EUCs As responsabilidades de um objeto incluem o conhecimento que ele deve possuir atributos e as a es que ele deve realizar opera es WIRFS BROCK et al 1990 O procedimento proposto inicia com apenas uma classe representando todo o sistema qual s o atribu das todas as responsabilidades extra das da descri o dos EUCs Em seguida como no CRC outras classes candidatas s o identificadas e as responsabilidades s o compartilhadas ou delegadas em v rias itera es at que o modelo atinja um estado suficientemente est vel An lise A proposta n o estabelece qualquer rastro formal entre elementos dos dois modelos Entretanto rastros podem
193. lagem escolhido estrutural comportamental funcional do usu rio e de contexto Entretanto como todo diagrama exibido apenas uma vis o do modelo integrado foi poss vel embutir na linguagem do m todo regras fortes de consist ncia e de completude e construir ferramentas poderosas para a verifica o e manuten o dessas regras Permitir aos usu rios expressar diferentes partes de uma especifica o com um grau vari vel de formalidade adaptado a import ncia e ao risco de cada parte As especifica es em ADORA podem misturar texto informal e com outras nota es formais Por exemplo transi es de estado podem ser especificadas atrav s da nota o formal de statecharts ou informalmente com texto ou ainda uma combina o de ambas Portanto a MIC tem v rios pontos em comum com ADORA A come ar e principalmente pela utiliza o de um modelo integrado Conseqiientemente os mesmos benef cios reivindicados para ADORA decorrentes dessa op o tamb m valem para a MIC Outro ponto em comum a mistura de especifica es formais e informais no modelo integrado Por fim ADORA assim como a MIC est baseada no reconhecimento de que comportamento e informa o devem ser considerados conjuntamente em uma especifica o de requisitos cc cen rios e objetos s o complementares em uma especifica o Os cen rios especificam est mulos que os atores enviam ao sistema e as rea es do sistema a
194. lcan adas por esse identificador No sistema Restaurante Figura 5 2 por exemplo quant item IC 1 deve ser alocado na classe de associa o Pedido item correspondente associa o entre as classes alcan adas Pedido e Item criada para conter esse atributo padr o sint tico R3d P1 classes alcan adas pelos identificadores id pedido e id item dt pedido IC 1 deve ser alocado na classe Pedido padr o R3d P2 classe identificada por id pedido pc item IC 11 deve ser alocado na classe Pedido Item padr o R3d P1 classe de associa o determinada pelos identificadores id pedido e id item e dt pagto IC 4 na classe Pedido padr o R3c P3 classe alcan ada por id pedido etc O grau de acerto proporcionado pelos padr es sint ticos foi de 9 9 100 A execu o do processo subjacente a um IC sempre produz mudan a de estado seja do sistema ou do ambiente que com ele interage pois corresponde ao alcance de um objetivo de algum stakeholder A presente se o mostrou at agora que poss vel detectar o tipo de mudan a de estado no sistema pela configura o da interface informacional dos ICs o Cria o de objetos interfaces com pelo menos um identificador gerado no fluxo de sa da o Cria o de associa o entre objetos interfaces com pelo menos dois identificadores o Modifica o do estado de um objeto ou de uma associa o entre objetos interfaces com algum item a persistir Comumente a modif
195. leitura dos objetivos informacionais de um sistema em fase de manuten o Primeiramente um dos analistas aplicou as regras utilizando a especifica o informacional de um sistema de biblioteca com 19 objetivos informacionais fornecida pelo experimentador O modelo de classes obtido foi comparado com o modelo de classes constru do previamente pelo experimentador pela aplica o das mesmas regras As diferen as detectadas revelaram dificuldades do analista na compreens o de algumas regras o que motivou a revis o do manual de regras Posteriormente e com o manual revisado o outro analista executou o mesmo 54 autor desta tese 115 estudo Para avaliar a uniformidade dos resultados foram contadas as diferen as entre o modelo obtido por cada analista e o modelo constru do pelo experimentador Consideramos diferen a para fins dessa avalia o os elementos classes atributos associa es e opera es a mais ou faltando em rela o ao modelo produzido pelo experimentador A Tabela 6 1 apresenta os resultados dessa avalia o Tabela 6 1 Resultados do Estudo Precursor 2 Analista 1 Analista 2 Legenda Elementos E HD S ED S HE Nr de elementos no modelo do Classes 5 0 100 0 100 experimentador Associa es 11 1 91 0 100 HD Nr de diferen as Atributos 20 4 80 0 100 S Perc de sucesso em reproduzir o Opera es 41 4 90 1 97 modelo do experimentador
196. lidar as constela es de objetos durante a valida o dos UCs o MD parcialmente validado tamb m An lise Rastros formais entre os dois modelos s o estabelecidos apenas para as opera es das classes Em um primeiro momento a determina o das classes continua sendo feita de forma ad hoc a partir do conhecimento adquirido pelo analista sobre o dominio ou por sugest o de nomes presentes na descri o dos UCs Depois o m todo ajuda a refinar esse primeiro MD durante a inspe o manual dos AG s enriquecidos com cen rios e constela es de objetos O m todo envolve um esfor o consider vel do analista para obter os AG s o que n o pode ser automatizado O MD n o propriamente validado mas apenas verificado em rela o ao modelo validado de UCs From Essential Use Cases to Objects BIDDLE NOBLE 2002 Esta proposta utiliza o modelo de UCs essenciais Essential UCs EUCs produzido na fase de requisitos para derivar um MD do sistema como um modelo preliminar de projeto UCs essenciais EUCs fazem parte do m todo de Projeto Centrado em Utiliza o Usage Centered Design desenvolvido por CONSTANTINE e LOCKWOOD 1999 Sua motiva o decorreu de limita es identificadas por esses autores nos UCs convencionais Em particular UCs tipicamente cont m suposi es Qs autores n o definem o que vem a ser constela es de objetos de dominio mas tudo indica que seja uma vis o parcia
197. lise das propostas que tentam promover a consist ncia entre os dois modelos vide se o 3 3 nos permite concluir que l Quando se tenta derivar automaticamente o MD a partir do MUC o resultado um modelo muito incompleto Todas as propostas que visam certa automatiza o desse processo de transforma o utilizam alguma forma de an lise ling stica por exemplo K RKK INEN et al 2008 sabidamente incapaz de levar a resultados conclusivos Ou seja a maior parte da obten o do MD fica a depender da interpreta o do modelador 2 Quando se tenta verificar a consist ncia entre os dois modelos obtidos em separado novamente a parte pass vel de automatiza o minima Em outras palavras os rastros formalmente identific veis entre os dois modelos s o 46 poucos Isso fica evidente no trabalho de GLINZ 2000 descrito na se o 3 3 2 Apesar dessas dificuldades poder se ia argumentar que a n o automatiza o da obten o do MD ou da verifica o da consist ncia entre ele e o MUC n o um i 12 as problema real ou seja que por serem esses modelos muito diferentes essa obten o e verifica o precisam mesmo ser feitas manualmente pelo modelador com base no seu conhecimento do sistema pretendido e do dom nio onde ele se insere Mas se assim o MD como qualquer modelo de requisitos precisa ser validado pelos stakeholders E essa valida o leva a outros questionamentos A valida o
198. lizados A modelagem por casos de uso inclui al m do diagrama de casos de uso uma descri o de cada caso de uso e a extra o de cen rios Esse tipo de modelagem est focado em objetivos para evitar que os modeladores passem a considerar solu es antes de aprofundar a compreens o dos requisitos ERq e Cen rios Segundo LEITE et al 2000 cen rios descrevem situa es que ocorrem no universo de discurso dom nio da aplica o Um cen rio tamb m comumente definido como um caminho l gico atrav s de um caso de uso BITTNER SPENCE 2002 Com cen rios poss vel raciocinar e argumentar com base em exemplos ou detalhes espec ficos do mundo real durante o processo cognitivo de generaliza o SUTCLIFFE 2003 Cen rios s o teis para mostrar como o sistema ir se comportar na pr tica Cada cen rio pode ser visto como um caso de teste sendo assim um subs dio importante para o teste de um sistema BITTNER SPENCE 2002 Uma pesquisa NEILL LAPLANTE 2003 indicou que eles s o utilizados juntamente com casos de uso em 50 dos projetos levantados A especifica o da linguagem UML incorporou o conceito a partir da sua vers o 2 0 OMG 2008 ERq e Modelagem Organizacional Casos de uso use cases UCs focam os requisitos de um sistema que por sua vez deve atender a requisitos mais amplos os requisitos organizacionais Normalmente considera se que a ERq deve modelar aspectos organizacionais vi
199. logia descrita na se o anterior A nosso ver esses trabalhos d o uma vis o representativa da pesquisa sobre a utiliza o dos dois modelos na fase de requisitos 29 A seguir fazemos um breve relato de cada trabalho focando principalmente os seguintes t picos o O papel do MD na fase de requisitos o A obten o de elementos do MD a partir do MUC o O estabelecimento de rela es ou rastros formais entre os dois modelos o A consist ncia entre os dois modelos e A valida o do MD Cada relato abaixo seguido de uma breve an lise do trabalho correspondente No final da se o a Tabela 3 1 mostra quanto cada trabalho avan a no sentido de estabelecer rela es ou rastros formais entre o MUC e o MD A Lightweight Approach to Consistency of Scenarios and Class Models GLINZ 2000 Glinz adota a vis o de que o MUC e o MD devem ser utilizados de forma complementar e estabelece uma s rie de regras a serem seguidas durante a sua constru o em paralelo para promover a consist ncia entre eles durante o processo construtivo Glinz destaca o fato de se tratarem de modelos n o completamente formais para justificar a defini o de consist ncia adotada Ent o para ele os dois modelos s o consistentes se l N o existirem contradi es entre a informa o presente no MUC e a informa o presente no MD tanto no compartilhamento de informa o quanto na intera o entre os modelos e ER N o houver in
200. m UCs essa valida o retomada e de forma mais efetiva pois agora a compreens o do problema maior tanto por parte dos desenvolvedores quanto dos stakeholders 2 4 2 Problemas da MUC Alguns problemas da modelagem de requisitos com UCs MUC t m sido apontados frequentemente na literatura dentre os quais destacamos o Indu o decomposi o funcional Muito facilmente os modeladores s o levados a tratar os UCs como se fossem fun es e a decomp los em outros de n vel mais baixo o Interfer ncia no projeto da interface H C Muitos modeladores descrevem UCs comprometidos com uma interface H C espec fica e Diversidade de abordagens para a MUC Existem muitas abordagens distintas para a modelagem com UCs algumas delas conflitantes entre si Transi o dif cil para o modelo de objetos do dom nio MD do sistema O MUC tem se mostrado um ponto de partida fraco para a obten o do MD do sistema Os tr s primeiros problemas s o detalhados a seguir enquanto que o ltimo pela sua import ncia para esta tese ser discutido em profundidade no pr ximo cap tulo Indu o decomposi o funcional A decomposi o funcional de um sistema inerente modelagem com UCs Essa modelagem envolve pelo menos dois n veis de decomposi o funcional No primeiro n vel o sistema decomposto em um conjunto de UCs onde cada UC abstrai 20 um processo subjacente que realiza a funcionalidade do UC No seg
201. m a institui o do NIO N vel Informacional de Objetivos resultante da determina o dos UCs segundo tr s crit rios enunciados se o 5 2 A continua o da presente se o mostra a linguagem semiformal adotada para cumprir a segunda provid ncia e ilustra sua utiliza o atrav s de um sistema simples de ger ncia de restaurante especialmente concebido para isso Esse sistema possui dois atores o gerente do restaurante e o cliente e deve prover as seguintes funcionalidades a Registrar o pedido de pratos e bebidas de cada cliente Dever tamb m ser feita a emiss o de um ticket de fechamento quando o cliente solicitar a conta b Cancelar um pedido por solicita o do cliente c Registrar o pagamento ou a pendura da conta do cliente A pendura facultada apenas aos clientes considerados habituais do restaurante d Emitir um relat rio detalhado do consumo di rio de pratos e bebidas para fins de reposi o de estoque e Emitir um relat rio detalhado da receita do restaurante em um dado per odo separando a receita realizada daquela a realizar pelo pagamento de contas penduradas f Registrar o card pio em vigor permitindo sua emiss o por iniciativa do gerente A especifica o da interface informacional de um UC constitu da das duas partes listadas a seguir e ilustradas na Figura 5 2 e na Tabela 5 1 respectivamente para o sistema Restaurante o Especifica o da composi o dos fluxos e
202. m com o sistema Embora a primeira categoria de propostas seja a mais popular a segunda categoria tem um representante de destaque os Casos de Uso Essenciais CONSTANTINE 2000 BIDDLE NOBLE 2002 14 A maioria das propostas de UCs d pouca ou nenhuma aten o informa o trocada entre os atores e o sistema conforme observa LAUESEN 2002 pp 100 132 432 e HAY 2003 pp 43 185 240 entre outros Nessa categoria est o propostas como as contidas em JACOBSON et al 1992 JACOBSON et al 1994 ROBERTSON ROBERTSON 1999 JACOBSON NG 2004 COCKBURN 2005 OMG 2008 e ROBERTSON ROBERTSON 2006 Dentre as propostas que enfatizam a import ncia do detalhamento da informa o se destaca a proposta contida em BITTNER SPENCE 2002 Tamb m variam os crit rios adotados para a escolha dos UCs Um dos crit rios mais comumente recomendados para isso o UC ter um valor mensur vel para algum stakeholder adotado por exemplo em JACOBSON et al 1994 BITTNER SPENCE 2002 JACOBSON 2004 JACOBSON NG 2004 e OMG 2008 Com base na An lise Essencial MCMENAMIM PALMER 1991 outro crit rio sugerido em ROBERTSON ROBERTSON 1999 ROBERTSON ROBERTSON 2006 cada UC deve corresponder a uma atividade essencial Na mesma linha segue HAY 2003 mas enquanto os ROBERTSON 1999 pp 76 permitem a decomposi o dos UCs do n vel essencial em outros de n vel mais baixo HAY 2003 pp 262 afirma que
203. m med inscr mt tel resid tel cel tel comerc resid med localTrab med cidade med estado med 3 1 id_exame PK id_result_exame PK material id_exame FK mat_exame id_exame_clinico FK nome exame E id trabEmp FK amb03 exame dt exame tempo est normal laudo compl conduta exame obs result exame compl alter exame id exame PFK id alterEx PFK id_alterEx PFK id_result_exame PFK dados_alter Mm id alterEx PK ocupacional nome alter evolucao Ped cid alter 4 a S id_alter P sistema_alter Z sigla_alter nome alter id defic PK id alter PFK cid alter id exame clinico PFK cat defic sigla defio did defic PFK Ae ade id_exame_clinico PFK habilitado restr trab exame clinico id restrTrab PFK id exame clinico PFK id restrTrab PK sigla restr descr restr o doenca prof did exame clinico PFK id doenca prof PK id cid PK id doenca prof PFK nome doenca cod cid descr cid PROJECT mel MODEL mel SUBMODEL Main model AUTHOR claudio ferraz victor emanuel gilmar pedretti patricia curvelo horTrab med id horTrab med PK a o id medico FK COMPANY mel VERSION 1 4 CREATED 4 10 2004 UPDATED 3 2 2005 dia_semana inicio_trabalho termino_trabalho 184 Ap ndice 3 Instrumentos do Estudo 2 EXP 2 Question rio de Caracteriza o dos Participantes uestion rio Experi ncia pr via no dom ni
204. m o UC de extens o ou seja deve ser completo e prover valor a seus atores sem que para isso tenha de se apoiar no UC que o estende Diferentemente do que acontece no relacionamento include o UC b sico n o toma conhecimento da exist ncia dos UCs que podem estend lo O relacionamento generalization generaliza o permite criar descri es gen ricas de comportamento que podem ser especializadas para atender necessidades espec ficas A motiva o para generalizar UCs surgiu principalmente da necessidade de se descrever fam lias de sistemas nas quais diversas vers es de um sistema podem ser vistas como especializa es de uma nica descri o geral do sistema Em geral se considera que os tr s ltimos tipos de relacionamento promovem a reutiliza o de descri es ao mesmo tempo em que simplificam os UCs envolvidos Al m do diagrama de UCs o MUC tamb m inclui uma especifica o descrevendo cada UC nele contido Embora a descri o de um UC possa utilizar nota es semi formais tais como diagramas de intera o de atividades ou m quinas de estado ou ainda uma combina o delas na pr tica prevalece a forma de narrativa com texto em linguagem natural estruturado em se es A seguir apresentada a descri o de um UC que adota um esquema de descri o proposto em BITTNER SPENCE 2002 11 CASO DE USO Cadastra novo exemplar Descri o Descreve o cadastramento de um novo exemplar de liv
205. mas interativos de informa o Informa o variety Sistemas batch Figura 5 4 Aplicabilidade da MIC Sistemas de processamento em lote S o sistemas caracterizados por um baixo n vel de intera o mais especificamente a intera o do sistema com o seu ambiente ocorre apenas em dois momentos no in cio da execu o com a entrada dos dados a processar e no fim da execu o com a sa da dos resultados A modelagem informacional nesse caso n o produz particionamento funcional pois identifica apenas um evento aquele correspondente a ativa o inicial do sistema Conseqiientemente o sistema visto como constitu do de um nico processo respons vel pela sua execu o do in cio ao fim Outra caracter stica desse tipo de sistema n o demandar armazenamento persistente de dados o que facilmente percebido na modelagem informacional pelo fato de existir apenas um evento externo Ou seja esse tipo de 87 sistema prescinde da capacidade da MIC em derivar um modelo de classes de objetos para o sistema Sistemas de controle de processos e ou dispositivos Esses sistemas se caracterizam pela predomin ncia da informa o de controle na comunica o do sistema com o seu ambiente Segundo a Teoria da Informa o informa o a quantidade de variety variedade diversidade em uma comunica o sendo variety o n mero de estados que uma situa o pode ter HAY 2003 pp 210 A comunica o de inf
206. mento id pedido vl entregue dt pagto troco ATOR Cliente IC 5 Pendurar a nota gt pendura id pedido id cliente ATOR Gerente IC 6 Cadastrar cliente habitual gt cliente nome cliente tel cliente id cliente ATOR Gerente IC 7 Atualizar o card pio gt item consumo nome item pc unit cat item descr item id item ATOR Gerente IC 8 Solicitar consumo di rio gt solic consumo dt emissao dt consumo consumo dia dt emissao dt consumo consumo itens Z consumo itens ofcat item fid item nome item quant itemJ TOR Gerente IC 9 Solicitar receita solic receita dt emissao periodo apur periodo apur dt inicio dt fim receita dt emissao periodo apur vl consumo receita realiz receita pend receita txServ receita total gt Ti NA ATOR Gerente IC 10 Cadastrar mesa gt mesa nr mesa id mesa ATOR Gerente IC 11 Solicitar rela o de notas penduradas gt solic penduras dt emissao periodo apur Z periodo apur dt inicio dt fim penduras dt emissao periodo apur fid cliente nome cliente tel cliente notas pend vl_pendCli vl pend notas pend fid pedido dt pedido nr mesa itens nota vl nota itens nota id item cat item nome item p item quant item vl item A
207. modelo integrado de requisitos proposto Essas regras cobrem todos os principais elementos de um modelo de classes de objetos classes associa es atributos e opera es Elas podem ser categorizadas segundo o grau de determinismo e automatiza o na obten o dos resultados da sua aplica o As regras determin sticas s o aquelas capazes de determinar individualizar o elemento ou aspecto por ela tratado do MD Esse o caso por exemplo da regra R3a sobre persist ncia que sempre permite determinar a persist ncia ou a n o persist ncia dos itens de informa o presentes nos fluxos de entrada dos ICs J a regra R3d sobre aloca o dos atributos nas classes um exemplo de regra n o determin stica pois n o capaz no caso geral de determinar uma classe nica qual alocar o atributo em quest o Al m de R3a as seguintes regras s o deterministicas R1 R2 R3b R3c R3e R4a R4b R4c e R4d As regras R2 R3d e R4e s o n o determin sticas As regras automatiz veis s o aquelas cuja aplica o pode ser decidida e realizada de forma autom tica sem interven o do modelador Entre as regras da 70 pr xima se o apenas as regras R3e e R4a s o completamente automatiz veis Todas as demais s o semi automatiz veis ou seja algumas a es envolvidas na sua aplica o s o automatiz veis e outras n o Por exemplo a aplica o da regra R3a exige decidir sobre se um item necess rio ou
208. n as significativas entre eles do ponto de vista do conhecimento e experi ncia com qualquer das t cnicas empregadas ou em rela o ao dom nio do sistema Os instrumentos preparados pelo experimentador e utilizados pelos participantes do estudo foram 1 um sum rio do sistema a modelar escrito em linguagem natural 2 material did tico sobre UCs e sobre ICs para o treinamento dos participantes nessas t cnicas e 3 um question rio para caracteriza o dos participantes Antes da execu o do estudo ambas as turmas receberam treinamento em UCs e a turma noturna recebeu adicionalmente treinamento complementar para aplicar ICs A rodada de cada turma foi executada no mesmo dia ocupando parte de uma aula An lise pr via da Validade Durante o planejamento e a prepara o do estudo foi feita uma an lise sobre a validade dos resultados a serem obtidos visando prevenir amea as a essa validade Uma das principais preocupa es foi uma poss vel diferencia o entre as turmas o que poderia comprometer a validade interna do estudo Do ponto de vista do curso as turmas s se diferenciam quanto ao turno j que pertencem mesma disciplina e s o oferecidas no mesmo per odo letivo da sua grade geralmente pelo mesmo professor Mesmo assim foi elaborado um question rio para caracterizar os participantes quanto ao conhecimento e experi ncia pr vias na t cnica de UCs e no dom nio do sistema a modelar O questi
209. n o em outro IC distinto daquele em que ele entrou no sistema Para isso preciso a interven o do modelador O grau de automatismo de uma regra a rela o entre o n mero de a es automatiz veis e o n mero total de a es envolvidas na aplica o da regra A se o 5 5 5 apresenta o c lculo do grau de automatismo para cada uma das regras apresentadas na pr xima se o 5 4 2 Para auxiliar o modelador na aplica o das regras n o determin sticas e ou n o automatiz veis foram identificadas algumas heur sticas aproveitando o formalismo e a estrutura o da especifica o da interface informacional dos ICs Essas heur sticas se baseiam na ocorr ncia de padr es sint ticos nessa interface Um padr o sint tico para uma regra uma configura o da interface informacional dos ICs cuja ocorr ncia sugere um resultado espec fico para a aplica o da regra Portanto a cada padr o sint tico corresponde uma heur stica supostamente capaz de ajudar a resolver uma indetermina o da regra associada ou de facilitar a sua aplica o se a regra n o for plenamente automatiz vel ou ambos Portanto s o desnecess rios para regras determin sticas e automatiz veis Por exemplo na aplica o da regra R3a acima mencionada que semi automatiz vel a ocorr ncia do seguinte padr o sint tico sugere a necessidade de persistir um item elementar de informa o itens elementares hom nimos em ICs distintos com p
210. n o determinou a persist ncia Parcela recebimento Conta bancaria Porque essa informa o ser usada em outro sub sistema n o Caixa modelado nos IC s IC9 Cadastrar Atributo cargo contato classe Inclus o As regras n o determinaram a persist ncia deste atributo mas ele cliente Contato 7 Tipo Al foi adicionado pois um usuario pode estar interessado nessa 09 06 08 informa o ao visualizar um determinado contato Por que a regra n o determinou a persist ncia Porque essa informa o ser usada em outro sub sistema n o modelado nos IC s Opera o construtora Inclus o As regras n o determinaram a cria o desta opera o mas ela foi Cliente despesa custo Tipo A2 adicionada por haver necessidade Currency Cliente despesa de se criar um contrutor classe Cliente despesa para a classe Cliente despesa Por que a regra n o determinou a cria o da opera o Pois n o h identificador gerado para esta classe na especifica o Atributo dt correnteCancel classe Inclus o As regras n o determinaram a persist ncia deste atributo Contudo Contrato Tipo Al foi adicionado por motivos de seguran a Por que a regra n o determinou a persist ncia Porque essa informa o ser usada em outro sub sistema n o modelado nos IC s Atributos motivo cancel Inclus o As regras n o determinaram a persist ncia destes atributos 189 Identifica o do s elemento s envolvido s na
211. na Fase de Requisitos Nesta se o vamos analisar duas quest es pertinentes utiliza o do MUC e do MD A primeira delas por que utilizar ambos os modelos na fase de requisitos Ao considerar essa quest o pretendemos justificar a pr tica do uso conjunto dos modelos na fase de requisitos A segunda quest o qual deve ser a ordem de elabora o dos modelos A resposta dif cil e existem argumentos na literatura para se decidir por qualquer uma das duas possibilidades Entretanto como alguns desses argumentos conflitam entre si a proposta de se fazer ambos em paralelo surge fortalecida Passamos agora s quest es e respectivas an lises 3 2 1 Por que Utilizar o MUC e o MD na Fase de Requisitos N s compartilhamos com GLINZ 2000 e outros autores por exemplo KOSTERS et al 2001 a vis o de que os dois modelos se complementam mutuamente Isso porque cen rios modelam o comportamento din mico externamente observ vel de um sistema enquanto que o modelo de classes especifica a estrutura e comportamento internos isto estruturas de dados relacionamentos entre elas e opera es necess rios determina o do comportamento externo do sistema Segundo GLINZ 2000 quase todas as abordagens pr ticas que fazem uso de cen rios combinam os cen rios com um modelo de classes Tamb m a literatura t cnica apresenta ind cios dessa complementaridade m tua dos dois modelos Por exemplo o JACOBSO
212. neeeees 108 Tabela 6 1 Resultados do Estudo Precursor 2 eres 116 Tabela 6 2 Testes de Normalidade para a vari vel Cobertura t 121 Tabela 6 3 Testes de amostras independentes para a vari vel Cobertura 122 Tabela 6 4 Complemento da an lise do Teste T rea 123 Tabela 6 5 Testes de Normalidade para a vari vel Granularidade 124 Tabela 6 6 Testes de amostras independentes para a vari vel Granularidade 125 Tabela 6 7 Caracteriza o dos participantes do estudo 00 ecceeeeeceeeseeetseesteceeeeeees 130 Tabela 6 8 Cronograma de execu o do estudo ccceeceesceesseceteceeeeeeeeeeeecseeneenees 136 Tabela 6 9 Esfor o de cada participante c cc cecesccescesceesseceseceseeeeseeeaeecssecneeeenes 140 Tabela 6 10 N mero de classes por participante serenas 141 Tabela 6 11 Abstra es nos modelos de dominio MDS 142 Tabela 6 12 Associa es nos modelos de dom nio MDS 143 Tabela 6 13 Atributos nos modelos de dom nio MDS 144 Tabela 6 14 Opera es nos modelos de dom nio MDS 145 Tabela 6 15 Opera es nos modelos exclu das as opera es construtoras 146 Tabela 6 16 Uniformidade de associa es atributos opera es e representacional 147 Tabela 6 17 Compara o das m dias de uniformidade 149 Tabela 6 18 Nr de m
213. nt Fomecedor Parcela despesa aParcDespPai Parcela despesa divenc Dale l parcela Currency Parcela despesa Parcela despesa aDespesa Despesa dt venc Date v_parcela Currency Parcela despesa Parcela despesafaDespesa Despesa dt prevVenc Date v_prevPare Currency Parcela despesa doser mov Sting ref mou String Cliente despesa sipan veil eusto Currency tipo mov Sting v dHPrevParcl Currency Ciente _despasalcusto Currency Ciente_despesa parapine T juros Cumency vmu Currency atrasada boolean i informar pagto pago Currency vi_desconto Currency dt pagto Date conta Object parcelas_compl Array lt dt_venc Date vi parcela Currency gt obs pago Sting dt_corene Dat void ER ER q q Cleto despesa Pei Out j ot oaf Jos 1 x ta fem o Conta bancaria Cliente brio Despes nome ci Sting descr despesa Sting nome_banco Sting cpf ci Sting dk gera o Date me banco int cre chi Sting mena Sting ne agencia Sting Iograd ct Sting te juros Percentual ne conta Sting bairro ci String mula Percentual di abertura Date cep ci Sting at comente Date vino Cureney cidade ci Sting vcsado Currency Soa one Despesa aCiasseliom Classe om descr desp Sting sAreaEmp Area empresa Func Profissional voce dados ch Array lt oCliente Cliente custo Cuency gt oFomes Fomecador v desp Currency nr nota Sting bx Juros Percentual mula Percen
214. ntre o sistema e seus atores em cada UC Para facilitar a refer ncia a esses fluxos passaremos a denomin los daqui para frente de interface informacional IN dos UCs As rela es formais a introduzir na interface informacional dos UCs dever o transformar o MUC em um modelo integrado de requisitos se o 4 3 2 permitindo a deriva o a partir dessa interface de elementos de um MD correspondente classes e seus relacionamentos atributos e opera es Com base na an lise realizada no cap tulo anterior se o 4 3 necess rio tomar duas provid ncias conjuntamente 1 Estabelecer um novo crit rio para determinar os UCs ou seja para particionar em UCs a funcionalidade do sistema e 2 Especificar com um maior rigor formal a interface informacional dos UCs O restante deste cap tulo est organizado da seguinte forma A se o 5 2 apresenta o conceito de n vel informacional de objetivos e mostra como implementar com o aux lio dele a primeira provid ncia acima indicada A se o 5 3 mostra como implementar a segunda provid ncia introduz uma linguagem semiformal para especificar a interface informacional dos UCs A se o 5 4 apresenta as regras com as quais se pode derivar a vis o MD a partir do modelo integrado e exemplifica a utiliza o delas A se o 5 5 faz um balan o da solu o representada pelo modelo integrado analisando a qualidade das especifica es produzidas com a linguagem descrita na
215. o 1 Voc j teve experi ncia na modelagem de um sistema parecido com o sistema FGV contas a pagar receber Descreva n mero de sistemas porte tempo dedicado 2 Mesmo n o tendo modelado como avalia o seu conhecimento experi ncia anterior sobre este tipo de sistema Experi ncia pr via na t cnica casos de uso 1 Voc tem experi ncia na modelagem de casos de uso elabora o leitura Essa experi ncia foi apenas acad mica estudo ou trabalho escolar ou tamb m profissional sistema real 2 Voc tem experi ncia na modelagem informacional com casos de uso apenas grupo A Descreva brevemente Experi ncia profissional 1 Descreva sua experi ncia profissional empresa fun o tempo na fun o Forma o 2 Qual o seu n vel de escolaridade Descreva Participou de treinamento sobre casos de uso Com que carga hor ria 185 Sum rio do Sistema FGV Deseja se um sistema computadorizado para melhorar o seu controle financeiro da empresa Entre outras coisas a empresa deseja Prever e acompanhar a entrada e sa da de dinheiro decorrente do recebimento dos clientes e do pagamento de contas a credores da empresa Ou seja para cada dia do m s ela precisa saber o que deve pagar e o que tem a receber at aquele dia O principal objetivo prever eventuais dificuldades de caixa para tomar provid ncias por exemplo fazer um
216. o No caso do sistema PDV esse segundo evento deve obrigatoriamente ocorrer ap s o primeiro O sistema deve embutir essa suposi o pois se tal n o ocorrer necess rio alguma a o para tratar essa situa o excepcional J no caso do sistema Restaurante o segundo evento n o precisa necessariamente ocorrer em seguida ao primeiro Por exemplo ap s registrar os pratos e bebidas de uma refei o o ator poderia registrar o mesmo para outra refei o antes de registrar o pagamento da primeira refei o Ou seja nenhuma suposi o pode ser embutida no sistema sobre o evento que o antecede trata se de um evento aut nomo Se um evento externo n o aut nomo ele subassumido por algum outro evento Supondo que o sistema precise por exemplo emitir um relat rio dos pratos e bebidas consumidas em um dado per odo de tempo ou que o restaurante permita o pagamento postergado da refei o para clientes habituais cadastrados no sistema Nesta ordem para satisfazer restri es do dom nio do problema Evento disparado a partir do ambiente do sistema ou seja por um de seus atores 62 aut nomo o caso do segundo evento da solu o de um nico UC adotada para o sistema PDV ele subassumido pelo evento aut nomo que dispara a primeira parte do UC aquela respons vel pela fun o de registro dos itens da compra Resumindo para figurar no particionamento almejado do sistema um UC precisa satisfazer
217. o A segunda equipe equipe 2 respons vel pela implementa o do sistema foi constitu da por um dos profissionais da empresa que tinham participado da primeira equipe e mais um estagi rio admitido para colaborar na implementa o Nessa segunda etapa o experimentador n o participou diretamente mas manteve contato e orientou os participantes quanto coleta dos dados a serem analisados Nenhum dos participantes de ambas as equipes tinha conhecimento significativo do dom nio do sistema financeiro A especifica o dos ICs do sistema foi elaborada em conjunto pelos tr s participantes da equipe 1 sob a coordena o de um dos analistas da empresa Esse analista elaborou uma vers o preliminar dos ICs vers o essa que sofreu extensas modifica es durante mais de um m s de discuss es entre os membros da equipe e com os stakeholders Ambos os analistas da empresa tinham poca pelo menos 1 ano de experi ncia na modelagem de ICs Quando o MIC foi considerado est vel o suficiente a equipe 1 se preparou para a deriva o da vis o MD do MIC Essa prepara o envolveu a distribui o de documentos de apoio uma c pia do MIC e das regras para cada participante e um treinamento sobre a aplica o das regras O treinamento foi ministrado pelo experimentador durante um dia e meio visando nivelar o conhecimento dos analistas sobre as regras Uma vez conclu do o treinamento procedeu se a deriva o do MD Desta vez
218. o da verifica o de consist ncia entre os modelos Como eliminar ou reduzir o indeterminismo apontado por SVETINOVIC et al 2005 no processo de obten o do MD a partir dos UCs 3 4 3 Objetivo da Tese O objetivo deste trabalho de tese obter respostas para os questionamentos listados no final da se o anterior e propor uma solu o correspondente que Ol O2 Inclua mais rastros formais entre elementos dos dois modelos contribuindo assim para um maior automatismo e cobertura de elementos na deriva o do MD a partir do MUC ou na verifica o de consist ncia entre os dois modelos Elimine ou reduza a inconsist ncia entre MDs obtidos por diferentes modeladores a partir dos UCs de um mesmo sistema Acreditamos que o alcance do segundo objetivo acima decorra em parte de se alcan ar o primeiro O pr ximo cap tulo identifica e analisa as poss veis causas para os problemas aqui caracterizados e prop e um enfoque para resolv los 48 4 4 1 Causas dos Problemas e Enfoque de Solucao Introdu o No cap tulo anterior identificamos alguns problemas associados utiliza o conjunta e complementar do modelo de casos de uso MUC e do modelo de classes de objetos de dom nio MD na fase de elicita o e modelagem de requisitos Esses problemas s o P1 P2 P3 A pequena cobertura autom tica para a obten o de elementos do MD a partir do MUC ou para a verifica o
219. o da vis o MD do MIC Solu o o modelador deve considerar essa necessidade de opera es retrieve na hora de interpretar a regra da persist ncia de itens informados na entrada regra R3a N mero de ocorr ncias 1 B3 Introdu o de atributo correspondente ao item de informa o do MIC que deveria ter sido considerado a persistir An lise falha na aplica o da regra de persist ncia R3a decorrente principalmente de uma subespecifica o do dicion rio de itens elementares DI que deve dizer como se obt m uma informa o Portanto a inclus o n o pode ser justificada com base no MIC e portanto n o configura omiss o da vis o MD do MIC N mero de ocorr ncias 1 B4 Introdu o de opera o da interface com o usu rio An lise trata se de uma opera o que visa organizar informa es dispon veis no MD para visualiza o pelo usu rio Portanto essa opera o est relacionada com o projeto da interface do usu rio e como tal estaria melhor localizada na camada de objetos de apresenta o do sistema e n o na camada de objetos de dom nio Por isso ela n o deve aparecer em nenhum dos dois modelos MIC e MD N o sendo essa inclus o justific vel com base no MIC ela n o configura uma omiss o da vis o MD do MIC N mero de ocorr ncias 1 155 Compara o entre o par de modelos intermedi rios de implementa o e o par de modelos finais de implementa o Cl Introdu o de item de inf
220. o de Pj nene OO Unif O s Oii Oi E P1 P2 13 12 9 0 5625 P1 P3 15 15 14 0 8750 P2 P3 15 13 11 0 6471 P4 P5 27 16 7 0 1944 P4 P6 og 19 5 0 1389 P5 P6 14 14 2 0 0769 A t cnica de modelagem com ICs determina a cria o de uma opera o construtora em cada classe do modelo com o mesmo nome da classe Cada opera o construtora gerou uma coincid ncia de opera es A t cnica tradicional de UCs n o determina a introdu o de opera es construtoras embora pudesse faz lo da mesma 145 forma que na MIR Por exemplo o participante P5 n o incluiu nenhuma opera o construtora em suas classes Em vista disso decidiu se calcular tamb m a uniformidade de opera es sem levar em conta as opera es construtoras As opera es designadas or cadastra dos participantes P4 e P6 foram consideradas opera es construtoras gt ja que elas t m o mesmo prop sito A Tabela 6 15 apresenta os dados coletados sobre as opera es quando n o s o computadas as opera es construtoras nos modelos de ambos os grupos Tabela 6 15 Opera es nos modelos exclu das as opera es construtoras Parks Opera es no Opera es no Oneracnes Pi Pj modelo de Pi modelo de Pj coincidentes OD Unif O 2 Oii Oj E P1 P2 7 7 3 0 2727 P1 P3 7 7 6 0 7500 P2 P3 10 8 6 0 5000 P4 P5 24 16 7 0 2121 P4 P6 17 15 1 0 0323 P5 P6 14 12 2 0 0833 A compara o da uni
221. o de vezes que a aplica o da heur stica gerou um resultado consistente com o MIC do sistema aqui denominado grau de acerto da heur stica segundo a avalia o do autor desta tese com base em seu conhecimento e experi ncia na elabora o de MDs em geral e do sistema Restaurante em particular O modelo de dom nio resultante apresentado na Figura 5 3 no final desta se o Classes de Objetos As classes s o determinadas pelos identificadores gerados nos ICs Um identificador gerado em um IC quando o seu valor estabelecido durante a execu o do IC Seu prop sito ser uma refer ncia para um objeto criado nesse IC Por exemplo id cliente um identificador gerado no IC 6 Cadastrar cliente habitual Figura 5 2 para servir de refer ncia a um objeto cliente criado durante o processamento do IC A gera o de um identificador s deve ser especificada em um IC se for necess rio fazer em outro IC refer ncia ao objeto correspondente criado nesse IC Regra R1 Determina o de classes Cada identificador gerado d origem a uma classe de objetos As classes obtidas a partir dos identificadores gerados representam abstra es utilizadas e compartilhadas pelos especialistas de dom nio que participam da defini o dos requisitos do sistema Assim elas t m boa chance de serem classes teis com atributos e opera es significativas no dom nio MEYER 1997 pg 733 Padr o sint tico R1 P1 Identif
222. o dos ICs LI DI nos testes Os testes do sistema foram organizados IC a IC tendo sido realizados pelos programadores medida que o IC era constru do e ao final de sua implementa o era testado como um todo Depois disso os testes ficaram a cargo dos usu rios Os erros encontrados durante os testes do sistema foram apenas erros de programa o 199 A especifica o dos IC s n o foi usada diretamente nos testes pois a implementa o foi um reflexo da especifica o 6 Qual foi a influ ncia dos Objetivos Organizacionais OO na implementa o testes dos m dulos do sistema As seqii ncias admiss veis SA s que est o diretamente ligadas aos OO s foram preponderantes na implementa o e conseqiientemente nos testes do sistema Elas determinaram a ordem de implementa o dos IC s e da mesma forma a ordem dos testes 7 Que outros modelos foram utilizados al m do modelo de ICs II DI OO durante a implementa o O nico modelo utilizado al m do modelo de IC s foi o diagrama de classes obtido da aplica o das regras de deriva o nos IC s 8 Que outras observa es voc poderia fazer sobre a rela o entre a especifica o de ICs II DI OO e a implementa o do sistema A especifica o de IC s guiou a implementa o do sistema ajudou a distribuir melhor as tarefas entre os programadores e deu maior clareza aos programadores quanto ao que d
223. o e contribui o nos estudos experimentais Aos colegas do NCE e da COPPE pela conviv ncia amiga e instrutiva Ta sa s secretarias do PESC COPPE e do Departamento de Ci ncia da Computa o do IM bem como a outros rg os da UFRJ pelo apoio e pronto atendimento s minhas in meras solicita es UFJF por ter viabilizado o meu doutorado ao PESC COPPE pelo apoio financeiro para apresenta o de artigos em confer ncias e CAPES pelo suporte financeiro concedido na forma de bolsa de estudos minha m e Jorgette in memoriam que silenciosamente modelou boa parte do que eu sou Ao meu pai Feliciano que me mostrou o valor do trabalho e da perseveran a Ao meu irm o Alexandre que me apoiou e foi um companheiro sempre presente nos momentos decisivos A minha esposa Teresinha pelo amor apoio e paci ncia em todos esses anos As minhas filhas Luiza e Raquel pela doa o espont nea e amorosa que principalmente as crian as s o capazes A DEUS express o infinita do Amor revelada em cada passo da minha vida Resumo da Tese apresentada COPPE UFRJ como parte dos requisitos necess rios para a obten o do grau de Doutor em Ci ncias D Sc INFO CASES UM MODELO INTEGRADO DE REQUISITOS COM CASOS DE USO Michel Heluey Fortuna Dezembro 2008 Orientadores Cl udia Maria Lima Werner Marcos Roberto da Silva Borges Programa Engenharia de Sistemas e Computa o Existem evid ncia
224. o html gt Acesso em Dez de 2008 ANDERSON D J Use Cases still considered Dangerous 1999b Dispon vel em lt http www uidesign net 1999 imho oct imho html gt Acesso em Dez de 2008 ARA JO M A P BARROS M O TRAVASSOS G H et al 2006 M todos Estat sticos Aplicados em Engenharia de Software Experimental Tutorial In XX Simp sio Brasileiro de Engenharia de Software SBES 06 p 325 325 Florianopolis SC Brasil Outubro BECK K CUNNINGHAM W 1989 A laboratory for teaching object oriented thinking In OOPSLA 89 ACM Conf on Object Oriented Programming Sysstems Languages and Applications ACM Press pp 1 6 New Orleans Louisiana USA October BERRISFORD G 2004 Why IT veterans are sceptical about MDA 2nd European Workshop on Model Driven Architecture MDA Canterbury England September BIDDLE R NOBLE J 2002 From Essential Use Cases to Objects In 1 Intl Conference on Usage Centered Design forUSE 02 Larry Constantine ed BITTNER K SPENCE I 2002 Use Case Modeling 1 ed New York Addison Wesley Professional BREITMAN K K LEITE J C P 2003 Ontology as a Requirements Engineering Product In th IEEE Intl Requirements Engineering Conference IREC pp 309 319 Monterey Bay California September 172 CITESEER 2003 Estimated Impact of Publication Venues in Computer Science CiteSeer Dispon vel em lt http citeseer i
225. o j presentes nas classes que representam abstra es comuns a ambos os modelos i e j e o At a cardinalidade do conjunto de atributos coincidentes em todas as classes que representam abstra es comuns a ambos os modelos i e J A uniformidade de opera es Unif O e a uniformidade de associa es Unif Lij entre dois MDs i e j s o definidas de forma an loga Por fim a uniformidade representacional entre dois MDs i e j calculada como a m dia aritm tica das uniformidades de atributos opera es e associa es entre os modelos Unif At Unif O Unif L Unif R 2 2 i 3 Onde o Unif At Uniformidade de atributos entre os modelos i e j e o Unif O Uniformidade de opera es entre os modelos i e j e o Unif L Uniformidade de associa es entre os modelos 1 e j 6 3 2 Sele o de Participantes Conforme visto na introdu o deste cap tulo a popula o alvo do estudo constitu da pelos profissionais graduados em Ci ncia da Computa o pela Universidade Federal de Juiz de Fora UFJF A amostra da popula o foi selecionada por conveni ncia sendo formada por seis pessoas conhecidas do autor do trabalho de conclus o de curso e que tinham disponibilidade para participar do estudo Portanto n o foi utilizado o princ pio de aleatoriedade na sele o da amostra populacional Os seis participantes foram divididos em dois grupos com tr s participantes cada um
226. o que neste caso ser o Teste de Levene WOHLIN et al 2000 que sera feito posteriormente 120 cobertura N I tecnica Figura 6 1 Diagrama Box Plot para a vari vel Cobertura O Teste T WOHLIN et al 2000 para duas amostras independentes exige que as amostras sigam uma distribui o normal Desta forma tem se um primeiro teste de hip teses a ser feito considerando um n vel de signific ncia de 5 sendo HO hip tese nula A distribui o normal H1 hip tese alternativa A distribui o n o normal A Tabela 6 2 abaixo apresenta a sa da dos testes de normalidade do SPSS SPSS 2008 considerando a vari vel Cobertura No SPSS Analyze Descriptive Statistics Explore Tabela 6 2 Testes de Normalidade para a vari vel Cobertura Tests of Normality phenio wik io tecnica Statistic a Statistic cobertura 186 941 211 15 4 a Lilliefors Significance Correction O Teste de Kolmogorov Smirnov bastante utilizado para a verifica o de normalidade em amostras com mais de 30 elementos Entretanto para amostras com menos de 50 elementos pequenas amostras costuma se utilizar o Teste de Shapiro Wilk WOHLIN et al 2000 121 Independente do teste observa se que ambas as amostras possuem o valor de signific ncia Sig superior a 0 05 e portanto n o h ind cios para rejeitar a hip tese nula a um n vel de signific ncia de 5 Desta forma a distribui o d
227. o usu rio 1 3 Erro de implementa o programa o 6 4 Erro de implementa o propiciado pela subespecifica o do DI 5 5 Requisito n o implementado subespecifica o do DI 2 6 Requisito evolutivo 1 7 Novo requisito n o apontado inicialmente pelos stakeholders 5 Total 24 Por fim vale registrar que os stakeholders e usu rios que participaram dos testes de aceita o demonstraram satisfa o em ver o sistema realizando aquilo que eles tinham ativamente ajudado a especificar 6 Essas seqiiencias s o denominadas de Objetivos Organizacionais mais informa es na se o 7 4 6 Dicion rio de Itens Elementares parte integrante do MIC Receberam um r pido treinamento e utilizaram a MIC pela primeira vez 158 6 4 6 Outros Ajustes das Regras de Deriva o A Se o 6 4 4 indicou a necessidade de dois ajustes nas regras de deriva o para garantir a adequa o da vis o MD do MIC por elas produzida A presente se o apresenta e discute os outros ajustes motivados por observa es e decididos ap s longas reflex es realizadas entre os participantes do estudo principalmente durante a etapa de deriva o da vis o MD do MIC A vers o das regras apresentada na Se o 5 4 2 j incorpora todos esses ajustes Associa o entre classes Vers o anterior R2a Determina o de associa es identificadores em fluxos distintos Todo par lt id id gt que possa ser formado com id s
228. odifica es segundo o efeito sobre a adequa o do MD 157 Tabela 6 19 Apura o dos problemas no teste de aceita o do sistema 158 Tabela 6 20 Contribui o dos estudos para a valida o das hip teses 163 xiii Lista de Siglas e Abreviaturas AE AOO ERq H C IC e ICs I IU LRgs MIC MIR MD MOObj MUC NIO SI e SIs UC e UCs An lise Essencial An lise Orientada a Objetos Engenharia de Requisitos Humano Computador em Intera o H C e Interface H C Info Case e Info Cases respectivamente Interface Informacional de um IC Interface com o Usu rio Lista de requisitos Modelagem Modelo de Info Cases Modelagem Modelo Informacional de Requisitos ou dependendo do contexto Modelo Integrado de Requisitos Modelagem Modelo de Classes de Objetos do Dom nio Modelagem de Requisitos Orientada a Objetivos Modelagem Modelo de Requisitos com Casos de Uso N vel Informacional de Objetivos Sistema de Informa o e Sistemas de Informa o respectivamente Use Case e Use Cases respectivamente xiv 1 Introdu o 1 1 Motiva o A t cnica de casos de uso do ingl s use cases UCs JACOBSON et al 1992 bastante utilizada principalmente para especifica o de requisitos funcionais de sistemas de software Em geral ela emprega duas especifica es a um diagrama denominado Diagrama de Casos de Uso que apresent
229. om tica de um MD O MD assim obtido adequado A MIC promove uma maior uniformidade entre os MDs obtidos por diferentes modeladores para um mesmo sistema A MIC mant m as principais vantagens alegadas para a MUC e A MIC n o exige um aumento excessivo do esfor o de modelagem A Tabela 6 20 resume a contribui o de cada um desses estudos exceto a dos individuais e did ticos para a valida o das hip teses da tese Tabela 6 20 Contribui o dos estudos para a valida o das hip teses Estudo po EC 2 EXP 1 EXP 3 EC 3 Hip tese H1 x x x H2 X H3 EA E X H4 H5 X Alguns comentarios sobre a valida o de cada uma das hip teses s o relevantes para ajudar a esclarecer as informa es apresentadas na Tabela 6 20 Hl A deriva o da vis o MD do MIC sempre foi feita manualmente nos estudos experimentais relatados uma vez que n o se disp e ainda de uma ferramenta computacional para apoiar a aplica o das regras A despeito disso ficou claro para os participantes dos estudos EC 2 EXP 3 e EC 3 o potencial de automatiza o inerente as regras confirmando assim na pr tica os resultados te ricos apresentados na Se o 5 5 5 163 H2 H3 H4 H5 A adequa o da vis o MD do MIC obtida atrav s das regras de deriva o foi validada tanto experimentalmente EC 3 quanto teoricamente Se o 5 5 5 O principal estudo pa
230. on rio foi aplicado antes da execu o do estudo e as respostas obtidas evidenciaram a uniformidade das duas turmas nesses aspectos Tamb m foram tomadas provid ncias para evitar troca de informa es entre os participantes o que poderia invalidar os resultados Isso foi facilitado pelo fato das turmas serem de turnos distintos diurno e noturno Al m disso cada turma aplicou uma t cnica distinta UCs ou ICs as rodadas foram executadas no mesmo dia ocupando parte do tempo de aula e sob a supervis o do experimentador O treinamento na t cnica de UCs foi o mesmo para ambas as turmas ministrado pelo mesmo instrutor e utilizou o mesmo material did tico Embora a turma noturna fosse aplicar apenas a t cnica de ICs esta conforme apresentado no Cap tulo 5 uma 5 Quanto t cnica de ICs havia certeza do seu desconhecimento por parte de todos os alunos j que ela ainda n o havia sido divulgada externamente 119 especializa o da t cnica de UCs e portanto seu treinamento deve iniciar com os elementos da t cnica de UCs Ap s o treinamento de UCs a turma noturna foi capacitada na t cnica de ICs mediante o treinamento na parte que espec fica desta t cnica Assim procurou se garantir que eventuais diferen as nos resultados do estudo n o fossem causadas por diferen as na aplica o dos elementos da t cnica de UCs mas sim pelas novidades introduzidas com ICs Gra as ao n mero de participantes em
231. onsiderar a rastreabilidade Prover rastreabilidade entre o MIC e o MD mais f cil do que entre o MUC e o MD Isso porque o MD est intimamente integrado ao MIC a ponto de poder ser em grande parte derivado deste atrav s das regras de deriva o apresentadas na se o 5 4 2 Essas regras exploram rastros formais entre elementos dos dois modelos Portanto a necessidade de se inserir manualmente rastros entre o MIC e seu MD menor do que entre o MUC e seu MD Por fim e em decorr ncia do favorecimento da rastreabilidade que a t cnica de ICs proporciona podemos considerar tamb m favorecida a manutenibilidade do conjunto de modelos dela resultantes MIC e MD Al m disso as regras orientam a propaga o de modifica es feitas em um modelo em modifica es correspondentes no Uma das opera es CRUD Create Retrieve Update Delete 86 outro modelo Do MIC para o MD parte dessa propaga o pode ser feita automaticamente se o 5 5 5 5 5 2 Aplicabilidade do Modelo Integrado O MIC se aplica principalmente a sistemas interativos e em especial a sistemas de informa o Isso pode ser melhor compreendido considerando se os tipos de sistemas classificados segundo o grau de intera o e a quantidade de informa o envolvidos na comunica o com o seu ambiente A Figura 5 4 mostra essa classifica o discutida a seguir Intera o Sistemas de controle processos dispositivos Siste
232. or Staff o Sistema armazena as informa es acima registra o novo exemplar do livro com a data do cadastramento data corrente gerando um identificador para o exemplar O exemplar passa a estar dispon vel para empr stimo No caso de reposi o compensa o a data do cadastramento deve ser posterior data da baixa do exemplar que est sendo reposto compensado e o Sistema deve rever a situa o do usu rio de suspenso para regular desde que as demais condi es para isso estejam satisfeitas nenhum outro livro perdido por ele e ainda n o compensado reposto ou ressarcido sem d bito de multas sem devolu o atrasada em mais de 5 dias Verifica reserva O sistema verifica que inexiste reserva ativa aguardando retorno para o livro correspondente ao exemplar retornado O caso de uso termina 12 Fluxos Alternativos Al Trata exist ncia de reserva ativa Em Verifica reserva se existir reserva ativa aguardando retorno para o livro correspondente ao exemplar retornado 1 O sistema coloca o exemplar na situa o dispon vel com reserva e alerta o ator Staff da exist ncia da reserva para que ele coloque o exemplar na prateleira de livros reservados para empr stimo Em seguida notifica por e mail o retorno do exemplar ao pr ximo Usu rio da lista de reservas do livro usu rio regular com reserva ativa mais antiga aguardando retorno e portanto ainda n o notificado passando a reserva correspondente para a situa
233. or a 0 05 e portanto nao ha indicios para rejeitar a hip tese nula a um nivel de signific ncia de 5 Desta forma a distribui o das amostras para a vari vel Granularidade normal logo ser utilizado o teste param trico T para duas amostras independentes Antes por m necess rio verificar se as vari ncias podem ser assumidas como iguais ou n o Assim tem se outro teste de hip teses a um n vel de signific ncia de 5 HO As vari ncias s o iguais 6 T cnical O T cnica 124 Eus a 2 2 H1 As vari ncias s o diferentes 0 Tecnica O T cnica A Tabela 6 6 apresenta a sa da do teste de Levene do SPSS considerando a vari vel Granularidade No SPSS Analyze Compare Means Independent Samples T Test Tabela 6 6 Testes de amostras independentes para a vari vel Granularidade Independent Samples Test Levene s Test for Equality of Variances t test for Equality of Means 95 Confidence Interval of the Mean Std Error Difference Difference Difference granularidade Equal variances assumed Equal variances not assumed Atrav s desta tabela pelas colunas do Teste de Levene para Igualdade de Vari ncias verifica se pela primeira linha dos resultados que a signific ncia Sig maior que 0 05 Portanto considerando um nivel de significancia de 5 nao ha indicios para se rejeitar a hip tese nula podendo se considerar que as amostras possuem vari ncias iguais P
234. or fim satisfeito o pressuposto de normalidade e uma vez que as vari ncias s o iguais pode se proceder com a an lise de compara o das m dias das duas amostras gerando um novo teste de hip teses a um n vel de signific ncia de 5 sendo HO As m dias s o iguais Lr cnical HT cnica H1 As m dias s o diferentes Ur cnical T cnica Retornando Tabela 6 6 percebe se na primeira linha que corresponde confirma o de que as vari ncias das amostras s o iguais que a signific ncia do Teste T Sig 2 tailed superior a 0 05 e desta forma n o h ind cios para rejeitar a hip tese nula concluindo se que as m dias s o iguais a um n vel de signific ncia de 5 Outra maneira de verificar esta situa o a constata o de que o valor zero est entre os limites inferior e superior do intervalo de confian a tamb m n o sendo poss vel rejeitar a hip tese nula Embora muito pr xima 0 051 125 6 2 3 Considera es sobre o Estudo 1 O estudo permitiu concluir a um n vel de signific ncia de 5 que o particionamento por ICs crit rio dos eventos aut nomos proporciona maior cobertura funcional do que o particionamento por UCs crit rio de valor Quanto granularidade dos particionamentos o estudo n o validou a um n vel de signific ncia de 5 a hip tese de que o particionamento por ICs tem gr o mais fino do que o particionamento por UCs Deve se ressaltar que a hip tese
235. orm Grad o n vel de escolaridade o tempo de experi ncia profissional o conhecimento e experi ncia anteriores no dom nio do sistema objeto do estudo a experi ncia com casos de uso e por fim apenas para os participantes do Grupo A ICs a experi ncia com ICs Para facilitar a compara o da experi ncia profissional dos participantes a tabela apresenta al m dos tempos de est gio carga hor ria de 20 h semanais e normal 40 h semanais o tempo equivalente calculado a partir desses dois Al m disso o n vel de experi ncia em UCs e em ICs detalhado em experi ncia de leitura L e ou de escrita E Pode se ainda acrecentar a t tulo de caracteriza o dos participantes que todos eles se graduaram no mesmo curso Ci ncia da Computa o pela mesma universidade UFJF Al m disso a disciplina respons vel pela ensino da t cnica de UCs Modelagem de Sistemas foi cursada por todos eles com a mesma ementa e com mesmo professor Uma vez que a t cnica de ICs baseada na t cnica de UCs todos os participantes receberam o mesmo treinamento em UCs adicionalmente os participantes do Grupo A ICs receberam um treinamento nos elementos espec ficos da t cnica de ICs crit rios adicionais para o particionamento do sistema em ICs e regras de deriva o do MD a partir dos ICs 5 Alguma informa o sobre a intensidade dessa experi ncia dada atrav s dos sinais maior e menor 130 6
236. orma o de controle seria ent o uma comunica o com baixa quantidade de variety Com base na cibern tica a ci ncia da comunica o e do controle podemos afirmar que a quantidade de variety comunicada pelo sistema ao seu ambiente deve igualar a quantidade de variety que pode ser absorvida por esse ambiente HAY 2003 pp 214 Certamente o ambiente dos sistemas de controle formado pelos processos e dispositivos controlados sensores e ativadores tem capacidade de absor o de variety muito menor do que a capacidade dos atores humanos que interagem com um sistema de informa o Portanto podemos considerar que a informa o comunicada pelo sistema aos processos e dispositivos controlados informa o de controle ou seja informa o filtrada para poder ser utilizada por eles Essa caracter stica de baixa quantidade de variety das informa es de controle tamb m significa que uma vez gerada tal informa o ser praticamente de uso exclusivo do ambiente tendo pouca ou nenhuma utilidade dentro do pr prio sistema Ou seja muito provavelmente n o ser necess rio persisti la entre os eventos externos e portanto o MD obtido segundo a MIC ser bastante reduzido ou mesmo inexistente Novamente uma subutiliza o da MIC Sistemas interativos de informa o Esses s o os sistemas caracterizados por um grau mais elevado de intera o com o seu ambiente principalmente atores humanos e tamb m por comunicar ao amb
237. orma o no MIC correspondente a atributo j presente no MD persistido a partir de outro IC An lise Modifica o corretiva no MIC que n o gera efeito na vis o MD N mero de ocorr ncias 1 C2 Introdu o de um item de informa o derivado no MIC que por n o precisar ser persistido levou introdu o da opera o correspondente no MD An lise Modifica o corretiva no MIC que gerou o devido efeito na vis o MD com a aplica o das regras N mero de ocorr ncias 1 C3 Elimina o de itens de informa o de um fluxo de sa da muito complexo de um IC para possibilitar o enquadramento de todas as informa es na folha de emiss o do relat rio no entanto os respectivos atributos foram mantidos no MD para futura utiliza o em outro layout de relat rio An lise Essa modifica o foi motivada por detalhes de implementa o que n o deveriam ter efeito sobre o MIC Portanto deve ser desfeita N mero de ocorr ncias 1 C4 Introdu o de uma opera o para a realiza o de uma consulta de interesse dos stakeholders n o prevista na MIC An lise A inclus o da opera o n o justific vel com base no MIC e portanto n o deve ser considerada como uma omiss o da vis o MD Sendo a consulta realmente necess ria o MIC deveria ser alterado para especific la o que resultaria na inclus o da opera o no MD pela regra R4c N mero de ocorr ncias 6 C5 Introdu o de uma opera o para
238. ormacional de Requisitos MIR A Figura 4 4 resume isso atrav s de um esquema gr fico e evidencia a rela o entre a solu o e os requisitos que guiaram sua obten o REQUISITOS DA SOLU O R1 Capturar durante a MUC Serraria E MODELO INTEGRADO DE REQUISITOS identific veis para a Especializa o do MUC constru o do MD R3 Promover a participa o Detalhamento e semi formaliza o das direta dos stakeholders na informa es trocadas entre os atores e o sistema elicita o dos elementos do MD Novo crit rio de elicita o de UC s R2 Provermaior orienta o sobre n veis de abstra o a Modelo de UC s serem utilizados na MUC R4 Tercusto esfor o adicional de modelagem aceit vel R5 Manteras caracter sticas e benef cios da MUC Figura 4 4 Enfoque de solu o 5 Observe que desta forma estamos tamb m atribuindo um significado mais formal e portanto mais preciso no o de objetivo de um ator 58 4 4 Hip tese Geral Em vista do que foi exposto a hip tese geral da presente tese A MIR permite a deriva o semi autom tica de um MD adequado e promove uma maior uniformidade entre os MDs obtidos por diferentes modeladores para um mesmo sistema Isso mantendo as principais vantagens alegadas para a MUC se o 2 4 1 e sem exigir um aumento excessivo do esfor o de modelagem O termo MD adequado ser interpretado com base no conceito de
239. ormais entre os dois modelos A consist ncia entre os dois modelos A valida o do MD No final da se o inclu mos uma an lise visando consolidar posi es extra das dos livros sobre os t picos acima 9 38 Exceto JURISTO et al 2000 e MAFRA et al 2006 por n o adotarem especificamente o MUC como ponto de partida para a obten o do MD Object Oriented Software Engineering A User Case Driven Approach JACOBSON et al 1992 Os autores consideram o MD parte integrante do modelo de requisitos juntamente com o modelo de UCs Sua fun o servir de suporte ao desenvolvimento desse modelo ajudando a desenvolver uma terminologia comum a ser utilizada nos UCs Eles prop em que a descoberta dos candidatos a objetos se fa a a partir da an lise da terminologia utilizada na descri o dos UCs e que a decis o sobre sua inclus o ou n o no MD deve levar em conta o contexto de sua utiliza o Os objetos s o divididos em tr s tipos objetos entidade de controle e de interface Os objetos entidade s o aqueles que t m uma contraparte direta no dom nio do problema e modelam informa es que o sistema manipula durante um per odo mais longo de tempo Tipicamente essas informa es precisam ser mantidas mesmo depois do t rmino da execu o dos UCs que as manipulam Os autores consideram que em geral n o se deve identificar opera es no modelo de an lise uma vez que elas frequentemente mud
240. os Ele aqui referido como uma transi o dif cil entre os modelos e foi identificado a partir de evid ncias obtidas na literatura do baixo grau de automatiza o poss vel para a deriva o de um MD a partir do MUC ou para a verifica o da consist ncia entre os dois modelos A literatura mostra que ambos os processos s o altamente dependentes da interpreta o do modelador o que gera outros problemas como por exemplo a acentuada discrep ncia entre MDs obtidos por diferentes modeladores para um mesmo sistema SVETINOVIC et al 2005 V rios s o os trabalhos dispon veis na literatura que prop em algum tipo de solu o para incrementar o grau de automatiza o da deriva o de um MD a partir do MUC por exemplo SUBRAMANIAM et al 2004 KARKKAINEN et al 2008 ou da verifica o da consist ncia entre os modelos por exemplo GLINZ 2000 O caminho seguido para isso contudo o da an lise ling stica das descri es em linguagem natural dos UCs o que for a manter um grande envolvimento do modelador para interpretar os resultados por conta da ambigiiidade inerente s linguagens naturais A solu o constru da nesta tese avan a em rela o s dispon veis na literatura no sentido de diminuir a interven o do modelador para a obten o de um MD a partir do MUC reduzindo tamb m o problema de se manter a consist ncia entre esses modelos A t cnica proposta nesta tese constitui uma sol
241. os analistas de requisitos s devem se interessar pelos UCs do n vel essencial e de n veis superiores A partir da an lise da literatura levantada principalmente do artigo Use cases Yesterday today and tomorrow em que JACOBSON 2004 faz um balan o dos ltimos 18 anos dessa t cnica e prop e algumas mudan as pudemos identificar algumas tend ncias na evolu o da MUC o Maior detalhamento da informa o trocada entre o sistema e seu ambiente em cada UC A literatura mais antiga aponta a falta desse detalhamento como uma falha dos UCs enquanto a mais recente tem proposto medidas que aliviam o problema Embora muitos ainda se limitem a recomendar a elabora o de um modelo de objetos ou de dados do dom nio BITTNER e SPENCE 2002 preconizam com o aval do pr prio JACOBSON 2004 o detalhamento completo da informa o o Fixa o de um n vel m nimo para os UCs Os crit rios acima mencionados para a escolha dos UCs juntamente com o crit rio onipresente de valor do UC gt Endossada por Jacobson 2004 15 apontam para a ado o impl cita do n vel de atividades essenciais da An lise Essencial como n vel minimo a considerar nessa elicita o Mais recentemente JACOBSON 2004 prop s que UCs utilizados em relacionamentos extend e include com outros UCs e que n o possam ser instanciados separadamente passem a ser considerados fragmentos de UCs e n o mais UCs o que refor a essa imp
242. os e o n mero de abstra es nicas entre os dois modelos Essa m trica pode ser expressa pela f rmula A Unif A a f A Eu A E A Onde para 1 3 A a cardinalidade do conjunto das abstra es do Modelo i o A a cardinalidade do conjunto das abstra es do Modelo j e o A a cardinalidade do conjunto das abstra es comuns a ambos os modelos 1 ej A Figura 6 3 ilustra a m trica acima Nela a uniformidade de abstra es entre os modelos est representada pela regi o de intercess o Quanto maior essa regi o maior a uniformidade de abstra es dos modelos Abstra es do Modelo i abstra es do Modelo j Ai Aj Abstra es Coincidentes A i j Figura 6 3 Ilustra o dos elementos da m trica de uniformidade de abstra es A uniformidade de um tipo de elemento representacional associa es atributos ou opera es entre dois MDs dada pela raz o entre o n mero de elementos coincidentes e o n mero de elementos nicos considerando apenas as classes que representam abstra es comuns aos dois MDs Por exemplo essa m trica para atributos pode ser expressa pela f rmula At Unit Att At At Onde para i 4j o At a cardinalidade do conjunto de atributos do Modelo 1 presentes nas classes que representam abstra es comuns a ambos os modelos 1 e j 128 o At a cardinalidade do conjunto de atributos do model
243. os pelo termo comportamento informacional Assim ICs que incorporem uma descri o completa de comportamento no estilo tradicional dos UCs podem exibir certa redund ncia na especifica o do comportamento informacional Al m disso a experi ncia com a MIC tem evidenciado que boa parte do comportamento n o informacional pode ser derivada do comportamento informacional e de regras de melhores pr ticas no projeto da interface H C Portanto uma linha de pesquisa poderia aprofundar essas quest es visando explorar o seu potencial de simplifica o das descri es dos ICs 6 Apoio computacional MIC Por fim mais do que necess rio especificar e desenvolver uma ferramenta computacional para apoiar a aplica o da t cnica proposta nesta tese S assim os benef cios por ela prometidos ser o plenamente alcan ados Entre outras coisas essa ferramenta dever prover mecanismos adequados para promover o trabalho cooperativo entre modeladores e stakeholders durante a elicita o e a modelagem dos ICs 171 Refer ncias ALENCAR F M R PEDROSA F CASTRO J F B et al 2003 New Mechanisms for the Integration of Organizational Requirements and Object Oriented Modeling In VI Workshop on Requirements Engineering WER 03 pp 109 123 Piracicaba S o Paulo November ANDERSON D J Are Use Cases the death of good UI Design 1999a Dispon vel em lt http www uidesign net 1999 imho feb_imh
244. os seguintes crit rios Crit rio 1 Propiciar o alcance de um objetivo de algum stakeholder Crit rio 2 Deixar o sistema em um estado est vel Crit rio 3 Necessitar de apenas 1 evento aut nomo para ser ativado e completamente executado Entretanto para UCs de consulta ou seja UCs que n o modificam o estado do sistema n o acrescentam nem alteram ou eliminam nada da mem ria ou dos arquivos do sistema basta verificar o atendimento de dois crit rios apenas Crit rio 1 e Crit rio 3 Isso porque para um UC de consulta o Crit rio 2 estados est veis sempre trivialmente atendido j que ap s a realiza o do UC o sistema permanece no mesmo estado em que se encontrava antes presumivelmente um estado est vel No contexto do sistema Restaurante se o 5 3 s o exemplos de UCs de consulta Gerente Solicitar relat rio de consumo di rio e Gerente Solicitar relat rio de receita Supondo que o gerente emite e usa cada relat rio de forma independente do outro ent o cada UC ativado pelo seu pr prio evento aut nomo e portanto eles devem ser mantidos separados Conforme mencionado na se o 4 3 3 pretendemos capturar elementos do MD durante a MUC utilizando principalmente os fluxos de informa es trocadas entre o sistema e seu ambiente durante a realiza o dos UCs Gra as conjuga o dos tr s crit rios acima temos um particionamento do sistema em UCs particularmente favor
245. ot tipo de parte do sistema a desenvolver ocasi o em que quest es de interface H C s o consideradas No entanto no caso geral e no contexto de sistemas de informa o deve se evitar considerar aspectos do projeto da interface H C durante a defini o dos requisitos do sistema Por isso v rios autores t m chamado a aten o para a intromiss o em potencial que a MUC representa para o projeto da interface H C Por exemplo LAUESEN 2002 afirma que a maioria dos tipos de UCs especifica parte do projeto da interface H C sendo portanto inadequados para especificar requisitos no n vel do dom nio da aplica o Outros autores enfatizam a necessidade de se evitar detalhar aspectos de projeto e implementa o da interface H C nos UCs ANDERSON 1999a 1999b DOBING PARSONS 2000 BITTNER SPENCE 2002 CONSTANTINE O relacionamento extend tamb m gera decomposi o JACOBSON 2004 pp 218 21 2000 considera que o caso de uso de Jacobson JACOBSON et al 1992 usualmente assume uma interface de usu rio em particular Para ele importante expressar requisitos independentemente da sua implementa o e realiza o em uma forma particular de IU CONSTANTINE 2001 Conseqiientemente Constantine e seus seguidores prop em uma modalidade de UC livre desse tipo de comprometimento denominada caso de uso essencial BIDDLE NOBLE 2002 Diversidade de abordagens para a MUC Conforme mostrou a se o 2 3 a literatur
246. otDia_comis at_ref Date Vend Profissional_voce Currency totPer_comis dt inc Date dt fim Date oVend Profissional voce Currency racebimentos inic Date d fim Date aClasseltem Classe item oCliente Cliente status_rec String dt corrente Date void totDia_rec dt ref Date aClasseltem Class item oCliente Cliente Currency totDia_recDif dt_ref Date aClasseltom Classe_tem oCliente Cliente Currency totPer rec inic Date dt fm Date aClasseltem Classe item oCliente Cent Currency totPer_recDifd inic Date dt fim Date aClasseltem Classe tem oCliente Cliente Currency totDia_aRec dt ref Date aClasseltem Classe item oClent Cliente Currency toiDia aitecDild ref Dat aClasseltem Classe item oCliente Cliente Currency totPer_aReo t inc Date ct fim Date aClassellam Classe item Cliente Cliente Currency totPer_aRecDif t_inic Date dt fm Date aClasseltom Classe item Cliente Cliente Currency totPer aRecAtat inic Date dt fim Date aClasseltem Classe em oCliente Chant Currency Percentual comissao totDia_prevRec dt ref Date aClasseltem Classe item oClent Ciente Currency totPer_prevRec dt inic Date dt fim Date aClassaliem Classe tem oCliente Client Currency ita caixas nome caixa Sting Aray lt Caia gt ita conta bancaria cons conta Sting cons banco Sting Aray lt Conta_bancaria gt
247. por cada participante os MDs foram comparados e as diferen as analisadas em conjunto pelos participantes visando detectar eventuais problemas com as regras de deriva o O resultado dessa an lise est descrita na se o 6 4 6 Em seguida foi iniciada a implementa o do sistema pela segunda equipe do estudo Nessa etapa foram feitas duas coletas de dados para an lise posterior cobrindo tr s meses de trabalho A primeira coletou dados sobre a evolu o dos modelos MIC e MD ao longo da implementa o da primeira vers o do sistema Tr s pares de vers es dos modelos foram produzidos durante a implementa o para consolidar modifica es efetuadas nos modelos durante o per odo de apura o O analista que participou das duas equipes foi o respons vel pelo preenchimento de uma planilha onde indicava para cada par de vers es as modifica es introduzidas em rela o ao par anterior As informa es preenchidas nessa planilha foram identifica o do s modelo s modificado s indica o do ponto exato IC no MIC classe no MD onde ocorreu a modifica o o elemento modificado o tipo de modifica o inclus o altera o ou exclus o e uma an lise dos motivos que levaram modifica o e caso a modifica o n o pudesse ser obtida via regra de deriva o uma an lise da raz o dessa incapacidade O Ap ndice 5 apresenta a planilha resultante dessa coleta Posteriormente os dados coletados foram analisados pelo
248. pos que aplicaram as duas t cnicas UCs e ICs Por isso seria interessante reproduzir o estudo com grupos maiores visando isolar blocar os diversos fatores potencialmente perturbadores e assim obter resultados mais confi veis Tamb m um n mero maior de participantes motivaria a utiliza o dos m todos estat sticos adequados para a an lise dos resultados obtidos 6 4 Estudo 3 EC 3 Adequa o do MD 6 4 1 Objetivos e Quest es de Investiga o Este estudo de caso foi uma oportunidade para o teste das regras de deriva o no desenvolvimento de um sistema de porte m dio real para uma empresa de medicina e engenharia de seguran a do trabalho At ent o as regras n o tinham passado pelo crivo de sua aplica o a um sistema complexo e de maior porte As quest es a serem investigadas no estudo de caso eram as regras seriam capazes de derivar uma vis o MD adequada a partir do ICs do sistema Se n o que ajustes ou refinamentos deveriam ser feito nas mesmas para se conseguir isso A interpreta o dada nesse estudo para a adequa o da vis o MD do MIC est baseada na defini o proposta por GLINZ 2000 para o conceito de adequa o de um MD em rela o ao MUC correspondente Supondo que o MIC reflete as necessidades dos stakeholders para o sistema a ser desenvolvido a vis o MD do MIC adequada se nenhuma das duas situa es seguintes ocorrer 1 O MD passar a incluir ao longo do desenvolvimento do s
249. precisa fazer parte do mesmo Regra R3d Aloca o de atributo Cria o de classe de associa o Cada item a persistir presente na interface informacional de um IC deve ser alocado como atributo de uma das classes alcan adas pelos identificadores presentes nessa mesma interface Caso nenhuma dessas classes comporte o item ele deve ser alocado em uma nova classe Informa o relativa a um estado anterior do sistema que possivelmente n o mais vigora 46 Em qualquer estado est vel do sistema 99 de associa o criada para esse fim correspondente a uma associa o existente entre as classes alcan adas Procedimento para aloca o Para cada item elementar a persistir presente na interface informacional de um IC o modelador deve escolher uma das classes alcan adas pelos identificadores presentes nessa interface para alocar o atributo correspondente ao item Caso nenhuma dessas classes seja adequada para conter o item como seu atributo o modelador deve criar uma classe de associa o correspondente a uma das associa es existentes entre as classes alcan adas para alocar o item como atributo Regra semi automatiz vel A es automatiz veis 1 Determina o das classes alcan adas pelos identificadores presentes na interface informacional do IC que cont m o item a persistir 2 Cria o e nomea o de uma classe de associa o a partir do nome das classes que participam na associa o
250. quirements Styles and Techniques Great Britain Addison Wesley LEITE J C S P OLIVEIRA A P 1995 A Client Oriented Requirements Baseline In 2nd Intl Symposium on Requirements Engineering pp 108 115 York England March LEITE J C S P et al 1997 Enhancing a Requirements Baseline with Scenarios In 3rd IEEE Intl Symposium on Requirements Engineering pp 44 53 Annapolis USA January LEITE J C S P HADAD G D S DORN J H et al 2000 A Scenario Construction Process Requirements Engineering Journal v 5 pp 38 61 LIANG Y 2003 From use cases to classes a way of building object model with UML Information and Software Technology v 45 pp 83 93 MAC KNIGHT D 2004 Elicita o de Requisitos de Software a partir do Modelo de Neg cio Disserta o de Mestrado IM NCE UFRJ Rio de Janeiro MAFRA S N TRAVASSOS G H 2006 Leitura Baseada em Perspectiva A Vis o do Projetista Orientada a Objetos In V Simp sio Brasileiro de Qualidade de Software SBQS 2006 pp 144 158 Vila Velha ES Brasil Maio MAFFEO B 1992 Engenharia de Software e Especifica o de Sistemas Rio de Janeiro Editora Campus MART NEZ A CASTRO J PASTOR O et al 2003 Closing the gap between Organizational Modeling and Information System Modeling In VI Workshop on Requirements Engineering WER 03 pp 93 108 Piracicaba S o Paulo November
251. quisitos tamb m s o atendidos A determina o de UCs pelos crit rios propostos pode ser considerada uma especializa o do crit rio tradicionalmente recomendado na literatura o de todo UC ter valor para algum stakeholder requisito 1 Isso porque em obedi ncia ao Crit rio 1 todo UC deve levar ao alcance de um objetivo de um ator ou stakeholder e portanto tem valor para esse ator stakeholder Considerando que o UC tamb m deixa o sistema em um estado est vel Crit rio 2 sua realiza o d ao ator stakeholder um sentimento de miss o cumprida ou mais especificamente um sentimento de que a sua parte ou responsabilidade no fluxo de trabalho workflow est conclu da e que a partir da outros atores e eventualmente ele pr prio podem dar prosseguimento a esse fluxo Este um crit rio mais objetivo de valor que os stakeholders percebem facilmente pois exprime algo que faz parte da realidade do seu dia a dia ou seja a divis o de trabalho entre eles Al m disso j que um evento aut nomo abstrai todos os outros eventos por ele subassumidos os UCs assim elicitados realizam toda a funcionalidade do sistema constituindo um particionamento funcional completo do mesmo requisito 3 Por fim interessante observar que os processos subjacentes aos UCs do particionamento proposto est o em um n vel especial e espec fico de abstra o requisito 2 pois o O resultado da decomposi o funcional de um pro
252. r uma das caracter sticas dessa estrat gia manter a responsabilidade principal de identificar os conceitos com o modelador ou seja deixar que ele decida com base em diversos artefatos e n o apenas nos UCs que conceitos escolher para compor o MD Diferentemente da abordagem de Svetinovic a MIC assume que o modelador deve antes de tudo considerar os conceitos que os stakeholders utilizam no dia a dia do neg cio Idealmente esses conceitos devem ser capturados durante o levantamento de requisitos Assim o MUC serve como um canal para elicitar os conceitos de dom nio com a participa o ativa dos stakeholders Trata se de aproveitar a oportunidade e a familiaridade dos stakeholders com a MUC para extrair deles os conceitos que constituir o uma esp cie de baseline para o modelo de dominio final N o se descarta a possibilidade do modelador sugerir novas abstra es ou aperfei oamentos nas abstra es utilizadas pelos stakeholders mas para isso preciso tomar por base as abstra es consolidadas pelos stakeholders 5 7 Considera es Finais Este cap tulo apresentou a solu o constru da nesta tese para o problema alvo escolhido Cap tulo 3 e mostrou que ela atende uma lista de requisitos identificados a partir da an lise das principais causas do problema Cap tulo 4 O passo fundamental na dire o da solu o foi dado com duas provid ncias 1 Escolher os UCs no Nivel Informacional de Objetivos NIO se
253. ra o ou ent o a extens o da funcionalidade de alguma opera o j existente nele Para manter a boa coes o das opera es do MD desaconselh vel estender as opera es construtoras nicas at agora a realizar mudan a de estado no sistema para incluir a mudan a ora necess ria Consistentemente com isso a regra R4d prop e a introdu o de uma nova opera o capaz de realizar a mudan a requerida no estado do sistema bem como se necess rio produzir qualquer sa da especificada no IC garantindo assim a completude do MD em rela o ao MIC no que diz respeito s opera es geradoras de mudan a de estado no sistema Caso o MD possua uma opera o para realizar mudan a de estado no sistema que n o seja uma opera o construtora dever existir no MIC um IC que n o seja de consulta respons vel pela mudan a Se toda opera o desse tipo for resultante da aplica o da regra R4d isso estar garantido e portanto tamb m a completude do MIC em rela o ao MD Por outro lado n o existe a necessidade do MD possuir uma opera o para realizar mudan a de estado no sistema que n o seja uma opera o construtora ou uma opera o gerada pela regra R4d Isso porque a regra R4d se encarrega de gerar opera o para qualquer necessidade de mudan a de estado do sistema que n o esteja coberta por uma opera o construtora Regra R4e Aloca o das opera es Toda opera o gerada pela aplica o de um
254. ra a valida o dessa hip tese foi o EXP 3 embora o EC 2 tamb m tenha contribu do com evid ncias favor veis mesma Tamb m o EC 1 pode ser considerado como tendo contribuido indiretamente nesse sentido pois apesar dos participantes n o terem utilizado as regras de deriva o para a obten o do MD eles conseguiram produzir trabalhando em conjunto mas sem contato com o respons vel pela elabora o do MIC um MD que atendeu plenamente as expectativas desse ltimo Esta hip tese estava desde o in cio validada por constru o na medida em que a MIC uma especializa o da MUC que mant m desta a caracter stica de ser centrada nos usu rios e em seu julgamento de valor Embora o acr scimo da linguagem semiformal adotada na MIC para a especifica o da interface informacional dos ICs Se o 5 3 seja um componente em principio desfavor vel hip tese alguns autores a consideram adequada para os usu rios LAUESEN 2002 A experi ncia mostrou que com um breve treinamento os usu rios passam a trabalhar com a linguagem de maneira confort vel Mas mesmo que assim n o fosse dado o formalismo da linguagem poderia ser utilizado o expediente do parafraseamento autom tico da mesma em descri es em linguagem natural para atender a usu rios menos afeitos ao formalismo O estudo EXP 3 bem como a experi ncia acumulada com a utiliza o da MIC nos demais estudos mostraram que a sobrecarga de esfor o para aplicar a t
255. ra o modelo de dados desde o in cio da atividade de levantamento de requisitos Portanto podemos concluir ser uma pr tica recomend vel a elabora o de um modelo de dom nio em paralelo com a modelagem de requisitos com UCs 3 2 2 Qual deve ser a ordem de elabora o dos modelos A tend ncia atual capitaneada pelos m todos baseados na UML por exemplo RUP JACOBSON et al 1999 d preced ncia ao MUC em rela o ao MD SHOVAL et al 2006 Isso compreens vel a partir das seguintes constata es O MUC e em especial os cen rios dele derivados s o normalmente considerados mais amig veis do que o MD ou seja s o de mais f cil leitura e compreens o pelos stakeholders O MUC tem maior escopo de modelagem do que o MD j que ele inerentemente modela o comportamento do ambiente do sistema representado pelos seus atores al m do comportamento do pr prio sistema enquanto que o MD correspondente tem o escopo de modelagem normalmente restrito ao sistema detalhando elementos internos do mesmo O experimento apresentado em SHOVAL et al 2006 resultou em diagramas de classes de melhor qualidade quando eles s o feitos antes dos UCs pelo menos nas condi es do experimento modelagem de um sistema de informa o dentre outras A hip tese levantada pelos autores para explicar isso que a cria o dos UCs antes da cria o do diagrama de classes mais dif cil por dois motivos
256. rat rio nas etapas iniciais da fase de requisitos A descoberta das classes pode ser feita segundo eles a partir do modelo de contexto o diagrama que mostra os dados que fluem para dentro e para fora do work Em geral os dados armazenados utilizados pelo work entram via fluxos de dados Portanto se existem dados dentro do work deve haver algum fluxo de dados atrav s do qual eles entraram Para cada informa o contida nos fluxos presentes no modelo de contexto deve se perguntar O que descreve essa informa o ou Qual o sujeito dessa informa o O sujeitos s o as classes Portanto ap s analisar dessa forma todos os fluxos de dados muito prov vel que todas as classes de dom nio tenham sido identificadas Os autores n o esclarecem como obter as opera es das classes as associa es entre elas e demais elementos do MD Tamb m n o discutem como verificar a consist ncia entre os modelos e como validar o MD Escrevendo Casos de Uso Eficazes COCKBURN 2005 Este autor praticamente nada diz sobre a utiliza o do MD na fase de requisitos e sua integra o com o MUC Apenas sugere que a identifica o das classes se fa a com base na ocorr ncia de termos que designam conceitos do dom nio na descri o dos UCs E acrescenta que sem a orienta o dos UCs o modelador tende a gastar tempo excessivo modelando partes do dom nio que n o s o relevantes para o sistema desejado Ou seja os U
257. ress o De certa forma Jacobson est propondo um n vel m nimo de abstra o para os UCs mesmo que o fa a de forma indireta e subjetiva 2 4 An lise da Modelagem de Requisitos com UCs Nesta se o analisaremos a MUC no contexto da modelagem de software segundo o paradigma da orienta o a objetos por ser esse um paradigma muito popular nos dias atuais para o desenvolvimento de software Com base em um levantamento feito na literatura a se o seguinte 2 4 1 apresenta e discute as principais vantagens da MUC enquanto a se o 2 4 2 faz o mesmo com rela o s desvantagens dessa t cnica de modelagem 2 4 1 Vantagens da MUC Uma pr tica comum de modelagem de requisitos principalmente antes do advento dos UCs consistia em listar os requisitos ou features LAUESEN 2002 a serem implementados pelo sistema ROBERTSON ROBERTSON 1999 ROBERTSON ROBERTSON 2006 Uma feature pode ser definida como uma afirma o de alto n vel sobre uma capacidade desejada para o sistema em termos de funcionalidade ou algum atributo de qualidade performance seguran a etc JACOBSON NG 2004 Por exemplo a Lista de Requisitos LRqs para um sistema de hotelaria poderia incluir estes dois requisitos 1 o sistema dever ser capaz de colocar um quarto indispon vel em um determinado per odo para a realiza o de reparos 2 o sistema dever ser capaz de reservar quartos pelo seu tipo A literatura aponta pelo menos tr s van
258. rifica o dos modelos com base nas tr s situa es de correspond ncia entre elementos dos dois modelos acima descritas An lise A nosso ver uma das principais desvantagens da proposta de Glinz requerer obrigatoriamente dos stakeholders uma capacidade plena de leitura e an lise do MD pois para terem uma vis o completa do sistema sendo modelado eles precisam ler e analisar o MUC de forma conjugada com o MD Outro aspecto a ressaltar o baixo grau de automatiza o permitido pela proposta How to Use Linguistic Instruments for Object Oriented Analysis JURISTO et al 2000 Os autores afirmam que a AOO An lise Orientada a Objetos n o prov um m todo sistem tico para a obten o do MD object model e do modelo de comportamento behavior model Segundo eles os modelos resultantes da AOO s o fortemente dependentes da experi ncia do modelador e n o replic veis Em vista disso prop em um m todo em 9 passos para a constru o de modelos semiformais cuja principal entrada o documento de requisitos descri o informal do problema em linguagem natural traduzido manualmente para uma linguagem natural controlada Utility Language UL A UL possui constru es que correspondem formalmente atrav s de uma equival ncia matem tica a elementos do MD classes relacionamentos atributos e opera es e do modelo comportamental Com base na 31 sintaxe e sem ntica formais da UL os au
259. rminar um MD ou facilitar a verifica o da consist ncia entre os modelos Essa defici ncia dos UCs em prover elementos facilmente mape veis para o MD fica evidente nas propostas que tentam garantir a consist ncia entre os modelos ou gerar o MD a partir do MUC conforme vimos no cap tulo anterior se o 3 3 Nessas propostas a automa o poss vel se resume an lise ling stica das descri es textuais e 50 informais dos UCs e por conta disso os resultados ficam a depender em grande parte da interpreta o que o modelador faz dessas descri es CAUSAS Os modeladores s o deficientes no conhecimento Fraca orienta o sobre a busca no compreens o do dom nio do sistema C2 espa o de abstra es do dom nio C3 Dificuldades dos stakeholders com o MD C4 Necessidade maior de valida o causa causa 4 agrava gera Baixa cobertura autom tica p deriva o do MD ou p verifica o da consist ncia O MUC fornece poucos subs dios para a obten o do MD C1 causa Grande depend ncia da interpreta o do modelador para deriva o do MD a partir do MUC ou para a dos modelos P1 verifica o da consist ncia entre esses modelos Inconsist ncia Ra entre MD s P2 contribui Ra Valida o n o EN o efetiva do MD P3 contribui PROBLEMAS Figura 4 2 Os problemas alvo e suas causas C2 Defici ncia de conhecimento compreens o do dom nio pelo
260. ro j pertencente ao acervo da biblioteca Esse cadastramento pode ou n o decorrer da doa o do exemplar por um usu rio como reposi o ou compensa o pela perda extravio ou estrago de exemplar a ele emprestado A compensa o deve ser previamente autorizada pela autoridade competente da biblioteca Pr condi es N o h Fluxo B sico l O caso de uso inicia quando o ator Staff indica o objetivo de cadastrar um novo exemplar de livro j pertencente ao acervo da biblioteca O Sistema solicita e o ator Staff informa identificador do livro O ator Staff deve indicar ainda se se trata de reposi o compensa o por exemplar perdido caso em que deve informar identificador do usu rio que est fazendo a doa o de exemplar para repor compensar a perda Deve corresponder a um usu rio que teve exemplar extraviado ou estragado enquanto emprestado a ele ainda n o compensado ou ressarcido identificador do exemplar que est sendo reposto compensado pela doa o Deve corresponder a um exemplar que tenha sido baixado por extravio ou estrago na vig ncia do um empr stimo ao usu rio Caso o livro cujo exemplar est sendo cadastrado tenha um exemplar baixado por extravio ou estrago na vig ncia de empr stimo pelo usu rio trata se de uma reposi o e este identificador ser obrigatoriamente o identificador a ser informado aqui Caso contr rio trata se de uma compensa o Ap s confirma o do at
261. rque houve um erro de interpreta o do item elementar Achava se que no IC de Controle de Despesas onde ele usado o valor dele seria o valor informado no IC de Cadastro de Despesa o que pode n o ser verdade visto que ele pode ter seu valor acrescido de 190 Identifica o do s elemento s envolvido s na Tipo de An lise manuten o manuten o MUC MD juros e multa Atributo obs dispServ classe Inclus o As regras n o determinaram a persist ncia deste atributo Contudo Disp servicos Tipo Al ele foi adicionado pois posteriormente pode se desejar criar um relat rio de disponibiliza es de servi os Por que a regra n o determinou a persist ncia Porque essa informa o n o ser usada na vers o atual do sistema e sim em uma vers o posterior Opera o construtora Inclus o As regras n o determinaram a cria o desta opera o mas ela foi DispServ itemCobr Tipo A2 adicionada por haver necessidade paga porOcor boolean de se criar um contrutor vil itemCobr Currency para a classe DispServ_itemCobr atual itemCobr valorado lim trab int previs o Por que a regra n o determinou a cria o da opera o boolean DispServ itemCobr Pois n o h identificador gerado para esta classe na especifica o classe DispServ_itemCobr que posteriormente teve seu nome trocado para itemCobr_valorado Obs O nome da classe foi trocado porque se encontrou um nome mais significativo para a
262. rray lt olemCobranca le cobranca vliemCobr Currency lim trab int paga_porOcor boolean gt oCliente Cliente oContrato Contrato oVendedor Profssional_voce nTotal_prevParc int dados pare Array lt a prevent Date prevParc Curency gt dt inicio Date dl termino Date obs_dispServ String dt comente Date di vene int Disp servicos Disp senvicos oDisp servicos Disp servicos xCorrecao Percentual d corrente Date Disp servicos afetivarDispServicos temCobr _valorados Array lt oltemCobranca em cobrancavlilemGobr Currency im trab int paga_porOcor boolean gt oContrato Contrato oVendedor Profissional voce x juros Percentual multa Percentual nrTotal_parcelas int dados parcelas Array lt a ven Date parcela Curency bs parcela Sting not boolean bolelo boolean nici Date termino Date obs_dispServ Sting void m pareelalaParcola Parcela recebimento int not parcelas int neTotprevPare int diPrevRec Currency vree Currency vLprevRec Currency descr movl Sting o o 1 ot Servico nome senico Sing Serico nome_serv String allasse fem Classe fem Servico y Hom cobranca o nome temor Sting i i em cobrancafnome ilemGor Siring Servco Servico Item cobranca i Sistema financeiro i i es as al rella base Dat Date ItemCobiyalorado o Ji a a fuo Financeiro inic Date dk fim Date dt_corrente Date caixa boolean contas Array lt Cont
263. rticionamento espec fico do sistema em UCs Se o MD puder ser considerado uma representa o dos estados da mem ria compartilhada resultante desse particionamento ent o as informa es trocadas pelo sistema com seu ambiente poder o ser utilizadas para a extra o de elementos necess rios elabora o do MD O crit rio dos estados est veis Crit rio 2 faz com que apenas estados est veis persistentes e firmes dessa mem ria sejam considerados crit rio de sufici ncia enquanto que a observ ncia do crit rio de eventos aut nomos Crit rio 3 faz com que todos os estados est veis sejam considerados crit rio de completude Al m disso todo estado est vel modela abstra es relevantes para o sistema pois est associado ao alcance de um objetivo de ator stakeholder mediante o uso do sistema Crit rio 1 Em vista disso podemos considerar que o MD desejado aquele capaz de representar os estados da mem ria compartilhada resultante do particionamento gerado pelos tr s crit rios e conseqtientemente os fluxos de entrada e de sa da de informa o trocados entre o sistema e seu ambiente t m um papel importante na determina o desse MD 64 Acabamos de constatar que o requisito 4 se o 5 2 para o particionamento almejado favorecer a determina o de uma vis o do MD a partir da interface informacional dos UCs enunciado no in cio desta se o fica atendido poss vel verificar que os outros tr s re
264. rtida ou mesmo passar a v la como geradora de ganho em vez de custo Essa an lise levaria em conta os benef cios da consist ncia entre o MIC e o MD proporcionada pela nova t cnica e que afetam favoravelmente todo o ciclo de vida de um sistema Outro ponto a ser considerado nessa an lise seria o ganho advindo da explora o plena do potencial de automatiza o da t cnica atrav s de uma ferramenta computacional para apoiar a sua aplica o 7 3 Limita es A nosso ver a limita o mais significativa da t cnica de ICs sua aplicabilidade plena estar restrita a sistemas de informa o se o 5 5 2 Este foi o pre o pago pelas vantagens espec ficas que a MIC tr s na modelagem desse tipo de sistema Outra limita o compartilhada com os UCs a foco apenas em requisitos funcionais deixando a importante categoria de requisitos n o funcionais sem um tratamento espec fico Com seu relat rio t cnico associado FORTUNA et al 2008b 168 7 4 Trabalhos Futuros Al m dos resultados relatados nesta monografia de tese a pesquisa realizada evidenciou diversas oportunidades para novas pesquisas em geral para explorar a rela o ou as possibilidades de intera o da MIC com outras abordagens de Engenharia de Requisitos ou com t cnicas empregadas em outras etapas do ciclo de desenvolvimento de um sistema A seguir apresentamos e comentamos algumas dessas possibilidades l A MIC e a modelagem de proce
265. rupo A demandou mais tempo nessa fase tendo conclu do os seus MDs ao longo da manh do segundo dia Aos participantes foi solicitado anotar o tempo gasto na elabora o dos modelos para a posterior compara o do esfor o n mero de horas despendido em cada tipo de modelagem Tabela 6 8 Cronograma de execu o do estudo PRIMEIRO DIA 23 junho 07 Hora GRUPO A ICs GRUPO B UCs 8 00 9 00 Treinamento UC Inicial Treinamento UC Inicial ete KIT 1 KIT 1 9 00 10 00 Treinamento UC Suplemento Estudo Fase 1 Elabora o do f i KIT la MUC 10 00 10 15 Coffee Break Coffee Break Z A lt 10 15 11 00 Estudo Fase 1 Elabora o do MIC Pogo se LE apOracas do MUC 11 00 12 00 Estudo Fase 1 Elabora o do MIC Estudo D qa do 12 00 13 00 Estudo Fase 1 Elabora o do MIC ee TOM 13 00 14 30 Almo o Almo o Treinamento MIC MD Estudo Fase 2 Elabora o do 14 30 15 30 KIT 2a MD z 15 30 16 30 Estudo Fase 2 Elabora o do MD o Fase a do lt 16 30 17 00 Coffee Break Coffee Break 17 00 18 00 Estudo Fase 2 Elabora o do MD E840 Fase Ra do 18 00 18 30 Estudo Fase 2 Elabora o do MD SEGUNDO DIA 24 junho 07 Hora GRUPO A ICs GRUPO B UCs lt 9 00 10 00 Estudo Fase 2 Elabora o do MD E cont a 10 00 11 00 Estudo Fase 2 Elabora o do MD Entrevista
266. s modeladores Muito frequentemente o contato dos modeladores com o dom nio do sistema se restringe ao breve per odo de tempo em que participam da especifica o do sistema Isso muito pouco se comparado com a dedica o dos profissionais que desempenham suas atividades naquele dom nio ao longo de v rios anos de trabalho A precariedade do conhecimento que os modeladores conseguem interiorizar sobre o dom nio e necessidades dos stakeholders tem sido evidenciada em frequentes alertas na literatura t cnica e cient fica que trata de requisitos sobre a falta de entendimento entre stakeholders e modeladores a respeito do sistema a ser constru do e 51 principalmente sobre a incapacidade comumente observada da especifica o de requisitos refletir as reais necessidades dos stakeholders Portanto em principio os modeladores n o poderiam abrir m o do conhecimento e experi ncia dos profissionais do dom nio na hora de decidir sobre as abstra es a serem inclu das no MD seus relacionamentos e esquemas representacionais para elas Entretanto n o isso que normalmente acontece Durante a elabora o do MD os modeladores em geral trabalham sozinhos confiando basicamente no conhecimento prec rio adquirido sobre o sistema e seu dom nio para interpretar o MUC e decidir sobre qual deve ser o MD correspondente mais adequado N o de admirar que diferentes modeladores cheguem a MDs muito distintos entre si para um
267. s S 11 00 12 00 Entrevistas Entrevistas 6 O Ap ndice 3 mostra exemplares dos ICs produzidos 136 Com os MDs terminados passou se fase de entrevistas com pares de participantes pertencentes a um mesmo grupo Isto foi feito no dia 23 de junho de 2007 com os pares P1 P3 P4 P5 P4 P6 e P5 P6 Como o participante P2 n o conseguiu entregar o modelo de classes no prazo da execu o do estudo mas sim na semana seguinte as entrevistas deste participante com os demais do seu grupo foram feitas em um momento posterior A entrevista do par P1 P2 ocorreu em 24 de outubro de 2007 e a entrevista do par P2 P3 em 26 de outubro de 2007 Essas entrevistas tiveram como finalidade inicial identificar as classes representativas de abstra es comuns entre os modelos do par entrevistado Uma vez identificadas essas classes as entrevistas prosseguiram com a identifica o dos atributos opera es e associa es coincidentes para as classes comuns 6 3 8 An lise de Amea as Na fase de planejamento do estudo foram consideradas precau es a serem tomadas para uma execu o adequada do mesmo Nesta se o s o relatadas observa es registradas durante a execu o do estudo com potencial de influenciar seus resultados S o basicamente amea as validade interna dos resultados Um problema observado foi o entendimento muito variado sobre o sistema a ser modelado e seu dom nio a despeito de um sum rio sobre isso ter sido
268. s atuais Mas se o sistema tiver complexidade menor ou estiver inserido em um ambiente organizacional j bem estudado tal modelagem pode ser dispensada partindo se logo para o MIC Uma sugest o de integra o da MOObj com o MIC identificar dentre os objetivos elicitados na MOObj aqueles pertencentes ao NIO para ent o realizar os passos subsegiientes de elabora o do MIC se o 5 3 Dessa forma sugerimos um processo de modelagem que faz decomposi o e composi o de objetivos segundo uma estrat gia em y espelhado inicialmente top down na MOObj e depois middle up na MIC Enquanto o detalhamento na MOObj prioriza as rela es entre objetivos a MIC se dedica a detalhar principalmente os pr prios objetivos detalhando a sua interface informacional Sendo duas dimens es complementares e em certo grau ortogonais de detalhamento esperamos uma sinergia capaz de gerar aprimoramentos em cada um dos modelos 5 5 5 Grau de Automatismo das Regras e Completude do MD Derivado Nesta se o s o analisados o grau de automatismo das regras apresentadas na se o 5 4 2 e a completude do MD com elas obtido a partir o MIC conforme defini es a seguir Ao final da se o a Tabela 5 2 resume as principais caracter sticas de cada regra O grau de automatismo de uma regra a rela o entre o n mero de a es automatiz veis e o n mero total de a es envolvidas na aplica o da regra O MD est completo em r
269. s acess rias Levantamento e an lise comparativa das v rias abordagens da MUC se o 2 3 e Identifica o e an lise dos problemas e vantagens da MUC se o 2 4 167 o Levantamento e consolida o das orienta es dadas na literatura quanto utiliza o conjunta do MUC e do MD na fase de requisitos se o 3 3 o Identifica o de quest es de pesquisa relevantes para o aperfei oamento da utiliza o conjunta dos dois modelos se o 3 4 o Identifica o e an lise das prov veis causas dos problemas apontados na utiliza o conjunta dos dois modelos se o 4 2 Uma parte significativa do conte do da tese j foi publicada em eventos cient ficos espec ficos da rea FORTUNA BORGES 2005 FORTUNA et al 2007 FORTUNA et al 20084 obtendo coment rios e sugest es dos revisores que contribu ram para o aperfei oamento dos resultados Em princ pio os benef cios advindos da nova t cnica cobram uma contrapartida em termos de um maior treinamento para a sua utiliza o e um maior esfor o por parte do modelador para especificar com rigor os fluxos de informa o trocados entre o sistema e seus atores Entretanto duas considera es podem ser feitas com rela o a essa contrapartida A primeira que os estudos experimentais indicaram que ela acontece em um n vel aceit vel A segunda que mediante uma an lise mais profunda e abrangente parece ser poss vel justificar essa contrapa
270. s cuja nota n o deve ser emitida naquele momento Al m disso deve ser poss vel gerar nota para algumas empresas escolhidas 7 NOVO REQUISITO REGRA DE NEG CIO N O APONTADO INICIALMENTE PELOS STAKEHOLDERS Novo IC Agente adm Cancelar nota com o motivo do cancelamento 7 NOVO REQUISITO REGRA DE NEG CIO N O APONTADO INICIALMENTE PELOS STAKEHOLDERS 21 notas O sistema est gerando a mesma nota com n mero diferente N o pode acontecer 4 ERRO DE IMPLEMENTA O A Regina sugere que o sistema mostre apenas as notas a serem geradas as j geradas seriam mostradas em outro IC 1 PROBLEMA DA INTERFACE COM O USUARIO 20 boletos Boletos zerados mesmo problema que ocorre na gera o das notas 3 ERRO DE IMPLEMENTA O 20 boletos O sistema est gerando a mesma nota com n mero diferente N o pode acontecer 3 ERRO DE IMPLEMENTA O Sugest o que o sistema mostre apenas os boletos a serem gerados os j gerados seriam mostrados em outro IC 1 PROBLEMA DA INTERFACE COM O USUARIO Novo IC Agente adm Cancelar boleto ou talvez apenas uma exclus o j que n o necess rio manter registro disto 7 NOVO REQUISITO REGRA DE NEGOCIO N O APONTADO INICIALMENTE PELOS STAKEHOLDERS 25 Para notas e boletos ainda n o gerados ou cancelados exclu do deve permitir alterar data de vencimento e valor das parcelas de recebimento associadas 4 ERRO DE IMPLEMENTA AO propiciado pela subesp
271. s da MUC e vantagens em rela o LRqs 17 Figura 2 4 UC como artefato central para o desenvolvimento 19 Figura 4 1 Problemas alvo suas pissee ei peaaiiana tras aa anda aa tra ata aa sas a 50 Figura 4 2 Os problemas alvo e suas causas ceeeceseeseeeseeeeceseceseceneeeeeeeeaeceaeeseeess 51 Figura 4 3 Requisitos da solu o c1 ccsisdeccdeacaxesacveteenss ctapcousccsevsetd ance sdeendevasiededanconauers 54 Fig ra 4 A Enoque de solu o asas po asc aa 58 Figura 5 1 Topologia dos processos subjacentes aos UCS ie 64 Figura 5 2 Composi o dos fluxos da aplica o Restaurante 68 Figura 5 3 Vis o do MD do sistema Restaurante ra 84 Figura 5 4 Aplicabilidade da MIC assess aims asc cslrelo dantas tania nana 87 Figura 6 1 Diagrama Box Plot para a vari vel Cobertura 121 Figura 6 2 Diagrama Box Plot para a vari vel Granularidade 124 Figura 6 3 Ilustra o dos elementos da m trica de uniformidade de abstra es 128 xii Lista de Tabelas Tabela 3 1 Elementos do MD com rastros formais a partir do MUC 38 Tabela 5 1 Dicion rio de itens elementares de informa o do UC 3 parcial 69 Tabela 5 2 Caracteriza o das regras de deriva o ceecceesseeeseceseceeseeeeeeeec
272. s de Investiga o e Objetivo da Tese Esta se o descreve na subse o 3 4 1 um problema observado quando v rios modeladores constroem independentemente MDs para um mesmo sistema esses MDs ficam muito diferentes entre si Isso inspirou o estabelecimento de algumas quest es a serem investigadas subse o 3 4 2 a partir das quais foi definido o objetivo principal desta tese subse o 3 4 3 44 3 4 1 O Problema da Inconsist ncia entre MDs Em uma s rie de trabalhos SVETINOVIC 2005 e SVETINOVIC et al 2005 2006 apresentaram e discutiram um problema observado ao longo de 5 cinco anos lecionando um curso sobre t cnicas orientadas a objetos para o desenvolvimento de software Nesse per odo os autores revisaram pessoalmente 135 especifica es de requisitos em m dia 120 p ginas cada de um total de 195 elaboradas com a participa o de 740 estudantes de Engenharia de Software Ci ncia da Computa o Engenharia El trica e Engenharia de Computa o Na sequ ncia das tr s disciplinas do curso os estudantes desenvolvem um sistema de telefonia que inclui um subsistema de informa es para o gerenciamento de contas Eles utilizam UCs para capturar requisitos no n vel de dom nio e a An lise Orientada a Objetos AOO COAD YOURDON 1990 como uma ponte para o projeto OO do sistema Fazendo a revis o das especifica es produzidas pelos estudantes e interagindo com eles os autores observaram muitas dificul
273. s de um gap entre a modelagem com casos de uso e a modelagem de classes de dom nio no desenvolvimento de um sistema particularmente durante a fase de defini o dos requisitos do sistema Por exemplo o n vel de automatiza o alcan ado nas propostas de gera o do modelo de dom nio a partir do modelo de casos de uso ou na verifica o da consist ncia entre eles baixo ou depende da interpreta o do modelador Al m disso j foi observado que diferentes modeladores trabalhando de forma independente e com base nos casos de uso de um mesmo sistema produzem modelos de dom nio bastante discrepantes Este trabalho analisa esses problemas e prop e uma especializa o do modelo de casos de uso para que o mesmo passe a servir como um modelo integrado de requisitos a partir do qual um modelo de dom nio possa ser derivado Regras semiformais s o apresentadas para demonstrar essa capacidade assim como resultados de estudos experimentais realizados para avaliar o modelo proposto vi Abstract of Thesis presented to COPPE UFRJ as a partial fulfillment of the requirements for the degree of Doctor of Science D Sc INFO CASES A REQUIREMENTS INTEGRATED MODEL WITH USE CASES Michel Heluey Fortuna December 2008 Advisors Claudia Maria Lima Werner Marcos Roberto da Silva Borges Department Computer and Systems Engineering There is evidence of a gap between use case modeling and domain modeling in the development of a
274. s do MD Por estado est vel do sistema entendemos um estado alcan ado no t rmino da execu o do 57 processo subjacente a um UC com o alcance de um objetivo de ator alcance esse que por sua vez significa eliminar qualquer necessidade de rollback a um estado anterior Em outras palavras um estado em que o sistema se encontra logo ap s um ator ter conclu do uma atividade de sua responsabilidade no fluxo de trabalho apoiado pelo sistema podendo ent o passar a bola para outros atores darem prosseguimento a esse fluxo no devido tempo Como veremos no pr ximo cap tulo 5 o crit rio de particionar o sistema em UCs com base nos estados est veis do mesmo faz com que a busca por abstra es de dominio para o MD fique restrita s abstra es persistentes entre os estados est veis do sistema Tamb m mostraremos que o crit rio de particionamento resultante capaz de atender n o apenas o requisito em quest o mas tamb m os demais acima indicados 4 3 5 A Solu o Concluindo podemos dizer que a solu o almejada dever ser um modelo integrado para requisitos resultante da especializa o do modelo de UCs pela introdu o de uma regra de elicita o de UCs e pela exig ncia de um maior rigor na descri o dos fluxos de informa o trocados entre o sistema e as entidades externas que com ele interagem atores Para facilitar a refer ncia a essa variante da MUC utilizaremos a denomina o Modelagem Inf
275. s stakeholders A estrutura o baseada nas necessidades dos stakeholders tamb m tem efeitos ben ficos sobre a rastreabilidade de requisitos entre os diversos artefatos produzidos ao 18 longo do ciclo de desenvolvimento de um sistema Rastreabilidade de requisitos a capacidade de se descrever e acompanhar a vida de um requisito tanto na dire o da sua implementa o no sistema forward traceability quanto na dire o de sua origem backward traceability PINHEIRO 2004 Segundo KULAK GUINEY 2003 UCs s o rastre veis pois as est rias contidas neles s o mapeadas naturalmente em artefatos de an lise projeto e testes enquanto que a LRqs n o tem rastreabilidade nesses artefatos Na nossa vis o o foco nos stakeholders e em seus objetivos promovido pelos UCs fez com que o modelo de UCs se tornasse o artefato central do ciclo de desenvolvimento de um sistema referenciado e utilizado em todas as fases desse ciclo Figura 2 4 traduzida de JACOBSON 2004 Requisitos Arquitetura Casos de Uso Planejamento as An lise e Projeto da Intera o J Modelagem de Negocio Projeto da Inteface H C Figura 2 4 UC como artefato central para o desenvolvimento Durante as fases de an lise e projeto do sistema cada UC tem o comportamento modelado atrav s da colabora o entre classes de objetos Na fase de testes cada UC resulta em um conjunto de casos de teste Os UCs tamb m s o importantes para
276. sando entender melhor as inten es relacionamentos e motiva es entre os membros de uma organiza o Algumas propostas para esse tipo de modelagem t m sido apresentadas Um exemplo not vel o modelo i YU 1997 A partir desse tipo de modelagem pode se compreender melhor o funcionamento do ambiente organizacional bem como as rela es humanas e de trabalho entre os participantes da organiza o Com essas informa es os requisitos de uma solu o computacional para processos organizacionais podem ser melhor elicitados e especificados interessante observar que todas essas linhas de pesquisa t m intercess o com UCs Para a ERq Orientada a Objetivos UCs exprimem objetivos Cen rios s o caminhos dentro de um UC E a Modelagem Organizacional pretende ser uma etapa anterior de modelagem a partir da qual os UCs s o elicitados e constru dos 2 Casos de Uso A t cnica de casos de uso use cases UCs teve sua origem com JACOBSON 1987 Desde ent o ela tem sido amplamente adotada na pr tica da modelagem de requisitos de sistemas de software Mesmo com essa sedimenta o na pr tica e com reconhecidos m ritos UCs despertam muitas cr ticas tanto no meio profissional quanto no acad mico Este cap tulo tem por objetivo fazer uma breve recapitula o de UCs e da modelagem feita a partir deles se o 2 1 e 2 2 respectivamente para em seguida apresentar um panorama das diversas abordagens desse tipo de model
277. seja obtidos com uma mesma t cnica foi feita a seguir comparando se as m dias Lyrics e Hurucs Na se o 6 3 3 vimos que Unif L Unif L Unif L Hou ics E RS Unif L Unif L Unif L Hurucs 143 onde Unif L representa a uniformidade de associa es entre os modelos produzidos pelos participantes i e j que aplicaram a mesma t cnica ou seja pertenceram ao mesmo grupo experimental sendo dada pela f rmula se o 6 3 1 E Unif L _ gt ___ L L z L ip Assim com base nos valores da Tabela 6 12 tem se 3 6 4 Los 563 10 7 6 644 4 0 3754 0 5455 0 6667 0 599 UI ICs V 3 3 ON o E Huics 445 3 24322 2 4 1 SO EOZET TOZ 20 3286 Portanto a uniformidade de associa es entre MDs produzidos pelo grupo que utilizou ICs foi em m dia aproximadamente 61 maior do que entre os MDs obtidos com a t cnica tradicional de UCs A Tabela 6 13 mostra os dados coletados sobre os atributos considerando se as classes que representam abstra es coincidentes entre os modelos dos participantes de um mesmo grupo tomados aos pares Tabela 6 13 Atributos nos modelos de dom nio MDs Pares Atributos no Atributos no Atributos Pi Pj modelo de Pi modelo de Pj coincidentes Unif At 9 At i Ati At ij Pl P2 28 24 15 0 4054 PI P3 e 24 16 0 3478 ae S 10 0 3571 z 14 0 3333 oe ze 33 18 0 4186 Ed P aa 9 0 3
278. ser explicitamente criados pelo analista entre as responsabilidades descritas nos EUCs e aquelas inclu das no modelo de classes refor ando a rastreabilidade entre esses dois modelos A proposta cobre a identifica o das classes e suas responsabilidades atributos e opera es embora informalmente A frequ ncia de ocorr ncia de um termo na descri o das responsabilidades de uma classe sugere a cria o de novas classes enquanto que a extra o das responsabilidades a partir dos EUCs bem como a distribui o das mesmas entre as classes s o realizadas segundo a interpreta o do analista Nada dito sobre como estabelecer as associa es entre classes A consist ncia e a completude parcial entre os modelos promovida pelo pr prio processo construtivo informal que deriva o MD a partir dos EUCs Por isso e tamb m por considerarem o modelo resultante dessa deriva o como um modelo 34 preliminar de projeto os autores n o se preocupam em validar o MD com o envolvimento direto dos stakeholders Todo o processo demanda a interpreta o do analista e portanto um esfor o consider vel Por esse motivo pouco automatiz vel From use cases to classes a way of building object model with UML LIANG 2003 O autor apresenta uma proposta de obten o do MD na verdade um diagrama de classes a partir dos objetivos representados pelos UCs do sistema as descri es dos UCs n o s o utilizadas Lan
279. sessessrssressesseesees 159 6 4 7 Considera es sobre o Estudo 3 cccceccccesscccssececesececsseceesseeeeseeeesseeees 162 Do Considera es Finais ae Ri Ein OA A ai leat 162 o Me ONCIUS O di Za R A EAST TAE 166 7 1 Vis o Geral do Trabalho ican dscnccnncasteai nets cn auntie aianesitins 166 7 2 Principais Contribui es e Contrapartida casei chive acieateeiiciveaieas aceon 167 Tas MAMA OSS ord basis aie aa AS has ase atest asa aera 168 TA Trabalhos F t ros isnin aah uae A et Soe 169 LII L C E EEE E E E EE 172 Ap ndice 1 Sintaxe da Ling da Int Informacional de ICs 181 Ap ndice 2 Tabelas do Sistema SIMEL EC 1 0 0 0 0 182 Ap ndice 3 Instrumentos do Estudo 2 EXP 2 ccssscccsssseessseees 185 Ap ndice 4 MD do SisConf EC 3 ccssccssscsssscsssccsssscssscccssesssssees 188 Ap ndice 5 Planilha de Evolu o dos Modelos EC 3 189 Ap ndice 6 Planilha dos Testes de Aceita o EC 3 cccssscccsssees 197 Ap ndice 7 Question rio dos Desenvolvedores EC 3 199 xi Lista de Figuras Figura 1 1 O Desenvolvimento de Requisit0os c cccsccsscesscesssnrsenscessetsceacreacesrsessoneses 5 Fig ra 2 1 Diasramacde UCs AS ities penne DDS OGU TD Ina 10 Figura 2 2 Exemplo de descri o de um UC is sicccescesacssctdaevisgcincastsssecsecencedacsstsessssesenee 13 Figura 2 3 Caracter stica
280. spondente ao atributo n o entra em nenhum IC ou se entra n o necess rio em nenhum IC distinto daquele em que ele entrou condi o que impede a aplica o das regras R3a e R3b e b O item de informa o correspondente ao atributo entra em um IC aparece no fluxo de sa da de outro s IC s como um valor hist rico mas esse valor sempre pode ser restaurado lembrado nesse s outro s IC s condi o complementar que impede a aplica o da regra R3b e c O item n o calculado pelo sistema e se for n o necess rio em outro IC distinto daquele em que ele calculado ou ent o pode ser re calculado em todo IC onde necess rio condi o que impede a aplica o da regra R3c Se o item n o entra e n o calculado pelo sistema ent o o MD n o precisa inclu lo pois ele n o utilizado no sistema e portanto n o precisa compor nenhum estado do mesmo Se o item entra ou calculado em um IC mas n o utilizado em nenhum outro IC mas apenas no IC em que ele entra ou calculado o item n o necess rio representa o de um estado persistente do sistema e portanto n o precisa entrar no MD j que o MD representa apenas estados persistentes e firmes do sistema 2 aut 46 Se um item necess rio em mais de um IC pode ser sempre derivado nesses ICs a partir de itens informados ou de outros itens derivados ent o ele configura um atributo derivado no MD e portanto a rigor n o
281. ssas home pages tais como vers es preliminares livres de artigos notas de aulas orienta es e coment rios A sele o dos pesquisadores foi feita a partir das listas de membros dos comit s de programa dos seguintes eventos RE 2005 2006 Intl Requirements Engineering Conference WER 2005 2006 Workshop em Engenharia de Requisitos CERE 2005 2006 Comparative Evaluation in Requirements Engineering REFSQ 2005 2006 ntl Working Conference on Requirements Engineering Foundation for Software Quality e REET 2005 Intl Workshop on Requirements Engineering Education and Training Tamb m foram considerados os pesquisadores pertencentes ao quadro editorial do Requirements 28 Engineering Journal REJ Ao longo de 2 anos foram selecionados 31 pesquisadores de um total de 161 levantados com base principalmente na sua produ o cient fica em Engenharia de Requisitos A visita s home pages desses pesquisadores feita periodicamente para atualiza o do levantamento dos recursos l dispon veis Livros Procuramos identificar um conjunto de livros sobre ERq com relev ncia para a pesquisa que estamos desenvolvendo Para isso procuramos indica es bibliogr ficas nas home pages dos 31 pesquisadores previamente selecionados a maioria deles tamb m professores fizemos buscas no site da Amazon Bookstore e seguimos as indica es e coment rios dispon veis nesse site do tipo quem compra esse livro tamb m compra
282. sse que representa o sistema Os seguintes padr es sint ticos podem auxiliar a aloca o das opera es determinadas pela regra R4b nas classes Padr o sint tico R4e P1 Interface informacional sem identificadores no n vel P Pc 5195 dia FE mais externo de repeti o ou caso existam se forem condicionais Heur stica Alocar a opera o na classe que representa a aplica o Padr o sint tico R4e P2 Identificador presente juntamente com o item gerador da opera o no escopo de uma repeti o em rela o a outro identificador Heur stica Alocar a opera o na classe de associa o determinada por esses dois identificadores se ela existir J tratado na regra R4b Para manter a coes o das demais classes 35 N vel da repeti o mais externa caso existam repeti es aninhadas Se n o o fluxo s tem 1 n vel e ele o mais externo 81 Padr o sint tico R4e P3 Um ou mais identificadores no mesmo n vel de repeti o em que se encontra o item gerador da opera o Heur stica Alocar a opera o em uma das classes alcan adas por esses identificadores Padr o sint tico R4e P4 Identificador es presente s apenas no fluxo de entrada Heur stica Alocar a opera o em uma das classes alcan adas pelos identificadores do n vel de repeti o mais externo do fluxo No sistema Restaurante opera es vl_consumo vl realiz receita pend receita txServ recei
283. ssos de neg cio Normalmente se considera que a modelagem de um sistema deve ser precedida pela modelagem dos processos de neg cio de uma organiza o aos quais o sistema deve estar alinhado e apoiar A MIC procura manter uma ponte com os requisitos de neg cio adotando a vis o de que cada IC representa um objetivo de neg cio de algum stakeholder Al m disso no mbito da MIC um novo conceito denominado objetivo organizacional est sendo investigado Esse conceito traduz uma vis o mais precisa do que seria um objetivo de neg cio sequ ncias admiss veis e mais prov veis de ICs desempenhados no dia a dia do neg cio Os objetivos organizacionais representam abstra es de mais alto n vel e com forte significado no dom nio de aplica o do sistema Como tal contribuem para a escalabilidade da MIR Este conceito foi preliminarmente testado no Estudo 3 EC 3 se o 6 4 quando percebemos outras vantagens de sua utiliza o a facilmente percebido e validado pelos stakeholders o que contribui para a valida o dos ICs b refor a a verifica o da consist ncia do MIC c estabelece um crit rio centrado nos atores para organizar e priorizar a implementa o e os testes do sistema e d facilita a defini o dos testes de integra o e de aceita o do sistema O Ap ndice 7 inclui entre outras coisas uma avalia o feita por participantes do EC 3 sobre a utiliza o que eles fizeram desse conceito Uma inicia
284. st psu edu impact html gt Acesso em Dezembro 2008 COAD P YOURDON E 1990 Object Oriented Analysis 2nd ed Englewood Cliffs NJ Prentice Hall COCKBURN A 2005 Escrevendo Casos de Uso Eficazes 1 ed Porto Alegre Bookman Editora CONSTANTINE L L 2000 What Do Users Want Engineering Usability into Software Constantine amp Lockwood Ltd June CONSTANTINE L L LOCKWOOD L A D 2001 Structure and Style in Use Cases for User Interface Design In Mark Van Harmelen ed Object Modeling and User Interface Design Designing Interactive Systems pp 245 279 Boston MA Addison Wesley Longman Publishing Co CONSTANTINE L L LOCK WOOD L A D 1999 Software for Use A Practical Guide to the Models and Methods of Usage Centered Design Boston Addison Wesley HE L CARVER J C VAUGHN R B 2008 Using Inspections to Teach Requirements Validation CrossTalk The Journal of Defense Software Engineering January pp 11 15 DAVIS L DAWE M 2001 Collaborative Design with Use Case Scenarios In Ist ACM IEEE CS Joint Conf on Digital Libraries JCDL 01 pp 146 147 Roanoke VA USA June DE LA VARA J L FORTUNA M H WERNER C M L et al 2009a Modelado de Requisitos de Datos para Sistemas de Informacion basados em Procesos de Negocio In XI Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes de Software IDEAS 09 Medellin Colomb
285. stema de Controle Financeiro Quantificando pelos OO s seis num total de nove j foram conclu dos 3 Que diferen as existem entre o diagrama de classes e a implementa o do banco de dados do sistema A primeira diferen a notada quanto a identificadores de classes que n o existem no diagrama de classes mas no banco de dados s o necess rios Outra diferen a no que diz respeito aos relacionamentos entre as classes no diagrama de classes No banco de dados os relacionamentos s o representados pelos identificadores A ltima diferen a notada a convers o de tipos que teve de ser feita de forma a se adequar aos tipos do banco de dados utilizado 4 Como est o organizados os m dulos execut veis na implementa o Qual a rela o com a especifica o dos ICs A funcionalidade especificada nos ICs exatamente aquela implementada Cada IC representado por um diret rio que cont m arquivos referentes a cadastro altera o visualiza o altera o no banco de dados ou outros arquivos pertinentes ao fluxo de entrada e sa da dos IC s Deste modo esta a rela o estabelecida entre a especifica o dos IC s e os m dulos execut veis Acredita se o que foi implementado no sistema est de acordo com o que foi especificado anteriormente 5 Como foram organizados os testes do sistema Que tipos de erros foram encontrados durante os testes do sistema Qual o papel da especifica
286. stidos n o geram opera es j que eles est o dispon veis como atributos na interface das classes 80 ltima do IC 11 v nota IC 3 quant item IC 8 e vi pendCli IC 11 e troco IC 4 Regra R4c fluxos de sa da Todo fluxo de sa da presente em IC cujo processamento n o produz mudan a de estado no sistema ou seja n o possui identificador gerado nem item persistido ou atributo de estado e n o altera o valor de algum item persistido tipicamente ICs de consulta e que n o se resuma a apenas um H33 A un ss a nico item n o persistido d origem a uma opera o para produzir o fluxo No sistema Restaurante opera es consumo dia IC 8 receita IC 9 e penduras IC 11 Regra R4d mudan a de estado Todo IC que causa mudan a no estado do sistema produz uma opera o para realizar essa mudan a e para produzir o fluxo de sa da se existir a menos que uma opera o construtora resultante da aplica o da regra R4a realize toda a mudan a de estado requerida e n o exista sa da a produzir No sistema Restaurante opera es cancelar IC 2 pedirNota IC 3 pagarNota IC 4 e pendurarNota IC 5 Regra R4e Aloca o das opera es Toda opera o gerada pela aplica o de uma das regras R4b R4c ou R4d a um IC deve ser alocada em uma das classes alcan adas pelos identificadores presentes na interface informacional do IC ou na l 34 cla
287. strar uma conta 2 O sistema solicita as informa es necess rias de uma conta gt conta banco conta agencia 3 O sistema cadastra a conta e emite uma mensagem de sucesso id conta 4 O caso de uso termina Ator Funcion rio da Empresa IC2 Cadastrar Credor O ator informa ao sistema sua necessidade de cadastrar um credor 2 O sistema solicita as informa es necess rias de um credor gt credor tipo pessoa nome CPF raz o social CNPJ endereco contato telefone email 3 O sistema cadastra o credor e emite uma mensagem de sucesso id credor 4 O caso de uso termina Ator Funcion rio da Empresa IC3 Cadastrar Cliente 1 O ator informa ao sistema sua necessidade de cadastrar um cliente 2 O sistema solicita as informa es necess rias de um cliente gt cliente tipo pessoa nome CPF raz o social CNPJ endereco contato telefone email 3 O sistema cadastra o cliente e emite uma mensagem de sucesso id cliente 4 O caso de uso termina Ator Funcion rio da Empresa IC4 Cadastrar servi o 1 O ator informa ao sistema sua necessidade de cadastrar um servi o oferecido pela empresa 2 O sistema solicita as informa es necess rias de um servi o gt servico nome descricao preco padrao 3 O sistema cadastra o servico e emite uma mensagem de sucesso id servico 4 O caso de uso termina Ator Funcion rio da Empresa IC5 Cadastrar item de despesa
288. stros formais entre os elementos do MUC e do MD Considera es Finais sobre as Propostas da Literatura Cient fica Nela s o indicados os elementos do MD contemplados com esses rastros dificuldade para cobrir os principais elementos do MD Mesmo a proposta de SUBRAMANIAN et al 2004 que trata a maioria deles o faz apenas sugerindo os Tabela 3 1 Elementos do MD com rastros formais a partir do MUC 1 2 3 4 5 Classes X Atributos X Legenda de estado Associa es Multiplicidade Opera es Assinatura 11 Glinz 2000 2 KG6sters et al 2001 3 Biddle et al 2002 4 Liang 2003 5 Subramaniam et al 2004 Pela observa o da Tabela 3 1 fica evidente que as propostas t m em geral elementos que devem ser em seguida confirmados ou n o pelo modelador 3 3 3 Propostas da Literatura T cnica A seguir apresentamos as orienta es que alguns livros fornecem quanto utiliza o dos dois modelos UCs e MD na fase de requisitos Nosso objetivo fornecer uma vis o representativa da t cnica empregada ou ensinada nessa rea Assim como fizemos com rela o aos artigos relatados na se o anterior focamos principalmente os seguintes t picos O papel do MD na fase de requisitos A obten o de elementos do MD a partir do MUC O estabelecimento de rela es ou rastros f
289. t venc Se a data de vencimento de uma parcela i for menor ou igual data de venc da parcela 1 1 dar uma mensagem de alerta 2 REQUISITO DA INTERFACE COM O USU RIO 1 25 I 1 dt venc Esta aceitando 0 e 32 por exemplo 3 ERRO DE IMPLEMENTACAO 1 8 Permite cancelar um contrato mantendo suas disponibiliza es de servi o apesar das parcelas de recebimento deverem permanecer 4 ERRO DE IMPLEMENTA O propiciado pela subespecifica o do DI Bloquear na 1 vers o do sistema o bot es de exclus o por exemplo o bot o de exclus o de contrato PARTE 197 OO IC Nome Elem Observa es INTEGRANTE DA MIC QUE N O FOI SEGUIDA NA IMPLEMENTA O n o considerado 25 Possibilitar a altera o e cancelamento das parcelas valor vencimento caso essas ainda n o tenham sido pagas pelo cliente motivo resultado de negocia o no cancelamento de um contrato por exemplo 7 NOVO REQUISITO REGRA DE NEG CIO N O APONTADO INICIALMENTE PELOS STAKEHOLDERS 21 notas Notas zeradas por exemplo pemso cada novo que n o aconteceu est o sendo geradas N o deve 4 ERRO DE IMPLEMENTA O propiciado pela subespecifica o do DI 25 A primeira parcela gerada deve ter data de vencimento igual data base de vencimento informada 7 NOVO REQUISITO REGRA DE NEG CIO N O APONTADO INICIALMENTE PELOS STAKEHOLDERS 21 Deve ser poss vel indicar algumas empresa
290. ta total e vl pend as 5 primeiras provenientes do IC 9 e a ltima do IC 11 alocadas na classe Restaurante pelo padr o R4e P1 v nota IC 3 quant item IC 8 e vl_pendCli IC 11 alocadas nas classes Pedido Item e Cliente respectivamente pelo padr o R4e P3 e troco IC 4 alocada na classe Pedido pelo padr o R4e P4 O grau de acerto proporcionado pelos padr es sint ticos foi de 11 11 100 Os seguintes padr es sint ticos podem auxiliar a aloca o das opera es determinadas pelas regras R4c e R4d nas classes Padr o sint tico R4e P5 Interface informacional sem identificadores no n vel mais externo ou caso existam se forem condicionais ou estiverem dentro do escopo de uma repeti o n o unit ria Heur stica Alocar a opera o na classe que representa a aplica o Padr o sint tico R4e P6 Identificador n o condicional presente no n vel mais externo do fluxo de entrada Heur stica Alocar a opera o em uma das classes alcan adas por esse identificador Padr o sint tico R4e P7 Identificador apenas no fluxo de sa da no n vel mais externo do fluxo e fora do escopo de repeti o n o unit ria Heur stica Alocar a opera o em uma das classes alcan adas pelo identificador No sistema Restaurante as opera es determinadas pela regra R4c s o assim alocadas nas classes opera es consumo dia IC 8 receita IC 9 e penduras IC 11 alocadas na classe R
291. tado as constata es de que 1 a maior de todas as uniformidades de abstra es obtida entre modelos de participantes de um mesmo grupo foi obtida aplicando ICs e 2 a menor uniformidade de abstra es entre os pares de modelos constru dos com ICs maior do que a maior uniformidade de abstra es entre os pares de modelos constru dos com a outra t cnica UCs A tabela 6 12 mostra os dados coletados sobre as associa es considerando se as classes que representam abstra es coincidentes entre os modelos dos participantes de um mesmo grupo tomados aos pares Tabela 6 12 Associa es nos modelos de dom nio MDs Pares Associa es no Associa es no Associa es Unif L Pi Pj modelo de Pi Li modelo de Pj L coincidentes L A P1 P2 5 6 3 0 3750 P1 P3 10 7 6 0 5455 P2 P3 6 4 4 0 6667 P4 P5 4 5 3 0 5000 P4 P6 2 7 2 0 2857 P5 P6 2 4 1 0 2000 Como visto na compara o de uniformidades das abstra es dos MDs poss vel que associa es ocorram entre classes que representam uma abstra o em um modelo e que corresponda a mais de uma classe em outro modelo Desta maneira a associa o Pagamento FormaPagamento do modelo do participante P3 coincidiu com as associa es Despesa Parcela e Credito Parcela do participante P1 A compara o da uniformidade de associa es entre os modelos de classes de cada grupo ou
292. tagens da modelagem de requisitos com UCs MUC em rela o LRgs relacionadas e discutidas a seguir 1 Facilita a verifica o de completude e consist ncia da especifica o de requisitos 2 Reduz o risco do sistema modelado nao atender as reais necessidades dos stakeholders LARMAN 2004 16 3 Facilita a rastreabilidade de requisitos entre os artefatos produzidos ao longo do desenvolvimento KULAK GUINEY 2003 A Figura 2 3 mostra as vantagens listadas anteriormente e a rela o delas com algumas caracter sticas tamb m apontadas na MUC servindo de pano de fundo para a an lise que se segue promove Envolvimento dos stakeholder s favorece facilita Completude e consist ncia dos requisitos Risco de n o atendimento gs T dos reais anseios Rastreabilidade de requisitos dos stakehol ders 1 entre os artefatos 2 Figura 2 3 Caracteristicas da MUC e vantagens em rela o LRqs Existem diversos fatores de qualidade que devem estar presentes em uma especifica o completude consist ncia precis o legibilidade manutenibilidade concis o compreensibilidade testabilidade etc Desses a utiliza o de UCs em substitui o ou acr scimo Lista de Requisitos LRqs impacta mais diretamente a consist ncia completude e rastreabilidade de requisitos conforme indicado na Figura 2 3 Uma especifica o incompleta pode resultar em um sistema incapaz de atender todas as nec
293. tant messenger c As especifica es foram elaboradas em paralelo com o desenvolvimento do sistema cada objetivo informacional sendo liberado assim que a sua defini o ficava pronta d Toda a divis o de trabalho entre os analistas foi feita por objetivo informacional e O esquema conceitual e o projeto do BD do sistema foram elaborados de forma incremental por objetivo informacional pelos analistas sem a participa o do engenheiro O estudo de caso SIMEL antecede a defini o das regras de deriva o do MD se o 5 4 2 e portanto o MD do SIMEL foi obtido de forma ad hoc a partir da sua especifica o informacional Mesmo assim o esquema conceitual do BD elaborado pelos analistas atendeu as expectativas do engenheiro O Ap ndice 2 apresenta o MD do SIMEL com o intuito de dar uma id ia do porte do sistema constru do 6 1 3 Estudo Precursor 2 EC 2 1 Estudo da Uniformidade dos MDs Outro estudo foi realizado com a finalidade de avaliar preliminarmente a compreensibilidade e usabilidade das regras de deriva o e respectivos padr es sint ticos se o 5 4 2 bem como ter uma primeira avalia o do grau de uniformidade dos MDs resultantes da sua aplica o Participaram do estudo em momentos diferentes dois profissionais graduados em Ci ncia da Computa o analistas de sistemas de uma empresa de medicina e seguran a do trabalho ambos com 2 anos de experi ncia no desenvolvimento de sistemas e 1 ano na
294. tiva concreta para integrar os resultados da pesquisa desenvolvida nesta tese em um m todo para o desenvolvimento de sistemas alinhados com os processos de neg cios de uma organiza o j est em andamento DE LA VARA et al 2009a DE LA VARA et al 2009b 78 Embora n o tenha sido relatado na se o que apresentou o estudo 6 4 por se tratar de uma investiga o preliminar prova de conceito n o enquadrada nos objetivos principais do estudo No entanto a opini o de alguns participantes que utilizaram o conceito pode ser vista no Ap ndice 7 169 2 A MIC e a Modelagem Orientada a Objetivos MOObj A se o 5 5 4 discutiu a rela o entre a MOObj e a MIC e indicou um caminho para uma poss vel integra o entre elas Essa integra o em princ pio desej vel do ponto de vista da MIC pela capacidade da MOObj de analisar objetivos incluindo objetivos n o funcionais soft goals Portanto uma sugest o de trabalho futuro investigar como essa integra o poderia ser feita e determinar as propriedades do modelo combinado resultante Essa investiga o deveria tamb m levar em conta o conceito de objetivo organizacional mencionado no item 1 acima 3 A MIC e o projeto da interface H C Os estudos de caso realizados mostraram ind cios do potencial da MIC para ajudar no projeto da interface H C de um sistema A descri o rigorosa da interface informacional dos ICs abre uma s rie de possibilidades para
295. to da Silva Borges Tese doutorado UFRJ COPPE Programa de Engenharia de Sistemas e Computa o 2008 Referencias Bibliogr ficas p 172 180 1 Info cases 2 Casos de uso 3 N vel informacional de Objetivos 4 Interface informacional de casos de uso I Werner Cl udia Maria Lima et al II Universidade Federal do Rio de Janeiro COPPE Programa de Engenharia de Sistemas e Computa o II Titulo iii Aos meus pais Feliciano e Jorgette in memorian minha esposa Teresinha e s minhas filhas Luiza e Raquel iv Agradecimentos Aos meus orientadores Cl udia Werner e Marcos Borges pelo apoio e orienta o nos momentos certos Aos professores Ana Regina Rocha J lio Leite Guilherme Travassos e Renata Ara jo que aceitaram participar da minha banca Aos dois primeiros tamb m pela orienta o valiosa durante o meu exame de qualifica o Aos meus professores do PESC COPPE Claudia Werner e Guilherme Travassos e aos do NCE IM Marcos Borges Fl via Santoro Maria Luiza Campos Renata Ara jo Carlo Emmanoel Oliveira bem como a muitos outros que os precederam pelo tanto que contribu ram para a minha forma o Aos amigos e colegas Carlos Henrique Duarte Leonardo Murta Marco Ant nio Ara jo e Tarc sio Lima pela valiosa ajuda durante o trabalho de tese Aos meus alunos William Fernandes Vitor Padilha Gon alves e Gilmar Pedretti al m de muitos outros pela amizade participa
296. tores apresentam um conjunto de regras e diretrizes para auxiliar o modelador a extrair os elementos desses modelos Alguns procedimentos de verifica o de consist ncia s o preconizados ao longo das etapas do m todo An lise Os autores reconhecem a import ncia de se ter um MD na fase de requisitos N o utilizam UCs como ponto de partida para obten o do MD ambos os modelos MD e modelo de comportamento resultam do documento de requisitos e s o ao longo do processo de constru o verificados entre si Alguns rastros formais s o estabelecidos entre os modelos por conta de sua base comum representada pela tradu o do documento de requisitos na UL Uma vez que o m todo proposto adota a abordagem de an lise ling stica de texto em linguagem natural ele sofre as mesmas limita es de trabalhos semelhantes entre eles depend ncia da qualidade do texto que serve de base para a an lise necessidade dos modeladores terem conhecimentos ling sticos depend ncia da interpreta o dos modeladores e um grau limitado de automatiza o No entanto a utiliza o da UL tem uma influ ncia favor vel ao diminuir a necessidade de interpreta o dos modeladores pois a UL leg vel pelos stakeholders e aumentar o grau de automatiza o gra as ao mapeamento formal entre ela e o MD Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications KOSTERS et al 2001 Os
297. tos segundo esses objetivos contribuem para facilitar a verifica o da consist ncia e completude da especifica o e a sua valida o pelos stakeholders Em consegii ncia essa caracter stica especial da MUC tamb m ajuda a reduzir o risco do sistema resultante n o atender adequadamente as reais necessidades dos stakeholders Outra caracter stica da MUC tamb m fundamental para propiciar a redu o do risco do sistema especificado n o satisfazer os stakeholders o sentimento de familiaridade que ela desperta neles Eles n o se sentem intimidados ao serem apresentados t cnica de UCs LARMAN 2004 Isso ocorre por dois motivos principais Primeiro porque essa t cnica na ess ncia um relato de est rias ou cen rios de utiliza o do sistema pelos usu rios atores que com ele interagem e como tal percebida como simples e familiar por eles KULAK GUINEY 2003 Al m disso ela emprega pelo menos na forma mais comum a linguagem natural para a descri o dos cen rios casos de uso Nas fases iniciais da modelagem essa linguagem utilizada sem maiores restri es ou elementos estruturantes e portanto n o h necessidade de um treinamento extenso para capacitar os stakeholders a ler ou mesmo escrever vers es iniciais outlines dos UCs Isso tudo facilita e estimula o envolvimento dos mesmos na defini o e revis o dos requisitos o que ajuda a garantir a sintonia do sistema especificado com os anseios do
298. tual Classes que representam associa es entre classes 161 Opera es para mudan a de estado do sistema e do ambiente O estudo de caso propiciou a descoberta de que o conjunto vigente de regras para a determina o das opera es do MD n o tratava todas as situa es poss veis Especificamente quando um IC tinha identificador gerado nele e ao mesmo tempo produzia outras mudan as de estado no sistema ou ent o sa da a aplica o das regras se restringia a gerar uma opera o construtora que como tal n o deve produzir outras mudan as de estado al m daquelas correspondentes inicializa o de um objeto nem produzir sa das previstas no MIC Por isso resolvemos alterar a vers o vigente da regra R4d para torn la aplic vel na situa o descrita A vers o vigente desta regra era R4d Todo UC que n o tenha sido contemplado com opera es originadas pelas regras R4a e R4c d origem a uma opera o para realizar mudan a no estado do sistema a ser inclu da em uma das classes alcan adas pelos identificadores presentes na interface informacional do UC ou na falta desses a ser inclu da na classe que representa o sistema Esta regra em sua vers o atual mais abrangente R4d mudan a de estado Todo IC que causa mudan a no estado do sistema produz uma opera o para realizar essa mudan a e para produzir o fluxo de sa da se existir a menos que uma opera o construtora resultante da aplic
299. tual dt_geracao Dale aT parcelas ink dados_parc Array lt dt_venc Date parcela Gurency gt corrente Date Despesa Ad bares ng E Despesa aCiasseliom Classe ilem descr desp String aAreaEmp Area empresa oF unc Profissional voce dados cl Array lt oCliente Cliente custo Curency gt oFomec Fomecedor vi_prevDesp Currency nrTot_prevPare int dados_parcPrev Aray lt dt prevVene Dale prevPare Currency gt di corent Date Despesa te2 banco Sting Cliente nome ci Sving co cl Sting cp ch Sing lograd ch Sting baio ch Sting cep ci Sting cidade cl String estado ci Sting contato ch Aray lt Contato Ciente Despesa aDespesa Despesa bCorrecao Percentual corrente Dae Despesa nome gerente Sting ista contrtosfestado String Array lt Conrato gt efetivar despesa v desp Currency vTO parcels nt dados parc Array lt dt venc Date parcela Curency gt nota bolean nr_nola String juros Percentual mula Percentual d geracao Dale void Emenda m ocorlem nome servico Sting nome temCobr String int mr parcela aParcela Parcela despesa int Tot parcelas int Conia bancaria definition ml Conta bancaria di 4 not prewParo int saldo inie dt ref Date Currency VL iPrevDespl Currency saldo fimo ef Date Currency deep Curency saldolDia bancodt ref Date Currency T MARecDia_banco dt_ref Date Currency vl_prevDesp Cures mente ro saldo Dia
300. u 42 l gica de dom nio N o h qualquer recomenda o sobre como chegar a esses m todos na fase de requisitos Quanto s determina o das associa es entre classes a recomenda o de que sejam consideradas a associa es que representem relacionamentos que devem ser preservados por algum tempo e b associa es derivadas de uma lista de associa es comuns que incluiria transa es do tipo A uma transa o relacionada com outra transa o B A um item linha da transa o B A um produto ou servi o para a transa o B etc Nada diz sobre como determinar outros elementos do MD tais como atributos das classes e multiplicidades das associa es Igualmente as quest es de consist ncia entre o MUC e o MD e de valida o do MD s o omitidas Aspect Oriented Software Development with Use Cases JACOBSON NG 2004 Segundo os autores uma passagem pelos cen rios de neg cio que o sistema pretende apoiar permite identificar as informa es que o sistema dever guardar ou manipular Essas informa es s o modeladas como classes de dom nio Em geral basta identificar para cada classe atributos essenciais e relacionamentos com outras classes pois nesse est gio se est meramente capturando conceitos e seus relacionamentos Mais adiante na fase de an lise com os UCs j especificados as responsabilidades das classes s o determinadas ao se elaborar diagr
301. u o para ambos 2 1 3 Objetivo e Enfoque da Solu o O objetivo deste trabalho foi resolver o problema da transi o dif cil entre o MUC e o MD Para isso constru mos uma variante da t cnica de UCs mais especificamente uma especializa o dela capaz de diminuir o grau de depend ncia da interpreta o do modelador no momento de se obter um MD a partir do MUC ou de se verificar a consist ncia entre esses modelos A nova t cnica resultou da introdu o de uma regra de determina o de UCs e da exig ncia de um maior rigor na descri o dos fluxos de informa es trocados entre o sistema e seus atores Al m de caracterizar e analisar o problema envolvido na utiliza o dos dois modelos MUC e MD o enfoque de solu o adotado justificado e s o apresentadas evid ncias de que ele capaz de propiciar uma solu o aceit vel para o problema incluindo a manuten o de pontos fortes da modelagem de requisitos com UCs 1 4 Organiza o Esta tese est organizada em sete cap tulos incluindo este primeiro de introdu o onde feita ainda uma breve revis o da rea de Engenharia de Requisitos focando basicamente os assuntos mais relevantes para a tese O Cap tulo 2 apresenta um resumo da t cnica de UCs discute as diversas abordagens dessa modelagem encontradas na literatura e identifica e analisa seus pontos fortes e fracos O Cap tulo 3 justifica a utiliza o conjunta do MUC e do MD na fase
302. ude do MD em rela o ao MIC no que diz respeito aloca o das opera es s classes Por outro lado como toda aloca o de opera es no MD feita via regra R4e o MIC tamb m estar completo em rela o ao MD A Tabela 5 2 d uma vis o geral das principais caracter sticas das regras de deriva o 5 6 Trabalhos Mais Diretamente Relacionados As propostas extra das da literatura apresentadas na se o 3 3 2 t m em comum com o MIC a motiva o tornar mais efetiva a obten o de um MD a partir do MUC ou promover a consist ncia entre os dois modelos Entretanto nenhuma delas adota a estrat gia de utilizar um modelo integrado de requisitos mantendo o MUC como um dos modelos analisados em separado O resultado invariavelmente a obten o de MDs bastantes incompletos e ou uma grande depend ncia do modelador para interpretar os elementos de cada modelo baixo automatismo Nesta se o s o discutidos outros dois trabalhos relatados na literatura bem mais pr ximos da solu o constru da nesta tese o primeiro porque tamb m adota a abordagem de modelo integrado de requisitos e o segundo porque ataca diretamente o problema da inconsist ncia entre MDs obtidos por diferentes modeladores para um mesmo sistema 107 Tabela 5 2 Caracteriza o das regras de deriva o Regra Det Auto Grau PSint Compl RiI classes sim semi 67 l MIC MD R2 associa es n o semi ay 1 8
303. ugere multiplicidade O limite superior da multiplicidade no lado 6699 da classe identificada por id O limite inferior de ambas as multiplicidades 0 co 2924 a menos que a aplica o de outro padr o sint tico determine o limite superior da multiplicidade do lado da classe identificada por id nao sugerido Padr o sint tico R2 P6 Ocorr ncia de R2 P4 identificadores da associa o no fluxo de entrada do IC com nenhum deles no escopo de uma repeti o em rela o ao outro Heuristica sugere multiplicidade O limite inferior de ambas as multiplicidades 0 a menos que a aplica o de outro padr o sint tico determine 1 os limites superiores n o s o sugeridos No sistema Restaurante Figura 5 2 o padr o sint tico R2 P4 ocorre nos ICs 3 Pedir a nota e 5 Pendurar a nota com a presen a dos identificadores id pedido e id cliente no fluxo de entrada Assim pode ser formado o par lt id pedido id cliente gt o que sugere pela heur stica associada a esse padr o sint tico a introdu o da associa o Pedido Cliente grau de acerto 1 1 100 Com rela o s multiplicidades dessa associa o a ocorr ncia do padr o sint tico R2 P5 sugere 0 como limite inferior das multiplicidades de ambos os lados da associa o grau de acerto 2 2 100 2 Em outro UC para a mesma associa o 75 Padr o sint tico R2 P7 Ocorr ncia de R2 P4 ident
304. um UC iniciada a partir de um est mulo proveniente de um dos seus atores OMG 2008 A lista de atores um bom ponto de partida para a elicita o dos UCs Para cada ator identificado pode se relacionar aquilo que o ator necessita obter atrav s da utiliza o do sistema Cada UC deve representar uma tarefa cuja realiza o traduza um valor mensur vel para o ator Por exemplo em um sistema banc rio o ator que desempenha o papel de cliente do banco pode desejar obter o saldo de sua conta banc ria ou fazer uma transfer ncia de fundos entre contas Cada um desses objetivos d origem a um UC 2 2 O Modelo de Casos de Uso MUC Um modelo de UCs MUC um modelo do sistema definido em termos de UCs atores e relacionamentos entre eles Ele cont m em geral v rios UCs e frequentemente representado por um diagrama de UCs BITTNER SPENCE 2002 O diagrama de UCs OMG 2008 um elemento gr fico que d uma vis o geral dos UCs e seus respectivos atores A Figura 2 1 exemplifica esse diagrama para um sistema de biblioteca ilustrando tamb m tr s dos quatro tipos de relacionamentos normalmente considerados entre UCs az reserva de livro 4 O SR VL te O es a Faz empr stimo Autentica Cadastra A I Faz exemplar include Usu rio 7 novo Do Leitor B Bibliotec rio OS 2 es Retoma ie Cadastra exemplar assunto Figura 2 1 Diagrama de UCs
305. uma mem ria compartilhada Portanto interessante analisar qual seria a rela o entre as duas abordagens AE e o MIC Na AE o particionamento feito por eventos gerados pelo ambiente fora do controle do sistema dividindo o mesmo em atividades essenciais Tais eventos podem ser de dois tipos 1 eventos iniciados por entidades do ambiente denominados eventos externos por MCMENAMIM et al 1991 pp 20 e eventos sinalizados por fluxos reais por MAFFEO 1992 pp 182 ou 2 eventos iniciados pela passagem do tempo denominados eventos temporais por MCMENAMIM et al 1991 e eventos sinalizados por fluxos virtuais por MAFFEO 1992 Nesse particionamento a cada evento corresponde uma atividade essencial que traduz a resposta do sistema planejada para o evento O conjunto das atividades essenciais s o todas as tarefas que o sistema deve realizar mesmo considerando a utiliza o de uma tecnologia perfeita para sua implementa o MCMENAMIM PALMER 1991 pp 23 As atividades essenciais se subdividem em atividades fundamentais que s o parte da finalidade do sistema e em atividades custodiais respons veis por estabelecer e manter a mem ria essencial do sistema O particionamento do sistema empregado na AE inspirou inicialmente a ado o do conceito de particionamento por eventos aut nomos e do ponto de vista da sua Com tecnologia perfeita um sistema teria um processador e um meio de armazenamento perfeitos
306. undo n vel cada UC decomposto na sequ ncia de a es que expressam o comportamento do sistema e dos atores que com ele interagem Essas a es tamb m s o abstra es de sub processos cada qual realizando uma parte da funcionalidade do UC Muitos autores alertam para os perigos da decomposi o funcional na modelagem com UCs BITTNER SPENCE 2002 ANDERSON 1999a 1999b JACOBSON 2004 Certamente eles n o est o se referindo decomposi o mencionada no par grafo anterior intr nseca aos UCs Eles se referem a uma decomposi o funcional recursiva em v rios n veis adicionais comum na modelagem com UCs e cujo principal indutor o relacionamento include Por isso eles recomendam uma disciplina r gida no uso desse relacionamento BITTNER SPENCE 2002 ou mesmo a sua completa desconsidera o KULAK GUINEY 2003 ROBERTSON ROBERTSON 2006 O efeito negativo da decomposi o funcional recursiva de UCs est na gera o de UCs que n o preenchem o atributo chave de possuir valor real para pelo menos um dos stakeholders do sistema BITTNER SPENCE 2002 JACOBSON 2004 dificultando a percep o dos stakeholders quanto ao que o sistema faz e consequentemente do seu valor para eles Outro efeito desfavor vel est na considera o prematura de aspectos de projeto do sistema Interfer ncia no projeto da interface H C Durante a fase de requisitos em algumas situa es pode ser til construir um pr
307. upo tomados aos pares Tabela 6 16 Uniformidade de associa es atributos opera es e representacional Pares Unif O Unif Ri Pi Pj Unif Li Unif At a D a 2 P1 P2 0 3750 0 4054 0 5625 0 2727 0 4476 0 3510 P1 P3 0 5455 0 3478 0 8750 0 7500 0 5894 0 5478 P2 P3 0 6667 0 3571 0 6471 0 5000 0 5570 0 5079 P4 PS 0 5000 0 3333 0 1944 0 2121 0 3426 0 3485 P4 P6 0 2857 0 4186 0 1389 0 0323 0 2811 0 2455 P5 P6 0 2000 0 3103 0 0769 0 0833 0 1957 0 1979 Legenda 1 Considerando opera es construtoras 2 N o considerando opera es construtoras A compara o da uniformidade representacional entre os MDs de cada grupo ou seja obtidos com uma mesma t cnica foi feita a seguir comparando se as m dias Lurics e Hur vcs Na se o 6 3 3 vimos que Unif R Unif R Unif R y HUour cs i 3 e Umf R Umf R Unif R hs Hur vcs z 3 147 onde Unif R representa a uniformidade representacional entre os modelos produzidos pelos participantes i e j que aplicaram a mesma t cnica ou seja pertenceram ao mesmo grupo experimental sendo dada pela f rmula se o 6 3 1 Unif L Unif At Unif O 3 Unif R Primeiramente com base nos valores da tabela 6 16 e considerando todas as opera es tem se 0 4476 0 5894 0 5570 Hurics 3 0 5313
308. utro tipo Neste aspecto a prioridade adotada decorreu da sugest o de COOK e CAMPBELL 1979 apud WOHLIN et al 2000 para experimentos com a finalidade de testar teorias Para essa categoria de experimentos eles sugerem a seguinte prioridade da maior para a menor validade interna validade de constru o validade de conclus o e validade externa A an lise que se segue apresentada nesta ordem 134 Validade Interna Para evitar que fatores ambientais e externos produzissem efeitos que pudessem ser confundidos com os efeitos dos tratamentos t cnicas empregadas os tratamentos foram aplicados ao mesmo tempo um para cada grupo de participantes e no mesmo ambiente na empresa em que o autor trabalha Os participantes de cada grupo ficaram em salas distintas e foram instru dos a n o trocar informa es entre si Para garantir a observ ncia dessa regra cada sala contou com a presen a constante de um dos experimentadores Validade de Constru o Neste aspecto o treinamento ministrado aos participantes e o material de apoio que acompanhou o treinamento visaram garantir um entendimento uniforme das t cnicas a serem aplicadas Validade de Conclus o N o foi poss vel obter um n mero maior de participantes para a execu o do estudo Com isso a validade de conclus o ficou de certa forma prejudicada principalmente pela n o utiliza o de testes estat sticos para o teste das hip teses do estudo Validade Extern
309. vados vl consumo receita realiz receita pend receita txServ e receita total IC 9 vi pendCli vl_pend Uma potencial falha da especifica o de requisitos que esta regra ajuda a detectar Informa o relativa a um estado anterior do sistema que possivelmente n o mais vigora com o mesmo valor no estado atual 77 vi nota e vl item IC 11 representem informa o hist rica eles podem ser restaurados a partir de outros itens anteriormente persistidos por exemplo v item no IC 11 pode ser restaurado a partir dos itens quant item e p item persistidos com base nas regras R3a e R3b respectivamente Uma vez decidida a persist ncia de um item regras R3a R3b e R3c o pr ximo passo alocar o item como atributo de uma das classes determinadas com a regra R1 Na modelagem com ICs do NIO a nica forma de estabelecer a liga o entre um item e o objeto do qual representa uma propriedade atributo incluir a identifica o do objeto na mesma interface informacional que cont m o item ou seja ambos devem participar da II do mesmo IC o que acontece por exemplo na interface informacional do IC 4 que inclui al m de dt pagto id pedido para identificar o pedido que est sendo pago A regra a seguir utiliza isso e o conceito de classes alcan adas por um identificador que inclui a a classe que ele identifica e b as classes de associa o nas quais ele participa como um dos identificadores se exist
310. vidas nas classes correspondentes s abstra es coincidentes entre pares de modelos A Tabela 6 17 d uma vis o geral desses resultados Dois resultados mostrados na tabela 6 17 devem ser destacados Um deles o acr scimo relativamente pequeno obtido na uniformidade de atributos para os MDs constru dos a partir dos ICs 5 Uma explica o para isso que v rios desses atributos aparecem explicitamente no sum rio do sistema Ap ndice 3 o que provavelmente facilitou a identifica o dos mesmos pelos participantes independentemente da t cnica utilizada Tabela 6 17 Compara o das m dias de uniformidade Uniformidade Uniformidade Representacional T cnica de abstra es Associa es Atributos Opera es Global Lua Hu Huai Huo Hur 0 6949 408 0 5313 95 ICs 0 6615 5 0 5291 61 0 3701 5 050762 43659 0 4680 478 2 0 1367 0 2731 0 1092 0 2640 UCs 0 4278 0 3286 0 3541 Legenda 1 Considerando opera es construtoras 2 N o considerando opera es construtoras O outro resultado a destacar na Tabela 6 17 o grande acr scimo na uniformidade de opera es obtido na modelagem com ICs 365 Algumas considera es podem ser feitas sobre esse resultado Em primeiro lugar o sum rio distribuido aos participantes muito menos expl cito com rela o a opera es do que com rel
311. vido a necessidade de se ter uma listagem lista item cobranca consulta Tipo C4 de todos os itens de cobran a existentes N o foi determinada nome String partir das regras Array lt Item cobranca gt classe Sistema financeiro Opera o Inclus o Opera o criada pela sua necessidade no IC6 Controlar lista parcelasRecebimento dt recebimentos no IC20 Gerar boletos e no IC21 Gerar notas 195 Identifica o do s elemento s envolvido s na Tipo de An lise manuten o manuten o MUC MD inicio Date dt fim Date fiscais N o foi determinada partir das regras boleto boolean nota Esta opera o seleciona as parcelas a serem listadas o que no boolean tipo _ rec String MUC refletido pela ocorr ncia de id_cliente no fluxo oCliente Cliente recebimentos al m de outros filtros per_apur tipo_rec no caso do aClasseItem Classe item IC6 Array lt Parcela recebimento gt classe Sistema financeiro Opera o Inclus o Opera o criada devido a necessidade de sua utiliza o no IC1 lista dispServicos cliente Tipo C4 Informar recebimentos IC27 Informar parcelas de valores Cliente estado String vari veis e tamb m para uma listagem das disponibiliza es de paga porOcor boolean servi os associadas a um cliente espec fico N o foi determinada dia vence int partir das regras Array lt Disp servicos gt classe Mesma an l
312. xas Array lt Caixa gt contasB Aray lt Conta_bancaria gt vid 2 ea ink TOR saldol_perCB dt_inic Date dt fim Date caixas Array lt Caixa gt contasB Array lt Conta_bancaria gt Currency previsao boolean a cs pera o Dal fm Oat Carney T area Para see lp Soto e Dala V Fe r Free Gong re roo o po Ra can 1 oeste Ca om oo Fomos tt des tg cost Dala voi pias rip ini e Ds Ma ia ie ppol ef Dto assay Cai fem roma Foner Cure T ene mevo Sia bi Eee e Dalo ecl Cs em efans Fomecoo Coy Teron Sg MSpace li Dat mt atm at Hm rena Famer Curerey Aro Currey T par pego in Date fin Cae alist Classe Mm rn Fonseca Crnoy Mimo L oi apaga o Dao acaselar Coe tom ofomec Forno Curar Tiler oureey L oia apegar Das elsenom Cane tom somes Fomecato Caney E pe tac bean Op araa ati to a sam Casas em ePomos Fomownde Gurenoy pn Pera L par araa Di ir Bd tm Das alssolom ase tom oFomes Foren Guns prq ri par apaga coreto Ba tlasetam ss tem onto Fanesdo Surrey a e ea senna Bt aust Cost tart our om Curry T a ca Par pesoea me Das fm Bt Cacao Cc om rem Freeda Cunene Troa SA ir TO con a id vot venc Data M Sr ia a Bi Ae Dala vaid pao Dt thn at ec coro Dm ad Renata ooo pi gerarNotas dt inic Date dt fim Date nr_nicNota int dt_corrente Date void mesAno indice String comissoes a ini Date dt fim Date oVend Profisional voce ct corrente Date void t

Info Cases: Um Modelo Integrado de Requisitos - Introdução

Contents

Download Pdf Manuals

Related Search

Related Contents

Info Cases: Um Modelo Integrado de Requisitos - Introdu&ccedil;&atilde;o

Contents

Download Pdf Manuals

Related Search

Related Contents

Info Cases: Um Modelo Integrado de Requisitos - Introdução