3 Modelando Sistemas com UML

Nessa Seção apresentaremos um resumo sobre os principais diagramas UML utilizados namodelagem funcional, modelagem estática e modelagem dinâmica de um sistema. O conteúdoda Seção é baseado no ótimo trabalho de ERIKSSON [1], o qual pode (na verdade, deve) serconsultado para maiores detalhes.

3.1 Notação

As partes que compõem a UML são:

• Visões. As visões mostram os diferentes aspectos do sistema que está sendomodelado. A visão não é um gráfico, mas uma abstração consistindo em uma sériede diagramas. Cada tipo de visão mostrará aspectos particulares do sistema, dandoenfoque em ângulos e níveis de abstrações diferentes e possibilitando a construçãode uma figura completa do sistema. As visões também podem servir de ligaçãoentre a linguagem de modelagem e o método/processo de desenvolvimentoescolhido. (A UML não é um método, mas sim uma linguagem, independente dométodo utilizado para o desenvolvimento do sistema.)

• Modelos de elementos. Os conceitos usados nos diagramas são modelos deelementos que representam definições comuns da orientação a objetos, tais comoclasses, objetos, mensagens e relacionamentos entre classes, incluindo associações,dependências e heranças.

• Mecanismos gerais. Os mecanismos gerais provêm comentários suplementares,informações ou semântica sobre os elementos que compõe os modelos. Provêm,também, mecanismos de extensão para adaptar ou estender a UML para ummétodo/processo, organização ou usuário específico.

• Diagramas. Os diagramas são os gráficos que descrevem o conteúdo em umavisão. A UML possui nove tipo de diagramas que são usados em combinação paraprover todas as visões do sistema.

3.1.1 Visões

Genericamente, um sistema pode ser descrito através de três modelos: funcional, estático edinâmico. Além disso, há aspectos não funcionais (requisitos de tempo e confiabilidade, porexemplo) e aspectos organizacionais (organização do trabalho e mapeamento dos módulos decódigo, por exemplo) que devem ser lavados em consideração. Em UML, um sistema édescrito com um certo número de visões, cada uma representando uma projeção da descriçãocompleta e mostrando aspectos particulares do sistema.

Cada visão é descrita por um número de diagramas que contêm informações que dãoênfase aos aspectos particulares do sistema. Existe, em alguns casos, uma certa sobreposiçãoentre os diagramas, o que significa que um deles pode fazer parte de mais de uma visão. Osdiagramas que compõem as visões contêm os modelos de elementos do sistema. As visõesque compõem um sistema são:

• Visão de casos de uso. A visão de caso de uso descreve a funcionalidade dosistema desempenhada pelos atores externos do sistema (usuários e/ou clientes). Avisão de casos de uso é central, já que seu conteúdo é base do desenvolvimento dasoutras visões do sistema. Essa visão é montada sobre os diagramas de caso de usoe, eventualmente, diagramas de atividade.

• Visão lógica. A visão lógica descreve como a funcionalidade do sistema serácompreendida e implementada, sendo efetuada principalmente por analistas edesenvolvedores. Em contraste com a visão de casos de uso, a visão lógica observae estuda o sistema internamente, descrevendo e especificando a estrutura estática

2

do sistema (classes, objetos, e relacionamentos) bem como as colaboraçõesdinâmicas entre os objetos (envio de mensagens entre objetos para execução dasfunções do sistema). Propriedades como persistência e concorrência são definidasnesta fase, bem como as interfaces e as estruturas de classes. A estrutura estática édescrita pelos diagramas de classes e diagramas de objetos. O modelo dinâmico édescrito pelos diagramas de estado, diagramas de seqüência, diagramas decolaboração e diagramas de atividade.

• Visão de componentes. A visão de componentes é uma descrição da arquiteturafísica dos componentes de software, necessários à implementação dos módulos dosistema, e suas dependências. É principalmente executado por desenvolvedores, econsiste dos diagramas de componentes.

• Visão de concorrência. A visão de concorrência trata da divisão do sistema emprocessos e processadores. Este aspecto, que é uma propriedade não funcional dosistema, permite uma melhor utilização do ambiente onde o sistema se encontrará,se o mesmo possuir execuções em paralelo, e se existir dentro do sistema umgerenciamento de eventos assíncronos. Uma vez dividido o sistema em linhas deexecução de processos concorrentes (threads), esta visão de concorrência deverámostrar como se dá a comunicação e a concorrência destas threads. A visão deconcorrência é suportada pelos diagramas dinâmicos, que são os diagramas deestado, seqüência, colaboração e atividade, e pelos diagramas de implementação,que são os diagramas de componente e diagramas de execução.

3.1.2 Modelos de Elementos

Os conceitos usados nos diagramas são chamados de modelos de elementos. Um modelo deelementos é definido por sua semântica, ou seja, a definição formal do elemento com o exatosignificado do que ele representa, sem definições duvidosas ou ambíguas. Um modelo deelementos define também define sua representação gráfica que é mostrada nos diagramas daUML. Um elemento pode existir em diversos tipos de diagramas, mas existem regras quedefinem que elementos podem ser mostrados em determinados tipos de diagramas. Algunsexemplos de modelos de elementos são as classes, objetos, estados, pacotes e componentes.Os relacionamentos também são modelos de elementos e são usados para conectar outrosmodelos de elementos entre si.

Como exemplo, veremos o modelo de elementos de pacotes. Pacote é um mecanismo deagrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, umpacote é definido como “um mecanismo de propósito geral para organizar elementossemanticamente relacionados em grupos.” Um pacote pode, inclusive, estar aninhado dentrode outros pacotes (pacotes subordinados). Todos os modelos de elementos que são ligados oureferenciados por um pacote são chamados de “conteúdo do pacote”. Um pacote possui váriosmodelos de elementos, o que significa que estes não podem ser incluídos em outros pacotes.

Um pacote é mostrado como um retângulo com uma aba anexada ao canto esquerdosuperior do retângulo. Se o conteúdo do pacote é exibido, então o nome do pacote é colocadodentro da aba. Caso contrário, o nome do pacote é colocado dentro do retângulo. A Figura 3.1mostra um exemplo de pacotes.

Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo deelemento é importado, refere-se apenas ao pacote que possui o elemento. Na grande maioriados casos, os pacotes possuem relacionamentos com outros pacotes, embora estes nãopossuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entrepacotes são de dependência, refinamento e generalização (herança). O pacote tem uma grandesimilaridade com a agregação (relacionamento que será tratado em seguida). O fato de umpacote ser composto de modelos de elementos cria uma agregação de composição. Se este fordestruído, todo o seu conteúdo também será.

3

Interface doUsuário

Objetos doSistema

Banco de Dados

Utilidades

Figura 3.1 Representação de pacotes com relacionamentos.

3.1.3 Mecanismos Gerais

A UML utiliza alguns mecanismos em seus diagramas para tratar informações adicionais.• Ornamentos. Ornamentos gráficos são anexados aos modelos de elementos em

diagramas e adicionam semânticas ao elemento. Um exemplo de um ornamento é oda técnica de separar um tipo de uma instância. Quando um elemento representaum tipo, seu nome é mostrado em negrito. Quando o mesmo elemento representa ainstância de um tipo, seu nome é escrito sublinhado e pode significar tanto o nomeda instância quanto o nome do tipo. Outros ornamentos são os de especificação demultiplicidade de relacionamentos, onde a multiplicidade é um número ou umintervalo que indica quantas instâncias de um tipo conectado pode estar envolvidona relação.

• Notas. Nem tudo pode ser definido em uma linguagem de modelagem, não importao quanto extensa ela seja. Para permitir adicionar informações a um modelo quenão poderiam ser representadas de outra forma, a UML provê a capacidade deadicionar notas. Uma nota pode ser colocada em qualquer lugar em um diagrama epode conter qualquer tipo de informação, conforme ilustrado na Figura 3.2.

• Estereótipos. O uso da palavra “estereótipo” foi sugerido por Rebecca Wirfs-Brockpara criar uma metaclassificação de elementos na UML, isto é, a introdução denovos elementos no metamodelo para permitir que usuários estendam a capacidadede modelagem da linguagem. As vantagens principais de estereótipos são apossibilidade de se referir ao tipo de elemento, como em classe de exceção, etornar a UML extensível pelo usuário do modelo pela definição de estereótiposadicionais. Estereótipos permitem definir a semântica na UML de maneira precisa,além de prover um grau de liberdade aos usuários para ajustar a linguagem a suasnecessidades. Um estereótipo para uma classe é escrito textualmente (emguillemets sobre a seqüência de nome) ou como um ícone no canto direitosuperior.

4

Cliente

A classeClientemanterá umvetor comtodos osclientes dobanco

Figura 3.2 Exemplo de uma nota.

3.1.4 Diagramas

Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico. A UMLoferece diagramas para descrição dos modelos funcional, estático (estrutura estática) edinâmico (comportamento dinâmico) de um sistema. Os tipos de diagramas utilizados pelaUML são nove: diagrama de casos de uso, de classes, de objeto, de estado, de seqüência, decolaboração, de atividade, de componente e de execução.

O modelo funcional é descrito pelos diagramas de casos de uso. A modelagem estáticaé descrita pelo diagrama de classes e de objetos, os quais consistem das classes e seusrelacionamentos. Os relacionamentos podem ser associações, herança (generalização),dependência ou refinamentos. Os modelos dinâmicos são descritos pelos diagramas de estado,seqüência, colaboração e atividade. Além disso, a arquitetura física do sistema pode serdescrita pelos diagramas de componentes e diagrama de execução. Veremos resumidamenteos diagramas UML, a seguir.

3.2 Modelos de Casos de Uso

Um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistemadeve fazer ou o que um sistema existente já faz. Um modelo de casos de uso é construídoatravés de um processo interativo no qual as discussões entre o cliente (e/ou usuários finais) eos desenvolvedores do sistema conduzem a uma especificação do sistema da qual todosconcordam. Os propósitos de um modelo de uso de casos são:

• Decidir e descrever os requisitos funcionais do sistema, os quais são resultantes deum acordo entre o cliente (e/ou usuários finais) e os desenvolvedores de softwareque estão construindo o sistema.

• Fornecer uma descrição clara e consistente do que o sistema deve fazer, tal que omodelo de casos de uso possa ser utilizado ao longo do processo dedesenvolvimento para documentar os requisitos do sistema e servir de base para amodelagem do projeto.

• Servir de base para realização dos testes de verificação do sistema, a partir dosquais podemos responder a perguntas do tipo “o sistema final oferece afuncionalidade requerida inicialmente?”

• Nos habilitar a descobrir os requisitos funcionais das classes e operações dosistema.

Os componentes primários de um modelo de casos de uso são os atores, casos de uso,e o sistema modelado. Para criarmos um modelo de casos de uso devemos definir o sistema,encontrar os atores e os casos de uso, descrever os casos de uso, definir os relacionamentosentre os casos de uso e validar o modelo. A criação de um modelo de casos de uso é umprocesso altamente interativo que inclui discussões entre o cliente e as pessoas querepresentam os atores. O modelo consiste de diagramas de casos de uso os quais mostram osatores, os casos de uso e seus relacionamentos. Estes diagramas nos dão uma visão geral domodelo, mas as descrições dos casos de uso são tipicamente textuais. (Modelos visuais não

5

podem nos oferecer toda as informações necessárias em um modelo de casos de uso; por isso,usamos também descrições textuais, em adição aos diagramas de casos de uso.)

Modelos de casos de uso são interessantes para o cliente (e/ou usuários finais) porqueespecificam a funcionalidade do sistema e descrevem como o sistema pode ser e será usado.Os desenvolvedores necessitam dos modelos de casos de uso para entender o que o sistemadeve fazer, oferecendo-lhes as bases para o trabalho futuro (outros modelos, projeto dosistema e implementação). A equipe de testes utiliza os modelos de casos de uso para testar osistema e garantir que sua funcionalidade satisfaça as especificações ditadas nos casos de uso.De um modo geral, quaisquer pessoas envolvidas em atividades relacionadas àsfuncionalidades do sistema podem ter interesse nos modelos de casos de uso, tais como osintegrantes das equipes de propaganda, vendas, documentação e suporte do sistema.

3.2.1 Diagramas de Casos de Uso

Um modelo de casos de uso é descrito em UML em diagramas de casos de uso. Um diagramade casos de uso contém elementos gráficos que representam o sistema, os atores e os casos deuso, mostrando os diferentes relacionamentos entre esses elementos, tais como generalização,associação e dependência. A Figura 3.3 ilustra um diagrama de casos de uso.

CadastraDependente

Remover ouAtualizar Cliente

Cadastrar ClienteAbrirConta corrente

FecharConta corrente

Abrir Poupança

FecharPoupança Cadastrar Agência Remover ou Atualizar

Agência

Remover ou AtualizarOperação (Histórico)

Cadastrar Operação(Histórico)

Administração doBanco

Figura 3.3 Exemplo de diagrama de casos de uso.

O diagrama de casos de uso da Figura 3.3 apresenta as funções de um ator externo de umsistema de controle bancário de um banco fictício. O diagrama especifica quais as funções queo administrador do banco poderá desempenhar. Note que não existe nenhuma preocupaçãocom a implementação de cada uma destas funções, pois o propósito do digrama de casos deuso é determinar somente a funcionalidade que deverá ser oferecida pelo sistema modelado.

3.2.2 Atores

Um ator é alguém ou algo que interage com o sistema; é quem ou o que usa o sistema.“Interage com o sistema” significa que o ator envia ou recebe mensagens para ou do sistemaou troca informações com o sistema. Em resumo, um ator executa um caso de uso. Um ator

6

pode ser humano ou outro sistema (tal como um computador conectado ao sistema ou umdispositivo de hardware que se comunica com o sistema).

Um ator é um tipo (uma classe), não uma instância. Um ator representa uma regra, nãoum usuário individual do sistema. Um ator se comunica com o sistema enviando e recebendomensagens, embora essas mensagens não sejam formalmente especificadas em um caso deuso. Um caso de uso é sempre inicializado por um ator que envia uma mensagem para ele(chamamos isso de estímulo). Um caso de uso, quando executado, pode enviar mensagenspara um ou mais atores.

Um ator pode ser um ator primário ou secundário. Um ator primário é aquele que usaas funções que definem a funcionalidade principal do sistema. Um ator secundário é aqueleque usa as funções que mantêm o sistema, tais como funções de gerenciamento de bases dedados, comunicação e outras tarefas administrativas. Um ator pode ser, também, ativo oupassivo. Um ator ativo é aquele que inicializa um caso de uso. Um ator passivo nuncainicializa um caso de uso, somente participa em um ou mais casos de uso.

A identificação dos atores consiste na determinação das entidades interessadas em usare interagir com o sistema. Podemos identificar os atores respondendo questões tais como:

• Quem usará a funcionalidade principal do sistema (atores primários)?• Quem necessitará da ajuda do sistema para realizar suas tarefas diárias?• Quem necessitará fornecer manutenção, administrar e manter o sistema

funcionando (atores secundários)?• Quais dispositivos de hardware o sistema necessita manipular?• Com quais outros sistemas o sistema necessita interagir?• Quem ou o que tem algum interesse nos resultados que o sistema produz?

Durante a análise do sistema, não consideraremos os atores como sendo somentepessoas em frente ao computador (um ator pode ser alguém ou algo que direta ouindiretamente interage com o sistema e usa os serviços do sistema para realizar algo). Um atorpossui um nome que representa sua regra no sistema.

Como são classes, atores podem ter os mesmos relacionamentos de classes. Nosdiagramas de casos de uso, somente os relacionamentos de generalização (herança) sãousados para descrever comportamento comum entre atores.

3.2.3 Casos de Uso

Um caso de uso, em UML, é definido como sendo um “conjunto de seqüências de açõesexecutadas por um sistema que produzem um resultado observável significativo para um atorparticular.” As características de um caso de uso são:

• Um caso de uso sempre é inicializado por um ator, direta ou indiretamente.• Um caso de uso oferece um resultado para um ator, não necessariamente saliente,

mas discernível.• Um caso de uso é completo. Uma caso de uso deve ser uma descrição completa.

Um caso de uso não é completo enquanto não fornecer um resultado para um ator.

Casos de uso são conectados a atores através de associações, as quais são algumas vezeschamada de associações de comunicação. As associações mostram com quais atores o uso decaso se comunica, incluindo o ator que inicializa a execução do caso de uso.

Um caso de uso é uma classe, não um objeto, a qual descreve a funcionalidade comoum todo, inclusive alternativas possíveis, erros e exceções que podem ocorrer durante aexecução do caso de uso. Uma instância de um caso de uso é chamada cenário, e representaum exemplo de uso de um sistema.

O processo de determinação dos casos de uso começa com a definição dos atores,como discutido anteriormente. Para cada um dos atores identificados, perguntamos:

7

• Quais funções do sistema o ator necessita? O que o ator necessita fazer?• O ator necessita criar, destruir, modificar, armazenar ou recuperar informações do

sistema?• O ator tem que ser notificado sobre eventos ocorridos no sistema, ou o ator

necessita notificar o sistema sobre alguma coisa? O que esses eventos representamem termos de funcionalidade?

• O trabalho diário do ator poderia ser simplificado ou tornado mais eficiente comnovas funções no sistema?

Há três tipos de relacionamentos entre casos de uso:

• Extensão. Relacionamento de generalização onde um uso de caso “estende” outrocaso de uso adicionando ações ao caso de uso genérico. O caso de uso estendidopode incluir parte do comportamento do caso de uso genérico.

• Uso. Relacionamento de generalização onde um caso de uso “usa” outro caso deuso, indicando que, como parte do caso de uso especializado, o comportamento docaso de uso genérico também será incluído.

• Agrupamento. Quando dois ou mais de casos de uso oferecem funcionalidadessimilares, ou estão de alguma maneira relacionados, podem ser agrupados em umpacote UML, como visto anteriormente.

3.2.5 Descrição de Casos de Uso

A descrição de um caso de uso é normalmente feita através de um texto contendo:

• Objetivo do caso de uso. Quais são os objetivos do caso de uso? Casos de uso sãoorientados por propósitos, e o propósito de um caso de uso precisa ser aparente.

• Como o caso de uso é inicializado. Quais atores inicializam a execução do caso deuso, e em quais situações?

• O fluxo de mensagens entre atores e casos de uso. Quais mensagens ou eventossão trocados entre o caso de uso e os atores para atualização ou recuperação deinformações ou para auxiliar um e outro nas tomadas de decisões? Qual é o fluxoprincipal de mensagens entre o sistema e os atores, e quais entidades no sistemasão usadas ou modificadas?

• Fluxo alternativo no caso de uso. Um caso de uso pode ter execuções alternativas,dependendo de condições e exceções ocorridas no sistema.

• Como o caso de uso termina e retorna um valor para o ator. Quando o caso de usotermina e qual a categoria de valor produzido para o ator?

A descrição de um caso de uso identifica o que é feito para um ator externo, e não como éfeito pelo sistema. O texto precisa ser claro e consistente para que o cliente possa entendê-lo evalidá-lo. Sentenças complicadas difíceis de interpretar devem ser evitadas.

3.3 Modelos de Classes e Objetos

Em modelagem orientada a objetos, classe, objetos e seus relacionamentos se constituem noselementos primários de modelagem. Um modelo de classes e objetos descreve a visão estáticade um sistema em termos de classes e objetos e relacionamentos entre classes e objetos.Embora seja similar a modelos de dados, classes não mostram apenas a estrutura de nossasinformações, mas descrevem também seu comportamento.

A identificação das classes de um sistema pode ser uma tarefa complicada, e deve serfeito por especialistas do domínio do problema no qual o software modelado se baseia. Asclasses devem ser retiradas do domínio do problema e nomeadas pelo que elas representam nosistema. Quando procuramos definir as classes de um sistema, existem algumas questões quepodem ajudar a identificá-las.

8

• Existem informações que devem ser armazenadas ou analisadas? Se existir algumainformação que tenha que ser guardada, transformada ou analisada de algumaforma, então é uma possível candidata para ser uma classe.

• Existem sistemas externos ao sistema modelado? Se existir, eles deverão ser vistoscomo classes pelo sistema para que possa interagir com os sistemas externos.

• Existem classes de bibliotecas, componentes ou modelos externos a seremutilizados pelo sistema modelado? Se a resposta for afirmativa, normalmente essasclasses, componentes e modelos serão classes candidatas do nosso sistema.

• Existem dispositivos que devem ser manipulados pelo sistema? Para quaisquerdispositivos conectados ao sistema podemos ter classes candidatas que manipulamtais dispositivos.

• Existem partes organizacionais no sistema? A representação de uma organização éfeita com classes, especialmente em modelos de negócios.

• Qual o papel dos atores dentro do sistema? Talvez o papel de um ator possa serdescrito através de uma classe tal como usuário, operador, cliente, etc.

Em UML, modelos de classes e objetos são descritos através dos diagramas de classese diagramas de objetos.

3.3.1 Diagramas de Classes

Um diagrama de classes descreve as classes de objetos do sistema, seus atributos, operações erelacionamentos. O diagrama de classes é uma visão estática do sistema, porque a estrutura eo comportamento descritos são sempre válidos em qualquer ponto do ciclo de vida do sistema.Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classesque estão inseridas em um único diagrama, ou seja, uma certa classe pode participar de váriosdiagramas de classes. Um exemplo de diagrama de classe é mostrado na Figura 3.4.

Compahia deAluguel de Veículos

Cliente

0..*

0..1

Carro SportCaminhão Carro de Passeio

Contrato de Aluguel

11

1

Veículo Alugado

1

0..*

refere a

possui

possui Tipos de Veículos

Figura 3.4 Exemplo de diagrama de classes.

Uma classe num diagrama pode ser diretamente implementada utilizando-se umalinguagem de programação orientada a objetos que tenha suporte direto para construção declasses. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas erelacionadas entre si. A seguir, descreveremos sucintamente a representação de classes e seusrelacionamentos em UML.

Em UML, uma classe é representada por um retângulo dividido em trêscompartimentos: o compartimento de nome, contendo apenas o nome da classe modelada; ode atributos, contendo a relação dos atributos que a classe possui em sua estrutura interna; e ocompartimento de operações, contendo os métodos de manipulação de dados e de

9

comunicação de uma classe com outras do sistema. A sintaxe usada em cada um destescompartimentos é independente de qualquer linguagem de programação, embora possam serusadas outras sintaxes como a do C++ ou Java, por exemplo. A Figura 3.5 mostra uma classerepresentada em UML.

Cliente

Nome : StringIdade : Num

Criar()Destruir()

Nome da Classe

Atributos

Operações

Figura 3.5 Representação de classe em UML.

Os relacionamentos ligam classes (e objetos) entre si, criando relações lógicas entreestas entidades. Os relacionamentos podem ser dos seguintes tipos:

• Associação. É uma conexão entre duas ou mais classes, uma conexão semânticaentre objetos das classes envolvidas na associação. Uma associação, normalmente,é bidirecional,. ou seja, se um objeto X é associado com um objeto Y, então Y étambém associado com X.

• Generalização. É um relacionamento de um elemento mais geral e outro maisespecífico. O elemento mais específico pode conter apenas informações adicionais.Uma instância (um objeto é uma instância de uma classe) do elemento maisespecífico pode ser usada onde o elemento mais geral seja permitido.

• Dependência e refinamentos. Dependência é um relacionamento entre elementos,um independente e outro dependente. Uma modificação em um elementoindependente afetará diretamente seus elementos dependentes. Refinamento é umrelacionamento entre duas descrições de uma mesma entidade, mas em níveisdiferentes de abstração.

Abordaremos, a seguir, cada tipo de relacionamento.

Associações

Uma associação representa que duas (ou mais) classes possuem uma ligação entre si, cujosignificado é, por exemplo, “conhece a”, “está conectada com”, ou “para cada X existe umY”. Classes e associações são muito úteis quando modelamos sistemas complexos.

Associação normal O tipo mais comum de associação é apenas uma conexão entre classes,sendo representada por uma linha sólida entre duas classes. A associação possui um nome,normalmente um verbo escrito junto à linha que representa a associação, mas substantivostambém são permitidos. Podemos também colocar uma seta no final da associação indicandoque esta só pode ser usada para o lado onde a seta aponta. Se a associação for bidirecional,podemos usar dois nomes, um nome para cada sentido da associação.

Para expressar a multiplicidade entre os relacionamentos, usamos um intervalo que indicaquantos objetos estão relacionados na associação. O intervalo pode ser de zero para um (0..1),zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) eassim por diante. É também possível expressar uma série de números como (1, 4, 6..12). Amultiplicidade, padrão, se nenhuma for especificada, é de um para um (1..1 ou apenas 1). AFigura 3.6 mostra um exemplo de associação normal entre objetos da classe Cliente e objetosda classe Conta Corrente. A multiplicidade da associação é de um para um.

10

Cliente Conta CorrentePossui !

" É possuído

Figura 3.6 Exemplo de associação normal.

Associação recursiva É possível conectar uma classe a ela mesma através de uma associaçãochamada associação recursiva. Semanticamente, a associação ainda representa uma conexãoentre dois objetos, mas os objetos conectados são da mesma classe. A Figura 3.7 mostra umexemplo de associação recursiva.

Pessoa

Marido

Esposa

" é casado com

Figura 3.7 Exemplo de associação recursiva.

Associação qualificada Associações qualificadas são associações com multiplicidade umpara vários (1..*) ou vários para vários (*) que possuem um “qualificador.” O “qualificador” éo identificador da associação qualificada, o qual especifica como um determinado objeto nofinal da associação “n” é identificado, podendo ser visto como um tipo de chave para separartodos os objetos na associação. O identificador é desenhado como uma pequena caixa no finalda associação, junto à classe de onde a navegação deve ser feita. A Figura 3.8 mostra umexemplo de associação qualificada.

Cód_ContaCorrente

Cliente Conta Corrente**

Figura 3.8 Exemplo de associação qualificada

Associação exclusiva Uma associação exclusiva representa uma restrição em duas ou maisassociações, especificando que objetos de uma classe podem participar de no máximo umadas associações em um dado momento. Uma associação exclusiva é representada por umalinha tracejada entre as associações que fazem parte da associação exclusiva, com aespecificação “{ou}” sobre a linha tracejada, conforme ilustrado na Figura 3.9.

Pessoa

Contrato

Empresa

0..*

0..*

1..* 1..*

{ou}

Figura 3.9 Exemplo de associação exclusiva.

11

No diagrama da Figura 3.9, um contrato não pode se referir a uma pessoa e a umaempresa ao mesmo tempo, significando que o relacionamento é exclusividade de uma dasduas classes.

Associação ordenada As associações entre objetos podem ter uma ordem implícita. Opadrão para uma associação é desordenada (ou sem nenhuma ordem específica). Mas umaordem pode ser especificada através da associação ordenada. Este tipo de associação pode sermuito útil, por exemplo, no caso de janelas de um sistema que devem estar ordenadas na tela(uma está no topo, uma está no fundo e assim por diante). A associação ordenada pode serescrita apenas colocando “{ordenada}” junto a linha de associação entre as duas classes.

Associação de classe Uma classe pode ser associada a uma outra associação. Este tipo deassociação não é conectada a nenhuma das extremidades da associação já existente, mas naprópria linha da associação. Esta associação serve para se adicionar informações extras àassociação já existente. A Figura 3.10 mostra um exemplo de uma associação de classe.

Cliente Processo

Fila

**

Figura 3.10 Exemplo de uma associação de classe.

Na Figura 3.10, a associação da classe Fila com a associação das classes Cliente eProcesso pode ser estendida com operações para adicionar processos na fila, ler e remover dafila e obter o tamanho da fila. Se operações ou atributos são adicionados a associação, aassociação deve ser mostrada como uma classe.

Associação ternária A associação ternária associa três classes de objetos, como mostrado nomodelo da Figura 3.11. Neste exemplo, a associação ternária especifica que um cliente poderápossuir 1 ou mais contratos e cada contrato será composto de 1 ou várias regras contratuais. Aassociação ternária é mostrada como um grade losango (diamante). Regras e multiplicidadepodem ser mostradas, mas “qualificadores” e agregação não são permitidos. Uma associaçãode classe pode ser conectada a uma associação ternária através de uma linha tracejadadesenhada a partir de um dos quatro pontos do losango.

Regras Contratuais

Contrato Cliente0..* 1..*

1..*

Figura 3.11 Exemplo de associação ternária.

12

Agregação A agregação é um caso particular da associação. A agregação indica que uma dasclasses do relacionamento é uma parte, ou está contida em outra classe. As expressões usadaspara identificar uma agregação são “consiste em”, “contém” e “é parte de”. A Figura 3.12mostra um exemplo de agregação.

NaviosMarinha*

contém

*

Figura 3.12 Exemplo de agregação.

Existem tipos especiais de agregação: agregações compartilhadas e compostas.• Agregação compartilhada. A agregação é dita compartilhada quando uma das

classes é uma parte, ou está contida na outra, mas esta parte pode fazer parte ouestar contida na outra várias vezes em um mesmo momento. No modelo da Figura3.13, uma pessoa pode ser membro de um ou de vários times em determinadomomento.

PessoaTime * *

Membros

**

Figura 3.13 Exemplo de agregação compartilhada.

• Agregação de composição. Agregação de composição é uma agregação na qualuma classe X que está contida em outra classe Y é parte de Y e “vive” em Y. Se oobjeto da classe Y que contém objetos da classe X for destruído, os objetos daclasse X agregados ao objeto da classe Y também serão destruídos. A Figura 3.14mostra um exemplo de agregação de composição.

Text

ListBox

Botão

Menu

Janela

*

*

*

**

*

*

*

Figura 3.14 Exemplo de agregação de composição.

Generalizações

A generalização é um relacionamento entre um elemento genérico e um outro mais específico.O elemento mais específico possui todas as características do elemento geral e pode conter,estrutura e comportamento particulares. Generalização/especialização é sinônimo de herança(vimos herança na Seção anterior). A generalização permite a criação de elementos maisespecializados a partir de outros elementos.

Uma generalização pode ser do tipo normal ou restrita. Uma generalização restrita, porsua vez, se divide em generalização de sobreposição, disjuntiva, completa e incompleta.

Generalização normal Na generalização normal, a classe mais específica, chamada desubclasse ou classe derivada, herda os atributos e métodos da classe mais genérica, chamadade superclasse ou classe base A Figura 3.15 exemplifica a generalização normal.

13

Conta Corrente Poupança

Figura 3.15 Exemplo de generalização normal.

Conforme podemos observar na Figura 3.15, a generalização normal é representadapor uma linha entre as duas classes do relacionamento, com uma seta no lado da linha ondeestá superclasse. Uma classe pode ser tanto uma subclasse quanto uma superclasse,dependendo de sua posição na hierarquia de classes na qual está inserida.

Generalização restrita Uma restrição aplicada a uma generalização especifica informaçõesmais precisas sobre como a generalização deve ser usada e estendida no futuro. As restriçõesa seguir definem as generalizações restritas com mais de uma subclasse:

• Generalizações de sobreposição e disjuntivas. Uma generalização de sobreposiçãoé aquela na qual qualquer subclasse que deriva de outras subclasses pode herdarmais de uma cópia de uma superclasse comum dessas subclasses (ou seja,generalização de sobreposição é uma associação que representa herança múltiplacom uma superclasse comum). A Figura 3.16 mostra um exemplo de generalizaçãode sobreposição. A generalização disjuntiva representa exatamente o contrário, istoé, uma subclasse derivada de duas ou mais subclasses não possui uma superclassecomum. A generalização disjuntiva é utilizada como padrão na UML.

Veículo

BarcoCarro

Anfíbio

{sobreposição}

Figura 3.16 Exemplo de generalização de sobreposição.

• Generalizações completas e incompletas. Uma restrição simbolizando que umageneralização é completa significa que todas as subclasses já foram especificadas,e não existe mais possibilidade de outra generalização a partir daquele ponto. AFigura 3.17 mostra um exemplo de generalização completa. A generalizaçãoincompleta é exatamente o contrário da generalização completa, isto é, novassubclasse podem derivadas. A generalização incompleta é assumida como padrãoda linguagem.

14

Pessoa

MulherHomem

{completa}

Figura 3.17 Exemplo de uma generalização completa.

Dependência e Refinamento

Além das associações e generalizações, existem ainda dois tipos de relacionamentos emUML: dependências e refinamentos.

O relacionamento de dependência é uma conexão semântica entre dois modelos deelementos, um independente e outro dependente. Uma mudança no elemento independente iráafetar o modelo dependente. Uma relação de dependência é simbolizada por uma linhatracejada com uma seta no final de um dos lados do relacionamento. O tipo de dependênciaentre as duas classes é especificado sobre a linha. As classes “amigas”, provenientes do C++,são um exemplo de um relacionamento de dependência, conforme ilustrado na Figura 3.18.

<< friend >> Classe BClasse A

Figura 3.18 Exemplo de dependência entre classes.

Os refinamentos são um tipo de relacionamento entre duas descrições de um mesmoelemento, mas em níveis de abstração diferentes. Refinamentos podem ser usados paramodelar diferentes implementações de um mesmo elemento (uma implementação simples eoutra mais complexa, mas também mais eficiente). Os refinamentos são simbolizados poruma linha tracejada com um triângulo no final de um dos lados do relacionamento e sãousados na coordenação de modelos. Em grandes projetos, todos os modelos do sistema devemser coordenados. A coordenação de modelos pode ser usada para mostrar modelos emdiferentes níveis de abstração, além de modelos em diferentes fases do desenvolvimento eseus relacionamentos. A Figura 3.19 mostra um exemplo de refinamento.

Classe de DesignClasse de Análise

Figura 3.19 Exemplo de um refinamento.

3.3.2 Diagramas de Objetos

O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesmanotação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciadosdas classes. Um diagrama de objetos mostra o perfil do sistema em um certo momento de suaexecução. A mesma notação do diagrama de classes é utilizada, com duas diferenças: osobjetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamentosão mostradas. Os diagramas de objetos não são tão importantes como os diagramas de

15

classes, mas eles são muito úteis para exemplificar diagramas complexos de classes, ajudandomuito em sua compreensão. Diagramas de objetos também são usados como parte dosdiagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema sãomostrados. A Figura 3.20 mostra um exemplo de diagrama de objetos.

2678: Contrato de Aluguel

Num_Contrato : 2678Veículo : "BMW 914"

2679: Contrato de Aluguel

Num_Contrato : 2679Veículo : "Audi V8"

Pablo: Cliente

Nome : "Pablo F. Barros"Idade : 20CPF : 94168912-15

Figura 3.20 Exemplo de diagrama de objetos.

Em UML, um objeto é mostrado da mesma forma que uma classe, mas com o nome doobjeto sublinhado e, opcionalmente, precedido pelo nome da classe. conforme ilustrado naFigura 3.21.

Nome do Objeto

Atributos

Operações

Pablo Barros:Cliente

Nome : "Pablo Barros"Idade : 20

Criar()Destruir()

Figura 3.21 Representação de um objeto.

3.4 Modelos Dinâmicos

Em sistemas orientados a objetos, o modelo de computação é baseado em um universoconstituído de objetos que se comunicam entre si através do mecanismo de troca demensagens. A forma pela qual os objetos se comunicam e os efeitos da comunicação entre osobjetos de um sistema determinam a dinâmica do sistema, isto é, como os objetos interagematravés da comunicação e como os objetos no sistema alteram seus estados durante o tempode vida do sistema. A comunicação entre um conjunto de objetos, com o propósito deexecutar alguma função, é chamada interação, a qual pode ser descrita por três tipos dediagrama: diagramas de seqüência, diagramas de colaboração e diagramas de atividade. Alémdesses diagramas, o modelo dinâmico de um sistema também pode ser descrito com auxíliodos diagramas de estados.

3.4.1 Diagramas de Estados

Todos os objetos possuem um estado que representa o resultado de atividades executadas peloobjeto, sendo normalmente determinado pelos valores de seus atributos e ligações com outrosobjetos. Um objeto muda de estado quando acontece algo. O fato de acontecer alguma coisa

16

com o objeto é chamado de evento. Através da análise da mudança de estados dos tipos deobjetos de um sistema, podemos prever todos os possíveis comportamentos de um objetos deacordo com os eventos que o mesmo possa sofrer.

O diagrama de estado é tipicamente um complemento para a descrição das classes.Este diagrama mostra todos os estados possíveis que objetos de uma certa classe podem seencontrar e mostra também quais são os eventos do sistemas que provocam tais mudanças. Osdiagramas de estado não são escritos para todas as classes de um sistema, mas apenas paraaquelas que possuem um número definido de estados conhecidos e onde o comportamento dasclasses é afetado e modificado pelos diferentes estados.

Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas,mostrando os estados que um objeto pode possuir e como os eventos (mensagens recebidas,timer, erros, e condições sendo satisfeitas) afetam estes estados ao passar do tempo. A Figura3.22 mostra um exemplo de diagrama de estados.

No Térreo Subindo

ParadoDescendo

Indo para otérreo

subir (andar)

Chegar no andar subir (andar)

Chegar no andar

descer (andar)

tempo de espera

Chegar no térreo

Figura 3.22 Exemplo de diagramas de estados

Diagramas de estado possuem um ponto de início e vários pontos de finalização. Umponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um ponto definalização (estado final) é mostrado como um círculo em volta de um outro círculo menorpreenchido.

Um estado é mostrado como um retângulo com cantos arredondados, Um estado, emsua notação, pode conter três compartimentos. O primeiro mostra o nome do estado. Osegundo é opcional e mostra as variáveis do estado, onde os atributos do objeto em questãopodem ser listados e atualizados. Os atributos são aqueles mostrados na representação daclasse, e em algumas vezes, podem ser mostradas também as variáveis temporárias, muitoúteis em diagramas de estado, já que através da observação de seus valores podemos percebera sua influência na mudança de estados de um objeto. O terceiro compartimento é opcional e échamado de compartimento de atividade, onde eventos e ações podem ser listadas. Trêseventos padrões podem ser mostrados no compartimento de atividades de um estado: entrar,sair e fazer. O evento entrar pode ser usado para definir atividades no momento em que oobjeto entra naquele estado. O evento sair define atividades que o objeto executa antes depassar para o próximo estado. O evento fazer define as atividades do objeto enquanto seencontra naquele estado.

Entre os estados estão as transições, mostrados como uma linha com uma seta no finalde um dos estados. A transição pode ser nomeada com o seu evento causador. Quando oevento acontece, a transição de um estado para outro é executada ou disparada.

17

Uma transição de estado normalmente possui um evento ligado a ela. Se um evento éanexado a uma transição, esta será executada quando o evento ocorrer. Se uma transição nãopossuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código do estadofor executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelodesenvolvedor). Quando todas as ações forem executadas pelo estado, a transição serádisparada e serão iniciadas as atividades do próximo estado no diagrama de estados.

3.4.2 Diagramas de Seqüência

Um diagrama de seqüência mostra a colaboração dinâmica entre os vários objetos de umsistema. O mais importante aspecto deste diagrama é que, a partir dele, podemos perceber aseqüência de mensagens enviadas entre os objetos. O diagrama mostra a interação entre osobjetos, alguma coisa que acontecerá em um ponto específico da execução do sistema. Odiagrama de seqüência consiste em um número de objetos mostrado em linhas verticais. Odecorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima parabaixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos quese relacionam.

Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o tempo, e oeixo horizontal, que mostra os objetos envolvidos na seqüência de uma certa atividade.Também mostram as interações para um cenário específico de uma certa atividade do sistema.No eixo horizontal estão os objetos envolvidos na seqüência. Cada um é representado por umretângulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamadade linha de vida do objeto, indicando a execução do objeto durante a seqüência, comoexemplo citamos: mensagens recebidas ou enviadas e ativação de objetos. A comunicaçãoentre os objetos é representada como linha com setas horizontais simbolizando as mensagensentre as linhas de vida dos objetos. A seta especifica se a mensagem é síncrona, assíncrona ousimples. As mensagens podem possuir também números seqüenciais, eles são utilizados paratornar mais explícito as seqüência no diagrama.

Em alguns sistemas, objetos executam concorrentemente, cada um com sua linha deexecução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado comoativação, mensagens assíncronas, ou objetos assíncronos. A Figura 3.23 mostra um exemplode diagrama de seqüência.

: Computador : Servidor deImpressão

: Impressora : Fila

Imprimir (arquivo) [Impressora Livre]

Imprimir (arquivo)

[Impressora Ocupada]

Imprimir (arquivo)

Figura 3.23 Exemplo de diagrama de seqüência.

Os diagramas de seqüência podem mostrar objetos que são criados ou destruídos comoparte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos através de

18

mensagens. A mensagem que cria ou destrói um objeto é geralmente síncrona, representadapor uma seta sólida.

3.4.3 Diagramas de Colaboração

Um diagrama de colaboração mostra, de maneira semelhante ao diagrama de seqüência, acolaboração dinâmica entre os objetos. Normalmente, podemos escolher entre utilizar odiagrama de colaboração ou o diagrama de seqüência.

No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,podemos perceber, também, os objetos com os seus relacionamentos. A interação demensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer dotempo, é melhor escolher o diagrama de seqüência, mas se a ênfase for o contexto do sistema,é melhor dar prioridade ao diagrama de colaboração.

O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversosobjetos são mostrados juntamente com seus relacionamentos. As setas de mensagens sãodesenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens sãonomeadas, e a ordem em que as mensagens são enviadas são mostradas. O diagrama tambémpode mostrar condições, interações e valores de resposta, além de poder conter objetos ativosque executam paralelamente com outros objetos. Um exemplo de diagrama de colaboração émostrado na Figura 3.24.

1: Imprimir (arq)

[Impressora Ocupada]1.2: Armazenar (arq)

[Impressora Livre]1.1: Imprimir (arq): Servidor de

Impressão

: Computador: Fila

: Impressora

Figura 3.24 Exemplo de diagrama de coloboração.

3.4.4 Diagramas de Atividade

Diagramas de atividade capturam ações e seus resultados, com foco no trabalho executado naimplementação de uma operação (método) e suas atividades numa instância de um objeto. Odiagrama de atividade é uma variação do diagrama de estado e possui um propósito um poucodiferente do diagrama de estado, qual seja capturar ações (trabalho e atividades que serãoexecutados) e seus resultados em termos das mudanças de estados dos objetos.

Os estados no diagrama de atividade mudam para um próximo estágio quando umaação é executada (sem ser necessário especificar nenhum evento como no diagrama deestado). Outra diferença entre o diagrama de atividade e o de estado é que o diagrama deatividades pode conter “swimlanes”. Uma swimlane agrupa atividades, informando onde estasatividades residem na organização, sendo representada por retângulos que englobam todos osobjetos que estão ligados.

Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com apossibilidade de expressar como as ações são executadas, o que elas fazem (mudanças dosestados dos objetos), quando elas são executadas (seqüência das ações), e onde elasacontecem (swimlanes). Um diagrama de atividade pode ser usado com diferentes propósitos:

• Para capturar os trabalhos que serão executados quando uma operação é disparada(ações). Este é o uso mais comum para o diagrama de atividade.

19

• Para capturar o trabalho interno em um objeto.• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como

elas vão afetar os objetos em torno delas.• Para mostrar como uma instância pode ser executada em termos de ações e

objetos.• Para mostrar como um negócio funciona em termos de trabalhadores (atores),

fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados nonegócio).

O diagrama de atividade mostra o fluxo seqüencial das atividades, sendo normalmenteutilizado para demonstrar as atividades executadas por uma operação específica do sistema. Odiagrama consiste em estados de ação, os quais especificam uma atividade desempenhada poruma operação do sistema. Decisões e condições, como execução paralela, também podem sermostrados na diagrama de atividade. O diagrama também pode conter especificações demensagens enviadas e recebidas como partes de ações executadas. Um exemplo de diagramade atividades é mostrado na Figura 3.25.

Mostrar Caixa deMensagem

“Disco Cheio”

Mostrar Caixa deMensagem

“Imprimindo”

Criar arquivoPostScriptRemover Caixa

de Mensagem

ImprimirArquivo()

[Disco Cheio]

[Espaço em disco]

^Impressora.Imprimir(arq)

Figura 3.25 Exemplo do diagrama de atividades.

4 Projeto de Sistemas

O projeto é a expansão e adaptação técnica dos resultados da análise. As classes, objetos,relacionamentos e colaborações da análise são complementados com novos elementos com opropósito de especificar como implementar o sistema em computador. No projeto, todos osdetalhes técnicos e restrições do ambiente de implementação são levados em consideração. Osresultados da análise são trazidos para o projeto e mantidos no centro do sistema. Às classesda análise são acrescidas classes técnicas que ajudam os objetos das classes de análise atornarem-se persistentes, a comunicarem-se e a apresentarem-se na interface com o usuário.No projeto, os mesmos tipos de diagramas da análise são utilizados, embora novos diagramassejam criados e modelados para mostrar a solução técnica.

Algumas atividades típicas de projeto são:

• Projeto da arquitetura do sistema, no qual as classes da análise são divididas empacotes funcionais (se ainda não o foram durante a análise). Novos pacotes paraárea técnicas tais como interface com o usuário, manipulação de bancos de dados ecomunicação, são adicionados. Os pacotes da análise poderiam usar serviçostécnicos desses pacotes do projeto, mas, a menos disso, deveriam permanecer tão

20

inalterados quanto possível. Os mecanismos de comunicação entre os diferentespacotes são estabelecidos.

• A concorrência necessita ser identificada e modelada através de classes ativas,mensagens assíncronas e técnicas de sincronização para manipulação de recursoscompartilhados.

• O formato detalhado da saída do sistema é especificado: interface com o usuário,relatórios e transações enviadas a outros sistemas. O projeto da interface com ousuário deve ser vista como uma atividade de projeto separada, dada suaimportância.

• Bibliotecas de classes e componentes que melhoram a arquitetura e minimizam ostrabalhos de implementação do sistema são comprados.

• Se bancos de dados relacionais serão usados, as classes do sistema são mapeadasem tabelas de um modelo relacional. Os mecanismos de leitura do banco de dadossão também estabelecidos no projeto da arquitetura.

• Considerações especiais são feitas a respeito da manipulação de exceções e falhasdo sistema. A manipulação de erros pode ser de erros “normais” (erros que podemser antecipados durante o desenvolvimento do sistema) e error anormais (erros quenão podem ser antecipados e que devem ser manipulados por algum mecanismogenérico de tratamento de exceções).

• As classes são organizadas em componentes de código fonte, e componentesexecutáveis são alocados a nós, através de diagramas de componentes e diagramasde execução, como veremos a seguir.

Uma atividade detalhada do projeto consiste na especificação de todas as classes dosistema, seus atributos, suas interfaces detalhadas e as descrições de todas as operações (empseudocódigo ou textualmente). As especificações precisam ser suficientemente detalhadas talque, juntamente com os diagramas dos modelos do sistema, ofereçam todas as informaçõesnecessárias para a fase de codificação.

Durante a fase de projeto, devemos ter em mente:• Interface. As interfaces criadas devem ser simples, completas e consistentes, tal

que os serviços dos componentes da interface sejam facilmente compreendidos eutilizados.

• Performance. Não precisamos nos preocupar demasiadamente com performancenos primeiros estágios do projeto. É mais fácil melhorar a performance de umsistema que funciona do que melhorar um sistema rápido que não funciona.

• Simplicidade. As modelos do projeto devem ser simples o bastante tal que possamser entendidas e usadas por todos os desenvolvedores.

• Documentação. Os diagramas UML criados na fase de projeto são os diagramas declasse, de seqüência, de colaboração, de estados, de atividade, de componentes ede execução. Os diagramas devem especificar uma solução técnica detalhada queservirá de base para a fase de implementação.

O projeto pode ser dividido em dois segmentos:

• Projeto do sistema. Projeto de mais alto nível do sistema, no qual os pacotes, ousubsistemas, que compõe o sistema são definidos, bem como as dependências emecanismos de comunicação primária entre os pacotes. O objetivo é projetar umaarquitetura clara e simples, com poucas dependências, evitando-se, na medida dopossível, dependências bidirecionais.

• Projeto de objetos. O projeto de objetos consiste na especificação das estruturas dedados e algoritmos utilizados na implementação das classes dos pacotes, de talforma que as classes sejam descritas em detalhes suficientes para a codificação.

A seguir, abordaremos esses dois segmentos do projeto de um sistema.

21

4.1 Projeto do Sistema

Uma arquitetura bem projetada é a base de um sistema extensível e modificável. Os pacotespodem estar relacionados com a manipulação de uma área funcional específica ou com umaárea técnica específica. É importante separar a lógica da aplicação (as classes de domínio) dalógica da implementação, de tal forma que alterações em uma dessas partes possam serefetuadas sem causar muito impacto na outra. Durante a definição da arquitetura é necessárioidentificar e estabelecer as regras de dependência entre pacotes (ou subsistemas), tal quenenhuma dependência bidirecional seja criada entre os pacotes, e identificar as bibliotecas aserem utilizadas.

Usualmente, a arquitetura de um sistema pode ser dividida em arquitetura lógica earquitetura física. A arquitetura lógica especifica as propriedades funcionais do sistema. Aarquitetura física é baseada nos aspectos não funcionais do sistema, tais como segurança,compatibilidade, utilização de recursos e ambiente de execução do sistema.

Arquitetura lógica Na arquitetura lógica, alocamos a funcionalidade a diferentes partes dosistema e especificamos em detalhes como nosso modelo de solução funciona. A arquiteturalógica contém a lógica da aplicação, mas não a distribuição física dessa lógica em diferentesprocessos, programas, ou computadores. A arquitetura lógica deve fornecer uma compreensãoclara da construção do sistema para tornar mais fácil a administração e coordenação dotrabalho de desenvolvimento. Nem todas as partes da arquitetura lógica são desenvolvidas noprojeto do sistema: bibliotecas de classes e componentes binários podem, muitas vezes, sercomprados.

A arquitetura lógica responde questões tais como:

• Qual é a funcionalidade oferecida pelo sistema?• Quais são as classes do sistema, e como essas classes relacionam-se entre si?• Como as classes e seus objetos colaboram para oferecer a funcionalidade?• Quais as restrições, nas funções do sistema, relativas a tempo?• Qual o melhor plano que os desenvolvedores deveriam seguir para desenvolver

esta arquitetura?

Em UML, os diagramas utilizados para descrever a arquitetura lógica são os diagramasde casos de uso, diagramas de classes, diagramas de estados, diagramas de atividade,diagramas de colaboração e diagramas de seqüência.

Uma arquitetura comum em sistemas de gestão empresarial e comercial é definida poruma estrutura em três camadas constituída dos seguintes pacotes:

• Pacote de interface com o usuário. O pacote de interface com o usuário está ”notopo” dos outros pacotes do sistema. Este pacote oferece os serviços de entrada dedados do usuário e de visualização dos resultados de saída oferecidos pelo sistema.Em sistemas desenvolvidos com auxílio de um ambiente de programação visual,como é o caso do Delphi, a tarefa de criação da interface é facilitada porque ousuário conta com inúmeros componentes visuais que podem imediatamente serinseridos na aplicação. Esses componentes representam elementos de interface taiscomo janelas, menus, caixas de diálogos, campos de edição, botões e relatórios.Além de definir a aparência da interface, os componentes visuais permitem, muitorapidamente, a especificação das funções de tratamento dos eventos disparadospelo usuário.

• Pacote de objetos de negócio. O pacote de objetos de negócio do projeto é baseadono pacote de objetos de negócio da análise. As classes do domínio da aplicação,bem com seus relacionamentos, estruturas e comportamentos, são preservados,porém descritos em mais detalhes, especificando-se como os relacionamentos,estruturas e comportamentos serão implementados.

22

• Pacote de persistência. Objetos persistentes, ao contrário de objetos transientes,são objetos que sobrevivem à execução de um programa, ou seja, são objetos quesão armazenados persistentemente em algum espaço persistente de objetos. Umespaço persistente pode ser tão simples como um arquivo texto ou tão complexoquanto um banco de dados orientado a objetos. Uma solução natural é a utilizaçãode um banco de dados comercial, orientado a objetos ou, mais tradicionalmente,um banco de dados relacional. Nesse último caso, é necessária uma camada deconversão do estado interno de um objeto em atributos de uma tabela e vice-versa,conforme vimos ao final de nosso curso de Projeto de Sistemas.

Arquitetura física A arquitetura física apresenta uma descrição detalhada dos componentesde software e hardware do sistema. A estrutura dos diferentes nós de hardware, bem comosuas conexões, são mostrados no projeto da arquitetura física. A estrutura e dependências dosmódulo de código que implementam os conceitos definidos na arquitetura lógica também sãoilustrados no projeto da arquitetura física, além da distribuição do componentes executáveisde software em computadores, processos e programas do sistema

A arquitetura física responde questões tais como:

• Em quais programas ou processos as classes e objetos do sistema estão fisicamentelocalizados?

• Em quais computadores os programas e processos executam?• Quais computadores e dispositivos de hardware estão presentes no sistema, e como

estão conectados entre si?• Quais as dependências entre os diferentes arquivos de código? Se determinado

arquivo é alterado, quais outros arquivos devem ser recompilados?

Em UML, a arquitetura física de um sistema é mostrada em dois tipos de diagramas: odiagrama de componentes e o diagrama de execução. O diagrama de componentes contém oscomponentes de software: as unidades de código e a estrutura dos arquivos de código fonte ebinários do sistema. O diagrama de execução mostra a arquitetura em tempo de execução dosistema, ou seja, os computadores e dispositivos físicos e o software alocado a eles.

4.1.1 Diagramas de Componentes

O diagrama de componentes descreve os componentes de software e suas dependências,representando a estrutura do código gerado. Os componentes são a implementação, naarquitetura física, dos conceitos e da funcionalidade definidos na arquitetura lógica (classes,objetos e seus relacionamentos). Tipicamente, componentes são os arquivos implementadosno ambiente de desenvolvimento, os quais podem ser dos seguintes tipos:

• Componentes de código fonte. Um componente de código fonte é, tipicamente, umarquivo contendo o código fonte que implementa uma ou mais classes do sistema.O arquivo persistent.pas, por exemplo, é um componente de código fonte.

• Componentes binários. Um componente binário é, tipicamente, um arquivo comcódigo objeto, uma biblioteca de ligação estática ou uma biblioteca de ligaçãodinâmica, resultante da compilação de um ou mais componentes de código fonte.

• Componentes executáveis. Um componente executável é um arquivo de programaexecutável resultante da ligação dos componentes binários do sistema. Umcomponente executável representa uma unidade de software que pode serexecutada por um computador.

Um componente é mostrado em UML como um retângulo com uma elipse e doisretângulos menores do seu lado esquerdo. O nome do componente é escrito abaixo ou dentrode seu símbolo, conforme ilustrado na Figura 4.1.

23

Gerenciador deComunicação

Comm.dll

Gráficos

Graficos.dll

Gerenciador deBanco de

DadosDb.dll

Aplicação

App.exel

Figura 4.1 Exemplo de diagrama de componentes.

Componentes são tipos, mas apenas componentes executáveis podem ter instâncias.Um diagrama de componentes mostra apenas componentes como tipos. (Para mostrarinstâncias de componentes, deve ser usado um diagrama de execução, onde as instânciasexecutáveis são alocadas em nós.) A dependência entre componentes pode ser mostrada comouma linha tracejada com uma seta, simbolizando que um componente precisa do outro parapossuir uma definição completa. Com o diagrama de componentes é facilmente visíveldetectar quais arquivos .dll são necessários para executar a aplicação.

Componentes podem definir interfaces que são visíveis para outros componentes. Asinterfaces podem ser tanto definidas em nível de codificação (como em Java) quanto eminterfaces binárias usadas em tempo de execução (como em OLE). Uma interface é mostradacomo uma linha partindo do componente e com um círculo na outra extremidade. O nome écolocado junto do círculo no final da linha. Dependências entre componentes podem entãoapontar para a interface do componente que está sendo usada.

4.1.2 Diagramas de Execução

Um diagrama de execução exibe a arquitetura física do hardware e do software no sistema.Especificamente, um diagrama de execução mostra os computadores e periféricos presentesno sistema, juntamente com as conexões e tipos de conexões entre computadores eperiféricos. Além disso, um diagrama de execução pode especificar também os componentesexecutáveis e objetos do sistema, para mostrar quais são as unidades de software executadas eem quais computadores tais unidades são executadas.

Um diagrama de execução é composto por:

• Componentes de software, denotados pela mesma simbologia dos componentes dodiagrama de componentes.

• Nós, objetos físicos que fazem parte do sistema, tais como máquinas servidoras,máquinas clientes numa LAN, impressoras, roteadores, etc.

• Conexões entre nós e componentes que, juntos, compõem toda a arquitetura físicado sistema.

O diagrama de execução demonstra a arquitetura em tempo de execução deprocessadores, dispositivos e componentes de software que executam no ambiente no qual osistema desenvolvido será utilizado. É a última descrição física da topologia do sistema,descrevendo a estrutura de hardware e de software que executam em cada unidade. A Figura4.2 ilustra um exemplo de diagrama de execução.

24

<<TCP/IP>>

<<TCP/IP>>

SQL <<TCP/IP>>

ClienteA :Pentium 200

MMX

ClienteB :Pentium 200

MMX

Servidor deAplicação :

HP/UX

Servidor deBanco deDados :

ORACLE

4.2 Exemplo de diagrama de execução.

4.2 Projeto de Objetos

O propósito do projeto de objetos é descrever as classes técnicas — classes dos pacotes deinterface com o usuário e persistência — e adicionar às classes do pacote de negócios detalhescomputacionais tais como estruturas de dados e algoritmos necessários a sua implementação.Em UML, essas descrições são feitas com novos diagramas de classes e diagramas demodelos dinâmicos (tais como diagramas de estados, seqüência, colaboração e atividade).Esses diagramas são os mesmos diagramas utilizados na fase de análise, definidos, porém,com muito mais detalhes e com o emprego de conceitos do universo da computação, ao invésde conceitos do universo da aplicação.

Como exemplo de projeto de objetos, desenvolvemos um pacote de persistência deobjetos utilizando tabelas de bancos de dados relacionais. O código das classes do pacote eparte da documentação textual das classes podem ser encontrados no seu ftp favorito.

Referências Bibliográficas

[1] ERIKSSON, H.; PENKER, M. UML Toolkit. Jonh Wiley & Sons, 1998

[2] FOWLER, M.; SCOTT, K. UML Destilled – Appling the Standard Object ModelingLanguage. Addison-Wesley, 1997.

[3] PAGLIOSA, P.A. Um Sistema de Modelagem Estrutural Orientado a Objetos. SãoCarlos, 1998. Tese (Doutorado) – Escola de Engenharia de São Carlos – USP.

[4] RAMBAUGH, J. et al. Object-Oriented Modeling and Design. Prentice-Hall, 1991.