Documente Academic
Documente Profesional
Documente Cultură
So Paulo
2014
So Paulo
2014
FICHA CATALOGRFICA
DEDICATRIA
AGRADECIMENTOS
A Deus, por ter me dado a vida e por estar vivendo este momento - a minha f
Nele me fez caminhar mesmo nos momentos de dvidas e incertezas.
Ao professor Paulo Srgio Muniz Silva, meu estimado orientador, pelos esclarecimentos e discusses precisas, bem como pela sua pacincia e amizade.
Aos meus pais, Sebastio e Maria do Socorro, e minhas irms, Mariana e Amanda,
pelo grande apoio, amor e carinho que me ofereceram durante esta jornada.
minha amada esposa Marina, que merece um beijo especial por ter tido uma
enorme compreenso de minhas ausncias em momentos especiais.
Aos professores Colin Snook, Michael Poppleton, Michael Butler e Andy Edmunds, por terem me proporcionado uma imerso inesquecvel no mundo Event-B
durante o estgio na Inglaterra.
Aos meus amigos Aryldo Russo Jr, Claudia Melo, Eduardo Takeo, Vladimir Moreira, Haniel Barbosa, Vitaly Savicks, Renato Silva, Ricardo Sekeff e Fbio Siqueira,
pelo incentivo e pelas importantes pausas para um cafezinho.
Aos professores Ricardo Luiz da Rocha e Ana Cristina de Melo, pelas valiosas
crticas e sugestes durante o processo de qualificao de doutorado.
sociedade brasileira que, atravs da USP e do CNPq, permitiu-me realizar o
sonho de contribuir de alguma forma para o desenvolvimento do nosso pas.
RESUMO
As melhores prticas de engenharia de software indicam que a atividade de verificao
fundamental para se alcanar o mnimo de qualidade na construo de um software.
Nos processos de desenvolvimento baseados na UML, um dos seus focos principais
detectar inconsistncias nos diagramas representativos do software. No entanto, a maioria desses processos, como o Iconix, aplica apenas tcnicas informais (ex: inspees
visuais nos modelos), fazendo com que muitas vezes essa atividade seja negligenciada
pelos desenvolvedores. Por outro lado, com o avano das ferramentas automatizadas
de verificao, os mtodos formais, tais como o Event-B, esto atraindo cada vez mais
a ateno das empresas de software. Porm, ainda difcil convencer os desenvolvedores a adot-los, pois no esto acostumados com os conceitos matemticos envolvidos.
Assim, este trabalho apresenta uma proposta de incluso do Event-B no Iconix, dando
origem ao BIconix, um processo de desenvolvimento orientado a objetos com suporte
verificao formal de inconsistncias. Mais especificamente, esta tese aborda a traduo automtica dos quatro diagramas existentes no Iconix (classes, casos de uso,
robustez e sequncia) para o Event-B, alm de mostrar como esta formalizao pode
auxiliar na atividade de verificao em pontos especficos e bem definidos no processo
proposto.
Palavras-chave: Processo de Desenvolvimento de Software, Mtodos Formais, Verificao de Inconsistncias, Iconix, UML, Event-B.
ABSTRACT
The best practices of software engineering indicate that the verification activity is essential to achieve some quality during the software construction. In UML-based development processes, one of its main focuses is the detection of inconsistencies in
diagrams that represent the software. However, most of these processes, such as Iconix, apply only informal techniques (eg. visual model inspections), often implying the
negligence of that activity by developers. Moreover, with the advance of automated
verification tools, formal methods, such as Event-B, are increasingly attracting the attention of software companies. However, it is still difficult to convince developers to
adopt them, because they are not acquainted with some mathematical concepts. Thus,
this paper presents a proposal for the inclusion of Event-B within Iconix, giving rise to
BIconix, an object-oriented development process that supports automatic inconsistencies formal verification. More specifically, this thesis addresses the translation of the
four existing diagrams in Iconix (classes, use cases, robustness and sequence) to EventB, and show how this formalization can assist the verification activity in well-defined
check points of the proposed process.
Keywords: Software Development Process, Formal Methods, Inconsistencies Verification, Iconix, UML, Event-B.
SUMRIO
INTRODUO
21
1.1
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.2
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.3
Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.4
Trabalhos Correlatos . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.5
Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
1.6
Organizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
ICONIX
33
2.1
Definio de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.1.1
Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . .
35
2.1.2
Modelo de Domnio . . . . . . . . . . . . . . . . . . . . . .
36
2.1.3
Requisitos Comportamentais . . . . . . . . . . . . . . . . . .
37
2.1.4
Primeiro Marco . . . . . . . . . . . . . . . . . . . . . . . . .
41
42
2.2.1
Anlise de Robustez . . . . . . . . . . . . . . . . . . . . . .
43
2.2.2
44
2.2.3
Segundo Marco . . . . . . . . . . . . . . . . . . . . . . . . .
45
Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
2.3.1
48
2.2
2.3
Diagrama de Sequncia . . . . . . . . . . . . . . . . . . . . .
2.4
49
2.3.3
Terceiro Marco . . . . . . . . . . . . . . . . . . . . . . . . .
51
Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.4.1
Codificao . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
2.4.2
Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2.4.3
Quarto Marco . . . . . . . . . . . . . . . . . . . . . . . . . .
55
EVENT-B
57
3.1
A Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.1.1
Notao de Modelagem . . . . . . . . . . . . . . . . . . . .
59
3.1.2
Notao Matemtica . . . . . . . . . . . . . . . . . . . . . .
64
3.1.3
Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Obrigaes de Prova . . . . . . . . . . . . . . . . . . . . . . . . . .
72
3.2.1
Provas de Consistncia . . . . . . . . . . . . . . . . . . . . .
72
3.2.2
Provas de Refinamento . . . . . . . . . . . . . . . . . . . . .
73
A Plataforma Rodin . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
3.3.1
Ncleo do Rodin . . . . . . . . . . . . . . . . . . . . . . . .
77
3.3.2
Bibliotecas do Event-B . . . . . . . . . . . . . . . . . . . . .
78
3.3.3
Ncleo do Event-B . . . . . . . . . . . . . . . . . . . . . . .
78
3.3.4
79
3.3.5
Extenses . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
3.2
3.3
2.3.2
BICONIX
82
4.1
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
4.2
Viso Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.3
Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.4
4.5
4.6
4.3.1
Definio de Requisitos . . . . . . . . . . . . . . . . . . . .
85
4.3.2
86
4.3.3
Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . .
88
4.3.4
Implementao . . . . . . . . . . . . . . . . . . . . . . . . .
89
Fluxos de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.4.1
Definio de Requisitos . . . . . . . . . . . . . . . . . . . .
90
4.4.2
91
4.4.3
Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . .
91
4.4.4
Implementao . . . . . . . . . . . . . . . . . . . . . . . . .
92
Papis e Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
4.5.1
Definio de Requisitos . . . . . . . . . . . . . . . . . . . .
95
4.5.2
4.5.3
4.5.4
Implementao . . . . . . . . . . . . . . . . . . . . . . . . . 111
Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6.1
4.6.2
4.6.3
4.6.4
Implementao . . . . . . . . . . . . . . . . . . . . . . . . . 126
FORMALIZAO DO BICONIX
128
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.9.2
5.9.3
5.9.4
175
6.1
6.2
6.3
6.4
CONSIDERAES FINAIS
211
7.1
Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
7.2
7.3
Publicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.4
REFERNCIAS
220
227
274
LISTA DE ILUSTRAES
2.1
Processo Iconix . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.2
Modelo de Domnio . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.3
39
2.4
40
2.5
Passos da Fase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.6
45
2.7
Passos da Fase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
2.8
50
2.9
Passos da Fase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
56
3.1
59
3.2
61
3.3
62
3.4
62
3.5
64
3.6
77
3.7
78
3.8
Perspectiva de Modelagem . . . . . . . . . . . . . . . . . . . . . . .
80
3.9
Perspectiva de Prova . . . . . . . . . . . . . . . . . . . . . . . . . .
80
81
4.1
83
4.2
90
4.3
92
4.4
93
4.5
94
4.6
96
4.7
97
4.8
97
4.9
98
98
99
100
103
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
LISTA DE TABELAS
5.1
LISTA DE ABREVIATURAS
AUP Agile Unified Process
ASM Abstract State Machines
CCS Calculus of Communicating Systems
CSP Communicating Sequential Processes
DAO Data Access Object
EssUP Essential Unified Process
EUP Enterprise Unified Process
FDR Failures Divergence Refinement
JML Java Modeling Language
JSP Java Server Pages
OCL Object Constraint Language
OMG Object Management Group
RUP Rational Unified Process
SMV Symbolic Model Verifier
UML Unified Modeling Language
VCL Visual Contract Language
VDM Viena Development Method
XP Extreme Programming
21
INTRODUO
Este captulo apresenta a motivao desta tese, seus objetivos, os trabalhos correlatos, a metodologia que o norteou, bem como a sua estrutura.
1.1
Motivao
O desenvolvimento de sistemas de software de mdio a grande porte caracterizado muitas vezes pela construo de vrios modelos parciais do sistema a ser produzido. Estes modelos, que podem ser especificaes de requisitos, modelos de domnio,
modelos de arquitetura, modelos de projeto estrutural e comportamental do sistema,
modelos de implantao dos componentes do sistema, etc, normalmente descrevem
um sistema a partir de ngulos distintos e em diferentes nveis de abstrao e formalidade. Eles tambm so geralmente produzidos utilizando mais de uma notao
e tendem a refletir as perspectivas e os objetivos diversos das pessoas envolvidas na
sua construo. Muito frequentemente, essa grande heterogeneidade leva a uma srie
de problemas de inconsistncias bem conhecidos pela comunidade de engenharia de
software.
Um desses problemas como sustentar o que aqui ser denominado de consistncia restritiva, na qual preciso certificar-se de que todos os modelos respeitam as
restries (regras de negcios e propriedades) impostas pelo domnio da aplicao e/ou
partes interessadas (clientes, usurios, etc).
Outra dificuldade no trivial como assegurar a consistncia interna, que neste trabalho significar garantir que cada modelo tenha uma interpretao nica, no sendo
possvel, por exemplo, que seja entendido de maneiras distintas por dois desenvolvedores.
1.1 Motivao
22
1.1 Motivao
23
1.2 Objetivo
1.2
24
Objetivo
1.3 Justificativa
1.3
25
Justificativa
A orientao a objetos um paradigma de anlise, projeto e programao que atualmente bastante disseminado na engenharia de software. Praticamente todas as principais linguagens de programao (Java, C++, Python, etc) do suporte orientao a
objetos. Em relao anlise e projeto orientado a objetos, a UML muito popular,
destacando-se por apresentar uma notao visual e padronizada, ainda que a semntica
seja imprecisa em vrias de suas definies. Devido grande expressividade de seus
diagramas, possvel representar tanto aspectos estruturais quanto comportamentais
de um software em diferentes nveis de abstrao, o que auxilia os sucessivos refinamentos informais da especificao de requisitos at o cdigo. Assim sendo, a UML foi
escolhida como linguagem para expressar os modelos que representam o software.
H diversos processos bem conhecidos, tais como o RUP (KRUCHTEN, 2003), o
Iconix (ROSENBERG; STEPHENS, 2007), o Catalysis (DSOUZA; WILLS, 1999), o
AUP (AMBLER; JEFFRIES, 2002), o EUP (AMBLER; NALBONE; VIZDOS, 2005),
o EssUP (JACOBSON, 2008) e o OpenUP (SURHONE; HENSSONOW, 2011), que
usam a UML para auxiliar no desenvolvimento de software orientado a objetos. No
entanto, o Iconix, apesar de utilizar um diagrama (o de robustez - fazendo uso de
elementos com esteretipos padronizados na UML) que no muito difundido, tem
caractersticas bastante interessantes, com destaque para as seguintes: usa apenas quatro diagramas; tem um conjunto de passos relativamente simples; permite um rastreamento dos requisitos; minimiza a conhecida paralisia da anlise (analysis paralysis)
(BROWN et al., 1998), em que o desenvolvedor tem dificuldades em transitar dos requisitos ao projeto; e fornece um procedimento passo-a-passo, com etapas regulares
de verificao, para realizar esse refinamento. Portanto, o Iconix foi selecionado como
base para o processo a ser apresentado.
Existem alguns mtodos formais baseados em modelos, tais como VDM (BJRNER; JONES, 1978), B (ABRIAL, 1996), Z (SPIVEY, 1989), Alloy (JACKSON,
2006) e ASM (BRGER; STRK, 2003), que possuem suporte verificao automtica de inconsistncias. Porm, a linguagem B se destaca por sua robustez, maior
aplicao industrial e comunidade cientfica bastante ativa. Recentemente, uma variante dessa linguagem, chamada Event-B, vem ganhando espao como a linguagem
formal padro de algumas empresas da rea aero-espacial (FATHABADI; REZAZA-
26
DEH; BUTLER, 2011), servios (WIECZOREK et al., 2008) e metro-ferroviria (LECOMTE; SERVAT, 2007). Assim, a linguagem Event-B foi escolhida como a base
para prover uma semntica formal aos diagramas UML e para expressar as restries
(regras de negcio e propriedades funcionais), auxiliando na verificao das consistncias interna e restritiva, e para dotar os modelos com regras para um refinamento
formal, facilitando a anlise das consistncias horizontal e vertical.
Apesar de no momento ser a nica ferramenta que d suporte ao Event-B, a plataforma Rodin bem madura (existe desde 2004) e tem como grande vantagem o fato
de ser uma extenso da conhecida IDE Eclipse (GALLARDO; MCGOVERN, 2003),
possuindo cdigo aberto. Por isso, o Rodin foi usado para apoio implementao de
uma ferramenta de suporte ao processo proposto.
1.4
Trabalhos Correlatos
27
mente devido ausncia de familiaridade por parte dos desenvolvedores com a notao
matemtica.
Em (BERARDI; CALVANESE; GIACOMO, 2005) apresentado um modelo que
define os elementos do Diagrama de Classe em termos de uma lgica de descrio
(description logics), o que faz com que suas inconsistncias possam ser analisadas
por verificadores que deem suporte a esta lgica. J (FERREIRA, 2010) apresenta
algumas regras de refinamento para o Diagrama de Classes descritas em OCL, que
so mapeadas para a notao formal Alloy (JACKSON, 2006) e depois verificadas
pela sua ferramenta. Outra proposta, apresentada por (KIM; DAVID, 1999), fornece
um mapeamento baseado em meta-modelos do Diagrama de Classes para a notao
formal Object-Z (SMITH, 2000). No entanto, essas propostas de formalizao do Diagrama de Classes ou no utilizam conceitos familiares comunidade de engenharia de
software (caso das lgicas de descrio), ou no propem a incluso em um processo
conhecido de desenvolvimento (caso do Alloy), ou no possuem uma ferramenta de
apoio (caso do Object-Z). Alm disso, essas abordagens focalizam apenas o Diagrama
de Classes que, apesar de ser o mais usado, geralmente no utilizado sozinho na
maioria dos processos de desenvolvimento conhecidos que adotam a UML.
Em (MOKHATI; BADRI, 2009) definida uma traduo do Diagrama de Casos de
Uso para a a lgica de reescrita (rewriting logic) e sua posterior verificao por meio
da ferramenta Maude (CLAVEL et al., 1999). J em (RYNDINA; KRITZINGER,
2004) apresentado um mapeamento de um Diagrama de Casos de Uso anotado com
invariantes, pr e ps condies, para uma especificao em SMV e sua posterior verificao na plataforma NuSMV (CIMATTI et al., 2002). Outra abordagem, fornecida
por (KLIMEK; SZWED, 2013), prope a verificao do Diagrama de Casos de Uso
por meio de regras que podem ser inferidas simbolicamente usando lgica temporal.
Entretanto, essas propostas de formalizao do Diagrama de Casos de Uso se utilizam
de tcnicas pouco conhecidas da comunidade de engenharia de software, como a lgica
de reescrita e a lgica temporal. Ademais, como no caso anterior, focalizam apenas
um diagrama da UML, no propondo a incluso da abordagem em algum processo de
desenvolvimento de software.
Em (RUNDE; HAUGEN; STLEN, 2005) descrita uma semntica precisa para o
refinamento do Diagrama de Sequncia, realizado em um mtodo de desenvolvimento
prprio chamado STAIRS. J em (CHEN; ZHENHUA, 2011) proposta uma soluo
28
1.5 Metodologia
29
mas UML e anotaes OCL para gerar cdigo verificado em formato Java Card por
meio uma ferramenta desenvolvida pelos prprios autores. Em (PAIGE; OSTROFF,
2001) detalhado mais um processo formal que verifica as inconsistncias de trs dos
diagramas da UML (casos de uso, classe e colaborao) por meio da definio precisa
de seus meta-modelos. Apesar de serem abordagens bem prximas da proposta desta
tese, elas no so baseadas em nenhum processo de desenvolvimento conhecido, sendo
aplicados em domnios de problemas especficos, o que no contribui para disseminlos entre desenvolvedores de software de aplicaes mais comuns.
1.5
Metodologia
Para a realizao deste trabalho o mtodo de pesquisa adotado foi composto pelas
seguintes etapas:
1. Reviso bibliogrfica sobre as solues existentes para os problemas de consistncia interna, restritiva, horizontal e vertical da UML.
2. Busca bibliogrfica sobre mtodos formais e sobre processos de desenvolvimento orientado a objetos difundidos no mercado;
3. Definio de como os problemas de inconsistncias deveriam ser abordados,
qual linguagem formal seria utilizada e qual processo orientado a objetos seria
empregado como base da proposta;
4. Descrio detalhada do processo de desenvolvimento incluindo um mtodo formal, com o objetivo de solucionar parte dos problemas de inconsistncia apresentados;
5. Mapeamento dos diagramas presentes no processo proposto para a linguagem
formal escolhida;
6. Elaborao de regras de verificao, assim como a definio de como representlas na notao formal definida;
7. Escolha de uma plataforma de desenvolvimento e construo de um prottipo
para dar suporte ao processo apresentado.
1.5 Metodologia
30
1.6 Organizao
31
Na quinta etapa foi elaborado o mapeamento formal para a notao Event-B dos
quatro diagramas presentes no processo proposto (casos de uso, classes, robustez e
sequncia). As regras resultantes dessa etapa esto informalmente exemplificadas no
Captulo 5 e formalmente descritas no Apndice B.
A sexta etapa encerrou-se com a definio de um conjunto inicial de verificaes
formais possveis de serem realizadas em cada um dos diagramas do processo proposto, por meio das regras determinadas na etapa anterior. Os exemplos dessas verificaes podem ser vistos no Captulo 6.
Na stima etapa foi decidido que seria feita uma extenso da plataforma Rodin, via
plugin, para incorporar os diagramas presentes no processo proposto e gerar, a partir
deles, uma especificao Event-B. Um prottipo foi desenvolvido e estar disponvel
em breve no site oficial da linguagem Event-B (wiki.event-b.org) na seo Plugins.
1.6
Organizao
Esta tese pretende ter um formato fluido, com uma linguagem fcil e direta, acompanhada de diversos exemplos, com a inteno de atender abordagem pragmtica
escolhida e facilitar a compreenso por parte dos leitores. Alm disso, deve ser ressaltado que muitos dos artefatos, modelos, termos e exemplos, sero apresentados na
lngua inglesa devido ao contexto internacional desse projeto.
O restante do presente texto est estruturado em mais seis captulos. No captulo
2 detalha-se o Iconix, destacando as suas origens, os principais conceitos, os seus
benefcios, explicando-se cada uma de suas fases, assim como os diagramas utilizados.
O captulo 3 dedicado introduo abreviada da linguagem Event-B, descrevendose sua sintaxe e as obrigaes formais de prova necessrias para um refinamento correto. Alm disso, h uma breve introduo plataforma Rodin, a ferramenta que d
suporte a essa linguagem e que foi estendida neste trabalho.
J o captulo 4 delineia o processo de desenvolvimento de software proposto nesta
tese, o BIconix, apresentando sua viso geral e seu conjunto bem definido de passos,
assim como os artefatos utilizados e a responsabilidade de cada um dos papis no
processo.
1.6 Organizao
32
O captulo 5 reservado para a descrio dos meta-modelos utilizados pelos diagramas, a fim de possibilitar a realizao do mapeamento deles para Event-B via regras
de transformao. Um exemplo informal para cada uma dessas regras apresentado
ao longo do captulo.
J no captulo 6 so abordadas algumas verificaes formais possveis de serem
realizadas no processo BIconix. Exemplos so expostos para cada um dos 23 problemas de inconsistncias apresentados, mostrando como detect-los automaticamente
apoiando-se na formalizao proposta.
Por fim, no captulo 7 faz-se uma discusso dos resultados alcanados neste trabalho e elenca-se sucintamente as suas principais contribuies. Adicionalmente, so
indicados possveis caminhos de investigao que podem ser seguidos para a realizao
de trabalhos futuros.
33
ICONIX
O processo Iconix (ROSENBERG; STEPHENS, 2007) comeou a ser desenvolvido em 1993 com o objetivo de mesclar os melhores aspectos das trs mais famosas
metodologias orientada a objetos vigentes na poca (Booch, OMT e Objectory), que
posteriormente formaram a base da UML.
O Iconix se apresenta como uma metodologia prtica, intermediria entre a complexidade do RUP (KRUCHTEN, 2003) e a simplicidade do XP (BECK; ANDRES,
2004), mas sendo ao mesmo tempo poderosa para guiar a anlise e projeto orientado a
objetos. Entre suas caractersticas principais, destacam-se:
Utiliza um subconjunto da UML: apenas 3 diagramas (casos de uso, classes e
sequncia), mais o de robustez, ao invs dos 14 diagramas da UML existentes;
Minimiza a paralisia da anlise: ignora a semntica de esteretipos do padro
UML tais como << extend >>, << include >>, etc que faz o desenvolvedor
perder tempo, retardando a passagem da anlise para o projeto;
Possui rastreamento da anlise implementao: todos os requisitos so associados a casos de uso e classes, que formam o eixo de sustentao do processo;
iterativo e incremental: vrias iteraes ocorrem entre o desenvolvimento do
Modelo de Domnio e a modelagem dos casos de uso, enquanto que o modelo
esttico incrementalmente refinado pelo modelo dinmico;
baseado nas questes fundamentais da orientao a objetos: o que fazem os
usurios? (casos de uso); quais os objetos do mundo real? (Modelo de Domnio);
quais os objetos relacionados com os casos de usos? (robustez); como os objetos
colaboram entre si? (sequncia); como realmente ser construdo o software?
(classes).
34
2.1
Definio de Requisitos
35
1. Requisitos Funcionais: define o que o sistema deve ser capaz de fazer. De acordo
com a organizao do projeto, pode-se participar ativamente da criao desses
requisitos ou j receb-los diretamente do cliente ou da equipe de anlise de
negcios.
2. Modelo de Domnio: estabelece o escopo do problema, facilitando o seu entendimento ao elicitar os conceitos envolvidos.
3. Requisitos Comportamentais: define como o usurio e o sistema iro interagir (i.e., escreve-se a primeira verso dos casos de uso). Recomenda-se iniciar
com prottipos de interface e identificar todos os casos de uso que sero implementados, ou pelo menos uma primeira lista quando se tem certeza que muitas
mudanas ainda ocorrero.
4. Primeiro Marco: realiza a reviso dos requisitos, analisando se os casos de uso
atendem s expectativas do cliente. Deve-se revisar apenas o pequeno grupo de
casos de uso escolhidos para serem implementados no ciclo de desenvolvimento
da iterao atual.
2.1.1
Requisitos Funcionais
36
2.1.2
Modelo de Domnio
37
2.1.3
Requisitos Comportamentais
38
formam a base dos casos de uso. No h um modelo padronizado para descrever casos
de uso, mas, assim como nas outras atividades, o Iconix oferece uma lista de sugestes:
1. Refira-se s classes de interface (telas) pelo nome.
2. Cite as classes de domnio pelo nome.
3. Escreva os casos de uso usando a estrutura sujeito-verbo-objeto.
4. Escreva o caso de uso no contexto do Modelo de Domnio.
5. Lembre-se que um caso de uso representa um comportamento executvel.
6. Use interfaces, prottipos de telas, etc.
7. Escreve o caso de uso usando um fluxo de evento/resposta, descrevendo os dois
lados do dilogo usurio/sistema.
8. Escreva o caso de uso na voz ativa.
9. Organize os casos de uso usando o Diagrama de Casos de Uso.
10. Um caso de uso no deve ter mais do que dois pargrafos de texto.
Muitas pessoas tm dificuldade em visualizar um software apenas por meio textual. Assim, o Iconix incentiva o uso de uma sequncia de telas e interfaces grficas
39
como ponto de partida para simular a interao entre usurios e sistema, identificando
os casos de uso e facilitando o seu entendimento pelas partes interessadas. Essas telas podem ser prottipos, sem muita elaborao grfica (papel, slides do PowerPoint,
HTML, etc), mas devem conter o mximo possvel de detalhes (botes, menus, etc) de
tal forma que explicite os fluxos alternativos do caso de uso. Ao se retornar ao exemplo apresentado, a seguinte tela (Figura 2.3) bastante importante para identificar e
elucidar o caso de uso Login.
Depois de identificados os casos de uso por meio das telas de interface, o prximo
passo criar o Diagrama de Casos de Uso. Com esse diagrama, possvel delimitar o
escopo do projeto, indicando quais funcionalidades efetivamente fazem parte do software. Alm disso, ele bastante utilizado para indicar o relacionamento entre atores,
na maioria das vezes usurios e representados graficamente por bonecos, e casos de
uso, representados por elipses. Tal relacionamento uma associao em UML e indica que um ator participa do caso de uso. H tambm a possibilidade de se efetuar o
relacionamento de generalizao entre atores, bem como outros relacionamentos entre
casos de usos (incluso e extenso).
No entanto, o Iconix defende que a aplicao desses relacionamentos no to
trivial, levando conhecida paralisia da anlise (BROWN et al., 1998). Assim, o tempo
que se desperdia definindo-se o uso de generalizao, incluso ou extenso diminui a
produtividade na fase de definio de requisitos e, por isso, no se deve perder tempo
com eles. O Iconix prope que o mximo de relacionamento que deve existir pode ser
alcanado por meio de dois esteretipos propostos: um chamado invokes, para indicar
que um caso de uso invoca outro; e outro chamado precedes para indicar a ordem
temporal de execuo dos casos de uso 1 .
1 Neste
40
2.1.4
41
Primeiro Marco
A reviso dos artefatos produzidos at o momento um passo vital para assegurar que os requisitos foram suficientemente bem compreendidos, tanto pela equipe de
desenvolvimento quanto pelo cliente/usurio. O Iconix aconselha as seguintes verificaes:
1. Remova tudo o que esteja fora do escopo do software.
2. Troque a voz passiva pela ativa nos casos de uso.
3. Verifique se o texto dos casos de uso no est muito abstrato.
4. Analise se o texto do caso de uso est refletindo as informaes dos prottipos
de telas.
5. Verifique se foram includos todos os fluxos alternativos.
6. Certifique-se de que cada requisito tenha um rastreamento com casos de uso.
7. Confirme que o caso de uso descreve o que os usurios esto tentando fazer.
8. Se existirem muitos casos de uso, organize-os em pacotes.
9. Revise os casos de usos, Modelo de Domnio e prottipos de telas com todos os
envolvidos no projeto, incluindo tanto os usurios finais quanto a equipe tcnica.
10. Verifique se o Modelo de Domnio descreve pelo menos 80% dos conceitos mais
importantes (objetos do mundo real) do domnio do problema em uma linguagem
no tcnica que os usurios possam entender.
Uma vez finalizada essa reviso, que deve envolver todos os interessados no projeto de desenvolvimento do software, pode-se passar para a prxima fase, anlise e
projeto preliminar. Um viso global das principais atividades da fase de requisitos
pode ser encontrada na Figura 2.5.
42
2.2
A fase de anlise e projeto preliminar envolve uma explorao mais apurada dos
requisitos, de forma a facilitar a passagem para a fase de projeto detalhado. Mais
especificamente, o foco dessa etapa remover inconsistncias encontradas nos requisitos e relacionar os casos de usos com os objetos do domnio. Essa fase engloba trs
atividades:
1. Anlise de Robustez: permite uma transio suave da descrio textual de um
caso de uso para o Diagrama de Sequncia por meio do Diagrama de Robustez,
que uma espcie de foto dos objetos presentes no caso de uso.
43
2. Atualizao do Modelo de Domnio: as classes e atributos descobertos pela atividade anterior foram uma atualizao do Modelo de Domnio criado na primeira
fase.
3. Segundo Marco: realiza a reviso do Diagrama de Robustez, do Modelo de Domnio e da descrio textual dos casos de uso, para garantir que estejam consistentes entre si.
2.2.1
Anlise de Robustez
O conceito de anlise de robustez provm do mtodo proposto por Jacobson (JACOBSON, 1992) para o mundo de OO em meados da dcada de 90. Basicamente,
a anlise de robustez envolve examinar a narrao da descrio textual de cada caso
de uso e identificar um primeiro conjunto dos objetos participantes. A anlise de robustez tem como objetivo principal suavizar a lacuna entre os requisitos e o projeto,
bem como esclarecer o caso de uso e encontrar possveis fontes de ambiguidade. Alm
disso, como ser visto mais adiante, durante essa atividade, novas classes so descobertas, bem como os atributos delas e das outras classes j existentes.
Essa anlise usa como suporte grfico o Diagrama de Robustez, um hbrido entre
o Diagrama de Classes e o Diagrama de Atividades da UML, que representa um caso
de uso utilizando trs esteretipos de classes: classes de interface, que so responsveis pela comunicao do exterior (atores) com os componentes internos do software;
classes de entidade, que so responsveis pela reteno de dados, armazenando todas
as informaes essenciais ao software; e classes de controle, que orquestram todas as
trocas de mensagens entre as demais classes.
O Iconix fornece alguns conselhos para a construo do Diagrama de Robustez:
1. Lembre-se que o Diagrama de Robustez uma foto dos objetos presentes em
um caso de uso, cujo objetivo forar o refinamento tanto da descrio textual
do caso de uso quanto do Modelo de Domnio.
2. As classes de entidade e interface se transformaro em classes no Diagrama
de Sequncia, enquanto que as classes de controle se tornaro mensagens na
maioria das vezes.
44
2.2.2
Alm de amenizar a dificuldade da passagem dos requisitos para o projeto, o Diagrama de Robustez leva descoberta de novas classes que no foram percebidas na
primeira verso do Modelo de Domnio. Alm disso, quando se utiliza os prottipos
de telas na fase de definio de requisitos, os casos de uso se enriquecem com vrios
atributos, que se tornam explcitos quando se usa o Diagrama de Robustez.
Assim, ao final da atividade anterior, aps se desenhar um Diagrama de Robustez
para cada caso de uso, necessrio atualizar o Modelo de Domnio com as classes e
45
2.2.3
Segundo Marco
46
2.3
Projeto Detalhado
O objetivo dessa fase detalhar o comportamento de cada caso de uso por meio
de Diagramas de Sequncia, identificando as mensagens entre os diferentes objetos
envolvidos. Como na fase anterior, essa etapa compreende trs atividades:
47
48
3. Terceiro Marco: realiza a reviso dos Diagramas de Sequncia para garantir que
o como do projeto corresponde ao o qu das fases anteriores.
2.3.1
Diagrama de Sequncia
49
8. Revise o Modelo de Domnio frequentemente para garantir que todas as operaes foram atribudas s respectivas classes.
9. Revise o Diagrama de Sequncia quantas vezes for necessrio.
10. Enxugue e limpe o modelo esttico antes de prosseguir para a prxima atividade.
A transio do Diagrama de Robustez para o Diagrama de Sequncia bastante
suave. Cada ator e classe de interface ou entidade transposto como uma linha de
vida no Diagrama de Sequncia, sendo que algumas ferramentas j automatizam esse
processo. O trabalho principal dessa atividade se volta para decidir como atribuir o
comportamento das classes de controle entre as classes de interface e entidade, ou
seja, em como distribuir a responsabilidade das operaes entre essas classes do diagrama com base nas classes de controle. importante ressaltar que no existe um
mapeamento um-a-um entre uma classe de controle e uma operao, isto , cada classe
de controle pode gerar duas ou mais operaes, dependendo da deciso do desenvolvedor. O Diagrama de Sequncia tambm o local ideal para detalhar o tipo de retorno
de cada operao.
Observando-se o exemplo apresentado, um possvel Diagrama de Sequncia para
detalhar o caso de uso Login pode ser visualizado na Figura 2.8. Note a existncia
da apenas quatro linhas de vida, correspondendo ao ator e as classes de interface e
entidades, e que cada classe de controle do Diagrama de Robustez se transforma em
uma operao, com exceo da classe Login Valid?, que foi refinada em duas operaes
(checkUser e initSession).
2.3.2
50
e seus tipos de retorno, e classes de interface. Para isso, basta verificar no Diagrama
de Sequncia quais as operaes associadas s mensagens que esto alcanando cada
uma das classes, bem como os tipos de retorno existentes nas operaes. No exemplo
apresentado, o Diagrama de Sequncia do caso de uso Login responsvel pela:
Incluso dos mtodos checkSession e initSession na classe Session e do mtodo
checkUser na classe User Account.
Incorporao da classe Login Screen e de seus mtodos (showLoginScreen, typeUserPass, clickLogin, displayUserLoggedMsg, displayConfirmationMsg e displayErrorMsg).
importante destacar que nessa atividade de atualizao deve-se detalhar a cardinalidade entre as associaes das classes e modificar o foco para o domnio da soluo,
ou seja, neste ponto as classes devem comear a refletir as tecnologias que sero usadas, tais como classes JSP, classes DAO, etc. Logo aps, passa-se para a reviso do
projeto.
2.3.3
51
Terceiro Marco
A reviso dessa fase tem como objetivo verificar a qualidade do projeto, se todos os
diagramas de sequncia esto representando fielmente os casos de uso, se o Diagrama
de Classes est completo, incluindo as classes relacionadas ao domnio da soluo, etc.
O Iconix sugere as seguintes verificaes:
1. Revise e incremente os testes definidos na primeira fase.
2. Gere os cabealhos do cdigo-fonte a partir do Diagrama de Classes.
3. Verifique se todos os atributos possuem tipos e os mtodos possuem valores de
retorno.
4. Certifique-se de que os desenvolvedores revisaram o projeto.
5. Rastreie todos os requisitos em casos de uso e classes para garantir que todos
foram implementados.
6. Se o projeto de classes reflete algum padro ou construo especfica, garanta
que tal detalhe aparea no Diagrama de Sequncia.
7. Revise as classes para garantir que todas possuam atributos e mtodos, alm da
multiplicidade das associaes.
8. Certifique-se de que as operaes foram alocadas para as classes corretas.
9. Verifique mais uma vez se cada Diagrama de Sequncia leva em considerao
tanto o fluxo bsico quanto os fluxos alternativos.
10. Tenha certeza que o Diagrama de Sequncia corresponde descrio textual do
caso de uso.
Uma vez finalizada essa reviso, que deve envolver todos os interessados no projeto de desenvolvimento do software, pode-se passar para a prxima fase, implementao. Um viso global das principais atividades da fase de projeto detalhado pode ser
encontrada na Figura 2.9.
2.4 Implementao
52
2.4
Implementao
2.4 Implementao
53
2. Testes: efetuam-se os testes unitrios, de integrao e aceitao. Para cada mtodo implementado, cria-se um teste unitrio para o mesmo ou vice-versa, caso
a preferncia do desenvolvedor seja pela abordagem TDD (Test Driven Development) (BECK, 2003). Os demais testes so baseados nos casos de uso, incluindo
tanto o fluxo bsico quanto os fluxos alternativos.
3. Quarto Marco: faz-se uma reviso do cdigo e dos modelos criados para poder
se iniciar o prximo ciclo de desenvolvimento iterativo.
2.4.1
Codificao
O Iconix considera bastante subjetiva a escolha de algoritmos e estilo de programao e por isso a codificao fica ligeiramente fora do seu escopo. Mas se a fase
anterior foi realizada de maneira correta, o Diagrama de Classes deve ter as classes
do domnio da soluo. Assim, as classes de interface podem se tornar, por exemplo,
pginas web (PHP, JSP, etc) e as classes de entidade formaro a base para o desenvolvimento do banco de dados. O Iconix sugere os seguintes conselhos para a atividade
de codificao:
1. Lembre-se de implementar tambm os fluxos alternativos.
2. No faa comentrios excessivos no cdigo (isso dificulta a manuteno e legibilidade).
3. Pense no teste unitrio enquanto realiza a implementao.
4. Tente manter o projeto e o cdigo sincronizados.
5. Se o cdigo comear a ficar fora de controle, pare e reveja o projeto.
6. No deixe os problemas de framework se sobressarem em relao aos problemas
de negcio.
7. Sempre questione as escolhas de projeto do framework.
8. Realize inspees regulares no cdigo.
9. Se o cdigo revelar que algo est errado no projeto, mude-o, mas tambm reveja
o modelo.
2.4 Implementao
54
2.4.2
Testes
O Iconix defende que os testes devem ser membros ativos do ciclo iterativo e
incremental, no somente como algo que deve ser feito ocasionalmente quando se tem
o cdigo pronto. A razo para isso simples: os testes mostram que o produto atende
especificao proposta. Mas se os testes no estiverem diretamente alinhados com a
especificao, eles so apenas uma grande perda de tempo. Um importante conceito
entender os diferentes tipos de testes. O processo Iconix utiliza-se do modelo V
(BEIZER, 1990) para derivar os testes de unidade, integrao, sistema e aceitao.
Assim, cada artefato criado nas fases anteriores ajuda na gerao de cada um desses
tipos de testes. Por exemplo, o teste unitrio, que deve ser feito para cada mtodo a ser
implementado, tem como base as classes de controle do Diagrama de Robustez. As
seguintes sugestes so dadas aos desenvolvedores para a construo e aplicao de
testes:
1. Descreva os testes com um bom nvel de detalhe.
2. Use frameworks como o JUnit e Selenium para armazenar, organizar e automatizar os testes.
3. Crie os testes de integrao para cobrir todos os fluxos bsicos.
4. Expanda os testes de integrao para cobrir parte do fluxo bsico e mais cada um
dos fluxos alternativos.
5. Faa um teste de aceitao para cada caso de uso.
6. Verifique se os testes cobrem todos os requisitos.
7. Use uma matriz de rastreamento para ajudar na verificao de que todos os requisitos foram testados.
8. Use o Diagrama de Robustez como auxlio para a criao de testes unitrios.
9. Entenda os diferentes tipos de testes e quando e o porqu de us-los.
2.4 Implementao
55
10. Adote uma mentalidade de que cada erro encontrado uma vitria e no um
defeito.
2.4.3
Quarto Marco
A reviso dessa fase tem basicamente como finalidade averiguar se que o cdigo e
o projeto esto sincronizados. O Iconix elenca os seguintes passos para essa verificao:
1. Prepare a reviso e garanta que todas as partes interessadas tenham recebido
todos os modelos e o cdigo antes da reunio.
2. Crie uma lista abstrata, baseada nos casos de uso, dos itens a serem revisados.
3. Se necessrio, decomponha essa lista em checklists menores.
4. Revise o cdigo.
5. Faa anotaes durante essa reviso para serem usadas em revises futuras.
6. Aps a reunio, envie um email para as partes interessadas informando as aes
que sero tomadas.
7. Tente focalizar a deteco de erros e no a correo.
8. Use ferramentas CASE para automatizar a sincronizao entre o cdigo e o modelo de software.
9. Mantenha apenas um formalismo mnimo nos checklists, evitando burocracias
desnecessrias.
10. Lembre-se que uma reunio de reviso de modelos tambm, no apenas de
cdigo.
Aps a finalizao dessa reviso, que deve envolver todos os interessados no projeto de desenvolvimento do software, um novo conjunto de casos de uso selecionado
dando incio ao prximo ciclo de desenvolvimento (iterao). Um viso global das
principais atividades da fase de implementao pode ser encontrada na Figura 2.10.
2.4 Implementao
56
57
EVENT-B
58
3 EVENT-B
Dentre os mtodos citados, o B se destaca por garantir o desenvolvimento do software da especificao implementao por meio de refinamentos formais e obrigaes
de provas, alm de ser um mtodo bem maduro (criado no final de dcada de 80), com
aplicao industrial comprovada (Alstom, Siemens, ClearSy e Peugeot) e comunidade
cientfica bastante ativa 1 .
O mtodo B prope que a especificao funcional do sistema seja baseada em
mquinas de transio de estados abstratas (ASM). Cada mquina deve ser refinada
sucessivamente at alcanar um nvel mais concreto, de tal forma que se consiga gerar
cdigo em uma linguagem de programao (geralmente Ada ou C). Para toda mquina
criada, preciso garantir a sua consistncia com as propriedades do sistema expressas
via invariantes, assim como para cada passo de refinamento existe a necessidade de
se comprovar que o nvel mais detalhado est de acordo com a especificao no nvel
mais abstrato.
No entanto, alguns problemas conhecidos do mtodo B, tais como a falta de escalabilidade, a ausncia de um mecanismo formal de decomposio, a impossibilidade de
acrescentar novas operaes durante um passo de refinamento e o uso de construes
que tornam as provas matemticas mais complexas (ex. if-else), contriburam para o
desenvolvimento de uma variante do B, conhecida como Event-B.
O Event-B comeou a ser desenvolvido no comeo deste sculo por Abrial (ABRIAL,
2010), o mesmo criador do B, que tinha como objetivo a criao de um mtodo semelhante ao B, que cobrisse os aspectos centrais do processo de desenvolvimento de um
software e que garantisse a sua correo por construo por meio de refinamentos matematicamente provados. A diferena principal entre as linguagens que o Event-B
soluciona os problemas anteriormente apresentados, alm de ser extensvel tambm
para modelagem de hardware.
Para lidar com a falta de escalabilidade, o Event-B separa a parte esttica da parte
dinmica, provendo uma srie de relacionamentos entre elas a fim de facilitar a modelagem da arquitetura do sistema. O Event-B possui duas abordagens para a decomposio de uma mquina: uma na qual as sub-mquinas dividem eventos e uma outra
na qual elas compartilham as variveis. O Event-B possibilita uma maior liberdade ao
desenvolvedor ao permitir que um evento (semelhante a uma operao no B) possa ser
1 www.vasco.imag.fr/B/
e www.bmethod.com
59
3.1 A Linguagem
refinado por vrios eventos e que um evento possa ser includo a qualquer momento
em uma mquina por meio do refinamento de um evento abstrato chamado skip. O
Event-B tambm reduziu a complexidade de provas de refinamento ao eliminar algumas estruturas de controle, tais como o if-else e o while, bem como alguns tipos primitivos (char, double, etc). Por fim, essa variante do B permite a integrao do software
com ambientes externos (hardware de sensores, etc) ao possibilitar o monitoramento
de variveis que so passadas como parmetros para os eventos.
Todo o texto que segue no restante do captulo baseado no manual de referncia
do Event-B (Deploy Project, 2011), que descreve tanto os aspectos de modelagem
quanto os matemticos dessa linguagem, bem como as obrigaes de provas que devem
ser verificadas e a plataforma de desenvolvimento que d suporte a esse mtodo.
3.1
3.1.1
A Linguagem
Notao de Modelagem
3.1 A Linguagem
60
61
3.1 A Linguagem
62
3.1 A Linguagem
Outras maneiras menos usadas para descrever um evento encontram-se na Figura 3.4.
3.1 A Linguagem
63
64
3.1 A Linguagem
3.1.2
Notao Matemtica
65
3.1 A Linguagem
f e g so funes;
E e F so expresses;
E, F um padro recursivo, isto , corresponde a e1, e2 e tambm a e1, e2, e3, ...;
similarmente para x, y;
O meta-predicado f ree(z, E) significa que nenhuma das variveis de z est
livre em E. Este meta-predicado definido recursivamente na estrutura de E.
Os casos base so: f ree(z, z P Q), f ree(z, z P Q), f ree(z, {z P |
F}), f ree(z, z P | E) e f ree(z, z);
P deve restringir z significa que o tipo de z deve ser no mnimo inferido a partir
do P;
Parnteses so usados para mostrar a estrutura sinttica, sendo omitidos quando
no existir nenhuma confuso.
3.1.2.1
Predicados
3.1 A Linguagem
66
Conjuntos
3.1 A Linguagem
67
3.1 A Linguagem
3.1.2.3
68
Nmeros
O Event-B tem como tipos primitivos o conjunto dos nmeros inteiros, o conjunto
dos naturais e o conjunto dos naturais positivos.
1. Inteiros: Z
2. Naturais: N
3. Naturais Positivos: N1 = N \ {0}
4. Mnimo: min(S). Devolve o menor elemento de um conjunto. S deve ser um
subconjunto finito de Z.
5. Mximo: max(S). Devolve o maior elemento de um conjunto. S deve ser um
subconjunto finito de Z.
6. Soma: m + n.
7. Diferena: m n, onde n m.
8. Produto: m n.
9. Diviso: m/n, com n 6= 0.
10. Resto: m mod n, com n 6= 0.
11. Intervalo: m..n = {i | m i i n}.
12. Maior: m > n.
13. Menor: m < n.
14. Maior ou igual: m n.
15. Menor ou igual: m n.
3.1 A Linguagem
3.1.2.4
69
Relaes
3.1 A Linguagem
70
Funes
Uma funo uma relao com a restrio de que cada elemento do domnio est
relacionado a um nico elemento da imagem, um mapeamento muitos para um.
1. Funo Parcial: S
7 T = {r r S T r1 ; r T C id}.
2. Funo Total: S T = { f f S
7 T dom( f ) = S}.
3. Funo Parcial Injetora: S
7 T = {f f S
7 T f 1 T
7 S}
4. Funo Total Injetora: S T = S
7 T ST.
5. Funo Parcial Sobrejetora: S
7 T = {f f S
7 T ran( f ) = T }.
6. Funo Total Sobrejetora: S T = S
7 T ST.
7. Funo Bijetora: S
T = ST ST.
8. Abstrao Lambda: ( p P | E) = {z P | p 7 E}, na qual z a lista de variveis
que aparecem em p.
9. Aplicao de Funo: f (E) = y se E 7 y E dom( f ) f X Y
7 , na qual
f do tipo P(X Y ).
Por fim, importante ressaltar que no Event-B as relaes e funes s possuem
um nico argumento, mas esse parmetro pode ser um par ou uma tupla (eg. f (E 7
F)). Construes do tipo f (E, F) no so vlidas.
3.1.3
Exemplo
3.1 A Linguagem
CONTEXT BooksOnLine
CONSTANTS
H
AXIOMS
axm1 : H N
END
MACHINE BookStore
SEES BooksOnLine
VARIABLES
soldBooks
booksUser
INVARIANTS
inv1 : soldBooks N
inv2 : booksUser N N
inv3 : uu dom(booksUser) card(finite(booksUser(u))) H
EVENTS
Initialisation
begin
act1 : booksUser := {0 7 0}
act2 : soldBooks := 0
end
Event addBooksOrder =
b
any
b, u
where
grd1 : b N1 u N1
then
act1 : booksUser(u) := b
act2 : soldBooks := soldBooks + 1
end
END
71
72
3.2
Obrigaes de Prova
3.2.1
Provas de Consistncia
Como toda mquina Event-B uma construo matemtica por natureza, expressando precisamente os estados, invariantes e eventos, necessrio que se garanta minimamente a consistncia lgica dos elementos descritos na especificao. Para tanto,
preciso certificar-se de duas propriedades: cada evento (incluindo o de inicializao)
deve preservar o invariante, ou seja, antes da execuo do evento o invariante valido e assim deve permanecer aps a sua aplicao; sempre viabilizar um evento, ou
seja, deve sempre existir guardas que permitam a ocorrncia do evento, garantindo que
sempre um prximo estado seja alcanado a partir do atual. Mais formalmente temos
que:
Definio 1. Seja G, uma guarda de um evento, S, a ao resultante da execuo
desse evento, Inv, o predicado do invariante, t os parmetros desse evento, e v e v0
representando os valores das variveis antes e depois do evento. Para se garantir a
consistncia da mquina Event-B, os seguintes predicados devem ser vlidos:
Preservar : Inv(v) G(t, v) S(t, v, v0 ) Inv(v0 )
Viabilizar : Inv(v) G(t, v) v0 |S(t, v, v0 )
Existe uma forma especial de a obrigao de prova preservar para a Initialisation
sem o invariante e a guarda na hiptese.
73
No exemplo da especificao citada anteriormente bem fcil verificar a sua consistncia. Por simplicidade, apenas a obrigao de prova do evento INITIALISATION
ser mostrada. O invariante da mquina estabelece que a varivel soldBooks um
nmero natural, que booksUser uma relao de usurio com um livro e que a quantidade pedida seja menor que H. Nesse caso, o evento de inicializao vai preservar o
invariante pois a sua ao S gera valores para as variveis compatveis com este. Como
a guarda do evento sempre vlida, viabilizar o evento trivial. As obrigaes de
prova formais so descritas abaixo:
[booksUser := {0 7 0} soldBooks := 0](v, v0 ) [soldBooks N booksUser
N N (uu dom(booksUser) card( f inite(booksUser(u))) H)](v0 )
[soldBooks N booksUser N N (uu dom(booksUser) card( f inite
(booksUser(u))) H](v) v0 |[booksUser := {0 7 0} soldBooks := 0](v, v0 )
3.2.2
Provas de Refinamento
74
75
Para evitar o deadlock (restrio 3), tem-se que garantir a seguinte obrigao de
prova:
InvM (v) InvR (v, w) (GM1 (t, v) ... GMn (t, v)) (GR1 (t, w) ... GRm (t, w))
Por simplicidade, ser apresentada a prova requerida na qual um evento j existente refinado. De volta ao exemplo apresentado, pode-se verificar que a especificao abaixo, na qual h uma limitao no nmero de livro existentes, um possvel
refinamento do evento addBooksOrder
MACHINE BookStoreR
REFINES BookStore
SEES BooksOnLine
VARIABLES
stock
INVARIANTS
inv4 : stock = 100
inv5 : soldBooks <= stock
// gluing invariant
...
Event addBooksOrderR =
b
refines addBooksOrder
any
b, u
where
grd1 : b N1 u N1
grd2 : soldBooks < stock
then
act1 : booksUser(u) := b
act2 : soldBooks := soldBooks + 1
end
...
76
3.3
A Plataforma Rodin
77
3.3.1
Ncleo do Rodin
O ncleo do Rodin composto pelo prprio Eclipse IDE e pelo Rodin Core, que
por sua vez formado por dois componentes derivados do projeto Java Development
Tools of Eclipse: o repositrio e o construtor. O repositrio responsvel por armazenar persistentemente, em formato XML, elementos de dados em forma de objetos Java,
enquanto que o construtor se incumbe da tarefa de organizar as alteraes feitas nos
elementos do repositrio. Esses dois componentes so bastante usados em extenses
do Eclipse por prover recursos para armazenar e gerenciar qualquer tipo de dados de
maneira fcil e transparente, o que torna desnecessrio a criao de uma sintaxe fixa
para o Event-B. No entanto, o uso desses componentes faz com que o Rodin se torne
muito dependente dos recursos e do modelo de concorrncia do Eclipse.
78
3.3.2
Bibliotecas do Event-B
De forma geral, o Event-B no tem uma sintaxe que precisa ser analisada, pois os
modelos so mantidos em um repositrio. No entanto, a notao matemtica usada, por
exemplo, em invariantes ou guardas, tem uma sintaxe especificada por uma gramtica.
Esta gramtica, bem como a sua rvore de sintaxe abstrata (AST), formam uma das
bibliotecas do Event-B.
A outra biblioteca (SEQP) responsvel por fornecer o mecanismo de prova. Ela
contm os tipos de dados necessrios para as provas, em especial na forma de sequentes, alm de algumas regras de inferncia e tticas. Por meio das regras de inferncia,
possvel representar uma prova como uma rvore, que pode ser facilmente manipulada quando se deseja realizar provas interativas. Essa biblioteca recebe suporte de
dois provadores provenientes da ferramenta Atelier-B (ClearSy, 2011): o PP (Predicate Prover), usado para provas que envolvem basicamente lgica de predicados; e o
ML (Mono-Lemma), usado fortemente quando as provas envolvem aritmtica.
3.3.3
Ncleo do Event-B
O analisador esttico responsvel por verificar a boa formao sinttica dos contextos e mquinas Event-B, fornecendo mensagens de erro caso ocorra algum problema de digitao. A notao matemtica especificada por uma gramtica livre
de contexto, enquanto que o restante dos elementos do Event-B so especificados por
79
3.3.4
A interface grfica do Event-B composta por duas partes: uma interface para
modelagem e outra para provas. Elas esto disponveis para o usurio na forma de
perspectivas da IDE Eclipse de tal maneira que o usurio possa altern-las facilmente.
No entanto, isso no significa que as duas perspectivas no estejam perfeitamente integradas, o que poderia sugerir que a modelagem e a prova sejam atividades diferentes.
A arquitetura da plataforma Rodin foi desenvolvida para o usurio perceber explicitamente que as provas fazem parte da modelagem. Assim, uma das facilidades que
cada obrigao de prova presente na perpectiva de prova possui links para que o usurio
possa selecionar rapidamente os elementos relacionados a ela que esto na perspectiva
de modelagem. A tela da interface de modelagem pode ser visualizada na Figura 3.8,
enquanto que a tela da interface de prova pode ser vista na Figura 3.9.
J a Figura 3.10 mostra como essas duas partes se integram com os componentes
da ncleo do Event-B. importante destacar que a interface para prova no acessa
diretamente as provas, mas usa os servios do gerenciador de obrigaes de provas. O
mesmo ocorre com a interface de modelagem, provendo elementos para serem primeiramente verificados pelo analisador esttico.
80
81
3.3.5
Extenses
Uma das grandes vantagens de se utilizar uma ferramenta baseada na IDE Eclipse
a facilidade de extenso fornecida por meio do mecanismo de plugins. A comunidade
do Rodin j desenvolveu uma dzia deles, com destaques para o UML-B (SNOOK;
BUTLER, 2006), o Decomposition (SILVA et al., 2011), o ProB (LEUSCHEL; BUTLER, 2008) e o ProR (JASTRAM, 2010).
O UML-B prov uma notao semelhante UML como interface de modelagem
para o Event-B, incluindo o suporte ao refinamento. O UML-B, composto pelos diagramas de pacote, contexto, classes e mquinas de estados, tem grande influncia
sobre o projeto desta tese, sendo usado como ponto de extenso para a implementao
realizada.
J o Decomposition permite a decomposio de mquinas e contextos Event-B
usando tanto a abordagem de variveis quanto a de eventos compartilhados. O ProB
uma adaptao para a plataforma Rodin do verificador de modelos de mesmo nome,
originalmente desenvolvido para o B. Por fim, o ProR um plugin que gerencia requisitos, mantendo o rastreamento deles com os elementos do modelo Event-B.
82
BICONIX
4.1
Introduo
No captulo 2 foi apresentado o processo de desenvolvimento Iconix, cujas caractersticas principais so: empregar orientao a objetos, utilizar um subconjunto de
diagramas UML, minimizar a paralisia da anlise, ser iterativo e incremental, possuir
um conjunto de passos bem definidos da anlise implementao, estimular a cultura
de verificao e permitir o rastreamento de requisitos. No entanto, as etapas nas quais
existe a atividade de verificao de inconsistncias so totalmente informais e dependentes da habilidade e experincia dos desenvolvedores que as esto executando, sendo
muitas vezes negligenciadas.
No captulo 3 foi descrito o mtodo formal Event-B, que baseado no conceito
de refinamento de mquinas de transio de estados. Cada mquina abstrata (usada
para representar o software) pode ser refinada sucessivamente at se alcanar o nvel
de cdigo-fonte, sendo que a verificao de inconsistncias formalmente garantida
por obrigaes de provas matemticas expressas em lgica de predicados, aritmtica e
teoria dos conjuntos. Contudo, como a maioria dos mtodos formais, o Event-B no
bem difundido na indstria pela dificuldade de compreenso dos conceitos matemticos envolvidos por grande parte dos desenvolvedores.
No presente captulo ser apresentado um processo de desenvolvimento orientado
a objetos com suporte verificao formal de inconsistncias, denominado BIconix.
O processo proposto tem como objetivo principal integrar o processo Iconix com o
mtodo Event-B, a fim de capturar o melhor dos dois mundos: a usabilidade fornecida
por um processo difundido e por uma notao visual conhecida (UML), e o conceito
de verificao apoiado por um mtodo formal, cujo uso essencial na deteco e correo de inconsistncias. Mais especificamente, o BIconix tem como propsito auxiliar
83
4.2
Viso Geral
84
4.3 Fases
4.3
85
Fases
O BIconix, assim como o Iconix, dividido em quatro fases sequenciais, cada uma
concluda por um marco principal, ou seja, cada fase essencialmente um intervalo de
tempo entre dois marcos. Ao final de uma fase executada uma reviso crtica para
determinar se os objetivos da fase foram alcanados. Uma avaliao positiva permite
que o projeto passe para a fase adiante.
O BIconix tambm define vrios ciclos de desenvolvimento at se alcanar o software desejado. Assim como no Iconix, uma passagem pelas quatro fases um ciclo de
desenvolvimento.
4.3.1
Definio de Requisitos
4.3 Fases
86
2. Modelo de Domnio: estabelece o escopo do problema, simplificando o seu entendimento ao capturar os conceitos envolvidos. tambm a mesma etapa presente no Iconix, com algumas poucas diferenas relacionadas sintaxe permitida
para elaborao do Modelo de Domnio.
3. Requisitos Comportamentais: define como o usurio e o sistema iro interagir
por meio de prottipos de interface e identificao/descrio de casos de uso,
como foco nas restries e pr/ps-condies existentes. uma tarefa bastante
semelhante etapa correspondente no Iconix, diferenciando-se basicamente por
algumas limitaes de sintaxe em relao ao Diagrama de Casos de Uso.
4. Modelo Restritivo: esta etapa no existe no Iconix e nela que se declaram as
restries impostas pelo domnio da aplicao e/ou partes interessadas em relao ao Modelo de Domnio, bem como a formalizao das pr/ps condies dos
casos de uso, incrementando assim o modelo Event-B gerado automaticamente.
Esse modelo Event-B ampliado ser aqui denominado de Modelo Restritivo.
Ressalta-se que antes de iniciar esta etapa realiza-se a reviso informal prevista
no Iconix original (ver captulo 2), mas que no ser tratada aqui novamente.
5. Primeiro Marco: efetua a reviso crtica dos requisitos, analisando se os casos de
uso e o Modelo de Domnio so consistentes por meio da verificao automtica
da consistncia do Modelo Restritivo, que providencia um retorno sobre possveis problemas de violao das restries exigidas. Ao contrrio do Iconix, que
apenas informalmente revisa os modelos UML para se avanar para a prxima
fase, no BIconix, caso algum problema seja encontrado na verificao formal,
todas as etapas devem ser repetidas.
4.3.2
4.3 Fases
87
4.3 Fases
4.3.3
88
Projeto Detalhado
A fase de Projeto Detalhado do BIconix tem como misso principal um detalhamento ainda maior do comportamento de cada caso de uso de acordo com a arquitetura escolhida, bem como a definio e verificao das ltimas restries. Os objetivos
principais desta terceira fase incluem:
Finalizar o design (projeto) de casos de uso usando os Diagramas de Sequncia.
Completar o Modelo de Classes.
Descrever as ltimas restries sobre o domnio da aplicao do software e as
pr/ps-condies sobre os Diagramas de Sequncia.
Verificar os modelos refinados do software, analisando se as restries no so
violadas.
Assim, esta fase tambm compreende quatro etapas:
1. Diagrama de Sequncia: elabora-se um Diagrama de Sequncia para cada caso
de uso de acordo com a arquitetura definida para mostrar em detalhes como ele
ser implementado. Esta etapa bastante semelhante do Iconix, apenas com o
Diagrama de Sequncia tendo algumas restries sintticas.
2. Atualizao do Modelo de Domnio: a distribuio de responsabilidade por cada
operao entre as classes definidas na etapa anterior provoca igualmente uma
atualizao no Modelo de Domnio que, ao incorporar tambm as classes de
interface, transforma-se em um Modelo de Classes, que um pouco diferente do
apresentado no Iconix por possuir algumas restries.
3. Refinamento do Modelo Restritivo: esta etapa, no existente no Iconix, tem
como objetivo incrementar e refinar o Modelo Restritivo criado na fase anterior com restries que surgiram com o desenvolvimento do Modelo de Classes
e com pr/ps condies dos Diagramas de Sequncia. Mais uma vez, antes
de se iniciar esta etapa, realiza-se a reviso informal prevista no Iconix original,
mas que no ser relatada aqui.
4.3 Fases
89
4. Terceiro Marco: realiza a reviso dos Diagramas de Sequncia para garantir que
o como do projeto corresponde ao o qu das fases anteriores por meio da
verificao do Modelo Restritivo, que providencia um retorno sobre possveis
problemas no refinamento dos modelos ou com a violao de alguma nova restrio. Ao contrrio do Iconix, assim como nas fases anteriores, no BIconix,
caso algum problema seja encontrado, todas as etapas devem ser repetidas.
4.3.4
Implementao
Esta fase, anloga presente no Iconix, tem como misso transformar o projeto
detalhado em cdigo executvel e test-lo. Mais especificamente, seus objetivos so:
Desenvolver o cdigo do software baseado no Modelo de Classes e Diagramas
de Sequncia modelados na fase anterior.
Elaborar Casos de Teste baseado nos modelos comportamentais do software.
Aplicar estes testes e realizar as correes necessrias.
Verificar a implementao do software com seus modelos e preparar o ambiente
para o prximo ciclo de desenvolvimento.
Assim, esta fase engloba as seguintes etapas, nenhuma automatizada:
1. Codificao: nesta etapa, idntica a presente no Iconix, realiza-se a transformao dos artefatos em cdigo de acordo com a linguagem orientada a objetos
escolhida (Java, C++, etc).
2. Testes: efetuam-se os Testes Unitrios, de integrao, sistema e aceitao. Para
cada mtodo implementado, cria-se um Teste Unitrio para o mesmo ou viceversa, caso a preferncia do desenvolvedor seja pela abordagem TDD. Os demais
testes so baseados nos casos de uso, sendo esta etapa similar a mesma do Iconix.
3. Quarto Marco: faz-se uma reviso do cdigo para corrigi-lo e valid-lo com a
especificao de requisitos a fim de se poder iniciar o prximo ciclo de desenvolvimento. Ao contrrio do Iconix, no possvel modificar os modelos j
criados, apenas o cdigo, uma vez que qualquer alterao neles pode anular as
verificaes formais j realizadas.
4.4
90
Fluxos de Trabalho
4.4.1
Definio de Requisitos
91
4.4.2
A Figura 4.3 apresenta de forma visual o fluxo de trabalho da fase de Anlise e Projeto Preliminar. Como se pode observar, o fluxo de trabalho desta fase praticamente
idntico ao apresentado pelo Iconix. As diferenas so: a incluso de uma atividade ao
seu final que refina o Modelo Restritivo criado na fase anterior , no qual se possvel
acrescentar mais Invariantes sobre o Modelo de Domnio Atualizado e Guardas/Aes
sobre os Diagramas de Robustez; a incluso de uma atividade para revisar o projeto
preliminar de maneira automatizada; e a repetio de todo o processo caso esta reviso
indique a necessidade.
4.4.3
Projeto Detalhado
92
4.4.4
Implementao
A Figura 4.5 apresenta de forma visual o fluxo de trabalho da fase de Implementao. Como se pode notar, o fluxo de trabalho desta fase anlogo ao mesmo apresentado pelo Iconix, apenas com a incluso no seu incio de uma atividade que vai
padronizar o Modelo de Classes com a arquitetura definida. Optou-se por no se re-
93
alizar uma verificao formal nesta fase uma vez que a aplicao de Casos de Testes
funcionais e Testes Unitrios j contribui bastante para a tarefa de verificao do software, ainda que informal, inclusive j contando com o suporte de boas ferramentas
automatizadas tais como o Selenium 2 e o JUnit 3 .
2 http://www.seleniumhq.org/
3 http://www.junit.org/
94
4.5
Papis e Atividades
95
4.5.1
Definio de Requisitos
96
Papel
Iconix
Selecionar os Requisitos
Participantes do Ciclo
Especificao de
Requisitos Formatada
Distinguir Requisitos
Funcionais de Restries
Descrever os Requisitos
Funcionais em Cenrios de Uso
Como se pode observar, essa atividade tem como finalidade utilizar o documento
de Especificao de Requisitos (artefato de entrada) recebido do cliente para facilitar
o desenvolvimento dirigido por casos de uso, como preconizado pelo Iconix. Assim,
a primeira tarefa a seleo dos requisitos que iro participar do ciclo de desenvolvimento atual, seguido pela distino destes entre funcionais e restries. Depois disso,
os requisitos funcionais devem ser descritos em termos comportamentais, ou seja, em
cenrios operacionais, tendo-se assim uma Especificao de Requisitos Formatada (artefato de sada). importante observar que todas estas tarefas so realizadas pelo papel
Iconix.
A prxima atividade desta fase Identificar objetos do mundo real relacionados
com o domnio do problema, cujo detalhes encontram-se na Figura 4.7. Essa atividade
tem como objetivo capturar os objetos relacionados com o domnio do problema, o que
est de acordo com o paradigma orientado a objetos, que seguido pelo Iconix. Assim,
ela inclui entre suas tarefas a seleo dos mais relevantes substantivos e verbos presentes no artefato de entrada (Especificao de Requisitos Formatada), descrevendo-os
em termos comuns ao projeto de tal forma que auxilie a compreenso dos conceitos
envolvidos e a comunicao entre os membros da equipe, criando assim um Glossrio.
Novamente, todas estas tarefas so executadas pelo papel Iconix.
A outra atividade do fluxo de trabalho desta fase que pode ocorrer em paralelo
descrita anteriormente a Fazer rapidamente prottipos de tela, cujo detalhamento
encontra-se na Figura 4.8. Esta atividade tem como finalidade produzir uma sequncia
97
Glossrio
Capturar um Vocabulrio Comum
de telas e interfaces grficas como ponto de partida para simular a interao entre usurios e sistema, facilitando assim o seu entendimento pelas partes envolvidas. Assim
sendo, esta atividade inclui a tarefa de modelagem dos prottipos de tela, com a definio dos campos, seus nomes e tipos, bem como de botes e links. Para isso, recebe
a Especificao de Requisitos Formatada como artefato de entrada e interage tambm
com o artefato Glossrio a fim de se manter uma coerncia dos termos conceituais no
projeto. Finalmente, h ainda a tarefa de implement-los, criando como artefato de
sada os Prottipos GUI. Nota-se que, mais uma vez, estas tarefas so desempenhadas
pelo papel Iconix.
Especificao de
Requisitos Formatada
Papel
Iconix
Modelar as Interfaces
do Usurio
Glossrio
Prottipos GUI
98
Glossrio
Papel
Iconix
Analisar Glossrio e
Conceitos-chave
Desenvolver Modelo
de Domnio
Modelo de
Domnio
Papel
Iconix
Prottipos GUI
Localizar Atores
e Casos de Uso
Desenvolver o Diagrama
de Casos de Uso
Diagrama de
Casos de Uso
Essa atividade tem como propsito identificar os atores e casos de uso presentes no
contexto do software, bem como o relacionamento existente entre eles. Assim, a sua
tarefa inicial a de localizar os atores e casos de uso usando dois artefatos de entrada
(Prottipos GUI e Especificao de Requisitos Formatada) como apoio. Depois, h
uma tarefa na qual se elucidam os relacionamentos entre atores e casos de usos. Por
fim, a ltima tarefa a criao do Diagrama de Casos de Uso (artefato de sada),
desenhando-se os casos de uso, os atores, bem como seus relacionamentos, usando
99
Papel
Iconix
Diagrama de
Casos de Uso
Modelo de
Domnio
Relacionar Casos de
Uso com Objetos
Matriz de
Rastreabilidade
100
Especificao de
Requisitos Formatada
Modelo de
Domnio
Prottipos GUI
Descrever os Fluxos
Alternativos de Eventos
Papel
Iconix
Descrever as
Pr-condies
Descrever o Fluxo
Principal de Eventos
Descrever as
Ps-condies
Incluir Pontos de
Relacionamento
Descrio dos
Casos de Uso
Figura 4.12: Detalhamento da atividade Escrever uma verso dos casos de uso
Fonte: o autor
Diagrama de
Casos de Uso
Descrio dos
Casos de Uso
Especificao de
Requisitos Formatada
Viabilizar Restries
Papel
Event-B
Gerar Modelo
Abstrato Event-B
Incluir Invariantes
e Guardas e Aes
Viabilizar Pr e
Ps Condies
Modelo Abstrato
Event-B
101
Formatada e das pr e ps-condies existentes na Descrio dos Casos de Uso em Invariantes, Guardas/Aes descritas na notao Event-B, respectivamente. Todas essas
tarefas so executadas pelo papel Event-B, tendo como resultado um Modelo Abstrato
Event-B completo e pronto para ser verificado.
A ltima atividade desta fase Revisar Requisitos (detalhes na Figura 4.14), cujo
objetivo definir o primeiro marco como realizador da reviso dos requisitos. Assim,
as primeiras duas tarefas so executadas pelo papel Event-B. A primeira se encarrega
de realizar a verificao automtica do Modelo Abstrato Event-B por meio da ferramenta Rodin. A segunda, analisa os resultados recebidos, usando o retorno provido
pela ferramenta por meio do mapeamento de volta dos erros para os modelos UML.
Depois disso, o papel Iconix, munido do Modelo de Domnio, da Descrio dos Casos
de Uso e da Especificao de Requisitos Formatada, discute com o papel Event-B os
possveis problemas encontrados para tentar esclarecer os erros de modelagem.
Modelo de
Domnio
Descrio dos
Casos de Uso
Especificao de
Requisitos Formatada
Papel
Iconix
Discutir
Problemas
Papel
Event-B
Verificar
Formalmente
Analisar
Resultados
Modelo Abstrato
Event-B
Essa fase se encerra com a Aprovao da Fase 1, que ocorre apenas se nenhum
erro foi encontrado na atividade de Revisar Requisitos. Caso existam problemas, a
fase deve ser repetida a fim de se eliminar as falhas ocorridas durante a modelagem.
102
4.5.2
Papel
Iconix
Prottipos GUI
Sugerir
Arquitetura
Descrio dos
Casos de Uso
Contruir Prova de
Conceito Arquitetnico
Especificao de
Requisitos Formatada
Avaliar Viabilidade
Arquitetnica
Modelo de
Arquitetura
Esta atividade tem como objetivo definir a arquitetura que ser usada como guia
durante o desenvolvimento do software. Assim, a primeira tarefa propor tal arquitetura, se ser MVC, cliente-servidor, desktop, etc, bem como qual linguagem orientada
a objetos (Java, C++, etc) e framework (Spring, VRaptor, etc) sero usados. Depois
disso, constri-se uma rpida prova conceitual desta arquitetura para analisar a sua
viabilidade tcnica, produzindo por fim um Modelo de Arquitetura. Essas tarefas,
que recebem o suporte de quatro artefatos de entrada (Modelo de Domnio, Prottipos
GUI, Descrio dos Casos de Usos e Especificao de Requisitos Formatada), so
todas executadas pelo papel Iconix.
O prximo passo do fluxo de trabalho dessa fase Realizar a anlise de robustez
para cada caso de uso que faz parte do ciclo de desenvolvimento atual. Este envolve
trs atividades: Revisar a verso do caso de uso em busca de ambiguidades, Identificar
os objetos que acompanham cada cenrio e Atualizar o Modelo de Domnio com os
objetos e atributos descobertos.
O detalhamento da primeira atividade encontra-se na Figura 4.16 e tem como finalidade esclarecer o caso de uso, minimizando as possveis ambiguidades, bem como
projetando a sua adequao arquitetura definida. Para isso, o desenvolvedor com
papel Iconix recebe o Modelo de Arquitetura e o Modelo de Domnio e desenha o Diagrama de Robustez, que abastecido pela Descrio de Casos de Uso, e ao mesmo
103
tempo serve para redefini-la. Mantem-se ento uma retroalimentao contnua at que
a descrio textual do caso de uso analisado seja fielmente idntica leitura proporcionada pelo diagrama desenhado.
Modelo de
Arquitetura
Modelo de
Domnio
Descrio dos
Casos de Uso
Diagrama de
Robustez
Re-escrever Casos de Uso
Diagrama de
Robustez
Selecionar Entidades
Atualizar Matriz de
Rastreabilidade
Papel
Iconix
Destacar Substantivos
Matriz de
Rastreabilidade
Essa atividade usada para levantar novos objetos e atributos descobertos durante
a atividade de Revisar a verso do caso de uso em busca de ambiguidades. Para
isso, o desenvolvedor com papel Iconix usa o Modelo de Domnio como artefato de
entrada para fazer uma comparao com o Diagrama de Robustez, a fim de selecionar as classes de entidade deste que no esto presentes naquele. Alm disso, este
104
mesmo desenvolvedor tem como segunda tarefa se encarregar de marcar alguns substantivos presentes no Diagrama de Robustez, que potencialmente se tornaro atributos.
Por fim, ele atualiza a Matriz de Rastreabilidade com as novas classes descobertas,
relacionando-as com seus casos de uso.
A atividade imediatamente seguinte identificao dos objetos de cada cenrio
a Atualizar o Modelo de Domnio com os objetos e atributos descobertos, cujo detalhamento pode ser visualizado na Figura 4.18.
Diagrama de
Robustez
Papel
Iconix
Copiar Entidades
Modelo de
Domnio
Associar Atributos
Modelo de Domnio
Atualizado
105
Glossrio
Diagrama de
Robustez
Papel
Iconix
Designar Tipos
aos Atributos
Modelo de Domnio
Atualizado
Criar
Relacionamentos
Diagrama de
Robustez
Especificao de
Requisitos Formatada
Viabilizar Restries
Papel
Event-B
Gerar Modelo
Event-B Ref. 1
Incluir Invariantes
e Guardas e Aes
Viabilizar Pr e
Ps Condies
Modelo Event-B
Ref. 1
106
presentes nos casos de uso e que esto relacionadas s classes de controle dos Diagramas de Robustez, analisando-se como convert-las em Guardas e Aes expressas
na notao Event-B. Todas essas atividades so executadas pelo papel Event-B, tendo
como resultado um Modelo Event-B Ref. 1.
A ltima atividade dessa fase Revisar Projeto Preliminar (detalhes na Figura 4.21).
Modelo de Domnio
Atualizado
Diagrama de
Robustez
Especificao de
Requisitos Formatada
Papel
Iconix
Discutir
Problemas
Papel
Event-B
Verificar
Formalmente
Analisar
Resultados
Modelo Event-B
Ref. 1
107
Essa fase se encerra com a Aprovao da Fase 2, que ocorre apenas se nenhum erro
foi encontrado na atividade de Revisar Projeto Preliminar. Caso existam problemas, a
fase deve ser repetida a fim de se eliminar as falhas ocorridas durante a modelagem.
4.5.3
Projeto Detalhado
O primeiro passo do fluxo de trabalho da terceira fase do processo BIconix Alocar comportamento elaborando um Diagrama de Sequncia para cada Diagrama de
Robustez que faz parte do ciclo de desenvolvimento atual. Este envolve trs atividades: Gerar o modelo do Diagrama de Sequncia a partir das classes de interface e
entidade do Diagrama de Robustez, Desenhar as mensagens entre objetos e Atualizar
o Diagrama de Classes com os atributos e operaes descobertas.
O detalhamento da primeira atividade encontra-se na Figura 4.22 e tem como finalidade projetar o modelo do Diagrama de Sequncia que est sendo elaborado, apresentando os objetos envolvidos.
Diagrama de
Robustez
Papel
Iconix
Copiar Casos
de Uso
Copiar
Entidades
Copiar
Interfaces e Atores
Diagrama de
Sequncia
108
Diagrama de
Robustez
Papel
Iconix
Desmembrar
Controles
Alocar
Operaes
Incluir
Parmetros
Essa atividade uma das mais importantes e difceis de serem executadas dentro
do processo BIconix pelo papel Iconix. Seu objetivo mostrar como o comportamento
do caso de uso realizado pelos objetos, tarefa primordial para o sucesso do projeto sob
o ponto de vista do paradigma orientado a objetos. Assim, a primeira tarefa analisar
as classes de controle do Diagrama de Robustez a fim de se saber se cada uma delas
se transformar em uma ou mais operaes. A segunda tarefa alocar as operaes
conforme se desenha a troca de mensagens entre os objetos do diagrama. Nesta tarefa
deve-se evitar desperdiar tempo se preocupando com a passagem de controle entre os
objetos, mas sim em manter a coerncia entre o diagrama e o caso de uso, adaptando-o
e re-escrevendo-o quando necessrio. Finalmente, para cada operao, deve-se analisar
a descrio textual do caso de uso presente no Diagrama de Sequncia a fim de se
identificar os seus parmetros de entrada e sada. Essa atividade tem como artefato de
sada um Diagrama de Sequncia completo.
A prxima atividade do fluxo de trabalho dessa fase Atualizar o Modelo de Classes com os atributos e operaes descobertas, cujo detalhamento pode ser visualizado
na Figura 4.24, e objetiva transformar o Modelo de Domnio Atualizado em um Modelo
de Classes. Assim, a primeira tarefa transpor as classes de interface provenientes do
Diagrama de Sequncia para o Modelo de Domnio Atualizado, criando-se assim um
Modelo de Classes, uma vez que est ocorrendo uma transformao do domnio do
problema para o domnio da soluo. Depois disso, transporta-se as operaes encontradas no Diagrama de Sequncia como mtodos para as suas respectivas classes.
109
Logo em seguida, analisa-se os parmetros tanto de entrada quanto de sada das operaes do Diagrama de Sequncia a fim se encontrar novos atributos (e seus tipos) e
associ-los s suas classes. Estas trs tarefas so desempenhadas pelo papel Iconix,
sendo as duas primeiras passveis de automatizao.
Diagrama de
Sequncia
Modelo de Domnio
Atualizado
Copiar Interfaces
Papel
Iconix
Copiar Operaes
Incluir Atributos
Modelo de
Classes
Diagrama de
Sequncia
Especificao de
Requisitos Formatada
Viabilizar Restries
Papel
Event-B
Gerar Modelo
Event-B Ref. 2
Incluir Invariantes
e Guardas e Aes
Viabilizar Pr e
Ps Condies
Modelo Event-B
Ref. 2
110
Diagrama de
Sequncia
Especificao de
Requisitos Formatada
Papel
Iconix
Discutir
Problemas
Papel
Event-B
Verificar
Formalmente
Analisar
Resultados
Modelo Event-B
Ref. 2
111
4.5.4
Implementao
A quarta e ltima fase do BIconix comea com uma atividade que originalmente
est presente no Projeto Detalhado do Iconix (Enxugar e limpar o modelo esttico),
mas que foi transferida para esta fase para evitar complexidades desnecessrias de
formalizao, sem prejuzo significativo para o processo. Essa atividade, cujo detalhamento apresentado na Figura 4.27, tem como finalidade fazer uma reviso mais
apurada no Modelo de Classes.
Modelo de
Classes
Modelo de
Arquitetura
Papel
Iconix
Padronizar
Modelo
Caracterizar
Arquitetura
112
A prxima atividade dessa fase Gerar o modelo das classes, cujos detalhes
encontram-se na Figura 4.28.
Modelo de
Classes
Papel
Iconix
Criar Classes
Bsicas
Modelo de
Arquitetura
Adicionar Classes
Auxiliares
Cdigo
Fonte
Essa atividade tem como objetivo gerar o primeiro cdigo a partir do Modelo de
Classes existente. Para isso, a primeira tarefa criar um Cdigo-Fonte (artefato de
sada) com as classes na linguagem de programao definida no Modelo de Arquitetura, inserindo seus atributos, mtodos, construtores, etc. Depois disso, adicionam-se
classes auxiliares que esto relacionadas arquitetura e tecnologias aplicadas ao projeto, como classes DAO, classes de sesses, etc. Mais uma vez, essas tarefas so
desempenhadas pelo papel Iconix, sendo algumas delas passveis de automatizao.
O prximo passo do fluxo de trabalho da quarta fase Codificar e Testar cada
operao do Diagrama de Sequncia e envolve trs atividades: Escrever cdigo-fonte,
Implementar testes unitrios e Executar os testes. importante destacar que a ordem
de execuo destas depende da opo do desenvolvedor, se ele prefere implementar os
Testes Unitrios antes ou depois de escrever o cdigo.
O detalhamento da primeira atividade, Escrever cdigo-fonte, encontra-se na Figura 4.29. Ela uma das mais importantes de todo o processo e objetiva transformar
o Modelo de Arquitetura, os Prottipos GUI e o comportamento definido pelos Diagramas de Sequncia em Cdigo-Fonte. Assim, a primeira tarefa investigar como as
classes de interface e entidades sero implementadas. As primeiras podem se tornar,
por exemplo, pginas web (PHP, JSP, etc), enquanto que as classes de entidade podem
ser a base para o desenvolvimento de um possvel banco de dados. A segunda tarefa
analisar e projetar qual a mais conveniente estrutura de dados e o melhor algoritmo
para resolver de forma efetiva a funcionalidade proposta por cada operao (Exemplo:
113
se a operao for de ordenao, escolher se vai usar quicksort, mergesort, etc). Em seguida, codifica-se o algoritmo na linguagem de programao escolhida para o projeto,
adaptando-o para a estrutura, as entradas e sadas do mtodo correspondente. Essas
tarefas so realizadas pelo papel Iconix.
Modelo de
Arquitetura
Papel
Iconix
Diagrama de
Sequncia
Cdigo
Fonte
Prottipos GUI
Realizar Entidades
e Interfaces
Selecionar
Algoritmos
Codificar
Comportamento
A atividade seguinte Implementar testes unitrios, cujos detalhes podem ser visualizados na Figura 4.30.
Diagrama de
Sequncia
Papel
Iconix
Selecionar
Tcnica
Estabalecer
Conjunto de Dados
Codificar
Teste
Teste
Unitrio
Essa atividade tem como objetivo aplicar o primeiro conjunto de testes do processo
BIconix, mais especificamente Testes Unitrios para cada uma das operaes presentes
nos Diagramas de Sequncia. Assim sendo, a sua primeira tarefa escolher a melhor
tcnica de testes para o projeto, podendo-se utilizar at mais que uma. A maioria das
abordagens se volta para a criao de quatro tipos de scripts de testes: manual, na qual
o teste executado mecanicamente pelo testador; programado, no qual possvel se
planejar a sua execuo, sendo bastante usado atualmente pelos testadores que usam
114
Papel
Iconix
Cdigo
Fonte
Configurar
Ambiente
Aplicar
Testes Unitrios
Inspecionar
Resultados
Essa atividade, executada pelo papel Iconix, tem como finalidade aplicar os testes
definidos (Teste Unitrio) na atividade Implementar testes unitrios a fim de verificar
se o Cdigo-Fonte est de acordo com as funcionalidades esperadas. Assim, tem-se
como primeira tarefa a configurao do ambiente de testes, na qual deve-se garantir
que toda a infra-estrutura necessria para a execuo do teste esteja disponvel, tais
como hardware, banco de dados, etc. Logo em seguida, os Testes Unitrios so executados e os resultados obtidos so analisados. Caso ocorra algum erro, deve-se retornar
atividade Escrever cdigo-fonte a fim de corrigi-lo. Caso contrrio, pode-se prosseguir para a prxima atividade, Efetuar testes de integrao, sistema e aceitao, cujos
detalhes aparecem na Figura 4.32.
4 http://www.qunitjs.com/
5 http://code.google.com/p/googletest/
115
Papel
Iconix
Diagrama de
Robustez
Projetar
Testes
Cdigo
Fonte
Executar
Testes
Casos de Teste
Apurar
Resultados
Essa atividade tem como objetivo finalizar o conjunto de testes a serem aplicados
no software a fim de verificar se ele atende ao que foi especificado. Assim, a primeira
tarefa projetar Casos de Teste de integrao, sistema e aceitao. Para o primeiro
caso, como as classes de controle dos Diagramas de Robustez correspondem na maioria das vezes a uma ou mais operaes dos Diagramas de Sequncia, os testes so
derivados a partir destas classes a fim de se verificar a integrao entre as respectivas
operaes. Para o segundo caso, os testes so definidos usando completamente os Diagramas de Robustez a fim de tentar simular o comportamento que so representados
por eles. Em seguida os testes de aceitao so aplicados tendo como base a descrio
dos casos de uso e todos os resultados so apurados. Como se pode observar, essas trs
tarefas devem ser realizadas pelo papel Iconix.
A ltima atividade dessa fase Revisar Cdigo (detalhes podem ser vistos na Figura 4.33), cujo objetivo analisar se o cdigo atende aos casos de usos selecionados
para aquele ciclo de desenvolvimento. Assim, a primeira tarefa examinar os resultados dos testes de integrao, sistema e aceitao e confront-los com a especificao
de requisitos. Caso exista alguma divergncia, o cdigo deve ser modificado a fim de
atend-la.
Essa fase se encerra com o quarto marco, Aprovao da Fase 4, que ocorre aps a
correo dos problemas na atividade Revisar Cdigo, e um novo ciclo de desenvolvimento pode ser iniciado.
116
4.6 Artefatos
Especificao de
Requisitos Formatada
Papel
Iconix
Casos de Teste
Examinar
Resultados
Cdigo
Fonte
Corrigir
Cdigo
4.6
Artefatos
117
4.6 Artefatos
Diagrama de
Casos de Uso
Descrio dos
Casos de Uso
Diagrama de
Sequncia
Diagrama de
Robustez
Teste
Unitrio
Prottipos GUI
Casos de Teste
Modelo de
Domnio
Cdigo
Fonte
Modelo de Domnio
Atualizado
Especificao de
Requisitos Formatada
Modelo de
Classes
Modelo Event-B
Ref. 2
Modelo Event-B
Ref. 1
Modelo Abstrato
Event-B
4.6.1
Definio de Requisitos
O conjunto de artefatos produzidos nesta fase pode ser visualizado na Figura 4.35.
importante ressaltar que o artefato Especificao de Requisitos, como no Iconix, no
gerado durante o processo, j sendo recebido do cliente/analista de negcio. Assim,
este artefato no ser explicitamente detalhado aqui. Apesar de ser muito importante
ao apresentar os requisitos e escopo do projeto, sua sintaxe e o padro utilizados sero
considerados genricos.
Especificao de
Requisitos Formatada
Diagrama de
Casos de Uso
Modelo de
Domnio
Prottipos GUI
Papel
Iconix
Papel
Event-B
Matriz de
Rastreabilidade
Glossrio
Modelo Abstrato
Event-B
Descrio dos
Casos de Uso
O artefato de Especificao de Requisitos Formatada tem como finalidade organizar os requisitos de maneira mais lgica sob o ponto de vista de um desenvolvimento
dirigido por casos de uso com suporte verificao de inconsistncias, facilitando as-
4.6 Artefatos
118
4.6 Artefatos
119
O artefato Modelo de Domnio tem como propsito relacionar os principais conceitos envolvidos no software, ajudando a definir uma arquitetura inicial sob o ponto
de vista da orientao a objetos. Este artefato composto essencialmente por classes
conceituais, representadas por retngulos, e associaes, que relacionam esses conceitos, podendo ser generalizaes ou agregaes. Os detalhes da sintaxe e semntica
dos componentes do Modelo de Domnio sero apresentados no captulo sobre o mapeamento para Event-B, uma vez que este artefato faz parte dos que so formalizados,
possuindo portanto algumas limitaes sintticas.
O artefato Prottipos GUI tem como finalidade auxiliar o papel Iconix na descoberta e identificao dos casos de uso que participam do ciclo de desenvolvimento
atual, uma vez que, para a maioria dos sistemas de software, a interao entre usurios
e sistema ocorre via telas, janelas ou pginas. Esse artefato pode se manifestar como:
esboos em papel ou figuras; bitmaps feitos com uma ferramenta apropriada, como
por exemplo o Microsoft Power Point; ou prottipos de execuo interativa feitos em
alguma linguagem adequada, como por exemplo HTML. Assim, o BIconix prope que
o padro utilizado para esse artefato seja genrico, o que permite grande liberdade de
criao ao desenvolvedor.
O artefato Matriz de Rastreabilidade tem como finalidade manter o rastreamento
entre os requisitos, os casos de uso e as classes envolvidas. Como o BIconix um processo orientado a objetos e dirigido por casos de uso, usando-se este artefato possvel
relacionar estes trs conceitos, minimizando os impactos das mudanas de requisitos,
bem como facilitando a verificao de que eles foram implementados. Muitas ferramentas de desenvolvimento (Enterprise Architect, Visual Studio, etc) possuem dentre
suas funcionalidades o rastreamento de requisitos e podem ser usadas para a construo deste artefato. No entanto, a forma mais comum a criao de um documento
contendo duas tabelas: uma para o cruzamento requisitos versus casos de uso e outra
para o mapeamento classes versus casos de uso. Para o primeiro caso, os requisitos se
instalam nas colunas por meio de seus identificadores (F1, F2, etc), enquanto que os
nomes dos casos de uso ficam nas linhas. Para cada correspondncia entre eles, marcase um X na tabela. O segundo caso semelhante, mas com os nomes das classes se
posicionando nas colunas no lugar dos requisitos. Um exemplo do padro utilizado
nas tabelas que compem este artefato pode ser visualizado na Figura 4.37.
120
4.6 Artefatos
O Glossrio define termos importantes usados pelo projeto, mantendo uma linguagem unificada, ajudando a evitar interpretaes erradas e facilitando a comunicao entre as partes interessadas. Pode ser usado tanto para projetar classes, tabelas
de banco de dados e interfaces de usurio, quanto para manuais sobre o software e
material de treinamento. Assim, este artefato um documento bem simples, com apenas uma seo na qual se esclarecem os significados das palavras-chave do projeto,
podendo inclusive se dar detalhes sobre o domnio e o tamanho destes termos. Um
exemplo do padro utilizado nesse artefato apresentado na Figura 4.38.
O artefato Descrio dos Casos de Uso um dos mais importantes artefatos desta
fase e tem como objetivo expressar o comportamento do software por meio de cenrios
de uso de uma forma organizada e de fcil compreenso para os participantes do projeto. Os casos de uso devem ser escritos em voz ativa, no formato sujeito-verbo-objeto,
usando um fluxo evento/resposta para descrever os dois lados do dilogo ator /sistema.
Deve-se dar uma ateno especial aos fluxos alternativos a fim de tentar garantir que
todos os caminhos foram diagnosticados. importante tambm que cada caso de uso
tenha explicitado as suas pr e ps-condies de operao, que faz parte das melhores
prticas da engenharia de software, alm da indicao dos pontos de relacionamento
4.6 Artefatos
121
com outros casos de uso. Assim, este artefato um documento no qual cada caso de
uso descrito possui: Nome, Atores, Pr-condies, Fluxo Bsico, Fluxos Alternativos,
Ps-condies e Pontos de Relacionamento. Um exemplo do padro utilizado para
esse artefato pode ser visualizado na Figura 4.39.
122
4.6 Artefatos
4.6.2
Papel
Iconix
Diagrama de
Robustez
Modelo de Domnio
Atualizado
Modelo Event-B
Ref. 1
Papel
Event-B
4.6 Artefatos
123
4.6 Artefatos
124
125
4.6 Artefatos
4.6.3
Projeto Detalhado
Papel
Iconix
Modelo de
Classes
Modelo Event-B
Ref. 2
Papel
Event-B
126
4.6 Artefatos
4.6.4
Implementao
O conjunto de artefatos produzidos nessa ltima fase pode ser visualizado na Figura 4.43.
Cdigo
Fonte
Teste
Unitrio
Casos de Teste
Papel
Iconix
O artefato Cdigo-Fonte responsvel por finalmente transformar todos os modelos criados anteriormente em um produto de software que possa ser utilizado pelo
cliente. Esse artefato inclui no somente o cdigo relativo ao ncleo do sofware, mas
tambm ao cdigo das interfaces grficas e aos scripts das tabelas de banco de dados,
caso existam, criando assim um produto completo. Por ser dependente das linguagens
e tecnologias escolhidas, esse artefato no possui um modelo-padro, mas se recomenda o uso de padres de codificao existentes na indstria, tais como o MISRA
C++ 6 e o Code Conventions for the Java Programming Language 7 .
Os testes so bastante importantes como complemento da verificao formal proposta nas fases anteriores. No BIconix, a atividade de testes produz dois artefatos. O
primeiro deles, Teste Unitrio, tem como objetivo aplicar testes nas menores unidades
executveis do software, que so as operaes, simulando diversas entradas possveis
e observando se o comportamento est dentro do esperado. Por ser bastante dependende da tcnica e ferramenta escolhida, no h um padro para eles. No entanto,
recomenda-se realizar comentrios no prprio cdigo dos scripts a fim de facilitar o
mapeamento do teste para a operao. O segundo artefato relacionado a essa atividade
6 http://www.misra.org.uk/
7 http://www.oracle.com/technetwork/java/codeconv-138413.html
127
4.6 Artefatos
conhecido como Casos de Teste, cuja finalidade definir os valores dos testes a serem aplicados no nvel de integrao, sistema e aceitao. Assim, esse artefato um
documento composto basicamente por tabelas que formam uma espcie de checklist
dos testes a serem realizados. Cada caso de uso possui uma tabela para representar
o teste de aceitao, na qual as entradas a serem testadas so colocadas nas linhas, o
resultado esperado na primeira coluna e o resultado observado na segunda, sendo marcado OK quando forem iguais ou KO, caso contrrio. Tabelas semelhantes devem
ser produzidas para representar os testes de integrao e sistema, com a diferena que
neste caso cada tabela refere-se a uma classe (ou conjunto de classes) de controle dos
Diagramas de Robustez. Um exemplo de padro utilizado nas tabelas que compem
este artefato pode ser visualizado na Figura 4.44.
128
FORMALIZAO DO
BICONIX
5.1
Definio de Semntica
O termo semntica tem sido usado de maneiras diferentes, com algumas confundindo a semntica com restries de construo dos elementos de uma linguagem, ou
seja, misturando os conceitos de sintaxe de uma notao com sua semntica. Neste
trabalho, foi utilizada a seguinte definio apresentada por (LANO, 2009):
129
5.2
Abordagens Semnticas
Ainda de acordo com (LANO, 2009), h vrias maneiras possveis para se definir a
semntica de uma notao. Abaixo, esto algumas das principais abordagens utilizadas
para prover uma semntica formal para uma linguagem:
Algbrica: mapeia os elementos de uma notao em expresses algbricas;
Axiomtica: mapeia os componentes de uma linguagem em teorias lgicas, consistindo de estruturas matemticas (juntamente com axiomas) que definem suas
propriedades;
Meta-modelagem: define os elementos de uma notao L1 como um modelo em
uma notao L2 (possivelmente a mesma notao L1 );
Operacional: mapeia os componentes de uma notao em estruturas de um ambiente de execuo abstrato;
Transformacional: mapeia os elementos de uma linguagem L1 em elementos de
uma linguagem L2 , que j tem uma semntica definida, a fim de atribuir uma
semntica para L1 .
130
Cada uma dessas abordagens tem vantagens e desvantagens, oferecendo diferentes tipos de anlise. Por exemplo, o mapeamento algbrico bom para verificar a
igualdade de modelos (por ex: analisar a validade das leis associativas e comutativas)
e a modelagem axiomtica boa para fazer anlises de teoremas gerais, mas ambas
exigem um forte formalismo que muitas vezes no pode ser verificado por alguma ferramenta existente. J as abordagens de meta-modelagem e transformacional so mais
fceis de serem desenvolvidas, embora necessitem de uma segunda linguagem com
semntica bem definida. Na prxima seo sero apresentadas as razes da escolha de
uma abordagem transformacional para este trabalho.
5.3
131
5.4
O Meta-Modelo do Event-B
132
133
134
5.5
O meta-modelo apresentado nesta seo define os elementos presentes no diagrama que representa a parte esttica de um software dentro do BIconix: o Diagrama
de Classes. importante ressaltar que, apesar de o processo diferenciar Modelo de
Domnio de Diagrama de Classes, do ponto de vista prtico, ambos possuem os mesmos componentes, sendo bastante semelhantes. Por isso, optou-se por se ter apenas
um meta-modelo para ambos. Outro ponto a se destacar que a modelagem proposta
fortemente baseada no meta-modelo do Diagrama de Classes do UML-B (SNOOK;
BUTLER, 2006), com uma mudana para incorporar associaes do tipo agregao.
Assim, o meta-modelo apresentado bem mais simples que o especificado pela OMG
135
Maiores detalhes sobre a semntica, restries, notao, etc, de cada uma das metaclasses do meta-modelo do Diagrama de Classes do BIconix podem ser encontrados
no Apndice A.
5.6
136
5.7
137
5.8
138
139
5.9
Regras de Transformao
Uma vez definidos os meta-modelos que representam a linguagem dos quatro diagramas que se deseja atribuir uma semntica formal, bem como o meta-modelo da
linguagem Event-B, a prxima etapa definir as regras de transformao que mapeiam os elementos destas linguagens. Essas regras sero baseadas em funes que
tero como entrada instncias dos quatro diagramas especificados e como sada uma
especificao Event-B. Como relatado anteriormente, a abordagem escolhida foi pela
utilizao do QVT, uma linguagem formal baseada em OCL e padronizada pela OMG,
como ferramenta para descrio dessas regras. Para facilitar o entendimento e evitar
uma explicao prolongada sobre essa notao, decidiu-se apresentar de forma simples
e direta o mapeamento sugerido por meio de exemplos. No entanto, os detalhes da sintaxe do QVT, assim com as regras formais das transformaes propostas, encontram-se
no Apndice B. importante destacar que esse trabalho segue uma abordagem pragmtica como o UML-B, ficando fora do seu escopo a anlise de corretude (soundness)
e completeza (completeness) dessas regras.
140
5.9.1
141
Para cada um dos elementos presentes no Diagrama de Classes/Modelo de Domnio do BIconix ser apresentado o seu equivalente na linguagem Event-B.
5.9.1.1
BIconixClassDiagram
Em Event-B
Uma instncia de uma meta-classe BIconixClassDiagram mapeada diretamente
em uma instncia da meta-classe Context, recebendo o mesmo nome daquela.
Exemplo
Se o nome de um Diagrama de Classes for BooksOnLine, como na Figura 5.9,
BIconixClass
Em Event-B
A meta-classe BIconixClass gera cinco mapeamentos no Event-B: um no Context
e outros quatro na Machine. No primeiro caso gerado um conjunto global (CarrierSet) chamado {BIconixClass.name}_SET. No segundo so gerados: uma Variable
com o mesmo nome da instncia da meta-classe; uma Invariant como um subconjunto do conjunto global criado no Context ({BIconixClass.name} P({BIconixClass.name}_SET)), correspondendo s instncias daquela classe; uma Event, como
142
o construtor da classe, chamada Cons_{BIconixClass.name}, com uma Parameter denominada self, uma Guard nomeada self {BIconixClass.name}_SET\ {BIconixClass.name} e uma Action designada {BIconixClass.name} := {BIconixClass.name}
{self}; e uma Event, como o destrutor da classe, chamada Des_{BIconixClass.name},
com uma Parameter nomeada self, uma Guard designada self {BIconixClass.name}
e uma Action denominada {BIconixClass.name} := {BIconixClass.name}\{self}.
Exemplo
Se uma classe nomeada Catalog no Diagrama de Classes, como na Figura 5.10,
143
Event Des_Catalog =
b
any
self
where
grd1 : self Catalog
then
act1 : Catalog := Catalog \ {self}
end
5.9.1.3
BIconixAttribute
Em Event-B
Uma instncia da meta-classe BIconixAttribute mapeada como uma instncia de
Invariant, sendo um elemento pertencente a uma funo total cujo domnio o nome da
classe e a imagem tipo do atributo ({BIconixAttribute.name} {BIconixClass.name}
{BIconixAttribute.type})
Exemplo
Se uma classe chamada Catalog possui um atributo nomeado active do tipo
booleano, como mostrado na Figura 5.11,
5.9.1.4
144
BIconixAssociation
Em Event-B
A meta-classe BIconixAssociation abstrata, portanto no possui instncias e consequentemente no possui um mapeamento direto para os elementos concretos (Machine ou Context) do meta-modelo do Event-B, sendo usada para criar uma base comum para associaes dos tipos generalizao e agregao com instncias da metaclasse BIconixClass.
Exemplo
Sem exemplos concretos.
5.9.1.5
BIconixGeneralization
Em Event-B
Uma instncia da meta-classe BIconixGeneralization mapeada como uma instncia de uma Invariant, fazendo com uma classe filha corresponda a um subconjunto
da classe pai ({BIconixClass.name} P({BIconixClass.name})).
Exemplo
Se uma classe chamada Catalog possui uma classe especializada denominada
Mini-Catalog, como na Figura 5.12,
5.9.1.6
145
BIconixAggregation
Em Event-B
Uma instncia da meta-classe BIconixAggregation mapeada em uma Invariant,
correspondendo a um elemento pertencente a uma relao entre as duas classes associadas. O tipo dessa relao (sobrejetora, injetora, total, funo, etc) depende da multiplicidade da agregao, ou seja, dos valores de seus quatro atributos (lowersource,
uppersource, lowertarget e uppertarget). Essas regras de traduo encontram-se na
tabela 5.1.
Exemplo
Se uma classe chamada Catalog possui uma agregao denominada itens com
uma classe nomeada Book e uma multiplicidade definida (por exemplo: 0, n, 1, n),
como na Figura 5.13,
5.9.2
BIconixUCDiagram
Em Event-B
146
upper
target
n
Event-B
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
7 BIconixClass.name
BIconixAttribute.name BIconixClass.name
BIconixClass.name
147
Uma instncia de uma meta-classe BIconixUCDiagram mapeada como uma instncia da meta-classe Machine, recebendo um nome idntico quela, bem como referenciando a instncia Context gerada pelo mapeamento do Diagrama de Classe, e
tambm criando um evento INITIALISATION vazio. Alm disso, ela gera tambm
algumas construes neste Context: uma CarrierSet denominada Status; trs instncias de Constant, chamadas nostatus, started e ended; e uma Axiom que enumera
estas constantes como os estados possveis do conjunto Status.
Exemplo
Se o nome de um Diagrama de Casos de Uso for BookStore (Figura 5.14),
148
AXIOMS
axm1 : partition(Status, {nostatus}, {started}, {ended})
5.9.2.2
BIconixUC
Em Event-B
Uma instncia da meta-classe BIconixUC gera vrios mapeamentos em Event-B,
tanto no Context quanto na Machine. No primeiro gerada uma instncia de Constant
nomeada waitingfor{BIconixUC.name}, que incorporada partio do conjunto
Status gerado pelo Diagrama de Casos de Uso. No segundo vrias instncias so criadas: uma Variable nomeada control_{BIconixUC.name}; uma Invariant, indicando
que esta varivel possui um status, chamada control_{BIconixUC.name} Status;
uma Action dentro do evento INITIALISATION, designada control_{BIconixUC.name}
:= nostatus, para indicar a ausncia inicial de status; e uma Event, representando a
finalizao da execuo do Caso de Uso, chamada {BIconixUC.name}, com uma
Guard nomeada control_{BIconixUC.name} = started e uma Action designada control_{BIconixUC.name} := ended.
Exemplo
Se um Caso de Uso do BIconix for chamado AddBooktoCatalog (Figura 5.15),
149
VARIABLES
control_AddBooktoCatalog
INVARIANTS
inv5 : control_AddBooktoCatalog Status
EVENTS
Initialisation
begin
act1 : control_AddBooktoCatalog := nostatus
end
Event AddBooktoCatalog =
b
when
grd1 : control_AddBooktoCatalog = started
then
act1 : control_AddBooktoCatalog := ended
end
5.9.2.3
BIconixLink
Em Event-B
A meta-classe BIconixLink abstrata, portanto sem instncias, no possuindo um
mapeamento direto para os elementos concretos (Machine ou Context) do meta-modelo
do Event-B, sendo usada para criar uma base comum para ligaes dos tipos precedes
e invokes com instncias das meta-classes BIconixUC e BIconixActor.
Exemplo
Sem exemplos concretos.
5.9.2.4
BIconixInvokes
Em Event-B
Uma instncia da meta-classe BIconixInvokes pode gerar diferentes instncias dentro de uma Machine dependendo dos relacionamentos modelados. Cria-se uma Event,
chamada {BIconixInvokes.from.name}invokes{BIconixInvokes.to.name} para cada
150
ligao entre dois Casos de Uso. Dentro deste evento, criam-se duas Guard (control_{BIconixInvokes.from.name} = started e control_{BIconixInvokes.to.name} =
nostatus) e duas Action (control_{BIconixInvokes.from.name} := waitingfor{BIconix
Invokes.to.name} e control_{BIconixInvokes.to.name} := started), indicando os status necessrios para se invocar o Caso de Uso e como estes permanecem aps a sua
inicializao.
Se o Caso de Uso invoca dois ou mais Casos de Uso, ento na Guard control_{BIconixInvokes.from.name} = started do evento gerado introduzida uma disjuno do tipo control_{BIconixInvokes.from.name} = waitingfor{BIconixUC.leaving
[!{BIconix Invokes.to.name}].to.name} control_{BIconixUC.leaving[!{BIconixInvo
kes.to.name}].to.name} = ended para cada um dos demais Casos de Uso relacionados, indicando que a invocao pode ocorrer, ou quando o Caso de Uso invocador
est inicializado (started), ou quando um dos outros Casos de Uso invocados estiver
finalizado (ended).
Para cada Caso de Uso invocado, uma disjuno do tipo control_{BIconixInvokes.
from.name} = waitingfor{BIconixInvokes.to.name} control_{BIconixInvokes.to.name} = ended tambm adicionada Guard control_{BIconixInvokes.from.name}
= started do evento que representa o Caso de Uso invocador, assinalando que ele pode
ser finalizado, ou sem invocar nenhum outro, ou aps a invocao de qualquer um dos
Casos de Uso invocados.
Para cada ligao entre Ator e Caso de Uso o mapeamento para instncias Event-B
semelhante, basicamente trocando-se a referncia do Caso de Uso pelo do Ator.
Exemplo
Se um Caso de Uso do BIconix chamado CatalogMngmt invoca um Caso de Uso
nomeado AddBooktoCatalog e um outro denominado Login, como na Figura 5.16,
151
BIconixPrecedes
Em Event-B
152
153
Initialisation
begin
act2 : Login_precedes := nostatus
end
Event Login =
b
when
grd2 : Login_precedes = nostatus
then
act2 : Login_precedes := ended
end
Event CatalogMngmtinvokesAddBooktoCatalog =
b
when
grd2 : Login_precedes = ended
then
end
5.9.2.6
BIconixActor
Em Event-B
A instncia da meta-classe BIconixActor mapeia instncias para Event-B de forma
bem parecida a uma BIconixUC, com algumas sutis diferenas: nada gerado na Context; a Action dentro do evento INITIALISATION designada control_{BIconixActor.
name} := ended; na Event gerada como {BIconixActor.name} existe tambm uma
Action do tipo control_{BIconixUC.name} := nostatus para cada Caso de Uso existente e uma do tipo {BIconixPrecedes.from.name}_precedes := nostatus para cada
ligao Precedes visvel, a fim de reiniciar os status das variveis de controle; h uma
segunda Event criada ({BIconixActor.name}starts) para iniciar a atividade do Ator,
tendo uma Guard nomeada control_{BIconixActor.name} = ended e uma Action
chamada control_{BIconixUC.name} := started.
Exemplo
Se um Ator do BIconix for chamado Manager e invoca dois Casos de Uso (Login
e CatalogMngmt), como na Figura 5.18,
154
155
then
act1 : control_Manager := ended
act2 : control_AddBooktoCatalog := nostatus
act3 : control_Login := nostatus
act4 : control_CatalogMngmt := nostatus
act5 : Login_precedes := nostatus
end
5.9.3
BIconixRtnessDiagram
Em Event-B
Uma instncia da BIconixRtnessDiagram no possui um mapeamento direto para
os elementos concretos (Machine ou Context) do meta-modelo do Event-B, sendo seu
nome usado apenas como referncia para se conhecer qual Caso de Uso se est detalhando.
Exemplo
Sem exemplos concretos.
5.9.3.2
BIconixAnalysisClass
Em Event-B
A meta-classe BIconixAnalysisClass abstrata, portanto sem instncias, no possuindo um mapeamento direto para os elementos concretos (Machine ou Context) do
meta-modelo do Event-B, sendo usada apenas para referenciar instncias que chegam
ou saem das conexes.
Exemplo
Sem exemplos concretos.
5.9.3.3
156
BIconixBoundary
Em Event-B
Uma instncia da meta-classe BIconixBoundary no possui um mapeamento direto para a linguagem Event-B, uma vez que estar presente posteriormente, com o
mesmo nome, como uma classe no Diagrama de Classes, participando portanto do mapeamento nele realizado. No contexto do Diagrama de Robustez usada apenas como
intermediria entre as Classes de Controle que nela chegam e as que saem.
Exemplo
Sem exemplos concretos.
5.9.3.4
BIconixControl
Em Event-B
O mapeamento de um instncia da meta-classe BIconixControl para Event-B semelhante ao proposto para uma BIconixUC. Na Machine, vrias instncias so criadas:
uma Variable nomeada control_{BIconixControl.name}; uma Invariant, indicando
que esta varivel possui um status, chamada control_{BIconixControl.name} Status; uma Action dentro do evento INITIALISATION, designada control_{BIconixControl.name} := nostatus, para indicar a ausncia inicial de status; e uma Event chamada
{BIconixControl.name}, com uma Guard control_{BIconixControl.name} = nostatus, com uma Parameter st sob uma Guard st {} e uma Action designada
control_{BIconixControl.name} := st.
Exemplo
Se existir uma Classe de Interface chamada CatalogMngmtScreen, que alcana
uma Classe de Controle checkISBN, como na Figura 5.19,
157
BIconixEntity
Em Event-B
Uma instncia da meta-classe BIconixEntity no possui um mapeamento para a
linguagem Event-B, uma vez que se tornar uma classe no Diagrama de Classes,
encaixando-se no mesmo caso da BIconixBoundary. No contexto do Diagrama de
Robustez usada apenas por uma conexo associada para identificar as instncias existentes da Classe de Entidade.
Exemplo
Sem exemplos concretos.
5.9.3.6
158
BIconixParticipant
Em Event-B
Uma instncia da meta-classe BIconixParticipant no possui um mapeamento direto para Event-B, uma vez que eles j esto presentes no Diagrama de Casos de Uso,
sendo previamente traduzidos. No entanto, se o participante estiver invocando o Caso
de Uso refinado, ento ser adicionada uma Action chamada control_{BIconixControl.
name} := nostatus, para cada Classe de Controle existente, no evento que representa
o participante, a fim de reiniciar os status das variveis de controle.
Exemplo
Se um participante Manager invoca uma Classe de Interface CatalogMngmtScreen, que por sua vez alcana uma Classe de Controle denominada checkISBN,
como na Figura 5.20,
BIconixConnection
Em Event-B
159
160
Se uma conexo sai de uma Classe de Entidade, ento gerada uma Parameter
elem com uma Guard elem {BIconixEntity.name} no evento que representa a
Classe de Controle associada. Caso seja uma conexo de chegada, ento uma Parameter denominada inst, uma Guard nomeada inst {BIconixEntity.name}_SET\
{BIconixEntity.name} e uma Action designada {BIconixEntity.name} := {BIconixEntity.name} {inst} so adicionadas no evento que representa a Classe de Controle
conectada.
Exemplo
Se uma Classe de Controle chamada checkISBN recebe uma conexo de uma
Classe de Entidade denominada Book, alcana um Caso de Uso AddBooktoCatalog com restrio yes e outra Classe de Controle DisplayISBNErrorMsg com
restrio no, como na Figura 5.21,
161
EVENTS
Event AddBooktoCatalog =
b
extends AddBooktoCatalog
where
grd1 : control_AddBooktoCatalog = startedcontrol_checkISBN =
yes
then
end
Event Manager =
b
extends Manager
when
grd1 : control_Manager = started(control_Manager = waitingforLogin
control_Login = ended)(control_Manager = waitingforCatalogMngmt
control_CatalogMngmt = ended)control_DisplayISBNErrorMsg =
started
then
end
Event checkISBN =
b
any
st
elem
where
grd1 : control_checkISBN = nostatus
grd2 : st {yes, no}
grd3 : elem Book
grd4 : control_DisplayISBNErrorMsg = startedcontrol_Manager =
started
then
act1 : control_checkISBN := st
end
Event DisplayISBNErrorMsg =
b
any
162
st
where
grd1 : control_DisplayISBNErrorMsg = nostatus
grd2 : st {started}
grd3 : control_checkISBN = no
then
act1 : control_DisplayISBNErroMsg := st
end
5.9.4
BIconixSqcDiagram
Em Event-B
Uma instncia da BIconixSqcDiagram no possui um mapeamento direto para os
elementos concretos (Machine ou Context) do meta-modelo do Event-B, sendo seu
nome usado apenas como referncia para se conhecer qual Diagrama de Robustez se
est detalhando.
Exemplo
Sem exemplos concretos.
5.9.4.2
BIconixInteractionFragment
Em Event-B
A meta-classe BIconixInteractionFragment abstrata, no possuindo um mapeamento para os elementos concretos (Machine ou Context) do meta-modelo do Event-B,
sendo realizado por uma de suas especializaes (BIconixCombinedFrag, BIconixInteractionOperand e BIconixMsgOccurrence).
163
Exemplo
Sem exemplos concretos.
5.9.4.3
BIconixMessage
Em Event-B
Uma instncia da BIconixMessage tambm no possui um mapeamento para os
elementos concretos (Machine ou Context) do meta-modelo do Event-B, sendo utilizado apenas para auxiliar nas verificaes de sintaxe, que sero detalhadas no prximo
captulo.
Exemplo
Sem exemplos concretos.
5.9.4.4
BIconixMsgOccurrence
Em Event-B
A abordagem aqui utilizada para esse mapeamento tenta simular a criao e destruio de instncias (objetos) das classes envolvidas. Assim, uma instncia da BIconixMsgOccurrence mapeada em instncias do Event-B de acordo com o tipo de
associao que ocorre com uma BIconixMessage. Caso seja uma relao do tipo
msgReceived, ento gerada uma Event chamada {BIconixOperation.name} com
o nome da operao relacionada, com uma Parameter denominada unit sob uma
Guard nomeada unit {BIconixConectableElement.name}_SET\ {BIconixConectableElement.name} e uma Action designada {BIconixConectableElement.name}
:= {BIconixConectableElement.name} {unit}, sendo esse Elemento Conectvel
aquele representado pela Linha de Vida que cobre a Ocorrncia. Caso seja uma relao
do tipo msgSent, ento produzida uma Event chamada {BIconixOperation.name}
com o nome da operao relacionada, com uma Parameter nomeada own sob uma
Guard designada own {BIconixConectableElement.name} e uma Action denominada {BIconixConectableElement.name} := {BIconixConectableElement.name}\{own}, sendo este Elemento Conectvel aquele ligado Linha de Vida que cobre a
Ocorrncia.
164
5.9.4.5
165
BIconixOperation
Em Event-B
Uma instncia da BIconixOperation provoca a gerao de instncias de elementos
concretos de uma Machine do meta-modelo do Event-B. So geradas: uma Variable
nomeada control_{BIconixOperation.name}; uma Invariant, indicando que esta varivel possui um status, chamada control_{BIconixOperation.name} Status; uma
Action do evento INITIALISATION, designada control_{BIconixOperation.name} :=
nostatus, para indicar a ausncia inicial de status; e uma Guard nomeada control_{BI
conixOperation.name} = nostatus e uma Action designada control_{BIconixOperation.name} := started no evento gerado pela operao da mensagem associada a ocorrncia.
Exemplo
Se no Diagrama de Sequncia do BIconix existir uma Operao chamada checkBookInformation, como na Figura 5.23,
166
begin
act5 : control_checkBookInformation := nostatus
end
EVENTS
Event checkBookInformation =
b
where
grd1 : control_checkBookInformation = nostatus
then
act1 : control_checkBookInformation := started
end
5.9.4.6
BIconixParam
Em Event-B
Uma instncia da BIconixParam possui um mapeamento simples para uma instncia do Event-B. Para cada parmetro de uma BIconixOperation gerada uma Parameter BIconixParam.name, com uma Guard BIconixParam.name BIconixParam.argtype no evento gerado pela operao.
Exemplo
Se no Diagrama de Sequncia do BIconix existir uma Operao chamada DisplayConfirmationMsg com um parmetro int num para representar o nmero de
catlogo de um livro, como na Figura 5.24,
ento em Event-B:
167
EVENTS
Event DisplayConfirmationMsg =
b
any
unit
own
num
where
grd1 : unit CatalogMngmtScreen_SET \ CatalogMngmtScreen
grd2 : own Catalog
grd3 : num Z
then
end
5.9.4.7
BIconixLifeLine
Em Event-B
O mapeamento de uma instncia de uma BIconixLifeLine em instncias de EventB realizado de acordo com a ordem temporal (total) das Ocorrncias cobertas por ela,
sendo possvel controlar o fluxo de eventos de forma semelhante viso existente no
Diagrama de Sequncia do BIconix. Assim, mantendo-se a abordagem de passagem
de basto, para cada Linha de Vida presente, ela percorrida verticalmente do topo
para a base e, ao encontrar uma Ocorrncia que tenha uma relao do tipo msgSent,
ento gerada uma Guard nomeada control_{BIconixMsgOccurrence.[msgReceived
| msgSent].operation.name} = started no evento criado pela BIconixOperation associado ela, tendo-se como base a Ocorrncia imediatamente anterior. Para tanto,
utiliza-se o atributo vpvalue do BIconixMsgOccurrence para comparar as ordens das
posies. importante tambm frisar que esse mapeamento ocorre somente se ambas Ocorrncias fazem parte de um mesmo BIconixInteractionOperand, uma vez que
nesse caso a traduo diferenciada, como ser apresentado mais adiante na sub-seo
sobre Fragmentos Combinados.
Alm disso, caso exista uma Linha de Vida de um Ator ou Caso de Uso, ento, para
a ltima Ocorrncia entre todas, adicionada, na Guard disjunta do(s) evento(s) que representa o(s) Ator(es)/Casos de Uso(s), a expresso denominada control_{BIconixMsg
168
169
BIconixConectableElement
Em Event-B
A meta-classe abstrata BIconixConectableElement no possui um mapeamento direto para os elementos concretos (Machine ou Context) do meta-modelo do Event-B,
uma vez que suas meta-classes especializadas j possuem uma traduo prpria, sendo
usado apenas para referenciar a Linha de Vida associada a ela e auxiliar no mapeamento das Ocorrncias.
Exemplo
Sem exemplos concretos.
5.9.4.9
BIconixInteractionOperand
Em Event-B
Uma instncia da BIconixInteractionOperand no possui um mapeamento direto
para os elementos concretos (Machine ou Context) do meta-modelo do Event-B, sendo
usada apenas para auxiliar nos mapeamentos da Linha de Vida (BIconixLifeLine) e do
Fragmento Combinado (BIconixCombinedFragment) associados a ela.
170
Exemplo
Sem exemplos concretos.
5.9.4.10 BIconixConstraint
Em Event-B
Uma instncia da BIconixConstraint possui um mapeamento para uma Machine
do Event-B com o intuito de tentar expressar formalmente as restries impostas pelas
guardas dos Operandos de Interao existentes nos Fragmentos do tipo loop e alt. Para
tanto, como as variveis expressas nas restries devem estar definidas como BIconixAttribute e o mapeamento deste cria um elemento pertencente a um relao, ento o
primeiro passo da traduo de uma BIconixConstraint ajustar as variveis existentes
substituindo-as na expresso por {nomedavariavel}(dmn), onde dmn uma Parameter para representar o domnio. Depois, existem duas situaes possveis. Caso a
restrio faa parte de um Operando de tipo loop, ento adiciona-se uma Guard nomeada {BIconixInteractionOperand.guard.constr} nos eventos de reinicializao do
loop e naquele criado pela primeira Operao presente no Fragmento. Ademais, ainda
nesta situao, incrementa-se tambm o evento gerado pela Operao relacionada
Mensagem existente logo aps o Fragmento com uma Guard denominada ({BIconixInteractionOperand.guard.constr}). Caso a restrio faa parte de um Operando de
tipo alt, ento adiciona-se uma Guard {BIconixInteractionOperand.guard.constr}
no evento criado para representar a primeira Operao do Operando.
Exemplo
Se existir uma restrio booleana denominadaoptEBook = TRUE em um Fragmento do tipo alt, cujas primeiras Operaes de cada um dos Operandos sejam chamadas selectRegularBook e selectE-Book, respectivamente, como descrito na Figura 5.26, ento em Event-B tem-se:
EVENTS
Event selectRegularBook =
b
any
dmn
171
where
grd1 : optEBook(dmn) = FALSE
then
end
Event selectE-Book =
b
any
dmn
where
grd1 : optEBook(dmn) = TRUE
then
end
5.9.4.11 BIconixCombinedFrag
Em Event-B
Uma instncia da BIconixCombinedFrag possui uma mapeamento para Event-B
de acordo com o tipo de Operador associado (opt, alt ou loop).
Caso seja do tipo opt, o evento gerado pela Operao relacionada Mensagem
existente logo aps o Fragmento recebe uma Guard formada pela conjuno da varivel de controle do evento pr-Fragmento (com status igual a started) com a varivel
de controle do primeiro evento do Fragmento (com status igual a nostatus), ambas
172
formando uma disjuno com a varivel de controle do evento gerado pela Operao relacionada ltima Mensagem do Fragmento (com status igual started). Alm
disso, uma Guard com a varivel de controle do evento pr-Fragmento (com status
igual a started) gerada no evento criado pela primeira Operao do Fragmento.
Caso seja do tipo alt, o evento gerado pela Operao relacionada Mensagem
existente logo aps o Fragmento recebe uma Guard formada pela disjuno do status
(started) das variveis de controle dos eventos gerados pelas Operaes relacionadas
s ltimas Mensagens de cada Operando de Interao do Fragmento. Ademais, uma
Guard com a varivel de controle do evento pr-Fragmento (com status igual a started) gerada nos eventos criados para representar as primeiras Operaes de cada um
dos Operandos de Interao existentes.
Caso seja do tipo loop, ento o evento gerado pela Operao relacionada Mensagem existente logo aps o Fragmento, bem como o evento criado para representar a primeira Operao do Fragmento, recebem uma Guard formada pelo varivel de controle
(com status igual a started) do evento pr-Fragmento. Alm disso, um novo evento,
denominado loop_{ConcatenaNomedasOperacoesdoOperando}, criado para reinicializar o ciclo iterativo deste construtor, tendo como Guard a varivel de controle do
evento (status igual a started) gerado pela Operao relacionada ltima Mensagem
do Operando de Interao do Fragmento, e uma Action de atribuio de nostatus
para cada uma das variveis de controle dos eventos que representam as Operaes
existentes no Operando.
Exemplo
Se existirem os trs tipos de Fragmentos Combinados em um Diagrama de Sequncia do BIconix, como na Figura 5.27, ento em Event-B tem-se:
Event recoveryISBN =
b
where
grd1 : (control_DisplayDOINumber = startedcontrol_markSpecialBook =
nostatus) control_markSpecial = started
then
end
Event markSpecialBook =
b
where
grd1 : control_DisplayDOINumber = started
then
end
Event recoveryDOI =
b
where
grd2 : control_submitBookReg = started
then
end
Event checkBookInformation =
b
where
grd6 : control_submitBookReg = started
173
174
then
end
Event loop_checkBookInformation_DisplayBookErrorMsg =
b
where
grd2 : control_DisplayBookErrorMsg = started
then
act1 : control_checkBookInformation := nostatus
act2 : control_DisplayBookErrorMsg := nostatus
end
Event DisplayConfirmationMsg =
b
where
grd5 : control_selectRegularBook = startedcontrol_selectE
Book
then
end
Event selectRegularBook =
b
where
grd2 : control_DisplayISBNNumber = started
then
end
Event selectE-Book =
b
where
grd2 : control_DisplayISBNNumber = started
then
end
175
VERIFICAO FORMAL NO
BICONIX
No captulo anterior foi apresentada a abordagem proposta de formalizao de quatro artefatos do BIconix na linguagem Event-B, mostrando os meta-modelos das duas
notaes, bem como as regras de transformao para efetuar tal procedimento. Entretanto, nada se explanou sobre a formalizao das restries impostas a cada diagrama,
nem sobre os possveis problemas de modelagem que podem ser evitados.
Neste captulo ser exposto um conjunto inicial de verificaes formais possveis
desses artefatos. No se pretende exaurir todos os provveis problemas que ocorrem
quando se modela um software usando cada um desses quatro diagramas. Muitos
dos erros relatados na literatura sobre inconsistncias na UML (MALGOUYRES;
SEUMA-VIDAL; MOTET, 2006) foram eliminados devido s limitaes de sintaxe
impostas aos diagramas utilizados, tais como ausncia de navegabilidade, inexistncia
de classes abstratas, etc. Ressalta-se tambm que no ser feita distino entre os tipos
de restries, considerando tanto os perfis de inconsistncia relativos prpria UML
(sinttica ou semntica, intra ou inter diagramas, etc) quanto as questes de estilo de
modelagem determinadas pelas premissas do BIconix, adotando-se, como em todo o
restante do trabalho, uma abordagem pragmtica.
Outro fator importante a se destacar que aqui sero apresentadas apenas as verificaes formais automticas, ou seja, aquelas sem interveno do usurio. No entanto,
o processo BIconix prev que o desenvolvedor com perfil Event-B possa introduzir manualmente invariantes, guardas e aes no modelo previamente gerado, aproveitandose mais ainda do poder de verificao proporcionado pela formalizao.
Por fim, necessrio salientar que h duas respostas de erros possveis para a
verificao oferecida pela plataforma Rodin . Em algumas situaes, no possvel
176
validar todos os axiomas introduzidos no componente Context, fazendo com que algumas obrigaes de provas geradas apaream preenchidas com o sinal de interrogao
(como na Figura 6.1) na aba Event-B Explorer. Em outras, h uma gama de erros
de sintaxe, dependendo da restrio violada, que podem ser mostrados na aba Rodin
Problems.
No restante do captulo, sero apresentados exemplos de possveis problemas existentes em cada um dos diagramas, mostrando como a formalizao pode ajudar na sua
deteco e correo.
6.1
177
R1: Todo Atributo deve possuir um tipo booleano, inteiro ou de uma Classe.
Um exemplo de um diagrama com duas classes, sendo uma delas com um atributo
sem tipo e outro com tipo char, encontra-se na Figura 6.2. Este um dos problemas
impostos pela abordagem da formalizao, uma vez que a linguagem Event-B s possui esses dois tipos de dados primitivos. Nesta restrio tambm no h necessidade
de utilizar os axiomas e teoremas do modelo Event-B, j que o mapeamento proposto
faz com que a plataforma Rodin consiga detectar esse tipo de problema de modelagem
como um erro sinttico.
Logo, erros como Variable ? does not have a type, Identifier ? has not been
declared e Syntax error: Premature End of Formula aparecem ao usurio (Figura 6.3 )
aps a traduo do referido diagrama:
VARIABLES
Book
Catalog
active
itens
attri3
attri4
INVARIANTS
inv1 : Book P(Book_SET)
inv2 : Catalog P(Catalog_SET)
inv3 : active Catalog BOOL
inv4 : itens Catalog
Book
178
179
VARIABLES
VIPList
Catalog
MiniCatalog
INVARIANTS
inv1 : Catalog P(Catalog_SET)
inv2 : VIPList P(List_SET)
inv3 : MiniCatalog P(Catalog)
inv4 : MiniCatalog P(VIPList)
Esta restrio mais uma das que no precisa utilizar os axiomas e teoremas do
modelo Event-B, uma vez que o mapeamento proposto faz com que a plataforma Rodin
180
R4: Uma Agregao no pode agregar uma Classe que direta ou indiretamente a agrega.
Um exemplo de um diagrama com duas classes, uma agregando a outra, encontrase na Figura 6.8. Esta restrio mais uma daquelas descritas na especificao da
OMG para a UML, sendo tambm abordada neste trabalho.
Neste caso existe a necessidade usar os axiomas e teoremas introduzidos no modelo Event-B a fim de fornecer uma maneira automtica para realizar essa verificao. No componente Context existe uma constante aggreg para representar as relaes de agregao entre instncias de objetos, com um axioma do tipo aggreg = {
const_{BIconixAggregation.source.name} 7 const_{BIconixAggregation.target.name},
...}. Para se efetuar essa verificao, h um teorema para deteco de ciclos ((z z
181
dom(aggreg) z z aggreg[z])) no modelo Event-B, a fim de se criar automaticamente uma obrigao de prova, gerando-se a seguinte especificao:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_Catalog
const_Book
aggreg
AXIOMS
axm1 : const_Catalog OBJECT_SET
axm2 : const_Book OBJECT_SET
axm3 : aggreg = {const_Catalog 7 const_Book, const_Book 7 const_Catalog}
axm4 : (zz dom(aggreg) z z aggreg[z])
END
Caso a obrigao de prova referente ao quarto axioma esteja preenchida com o
sinal de interrogao no Event-B Explorer da plataforma Rodin, ento h grandes
indcios de que existe um ciclo formado por agregaes no diagrama verificado.
6.2
182
183
184
7 const_{BIconixInvokes.to.name}, ...}. Para se realizar a verificao da propriedade, h um teorema para deteco de ciclos ((z z dom(invks) z z
invks[z])) na especificao Event-B, a fim de se criar automaticamente uma obrigao
de prova, gerando-se o seguinte modelo:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_CatalogMngmt
const_Login
const_AddBooktoCatalog
invks
AXIOMS
axm1 : const_Catalog OBJECT_SET
axm2 : const_Login OBJECT_SET
axm3 : const_AddBooktoCatalog OBJECT_SET
axm4 : invks = {const_Login 7 const_CatalogMngmt, const_CatalogMngmt 7
const_AddBooktoCatalog, const_AddBooktoCatalog 7 const_Login}
axm5 : (zz dom(invks) z z invks[z])
END
185
Este mais um dos casos que exige a utilizao dos axiomas e teoremas presentes
no modelo Event-B gerado para auxiliar na verificao dessa propriedade. Assim, no
Context existe uma constante links para representar todas ligaes entre instncias
de casos de uso, com um axioma do tipo links = { const_{BIconixLink.from.name}
7 const_{BIconixLink.to.name}, ...}. Para efeitos de verificao, h um teorema
para se analisar a existncia de elementos iguais em um conjunto ((z z links z
links \ {z})) no modelo Event-B, a fim de se gerar uma obrigao de prova, criando-se
a seguinte especificao:
186
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_CatalogMngmt
const_Login
links
AXIOMS
axm1 : const_Catalog OBJECT_SET
axm2 : const_Login OBJECT_SET
axm3 : links = {const_Login 7 const_CatalogMngmt,
const_Login 7 const_CatalogMngmt}
axm4 : (zz links z links \ {z})
END
Caso a obrigao de prova referente ao quarto axioma esteja preenchida com um
sinal de interrogao no Event-B Explorer da plataforma Rodin, ento um grande
indicativo de que existe um elemento com duas ou mais ligaes para outro. Ressaltase que esse axioma no considerado uma tautologia uma vez que o Event-B trata o
conjunto links como bags.
6.3
187
de uso) presentes no diagrama, cria-se uma constante nomeada const_{BIconixAnalysisClass.name/ BIconixParticipant.name} e, para cada uma destas, gera-se um axioma do tipo const_{BIconixAnalysisClass.name/BIconixParticipant.name} OBJEC
T_SET, indicando que a instncia faz parte das possveis existentes. So tambm introduzidas cinco constantes, bdry, enty, contr, act e uc, que se utilizam de axiomas para
armazenar as instncias das classes de interface, de entidade, de controle, de atores e
de casos de uso, respectivamente. Alm disso, a fim de facilitar as verificaes, uma
constante denominada connections introduzida para representar as conexes entre
as instncias de classes e participantes do diagrama, sendo criado um axioma do tipo
connections = { const_{BIconixConnection.base.name/BIconixConnection.start.name
} 7 const_{BIconixConnection.aim.name/BIconix Connection.goal.name}, ...}.
A seguir ser apresentado um exemplo de erro e a mensagem mostrada ao usurio
pela plataforma Rodin para cada uma das sete restries verificadas automaticamente
no Diagrama de Robustez do BIconix.
R8: Um Ator s possui conexes de sada.
Um exemplo de um diagrama com uma classe que alcana um ator mostrado
na Figura 6.12. Esta restrio tambm imposta implicitamente pelo Iconix para o
Diagrama de Robustez e por isso ela tambm ser tratada por este trabalho.
188
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_checkISBN
const_CatalogMngmtScreen
const_Manager
const_ISBNErrorScreen
act
connections
AXIOMS
axm1 : const_checkISBN OBJECT_SET
axm2 : const_CatalogMngmtScreen OBJECT_SET
axm3 : const_Manager OBJECT_SET
axm4 : const_ISBNErrorScreen
axm5 : act = {const_Manager}
axm6 : connections = {const_Manager 7 const_CatalogMngmtScreen,
const_CatalogMngmtScreen 7 const_checkISBN,
const_checkISBN 7 const_ISBNErrorScreen,
const_ISBNErrorScreen 7 const_Manager}
axm7 : zz act z
/ ran(connections)
END
Caso a obrigao de prova referente ao stimo axioma (teorema) esteja preenchida
com o sinal de interrogao no Event-B Explorer da plataforma Rodin, ento possvel que exista um ator que atingido por alguma conexo no diagrama verificado.
R9: Um Participante no se conecta diretamente a outro Participante.
Um exemplo de um Diagrama de Robustez com um participante conectado a outro
apresentado na Figura 6.13. Esta restrio mais uma daquelas definidas pelo Iconix
para esse diagrama, sendo tambm abordada por esta proposta.
189
190
191
const_Book
act
bdry
connections
AXIOMS
axm1 : const_checkISBN OBJECT_SET
axm2 : const_Manager OBJECT_SET
axm3 : const_Book OBJECT_SET
axm4 : act = {const_Manager}
axm5 : bdry = {}
axm6 : connections = {const_Manager 7 const_Book,
const_Manager 7 const_checkISBN}
axm7 : ran(act C connections) bdry
END
Caso a obrigao de prova referente ao stimo axioma (teorema) esteja preenchida
com o sinal de interrogao, ento significa que deve existir uma conexo proveniente
de um ator que atinge outros elementos que no sejam classes de interface.
R11: Uma Conexo proveniente de um Caso de Uso atinge apenas Classes de
Controle.
Um exemplo de um diagrama com conexes provenientes de um caso de uso atingindo tanto um classe de interface quanto uma classe de entidade pode ser visualizado
na Figura 6.15. Esta restrio tambm definida explicitamente pelo processo Iconix
para esse diagrama, sendo por isso abordada neste trabalho.
192
193
Um exemplo de um diagrama com conexes provenientes de uma classe de interface atingindo tanto um classe de interface quanto uma classe de entidade mostrado
na Figura 6.16. Esta mais uma restrio que tambm definida explicitamente pelo
processo Iconix para esse diagrama e, devido a tal fato, foi includa neste trabalho.
Esta mais uma das situaes em que preciso a utilizao dos axiomas e teoremas introduzidos no modelo Event-B. Assim sendo, no Context existe um teorema
(ran(bdry C connections) contr) com o objetivo se criar uma obrigao de prova
para a verificao dessa propriedade, gerando-se a seguinte especificao:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_CatalogMngmtScreen
const_ISBNErrorScreen
const_Book
bdry
contr
connections
AXIOMS
axm1 : const_CatalogMngmtScreen OBJECT_SET
axm2 : const_ISBNErrorScreen OBJECT_SET
axm3 : const_Book OBJECT_SET
axm4 : bdry = {const_ISBNErrorScreen, const_CatalogMngmtScreen}
axm5 : contr = {}
194
A verificao dessa restrio exige o uso dos axiomas e teoremas introduzidos automaticamente no modelo Event-B. Assim sendo, no Context h um teorema (ran(entyC
connections) contr) com o objetivo se criar uma obrigao de prova, gerando-se a
seguinte especificao para o referido exemplo:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_CatalogMngmtScreen
195
const_Catalog
const_Book
enty
contr
connections
AXIOMS
axm1 : const_CatalogMngmtScreen OBJECT_SET
axm2 : const_Catalog OBJECT_SET
axm3 : const_Book OBJECT_SET
axm4 : enty = {const_Book, const_Catalog}
axm5 : contr = {}
axm6 : connections = {const_Catalog 7 const_Book,
const_Catalog 7 const_CatalogMngmtScreen}
axm7 : ran(enty C connections) contr
END
Caso a obrigao de prova referente ao stimo axioma (teorema) esteja preenchida
com o sinal de interrogao no Event-B Explorer da plataforma Rodin, ento pode
ser que se tenha uma conexo proveniente de uma classe de entidade que atinge outros
elementos que no sejam classes de controle.
R14: Uma Conexo possui restrio apenas se for proveniente de uma Classe
de Controle.
Um exemplo de um Diagrama de Robustez com conexes providas de restries,
mas no provenientes de classes de controle, pode ser visualizado na Figura 6.18. Esta
uma limitao imposta pela formalizao proposta a fim de facilitar a semntica do
diagrama, uma vez que apenas as classes de controle se transformam em eventos e
estas restries somente fazem sentido se forem geradas como aes de eventos.
Neste caso tambm existe a necessidade de se utilizar dos axiomas e teoremas
introduzidos no modelo Event-B a fim de prover a verificao. No Context existe
uma constante restr para armazenar a origem de todas as conexes com restries
presentes no diagrama, com um axioma na forma restr = {const_{BIconix Connection.base.name/BIconixConnection.start.name }. Assim, h um simples teorema (restr
196
contr) no modelo Event-B, a fim de se criar uma obrigao de prova para a verificao dessa propriedade, gerando-se a seguinte especificao no Context:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_checkISBN
const_Manager
const_Book
const_CatalogMngmtScreen
contr
restr
AXIOMS
axm1 : const_checkISBN OBJECT_SET
axm2 : const_Manager OBJECT_SET
axm3 : const_Book OBJECT_SET
axm4 : const_CatalogMngmtScreen OBJECT_SET
axm5 : contr = {const_checkISBN}
axm6 : restr = {const_Manager, const_Book, const_CatalogMngmt}
axm7 : restr contr
END
197
6.4
O Diagrama de Sequncia possui uma grande quantidade de problemas de modelagem passveis de serem verificados, tanto relacionados ambiguidade semntica
quanto a erros de sintaxe. Mas muitos deles so eliminados pelas limitaes impostas no meta-modelo descrito no captulo 5 (ver anexo A), tais como o uso apenas em
sistemas sequenciais e a excluso de vrios de seus elementos oficiais (tipos de mensagens, ocorrncia de execuo, etc). Assim, preferiu-se por delimitar o escopo de
anlise deste diagrama a estas restries , alcanando-se um total de nove verificaes
possveis. Para duas delas, a abordagem de mapeamento proposta j introduz erros de
sintaxe da linguagem, enquanto que para as restantes so utilizados os axiomas e teoremas introduzidos do modelo Event-B durante a traduo dos diagramas. Neste caso,
necessrio esclarecer as estruturas utilizadas no apoio a estas verificaes. Assim, para
cada instncia de elemento conectvel (ator, caso de uso, classes de entidade e interface), cria-se uma constante nomeada const_{BIconixConnectableElement.name} e,
para cada uma destas, gera-se um axioma do tipo const_{BIconixConnectableElement.
name} OBJECT_SET, indicando que a instncia faz parte das possveis existentes.
Similarmente, faz-se o mesmo para cada um dos trs tipos de fragmentos combinados
existentes (const_1 para opt, const_2 para alt e const_3 para loop), alm de se
criar tambm uma constante para representar um operando (const_oper).
Para o auxlio na verificao das propriedades das ocorrncias de mensagens, as
constantes e axiomas so criadas de forma semelhante, substituindo o nome pelo valor
presente no atributo vpvalue multiplicado por 1000 e posteriormente transformado em
nmero inteiro. Por exemplo, se o vpvalue de uma BIconixMsgOccurrence for 12.345,
ento ser gerada uma constante nomeada const_12345. Foi necessrio a utilizao
desse artifcio pois o caractere ponto (.) considerado especial na linguagem Event-B,
no se permitindo o seu uso em nomes de constantes. Alm disso, acredita-se que a
utilizao de trs casas decimais seja suficiente para identificar a posio relativa de
um ponto. J para facilitar a verificao das propriedades referentes aos fragmentos
198
Para essa verificao existe a necessidade utilizar os axiomas/teoremas introduzidos no modelo Event-B a fim de prover uma maneira automtica para realiz-la.
Assim, no elemento Context existe uma constante blfo para representar as ocorrncias de mensagens de cada linha de vida presente no diagrama, com um axioma do
tipo blfo = { const_{BIconixLifeLine.represents.name} 7 const_{(int)(BIconixLifeLine.coveredby.vpvalue)*1000}, ...}. Para se efetuar a verificao da propriedade, h
um teorema para avaliar a deteco de elementos repetidos em um conjunto ((z z
199
200
Um exemplo de um diagrama com uma mensagem entre duas linhas de vida, mas
com ocorrncias em pontos horizontais em nveis distintos, pode ser visualizado na
Figura 6.20. Esta um mais restrio imposta pela abordagem de formalizao, uma
vez que a troca de mensagens entre as linhas de vida considerada instantnea no
BIconix.
Neste caso necessrio tambm utilizar os axiomas e teoremas presentes no modelo Event-B a fim de prover uma maneira automtica para a verificao dessa propriedade. Assim, no Context existe uma constante msgs para representar as posies
das ocorrncias de mensagens entre linhas de vida, com um axioma do tipo msgs =
{ const_{(int) (BIconixMessage.sendEvent.vpvalue)*1000} 7 const_{(int) (BIconixMessage.receiveEvent.vpvalue)*1000}, ...}. Para se verificar essa propriedade, h um
teorema (z, y z 7 y msgs z = y) no modelo Event-B, a fim de se criar uma obrigao de prova. Assim, supondo-se que uma das ocorrncias esteja na posio 5.4321
e a outra na posio 9.8765, tem-se a seguinte especificao:
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_CatalogMngmtScreen
const_Manager
const_54321
const_98765
201
msgs
AXIOMS
axm1 : const_CatalogMngmtScreen OBJECT_SET
axm2 : const_Manager OBJECT_SET
axm3 : const_54321 OBJECT_SET
axm4 : const_98765 OBJECT_SET
axm5 : msgs = {const_54321 7 const_98765}
axm6 : z, yz 7 y msgs z = y
END
Como este um exemplo problemtico, a obrigao de prova referente ao sexto
axioma deve aparecer preenchida com o sinal de interrogao no Event-B Explorer
do Rodin, significando que h muitas chances de existir ocorrncias em nveis distintos
para uma mensagem entre duas linhas de vida.
R17: Uma Mensagem no tem como alvo uma Linha de Vida do tipo Ator.
Um exemplo de um diagrama com uma mensagem alcanando uma linha de vida
de um ator mostrado na Figura 6.21. Esta uma restrio presente implicitamente
no processo Iconix e, como a proposta pretende segui-lo o mais fielmente possvel, foi
incorporada a este trabalho.
Este mais um dos casos que se faz necessrio a utilizao dos axiomas e teoremas do modelo Event-B, a fim de realizar tal verificao de forma automtica. Assim sendo, no Context existe uma constante rmlf para representar as linhas de vida
que possuem ocorrncias como alvo de mensagens, com um axioma do tipo rmlf =
202
203
Nesta restrio tambm no h necessidade de complementar o modelo EventB gerado, j que o mapeamento proposto faz com que a plataforma Rodin consiga
detectar esse tipo de problema de modelagem como um erro sinttico. Logo, erros
como Identifier ? has not been declared e Parameter ? does not have a type aparecem
ao usurio (Figura 6.23 ) aps a traduo do referido diagrama:
VARIABLES
control_displayConfirmationMsg
CatalogMngmtScreen
Catalog
INVARIANTS
inv1 : control_displayConfirmationMsg Status
inv2 : CatalogMngmtScreen P(CatalogMngmtScreen_SET)
inv3 : Catalog P(Catalog_SET)
EVENTS
Event displayConfirmationMsg =
b
any
unit
own
ident
where
grd1 : unit CatalogMngmtScreen_SET \ CatalogMngmtScreen
grd2 : own Catalog
grd3 : control_displayConfirmationMsg = nostatus
204
Este mais uma das situaes que usa axiomas e teoremas no modelo Event-B a
fim de realizar tal verificao de forma automtica. Assim, existe um teorema do tipo
zz ran({const_1} C operg) z = FALSE no modelo Event-B, a fim de se criar
uma obrigao de prova. Portanto, tem-se a seguinte especificao para o exemplo
supracitado:
205
CONTEXT BooksOnLine
SETS
OBJECT_SET
CONSTANTS
const_1
AXIOMS
axm1 : const_1 OBJECT_SET
axm2 : operg = {const_1 7 TRUE}
axm3 : zz ran({const_1} C operg) z = FALSE
END
Neste exemplo a obrigao de prova referente ao terceiro axioma aparece preenchida com um sinal de interrogao no Event-B Explorer da plataforma Rodin,
indicando que pode existir um fragmento do tipo opt com seu operando com guarda.
R20: Operandos do tipo loop ou alt devem possuir guardas.
Um exemplo de um diagrama com dois fragmentos, sendo um do tipo alt e outro
do tipo loop, com seus operandos sem guardas, mostrado na Figura 6.25. Esta uma
limitao que foi imposta pela proposta de formalizao devido a no se ter encontrado
um mapeamento semntico razovel para esses casos em Event-B.
206
207
os atributos das classes se tornam variveis globais no modelo formal, ento delimitouse que uma guarda somente deve fazer referncias a estes.
Nesta restrio no necessrio usar uma obrigao de prova gerada para se fazer
a verificao formal dessa propriedade, uma vez que o mapeamento proposto j provoca um problema de sintaxe no modelo formal produzido. Assim, dois tipos de erros
(Identifier ? has not been declared e Parameter ? does not have a type) aparecem ao
usurio (Figura 6.27 ) aps o mapeamento do diagrama exemplificado:
EVENTS
Event selectRegularBook =
b
any
dmn
where
grd1 : optEBook(dmn) = FALSE
then
end
Event selectE-Book =
b
any
dmn
where
grd1 : optEBook(dmn) = TRUE
208
then
end
Esta mais uma das situaes que se faz necessrio a aplicao dos axiomas e
teoremas do modelo Event-B a fim de se utilizar o poder da ferramenta Rodin para a
verificao automtica. Assim sendo, existe um teorema sob o conjunto opern (descrito no incio da seo) do tipo zz (ran({const_1} C opern) ran({const_3} C
209
210
211
CONSIDERAES FINAIS
Este captulo apresenta uma discusso dos resultados desta tese, suas contribuies
e publicaes derivadas, bem como as oportunidades de trabalhos futuros.
7.1
Discusso
A atividade de verificao de inconsistncias em modelos que representam o software, realizada durante as diversas etapas de sua construo, de extrema importncia
para se alcanar um nvel mnimo de qualidade do sistema que est sendo desenvolvido. Apesar de fazer parte de vrios dos processos de desenvolvimento difundidos,
essa atividade geralmente realizada de forma manual, por meio de inspees visuais
nos modelos, ou por meio de um conjunto, nem sempre apropriado, de casos de testes
automatizados. Essa prtica acaba fazendo com que essa atividade seja negligenciada
ou efetuada em um escopo bem reduzido de verificaes, no atingindo seu objetivo:
encontrar problemas que ocorrem nas fases do processo de desenvolvimento.
Por outro lado, a rea de mtodos formais, por meio de um conjunto de tcnicas
baseadas em notaes e linguagens com preciso lgica e matemtica, proporciona
um mecanismo eficiente, na maioria das vezes automatizado, para realizar essa atividade de verificao de inconsistncias desde as fases iniciais do desenvolvimento at
a codificao. No entanto, o foco predominante da aplicao de mtodos formais no
desenvolvimento de software o da correo por construo, no qual cada passo do
processo deve ser corretamente (formalmente) construdo. Entretanto, boa parte dos
desenvolvedores no tem uma formao adequada que os permita compreender os conceitos apresentados por essa rea, o que termina por fazer com que esses mtodos no
recebam investimento em treinamento por parte da indstria.
7.1 Discusso
212
Esta tese de doutorado abordou esse problema propondo como soluo a incorporao de um suporte eficiente verificao de inconsistncias em um processo de
desenvolvimento que seja difundido no mercado. Para se atingir tal objetivo, optou-se
pela incluso do mtodo formal Event-B no Iconix, resultando no BIconix, um processo que permite ao desenvolvedor com perfil usual e conhecedor do Iconix continuar
realizando as tarefas previstas neste processo, enquanto que um especialista no mtodo Event-B realiza verificaes formais de inconsistncias nas etapas especficas de
reviso do Iconix. Nesta tese, foi proposto um mapeamento formal de alguns artefatos
do Iconix e apresentado um conjunto inicial de verificaes que podem ser realizadas
automaticamente pela ferramenta Rodin.
A anlise dos resultados deste trabalho pode ser dividida em dois grandes eixos
ortogonais: o ncleo tcnico e o aspecto gerencial. As possveis limitaes e vantagens
do processo proposto (BIconix) sero expostas a seguir sob cada uma dessas duas
perspectivas.
Sob o ponto de vista tcnico, a maior dificuldade desta pesquisa de doutorado foi
fazer a unio do Iconix com o Event-B, de tal forma que houvesse a menor quantidade
de modificaes possveis tanto no nvel semntico/sinttico quanto no operacional
para os seguidores regulares deste processo. Algumas caractersticas inerentes linguagem formal e ao processo criaram problemas inevitveis, tendo como consequncia
o estabelecimento de algumas limitaes.
Uma das limitaes est relacionada expressividade do Event-B, pois sua linguagem no permite a representao da semntica orientada a objetos como ocorre na
UML. Assim, alguns conceitos, como encapsulamento, classes abstratas e interfaces,
devem ser evitados pelos desenvolvedores. Ademais, a linguagem Event-B no adequada para a construo de sistemas concorrentes, sendo mais um fator limitante, o
que faz com que este trabalho focalize apenas em sistemas sequenciais.
Outro problema que impacta o alcance do propsito deste trabalho a restrio
imposta sintaxe de alguns componentes dos diagramas utilizados no processo. Essa
restrio termina ocorrendo devido adequao necessria para se formalizar os modelos representados nesses diagramas, uma vez que nem todos os seus elementos presentes na especificao da OMG so passveis de um mapeamento correto na linguagem
formal.
7.1 Discusso
213
7.1 Discusso
214
7.2
215
Principais Contribuies
7.3 Publicaes
7.3
216
Publicaes
7.3 Publicaes
217
7.4
218
Trabalhos Futuros
Esta tese abre caminho para uma discusso sobre o papel dos mtodos formais
como ferramenta auxiliar dos processos usuais de desenvolvimento de software. O
foco deste trabalho foi a sua utilizao como complemento aos mecanismos de verificao tradicionais (inspeo e testes). Ainda assim, existe uma srie de melhorias que
podem ser feitas para que o BIconix possa trazer mais benefcios aos seus usurios.
Por isso, no por ordem de importncia, prope-se como continuidade deste trabalho:
Incluso de elementos que deem suporte orientao a objetos ou concorrncias
na linguagem B/Event-B, algo similar ao que foi feito com a notao Z, tendo-se
a sua variante Object-Z;
Adio de mais elementos oficiais da UML nos diagramas que compem o processo, como por exemplo, permitir outros tipos de mensagens no Diagrama de
Sequncia ou a multiplicidade para as conexes entre atores e casos de uso;
Definio dos padres de refinamento existentes entre os diagramas do processo
que esto em diferentes nveis de abstrao, fazendo com que o invariante de
cola (gluing invariant) no modelo formal possa ser definido mais rapidamente;
Adaptao do processo para seguir completamente o paradigma iterativo e incremental, fazendo com que uma mudana no modelo mais abstrato no novo ciclo
possa ser considerado como um novo modelo Event-B, por exemplo;
Melhoria do mapeamento de volta dos erros encontrados durante o processo de
verificao a fim de prover para o desenvolvedor uma forma mais rpida para a
identificao dos componentes problemticos nos modelos produzidos;
Incorporao de um mecanismo automatizado (ou semi-automtico) a fim de
facilitar a transio dos requisitos (incluindo as pr e ps condies) para os modelos de Casos de Uso e de Domnio, criando, por exemplo, alguma linguagem
controlada para express-los;
Complementao do processo com o acrscimo de Invariantes e Guardas/Aes
na fase de Implementao, integrando-os a alguma linguagem que permita especificar esses detalhes diretamente no cdigo-fonte, como a JML (LEAVENS;
BAKER; RUBY, 1998), por exemplo;
219
Associao da abordagem proposta com ferramentas de gerao de testes a partir de modelos descritos em B/Event-B, como (MATOS; MOREIRA, 2012) ou
(SOUSA; MELO, 2010), a fim de fortalecer o processo de verificao;
Integrao do processo com alguma linguagem simples para descrio de restries, como a VCL (AMALIO; KELSEN, 2010) ou a VisualOCL (KIESNER;
TAENTZER; WINKELMANN, 2002), reduzindo assim as responsabilidades do
desenvolvedor com papel do Event-B;
Elaborao de um experimento controlado a fim de avaliar a viabilidade, tanto
sob o ponto de vista tcnico quanto gerencial, do uso desse processo em projetos
reais, bem como analisar as suas vantagens em relao ao Iconix.
220
REFERNCIAS
ABRIAL, J.-R. The B-book: assigning programs to meanings. 1st. ed. New York, NY,
USA: Cambridge University Press, 1996. ISBN 0-521-49619-5.
ABRIAL, J.-R. Modeling in Event-B: System and Software Engineering. 1st. ed.
New York, NY, USA: Cambridge University Press, 2010. ISBN 0521895561,
9780521895569.
ABRIAL, J.-R.; BUTLER, M.; HALLERSTEDE, S.; VOISIN, L. An open extensible
tool environment for Event-B. In: Proceedings of the International Conference on
Formal Engineering Methods (ICFEM 2006). [S.l.]: Springer, 2006. (Lecture Notes
in Computer Science), p. 588605.
AHRENDT, W.; BECKERT, B.; HHNLE, R.; SCHMITT, P. H. KeY: A formal
method for object-oriented systems. In: Procs. of 9th. Intl. Conf. on Formal Methods
for Open Object-Based Distributed Systems, Cyprus, 2007. [S.l.]: Springer, 2007.
(LNCS).
AMALIO, N.; KELSEN, P. Modular Design by Contract Visually and Formally
Using VCL. In: Proceedings of the IEEE Symposium on Visual Languages and
Human-Centric Computing (VLHCC 2010). [S.l.]: IEEE Computer Society, 2010. p.
227234. ISBN 978-0-7695-4206-5.
AMBLER, S.; NALBONE, J.; VIZDOS, M. The Enterprise Unified Process:
extending the Rational Unified Process. 1st. ed. Upper Saddle River, NJ, USA:
Prentice Hall Press, 2005. ISBN 0131914510.
AMBLER, S. W.; JEFFRIES, R. Agile Modeling: effective practices for Extreme
Programming and the Unified Process. 1st. ed. New York, NY, USA: John Wiley &
Sons, Inc., 2002. ISBN 0-471-20282-7.
BECK, K. Test-Driven Development by Example. [S.l.]: Addison-Wesley, 2003.
BECK, K.; ANDRES, C. Extreme Programming Explained : Embrace Change. 2nd.
ed. [S.l.]: Addison-Wesley Professional, 2004. Paperback.
BEIZER, B. Software testing techniques. 2nd. ed. New York, NY, USA: Van Nostrand
Reinhold Co., 1990. ISBN 0-442-20672-0.
BERARDI, D.; CALVANESE, D.; GIACOMO, G. D. Reasoning on uml
class diagrams. Artif. Intell., Elsevier Science Publishers Ltd., Essex,
UK, v. 168, n. 1, p. 70118, out. 2005. ISSN 0004-3702. Disponvel em:
<http://dx.doi.org/10.1016/j.artint.2005.05.003>.
REFERNCIAS
221
BJRNER, D.; JONES, C. B. The Vienna Development Method: The MetaLanguage. Lecture Notes in Computer Science, Springer-Verlag, London, UK, v. 61,
1978.
BOEHM, B. W.; BASILI, V. R. Software defect reduction top 10 list. IEEE Computer,
v. 34, n. 1, p. 135137, 2001.
BOLOGNESI, T.; BRINKSMA, E. Introduction to the ISO Specification Language
LOTOS. Computer Networks, v. 14, p. 2559, 1987.
BRIAND, L. C.; LABICHE, Y.; PENTA, M. D.; YAN-BONDOC, H. D. An
experimental investigation of formality in uml-based development. IEEE Trans. Softw.
Eng., IEEE Press, Piscataway, NJ, USA, v. 31, n. 10, p. 833849, out. 2005. ISSN
0098-5589. Disponvel em: <http://dx.doi.org/10.1109/TSE.2005.105>.
BROADFOOT, P.; ROSCOE, B. Tutorial on fdr and its applications. In: HAVELUND,
K.; PENIX, J.; VISSER, W. (Ed.). SPIN Model Checking and Software Verification.
[S.l.]: Springer Berlin Heidelberg, 2000, (Lecture Notes in Computer Science,
v. 1885). p. 322322. ISBN 978-3-540-41030-0.
BROWN, W. J.; MALVEAU, R. C.; MCCORMICK, H. W. S.; MOWBRAY, T. J.
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis: Refactoring
Software, Architecture and Projects in Crisis. 1st. ed. [S.l.]: John Wiley & Sons, 1998.
ISBN 0471197130.
BRGER, E.; STRK, R. F. Abstract State Machines. A Method for High-Level
System Design and Analysis. [S.l.]: Springer, 2003.
CHEN, Z.; ZHENHUA, D. Specification and verification of uml2.0 sequence
diagrams using event deterministic finite automata. In: Secure Software Integration
Reliability Improvement Companion (SSIRI-C), 2011 5th International Conference
on. [S.l.: s.n.], 2011. p. 4146.
CIMATTI, A.; CLARKE, E.; GIUNCHIGLIA, E.; GIUNCHIGLIA, F.; PISTORE,
M.; ROVERI, M.; SEBASTIANI, R.; TACCHELLA, A. Nusmv 2: An opensource
tool for symbolic model checking. In: . [S.l.]: Springer, 2002. p. 359364.
CLAVEL, M.; DURN, F.; EKER, S.; LINCOLN, P.; MART-OLIET, N.;
MESEGUER, J.; QUESADA, J. F. The Maude system. In: NARENDRAN, P.;
RUSINOWITCH, M. (Ed.). [S.l.: s.n.], 1999. v. 1631, p. 240243.
ClearSy. Atelier B, the industrial tool to efficiently deploy the B method. Version 4.0.2.
2011.
Deploy Project. Rodin Handbook. 2011. Disponvel em: <http://handbook.eventb.org/>.
DSOUZA, D. F.; WILLS, A. C. Objects, components, and frameworks with UML:
the catalysis approach. Boston, MA, USA: Addison-Wesley Longman Publishing
Co., Inc., 1999. ISBN 0-201-31012-0.
REFERNCIAS
222
REFERNCIAS
223
REFERNCIAS
224
REFERNCIAS
225
REFERNCIAS
226
227
A.1
A.1.1
Pacote core
A.1.1.1 EventBObject
Descrio
Meta-classe raiz deste meta-modelo que representa um objeto Event-B.
Generalizaes
EObject, uma classe do EMF.
Associaes
annotations: Annotation[0..*], guarda informaes sobre objetos Event-B.
228
Atributos
Sem atributos.
Operaes
getContaining, acessa um objeto Event-B de um determinado tipo;
getAllContained, acessa uma lista de objetos Event-B de um determinado tipo;
getURI, obtm a referncia URI de um objeto Event-B;
getAnnotation, devolve as informaes anotadas sobre um objeto Event-B.
Restries
Sem restries.
Semntica
A meta-classe abstrata EventBObject estende a classe EObject do EMF e classeraiz de todas as meta-classes do meta-modelo Event-B. Ela utilizada apenas para
prover algumas operaes genricas para acessar elementos de um tipo especfico, uma
operao para obter a referncia URL de um objeto Event-B, alm de um conjunto de
anotaes sobre o mesmo.
Notao
No h uma notao definida.
A.1.1.2 Annotation
Descrio
Esta meta-classe representa um objeto que armazena informaes extras sobre
qualquer elemento do modelo Event-B.
Generalizaes
EventBObject.
Associaes
229
230
231
fornecidos, um para os atributos simples e outra para os elementos, tendo como suporte
as meta-classes StringToAttributeMapEntry e AbstractExtension, respectivamente.
Notao
No h uma notao definida.
A.1.1.4 Attribute
Descrio
A meta-classe Attribute representa os atributos de um elemento Event-B.
Generalizaes
EventBObject.
Associaes
Sem associaes visveis.
Atributos
type, identifica o tipo de atributo de acordo com o tipo enumerado AttributeType
presente no meta-modelo;
value, indica valor do atributo, que deve consentir com o tipo do atributo.
Operaes
Sem operaes disponveis.
Restries
1.Se existir um objeto do tipo Attribute, ento existe um atributo key da meta-classe
StringToAttributeMapEntry que corresponde a uma extensionId da meta-classe
AbstractExtension.
Semntica
232
233
Uma extenso de novos elementos definido por um conjunto de objetos da metaclass AbstractExtension, que tem um atributo extensionId para identificar uma extenso
vlida. A qualquer momento uma instncia da meta-classe Extension, que estende
a meta-classe AbstractExtension, pode ser criada, podendo ser adicionada como um
elemento do conjunto de extenses (extensions) de um EventBElement.
Notao
No h uma notao definida.
A.1.1.6 Project
Descrio
A meta-classe Project tem como funo representar os projetos Event-B.
Generalizaes
EventBNamedCommentedElement.
Associaes
components: EventBNamedCommentedComponentElement[0..*], armazena todos os componentes de um projeto Event-B.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
Sem restries.
Semntica
A meta-classe Project permite que ferramentas deem suporte para apresentar e/ou
manipular o contedo de um projeto. Um projeto contm uma coleo de componentes
234
Outras Meta-Classes
A.1.2
235
Sub-Pacote machine
A.1.2.1 Machine
Descrio
A meta-classe Machine representa uma mquina Event-B.
Generalizaes
EventBNamedCommentedComponentElement.
Associaes
variables: Variable[0..*], guarda todas as variveis de uma mquina Event-B;
invariants: Invariant[0..*], armazena todos os invariantes presentes em uma mquina Event-B;
variant: Variant[0..1], conserva o possvel variante de uma mquina;
events: Event[0..*], reune todos os eventos de uma mquina;
refines: Machine[0..*], armazena todos as mquinas refinadas por uma mquina
Event-B.
Atributos
refinesNames, indica os nomes das mquinas Event-B que so refinadas;
seesNames, apresenta os nomes contextos que so vistos pela mquina.
Operaes
Sem operaes.
Restries
Sem restries.
Semntica
236
237
Outras Meta-Classes
Alm das meta-classes descritas, h ainda vrias outras dentro deste sub-pacote,
como a Variable, a Invariant, a Variant, a Parameter, a Guard, a Witness e a Action,
mas que por serem trivialmente compreendidas no sero aqui expostas. Detalhes
sobre a semntica e sintaxe dessas meta-classes podem ser encontradas no captulo 3.
A.1.3
Sub-Pacote context
A.1.3.1 Context
Descrio
A meta-classe Context desempenha o papel de um contexto Event-B.
Generalizaes
EventBNamedCommentedComponentElement.
Associaes
238
Outras Meta-Classes
Alm das meta-classes expostas, h ainda vrias outras dentro deste sub-pacote,
como a Axiom, a Constant e a CarrierSet, mas que por serem facilmente compreendidas no sero aqui expostas. A semntica e sintaxe dessas meta-classes podem ser
encontradas em detalhes no captulo 3 deste trabalho
A.2
239
A.2.1 BIconixClassDiagram
Descrio
A meta-classe BIconixClassDiagram representa um Diagrama de Classes ou um
Modelo de Domnio dentro do processo BIconix.
Generalizaes
Sem generalizaes.
Associaes
classes: BIconixClass[1..*], guarda todas as classes presentes em um Diagrama
de Classes do BIconix;
associations: BIconixAssociation[0..*], armazena todas as associaes existentes em um Diagrama de Classes do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Toda BIconixClassDiagram deve possuir um nome.
Semntica
A meta-classe BIconixClassDiagram permite a descrio de um Diagrama de Classes ou Modelo de Domnio dentro do processo BIconix por meio de dois componentes
(classes e associaes), sendo que ele deve possuir pelo menos uma classe.
Notao
Por se tratar de um composio de elementos grficos, um Diagrama de Classes
no possui uma notao especfica.
240
A.2.2 BIconixClass
Descrio
A meta-classe BIconixClass representa uma Classe dentro de um Diagrama de
Classes/Modelo de Domnio do BIconix.
Generalizaes
Sem generalizaes.
Associaes
outgoing: BIconixAssociation[0..*], coleciona todas as associaes que saem de
uma Classe do BIconix;
incoming: BIconixAssociation[0..*], armazena todas as associaes que chegam
em uma Classe do BIconix;
classAttributes: BIconixAttribute[0..*], guarda todas os atributos existentes em
uma Classe do BIconix, incluindo os gerados a partir de associaes;
operations: BIconixOperation[0..*], reune todas as operaes presentes em uma
Classe do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Toda BIconixClass deve possuir um nome;
2.Os conjuntos outgoing e incoming de uma BIconixClass devem ser disjuntos;
3.Toda BIconixClass deve aparecer pelo menos uma vez em algum Diagrama de
Robustez e Diagrama de Sequncia como BIconixEntity ou BIconixBoundary.
241
Semntica
A meta-classe BIconixClass permite a especificao de uma Classe do BIconix,
que descreve um conjunto de objetos que compartilham as mesmas caractersticas especficas (atributos e operaes), restries e semntica. Uma BIConixClass possui trs
partes principais, chamadas de compartimentos, sendo o primeiro para o seu nome, o
segundo para os seus atributos e o terceiro para as suas operaes.
Notao
A notao semelhante quela apresentada pelo especificao da OMG para uma
Classe, ou seja, um retngulo com trs divises, sendo a parte superior o compartimento destinado ao nome da Classe, a parte intermediria para os seus atributos e a
parte inferior designada para suas operaes.
A.2.3 BIconixAttribute
Descrio
A meta-classe BIconixAttribute representa a propriedade de um atributo de uma
Classe do BIconix.
Generalizaes
Sem generalizaes.
Associaes
Sem associaes.
Atributos
type, indica o tipo do atributo, podendo ser tanto um tipo primitivo quanto uma
Classe;
Operaes
Sem operaes.
Restries
1.Toda BIconixAttribute deve possuir um nome com um type;
242
2.O type de uma BIconixAttribute deve ser um tipo primitivo (inteiro ou booleano)
ou o nome de uma BIconixClass;
Semntica
A meta-classe BIconixAttribute permite a representao de um atributo de Classe
do BIconix, que uma caracterstica estrutural comum a todas as instncias da Classe.
Notao
Deve-se seguir a seguinte sintaxe:
BIconixAttribute.name ":" BIconixAttribute.type
A.2.4 BIconixAssociation
Descrio
A meta-classe abstrata BIconixAssociation representa uma associao entre Classes do BIconix.
Generalizaes
Sem generalizaes.
Associaes
source: BIconixClass[1], guarda a Classe de onde se origina uma Associao
do BIconix;
target: BIconixClass[1], armazena a Classe atingida por uma Associao do
BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
243
1.Toda BIconixAssociation deve ter seu conjunto target diferente de seu conjunto
source, ou seja, no deve existir auto-relacionamento.
Semntica
A meta-classe abstrata BIconixAssociation permite a representao de uma associao dentro do Diagrama de Classes do BIconix, permitindo assim uma conexo
(apenas binria) entre as instncias de Classes.
Notao
Sem uma notao especfica, uma vez que uma meta-classe abstrata. O processo
BIconix utiliza apenas as suas duas meta-classes especializadas.
A.2.5 BIconixGeneralization
Descrio
A meta-classe BIconixGeneralization representa uma associao do tipo especializao/generalizao entre Classes do BIconix.
Generalizaes
BIconixAssociation.
Associaes
Sem associaes
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixGeneralization no possui nome;
2.A hierarquia de qualquer BIconixGeneralization deve ser acclica;
244
3.A BIconixGeneralization no permite herana mltipla, ou seja, cada BIconixClass s possui no mximo uma BIconixAssociation deste tipo na sua associao
outgoing.
Semntica
A meta-classe BIconixGeneralization permite a descrio de uma relao de generalizao/especializao entre um elemento geral (Classe pai) e um elemento mais
especfico (Classe filha). A Classe filha retm a estrutura e o comportamento da Classe
pai e acrescenta informaes mais especficas. Na generalizao do BIconix no possvel especificar se a especializao total ou parcial e se as Classes filhas possuem ou
no instncias em comum. Neste caso, segue-se o valor padro (default) da OMG, que
parcial e sem instncias compartilhadas.
Notao
A notao semelhante quela apresentada pelo especificao da OMG para uma
associao do tipo generalizao, ou seja, uma conexo com um tringulo sem preenchimento em uma de suas pontas.
A.2.6 BIconixAggregation
Descrio
A meta-classe BIconixAggregation representa uma associao do tipo agregao
entre Classes do BIconix.
Generalizaes
BIconixAssociation;
BIconixAttribute.
Associaes
Sem associaes
Atributos
245
A.3
246
A.3.1 BIconixUCDiagram
Descrio
A meta-classe BIconixUCDiagram representa um Diagrama de Casos de Uso dentro do processo BIconix.
Generalizaes
Sem generalizaes.
Associaes
usecases:BIconixUC[1..*], armazena todos os casos de uso presente do Diagrama de Casos de Uso do BIconix;
links:BIconixLink[1..*], guarda todas as ligaes existentes no Diagrama de Casos de Uso do BIconix;
actors:BIconixActor[1..*], registra todos os atores visveis no Diagrama de Casos de Uso do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixUCDiagram deve possuir um nome;
Semntica
A meta-classe BIconixUCDiagram permite a descrio de um Diagrama de Casos
de Uso dentro do processo BIconix por meio de dois componentes (casos de uso, ligaes e atores), sendo que o mesmo deve possuir pelo menos uma instncia de cada um
destes elementos.
247
Notao
Por se tratar de um composio de elementos grficos, um Diagrama de Casos de
Uso do BIconix no possui uma notao definida.
A.3.2 BIconixUC
Descrio
A meta-classe BIconixUC representa um Caso de Uso dentro de um Diagrama de
Casos de Uso do BIconix.
Generalizaes
Sem generalizaes.
Associaes
leaving: BIconixLink[0..*], coleciona todas as ligaes que saem de um Caso de
Uso do BIconix;
entry: BIconixLink[1..*], armazena todas as ligaes que chegam em um Caso
de Uso do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Toda BIconixUC deve possuir um nome;
2.Os conjuntos leaving e entry de uma BIconixUC devem ser disjuntos.
Semntica
A meta-classe BIconixUC permite a identificao de um Caso de Uso dentro do
processo, sendo associada especificao de um Caso de Uso do BIconix , que des-
248
creve como o usurio interage com o sistema e como este o responde, proporcionando
um maneira estruturada para capturar o requisitos comportamentais de um software.
Notao
A notao semelhante quela apresentada pelo especificao da OMG para a
representao grfica de um Caso de Uso , ou seja, uma elipse com o nome do caso de
uso em seu interior.
A.3.3 BIconixLink
Descrio
A meta-classe abstrata BIconixLink representa uma ligao entre Casos de Uso
e/ou Atores no Diagrama de Casos de Uso do BIconix.
Generalizaes
Sem generalizaes.
Associaes
from: BIconixUC[0..1], guarda o Caso de Uso de onde se origina uma ligao
do BIconix;
to: BIconixUC[1], armazena o Caso de Uso atingido por uma ligao do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Toda BIconixLink deve ter seu conjunto from diferente de seu conjunto to, ou
seja, no deve existir auto-relacionamento.
Semntica
249
A.3.4 BIconixInvokes
Descrio
A meta-classe BIconixInvokes representa uma ligao do tipo invokes entre Casos
de Usos e/ou Atores do BIconix.
Generalizaes
BIconixLink.
Associaes
origin: BIconixActor[0..1], guarda um Ator de onde se origina uma ligao do
tipo invokes;
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.A hierarquia de qualquer BIconixInvokes deve ser acclica;
2.Se um BIconixInvokes possui relao com BIconixActor (origin), ento sua associao from deve ser vazia.
250
Semntica
A meta-classe BIconixInvokes permite a representao de uma ligao do tipo invokes dentro do Diagrama de Casos de Uso do BIconix. Este esteritipo, proposto
pelo processo Iconix, indica que um Caso de Uso pode iniciar um outro durante a sua
execuo, englobando simultaneamente os esteretipos includes e extends que esto
presentes na especificao original da UML. importante ressaltar tambm um outra
diferena em relao documentao da OMG: no h multiplicidade entre Atores e
Casos de Uso, ou seja, apenas uma instncia de Ator usa uma instncia de Caso de
Uso por vez.
Notao
Uma ligao nomeada invokes com uma seta simples em uma de suas pontas
indicando a ordem de leitura.
A.3.5 BIconixPrecedes
Descrio
A meta-classe BIconixPrecedes representa uma ligao do tipo precedes entre Casos de Usos do BIconix.
Generalizaes
BIconixLink.
Associaes
Sem associaes
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.A hierarquia de qualquer BIconixPrecedes deve ser acclica.
251
Semntica
A meta-classe BIconixPrecedes permite a representao de uma ligao do tipo
precedes dentro do Diagrama de Casos de Uso do BIconix. Este esteritipo, proposto
pelo processo Iconix, indica que um Caso de Uso deve ter sido totalmente finalizado
antes do incio de outro.
Notao
Uma ligao nomeada precedes com uma seta simples em uma de suas pontas
indicando a ordem de leitura.
A.3.6 BIconixActor
Descrio
A meta-classe BIconixActor representa um Ator dentro de um Diagrama de Casos
de Uso do BIconix.
Generalizaes
Sem generalizaes.
Associaes
exit: BIconixInvokes[1..*], guarda as ligaes do tipo invokes que saem do Ator;
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixActor deve ter um nome;
2.Uma BIconixActor no dever ser alvo de uma BIconixInvokes.
Semntica
252
A.4
A.4.1 BIconixRtnessDiagram
Descrio
A meta-classe BIconixRtnessDiagram representa um Diagrama de Robustez dentro do processo BIconix.
Generalizaes
Sem generalizaes.
Associaes
participants:BIconixParticipant[1..*], armazena todos os participantes (casos de
uso e atores) presentes do Diagrama de Robustez do BIconix;
connections:BIconixConnection[1..*], guarda todas as conexes existentes no
Diagrama de Robustez do BIconix;
analysisclasses:BIconixAnalysisClass[1..*], registra todas as classes de anlise
(entidade, interface e controle) que aparecem no Diagrama de Robustez do BIconix.
Atributos
Sem atributos.
Operaes
253
Sem operaes.
Restries
1.Uma BIconixRtnessDiagram deve possuir um nome;
2.O nome de uma BIconixRtnessDiagram deve ser idntico ao nome de alguma
instncia da BIconixUC que no esteja contida nele.
Semntica
A meta-classe BIconixRtnessDiagram permite expressar um Diagrama de Robustez dentro do processo BIconix por meio de trs elementos (participantes, classes de
anlise e conexes), sendo que o mesmo deve possuir pelo menos uma instncia de
cada um destes componentes. Um Diagrama de Robustez detalha graficamente um
Caso de Uso, da a necessidade ambos terem o mesmo nome, sendo uma forma de
referenci-lo.
Notao
Por se tratar de uma juno de elementos grficos, um Diagrama de Robustez no
possui uma notao especfica.
A.4.2 BIconixAnalysisClass
Descrio
A meta-classe abstrata BIconixAnaysisClass representa uma Classe de Anlise,
que pode ser de Interface, Controle ou Entidade, dentro do Diagrama de Robustez.
Generalizaes
Sem generalizaes.
Associaes
out:BIconixConnection[0..*], armazena as conexes que saem de uma Classe de
Anlise do BIconix;
in:BIconixConnection[0..*], guarda as conexes que chegam a um Classe de
Anlise do BIconix.
254
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixAnalysisClass deve possuir um nome;
2.Uma BIconixAnalysisClass deve ter pelo menos um elemento ou em sua associao out ou em sua associao in.
Semntica
A meta-classe abstrata BIconixAnalysisClass permite representar as Classe de Anlise dentro de um Diagrama de Robustez do BIconix, tendo uma semntica diferente
para cada uma de suas especializaes: Classe de Interface, Classe de Controle ou
Classe de Entidade.
Notao
Sem uma notao especfica, uma vez que uma meta-classe abstrata. O processo
BIconix utiliza apenas as suas trs meta-classes especializadas.
A.4.3 BIconixBoundary
Descrio
A meta-classe BIconixBoundary representa uma Classe de Anlise do tipo Interface dentro do Diagrama de Robustez.
Generalizaes
BIconixAnalysisClass.
Associaes
Sem associaes.
255
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
Sem restries.
Semntica
A meta-classe BIconixBoundary permite representar as Classes de Anlise do tipo
Interface, que so responsveis por manter a interao e a troca de informaes entre
os atores e o sistema.
Notao
A notao semelhante quela apresentada por Jacobson, tambm encontrada no
Iconix, para a representao grfica de um Classe de Interface , ou seja, um crculo
com uma barra vertical ao seu lado esquerdo.
A.4.4 BIconixControl
Descrio
A meta-classe BIconixControl representa uma Classe de Anlise do tipo Controle
dentro do Diagrama de Robustez.
Generalizaes
BIconixAnalysisClass.
Associaes
Sem associaes.
Atributos
Sem atributos.
Operaes
256
Sem operaes.
Restries
1.Uma BIconixControl deve possuir um nome;
Semntica
A meta-classe BIconixControl permite representar as Classes de Anlise do tipo
Controle, que so responsveis por executar as tarefas inerentes ao sistema dentro dos
cenrios do Caso de Uso, orquestrando as trocas de informaes entre as Classes de
Interface e as Classes de Entidade.
Notao
A notao semelhante quela apresentada por Jacobson, tambm encontrada no
Iconix, para a representao grfica de um Classe de Controle, ou seja, um crculo com
uma seta para a esquerda em sua parte superior.
A.4.5 BIconixEntity
Descrio
A meta-classe BIconixEntity descreve uma Classe de Anlise do tipo Interface
dentro do Diagrama de Robustez do BIconix.
Generalizaes
BIconixAnalysisClass.
Associaes
Sem associaes.
Atributos
Sem atributos.
Operaes
Sem operaes.
257
Restries
Sem restries.
Semntica
A meta-classe BIconixEntity permite representar as Classes de Anlise do tipo Entidade, que so responsveis por armazenar informaes que necessitam ser persistidas
pelo software, sendo estas gerenciadas por Classes de Controle.
Notao
A notao semelhante quela apresentada por Jacobson e encontrada no Iconix
para a representao grfica de um Classe de Entidade , ou seja, um crculo com uma
barra horizontal em sua parte inferior.
A.4.6 BIconixParticipant
Descrio
A meta-classe abstrata BIconixParticipant representa um participante externo ao
Diagrama de Robustez, podendo ser um Ator ou um Caso de Uso.
Generalizaes
Sem generalizaes.
Associaes
output:BIconixConnection[1..*], armazena todas as conexes que saem de um
participante do Diagrama de Robustez do BIconix;
input:BIconixConnection[0..*], guarda todas as conexes que chegam a um participante do Diagrama de Robustez do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
258
Restries
1.Um participante (BIconixParticipant) deve possuir obrigatoriamente uma ligao(BIconixLink) com o Caso de Uso (BIconixUC) referenciado pelo Diagrama
de Robustez (BIconixRtnessDiagram) no Diagrama de Casos de Uso (BIconixUCDiagram);
2.Se uma BIconixParticipant for do tipo BIconixActor, ento sua associao input
com BIconixConnection vazia, ou seja, um Ator s possui conexes que saem
dele.
Semntica
A meta-classe abstrata BIconixParticipant permite representar um participante externo em um Diagrama de Robustez. Um participante referencia um Caso de Uso ou
Ator que j possua uma relacionamento visvel no Diagrama de Casos de Uso com o
Caso de Uso que est sendo detalhado pelo Diagrama de Robustez.
Notao
Sem uma notao especfica, uma vez que uma meta-classe abstrata. O processo
BIconix utiliza apenas as suas duas meta-classes especializadas.
A.4.7 BIconixConnection
Descrio
A meta-classe BIconixConnection representa uma conexo dentro do Diagrama de
Robustez.
Generalizaes
Sem generalizaes.
Associaes
start:BIconixParticipant[0..1], armazena o participante de onde a conexo sai;
goal:BIconixParticipant[0..1], guarda o participante para onde a conexo vai;
259
260
9.Uma BIconixConnection somente pode possuir o atributo restriction quando tiver em sua associao base uma BIconixControl.
Semntica
A meta-classe BIconixConnection permite representar uma conexo qualquer dentro de um Diagrama de Robustez do BIconix, relacionando um Ator com uma Classe
de Interface, esta com uma Classe de Controle, uma Classe de Entidade com uma
Classe de Controle, etc.
Notao
Uma conexo, que pode ser nomeada (restriction), com uma seta simples em uma
de suas pontas indicando o elemento alvo (goal ou aim).
A.5
A.5.1 BIconixSqcDiagram
Descrio
Uma BIconixSqcDiagram representa um Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
messages:BIconixMessage[1..*], armazena todas as mensagens presentes do Diagrama de Sequncia do BIconix;
fragments:BIconixInteractionFragment[1..*], guarda todos os fragmentos de interao existentes no Diagrama de Sequncia do BIconix;
lifelines:BIconixLifeLine[2..*], registra todas as linhas de vida que aparecem no
Diagrama de Sequncia do BIconix.
Atributos
261
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixSqcDiagram deve possuir um nome;
2.O nome de uma BIconixSqcDiagram deve ser idntico ao nome de alguma instncia da BIconixRtnessDiagram.
Semntica
A meta-classe BIconixSqcDiagram permite descrever um Diagrama de Sequncia
dentro do processo BIconix por meio de trs elementos (mensagens, fragmentos e
linhas de vida), sendo que ela deve possuir pelo menos uma instncia de cada um
dos dois primeiros componentes e pelo menos duas deste ltimo. Um Diagrama de
Sequncia detalha um Diagrama de Robustez ao refinar as Classes de Controle em
uma ou mais Operaes, alocando comportamento para as Classes de Interface e de
Entidade. Da a necessidade de ambos terem o mesmo nome, sendo uma forma de
referenci-lo.
Notao
Por se tratar de uma agregao de elementos grficos, um Diagrama de Sequncia
do BIconix no possui uma notao definida.
A.5.2 BIconixInteractionFragment
Descrio
A meta-classe abstrata BIconixInteractionFragment representa um Fragmento de
Interao dentro de um Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
262
A.5.3 BIconixMessage
Descrio
A meta-classe BIconixMessage representa uma Mensagem no Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
operation:BIconixOperation[1], armazena a operao associada a uma Mensagem presente no Diagrama de Sequncia do BIconix;
263
sendEvent:BIconixMsgOccurrence[1], guarda a referncia da Ocorrncia de envio de uma Mensagem existente no Diagrama de Sequncia do BIconix;
receiveEvent:BIconixMsgOccurrence[1], registra a referncia da Ocorrncia do
recebimento de uma Mensagem existente no Diagrama de Sequncia do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixMessage no possui Ocorrncias de envio e recebimento com o
mesmo valor do atributo vpvalue em uma mesma Linha de Vida;
2.Uma BIconixMessage no deve cruzar os limites de um fragmento combinado;
3.Uma BIconixMessage no deve ter em sua associao sendEvent uma BIconixOccurrence que faa parte (covered) de uma BIconixLifeLine que tenha como
elemento conectvel uma BiconixAtor, ou seja, uma mensagem no deve ter
como alvo uma linha de vida de um Ator;
4.Caso conecte duas Linhas de Vida, uma BIconixMessage deve ter em suas associaes receiveEvent e sendEvent Ocorrncias com o mesmo valor do atributo
vpvalue.
Semntica
A meta-classe BIconixMessage permite expressar uma troca de mensagens entre
dois objetos em um Diagrama de Sequncia do BIconix. Uma Mensagem no BIconix
descreve apenas o tipo completo (no h os tipos lost, found, etc da UML padro),
sendo meramente um rastro <sendEvent, receiveEvent> que reflete a chamada de
uma Operao. Assim, toda Mensagem deve ter uma Operao associada a ela, bem
como conectar uma ou duas Linhas de Vida.
Notao
264
A.5.4 BIconixMsgOccurrence
Descrio
A meta-classe BIconixMsgOccurrence representa uma Ocorrncia de tempo que
est associada ao incio ou ao fim de uma Mensagem no Diagrama de Sequncia do
BIconix.
Generalizaes
BIconixInteractionFragment.
Associaes
msgSent:BIconixMessage[0..1], armazena a Mensagem associada a uma Ocorrncia de envio;
msgReceived:BIconixMessage[0..1], guarda a Mensagem relacionada a uma Ocorrncia de recebimento.
Atributos
vpvalue, indica o valor da posio da ocorrncia em relao ao topo da linha de
vida qual ela est associada.
Operaes
Sem operaes.
Restries
1.Uma BIconixMsgOccurrence ou possui a sua associao msgSent ou a msgReceived vazia;
265
A.5.5 BIconixOperation
Descrio
A meta-classe BIconixOperation representa uma Operao associada a uma Mensagem no Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
args:BIconixParam[0..*], armazena todos os parmetros de uma Operao do
Diagrama de Sequncia do BIconix.
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
266
A.5.6 BIconixParam
Descrio
A meta-classe BIconixParam representa um Parmetro de uma Operao associada
a uma Mensagem dentro do Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
Sem associaes.
Atributos
267
A.5.7 BIconixLifeLine
Descrio
A meta-classe BIconixLifeLine representa uma Linha de Vida no Diagrama de
Sequncia do BIconix.
Generalizaes
Sem generalizaes.
Associaes
coveredby:BIconixInteractionFragment[1..*], armazena os Fragmentos de Interao das quais a Linha de Vida faz parte;
268
A.5.8 BIconixConectableElement
Descrio
A meta-classe abstrata BIconixConectableElement representa uma Elemento Conectvel em um Diagrama de Sequncia do BIconix.
Generalizaes
Sem generalizaes.
269
Associaes
Sem associaes
Atributos
Sem atributos.
Operaes
Sem operaes.
Restries
1.Uma BIconixConectableElement deve se especializar em uma instncia de um
elemento (Ator, Caso de Uso, Classe de Entidade ou de Interface) que existe no
Diagrama de Robustez refinado pelo Diagrama de Sequncia o qual ele pertence.
Semntica
A semntica da meta-classe abstrata BIconixConectableElement definida pelos
seus sub-tipos, funcionando apenas como uma base comum para os elementos cujas
instncias se encontram no Diagrama de Robustez.
Notao
Sem uma notao especfica, uma vez que uma meta-classe abstrata. O processo
BIconix utiliza apenas as suas quatro meta-classes especializadas.
A.5.9 BIconixInteractionOperand
Descrio
A meta-classe BIconixInteractionOperand representa um Operando de Interao
em um Diagrama de Sequncia do BIconix.
Generalizaes
BIconixInteractionFragment.
Associaes
270
A.5.10 BIconixConstraint
Descrio
271
A meta-classe BIconixConstraint representa uma Guarda presente em um Operando de Interao dentro de um Fragmento Combinado de um Diagrama de Sequncia
do BIconix.
Generalizaes
Sem generalizaes.
Associaes
Sem associaes.
Atributos
constr, registra a expresso da guarda que dever ser avaliada como verdadeira
para que o Operando de Interao seja executado.
Operaes
Sem operaes.
Restries
1.O atributo constr somente deve fazer referncia a variveis definidas como BIconixAttribute em uma BIconixClass.
Semntica
Uma BIconixConstraint permite representar uma expresso booleana (uma guarda)
cuja avaliao decidir ou no pela execuo do Operando de Interao associado.
Notao
A expresso matemtica alojada no atributo constr posicionada no canto esquerdo superior do quadro que representa o Operando de Interao associado a ele.
A.5.11 BIconixCombinedFrag
Descrio
A meta-classe BIconixCombinedFrag representa um Fragmento Combinado em
um Diagrama de Sequncia do BIconix.
272
Generalizaes
BIconixInteractionFragment.
Associaes
operands:BIconixInteractionOperand[1..*], armazena os Operandos de Interao existentes dentro de um Fragmento Combinado.
Atributos
intOp, registra o tipo de Operador de um Fragmento Combinado, podendo ser
alt, opt ou loop.
Operaes
Sem operaes.
Restries
1.Se o atributo intOp de uma BIconixCombinedFrag for do tipo opt ou loop, ento
este composto por exatamente um Operando de Interao;
2.Se o atributo intOp de uma BIconixCombinedFrag for do tipo alt, ento este
composto por pelo menos dois Operandos de Interao.
Semntica
A semntica de uma BIconixCombinedFrag depende do Operador associado a ela.
Por possuir apenas os elementos bsicos mais utilizados na prtica, no BIconix existem
apenas trs tipos (alt, opt e loop), ou seja, no se tem os Operadores par, break, critical,
etc, que esto presentes na UML padro. Alm disso, o Operador loop mais simples,
no se tendo a opo de definir o nmero mnimo e mximo de interaes possveis.
Assim, temos apenas trs significados possveis para uma BIconixCombinedFrag: se
o Operador for do tipo alt, indica uma escolha entre comportamentos, em que apenas
um nico Operando de Interao escolhido para ser executado; se o Operador for
273
do tipo opt, implica que o Operando de Interao pode ou no ser executando, sendo
semanticamente idntico a um Operador do tipo alt com dois Operandos de Interao,
sendo um vazio; se o Operador for do tipo loop, significa que o Operando de Interao
ser executado repetidas vezes enquanto a sua Guarda for avaliada como verdadeira.
Notao
A notao grfica de uma BIconixCombinedFrag semelhante proposta pela
especificao da OMG, com um retngulo formado pelos quadros (frames) de um ou
mais Operandos e o nome do Operador posicionado no canto esquerdo superior dentro
de um pequeno retngulo.
274
A linguagem QVT foi criada pelo OMG em 24 de Abril de 2008 com o intuito
de padronizar as transformaes realizadas de modelo para modelo. Uma transformao pode ser independente, onde no existe relao entre os modelos, ou dependente,
quando ambos modelos esto relacionados, podendo ainda ser unidirecional, na qual
cada alterao no modelo-fonte provoca alteraes no modelo-alvo, porm o inverso
no permitido, ou bidirecional, admitindo que qualquer alterao em um dos modelos afete o outro. Esta especificao possui uma arquitetura hbrida composta por
uma parte declarativa e imperativa. A primeira conhecida por Relations enquanto a
segunda a Operational Mappings. Este trabalho usa a arquitetura imperativa, popularmente mais conhecida pela sigla QVTo. Maiores detalhes sobre a sua sintaxe podem
ser encontradas em (GRONBACK, 2009). A seguir encontram-se as principais regras
de transformao, descritas no captulo 5, que foram implementadas para mapear os
quatro diagramas do BIconix em Event-B.
B.1
Diagrama da Classes
in inClassDiagram:classdiagram);
main() {
setupMachineContext(inoutMachine.rootObjects()!
275
[eventb::machine::Machine], inoutContext.rootObjects()!
[eventb::context::Context]);
inoutContext.rootObjects()[eventb::context::Context]->map
classdiagram2eventbContext(inClassDiagram.rootObjects()!
[classdiagram::BIconixClassDiagram]);
inoutMachine.rootObjects()[eventb::machine::Machine]->map
classdiagram2eventbMachine(inClassDiagram.rootObjects()!
[classdiagram::BIconixClassDiagram]);
}
mapping inout
eventb::context::Context::classdiagram2eventbContext(in
rootClassDiagram : classdiagram::BIconixClassDiagram) {
var generatorID : String := rootClassDiagram.extensionId;
self.sets := rootClassDiagram.map class2sets(generatorID);
}
mapping inout
eventb::machine::Machine::classdiagram2eventbMachine(in
rootClassDiagram: classdiagram::BIconixClassDiagram) {
var generatorID : String := rootClassDiagram.extensionId;
self.map machine2nonGeneratedMachine(generatorID);
self.seesNames->includes(rootClassDiagram.name);
self.variables := rootClassDiagram.map
classDiagram2variables(generatorID)->
union(self.variables->asSequence());
self.invariants := rootClassDiagram.map
classDiagram2invariant(generatorID)->
union(self.invariants->asSequence());
self.events := rootClassDiagram.map
classDiagram2events(generatorID);
}
mapping classdiagram::BIconixClassDiagram::classDiagram2variables(in
276
277
init {
result := self.classes[classdiagram::BIconixClass].map
class2typeInvariant(generatorID)->sortedBy(i | i.name)->
asSequence()-> union(self.classes.classAttributes
[classdiagram::BIconixAttribute].map attribute2invariant
(generatorID)->asSequence())-> union(self.associations
[classdiagram::BIconixGeneralization].map
generalizationmain2invariant(generatorID)->asSequence());
}
}
mapping classdiagram::BIconixAttribute::attribute2invariant(in
generatorID : String) : eventb::machine::Invariant
disjuncts classdiagram::BIconixAttribute::attributeType2Invariant {}
mapping classdiagram::BIconixGeneralization::
generalizationmain2invariant(in generatorID : String) : eventb::
machine::Invariant disjuncts classdiagram::BIconixGeneralization::
generalization2Invariant {}
mapping classdiagram::BIconixClass::class2typeInvariant(in
generatorID : String) :
Sequence(eventb::machine::Invariant){
init{
var invariants : Sequence(eventb::machine::Invariant) := null;
var resp : Boolean := hasFather(self);
if (not resp)
then{
invariants := getInvariant(getInvariantName(), self.name +
B_IN + B_POW + B_LPAR + self.name + "_SET" +
B_RPAR, generatorID)->asSequence()->union(self.outgoing
[classdiagram::BIconixAggregation].map
aggregation2Invariant(self, generatorID)->asSequence());
}else{
invariants := self.outgoing[classdiagram::BIconixAggregation].
map aggregation2Invariant(self, generatorID)->asSequence();
278
}endif;
result := invariants;
}
}
mapping classdiagram::BIconixAttribute::attributeType2Invariant(in
generatorID : String) : eventb::machine::Invariant
when { not self.oclIsKindOf(BIconixAggregation) }
{
init {
result := getInvariant(getInvariantName(),
self.name.trim() + B_IN + self.eContainer().oclAsType(BIconixClass).
name + B_TFUN +
getAttributeType(self), generatorID)
}
}
mapping
classdiagram::BIconixGeneralization::generalization2Invariant(in
generatorID : String) : eventb::machine::Invariant{
init {
result := getInvariant(getInvariantName(),
self.source.name + B_IN + B_POW + B_LPAR + self.target.name +
B_RPAR, generatorID)
}
}
mapping classdiagram::BIconixAggregation::aggregation2Invariant(in
clazz : classdiagram::BIconixClass, in generatorID : String) :
Sequence(eventb::machine::Invariant) {
init {
var invariants : Sequence(eventb::machine::Invariant) := null;
switch {
case (cardinality(self,"0","n","0","n"))
invariants := getInvariant(getInvariantName(), self.name +
279
280
generatorID)->asSequence());
case (cardinality(self,"0","1","0","1"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_PINJ + clazz.name, generatorID)->
asSequence();
case (cardinality(self,"0","1","1","1"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_TINJ + clazz.name, generatorID)->
asSequence();
case (cardinality(self,"1","1","0","n"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_SURREL + clazz.name, generatorID)->
asSequence()-> union(getInvariant(getInvariantName(),
self.name + B_CONV + B_IN + clazz.name + B_PFUN + clazz.name,
generatorID)->asSequence());
case (cardinality(self,"1","1","1","n"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_TSURREL + clazz.name, generatorID)->
asSequence()-> union(getInvariant(getInvariantName(),
self.name + B_CONV + B_IN + clazz.name + B_PFUN + clazz.name,
generatorID)->asSequence());
case (cardinality(self,"1","1","0","1"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_PSUR + clazz.name, generatorID)->
asSequence()-> union(getInvariant(getInvariantName(),
self.name + B_CONV + B_IN + clazz.name + B_PFUN + clazz.name,
generatorID)->asSequence());
281
case (cardinality(self,"1","1","1","1"))
invariants := getInvariant(getInvariantName(), self.name +
B_IN + clazz.name + B_TBIJ + clazz.name, generatorID)->
asSequence();
};
result := invariants;
}
}
mapping classdiagram::BIconixClassDiagram::class2sets(in generatorID
: String) : Sequence(eventb::context::CarrierSet) {
init {
result := self.classes[classdiagram::BIconixClass].map
class2set(generatorID)->asSequence();
}
}
282
self.name;
}
mapping classdiagram::BIconixClass::class2action(in generatorID :
String) : eventb::machine::Action {
name := getActName() ;
action := self.name + B_BEQ + self.name + B_UNION + B_LBRC +
"self" + B_RBRC;
}
mapping classdiagram::BIconixClass::class2parameter(in generatorID :
String) : eventb::machine::Parameter {
283
name := "self";
}
mapping classdiagram::BIconixClass::class2desEvent(in generatorID :
String) :eventb::machine::Event when{ not hasFather(self)} {
name := "Des_" + self.name ;
guards := self.map class2desguard(generatorID)->
asSequence();
actions := self.map class2desaction(generatorID)->
asSequence();
parameters := self.map class2desparameter(generatorID)->
asSequence();
generated := true;
}
mapping classdiagram::BIconixClass::class2desguard(in generatorID :
String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping classdiagram::BIconixClass::class2desaction(in generatorID :
String) : eventb::machine::Action {
name := getActName() ;
action := self.name + B_BEQ + self.name + B_MINUS + B_LBRC +
"self" + B_RBRC;
}
mapping classdiagram::BIconixClass::class2desparameter(in
generatorID : String) : eventb::machine::Parameter {
name := "self";
}
mapping inout eventb::machine::Event::initEvent2initActions(in
284
B.2
285
in inUCDiagram:usecasediagram);
main() {
setupMachineContext(inoutMachine.rootObjects()![eventb::machine::
Machine], inoutContext.rootObjects()![eventb::context::Context]);
inoutContext.rootObjects()[eventb::context::Context]->map
ucdiagram2eventbContext(inUCDiagram.rootObjects()![usecasediagram::
BIconixUCDiagram]);
inoutMachine.rootObjects()[eventb::machine::Machine]->map
ucdiagram2eventbMachine(inUCDiagram.rootObjects()![usecasediagram::
BIconixUCDiagram]);
}
mapping inout eventb::context::Context::ucdiagram2eventbContext(in
rootUCDiagram : usecasediagram::BIconixUCDiagram) {
var generatorID : String := rootUCDiagram.extensionId;
self.sets := rootUCDiagram.map usecase2sets(generatorID);
self.constants := rootUCDiagram.map usecasedagram2constants(generatorID);
self.axioms := rootUCDiagram.map usecasediagram2axioms(generatorID);
}
mapping inout eventb::machine::Machine::ucdiagram2eventbMachine(in
rootUCDiagram: usecasediagram::BIconixUCDiagram) {
var generatorID : String := rootUCDiagram.extensionId;
self.map machine2nonGeneratedMachine(generatorID);
self.seesNames->includes(self.name + _IMPLICIT_CONTEXT);
self.variables := rootUCDiagram.map useCaseDiagram2variables
(generatorID)->union(self.variables->asSequence());
286
mapping
usecasediagram::BIconixUCDiagram::useCaseDiagram2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
result := self.usecases[usecasediagram::BIconixUC].map
useCase2variables(generatorID)-> union(self.actors
287
[usecasediagram::BIconixActor].map actor2variables(generatorID))->
union(self.links[usecasediagram::BIconixPrecedes].map
precedes2variables(generatorID));
}
}
mapping usecasediagram::BIconixUC::useCase2variables(in generatorID
: String) : Sequence(eventb::machine::Variable) {
init {
result := self.map useCase2variable(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixUC::useCase2variable(in generatorID :
String) : eventb::machine::Variable {
name := CONTROL + self.name;
generated := true;
attributes += getGeneratedAttr(generatorID);
}
mapping usecasediagram::BIconixActor::actor2variables(in generatorID
: String) : Sequence(eventb::machine::Variable) {
init {
result := self.map actor2variable(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixActor::actor2variable(in generatorID
: String) : eventb::machine::Variable {
name := CONTROL + self.name;
generated := true;
attributes += getGeneratedAttr(generatorID);
}
288
mapping usecasediagram::BIconixPrecedes::precedes2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
result := self.map precedes2variable(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixPrecedes::precedes2variable(in
generatorID : String) : eventb::machine::Variable {
name := self._from.name + _PRECEDES;
generated := true;
attributes += getGeneratedAttr(generatorID);
}
mapping
usecasediagram::BIconixUCDiagram::useCaseDiagram2invariants(in
generatorID : String) : Sequence(eventb::machine::Invariant) {
init {
result := self.usecases[usecasediagram::BIconixUC].map
useCase2invariant(generatorID)->sortedBy(i | i.name)->
asSequence()-> union(self.actors[usecasediagram::BIconixActor].
map actor2invariant(generatorID)->sortedBy(i | i.name)->
asSequence())-> union(self.links[usecasediagram::BIconixPrecedes].
map precedes2invariant(generatorID)->sortedBy(i | i.name)->
asSequence());
}
}
mapping usecasediagram::BIconixUC::useCase2invariant(in generatorID
: String) : Sequence(eventb::machine::Invariant){
init {
result := getInvariant(getInvariantName(), CONTROL + self.name +
B_IN + STATUS, generatorID)->asSequence()
}
289
}
mapping usecasediagram::BIconixActor::actor2invariant(in generatorID
: String) : Sequence(eventb::machine::Invariant){
init {
result := getInvariant(getInvariantName(), CONTROL + self.name +
B_IN + STATUS, generatorID)->asSequence()
}
}
mapping usecasediagram::BIconixPrecedes::precedes2invariant(in
generatorID : String) : Sequence(eventb::machine::Invariant){
init {
result := getInvariant(getInvariantName(), self._from.name +
_PRECEDES + B_IN + STATUS, generatorID)->asSequence()
}
}
mapping usecasediagram::BIconixUCDiagram::usecasedagram2constants(in
generatorID : String) : Sequence(eventb::context::Constant) {
init {
result := self.map nostatus2constant(generatorID)->asSequence()->
union(self.map started2constant(generatorID)->asSequence())->
union(self.map ended2constant(generatorID)->asSequence())->
union(self.usecases[usecasediagram::BIconixUC].map
useCases2constant(generatorID)->asSequence());
}
}
mapping usecasediagram::BIconixUCDiagram::nostatus2constant(in
generatorID : String) : eventb::context::Constant{
name := NOSTATUS;
comment := "Indicate the ausence of status";
generated := true;
290
}
mapping usecasediagram::BIconixUCDiagram::started2constant(in
generatorID : String) : eventb::context::Constant{
name := STARTED;
comment := "Indicate the inicialization";
generated := true;
}
mapping usecasediagram::BIconixUCDiagram::ended2constant(in
generatorID : String) : eventb::context::Constant{
name := ENDED;
comment := "Indicate the finalization";
generated := true;
}
mapping usecasediagram::BIconixUC::useCases2constant(in generatorID
: String) : eventb::context::Constant{
name := WAITINGFOR + self.name;
generated := true;
}
mapping usecasediagram::BIconixUC::useCase2constant(in generatorID :
String) : eventb::context::Constant when {self.name = null}{
init {
result := getConstant( WAITINGFOR + self.name )
}
}
mapping usecasediagram::BIconixUCDiagram::useCaseDiagram2events(in
generatorID : String) : Sequence(eventb::machine::Event) {
init {
result := self.map useCase2initialization(generatorID)->
asSequence()->
291
union(self.actors[usecasediagram::BIconixActor].map
actor2initEvents(self, generatorID))->
union(self.actors[usecasediagram::BIconixActor].map
actor2initEventsTwo(self, generatorID))->
union(self.usecases[usecasediagram::BIconixUC].map
useCase2initEvents(self, generatorID))->
union(self.links[usecasediagram::BIconixInvokes].map
invokes2initEvents(self, generatorID))->
union(self.links[usecasediagram::BIconixInvokes].map
invokesActors2initEvents(self, generatorID));
}
}
mapping usecasediagram::BIconixUCDiagram::useCase2initialization(in
generatorID : String) : eventb::machine::Event {
name := INITIALISATION;
}
mapping usecasediagram::BIconixUC::useCase2initEvents(in diagram :
usecasediagram::BIconixUCDiagram, in generatorID : String) :
Sequence(eventb::machine::Event) {
init {
result := self.map useCase2initEvent(diagram, generatorID)->
asSequence();
}
}
mapping usecasediagram::BIconixUC::useCase2initEvent(in diagram :
usecasediagram::BIconixUCDiagram, in generatorID : String) :
eventb::machine::Event {
name := self.name;
guards := self.map useCase2guard(diagram, generatorID)->
asSequence()-> union(diagram.links[usecasediagram::BIconixPrecedes].
map precedes2guards(self, generatorID)->asSequence());
292
diagram.links2disjuncts(self, self);
}
mapping usecasediagram::BIconixPrecedes::precedes2guards(in usecase
: usecasediagram::BIconixUC, in generatorID : String) :
eventb::machine::Guard
when {self._from = usecase}
{
init{
result := self.map precedes2guard(generatorID);
}
}
mapping usecasediagram::BIconixPrecedes::precedes2guard(in
generatorID : String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping usecasediagram::BIconixUC::useCase2action(in generatorID :
String) : eventb::machine::Action {
name := getActName() ;
action := CONTROL + self.name + B_BEQ + ENDED;
293
}
mapping usecasediagram::BIconixActor::actor2initEvents(in diagram :
usecasediagram::BIconixUCDiagram, in generatorID : String) :
Sequence(eventb::machine::Event) {
init {
result := self.map actor2initEvent(diagram, generatorID)->
asSequence();
}
}
mapping usecasediagram::BIconixActor::actor2initEvent(in diagram :
usecasediagram::BIconixUCDiagram, in generatorID : String) :
eventb::machine::Event {
name := self.name;
actions := diagram.usecases[usecasediagram::BIconixUC].map
actorEvent2action(generatorID)->asSequence()->
union(diagram.
links[usecasediagram::BIconixPrecedes].map
actorPrecedesEvent2action(generatorID)->asSequence());
generated := true;
convergence := core::machine::Convergence::ordinary;
extended := false;
}
mapping usecasediagram::BIconixUC::actorEvent2action(in generatorID
: String) : Sequence(eventb::machine::Action) {
init{
result := self.map actorUC2events(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixUC::actorUC2events(in generatorID :
String) : eventb::machine::Action {
name := getActName();
294
295
convergence := core::machine::Convergence::ordinary;
extended := false;
}
mapping usecasediagram::BIconixActor::actor2guard(in generatorID :
String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping usecasediagram::BIconixUC::actorEvent2actionTwo(in
generatorID : String) : Sequence(eventb::machine::Action) {
init{
result := self.map actorUC2eventsTwo(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixUC::actorUC2eventsTwo(in generatorID
: String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.name + B_BEQ + STARTED;
}
mapping usecasediagram::BIconixInvokes::invokes2initEvents(in
diagram : usecasediagram::BIconixUCDiagram, in generatorID : String)
: Sequence(eventb::machine::Event) when{self._from <> null}{
init {
result := self.map invokes2initEvent(diagram, generatorID)->
asSequence();
}
}
mapping usecasediagram::BIconixInvokes::invokes2initEvent(in diagram
: usecasediagram::BIconixUCDiagram, in generatorID : String) :
296
eventb::machine::Event {
name := self._from.name + INVOKES + self.to.name;
guards := self.map invokes2guardOne(diagram, generatorID)->
asSequence()-> union(self.map invokes2guardTwo(generatorID)->
asSequence())-> union(diagram.links[usecasediagram::BIconixPrecedes].
map invokesPrecedes2guards(self.to, generatorID)->asSequence());
actions := self.map invokes2action(generatorID)->asSequence()->
union(self.map invokes2actionTwo(generatorID)->asSequence());
generated := true;
convergence := core::machine::Convergence::ordinary;
extended := false;
}
mapping usecasediagram::BIconixPrecedes::invokesPrecedes2guards(in
usecase : usecasediagram::BIconixUC, in generatorID : String) :
eventb::machine::Guard
when {self.to = usecase}
{
init{
result := self.map invokesPrecede2guard(generatorID);
}
}
mapping usecasediagram::BIconixPrecedes::invokesPrecede2guard(in
generatorID : String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping usecasediagram::BIconixInvokes::invokes2guardOne(in diagram
: usecasediagram::BIconixUCDiagram, in generatorID : String) :
eventb::machine::Guard{
name := getGuardName();
predicate :=
297
diagram.links2disjuncts(self._from, self.to);
}
mapping usecasediagram::BIconixInvokes::invokes2guardTwo(in
generatorID : String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping usecasediagram::BIconixInvokes::invokes2action(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self._from.name + B_BEQ + WAITINGFOR +
self.to.name;
}
mapping usecasediagram::BIconixInvokes::invokes2actionTwo(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.to.name + B_BEQ + STARTED;
}
mapping usecasediagram::BIconixInvokes::invokesActors2initEvents(in
diagram : usecasediagram::BIconixUCDiagram, in generatorID : String)
: Sequence(eventb::machine::Event) when{ self.origin <> null and
self._from = null } {
init {
result := self.map invokesActor2initEvent(diagram, generatorID)->
asSequence();
}
}
mapping usecasediagram::BIconixInvokes::invokesActor2initEvent(in
diagram : usecasediagram::BIconixUCDiagram, in generatorID : String)
298
: eventb::machine::Event {
name := self.origin.name + INVOKES + self.to.name;
guards := self.map invokesActor2guardOne(diagram, generatorID)->
asSequence()-> union(self.map invokesActor2guardTwo(generatorID)->
asSequence());
actions := self.map invokesActor2action(generatorID)->asSequence()->
union(self.map invokesActor2actionTwo(generatorID)->asSequence());
generated := true;
convergence := core::machine::Convergence::ordinary;
extended := false;
}
mapping usecasediagram::BIconixInvokes::invokesActor2guardOne(in
diagram : usecasediagram::BIconixUCDiagram, in generatorID : String)
: eventb::machine::Guard{
name := getGuardName();
predicate :=
diagram.linksActor2disjuncts(self.origin, self.to);
}
mapping usecasediagram::BIconixInvokes::invokesActor2guardTwo(in
generatorID : String) : eventb::machine::Guard{
name := getGuardName();
predicate :=
}
mapping usecasediagram::BIconixInvokes::invokesActor2action(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.origin.name + B_BEQ + WAITINGFOR +
self.to.name;
}
mapping usecasediagram::BIconixInvokes::invokesActor2actionTwo(in
299
300
init {
result := self.map actor2initialization(generatorID)->asSequence();
}
}
mapping usecasediagram::BIconixActor::actor2initialization(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.name + B_BEQ + ENDED;
}
mapping usecasediagram::BIconixPrecedes::precedes2initializations(in
generatorID : String) : Sequence(eventb::machine::Action) {
init {
result := self.map precedes2initialization(generatorID)->
asSequence();
}
}
mapping usecasediagram::BIconixPrecedes::precedes2initialization(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := self._from.name + _PRECEDES + B_BEQ + NOSTATUS;
}
B.3
Diagrama de Robustez
301
inoutContext:eventb,
in inRtnessDiagram:rtnessdiagram);
main() {
setupMachineContext(inoutMachine.rootObjects()![eventb::machine::
Machine], inoutContext.rootObjects()![eventb::context::Context]);
inoutContext.rootObjects()[eventb::context::Context]->map
rtnessdiagram2eventbContext(inRtnessDiagram.rootObjects()!
[rtnessdiagram::BIconixRtnessDiagram]);
inoutMachine.rootObjects()[eventb::machine::Machine]->map
rtnessdiagram2eventbMachine(inRtnessDiagram.rootObjects()!
[rtnessdiagram::BIconixRtnessDiagram]);
}
mapping inout
eventb::context::Context::rtnessdiagram2eventbContext(in
rootRtnessDiagram : rtnessdiagram::BIconixRtnessDiagram) {
var generatorID : String := rootRtnessDiagram.extensionId;
self.sets := rootRtnessDiagram.map usecase2sets(generatorID);
self.constants := rootRtnessDiagram.map rtnessdiagram2constants
(generatorID);
self.axioms[name = AXM1].map rtnessdiagram2axioms(generatorID);
}
mapping inout
eventb::machine::Machine::rtnessdiagram2eventbMachine(in
rootRtnessDiagram: rtnessdiagram::BIconixRtnessDiagram) {
var generatorID : String := rootRtnessDiagram.extensionId;
self.invariants->forEach(i){
if(i.name.substringAfter(INV).toInteger() <> SEQ) then{
SEQ := i.name.substringAfter(INV).toInteger();
}endif;
};
self.map machine2nonGeneratedMachine(generatorID);
302
self.seesNames->includes(self.name + _IMPLICIT_CONTEXT);
self.variables := rootRtnessDiagram.map rtnessDiagram2variables
(generatorID)->union(self.variables->asSequence());
self.invariants := rootRtnessDiagram.map rtnessDiagram2invariants
(generatorID)->union(self.invariants->asSequence());
self.events := rootRtnessDiagram.map rtnessDiagram2events(generatorID);
self.events[name = INITIALISATION].map rtnessDiagram2initializations
(rootRtnessDiagram, generatorID);
}
mapping rtnessdiagram::BIconixRtnessDiagram::usecase2sets(in
generatorID : String) : Sequence(eventb::context::CarrierSet) {
init {
result := self.participants[rtnessdiagram::BIconixUC].map
usecase2set(generatorID)->asSequence()->
union(self.analysisclasses[rtnessdiagram::BIconixActor].
map actor2set(generatorID)->asSequence())->
union(self.map status2carrierSet()->asSequence());
}
}
mapping rtnessdiagram::BIconixRtnessDiagram::status2carrierSet() :
eventb::context::CarrierSet {
name := STATUS;
}
mapping
rtnessdiagram::BIconixRtnessDiagram::rtnessdiagram2constants(in
generatorID : String) : Sequence(eventb::context::Constant) {
init {
result := self.connections[rtnessdiagram::BIconixConnection].
map connection2constant(generatorID)->asSequence();
}
303
}
mapping rtnessdiagram::BIconixConnection::connection2constant(in
generatorID : String) : eventb::context::Constant{
name := self.name;
generated := true;
SET_AXIOMS := SET_AXIOMS + B_COM + B_LBRC + self.name + B_RBRC;
}
mapping inout eventb::context::Axiom::rtnessdiagram2axioms(in
generatorID : String) {
name := SET_AXIOMS + B_RPAR;
}
mapping
rtnessdiagram::BIconixRtnessDiagram::rtnessDiagram2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
result := self.analysisclasses[rtnessdiagram::BIconixControl].
map control2variables(generatorID);
}
}
mapping rtnessdiagram::BIconixControl::control2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
result := self.map rtness2variable(generatorID)->asSequence();
}
}
mapping rtnessdiagram::BIconixControl::rtness2variable(in
generatorID : String) : eventb::machine::Variable {
name := CONTROL + self.name;
generated := true;
304
attributes += getGeneratedAttr(generatorID);
}
mapping
rtnessdiagram::BIconixRtnessDiagram::rtnessDiagram2invariants(in
generatorID : String) : Sequence(eventb::machine::Invariant) {
init {
result := self.analysisclasses[rtnessdiagram::BIconixControl].
map control2invariant(generatorID)->sortedBy(i | i.name)->
asSequence();
}
}
mapping rtnessdiagram::BIconixControl::control2invariant(in
generatorID : String) : Sequence(eventb::machine::Invariant){
init {
result := getInvariant(getInvariantName(), CONTROL + self.name +
B_IN + STATUS, generatorID)->asSequence()
}
}
mapping rtnessdiagram::BIconixRtnessDiagram::rtnessDiagram2events(in
generatorID : String) : Sequence(eventb::machine::Event) {
init {
result := self.map control2initialization(generatorID)->
asSequence()-> union(self.analysisclasses[rtnessdiagram::
BIconixControl].map control2initEvents(self, generatorID))->
union(self.participants[rtnessdiagram::BIconixActor].map
connectionActor2initEvents(self, generatorID));
}
}
mapping
rtnessdiagram::BIconixRtnessDiagram::control2initialization(in
305
306
}
mapping rtnessdiagram::BIconixActor::connectionActor2initEvents(in
diagram : rtnessdiagram::BIconixRtnessDiagram, in generatorID :
String) : Sequence(eventb::machine::Event) {
init {
result := self.map connectionActor2initEvent(diagram,
generatorID)->asSequence();
}
}
mapping rtnessdiagram::BIconixActor::connectionActor2initEvent(in
diagram : rtnessdiagram::BIconixRtnessDiagram, in generatorID :
String) : eventb::machine::Event {
name := self.name;
}
mapping rtnessdiagram::BIconixControl::control2action(in generatorID
: String) : eventb::machine::Action {
name := getActName() ;
action := CONTROL + self.name + B_BEQ + ST;
}
mapping rtnessdiagram::BIconixControl::control2parameter(in
generatorId : String) : eventb::machine::Parameter{
name := ST;
}
mapping inout
307
eventb::machine::Event::rtnessDiagram2initializations(in
rtnessDiagram : rtnessdiagram::BIconixRtnessDiagram, in generatorID
: String) {
name := INITIALISATION;
actions := rtnessDiagram.analysisclasses[rtnessdiagram::
BIconixControl].map control2initializations(generatorID)->union
(actions->asSequence());
}
mapping rtnessdiagram::BIconixControl::control2initializations(in
generatorID : String) : Sequence(eventb::machine::Action) {
init {
result := self.map control2initialization(generatorID)->
asSequence();
}
}
mapping rtnessdiagram::BIconixControl::control2initialization(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.name + B_BEQ + NOSTATUS;
}
B.4
Diagrama de Sequncia
in inSeqDiagram:seqdiagram);
308
setupMachineContext(inoutMachine.rootObjects()![eventb::machine::
Machine]);
inoutMachine.rootObjects()[eventb::machine::Machine]->map
seqdiagram2eventbMachine(inSeqDiagram.rootObjects()!
[seqdiagram::BIconixSqcDiagram]);
}
mapping inout eventb::machine::Machine::seqdiagram2eventbMachine(in
rootSeqDiagram: seqdiagram::BIconixSqcDiagram) {
var generatorID : String := rootSeqDiagram.extensionId;
self.map machine2nonGeneratedMachine(generatorID);
self.seesNames->includes(self.name + _IMPLICIT_CONTEXT);
self.variables := rootSeqDiagram.map SeqDiagram2variables
(generatorID)->union(self.variables->asSequence());
self.invariants := rootSeqDiagram.map SeqDiagram2invariants
(generatorID)->union(self.invariants->asSequence());
self.events := rootSeqDiagram.map SeqDiagram2events(generatorID);
self.events[name = INITIALISATION].map SeqDiagram2initializations
(rootSeqDiagram, generatorID);
}
mapping seqdiagram::BIconixSqcDiagram::SeqDiagram2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
result := self.operations.map operation2variables
(generatorID);
}
}
mapping seqdiagram::BIconixOperation::operation2variables(in
generatorID : String) : Sequence(eventb::machine::Variable) {
init {
309
310
311
mapping seqdiagram::BIconixOperation::operation2guardparams(in
generatorID : String) : Sequence(eventb::machine::Event) {
init {
result := self.map operation2param(generatorID)->asSequence();
}
}
mapping seqdiagram::BIconixOperation::operation2param(in diagram :
seqdiagram::BIconixSqcDiagram, in generatorID : String) :
eventb::machine::Guard{
name := getGuardName();
predicate :=
generated := true;
attributes += getGeneratedAttr(generatorID);
}
mapping seqdiagram::BIconixOperation::operation2guardlifeline(in
diagram : seqdiagram::BIconixSqcDiagram, in generatorID : String) :
eventb::machine::Guard{
name := getGuardName();
predicate :=
mapping seqdiagram::BIconixOperation::operation2action(in
generatorID : String) : eventb::machine::Action {
name := getActName() ;
action := CONTROL + self.name + B_EQ + STARTED;
}
mapping seqdiagram::BIconixOperation::operation2parameter(in
generatorId : String) : eventb::machine::Parameter{
self.args->forEach(i){
312
name := self.i.name;
}
}
mapping seqdiagram::BIconixOperation::msgocc2REvents(in generatorID
: String) :eventb::machine::Event when{ not hasFather(self)} {
guards := self.map seq2guard(generatorID)->asSequence();
actions := self.map seq2action(generatorID)->asSequence();
parameters := self.map seq2parameter(generatorID)->asSequence();
generated := true;
}
mapping seqdiagram::BIconixOperation::seq2guard(in generatorID :
String) :
eventb::machine::Guard{
name := getGuardName();
predicate :=
self.name;
}
mapping seqdiagram::BIconixOperation::seq2action(in generatorID :
String) : eventb::machine::Action {
name := getActName() ;
action := self.name + B_BEQ + self.name + B_UNION + B_LBRC +
"unit" + B_RBRC;
}
mapping seqdiagram::BIconixOperation::seq2parameter(in generatorID :
String) : eventb::machine::Parameter {
name := "unit";
}
mapping seqdiagram::BIconixOperation::msgocc2SEvents(in generatorID
: String) :eventb::machine::Event when{ not hasFather(self)} {
313
}
mapping seqdiagram::BIconixOperation::seq2desaction(in generatorID :
String) : eventb::machine::Action {
name := getActName() ;
action := self.name + B_BEQ + self.name + B_MINUS + B_LBRC +
"own" + B_RBRC;
}
mapping seqdiagram::BIconixOperation::seq2desparameter(in
generatorID : String) : eventb::machine::Parameter {
name := "own";
}
mapping seqdiagram::BIconixCombinedFrag::frag2event(in generatorID :
String) : eventb::machine::Event {
guards := self.map frag2guard(generatorID)->asSequence();
parameters := self.map frag2parameter(generatorID)->asSequence();
generated := true;
}
314
self.operands.guard.constr;
}
mapping seqdiagram::BIconixCombinedFrag::frag2parameter(in
generatorID : String) : eventb::machine::Parameter {
name := "dmn";
}
mapping inout
eventb::machine::Event::SeqDiagram2initializations(in seqDiagram :
seqdiagram::BIconixSqcDiagram, in generatorID : String) {
name := INITIALISATION;
actions := seqDiagram.operations.map
operation2initializations(generatorID)->union
(actions->asSequence());
}
mapping seqdiagram::BIconixOperation::operation2initializations(in
generatorID : String) : Sequence(eventb::machine::Action) {
init {
result := self.map operation2initialization(generatorID)->
asSequence();
}
}
mapping seqdiagram::BIconixOperation::operation2initialization(in
generatorID : String) : eventb::machine::Action {
name := getActName();
action := CONTROL + self.name + B_BEQ + NOSTATUS;
}