Unidade IV. Compreende uma conexão bidirecional entre classes que indica a existência de um relacionamento entre os objetos dessas classes.

25/08/09

Unidade IV

É a maneira como as classes de objetos interagem entre si para formar o comportamento do sistema. Esse relacionamento é apresentado pelo diagrama de classes. Os dois principais tipos de relacionamento são associação e agregação.

6.1 Associação

• Compreende uma conexão bidirecional entre classes que indica a existência de um relacionamento entre os objetos dessas classes.

• Nos diagramas de classe, é representada por uma linha conectando as classes associadas.

• O fl uxo de dados pode ser unidirecional ou bidirecional por meio da conexão.

• Para esclarecer o signifi cado de uma associação, ela é nomeada. No diagrama de classes, o nome é apresentado ao longo da linha de associação. Usualmente, esse nome é um verbo ou uma frase verbalizada.

• Entre duas classes pode existir mais de uma associação. 6.2 Multiplicidade de associação

É o número de instâncias de uma classe relacionada com uma instância de outra classe. Para cada associação, há uma multiplicidade em cada direção.

cio -

25/08/09

A expressão usada pela UML para os indicadores de multiplicidade é: Muitos * Apenas um Zero ou muitos 1 Um ou muitos Zero ou um 0..* Intervalo específi co 1 *

Exemplo de nomeação de uma associação:

<<Controle>> GerenteDeRegistro

<<Entidade>> Curso gerência

Exemplo de indicador de multiplicidade de uma associação:

<<Controle>> GerenteDeRegistro

<<Entidade>> Curso

1 1..*

Exemplos de como interpretar (ler) a associação representada em num diagrama de classes:

<<Controle>> GerenteDeRegistro <<Entidade>> Curso é gerenciada 1

Um objeto “Curso” é gerenciado por um único “GerenteDeRegistro”: <<Controle>> GerenteDeRegistro <<Entidade>> Curso gerência 1..* 5 10

25/08/09

Um “GerenteDeRegistro” gerencia um ou muitos “Cursos”. 6.3 Associação refl exiva

É quando os objetos da própria classe estão se relacionando.

<<Entidade>> Curso Pré-requisito

0..* 0..*

Um curso está associado a nenhum ou a muitos pré-requisitos. Além disso, um curso é pré-requisito de nenhum ou muitos cursos.

6.4 Agregação

• É uma forma especializada de associação, na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo.

• É representada como uma linha de associação com um diamante junto à classe agregadora.

• A multiplicidade é representada da mesma maneira que nas associações.

<<Fronteiriça>>

FormularioDeRegistro 1 1

<<Fronteiriça>> FormularioDeRegistro

Um objeto da classe “FormularioDeRegistro” contém um único objeto “FormularioDeMatricula”. Um objeto “FormularioDeMatricula” está contido num único objeto “FormularioDeRegistro”.

5

10

cio -

25/08/09

Agregação refl exiva: é quando objetos de uma classe é composto de objetos da própria classe.

6.4.1 Associação ou agregação <<Fronteiriça>> FormularioDeRegistro 1 1 <<Fronteiriça>> FormularioDeRegistro 1 <<Controle>> GerenteDeRegistro

6.4.2 Classe de uma associação de classe

Permite adicionar atributos, operações e outras características a uma dada associação.

Aluno Curso

Nota 3..10 1..*

A classe de uma associação de classe, normalmente, é gerada a partir de uma associação de muitos para muitos.

6.5 Relacionamento entre pacotes

• Pacotes são relacionados uns com os outros usando um relacionamento de dependência.

• Se uma classe de um pacote interage com uma classe de outro pacote, a relação de dependência é adicionada em nível de pacote.

5

25/08/09

• Relacionamentos entre pacotes são obtidos a partir dos diagramas de classe e de cenário.

Aluno RegrasDoNegocio Elementos da Universidade 6.6 Diagrama de componentes terraogcwmscgi terraogcwmstheme terraogcwmsclient terraogcwmsserver terramanager terralib xerces-c_2_7 terraogcwms wmsplugin terraogxml terraogccommon terraogcutils terraogcows

cio - 25/08/09 6.7 Diagrama de implantação ogwsserver ogwswms Servidor Cliente 1 - WMS Cliente 2 - WMS Cliente 3 - WFS HTTP HTTP HTTP SGBD 1 SGBD 2 SGBD 3

Figura 24 - Diagrama de implantação.

7 MODELAGEM CONCEITUAL

O modelo conceitual deve descrever a informação que o sistema vai gerenciar. Trata-se de um artefato do domínio do problema e não do domínio da solução. Portanto, o modelo conceitual não deve ser confundido com a arquitetura do software (diagrama de classes de projeto), pois esta, embora inicialmente derivada do modelo conceitual, pertence ao domínio da solução e, então, serve a um objetivo diferente.

O modelo conceitual também não deve ser confundido com o modelo de dados, pois o modelo de dados enfatiza a representação e a organização dos dados armazenados, enquanto o modelo conceitual visa representar a compreensão da informação e não a sua representação física.

O modelo conceitual procura mostrar quais são os elementos de informação tratados pelo sistema, para que mais adiante se possa mostrar ainda como essa informação é transformada pelo sistema a partir das diferentes requisições do usuário (operações de sistema).

5

10

25/08/09

O analista deve lembrar que a fase de análise considera apenas o mundo exterior ao sistema, e nunca seu interior. Por isso, não faz sentido falar em modelo de dados nessa fase porque os dados somente existirão no interior do sistema. Uma maneira interessante de compreender o modelo conceitual é imaginar que os elementos descritos nele correspondem a informações inicialmente existentes apenas na mente do usuário.

Figura 25 - O modelo conceitual é uma representação da visão que o usuário tem das informações gerenciadas pelo sistema.

O usuário, pelas operações e consultas de sistema, passa informações ao sistema e recupera informações do sistema. O sistema nem precisa ser considerado um sistema computacional nesse momento. Ou seja, essas informações existem independentes da existência de um computador para armazená-las.

O objetivo da análise é estudar o problema. Mas o sistema computacional seria uma solução para o problema, logo, objeto de estudo da fase de projeto. O sistema-solução poderia também não ser computacional. Seria possível analisar todo um sistema e propor uma solução manual para implementá-lo, na qual os dados são armazenados em fi chas de papel e as operações são efetuadas por funcionários da empresa com o uso de lápis, borracha e grampeador.

5

10

15

cio -

25/08/09

Assim, o modelo conceitual deve ser independente da solução física que virá a ser adotada e deve conter apenas elementos referentes ao domínio do problema em questão, fi cando relegados à fase de projeto os elementos da solução, isto é, todos os conceitos que se referem a computadores como: interfaces, formas de armazenamento (bancos de dados), segurança de acesso, comunicação etc.

7.1 Elementos básicos do modelo conceitual Apesar de a análise trabalhar com diferentes casos de uso em cada um dos ciclos iterativos, o modelo conceitual é único para todo o sistema. Então, não existe “modelo conceitual do primeiro ciclo”, ou do segundo ciclo etc. Existe um único modelo conceitual para todo o sistema, o qual vai sendo completado à medida que se passa de um ciclo para outro.

O modelo conceitual representa somente o aspecto estático da informação. Dessa maneira, não podem existir no modelo conceitual referências a operações ou aspectos dinâmicos dos sistemas.

Quando se trabalha modelagem conceitual com diagramas de classes da UML, existem precisamente três elementos para representar informação:

• conceitos, que são representados por classes. Conceitos na modelagem conceitual são a representação da informação complexa, que não pode ser descrita meramente por tipos alfanuméricos. Exemplos de conceitos num sistema de videolocadora são: fi ta, cliente, empréstimo e reserva;

• atributos, que são informações alfanuméricas diretamente ligadas aos conceitos. Exemplos de atributos num sistema de videolocadora são: idade do cliente, data do pagamento, nome do fi lme e endereço do cliente;

5 10 15 20 25 30

25/08/09

• associações, que muitas vezes são pouco compreendidas e consistem em um tipo de informação que liga diferentes conceitos entre si. Porém, a associação é mais do que uma mera ligação: ela própria é um tipo de informação conceitual importante. Exemplos de associações são: “é dono de”, entre uma pessoa e seu automóvel, “contraiu”, entre um cliente e um empréstimo, “emprega”, entre uma empresa e um grupo de funcionários.

Cliente + nome: String + endereço: String + telefone: Inteiro + debito: Moeda Emprestimo + data: Data + valorTotal: Moeda + pago: Booleano TipoDeFilme + tipo: String + prazo: Inteiro + preco: Moeda ItemDeEmprestimo + prazo: Inteiro + valor: Moeda Reserva + data: Data Filme + titulo: String Fita

+ danifi cada: Booleano = falso + codigo: String Concluído Em andamento EstadoDeItemDeEmprestimo tipo titulo codigo nome cadastra +cadastro 1 1 1 1 1 1 1 1 * * * * * * * * 1 1 1 1 1 1 1 0..1 Videolocadora especifi ca prioriza solicitou contém está em apareceu em especifi ca aparece em referenciou *[ordered}

Figura 26 - Modelo conceitual para o primeiro ciclo de uma videolocadora. Fonte: Waslawick, 2004.Glossário

Glossário

SOAP – protocolo simples baseado em XML que permite que

aplicações troquem informações sobre HTTP. 5

cio -

25/08/09

Referências bibliográfi cas

ASSEMBLY LANGUAGE SOURCE CODES. Disponível em: <http:// www. emu8086.com/dr/asm2html/assembler_source_code/>. Acessado em 23 de maio 2009.

DAUN, Berthould. Modelagem de objetos de negócios com XML: abordagem com base em XML. Rio de Janeiro: Elsevier, 2004.

FOWLER, Martin; SCOTT, Kendal. UML essencial: um breve guia para a linguagem padrão de modelagem de objetos. 2. ed. Porto Alegre: Bookman, 2000.

GORDON, Steven R.; GORDON, Judith R. Sistemas de informação: uma abordagem gerencial. Rio de Janeiro: LTC, 2006.

QUEIROZ, Gilberto Ribeiro de. UML: visão geral. Instituto Nacional de Pesquisas Espaciais: s.l, 2008. Disponível em: <http://www.dpi.inpe.br/~gribeiro/apresentacoes/uml_ 2008_ 02_29.pdf>. Acessado em 25 de maio 2009.

SOAP TUTORIAL. Disponível em: <http://www.w3schools.com/ soap/ default.asp>. Acessado em 23 de maio 2009.

WAZLAWICK, Raul Sidnei. Análise e projetos de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.