Guia Prático para Utilização do Ambiente Odyssey

Guia Prático
para Utilização do
Ambiente Odyssey
http://reuse.cos.ufrj.br/odyssey
Índice
1. Introdução.......................................................................................................... 4
1.1. Ferramentas de Apoio ................................................................................ 6
2. Acessando o Ambiente..................................................................................... 8
2.1. Página do Odyssey..................................................................................... 8
2.2. Versão demonstração do Odyssey ........................................................... 9
2.3. Odyssey Login .......................................................................................... 10
2.4. Definição do Mecanismo de Armazenamento........................................ 11
2.5. Engenharia de Domínio x Engenharia de Aplicação ............................. 13
3. Engenharia de domínio................................................................................... 14
3.1. Criação de um domínio ............................................................................ 15
3.2. Descrição do Domínio .............................................................................. 17
3.3. Odyssey-Search........................................................................................ 18
3.4. Trabalhando com o Domínio ................................................................... 21
3.5. Visão Geral do Domínio ........................................................................... 22
3.6. Diagramação do Odyssey ........................................................................ 23
3.7. Diagrama de Contexto.............................................................................. 24
3.8. Diagrama de Features .............................................................................. 29
3.9. Diagrama de Negócios ............................................................................. 32
3.10. Diagrama de Casos de Uso.................................................................... 34
3.11. Diagrama Estrutural................................................................................ 35
3.12. Visão de Componente ............................................................................ 36
3.12. Criação de um processo de desenvolvimento de software ................ 43
Modelagem de processo ................................................................................ 43
2
Instanciação do Processo .............................................................................. 47
Acompanhamento do Processo ..................................................................... 50
Monitoramento de Processos......................................................................... 50
4. Engenharia de Aplicação................................................................................ 52
4.1. Criando uma Aplicação ............................................................................ 52
4.2. Instanciação da aplicação........................................................................ 54
4.3. Contextos da Aplicação ........................................................................... 55
4.4. Seleção de Componentes ........................................................................ 56
4.5. Diagramadores.......................................................................................... 57
Diagrama de Contexto ................................................................................... 58
Diagrama de Casos de Uso ........................................................................... 58
Diagrama de Features.................................................................................... 59
Diagrama Estrutural ....................................................................................... 59
Diagrama de Negócios................................................................................... 59
4.6. Component View....................................................................................... 59
5. Considerações Finais ..................................................................................... 62
6. Referências ...................................................................................................... 63
3
1. Introdução
O Odyssey é um ambiente de suporte ao desenvolvimento baseado em reutilização a partir
de modelos de domínio que pode auxiliar na utilização efetiva de uma estratégia de
reutilização durante todo o processo de desenvolvimento de software, fornecendo métodos,
ferramentas e procedimentos que são adequados para a especificação de modelos e
aplicações de um domínio específico. Chamamos de domínio uma família de sistemas com
características semelhantes, pertencentes a uma mesma área de aplicação.
O principal objetivo do projeto Odyssey é prover mecanismos baseados em reutilização
para o desenvolvimento de software, servindo como um arcabouço onde modelos
conceituais, arquiteturas de software, padrões de projeto e modelos de implementação são
especificados para domínios de aplicação previamente selecionados.
Os modelos de domínio são especificados e posteriormente evoluídos segundo as atividades
de um processo de Engenharia de Domínio, denominando Odyssey-DE (Para detalhes sobre
o processo veja em [BRAGA,2000]). A partir desses modelos, aplicações específicas
podem ser desenvolvidas através de um processo de Engenharia de Aplicação, denominado
Odyssey-AE (Para detalhes veja em [MILER, 2000]). As atividades desses processos são
apoiadas por um conjunto de ferramentas, dentre elas, ferramentas para aquisição de
conhecimento, editor de diagramas UML (Unified Modelling Language), navegador e
ferramenta de documentação.
Os principais usuários são engenheiros de domínio, especialistas do domínio e engenheiros
de aplicação responsáveis pelo desenvolvimento de aplicações no domínio. Os engenheiros
de domínio e os especialistas utilizam a infraestrutura para especificar e evoluir os
conceitos do domínio. Os engenheiros de aplicação utilizam o ambiente para obter
conhecimento sobre o domínio e reutilizar este conhecimento na especificação de suas
aplicações.
O Odyssey foi desenvolvido na linguagem Java e pode utilizar GOA++, também
desenvolvido
na
COPPE/UFRJ
(Detalhes
sobre
o
projeto
encontram-se
em
4
http://www.cos.ufrj.br/~goa), como uma das possibilidades de servidor de objetos
persistentes, além de poder utilizar outros mecanismos de armazenamento como JDO,
MOR ou serialização, por exemplo.
5
1.1. Ferramentas de Apoio
FERRAMENTAS ESTRUTURAIS:
As ferramentas estruturais que fazem parte do Odyssey podem ser assim resumidas:
•
Editor de Diagramas UML (Modelagem de Domínio e de Aplicações)
•
Navegador Inteligente (Odyssey-SEARCH) ([BRAGA,2000])
•
Gerador de Aplicações
MOR:
Trata-se de um mecanismo transparente de mapeamento objeto-relacional, baseado nos
recursos de reflexão e introspecção da linguagem Java. O mecanismo torna possível o
armazenamento dos artefatos criados no Odyssey com suporte a ODBC.
ORÁCULO:
Trata-se de um sistema de críticas para verificação da consistência dos modelos construídos
pelo editor de diagramas, segundo as regras de boa-formação da linguagem UML.
Apresenta Estrutura Hierárquica, Armazenamento do conjunto de críticas, Configuração de
críticas e regras, Geração de Relatórios.
FRAMEDOC:
Trata-se de um framework para a documentação de componentes reutilizáveis através do
uso de hipermídia e padrões.
ARES:
A ferramenta ARES auxilia a recuperação de modelos de classes da UML a partir de
código Java. O modelo extraído pode ser unificado a um modelo existente e exportando
tanto para o ambiente de diagramação, como para uma base de dados em Prolog.
6
CHARON:
O desenvolvimento de software necessita de um processo que o sistematize, como também
um acompanhamento de sua execução, objetivando, entre outras coisas, fornecer
informações que permitam a tomada de decisões gerenciais, de acordo com situações
detectadas durante sua execução, e controlar o fluxo de trabalho dos engenheiros através da
automação do processo. O software responsável por automatizar a execução de processos é
conhecido como máquina de processos.
OBS: Detalhes sobre cada uma das ferramentas/mecanismos podem ser encontrados em
http://reuse.cos.ufrj.br/odyssey.
7
2. Acessando o Ambiente
Para que o usuário tenha acesso ao ambiente Odyssey, basta acessar a página do projeto e
baixar uma versão atualizada do ambiente. Os detalhes estão a seguir.
2.1. Página do Odyssey
Uma versão demo do Odyssey encontra-se disponível através do site do projeto, que se
encontra no seguinte endereço:
http://reuse.cos.ufrj.br/odyssey
Depois de conectado ao site, deve ser selecionada a distribuição “Odyssey”, indicada em
vermelho na figura 1 abaixo.
Figura 1 – Página do Projeto Odyssey
8
2.2. Versão demonstração do Odyssey
Como mencionado na página, para executar o Odyssey via Web, é necessário que o usuário
possua Java Web Start.
Caso o usuário não o tenha, este poderá ser encontrado no site:
http://java.sun.com/products/javawebstart/
Se o usuário já possui o JDK1.4 ou superior, não é necessária a instalação do Java Web
Start.
A seguir, deve ser selecionada uma versão disponível do ambiente. As versões disponíveis
ficam na página de descrição do Odyssey apresentada na figura 2.
Figura 2 – Página de Descrição do Odyssey
9
2.3. Odyssey Login
A próxima tela é a de login do Odyssey (figura 3).
Conforme mostrados abaixo, três campos devem ser preenchidos e selecionados, da
seguinte maneira:
Name: odyssey
Password: odyssey
Database: New Base
Figura 3 – Tela de Login do Odyssey
Depois de preenchidos os campos, a opção Go deve ser selecionada para a efetivação do
login.
Obs: Esta tela só aparece para algumas versões disponíveis. Caso não apareça, os campos
são automaticamente preenchidos e esta tela não é apresentada ao usuário.
10
2.4. Definição do Mecanismo de Armazenamento
Depois da efetivação do login, é mostrada a tela para definição do mecanismo de
armazenamento (figura 4a). Neste momento, é possível criar uma nova base ou
simplesmente usar uma já existente.
Para criação de uma nova base, deve ser selecionada a opção Create a new empty base e
em seguida apertar o botão Next para prosseguir com o processo. A figura 4b informa que
a base está sendo criada, juntamente com uma conta de usuário administrador, com a senha
e login padrão do sistema, sendo possível a sua troca pelo usuário. Para concluir o processo,
basta clicar no botão Finish.
Figura 4a – Mecanismo de Armazenamento
Figura 4b - Confirmação da Criação de Nova Base.
11
Para utilizar uma base já existente, deve ser selecionada a opção Open an existent base
from, selecione o banco onde se encontra a base, em seguida clique no botão Next para
prosseguir com o processo (figura 5a). Na tela seguinte (figura 5b), preencha os campos
Odyssey User Name e Odyssey User Password respectivamente com o login e a
senha do usuário no banco. Para concluir o processo, basta clicar no botão Finish.
Figura 5a – Mecanismo de Armazenamento
Figura 5b – Login e senha do usuário no banco
12
2.5. Engenharia de Domínio x Engenharia de Aplicação
A próxima tela a aparecer é a tela inicial do Odyssey (figura 6). É nesse ponto que o
usuário deverá escolher em trabalhar na Engenharia de Domínio (Odyssey-ED) ou na
Engenharia de Aplicação (Odyssey-EA).
No Odyssey, a Engenharia de Domínio (ED) enfoca o desenvolvimento de componentes
com ênfase na sua reutilização, disponibilizando a automação necessária às etapas a serem
seguidas e auxiliando o engenheiro de domínio na especificação do domínio e na criação de
componentes que possam ser utilizados em aplicações do domínio de aplicação em questão.
A Engenharia de Aplicação (EA) tem como objetivo construir aplicações em um
determinado domínio, reutilizando os componentes genéricos já existentes construídos na
ED. Aqui, o engenheiro de aplicação verificará e avaliará um domínio existente para
identificar a viabilidade de desenvolvimento da aplicação desejada, a qual deve levar em
conta as funcionalidades já disponibilizadas no domínio. Portanto, é na EA que os
componentes do domínio são efetivamente utilizados na construção de aplicações reais.
Além disso, o engenheiro de aplicação é o responsável pelo processo de adaptação dos
componentes de aplicação à arquitetura instanciada e pela adição de outros possíveis
componentes tecnológicos que possam ser necessários.
Assim, o engenheiro de domínio e o especialista têm a possibilidade de utilizar o Odyssey
principalmente para especificar e evoluir os conceitos de domínio, enquanto o engenheiro
de aplicação utiliza essa infra-estrutura para obter conhecimentos sobre o domínio da
aplicação e reutilizar este conhecimento na especificação de sua aplicação. É importante
notar que um domínio pode estar relacionado com diversas aplicações.
Nas próximas seções tratamos cada um desses contextos separadamente.
13
3. Engenharia de domínio
Esta seção é destinada à engenharia de domínio, ou seja, o usuário aqui considerado exerce
o papel de um engenheiro de domínio.
Abaixo, é mostrada a tela principal do Odyssey (figura 6), onde, a partir desta, o engenheiro
de domínio pode criar novos modelos de domínio, modificá-los, utilizar as ferramentas de
suporte do ambiente, enfim, realizar as tarefas de acordo com as suas necessidades.
Figura 6 – Tela Inicial do Odyssey
14
3.1. Criação de um domínio
Portanto, para prosseguir, o usuário precisa escolher se a atividade desejada é criar um
domínio ou criar um processo de desenvolvimento de software. Nesta primeira etapa,
seguiremos com a escolha da opção de criação de um domínio.
Para criação de um domínio, deve ser selecionada a opção file da barra de ferramentas, em
seqüência New Domain..., como apresentado na figura 7.
Figura 7 – Novo Domínio
Na tela apresentada na Figura 8, deverá ser escolhido o tipo de instanciação, que neste caso
não será instanciação de um processo, já que estamos tratando da criação de um novo
domínio. Portanto, a opção Do not instanciate a process deverá ser escolhida, como
indicado na figura 8.
Para prosseguir, o usuário deve escolher a opção Next.
15
Figura 8 – Processo de Instanciação
16
3.2. Descrição do Domínio
Depois de criado um novo domínio, visualiza-se duas caixas de texto: Name e
Description, conforme a figura 9. O campo Name corresponde ao nome do domínio, e
pode ser editado, bastando para isso clicar sobre o campo de texto. Além disso, uma
descrição do domínio pode ser inserida na caixa de texto Description.
Figura 9 – Descrição do Domínio
Em seguida aparece uma tela de questionário, para especificação de algumas características
do domínio (relacionado a Odyssey-Search), como mostram as figuras 10 e 11 .
17
3.3. Odyssey-Search
A Odyssey-Search é um sistema de múltiplos agentes que realizam o armazenamento e a
busca por informações de um dado domínio relevantes para a aplicação sendo especificada,
e a busca por informações em domínios correlatos ao domínio em questão, pelo engenheiro
de domínio. Foi dividida em quatro módulos básicos: módulo de modelagem do usuário,
agente de interface (AI), agente de filtragem de informação (AF) e agente de
armazenamento e recuperação de informação (AR). A modelagem do usuário é um
processo de criação de um perfil de usuário, baseado em seus interesses e hábitos, que
auxilia os outros agentes, e que vai sendo modificado durante a navegação. O AI é
responsável pela adaptação da interface, de acordo com o perfil do usuário. O AF é
responsável pela filtragem da informação, de acordo com as necessidades de informações
por parte do usuário, e o AR é responsável pelo armazenamento e busca das informações
nos repositórios de dados, lidando de forma transparente com questões como distribuição e
heterogeneidade dos repositórios.
Uma interação típica de um usuário com o módulo de modelagem do usuário é realizada da
seguinte maneira: primeiro, o usuário de registra como um usuário da infra-estrutura
Odyssey, figura 5b, e depois da Odyssey-Search através de um questionário (figura 10),
onde o usuário tem a possibilidade de especificar as características do domínio criado,
indicando o nível de conhecimento em relação aos termos do domínio e também categorias
do domínio que sejam de seu interesse.
Figura 10 – Questionário – Domain User
18
•
Objectives indica o objetivo que o usuário deseja alcançar com a navegação através
da Odyssey-Search. Tem como possibilidades: Domain Understanding –
conhecimento do domínio em termos de seus conceitos e funcionalidades – ou
Application Development – um detalhamento do domínio é de interesse do usuário,
já que deseja desenvolver aplicações no domínio.
•
Expertise Level indica o nível de conhecimento do usuário em relação ao domínio,
que pode ser: Low – o conhecimento é mínimo, Medium – conhecimento básico do
domínio, ou High – o usuário é especialista no domínio.
•
KeyWords são palavras-chaves utilizadas pela Odyssey-Search.
•
Em Interests pode-se também definir as subáreas do domínio, em SubAreas, com a
seleção de contextos que são de interesse do usuário.
•
Em Applications, também pode-se definir as aplicações relacionadas já
desenvolvidas no domínio ou similares à aplicação que o usuário deseja desenvolver.
Para prosseguir, basta clicar no botão Ok.
Figura 11 – Quentionário - Interests
19
Depois desta intervenção inicial, a Odyssey-Search, através de seus agentes, pode agir de
maneira autônoma. Com o questionário respondido, o agente tenta associar o novo usuário
a um estereótipo já existente. Assim, baseado no estereótipo e nas palavras-chaves, a
Odyssey-Search pode mostrar caminhos de navegação que podem ser adequados para o
usuário, utilizando as palavras-chaves especificadas pelo usuário, os contextos e aplicações
escolhidas com a descrição textual de cada item do domínio nos caminhos da navegação.
Assim, muitas vezes são mostradas opções de navegação ao usuário, que pode segui-la ou
não. Um exemplo desta sugestão é mostrado na figura 12.
Figura 12 – Sugestão explícita de navegação.
20
3.4. Trabalhando com o Domínio
Para trabalhar com o novo domínio criado, basta que o usuário clique com o botão direito
do mouse sobre o domínio com o qual deseja trabalhar e escolher a opção Model selected
element, ou dar duplo clique sobre o nome do domínio, como mostra a figura 13.
Caso o usuário deseje remover algum domínio existente, basta clicar sobre o elemento a ser
removido, e com o botão direito escolher a opção Remove selected element.
Figura 13 – Modelagem do Domínio.
21
3.5. Visão Geral do Domínio
A próxima tela a aparecer é mostrada na figura 14. À direita, são mostradas as
características e descrições do domínio, preenchidas anteriormente, mas que também
podem ser editadas.
À esquerda, aparece a árvore de objetos de modelagem semânticos instanciados, como
contexto, features, negócios, casos de uso, estrutural e de componente, sobre as quais o
engenheiro de domínio irá trabalhar.
Figura 14 – Visão Geral do Domínio
22
3.6. Diagramação do Odyssey
Para a criação de diagramas, o Odyssey apresenta editores gráficos, que têm como principal
objetivo o suporte à criação dos modelos definidos pelo Odyssey-ED/EA. A notação
utilizada é similar ao UML, com algumas construções adicionais para suporte ao
desenvolvimento de componentes reutilizáveis.
A figura 15 apresenta uma das telas de diagramação do Odyssey. À esquerda (destacado) se
localiza a árvore de objetos de modelagem semânticos instanciados. À direita é exibido o
painel de edição da categoria que atualmente está selecionada na árvore. Se o objeto
selecionado for um nó, são apresentados painéis para exibição e edição das propriedades do
nó em questão. Se o objeto for um diagrama, é apresentado o desenho dos nós e das arestas
contidos naquele diagrama. Na parte superior da janela há a barra de ferramentas do
Odyssey, que auxilia o usuário nas tarefas de modelagem, e é sensível ao contexto, ou seja,
muda dinamicamente conforme a categoria do item selecionado na árvore. Além disso, para
um maior entendimento e concisão, algumas vezes há a divisão de janelas em diferentes
abas, mostradas no canto superior esquerdo da tela, com as informações em uma só janela.
Figura 15 - Tela de diagramação
23
3.7. Diagrama de Contexto
Um diagrama de contexto situa o domínio em relação ao seu escopo, limites,
relacionamentos com outros domínios e principais atores envolvidos. O diagrama de
contexto evolui de acordo com as mudanças do domínio, sendo seu objetivo principal dar
um panorama geral do domínio no contexto da organização.
Para criar um diagrama de contexto, deve-se clicar sobre Context View, na área à esquerda
da tela, conforme figura 16. Então, aparecerão ícones na barra de ferramentas e o ícone
indicado deverá ser selecionado para abrir o diagrama de contexto, onde o usuário irá
trabalhar, tendo acesso a uma barra de ferramentas específicas para a realização das tarefas.
Figura 16 – Visão do Contexto
24
Com o Diagrama de Contexto aberto, deve ser selecionada a opção Context Diagram para
que a barra de ferramentas apareça e o usuário possa utilizá-la, como mostrado na figura17.
Figura 17 – Diagrama de Contexto.
Através da barra de ferramentas, o usuário é capaz de construir o seu diagrama de contexto,
tendo as seguintes opções:
Inserir Pacote
Inserir Contexto
Inserir Feature Externa
Inserir Feature de Entidade
Inserir Links de Comunicação e Dependências
Mostrar funcionalidades Relacionadas
Deletar e editar itens
dentre outras que podem ser encontradas na barra,
para modelagem do diagrama.
25
Ao clicar sobre um item criado no diagrama de contexto, na tela à direita aparecem as
características e descrições do item selecionado, podendo ser alteradas pelo usuário, como
nome, estereótipo e descrição (figura 18).
Para isso, basta selecionar a descrição do item a ser modificada ou colocar o cursor na caixa
de texto correspondente. Além de modificar a descrição, para o item selecionado, também
há a possibilidade de importar outros elementos e definir os elementos por ele acessados,
como é mostrado na figura 19.
Figura 18 – Descrição de um Item.
26
Figura 19 – Elementos Importados.
A tela de um diagrama de contexto é mostrada na figura 20, com alguns itens criados como
exemplo. É interessante notar que estes não só aparecem no diagrama como também na
árvore que compõe o Context View. Os itens podem ser criados na árvore diretamente,
com o botão direito do mouse, ou dentro do diagrama. Neste último caso, o item criado
aparece automaticamente na árvore, como um nó de Context View.
27
Figura 20 – Diagrama de Contexto.
Para a visualização da documentação do diagrama de contexto criado ou selecionado e dos
itens criados, deve ser selecionada a aba Document’s Visualization.
28
3.8. Diagrama de Features
O diagrama de features corresponde às características essenciais do domínio, e representa
uma forma de captura da informação do mesmo. Assim, mostra de forma padronizada todos
os elementos do domínio. É também onde são representadas todas as particularidades e
restrições dos conceitos e funcionalidades do domínio.
No diagrama de features pode-se notar a existência de duas visões: Funcional e Conceitual.
O modelo funcional mostra as similaridades e diferenças funcionais no domínio, facilitando
a busca dessas funcionalidades por parte do usuário. O modelo conceitual descreve os
principais conceitos do domínio e o relacionamento entre estes (veja detalhes em [MILER,
2000]).
Para a criação de um diagrama de features, o usuário deve seguir basicamente os mesmos
passos da criação de uma diagrama de contextos.
Conforme a figura 21, clicando sobre Feature Diagram o usuário tem acesso às barras de
ferramentas para a construção do diagrama. A descrição das opções da barra pode ser vista
deixando o mouse sobre os ícones da mesma. Assim, o usuário pode criar pacotes,
entidades externas, dentre outras funcionalidades do domínio.
Figura 21 – Diagrama de Features.
29
Caso o usuário crie os itens dentro do diagrama, estes automaticamente aparecem dentro da
árvore que compõe a feature, como mostra a figura 22.
Figura 22 – Diagrama de Features
Porém, a criação de tais itens também pode ser feita fora do diagrama, como mencionado
no diagrama de contexto, bastando clicar com o botão direito do mouse sobre a feature e
selecionar a opção desejada, como mostrado na figura 23.
Figura 23 – Features View.
30
No exemplo das figuras 22 e 23, criou-se um novo pacote e depois uma Entity Feature. Ao
clicar sobre um item criado, as respectivas opções aparecem à direita, conforme a figura 24,
dando ao usuário a possibilidade de alterar as opções padrão e escolher as mais adequadas
ao seu trabalho.
As abas superiores também apresentam opções adicionais ao usuário, onde através delas
pode-se visualizar o padrão de domínio de um componente essencial. As características
correspondentes a uma Feature selecionada são mostradas na figura 24.
É no padrão de domínio onde estão explicitados os relacionamentos entre os componentes,
implementando o conceito de rastreabilidade, ou seja, definição de como se dá o
relacionamento entre diversos modelos descritos no Odyssey (para mais detalhes ver em
[BRAGA, 2000]).
Figura 24 – Feature do Item Selecionado.
31
3.9. Diagrama de Negócios
Nos Diagramas de Negócios são modeladas as associações, multiplicidades e navegações
entre os tipos de negócio, que são usadas na geração dos componentes de negócio (veja
detalhes em [TEIXEIRA, 2003]).
O processo de criação de um diagrama de negócios é o mesmo dos anteriores. Como mostra
a figura 25, clicando sobre Business Type Diagram, a barra de ferramentas aparece para
que o usuário construa seu diagrama. Com o botão direito do mouse sobre Business View
(que pode ter seu nome alterado caso o usuário deseje) aparece a opção de criar um novo
tipo de negócios, como mostrado abaixo. As características do tipo de negócios e de seus
atributos podem ser alteradas pela seleção das abas na tela à direita.
Um novo tipo de negócios também pode ser criado dentro do diagrama, além de outros
itens. Assim, este aparece automaticamente na árvore do Business View.
Figura 25 – Tipo de Negócio.
32
A janela de edição (figura 25) de um tipo de negócio possui todos os campos necessários a
sua completa especificação. Dentre eles, podemos citar o campo plural, as dependências
de identificação única e os parâmetros de criação.
Para editarmos os atributos de um tipo de negócio, utilizamos a janela vista na figura 26,
onde definimos seu nome e tipo. Além disso, podemos definí-los como chave de negócio
ou se eles possuem parâmetros.
Figura 26 – Atributos de um tipo de negócio.
33
3.10. Diagrama de Casos de Uso
Um diagrama de casos de uso é utilizado para representar o conhecimento no domínio. Sua
representação é similar a representação deste tipo de diagramas em UML.
Dentro de Use Case View pode-se criar um novo pacote, ator, um novo caso de uso ou um
novo diagrama de caso de uso, através dos ícones na barra de ferramentas ou clicando com
o botão direito do mouse sobre Use Case View, como mostrado na figura 27.
Ao selecionar a opção de criação de um novo diagrama, a barra de tarefas é montada com
as funcionalidades específicas para este tipo de diagrama.
Figura 27 – Visão de um caso de uso.
34
3.11. Diagrama Estrutural
O diagrama estrutural, como o próprio nome já diz, fornece uma visão estrutural do
sistema, sendo representado basicamente pelos diagramas de classes, onde as classes
detalham seus atributos e métodos.
A criação de um diagrama estrutural também segue os modelos anteriores. A criação de um
pacote, de uma nova classe ou um diagrama de classes pode ser feita clicando com o botão
direito do mouse sobre o nome da Structural View, ou pelos ícones na barra de
ferramentas, como mostra a figura 28.
A construção do diagrama é feita como nos diagramas anteriores, ou seja, clicando sobre
Structural View, a barra de ferramentas com os itens disponíveis aparece para que o
usuário construa o diagrama.
Figura 28 – Visão Estrutural.
35
3.12. Visão de Componente
A visão de componentes é o local onde os componentes de software são especificados e
desenvolvidos para montar a arquitetura do software. Um componente existe sob duas
formas distintas:
•
Em forma de Especificação: As especificações de componentes, descritas
independentes de tecnologia, representam um conjunto de modelos, documentos e
diagramas que explicam como os serviços do componente devem ser atendidos na
arquitetura.
•
Em forma de Implementação: As implementações de componentes são as possíveis
realizações para as especificações de componentes, oferecidas em termos de
algoritmos e elementos de tecnologias.
Todas as informações que entram ou saem de um componente devem passar pelas suas
interfaces, as quais são formadas por um conjunto de operações seguidas de suas
assinaturas (parâmetros de entrada e o seu retorno).
Uma arquitetura de componentes pode ser divida em camadas com diferentes níveis de
abstração. A camada mais alta consiste de componentes específicos de negócio que
realizam as regras de negócio do domínio. Na camada intermediária encontram-se
componentes utilitários que prestam serviços genéricos necessários ao desenvolvimento das
aplicações. A última camada inclui os componentes de infra-estrutura que se comunicam
com as plataformas de execução do software (ex: sistema operacional, drivers ou
dispositivos de hardware).
No ambiente Odyssey, é possível gerar os componentes de negócio do software (camada
mais superior da arquitetura) utilizando um mecanismo pré-programado que auxilia o
arquiteto do software a organizar a distribuição dos serviços e informações pela arquitetura.
Esta geração é, na verdade, uma forma de facilitar a criação das especificações de
componente para os requisitos modelados pelo usuário na ferramenta. Para tanto, dois
estilos arquiteturais específicos para o desenvolvimento de componentes de negócio são
36
permitidos para esta geração: o estilo baseado em tipos (typebased) e o estilo baseado em
instâncias (instance-based). Tais estilos necessitam que a Visão de Negócio esteja
corretamente montada, com suas devidas associações, atributos, multiplicidades e
relacionamentos. Além disso, os casos de uso também precisam estar detalhados passo a
passo, utilizando as ações de negócio que informam quando uma informação é criada,
alterada, removida ou trocada com o usuário.
Estilo Baseado em Tipos
Geração dos componentes gerentes de instâncias
A geração dos componentes é iniciada com o agrupamento dos tipos de negócio presentes
na visão de negócio. Acessando esta funcionalidade através do menu Tools
Architecture
►
Styles
►
Type-based
►
►
Component
Generate Type Managers, uma janela de agrupamento é
aberta (figura 28). Do lado esquerdo, aparece uma árvore com os grupos pré-formados
pelas regras, onde são indicados os candidatos recomendados ( ) e os candidatos
sugeridos ( ) de cada grupo. Ao clicarmos em um dos grupos na árvore, seus detalhes são
apresentados do lado direito da janela. Como as regras de agrupamento são sugestões para
o projetista, checkboxes são utilizadas para a seleção dos candidatos desejados. Quando a
checkbox é marcada, o candidato passa a fazer parte do grupo que está selecionado, e todos
os candidatos que, antes, faziam parte do grupo do candidato, são trazidos, agora, para o
grupo em que ele foi inserido (como candidato também, podendo ou não ser selecionado).
Considerações:
1. O especialista pode mudar de idéia com relação aos agrupamentos selecionados,
assim, se ele retroceder e desfazer qualquer agrupamento, a janela devolve os
candidatos inicialmente selecionados e os reagrupa.
2. Um candidato só pode estar em um grupo por vez.
37
(a)
Cliente e Hospede
permanecem juntos pela
aplicação da regra da herança.
Quarto é um candidato forte
(recomendado) para fazer
parte do grupo do hotel.
Tipo de Quarto é um
candidato fraco para fazer
parte do grupo do hotel.
(b)
Ao escolhermos o Quarto
como integrante do grupo do
hotel, o Tipo de Quarto passa a
fazer parte dos candidatos
(fracos) a entrarem neste grupo
também.
Figura 29 - Janela de agrupamento.
Após o agrupamento, uma janela de preferências é aberta, para que o arquiteto escolha
algumas opções sobre a arquitetura, como mostrado na figura 29.
Escolha do tipo de dado da chave
técnica da arquitetura. Pode ser
números inteiros ou string.
Tratamento de Remoções: opção
para criar as interfaces dos
componentes que emitem e
escutam os eventos de remoção.
Tratamento de Remoções: opção para
conectar (utilizando as interfaces criadas) os
componentes que emitem com aqueles que
precisam escutar os eventos de remoção.
Figura 30 - Janela de opções sobre a arquitetura.
38
Clicando no botão Next da figura 29, a janela de conclusão da geração de componentes é
mostrada (figura 30), em que se define o nome dos pacotes onde os componentes e
interfaces serão inseridos. Além disso, é mostrado um relatório com as características da
geração, visando documentar o conteúdo destes pacotes, podendo este ser editado pelo
arquiteto.
Tipo da chave
técnica.
Tratamento de
remoções.
Navegabilidades
usadas na geração.
Figura 31 - Informações sobre os pacotes onde os componentes e as interfaces serão
inseridos
Após concluir o procedimento, clicando no botão Finish da figura 30, os componentes e as
interfaces são gerados, podendo ser vistos em Componente View
►Components
ou em
Componente View ► Interfaces, mostrados na tela de diagramação, como na figura 32
39
Figura 32 - Componentes e interfaces gerados.
Geração dos Componentes de Processo
A geração dos componentes de processo utiliza a especificação dos casos de uso como um
guia para acessar os componentes gerentes de instância criados. Clicando sobre um
componente, a aba Software Component é mostrada, com as características do
componente. Em seguida, é necessário definir quais casos de uso um componente realiza,
associando-os na aba Use Case Realization, através dos botões Add, Add All, Remove e
Remove All, conforme apresentado na figura 32.
A geração é iniciada pelo menu Tools
►
Component Architecture
►
Styles
►
Type-based
►
Generate Interactions From Use Case Realization, onde um wizard é aberto. Inicialmente, o
arquiteto precisa escolher qual componente será especificado pelo algoritmo. Após a
escolha do componente de processo desejado, devem-se selecionar quais dos casos de uso
associados a ele o usuário está interessado em gerar (figura 33a).
O passo seguinte é escolher as interfaces que o algoritmo precisa utilizar (as que possuem
métodos para a manipulação das instâncias dos tipos de negócio) (figura 33b). O arquiteto
40
pode escolher quantas interfaces quiser, influenciando apenas o tempo que o algoritmo leva
para gerar as seqüências.
Figura 33: Passos para a geração de um componente de processo.
Ao concluir a geração, o resultado obtido pode ser visto na figura 34, onde o diagrama de
interação é gerado dentro do componente de processo. Caso algum erro ocorra durante a
geração, este é informado para que o projetista procure uma solução para o problema.
41
Figura 34: Diagrama gerado para o caso de uso “Fazer Reserva”.
Estilo baseado em Instâncias
Aqui, a geração de componentes de negócio consiste em criar, para cada tipo de negócio,
um componente de entidade e um componente-coleção na arquitetura.
Para realizar essa geração, o arquiteto deve acessar o menu Tools ► Component Architecture
►
Styles
►
Instance-based
►
Generate Instance Managers e a única informação que deverá ser
fornecida é o nome e a descrição dos pacotes onde os componentes serão inseridos.
A figura correspondente é a figura 31, só que neste caso, o relatório é montado com os
detalhes do estilo baseado em instâncias.
42
3.12. Criação de um processo de desenvolvimento de software
Nesta parte, trataremos da criação de um processo de desenvolvimento de software no
Odyssey.
O desenvolvimento de software necessita de um processo que o sistematize, como também
um acompanhamento de sua execução, objetivando, entre outras coisas, fornecer
informações que permitam a tomada de decisões gerenciais, de acordo com situações
detectadas durante sua execução, e controlar o fluxo de trabalho dos engenheiros através da
automação do processo. O software responsável por automatizar a execução de processos é
conhecido como máquina de processos.
Modelagem de processo
Inicialmente, o processo deverá ser modelado. Isso é feito através da escolha Preferences
– Environment na janela principal do Odyssey, como na figura 35.
Figura 35: Passos para modelagem do processo.
43
Com esses passos, a tela da figura 36 será mostrada.
Figura 36: Ambiente Odyssey.
Para modelagem do processo, deve-se clicar em Process View, e com o botão direito do
mouse ou pela barra de ferramentas que aparece para este caso, o usuário tem a opção de
criar um novo processo, novas ferramentas, artefatos ou regras para acompanhamento do
processo, como mostra a figura 37.
Figura 37 – Modelagem do Processo.
44
O processo modelado deve descrever cada uma das atividades do ciclo de vida, que
também devem ser modeladas. Um exemplo está mostrado na figura 38.
Figura 38 – Modelagem do processo raiz.
Obs: O símbolo
indica que determinadas atividades são compostas, contendo um
outro fluxo de atividades que descreve as suas sub-atividades.
Além de modelar o processo principal, é necessário modelar seus sub-processos. Na
máquina de processos, a modelagem permite a separação dos processos de software em
primitivos e compostos, onde os processos primitivos são descritos através de roteiros,
papéis, ferramentas e artefatos consumidos e produzidos, e os processos compostos são
descritos através de um fluxo de atividades de sub-processos.
45
Para a modelagem dos sub-processos, deve-se clicar sobre o sub-processo da árvore que
será modelado. Em Type, pode ser escolhida a opção Primitive ou Composite, para a
modelagem do sub-processo primitivo ou composto, respectivamente.
O processo primitivo, como mostra a figura 39, é descrito através de seu tempo médio de
execução, em Average Execution Time; um roteiro, em Script, que descreve o que deve
ser feito para que o processo seja executado; uma lista de papéis, em Authorized Roles,
que indica quais tipos de desenvolvedor são autorizados a executar esse processo; listas de
artefatos consumidos e produzidos, que indicam o que deve ser utilizado para que o roteiro
seja cumprido; e a lista de ferramentas, que indica quais ferramentas devem ser utilizadas
para que os artefatos consumidos e produzidos possam ser manipulados.
Figura 39 – Modelagem de um sub-processo primitivo.
Após a modelagem de todos os sub-processos necessários para execução do processo
principal, é possível iniciar sua instanciação.
46
Instanciação do Processo
A instanciação do processo, que ocorre no momento da criação do domínio ou da aplicação,
consiste inicialmente da instanciação do processo raiz, como mostra a figura 40.
Figura 40 – Processo de Instanciação.
Após a seleção do processo raiz, ocorre o mapeamento do processo e a seleção dos papéis
pendentes, para que seja possível informar à máquina de processos quais desenvolvedores
estão autorizados a atuar em quais processos, exercendo quais papéis, como mostra a figura
41.
47
Figura 41 – Instanciação do Processo.
Em Existing Roles, é selecionado o papel desejado (por exemplo gerente, projetista...), e
em Existing Users, os usuários para o papel selecionado são escolhidos. Para isso, deve-se
clicar sobre o nome do usuário e através do botão Add, adicioná-lo a Selected Users.
Após a instanciação, o processo será simulado para verificar se existem erros de
modelagem, que inviabilizem a sua execução. Caso não seja encontrado erro, o processo
poderá entrar em execução. Para prosseguir, basta clicar em OK, como mostra a figura 42.
Figura 42 – Resultado da simulação.
48
Caso a simulação ocorra por mais do que 5 segundos, o Agente de Simulação notifica ao
usuário que pode estar ocorrendo uma repetição infinita, como mostra a figura 43.
Figura 43 – Notificação do Agente de Simulação.
O usuário então pode optar por continuar a simulação por mais 5 segundos, ou cancelá-la,
para corrigir ou reestruturar o processo.
O usuário tem ainda as seguintes opções relacionadas aos processos:
•
monitoramento: acompanhamento ou acesso ao ambiente do monitoramento do
processo para uma visão geral;
•
retrocesso: quando é necessário retroceder a execução do processo quando seu término
ou tomada de decisão não ocorrerem em momento oportuno;
•
reinstanciação: utilizada para melhoria do processo que foi modelado caso seja
detectada uma falha e que seja interessante melhorar dentro do projeto que está em
execução.
Para a escolha destas opções, clicar em Tools, em seguida em Process Wizard e escolher
a opção desejada, como mostra a figura 44.
49
Figura 44 – Menu para processos.
Acompanhamento do Processo
O acompanhamento do processo é útil para indicar as tarefas pendentes e decisões que
devem ser tomadas. Quando o desenvolvedor entra pela primeira vez no ambiente de
desenvolvimento, este é informado quais atividades estão pendentes para ele.
Monitoramento de Processos
O ambiente de monitoramento é utilizado para se obter uma visão global do processo em
execução. Para selecionar esta opção, deve-se selecionar a aba mostrada na figura 46,
abaixo da árvore à esquerda. Através da diferenciação de cores, são mostrados quais
processos executaram dentro do tempo previsto (mostrados em verde), os que ainda estão
50
em execução (mostrados em amarelo) e os que tiveram o tempo de execução pior que o
previsto (mostrados em vermelho), como aparece na figura 45.
Figura 45 – Monitoramento do Processo.
51
4. Engenharia de Aplicação
Esta seção é destinada à engenharia de aplicação, ou seja, o usuário aqui considerado
exerce o papel de um engenheiro de aplicação.
Como já mencionado anteriormente, o processo de Engenharia de Aplicação (EA) atua de
forma paralela ao de Engenharia de Domínio (ED).
Assim, a EA se dedica ao estudo das melhores técnicas, processos e métodos para a
produção de aplicações, no contexto do desenvolvimento baseado em reutilização,
utilizando os componentes do domínio previamente criados.
4.1. Criando uma Aplicação
A criação de uma nova aplicação na infra-estrutura do Odyssey começa pela seleção de um
domínio onde a aplicação será criada. Para escolher o domínio de trabalho basta clicar
sobre o mesmo, para que seja selecionado, e então, com o botão direito, escolher a opção
Create new application, como mostra a figura 46.
Figura 46 – Criação de uma nova aplicação.
52
Depois de escolhida esta opção, a tela de instanciação do processo aparece (figura 47), e a
opção Do not instantiate a process deve ser selecionada, no caso onde os usuário não
deseje instanciar um processo raiz. Para prosseguir, o usuário deve clicar no botão Next.
Figura 47 – Instanciação do Processo.
53
4.2. Instanciação da aplicação
A próxima tela para instanciação da aplicação é mostrada (figura 48). Como a aplicação
será feita com base no domínio escolhido, a opção Instantiates new application based
on domain model deverá ser selecionada e o botão Next, para prosseguir com o processo.
Figura 48 – Tipo de Instanciação.
A próxima tela mostrada (figura 49) é a tela para escolha e definição das características da
aplicação, como nome, estereótipo e descrição da aplicação. Depois de devidamente
preenchidos os campos, o botão Next deve ser escolhido para continuação.
Figura 49 – Descrição da aplicação.
54
4.3. Contextos da Aplicação
O próximo passo agora, é a escolha de contextos e componentes da aplicação por parte do
engenheiro de aplicação.
A figura 50 mostra a escolha dos contextos da aplicação, do lado esquerdo da janela, são
escolhidos os contextos nos quais a aplicação a ser desenvolvida se encaixa. Isto é feito
através dos botões Add, Add All, Remove e Remove All que incluem ou retiram
contextos do Domínio (campo do lado esquerdo) na Aplicação (lado direito).
A escolha destes contextos pré-seleciona, automaticamente, os componentes que serão
sugeridos ao especialista. Ou seja, o ambiente só mostrará os componentes relativos aos
contextos escolhidos, o que dependerá das ligações realizadas anteriormente nos contextos,
features, etc.
Figura 50 – Contextos para a Aplicação.
Em seguida, o botão Next deverá ser acionado e a tela da figura 52 é apresentada.
55
4.4. Seleção de Componentes
Na tela da figura 51, é onde são mostrados os componentes já com o corte inicial
proporcionado pela definição do escopo feita na tarefa anterior (seleção de contextos).
São mostrados os diferentes tipos de features, com sua natureza opcional ou mandatória,
seus relacionamentos e restrições. A seleção é executada através do botão direito do mouse
ou através do botão Add, mostrado na tela à esquerda. Para remoção de algum componente,
o botão Remove também da tela à esquerda deverá ser usado.
Na escolha de cada feature, o engenheiro recebe mensagens mostrando os diferentes
componentes relacionados.
Figura 51 – Seleção dos Componentes.
Para terminar o processo, deve ser selecionado o botão Finish. Terminado o processo,
ocorre automaticamente uma verificação do processo de escolha dos componentes da
aplicação. Os relacionamentos fora do contexto da aplicação são informados, cabendo ao
engenheiro da aplicação avaliar a relevância das informações relatadas.
56
Na versão atual do ambiente, após este processo, os componentes do domínio são copiados
para o contexto da aplicação, comportando-se a partir de agora como componentes distintos
dos do módulo de domínio, ou seja, qualquer alteração realizada, não se refletirá no modelo
de domínio.
4.5. Diagramadores
Na engenharia de aplicação, os diagramas presentes na tela de diagramação são
basicamente os mesmos que os descritos na seção 3, ou seja, as funcionalidades de cada um
são mantidas. Porém, para a engenharia de aplicação, os diagramas são uma forma de
extração de dados, conceitos, funcionalidades e características dos componentes dos
domínios que serão necessários à aplicação. Enfim, são utilizados como forma de
exploração do domínio.
É aqui também que se dá a adaptação dos componentes escolhidos na fase de instanciação
da aplicação e a especificação de novos componentes.
Para ter acesso aos diagramadores da aplicação, depois de sua instanciação, basta dar um
duplo clique sobre o nome da aplicação desejada e a figura 52 é mostrada.
Como a definição mais completa dos diagramas já foi realizada na sessão referente ao
domínio, aqui explicaremos suas funcionalidades no contexto da aplicação, mas sem
mostrar novamente as telas de diagramação, que são as mesmas já exibidas anteriormente.
57
Figura 52 – Exemplo de uma Feature.
Diagrama de Contexto
O diagrama de contexto auxilia o engenheiro de domínio na definição do escopo da
aplicação, ou seja, em sua fase de análise da aplicação, porém este não aparece na tela de
diagramação, por já ter sido explorado na etapa de instanciação da aplicação (seção 4.2). É
através do diagrama de contexto do domínio disponível para reutilização que o engenheiro
de aplicação definirá qual escopo a aplicação a ser desenvolvida contemplará.
Diagrama de Casos de Uso
O diagrama de casos de uso é utilizado no contexto da engenharia de aplicação para
capturar o conhecimento sobre o domínio para o desenvolvimento de sua aplicação. É
também a partir da definição dos casos de uso do domínio que os componentes de cada
função de uma aplicação são descritos.
58
Diagrama de Features
O modelo de features contém as características essenciais do domínio, representando de
forma padronizada seus componentes. Através deste diagrama serão selecionados os
componentes da aplicação segundo suas funcionalidades presentes na visão funcional do
diagrama.
Diagrama Estrutural
Este diagrama representa a visão estrutural dos componentes do domínio, ou seja, é
basicamente composto pelo diagrama de classes e objetos dos seus componentes; e pode
ajudar ao engenheiro verificar a escolha adequada do componente.
Diagrama de Negócios
Os diagramas de negócios têm seu foco principal na Engenharia de Aplicação, e como dito
anteriormente, descrevem como o software que será construído deve tratar os conceitos
(entidades), seus atributos e relacionamentos, descrevendo conceitos que são instanciados
pela aplicação.
4.6. Component View
Para apoiarmos a decisão do arquiteto durante a escolha dos estilos e tecnologias que
podem ser empregadas no desenvolvimento das aplicações precisamos cadastrar todas as
tecnologias de componente em que estamos interessados, utilizando a janela vista na figura
53 (menu Tools
►
Component Architecture
►
Technology
►
Add/Remove Component
Technologies).
59
Figura 53 – Janela de cadastro de tecnologias de componente.
O próximo passo consiste em avaliar as tecnologias disponíveis na geração de
componentes. Esta avaliação é feita na janela da figura 54 (menu Tools
Architecture
►
►
Component
NonFunctional Requirements & Technology Evaluation Support), onde os
atributos devem ser conceituados separadamente. Para saber qual o estilo e a tecnologia
mais indicados para uma aplicação em particular, o arquiteto precisa expor seus desejos
para cada um dos onze atributos de qualidade utilizados. Isto é feito indicando-os como
Importante, Desejável ou Irrelevante para o software (figura 55).
Figura 54 – Janela de avaliação das tecnologias nos estilos arquiteturais.
60
Figura 55 – Atributos de qualidade desejados para o software.
Clicando no botão Finish da figura 55, é apresentado então na figura 56 os resultados
obtidos segundo as opções escolhidas anteriormente. Para cada linha retornada, temos um
valor que indica a distância vetorial da tecnologia e do estilo até o objetivo pretendido.
Assim, o arquiteto pode decidir sobre o melhor caminho a ser seguido no desenvolvimento.
Figura 56: Resultados obtidos para os desejos do arquiteto.
61
5. Considerações Finais
Este manual tem como objetivo apresentar uma breve descrição operacional para aqueles
que querem utilizar o protótipo do Odyssey. O objetivo principal aqui é apresentar os
passos necessários para criação de domínios e também de aplicações dentro de domínios
previamente criados. Dessa forma, o manual foi dividido em duas etapas: uma para os
usuários interessados em trabalhar na engenharia de domínio, e outra para os usuários que
desejam trabalhar na engenharia de aplicação.
O Odyssey está em constante evolução. Notícias sobre as pesquisas em desenvolvimento
podem ser obtidas através do site do projeto (http://reuse.cos.ufrj.br/odyssey).
62
6. Referências
BRAGA, Regina; "Busca e Recuperação de Componentes em Ambientes de Reutilização
de Software", Tese de Doutorado – COPPE/Sistemas, Dezembro 2000.
MILER, Nelson; “A Engenharia de Aplicações no Contexto da Reutilização baseada em
Modelos de Domínio” , Tese de Mestrado - COPPE/Sistemas, Julho 2000.
MURTA, L. G. P., “Charon: Uma Máquina de Processos Extensível Baseada em Agentes
Inteligentes”, Tese de Mestrado - COPPE/Sistemas, Março 2002.
TEIXEIRA, H. V., “Geração de Componentes de Negócio a partir de Modelos de Análise”,
Tese de Mestrado – COPPE/Sistemas, Março 2003.
63