3 Modelando Sistemas com UML

Transcrição

1 3 Modelando Sistemas com UML Nessa Seção apresentaremos um resumo sobre os principais diagramas UML utilizados na modelagem funcional, modelagem estática e modelagem dinâmica de um sistema. O conteúdo da Seção é baseado no ótimo trabalho de ERIKSSON [1], o qual pode (na verdade, deve) ser consultado 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á sendo modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas. Cada tipo de visão mostrará aspectos particulares do sistema, dando enfoque em ângulos e níveis de abstrações diferentes e possibilitando a construção de uma figura completa do sistema. As visões também podem servir de ligação entre a linguagem de modelagem e o método/processo de desenvolvimento escolhido. (A UML não é um método, mas sim uma linguagem, independente do método utilizado para o desenvolvimento do sistema.) Modelos de elementos. Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos, tais como classes, 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 um método/processo, organização ou usuário específico. Diagramas. Os diagramas são os gráficos que descrevem o conteúdo em uma visão. A UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema Visões Genericamente, um sistema pode ser descrito através de três modelos: funcional, estático e dinâmico. Além disso, há aspectos não funcionais (requisitos de tempo e confiabilidade, por exemplo) e aspectos organizacionais (organização do trabalho e mapeamento dos módulos de có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ção completa 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ção entre os diagramas, o que significa que um deles pode fazer parte de mais de uma visão. Os diagramas que compõem as visões contêm os modelos de elementos do sistema. As visões que compõem um sistema são: Visão de casos de uso. A visão de caso de uso descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usuários e/ou clientes). A visão de casos de uso é central, já que seu conteúdo é base do desenvolvimento das outras visões do sistema. Essa visão é montada sobre os diagramas de caso de uso e, 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 e desenvolvedores. Em contraste com a visão de casos de uso, a visão lógica observa e estuda o sistema internamente, descrevendo e especificando a estrutura estática

2 2 do sistema (classes, objetos, e relacionamentos) bem como as colaborações dinâmicas entre os objetos (envio de mensagens entre objetos para execução das funções do sistema). Propriedades como persistência e concorrência são definidas nesta 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 de colaboração e diagramas de atividade. Visão de componentes. A visão de componentes é uma descrição da arquitetura física dos componentes de software, necessários à implementação dos módulos do sistema, e suas dependências. É principalmente executado por desenvolvedores, e consiste dos diagramas de componentes. Visão de concorrência. A visão de concorrência trata da divisão do sistema em processos e processadores. Este aspecto, que é uma propriedade não funcional do sistema, 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 um gerenciamento de eventos assíncronos. Uma vez dividido o sistema em linhas de execuçã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 de concorrência é suportada pelos diagramas dinâmicos, que são os diagramas de estado, seqüência, colaboração e atividade, e pelos diagramas de implementação, que são os diagramas de componente e diagramas de execução Modelos de Elementos Os conceitos usados nos diagramas são chamados de modelos de elementos. Um modelo de elementos é definido por sua semântica, ou seja, a definição formal do elemento com o exato significado do que ele representa, sem definições duvidosas ou ambíguas. Um modelo de elementos define também define sua representação gráfica que é mostrada nos diagramas da UML. Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem que elementos podem ser mostrados em determinados tipos de diagramas. Alguns exemplos 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 outros modelos de elementos entre si. Como exemplo, veremos o modelo de elementos de pacotes. Pacote é um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, um pacote é definido como um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos. Um pacote pode, inclusive, estar aninhado dentro de outros pacotes (pacotes subordinados). Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de conteúdo do pacote. Um pacote possui vários modelos 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 esquerdo superior do retângulo. Se o conteúdo do pacote é exibido, então o nome do pacote é colocado dentro da aba. Caso contrário, o nome do pacote é colocado dentro do retângulo. A Figura 3.1 mostra um exemplo de pacotes. Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento é importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes, embora estes não possuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança). O pacote tem uma grande similaridade com a agregação (relacionamento que será tratado em seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição. Se este for destruído, todo o seu conteúdo também será.

3 3 Interface do Usuário Objetos do Sistema Utilidades Banco de Dados Mecanismos Gerais Figura 3.1 Representação de pacotes com relacionamentos. 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 é o da técnica de separar um tipo de uma instância. Quando um elemento representa um tipo, seu nome é mostrado em negrito. Quando o mesmo elemento representa a instância de um tipo, seu nome é escrito sublinhado e pode significar tanto o nome da instância quanto o nome do tipo. Outros ornamentos são os de especificação de multiplicidade de relacionamentos, onde a multiplicidade é um número ou um intervalo que indica quantas instâncias de um tipo conectado pode estar envolvido na relação. Notas. Nem tudo pode ser definido em uma linguagem de modelagem, não importa o quanto extensa ela seja. Para permitir adicionar informações a um modelo que não poderiam ser representadas de outra forma, a UML provê a capacidade de adicionar notas. Uma nota pode ser colocada em qualquer lugar em um diagrama e pode 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-Brock para criar uma metaclassificação de elementos na UML, isto é, a introdução de novos elementos no metamodelo para permitir que usuários estendam a capacidade de modelagem da linguagem. As vantagens principais de estereótipos são a possibilidade de se referir ao tipo de elemento, como em classe de exceção, e tornar a UML extensível pelo usuário do modelo pela definição de estereótipos adicionais. 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 suas necessidades. Um estereótipo para uma classe é escrito textualmente (em guillemets sobre a seqüência de nome) ou como um ícone no canto direito superior.

4 4 Cliente A classe Cliente manterá um vetor com todos os clientes do banco Figura 3.2 Exemplo de uma nota Diagramas Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico. A UML oferece diagramas para descrição dos modelos funcional, estático (estrutura estática) e dinâmico (comportamento dinâmico) de um sistema. Os tipos de diagramas utilizados pela UML são nove: diagrama de casos de uso, de classes, de objeto, de estado, de seqüência, de colaboraçã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 seus relacionamentos. 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 ser descrita pelos diagramas de componentes e diagrama de execução. Veremos resumidamente os 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 sistema deve fazer ou o que um sistema existente já faz. Um modelo de casos de uso é construído através de um processo interativo no qual as discussões entre o cliente (e/ou usuários finais) e os desenvolvedores do sistema conduzem a uma especificação do sistema da qual todos concordam. 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 de um acordo entre o cliente (e/ou usuários finais) e os desenvolvedores de software que estão construindo o sistema. Fornecer uma descrição clara e consistente do que o sistema deve fazer, tal que o modelo de casos de uso possa ser utilizado ao longo do processo de desenvolvimento para documentar os requisitos do sistema e servir de base para a modelagem do projeto. Servir de base para realização dos testes de verificação do sistema, a partir dos quais podemos responder a perguntas do tipo o sistema final oferece a funcionalidade requerida inicialmente? Nos habilitar a descobrir os requisitos funcionais das classes e operações do sistema. 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 relacionamentos entre os casos de uso e validar o modelo. A criação de um modelo de casos de uso é um processo altamente interativo que inclui discussões entre o cliente e as pessoas que representam os atores. O modelo consiste de diagramas de casos de uso os quais mostram os atores, os casos de uso e seus relacionamentos. Estes diagramas nos dão uma visão geral do modelo, mas as descrições dos casos de uso são tipicamente textuais. (Modelos visuais não

5 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) porque especificam 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 sistema deve fazer, oferecendo-lhes as bases para o trabalho futuro (outros modelos, projeto do sistema e implementação). A equipe de testes utiliza os modelos de casos de uso para testar o sistema 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 às funcionalidades do sistema podem ter interesse nos modelos de casos de uso, tais como os integrantes das equipes de propaganda, vendas, documentação e suporte do sistema Diagramas de Casos de Uso Um modelo de casos de uso é descrito em UML em diagramas de casos de uso. Um diagrama de casos de uso contém elementos gráficos que representam o sistema, os atores e os casos de uso, 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. Abrir Conta corrente Cadastrar Cliente Remover ou Atualizar Cliente Cadastra Dependente Fechar Conta corrente Abrir Poupança Administração do Banco Cadastrar Operação (Histórico) Fechar Poupança Cadastrar Agência Remover ou Atualizar Agência Remover ou Atualizar Operação (Histórico) 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 um sistema de controle bancário de um banco fictício. O diagrama especifica quais as funções que o administrador do banco poderá desempenhar. Note que não existe nenhuma preocupação com a implementação de cada uma destas funções, pois o propósito do digrama de casos de uso é determinar somente a funcionalidade que deverá ser oferecida pelo sistema modelado 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 sistema ou troca informações com o sistema. Em resumo, um ator executa um caso de uso. Um ator

6 6 pode ser humano ou outro sistema (tal como um computador conectado ao sistema ou um dispositivo 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ão um usuário individual do sistema. Um ator se comunica com o sistema enviando e recebendo mensagens, embora essas mensagens não sejam formalmente especificadas em um caso de uso. 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 mensagens para um ou mais atores. Um ator pode ser um ator primário ou secundário. Um ator primário é aquele que usa as funções que definem a funcionalidade principal do sistema. Um ator secundário é aquele que usa as funções que mantêm o sistema, tais como funções de gerenciamento de bases de dados, comunicação e outras tarefas administrativas. Um ator pode ser, também, ativo ou passivo. Um ator ativo é aquele que inicializa um caso de uso. Um ator passivo nunca inicializa 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 usar e 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 somente pessoas em frente ao computador (um ator pode ser alguém ou algo que direta ou indiretamente interage com o sistema e usa os serviços do sistema para realizar algo). Um ator possui um nome que representa sua regra no sistema. Como são classes, atores podem ter os mesmos relacionamentos de classes. Nos diagramas de casos de uso, somente os relacionamentos de generalização (herança) são usados para descrever comportamento comum entre atores Casos de Uso Um caso de uso, em UML, é definido como sendo um conjunto de seqüências de ações executadas por um sistema que produzem um resultado observável significativo para um ator particular. 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 vezes chamada de associações de comunicação. As associações mostram com quais atores o uso de caso 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 como um todo, inclusive alternativas possíveis, erros e exceções que podem ocorrer durante a execução do caso de uso. Uma instância de um caso de uso é chamada cenário, e representa um 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 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 representam em termos de funcionalidade? O trabalho diário do ator poderia ser simplificado ou tornado mais eficiente com novas 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 outro caso de uso adicionando ações ao caso de uso genérico. O caso de uso estendido pode incluir parte do comportamento do caso de uso genérico. Uso. Relacionamento de generalização onde um caso de uso usa outro caso de uso, indicando que, como parte do caso de uso especializado, o comportamento do caso de uso genérico também será incluído. Agrupamento. Quando dois ou mais de casos de uso oferecem funcionalidades similares, ou estão de alguma maneira relacionados, podem ser agrupados em um pacote UML, como visto anteriormente 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ão orientados 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 de uso, e em quais situações? O fluxo de mensagens entre atores e casos de uso. Quais mensagens ou eventos são trocados entre o caso de uso e os atores para atualização ou recuperação de informações ou para auxiliar um e outro nas tomadas de decisões? Qual é o fluxo principal de mensagens entre o sistema e os atores, e quais entidades no sistema sã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 uso termina 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 e validá-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 nos elementos primários de modelagem. Um modelo de classes e objetos descreve a visão estática de 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 nossas informações, mas descrevem também seu comportamento. A identificação das classes de um sistema pode ser uma tarefa complicada, e deve ser feito por especialistas do domínio do problema no qual o software modelado se baseia. As classes devem ser retiradas do domínio do problema e nomeadas pelo que elas representam no sistema. Quando procuramos definir as classes de um sistema, existem algumas questões que podem ajudar a identificá-las.

8 8 Existem informações que devem ser armazenadas ou analisadas? Se existir alguma informação que tenha que ser guardada, transformada ou analisada de alguma forma, então é uma possível candidata para ser uma classe. Existem sistemas externos ao sistema modelado? Se existir, eles deverão ser vistos como classes pelo sistema para que possa interagir com os sistemas externos. Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo sistema modelado? Se a resposta for afirmativa, normalmente essas classes, componentes e modelos serão classes candidatas do nosso sistema. Existem dispositivos que devem ser manipulados pelo sistema? Para quaisquer dispositivos conectados ao sistema podemos ter classes candidatas que manipulam tais 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 ser descrito 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 classes e diagramas de objetos Diagramas de Classes Um diagrama de classes descreve as classes de objetos do sistema, seus atributos, operações e relacionamentos. O diagrama de classes é uma visão estática do sistema, porque a estrutura e o 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 classes que estão inseridas em um único diagrama, ou seja, uma certa classe pode participar de vários diagramas de classes. Um exemplo de diagrama de classe é mostrado na Figura 3.4. Cliente 1 possui 0..* Contrato de Aluguel 0..* 0..1 refere a Veículo Alugado 1 possui Tipos de Veículos Compahia de Aluguel de Veículos Caminhão Carro Sport Carro de Passeio Figura 3.4 Exemplo de diagrama de classes. Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de programação orientada a objetos que tenha suporte direto para construção de classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e relacionadas entre si. A seguir, descreveremos sucintamente a representação de classes e seus relacionamentos em UML. Em UML, uma classe é representada por um retângulo dividido em três compartimentos: o compartimento de nome, contendo apenas o nome da classe modelada; o de atributos, contendo a relação dos atributos que a classe possui em sua estrutura interna; e o compartimento de operações, contendo os métodos de manipulação de dados e de

9 9 comunicação de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programação, embora possam ser usadas outras sintaxes como a do C++ ou Java, por exemplo. A Figura 3.5 mostra uma classe representada em UML. Cliente Nome : String Idade : 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 entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associação. É uma conexão entre duas ou mais classes, uma conexão semântica entre 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 mais especí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 mais especí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 elemento independente afetará diretamente seus elementos dependentes. Refinamento é um relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes 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, cujo significado é, por exemplo, conhece a, está conectada com, ou para cada X existe um Y. 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 substantivos também são permitidos. Podemos também colocar uma seta no final da associação indicando que 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 indica quantos 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) e assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). A multiplicidade, padrão, se nenhuma for especificada, é de um para um (1..1 ou apenas 1). A Figura 3.6 mostra um exemplo de associação normal entre objetos da classe Cliente e objetos da classe Conta Corrente. A multiplicidade da associação é de um para um.

10 10 Cliente Possui! " É possuído Conta Corrente Figura 3.6 Exemplo de associação normal. Associação recursiva É possível conectar uma classe a ela mesma através de uma associação chamada associação recursiva. Semanticamente, a associação ainda representa uma conexão entre dois objetos, mas os objetos conectados são da mesma classe. A Figura 3.7 mostra um exemplo de associação recursiva. Esposa Pessoa Marido " é casado com Figura 3.7 Exemplo de associação recursiva. Associação qualificada Associações qualificadas são associações com multiplicidade um para 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 no final da associação n é identificado, podendo ser visto como um tipo de chave para separar todos os objetos na associação. O identificador é desenhado como uma pequena caixa no final da associação, junto à classe de onde a navegação deve ser feita. A Figura 3.8 mostra um exemplo de associação qualificada. Cliente Cód_Conta Corrente * Conta Corrente Figura 3.8 Exemplo de associação qualificada Associação exclusiva Uma associação exclusiva representa uma restrição em duas ou mais associações, especificando que objetos de uma classe podem participar de no máximo uma das associações em um dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações que fazem parte da associação exclusiva, com a especificação {ou} sobre a linha tracejada, conforme ilustrado na Figura 3.9. Contrato 0..* 0..* {ou} 1..* 1..* Pessoa Empresa Figura 3.9 Exemplo de associação exclusiva.

11 11 No diagrama da Figura 3.9, um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento é exclusividade de uma das duas classes. Associação ordenada As associações entre objetos podem ter uma ordem implícita. O padrão para uma associação é desordenada (ou sem nenhuma ordem específica). Mas uma ordem pode ser especificada através da associação ordenada. Este tipo de associação pode ser muito ú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 ser escrita 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 de associação não é conectada a nenhuma das extremidades da associação já existente, mas na pró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 e Processo pode ser estendida com operações para adicionar processos na fila, ler e remover da fila e obter o tamanho da fila. Se operações ou atributos são adicionados a associação, a associação deve ser mostrada como uma classe. Associação ternária A associação ternária associa três classes de objetos, como mostrado no modelo da Figura 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. A associação ternária é mostrada como um grade losango (diamante). Regras e multiplicidade podem ser mostradas, mas qualificadores e agregação não são permitidos. Uma associação de classe pode ser conectada a uma associação ternária através de uma linha tracejada desenhada a partir de um dos quatro pontos do losango. Contrato 0..* 1..* Cliente 1..* Regras Contratuais Figura 3.11 Exemplo de associação ternária.

12 12 Agregação A agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As expressões usadas para identificar uma agregação são consiste em, contém e é parte de. A Figura 3.12 mostra um exemplo de agregação. Marinha contém * Navios 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 ou estar contida na outra várias vezes em um mesmo momento. No modelo da Figura 3.13, uma pessoa pode ser membro de um ou de vários times em determinado momento. Time * * Membros Pessoa Figura 3.13 Exemplo de agregação compartilhada. Agregação de composição. Agregação de composição é uma agregação na qual uma classe X que está contida em outra classe Y é parte de Y e vive em Y. Se o objeto da classe Y que contém objetos da classe X for destruído, os objetos da classe X agregados ao objeto da classe Y também serão destruídos. A Figura 3.14 mostra um exemplo de agregação de composição. Janela * * * * Text ListBox Botão Menu 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 mais especializados a partir de outros elementos. Uma generalização pode ser do tipo normal ou restrita. Uma generalização restrita, por sua 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 de subclasse ou classe derivada, herda os atributos e métodos da classe mais genérica, chamada de superclasse ou classe base A Figura 3.15 exemplifica a generalização normal.

13 13 Conta Corrente Poupança Figura 3.15 Exemplo de generalização normal. Conforme podemos observar na Figura 3.15, a generalização normal é representada por uma linha entre as duas classes do relacionamento, com uma seta no lado da linha onde está 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ções mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições a 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 herdar mais 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últipla com uma superclasse comum). A Figura 3.16 mostra um exemplo de generalização de sobreposição. A generalização disjuntiva representa exatamente o contrário, isto é, uma subclasse derivada de duas ou mais subclasses não possui uma superclasse comum. A generalização disjuntiva é utilizada como padrão na UML. Veículo {sobreposição} Carro Barco Anfíbio Figura 3.16 Exemplo de generalização de sobreposição. Generalizações completas e incompletas. Uma restrição simbolizando que uma generalização é completa significa que todas as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A Figura 3.17 mostra um exemplo de generalização completa. A generalização incompleta é exatamente o contrário da generalização completa, isto é, novas subclasse podem derivadas. A generalização incompleta é assumida como padrão da linguagem.

14 14 Pessoa {completa} Homem Mulher 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 em UML: dependências e refinamentos. O relacionamento de dependência é uma conexão semântica entre dois modelos de elementos, 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 linha tracejada com uma seta no final de um dos lados do relacionamento. O tipo de dependência entre 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 Classe A << friend >> Classe B Figura 3.18 Exemplo de dependência entre classes. Os refinamentos são um tipo de relacionamento entre duas descrições de um mesmo elemento, mas em níveis de abstração diferentes. Refinamentos podem ser usados para modelar diferentes implementações de um mesmo elemento (uma implementação simples e outra mais complexa, mas também mais eficiente). Os refinamentos são simbolizados por uma linha tracejada com um triângulo no final de um dos lados do relacionamento e são usados na coordenação de modelos. Em grandes projetos, todos os modelos do sistema devem ser coordenados. A coordenação de modelos pode ser usada para mostrar modelos em diferentes níveis de abstração, além de modelos em diferentes fases do desenvolvimento e seus relacionamentos. A Figura 3.19 mostra um exemplo de refinamento. Classe de Análise Classe de Design Figura 3.19 Exemplo de um refinamento Diagramas de Objetos O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. Um diagrama de objetos mostra o perfil do sistema em um certo momento de sua execução. A mesma notação do diagrama de classes é utilizada, com duas diferenças: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de

15 15 classes, mas eles são muito úteis para exemplificar diagramas complexos de classes, ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados. A Figura 3.20 mostra um exemplo de diagrama de objetos. Pablo: Cliente Nome : "Pablo F. Barros" Idade : 20 CPF : : Contrato de Aluguel Num_Contrato : 2678 Veículo : "BMW 914" 2679: Contrato de Aluguel Num_Contrato : 2679 Veículo : "Audi V8" Figura 3.20 Exemplo de diagrama de objetos. Em UML, um objeto é mostrado da mesma forma que uma classe, mas com o nome do objeto sublinhado e, opcionalmente, precedido pelo nome da classe. conforme ilustrado na Figura Pablo Barros:Cliente Nome : "Pablo Barros" Idade : 20 Criar() Destruir() Nome do Objeto Atributos Operações 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 universo constituído de objetos que se comunicam entre si através do mecanismo de troca de mensagens. A forma pela qual os objetos se comunicam e os efeitos da comunicação entre os objetos de um sistema determinam a dinâmica do sistema, isto é, como os objetos interagem através da comunicação e como os objetos no sistema alteram seus estados durante o tempo de vida do sistema. A comunicação entre um conjunto de objetos, com o propósito de executar alguma função, é chamada interação, a qual pode ser descrita por três tipos de diagrama: diagramas de seqüência, diagramas de colaboração e diagramas de atividade. Além desses diagramas, o modelo dinâmico de um sistema também pode ser descrito com auxílio dos diagramas de estados Diagramas de Estados Todos os objetos possuem um estado que representa o resultado de atividades executadas pelo objeto, sendo normalmente determinado pelos valores de seus atributos e ligações com outros objetos. Um objeto muda de estado quando acontece algo. O fato de acontecer alguma coisa

16 16 com o objeto é chamado de evento. Através da análise da mudança de estados dos tipos de objetos de um sistema, podemos prever todos os possíveis comportamentos de um objetos de acordo 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 se encontrar e mostra também quais são os eventos do sistemas que provocam tais mudanças. Os diagramas de estado não são escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um número definido de estados conhecidos e onde o comportamento das classes é 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 Figura 3.22 mostra um exemplo de diagrama de estados. No Térreo subir (andar) Subindo Chegar no térreo Chegar no andar subir (andar) Indo para o térreo Descendo Chegar no andar Parado descer (andar) tempo de espera Figura 3.22 Exemplo de diagramas de estados Diagramas de estado possuem um ponto de início e vários pontos de finalização. Um ponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um ponto de finalização (estado final) é mostrado como um círculo em volta de um outro círculo menor preenchido. Um estado é mostrado como um retângulo com cantos arredondados, Um estado, em sua notação, pode conter três compartimentos. O primeiro mostra o nome do estado. O segundo é opcional e mostra as variáveis do estado, onde os atributos do objeto em questão podem ser listados e atualizados. Os atributos são aqueles mostrados na representação da classe, 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 perceber a 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ês eventos 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 o objeto entra naquele estado. O evento sair define atividades que o objeto executa antes de passar para o próximo estado. O evento fazer define as atividades do objeto enquanto se encontra naquele estado. Entre os estados estão as transições, mostrados como uma linha com uma seta no final de um dos estados. A transição pode ser nomeada com o seu evento causador. Quando o evento acontece, a transição de um estado para outro é executada ou disparada.

17 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ão possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelo desenvolvedor). 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 Diagramas de Seqüência Um diagrama de seqüência mostra a colaboração dinâmica entre os vários objetos de um sistema. O mais importante aspecto deste diagrama é que, a partir dele, podemos perceber a seqüência de mensagens enviadas entre os objetos. O diagrama mostra a interação entre os objetos, alguma coisa que acontecerá em um ponto específico da execução do sistema. O diagrama de seqüência consiste em um número de objetos mostrado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos que se relacionam. Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o tempo, e o eixo 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 um retângulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execução do objeto durante a seqüência, como exemplo citamos: mensagens recebidas ou enviadas e ativação de objetos. A comunicação entre os objetos é representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem é síncrona, assíncrona ou simples. As mensagens podem possuir também números seqüenciais, eles são utilizados para tornar mais explícito as seqüência no diagrama. Em alguns sistemas, objetos executam concorrentemente, cada um com sua linha de execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como ativação, mensagens assíncronas, ou objetos assíncronos. A Figura 3.23 mostra um exemplo de diagrama de seqüência. : Computador : Servidor de Impressã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 como parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos através de

18 18 mensagens. A mensagem que cria ou destrói um objeto é geralmente síncrona, representada por uma seta sólida Diagramas de Colaboração Um diagrama de colaboração mostra, de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entre os objetos. Normalmente, podemos escolher entre utilizar o diagrama 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 de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é 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 diversos objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens são nomeadas, e a ordem em que as mensagens são enviadas são mostradas. O diagrama também pode mostrar condições, interações e valores de resposta, além de poder conter objetos ativos que executam paralelamente com outros objetos. Um exemplo de diagrama de colaboração é mostrado na Figura : Computador [Impressora Ocupada] 1.2: Armazenar (arq) : Fila 1: Imprimir (arq) : Servidor de Impressão [Impressora Livre] 1.1: Imprimir (arq) : Impressora Figura 3.24 Exemplo de diagrama de coloboração Diagramas de Atividade Diagramas de atividade capturam ações e seus resultados, com foco no trabalho executado na implementação de uma operação (método) e suas atividades numa instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, qual seja capturar ações (trabalho e atividades que serão executados) 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 uma ação é executada (sem ser necessário especificar nenhum evento como no diagrama de estado). Outra diferença entre o diagrama de atividade e o de estado é que o diagrama de atividades pode conter swimlanes. Uma swimlane agrupa atividades, informando onde estas atividades residem na organização, sendo representada por retângulos que englobam todos os objetos que estão ligados. Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), quando elas são executadas (seqüência das ações), e onde elas acontecem (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 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 no negócio). O diagrama de atividade mostra o fluxo seqüencial das atividades, sendo normalmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema. O diagrama consiste em estados de ação, os quais especificam uma atividade desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser mostrados na diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas. Um exemplo de diagrama de atividades é mostrado na Figura ImprimirArquivo() [Disco Cheio] Mostrar Caixa de Mensagem Disco Cheio [Espaço em disco] Mostrar Caixa de Mensagem Imprimindo Remover Caixa de Mensagem ^Impressora.Imprimir(arq) Criar arquivo PostScript 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 o propósito de especificar como implementar o sistema em computador. No projeto, todos os detalhes técnicos e restrições do ambiente de implementação são levados em consideração. Os resultados da análise são trazidos para o projeto e mantidos no centro do sistema. Às classes da análise são acrescidas classes técnicas que ajudam os objetos das classes de análise a tornarem-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 diagramas sejam 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 em pacotes 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 e comunicação, são adicionados. Os pacotes da análise poderiam usar serviços técnicos desses pacotes do projeto, mas, a menos disso, deveriam permanecer tão

20 20 inalterados quanto possível. Os mecanismos de comunicação entre os diferentes pacotes 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 recursos compartilhados. 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 o usuário deve ser vista como uma atividade de projeto separada, dada sua importância. Bibliotecas de classes e componentes que melhoram a arquitetura e minimizam os trabalhos de implementação do sistema são comprados. Se bancos de dados relacionais serão usados, as classes do sistema são mapeadas em tabelas de um modelo relacional. Os mecanismos de leitura do banco de dados são também estabelecidos no projeto da arquitetura. Considerações especiais são feitas a respeito da manipulação de exceções e falhas do sistema. A manipulação de erros pode ser de erros normais (erros que podem ser antecipados durante o desenvolvimento do sistema) e error anormais (erros que não podem ser antecipados e que devem ser manipulados por algum mecanismo genérico de tratamento de exceções). As classes são organizadas em componentes de código fonte, e componentes executáveis são alocados a nós, através de diagramas de componentes e diagramas de execução, como veremos a seguir. Uma atividade detalhada do projeto consiste na especificação de todas as classes do sistema, seus atributos, suas interfaces detalhadas e as descrições de todas as operações (em pseudocódigo ou textualmente). As especificações precisam ser suficientemente detalhadas tal que, juntamente com os diagramas dos modelos do sistema, ofereçam todas as informações necessá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 e utilizados. Performance. Não precisamos nos preocupar demasiadamente com performance nos primeiros estágios do projeto. É mais fácil melhorar a performance de um sistema 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 possam ser entendidas e usadas por todos os desenvolvedores. Documentação. Os diagramas UML criados na fase de projeto são os diagramas de classe, de seqüência, de colaboração, de estados, de atividade, de componentes e de execução. Os diagramas devem especificar uma solução técnica detalhada que servirá 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, ou subsistemas, que compõe o sistema são definidos, bem como as dependências e mecanismos de comunicação primária entre os pacotes. O objetivo é projetar uma arquitetura clara e simples, com poucas dependências, evitando-se, na medida do possível, dependências bidirecionais. Projeto de objetos. O projeto de objetos consiste na especificação das estruturas de dados e algoritmos utilizados na implementação das classes dos pacotes, de tal forma que as classes sejam descritas em detalhes suficientes para a codificação. A seguir, abordaremos esses dois segmentos do projeto de um sistema.