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

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

Linguagem de Programação II Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação.

Apresentações semelhantes


Apresentação em tema: "Linguagem de Programação II Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação."— Transcrição da apresentação:

1 Linguagem de Programação II Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação

2 Um pouco sobre UML

3 Diferenças de Notação As diferenças de notação são muitas, e a ordem na qual o analista desenvolve o modelo em uma e outra técnica é completamente diferente; Em técnicas Estruturadas, você coloca suas fundações sobre as Funções do sistema - Coisas que mudam a toda hora; Em OO você coloca suas fundações sobre os Dados do sistema - algo que muda e evolui, mas não de forma tão dramática, a toda hora; A UML, em especial, é uma técnica muito flexível, com uma notação estendível, o que possibilita utilizá-la em diversos aspectos de um sistema sem ter de trocar de técnica - Dados, real-time, Interface, etc….

4 Diferentes padrões Em fins dos anos 80 e inicio dos anos 90 vários métodos orientados a objetos surgiram entre eles de Grady Booch, Jim Rumbaugh (OMT) e Ivar Jacobson A UML foi uma tentativa de unificar as notações destes três métodos. Foi concebida por esses profissionais A idéia era produzir um padrão com as melhores práticas adotadas pela indústria, levando mais desenvolvedores a modelar seus sistemas de software antes de construí-los

5 Grady Booch Um dos pioneiros da OO 1980: ênfase em técnicas de projetos para ADA : livros Object-Oriented Design With Applications Projeto de programas em C++ e Ada

6 Grady Booch 1994: Object-Oriented Analysis and Design with Applications Texto sobre conceitos de OO e modelagem de objetos Projeto de várias aplicações-exemplo com diferentes linguagens da época Base da UML 1998 Fundação da Rational

7 Booch

8 Ivar Jacobson Modelagem OO baseada em casos de uso

9 James Rumbaugh Object Modeling Technique (OMT) Desenvolvida na GE Metodologia baseada em notações pré- existentes (ER, DTE, DFD) Clara distinção entre as três visões do problema

10 OMT

11

12

13 Visão Geral da UML A UML é uma linguagem para: visualizar especificar construir documentar Artefatos de um sistema intensivamente baseado em software Elementos de modelagem Relacionamentos Mecanismos de extensibilidade Diagramas

14 História da UML Desenvolvimento do UML começou no final de 1994, quando Booch e Rumbaugh passaram a trabalhar em conjunto Versão Preliminar do UML (versão 0.8) outubro de 1995, quando Jacobson se une ao grupo A partir dos esforços de Booch, Rumbaugh e Jacobson versão 0.91 (outubro de 1996), liberada para a comunidade

15 História da UML Uma RFP (Request for Proposal) foi realizada pela OMG (Object Management Group) buscando contribuições da comunidade para o estabelecimento de uma linguagem unificada diversas contribuições lançaram o UML 1.0 Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI e Unisys. Em janeiro 1997, novas contribuições lançaram o UML 1.1 IBM & ObjecTime, Platinum Technology, Ptech, Taskon & Reich Technologies e Softeam

16 História da UML A Partir da Versão 1.1 comunidade de desenvolvimento de software faz uma aderência maciça ao UML Em novembro 1997 O UML 1.1 foi adotado como norma pela OMG OMG estabeleceu um RTF (Revision Task Force) para aperfeiçoar pequenos detalhes na linguagem Em Junho 1999 O RTF libera a versão UML 1.3 UML 1.4 Liberada em Setembro de 2001 UML 2.0 Liberada em Julho de 2005

17 Criação da UML Método Booch OMT Unified Method 0.8 OOSE Outros Métodos UML 0.9 feedback UML 1.0 UML 1.5 UML 2.0 UML 1.1 UML 1.3 Aceitação Final dOMG – Nov 1997 Submissão Final OMG – Set 1997 Primeira submissão OMG – Jan 1997 Parcerias UML Web – Junho 1996 OOPSLA ´95

18 Meyer Pré e Pós Condições Harel Máquinas de Estados Gamma, et al Frameworks e patterns, HP Fusion Descrições de Operações e Numeração de Menssagens Embley Classes Singleton e Visão de Alto Nível Wirfs-Brock Responsabilidades Odell Classificação Shlaer - Mellor Ciclos de Vida de Objetos Rumbaugh OMT Booch Booch method Jacobson OOSE Contribuições à UML

19 Sócios da UML Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft ObjecTime Oracle Platinum Technology Taskon Sterling Software Unisys

20 Unified Modeling Language UML significa Linguagem de Modelagem Unificada A UML combina o melhor do melhor de: Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento) Modelagem de Negócios (Fluxo de trabalhos) Modelagem de Objetos Modelagem de Componentes A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de um sistema intensamente baseado em software Pode ser usada com todos os processos, durante todo o ciclo de desenvolvimento, e com diferentes tecnologias de implementação

21 Modelos, Visões, Diagramas Use Case Diagramas Use Case Diagramas Caso de Uso Scenario Diagramas Scenario Diagramas Colaboração State Diagramas State Diagramas Componentes Component Diagramas Component Diagramas Distribuição State Diagramas State Diagramas Objetos Scenario Diagramas Scenario Diagramas Estado Use Case Diagramas Use Case Diagramas Sequência State Diagramas State Diagramas Classes Atividade Modelos Iteração Visões dinâmicasVisões estáticas

22 Modelos, Visões, Diagramas Caso de Uso Componentes Distribuição Objetos Estado Classes Atividade Colaboração Sequência Iteração Visão do usuário Visão comportamental Visão de ambiente Visão estrutural Visão de implementação

23 Atenção Como o foco da disciplina é orientação a objetos não iremos nos aprofundar demais em diagramas e sim trabalharmos de forma mais intensa os conceitos envolvidos na orientação a objetos ao longo semestre. A cadeira de Engenharia de Software proporciona o conhecimento necessário e aprofundado...

24 O Modelo de Objetos Um modelo de objetos busca capturar a estrutura estática de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operações que caracterizam cada classe de objetos. É através do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invés de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representação mais próxima do mundo real.

25 Objeto é definido como um conceito, abstração ou coisa com limites e significados bem definidos para a aplicação em questão. Objetos têm dois propósitos: promover o entendimento do mundo real e suportar uma base prática para uma implementação computacional. Não existe uma maneira correta de decompor um problema em objetos; esta decomposição depende do julgamento do projetista e da natureza do problema. Todos objetos têm identidade própria e são distinguíveis. Objeto

26 Objetos são a chave para se compreender a tecnologia orientada a objetos. Você olha ao seu redor e tudo o que vê são objetos: carro, mesa, janela, livro, pessoa, etc. Os objetos do mundo real têm duas carecterísticas em comum: ESTADO e COMPORTAMENTO. Estado O estado de um objeto revela seus dados importantes. Por exemplo, uma pessoa tem: idade, peso, altura, cor de cabelo, cor da pele. Comportamento O comportamento são as ações que aquele objeto pode exercer ou executar. Por exemplo, uma pessoa pode: andar, falar, ouvir, pular.

27 Objeto Esses objetos podem ser tanto objetos concretos (carro, livro, nota fiscal), quanto conceitos abstratos (conta corrente, venda, pessoa jurídica). Na Orientação a Objetos, os objetos do mundo real são modelados e representados no mundo computacional, ou seja, dentro do sistema, por meio de objetos de sotware. Cada objeto deve ser conhecido, bem definido e ter seu limite e um significado dentro do sistema. Os objetos de software, assim como os objetos do mundo real, também possuem estado e comportamento.

28 Classe Uma classe é um modelo que define as variáveis (estado) e os métodos (comportamento) comuns a todos os objetos do mesmo tipo. Um objeto nada mais é que uma instância de uma classe Ex.: Grupo de pessoas. Cada pessoa pode ser vista como um objeto mas todas elas pertencem a classe Pessoa

29 Representação de classes e objetos

30 Classe Nome da classe podem ser simples ou pode ser precedido pelo nome do pacote em que a classe está contida (Exceções::ClienteCadastrado) Representação Curso nome créditos abrir() incluir() Identificador - Nome (obrigatório) Atributos (opcional) Operações (opcional)

31 Classe Nome da Classe Visibilidade atributo: Tipo = ValorInicial Visibilidade operação (lista arg): Tipo retorno

32 Atributos Representa alguma propriedade do que está sendo modelado - identifica as características próprias da classe Descrevem os dados contidos nas instâncias de uma classe Podem ser identificados apenas com nomes Podem ter seus tipos (Classes) especificados e terem valores padrão definidos

33 Atributos Parede altura : real largura : real espessura : real viga : boolean = false

34 Visibilidade Usar marcações de acesso para especificar o tipo de acesso permitido aos atributos e operações Visibilidade: + público : visível em qualquer classe # protegido : qualquer descendente poderá usar - privado : visível somente dentro da classe + saldoEM (date: Date): Money

35 Operações/Métodos Uma operação é uma função ou transformação que pode ser aplicada a/ou por objetos em uma classe. Por exemplo, abrir, salvar e imprimir são operações que podem ser aplicadas a objetos da classe Arquivo. Todos objetos em uma classe compartilham as mesmas operações Operação é algo que é executado em um objeto (procedimento de chamada)

36 Operações/Métodos Um método é a implementação de uma operação para uma classe. Descreve o comportamento da classe e por consequencia todos os objetos daquela classe

37 Operações/Métodos Visibilidade +público #protegido -privado

38 Diagrama de Classes Objetivo Descrever os vários tipos de objetos no sistema e o relacionamento entre eles. São os principais diagramas estruturais da UML As classes especificam a estrutura e o comportamento (operações) dos objetos, que são instâncias das classes

39 Exemplo de diagrama

40 Diagrama de classes Um diagrama de classes contém Entidades Representação de cada uma das pequenas partes daquilo que está se querendo representar Classes Interface vamos ver mais adiante o que é isso Relacionamentos Representa a forma como ocorrerá o relacionamento entre as partes Associações Generalização (herança) Dependências

41 Atenção

42 Relacionamentos **** Poucas classes vivem sozinhas **** Comunicação entre classes - definem responsabilidades Construir uma casa casa, parede, porta, janela, cômodo, luz Casa tem janelas, que têm vários tipos! Janelas podem ser abertas no sentido vertical e/ou horizontal Existem semelhanças entre as janelas e diferenças....

43 Relacionamentos 3 Tipos: Associações Agregação Composição Generalização (herança) Dependências

44 Associação Agregação Herança Composição Dependência

45 Associação Define um relacionamento entre duas entidades conceituais do sistema Especifica que objetos de uma classe estão conectados a objetos de outras Ex: as salas são formadas por paredes É o tipo de ligação de classe mais utilizado nos diagramas de classe

46 Dependência Dependência - relacionamentos de utilização, no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente Ex: os canos dependem do aquecedor para fornecerem água quente Indica que mudanças em um elemento (o servidor) podem afetar outro elemento (o cliente) Dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe ClienteServidor

47 Generalização Generalização (herança simples e múltipla) - relacionamento entre um elemento mais geral e um mais específico Herda de alguém alguma coisa ou características é um relacionamento de taxonomia entre um elemento mais geral e um mais específico, que é totalmente consistente com o primeiro, somando-o informação especializada O comportamento da classe ou característica da classe muda com relação as outras associações existentes A classe sendo refinada é chamada de superclasse ou classe base, enquanto que a versão refinada da classe é chamada uma subclasse ou classe derivada As vezes é chamada de relacionamento is-a (é-um), porque cada instância de uma classe derivada é também uma instância da classe base. Ex: Veículo terrestre pode ser do tipo automóvel ou caminhão (TIPO DE), Tipos de Animal (mamífero, ave, peixe)

48 Generalização

49 Clube Associado Dependente Exemplo de associação e dependencia

50 Import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) g.drawString(Hello, world!, 10, 10); } HelloWorld paint() Graphics Applet

51 Tipos des associação (agregação ou composição) Agregação - tipo especial de associação - relacionamento é parte de, todo/parte (diamante aberto) O objeto que contém a referência a outros objetos (todo) PODE EXISTIR independentemente da existência dos objetos referenciados (parte). DisciplinaEstudante TodoParte Agregação

52 Objeto TODO mantém um ponteiro ou uma referência para suas partes Ex.: Temos o objeto Carro que por sua vez faz referência ao objeto Rodas, porém o objeto "Carro" pode existir mesmo que vc destrua "Rodas", ou seja "faz sentido a existência do carro mesmo sem seus pneus".

53 Composição Composição - relacionamento entre um elemento (o todo) e outros elementos (as partes) indica que as partes só podem pertencer ao todo e são criadas e destruídas com ele A parte não vive sem o todo O objeto que contém a referência a outros objetos NÃO FAZ SENTIDO EM EXISTIR sem a existência dos objetos referenciados. É semanticamente esquivalente a um ATRIBUTO, mas pode ser mais atraente quando a parte tem uma estrutura interna DisciplinaEstudante TodoParte Composição

54 Ex.: Objeto Pedido que por sua vez faz referência ao objeto Itens, portanto o objeto "Itens" não faz sentido sem o objeto "Pedido". Qual o principal "conteúdo" do pedido ? São seus itens certo ?

55 Computador TecladoMouseMonitor Janela BotãoTítuloMenu

56 Associação x Agregação x Composição Como você modelaria: Dependente e Funcionário? Pedido e Item do pedido? Funcionário e Cartão de ponto? Carro, Roda, Direção e Carburador? Na dúvida, use agregação! Na dúvida, use associação!

57 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 A multiplicidade em uma das extremidades da associação especifica para cada objeto da classe encontrada na extremidade oposta deve haver a determinada quantidade de objetos na extremidade próxima

58 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..* , 4..6

59 Exemplo: Multiplicidade Disciplina Estudante Multiplicidade 1..*1 Uma instância de Disciplina pode conter 1 ou mais Estudantes Uma instância de Estudante pode 1 Disciplina

60 Navegação Especifica a direção da associação Associações e agregações são bidirecionais por default Disciplina Estudante Navegação 1..*1 Nesse caso Disciplina não sabe o vinculo de multiplicidade com Estudante

61 PessoaEmpresa funcionárioempregador 1..** Trabalha para Departamento 1 *

62 Notações Diagrama de classe Nome das classes sõa substantivos Primeiro caractere maiúsculo (Customer, java::awt::Rectangle) Atributo: substantivo, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome do atributo, exceto a primeira letra: nomeProfessor Operação verbo ou locução verbal, aparece como maiúsculo o primeiro caractere de cada palavra existente no nome da operação, exceto a primeira letra: isEmpty

63 Sugestões de desenvolvimento Não comece a construir um modelo de objetos simplesmente definindo classes, associações e heranças. A primeira coisa a se fazer é entender o problema a ser resolvido. Tente manter seu modelo simples. Evite complicações desnecessárias. Escolha nomes cuidadosamente. Nomes são importantes e carregam conotações poderosas. Nomes devem ser descritivos, claros e não deixar ambiguidades. A escolha de bons nomes é um dos aspectos mais difíceis da modelagem. Não enterre apontadores ou outras referências a objetos dentro de objetos como atributos. Ao invés disto, modele estas referências como associações. Isto torna o modelo mais claro e independente da implementação.

64 Sugestões de desenvolvimento Tente evitar associações que envolvam três ou mais classes de objetos. Muitas vezes, estes tipos de associações podem ser decompostos em termos de associações binárias, tornando o modelo mais claro. Não transfira os atributos de ligação para dentro de uma das classes. Tente evitar hierarquias de generalização muito profundas. Não se surpreenda se o seu modelo necessitar várias revisões; isto é o normal. Nem sempre todos os símbolos são necessárias para descrever uma aplicação. Use apenas aquelas que forem adequadas para o problema analisado.


Carregar ppt "Linguagem de Programação II Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação."

Apresentações semelhantes


Anúncios Google