UML Diagramas de Classes UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 1 Índice Objectivo dos diagramas de classes Objectos, classes, atributos e operações Relações entre classes: associação, agregação e composição Relações entre classes: generalização Relações entre classes: dependência e concretização Restrições, elementos derivados, pré-condições e póscondições Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes e utilitários 2
Objectivo dos diagramas de classes 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) Construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projectistas (designers) e implementadores 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.) Modelos de objectos de domínio, negócio, análise e design 3 Objectos, classes, atributos e operações UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 4
Objectos Um objecto é algo com fronteiras bem definidas, relevante para o problema em causa, com estado, modelado por valores de atributos (tamanho, forma, peso, etc.) e por ligações que num dado momento tem com outros objectos comportamento um objecto exibe comportamentos invocáveis (por resposta a chamadas de operações ) ou reactivos (por resposta a eventos) 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 5 Objectos do mundo real e objectos computacionais No desenvolvimento de software orientado por objectos, procurase imitar no computador o mundo real visto como um conjunto de objectos que interagem entre si Muitos objectos computacionais são imagens de objectos do mundo real 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 Exemplos de objectos do mundo real: o Sr. João a aula de ES no dia 11/10/2000 às 11 horas 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) 6
Classes (1) No desenvolvimento de software OO, não nos interessam tanto os objectos individuais mas sim as classes de objectos 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 Um objecto de uma classe é uma instância da classe A extensão de uma classe é o conjunto de instâncias da classe 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,...} 7 Classes (2) O conjunto de todos os objectos num determinado contexto forma um universo (UoD - Universe of Discourse) As extensões das classes são subconjuntos desse universo UoD x João Aluno Curso classe x Maria x Informática objecto x Rui x Dª Rita x Sr. Silva Funcionário x Electrotecnia ligação 8
Classes (3) 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 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 9 Classes (4) Em UML, uma classe é representada por um rectângulo com o nome da classe Aluno Curso Habitualmente escreve-se o nome da classe no singular (nome de uma instância), com a 1ª letra em maiúscula Para se precisar o significado pretendido para uma classe, devese 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 10
Atributos de instância O estado de um objecto é dados por valores de atributos (e por ligações que tem com outros objectos) 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 Atributos são definidos ao nível da classe, enquanto que os valores dos atributos são definidos ao nível do objecto 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 11 Atributos de instância Atributos são listados num compartimento de atributos (opcional) a seguir ao compartimento com o nome da classe Uma classe não deve ter dois atributos com o mesmo nome Os nomes dos tipos não estão pré-definidos em UML, podendo-se usar os da linguagem de implementação alvo classe compartimento de atributos nome do atributo tipo de dados Pessoa nome: string data de nascimento: date peso: real = 75 kg valor inicial por omissão 12
Operações de instância 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 Objectos da mesma classe têm as mesmas operações 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 Princípio do encapsulamento: acesso e alteração do estado interno do objecto (valores de atributos e ligações) controlado por operações Nas classes que representam objectos do mundo real é mais comum definir responsabilidades em vez de operações compartimento de operações nome: string morada: string Pessoa setmorada(novamorada:string): bool 13 Atributos e operações estáticos ( de instância) 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 Operação estática: não é invocada para um objecto específico da classe Notação: nome sublinhado 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 14
Visibilidade de atributos e operações 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) 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 15 Multiplicidade de classes e atributos Multiplicidade de classe: número de instâncias que podem existir por omissão, é 0.. 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 16
Relações entre classes: associação, agregação e composição UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 17 Associações binárias Participante-1 papel-1 Nome da associação papel-2 Participante-2 Uma associação é uma relação entre objectos das classes participantes (um objecto de cada classe em cada ligação) Não gera novos objectos Matematicamente,uma associação binária é uma relação binária, i.e., um subconjunto do produto cartesiano das extensões das classes participantes Assim como um objecto é uma instância duma classe, uma ligação é uma instância duma associação Pode haver mais do que uma associação (com nomes diferentes) entre o mesmo par de classes Papéis nos extremos da associação podem ter indicação de visibilidade (pública, privada, etc.) 18
Multiplicidade de associações binárias Muitos-para-Muitos Muitos-para-1 1-para-1 Professor Curso Aluno 1 Curso Curso 1 1 Plano de Curso (sem restrições ) 19 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 20
Associação reflexiva Pode-se associar uma classe com ela própria (em papéis diferentes) pai 0..1 Pessoa filho filho mãe 0..1 21 Nome de associação A indicação do nome é opcional O nome é indicado no meio da linha que une as classes participantes Pode-se indicar o sentido em que se lê o nome da associação Empresa empregador Trabalha-para Emprega empregado Pessoa 22
Associações unidireccionais As associações são classificadas quanto à navegabilidade em: bidireccionais (normal) unidireccionais Class-1 Class-1 Class-2 Class-2 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) 23 Classe-Associação Class-1 Association Name Class-2 Association Name link attribute... link operation... reúne as propriedades de associação e classe 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 o nome também pode ser colocado nos dois sítios não é possível repetir combinações de objectos das classes participantes na associação 24
Associações n-árias Notação Association Name Class-1 role-1 role-3 Class-3 role-2 Class-2 Multiplicidade Class-1 0..1 Class-3 Class-2 a cada par de objectos das restantes classes (1 e 2), correspondem 0 ou 1 objectos da classe 3 25 Atributos versus Associações 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 Exemplo: País nome: string capital: string capital: Cidade 1 0..1 Pertence a Cidade 1 nome: string capital 26
Associações qualificadas Associação Classe A qualificador Classe B Qualificador: lista de um ou mais atributos de uma associação utilizados para navegar de A para B "Chave de acesso" a B (acesso a um objecto ou conjunto de objectos) a partir de um objecto de A uma Pessoa pode ser sócia de vários clubes para cada par Clube + nº de sócio Clube nº de sócio 0..1 Pessoa nome morada 27 Agregação Associação com o significado contém (é constituído por) / faz parte de (part of) Relação de inclusão nas instâncias das classes Hierarquias de objectos Exemplo: Equipa 0..1 Jogador Uma equipa contém 0 ou mais jogadores Um jogador faz parte de uma equipa (num dado momento), mas também pode estar desempregado 28
Composição 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 Membros-objecto em C++ 29 Composição: notações alternativas Window 1 1 1 scrollbar 2 title 1 body 1 Slider Header Panel Window scrollbar: Slider 2 title: Header 1 Window scrollbar[2]: Slider title: Header body: Panel body: Panel 1 (sub-objectos no compartimento dos atributos) 30
Relações entre classes: generalização UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 31 Generalização Pessoa super-classe generalização Aluno especialização sub-classe 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 x x x sub-classe x x objecto extensão (sub-classe) extensão (super-classe) 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 32
As três facetas da generalização Substitutabilidade onde se espera um objecto da super-classe pode-se passar um objecto duma subclasse Herança de interface a subclasse herda as assinaturas (e significados) das operações da super-classe Herança ou overriding de implementação a subclasse pode herdar as implementações das operações da superclasse, 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 33 Polimorfismo 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 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 34
Exemplo em C++ Pessoa nome : string datanascimento : Data Pessoa(string, Data) getnome() : string getdatanascimento() : Data getidade() : int setnome(string) : void setdatanascimento(data) : void imprime() : void 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; }; curso : string Aluno Aluno(string nm, Data, string crs) getcurso() : string setcurso(string) : void imprime() : void Ferramenta: Microsoft Visual Modeler class Aluno : public Pessoa { private: string curso; public: Aluno(string nm, Data, string crs); string getcurso() const; void setcurso(string); virtual void imprime() const; }; 35 Hierarquias de classes 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! curso : string Aluno Pessoa nome : string datanascimento : Data Aluno(string nm, Data, string crs) getcurso() : string setcurso(string) : void imprime() : void AlunoDoutoramento Pessoa(string, Data) getnome() : string getdatanascimento() : Data getidade() : int setnome(string) : void setdatanascimento(data) : void imprime() : void (...) categoria : string Professor Professor(string nm, Data, string ctg) getcategoria() : string setcategoria(string) : void imprime() : void 36
Notações alternativas para hierarquias de classes Pessoa Aluno Professor Pessoa Aluno Professor 37 Subclasses sobrepostas ( disjuntas) caso em que um objecto da superclasse pode pertencer simultaneamente a mais do que uma subclasse indicado por restrição {overlapping} o contrário é {disjoint} (situação por omissão?) Superclass ou Superclass {overlapping} {overlapping} Subclass-1 Subclass-2 Subclass-1 Subclass-2 38
Subclasses incompletas ( completas) caso em que um objecto da superclasse pode não pertencer a nenhuma das subclasses indicado por restrição {incomplete} o contrário é {complete} (situação por omissão?) Funcionário Técnico {incomplete} Comercial 39 Herança múltipla ( simples) ocorre numa subclasse com múltiplas super-classes geralmente suportada por linguagens de programação OO Estudante curso Académico nome e-mail Professor categoria {overlapping} pelo menos conceptualmente, existe uma super-classe comum Só faz sentido assim! Professor-Estudante redução de horário herda propriedades de Estudante e Professor e, indirectamente, de Académico (uma única vez!) 40
Classificação dinâmica ( estática) classificar objecto: atribuir classe a objecto caso em que a(s) classe(s) a que um objecto pertence pode(m) variar ao longo da vida do objecto indicado por estereótipo «dynamic» geralmente não suportada por linguagens de programação OO Pessoa tarefa «dynamic» atributo discriminante (atributo de pessoa que indica a subclasse a que pertence) Gestor Engenheiro Vendedor Uma pessoa que num dado momento tem a tarefa de gestor, pode noutro momento ter a tarefa de vendedor, etc. 41 Classificação múltipla ( simples) 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) geralmente não suportado pelas linguagens de programação OO (pode então ser simulada por agregação de papéis) Homem Mulher sexo função Pessoa paciente Paciente Médico Enfermeira Fisioterapeuta exemplo de combinação legal: {Mulher, Paciente, Enfermeira} 42
Classes e operações abstractas ( concretas) Classe abstracta: classe que não pode ter instâncias directas pode ter instâncias indirectas pelas subclasses concretas Icon origin: Point display() getid(): Integer 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++ Notação : nome em itálico ou propriedade {abstract} RectangularIcon height: Integer width: Integer Button display() ArbitraryIcon edge:linecollection display() isinside(p:point):bool Fonte: The UML User Guide, Booch et al 43 Associação versus Agregação / Composição versus Generalização generalização Pessoa classe Professor José Cursos e disciplinas Aluno João Curso de Modelação de Software UML Maria associação objecto VDM++ agregação ou composição 44
Exemplo: meta-modelo parcial Generalização superclasse subclasse Classe 1 nome Extremo de Associação 2.. 1 multiplicidade papel visibilidade 2 no caso de agregação Relação Associação nome Agregação Classe-Associação Composição 45 Relações entre classes: dependência e concretização UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 46
Relação de dependência 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 Exemplo típico: classe-1 que depende de outra classe-2 porque usa operações ou definições da classe-2 Úteis para gestão de dependências cliente servidor 47 Relação de concretização (realization) 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) Difere da generalização porque há apenas herança de interface e não herança de implementação LinkedStack XMLDocument Colaboração «type» Stack «interface» ISerializable Caso de utilização 48
Dependência e concretização Aparecem frequentemente combinados Cliente usa o servidor sem dele depender directamente (depende apenas da interface ou contracto que o servidor implementa) cliente contracto ou interface servidor 49 Restrições, elementos derivados, pré-condições e pós-condições UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 50
Restrições Uma restrição especifica uma condição que tem de se verificar no estado do sistema (objectos e ligações) 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) Podem ser formalizadas em UML com a OCL - "Object Constraint Language" Também podem ser formalizadas (como invariantes) numa linguagem de especificação formal como VDM++ 51 Restrições em classes Pessoa nome datanascimento localnascimento datafalecimento {chave candidata: (nome, datanascimento, localnascimento)} {datafalecimento > datanascimento} Factura número data {chave candidata: (número)} 1 LinhaFactura número artigo quantidade valor {chave candidata: (factura, número)} 52
Restrições em associações {ordered} Factura LinhaFactura 1 uma factura é constituída por um conjunto ordenado de 0 ou mais linhas Pessoa 1 Membro-de {subset} Director-de Comité Conta {xor} Pessoa Empresa associações mutuamente exclusivas chefe empregado Pessoa 0..1 subordinado empregador 1 Pessoa.empregador = Pessoa.chefe.empregador Empresa 53 Elementos derivados Elemento derivado (atributo, associação ou classe): elemento calculado em função doutros elementos do modelo Notação: barra / antes do nome do elemento derivado Um elemento derivado tem normalmente associada uma restrição que o relaciona com os outros elementos 54
Exemplo de elementos derivados Empresa 1 empregador 1 /TrabalhaEmEmpresa {Pessoa.empregador = Pessoa.departamento.empresa} Departamento 1 TrabalhaEmDepartamento Pessoa datanascimento /idade {idade = dataactual() - datanascimento} data valor Movimento / TotalMensal mês valor {valor = (select sum(valor) from Movimento where month(data)=mês)} 55 Pré-condições e pós-condições Semântica de operações pode ser captada através de précondições e pós-condições Pré-condição: uma condição nos argumentos e estado inicial do objecto, a verificar na chamada (início) da operação 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 Podem ser expressas em UML através da OCL (Object Constraint Language) 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 56
Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes, utilitários UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 57 Classes parametrizadas (templates) classe parametrizada parâmetros actuais data [k] : T FArray «bind» (Point,3) T k: Integer parâmetros formais generalização, porque não se podem acrescentar propriedades! ThreePoints ou Farray<Point,3> C++ classe ligada ("bound") template <class T, int k> class FArray { public: T[k] data; }; typedef Farray<Point,3> ThreePoints; 58
Interfaces 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 Relação de concretização de muitos parta muitos entre interfaces e classes de implementação 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 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) 59 Interfaces: notações alternativas Cliente depende só da interface e não da implementação InterfaceClass ImplementationClass attributes operations ClientClass ou operations «interface» InterfaceClass ImplementationClass attributes operations ClientClass relação de concretização 60
Tipos 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 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 61 Tipos: exemplo maxsize:integer «type» FinitePriorityQueue isfull():boolean relação de concretização HeapFinitePriorityQueue - elems [0..maxSize]: T - size: Integer = 0 + insert(value: T, priority: Integer) + deletemax():t + isempty(): Boolean + isfull(): Boolean - HeapifyUp - HeapifyDown T maxsize:integer «type» PriorityQueue elems: set of (priority: Integer, value:t) insert(value:t, priority:integer) deletemax():t isempty():boolean «bind» (Paciente, 100) HeapFilaPacientes T 62
Meta-classes Uma meta-classe é uma classe cujas instâncias são classes Notação: classe com estereótipo «metaclass» Usadas geralmente em meta-modelos Relação de instanciação (entre classe e meta-classe) pode ser indicada por dependência com estereótipo «instanceof» «metaclass» SYSCLASSES name «instanceof» Class-1 63 Utilitários Um utilitário é um agrupamento de variáveis globais e procedimentos como classe Pode ser implementado por classe em que todos os atributos e operações são estáticos Notação: classe com estereótipo «utility» pi: Real «utility» MathPack sin(ang: Real): Real cos(ang: Real): Real 64
Estereótipos de classes em modelos 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: business actor actor em relação ao negócio (cliente ou outra entidade ou sistema que interage com o negócio); actor externo business worker 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 business entity 65 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 actor em relação ao sistema de software (pode ser interno ou externo ao negócio) objecto de fronteira (formulário, janela, etc.) boundary control objecto de controlo (controla sequência de funcionamento, transacções, etc.; estabelece ligação entre objectos de fronteira e entidades) entity objecto passivo que guarda estado mais ou menos persistente 66
Caso de estudo e exercícios UML Diagramas de Classes v.1.2, João Pascoal Faria, Outubro de 2002 67 Caso de estudo (Biblioteca): modelo de domínio Autor nome nacionalidade Publicação isbn nº de património título ano editora data de aquisição custo contador de consultas / estado : (disponível,emprestada) 1 Biblioteca nome morada telefone 1 1 Sócio número nome morada telefone data de inscrição validade da inscrição estado : (activo,inactivo) 1 Só se considera a existência dma instância Requisição número data de requisição prazo de devolução data de devolução 68
Caso de estudo (Biblioteca): modelo de desenho - camada de lógica de negócio Biblioteca (from Lógica de Negócio - Recursos) nome morada telefone estatísticautilização() Publicação (from Lógica de Negócio - Recursos) A rever! isbn título ano editora data da aquisição custo / estado : (disponível, emprestada) contador de utilizações : int : = 0 <<static>> registarpublicação(isbn, título, autores) <<static>> listarpublicações(filtro) Autor (from Lógica de Negócio - Recursos) nome nacionalidade <<static>> registarautor(nome, nacionalidade) <<static>> procurarautor(nome, nacionalidade) : Autor <<static>> listarautores(filtro) 1 Requisição (from Lógica de Negócio - Clientes) 1 número : int data da requisição : date : = curdate prazo de devolução : date data da devolução : date Sócio (from Lógica de Negócio - Clientes) número : int nome : string morada : string telefone : int data de inscrição validade da inscrição / estado : (activo,inactivo) <<static>> registarsócio(nome, morada, telefone) : int registardevolução(data) <<static>> registarrequisição(publicação, sócio) 69 Exercício 1 Refinar o caso de estudo (modelo de domínio e modelo de desenho da camada de lógica de negócio) de acordo com os seguintes requisitos: Uma publicação pode ter vários exemplares Uma publicação pode ser um livro ou uma revista. Uma revista contém artigos, sendo os autores definidos artigo a artigo As publicações podem ser agrupadas em colecções; nesse caso, a editora é definida ao nível da colecção Possibilidade de ficarem requisições em lista de espera Refinar o modelo de domínio com restrições de integridade Elaborar modelos de análise e de negócio 70
Exercício 2 (ASI 24/4/97) Um jornal desportivo pretende manter informação relativa a diversos campeonatos de futebol (1º divisão nacional, 2ª divisão nacional, campeonatos regionais, etc.), de acordo com o seguintes pressupostos: Em cada campeonato participam várias equipas. Cada campeonato está organizado numa sequência de jornadas. Numa jornada de um campeonato realizam-se diversos jogos em paralelo em que se defrontam todas as equipas duas a duas (um equipa visitada e uma equipa visitante em cada jogo). Cada equipa participa num e num só jogo por jornada. Relativamente a cada jogo interessa saber a data-hora e local da sua realização, o árbitro, o resultado do jogo, os jogadores efectiv os, e eventos importantes (com o tempo em que ocorreram e a indicação dos jogadores envolvidos), tais como golos, cartões, expulsões e substituições. Elabore um diagrama de classes relativamente a esta realidade, com atributos e relações entre classes 71 Exercício 3 Elaborar um diagrama de classes em UML relativo a um módulo que permite construir passo a passo interrogações simples (queries) em SQL, de acordo com as seguintes requisitos: As interrogações que interessa tratar são da forma: selectcoluna 1,..., coluna n fromtabela 1 alias 1,..., tabela m alias m where (... and... and...) or... or (... and... and...) order by coluna 1 asc/desc,..., coluna k asc/desc As partes de where e order by são opcionais. Na parte de selectapenas se admite uma lista de nomes de colunas e não expressões genéricas. Na parte de from apenas se indica uma lista de nomes de tabelas. A seguir ao nome de uma tabela pode-se indicar um alias (nome a usar localmente na interrogação). A mesma tabela pode aparecer mais do que uma vez na parte de from, com aliases diferentes. A parte de where está na forma normal disjuntiva (disjunção de conjunções). Os operandos da conjunção são termos ou termos negados (precedidos de not). Cada termo aplica um operador de comparação a um ou mais operandos. 72
Exercício 3 (cont.) Os operadores de comparação com um operando são is null e is not null. Os operadores de comparação com dois operandos são =, <>, >, >=, <, <=, like e not like. O único operador de comparação com três operando é o operador between... and. Um operando é uma constante (número ou string) ou uma referência a uma coluna de uma tabela mencionada na parte de from. As classes devem disponibilizar operações para: - registar (adicionar) uma tabela - registar uma coluna numa tabela - criar um query inicialmente vazio - preencher um query incrementalmente: - adicionar uma tabela à parte de from de um query (as tabelas são adicionadas uma a uma) - adicionar uma coluna à parte de select de um query (as colunas são adicionadas uma a uma) - adicionar uma coluna à parte de orderby de um query (as colunas são adicionadas uma a uma) - acrescentar uma conjunção (inicialmente vazia) à parte de where - criar um termo e acrescentá-lo a uma conjunção da parte de where - obter o query em string em SQL - obter o query em string em XML Opcionalmente, implementar em Java, C# ou VB.NET e escrever um pequeno programa de teste 73