21
UNIVERSIDADE FEDERAL DE OURO PRETO INSTITUTO DE CIÊNCIAS EXATAS E APLICADAS DEPARTAMENTO DE CIÊNCIAS EXATAS E APLICADAS ENGENHARIA DE SOFTWARE II UML , Diagramas estruturais Jéssica Pires – 09.1.8068, Priscila de Ávila - 09.1.8050, Rafaela Priscila - 09.1.8080, Thaise Delfino - 09.2.8115

Uml Diagramas estruturais - parte escrita

Embed Size (px)

DESCRIPTION

Conteúdo teórico sobre Diagramas estruturais.

Citation preview

Page 1: Uml   Diagramas estruturais - parte escrita

UNIVERSIDADE FEDERAL DE OURO PRETO

INSTITUTO DE CIÊNCIAS EXATAS E APLICADAS

DEPARTAMENTO DE CIÊNCIAS EXATAS E APLICADAS

ENGENHARIA DE SOFTWARE II

UML ,

Diagramas estruturais

Jéssica Pires – 09.1.8068, Priscila de Ávila - 09.1.8050, Rafaela Priscila - 09.1.8080, Thaise Delfino - 09.2.8115

Page 2: Uml   Diagramas estruturais - parte escrita

1

Sumário

Introdução ................................................................................................................................ 2

História do UML ........................................................................................................................ 3

Diagramas Estruturais ............................................................................................................... 4

Diagrama de Classes ................................................................................................................. 5

Diagrama de objetos ................................................................................................................. 8

Diagramas de Pacotes ............................................................................................................. 11

Diagrama de Estrutura Composta............................................................................................ 12

Diagrama de Componentes ..................................................................................................... 13

Diagramas de Implantação ...................................................................................................... 16

Diferenças entre os Diagramas ................................................................................................ 17

Aplicação ................................................................................................................................ 18

Conclusões .............................................................................................................................. 19

Referências Bibliográficas ....................................................................................................... 20

Page 3: Uml   Diagramas estruturais - parte escrita

2

Introdução

Modelagem nada mais é do que uma representação do software a ser feito sobre imagens e aspectos que facilite o usuário a enxergar o que deve ser feito em seu trabalho. Geralmente são feito diagramas e existem inúmeras ferramentas no mercado para ajudar a elaborar esses diagramas. A UML (Unified Modeling Language) é uma linguagem para fazer exatamente isso: modelagem de software.

A UML é uma linguagem na qual se obtém a especificação desejada, a documentação correta e uma fácil visualização do projeto para um sistema orientado a objetos. Através de seus diversos diagramas podemos obter diferentes perspectivas de visualização. Facilita na comunicação entre as pessoas envolvidas com o sistema, como gerentes, coordenadores, analistas e desenvolvedores, pois apresenta uma forma fácil de entender o problema como um todo.

Page 4: Uml   Diagramas estruturais - parte escrita

3

História do UML

No início da utilização de programas orientados à objetos, vários foram os métodos de modelagem que surgiram, porém apenas três deles se destacaram por não estender os métodos estruturados já existentes, erro cometido pelos demais. Cada método possuía pontos fontes e diferentes entre si, um deles era focado em casos de uso (OOSE de Ivar Jacobson), outro focava na fase de projeto (Booch’93 de Grady Booch) e o terceiro era voltado para análise de sistemas de informação (OMT-2 de James Rumbaugh).

Em outubro de 1994 começaram os projetos para a junção destes três métodos. Em 1995, dois deles já eram unificados (Booch’93 e o OMT-2), um tempo depois, OOSE passou a fazer parte desse conjunto, formando assim o “método unificado”.

Em julho de 1996, os três criadores do “método unificado” lançaram uma versão desse novo método com a união dos outros três já existentes. A versão foi batizada de UML e mais tarde lançaram várias outras novas versões.

A OMG3 (organização internacional que aprova padrões abertos para aplicações orientadas a objetos) contribuiu imensamente para o crescimento da UML, pois ela lançou uma solicitação de proposta para que outras empresas também pudessem contribuir com o crescimento do UML, depois disso ela chegou a sua versão 1.1 e a OMG3 passou a se responsabilizar pelas revisões e a adotou como linguagem padrão. As revisões são feitas com o cuidado de não modificar a ideia principal do projeto e isso acaba sendo um motivo para disseminar a linguagem para o mundo inteiro.

A linguagem UML chegou a sua versão 2 em 2003. Essa versão é composta por treze diagramas, esses diagramas são divididos em diagramas de comportamento e diagramas estruturais, da qual iremos tratar no restante do nosso trabalho.

Page 5: Uml   Diagramas estruturais - parte escrita

4

Diagramas Estruturais

Os diagramas estruturais são aspectos estáticos, ou seja, representação da estrutura de um sistema. Eles são classificados em diagramas de classe, objetos, de pacotes, de estrutura composta, de componentes e de implementação.

DIAGRAMAS ESTRUTURAIS

DIAGRAMA DE CLASSES

DIAGRAMA DE OBJETOS

DIAGRAMA DE PACOTES

DIAGRAMA DE ESTRUTURA COMPOSTA

DIAGRAMA DE COMPONENTES

DIAGRAMA DE IMPLEMENTAÇÃO

Page 6: Uml   Diagramas estruturais - parte escrita

5

Diagrama de Classes

O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagrama que chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos, atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer uma modelagem utilizando esses dados.

Precisamos, antes de tudo, saber o que é uma linguagem com orientação a objetos. Basicamente é abstração de conceitos do mundo real. Para compreendermos melhor, podemos citar o exemplo de uma locadora de filmes, temos que pensar em dividir esse problema em objetos. Neste exemplo temos os seguintes objetos: CD’s e Fitas, Clientes, etc. A melhor forma de conceituar é imaginar objetos do mundo real e tentar abstrair esses conceitos.

Um exemplo real:

Meu cachorro Thor. Posso descrever seus atributos físicos: é grande, sua cor principal é castanha, olhos pretos, orelhas grandes e caídas, rabo grande. Além de seus atributos físicos, posso descrever algumas ações que ele costuma fazer: balança o rabo quando chego em casa, late quando ouve um barulho estranho, trás a bola pra mim quando quer brincar. Temos baixo a representação do Thor.

Para tratar objetos, temos as classes. Então temos uma classe: Cachorro, onde eu posso representar o Thor. Podemos pensar em classe como um modelo para criar várias outros objetos. Funciona como um carimbo, temos o carimbo e com ele podemos fazer quantas cópias do mesmo modelo quisermos.

A representação gráfica de uma classe é feita em um triangulo com três divisões: nome da classe, atributos e métodos.

Temos então a representação de um objeto (Thor) que possui determinadas propriedades e métodos:

Propriedades: Cor do corpo: castanha, Cor dos olhos: preto, Altura: 30 cm Comprimento: 80 cm, Largura: 24 cm.

Métodos: Balançar o rabo, Brincar, Latir, Deitar.

Page 7: Uml   Diagramas estruturais - parte escrita

6

Atributos: Um atributo especifica características gerais para um objeto. Mas cada objeto pode receber valores diferentes em cada atributo. Então, no exemplo do cachorro Thor, temos que os atributos dele são aqueles descrito acima, mas podemos criar um outro objeto cachorro com outras propriedades, ou seja, outros atributos. Podemos representar a visibilidade dos atributos utilizando as seguintes marcações:

+ público - visível em qualquer classe

# protegido - qualquer descendente pode usar

- privado - visível somente dentro da classe

Métodos: são ações que representam um determinado objeto. Como no exemplo anterior, temos que o meu cachorro, Thor, pode latir, sentar, comer, etc.

Os objetos possuem relações entre si, uma classe pode se relacionar com outra. O UML reconhece três importantes tipos de relação: dependência, associação e generalização (ou herança). As relações são esquematizadas da seguinte forma.

Associação: São relacionamentos entre instâncias, indica que objetos de duas classes diferentes podem estar relacionados. Por exemplo, uma classe professor e uma classe disciplina, onde uma instância da classe professor terá uma associação com uma instância da classe disciplina.

Dependência: Relacionamentos em que um elemento de uma classe depende de um elemento de outra classe, logo, se houver alteração em um elemento o outro também se alterará.

Generalização: Relacionamento entre elementos generalistas e especialistas, na qual a classe especialista herda da outra propriedades e métodos gerais.

Agregação Regular: É a associação onde o objeto parte é um atributo do todo. Os objetos parte são criados apenas quando o todo ao qual está agregado também é criado. Um exemplo prático seria uma classe Pedido e uma classe Item. O pedido só pode ser feito quando os itens do pedido estão disponíveis.

Page 8: Uml   Diagramas estruturais - parte escrita

7

Composição – Relacionamento onde existe um elemento como o todo e um como a parte do todo. A parte do todo só pertence ao todo e são criadas e destruídas nele.

O diagrama de classes é consequência de um levantamento de requisitos feitos previamente. Como exemplo podemos fazer o levantamento de requisitos para um sistema de consultório dentário. As etapas são:

Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o cliente, no caso o proprietário de uma clinica, um dentista, ou mesmo funcionários que saibam dar as informações de maneira clara e especifica.

Definição dos objetos do sistema: Paciente, agenda, dentista, serviço, contrato, consulta, pagamento, etc..

Definição e detalhamento das ações: marcar consulta confirmar consulta cadastrar paciente, cadastrar serviços, etc.

Definição das classes: paciente, dentista, exame, agenda, serviço.

Definir os atributos e métodos das classes.

Após toda esta análise, podemos construir o diagrama que represente esse problema.

Neste exemplo, temos as classes paciente, Agenda, serviço, consulta, horário, limpeza/Restauração e Exame. Cada classe possui seus atributos e métodos e cada uma possui uma relação com outras classes.

Page 9: Uml   Diagramas estruturais - parte escrita

8

Diagrama de objetos

O Diagrama de Objetos é uma variação do Diagrama de Classes, e é muito pouco utilizado. Eles são usados, também, como parte dos diagramas de comunicação, onde os objetos do sistema possuem um vínculo. Nessa variação do diagrama, podem ser atribuídos nomes reais aos objetos. Os diagramas de Objetos não são tão importantes como os diagramas de classes, mas são muito úteis para simplificar diagramas de classes mais complexos e de difícil entendimento, ajudando muito em sua compreensão.

Existem apenas duas diferenças entre a notação desse diagrama com o diagrama de classes:

Os objetos são escritos com seus nomes sublinhados

Todas as instâncias num relacionamento são mostradas.

Com esse diagrama, temos o perfil do sistema em um certo momento de sua execução, tendo a possibilidade, assim, de conferir se os dados estão atribuídos corretamente e se são consistentes. Os diagramas de objetos têm seu nome sublinhado e todos os seus relacionamentos são mostrados. Seus nomes vêm separados das classes que ele representa por “:” (dois pontos). Nesse Diagrama, os atributos já podem se receber seus respectivos valores.

Por exemplo, o cachorro que se chama Thor, você pode definir um objeto “Thor” e representar ele aqui.

Por exemplo, Thor:Cachorro

Os diagramas de objetos são importantes para visualizar, especificar e documentar os modelos estruturais, assim como aspectos dentro de um sistema.

Exemplo de um diagrama:

Thor:Cachorro

Thor:Cachorro +cor: Castanho: string +peso: 37: int latir() comer() correr()

Jessica:Dona +cpf:12345678901:int +numCarteirinha:2345: int

Page 10: Uml   Diagramas estruturais - parte escrita

9

O diagrama pode ser lido da seguinte maneira: O objeto Jéssica da classe Dona está associado ao objeto Thor da classe Cachorro.

Podemos com os diagramas, projetar um jogo por exemplo. Onde o jogador está preso em uma casa de tortura e ele deve tentar sair de lá.

O jogo tem as seguintes regras (não nos preocuparemos com objetos no jogo, somente com o projeto da cena):

A casa onde o jogador está possui dois quartos espelhados;

Cada quarto reconhece quatro elementos da casa (uma porta, uma parede, ou outro quarto);

Se o jogador entra em um quarto, sua localização é alterada;

Se ele entra em uma porta e a porta estiver

o Aberta: o jogador muda de quarto;

o Fechada: o jogador se machuca;

Se o jogador se depara com a parede, se machuca.

Criando o diagrama de classes para esse jogo, temos:

A classe Quarto herda elementos da classe CasaEspelhada, e a Interface herda os elementos de Parede . Porta tem uma relação de associação com Quarto, o que quer dizer que os atributos de quarto e de porta se relacionam (Por exemplo, cada quarto possui uma porta). Vários quartos dependem da existência de uma casaEspelhada e os elementos do jogo dependem da existência de um quarto.

Podemos simplificar a visualização desse diagrama, criando o Diagrama de Objetos para esse mesmo problema:

<<interface>> ElementoDoJogo Joga()

CasaEspelhada adicionaQuarto() getQuarto(int):Quarto

Porta estaAberta:boolean QuartoUM:ElementoDeCasaEsp() Entra() QuartoEspDoOutroLado(:QuartoEsp)

Parede

Entra()

Quarto +QuartoNumero Entra() getQuartoViz() getQuartoViz()

n 1

4 elementos

1

Page 11: Uml   Diagramas estruturais - parte escrita

10

Escolhemos o cenário que desejamos representar (casos de uso);

Identificamos as classes (diagrama de classes);

Defina os relacionamentos entre os objetos (tipos de relacionamento);

O diagrama de objetos traz uma visualização muito mais sucinta do que será o projeto: A casa espelhada possui dois quartos, e esses quartos devem reconhecer paredes, portas ou outro quarto. E, por ultimo, devemos:

Definir os nomes e valores para os atributos dos objetos;

nJogo:JogosMortais

QuartoUM:Quarto + +

QuartoDOIS:Quarto + +

aPorta:Porta +

:Parede +

:Parede +

:Parede +

:Parede +

:Parede +

nArea:CasaEspelhada +

Page 12: Uml   Diagramas estruturais - parte escrita

11

Diagramas de Pacotes

O diagrama de pacotes mostra as relações entre diferentes pacotes e dependências entre suas classes.

Os pacotes e dependências são importantes para fazer testes de sistema e visam organizar o modelo de sistema UML. Com isso os desenvolvedores conseguem ver as dependências do sistema em larga escala e minimizar impactos nas modificações.

Loja

O exemplo abaixo ilustra um diagrama de pacotes de uma loja qualquer onde cada pacote é composto por um conjunto de classes. As setas representam a dependência entre os mesmos.

Clientes

Produtos

Serviços

Page 13: Uml   Diagramas estruturais - parte escrita

12

Diagrama de Estrutura Composta

O Diagrama de estrutura composta mostra a estrutura interna de uma classe, ou seja, como seus objetos estão interligados, com um objetivo comum. O diferencial desse diagrama é que ele expressa tempo de execução, padrões de uso e o relacionamento entre os objetos. Porém ele não é muito utilizado na prática, pois sua estrutura é bastante complexa.

A figura abaixo ilustra um exemplo de diagrama de estrutura composta, onde, por exemplo, um usuário que imprimir um documento através de um programa de computador e vai utilizar a impressora.

Neste outro exemplo, o objetivo é chegar a um diagnóstico do paciente, para isso precisa de uma colaboração do médico com o paciente em uma consulta.

Computador

Programa

Impressora

Médico PacienteConsulta

Diagnóstico

Page 14: Uml   Diagramas estruturais - parte escrita

13

Diagrama de Componentes

O Diagrama de componentes da UML mostra como as classes deverão se encontrar organizadas através da noção de componentes. O diagrama tem por objetivo apresentar a disposição dos componentes físicos de um sistema, como interfaces e suas relações, mostrando os elementos reutilizáveis de software e sua interdependência. Um componente pode ser um pedaço de software retulizável, bem encapsulado e facilmente substituido.

O principal objetivo deste diagrama é possibilitar a construção de artefatos para o perfil de arquitetura da solução, seja para a arquitetura técnica ou a de negócios. Um componente é formado por um conjunto de classes que se encontram nele implementadas.

O componente em si pode ser um código em linguagem de programação como um código executável já compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class é um componente do sistema. Exemplo de componente:

Um componente é mostrado em UML como um retângulo com uma elipse e dois retângulos menores do seu lado esquerdo. Na figura abaixo segue uma forma de representação mais antiga de componentes, temos o exemplo anterior e a seguinte forma:

No diagrama de componentes também é possível mostrar a configuração de um sistema de software mostrando, graficamente, a dependência entre os diversos arquivos que compõem o sistema, ou seja, um componente, assim como as classes que ele possui, dependem funcionalmente das classes de outro componente.

Graficos.dll

Cliente.java

Widget

Page 15: Uml   Diagramas estruturais - parte escrita

14

No exemplo acima, a dependência entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definição completa. Nota-se facilmente que arquivos .dll são necessários para executar a aplicação.

Em outro tipo de notação, o diagrama é composto normalmente por componentes, interfaces e portas. Os componentes são representados pelo estereótipo da uml <> . Interfaces são representadas através de uma linha com um círculo ou semicírculo ligado ao componente. Portas são representados através de retângulos saindo dos componentes.

Segundo MACORATTI, a UML reconhece cinco estereótipos de componentes:

Um executável: Um componente que pode ser executado (um programa).

Uma biblioteca: Uma biblioteca de classes ou funções, dinâmica ou estática.

Uma tabela: Uma tabela de um banco de dados.

Um documento: Uma parte da documentação (texto livre, diagramas, documentos de ajuda, etc.)

Um arquivo: Outros arquivos, geralmente, se trata de um arquivo de código fonte, mas pode ser também um arquivo de dados, um ``script'' ou outros arquivos.

Exemplo de um diagrama de componente exibindo os componentes para um sistema de locadora na web :

Gerenciador de Comunicação

Comm.dll

Graficos

Graficos.dll

Gerenciador de Banco de

dados

DB.dll

Aplicação

App.exe

Page 16: Uml   Diagramas estruturais - parte escrita

15

Neste exemplo, utiliza-se << >> para falar o que é utilizado para implementar o componente e, o nome do componente. Estas duas informações vão dentro de um retângulo. Normalmente é utilizado para:

Modelar os componentes do código-fonte, do código executável do software.

Destacar a função de cada módulo para facilitar a sua reutilização.

Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

<<HTML>> Interface

Cliente.html

<<Aplication>> GerenteDeBusca.java

<<HTML>> InterfaceEstatica

.html

<<HTML>> InterfaceDinamica

.html

<<Aplication>> MontaApplet

<<dataBase>> BancoDeVideos.mdb

<<Aplication>> Servidor.java

<<Aplication>> TransmissorAV.java

<<Applet>> Cliente.java

<<HTML>> InterfaceExibida

.html

Page 17: Uml   Diagramas estruturais - parte escrita

16

Diagramas de Implantação

Um diagrama de implantação, também chamado de digrama de utilização, modela o relacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas. Este diagrama é normalmente utilizado em projetos onde há muita interdependência entre partes de hardware e software. Cada nó deste diagrama é uma unidade física que representa um recurso computacional, como processadores, dispositivos, roteadores ou qualquer equipamento de importância para o sistema de software.

Modela o mundo físico do sistema, considerando:

o Computadores

o Dispositivos e

o Suas interconexões

Terminal 1

Terminal 2

Servidor

FAX

Impressora Matricial

Impressora Laser

Page 18: Uml   Diagramas estruturais - parte escrita

17

Diferenças entre os Diagramas

O diagrama de classes é o diagrama principal do modelo estrutural, ele é o diagrama que chega mais perto do código do programa, onde é fácil visualizar as classes, seus métodos, atributos e os relacionamentos, de acordo com a especificação do sistema podemos fazer uma modelagem utilizando esses dados.

Os diagramas de Objetos são muito parecidos com os Diagramas de Classes, e são usados, mormente, para exemplificar Diagramas de Classes mais complexos. Nos Diagramas de Objetos, seus objetos recebem nomes reais e é muito mais fácil compreender as relações entre eles.

Já os Diagramas de Pacotes, devem mostrar as relações entre pacotes e pacotes, ou seja, a relação entre um grupo de classes ou outro grupo de classes através de uma relação de dependência.

O principal objetivo do Diagrama de Estrutura Composta é mostrar a estrutura interna de uma classe, a interligação de seus objetos.

Os Diagramas de Componentes apresentam a disposição dos componentes físicos de um sistema, como interfaces e suas relações.

Os Diagramas de Implantação são utilizados, na maioria das vezes em projetos onde há muita interdependência entre partes de hardware e software. Este diagrama modela o relacionamento entre recursos de infraestrutura, de rede ou artefatos de sistemas.

Page 19: Uml   Diagramas estruturais - parte escrita

18

Aplicação

Utilização da ferramenta case StarUML.

StarUML é uma plataforma de modelagem de software que suporta UML. Com ela você pode modelar diagramas e ter uma melhor visualização dos mesmos.

Agência

+Número: int+Nome: string+Endereço: string

+abrirconta(cliente: Cliente, tipo: string): Conta+obterCliente(id; int): Cliente+autenticar(cliente: int, conta: int, senha: int): void

ContaBancária

+Titular: Cliente+Número: int+Dígito: int+Saldo: float

+deposito(valor: float): void+saque(valor: float): void

Cliente

+Código: int+CPF+Nome: string+Endereço: string

+obterConta(numero: int): void

1..n

0..n

0..n

1

Page 20: Uml   Diagramas estruturais - parte escrita

19

Conclusões

A UML é uma ferramenta adequada para poder visualizar características de comportamento de um software ou sistema, por isso é considerada uma das linguagens mais expressivas no quesito modelagem.

Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna. A ferramenta integrou muitas idéias adversas, e esta integração acelera o uso do desenvolvimento de softwares orientados a objetos. Mostra uma relação de dependência entre os diagramas que a compõe (Pacote, componente, implantação, etc.), seja de modelagem ou infraestrutura física do sistema.

Os diagramas UML permite em si que a construção de um sistema possa ser eficiente, justamente por permitir uma detalhada análise de requisitos principalmente para linguagens orientadas a objeto, além de facilitar a comunicação entre todas as pessoas envolvidas no processo. A UML é método satisfatório para construção de sistema.

Page 21: Uml   Diagramas estruturais - parte escrita

20

Referências Bibliográficas Principais: http://staruml.sourceforge.net SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florian ́polis: Visual Books, 2007.

VARGAS, Thânia Clair de Souza. A história de UML e seus diagramas .

BOOCH, G.; RUMBAUGH,J.; JACOBSON,I. UML Guia do Usuário.2.ed. Rio de Janeiro:Elsevier, 2006.

PFLEEGER, S.L.Engenharia de Software - Teoria e Prática. 2.ed. São Paulo: Prentice Hall,2004.

CRAIG, L. Utilizando UML e padrões - Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo.

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. – Rio de Janeiro : Elsevier, 2003.

PENDER, Tom. UML A Bíblia – Rio de Janeiro:Elsevier, 2004.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML Guia do Usuário. – Rio de Janeiro : Elsevier, 2006.

MARTIN, James.; ODELL, James. Análise e Projeto Orientados a Objeto. 639 p. – São Paulo: Makron Books, 1995.

Relevantes: http://www.lavailama.com.br http://pt.wikipedia.org http://www.cassao.eti.br http://irup.rsuzano.com http://www.novatec.com.br http://pt.wikipedia.org/wiki/Diagrama_de_objetos http://techblog.desenvolvedores.net/2011/05/28/diagrama-de-objeto-uml/ http://portalarquiteto.blogspot.com.br/2008/03/diagrama-de-objetos.html http://www.portalarquiteto.com.br/diagrama-de-componentes/ http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdf http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-elements.html http://www.macoratti.net/net_uml3.htm MELO, Ana Cristina. Desenvolvendo aplicações com UML. 255 p. – Rio de Janeiro: Brasport, 2002.