Spelling suggestions: "subject:"modelo dde features"" "subject:"modelo dee features""
1 |
Uma Abordagem Orientada a Objetivos para as Fases de Requisitos de Linhas de Produtos de SoftwareCésar Borba, Clarissa 31 January 2009 (has links)
Made available in DSpace on 2014-06-12T15:55:38Z (GMT). No. of bitstreams: 2
arquivo2275_1.pdf: 5480552 bytes, checksum: be0d8c06ce046cc764aaa9918db223b4 (MD5)
license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5)
Previous issue date: 2009 / Uma Linha de Produtos de Software (LPS) é um grupo de produtos de software com características
comuns e variáveis, que também pode ser chamada de família de produtos. As caracterísiticas
de uma LPS precisam ser documentadas explicitamente para possibilitar o reuso
estratégico dos seus artefatos. Na atividade de Engenharia de Requisitos, isto significa que
além de capturar as suas variabilidades, também é preciso relacionar os diferentes tipos de
requisitos, tais como organizacionais, não-funcionais e funcionais, além de manter o rastreamento
entre eles. Atualmente a captura desta informação é feita usando os modelos de features,
mas esses não capturam requisitos não-funcionais explicitamente e nem a influência positiva/
negativa destes requisitos para alcançar configurações alternativas de uma aplicação na
LPS. Esta influência pode ajudar na escolha de uma configuração específica para uma aplicação
alcançar os objetivos da organização. Um objetivo é um estado do mundo que os stakeholders
desejam alcançar enquanto que uma feature é uma característica que o sistema deve
apresentar. Partindo destas definições, abordagens orientadas a objetivos podem ser usadas
como uma forma efetiva para descobrir requisitos variáveis e comuns de uma LPS, bem como
para reduzir os custos associados à configuração de um produto específico na família de produtos.
Uma abordagem de requisitos orientada a objetivos que tem sido usada para o desenvolvimento
de sistemas complexos é o framework i*. O i* fornece uma maneira natural de
identificar e especificar tanto os interesses dos stakeholders como as características do sistema
pretendido. Este trabalho propõe uma extensão da linguagem de modelagem do i*, chamada
i*-c (i* with cardinality), que adiciona cardinalidade nos elementos de modelos intencionais
e assim, permite a identificação e modelagem de features a partir de modelos orientados
a objetivos. Para guiar a configuração de uma aplicação específica em uma LPS foi definida
a abordagem G2FM (Goal to Feature Model). Ela propõe um processo de identificação e
modelagem de features comuns e variáveis de uma LPS em modelos i* com cardinalidade e, a
partir destes, produz um modelo de features equivalente
|
2 |
Objetivos e Cenários na Engenharia de Requisitos para Linhas de Produto de SoftwareSouza, Gabriela Guedes de 24 February 2012 (has links)
Submitted by Pedro Henrique Rodrigues (pedro.henriquer@ufpe.br) on 2015-03-05T17:03:30Z
No. of bitstreams: 2
license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5)
Dissertacao - Gabriela 04-12.pdf: 8388608 bytes, checksum: bf0a6a0b446548dba8b07cf11cea0989 (MD5) / Made available in DSpace on 2015-03-05T17:03:30Z (GMT). No. of bitstreams: 2
license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5)
Dissertacao - Gabriela 04-12.pdf: 8388608 bytes, checksum: bf0a6a0b446548dba8b07cf11cea0989 (MD5)
Previous issue date: 2012-02-24 / Abordagens da Engenharia de Requisitos Orientada a Objetivos (em inglês, Goal Oriented
Requirements Engineering ou GORE) podem capturar de forma efetiva tanto os objetivos dos
stakeholders como os requisitos do sistema. Quando aplicadas no contexto de Linha de Produto
de Software (LPS), elas podem oferecer uma maneira natural de capturar similaridades e
a variabilidade de uma LPS. Já existe, inclusive, uma abordagem GORE que possibilita a obtenção
sistemática do modelo de features a partir de modelos i* com cardinalidade. Porém,
através de uma abordagem GORE não é possível modelar características comportamentais de
uma LPS, para isso é comum usar uma técnica de especificação de cenários de caso de uso.
Este trabalho define uma abordagem de Engenharia de Requisitos para LPS que integra uma
abordagem GORE com uma técnica de especificação de cenários de caso de uso com variabilidade.
Esta abordagem é denominada GS2SPL (do inglês, Goals and Scenarios to Software
Product Line) e inclui também um subprocesso para configuração de aplicações específicas
de uma LPS com base na priorização de requisitos não-funcionais. Este trabalho também apresenta
a aplicação de GS2SPL à LPS TaRGeT, cujos produtos são ferramentas de geração
automática de casos de teste.
|
3 |
Uma abordagem para linha de produtos de software científico baseada em ontologia e workflowCosta, Gabriella Castro Barbosa 27 February 2013 (has links)
Submitted by Renata Lopes (renatasil82@gmail.com) on 2017-05-31T17:53:13Z
No. of bitstreams: 1
gabriellacastrobarbosacosta.pdf: 2243060 bytes, checksum: 0aef87199975808e0973490875ce39b5 (MD5) / Approved for entry into archive by Adriana Oliveira (adriana.oliveira@ufjf.edu.br) on 2017-06-01T11:50:00Z (GMT) No. of bitstreams: 1
gabriellacastrobarbosacosta.pdf: 2243060 bytes, checksum: 0aef87199975808e0973490875ce39b5 (MD5) / Made available in DSpace on 2017-06-01T11:50:00Z (GMT). No. of bitstreams: 1
gabriellacastrobarbosacosta.pdf: 2243060 bytes, checksum: 0aef87199975808e0973490875ce39b5 (MD5)
Previous issue date: 2013-02-27 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Uma forma de aprimorar a reutilização e a manutenção de uma família de produtos
de software é através da utilização de uma abordagem de Linha de Produtos de Software
(LPS). Em algumas situações, tais como aplicações científicas para uma determinada área,
é vantajoso desenvolver uma coleção de produtos de software relacionados, utilizando uma
abordagem de LPS. Linhas de Produtos de Software Científico (LPSC) diferem-se de Li
nhas de Produtos de Software pelo fato de que LPSC fazem uso de um modelo abstrato de
workflow científico. Esse modelo abstrato de workflow é definido de acordo com o domínio
científico e, através deste workflow, os produtos da LPSC serão instanciados. Analisando
as dificuldades em especificar experimentos científicos e considerando a necessidade de
composição de aplicações científicas para a sua implementação, constata-se a necessidade
de um suporte semântico mais adequado para a fase de análise de domínio. Para tanto,
este trabalho propõe uma abordagem baseada na associação de modelo de features e onto
logias, denominada PL-Science, para apoiar a especificação e a condução de experimentos
científicos. A abordagem PL-Science, que considera o contexto de LPSC, visa auxiliar
os cientistas através de um workflow que engloba as aplicações científicas de um dado
experimento. Usando os conceitos de LPS, os cientistas podem reutilizar modelos que
especificam a LPSC e tomar decisões de acordo com suas necessidades. Este trabalho
enfatiza o uso de ontologias para facilitar o processo de aplicação de LPS em domínios
científicos. Através do uso de ontologia como um modelo de domínio consegue-se fornecer
informações adicionais, bem como adicionar mais semântica ao contexto de LPSC. / A way to improve reusability and maintainability of a family of software products is
through the Software Product Line (SPL) approach. In some situations, such as scientific
applications for a given area, it is advantageous to develop a collection of related software
products, using an SPL approach. Scientific Software Product Lines (SSPL) differs from
the Software Product Lines due to the fact that SSPL uses an abstract scientific workflow
model. This workflow is defined according to the scientific domain and, using this abstract
workflow model, the products will be instantiated. Analyzing the difficulties to specify
scientific experiments, and considering the need for scientific applications composition for
its implementation, an appropriated semantic support for the domain analysis phase is
necessary. Therefore, this work proposes an approach based on the combination of feature
models and ontologies, named PL-Science, to support the specification and conduction
of scientific experiments. The PL-Science approach, which considers the context of SPL
and aims to assist scientists to define a scientific experiment, specifying a workflow that
encompasses scientific applications of a given experiment, is presented during this disser
tation. Using SPL concepts, scientists can reuse models that specify the scientific product
line and carefully make decisions according to their needs. This work also focuses on the
use of ontologies to facilitate the process of applying Software Product Line to scientific
domains. Through the use of ontology as a domain model, we can provide additional
information as well as add more semantics in the context of Scientific Software Product
Lines.
|
4 |
Reqsys-MDD: uma ferramenta para mapeamento entre modelos de features e requisitos em linhas de produto de softwareSousa, Lidiane Oliveira dos Santos 23 May 2012 (has links)
Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1
LidianeOSS_DISSERT.pdf: 4948473 bytes, checksum: f3f2d84880d3d969d6a1a9ec6252b0ff (MD5)
Previous issue date: 2012-05-23 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / The approach Software Product Line (SPL) has become very promising these days, since it
allows the production of customized systems on large scale through product families. For the
modeling of these families the Features Model is being widely used, however, it is a model
that has low level of detail and not may be sufficient to guide the development
team of LPS. Thus, it is recommended add the Features Model to other models representing
the system from other perspectives. The goals model PL-AOVgraph can assume this
role complementary to the Features Model, since it has a to context oriented language of
LPS's, which allows the requirements modeling in detail and identification of crosscutting
concerns that may arise as result of variability. In order to insert PL-AOVgraph in
development of LPS's, this paper proposes a bi-directional mapping between PL-AOVgraph
and Features Model, which will be automated by tool ReqSys-MDD. This tool uses the
approach of Model-Driven Development (MDD), which allows the construction of systems
from high level models through successive transformations. This enables the integration of
ReqSys-MDD with other tools MDD that use their output models as input to other
transformations. So it is possible keep consistency among the models involved, avoiding loss
of informations on transitions between stages of development / A abordagem de Linha de Produto de Software (LPS) tem se tornado bastante promissora nos
dias de hoje, uma vez que permite a produ??o de sistemas customizados em larga escala,
atrav?s de fam?lias de produtos. Para a modelagem destas fam?lias o Modelo de Features tem
sido muito utilizado, no entanto, se trata de um modelo que apresenta baixo n?vel de
detalhamento, podendo n?o ser suficiente para orientar a equipe de desenvolvimento da LPS.
Dessa forma, ? recomend?vel agregar o Modelo de Features a outros modelos que
representem o sistema sob outras perspectivas. O Modelo de Metas PL-AOVgraph pode
assumir esta fun??o complementar ao Modelo de Features, uma vez que possui uma
linguagem voltada para o contexto das LPS s, que permite a modelagem de requisitos de
forma detalhada e a identifica??o de caracter?sticas transversais, que podem surgir em
decorr?ncia da variabilidade. Com o objetivo de inserir PL-AOVgraph no processo de
desenvolvimento das LPS s, este trabalho prop?e um mapeamento bi-direcional entre PLAOVgraph
e Modelo de Features, que ser? automatizado pela ferramenta ReqSys-MDD. Esta
ferramenta utiliza a abordagem de Desenvolvimento Orientado a Modelos (Model-Driven
Development MDD), que permite a constru??o de sistemas a partir de modelos de alto n?vel,
atrav?s de transforma??es sucessivas. Isto possibilita a integra??o de ReqSys-MDD com
outras ferramentas MDD que utilizem seus modelos de sa?da como entrada para outras
transforma??es. Assim, ? poss?vel manter a consist?ncia entre os modelos envolvidos,
evitando a perda de informa??es nas transi??es entre as etapas de desenvolvimento
|
Page generated in 0.1265 seconds