A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

2 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Tópicos 1 - Visão Geral de Orientação a Objetos e UML 2 - Visão Geral do Fluxo de Análise e Projeto 3 - Atividade Analisar de Caso de Uso 4 - Atividade Projetar Arquitetura 5 - Atividade Projetar Caso de Uso 6 - Atividade Projetar Subsistema 7 - Atividade Projetar Classe Aspectos de Concorrência, Distribuição e Projeto de Base de Dados não serão abordados Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

3 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Referências Descrição do fluxo de análise e projeto Link para o RUP a partir da página do curso Capítulos 8 e 9 do livro The Unified Software Development Process Uma observação importante é que o CD do RUP apresenta um único fluxo para análise e projeto, enquanto no livro são dois fluxos independentes The Unified Modeling Language User Guide Introdução e consultas eventuais à notação de UML Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

4 1 - Visão Geral de Orientação a Objetos e UML
Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

5 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Objetivos Apresentar os princípios do paradigma de orientação a objetos Apresentar os conceitos de orientação a objetos com a notação UML correspondente Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

6 Princípios básicos de OO
Abstração Encapsulamento Modularidade Herança Antes de apresentarmos os conceitos de orientação a objetos, vamos discutir os quatro princípios básicos deste paradigma: abstração, encapsulamento, modularidade e herança. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

7 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Abstração Construção de um modelo para representação de uma realidade Concentração nas características essenciais, gerenciando complexidade Abstração nos permite gerenciar complexidade concentrando nas características essenciais de uma entidade que a distingue das outras. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

8 Abstração - Objetos do mundo real
gado cliente É importante identificar nas entidades acima quais as características que importam no contexto do sistema sendo desenvolvido. automóvel Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

9 Abstração - construção de um modelo para a realidade
Automovel modelo preco ... atualizaPreco() ... Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

10 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Encapsulamento Elimina dependência de implementação, escondendo-a do cliente Uso de interfaces Mudanças internas não têm impacto sobre os clientes Encapsulamento elimina dependências diretas da implementação, tornando possível a alteração da implementação sem causar impacto no cliente, contanto que a interface não seja alterada. Isso torna a manutenção mais fácil e menos cara. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

11 Encapsulamento - Objeto televisão
Encapsulamento torna possível que clientes operem sem conhecer como a implementação implementa a interface. Uma cápsula medicinal e um controle remoto são dois exemplos claros de encapsulamento. A cápsula você toma apenas lendo a sua bula, mesmo sem saber o que exatamente tem dentro. O controle remoto é operado através de seus botões mas seus usuários não precisam saber como é o seu funcionamento interno. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

12 Encapsulamento: Objeto conta bancária
Número Saldo 875,32 Crédito Débito Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

13 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Modularidade Decomposição de um problema em pequenos pedaços, para gerenciar complexidade Cada conceito independente deve ser representado por um módulo Construção de módulos desacoplados Dividir para conquistar ... Modularidade é um outro meio de gerenciar complexidade porque permite quebrar algo complexo em um conjunto de pedaços menores e consequentemente mais fáceis de serem desenvolvidos e gerenciados. É dividir para conquistar. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

14 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Modularidade Que tal quebrar um problema grande e complexo em vários menores, mais fáceis de serem resolvidos? Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

15 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Herança Criação de hierarquias de abstração Permite ordenar hierarquias relacionadas Base conceitual para permitir extensibilidade do software Reuso de código e comportamento (subtipo) Hierarquia envolve organizar algo de acordo com uma determinada ordem . O uso do conceito de hierarquia para descrever diferenças ou variações de um conceito provê abstrações mais coesas. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

16 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Herança Figura Conta Polígono Poupança ContaEspecial Triângulo Retângulo O exemplo acima ordena conceitos relacionados de forma hierárquica. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

17 Herança: Objeto poupança
Número Saldo 875,32 Crédito Débito R. Juros Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

18 Conceitos básicos de OO
Objeto Classe Interface Componente Pacote Subsistema Relacionamentos Os conceitos acima serão vistos durante o restante deste módulo. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

19 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Classe Descrições de objetos com propriedades e comportamento comuns Abstração que enfatiza o que é relevante suprime o que não interessa Classes são fábricas de objetos Objetos são agrupados em classes Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica (esses conceitos serão vistos mais adiante). A identificação das características relevantes (uso do princípio de abstração) e comuns a um conjunto de objetos e definição de classes ajuda a tratar a complexidade de sistemas. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

20 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Classes de Objetos Quantas classes temos aqui? Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

21 Classe de Contas Bancárias
Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

22 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Classe em UML Conta Conta Nome da Classe numero saldo Atributos estrutura Operações credito() debito() getSaldo() getNumero() O exemplo acima mostra como modelar uma classe em UML, identificando o seu nome, atributos e operações, sendo os dois últimos opcionais. comportamento Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

23 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Objeto Modelo de um objeto real entidade física, conceitual ou de software Possui comportamento, estado e identidade Exemplo: objetos conta e poupança apresentados Um objeto representa uma entidade física, conceitual ou de software. Um objeto é uma manifestação concreta de uma abstração; uma entidade que encapsula estado e comportamento; uma instância de uma classe. O estado de um objeto é uma das possíveis condições que o objeto pode existir e normalmente muda com o passar do tempo; é um conjunto de propriedades que o objeto possui. Comportamento determina como um objeto age e reage a pedidos (para realização de operações) de outros métodos. É representado pelo conjunto de mensagens que o objeto é capaz de responder. Cada objeto possui também um identidade única no sistema, tornando assim possível que dois objetos mesmo com estados iguais possam ser identificados como diferentes. Um objeto é qualquer pessoa, lugar, evento, coisa, tela, relatório, ou conceito aplicável ao sistema. Um objeto pode ser qualquer coisa que faça parte do seu sistema. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

24 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Objeto em UML : Conta Apenas o nome da classe ContaSaque Apenas o nome do objeto ContaSaque : Conta Os exemplos acima mostram as diferentes formas em que um objeto pode ser modelado em UML. Nome da classe e do objeto Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

25 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Objeto em UML Objeto : ContaSaque numero = saldo = 875,32 Valor do Atributo Conta numero saldo : ContaDeposito numero = saldo = 500,00 O exemplo acima ilustra objetos com diferentes valores de atributos. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

26 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Polimorfismo Escondendo diferentes implementações através de uma única interface Manufacturer B Manufacturer A Manufacturer C Polimorfismo diz que um objeto pode ser de várias formas, e que outros objetos podem interagir com este sem saber de que forma específica ele é. No exemplo acima, um controle remoto pode ser utilizado para controlar vários tipos de televisões, contanto que estas implementem a mesma interface. Vamos ver o conceito de interface na próxima transparência. É uma técnica baseada em herança e ligação dinâmica que dá grande adaptabilidade ao código, reduzindo assim o esforço na manutenção. interface bem definida Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

27 Interface Interfaces formalizam polimorfismo
Interfaces permitem o uso de arquitetura baseada em componentes Círculo <<interface>> Forma Desenhar Mover ModificarTamanho Rotacionar Pirâmide Cubo Uma interface é uma coleção de operações, usadas para especificar um serviço de uma classe ou componente. Relacionamento de realização Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

28 Exemplo: Repositório de Contas
ListaContas <<interface>> Repositorio Incluir Remover credito debito RepositorioBDR RepositorioBDOO Uma interface é uma coleção de operações, usadas para especificar um serviço de uma classe ou componente. Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

29 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Interface Interfaces definem um tipo especificando apenas a assinatura de seus métodos Interfaces não possuem atributos e seus métodos não têm corpo Classes implementam interfaces provêem implementação para os métodos especificados em uma interface Uma interface define um tipo especificando apenas a assinatura (parâmetros de entrada e saída) dos métodos pertencentes a este tipo. São definidos então o nome, tipos de argumento e resultado dos métodos de uma classe mas não o código para a implementação destes métodos. Classes implementam interfaces, isto é, classes provêem implementação para os métodos especificados em uma interface. Ao implementar uma interface, uma classe deve prover implementação para todos os métodos definidos na interface, a não ser que esta classe seja abstrata. Quando uma classe implementa uma interface, provendo implementação para todos os métodos da interface, dizemos que esta classe é do tipo da interface. Pense assim: quando uma classe é do tipo de uma interface, esta classe pode ser usada em qualquer lugar que estiver sendo esperado um objeto do tipo desta interface. Dois elementos são polimórficos se eles implementam a mesma interface. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

30 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Interface em UML Representação com ícone Círculo Pirâmide Forma Cubo Representação Canônica <<interface>> Forma Círculo Pirâmide Desenhar Mover ModificarTamanho Rotacionar Os exemplos acima mostram as diferentes formas de modelar interfaces em UML. Cubo Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

31 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Classe abstrata Classe abstrata é aquela que não possui instância Em geral, possui pelo menos um método abstrato Métodos abstratos não têm corpo devem ser implementados em subclasses não abstratas Uma classe abstrata é aquela que não possui instâncias. Em geral, possui pelo menos um método abstrato, isto é, método com interface definida mas sem implementação, a ser implementado nas subclasses da classe abstrata. Toda classe que herdar de uma classe abstrata e não for abstrata deve prover implementação para todos os métodos abstratos definidos na sua superclasse. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

32 Classes abstratas x Interfaces
Herança de tipos x herança de código Classes descrevem propriedades fundamentais de um objeto Interfaces descrevem papéis desempenhados por um objeto em determinadas situações Interfaces são úteis para implementar herança múltipla É importante saber quando devemos usar herança de classe e implementação de interface: classes descrevem propriedades fundamentais de um objeto, enquanto que interfaces descrevem papéis desempenhados por um objeto em determinadas situações. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

33 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Componente Parte não trivial, quase independente, substituível de um sistema, que provê a realização de (uma/um conjunto de) interface(s) Exemplos um código fonte um componente de tempo de execução um componente executável Um componente é uma parte do sistema que provê a realização física de um conjunto de interfaces. Desenvolvimento baseado em componentes é a criação e implantação de software composto por componentes. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

34 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Componente em UML <<DLL>> Component Name Source File Name <<EXE>> Executable Name Component Interface Acima alguns exemplos de componentes são ilustrados em UML. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

35 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Pacote Mecanismo para organizar elementos em grupos Facilita entendimento do sistema Favorece modularidade e reuso em larga escala Essencial para estruturar sistemas complexos Package Name Um pacote representa um grupo de classes relacionadas, e possivelmente outros pacotes, de acordo com algum ponto de vista ou critério. O uso de pacotes para encapsular classes relacionadas favorece modularidade e consequentemente reuso em larga escala e manutenção, sendo assim essencial para estruturar sistemas orientados a objetos complexos. Quando o número de classes do seu sistema é muito alto, você deve organizá-las em pacotes para facilitar o seu entendimento Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

36 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Coesão e Acoplamento Acoplamento é a medida de quão conectadas duas classes são cuidado com herança Coesão é a medida de quão auto-contida uma classe é Sistemas devem ter baixo acoplamento e alta coesão bom para manutenção Coesão e acoplamento são dois conceitos importantes na engenharia de software. Para desenvolver um sistema de fácil manutenção, você deve desenvolver classes que sejam fracamente acopladas e fortemente coesas. Acoplamento é a medida de quanto dois módulos, classes ou métodos estão inter-conectados. Por exemplo, quando uma classe interage com outra mas não sabe nada da implementação desta outra classe, dizemos que estas classes são fracamente acopladas. Uma classe que depende da implementação de outra é fortemente acoplada a esta outra. Coesão é a medida de quanto uma classe ou método está auto-contido, isto é, se ele faz sentido por si só. Se uma classe não faz sentido sozinha, isto é, se para realizar qualquer operação esta precisa da colaboração de outra classe, então esta classe possui fraca coesão. É preciso ter cuidado com o uso de herança para evitar que uma classe se torne fortemente acoplada à sua superclasse. Mudanças nos atributos ou operações na superclasse se propagam a todas as subclasses. Logo, estas mudanças devem ser controladas cuidadosamente. Baixo acoplamento implica que mudanças em componentes dificilmente afetarão outros componentes. Sistemas orientados a objetos em geral são fracamente acoplados pois não compartilham estado e a comunicação entre os objetos é feita através de troca de mensagem. Classes que fazem parte de diferentes pacotes ou subsistemas devem ser o menos acopladas possível. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

37 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Subsistema União de pacote (agrupa outros elementos) classe (comportamento) Realiza uma ou mais interfaces, que definem o seu comportamento Subsistema é um elemento que possui a semântica de um pacote, pois contém outros elementos, e uma classe, porque possui comportamento. O comportamento de um subsistema é provido pelas classes e subsistemas que ele contém. Um subsistema realiza uma ou mais interfaces, que definem o seu comportamento. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

38 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Subsistema em UML Realização Subsistema <<subsystem>> Subsystem Name Interface Subsistemas são representados em UML com um elemento de pacote com o estereótipo <<subsystem>>. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

39 Subsistemas e Componentes
Ambos encapsulam um comportamento modelado por interfaces Subsistemas representam componentes no modelo de projeto Componentes são a realização física dos subsistemas Projeto <<subsystem>> Nome do subsistema Implementação Subsistemas e componentes: ambos encapsulam um conjunto de comportamentos modelado por interfaces. Um componente provê a realização física de um conjunto de interfaces. Componentes são elementos de implementação. Um componente é um subsistema implementado. Nome do componente Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

40 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Relacionamentos Associação simples agregação composição Dependência Generalização Realização Existem vários tipo de relacionamentos, como mostra o slide acima. Veremos a seguir cada um destes tipos de relacionamento. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

41 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Associação Relação estrutural entre classes Nome da associação Pessoa trabalha Empresa Associação Papéis Classe Pessoa Empresa Empregado Empregador Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

42 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Agregação Tipo especial de associação Relacionamento todo-parte O todo possui um nível de abstração maior que a parte Todo Parte Empresa Departamento Agregação Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

43 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Composição Tipo especial de agregação Relação de posse mais forte O todo é responsável pela criação da parte A parte não vive sem o todo Todo Parte Empresa Departamento Composição Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

44 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Dependência Relacionamento não estrutural (uso) mais fraco que associação Uma dependência entre dois elementos indica que mudança em um elemento pode causar mudanças no outro LeitoraCartao Cartão lerCartao (cartao) Relacionamento de Dependência Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

45 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Dependência Pode existir relacionamento de dependência entre vários elementos de UML Classe Cliente Fornecedor Componente Pacote Cliente Fornecedor PacoteCliente PacoteFornecedor Dependência Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

46 Exercício - Relacionamentos
Modele os relacionamentos existentes entre as classes abaixo: Universidade Departamento Estudante Disciplina Instrutor Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

47 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Multiplicidade Multiplicidade define quantos objetos participam do relacionamento O número de instâncias de uma classe relacionada a uma instância de outra classe Especificado em cada uma das pontas da associação Multiplicidade indica, numa associação, quantos objetos de uma classe podem estar associados com uma instância da outra classe participante da associação. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

48 Tipos de Multiplicidade
Não especificada Exatamente um Zero ou mais Muitos (mesmo que 0..*) Um ou mais Zero ou um Intervalo determinado Valores múltiplos 1 0..* * 1..* 0..1 2..4 2, 4..6 Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

49 Exemplo: Multiplicidade
Pessoa Empresa 1 1..* Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

50 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Navegação Especifica a direção da associação Associações e agregações são bidirecionais por default, mas é desejável que a navegação seja restringida a apenas uma direção Associações bidirecionais são mais difíceis de implementar Multiplicidade indica, numa associação, quantos objetos de uma classe podem estar associados com uma instância da outra classe participante da associação. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

51 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Exemplo: Navegação Pessoa Empresa 1 1..* Navegação Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

52 Exercício - Multiplicidade
Acrescente a multiplicidade nos relacionamentos encontrados no exercício anterior. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

53 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Generalização Relacionamento entre classes onde uma classe compartilha a estrutura (atributos e relacionamentos) e comportamento (operações) de outras classes Define uma hierarquia de abstrações Relacionamento “é um tipo de” (is-a-kind-of) Diferentes classes geralmente possuem características e comportamento (modelados através de atributos e métodos) em comum. Para evitarmos escrever o mesmo código diversas vezes, foi criado um mecanismo para reaproveitar essas similaridades. Herança é este mecanismo. O relacionamento de generalização ou especialização indica que objetos do tipo filho podem ser usados no lugar de objetos do tipo pai. Generalização é mais conhecido como relacionamento “é um tipo de” (is-a- kind-of). Uma subclasse (classe filha) herda a estrutura e o comportamento da sua superclasse (classe pai). Generalização é o nome do relacionamento e herança, o nome do mecanismo. Existem dois tipo de herança: simples e múltipla, apresentados a seguir. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

54 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Generalização Uma subclasse pode adicionar atributos, operações e relacionamentos redefinir operações herdadas Tipos de herança: simples e múltipla Além de herdar a estrutura e comportamento da sua classe pai, uma classe filha pode adicionar atributos, operações e relacionamentos em sua definição, e até redefinir operações herdadas. Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

55 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Herança Simples Classes herdando de apenas uma outra classe Figura cor largura da linha desenhar() girar(graus) selecionar() Superclasse (pai) Relacionamento de Generalização Retângulo vertices desenhar() diagonal() Círculo raio centro desenhar() Subclasses Quadrado Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

56 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Herança Múltipla Classes herdando de mais de uma classe ObjetoVoador Animal Herança múltipla Avião Helicóptero Pássaro Lobo Cavalo Fonte: Rational Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

57 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Herança Múltipla O que acontece quando as superclasses possuem o mesmo método (métodos com o mesmo nome)? O que acontece quando se tenta executar um método que não está definido na subclasse? Em que hierarquia de superclasses deve-se procurar o método? Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

58 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Realização Indica que um elemento serve como contrato que o outro deve seguir Exemplos: Componente Classe Subsistema Realização Caso de uso Realização de Caso de uso Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

59 Exercício - Generalização
Modele a hierarquia de classes de uma aplicação bancária com contas correntes (contas comuns, sem cheque especial), poupanças e contas especiais (contas com certo crédito). Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

60 Mecanismos adicionais de UML
Estereótipos Notas Propriedades (Tagged values) Restrições Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

61 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Estereótipos Mecanismo utilizado para estender os elementos de UML Define um novo modelo de elemento em termos de outro já existente Como criando um novo ícone utilizando a notação <<novo_elemento>> Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

62 Estereótipos - Exemplo
Classes de fronteira: <<boundary>> ClasseFronteira ClasseFronteira Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

63 Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Notas Anotação utilizada para adicionar informação a diagramas Pode ser associada a qualquer elemento de UML Pode ser ligada a um elemento com uma linha tracejada Exemplo: Esta classe é uma abstração do dispositivo de hardware que será usado para ler efetivamente as informações do cartão magnético. LeitoraCartao Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

64 Propriedades (Tagged Values)
Servem para estender elementos UML, adicionando informações sobre eles Exemplos já definidos em UML: Persistence Location (ex: no cliente, no servidor) Você pode criar suas próprias propriedades Cliente {persistence} LeitoraCartao {location=server} Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

65 Paradigma de Orientação a Objetos
Benefícios Favorece modularidade, extensibilidade, compatibilidade e reuso, suportando a evolução do sistema Aproxima-se do mundo real Uso do mesmo conceito em todas as fases do desenvolvimento Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

66 Respostas dos Exercícios
Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

67 Relacionamentos Resposta do exercício
Universidade Departamento coordena vinculado alocado no Estudante Disciplina Instrutor inscrito ministra Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

68 Multiplicidade Resposta do exercício
Universidade Departamento coordena 0..1 1 1..* 1..* 1..* 1..* vinculado alocado no * 1..* 1..* 0..1 Estudante Disciplina Instrutor inscrito ministra * * * 1..* Copyright CESAR-Qualiti, Maio Todos os direitos reservados.

69 Generalização Resposta do exercício
Conta Conta-corrente Poupança Conta especial Copyright CESAR-Qualiti, Maio Todos os direitos reservados.


Carregar ppt "Engenharia de Software"

Apresentações semelhantes


Anúncios Google