Linguagem de Programação II

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 • 1992-1994: 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

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 feedback UML 2.0 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 UML 1.5 UML 1.3 UML 1.1 UML 1.0 UML 0.9 Unified Method 0.8 Método Booch Outros Métodos OMT OOSE

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

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 State Diagramas State Diagramas State Diagramas State Diagramas State Diagramas State Diagramas Componentes Classes Objetos Component Diagramas Component Diagramas Distribuição Use Case Diagramas Use Case Diagramas Scenario Diagramas Scenario Diagramas Use Case Diagramas Use Case Diagramas Scenario Diagramas Scenario Diagramas Caso de Uso Sequência Estado Colaboração Atividade Iteração Modelos Visões dinâmicas Visões estáticas

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

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 • 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.

26. Objeto • 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 Identificador - Nome (obrigatório) nome Atributos (opcional) créditos abrir() Operações (opcional) incluir()

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 Novamente falando, não iremos nos deter nos vários aspectos do diagrama o qual será detalhado nas disciplinas de engenharia de software. Vamos somente ver o essencial para prosseguimento do conteúdo....

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 Composição Herança 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çosdos objetos de outra classe Cliente Servidor

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. Applet HelloWorld Graphics paint() Import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) g.drawString(“Hello, world!”, 10, 10); }