Este capítulo dar-lhe-á uma ideia geral sobre as bases do &UML;. Tenha em mente que isto não é um tutorial compreensivo sobre o &UML; mas sim uma breve introdução ao mesmo, como tal poderá ser lido como um tutorial de &UML;. Se você quiser aprender mais sobre a Unified Modelling Language ou, na generalidade, sobre a análise e desenho de 'software', baseie-se num dos vários livros disponíveis sobre o tópico. Existem também vários tutoriais na Internet que você poderá usar como ponto de partida. A Unified Modelling Language (&UML;) é uma linguagem ou notação de diagramas para especificar, visualizar e documentar modelos de 'software' orientados por objectos. O &UML; não é um método de desenvolvimento, o que significa que não lhe diz o que fazer primeiro ou o que fazer a seguir ou como desenhar o seu sistema, mas ajuda-o a visualizar o seu desenho e a comunicar com os outros. O &UML; é controlado pelo Object Management Group (OMG) e é a norma da indústria para descrever graficamente o 'software'. O &UML; está desenhado para o desenho de 'software' orientado por objectos e tem uma utilização limitada para outros paradigmas de programação. O &UML; é composto por vários elementos do modelo que representam as diferentes partes de um sistema de 'software'. Os elementos de &UML; são usados para criar diagramas que representam uma dada parte ou um ponto de vista do sistema. São suportados os seguintes tipos de diagramas pelo &umbrello;: Os Diagramas de Casos de Uso mostram os actores (as pessoas ou os outros utilizadores do sistema), os casos de utilização (os cenários em que eles usam o sistema) e as suas relações Os Diagramas de Classes mostram as classes e as relações entre elas Os Diagramas de Sequência mostram os objectos e uma sequência de chamadas de métodos que eles fazem a outros objectos. Os Diagramas de Colaboração mostram os objectos e as suas relações, colocando alguma ênfase nos objectos que participam na troca de mensagens Os Diagramas de Estados mostram os estados, as mudanças de estado e os eventos num objecto ou numa parte do sistema Os Diagramas de Actividades mostram as actividades e as mudanças de uma actividade para outra com os eventos a ocorrerem numa parte do sistema Os Diagramas de Componentes mostram os componentes de alto-nível de programação (como as KParts ou os Java Beans). Os Diagramas de Entradas em Produção mostram as instâncias dos componentes e as suas relações. Os Diagramas de Casos de Uso descrevem as relações e as dependências entre um grupo de Casos de Uso e os Actores que participam no processo. É importante reparar que os Diagramas de Casos de Uso não são adequados para representar o desenho e também não podem descrever os detalhes internos de um sistema. Os Diagramas de Casos de Uso pretendem facilitar a comunicação com os utilizadores futuros do sistema e com o cliente, e são especialmente úteis para determinar as funcionalidades necessárias que o sistema deverá ter. Os Diagramas de Casos de Uso indicam o que o sistema deverá fazer mas não devem — e não podem — especificar como isto deverá ser feito. Um exemplo de diagrama de Casos de Utilização. &umbrello; a mostrar um diagrama de Casos de Utilização &umbrello; a mostrar um diagrama de Casos de Utilização Um Caso de Utilização descreve — do ponto de vista dos actores — um grupo de actividades de um sistema que produzem um resultado concreto e tangível. Os Casos de Uso são descrições das interacções típicas entre os utilizadores de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um dado tipo de requisitos sobre o que o sistema tem de fazer (lembre-se, só 'o quê', não 'como'). Ao lidar com os Casos de Uso, é importante recordar algumas regras simples: Cada Caso de Utilização está relacionado com pelo menos um actor Cada Caso de Utilização tem um iniciador (ou seja, um actor) Cada Caso de Uso conduz a um resultado relevante (um resultados com valor de negócio) Os Casos de Uso também poderão ter relações com outros Casos de Uso. Os três tipos de relações mais típicos entre Casos de Uso são: <<include>> (incluir) que indica que um Caso de Uso toma lugar dentro de outro Caso de Uso <<extends>> (extende) que indica que, em certas situações ou numa dada altura (chamada de ponto de extensão), um Caso de Uso será extendido por outro. Generalization (generalização) indica que um Caso de Uso herda as características do Super-Caso de Uso e poderá implementar novamente algumas delas ou adicionar novas de uma forma semelhante à da herança de classes. Um actor é uma entidade externa (fora do sistema) que interage com o sistema ao participar (ou iniciar normalmente) um Caso de Uso. Os actores poderão ser pessoas reais (como, por exemplo, utilizadores do sistema), outros sistemas informáticos ou eventos exteriores. Os actores não representam as pessoas físicas ou os sistemas, mas sim o seu papel. Isto significa que, quando uma pessoa interage com o sistema de formas diferentes (assumindo papéis diferentes), ele será representado por vários actores. Por exemplo, uma pessoa que dá suporte ao cliente por telefone e que recebe encomendas do cliente para colocar no sistema seria representado por um actor Técnico de Suporte e por um actor Representante de Vendas As descrições dos Casos de Uso são narrativas textuais do Caso de Uso. Elas normalmente tomam a forma de uma nota ou de um documento que esteja associado de alguma forma ao Caso de Uso e explicam os processos ou actividades que tomam lugar no Caso de Uso. Os Diagramas de Classes mostram as diferentes classes que compõem um sistema e como elas se relacionam umas com as outras. Os Diagramas de Classes são apontados normalmente como estáticos porque mostram as classes, em conjunto com os seus métodos e atributos, assim como as relações estáticas entre elas, quais as classes que conhecem outras classes ou que fazem parte de outra classe, mas não mostram as chamadas de métodos entre elas. Um exemplo de um Diagrama de Classes O &umbrello; a mostrar um diagrama de Classes O &umbrello; a mostrar um diagrama de Classes Uma classe define os atributos e os métodos para um conjunto de objectos. Todos os objectos desta classe (as instâncias da mesma) partilham o mesmo comportamento e têm o mesmo conjunto de atributos (cada objecto tem o seu próprio conjunto). O termo Tipo é usado em algumas ocasiões em vez de Classe, mas é importante mencionar que os dois conceitos não são iguais e que o Tipo é um termo mais genérico. No &UML;, as Classes são representadas por rectângulos com o nome da classe, e poderão também mostrar os atributos e as operações da classe em outros dois compartimentos dentro do rectângulo. Uma Classe em &UML; Representação visual de uma Classe em &UML; Representação visual de uma Classe em &UML; No &UML;, os Atributos são mostrados como tendo o seu nome, pelo menos, e poderão mostrar também o seu tipo, o seu valor inicial e outras propriedades. Os atributos também poderão ser mostrados com a sua visibilidade: + Representa atributos públicos # Representa atributos protegidos - Representa atributos privados As operações (métodos) são também mostradas contendo pelo menos o seu nome e poderão também mostrar os seus parâmetros e tipos de valor devolvidos. As operações podem, assim como os Atributos, mostrar a sua visibilidade: + Corresponde a operações públicas # Corresponde a operações protegidas - Corresponde a operações privadas As Classes poderão ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é definido quando uma classe é iniciada (&ie; um objecto é criado). Os modelos existem como 'template' no C++ actual e serão introduzidos no Java 1.5 onde serão chamados de 'Generics'. Uma classe pode-se relacionar (ser associada) com outra qualquer de diferentes maneiras: A herança é um dos conceitos fundamentais da programação orientada por objectos, nos quais uma classe ganha todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias. No &UML;, uma associação por Generalização entre duas classes representa o conceito de herança entre uma classe de base e uma classe derivada. No &UML;, as Generalizações são representadas com uma linha que liga as duas classes, em que existe uma seta do lado da classe de base. Generalização Representação visual de uma generalização em &UML; Representação visual de uma generalização em &UML; Uma associação representa uma relação entre classes e dá a semântica e a estrutura comum para vários tipos de ligações entre os objectos. As associações são o mecanismo que permite aos objectos comunicarem uns com os outros. Descreve a ligação entre as diferentes classes (a ligação entre os objectos em si é chamada de ligação do objecto. As associações podem ter um papel que indica o objectivo da associação e pode ser unidireccionais ou bidireccionais (indica se os dois objectos que participam na relação poderão enviar mensagens um para o outro, ou se só um deles é que conhece o outro). Cada extremo da associação também tem um valor de multiplicidade, que define quantos objectos desse lado da associação poder-se-ão relacionar com um objecto do outro lado. No &UML;, as associações são representadas como linhas que ligam as classes que participam na relação e poderá também mostrar o papel e a multiplicidade de cada um dos participantes. A multiplicidade é mostrada como um intervalo [mín..máx] de valores não-negativos ou com um asterisco (*) no lado do máximo que representa o infinito. Associação &UML; Uma representação visual de uma associação em &UML; Uma representação visual de uma associação em &UML; As agregações são um tipo especial de associações nas quais as duas classes participantes não têm um estado igual, mas têm uma relação do 'todo' para as partes. Uma agregação diz como é que a classe que têm o papel do 'todo' é composta (ou tem) as outras classes, que têm o papel das partes. Para as agregações, a classe que actua como o 'todo' tem sempre uma multiplicidade de um. No &UML;, as agregações são representados por uma associação com um losango do lado do 'todo'. Agregação Uma representação visual de uma relação de agregação no &UML; Uma representação visual de uma relação de agregação no &UML; As composições são associações que representam agregações muito fortes. Isto significa que as composições formam também relações do 'todo' para as partes, mas a relação é tão forte que as partes não podem existir por si só. Elas só existem dentro do todo e se o todo for destruído, as partes desaparecem também. No &UML;, as Composições são representadas por um losango a cheio do lado do 'todo'. Composição Uma representação visual de uma relação de Composição no &UML; Os diagramas de classe poderão conter outros itens para além das classes. As interfaces são classes abstractas, o que significa que as instâncias não podem ser criadas directamente a partir delas. Elas poderão contem operações, mas não podem conter atributos. As classes podem herdar das interfaces (através de uma relação de realização) e as instâncias poderão então ser compostas a partir dessas classes. Os tipos de dados são primitivas que vêm tipicamente incorporadas numa linguagem de programação. Os exemplos comuns incluem os inteiros e os booleanos. Eles não poderão ter relações com as classes, mas as classes poderão ter relações com eles. Os enumerados são uma lista simples de valores. Um exemplo típico são os enumerados para os dias da semana. Como os tipos de dados, os enumerados não poderão ter relações com as classes, mas as classes poderão ter relações com eles. Os pacotes representam um espaço de nomes numa linguagem de programa. Num diagrama, eles são usados para representar partes de um sistema que contém mais do que uma classe, podendo ser mesmo centenas de classes. Os Diagramas de Sequência mostram a troca de mensagens (&ie; as chamadas aos métodos) entre os vários objectos numa situação específica delimitada no tempo. Os objectos são instâncias das classes. Os Diagramas de Sequência colocam uma ênfase especial na ordem e nas alturas em que as mensagens são enviadas para os objectos. Nos Diagramas de Sequência, os objectos são representados através de linhas tracejadas verticais, com o nome do objecto no topo. O eixo do tempo também é vertical, e vai aumentando de cima para baixo, de modo a que as mensagens sejam enviadas de um objecto para outro, sob o formato de setas com o nome da operação e dos parâmetros. Diagrama de Sequência O &umbrello; a mostrar um Diagrama de Sequência O &umbrello; a mostrar um Diagrama de Sequência As mensagens tanto podem ser síncronas, o que acontece normalmente nas chamadas de mensagens quando o controlo é passado para o objecto que é invocado até que esse método termine a sua execução, ou poderão também ser assíncronas, onde o controlo é passado de volta directamente para o objecto que invoca o método. As mensagens síncronas têm uma caixa vertical do lado do objecto que é chamado para mostrar o fluxo de controlo do programa. Os Diagramas de Colaboração mostram as interacções entre os objectos que participam numa dada situação. Esta é mais ou menos a mesma informação que é mostrada pelos Diagramas de Sequência, mas existe também uma ênfase posta sobre como as interacções ocorrem no tempo, enquanto que os Diagramas de Colaboração colocam as relações entre os seus objectos e a sua topologia em primeiro plano. Nos Diagramas de Colaboração, as mensagens enviadas de um objecto para o outro são representadas por setas que mostram o nome da mensagem, os parâmetros e a sequência da mensagem. Os Diagramas de Colaboração são particularmente adequados a mostrar um fluxo específico de um programa ou situação, e são uns dos melhores tipos de diagramas para demonstrar ou explicar rapidamente um processo na lógica do programa. Colaboração O &umbrello; a mostrar um Diagrama de Colaboração O &umbrello; a mostrar um Diagrama de Colaboração Os Diagramas de Estados mostram os diferentes estados de um objecto durante a sua vida, bem como os estímulos que fazem com que o objecto mude o seu estado. Os Diagramas de Estados vêem os objectos como máquinas de estados ou autónomos finitos que poderão estar num estado pertencente a uma lista de estados finitos e que poderão mudar o seu estado através de um estímulo pertencente a um conjunto finito de estímulos. Por exemplo, um objecto do tipo ServidorRede poderá estar num dos seguintes estados durante a sua vida: Pronto À espera A trabalhar Parado e os eventos que poderão fazer com que o Objecto mude de estado são O objecto é criado O objecto atende a mensagem Um cliente pede uma ligação pela rede Um cliente termina um pedido O pedido é executado e terminado O objecto recebe a mensagem parar etc Diagrama de Estado O &umbrello; a mostrar um Diagrama de Estado O &umbrello; a mostrar um Diagrama de Estado Os estados são os blocos de construção dos Diagramas de Estado. Um estado pertence a exactamente uma classe e representa um resumo dos valores que os atributos de uma classe poderão obter. Um Estado no &UML; descreve o estado interno de um objecto de uma determinada classe Tenha em atenção que nem todas as alterações de um atributo de um objecto deverão ser representadas por um estado, mas só mesmo aquelas alterações que poderão afectar significativamente o funcionamento do objecto Existem dois tipos especiais de Estados: o Inicial e o Final. Eles são especiais na medida em que não existe nenhum evento que possa fazer um objecto voltar ao seu estado inicial, da mesma forma que não há nenhum evento que possa retirar um objecto do seu estado final, logo que o tenha atingido. Os Diagramas de Actividades descrevem a sequência de actividades de um sistema, com a ajuda das Actividades propriamente ditas. Os Diagramas de Actividades são um tipo especial de Diagramas de Estados, que só (ou em grande parte) contêm Actividades. Um exemplo de Diagrama de Actividades. O &umbrello; a mostrar um Diagrama de Actividade O &umbrello; a mostrar um Diagrama de Actividade Os Diagramas de Actividades são semelhantes aos fluxogramas procedimentais, com a diferença que todas as Actividades estão claramente associadas a objectos. Os Diagramas de Actividades estão sempre associados a uma Classe, uma Operação ou um Caso de Uso. Os Diagramas de Actividades suportam as Actividades sequências, assim como as paralelas. A execução paralela é representada através de ícones de 'Fork' (Bifurcação) ou 'Wait' (Espera) e, para as actividades que decorrem em paralelo, não é importante a ordem pela qual são desempenhadas (elas poderão ser executadas ao mesmo tempo ou uma a seguir à outra) Uma Actividade é um passo único num processo. Uma Actividade é um estado no sistema com actividade interna e, pelo menos, uma transição de saída. As Actividades também poderão conter mais do que uma transição de saída se tiverem diferentes condições. As Actividades poderão formar hierarquias, o que significa que uma Actividade poderá ser composta por várias Actividades de detalhe, onde nesse caso as transições de entrada e de saída deverão corresponder às transições de entrada e de saída do diagrama de detalhe. Existem alguns elementos no &UML; que não têm nenhum valor semântico real para o modelo, mas que ajudam a clarificar partes do diagrama. Esses elementos são Linhas de texto Notas de Texto e âncoras Caixas As linhas de texto são úteis para adicionar algumas informações textuais breves para um diagrama. Correspondem a texto livre e não têm nenhum significado para o modelo em si. As notas são úteis para adicionar informações mais detalhada sobre um objecto ou uma dada situação. Têm a grande vantagem de poderem ser anexadas a Elementos de &UML; para mostrar que a nota pertence a um dado objecto ou situação. As caixas são rectângulos livres que poderão ser usados para agrupar os itens em conjunto para tornar os diagramas mais legíveis. Elas não têm significado lógico no modelo. Os Diagramas de Componentes mostram os componentes do 'software' (sejam referentes a tecnologias de componentes como os KParts, os componentes do CORBA ou Java Beans, ou mesmo secções do sistema que sejam claramente distintas), bem como os artefactos de que são compostos, como os ficheiros de código-fonte, as bibliotecas de programação ou as tabelas de bases de dados relacionais. Os componentes poderão ter interfaces (&ie; classes abstractas com operações) quer permitem associar os componentes. Os Diagramas de Entrada em Produção mostram as instâncias em execução, bem como as suas associações. Eles incluem os Nós, que são recursos físicos, correspondendo tipicamente a um único computador. Mostram também as interfaces e os objectos (as instâncias das classes).