Trnsformando Mapas Mentais em Modelos Conceituais PDF

RevistaBrasileirade
AdministraoCientfica,
Aquidab,v.3,n.2,Ago2012.
TRANSFORMANDO MAPAS MENTAIS EM MODELOS

CONCEITUAIS DE INFORMAO
ISSN2179684X
SEO:Artigos
TEMA:SistemasdeInformao
RESUMO
A engenharia de requisitos um fator crtico de sucesso em projetos de
Sistemas de Informao. Recentes pesquisas relatam evidncias que parte
desta dificuldade encontra-se no entendimento dos requisitos do sistema.
Ou seja, existem problemas entre os especialistas do domnio, aquele que
entende do negcio, e o desenvolvedor, profissional da rea de Tecnologia
da Informao. Para minimizar esse problema, este artigo explorou a
hiptese de que a utilizao de uma tcnica criativa e gil de modelagem,
por meio da adoo de mapas mentais, pudesse trazer um suporte
cognitivo e eficaz para a obteno mais rpida de modelos de requisitos
mais fidedignos a realidade levantada pelos especialistas de domnio.
Deste modo, o objetivo deste artigo foi apresentar um mecanismo de
transformao de mapas mentais para os modelos de requisitos, mais
especificamente no modelo conceitual de informao, a partir de tcnicas
de engenharia orientada a modelos. A ideia central apropriar-se das
caractersticas cognitivas do mapa mental para auxiliar aos projetistas de
sistemas a confeccionarem seus modelos de forma mais sistemtica,
servindo inclusive, como um artefato de auxlio na compreenso do
domnio do sistema.
PALAVRAS-CHAVES: Mapas Mentais; Transformao;
Conceituais de Informao; Modelos de Requisitos.
Modelos
TRANSFORMING MENTAL MAPS IN CONCEPTUAL

MODELS OF INFORMATION
ABSTRACT
The requirements engineering is a critical success factor in software
projects. Recent research studies report evidence that, one reason why
resilience engineering is often not used successfully, part of this difficulty
lies in understanding what the system requirements are. That is to say,
there are problems between domain experts, those who understand the
business, and developers, the professionals in the field of Information
Technology. To minimize this problem, this paper explored the hypothesis
that the use of a creative and agile modelling technique, by means of
adopting mind maps, could bring cognitive and effective support that would
more rapidly obtain requirements models that are more reliable with regard
to the reality surveyed by domain experts. Thus, this paper sought to put
forward a mechanism for transforming mind maps into requirements
models, more specifically in the conceptual model for information, based on
model-driven engineering. The central idea is to take the cognitive
characteristics of the mind map to help software designers to fashion their
models more systematically, including these serving as an artifact that will
aid understanding of the system domain.
KEYWORDS: Mind Maps; Transforming; Conceptual Model for Information;
Requirements Models.
RevistaBrasileiradeAdministraoCientficaumapub.daEscolaSuperiordeSustentabilidade
RuaDr.JosRollembergLeite,120,BairroBugio,CEP49050050,Aquidab,Sergipe,Brasil
Site:www.arvore.org.brContato:contato@arvore.org.brTelefone(79)99798991
AnaisdoSimpsioBrasileirode
TecnologiadaInformao(SBTI2012)
DOI:10.6008/ESS2179684X.2012.002.0007
FernandoJoseAraujoWanderley
UniversidadedePernambuco,Brasil
http://lattes.cnpq.br/0508472049376625
fjaw@ecomp.poli.br
DenisSilvadaSilveira
UniversidadeFederaldePernambuco,
Brasil
http://lattes.cnpq.br/3799501798859187
dsilveira@ufpe.br
Recebido:10/06/2012
Aprovado:15/08/2012
Avaliadoanonimamenteemprocessodeparescegas.
Referenciarassim:
WANDERLEY,F.J.A.;SILVEIRA,D.S..
Transformandomapasmentaisem
modelosconceituaisdeinformao.
RevistaBrasileiradeAdministrao
Cientfica,Aquidab,v.3,n.2,p.105122,
2012.
WANDERLEY,F.J.A.;SILVEIRA,D.S.
INTRODUO
Segundo estudo realizado pelo Standish Group (2011), cerca de 66% dos Sistemas de
Informao (SI) desenvolvidos no atenderam as expectativas dos usurios no que se refere s
suas funcionalidades e comportamentos. Em Brooks (1987) j destacava que a parte mais difcil
na construo de um sistema entender, compreender e decidir precisamente o que se vai
construir. Porm, nenhuma outra parte do processo de desenvolvimento de SI to difcil como
estabelecer uma comunicao alinhada entre o especialista do domnio, aquele que entende do
negcio, e o desenvolvedor, profissional da rea de Tecnologia da Informao (TI), que consolide
os detalhes tcnicos do negcio em mesmo documento (os requisitos). Segundo alguns autores
(PRESSMAN, 2009; SOMMERVILLE, 2010), nenhuma atividade do processo de desenvolvimento
de um sistema gera tanto prejuzo se realizada de forma errada, como a fase de levantamento dos
requisitos.
Uma das dificuldades dessa rea encontra-se na sua multidisciplinaridade, que impe s
organizaes a necessidade de se estabelecer um vocabulrio comum que transite tanto no
universo dos especialistas do domnio como na rea de TI. No entanto, na maioria das
organizaes o que realmente ocorre uma diviso lingustica entre os envolvidos (Figura).
Figura 1: Diviso Lingustica entre os Especialistas de Domnio e os Profissionais de TI.
Em meio a essa diviso lingustica, os especialistas de domnio descrevem as suas

necessidades; e, por sua vez, os profissionais da rea de TI tentam traduzi-las em requisitos
funcionais, replicando suas dvidas com termos tcnicos que obviamente, na maioria das vezes,
no so entendidos pelos especialistas.
Essa falha na comunicao normalmente acarreta em perda de informaes sobre o
negcio que dever ser modelado. Essa perda de informao produz um gap semntico, que
representa a dificuldade recorrente no processo de modelar o mundo real do domnio do problema
o ambiente organizacional em um conjunto de modelos sistmicos, que seja o mais fiel na
representao do domnio.
Neste contexto, o presente artigo utiliza uma tcnica cognitiva e criativa de modelagem, a
partir da adoo de Mapas Mentais (BUZAN e BUZAN, 2003), que traz um suporte cognitivo e
RevistaBrasileiradeAdministraoCientficav.3n.2Agostode2012
P g i n a |106
Transformandomapasmentaisemmodelosconceituaisdeinformao
eficaz para a obteno de uma linguagem ubqua, que transmita o conhecimento atrelado ao
domnio, traduzindo um entendimento comum entre os Projetistas de Software e os Especialistas
de Domnio (Figura).
Figura 2: Representao da Linguagem Ubqua Entre as reas.
Assim, o objetivo principal deste artigo propor um mtodo que utiliza modelos (mapas)
mentais (BUZAN, 2003), apropriando-se de suas caractersticas simples e cognitivas, para facilitar
a comunicao com os especialistas de domnio; e simplificar a modelagem de domnio e os seus
comportamentos comuns e variveis, tornando este processo mais gil e eficaz, para os
projetistas de software.
A Figura, ilustra esse mtodo que possibilita capturar ideias no estruturadas e vagas,
oriundas dos especialistas, para transform-las de forma semiautomtica (atravs de tcnicas
de Engenharia Orientada a Modelos) no Modelo Conceitual de Informao (LARMAN, 2004). A
aplicao desse tipo transformao tem como vantagem a garantia na consistncia entre os
modelos.
Figura 3: Transformando Ideias No Estruturadas em Modelos Estruturados.

Fonte: Adaptado de Hiranabe (2008).
O presente artigo encontra-se estruturado nas seguintes sees: a Seo 2, a seguir, ir

abordar o referencial terico necessrio para o entendimento da abordagem proposta neste artigo;
a Seo 3 apresenta o mtodo de transformao definido a partir das regras de mapeamento; e,
por fim, a Seo 4 com as consideraes finais.
P g i n a |107
REFERENCIAL TERICO
Mapas Mentais
O Mapa Mental um diagrama utilizado para conectar palavras, ideias a um conceito

central, utilizado para visualizar, classificar, estruturar conceitos, utilizado tambm para se gerar
novas ideias (BUZAN e BUZAN, 2003). Este modelo mental, ainda segundo os autores, usado
como um recurso que canaliza a criatividade, por se apropriar do uso de todas as habilidades
relacionadas a ela, sobretudo a imaginao, a associao de ideias e a flexibilidade. De acordo
com Biktimirov e Nilson (2006) os mapas mentais podem ser definidos como uma representao
no linear das ideias e seus respectivos relacionamentos.
Para ilustrar esse conceito, o mapa mental na Figura 4, apresenta a modelagem de um
domnio de gerenciamento de jornadas para uma cooperativa de txis. O esquema conceitual para
este sistema ser detalhado nas sees seguintes.
Figura 4: Sistema de Gerenciamento de Jornada de uma Cooperativa de Txis.
Neste artigo, o mapa mental utilizado com o propsito de representar um mapa cognitivo,
tendo como objetivo extrair, estruturar e organizar o conhecimento ou domnio de forma espacial.
Alguns trabalhos (DOWNS, 1973; KITCHIN, 1994) ressaltam que esse tipo de representao
facilita a mente humana no entendimento das informaes, reduzindo a carga cognitiva para a
absoro do conhecimento ou domnio. Neste contexto, o mapa mental foi aqui empregado com o
intuito de facilitar a comunicao e simplificar a modelagem de termos, entidades, relacionadas ao
domnio de um sistema de informao, tornando este processo de anlise do domnio um
processo mais inclusivo, para que Especialistas de Domnio possam expressar e projetar os
conceitos de seu domnio de forma mais gil (simples) e eficaz.
Vrias tcnicas e ferramentas derivadas dos modelos mentais tm sido atualmente
consideradas tanto pela academia quanto pela indstria, como uma poderosa ferramenta para
gerenciar o processo de elicitao dos requisitos em um contexto de desenvolvimento gil
(JAAFAR, 2009; CHENAL, 2008 e HIRANABE, 2008). Em (MAHMUD, 2011) o autor ressalta bons
resultados na coleta de requisitos em um contexto gil atravs de um experimento com grupos
com conhecimento em mapas mentais e sem o conhecimento de mapas mentais. Ainda dentro
P g i n a |108
deste mesmo contexto, alguns autores (LARMAN, 2003; AMBLER, 2002), introduzem a ideia de
utilizar mapas mentais como uma das prticas geis para obter e representar os requisitos.
Modelagem Conceitual de Informao
A modelagem conceitual de informao consiste na representao das entidade/objetos,

suas caractersticas e seus relacionamentos no contexto de determinado ambiente. Esta
representao deve ser independente do uso de tcnicas de implementao, tecnologias ou
dispositivos fsicos (LARMAN, 2004). Dentro do contexto de Sistemas de Informao, Maxey
(2002) afirma que o modelo conceitual est associado ao uso de abstraes de um domnio ou
conceito atravs do gerenciamento de informaes. As atividades parceiras deste processo de
abstrao consideram o domnio do usurio, o modelo lgico e o modelo fsico do produto a ser
desenvolvido (Figura 5).
Figura 5: A importncia de Modelos Conceituais. Fonte: Adaptado de Maxey (2002).
Para se construir um produto ou sistema para um propsito especfico, preciso que se

desenvolva um modelo conceitual apropriado s suas necessidades (FOWLER, 1997). Para que o
sistema execute funes, preciso ter algum conhecimento sobre o domnio e sobre as funes
que o mesmo ter que executar. A esse conhecimento d-se o nome de esquema conceitual.
Segundo (OLIV, 2007), para desenvolver um Sistema de Informao necessrio e suficiente
definir seu esquema conceitual.
A representao do ambiente observado, usando-se a modelagem conceitual, ocorre
atravs de entidades ou classes, suas caractersticas e seus relacionamentos. Uma
entidade/classe uma categoria atribuda ao conjunto de objetos existentes neste ambiente que
esto agrupados em funo de suas semelhanas. Os objetos representados passam a ser
denominados como instncias destas entidades (SCHMITZ e SILVEIRA, 2000). Ao conjunto de
caractersticas que definem uma entidade/classe d-se nome de atributos (LARMAN, 2004;
P g i n a |109
SCHMITZ e SILVEIRA, 2000). Cada atributo representa uma caracterstica comum dos objetos
individualizados pertencentes mesma entidade.
Os objetos no existem em um determinado ambiente de forma isolada, eles relacionamse entre si para definirem o ambiente que est sendo representado. De acordo com os tipos de
objetos envolvidos no relacionamento, este pode ser classificado em relacionamento entre objetos
de diferentes tipos (os mais comuns) e relacionamentos entre objetos do mesmo tipo. No
relacionamento entre objetos de tipos diferentes, instncias de uma entidade interagem com
instncias de outra entidade. No contexto deste artigo foi utilizado o Diagrama de Classes
(DC/UML) (OMG, 2005) para definio dos termos de domnio (entidades) e seus
relacionamentos.
Dentre os diagramas da UML (Unified Modeling Language), o DC/UML o diagrama mais
importante (OMG, 2005). Ele descreve a estrutura esttica dos objetos em um sistema e os vrios
tipos de relacionamentos estticos que existem entre eles, com objetivo de representar o
esquema conceitual do Sistema de Informao. Para o presente artigo, sero tratados apenas os
relacionamentos de associao simples, composio e agregao. Sendo esses suficientes para
representar a forma como as entidades de um domnio se comunicam para criar ou alterar os
estados umas da outras. A Figura 6 ilustra um exemplo com um DC/UML representando o mesmo
domnio do modelo mental da Figura 4.
Figura 6: DC/UML para um Sistema de Gerenciamento de Jornada de uma Cooperativa de Txis.
Na prxima seo sero apresentados os conceitos relacionados tcnica utilizada para

transformar os modelos de mapas mentais (Figura 4) em modelos conceituais de informao,
representado aqui pelo DC/UML (Figura 6), de forma semiautomtica.
Engenharia Orientada a Modelos
Os modelos so utilizados por serem uma representao simplificada de algum conceito

ou domnio. E tem por objetivo, facilitar a observao, comunicao, manipulao e o
entendimento do comportamento do sistema (MELLOR et al., 2004). Na Engenharia Orientada a
Modelos (Model-Driven Engineering - MDE), que uma abordagem para o desenvolvimento de
software, os modelos so focados como entidades de primeira classe para o desenvolvimento de
P g i n a |110
sistemas (SCHMIDT, 2006). A utilizao de modelos na construo de sistemas complexos uma

forma de resolver a nossa limitada capacidade cognitiva visto que, em geral, no conseguimos
compreender o sistema em sua totalidade (PRESSMAN, 2009).
A proposta da MDE fazer com que os profissionais de TI no necessitem interagir
manualmente com todo o cdigo-fonte, podendo se concentrar em modelos de mais alto nvel,
deixando-o protegido das complexidades requeridas para o desenvolvimento nas diferentes
plataformas.
Dentre as principais vantagens da abordagem MDE apresentadas pelos autores
(DEURSEN, 1998; KLEPPE, WARMER, BAST, 2003; BAHNOT, 2005 e MERNIK, 2005)
destacam-se: i) produtividade - o tempo de desenvolvimento ser melhor aproveitado, pois ser
gasto na produo de modelos de mais alto nvel. Alm disso, um nico modelo pode gerar uma
grande quantidade e diversidade de cdigo; ii) interoperabilidade - cada parte do modelo pode ser
transformada em cdigo para uma plataforma diferente, resultando em um software que executa
em um ambiente heterogneo, porm mantendo a funcionalidade global; iii) comunicao - no
MDE, os diferentes profissionais possuem meios mais efetivos para comunicao, uma vez que
modelos geralmente so mais abstratos que o cdigo, no exigindo conhecimento tcnico relativo
plataforma. Especialistas do domnio tm um papel mais ativo no processo, podendo utilizar
diretamente os modelos para identificar mais facilmente os conceitos do negcio, enquanto
especialistas em computao podem identificar os elementos tcnicos.
Com o intuito de garantir a produtividade, a MDE enfatiza a necessidade de se ter modelos
produtivos, que possam ser automaticamente manipulados por programas. Para construir modelos
produtivos necessrios complement-los e formalmente defini-los. No contexto de MDE,
metamodelos so utilizados para construir uma definio formal dos modelos (KLEPPE,
WARMER, BAST, 2003).
Transformao entre Modelos
Com base nesta definio de metamodelos, que utiliza o conceito de metaclasses ou

metatipos (OMG, 2005), onde o conjunto de todas metaclasses de uma linguagem e os
relacionamentos entre elas constitui o metamodelo da linguagem, possvel implementar
transformaes entre modelos. Metamodelos e transformaes automticas de modelos so dois
conceitos chaves e crucias em MDE (KLEPPE, WARMER, BAST, 2003). Os modelos servem de
entrada para transformaes que iro gerar outros modelos ou cdigo-fonte. A transformao de
modelos, por sua vez, a gerao de um modelo-alvo, a partir de um modelo-fonte, atravs da
definio de regras de mapeamento estabelecidas entre seus metamodelos, conforme descrito
pela Figura 7.
P g i n a |111
Figura 7: Esquema de Transformao entre Modelos.

Fonte: Adaptado de Kleppe, Warmer e Bast (2003).
Desta forma, quando se fala em transformaes necessrio ter os seguintes conceitos

bem estabelecidos (KLEPPE, WARMER, BAST, 2003):
Uma transformao a gerao automtica de um modelo-alvo, dado um

modelo-fonte, de acordo com uma funo (regras) de transformao;
Uma definio de transformao um conjunto de regras de
transformao, que juntas descrevem como um modelo-fonte pode ser
transformado em um modelo-alvo;
Uma regra de transformao um mapeamento entre um elemento da
linguagem origem e outro elemento da linguagem destino.
importante tambm notar tambm que nem sempre possvel conseguir o automatismo
das transformaes. Para que isso seja possvel, necessrio que haja uma firme conexo
semntica entre os elementos do modelo, com regras claras e no ambguas (BROWN;
CONALLEN, 2005).
Linguagens de Transformao
Linguagens de transformao, segundo (KLEPPE, WARMER, BAST, 2003), uma

linguagem que define operacionalmente como a transformao de um modelo fonte, a um modelo
alvo realizado atravs da manipulao dos elementos de modelos, considerando os
metamodelos utilizados na construo dos mesmos. Estas linguagens podem ser definidas em
linguagens de transformao baseadas em: linguagens de programao (e.g, Java, Delphi, C++,
etc.), baseada em templates (e.g., eXtensible Stylesheet Language for Transformation - XSLT) ou
baseadas em modelos (e.g., Atlas Transformation Language - ATL, Query View Transformation QVT e o MOFScript).
No contexto deste artigo foi escolhida a linguagem de transformao MOFScript
(OLDEVIK, 2006). A linguagem MOFScript atende a todos os requisitos bsicos da OMG (Object
Management Group) e adiciona outros requisitos avaliados como importantes para uma linguagem
desse tipo, tais como suporte a mecanismos de controle de fluxo, interao com servios do
sistema operacional (e.g., consultar a data e hora do sistema), e um equilbrio entre facilidade de
uso e poder de expressividade dos domnios. A prxima seo apresenta os mapeamentos,
atravs de regras expressas em MOFScript, definidos entre os metamodelos dos mapas mentais
e DC/UML e a infraestrutura do ambiente de modelagem.
P g i n a |112
METODOLOGIA
Nesta pesquisa foi adotado o mtodo emprico, onde foram realizados estudos de casos
para caracterizar e dimensionar melhor o problema, coletando, dessa forma, mais evidncia sobre
a eficaz do mtodo de transformao aqui apresentado.
Durante a execuo de um estudo de caso, dados so coletados e, baseados na coleta
desses dados, anlises estatsticas so conduzidas de forma a permitir-se avaliar um determinado
atributo ou relacionamento entre diferentes atributos. Uma vantagem na conduo de estudos de
caso a facilidade de planejamento. Entretanto, uma desvantagem a dificuldade a dificuldade
em generalizar-se os resultados obtidos. Com isto, na condio de avalio futura deste trabalho,
est sendo planejado um projeto experimental (discutido na seo 4) a fim de conduzir anlises
empricas mais consistentes e capazes de generalizao de seus resultados.
No contexto da Tecnologia da Informao, o procedimento metodolgico baseado em
experimentos permitir a caracterizao e a viabilidade de uma determinada tecnologia em uso.
Atravs dessa caracterizao ser possvel determinar com nveis razoveis de segurana o que
funciona e o que no funciona sob devidas circunstncias.
Neste sentido, de acordo com KITCHENHAM et al. (2004), para atender esta finalidade, a
Tecnologia de Informao baseadas em Evidncias deve prover meios pelos quais melhores
evidncias provenientes das pesquisa possam ser integradas com experincia prtica, aplicada e
valores humanos no processo de tomada de deciso considerando o desenvolvimento e a
manuteno da tecnologia pretendida.
A Figura 8 apresenta o esquema com as atividades desta pesquisa, sendo a atividade
principal, a transformao, descrita em mais detalhes na prxima seo.
Figura 8: Esquema que Representa as Etapas do Mtodo aqui Apresentado.
P g i n a |113
A Transformao
No contexto desta dissertao, para a definio dos modelos utilizados na transformao,

foi utilizado os seus respectivos metamodelos para defini-los formalmente. Tomando-se como
base as definies formais de Siochos e Papatheodorou (2011), o metamodelo de um mapa
mental ser representado, neste trabalho, utilizando a linguagem Ecore, com base no framework
do EMF (Eclipse Modelling Framework), conforme ilustrado na Figura 9.
Figura 9: Metamodelo do Mapa Mental (SIOCHOS, 2011).
De acordo com esse metamodelo, um mapa mental est associado a uma estrutura e a um
contedo (conceito). Esta estrutura ento definida pela composio de ns e ligaes (entre os
ns), equivalente estrutura de um grafo. Os ns, por sua vez, podem ser classificados como ns
de grupo ou de folha, estabelecendo uma relao hierrquica entre eles. A notao o recurso
grfico utilizado para especificar ou diferenciar um n de outros do mapa. Esta notao pode ser
representada nas formas: (i) textual (semanticamente representada no XML - Extensible Markup
Language - da estrutura do mapa); (ii) um cone, podendo este, tambm, ser utilizado para
qualquer fim; ou (iii) uma imagem. A Figura 10, apresentada a seguir, ilustra o fragmento do
metamodelo alvo da transformao (DC/UML). Este metamodelo foi definido formalmente em
(OMG, 2005).
O metamodelo do DC/UML pode ser representado por dois elementos principais:
classificadores (e sua estrutura interna) e os relacionamentos entre classificadores. Estes
elementos so definidos na especificao da UML e possuem representaes especficas em
diagramas de classe. A seguir estes elementos so detalhados.
P g i n a |114
Figure 10: Um fragmento do Metamodelo do Diagrama de Classe (OMG, 2005).
Um classificador (Classifier) pode ser uma classe, uma interface ou um tipo bsico de
dados (DataType). Uma classe um descritor para um conjunto de objetos com comportamento,
estrutura e relacionamentos semelhantes (OMG, 2005). As classes so compostas por elementos
que definem seu estado (Attribute) e elementos que definem o seu comportamento (Operation).
Uma interface especifica um comportamento a ser seguido pelas classes que a implementam.
Este comportamento definido por um conjunto de operaes. Um tipo bsico de dados descreve
um conjunto de valores sem identidade, correspondendo normalmente a nmeros, cadeias de
caracteres, data e hora (OMG, 2005).
O DC/UML possui vrios relacionamentos como associao (associao simples,
agregao e composio), dependncia, herana e realizao, porm no contexto deste trabalho,
as relaes de interesse sero as de associao (agregao, composio e associao simples).
Por serem os principais relacionamentos para um modelo conceitual sendo de natureza mais
conceitual.
Uma associao (Association) define um relacionamento semntico entre pelo menos dois
classificadores. Este relacionamento possui algumas propriedades, inerentes aos participantes da
ligao, que determinam sua natureza. As propriedades mais importantes so multiplicidade,
navegabilidade, indicador de agregao, papel e visibilidade. Tais propriedades dizem respeito
estrutura esttica dos elementos participantes da associao. Outra propriedade da associao
o indicador de agregao. Este indicador especifica se a instncia de um participante (o todo)
composto por (composio) ou agrega (agregao) elementos do outro participante (a parte),
constituindo assim uma associao todo-parte entre as classes.
Porm, com o objetivo de mapear os principais elementos relacionados aos modelos
conceituais (as entidades e seus atributos), optamos em estender o metamodelo do mapa mental.
A extenso realizada consistiu na aplicao do padro de projeto State (GAMMA et al., 1995), que
P g i n a |115
possibilitou refletir os estados de um n no mapa. Visto que, em um mapa mental, um n pode

estar em um estado de folha (atributo) ou grupo (classe), conforme ilustra a Figura 11.
Figura 11. Extenso no Metamodelo de Mapa Mental.
Regras de Transformao
Esta seo detalha as regras que foram utilizadas no processo de transformao entre os
metamodelos referenciados. A saber:
Regra 1: O n central de um mapa mental sempre ser transformado para uma classe (Figura
12).
Figura 12: N central mapeado em uma Classe.
Esta regra foi implementada em MOFStript da seguinte forma:

1 mm.map::insertRootClass() {
2 var rootNode:mm.node = self.node.first()
3
4 var clazz:uml.Class = new uml.Class(name=rootNode.TEXT)
5
6 uml.packagedElement.add(clazz)
7
8 rootNode.insertClasses(clazz)
9
10 rootNode.insertAttributes(clazz)
11
12 }
P g i n a |116
De acordo com a listagem da definio da regra 1, a linha 2 define a instncia de um objeto

denominado rootNode, em que ser atribudo a ele, a instncia relacionada ao primeiro n do
modelo do mapa mental (self.node.first). Na linha 4 definido um objeto clazz do tipo uml.Class,
ou seja, um objeto criado a partir das definies do metamodelo UML, em que a este objeto
atribudo uma instncia do mesmo tipo (uml.Class) em que o construtor recebe o nome do n
central definido como parmetro como o nome da classe. Em seguida, na linha 6, a classe
adicionada como elemento do pacote. A linha 8 faz referncia a chamada de uma funo
(detalhada a seguir) em que a classe adicionada ao diagrama, bem como na linha 10, que trata
de outra chamada de uma funo que adiciona atributos, no marcados com estados (Entity)
entidades do n central.
Regra 2: Para cada n, diferente do n central, definido com o estado de Entity, representados
com a respectiva notao, ele ser transformado para uma classe (Figura 13).
Figura 13. Ns com Estado de Entidade Mapeados para Classes.

1 mm.node::insertClasses(parentClass:uml.Class) {
2
3 var classes:List
4
5 self.node->forEach(n:mm.node) {
6
7
var isEntityState:Boolean = n.isEntityState()
8
9
if (isEntityState)
10
{
11
var clazz:uml.Class = new uml.Class(name=n.TEXT)
12
13
n.insertClasses(clazz)
14
n.insertAttributes(clazz)
15
classes.add(clazz)
16
17
uml.packagedElement.add(clazz)
18
}
19 }
20
21 classes->forEach(clazz:uml.Class){
22
insertAggregation(parentClass, clazz)
23 }
24
25 }
A especificao do MOFScript, apresentada anteriormente, percorre cada n definido no

mapa (self.node->forEach(n:mm.node)), verificando se o n est no estado de Entity, conforme
P g i n a |117
procedimento isEntityState, definida na linha 7. Este procedimento booleano executa uma

verificao semntica do n, analisando se o valor da notao textual, atribuda para o cone
representado, <<list>>, conforme a linha 2 da listagem que segue.
1 mm.node::isEntityState():Boolean {
2
var icon:List = self.icon->select(i:mm.icon | i.BUILTIN.equals("list"))
3
return (icon.size() > 0)
4}
Analisado o estado do n como Entity, (linha 9 da especificao da regra), a funo

principal define o nome da classe atravs de seu construtor, obtido a partir do nome do n (linha
11), e ento a atribui ao pacote default do diagrama (linhas 13 a 17).
Pode-se observar que na linha 21, existe outro procedimento responsvel por inserir a
relao de agregao. Esta relao de agregao (linha 9) determinada quando, dois ns (pai e
filho), estejam ambos anotados com o estado Entity. Neste procedimento definida a classe de
origem e destino da relao, com multiplicidades padro de valor um (1), de mnimo e de mximo
(linha 8), conforme especificao que segue.
1 insertAggregation(fromClass:uml.Class, toClass:uml.Class) {
2 var association:uml.Association = new uml.Association()
3
4 association.name = fromClass.name + '_' toClass.name
5
6 var from:uml.Property = addDefaultMultiplicity(fromClass)
7
8 var to:uml.Property = addDefaultMultiplicity(toClass)
9 to.aggregation = uml.AggregationKind.shared
10
11 association.navigableOwnedEnd.add(to)
12
13 association.ownedEnd.add(from)
14 association.ownedEnd.add(to)
15
16 uml.packagedElement.add(association)
17 }
Regra 3: Para cada n, diferente do n central, que no estiver com a notao Entity e filho de um
n do tipo entidade, ser transformado para um atributo (Figura 14).
Figura 14: Mapeamento dos Atributos.
P g i n a |118

1 mm.node::insertAttributes(element:uml.StructuredClassifier) {
2 self.node->forEach(n:mm.node) {
3
4
var isNotEntityState:Boolean = !n.isEntityState()
5
6
if (isNotEntityState)
7
{
8
var attribute:uml.Property = new uml.Property()
9
attribute.name = n.TEXT
10
element.ownedAttribute.add(attribute)
11
}
12 }
13 }
A funo definida na especificao anterior analisa todos os ns definidos no mapa,

verificando, por meio da funo isNotEntityState, se os ns no esto definidos com o estado de
Entity (linha 4). Este procedimento executa uma verificao inversa ao analisado pelo
procedimento citado na regra 2. Em outras palavras, o procedimento verifica se o n no esta
definido com semntica da notao textual igual a <<list>>. Uma vez definido como n no estado
de Attribute, a funo instancia um objeto do tipo uml.Property, identificado por attribute (linha 8).
O atributo recebe o nome definido no n do mapa (linha 9), e ento atribudo ao elemento
passado como parmetro inicial da funo, que na maioria das vezes uma classe.
Regra 4: Cada relao binria entre dois ns ser transformada em uma associao do tipo
agregao, conforme Figura 15.
Figura 15: Mapeamento de Relao de Ns para Agregao.

1 insertAggregation(fromClass:uml.Class, toClass:uml.Class) {
2
var association:uml.Association =.new uml.Association()
3
association.name = fromClass.name + - toClass.name
4
var from:uml.Property = addDefaultMultiplicity(fromClass)
5
var from:uml.Property = addDDefaultMultiplicity(toClass)
6
to.aggregation = uml.Aggregation.shared
7
association.navigableOwnedEnd.add(to)
8
association.ownedEnd.add(from)
9
association.ownedEnd.add(to)
10
uml.packagedElement.add(association)
11 }
P g i n a |119
Aps a gerao do DC/UML (Figura 15), um profissional da rea de TI dever refinar o

modelo gerado. Para tal, sugerido que ele atribua os tipos de dados dos atributos; valide as
relaes geradas e atribua s multiplicidades as associaes, tornando o modelo mais consistente
ao domnio (Figura 16). Este refinamento possibilita o profissional de Tecnologia, por exemplo, a
identificar que Jornada uma classe associativa, uma vez que, a mesma s se concretiza pela
associao existente entre o Motorista e o Veculo no explicitada no mapa mental. A Figura 16
ilustra o modelo final aps o esse refinamento, porm, interessante ressaltar que, o modelo
apresentado na Figura 15 no se encontra errado.
Figura 16: Modelo Conceitual (DC/UML) Estruturado.
CONSIDERAES FINAIS
Por lidar com diferentes stakeholders e as diferentes expectativas e pontos de vistas a

respeito de um mesmo sistema, o processo de modelagem dentro do contexto da Engenharia de
Requisitos, precisa ser realizado na sua forma mais eficiente possvel, evitando ambiguidades e
divergncias, em fases inicias do projeto. sabido que, um modelo eficaz est diretamente ligado
capacidade que este modelo tem de comunicar-se com todos os envolvidos no processo de sua
confeco, obtendo-se um entendimento onipresente do domnio deste sistema.
Foi neste contexto, que se caracterizou o principal objetivo deste trabalho: definir modelos
simples, de fcil uso, e cognitivos, de fcil entendimento, para a modelagem de artefatos de
requisitos. Mais precisamente os modelos conceituais de informao (DC/UML).
Tomando-se como base nas definies de Ambler (2002) para modelagem gil de
requisitos, o referente trabalhou props a formalizao e utilizao de mapas mentais, como o
modelo fonte para a transformao para os modelos de requisitos (CD/UML). Desta forma, este
artigo contribuiu diretamente com a definio de um mtodo para transformar mapas mentais de
modelos de requisitos.
O estgio atual desta pesquisa busca como trabalho futuro, alm da execuo do
experimento referenciado na seo anterior, evoluir esta transformao para um conjunto de
regras que possam ser reusadas ou especializadas para outros modelos, por exemplo, os
modelos de features.
P g i n a |120
REFERNCIAS
AMBLER, S. W.. Agile modeling: effective practices for extreme programming and the unified process.
2002.
BAHNOT, V.; PANISCOTTI, D.; ROMAN, A.; TRASK, B.. Using domain-specific modeling to develop
software defined radio components and applications. In: OOPSLA WORKSHOP ON DOMAIN-SPECIfiC
MODELING, 5. Anais. San Diego: 2005. p.33-42.
BIKTIMIROV, E. N.; NILSON, L. B.. Show them the money: using mind mapping in the introductory finance
course. Journal of Financial Education, v.32, p.72-86, 2006.
BROOKS, F. P.. No silver bullet-essence and accidents of software engineering. University or North Carolina
at Chapel Hill, Computer Magazine, April, 1987.
BROWN, A. W.; CONALLEN, J.. An introduction to model-driven architecture. Part III: How MDA affects
the iterative development process, 2005.
BUZAN, T.; BUZAN, B.. The mind map book. London: BBC, 2003.
CHENAL D.. Mind mapping improves software requirements quality: communication and traceability.
Tech Brief, QA Vantage, 2008.
CZARNECKI, K., KIM, C. H. P.; KALLEBERG, K. T.. Feature models are views on ontologies. In:
SOFTWARE PRODUCT LINE CONFERENCE: SPLC 2006. Anais. Baltimore: IEEE CS, 2006.
DEURSEN, A. V.; KLINT, P.. Little languages: little maintenance. Journal of Software Maintenance, v.10,
n.2, p.75-92, 1998.
DOWNS, R. G.; STEA D.. Image & environment: cognitive mapping and spatial behavior. 1973.
EMF. The eclipse modeling framework (EMF) overview. Disponvel:
<download.eclipse.org/tools/emf/scripts/docs.php?doc=references/overview/EMF.html>. Acesso: Ago 2012.
FOWLER, M.. Analysis patterns, reusable object models. Addison Wesley, 1997.
GAMMA, E. et al.. Design patterns: elements of reusable object-oriented software. Addison-Wesley, 1995.
HIRANABE, K.. Exploring user requirements through mind mapping: 2008. Disponvel:
<http://www.change-vision.com/en/ExploringUserRequirementsThroughMindMapping_Letter.pdf>. Acesso:
Mai 2012.
JAAFAR, J.. Collaborative mind map tool to facilitate requirement engineering (RE). Dissertao
(Mestrado em Cincias) Faculty of Engineering and Physical Science, 2009.
KLEPPE, A.; WARMER, J.; BAST, W.. MDA Explained: the model driven architecture: practice and promise.
Addison-Wesley, 2003. Object Technology Series
KITCHIN, R. M.. Maps cognitive: what are and why study them?. Psychology Journal, v.14, n.1-19, 1994.
LARMAN, C.. Applying UML and patterns: an introduction to object-oriented analysis and design and
iterative development. 3 ed. New York: Prentice-Hall, 2004.
MAHMUD, I.. Mind-mapping: an effective technique to facilitate requirements engineering in agile software
development. In: INTERNATIONAL CONFERENCE ON COMPUTER AND INFORMATION TECHNOLOGY:
ICCIT 2011, 14. Anais. Dhaka, Dec 2011.
MAXEY, C.. User interface design. First draft abril 2002. Disponvel:
<http://www.wpdesign.com/User_Interface_Design.html>. Acesso: Jan 2011.
P g i n a |121
MERNIK, M.; HEERING, J.; SLOANE, A. M.. When and how to develop domain-specific languages. ACM
Computing Surveys, v.37, n.4, p.316344, 2005.
OLDEVIK, J.. MOFScript user guide. Disponvel:
<http://www.planeteclipse.net/gmt/mofscript/doc/MOFScript-User-Guide.pdf> Acesso: Ago 2012.
OLIV, A.. Conceptual modeling of information systems. Springer, 2007.
OMG. Object Management Group. Unified Modeling Language (UML) Superstructure Specification.
Version 2.0, 2005. Disponvel: <http://www.omg.org/cgi-bin/doc? formal/05-07-04>. Acesso: Jan 2007.
PRESSMAN, R. S.. Software engineering: a practitioner's approach. 6 ed. McGraw-Hill, 2009.
SIOCHOS, V., PAPATHEODOROU, C.. Developing a formal model for mind maps. In: WORKSHOP ON
DIGITAL INFORMATION MANAGEMENT, 1. Anais. Greece, 2011.
SCHMIDT, D. C.. Guest editors introduction: model-driven engineering. IEEE Computer, v.39, n.2, p.25-31,
2006.
SCHMITZ, E. A.; SILVEIRA, D. S.. Desenvolvimento de software orientado a objetos. Rio de Janeiro:
Brasport, 2000.
SOMMERVILLE, I.. Software engineering. 9 ed. Pearson Addison Wesley, 2010.
STANDISH GROUP. Site oficial. Disponvel: <http://blog.standishgroup.com>. Acesso: Nov 2011.
P g i n a |122

Trnsformando Mapas Mentais em Modelos Conceituais PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Trnsformando Mapas Mentais em Modelos Conceituais PDF

Enviado por

Direitos autorais:

Formatos disponíveis

RevistaBrasileirade

TRANSFORMANDO MAPAS MENTAIS EM MODELOS

TRANSFORMING MENTAL MAPS IN CONCEPTUAL

Figura 1: Diviso Lingustica entre os Especialistas de Domnio e os Profissionais de TI.

Em meio a essa diviso lingustica, os especialistas de domnio descrevem as suas

Figura 2: Representao da Linguagem Ubqua Entre as reas.

Figura 3: Transformando Ideias No Estruturadas em Modelos Estruturados.

O presente artigo encontra-se estruturado nas seguintes sees: a Seo 2, a seguir, ir

O Mapa Mental um diagrama utilizado para conectar palavras, ideias a um conceito

Figura 4: Sistema de Gerenciamento de Jornada de uma Cooperativa de Txis.

Modelagem Conceitual de Informao

A modelagem conceitual de informao consiste na representao das entidade/objetos,

Figura 5: A importncia de Modelos Conceituais. Fonte: Adaptado de Maxey (2002).

Para se construir um produto ou sistema para um propsito especfico, preciso que se

Figura 6: DC/UML para um Sistema de Gerenciamento de Jornada de uma Cooperativa de Txis.

Na prxima seo sero apresentados os conceitos relacionados tcnica utilizada para

Engenharia Orientada a Modelos

Os modelos so utilizados por serem uma representao simplificada de algum conceito

sistemas (SCHMIDT, 2006). A utilizao de modelos na construo de sistemas complexos uma

Transformao entre Modelos

Com base nesta definio de metamodelos, que utiliza o conceito de metaclasses ou

Figura 7: Esquema de Transformao entre Modelos.

Desta forma, quando se fala em transformaes necessrio ter os seguintes conceitos

Uma transformao a gerao automtica de um modelo-alvo, dado um

Linguagens de transformao, segundo (KLEPPE, WARMER, BAST, 2003), uma

Figura 8: Esquema que Representa as Etapas do Mtodo aqui Apresentado.

No contexto desta dissertao, para a definio dos modelos utilizados na transformao,

Figura 9: Metamodelo do Mapa Mental (SIOCHOS, 2011).

Figure 10: Um fragmento do Metamodelo do Diagrama de Classe (OMG, 2005).

possibilitou refletir os estados de um n no mapa. Visto que, em um mapa mental, um n pode

Figura 11. Extenso no Metamodelo de Mapa Mental.

Figura 12: N central mapeado em uma Classe.

Esta regra foi implementada em MOFStript da seguinte forma:

De acordo com a listagem da definio da regra 1, a linha 2 define a instncia de um objeto

Figura 13. Ns com Estado de Entidade Mapeados para Classes.

Esta regra foi implementada em MOFStript da seguinte forma:

A especificao do MOFScript, apresentada anteriormente, percorre cada n definido no

procedimento isEntityState, definida na linha 7. Este procedimento booleano executa uma

Analisado o estado do n como Entity, (linha 9 da especificao da regra), a funo

Figura 14: Mapeamento dos Atributos.

Esta regra foi implementada em MOFStript da seguinte forma:

A funo definida na especificao anterior analisa todos os ns definidos no mapa,

Figura 15: Mapeamento de Relao de Ns para Agregao.

Esta regra foi implementada em MOFStript da seguinte forma:

Aps a gerao do DC/UML (Figura 15), um profissional da rea de TI dever refinar o

Figura 16: Modelo Conceitual (DC/UML) Estruturado.

Por lidar com diferentes stakeholders e as diferentes expectativas e pontos de vistas a

Você também pode gostar