SISTEMAS DE INFORMAÇÃO

1. SISTEMAS DE INFORMAÇÃO Alexandre Campos Moretti E-mail: alexandre.moretti@aes.edu.br Versão 1.0.10 – Mar/2010.

2. Processo de SoftwareOrientado a Objetos

3. Introdução • O desenvolvimento de software atual • Uso de linguagens de programação Orientadas a Objeto (OO) • Delphi, Java, ... • Linguagens compactas com bibliotecas de classes poderosas • Ambientes de programação • Sistemas de Banco de Dados Relacionais • Oracle, SQL-Server, mySQL, ...

4. Conceito de Software Orientado a Objetos • Na compreensão do mundo, os seres humanos utilizam-se de três métodos de organização dos pensamentos: • Diferenciação • Distinção entre todo e parte • Classificação • Vê a orientação a objetos, como técnica para modelagem de sistemas, utiliza estes métodos para diminuir a diferença semântica entre a realidade e o modelo 4

5. Conceito de Software Orientado a Objetos 5

6. Fases do Desenvolvimento de um Sistema em UML • Análise de Requisitos • Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". • Análise • A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema • Design (Projeto) • Na fase de design, o resultado da análise é expandido em soluções técnicas

7. Fases do Desenvolvimento de um Sistema em UML • Programação • Na fase de programação, as classes provenientes do design são convertidas para o código da linguagem orientada a objetos escolhida • Testes • Um sistema normalmente é rodado em testes de unidade, integração, e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos.

8. Partes que compõem a UML • Visões: • As Visões mostram diferentes aspectos do sistema que está sendo modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas. Definindo um número de visões, cada uma mostrará aspectos particulares do sistema, dando enfoque a ângulos e níveis de abstrações diferentes e uma figura completa do sistema poderá ser construída. As visões também podem servir de ligação entre a linguagem de modelagem e o método/processo de desenvolvimento escolhido. • Modelos de Elementos: • Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associações, dependências e heranças.

9. Partes que compõem a UML • • Mecanismos Gerais: • Os mecanismos gerais provém comentários suplementares, informações, ou semântica sobre os elementos que compõem os modelos; eles provém também mecanismos de extensão para adaptar ou estender a UML para um método/processo, organização ou usuário específico. • • Diagramas: • Os diagramas são os gráficos que descrevem o conteúdo em uma visão. UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema

10. Visoes • O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por completo as reais intenções do sistema sem ambigüidades, sendo facilmente interpretável. Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as informações necessárias para descrever um sistema

11. Visoes • Um sistema é composto por diversos aspectos: funcional (que é sua estrutura estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento dos módulos de código, etc.).

12. Visoes • Visão "use-case": • Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usuários) • Visão Lógica: • Descreve como a funcionalidade do sistema será implementada. É feita principalmente pelos analistas e desenvolvedores • Visão de Componentes: • É uma descrição da implementação dos módulos e suas dependências. É principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas. • Visão de concorrência: • Trata a divisão do sistema em processos e processadores. Este aspecto, que é uma propriedade não funcional do sistema. • Visão de Organização: • Finalmente, a visão de organização mostra a organização física do sistema, os computadores, os periféricos e como eles se conectam entre si

13. Conceito de Software Orientado a Objetos • Objetos e Instâncias • Classes • Atributos • Métodos • Visibilidade de atributos e operações • Mensagens 13

14. Conceito de Software Orientado a Objetos • Um objeto denota uma entidade, seja ela de natureza física, conceitual ou de software. • Entidades físicas: um carro, uma pessoa, uma casa • Entidade conceitual: um organograma de uma empresa • Entidade de software: um botão em uma GUI 14

15. Conceito de Software Orientado a Objetos • É uma entidade capaz de reter um estado (informação/atributos/propriedades) e que oferece uma série de operações (comportamentos/métodos) ou para examinar ou para afetar este estado • Um objeto é um conceito, uma abstração, algo com limites e significados nítidos em relação ao domínio de uma aplicação • Objetos facilitam a compreensão do mundo real e oferecem uma base real para implementação em computador 15

16. Conceito de Software Orientado a Objetos • Um objeto é algo que tem: • Estado • Comportamento • Identidade 16

17. Conceito de Software Orientado a Objetos • Comportamento de um Objeto • O comportamento determina como um objeto pode responder a interações mediante à ativação de operações decorrentes de mensagens recebidas de outros objetos • O Comportamento é determinado pelo conjunto de operações que o objeto pode realizar. • Controle Acadêmico • José da Silva • Solicita matrícula • Retorna: 1045478 17

18. Conceito de Software Orientado a Objetos • Identidade de um Objeto • Cada objeto tem um único identificador, mesmo que seu estado seja idêntico ao de outro objeto • Jose da Silva (objeto) • Controle Acadêmico (Sistema que está sendo construído) • Semestre (estado) • Matrícula 1045478(Propriedade de um aluno) • Lista de Semestres Cursados (candidato a objeto) • Semestre corrente (o mesmo que semestre) 18

19. Conceito de Software Orientado a Objetos • Classe • Uma classe é a descrição de um grupo de objetos com propriedades Semelhantes (atributos), mesmo comportamento (operações), mesmos relacionamentos com outros objetos (associações e agregações), e mesma semântica • Um objeto é uma instância de uma classe, • Uma classe é uma abstração que • Enfatiza características relevantes • Abstrai outras características • Abstração: ajuda lidar com a complexidade 19

20. Conceito de Software Orientado a Objetos • Exemplos de Classes • Professor • Atributos: Nome, Matrícula, Data de Contratação,Titulação • Operações: DefineNome(), AlteraNome(),TempoServiço(), DefineTitulação(), AlteraTitulação(), ... • Turma: • Atributos: Cod, Nome, Local, Créditos, Horário, Capacidade • Operações: DefineCod(), AlteraCod(), DefineNome(), AlteraNome(), NrCreditos(), AdicionaAluno(), EliminaAluno(), VerificaEstado(), ... 20

21. Conceito de Software Orientado a Objetos • Classe • Encontrando Classes • Uma classe deveria capturar uma e somente uma abstração chave. • Abstração ruim: classe "Aluno" que conhece a informação do aluno e as disciplinas que aquele aluno está matriculado. • Boa abstração: separar em uma classe para Aluno e uma classe para Disciplina 21

22. Conceito de Software Orientado a Objetos • Classe • Nomeando Classes • Uma classe deveria ser um substantivo singular que melhor caracteriza a abstração • Dificuldades na nomeação das classes podem indicar abstrações mal definidas • Nomes deveriam surgir diretamente do domínio do problema 22

23. Conceito de Software Orientado a Objetos • Atributo • O estado de um objeto é dado por valores de atributos e por ligações que tem com outros objetos • Todos os objetos de uma classe são caracterizados pelos mesmos atributos, ou variáveis de instâncias • O mesmo atributo pode ter valores diferentes de objeto para objeto 23

24. Conceito de Software Orientado a Objetos • Atributo • Atributos são definidos ao nível da classe, enquanto que os valores dos atributos dos atributos são definidos ao nível do objeto • Exemplos: • uma pessoa (classe) tem os atributos nome, data de nascimento e peso • João é uma pessoa (objeto da classe pessoa) com nome "João da Silva", data de nascimento "18/03/1973" e peso "70Kg" 24

25. Conceito de Software Orientado a Objetos • Métodos • O comportamento invocável de objetos são os métodos • Um método é algo que se pode pedir para um objeto de uma classe fazer • Objetos da mesma classe tem os mesmos métodos • Métodos são definidos ao nível de classe, enquanto que a invocação de uma operação é definida ao nível de objeto 25

26. Conceito de Software Orientado a Objetos • Mensagens • Uma mensagem é uma solicitação feita por um objeto A a um objeto B • Como resultado desta solicitação, o objeto B irá modificar seu estado ou irá retornar algum valor • O conceito de mensagem está diretamente associado ao conceito de operação • A interação entre os objetos é feita através da troca de mensagens 26

27. Conceito de Software Orientado a Objetos • Hierarquia • Quando vamos trabalhar com um grande conjunto de classes de objetos, é necessário organizar estas classes de maneira ordenada de modo que tenhamos uma hierarquia • Em uma hierarquia de classes teremos as classes mais genéricas no topo, e as mais específicas na base. 27

28. Conceito de Software Orientado a Objetos • Hierarquia • Automóveis • automóveis utilitários (camionetes leves) • utilitários urbanos • utilitários off-road • automóveis de passeio • passeio família • passeio esportivo • automóveis de carga • carga inflamáveis • carga com frigorífico 28

29. Conceito de Software Orientado a Objetos • Herança • Em uma hierarquia de classes semelhantes podemos dizer que as classes mais específicas herdam as características das mais genéricas, ou seja, todo automóvel de passeio família é um automóvel de passeio • A classe de nível superior na associação de herança é chamada de superclasse e a inferior de subclasse • Portanto automóvel de passeio família é uma subclasse de automóvel de passeio 29

30. Conceito de Software Orientado a Objetos • Abstração • Abstração é o processo através do qual detalhes são ignorados, para nos concentrarmos nas características essenciais • A abstração nos leva a representar os objetos de acordo com o ponto de vista e interesse de quem os representa 30

31. Conceito de Software Orientado a Objetos • Abstração • Para descrevermos um automóvel (do ponto de vista de um observador externo), identificamos a cor do mesmo, o número de portas, o tipo das rodas e pneus. • Quando identificamos o automóvel apenas a partir destas características externas estamos fazendo uma abstração pois uma série de detalhes internos não estarão sendo descritos. 31

32. Conceito de Software Orientado a Objetos • Abstração • Ex: Ao modelarmos um objeto avião no contexto de um sistema de marcação de passagens aéreas, não vai nos interessar a característica número de turbinas do avião, mas irá nos interessar a característica número de assentos disponíveis • Ao ignorarmos algumas características não relevantes em um determinado contexto, estamos fazendo uma abstração 32

33. Conceito de Software Orientado a Objetos • Encapsulamento • É o processo de ocultação das características internas do objeto • O encapsulamento cuida para que certas características não possam ser vistas ou modificadas externamente • Exemplo: • Podemos dizer que o motor de um automóvel está encapsulado, pois normalmente não podemos ver ou alterar características do motor • Podemos então utilizar um automóvel sem conhecer nada das complexidades do motor, que estão encapsuladas 33

34. Conceito de Software Orientado a Objetos • Encapsulamento • No contexto de uma linguagem OO um objeto pode ser definido como um conjunto de "funções“ unidas aos dados que elas necessitam • O encapsulamento "protege" os dados que estão "dentro" dos objetos, evitando assim que os mesmos sejam alterados erroneamente • Os dados só poderão ser alterados pelas "funções“ dos próprios objetos • As "funções" dos objetos são chamadas de operações ou métodos 34

35. Conceito de Software Orientado a Objetos • Polimorfismo • É a capacidade de objetos diferentes reagirem segundo a sua função a uma ordem padrão. • O comando "abre", por exemplo, faz um objeto entrar em ação, seja ele uma janela, uma porta ou uma tampa de garrafa 35

36. Conceito de Software Orientado a Objetos • Persistência • Refere-se à habilidade de um objeto existir além da execução que o criou, ou seja, ser armazenado em memória secundária (permanente ou persistente). • Não é o armazenamento apenas dos atributos (dados), mas também dos métodos para realizar os acessos. • Muito encontrado em sistemas que manipulam banco de dados 36

37. Análise e Desenvolvimento 37

38. Análise Orientada a Objetos • Por que utilizar Orientação a Objetos? • Quando bem empregada, a Orientação a Objetos traz diversas vantagens: • reutilização, • confiabilidade, • modelo de sistema mais realístico, • facilidade de interoperabilidade e de manutenção, • aumento da qualidade, • maior produtividade • unificação do paradigma (da análise a implementação). • A Orientação a Objetos é um paradigma que pode ser aplicado ao longo de todo o processo de construção do software.

39. Análise Orientada a Objetos • UML (Unified Modeling Language) • UML é uma linguagem para especificação, construção, visualização e documentação de sistemas de software. • UML não é uma metodologia não diz quem deve fazer o quê, quando e como UML pode ser usado segundo diferentes metodologias, tais como RUP (Rational Unified Process), FDD (Feature Driven Development), etc. • UML não é uma linguagem de programação 39

40. Análise Orientada a Objetos • UML (Unified Modeling Language) • Modelos e Diagramas • Um modelo é uma representação em pequena escala, numa perspectiva particular, de um sistema existente ou a criar • Ao longo do ciclo de vida de um sistema são construídos vários modelos, sucessivamente refinados e enriquecidos • Um modelo é constituído por um conjunto de diagramas (desenhos) consistentes entre si, acompanhados de descrições textuais dos elementos que aparecem nos vários diagramas 40

41. Análise Orientada a Objetos • UML (UnifiedModelingLanguage) • Um diagrama é uma vista sobre um modelo • O mesmo elemento (exemplo: classe) pode aparecer em vários diagramas de um modelo • No UML, há nove diagramas Standard • Diagramas de visão estática: casos de utilização (use case), classes, objetos, componentes, distribuição (deployment) • Diagramas de visão dinâmica: seqüência, colaboração, estados (statechart), atividades 41

42. Análise Orientada a Objetos UML (Unified Modeling Language) 42

43. Análise Orientada a Objetos UML (Unified Modeling Language) 43

44. Análise Orientada a Objetos UML (Unified Modeling Language) • O que é UML • Privilegia a descrição de um sistema segundo três perspectivas: • Dados (estrutural) • Diagrama de Classes • Operações (funcional) • Diagrama de Caso de Uso • Eventos (temporal) • Diagramas de Seqüência, Atividades, de Transição de Estados 44

45. Análise Orientada a Objetos UML (Unified Modeling Language) • Padrão OMG • Em http://www.omg.org estão disponíveis documentos eletrônicos que contém • Sumário da UML • Semântica • Guia da Notação • Extensões da Linguagem 45

46. Análise Orientada a Objetos UML (Unified Modeling Language) • UML (Unified Modeling Language) • Diagramas da UML • Casos de Uso (OOSE) • Diagramas de Classe (OMT, Booch e OOSE) • Deployment Diagramas (Booch) • Diagramas de Interação • Diagramas de Seqüência (OMT e Booch) • Diagramas de Colaboração (Booch ) • Diagramas de Pacotes (Booch) • Diagramas de Transição de Estados (OMT e Booch) • Diagramas de Atividade 46

47. Análise Orientada a Objetos UML (Unified Modeling Language) • UML (Unified Modeling Language) • Vantagens • Define um mapeamento da análise ao projeto e à implementação • Define uma notação expressiva e consistente • Facilita a comunicação entre as pessoas; • Ajuda a apontar inconsistências e omissões; • Suporta a análise e projeto de sistemas de pequeno e grande porte. 47