3014 3939 logica programação, Notas de estudo de Sistemas de Informação

Baixe 3014 3939 logica programação e outras Notas de estudo em PDF para Sistemas de Informação, somente na Docsity!

Análise e Projeto

Orientados a Objeto

Autor:

Haline Gregório Vicente

Apostila de Análise e Projeto Orientados a Objeto

EmentaEmentaEmentaEmenta

Antes dos Anos 70

Técnicas de Documentação de Programas

Fluxogramas

HIPO (Hierarchy plus Input Process Output-produto IBM)

Outras técnicas

(excesso de diagramas)

Meio dos Anos 70

 Análise Estruturada - Tom de Marco, Yourdon, Gane.

 Projeto Estruturado - Constantine, Myers, Yourdon, Page-Jones

Anos 80

 Modelagem de Informações

 Modelagem Essencial

 Sistemas de Tempo Real

 Ferramentas CASE (Computer Aided Software Engineering)

Anos 90

Análise e Projeto Orientados a Objetos

Coad

Booch

Rambaugh (OMT)

Jacobson

Coleman (FUSION)

UML

Anos 2000...

• WEB

• Componentes
• Frameworks
• eXtreme Programming (XP)
• Orientação a Aspectos (AOP)
• Processos Ágeis

1. Introdução

Entre as idéias fundamentais básicas para a tecnologia orientada a objeto incluem-se:

• Objetos;
• Classes;
• Métodos;
• Herança;
• Encapsulamento.

Cada conceito é uma idéia ou um entendimento pessoal que temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam são denominados objetos.

ObjetoObjetoObjetoObjeto

Um objeto pode ser real ou abstrato.

Os objetos possuem informações (contém dados) e desempenham ações (possuem

funcionalidade).

Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância de

um conceito ou tipo de objeto.

Um objeto é uma instância de uma classe.

Exemplo:

• Uma fatura;
• Uma organização;
• Um vôo de avião;
• Uma pessoa;
• Um lugar.

Na análise e no projeto OO, estamos interessados no comportamento do objeto. As operações são codificadas como métodos. A representação de software OO do objeto é, dessa forma, uma coleção de tipos de dados e métodos. No software OO: Um objeto é qualquer coisa, real ou abstrata, a respeito da qual armazenamos dados e os métodos que os manipulam.

Um tipo de objeto é uma categoria de objeto. (entidade) Um objeto é uma instância de um tipo de objeto. (atributo)

Exemplo: um tipo de objeto poderia ser Fatura e um objeto poderia ser nº. 51.783.

OBS: O termo objeto, porém, é diferente do termo entidade. A entidade preocupa-se apenas com os dados enquanto o objeto preocupa-se tanto com os dados como com os métodos com os quais os dados são manipulados.

MétodosMétodosMétodosMétodos

Os métodos especificam a maneira pela qual os dados de um objeto são

manipulados.

Uma especificação dos passos pelos quais uma operação deve ser executada.

Ele é um script de implementação de uma operação.

Diferentes métodos podem ser usados para executar a mesma operação.

Os métodos de um tipo de objeto referenciam somente as estruturas de dados

desse tipo de objeto.

A ação que um objeto ou uma classe podem desempenhar.

Os métodos são similares às funções e procedures do universo da programação

estruturada.

Um objeto é, dessa forma, uma coisa, com suas propriedades representadas pelos tipos de dados e seu comportamento representado pelos métodos.

EncapsulamentoEncapsulamentoEncapsulamentoEncapsulamento

O ato de empacotar ao mesmo tempo dados e objetos é denominado encapsulamento. O objeto esconde seus dados de outros objetos e permite que os dados sejam acessados por intermédio de seus próprios métodos. Isso é chamado de ocultação de informações (information hiding).

O encapsulamento protege os dados do objeto do uso arbitrário e não-intencional.

Encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da

implementação de um objeto.

O Encapsulamento é importante porque separa a maneira como um objeto se

comporta da maneira como ele é implementado.

A definição de como implementar os conhecimentos ou ações de uma classe, sem

informar como isto é feito.

Classes Abstratas e Concretas

A classe abstrata é uma classe que não possui objetos instanciados a partir dela, enquanto a classe concreta possui objetos instanciados (criados) a partir dela.

Exemplo: No mundo real, por exemplo, existem automóveis e aviões, mas nada que seja simplesmente um veiculo (em outras palavras, se não for um carro ou avião, não é de nosso interesse). Isso significa que podemos instanciar objetos como carros e aviões, mas nunca iremos criar objetos veículos. As classes abstratas são criadas quando necessitamos de uma classe que implemente recursos comuns a duas ou mais classes.

Pessoa

Nome

Endereço

Telefone

Idade

Altura

Registrar()

Matricular()

Pagar()

Estudar()

Cadastrar()

Classe

A T R I B U T O S M É T O D O S

Pedro

Maria

Objetos

Veículo

Avião Carro

Avião – nº. de motores, autonomia, velocidade máxima, altitude máxima, nº. passageiros (arremeter, aterrissar, glissar, aumentar e diminuir a velocidade). Carro - nº. passageiros, autonomia, marca, modelo (fazer curvas, aumentar e diminuir a velocidade). Veículo - nº. passageiros, autonomia (aumentar e diminuir a velocidade).

HerançaHerançaHerançaHerança

É comum haver similaridades entre diferentes classes. Frequentemente, duas ou mais classes irão compartilhar os mesmos atributos e/ou métodos. Como nenhum de nós deseja reescrever várias vezes o mesmo código, seria interessante se algum mecanismo pudesse tirar proveito dessas similaridades. A herança é esse mecanismo. Por intermédio da herança, é possível modelar relacionamentos do tipo “é” ou “é semelhante”, o que nos permite reutilizar rotinas e dados já existentes. Uma subclasse herda as propriedades de sua classe-mãe; uma subclasse herda as propriedades das subclasses e assim por diante. Uma subclasse pode herdar a estrutura de dados e os métodos, ou alguns dos métodos, de sua superclasse. Ela também tem métodos e às vezes, tipos de dados próprios.

Herança – permite tirar proveito das similaridades entre as classes representadas por relacionamentos do tipo “é” ou “é semelhante”.

Subclasse – uma classe que é um subtipo de uma ou mais classes (denominadas superclasses). Como tal, ela herda todas as características de suas superclasses. Em outras palavras, todas as características de uma classe são reusáveis por suas subclasses. Se a classe B herda de A, então dizemos que B é uma subclasse de A.

Superclasse – Uma classe que é um supertipo de uma ou mais classes (tb chamadas de subclasses). Como tal, ela é uma classe a partir da qual todas as suas características são herdadas por suas subclasses. Em outras palavras, todas as características de uma superclasse são reusáveis por aquelas classes que são seus subtipos. Se a classe B herda de A, então dizemos que A é uma superclasse de B.

Exemplo 1: A figura abaixo mostra uma classe e uma subclasse. A subclasse tem os mesmos métodos de sua superclasse, mas tem tb o método G. Ás vezes, uma classe herda propriedades de mais de uma superclasse. Isso é denominado herança múltipla.

Herança Simples e MúltiplaHerança Simples e Múltipla Herança Simples e MúltiplaHerança Simples e Múltipla

Quando uma classe herda características somente de uma outra classe, dizemos que esta é uma herança simples. Quando uma classe herda de duas ou mais classes, temos um caso de herança múltipla. Em qualquer circunstância, o fato que você deverá lembrar é o seguinte: a subclasse herda todos os atributos e métodos das superclasses.

Hierarquias de GeneralizaçãoHierarquias de Generalização^ Hierarquias de GeneralizaçãoHierarquias de Generalização

Um conjunto de classes relacionadas por meio da herança. Uma boa maneira de organizarmos os conhecimentos é arranjando-o em hierarquias do geral para o mais especifico. Por exemplo, a figura abaixo descreve uma hierarquia com o conhecimento do tipo de objeto Pessoa no topo. Isso significa que Pessoa é um tipo de objeto mais geral do que empregado e estudante. Isso significa que empregado e estudante são subtipos de pessoa, ou, inversamente, que pessoa é um supertipo de empregado e estudante.

Pessoa

Empregado Estudante

Vendedor Gerente

Pássaro Lagarto

Dragão

Pássaro – Envergadura de assas, Velocidade máxima (comer/voar). Lagarto – Nº de garras, cor das escamas (comer/voar) Dragão – Nome, Envergadura de assas, Velocidade máxima, Nº. de garras, cor das escamas (expelir/capturar donzelas/comer)

Diferenças entre análise e projeto:

Primeira alternativa:

1. A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema ( o que deve ser feito). É uma atividade de investigação.
2. O projeto modela a solução e consiste das atividades de criação ( como pode ser feito)

Segunda alternativa:

1. A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar
2. O projeto inclui as atividades que resultam em informação que interessa apenas ao programador
3. Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc.

Diagramas Orientados a Objeto

Resumo dos símbolos usados para a analise e projeto orientado a objeto. Como já sabemos um objeto, como uma entidade, é uma coisa real ou abstrata. Nós, por conseguinte, usamos um retângulo para desenhar tipos de objetos. Recomenda-se que os tipos de objetos e classes sejam desenhados com caixas de cantos vivos e as atividades com caixas de cantos arredondados.

Dados Caixa de cantos vivos Representam dados (tipo De entidade, subtipos,registros)

Cardinalidade (multiplicidade)

Exclusividade Mútua Uma e somente uma das Ramificações são tomadas

A

A

A

A

A

B

B

B

B

B

Atividades Caixa de cantos arredondados Representam atividades (funções, processos,procedimentos)

A

X

Y

Z

A está associado a X, Y ou Z.

A

A

A

A

A

B

B

B

B

B

Mínimo Máximo

Mais do que 1

Mais do que 0

Mais do que 1

Mais do que 1

Fluxo ou seqüência

Os métodos orientados a objetos utilizam um modelo único, o qual é utilizado em todas as fases do ciclo de vida de um sistema. Dessa forma, o processo de desenvolvimento de sistemas é simplificado, interativo e controlável. Cada iteração acrescenta características ao modelo, de forma a haver menores possibilidades de inconsistências e erros. O desenvolvimento de sistemas baseado em objetos concentra a maior parte do esforço na fase de análise de requisitos. Esse esforço adicional é compensado pela implementação mais rápida e mais simples do projeto. O sistema resultante é mais completo e de fácil manutenção devido ao encapsulamento e ao reuso. Grande parte de projetos de desenvolvimento de sistemas fracassam devido principalmente à má administração de riscos, construção de sistemas errados e por superestimar a tecnologia. Entre os riscos, podemos citar problemas de domínio de tecnologia, riscos financeiros, impossibilidade de fazer integração, inexistência de testes de requerimentos e código, requerimentos incompletos, ausência de interação com o usuário etc. Uma das maneiras de evitar o fracasso é definir um processo de desenvolvimento de sistemas. O processo de desenvolvimento de sistemas de informação é formado por um conjunto padronizado e documentado de atividades para todas as fases do ciclo de desenvolvimento. O processo de desenvolvimento tem que ser controlado e medido para facilitar a gerência dos riscos do projeto em cada fase, disciplinar a criatividade quando o desenvolvimento é feito em equipe e assegurar a qualidade do sistema. A escolha de uma metodologia constitui um dos passos mais importantes no processo de desenvolvimento de sistemas, e é através dela que as equipes e seus membros mantêm uma linguagem comum durante todo o ciclo de desenvolvimento.

Os principais benefícios na adoção de metodologias são:

• Permitir o compartilhamento da mesma filosofia de trabalho entre os desenvolvedores de sistemas de informação corporativos;
• Evitar trabalho desnecessário;
• Aumentar a produtividade;
• Estabelecer pontos de verificação para acompanhamento e controle de execução do projeto de desenvolvimento;
• Facilitar o envolvimento do usuário no projeto;
• Prover uma notação e linguagem comum.

Com a adoção de tecnologias orientadas a objetos o processo de desenvolvimento passa a ter um enfoque iterativo, com maior participação do usuário, foco em redução de riscos, alto nível de reuso e flexibilidade em relação aos requerimentos. O controle para o processo iterativo é suportado pelo "Rational Objectory Process". O Rational Objectory Process é estruturado em duas dimensões:

Tempo - divisão do ciclo de vida em fases e iterações.

Componentes - produção de um conjunto específico de artefatos com atividades bem definidas.

A estruturação de um projeto através da dimensão 'tempo' envolve a adoção das seguintes fases:

• Iniciação - especifica a visão do projeto.
• Elaboração - analisa o domínio do problema, projeta a arquitetura apropriada, identifica elementos de riscos e desenvolve um plano abrangente de como será implementado o projeto.
• Construção - desenvolve o produto através de iterações incrementais para a transição para os usuários.
• Transição - promove a transição do produto para os usuários (liberação de versão e treinamento). Cada fase é concluída quando os objetivos específicos da respectiva fase são alcançados. As fases se tornaram mais flexíveis, sendo possível encontrar diversas partes do sistema em fases diferentes do ciclo de desenvolvimento.

Cada fase do ciclo de desenvolvimento de sistemas deve ser descrita de acordo com os seguintes tópicos:

• Objetivos;
• Produtos;
• Atividades;
• Pessoas envolvidas;
• Medidas para avaliar a qualidade dos produtos (métricas).

A estruturação de um projeto através da dimensão 'componente' envolve a realização das seguintes atividades realizadas ao longo do processo de desenvolvimento:

• Análise de requisitos - descrição do que o sistema deve fazer.
• Análise – detalhamento das atividades do sistema.
• Projeto - como o sistema será implementado.
• Implementação - desenvolvimento do código que resultará no sistema executável.
• Teste - verificação do sistema inteiro.