UML - Luciano Tucci
Propaganda
Histórico da UML Os estudos sobre a tecnologia de objetos iniciaram-se na década de 1980 com ênfase nas linguagens de programação. No final da mesma década começaram a surgir os métodos de análise e projeto. Os principais métodos foram de: • SHLAER & MELLOR (1989 e 1991); • COAD & YOURDON (1991); • COAD & NICOLA (1993); • COAD et al. (1995); • WIRFS-BROCK et al. (1990); • BOOCH (1994 e 1995); • RUMBAUGH et al. (1991 e 1996); • MARTIN & ODELL (1994 e 1995); • JACOBSON (1994 e 1995). Todos os métodos eram muito similares, apesar da existência de diferentes notações para representar o mesmo conceito, o que na verdade, causava muita confusão entre os técnicos e competição entre os metodologistas, o que provocou a "guerra dos métodos". Em 1994 James Rumbaugh e Grady Booch iniciaram o trabalho de unificação dos métodos Booch e OMT. Em 1995 no OOPSLA , Booch e Rumbaught apresentaram a documentação da versão 0.8 do método unificado e anunciaram a integração de Ivar Jacobson na equipe, formando assim o que eles denominaram de "Three amigos". Durante 1996 eles trabalharam no método que passou a chamar de Unified Modeling Language (UML) e a Object Management Group (OMG) iniciou um esforço para padronização na área de métodos. Os esforços de Rumbaugh, Booch e Jacobson resultaram as versões 0.9 e 0.91 da UML em junho e outubro de 1996 respectivamente. A UML é a sucessora da linguagem de modelagem encontrada nos métodos Booch, OOSE/Jacobson, OMT e outros como Modelos de Entidades e Relacionamentos. Cada um desses métodos era reconhecido mediante alguma forte característica. O OOSE é orientado a ‘use case’ e provê um excelente recurso para a análise de requisitos. A OMT foi expressiva para análise e sistemas centrados a dados. Durante 1996 a Rational Software Corporation contou com a participação de outras Instituições parceiras como: HewlettPackard, IBM, Microsoft, Oracle, Unisys, Platinum Technology, etc. Essa colaboração contribuiu para a produção da versão 1.0, uma versão bem definida, expressiva, poderosa e aplicável, a qual foi submetida a OMG para adoção. Em setembro de 1997 liberaram a versão 1. 1 da UML e em dezembro a mesma foi aprovada como padrão pela OMG. Com a unificação dos métodos a UML alcançou dois objetivos: Acabou com as diferenças existentes entre os métodos anteriores; Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de desenvolvimento e conceitos internos. Método A UML não é um método é uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem é a notação que o método utiliza para expressar projetos enquanto que o processo indica quais passos seguir para desenvolver um projeto. A especificação da UML consiste de duas partes: Semântica - especifica a sintaxe abstrata e a semântica dos conceitos de modelagem estática e dinâmica de objetos; Notação – especifica a notação gráfica para a representação visual da semântica. A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental é o processo de desenvolvimento de sistemas em pequenos passos. Uma iteração é um laço de desenvolvimento que resulta na liberação de um subconjunto de produtos que evolui até o produto final percorrendo as seguintes atividades: Análise de requisitos Análise Projeto Implementação Teste O detalhamento de cada etapa destas atividades define o método de desenvolvimento de sistemas. Análise de requisitos Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o relacionamento entre o ambiente e o sistema. Deve ser uma definição de necessidades do usuário e não uma proposta de solução. O usuário deve indicar os requisitos prioritários para o sistema. O grupo de análise deve identificar as necessidades do usuário. Decisões do projeto impostas não são características essenciais do domínio do problema. A análise de requisitos compõe-se dos seguintes diagramas: Diagrama de caso de uso; Diagrama de seqüência; Diagrama de colaboração; Para realizar a análise de requisitos, primeiramente deve-se: Identificar objetivo e características do sistema; Identificar os requisitos essenciais; Descrever as necessidades do usuário; Elaborar diagrama de caso de uso; Elaborar diagrama de seqüência; Elaborar diagrama de colaboração Conceitos UML é uma linguagem visual para especificação (modelagem) de sistemas orientados a objeto. A UML privilegia a descrição de um sistema seguindo três perspectivas: 1. Os diagramas de classes - (Dados estruturais); 2. Os diagramas de casos de uso (Operações funcionais); 3. Os diagramas de seqüência, atividades e transição de Estados (Eventos temporais). Os casos de uso de um projeto de software são descritos na linguagem UML através de Diagramas de Casos de Uso (Use Case). Diagrama de "Use Case": É um diagrama usado para se identificar como o sistema se comporta em várias situações que podem ocorrer durante sua operação. Descrevem o sistema, seu ambiente e a relação entre os dois. Os componentes deste diagrama são os atores, os "Use Case" e os relacionamentos. Casos de uso e Relacionamentos. Ainda pode-se usar as primitivas Pacotes e Notas. Ator: Representa qualquer entidade que interage com o sistema durante sua execução essa interação se dá através de comunicações (troca de mensagens). Um ator pode ser uma pessoa (usuário, secretaria, aluno...), um dispositivo (impressora, máquina...), hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc. Algumas de suas características são descritas abaixo: Ator Ator Ator Ator não é parte do sistema. Representa os papéis que o usuário do sistema pode desempenhar. pode interagir ativamente com o sistema. pode ser um receptor passivo de informação. pode representar um ser humano, uma máquina ou outro sistema. Representação: OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outros quando interagem com o sistema. Um ator cujo identificador seja ALUNO não representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de aluno. Use Case: Como foi exemplificado acima, é uma seqüência de ações que o sistema executa e produz um resultado de valor para o ator. Modela o dialogo entre os atores e o sistema; é um fluxo de eventos completos. Algumas de suas características são descritas abaixo: Um "Use Case" modela o diálogo entre atores e o sistema. Um "Use Case" é iniciado por um ator para invocar uma certa funcionalidade do sistema. Um "Use Case" é fluxo de eventos completo e consistente. O conjunto de todos os "Use Case" representa todas as situações possíveis de utilização do sistema. Relacionamento: Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associação: É uma conexão entre classes, e também significa que é uma conexão entre objetos daquelas classes. Em UML, uma associação é definida com um relacionamento que descreve uma série de ligações, onde a ligação é definida como a semântica entre as duplas de objetos ligados. 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. Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento é representado através de uma seta : Exemplo: Diagrama de "Use Cases" para um sistema automatizado de Matrícula num Curso Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "estão conectadas com", "para cada X existe um Y" e assim por diante. Classes e associações são muito poderosas quando modeladas em sistemas complexos Associações Normais O tipo mais comum de associação é apenas uma conexão entre classes. É representada por uma linha sólida entre duas classes. A associação possui um nome (junto à linha que representa a associação), normalmente um verbo, mas substantivos também são permitidos. Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada para o lado onde a seta aponta. Mas associações também podem possuir dois nomes, significando um nome para cada sentido da associação. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão relacionados no link. 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). Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1). Duas classes se relacionando por associação normal No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associação. Associação Recursiva É possível conectar uma classe a ela mesma através de uma associação e que ainda representa semanticamente a conexão entre dois objetos, mas os objetos conectados são da mesma classe. Uma associação deste tipo é chamada de associação recursiva. Exemplo de uma associação recursiva Associação Ternária Mais de duas classes podem ser associadas entre si, a associação ternária associa três classes. Ela é mostrada como uma grade losango (diamante) e ainda suporta uma associação de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do losango para a classe onde seria feita a associação ternária. Exemplo de uma associação ternária No exemplo acima 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. 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 palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de". É uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo. É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações. Tipo de Relacionamento - Generalizações A generalização é um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. A generalização, também chamada de herança, permite a criação de elementos especializados em outros. Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São elas: generalização normal e restrita. As generalizações restritas se dividem 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, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdados. Exemplo de uma generalização normal Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações. A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalização. 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 Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma superclasse por sobreposição, novas subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada como padrão Exemplo de uma generalização de sobreposição Generalizações Completa e Incompleta: 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 generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem. Diagrama de Seqüência Em um sistema computacional orientado a objeto os serviços (casos de uso) são fornecidos através da colaboração de grupos. Os objetos interagem através de comunicações de forma que juntos, cada um com suas responsabilidades, realizem os casos de uso. O Diagrama de seqüência é uma ferramenta importante no projeto de sistemas orientados a objetos. Embora a elaboração dos diagramas possa consumir um tempo considerável para sistemas maiores ou mais complexos, eles oferecem a seguir as bases para a definição de uma boa parte do projeto como: os relacionamentos necessários entre as classes, métodos e atributos das classes e comportamento dinâmico dos objetos. Um diagrama de seqüência é um diagrama de objetos, ou seja, ele contém como primitiva principal um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqüência é descrever as comunicações necessárias entre objetos para a realização dos processos em um sistema computacional. Os diagramas de seqüência têm este nome porque descrevem ao longo de uma linha de tempo a seqüência de comunicações entre objetos. Como podem existir muitos processos em um sistema computacional, sugere-se proceder à construção dos diagramas de seqüência por caso de uso. Assim, tomar-se-ia separadamente cada caso de uso para a construção de seus diagramas de seqüência. De uma forma geral, para cada caso de uso constrói-se um diagrama de seqüência principal descrevendo as seqüências normais de comunicação entre objetos e diagramas complementares descrevendo seqüências alternativas e tratamento de situações de erro. Utiliza-se também o termo cenário associado com os diagramas de seqüência. Um cenário é uma forma de ocorrência de um caso de uso. Como o processo de um caso de uso pode ser realizado de diferentes formas, para descrever a realização de um caso de uso pode ser necessário estudar vários cenários. Cada cenário pode ser descrito por um diagrama de seqüência. No exemplo do caso de uso Cadastrar Aluno do sistema de controle acadêmico, podem-se considerar os cenários de inclusão, alteração e exclusão de aluno. Notação UML para Diagramas de Seqüência A notação UML para descrição de diagramas de seqüência envolve a indicação do conjunto de objetos envolvidos em um cenário e a especificação das mensagens trocadas entre estes objetos ao longo de uma linha de tempo. Os objetos são colocados em linha na parte superior do diagrama. Linhas verticais tracejadas são traçadas da base dos objetos até a parte inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, à medida que se avança para baixo evolui-se o tempo. Retângulos colocados sobre as linhas de tempo dos objetos indicam os períodos de ativação do objeto. Durante um período de ativação, o objeto respectivo esta em execução realizando algum processamento. Nos períodos em que o objeto não esta ativo, ele esta alocada (ele existe), mas não esta executando nenhuma instrução. A figura abaixo ilustra a estrutura básica de um diagrama de seqüência para o cenário Inclusão de Aluno do caso de uso Cadastrar Aluno. Outra primitiva importante dos diagramas de seqüência é a troca de mensagem. Esta primitiva é utilizada para indicar os momentos de interação ou comunicação entre os objetos. Utiliza-se como notação para trocas de mensagens segmentos de retas direcionadas da linha de tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta é colocada na extremidade do objeto destino. As linhas representando troca de mensagens são desenhadas na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezível. O objeto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, no recebimento de uma mensagem o objeto destino é ativado para tratamento da mensagem. A figura abaixo ilustra a troca de mensagens entre objetos e entre atores e objetos. As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter três significados: · Chamada de Função ou Procedimento Uma das interações mais freqüentes entre objetos é a chamada de função. Uma chamada de função significa que um objeto esta solicitando a execução de uma função (um método) de um outro objeto. Este conceito segue estritamente o processo de chamada de função ou de procedimento utilizado nas linguagens de programação. Obviamente, para que um objeto possa chamar um método de outro objeto é necessário que o método seja declarado como publico na classe respectiva. Como será visto a seguir, a sintaxe, no caso de mensagens que representem chamadas de função, é semelhante àquela das linguagens de programação. · Envio de Mensagem Objetos também podem comunicar-se com outros objetos através do envio explıcito de uma mensagem. O envio de uma mensagem, ao contrario da chamada de função, não é uma interação direta entre dois objetos. Na verdade, quando um objeto envia uma mensagem a outro objeto, a mensagem é roteada ou encaminhada por algum mecanismo de entrega de mensagens. Normalmente, este serviço é prestado pelo sistema operacional através de mecanismos como Message Queries (filas de mensagens) ou serviços de notificação. · Ocorrência de Evento Existem também outras formas de interação entre objetos através de eventos. Esta é também a forma padrão de interação entre objetos e atores. Basicamente, um evento é algum acontecimento externo ao software, mas que é a ele notificado, pois lhe diz respeito. A notificação, ou seja, a indicação de que um determinado evento ocorreu é, na maioria dos casos, feita pelo sistema operacional. Eventos podem também ser gerados pelo software para o sistema operacional. Exemplos são as saídas para dispositivos (monitor, porta serial, disco) feitos através de serviços do sistema operacional. Alguns exemplos de eventos são: Evento Origem Destino Clique do mouse mouse Algum objeto Movimentação do mouse mouse Algum objeto Dados no buffer do teclado teclado Algum objeto Dados no buffer da serial porta serial Algum objeto Projeção de dados no monitor. Bip do alto-falante. Algum objeto Algum objeto monitor alto-falante Colocação de dados no buffer da serial Algum objeto Porta serial Interrupção Dispositivo de hardware Algum objeto Eventos do sistema operacional (timer) Sistema operacional Algum objeto Tipos de Mensagens Nos exemplos das figuras utilizou-se como notação gráfica para as trocas de mensagens segmentos de reta com uma seta aberta em uma das extremidades. Esta é a notação genérica para mensagens que pode ser utilizada nas primeiras versões dos diagramas de seqüência. Em diagramas mais detalhados, entretanto, será utilizada outra notação deforma a indicar também o tipo das mensagens. Existem dois tipos de mensagens chamadas mensagens síncronas e assíncronas. · Mensagens Síncronas Mensagens síncronas são mensagens que implicam um sincronismo rígido entre os estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um sincronismo entre objetos pode ser entendido, de uma forma geral, como uma dependência na evolução de estado de um objeto sobre o estado de um segundo objeto. De uma forma mais direta, pode-se dizer que uma mensagem síncrona implica que o objeto que enviou a mensagem aguarde a conclusão do processamento da mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para então prosseguir seu fluxo de execução. O exemplo mais comum de mensagem síncrona é a chamada de função. Em uma chamada de função o objeto que faz a chamada ü empilhado e fica neste estado até a conclusão do processamento da função chamada. Trata-se, portanto, de um sincronismo rígido entre o objeto chamador e o objeto chamado. Alguns sistemas operacionais oferecem também mecanismos de troca de mensagens síncronas de forma que o objeto que envia a mensagem fique em estado de espera até a conclusão do tratamento da mensagem. A notação UML para uma mensagem síncrona é a de um segmento de reta com uma seta cheia em uma das extremidades · Mensagens Assíncronas Mensagens assíncronas são mensagens enviadas de um objeto a outro sem que haja uma dependência de estado entre os dois objetos. O objeto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem feita no objeto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais são o exemplo mais comum deste tipo de mensagem. Além disso, de uma forma geral, todas as comunicações entre atores e objetos representam trocas de mensagem assíncronas. Considere, por exemplo, uma operação para apresentação de uma mensagem no monitor. Um objeto executa uma instrução print (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O objeto prossegue seu processamento independentemente do desfecho na operação. Observe que os softwares não bloqueiam quando o monitor não apresenta alguma informação. A notação UML para uma mensagem assíncrona é a de um segmento de reta com uma meia seta em uma das extremidades. · Autodelegação Um objeto pode enviar mensagens para outros objetos e pode também enviar mensagens para ele próprio. Uma mensagem enviada de um objeto para ele próprio chama-se uma Autodelegação. Mensagens de Autodelegação podem ser síncronas ou assíncronas. O caso mais comum de mensagens assíncronas é o envio de uma mensagem de um objeto para ele mesmo através de mecanismos de envio de mensagens do sistema operacional. O caso mais comum de mensagens de Autodelegação síncronas é a chamada de função de um objeto pelo próprio objeto. Diagrama de Colaboração Mostra a interação organizada ao lado de cada classe de objetos e a ligação entre elas. Como o diagrama de seqüência, o diagrama de colaboração mostra as mensagens trocadas por um conjunto de objetos durante um cenário. É uma representação gráfica alternativa para mostrar um cenário. Descrevem grupos de objetos que colaboram através de comunicação. Um diagrama de colaboração contém: Objetos, que são representados por retângulos. Ligações entre objetos, representadas por uma linha conectando os objetos. Mensagens trocadas entre objetos em uma seqüência ordenada Fluxo de dados entre objetos, se houver. Através do diagrama de colaboração é mais fácil visualizar as mensagens trocadas entre os objetos, subsidiando assim a elaboração do diagrama de classes de objetos. Os objetos e as mensagens são as mesmas do diagrama de seqüência. Utilizando o diagrama de colaboração é possível identificar se existe algum objeto que não troca mensagens com outro. Caso isto aconteça deve-se analisar o modelo de origem e verificar se este objeto é mesmo necessário. Os diagramas de seqüência e de colaboração serão mais utilizados no desenvolvimento do projeto quando são projetadas as implementações dos relacionamentos. O objetivo do diagrama de colaboração é agrupar as mensagens entre pares de objetos de forma a fazer-se um levantamento das necessidades de comunicação. Diagrama de Estado O comportamento de uma classe de objetos é representado através de um diagrama de transição de estado, que descreve o ciclo de vida de uma dada classe, os eventos que causam a transição de estado para o outro e as ações resultantes da mudança de estado. O estado de um objeto é uma das possíveis condições na qual o objeto pode existir. O estado compreende todas as propriedades do objeto associadas aos valores correntes de cada uma dessas propriedades. Segundo a UML a especificação da dinâmica do sistema deve ser feita através de diagramas de estados. Constrói-se um diagrama de estado descrevendo o comportamento de cada classe e eventuais diagramas comportamentais para descrever a dinâmica de todo o sistema ou de certos módulos. Diagrama de estado é uma descrição global do comportamento dos objetos desta classe em todo o sistema; Diagrama de estado; a especificação da dinâmica do sistema deve ser feita através de diagramas de classe; Descreve-se o conjunto de estados de um objeto e também o conjunto de transações de estados existentes. A UML utiliza como notação para diagramas de estados a notação proposta por Harel. Nesta notação, um diagrama de estados e um grafo dirigido cujos nodos representam estados e cujos arcos representam transições entre estados. Estados são representados graficamente por elipses ou retângulos com bordas arredondadas e transições são representadas por segmento de retas dirigidas.
