Upload
phungthu
View
225
Download
1
Embed Size (px)
Citation preview
PUBLICAÇÕES TÉCNICAS 2/2005 COPPE/UFRJ Caixa Postal 68511 - CEP 21941-972 - Rio de Janeiro - RJ
Metamodelo de Características da Notação Odyssey-FEX: Descrição de Classes
Regiane Felipe de Oliveira, Ana Paula Blois, Aline Vasconcelos e Cláudia Werner
Junho 2005
Reuse Reuse Reuse Reuse Técnicas e Ferramentas de apoio à Reutilização de Software Financiamento CNPq
2
ÍNDICE
INTRODUÇÃO .................................................................................................................3 PACOTE PRINCIPAL ........................................................................................................4
1. EspaçoDeNomes ...............................................................................................4 2. Domínio ............................................................................................................5 3. Contexto............................................................................................................6 4. Pacote................................................................................................................7 5. Característica.....................................................................................................8 6. CaracterísticaDeEntidade.................................................................................11 7. CaracterísticaDeDomínio.................................................................................12 8. CaracterísticaConceitual ..................................................................................13 9. CaracterísticaFuncional ...................................................................................14 10. CaracterísticaTecnológica................................................................................15 11. CaracterísticaAmbienteOperacional.................................................................16 12. CaracterísticaTecnologiaDomínio....................................................................17 13. CaracterísticaTécnicaImplementação...............................................................18 14. TipoVariabilidade............................................................................................19
PACOTE RELACIONAMENTO .........................................................................................21 15. Relacionamento...............................................................................................21 16. Alternativo ......................................................................................................22 17. LigaçãoDeComunicação..................................................................................23 18. ImplementadoPor ............................................................................................24 19. Generalização..................................................................................................25 20. Associação ......................................................................................................26 21. Propriedade .....................................................................................................27 22. TipoAgregação................................................................................................28
PACOTE REGRACOMPOSIÇÃO .......................................................................................30 23. RegraComposição ...........................................................................................30 24. RegraComposiçãoInclusiva .............................................................................31 25. RegraComposiçãoExclusiva ............................................................................32 26. Expressão ........................................................................................................33 27. ExpressãoLiteral..............................................................................................34 28. AND................................................................................................................34 29. OR...................................................................................................................35 30. XOR................................................................................................................35 31. NOT................................................................................................................36
REFERÊNCIAS ..............................................................................................................37
3
INTRODUÇÃO
A Engenharia de Domínio (ED) é uma área da Engenharia de Software que tem como
principal objetivo desenvolver artefatos de software para uma família de aplicações, ou
domínio, de modo que estes possam ser reutilizados no desenvolvimento de aplicações deste
domínio (BRAGA, 2000). A ED incorpora uma etapa de Análise de Domínio que visa, entre
outras coisas, detectar e modelar variabilidades, isto é, um conjunto de características comuns
e variáveis entre as aplicações do domínio (PRIETO-DIAZ & ARANGO, 1991).
O ponto de partida para a representação de variabilidade em um domínio é o modelo
de características (features) (KANG et al., 1990). Um modelo de características representa as
características de uma família de sistemas em um domínio, as relações entre elas e suas
semelhanças e diferenças, também chamadas de variabilidades.
A notação Odyssey-FEX é uma notação para representação de variabilidade em
modelos de características, proposta no contexto do ambiente Odyssey (ODYSSEY, 2005). A
semântica dessa notação é formalizada por um metamodelo.
A fim de apoiar o usuário na compreensão e no bom uso da notação Odyssey-FEX,
este trabalho tem por objetivo fornecer uma descrição detalhada das classes que compõem o
seu metamodelo. Para facilitar a compreensão, as classes estão agrupadas em três pacotes: a)
Principal, que representa a parte da definição da taxonomia das características, b)
Relacionamento, que especifica propriedades dos relacionamentos existentes no modelo de
características; e c) Regras de Composição, que especifica as regras de dependência e
exclusividade entre as características de um modelo.
4
PACOTE PRINCIPAL
Figura 1- Metamodelo Odyssey-FEX: Principal
1. EspaçoDeNomes
Descrição
Um EspaçoDeNomes (Namespace) é um elemento em um modelo que contenha um conjunto
de elementos nomeados, e que podem ser identificados unicamente pelo nome (OMG, 2005).
Subclasses: Domínio, contexto, Pacote.
Atributos
- nome : String [1] – Referencia o nome do EspaçoDeNomes.
- Descrição : String [0..1] – Referencia a descrição do EspaçoDeNomes, se existir.
Associações
• característicaImportada : Característica [*] – Referencia as características presentes
em um EspaçoDeNomes, pertencentes a outro EspaçoDeNomes.
• característicaPrópria : Característica[*] - Referencia características presentes em
um EspaçoDeNomes, pertencentes ao próprio EspaçoDeNomes.
5
Restrições
[1] Todos os membros de um EspaçoDeNomes são distinguíveis dentro daquele
EspaçoDeNomes. (OMG, 2005)
Notação
Sem notação específica.
Exemplo
Características View.CellPhone
Structural View.CellPhone
Os exemplos acima se referem aos EspaçoDeNomes do ambiente Odyssey (Features View e
Structural View), onde, apesar do mesmo nome, o elemento CellPhone pode ser identificado
inequivocamente como uma característica ou uma classe, respectivamente.
2. Domínio
Descrição
Descreve uma coleção de problemas reais e/ou uma coleção de aplicações que compartilham
características comuns (PRIETO-DIAZ & ARANGO, 1991).
Superclasse: EspaçoDeNomes.
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Domínios podem conter contextos.
Notação
Sem notação específica.
Exemplo
Setor Agropecuário
Ambiente de Desenvolvimento de Software
Telefonia Celular
6
3. Contexto
Descrição
Representa um contexto da organização. Pode ser organizado em diagramas, que têm por
objetivo situar o domínio em relação ao seu escopo, limites, relacionamentos com outros
domínios de aplicação e principais atores envolvidos (BRAGA, 2000).
Superclasse: EspaçoDeNomes.
Atributos
- estereótipo : String [0..1] – Indica o estereótipo utilizado pelo contexto, se existir
Associações
• Características de um contexto podem se relacionar com características de outro
contexto.
Restrições
[1] Contextos pertencem obrigatoriamente a um Domínio.
[2] Contextos podem conter pacotes.
[3] Instâncias distintas da classe Contexto podem se relacionar entre si.
Notação
Contextos são representados por elipses, em cujo centro se encontra o nome do contexto. Um
contexto pode ainda conter estereótipos, apresentados entre os sinais
<< >>, como mostra a Figura 2:
Figura 2 - Representação de um contexto
Exemplo
Ensino
7
O exemplo acima se refere ao domínio de Ensino Colaborativo Suportado por Computador
(Computer Supported Cooperative Learning -CSCL), onde um pacote Ensino pode ser
dividido em três contextoos: Superior, Médio e Fundamental. As setas pontilhadas
representam a dependência entre os contextoos.
4. Pacote
Descrição
Um pacote é usado para agrupar elementos (tais como características), e fornece um
EspaçoDeNomes para os elementos agrupados (OMG, 2005).
Superclasse: EspaçoDeNomes.
Atributos
- estereótipo : String [0..1] – Indica o estereótipo utilizado pelo pacote, se existir.
Associações
Pacote pode ser uma agregação de outros pacotes.
Restrições
Sem restrições específicas.
Notação
Um pacote é representado como sugerido na UML, isto é, um retângulo grande com uma
"aba" no canto superior esquerdo do retângulo, como mostra a Figura 3.
Figura 3 - Representação de um pacote
Exemplo
8
5. Característica
Descrição
Representam conceitos e/ou capacidades do domínio. Captura a compreensão de usuários
finais e clientes a respeito das capacidades gerais das aplicações em um domínio (KANG et
al., 1990)
Subclasses: CaracterísticaDeEntidade, CaracterísticaDeDomínio e
CaracterísticaTecnológica
Atributos
- nome : String [1] – Referencia o nome da característica.
- camada: Integer [1] – Indica a camada de características do domínio à qual pertence a
característica, conforme proposto por Kang et al (2002).
Pode assumir os seguintes valores:
0 – Primeira Camada – Capacidades (Capabilities)
1 – Segunda Camada - Ambiente Operacional (Operational
Environment)
2 – Terceira Camada - Tecnologia de Domínio (Domain Technology)
3 – Quarta Camada - Técnica de Implementação (Implementation
Technique)
- estereótipo : String [0..1] – Indica o estereótipo utilizado pela característica, se existir.
- prioridade: Void - Indica o nível de importância daquela característica para o domínio que
está sendo modelado (BRAGA, 2000).
Pode assumir os valores “Alta”, “Media” ou “Baixa”.
- descrição : String [0..1] - Descrição detalhada da característica, incluindo restrições de uso
(BRAGA, 2000).
9
- sinônimo: String [*] – Outros nomes que identificam a característica (BRAGA, 2000).
- fontes : String [*] – Lista de fontes de onde a característica foi identificada (BRAGA,
2000).
- ehDefinida : Boolean – Indica se a característica é definida, isto é, características já
levantadas de um domínio, porém ainda não definidas através de use-
cases e/ou modelos conceituais (MILER, 2000). Default: true.
- ehOrganizacional : Boolean – Indica se a característica é organizacional, isto é,
características do modelo que têm apenas o intuito de facilitar o
entendimento ou organizar o domínio. Não possuem ligações concretas
com o uso real do domínio(MILER, 2000). Default: false.
- ehMandatoria : Boolean – Indica se a característica é mandatória no domínio, isto é, se a
característica estará presente em todas as aplicações derivadas do
domínio. Caso false, a característica é chamada de Opcional. Default:
true.
- ehExterna : Boolean – Indica se a característica é externa ao domínio, isto é, se pertence a
um domínio diferente daquela que está sendo modelado. Default: false.
- tipoVariabilidade : TipoVariabilidade [1] – Indica o tipo de variabilidade que a
característica apresenta. Pode assumir os valores “Invariante”,
“Variante” e “Ponto de Vaiação”.
Default: Invariante
Associações
• origin : Domínio [0..1] – Indica o domínio ao qual a característica pertence, quando
este é diferente do domínio que está sendo modelado.
Restrições
[1] Características que sejam Não-Definidas (Característica.ehDefinida = false) não podem
ser Organizacionais (Característica.ehOrganizacional = true), e vice versa.
[2] Características que não pertencem ao domínio que está sendo modelado são chamadas de
Características Externas (Característica.ehExterna = true)
[3] Características classificadas como Ponto de Variação (Característica.tipoVariabilidade =
pontoVariação) são caracterizadas no diagrama pelo relacionamento do tipo Alternativo,
como características de origem de tal relacionamento.
[4] Características classificadas como Variantes (Característica.tipoVariabilidade = variante)
são caracterizadas no diagrama pelo relacionamento do tipo Alternativo, como
10
características de destino de tal relacionamento.
[5] Características que tenham classificação de Variante (Característica.tipoVariabilidade =
variante) e Mandatória (Característica.ehMandatoria = true) devem ter um relacionamento
do tipo Alternativo com outra característica classificada como Ponto de Variação
(Característica.tipoVariabilidade = pontoVariação) NECESSARIAMENTE mandatória
(Característica.ehMandatoria = true).
[6] Características que tenham classificação de Variante (Característica.tipoVariabilidade =
variante) e Opcionais (Característica.ehMandatoria = false) podem ter um relacionamento
do tipo Alternativo com outra característica classificada como Ponto de Variação
(Característica.tipoVariabilidade = pontoVariação) que seja mandatória
(Característica.ehMandatoria = true). Neste caso, a obrigatoriedade do ponto de variação
indica que pelo menos uma das variantes ligadas a ele deve ser selecionada na aplicação.
[7] Características que tenham classificação de Ponto de Variação
(Característica.tipoVariabilidade = pontoVariação) e Opcionais
(Característica.ehMandatoria = false) devem ter um relacionamento do tipo Alternativo
com outras características classificadas como Variantes (Característica.tipoVariabilidade
= variante) NECESSARIAMENTE Opcionais (Característica.ehMandatoria = false)
[8] Características dependentes entre si não podem ser mutuamente exclusivas, e vice versa.
Notação
Além da notação específica de cada uma de suas subclasses, a classe Característica possui as
seguintes notações:
<<from Another Domain>> Característica Externa: é representada por um estereótipo indicando o Domínio ao qual a característica pertence.
Figura 4– Característica Não Definida
Característica Não Definida: é representada pelo símbolo de interrogação no canto superior esquerdo da característica, conforme mostra a Figura 4.
Figura 5– Característica Organizacional
Característica Organizacional : é representada por um símbolo no canto superior esquerdo da característica, conforme mostra a Figura 5
Figura 6– Característica Opcional
Características Opcionais: são representadas por uma linha tracejada, conforme mostra a Figura 6
?
����
11
Exemplo
O exemplo acima se refere ao domínio Agropecuário. A característica externa
Fiscalização pertence ao domínio Secretaria de Agricultura.
6. CaracterísticaDeEntidade
Descrição
São os atores do modelo. Entidades do mundo real que atuam sobre o domínio. Podem, por
exemplo, expor a necessidade de uma interface com o usuário ou de procedimentos de
controle (MILER, 2000).
Atributos
Sem atributos.
Associações
Sem associações específicas
Restrições
[1] Características de Entidade podem se relacionar com Ambiente Operacional
Características de Ambiente Operacional, Características de Tecnologia de Domínio, e
com Características de Domínio.
[2] Características de Entidade se relacionam via LigaçãoDeComunicação com as
Características de Domínio, que pertencem à primeira camada de características do
Característica Externa
Característica Opcional
Característica Organizacional
Característica Não-Definida
12
domínio, conforme proposto por Kang et al (2002) (Característica.camada = 0).
Notação
Características de Entidade são representadas por um retângulo, cujo fundo contém o ícone
mostrado na Figura 7. O nome da característica é centralizado no retângulo. Uma
Característica de Entidade pode ainda conter o estereótipo <<Actor >>.
Figura 7 - Ícone que representa uma Característica de Entidade
Exemplo
O exemplo acima se refere ao domínio de Máquinas de Processo e mostra o
relacionamento entre a Característica de Entidade“Gerente de Projeto” e a característica de
Domínio “Monitoramento de Processo”.
7. CaracterísticaDeDomínio
Descrição
Características intimamente ligadas à essência do domínio. Representam as
funcionalidades/conceitos do modelo e correspondem a casos de uso e componentes
estruturais concretos (MILER, 2000).
Superclasse: Característica.
Subclasses: CaracterísticaConceitual e CaracterísticaFuncional
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
13
[1] Características de Domínio pertencem à primeira camada de características do domínio,
conforme proposto por Kang et al (2002) (Característica.camada = 0)
Notação
Características de Domínio são representadas por um retângulo, cujo fundo contém o ícone
do Projeto Odyssey, como mostra a Figura 8. O nome da característica é centralizado no
retângulo. Uma Característica de Domínio pode ainda conter o estereótipo <<Conceptual >>
ou <<Functional >>, dependendo da sua classificação.
Figura 8 – Ícone do Projeto Odyssey
Exemplo
No exemplo acima, as características “Caixa Postal” e “Enviar Mensagens” são
características do domínio de telefonia celular.
8. CaracterísticaConceitual
Descrição
Características que representam os conceitos do domínio (BRAGA, 2000).
Superclasse: CaracterísticasDeDomínio.
Atributos
Sem atributos.
Associações
Sem associações específicas.
14
Restrições
Sem restrições específicas.
Notação
Uma Característica Conceitual é representada como uma Característica de Domínio, uma vez
que a primeira é subclasse da última. Além disso, um estereótipo <<Conceptual>> é utilizado
para definir esse tipo de característica.
Exemplo
No exemplo acima, a característica “Agenda” representa um conceito no domínio de
telefonia celular.
9. CaracterísticaFuncional
Descrição
Características que representam as funcionalidades do domínio (BRAGA, 2000).
Superclasse: CaracterísticaDeDomínio.
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
Sem restrições específicas.
Notação
Uma Característica Funcional é representada como uma Característica de Domínio, uma vez
15
que a primeira é subclasse da última. Além disso, um estereótipo <<Functional>> é utilizado
para definir esse tipo de característica.
Exemplo
No exemplo acima, a característica “Envio de Mensagens” representa uma funcionalidade no
domínio de telefonia celular.
10. CaracterísticaTecnológica
Descrição
Classe abstrata que agrupa os tipos de características propostos por Kang et al (2002), e que
complementam a camada conceitual com as camadas de Tecnologia de Domínio (Domain
Technology), Ambiente Operacional (Operational Environment) e Técnicas de
Implementação (Implementation Techniques).
Subclasses:CaracterísticaTecnologiaDomínio, CaracterísticaAmbienteOperacional,
CaracterísticaTecnicaImplementação
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Características tecnológicas não devem se relacionar com características conceituais.
Notação
Uma Característica Tecnológica não tem notação específica. A notação é determinada por
cada uma das subclasses.
Exemplo
Vide CaracterísticaTecnologiaDomínio, CaracterísticaAmbienteOperacional, e
CaracterísticaTecnicaImplementação.
16
11. CaracterísticaAmbienteOperacional
Descrição
Características que representam ambientes que uma aplicação do domínio pode usar e operar.
Superclasse: CaracterísticaTecnológica .
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Características de Ambiente Operacional pertencem à segunda camada de características
do domínio, conforme proposto por Kang et al (2002) (Característica.camada = 1).
Notação
Características de Ambiente Operacional são representadas por um retângulo, cujo
background contém o ícone mostrado na Figura 9. O nome da característicaé centralizado no
retângulo. Uma Característica de Ambiente Operacional pode ainda conter o estereótipo <<
Operational Environment >>.
Figura 9 - Ícone que representa uma Característica de Ambiente Operacional
Exemplo
Software e hardware que suportam o domínio.
17
O exemplo acima se refere ao domínio de telefonia celular, onde a característica “JAVA”,
pertencente à segunda camada de características, implementa o jogo representado pela
característica “Car Racer”, pertencente à primeira camada de características.
12. CaracterísticaTecnologiaDomínio
Descrição
Características que representam alternativas de implementação de serviços ou operações.
Podem, ainda, representar detalhes de implementação de mais baixo nível, específicos para o
contexto de um domínio.
Superclasse: CaracterísticaTecnológica
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Características de Tecnologia de Domínio pertencem à terceira camada de características
do domínio, conforme proposto por Kang et al (2002) (Característica.camada = 2).
Notação
Característica de Tecnologia de Domínio são representadas por um retângulo, cujo
background contém o ícone mostrado na Figura 10. O nome da característica é centralizado
no retângulo. Uma Característica de Tecnologia de Domínio pode ainda conter o estereótipo
<<Domain Technology >>.
18
Figura 10 - Ícone que representa uma Característica de Tecnologia de Domínio
Exemplo
Métodos de navegação no domínio de aviões
13. CaracterísticaTécnicaImplementação
Descrição
Características que representam funções ou técnicas genéricas que são usadas para executar
serviços, operações, e funções do domínio.
Superclasse: CaracterísticaTecnológica.
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Característica de Técnica de Implementação pertencem à quarta camada de características
do domínio, conforme proposto por Kang et al (2002) (Característica.camada = 3).
Notação
Característica de Técnica de Implementação são representadas por um retângulo, cujo fundo
contém o ícone mostrado na Figura 11. O nome da característica é centralizado no retângulo.
Uma Característica de Técnica de Implementação pode ainda conter o estereótipo <<
19
Implementation Technique >>.
Figura 11 - Ícone que representa uma Característica de Técnica de Implementação
Exemplo
O exemplo acima se refere ao domínio de telefonia celular. A característica “MergeSort” é
uma Característica de Técnica de Implementação, que representa o algoritmo de busca que
pode ser usado na aplicação
14. TipoVariabilidade
Descrição
TipoVariabilidade é uma classe do tipo “ennumeration”, que define literais que determinam o
tipo de variabilidade presente em uma Característica. Pode assumir os valores: “ponto de
variação”, “variante” ou “invariante”, onde
1 pontos de variação: são características que refletem a parametrização no domínio de
uma maneira abstrata. São configuráveis através das variantes.
2 variantes: são elementos NECESSARIAMENTE ligados a um ponto de variação, que
atuam como alternativas para se configurar aquele ponto de variação.
3 invariantes: são elementos “fixos”, que não são configuráveis no domínio.
Atributos
Sem atributos.
Associações
Sem associações específicas.
20
Restrições
Sem restrições específicas.
Notação
Sem notação específica.
Exemplo
Vide Característica
21
PACOTE RELACIONAMENTO
Figura 12 - Metamodelo Odyssey-FEX : Relacionamentos
15. Relacionamento
Descrição
Relacionamento é um conceito abstrato que especifica algum tipo de relacionamento entre
elementos (OMG, 2005). Classe abstrata.
Subclasses: Alternativo, Ligação de Comunicação, Implementado Por
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
Sem restrições específicas.
Notação
22
Um Relacionamento não tem notação específica. A notação é determinada por cada uma das
subclasses.
Exemplo
Vide Alternativo, Ligação de Comunicação e Implementado Por.
16. Alternativo
Descrição
Relacionamento existente entre um ponto de variação e suas variantes. Denota a pertinência
de uma variante a um determinado ponto de variação.
Superclasse: Relacionamento.
Atributos
Sem atributos.
Associações
• variante : Característica [1..*] – Referencia as características do tipo Variante que
fazem parte do relacionamento Alternativo
• pontoVariação : Característica [1] - Referencia a característica do tipo Ponto de
Variação que faz parte do relacionamento Alternativo
Restrições
[1] O relacionamento Alternativo só poderá ocorrer entre Características do tipo Variante
(Característica.tipoVariabilidade = variante) e Ponto de Variação
(Característica.tipoVariabilidade = pontoVariação)
Notação
O relacionamento Alternativo é representado por linhas simples que partem do Ponto
de Variação para as Variantes, interligadas por uma linha curva, como mostra a Figura 13
abaixo:
Figura 13 – Relacionamento Alternativo
23
Exemplo
O exemplo acima se refere ao domínio de Telefonia Celular. A característica “Cores no
Visor” representa um ponto de variação, enquanto as demais características representam suas
variantes, estando ligadas ao ponto de variação através de relacionamento Alternativo.
17. LigaçãoDeComunicação
Descrição
Relacionamento existente entre uma Característica do tipo Entidade e outras Características
do domínio. Denota interação de um ator com o domínio(MILER, 2000).
Superclasse: Relacionamento
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] O relacionamento Ligação de Comunicação só poderá ocorrer entre Características de
Domínio e Características de Entidade.
Notação
O relacionamento Ligação de Comunicação é representado por uma associação bidirecional,
com o estereótipo <<Communication Link>>.
Exemplo
24
O exemplo se refere ao domínio de Ambientes de Desenvolvimento de Software, e a
característica de Entidade “Especialista” se relaciona com a característica de Domínio
“Odyssey Light” através do relacionamento Ligação de Comunicação.
18. ImplementadoPor
Descrição
Relacionamento existente entre Características Tecnológicas e Características de Domínio ,
que se encontrem em camadas diferentes de organização das características : camada de
Capacidades (Característica.camada = 0), camada de Ambiente Operacional
(Característica.camada = 1), camada de Tecnologia de Domínio (Característica.camada = 2) e
camada de Técnica de Implementação (Característica.camada = 3), conforme proposto por
Kang et al (2002).
Atributos
Sem atributos específicos.
Associações
• destino : Característica[*] – Referencia a característica de destino do
relacionamento.
• origem : Característica[*] - Referencia a característica de origem do
relacionamento.
Restrições
[1] No relacionamento Implementado Por, a característica de origem deve pertencer a
camadas superiores à da característicade destino, isto é, ter valor do atributo camada
menor do que o da característicade destino (origem.camada < destino.camada).
[2] O relacionamento Implementado Por não deve ocorrer entre características tecnológicas e
características conceituais.
Notação
O relacionamento Implementado Por é representado por uma linha simples com o estereótipo
<<Implemented by>>.
25
Exemplo
O exemplo acima se refere ao domínio de telefonia celular, onde a característica “WAP”,
pertencente à terceira camada de características, implementa a conexão representada pela
característica “Acesso à Internet”, pertencente à primeira camada de características.
19. Generalização
Descrição
Uma generalização é um relacionamento entre uma característica mais geral e uma
característica mais específica. Cada instância da característica específica é também um
exemplo indireto da característica geral.
Atributos
Sem atributos específicos para este metamodelo.
Associações
- genérico: Característica[1] - Referencia a característica mais geral no relacionamento de
Generalização
- específico: Característica[1] - Referencia a característica mais específica no relacionamento
de Generalização
Restrições
Sem restrições específicas para este metamodelo.
Notação
Uma generalização é mostrada como uma linha com um triângulo não-preenchido entre os
símbolos que representam as características envolvidas. O triângulo aponta para o símbolo
que representa a característica geral.
Exemplo
26
O exemplo acima se refere ao domínio de Máquinas de Processo, onde a característica
Processo Composto é uma especialização da característica Processo.
20. Associação
Descrição
Uma associação descreve um conjunto de tuplas cujos os valores se referem a
instancias tipadas. Uma instância de uma associação é chamada ligação.
Uma associação pode representar uma composição (isto é, um relacionamento de
todo/parte). Somente as associações binárias podem ser agregações. A composição é um
relacionamento mais forte do que agregação, e requer queem um dado momento, uma
instância esteja incluída em no máximo uma composição. Se uma composição for deletada,
todas suas partes serão deletadas automaticamente com ela. Note que uma parte pode (quando
permitido) ser removida de uma composição antes que a composição seja deletada, e, assim,
não ser deletada automaticamente com a composição. A composição é representada pelo
atributo ehComposição na extremidade da associação, quando este estiver definido com o
valor "true".(OMG, 2005)
Atributos
Sem atributos específicos para este metamodelo.
Associações
• extremidadeNavegável: Propriedade[*] - extremidade navegável que é parte da
associação (OMG,2005)
• extremidade: Propriedade[2..*] - Cada extremidade representa a participação das
instâncias das classes conectadas à associação.
Restrições
[1] Somente associações binárias podem ser Agregação ou Composição.
27
[2] Não deve haver relacionamento de composição entre características quando a
característica que representa o “todo” é opcional e a característica que representa a “parte” é
mandatória
Notação
Uma associação binária é normalmente desenhada como uma linha contínua que
conecta duas características, ou uma linha contínua que conecta uma única característica
(com duas extremidades distintas).
Uma seta aberta na extremidade de uma associação indica que a extremidade é
navigavel.
Uma associação cuja extremidade tem o atributo tipoAgregação = compartilhada
difere na notação das associações binárias por adicionar um diamante não-preenchido na
extremidade agregada da linha da associação. Uma associação com tipoAgregação=
composite tem, do mesmo modo, um diamante na extremidade agregada, mas nesse caso,
difere da agregação por ter o diamante preenchido.
Exemplo
O exemplo acima se refere ao domínio de telefonia celular, onde a característica Cell Phone
possui uma composição com a característica Agenda, uma agregação com a característica
Câmera e uma ssociação com a característica Envio de Mensagens.
21. Propriedade
Descrição
Uma propriedade relacionada a uma associação representa a extremidade da associação.
Atributos
Composição Agregação
Associação
28
- agregação : TipoAgregação[1] - Especifica o tipo do agregação que se aplica à propriedade.
Default : “nenhuma”.
Associações
• associação : Associação[0..1] - Referencia a associação à qual a propriedade
pertence, se existir.
Restrições
[1] A multiplicidade da extremidade que represetna o “todo” em uma composição não deve
ter valor maior do que 1(OMG, 2005).
Notação
Vide Associação
Exemplo
Vide Associação
22. TipoAgregação
Descrição
TipoAgregação é uma classe do tpo “ennumeration” que especifica os valores que definem o
tipo de agregação de uma propriedade Pode assumir os valores “nenhuma”, “compartilhada”
ou “composite”, onde:
1 None: Indica que a propriedade não tem nenhuma agregação.
2 Compartilhada: Indica que a propriedade tem uma agregação.
3 Composite; Indica que a propriedade tem uma composição.
Atributos
Sem atributos
Associações
Sem associações.
Restrições
Sem restrições.
Notação
30
PACOTE REGRACOMPOSIÇÃO
Figura 14 - Metamodelo Odyssey-FEX: Regras de Composição
23. RegraComposição
Descrição
Regras que definem restrições existentes entre características e que não são expressas
no diagrama, por questões visuais. Tais regras incluem relações do tipo “mutuamente
exclusivo com” e “requerido”, entre características quaisquer conjuntos de características.
Subclasses: RegraComposiçãoInclusiva e RegraComposiçãoExclusiva
Atributos
- nome : String [1] – Referencia o nome da Regra de Composição.
Associações
• antecedenet: Expressão[1] – Indica a expressão antecedente de uma Regra
Composição.
• consequente: Expressão[1] – Indica a expressão consequente de uma Regra
Composição
Restrições
[1] Uma Regra Composição é formada de duas Expressões, uma como antecedente e outra
como conseqüente.
[2] Uma Regra Composição não pode ser contraditória, i.e., não pode ter antecedente e conseqüente
31
iguais.
[3] Regras de Composição não são bidirecionais. Por exemplo, se uma característica A requer
a característica B, e a característica B requer a característica A, existirão duas Regras de
Composição.
[4] Uma Regra de Composição não pode ter antecedente definido e conseqüente nulo ou vice versa.
Notação
Vide RegraComposiçãoInclusiva e RegraComposiçãoExclusiva
Exemplo
Vide RegraComposiçãoInclusiva e RegraComposiçãoExclusiva
24. RegraComposiçãoInclusiva
Descrição
Regras de composição que indicam dependência entre duas ou mais características ou
conjunto de características. Indicam as regras do tipo “requer”.
Superclasse: RegraComposição.
Atributos
Sem atributos específicos
Associações
Sem associações específicas.
Restrições
[1] Numa Regra de Composição Inclusiva, o consequente só poderá ser opcional se o antecedente for
opcional.
Notação
Regras de Composição Inclusivas são representadas da seguinte forma: no canto inferior
direito da característica, pode existir o símbolo R_n, onde n é um número inteiro, que
representa a relação de dependência existente entre as características de mesmo número, (e. g.
R e R, R_1 e R_1)
Exemplo
32
A Figura acima representa a dependência entre as características MOR e SGBD,
significando que o mecanismo de persistência MOR requer um Sistema Gerenciador de
Banco de Dados (SGBD) (MOR requires SGBD).
25. RegraComposiçãoExclusiva
Descrição
Regras de composição que indicam mutua exclusividade entre duas ou mais características ou
conjunto de características. Indicam as regras do tipo “exclui”.
Superclasse: RegraComposição.
Atributos
Sem atributos.
Associações
Sem associações específicas.
Restrições
[1] Uma regra exclusiva não deve envolver características mandatórias, somente
características opcionais.
Notação
Regras de Composição Exnclusivas são representadas da seguinte forma: no canto inferior
direito da característica, pode existir o símbolo X_n, onde n é um número inteiro, que
representa a relação de dependência existente entre as características de mesmo número, (e. g.
X e X, X_1 e X_1)
33
Exemplo
No exemplo acima, referente ao domínio de Máquinas de Processo, são mostradas duas
características que representam as Máquinas de Processo “Charon” e “enactPro”,
mutuamente exclusivas entre si (Charon excludes enactPro)
26. Expressão
Descrição
Expressões que constituem as Regras de Composição. Podem ser Booleanas ou Literais.
Atributos
Sem atributos específicos.
Associações
Sem associações específicas.
Restrições
Sem restrições específicas.
Notação
Uma expressão booleana é representada de acordo com o seu tipo: AND, OR, XOR, NOT ou
Expressão Literal.
Exemplo
Vide AND, OR, XOR, NOT e Expressão Literal.
34
27. ExpressãoLiteral
Descrição
Expressão Literal é a expressão mais elementar de uma Regra de Composição. É representada
por uma única característica.
Atributos
- característica : Característica[1] - Característica que constitui a expressão literal.
Associações
Sem associações específicas.
Restrições
Sem restrições específicas.
Notação
A expressão é representada pelo nome da característica.
Exemplo
Jogos, WAP, telefone Celular
28. AND
Descrição
Expressão que representa o AND lógico.
Atributos
Sem atributos específicos.
Associações
• expEsquerda: Expressão[1] - representa a expressão que vem antes do conector
AND. Pode ser uma expressão literal ou de qualquer outro tipo booleano.
• expDireita: Expressão[1] - representa a expressão que vem depois do conector
AND. Pode ser uma expressão literal ou de qualquer outro tipo booleano.
Restrições
Sem restrições específicas.
Notação
(expEsquerda AND expDireita)
35
Exemplo
(Alarme AND Campainha)
29. OR
Descrição
Expressão que representa o OR lógico.
Atributos
Sem atributos específicos.
Associações
• expEsquerda: Expressão[1] - representa a expressão que vem antes do conector OR.
Pode ser uma expressão literal ou de qualquer outro tipo booleano.
• expDireita: Expressão[1] - representa a expressão que vem depois do conector OR.
Pode ser uma expressão literal ou de qualquer outro tipo booleano.
Restrições
Sem restrições específicas.
Notação
(expEsquerda OR expDireita)
Exemplo
(Alarme OR Campainha)
30. XOR
Descrição
Expressão que representa o XOR lógico.
Atributos
Sem atributos específicos.
Associações
• expEsquerda: Expressão[1] - representa a expressão que vem antes do conector
XOR. Pode ser uma expressão literal ou de qualquer outro tipo booleano.
• expDireita: Expressão[1] - representa a expressão que vem depois do conector
36
XOR. Pode ser uma expressão literal ou de qualquer outro tipo booleano.
Restrições
Sem restrições específicas.
Notação
(expEsquerda XOR expDireita)
Exemplo
(Alarme XOR Campainha)
31. NOT
Descrição
Expressão que representa o NOT lógico.
Atributos
Sem atributos específicos.
Associações
• exp: Expressão[1] - representa a expressão que vem depois do conector NOT. Pode
ser uma expressão literal ou de qualquer outro tipo booleano.
Restrições
Sem restrições específicas.
Notação
NOT (exp)
Exemplo
NOT (Alarme AND Campainha)
NOT(Acesso à Internet)
37
REFERÊNCIAS
BRAGA, R.M.M., 2000, Busca e Recuperação de Componentes em Ambientes de
Reutilização de Software, Tese de DSc., COPPE, UFRJ, Rio de Janeiro, Brasil.
KANG, K.C., COHEN, S.G., HESS, J.A., et al., 1990, Feature-Oriented Domain Analysis
(FODA) - Feasibility Study, Software Engineering Institute (SEI), CMU/SEI-90-TR-
21.
MILER, N., 2000, A Engenharia de Aplicações no Contexto da Reutilização baseada em
Modelos de Domínio, Dissertação de M.Sc, COPPE, UFRJ, Rio de Janeiro, Brasil.
ODYSSEY, 2005, "Odyssey SDE". In: http://reuse.cos.ufrj.br/odyssey, accessed in
25/08/2005.
OMG, 2005, "Unified Modeling Language Specification Version2.0". In:
http://www.omg.org/cgi-bin/doc?formal/05-07-04, accessed in 04/10/2005.
PRIETO-DIAZ, R., ARANGO, G., 1991, "Domain Analysis Concepts and Research
Directions". In: PRIETO-DIAZ, R., ARANGO, G. (eds), Domain Analysis and
Software Systems Modeling, IEEE Computer Society Press.