princípios de análises e projetos de sistemas

58
PRINCÍPIOS DE ANÁLISES E PROJETOS DE SISTEMAS 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

Upload: damon-rivers

Post on 03-Jan-2016

44 views

Category:

Documents


5 download

DESCRIPTION

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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Princípios de Análises e projetos de sistemas

PRINCÍPIOS DE ANÁLISES E

PROJETOS DE SISTEMASTó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

Page 2: Princípios de Análises e projetos de sistemas

TIPOS ABSTRATOS DE DADOS

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.

Page 3: Princípios de Análises e projetos de sistemas

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:

a) 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.

Page 4: Princípios de Análises e projetos de sistemas

b) 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.

Page 5: Princípios de Análises e projetos de sistemas

PROGRAMAÇÃO ORIENTADA A OBJETOS

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.

Page 6: Princípios de Análises e projetos de sistemas

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.

Page 7: Princípios de Análises e projetos de sistemas

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.

Page 8: Princípios de Análises e projetos de sistemas

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.

Page 9: Princípios de Análises e projetos de sistemas

6 ACONTECIMENTOS QUE MARCARAM ACRIAÇÃO DO MODELO DE OBJETOS:

1) Introdução do conceito de objetos no ano de 1967,

lançamento da linguagem Simula-67.

2) Em 1972 Dahl escreveu um artigo sobre ocultamento

de informações (o conceito de objetos nesta época já

estava bem definido).

3) 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.

Page 10: Princípios de Análises e projetos de sistemas

6 ACONTECIMENTOS QUE MARCARAM ACRIAÇÃO DO MODELO DE OBJETOS:

4) Em 1983 foi disponibilizada a primeira versão do C+

+, versão orientada a objetos da disseminada

linguagem C.

5) Em 1988, foi lançada a linguagem Eiffel, a primeira

linguagem considerada orientada a objetos “pura”.

6) 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++.

Page 11: Princípios de Análises e projetos de sistemas

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

linguagens e cada uma tem sua própria maneira de

implementá-los.

Page 12: Princípios de Análises e projetos de sistemas

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.

Page 13: Princípios de Análises e projetos de sistemas

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.

Page 14: Princípios de Análises e projetos de sistemas

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.

Page 15: Princípios de Análises e projetos de sistemas

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.

Page 16: Princípios de Análises e projetos de sistemas

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:

Page 17: Princípios de Análises e projetos de sistemas

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

Page 18: Princípios de Análises e projetos de sistemas

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

Page 19: Princípios de Análises e projetos de sistemas

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

Page 20: Princípios de Análises e projetos de sistemas

O encapsulamento de dados e funções,

decorrente do conceito de objetos e classes

foi um grande passo para a homogenização

do 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

Page 21: Princípios de Análises e projetos de sistemas

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

Page 22: Princípios de Análises e projetos de sistemas

PROGRAMAÇÃO ORIENTADA A OBJETOS VS. PROGRAMAÇÃO ESTRUTURADA

Page 23: Princípios de Análises e projetos de sistemas

PROGRAMAÇÃO ORIENTADA A OBJETOS VS. PROGRAMAÇÃO ESTRUTURADA

Page 24: Princípios de Análises e projetos de sistemas

LINGUAGENS ORIENTADAS A OBJETOS

Existe uma distinção clara entre:a) Linguagens baseadas em objetos –

quando ela dá apoio explícito somente ao conceito de objetos;

b) 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;

c) 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.

Page 25: Princípios de Análises e projetos de sistemas

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.

Page 26: Princípios de Análises e projetos de sistemas

LINGUAGENS ORIENTADAS A OBJETOS

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.

Page 27: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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ção dos dados e funções, que tradicionalmente são considerados separadamente.

Page 28: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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)

Page 29: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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.

Page 30: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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.

Page 31: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

Classe Automóvel

Automóvel Esportivo

Porsche

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.

Page 32: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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.

Page 33: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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

Page 34: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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.

Page 35: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

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.

Page 36: Princípios de Análises e projetos de sistemas

FUNDAMENTOS DO PARADIGMA DE OBJETOS

Polimorfismo

Saldo (Correntista )

Saldo

Saldo Poupança Saldo Renda Fixa

Saldo Fundo de Ações

Page 37: Princípios de Análises e projetos de sistemas

UML - UMA BREVE HISTÓRIA

UML começou a ser definida a partir de uma

tentativa de Jim Rumbaugh e Grady Booch de

combinar dois métodos populares de modelagem

orientada a objeto: Booch e OMT

(Object Modeling Language).

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 (Unified

Modeling Language).

UML foi adotada em 1997 pela OMG

(Object Management Group).

Page 38: Princípios de Análises e projetos de sistemas

UML - UMA BREVE HISTÓRIA

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 St

H Programação Orientada a ObjetosFlávio de 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

Page 39: Princípios de Análises e projetos de sistemas

UML - UMA BREVE HISTÓRIA

A UML 1.0 foi oferecida ao OMG (Object Management 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 Revision Task 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

Page 40: Princípios de Análises e projetos de sistemas

UML - UMA BREVE HISTÓRIA

Page 41: Princípios de Análises e projetos de sistemas

UML - DEFINIÇÃO

A UML (Unified Modeling Language) é uma notação para descrição de sistemas orientados:

– “The Unified Modeling Language for ObjectOriented Development” de Grady Booch,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 (Object Management Group) em 19

Page 42: Princípios de Análises e projetos de sistemas

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

Page 43: Princípios de Análises e projetos de sistemas

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.

Page 44: Princípios de Análises e projetos de sistemas

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

Page 45: Princípios de Análises e projetos de sistemas
Page 46: Princípios de Análises e projetos de sistemas

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.

Page 47: Princípios de Análises e projetos de sistemas

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.

Page 48: Princípios de Análises e projetos de sistemas
Page 49: Princípios de Análises e projetos de sistemas

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.

Page 50: Princípios de Análises e projetos de sistemas

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

Page 51: Princípios de Análises e projetos de sistemas

UML é uma linguagem para visualização,

especificação, construção e documentação de

artefatos de um software em

desenvolvimento.

UML – CONCEITOS BÁSICOS

Page 52: Princípios de Análises e projetos de sistemas

UML permite modelar:

1. elementos;

2. relacionamentos;

3. mecanismos de extensibilidade;

4. diagramas.

UML – CONCEITOS BÁSICOS

Page 53: Princípios de Análises e projetos de sistemas

1) Elementos:

estruturais

classes, interfaces, componentes

comportamentais

interações, máquinas de estado

grupos de elementos

pacotes, subsistemas

outros

anotações

UML – CONCEITOS BÁSICOS

Page 54: Princípios de Análises e projetos de sistemas

2) Relacionamentos:

Dependências, Associações, Generalizações,

Implementações (realization)

3) Mecanismos de Extensibilidade

Estereótipos

Tagged value

Regras (constraints)

UML – CONCEITOS BÁSICOS

Page 55: Princípios de Análises e projetos de sistemas
Page 56: Princípios de Análises e projetos de sistemas

4) Diagramas

Um modelo é uma descrição completa do sistema

em uma determinada perspectiva.

UML – CONCEITOS BÁSICOS

Page 57: Princípios de Análises e projetos de sistemas

Um modelo é representado por um ou mais

diagramas. Desta forma, um diagrama pode

ser visto como uma visão dentro de um

modelo.

Um diagrama pode ser representado de

várias formas, dependendo de quem irá

interpretá-lo.

Page 58: Princípios de Análises e projetos de sistemas

Inside the Unified Modeling Language, Material da Rational

UML Distilled Applying the Standard Object Modeling Language, Martin Fowler

Curso on-line da TogetherSoft, www.togethersoft.com/services/ practical_guides/umlonlinecourse/

Especificação da Linguagem UML Versão 1.4, OMG Software Architecture

and the UML, Grady Booch (Seminário) http://www.dsc.ufcg.edu.br/~jacques/cursos/map/ht

ml/uml/diagramas/usecases/usecases.htm

BIBLIOGRAFIA: