Princípios de Análises e projetos de sistemas

1. Tópicos a serem abordados: Tipos Abstratos de Dados (TAD) Programação orientada a objetos Programação orientada a objetos x Programação Estruturada Linguagens orientadas a objetos Fundamentos do Paradigma de Objetos UML – histórico UML – introdução e definições básicas Princípios de Análises e projetos de sistemas

2. A noção de tipos abstratos de dados (TAD) se refere ao encapsulamento de uma estrutura de dados juntamente com as operações que manipulam essas estruturas dentro de uma região protegida. Uma linguagem dá apoio a tipos abstratos de dados quando ela possui mecanismos que permitem a sua representação diretamente. Tipos Abstratos de Dados

3. Linguagens de programação como Ada e Modula-2 dão apoio a tipos abstratos de dados, mas ainda têm certas limitações. As principais são: • O sistema de tipos é unidimensional, ou seja, um programa é desenvolvido como um conjunto de tipos abstratos de dados cuja estrutura é definida no nível horizontal: as hierarquias de generalização/ especialização não podem ser representadas explicitamente.

4. Tipos abstratos de dados não são representados explicitamente em tempo de execução, isto é, embora tipos abstratos de dados sejam úteis durante as fases de análise, projeto e implementação, eles desaparecem durante o tempo de execução e o software se torna de novo um monte de linhas de código agrupadas em módulos completamente desestruturados.

5. O próximo passo da evolução das linguagens de programação foi introduzido com o conceito de objetos, criado por Dahl e Nygaard com a linguagem Simula-67 [17], e consolidado com a linguagem Smalltalk-76. Simula-67 introduziu os conceitos de classe, objeto e herança. Programação Orientada a Objetos

6. O modelo clássico de objetos emprega classes para a descrição de objetos. Essas classes contém a definição da estrutura dos objetos (dados e funções). Além disso, através dos mecanismos de herança e agregação, classes já existentes podem compartilhar seu comportamento com novas classes.

7. Essencialmente, o modelo de objetos trata dados e funções como aspectos indivisíveis no domínio do problema. O forte relacionamento entre o modelo de objetos e a noção de tipo abstrato de dados se torna evidente, uma vez que os objetos podem ser vistos como instâncias de tipos abstrato de dados.

8. Na verdade, na maioria das linguagens orientadas a objetos, a definição de uma classe descreve um tipo de dados associado com as operações que podem ser executadas nas instâncias desse tipo.

9. Introdução do conceito de objetos no ano de 1967, lançamento da linguagem Simula-67. Em 1972 Dahl escreveu um artigo sobre ocultamento de informações (o conceito de objetos nesta época já estava bem definido). Em 1976 foi lançada a primeira versão do Smalltalk e a orientação a objetos foi consolidada. A partir daí, o modelo de objetos evoluiu no sentido de oferecer novas linguagens de programação. 6 acontecimentos que marcaram acriação do modelo de objetos:

10. Em 1983 foi disponibilizada a primeira versão do C++, versão orientada a objetos da disseminada linguagem C. Em 1988, foi lançada a linguagem Eiffel, a primeira linguagem considerada orientada a objetos “pura”. No final do século XX, mais precisamente no ano de 1995, foi lançada a primeira versão da linguagem Java, uma linguagem orientada a objetos “pura”, baseada na sua antecessora C++. 6 acontecimentos que marcaram acriação do modelo de objetos:

11. Programação orientada a objetos é um modelo de programação baseado em conceitos, tais como objetos, classes, tipos, ocultamento da informação, herança, polimorfismo e parametrização. Análise e projeto orientados a objetos oferecem uma maneira de usar todos esses conceitos para a estruturação e construção de sistemas. Esses conceitos são intrinsicamente independentes de linguagense cada uma tem sua própria maneira de implementá-los.

12. A essência da programação orientada a objetos é a resolução de problemas baseada na identificação de objetos do mundo real pertencentes ao domínio da aplicação e no processamento requerido por esses objetos, através de interações entre eles.

13. Esta ideia de “programas simulando o mundo real” cresceu com o lançamento do Simula-67, que inicialmente foi projetada para o desenvolvimento de aplicações de simulação. Devido ao fato do mundo estar povoado de objetos, uma simulação de tal mundo deveria conter objetos simulados capazes de enviar e receber mensagens e reagir às mensagens recebidas.

14. Consequentemente, na programação orientada a objetos, a execução de um programa consiste de um conjunto de objetos relacionados que trocam mensagens entre si, isto é, que se comunicam através da execução das operações uns dos outros.

15. Cada objeto tem um estado interno composto por atributos que são modificados mediante a recepção e o envio de mensagens. Programas são construídos através da definição de classes, que se relacionam e formam hierarquias de abstração.

16. Melhor estruturação do sistema e do encapsulamento entre dados e funções; Facilita a construção de programas complexos; Aumento da reutilização; A estruturação do raciocínio e o menor acoplamento proporcionado pelo conceito de objetos melhoram a qualidade do produto final e reduzem os custos de manutenção do sistema. Benefícios da programação OO:

17. Para a resolução de problemas, a abordagem estruturada utiliza uma técnica conhecida como decomposição funcional. Dessa forma, uma operação complexa é dividida em operações menores e assim sucessivamente, até atingir um nível de detalhes que possa ser implementado facilmente. Programação Orientada a Objetos vs. Programação Estruturada

18. Dessa forma, as funções assumem um papel central no desenvolvimento, que recebem dados de entrada e produzem dados de saída. Apesar da estreita relação entre dados e funções, nas linguagens estruturadas esses dois conceitos são completamente disjuntos, tratando cada um deles de uma maneira particular. Programação Orientada a Objetos vs. Programação Estruturada

19. Por essa razão, os processos estruturados de desenvolvimento de software exigem mudanças de contexto constantes, o que dificulta o mapeamento dos artefatos de diferentes fases do desenvolvimento. Programação Orientada a Objetos vs. Programação Estruturada

20. O encapsulamento de dados e funções, decorrente do conceito de objetos e classes foi um grande passo para a homogenizaçãodo raciocínio e a redução da complexidade dos sistemas. Com essa visão unificada, a ideia central passa a ser a decomposição de dados, ao invés da decomposição funcional. Programação Orientada a Objetos vs. Programação Estruturada

21. As funções se tornam ligadas a um modelo de dados, que juntos formam o conceito de classe. Em OO, as classes desempenham um papel semelhante aos módulos da programação estruturada, com a vantagem de garantir a coesão entre elementos agrupados (dados e funções). Programação Orientada a Objetos vs. Programação Estruturada

22. Programação Orientada a Objetos vs. Programação Estruturada

23. Programação Orientada a Objetos vs. Programação Estruturada

24. Existe uma distinção clara entre: Linguagens baseadas em objetos – quando ela dá apoio explícito somente ao conceito de objetos; Linguagens baseadas em classes- quando ela dá apoio tanto para a criação de objetos, quanto para o agrupamento de objetos através da criação de novas classes; Linguagens orientadas a objetos - proporciona suporte linguístico para objetos, requer que esses objetos sejam instâncias de classes e além disso, oferece suporte para um mecanismo de herança. Linguagens Orientadas a Objetos

25. Linguagens Orientadas a Objetos • Linguagens como Ada85 e CLU são baseadas em objetos, enquanto C++, Java, C#, Modula-3 e Smalltalk-80 são orientadas a objetos.

26. Um ponto muito importante na programação orientada a objetos é a obtenção de componentes reutilizáveis e flexíveis através de conceitos como, por exemplo, objetos, classes, tipos, herança, polimorfismo, e acoplamento dinâmico. O conceito de herança é exclusivo do modelo de objetos. Linguagens Orientadas a Objetos

27. Objetos: O modelo de objetos representa elementos que encontramos no mundo real. Esses elementos podem ser de vários tipos, como entidades físicas (aviões, robôs, etc.) e abstratas (listas, pilhas, filas,etc.). A característica mais importante (e diferente) da abordagem orientada a objetos para desenvolvimento de software é a unificaçãodos dados e funções, que tradicionalmente são considerados separadamente. Fundamentos do Paradigma de Objetos

28. A representação unificada desses dois elementos de programação resulta no que nós chamamos de encapsulamento. O encapsulamento possibilita omitir detalhes desnecessários externamente aos objetos. Objeto = dados(privados) + procedimentos(públicos) Fundamentos do Paradigma de Objetos

29. Classes: Classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. Representam uma ideia ou um conceito simples e categoriza objetos que possuem propriedades similares. Todos os objetos de uma classe possuem as mesmas definições, mas podem possuir valores diferentes nos dados, respondendo de modo diferente as mensagens enviadas. Fundamentos do Paradigma de Objetos

30. Herança: É a capacidade de um novo objeto tomar atributos e operações de um objeto existente, permitindo criar classes complexas sem ter que repetir o código. Se uma classe herda comportamento e atributos de mais de uma classe damos a ela o nome de herança múltipla, uma variação semântica de generalização, na qual um tipo pode ter mais de um supertipo. Fundamentos do Paradigma de Objetos

31. Classe Automóvel Automóvel Esportivo Porsche Fundamentos do Paradigma de Objetos A Classe Automóvel contém informações como potência , passageiros, etc... A sub Classe Esportivo herda todas essas propriedades e acrescenta outras. Por Fim Porsche herda todas as propriedades das classes acima.

32. Mensagens: Os objetos se comunicam através de mensagens, isto é, um sinal é enviado a um objeto requisitando um serviço, as operações são executadas e o resultado da operação é enviado ao objeto solicitante. Uma mensagem é a chamada de uma função de um objeto, o acionamento de uma operação encapsulada no objeto de destino, feita a partir do objeto de origem. Fundamentos do Paradigma de Objetos

33. Para que os objetos se comuniquem é necessário que haja algum tipo de ligação /vínculo entre eles. Esses vínculos podem ser relacionamentos entre os objetos. Exemplo: Controle Remoto Televisão Envia Fundamentos do Paradigma de Objetos

34. O controle remoto envia uma mensagem para a tv, mas essa só consegue interpretar a mensagem por que possui uma interface derecepção. A definição das interfaces e das mensagens a serem implementadas nos objetos é uma importante atividade de modelagem de software, é feita na fase de design de um projeto de software. Fundamentos do Paradigma de Objetos

35. Polimorfismo: Polimorfismo é a propriedade que o emissor de uma mensagem não precisa saber a instância da classe que recebe esta mensagem. Essa propriedade leva ao fato de que uma mensagem pode ser interpretada de várias formas daí o nome Polimorfismo. Fundamentos do Paradigma de Objetos

36. Polimorfismo Saldo (Correntista ) Saldo Saldo Poupança Saldo Renda Fixa Saldo Fundo de Ações Fundamentos do Paradigma de Objetos

37. UML começou a ser definida a partir de uma tentativa de Jim Rumbaugh e GradyBooch de combinar dois métodos populares de modelagem orientada a objeto: Booch e OMT (ObjectModelingLanguage). Mais tarde, IvarJacobson, o criador do método Objectory, uniu-se aos dois (formando os famosos três amigos), para a concepção da primeira versão da linguagem UML (UnifiedModelingLanguage). UML foi adotada em 1997 pela OMG (Object Management Group). UML - Uma Breve História

38. Outubro/1995 o esboço da versão 0.8 foi lançada Junho/1996 – Lançada a versão 0.9 da UML Foi estabelecido um consórcio de UML com a participação das empresas: Rational Software; Digital; Hewlett-Packard; I L i I t li IBM I C ti MCI StH Programação Orientada a ObjetosFláviode Oliveira Silva, M.Sc. -Logix; Intelicorp; IBM; Icon Computing; MCI SystemHouse; Microsoft; Oracle; Texas Instruments e Unysis. Este consórcio apresenta em Janeiro/1997 a UML 1.0 UML - Uma Breve História

39. A UML 1.0 foi oferecida ao OMG (ObjectManagement Group) Em 1997 o consórcio se ampliou Em 1997 o consórcio se ampliou Em Novembro/1997 o OMG adotou a UML 1.1 O grupo RevisionTask Force (RTF) do OMG assume a manutenção da linguagem e em Junho/1998 a versão 1.2 foi lançada Em Dezembro/1998 o RTF lançou a versão 1.3 da UML 2001 - Versão 1.5 2003 – Lançamento da Especificação 2.0 pelo OMG UML - Uma Breve História

40. UML - Uma Breve História

41. A UML (UnifiedModelingLanguage) é uma notação para descrição de sistemas orientados: – “TheUnifiedModelingLanguage for ObjectOrientedDevelopment” de GradyBooch,James Rumbaugh e Ivar Jacobson. • Baseia-se na experiência dos principais autores dos 3 principais métodos OO. • Esta notação foi padronizada pela OMG (ObjectManagement Group) em 19 UML - Definição

42. Da mesma forma que é impossível construir uma casa sem primeiramente definir sua planta, também é impossível construir um software sem inicialmente definir sua arquitetura. UML - Motivação e Necessidade de uma Modelagem Visual

43. Desta forma, é extremamente importante ter uma representação visual de seu sistema antes que ele entre na etapa de implementação. Descobrir entre as etapas a serem percorridas, aquelas mais importantes do ponto de vista do cliente.

44. Necessidade de estabelecer um rumo, que deve ser definido a partir dos requisitos de software. Uma modelagem visual permite representar (especificar) estes requisitos, ou seja, facilita a captura destes requisitos. Necessidade de estabelecer uma padronização para facilitar a comunicação entre os analistas (responsáveis pelo levantamento dos requisitos) e o time de desenvolvimento (responsáveis pela implementação).

46. Um sistema tem geralmente muitas classes (centenas e até milhares) e nem sempre estas classes são vistas por uma só pessoa. Isto é, dependendo do nível hierárquico desta pessoa, formas diferentes de apresentar uma diagrama de classes devem existir.

47. Um cliente não quer saber o que é uma classe, mas apenas compreender determinados conceitos; • Um gerente de um projeto não precisa ver detalhes de um modelo; • Um time de desenvolvimento precisa ver um diagrama e compreender uma série de detalhes.

49. Um modelo dever ser criado independentemente de sua implementação. A qualquer momento uma implementação pode ser trocada por outra sem afetar o modelo.

50. A utilização de uma modelagem visual facilita a visualização, e, por conseguinte, a criação de um melhor modelo (mais flexível, mais robusto e principalmente mais reutilizável).