Home

uma abordagem baseada em modelos para especificação e

1. Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 8 Tela da UseCaseAgent com a lista de defeitos do caso de uso Pagar boleto banc rio 6 2 1 3 Gera o do Diagrama de Atividades Para gerar o diagrama de atividades correspondente especifica o do caso de uso basta salvar essa especifica o Antes de realizar a gera o propriamente dita o UseCaseAgent aciona a op o de verifica o do caso de uso Caso algum defeito seja detectado a opera o de gera o do diagrama cancelada e o desenvolvedor tem a oportunidade de analisar e eliminar os defeitos existentes Ou seja a gera o do diagrama s realizada caso a especifica o n o contenha nenhum defeito A Figura 6 9 mostra o diagrama de atividades gerado automaticamente a partir da especifica o do caso de uso de exemplo Pagar boleto banc rio somente a diagrama o do modelo foi realizada manualmente 143 UC001 Pagar boleto banc rio lt lt precondition gt lt lt postcondition gt gt informa que deve ser selecionada uma op o lt lt system response gt gt Al op o inv lida lt lt conceptual_rule gt gt BR2 obrigat rio que o boleto seja emitido pelo banco se a data de vencimento for menor que a data corrente lt lt conceptual_rule gt gt BR4 obrigat rio que o n mero do boleto esteja de acordo com a especifica o da se o 3 do documento de refer n
2. apresenta o comprovante de pagamento do boleto system response informa que os dados do pagamento sao invalidos system response dadosPagamentol data invalida or dadosPagamentol desconto invalido or et juros_invalidos or ol valor final invalido inv lida e WE enh invafda and errol 3 231 1 2 2 Test Case Steps 1 solicita a fonte de recurso de onde ser debitado o pagamento system lt no description gt response 2 seleciona uma das op es actor action lt no description gt 3 informa que deve ser selecionada uma op o system response lt no description gt 4 solicita a fonte de recurso de onde ser debitado o pagamento system lt no description gt response 5 seleciona uma das op es actor action lt no description gt 6 solicita o numero do boleto system response lt no description gt 7 solicita que o cliente fa a a leitura eletr nica do boleto system lt no description gt response 8 realiza a leitura eletr nica actor action lt no description gt 9 solicita os dados relativos ao pagamento system response lt no description gt 10 linforma os dados do pagamento actor action lt no description gt 11 solicita a senha system response lt no description gt 12 fornece a senha actor action lt no description gt 13 jinforma que a senha inv lida system response lt no descri
3. 110 Tabela 5 10 Tipos de a es para inclus o e extens o de casos de uUso 110 Tabela 5 11 Mapeamento entre as a es do caso de uso e os elementos do metamodelo UCModel cscctsacenzsncedrecal exis oc Sie C ar edencenE and res alcada Clnndo aEgsa dean ehatacareoelades 111 Tabela 5 12 Estere tipos usados na defini o das a es 113 Tabela 5 13 Restri es aplicadas ao caso de uso Autenticar usu rio da Figura 5 16 TA OO aa a dA Sand Nr Do E ae cae E 131 Tabela 6 1 Transforma o dos elementos do metamodelo UCModel para o metamodBIO DE eis cemtenneiiciwdeicduroe cnt go Eneas p EAEE EAE ca VEEE EECA PR a EEUE 153 xii Tabela 7 1 C lculo da complexidade dos casos de USO 165 Tabela 7 2 Conjuntos de casos de uso balanceados pelo n vel de complexidade 167 Tabela 7 3 Conjuntos de casos de uso atribu dos a cada participante por rodada 167 Tabela 7 4 Tempos reportados pelos participantes para especifica o dos casos de USO siege ictones ND aie heeds ofohacs eedeend ohh Gos avi A ask she Meine eee a ND 170 Tabela 7 5 Distribui o dos casos de uso pelos participantes do segundo estudo 174 Tabela 7 6 N mero de defeitos reportados por caso de uso e ferramenta 176 Tabela 7 7 Defeitos nos requisitos detectados pela ferramenta UseCaseAgent 178 xiii 1 Introdu o Neste cap tulo s o apresentados o contexto do traba
4. Na execu o desse estudo foram adotados modelos retirados dos m todos OOWS PASTOR et al 2001 e UWE KOCH amp KRAUS 2002 para representar as perspectivas de navega o e apresenta o A sele o desses modelo ocorreu pelos seguintes motivos e O Mapa de Atores e o Diagrama de Contexto Navegacional est o na nossa avalia o conceitualmente pr ximos dos Casos de Uso o que poderia facilitar a constru o daqueles modelos a partir destes e O Template de Apresenta o permite a representa o da interface de uma forma bastante abstrata focando apenas no tipo da informa o que ser veiculada em uma determinada rea Essa forma de representa o pode ser til caso a interface tenha baixa complexidade ou se deseje apenas delimitar essas reas deixando o detalhamento dos componentes da interface para fases posteriores e O Diagrama de Apresenta o do m todo UWE KOCH amp KRAUS 2002 permite a representa o da estrutura da interface em termos dos elementos 14 conceituais que a comp em Esse modelo pode ser usado como uma alternativa ao Template de Apresenta o do m todo OOWS Disponibilidade de material para treinamento o que facilitou tanto o entendimento dos pesquisadores quanto dos participantes do estudo Possibilidade de usar uma ferramenta UML para construir os diagramas Os modelos solicitados durante o processo de desenvolvimento foram Modelo Conceitual representa o dos elementos do dom
5. 189 Proceedings of the 21 ACM Symposium on Applied Computing v 2 pp 1232 1239 CACHERO C GOMEZ J PASTOR O 2001 Conceptual Modeling of Device Independent Web Applications IEEE Multimedia abr jun pp 26 39 CACHERO C KOCH N 2002 Navigation Analysis and Navigation Design in OO H and UWE Technical Report 0205 Institute of Computer Science Ludwig Maximilians University of Munich CACHERO C KOCH N GOMEZ J PASTOR O 2002 Conceptual Navigation Analysis a device and platform independent navigation specification Proceedings of 2nd International Worskhop on Web oriented Software Technology INWOST 02 CARVER J JACCHRI L MORASCA S SHULL F 2003 Issues in Using Students in Empirical Studies in Software Engineering Education Proceedings of 9 International Software Metrics Symposium pp 3 5 CASALANGUIDA H DURAN J E 2009 Aspect oriented navigation modeling for web applications based on UML IEEE Latin American Transactions v 7 n 1 pp 92 100 CASTRO de V MARCOS E CACERES P 2004 A User Service Oriented Method to model Web Information Systems Proceedings of the 5 International Conference on Web Information Systems Engineering WISE 04 pp 41 52 CERI S FRATERNALI P BONGIO A 2000 Web Modeling Language WebML a Modeling Language for Designing Web Sites WWW9 Conference Amsterdam CHEN P
6. Project Windows Tools Languages Miscellaneous Help c Guo nw E template 8 Je lt uc modeb gt use case model E Jccactors gt gt actors a use Use case view actors Fause New use case diagram E Ie lt use New sequence diagram scriptions oon New communication diagram E Je lt te mod New class diagram ectest New object diagram scriptions C Profieucm New use case _ ProfileTcm Use case view actor Figura A 2 Cria o de atores na ferramenta BOUML A 5 Cria o de um Caso de Uso Ap s a cria o do projeto com base no projeto Template conforme se o 3 basta acionar o menu de contexto no pacote lt lt uc model gt gt e selecionar Tool gt Create Use Case Figura A 3 204 r a Freeware Bouml C JOBSON Doutorado Projetos UCModel TestesUseCaseAgent template template pr acah Project Windows Tools Languages Miscellaneous Help FUSO MR E template E E Jecactors gt gt actors package use model Factors New package E Jecuse cases gt usec New use j Fause cases a Je lt use cases descri New class view gluse cases descrip New component view e lt domain modeb gt d New deployment view a este modeb gt testcaser New profile HTML documentation Jestest cases descriy project HTML doc flat JProfileucModel ae HTML doc svg HiPronieTCiodel HTML doc fiat svg Edit class settings Em gan Edit dr
7. SOHDM DFD Cen rios Lista de eventos RNA Linguagem natural HFPM Casos de uso Linguagem natural Gloss rio Esbo os da interface Prot tipo OOHDM Casos de uso Linguagem natural UIDs UWE Casos de uso Linguagem natural Diagrama de atividades Cen rio Gloss rio Prot tipo Revis o ad hoc MagicDRAW WebML Casos de uso Linguagem natural semi estruturada Diagrama de atividades Esbocos da interface WebRatio W2000 Casos de uso Linguagem natural DDDP Prot tipo UWA Casos de uso Linguagem natural Prot tipo NDT Casos de uso Linguagem natural semi estruturada Gabaritos Gloss rio BNL Prot tipo Revis es ad hoc NDT Tool 53 WebGen Casos de uso Linguagem natural AWDP Casos de uso Prot tipo ProcessManager Linguagem natural OOWS ConcurTaskTrees OOWS Suite Diagrama de atividades com nota o pr pria Gabarito de dados WebRE Casos de uso Linguagem natural semi estruturada Diagrama de atividades estereotipado Gabaritos HM Casos de uso Linguagem natural Modelos conceituais ADAMKO 2006 Caso de uso E o Linguagem natural Diagrama de atividades ADM Linguagem natural Prot tipo AriadneTool Diagrama de estrutura Especifica o de processos Cat logo de eventos WRM N o define um artefato Eclipse plug in especifico GARR
8. Equipe Desenv Dificuldades Diamante 4 Defini o do Modelo navegacional falta de uma vis o geral da aplica o confus o entre modelo OO e modelo ER trabalho distribu do e diagrama o dos modelos Zafira 3 Divis o do trabalho entre os membros causou confus o modelos navegacionais e controle da vers o dos modelos devido ao trabalho distribu do Rubi 4 Desenvolvimento separado dos Casos de uso pelos membros levou a dificuldades na hora de unir os modelos modelo conceitual n o foi bem compreendido falta de exemplos de modelos prontos e falta de reuni es presenciais Top zio 3 Confus o entre modelo conceitual e modelo ER e dificuldade para definir as classes A partir dos artefatos entregues foi poss vel extrair algumas medidas diretas apresentadas na Tabela 2 5 Tabela 2 5 Dados quantitativos do 2 estudo Equipe No de No No de No No de No participantes de classes atores contextos de UCs UCs conceituais navegacio prototipados nais Diamante 4 30 14 6 33 6 Zafira 3 36 15 8 21 3 Rubi 4 27 12 5 18 19 20 Top zio 3 33 13 5 77 15 Com rela o ao uso dos prot tipos da interface humano computador pudemos observar que a sua cria o durante o desenvolvimento foi mais bem assimilada pelas equipes do que os diagramas de apresenta o usados no primeiro estudo de observa o se o 3 1 Isso j er
9. 7 3 9 Valida o dos Dados Todos os oito participantes enviaram seus formul rios e nenhum relat rio de discrep ncias foi descartado Como n o havia um or culo que informasse os defeitos reais existentes nos artefatos todas as trinta e duas planilhas foram verificadas individualmente por dois pesquisadores e cada discrep ncia foi classificada como um defeito ou falso positivo individualmente Ap s essa etapa uma reuni o de consenso entre esses mesmos pesquisadores foi realizada para decidir se determinada discrep ncia era ou n o um defeito Nos casos em que a classifica o inicial dos pesquisadores era conflitante eles chegavam a um consenso argumentando contra ou a favor de determinada interpreta o acerca da discrep ncia relatada 7 3 10 Resultados A an lise estat stica apresentada nessa se o foi executada com a ferramenta JMP v 4 e a 0 05 A Tabela 5 6 resume o resultado geral das inspe es apresentando o n mero de defeitos reportados e a mediana dos defeitos por tipo de especifica o EDA ou UCA Pode se observar que houve um decr scimo de 22 8 no n mero de defeitos reportados nas especifica es produzidas com a ferramenta UCA em rela o aquelas produzidas com a ferramenta EDA o que sugere que os casos de uso especificados com UCA apresentam menos defeitos que os mesmos casos de uso especificados com EDA Entretanto o caso de uso 15 de alta complexidade apresentou um comportamento diferente dos
10. Tela inicial da ModelT para sele o dos casos de uso r E ModelT2 vers o 2 ax E Model Verifica o das Especifica es dos Casos de Uso UC001 cont m 1 erro s Corrija o s antes de gerar o Caso de Teste UC004 n o cont m erros Grupo de Engenharia de Software Experimental COPPE UFRJ ese cos ufrj br Figura 6 14 Segunda tela da ModelT que indica os casos de uso que est o aptos a terem A seus modelos de teste gerados Figura 6 15 apresenta o modelo de testes referente esse caso de uso gerado pela ferramenta ModelT2 Repare que 1 2 As a es do sistema foram eliminadas no modelo de testes enquanto as a es do ator e as respostas do sistema foram mantidas Os coment rios associados s a es reportam as regras relevantes nesse ponto de execu o do caso de uso Os coment rios associados s a es destacam as express es condicionais que precisam ser refatoradas para refletir os valores das classes de equival ncia Para o fluxo alternativo A2 que representa a escolha expl cita do ator pela op o cliente seleciona a op o de leitura eletr nica a ModelT2 cria automaticamente uma classe de equival ncia a2 com os valores sim e n o e substitui a express o cliente seleciona a op o de leitura eletr nica pela express o a2 sim Dessa forma o procedimento de testes gerado ao final vai percorrer o fluxo A2
11. ZS ZS lt lt metaclass gt gt ExecutableNode a Lo lt lt metaclass gt gt lt lt metaclass gt gt InitialNode ActivityFinalNode Action lt lt metaclass gt gt lt lt metaclass gt gt Constraint Metamodelo UCModel visao parcial Figura 5 4 Vis o parcial do metamodelo UCModel referente ao caso de uso e seus elementos b sicos 100 Representa o no Diagrama de Atividades Com base no mapeamento da Tabela 5 2 foram definidos estere tipos e tagged values para representar no diagrama de atividades o caso de uso e suas informa es b sicas Neste caso houve a necessidade de criar somente um estere tipo para estender a metaclasse Activity da UML na metaclasse UseCase do UCModel Tabela 5 3 Os atributos precondition e postcondition da metaclasse UseCase n o precisam ser representados como tagged values porque s o mapeados diretamente para os mesmos atributos na classe Activity da UML Tabela 5 3 Estere tipos usados na defini o do caso de uso e seus elementos b sicos Estere tipo Tipo base Defini o lt lt use case description gt gt Activity Indica que a atividade uma descri o de caso de uso Tagged values id N mero nico que identifica o caso de uso summary Breve descri o do objetivo do caso de uso actors Nomes dos atores separados por v rgula trigger Express o que indica o evento ou condi o que dispara
12. obrigat rio que o cliente tenha Calcular peso um desconto de 10 no valor do pedido seeletivermaisde i peso 1000 00 em compras nos gt Calcular valor Es valor pedido gt 500 00 ultimos 30 dias acumulado peso valor acumulado aca z Calcular frete valor pedido Nr lor_fret valor acumulado gt 1000 00 valor frete Aplicar desconto valor frete z cliente VIP valor_pedido Aplicar desconto VIP O y valor_frete valor_frete q Aplicar desconto destino e capital do sul sudeste capital e valor_pedido E frete E lt lt conceptual rule gt gt BR4E obrigat rio que o frete tenha lt lt conceptual rule gt Calcular valor total um desconto de 20 se o BRS obrigat rio que o destino da entrega for uma frete tenha um desconto e valor foal E capital do sul sudeste 50 se o cliente for vip y valor pedido valor frete H valor_total Ea Figura 4 8 Diagrama de atividades detalhando o comportamento da a o Calcular valor do pedido do caso de uso da Figura 4 7 Na Figura 4 8 poss vel observar as anota es indicando em quais pontos do diagrama de atividades as regras definidas no caso de uso s o tratadas Cabe ressaltar tamb m que atrav s do diagrama poss vel estabelecer de forma clara a ordem de aplica o das regras Esse mecanismo possibilita a especifica o dos comportamentos inerentes ao sistema em dois n veis de abstra o e No primeiro n vel n vel do caso
13. 2 4 5 Execu o As equipes tiveram quatro semanas para realizar a modelagem da aplica o proposta e ap s a entrega dos trabalhos os participantes foram convidados a responderem individualmente um question rio sobre as suas percep es acerca dos modelos utilizados O question rio final foi respondido por 23 dos 34 participantes e continha quatro quest es quantitativas e uma qualitativa sobre o uso dos modelos Para que as respostas do question rio pudessem ser analisadas de forma isenta a primeira pergunta procurou definir o n vel de participa o que cada integrante da equipe teve em rela o elabora o dos modelos A Tabela 2 6 sumariza esse n vel de participa o Tabela 2 6 Atua o dos desenvolvedores por modelo Tipo de Classe Sequ ncia Ea Atividade Ea Navega participa o o N o construiu nem 0 0 0 0 13 0 34 8 26 1 17 4 revisou 7 Para as demais quest es quantitativas as opini es dos participantes que n o tiveram nenhum contato com o modelo foram expurgadas das estat sticas ou seja os indiv duos que nem constru ram e nem revisaram o modelo tiveram a sua opini o removida da estat stica A segunda quest o procurou capturar o esfor o de constru o de cada modelo na percep o dos participantes As repostas poss veis nesse caso eram Alto M dio ou Baixo A Tabela 2 7 resume a percep o de esfor o dos participantes al m de destacar essa percep o para as tr s eq
14. A 13 Edi o de um Caso de Uso Para editar um caso de uso no BOUML basta acionar o menu de contexto sobre a atividade que especifica o caso de uso e acionar a op o Tool gt Edit Use Case conforme a Figura A 13 Freeware Bouml C JOBSON Doutorado Projetos UCModel TestesUseCaseAgent te bo Es Project Windows Tools Languages Miscellaneous Help SVO NR browser E template 8 C lt lt uc_moder gt use case model C lt lt actors gt gt actors Ic lt use cases gt gt use cases a c lt use cases descriptions gt gt use cases descriptions E Fguse cases descriptions ME lt lt use case description gt gt UC001 Autentica o do lt lt domain modet gt gt domain model activity UCO01 Autentica o do usu rio C lt lt tc_moder gt test case model Jestest cases descriptions gt gt test cases descriptions JProfileucmode JProfiletemode New interruptible activity region New expansion region New activity diagram New parameter New partition New activity action New object node Edit Duplicate Delete Referenced by Mark Force stereotype consistency HTML documentation HTML doc flat HTML doc svg HTML doc flat svg 4 activity UCOO1 Autentica o do usu rio 4 ee ET 214 Figura A 13 Ativa o do UseCaseAgent a partir do BOUML para edi o de um caso de uso As mesmas funcionalidades usadas na cria o de
15. Contextualizando o aprimoramento da qualidade e a especifica o de requisitos no cen rio contempor neo de desenvolvimento de aplica es Web duas sub quest es podem ser formuladas Seria poss vel Q1 apoiar a redu o de defeitos nas especifica es funcionais de aplica es Web e Q2 apoiar a redu o do esfor o necess rio para planejamento dos casos e procedimentos de testes funcionais atrav s de uma abordagem para an lise e especifica o desses requisitos alinhada aos conceitos explorados pelos m todos Web contempor neos em compara o a uma abordagem ad hoc 1 4 Objetivos O objetivo principal deste trabalho consiste em propor uma abordagem para especifica o estruturada de requisitos funcionais de aplica es Web conforme definido na quest o de pesquisa formulada na se o 1 3 Esse objetivo pode ser mais bem detalhado nos seguintes sub objetivos Estruturar um arcabou o para an lise classifica o e especifica o de requisitos funcionais alinhado aos conceitos explorados pelos m todos Web contempor neos oferecendo assim uma forma consistente para tratamento dos requisitos desde a fase inicial do projeto Explorar modelos conceituais para representa o das entidades relacionadas ao dom nio do problema do ponto de vista estrutural e comportamental Explorar modelos de casos de uso para especifica o do comportamento esperado do sistema do ponto de vista dos seus usu rios
16. aplica o utilizando as representa es propostas para cada uma das perspectivas A concord ncia em participar do estudo foi formalizada atrav s de um formul rio de consentimento e a caracteriza o dos participantes foi realizada atrav s de um formul rio preenchido pelos pr prios participantes que foi posteriormente analisado por tr s pesquisadores para classifica o final da experi ncia em desenvolvimento de cada participante escala ordinal com valores alta m dia ou baixa Os quinze participantes foram organizados em cinco equipes de tr s desenvolvedores de forma que todas as equipes tivessem aproximadamente um n vel equivalente de experi ncia Nesse estudo as equipes deveriam realizar as atividades e entregar os artefatos conforme descrito na Tabela 2 1 Tabela 2 1 Atividades e artefatos do 1 estudo de observa o Atividade Artefatos gerados Especifica o de requisitos e Documento contendo o escopo da aplica o o gloss rio de termos e a lista de requisitos funcionais n o funcionais e de dados Especifica o de Casos de e Documento contendo a lista de Atores e a Uso descri o de cada Caso de Uso Modelagem das Perspectivas Modelo Conceitual e Modelo de Navega o Mapa de Atores Diagrama de Contexto Navegacional e Diagrama de Navega o e Modelo de Apresenta o Templates de Apresenta o e Diagrama de Apresenta o Projeto detalhado e Modelos de Classes detalhado
17. o O comportamento descrito nesse exemplo pode ser representado sob a tica do ciclo de vida da entidade tratada solicita o de movimenta o nesse caso e dos eventos que a afetam Figura 4 4 ou sob a tica das atividades e respectivos respons veis pelo processo Figura 4 5 A Figura 4 4 apresenta uma m quina de estado onde os poss veis estados da entidade s o definidos e as transi es representam os eventos e as condi es necess rias para que haja uma mudan a de estado Por outro lado a Figura 4 5 apresenta as atividades do processo modelado com os respectivos respons veis e as informa es que fluem por essas atividades com seus respectivos estados destacados em cinza Note que os processos e eventos capturados nesse momento podem transcender os limites de um caso de uso ou seja n o existe necessariamente uma rela o direta entre um processo descrito nesse n vel de abstra o e um caso de uso 69 Solicita o de Movimenta o lt lt machine gt gt apreciar solicita o aprovado encerrar processo Figura 4 4 M quina de estado representando o ciclo de vida da entidade Solicita o de Movimenta o 70 Administrar solicita o de movimenta o Fluxo de dados entidade e estado estados terminais atingidos nesse processo 1 solicita o indeferiu indeferida solicita o i aprecia o a solicita o reprovou reprovada es A F
18. o Ao longo dos anos v rios trabalhos t m tentado demonstrar que requisitos inadequados inconsistentes ou amb guos t m um impacto negativo na qualidade do software e que a ado o dos processos previstos na Engenharia de Requisitos SAWYER e KOTONYA 2004 SOMMERVILLE 2006 pode reduzir significativamente esses impactos BOEHM e BASILI 2001 Nesse contexto um estudo experimental recente realizado por HAN e HUANG 2007 observou seis dimens es de risco usu rios requisitos complexidade do projeto planejamento e controle equipe ambiente organizacional em 115 projetos de software e concluiu que a dimens o requisitos foi a que mais afetou o desempenho geral dos projetos analisados Uma das formas de minimizar defeitos em requisitos a aplica o de t cnicas est ticas de avalia o Dentre essas as t cnicas de inspe o t m se mostrado um importante meio para aprimorar a qualidade do software FAGAN 1976 ACKERMAN et al 1989 pois ap iam a identifica o de defeitos tao logo eles tenham sido introduzidos reduzindo o retrabalho em fases subsequentes do desenvolvimento e falhas no produto final TRAVASSOS et al 1999 Por outro lado o teste de software tem por objetivo identificar defeitos presentes em determinado produto atrav s da sua an lise din mica ou seja atrav s da sua execu o Essa execu o tem como meta revelar falhas no produto permitindo assim que as devidas corre es tornem o produ
19. um sistema de software baseado em tecnologias e padr es do World Wide Web Consortium W3C que prov recursos espec ficos da Web como conte do e servi os atrav s de um cliente Web Essa defini o pode ser complementada ressaltando que o foco deste trabalho est nas aplica es Web que representam sistemas de software complexos orientados a processos ou a dados e que integram a explora o n o linear da informa o com a capacidade de execu o de processos de forma distribu da importante notar que de acordo com essa defini o p ginas HTML est ticas n o s o consideradas aplica es Web Aplica es Web se diferenciam de aplica es convencionais por uma s rie de caracter sticas que est o relacionadas com a pr pria aplica o seu uso sua evolu o ou seu processo de desenvolvimento SCHWINGER e KOCH 2006 e Integra o de diferentes meios para apresenta o das informa es textos gr ficos udio v deo dentre outros e Caracter sticas ligadas seguran a e privacidade demandam maior aten o dos desenvolvedores e Explora o do espa o da informa o de forma n o linear O termo software ou aplica o convencional ser usado neste trabalho como sin nimo de software ou aplica o nao Web e Aten o especial quanto usabilidade e acessibilidade pois s o normalmente projetadas visando atingir um p blico bem maior com expectativas habilidades e limita es difer
20. Formalizar um arcabou o para especifica o de casos de uso composto por um conjunto de defini es crit rios e restri es e oferecer a partir dele uma estrutura sint tica e sem ntica capaz de apoiar a garantia da qualidade da especifica o e do produto final Definir uma infra estrutura computacional que ap ie a especifica o e verifica o dos casos de uso e Definir uma infra estrutura computacional que ap ie o planejamento dos casos e procedimentos de testes funcionais a partir da explora o dos modelos de casos de uso Essa tese apresenta a abordagem proposta e as ferramentas de apoio criadas para viabilizar o seu uso bem como discute os resultados obtidos a partir das avalia es e as limita es observadas A metodologia de trabalho baseada em evid ncias SHULL et al 2001 MAFRA et al 2006 SP NOLA et al 2008 adotada nesta pesquisa apoiou tanto a concep o quanto as avalia es da abordagem proposta atrav s de um estudo secund rio que n o foi conduzido no escopo deste trabalho tr s estudos de observa o e dois estudos de caracteriza o em busca de indicadores que mostrassem a viabilidade do seu uso 1 5 Metodologia de Trabalho A abordagem proposta neste trabalho teve sua constru o e avalia o de viabilidade apoiada por experimenta o atrav s da ado o dos conceitos preconizados por metodologias baseadas em evid ncias para desenvolvimento e introdu o de tecnologias de so
21. OP Instituto Alberto Luiz Coimbra de J F RJ P s Gradua o e Pesquisa de Engenharia UMA ABORDAGEM PARA ESPECIFICA O DE REQUISITOS DIRIGIDA POR MODELOS INTEGRADA AO CONTROLE DA QUALIDADE DE APLICA ES WEB Jobson Luiz Massollar da Silva 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 Guilherme Horta Travassos Rio de Janeiro Abril de 2011 UMA ABORDAGEM PARA ESPECIFICA O DE REQUISITOS DIRIGIDA POR MODELOS INTEGRADA AO CONTROLE DA QUALIDADE DE APLICA ES WEB Jobson Luiz Massollar da Silva 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 Examinada por Prof Guilherme Horta Travassos D Sc Prof Toacy Cavalcante de Oliveira D Sc Prof Geraldo Bonorino Xex o D Sc Prof Maria Emilia Xavier Mendes D Sc Prof S rgio Castelo Branco Soares D Sc RIO DE JANEIRO RJ BRASIL ABRIL DE 2011 Silva Jobson Luiz Massollar da Uma Abordagem para Especifica o de Requisitos Dirigida por Modelos Integrada ao Controle
22. Quality and understanding of use case models In Lindskov Knudsen J ed 15th European Conference on Object Oriented Programming LNCS Springer Verlag pp 402 428 APFELBAUM L DOYLE J 1997 Model Based Testing Software Quality Week Conference QWE Bruxelas B lgica ARLOW J NEUSTADT I 2005 UML 2 and the Unified Process Practical Object Oriented Analysis and Design Addison Wesley 2 edi o ARMOUR F MILLER G 2001 Advanced Use Case Modeling Addison Wesley BARESI L GARZOTTO F PAOLINI P 2001 Extending UML for Modelling Web Applications Proceedings of the 34 Annual Hawaii International Conference on System Science BARESI L GARZOTTO F MARITATI M 2002 W2000 as a MOF Metamodel Proceedings of the 2002 World Multiconference on Systemics Cybernetics and Informatics volume I 188 BARESI L MAINETTI L 2006 W2000 meets J2ME for the fast prototyping of mobile web applications Proceedings of 24th IASTED International Multi Conference on APPLIED INFORMATICS pp 59 64 BASILI V ROMBACH H 1998 The TAME Project Towards Improvement Oriented Software Environments IEEE Transactions on Software Engineering n 14 BELGAMO A FABBRI S 2004 GUCCRA Contribuindo para a Identifica o de Defeitos em Documentos de Requisitos Durante a Constru o de Modelos de Casos de Uso Proceedings of the VIl Workshop on Requir
23. ROBERTSON J C 2006 Mastering the Requirements Process Addison Wesley 2 edi o ROBERTSON J ROBERTSON S 2010 Volere Requirements Specification Template 15 edi o http www volere co uk templates htm ROSENBERG D STEPHENS M 2007 Use Case Driven Object Modeling with UML Theory and Practice Apress RUI K BUTLER G 2003 Refactoring Use Case Models The Metamodel Proceedings of 26 Australasian Computer Science Conference pp 484 491 SANTOS P S M TRAVASSOS G H 2010 Inspe o de Qualidade em Descri es de Casos de Uso uma Avalia o Experimental em um Projeto Real Anais do IX Simp sio Brasileiro de Qualidade de Software pp 261 275 Bel m Brasil SAWYER P KOTONYA G 2004 Software Requirements IEEE Software Engineering Body of Knowledge SWEBok cap tulo 2 SCHNEIDER G WINTERS J P 2001 Applying Use Cases A Practical Guide Addison Wesley 2 edi o SCHWABE D ROSSI G BARBOSA S 1996 Systematic Hypermedia Application Design with OOHDM Proceedings of 7 ACM International Conference on Hypertext SCHWINGER W KOCH N 2006 Modeling Web Applications In Kappel G Pr ll B Reich S Retschitzegger W eds Web Engineering The Discipline of Systematic Development of Web Applications John Wiley amp Sons ISBN 978 0470015544 198 SHULL F CARVER J TRAVASSOS G 20
24. es que pode ser reusado entre v rios projetos Apesar dos autores declararem que o WRM destinado modelagem de requisitos de sistema de informa o Web esse arcabou o pode ser utilizado para modelagem e gerenciamento de aplica es de software em geral validatedBy obtainedFro obtainedF rom collects validatedT hrough Figura 3 1 Metamodelo de requisitos do WRM 49 3 2 3 20 Abordagem para An lise de Requisitos com i A abordagem apresentada por GARRIGOS et al 2009 e AGUILAR et al 2010 voltada para a an lise de requisitos de aplica es Web a partir de uma vers o estendida do framework i YU 1997 O i uma linguagem de modelagem voltada para as fases iniciais do entendimento do dom nio do problema Ele usa o modelo de depend ncia estrat gica SD Strategic Dependency para descrever a depend ncia entre os v rios atores do contexto organizacional e o modelo de racioc nio estrat gico SR Strategic Rationale para capturar para cada ator o seu objetivo Goal as tarefas Task para atingir esse objetivo os recursos Resource necess rios e os objetivos secund rios Softgoals Para adequar o framework i modelagem de requisitos Web foram acrescentados novos conceitos para representar os requisitos de conte do conceitos do dom nio servi o funcionalidades do sistema navega o apresenta o e personaliza o Assim o conceito de Task foi estendido para Service Navi
25. lista dos m todos Web a serem analisados os 10 m todos estudados por ESCALONA e KOCH 2004 O objetivo desse arranjo obter uma vis o mais atualizada sobre o tratamento dos requisitos nos m todos Web e ao mesmo tempo complementar essa an lise com a avalia o de m todos anteriores ao ano de 2004 e que se demonstravam mais relevantes quela poca segundo a vis o de ESCALONA e KOCH 2004 Nesse cen rio vale ressaltar que aqueles m todos analisados por ESCALONA e KOCH 2004 que continuaram evoluindo ao longo dos ltimos 7 anos poderiam ser selecionados nessa revis o e caso isso acontecesse seriam re analisados luz dessa evolu o 3 2 Revis o da Literatura sobre M todos de Desenvolvimento de Aplica es Web As se es a seguir definem o protocolo adotado na revis o da literatura os dados da execu o da revis o e os resultados obtidos com a an lise dos estudos selecionados nessa revis o 3 2 1 Protocolo da Revis o 3 2 1 1 Quest o de Pesquisa O contexto de aplica o dessa revis o refere se aos m todos de desenvolvimento que tratam requisitos de aplica es Web 35 e Quest o quais m todos de desenvolvimento que tratam requisitos de aplica es Web t m sido propostos na literatura t cnica e Popula o projetos de desenvolvimento Web e Interven o m todos de desenvolvimento Web que tratam requisitos de aplica es Web e Resultado m todos de desenvolvimento Web 3 2 1 2 Es
26. o da abordagem onde foram conduzidos tr s estudos de observa o que forneceram indica es sobre o foco a ser adotado na abordagem at a sua avalia o onde foram realizados dois estudos envolvendo a abordagem proposta o metamodelo UCModel e a ferramenta UseCaseAgent Nesse sentido as se es a seguir apresentam respectivamente as contribui es desta pesquisa suas limita es e quest es em aberto e as possibilidades de trabalhos futuros 8 2 Contribui es da Pesquisa As contribui es consequentes do desenvolvimento desta pesquisa s o 183 e Defini o de uma abordagem para an lise classifica o e especifica o de requisitos funcionais alinhada aos conceitos explorados pelos m todos Web contempor neos e estruturada visando prover um arcabou o para a garantia da qualidade da especifica o e do produto final e envolvendo O Elabora o de um conjunto de diretrizes para tratamento das regras de neg cio dom nio de forma consistente e integrada com a perspectiva de tratamento dos requisitos visando destacar os elementos da especifica o impactados por essas regras Estrutura o do metamodelo UCModel que permite a organiza o das especifica es de casos de uso segundo um conjunto de crit rios e restri es bem definido e oferece a estrutura o sint tica e sem ntica a partir do qual poss vel tratar quest es relacionadas a garantia da qualidade Elabora o a partir da repres
27. o da estrutura de pacotes na ferramenta BOUML que ap ia a especifica o do caso de uso A 2 Por que BOUML A escolha do BOUML como ferramenta base para o desenvolvimento do UseCaseAgent se deve aos seguintes fatores Open source Roda em diversas plataformas Windows Linux e Mac OS Implementa praticamente toda a defini o da UML 2 Permite a defini o e uso de perfis UML e Permite a cria o de plug ins em C ou Java para estender as suas funcionalidades A 3 Instala o e Configura o Para instala o do UseCaseAgent s o distribu dos 2 arquivos Plugout zip Template zip A configura o do ambiente deve ser feita em 3 passos 1 2 3 Instala o do BOUML fa a o download da ferramenta em http bouml free fr Descompacta o do plug in o arquivo plugout zip deve ser descompactado no mesmo diret rio onde foi instalado o BOUML Descompacta o do projeto Template zip descompacte o arquivo template zip em um diret rio qualquer Depois desses passos para cada projeto que desejamos utilizar o UseCaseAgent devemos configurar o acesso do BOUML ao plug in e aos perfis UML necess rios Infelizmente essas duas tarefas devem ser feita para cada projeto porque o BOUML n o leva essa configura o de um projeto para o outro Visando facilitar a utiliza o do UseCaseAgent distribu do juntamente com o plug in um projeto BOUML chamado Template que j possui t
28. o destas e o seu consequente desdobramento de acordo com as perspectivas de projeto que elas impactam Por fim a abordagem aqui proposta prev que as regras de neg cio dom nio estejam diretamente associadas aos casos de uso descritos no documento de especifica o ou seja a descri o dos casos de uso deve fazer refer ncia direta s regras porque elas impactam no comportamento descrito no caso de uso sendo portanto decisivas para definir e especificar de forma precisa o comportamento esperado para o mesmo 4 5 3 Modelo de Casos de Uso 4 5 3 1 Casos de Uso Requisitos funcionais podem ser especificados em diferentes n veis de detalhamento e formaliza o usando abordagens que variam desde descri es em linguagem natural at especifica es formais ESCALONA e KOCH 2004 A natureza interativa da grande maioria das aplica es Web favorece o uso de t cnicas baseadas em cen rios tal como casos de uso JACOBSON 1992 para especifica o dos aspectos comportamentais dessas aplica es Al m dos casos de uso representarem uma das abordagens mais usadas pela ind stria de software a ampla dissemina o de conhecimento acerca dessa t cnica a torna uma candidata natural para compor uma abordagem para especifica o de requisitos de aplica es Web Casos de uso foram originalmente desenvolvidos por Ivar Jacobson como parte do Objectory um processo de desenvolvimento de software orientado a objetos JACOBSON 1992 Desd
29. o do Caso de Uso Para criar o caso de uso basta selecionar o pacote raiz estereotipado lt lt uc model gt gt e em seguida selecionar a op o Tools gt Create Use Case O UseCaseAgent ser executado e ser apresentada a tela da Figura 6 3 para entrada das informa es b sicas sobre o caso de uso Ao clicar nos itens do painel a esquerda da tela poss vel navegar pelos atores do caso de uso fluxo principal fluxos alternativos e de exce o regras que devem ser observadas e erros de verifica o do caso de uso Nessa tela destacam se tamb m as op es de salvar o caso de uso isto gerar o diagrama de atividades a partir da descri o e verificar o caso de uso 139 A Use Case Agent vers o 0 39 Erim Arquivo Verificar Hye UCModel Atores Caso de Uso 1 E B Casos de Uso Nome Pagar boleto banc rio Descri o Nesse caso de uso o diente paga o boleto banc rio emitido pelo pr prio banco ou por terceiros Criticalidade Alta Frequencia Alta Cliente aciona a op o de pagamento de boleto Trigger Pr condi o Cliente dever estar aut nticado no sistema de home banking Cliente obt m o comprovante de pagamento do boleto Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 3 Tela inicial da UseCaseAgent com os elementos b sicos do caso de uso A Fi
30. o propostos possam estar integrados O uso de prot tipos a t cnica mais recorrente para valida o dos requisitos Entretanto a maior parte desses prot tipos representa apenas a vis o estrutural relacionada navega o e apresenta o negligenciando o comportamento relacionado s funcionalidades da aplica o O apoio do diagrama de atividades da UML OMG 2010a descri o de casos de uso sem o uso de recursos adicionais n o traz nenhum valor agregado ao entendimento do problema pois n o acrescenta nenhuma sem ntica a mais nessas descri es al m daquelas que j existem quando usado o formato textual Parece haver uma cobertura inconsistente das atividades e t cnicas propostas pelos m todos Web pelas ferramentas concebidas para apoiar essas atividades e t cnicas Isso parece ser contraproducente j que grande parte desses m todos exploram modelos e transforma es entre esses artefatos que parecem n o fazer sentido sem o apoio ferramental adequado Nesse contexto a pr pria avalia o desses m todos seja com um estudo de caso ou com um estudo controlado s parece fazer sentido se o apoio ferramental adequado fizer parte do pacote onde o m todo est inclu do e A falta de apoio aos testes de sistema dentro da filosofia do modelo V tamb m pode ser observada Esse cen rio indica que os m todos Web n o tem se preocupado em definir uma pol tica integrada para garantia da qualidade do produto final
31. or self caller gt size self caller gt select incoming source oclIsType0Of SystemResponse gt size inv self caller gt asSequence gt first incoming source oclIsType0Of ActorAction implies self actions gt asSequence gt first oclIsTypeoOf SystemAction inv self caller gt asSequence gt first incoming source oclIsType0Of SystemAction implies self actions gt asSequence gt first oclIsType0Of SystemResponse or self actions gt asSequence gt first oclIsType0Of FinishAction inv self caller gt asSequence gt first incoming source oclisTypeOf SystemResponse implies self actions gt asSequence 119 gt first ocliIsTypeoOf or J SystemResponse self actions gt asSequenc gt first oclIsType0Of QE TE SystemAction self actions gt asSequenc gt first oclIsType0Of 5 3 6 5 Metaclasse ExceptionFlow Condi o de guarda obrigat ria N Deve ter pelo menos uma a o AA O disparado por a es do mesmo tipo FinishAction Deve ser referenciado por pelo menos uma a o do UseCase Deve estar sempre associado a a es do mesmo tipo ou seja sempre Se for disparado por uma SystemAction ent o sua primeira a o tem que ser uma SystemResponse ou outra SystemAction Se for disparado por uma SystemR
32. preciso ressaltar ainda que mesmo com o uso de prot tipos as regras comportamentais ainda devem ser especificadas usando linguagem natural estruturada pois mesmo que os prot tipos simulem a din mica dessas regras estas devem ficar explicitamente especificadas a fim se serem consideradas nas fases posteriores do projeto Por fim as regras relacionadas perspectiva de navega o sejam elas estruturais ou comportamentais tamb m devem estar associadas casos de uso pois elas definem quais informa es estar o dispon veis durante a intera o ator sistema Os detalhes dessa associa o ser o apresentados na se o 4 5 3 2 77 4 5 2 3 Regras x Perspectiva de Apresenta o Regras associadas perspectiva de apresenta o definem como as informa es disponibilizadas ser o apresentadas e poss veis restri es sobre essa apresenta o A Tabela 4 9 exemplifica a aplica o dos princ pios da SBVR para especifica o de regras na perspectiva de apresenta o Tabela 4 9 Exemplo de especifica o de regras de apresenta o segundo a SBVR Termos CPF data de nascimento formato de data usu rio prefer ncias Tipos de fatos usu rio tem prefer ncias prefer ncias define formato de data CPF pode ter formato Regras R1 O CPF deve ser apresentado no formato 999 999 999 99 estruturais Regras R2 obrigat rio que a data de nascimento seja apresentada comportamentais no formato de dat
33. ucmodel lt lt metaclass gt gt E lt lt profile gt gt lt lt metaclass gt gt UML Action ee UML Activity lt lt stereotype gt gt basic_action lt lt stereotype gt gt use_case_description i D lt lt stereotype gt gt action frequencyofuse lt lt stereotype gt gt lt lt stereotype gt gt 5 lt lt metaclass gt gt i execute_uc_action behavior_action UML Constraint o EEE Lo Do ZS EEE ZS lt lt stereotype gt gt lt lt stereotype gt gt lt lt stereotype gt gt lt lt stereotype gt lt lt stereotype gt lt lt stereotype gt gt lt lt stereotype gt gt lt lt stereotype gt gt actor action system response system action include action extend_action navigation rule conceptual rule presentation rule actor E Figura 5 15 Estere tipos e tagged values para defini o de diagramas de atividades segundo o UCModel 125 5 4 Orienta es para Especifica o de Casos de Uso no UCModel A defini o sem ntica das a es que comp em a especifica o do caso de uso torna poss vel al m da valida o da estrutura da descri o do caso de uso valida o sint tica a defini o de um conjunto de orienta es voltadas para a reda o da descri o das a es que o comp em A organiza o dos itens tamb m incluiu algumas orienta es gerais presentes na literatura t cnica COX et al 2001 ROSENBERG e STEPHEN
34. 126 5 4 1 Orienta es Gerais acres cases none sais idaaai ns engine dias do aan dp SE qaea nadas 126 5 4 2 Orienta es relacionadas A o do Ator 126 5 4 3 Orienta es relacionadas A o do sistema 127 5 4 4 Orienta es relacionadas Resposta do Sistema 127 5 5 Exemplo de Caso de Uso especificado com o UCModel 128 5 6 CONG SA E E EEE E E E E E 132 6 Infra estrutura de Apoio Especifica o de Casos de Uso e Garantia da QUAI AG Sch cos codes cers dra Ro DT Cp a E 134 6 1 laji sis 9 er Va PRA RD E PRN DRA CR PD RR PCE ee RS 134 6 2 Ferramenta USeCaseAgent ccccccceeeeeeeseecceeeeeeeeeeeneeeaeaeeeeeeeeteeeesaaaes 136 6 2 1 Cen rios de uso da UseCaseAgent 139 6 2 2 Trabalhos Relacionados sicaciccctci teks hetince cient noche dee 149 6 3 J PetramemlaciWWodel lcngtanceeccrhat cite talt sa Saat oat td 151 6 4 CONCLUSO inia a A cud etendradetend cudecend eadeecus caletexdsadeteud tabacendsaamenus E 161 7 Avalia o Experimental sines san E E E 162 7 1 INOdU O ee R E AA EE R e 162 7 2 Primeiro ESTUDO ercstordecasiaduntaideandevtscuuvens tesa coasenvaueatacnd oes ccutensdeensOsuecsauees 164 RE OBIONVO fet est dt tet ent eee eee tate treo ea ct eee R 164 7 2 2 Sele o do Contexto asc isenta as do eaceiahgecey do aeie lacie gacticiueneienactseg 164 7 2 3 Sele o de Vari veis na ciweknaiwadenaieAneeaied 166 T24 Parti
35. 1976 The Entity Relationship Model Toward a Unified View of Data ACM Transaction on Database Systems v 1 n 1 pp 9 36 COCKBURN A 2000 Writing Effective Use Cases Addison Wesley CONALLEN J 2002 Building Web Applications with UML Addison Wesley ISBN 0 201 73038 3 2 edi o CONSTANTINE L YOURDON E 1979 Structured Design Prentice Hall 1979 CONTE T MENDES E TRAVASSOS G H 2005 Processos de Desenvolvimento para Aplica es Web Uma Revis o Sistem tica Anais do XI Simp sio Brasileiro de Sistema Multim dia e Web WebMedia 05 pp 107 116 190 COX K AURUM A JEFFERY R 2004 An Experiment in Inspecting the Quality of Use Case Descriptions Proceedings of 7 International Conference on Requirements Engineering Foundation for Software Quality v 36 n 4 pp 211 229 COX K PHALP K SHEPPERD M 2001 Comparing Use Case Writing Guidelines Journal of Research and Practice in Information Technology pp 101 112 DA CRUZ A M R FARIA J P 2010 A Metamodel based Approach for Automatic User Interface Generation LNCS v 6394 pp 256 270 DE SILVA B GINIGE A BAJAJ S EKANAYAKE A SHIRODKAR R SANTA M 2009 A tool to support end user development of web applications based on a use case model LNCS v 5684 pp 527 530 DE TROYER O LEUNE C 1997 WSDM A User Centered Design Method for We
36. 47 56 URBIETA M ROSSI G GINZBURG J SCHWABE D 2007 Designing the interface of rich internet applications Proceedings of the 2007 Latin American Web Conference LA WEB 07 pp 144 153 VALDERAS P FONS J PELECHANO V 2005 Transforming web requirements into navigational models AN MDA based approach LNCS v 3716 pp 320 336 VALDERAS P PELECHANO V PASTOR O 2007 A transformational approach to produce web application prototypes from a web requirements model International Journal of Web Engineering and Technology v 3 n 1 pp 4 42 VILAIN P SCHWABE D SIECKENIUS C 2000 A diagrammatic Tool for Representing User Interaction in UML Proceeding of UML 2000 LNCS v 1939 pp 133 147 199 WAN KADIR W M N LOUCOPOULOS P 2004 Relating evolving business rules to software design Journal of System Architecture n 50 pp 367 382 WANG W GENG G ZHOU M 2010 A Rule Repository Model for Rule Driven Question Answer Based Web Applications Proceedings of 2010 International Conference on Artificial Intelligence and Computational Intelligence AICI 10 pp 17 22 WANG H LI J WANG Q YANG Y 2010 Quantitative Analysis of Requirements Evolution across Multiple Versions of an Industrial Software Product Proceedings of 17 Asia Pacific Software Engineering Conference pp 43 49 WOOKJIN L SANGHYUN P KEEYOULL L CHU
37. Positive values show pairs of means that are significantly different Figura 7 3 Boxplots relativos aos defeitos reportados nas especifica es de caso de uso constru das com as ferramentas EDA e UCA tela da ferramenta JMP v 4 Uma quest o crucial que emerge nesse contexto os defeitos detectados nos diagramas foram introduzidos durante o processo de cria o destes no primeiro estudo com o uso da ferramenta EDA ou a ferramenta UCA ajudou os desenvolvedores a remover os defeitos previamente existentes na especifica o original de requisitos usada como base para cria o dos diagramas importante relembrar que na an lise qualitativa do primeiro estudo ambos os desenvolvedores informaram que UCA apoiou a remo o de defeitos mas somente essa informa o n o suficiente para responder tal quest o Uma investiga o adicional foi realizada 177 para tentar compreender quais defeitos a ferramenta UCA de fato ajudou a remover e quais defeitos foram introduzidos com o uso da ferramenta EDA Para listar os defeitos existentes nos diagramas constru dos com EDA os pesquisadores usaram a pr pria ferramenta UseCaseAgent para editar tais diagramas mais precisamente os diagramas da primeira rodada do primeiro estudo Vale a pena relembrar que os diagramas da segunda rodada do primeiro estudo j haviam sido constru dos com a ferramenta UseCaseAgent logo os defeitos existentes na especifica o original do m dulo finance
38. a fim de mitigar efeitos colaterais relacionados ao n vel de experi ncia do inspetor o mesmo caso de uso foi inspecionado por participantes com diferentes habilidades Com esse arranjo cada caso de uso foi inspecionado oito vezes por diferentes participantes com diferentes n veis de experi ncia 173 Tabela 7 5 Distribui o dos casos de uso pelos participantes do segundo estudo Participante N vel de Casos de uso especificados com experi ncia EDA UCA Alto 15 06 40 36 P2 Alto 06 15 36 40 P3 M dio Alto 36 06 40 15 P4 M dio Alto 06 36 15 40 P5 M dio Baixo 36 40 06 15 P6 M dio Baixo 40 36 15 06 P7 Baixo 15 40 06 36 P8 Baixo 40 15 36 06 7 3 6 Instrumenta o Os instrumentos preparados e usados para apoiar o estudo foram 1 2 N OD CO ce Formul rio de consentimento Formul rio de caracteriza o Planilha eletr nica para relato das discrep ncias e do tempo de dura o da inspe o Material de treinamento sobre categoriza o de defeitos Material de treinamento sobre diagramas de atividades da UML 2 Material de treinamento sobre o metamodelo UCModel e Material de treinamento sobre a ferramenta BOUML mais especificamente sobre o editor de diagramas de atividades Os materiais 5 6 e 7 foram os mesmos utilizados no primeiro estudo se o 7 2 7 3 7 Prepara o Ao longo do curso de VV amp T todos os participantes tive
39. atrav s do apoio ao planejamento gera o de testes de sistema 3 5 Conclus o Este cap tulo teve como objetivo descrever os resultados de uma revis o da literatura t cnica com o prop sito de caracterizar os m todos de desenvolvimento que tratam requisitos de aplica es Web A an lise desses m todos forneceu ind cios da exist ncia de diversas reas de oportunidades de pesquisa relacionadas a esse tema Entretanto vale lembrar que essa an lise foi sendo constru da ao longo dos ltimos 55 anos Logo ap s a publica o dos resultados de um estudo secund rio para caracteriza o de m todos de desenvolvimento Web CONTE et al 2005 surgiu a necessidade de observar e compreender de forma mais elaborada algumas quest es relacionadas ao uso dos m todos Web e a explora o e representa o das perspectivas de projeto em cen rios de desenvolvimento especialmente as dificuldades e a relev ncia percebidas pelos desenvolvedores ainda precisavam ser observadas Para tal foram realizados tr s estudos preliminares elabora o da abordagem proposta estudos de observa o que s o descritos em detalhes no pr ximo cap tulo 56 4 Abordagem para Especifica o de Requisitos Neste cap tulo uma vis o geral da abordagem proposta e seu escopo de atua o s o apresentados juntamente com o processo previsto para especifica o dos requisitos e os diversos elementos que visam representar a especific
40. descri o dos casos de uso atrav s de um arcabou o com estrutura sint tica e sem ntica bem definidas O Cap tulo 6 apresenta a infra estrutura computacional organizada com o prop sito de apoiar a abordagem de especifica o e garantia da qualidade proposta nesta tese al m de detalhar as ferramentas UseCaseAgent e ModelT que comp em essa infra estrutura No Cap tulo 7 s o apresentados dois estudos que foram planejados e conduzidos com o objetivo de avaliar a abordagem proposta neste trabalho juntamente com o metamodelo UCModel e a ferramenta UseCaseAgent que ap ia a atividade de especifica o 92 5 Metamodelo para Especifica o de Casos de Uso Neste cap tulo apresentado o metamodelo UC Model criado com o objetivo de apoiar a descri o de casos de uso segundo um conjunto de crit rios e restri es bem definido e que comp e a abordagem proposta nesta tese S o apresentados os princ pios que nortearam a cria o desse metamodelo os elementos e as restri es que o comp em e os desdobramentos do seu uso em rela o ao controle de qualidade da especifica o 5 1 Introdu o A organiza o e ado o de um gabarito para descri o dos casos de uso representa o primeiro passo no sentido de padronizar essas descri es pois ele oferece uma estrutura a partir da qual poss vel capturar um conjunto de caracter sticas relevantes do caso de uso sob determinada perspectiva Essa padroniza o ofe
41. equipe poderia abdicar do uso de qualquer um desses modelos se assim desejasse Ao final cada equipe deveria entregar um documento de projeto com os modelos constru dos al m de realizar uma apresenta o de 20 minutos ressaltando os principais pontos do projeto importante ressaltar que a perspectiva de apresenta o foi exclu da desse estudo porque os seus modelos se demonstraram os menos aderentes aos padr es de modelagem aplicados neste trabalho particularmente no que diz respeito ao uso da UML Novas investiga es s o necess rias no sentido de aprimorar a percep o de como os aspectos estruturais e comportamentais dessa perspectiva podem ser representados em um contexto de desenvolvimento dirigido por modelos 2 4 4 Instrumenta o Foram entregues aos participantes a especifica o da aplica o e um template para prepara o da apresenta o da equipe direcionando a apresenta o para as quest es de interesse dos pesquisadores Tamb m foi disponibilizada a ferramenta BOUML PAG S 2011 juntamente com perfis UML OMG 2010a para constru o do modelo navegacional segundo o m todo OOWS PASTOR et al 2001 Novamente houve mudan a da ferramenta em rela o o estudo anterior Nesse caso a mudan a foi motivada pela descontinua o da ferramenta StarUML que naquele momento nao implementava inova es importantes da especifica o UML 2 0 principalmente em rela o aos diagramas de estado e atividades 22
42. gt Dat 0 oc and IsTypeoO nce f SystemResponse actions gt Dat 1 oc self gt asSequ IsTypeoO and nce f ActorAction self actions gt asSequ gt Dat 2 oc IsTypeo nce f SystemAction 118 5 3 6 4 Metaclasse AlternativeFlow A OU N 5 6 7 Condi o de guarda obrigat ria Deve ter pelo menos uma a o Deve ser referenciado por pelo menos uma a o do UseCase Deve sempre ser disparado por a es do mesmo tipo Se for disparado por uma ActorAction ent o sua primeira a o tem que ser uma SystemAction Se for disparado por uma SystemAction ent o sua primeira a o tem que ser uma SystemResponse ou uma FinishAction Se for disparado por uma SystemResponse ent o sua primeira a o tem que ser uma SystemResponse uma SystemAction ou uma FinishAction Formaliza o em OCL context AlternativeFlow inv self condition gt notEmpty inv self actions gt size gt 1 inv self cal r gt size gt 1 inv self caller gt size self caller gt select incoming source oclisTypeOf ActorAction gt size or self caller gt size self caller gt select incoming source oclIsType0Of SystemAction gt size
43. lt lt extend gt gt previstos na especifica o da UML OMG 2010a foram acrescentadas mais duas especializa es da metaclasse Action da UML definidas na Tabela 5 10 Tabela 5 10 Tipos de a es para inclus o e extens o de casos de uso Tipo da A o Descri o IncludeUCAction Define a inclus o de outro caso de uso no ponto onde esta a o definida ExtendUCAction Define a inser o de outro caso de uso no ponto onde esta a o definida 5 3 4 3 A es Especializadas no Metamodelo A Tabela 5 11 apresenta as v rias a es definidas para descri o de casos de uso e como esses elementos s o capturados pelo metamodelo UCModel A Figura 110 5 10 apresenta um extrato do metamodelo UCModel extrato da Figura 5 3 que destaca as metaclasses utilizadas para capturar as a es especializadas Tabela 5 11 Mapeamento entre as a es do caso de uso e os elementos do metamodelo UCModel Informa o Elemento do Modelo Figura 5 10 Agao do ator ActorAction 1 Ator da a o ActorAction actor 2 A o do sistema AlternativeFlow 3 Resposta do sistema AlternativeFlow actions 4 Ordem da a o BasicAction order 5 Fluxo ao qual a a o pertence BasicAction parent 6 Descri o da a o ActorAction name 7 SystemAction name SystemResponse name Complemento da a o ActorAction complement 8 SystemAction complement SystemResp
44. nio e suas associa es segundo a abordagem orientada a objetos Usa o diagrama de classes da UML Mapa de Atores foi extra do do m todo OOWS e utilizado para representar a taxonomia de atores no contexto da aplica o Diagrama de Contexto Navegacional tamb m foi extra do do OOWS e utilizado para representar os contextos de navega o acessados direta ou indiretamente por cada um dos atores Diagrama de Navega o representa o conte do de cada contexto de navega o usando os conceitos de n s e links Um n representa um conjunto de informa es que podem ser originadas de servi os ou vis es sobre o modelo conceitual Os links representam as formas de explora o das informa es ou servi os Templates de Apresenta o tamb m foram extra dos do OOWS e representam o particionamento da rea de apresenta o de acordo com o tipo da informa o a ser veiculada em cada rea Diagrama de Apresenta o foi extra do do m todo UWE HENNICKER e KOCH 2000 e se prop e a representar a estrutura das p ginas Web atrav s de um modelo de interface abstrata que mostra como os elementos abstratos da interface humano computador est o distribu dos pela p gina Modelo de Classes Detalhado modelo de classes representando a solu o computacional para o problema proposto Das cinco aplica es definidas no contexto do estudo somente a primeira foi alocada por conveni ncia a uma equipe devido complexidade do te
45. o tinham experi ncia na utiliza o das ferramentas que seriam usadas para especifica o dos casos de uso UCA e EDA Havia portanto um risco de despender um tempo maior para especifica o dos primeiros casos de uso em virtude do aprendizado relativo manipula o dos elementos da interface dessas ferramentas Para mitigar esse risco foi solicitado que os participantes especificassem inicialmente dois casos de uso que nao foram inclu dos na an lise dos dados casos de uso 10 e 26 Essa amea a afeta somente o primeiro estudo e Editor BOUML embora a ferramenta BOUML PAGES 2011 utilize uma interface gr fica semelhante a outras ferramentas UML barra de ferramentas apresentada de acordo com o tipo do diagrama janelas pop up para edi o das propriedades dos elementos drag and drop de elementos gr ficos dentre outros n o poss vel ter garantias de que o tempo gasto com o uso dessa ferramenta espec fica teria a mesma ordem de grandeza se a cria o dos diagramas fosse feita com outra ferramenta UML Nesse caso a influ ncia da qualidade da ferramenta no desempenho do participante pode ser minimizada com o uso de v rias ferramentas UML distintas Entretanto esse arranjo requer um aumento substancial no n mero de participantes do estudo e Tamanho da amostra pequenas amostragens s o um problema conhecido em experimentos na rea de Engenharia de Software e dif ceis de serem superados Neste caso explorou se
46. o de casos de uso durante a edi o Assim eles preferem trabalhar com a abordagem defendida por UCA Finalmente ambos os participantes relataram que a carga de treinamento e o material disponibilizado foram suficientes para especificar os casos de uso solicitados 171 Com rela o ao tempo reportado foi perguntado ao participante P2 se ele teve alguma dificuldade ao usar a UCA j que o tempo de especifica o com a UCA foi similar ao tempo de especifica o com a EDA Ele respondeu que n o se lembrava de nenhuma dificuldade em particular e que preferia usar a UCA ao inv s da EDA Assim nenhuma explica o plaus vel sobre a diferen a de tempo foi dada Uma hip tese para esse comportamento que a corre o dos defeitos apontados por UCA levou algum tempo no processo de especifica o pois a ferramenta n o permite gera o do diagrama de atividades caso as especifica es n o estejam em total conformidade com o metamodelo UCModel Os dados coletados no segundo estudo foram usados para avaliar esta possibilidade 7 3 Segundo Estudo 7 3 1 Objetivo O objetivo do segundo estudo pode ser formalizado usando o paradigma GQM BASILI e ROMBACH 1998 como Analisar especifica es de casos de uso constru dos com a ferramenta UseCaseAgent doravante denominada UCA e com um editor comum de diagramas de atividades doravante denominado EDA com o prop sito de caracterizar com respeito ao n mero de defeitos do p
47. pante Ski krein p a E e E A beets 166 1 2 0 Projeto do EsStUdO ass uniao eee E E E R E 166 7 2 6 Instrumenta o nneeeeeeeoeeenerenetesterttrrnnrresterrrrrrnnrrserrtnernnnrserernnnnnnnt 168 7 2 7 RECDAR AGA occ thao Se oc carers ecisansacceceentanadus vageeaiars eaicwcvsacenen eaciseevsaeaaionss 168 12 87 EXO CUA ess a Gt eat aaa a lh eal te ale Maca O etl 169 7 2 9 An lise CUAL VG ca ces ee Lave Soa gn een deed ave dar Seat eeeeeees cane endeevee ieee 169 7 2 10 An lise Qualitative ssccstecsccccitiasiiedeedecees ties sieeeedebeatinasiuadiethtesteaenie ne 171 7 3 Segundo EStUGO rrii a E E EEE REER eden ene 172 od O S11E10 EE E E E Aree E Nery E E Ra 172 73 2 S6le do CONTENTO eaer eto ain as e EE E ada 172 7 3 3 Sele o de Vari veis s cpmeniisa das gal Sncrvzengeneesamtees Teen peck Ad Ian det adianta cha 173 vii P34 PARICIPANTOS ienne a teh alavenpie aks aentlaiasehons 173 7 3 5 Projeto do Estudo i 8 erica ae CR crete earn qro E RGE ndo Ego ds 173 7 3 0 Instrumenta o aces oa aah cates Lema Rah da atau eae US 174 1 3 1 Prepara o Pesa Sein Fe orar in a ra O a AE ias 174 T38 EXECU O clama ie Sais eich nce le Mikael nda Met enable aa nbr TEE teen 175 7 3 9 Valida o dos DAdOS viescccscietesereiescipeeetianeie en siieerede enn eo 175 Toco FAOSUNAGOS soo eles acne ase O O A see Saag hac 175 7 4 Amea as Validade dos Estudos ra 179 7 5 CONCLUS O aaa fait acres aiaa eee E raea a a iii 18
48. rie de coment rios que procuram indicar quais regras s o relevantes em determinado ponto do diagrama Gera o dos casos e procedimentos de teste a partir dos modelos de teste devidamente complementados essa atividade se limita a percorrer o modelo de testes e gerar os caminhos poss veis de execu o no diagrama aplicando os valores definidos em cada ponto de decis o Os passos 1 e 3 desse processo s o apoiados por uma ferramenta chamada ModelT definida e constru da no escopo deste trabalho que ser apresentada em detalhes no Cap tulo 6 4 8 Conclus o Neste cap tulo foi apresentada uma vis o detalhada da abordagem proposta e dos conceitos que a comp em al m dos documentos e artefatos envolvidos na produ o da especifica o de requisitos funcionais Fazem parte do escopo dessa abordagem 1 4 Um conjunto de atividades de especifica o e inspe o de requisitos funcionais alinhadas com o processo de engenharia de requisitos previsto no SEWBOK SAWYER e KOTONYA 2004 al m de atividades para gera o de testes funcionais a partir de descri es de casos de uso Um gabarito para o documento de requisitos alinhado com o padr o IEEE 830 1998 IEEE 1998 e com o gabarito de especifica o Volere ROBERTSON e ROBERTSON 2010 e organizado para apoiar a especifica o de requisitos funcionais de aplica es Web segundo a abordagem proposta Um gabarito para especifica o de casos de uso org
49. s o lt no description gt vencimento system response 1 1 3 Test Case Data Variations opcaol a2 boletol valida invalida sim nao numero invalido vencido valido TC001 TPI Step 2 Step 3 Step 4 Step 6 Step 7 Figura 6 17 Trecho do documento de casos e procedimentos de testes do caso de uso Pagar boleto banc rio com um caminho e os valores para percorrer esse caminho 6 3 1 4 Trabalhos Relacionados A utiliza o da ModelT para gera o do modelo de testes inicial se prop e a e Minimizar o esfor o na cria o desse modelo no momento em que permite obter todos os caminhos poss veis de explora o do caso de uso de forma autom tica e e Apoiar a defini o das classes de equival ncia e seus valores atrav s de coment rios no modelo de testes que destacam as regras a serem observadas em determinado ponto de decis o Nas abordagens para modelagem de testes funcionais TDE HARTMANN et al 2005 e TSD G IS et al 2010 os diagramas que descrevem os modelos de teste s o gerados manualmente pelo analista de testes apoiado pelas respectivas ferramentas TDE UML e TestKase A abordagem aqui proposta procura reusar a especifica o dos casos de uso e criar artefatos que permitam explorar abordagens de MBT para testes funcionais tentando minimizar a interfer ncia manual na deriva o dos modelos de
50. sticas de forma bastante semelhante ao uso de uma DSL Domain Specific Language Como os pr prios autores afirmam essa uma abordagem voltada para organiza es de pequeno e m dio porte 3 2 3 24 WebTDD O m todo WebTDD LUNA et al 2010a aplica o mesmo estilo adotado no desenvolvimento dirigido por testes TDD Test Driven Development por m ao inv s de se basear na codifica o baseia se na modelagem para gera o da aplica o No WebTDD os requisitos s o adicionados incrementalmente em ciclos de desenvolvimento curtos atrav s de diagramas descritos na linguagem espec fica de dom nio WebSpec LUNA et al 2010b O diagrama da WebSpec tem dois elementos chave e Intera o representa uma p gina Web que pode conter elementos gr ficos como bot es listas r tulos dentre outros e e Navega o s o liga es entre as intera es ou seja links entre p ginas que podem estar associados restri es ou trechos de c digo escritos em WebSpec Com esses diagramas os comportamentos do sistema durante a intera o ator sistema s o definidos visualmente Esses diagramas s o explorados no processo WebTDD que composto das seguintes fases 1 Captura de requisitos feita atrav s de mockups e diagramas WebSpec 2 Gera o de testes s o criados testes para verificar a intera o a partir dos diagramas WebSpec 3 Execu o dos testes assim como no TDD os testes s o executados para verifi
51. 1 WSDM Web Site Design Method O WSDM DE TROYER e LEUNE 1997 uma abordagem centrada no usu rio cuja fase inicial se concentra na modelagem dos usu rios Nessa fase os diferentes tipos de p blico alvo s o agrupados de acordo com interesses relacionados as funcionalidades ou informa es a serem providas pelo sistema O resultado final dessa an lise uma hierarquia de grupos de usu rios onde para cada grupo s o definidos em linguagem natural os requisitos funcionais de informa o de usabilidade al m de outras caracter sticas como idioma e experi ncia Em seguida executada a modelagem conceitual onde s o criados os modelo de informa o o modelo funcional e o modelo navegacional Por fim os modelos de implementa o detalham as p ginas da aplica o juntamente com o projeto da apresenta o e o modelos de dados 3 2 3 2 SOHDM Scenario based Object oriented Hypermedia Design Methodology O SOHDM LEE et al 1998 foi o primeiro m todo Web a incluir uma fase espec fica de an lise de requisitos onde s o explorados cen rios para a descri o desses requisitos Cen rios s o descritos graficamente atrav s de uma nota o propriet ria chamada Gr fico de Atividade do Cen rios SAC Scenario Activity Chart e descrevem a intera o entre o usu rio e o sistema quando um evento ocorre Nesse gr fico s o especificados o fluxo de atividades os objetos envolvidos e as transa es executadas A partir
52. 131 132 KAPPEL G PROLL B REICH S RETSCHITZEGGER W 2006 An Introduction to Web Engineering In Kappel G Pr ll B Reich S Retschitzegger W eds Web Engineering The Discipline of Systematic Development of Web Applications John Wiley amp Sons ISBN 978 0470015544 KITCHENHAM B 2004 Procedures for Performing Systematic Reviews Joint Technical Report Keele University TR SE 0401 and NICTA Technical Report 0400011T 1 Keele University and NICTA KOCH N ZHANG G ESCALONA M J 2006 Model transformations from requirements to web system design Proceedings of 6 International Conference on Web Engineering ICWE 06 pp 281 288 KOSTERS G SIX H W WINTER M 2001 Coupling Use Cases and Class Models as a Mean for Validation and Verification of Requirements Specifications Requirements Engineering v 6 n 1 pp 3 17 KRUCHTEN P 2004 The Rational Unified Process an Introduction Addison Wesley 3 edi o KULAK D GUINEY E 2003 Use Cases Requirements in Context Addison Wesley 2 edi o LAMSWEERDE A van 2009 Requirements Engineering John Wiley amp Sons ISBN 978 0 470 01270 3 LARMAN C 2003 Applying UML and Patterns An Introduction to Object Oriented Analysis and Design and the Iterative Development Prentice Hall PTR 3 edi o LAVAZZA L BIANCO V GARAVAGLIA C 2008 Model based Functional
53. Ferramenta Participante N vel de Grupo do caso de experi ncia uso 1 EDA P1 Alto A P2 Baixo B 2 UCA P1 Alto B P2 Baixo A A rodada 1 foi executada de forma ad hoc ou seja os participantes constru ram as especifica es dos casos de uso usando somente um editor comum de diagramas de atividades com o perfil ProfieUCModel Na segunda rodada as especifica es dos casos de uso foram constru das usando a ferramenta UseCaseAgent que gera automaticamente os diagramas de atividades correspondentes a cada caso de uso a partir das especifica es textuais de cada um 167 Com rela o ao editor de diagramas de atividades a ferramenta BOUML PAGES 2011 foi escolhida Adicionalmente cada participante executou a especifica o individualmente e foi solicitado que fosse seguida a ordem definida na Tabela 7 1 7 2 6 Instrumenta o Os instrumentos preparados e usados como apoio ao estudo foram 1 o No a e Especifica o funcional original do m dulo financeiro contendo a descri o dos casos de uso Projeto na ferramenta case BOUML vazio ou seja sem nenhum modelo contendo somente o perfil ProfileUCModel com os estere tipos necess rios para cria o dos diagramas de atividades Planilha eletr nica para registrar o tempo gasto em minutos na especifica o de cada caso de uso Material de treinamento sobre casos de uso Material de treinamento sobre diagramas de atividades da UML 2 Mat
54. TCModel Package Structure Generate Check UCModel TCModel Package Structure Reverse Create Use Case Roundtrip Print Use Cases Create Test Cases package use case model Figura A 14 Ativa o do UseCaseAgent a partir do BOUML para impress o dos casos de uso Na tela apresentada na Figura A 15 basta selecionar os casos de uso a serem impressos e acionar a op o Verificar Os casos de uso cujas especifica es estiverem sintaticamente corretas poder o ser impressos no arquivo RTF desejado Figura A 16 215 r Use Case Agent vers o 0 3 Selecione os Casos de Uso UCOO1 Autentica o do usu rio Verificar gt gt Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 15 Tela do UseCaseAgent para sele o dos casos de uso a serem impressos 4 Use Case Agent vers o 0 Verifica o das Descri es dos Casos de Uso UCOO1 est OK Sair Arquivo C Users Jobson Documents teste rtf i Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 16 Tela do UseCaseAgent para sele o do documento onde os casos de uso sintaticamente corretos serao serem impressos A 15 Verificagao Sintatica do Diagrama de Atividades O UseCaseAgent nao impossibilita que o desenvolvedor crie altere a especifica o do caso de uso editando diretamente o diagrama de atividades Entretanto essa op o deve ser usada
55. a gera o do diagrama de descri o do UC abortada Alguns desses erros s o auto explicativos e Nome do Caso de Uso obrigat rio e Resumo do Caso de Uso obrigat rio e Trigger do Caso de Uso obrigat ria e Pr condicao do Caso de Uso obrigat ria e P s condi o do Caso de Uso obrigat ria e O destino do goto deve ser definido e A descri o da a o obrigat ria e Regra X tem que ter uma descri o e A regra X n o referenciada por nenhum passo do Caso de Uso 224 e O destino de uma a o goto n o pode ser outra a o goto e A inclus o lt lt include gt gt deve referenciar um caso de uso existente e A extens o lt lt extend gt gt deve referenciar um caso de uso existente e O Fluxo Alternativo X n o referenciado por nenhum passo do Caso de Uso e O Fluxo de Exce o X n o referenciado por nenhum passo do Caso de Uso e O Caso de Uso tem que ter pelo menos um ator Voc deve selecionar ao menos um ator para o Caso de Uso Use a op o Atores do Caso de Uso se o 5 2 e Um fluxo tem que ter pelo menos uma a o O fluxo principal alternativo ou de exce o deve ter pelo menos uma a o ou seja voc n o pode criar um fluxo e n o defini lo e Um fluxo alternativo exce o n o pode ter somente uma a o goto Fluxos alternativos exce o devem possuir pelo menos uma a o concreta a o do ator a o do sistema ou resposta do sistema N o
56. ae nd desde at rode USAR ba ear 157 Figura 6 17 Trecho do documento de casos e procedimentos de testes do caso de uso Pagar boleto banc rio com um caminho e os valores para percorrer esse COMMUN MPS ea SR a DDR RR EN 160 Figura 7 1 Vis o geral dos estudos de avalia o 163 Figura 7 2 Avalia o do n vel de complexidade dos casos de uso selecionados 166 Figura 7 3 Boxplots relativos aos defeitos reportados nas especifica es de caso de uso constru das com as ferramentas EDA e UCA tela da ferramenta JMP v 4 177 xi NDICE DE TABELAS Tabela 2 1 Atividades e artefatos do 1 estudo de observa o 14 Tabela 2 2 Medidas diretas extra das dos artefatos de projeto do 1 estudo 16 Tabela 2 3 Atividades e artefatos do 2 estudo de observa o 18 Tabela 2 4 Dificuldades relatadas pelos participantes do 2 estudo 20 Tabela 2 5 Dados quantitativos do 2 CStUCO sseeeseseeeeeeeesesseeeeeeseeseeeseteeeeeees 20 Tabela 2 6 Atua o dos desenvolvedores por modelo 23 Tabela 2 7 Percep o de esfor o ssa ntsasdrs paris ia dasia co asbasnpaRasib posa nioD ossadas somasssalpadas 23 Tabela 2 8 Distribui o de percep o de esfor o dos participantes que criaram os AN SIO S lena pen E E tak E E AE E iu taeitdakeaalidantealsaantealsade E 24 Tabela
57. artefatos 7 1 Introdu o O objetivo principal dos dois estudos apresentados neste cap tulo de avaliar de forma conjunta a abordagem proposta neste trabalho da qual o metamodelo UCModel faz parte e as ferramentas que ap iam a atividade de especifica o Com rela o s ferramentas duas possibilidades para especifica o s o contempladas atrav s de artefatos e ferramentas definidos e constru dos no escopo desta tese e Especifica o usando o perfil UML ProfileUCModel neste caso o desenvolvedor conta apenas com a ferramenta BOUML e o perfil ProfileUCModel para constru o dos diagramas de atividades relativos aos casos de uso No contexto deste estudo essa abordagem de especifica o foi considerada ad hoc devido a essa ser a forma usual de trabalho dos participantes do estudo ou seja constru o de modelos com o uso de ferramentas case Al m disso a aplica o dos estere tipos do perfil ao diagrama n o garante que este est em conformidade com o metamodelo UCModel ficando a cargo do desenvolvedor a tarefa de verifica o Nesse caso o desenvolvedor pode ou n o estar atento s quest es de conformidade e Especifica o usando UseCaseAgent neste caso o desenvolvedor conta com uma ferramenta especialmente projetada para tratar os elementos do metamodelo UCModel e suas restri es Essa ferramenta permite que o desenvolvedor especifique o caso de uso em formato puramente textual a partir do qual o diagr
58. banc rio Atores do Caso de Uso BR2 E obrigat rio que o boleto seja emitido pelo banco se a data de vencimento for menor que 6 g BR4 E obrigat rio que o n mero do boleto esteja de acordo com a especifica o da se o 3 do 6 E Fluxos Alternativos ee E E ree de Esse INR3 E obrigat rio que seja apresentado o valor do boleto contido no n mero do boleto se o n 7 Em e aiii BR5 E obrigat rio que a data de pagamento seja maior ou igual a data corrente 9 a 9 9 9 4 Fluxo Principal BR6 obrigat rio que o valor do desconto seja menor que o valor do boleto Ea Pag bio iti ia BR7 obrigat rio que o valor dos juros seja fornecido se a data de pagamento for menor que a a TEn BR8 Valor a ser pago valor do boleto desconto juros E ad BR9 E obrigat rio que o valor a ser pago seja maor que zero 9 EE UCOO4 Autenticar usu rio BR11 E obrigat rio que a senha fornecida seja id ntica a senha do cart o cadastrada no sistema 12 INR 10 E obrigat rio que o sistema apresente uma mensagem de erro para cada dado que esteja i A5 1 Neg cio A obrigat ria a sele o de uma e apenas uma fonte de recurso jum Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 7 Tela da UseCaseAgent com as regras do caso de uso Pagar boleto banc rio 6 2 1 2 Verifica o
59. capturar as informa es do caso de uso nome descri o import ncia frequ ncia de uso trigger a es e exce es fluxos alternativos As descri es das a es realizada em linguagem natural e a verifica o da especifica o realizada atrav s da ader ncia da especifica o ao metamodelo e de um conjunto de heur sticas que tratam do balanceamento do n mero de a es do ator e a es do sistema em um caso de uso da complexidade ciclom tica do caso de uso dentre outras A descri o do caso de uso n o representada usando nenhum modelo somente texto 149 6 2 2 3 UCEd uma ferramenta para modelagem de casos de uso que implementa o metamodelo descrito em SOM 2006 e SOM 2009 O UCEd um editor orientado a formul rios que captura um conjunto de informa es acerca do caso de uso a saber t tulo descri o ator prim rio pr e p s condi es e trigger fluxo principal e fluxos alternativos Com rela o s a es do caso de uso o UCEd captura essas a es em linguagem natural e verifica se estas seguem uma sintaxe pr definida que envolve substantivos entidades do dom nio e verbos opera es relacionadas entidades do dom nio A partir da descri o do caso de uso a ferramenta UCEd pode gerar uma m quina de estados OMG 2010a onde os estados s o definidos pelos valores dos atributos das entidades do dom nio e as transi es representam as opera es isto os verbos
60. caso de uso Pagar boleto banc rio 155 6 3 1 2 Edi o do Modelo de Testes Do ponto de vista estrutural nada precisa ser alterado no modelo de testes gerado pela ModelT2 pois as sequ ncias de a es e desvios definidos nesse modelo cobrem todos os caminhos especificados nos casos de uso Nessa etapa o analista de testes deve concentrar seus esfor os na defini o das classes de equival ncia e seus valores de forma a cobrir as condi es estabelecidas nas regras e nas express es de guarda associadas aos desvios Para essa tarefa o analista de testes utiliza a pr pria ferramenta BOUML e apoiado pelos coment rios criados no modelo que destacam as regras relevantes em cada ponto de decis o e por outros artefatos da especifica o como o gloss rio e os modelos conceituais do dom nio nos quais os conceitos relacionados ao dom nio do problema devem estar definidos A Figura 6 16 apresenta o modelo de testes do caso de uso Pagar boleto banc rio alterado pelo analista de testes Neste caso foram realizadas as seguintes altera es 1 Cria o das classes de equival ncia opcao1 com os valores valida e invalida 2 Cria o da classe de equival ncia boleto com os valores numero invalido vencido e valido 3 Cria o da classe de equival ncia dadosPagamento1 com os valores data invalida desconto invalido juros invalidos valor final invalido e valido
61. cd AD O att nS RD NS Ra ao taka ar 99 Figura 5 4 Vis o parcial do metamodelo UCModel referente ao caso de uso e seus elementos DASICOS essi at sineira pari Noneades ae aeanhaesiedeadeete REEN AEE ETEINEN 100 Figura 5 5 Padr o de representa o de um caso de uso e seus elementos b sicos usando o diagrama de atividades da UML 2 ccccccccccccccccceeeeeeeeeeeeeeeeeeeeeeeeeeeeess 102 Figura 5 6 Vis o parcial do metamodelo UCModel referente s regras de neg cio dom nio e sua rela o com o metamodelo da UML 104 Figura 5 7 Padr o de representa o de um caso de uso e suas regras de neg cio dom nio usando o diagrama de atividades da UML 2 105 Figura 5 8 Vis o parcial do metamodelo UCModel referente aos fluxos principal alternativos e de exce o e sua rela o com o metamodelo da UML 106 Figura 5 9 Padr o de representa o de um caso de uso e seus fluxos principal alternativos e de exce o usando diagrama de atividades da UML 107 Figura 5 10 Vis o parcial do metamodelo UCModel referente s a es que comp em os fluxos do caso de uso e a sua rela o com o metamodelo da UML 112 Figura 5 11 Transi es b sicas permitidas entre as a es ActorAction SystemAction e SPSS em RESpONSO nas grades Roi ei aa Madden Fi a a ga dn ara 115 Figura 5 12 Transi es permitidas a partir de uma ActorAction com fluxo alternat
62. com cuidado pois caso o diagrama criado editado n o possua os requisitos m nimos para ser convertido para o metamodelo UCModel a sua edi o via UseCaseAgent n o ser poss vel Para verificar se um diagrama alterado no BOUML est ou n o aderente ao metamodelo UCModel basta acionar o menu de contexto sobre a atividade que especifica o caso de uso e acionar a op o Tool gt Check Use Case conforme a Figura A 17 Caso alguma incompatibilidade seja detectada a mensagem de erro correspondente ser apresentada no console do BOUML Nesse caso o diagrama deve ser corrigido pelo desenvolvedor usando o editor do BOUML 216 Use Case Agent vers o 0 3 Selecione os Casos de Uso UC001 Autentica o do usu rio Verificar gt gt Lose Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 17 Tela do BOUML A 16 Restri es do UseCaseAgent Ao editar um caso de uso o UseCaseAgent sempre exclui a sua especifica o anterior diagrama de atividades e gera um nova especifica o Portanto se foram acrescentados elementos ao diagrama que n o fazem parte do metamodelo por exemplo coment rios associados s a es estes ser o perdidos Na vers o atual o UseCaseAgent n o permite a edi o de informa es que fluem entre as a es do caso de uso fluxo de dados Assim se forem criados fluxos de dados entre as a es do caso de uso esses n o ser o vis veis no UseC
63. complementados por uma descri o semi estruturada em linguagem natural A utiliza o de diagramas de atividades para casos de uso complexos tamb m sugerida A partir da especifica o dos requisitos s o desenvolvidos o modelo de dados o modelo de hipertexto e o modelo de apresenta o Finalmente os testes de aceita o propostos s o voltados para verifica o de requisitos n o funcionais 3 2 3 8 W2000 O W2000 BARESI et al 2001 um m todo originado do m todo HDM GARZOTTO et al 1993 que tenta promover o refinamento gradativo dos modelos desde a fase da an lise O ciclo de vida proposto pelo W2000 composto de 3 fases an lise de requisitos projeto hiperm dia e projeto funcional Na fase de an lise de requisitos s o previstas duas atividades e An lise de requisitos funcionais define o modelo de casos de uso e seus atores e e An lise de requisitos navegacionais tamb m usa o modelo de casos de uso para representar as possibilidades de navega o do ator Nesse caso usa uma nota o gr fica que estende a nota o UML original 42 A partir desses casos de uso s o projetados os modelos conceitual e navegacional e a partir desses modelos s o definidos os diagramas de sequ ncia que descrevem as funcionalidades do sistema 3 2 3 9 Design driven Requirements Elicitation DDDP O DDDP parte do processo proposto por LOWE e EKLUND 2002 para desenvolvimento de aplica es Web Esse m tod
64. de uso por duas equipes e como representa o gr fica dos processos de neg cio por uma equipe uma das equipes abdicou do seu uso Entretanto nenhuma delas declarou que o diagrama era essencial ou ao menos importante Esse fato nos remete a uma quest o mais geral a percep o da import ncia pode estar diretamente 27 relacionada defini o de um foco claro e objetivo para o modelo a partir do qual o desenvolvedor consegue perceber os benef cios e os desdobramentos do seu uso Diagrama de Estado Esse diagrama foi razoavelmente explorado pelas equipes e o seu grau de import ncia teve um vi s de baixa Tabela 2 9 assim como o esfor o percebido pelos participantes Tabela 2 8 Apesar do dom nio da aplica o desenvolvida realmente n o exigir m quinas de estado muito aprimoradas constatamos atrav s da an lise dos diagramas gerados pelas equipes que o grau de detalhamento desses diagramas n o acompanhou o grau de detalhamento do modelo de classes e sequ ncia causando um desbalanceamento entre esses modelos em termos de abstra o Isso pode ter sido causado pela falta de experi ncia dos desenvolvedores e ou treinamento inadequado o mesmo ocorreu com os diagramas de sequ ncia j que ambos focam no aspecto comportamental Entretanto uma dificuldade relatada chamou a aten o o documento de requisitos Atrav s da an lise dos dados qualitativos foi poss vel entender a raz o dessa dificuldade alguns participant
65. de um ator e Ser escrito no vocabul rio do dom nio e Modelar um ou mais requisitos funcionais do sistema e Fornecer uma vis o externa do sistema importante para os stakeholders validarem e Descrever o qu o sistema faz mas n o detalha ou especifica como feito e e Ser livre de tecnologia Segundo Jacobson Jacobson 92 um caso de uso uma sequ ncia de transa es realizada por um sistema para produzir um resultado de valor observ vel para um determinado ator ou conjunto de atores Uma transa o consiste em um conjunto de a es realizado por um sistema e disparada por um ator ou por um evento qualquer dentro do sistema De acordo com Jacobson uma transa o consiste em 4 passos 1 Um ator prim rio envia uma solicita o e os dados se existirem para o sistema 2 O sistema valida a solicita o e os dados se pertinente 3 O sistema altera seu estado interno como resultado do processamento da solicita o 4 O sistema retorna o resultado ao ator Para aprimorarmos as descri es alguns conceitos s o importantes 220 e Fluxo Principal descreve a sequ ncia de a es que ser o executadas considerando que nada anormal acontecer durante essa execu o ou seja descreve o que normalmente acontece quando o caso de uso realizado na situa o ideal ou mais comum e Fluxos Alternativos descrevem o que acontece quando o ator faz uma escolha alternativa ou quando o resultado
66. de um apoio ferramental para suprir essa lacuna Em um primeiro momento a funcionalidade b sica do UseCaseAgent seria somente a de permitir a verifica o da ader ncia de diagramas de atividades criados 136 com o perfil ProfileUCModel ao metamodelo UCModel ou seja o desenvolvedor usaria o editor da ferramenta UML para criar o digrama de atividades com o perfil ProfileUCModel e posteriormente usaria a ferramenta UseCaseAgent para verificar a ader ncia de tais diagramas ao metamodelo UCModel Como clara desvantagem desse arranjo est a possibilidade de criar diagramas n o aderentes ao UCModel pois ficaria a cargo do desenvolvedor acionar ou n o a verifica o dos modelos gerados Em virtude disso ao inv s de implementar somente a funcionalidade de verifica o do diagrama optou se por incluir uma funcionalidade para cria o edi o do caso de uso em formato texto integrando a verifica o de ader ncia ao UCModel e a gera o autom tica do diagrama de atividades a partir dessa descri o textual Assim as principais funcionalidades implementadas na ferramenta UseCaseAgent s o 1 Cria o das especifica es dos casos de uso de acordo com o metamodelo UCModel usando uma abordagem textual 2 Verifica o autom tica das restri es previstas no metamodelo UCModel ou seja verifica o sint tica da especifica o do caso de uso 3 Gera o autom tica do diagrama de atividades correspondente ao caso de uso especifi
67. de um processamento demanda alguma tomada de decis o e Fluxos de Exce o correspondem descri o das situa es de exce o ou seja descrevem o que acontece quando algo inesperado ocorre na intera o entre o ator e o sistema e Trigger evento ou condi o que dispara a execu o do caso de uso e Pr condi o define que hip teses s o assumidas como verdadeiras para que o caso de uso tenha in cio Deve ser usada em casos de uso cuja realiza o n o faz sentido em qualquer momento mas somente quando o sistema est em um determinado estado ou com certas propriedades e P s condi o estado que o sistema alcan a ap s o caso de uso ter sido realizado com sucesso e Regras s o pol ticas condi es ou restri es que devem ser consideradas na execu o dos processos existentes em uma organiza o ou em um sistema em particular Dicas de Estilo e Casos de uso devem ter nomes que indiquem o objetivo do ator de prefer ncia no formato verbo no infinitivo substantivo e Descreva o caso de uso do ponto de vista do ator prim rio e Use sempre termos relacionados ao dom nio do problema e e N o use termos que direcionem para uma solu o ou tecnologia espec fica 221 e Use links para outros documentos ou refer ncias para outras se es do documento f rmulas de c lculos layouts de relat rios telas arquivos de interface com outros sistemas dentre outros ao
68. decis o de n o avalia o est baseada em um dos objetivos da pr pria abordagem aqui proposta e materializado atrav s da ferramenta ModelT apoiar a gera o de casos e procedimentos de testes funcionais usando uma abordagem MBT atrav s da gera o autom tica de um modelo de testes preliminar em substitui o gera o manual desse modelo Ou seja como a abordagem preconizada por TDE e a pr pria ferramenta TDE UML s o usados em um ambiente industrial de larga escala a preocupa o era mostrar a viabilidade da deriva o autom tica de uma vers o preliminar do modelo de testes a fim de evitar que este seja gerado manualmente pelo analista de testes Entretanto existem avalia es que devem ser conduzidas nesse contexto e que ser o objetos de trabalhos futuros como por exemplo avaliar se o apoio criado no modelo de testes preliminar para auxiliar o analista de testes na complementa o do modelo adequado Por outro lado a ferramenta UseCaseAgent foi utilizada na condu o da avalia o experimental da abordagem que ser apresentada no Cap tulo 7 161 7 Avalia o Experimental Neste cap tulo s o apresentados dois estudos conduzidos no contexto da abordagem proposta nesta tese O resultado desses estudos nos trazem indica es de que o uso da abordagem para especifica o de casos de uso baseada no metamodelo UCModel apoiada pela ferramenta UseCaseAgent pode auxiliar na redu o de defeitos nesses
69. desenvolvimento espec fico apoiada por uma grande quantidade de ferramentas case algumas delas open source 4 3 Processo de Engenharia de Requisitos O SWEBOK Software Engineering Body of Knowledge SAWYER e KOTONYA 2004 publicado tamb m como ISO IEC TR 19759 2005 sugere que o processo de Engenharia de Requisitos seja dividido em quatro atividades defini o Elicita o de requisitos abrange a identifica o de necessidades e a coleta de informa es relacionadas ao sistema Essas informa es podem ser capturadas de diversas fontes usu rios documentos sistemas legados modelos e outros mais usando diversas t cnicas entrevistas brainstorming observa o dentre outras ESCALONA e KOCH 2004 SAWYER e KOTONYA 2004 e constituem os requisitos da aplica o An lise de requisitos processo de an lise das informa es obtidas durante a elicita o a fim de obter os requisitos do software Pode envolver a classifica o dos requisitos elicitados a defini o das fronteiras do sistema e a elabora o de modelos conceituais relacionados ao dom nio do problema Especifica o de requisitos produ o de um ou mais documentos segundo uma abordagem ou t cnica que podem ser sistematicamente revisados avaliados e aprovados Dependendo da complexidade do produto a ser desenvolvido esses documentos podem conter a defini o do sistema os requisitos do sistema e os requisitos do software e Vali
70. deste trabalho com o objetivo de oferecer um arcabou o sint tico e sem ntico a partir do qual poss vel estruturar a especifica o do comportamento do sistema atrav s de um conjunto de crit rios e restri es que ap iam a especifica o de casos de uso Dois princ pios nortearam a defini o do metamodelo UCModel e O conceito de transa o de casos de uso JACOBSON 1992 a partir do qual foi elaborado um conjunto de a es especializadas para especifica o das sequ ncias de a es do caso de uso e e As perspectivas de projeto Web que refor aram a especializa o das a es do sistema a partir da defini o das perspectivas onde essas a es atuam A formaliza o sint tica e sem ntica da especifica o dos casos de uso proporcionada pelo UCModel um dos elementos chave da abordagem proposta nesta tese pois ela traz a possibilidade de explorar cen rios relacionados garantia da qualidade da especifica o e do produto final como e Defini o de um apoio computacional para verifica o autom tica de defeitos sint ticos nas especifica es de casos de uso 132 e Elabora o de um conjunto de orienta es para descri o de casos de uso baseado na sem ntica dos elementos do UCModel e Elabora o de regras de transforma o modelo modelo com o prop sito de derivar modelos de testes funcionais a partir dos modelos de especifica o Com rela o ao primeiro c
71. do Caso de Uso A qualquer momento da cria o do caso de uso poss vel acionar a op o de verifica o dessa especifica o A verifica o avalia a especifica o de acordo com as restri es definidas na se o 5 3 6 p gina 117 Para cada defeito detectado apresentado o local e a posi o do mesmo A Figura 6 8 apresenta a tela com a lista de defeitos detectados para o caso de uso usado como exemplo 142 i S Use Case Agent vers o 0 39 or w _ belak Arquivo Verificar Av amp UCModel Atores Local Posi o Descri o 5 dk Casos de Uso Fluxo principal Uma a o do ator deve ser sucedida por uma a o do sistema goto indude ou extend G r UC001 Pagar boleto banc rio Fluxo principal Uma resposta do sistema deve ser sucedida por uma a o do ator goto indude ou extend Fluxo Principal A7 Se um fluxo alternativo exce o disparado por uma a o do ator ent o sua primeira a o tem que ser uma a o do sistema E Fluxos Alternativos Fluxo principal Uma a o do sistema deve ser sucedida por outra a o do sistema uma resposta do sistema goto include ou extend 5 6 Atoresdo Casode Uso la3 1 Se um fluxo alternativo exce o disparado por uma a o do ator ent o sua primeira a o tem que ser uma a o do sistema 1 7 Fluxos de Exce o Regra A regra BR9 n o referenciada por nenhum passo do Caso de Uso Regras Eu
72. e Sair sai do UseCaseAgent sem salvar a descri o do caso de uso No menu existe uma quarta op o e Salvar como novo verifica a sintaxe da descri o e cria um novo caso de uso caso n o haja nenhum erro Essa op o s est dispon vel se o caso de uso estiver sendo editado Nessa tela tamb m temos a rvore no painel esquerda que usada para navegar entre os elementos do caso de uso Ao selecionar os elementos dessa rvore s o apresentadas telas espec ficas no painel direita da tela e Atores mostra a lista de atores cadastrados e os casos de uso que os referenciam e Lista de Casos de Uso lista com todos os casos de uso existentes O caso de uso destacado em vermelho aquele que est sendo 206 criado editado Os demais casos de uso n o podem ser editados mas podem ser referenciados nos includes ou extends e Atores do Caso de Uso mostra a lista com os atores existentes e permite selecionar quais atores estao associados ao caso de uso Corrente e Fluxo principal mostra a lista de a es do fluxo principal permitindo a sua edi o e Fluxos alternativos lista com os fluxos alternativos definidos para o caso de uso corrente Para editar um fluxo alternativo basta clicar sobre ele e Fluxos de exce o lista com os fluxos de exce o definidos para o caso de uso corrente Para editar um fluxo de exce o basta clicar sobre ele e Regras mostra a lista com as regras associadas ao caso de uso
73. em minutos para cada caso de uso especificado 7 2 9 An lise Quantitativa A Tabela 7 4 apresenta os tempos reportados pelos participantes para cada caso de uso Somente oito dos dez casos de uso foram considerados nessa an lise pois os casos de uso 10 e 26 foram usados como exerc cio de aquecimento no uso da ferramenta Nessa mesma tabela tamb m poss vel observar o tempo total e a mediana de tempo por grupo de caso de uso e n vel de experi ncia dos participantes al m do tempo total e mediana de tempo por ferramenta 169 Observando o tempo e a mediana por ferramenta os dados coletados sugerem que o tempo gasto com o uso da ferramenta UCA pode ser menor que o tempo gasto com a ferramenta EDA Tamb m poss vel observar que o desenvolvedor mais experiente teve uma redu o significava no tempo de especifica o usando a ferramenta UCA enquanto o desenvolvedor menos experiente n o apresentou redu o no tempo independente do uso da ferramenta ADE ou UCA Esse ltimo comportamento sugere que pode existir alguma rela o entre a experi ncia do desenvolvedor e o tempo gasto com uso da ferramenta UCA Por outro lado analisando os tempos gastos com a especifica o dos casos de uso do conjunto A o tempo gasto e a mediana de tempo com o uso da ferramenta EDA foi menor que o tempo gasto e a mediana de tempo com a ferramenta UCA o que pode indicar que o n vel de experi ncia do desenvolvedor influencia no desempenho dess
74. es 9 ern Ts a cmo Ma MM aie Arquivo Verificar genres Atores do Caso de U Atores es do iso de Uso 3 1 Casos de Uso J CO 1 Autentica o do usu rio Atores do Caso de Uso Fluxo Principal E Fluxos Alternativos E Fluxos de Exce o E g Regras Erros Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 6 Tela do UseCaseAgent para associa o dos atores com o caso de uso Nessa tela s o listados todos os atores cadastrados na pasta lt lt actors gt gt Para associar ou dissociar um ou mais atores ao caso de uso basta marc los ou desmarc los nessa lista A 8 Fluxo Principal Ao clicar em Fluxo Principal apresentada a tela da Figura A 7 para edi o dos passos do caso de uso 208 Use Case Agent vers o 0 3 o E EE 9 Oe on os cosa Mada sm 0a Sox Arquivo Verificar Av amp UCModel Atores EI Casos de Uso GJ UCOO1 Autentica o do usu rio Atores do Caso de Uso e GEO E Fluxos Alternativos E Fluxos de Exce o E g Regras Erros Fluxo Principal Ordem Descri o Alternativas Exce es Regras A es Alternativas Exce es Regras Acrescentar Inse Delet Para cima Para baixo Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 7 Tela do UseCaseAgent para cria o das a es do fluxo principal Nessa tela poss vel e Acrescentar uma a o ao final do fluxo e Inse
75. es Web Foram analisados 24 m todos ao longo dos ltimos anos e os resultados dessa an lise auxiliaram no entendimento do estado da arte em termos de tratamento de requisitos por parte dos m todos Web e forneceram indica es para a concep o da abordagem de especifica o proposta nesta tese 3 1 Introdu o Com o objetivo de identificar trabalhos relevantes com rela o ao tratamento de requisitos de aplica es Web foi realizado um levantamento sobre quais m todos de desenvolvimento que tratam requisitos de aplica es Web t m sido propostos na literatura t cnica Revis es sistem ticas da literatura KITCHENHAM 2004 baseiam se em uma estrat gia de pesquisa bem definida com o objetivo de selecionar o m ximo de material bibliogr fico relevante sobre um tema O protocolo da revis o sistem tica um documento que especifica a quest o central da pesquisa e os m todos que ser o utilizados para executar a revis o Ele deve documentar a estrat gia de busca e definir de forma expl cita os crit rios de inclus o e exclus o para avaliar cada estudo prim rio potencial Assim o protocolo permite que leitores e outros pesquisadores possam conhecer seu grau de rigor e a completeza da revis o BIOLCHINI et al 2007 Uma revis o sistem tica prop e uma avalia o mais justa do t pico de pesquisa medida que utilza uma metodologia de revis o rigorosa confi vel e pass vel de auditagem KITCHENHAM 2004 A rev
76. ferramenta TDE UML quanto a abordagem de modelagem preconizada por ela s o efetivamente usadas em projetos reais dessa organiza o A Figura 6 1 apresenta o ciclo de uso completo das ferramentas previstas na abordagem proposta nesta tese relacionando esse uso com as atividades do processo de especifica o no qual a abordagem est inserida O uso das ferramentas acontece em quatro etapas 1 Etapa 1 nesta etapa o desenvolvedor usa a ferramenta UseCaseAgent para criar as especifica o dos casos de uso atrav s de diagramas de atividades aderentes ao metamodelo UCModel Tamb m nesta etapa as especifica es s o validadas segundo as restri es do UCModel Etapa 2 nessa etapa o analista de testes gera os modelos preliminares de testes a partir dos modelos de caso de uso criados na etapa anterior usando a ferramenta ModelT Esses modelos s o considerados preliminares porque ainda carecem de um conjunto de informa es que possibilite a gera o dos casos e procedimentos de teste Etapa 3 nesta etapa o analista de testes edita os modelos de teste com a ferramenta BOUML analisa os e insere as informa es faltantes ou altera informa es existentes para que o modelo esteja completo o suficiente para permitir a gera o dos casos e procedimentos de testes e Etapa 4 aqui o analista de testes usa a ferramenta TDE UML para gerar automaticamente os casos e procedimentos de teste a partir dos modelos de teste 13
77. individualmente e enviado para jobson cos ufrj br Suas respostas NAO ser o usadas para efeito de avalia o do curso e servem apenas para complementar o conjunto de informa es referentes s atividades envolvidas no processo de desenvolvimento de aplica es WEB Nome da Equipe que participou 1 Durante o projeto indique aqueles que voc ajudou a construir ou revisar O n o constru revisei 1 Apenas revisei 2 Apenas construi 3 Construi e Revisei Diagrama Diagrama de Diagrama de Diagrama de Mapa de Modelo de classes sequ ncia estado atividades atores navegacional 2 Nasua percep o qual foi o esfor o para cria o desses modelos A alto M m dio B baixo Diagrama Diagrama de Diagrama de Diagrama de Mapa de Modelo de classes sequ ncia estado atividades atores navegacional 3 No seu entendimento indique na tabela 3 fatores que trouxeram mais dificuldades na constru o de cada um dos modelos Utilize a lista abaixo como roteiro inicial Acrescente outros se desejar ou tenha percebido no desenvolvimento do trabalho A Treinamento exemplos qualidade do material disponibilizado etc B Complexidade do sistema dificuldade de entendimento do dom nio C Documento de especifica o documenta o confusa e ou inadequada D Falta de experi ncia na cria o do modelo E Ferramenta case componentes inadequados para constru o
78. inv s de descrever toda a complexidade da estrutura ou do comportamento dentro do pr prio caso de USO e Use diagramas de atividades para explicitar comportamento complexos ao inv s de defini los usando linguagem natural e Na descri o das a es O O Indique sempre quem faz o qu Inicie sempre indicando quem realiza a a o Sistema ou Ator Use sempre verbos no presente e na voz ativa N o use comandos de controle de fluxo do tipo se ent o ou enquanto fa a Refatore esses desvios como fluxos alternativos ou de exce o e N o junte diversas a es do sistema em um nico passo Exemplo O Sistema calcula o valor da compra e o frete e os apresenta ao cliente deve ser descrito como 1 O Sistema calcula o valor da compra e o frete 2 O Sistema apresenta o valor da compra e o frete ao cliente Por qu o Regras diferentes podem estar associadas a uma ou outra a o o Alternativas ou exce es diferentes podem estar associados a uma ou outra a o o Dados complementares das a es podem ser diferentes o A natureza das duas a es pode ser diferente Nesse exemplo uma representa um comportamento interno do sistema e outra representa uma interface HC com o ator 222 A 19 Mensagens de Erro A 19 1 Mensagens de Erro na Verifica o de Diagramas Essa verifica o realizada quando o mesmo editado ou transformado e tem o objetivo de gar
79. metamodelo que representa os requisitos de aplica es Web sob duas ticas comportamental e estrutural Os estere tipos para classifica o dos requisitos nessas duas vis es s o apresentados na Tabela 3 3 Tabela 3 3 Estere tipos do metamodelo do WebRE Vis o UML WebRE Defini o Comportamental Caso de uso Navigation Modelo casos de uso que possuem somente navega o ou seja a es do tipo Browse e Search WebProcess Modela casos de uso que possuem transa es A o Browse Modela o acionamento de um link Search Modela uma consulta realizada pelo ator User Transaction Modela uma transa o iniciada pelo ator Ator WebUser Ator que interage com a aplica o Estrutural Classe Node Unidades de informa o com as quais o usu rio interage Content Informa es manipuladas 46 pelo sistema WebUIl P ginas que s o apresentadas ao usu rio Podem conter v rios Nodes Casos de uso s o representados graficamente atrav s de diagramas de atividades onde s o aplicados os estere tipos Browse Search e User Transaction Tabela 3 3 Os insumos e produtos das a es nesse diagrama s o estereotipados como Content A partir desses modelos s o aplicadas transforma es para gera o do Modelo de Conte do ou Modelo de Dom nio e do Modelo Navegacional no padr o definido pelo m todo UWE Casos de uso tamb m podem ser representados textua
80. mostra adequado para representar esses conceitos Com rela o aos eventos que podem ocorrer no escopo do sistema estes devem ser representados em modelos comportamentais que capturem os efeitos da ocorr ncia desses eventos nos demais conceitos Na UML as m quinas de estado OMG 2010a se apresentam como um mecanismo adequado para capturar essa din mica pois representam de forma nativa os conceitos de eventos transi es e estados Por outro lado processos descritos nos requisitos podem ser representados atrav s da sequ ncia de a es que os comp em dos insumos e produtos dessas a es e dos respons veis pelas mesmas Nesse caso o diagrama de atividades da UML OMG 2010a possui construtores capazes de representar os fluxos de controle e dados existentes nesses processos Por exemplo o texto a seguir apresenta a din mica de um processo de promo o de funcion rios no contexto de uma organiza o 68 Para promover um funcion rio o seu coordenador deve abrir um processo de solicita o de movimenta o de pessoal junto ao departamento de RH Essa solicita o ser avaliada e pode ser indeferida se n o estiver de acordo com um conjunto de regras ou enviada para aprecia o da ger ncia s nior da respectiva rea Nessa segunda avalia o a solicita o pode ser reprovada ou aprovada em definitivo Caso seja aprovada o setor de RH realiza as altera es necess rias no registro do funcion rio e encerra a solicita
81. nessa decis o Sistema solicita tipo da opera o Ator seleciona opera o opera o dep sito Figura A 19 Interpreta o de uma decis o ap s uma a o do ator 2 Uma decis o ap s uma resposta do sistema como a resposta do sistema apresenta o resultado de um processamento e ou a solicita o de uma nova informa o a decis o interpretada como uma atitude do ator diferente daquela esperada solicitada pelo sistema Nesse caso a condi o define a a o tomada pelo ator Sistema solicita login e senha Ator seleciona op o de esqueci a senha Sistema solicita login Ator informa login e senha Figura A 20 Interpreta o de uma decis o ap s uma resposta do sistema 3 Uma decis o ap s uma a o do sistema representa alternativas de resposta do sistema ou de processamento em fun o do resultado do processamento de uma informa o Nesse caso a condi o normalmente verifica o resultado do processamento realizado ou o estado do sistema 219 Sistema solicita login e senha Ator fornece login e senha Sistema valida login e senha Sistema informa login ou Login ou senha inv lidos senha inv lido Sistema apresenta menu Figura A 21 Interpreta o de uma decis o ap s uma a o do sistema A 18 Orienta es para Descri o de Casos de Uso Um Caso de Uso deve e Atingir um nico significativo e bem definido resultado de interesse
82. nos ultimos AN 30 dias lt lt business_rule gt gt BR2 obrigat rio que o frete calcula o valor do pedido seja gratuito se o valor do pedido for maior que lt lt system_action gt gt 500 00 valida a quantidade do item lt lt business rule gt gt BR3 obrigat rio que o frete seja calculado como o peso total do pedido x valor por kilo apresenta o valor do pedido lt lt business_rule gt gt BR4 E obrigat rio que o frete A1 lt lt system_response gt gt tenha um desconto de 20 se o destino da y g entrega for uma capital do sul sudeste altera do item lt lt business_rule gt gt BR5 obrigat rio que o frete lt lt system_action gt gt h j i ae dignos tenha um desconto e 50 se o cliente for vip lt lt actor action gt valida os dados de pagamento lt lt system action gt gt gera o pedido lt lt svstem action gt gt apresenta o n mero do pedido lt lt system response gt gt Figura 4 7 Diagrama de atividades com a especifica o do caso de uso Concluir compra 85 Calcular valor do pedido carrinho lt lt conceptual_rule gt gt BR3 E Calcular valor pedido lt lt conceptual_rule gt gt BR2 E obrigat rio que o frete seja obrigat rio que o frete seja calculado como o peso total do ciente O gratuito se o valor do pedido poco x vakir por Mio valor_pedido for maior que 500 00 carrinho lt lt conceptual_rule gt gt BR1
83. o que j era de certa forma esperado haja vista o seu papel de destaque no desenvolvimento de software OO Os participantes puderam perceber a grande import ncia de construir esse modelo Tabela 2 9 mas relataram uma percep o de esfor o alta com vi s para m dia talvez influenciada pela falta de experi ncia dos participantes j que a aplica o n o tinha alta complexidade Essa dificuldade tamb m pode estar relacionada com o entendimento do paradigma OO pois alguns participantes dos estudos 2 e 3 relataram certa confus o entre os paradigmas OO e os modelos ER Entidades Relacionamentos A divis o das tarefas tamb m foi apontada como um fator que trouxe dificuldades no uso desse modelo j que ela 26 levou divis o da especifica o em casos de uso que foram tratados individualmente pelos desenvolvedores que por sua vez perderam a vis o geral do dom nio necess ria para constru o e evolu o do modelo O reflexo disso foi que muitos participantes apontaram as reuni es presenciais como um instrumento para mitigar esse risco Outro ponto levantado foi a dificuldade de criar o modelo conceitual de classes pois a vis o dos casos de uso n o proporcionava uma vis o geral dos processos de neg cio Da surgiram algumas sugest es no sentido aprimorar o documento de especifica o a fim de incorporar essa informa o Diagrama de Sequ ncia Esse modelo tamb m foi bastante explorado pelos desenvolvedores po
84. o associadas vis o estrutural devendo portanto serem representadas atrav s de um modelo de classes Tabela 4 1 p gina 60 Por outro lado as regras R10 a R12 da Tabela 4 6 referem se ao comportamento esperado para o tratamento da entidade licen a sendo indicado o uso de uma m quina de estados ou diagrama de atividades OMG 2010a para representa o dessas regras em alternativa representa o em linguagem natural estruturada Tabela 4 1 p gina 60 Regras comportamentais tamb m podem estabelecer restri es ou detalhar procedimentos acerca de processos ou funcionalidades do sistema Regras desse tipo devem estar associadas aos contextos em que atuam para que seja poss vel interpret las e trat las com risco m nimo de m interpreta o Para as regras R7 a R12 Tabela 4 6 os poss veis contextos s o exemplificados na Tabela 4 7 Tabela 4 7 Regras comportamentais e poss veis contextos de atua o Regra Poss veis contextos R7 proibido que um coordenador e C lculo dos vencimentos dos receba gratifica o se estiver professores licenciado e C lculo dos vencimentos dos funcion rios R8 proibido que um professor seja e Avalia o de candidatos coordenador se ele lecionar mais de coordena o duas disciplinas R9 proibido que um professor e Solicita o de licen a solicite licen a para outro professor R10 obrigat rio que o estado de uma licen a sej
85. o n mero do boleto esteja de acordo com a especifica o da se o 3 do documento de refer ncia NR E obrigat rio que seja apresentado o valor do boleto contido no n mero do boleto se o n mero contiver o valor BR5 E obrigat rio que a data de pagamento seja maior ou igual a data 147 corrente BR6 E obrigat rio que o valor do desconto seja menor que o valor do boleto BR7 obrigat rio que o valor dos juros seja fornecido se a data de pagamento for menor que a data corrente BR8 Valor a ser pago valor do boleto desconto juros BRO9 E obrigat rio que o valor a ser pago seja maor que zero BR11 E obrigat rio que a senha fornecida seja id ntica a senha do cart o cadastrada no sistema NR10 E obrigat rio que o sistema apresente uma mensagem de erro para cada dado que esteja incorreto Figura 6 12 Representa o em formato texto da especifica o do caso de uso Pagar boleto banc rio A combina o das funcionalidades da ferramenta UseCaseAgent com um editor de diagramas de atividades nesse caso a ferramenta BOUML oferece aos desenvolvedores tr s op es para especifica o dos casos de uso e Cria o edi o das especifica es usando somente a ferramenta BOUML ou seja o caso de uso manipulado somente graficamente atrav s do diagrama de atividades e Cria o edi o das especifica es de casos de uso usando somente a UseCaseAgent ou seja o caso de uso manipulado usando
86. objetivo de caracterizar tais m todos possibilitou observar um conjunto de caracter sticas comuns e Os m todos apontam para a necessidade de capturar e representar perspectivas de projeto relevantes no contexto do desenvolvimento de aplica es Web com destaque para as perspectivas de conceitua o representa o de elementos conceituais relacionados ao dom nio do problema apresenta o representa o de caracter sticas relativas interface com o usu rio e navega o representa o de caracter sticas relativas explora o da informa o de forma n o linear e O paradigma da orienta o a objetos o mais explorado pelos m todos e Os m todos t m procurado explorar modelos para representar as perspectivas de projeto e e As preocupa es com qualidade ou inexistem ou reaproveitam t cnicas exploradas no contexto das aplica es convencionais sem a adapta o dessas t cnicas s particularidades das aplica es Web Um estudo comparativo realizado anteriormente por ESCALONA e KOCH 2004 com 10 m todos Web complementada por uma revis o da literatura conduzida no escopo desta pesquisa com outros 14 m todos Web sobre o tratamento dispensado aos requisitos funcionais nesses m todos acrescenta mais algumas caracter sticas a essa lista 3A palavra m todo aqui usada no sentido de um procedimento organizado com o objetivo de conduzir a um determinado resultado Como os autores dos diverso
87. para refletir esse novo metamodelo A avalia o do arcabou o para gera o de casos e procedimentos de testes funcionais poderia ser replicada nesse novo contexto T cnicas de Inspe o Defini o ou adapta o de t cnicas de inspe o alinhadas aos conceitos definidos na abordagem e que possam explorar os elementos que a comp em modelos de especifica o de casos de uso modelos conceituais regras dentre outras Tratamento de requisitos n o funcionais A especifica o de requisitos n o funcionais como caracter sticas relacionadas a ubiquidade no escopo da abordagem proposta requer uma avalia o do impacto da incorpora o desses novos requisitos nos conceitos nos quais a abordagem se ap ia A partir dessa avalia o ser poss vel definir mecanismos que permitam a especifica o desse tipo de requisito luz dos conceitos j existentes ou a adapta o da abordagem de acordo com esse novo contexto de atua o Para finalizar entendemos que a abordagem proposta nesta tese visa contribuir com os avan os e com o corpo de conhecimento relacionado Engenharia de Aplica es Web no que diz respeito ao desenvolvimento de aplica es Assim esta pesquisa vai ao encontro dos avan os j realizados nessa rea e procura oferecer uma solu o relacionada ao tratamento de requisitos que esteja alinhada com os conceitos que permeiam os m todos de desenvolvimento Web propostos na literatura t cnica e nos quais f
88. prot tipo avaliado Diagrama de cen rios define os cen rios que ser o executados pelos clientes juntamente com os dados usados nessa execu o e Diagrama Navegacional representado por diagramas de atividades que representam a sequ ncia de invoca o dos servi os e quem pode acess los Nesse caso cada a o corresponde a um servi o os fluxos de controle representam os links entre esses servi os e as raias representam os atores que podem acessar esses servi os 3 2 3 23 Desenvolvimento Web por Usu rios Finais DE SILVA et al 2009 prop em uma abordagem iterativa baseada em casos de uso que permite o envolvimento dos usu rios finais na especifica o da aplica o e a sua gera o semi autom tica a partir dessa especifica o A especifica o da aplica o constru da a partir da especifica o dos casos de uso da defini o do 51 modelo de objetos modelo do dom nio e do desenho da interface com o usu rio Uma ferramenta ap ia todo esse processo A especifica o e a gera o da aplica o s o apoiadas por um framework que estende um conjunto de componentes chamado CBEADS Component Based E Application Development and Deployment Shell O metamodelo criado com a extens o do CBEADS tenta reaproveitar conceitos que s o comuns a um conjunto de dom nios e define uma estrutura a partir da qual a aplica o pode ser especificada referenciando diretamente esses conceitos e suas caracter
89. qual somente uma das equipes estava apta importante ressaltar tamb m que apesar de conhecer o dom nio esta equipe ainda n o havia modelado essa aplica o utilizando os conceitos solicitados no estudo e Mudan a das ferramentas o uso de tr s ferramentas diferentes nos tr s estudos relatados pode ter influenciado nos resultados devido eventuais facilidades ou dificuldades proporcionadas por essas ferramentas Por outro lado as tr s ferramentas utilizadas seguem o padr o de interface normalmente adotado nesse tipo de aplica o como barra de ferramentas apresentada de acordo com o tipo do diagrama janelas pop up para edi o das propriedades dos elementos drag and drop de elementos gr ficos dentre outros Adicionalmente nos tr s estudos conduzidos os participantes tiveram tempo considerado suficiente para mitigar quest es relacionadas ao aprendizado dessas ferramentas minimizando esse efeito no resultado final e Medi o da experi ncia dos participantes a classifica o da experi ncia foi feita inicialmente pelos pr prios participantes utilizando um question rio que continha perguntas gerais sobre experi ncia em desenvolvimento tanto no meio acad mico quanto industrial e perguntas mais espec ficas sobre modelagem Entretanto os pesquisadores se reuniram posteriormente e analisaram essas classifica es levando em conta suas observa es acerca desses indiv duos durante a disciplina assiduidade particip
90. quando o valor de a2 sim e vai seguir pelo fluxo normal quando valor de a2 n o 154 TC001 Pagar boleto banc rio lt lt precondition gt gt lt lt postcondition gt gt Cliente devera estar aut nticado no sistema de home banking Cliente obt m o comprovante de pagamento do boleto solicita a fonte de recurso de onde ser debitado o pagamento lt lt system response gt gt informa que deve ser selecionada uma op o seleciona uma das op es lt lt actor action gt gt lt lt system_response gt gt Al opcao inv lida solicita o n mero do boleto lt lt system_response gt gt informa que o n mero do boleto inv lido lt lt system_response gt gt digita o n mero do boleto lt lt actor action gt A3 n mero do boleto inv lido A4 data de vencimento menor que a dai atual e o boleto foi emitido por out nco informa que n o possivel nd a ao pagamento pagar um boleto de outro lt lt system_response gt gt banco ap s o vencimento lt lt system response gt gt e 3 2 lt lt navigation_rule gt gt NR3 obrigat rio que seja apresentado o valor do boleto contido no n mero do boleto se o n mero contiver o valor informa os dados do pagamento lt lt actor action gt gt AT lt lt system_response gt gt senha inv lida na 3a tentativa informa que a senha inv lida e que encontra se bloqueada a senha actio
91. s o definidas pelo SWEBOK s o tratadas como uma nica atividade denominada Especifica o Adicionalmente as preocupa es relativas qualidade do produto levaram inclus o de uma atividade relacionada ao planejamento de casos e procedimentos de testes funcionais ao final das atividades de engenharia de requisitos Assim o processo organizado neste trabalho adota os conceitos preconizados pelo modelo V que promove o planejamento antecipado dos testes O diagrama de atividades da Figura 4 2 apresenta uma vis o geral do processo organizado para especifica o dos requisitos destacando em cinza as atividades e artefatos que fazem parte do escopo da abordagem proposta neste trabalho Essas atividades podem ser definidas como e Especifica o de requisitos a atividade que analisa classifica organiza e documenta os requisitos coletados A t cnica adotada para especifica o baseia se principalmente em modelos conceituais para representar os aspectos estruturais e comportamentais relacionados ao dom nio do problema e em modelos de casos de uso para representar os aspectos comportamentais do sistema JACOBSON et al 1992 A se o 4 5 discute com mais detalhes essa atividade e os seus artefatos e Valida o de requisitos a atividade respons vel por tentar garantir que n o existem defeitos no documento de requisitos gerado na especifica o A se o 4 6 examina com mais detalhes essa atividade e Gera o de
92. sint tica revis o com apoio ferramental e semanticamente inspe es e e Apoiar a garantia da qualidade do produto final atrav s da gera o semi autom tica de casos e procedimentos de testes funcionais O metamodelo UCModel foi definido como uma extens o do metamodelo da UML OMG 2010a especializando parte dos conceitos relacionados ao diagrama de atividades para capturar tanto as informa es b sicas acerca dos casos de uso quanto os fluxos das a es que descrevem o seu comportamento Este cap tulo apresenta o metamodelo UCModel e os princ pios que orientaram a sua cria o S o detalhados os elementos que comp em o UCModel as extens es do metamodelo da UML usadas para defini los e as restri es que possibilitam a estrutura o das descri es dos casos de uso segundo os crit rios e princ pios desse metamodelo 5 2 Diagrama de Atividades e Casos de Uso O Diagrama de Atividades um dos diagramas comportamentais propostos pela UML 2 OMG 2010a Diagramas de atividades descrevem comportamentos a partir de uma sequ ncia de a es chamada de fluxo de controle Os comportamentos representados podem estar em diversos n veis de abstra o sendo poss vel modelar desde processos de neg cio e procedimentos relacionados regras de neg cio at algoritmos e opera es que devem ser efetivamente implementadas em um sistema A partir da especifica o da UML 2 0 os diagramas de atividades passaram a trab
93. somente o formato textual e e Cria o edi o das especifica es usando uma abordagem h brida onde o caso de uso pode ser manipulado tanto no formato texto UseCaseAgent quanto no formato gr fico BOUML A princ pio a prefer ncia do desenvolvedor e a sua habilidade e familiariza o com uma ou outra abordagem que v o determinar a op o a seguir Duas caracter sticas comuns que acompanham essas tr s op es s o e Sempre poss vel gerar a especifica o do caso de uso no formato texto o que pode ser til ao lidar com stakeholders ou at desenvolvedores n o familiarizados com a sintaxe e a sem ntica dos diagramas de atividades e e O metamodelo UCModel a base de apoio da especifica o do caso de uso independente do formato em que ela se materialize Outro recurso dispon vel a possibilidade de usar a ferramenta UseCaseAgent para criar as especifica es dos casos de uso em modo texto e posteriormente gerar essas especifica es tamb m em modo texto Nesse caso em momento algum o desenvolvedor ou outros stakeholders tratam diretamente os diagramas de atividades apesar da sua exist ncia apoiar a cria o e verifica o da especifica o Essa 148 flexibilidade pode ser til ao lidar com stakeholders n o familiarizados com a sintaxe e a sem ntica dos diagramas de atividades ou mesmo ser utilizada por desenvolvedores que preferem trabalhar com o estilo textual de representa o 6 2
94. teste e destacando os pontos onde ela se faz necess ria Nesse 160 sentido o mapeamento realizado entre o metamodelo UCModel e o metamodelo TDE pode servir como ponto de partida para que outras abordagens MBT possam se valer da UCModel para gera o de informa es relevantes para os testes funcionais 6 4 Conclus o O objetivo principal da infra estrutura computacional organizada no escopo deste trabalho oferecer apoio especifica o dos casos de uso descritos como diagramas de atividades baseados na UCModel e gera o de casos e procedimentos de teste duas atividades que fazem parte da abordagem proposta Para tal foram implementadas duas ferramentas chamadas UseCaseAgent e ModelT A concep o dessas ferramentas procurou levar em considera o a organiza o de um ambiente de trabalho no qual o desenvolvedor tivesse acesso s v rias funcionalidades oferecidas pelas ferramentas da forma mais transparente poss vel minimizando a necessidade de transfer ncia de informa es diagramas entre as diversas ferramentas que comp em a infra estrutura proposta Por isso ambas as ferramentas foram implementadas como plug ins da ferramenta BOUML PAGES 2011 o que possibilita a explora o das funcionalidades oferecidas por essas ferramentas dentro do mesmo ambiente de trabalho A gera o de casos e procedimentos de testes e a ferramenta ModelT n o foram alvos de uma avalia o experimental no escopo desse trabalho A
95. todo que contem os dados retirados do modelo conceitual a serem tratados nesse ponto Os links entre os n s do modelo navegacional s o definidos a partir dos fluxos de controle existentes no diagrama de atividades O comportamento do sistema implementado a partir dos servi os do caso de uso explorando o conceito e web services como prev a metodologia ou atrav s de outra tecnologia A partir dos artigos analisados n o foi poss vel observar atividades de valida o dos modelos ou relacionadas garantia da qualidade do produto 47 3 2 3 17 Modelagem de Aplica es Orientadas a Dados A metodologia proposta por ADAMK 2006 voltada para a modelagem de aplica es de pequeno e m dio porte como afirma o pr prio autor orientadas a dados O desenvolvimento tem in cio com a an lise do dom nio e a constru o de casos de uso que s o detalhados atrav s de diagramas de atividades A partir desses elementos s o constru dos os modelo estruturais ou seja modelos de classes que definem as entidades a serem tratadas no contexto da aplica o O modelo navegacional constru do a partir das classes do modelo estrutural e posteriormente decorado com componentes de navega o index query e menu Nesse caso o modelo navegacional adotado bastante semelhante ao usado no m todos UWE HENNICKER e KOCH 2000 A partir desses modelos ser o gerados o esquema do banco de dados e as p ginas Web descritas segundo a tecno
96. um novo caso de uso se aplicam sua edi o A 14 Impress o dos Casos de Uso A vers o atual do UseCaseAgent permite a gera o de um documento em formato RTF com a descri o textual dos casos de uso existentes Para tal basta acionar no BOUML o menu de contexto no pacote lt lt uc model gt gt e selecionar Tool gt Print Use Cases conforme a Figura A 14 m A Freeware Bouml C JOBSON Doutor jetos UCModel TestesUseCaseAgent template template j Project Windows Tools Languages Miscellaneous Help CA ERKL browser E template E Je lt actors gt gt actors Jeuse cases gt use cases New package 8 Je lt use cases descriptions gt gt use cases descriptions New use case view G Pgjuse cases descriptions E lt c lt use case description gt gt UC001 Autenticagao lt lt domain model gt gt domain model New component view a este modeb gt test case model New deployment view Jestest cases descriptions gt gt test cases descriptions JProfileuCcModel JProfilercmodel package use case model New class view HTML documentation HTML doc flat HTML doc svg HTML doc flat svg New profile Import project Import project as library Edit E Global Change Edit class settings E Uml projection Edit drawing settings Import Rose Delete Import XMI 21 Referenced by Ched Mark Check out Force stereotype consistency Create UCModel
97. uma ferramenta propriet ria denominada TDE UML O processo de gera o dos casos e procedimentos de testes funcionais a partir das especifica es de casso de uso realizado em 3 etapas distintas 1 Deriva o do modelo preliminar de testes ocorre ap s a especifica o e valida o da especifica o e produz um modelo preliminar de testes representado como um diagrama de atividades da UML2 OMG 2010a e descrito de acordo com o metamodelo TDE Este modelo chamado de preliminar porque neste momento existem lacunas no modelo que correspondem aquelas informa es relevantes no contexto do teste funcional mas que n o puderam ser extra das diretamente da especifica o de casos de uso devido a diferen as conceituais entre esses dois modelos 2 Edi o do modelo de testes nesta atividade os modelos gerados na atividade anterior s o editados e complementados com um conjunto de 89 informa es que s o relevantes apenas no contexto de teste como por exemplo a defini o de classes de valores a serem aplicados durante a execu o dos testes A complementa o do modelo de testes necess ria porque o modelo de casos de uso trata de conceitos abstratos enquanto o modelo de testes lida com valores concretos associados a esses conceitos para que o comportamento do sistema possa ser avaliado a partir destes valores Para auxiliar o analista de testes nessa tarefa o modelo preliminar de testes incrementado com uma s
98. uma tarefa fundamental para produzir solu es que reflitam os procedimentos e restri es do ambiente nas quais estas est o inseridas Assim a especifica o de tais regras em termos de elementos no espa o da solu o computacional merece aten o especial no contexto geral da especifica o de requisitos funcionais Com rela o aos casos de uso tais regras afetam diretamente o comportamento do sistema restringindo o ou detalhando o Frequentemente regras de neg cio dom nio t m sido especificadas juntamente com requisitos funcionais de uma forma indistinta Entretanto algumas diferen as fundamentais separam esses dois conceitos conforme exemplificado na Tabela 4 4 Tabela 4 4 Algumas diferen as entre Requisitos Funcionais e Regras de Neg cio Requisitos Funcionais Regras de Neg cio Descrevem as funcionalidades ou Descrevem pol ticas procedimentos ou capacidades do sistema restri es organizacionais Definem o comportamento do sistema Definem o comportamento da organiza o Est o limitados ao escopo do sistema Transcendem o escopo do sistema Devem ser garantidos pelo sistema Podem ser garantidas sem a necessidade de sistema algum Podem ser representados como casos Podem restringir o comportamento de uso descrito nos casos de uso A separa o desses conceitos e a visualiza o clara do conjunto de regras de neg cio envolvido podem trazer algumas vantagens e O trabalho de W
99. uso Criticalidade Um classifica o de acordo com uma escala ordinal do qu o cr tico esse caso de uso para a organiza o Essa caracteriza o visa apoiar o gerenciamento das atividades relacionadas garantia da qualidade como prioriza o de inspe es ou aplica o de crit rios de parada de inspe es e testes Frequ ncia de Um classifica o de acordo com uma escala ordinal da uso frequ ncia de utiliza o do caso de uso para a organiza o Essa caracteriza o tamb m visa apoiar o gerenciamento das atividades relacionadas garantia da qualidade Pr condi es Uma descri o textual das condi es que devem ser satisfeitas para que o caso de uso se inicie Deve ser usada em casos de uso cuja execu o n o faz sentido em qualquer momento mas somente quando o sistema est em determinado estado ou quando determinada condi o for satisfeita P s condi es Uma descri o textual do estado que o sistema alcan a ou do pr prio resultado observ vel ap s o caso de uso ter sido executado com sucesso Trigger Uma descri o textual dos eventos ou a es que iniciam o caso de uso Fluxo principal Uma sequ ncia de passos numerados que descreve a sequ ncia de a es que ser o executadas considerando que nada de errado acontecer durante essa execu o Representa o caminho mais comum ou o cen rio ideal para que o ator atinja o seu objetivo Fluxos Uma sequ ncia de passo
100. verificar a ader ncia do documento ao gabarito proposto e e Facilitar a comunica o entre membros da equipe e os demais interessados Entretanto embora seja importante a defini o de um padr o a sua ado o n o nos permite explorar cen rios mais proeminentes tais como e A organiza o de um apoio adequado especifica o dos casos de uso e A organiza o de um apoio semi automatizado avalia o da qualidade dos casos de uso 83 e Transforma es modelo modelo ou modelo texto visando apoiar as fases subsequentes do desenvolvimento que usam as informa es contidas no documento de especifica o dos casos de uso O problema reside na pouca formaliza o da sem ntica dos elementos usados na descri o do caso de uso A ado o de gabaritos para descri o de casos de uso mesmo acompanhada de orienta es para reda o dos mesmos n o permite a organiza o de um apoio computacional que explore o processamento das informa es existentes no caso de uso limitando a sua utiliza o como simples ve culos de comunica o entre os membros da equipe e os demais interessados WILLIAMS et al 2005 Visando aprimorar o grau de formaliza o das descri es dos casos de uso um metamodelo para descri o de casos de uso denominado UCModel foi definido no contexto deste trabalho Este metamodelo estende o diagrama de atividades da UML OMG 2010a e acrescenta novos elementos para descri o d
101. 007 UWE HENNICKER e KOCH 2000 KOCH e KRAUS 2002 KOCH et al 2006 PRECIADO et al 2008 W2000 BARESI et al 2001 BARESI et al 2002 BARESI e MAINETTI 2006 e NDT ESCALONA et al 2003 ESCALONA et al 2007 e Requisitos de dados tamb m chamados requisitos de armazenamento ou requisitos conceituais determinam como a informa o dever ser estruturada e Requisitos de apresenta o ou intera o determinam a estrutura e o comportamento da interface da aplica o durante a intera o com o usu rio e Requisitos de navega o determinam as necessidades de explora o da informa o e Requisitos de adapta o personaliza o ou customiza o descrevem como a aplica o dever se adaptar dinamicamente ao usu rio ou ao ambiente e Requisitos de transa o tamb m chamados de requisitos de servi o determinam como ocorrer o processamento dos dados sem levar em conta os aspectos de intera o com os usu rios A abordagem proposta neste trabalho prev a classifica o dos requisitos elicitados conforme as perspectivas de projeto Web e as vis es estrutural e comportamental da modelagem Essa classifica o visa definir um foco para o requisito e a partir desse foco e Analisar e refatorar o requisito de acordo com esses conceitos e Permitir uma vis o mais clara sobre quais modelos de projeto ser o impactados pelo requisito e Fornecer um foco de leitura bem definido minimizando ambig idades
102. 01 An Empirical Methodology for Introducing Software Processes Proceedings of the Joint 8 European Software Engineering Conference ESEC and 9 ACM SIGSOFT Symposium on the Foundations of Software Engineering FSE 9 pp 288 296 SOME S 2006 Supporting use case based requirements engineering Journal of Information and Software Technology n 48 pp 43 58 SOME S 2009 A Meta Model for Textual Use Case Description Journal of Object Technology v 8 n 7 pp 87 106 SOMMERVILE 2006 Software Engineering Addison Wesley ISBN 978 0 321 31379 9 8a edi o SOUSA G SOARES S BORBA P CASTRO J 2004 Separation of Crosscutting Concerns from Requirements to Design Adapting an Use Case Driven Approach Early Aspects 2004 Aspect Oriented Requirements Engineering and Architecture Design Workshop at International Conference on Aspect Oriented Software Development AOSD 04 pp 93 102 TRAVASSOS G H SANTOS P S M D MIAN P G DIAS NETO A C BIOLCHINI J C D A 2008 An Environment to Support Large Scale Experimentation in Software Engineering Proceedings of the 13 IEEE International Conference on Engineering of Complex Computer Systems ICECCS 08 pp 193 202 TRAVASSOS G H SHULL F FREDERICKS M BASILI V 1999 Detecting defects in object oriented designs using reading techniques to increase software quality ACM SIGPLAN Notices v 34 n 10 pp
103. 1 8 Conclus o e Trabalhos Futuros 03 2 ccseicescsdeceediscsiees ced eteeasnnatenacedeneetsncaensennees 183 8 1 Considera es Finais caca asias ines Gana SE Ga aids Cu Saad 183 8 2 Contribui es da Pesquisa seia asiicoscstantraeer fitness fontacig ds imanal potes ent diicacaggaL 183 8 3 IMAC OCS pps RDPI NUR SRP RUDE PNR MORE PERA RDROS a AA RAD PP 185 8 4 Quest es em AberO us sicairpinesaasala a ind nua aiaca teeta een 185 8 5 Trabalhos FUtUIOS sas 224 cas auasres Gees rasa ivesvade lewd ea aiaa ch E pal EEE R REEE amassada 186 REFER NCIAS BIBLIOGR FICAS cccccssecessecesesesseseseeessesesseeessesessneeseneasaeees 188 AP NDICE A Manual do Usu rio do UseCaseAgent eee 201 A 1 Ta igts 8 e7 Ve hea erence NR een eae aes ere BS aE nor ee A A EN 201 AZ Por gue BOW Mes 2 re e ee nara dias tanec EE at ANE 202 AS Instala o e Configura o vrs seca ceiveeteesrbaies repented Ore peso a passed 202 AA Cria o dos Atores ea ccs cetecc ceed teeecel cease ses siena eneeveabistieestenereeadenieee ears 203 A 5 Cria o de um Caso de USO sisi cccceiscshsceecsnesthl aelavieastieoradeieae rac ecnlanehers 204 A 6 Dados Gerais do Caso de Uso aaa 207 A T Atores do Caso de SO ads ct LD Lag en 208 A8 Fl xo Principal et conse ca et aeee a aaee no dao sea aa da 208 AD Fl xos Alternativos occa cise mando tata acts tage ND O dada DOU oe oe aac ag seed nad 211 A110 Fl xos de Exce o enano ana st
104. 2 7 Inspe o id UseCaseAgent ae UCModel 4 a I E Diagramas criados pelo UseCaseAgent Relatos de l Defeitos I a l I l Diagramas criados Relatos de BOUML l pelo desenvolvedor Defeitos pA ProfileUCModel I _ _ os s athod Inspe o a O o cebo A l I ae Figura 7 1 Vis o geral dos estudos de avalia o As se es 7 2 e 7 3 relatam os dois estudos detalhando os objetivos contexto planejamento execu o e an lise dos dados A se o 7 4 discute as amea as validade levando em considera o a combina o dos dois estudos Finalmente a se o 7 5 apresenta a conclus o com um breve resumo dos resultados obtidos 163 7 2 Primeiro Estudo 7 2 1 Objetivo O objetivo do primeiro estudo pode ser formalizado usando o paradigma GQM BASILI e ROMBACH 1998 como Analisar a ferramenta UseCaseAgent doravante denominada UCA e um editor comum de diagrama de atividades doravante denominado EDA com o prop sito de caracterizar com respeito ao tempo gasto na constru o de diagramas de atividades do ponto de vista dos engenheiros de software no contexto da constru o de casos de uso do m dulo financeiro de um sistema de informa o Web de larga escala por desenvolvedores pertencentes equipe do projeto 7 2 2 Sele o do Contexto A sele o dos casos de uso foi realizada por conveni ncia a partir do documento de requisitos fu
105. 2 9 Distribui o de import ncia percebida pelos participantes por diagrama 24 Tabela 2 10 Fatores de dificuldade apontados pelos participantes 25 Tabela 3 1 Resumo da execu o da revis o da literatura eseeeeeeeeeeeeeeeeeeeees 38 Tabela 3 2 Distribui o dos 21 artigos aprovados pelos m todos Web 38 Tabela 3 3 Estere tipos do metamodelo do WebRE sseseeeeseesseeeeeeeeeeeees 46 Tabela 3 4 Resumo dos m todos Web analiSadOS sesseseeesseeseeeeeeeseeeeeeees 53 Tabela 4 1 Artefatos para representa o dos requisitos na perspectiva de CONCONA O asas era rafa tonal aura a o Ro Mae Su a raca nee toe nai cmo 60 Tabela 4 2 Artefatos para representa o dos requisitos na perspectiva de navega o BOATENG te tte in RDPI PRN SRD WISE Nes Sak SN RE RENO hoes Sach DO RR ee aah Soba ORNE DREAMER E 61 Tabela 4 3 Artefatos para representa o dos requisitos na perspectiva de UIE SO MAG A ai ae hE ath face ate eras Mak eae RO E ene duced Yan Meee ee Lee 2 61 Tabela 4 4 Algumas diferen as entre Requisitos Funcionais e Regras de Neg cio 72 Tabela 4 5 Sugest o para prefixa o de regras no SBVR OMG 2008 BOLLEM ZOUG EE NO PERDER DEDO PS RD E PE NERO PRN ORDER one oe ead RE DNS SEN ecole ED 73 Tabela 4 6 Exemplo de especifica o de regras conceituais segundo a SBVR 74 Tabela 4 7 Regras comportamentais e poss vei
106. 2 Trabalhos Relacionados A partir dos trabalhos apresentados no Cap tulo 5 que relatam abordagens para modelagem da especifica o de casos de uso foram analisadas as ferramentas que ap iam essas abordagens As se es a seguir descrevem um breve resumo de cada uma delas 6 2 2 1 SCORESTOOL SCORESTOOL KOSTER et al 2001 uma ferramenta que automatiza o m todo de modelagem do dom nio chamado SCORES que se baseia dentre outras caracter sticas no refinamento de casos de uso para especifica o do comportamento do sistema A especifica o dos casos de uso realizada atrav s de um diagrama de atividades A ferramenta n o trabalha com um metamodelo somente com um conjunto de estere tipos que define os tipos poss veis que uma a o do caso de uso pode assumir a o do sistema a o do ator e a o do ator fora do escopo do sistema N o realizado nenhum tipo de verifica o semi autom tica do diagrama de atividades produzido pois o processo de garantia da qualidade dos modelos produzidos totalmente manual 6 2 2 2 REM REquirements Manager A REM DURAN et al 2002 uma ferramenta para gerenciamento de requisitos que engloba a sua classifica o e especifica o Casos de uso s o classificados como requisitos do cliente e a sua especifica o apoiada por um metamodelo que classifica as a es em a o do ator ou a o do sistema A ferramenta REM tamb m utiliza a abordagem de formul rios para
107. 4 Cria o das classes de equival ncia senha1 com os valores valida e invalida 5 Cria o das classes de equival ncia erro1 com os valores 2 e 3 Esses valores s o usados para simular a senha invalida na 2 e 3 tentativas 6 Refatora o das express es de guarda associadas aos desvios para que estas refletissem as vari veis e valores definidos nas classes de equival ncia 156 TC001 Pagar boleto banc rio lt lt precondition gt gt Cliente devera estar aut nticado no sistema de home banking lt lt postcondition gt gt Cliente obt m o comprovante de pagamento do boleto lt lt conceptual rule gt BR1 obrigat ria a sele o de uma e apenas uma lt lt equivalence_class gt gt fonte de recurso e 1 opcao Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia op o inv lida Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia solicita a fonte de recurso de onde ser debitado o pagamento lt lt system response gt gt informa que deve ser selecionada uma op o seleciona uma das op es lt lt system_response gt gt lt lt actor_action gt gt lt lt conceptual_rule gt gt BR2 obrigat rio que o boleto seja emitido pelo banco se a data de vencimento for menor que a data corrente lt lt conceptual_rule gt gt BR4 E obrigat rio que o n
108. 5 Especifica o Gera o de Casos e Procedimentos de Testes Funcionais Especifica o e Iverifica ol Qualidade do verifica o sint tica sem ntica produto UseCaseAgent ModelT2 BOUML TDE UML m perme J Model amp sw ss 1 2 3 I Modelo ii de Modelo de testes Modelo de testes UCModai preliminar TCModel Casos e TCModel procedimentos de teste Figura 6 1 Ciclo de uso das ferramentas previstas na abordagem com insumos e produtos A se o 6 2 a seguir descreve em detalhes a ferramenta UseCaseAgent usada na etapa 1 e a se o 6 3 apresenta a ferramenta ModelT e discute as atividades relativas s etapas 2 3 e 4 6 2 Ferramenta UseCaseAgent A especifica o de casos de uso de acordo com o metamodelo UCModel demanda o uso de uma ferramenta UML capaz de e Criar diagramas de atividades de acordo com a especifica o UML 2 e e Trabalhar com perfis UML onde est o definidos os estere tipos e tagged values do metamodelo UCModel Entretanto a cria o de diagramas de atividades nesse contexto n o contemplaria a valida o da sua ader ncia ao metamodelo UCModel pois a ferramenta UML simplesmente aplicaria os estere tipos aos elementos do diagrama mas n o teria condi es de validar a sua estrutura frente as restri es estabelecidas pelo UCModel Assim foi identificada a necessidade
109. ANG et al 2010b apresenta evid ncias de que as demandas por manuten es est o geralmente relacionados volatilidade das regras de neg cio Logo o seu gerenciamento essencial para rastrear os impactos das solicita es de altera o e As regras de neg cio desempenham papel central na cria o de testes funcionais pois as alternativas do comportamento sist mico podem estar associadas pol ticas ou restri es definidas por tais regras e e A reutiliza o das regras de neg cio torna se independente de um ou outro sistema Recentemente a OMG definiu uma nova especifica o especialmente voltada modelagem de regras de neg cio cnamada Semantics of Business Vocabulary and 72 Rule SBVR OMG 2008 com o objetivo de prover uma base para a descri o detalhada e formal das mesmas atrav s de uma linguagem natural estruturada A SBVR distingue regras usando duas modalidades l gicas HALPIN 2006 e Al tica regras que n o deveriam a princ pio ser violadas sob nenhuma hip tese sendo portanto chamadas de regras estruturais e e De ntica regras que expressam obriga es ou expectativas com rela o ao comportamento mas sem nenhuma garantia de que elas n o ser o violadas Baseado nessas modalidades o gabarito de descri o de regras definido no SBVR defende que a descri o das regras siga um estilo prefixado conforme apresentado na Tabela 4 5 O padr o prev que caso seja omit
110. ActorAction Descri o da a o obrigat ria 11 Deve ter um ator associado N o pode ser a ltima a o de um fluxo Deve ser sucedida por uma SystemAction GotoAction IncludeUCAction ou ExtendUCAction RON SystemAction 1 Descri o obrigat ria 12 131 Deve ser sucedida por outra SystemAction SystemResponse GotoAction FinishAction IncludeUCAction ou ExtendUCAction SystemResponse Descri o obrigat ria Deve ser sucedida por uma ActorAction GotoAction FinishAction IncludeUCAction ou ExtendUCAction 13 GotoAction Destino obrigat rio Destino n o pode ser outra a o GotoAction Destino deve pertencer cadeia de ativa o do fluxo S pode ser definida para fluxos alternativos ou de exce o Tem que ser a ltima a o em um fluxo alternativo ou de exce o Se vier ap s uma resposta do sistema deve ter como destino outra resposta do sistema ou uma a o do ator 14 FinishAction N o pode ter fluxos alternativos ou de exce o essa regra j est implementada na estrutura do metamodelo S pode ser definida para fluxos alternativos ou de exce o Tem que ser a ltima a o em um fluxo alternativo ou de exce o 15 ConceptualRule Descri o obrigat ria Deve ser referenciada por pelo menos uma a o do UseCase 7e8 5 6 Conclus o Este cap tulo apresentou o metamodelo UCModel definido no escopo
111. Casos e Procedimentos de Testes Funcionais a atividade respons vel por a partir do documento de requisitos gerar os casos e procedimentos de testes funcionais Essa gera o ocorre de forma semi autom tica e a se o 4 7 apresenta mais detalhes acerca deste recurso 63 Processo de especifica o de requisitos Elicita o defeitos Inicia uma nova itera o no processo de Engenharia de Requisitos Atividades de projeto Figura 4 2 Atividades previstas na abordagem proposta No contexto deste trabalho as atividades destacadas na Figura 4 2 podem ser definidas como 4 4 Classifica o de Requisitos Tradicionalmente os requisitos t m sido classificados como requisitos funcionais e n o funcionais Enquanto os requisitos funcionais descrevem as fun es 64 que o software deve executar para solucionar determinado problema os requisitos n o funcionais restringem o espa o da solu o SAWYER amp KOTONYA 2004 SOMMERVILLE 2006 A maioria dos m todos de desenvolvimento Web analisados no 3 prop e uma classifica o para os requisitos Embora n o haja consenso sobre essa classifica o e os termos empregados variem de um m todo para o outro poss vel observar uma classifica o recorrente principalmente nos m todos mais recentes ou que vem evoluindo ao longo do tempo como OOHDM SCHWABE et al 1996 VILAIN et al 2000 URBIETA et al 2007 WebML CERI et al 2000 MORENO et al 2
112. ConditionalFlow E BasicAction TE ZS 1 caller BehavioralAction Action Doo Figura 5 8 Vis o parcial do metamodelo UCModel referente aos fluxos principal alternativos e de exce o e sua rela o com o metamodelo da UML Representa o no Diagrama de Atividades A representa o dos fluxos principal alternativos e de exce o feita de forma distinta no diagrama de atividades conforme apresentado na Figura 5 9 e Fluxo principal sequ ncia de a es que representa o caminho ideal ou mais comum para que o ator atinja o objetivo desejado representado pelos fluxos de controle que ligam o n inicial ao n final sem nenhuma condi o de guarda associada a nenhum dos fluxos Na Figura 5 9 o fluxo principal formado pela sequ ncia de a es a o 1 a o 2 e a o 3 e Fluxo alternativo sequ ncia de a es que indica uma escolha alternativa do ator ou um caminho alternativo para execu o do caso de uso quando determinado estado ou condi o alcan ado representada por um fluxo que se inicia sempre a partir de um n de decis o O n de decis o indica que neste ponto do diagrama existe um caminho alternativo que pode ser executado dependendo da avalia o da condi o associada ao fluxo 106 alternativo Os fluxos de controle que pertencem ao fluxo alternativo s o nomeados com o mesmo identificador do fluxo alternativo a fim de to
113. E FEsjatores lt lt actor gt gt Cliente Es lt lt actor gt gt Gerente lt lt actor gt gt Administrador E Je lt use cases gt gt casos de uso E fEsjcasos de uso F2 casos de uso _3UC001 Pagar boleto banc rio JUC002 Transfer ncia entre contas UC003 Emitir extrato C JUCO04 Autenticar usu rio a Jc lt use cases descriptions gt gt descricoes de casos de uso E Bgjdescricoes de casos de uso E lt lt use case description gt gt UC001 Pagar boleto banc rio E lt c lt use case description gt gt UC002 Transfer ncia entre contas E lt lt use case description gt gt UC003 Emitir extrato E lt lt use case description gt gt UC004 Autenticar usu rio s lt conceptual modeb gt modelos conceituais Je lt structural view gt gt modelos estruturais Je lt behavioral view gt gt modelos comportamentais ic Je lt te modeb gt test case model Jectest cases descriptions gt gt test cases descriptions JProfileucmode package Projeto Exemplo Figura 6 2 Tela principal da ferramenta BOUML com a estrutura de pacotes A se o a seguir ir descrever um cen rio de especifica o de um caso de uso onde as cinco funcionalidades da UseCaseAgent ser o exploradas 6 2 1 Cen rios de uso da UseCaseAgent O cen rio de exemplo retrata a funcionalidade de pagamento de boleto banc rio usando um sistema de home banking Ser criado um caso de uso chamado Pagar boleto banc rio 6 2 1 1 Cria
114. HEN 1976 e o enfoque comportamental capturado pelo Diagrama de Fluxo de Dados CONSTANTINE e YOURDON 1979 Apesar de ortogonais a explora o dessas duas perspectivas se mostrou adequada tanto para a representa o do dom nio do problema quanto para representa o da solu o 58 computacional Al m disso a jun o dessas duas vis es estrutural e comportamental em um nico conceito comp e a base da abordagem orientada a objetos t o difundida e explorada nos dias atuais SCHWINGER e KOCH 2006 As caracter sticas particulares das aplica es Web no que diz respeito explora o n o linear da informa o e integra o de diferentes meios para apresenta o das informa es levou os pesquisadores da Engenharia Web a propor a separa o entre esses conceitos A Figura 4 1 sintetiza essa separa o e apresenta em seus tr s eixos as perspectivas de projeto Web conceitua o apresenta o e navega o as vis es de modelagem comportamentais e estruturais e as fases que representam o processo de desenvolvimento especifica o projeto dentre outras independente de um modelo de processo espec fico O que essa figura se prop e a representar que os conceitos relacionados ao dom nio do problema navega o e apresenta o perspectivas de projeto Web devem ser capturados tanto por modelos estruturais quanto comportamentais vis es da modelagem criando assim um foco bem definido para leitura e interpre
115. IGOS et al Modelo de depend ncia E 2009 estrat gica Modelo de racioc nio estrat gico CASAL NGUIDA idem m todo WebRE et al 2009 OGATA et al Caso de uso Prot tipo UI Prototype 2009 Diagrama de atividades Generation Tool DE SILVA etal Caso de uso Prot tipo Requirements 2009 Linguagem natural Specification Tool WebTDD Diagramas em WebSpec Prot tipo Eclipse plug in Gera o de scripts 3 4 Contribui es da Revis o A an lise dos 24 m todos apresentados na se o 3 2 3 possibilitaram uma vis o mais ampla do estado da arte em termos de tratamento de requisitos por parte dos m todos Web Apesar dessa revis o ter sido executada ao longo desses ltimos anos o cen rio inicial n o sofreu altera es significativas podendo ser resumido nos seguintes t picos e Casos de uso t m sido propostos em combina o com o uso de linguagem natural o que sugere que o comportamento do sistema definido nesses artefatos traduzido manualmente para os modelos de projeto apesar de muitos m todos advogarem que geram esses modelos de forma autom tica 54 De um modo geral n o foram observadas preocupa es em definir atividades de garantia da qualidade dos requisitos Os m todos que procuram tratar essa quest o o fazem de forma ad hoc N o foi poss vel identificar sugest es em rela o estrutura o do documento de requisitos de forma que os diversos modelos de especifica
116. ILLO J TOVAL A 2008 Modelling Web Based Systems Requirements Using WRM Web Information Systems Engineering WISE 2008 Workshops LNCS v 5176 pp 122 131 MONTERO S DIAZ P AEDO 2006 From requirements to implementations A model driven approach for web development European Journal of Information Systems v 16 n 4 pp 407 419 MORENO N FRATERNALLI P VALLECILLO A 2006 A UML 2 0 profile for WebML modeling Proceedings of the 6th International Conference on Web Engineering ICWE 06 MORENO N FRATERNALLI P VALLECILLO A 2007 WebML modeling in UML IET Software v 1 n 3 pp 67 80 MYERS G J 2004 The Art of Software Testing John Wiley amp Sons 2a edi o NAKATANI T URAI T OHMURA S TAMAI T 2001 A requirements description metamodel for use cases Proceeding of 8 Asia Pacific Software Engineering Conference pp 251 258 MUSE J D 1992 The Operational Profile in Software Reliability Engineering An Overview Proceedings of 3 International Symposium on Software Reliability Engineering pp 140 154 OFFUT J 2002 Quality attributes of Web software applications IEEE Software v 19 n 2 OGATA S MATSUURA S 2009 An evaluation of a use case driven requirements analysis using web UI prototype generation tool Proceedings of the 9 WSEAS International Conference on Applied Computer Science ACS 09
117. J sobre esse modelo e colabora o existente entre o grupo ESE e a Siemens Corporation Research USA A primeira vers o da ferramenta ModelT foi implementada como uma transforma o XSLT onde os diagramas de entrada e sa da eram armazenadas em arquivos XMI ALBUQUERQUE et al 2010 Essa vers o foi usada para avaliar a viabilidade da deriva o do modelo de testes no padr o TDE a partir do modelo de casos de uso descritos usando o UCModel mas tinha a desvantagem de obrigar o desenvolvedor a realizar uma s rie de passos para gera o e tratamento dos arquivos XMI Na vers o atual a ferramenta ModelT foi implementada como um plug in da ferramenta BOUML sendo assim capaz de ler e gerar modelos diretamente nessa ferramenta Ser o apresentadas a seguir as tr s etapas desse processo usando como exemplo o caso de uso Pagar boleto banc rio Figura 6 9 p gina 44 13 WWW w3 org TR xslt 151 6 3 1 1 Deriva o do Modelo de Testes Essa etapa ocorre ap s o t rmino das atividades relacionadas engenharia de requisitos ou seja ap s a conclus o da especifica o e valida o dos casos de uso O analista de testes utiliza a ferramenta ModelT para derivar o modelo de testes preliminar a partir dos diagramas de atividades que representam as especifica es dos casos de uso Esse modelo de testes chamado de preliminar porque no momento em que gerado ainda n o est pronto para ser usado na gera o dos ca
118. ML 107 5 3 4 A es do Caso de Uso O metamodelo da UML prev unicamente a metaclasse Action para descri o das a es em um diagrama de atividades Embora esse conceito gen rico possibilite o uso desse diagrama na representa o de comportamentos sob diferentes perspectivas o aumento no rigor da descri o de casos de uso que usam diagramas de atividades passa pela especializa o das a es que comp em esse diagrama A defini o dessa especializa o por sua vez demanda uma an lise cuidadosa sobre a natureza das a es usadas na descri o de casos de uso Neste trabalho essa an lise foi feita a partir do conceito de transa o de JACOBSON 1992 5 3 4 1 Transa o e Casos de Uso Os conceitos de caso de uso e transa o preconizados por JACOBSON 1992 s o definidos como e Um caso de uso uma sequ ncia de transa es executadas por um sistema que produz um resultado de valor observ vel para um determinado ator e uma transa o consiste em um conjunto de a es executadas por um sistema Uma transa o invocada por um est mulo enviado do ator para o sistema ou por um gatilho de tempo dentro do sistema De acordo com essas duas defini es uma transa o pode ser detalhada da seguinte forma 1 O ator envia ao sistema uma requisi o e os dados 2 O sistema valida a requisi o e os dados se necess rio 3 O sistema processa a requisi o e altera seu estado interno ou prod
119. NWOO L BYUNGJEONG L WOOSUNG J TAEKSU K HEECHERN K CHISU W 2005 Agile development of web application by supporting process execution and extended UML model Proceedings of 12 Asia Pacific Software Engineering Conference APSEC pp 193 200 WIEGERS K 2003 Software Requirements Microsoft Press 2 edi o WILLIAMS C KAPLAN M KLINGER T PARADKAR A 2005 Toward Engineered Useful Use Cases Journal of Object Technology v 4 n 6 pp 45 57 WU J FU S 2008 Business Process Modeling Based On Norm Analysis Proceedings of 2008 International Seminar on Business and Information Management ISBIM 08 v 2 pp 489 493 YU E S L 1997 Towards modelling and reasoning support for early phase requirements engineering Proceedings of 3 International Symposium of Requirements Engineering pp 226 235 200 AP NDICE A Manual do Usu rio do UseCaseAgent Neste ap ndice apresentado o manual do usu rio do UseCaseAgent abrangendo a instala o do plug in as funcionalidades e restri es da ferramenta e as mensagens de erro oriundas da verifica o do diagrama e da especifica o do caso de uso A 1 Introdu o O UseCaseAgent um plug in desenvolvido em Java que trabalha em conjunto com a ferramenta BOUML Esse plug in foi desenvolvido para apoiar a cria o e verifica o sint tica das especifica es de casos de uso descritas segu
120. S 2007 e que est o diretamente alinhadas com as orienta es propostas neste trabalho 5 4 1 Orienta es Gerais e Na descri o das a es use sempre frases curtas e objetivas e Indique sempre quem realiza a a o Sistema ou Ator e Use sempre verbos no presente e na voz ativa e N o acrescente detalhes sobre a a o na sua descri o Caso seja necess rio fornecer alguma informa o complementar use o complemento da a o para essa tarefa e Seja coerente na ado o dos termos usados na descri o Em caso de exist ncia de sin nimos adote um termo e utilize o de forma consistente e e N o use termos que direcionem para uma solu o ou tecnologia espec fica e e N o junte a es do sistema e resposta do sistema em uma nica a o Essas a es t m naturezas diferentes e podem estar associadas alternativas exce es ou regras diferentes 5 4 2 Orienta es relacionadas A o do Ator e Indique objetivamente a requisi o enviada pelo ator com seus respectivos dados e Use termos relacionados perspectiva de apresenta o ou navega o e Referencia regras relacionadas s perspectivas de apresenta o ou navega o e e As alternativas disparadas por uma a o do ator devem fazer sentido no contexto desse tipo de a o Normalmente essas alternativas est o associadas requisi o enviada pelo ator e ou estado do sistema 126 5 4 3 5 4 4 Orienta e
121. Size Measurement Proceedings of the 2 ACM IEEE International Symposium on Empirical Software Engineering and Measurement ESEM 08 LAVAZZA L ROBIOLO G 2010 Introducing the evaluation of complexity in functional size measurement A UML based approach Proceedings of the 4 194 ACM IEEE International Symposium on Empirical Software Engineering and Measurement ESEM 10 LEE H LEE C YOO C 1998 A Scenario based Object oriented Methodology for Developing Hypermedia Information Systems Proceedings of 31 Annual Conference on Systems Science LEFFINGWELL D WIDRIG D 2003 Managing Software Requirements A Use Case Approach Addison Wesley 2 edi o LINEHAN M H 2008 SBVR Use Cases Rule Representation Interchange and Reasoning on the Web LNCS v 5321 2008 pp 182 196 Springer Heidelberg LOWE D EKLUND J 2002 Client Needs and the Design Process in Web Projects Web Engineering Track of the WWW2002 Conference LOZINSKY S 1998 Enterprise wide Software Solutions Integration Strategies and Practices Addison Wesley ISBN 978 0201309713 LU C SONG 2008 A Comprehensive Aspect Oriented Use Case Method for Modeling Complex Business Requirements Advances in Conceptual Modeling Challenges and Opportunities LNCS v 5253 pp 133 143 LUNA E R GARRIGOS l ROSSI G 2010 Capturing and validating personalization requiremen
122. Ss a E Casos de Uso E UCO01 Pagar boleto banc rio Atores do Caso de Uso E Fluxo Principal Fluxos Alternativos as Sistema valida a op o selecionada pri Fluxos de Exce o Sistema solicita o n mero do boleto Regras Cliente digita o n mero do boleto Erros e Sistema valida o n mero do boleto JBRZBR4 UC002 Transfer ncia entre contas em solicita os dados relativos ao pagamento rs UMEEN ra s liente informa os dados do pagamento UC004 Autenticar usu rio 7 istema valida os dados do pagamento BRS BRE BR Sistema solicita a senha Cliente fornece a senha Sistema valida a senha Sistema debita o valor a ser pago da fonte de recurso selecionada Sistema registra o boleto como pago na fonte de recurso selecionada Sistema apresenta o comprovante de pagamento do boleto Alternativas Exce es Regras System Response solicita a fonte de recurso de onde ser debitado o pagamento O sistema apresenta duas op o para fonte de recurso conta corrente conta poupan a EE BEER Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 5 Tela da UseCaseAgent com o fluxo principal do caso de uso Pagar boleto banc rio 141 ido ut tail dot ds UCModel Atores A2 cliente seleciona op o de leit
123. Step 5 Step 6 Step 10 Step 11 Step 13 Step 16 Step 6 Step 10 Step 11 Step 13 Step 16 Step 18 E 235 2 Category diagrams 2 1 Class Diagram Category Diagram Category Diagram _ p EEE EEE SSeS invalida invalida data_invalida numero_invalido valida desconto_invalido valido juros_invalidos ARS 2 1 1 Category Senha1 1 Choice valida lt no description gt Choice invalida lt no description gt 2 1 2 Category Opcaot Choice valida lt no description gt N Choice invalida lt no description gt 2 1 3 Category DadosPagamento1 Choice data invalida lt no description gt Choice desconto invalido lt no description gt Choice juros invalidos lt no description gt Choice valor final invalido lt no description gt NA BL wN Re Choice valido lt no description gt 2 1 4 Category A2 1 Choice sim lt no description gt Choice nao lt no description gt 2 1 5 Category Boleto1 1 Choice numero invalido lt no description gt Choice vencido lt no description gt 3 Choice valido lt no description gt 2 1 6 Category Erro1 1 Choice 2 lt no descri
124. UCModel A avalia o inicial da t cnica ActCheck tamb m foi realizada no contexto do SiGIC e os resultados desse estudo bem como a evolu o da t cnica est o reportados em MELLO 2011 Por fim com rela o quest o 3 o cap tulo 6 apresenta uma infra estrutura de apoio que cont m uma ferramenta especialmente projetada para apoiar a descri o dos casos de uso de acordo com o metamodelo UCModel No escopo dessa ferramenta o metamodelo proposto e as regras que o regem s o usadas como um or culo para detec o de defeitos de n o conformidade 4 7 Gera o de Casos e Procedimentos de Testes Funcionais Levando se em considera o que as atividades relacionadas aos testes do software est o entre as mais custosas do processo de desenvolvimento JURISTO et al 2004 uma das condi es necess rias para sucesso de projetos de software reside no planejamento cuidadoso dos testes Esse planejamento vital para que dentre outros fatores as funcionalidades identificadas nos documentos de requisitos do software sejam executadas sob todas as condi es e regras definidas pelos requisitos evitando se assim parcialidade nos testes Dentro do Plano de Testes os 88 Casos de Teste definem o conjunto de dados a serem aplicados e os resultados esperados enquanto os Procedimentos de Testes referenciam os Casos de Teste e definem os passos para a execu o efetiva dos testes MYERS 2004 No Teste Baseado em Modelos MBT Mod
125. _rule gt gt R3 obrigat rio que a senha tempor ria seja um n mero de oito digitos E1 Erro no envio do email avisa que n o foi capaz de enviar o email e pede que o usu rio contacte o suporte lt lt system_response gt gt solicita login lt lt system_response gt gt fornece o login lt lt actor action gt gt valida o login lt lt system action gt gt gera uma senha tempor ria lt lt system action gt gt envia a senha tempor ria para o email do internauta lt lt system action gt gt registra a nova senha lt lt system_action gt avisa para qual email a senha temporaria foi enviada lt lt system_response gt gt Identifica o UCO001 Nome Autenticar usuario Descri o Esse caso de uso permite que o usu rio fa a login na aplica o Ator es Internauta Criticalidade Alta Frequ ncia de uso M dia 129 Pr condi es O ator n o est autenticado P s condi es O menu da aplica o apresentado de acordo com o perfil do usu rio Trigger Ator acessa qualquer p gina da aplica o Fluxo Principal 1 Sistema solicita login e senha juntamente com uma op o Esqueci a senha 2 Internauta fornece login e senha A1 3 Sistema valida login e senha R1 R2 4 Sistema apresenta o menu da aplica o de acordo com o perfil do usu rio A2 Fluxos Alternativos A1 Ator seleciona Esqueci a senha A1 1 Sistema sol
126. a o dos requisitos Em consequ ncia ela gera um conjunto de diagramas de atividades que representam o modelo de casos de uso criado de acordo com o metamodelo UCModel e Ferramenta ModelT usada ap s a conclus o das atividades de engenharia de requisitos e tem por objetivo gerar um modelo preliminar de testes funcionais a partir do modelo de casos de uso Como insumo a ferramenta recebe um diagrama de atividades que representa a especifica o de um caso de uso baseada no UCModel e gera como resultado um outro diagrama de atividades que representa o caso de uso do ponto de vista do teste funcional As outra duas ferramentas que completam a infra estrutura s o e Ferramenta BOUML PAG S 2011 uma ferramenta UML usada na constru o dos diagramas UML Foi selecionada porque uma ferramenta open source implementa quase toda a especifica o UML 2 OMG 20104 134 roda em diversas plataformas WindowsO MacOS XO e distribui es Linux e permite a constru o de plug ins para estender as suas funcionalidades Ferramenta TDE UML pertence Siemens Corporation Research USA e usada para gera o dos casos e procedimentos de teste a partir dos modelos de teste Sua escolha se deu por oportunidade e conveni ncia devido a facilidade de acesso ferramenta em virtude da colabora o existente entre o grupo de Engenharia de Software Experimental e a Siemens Corporation Research USA importante frisar que tanto a
127. a o em sala de aula trabalhos realizados no contexto da disciplina ao longo do semestre dentre outros e Defini o dos grupos a defini o dos grupos no primeiro e terceiro estudo procurou criar equipes da forma mais equilibrada poss vel levando em considera o os diversos crit rios adotados na classifica o dos participantes Na defini o dos grupos foi tomado um cuidado espec fico para que n o houvesse em um mesmo grupo participantes que demonstraram assiduidade ou interesse pela mat ria muito dissonantes em detrimento da pr pria experi ncia do participante No segundo estudo 31 havia um interesse muito grande dos participantes na defini o dos requisitos da aplica o Web que aliado ao equil brio entre as experi ncias dos participantes permitiu que a organiza o dos grupos pudesse ser feita pelos pr prios participantes e Participa o de estudantes estudantes n o representam de forma adequada os desenvolvedores do mundo real assim como o ambiente acad mico n o simula de forma adequada o ambiente industrial Entretanto a aplica o usada no terceiro estudo apresenta caracter sticas bastante semelhantes s aplica es de pequeno a m dio porte encontradas na ind stria Adicionalmente CARVER et al 2003 apresentam uma s rie de benef cios que podem ser obtidos com a participa o de estudantes em estudos experimentais e e Uso das ferramentas a falta de familiaridade com as ferramen
128. a o final 7 5 Conclus o Os resultados do primeiro estudo sugerem a viabilidade no uso da abordagem proposta neste trabalho apoiada pela ferramenta UseCaseAgent O segundo estudo que utilizou se dos artefatos gerados no primeiro estudo indicou uma redu o de 22 8 dos defeitos nos casos de uso especificados de acordo com o UCModel se comparado aos casos de uso especificados de forma ad hoc A compara o entre os n mero de defeitos reportados pelas inspe es nas especifica es constru das de forma ad hoc e o n mero de defeitos reportados pelas inspe es nas especifica es constru das de acordo com o UCModel mostra que h uma diferen a estatisticamente significativa a 0 05 a favor do segundo Entretanto a repeti o do primeiro estudo deve ser realizada com um n mero maior de participantes para avaliar as tend ncias l observadas e que n o puderam ser estatisticamente testadas devido ao pequeno tamanho da amostra Com rela o ao segundo estudo uma repeti o com um maior n mero de participantes tamb m 181 pode fortalecer os resultados aqui apresentados A repeti o desses dois estudos pode ser realizada reusando o planejamento e a instrumenta o j definidos nos estudos aqui relatados bastando apenas alterar a distribui o dos artefatos pelo novo grupo de participantes seguindo os mesmos crit rios adotados desses estudos Apesar das limita es dos estudos acreditamos que os resultados obtidos po
129. a o funcional sob a tica das perspectivas de projeto Web e das vis es estrutural e comportamental 4 1 Introdu o A partir da an lise dos m todos de desenvolvimento Web propostos na literatura t cnica Cap tulo 2 dos resultados dos estudos preliminares visando observar quest es relacionadas ao uso das perspectivas Web Cap tulo 3 e das experi ncias no contexto do desenvolvimento do SiGIC foram identificadas reas de oportunidade relacionadas ao desenvolvimento de aplica es Web contempor neas mais especificamente no que tange estrutura o dos requisitos funcionais e garantia da qualidade da aplica o Desta forma este cap tulo apresenta uma abordagem para especifica o de requisitos funcionais que prop e uma estrutura para an lise classifica o e especifica o desses requisitos alinhada aos conceitos explorados pelos m todos Web e que explora essa mesma estrutura para garantia da qualidade da especifica o e do produto final A abordagem apresentada neste trabalho e objeto desta tese prop e uma especifica o de requisitos funcionais apoiada por modelos e organizada de forma que seus elementos sejam descritos luz das perspectivas de projeto Web conceitua o navega o e apresenta o e das vis es de modelagem estrutural e comportamental permitindo assim que esses requisitos sejam explorados de forma consistente desde a fase inicial do projeto ou seja a especifica o A preocupa o c
130. a complementa o do planejamento dos testes o que envolve a descri o dos procedimentos e casos de teste e e Os casos e procedimentos de teste s o gerados atualmente pela ferramenta TDE UML que devido sua caracter stica industrial limita a sua utiliza o de forma mais abrangente 8 4 Quest es em Aberto No contexto da pesquisa apresentada nesta tese algumas quest es permanecem em aberto e consequentemente candidatas a futuras investiga es e A utiliza o dessa abordagem em diferentes categorias de software e em diferentes escalas tamb m se mostra vi vel 185 e A constru o da especifica o de casos de uso seguindo a abordagem apresentada nesta teste apresenta benef cios em termos de custo se comparada a uma abordagem ad hoc e O modelo de testes gerado a partir da especifica o de casos de uso capaz de apoiar a gera o de um conjunto de casos e procedimentos de testes funcionais que cubra todas as regras e restri es estabelecidas nas vis es estruturais e comportamentais definidas na especifica o e A combina o da gera o autom tica dos modelos de teste preliminares com a complementa o deste modelo pelo analista de testes e a posterior gera o do plano de casos e procedimentos de testes funcionais efetiva em termos de custo e esfor o se comparada a uma abordagem ad hoc 8 5 Trabalhos Futuros A abordagem de especifica o e garantia da qualidade de aplica es Web pr
131. a and EER REEE EER ER 212 AAT Regras engene ee a e E a ques a aaa 212 A 12 Verifica o Sint tica sas aa RARE GUESS SE ES 213 A 13 Edi o de um Caso de USO Les anseso inatas si itasadit zen ise nfs isa da aeamanasibatasniraa 214 A 14 Impress o dos Casos de Uso seara 215 A 15 Verifica o Sint tica do Diagrama de Atividades i 216 A 16 Restri es do UseCaseAgent essere 217 A 17 Combina o de A es na Especifica o do Caso de Uso 217 A 18 Orienta es para Descri o de Casos de USO c ceceeeeeeeteeeeenteeeeeeees 220 PAD Mensagens d EMO renees pa alegria EURO ga Sida e upa esa 223 A 19 1 Mensagens de Erro na Verifica o de Diagramas 223 A 19 2 Mensagens de Erro na Especifica o do Caso de Uso 224 AP NDICE B Exemplo de Casos e Procedimentos de Teste Funcional 228 Te TOSECASOS respira raa Ea REDE E FO Er ADIA ee ree ra aaa 228 1 1 Test Case TC001 TP1 ou cceccccccceeeeeceeesseseeeeeeeeeseaeeeaesceeeeeseseaaeasseseeeess 228 Mele la Test CASE PA asas sara rise ia ensaios erect sista Ses Lapa E AE 228 121 2 Test CaseSteps serrr sia ns chains easier ala 229 1 1 3 Test Case Data Variations essere naaana 230 1 22 Pest Case 16001 TPZ honton omena beech eee eee 231 1 2 Test CasO PA Gas solte ite cien Rest Solon a R 231 1 2 2 Test Case ICDS esca
132. a de Conceitua o A perspectiva de Conceitua o trata da representa o dos elementos conceituais que comp em o dom nio do problema abrangendo tanto as entidades que povoam esse dom nio com seus atributos e associa es quanto os eventos ou processos que exploram ou afetam essas entidades A Tabela 4 1 define os artefatos a serem constru dos para representar as vis es estrutural e comportamental da perspectiva de conceitua o Os detalhes de cada artefato ser o apresentados nas se es seguintes Tabela 4 1 Artefatos para representa o dos requisitos na perspectiva de conceitua o Estrutural 1 Entidades do dom nio modelo de classes Comportamental 2 Funcionalidades do sistema na vis o do usu rio casos de uso 3 Detalhamento do comportamento sist mico diagrama de atividades 4 Processos diagrama de atividades 5 Eventos m quinas de estado 4 2 2 Perspectiva de Navega o A perspectiva de Navega o procura representar o espa o de explora o n o linear das informa es a partir dos elementos conceituais que comp em o dom nio do problema Assim essa perspectiva define quais caminhos podem ser explorados e quais informa es originadas do modelo conceitual estar o access veis aos usu rios em determinado ponto sob a perspectiva de uma explora o n o linear dessas informa es Esse conceito tem sido explorado por diversos pesquisadores da Engenharia Web conforme pod
133. a defini o das a es Estere tipo Tipo base Defini o lt lt actor action gt gt Action Define uma a o do ator ActorAction Tagged value Actor Nome do ator que executa a a o complement Informa es complementares sobre a a o Estere tipo Tipo base Defini o lt lt system action gt gt Action Define uma a o do sistema SystemAction Tagged value complement Informa es complementares sobre a a o Estere tipo Tipo base Defini o lt lt system response gt gt Action Define uma resposta do sistema SystemResponse Tagged value complement Informa es complementares sobre a a o Estere tipo Tipo base Defini o lt lt include action gt gt Action Define um ponto de inclus o Tagged value uc Identificador do caso de uso a ser inclu do 113 complement Informa es complementares sobre a a o Estere tipo Tipo base Defini o lt lt extend action gt gt Action Define um ponto de extens o Tagged value Defini o uC Identificador do caso de uso que estende o caso de uso corrente complement Informa es complementares sobre a a o 5 3 5 Combinando A es na Descri o do Comportamento A defini o de cada a o proposta pelo metamodelo UCModel e o pr prio conceito de transa o sugerem que nem todas as combina es entre essas a es fazem sentido Por exemplo n o faz se
134. a definido nas prefer ncias do usu rio As regras estruturais e comportamentais da perspectiva de apresenta o devem ser representadas em linguagem natural estruturada Contudo existem alguns tipos de regra onde essa representa o n o recomendada como por exemplo e Regras que definem diagrama o e Regras que definem estilos relacionados ao look and feel da interface e e Regras que definem os elementos da interface gr fica a serem utilizados Para esses casos sugere se a ado o de um prot tipo da interface onde essas quest es podem ser representadas de forma mais adequada Nesse caso as mesmas observa es sobre o uso de prot tipos de interface na representa o de regras de navega o s o v lidas para o uso de prot tipo nas regras de apresenta o Semelhante ao que ocorre com as regras da perspectiva de navega o as regras da perspectiva de apresenta o tamb m devem estar associadas aos casos de uso pois elas definem como as informa es ser o apresentadas durante a intera o ator sistema A se o 4 5 3 2 discute esse t pico com maiores detalhes Com rela o transcri o das regras capturadas na elicita o de requisitos para o documento de requisitos importante ressaltar que nem todas as regras identificadas podem ser diretamente transcritas para o documento de especifica o A interpreta o das regras originais segundo as perspectivas de projeto Web pode levar 78 a refatora
135. a em avalia o quando 75 o professor solicitar a licen a R11 obrigat rio que o estado de e Avalia o da solicita o de licen a uma licen a seja aprovada quando a documenta o adicional estiver de acordo com o conjunto de normas para concess o de licen a R12 obrigat rio que o estado de uma licen a seja reprovada quando a documenta o adicional n o estiver de acordo com o conjunto de normas para concess o de licen a Os contextos de atua o desse tipo de regra normalmente representam funcionalidades previstas para o sistema ou procedimentos a es dentro de uma funcionalidade prevista Como a abordagem proposta prev que o ponto de partida para especifica o do comportamento do sistema s o os casos de uso tamb m previsto que as regras que impactam nesse comportamento estejam diretamente associadas ao caso de uso mais precisamente s a es sist micas presentes nesses casos de uso O detalhamento dessa associa o ser apresentado na se o 4 5 3 2 4 5 2 2 Regras x Perspectiva de Navega o Regras associadas perspectiva de navega o definem quais informa es ser o disponibilizadas e poss veis restri es sobre essa disponibiliza o A Tabela 4 8 exemplifica a aplica o dos princ pios da SBVR para especifica o de regras na perspectiva de navega o de um sistema de administra o para a rea de RH Tabela 4 8 Exemplo de especifica
136. a esperado pois os prot tipos materializam a estrutura da interface com os usu rios de uma forma concreta e mais natural para os desenvolvedores Contudo ainda persistiram d vidas quanto forma de representar os aspectos comportamentais relacionados perspectiva de apresenta o Algumas dificuldades relatadas pelos participantes do primeiro estudo surgiram tamb m neste segundo estudo mais notadamente as quest es relacionadas ao modelo navegacional relatado por 2 das 4 equipes enquanto outras dificuldades vieram tona somente nesse estudo como a divis o dos modelos entre os membros da equipe relatado por 3 das 4 equipes Entretanto apesar dessa repeti o n o foi poss vel estabelecer com maior precis o nenhuma sugest o de poss vel causa e efeito Assim um terceiro estudo de observa o foi elaborado no sentido de tentar capturar os dados de forma mais rigorosa e objetiva a fim de possibilitar essa an lise 2 4 Terceiro Estudo de Observa o Esse estudo de observa o acorreu no contexto da disciplina de gradua o Engenharia de Software Orientada a Objetos ministrada no 2 semestre de 2008 na UFRJ 2 4 1 Objetivo Analisar o uso de modelos no desenvolvimento de aplica es Web com o prop sito de caracterizar com respeito viabilidade e relev ncia dos modelos percep o de esfor o dificuldade e import ncia do ponto de vista do pesquisador no contexto do desenvolvimento de uma aplica o Web
137. a execu o do caso de uso criticality Indica o n vel de criticalidade do caso de uso escala ordinal frequencyofuse Indica a frequ ncia em escala ordinal com que o caso de uso executado pelos atores A Figura 5 5 apresenta um diagrama de atividades que descreve um caso de uso e seus elementos b sicos Os elementos que s o mapeados diretamente para a UML s o representados nativamente no diagrama de atividades elementos 3 4 e 5 da Figura 5 4 Os demais elementos por n o terem contrapartida no metamodelo da UML devem ser descritos como estere tipos ou tagged values que s o apresentados no diagrama como coment rios associados ao elemento redefinido pelo estere tipo Assim o coment rio associado atividade indica que esta na realidade uma descri o de caso de uso estere tipo lt lt use case description gt gt e define os valores para as tagged values id summary actors criticality e frequencyofuse Para facilitar a identifica o do caso de uso para o leitor do modelo o id do caso de uso tamb m representado no nome do mesmo no formato UCxxx onde xxx o id do caso de uso Al m dos dez elementos apresentados na Tabela 5 2 o diagrama da Figura 5 5 apresenta tamb m os n s inicial e final que marcam o in cio e o fim respectivamente da execu o do caso de uso 101 lt lt use case description gt gt id 2 summary Breve descri o do objetivo do caso de uso trig
138. a tarefa com a ferramenta UCA Entretanto nenhuma dessas tend ncias p de ser avaliada estatisticamente devido ao pequeno tamanho da amostra dispon vel Estudos futuros com maior quantidade de participantes podem tirar vantagem do arranjo desse estudo e verificar a validade estat stica dessas suposi es Tabela 7 4 Tempos reportados pelos participantes para especifica o dos casos de uso Ferra Partici N velde Conjunto Caso de N vel de Tempo Mediana menta pante experi n do Caso uso complexidade em minutos em minutos cia de uso 27 M dia Baixa 50 40 M dia Baixa 45 P1 Alta A 35 M dia Alta 35 180 47 5 15 Alta 50 EDA E Baixa 24 356 50 16 M dia Baixa 51 P2 Baixa B 36 M dia Alta 50 176 50 5 17 Alta 51 6 Baixa 20 16 M dia Baixa 25 a Alta p 36 M diaAlta 20 86 a 17 Alta 21 une 27 M dia Baixa 20 ea oe f 40 M dia Baixa 43 P2 Baixa A 35 M dia Alta 62 185 51 5 15 Alta 60 170 7 2 10 An lise Qualitativa Ap s a execu o do estudo foi realizada uma reuni o com cada participante individualmente a fim de coletar dados qualitativos acerca da execu o das atividades O objetivo dessa reuni o foi coletar a percep o de viabilidade de uso da ferramenta UCA e as dificuldades e facilidades observadas no processo de especifica o dos casos de uso Para tal seis quest es foram formuladas 1 Na sua opin
139. abela 5 13 Restri es aplicadas ao caso de uso Autenticar usu rio da Figura 5 16 Metaclasse Restri es Item UseCase ID obrigat rio 1 Nome obrigat rio Resumo obrigat rio Criticalidade obrigat ria Frequ ncia de uso obrigat ria Pr condi o obrigat ria P s condi o obrigat ria Deve ter pelo menos um ator associado MainFlow Deve possuir pelo menos uma transa o AlternativeFlow Condi o de guarda obrigat ria Deve ter pelo menos uma a o WIM A ONOoaBRWND ed ed ee ee ee 0 O1 PO Deve ser referenciado por pelo menos uma a o do UseCase o 4 Deve estar sempre associado a a es do mesmo tipo ou Seja sempre disparado por a es do mesmo tipo 6 Se for disparado por uma SystemAction ent o sua 9 primeira a o tem que ser uma SystemResponse ou uma FinishAction 7 Se for disparado por uma SystemResponse ent o sua 10 primeira a o tem que ser uma SystemResponse uma SystemAction ou uma FinishAction ExceptionFlow 1 Condi o de guarda obrigat ria 2 Deve ter pelo menos uma a o AIO 3 Deve ser referenciado por pelo menos uma a o do UseCase 4 Deve estar sempre associado a a es do mesmo tipo 4 ou Seja sempre disparado por a es do mesmo tipo 5 Se for disparado por uma SystemAction ent o sua 4 primeira a o tem que ser uma SystemResponse ou outra SystemAction
140. adas sugest es relacionadas adequa o do documento de requisitos como insumo principal para gera o inicial dos modelos Essas sugest es dizem respeito tanto necessidade de aprimoramento no n vel de detalhamento necess rio quanto estrutura do pr prio documento Tamb m foram citadas a necessidade de apresentar inicialmente uma vis o geral dos processos de neg cio assim como o escopo do projeto e as perspectivas de futuras evolu es Ferramenta CASE Foram citadas recorrentemente tr s sugest es adequa o sint tica e sem ntica aos modelos interface que privilegie a agilidade na manipula o dos modelos e trabalho colaborativo Garantia da Qualidade 29 Foram citadas a necessidade de processos para verifica o da consist ncia entre os modelos processos para inspe o dos requisitos e processos para valida o dos modelos de navega o junto aos clientes Modelos Foram sugeridas a explora o de transforma es semi autom ticas de modelos a gera o de outros artefatos a partir dos modelos e o reuso de modelos e padr es de projeto Processo de Modelagem A maior parte das sugest es se enquadrou nessa categoria tais como defini o de heur sticas de apoio constru o dos modelos crit rios para sele o dos modelos mais relevantes de acordo com o contexto de desenvolvimento crit rios para defini o do n vel de detalhamento a ser utilizado nos modelos de acordo com a complexidade ex
141. adastrada no informa que a senha inv lida PAS e que encontra se bloqueada lt lt system_response gt gt Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia senha inv lida em menos de 3 tentativas apresenta o comprovante senha inv lida na 3a tentativa de pagamento do boleto Corrija as express es associadas com as decis es de lt lt system_response gt gt forma que elas reflitam os dados definidos nas classes de equival ncia Figura 6 16 Modelo de testes referente ao caso de uso Autenticar usu rio alterado pelo analista de testes 157 6 3 1 3 Gera o dos Casos e Procedimentos de Teste Funcionais Ap s a complementa o do modelo de testes poss vel utiliz lo na gera o dos casos e procedimentos de teste funcionais Para essa tarefa utilizada a ferramenta TDE UML que interpreta o modelo de testes e as classes de equival ncia com os respectivos valores e percorre os caminhos especificados pelo diagrama do modelo de testes aplicando combina es desses valores O comportamento padr o da TDE UML percorrer todos os caminhos poss veis e combina es entre eles al m de todas as combina es de valores poss veis em cada ponto de decis o mas essa estrat gia pode ser alterada na ferramenta Usando a estrat gia padr o o modelo da Figura 6 16 gerou 56 combina es de caminhos poss veis com 80 possibilidades de explora o desses caminhos a p
142. alhar tamb m com fluxos de dados permitindo a modelagem dos objetos consumidos ou produzidos pelas a es do processo que est sendo modelado A constru o de diagramas de atividades realizada a partir de um conjunto de elementos que fazem parte do metamodelo da UML Entretanto os diagramas de atividades que comp em a abordagem proposta neste trabalho utilizam apenas uma parte desses elementos mais precisamente os sete elementos definidos na Tabela 5 1 94 Tabela 5 1 Subconjunto de elementos do diagrama de atividades da UML explorados no contexto deste trabalho Nome Descri o S mbolo N inicial Representa o ponto de partida para execu o do diagrama Atividade o processo ou comportamento que est sendo modelado Atividade N de a o um a o que comp e a sequ ncia de ou A o a es do processo ou comportamento A ao que est sendo modelado N de Define um ponto a partir do qual existem decis o diferentes alternativas de execu o Fluxo de uma conex o direcionada entre duas E a a Pa d A o 1 A o 2 controle a es que denota a seq ncia de execu o do diagrama Condi o de E uma express o associada a um fluxo de guarda controle que define se este pode ou n o express o executado N final Representa o ponto de parada da execu o do diagrama Por outro lado casos de uso podem ser definidos como especifica es do comportamento esperad
143. ama de atividades correspondente automaticamente gerado na ferramenta BOUML 162 Visando avaliar a viabilidade de uso da ferramenta UseCaseAgent que ap ia a constru o de especifica es de caso de uso aderentes ao UCModel foi elaborado o primeiro estudo Nesse caso o tempo gasto na especifica o do caso de uso e consequentemente gera o do diagrama de atividades foi usado como uma medida indireta que compara as duas possibilidades de especifica o Entretanto o primeiro estudo n o foi planejado para permitir a avalia o completa da abordagem em si mas somente da viabilidade da ferramenta que implementa a especifica o de casos de uso de acordo com a formaliza o oferecida por UCModel Assim um segundo estudo foi elaborado com a finalidade de avaliar a abordagem proposta sob a tica da qualidade das especifica es de caso de uso geradas atrav s da ferramenta UseCaseAgent Nesse caso a quantidade de defeitos reportados na inspe o das especifica es foi usada como uma medida indireta da qualidade das mesmas Como insumo para o segundo estudo foi usado um subconjunto das especifica es geradas no primeiro estudo composto de modelos diagramas de atividade constru dos com e sem a ajuda de UseCaseAgent A Figura 7 1 apresenta uma vis o geral dos estudos de avalia o planejados e executados no escopo desta tese I 1 Estudo i 20 Estudo Es amp n G _ gt See e E
144. anizado a partir do corpo de conhecimento existente na literatura t cnica e que define os elementos para descri o do comportamento do sistema Estrutura o dos requisitos funcionais a partir de 90 e Um conjunto de modelos conceituais que capturam os aspectos estruturais e comportamentais relacionados ao dom nio do problema e Um conjunto de diagramas de atividades que formalizam o comportamento do sistema tanto no n vel de abstra o do caso de uso quanto no detalhamento das a es do sistema e e Um conjunto de regras que define e restringe o comportamento do sistema classificadas de acordo com as perspectivas de projeto Web nas quais impactam 5 O metamodelo UCModel definido com o objetivo de estruturar a especifica o dos casos de uso em torno de um conjunto de regras e restri es bem definido e prover um arcabou o sint tico e sem ntico a partir do qual poss vel explorar quest es relacionadas qualidade da especifica o e 6 Um conjunto de regras de transforma o modelo modelo que possibilitam a gera o autom tica de um modelo preliminar de testes funcionais a partir da especifica o de casos de uso proporcionando ao analista de testes um ponto de partida consistente com a especifica o a partir do qual os modelos definitivos de teste podem ser obtidos Assim a abordagem apresentada como objeto desta tese procura contemplar um espectro que engloba desde a an lise e classifica o dos requis
145. antir que o diagrama possui os requisitos m nimos para que possa ser traduzido para o metamodelo UCModel Caso algum desses erros seja encontrado a edi o transforma o do modelo abortada e ID do Caso de Uso nulo ou n o um inteiro positivo Verifique a tagged value ID da descri o do Caso de Uso As atividades estereotipadas com lt lt use case description gt gt possuem uma tagged value chamada ID Esse ID identifica o caso de uso de forma nica dentre os demais e gerado automaticamente pelo UseCase Agent Caso algum caso de uso seja criado sem a ajuda do UseCaseAgent o desenvolvedor respons vel por fornecer esse ID e garantir que ele nico e N inicial n o encontrado Um diagrama de descri o de UC deve ter um e somente um n inicial e N final n o encontrado Um diagrama de descri o de UC deve ter um e somente um n final e O n inicial deve ter um e somente um fluxo de controle sem nenhuma condi o de guarda Apenas um fluxo de controle sem nenhuma condi o de guarda permitido a partir de um n inicial e Uma a o deve ter um e somente um fluxo de controle sem nenhuma a o de guarda e zero ou mais interrup es fluxos de controle com lt lt interrupt gt gt para tratamento de exce o Apenas um fluxo de controle sem nenhuma condi o de guarda permitido a partir de uma a o Se houverem outros fluxos esses representam tratamentos de exce es e d
146. artir dos valores definidos para as classes de equival ncia A Figura 6 17 apresenta parte do documento de casos e procedimentos gerados pela TDE UML ressaltando um dos caminhos gerados e as combina es de valores que permitem percorrer esse caminho de duas formas distintas O Ap ndice B apresenta os casos e procedimentos de teste gerados a partir do modelo da Figura 6 16 onde foi selecionada a estrat gia de percorrer todas as transi es mas sem realizar todas as combina es entre elas Como resultado foram gerados 3 caminhos poss veis no diagrama com 6 possibilidades para percorr los 158 1 1 Test Case TC001_TP1 1 1 1 Test Case Path Pagar Boleto Bancario J informa que deve ser selecionada uma op o system response lt lt business_rule gt lt lt business_rule gt gt informa que o n mero do boleto inv lido system response boletol 5 informa que n o poss vel pagar um boleto de outro banco ap s o vencimento system response lt lt business rule gt bs informa que a senha inv lida e WYSenhb invalida and errok 3 solicita a fonte de recurso de onde sera debitado o pagamento system response seleciona uma das op es actor action lt lt business_rule gt gt 0 opcaol invalida lt lt solicita o n mero do boleto system response solicita que o cliente fa a a leitura eletr
147. aseAgent mas ser o preservados se o caso de uso for editado Como o BOUML n o possui nenhuma API para gera o autom tica de diagramas o UseCaseAgent sempre cria um diagrama em branco Para popular o diagrama com os elementos desejados basta arrast los a partir do project browser painel esquerda do BOUML para dentro do diagrama Devido a essa restri o recomendado que o desenvolvedor n o perca tempo formatando o diagrama enquanto o caso de uso n o estiver conclu do pois caso seja necess rio editar o caso de uso O diagrama criado anteriormente ser perdido quando a nova especifica o for salva Dica para alterar as configura es de desenho do diagrama ou de qualquer um de seus elementos basta acionar no BOUML o menu de contexto sobre o diagrama ou no elemento desejado e clicar na op o Edit drawing settings A 17 Combina o de A es na Especifica o do Caso de Uso A sequ ncia b sica de a es de um caso de uso preconizada pelo metamodelo UCModel segue os conceitos definidos em Jacobson 1992 conforme a Figura A 18 217 A o do Ator A o do Sistema Resposta do Sistema Figura A 18 Sequ ncia b sica de a es previstas no metamodelo UCModel De acordo com a Figura A 18 temos Uma a o do ator seguida de uma ou mais a es do sistema que s o seguidas de respostas do sistema que retornam uma outra a o do ator reiniciando o ciclo e A o do ato
148. at rio que o valor dos juros seja fornecido se a data de pagamento for menor que a data corrente lt lt conceptual_rule gt gt BR8 Valor a ser pago valor do boleto desconto juros lt lt conceptual_rule gt gt BR9 obrigat rio que o valor a ser pago seja maor que zero Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia dados de pagamento inv lidos Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia AS informa que os dados do dados de mento inv lidos l pasa J pagamento s o inv lidos lt lt system_response gt gt lt lt navigation_rule gt gt NR10 obrigat rio que o sistema apresente uma mensagem de erro para cada dado que esteja incorreto informa que a senha inv lida lt lt system_response gt gt AS senha inv lida em menos de 3 tentativas lt lt conceptual_rule gt gt BR11 obrigat rio que a senha fornecida seja id ntica a senha do cart o cadastrada no sistema Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia senha inv lida em menos de 3 tentativas senha inv lida na 3a tentativa Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia Figura 6 15 Modelo de testes gerado pela ModelT2 referente ao
149. awing settings nea Delete cs Import XMI 2 1 Ee Checkin Mark Check out Force stereotype consistency Create UCModel TCModel Package Structure Generate Check UCModel TCModel Package Structure Create Use Case package use case model 4 Figura A 3 Ativa o do UseCaseAgent a partir do BOUML para cria o de um novo caso de uso Em seguida ser aberta a janela de console do BOUML e a janela do UseCaseAgent com a tela para defini o dos dados b sicos do caso de uso Figura A 4 Importante a janela do console do BOUML s usada caso n o seja poss vel iniciar o plug in ou ocorra algum erro fatal durante a execu o do BOUML 205 S Use Case Agent vers o 0 39 E e ha Sox Arquivo Verificar do UCModel Atores Caso deUso 4 du Casos de Uso UC001 Pagar boleto bant UCO02 Transfer ncia ent Descri o UC003 Emitir extrato UCc004 E UC005 Conduir compra Nome Criticalidade Pr condi o P s condi o Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 4 Tela inicial do UseCaseAgent Nessa tela poss vel observar 3 op es na toolbar e Salvar verifica a sintaxe da descri o e gera o diagrama de atividades correspondente ao caso de uso caso n o haja nenhum erro de sintaxe no modelo e Verificar verifica a sintaxe do modelo
150. b Sites Technical Report of Tilburg University Infolab B lgica DIAS NETO A C TRAVASSOS G H 2006 Marak Uma Infra estrutura Computacional para Apoiar o Planejamento e Controle de Testes de Software Anais do V Simp sio Brasileiro de Qualidade de Software SBQS 06 pp 250 264 DIAZ P MONTERO S AEDO 2005 Modelling hypermedia and web applications the Ariadne Development Method Information Systems v 30 no 8 pp 649 673 DIEV S 2006 Use cases modeling and software estimation Applying Use Case Points ACM Software Engineering Notes v 31 n 6 pp 1 4 DESHPANDE Y MURUGESAN S GINIGE A HANSEN S SCHWABE D GAEDKE M WHITE B 2002 Web Engineering Journal of Web Engineering v 1 v 1 pp 3 17 DURAN A RUIZ A TORO M 2002 Implementing Automatic Quality Verification of Requirements with XML and XSLT Proceedings of 6th ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engineering QAOOSE 02 DURAN A BERNARDEZ B GENERO M PIATINNI M 2004 Empirically Driven Use Case Metamodel Evolution LNCS v 3273 pp 1 11 191 ESCALONA M J MEJ AS M TORRES J REINA A M 2003 The NDT development process Proceedings of IV International Conferences on Web Engineering LNCS vol 2722 pp 463 7 ESCALONA M J KOCH N 2004 Requirements Engineering for Web Applications A Compara
151. bilizada Acesso estrat gias para localiza o da informa o Navega o caracter sticas relacionadas ao hipertexto Apresenta o organiza o das p ginas opera o do usu rio opera es dispon veis ao usu rio e opera o do sistema opera es que o sistema deve executar e Projeto hiperm dia nessa fase s o desenvolvidos o modelo da informa o entidades e seus atributos e relacionamentos modelo de navega o como a informa o organizada em n s e os links entre esses n s e Os autores n o definiram um nome para a metodologia por isso essa sigla foi usada nesta tese para referenci la 43 modelagem da publica o como a informa o ser apresentada ao usu rio e Projeto das opera es define quais opera es estar o dispon veis ao usu rio com suas respectivas pr e p s condi es e Projeto transacional define as transa es ou seja uma sequ ncia de opera es que define um processo de neg cio e e Projeto da customiza o especifica regras que definem como a aplica o ir se adaptar a diferentes contextos de uso 3 2 3 11 NDT Navigational Development Techniques O NDT ESCALONA et al 2003 um m todo que inclui apenas as fases de tratamento de requisitos e an lise onde s o aplicadas t cnicas espec ficas para obten o de modelos de an lise No NDT cada requisito classificado em requisito de armazenamento do usu rio funcional intera
152. ca o adicional tem por objetivo 73 e Oferecer uma perspectiva adicional para escrita leitura compreens o e avalia o dessas regras minimizando a sobrecarga sem ntica cada regra est relacionada a uma e somente uma perspectiva de projeto e Possibilitar a especifica o das regras usando o formalismo e vocabul rio mais adequado de acordo com a perspectiva na qual ela est inserida e e Evitar regras declarativas com comportamento complexo 4 5 2 1 Regras x Perspectiva de Conceitua o Regras associadas perspectiva de conceitua o relatam proposi es acerca dos conceitos relacionados ao escopo do sistema ou seja os mesmo conceitos que s o capturados e representados pelos modelos conceituais A Tabela 4 6 exemplifica a aplica o dos princ pios da SBVR para especifica o de regras na perspectiva conceitual no contexto de um sistema de administra o de unidades de ensino Tabela 4 6 Exemplo de especifica o de regras conceituais segundo a SBVR Termos professor departamento coordenador licen a solicita o de licen a disciplina documenta o adicional em andamento aprovada reprovada Tipos de fatos professor est vinculado a departamento departamento tem coordenador coordenador um professor professor pode solicitar licen a coordenador recebe gratifica o professor leciona disciplina departamento oferece disciplina solicita o de licen a re
153. cado 4 Edi o do diagrama de atividades ou seja da especifica o do caso de uso usando uma abordagem textual e 5 Gera o da especifica o do caso de uso em formato texto padr o RTF Rich Text Format conforme os elementos previstos no gabarito de casos de uso apresentado na Tabela 4 1 p gina 60 As funcionalidades 1 2 e 4 tem o objetivo de dar mais flexibilidade ao desenvolvedor pois coloca sua disposi o duas abordagens distintas para especifica o dos casos de uso 1 Gr fica atrav s de um editor de diagrama de atividades de uma ferramenta case UML com o apoio do perfil ProfileUCModel 2 Textual atrav s da ferramenta UseCaseAgent com a gera o autom tica do diagrama de atividades Na primeira op o o desenvolvedor cria o elemento desejado diretamente no diagrama de atividades aplica um dos estere tipos dispon veis no perfil UML ProfileUCModel e define o valor de cada tagged value associada ao estere tipo Na segunda op o o desenvolvedor usa o editor de casos de uso da ferramenta UseCaseAgent que oferece flexibilidade semelhante a um editor de textos 137 comum por m direcionando a cria o da especifica o de acordo com os elementos do UCModel Para atender s funcionalidades especificadas e necessidade de integra o da UseCaseAgent com a ferramenta UML foi selecionada a ferramenta BOUML PAG S 2011 como ferramenta UML A escolha da BOUML est baseada nas seguintes carac
154. car se a especifica o atende aos requisitos do usu rio 4 Criar e aprimorar modelos nessa fase um conjunto de modelos s o criados para a gera o da aplica o O WebTDD n o define qual abordagem usar nessa fase e 5 Execu o dos testes na aplica o os mesmo testes definidos na fase 2 s o re executados na aplica o final Caso seja reprovado volta ao passo 4 52 Caso seja aprovado esse conjunto de requisitos liberado e o processo reinicia com um novo conjunto de requisitos 3 3 Resumo Comparativo dos M todos Web A Tabela 3 4 resume as principais caracter sticas dos m todos selecionados pela revis o da literatura t cnica conduzida no escopo desta tese e dos m todos analisados por ESCALONA e KOCH 2004 Como a an lise realizada por ESCALONA e KOCH 2004 n o abrangia a verifica o de ferramentas nem a exist ncia de apoio a testes os artigos que relatam esses m todos tamb m foram lidos e analisados para verifica o desses itens Assim os valores resumidos na Tabela 3 4 foram extra dos dos artigos aprovados na revis o da literatura t cnica e dos artigos que relatam os 10 m todos analisados por ESCALONA e KOCH 2004 de acordo com a estrat gia de extra o de dados estabelecida no protocolo da revis o Tabela 3 4 Resumo dos m todos Web analisados M todo Requisitos An lise Especifica o Valida o Ferramenta Apoio a teste WSDM Linguagem natural
155. caso de uso e suas regras de neg cio dom nio usando o diagrama de atividades da UML 2 5 3 3 Fluxos do Caso de Uso A Tabela 5 7 apresenta os diferentes fluxos de execu o em um caso de uso e como esses elementos s o capturados pelo metamodelo UCModel A Figura 5 8 apresenta um extrato do metamodelo UCModel extrato da Figura 5 3 que destaca as metaclasses utilizadas para capturar os fluxos do caso de uso Cada fluxo possui uma sequ ncia de passos a es que especificam o comportamento do mesmo e cada fluxo alternativo e de exce o est associado a uma condi o usada para avaliar se ele deve ou n o ser executado Tabela 5 7 Mapeamento entre os fluxos do caso de uso e os elementos do metamodelo UCModel Informa o Elemento do Modelo Figura 5 8 Fluxo principal UseCase mainFlow 1 A es do fluxo principal UseCase mainFlow actions 5 Fluxo alternativo AlternativeFlow 2 A es do fluxo alternativo AlternativeFlow actions 5 Fluxo de exce o ExceptionFlow 3 A es do fluxo de exce o ExceptionFlow actions 5 Identificador do fluxo AlternativeFlow id 6 105 ExceptionFlow id Condi o de guarda dos fluxos AlternativeFlow condition ExceptionFlow condition Metamodelo da UML vis o parcial lt lt metaclass gt gt Activity lt lt metaclass gt gt Action Metamodelo UCModel visao parcial useCase
156. clicar na op o Regras na rvore esquerda mostrada a lista de regras associadas ao caso de uso Figura A 11 Atualmente n o existe nenhum apoio para compartilhamento de regras entre casos de uso Cada regra criada deve ser categorizada como 1 Regra Conceitual define uma restri o estrutural ou comportamento a ser observado pelo sistema em termos dos conceitos do dom nio 2 Regras de Apresenta o define restri es relacionadas interface entre o ator e o sistema seja ela uma interface gr fica ou de qualquer outra natureza 212 3 Regras de Navega o define restri es no acesso s informa es ou servi os disponibilizados pelo sistema Ap s a cria o das regras poss vel associ las aos passos do caso de uso usando a aba Regras durante a edi o dos fluxos principal alternativo ou de exce o r S Use Case Agent vers o 0 3 as ss oon i z Arquivo Verificar sos A Ei A UCModel amp Atores Regras do Caso de Uso 4 B Casos de Uso td Gj UCOO1 Autentica o do usu rio BR1 O login deve conter apenas letras Atores do Caso de Uso log PE BR2 JA senha deve iniciar com uma letra e ter letras d gitos e caracteres especiais Fluxo Principal E Fluxos Alternativos E Fluxos de Exce o E Erros Neg cio X m gt Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 11 Tela
157. cludeUCAction e ExtendUCAction 1 Deve referenciar um UseCase Formaliza o em OCL context ExecuteUCAction inv self uc gt notEmpty 5 3 6 12 Metaclasses ConceptualRule NavigationRule e PresentationRule 1 Descri o obrigat ria 2 Deve ser referenciada por pelo menos uma a o do UseCase Formaliza o em OCL context Rule P F inv self specification gt notEmpty inv self useCase mainFlow actions gt any rules gt any id self id or 124 self useCase alternativeFlows gt forAll af af actions gt any rules gt any id self id or self useCase exceptionFlows gt forAll ef ef actions gt any rules gt any id self id A estrutura do metamodelo apresentado na figura complementado pelo conjunto de restri es apresentadas nas se es anteriores formam a base te rica para organiza o de um apoio ferramental para cria o e valida o de descri es de casos de uso segundo o metamodelo UCModel definido no escopo deste trabalho 5 3 7 Perfil UML Todos os estere tipos definidos nas se es anteriores foram reunidos em um perfil UML chamado ProfileUCModel organizado com o objetivo de permitir a cria o de diagramas de atividades segundo os conceitos preconizados pelo metamodelo UCModel com o apoio de ferramentas UML capazes de tratar perfis UML A Figura 5 15 apresenta os estere tipos e tagged values definidos no ProfileUCModel
158. compra onde poss vel observar um conjunto de regras associadas ao c lculo do pedido 84 Essas regras descrevem uma s rie de condi es relacionadas ao desconto e c lculo do valor do frete que definem o comportamento esperado do sistema Nesse caso poss vel optar por detalhar esse comportamento atrav s de outro diagrama de atividades Figura 4 8 buscando eliminar qualquer ambig idade ou inconsist ncia em rela o descri o das regras em linguagem natural lt lt use case description gt gt id 5 actors Cliente summary Permite ao cliente fechar a compra ou seja realizar o pagamento e obter o n mero do pedido trigger Cliente aciona a op o fechar compra invariant N i ha criticality Alta frequencyofuse Alta UC005 Concluir compra lt lt precondition gt gt Cliente deve estar autenticado lt lt postcondition gt gt Cliente realiza o pagamento e obtem o n mero do pedido lista os produtos que constam do carrinho de compras lt lt system_response gt gt solicita a quantidade exclui o item selecionado lt lt system_response gt gt Cliente seleciona alterar item Cliente seleciona excluir item lt lt system action gt seleciona a op ao etetuar pagamento lt lt business_rule gt gt BRI E obrigat rio que o cliente informa a quantidade lt lt actor action gt tenha um desconto de 10 no valor do pedido se lt lt actor action gt gt ele tiver mais de 1000 00 em compras
159. condi o obrigat ria 8 Deve ter pelo menos um ator associado Formaliza o em OCL context UseCase inv self id gt notEmpty inv self name gt notEmpty 117 inv inv inv inv inv inv sel sel sel sel sel sel 5 3 6 2 Metaclasse Actor 1 Nome obrigat rio Formaliza o em OCL context Actor self name gt notEmpty inv 5 3 6 3 Metaclasse MainFlow gt description gt notEmpty criticality gt notEmpty frequencyofuse gt precondition specification gt notEmpty postcondition specification gt notEmpty actors gt size notEmpty JE 1 Deve possuir pelo menos uma transa o Formaliza o em OCL context MainFlow inv self action and s gt size gt 2 action gt Dat 0 ocl self s gt asSequenc IsTypeoO and f ActorAction self actions gt assSequ gt Dat 1 oc IsTypeo or se ae action TE s gt size nce f SystemAction gt 2 and action gt Dat 0 ocl se s gt asSequenc IsTypeo and f SystemAction self actions gt asSequ gt Dat 1 0cl or sel action IsTypeoOf s gt size nce SystemResponse gt 3 and self actions gt assSequ
160. controle do tipo fa a enquanto ou se ent o Por isso o conjunto de a es a ser executado sob determinada condi o deve ser definido como um fluxo alternativo ou de exce o Cada um dos fluxos definidos no caso de uso principal alternativos e de exce o s o descritos separadamente e possuem sub objetivos pr prios o que oferece a possibilidade de serem tratados e detalhados de forma independente Fluxos alternativos e de exce o possuem uma identifica o nica e uma express o de guarda que determina se estes devem ou n o serem executados Para cada a o poss vel definir os fluxos alternativos exce o que podem ser ativados a partir da mesma A ativa o do fluxo em determinado ponto do caso de uso est associada satisfa o da express o de guarda associada ao mesmo Regras definem restri es a serem observadas e est o sempre associadas as a es nas quais impactam Nome Descri o Atores Identifica o UC001 Autenticar usu rio Esse caso de uso permite que o usu rio fa a login na aplica o Internauta Criticalidade Alta Frequ ncia de uso M dia 82 Pr condi es P s condi es Trigger Fluxo Principal Fluxos de Exce o Regras Fluxos Alternativos O usu rio n o est autenticado O menu da aplica o apresentado de acordo com o perfil do usu rio Ator acessa qualquer p gina da aplica o 1 Sistema solicita login e s
161. crs gee arenes eee ea ree dO SEDA de once rere 11 2 2 Primeiro Estudo de Observa o a ereraseaaana 11 Ze o 1 o seer RR UR trite ner RR RIR RU RR DR RR iae 12 2 2 2 CONTEXTO adaa e RENA END E a RBD e COPE ra EPE 12 2 2 9 Projeto do ESTUDO xssisatcinetstivertieta ics a a E a gad ans 13 2 2 4 INSIUMENA O a ao O ce a dete 16 22 5 EROCUE O pia ga it io r a sea 16 2 3 Segundo Estudo de Observa o n rara 18 PES Pa RR O 0 51h 0 sarie PEN n hak teen ease RD bana A ins ha Fiat a tine Nd unease PR 18 COA COMO alas tara ate pondo SIE ST OS ga EURO EO gs E 18 2 3 9 Projeto do ESIU O sirp aea R E EEEE 18 2 3 4 IASTUMEMA O mA a A a 19 ZG OF EXOQUE O ses ticcoeren ance test ia E tecer A e A ios 20 2 4 Terceiro Estudo de Observa o arara 21 24A OBJEV neni cient sans Dori cuales teed a a a A an 21 PAZ CONTEXTO oea aa aa E e E A AE EAEE Eae ERRE E TRAA E EA RERE 21 2 4 3 Projeto do EStudo sisas aeaee eden E E EREE eens 22 2 4 4 INST AGA essa 4 Ack Rede tl cae ci a O a et ee ennn 22 24 5 EXCCU O panier Lada CR CI teenies dns a Lee 23 2 5 An lise dos Resultados dos Estudos a 26 2 5 1 An lise dos Resultados Quantitativos 26 2 5 2 An lise dos Dados Qualitativos nn rrreeana 29 2 6 Amea as Validade dos Estudos e arraaa 30 2 7 CONCIUSAO de an a OS Susa Sad enNio 32 M to
162. curso de p s gradua o na COPPE UFRJ Oito participantes assinaram o termo de consentimento e preencheram um formul rio de caracteriza o usado para avaliar sua experi ncia na ind stria de software e conhecimentos com rela o especifica o de requisitos inspe es de software e UML dentre outros Tomando por base as informa es do formul rio de caracteriza o os participantes foram classificados com n vel de experi ncia Baixa M dia Baixa M dia M dia Alta ou Alta O processo de classifica o dos participantes foi realizado por dois pesquisadores que analisaram os question rios de caracteriza o e chegaram a um consenso sobre o n vel de experi ncia de cada participante Essa classifica o foi posteriormente discutida com um terceiro pesquisador s nior para obten o da classifica o final 7 3 5 Projeto do Estudo A Tabela 7 5 apresenta a distribui o dos quatro casos de uso selecionados para o segundo estudo entre seus participantes Essa distribui o procurou equilibrar o n vel de complexidade dos casos de uso atribu dos a cada um dos participantes e para evitar efeitos colaterais relacionados ferramenta usada para especificar o caso de uso atribuiu a cada um deles diagramas de atividades criados tanto com a ferramenta UCA quanto com a ferramenta EDA Vale a pena ressaltar que os participantes n o foram informados se os casos de uso haviam sido especificados com uma ou outra ferramenta Al m disso
163. da o de requisitos preocupa se com o exame dos documentos de requisitos para averiguar se estes est o consistentes entre si em concord ncia com os requisitos elicitados e se contemplam as expectativas e necessidades dos usu rios poss vel observar na literatura t cnica algumas varia es a partir da dessas quatro atividades SOMMERVILLE 2006 prop e estas mesmas quatro atividades para a Engenharia de requisitos por m com um arranjo ligeiramente diferente as fases de elicita o e an lise s o fundidas como uma s atividade 62 denominada elicita o e an lise de requisitos LAMSWEERDE 2009 tamb m prop e essas quatro atividades por m a atividade de an lise de requisitos substitu da pela atividade de avalia o dos requisitos resolu o de conflitos e riscos dividindo as tarefas relacionadas an lise de requisitos entre a avalia o e a especifica o dos requisitos A abordagem proposta neste trabalho n o engloba quest es relacionadas elicita o dos requisitos Entretanto o uso dessa abordagem demanda a produ o de um conjunto de artefatos relacionados tanto com a An lise quanto com a Especifica o de requisitos pois a gera o desses artefatos se inicia com a an lise das informa es coletadas na elicita o e se completa com a obten o dos documentos de especifica o propriamente ditos Em virtude disso as atividades de An lise e Especifica o de requisitos da forma como
164. da Qualidade de Aplica es Web Jobson Luiz Massollar da Silva Rio de Janeiro UFRJ COPPE 2011 XIII 239 p il 29 7 cm Orientador Guilherme Horta Travassos Tese doutorado UFRJ COPPE Programa de Engenharia de Sistemas e Computa o 2011 Refer ncias Bibliogr ficas p 186 198 1 Engenharia de Aplica es Web 2 Engenharia de Requisitos 3 Especifica o e Verifica o de Requisitos 4 Engenharia de Software Experimental Travassos Guilherme Horta Il Universidade Federal do Rio de Janeiro COPPE Programa de Engenharia de Sistemas e Computa o Ill T tulo iii 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 UMA ABORDAGEM PARA ESPECIFICA O DE REQUISITOS DIRIGIDA POR MODELOS INTEGRADA AO CONTROLE DA QUALIDADE DE APLICA ES WEB Jobson Luiz Massollar da Silva Abril 201 1 Orientador Guilherme Horta Travassos Programa Engenharia de Sistemas e Computa o Esta tese prop e uma abordagem para especifica o estruturada de requisitos funcionais de aplica es Web que contempla quest es relacionadas garantia da qualidade dos requisitos e do produto final atrav s de um arcabou o para an lise classifica o e especifica o de requisitos alinhado aos conceitos explorados pelos m todos Web contempor neos Essa abordagem explora o tratamento das perspectivas de projeto Web conceitua o
165. da Sigo abas indi fed Boi UOL End cu aa T Eia 232 1 2 3 Test Case Data Variations serrana nana 232 1 3 Test Case TCO01 TIPS ks centieneedi andere ete 233 1 3 1 Test Gase Pai espa os up cece balks ens e ae a eaae e aeta deed iris ada tiin 233 1 3 2 Test Case Steps i ee araea AEREE sites saaRaa aaa aaa Fadas pass danada 234 1 3 3 Test Case Data Variations case SS 234 2 1 Class Diagram Category Diagram essere 236 2 1 1 Category SORA o a a ta ROTA SERRO 236 2 Ase atedory OCA I sarau conernhards wodaedi donates io A R reali ARAN 236 2 1 3 Category DadosPagamento as ssusapis nus jadsssa anda rasuabiasanfde usada Ras atas casada 236 2 NR PR Gategory A PLANO RR CRP RR RARE DRE DR DRE RE ii Ris 236 2 1 5 Category Boleto eee nadas dies as seach i dae aa nao aeb pda es ee dE da gated eae 236 2 16 Category Erno peter cats ca settee cat a a ack at doa let nesta nO ada 236 AP NDICE C Instrumentos do Estudo Experimental 239 C 1 Question rio do 1 estudo de observa o 239 C 2 Question rio do 3 estudo de observa o 240 NDICE DE FIGURAS Figura 1 1 Vis o geral da metodologia adotada 9 Figura 3 1 Metamodelo de requisitos do WRM 49 Figura 4 1 Perspectivas de projeto x caracter sticas dos modelos x fases de desenvolvimento adaptada de SCHWINGER e KOCH 2006 59 Fi
166. da lista de artigos aprovados 3 2 1 4 Estrat gia para Extra o de Dados Para cada artigo aprovado pelos crit rios e procedimentos de sele o dever o ser extra dos e Descri o do m todo e Artefatos gerados durante o tratamento de requisitos e T cnicas adotadas para an lise especifica o valida o dos requisitos e Ferramenta para apoiar a fase de tratamento de requisitos e 37 e Exist ncia de apoio para gera o de testes a partir dos requisitos 3 2 2 Execu o da Revis o A string de busca foi executada por ano de 2004 a 2010 para facilitar a recupera o e gerenciamento da lista de artigos candidatos A Tabela 3 1 e a Tabela 3 2 resumem os dados da execu o Tabela 3 1 Resumo da execu o da revis o da literatura Ano No de artigos No de artigos No de artigos No de artigos recuperados selecionados indispon veis aprovados 2004 234 6 0 1 2005 260 2 0 2 2006 324 7 0 5 2007 404 7 0 3 2008 388 8 2 2 2009 392 6 0 4 2010 359 11 4 4 Total 2361 47 6 21 Tabela 3 2 Distribui o dos 21 artigos aprovados pelos m todos Web Ano M todo No de Refer ncias artigos 2004 WebGen 1 LOH e ROBEY 2004 2005 AWDP 1 WOOKUJIN et al 2005 OOWS 1 VALDERAS et al 2005 2006 WebML 1 MORENO et al 2006 WebRE 2 ESCALONA e KOCH 2006 KOCH et al 2006 HM3 C CERES et al 2006 Modelage
167. das aplica es pode ter influenciado nessa avalia o j que nesse caso a predisposi o do participante em usar ou n o as perspectivas pode suplantar a real necessidade de represent las Por outro lado essa dispers o pode ser um ind cio de que a explora o de todas essas perspectivas s fa a sentido caso alguma caracter stica relacionada aplica o direcione para essa demanda A ltima opini o da pergunta 2 revela um comportamento que pode ser recorrente o participante considerou os modelos dispens veis porque n o enxergou como esses modelos poderiam auxiliar em atividades posteriores Al m disso a an lise dos diagramas de apresenta o constru dos pelas equipes mostrou que eles foram explorados de forma muito superficial em rela o ao detalhamento apresentado nos demais artefatos como casos de uso e o modelos de classe As raz es para esse desbalanceamento n o puderam ser capturadas neste estudo por m a abstra o proporcionada pelos diagramas de apresenta o pode ter influenciado nesse ponto Um item que n o pode ser negligenciado nesse estudo foi o pouco apoio proporcionado pela ferramenta Poseidon for UML for Community Edition constru o de modelos baseados na UML que adotam sem nticas adicionais para os elementos dos diagramas atrav s do uso de estere tipos esse apoio existe mas est dispon vel somente nas vers es comerciais da ferramenta O ideal nesse caso seria a utiliza o de uma ferram
168. de tarefas associadas ao ator ou do sistema mas n o a ambos Os autores prop em o uso do CTT PATERNO et al 1997 para descri o dessa taxonomia de tarefas Para descri o das tarefas elementares usada uma nota o inspirada no diagramas de atividade da UML OMG 2010a mas que lan a m o de v rios construtores espec ficos e com sem ntica pr pria para definir as a es b sicas e as informa es que elas manipulam Nessa fase tamb m s o constru dos templates para definir a informa o a ser armazenada no sistema ou seja os requisitos de dados A partir da descri o das tarefas elementares e dos requisitos de dados s o aplicadas transforma es para gera o dos modelos navegacionais conforme preconizados pelo OOWS Os modelos navegacionais representam vis es do modelo conceitual e especificam as estruturas de acesso informa o para cada tipo de usu rio identificado na elicita o de requisitos A cria o do modelo navegacional dividida em duas atividades 1 Gest o de Usu rios onde s o capturados todos os poss veis atores da aplica o e suas associa es e 2 Especifica o de Propriedades Navegacionais onde s o definidos os contextos navegacionais para cada ator ou seja que informa es e servi os estar o acess veis atrav s da navega o 3 2 3 15 WebRE Web Requirements Engineering O WebRE ESCALONA e KOCH 2006 KOCH et al 2006 re ne conceitos dos m todos NDT e UWE e define um
169. de uso a es do sistema descritas no n vel de intera o ator sistema o que o sistema faz e e No segundo n vel n vel do comportamento sist mico a es do sistema que descrevem o comportamento interno do mesmo como o sistema faz importante ressaltar que o segundo n vel n o se refere implementa o mas sim ao refinamento do comportamento esperado que normalmente reflete algum procedimento relacionado ao dom nio do problema 86 Essa separa o de abstra es refor a o n vel em que deve ser descrito o caso de uso e oferece um mecanismo coerente para descri o do comportamento do sistema em diversos n veis de abstra o usando sempre o mesmo formalismo de representa o diagramas de atividades 4 6 Inspe o de Requisitos Uma forma de minimizar defeitos nas especifica es de casos de uso a aplica o de t cnicas de avalia o est tica para controlar a sua qualidade Dentre essas t cnicas as de inspe o t m se mostrado um importante mecanismo de aprimoramento da qualidade do software FAGAN 1976 ACKERMAN et al 1989 Embora as t cnicas de inspe o ad hoc tenham o seu valor e sejam efetivas em muitos casos aquelas com um foco bem definido por exemplo t cnicas baseadas em checklist ou t cnicas de leitura baseadas em perspectivas tendem a produzir melhores resultados no que diz respeito ao n mero de defeitos detectados e ou produtividade defeitos detectados por unidade de temp
170. demais casos de uso pois foi o nico no qual o n mero 175 de defeitos na especifica o com UCA aumentou em compara o com EDA destacado em cinza na Tabela 7 6 A an lise dos defeitos apontados pelos inspetores revelou que um nico inspetor dos oito que realizaram a inspe o relatou 7 defeitos relacionados ao n vel de abstra o das descri es das a es desse caso de uso Nenhum dos outros sete inspetores considerou isso um defeito o que causou o desbalanceamento somente neste caso de uso Tabela 7 6 N mero de defeitos reportados por caso de uso e ferramenta Ferramenta Caso de N vel de N mero de defeitos Mediana Uso complexidade reportados 6 Baixa 11 15 Alta 18 EEA 36 M dia Baixa 24 ae 10 5 40 M dia Alta 39 6 Baixa 7 15 Alta 22 cia 36 M dia Baixa 10 A 7 0 40 M dia Alta 32 Os boxplots com a distribui o de defeitos por tipo de especifica o Figura 7 3 mostram que o n mero de defeitos reportados para casos de uso especificados com UCA menor que o n mero de defeitos reportados para casos de uso especificados com EDA A an lise dos boxplots nos permite observar que e H ind cios de que o n mero de defeitos dos casos de uso especificados com UCA seja menor que o n mero de defeitos dos casos de uso especificados com ADE pois a mediana de defeitos para distribui o UCA menor que a mediana para a distribui o EDA e H ind cios de qu
171. desses cen rios s o obtidos os modelos conceituais modelos de 39 classes e no pr ximo passo as classes s o agrupadas em unidades navegacionais e o modelo de navega o gerado Por fim as p ginas Web a interface com o usu rio e o banco de dados s o implementados 3 2 3 3 RNA Relationship Navigation Analisys RNA BIEBER et al 1998 n o um m todo para an lise mas sim um m todo que prev uma s rie de atividades a serem executadas durante a fase de an lise An lise do ambiente caracter sticas do p blico alvo s o avaliadas e classificadas de forma semelhante ao que ocorre na modelagem de usu rios do WSDM e An lise dos elementos de interesse s o definidas telas documentos relat rios dados dentre outros e An lise do conhecimento defini o do esquema da aplica o com a identifica o de objetos processos e opera es e seus relacionamentos e An lise da navega o o esquema definido na fase anterior enriquecido e incrementado com componentes espec ficos para dar suporte navega o e e Implementa o da an lise define como os modelos produzidos ser o convertidos para uma linguagem de programa o O RNA n o define uma nota o nem tampouco orienta es para modelagem apenas orienta es sobre as a es a serem executadas em cada fase do m todo 3 2 3 4 HFPM Hypermedia Flexible Process Modeling O m todo HFPM OLSINA 1998 cobre todo o ciclo de vida do desenvol
172. desses estudos foi tentar compreender de forma mais detalhada o uso dos modelos propostos pelos m todos Web em um processo de desenvolvimento e coletar dados qualitativos acerca do seu uso O Cap tulo 2 apresenta esses tr s estudos e discute os resultados obtidos Ao final dos tr s estudos de observa o preliminares a an lise dos dados obtidos indicou a adequa o dos requisitos e o apoio ferramental como dois fatores cr ticos para o sucesso da explora o dos modelos Web propostos na literatura t cnica Dessa forma uma revis o da literatura foi conduzida com o objetivo de caracterizar os m todos Web propostos na literatura t cnica com respeito ao tratamento dos requisitos O Cap tulo 3 apresenta o protocolo adotado nessa revis o e sumariza os resultados da an lise de 24 m todos de desenvolvimento Web selecionados nessa revis o o Ss a T v lt a o a a v lt 5 e E Q 0 SHULL et al 2001 Figura 1 1 Visao geral da metodologia adotada Tanto os tr s estudos de observa o preliminares Cap tulo 2 quanto a revis o da literatura Cap tulo 3 forneceram subs dios para a defini o da abordagem apresentada nesta tese que encontra se detalhada juntamente com as ferramentas que a ap ia nos Cap tulos 4 5 e 6 Por ltimo foram realizados dois estudos de viabilidade com o objetivo de caracterizar a abordagem e verificar a viabilidade de seu uso Esses estudo est o detal
173. diagramas de atividades aderentes ao metamodelo proposto al m de exemplos de como tais elementos s o representados nesses diagramas 5 3 1 Caso de Uso e seus Elementos B sicos A Tabela 5 2 apresenta o caso de uso e seus elementos b sicos conforme organizado na Tabela 4 10 p gina 81 e como esses elementos s o capturados pelo 99 metamodelo UCModel A Figura 5 4 apresenta uma parte do metamodelo UCModel retirado da Figura 5 3 que destaca as metaclasses utilizadas para capturar o caso de uso e seus elementos b sicos A primeira coluna da Tabela 5 2 define a informa o a ser capturada enquanto a segunda coluna indica o elemento do metamodelo UCModel usado para representar essa informa o A terceira coluna da Tabela 5 2 indica em que parte do metamodelo UCModel Figura 5 4 est o elemento referenciado Tabela 5 2 Mapeamento entre as informa es b sicas do caso de uso e os elementos do metamodelo UCModel Informa o Elemento do UCModel Figura 5 4 Caso de Uso UseCase 1 ID UseCase id 1 Nome UseCase name 3 Descri o UseCase summary 1 Criticalidade UseCase criticality 1 Frequ ncia de uso UseCase frequencyofuse 1 Ator es UseCase actors 2 Trigger UseCase trigger 1 Pr condi o UseCase precondition 4 P s condi o UseCase postcondition 4 Metamodelo da UML vis o parcial lt lt metaclass gt gt lt lt metaclass gt gt Activity D gt gt E
174. do UseCaseAgent para cria o de regras Atualmente a categoriza o das regras em regras conceitual regras de apresenta o e regras de navega o n o tem nenhum desdobramento ou cr tica em termos de descri o do caso de uso Entretanto essa classifica o pode auxiliar em fases posteriores do desenvolvimento A 12 Verifica o Sint tica A qualquer instante o desenvolvedor poder acionar a op o Verificar para checar a sintaxe da especifica o do caso de uso Caso algum erro seja detectado o mesmo poder ser visualizado acionando a op o Erros da rvore esquerda Figura A 12 Para dada erro o UseCaseAgent apresenta a sua localiza o a fim de facilitar a corre o importante ressaltar que a verifica o automaticamente chamada quando a op o Salvar acionada e que caso algum erro seja detectado a opera o de salvar ser cancelada 213 Use Case Agent vers o 03 e a Seeks Arquivo Verificar Posi o Descri o S J Casos de Uso 5 A descri o da a o obrigat ria UCO01 Autentica o do usu rio 5 Uma a o do ator n o pode ser a ltima a o de um fluxo 4 Atores do Caso de Uso Fluxo Principal Fluxos Alternativos Fluxos de Exce o Edy Regras ros Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 12 Tela do UseCaseAgent com a lista de erros sint ticos e suas localiza es
175. do a complexidade calculada a partir dessa f rmula demonstra se coerente em virtude do contexto e das caracter sticas do ambiente onde esses casos de uso foram especificados e Todos os casos de uso descreviam funcionalidades pertencentes ao mesmo dom nio de problema e Todos os casos de uso foram descritos pela mesma equipe de requisitos ou seja o estilo de reda o dos casos de uso era bastante semelhante e Todos os casos de uso foram elicitados com o mesmo stakeholder e e Todos os casos de uso adotaram o mesmo gabarito na sua descri o A Tabela 5 1 apresenta o c lculo de complexidade para os dez casos de uso selecionados A partir desses n meros foram calculadas a m dia 74 63 e o desvio padr o 28 91 da amostra e a partir desses valores foram criados 4 faixas com os limites m dia 2 x desvio padr o m dia desvio padr o m dia desvio padr o e m dia 2 x desvio padr o Cada uma dessas faixas foi associada aos valores ordinais Baixo M dio Baixo M dio Alto e Alto A faixa em que o caso de uso posicionado determina o seu n vel de complexidade Figura 5 1 O n vel de complexidade foi usado posteriormente para apoiar a distribui o dos casos de uso entre os participantes de forma mais equilibrada Tabela 7 1 C lculo da complexidade dos casos de uso Caso de uso N de a es do N mero de N mero de Complexidade fluxo principal fluxos regras alte
176. do modelo F Complexidade do diagrama G Ordem com que os modelos foram constru dos H Divis o de tarefas responsabilidades entre a equipe I Perspectiva de projeto usada pela equipe inconsistente cq a 5 T Aten o a ordem importante De cada 3 fatores escolhidos o 1 fator representa o que trouxe mais dificuldade e o 3 fator menos 1 fator 2 fator 3 fator Diagrama de classes Diagrama de sequ ncia Diagrama de estado Diagrama de atividades Mapa de atores Modelo navegacional 240 4 Nasua opini o o que poderia ser feito para diminuir o esfor o com estes modelos Iniciativas para diminui o do esfor o Diagrama de classes Diagrama de sequ ncia Diagrama de estado Diagrama de atividades Mapa de atores Modelo navegacional 241
177. dos de Desenvolvimento de Aplica es Web 34 3 1 aig o Uier Va ane ue De e ENA EE PERE rd PEE BEER ORE DARE A SR Uy PERO RR RR 34 3 2 Revis o da Literatura sobre M todos de Desenvolvimento de Aplica es Web 35 3 2 1 YRFOIOGOIO da REVISAO ei laedi nadia tens aparar eee 35 3 2 2 Exec o da REVIS O esmas costs spread A ceeds anais 38 3 2 3 Resultados obtidos com a An lise dos Estudos 39 3 3 Resumo Comparativo dos M todos Web n s nennen renerne 53 3 4 Conirbui es da Revis o ste papa garestonatsenpiisenes uceanntitinacas tawtacteesmmesten sane 54 3 5 CONICS AO Far sas ads ed ad LO ad EU sa ate ot eda heat alt 55 Abordagem para Especifica o de Requisitos 57 4 1 WTOC WCAG seann rash doses cat a oes RR RR RR CR yan hel 57 4 2 Vis o Geral da Abordagem esses en teatieteeatierecent siotertautet aati ie dial eles 58 4 2 1 Perspectiva de Conceitua o icvccicissicceecetvceeisteeccnceetedensivedincedeetasedeecde 60 4 2 2 Perspectiva de Navega o seeeseeessesrstrrrrrttssrrrrrrrnnrrssrrrrnnrnnnnesernnee 60 4 2 3 Perspectiva de Apresenta o sesessesssnerrrreeserrtrrrrnrrrssrrrrnrrnnnnesrerrnee 61 4 2 4 Linguagem de Modelagem aerea 61 vi 4 3 Processo de Engenharia de Requisitos 62 4 4 Classifica o de Requisitos rrenan 64 4 5 Especifica o de Requisitos aa asas past saat users EST aaa 67 4 5 1 Mode
178. e dadosPagamentol data invalida or dadosPagamentol desconto invalido or ros invalidos or dadosPagamentol valor final invalido informa os dados do pagamento actor action lt lt business_rule gt By lt lt business rule gt gt lt lt business rule gt gt informa que a senha inv lida system response solicita a senha system response lt lt business rule gt s fornece a senha actor action informa que a senha inv lida e que nhhy invalida and errot encontra se bloqueada system response senhal invalida and errol 3 apresenta o comprovante de pagamento do boleto system response 233 1 3 2 Test Case Steps 1 solicita a fonte de recurso de onde ser debitado o pagamento system lt no description gt response 2 seleciona uma das op es actor action lt no description gt 3 informa que deve ser selecionada uma op o system response lt no description gt 4 solicita a fonte de recurso de onde ser debitado o pagamento system lt no description gt response 5 seleciona uma das op es actor action lt no description gt 6 solicita o n mero do boleto system response lt no description gt 7 solicita que o cliente fa a a leitura eletr nica do boleto system lt no description gt response 8 realiza a leitura eletr nica actor action lt no description gt 9 informa
179. e Constraint do metamodelo da UML por esta representar restri es ou condi es que afetam o elemento ao qual est o associadas Tabela 5 5 Mapeamento entre as regras e os elementos do metamodelo UCModel Informa o Elemento do UCModel Figura 5 6 Regras ConceptualRule 1 NaviagtionRule PresentationRule Associa o de regras UseCase rules 2 com casos de uso Associa o de regras Action Rules 3 com a es 103 Metamodelo da UML vis o parcial lt lt metaclass gt gt Action lt lt metaclass gt gt lt lt metaclass gt gt Constraint Activity specification ESS E S Z7 ZS Metamodelo UCModel visao parcial useCase f 1 mainFlow 1 parent rules ConceptualRule NavigationRule PresentationRule complement Do Figura 5 6 Vis o parcial do metamodelo UCModel referente s regras de neg cio dom nio e sua rela o com o metamodelo da UML Representa o no Diagrama de Atividades Para representar os tr s tipos de regras de neg cio dom nio ConceptualRule NavigationRule e PresentationRule da Tabela 5 5 no diagrama de atividades foram definidos tr s estere tipos conforme detalhado na Tabela 5 6 Tabela 5 6 Estere tipos usados na defini o de regras de neg cio dom nio Estere tipo Tipo base Defini o lt lt conceptual rule gt gt Con
180. e Criticalidade Alta Frequ ncia de uso Alta Pr condi es Cliente dever estar autenticado no sistema de home banking Invariantes N o h P s condi es Cliente obt m o comprovante de pagamento do boleto Trigger Cliente aciona a op o de pagamento de boleto Fluxo Principal 1 Sistema solicita a fonte de recurso de onde ser debitado o pagamento O sistema deve apresentar duas op o para fonte de recurso conta corrente conta poupan a 2 Cliente seleciona uma das op es 3 Sistema valida a op o selecionada BR 1 4 Sistema solicita o n mero do boleto A1 5 Cliente digita o n mero do boleto A2 6 Sistema valida o n mero do boleto BR2 BR4 7 Sistema solicita os dados relativos ao pagamento A3 A4 NR3 Os dados a serem solicitados s o data de pagamento valor do boleto valor do desconto juros valor a ser pago 8 Cliente informa os dados do pagamento 9 Sistema valida os dados do pagamento BR5 BR6 BR7 BR8 BR9 10 Sistema solicita a senha A5 11 Cliente fornece a senha 12 Sistema valida a senha BR1 1 146 Fluxos Alternativos Fluxos de Exce o Regras 13 Sistema debita o valor a ser pago da fonte de recurso selecionada A6 A7 14 Sistema registra o boleto como pago na fonte de recurso selecionada 15 Sistema apresenta o comprovante de pagamento do boleto Os dados do comprovante s o nome do correntista data e hora do pagamento
181. e Qtde Qtde de Qtde de N s Qtde de Requisitos Casos de de Classes Navegacionais Classes de Uso Atores Conceituais Projeto 1 21 4 2 11 4 21 2 15 19 4 10 17 3 9 5 3 11 17 32 4 16 12 3 10 21 13 5 19 9 3 4 16 Quanto ao question rio onze dos quinze participantes responderam s duas quest es formuladas 1 Facilidades dificuldades provocadas pelo uso das perspectivas quatro participantes responderam que as perspectivas facilitaram tr s responderam que as perspectivas n o trouxeram nem dificuldades nem www gentleware com 16 facilidades dois apontaram dificuldades e um considerou as perspectivas dispens veis 2 Aplicabilidade do modelo navegacional e do modelo de apresenta o sete consideraram que os modelos puderam ser desenvolvidos e aplicados ao projeto sendo que um destes destacou a alta complexidade dos diagramas de navega o e outro considerou o mapa de atores sem utilidade em aplica es de pequeno porte Dois participantes questionaram a aplicabilidade dos diagramas de navega o e apresenta o em aplica es de pequeno porte Um dos participantes questionou a aplicabilidade dos diagramas de navega o e dos templates e diagramas de apresenta o enquanto elementos de comunica o com o web designer De acordo com o que foi descrito no item 1 houve uma dispers o de opini o com rela o ao benef cio do uso das perspectivas de projeto A baixa complexidade
182. e casos de uso especificados com UCA s o mais est veis em termos de n mero de defeitos n o sofrendo tanto a influ ncia de fatores externos quanto os casos de uso especificados com EDA Esse ind cio sustentado pelo intervalo quart lico mais concentrado do boxplot UCA em rela o ao boxplot EDA que se apresenta mais disperso e e H ind cios de que a diferen a entre o n mero de defeitos apresentados por UCA e EDA seja estatisticamente significativa pois todo o intervalo quart lico do boxplot da distribui o de UCA ou seja pelo menos 75 da amostra est abaixo da mediana de defeitos da distribui o de EDA Na Figura 7 3 a ferramenta EDA est representada pelo r tulo ADE Activity Diagram Editor 176 O teste estat stico t de Student confirmou que o n mero de defeitos reportados para os casos de uso especificados com UCA significativamente menor que o n mero de defeitos reportados para os casos de uso especificados com EDA a 0 05 defects 15 10 E 0 ADE UCA Each Pair Tool Student s t es 0 05 Means and Std Deviations Level Number Mean Std Dev Std Err Mean Lower 95 Upper 95 ADE 16 6 43750 3 82916 0 95729 4 4765 8 3984 UCA 14 3 71429 2 70124 0 72194 2 2355 5 1931 Means Comparisons Dif Mean i Mean j ADE UCA ADE 0 00000 2 72321 UCA 2 72321 0 00000 Alpha 0 05 Comparisons for each pair using Student s t t 2 04841 Abs Dif LSD ADE UCA ADE 2 42832 0 20566 UCA 0 20966 2 59598
183. e ent o casos de uso t m sido explorados em muitos outros processos JACOBSON et al 1999 KRUCHTEN 2004 ROSENBERG e STEPHENS 2007 e hoje em dia eles n o tem seu uso limitado s abordagens orientadas objetos Atualmente casos de uso fazem parte da especifica o da UML OMG 2010a sendo definidos como a especifica o de um conjunto de a es realizadas por um sistema que produz um resultado observ vel que normalmente de valor para um ou mais atores ou outros stakeholders do sistema 4 5 3 2 Descri o de Casos de Uso A especifica o da UML n o define um padr o para descri o de casos de uso embora sugira algumas op es 1 Atrav s de um tipo Collaboration que representa a estrutura e o relacionamento de uma cole o de inst ncias que realizam coletivamente uma funcionalidade desejada 79 2 Atrav s de pr e p s condi es 3 Atrav s de linguagem natural 4 Atrav s de um tipo Behavior o que permite a representa o usando uma m quina de estados ou um diagrama de atividades ou 5 Atrav s de uma combina o das op es anteriores O uso da linguagem natural para descri o de casos de uso encorajado por profissionais da pr tica e por alguns m todos de desenvolvimento JACOBSON et al 1999 COCKBURN 2000 ARMOUR e MILLER 2001 KRUCHTEN 2004 ROSENBERG e STEPHENS 2007 Entretanto a especifica o da UML n o define se essa representa o textual deve ser feita at
184. e na descri o textual Figura 5 17 s o id nticas Na pr tica a descri o textual apresentada na Figura 5 17 foi gerada automaticamente a partir do diagrama de atividades da Figura 5 16 com o apoio ferramental que ser detalhado no Cap tulo 6 128 UC001 Autenticar usu rio lt lt precondition gt gt 4 lt lt postcondition gt gt solicita login e senha juntamente com uma op o Esqueci a senha lt lt system response gt avisa que o login ou a senha s o inv lidos lt lt system response gt valida login e senha lt lt system action gt gt Login ou senha invalida 13 apresenta o menu da aplica o de acordo com o perfil do usu rio lt lt system response gt gt Figura 5 16 Diagrama de atividades com a descri o do caso de uso da Figura 5 17 lt lt use case description gt gt id 1 actors internauta summary Esse caso de uso permite que o usu rio fa a login na aplica o trigger Ator acessa qualquer p gina da aplica o criticality Alta frequencyofuse M dia O ator n o est autenticado O menu da aplica o apresentado de acordo com o perfil do usu rio lt lt conceptual_rule gt gt R1 obrigat rio que o Login esteja registrado como v lido 7 lt lt conceptual_rule gt gt R1 obrigat rio que o Login esteja registrado como v lido lt lt conceptual rule gt R2 obrigat rio que a senha fornecida seja id ntica lt lt conceptual
185. e ser observado na literatura t cnica HENNICKER e KOCH 2000 PASTOR et al 2001 CACHERO e KOCH 2002 CACHERO et al 2002 ESCALONA et al 2007 com pequenas varia es de um m todo para outro A Tabela 4 2 lista os artefatos organizados para representar os aspectos estrutural e comportamental dessa perspectiva Os artefatos sugeridos nessa tabela devem ser usados em pares obedecendo sempre a mesma numera o Por exemplo se a op o de representa o da vis o estrutural for 1a a op o para representa o da vis o comportamental deve ser 1b e assim por diante 60 Tabela 4 2 Artefatos para representa o dos requisitos na perspectiva de navega o Estrutural 1a Detalhamento da intera o ator sistema na descri o do caso de uso ou seja em linguagem natural 2a Modelos navegacionais usados nos m todos Web Por exemplo UWE Modelo do Espa o Navegacional OOWS Diagrama de Contexto Navegacional e Diagrama de Navega o 3a Prot tipos da interface ou mockups Comportamental 1b Regras em linguagem natural estruturada associadas descri o do caso de uso 2b Restri es associadas ao modelos navegacionais 3b Pode ser representado no pr prio prot tipo atrav s de anota es ou usar regras em linguagem natural estruturada associadas descri o do caso de uso 4 2 3 Perspectiva de Apresenta o A perspectiva de Apresenta o se prop e a representar caracter s
186. e ser sucedida por uma nica a o Deve ser sucedida por uma SystemAction GotoAction IncludeUCAction ou ExtendUCAction Formaliza o em OCL context ActorActio inv inv inv inv inv n self name gt notEmpty self actor gt notEmpty self order lt self parent gt size self outgoing gt size 1 self outgoing target oclIsType0Of SystemAction or self outgoing target oclIsType0Of GotoAction or self outgoing target oclIsType0Of IncludeUCAction or self outgoing target oclIsType0Of ExtendUCAction 5 3 6 7 Metaclasse SystemAction 1 2 Descri o obrigat ria Se estiver no fluxo principal deve ser sucedida por no m ximo uma a o do tipo SystemAction SystemResponse GotoAction IncludeUCAction ou ExtendUCAction Se estiver no fluxo alternativo ou de exce o deve ser sucedida por uma nica a o do tipo SystemAction SystemResponse GotoAction FinishAction IncludeUCAction ou ExtendUCAction Formaliza o em OCL context SystemAction inv inv self name gt notEmpty self parent oclisTypeOf MainFlow implies self outgoing gt size lt 1 and self outgoing target oclisTypeOf SystemAction or 121 inv self outgoing targ
187. ectivas de projeto Web Tabela 5 8 Tabela 5 8 Principais tipos de a es previstos pelo metamodelo UCModel Tipo da A o Descri o Perspectiva Web ActorAction Representa uma intera o do ator com o Apresenta o e sistema na qual este faz uma requisi o ao Navega o sistema informando os dados necess rios SystemAction Representa uma a o do sistema cujos Conceitua o resultados gerados n o s o diretamente observados pelo ator E usada para explicitar o tratamento dado requisi o do ator Esta a o est normalmente associada a recupera o de informa es altera o do estado interno do sistema e gera o de resultados que ser o posteriormente apresentados SystemResponse Representa uma a o do sistema cujos Apresenta o e resultados s o direta ou indiretamente Navega o observados pelo ator Essa a o pode apresentar resultados gerados anteriormente ou solicitar outros dados ao ator Alguns trabalhos da literatura t cnica tratam a a o do sistema e a resposta do sistema como um s elemento que normalmente chamado de a o do sistema KOSTERS et al 2001 DURAN et al 2002 GUTI RREZ et al 2008 LU e SONG 2008 Todavia as perspectivas associadas a cada uma dessas a es revelam diferen as sutis por m importantes enquanto a SystemAction lida com conceitos do 109 dom nio do problema que comp em a estrutura interna do sistema a SystemResp
188. el Based Testing APFELBAUM e DOYLE 1997 modelos s o usados para descrever os v rios elementos relacionados ao Teste de Software dentre eles os casos e procedimentos de teste Em rela o aos testes funcionais esses modelos s o obtidos a partir das especifica es funcionais do sistema Algumas abordagens na literatura exploram a gera o dos casos e procedimentos de teste a partir de casos de uso e modelos de teste HARTMANN et al 2005 G IS et al 2010 Nestes casos por m a cria o dos modelos de teste fica sob inteira responsabilidade do Analista de Testes pois estas abordagens n o definem como construir estes modelos a partir da especifica o dos requisitos A abordagem proposta neste trabalho usa como base a especifica o dos casos de uso estruturada de acordo com o UCModel e define um conjunto de regras de transforma o que ap ia a gera o autom tica dos modelos preliminares de testes funcionais diretamente a partir dessa especifica o Para constru o do modelo de testes foi adotado por oportunidade e conveni ncia o metamodelo TDE HARTMANN et al 2005 Esse metamodelo foi selecionado em virtude do conhecimento pr vio de membros do grupo de Engenharia de Software Experimental ESE da UFRJ sobre esse modelo e da colabora o existente entre o grupo ESE e a Siemens Corporation Research USA onde esse metamodelo foi desenvolvido e atualmente explorado em projetos reais de larga escala com o apoio de
189. elo da UML lt smetaclass gt gt constrainedElement sm Element 1 vis o parcial lt lt metaclass gt gt NamedElement ESSES ZS lt lt metaclass gt gt lt lt metaclass gt gt ActivityEdge incoming outgoing 1 target lt lt metaclass gt gt lt lt metaclass gt gt ActivityNode source 4 precondition lt lt metaclass gt gt lt metaclass gt gt lt lt metaclass gt gt ControlNode ExecutableNode o Constramt E ESSA postcondition El 3 te lt lt metaclass gt gt lt metaclass gt lt lt metaclass gt gt lt lt metaclass gt gt InitialNode ActivityFinalNode DecisionNode Action Ze Metamodelo UCModel useCase useCase 1 ConditionalFlow iai MainFlow ainFlow condition id 1 exceptipnFlows 1 parent alternativeFlows ExceptionFlow target excegtionFlows alternativeFlows E ici caller BehavioralAction gt SystemResponse SystemAction Figura 5 3 Metamodelo UCModel e seu relacionamento com o metamodelo da UML As se es 5 3 1 a 5 3 4 detalham cada elemento do metamodelo UCModel e apresentam os estere tipos e tagged values definidos para constru o de
190. ements Engineering WER 04 pp 100 111 BELGAMO A FABBRI S MALDONADO J C 2005 Avaliando a Qualidade da T cnica GUCCRA com T cnica de Inspe o Proceedings of the VIII Workshop on Requirements Engineering WER 05 BERNARDI M L CIMITILE M DISTANTE D MAZZONE F 2010 Web Application Design Evolution with UWA Proceedings of 12 IEEE International Symposium on Web System Evolution pp 3 12 BEZIVIN J 2006 Model Driven Engineering An Emerging Technical Space LNCS v 4148 pp 36 64 BIEBER M GALNARES R LU Q 1998 Web Engineering and Flexible Hypermedia Proceedings of the 2 Workshop on Adaptive Hypertext and Hypermedia Hypertext 98 BIOLCHINI J C D A MIAN P G NATALI A C C CONTE T TRAVASSOS G H 2007 Scientific research ontology to support systematic review in software engineering Advanced Engineering Informatics v 21 n 2 pp 133 151 BITTNER K SPENCE I 2002 Use Case Modeling Addison Wesley BOEHM B W BASILI V R 2001 Software Defect Reduction Top 10 List IEEE Computer v 34 n 1 pp 135 137 BOOCH G MAKSIMCHUK R A ENGLE M W YOUNG B J CONALLEN J HOUSTON K 2007 Object Oriented Analysis and Design with Applications Addison Wesley 3a edi o C CERES P De CASTRO V VARA J M MARCOS E 2006 Model Transformations for Hypertext Modeling on Web Information Systems
191. en rio uma ferramenta denominada UseCaseAgent foi definida e implementada com o objetivo de apoiar a constru o e verifica o sint tica de especifica es de casos de uso segundo os conceitos preconizados pelo UCModel al m de permitir a gera o da descri o textual do caso de uso a partir do seu diagrama de atividades No segundo cen rio o conjunto de orienta es definido a partir da sem ntica do UCModel apoiou a elabora o de um conjunto de quest es de uma t cnica customizavel de inspe o de diagramas de atividades baseada em checklist chamada ActCheck MELLO 2011 Adicionalmente a descri o textual do caso de uso obtida a partir do diagrama de atividades oferece a possibilidade do uso de t cnicas de inspe o de casos de uso n o especificamente projetadas a partir dos conceitos do metamodelo UCModel mas alinhadas conceitualmente com a estrutura de especifica o preconizada por esse metamodelo Como exemplo duas t cnicas desenvolvidas por pesquisadores brasileiros podem ser aplicadas nesse contexto a t cnica GUCCRA BELGAMO e FABBRI 2004 e a t cnica desenvolvida por GREGOLIN e DEBONI 2008 ambas avaliadas experimentalmente BELGAMO et al 2005 SANTOS e TRAVASSOS 2010 Para o terceiro cen rio uma outra ferramenta denominada ModelT ALBUQUERQUE et al 29010 tamb m foi definida e implementada com o objetivo de derivar modelos de testes funcionais a partir dos modelos de especifica o Dessa for
192. enha juntamente com uma op o Esqueci a senha 2 Internauta fornece login e senha A1 3 Sistema valida login e senha R1 R2 4 Sistema apresenta o menu da aplica o de acordo com o perfil do usu rio A2 A1 Internauta seleciona Esqueci a senha A1 1 Sistema solicita o login A1 2 Internauta fornece o login A1 3 Sistema valida o login R1 A1 4 Sistema gera uma senha tempor ria R3 A1 5 Sistema envia a senha tempor ria para o email do internauta E 1 A1 6 Sistema registra a nova senha A1 7 Sistema avisa para qual email a senha tempor ria foi enviada A2 Login ou senha inv lida A2 1 Sistema avisa que o login ou a senha s o inv lidos A2 2 Vai para 1 E1 Erro no envio do email E1 1 Sistema avisa que n o foi capaz de enviar o email e pede que o usu rio contacte o suporte R1 login deve estar registrado no sistema como v lido R2 senha fornecida deve ser id ntica senha associada ao login R3 A senha tempor ria deve ser um n mero de 8 d gitos Figura 4 6 Exemplo de uso do gabarito proposto pela abordagem A ado o de gabaritos para descri o dos casos de uso em um processo de desenvolvimento pode trazer alguns benef cios como por exemplo e Padroniza o da especifica o de casos de uso e Padroniza o da perspectiva de leitura e escrita da especifica o de casos de uso atrav s da defini o dos elementos que o comp em e Possibilidade de
193. enta o sem ntica proporcionada pelo metamodelo UCModel de um conjunto de orienta es voltadas para a reda o das descri es das a es do caso de uso e que foram usadas como base para a defini o de algumas quest es de uma t cnica de inspe o de diagramas de atividades baseada em checklist MELLO 2010 Especifica o e implementa o da ferramenta UseCaseAgent destinada cria o e verifica o sint tica de especifica es de casos de uso que implementa totalmente a estrutura e restri es definidas no metamodelo UCModel Especifica o e implementa o da ferramenta ModelT2 destinada gera o de modelos preliminares de testes funcionais a partir de modelos de especifica o de casos de uso e Integra o dos modelos de testes gerados a partir dos modelos de especifica o ferramenta TDE UML para obten o de forma autom tica de planos de testes funcionais contendo casos e procedimentos de testes e Defini o de pacotes de laborat rio abrangendo o planejamento execu o e an lise de estudos de observa o e de caracteriza o que ap iam a avalia o e evolu o das tecnologias propostas e e Revis o da literatura t cnica na rea de Engenharia de Aplica es Web com o objetivo de identificar caracter sticas dos m todos de desenvolvimento Web no que diz respeito ao tratamento de requisitos funcionais Para tal foi 184 definido um protocolo baseado nos conceitos da
194. enta o menu principal de acordo com o perfil do usu rio E Regras Erros A es Alternativas Exce es I Regras l Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 9 Tela do UseCaseAgent para cria o de fluxo alternativo associado a uma a o 211 Use Case Agent vers o 0 3 a 2 aa cas MA Mee Cll Arquivo Verificar Av amp UCModel Atores El Casos de Uso UCO01 Autenticacdo do usu rio Atores do Caso de Uso Fluxo Principal Ed Fluxos Alternativos 5 Fluxos de Exce o A1 login invalido ou senha invalida Ordem Descri o A es Alternativas Exce es Regras Acrescentar Para cma Para baixo Alternativas Exce es Regras Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 10 Tela do UseCaseAgent para edi o das a es do fluxo alternativo A cria o das a es para os fluxos alternativos segue o mesmo padr o definido para o fluxo principal A nica diferen a que para fluxos alternativos existe sempre uma condi o que define se esse fluxo ser ou n o executado nos pontos nos quais referenciado A 10 Fluxos de Exce o A cria o de fluxos de exce o e suas respectivas a es ocorre de forma id ntica a dos fluxos alternativos apenas usando a aba Exce es Figura A 9 A 11 Regras Ao
195. enta que permitisse o uso de perfis UML para defini o dos estere tipos e tagged values adequados modelagem navegacional o que n o foi poss vel nesse estudo devido ao desconhecimento dos pesquisadores acerca de uma ferramenta gratuita com tal funcionalidade 17 Apesar dos ind cios pontuais a informalidade e o pr prio tamanho da amostra n o nos permitiram consolid los Um segundo estudo de observa o se fez ent o necess rio 2 3 Segundo Estudo de Observa o Esse estudo de observa o acorreu no contexto da disciplina de gradua o Interface Humano Computador ministrada no 1 semestre de 2007 na UFRJ 2 3 1 Objetivo Analisar o uso de modelos no desenvolvimento de aplica es Web com o prop sito de caracterizar com respeito viabilidade dos modelos percep o de dificuldade do ponto de vista do pesquisador no contexto do desenvolvimento de um portal Web por alunos de gradua o do curso de Engenharia de Computa o e Informa o da UFRJ 2 3 2 Contexto Nesse estudo os participantes focaram em uma nica aplica o Web para que fosse poss vel isolar a percep o de dificuldade do tipo da aplica o e observar de forma mais isenta as diferen as entre os artefatos gerados pelas diversas equipes A escolha da aplica o baseou se no interesse dos pr prios alunos em gerar a especifica o e o projeto para o portal do curso de Engenharia da Computa o e Informa o da UFRJ sendo pa
196. entes e Necessidade de lidar com uma grande variedade de dispositivos de hardware redes convencionais redes sem fio celulares PDAs desktops dentre outros e Necessidade de adequa o s quest es culturais e ling sticas haja vista a possibilidade de acesso global e Aten o quanto escalabilidade pois as caracter sticas da aplica o podem tornar dif cil a previs o da quantidade real de usu rios e Constante evolu o de tecnologias que ap iam a constru o de aplica es Web novas linguagens padr es e ferramentas e Integra o de diversas tecnologias e padr es de software linguagens de programa o linguagens de scripts linguagens de marca o bancos de dados protocolos browsers servidores web servidores de aplica o e services dentre outros e Necessidade de equipes de desenvolvimento multidisciplinares especialistas em software programadores visuais especialistas em infra estrutura dentre outros e Integra o com sistemas legados e com servi os disponibilizados fora do escopo da aplica o e e Maior press o do time to market ou seja ciclos de manuten o curtos em fun o de press es de mercado A lista acima n o significa que aplica es convencionais n o tenham preocupa es relativas a esses aspectos mas que eles s o normalmente mais significativos no contexto de desenvolvimento de aplica es Web Tampouco essa lista pretende ser definitiva ou exclusiva Mui
197. erial de treinamento sobre o metamodelo UCModel Material de treinamento sobre a ferramenta UseCaseAgent e Material de treinamento sobre a ferramenta BOUML mais especificamente sobre o editor de diagramas de atividades O segundo instrumento dessa lista foi criado para evitar que os desenvolvedores precisassem configurar a ferramenta BOUML para uso do perfil ProfileUCModel 7 2 7 Prepara o O pacote de treinamento dos participantes foi dividido em cinco m dulos 1 Treinamento sobre conceitos gerais relacionados a casos de uso o gabarito organizado para descri o dos casos de uso e seus elementos Treinamento sobre o diagrama de atividades da UML 2 e seus elementos Treinamento sobre o metamodelo UCModel suas defini es e restri es Treinamento sobre a ferramenta BOUML mais especificamente sobre o editor de diagramas de atividades e Treinamento sobre a cria o e edi o de casos de uso com a ferramenta UseCaseAgent 168 Antes da primeira rodada os treinamentos de 1 a 4 foram ministrados para ambos os participantes na mesma sess o de treinamento O treinamento 5 foi ministrado somente ap s a rodada 1 para evitar que o conhecimento sobre a ferramenta UseCaseAgent influenciasse no resultado final do estudo 7 2 8 Execu o Baseados no documento original de requisitos do m dulo financeiro do SiGIC cada desenvolvedor especificou os casos de uso atribu dos para ele Vale a pena lembrar que os casos de uso
198. ero do boleto inv lido Ji lt lt system_response gt gt cliente seleciona op o de leitura eletr nica de vencimento menor que a data atual e o boleto foi emitido por outro bancq solicita que o cliente fa a a leitura eletr nica do boleto lt lt system_response gt gt realiza a leitura eletr nica lt lt actor_action gt gt As informa que n o poss vel pagar um boleto de outro banco ap s o vencimento valida os dados do pagamento lt lt system_action gt gt solicita a senha lt lt system_response gt gt fornece a senha lt lt actor_action gt gt valida a senha lt lt system action gt gt dados de pagamento inv lidos lt lt system_response gt gt informa que os dados do pagamento s o inv lidos lt lt system_response gt gt x lt lt navigation_rule gt gt NR10 obrigat rio que o sistema apresente uma mensagem de erro para cada dado que esteja incorreto lt lt conceptual_rule gt gt BR11 E obrigat rio que a senha fornecida seja id ntica a senha do cart o i fips AT informa que a senha inv lida e debita o valor a ser pago da fonte de recurso selecionada lt lt system action gt gt registra o boleto como pago na fonte de recurso selecionada lt lt system action gt gt Senha inv lida na 3a tentativa que encontra se bloqueada lt lt system_response g
199. es relataram que as transi es de estado definidas na especifica o estavam nas entrelinhas das descri es dos casos de uso e sugeriram que tanto a defini o dos estados quanto os eventos que disparam a sua transi o sejam representados de uma forma mais objetiva para facilitar a constru o inicial deste modelo Mapa Navegacional A Tabela 2 6 indica que um n mero razo vel de participantes tentou explorar esse modelo Contudo a percep o de esfor o alta Tabela 2 8 aliada ao baixo grau de import ncia percebido Tabela 2 9 fez com que as equipes classificassem esse modelo apenas como desej vel ou at mesmo descart vel A falta de experi ncia e ou treinamento adequado aliadas baixa ader ncia da ferramenta CASE sem ntica do mapa navegacional de fato podem ser fatores cr ticos que explicam essas dificuldades Por m o que realmente chama a aten o nesse caso que os participantes n o conseguiram perceber a import ncia de representar essa perspectiva no desenvolvimento de uma aplica o Web Em ltima an lise isso poderia indicar que os participantes n o sentiram a necessidade de representar a perspectiva navegacional ou que as informa es relevantes foram ou poderiam ser capturadas em outros modelos Analisando por outro ngulo a import ncia pode n o ter sido percebida porque os desdobramentos que a cria o desse modelo poderia ter no produto final em termos de garantia da qualidade ou at mes
200. esponse ent o sua primeira a o tem que ser uma SystemResponse uma SystemAction ou uma FinishAction Formaliza o em OCL context ExceptionFlow inv self condition gt notEmpty inv self actions gt size gt 1 inv self caller gt size gt 1 inv self caller gt size self caller gt select oclIsType0Of SystemAction gt size or self caller gt size self caller 1 inv self ca r gt asSequence gt first ocl implies P IsTypeOf gt select oclIsType0Of SystemResponse gt size SystemAction self actions gt asSequenc gt first oclIsType0Of Or SystemResponse self actions gt asSequenc gt first oclIsType0Of self caller gt asSequence gt first oclIsType0Of implies inv FinishAction SystemResponse self action gt first s gt asSequenc oclIsType0Of or dE SystemResponse action gt first se s gt asSequenc oclIsType0Of or TE SystemAction self actions gt asseq 120 gt first oclIsType0Of FinishAction 5 3 6 6 Metaclasse ActorAction A OU N 5 Descri o da a o obrigat ria Deve ter um ator associado N o pode ser a ltima a o de um fluxo S pod
201. essa perspectiva porque eles podem impactar em mais de uma perspectiva de projeto ou vis o da modelagem da mesma forma que os requisitos de adapta o exemplificados anteriormente Al m disso requisitos n o funcionais impactam diretamente em modelos arquiteturais que n o fazem parte do escopo da abordagem proposta Dessa forma requisitos n o funcionais transcendem as perspectivas de projeto e as vis es de modelagem requerendo outras perspectivas para sua representa o Assim apesar da sua import ncia para defini o completa da aplica o a ser desenvolvida necess rio um estudo mais detalhado sobre o impacto dos requisitos n o funcionais na abordagem proposta e quais altera es podem ser adotadas com o objetivo de adequar o arcabou o proposto s especificidades dos requisitos n o funcionais Essa 66 investiga o representa um consider vel esfor o de pesquisa est fora do escopo deste trabalho 4 5 Especifica o de Requisitos Por ser uma abordagem centrada no usu rio ser o adotados Casos de Uso JACOBSON 1992 para representar o comportamento do sistema no n vel mais alto de abstra o Os elementos conceituais que permeiam o dom nio do problema ser o representados pelos Modelos Conceituais e por fim as pol ticas procedimentos e restri es organizacionais ser o capturados atrav s de Regras de Neg cio A abordagem apresentada neste trabalho defende que o documento de requisitos con
202. et oclIsType0Of SystemResponse or self outgoing target oclIsType0Of GotoAction or self outgoing target oclIsType0Of IncludeUCAction or self outgoing target oclisTypeOf ExtendUCAction self parent oclIsTypeoOf AlternativeFlow or self parent oclIsTypeoOf ExceptionFlow implies self outgoing gt size 1 and self outgoing target oclisTypeOf SystemAction or self outgoing target oclisTypeOf SystemResponse or self outgoing target oclisTypeOf GotoAction or self outgoing target oclisTypeOf FinishAction or self outgoing target oclisTypeOf IncludeUCAction or self outgoing target oclisTypeOf ExtendUCAction 5 3 6 8 Metaclasse SystemResponse 1 2 Descri o obrigat ria Se estiver no fluxo principal deve ser sucedida por no m ximo uma a o do sucedida por IncludeUCAction ou ExtendUCAction Se estiver no fluxo alternativo ou de exce o deve ser sucedida por uma tipo Deve ser uma ActorAction GotoAction nica a o do tipo Actor Action GotoAction FinishAction IncludeUCAction ou ExtendUCAction Formaliza o em OCL context SystemResponse inv self name gt notEmpty inv self parent oclisTypeOf MainFlow implies self outgoing gt size lt 1 and self outgoing target oclisTypeOf ActorAction or self outgoing target oclisTypeOf GotoAction or self outgoing target oclIsType0Of IncludeUCAction or self o
203. eu hist rico de movimenta o tamb m armazenado de forma a permitir que os administradores possam saber a qualquer instante qual a posi o do invent rio valor bem como onde e quando foram adquiridos seu valor venal considerando a deprecia o anual o estado atual dos bens e onde se encontram na companhia Conjunto de Componentes e Servi os Web para a Realiza o de Vota o Eletr nica este conjunto de componentes dever apoiar a consulta de opini o de grupos de indiv duos realizando um controle sobre a unicidade e privacidade do voto A flexibiliza o de organiza o das consultas bem como a tabula o e exporta o dos resultados em formato padronizado permitir sua utiliza o em diferentes contextos e dom nios de aplica o 2 2 3 Projeto do estudo Todos os quinze participantes alunos de gradua o do 8 per odo do curso de Engenharia da Computa o e Informa o da UFRJ j haviam cursado a disciplina de Engenharia de Software anteriormente e adicionalmente estavam cursando a disciplina de Engenharia de Software Orientada a Objetos Nos per odos anteriores os alunos tiveram oportunidade de participar de projetos em sala de aula envolvendo os conceitos da orienta o a objetos sendo que alguns deles j atuavam na ind stria como estagi rios ou programadores na rea de Tecnologia da Informa o No decorrer da disciplina foi ensinado aos participantes como desenvolver o projeto da 13
204. evem ser obrigatoriamente estereotipados com lt lt interrupt gt gt Nesse caso a condi o de guarda obrigat ria e descreve a exce o a ser tratada 223 e Uma a o deve estar estereotipada como lt lt actor_action gt gt lt lt system_action gt gt ou lt lt system response gt gt Cada a o do diagrama de descri o do UC deve ser obrigatoriamente estereotipada com um desses tr s estere tipos e Um n de decis o deve ter um e somente um controle de fluxo sem nenhuma condi o de guarda e um ou mais fluxos de controle com condi es de guarda Apenas um fluxo de controle sem nenhuma condi o de guarda permitido a partir de um n de decis o Se houverem outros fluxos esses representam fluxos alternativos e nesse caso a condi o de guarda obrigat ria e descreve a condi o que dispara o fluxo alternativo e Um diagrama de descri o de Caso de Uso pode ter somente um n inicial um n final a es opacas ou call behavior e n s de decis o Um diagrama de descri o de UC utiliza somente um subconjunto dos elementos poss veis em um diagrama de atividades da UML 2 n s inicial e final a es e n s de decis o A 19 2 Mensagens de Erro na Especifica o do Caso de Uso Essa verifica o realizada dentro do pr prio Use Case Agent e tem o objetivo de garantir que a descri o gerada obedece a todas as restri es do metamodelo UCModel Caso algum desses erros seja encontrado
205. fica o de Casos de Uso apresenta a infra estrutura computacional organizada para apoiar a abordagem de especifica o e garantia da qualidade Cap tulo 7 Avalia o Experimental descreve dois estudos conduzidos no contexto da abordagem cujos resultados nos trazem indica es de que o uso da abordagem pode auxiliar na redu o de defeitos na especifica o de requisitos e Cap tulo 8 Conclus o e Trabalhos Futuros apresenta as conclus es contribui es da pesquisa limita es quest es n o respondidas e discute algumas perspectivas de trabalhos futuros 10 2 Estudos Preliminares Neste cap tulo s o apresentados com detalhes tr s estudos preliminares conduzidos com o objetivo de observar a utiliza o dos conceitos preconizados pelos m todos Web em cen rios de desenvolvimento Os resultados desses estudos forneceram indica es que apoiaram a defini o da abordagem proposta nesta tese 2 1 Introdu o A an lise dos m todos de desenvolvimento Web propostos na literatura t cnica apresentada no Cap tulo 2 nos permitiu ter uma vis o cr tica de suas principais caracter sticas e limita es com rela o ao tratamento de requisitos Entretanto mesmo com as informa es obtidas a partir das descri es desses m todos tornou se necess rio observar na pr tica algumas id ias e quest es iniciais que surgiram dessa an lise mais precisamente com rela o a 1 relev ncia dos modelos de pro
206. ftware baseado em tecnologias e padr es do World Wide Web Consortium W3C que prov recursos espec ficos da Web como conte do e servi os atrav s de uma interface de usu rio o browser Web Contudo essa defini o parece restringir a classe de aplica es Web por incluir o browser como um elemento indispens vel da interface dessas aplica es Apesar da presen a maci a do browser na grande maioria das aplica es Web n o podemos excluir dessa defini o as aplica es que utilizam a infra estrutura e os conceitos da Web mas abrem m o do browser como 1 www w38c org componente principal para apresenta o e explora o das informa es disponibilizadas pela aplica o Essa uma realidade que tem sido observada na pr tica pelo grupo de Engenharia de Software Experimental da COPPE UFRJ envolvido com projetos de pesquisa que demandam a especifica o de aplica es Web envolvendo workflow cient fico e caracter sticas de ubiquidade computacional Neste cen rio foi poss vel identificar maiores preocupa es relacionadas a quest es arquiteturais integra o de servi os e manipula o de grandes volumes de dados n o estruturados em detrimento de outras relacionadas puramente com a explora o da informa o atrav s do browser apesar da exist ncia destas com um menor grau de relev ncia Assim no contexto deste trabalho foi adotada uma defini o adaptada de KAPPEL et al 2006 Uma aplica o Web
207. ftware na ind stria SHULL et al 2001 MAFRA et al 2006 SP NOLA et al 2008 A Figura 1 1 apresenta um resumo das atividades realizadas bem como os cap tulos deste trabalho que reportam cada uma dessas atividades O arcabou o proposto por MAFRA et al 2006 tem como objetivo principal apoiar o desenvolvimento de novas tecnologias de software desde a sua concep o at a sua transfer ncia para a ind stria Ele prev como primeiro passo a execu o de uma revis o sistem tica KITCHENHAM et al 2004 com o objetivo de coletar com maior grau de rigidez e amplitude o conhecimento existente na literatura acerca de um tema de pesquisa No contexto desta tese essa revis o foi realizada por CONTE et al 2005 cuja quest o principal de pesquisa focava na caracteriza o dos m todos propostos na literatura t cnica para desenvolvimento de aplica es Web A introdu o de estudos prim rios logo ap s a revis o sistem tica foi formalizada por SPINOLA et al 2008 onde os autores prop em que o conhecimento obtido com a revis o sistem tica seja avaliado atrav s de surveys com pesquisadores externos da mesma linha de pesquisa No escopo desta pesquisa esses estudos prim rios foram conduzidos como tr s estudos de observa o preliminares com o prop sito de adquirir um entendimento mais refinado sobre a explora o de diversos conceitos coletados pela revis o sistem tica CONTE et al 2005 Assim o principal objetivo
208. gational Layout e Personalization e Layout enquanto o conceito de Resource foi estendido para Content O modelo SR do i ent o constru do a partir desses novos conceitos ou seja especializando as tarefas e os recursos segundo os tipos de requisitos relacionados s aplica es Web A abordagem prev que a partir dos modelos SR sejam gerados os modelos preliminares de dom nio e navega o Os autores declaram que poss vel gerar esses modelos para v rios m todos Web como OO H OOWS ou UWE 3 2 3 21 Modelagem de Navega o Orientada a Aspectos CASAL NGUIDA e DURAN 2009 prop em que modelagem navegacional seja realizada levando se em considera o as tarefas que o usu rio deseja executar na aplica o modelando a complexidade das entradas de dados necess rias a essas tarefas e n o somente como uma simples vis o do modelo conceitual O m todo proposto baseia se totalmente nos conceitos e processos do m todo WebRE e prop e que os casos de uso sejam modelados segundo uma abordagem orientada a aspectos proposta por SOUZA et al 2004 O objetivo modelar casos de uso crosscutting ou seja casos de uso que fornecem funcionalidades que sao reusadas em varios outros casos de uso Os casos de uso s o classificados segundo o m todo WebRE em Navigation ou WebProcess O m todo prop em que o modelo navegacional dos casos de uso do tipo WebProcess sejam criados com um novo conjunto de estere tipos que visam detalhar co
209. ger express o de trigger actors nome do ator criticality alta frequencyofuse baixa UC002 Nome do caso de uso lt lt precondition gt gt express o de pr condi o lt lt postcondition gt gt express o de p s condi o Figura 5 5 Padr o de representa o de um caso de uso e seus elementos b sicos usando o diagrama de atividades da UML 2 5 3 2 Regras Regras definem pol ticas procedimentos ou restri es relacionadas a uma organiza o ao contexto onde essa organiza o atua ou a um dom nio de problema Do ponto de vista da sua natureza regras podem expressar restri es que n o podem ser violadas sob nenhuma circunst ncia ou expressar expectativas com rela o a um comportamento HALPIN 2006 Essa distin o leva explora o de mecanismos diferentes para representar um ou outro tipo de regra como por exemplo linguagem natural estruturada modelos de dom nio que definem rela es estruturais diagramas de atividades que especificam processos m quinas de estado que representam ciclos de vida com eventos e rea es a esses eventos dentre outros conforme detalhado na se o 4 5 2 p gina 71 Na especifica o do caso de uso estamos interessados em representar as regras que impactam no comportamento esperado para o mesmo ou na interface usada no di logo ator sistema Com o objetivo de definir regras auto contidas do ponto de vista da perspectiva em que atuam a Tabela 5 4 descreve os tr s tipo
210. gura 4 2 Atividades previstas na abordagem proposta 64 Figura 4 3 Mapeamento entre a taxonomia de requisitos de ESCALONA e KOCH 2004 e as perspectivas de projeto Web e vis es de modelagem 66 Figura 4 4 M quina de estado representando o ciclo de vida da entidade Solicita o de Movimenta o p ga eaaa red AEE E EAA KEE EE eE uai nona tase ER E E 70 Figura 4 5 Diagrama de atividades representando o processo de administra o de solicita o de movimenta o ssempscipaatesasacu ieramas sepaciadoptedsiinsaa ad Lngaeir ana asas El icacifana s 71 Figura 4 6 Exemplo de uso do gabarito proposto pela abordagem 83 Figura 4 7 Diagrama de atividades com a especifica o do caso de uso Concluir COMPra tusiuaticaa aea ganda r cas Padeiro A AEE TEA E A T E EA E EEEE E 85 Figura 4 8 Diagrama de atividades detalhando o comportamento da a o Calcular valor do pedido do caso de uso da Figura 4 7 sssssssssssereseesserrrrrrrnrrssrrrrnrrrnnnsssrrrnne 86 Figura 5 1 Vis o parcial do metamodelo da UML 2 com os elementos do diagrama de atividades usados na defini o do metamodelo UCModel 97 Figura 5 2 Exemplo da an lise realizada para definir quais elementos da UML seriam especializados para cria o dos elementos da UCModel 98 Figura 5 3 Metamodelo UCModel e seu relacionamento com o metamodelo da UML at Ook acct
211. gura 6 4 apresenta a tela para defini o dos atores associados ao caso de uso poss vel selecionar um ou mais atores que ficar o dispon veis no momento de criar os fluxos dos casos de uso Neste exemplo somente o ator Cliente foi selecionado Tiere ees DR a Arquivo Verificar Hye p Atores Atores do Caso de Uso EI Casos de Uso Y Cliente amp UC001 Paaar boleto banc rio 7 Gerente e AGL AEE IE Administrador amp Fluxo Principal Fluxos Alternativos Fluxos de Exce o Regras Erros E i UC002 Transfer ncia entre contas B A E E UC003 Emitir extrato E E UC004 Autenticar usu rio A Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 4 Tela da UseCaseAgent para defini o dos atores do caso de uso As Figura 6 5 e 6 6 apresentam as tela dos UseCaseAgent para defini o do fluxo principal e fluxo alternativo A2 respectivamente Nessa telas poss vel criar a sequ ncia de a es que comp em esses fluxo Para cada a o poss vel definir 140 e Tipo do a o e Descri o da a o e Complemento da a o e Alternativas e exce es e Regras associadas a o Para defini o dos fluxos alternativos e de exce o a tela id ntica a da Figura 6 5 por m com a inclus o da condi o que dispara o fluxo Figura 6 6 ET o
212. hados no Cap tulo 7 1 6 Organiza o Este cap tulo apresentou o contexto e a motiva o para realiza o dessa pesquisa bem como as quest es de pesquisa os objetivos planejados e a metodologia utilizada na defini o e avalia o da abordagem proposta Estes t picos ser o refinados ao longo dos seguintes cap tulos Cap tulo 2 Estudos Preliminares apresenta tr s estudos preliminares que foram conduzidos com o objetivo de observar a utiliza o dos conceitos preconizados pelos m todos Web em cen rios de desenvolvimento Os resultados desses estudos forneceram indica es que apoiaram a defini o da abordagem proposta nesta tese Cap tulo 3 M todos de Desenvolvimento de Aplica es Web caracteriza os m todos que tratam requisitos das aplica es Web a partir de uma revis o da literatura t cnica e do estudo comparativo realizado por ESCALONA e KOCH 2004 Cap tulo 4 Abordagem para Especifica o de Requisitos apresenta detalhadamente a abordagem proposta e seu escopo de atua o juntamente com o processo e os artefatos previstos para especifica o dos requisitos Cap tulo 5 Metamodelo para Especifica o de Casos de Uso apresenta o arcabou o criado com o objetivo de apoiar a descri o de casos de uso segundo um conjunto de crit rios e restri es bem definido juntamente com os princ pios que nortearam a cria o desse arcabou o Cap tulo 6 Infra estrutura de apoio Especi
213. har as informa es acess veis Uma representa o alternativa s o os modelos navegacionais propostos por m todos Web da literatura t cnica Tabela 4 2 p gina 61 Uma poss vel alternativa essa representa o seria a ado o de modelos navegacionais espec ficos de determinado m todo Web para essa tarefa como por exemplo o Diagrama de Contexto Navegacional e o Diagrama de Navega o do m todo OOWS PASTOR et al 2001 ou o Modelo de Espa o Navegacional do m todo UWE KOCH amp KRAUS 2002 A representa o atrav s desses modelos pode tornar se uma escolha natural caso o m todo Web seja adotado no restante do processo de desenvolvimento Contudo preciso levar em considera o as eventuais dificuldades que ser o impostas aos usu rios ao tentarem validar esses modelos poss vel tamb m optar pelo uso de prot tipos da interface ou maquetes mockups para representar as regras estruturais da perspectiva de navega o Tabela 4 2 Cabe nesse caso uma an lise de custo benef cio porque se por um lado prot tipos de interface apresentam vantagens como facilitar a comunica o com os usu rios por outro podem existir desvantagens como custos adicionais referentes sua constru o SAWYER e KOTONYA 2004 Entretanto essa alternativa deve ser fortemente considerada se a prototipa o da interface j estiver sendo usada no processo de desenvolvimento como t cnica de valida o dos requisitos junto aos usu rios
214. i o os conceitos preconizados pelo metamodelo UCModel trouxeram algum benef cio se comparado com o gabarito original dos casos de uso 2 Quais foram as principais dificuldades na especifica o de casos de uso com EDA 3 Quais foram as principais dificuldades na especifica o de casos de uso com UCA 4 Se voc tivesse que usar novamente essa abordagem hoje voc adotaria a ferramenta UCA O treinamento para uso da EDA foi adequado e suficiente O treinamento para uso da UCA foi adequado e suficiente Ambos os desenvolvedores consideraram os conceitos do UCModel adequados para serem usados no projeto O participante mais experiente relatou que a padroniza o importante mas expressou preocupa o quanto possibilidade de perda de liberdade na descri o dos casos de uso embora ele n o tenha percebido essa situa o nos casos de uso especificados Com rela o especifica o usando EDA ambos os participantes relataram dificuldades ao lidar com e As limita es da tela especialmente para diagramas maiores e Os estere tipos e tagged values do perfil UCModel e A cria o e edi o das a es passos do caso de uso e e A grande quantidade de n s de decis o que representam fluxos alternativos Nenhum problema foi relatado com rela o ao uso da UCA Os participantes relataram que trabalhar com a UCA foi muito mais f cil pois ela semelhante a um editor de textos comum al m de permitir a corre
215. ia mesmo que isso implicasse em esfor o maior na an lise preliminar dos estudos recuperados 3 2 1 3 Crit rios e procedimentos de sele o de estudos Os crit rios de inclus o exclus o dos artigos s o e Os artigos devem estar dispon veis na web e Os artigos devem estar escritos em ingl s e Os artigos devem descrever um m todo de desenvolvimento que trate ou que inclua fases que tratem dos requisitos de aplica es Web independente da cobertura parcial ou total do ciclo de vida de desenvolvimento e e Os artigos n o devem descrever m todos que utilizam os requisitos somente para obter outros artefatos ou produtos sem descrever como trat los A partir da leitura do t tulo e do resumo do artigo o pesquisador far a sele o preliminar e gerar uma lista de artigo para leitura Os artigos que suscitarem d vidas nessa fase tamb m dever o ser selecionados para leitura Para todos os artigos selecionados para leitura ser o recuperados os textos completos na web Caso algum desses artigos n o esteja dispon vel na web por qualquer motivo ele ser marcado como indispon vel Ap s a leitura completa os artigos que n o atenderem a todos os crit rios de inclus o exclus o ser o descartados N o foram definidos crit rios ou procedimentos adicionais em rela o qualidade dos estudos Somente os crit rios de inclus o exclus o ser o usados como refer ncia para incluir ou excluir um artigo
216. icipantes do 1 estudo que levantaram d vidas quanto utilidade desses diagramas como um instrumento de comunica o entre os membros da equipe e na cria o da interface e 2 o aparente desinteresse dos participantes do primeiro estudo no desenvolvimento desses diagramas Optamos por deixar a cargo de cada equipe a defini o de qual ferramenta ou abordagem utilizar na representa o desses prot tipos ferramentas de autoria ou apresenta o storyboards mockups p ginas HTML ou outro mecanismo Os modelos previstos nesse estudo foram e Modelo Conceitual representa o dos elementos do dom nio e suas associa es segundo a abordagem orientada a objetos Usa o diagrama de classes da UML e Mapa de Atores foi extra do do m todo OOWS e utilizado para representar a taxonomia de atores no contexto da aplica o e Diagrama de Contexto Navegacional tamb m foi extra do do OOWS e utilizado para representar os contextos de navega o acessados direta ou indiretamente por cada um dos atores e Diagrama de Navega o tamb m foi extra do do OOWS e utilizado para representar o conte do de cada contexto de navega o a partir das vis es sobre as classes e associa es do modelo conceitual 2 3 4 Instrumenta o Os requisitos do portal foram definidos por dois pesquisadores e disponibilizados aos participantes Tamb m foi disponibilizada a ferramenta StarUML juntamente com um perfil UML OMG 2010a para cons
217. icita o login A1 2 Internauta fornece o login A1 3 Sistema valida o login R1 A1 4 Sistema gera uma senha tempor ria R3 A1 5 Sistema envia a senha tempor ria para o email do internauta E 1 A1 6 Sistema registra a nova senha A1 7 Sistema avisa para qual email a senha tempor ria foi enviada A1 8 Caso de uso encerrado A2 Login ou senha inv lida A2 1 Sistema avisa que o login ou a senha s o inv lidos A2 2 Vai para 1 Fluxos de Exce o E1 Erro no envio do email E1 1 Sistema avisa que n o foi capaz de enviar o email e pede que o usu rio contacte o suporte E1 2 Caso de uso encerrado Regras Ri obrigat rio que o login esteja registrado como v lido R2 E obrigat rio que a senha fornecida seja id ntica senha associada ao login R3 E obrigat rio que a senha tempor ria seja um n mero de 8 d gitos Figura 5 17 Descri o textual do caso de uso Autenticar usu rio de acordo com o gabarito apresentado na Tabela 4 10 p gina 81 Observando a especifica o do caso de uso Autenticar usu rio representada como um diagrama de atividades na Figura 5 16 poss vel visualizar os elementos do metamodelo UCModel definidos nas se es anteriores Os itens listados a seguir est o destacados no diagrama Figura 5 16 com o mesmo n mero do item 1 O caso de uso e seus elementos b sicos s o representados pela atividade estereotipada como l
218. ido o estilo adotado o necess rio que Tabela 4 5 Sugest o para prefixa o de regras no SBVR OMG 2008 BOLLEM 2008 Modalidade Estilo prefixado Estilo coloquial Estrutural Necessidade necess rio que Sempre Impossibilidade E imposs vel que Nunca Possibilidade restrita E possivel que AS VEZES Comportamental Obrigatoriedade obrigat rio que tem que Proibi o proibido que n o deve Permiss o restrita permitido que pode Segundo a SBVR os princ pios para descri o de regras sao LINEHAN 2008 BOLLEM 2008 e Regras devem ser descritas sempre que poss vel usando l gica de primeira ordem e Regras s o compostas de tipos de fatos fact types e Tipos de fatos s o compostos de termos ou seja defini es conceituais e e Uma regra estrutural ou comportamental Seguindo esses princ pios regras devem ser organizadas de forma a referenciar de forma direta os conceitos do dom nio neg cio no qual est o inseridas e devem expressar ou caracter sticas restri es estruturais ou comportamentos esperados A abordagem proposta neste trabalho adota estes princ pios e prop e que as regras de neg cio dom nio tamb m sejam analisadas e classificadas de acordo com as perspectivas de projeto Web mantendo assim consist ncia com os conceitos da Figura 4 1 Essa classifi
219. iro que causavam algum tipo de n o conformidade com o metamodelo UCModel foram removidos durante o processo de cria o da especifica o Ao editar os diagramas especificados com EDA usando a ferramenta UseCaseAgent s o listados os erros de n o conformidade com o metamodelo UCModel que devem ser corrigidos Essa an lise foi feita para os oito casos de uso do primeiro estudo e n o somente para aqueles inspecionados no segundo estudo A partir da lista de defeitos de cada diagrama apontados pela ferramenta UseCaseAgent a especifica o original foi analisada para verificar se esses defeitos pertenciam de fato ao documento original ou foram introduzidos pelo desenvolvedor ao transcrever o caso de uso em modo textual da especifica o original para o diagrama de atividades usando EDA A Tabela 7 7 apresenta os resultados dessa an lise Tabela 7 7 Defeitos nos requisitos detectados pela ferramenta UseCaseAgent Caso N vel de Defeitos Defeitos Defeitos previamente de uso complexidade apontados introduzidos existentes no por UCA pelo documento de desenvolvedor requisitos original 6 Baixa 5 2 3 15 Alta 6 3 3 36 M dia Alta 11 5 6 40 M dia Baixa 7 6 1 16 M dia Baixa 14 9 5 27 M dia Baixa 6 4 2 35 M dia Alta 5 2 3 17 Alta 11 5 6 Total 65 36 29 Os dados obtidos a partir dessa an lise refor am o resultado estat stico do segundo estudo diagramas de atividades de casos de us
220. is o realizada no contexto desta tese apoiou se em uma s rie de caracter sticas das revis es sistem ticas da literatura como a defini o das quest es de pesquisa de crit rios para sele o dos estudos e da estrat gia para extra o de dados Por outro lado algumas caracter sticas que fortalecem a formaliza o e o rigor cient fico das revis es sistem ticas n o foram observadas na sua totalidade 34 e O protocolo da revis o com os termos selecionados para busca crit rios de inclus o exclus o dentre outros n o foi avaliado por outros pesquisadores e O resultado da sele o preliminar dos estudos prim rios n o foi revisado por nenhum pesquisador e e A busca pelos estudos foi realizada em somente uma fonte de pesquisa embora esta fonte indexe v rias outras fontes relevantes Adicionalmente ESCALONA e KOCH 2004 publicaram um estudo comparativo sobre 10 m todos de desenvolvimento Web destacando como estes m todos tratavam os requisitos das aplica es naquela poca O trabalho n o deixa expl cito os crit rios utilizados na sele o desses 10 m todos mas 9 deles podem ser considerados m todos bem divulgados em eventos e publica es da rea de Engenharia de Aplica es Web Devido sobreposi o de interesses entre a revis o pretendida nessa pesquisa e o estudo comparativo de ESCALONA e KOCH 2004 optou se por realizar a revis o da literatura a partir do ano de 2004 inclusive e acrescentar
221. istente em determinada parte da aplica o e a defini o de uma ordem para constru o refinamento dos modelos Treinamento em Modelagem As diversas sugest es podem consolidadas como explora o de exerc cios e exemplos com nfase na simula o de situa es reais de projeto 2 6 Amea as Validade dos Estudos Foram consideradas cinco amea as validade recorrentes nos tr s estudos preliminares realizados e Treinamento das equipes a mitiga o desse risco envolveu a apresenta o e discuss o durante as disciplinas ministradas sobre todos os artefatos explorados nos estudos embora a aus ncia de alguns alunos nessas apresenta es possa ter desequilibrado o n vel de conhecimento entre eles Por outro lado como as tarefas eram sempre realizadas em grupo esse desequil brio pode ser minimizado e Defini o das aplica es Web embora a sele o das aplica es Web a serem desenvolvidas tenha sido realizada pelos pesquisadores estudos 1 e 3 a defini o dessas aplica es e suas respectivas funcionalidades surgiram de demandas reais observadas pelos pesquisadores no dia a dia 30 e Aloca o das aplica es Web pelas equipes somente 1 estudo embora a aloca o de uma das aplica es do primeiro estudo tenha sido direcionada para uma equipe espec fica importante ressaltar que a modelagem dessa aplica o demandava conhecimento espec fico sobre Engenharia de Software Experimental para o
222. ita o ao sistema e uma resposta do sistema Por fim para cada ciclo request response s o definidos os eventos necess rios para que a resposta prevista no cen rio do caso de uso seja gerada a partir da requisi o enviada Adotando o paradigma da orienta o a 44 objetos os eventos podem ser comparados s mensagens trocadas entre os objetos para que a resposta esperada seja gerada a partir da requisi o Quando todos os cen rios de um caso de uso s o especificados segundo esta abordagem as p ginas Web e os eventos que descrevem esses cen rios formam uma rvore que representa todos os poss veis eventos e p ginas Web que realizam o caso de uso A abordagem tamb m prev a gera o parcial do c digo da aplica o a partir dessa rvore de eventos 3 2 3 13 Agile Web Development Process AWDP A metodologia gil AWDP WOOKJIN et al 2005 inclui o uso de modelos orientados a objetos e ferramentas aliados a um processo gil e sistem tico para o desenvolvimento de aplica es Web A agilidade nesse contexto visa atender s solicita es constantes de mudan a em virtude de press es do mercado O processo dividido em duas grandes fases Percep o e Produ o Na fase de Percep o s o definidos os modelos conceituais relacionados ao dom nio do problema e os casos de uso descritos em linguagem natural A fase de Produ o sub dividida em 2 fases Sofistica o e Constru o A fase de Sofistica o rep
223. itos funcionais de forma alinhada vis o dos m todos Web contempor neos passando pela estrutura o da especifica o em torno de um conjunto de modelos que representam esses requisitos e formalizam o comportamento do sistema com o apoio de um metamodelo chegando at o controle de qualidade da especifica o t cnicas de inspe o e do produto final gera o de casos e procedimentos de testes funcionais atrav s da explora o do arcabou o sint tico e sem ntico que ap ia a pr pria especifica o dos requisitos O tratamento dos requisitos a partir de uma vis o horizontal representada pela cobertura no tratamento dos requisitos desde a sua an lise e classifica o at o seu desdobramento em termos de garantia da qualidade do produto aliada uma vis o vertical representada pelo detalhamento e formaliza o em termos de modelos das caracter sticas comportamentais do sistema representam diferenciais desta abordagem em rela o a outros trabalhos que tamb m investigaram quest es relacionadas especifica o de requisitos para aplica es de software INSFRAN et al 2002 ESCALONA et al 2003 SOME 2006 ESCALONA et al 2007 GUTI RREZ et al 2008 SOME 2009 91 No Cap tulo 5 ser apresentado em detalhes o metamodelo UCModel que foi definido no contexto deste trabalho com o objetivo de estruturar a especifica o de casos de uso atrav s de um conjunto de crit rios e restri es que visam formalizar a
224. ivo Pad eo e E RR RR Bart ta RR EANET RS RR as erase a eat amor 116 Figura 5 13 Transi es permitidas a partir de uma SystemAction com fluxo alternativo ee Daited ict EE UNDER DE ROVER DR CORDA RA OO ee nites Orel EE 116 Figura 5 14 Transi es permitidas a partir de uma SystemResponse com fluxo EMETA aTe 11o entire sad o Ra E LE TODAS ab DD SS DOER A E 117 Figura 5 15 Estere tipos e tagged values para defini o de diagramas de atividades sagundo oC MOTO ca pias e Ein ada tec sentonet Raro UE a ria edi 125 Figura 5 16 Diagrama de atividades com a descri o do caso de uso da Figura 5 17 ebay od pala asa Rupia nena A Santee ule is E dE ic RS pa bad ta nd 129 Figura 5 17 Descri o textual do caso de uso Autenticar usu rio de acordo com o gabarito apresentado na Tabela 4 10 p gina 81 130 Figura 6 1 Ciclo de uso das ferramentas previstas na abordagem com insumos e oj o o U LOTS E GR RD DR ND RNP RD nied a EA ORDER POR stare PR 136 Figura 6 2 Tela principal da ferramenta BOUML com a estrutura de pacotes 139 Figura 6 3 Tela inicial da UseCaseAgent com os elementos b sicos do caso de uso pda EA Des a a AMD E EEE O da RO e o 140 Figura 6 4 Tela da UseCaseAgent para defini o dos atores do caso de uso 140 Figura 6 5 Tela da UseCaseAgent com o fluxo principal do caso de uso Pagar boleto banc rio a near era UDOP RD ua 141 Figura 6 6 Tela da UseCaseAgent com o fluxo alternativo A2 do cas
225. j haviam sido especificados dentro do processo normal de desenvolvimento do m dulo financeiro e a tarefa dos participantes consistia em criar o diagrama de atividades para cada caso de uso de acordo com os conceitos preconizados pelo metamodelo UCModel Na primeira rodada a cria o dos diagramas foi feita por EDA somente com o apoio do perfil ProfileUCModel Cabe ressaltar que a exist ncia do perfil e a aplica o dos estere tipos n o garantem que o diagrama de atividades criado esteja aderente ao metamodelo UCModel ou seja n o h como garantir que o desenvolvedor ir criar sem nenhum apoio computacional extra um diagrama totalmente aderente ao UCModel Assim se o caso de uso no documento original contiver alguma n o conformidade com o UCModel existe a possibilidade de que essa n o conformidade seja traduzida para o diagrama de atividades Na segunda rodada a especifica o dos casos de uso foi feita por UCA e os diagramas de atividades correspondentes a cada caso de uso foram gerados automaticamente pela ferramenta Nesse caso como a UCA s aceita especifica es de caso de uso totalmente aderentes ao UCModel se o caso de uso no documento original contiver alguma n o conformidade com o UCModel o desenvolvedor tera de corrigi la para posteriormente gerar o diagrama de atividades Os desenvolvedores tiveram uma semana para executar cada rodada e ao final de cada uma foi enviada uma planilha eletr nica contendo o tempo gasto
226. jeto Web em fun o do tipo da aplica o 2 viabilidade da constru o dos modelos de projeto Web a partir de um conjunto de requisitos 3 dificuldades relacionadas gera o desses modelos dentro de um processo de desenvolvimento 4 tipos de modelos mais adequados para representa o da perspectiva de apresenta o e 5 modelagem da informa o no contexto da perspectiva de navega o Seguindo a metodologia cient fica apresentada na se o 1 5 foram realizados tr s estudos com o objetivo de observar essas quest es que s o apresentados nas se es 2 2 2 3 e 2 4 A se o 2 5 apresenta uma an lise global dos tr s estudos tanto do ponto de vista quantitativo quanto qualitativo Finalmente na se o 2 7 apresentada a conclus o mostrando como esses estudos foram teis para a formaliza o da abordagem de desenvolvimento Web proposta neste trabalho 2 2 Primeiro Estudo de Observa o Esse estudo ocorreu no contexto da disciplina de gradua o Engenharia de Software Orientada a Objetos ministrada no 2 semestre de 2005 na UFRJ 11 2 2 1 Objetivo O objetivo do estudo segundo o paradigma GQM Goal Question Metric BASILI 1988 pode ser formalizado como Analisar o uso de modelos no desenvolvimento de aplica es Web com o prop sito de caracterizar com respeito relev ncia das perspectivas percep o de import ncia e viabilidade dos modelos percep o de dificuldade do pon
227. lho o que motivou esta pesquisa e a quest o de investiga o S o tamb m apresentados os objetivos a metodologia de pesquisa adotada e a organiza o deste texto 1 1 Motiva o e Contexto Nos ltimos anos a complexidade e o escopo de atua o das aplica es Web v m crescendo rapidamente e atualmente essa categoria de software tem apoiado o relacionamento entre empresas e indiv duos em atividades do dia a dia relacionadas ao trabalho ou lazer BERNARDI et a 2010 Atualmente v rias ind strias ligadas ao com rcio manufatura log stica sistema financeiro e educa o exploram as caracter sticas da Web como ubiquidade padr es abertos e facilidade de acesso a informa es e servi os para criar novas oportunidades de neg cio e expandir seus mercados Nesse contexto o aumento da complexidade de tais aplica es vem sendo acompanhado pela crescente demanda por aplica es Web confi veis seguras e us veis tr s crit rios de qualidade dominantes segundo OFFUT 2002 tornando essa categoria de aplica es uma das mais importantes da ind stria em geral e da ind stria de software em particular No contexto deste trabalho importante definir primeiramente o que s o aplica es Web Apesar de n o existir um consenso da comunidade cient fica em torno de uma defini o em comum do que seria uma aplica o Web KAPPEL et al 2006 apresentam a seguinte defini o Uma aplica o Web um sistema de so
228. licita que o cliente fa a a leitura eletr nica do boleto system response nvalido e realiza a leitura eletr nica actor action lt lt navigation rul Y solicita os dados relativos ao pagamento system response informa que os dados do pagamento s o inv lidos system response lt lt navigation_rul s dadosPagamentol 4 data invalida or eariostagamentny desconto_invalido or jjuros_invalidos or dadosPagamentol valor_final_invalido Y informa os dados do pagamento actor action lt gt PARE ABRO informa que a senha system response inv lida system response Y fornece a senha actor action informa que a senha inv lida e Ifenhb invalida and egora encontra se bloqueada system senhal invalida and errol 3 response apresenta o comprovante de pagamento do boleto system response 1 1 2 Test Case Steps solicita a fonte de recurso de onde ser debitado o pagamento system response lt no description gt seleciona uma das op es actor action lt no description gt solicita o n mero do boleto system response lt no description gt digita o n mero do boleto actor action lt no description gt informa que o n mero do boleto inv lido system response lt no description gt solicita o n mero do boleto system response lt no descrip
229. lisando os elementos da Figura 5 1 poss vel tra ar um paralelo entre os elementos Activity Action destacados por ret ngulos tracejados e Casos de Uso A es do caso de uso Assim como o Caso de Uso representa em linhas gerais um comportamento composto por uma sequ ncia de A es o elemento Activity representa um processo especificado por uma sequ ncia de elementos Action Entretanto essa equipara o n o totalmente verdadeira porque as a es do caso de uso n o est o diretamente relacionados a ele mas sim aos fluxos principal alternativos e de exce o que por sua vez pertencem ao caso de uso conforme apresentado na Figura 5 2 Nesse caso houve a necessidade de acrescentar elementos ao metamodelo UCModel que representassem esses tr s conceitos fluxos principal alternativos e de exce o sem paralelo no metamodelo da UML 97 Conceitos relacionados ao caso de uso sem contrapartida na UML Figura 5 2 Exemplo da an lise realizada para definir quais elementos da UML seriam especializados para cria o dos elementos da UCModel Essa mesma an lise foi realizada para cada um dos elementos que comp em o conjunto de informa es do caso de uso conforme o gabarito de casos de uso apresentado na Tabela 4 10 p gina 81 O resultado final pode ser observado na Figura 5 3 que apresenta os elementos do metamodelo UCModel e como estes se relacionam com o metamodelo da UML 98 Metamod
230. lista s o pass veis de serem resolvidas de forma autom tica por m os itens 3 e 4 requerem a interven o do analista de testes Para apoiar essa interven o s o inseridos coment rios no modelo de testes gerados a partir das regras associadas s a es no modelo de casos de uso O objetivo desses coment rio deixar claro para o analista de testes as regras que influenciam o comportamento do sistema naquele ponto A partir da an lise desses coment rios 152 espera se que o analista seja capaz de definir as classes de equival ncia de forma a cobrir as possibilidades estabelecidas nas regras A Tabela 6 1 define as transforma es entre os elementos do metamodelo UCModel e TDE Tabela 6 1 Transforma o dos elementos do metamodelo UCModel para o metamodelo TDE UCModel TDE A o do ator ActorAction A o do ator ActorAction A o do sistema Eliminado do modelo A a o anterior a o do sistema SystemAction deve ser ligada a o posterior a a o do sistema Resposta do sistema Resposta do sistema SystemResponse SystemResponse N de decis o Devem ser gerados n 1 n s de decis o onde n o n mero de desvio que existem a partir do n de decis o do modelo de casos de uso N s de decis o E gerada uma classe de equival ncia com o nome do antecedidos por uma fluxo e as op es sim e n o indicando que esse resposta do sistema caminho pode ou n o ser perc
231. lmente usando o gabarito de casos de uso proposto pelo m todo NDT por m nesse caso n o podem ser usados pelos mecanismos de transforma o 3 2 3 16 HM Hypertext Modeling Method of MIDAS O m todo HM C CERES et al 2006 que faz parte do m todo MIDAS CASTRO et al 2004 defende que o modelo navegacional seja obtido a partir dos servi os demandados pelo usu rio ao inv s de ser estruturado a partir do modelo conceitual como ocorre na maioria dos m todos Web Para tal usado o modelo de casos de uso que representa a vis o comportamental do sistema e o modelo conceitual de dados que representa a vis o estrutural do sistema Casos de uso s o decompostos usando os conceitos de include e extend em servi os estruturais respons veis somente pela visualiza o dos dados ou funcionais quando ocorre algum tipo de intera o entre o ator e o sistema Cada servi o que comp e o caso de uso pode ser visto como um caminho alternativo que descreve uma possibilidade de execu o do caso de uso e que representa um servi o na vis o do usu rio Para especificar o encadeamento entre os servi os estruturais e funcionais criado um diagrama de atividades da UML OMG 2010a para cada caso de uso onde as a es do diagrama s o os servi os do caso de uso Ao final cada servi o do caso de uso ou seja cada a o do diagrama de atividades descrito no modelo navegacional como um n ou slice na terminologia do m
232. logia XForms Para implementar restri es adicionais relacionados ao neg cio al m daquelas restri es estruturais j previstas no modelo de dados o m todo prev algumas possibilidades como a introdu o de trechos de c digo atrav s de restri es associadas s classes Esses trechos seriam implementados posteriormente nas classes respons veis pelo gerenciamento dos dados ou diretamente no SGBD Sistema de Gerenciamento de Banco de dados 3 2 3 18 ADM Ariadne Development Method O m todo ADM foi inicialmente proposto por DIAZ et al 2005 mas contemplava somente as fases relativas ao projeto design da aplica o Web MONTERO et al 2007 acrescentam o tratamento dos requisitos e prop em um processo flex vel e detalhado que permite que os desenvolvedores tratem diferentes quest es de projeto em 6 n veis de abstra o como o sistema est estruturado estrutura quais capacidades de navega o s o oferecidas navega o como o sistema reage a eventos externos comportamento como o sistema funciona internamente processo quais as caracter sticas da apresenta o da informa o apresenta o e quais regras de acesso ser o aplicadas para prover um ambiente seguro acesso A constru o dos modelos em cada um desses n veis est dividida nas 3 fases do processo proposto projeto conceitual projeto detalhado e avalia o O projeto conceitual envolve a defini o da estrutura abstrata do sistema um tip
233. logy for Hypermedia Design Proceedings of 3 International Conference on Unified Modeling Language Advancing the Standard UML 00 pp 410 424 IEEE 1998 IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830 1998 The Institute of Electrical and Electronics Engineers http standards ieee org findstds standard 830 1998 html INSFRAN E PASTOR O WIERINGA R 2002 Requirements Engineering Based Conceptual Modeling Requirements Engineering Journal v 7 pp 61 72 ISAKOWITZ T STOHR E BALASUBRAMANIAN P 1995 RMM a methodology for structured hypermedia design Communications ACM v 38 n 8 pp 34 44 ISO 2001 Information Technology Software Product Quality Part 1 Quality Model ISO IEC 9126 1 2001 International Organization for Standardization JACOBSON I 1992 Object oriented software engineering a use case driven approach Addison Wesley JACOBSON l BOOCH G RUMBAUGH J 1999 The Unified Software Development Process Addison Wesley 193 JURISTO N MORENO A M VEGAS S 2004 Reviewing 25 years of testing technique experiments Empirical Software Engineering An International Journal n 9 pp 7 44 KANJILAL A SENGUPTA S BHATTACHARYA S 2009 Analysis of complexity of requirements A metrics based approach Proceedings of the 2 India Software Engineering Conference ISEC 09 pp
234. los Conceituais ses etc Be Asics cereedeur sie anta duo abr sb pn ada soul pesL possa ca gua sda 68 A a ROgras de Neg cio css ae unas tie undtaro Maaetiewties de eaaeD emda Mae ias 71 45 3 Modelo de Casos de USO iscicieisisvisesorvianeneessuietiieteee enue eateaneee 79 4 6 Inspe o de Requisitos cccccceeeeeeeeeeesecceeeeeeeeeeeeenaaaaaeeeeeeeesenessaaaeeeeeeee 87 4 7 Gera o de Casos e Procedimentos de Testes Funcionais 88 4 8 CONCIUS O ucraniana sora iria dica aire a AA re nes cia trocaria ea 90 5 Metamodelo para Especifica o de Casos de Uso 93 5 1 Lainate 8 ere te E SS ee Cie eee Re le is 93 5 2 Diagrama de Atividades e Casos de USO ccseeeeeeeeeeeesesesesseeeeeeeeeeeeees 94 5 3 O Metamodelo UCModel episesiestrasierissenco prata copeasoltoniaria cota acnitoraatia do peado 96 5 3 1 Caso de Uso e seus Elementos B sicos 99 Bo ROS eae a ae do RA cede teed Re alada R E pn US A SEAE ERREA 102 5 3 3 Fluxos do Caso de USO aan anaana dinda ani aa neu nita cade 105 5 3 4 A es do Caso de USO ianesia ani aloe grain IEA sonda asa LG nrR Achas dad ro cin ad 108 5 3 5 Combinando A es na Descri o do Comportamento 114 5 3 6 Restri es do Metamodelo UCModel e 117 Boss Pen UME austero ico paira dr ananEs r aah ade cg da era 125 5 4 Orienta es para Especifica o de Casos de Uso no UCModel
235. luxo de controle atividade e respons vel coordenador Abrir processo RH Avaliar solicita o ger ncia s nior Apreciar solicita o indeferiu reprovou Figura 4 5 Diagrama de atividades representando o processo de administra o de solicita o de movimenta o importante ressaltar que os modelos conceituais devem e Capturar os conceitos independente das funcionalidades nos quais eles estejam envolvidos e Capturar os conceitos e suas caracter sticas no mesmo n vel de abstra o dos requisitos e Limitar os conceitos modelados ao escopo do sistema e e Ter uma estreita consist ncia entre si no que se refere aos conceitos representados e suas caracter sticas 4 5 2 Regras de Neg cio Regras de neg cio s o declara es que descrevem pol ticas procedimentos ou restri es relacionadas a uma organiza o ou ao contexto onde essa organiza o atua e tem sido amplamente utilizadas na especifica o de sistemas de informa o 71 HALPIN 2006 WANG et al 2010a Entretanto este limite pode ser estendido levando se em considera o que n o somente as organiza es possuem um conjunto de regras espec ficas a serem observadas Dom nios de problema tamb m possuem procedimentos ou restri es intr nsecos que precisam ser considerados O entendimento e a tradu o corretos de regras relacionadas ao dom nio ou neg cio para o espa o da solu o computacional
236. m Projetos de Software o prop sito desta ferramenta auxiliar o Engenheiro de Software a gerenciar sua baseline de requisitos Para isso necess rio estabelecer a rastreabilidade v nculos entre os requisitos e os outros produtos de trabalho do desenvolvimento modelos de an lise e projeto c digo casos de teste A rastreabilidade importante para auxiliar a avaliar o impacto de 12 mudan as nos requisitos e tamb m para demonstrar a completa satisfa o dos requisitos Aplica o para a Ger ncia de Configura o e Manuten o de Computadores esta aplica o Web tem o objetivo de realizar o gerenciamento e o controle das configura es de computadores instalados em laborat rios de pesquisa A id ia permitir aos usu rios do laborat rio identificar as facilidades existentes em cada m quina otimizando assim sua utiliza o e evitando retrabalho de instala o Al m disso interessante tamb m poder ter um controle de manuten o hardware e software o que possibilitar aprimorar o planejamento de substitui o e renova o Sistema para Controle de Invent rio Patrimonial gerenciar e controlar o invent rio ou seja os bens de uma determinada organiza o representa um conjunto de atividades importantes e relacionadas com a evolu o patrimonial da empresa Desta forma este sistema intenciona permitir que as informa es relacionadas aos bens adquiridos por uma empresa possam ser registrados e tenham s
237. m de Aplica es ADAMKO 2006 Orientadas a Dados 2007 Ariadne 1 MONTERO et al 2007 WebML 1 MORENO et al 2007 OOWS 1 VALDERAS et al 2007 2008 WRM 1 MOLINA et al 2008 NDT 1 ESCALONA e ARAG N 2008 2009 Abordagem para An lise de 1 GARRIG S et al 2009 Requisitos com i Modelagem de Navega o 1 CASAL NGUIDA e DUR N Orientada a Aspectos 2009 An lise de Requisitos com 1 OGATA e MATSUURA 2009 Gera o de Prot tipos Desenvolvimento Web por 1 DE SILVA et al 2009 Usuarios Finais 2010 WebTDD 1 LUNA et al 2010 UWA 1 BERNARDI et al 2010 An lise de Requisitos com 1 OGATA e MATSUURA 2010 Gera o de Prot tipos 38 Abordagem para An lise de 1 AGUILAR et al 2010 Requisitos com i Total 16 21 3 2 3 Resultados obtidos com a An lise dos Estudos A partir dos 21 artigos aprovados foram identificados 16 m todos que lidam com requisitos para aplica es Web A essa lista foram mesclados os 10 m todos analisados anteriormente por ESCALONA e KOCH 2004 perfazendo um total de 24 m todos importante ressaltar que 2 m todos analisados por ESCALONA e KOCH 2004 WebML e NDT tamb m foram selecionados pela revis o da literatura indicando que esses m todos ainda continuam ativos no que se refere ao tratamento de requisitos de aplica es Web Nas se es a seguir os 24 m todos aprovados na revis o da literatura t cnica s o apresentados de forma resumida 3 2 3
238. ma o metamodelo UCModel contribui para o objetivo geral deste trabalho oferecendo um arcabou o conceitual a partir do qual t cnicas e ferramentas de apoio especifica o e garantia da qualidade podem ser definidas e implementadas O Cap tulo 6 apresenta o apoio computacional elaborado com o objetivo de apoiar a abordagem de especifica o e garantia da qualidade proposta neste trabalho Detalhes sobre a utiliza o das ferramentas UseCaseAgent e ModelT tamb m s o apresentados nesse cap tulo 133 6 Infra estrutura de Apoio Especifica o de Casos de Uso e Garantia da Qualidade Neste cap tulo apresentada infra estrutura computacional organizada para apoiar a abordagem de especifica o e garantia da qualidade proposta nesta pesquisa e detalha as duas ferramentas desenvolvidas no escopo deste trabalho que comp em essa infra estrutura 6 1 Introdu o A infra estrutura computacional organizada para apoiar a abordagem proposta neste trabalho composta de quatro ferramentas que atuam em momentos distintos do processo de desenvolvimento Dessas quatro ferramentas duas foram desenvolvidas no escopo desta pesquisa e Ferramenta UseCaseAgent tem o objetivo de apoiar a constru o da especifica o dos casos de uso garantindo que essas especifica es sigam o metamodelo UCModel e as restri es nele definidas Como insumo a ferramenta recebe o resultado da an lise das informa es coletadas durante a elicit
239. ma SystemAction ou uma SystemResponse ou seja a ltima a o de um fluxo deve ser uma dessas duas a es O sucessor de uma ActorAction deve ser uma SystemAction O sucessor de uma SystemAction deve ser o n final outra SystemAction ou uma SystemResponse e 5 O sucessor de uma SystemResponse deve ser o n final ou uma ActorAction O cen rio apresentado pela Figura 5 11 torna se mais complexo levando se em considera o a possibilidade da exist ncia de fluxos alternativos ap s cada uma dessas a es Conforme definido no metamodelo da UML Figura 5 1 p gina 97 poss vel ter n s de decis o que representam fluxos alternativos no caso de uso ap s cada a o da atividade Como o metamodelo UCModel se baseia no metamodelo da UML poss vel ter fluxos alternativos associados s a es ActorAction SystemAction e SystemResponse 5 3 5 2 A o do Ator com Fluxo Alternativo A Figura 5 12 apresenta as transi es v lidas caso exista um fluxo alternativo DecisionNode associado a uma a o do ator ActorAction De acordo com essa figura a partir do n de decis o poss vel continuar a execu o pelo fluxo principal ou iniciar um fluxo alternativo Em ambos os casos por m a sequ ncia de a es a mesma ou seja tanto no fluxo principal quanto no fluxo alternativo a primeira a o do fluxo deve ser uma a o do sistema Esse arranjo refor a a id ia de que uma 115 requisi o do ator deve sem
240. ma e ao conhecimento pr vio do dom nio por dois integrantes da equipe que j haviam trabalhado com este tema em projetos de pesquisa do grupo de Engenharia de Software Experimental da COPPE UFRJ As demais aplica es foram sorteadas entre as outras quatro equipes 15 2 2 4 Instrumenta o Os pr prios pesquisadores nesse caso 3 indiv duos desempenharam o papel de stakeholders e foram associados a cada um dos cinco projetos de forma a permitir uma avalia o completa do problema e da solu o proposta A ferramenta Poseidon for UML Community Edition foi disponibilizada para constru o dos modelos 2 2 5 Execu o Durante a disciplina os participantes elaboraram a especifica o de requisitos e realizaram a inspe o dos mesmos usando t cnica de inspe o ah hoc Em seguida as equipes tiveram cerca de tr s semanas para a elabora o e entrega dos modelos referentes s perspectivas de projeto Web e ao projeto detalhado Ap s a entrega final do trabalho foi distribu do aos participantes um question rio para ser respondido individualmente contendo uma avalia o sobre o trabalho realizado Todas as equipes entregaram todos os artefatos solicitados com exce o das equipes 2 e 5 que n o entregaram o projeto detalhado A Tabela 2 2 lista algumas medidas diretas extra das desses artefatos Tabela 2 2 Medidas diretas extra das dos artefatos de projeto do 1 estudo Projeto Qtde de Qtde d
241. mero do boleto esteja de acordo coma f Baal g s N especifica o da se o 3 do documento de refer ncia opcao inval Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia n mero do boleto inv lido data de vencimento menor que a data atual e o boleto foi emitido por outro banco Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia lt lt equivalence_class gt gt boleto1 Boletot solicita que o cliente fa a a E informa que o n mero do letura eletr nica do boleto lt lt conceptual_rule gt gt BRS E obrigat rio que a boleto inv lido lt lt system response gt gt data de pagamento seja maior ou igual a data lt lt system_response gt gt corrente i lt lt conceptual_rule gt gt BR6 E obrigat rio que o digita o n mero do boleto valor do desconto seja menor que o valor do lt lt actor_action gt gt boleto P o 2 lt lt conceptual_rule gt gt BR7 obrigat rio que o 6 valor dos juros seja fornecido se a data de A3 pagamento for menor que a data corrente Y boleto1 numero invalido realiza a leitura eletr nica lt lt conceptual_rule gt gt BR8 Valor a ser pago lt lt actor action gt gt valor do boleto desconto juros lt lt conceptual_rule gt gt BR9 E obrigat rio que o valor a ser pago seja maor que zero i Importante solicita os dados relativos Ne
242. mo as transa es definidas no caso de uso ocorrem em termos de interface 50 com o usu rio e funcionalidades do sistema Essa vis o detalhada n o prevista no m todo WebRE 3 2 3 22 An lise de Requisitos com Gera o de Prot tipos O m todo proposto por OGATA e MATSUURA 2009 explora a especifica o de requisitos atrav s de casos de uso que s o descritos usando diagramas de atividades Esses diagramas s o explorados em um processo iterativo onde prot tipos s o gerados diretamente a partir dos diagramas e s o usados para validar refinar os requisitos que por sua vez alteram novamente os diagramas gerando novos prot tipos Para que seja poss vel gerar prot tipos a partir dos diagramas estes contam com as seguintes caracter sticas e O diagrama possui raias para determinar de quem a responsabilidade pela a o ator ou sistema e Fluxos alternativos e de exce o s o representados como n s de decis o e Os dados de entrada ou sa da da aplica o s o representados como fluxos de objetos e e Os campos de entrada s o definidos como a es com palavras reservadas como input lt nome gt que cria uma caixa de texto para entrada do campo nome ou select single from list lt nota gt que cria uma lista de sele o com os valores de nota O m todo conta ainda com outros diagramas Diagrama de classes modelo de dom nio Diagrama de objetos respons vel por definir os valores a partir dos quais o
243. mo da confec o do produto em si n o foram percebidos pelos participantes Talvez esse seja um 28 mecanismo natural de corte implicitamente usado pelos desenvolvedores n o vale a pena criar um modelo quando este n o usado de forma direta ou indireta na obten o do produto final Mapa de Atores A an lise dos trabalhos nos permite afirmar que esse diagrama foi efetivamente pouco explorado no contexto de desenvolvimento proposto Na realidade o mapa de atores s tem sentido se explorado juntamente com o mapa navegacional j que ambos fazem parte do mesmo m todo OOWS Contudo as equipes tentaram explorar esse diagrama de forma isolada o que resultou em um baixo n vel de import ncia percebida 2 5 2 An lise dos Dados Qualitativos Os dados qualitativos foram analisados de forma conjunta sem levar em considera o opini es espec ficas acerca de um modelo em particular A id ia por tr s dessa an lise foi poder obter um conjunto de categorias e c digos que indicassem facilitadores em um processo de desenvolvimento de aplica es Web dirigido por modelos que poderiam indicar em ltima an lise caracter sticas a serem observadas e ou adotadas nesses processos A seguir s o listadas as categorias obtidas com a aplica o da codifica o aberta e da codifica o axial sugeridas por STRAUSS e CORBIN 1998 para o m todo Grounded Theory e as principais sugest es relacionadas a elas Requisitos Foram cit
244. n BasicAction Boolean if self oclisTypeOf ConditionalFlow then self caller gt forAlli c c parent targetInChain chain gt union c parent actions action else chain gt exists action endif context GotoAction inv self target gt notEmpty inv not self target oclIsType0Of GotoAction inv self parent targetInChain Set self target 123 1 4 inv se inv se order self parent gt size incoming source oclisTypeOf ActorAction implies self target oclIsTypeoOf SystemAction incoming source oclisTypeOf SystemAction implies self target oclisTypeOf SystemAction or self target ocliIsTypeOf SystemResponse inv self incoming source oclisTypeOf SystemResponse implies self target ocliIsTypeOf SystemResponse or self target oclisTypeOf ActorAction ye Te inv se 5 3 6 10 Metaclasse FinishAction 1 N o pode ter fluxos alternativos ou de exce o essa regra ja esta implementada na estrutura do metamodelo 2 S pode ser definida para fluxos alternativos ou de exce o 3 Tem que ser a ltima a o em um fluxo alternativo ou de exce o Formaliza o em OCL context FinishAction inv self parent oclisTypeOf AlternativeFlow or self parent oclisTypeOf ExceptionFlow inv self order self parent gt size 5 3 6 11 Metaclasses In
245. n gt gt apresenta o comprovante de pagamento do boleto lt lt system response gt gt lt lt conceptual_rule gt gt BR1 obrigat ria a sele o de uma e apenas uma fonte de recurso Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia op o inv lida Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia lt lt conceptual rule gt gt BRZ obrigat rio que o boleto seja emitido pelo banco se a data de vencimento for menor que a data corrente lt lt conceptual_rule gt gt BR4 E obrigat rio que o n mero do boleto esteja de acordo com a especifica o da se o 3 do documento de refer ncia Importante Nesse ponto atente para os seguintes crit rios para gerar as classes de equival ncia n mero do boleto inv lido data de vencimento menor que a data atual e o boleto foi emitido por outro banco Corrija as express es associadas com as decis es de forma que elas reflitam os dados definidos nas classes de equival ncia solicita que o cliente fa a a Es leitura eletr nica do boleto lt lt conceptual rule gt gt BRS obrigat rio que a lt lt system response gt gt data de pagamento seja maior ou igual a data corrente lt lt conceptual rule gt BR6 E obrigat rio que o valor do desconto seja menor que o valor do boleto g lt lt conceptual_rule gt gt BR7 E obrig
246. na interpreta o do requisito 65 e Favorecer uma pol tica de rastreabilidade desses requisitos pelos artefatos gerados e e Determinar qual ou quais elementos da especifica o s o mais adequados para representa o do requisito A Figura 4 3 apresenta o mapeamento entre a taxonomia usada por ESCALONA e KOCH 2004 as perspectivas de projeto Web e as vis es estrutural comportamental Requisitos de dados s o exclusivamente estruturais enquanto requisitos de transa o s o exclusivamente comportamentais Requisitos de navega o e apresenta o podem ter vis es estruturais ou comportamentais dependendo se estes tratam da estrutura ou de caracter sticas din micas dessas perspectivas Os requisitos de adapta o diferente dos demais englobam a no o de variabilidade que pode estar associada a uma funcionalidade ou restri o de qualidade QURESHI e PERINI 2009 Assim seu mapeamento pode ter desdobramentos nas diversas perspectivas e vis es de modelagem Estrutural Comportamental Conceitua o CALS IOS Oe Requisitos de transa o dados Apresenta o neauisiigs Ee Requisitos de adapta o Reguisitos Ee apresenta o apresenta o N a E E avegacao Requisitos de navega o Figura 4 3 Mapeamento entre a taxonomia de requisitos de ESCALONA e KOCH 2004 e as perspectivas de projeto Web e vis es de modelagem Os requisitos n o funcionais n o s o tratados sob
247. navega o e apresenta o desde a fase inicial do projeto e apoiada por um metamodelo cuja finalidade aprimorar o rigor da especifica o funcional e apoiar atividades de garantia da qualidade da especifica o dos casos de uso A concep o da abordagem est baseada nos resultados de um estudo secund rio anterior de uma revis o da literatura t cnica baseada nos conceitos de revis o sistem tica e de tr s estudos prim rios estudos de observa o enquanto a sua avalia o foi efetuada atrav s de dois estudos prim rios estudos de viabilidade Os resultados da avalia o experimental indicam que o uso da abordagem proposta para especifica o de requisitos de aplica es Web contribui para a redu o de defeitos nas especifica es de caso de uso quando comparada ao uso de uma abordagem ad hoc Abstract of Thesis presented to COPPE UFRJ as a partial fulfillment of the requirements for the degree of Doctor of Science D Sc A MODEL DRIVEN APPROACH FOR REQUIREMENTS SPECIFICATION INTEGRATED TO WEB APPLICATIONS QUALITY ASSURANCE Jobson Luiz Massollar da Silva April 2011 Advisor Guilherme Horta Travassos Department Computer Science and Systems Engineering This thesis proposes a structured approach to support the specification of functional requirements aiming to assure their quality It makes use of a framework for analysis classification and specification of functional requirements aligned with the concepts p
248. ncionais do m dulo financeiro do SiGIC Foram selecionados dez casos de uso Esses casos de uso j haviam sido especificados anteriormente usando um gabarito de casos de uso pr prio do projeto e um editor de textos N o foi adotado naquele momento nenhum modelo formal de casos de uso que apoiasse a especifica o nem tampouco uma forma de verifica o semi autom tica desses documentos Todos os dez casos de uso selecionados j haviam sido inspecionados e corrigidos de forma ad hoc por membros da equipe do projeto que n o participaram desse estudo Existem algumas propostas na literatura t cnica para medi o de casos de uso DIEV 2006 LAVAZZA et al 2008 KANJILAL et al 2009 LAVAZZA e ROBIOLO 2010 Entretanto at o presente momento n o h consenso na comunidade cient fica sobre um m todo que permita obter uma medida de tamanho ou complexidade para este artefato Dessa forma usando como ponto de partida o contexto do desenvolvimento e os conceitos explorados na descri o dos casos de uso selecionados para o estudo foi definida uma m trica com seus valores de medida apresentados na escala raz o para determinar a complexidade desses casos de uso e permitir a compara o entre eles Essa m trica pode ser descrita pela f rmula C NAFP NFA NR 164 onde NAFP n mero de a es no fluxo principal NFA n mero de fluxos alternativos NR n mero de regras A compara o dos casos de uso usan
249. ndo o metamodelo UCModel Tais especifica es s o representadas como um diagrama de atividades e o principal objetivo do UseCaseAgent permitir que o desenvolvedor trabalhe com a descri o textual do caso de uso deixando a cargo do plug in a tarefa de gerar automaticamente o diagrama de atividades correspondente Para que seja poss vel realizar a tradu o de uma descri o textual do caso de uso para um diagrama de atividades e vice versa algumas condi es s o necess rias e A descri o textual deve seguir um padr o que possa ser interpretado Para atender a essa condi o foi criado um metamodelo chamado UCModel que descreve o padr o a ser adotada na especifica o de casos de uso Esse metamodelo descreve os elementos que comp em a descri o de um caso de uso bem como as regras que definem as combina es v lidas entre esses elementos e e Deve haver uma estrutura de pacotes bem definida na qual os diversos elementos que comp em o caso de uso e sua descri o possam ser gerados Nesse caso foram acrescentadas funcionalidades espec ficas para gerar a estrutura de pacotes adequada Assim o UseCaseAgent conta com as seguintes funcionalidades e Cria o de um novo caso de uso e Edi o de um caso de uso j existente 201 Verifica o sint tica de diagramas de atividades que representam a especifica o de caoss de uso Impress o da especifica o de casos de uso no formato RTF e Gera
250. ngenharia dos requisitos As se es 4 4 a 4 7 detalham a abordagem focando desde a classifica o dos requisitos at a gera o de casos e procedimentos de testes funcionais Finalmente a se o 4 8 apresenta a conclus o resumindo o diferencial da abordagem de especifica o proposta em rela o a outros trabalhos na mesma linha 4 2 Vis o Geral da Abordagem Modelos t m sido usados em diversas reas da Engenharia como uma forma de documenta o das decis es de projeto comunica o entre os membros da equipe e compartilhamento de informa es para tomadas de decis o entre outras SWINGER e KOCH 2003 A utiliza o de modelos nos permite abstrair e simplificar a representa o de um problema ou solu o atrav s da utiliza o de elementos que capturem caracter sticas particulares criando assim um foco bem definido para o modelo Esse foco essencial pois permite diminuir a complexidade do modelo e fornecer uma perspectiva de leitura e compreens o para o mesmo V rios problemas da engenharia cl ssica demandam a representa o da solu o a partir de um conjunto de modelos que por sua vez visam representar as v rias facetas da solu o proposta OGREN 2000 Na Engenharia de Software mais especificamente a multiplicidade de perspectivas vem sendo explorada h bastante tempo Um exemplo cl ssico dessa multiplicidade o enfoque na estrutura dos dados capturado pelo modelo de Entidades e Relacionamentos C
251. nica do boleto system response a o n mero do boleto actor action boletol numero invalido cido lt lt navigation_rul solicita os dados relativos ao pagamento system response informa que os dados do pagamento s o inv lidos system response informa os dados do pagamento actor action dadosPagamentol 4 data invalida or dadosPagamentol desconto invalido or dadesPagamentel Jjuros invalidos or dadosPagamentol valor final invalido informa que a senha inv lida system response solicita a senha system response fornece a senha actor action senhal invalida and errol 3 encontra se bloqueada system response apresenta o comprovante de pagamento do boleto system response 159 1 1 2 Test Case Steps 1 Eolicita a fonte de recurso de onde ser debitado o pagamento system lt no description gt response 2 Seleciona uma das op es actor action lt no description gt 3 solicita o numero do boleto system response lt no description gt 4 digita o n mero do boleto actor action lt no description gt 5 informa que o n mero do boleto inv lido system response lt no description gt 6 solicita o numero do boleto system response lt no description gt 7 digita o n mero do boleto actor action lt no description gt 8 informa que n o poss vel pagar um boleto de outro banco ap
252. ntido especificar uma a o do ator ActorAction logo ap s uma a o do sistema SystemAction j que o ator nesse ponto ainda n o obteve nenhuma resposta informando o que aconteceu durante o processamento da requisi o Da mesma forma n o faz sentido especificar uma resposta do sistema SystemResponse logo ap s uma a o do ator ActorAction pois necess rio processar a requisi o para que o resultado a ser apresentado seja gerado As quatro se es a seguir discutem as combina es v lidas entre a o do ator ActorAtion a o do sistema SystemAction e resposta do sistema SystemResponse com a possibilidade de defini o de fluxos alternativos entre eles 5 3 5 1 Transa o B sica sem Fluxos Alternativos A Figura 5 11 apresenta o fluxo b sico das transi es permitidas pelo metamodelo UCModel envolvendo as a es ActorAction SystemAction e SystemResponse sem levar em conta a exist ncia de fluxos alternativo basic flow system action system response actor action system action system response 114 A Copias senta ee eee eee Figura 5 11 Transi es b sicas permitidas entre as a es ActorAction SystemAction e SystemResponse A Figura 5 11 mostra que 1 O sucessor do n inicial pode ser qualquer uma das tr s a es ou seja a descri o do fluxo de a es pode ser iniciada com qualquer uma das tr s a es 2 O antecessor do n final deve ser u
253. numero da conta corrente ou conta poupan a numero do boleto data de vencimento valor do boleto valor do desconto juros valor pago A1 op o inv lida A1 1 Sistema informa que deve ser selecionada uma op o A1 2 Vai para 1 A2 cliente seleciona op o de leitura eletr nica A2 1 Sistema solicita que o cliente fa a a leitura eletr nica do boleto A2 2 Cliente realiza a leitura eletr nica A2 3 Vai para 6 A3 numero do boleto invalido A3 1 Sistema informa que o n mero do boleto inv lido A3 2 Vai para 4 A4 data de vencimento menor que a data atual e o boleto foi emitido por outro banco A4 1 Sistema informa que n o poss vel pagar um boleto de outro banco ap s o vencimento A4 2 Encerra o caso de uso A5 dados de pagamento inv lidos A5 1 Sistema informa que os dados do pagamento s o inv lidos NR10 A5 2 Vai para 7 A6 senha invalida em menos de 3 tentativas A6 1 Sistema informa que a senha inv lida A6 2 Vai para 10 A7 senha inv lida na 3a tentativa A7 1 Sistema informa que a senha inv lida e que encontra se bloqueada Deve ser apresentada uma mensagem para que o cliente compare a ag ncia banc ria A7 2 Encerra o caso de uso N o h BRi1 obrigat ria a sele o de uma e apenas uma fonte de recurso BR2 E obrigat rio que o boleto seja emitido pelo banco se a data de vencimento for menor que a data corrente BR4 E obrigat rio que
254. o PORTER et al 1995 Na literatura t cnica poss vel encontrar diferentes t cnicas de inspe o que tratam documentos de requisitos Algumas dessas t cnicas s o capazes de inspecionar o documento de requisitos independente da abordagem usada para a sua especifica o MAFRA e TRAVASSOS 2006 enquanto outras foram especialmente projetadas para inspe o de casos de uso ANDA et al 2001 COX et al 2004 BELGAMO e FABBRI 2004 GREGOLIN e DEBONI 2008 sendo a maioria dessas ltimas baseadas em checklist Mais especificamente com respeito s quest es apresentadas pelas t cnicas baseadas em checklist elas geralmente variam de quest es puramente sint ticas por exemplo verifica o da consist ncia da numera o dos passos do caso de uso ou verifica o de defini es ausentes at quest es sem nticas de grande amplitude por exemplo verifica o da consist ncia do n vel de abstra o do caso de uso ou verifica o da clareza do objetivo do caso de Uso A abordagem proposta neste trabalho sugere a ado o de uma combina o de quest es a fim de maximizar a detec o de defeitos nos requisitos 1 Quest es gerais relacionadas ao gabarito adotado para descri o dos casos de uso 2 Quest es espec ficas relacionadas aos construtores usados na descri o dos casos de uso e 3 Detec o autom tica de defeitos sint ticos 87 Para a cobertura dos itens 1 e 2 poss vel aplicar a t cnica apresen
255. o As combina es nesse caso tamb m devem seguir o metamodelo do UCModel e Destino do goto X n o pertence cadeia de ativa o do fluxo O destino de uma a o goto deve ser obrigatoriamente uma das a es em um dos fluxos que ativou o fluxo do goto Por exemplo se o fluxo principal ativa o fluxo alternativo A1 e esse por sua vez ativa o fluxo alternativo A2 uma a o goto em A2 deve ter como destino uma a o de A1 ou do fluxo principal que fazem parte da cadeia de ativa o de A2 221 AP NDICE B Exemplo de Casos e Procedimentos de Teste Funcional Este ap ndice apresenta o plano de testes funcionais gerado pela ferramenta TDE UML referente ao caso de uso Pagar boleto banc rio apresentado como exemplo na se o 6 3 p gina 151 1 Test Cases 1 1 Test Case TC001_TP1 1 1 1 Test Case Path 228 Pagar Boleto Bancario A Ee que deve ser selecionada uma op o Ee response lt lt business_rule gt Bs lt lt business_rule gt gt informa queo n mero do boleto inv lido system boletol numero response boletol z informa que n o poss vel pagar um boleto de outro banco ap s o vencimento system response digita o n mero do boleto actor action cido solicita a fonte de recurso de onde ser debitado o pagamento system response seleciona uma das op es actor action lt lt business_rule gt gt 08 so
256. o comportamento do caso de uso O Cap tulo 5 apresenta uma descri o completa do metamodelo UCModel e de seus elementos 4 5 3 3 Detalhamento do Comportamento A especifica o do comportamento de sistemas complexos especialmente aqueles orientados a processos requer que o desenvolvedor explore o uso de formalismos alternativos para sua representa o j que o n vel de abstra o oferecido pelos di logos ator sistema n o o mais adequado para o detalhamento de comportamentos sist micos O que a abordagem apresentada neste trabalho prop e e o metamodelo UCModel tenta garantir que o n vel de abstra o da descri o dos casos de uso esteja mais pr ximo da vis o do ator o que o sistema deve fazer do que da vis o interna do sistema como o sistema deve fazer Entretanto durante a especifica o funcional muitas vezes torna se necess rio o detalhamento de uma a o do sistema que apresenta se at mica no n vel de abstra o do caso de uso mas est associada a uma s rie de regras comportamentais que devem ser validadas pelos stakeholders e posteriormente observadas pelos desenvolvedores O diagrama de atividades da UML OMG 2010a possui um recurso que ap ia essa necessidade a habilidade de detalhar uma a o com um diagrama de atividades ou seja o diagrama de atividades associado a o t m o objetivo de detalhar o comportamento da mesma A Figura 4 7 apresenta a especifica o do caso de uso Concluir
257. o de WBS Work Breakdow Structure a descri o dos principais servi os da aplica o a defini o das op es de navega o a especifica o das entidades e a defini o de 12 http www w3 0rg MarkUp Forms 48 pol ticas de seguran a O projeto detalhado envolve o detalhamento de todos os elementos definidos na fase anterior e a especifica o da apresenta o Na fase de avalia o s o criados e avaliados os prot tipos da aplica o A completude consist ncia e integridade dos v rios artefatos gerados durante as fases de projeto conceitual e detalhado s o garantidas atrav s de um conjunto de regras Todo o processo apoiado por uma ferramenta denominada AriadneTool 3 2 3 19 WRM Web Requirements Metamodel O WRM MOLINA et al 2008 uma abordagem para modelagem e gerenciamento de requisitos funcionais e n o funcionais onde cada requisito est sempre associado a um objetivo que por sua vez definido por um stakeholder O WRM define que o requisito seja descrito em linguagem natural mas para prevenir ambig idades essa descri o tem que ser feita a partir de termos armazenados no gloss rio do projeto O WRM prev que cada requisito pode ser refinado atrav s de v rias descri es Assim o desenvolvedor pode armazenar nessas descri es casos de uso cen rios templates modelos ou qualquer outro artefato desejado O WRM tamb m prev um cat logo para armazenamento de leis regras ou orienta
258. o de especifica o documenta o confusa e ou inadequada Falta de experi ncia na cria o do modelo Ferramenta case componentes inadequados para constru o do modelo Complexidade do diagrama Ordem com que os modelos foram constru dos Divis o de tarefas responsabilidades entre a equipe e So No a F amp O DN Perspectiva de projeto inconsistente usada pela equipe A cria o dessa lista de fatores se baseou nas an lises feitas nos question rios A Tabela 2 10 sumariza os tr s fatores que trouxeram mais dificuldades para cada modelo na dos primeiro e segundo estudos de observa o anteriormente descritos percep o dos participantes do estudo Tabela 2 10 Fatores de dificuldade apontados pelos participantes Dificuldade Classe Sequ ncia pa eral aes Es a SA ca h CA a ES E na cria o do modelo Fenamenta case PP E Treinamento f zee especifica o Complexidade do ES diagrama Ordem de constru o dos modelos A quinta e ltima quest o foi concebida com o intuito de capturar o que poderia ser feito na opini o dos participantes para diminuir o esfor o ou eventuais dificuldades no uso desses modelos A pergunta formulada foi 25 Na sua opini o de engenheiro de software o que poderia ser feito para diminuir o esfor o dificuldade com estes modelos Foi solicitada uma resposta separada para cada um dos modelos envolvidos no estudo Por se tratar de uma quest o aberta as respo
259. o de observa o Nome 1 Da abordagem de Desenvolvimento A Do ponto de vista do desenvolvimento do software a abordagem que voc s usaram se demonstrou adequada Comente B As dimens es WEB conceitual navega o visualiza o e estrutura o sugeridas para o processo provocaram algum tipo de dificuldade facilidade para o desenvolvimento dos artefatos de projeto C Destes artefatos mapa de atores diagrama de contexto mapa de navega o telas de visualiza o qual voc considera que n o se aplicaria diretamente ao seu projeto Comente D O que voc sugeriria ser modificado na abordagem utilizada para apoiar o desenvolvimento de futuros projetos ex nota o modelos UML etc 2 Do trabalho da Disciplina A Comente sobre o projeto em geral Quais os principais problemas encontrados O que dificultou o andamento das atividades B Em rela o s estimativas iniciais o que voc acredita que n o foi considerado que poderia ter alterado sua percep o sobre o projeto tempo custo ferramentas plataformas etc C Como foi a participa o da equipe no projeto Numa escala de 0 10 classifique a participa o de cada um incluindo a sua segundo sua percep o no contexto deste projeto D Voc usaria os princ pios discutidos no curso em futuros projetos Comente 239 C 2 Question rio do 3 estudo de observa o EEL 884 Question rio Esse question rio deve ser preenchido
260. o de regras de navega o segundo a SBVR Termos funcion rio nome CPF data de nascimento estado civil nome do c njuge data de casamento formul rio de cadastro de funcion rio casado solteiro perfil usu rio rh financeiro ger ncia Tipos de fatos formul rio de cadastramento de funcion rio possui nome CPF nome data de nascimento estado civil nome do c njuge e data de casamento estado civil pode ser casado ou solteiro usu rio tem perfil perfil pode ser rh financeiro ou ger ncia usu rio pode cadastrar funcion rio Regras R1 O formul rio de cadastramento de funcion rio requer CPF estruturais nome data de nascimento estado civil nome do c njuge e data de casamento Regras R2 obrigat rio que nome do c njuge e data de casamento comportamentais sejam informados se o estado civil for casado 76 R3 proibido que o usu rio acesse a funcionalidade de cadastramento de funcion rio se este n o tiver perfil RH As regras estruturais representam quais informa es estar o acess veis aos usu rios e poss veis restri es a esse acesso Sendo assim essa descri o pode ser feita em linguagem natural estruturada como um detalhamento da intera o entre o ator e o sistema na descri o do caso de uso Tabela 4 2 p gina 61 Ou seja ao especificar as intera es entre o ator e o sistema essas regras podem estar associadas essas intera es no sentido de detal
261. o de uso Pagar DOIGIO DANCANO sai ES ro SA Gaia parada tees ATRASO URU aie 142 Figura 6 7 Tela da UseCaseAgent com as regras do caso de uso Pagar boleto DANCANO Siafi parse nc Dinda dani aa entaks le Parada dia ana aaa dedo 142 Figura 6 8 Tela da UseCaseAgent com a lista de defeitos do caso de uso Pagar boleto banc rio ss sseece es sadio elect a a i AA Tea Dead ADO qa PER A GA DARE Cedae 143 Figura 6 9 Diagrama de atividades com a especifica o do caso de uso Pagar boleto bancario eiaa eia eta ed Dar Rated 144 Figura 6 10 Tela da UseCaseAgent para sele o dos casos de uso que far o parte do documento ds CS PSCIICACAO mess uines 2a Ba bet Bonet seco foro weatict ad cast pra ene Rone 145 Figura 6 11 Tela da UseCaseAgent para impress o das especifica es de casos de Uso em tormato RTE assino EE o cUnds soa Lada AE A 146 Figura 6 12 Representa o em formato texto da especifica o do caso de uso Pagar DOlSIG DANCA crer sirene tcp as ed A RO Sa UE RES 148 Figura 6 13 Tela inicial da ModelT para sele o dos casos de USO 154 Figura 6 14 Segunda tela da ModelT que indica os casos de uso que est o aptos a terem seus modelos de teste gerados raras anna 154 Figura 6 15 Modelo de testes gerado pela ModelT2 referente ao caso de uso Paga r boleto banc rio 155 Figura 6 16 Modelo de testes referente ao caso de uso Autenticar usu rio alterado pelo analista de TOSIOS sa teannen
262. o do sistema sob a tica de quem interage com ele ROSENBERG e STEPHENS 2007 sendo tal comportamento descrito a partir de uma sequ ncia de a es que definem como essa intera o ocorre Assim a flexibilidade para descrever processos do diagrama de atividades em diversos n veis de abstra o e o alinhamento conceitual entre a sequ ncia de a es do diagrama de atividades e a sequ ncia de a es do caso de uso fizeram surgir algumas propostas de explora o deste modelo para especifica o do comportamento de casos de uso NAKATANI et al 2001 ALMENDROS JIMENEZ e IRIBARNE 2005 KOCH et al 2006 GUTI RREZ et al 2008 Entretanto essas propostas se limitam a explorar o diagrama de atividades para descrever o comportamento do caso de uso utilizando somente os elementos originalmente propostos na UML ou seja sem estender a sem ntica dos elementos que comp em os diagramas de atividades Esse cen rio nos leva s seguintes restri es e A representa o do caso de uso atrav s de um diagrama de atividades semanticamente equivalente sua descri o textual pois n o h especializa o de nenhum elemento do diagrama de atividades com o objetivo de alterar a sem ntica original e Os diagramas representam somente a descri o do comportamento do caso de uso ou seja a sua sequ ncia de a es Os demais elementos que 95 comp em o caso de uso descri o atores criticalidade frequ ncia de uso trigger pr e
263. o em quest es tecnol gicas STANDING 2002 Esse argumento refor ado se levarmos 32 em considera o que a forma o tradicional dos desenvolvedores de software prioriza mais as fases relacionadas manufatura coding do que ao projeto design ou ao tratamento dos requisitos Em paralelo a esses estudos o grupo de Engenharia de Software Experimental da COPPE UFRJ tem estado envolvido com o desenvolvimento de um sistema de informa o Web larga escala denominado SiGIC Esse sistema apesar de aparentemente representar um sistema tradicional orientado a dados respons vel pela integra o de todas as reas de neg cio da organiza o tanto do ponto de vista gerencial quanto operacional A criticidade e a abrang ncia dessa atua o lhe conferem uma complexidade semelhante aos sistemas de gest o corporativa ou ERP Enterprise Resource Planing LOZINSKY 1998 apud PRESSMAN 2000b A automa o de processos de neg cio muitas vezes envolvendo workflows entre reas da organiza o ou entre a organiza o e entidades externas seguran a e auditoria nas opera es realizadas integra o com sistemas legados entre outros s o alguns dos requisitos demandados no contexto desse sistema O cen rio de desenvolvimento do SiGIC possibilitou com o apoio da experimenta o a explora o de algumas id ias e temas de pesquisa relacionados Engenharia de Aplica es Web como e Aplica o de t cnicas de inspe o em m d
264. o especificados com a ferramenta UseCaseAgent tendem a apresentar um n mero menor de defeitos quando comparados com diagramas de atividades de casos de uso especificados sem esse apoio No contexto desse estudo as principais raz es para esse comportamento s o e O metamodelo UCModel ap ia a remo o de defeitos de requisitos 178 A ferramenta UseCaseAgent previne a introdu o de defeitos nos diagramas de atividades de casos de uso quando comparado ao uso de um editor comum de diagramas de atividades e A ferramenta UseCaseAgent evita transforma es desnecess rias o que ap ia a afirma o de que parte dos defeitos existentes em determinado artefato introduzido por falhas humanas durante o processo de transforma o desses artefatos RAMLER et al 2010 A an lise das categorias dos 29 defeitos encontrados no documento de requisito s original Tabela 7 7 quinta coluna mostrou que 8 eram fatos incorretos 2 relacionados a desvios equivocados no controle de fluxo e 6 relacionados a descri es de a es que juntavam a es de tipos diferentes e 21 eram omiss es todos relacionados a comportamentos sist micos n o explicitamente especificados A exist ncia dessas omiss es pode ter v rios impactos negativos como por exemplo Os desenvolvedores podem ter m ltiplas interpreta es do que deve ser projetado implementado testado Detalhes sobre os procedimentos ou restri es associadas a esses compor
265. o m ximo poss vel a participa o atrav s do arranjo de distribui o dos casos de uso o que permitiu gerar 32 pontos de observa o considerando 8 participantes 180 e Classifica o das discrep ncias em defeitos ou falsos positivos poucas discrep ncias n o tiveram consenso entre os pesquisadores sobre se estas eram ou n o defeitos Entretanto esse mecanismo de avalia o precisa ser aprimorado em estudos futuros com a participa o de outros pesquisadores a fim de tornar o resultado da reuni o de discuss o mais preciso e ou a utiliza o dos defeitos detectados no segundo estudo como um ponto de partida para futuras avalia es e Medi o da complexidade dos casos de uso em um cen rio ideal a complexidade ou o tamanho dos casos de uso deveria ser obtido atrav s de algum m todo com evid ncias na literatura t cnica para medi o desses artefatos Entretanto como a especifica o dos casos de uso usada no estudo foi realizada dentro do mesmo contexto no que diz respeito ao dom nio do problema tecnologias empregadas e recursos humanos o risco de compara o entre esses casos de uso usando as medidas obtidas com o m todo ad hoc descrito na se o 7 2 2 minimizado e e Medi o da experi ncia dos participantes a mitiga o desse risco foi feita atrav s da avalia o dos perfis dos participantes por dois pesquisadores envolvendo ainda um terceiro pesquisador para avaliar e referendar a classific
266. o ou n o funcional Para cada tipo de requisito existe um gabarito espec fico que direciona o desenvolvedor no seu preenchimento criando um processo sistem tico Com o apoio dos gabaritos os requisitos s o descritos em linguagem natural estruturada Requisitos funcionais s o descritos atrav s de um gabarito para casos de uso Ap s a especifica o os requisitos s o revisados e criada uma matriz de rastreabilidade para verificar se todos os requisitos foram especificados A fase de an lise tem in cio com a gera o dos modelos preliminares de an lise a partir dos modelos de especifica o Esses modelos s o ent o alterados pelos desenvolvedores para obter os modelos de an lise A partir desse ponto o NDT sugere o uso dos modelos do m todo UWE no restante do processo de desenvolvimento 3 2 3 12 WebGen O WebGen LOH e ROBEY 2004 prop e uma abordagem para gera o do modelo navegacional e de trechos de c digo para a aplica o final a partir da descri o de casos de uso O processo se inicia com a especifica o textual dos casos de uso onde cada a o descrita deve ser classificada como uma a o do ator ou uma a o do sistema Em seguida para cada cen rio do caso de uso s o definidas p ginas com as informa es que cada uma deve conter Para cada cen rio o desenvolvedor mapeia os ciclos a o do ator a o do sistema em um ciclo request response que representa no jarg o do protocolo HTTP uma solic
267. o para que seja poss vel especificar outras informa es relevantes no contexto de um projeto espec fico Todavia este o conjunto m nimo organizado para apoiar a especifica o de requisitos funcionais de aplica es Web segundo a abordagem proposta O detalhamento de cada um desses elementos apresentado nas se es a seguir 4 5 1 Modelos Conceituais As informa es coletadas na elicita o de requisitos podem ter v rias fontes usu rios documentos sistemas legados e modelos dentre outros e estar representadas de diversas formas textos em linguagem natural planilhas eletr nicas grava es de udio de entrevistas modelos de processos e estruturas c digos fonte ou outros artefatos Os modelos conceituais na especifica o de requisitos t m o objetivo de organizar e representar os conceitos contidos nessas fontes e que s o tratados no escopo do sistema entidades atributos associa es eventos estados processos dentre outros LAMSWEERDE 2009 Esses conceitos s o em grande parte entidades que comp em o dom nio do problema por m tamb m devem ser consideradas as entidades relacionadas ao escopo do sistema ou seja entidades que n o fazem parte do dom nio do problema mas s o tratadas ou referenciadas nos requisitos do sistema A nota o adotada para representar entidades conceituais e suas estruturas atributos e associa es o diagrama de classes da UML OMG 2010a cujo enfoque estrutural se
268. o prev a identifica o defini o e valida o dos requisitos durante a fase de projeto design ou seja o processo organizado de tal forma que as atividades de engenharia de requisitos e projeto ocorrem simultaneamente Esse processo baseia se na prototipa o a fim de explorer poss veis solu es para o problema Os usu rios definem os requisitos a partir da avalia o dos prot tipos e estes s o alterados para refletir os requisitos dentro de um processo iterativo que procura reduzir as d vidas dos usu rios Um ciclo completo nesse processo possui tr s fases avalia o especifica o e constru o importante destacar que nesse processo a especifica o do sistema o pr prio prot tipo A concep o do processo foi baseada na an lise das melhores pr ticas de desenvolvimento de aplica es Web comerciais Os requisitos s o classificados de v ria formas mas s o tratados da mesmo maneira 3 2 3 10 UWA Ubiquitous Web Application O m todo UWA PERRONE e PAOLINI 2003 BERNARDI et al 2010 divide o processo de desenvolvimento nas seguintes fases e Elicita o de requisitos nesta fase os stakeholders e os requisitos s o identificados atrav s de uma metodologia orientada a objetivos ou seja s o identificados os objetivos de cada stakeholders no uso do sistema Nesse momento os requisitos s o associados aos objetivos e s o classificados em Conte do a informa o que est sendo disponi
269. odas as configura es necess rias 202 Dessa forma para criar um novo projeto basta abrir o projeto Template e usar a op o Save as para criar efetivamente o projeto desejado Importante como o UseCaseAgent foi desenvolvido em Java para que a sua execu o seja bem sucedida o JRE vers o 1 6 ou superior deve estar instalado e dispon vel a partir de um diret rio qualquer Para verificar essa condi o basta abrir uma janela do console e digitar java version conforme Figura A 1 r u O O TER EE BA Administrador C Windows system32 cmd exe C N gt java version java version 1 6 8 21 Java TM gt SE Runtime Environment build 1 6 0 21 hb87 gt Java HotSpot TM gt D Client UM Cbhuild 17 b17 mixed mode sharing th Figura A 1 Janela do console do sistema para verifica o da vers o do JRE A 4 Cria o dos Atores O UseCaseAgent nao cria os atores que serao associados aos caso de uso Para essa tarefa deve ser usado o proprio BOUML Os atores devem ser criados obrigatoriamente na pasta lt lt actors gt gt pois nessa pasta que o plug in ira buscar os atores candidatos Figura A 2 Caso voc acione o UseCaseAgent e se lembre que esqueceu de criar o ator do caso de uso voc dever sair do UseCaseAgent criar o ator e depois acionar o UseCaseAgent novamente 203 a Freeware Bouml C JOBSON Doutorado Projetos UCModel TestesUseCaseAgent tempiate template pr e
270. ode ser definido como curso normal caminho b sico fluxo principal fluxo otimista caminho alternativo ou fluxo alternativo dentre outros Em alguns casos a diferen a est apenas no nome do elemento mas em outros existe uma interpreta o diferente para 80 esses termos Apesar dessa varia o poss vel distinguir nos gabaritos adotados nesses trabalhos um conjunto de elementos comuns presentes em mais da metade dos trabalhos listados anteriormente nome descri o ator pr condi es p s condi es cen rio principal cen rios secund rios e requisitos especiais A abordagem proposta neste trabalho tamb m adota um conjunto de elementos para descri o de casos de uso Esse conjunto foi definido a partir da relev ncia desses elementos no contexto da abordagem proposta e est alinhado com o corpo de conhecimento existente na literatura t cnica A Tabela 4 10 apresenta os elementos adotados para descri o de casos de uso e suas respectivas defini es comumente utilizados pelo grupo de Engenharia de Software Experimental da COPPE UFRJ e que foram inspirados nos trabalhos de MUSA 1992 MEYER 2004 e JACOBSON 1992 Tabela 4 10 Gabarito de caso de uso adotado na abordagem proposta Elemento Descri o ID Identificador nico do caso de uso Nome Nome do caso de uso Descri o Uma breve descri o sobre o objetivo do caso de uso Ator es Nome s do s ator es que participa m do caso de
271. om essa consist ncia no tratamento dos requisitos se justifica porque os m todos contempor neos de desenvolvimento Web propostos na literatura t cnica exploram modelos que se prop em a representar essas mesmas dimens es Esta abordagem prop e tamb m a explora o de modelos conceituais para representa o das entidades relacionadas ao dom nio do problema juntamente com sua estrutura e comportamento e modelos de casos de uso para especifica o do comportamento esperado do sistema do ponto de vista dos seus usu rios Para 57 modelagem dos casos de uso a abordagem adota um metamodelo chamado UCModel definido no escopo deste trabalho O objetivo desse metamodelo permitir a estrutura o da especifica o dos casos de uso segundo um conjunto de crit rios e restri es bem definido e oferecer um arcabou o sint tico e sem ntico para apoiar o controle da qualidade da especifica o e do produto final Assim a estrutura que ap ia a an lise classifica o e especifica o dos requisitos funcionais oferece um arcabou o acoplado conceitualmente ao arcabou o de modelagem utilizado pelos m todos Web contempor neos e que pode ser explorado em conjunto com tais m todos suprindo os com um tratamento consistente dos requisitos e com o controle de qualidade da especifica o e do produto final A se o 4 2 apresenta uma vis o geral da abordagem e seu escopo de atua o A se o 4 3 apresenta o processo adotado para e
272. onse complement IncludeUCAction complement ExtendUCAction complement Fluxo alternativos associados a o Action alternativeFlows 9 Fluxo de exce o associados a o BehavioralAction exceptionFlows 10 Detalhamento do comportamento da BehavioralAction behavior 11 a o Desvio incondicional GotoAction 12 Destino da desvio GotoAction target 13 Fim da execu o de fluxo FinishAction 14 alternativo exce o Inclus o de caso de uso IncludeUCAction 15 Extens o de caso de uso ExtendUCAction 16 Caso de uso incluido IncludeUCAction uc 17 Caso de uso que estende o atual ExtendUCAction uc 17 111 Metamodelo da UML vis o parcial lt lt metaclass gt gt lt lt metaclass gt gt ActivityEdge 00m9 NamedElement source lt smetaclass gt a ActivityNode Activity EEEF Ss EE ZS lt lt metaclass gt gt ExecutableNode PD E lt lt metaclass gt gt lt lt metaclass gt Cossirent cian specification Zs Metamodelo UCModel visao parcial Lo target Figura 5 10 Vis o parcial do metamodelo UCModel referente s a es que comp em os fluxos do caso de uso e a sua rela o com o metamodelo da UML Dois elementos do metamodelo UCModel apresentado na Figura 5 10 merecem explica es adicionais e Detalhamento do comportamento da a o destaque 11 conforme definido no UCModel poss vel detalhar o comportamento de uma SystemAction ou Sys
273. onse lida com elementos da interface com o mundo externo seja essa uma interface gr fica padr o ou uma interface n o convencional representada por algum tipo de dispositivo Apesar de serem a base para especifica o de casos de uso as tr s a es definidas na Tabela 5 8 n o s o suficientes para cobrir situa es relacionadas ao controle da execu o e conceitos como include e extend Para tal foram inclu dos mais quatro tipos de a o Como o metamodelo UCModel n o prev que a descri o do caso de uso utilize estruturas de controle do tipo fa a enquanto ou se ent o s o necess rias mais duas especializa es da metaclasse Action da UML conforme apresentado na Tabela 5 9 Tabela 5 9 Tipos de a es para estrutura o da descri o do caso de uso Tipo da A o Descri o GotoAction Define um desvio incondicional para um determinado ponto do caso de uso i FinishAction Termina a execu o do caso de uso E usada somente nos fluxos alternativos e de exce o para indicar explicitamente o fim do caso de uso importante destacar que a FinishAction s pode ser usada em fluxos alternativos ou de exce o A raz o para isso que todo fluxo alternativo exce o deve indicar explicitamente se a execu o continua em outro ponto do caso de uso GotoAction ou se o caso de uso deve ser encerrado FinishAction Para atender aos conceitos de inclus o lt lt include gt gt e extens o
274. onto de vista dos inspetores de requisitos no contexto de inspe o ad hoc de diagramas de atividades descrevendo casos de uso do m dulo financeiro de um sistema de informa o Web de larga escala por estudantes de p s gradua o de Engenharia de Software 7 3 2 Sele o do Contexto Do total de oito casos de uso especificados e analisados no primeiro estudo quatro foram selecionados para o segundo estudo 6 15 36 e 40 S foi poss vel selecionar quatro casos de uso devido ao n mero de participantes dispon veis para este segundo estudo n mero de alunos inscritos na disciplina onde foi conduzido o estudo Os quatro casos de uso foram escolhidos por conveni ncia tentando selecionar aqueles com diferentes n veis de complexidade e especificados anteriormente pelos desenvolvedores tanto com a ferramenta UCA quanto com a ferramenta EDA 172 7 3 3 Sele o de Vari veis Nesse estudo a vari vel independente a especifica o dos casos de uso escala nominal enquanto a vari vel dependente o n mero de defeitos detectados na especifica o de casos de uso escala raz o Assim esse estudo tamb m pode ser caracterizado como um fator especifica o de caso de uso e dois tratamentos especifica es de casos de uso criadas com a UCA e com a EDA 7 3 4 Participantes Os participantes foram selecionados por conveni ncia em uma disciplina de Verifica o Valida o e Teste VV amp T oferecida em um
275. oposta nesta teste oferece oportunidades de pesquisa que diz respeito a Repeti o dos Estudos sobre a Abordagem Apesar dos ind cios de viabilidade e redu o de defeitos em documentos de especifica o obtidos com os estudos conduzidos no escopo deste trabalho a repeti o desses estudos reusando o mesmo pacote pode fortalecer as evid ncias obtidas atrav s do uso de uma quantidade maior de participantes e indicar dire es para o aprimoramento da abordagem Avalia o do Arcabou o de Testes Funcionais Faz se necess ria a avalia o do arcabou o para gera o dos casos e procedimentos de testes funcionais mais precisamente no que diz respeito 1 cobertura do modelo de testes em rela o s regras e pr p s condi es estabelecidos no modelo de especifica o e 2 adequa o do apoio criado no modelo de testes preliminar para auxiliar o analista de testes na sua complementa o Aprimoramento do Metamodelo de Testes Funcionais O metamodelo TDE implementa o modelo de testes com uma vis o caixa preta do sistema Essa abordagem adequada na explora o de cen rio onde a interface reflete totalmente o comportamento esperado do sistema Nesse contexto a oportunidade de pesquisa esta no aprimoramento do metamodelo TDE para tratamento das a es e estados internos do sistema visando a avalia o de p s 186 condi es de forma independente da interface deste com o mundo externo e a adapta o de ModelT
276. oram observadas lacunas relacionadas ao tema central dessa pesquisa conforme visto no Cap tulo 2 Al m disso entendemos que a abordagem proposta nesta tese embora em sua vers o inicial j consegue proporcionar uma s rie de oportunidades de pesquisa visando oferecer um conjunto de tecnologias desenvolvidas com o apoio da experimenta o que permitam a evolu o do corpo de conhecimento da Engenharia de Aplica es Web 187 REFER NCIAS BIBLIOGR FICAS ABRAH O S CONDORI FERNANDEZ N OLSINA L PASTOR O 2003 Defining and Validating Metrics for Navigational Models Proceedings of the 9 International Symposium on Software Metrics pp 200 210 ACKERMAN A BUCHWALD L LEWSKI F 1989 Software Inspections An Effective Verification Process IEEE Software v 6 n 3 pp 31 37 AGUILAR J A GARRIGOS I MAZON J TRUJILLO J 2010 An MDA approach for goal oriented requirement analysis in Web engineering Journal of Universal Computer Science v 16 n 16 pp 2475 2495 ALBUQUERQUE P P B MASSOLLAR J L TRAVASSOS G H 2010 ModelT2 Apoio Ferramental Gera o de Casos e Procedimentos de Testes Funcionais a partir de Casos de Uso Anais do XXIV Simp sio Brasileiro de Engenharia de Software SBES 10 ALMENDROS JIM NEZ J M IRIBARNE L 2005 Describing Use Cases with Activity Charts LNCS v 3511 pp 153 167 ANDA B SJOBERG D JORGENSEN M 2001
277. ormation Systems v 11 n 1 pp 1 26 GINIGE A MURUGESAN S 2001 Web Engineering an Introduction IEEE Multimedia v 8 n 1 pp 14 18 G IS F FARIAS P OLIVEIRA R 2010 Test Script Diagram Um modelo para gera o de scripts de testes Anais do IX Simp sio Brasileiro de Qualidade de Software SBQS 10 pp 73 87 192 GREGOLIN R DEBONI J E Z 2008 Inspe o de Qualidade em Descri es de Casos de Uso Uma Proposta de Modelos e Artefatos Anais do VII Simp sio Brasileiro de Qualidade de Software SBQS 08 Florian polis Brasil GUTIERREZ J J NEBUT C ESCALONA M J MEJIAS M RAMOS M 2008 Visualization of use cases through automatically generated activity diagrams Proceedings of the 11th International Conference on Model Driven Engineering Languages and Systems MODELS 08 pp 83 96 HALPIN T 2006 Business Rule Modality Proceedings of 11th International Workshop on Exploring Modeling Methods in Systems Analysis and Design EMMSAD HAN W M HUANG S J 2007 An empirical analysis of risk components and performance on software projects Journal of Systems and Software v 80 n 1 pp 42 50 HARTMANN J VIEIRA M FOSTER H RUDER A 2005 A UML based approach to system testing Journal of Innovations in Systems and Software Engineering v 1 n 1 p 12 24 HENNICKER R KOCH N 2000 A UML Based Methodo
278. orrido A condi o de guarda do fluxo substitu da por fluxo sim Regras Rules Coment rios Caso as regras estejam associadas a uma a o do sistema os coment rio devem ser associadas s a es anteriores esta Por ser implementado como um plug in do BOUML PAGES 2011 a ModelT capaz de ler o modelo de casos de uso aplicar as regras de deriva o e gerar o modelo de testes diretamente na ferramenta BOUML sem a necessidade de exportar ou importar esses modelos Assim basta o analista de testes selecionar o pacote raiz estereotipado lt lt tc model gt gt e sem seguida acionar a op o Tools gt Create Test Models para executar a ModelT A Figura 6 13 e a Figura 6 14 mostram respectivamente a tela de sele o dos casos de uso para os quais os modelos de teste ser o gerados e a tela que confirma quais casos de uso est o em conformidade com o metamodelo UCModel ou seja antes da gera o do modelo de testes necess rio que o modelo de casos de uso atenda a todas as restri es do metamodelo UCModel 153 r 2 ModeiT2 vers o 2 alo Model p Selecione os Casos de Uso UCOO1 Pagar boleto banc rio ATUALIZAR 7 Ucooz Transfer ncia entre contas NOVO E UC003 Emitir extrato NOVO Autenticar usu rio ATUALIZAR Conduir compra NOVO Grupo de Engenharia de Software Experimental COPPE UFRJ ese cos ufrj br Figura 6 13
279. p s condi es e regras s o ignorados e e Mesmo com o foco voltado para a descri o do comportamento n o poss vel distinguir no diagrama de atividades o fluxo principal dos fluxos alternativos pois o caso de uso descrito como uma sequ ncia de a es e decis es sem contrapartida com os conceitos do caso de uso Com o objetivo de tratar essas quest es o metamodelo UCModel prop e um conjunto de elementos e restri es que visam mapear todos os conceitos do caso de uso explorados pela abordagem de especifica o proposta neste trabalho Tabela 4 10 p gina 81 de forma que o caso de uso possa ser completamente descrito usando o diagrama de atividades Em complemento o UCModel procura explorar o conceito de transa o preconizado por JACOBSON 1992 com o objetivo de criar um conjunto especializado de a es a partir das quais os diversos fluxos do caso de uso possam ser descritos 5 3 O Metamodelo UCModel De acordo com B ZIVIN 2006 um metamodelo descreve os diversos tipos de elementos contidos em um modelo e a forma como eles s o arranjados relacionados e restringidos ou seja um metamodelo define a linguagem a ser usada por modelos que estejam em conformidade com ele Entretanto antes de definir concretamente quais elementos far o parte do metamodelo necess rio definir quais informa es ser o capturadas e suas respectivas defini es No caso do metamodelo UCModel o conjunto de informa e
280. para Controle de Invent rio Patrimonial por alunos de gradua o do curso de Engenharia de Computa o e Informa o da UFRJ 2 4 2 Contexto Nesse estudo os participantes focaram novamente em uma nica aplica o Web A escolha da aplica o baseou se principalmente no interesse dos pesquisadores em aumentar o grau de complexidade da aplica o a ser modelada Assim a especifica o da aplica o de Controle de Invent rio Patrimonial usada no primeiro estudo foi revista e ampliada para que novos casos de uso fossem 21 incorporados A nova vers o da especifica o passou a ser composta por 17 casos de uso 2 4 3 Projeto do Estudo A divis o das equipes seguiu dois crit rios a experi ncia dos participantes e a assiduidade nas aulas de forma a manter os alunos mais ass duos em um mesmo grupo O crit rio da assiduidade foi adotado para que os alunos que tiveram menor participa o nas aulas te ricas n o influenciassem negativamente no desempenho daqueles que participaram de todas as discuss es envolvendo a constru o dos modelos Foram definidas dez equipes com tr s participantes e uma equipe com quatro participantes As equipes tiveram a liberdade de se organizarem internamente e n o foi exigido que nenhum processo de desenvolvimento espec fico fosse seguido Foi sugerido que as equipes utilizassem os diagramas de classes sequ ncia atividades e estado o mapa de atores e o mapa navegacional Entretanto cada
281. participantes do estudo onde as respostas poss veis variavam de 0 nenhuma import ncia a 6 muito importante Visando realizar uma avalia o mais justa a resposta de cada participante foi multiplicada por um peso que indicava como o participante manipulou o artefato e N o criou nem revisou peso 0 e S revisou peso 1 e S criou peso 2 e e Criou e revisou peso 3 A Tabela 2 9 resume a distribui o de import ncia percebida pelos participantes por diagrama destacando para cada diagrama as import ncias que obtiveram vota o mais expressiva Tabela 2 9 Distribui o de import ncia percebida pelos participantes por diagrama Import ncia Classe Sequ ncia Estado Atividade Ator Navega Percebida o 0 sem import ncia 0 0 0 0 1 4 0 9 0 6 0 0 1 0 0 0 0 12 4 2 6 66 9 9 2 2 0 0 0 0 11 1 6 8 9 6 51 5 3 0 0 5 0 55 3 10 3 9 6 0 6 24 4 0 0 10 6 18 4 61 5 0 0 30 7 5 0 2 68 8 0 0 17 9 13 4 6 1 6 muito importante 99 8 15 6 1 4 0 0 0 0 1 8 Total 100 100 100 100 100 100 Nessa quest o os participantes puderam apontar at tr s fatores de uma lista pr definida de nove fatores a saber 1 Treinamento exemplos qualidade do material disponibilizado entre outros Complexidade do sistema dificuldade de entendimento do dominio Document
282. permitindo a sua edi o e Erros mostra a lista de erros ap s acionar a verifica o sint tica do caso de Uso A 6 Dados Gerais do Caso de Uso Ao clicar no caso de uso destacado em vermelho caso de uso que est sendo criado editado apresentada a tela da Figura A 5 Nessa tela devem ser informados os dados b sicos do caso de uso Repare que na cria o o n mero do caso de uso gerado automaticamente pelo plug in 2 Use Case Agent ver o 039 STE eis Arquivo Verificar do amp UCModel e Atores CasodeUso 4 E Casos de Uso Nome Autenticar usu rio UCO01 Pagar boleto ban UC002 Transfer ncia ent Descri o Esse caso de uso permite que o usu rio fa a a sua autentica o no sistema UCOO3 Emitir extrato UCOD4 Autenticar usu ri UC005 Conduir compra Criticalidade Alta Frequencia Alta E O usu rio acessa a tela inicial do sistema Trigger Pr condi o O usu rio n o encontra se autenticado P s condi o O menu principal da aplica o apresentado de acordo com o perfil do usu rio Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 5 Tela do UseCaseAgent para defini o dos dados b sicos do caso de uso 207 A 7 Atores do Caso de Uso Ao clicar na op o Atores do Caso de Uso apresentada a tela da Figura A S Use Case Agent vers o 0 3 EE
283. pp 235 240 OGATA S MATSUURA S 2010 Evaluation of a use case driven requirements analysis tool employing web UI prototype generation WSEAS Transactions on Information Science and Applications v 7 n 2 pp 273 282 196 OGREN 2000 On principles for model based systems engineering Systems Engineering Journal v 3 n 1 pp 38 49 OLSINA L 1998 Building a Web based Information System applying the Hypermedia Flexible Process Modeling Strategy Proceeding of 1 International Workshop on Hypermedia Development Hypertext 98 Pittsburg EUA OMG 2008 Semantics of Business Vocabulary and Business Rules version 1 0 Object Management Group http www omg org spec SBVR 1 0 OMG 2010a Unified Modeling Language Superstructure version 2 3 Object Management Group http www omg org spec UML 2 3 OMG 2010b Object Constraint Language version 2 2 Object Management Group http www omg org spec OCL 2 2 PAGE B 2011 BOUML http boum free fr PASTOR O ABRAHAO S M FONS J J RAMON S 2001 An Object Oriented Approach to Automate Web Applications Development Proceedings of 2 International Conference on Electronic Commerce and Web Technologies LNCS v 2115 pp 16 28 PASTOR O 2004 Fitting the Pieces of the Web Engineering Puzzle Palestra convidada XVIII Simp sio Brasileiro de Engenharia de Software SBES 04 Brasilia B
284. pre ser tratada mesmo que esse tratamento leve conclus o de que a requisi o n o pode ser atendida aa flow actor action decision node principal system action system response alternativo system action t system response eRT Cn J Firma Case system action Figura 5 12 Transi es permitidas a partir de uma ActorAction com fluxo alternativo 5 3 5 3 A o do Sistema com Fluxo Alternativo A Figura 5 13 apresenta as transi es v lidas caso exista um fluxo alternativo DecisionNode associado a uma a o do sistema SystemAction Esta figura define que caso exista um fluxo alternativo associado uma a o do sistema este fluxo deve iniciar obrigatoriamente com outra a o do sistema SystemAction ou uma resposta do sistema SystemResponse Esse arranjo possibilita que o fluxo alternativo represente possibilidades alternativas de resposta do sistema ou de processamento da informa o em fun o do resultado obtido em determinada a o do sistema sa flow system action decision node system response EA syutem action PE TT U svstem responee Figura 5 13 Transi es permitidas a partir de uma SystemAction com fluxo alternativo 5 3 5 4 Resposta do Sistema com Fluxo Alternativo A Figura 5 14 apresenta as transi es v lidas caso exista um fluxo alternativo DecisionNode associado a uma resposta do sistema SystemResponse Esta figura define que se hou
285. prev a classifica o dos requisitos em conte do estrutural apresenta o adapta o e modelo do usu rio O processo de desenvolvimento de aplica es Web consiste em quatro passos 41 e An lise de requisitos constru o do modelo de casos de uso contendo todas as informa es relevantes para implementa o dos casos de uso que podem ser representados em linguagem natural ou diagramas de atividades e Projeto conceitual constru o do modelo conceitual contendo as abstra es relacionadas ao dom nio da aplica o e Projeto navegacional contendo inicialmente o modelo de espa o navegacional onde s o definidos quais conceitos podem ser visitados durante a navega o e posteriormente evoluindo para o modelo de estrutura navegacional onde s o definidas as estruturas de acesso s informa es menus pagina o e ndices e Projeto de apresenta o constru o do modelo de apresenta o contendo os componentes da interface respons veis pela intera o com o usu rio formul rios imagens bot es e todos os demais elementos gr ficos 3 2 3 7 WebML Web Modeling Language A WebML CERI et al 2000 uma linguagem de especifica o de alto n vel voltada para o desenvolvimento de aplica es Web que manipulam grandes quantidades de dados data intensive Web applications Faz parte do ciclo de vida proposto pela WebML uma fase de especifica o de requisitos onde s o definidos os casos de uso
286. ption gt Choice 3 lt no description gt 236 3 Global Test Data Matrix opcaol a2 boletol dadosPagamentol senhal errol vali finva sim nao nume venci vali data idescojuros jvalor fijvali valifinval 2 3 da lida ro in do do Invalid nto i invalijnal inv do da lida valido a Invalid dos alido o ITCO01 TPI Step 2 Step 3 Step 4 Step 6 Step 7 DD TC001 TP2 Step 2 Step 5 Step 6 Step 10 _ Step 12 Step 15 C001 TP3 Step 2 Step 5 Step 6 Step 10 Step 11 E Step 13 DD Step 16 E Step 18 Step 2 Step 5 Step 6 n Step 10 Step 11 Step 13 Step 16 Step 18 Step 2 Step 5 Step 6 Step 10 Step 11 Step 13 Step 16 Step 18 Step 2 237 Step 5 Step 6 Step 10 Step 11 Step 13 Step 16 Step 18 238 AP NDICE C Instrumentos do Estudo Experimental Este ap ndice apresenta os instrumentos utilizados nos estudos relatados nesta tese C 1 Question rio do 1 estud
287. ption gt 14 solicita a senha system response lt no description gt 15 fornece a senha actor action lt no description gt 16 informa que a senha inv lida e que encontra se bloqueada system lt no description gt response 1 2 3 Test Case Data Variations opcaol a2 dadosPagamento1 senhal errol valida invalid sim nao data i desco juros valor valido valida invalida 2 3 a nvalidinto in invali final i a valido dos nvalid o TC001 TP2 Step 2 Step 5 Step 6 Step 10 E Step 12 Step 15 232 1 3 Test Case TCO001_TP3 1 3 1 Test Case Path Pagar Boleto Bancario J solicita a fonte de recurso de onde sera seleciona uma das op es actor action informa que deve ser selecionada uma op o system response opcaol invalida solicita o n mero do boleto system response solicita que o cliente fa a a leitura eletr nica do boleto system response digita o numero do boleto actor action informa que o numero do boleto inv lido system response lt lt navigation rul informa que n o poss vel pagar um boleto de outro banco ap s o vencimento system response solicita os dados relativos ao pagamento system response informa que os dados do pagamento s o inv lidos system respons
288. que o n mero do boleto inv lido system response lt no description gt 10 solicita o n mero do boleto system response lt no description gt 11 digita o numero do boleto actor action lt no description gt 12 solicita os dados relativos ao pagamento system response lt no description gt 13 informa os dados do pagamento actor action lt no description gt 14 finforma que os dados do pagamento s o inv lidos system response _ lt no description gt 15 solicita os dados relativos ao pagamento system response lt no description gt 16 jinforma os dados do pagamento actor action lt no description gt 17 solicita a senha system response lt no description gt 18 fornece a senha actor action lt no description gt 19 japresenta o comprovante de pagamento do boleto system response lt no description gt 1 3 3 Test Case Data Variations opcaol a2 boletol dadosPagamentol senhal errol vali inva sim nao numelvencilvalididata_ desc juros valor fijvalidojvalidalinvali 2 3 da lida ro in do o linval onto invajnal inv da valid ida invallidos alido o lido C001 TP3 Step 2 Step 5 Step 6 Step 10 Step 11 Step 13 Step 16 Step 18 Step 6 Step 10 Step 11 Step 13 Step 16 Step 18 234 Step 2
289. quer documenta o adicional solicita o de licen a pode assumir os estados em avalia o aprovada ou reprovada Regras estruturais R1 Um professor est vinculado a somente um departamento R2 Um departamento tem somente um coordenador R3 necess rio que um coordenador seja sempre um professor R4 imposs vel que um departamento tenha um coordenador que n o seja um professor vinculado ao pr prio departamento R5 poss vel que um departamento ofere a v rias disciplinas R6 Uma solicita o de licen a deve estar associada a 74 somente um estado Regras R7 proibido que um coordenador receba gratifica o se comportamentais estiver licenciado R8 proibido que um professor seja coordenador se ele lecionar mais de duas disciplinas R9 proibido que um professor solicite licen a para outro professor R10 obrigat rio que o estado de uma licen a seja em avalia o quando o professor solicitar a licen a R11 obrigat rio que o estado da solicita o de uma licen a seja aprovada quando a documenta o adicional estiver de acordo com o conjunto de normas para concess o de licen a R12 obrigat rio que o estado de uma licen a seja reprovada quando a documenta o adicional n o estiver de acordo com o conjunto de normas para concess o de licen a As regras R1 a R6 da Tabela 4 6 est
290. r m o grau de import ncia atribu do pelos participantes foi bem menor se comparado com o modelo de classes Tabela 2 9 Esse fato surpreende at certo ponto pois essas duas perspectivas s o totalmente complementares e fazem parte da ess ncia do paradigma OO Esse fato pode ser explicado pela falta de experi ncia e ou treinamento estudo insuficiente Tabela 2 10 o que pode fazer com que os desenvolvedores tendam a tratar as quest es comportamentais prioritariamente atrav s da codifica o usando uma linguagem de programa o Seguindo esse racioc nio a modelagem da estrutura seria importante e essencial como ponto de partida apenas para o processo de codifica o Por outro lado essa tend ncia tamb m pode ser alimentada pelo alto grau de esfor o percebido na constru o desse modelo Tabela 2 8 o que poderia levar os desenvolvedores a abandon lo em fun o de outra atividade que atinge o mesmo objetivo mas cuja percep o de esfor o menor Diagrama de Atividades Analisando os trabalhos entregues pelas equipes verificamos que ora esse diagrama era citado como essencial ora como descart vel Talvez pela falta de um foco bem definido como ocorre com os diagramas de classe e sequ ncia a explora o desse diagrama tenha sido pequena e as percep es tenham sido t o dispersas Analisando o uso desse diagrama pelas quatro equipes mais bem colocadas constatamos que ele foi usado como representa o gr fica dos casos
291. r representa uma intera o do ator com o sistema na qual este faz uma requisi o ao sistema informando os dados necess rios e A o do Sistema Representa uma a o do sistema cujos resultados gerados n o s o diretamente observados pelo ator usada para explicitar o tratamento dado requisi o do ator Esta a o est normalmente associada a recupera o de informa es altera o do estado interno do sistema e gera o de resultados que ser o posteriormente apresentados e Resposta do sistema Representa uma a o do sistema cujos resultados s o direta ou indiretamente observados pelo ator Essa a o pode apresentar resultados gerados anteriormente ou solicitar outros dados ao ator Essa resposta pode usar uma interface HC um email um sinal que enviado a um sensor ou outros meios A descri o do Caso de Uso pode ser iniciada com qualquer uma dessas tr s a es e o seu t rmino deve ser obrigatoriamente com uma a o ou resposta do sistema De acordo com o tipo da a o que leva a um ponto de decis o esta pode ser interpretada de diversas formas 1 Uma decis o ap s uma a o do ator interpretada como uma decis o sobre as informa es fornecidas pelo ator ou seja o ator pode realizar uma escolha expl cita que leva a uma ou outra a o do sistema ou a natureza da 218 informa o fornecida pode levar a uma ou outra a o do sistema O estado SOS sistema tamb m pode influenciar
292. ra eles uma aplica o real 2 3 3 Projeto do Estudo Os quatorze participantes tiveram a liberdade de se organizarem livremente desde que formassem quatro equipes de desenvolvimento sendo duas com quatro participantes e outras duas com tr s participantes Al m disso o aparente desinteresse dos participantes do primeiro estudo no desenvolvimento dos diagramas de apresenta o fez com que os pesquisadores lan assem m o do uso de prot tipos como uma alternativa para a representa o das interfaces humano computador As atividades executadas durante o desenvolvimento e os artefatos gerados podem ser vistos na Tabela 3 3 Tabela 2 3 Atividades e artefatos do 2 estudo de observa o Atividade Artefatos gerados Especifica o de Casos de e Documento contendo a lista de requisitos a lista Uso de atores e a descri o dos casos de uso 18 Modelo conceitual e Modelo de Navega o Mapa de Atores Diagrama de Contexto Navegacional e Diagrama de Navega o Cria o do prot tipo e Prot tipos da interface dos Casos de Uso Modelagem das Perspectivas Neste segundo estudo diferentemente do primeiro utilizamos somente os diagramas da perspectiva de navega o previstos no m todo OOWS PASTOR et al 2001 Os diagramas relacionados perspectiva de apresenta o foram totalmente substitu dos por prot tipos da interface humano computador devido 1 as observa es feitas pelos part
293. ram acesso informa es te ricas sobre inspe o de software e a oportunidade de praticar inspe es utilizando diferentes t cnicas ad hoc t cnicas baseadas em checklist t cnicas baseadas em heur sticas e t cnicas de leitura baseadas em perspectivas Os oito participantes foram treinados nos mesmos t picos a saber 1 Treinamento sobre a categoriza o de defeitos a ser utilizada no contexto do estudo Treinamento sobre o diagrama de atividades da UML 2 e seus elementos Treinamento sobre o metamodelo UCModel suas defini es e restri es e Treinamento sobre a ferramenta BOUML mais especificamente sobre o editor de diagramas de atividades 174 Devido aus ncia de alguns participantes o treinamento foi ministrado em dois momentos o primeiro com cinco participantes e o segundo com os tr s restantes por m usando o mesmo material com o mesmo tempo de dura o e com os mesmos instrutores Acreditamos que o treinamento dos participantes em duas sess es separadas n o causou impacto no resultado final pois as inspe es ocorreram de forma individual e foi solicitado aos participantes que n o trocassem informa es entre eles sobre as inspe es que estavam sendo realizadas 7 3 8 Execu o Os participantes tiveram duas semanas para executar a inspe o ad hoc e ao final enviaram a planilha eletr nica com as discrep ncias encontradas e os tempos de inspe o em minutos por caso de uso
294. rasil PATERNO F MANCINI C MENICONI S 1997 ConcurTaskTrees a Diagrammatic Notation for Specifying Task Models INTERACT 97 Chapman amp Hall pp 362 369 PERONE V PAOLINI P 2003 An Approach for Designing Ubiquitous Web Applications A Case Study Proceedings of IASTED International Conference on Communications Internet and Information Technology CIIT 03 PORTER A A VOTTA L G BASILI V R 1995 Comparing detection methods for software requirements inspections a replicated experiment IEEE Transactions on Software Engineering v 21 n 6 pp 563 575 PRECIADO J C LINAJE M MOLARES CHAPARRO R SANCHEZ FIGUEROA F ZHANG G KROIB C KOCH N 2009 Proceedings of 8th International Conference on Web Engineering ICWE 08 pp 148 154 PRESSMAN R 2000 What a tangled Web we weave IEEE Software v 17 n 1 pp 18 21 197 PRESSMAN R 2000 Software Engineering A practitioner s approach McGraw Hill 5 edi o ISBN 978 0077096779 QURESHI A PERINI A 2009 Engineering adaptive requirements ICSE Workshop on Software Engineering for Adaptive and Self Managing Systems pp 126 131 RAMLER R KLAMMER C NATSCHLAGER T 2010 The usual suspects A case study on delivered defects per developer Proceedings of the 2010 ACM IEEE International Symposium on Empirical Software Engineering and Measurement ESEM 10 ROBERTSON S
295. rav s de linguagem natural irrestrita ou estruturada e nesse ltimo caso em que formato Nesse sentido diversos trabalhos prop em gabaritos para a representa o textual do caso de uso como por exemplo e Trabalhos que tratam de descri es gerais de casos de uso frente a outras t cnicas de Engenharia de Requisitos LEFFINGWELL e WIDRIG 2003 WIEGERS 2003 ROBERTSON e ROBERTSON 2006 e Trabalhos que prop em m todos de desenvolvimento de software que empregam casos de uso JACOBSON et al 1999 LARMAN 2003 ARLOW e NEUSTADT 2005 BOOCH et al 2007 ROSENBERG e STEPHENS 2007 e Trabalhos que detalham a t cnicas de caso de uso COCKBURN 2000 ARMOUR e MILLER 2001 SCHNEIDER e WINTERS 2001 BITTNER e SPENCER 2002 KULAK e GUINEY 2003 ou e Trabalhos que prop em metamodelos de casos de uso NAKATANI et al 2001 DURAN et al 2004 SOME 2006 SOME 2008 GUTIERREZ 2009 Esses gabaritos visam definir um conjunto de elementos mandat rios ou n o a partir dos quais os casos de uso devem ser descritos e a escolha desses elementos influenciada pelo m todo empregado ou pelo ponto de vista que se deseja representar Apesar da grande variedade de gabaritos propostos na literatura t cnica poss vel observar algumas similaridades com rela o aos elementos propostos embora os nomes definidos para esses elementos difiram em muitos casos Por exemplo o conjunto de a es que formam o comportamento do caso de uso p
296. rece ainda um foco de leitura para os casos de uso baseado na defini o dos componentes do gabarito possibilitando que os membros da equipe e demais interessados no projeto tenham um entendimento comum sobre esses artefatos COCKBURN 2000 ARMOUR e MILLER 2001 Por outro lado a natureza livre das descri es textuais dos elementos que comp em o caso de uso limita sua utiliza o comunica o entre os stakeholders Apesar dessa comunica o ser relevante para o sucesso de projetos de software o fr gil apoio sem ntico proporcionado pelas descri es textuais n o permite a organiza o de uma infra estrutura computacional capaz de WILLIAMS et al 2005 e Oferecer apoio adequado especifica o dos casos de uso principalmente dos comportamentos que o comp em fluxos principal alternativos e de exce o e Apoiar um procedimento semi automatizado de avalia o da qualidade dos casos de uso e e Viabilizar transforma es modelo modelo ou modelo texto a partir das especifica es dos casos de uso com o objetivo de apoiar as fases subsequentes do desenvolvimento 93 Nesse sentido neste cap tulo apresentado um metamodelo denominado UCModel cujo objetivo permitir a organiza o das especifica es de casos de uso segundo um conjunto de crit rios e restri es bem definido e oferecer uma estrutura sint tica e sem ntica a partir da qual seja poss vel e Avaliar as especifica es dos casos de uso
297. rem outras a es ap s o mesmo e Se um fluxo alternativo exce o disparado por uma a o do ator ent o sua primeira a o tem que ser uma a o do sistema e Se um fluxo alternativo disparado por uma a o do sistema ent o sua primeira a o tem que ser uma resposta do sistema e Se um fluxo de exce o disparado por uma a o do sistema ent o sua primeira a o tem que ser uma resposta do sistema ou outra a o do sistema e Se um fluxo alternativo exce o disparado por uma resposta do sistema ent o sua primeira a o tem que ser uma resposta do sistema ou a o do sistema Esses 4 ltimos erros indicam que h um problema entre a a o que dispara o fluxo alternativo exce o e a primeira a o desses fluxo As combina es nesse caso tamb m devem seguir o metamodelo do UCModel e Um goto n o pode ter fluxos alternativos ou de exce o Como um goto representa um desvio incondicional n o faz sentido existirem alternativas ou exce es para o mesmo e Um goto ap s uma a o do ator deve ter como destino uma a o do sistema e Um goto ap s uma a o do sistema deve ter como destino outra a o do sistema ou uma resposta do sistema e Um goto ap s uma resposta do sistema deve ter como destino outra resposta do sistema ou uma a o do ator 226 Esses 3 ltimos erros indicam que h um problema entre a ltima a o de fluxo alternativo exce o e a a o destino de um got
298. resenta o detalhamento da an lise e projeto e a cria o dos testes Para a an lise e projeto s o utilizados 1 storyboards que definem a intera o da aplica o com o usu rio 2 modelo navegacional e modelo de componentes 3 prototipa o da interface e 4 valida o dos storyboards e prot tipos pelo cliente Tanto o modelo navegacional quanto o modelo de componentes tratam elementos diretamente ligados tecnologia utilizada no desenvolvimento ou seja o modelo navegacional define as p ginas e os links entre elas enquanto o modelo de componentes representa a troca de mensagens entre as classe de implementa o diagrama de sequ ncia Por fim como afirmam os pr prios autores o AWDP um m todo voltado para desenvolvimento e manuten o de sistemas de pequeno porte 3 2 3 14 OOWS Object Oriented Web Solution O m todo OOWS PASTOR et al 2001 em sua vers o original n o previa atividades relacionadas ao tratamento dos requisitos A abordagem proposta por VALDERAS et al 2005 preenche essa lacuna usando a met fora de tarefas S o identificados os usu rios do sistema e uma s rie de tarefas que esses usu rios devem executar usando o sistema Posteriormente essas tarefas s o refinadas at a 11 Os autores n o definiram um nome para a metodologia por isso essa sigla foi usada nesta tese para referenci la 45 gera o de um grupo de tarefas elementares Uma tarefa elementar aquela composta
299. revis o sistem tica que pode servir de base para futuras investiga es sobre esse tema 8 3 Limita es As principais limita es identificadas nessa pesquisa se referem a e O uso da abordagem proposta nesta pesquisa tem sua viabilidade associada ao apoio das ferramentas UseCaseAgent e ModelT Como essas ferramentas foram desenvolvidas como plug ins de uma ferramenta gen rica para modelagem UML no caso a BOUML PAG S 2011 a sua evolu o fica limitada s caracter sticas implementadas na BOUML Al m disso mesmo sendo uma aplica o open source existe o risco de descontinua o da ferramenta BOUML por parte do seu autor e O pequeno n mero de participantes no primeiro estudo de avalia o apresentado no Cap tulo 7 n o permitiu obter ind cios mais fortes da viabilidade da abordagem e do apoio computacional que a comp e N o foi poss vel obter respostas para as quest es quantitativas relacionadas a custo ou esfor o de uso dessa abordagem em compara o a outras existentes Avalia es adicionais s o necess rias visando fortalecer as indica es iniciais e e A obten o do modelo preliminar de testes a partir da especifica o dos casos de uso de forma autom tica nos deu indica es da viabilidade de explorar esse mecanismo para constru o do modelo de testes final Entretanto apenas a gera o dos modelos preliminares de teste foi realizada n o sendo avaliada a continua o das atividades visando
300. ria Cliente dever estar aut nticado no sistema de home banking Cliente obt m o comprovante de pagamento do boleto solicita a fonte de recurso de onde ser debitado o pagamento lt lt system response gt gt seleciona uma das op es lt lt actor action gt gt valida a op o selecionada lt lt system action gt gt Ne Q Ne lt lt conceptual_rule gt gt BR1 obrigat ria a sele o de uma e apenas uma fonte de recurso A2 Q lt lt navigation_rule gt gt NR3 obrigat rio que seja apresentado o valor do boleto contido no n mero do boleto se o n mero contiver o valor lt lt conceptual_rule gt gt BRS E obrigat rio que a data de pagamento seja maior ou igual a data corrente lt lt conceptual_rule gt gt BR6 E obrigat rio que o valor do desconto seja menor que o valor do boleto lt lt conceptual_rule gt gt BR7 E obrigat rio que o valor dos juros seja fornecido se a data de pagamento for menor que a data corrente lt lt conceptual rule gt BR8 Valor a ser pago valor do boleto desconto juros lt lt conceptual_rule gt gt BR9 obrigat rio que o valor a ser pago seja maor que zero informa que a senha inv lida lt lt system_response gt gt senha inv lida em menos de 3 tentativas valida o n mero do boleto lt lt system_action gt gt informa que o n mero do A3 X boleto inv lido n m
301. rir uma a o na posi o selecionada e Deletar uma a o e Mover a a o selecionada para cima ou para baixo e Incluir ou excluir alternativas e exce es e e Associar regras a um determinado passo Cada a o pode ser de um dos seguintes tipos 1 A o do ator representa uma a o do ator que normalmente fornece ao sistema alguma informa o solicitada 2 A o do Sistema representa uma a o do sistema que n o tem um resultado observ vel pelo ator normalmente usada para explicitar o tratamento da informa o fornecida pelo ator 3 Resposta do sistema representa uma a o do sistema que tem um resultado observ vel pelo ator chamada de resposta do sistema Essa resposta pode usar uma interface HC um email um sinal que enviado a um sensor ou qualquer outro meio atrav s do qual o sistema possa se comunicar com o mundo externo 4 Vai para representa um desvio na execu o e s pode ser criada para fluxos alternativos ou de exce o O destino de uma a o vai para pode 209 ser uma a o no mesmo fluxo ou qualquer a o nos fluxos da sua cadeia de ativa o 5 Encerrar encerra o caso de uso 6 Include 7 Extend representa a inclus o de outro caso de uso representa a extens o de outro caso de uso Para as a es do tipo 1 2 3 6 e 7 poss vel definir e Uma descri o para a a o e Um complemento para a descri o Exemplo A o Respos
302. rnar claro para o leitor do diagrama que este caminho pertence aquele fluxo Na Figura 5 9 os fluxos alternativos s o os fluxos de controle nomeados A1 e A2 e Fluxo de exce o sequ ncia de a es que interrompe a execu o de uma outra a o indicando que uma situa o extraordin ria ocorreu e deve ser tratada representada por um fluxo do tipo lt lt interrupt gt marcado pelo cone gt que sai diretamente da a o que gerou a exce o ou seja n o usa n de decis o na sua representa o Na Figura 5 9 o fluxo de exce o representado pelo fluxos de controle nomeados E1 Como cada fluxo representado de forma distinta e inequ voca no diagrama de atividades n o foi necess ria a defini o de estere tipos espec ficos para capturar esses elementos lt lt use case description gt gt id 4 summary Breve descri o do objetivo do caso de uso trigger express o de trigger actors nome dos atores criticality Alta frequencyofuse Alta UC004 Nome do caso de uso lt lt precondition gt gt express o de pr condi o lt lt postcondition gt gt express o de p s condi o a o A1 1 lt lt conceptual rule gt R1 regra de conceitua o lt lt navigation_rule gt gt R2 regra de navega o Figura 5 9 Padr o de representa o de um caso de uso e seus fluxos principal alternativos e de exce o usando diagrama de atividades da U
303. rnativos 26 20 1 5 26 10 28 2 1 31 6 30 3 2 35 27 42 4 4 50 16 43 5 6 54 40 51 9 7 67 36 72 3 7 82 35 72 3 7 82 17 98 5 5 108 15 92 8 19 119 165 132 45 M dia 2 x DP UC15 Alta UC17 103 54 M dia DP M dia Alta UC35 e UC36 74 63 M dia UCi6 M dia Baixa UC27 45 71 M dia DP UC06 UCi0 Baixa UC26 16 80 M dia 2 x DP Figura 7 2 Avalia o do nivel de complexidade dos casos de uso selecionados 7 2 3 Sele o de Vari veis Nesse estudo a vari vel independente representada pela ferramenta usada para especificar os casos de uso UCA EDA escala nominal enquanto a vari vel dependente o tempo gasto na especifica o de cada caso de uso escala raz o Assim esse estudo pode ser caracterizado como um fator ferramenta e dois tratamentos UCA e EDA 7 2 4 Participantes Dois desenvolvedores da equipe de projeto foram escolhidos por conveni ncia Esses desenvolvedores tinham conhecimento do dom nio do problema e estavam diretamente envolvidos com a especifica o funcional e as atividades de teste do m dulo financeiro O primeiro desenvolvedor tinha larga experi ncia na especifica o de casos de uso e conhecimento detalhado do m dulo financeiro enquanto o segundo por ter sido integrado ao projeto em per odo mais recente tinha pouca experi ncia nesses t picos 7 2 5 Projeto do Estudo Os dez casos de uso selecionado
304. romoted by contemporary Web development methods This approach explores web design perspectives concept navigation and presentation through the requirements specification A metamodel designed to guarantee the specification accuracy and to support the specification quality assurance activities makes part of it lts inception has been based on the results of a preliminary secondary study systematic review the conduction of a technical literature review based on systematic reviews concepts and three primary studies observational studies whilst its assessment has been conducted through two experimental studies feasibility studies The experimental studies have indicated that this approach contributes to the reduction of defects on Web application s use case specifications when compared to an ad hoc approach 1 NDICE VPRO o L jota To PRADO Sales sash ees eda Seles Op RR PR 1 1 1 Motiva o e Contexo e a RA crea cet eae i ee ered opta 1 1 2 Problema cce pras gs carve worden Renta dared gar Dene a e dei ae 5 1 3 Quest es d Pesquisa issues teas ieedssdctees ace bindesd tues dice teedeebeuoeade cktendeebetekae 6 1 4 ODICUIVOS so bewesh tice tape oia sad andor REE REE EEE EERE sand cade is head 7 1 5 Metodologia de Trabalho ep RS ds O eee aa 8 1 6 CPO ANIZAC AC Asas cera prestar a cio rca tati d e tan sd ecna ind ia ea atrai 10 Estudos Preliminares cuca Asa tapas Dan o Dna EaD vetted a ob pad US as dando 11 2 1 IMPOQUC Ae eee me O contr
305. s o permitidos fluxos alternativos exce o apenas com um desvio para outro ponto do Caso de Uso e Um fluxo alternativo exce o tem que ter uma condi o Um fluxo alternativo exce o deve sempre definir a condi o que o dispara e Uma a o do ator n o pode ter exce o Exce es s o condi es inesperadas que ocorrem durante uma a o ou resposta do sistema Assim n o s o permitidas exce es em a es relacionadas aos atores do caso de uso e Uma a o do ator n o pode ser a ltima a o de um fluxo A sem ntica de uma a o do ator indica que nessa a o o ator envia informa es para o sistema ou fornece as informa es solicitadas pelo mesmo Logo n o faz sentido que essa a o seja a ltima a o de um fluxo seja ele principal alternativo ou exce o pois n o h nenhuma a o posterior para processar a informa o enviada 225 e Uma a o do ator deve ser sucedida por uma a o do sistema goto include ou extend e Uma a o do sistema deve ser sucedida por outra a o do sistema uma resposta do sistema goto include ou extend e Uma resposta do sistema deve ser sucedida por uma a o do ator goto include ou extend Esses 3 ltimos erros informam que o sequenciamento das a es n o segue o padr o definido no metamodelo e Um goto tem que ser a ltima a o em um fluxo alternativo exce o Como um goto representa um desvio incondicional n o faz sentido existi
306. s a verifica o e permite a sele o do documento onde a especifica o ser gerada em formato RTF Somente os casos de uso que atenderem todas as restri es do metamodelo UCModel far o parte do documento de especifica o EF Use Case Agent vers o 0 39 Selecione os Casos de Uso 7 UCO01 Pagar boleto banc rio UCO02 Transfer ncia entre contas F UC003 Emitir extrato UC004 Autenticar usu rio 7 Ucoos Conduir compra Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 10 Tela da UseCaseAgent para sele o dos casos de uso que far o parte do documento de especifica o 145 j Use Case Agent vers o 0 39 Verifica o das Descri es dos Casos de Uso UCO01 n o cont m erros C004 cont m 2 erro s Edite o caso de uso e corrija os erros antes de imprimir o caso de uso lt lt Voltar j Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 11 Tela da UseCaseAgent para impress o das especifica es de casos de uso em formato RTF Finalmente a Figura 6 12 apresenta a especifica o do caso de uso Pagar boleto banc rio gerada pelo UseCaseAgent a partir do diagrama de atividades que especifica esse caso de uso UC001 Pagar boleto banc rio Objetivo Nesse caso de uso o cliente paga o boleto banc rio emitido pelo pr prio banco ou por terceiros Atores Client
307. s acerca dos casos de uso a ser capturado se refere aquelas organizadas no gabarito de casos de uso apresentado na Tabela 4 10 p gina 81 A partir da defini o do conjunto de informa es a ser capturado foram analisados quais elementos do metamodelo da UML seriam candidatos especializa o a fim de apoiarem a representa o dessas informa es Essa an lise n o foi realizada levando se em conta todos os elementos do metamodelo da UML mas somente aqueles usados na defini o dos diagramas de atividades A Figura 5 1 apresenta uma vis o parcial do metamodelo da UML 2 contendo esses elementos destacando em cinza as metaclasses concretas 96 Metamodelo da UML vis o parcial lt lt metaclass gt gt NamedElement lt lt metaclass gt gt incoming ActivityEdge lt lt metaclass gt gt InitialNode lt lt metaclass gt gt ControlNode o Zs lt lt metaclass gt gt ActivityFinalNode lt lt metaclass gt gt ActivityNode lt lt metaclass gt gt DecisionNode lt lt metaclass gt gt ExecutableNode as ZS lt lt metaclass gt gt Action lt lt metaclass gt gt Element IT TE constrainedElement lt lt metaclass gt gt Behavior a CC precondition postcondition lt lt metaclass gt gt Constraint Figura 5 1 Vis o parcial do metamodelo da UML 2 com os elementos do diagrama de atividades usados na defini o do metamodelo UCModel Ana
308. s contextos de atua o 75 Tabela 4 8 Exemplo de especifica o de regras de navega o segundo a SBVR 76 Tabela 4 9 Exemplo de especifica o de regras de apresenta o segundo a SBVR78 Tabela 4 10 Gabarito de caso de uso adotado na abordagem proposta 81 Tabela 5 1 Subconjunto de elementos do diagrama de atividades da UML explorados no contexto deste trabalho errei 95 Tabela 5 2 Mapeamento entre as informa es b sicas do caso de uso e os elementos do metamodelo UCModel errar ererrraereararaa 100 Tabela 5 3 Estere tipos usados na defini o do caso de uso e seus elementos B SICOS pap foi Cucina aa Ud dE Si pia a Ca E Pad tey 101 Tabela 5 4 Classifica o da regras de neg cio dom nio de acordo com as perspectivas de projeto WD a sessuinos rasta ces raiaias bora rabo na nele sav a Daiana ndanad wake aeeiesh 103 Tabela 5 5 Mapeamento entre as regras e os elementos do metamodelo UCModel ee ee ee ee ek eR A eer eae Sete oe eee eee 103 Tabela 5 6 Estere tipos usados na defini o de regras de neg cio dom nio 104 Tabela 5 7 Mapeamento entre os fluxos do caso de uso e os elementos do MetamoOgdelocWO MOGs cso RR MRS PR OURO IRADO PAR DANDO IR NIRO RR eiS epist 105 Tabela 5 8 Principais tipos de a es previstos pelo metamodelo UCModel 109 Tabela 5 9 Tipos de a es para estrutura o da descri o do caso de uso
309. s de regras definidas no metamodelo UCModel A classifica o dessas regras inspirada nas perspectivas de projeto Web tem o objetivo de oferecer um foco bem definido para tratamento dessas regras importante ressaltar que segundo o UCModel regras pertencem ao caso de uso mas devem estar sempre associadas s a es que afetam Essa localiza o importante porque delimita o escopo do impacto daquela regra no contexto do caso de uso 102 Tabela 5 4 Classifica o da regras de neg cio dom nio de acordo com as perspectivas de projeto Web Tipo de Regra Descri o Perspectiva Web ConceptualRule Restringe as a es do sistema definindo como esta deve ser realizada ou estabelecendo condi es para sua execu o Conceitua o NavigationRule Restri es sobre quais caminhos podem ser explorados e sobre quais informa es ser o apresentadas solicitadas ao ator Navega o PresentationRule Restri es sobre como as informa es ser o apresentadas solicitadas ao ator Apresenta o A Tabela 5 5 apresenta como as regras de neg cio dom nio e suas associa es s o capturadas no metamodelo UCModel A Figura 5 6 apresenta uma parte do metamodelo UCModel retirado da Figura 5 3 destacando as metaclasses utilizadas para capturar as regras associadas ao caso de uso Como elemento base para cria o das regras no metamodelo UCModel foi selecionada a metaclass
310. s foram separados em dois conjuntos com cinco casos de uso cada Esses conjuntos foram criados baseando se na complexidade dos casos de uso se o 7 2 2 de forma a equilibrar a complexidade 166 dos dois conjuntos A Tabela 7 2 apresenta os conjuntos A e B com os respectivos casos de uso e a complexidade de cada um Tabela 7 2 Conjuntos de casos de uso balanceados pelo n vel de complexidade Conjunto de Caso de uso Complexidade Complexidade m dia casos de uso do caso de uso do conjunto 26 Baixa 10 Baixa A 27 M dio Baixo 79 5 40 M dio Baixo M dia Alta 35 M dia Alta 15 Alta 26 Baixa 10 Baixa B 06 Baixa 69 75 16 M dio Baixo M dia Baixa 36 M dia Alta 17 Alta Os casos de uso 10 e 26 fizeram parte dos conjuntos A e B porque foram usados como exerc cio de aquecimento a fim de minimizar os efeitos do aprendizado da ferramenta de especifica o embora os desenvolvedores n o soubessem desse detalhe Ap s a defini o dos conjuntos A e B estes foram associados a cada um dos participantes P1 e P2 alternadamente de forma que cada participante especificasse casos de uso de ambos os conjuntos Esse arranjo entre os dois conjuntos e os dois participantes demandou que a execu o fosse realizada em duas rodadas conforme apresentado na Tabela 7 3 Tabela 7 3 Conjuntos de casos de uso atribu dos a cada participante por rodada Rodada
311. s m todos utilizam termos distintos em seus trabalhos optamos pelo uso deste termo para referenci los de forma coletiva e Pode ser observada uma clara evolu o dos m todos no sentido de incorporar atividades relacionadas engenharia de requisitos destacando o tratamento diferenciado dos requisitos relevantes no contexto do desenvolvimento das aplica es Web como navega o e apresenta o em rela o aos demais requisitos e Para os requisitos que n o envolvem navega o ou apresenta o os m todos analisados normalmente prop em o uso de t cnicas tradicionais como casos de uso ou linguagem natural sem nenhuma adapta o as particularidades das aplica es Web e N o foi poss vel identificar preocupa es em rela o estrutura o do documento de requisitos de forma que os diversos modelos produzidos possam ser acessados e analisados de forma integrada e Com rela o valida o dos requisitos poucos m todos prop em o uso de t cnicas de avalia o e quando o fazem se limitam t cnicas tradicionais como revis o walk through e prototipagem e e Os m todos de um modo geral n o tem demonstrado preocupa es em integrar os modelos de especifica o ao processo de garantia da qualidade do produto final 1 2 Problema O problema tratado nesta tese est relacionado especifica o dos requisitos funcionais das aplica es Web e seu desdobramento em termos de garantia da qualidade da aplica
312. s numerados que descreve o alternativos comportamento do sistema quando existe uma alternativa na execu o do caso de uso ou quando determinado estado ou condi o alcan ado Representa um caminho alternativo no 81 qual o ator pode ou n o atingir o seu objetivo Cada fluxo alternativo possui uma identifica o nica e deve estar associado uma condi o que define se este deve ou n o ser executado Fluxos de exce o Uma sequ ncia de passos numerados que descreve o comportamento do sistema quando algo inesperado ocorre Representa um caminho onde o ator normalmente n o atinge o seu objetivo Cada fluxo de exce o tamb m possui uma identifica o nica e deve estar associado a uma condi o que define se este deve ou n o ser executado Regras S o pol ticas procedimentos ou restri es que devem ser levadas em considera o durante a execu o do caso de uso Devem estar sempre associadas aos passos dos fluxos onde devem ser observadas Passos Representam a es a serem executadas no contexto do fluxo ao qual pertencem Cada passo a o pode estar associado a um ou mais fluxos alternativos de exce o ou regras A Figura 4 6 exemplifica o uso do gabarito proposto pela abordagem Esse exemplo apesar de simples ilustra o uso de todos os elementos existentes no gabarito Atrav s desse exemplo poss vel observar que 1 N o sao previstas estruturas de
313. s perspectivas de apresenta o ou navega o As alternativas disparadas por uma resposta do sistema devem fazer sentido no contexto desse tipo de a o Normalmente essas alternativas est o associadas a caminhos alternativos que o ator seleciona e As exce es associadas uma resposta do sistema devem representar situa es extraordin rias nesse contexto como por exemplo situa es onde h impossibilidade de apresentar essa resposta ao ator importante ressaltar que esses itens foram explorados na elabora o do checklist da t cnica ActCheck MELLO 2011 criada para inspe o de diagramas de 127 atividades e que pode ser customizada para inspecionar diagramas de atividades que descrevem casos de uso segundo o metamodelo UCModel 5 5 Exemplo de Caso de Uso especificado com o UCModel Essa se o apresenta um exemplo completo do caso de uso Autenticar usu rio descrito de acordo com o metamodelo UCModel A Figura 5 16 apresenta a especifica o desse caso de uso usando um diagrama de atividades que explora o perfil ProfileUCModel para definir a sem ntica dos v rios elementos que fazem parte da especifica o A Figura 5 17 apresenta a descri o textual desse mesmo caso de uso usando o gabarito organizado na se o 4 5 3 2 e apresentado na Tabela 4 10 p gina 81 importante frisar que em termos sem nticos as especifica es de caso de uso apresentadas no diagrama de atividades Figura 5 16
314. s relacionadas A o do sistema Use termos relacionados ao dom nio do problema perspectiva de conceitua o ou seja os mesmo termos explorados nos modelos conceituais Deixe expl cito atrav s do complemento da a o ou de regras os efeitos colaterais ou p s condi es da execu o da regra em rela o ao estado do sistema Referencia regras relacionadas perspectiva de conceitua o As alternativas disparadas por uma a o do sistema devem fazer sentido no contexto desse tipo de a o Normalmente essas alternativas est o associadas ao resultado da execu o da a o e ou estado do sistema As exce es associadas a o do sistema devem representar situa es extraordin rias nesse contexto como por exemplo situa es onde h impossibilidade de processar requisi o do ator e Caso exista uma estrutura de a es do sistema associadas alternativas que levam a outra a es do sistema verifique se o n vel de abstra o dessas a es compat vel com o caso de uso Caso n o seja refatore essa estrutura como um diagrama de atividades parte e substitua a na descri o do caso de uso por uma a o que indique do ponto de vista do ator a a o esperada do sistema Orienta es relacionadas Resposta do Sistema Indique objetivamente os resultados que o sistema ir retornar ao ator Use termos relacionados perspectiva de apresenta o ou navega o Referencia regras relacionadas
315. sitos utiliza uma abordagem padr o de identifica o de atores e casos de uso Os Casos de Uso s o ent o representados atrav s de Diagramas de Intera o do Usu rio UID que prov em uma representa o gr fica propriet ria da intera o ator x sistema e Modelo conceitual s o gerados a partir dos UIDs atrav s da aplica o de uma s rie de regras Utiliza a abordagem orientada a objetos classes associa es atributos generalizagao especializagao e agrega o para representa o dos conceitos relacionados ao dom nio da aplica o e Modelo navegacional descreve a vis o navegacional elaborada a partir do modelo conceitual Uma nota o pr pria usada para descrever primitivas de acesso e de navega o entre as classes e Modelo de interface abstrata define quais objetos da interface s o percept veis ao usu rio possibilitando a cria o de diferentes interfaces para o mesmo modelo navegacional O OOHDM utiliza a abordagem de vis o abstrata de dados para descrever a interface do usu rio de uma aplica o hiperm dia e e Implementa o consiste no mapeamento dos modelos de interface abstrata e do modelo navegacional em objetos concretos na plataforma de implementa o escolhida 3 2 3 6 UWE UML based Web Engineering O UWE HENNICKER e KOCH 2000 um processo de desenvolvimento para aplica es Web com foco na sistematiza o customiza o e gera o semi autom tica da aplica o O UWE
316. sos e procedimentos de testes pois algumas informa es relacionadas exclusivamente aos testes funcionais n o podem ser derivadas a partir da especifica o de casos de uso como por exemplo os valores ou categorias de valores a serem usados nos testes funcionais O metamodelo TDE est baseado em conceitos bastante semelhantes aos conceitos existentes no metamodelo UCModel As principais diferen as do metamodelo TDE em rela o ao metamodelo UCModel 1 Ele s possui a es do tipo ActorAction e SystemResponse ou seja ele n o modela a a o do sistema A explica o est no fato de que TDE modela o sistema como uma caixa preta e portanto s est interessado nas informa es que s o enviadas para o sistema a o do ator e a posterior resposta do mesmo resposta do sistema 2 Os n s de decis o s o modelados com apenas duas possibilidades de desvio A modelagem de m ltiplas possibilidades de desvio a partir de um nico ponto de decis o realizada encadeando se dois ou mais n s de decis o para cobrir todas as possibilidades existentes 3 S o usadas classes de equival ncia para definir os valores a serem usados nos testes funcionais o que n o tem contrapartida no modelo de casos de Uso 4 S o utilizadas express es booleanas com sintaxe estruturada nas condi es de guarda o que normalmente n o feito no modelo de casos de uso que usa express es em linguagem natural As diferen as 1 e 2 dessa
317. ssam contribuir para o julgamento da viabilidade da abordagem proposta nesta tese 182 8 Conclus o e Trabalhos Futuros Neste cap tulo as conclus es desta tese s o apresentadas resumindo sua motiva o e proposta e destacando suas contribui es Os trabalhos futuros indicam dire es que podem ser tomadas no sentido de dar continuidade pesquisa aqui apresentada 8 1 Considera es Finais H alguns anos as tecnologias Web eram vistas como meros coadjuvantes no cen rio de desenvolvimento de software e nas organiza es eram respons veis por aplica es cuja miss o tinha pouca interse o com os objetivos do neg cio Hoje esse cen rio mudou radicalmente e a demanda por aplica es Web complexas vem sendo acompanhada pela necessidade de abordagens capazes de garantir a qualidade de tais aplica es Esta tese tratou de quest es relacionadas especifica o dos requisitos funcionais das aplica es Web e seu desdobramento em termos de garantia da qualidade da aplica o Assim este trabalho definiu e avaliou uma abordagem para especifica o de requisitos funcionais de aplica es Web alinhada aos conceitos explorados pelos m todos Web contempor neos e estruturada visando prover um arcabou o para a garantia da qualidade da especifica o e do produto final A experimenta o explorada atrav s de uma metodologia baseada em evid ncias apoiou as atividades de pesquisa no escopo desta tese desde a concep
318. sse ponto atente para os seguintes crit rios ao pagamento para gerar as classes de equival ncia lt lt system_response gt gt dados de pagamento invalidos Corrija as express es associadas com as decis es de forma que elas reflitam os dados lt lt equivalence_class gt gt definidos nas classes de equival ncia informa os dados do dadosPagamento1 pagamento DadosPagamento1 lt lt actor action gt gt informa que n o poss vel pagar um boleto de outro banco ap s o vencimento lt lt system_response gt gt a A lt lt navigation_rule gt gt NR3 E dadosPagamento1 data invalida or obrigat rio que seja apresentado dadosPagamento1 desconto invalido or o valor do boleto contido no N dadosPagamento1 juros invalidos or n mero do boleto se o n mero dadosPagamento1 valor final invalido informa que os dados do contiver o valor pagamento s o inv lidos lt lt system response gt gt E A lt lt navigation_rule gt gt NR10 E obrigat rio que o sistema apresente uma mensagem de erro para cada dado que esteja incorreto lt lt equivalence class gt gt errot Erro1 lt lt equivalence_class gt gt senhat informa que a senha Senha1 p di inv lida lt lt system_response gt gt As senha1 invalida and senha1 invalida and 6 erro1 3 erro1 3 lt lt conceptual_rule gt gt BR11 obrigat rio que a senha i PPA fornecida seja id ntica a senha do cart o c
319. stas dos participantes foram analisadas de acordo com as codifica es aberta e axial propostas por STRAUSS e CORBIN 1998 para o m todo Grounded Theory Como a pergunta formulada era bastante espec fica o processo de codifica o categoriza o procurou interpretar as respostas em busca dos fatores facilitadores propostos pelos participantes Um resumo dos c digos e categorias obtidos nessa an lise ser apresentado na pr xima se o A pr xima se o apresenta uma an lise sobre o uso de modelos em um cen rio de desenvolvimento Web luz dos resultados obtidos nos tr s estudos de observa o realizados 2 5 An lise dos Resultados dos Estudos Os dados obtidos com os estudos nos deixam estabelecer algumas indica es sem permitir contudo nenhuma afirma o ou conclus o acerca do uso dos modelos no contexto de desenvolvimento Web Para facilitar essa an lise vamos tratar os dados quantitativos para cada um dos modelos separadamente e em seguida analisar os dados qualitativos de uma forma geral importante destacar que a an lise a seguir foi influenciada na maior parte dos casos pelos dados do terceiro estudo de observa o Entretanto os dados obtidos no primeiro e segundo estudos refor am em v rios momentos os resultados obtidos no terceiro se observados isoladamente 2 5 1 An lise dos Resultados Quantitativos Diagrama de Classes Esse modelo foi o mais manipulado pelas diversas equipes nos tr s estudos
320. straint Indica que a restri o uma regra associada perspectiva de conceitua o lt lt navigation rule gt gt Constraint Indica que a restri o uma regra associada perspectiva de navega o lt lt presentation rule gt gt Constraint Indica que a restri o uma regra associada perspectiva de apresenta o A Figura 5 7 apresenta um exemplo de um diagrama de atividades com um caso de uso e as regras de neg cio dom nio definidas para o mesmo Como as regras no metamodelo UCModel s o criadas a partir do conceito de Constraint da UML estas s o representadas usando coment rios no diagrama de atividades Cada coment rio contendo uma ou mais regras est associado a o na qual esta s regra s impacta m Cada regra possui um identificador nico dentro do caso de uso e classificada com um nico tipo 104 lt lt use case description gt gt id 3 summary Breve descri o do objetivo do caso de uso trigger express o de trigger actors nome do ator criticality baixa frequencyofuse m dia UC003 Nome do caso de uso lt lt precondition gt gt express o de pr condi o lt lt postcondition gt gt express o de p s condi o lt lt conceptual_rule gt gt R2 regra conceitual lt lt presentation_rule gt gt R3 regra de apresenta o lt lt navigation rule gt gt R1 regra de navega o Figura 5 7 Padr o de representa o de um
321. t gt apresenta o comprovante de pagamento do boleto lt lt system_response gt gt Figura 6 9 Diagrama de atividades com a especifica o do caso de uso Pagar boleto banc rio 144 6 2 1 4 Edi o do Caso de Uso Uma vez criado o diagrama de atividades relativo especifica o do caso de uso conforme exemplo da Figura 6 9 poss vel edit lo diretamente atrav s da ferramenta BOUML ou seja incluir excluir ou alterar elementos do diagrama ou edita lo com a UseCaseAgent Na segunda op o as telas apresentadas anteriormente para cria o da especifica o do caso de uso Figura 6 3 Figura 6 8 s o as mesmas usadas na edi o dessa especifica o 6 2 1 5 Gera o da Especifica o em Formato texto Ap s a especifica o de um ou mais casos de uso usando a ferramenta UseCaseAgent poss vel gerar um documento de especifica o em formato RTF contendo um ou mais casos de uso Para obter essa especifica o basta selecionar o pacote raiz estereotipado lt lt uc model gt gt e em seguida selecionar a op o Tools gt Print Use Case Em seguida ser apresentada a tela da Figura 6 11 onde o desenvolvedor poder selecionar quais casos de uso far o parte do documento de especifica o Ao clicar em verificar os casos de uso selecionados ser o verificados quanto sua ader ncia ao metamodelo UCModel A tela apresentada na Figura 6 11 mostra a situa o de cada caso de uso ap
322. t lt use case description gt gt e seus tagged values No diagrama tanto o estere tipo quanto as tagged values s o representados como um coment rio associado atividade Todas as a es do diagrama s o estereotipadas para indicar o seu tipo lt lt actor action gt gt lt lt system action gt gt ou lt lt system response gt gt Os pontos de ativa o dos fluxos alternativos s o marcados pelos n s de decis o do diagrama O ponto de ativa o do fluxo de exce o marcado pelo fluxo de interrup o partindo direto da a o onde essa exce o gerada estere tipo lt lt interrupt gt gt tamb m representado pelo cone gt As condi es que restringem a execu o dos fluxos alternativos e de exce o s o definidas como condi es de guarda associadas ao in cio desses fluxos 130 6 As sequ ncias de a es que comp em os fluxos alternativos e de exce o s o etiquetadas com os identificadores dos fluxos 7 As regras s o representadas como Constraints e est o estereotipadas classificadas de acordo com o seu tipo e 8 As regras est o sempre associadas s a es que restringem No diagrama de atividades da Figura 5 16 poss vel tamb m observar a ader ncia desse modelo s restri es estabelecidas no escopo do metamodelo UCModel A Tabela 5 13 lista as regras aplicadas ao exemplo da Figura 5 16 destacando os itens do diagrama onde a ader ncia regra pode ser observada T
323. ta o desses modelos SCHWINGER e KOCH 2006 Adicionalmente esses modelos evoluem durante o processo de desenvolvimento e ap iam a gera o de outros artefatos ao longo do ciclo de vida do sistema caracterizando um cen rio de Desenvolvimento Dirigido por Modelos FRANCE e RUMPE 2007 Perspectivas de ae Apresenta o o Navega o i I i Conceitua o Fases do processo Estrutural 4 Especifica o Projeto Projeto 1 f L gico F sico Comportamental 4 Vis es da modelagem Figura 4 1 Perspectivas de projeto x caracter sticas dos modelos x fases de desenvolvimento adaptada de SCHWINGER e KOCH 2006 SCHWINGER e KOCH 2006 sugerem que tanto as perspectivas de projeto Web quanto as vis es de modelagem sejam exploradas desde as fases iniciais do desenvolvimento poss vel incluir os requisitos funcionais nessa vis o buscando garantir consist ncia entre o tratamento dado aos requisitos e os diversos artefatos propostos pelos m todos Web gerados ao longo do processo de desenvolvimento 59 Nas se es 4 2 1 4 2 2 e 4 2 3 a seguir ser o apresentadas as defini es das perspectivas de projeto Web e os artefatos definidos para representa o da vis o estrutural e comportamental em cada uma dessas perspectiva segundo a abordagem proposta nesta pesquisa Cada um desses artefatos e as informa es que estes se prop em a representar ser o detalhados ao longo da se o 4 5 4 2 1 Perspectiv
324. ta do sistema Descri o Apresenta o formul rio de cadastramento Complemento O formul rio deve possuir os seguintes campos nome endere o email S Use Case Agent vers o 0 3 ad f Ferre e TT O M e Arquivo Verificar EDAG j UCModel Atores EI Casos de Uso UCo01 Autentica o do usu rio 4 Atores do Caso de Uso e Geo 5 Fluxos Alternativos Fluxos de Exce o f Regras Erros E Fluxo Principal Ordem Descri o Alternativas Exce es 1 Sistema apresenta o formulario de autentica o Regras linternauta fornece login e senha 2 3 Sistema valida login e senha 4 Sistema apresenta o menu principal de acordo com o perfil do usu rio A es Alternativas Exce es Regras System Response apresenta o formulario de autentica o 0 formul rio de autentica o deve possuir os seguintes componentes login senha op o de esqueci a senha Acrescentar Inserir Deletar Para cma Para baixo Grupo de Engenharia de Software Experimental COPPE UFRJ Figura A 8 Tela do UseCaseAgent mostrando a associa o de uma a o com um sub diagrama de atividades A tela apresentada na Figura A 8 destacada em vermelho a op o usada para criar associar um sub diagrama de atividades uma a o O objetivo especificar o comportamento da a o ou resposta do sistema usando um o
325. tada por GREGOLIN e DEBONI 2008 Essa t cnica foi definida a partir de um modelo de qualidade com atributos de qualidade e regras para elabora o de diagramas e descri es de casos de uso A partir desse modelo foram produzidos checklists para inspe o dos diagramas de caso de uso e das descri es de casos de uso Uma das caracter sticas dessa t cnica que as quest es do checklist para inspe o das descri es de casos de uso est o alinhadas com o gabarito adotado neste trabalho permitindo o uso da t cnica sem nenhuma customiza o adicional Al m disso essa t cnica foi experimentalmente avaliada no contexto do SiGIC SANTOS e TRAVASSOS 2010 cuja especifica o foi desenvolvida pelo grupo de Engenharia de Software Experimental da COPPE UFRJ usando o gabarito de casos de uso aqui definido e adotado Com rela o quest o 2 a t cnica de inspe o ActCheck MELLO et al 2010 foi desenvolvida para inspe o de diagramas de atividades no contexto da especifica o de requisitos Um diferencial dessa t cnica que ela possui dentre as quest es formuladas no checklist um grupo de quest es especialmente projetadas para detectar defeitos relacionados especifica o de casos de uso constru das a partir do metamodelo UCModel Essas quest es foram elaboradas com base em um conjunto de orienta es para descri o dos casos de uso que foram definidas no escopo deste trabalho a partir da sem ntica dos elementos do
326. tamentos sist micos podem ser negligenciados A gera o semi autom tica de outros artefatos a partir do modelo de requisitos funcional como por exemplo modelos de projeto estruturais ou comportamentais casos de teste ou procedimentos de teste pode se tornar incompleto e O conhecimento t cito do dom nio pode influenciar na qualidade da especifica o 7 4 Amea as Validade dos Estudos As principais amea as relacionadas validade dos dois estudos realizados s o listadas a seguir Medi o do tempo de especifica o e inspe o foi solicitado aos participantes que fossem o mais preciso poss vel com rela o medi o do tempo gasto nas tarefas de especifica o primeiro estudo e inspe o segundo estudo Entretanto n o h garantia quanto exatid o do tempo reportado pelos participantes 179 e Efeitos colaterais do treinamento a mitiga o desse risco foi feita ministrando treinamentos equivalentes com os mesmos exemplos e os mesmos instrutores A influ ncia da experi ncia do instrutor foi mitigada atrav s da organiza o do material de treinamento que procurou definir o que deveria ser apresentado tanto em termos te ricos como nos exemplos para minimizar poss veis desvios desses t picos e Aprendizado das ferramentas os desenvolvedores que participaram do estudo est o habituados no cotidiano do projeto a trabalhar com ferramentas para modelagem Entretanto esses desenvolvedores n
327. tas aplica es convencionais podem demandar um alto grau de aten o em uma ou mais dessas caracter sticas assim como outras caracter sticas n o citadas podem se tornar relevantes no contexto espec fico de uma determinada aplica o O aumento da complexidade das aplica es Web aliada s caracter sticas pr prias dessas aplica es levou necessidade do uso de boas pr ticas no desenvolvimento de aplica es Web para que estas pudessem ser entregues dentro do prazo e or amento planejados e com alto grau de qualidade e facilidade de manuten o Esses requisitos motivaram o surgimento da Engenharia de Aplica es Web Web Engineering com o objetivo de aplicar os princ pios da engenharia no desenvolvimento de aplica es Web de qualidade PRESSMAN 2000a onde a estrutura funcionalidade navega o e intera o com o usu rio sejam representadas de forma adequada PASTOR 2004 A Engenharia de Aplica es Web pode ser definida como o uso de princ pios cient ficos da engenharia e de gest o e de abordagens sistem ticas com o prop sito de desenvolver implantar e manter de maneira bem sucedida aplica es Web de alta qualidade MENDES et al 2005 No contexto da Engenharia de Aplica es Web v rios m todos t m sido propostos com o objetivo de apoiar de forma sistem tica o desenvolvimento de aplica es Web Uma revis o quasi sistem tica TRAVASSOS et al 2008 conduzida por CONTE et al 2005 com o
328. tas usadas durante os estudos podem trazer algum tipo de dificuldade na constru o dos modelos solicitados Entretanto como as tarefas realizadas n o eram pontuais nem individuais e n o requeriam medi o de tempo ou esfor o as eventuais dificuldades podem ser desconsideradas 2 7 Conclus o Os estudos realizados foram teis na medida em que juntamente com os trabalhos de ESCALONA e KOCH 2004 CONTE et al 2005 ESCALONA et al 2007 e ESCALONA e 2008 permitiram elaborar a vers o inicial da abordagem e observar na pr tica algumas quest es importantes No que diz respeito s atividades de modelagem em projetos de software de uma forma geral as dificuldades apontadas em ambos os estudos refor am a id ia de que modelagem de software n o uma atividade trivial Apesar dos participantes dos estudos serem alunos de gradua o e por isso existir o argumento da inexperi ncia dos desenvolvedores fato que as aplica es desenvolvidas n o tinham alta complexidade Esse cen rio indica que no contexto do desenvolvimento de aplica es Web que tem procurado explorar intensamente o uso de modelos deve haver uma preocupa o concreta com rela o ao apoio ferramental e ao treinamento dos desenvolvedores na abordagem a ser utilizada A mudan a de paradigma e de foco proposta pela maioria dos m todos de desenvolvimento Web orienta o a modelos traz mudan as significativas ao estado da pr tica tradicionalmente focad
329. temResponse usando um outro diagrama de atividades Esse segundo diagrama de atividades n o dever ser criado usando os mesmos conceitos do metamodelo UCModel j que ele dever conter somente a es que 112 dizem respeito ao comportamento do sistema Esse expediente pode ser usado para detalhar e formalizar um procedimento do sistema descrito como uma a o at mica no n vel do caso de uso ou regras de neg cio dom nio que devem ser observadas durante determinada a o ou resposta do sistema ao inv s de explorar a descri o dessas regras em linguagem natural Complemento da a o destaque 8 O atributo complement que parte integrante das a es ActorAction SystemAction SystemResponse IncludeUCAction e ExtendUCAction foi definido para que o desenvolvedor forne a informa es complementares sobre a a o permitindo que a descri o da mesma seja curta e objetiva Esse recurso ser explorado na se o 5 4 de orienta es para descri o das a es Representa o no Diagrama de Atividades Para representar as a es do metamodelo UCModel no diagrama de atividades foram definidos os estere tipos da Tabela 5 12 N o h necessidade de definir estere tipos para as a es GotoAction e FinishAction porque estas s o traduzidas para o diagrama atrav s de fluxos de controle que desviam para uma determinada a o GotoAction ou para o n final FinishAction Tabela 5 12 Estere tipos usados n
330. tenha um conjunto m nimo de informa es que Permita a descri o do conjunto de informa es geradas pela abordagem de especifica o proposta e Forme um conjunto coeso de informa es acerca da especifica o de requisitos O conjunto m nimo adotado representa tamb m um subconjunto dos conceitos definidos tanto no padr o IEEE 830 1998 IEEE 1998 quanto no gabarito de especifica o Volere ROBERTSON e ROBERTSON 2010 Assim a organiza o adotada para o documento de requisitos possui as seguintes se es Prop sito do projeto uma breve descri o da organiza o onde o projeto est inserido da motiva o que gerou a demanda pelo projeto e dos objetivos do projeto Gloss rio defini o de termos acr nimos e abrevia es usadas na especifica o dos requisitos Requisitos funcionais especifica o de cada requisito funcional do usu rio Requisitos n o funcionais especifica o de cada requisito n o funcional categorizados segundo a ISO IEC 9126 1 2001 ISO 2001 Modelos conceituais modelos criados para representar as diversas caracter sticas dos conceitos relacionados ao dom nio do problema Modelo de casos de uso modelos criados para capturar o comportamento esperado do sistema atrav s de casos de uso com a representa o e detalhamento desses comportamentos atrav s de diagramas de atividades 67 x Certamente outras se es poder o ser acrescentadas estrutura desse document
331. ter sticas e recursos dispon veis e uma ferramenta open source e Executavel em v rias plataformas Windows MacOS X distribui es Linux e Implementa a especifica o da UML 2 e Trabalha com perfis UML e e extens vel atrav s de plug ins escritos em C ou Java A ferramenta UseCaseAgent pode ser classificada como um editor orientado a formul rios e foi implementada na linguagem Java como um plug in para a ferramenta BOUML A arquitetura oferecida pela BOUML permite que seus plug ins leiam criem alterem ou excluam modelos ou elementos associados a esses modelos programaticamente Dessa forma a UseCaseAgent capaz de manipular os diagramas de atividades da BOUML criando ou editando esses diagramas segundo o metamodelo UCModel e suas restri es Para que as especifica es de casos de uso criadas com a UseCaseAgent pudessem ser disponibilizadas na BOUML como diagramas de atividades foi organizada uma estrutura de pacotes para armazenamento dessas informa es atores casos de uso e diagramas de atividades com as especifica es dos casos de uso A Figura 6 2 apresenta a tela principal da ferramenta BOUML destacando os pacotes que organizam os atores casos de uso e diagramas de atividades 138 Project Windows Tools Languages Miscellaneous Help seHaHuo WR EE ProjetoExemplo E Je lt ue modeb gt modelo de casos de uso E Je lt actors gt gt atores
332. ticas relativas aos aspectos visuais e diagrama o da interface com o usu rio Ou seja essa perspectiva define como as informa es acess veis pelos usu rios ser o efetivamente apresentadas e as varia es relacionadas a essa apresenta o Assim da mesma forma que a perspectiva de conceitua o ap ia a defini o da perspectiva de navega o esta ap ia a defini o da perspectiva de apresenta o A Tabela 4 3 lista os artefatos definidos para representar a estrutura e o comportamento relacionados perspectiva de apresenta o Tabela 4 3 Artefatos para representa o dos requisitos na perspectiva de apresenta o Estrutural 1 Prot tipos da interface Comportamental 2 Regras em linguagem natural estruturada associadas descri o do caso de uso 3 Regras em linguagem natural estruturada associadas ao prot tipo 4 2 4 Linguagem de Modelagem Com rela o aos modelos adotados na fase de especifica o a UML OMG 2010a foi escolhida como linguagem para modelagem desses artefatos Essa escolha se deve a um conjunto de fatores e um padr o de fato na ind stria de software e Oferece uma variedade de modelos para capturar aspectos estruturais e comportamentais 61 Possui mecanismos de extens o perfis UML e metamodelagem que permitem a defini o e explora o de novos elementos n o concebidos originalmente na linguagem N o imp e nenhum m todo ou processo de
333. tion gt NID Nn BY GW digita o numero do boleto actor action lt no description gt 229 8 informa que n o poss vel pagar um boleto de outro banco ap s o vencimento system response lt no description gt 1 1 3 Test Case Data Variations opcaol a2 boletol valida invalida sim nao numero invalido vencido valido TCO001 TPI Step 2 Step 3 Step 4 Step 6 Step 7 230 1 2 Test Case TC001 TP2 1 2 1 Test Case Path Pagar Boleto Bancario solicita a fonte de recurso de onde ser seleciona uma das op es actor action informa que deve ser selecionada uma op o system response solicita o n mero do boleto system response solicita que o cliente fa a a leitura eletr nica do boleto system response informa que o n mero do boleto inv lido system response informa que n o poss vel pagar um boleto de outro banco ap s o vencimento system response solicita os dados relativos ao pagamento system response informa os dados do pagamento actor action dadosPagament solicita a senha informa que a senha inv lida system lt lt business_rule gt Bs item a response fornece a senha actor action informa que a senha encontra se bloqueada system response
334. tive Study Journal of Web Engineering v 2 n 3 pp 193 212 ESCALONA M J KOCH N 2006 Metamodeling the Requirements of Web Systems Proceedings of 2 International Conference on Web Information Systems WEBIST 06 pp 310 317 ESCALONA M J TORRES J MEJ AS M GUTI RREZ J J VILLADIEGO D 2007 The Treatment of Navigation in Web Engineering Advances in Engineering Software v 38 n 4 pp 267 282 ESCALONA M J ARAG N G 2008 NDT A Model driven Approach for Web Requirements IEEE Transactions on Software Engineering v 34 n 3 pp 377 394 FAGAN M E 1976 Design and Code Inspection to Reduce Errors in Program Development IBM Systems Journal v 15 n 3 pp 182 211 FRANCE B RUMPE R 2007 Model driven Development of Complex Software A Research Roadmap Proceeding of Future of Software Engineering FOSE pp 37 54 FREIRE A P GOULARTE R FORTES R P M 2007 Techniques for Developing More Accessible Web Applications A Survey Towards a Process Classification Proceedings of 25 ACM International Conference on Design of Communication SIGDOC 07 GARRIGOS I MAZON J N TRUJILLO J 2009 A requirement analysis approach for using i in web engineering LNCS v 5648 pp 151 165 GARZOTTO F PAOLINI P SCHWABE D 1993 HDM A Model based Approach to Hypertext Application Design ACM Transactions on Inf
335. to de vista do pesquisador no contexto de desenvolvimento de diferentes tipos de aplica es Web por alunos de gradua o em Ci ncia da Computa o e Engenharia de Computa o e Informa o da UFRJ 2 2 2 Contexto O foco do trabalho foi o desenvolvimento de aplica es Web de pequena escala e diferentes tipos seguindo o paradigma de orienta o a objetos A sele o das aplica es foi baseada em demandas reais observadas por situa es do dia a dia referentes ao contexto institucional e de pesquisa 1 Ferramenta para Configura o e Aloca o de servi os em Ambientes de Engenharia de Software Experimental a Engenharia de Software tem explorado a constru o de ambientes atrav s de integra o de ferramentas para gerenciar as informa es e apoiar as atividades do processo de desenvolvimento Com o mesmo intuito a equipe de Engenharia de Software Experimental prop s a defini o e constru o de um ambiente que pudesse apoiar o Processo de Experimenta o em ES A execu o de estudos experimentais em ES visa investigar dentre outros aspectos a viabilidade custo benef cio e emprego de t cnicas tecnologias e metodologia utilizadas no processo de desenvolvimento O objetivo deste trabalho desenvolver um dos componentes do Ambiente respons vel pela configura o dos Processos de Experimenta o a serem executados Ferramenta para Constru o e Manuten o de Matriz de Rastreabilidade de Requisitos e
336. to mais confi vel e garantindo sua qualidade DIAS NETO e TRAVASSOS 2006 Mais especificamente sobre o teste funcional dois fatores que influenciam sobremaneira a qualidade desses testes s o 1 a pr pria qualidade dos requisitos usados como or culo para o planejamento dos testes e 2 o procedimento adotado para gera o dos casos e procedimentos de teste ou seja de que forma esses artefatos s o gerados e qual os insumos necess rio para essa gera o Al m de impactarem diretamente na qualidade do produto os requisitos funcionais comp em a base para constru o dos modelos Web Logo a estrutura o dos requisitos com o objetivo de apoiar adequadamente a constru o dos modelos Web deve ser tratada como um ponto crucial para obten o de modelos de qualidade Podemos depreender ent o que a qualidade do produto final passa pela estrutura o adequada e pelo controle de qualidade dos requisitos funcionais uma vez que estes representam o or culo a partir do qual os modelos Web e o plano de testes funcionais s o derivados 1 3 Quest es de Pesquisa A partir do problema exposto na se o anterior a quest o de pesquisa para esta tese pode ser formulada como poss vel aprimorar a qualidade das aplica es Web atrav s da estrutura o da especifica o dos requisitos funcionais dessas aplica es em torno de um arcabou o que promova a garantia da qualidade da pr pria especifica o e do produto final
337. trat gia para Pesquisa dos Estudos Prim rios Escopo da Pesquisa A pesquisa ser realizada exclusivamente em bases de dados eletr nicas utilizando se da m quina de busca disponibilizada na web pelas bibliotecas digitais A pesquisa ser realizada pelos campos t tulo palavras chave e resumo Ser o pesquisados somente estudos cujo ano de publica o seja maior ou igual a 2004 A fonte de pesquisa ser a Scopus que indexa estudos das fontes IEEE Xplore ACM Digital Library e Springer Nenhuma restri o adicional ser aplicada Dessa forma todos os artigos dispon veis nessa base s o considerados artigos potenciais Termos utilizados na Pesquisa e web requirements analysis specification modeling modelling process method methodology approach technique metamodel A string de busca foi definida atrav s do uso dos conectores AND e OR juntamente com o grupo de termos definidos anteriormente Assim a string de busca foi definida como web and requirements and analysis or specification or modeling or modelling and process or method or methodology or approach or technique or metamodel Www scopus com 7 ieeexplore ieee org portal acm org www springerlink com 36 importante ressaltar que na constru o da string de busca evitou se o uso de termos compostos como web requirements ou requirements analysis com o objetivo de evitar excluir estudos que n o usassem exatamente essa terminolog
338. tru o do modelo navegacional segundo o m todo OOWS Duas raz es motivaram a troca da ferramenta do primeiro para o segundo estudo 1 a n o evolu o das funcionalidades 5 www staruml com 19 oferecidas pela ferramenta Poseidon for UML Community Edition que continuava oferecendo a possibilidade de explorar perfis UML somente para as vers es comerciais e 2 o surgimento da ferramenta StarUML que poca oferecia mais flexibilidade para constru o dos modelos desejados principalmente por permitir a defini o de perfis UML e a renderiza o customizada dos elementos dos modelos facilitando a cria o de modelos aderentes sem ntica e visualmente ao m todo OOWS Como o objetivo do estudo n o estava associado avalia o da ferramenta a estrat gia adotada para sele o desta baseou se na sua adequa o constru o dos modelos especificados no projeto do estudo 2 3 5 Execu o As equipes tiveram cerca de tr s semanas para a elabora o e entrega dos artefatos citados na Tabela 2 4 Ao final desse prazo cada equipe fez uma apresenta o de aproximadamente 30 minutos na qual explicaram os modelos gerados e as decis es de projeto adotadas Nessa apresenta o cada equipe tamb m teve que descrever quais dificuldades foram encontradas durante o processo de desenvolvimento O resumo das dificuldades relatadas est listado na Tabela 4 4 Tabela 2 4 Dificuldades relatadas pelos participantes do 2 estudo
339. ts in web applications Proceedings of the 1 International Workshop on the Web and Requirements Engineering pp 13 20 LUNA E R GARRIGOS GRIGERA J WINCKLER M 2010 Capture and Evolution of Web Requirements Using Webspec Proceedings of the 10 International Conference on Web Engineering ICWE 10 pp 173 188 MAFRA S BARCELOS R TRAVASSOS G H 2006 Aplicando uma Metodologia Baseada em Evid ncia na Defini o de Novas Tecnologias de Software Anais do XX Simp sio Brasileiro de Engenharia de Software SBES 06 pp 239 254 Florian polis Brasil MAFRA S TRAVASSOS G H 2006 Leitura Baseada em Perspectiva A Vis o do Projetista Orientada a Objetos Anais do V Simp sio Brasileiro de Qualidade de Software SBQS 06 Vit ria Brasil MELLO R M MARTINHO W TRAVASSOS G H 2010 Inspe o de Diagramas de Atividades da Especifica o de Requisitos Anais do XXIV Simp sio Brasileiro de Engenharia de Software SBES 10 Salvador Brasil 195 MELLO R M 2011 Uma T cnica para Inspe o de Diagramas de Atividades Disserta o de mestrado Programa de Engenharia de Sistemas e Computa o PESC COPPE UFRUJ MENDES E MOSLEY N COUNSELL S 2005 The Need for Web Engineering an Introduction Web Engineering Theory and Practice of Metrics and Measurement for Web Development Springer Verlag ISBN 3 540 28196 7 cap tulo 1 MOLINA F PARD
340. uipes que apresentaram os melhores projetos e para as tr s equipes que apresentaram os piores projetos poss vel notar que independente da qualidade do projeto o esfor o percebido pelas equipes segue um comportamento semelhante Tabela 2 7 Percep o de esfor o Diagrama Esfor o Equipes com Equipes com Total Total de Percebido melhores projetos piores projetos opini es Alto 8 7 15 Classe M dio 4 3 7 23 Baixo 0 1 1 Alto 11 6 17 Sequ ncia M dio 1 5 6 23 Baixo 0 0 0 23 Alto 0 0 0 Estado M dio 3 2 5 21 Baixo 9 7 16 Alto 0 1 1 Atividade M dio 10 4 14 17 Baixo 1 1 2 Alto 0 0 0 Ator M dio 1 0 1 19 Baixo 11 7 18 Alto 9 8 17 Navega o M dio 3 1 4 22 Baixo 0 1 1 Levando em considera o somente a opini o dos participantes que criaram os artefatos a Tabela 2 8 apresenta o percentual de distribui o do esfor o percebido por diagrama Tabela 2 8 Distribui o de percep o de esfor o dos participantes que criaram os artefatos Esfor o Classe Sequ ncia Estado Atividade Ator Navega o percebido Alto 61 9 73 7 0 0 11 1 0 0 90 0 M dio 33 3 26 3 26 7 66 7 11 1 0 0 Baixo 4 8 0 0 73 3 22 2 88 9 10 0 Total 100 100 100 100 100 100 A terceira quest o teve como foco a import ncia de cada modelo na percep o dos
341. ulos do SiGIC com caracter sticas distintas de onde foi poss vel observar tend ncias sobre a origem dos defeitos identificados e Adapta o do processo de engenharia de requisitos adotado no projeto com rela o s atividades t cnicas e artefatos gerados em virtude da an lise do impacto desse processo na qualidade dos requisitos e Configura o desenvolvimento e ou adapta o de t cnicas de inspe o e teste aplicadas para garantia da qualidade de aplica es Web e e Identifica o de indicadores m tricas que permitam avaliar antecipadamente tend ncias relativas qualidade dos produtos sendo desenvolvidos Assim baseado na an lise dos m todos Web propostos na literatura t cnica apresentada no Cap tulo 2 no que p de ser depreendido dos estudos de observa o apresentados no Cap tulo 3 e nas observa es realizadas no processo de desenvolvimento do SiGIC mais precisamente sobre fatores que impactavam a qualidade do produto foram identificadas lacunas no que diz respeito ao tratamento de requisitos principalmente com rela o estrutura o desses requisitos em um arcabou o que possa servir de ponto de partida para explora o dos modelos preconizados nos m todos Web contempor neos 33 3 M todos de Desenvolvimento de Aplica es Web Neste cap tulo apresentada uma revis o da literatura t cnica para caracteriza o de m todos de desenvolvimento que tratam os requisitos de aplica
342. ura eletr nica p Casos de Uso 5 J UCO01 Pagar boleto banc rio O Descri o Alternati Exce es Regras Atores do Caso de Uso A2 1 Sistema solicita que o diente fa a a leitura eletr nica do boleto 4 Fluxo Principal A2 2 Cliente realiza a leitura eletr nica E Fluxos Alternativos MSjaz 3 vai para 6 Al op o inv lida E A2 diente seleciona op o de leitura eletr nica 4 A3 n mero do boleto inv lido amp As data de vencimento menor que a data atua system Response solicita que o diente fa a a leitura eletr nica do boleto 4 A5 dados de pagamento inv lidos E E 4 A6 senha inv lida em menos de 3 tentativas A7 senha inv lida na 3a tentativa E a Fluxos de Exce o A es Alternativas Exce es Regras Ej Regras Erros E UCO02 Transfer ncia entre contas E UC003 Emitir extrato 3 UC004 Autenticar usu rio Lad Le bo EDE DE MEDENEA m r Grupo de Engenharia de Software Experimental COPPE UFRJ Figura 6 6 Tela da UseCaseAgent com o fluxo alternativo A2 do caso de uso Pagar boleto banc rio A Figura 6 7 apresenta a tela para defini o das regras a serem observadas no escopo do caso de uso Cada uma das regras deve ser definida como regra de conceitua o navega o ou apresenta o 3 1 UC001 Pagar boleto
343. usados nas descri es das a es 6 2 2 4 Ferramenta de GUTI RREZ et al 2008 GUTIERREZ et al 2008 prop em uma ferramenta cujo nome n o citado no referido artigo para transforma o de descri es textuais em diagramas de atividades Est previsto que a descri o textual esteja armazenada em um arquivo XML de acordo com um esquema pr definido usando linguagem natural para descri o dos seus diversos elementos nome descri o fluxo principal e alternativos A ferramenta se limita ent o a realizar a transforma o deste arquivo em um diagrama de atividades O metamodelo que ap ia essa transforma o o pr prio esquema do arquivo XML e o metamodelo da UML Na realidade existe uma correla o quase direta entre os elementos do arquivo XML e os elementos do diagrama de atividades tornando a transforma o uma tarefa trivial N o h nenhum tipo de verifica o realizada sobre a especifica o do caso de uso pois o XML usado como entrada para o processo de transforma o j est constru do de acordo com o esquema pr definido Tamb m n o h nenhum tipo de classifica o para as a es que descrevem o caso de uso ou seja todas s o tratadas segundo a mesma perspectiva A partir dessa an lise poss vel destacar tr s diferenciais proporcionados pela ferramenta UseCaseAgent em rela o aquelas descritas anteriormente e Permite a defini o da especifica o em um modelo h brido onde o desen
344. utgoing target oclisTypeOf ExtendUCAction 122 inv sel or sel implies self outgoing gt size and parent oclisTypeOf AlternativeFlow parent oclisTypeOf ExceptionFlow self outgoing target oclisTypeOf ActorAction or se or sel or sel or sel T 5 3 6 9 Metaclasse GotoAction a A OO N Destino obrigat rio outgoing target oclIsType0O outgoing target oclIsType0Of GotoAction Fo outgoing target oclIsType0Of FinishAction outgoing target oclIsType0Of IncludeUCAction E ExtendUCAction Destino n o pode ser outra a o GotoAction Destino deve pertencer cadeia de ativa o do fluxo Tem que ser a ltima a o em um fluxo alternativo ou de exce o N o pode ter fluxos alternativos ou de exce o esta regra j est implementada na estrutura do metamodelo 6 Se vier ap s uma a o do ator deve ter como destino uma a o do sistema 7 Se vier uma a o do sistema deve ter como destino outra a o do sistema ou uma resposta do sistema 8 Se vier ap s uma resposta do sistema deve ter como destino outra resposta do sistema ou uma a o do ator Formaliza o em OCL context ActionFlow def targetInChain chain Set BasicAction actio
345. utro diagrama de atividades Repare que o UseCaseAgent n o ap ia a cria o desses sub diagramas 210 Essa op o permite apenas criar um link entre uma a o resposta do sistema e um diagrama de atividades que especifica detalhadamente o comportamento do sistema para essa a o espec fica Esses sub diagramas devem ser criados na pasta lt lt behavior view gt gt Caso o sub diagrama ainda n o exista o desenvolvedor pode selecionar a op o NOVO A 9 Fluxos Alternativos Para criar um fluxo alternativo basta selecionar a a o que ser substitu da pela alternativa e na aba Alternativas clicar em Novo ou selecionar na rvore esquerda uma alternativa previamente criada O UseCaseAgent sempre cria um novo fluxo alternativo A1 A2 A3 e assim por diante com uma condi o indefinida representada por Para editar esse fluxo basta clicar sobre ele na rvore a esquerda As Figuras A 9 e A 10 mostram esse procedimento S Use Case Agent vers o 0 3 a hd ee ll ai Ae A a elaks Arquivo Verificar UCModel 3 Atores Fluxo Principal S J Casos de Uso Ordem Descri o Alternativas Exce es Regras E tica o do usu ri E Uco01 Auten duuri la Sistema apresenta o formulario de autentica o Atores do Caso de Uso H 1 4 e TE a 2 linternauta fornece login e senha E Fluxos Alternativos B 3 Sistema valida login e senha E Fluxos de Exce o Sistema apres
346. uz um resultado a partir desta e 4 O sistema retorna o resultado do processamento da requisi o ao ator Analisando a natureza das a es que detalham a transa o do caso de uso poss vel afirmar que 1 O primeiro passo descreve uma a o que exprime o comportamento esperado para o ator Essa a o executada fora do escopo do sistema 2 Os passos dois e tr s descrevem a es que mudam o estado interno do sistema ou produzem algum resultado Essas a es normalmente consomem a requisi o e os dados enviados pelo ator e 108 3 O quarto passo descreve uma a o do sistema que retorna para o ator algum resultado observ vel Ela normalmente consulta o estado interno do sistema ou usa o resultado produzido anteriormente para gerar uma resposta para o ator Os conceitos contidos nesses tr s itens foram usados na elabora o de um conjunto de tr s a es que formam a base para descri o de casos de uso segundo a abordagem aqui proposta 5 3 4 2 Especializa o das A es A partir da an lise do conceito de transa o de caso de uso JACOBSON 1992 a metaclasse Action da UML foi especializada em tr s sub classes ActorAction SystemAction e SystemResponse Tabela 5 8 Adicionalmente o foco de cada uma dessas a es torna poss vel outra correspond ncia relevante no contexto do desenvolvimento de aplica es Web cada uma delas normalmente envolve o uso ou a refer ncia a elementos de uma ou mais persp
347. ver um fluxo alternativo ap s uma resposta do sistema este fluxo deve iniciar obrigatoriamente com outra resposta do sistema SystemResponse ou a o do sistema SystemAction Nesse caso como a resposta do sistema apresenta 116 o resultado de um processamento e ou a solicita o de uma nova informa o ent o o fluxo alternativo interpretado como uma atitude do ator diferente daquela esperada solicitada pelo sistema o que leva ao in cio de um novo di logo com o sistema sr flow system response decision node principal actor action alternativo system response system action system action Figura 5 14 Transi es permitidas a partir de uma SystemResponse com fluxo alternativo 5 3 6 Restri es do Metamodelo UCModel Os diagramas apresentados nas Figuras 5 11 a 5 14 n o esgotam todas as restri es previstas no metamodelo UCModel Outras restri es foram definidas com o objetivo de dar consist ncia ao metamodelo e se baseiam na sem ntica capturada por cada elemento ou grupo de elementos As se es a seguir apresentam uma lista de restri es para cada elemento do metamodelo e a sua respectiva especifica o em OCL Object Constraint Language OMG 2010b 5 3 6 1 Metaclasse UseCase mk ID obrigat rio 2 Nome obrigat rio 3 Resumo obrigat rio 4 Criticalidade obrigat ria 5 Frequ ncia de uso obrigat ria 6 Pr condi o obrigat ria 7 P s
348. vimento mas n o apresenta novas t cnicas ou modelos Por isso utiliza muitas das t cnicas e modelos propostos pelo OOHDM Ao todo o processo de desenvolvimento do HFPM possui 13 fases sendo que a fase de Modelagem dos Requisitos composta de 5 atividades e Descri o do problema n o prev nenhuma t cnica espec fica logo o uso da linguagem natural e Descri o de funcionalidades prop e a utiliza o de casos de uso e Modelagem de dados prop e o uso de diagramas de classes e Modelagem da interface com o usu rio usa prot tipos ou sketches para apresenta o ao cliente e e Descri o de requisitos n o funcionais tamb m em linguagem natural Ap s essa fase s o criados os modelos conceituais de navega o e de apresenta o seguindo os preceitos do m todos OOHDM 40 3 2 3 5 OOHDM Object Oriented Hypermedia Design Model O OOHDM SCHWABE et al 1996 um m todo baseado em modelos e orientados a objetos para especifica o e constru o de aplica es hiperm dia concentrando se em dois aspectos navegacional e estrutural Na sua vers o original o OOHDM n o previa atividades relacionadas ao tratamento de requisitos Entretanto esse recurso foi introduzido por VILAIN et al 2000 atrav s dos UIDs User Interaction Diagram O m todo OOHDM compreende cinco etapas que combinam um estilo de desenvolvimento incremental iterativo e baseado em prot tipos e Identifica o e defini o de requi
349. volvedor pode optar por especificar o caso de uso diretamente com o diagrama de atividades abordagem gr fica ou usando uma descri o 150 textual abordagem textual a partir da qual o diagrama de atividades gerado e Permite a verifica o da ader ncia da especifica o do caso de uso ao metamodelo UCModel verifica o sint tica independente da abordagem gr fica ou textual utilizada na cria o da especifica o e e Permite a gera o da descri o textual da especifica o independente da abordagem gr fica ou textual utilizada na cria o da especifica o 6 3 Ferramenta ModelT A ferramenta ModelT Mode Transformations applied to Test foi desenvolvida com o objetivo de apoiar a defini o do plano de testes funcionais explorando a abordagem de Testes Baseados em Modelos MBT Model Based Testing APFELBAUM e DOYLE 1997 a partir de diagramas de atividades Para tal sua principal funcionalidade a deriva o dos modelos de testes funcionais a partir dos diagramas de atividades que representam as especifica es dos casos de uso Posteriormente o modelo de testes usado na gera o dos casos e procedimentos de testes funcionais Para constru o do modelo de testes foi adotado o metamodelo TDE HARTMANN et al 2005 A escolha desse metamodelo TDE se deu por oportunidade e conveni ncia em virtude do conhecimento pr vio de membros do grupo de Engenharia de Software Experimental ESE da UFR

uma abordagem baseada em modelos para especificação e

Contents

Download Pdf Manuals

Related Search

Related Contents

uma abordagem baseada em modelos para especifica&ccedil;&atilde;o e

Contents

Download Pdf Manuals

Related Search

Related Contents

uma abordagem baseada em modelos para especificação e