UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 2 Índice n Introdução O que é a UML? Valor da UML Origens da UML Parceiros da UML n Modelos e diagramas n Elementos de modelação n Diagramas Diagrama de casos de utilização Diagrama de classes Diagrama de objectos Diagrama de componentes Diagrama de distribuição Diagrama de sequência Diagrama de colaboração Diagrama de estados Diagrama de actividades n Referências

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 3 O que é a UML? n UML = Unified Modeling Language n UML é uma linguagem (notação com semântica associada) para visualizar especificar construir documentar os artefactos de um sistema com uma componente intensiva de software (software intensive system) n UML não é uma metodologia não diz quem deve fazer o quê, quando e como UML pode ser usado segundo diferentes metodologias, tais como RUP (Rational Unified Process), FDD (Feature Driven Development), etc. n UML não é uma linguagem de programação

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 4 Valor da UML n É um standard aberto versão 1.1 aprovada pelo OMG (Object Management Group) em Novembro de 1997 versão 1.3 aprovada em Junho de 1999 n Suporta todo o ciclo de vida do software modelação do negócio (processos e objectos do negócio) modelação de requisitos alocados ao software modelação da solução de software n Suporta diversas áreas de aplicação n É baseado na experiência e necessidades da comunidade de utilizadores n É suportado por muitas ferramentas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 5 Booch Booch method Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Embley Singleton classes and high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Jacobson OOSE Origens da UML

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 6 Parceiros da UML n Rational Software Corporation n Hewlett-Packard n I-Logix n IBM n ICON Computing n Intellicorp n MCI Systemhouse n Microsoft n ObjecTime n Oracle n Platinum Technology n Taskon n Texas Instruments/Sterling Software n Unisys

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 7 Modelos e Diagramas n Um modelo é uma representação em pequena escala, numa perspectiva particular, de um sistema existente ou a criar Atitude de abstracção (omissão de detalhes) fundamental na construção de um modelo Modelos são a linguagem por excelência do projectista (designer) Modelos são veículos para comunicação com vários interessados (stakeholders) Modelos permitem raciocinar acerca do sistema real, sem o chegar a construir n Ao longo do ciclo de vida de um sistema são construídos vários modelos, sucessivamente refinados e enriquecidos n Um modelo é constituído por um conjunto de diagramas (desenhos) consistentes entre si, acompanhados de descrições textuais dos elementos que aparecem nos vários diagramas Um diagrama é uma vista sobre um modelo O mesmo elemento (exemplo: classe) pode aparecer em vários diagramas de um modelo n No UML, há nove diagramas standard Diagramas de visão estática: casos de utilização (use case), classes, objectos, componentes, distribuição (deployment) Diagramas de visão dinâmica: sequência, colaboração, estados (statechart), actividades

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 8 Modelos e Diagramas Use Case Diagrams Use Case Diagrams Diagramas de Casos de Utilização Scenario Diagrams Scenario Diagrams Diagramas de Colaboração State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Distribuição State Diagrams State Diagrams Diagramas de Objectos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Sequência State Diagrams State Diagrams Diagramas de Classes Diagramas de Actividades Modelos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 9 Elementos de Modelação (1) n Elementos estruturais classe, interface, colaboração, caso de utilização, classe activa, componente, nó Fonte: Grady Booch n Elementos de comportamento interacção, máquina de estados n Elementos de agrupamento pacote (package), subsistema n Outros elementos nota

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 10 Elementos de Modelação (2) n Relações Dependência Associação Generalização Concretização (realization) n Mecanismos de extensibilidade Estereótipos Propriedades (tagged values) Restrições (constraints) Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 11 Diagrama de Casos de Utilização (Use Case Diagram) n Captura a funcionalidade do sistema tal como é visto pelos utilizadores n Construído nos primeiros estágios do desenvolvimento n Objectivo Especificar o contexto de um sistema Capturar os requisitos funcionais de um sistema Validar a arquitectura de um sistema Dirigir a implementação e gerar casos de teste n Desenvolvido por analistas e especialistas de domínio

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 12 Diagrama de Casos de Utilização (Use Case Diagram) Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 13 Diagrama de Classes n Captura o vocabulário de um sistema n Construído e refinado ao longo do desenvolvimento n Objectivo Nomear e modelar conceitos no sistema Especificar colaborações Especificar esquemas lógicos de bases de dados n Desenvolvido por analistas, designers e implementadores

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 14 Diagrama de Classes Fonte: Grady Booch composition

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 15 Diagrama de Objectos n Mostra objectos (instâncias de classes) e ligações (instâncias de associações) n Construído durante a análise e design n Objectivo Ilustrar estruturas de dados/objectos Especificar instantâneos (snapshots) n Desenvolvido por analistas, designers e implementadores

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 16 Diagrama de Objectos Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 17 Diagrama de Componentes n Captura a estrutura física da implementação (tipicamente ficheiros) n Construído como parte da especificação da arquitectura n Objectivo Organizar o código fonte Construir uma release executável Especificar uma base de dados física n Desenvolvido por arquitectos e programadores

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 18 Diagrama de Componentes Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 19 Diagrama de Distribuição (Deployment Diagram) n Captura a topologia do hardware de um sistema n Construído como parte da especificação da arquitectura n Objectivo Especificar a distribuição de componentes Identificar estrangulamentos de desempenho n Desenvolvido por arquitectos, engenheiros de redes, e engenheiros de sistemas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 20 Diagrama de Distribuição (Deployment Diagram) Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 21 Diagrama de Sequência n Captura comportamento dinâmico (orientado ao tempo) n Objectivo Modelar fluxos de controlo Ilustrar cenários típicos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 22 Diagrama de Sequência Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 23 Diagrama de Colaboração n Captura comportamento dinâmico (orientado a mensagens) n Objectivo Modelar fluxo de controlo Ilustrar a coordenação entre estrutura de objectos e controlo

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 24 Diagrama de Colaboração Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 25 Diagrama de Estados (Statechart Diagram) n Captura comportamento dinâmico (orientado a eventos) n Objectivo Modelar ciclo de vida de objectos Modelar objectos reactivos (interfaces com o utilizador, dispositivos, etc.)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 26 Diagrama de Estados (Statechart Diagram) Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 27 Diagrama de Actividades n Captura comportamento dinâmico (orientado a actividades) n Objectivo Modelar processos de negócio e workflows Modelar operações (algoritmos)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 28 Diagrama de Actividades Fonte: Grady Booch

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 29 Referências n Ferramentas de modelação visual Rational Rose (www.rational.com)www.rational.com Together (www.togethersoft.com)www.togethersoft.com Platinum Paradigm Plus (www.platinum.com)www.platinum.com Microsoft Visio Mais ferramentas em www.objectsbydesign.com n Livros The Unified Modeling Language User Guide, Grady Booch et al, Addison- Wesley, October, 1998 UML, Metodologias e Ferramentas CASE, Alberto Silva e Carlos Videira, Centro Atlântico, 2001 n Especificações www.uml.org

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 30 UML - Diagramas de Casos de Utilização (Use Case Diagrams)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 31 Objectivo n Um diagrama de casos de utilização de um sistema mostra actores (tipos de utilizadores), casos de utilização e relações entre eles Fundamental acompanhar de descrições textuais de casos de utilização n Permite: mostrar para que serve o sistema (a utilidade do sistema), ignorando a forma como está organizado internamente especificar o contexto do sistema -com quem interage (actores) e com que finalidade (casos de utilização) capturar os requisitos funcionais do sistema -casos de utilização são funcionalidades do sistema vistas pelos utilizadores n Pode referir-se a um sistema de software, um sistema de negócio ou organização, um equipamento, uma classe, etc. n É elaborado por analistas e especialista de domínio nos primeiros estágios do desenvolvimento

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 32 As três perspectivas de um sistema n Casos de utilização para que serve o sistema (utilidade) num vídeo-gravador: reproduzir cassete, gravar cassete nem sempre evidente a partir da observação do interface! um caso de utilização engloba uma sequência de interacções com elementos da interface, para atingir resultado útil (produto ou serviço) para o utilizador! n Interface sistema como caixa preta o que é visível na fronteira do sistema (estrutura e funcionamento) num vídeo-gravador: teclas, visor, abertura para cassete, tomadas n Implementação sistema como caixa branca acrescenta o que está escondido (estrutura e funcionamento) num vídeo-gravador: motor, cabeças de gravação, sintonizador,...

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 33 Exemplo 1: Telemóvel (equipamento) Telemóvel nome do sistema fronteira do sistema actor caso de utilização associação de comunicação entre actor e caso de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 34 Exemplo 2: Restaurante (negócio) Cliente Servir almoço Fornecedor Restaurante Servir jantar Comprar bens casos de utilização primários - servem directamente clientes caso de utilização secundário - não serve directamente clientes - envolve interacção com o exterior - serve casos de utilização primários - tem valor para o fornecedor - utilizador ou utilizado? - o que importa é que interage com o sistema!

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 35 Exemplo 3: Aplicação de Gestão de Restaurantes (software) Empregado de mesa Registar pedido Aplicação de Gestão de Restaurantes Emitir factura Cozinheiro A mesma coisa para o sistema de informação do restaurante (hardware+software)!

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 36 Actores n Actor = papel (role) Um actor em relação a um sistema é um papel que alguém ou alguma coisa do ambiente envolvente desempenha quando interage com o sistema n Actor = classe classes são frequentemente usadas para modelar papéis que objectos individuais podem desempenhar n Actor = tipo de utilizador (em sentido lato) pode ser uma pessoa ou outro sistema pode utilizar ou ser utilizado, o que interessa é que interage com o sistema n Actor  recurso do sistema recursos são pessoas, máquinas, etc. que pertencem ao sistema e que são usados para levar a cabo tarefas dentro do sistema n Actor  indivíduo o mesmo indivíduo pode interagir com o sistema em vários papéis (como cliente, como fornecedor, etc.) Cliente ou «actor» Cliente

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 37 Casos de utilização n Definição: Um caso de utilização é uma descrição de um conjunto de sequências de acções (1), incluindo variantes (2), que um sistema realiza (3) para produzir um resultado observável com valor para um actor (4,5) (1) a definição dá ênfase à sequência (modo) de funcionamento, mas este detalhe só surge numa 2ª iteração, depois de se ter alguma ideia do interface do sistema (2) a sequência concreta de acções pode variar de instância para instância do caso de utilização (3) interessam-nos mais as acções do sistema, pois são essas que temos de implementar, mas também interessa descrever as acções do actor (5) é esta utilidade ou objectivo que importa descrever numa 1ª iteração (6) o resultado pode ser um produto, um serviço, etc. n Mais simplesmente, um caso de utilização é: uma funcionalidade do sistema vista pelos utilizadores um tipo de interacção (de alto nível) entre actores e o sistema Servir almoço ou Servir almoço

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 38 Descoberta dos casos de utilização n Pensar em cada actor e nas interacções que tem com o sistema n Um caso de utilização agrupa interacções elementares de actores com elementos da interface do sistema, mas qual deve ser o nível de agrupamento? n Caso de utilização simples: utilização de funcionalidade de grão mais fino possível que, uma vez implementada, acrescenta valor (do ponto de vista dos utilizadores) ao sistema que está a ser desenvolvido Exemplo no multibanco: -"introduzir cartão" não é um caso de utilização porque não tem valor isoladamente -"levantar dinheiro" é um caso de utilização porque tem valor para o detentor do cartão O caso de utilização inclui todas as acções a montante (de preparação) e a jusante (de finalização) necessárias (numa relação de um para um) à produção do resultado -Levantamento no multibanco, vai desde a introdução do cartão até à recolha do cartão, do talão e do dinheiro n Caso de utilização composto: combinação de casos de utilização mais simples modelar apenas quando importa automatizar

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 39 Descrição dos casos de utilização n 3 níveis de detalhe, de acordo com as 3 perspectivas de um sistema n 1º) essência / utilidade descrição breve independente da interface que o sistema apresenta descrever o objectivo ou resultado a produzir opcionalmente, indicar lista de features e limitações (nível de requisitos) n 2º) interface descrição de sequências de funcionamento normais e excepcionais, em termos de interacções dos actores com elementos da interface opcionalmente, acompanhar de desenhos da interface para o utilizador e de diagramas dinâmicos indicar quando é que o caso de utilização começa e acaba, quando ocorrem interacções com os actores, que objectos são trocados, quem faz o quê (o sistema ou um actor) pode ser aproveitado para o no manual do utilizador n 3º) implementação realização do caso de utilização por uma colaboração de objectos internos ao sistema sequências de funcionamento detalhadas com (inter)acções internas ao sistema já não compete ao analista, mais sim ao projectista/implementador já não faz parte do modelo de casos de utilização, mas sim do modelo de design

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 40 Exemplo: descrição do caso de utilização "servir almoço" n Objectivo: servir uma refeição rápido a um cliente que se dirige ao restaurante ao almoço n Features e limitações: há dois pratos do dia pré-confeccionados, um de carne e outro de peixe, e uma lista fixa de pratos de preparação rápida não se fazem reservas n Sequência normal de funcionamento: o cliente chega ao restaurante e senta-se numa mesa vaga o empregado entrega ao cliente uma folha com o menu do dia o cliente indica ao empregado o prato e bebida pretendidos o empregado transmite o pedido do prato à cozinha o empregado entrega a bebida ao cliente assim que está pronto, o empregado entrega o prato pedido ao cliente o cliente pede a conta o empregado faz a conta e entrega-a ao cliente o cliente paga a conta à saída n Sequência de funcionamento excepcional: Quando o restaurante está cheio, os clientes que chegam ao restaurante formam fila à entrada e o empregado vai chamando os clientes para as mesas há medida que vão vagando

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 41 Casos de utilização e o processo de desenvolvimento n Casos de utilização guiam o planeamento Cada iteração do processo de desenvolvimento deve analisar detalhadamente e implementar um conjunto de casos de utilização ou variantes de casos de utilização Cada iteração resultará num incremento ao produto com utilidade para o cliente Começar pelos casos de utilização ou variantes mais prioritários ou com mais risco n Casos de utilização guiam a captura e especificação de requisitos Casos de utilização definem implicitamente requisitos funcionais Alguns requisitos não funcionais podem também ser alocados a casos de utilização Em sistemas simples, dispensam definição prévia de uma lista de requisitos n Casos de utilização guiam o desenho do sistema Arquitectura (forma) do sistema (divisão em módulos e definição dos seus interfaces e dependências) é condicionada pelos casos de utilização (função) e requisitos adicionais A implementação de cada caso de utilização sobre essa arquitectura é modelada por uma colaboração de objectos, combinando estrutura e comportamento n Casos de utilização guiam o teste do sistema Casos de teste de "caixa preta" desenhados a partir dos casos de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 42 Aplicação a sistemas de negócio n Actores modelam clientes, fornecedores, parceiros, etc. n Casos de utilização modelam processos de negócio processos de negócio primários: servem directamente clientes processos de negócio secundários: não servem directamente clientes, mas envolvem interacção com o exterior e servem processos de negócio primários n Nem todas as actividades de um sistema de negócio se podem englobar em processos de negócio, numa definição estrita caso das actividades que não estão relacionadas, mesmo que indirectamente, com um actor individual essas actividades são englobadas em processos de suporte internos processos de gestão de recursos, planeamento, controlo, etc. n Processos de negócio e de suporte são relacionados e detalhados através de diagramas de actividades, até chegar a actividades que podem ser atribuídas a trabalhadores ou equipas individuais

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 43 Estruturação dos diagramas de casos de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 44 Formas de estruturar n Relação “extend” entre casos de utilização n Relação “include” entre casos de utilização n Relação de generalização entre casos de utilização n Relação de generalização entre actores n Agrupamento de casos de utilização em pacotes de casos de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 45 Relação “extend” entre casos de utilização n Para simplificar a descrição dos casos de utilização, podem-se organizar os casos de utilização em casos básicos (casos de utilização de acordo com a definição) e extensões aos casos básicos, que traduzem partes ou modalidades acrescentadas condicionalmente (opções) n Significado: uma instância do caso de utilização A pode incluir (sujeito a condições especificadas na extensão) o comportamento especificado por B o caso básico deve fazer sentido sozinho os actores interagem com o caso básico (A) n Em software, corresponde normalmente a seguir um botão ou um link num formulário que desencadeia uma acção ou dá acesso a outro formulário ou relatório A B «extend» extensão caso básico

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 46 n Exemplo: n Podem-se indicar explicitamente os pontos em que um caso de utilização básico pode ser estendido (pontos de extensão) Na descrição textual do caso básico:.... (sobremesa).... Servir uma sobremesa Servir jantar Extension points sobremesa «extend» (sobremesa) Servir uma entrada Servir jantar Servir uma sobremesa Servir à luz de velas «extend» Relação “extend” entre casos de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 47 Relação “extend” entre casos de utilização Modificar Disciplina Visualizar Lista de Disciplinas Adicionar Disciplina Eliminar Disciplina «extend» Visualizar Ficha de Disciplina «extend» Manutenção da Lista de Disciplinas: «extend»

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 48 Relação “include” entre casos de utilização (1) n Quando vários casos de utilização têm uma sub-sequência de funcionamento comum, é conveniente separar essa parte comum para um novo caso de utilização que é incluído pelos primeiros n Notação: n Significado uma instância do caso de utilização A inclui obrigatoriamente o comportamento especificado por B os actores interagem com A na descrição textual de A: include(B) A B (parte comum a outros casos de utilização além de A) «include»

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 49 Relação “include” entre casos de utilização (2) n Exemplo: Servir almoço Servir jantar Pagar refeição «include»

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 50 Relação de generalização entre casos de utilização n Relação de generalização: entre uma coisa mais genérica e uma coisa mais especializada n Significa que o caso de utilização "filho" (mais especializado) herda o comportamento, significado e actores do caso de utilização "pai" (mais genérico) O filho pode adicionar ou substituir comportamento do pai O filho pode aparecer em qualquer contexto em que o pai pode aparecer n Notação: mesmo que generalização entre classes n Exemplo: Servir uma refeição Servir almoço Servir jantar

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 51 Relação de generalização entre actores n Exemplo: Um cliente empresarial é um (is a) cliente O cliente empresarial herda as associações (de comunicação com casos de utilização) do cliente genérico Permite simplificar e estruturar os diagramas Cliente Cliente Empresarial

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 52 Pacotes de casos de utilização n Num sistema complexo, podem existir demasiados casos de utilização para visualizar com clareza num único diagrama! n Uma solução: um diagrama de casos de utilização inicial, com pacotes de casos de utilização, e um diagrama de casos de utilização relativo a cada pacote n Critérios de agrupamento de casos de utilização em pacotes: -por actores -por sub-sistemas n Pacotes de casos de utilização correspondem normalmente a menus em sistemas de software

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 53 Exemplo: Restaurante «extend» Servir almoço Pagar refeição «include» Cliente Fornecedor Restaurante Servir uma refeição Servir jantar Servir à luz de velas Servir uma sobremesa Servir uma entrada Comprar bens

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 54 Exemplo: Sistema de Gestão de Restaurantes Sist. de Gestão de Restaurantes (SGR) Empregado de mesa Relação com Fornecedores Relação com Clientes Empregado de caixa Cozinheiro

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 55 Exemplo: SGR (2) SGR – Relação com Clientes Cozinheiro Elaborar menu do dia Tirar a conta Pagar a conta Empregado de mesa Registar pedido Empregado da caixa

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 56 Exemplo: SGR (3) SGR – Relação com Fornecedores Cozinheiro Registar compra Preparar encomenda

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 57 Caso de Estudo: n Transportes Urbanos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 58 Objectivo n Modelar uma empresa de transportes urbanos cuja missão é transportar passageiros ao longo de carreiras pré-definidas, entre paragens, com horários estabelecidos, usando veículos guiados por motoristas, cobrando bilhetes ou usando títulos de transporte n Tratando-se de uma empresa moderna, possui sistemas de seguimento dos veículos o que permite monitorizar o cumprimento dos horários e fornecer informação aos passageiros não só sobre os horários mas sobre o tempo que demora efectivamente um veículo a atingir uma paragem

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 59 Caso de Estudo: Sistema de Informação de uma Biblioteca

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 60 Objectivo n Pretende-se projectar o Sistema de Informação de uma Biblioteca (SIB), para apoiar as seguintes actividades: gestão de aquisições de publicações -registar a aquisição gestão de consultas e fotocópias de publicações dentro da biblioteca -interessa contar o nº de vezes que cada publicação foi consultada consulta da base de dados de publicações (público e empregados) gestão de sócios -inscrição, renovação, cancelamento gestão de requisições -só os sócios podem requisitar publicações -requisição com levantamento, devolução

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 61 Metodologia n Captura e especificação de requisitos: listar requisitos candidatos construir um modelo de casos de utilização da biblioteca detalhar casos de utilização da biblioteca através de diagramas de actividades, identificando as actividades automatizadas com recurso ao SIB e os trabalhadores envolvidos construir um modelo de domínio construir um glossário de conceitos de domínio construir um modelo de casos de utilização do SIB (sistema de software) detalhar alguns casos de utilização da SIB através de diagramas de sequência -sistema representado por um único objecto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 62 Diagrama de casos de utilização da biblioteca Biblioteca

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 63 Actores em relação à biblioteca n Leitor Pessoa que se dirige à biblioteca para consultar publicações, sendo ou não sócio da biblioteca. n Sócio Leitor que está inscrito como sócio da biblioteca. n Fornecedor Empresa a quem a biblioteca adquire publicações.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 64 Casos de utilização da biblioteca n Consultar base de dados de publicações Consultar a base de dados com a lista de publicações existentes na biblioteca, incluindo informação sobre o estado das publicações. n Consultar publicação O leitor consulta a publicação dentro das instalações da biblioteca. Para fins de gestão, é mantido um contador do número de vezes que cada publicação é consultada dentro da biblioteca. n Obter cópia de publicação O leitor pode tirar fotocópias de partes de publicações numa fotocopiadora da biblioteca. n Requisitar publicação A biblioteca empresta uma publicação a um sócio para consulta no exterior da biblioteca mediante uma requisição. Envolve dois contactos com a biblioteca, para o levantamento e a devolução da publicação. n Adquirir publicação A biblioteca adquire livros a fornecedores.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 65 Diagrama de casos de utilização do SIB Sistema de Informação da Biblioteca (SIB)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 66 Actores em relação ao SIB n Leitor Pessoa que se dirige à biblioteca para consultar publicações, sendo ou não sócio da biblioteca. n Funcionário Empregado da biblioteca que atende os leitores e sócios. n Gestor Empregado da biblioteca que trata das aquisições de publicações e consulta estatísticas de utilização.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 67 Casos de utilização do SIB (1) n Consultar base de dados de publicações Consultar a base de dados com a lista de publicações existentes na biblioteca, incluindo informação sobre o estado das publicações. n Registar sócio Inscrever leitor como sócio da biblioteca. n Registar levantamento de publicação Registar o levantamento de uma publicação por um sócio (empréstimo da publicação ao sócio). n Registar devolução de publicação Registar a devolução à biblioteca de uma publicação que estava emprestada por um sócio.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 68 Casos de utilização do SIB (2) n Registar consulta de publicação Registar que uma publicação foi consultada por um leitor dentro da biblioteca. Não é necessário identificar o leitor. n Registar publicação Registar publicação já existente (na instalação do sistema) ou adquirida. n Obter estatísticas de utilização Obter estatísticas sobre a taxa de utilização das várias publicações, úteis para a aquisição de novas publicações.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 69 Exercícios n Para um caso prático: Definir o âmbito do sistema em análise Identificar os actores envolvidos Identificar os casos de utilização do negócio Relacionar os casos de utilização entre si, quando apropriado Descrever os casos de utilização em forma textual

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 70 UML – Diagramas de Classes

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 71 Índice n Objectivo dos diagramas de classes Objectivo dos diagramas de classes n Objectos, classes, atributos e operações Objectos, classes, atributos e operações n Relações entre classes: associação, agregação e composição Relações entre classes: associação, agregação e composição n Relações entre classes: generalização Relações entre classes: generalização n Relações entre classes: dependência e concretização Relações entre classes: dependência e concretização n Restrições, elementos derivados, pré-condições e pós- condições Restrições, elementos derivados n Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes e utilitários

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 72 Objectivo dos diagramas de classes n Um diagrama de classes serve para modelar o vocabulário de um sistema, do ponto de vista do utilizador/problema ou do implementador/solução Ponto de vista do utilizador/problema – na fase de captura e análise de requisitos, em paralelo com a identificação dos casos de utilização Vocabulário do implementador/solução – na fase de projecto (design) n Construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projectistas (designers) e implementadores n Também serve para: Especificar colaborações (no âmbito de um caso de utilização ou mecanismo) Especificar esquemas lógicos de bases de dados Especificar vistas (estrutura de dados de formulários, relatórios, etc.) n Modelos de objectos de domínio, negócio, análise e design

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 73 Objectos, classes, atributos e operações

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 74 Objectos n Um objecto é algo com fronteiras bem definidas, n relevante para o problema em causa, n com estado, modelado por valores de atributos (tamanho, forma, peso, etc.) e por ligações que num dado momento tem com outros objectos n comportamento um objecto exibe comportamentos invocáveis (por resposta a chamadas de operações) ou reactivos (por resposta a eventos) n e identidade no espaço: é possível distinguir dois objectos mesmo que tenham o mesmo estado -exemplo: podemos distinguir duas folhas de papel A4, mesmo que tenham os mesmos valores dos atributos no tempo: é possível saber que se trata do mesmo objecto mesmo que o seu estado mude -exemplo: se pintarmos um folha de papel A4 de amarelo, continua a ser a mesma folha de papel

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 75 Objectos do mundo real e objectos computacionais n No desenvolvimento de software orientado por objectos, procura- se imitar no computador o mundo real visto como um conjunto de objectos que interagem entre si n Muitos objectos computacionais são imagens de objectos do mundo real n Dependendo do contexto (análise ou projecto) podemos estar a falar em objectos do mundo real, em objectos computacionais ou nas duas coisas em simultâneo n Exemplos de objectos do mundo real: o Sr. João a aula de ES no dia 11/10/2000 às 11 horas n Exemplos de objectos computacionais: o registo que descreve o Sr. João (imagem de objecto do mundo real) uma árvore de pesquisa binária (objecto puramente computacional)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 76 Classes (1) n No desenvolvimento de software OO, não nos interessam tanto os objectos individuais mas sim as classes de objectos n Uma classe é um descritor de um conjunto de objectos que partilham as mesmas propriedades (semântica, atributos, operações e relações) Trata-se de uma noção de classe em compreensão, no sentido de tipo de objecto, por oposição a uma noção de classe em extensão, como conjunto de objectos do mesmo tipo n Um objecto de uma classe é uma instância da classe n A extensão de uma classe é o conjunto de instâncias da classe n Em Matemática, uma classe é um conjunto de “objectos” com uma propriedade em comum, podendo ser definida indiferentemente em compreensão ou em extensão C = {x  | N : x mod 3 = 2} = {2, 5, 8, 11, 14,...}

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 77 Classes (2) n O conjunto de todos os objectos num determinado contexto forma um universo (UoD - Universe of Discourse) n As extensões das classes são subconjuntos desse universo UoD x João x Rui x Maria Aluno Curso x Electrotecnia x Informática objecto x Dª Rita x Sr. Silva Funcionário classe ligação

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 78 Classes (3) n Classes podem representar: Coisas concretas: Pessoa, Turma, Carro, Imóvel, Factura, Livro Papéis que coisas concretas assumem: Aluno, Professor, Piloto Eventos: Curso, Aula, Acidente Tipos de dados: Data, Intervalo de Tempo, Número Complexo, Vector n Decomposição orientada por objectos : começa por identificar os tipos de objectos (classes) presentes num sistema contrapor com decomposição funcional ou algorítmica tipos de objectos são mais estáveis do que as funções, logo a decomposição orientada por objectos leva a arquitecturas mais estáveis

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 79 Classes (4) n Em UML, uma classe é representada por um rectângulo com o nome da classe n Habitualmente escreve-se o nome da classe no singular (nome de uma instância), com a 1ª letra em maiúscula n Para se precisar o significado pretendido para uma classe, deve- se explicar o que é (e não é...) uma instância da classe Exemplo: “Um aluno é uma pessoa que está inscrita num curso ministrado numa escola. Uma pessoa que esteve no passado inscrita num curso, mas não está presentemente inscrita em nenhum curso, não é um aluno.” Em geral, o nome da classe não é suficiente para se compreender o significado da classe AlunoCurso

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 80 Atributos de instância n O estado de um objecto é dados por valores de atributos (e por ligações que tem com outros objectos) n Todos os objectos de uma classe são caracterizados pelos mesmos atributos (ou variáveis de instância) o mesmo atributo pode ter valores diferentes de objecto para objecto n Atributos são definidos ao nível da classe, enquanto que os valores dos atributos são definidos ao nível do objecto n Exemplos: uma pessoa (classe) tem os atributos nome, data de nascimento e peso João (objecto) é uma pessoa com nome “João Silva”, data de nascimento “18/3/1973” e peso “68 Kg”

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 81 Atributos de instância n Atributos são listados num compartimento de atributos (opcional) a seguir ao compartimento com o nome da classe n Uma classe não deve ter dois atributos com o mesmo nome n Os nomes dos tipos não estão pré-definidos em UML, podendo-se usar os da linguagem de implementação alvo Pessoa nome: string data de nascimento: date peso: real = 75 kg compartimento de atributos valor inicial por omissão classe tipo de dados nome do atributo

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 82 Operações de instância n Comportamento invocável de objectos é modelado por operações uma operação é algo que se pode pedir para fazer a um objecto de uma classe n Objectos da mesma classe têm as mesmas operações n Operações são definidos ao nível da classe, enquanto que a invocação de uma operação é definida ao nível do objecto n Princípio do encapsulamento: acesso e alteração do estado interno do objecto (valores de atributos e ligações) controlado por operações n Nas classes que representam objectos do mundo real é mais comum definir responsabilidades em vez de operações Pessoa nome: string morada: string setMorada(novaMorada:string): bool compartimento de operações

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 83 Atributos e operações estáticos (  de instância) n Atributo estático: tem um único valor para todas as instâncias (objectos) da classe valor está definido ao nível da classe e não ao nível das instâncias n Operação estática: não é invocada para um objecto específico da classe n Notação: nome sublinhado n Correspondem a membros estáticos (static) em C++, C# e Java Factura número: Long data: Date valor: Real últimoNumero: Long = 0 criar(data:Date, valor:Real) destruir() valorTotal(): Real retorna a soma dos valores de todas as facturas cria nova factura com a data e valor especificados, e um nº sequencial atribuído automaticamente com base em ultimoNumero

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 84 Visibilidade de atributos e operações n Visibilidade: + (public) : visível por todos - (private) : visível só por operações da própria classe # (protected): visível por operações da própria classe e descendentes (subclasses) n Princípio do encapsulamento: esconder todos os detalhes de implementação que não interessam aos clientes (utilizadores) da classe permite alterar representação do estado sem afectar clientes permite validar alterações de estado Toolbar # currentSelection: Tool # toolCount: Integer + getTool(i: Integer): Tool + addTool(t: Tool) + removeTool(i: Integer) - compact() usada internamente por outras operações

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 85 *Multiplicidade de classes e atributos n Multiplicidade de classe: número de instâncias que podem existir por omissão, é 0..* n Multiplicidade de atributo: número de valores que o atributo pode tomar do tipo especificado por omissão é 1 qual a diferença em relação a especificar a multiplicidade no próprio tipo de dados do atributo? NetworkController consolePort [2..*]: Port 1

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 86 Relações entre classes: associação, agregação e composição

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 87 Associações binárias n Uma associação é uma relação entre objectos das classes participantes (um objecto de cada classe em cada ligação) n Não gera novos objectos n Matematicamente,uma associação binária é uma relação binária, i.e., um subconjunto do produto cartesiano das extensões das classes participantes n Assim como um objecto é uma instância duma classe, uma ligação é uma instância duma associação n Pode haver mais do que uma associação (com nomes diferentes) entre o mesmo par de classes n Papéis nos extremos da associação podem ter indicação de visibilidade (pública, privada, etc.) Participante-1 Participante-2 Nome da associação papel-1 papel-2

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 88 Multiplicidade de associações binárias Muitos-para-Muitos 1-para-1 Muitos-para-1 Professor Curso Aluno Curso Plano de Curso (sem restrições) * 111 **

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 89 Notação para a multiplicidade 1 - exactamente um 0..1 - zero ou um (zero a 1) * - zero ou mais 0..* - zero ou mais 1..* - um ou mais 1, 3..5 - um ou três a 5

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 90 Associação reflexiva n Pode-se associar uma classe com ela própria (em papéis diferentes) Pessoa pai filho 0..1 * filho mãe 0..1 *

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 91 Nome de associação n A indicação do nome é opcional n O nome é indicado no meio da linha que une as classes participantes n Pode-se indicar o sentido em que se lê o nome da associação Empresa Pessoa Trabalha-para Emprega empregadorempregado

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 92 Associações unidireccionais As associações são classificadas quanto à navegabilidade em: bidireccionais (normal) unidireccionais um objecto da classe 1 tem a responsabilidade de dar o(s) objecto(s) correspondente(s) da classe 2 (nível de especificação) ou um objecto da classe 1 tem apontador(es) para o(s) objecto(s) correspondente(s) da classe 2 (nível de implementação) Class-1 Class-2 Class-1 Class-2

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 93 Classe-Associação n reúne as propriedades de associação e classe n o nome pode ser colocado num sítio ou noutro, conforme interessa realçar a natureza de associação ou de classe, mas a semântica é a mesma n o nome também pode ser colocado nos dois sítios n não é possível repetir combinações de objectos das classes participantes na associação Class-1 Class-2 Association Name link attribute... link operation... Association Name

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 94 Associações n-árias n Notação n Multiplicidade a cada par de objectos das restantes classes (1 e 2), correspondem 0 ou 1 objectos da classe 3 Class-1 Class-2 Association Name role-1 role-2 Class-3 role-3 Class-1 Class-2 Class-3 0..1

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 95 Exemplo: associações n-árias Equipa Jogador Época Registo Golos marcados Golos sofridos Vitórias Derrotas empates Guarda-redes * equipa * época *

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 96 Pertence a Atributos versus Associações n Uma propriedade que designa um objecto de uma classe presente no modelo, deve ser modelada como uma associação e não como um atributo n Exemplo: País Cidade nome: string capital: string capital: Cidade 1 1 nome: string 0..1 * capital

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 97 *Associações qualificadas n Qualificador: lista de um ou mais atributos de uma associação utilizados para navegar de A para B n "Chave de acesso" a B (acesso a um objecto ou conjunto de objectos) a partir de um objecto de A qualificador Classe A Classe B 0..1 nº de sócio Clube Pessoa * para cada par Clube + nº de sócio Associação nome morada uma Pessoa pode ser sócia de vários clubes

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 98 Agregação n Associação com o significado contém (é constituído por) / faz parte de (part of) n Relação de inclusão nas instâncias das classes n Hierarquias de objectos n Exemplo: Equipa Jogador * 0..1 Uma equipa contém 0 ou mais jogadores Um jogador faz parte de uma equipa (num dado momento), mas também pode estar desempregado

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 99 Composição n Forma mais forte de agregação aplicável quando: existe um forte grau de pertença das partes ao todo cada parte só pode fazer parte de um todo (i.e., a multiplicidade do lado do todo não excede 1) o topo e as partes têm tempo de vida coincidente, ou, pelo menos, as partes nascem e morrem dentro de um todo a eliminação do todo propaga-se para as partes, em cascata Notação: losango cheio (   ou notação encaixada n Membros-objecto em C++

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 100 Window Composição: notações alternativas Window SliderHeaderPanel scrollbar 2 1 title 1 1 1 1 body scrollbar: Slider 2 title: Header 1 body: Panel 1 (sub-objectos no compartimento dos atributos) Window scrollbar[2]: Slider title: Header body: Panel

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 101 Relações entre classes: generalização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 102 Generalização Relação semântica “is a” (“é um” / “é uma”) : um aluno é uma pessoa Relação de inclusão nas extensões das classes: UoD super-classe sub-classe x x x x x objecto extensão (sub-classe)  extensão (super-classe) Pessoa Aluno generalização especialização Relação de herança nas propriedades: A sub-classe herda as propriedades (atributos, operações e relações) da super-classe, podendo acrescentar outras super-classe sub-classe

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 103 As três facetas da generalização n Substitutabilidade onde se espera um objecto da super-classe pode-se passar um objecto duma subclasse n Herança de interface a subclasse herda as assinaturas (e significados) das operações da super-classe n Herança ou overriding de implementação a subclasse pode herdar as implementações das operações da super- classe, mas também pode ter novas implementações de algumas dessas operações quando em UML se repete numa subclasse a assinatura de uma operação da super-classe, quer dizer que tem uma nova implementação na subclasse

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 104 Polimorfismo n Substitutabilidade + Overriding  Polimorfismo + Late Binding Quando se tem uma variável do tipo referência ou apontador para super-classe (que pode guardar uma referência para objecto da super-classe ou de uma subclasse), e se invoca uma operação, é usada a implementação da classe do objecto referenciado (determinada em tempo de execução – late binding), e não a implementação de acordo com o tipo de referência (determinada em tempo de compilação – early binding) Em C++ e C# só acontece com funções ou métodos virtuais n Mecanismo muito poderoso, que permite estender software através da criação de novas subclasses que são usadas a partir de classes pré-existentes (que dependem apenas da interface e não da implementação das operações), sem que estas tenham conhecimento dessas extensões

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 105 Exemplo em C++ class Pessoa { private: string nome; Data dataNascimento; public: Pessoa(string, Data); string getNome() const; Data getDataNascimento() const; int getIdade() const; void setNome(string); void setDataNascimento(Data); virtual void imprime() const; }; class Aluno : public Pessoa { private: string curso; public: Aluno(string nm, Data, string crs); string getCurso() const; void setCurso(string); virtual void imprime() const; }; Ferramenta: Microsoft Visual Modeler

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 106 Hierarquias de classes n Em geral, pode-se ter uma hierarquia de classes relacionadas por herança / generalização em cada classe da hierarquia colocam-se as propriedades que são comuns a todas as suas subclasses  evita-se redundância, promove-se reutilização! (...)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 107 Notações alternativas para hierarquias de classes AlunoProfessor Pessoa AlunoProfessor Pessoa

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 108 Subclasses sobrepostas (  disjuntas) n caso em que um objecto da superclasse pode pertencer simultaneamente a mais do que uma subclasse n indicado por restrição {overlapping} n o contrário é {disjoint} (situação por omissão?) Superclass Subclass-1Subclass-2 {overlapping} ou Superclass Subclass-1Subclass-2 {overlapping}

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 109 Subclasses incompletas (  completas) n caso em que um objecto da superclasse pode não pertencer a nenhuma das subclasses n indicado por restrição {incomplete} n o contrário é {complete} (situação por omissão?) TécnicoComercial Funcionário {incomplete}

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 110 Herança múltipla (  simples) n ocorre numa subclasse com múltiplas super-classes n geralmente suportada por linguagens de programação OO EstudanteProfessor cursocategoria Académico nome e-mail Professor-Estudante redução de horário {overlapping} Só faz sentido assim! pelo menos conceptualmente, existe uma super-classe comum herda propriedades de Estudante e Professor e, indirectamente, de Académico (uma única vez!)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 111 Classificação dinâmica (  estática) n classificar objecto: atribuir classe a objecto n caso em que a(s) classe(s) a que um objecto pertence pode(m) variar ao longo da vida do objecto n indicado por estereótipo «dynamic» n geralmente não suportada por linguagens de programação OO Pessoa tarefa Gestor Engenheiro Vendedor «dynamic» atributo discriminante (atributo de pessoa que indica a subclasse a que pertence) Uma pessoa que num dado momento tem a tarefa de gestor, pode noutro momento ter a tarefa de vendedor, etc.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 112 Classificação múltipla (  simples) n caso em que um objecto pode pertencer num dado momento a várias classes, sem que exista uma subclasse que represente a intersecção dessas classes (com herança múltipla) n geralmente não suportado pelas linguagens de programação OO (pode então ser simulada por agregação de papéis) exemplo de combinação legal: {Mulher, Paciente, Enfermeira} Homem Mulher Pessoa sexo Paciente paciente função Médico Enfermeira Fisioterapeuta

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 113 Classes e operações abstractas (  concretas) n Classe abstracta: classe que não pode ter instâncias directas pode ter instâncias indirectas pelas subclasses concretas n Operação abstracta: operação com implementação a definir nas subclasses uma classe com operações abstractas tem de ser abstracta função virtual pura em C++ n Notação : nome em itálico ou propriedade {abstract} Icon RectangularIconArbitraryIcon origin: Point display() getID(): Integer height: Integer width: Integer edge:LineCollection display() isInside(p:Point):Bool Button display() Fonte: The UML User Guide, Booch et al

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 114 Associação versus Agregação / Composição versus Generalização Aluno Pessoa João Maria generalização Cursos e disciplinas Curso de Modelação de Software UML VDM++ associação agregação ou composição objecto classe José Professor

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 115 Exemplo: meta-modelo parcial Agregação Composição nome Classe Extremo de Associação 2..* 1 1 * multiplicidade papel visibilidade Associação Classe-Associação Relação superclasse subclasse * * nome Generalização 2 no caso de agregação

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 116 Relações entre classes: dependência e concretização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 117 Relação de dependência n Relação de uso entre dois elementos (classes, componentes, etc.), em que uma mudança na especificação do elemento usado pode afectar o elemento utilizador n Exemplo típico: classe-1 que depende de outra classe-2 porque usa operações ou definições da classe-2 n Úteis para gestão de dependências servidor cliente

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 118 Relação de concretização (realization) n Relação entre elementos a diferentes níveis de abstracção, isto é, entre um elemento mais abstracto (que especifica uma interface ou um "contracto", entre clientes e implementadores) e um elemento correspondente mais concreto (que implementa esse contracto) n Difere da generalização porque há apenas herança de interface e não herança de implementação «type» Stack LinkedStack «interface» ISerializable XMLDocument Caso de utilização Colaboração

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 119 Dependência e concretização n Aparecem frequentemente combinados n Cliente usa o servidor sem dele depender directamente (depende apenas da interface ou contracto que o servidor implementa) contracto ou interface cliente servidor

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 120 Restrições, elementos derivados, pré-condições e pós-condições

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 121 Restrições n Uma restrição especifica uma condição que tem de se verificar no estado do sistema (objectos e ligações) n Uma restrição é indicada por uma expressão ou texto entre chavetas ou por uma nota posicionada junto aos elementos a que diz respeito, ou a eles ligada por linhas a traço interrompido (sem setas, para não confundir com relação de dependência) n Podem ser formalizadas em UML com a OCL - "Object Constraint Language" n Também podem ser formalizadas (como invariantes) numa linguagem de especificação formal como VDM++

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 122 Restrições em classes Pessoa nome dataNascimento localNascimento dataFalecimento {chave candidata: (nome, dataNascimento, localNascimento)} {dataFalecimento > dataNascimento} Factura LinhaFactura *1 número data número artigo quantidade valor {chave candidata: (factura, número)} {chave candidata: (número)}

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 123 Restrições em associações Pessoa Empresa chefe 1 * empregadoempregador subordinado 0..1* Pessoa.empregador = Pessoa.chefe.empregador Pessoa Comité Membro-de Director-de * * * 1 {subset} Factura LinhaFactura * {ordered} 1 uma factura é constituída por um conjunto ordenado de 0 ou mais linhas Conta Pessoa {xor} Empresa associações mutuamente exclusivas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 124 Elementos derivados n Elemento derivado (atributo, associação ou classe): elemento calculado em função doutros elementos do modelo n Notação: barra “/” antes do nome do elemento derivado n Um elemento derivado tem normalmente associada uma restrição que o relaciona com os outros elementos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 125 Exemplo de elementos derivados Movimento data valor / TotalMensal mês valor {valor = (select sum(valor) from Movimento where month(data)=mês)} Empresa 1 Departamento * Pessoa TrabalhaEmDepartamento 1 /TrabalhaEmEmpresa empregador 1 * {Pessoa.empregador = Pessoa.departamento.empresa} * dataNascimento /idade {idade = dataActual() - dataNascimento}

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 126 * Pré-condições e pós-condições n Semântica de operações pode ser captada através de pré- condições e pós-condições n Pré-condição: uma condição nos argumentos e estado inicial do objecto, a verificar na chamada (início) da operação n Pós-condição: uma condição nos argumentos, estado inicial do objecto, estado final do objecto e valor retornado pela operação, a verificar no retorno (fim) da operação n Podem ser expressas em UML através da OCL (Object Constraint Language) n Também podem ser expressas numa linguagem de especificação formal, como VDM++ VDM++ tem a vantagem de permitir também implementar as operações e executar as pré-condições e pós-condições

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 127 Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes, utilitários

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 128 * Classes parametrizadas (templates) FArray T k: Integer parâmetros formais data [k] : T ThreePoints «bind» (Point,3) classe parametrizada parâmetros actuais Farray ou template class FArray { public: T[k] data; }; typedef Farray ThreePoints;  generalização, porque não se podem acrescentar propriedades! classe ligada ("bound") C++

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 129 Interfaces n Uma interface especifica um conjunto de operações (com sintaxe e semântica) externamente visíveis de uma classe de (ou componente, subsistema, etc.) semelhante a classe abstracta só com operações abstractas e sem atributos nem associações (em C++ é mesmo isso!) separação mais explícita entre interface e (classes de) implementação interfaces são mais importantes em linguagens como Java, C# e VB.NET que têm herança simples de implementação e herança múltipla de interface n Relação de concretização de muitos parta muitos entre interfaces e classes de implementação n Vantagem em separar interface de implementação: os clientes de uma classe podem ficar a depender apenas da interface em vez da classe de implementação n Notação: classe com estereótipo «interface» (ligada por relação de concretização à classe de implementação) ou círculo (ligado por linha simples à classe de implementação)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 130 Interfaces: notações alternativas «interface» InterfaceClass ImplementationClass InterfaceClass operations ClientClass attributes operations attributes operations ou ClientClass Cliente depende só da interface e não da implementação relação de concretização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 131 * Tipos n Um tipo é usado para especificar um domínio de objectos em conjunto com as operações aplicáveis a esses objectos, sem especificar a implementação física desses objectos não pode incluir métodos (implementação de operações) pode ter atributos e associações (abstractos!), mas apenas para especificar o comportamento das operações, sem compromisso de implementação notação: classe com estereótipo «type» semelhante a tipo abstracto de dados n Uma classe de implementação (classe normal) define a estrutura física de dados (para atributos e associações) e métodos de um objecto tal como é implementado numa linguagem tradicional notação: classe normal ou classe com estereótipo «implementationClass» diz-se que uma classe de implementação concretiza ("realizes") um tipo se proporciona todas as operações definidos no tipo, com o mesmo comportamento especificado no tipo

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 132 * Tipos: exemplo «type» FinitePriorityQueue isFull():Boolean maxSize:Integer «type» PriorityQueue insert(value:T, priority:Integer) deleteMax():T isEmpty():Boolean T HeapFinitePriorityQueue + insert(value: T, priority: Integer) + deleteMax():T + isEmpty(): Boolean + isFull(): Boolean - HeapifyUp - HeapifyDown T maxSize:Integer - elems [0..maxSize]: T - size: Integer = 0 HeapFilaPacientes «bind» (Paciente, 100) elems: set of (priority: Integer, value:T) relação de concretização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 133 * Meta-classes n Uma meta-classe é uma classe cujas instâncias são classes n Notação: classe com estereótipo «metaclass» n Usadas geralmente em meta-modelos n Relação de instanciação (entre classe e meta-classe) pode ser indicada por dependência com estereótipo «instanceOf» «metaclass» SYSCLASSES name Class-1 «instanceOf»

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 134 * Utilitários n Um utilitário é um agrupamento de variáveis globais e procedimentos como classe n Pode ser implementado por classe em que todos os atributos e operações são estáticos n Notação: classe com estereótipo «utility» «utility» MathPack pi: Real sin(ang: Real): Real cos(ang: Real): Real

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 135 * Estereótipos de classes em modelos de negócio actor em relação ao negócio (cliente ou outra entidade ou sistema que interage com o negócio); actor externo perfil de trabalhador do negócio, interno (não interage com actores do negócio) ou de fronteira (interage com actores do negócio); actor interno objecto passivo manipulado pelos trabalhadores e actores nas actividades dos processos de negócio Um modelo de negócio descreve a implementação dos processos de negócio (de fronteira) e de suporte (internos) através de colaborações entre objectos dos seguintes tipos:

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 136 * Estereótipos de classes em modelos de análise Um modelo de análise descreve implementações "ideais" dos casos de utilização de um sistema de software, com vista a melhor compreender os seus requisitos, através de colaborações entre objectos dos seguintes tipos: actor em relação ao sistema de software (pode ser interno ou externo ao negócio) objecto de fronteira (formulário, janela, etc.) objecto passivo que guarda estado mais ou menos persistente objecto de controlo (controla sequência de funcionamento, transacções, etc.; estabelece ligação entre objectos de fronteira e entidades)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 137 Biblioteca: modelo de domínio

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 138 Biblioteca: modelo de desenho (lógica de negócio)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 139 Exercícios n Para um caso prático: Identificar os conceitos do domínio do problema Identificar propriedades dos conceitos Identificar associações entre os conceitos (tipos, nomes, cardinalidades, papéis)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 140 UML – Diagramas de Objectos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 141 Finalidade dos diagramas de objectos n Um diagrama de objectos mostra instâncias de classes (objectos) e de associações (ligações entre objectos) n Utilizados para ilustrar cenários / configurações particulares n Base para diagramas de colaboração

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 142 n Um objecto é uma instância de uma classe n É representado por um rectângulo com o nome sublinhado Objectos João: Aluno nome do objecto separador nome da classe ou : Aluno objecto anónimo ou João: classe não especificada Aluno nome: string data de nascimento: date peso: real = 75 kg João: Aluno nome = “João Silva” data de nascimento = 18/3/1973 peso = 70 kg classe objecto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 143 Objectos compostos n Um objecto composto é uma instância de uma classe que tem classes associadas por relações de composição n Componentes de objecto composto podem ser apresentados de forma encaixada n Componentes podem estar ligados entre si composto 1: Classe 1 componente 1: Classe 2 componente 2: Classe 2

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 144 Ligações n Assim como um objecto é uma instância duma classe, uma ligação é uma instância duma associação n Nomes de papéis e associações podem ser suprimidos se não há ambiguidade n Nome da associação quando aparece é sublinhado n A multiplicidade não aparece n Adornos de agregação, composição e navegação podem aparecer

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 145 Instanciação n Relação de instanciação entre objecto e classe pode ser indicada por dependência com estereótipo «instanceOf» Class-1 object-1: Class-1 «instanceOf»

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 146 Exemplo 1: Estrutura Organizacional

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 147 Exemplo 2: Árvore genealógica

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 148 Exemplo 3: Objecto composto Ficha de Sócio: Formulário Ok: Botão Cancelar: Botão Nome: Caixa de Texto Número: Caixa de Texto Fotografia: Imagem

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 149 UML – Diagramas de Pacotes (Packages) e Modelação da Arquitectura Lógica

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 150 Pacotes n Um pacote (package) em UML é um mecanismo de agrupamento genérico n Notação: pasta com o nome no interior ou na pega n No caso de um pacote contido noutro, o nome completo do pacote contido inclui o nome do seu contentor Client Sensors::Vision

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 151 Diagramas de pacotes n Um diagrama de pacotes mostra pacotes e relações entre pacotes n Na realidade, não existem propriamente diagramas de pacotes em UML; em vez disso, pacotes e relações entre pacotes aparecem noutros diagramas, de acordo com o tipo de pacote Pacotes de classes (pacotes lógicos) - em diagramas de classes Pacotes de componentes – em diagramas de componentes Pacotes de nós – em diagramas de distribuição Pacotes de casos de utilização – em diagramas de casos de utilização

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 152 Pacotes lógicos n Um pacote lógico (ou módulo lógico) é um agrupamento lógico de classes e relações entre essas classes divisão de um sistema em pacotes lógicos é uma divisão de responsabilidades n Corresponde ao conceito de package em Java ou de namespace em C++ e C# n Não confundir com empacotamento físico do software em ficheiros de código fonte, executáveis, dll's, etc. (designados componentes em UML) n Um pacote lógico pode atravessar vários ficheiros n Diagramas de pacotes lógicos utilizadas para modelar a arquitectura lógica de um sistema de software (organização em módulos lógicos e especificação de interfaces e dependências entre módulos)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 153 Conteúdo de um pacote n Uma vez que representa um agrupamento, um pacote é em geral dono de diversos elementos: classes, interfaces, componentes, nós, colaborações, casos de uso, diagramas, e até outros pacotes n Esses elementos podem ser indicados no interior do pacote, na forma de uma lista de nomes ou diagrama n Um pacote forma um espaço de nomes classe Order do pacote Client é designada Client::Order Client + OrderForm + TrackingForm - Order Client + OrderForm - Order + TrackingForm

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 154 Visibilidade dos elementos contidos num pacote n Pode-se indicar a visibilidade dos elementos: + (público) : visível por todos que importam ou acedem ao pacote (nomes sem :: no 1º caso, com :: no 2º caso) # (protegido): visível só pelos pacotes-filhos (por relação de generalização - ver adiante) - (privado): visível só por outros elementos do pacote n Os elementos públicos de um pacote são chamados também os elementos exportados pelo pacote

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 155 Dependências entre pacotes n Dependência simples: uma alteração do pacote de destino afecta o pacote de origem (dependente) (informação útil para controlo de alterações) n Dependência com estereótipo «access»: o pacote de origem (dependente) acede a elementos exportados pelo pacote de destino (precisa de :: nos nomes) n Dependência com estereótipo «import»: o pacote de origem (dependente) importa os elementos exportados pelo pacote de destino (não precisa de :: nos nomes) Client + OrderForm + TrackingForm - Order «import» GUI + Window + Form # EventHandler

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 156 Generalização de pacotes n Usada para especificar famílias de pacotes relacionados por herança GUI + Window + Form # EventHandler WindowsGUI + GUI::Window + Form # GUI::EventHandler +VBForm MacGUI herda os elementos públicos e protegidos de GUI substitui (overrides) o elemento Form de GUI adicionado herda sem alteração (default)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 157 Estereótipos em pacotes n «system» - pacote que representa o sistema completo que está a ser modelado (incluindo todos os modelos e elementos dos modelos) n «subsystem» - pacote que representa uma parte independente de sistema completo que está a ser modelado; corresponde normalmente a um corte "vertical" n «facade» (fachada) - pacote que constitui uma vista sobre outro pacote (não acrescenta funcionalidades, apenas apresenta de forma diferente) n «framework» (infra-estrutura aplicacional) - pacote que representa um conjunto de classes abstractas e concretas concebido para ser estendido, implementando a funcionalidade típica de um determinado domínio de aplicação n «stub» - pacote que serve como proxy para o conteúdo público de outro pacote n «layer» - pacote que representa uma camada horizontal de um sistema

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 158 Composição de pacotes (1) n Sub-pacotes podem ser indicados dentro do pacote-dono ou com relação de composição «system» Retail Enterprise System «subsystem» In Store Management subsystem «subsystem» Customer Service subsystem «subsystem» Warehouse Management subsystem Neste exemplo segue-se uma divisão vertical, por subsistemas!

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 159 Composição de pacotes (2) «system» Retail Enterprise System «layer» Retail Enterprise System - GUI Neste exemplo segue-se uma divisão horizontal, por camadas! «layer» Retail Enterprise System - BL «layer» Retail Enterprise System - DB Graphical User Interface Business Logic Database

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 160 Biblioteca: divisão em áreas funcionais

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 161 Biblioteca: divisão em camadas técnicas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 162 Biblioteca: divisão em camadas técnicas e áreas funcionais

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 163 UML - Diagramas de Actividades (activity diagrams)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 164 Objectivo n Um diagrama de actividades decompõe uma actividade em sub-actividades (actividades de mais baixo nível), podendo chegar a acções atómicas, com fluxo de controlo sequencial ou concorrente entre sub-actividades Opcionalmente, podem-se definir as unidades organizacionais, entidades ou objectos responsáveis pela execução de acções ou actividades Opcionalmente, podem-se indicar fluxos de objectos - objectos que são entrada ou saída de sub-actividades Pode-se usar toda a notação dos diagramas de estados n Um diagrama de actividades é essencialmente um fluxograma com concorrência n A actividade que está a ser decomposta pode ser: Um caso de utilização Uma operação de uma classe Um grupo de casos de utilização relacionados entre si Uma parte de uma actividade de mais alto nível

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 165 Tipos de estados n Estado de espera: a saída é causada por eventos Pode ter actividade e acções associadas Transições de saída têm eventos e possivelmente condições e acções n Estado de acção: estado de execução de uma acção, cuja conclusão determina a saída do estado Acção: operação atómica, instantânea, que não pode ser interrompida Transições de saída não têm eventos, mas podem ter condições e acções n Estado de (sub)actividade: estado de execução de uma (sub)actividade, cuja conclusão determina a saída do estado (Sub)Actividade: operação não atómica, possivelmente detalhada noutro diagrama (com ícone), potencialmente demorada, que pode ser interrompida Transições de saída não têm eventos, mas podem ter condições e acções n Decisão: estado de passagem em que são testadas condições As condições aparecem nas transições de saída Não é um estado verdadeiro, mas uma ramificação numa transição acção activ. Estado

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 166 Exemplo: Preparar bebida Procurar Bebida [não há café] [não há cola] [há cola] [há café] Pôr Água no Reservatório Pôr Café no Filtro Pôr Chávenas Pôr Filtro na Maquina Ligar Máquina Esperar que aqueça /send ligar cafeteira Deitar café Beber Buscar latas de cola luz desliga-se estado de espera (cantos arredondados) decisão e ramificação subactividade (lados arredondados) envio de sinal transição disparada por recepção de sinal barra de sincronização (separação) barra de sincronização (fusão)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 167 Notação alternativa para envio e recepção de sinais ligar cafeteira luz desliga-se Ligar Máquina Esperar que aqueça Deitar café cafeteira opcional Transição com acção de envio de sinal Transição causada por evento de recepção de sinal

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 168 Pistas de responsabilidade (swimlanes) n Um diagrama de actividades pode ser dividido em pistas de responsabilidade (swimlanes), separadas por linhas contínuas n Cada pista é encabeçada pelo nome da unidade organizacional, entidade ou objecto responsável pelas acções e actividades aí localizadas n Cada acção ou actividade é localizada numa única pista, mas uma transição pode atravessar várias pistas n Útil para modelar fluxos de trabalho relativos a processos de negócio

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 169 Fluxos de objectos n Um objecto pode ser entrada (para consulta) ou saída (para criação, modificação ou destruição) de uma acção indica-se por uma seta a traço interrompido (seta de dependência) entre a acção e o objecto, no sentido do fluxo n Quando uma acção tem como saída um objecto que é entrada para a acção seguinte, é desnecessário indicar o fluxo de controlo (a transição), basta o fluxo de/para objectos (tipo DFD) acção 1 obj1:C1 acção 2 consultacria, modifica ou destrói acção 1 obj1:C1 acção 2

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 170 Exemplo: Processo de encomenda Faz encomenda Cliente Regista encomenda VendasArmazém Emite factura Despacha encomenda Paga factura e: Encomenda [pendente] e: Encomenda [despachada] f: Factura [pendente] f: Factura [paga] Estado de objecto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 171 Modelação de processos de negócio n Processo de negócio é actividade estereotipada n Processo pode ter sub-diagrama encaixado n Dependências com estereótipos "supply", "controls",..., entre processos n Processos transformam objectos de entrada, produzem objectos de saída, usam recursos e pretendem atingir "goals" n Ver "Business Modeling with UML: Business Patterns at Work", de Hans-Erik Eriksson e Magnus Penker, Wiley & Sons, 2000 Requisitar Publicação Levantar Devolver

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 172 Caso de estudo: Biblioteca

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 173 Diagrama de actividades relativo ao caso de utilização de negócio "Requisitar publicação" : requisição [finalizada] : requisição [espera disponibilidade] : requisição [espera levantamento] : requisição [espera devolução]

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 174 Exercícios n Para um caso prático: Detalhar os casos de utilização do negócio através de diagramas de actividades

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 175 UML - Diagramas de Sequência

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 176 Objectivo n Um diagrama de sequência mostra uma interacção, isto é, uma sequência de mensagens trocadas entre vários objectos num determinado contexto (caso de utilização, operação, etc.) n Enfatiza a comunicação e passagem de controlo entre objectos ao longo do tempo n Útil para descrever uma sequência particular de funcionamento, mas não muitas sequências alternativas e ciclos nem acções realizadas por um objecto que não envolvem comunicação com outros objectos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 177 Objectos e linhas de vida n Cada objecto participante é representado por uma caixa em cima duma linha vertical a traço interrompido (linha de vida) n Podem aparecer actores (objectos externos ao sistema), normalmente a iniciar interacções n O tempo cresce de cima para baixo objecto1:Classe1 objecto2: :Classe3 mensagem

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 178 Mensagens n Uma mensagem é uma comunicação entre objectos (emissor e receptor) que veicula informação na expectativa de provocar uma resposta (acção ou actividade) Uma acção de um objecto capaz de provocar uma resposta noutro objecto pode ser modelada como uma mensagem do primeiro para o segundo objecto n Uma mensagem é representada por uma seta horizontal, do emissor para o receptor, com o nome e possíveis argumentos n Tipos de mensagens síncrona - o emissor fica parado à espera de resposta corresponde tipicamente a chamada de operação/procedimento no receptor retorno de mensagem síncrona desnecessário indicar quando se usam barras de activação (ver adiante) assíncrona - o emissor não fica parado à espera de resposta corresponde tipicamente a envio de sinal entre dois objectos concorrentes simples ou indiferenciada - não se decide se é síncrona, de retorno ou assíncrona usadas normalmente na modelação de interacções na fronteira do sistema (entre actores e o sistema representado por um ou mais objectos)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 179 Criação e destruição de objectos n Criação de objecto é representada por mensagem dirigida à própria caixa que representa o objecto (em vez de ser dirigida à linha de vida) Mensagem de criação pode ter estereótipo «create» n Destruição de objecto é representada por um X no fim da linha de vida do objecto Mensagem de destruição pode ter estereótipo «destroy » Pode ocorrer na recepção de mensagem ou no retorno de chamada Objecto pode auto destruir-se ob1:C1

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 180 Mensagens condicionais, iteradas e com retorno n O valor de retorno de uma mensagem síncrona pode ser indicado na chamada, com atribuição :=, ou na mensagem de retorno Exemplo: ret := msg(args) Nome “ret” será usado em mensagens e condições a seguir Também se pode escrever “ret” na mensagem de retorno n Uma mensagem condicional é indicada por uma condição de guarda entre parêntesis rectos [ ] Exemplo: [x<0] invert(x,color) A mensagem só é enviada se a condição se verificar Condições permitem mostrar várias sequências alternativas num único diagrama n Uma mensagem iterada é indicada com asterisco *, seguido ou não de uma fórmula de iteração Exemplo: *[i:=1..n] update(i)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 181 Barra de activação n Uma barra de activação mostra o período de tempo durante o qual um objecto está a executar uma acção, quer directamente quer indirectamente através de um procedimento chamado inclui situação em que está á espera de retorno de uma chamada síncrona não inclui situação em que um processo está adormecido à espera de receber uma mensagem assíncrona que o acorde n Em termos de processos, significa que o objecto tem um processo ou thread activo associado n A sua indicação é opcional n Retorno de chamada é implícito no fim da barra de activação n Chamadas recursivas provocam barras empilhadas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 182 Exemplo: Fazer chamada telefónica restrição temporal quem é chamado: Pessoa quem chama: Pessoa :Sistema telefónico levanta auscultador dá sinal de marcar marca (1º dígito) termina sinal de marcar marca (2º dígito) marca (último dígito) dá sinal de chamada toca o telefone levanta auscultador pára de tocar pára sinal de chamada poisa auscultador dá sinal de conexão terminada poisa auscultador a b {b-a < 10 seg.} marca temporal nesta altura decorre a conversação... mensagem simples

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 183 Exemplo: Tratar pedido de stock [e=“sim"]retirar(q) :Janela de Selecção de Pedidos :Pedido :Linha de Pedido e2:Encomenda tratar() * tratar() :Item de Stock e:=existe?(q) b:=baixo?() [b=“sim”] criar() [e=“nao”] criar() e1:Encomenda Para cada linha do pedido Quantidade pedida Para repor stock Para poder satisfazer pedido criação de objecto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 184 Exemplo: Executar transacção com subtransacções concorrentes Adormecida à espera de sinal de sub-transacção t: Transacção criar s1: Subtransacção s2: Subtransacção criar restam subtransacções? sucesso restam subtransacções? sucesso auto-destruição e executar

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 185 selecciona opção de levantamento Bifurcação e fusão de linhas de vida :Utilizador : Multibanco :SIBS introduz cartão introduz PIN selecciona montante solicita transacção sucesso entrega dinheiro entrega talão entrega cartão saldo insuficiente avisa saldo insuficiente Usar em vez de ou em combinação com mensagens condicionais bifurcações sincronizadas fusões sincronizadas

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 186 Relação com outros diagramas n Relação com diagramas de colaboração Diagramas de sequência e de colaboração colectivamente designados diagrama de interacção Diagrama de colaboração = diagrama de objectos + diagrama de sequência n Relação com diagramas de casos de utilização A um caso de utilização podem corresponder vários diagramas de sequência, para descrever sequências normais e sequências excepcionais de funcionamento Inicialmente, o sistema pode ser representado por um único objecto; depois de conhecida a sua estrutura interna, podem-se representar objectos internos ao sistema n Relação com diagramas de estados Enquanto que um diagrama de interacção mostra um comportamento possível de um conjunto de objectos, com passagem de controlo entre objectos, um diagrama de estados mostra todos os comportamentos possíveis de um único objecto, com passagem de controlo entre estados Envio e recepção de mensagens são acções e eventos nos diagramas de estados Intervalo de tempo entre duas mensagens é um estado no diagrama de estados n Relação com diagramas de actividades Adequados para mostrar acções realizadas por um objecto que não envolvem comunicação com outros objectos Com "swimlanes", permitem para mostrar sequências alternativas e ciclos envolvendo vários objectos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 187 Caso de estudo (biblioteca): diagrama de sequência relativo ao caso de utilização "Empréstimo"

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 188 Exercícios n Para um caso prático: Descrever sequências normais e excepcionais de funcionamento dos casos de utilização do negócio

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 189 Outros exercícios n Elaborar diagramas de sequência relativamente aos seguintes casos de utilização: Levantamento de dinheiro num terminal multibanco -Sequência normal -Sequência excepcional no caso do saldo ser insuficiente -Visão simplificada apenas com utilizador e sistema -Visão detalhada envolvendo o SIBS (Serviços Interbancários), o banco emissor do cartão e a conta envolvida

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 190 UML – Diagramas de Estados (Statechart Diagrams)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 191 Introdução

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 192 Objectivo n Um diagrama de estados especifica uma máquina de estados, com estados (duradoiros e em número finito) e transições entre estados (instantâneas) causadas por eventos (instantâneos) n Pode também especificar as acções (instantâneas) e actividades (duradoiras) realizadas em resposta a eventos ou durante a permanência em estados, respectivamente n Usado normalmente para modelar o ciclo de vida dos objectos de uma classe (objecto visto como máquina de estados) n Em geral, serve para modelar a dinâmica de um sistema ou objecto cujo estado evolui por saltos (transições instantâneas) em resposta a eventos, com um número finito de estados estado (de sistema, objecto, etc.) tempo evento

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 193 Comportamento e ciclo de vida de objectos ou sistemas reactivos (1) n Um diagrama de estados é útil para modelar o comportamento e o ciclo de vida de um objecto ou sistema reactivo n Objecto/sistema reactivo: funciona por resposta (reacção) a estímulos (eventos) Comportamento reactivo  comportamento invocável (operações) Sistema reactivo  sistema transformacional (tipo filtro Unix) Sistemas de interacção com o utilizador (com formulários, botões, etc.) são tipicamente reactivos Sistemas de tempo real (ex: semáforo) podem ser vistos como sistemas reactivos que reagem a eventos temporais (timeout,...) Sistemas reactivos geralmente têm memória - um estado interno que acumula o efeito dos estímulos recebidos no passado e afecta a resposta a estímulos futuros

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 194 Comportamento e ciclo de vida de objectos ou sistemas reactivos (2) n Ciclo de vida de um objecto/sistema: as sequências de estados por que pode passar durante a sua vida em resposta a eventos, em conjunto com as respostas a esses eventos, ou seja: os estados possíveis (exemplo - estado civil: solteiro, casado,...) as transições de estado possíveis (exemplo: pode passar de solteiro para casado, mas não o contrário) os eventos que causam essas transições (exemplo: o casamento implica a passagem ao estado de casado) as acções do objecto em resposta a esses eventos (ex: despedida de solteiro) n Objecto como máquina de estados n Objectos da mesma classe têm o mesmo ciclo de vida, pelo que basta construir um diagrama de estados por classe relevante Interacções entre objectos aparecem pouco explícitas, como trocas de mensagens

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 195 Relação com outros diagramas dinâmicos n Diagramas de estados focam o fluxo (passagem) de controlo de estado para estado num objecto, mostrando todas as sequências possíveis de funcionamento de um único objecto Bom para especificação Comunicação entre objectos do mesmo sistema aparece de forma pouco explícita, através de eventos gerados (como acções) na máquina de estados de um objecto que são testados (como eventos) na máquina de estados doutro objecto n Diagramas de interacção (sequência ou colaboração) focam o fluxo (passagem) de controlo de objecto para objecto numa sequência particular de funcionamento de um sistema Comunicação entre objectos aparece de forma explícita Bom para ilustração mas mau para especificação n Diagramas de actividades focam o fluxo de controlo de actividade para actividade numa actividade de mais alto nível (operação, caso de utilização, etc.) de um objecto ou sistema

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 196 Notação e conceitos básicos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 197 Notação básica Estado 1 do / actividade entry / acção exit / acção evento / acção Estado 2 evento(parâmetros) [condição] / acção transição Sequência de mudança de estado: - Ocorre o evento associado à transição e a condição de guarda é verdadeira - É interrompida a actividade associada ao estado de origem, se não tinha já terminado - É executada a acção á saída do estado de origem - É executada a acção associada à transição - É executada a acção à entrada do estado de destino - É iniciada a actividade associada ao estado de destino

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 198 Estados n Um estado é uma condição ou situação na vida de um objecto, durante a qual o objecto satisfaz alguma condição, realiza alguma actividade ou espera por algum evento Exemplo (relativamente ao estado civil de uma pessoa): solteira, casada,... n Escolha dos estados e relação com atributos e ligações: Foi dito anteriormente que o estado de um objecto é dado pelos valores de atributos e ligações com outros objectos que mantém num dado momento Essa definição conduz, em geral, a demasiados estados Ora, no diagrama de estados, interessa apenas distinguir estados que apresentam diferentes respostas a eventos Assim, os estados que interessa considerar aqui correspondem, em geral, a conjuntos de valores de atributos e ligações (possivelmente expressos por condições), e ignoram-se atributos e ligações irrelevantes para o comportamento do objecto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 199 Eventos n Um evento é uma ocorrência significativa que tem uma localização no tempo (instante de tempo do evento) e no espaço n No contexto de uma máquina de estados, um evento pode ter como resposta uma transição (mudança de estado) e/ou uma acção n Os eventos são instantâneos O que interessa é que se lhe possa atribuir um instante de tempo de ocorrência n Os eventos podem ser de vários tipos: Sinais - eventos simbólicos sinalizados explicitamente Chamadas - invocação de operações (porque não também o retorno?) Eventos temporais - passagem de tempo ou ocorrência de um data-hora Eventos de mudança - uma condição tornar-se verdadeira n Os eventos podem ter parâmetros [ exemplo: dígito-marcado(5) ]

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 200 Sinais (eventos simbólicos) n Sinais são modelados por classes com estereótipo «signal» Parâmetros (argumentos) do sinal são atributos da classe Hierarquias de sinais são modeladas como hierarquias de generalização n Envio de sinal representado por acção send Receptor pode ser conhecido do emissor ou não (graças a mecanismo publish/subscribe) n Sinais em linguagens de programação Sinais assíncronos, enviados imediatamente (kill, suspend,... ) ou de forma diferida (eventos em COM+) para processos concorrentes, usando primitivas do sistema operativo Sinais síncronos, em que a geração do evento provoca a chamada de rotinas que tratam o evento (event handlers) no mesmo processo, usando primitivas das linguagens de programação (eventos em C# e Visual Basic.NET) Excepções, representadas por objectos lançados com "throw" e apanhados com "catch", em que o lançamento da excepção provoca o retorno automático de vários níveis de chamadas e o salto para uma rotina de tratamento de excepções no mesmo processo

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 201 Exemplo de hierarquia de sinais «signal» Mouse Down «signal» Mouse Up «signal» Control Key Pressed «signal» Printable Key Pressed «signal» Mouse Event position «signal» Key Pressed character «signal» Event time «signal» User Input Event device

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 202 Chamadas n Um chamada representa a invocação de uma operação Para quem faz a chamada (ponto de vista do actuador), trata-se de uma acção Para quem testa se a operação foi chamada (ponto de vista do observador), trata-se de um evento n Um chamada é geralmente síncrona Quando uma operação de um objecto invoca uma operação noutro objecto, o controlo passa para o 2º objecto n Nome do evento tem a sintaxe da invocação da operação Exemplo: insert(record) Diferença entre evento e acção por contexto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 203 Eventos temporais n Evento de tempo relativo: Representa a passagem de um certo tempo desde um certo instante Notação: after(período-de-tempo) Por omissão, tempo conta desde a entrada no estado de origem da transição a que está associado o evento Também se usa a palavra chave timeout quando não se quer precisar o período de tempo Exemplo: after(5 segundos) n Evento de tempo abosluto: Representa a chegada a um certo instante de tempo (data e/ou hora) Notação: when(instante-de-tempo) Exemplo: when(11:59PM)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 204 Eventos de mudança n Um evento de mudança (change event) é um evento que representa o facto de uma condição se tornar verdadeira n Notação: when(expressão booleana) n A expressão booleana pode ser usada para marcar um tempo absoluto (ver atrás) ou para o teste contínua de uma expressão n Exemplo: when(altitude < 1000)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 205 Transições n Uma transição é uma relação entre dois estados indicando que um objecto no 1º estado realizará uma certa acção (opcional) e passará ao 2º estado quando um evento especificado ocorrer se uma condição especificada (opcional) for satisfeita n Duas transições a sair do mesmo estado devem ter eventos diferentes ou condições mutuamente exclusivas, para que o diagrama de estados seja determinístico n Se, num dado estado, ocorrer um evento que não corresponde a nenhuma transição, nenhuma transição é disparada e o evento é ignorado n Transição automática: transição sem evento Tem como evento implícito o fim da actividade associada ao estado de origem Se tiver uma condição, fica à espera que a condição seja satisfeita

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 206 Actividades n Uma actividade é uma execução contínua (ongoing execution) não atómica numa máquina de estados Tem duração Pode ser interrompida Pode ter fim (termina por si só) ou não (só termina se for interrompida) n É associada a estados Inicia-se ao entrar no estado Termina por si só ou é interrompida na saída do estado (causada por um evento) n Exemplo (num telefone): do / dá sinal de marcar

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 207 Acções n Uma acção é uma computação atómica executável que resulta numa mudança de estado ou no retorno de um valor A mudança de estado pode ser noutro objecto Não tem duração (pelo menos no modelo) e não pode ser interrompida Ocorre em resposta a um evento Exemplo (num telefone): poisa auscultador / pára sinal de marcar Acções são associadas a transições (mais comum) ou estados n Acção à entrada num estado: entry/acção equivale a associar a acção a cada transição que entra no estado n Acção à saída de um estado: exit/acção equivale a associar a acção a cada transição que sai do estado n Acção em resposta a evento interno a um estado: evento/acção difere de auto-transição, porque não são executadas acções à saída e entrada e não é interrompida a actividade associada ao estado

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 208 Exemplo: Jogo de xadrez Estado inicial (criação do objecto e início da máquina de estados) Estado final (fim da máquina de estados e destruição do objecto) EstadoTransição

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 209 Exemplo: Semáforo N O E S N S O E N O E S N O E S

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 210 Exemplo: Menu popup

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 211 Exemplo: Porta com motor Como seria este diagrama com as acções associadas às transições?

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 212 Exemplo: Telefone (fazer chamadas) Inactivo Desligado Sinal de ocupado Sinal de interrompido Tempo máximo Mensagem gravada no descanso levantado dígito(n) tempo máximo número válido número inválido número ocupado ramal ocupado resposta/ liga linha chamado desliga/desliga linha mensagem dada Ligado Tocando Ligando Discando Sinal de marcar dígito(n) tempo máximo encaminhada no descanso do/toca sinal do/ toca apito do/ passa mensagem do/ busca ligação do/ toca campaínha do/sinal ocupado lento do/ sinal ocupado rápido no descanso/ desliga linha

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 213 Subestados sequenciais

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 214 Exemplo: Estado civil estado composto (ou super-estado ou contorno) Equivale a várias transições, com origem em cada um dos subestados! Evita explosão combinatória de transições! subestados sequenciais

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 215 Exemplo: Transmissão automática Estado composto Subestados sequenciais de “Frente” Transição com origem em superestado e dirigida a sub-estado Transição dirigida a (subestado inicial de) estado composto

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 216 Subestados sequenciais n Vários estados de um diagrama (e transições entre esses estados) podem ser agrupados num único estado composto n Os primeiros estados passam a chamar-se subestados sequenciais Subestados – por estarem encaixados dentro doutro Sequenciais – por não ser possível estar em dois estados simultaneamente n Estado composto pode ser visto simplesmente como um contorno n Estados e transições agrupados no estado composto formam um diagrama de estados encaixado, podendo ter estado inicial e final n Também se chama a isto composição “ou” Estar no estado composto é estar no 1º subestado ou...ou no n-ésimo subestado n Também se chama a isto generalização de estados O estado composto é também chamado um superestado Estar num subestado é estar também no respectivo superestado

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 217 Transições com estados compostos n Podem-se definir transições com origem no estado composto Equivale a repetir a mesma transição com origem em cada um dos subestados (excepto ). Por outras palavras, os subestados herdam a transição. Simplifica-se o diagrama porque se desenha 1 transição em vez de n transições (tantas quantos os subestados), evitando-se a explosão combinatória de transições! A transição pode ser dirigida a um subestado ou a um estado externo n Podem-se definir transições com destino ao estado composto Equivale a definir a mesma transição com destino ao respectivo estado inicial (ou melhor, ao estado apontado por ), que tem de estar definido n Vantagem comum: abstracção de detalhes do estado composto O estado composto pode até ser detalhado separadamente n No entanto, também se podem definir transições que atravessam o estado composto, com origem ou destino em subestados O estado inicial é apenas um estado inicial por omissão

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 218 Propriedades de estados compostos n Um estado composto pode ter todas as propriedades dos estados simples, mas normalmente só tem o nome, que mesmo assim é opcional n Um estado composto pode ter acções à entrada e à saída Ao entrar no estado composto, executa primeira as acções à entrada no estado composto, e depois as acções à entrada no subestado de destino Ao sair do estado composto, executa primeira as acções à saída do subestado de origem, e depois as acções à saída do estado composto n A actividade do estado composto é detalhada pelos subestados e transições entre eles, isto é, pelo diagrama de estados encaixado n Em alternativa, pode-se dar um nome à actividade do estado composto (com “do/...”), e detalha-se essa actividade separadamente (com o mesmo diagrama de estados encaixado) As acções à entrada e à saída são representadas no 1º diagrama Uma actividade pode ser detalhada por um diagrama de estados ou actividade

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 219 Subestados concorrentes

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 220 Subestados concorrentes n Um estado (estado composto) pode ser dividido em duas ou mais regiões concorrentes, separadas por linhas a traço interrompido, representando subestados concorrentes (que, por sua vez, têm normalmente subestados sequenciais) n Subestados concorrentes correspondem a aspectos do objecto (grupos de atributos e ligações ou sub-objectos) que evoluem de forma mais ou menos independente n Dependências entre regiões podem ser expressas através de condições de guarda (num componente testar o estado doutro) n Também se chama a isto composição “e”: Estar no estado composto é estar no 1º e... e no nº subestado concorrente n Notar que, a um nível mais global, os objectos (e portanto os respectivos diagramas de estados) são concorrentes entre si

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 221 Exemplo: Concorrência num objecto Preparação do despertador Selecção da Banda Selecção do programa Activação do alarme Selecção do Programa banda escolhida comuta(banda)sintoniza(frequência) Selecção da Hora hora escolhida marca(hora) programa escolhido Subestados concorrentes de “Preparação do despertador” Sai quando terminarem os dois subdiagramas concorrentes Alarme ligado Ao entrar, inicia os dois subdiagramas concorrentes X E

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 222 O mesmo exemplo sem subestados concorrentes Preparação do despertador Selecção da Banda e Hora Selecção do Programa e Hora banda escolhida comuta(banda) sintoniza(frequência) marca(hora) programa escolhido marca(hora) Selecção da Hora hora escolhida marca(hora) Selecção da Banda hora escolhida programa escolhido Selecção do Programa sintoniza(frequência) comuta(banda) banda escolhida hora escolhida Tem-se (quase) o produto cartesiano dos estados do diagrama anterior!

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 223 Sincronização: separação e fusão n Separação - quando um objecto passa a fazer várias actividades concorrentemente (ordem irrelevante) transição para estado com subdiagramas concorrentes activa cada um deles n Fusão - quando as actividades concorrentes têm que terminar antes de passar ao estado seguinte subdiagramas que não estejam na fusão são automaticamente terminados Emissão (Multibanco) Preparação do/ liberta cartão pronto Concluído do/ liberta dinheiro recolhe dinheiro recolhe cartão

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 224 Conceitos avançados

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 225 Variáveis num estado n Um estado pode ter um compartimento de variáveis n Estas variáveis são atributos da classe dona do diagrama de estados, distinguidos porque são usadas ou afectadas por acções no diagrama de estados n Todos os compartimentos (nome, variáveis e actividade interna) são opcionais Typing Password password: String = “ ” fails: Integer = 0 entry / set echo invisible exit / set echo normal do / echo typing help / display help { compartimento de actividade interna { compartimento de variáveis

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 226 Transições complexas n Uma transição complexa é uma transição com múltiplos estados fonte (normalmente de subdiagramas concorrentes) ou múltiplos estados de destino (normalmente de subdiagramas concorrentes) n Representa uma separação e/ou fusão de controlo em/de fios de controlo concorrentes n Aplicável mesmo sem subdiagramas concorrentes n Desenha-se com uma barra forte (barra de sincronização): Estado fonte 1 Estado fonte n... Estado destino 1 Estado destino m... ev 1 ev n

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 227 Eventos diferidos n Uma acção possível em resposta a um evento é “defer”, que significa guardar o evento até chegar a um estado capaz de o “consumir” n É aplicável num par “evento/acção” interno a um estado n Exemplo (máquina de fax): A enviar fax chegada de fax/defer Repouso A receber faz enviar fax/defer chegada de fax enviar fax

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 228 Descrição de eventos compostos com diagramas de estados n Um evento composto corresponde a uma sequência de eventos mais simples O instante da ocorrência do evento composto é o instante da ocorrência do último evento da sequência Exemplo: o evento composto “introduzir número” é uma sequência de uma ou mais ocorrências do evento “introduzir dígito”, seguido de uma ocorrência do evento “enter” n Um evento composto pode ser definido através de um diagrama de estados (máquina de estados) que funciona como um “detector de eventos” Detector sequencial: a detecção do evento composto corresponde à chegada a um estado final com o nome do evento Detector cíclico: o evento composto é sinalizado explicitamente, podendo ser lançado vários vezes

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 229 Exemplo: Máquina de vendas (1) Inactivo moeda ( montante ) / põe balanço Recolhe dinheiro moeda(montante) / adiciona ao balanço do/ testa item e calcula troco [troco<0] escolhe(item) [item vazio] [troco=0][troco>0] do/ faz troco do/ entrega(item) cancelar / devolve moedas Diagrama pincipal:

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 230 Exemplo: Máquina de vendas (2) do/ inicializa item do/ acrescenta dígito limpa dígito(n) aceita escolhe(item) dígito(n) Detalhe do evento composto “escolhe(item)”: do/ move o braço para a fila correcta do/ move o braço para a coluna correcta do/ tira item da prateleira braço pronto tirado Detalhe da actividade “entrega(item)”:

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 231 Estados históricos (history states) n Estado histórico (dentro de um estado composto) – refere- se ao último subestado em que se encontrava o estado composto n Útil para reentrar num estado composto no subestado em que se encontrava anteriormente n Não é aplicável na primeira entrada B1 interrupt resume B2 H C estado histórico B A

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 232 Resíduos de subestados (stubs) n Aplicáveis quando se escondem os detalhes de um estado composto, mas há transições que o atravessam A C W E B F p r u s t D q A C W B p r D q abstracção s

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 233 Exemplos e exercícios

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 234 Exemplo: Rádio-despertador (a rever) 18:3589.5 FM minutos horas alarme tempo dormir desligar off radio alarme vol sintonia q obter o diagrama de estados o botão dormir faz tocar durante uma hora (desligar cala-o logo) ao chegar ao instante do alarme, começa a tocar durante 1 hora (desligar só desliga durante 10 minutos)

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 235 - Diagrama principal Desligado Funcionar do/ radio activo Despertador radio off alarme radio RuídoEstação sintoniza(freq) dessintoniza Botão de sintonia Cortado Activo ajusta(nível)/ alterar nível ajusta(nível)/alterar nível [nível=0] Botão de volume Hora actual do/ mostra hora actual Hora despertar do/ altera hora despertar botão alarme carregado botão alarme livre Display DesligadoTocar [em Estação e Activo e (Funcionar ou Despertar ou Adormecer)] [em (Ruído ou Cortado) ou (Desligado ou Armado ou Latente)] Altifalante Interruptor Rádio-despertador

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 236 - Subdiagrama Hora despertar Mostra do/ mostra hora despertar Põe minutos do / incrementa minutos despertar mod 60 botão minutos carregado botão minutos livre Hora despertar Põe horas do/ incrementa horas despertar mod 24 botão horas carregado botão horas livre

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 237 - Subdiagrama Hora actual Mostra do/ mostra hora actual Acerta minutos do/ incrementa minutos mod 60 botão minutos carregado botão minutos livre Hora actual Acerta horas do/ incrementa horas mod 24 botão horas carregado botão horas livre Altera hora do/ mostra hora actual botão tempo carregado botão tempo livre

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 238 - Subdiagrama Despertador Adormecer do/ rádio activo Latente do/ incrementa minutos mod 60 desligar/desliga 10 minutos Despertador Armado minuto [hora actual - hora despertar>60] / desliga minuto [hora_actual = hora_despertar] Despertar do/ rádio activo desligar /desliga dormir 60 minutos

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 239 Caso de estudo: Biblioteca

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 240 Estados de uma Publicação

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 241 Estados de um Sócio

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 242 Estados de uma Requisição

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 243 Exercícios n Para um caso prático: Representar o ciclo de vida de um conceito do domínio do problema (documento, entidade, etc.) através de um diagrama de estados.

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral.

Apresentações semelhantes

Apresentação em tema: "UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral.

Apresentações semelhantes

Apresentação em tema: "UML – Unified Modeling Language Ademar Aguiar, Gabriel David, João Pascoal Faria 1 UML – Visão Geral."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback