{barbara.bah.15,

Transcrição

1 Modelagem de contexto para o sistema FAQ baseado em Linhas de Produto Barbara Cristina dos Santos [Voluntário] 1, Simone Nasser Matos [Orientadora] 1, Thissiany Beatriz Almeida [Colaborador] 1 1 Departamento Acadêmico de Informática Câmpus Ponta Grossa Universidade Tecnológica Federal do Paraná - UTFPR Avenida Monteiro Lobato, s/n - km 04 - Ponta Grossa /PR, Brasil - CEP {barbara.bah.15, thissy.almeida}@gmail.com, snasser@utfpr.edu.br Resumo - Um dos desafios na construção de linhas de produto é que o profissional precisa conhecer profundamente o sistema que será desenvolvido, pois se faz necessário à criação de núcleos que sejam flexíveis o suficiente para se encaixar em todas as aplicações que o utilizarão. Este trabalho apresenta os passos realizados para a construção da modelagem de contexto de um sistema FAQ baseado em Linhas de Produto, em que foram criados: o modelo de contexto, o diagrama de características e o digrama de caso de uso. Palavras-chave: Modelagem de contexto, LPS, FAQ. Abstract - One of the challenge on the product line building is that the professional needs to know deeply the system that will be developed, because do necessary to creation of nuclei that is flexible enough to fit in all applications that use. This work shows the realized steps to building of modeling context of the FAQ s system based in Product in Line, where are created: the context model, diagram characteristics and the use case diagram. Keywords: Modeling context, PLS, FAQ. INTRODUÇÃO Atualmente a atividade de desenvolvimento de software vem enfrentando vários desafios. Desta forma, novos enfoques que favoreçam o reúso de artefatos de software têm sido propostos, como o de Engenharia de Linha de Produto [1]. Linhas de produto de software (LPS) é uma solução útil e viável para a questão do reúso de software. Este é um paradigma de desenvolvimento que tem como objetivo não apenas o reúso de código, mas também da arquitetura e dos requisitos. Além disso, proporciona diminuição nos custos de desenvolvimento, aumento da qualidade e redução do tempo de entrega do produto [2]. Vários métodos são usados para o desenvolvimento de LPS, entre eles: FAST (Family- Oriented Abstraction, Specification and Translaction), PLUS (Product Line UML-Based Software Engineering) e FODA (Feature Oriented Domain Analysis). Neste trabalho se usa um método baseado nos três citados anteriormente para o modelagem de um sistema FAQ. O método compreende duas fases principais da teoria de LPS: Engenharia de Domínio e Engenharia de Aplicação, sendo que cada uma contém suas subfases [3].

2 METODOLOGIA No decorrer do projeto foi necessário um estudo sobre os conceitos de FAQ (Frequently Asked Questions), RBC (Raciocinio Baseado em Casos) e o método proposto para desenvolvimento de LPS. Neste tópico serão descritos esses conceitos os quais são necessários para a modelagem de um sistema FAQ que está sendo desenvolvido para o auxílio de usuários de um framework de domínio na área de formação de preço de venda. FAQ. O FAQ é um acrônimo da expressão inglesa Frequently Asked Questions, que significa Perguntas Frequentes [5]. O nome nasceu, na Usenet, numa tentativa de reduzir o número de perguntas semelhantes colocadas repetidamente [6]. Este recurso tem como finalidade solucionar boa parte dos problemas dos usuários, sanando suas dúvidas. Consiste em uma listagem de respostas às dúvidas mais comuns apresentadas pelos usuários [7]. Para que este recurso seja eficiente, é necessário que haja uma atividade de monitoramento constante das perguntas feitas pelos usuários ao serviço de suporte. Logo após, estas perguntas são incluídas na lista de FAQs. Outro quesito a ser considerado é que esta lista seja facilmente acessível a partir de qualquer tela do ambiente. Para entender o funcionamento de um FAQ, foi realizado o estudo de alguns sistemas similares e através disso, pode-se perceber a rápida solução para problemas comuns entre os usuários de um determinado sistema. Para a construção de um sistema FAQ podem ser utilizadas algumas técnicas de Inteligência Artificial, como Raciocínio Baseado em Casos (RBC), Redes Neurais, Agentes, dentre outras [8]. O sistema FAQ que está sendo desenvolvido é para o auxílio aos usuários de um framework de domínio na área de formação de preço de venda. O framework em questão tem como objetivo fornecer o preço de venda de um produto e/ou serviço a partir de características comuns presentes num banco de dados [9]. Um ponto a ser levado em consideração quando se trata de um sistema FAQ é a escolha do tipo desse sistema a ser elaborado, podendo este ser estático ou dinâmico. No estudo de caso em questão optou-se pelo sistema FAQ dinâmico, que tem como objetivo a criação de um banco de dados de conhecimento exaustivo sobre o conjunto de dúvidas e necessidades dos usuários. O intuito na construção desse sistema FAQ é utilizar os conceitos baseados em Linhas de Produto de Software, FAQ e a técnica de Raciocínio Baseado em Casos (RBC) para criar um sistema dinâmico que possa ser reusado para várias aplicações. RBC. O Raciocínio Baseado em Casos (RBC) é uma técnica que busca resolver novos problemas adaptando soluções utilizadas para resolver problemas anteriores [10]. Dentre as características do funcionamento de um sistema RBC estão: A extração do conhecimento a partir de casos ou experiências com que o próprio sistema se depara. A identificação das características mais significantes dos casos apresentados a fim de devolver uma melhor solução (resposta). O armazenamento do caso e sua respectiva solução. A qualidade de um sistema RBC depende de sua experiência, ou seja, depende do número de casos relevantes que farão parte da base de casos. Método proposto para desenvolvimento de LPS. O método escolhido para o desenvolvimento do sistema FAQ, propõe um conjunto de fases adaptadas dos métodos PLUS, FAST e FODA. O método compreende duas fases principais da teoria de LPS:

3 Engenharia de Domínio e Engenharia de Aplicação, sendo que cada uma contém suas subfases [3]. A fase de Engenharia de Domínio tem como objetivo a produção de artefatos reutilizáveis que modelam o domínio da linha de produto e por isto é realizada de forma iterativa. É composta por algumas subfases, sendo elas, a Análise de Domínio e a Identificação de Características, que se subdivide em Requisitos, Modelagem, Projeto, Implementação e Teste do domínio. A subfase Análise de Domínio deriva-se do método FAST. Escolheu-se utilizar a ideia dada pelo FAST por ser o mais completo. O objetivo dessa subfase é analisar e definir o escopo do software que será explorado para obtenção de seus artefatos. Ao final, cria-se o modelo de contexto o qual define o escopo da modelagem do domínio. A subfase Requisitos de Domínio provém dos métodos FODA e PLUS, optou-se por utilizá-la por ser importante na extração de requisitos. Tem por objetivo identificar os requisitos contidos no sistema e observar os pontos comuns e variáveis de LPS. O artefato criado é o modelo de características onde estão explicitadas as características comuns contidas no domínio. A subfase Modelagem de Domínio provém do método PLUS. Tem como finalidade fazer a decomposição do problema em questão e a modelagem estática do software que está sendo modelado. Os artefatos criados são o Diagrama de Caso de Uso, os cenários dos casos de uso e o diagrama de classe. A subfase Projeto de Domínio também provém do método PLUS e foi escolhida por ser uma fase que permite a escolha da arquitetura em todos os produtos. Ao final, cria-se um modelo do projeto do software baseado em componentes. A subfase Implementação do Domínio foi adaptada do método PLUS. Escolheu-se permanecer com esta subfase, pois é nela que se faz a implementação dos componentes reutilizáveis e também se define a linguagem de programação que será utilizada no software. Na subfase Teste de Domínio são realizados os testes nos componentes de LPS, validando e verificando os componentes reutilizados, dando ênfase na integridade e funcionalidade. Esta subfase foi adaptada do método PLUS. A fase Engenharia de Aplicação tem como finalidade o desenvolvimento de uma aplicação individual baseando-se no que já foi definido na Engenharia de Domínio. É composta por algumas subfases, sendo elas, Requisitos, Implementação, Testes e Entrega e Suporte da Aplicação. A subfase Requisitos de Aplicação tem como objetivo identificar e modelar os requisitos da aplicação em diagramas de caso de uso, por isso decidiu-se permanecer com esta subfase. Ela foi adaptada dos métodos PLUS e FAST. Os artefatos criados são a lista de requisitos das variabilidades, o diagrama de caso de uso da aplicação e o diagrama de classe. A subfase de Implementação da Aplicação provém do método FAST, ela permite que seja realizada a implementação do produto conforme a extração de requisitos obtida em subfases anteriores. A subfase dos Testes da Aplicação tem como objetivo a validação do produto. Para isto são realizados testes funcionais e de integração e a análise da integridade dos requisitos. A subfase de Entrega e Suporte da Aplicação originou-se do método FAST e é considerada de importância para a satisfação do cliente. Nesta é feita a entrega da aplicação ao cliente ou posteriormente para o suporte, caso seja necessário. RESULTADOS E DISCUSSÃO A seguir serão apresentados os resultados atingidos com este trabalho. Tem-se a descrição do sistema utilizado para o estudo de caso, a Análise de Domínio e a Identificação das Características que é composta pelas seguintes etapas: Requisitos do Domínio,

4 Modelagem do Domínio e Projeto do Domínio. Durante o trabalho, foram desenvolvidas as etapas de Requisitos e Modelagem do Domínio. Análise de domínio. O sistema utilizado como domínio foi um sistema FAQ, o qual possui diversas funcionalidades tais como: Gestão de Habilidades, Controle de Usuário, Administração de Casos Similares e Controle de Dúvidas. Os diagramas foram criados na ferramenta Odyssey. Para estudo de caso desenvolvido neste trabalho foram escolhidos três sistemas FAQ com rotinas similares, o que possibilita a criação de core assets 1. Os sistemas foram retirados do sítio Inbenta [9], do sítio dos Correios [11] e do Metrô de São Paulo [12]. A Figura 1 ilustra o diagrama de contexto para o sistema FAQ. Figura 1. Modelo de Contexto Esta figura ilustra os sistemas que compõem um FAQ bem como seus relacionamentos. No sistema de Gestão de Habilidades o administrador pode visualizar todas as dúvidas enviadas para a análise que ainda estão pendentes de respostas e verificar a qual área a dúvida pertence. Logo após, ele escolhe para qual pessoa irá enviar a dúvida com a resposta. Neste sistema será feito o cadastro de áreas, pessoas, relacionando as pessoas a área. No Controle de Usuário o usuário consulta sua dúvida e o sistema processa a pergunta retornando as respostas iguais ou similares que já tenham sido cadastradas. Tendo as respostas em mãos, o usuário verifica dentre estas qual satisfaz a sua dúvida. Se ele encontrar uma resposta que o satisfaça, ele pode confirmar e seus dados serão salvos na base de dados. Caso contrário, o usuário envia sua dúvida para o controle de dúvidas, onde posteriormente será respondida e anexada a base de dados. A Administração de Casos Similares fornece aos usuários alternativas de respostas para seus questionamentos. Esta funcionalidade utiliza técnicas de RBC para identificar quais os casos registrados na base de casos mais se assemelham a dúvida informada pelo usuário. Sendo assim, retorna-se as perguntas similares. E por fim, no Controle de Dúvidas é feito o cadastro das dúvidas, a verificação se uma determinada pergunta foi respondida e enviada para o usuário, além de realizar estatísticas de respostas por cada pessoa e de qual área as dúvidas pertencem. Identificação de características. Apresenta-se a aplicação e os artefatos gerados por esta subfase em suas respectivas etapas. 1 É um conjunto de assets prontos para serem reusados no desenvolvimento de novos produtos.

5 Requisitos de domínio: Descrevem-se a seguir os três sistemas FAQ utilizados como base para o desenvolvimento do estudo de caso. Sistema FAQ sítio Inbenta O sistema utilizado como exemplo de domínio nesse trabalho foi baseado no sistema FAQ do sítio Inbenta. Este sistema foi escolhido, pois possui as características necessárias para um FAQ dinâmico. A partir da análise do funcionamento desse sistema, foi possível constatar que um FAQ dinâmico possui as seguintes features: Consultar dúvida: A consulta da dúvida é feita com o usuário inserindo sua pergunta no campo alguma dúvida. Como resultado serão apresentadas todas as perguntas similares com suas respectivas respostas, assim o usuário poderá procurar dentre essas opções, a mais adequada, ou ainda entrar em contato com a equipe de suporte através da aba contato, para maior esclarecimento. Cadastro de usuário: O usuário além de pesquisar a sua dúvida, ainda terá a possibilidade de fazer seu cadastro para se comunicar com um dos consultores. Para o cadastro, o usuário precisa fornecer os seguintes dados: Nome Completo, e a mensagem, sendo neste caso a dúvida. Enviar dúvidas: O usuário pode entrar em contato com a equipe de suporte para enviar as dúvidas de duas maneiras: a primeira é como já informada através de um cadastro no site, e a segunda diretamente no disponibilizado no sítio. Sistema FAQ sítio dos Correios Outro exemplo encontrado é o FAQ do site dos Correios, que possui um diferencial em relação aos outros encontrados, pois agrupa as perguntas em categorias. Outra característica encontrada neste sistema é o fato dele ser um FAQ estático, ao contrário do exemplo anterior. A partir da análise do funcionamento desse sistema, foi possível constatar que o FAQ dos Correios possui as seguintes features: Escolher categoria: A consulta da dúvida é feita com o usuário escolhendo uma das categorias, na qual ele acredite que sua dúvida se enquadre. Ao selecionar uma das categorias da tela principal do FAQ, é aberto o conjunto de perguntas daquela categoria. Escolher pergunta: Após ser escolhida a categoria, serão apresentadas as perguntas, e o usuário poderá selecionar a pergunta de seu interesse. Clicando na pergunta desejada, ele obtém a resposta. Sistema FAQ do Metrô de São Paulo Um outro exemplo encontrado foi o FAQ do Metrô de São Paulo. Este sistema é o mais simples e também pode ser classificado como um FAQ estático. A partir da análise do funcionamento desse sistema, foi possível constatar que o FAQ do Metrô de São Paulo possui as seguintes features: Escolher pergunta: Neste FAQ as perguntas frequentes foram armazenadas em apenas uma categoria, todas as perguntas são apresentadas na tela principal. Portanto, quando o usuário entrar na seção Fale Conosco e clicar no menu FAQ, basta procurar a pergunta desejada entre as 15 propostas. Após realizar a descrição narrativa dos sistemas, identifica-se para cada um deles suas funcionalidades e se estas são pontos similares (S) ou de variabilidade (V). A Tabela 1 apresenta a lista de requisitos para os três sistemas.

6 Tabela 1. Lista de Requisitos Sistemas Funcionalidades Classificação Consultar Dúvida S FAQ Inbenta Mostrar Perguntas Similares V Enviar Dúvida V Cadastrar Usuário V FAQ Correios Selecionar Categoria V Selecionar Dúvida S FAQ Metrô Selecionar Dúvida S Os Sistemas FAQ Inbenta, FAQ Correios e FAQ Metrô, possuem pontos distintos (variáveis) identificados por meio da análise dos aplicativos. As variabilidades são aquilo que os sistemas oferecem de diferente. Estão listadas a seguir: Mostrar Perguntas Similares: A função de apresentar as perguntas similares só aparece no sistema Inbenta, por isso é considerada uma variabilidade. Nessa função o usuário insere a sua pergunta, obtendo assim todas as perguntas similares existentes no banco, dessa forma o usuário pode escolher dentre as opções, aquela que mais se adequa com a sua dúvida. Cadastrar Usuário: Essa funcionalidade é considerada como variabilidade, pelo fato de estar presente somente no sistema Inbenta. O usuário além de pesquisar a sua dúvida, ainda terá a possibilidade de fazer seu cadastro para se comunicar com um dos consultores. Para o cadastro, o usuário precisa fornecer os seguintes dados: Nome Completo, e a mensagem, sendo neste caso a dúvida. Enviar Dúvidas: Assim como as duas funcionalidades apresentadas acima, a Enviar Dúvidas só aparece no sistema Inbenta. Nessa funcionalidade o usuário pode entrar em contato com a equipe de suporte para enviar as dúvidas de duas maneiras: a primeira é como já informada através de um cadastro no site, e a segunda diretamente no disponibilizado no sítio. Selecionar Categorias: Essa funcionalidade esta presente somente no sistema dos Correios. A consulta da dúvida é feita com o usuário escolhendo uma das categorias, na qual ele acredite que sua dúvida se enquadre. Ao selecionar uma das categorias da tela principal do FAQ, é aberto o conjunto de perguntas daquela categoria. Após a análise dos sistemas, nesta subfase se cria o Diagrama de Features que ilustra as variabilidades entre os sistemas analisados. A Figura 2 ilustra as variabilidades obtidas entre os sistemas. As variabilidades são obtidas por meio da análise detalhada de cada requisito.

7 Figura 2. Diagrama de features das Variabilidades. Modelagem de Domínio: Nesta fase é feita a decomposição do problema através de uma modelagem estática ou de comportamento do sistema, sendo esta representada por diagrama de classes ou de caso de uso, respectivamente. Neste caso, optou-se pela utilização do diagrama de casos de uso, pois este deixa o problema em questão mais claro e de fácil entendimento. A Figura 4 ilustra o diagrama de caso de uso para as similaridades entre os sistemas FAQ do site Inbenta, dos Correios e do Metrô de São Paulo. As similaridades foram obtidas da etapa de Requisitos do Domínio. Figura 4. Diagrama de Caso de Uso das Similaridades FAQ INBENTA/CORREIOS/METRO. CONCLUSÕES Para construir aplicações baseadas em Linhas de Produto, se faz necessário à realização de pesquisas sobre métodos e suas aplicações. Neste trabalho foi utilizado um método que possui as melhores práticas dos FODA, FAST e PLUS. Estudou-se a ferramenta de modelagem Odyssey, pois está possuí os diagramas necessários para a criação dos artefatos de entrada e saída proposto pelo método. Durante a modelagem do sistema FAQ foram identificadas as similaridades e variabilidades dos três exemplos de caso de uso. Durante a fase de Engenharia de Domínio, a qual inicia com a subfase Análise de Domínio, construiu-se o modelo de contexto que demonstra o sistema no qual os produtos estarão inseridos. Após esta subfase, é realizada a Identificação de Características, que começa com a Análise de Requisitos do domínio na qual se procura identificar a lista de requisitos contendo as similaridades e variabilidades entre as aplicações, elaborando o diagrama de características com os pontos variáveis dos sistemas. Por fim, é feita a Modelagem de Domínio, onde são produzidos os diagramas de caso de uso de domínio.

8 Com o estudo realizado se pôde notar algumas diferenças entre os softwares baseados em LPS e os softwares que não são. Uma das diferenças encontradas é que o início da modelagem de uma LPS é mais complexa visto que se deve analisar no mínimo duas aplicações e delas identificar os pontos comuns e variáveis. AGRADECIMENTOS Agradeço à Fundação Araucária pela compra de equipamentos e a Universidade Tecnológica Federal do Paraná Câmpus Ponta Grossa no que tange ao ambiente de desenvolvimento do sistema. REFERÊNCIAS [1] MUTHIG, D., JOHN, I., ANASTASOPOULOS, M., FORSTER, T., DÖRR, J. and SCHMIDS. K., GoPhone - A Software Product Line in the Mobile Phone Domain. IESE- Report No /E, Version 1.0, March 5, S [2] XAVIER, E. L. S. "Um estudo sobre ferramentas case para gerenciamento do processo de engenharia de domínio em linha de produtos de software," Universidade de Pernambuco, Caruaru, 2001, pp ]. [3] DELAZERI, B. R.; WOLF, E. C. Modelagem de um Sistema Organizador Baseado em Linhas de Produto f. Trabalho de Conclusão de Curso Tecnologia em Analise e Desenvolvimento de Sistemas - Universidade Tecnológica Federal do Paraná. Ponta Grossa, [4] SILVEIRA, M. S. and LEITE, L. L, Alternativas de ajuda On-line para Ambientes de Aprendizagem Colaborativa. Porto Alegre, 2009, 10 páginas. Artigo (Pós-Graduação em Ciência da Computação). Faculdade de Informática, Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS). [5] SANT ANNA, I. B. de C and FERNANDES, N. C., A comunicação Institucional dos Websites Corporativos: um estudo exploratório. Revista Anagrama de Informática, São Paulo, nº04, p. 1-17, junho/agosto [6] CORRÊA, J., Educação à distância: orientações metodológicas. Porto alegre: Artmed, [7] CAVALARI, G. O. T. and COSTA, H. A. X. Modelagem e Desenvolvimento de um Sistema Help-Desk para a Prefeitura Municipal de Lavras. Revista Facela. Curitiba, [8] Framemk. Framework de domínio na área de formação de preço de venda [9] Inbenta. FAQ dinâmica. [10] LEÃO, B. Construção da base de conhecimento de um sistema especialista de apoio ao diagnóstico de cardiopatias congênitas. São Paulo: Escola Paulista de Medicina, [11] Correios. < [12] Metrô de São Paulo. <