ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML CAP. 6. UML MODELAÇÃO DA ESTRUTURA - DIAGRAMA DE CLASSES Tópicos Diagrama de Classes Perspetivas dos Diagramas de Classes Associações Atributos Operações Visibilidade dos Atributos e Operações Generalização Restrições Conceitos Avançados Quando Utilizar os Diagramas de Classes 2 Diagrama de Classes 3 Diagrama de Classes 4 Técnica central em qualquer método orientado para objetos virtualmente todos os métodos incluem alguma variação desta técnica. O diagrama de classes É uma descrição formal da estrutura de objetos num sistema. Descreve os tipos de objetos no sistema, e os vários tipos de relacionamentos estáticos entre eles. Expressam, de uma forma geral, a estrutura estática do sistema em termos das classes e relacionamentos entre essas classes. Descrevem as classes - descrições abstratas e condensadas de um conjunto de objetos do domínio da aplicação, caracterizadas pelos seus: nome (ou identificador) deve facilitar a compreensão do que a classe é e não o que faz qualquer classe deve ter um nome (mesmo que genérico e provisório) atributos exemplo:a_ser_definido operações restrições os relacionamentos estáticos entre as classes associações (por ex., um cliente pode alugar vários vídeos) subtipos (por ex., uma enfermeira é um tipo de pessoa)

Diagrama de Classes 5 Diagrama de Classes 6 A classe representada no exemplo é: Os atributos das classes: identificada pelo nome Triângulo Triangulo Representam-se por baixo do nome Triangulo tem como atributos base e altura executa a operação area(), a partir dos atributos base altura da classe. Pode apenas ser escrito o nome de um atributo ou pode ser colocada também base: int altura: int está sujeita à restrição area() informação relativa ao seu tipo. area() {area <= 300} que limita a 300 Os nomes dos atributos devem começar o valor máximo da área a calcular por minúsculas e quando são compostos Os nomes das classes devem começar por maiúsculas e quando são compostos por mais de uma palavra, {area <= 300} por mais de uma palavra, a primeira letra de cada palavra deve ser maiúscula (excetuando a primeira). {area <= 300} a primeira letra de cada palavra deve ser maiúscula. restrição restrição Diagrama de Classes 7 Diagrama de Classes 8 As operações das classes: Representam-se por baixo dos atributos. Pode apenas ser escrito o nome da operação ou pode ser colocada também informação relativa ao tipo de dados que devolve, ou pode ainda ser colocada informação relativa aos parâmetros que recebe e seus tipos. Os nomes das operações seguem as mesmas regras dos nomes dos atributos. Triangulo base: int altura: int area(): int {area <= 300} A forma usada para representar as classes depende do seu fim: Numa fase de análise, usar uma Triangulo representação simplificada Na fase de desenho devem ser Triangulo incluídos mais detalhes base: int altura: int area(): int restrição As classes estão relacionadas usando as mesmas relações estudadas para os casos de uso: inclusão, generalização e associação.

Diagrama de Classes 9 Diagrama de Classes 0 A relação de inclusão indica que uma classe usa a outra; é normalmente usada quando uma classe é usada como argumento numa operação de outra classe. A generalização É uma relação entre uma classe geral (a superclasse ou pai) e uma ou mais classes mais específicas (subclasses ou filhos); As classes filho herdam todos os atributos e operações da classe pai e podem ter mais atributos e operações que aqueles que herdam. Se uma operação num filho tem o mesmo nome da do pai está a fazer um override (obrepôr-se) à do pai. A associação É uma relação estrutural entre duas classes. Exemplo: Perspectivas dos Diagramas de Classes Perspectivas dos Diagramas de Classes 2 As classes podem ser entendidas sob três perspetivas: Conceptual a classe exprime um conceito abstrato no domínio de estudo De especificação a classe é escrita pensando já em termos de software, mas é encarada de um ponto de vista exterior e não em termos de implementação (i.e., pensa-se nas interfaces, mas não na sua caracterização interna) De implementação a classe é descrita pensando já na forma como vai ser implementada Perspetiva conceptual desenha-se a classe sem pensar no tipo de implementação que vai ter (i.e., é independente da linguagem de programação que vai ser utilizada) Perspetiva de especificação é por vezes usado o conceito de tipo para designar as interfaces, quando ainda não se pensou na sua forma de implementação, que pode ser variada. De um modo geral, há vantagem em pensar mais na perspetiva de especificação do que na perspetiva de implementação, embora a segunda seja hoje mais popular. É fundamental reconhecer sempre em que perspetiva se está a desenhar ou a ler um diagrama de classes

Associações 3 Associações 4 As associações Representam relacionamentos entre instâncias de classes. São representadas através de uma linha que une as classes associadas. São caracterizadas por possuir um nome e, quando necessário, incluir o papel que as classes têm na relação. O nome das associações é dado, de preferência, utilizando formas verbais ativas ( trabalha para ) ou passivas ( é empregado por ), embora haja quem defende o uso de substantivos em análise OO, uma vez que assim é salientado o carácter estático da associação. Exemplo: O papel de uma pessoa é ser oempregado, enquanto que o papel de uma empresa é ser oempregador Alguns analistas dão nomes a todas as associações. Outros preferem só atribuir nomes às associações que tenham a ganhar em clareza com a existência de um nome papel Pessoa Empresa Empregado Emprego Empregador nome Associações: Associação Reflexiva 5 Associações: Perspetiva Conceptual - Papéis 6 Uma classe pode ter associações consigo própria, significando que um objeto da classe se relaciona com um ou mais objetos da mesma classe. Este tipo de relação surge, tipicamente, em relações de hierarquia (o chefe de um conjunto de empregados é também um empregado) Exemplo: associação na mesma classe Empregado Subordinado -Nome -Morada Papéis: O papel descreve como uma das classes vê a outra classe na associação. Cada associação binária tem dois papeis ( roles ), que correspondem a cada um dos dois sentidos do relacionamento Um papel pode ser caracterizado explicitamente por uma etiqueta que se coloca, em itálico a meio, entre as duas classes. Se não houver etiquetas, o papel fica caracterizado pela classe de destino. Exemplo: o papel de um professor élecionar disciplina, enquanto que o papel de uma disciplina éserlecionada por professor Chefe Chefiar Professor Lecionar Ser lecionada Disciplina

Associações: Perspetiva Conceptual - Multiplicidade 7 Associações: Perspetiva Conceptual - Multiplicidade 8 Multiplicidade ou Cardinalidade: Um papel tem multiplicidade (ou cardinalidade), que indica quantos objetos de uma dada classe podem estar ligados a um objeto da outra classe. No exemplo a seguir o * significa que cada professor pode ensinar várias disciplinas, e que não há nenhuma disciplina que possa ser ensinada por vários professores. Se fosse pretendido indicar ser possível algumas disciplinas não serem lecionadas por algum professor, utilizaríamos 0.. Professor 0.. * Disciplina Lecionar Ser lecionada Professor * Lecionar Ser lecionada As cardinalidades representam limites superiores * significa qualquer coisa entre 0 e vários representa o valor um e só um Disciplina Formas mais comuns de multiplicidade: 0.. - Opcional.. ou - Obrigatório existir um objeto M..N - Um valor do intervalo estabelecido (de M a N);..0 - de um a dez 0..* ou * - Zero a qualquer inteiro positivo objetos da classe..* - Um a qualquer inteiro positivo objetos da classe Associações: Perspetiva Conceptual - Multiplicidade 9 Associações: Perspetiva Conceptual Classe-associação 20 Exemplos de multiplicidades mais frequente Numa relação de associação entre classes, a associação pode também ter os seus próprios atributos (e eventualmente operações), devendo ser, por conseguinte, modelizada também como uma classe. Este tipo de classes designa-se por classe-associação. Estas são representadas por umalinhaatracejado a ligá-la à linha da associação entre as duas classes.

Associações: Perspetiva Conceptual Classe-associação 2 Associações: Perspetiva Conceptual Associações N-árias 22 Exemplo: a associação entre as classes Pessoa e Empresa traduz as tarefas que cada empregado realiza na empresa. Para cada tarefa é mantido um conjunto de atributos. A classe-associação Tarefa é representada visualmente como qualquer outra classe, mas apresenta uma linha a tracejado a ligá-la à linha da associação. A maioria das associações são binárias, pois ligam duas classes. Mas, uma classe pode estar ligada a mais do que uma outra, através das denominadas associações N-árias. Estas podem ser representadas por um losangulo apontado para as várias componentes da associação. Exemplo: Sala a classe Disciplina resulta da associação entre as classes Aluno, Professor e Sala. Aluno Professor Disciplina Data_Início Data_Fim Associações: Perspetiva Conceptual - Multiplicidade 23 Associações: Perspetiva Conceptual - Multiplicidade 24 Exemplo de uma associaçãoternária e de uma classe-associação: A associação Disciplina relaciona as classes Professor, Aluno e Sala. Caso a associação tenha também atributos e/ou operações próprias, cria-se uma classe-associação, a qual é ligada ao losango por uma linha a tracejado. Sala Sala As associações N-árias podem geralmente ser transformadas em várias relações binárias entre a classe-associação e as restantes classes participantes. No entanto, se for esta a estratégia adotada deve ser assinalado esse facto (por exemplo, através de um estereótipo ou de uma anotação) junto à classe-associação. Sala Aluno Disciplina Professor Data_Início Data_Fim Aluno Disciplina Data_Início Data_Fim Professor Aluno Disciplina Disciplina Data_Início Data_Fim Professor

Associações: Perspectiva de Especificação 25 Associações: Perspectiva de Implementação 26 As associações representam responsabilidades: No diagrama isso significa que há um ou mais métodos associados a Cliente que definem que Encomenda(s) é que um cliente fez Do mesmo modo haverá métodos em Encomenda que informam de que Cliente fez determinada encomenda, e de que Linha(s) de Encomenda constituem uma Encomenda Estas responsabilidades não implicam, no entanto, estruturas de dados. O diagrama exprime apenas as interfaces e nada mais. As associações representam agora a existência de ponteiros nos dois sentidos, entre as classes ligadas pela associação No diagrama isso significa que Encomenda tem um campo que é uma coleção de ponteiros para Linha(s) de Encomenda, e um ponteiro que aponta para Clientes A este nível não se podem tirar, a partir das associações, quaisquer conclusões acerca das interfaces. As operações sobre as classes é que darão essa informação. Associações: Navegabilidade 27 Associações: Navegabilidade 28 As associações descrevem a rede de relações estruturais que existem entre as classes e que dão origem às ligações entre os objetos, instâncias dessas classes. Essas ligações podem ser vistas como canais de navegabilidade entre os objetos. Por omissão, as associações são navegáveis nos dois sentidos, embora em alguns casos, só interesse um dos sentidos da navegabilidade. Exemplo: as instâncias do objeto A veem as instâncias do objeto B, mas as instâncias do objeto B, não veem as instâncias do objeto A. A B Quando se pretende exprimir a navegabilidade num só sentido, colocase uma seta sobre o papel para o qual a navegabilidade é possível Temos assim responsabilidades assimétricas Exemplo com navegabilidade: Encomenda Cliente significa queencomenda tem a responsabilidade de dizer a quecliente se destina, mascliente não tem a responsabilidade de dizer queencomendas lhe correspondem. Podia-se fazer o mesmo tipo de considerações acerca da navegabilidade entre Linha de Encomenda eproduto Encomenda datarecebida éprepaga número:string preço:money Despacha() Fecha() * Linha de Encomenda quantidade: inteiro preço: money estásatisfeita:booleano * Produto * {se Encomenda.cliente.regimeCrédito é "fraco", então Encomenda.éPrepaga tem de ser verdadeiro} nome Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() endereço facturaparamês(inteiro) * 0.. Empregado Cliente regimecrédito(): string Cliente Individual cartãocrédito# {regimecrédito == "fraco"}

Associações: Navegabilidade 29 Associações: Navegabilidade 30 A navegabilidade constitui um aspeto importante dos diagramas de implementação e de especificação, mas não a nível conceptual É frequente ver-se um diagrama conceptual que começa sem navegabilidade e que depois se transforma num diagrama de especificação ou implementação, pela adição das navegabilidade. Tem-se uma associação unidirecional quando só há navegabilidade num sentido; bidirecional quando as navegabilidades são nos dois sentidos. Uma associação que só pode ser navegada num sentido pode ser vista como uma meia associação, mostrando uma assimetria nos requisitos de comunicação. Uma associação sem setas é entendida como bidirecional, ou uma associação cujas navegabilidades não foram ainda definidas: deve definir-se qual das interpretações se adota; no caso dos diagramas a nível de especificação e de implementação é mais frequente adotar-se a segunda Se uma associação for bidirecional, isso significa que os dois papeis são inversos um do outro. Esta propriedade é válida para as três perspetivas (conceptual, de especificação e de implementação) Atributos 3 Operações 32 Os atributos são características das classes No caso mais geral, a notação para um atributo especifica o seu nome, tipo e valor por omissão (default), bem como a sua visibilidade Em UML, teremos: visibility name: type = defaultvalue O conceito de visibilidade (visibility) é descrito mais à frente Os atributos têm um valor único de cada vez Em geral os diagramas não indicam se um atributo é opcional ou obrigatório (embora, em rigor, devesse fazê-lo) As operações correspondem aos métodos da classe. A sintaxe completa em UML para uma operação é a seguinte: visibility name(parameter list): type = return-type-expression {property-string} onde: visibility (visibilidade) será descrita mais à frente name é uma cadeia de caracteres parameter-list contém argumentos (opcionais) cuja sintaxe é a mesma dos atributos return-type-expression é uma especificação opcional, property-string indica valores de uma propriedade que se aplica à operação

Operações 33 Operações 34 É útil distinguir entre operações que alteram e não alteram o estado de uma classe Uma interrogação (query) é uma operação que obtém o valor de uma classe sem alterar o seu estado observável. As operações que alteram o estado observável são chamadas de modificadores. As interrogações podem ser executadas por qualquer ordem, mas os modificadores exigem cuidados com a sequência de execução. O melhor é não misturar operações dos dois tipos citados. Outras designações: métodos de obtenção (gettingmethods) - devolvem o valor de um campo (e não fazem nada mais) métodos de fixação (settingmethods) - que colocam um valor num campo (e nada mais fazem) Também se deve reconhecer a distinção entre operação e método: Uma operação é algo que se evoca sobre um objecto (a chamada ao procedimento); já o método é o corpo do procedimento. É frequente confundirem-se os dois, mas importa fazer notar que a operação não é mais do que a invocação do método. Havendo polimorfismo, operação e método são distintos. Visibilidade de Atributos e Operações 35 Visibilidade de Atributos e Operações 36 A UML define três tipos de visibilidade para os atributos e operações: Exemplo: pública (simbolizada através do prefixo + ) que torna o elemento visível a todos os clientes da classe; protegida (simbolizada través do prefixo # ) que torna o elemento visível às subclasses da classe (aos respetivos descendentes); privada (simbolizada através prefixo - ) que torna o elemento apenas visível à própria classe Embora a indicação da visibilidade nem sempre figure de forma Privado Público Cliente - BI - Nome - Morada - Telefone # Registar( ) + Alterar Dados( ) + CalcularIdade( ) Protegido explícita nos diagramas de classes, isso não significa que ela não seja definida no modelo.

Generalização 37 Generalização 38 A Generalização é um caso especial no diagrama de classes noção de supertipo (superclasse) e subtipo (subclasse) na perspetiva de uma relação pai-filho Especifica o relacionamento entre um elemento geral e um elemento mais específico. O termo generalização especifica uma perspetiva focada numa classificação de hierarquia. Exemplo: um animal é um conceito mais geral do que um gato, um cão ou um guaxim. Inversamente, um gato é um conceito mais específico do que um animal. Em UML preferiu-se utilizar o termo generalização em vez do termo herança, já nosso conhecido. As classes obtidas por herança são denominadas subtipos (exceto no caso dos diagramas de implementação, em que são designadas por subclasses) O elemento mais específico contém informação que lhe é particular, desde que continue completamente consistente com a descrição do elemento mais geral. Generalização 39 Generalização 40 Um relacionamento de generalização significa um é um ou é um tipo de. Exemplo: um gato é um animal. O relacionamento de generalização é representado através de uma seta cuja ponta é um triângulo vazio, que aponta da classe mais especializada para a mais geral. Animal Gato Cão Guaxim No diagrama distinguem-se os clientes institucionais e os clientes individuais, que, tendo algumas diferenças entre si, têm também algumas semelhanças. Essas semelhanças podem ser colocadas na classe cliente (o supertipo) ficando as outras classes (os subtipos) com as características que são diferentes. Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Subtipos regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Supertipo

Generalização 4 Generalização: Perspetiva Conceptual e de Especificação 42 As classes podem ter várias superclasses. Quando é esse o caso, a generalização diz-se múltipla e várias setas são desenhadas da subclasse para as várias superclasses. A classetapetesvoadores tem dois antecessores distintos: a classetapetes, e Tapetes Veículos a classeveículos. Terrestres Aéreos Tapetes voadores Na perspetiva conceptual pode-se dizer que cliente institucional será um subtipo de cliente se todas as instâncias de cliente institucional forem também, por definição, instâncias de cliente. A ideia chave é que tudo o que se estabelecer para cliente (associações, atributos, operações) é também válido para cliente institucional. Na perspetiva de especificação, a generalização significa que a interface Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Subtipo regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Supertipo do subtipo tem que incluir todos os elementos da interface do supertipo. Dizse que a interface do subtipo está conforme com a interface do supertipo. Generalização: Perspetiva de Implementação 43 Generalização: Perspetiva de Implementação 44 Na perspetiva de implementação, A generalização está associada ao fenómeno de herança das linguagem de programação orientadas para objetos. Fala-se aqui de subclasse e não de subtipos e considera-se que a subclasse herda todos os métodos e campos da superclasse, podendo os métodos da subclasse sobrepor-se aos métodos herdados. O conceito de herança está presente, pois que as subclasses ( filhos ) herdam da superclasse ( pai ) a estrutura em termos de atributos e operações. Assim, está implícito que As subclasses Cliente Institucional e Cliente Individual possuem um nome, e um endereço. Cliente Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito regimecredito(): string Cliente Individual cartãocrédito# avisa() facturaparamês(inteiro) {regimecrédito()=="fraco"} Subclasse Superclasse

Restrições 45 Restrições 46 O próprio facto de se desenhar um diagrama de classes significa que se estão a respeitar restrições. Os conceitos de associação, de atributo ou de generalização são, afinal de contas, formas de especificar restrições. Apesar disto, os conceitos chave dos diagramas de classe não permitem exprimir todas as restrições. Assim, há restrições que têm de ser expressas de forma explícita, porque não caem em nenhuma das categorias previstas nos diagramas de classes. A sintaxe UML para exprimir restrições limita-se a indicar que devem ser colocados entre {}. Tudo o resto é livre, podendo ser expressas em pseudolinguagem, para enfatizar a legibilidade, ou ser traduzidas por instruções em código de programação. Nome Endereço Cliente Institucional nomecontacto regimecrédito limitecrédito avisa() facturaparamês(inteiro) Cliente regimecredito(): string Cliente Individual cartãocrédito# {regimecrédito()=="fraco"} Restrição: neste caso o regime de crédito só pode ser fraco Conceitos Avançados 47 Conceitos Avançados: Classes Associativas 48 Os conceitos até agora descritos, correspondem às notações chaves dos diagramas de classes. Correspondem a cerca de 90% do esforço na criação de diagramas de classes. Há, no entanto, alguns conceitos adicionais, dos quais iremos descrever alguns, os mais relevantes, podendo os restantes ser consultados na bibliografia indicada no início do capítulo. Iremos assim descrever: Classes Associativas Estereótipos Interfaces e desenho do sistema Agregação e Composição Surge da necessidade de obter mais informação de uma associação, permitindo adicionar atributos, operações e outros aspectos. Só existe em resultado da relação entre duas classes; por si só, não terá significado. Normalmente surgem nas relações de Muitos para Muitos e o nome da classe é dado pelo nome da associação.

Conceitos Avançados: Classes Associativas 49 Conceitos Avançados: Estereótipos 50 Exemplo: pretende saber-se quando (período de tempo) em que cada empregado trabalhou para a empresa poderíamos adicionar este atributo à classe Pessoa, mas trata-se realmente de um facto acerca do relacionamento da pessoa com a empresa. Pessoa Empregado Emprego Data_Início Data_Fim Empregador * * Classe Associativa Empresa Um estereótipo em UML é parte de um leque de mecanismos de extensibilidade utilizável quando a semântica base do elemento de modelação se revela insuficiente. Cada elemento UML pode ter um ou mais estereótipos. Permite, genericamente, criar novas classes de elementos de modelação por cima do núcleo de elementos pré-definidos pela UML, mantendo um controlo sobre as extensões das classes de metamodelos. É possível criar qualquer tipo de estereótipo, sendo os mais utilizados, para as classes, os de interface e controlo. Os estereótipos são normalmente mostrados entre aspas (por ex:, «control»), mas podem também ser representados por um ícone. Conceitos Avançados: Estereótipos 5 Conceitos Avançados: Interfaces e Desenho do Sistema 52 O estereótipo de «interface» classifica as classes que apenas disponibilizam um conjunto de operações visíveis externamente (públicas). Uma classe com o estereótipo de «control» representa uma classe cujo objetivo é conter um conjunto de regras que controlam determinadas operações do sistema e que coordenam as interações com as outras classes. Estereótipo «control» «interface» Controlo Acesso Gestão Interface: Proporciona uma vista total ou parcial do conjunto dos vários serviços proporcionados por um ou mais elementos. Permite que o impacto das alterações seja limitado, podendo efetuar-se alterações na classe sem afetar as classes restantes, desde que não se altere a interface respetiva. Permite separar o que é fornecido pela abstração da classe da forma como é produzido. É um grupo de operações que são utilizadas para especificar um serviço. + VerificaAcesso() + Criar() + Apagar() + Ver()

Conceitos Avançados: Interfaces e Desenho do Sistema 53 Conceitos Avançados: Interfaces e Desenho do Sistema 54 A UML representa as interfaces: Utilizando pequenos círculos ligados por uma linha ao elemento que proporciona os serviços descritos pela interface. Em alternativa a interface pode representar-se por uma classe, com o estereótipo «interface», mas sem atributos, apenas operações. Encomenda uma classe «interface» Gestão + Criar() + Apagar() + Ver() - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() Conceitos Avançados: Relação de Dependência 55 Conceitos Avançados: Relação de Dependência e Realização 56 Os dependentes da interface podem utilizar todos ou alguns dos serviços descritos na interface. Uma relação de dependência surge quando uma classe recorre aos serviços disponibilizados por outra classe. Quando um funcionário efetua uma consulta a uma encomenda, este terá de aceder aos serviços disponibilizados pela classe Encomenda, através da interface Gestão, que disponibiliza os serviços Criar(), Apagar() e Ver() da classe Encomenda O serviço funciona como um contrato entre a classe e os seus clientes, que, por sua vez, constroem os seus serviços com base na interface estabelecida Funcionário - BI: string - Nome: string - Morada: string «interface» Gestão + Criar() + Apagar() + Ver() Dependência Encomenda - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() A relação derealização mostra que existe um contrato entre a classe que utiliza o serviço e outra que garante a sua realização. A classe Funcionário, através da interface Gestão, pode Criar, Apagar e Ver encomendas. A classe Cliente apenas pode visualizar as encomendas, uma vez que a respetiva interface só disponibiliza a operação Ver() A classe Encomenda disponibiliza duas interfaces: Gestão e Visualizar. Funcionário - BI: string - Nome: string - Morada: string «interface» Gestão + Criar() + Apagar() + Ver() Encomenda - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() Cliente - BI: string - Nome: string - Morada: string + Pré-Registo() «interface» Visualizar + Ver() Realização

Conceitos Avançados: Interface e Desenho do Sistema 57 Conceitos Avançados: Diagrama de Classe com 3 níveis 58 Podemos construir um diagrama de classes com 3 níveis, dividido em três camadas de serviços:. Serviços de interface - fornece a interface para os utilizadores para apresentação e recolha de dados. 2. Serviços de negócio - engloba as classes que possuem as regras fundamentais de negócio, respondendo aos pedidos da camada ou de outros serviços da própria camada, através da execução de uma operação específica sobre dados relevantes com base em regras de negócio. 3. Serviços de Dados - permite manter, atualizar e aceder aos dados persistentes. Nesta arquitetura, quando os dados residem num servidor de base de dados, os serviços de negócio asseguram o acesso ao serviço de dados, isolando o seu acesso. Como as regras de negócio tendem a ser alteradas com relativa frequência, os serviços de negócio são úteis para encapsular estas regras, separando a tarefa a desempenhar da forma como é desempenhada. Ao isolar os serviços de negócio dos serviços de interface e dados, este diagrama permite ir ao encontro do paradigma de desenvolvimento de aplicações cliente/servidor, promovendo a reutilização, escalabilidade e manutenção dos componentes. Conceitos Avançados: Diagrama de Classe com 3 níveis 59 Conceitos Avançados: Diagrama de Classe com 3 níveis 60 A classe de interface Ecrã Pré- Registo necessita da classe clientes, nos serviços de negócio, para efetuar o registo, invocando para tal a operação pré-registo. Por sua vez, a classe cliente necessita de guardar num suporte físico os dados do cliente que está a efetuar o pré-registo, utilizando os serviços de dados através da classe SD_Cliente. Esquema semelhante se aplica para as classes Ecrã Reservas e Ecrã Encomenda. Dado necessitarem de verificar se o cliente tem permissão, o que é feito invocando a classe Controlo de Acesso (com estereótipo «control»), classe esta que contém as regras de negócio que gerem o acesso ao sistema. Serviços de Interface «user interface» Ecrã Pré-Registo «user interface» Ecrã Reservas «user interface» Ecrã Encomenda Serviços de Negócio Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() efetua 0..* Encomenda {persistence = Yes} - NumeroE - Data - TipoEncomenda + Criar() {sequencial} Serviços de Dados «data connection» SD_Cliente - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() efetua 0..* «data connection» Encomenda - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar() As classes persistentes Persistence=Yes necessitam que os seus objetos sejam gravados fisicamente numa base de dados ou outro meio. A classe Controlo, neste caso, não necessita de gravar os seus dados, utilizando os serviços da classe Cliente. No entanto, se fosse necessário manter um registo de acessos específicos da classe ou de regras de negócio, esta seria marcada como persistente e teria uma classe correspondente nos serviços de dados. Serviços de Interface «user interface» Ecrã Pré-Registo «user interface» Ecrã Reservas «user interface» Ecrã Encomenda Serviços de Negócio Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() efetua 0..* Encomenda {persistence = Yes} - NumeroE - Data - TipoEncomenda + Criar() {sequencial} Serviços de Dados «data connection» SD_Cliente - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() efetua 0..* «data connection» Encomenda - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar()

Conceitos Avançados: Diagrama de Classe com 3 níveis 6 Conceitos Avançados: Agregação e Composição 62 A parte física dos dados dependerá do tipo de base de dados (relacional ou objeto): Se base de dados relacional, aplicam-se as regras de transposição semelhantes às já tratadas em análise de sistemas, a propósito da transposição do modelo E-R para o modelo relacional. Se B.D. objeto ou relacional-objeto, a transposição será mais direta, e será tratada numa disciplina do plano de estudos do curso Tópicos Avançados de bases de Dados. A agregação num diagrama de classes pretende demonstrar a relação que um todo é composto por partes (part-ofrelationship). Representa uma relação assimétrica, na qual uma das partes desempenha um papel mais importante do que a outra. Restaurante - Nome - Morada..* Mesa - Num_mesa Um restaurante possui um conjunto de mesas (o losângulo sem enchimento pretende representar o conceito de agregação) Conceitos Avançados: Agregação e Composição 63 Conceitos Avançados: Agregação e Composição 64 Os critérios seguintes implicam uma agregação, mas o oposto nem sempre é verdade, ou seja, a agregação não os implica necessariamente: Uma classe é parte de outra classe (o todo é composto por partes) Os valores de um atributo de uma classe propagam-se aos atributos de outra classe. Uma ação numa classe implica uma ação na outra classe. Os objetos de uma classe estão subordinados aos objetos da outra classe. Em casos de dúvida quanto à existência de agregação, a associação simples será preferível: lembremo-nos de que é necessário escolher uma solução que implique o acoplamento mais fraco. A composição: é uma agregação com um significado mais forte existindo uma dependência direta entre as duas classes (se a parte deixar de existir, o todo também desaparece); dito de outra forma, a parte vive e morre com o todo. qualquer remoção do todo implica a eliminação em cascata das partes. Na composição a multiplicidade do lado do todo não ultrapassa o um, ao contrário da agregação. Não faz sentido haver linhas de encomenda (parte) sem a encomenda respetiva (todo). Encomenda - NúmeroE - Data - TipoEncomenda Todo..* Composição ItemEncomenda - Codtem - Quantidade Parte

Conceitos Avançados: Agregação e Composição 65 Quando Usar os Diagramas de Classes 66 Exemplo: Um polígono contém uma coleção ordenada de pontos. Esses pontos podem ser alterados com a edição do polígono (agregação) A composição é utilizada para o pacote gráfico do polígono (por ex., cor ou textura); foi separado do polígono porque diversos elementos gráficos podem utilizar o mesmo pacote de atributos gráficos. O relacionamento com o pacote gráfico é composição porque o pacote gráfico será criado ou destruído com o polígono. agregação {ordenado} 3..* Ponto Polígono Classes compostas - classes implementadas por composição. composição Pacote Gráfico Cor Textura Os diagramas de classes são a espinha dorsal de praticamente todos os métodos orientados para objetos, sendo, por isso, os mais usados. São, no entanto, os mais ricos e complexos, pelo que se recomenda o seu uso com alguns cuidados: Não tentar usar todas as notações disponíveis. Usar as mais complexas (aspetos avançados) quando forem estritamente necessárias. Adequar a perspetiva que se está a usar à fase em que o projeto se encontra: fazer diagramas conceptuais, se se está a fazer análise; fazer diagramas de especificação, ao começar a pensar-se em software; e fazer diagramas de implementação, apenas quando se pretender ilustrar uma solução de implementação mais particular. Quando Usar os Diagramas de Classes 67 Não desenhar modelos para tudo; é preferível concentrarmo-nos nas áreas chave. É melhor ter poucos diagramas, que se vão atualizando quando necessário, do que ter muitos diagramas que se vão tornando obsoletos por falta de atualização. Evitar a todo o custo começar a pensar nos pormenores de implementação demasiado cedo. Para o conseguir, concentrar a atenção nas perspetivas de concepção e de especificação.

ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Tópicos Objetivos Transição para os Objetos Diagramas de Objetos Representação das Ligações Objetos Compósitos Quando Utilizar os Diagramas de Objetos 2 CAP. 6.2 UML MODELAÇÃO DA ESTRUTURA - DIAGRAMA DE OBJETOS Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Objetivos 3 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 4 Facilitar a compreensão do processo de transição dos casos de uso para o universo dos objetos. Familiarizar com os conceitos essenciais à utilização dos diagramas de objetos. Esclarecer as relações entre os diagramas de objetos e diagramas de classes. Os diagramas de casos de uso Centram o desenvolvimento sobre as necessidades do utilizador. Têm um objetivo de eficácia: fazer o que deve ser feito. Dizem o que o sistema deve fazer, mas não como deve fazê-lo. Os diagramas de objetos Satisfazem um objetivo complementar, o da eficiência: fazer corretamente; Dizem como deve ser feito. Esta complementaridade é importante porque um bom projeto de software tem de satisfazer, em simultâneo, os objetivos de eficiência e eficácia.

Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 5 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 6 Transição de um caso de uso para uma formulação orientada para objetos <<realiza>> Caso de uso Colaboração <<participa>> <<participa>> <<participa>> Objeto Objeto Objeto A realização de um caso de uso é um momento crucial da construção do modelo: é o momento da passagem para objetos. Note-se, contudo, que uma decomposição que siga de forma direta um caso de uso, tal como ele foi criado, corre o risco de conduzir a uma abordagem estruturada clássica, com todos os inconvenientes de uma estruturação em torno de funções. Numa abordagem para objetos, realiza-se o caso de uso através de uma colaboração entre objetos. Veremos que os cenários, instâncias dos casos de uso, serão representados por diagramas de interação de dois tipos: de colaboração, e de sequência. Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Transição para os Objetos 7 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 8 Os diagramas de objetos ou diagramas de instâncias representam os objetos e as ligações entre eles, exatamente da mesma maneira que os diagramas de classes representam as classes e as associações entre elas. Tal como nos diagramas de classes, os diagramas de objetos, que não são mais do que a instanciação dos diagramas de classes, representam estruturas estáticas. A notação utilizada pelos diagramas de objetos deriva diretamente da dos diagramas de classes, com a diferença que apresenta os nomes dos elementos, que são as instâncias, sublinhados.

Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 9 Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos 0 Cada objeto é representado por um retângulo que contém os seguintes elementos: o nome da classe e do objeto, separados por : (diz-se que se tem o modelo completo) o nome da classe à qual o objeto pertence (diz-se que se tem o modelo anónimo) o nome do objeto, sem indicação da classe a que pertence (diz-se que se tem o modelo incompleto) O modelo anónimo é utilizado quando se sabe a que classe pertence o objeto, mas ainda não se atribuiu um nome para ele O modelo incompleto corresponde a situações em que já se escolheu o nome para o objeto, mas não se sabe ao certo a que classe pertence. Exemplo: Modelo completo: Modelo incompleto: Modelo anónimo: Nome do objeto: Classe Nome do objeto : Classe Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Diagramas de Objetos Cap. 6.2 UML - Modelação de Estrutura Diagramas de Objetos [Parte 2] Representação das Ligações 2 Os retângulos que simbolizam os objetos podem igualmente comportar um segundo compartimento que contém ovalordosatributos. O tipo não será necessário dado que já foi definido no diagrama de classes que engloba o dos objetos. Exemplo para um objeto anónimo da classe Automóvel, com um único atributo,cor, cujo valor évermelha: : Automóvel Os objetos de um diagrama encontram-se ligados por ligações que são instâncias das associações entre as classes às quais pertencem os objetos considerados. Exemplo do diagrama de objetos (simplificado) para um automóvel e do diagrama de classes para o qual representa uma instância: : Automóvel : Motor Automóvel Motor 4 : Roda : Roda : Roda : Roda Roda Cor = Vermelha É uma instancia de