Vous êtes sur la page 1sur 18

A APLICAÇÃO DA LINGUAGEM DE

MODELAGEM UNIFICADA (UML) PARA O


SUPORTE AO PROJETO DE SISTEMAS
COMPUTACIONAIS DENTRO DE UM
MODELO DE REFERÊNCIA

Carlos Alberto Costa


Departamento de Engenharia Mecânica
Universidade de Caxias do Sul (UCS)
Rua Francisco Getúlio Vargas, 1130
95.070-500 – Caxias do Sul – RS
v.8, n.1, p.19-36, abr. 2001 E-mail: cacosta@ucs.tche.br

Resumo

O desenvolvimento de sistemas automatizados de informações, que apóiam as atividades de proje-


to e manufatura de produtos, deve seguir um modelo como referência para permitir uma melhor
compatibilidade e portabilidade de tais sistemas, principalmente quando inseridos num ambiente
integrado de engenharia concorrente. Este artigo demonstra como a Linguagem de Modelagem
Unificada (UML) pode ser aplicada em conjunto com o Modelo de Referência para Processamento
Distribuído Aberto (ISO/RM-ODP), para o apoio ao desenvolvimento de sistemas de informações
orientados a objetos. Enquanto o RM-ODP oferece um padrão para representação de diferentes
pontos de vistas de tais sistemas, a UML é utilizada como notação para representação de cada uma
destas vistas. Um processo baseado em Use Cases é empregado para apoiar a evolução da represen-
tação das informações dentro deste modelo de referência. O ambiente de projeto de moldes de injeção
é utilizado como exemplo para ilustração dos diagramas da UML.

Palavras-chave: modelagem de informações, RM-ODP, UML.

1. Introdução namento de informações tem permitido a


aplicação de tais ferramentas nos mais diversos

O grande avanço dos sistemas computacio-


nais nas áreas de processamento e armaze-
campos. Tal aplicação tem se destacado
sobretudo nas áreas de engenharia (projeto e
20 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

fabricação) devido à grande quantidade de independência de “vendedores” e suporte para o


informações e decisões envolvidas. Paralelamen- ciclo de vida do produto.
te a este avanço, filosofias e técnicas como Contudo, ambos, os modelos de informações
Engenharia Concorrente (CE) tem propiciado e as aplicações computacionais, não permane-
formas mais inteligentes e otimizadas de se lidar cem estáticos ao longo do tempo, estando
com as informações envolvidas no desenvolvi- suscetíveis a mudanças (evoluções) ou até
mento de novos produtos. mesmo substituições. Por esta razão, modelos
Como resultado, os sistemas computacionais conhecidos de referência devem ser adotados
para o apoio às atividades de CE têm migrado de para a criação destes elementos visando, assim,
sistemas individuais para sistemas integrados uma maior portabilidade em tais mudanças.
que passam a considerar a arquitetura geral do Este artigo demonstra como o processo de
ambiente computacional onde estão inseridos. desenvolvimento de sistemas de informações,
Como conseqüência, dois elementos são que apóiam o projeto e manufatura integrados,
considerados fundamentais no desenvolvimento pode ser modelado e conduzido através da
destes sistemas integrados de CE (Figura 1), a utilização conjunta do RM-OPD (Reference
saber (MCKAY et al., 1996; YOUNG et al., Model for Open Distributed Processing) como
1998): modelos de informações e aplicações modelo de referência e da UML (Unified
computacionais. Modelling Language) como notação padrão. É
Os modelos de informações capturam como e demonstrado como a UML pode ser utilizada
onde as informações comuns a um produto são como um padrão para a representação dos
armazenadas e como as mesmas tornam-se diferentes níveis do RM-ODP, enfocando-se nos
disponíveis para as diferentes aplicações três primeiros níveis deste modelo.
computacionais durante o ciclo de projeto e a As duas próximas seções deste artigo apre-
fabricação de tal produto. Normalmente tal sentam uma breve descrição do RM-ODP e da
elemento está relacionado com a aplicação de UML. A seção 4 traz uma representação
tecnologias relacionadas com banco de dados, o diagramática de como a UML pode ser aplicada
que exige a criação de um modelo o mais aos três primeiros níveis de representação do
consistente e íntegro possível que possa ser RM-ODP, onde a ferramenta Rational Rose® é
“entendido” pelas diferentes aplicações utilizada para o modelagem gráfica dos
computacionais. diagramas da UML. Para tanto um sistema de
Por outro lado, as aplicações computacionais informações, chamado IMSS (Injection Mould
focalizam a captura e representação da funciona- Support System) é apresentado como exemplo
lidade específica de uma determinada atividade para exposição das idéias. Por último as
de projeto ou fabricação (p.ex. Projeto para a conclusões são apresentadas.
Manufatura), além de manter uma interface com
o usuário final (projetista, por exemplo). As 2. Modelo de Referência para Processamento
aplicações computacionais são responsáveis Distribuído Aberto
também pelas mudanças (recuperação ou arma-
zenamento) dos dados nos modelos de informa-
ções e normalmente estão relacionadas com
ferramentas computacionais, tais como compu-
O RM-ODP (ISO/IEC, 1995) foi criado para
servir como modelo de referência para a
descrição de sistemas distribuídos abertos e é
tação gráfica, sistemas especialistas, sistemas aceito atualmente como um padrão de facto
baseados em conhecimento, etc. (BLAIR et al., 1996). Cinco níveis estão defini-
Esta estrutura fornece às empresas algumas dos neste modelo e devem ser seguidos para que
vantagens tais como, uma completa integridade o desenvolvimento de um sistema de informa-
nos dados, rápida flexibilidade, manutenção, ções seja compatível com este padrão (Figura 2).
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 21

Modelos de Informações

Aplicações Computacionais

Figura 1 – Estrutura de Sistemas Integrados de CE

EMPRESA

INFORMAÇÕES

COMPUTACIONAL

TECNOLÓGICO

ENGENHARIA

Figura 2 – Níveis de representação do RM-ODP

Estes níveis (ou vistas) podem ser encontra- terísticas computacionais do processo de
dos em detalhes em ISO/IEC 10746-1 (ISO/IEC, mudança de informações;
1995), contudo abaixo uma breve descrição dos IV. Nível Tecnológico (Technological View-
mesmos é fornecida: point): descreve o sistema de informa-
I. Nível de Empresa (Enterprise Viewpoint): ções em termos dos componentes que o
descreve o sistema de informações em sistema é construído, e
termos de o que o mesmo deve fazer. As V. Nível de Engenharia (Engineering View-
necessidades e especificações administra- point): descreve o sistema de informa-
tivas e técnicas que guiam e justificam o ções em termos de recursos de engenha-
projeto do sistema também são captura- ria para suportar a natureza distribuída do
das neste nível; processamento.
II. Nível de Informações (Information Apesar do RM-ODP apresentar uma descri-
Viewpoint): descreve o sistema de infor- ção essencial dos conteúdos de cada nível, que
mações em termos de estruturas de infor- deve ser considerada e assim facilitar a
mações, fluxo de informações e restrições comparação entre sistemas alternativos, aderir ao
relacionados com a manipulação das mesmo não resolverá todas as questões práticas
mesmas; envolvidas no projeto e implementação de
III. Nível Computacional (Computational sistemas de software. O RM-ODP não determina
Viewpoint): descreve o sistema de infor- como o sistema de informações deve ser
mações em termos de operações e carac- projetado e implementado, bem como não define
22 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

quais as ferramentas ou técnicas que devem ser funcionalidades dos objetos. Ao contrário, fica
utilizadas para a representação de cada nível. Tal difícil uma clara separação entre a funcionalida-
tarefa é deixada a critério do usuário. Por esta de necessária pelo sistema e as atividades dos
razão, além do RM-ODP, torna-se necessária a usuários já existentes, o que podem, ou não,
aplicação de métodos formais que possam guiar representar a forma mais efetiva do novo sistema
o projeto e implementação efetiva e consistente atender as suas necessidades funcionais. Se um
de sistemas de software através de cada um dos nível demasiado de refinamento nos detalhes de
seus níveis. um sistema é enfocado já nos seus estágios
A aplicação da tecnologia orientada a objetos iniciais de análise, corre-se o risco de enfocar
tem se destacado no desenvolvimento de aspectos gerais do sistema, e portanto, difícil de
sistemas computacionais de informações. Os identificar claramente as fronteiras e característi-
objetos podem fornecer uma representação mais cas dos objetos.
realista e compatível com o mundo externo, As evoluções do IDEF0, como IDEF1x,
onde cada objeto guarda sua identidade, estado e permitem uma melhor representação da fun-
comportamento (BOOCH, 1994). Por esta razão, cionalidade de um sistema no Nível de Empresa
tal tecnologia pode fornecer uma representação (KUSIAK et al., 1997). Entretanto, segundo
potencial para os níveis do RM-ODP. Modelos esses autores a utilização dos objetos para a
para desenvolvimento de software orientados a representação dos modelos de informações
objetos, como por exemplo modelo espiral necessita ser ainda mais pesquisada. O IDEF4 se
(WAINWRIGHT et al., 1996) e metodologias propõe a auxiliar a aplicação da tecnologia
orientadas a objetos, que exploram os aspectos orientada a objetos através de um conjunto de
comportamentais dos objetos, têm sido desen- diagramas. Contudo, este não se apresenta ainda
volvidas para apoiar a análise e projeto de como uma linguagem amplamente difundida no
sistemas de informações (MONARCHI & meio industrial. Somado a isto, as diferentes
PURH, 1992; WU, 1995). Contudo um padrão metodologias IDEF’s ainda não permitem uma
comum para a representação dos elementos, e.g. modelagem completa, integrada e que possa
objetos, que serão utilizados durante as fases de migrar entre as diferentes fases do processo de
análise e implementação de um sistema de análise, projeto e desenvolvimento de sistemas
informações não tem sido claramente definido. de informações orientado a objetos.
Métodos como diagramas de fluxo de dados e Desta forma, uma notação o mais compatível
decomposição funcional (p. ex. IDEF0) têm sido possível para guiar as fases de análise, projeto e
usados para representar a funcionalidade de um implementação de um sistema de informação,
sistema computacional, normalmente relaciona- dentro dos diferentes níveis do RM-ODP,
das com o primeiro nível do RM-ODP, i.e. Nível deveria ser adotada.
de Empresa (MOLINA et al., 1994; MCKAY
et al., 1997). Contudo, tais ferramentas não são 3. A Linguagem de Modelagem Unificada
completamente orientadas a objetos, o que pode (UML) e Use Cases
fazer suas contribuições limitadas, no que se
refere a suportar o processo de migração natural
das informações através das diferentes fases e
perspectivas do desenvolvimento de um sistema
A UML (Unified Modelling Language –
Linguagem de Modelagem Unificada)
surgiu, nos últimos anos, da união de métodos
de informações. Somado a isto, a aplicação anteriores para análise e projeto de sistemas
dessas ferramentas exige uma análise detalhada orientados a objetos e em 1997 passou a ser
das funcionalidades e necessidades do sistema já aceita e reconhecida como um padrão potencial
no seu início, o que não necessariamente fornece de notação para modelagem de múltiplas
uma maior contribuição na representação das perspectivas de sistemas de informações pela
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 23

Tabela 1. 1 – Descrição dos Diagramas da UML

Diagramas Descrição/Representação
Representação de Representa um conjunto de objetos que compartilham os mesmos atributos,
uma Classe métodos, relacionamentos e semântica.
Molde_Injeção Nome da Classe
♦ Nome Configuração_Mold : int
Número_Impressões : int
♦ Atributos Mold_ID : long
Mold_Name : char
Atributos da Classe

♦ Métodos calcule_num_ótimo_impressões()
selecione_máquina_injeção()
retorne_Mold_ID() Métodos da Classe
retorne_Comp_Plástico_ID()

Use Cases Representam um alto nível de funcionalidade de um sistema (“o que o


sistema deveria fazer”). Use Cases são extraídos de discussões entre usuários
finais, analistas, gerentes, etc., e são complementados pelas descrições de
suas ações (Cenários) e interfaces gráficas.
Elementos

♦ Use Cases <<extends>>


Criar_Novo_Produto

♦ Atores
<<extends>>
Iniciar_Projeto
♦ Relações:
(dependência, Selecionar_Produto_Existente
generalização e Projetista
associação)
<<uses>>

Projetar_pela_Função Checar_Soluções_Projeto

OMG (“Object Management Group”) (BOOCH representações diagramáticas da UML podem


et al., 1999). Entre os métodos que deram ser encontradas em (BOOCH et al., 1999;
origem a esta linguagem de modelagem visual JACOBSON et al., 1999). O ambiente de projeto
estão: Booch (BOOCH, 1994), OMT (Object de moldes de injeção foi genericamente utilizado
Modelling Technique) e OOSE (Object Oriented como exemplo para a representação de tais
Software Engineering). A UML define um diagramas.
conjunto básico de diagramas e notações que Diferente do RM-ODP, a UML oferece um
permitem representar as múltiplas perspectivas suporte direto para o projeto e implementação de
(estruturais / estáticas e comportamentais / cada perspectiva do sistema em desenvolvimento
dinâmicas) do sistema sobre análise e desenvol- e também uma notação para sua representação.
vimento. Dentre os diagramas podem ser Por esta razão, para a sua completa utilização,
citados: Diagramas de Use Cases, Diagramas de torna-se necessário um processo/metodologia que
Classes, Diagramas de Interações (Seqüência ou permita a migração e evolução das informações
Colaboração), Diagramas de Atividades e através das diferentes fases de representação, tais
Diagramas de Estado e Transição. As Tabela como funcionalidade, análise e projetos, imple-
1. 1, Tabela 1. 2 e Tabela 1. 3 descrevem mentação, etc. JACOBSON et al. (1999) fornecem
brevemente alguns destes diagramas. Informa- um processo chamado Processo de Desenvol-
ções complementares sobre outros tipos de vimento de Software Unificado (UML process).
24 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

Tabela 1. 2 – Descrição dos Diagramas da UML

Diagramas Descrição/Representação
Classes Aplicados à Representam associações entre as principais partes do sistema (Pacotes ou
representação de Categorias). As Categorias representam um grupo de objetos com funcionalidade
Categorias (ou similar e apóiam o projeto e implementação modular do sistema em desenvol-
Pacotes) vimento. Por exemplo, Funções e Soluções de Projeto são duas categorias, sendo
que a primeira é uma referência para a segunda.
Elementos
<<Categoria>> <<Categoria>>

♦ Categorias/ "Input" <<direciona>> Funções

Pacotes

♦ Relações: <<referência>>

(dependência e
associação) <<Categoria>> <<Categoria>>
Interações << checar >> Soluções de
Projeto

Classes Representam a estrutura interna (atributos e métodos) e as relações entre um


conjunto de classes. Tais relações definirão principalmente a forma em que os
objetos serão implementados. Por exemplo, Molde_Injeção e Componente_Plástico
são tipos de Produto e assim herdam os atributos e métodos de tal classe.
Elementos Produto
Nome_Produto : char
Generalização
ID_Produto : long
♦ Classes Quantidade_Produto : int
Associação
retorne_ID()
♦ Relações: retorne_Nome() Agregação
(generalização,
associação e tipo_de tipo_de

agregação)
Componente_Plástico Molde_Injeção
Placas_do_Molde
Área_Projetada : float Configuração_Mold : int
Volume : float associado com tem Comprimento : float
Número_Impressões : int
Espessura_Média : float Altura : float
1..* 1..1 2..3
calcule_num_ótimo_impressões() Espessura : float
Material_ID : int
selecione_máquina_injeção()

Seqüência (ou Capturam e representam a colaboração necessária entre classes, ou Categorias,


Interação) através de seus métodos. Basicamente, os aspectos comportamentais dos objetos
são focalizados, mostrando quais métodos são necessários para satisfazer um “Use
Case” específico. Por exemplo, o “Use Case” avalie_Soluções_Projeto mostra
como as categorias Funções e Soluções_de_Projeto colaboram para atender uma
funcionalidade específica do sistema.
Elementos Fronteira_do_ : Funções : Soluções_de_ : Interações
Sistema Projeto

♦ Classes ou 1. O Projetista 1: selecione_função ( )


Categorias seleciona uma função
específica do produto a
ser atendida; 2: avalie_Soluções_Projeto ( )

♦ Métodos 2. O conjunto de
soluções de projeto
possíveis para tal 3: avalie_Interações ( )
função é avaliado
perante suas interações
com as condições de
projeto, para checar
sua elegibilidade;
3. Para cada possível
solução de projeto suas
interações são
avaliadas.
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 25

Tabela 1. 3 – Descrição dos Diagramas da UML

Diagramas Descrição/Representação
Estado e Transição Representam o comportamento interno de uma classe durante sua vida,
mostrando como específicos eventos (métodos) podem mudar as fases da
vida de mesma. Por exemplo, após uma avaliação, uma
Solução_de_Projeto poderá tornar-se Aceita ou Rejeitada.

Elementos
^Função.avalie_Solução_Projeto ()

♦ Estados da
classe Solução_de_Projeto
rejeita[ Interações reprovadas ] / Armazena como rejeitada
Solução_de_Projeto_Rejeitada

♦ Métodos
aceita[ Interações Aprovadas ] / Armazena como aceita

Solução_de_Projeto_Aceita

Atividades Representa o conjunto de passos a serem executados por um Método,


mostrando como uma operação pode(ria) ser implementada.

Elementos Selecione Soluções

♦ Atividade/Ação; Avalie Soluções

♦ Transição; [aceita] [não aceita]

♦ Barra de
Armazena Solução Aceita Armazena Solução Rejeitada
sincronização;

♦ Decisão;
Selecione próxima Solução
♦ Marcadores de
Início e fim. [existe outra]
[senão]

TEXEL & WILLIAMS (1997) propõem um volvimento e guiarão todas as fases subseqüen-
processo baseado em Use Cases combinado com tes de análise, projeto, implementação e testes do
Booch, OMT e UML, para o desenvolvimento sistema computacional.
de sistemas orientados a objetos. Este artigo não tem como objetivo maior
Em ambos os processos, os Use Cases explorar o processo a ser aplicado para a
definem o primeiro nível de representação do modelagem das informações, visto que se trata
sistema e resultam de uma fase de captura das de um outro tópico bastante abrangente. A
“necessidades” a serem atendidas pelo mesmo. Figura 3 mostra, de forma simplificada, como tal
Os Use Cases representarão, num nível mais processo pode ser desenvolvido (TEXEL &
geral, as funcionalidades do sistema em desen- WILLIAMS, 1997).
26 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

Fase de Análise do Sistema Fase de Projeto do Sistema


UC5_IMSS_Require_PossibleSolutions_PRM

Select Design Function Design_ Interaction_ Input_CAT


Solution_CAT CAT
<<uses>>

Based on the function

Descrição e
1: Check_Interactions( )
choose, specifications,
Request Specifications requirements, decisions
made and interactions, a
set of possible Design
Solution must be provided.

concordância sobre
2: List_of_Interactions_Class ( )
Check Interactions

<<uses>>

Designer

o que o sistema
3: Select_Possible_Solutions ( )

4: Design_Solutions_Available( )

deve fazer
Select Design Solution Check Manufacturing Capabilities

Identificação dos “Use


Cases” potenciais UC2_ISMM_Stores_Information_PM
1. The values inputed are Input_CAT PM_CAT
hgdhd hjhjdh djdg checked in terms of
consistence
USE CASE X: --------- -- --
hjgfh sfsd jgfghfh Check Manufacturing Options 2. The checked values
1: Check the values ( )

Diagramas de Seqüência
are stored in the PM

jgfh gfhjgf hg fgh


fg Diagrama de “Use Cases” 2: Initial Values( )

------ ----- --- (Interações entre Classes)


Estabelecimento das USE CASE01: --------- -
"Categorias" do
Sistema Get Function Type

<<Category>>
Input_CAT
<<stores>>
<<Category>>
PM_CAT

<<Category>>
PRM_CAT <<Category>>
MM_CAT
Diagrama de Seqüência Assembly Design Solution Collection

(Interações entre
Test Design Solutions

<<calls>>
[accepted] [not accepted]
<<calls>> <<calls>>

Categorias)
<<calls>>
<<Category>>
Function_CAT
Store Accepted Design Solutions Store Rejected Design Solutions
<<calls>> Function
<<calls>>
<<references>> <<Category>>
Interaction_
CAT

<<Category>> Select next Design Solutions


Design_ <<references>>
Solution_CAT

[exist another]
<<Category>>
<<references>> Manufact_
Option_CAT [else]
<<calls>>

Display Design Solutions

Ejection_Function Cooling_Function Feeding_Function

Diagrama de Categorias Diagramas de Atividades


Diagrama de Classes
(Classes do Software)

^Design_Solutions.Select_Design_Solution()

Accepted
Design Solution

Initialize

Non-Selected Select_Design_Solution Selected


Design Solution Design Solution

Accepted

^Function.Check_Design_Solution() Rejected Rejected


Design Solution
Design Solution

Initialize

Diagramas de
Estado e Transição

Figura 3 – Processo de Identificação dos Use Cases

Com base em uma descrição detalhada do 4. A UML e o RM-ODP Apoiando o Desenvol-


sistema, principalmente enfocando as expectati- vimento de Sistemas de Informações
vas dos usuários em termos de “o que o sistema
deveria fazer”, Use Cases potenciais são 4.1 Aplicação da UML para a Representação
extraídos, bem como as Categorias do sistema. dos Níveis do RM-ODP
As Categorias (ou Pacotes) são outros tipos de
elementos da UML e representam os módulos
principais (grupo de objetos com funcionalidade
similar) do sistema em desenvolvimento. Com
A Figura 4 mostra uma representação geral
dos diagramas da UML dentro da estrutura
do RM-ODP. Este artigo está concentrado
base nestes dois elementos, uma descrição geral apenas nos três primeiros níveis do RM-ODP
de como as Categorias interagem entre si para uma vez que, nestes níveis, encontram-se os
executar cada Use Case, pode ser representada principais aspectos relativos à análise e projeto
por diagramas de Seqüência. Esta fase é definida de um sistema de informações. Use Cases e
como análise do sistema onde tais representa- Categorias aparecem como principais elementos
ções podem ser utilizadas para um melhor na representação do Nível de Empresa, guiando
esclarecimento e discussão com os usuários e os níveis subseqüentes através de objetos, que
responsáveis pela implementação do sistema. são os principais elementos dos níveis 2 e 3,
Numa fase seguinte, caracterizada com maior Informação e Computacional respectivamente.
ênfase no projeto do sistema, busca-se um No Nível de Informações são utilizados os
refinamento destas representações, a nível dos diagramas de Classes e diagramas de Estados e
objetos que farão parte do sistema. Ambos os Transição, enquanto que no Nível Computacio-
diagramas, Classes e Interações são utilizados e nal são utilizados os diagramas de Seqüência e
apoiados por representações mais detalhadas dos diagramas de Atividades.
aspectos comportamentais dos objetos, através Para facilitar a apresentação das idéias pro-
de diagramas de Estado e Transição e diagramas postas neste artigo, alguns exemplos de diagra-
de Atividades. mas UML foram desenvolvidos. Estes exemplos
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 27

Diagramas de Diagramas de Diagramas de Seqüência


“Use Case” Categorias (Categorias)

RM - ODP
Diagramas de Classes Diagramas de Estado e Transição
EMPRESA

INFORMAÇÃO

COMPUTACIONAL

ENGENHARIA

TECNOLÓGICO

Diagramas de Seqüência Diagramas de Atividades


(Classes) Selecione Soluções

Avalie Soluções

[aceita] [não aceita]

Armazena Solução Aceita Armazena Solução Rejeitada

- Funcionalidade Selecione próxima Solução

[existe outra]

[senão]

- Objetos (atributos + métodos) Mostre Soluções

- Conjunto de objetos relacionados (Pacotes ou Categorias)

Figura 4 – Notação UML aplicada aos 3 primeiros níveis do RM-ODP

são baseados em um projeto de pesquisa na área capturadas por aqueles modelos, para apoiar o
de reutilização de informações no projeto de projeto funcional de moldes de injeção (Figura
moldes de injeção, onde um modelo de 5). O Modelo Variável do Produto armazena as
informações chamado “Product Range Model” relações entre as funções do molde e suas
(Modelo Variável do Produto) foi definido soluções potenciais de projeto, e as relações
(COSTA & YOUNG, 1998). Tal projeto não entre estas soluções e suas interações de projeto,
será descrito em detalhes neste artigo, sendo chamadas simplesmente de interações. Tais
utilizado somente como um sistema exemplo interações relacionam-se com as informações
para a demonstração do uso combinado do sobre o produto molde de injeção, que estão
RM-ODP e da UML. armazenadas no Modelo do Produto.
A pesquisa relacionada com o Modelo Variá- Para a demonstração neste artigo, uma ênfase
vel do Produto segue a mesma abordagem do maior foi dada aos aspectos relacionados com
projeto de pesquisa MOSES (ELLIS et al., 1995), definição da estrutura de informações para o
desenvolvido na Universidade de Loughborough Modelo Variável do Produto, bem como para as
(UK), onde modelos de informações implemen- relações entre os seus elementos.
tados em banco de dados fornecem todas as
informações solicitadas pelas várias aplicações 4.2 Use Cases e Categorias – Nível de Empresa
computacionais utilizadas durante o processo de do RM-ODP
projeto e manufatura do produto.
Um sistema chamado IMSS (Injection Mould O Nível de Empresa do RM-ODP captura os
Support System) é usado aqui como um exemplo principais objetivos e restrições do sistema em
de sistema de informações. Este sistema inclui desenvolvimento. Desta forma, os Use Cases,
dois modelos de informações, a saber Modelo do que representam a funcionalidade do sistema
Produto e o Modelo Variável do Produto, e (“o que o sistema deveria fazer”), enquadram-se
aplicações de software que usam as informações como um importante elemento para representação
28 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

Modelo Variável do Produto Modelo do Produto

Soluções de Projeto
Modelos de
Informações
Funções Interações
Molde de Injeção

Gerenciador do
Modelo Variável do
Aplicação DFF Aplicações
Produto “Projeto para a Computacionais
Funcionalidade”

Figura 5 – Ambiente do IMSS

deste nível. Embora os Use Cases tentem adoção das representações diagramáticas de Use
capturar o que os usuários querem do sistema, Cases e Categorias do sistema fornecerão uma
eles não especificam como o sistema deveria ser. documentação compreensiva que servirá como
Isso é definido nas fases seguintes de projeto do base para discussões entre gerentes, usuários
sistema. Os Use Cases por si só não apresentam finais, programadores, etc.
muitas informações, e assim os Cenários dos A Figura 6 mostra uma representação simpli-
Use Cases complementam suas descrições. Estes ficada de alguns dos Use Cases e Categorias
Cenários são compostos por fluxos de eventos, as identificados para o caso em aplicação, i.e.
ações e reações do software, as restrições, neces- ISMM. No exemplo citado, um dos Use Cases é
sidades de interfaces gráficas, etc. Esta descrição “Avaliar_Soluções_Projeto”, que está relaciona-
dos Use Cases, através de seus Cenários, fornecem do com duas categorias principais, Funções e
informações úteis também para a especificação Soluções de Projeto, sendo que a primeira Cate-
das propriedades (atributos e métodos) das goria é utilizada como elemento de referência
classes necessárias para executar os Use Cases. para a segunda. Por exemplo, para a função do
Apesar de permitir uma comum representa- molde “extrair componente plástico”, estará
ção da funcionalidade do sistema computacional associado um possível conjunto de soluções, tais
em questão, somente com a identificação inicial como pinos de extração, placas de extração, etc.
mais clara da estrutura geral do sistema poder- A representação do relacionamento destas
se-á alcançar um melhor entendimento e Categorias com os Use Cases que farão uso das
estabelecimento das responsabilidades das mesmas é feita através dos diagramas de
equipes envolvidas no seu desenvolvimento. Seqüência. Enquanto os Diagramas de Categorias
Uma das principais transições na utilização representam as associações entre as Categorias
da notação UML está em através dos Use Cases fornecendo uma visão geral das relações entre as
representar o sistema em termos de objetos. principais estruturas do sistema, os Diagramas
TEXEL & WILLIAMS (1997) mostram este de Seqüência representam as relações particula-
processo por intermédio de uma metodologia em res entre as Categorias, para cada Use Case. Tais
que uma lista das Categorias potenciais são representações fornecem para a equipe de
extraídas. desenvolvimento, um “feedback” em termos do
A identificação das Categorias do sistema é projeto inicial do sistema. Estas representações
recomendada para uma definição clara dos guiarão os futuros estágios de análise e projetos
módulos que farão parte do mesmo. Assim, a do sistema.
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 29

Captura dos Requisitos Representação Geral da Funcionalidade e dos Módulos


do Sistema Principais do Sistema
<<Categoria>> <<Categoria>>
"Input" <<direciona>> Funções

<<referência>>

<<Categoria>> <<Categoria>>
Interações << checar >> Soluções de
Projeto
Fronteira_ : Funções : Soluções

Diagrama de Categorias do_Sistema _de_Projeto

1. O Projetista 1: UC01 -- Selecionar_Função


seleciona uma
função específica do
Discussões, acordo e descrição de produto a ser
atendida; 2: UC02 -- Avaliar_Soluções_Projeto
“o que o sistema deveria fazer” 2. O conjunto de
soluções de projeto
possíveis para tal
função é avaliado
perante suas
interações com as
condições de
<<extends>> Criar_Novo_Produto projeto, para checar USE CASE 02 - Avaliar_Soluções_Projeto
sua elegibilidade;

<<extends>>
Iniciar_Projeto

Projetista Selecionar_Produto_ Diagrama de Seqüência


Existente

<<usa>>

Projetar_pela_Função
Avaliar_Soluções_Projeto

<<usa>>

Avaliar_Interações

Diagrama de Use Cases

Figura 6 – Identificação dos Use Cases e Categorias – 1º Nível do RM-ODP

4.3 UML e a Representação dos Objetos – puro ou o uso de um banco de dados relacional
Níveis de Informação e Computacional pode resultar em diferentes considerações sobre
do RM-ODP as formas de representação e relacionamentos
dos objetos. Contudo, indiferente da plataforma
Uma vez que o Nível de Empresa tenha escolhida, o resultado final desta fase deverá ser
concordância suficiente sobre a funcionalidade e uma clara representação de cada objeto,
estrutura geral do sistema, o próximo passo é a fornecendo assim, para a equipe envolvida na
identificação dos objetos que farão parte deste programação do sistema, uma clara visão de
sistema. Assim, as propriedades e comportamen- todos os detalhes de tal objeto.
tos dos objetos são analisados e desenvolvidos, Como apontado na seção 1 deste artigo, dois
bem como as associações entre este objetos, elementos principais estão presentes no
através de suas agregações e hierarquias. Para desenvolvimento de sistemas integrados para o
apoiar o processo de definição dos objetos, os apoio às atividades de projeto e fabricação de
Cenários de cada Use Case devem ser melhor peças: os modelos de informações e as aplica-
explorados e esclarecidos. ções computacionais. Tais elementos estão
Nesta fase, onde uma estrutura mais detalhada relacionados com diferentes aspectos dos
do sistema é representada, os aspectos relativos a objetos. Enquanto as estruturas definidas para a
plataforma utilizada para implementação passam representação dos modelos de informações
a ser considerados, permitindo assim um maior estarão primariamente relacionadas com as
refinamento na definição dos atributos e informações a serem armazenadas na base
métodos dos objetos. Por exemplo, no caso de comum de dados, por exemplo os valores dos
modelagem das informações sobre produto, o atributos de cada objeto ou suas relações com
uso de um banco de dados orientado a objetos outros objetos, as aplicações computacionais,
30 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

estarão mais relacionadas com o aspecto tipos de soluções de projetos (p.ex. Resfriamento,
comportamental dos objetos, ou seja, seus Extração, etc.) que podem fazer parte de um
métodos. Tais características determinam a molde de injeção. Apesar de todas estas soluções
ênfase na representação de um objeto no serem tipos de Soluções de Projeto cada uma
segundo ou terceiro níveis do RM-ODP. possuirá atributos particulares, que justificam a
definição de diferentes tipos classes. Por
4.3.1 Objetos e o Nível de Informações do exemplo, enquanto para uma solução de
RM-ODP resfriamento o diâmetro e posicionamento dos
canais de refrigeração bem como a temperatura
O Nível de Informações do RM-ODP está do líquido refrigerante são aspectos importantes,
relacionado principalmente com o modelo de para uma solução de extração, além do posicio-
informações a ser utilizado pelo sistema namento e dimensões, o curso de extração passa
computacional. Tal nível deve capturar uma também a ser um importante atributo.
representação o mais consistente possível da Os Diagramas de Estado e Transição com-
estrutura de informações, que representará este plementam a representação interna do compor-
modelo, e que deverá ser “entendida” por outras tamento dos objetos, mostrando as diferentes
aplicações computacionais possíveis. fases de seu ciclo de vida e os eventos específi-
O EXPRESS/STEP tem sido reconhecido cos (métodos) que podem causar a transição de
como uma linguagem padrão para a representa- um estado para outro. Os estados são definidos
ção do Nível de Informações do RM-ODP como situações, durante a vida de um objeto, em
(MOLINA et al., 1994; MCKAY et al., 1997). que ele satisfaz alguma condição, executa
Contudo, com o crescente uso das técnicas alguma atividade ou aguarda algum evento. A
orientadas a objetos, e mais recentemente a transição é a relação entre dois estados de um
UML, conversões entre ambas as linguagens tem objeto indicando que, baseado em certas ações e
se tornado mais comuns (GHODOUS & satisfação de uma condição específica, o estado
VEORPE, 1998). Somado a isto, considerando de tal objeto pode mudar para um segundo
que o sistema final a ser desenvolvido usará estado. Por exemplo, na Figura 7, dependendo
métodos orientados a objetos, o uso de notações das condições/especificações durante o projeto
padrões nesta área tem se tornado significativa- de um molde, uma solução de projeto pode ser
mente vantajosos. Desta forma, os diagramas de considerada aceita ou rejeitada.
Classes da UML podem representar de forma
adequada este nível do RM-ODP. 4.3.2 Objetos e o Nível Computacional do
Os Diagramas de Classes permitem uma RM-ODP
representação da estrutura interna de cada objeto,
bem como os relacionamentos entre os objetos, O Nível Computacional do RM-ODP está
fornecendo uma consistente representação da relacionado com os processos de mudança dos
estrutura (ou esquema) do banco de dados que dados nos modelos de informações, e captura os
conterá tais informações. Embora tal diagrama aspectos dinâmicos do sistema em desenvolvi-
mostre também os métodos associados a cada mento, ou seja, a representação das operações
objeto, os mesmos não possuem significante responsáveis por tais mudanças.
importância para este nível de representação. Os Diagramas de Seqüência fornecem uma
A Figura 7 mostra o segundo nível do RM- representação de como os objetos podem
ODP, i.e. Nível de Informações, dentro do interagir, por meio de seus métodos, para
exemplo do IMSS, onde uma Categoria é realizar cada uma das funcionalidades específi-
representada em termos de Classes, com seus cas do sistema, i.e., Use Cases. Tais diagramas
atributos e relações. São mostrados diferentes representam, também, as seqüências de interação
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 31

<<Categoria>> <<Categoria>> <<Categoria>>


<<referência>> << checar >>
Funções Soluções de Interações
Projeto

Nível de Empresa

Nível de Informações
Soluções_de_Projeto
Molde_Injeção
(from Logical View) Nome_DS : char = initval
Configuração_Mold : int DS_Status : int Soluções_Padrão
Número_Impressões : int <<possui>> DS_ID : int <<possui>> Fabricante : char
Diagrama de Classe calcule_num_ótimo_impressões() 1..1 1..* checar_interações()
associar_interação()
1..1 1..* Código_Fabricante : int

selecione_máquina_injeção()
associar_Função()

Soluções_de_Resfriamento Soluções_de_Extração Soluções_de_PontoInjeção Soluções_de_Galho


Diâmetro_Canal : double Diâmetro_Pino : double
Temperatura : double Curso_Extração : double

Seção_Transversal_Galho Layouts_Galho

^Função.avalie_Solução_Projeto ( )

Solução_de_Projeto rejeita[ Interações reprovadas ] / Solução_de_Projeto_Rejeitada


Armazena como rejeitada

aceita[ Interações Aprovadas ] /


Armazena como aceita Diagrama de Estado
e Transição
Solução_de_Projeto_Aceita

Nível Computacional

Figura 7 – Diagramas da UML no 2º Nível do RM-ODP

de cada objeto, capturando os aspectos relacio- atividade resulta em alguma ação que, por sua
nados com o comportamento de cada objeto. vez, resulta em trocas no estado do sistema ou
Cada um dos Diagramas de Seqüência, que retorno de algum valor. Ações podem incluir a
inicialmente representavam as interações gerais chamada de outras operações, envio de sinais,
entre as Categorias do sistema, são refinados a criação de um objeto ou ainda alguma expressão
um nível de representação dos métodos espe- puramente computacional.
cíficos de cada objeto envolvido para implemen- A Figura 8 mostra o Nível Computacional do
tação de cada Use Case. RM-ODP, para o exemplo do IMSS, onde cada
Os Diagramas de Atividades são utilizados função principal do sistema, i.e. Use Case, é
neste nível de representação para detalhar os representado em termos de métodos e operações
passos (ou atividades), dentro de um processo específicas, necessárias entre as classes, para sua
computacional, a serem executados para a implementação. Assim, enquanto a representa-
realização de cada método, fornecendo uma ção geral do relacionamento entre as Categorias
representação de o que deve ser capturado pela Funções e Soluções de Projeto, no Nível de
implementação de tal método. Desta forma tais Empresa do RM-ODP, era através de um método
diagramas estão relacionados com a representa- “avaliar_soluções_projeto”, tal representação
ção dos aspectos dinâmicos do sistema. Cada em termos de classes, passa a ser mais detalhada,
32 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

Fronteira_do_ Funções Soluções_de_


Sistema Projeto Nível de Empresa
1: UC01: Selecionar_Função ( )

Diagrama de Seqüência
2: UC02: Avaliar_Soluções_Projeto( ) (Categorias)

Nível de Informações

Nível Computacional
: Funções : Soluções_de_Projeto : Interações : Banco_de_
Dados

1: iniciar_transação_banco_dados( )

2: selecionar_soluções_associadas (Função ID)

Diagrama de Seqüência
3: checar_soluções_selecionadas( )
(Classes)
4: UC03: avaliar_interações

5: retornar_soluções_válidas (Lista de Soluções)

6: encerrar_transação_banco_dados( )

Teste Solução

[aceita] [não aceita]

Armazena Solução Aceita Armazena Solução Rejeitada


Diagrama de Atividade
Selecione próxima Solução

[existe outra]
[senão]

Figura 8 – Diagramas da UML no 3º Nível do RM-ODP

considerando aspectos como abrindo e fechando número 3, i.e. checar_soluções_selecionadas(),


transações com o banco de dados, decidir é representado, através de diagramas de
quando e como uma solução de projeto é Atividades, onde os critérios para aceitar ou
aprovada ou não, etc. rejeitar uma solução de projeto são definidos.
No exemplo do IMSS, para checar quais
soluções de projeto são aceitas, ou não, para uma 5. Implementação do IMSS
condição de projeto específica, um conjunto de
soluções de projeto associadas com uma deter-
minada função do molde devem ser selecionadas
e para cada uma suas interações devem ser veri-
A s representações fornecidas nos Níveis de
Informações e Computacional do RM-ODP
deveriam ser suficientemente detalhadas para
ficadas. O resultado deste processo de verifica- apoiar as fases seguintes de desenvolvimento do
ção para cada solução de projeto é retornado para sistema de informações, i.e. programação do
a classe Funções. Adicionalmente, o método sistema.
GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 33

Figura 9 – Exemplo do esquema do banco de dados para o ObjectStore®

No caso do IMSS, uma implementação de tal A Figura 10 mostra alguns exemplos destas
sistema foi realizada baseado nas representações duas classes citadas acima, onde as funções
fornecidas pelos três primeiros níveis do específicas de um molde de injeção, i.e. Feed
RM-ODP. Embora o Nível de Tecnologia do Impression (alimentar cavidade), são associadas
RM-ODP não tenha sido definido dentro do com soluções de projetos particulares. Ambas as
escopo deste artigo, para efeitos de demonstra- figuras, 9 e 10, mostram o resultado da represen-
ção um banco de dados orientado a objetos tação do Nível de Informações para o exemplo
(ObjectStore®) e um ambiente de programação do IMSS, que neste caso, foi implementado
(Visual C++®) foram utilizados. Enquanto o através da tecnologia de banco de dados
ObjectStore® propiciou a captura da representa- orientado a objetos.
ção do modelo de informações persistente, o A Figura 11 mostra uma das telas do sistema
Visual C++® propiciou um bom suporte em IMSS, onde é enfocado o resultado de um
termos de visualização dos resultados. Particu- processo de pesquisa por soluções de projeto que
larmente para o caso do ObjectStore®, foi atendam a função “Distribuir os Canais de
possível a utilização dos diagramas de classes, Alimentação” (Distribute Runner Layout). Neste
na notação UML, para a geração da estrutura de caso é mostrado os conjuntos de soluções de
informações persistentes do sistema, i.e. projetos “Aceitas” (Accepted) e Rejeitadas
esquema do banco de dados. (Rejected), conforme as especificações anterio-
A Figura 9 mostra um exemplo de represen- res de projeto, que são mostradas na janela de
tação de parte do esquema do banco de dados diálogo a direita. Neste caso são demonstrados
criado para o IMSS, dentro do ambiente alguns dos resultados da representação do Nível
ObjectStore®. Neste caso são enfocadas as Computacional do RM-ODP para o IMSS,
classes Funções (Functions) e Solução de Projetos através da implementação dos métodos dos
(Design Solutions), bem como suas relações. objetos. Tais métodos permitem definir quais
34 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

...

...
Figura 10 – Exemplos dos objetos Funções e Soluções de Projetos

Figura 11 – Tela do IMSS: resultado da pesquisa por função de um molde de injeção


GESTÃO & PRODUÇÃO v.8, n.1, p.19-36, abr. 2001 35

conjuntos de soluções de projeto válidas, ou não, combinação pode servir como uma forma de
podem ser oferecidas para o usuário. Nesta comunicação entre usuários e desenvolvedores
figura é mostrado também um resultado do Nível de software, permitindo um entendimento maior
de Informações do RM-ODP, para o IMSS, para ambos. Apesar de não ter sido explorado
através dos diferentes estados das soluções de neste artigo, a aplicação de tal notação também
projetos, i.e. aceitas ou rejeitadas. permite um melhor reutilização de Classes e
Categorias que já tenham sido definidas para
6. Conclusão outras aplicações computacionais.
Apesar das vantagens oriundas de tal combi-

A aplicação de um modelo de referência, como


o RM-ODP, é considerada como um requisito
mínimo para as empresas que pretendem desenvol-
nação, algumas limitações podem ser identifica-
das em termos de fornecer uma clara interpreta-
ção do sistema para os usuários finais. Esta
ver e trabalhar com ambientes computacionais inte- interpretação pode ser melhor fornecidas com o
grados. Tal modelo permite uma maior portabili- apoio de metodologias como IDEF0, que
dade e integração dos sistemas que farão parte continuam tendo uma importância fundamental
deste ambiente compartilhado de informações. na representação da funcionalidade e atividades
Este artigo demonstrou como este modelo de de um sistema. Somado a isto, pesquisas
referência pode ser utilizado em harmonia com a adicionais são necessárias para verificar como tal
Linguagem de Modelagem Unificada (UML) metodologia, i.e. IDEF0, pode ser utilizada em
para o suporte ao desenvolvimento de sistemas conjunto com a abordagem apresentada para
de informações. Enquanto o RM-ODP oferece apoiar a descrição dos Cenários de Use Cases.
uma estrutura com cinco níveis para descrever
um sistema de informações, a notação da UML Agradecimentos
oferece uma linguagem consistente para apoiar a
representação destes diferentes níveis. Ao Governo Brasileiro (CNPq – Conselho
Foi mostrado também como a notação UML Nacional de Desenvolvimento Científico e
fornecer uma vantagem no processo de migração Tecnológico) e a Universidade de Caxias do Sul
entre os três primeiros níveis do RM-ODP, que suportaram financeiramente as atividades de
através do uso de elementos comuns, i.e. Use doutorado do Prof. Carlos Alberto Costa na
Cases, Categorias e Classes. Universidade de Loughborough (Inglaterra). Aos
Além das vantagens propiciadas no desen- revisores da Revista G&P pelas suas sugestões
volvimento de sistemas de informações, tal para melhoria do artigo.

Referências Bibliográficas

BLAIR, G.; COULSON, G. & DAVIES, N.: COSTA, C.A. & YOUNG, R.I.M.: “Product Range
“Standards e platforms for open distributed Models: linking functional design to the reuse of
processing”. Electronics & Communication manufacturing information”. Engineering Design
Engineering Journal, (June): 123-133, 1996. Conference'98 – Design Reuse, Brunel, Professional
Engineering Publishing Ltd, 1998.
BOOCH, G.: Object-oriented analysis e design with
applications. California, The Benjamin/Cummings ELLIS, T.I.A.; MOLINA, A.; YOUNG, R.I.M. &
Publishing Company, Inc., 1994. BELL, R.: “An information sharing platform for
Concurrent Engineering”. Integrated Manu-
BOOCH, G.; RUMBAUGH, J. & JACOBSON, I.:
facturing Systems Engineering, Chapman & Hall,
The Unified Modelling Language User Guide,
pp. 262-275, 1995.
Addison Wesley Longman, Inc., 1999.
36 Costa – A Aplicação da Linguagem de Modelagem Unificada (UML)

GHOUDOUS, P. & VEORPE, D.: “A systematic MONARCHI, D.E. & PURH, G.I.: “A Research
approach for product e process data modeling Typology for Object-Oriented Analysis e
based on the Step standard”. Computer-Aided Civil Design.” Communications of the ACM, 35(9):
e Infrastructure Engineering, 13: 189-205, 1998. 35 47, 1992.
ISO/IEC: “Information technology-basic reference TEXEL, P. & WILLIAMS, C.: Use Cases Combined
model of open distributed processing”. British with BOOCH/OMT/UML: process e products,
Standard Implementation of ISO/IEC 10746-1, 1995. Prentice Hall, Inc., 1997.
JACOBSON, I.; BOOCH, G. & RUMBAUGH, J.:
The Unified Software Development Process, WAINWRIGHT, C.E.R.; LEUNG, A.C.K. &
Addison Wesley Longman, Inc., 1999. LEONARD, R.: “Objetc-oriented software
development: a case study”. Computer Integrated
KUSIAK, A.; LETSCHE, T. & ZAKARIAN, A.:
Manufacturing System, 9(4):245-255, 1996.
“Data modelling with IDEF1x.” International
Journal of Computer Integrated Manufacturing, WU, B.: “Object-oriented systems analysis and
10(6): 470-486, 1997. definition of manufacturing operations”.
MCKAY, A.; BLOOR, M.S. & DE PENNINGTON, International Journal of Production Research,
A.: “A Framework for product data.” IEEE 33(4): 955-974, 1995.
Transactions on Knowledge e Data Engineering, YOUNG, R.I.M.; CANCIGLIERI-JNR, O. &
8(5): 825-837, 1996. COSTA, C.A.: “Information Interactions in Data
MCKAY, A.; BLOOR, M. S. & DE PENNINGTON, Model Driven Design for Manufacture”.
A.: “Realising the Potential of Product Data Globalization of Manufacturing in the Digital
Engineering”. 5th International Conference on Communications Era of the 21st Century:
FACTORY 2000, Cambridge, UK, IEE, 1997. Innovation, Agility, and the Virtual Enterprise.
MOLINA, A.; ELLIS, T.I.A.; YOUNG, R.I.M. & Jacucci, G.; Olling, G.J.; Preiss, K.; Wozny, M.,
BELL, R.: “Methods e Tools for Modelling Trento, Kluwer Academic Publishers. 313-324,
Manufacturing Information to Support Simultaneous 1998.
Engineering”. Intelligent Manufacturing Systems
Workshop, Viena, 1994.

THE APPLICATION OF UML TO SUPPORT COMPUTATIONAL SYSTEMS


DESIGN WITHIN A REFERENCE MODEL FRAMEWORK
Abstract
The development of information systems to support design and manufacturing activities should
follow a reference model in order to be compatible with major systems architectures. RM-ODP
(Reference Model Open Distributed Processing) provides five level viewpoints against which
information systems development can be compared and classified. The RM-ODP does not dictate how
the information system should be designed and implemented. Rather it highlights the content of the
essential views of the system, which must be considered and hence facilitates comparison of alterna-
tives systems. In contrast, computational methodologies provide ways to design and build information
systems but usually do not take reference models into consideration. This paper shows how reference
models and computational methodologies can be used in harmony, and demonstrates this through the
application of a Use Case and UML combined methodology across the RM-ODP viewpoints. Injection
mould design is used as an example to the UML representation diagrams.

Key words: information modelling, RM-ODP, UML.