Orientação a Objeto

Assunto 1

Módulo 1: Orientação a Objetos

 Introdução

Nos últimos anos, a Programação Orientada a Objetos tornou-se muito popular. O aumento de sua relevância no mundo de programação atual é em grande parte devido às seguintes razões:

• Orientação a Objetos é particularmente adequado para fazer determinadas aplicações.
• Os mecanismos de encapsulamento de linguagens orientadas a objetos suportam um alto grau de reutilização de código, que é reforçada por mecanismos de herança.
• No campo bancos de dados, Orientação a Objetos encaixa bem com os mecanismos propostos pelos modelos de dados semânticos para resolver as limitações dos módulos tradicionais de dados, incluindo relacional.

Estas razões fazem dentro das tendências atuais em engenharia de software no âmbito da programação orientada a objetos a serem considerados como o mais adequado para a criação de projeto e desenvolvimento de aplicações.

Programação orientada a objetos é um conjunto de técnicas para obter qualidade interna como um meio para obter qualidade externo (Reutilização e extensibilidade).

Características de Programação Orientada a Objetos

Existem algumas características-chave da programação orientada a objetos, tais como:

• Produtividade de programação.
• Facilitar a manutenção do programa.
• Facilitar a abstração de programação: deve ser focado nas operações necessárias deixar a sua execução em segundo lugar.
• Facilitar a concepção hierárquica e estruturada.
• Facilitar a reutilização de código: uma vez que uma série de operações foi definida, usá-los em outros programas.
• Facilitar a construção de bons programas de observação portabilidade, legibilidade e facilidade de manutenção.
• Facilitar a documentação do programa.

A modularidade

Um produto de software bom deve ser modular. Um programa é modular, quando ele é formado por um conjunto de módulos de claros e independentes. Um módulo é a unidade básica de decomposição de um sistema de software.

Um método de construção de software é modular, se ele ajuda a produzir sistemas de software a partir de elementos autônomos interligadas por uma estrutura simples e consistente.

A principal razão para a modularidade, é a capacidade de reutilização, de modo que a composição dos módulos deve ser estudado para promover este propósito.

Os princípios da abstração, encapsulamento e modularidade não são independentes, mas eles formam um todo, porque o conceito unificador é a abstração, e tanto o encapsulamento e modularidade são em torno dele.

Há cinco critérios e cinco princípios básicos para determinar quando um método de construção é modular.

A modularidade: 5 critérios

Há cinco requisitos que um método de construção de software deve cumprir para merecer ser chamado modular:

• Para permitir uma decomposição modular
• Para permitir que uma composição modular
• Para produzir fácil de compreender módulos
• Para promover a continuidade software
• Proteção Modular

Decomposição Modular

[pic 1]

Um método de construção de software satisfaz a decomposição se modular que permite a decomposição de um problema em um pequeno número de menos sub-problemas complexos, ligados por uma estrutura simples e tratados separadamente. As unidades devem ser mínimas e devem conhecer uns aos outros.

Este critério é essencial para o desenvolvimento modular de sistemas não triviais.

Composição Modular

[pic 2]

Um método satisfaz a Composição Modular se favorece a produção de elementos de software que podem ser combinados para criar novos sistemas, possivelmente em ambientes diferentes daqueles em que foram criados.

Embora a decomposição modular tenta fazer produtos a partir das especificações, a composição é um processo inverso: a partir dos elementos de software, tenta combiná-los para aplicá-los na construção de novos sistemas.

Entendimento Modular

Um método favorece o entendimento Modular se facilitar que quem lê o módulo pode entendê-la sem ter que recorrer a outros módulos (na pior das hipóteses, alguns módulos), ou seja, ele ajuda a compreender cada módulo separadamente.

Continuidade Modular

Um método satisfaz a Continuidade modular se arquiteturas de software são promovidos em que uma pequena alteração nas especificações dá origem a uma alteração de um único módulo, ou em um pequeno número de módulos. Essas mudanças não devem afetar a arquitetura do sistema global.

Proteção Modular

Um método satisfaz a proteção modular se certas arquiteturas são gerados em que o efeito de uma condição excepcional, o erro, o que ocorreu em tempo de execução, só afeta o módulo onde ela ocorre, ou apenas se espalha para os módulos vizinhos.

A modularidade: 5 Princípios

Cinco princípios resultam dos critérios anteriores que devem ser seguidas para garantir a modularidade:

• Unidades Modulares Linguísticos
• Poucas conexões entre módulos
• Troca de informações intermodulação mínima.
• Conexões explícitas
• Informações esconderijo

Unidades Modulares Linguísticos

Os módulos devem corresponder a unidades sintáticas na língua utilizada. Esta pode ser uma linguagem de programação, uma linguagem de design, uma linguagem de especificação, etc.

Quanto às linguagens de programação, os módulos devem ser compilados separadamente.

Este princípio trata dos critérios de continuidade, a composição, decomposição e proteção modular antes mencionados.

Algumas Interfaces

Cada módulo deve comunicar-se, tanto quanto possível, com o menor número de módulos.

Este princípio trata dos critérios de continuidade e de proteção.

Pequenas Interfaces

Se dois módulos de comunicar uns com os outros, eles devem trocar a menor quantidade de informação.

Este princípio trata dos critérios de continuidade e proteção.