Universidade Estadual de Maring

Centro de Tecnologia
Departamento de Informtica






A Utilizao do Mtodo Catalysis no Desenvolvimento de
Software Baseado em Componentes

Flvio Rogrio Uber


TG-22-98






















Maring - Paran
Brasil

i
Universidade Estadual de Maring
Centro de Tecnologia
Departamento de Informtica














A Utilizao do Mtodo Catalysis no Desenvolvimento
de Software Baseado em Componentes

Flvio Rogrio Uber













Trabalho de Graduao apresentado ao Curso de Cincia da
Computao, do Centro de Tecnologia, da Universidade
Estadual de Maring.
Orientadora: Profa. Dra. Elisa Hatsue Moriya Huzita








Maring - Paran

1998

ii
Flvio Rogrio Uber












A Utilizao do Mtodo Catalysis no Desenvolvimento
de Software Baseado em Componentes




Este exemplar corresponde redao final da monografia aprovada como requisito parcial
para obteno do grau de Bacharel em Cincia da Computao da Universidade Estadual
de Maring, pela comisso formada pelos professores:





________________________________________
Orientadora: Profa. Dra. Elisa Hatsue Moriya Huzita
Departamento de Informtica, CTC, DIN


________________________________________
Prof. Dr. Mrcio Eduardo Delamaro
Departamento de Informtica, CTC, DIN


________________________________________
Prof. Ademir Carniel
Departamento de Informtica, CTC, DIN








Maring, Dezembro de 1998

iii
Agradecimentos


Agradeo em primeiro lugar a Deus, que me deu sade e capacidade para superar todos os
obstculos, no apenas durante esses quatro anos, mas em todos os momentos de minha
vida.

No apenas agradeo, mas dedico todos esses anos aos meus pais, Alcides e Sueli, que me
deram todo amor e todo apoio para prosseguir nos momentos mais difceis. Sei que, sem
eles, nada em minha vida teria sido possvel. A esses seres humanos fantsticos, minha
eterna gratido. Que Deus os ilumine sempre.

Aos meus irmos, Ana Paula e Renato que, da mesma forma, deram todo o apoio familiar
para que esse fim de curso se tornasse realidade. So meus anjos da guarda em todos os
momentos .

Ao meu amigo Danillo, com quem ri e chorei durante esses quatro anos, e quem eu aprendi
a respeitar e admirar, que Deus o ilumine e o conduza pelas mos nos caminhos que ele
escolher.

Aos no menos amigos, Luciano, Gerson e Alexandre (Don) que tambm enfrentaram
juntos todas as batalhas e tornaram-se praticamente uma famlia para mim. Que a vida
traga-lhes tudo de melhor, eles merecem.

Aos demais amigos, Fbio (Honda), Junior, Fbio (Alm), Fbio Chavenco, Alisson
(Jordy), Eduardo, Kazumi com quem tive a alegria de conviver durante esse curso. So
amizades que eu espero que perdurem por muitos anos

Aos demais colegas de curso, eles tambm fizeram parte dessa caminhada, e estaro
sempre na minha lembrana e no meu corao.

Aos professores, que durante todo o curso transmitiram seus conhecimentos e portanto
tiveram papel fundamental em minha vida acadmica, que Deus lhes d sade para que
continuem sua misso educadora por muitos anos.

iv

Um agradecimento especial a minha orientadora, profa. Elisa Hatsue Moriya Huzita, que
sempre apoiou e incentivou para que esse trabalho se tornasse uma realidade. Obrigado
pela compreenso, pela pacincia e por tudo que aprendi e pude melhorar, tanto em minha
vida pessoal, quanto profissional.

v
Resumo

Ao longo dos anos, tem-se presenciado o surgimento de vrios mtodos e abordagens para
o desenvolvimento de software. Este dinamismo motivado pela crescente complexidade
dos software e pelos cuidados a serem observados para a obteno de produtos de
qualidade. Neste contexto, surgiu o desenvolvimento baseado em componentes (CBD),
uma abordagem que visa a rpida construo de uma aplicao a partir de componentes de
software pr-fabricados [Bro97].

Neste trabalho foi realizado um estudo do mtodo Catalysis, tema central do trabalho, que
se trata de um mtodo para desenvolvimento de software baseado em componentes. Em
seguida efetuou-se a especificao de um sistema para a realizao de uma anlise do
mtodo e avaliar os pontos fortes e fracos do mesmo com base na experincia obtida com
essa especificao.


vi
Abstract

Several methods and approach for the software development have been studied and
adopted by developers. This dynamism is motivated by the growing of software
complexity and for the requirements to be observed to obtain software with quality. In this
context, appeared the component-based development (CBD), an approach that seeks the
fast construction of an application starting from on the shelf software components [Bro97].

A study of the Catalysis method was accomplished. This is a method for component-based
development. This is the central issue of the work. The specification of a system, using the
Catalysis method has been done aiming at the evaluation of the method.

vii
ndice
NDICE..........................................................................................................................................VII
CAPTULO 1 - INTRODUO..................................................................................................... 1
1.1 MOTIVAO................................................................................................................................. 1
1.2 OBJETIVOS.................................................................................................................................... 2
1.3 ESTRUTURA DA MONOGRAFIA..................................................................................................... 2
CAPTULO 2 - DESENVOLVIMENTO BASEADO EM COMPONENTE............................. 4
2.1 INTRODUO................................................................................................................................ 4
2.2 DEFINIO ................................................................................................................................... 4
2.3 APLICAES E BENEFCIOS.......................................................................................................... 5
2.4 TIPOS DE COMPONENTES.............................................................................................................. 8
2.5 CONSIDERAES FINAIS .............................................................................................................. 9
CAPTULO 3 - CATALYSIS ....................................................................................................... 10
3.1 INTRODUO.............................................................................................................................. 10
3.2 CONCEITOS BSICOS.................................................................................................................. 10
3.3 PROCESSO DE DESENVOLVIMENTO............................................................................................ 12
3.4 PACOTES..................................................................................................................................... 19
3.5 CONSIDERAES FINAIS ............................................................................................................ 20
CAPTULO 4 - O SISTEMA EXEMPLO................................................................................... 21
4.1 INTRODUO.............................................................................................................................. 21
4.2 O SISTEMA EXEMPLO................................................................................................................. 21
4.3 DIAGRAMAS ............................................................................................................................... 22
4.4 CONSIDERAES FINAIS ............................................................................................................ 29
CAPTULO 5 - EXPERINCIA NA UTILIZAO DO MTODO....................................... 31

viii
5.1 APRENDIZADO DO MTODO........................................................................................................ 31
5.2 RECURSOS PARA MODELAGEM................................................................................................... 32
5.3 SUPORTE REUSABILIDADE....................................................................................................... 34
5.4 SUPORTE AO PROCESSO DE DESENVOLVIMENTO........................................................................ 34
5.5 MAPEAMENTO PARA A IMPLEMENTAO.................................................................................. 35
5.6 RESTRIES................................................................................................................................ 36
CAPTULO 6.................................................................................................................................. 38
CONCLUSES................................................................................................................................... 38
REFERNCIAS BIBLIOGRFICAS......................................................................................... 40
BIBLIOGRAFIA............................................................................................................................ 42
ANEXO A......................................................................................................................................... 1

ix
ndice de Ilustraes

Figura 3.1 - Mind Map ........................................................................................................ 12
Figura 3.2 - Diagrama de Contexto................................................................................... 13
Figura 3.3 - Cenrio............................................................................................................ 14
Figura 3.4 - Snapshot .......................................................................................................... 15
Figura 3.5 - Modelo de Tipos ............................................................................................. 16
Figura 3.6 - Diagrama de Interao.................................................................................. 17
Figura 3.7 - Diagrama de Classes ...................................................................................... 18
Figura 3.8 - Diagrama de Estados (Statechart)................................................................. 18
Figura 4.1 - Diagrama de Contexto.................................................................................. 22
Figura 4.2 - Cenrio (EfetuaReserva) .............................................................................. 23
Figura 4.3 - Snapshot (EfetuaReserva)............................................................................. 24
Figura 4.4 - Modelo de Tipos ............................................................................................ 26
Figura 4.6 - Diagrama de Estados (Reserva)................................................................... 28
Figura 4.7 - Diagrama de classes ...................................................................................... 29
Figura A.1 Cenrio (CancelaReserva) ............................................................................. 1
Figura A.2 Cenrio (AlteraReserva) ................................................................................ 2
Figura A.3 Cenrio (ConfirmaReserva) .......................................................................... 3
Figura A.4 Cenrio (AdicionaVo) .................................................................................. 3
Figura A.5 Cenrio (RemoveVo) .................................................................................... 4
Figura A.6 Cenrio (AlteraVo)....................................................................................... 5
Figura A.7 Cenrio (AlteraPassageiro)............................................................................ 5
Figura A.8 Cenrio (CriaListaEspera) ............................................................................ 6
Figura A.9 Cenrio (RemoveLista) .................................................................................. 7
Figura A.10 Cenrio (InsereNaLista) .............................................................................. 8
Figura A.11 Cenrio (RemoveDaLista) ........................................................................... 8
Figura A.12 Cenrio (TemReserva) ................................................................................. 9
Figura A.13 Snapshot (InserePassageiro) ...................................................................... 10
Figura A.14 Snapshot (AdicionaVo)............................................................................. 10
Figura A.15 Snapshot (CancelaReserva)........................................................................ 11
Figura A.16 Snapshot (AlteraReserva) .......................................................................... 11
Figura A.17 Snapshot (ConfirmaReserva)..................................................................... 12

x
Figura A.18 Snapshot (CriaListaEspera)....................................................................... 12
Figura A.19 Snapshot (RemoveLista)............................................................................. 13
Figura A.20 Snapshot (InsereNaLista)........................................................................... 13
Figura A.21 Snapshot (RemoveDaLista)........................................................................ 14
Figura A.22 Snapshot (TemReserva).............................................................................. 15
Figura A.23 Diagrama de Interao (CancelaReserva) ............................................... 16
Figura A.24 Diagrama de Interao (ConfirmaReserva) ............................................ 16
Figura A.25 Diagrama de Interao (AdicionaVo)..................................................... 17
Figura A.26 Diagrama de Interao (CriaListaEspera) .............................................. 17
Figura A.27 Diagrama de Interao (InsereNaLista)................................................... 18
Figura A.28 Diagrama de Interao (RemoveDaLista)................................................ 18
Figura A.29 Diagrama de Interao (TemReserva) ..................................................... 19
Figura A.30 Diagrama de Estados (Passageiro)............................................................ 20
Figura A.31 Diagrma de Estados (ListaEspera) ........................................................... 20
Figura A.32 Diagrama de Estados (Vo) ....................................................................... 21



1
Captulo 1


Introduo

1.1 Motivao

Desde a construo dos primeiros software, sob encomenda e de pequeno porte, at os dias
atuais, com sistemas distribudos, tcnicas avanadas e usurios exigentes, ocorreram
muitas mudanas de filosofia na especificao de um software, devido crescente
preocupao com a qualidade do software, e portanto, com o processo de desenvolvimento
destes. Pressman [Pre95] define a qualidade de software como a conformidade a
requisitos funcionais e de desempenho explicitamente declarados, a padres de
desenvolvimento claramente documentados e a caractersticas implcitas que so esperadas
de todo software profissionalmente desenvolvido.

Durante os anos 50 e 60 as aplicaes eram construdas de acordo com critrios pessoais
de desenvolvedores. Isso criou um problema quando tornou-se necessria a manuteno
desses software, que no possuam qualquer documentao e estruturao.

Na dcada de 60 assistiu-se a uma evoluo no sentido de definir processos para
desenvolvimento de software aliado adoo de linguagens de programao de mais alto
nvel. Nesta poca surgiram mtodos como a anlise estruturada, com nfase sobre os
processos e que procurava uma maneira de se documentar o processo de software, para que
seu desenvolvimento seguisse um padro que tornasse a construo de aplicativos no mais
uma tarefa para poucos intelectuais capacitados.

Nos anos 70 e 80, com o aparecimento do Banco de Dados relacional e a modelagem de
entidade-relacionamento passaram a ser enfatizados os dados.

Em meados da dcada de 80, comearam a surgir deficincias na anlise estruturada,
quando tentou-se aplicar o mtodo em aplicaes orientadas a controle. Surgiram ento,
extenses que consideravam aspectos de tempo real, introduzidas por Ward e Mellor
[War85] e Hatley e Pirbhai [Hat87]. No final da dcada de 80, o paradigma orientado a

2
objeto comeava a amadurecer numa abordagem poderosa [Pre95], com a proposta de
resoluo dos problemas da anlise estruturada e de preocupao com manipulao de
dados. Trata-se da aplicao de conceitos que so aprendidos na infncia, objetos,
atributos ... e que demorou tanto tempo para se notar sua aplicao na anlise e
especificao de um sistema. Por que? Segundo [Coa90] porque talvez estivssemos
preocupados demais seguindo o fluxo, durante o apogeu da anlise estruturada, para
considerarmos alternativas.


Atualmente o desenvolvimento de software encontra-se em meio a duas tendncias
significativas de mudana. Um diz respeito aos tipos de aplicaes existentes, e a outra de
como estas aplicaes so construdas. A primeira mudana, enfatiza a alta dos negcios
usando Internet, e o aparecimento da network computing como um novo modelo
computacional. A segunda, diz respeito ao aparecimento da abordagem de
Desenvolvimento Baseado em Componentes (CBD) [Ste97b].

1.2 Objetivos

Neste sentido, o desenvolvimento baseado em componentes norteia a realizao deste
trabalho que tem ainda o intuito de realizar o estudo do mtodo Catalysis e efetuar uma
anlise com base na especificao de um sistema exemplo .

A teoria de desenvolvimento baseado em componentes, como ser mostrado no captulo 2,
centrada no reuso de componentes pr-fabricados e na melhora da qualidade do produto
obtido, j que utilizando-se componentes testados no mercado tem-se maior garantia
quanto confiabilidade deste.

1.3 Estrutura da Monografia

O Captulo 2 mostra toda a teoria e aplicabilidade do desenvolvimento baseado em
componente. O Captulo 3 expe os princpios de Catalysis, bem como os diagramas que a
compem. O Captulo 4 descreve o sistema exemplo ilustrado com alguns exemplos dos
diagramas desenvolvidos. O Captulo 5 trata da anlise do mtodo, quais seus pontos
fracos e fortes com relao aos recursos oferecidos, tendo por base a especificao do

3
sistema exemplo. No Captulo 6 tem-se a concluso obtida com a realizao do trabalho e
o Anexo A apresenta os demais diagramas, no demonstrados no Captulo 4.

4
Captulo 2

Desenvolvimento Baseado em Componente

2.1 Introduo

Com base nas tendncias atualmente presentes no processo de desenvolvimento de
software, o objeto de estudo deste trabalho se refere ao Desenvolvimento Baseado em
Componente e a aplicao do mtodo Catalysis para desenvolvimento de sistemas
utilizando esta abordagem. Este captulo prope uma srie de conceitos referentes esta
abordagem bem como justificativas para a sua aplicabilidade. Com estas informaes
possvel se entender o porqu de vrias pesquisas relevantes que so desenvolvidas na rea,
e consequentemente sua importncia na Engenharia de Software e na informtica de modo
geral. Num primeiro momento tem-se algumas definies pertinentes abordagem baseada
em componentes, na sequncia algumas aplicaes possveis para a tecnologia e alguns
benefcios que se pode atingir com o seu uso. Por fim algumas consideraes acerca do que
pode ser um componente.

2.2 Definio

Desenvolvimento Baseado em Componentes (CBD) prope-se a ser uma maneira prtica e
radicalmente diferente de construir aplicaes oferecendo tcnicas imensamente melhores
de desenvolv-las, que seria mais barata, mais rpida e se adaptaria naturalmente com a
emergente tecnologia de objetos distribudos.

O conceito de componentes implica na separao da especificao da implementao,
garantindo a propriedade da reusabilidade, podendo-se, desta forma, utilizar um
componente para diversas aplicaes e substituir um componente por outro em um sistema
a qualquer momento. Como definiu [DSo97], Um componente uma unidade de
software, desenvolvida independentemente, que encapsula seu projeto e sua
implementao e oferece interfaces ao mundo externo, pela qual ele pode ser unido a
outros componentes e formar um grande sistema.


5
Alguns componentes podem ser vistos, como descritos acima, como unidades que so
unidas a outros componentes, enquanto outros componentes funcionaro mais como um
framework, ou seja, uma unidade de implementao projetada para um domnio genrico,
onde outros componentes podero ser associados e desta forma constituir um sistema
funcional ao usurio.

2.3 Aplicaes e Benefcios

A idia de CBD centralizada em dois pontos[Ste97c]:
O desenvolvimento de aplicaes pode ser melhorado significativamente se
elas puderem ser reunidas rapidamente a partir de componentes de software
pr-fabricados.
Uma coleo cada vez maior de componentes de software interoperveis
estar disponvel para desenvolvedores em catlogos gerais e especializados.

Estes pontos do Desenvolvimento Baseado em Componentes podem proporcionar aos seus
desenvolvedores e usurios vantagens que justificaro seu uso bem como o investimento
na mudana de tecnologia [Ste97c]. Algumas dessas vantagens seriam:
Reduo do tempo de desenvolvimento: atravs de consultas a catlogos de
componentes.
Reduo dos custos de desenvolvimento: os custos de construo de um
componente so maiores do que a aquisio de um componente j pronto.
Aumento de produtividade: a preocupao dos desenvolvedores seria com a
reunio de componentes e no com o desenvolvimento dos mesmos.
Reduo nos riscos de problemas: a garantia maior quando se pode obter
componentes devidamente testados e certificados.
Maior consistncia: componentes utilizam arquiteturas padres para
desenvolver aplicaes.

Pode-se observar que estas vantagens esto centradas basicamente no reuso de
componentes. No entanto, CBD possui trs princpios que se constituem em desafios para
se obter esse reuso [Bro97]. Estes princpios so:


6
1. Separao da especificao da implementao: Um dos maiores prejuzos no
reuso a necessidade de se conhecer detalhadamente a implementao de um componente
para se procurar, integrar ou atualizar uma pea. No desenvolvimento baseado em
componente a especificao separada de como ele implementado, permitindo que
implementaes sejam usadas ou trocadas sem impacto para o sistema. Logo, um
componente pode se adaptar prontamente a novos requisitos de operao.

2. Encapsulamento de dados e processos: Atravs do encapsulamento, o acesso s
funcionalidades de um componente est limitado s operaes fornecidas pela sua interface
diminuindo o impacto das mudanas em um componente.

3. Independncia da tecnologia de componentes: Um dos desafios de muitas
organizaes reduzir os esforos para reimplementar a funcionalidade de um componente
quando h uma mudana de plataforma. Para isso, o modelo de implementao deve estar
suficientemente detalhado para que o cdigo possa ser gerado para uma variedade de
plataformas. Quando h uma mudana de plataforma, essa descrio abstrata da
implementao de um componente usada para gerar automaticamente o cdigo para esta
nova plataforma.

Contudo, o reuso no o nico desafio no Desenvolvimento Baseado em Componentes.
Outros pontos merecem ateno, como por exemplo a sua aplicao. Neste sentido, podem
ser verificadas algumas perspectivas e realidades envolvendo CBD.

Com relao s perspectivas, nota-se como impressionante a rapidez com que os
negcios tm explorado a Web como uma tecnologia, expandindo os limites dos negcios.
A Web pode ser vista como uma nova plataforma de implementao para aplicaes
cliente/servidor. Oferecendo uma localizao independente e protocolos consistentes para
acesso informao e servio de software, a Web tem iniciado simultaneamente a
distribuio computacional e um novo comportamento de aplicaes.

O uso crescente de redes e da Web torna cada vez mais necessrio o desenvolvimento de
aplicaes que funcionem em uma rede corporativa ou na Internet, e o desenvolvimento
baseado em componente visa facilitar e tornar realidade esta tendncia.

7

Num futuro prximo [DSo97], se eventualmente um componente de um sistema encontrar-
se na rede, poder ser feito um download automtico deste conforme seja necessrio, da
mesma forma que muitos applets Java fazem hoje em dia.

Mas uma mudana radical como esta pode levar bastante tempo, afinal necessrio que os
desenvolvedores de software mudem suas atitudes, estando constantemente alerta para o
reuso; a tecnologia de desenvolvimento mudar e ser melhorada. O desenvolvimento de
novas metodologias ser necessrio e padres para integrao de componentes precisa ser
definido.

Alm disso, outras aplicaes j se tornaram realidade. Algumas organizaes j fazem uso
dos primeiros estgios de desenvolvimento de componentes[Ste97d], como VBX da
Microsoft para aplicaes de Visual Basic e controles ActiveX.

Um padro para descrio de interfaces de componentes a IDL (Interface Definition
Language), que permite aos componentes de software executar e se intercomunicar atravs
de redes, em diferentes plataformas.

O maior desafio, continua sendo o fato de sistemas serem desenvolvidos de forma
artstica, muito mais pela criatividade do desenvolvedor do que pela adoo de padres,
mtricas e regras de modo geral. Estes padres sero possveis quando as organizaes
atingirem uma maturidade da construo de software, seguindo, por exemplo, o modelo
CMM (Capability Maturity Model) [Pau95].

A abordagem de componentes separa o desenvolvimento de componentes de sua reunio
final dentro de sistemas, ou seja, menos ateno dada construo interna de
componentes e mais ateno dada s necessidades dos clientes. O importante O QUE o
componente faz e no COMO ele faz.





8
2.4 Tipos de Componentes

Na prtica os diferentes tipos de componentes possuem potencial para reuso em nveis
diferentes, e tambm melhoram a produtividade do desenvolvedor em escalas variveis. O
potencial para o reuso maior quanto menor for a granularidade do componente, ou seja,
quanto menos funcionalidades ele reunir, enquanto a produtividade do desenvolvedor
maior quanto maior for a granularidade do componente. Os tipos de componente so:
bibliotecas de classes, grande potencial de reuso e baixa produtividade do desenvolvedor
- componentes encapsulados, frameworks e aplicaes pr-construdas baixo potencial de
reuso e alta produtividade do desenvolvedor.

As bibliotecas de classes correspondem ao nvel mais baixo de abstrao de componentes e
possuem um grande potencial para reuso. O problema na sua utilizao a necessidade de
um conhecimento maior por parte do programador j que muitas vezes as bibliotecas de
classes so black box
1
.

Os componentes encapsulados so na verdade o mesmo que bibliotecas de classes porm
com a definio de uma interface que separar a especificao da implementao. Esta
separao faz com que componentes encapsulados elevem a produtividade do programador
em relao s bibliotecas de classes j que no se exige mais tanto conhecimento do
profissional.

Um framework uma reunio pr-construda de componentes junto com uma ligao que
os une. Sua arquitetura inicial no pode ser modificada, mas a possibilidade de se expandir
com a agregao de novos componentes faz com que seu objetivo se volte para atender
necessidades individuais. Muitos frameworks que aparecem no mercado como por
exemplo o CIM (Computer-Integrated Manufacturing) da SEMANTECH em um projeto
conjunto com a Texas Instruments - so construdos usando bibliotecas de classes
orientadas a objeto.


1
Um componente black box quando o usurio tem direito apenas de utilizao, e white box quando
tem acesso a seu cdigo fonte.

9
As aplicaes pr-construdas proporcionam grande produtividade para o desenvolvedor, j
que na teoria, com elas, nenhum cdigo requerido e o domnio totalmente coberto pela
funcionalidade do pacote pr-construdo. Hoje em dia um exemplo de aplicaes pr-
construdas o COM da Microsoft que permite que o Word acesse o Excel.

2.5 Consideraes Finais

Este captulo apresentou os conceitos envolvidos no Desenvolvimento Baseado em
Componente. CBD se prope a garantir a construo de software de forma mais rpida e
com maior qualidade, a partir de componentes pr-fabricados e reusveis.

A reusabilidade de um componente, apesar de ser sua caracterstica principal, visa sempre
a qualidade do processo de software e do produto final. Este o princpio de CBD: obter
produtos mais confiveis e garantidos atravs da reutilizao de componentes j testados
no mercado.

10
Captulo 3

Catalysis

3.1 Introduo

Diversas metodologias tm a proposta de suporte ao desenvolvimento baseado em
componentes. Nesse trabalho utilizou-se, a fim de realizar sua avaliao, o mtodo
Catalysis, uma metodologia centrada na UML (unified modeling language) e que adota
muitos conceitos da OMT (object modeling technique). Este captulo apresenta a
fundamentao terica inerente ao mtodo bem como os diagramas que fazem parte da
mesma. apresentado tambm o processo de desenvolvimento, conforme a proposta de
autores, em trs nveis: nvel de domnio do problema, nvel de especificao do
componente e nvel de projeto do componente.

3.2 Conceitos Bsicos

O mtodo Catalysis de desenvolvimento de software baseado [Ico96] nos princpios de
abstrao, preciso e associao de componentes. Estes princpios podem ser aplicados em
todos os nveis de desenvolvimento de software a partir do domnio de um problema.

Segundo Georg Pigel da Sterling Software [Ico96], Catalysis no pretende ser a resoluo
de todos os problemas, ela define uma maneira prtica de construir software baseada em
componentes de forma sistemtica. Fornece regras prticas ao invs de conceitos ... uma
abordagem passo a passo para implementao ... .

Segundo os conceitos[Ste97b] de Catalysis um componente de software possui:
Uma especificao, que descreve o que o componente faz e como ele se
comporta quando os seus servios so utilizados.
Uma implementao, expressa em termos de cdigo e dado que ser a garantia
de atendimento da especificao.
E o encapsulamento, a diviso entre a especificao e a implementao. Este
encapsulamento se d atravs de uma interface, que dar ao desenvolvedor,
acesso especificao do componente, mas o isolar da implementao.

11
As interfaces de um componente resumem como o cliente deveria interagir com ele, mas
escondem detalhes que fundamentam a implementao. Clientes de aplicaes e
componentes trabalham com a interface, no com as implementaes.

Os principais elementos de uma interface so:

Lista de operaes: cada operao possui um nome e sua assinatura (os parmetros
esperados do cliente e o valor retornado para ele); tambm precisa de uma semntica
precisa e previsvel para obter a confiana do cliente e poder ser implementada pelos
programadores.

Modelo de especificao: a descrio do vocabulrio ou termos para explicar
detalhadamente os efeitos da operao. Este modelo deve ser claro, preciso e ajudar a
descrever o estado de algum tipo de objeto.

Um conceito importante seria o de invariantes, ou seja, regras, ou condies estabelecidas
para o comportamento de um componente. Por exemplo, supondo que o salrio mximo de
um empresa no poderia ultrapassar dez mil reais.

Por sua prpria natureza, herdada da orientao objeto, Catalysis suporta polimorfismo,
agregao, associao e os demais princpios bsicos da OO.

O mtodo Catalysis baseado em trs conceitos principais [DSo97]:
1. Tipo: Um tipo no o mesmo que classe. Ele define o que um objeto faz, pela
especificao de seu comportamento externamente visvel; no descreve sua
implementao, como faz a classe. Por exemplo, um calendrio pode ser implementado de
vrias maneiras mas todas as maneiras exibem o mesmo comportamento, que descrito no
TIPO calendrio.

2. Colaborao: Como um grupo de objetos interage. Uma colaborao define um
conjunto de aes entre objetos tipados desempenhando certos papis em relao a outros
objetos na colaborao.


12
3. Refinamento: Relacionamento entre duas descries da mesma coisa (a realizao e a
abstrao). Um modelo abstrato de uma pessoa usa um atributo dinheiro, modelos mais
detalhados so baseados, por exemplo, em contas bancrias, carto de crdito...

3.3 Processo de Desenvolvimento

Quanto ao processo desenvolvimento de software, Catalysis na verdade no prope uma
ordem para o desenvolvimento dos diagramas. Alguns autores consideram como a melhor
forma de se executar o desenvolvimento pela diviso em trs nveis que seriam [DSo97]:
nvel de domnio do problema, nvel de nvel de especificao do componente e nvel de
projeto do componente.

3.3.1 Nvel de domnio do problema

Neste nvel, a nfase est no entendimento do problema. Envolve o desenvolvimento de
mind-maps ( figura 3.1), diagrama de contexto (figura 3.2) e cenrios (figura 3.3).

Mind-maps a representao estruturada de termos que so relacionados. Um mind-map
representado simplesmente por conceitos e/ou frases conectadas atravs de linhas. Os
conceitos so representados por verbos ou substantivos extradas da idia do problema.
Esta tcnica ajuda o desenvolvedor a obter uma viso geral do comportamento do sistema e
suas funcionalidades. O desenvolvedor passa a ter uma viso mais clara do escopo que ser
considerado. Alm de obter uma primeira impresso acerca das classes que faro parte do
sistema.
Exemplo de notao:
Loja
Mercadoria
Cliente
Fornecedor
Figura 3.1 - Mind Map

13
Outro diagrama dentro deste nvel seria o diagrama de contexto do sistema (figura 2). Ele
representa os atores e suas interaes. Por atores entende-se que sejam todos aqueles que
interagem com o sistema ou o prprio sistema, isto , todos que agem diretamente atravs
de operaes. Interaes so as aes que so praticadas pelos atores e que alteram estados
e/ou atributos de uma classe. Quando o ator um sistema ele representado por um
retngulo, e quando trata-se de um usurio representado pela ilustrao de um homem.
Isto ajuda a definir mais precisamente os limites do sistema com relao queles limites
definidos nos mind-maps. Com o diagrama de contexto o desenvolvedor tem a idia das
operaes do sistema e quais so os atores que interagem a fim de executar a operao. As
aes nas quais o sistema em questo um ator so aquelas que devem ser desenvolvidas
como parte do sistema.
Notao:
Contole de
Estoque
InserCliete
RemoveCliente
AlteraCliente
Efetua Compra
TrocaMercadoria
Figura 3.2 - Diagrama de Contexto

Finalmente, neste nvel seriam includos os cenrios (figura 3). Cada cenrio ilustra uma
sequncia na qual as aes acontecem. Geralmente, o desenvolvimento de cenrios ajuda
na identificao de aes que ainda no foram descritas no diagrama de contexto. Eles
passam ao desenvolvedor quais so as aes e interaes que so necessrias para que
ocorra determinada operao. Os atores que interagem nas aes so representados como
setas verticais e setas horizontais representam as aes que so realizadas e unem os atores
que interagem na ocorrncia desta ao.

14
Notao:
Venda Estoque
Operao: Venda
Cliente
Requisita Mercadoria
Verifica disponibilidade
em estoque
Existe disponibilidade
Entrega a mercadoria
Figura 3.3 - Cenrio



3.3.2 Nvel de Especificao do Componente

Neste nvel deseja-se descrever o comportamento do sistema, visvel externamente, de
forma no ambgua. O ponto de partida, neste nvel, o diagrama de contexto do nvel
anterior. Nesse nvel so desenvolvidos os snapshots (figura 3.4), a especificao das
operaes e o modelo de tipos (figura 3.5).

O primeiro ponto a ser considerado neste nvel a especificao das operaes.
Inicialmente as operaes so especificadas informalmente indicando as entradas
requeridas pela operao, as mudanas no objeto e as sadas retornadas, e ainda as
condies sob as quais o comportamento garantido. Isso feito atravs da definio de
pr e ps condies.


15
Em seguida ser necessria uma especificao formal das operaes. Para isto
necessrio: identificar entradas e sadas (valores retornados); identificar atributos (termos
derivados das entradas das operaes); identificar tipos para parmetros de entrada/sada;
formalizar a especificao da operao de modo a especificar sadas e mudanas de estados
nos atributos, estritamente em termos de entradas e atributos do objeto; revisar e melhorar
a especificao informal.

Os atributos do tipo so descritos como tipos do modelo, com atributos e associaes entre
eles, e invariantes que relacionam os valores vlidos dos atributos. As associaes tm uma
cardinalidade para indicar a multiplicidade de um tipo em relao a outro.

Para esclarecer como os atributos de um sistema so afetados por uma operao descrita no
cenrio, podemos criar os snapshots (figura 3.4). Eles mostram o subconjunto de valores
de atributos que existem antes da execuo de uma operao e depois desta. Olhando para
um snapshot, temos na parte superior a representao dos atributos antes da operao, e na
parte inferior, a representao dos atributos aps a operao, podendo-se assim visualizar e
especificar precisamente os efeitos de uma operao. Os snapshots tm o intuito de
fornecer uma representao visual dos efeitos da operao, no entanto, eles podem ser
expressos em forma de texto, indicando o valor de um atributo (classe.atributo) antes e
depois da operao.
Representao grfica:








Venda
Sabo em p
Preo: 3,40
Forencedor: Bom-Brill
Qtd. em estoque: 87
Sabo em p
Preo: 3,40
Forencedor: Bom-Brill
Qtd. em estoque: 87
Fatura 213
Mrio da Silva
Figura 3.4 - Snapshot

Finalmente, neste nvel, o sistema que est sendo desenvolvido representado como um
tipo, que consiste de um modelo e um conjunto de operaes sobre esse modelo. A
definio inicial envolve a identificao de cada ao na qual o sistema a ser desenvolvido

16
participa, especificando-a como uma operao sobre o tipo. representado por um
retngulo, onde a parte superior identifica o nome do tipo, a parte central a sua interao
com outros tipos e finalmente na parte inferior as operaes na qual o tipo interage (figura
3.5).
Representao:
Controle de Estoque
Venda (mercadoria, quantidade)
Compra (mercadoria, quantidade
Fornecedor
Loja
Cliente
Figura 3.5 - Modelo de Tipos

3.3.3 Nvel de projeto do componente

A nfase aqui definir uma estrutura interna e interaes que satisfaam os requisitos
comportamentais, tecnolgicos e de engenharia de software de um sistema. So
desenvolvidos os diagramas de interao (figura 3.6), diagrama de classes (figura 3.7) e os
diagramas de estados (figura 3.8).

Normalmente, cada tipo identificado na especificao do modelo de tipo do componente
ser implementado como uma classe separada.

Para cada operao especificada, identifica-se um objeto para receber a operao
requisitada. Identificado o receptor da operao, constri-se um diagrama de interao
(figura 3.6) para especificar como os objetos interagem com outros para atingir o resultado
da operao.


17
Para construir este diagrama de interao:
- Use os snapshots criados na anlise para definir a configurao inicial do
objeto.
- Identifique as requisies recebidas por cada objeto como uma operao sobre
esta classe.
- Identifique os atributos de classe para indicar o que cada classe precisa
considerar antes e depois de cada requisio recebida.
Notao:
Loja Estoque
Requisita mercadoria
Requisita mercadoria
Vende
Figura 3.6 - Diagrama de Interao



Pode-se agora comear a definir o modelo de classes (figura 3.7). Este consiste das classes
que compe o sistema, seus atributos e operaes e as associaes entre eles. Na parte
superior da representao de uma classe descreve-se o nome da classe, enquanto na parte
intermediria so descritos os atributos e na parte inferior as operaes.

18
Notao:
Compra
Vende
Nome
CGC
Endereo
Telefone
Loja
InsereCliente
AlteraCliente
RemoveCliente
Nome
Endereo
Telefone
RG
Cliente
* *
Figura 3.7 - Diagrama de Classes

Associado a isso existiria o diagrama de estados representado por statecharts [Har96] que
representariam os estados de uma classe (Figura 3.8), ou seja, quais as condies de uma
classe aps a realizao de transio que em Catalysis correspondem a ocorrncia de uma
operao.

Inexistente
Ok
Em Dbito
Diagrama de
Estados: CLIENTE
Existente

Figura 3.8 - Diagrama de Estados (Statechart)



19

3.4 Pacotes

Realizada a especificao de um sistema, pode-se dar a construo de pacotes (figura 3.9).
O pacote a unidade bsica de desenvolvimento de um produto.

Ele tem como finalidade a reunio de informaes que estejam associadas para que um
usurio possa utilizar-se de apenas parte de um componente, ou seja, ele faria uso apenas
do pacote. Outro aspecto que justificaria seu uso a facilidade de controle no
desenvolvimento a partir de unidades bsicas que possuem uma certa independncia de
outros pacotes.

O pacote a coleo de todas as classes definidas e das operaes sobre elas, seja em
forma de diagramas ou de texto. Toda modelagem feita dentro de algum pacote. Ele
poderia conter tipos e classes, cdigo fonte ou compilado, grupos de classes que no fariam
sentido uma sem a outra, diagramas, outros pacotes, frameworks e etc...
Exemplo da notao de um pacote:
Um pacote
aaaaaaaaaaaaaa
aaaaaaaaaaaaaa
aaaaaaaaaaaaaa
Figura 3.9 - Pacote



20
3.5 Consideraes Finais

Neste captulo foram apresentados os conceitos de Catalysis, fazendo seus recursos irem ao
encontro da proposta do desenvolvimento baseado em componentes. Foram demonstrados
os diagramas que compem a metodologia e qual a funo de cada um deles na
especificao de um sistema.

Notou-se o suporte ao desenvolvimento baseado em componentes atravs da construo do
modelo de tipos e eventualmente, de pacotes que sero analisados com mais detalhes
no captulo 5.

21
Captulo 4

O Sistema Exemplo

4.1 Introduo

Para que se pudesse aplicar a teoria referente ao mtodo Catalysis realizou-se a
especificao de um sistema exemplo. O sistema escolhido foi de reserva de passagens
areas. Este sistema, mesmo com as simplificaes propostas para sua modelagem,
mostrou-se adequado para o desenvolvimento baseado em componente, j que ele pode ser
usado tambm por uma empresa de turismo, por exemplo, que utilize esse sistema
associado a um sistema de reserva em hotis ou qualquer outra funcionalidade pertinente a
ela.

Como descrito no Captulo 3, foram desenvolvidos: diagrama de contexto, cenrios,
snapshots, especificao das transaes, modelo de tipos, diagrama de interao, diagrama
de classe e diagrama de estados. A seguir ser apresentado um exemplo de cada diagrama
desenvolvido. No anexo A sero apresentados os demais diagramas.

4.2 O Sistema Exemplo

O sistema exemplo modelado hipottico e tratar de reservas de passagens para um
determinado aeroporto X. Como tal, este sistema atender a reserva e venda para todos os
vos e empresas disponveis em X.

O passageiro, quando desejar efetuar uma reserva, deve informar ao sistema o destino e a
data desejada para a viagem. O sistema automaticamente apresentar opes para que o
passageiro escolha o horrio, a classe e a empresa de sua preferncia. No caso de no
existirem vagas o passageiro pode optar por ser includo na lista de espera e desta forma
obter uma reserva to logo se torne disponvel uma vaga em um vo. Em ambos os casos o
passageiro ser cadastrado na lista de passageiros.


22
Se a reserva for concretizada o passageiro deve fornecer ao sistema, dados bsicos a seu
respeito como nome, RG, endereo e telefone.

Encerrada a reserva, o sistema fornece um nmero que poder ser utilizado para,
eventualmente, ter acesso ao sistema e modificar os itens desejados da reserva. Esse
nmero ser usado tambm para a obteno do PTA to logo seja confirmada a reserva por
parte do passageiro. Essa confirmao se dar atravs do pagamento da passagem.

O sistema manter tambm uma base de dados com os vos disponveis em X. Esta base
ser utilizada para consulta dos horrios de vos disponveis, e tambm para atualizao
dos lugares disponveis em cada vo, conforme forem acontecendo as reservas. As
empresas tero acesso a esta base de dados para cadastro, ou seja, insero, remoo e
alterao de seus vos, e o sistema deve dar suporte para isso.

4.3 Diagramas

A seguir so apresentados um exemplo de cada um dos diagramas desenvolvidos.

4.3.1 Diagrama de Contexto
Reserva
OPERADOR
PASSAGEIRO
AdicionaVoo
RemoveVoo
AlteraVoo
EfetuaReserva
CancelaReserva
AlteraReserva
ConfirmaReserva
AdicionaLista
RemoveLista
InsereNaLista
RemoveDaLista

Figura 4.1 - Diagrama de Contexto


23
Atravs desse diagrama (Figura 4.1) pode-se notar que, em contextos diferentes, a
interao entre o passageiro e o sistema pode gerar as operaes referentes reserva ou
lista de espera, e por esse motivo so representados separadamente.

4.3.2 Cenrios


EfetuaReserva / InserePassageiro

Passageiro Reserva Vo
Listade
Passageiros
Determi na o desti no e
data da viagem
Consulta horrios, classe
e empresa disponveis
Apresenta horrio/classe/
empresa
Apr esent a opes ao
usurio
Escolhe dentre as opes
Ge r a n me r o p a r a
obteno do PTA
Efetua Reserva
Atualizar quantidade de
lugares vagos
Requisita nome/endereo/
telefone/RG
Entra com dados pessoais
Confirma dados
OK
Dados do Passageiro

Figura 4.2 - Cenrio (EfetuaReserva)


Atravs deste diagrama (Figura 4.2) podemos observar todos os passos, ou seja, todas as
aes realizadas entre os atores para desempenhar a operao de EfetuaReserva, bem

24
como quais so os atores que participam desta operao. Neste diagrama, todas as
interaes passam pelo sistema de reserva.

Note que a operao InserePassageiro representada no mesmo cenrio, por essa ser
uma consequncia da operao de EfetuaReserva. Isso ocorrer em outros diagramas
pelo mesmo motivo.



4.3.3 Snapshots / Especificao das transaes

EfetuaReserva
Vo 693
So Paulo
15:00 h
25 lugares - 1a. Classe
EfetuaReserva
Joo da Silva
Reserva 23
Vo 693
So Paulo
15:00 h
24 lugares - 1a. Classe

Figura 4.3 - Snapshot (EfetuaReserva)


Operao EfetuaReserva (num_reserva, num_voo, nome_passageiro)
Pr: O vo desejado est cadastrado e com disponibilidade de lugares (lugares>0)
Ps: Passa a existir um registro com a reserva do passageiro requisitante para o vo
requisitado, que passa a ter um lugar disponvel a menos (lugares=lugares-1)











25

Especificadas as operaes foi construdo o dicionrio de dados, uma tabela que descreve
como os atributos so criados e modificados.

Dicionrio:


Tipo Descrio Aes que o criam
Atributos Descrio Aes que o
escrevem
Registro que estabelece uma reserva para determinado
vo.
EfetuaReserva
Nome_passageiro
Atributo: Nome do passageiro
para o qual a reserva foi efetuada
InserePassageiro
num_voo
Atributo: Vo para o qual a
reserva foi feita
AdicionaVo
Data
Atributo: Data para a qual a
reserva foi feita
EfetuaReserva
Classe
Atributo: Classe para a qual a
reserva foi feita
EfetuaReserva
Nmero_reserva Atributo: Nmero da reserva EfetuaReserva
Reserva
PTA
Atributo: Identificao do
passageiro para o vo
ConfirmaReserva
Registro que cadastra um passageiro que esteja
efetuando uma reserva.
InserePassageiro
Nome_passageiro
Atributo: Nome do passageiro
que est efetuando a reserva
InserePassageiro
Rg_passageiro
Atributo: RG do passageiro que
est efetuando a reserva
InserePassageiro
End_passageiro
Atributo: Endereo do passageiro
que est efetuando a reserva
InserePassageiro
Passageiro
Tel_passageiro
Atributo: Telefone do passageiro
que est efetuando a reserva
InserePassageiro
Registro que cadastra um vo de forma a
disponibiliz-lo para reservas
AdicionaVo
NomeEmpresa
Atributo: Nome da empresa que
fornece o vo
AdicionaVo
Num_vo
Atributo: Nmero do vo
cadastrado
AdicionaVo
Destino_vo
Atributo: Destino do vo
cadastrado
AdicionaVo
Horrio_vo Atributo: Horrio de sada do vo AdicionaVo
Vo
Lugares
Atributo: Quantidade de lugares
vagos no vo
AdicionaVo/
EfetuaReserva





26

Base de dados que armazena todos os passageiros que
esto aguardando liberao de lugar em algum vo
AdicionaLista
Destino
Atributo: Destino para o qual se
deseja uma reserva
AlteraLista
Data_lista
Atributo: Data para a qual se
deseja uma reserva
AlteraLista
Horrio_lista
Atributo: Horrio para o qual se
deseja uma reserva
AlteraLista
ListaEspera
Nome_passageiro
Atributo: Nome do passageiro
que deseja uma reserva
InserePassageiro




4.3.4 Modelo de Tipos


Reserva
EfetuaReserva (num_reserva, num_voo, nome_passageiro)
CancelaReserva (num_reserva, num_voo, nome_passageiro)
AlteraReserva (num_reserva, num_voo, nome_passageiro)
ConfirmaReserva (num_reserva, num_voo, nome_passageiro)
AdicionaVo (num_voo)
RemoveVo (num_voo)
AlteraVo (num_voo)
AlteraPassageiro (nome_passageiro)
Passageiro Vo
ListaEspera
*
* *
*
1 1

Figura 4.4 - Modelo de Tipos


27

4.3.5 Diagrama de interao


Nesses diagramas, a notao muito semelhante de cenrios, no entanto semanticamente
possuem diferenas. No diagrama de interao representamos as operaes e respostas -
setas tracejadas - a essas operaes por parte dos atores do sistema. Em termos prticos,
uma representao de operao feita por um diagrama de interao pode ser detalhada em
termos de aes que compem esta operao (cenrios).

As setas que saem de um ator e retornam a ele mesmo, formando um ciclo, representam
aes deste ator que afeta a ele mesmo, em seus atributos e/ou estados.

De modo a facilitar a compreenso, ao longo do desenvolvimento dos diagramas foram
representados no somente as requisies de operaes mas tambm as requisies de
dados e etc...

EfetuaReserva

Passageiro Reserva ListaPassageiro
EfetuaReserva
Dados do Passageiro
InserePassageiro
Insere
Reserva

Figura 4.5 - Diagrama de interao (EfetuaReserva)

28
Nesse diagrama (Figura 4.5) ListaPassageiro uma base de dados e a operao
InserePassageiro, sobre ele identifica uma entrada de dados que executada e retorna uma
resposta que, no caso, simboliza a concretizao da insero. Os ciclos Reserva e Insere
podem ser visualizados detalhadamente em uma consulta ao cenrio correspondente a esse
diagrama de interao.



4.3.6 Diagrama de estados

Reserva
Inexistente
Efetuada
Confirmada
Data Atual >
Data Reserva
C
o
n
f
i
r
m
a
R
e
s
e
r
v
a
EfetuarReserva
CancelarReserva
Existente

Figura 4.6 - Diagrama de Estados (Reserva)


Este diagrama de estados da classe Reserva (Figura 4.6) representa, a princpio dois
estados: existente ou inexistente. No entanto, quando a reserva existente, ela pode ser
ainda, efetuada ou confirmada. Com a realizao das transies operaes a classe
pode mudar de estado, conforme representado. Quando a data atual ultrapassa a data
programada para a reserva, a instncia da classe destruda.











29
4.3.7 Diagrama de classes


EfetuaReserva
CancelaReserva
AlteraReserva
ConfirmaReserva
num_reserva
nome_passageiro
num_voo
data
classe
PTA
Reserva
AdicionaVoo
RemoveVoo
AlteraVoo
num_voo
nome_empresa
horario_voo
destino_voo
lugares
Vo
CriaListaEspera
RemoveLista
InsereNaLista
RemoveDaLista
TemReserva
data_lista
horario_lista
destino
nome_passageiro
ListaEspera
InserePassageiro
RemovePassageiro
AlteraPassageiro
nome_passageiro
rg_passageiro
endereco_passageiro
telefone_passageiro
Passageiro
EmitePassagem
CancelaPassagem
TransferePassagem
num_passagem
nome_passageiro
num_voo
data_voo
num_poltrona
Passagem

Figura 4.7 - Diagrama de classes


4.4 Consideraes Finais

O sistema de reserva de passagens areas modelado, foi simplificado quanto s suas
atribuies, no entanto mostrou-se satisfatrio para a aplicao dos recursos do mtodo
Catalysis, e desta forma, prover o material necessrio para sua anlise, que ser
apresentada no captulo 5.


30
De acordo com os conceitos de componente apresentados no captulo 3, este sistema pode
funcionar como um sistema independente, ou como um componente associado a outros
componentes que teriam a funcionalidade de reserva em hotis para os passageiros, ou de
aluguel de carros quando o passageiro chegasse cidade destino e uma srie de outros
componentes que expandiriam a utilidade deste sistema.

31
Captulo 5

Experincia na Utilizao do Mtodo

Como definido anteriormente o objetivo primordial deste trabalho realizar uma anlise da
metodologia Catalysis a fim de tentar traar um perfil de seus pontos fracos e fortes. Os
aspectos aqui abordados no a tornam melhor ou pior que outra metodologia, ou seja, a
anlise foi feita em termos absolutos para evitar uma comparao em relao a outras que
no foram objetos de estudo. A anlise aqui tratada foi realizada com base na experincia
de utilizao do mtodo. Desta forma foram avaliados aspectos acerca da aprendizagem do
mtodo, dos recursos proporcionados para a modelagem, do suporte dado pelo mtodo
reusabilidade e por fim, algumas consideraes respeito do processo de desenvolvimento
e restries impostas quanto aos recursos do mtodo.

5.1 Aprendizado do mtodo

O primeiro aspecto considerado foi com relao aprendizagem da metodologia, ou seja,
se este se constituiria em um ponto negativo para os desenvolvedores ou no. Para o
desenvolvimento deste trabalho existiu este problema devido pouca disponibilidade de
material e a falta de didtica do material existente. No entanto, fcil concluir, pela
descrio aqui apresentada, que a partir de um material bem elaborado o aprendizado pode
tornar-se uma tarefa alm de fcil, agradvel, principalmente para aqueles que j tem
conhecimento de UML, ou j tem contato direto com outras metodologias orientadas a
objeto.

O conhecimento de outras metodologias orientadas a objeto facilita o aprendizado j que
Catalysis adota muitos aspectos conceituais e prticos dessas metodologias, como por
exemplo a existncia do diagrama de classes desenvolvido da mesma forma que nos
mtodos OO e outros diagramas, como os cenrios e o diagrama de estados.

Em relao ao diagrama de estados, apesar deste estar presente em outras metodologias,
um ponto desfavorvel ao aprendizado de Catalysis, j que o conhecimento de statecharts
desejvel para a confeco destes diagramas. Este conhecimento desejvel na medida

32
em que facilita o trabalho do desenvolvedor, que atravessaria essa fase da especificao
sem maiores obstculos.

5.2 Recursos para modelagem

Analisando os recursos proporcionados por uma modelagem utilizando Catalysis o
primeiro aspecto considerado foi a viso do sistema. Essa viso refere-se a quanto pode-se
abstrair sobre o funcionamento do sistema a partir de seus diagramas.

Pode-se notar que uma viso detalhada favorecida medida que temos diagramas que
descrevem com bastante preciso detalhes do sistema, como por exemplo os requisitos e
consequncias de operaes atravs da especificao de operaes em termos de pr e
ps condies - ou mesmo as classes que interagem e qual a sequncia de aes em uma
operao atravs dos cenrios.

No entanto, essa viso muito detalhada acaba por prejudicar uma viso geral de como o
sistema interage j que no se tem nenhum diagrama que represente todas as interaes das
classes simultaneamente. Exceo feita ao diagrama de classes que, no entanto, apenas
descreve quais classes que esto relacionadas, independente de quais operaes as
relacionam. Uma tentativa de se obter uma viso geral atravs do diagrama de interao.
No entanto, ele mostra o comportamento global para cada operao e no o
comportamento de todas as operaes.

Os demais recursos proporcionados pela modelagem referem-se aos recursos individuais
de cada diagrama, que podem ser sumarizados da seguinte maneira:

Diagrama de contexto Este diagrama relaciona todos os atores envolvidos nas operaes
que o sistema se dispe a realizar. Assim o desenvolvedor passa a ter a viso do escopo do
sistema, isto , do problema a ser resolvido.

Cenrios Determinado o escopo, atravs dos cenrios, como o prprio nome sugere, o
desenvolvedor ter a descrio de quais passos compem cada operao, ou seja, quais as

33
aes que sero praticadas pelos integrantes do sistema (atores, bases de dados e o prprio
sistema) para atingir o resultado desejado.

Especificao das operaes Determina uma operao em termos de pr e ps
condies. Desta forma, o usurio ter uma descrio dos requisitos de uma operao e
quais as consequncias desta. Agem juntamente com os snapshots para proporcionar esta
viso.

Snapshots Como dito anteriormente, tem a funo de proporcionar, em uma
representao grfica, os efeitos de uma operao e analisados em conjunto, proporciona a
viso dos requisitos da operao. Isso pode ser visto, no caso do sistema modelado, para a
efetivao de uma reserva. A visualizao do estado das classes e atributos antes da
operao de EfetuaReserva e CriaListaEspera a mesma, com exceo da quantidade de
lugares vagos que igual a 0 no segundo caso. Assim, analisados em conjunto, esses
snapshots provem informaes sobre quais so os requisitos para ambas as operaes.

Modelo de Tipos Este diagrama praticamente define o sistema como um componente, ou
seja, representa o sistema como um tipo e quais operaes so disponibilizadas para o
usurio externo, definindo em grande parte qual a interface do componente.

Diagrama de interaes Este diagrama representa a interao entre as classes para atingir
o resultado de uma operao. Pode ser definido como uma generalizao dos cenrios.
Desta forma, um diagrama de interaes representa a comunicao entre classes e as
respostas geradas desta comunicao, enquanto, para um detalhamento de quais aes so
realizadas para se ter esta comunicao, consulta-se os cenrios.

Diagrama de classes Representa as classes com todos os seus atributos e operaes, e
ainda, a interao entre as classes e a cardinalidade desse relacionamento. Assemelha-se
representao interna do modelo de tipos, onde tambm esto representados todos os
relacionamentos entre as classes do sistema.

Diagrama de estados Representa os estados de uma classe. Este estado alterado em
funo da mudana de atributos e/ou na situao da classe. O diagrama representa tambm

34
quais so as operaes que causam a mudana no estado. Desta forma tem-se uma
representao da dinmica do funcionamento do sistema com a ocorrncia das operaes.

5.3 Suporte reusabilidade

A grande questo que analisa-se quanto ao desenvolvimento baseado em componentes
com relao reusabilidade. Desta forma, Catalysis deve fornecer mecanismos que dem
suporte reusabilidade do componente especificado.

Este suporte fornecido principalmente atravs do diagrama de tipos. Este diagrama define
o sistema (componente) modelado como um tipo. Representa-se quais as classes que esto
a ele relacionadas a fim de representar um aspecto interno do sistema e que irrelevante
para seus objetivos.

So especificados tambm quais as operaes que este componente prov externamente,
isto , atravs de quais operaes ele far sua comunicao com componentes externos.
Pode-se notar que esta justamente a caracterstica da interface de um componente.

5.4 Suporte ao processo de desenvolvimento

Os autores de Catalysis propem como um processo de desenvolvimento, uma diviso em
trs nveis como descrito no Captulo 3. No entanto, verificou-se que algumas alteraes
nessa diviso melhoram a compreenso do desenvolvedor para a especificao de um
sistema. Estas alteraes so descritas a seguir.

No item 5.2 foi colocada a relao existente entre os cenrios e os diagramas de interao.
Portanto, o desenvolvimento em conjunto, ou em sequncia, desses dois diagramas facilita
o entendimento do desenvolvedor com relao s interaes entre as classes.

Outra alterao na construo do diagrama de tipos, que deveria ser efetuada to logo
sejam identificadas as operaes atravs do diagrama de contexto e dos cenrios para
que o desenvolvedor j saiba qual o perfil do componente que est sendo modelado.


35
5.5 Mapeamento para a implementao

A passagem da especificao para a implementao tende a ser uma facilitada com o uso
de Catalysis. Vrias visualizaes do sistema facilitam essa viso em termos de
implementao. Entre as quais pode-se destacar: a especificao das transaes, na qual se
tem os requisitos para se realizar uma operao e quais os efeitos desta nos atributos e/ou
estados de uma classe. E ainda os diversos diagramas - cenrios, diagrama de interao
que representam quais as entidades que se relacionam para a realizao das operaes.

A seguir podemos verificar a declarao das classes do sistema onde podemos verificar a
influncia do diagrama de classes:

package sistema;

public class reserva{

int numero;
int num_voo;
String data;
String classe;
String PTA;
passageiro pr;

public void EfetuaReserva(){}
public void CancelaReserva(){}
public void AlteraReserva(){}
public void ConfirmaReserva(){}
}


package sistema;

public class passageiro {

String nome;
String rg;
String endereco;
String telefone;

public void InserePassageiro(){}
public void RemovePassageiro(){}
public void AlteraPassageiro(){}
}

package sistema;


36
public class voo{

String numero;
String nome_empresa;
String horario;
String destino;
String lugares;

public void AdicionaVoo(){}
public void RemoveVoo(){}
public void AlteraVoo(){}
}


package sistema;

public class ListaEspera{

String data;
String horario;
String destino;
passageiro ple;

public void CriaListaEspera(){}
public void RemoveLista(){}
public void InsereNaLista(){}
public void RemoveDaLista(){}
public void TemReserva(){}
}


Nessas declaraes pode-se verificar que a classe passageiro ser instanciada toda vez
que reserva ou uma ListaEspera for instanciada destacada em negrito - , o que foi
identificado como requisito do sistema e desenvolvido ao longo de toda especificao.

Outro ponto da implementao que facilitada com a especificao a instanciao de
classes no que se refere s operaes. Percebe-se que no basta apenas a instanciao da
classe a qual ela pertence e sim de todas as classes que participam da operao o que
visualizado no diagrama de interao.


5.6 Restries

Se considerarmos que uma metodologia deveria prover suporte a todo o ciclo de vida de
um software, Catalysis deixa a desejar, j que no proporciona qualquer recurso, para

37
explicitamente, fazer a execuo de testes. Seria necessrio a elaborao de um plano de
testes independentes para se verificar a validade de um sistema.

Uma outra restrio refere-se especificao da distribuio de um software. Visto que o
desenvolvimento baseado em componentes prev a integrao de um software distribudo,
a metodologia deveria prever essa distribuio de forma mais transparente, j que a nica
maneira de se prever a distribuio atravs de pacotes, cujo desenvolvimento opcional,
no se tratando de um diagrama integrante de Catalysis.

Uma soluo possvel para isso seria que os usurios futuros considerassem a construo
de pacotes como parte integrantes do processo de desenvolvimento.



38
Captulo 6

Concluses

A crescente busca pela qualidade no software por parte do usurio final, faz com que os
desenvolvedores busquem constantemente novas tecnologias para a construo mais rpida
de aplicaes que resultem em produtos com maior qualidade.

Uma destas tecnologias o desenvolvimento baseado em componentes, que prope a
construo de componentes reusveis atravs da especificao de uma interface que faz
com que o usurio se preocupe com o que o componente faz e no como faz e de maior
qualidade utilizando-se componentes que j so utilizados no mercado e portanto
devidamente testados.

A propsito, a reusabilidade e a qualidade so caractersticas muito em voga na produo
de software hoje em dia, o que torna o desenvolvimento baseado em componentes uma
tecnologia promissora no que se refere aos requisitos impostos pela sociedade indstria
do software.

O mtodo Catalysis prov os recursos necessrios para o suporte ao desenvolvimento
baseado em componentes atravs de uma semntica clara e sem ambiguidades. O suporte
dado atravs, principalmente, do modelo de tipos, que define a interface do sistema
modelado, isolando-o da implementao. Esse suporte tambm possvel atravs da
construo de pacotes captulo 3 onde pode-se definir partes do sistema modelado
como um componente, caracterstica que no se aplicou ao sistema representado nesse
trabalho em virtude da simplificao do sistema. No caso de um sistema mais completo,
como sugerido anteriormente, com a agregao de reserva de hotis, esta caracterstica
poderia ser visualisada.

O mtodo apresentou-se apropriado para o objetivo a que se dispe, sendo o aprendizado,
como descrito no captulo 5, relativamente fcil. O processo de desenvolvimento, com as
mudanas propostas neste captulo, torna a tarefa de especificao agradvel e
compreensvel para o desenvolvedor.

39

O que destaca Catalysis como metodologia o rigor de seus conceitos e da sua notao, o
que dificulta uma especificao com ambiguidades na interpretao de seus resultados.
Esse rigor vai desde a definio clara e precisa do problema a ser resolvido at a utilizao
de mtodos formais nos diagramas de classe e na especificao de operaes.

Um trabalho futuro seria a utilizao deste sistema em conjunto com outros componentes,
como a integrao com sistema de reserva de hotis ou aluguel de carros para os
passageiros e desta forma analisar um comportamento mais complexo e visualizar a
construo e a utilidade dos pacotes.

A concluso principal obtida com esse trabalho que a utilizao de metodologias
adequadas para especificao facilita o desenvolvimento e permite zelar por caractersticas
que conduziro a produtos de melhor qualidade, o que significa dizer que sero cumpridas
as maiores exigncias de desenvolvedores e clientes no que se refere produo de
software.


40
Referncias Bibliogrficas


[Bro97] Brown, Alan W. & Morrow, Brian. Component Based Development for the
Enterprise , http://www.jorvik.com/alan/oo-cbd.html. 1997.

[Coa90] Coad, P. e E. Yourdon. Object-Oriented Analysis. Prentice-Hall. 1990.

[DSo97] DSouza Desmond, Wills Alan C. Objects, Components, and Frameworks
With UML The Catalysis Approach. Addison-Wesley Publishing Company.
1997.

[Har96] Harel, David. Statecharts: a visual formalism for complex systems.
Science of Computer Programming. 1987.

[Hat87] Hatley, D. J. e I. A. Pirbhai, Strategies for Real-Time System Specification.
Dorset House. 1987.

[Ico94] Icon Computing, Inc. Catalysis , http://www.iconcomp.com/
papers/catalysis-flyer.html. 1994.

[Ico96] Icon Computing, Inc. Catalysis , http://www.iconcomp.com/
catalysis/europe-tour.html. 1996.

[Ste97a] Sterling Software. Compontent Based Development and Object Modeling ,
http://www.cool.sterling.com/cbd/whitepaper/4.html. 1997.

[Ste97b] Sterling Software. Component Based Development and Object Modeling ,
http://www.cool.sterling.com/cbd/whitepaper/1.html. 1997.

[Ste97c] Sterling Software. Component Based Development and Object Modeling ,
http://www.cool.sterling.com/cbd/whitepaper/2.html. 1997.


41
[Ste97d] Sterling Software. Component Based Development and Object Modeling ,
http://www.cool.sterling.com/cbd/whitepaper/3.html. 1997.

[Pau95] Paulk Mark C., Weber Charles V., Curtis Bill, Chrissis Mary Beth. The
Capability Maturity Model: Guidelines for Improving the Software Process.
Addison-Wesley Publishing Company. 1995.

[Pre95] Pressman, Roger S. Engenharia de Software . Makron Books. 1995.

[War85] Ward, P. T. e S. J. Mellor, Structured Development for Real-Time
Systems. Yourdon Press. 1985.








42
Bibliografia


[Bar97] Barn, Balbir & Brown, Alan W. Improving Software Reuse Through
Component-Based Development Tools . http://jorvik.com/alan/icrs5/index.html. 1997.

[Sys95] Systems Techniques, Inc. OO and Component Based Development: Where
Do We Go From Here ? . 1995.




1
Anexo A

Aqui esto representados os demais diagramas desenvolvidos, ou seja, o restante dos
cenrios, dos diagramas de interao e dos diagramas de estados. Estes diagramas em
conjunto com aqueles apresentados no captulo 4 constituem-se na documentao deste
software exemplo.


CENRIOS


CancelaReserva / RemovePassageiro
Passageiro Reserva Vo
Listade
Passageiros
Ent r a com nmer o da
reserva
Conf i r ma val i dade do
nmero
Conifrma cancelamento
Indica cancelamento da
reserva
Atual i za quanti dade de
lugares vagos
E x c l u i d a d o s d o
passageiro

Figura A.1 Cenrio (CancelaReserva)

Atravs deste diagrama podemos observar todos os passos, ou seja, todas as aes
realizadas entre os atores para desempenhar a operao de cancelar uma reserva, bem
como quais so os atores que participam desta operao.








2

AlteraReserva
Passageiro Reserva Vo
Entra com o nmero da
reserva
Conf i r ma val i dade do
nmero
I n d i c a i n t e n o d e
mudana de determindado
item da reserva
Consulta disponibilidade
Confirma alterao
Apresenta disponibilidade
Apresenta ao usurio
Atual i za quanti dade de
lugares vagos

Figura A.2 Cenrio (AlteraReserva)

Neste diagrama, a alterao de uma reserva pode ser feita com relao a vrios atributos,
mas todas as possibilidades implicam em um outro vo, logo, torna-se necessria uma
consulta com relao disponibilidade de lugares nesse vo. Representou-se aqui apenas o
caso em que esta consulta retorna a existncia de lugares disponveis. O caso em que no
existem lugares, pode ser associado com o cenrio CriaListaEspera ou InsereNaLista, ou
seja, ser efetuada a insero do passageiro na lista de espera.












3

ConfirmaReserva
Passageiro Reserva Vo
Entra com o nmero da
reserva
Conf i r ma val i dade do
nmero
Confirma pagamento
Gera o nmero do PTA

Figura A.3 Cenrio (ConfirmaReserva)


Nesse diagrama a confirmao da reserva, ou seja, o pagamento da passagem, resulta na
gerao do nmero do PTA.



AdicionaVo
Operador Reserva Vo
Entra com nmero do vo
Solicita dados
En t r a c o m n o me d a
empresa/ horario/ destino/
lugares vagos
Verifica validade do vo
Indica insero de novo
vo
Confirma validade
Confirma insero
Insere vo

Figura A.4 Cenrio (AdicionaVo)

4
Neste cenrio, especificou-se a necessidade de se verificar a validade de um vo, ou seja,
se no existe um outro vo no mesmo horrio para o mesmo destino e outras
inconsistncias possveis nesses casos.


RemoveVo
Operador Reserva Vo
Entra com nmero do vo
Ver i f i c a v al i dade do
nmero
Conifrma validade
Indica validade
Solicita remoo
Remove vo
Indica remoo
Confirma remoo


Figura A.5 Cenrio (RemoveVo)



















5
AlteraVo
Operador Reserva Vo
Entra com nmero do vo
Ver i f i c a v al i dade do
nmero
Conifrma validade
Indica validade
Solicita alterao de um
item
Altera item
Indica alterao
Confirma alterao


Figura A.6 Cenrio (AlteraVo)


AlteraPassageiro
Passageiro Reserva
Listade
Passageiros
En t r e c o m n o me d o
passageiro
B u s c a c a d a s t r o d o
passageiro
Cadastro do passageiro
Procede alterao
Confirma?
Sim
Grava alterao
Apresenta cadastro

Figura A.7 Cenrio (AlteraPassageiro)

6

CriaListaEspera

Passageiro Reserva Vo
Lista de
Espera
Determi na o desti no e
data da viagem
Consulta horrios, classe
e empresa disponveis
No h disponibilidade
Apr esent a opes de
insero na lista
Ok
Existe lista de espera?
No
Cria lista
Insere passageiro

Figura A.8 Cenrio (CriaListaEspera)


Note que o incio das aes nesse cenrio so iguais quelas do cenrio de
EfetuaReserva a diferena se d na consulta da disponibilidade de lugares, sendo que
aqui essa disponibilidade no existe.

















7

RemoveLista
Passageiro Reserva
Listade
Passageiros
Data sa lista ultrapassou.
Existem passageiros?
Sim
Sim/No
Remove lista
Apresenta opes para
outra lista/vo


Figura A.9 Cenrio (RemoveLista)


Esse cenrio representa a remoo da lista de espera. Isso ocorre sempre que a data para
qual a lista de espera foi formada ultrapassada. Nesse caso, representou-se algo que se
aproximaria mais da realidade, a nvel de implementao: a opo do passageiro ser
includo em outra lista com a data e horrios mais prximos possveis.



















8

InsereNaLista

Passageiro Reserva Vo
Lista de
Espera
Determi na o desti no e
data da viagem
Consulta horrios, classe
e empresa disponveis
No h disponibilidade
Apr esent a opes de
insero na lista
Ok
Existe lista de espera?
Sim
Insere passageiro

Figura A.10 Cenrio (InsereNaLista)


Esse cenrio assemelha-se muito ao cenrio de CriaListaEspera porm diferencia-se no
fato de que aqui a lista de espera j existe, bastando a insero do passageiro.


RemoveDaLista

Reserva
Lista de
Espera
Existe lista espera?
Sim.
I n s e r e o p r i m e i r o
passagei r o da l i st a na
reserva
Exclui passageiro da lista
de espera
Atualiza num lugares
Primeiro passageiro

Figura A.11 Cenrio (RemoveDaLista)

9
A operao RemoveDaLista acontece quando um passageiro desiste de uma reserva e o
primeiro passageiro da lista ser inserido em seu lugar, sendo necessrio para isso, que ele
seja excludo da lista de espera. Outro caso de remoo no representado aqui por se tratar
de um caso mais raro, quando um passageiro simplesmente desiste de esperar um lugar
em um vo e solicita sua remoo da lista.



TemReserva

Passageiro Reserva
Lista de
Espera
Cancelar Reserva
Verifica primeiro nome da
lista
Insere na reserva

Figura A.12 Cenrio (TemReserva)


Essa operao realizada em conjunto com a operao de RemoveDaLista, j que ocorre
quando um passageiro transferido da lista de espera para a reserva. Seria um passo
posterior remoo do passageiro da lista.














10
SNAPSHOTS / ESPECIFICAO DAS TRANSAES

InserePassageiro

Jos da Silva
InserePassageiro
Reserva 23
Vo 692
Jos da Silva
Reserva 23
Vo 692

Figura A.13 Snapshot (InserePassageiro)


Operao InserePassageiro (nome_passageiro, num_reserva)
Pr: A reserva est efetuada para o vo requerido, restando apenas a insero dos
dados do passageiro requisitante. A base de dados Lista de Passageiros tem n
passageiros cadastrados.
Ps: A base de dados Lista de Passageiros passa a ter n+1 passageiros
cadastrados e a reserva finalizada.



AdicionaVo
Vo
AdicionaVoo
Vo 691
Vo 692
Vo
Vo 693
Vo 692
Vo 691

Figura A.14 Snapshot (AdicionaVo)



11
Operao AdicionaVo (num_voo)
Pr: A base de dados possui n vos cadastrados.
Ps: A base de dados passa a Ter n+1 vos cadastrados.



CancelaReserva / RemovePassageiro

Joo da Silva
CancelaReserva
Reserva 23
Vo 692
Vo 692

Figura A.15 Snapshot (CancelaReserva)

Operao CancelaReserva (num_reserva, num_voo, nome_passageiro)
Pr: Existe um registro confirmando a existncia de uma reserva para o vo.
Ps: O registro e dados do passageiro so excludos e o vo passa a ter um lugar
disponvel a mais.


AlteraReserva

Joo da Silva
AlteraReserva
Reserva 23
Vo 692
Joo da Silva
Vo 692
Reserva 23
Vo 693
Vo 693


Figura A.16 Snapshot (AlteraReserva)

12
Operao AlteraReserva (num_reserva, num_voo, nome_passageiro)
Pr: Existe uma reserva para um determinado vo (x) em nome do passageiro e
existe disponibilidade de lugares para um outro vo requisitado(y).
Ps: A reserva passa a ser para o vo y, que passa a ter um lugar disponvel a
menos, enquanto o vo x passa a ter um lugar disponvel a mais.



ConfirmaReserva
Joo da Silva
ConfirmaReserva
Reserva 23
PTA=0
Vo 692
Joo da Silva
Reserva 23
PTA=27658
Vo 692

Figura A.17 Snapshot (ConfirmaReserva)

Operao ConfirmaReserva (num_reserva, num_voo, nome_passageiro)
Pr: Existe uma reserva efetuada e o pagamento foi efetuado.
Ps: O sistema gera o nmero do PTA como identificao do passageiro.



CriaListaEspera
Jos da Silva
CriaListaEspera
Reserva 48
Vo 693
15/08
1a. Classe
Vo 692
So Paulo
Varig
15:00
0 lugares
Jos da Silva
ListaEspera
15/08
15:00
So Paulo

Figura A.18 Snapshot (CriaListaEspera)


13
Operao CriaListaEspera (nome_passageiro, data_lista, horario_lista, destino)
Pr: No existem mais lugares disponveis em nenhum vo para o destino, a data e
o horrio desejados.
Ps: Criada uma lista de espera da qual passar a fazer parte o passageiro
requisitante.


RemoveLista
RemoveLista
Jos da Silva
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Mrio Braga

Figura A.19 Snapshot (RemoveLista)

Operao RemoveLista (data_lista, horario_lista, destino)
Pr: Existe uma lista de espera para uma determinada data e horrio passados.
Ps: A lista e os passageiros a ela associados so removidos.


InsereNaLista

InsereNaLista
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Mrio Braga
Reserva 67
15/08
15:00
Varig
So Paulo
Vo 692
So Paulo
Varig
15:00
0 lugares
Jos da Silva
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Mrio Braga
Jos da Silva

Figura A.20 Snapshot (InsereNaLista)

14
Operao InsereNaLista (nome_passageiro, data_lista, horario_lista, destino)
Pr: No existem mais lugares disponveis em nenhum vo para o destino, horrio e
data requisitados e j foi criada uma lista de espera com o mesmo destino, horrio e
data.
Ps: O passageiro requisitante passa a fazer parte da lista de espera.






RemoveDaLista


RemoveDaLista
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Mrio Braga
Reserva 67
15/08
15:00
Varig
So Paulo
Vo 692
So Paulo
Varig
15:00
0 lugares
Jos da Silva
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Reserva 67
15/08
15:00
Varig
So Paulo
Vo 692
So Paulo
Varig
15:00
0 lugares
Mrio Braga

Figura A.21 Snapshot (RemoveDaLista)


Operao RemoveDaLista (nome_passageiro, data_lista, horario_lista, destino)
Pr: Foi cancelada uma reserva para o vo desejado.
Ps: Insere o primeiro passageiro da lista de espera na reserva e remove-o da lista
de espera.









15
TemReserva

TemReserva
ListaEspera
15/08
15:00
So Paulo
Joo de Souza
Mrio Braga
Reserva 67
15/08
15:00
Varig
So Paulo
Jos da Silva
ListaEspera
15/08
15:00
So Paulo
Joo de Souza Mrio Braga
Reserva 67
15/08
15:00
Varig
So Paulo

Figura A.22 Snapshot (TemReserva)

Operao TemReserva (nome_passageiro, num_voo)
Pr: Foi cancelada uma reserva que abriu uma vaga no vo x.
Ps: O primeiro passageiro que estava na lista de espera para o destino de x, num
horrio prximo ao do vo x e na mesma data, inserido na reserva do vo e
notificado.
























16
DIAGRAMA DE INTERAO


CancelaReserva
Passageiro Reserva ListaPassageiro
CancelaReserva
RemovePassageiro
Cancela


Figura A.23 Diagrama de Interao (CancelaReserva)


ConfirmaReserva
Passageiro Reserva
ConfirmaReserva
Confirma
PTA


Figura A.24 Diagrama de Interao (ConfirmaReserva)










17
AdicionaVo

Passageiro Reserva Vo
AdicionaVo
AdicionaVo
Vo

Figura A.25 Diagrama de Interao (AdicionaVo)



CriaListaEspera

Passageiro Reserva ListaEspera
EfetuaReserva
Existe Lista?
SemVaga
no
CriaListaEspera
Ins. Passag na Lista
Insere pass. na Lista


Figura A.26 Diagrama de Interao (CriaListaEspera)








18
InsereNaLista

Passageiro Reserva ListaEspera
EfetuaReserva
Existe Lista?
SemVaga
Insere passa na Lista
sim
InsereNaLista


Figura A.27 Diagrama de Interao (InsereNaLista)




RemoveDaLista

Reserva ListaEspera
ExisteLista?
RemoveDaLista
AtualizanumLugares
Sim
InserePassagnaReserva

Figura A.28 Diagrama de Interao (RemoveDaLista)







19
TemReserva

Passageiro Reserva ListaEspera
CancelaReserva
1o. Passag. da Lista?
CancReserva
InserePassag

Figura A.29 Diagrama de Interao (TemReserva)





























20
DIAGRAMA DE ESTADOS

Passageiro
Excludo do
Sistema
Possui Reserva
Reserva
Confirmada
Na Lista de
Espera
Data Atual >
Data Reserva
C
o
n
f
i
r
m
a
R
e
s
e
r
v
a
InserePassageiro / Lugares Vagos = 0
InserePassageiro /
Lugares Vagos > 0
RemovePassageiro
RemovePassageiro
TemReserva
Passageiro no Sistema

Figura A.30 Diagrama de Estados (Passageiro)


ListaEspera
Inexistente
CriaListaEspera
Data atual >
Data da Lista
Lista Criada
Lista Alterada
T
e
m
R
e
s
e
r
v
a
InsereNaLista
R
e
m
o
v
e
D
a
L
i
s
t
a
RemoveLista
RemoveLista
Existente

Figura A.31 Diagrama de Estados (ListaEspera)




21

Vo

Inexistente Vo Cadastrado
RemoveVoo
InsereVoo
Vo Alterado
AlteraVoo
RemoveVoo
Existente


Figura A.32 Diagrama de Estados (Vo)