Desenvolvimento
orientado a objetos com frameworks, padrões e componentes
INE 660600
|
Atualizado em 13/03/2012 |
informações para alunos matriculados
1. Do que trata a disciplina: três abordagens de desenvolvimento de software - frameworks, padrões e
componentes
2. Formato das aulas: aulas expositivas com slides, sendo que o período final do trimestre
será ocupado pelas apresentações dos alunos (as últimas semanas)
3. Pré-requisito: a partir de
2012 a disciplina volta a não ter pré-requisito oficial, mas subentende-se que
os alunos tenham experiência em desenvolvimento orientado a objetos:
programação e modelagem com UML.
4. Avaliação:
5. Horário: quarta-feira,
08:00 às 12:00 horas (pausa no meio)
6. Do que trata a disciplina
No contexto da Engenharia de Software, diferentes
abordagens buscam melhorar a qualidade dos artefatos de software, bem como
diminuir o tempo e o esforço necessários para produzi-los. Frameworks são
estruturas de classes que constituem implementações
incompletas que, estendidas, permitem produzir diferentes artefatos de
software. A grande vantagem desta abordagem é a promoção de reuso de código e
projeto, que pode diminuir o tempo e o esforço exigidos na produção de
software. Em contrapartida, é complexo desenvolver frameworks, bem como
aprender a usá-los. A abordagem de frameworks pode se valer de padrões para a
obtenção de estruturas de classes bem organizadas e mais aptas a modificações e
extensões. O desenvolvimento orientado a componentes pretende organizar a
estrutura de um software como uma interligação de artefatos de software
independentes, os componentes. O reuso de componentes previamente
desenvolvidos, como no caso dos frameworks, permite a redução de tempo e
esforço para a obtenção de um software. Por outro lado, devido a deficiências das
formas correntes de descrição de componentes, é complexo avaliar a adequação de
um componente existente a uma situação específica. Também é complexo adaptar
componentes quando estes não estejam exatamente adequados a necessidades
específicas. Em Arquitetura de Software estudam-se formas de registrar a
experiência de organização estrutural de software. O reuso desta experiência
pode facilitar a definição da organização mais adequada dos componentes de uma
aplicação, complementando a abordagem de desenvolvimento baseado em
componentes. A presente disciplina se preocupa em tratar a integração dessas
abordagens, que têm em comum a reutilização, seja de projeto ou de código, isto
é, o aproveitamento de experiência de desenvolvimento de software.
A Engenharia de Software atua na aplicação de
abordagens sistemáticas ao desenvolvimento e manutenção de software. Os
objetivos principais da Engenharia de Software são a melhora da qualidade do
software e o aumento da produtividade da atividade de desenvolvimento de software
[FAI 86]. A reutilização de software, em contraposição ao desenvolvimento de
todas as partes de um sistema, é um fator que pode levar ao aumento da
qualidade e da produtividade da atividade de desenvolvimento de software. Isto
se baseia na perspectiva de que o reuso de artefatos de software já
desenvolvidos e depurados, reduza o tempo de desenvolvimento, de testes e as
possibilidades de introdução de erros na produção de novos artefatos. A
reutilização de artefatos de software em larga escala é um dos argumentos a
favor da abordagem de orientação a objetos. Em muitos casos
porém, constitui uma perspectiva frustrada, pois a reutilização não é
característica inerente da orientação a objetos, mas é obtida a partir do uso
de técnicas que produzam software reutilizável [JOH 88] [PRE 94].
A produção de artefatos de software reutilizáveis
se coloca como um requisito para que ocorra reutilização de software. Os
princípios que norteiam a modularidade, como a
criação de módulos com interfaces pequenas, explícitas e em pequena quantidade,
e o uso do princípio da ocultação de informação [MEY 88], têm sido ao longo dos
últimos anos o principal elemento de orientação para a produção de bibliotecas
de artefatos reutilizáveis.
A reutilização de artefatos de software pode
abranger o nível de código, como também os de análise e projeto. A reutilização
de código consiste na utilização direta de trechos de código já desenvolvidos.
A reutilização de projeto consiste no reaproveitamento de concepções
arquitetônicas de um artefato de software em outro artefato de software, não
necessariamente com a utilização da mesma implementação.
A forma mais elementar de reutilização de artefatos
de software é a reutilização de trechos de código de aplicações já
desenvolvidas. Para sistematizar esta prática são criadas bibliotecas - como
bibliotecas de funções em linguagem C, por exemplo. Um problema encontrado com
o uso de bibliotecas de artefatos de software é a dificuldade de seleção de um
artefato adequado à aplicação em desenvolvimento. Se o desenvolvedor concluir
que é mais fácil produzir um novo artefato do que buscar um em uma biblioteca,
não haverá reutilização [NEI 89].
Observa-se que a reutilização dos produtos das
etapas de análise e projeto é mais significativa que a reutilização de trechos
de código [DEU 89]. Observa-se na literatura uma convicção de que uma abordagem
voltada à reutilização só alcança resultados significativos se estiver voltada
a um domínio específico [HEN 95] [SIM 95] [NEI 89] [ARA 91]. Neighbors afirma que a informação contida em produtos das
etapas de análise e projeto é específica do domínio de aplicações tratado [NEI
89]. Verificam-se dois objetivos distintos, na reutilização no nível das
especificações de análise e projeto:
Produzir uma
aplicação utilizando o projeto de outra aplicação. Isto é o que ocorre em um
processo de Reengenharia, em que a especificação de uma aplicação é alterada,
de modo a adaptar-se a novos requisitos, e é gerada uma nova aplicação.
Produzir uma
especificação adequada a um conjunto de aplicações (um domínio) e reutilizar
esta especificação no desenvolvimento de diferentes aplicações. Esta é a
abordagem dos frameworks orientados a objetos.
Um framework é uma
estrutura de classes interrelacionadas, que
corresponde a uma implementação incompleta para um
conjunto de aplicações de um domínio. Esta estrutura de classes deve ser
adaptada para a geração de aplicações específicas [JOH 92].
A granularidade do artefato de software reutilizado
é um fator relevante em termos de aumento de produtividade no desenvolvimento
de software. Um programador que usa linguagem C, por exemplo
se utiliza de bibliotecas de funções. Isto se classifica como reutilização de
rotinas [MEY 88]. A reutilização no nível de módulo corresponde a um nível de
granularidade superior à reutilização de rotinas. A reutilização de classes em
orientação a objetos, segundo Meyer, corresponde à reutilização de módulo.
Quando uma classe é reutilizada, um conjunto de rotinas é reutilizado
(métodos), bem como uma estrutura de dados (atributos). Uma classe que implementa uma estrutura de dados pilha, por exemplo, contém
esta estrutura de dados e o conjunto de procedimentos para a sua manipulação.
Reutilizar classes, portanto, tende a ser mais eficiente que reutilizar
rotinas, e de mais alto nível de granularidade (uma classe de objetos tende a
ser um artefato de software mais complexo que uma rotina isolada). Meyer em
1988 enfatizava a necessidade da disponibilidade de artefatos genéricos e afirmava
que "as classes de linguagens orientadas a objetos podem ser vistas como
módulos de projeto bem como módulos de implementação"
[MEY 88]. A reutilização de classes pode ocorrer sob dois enfoques diferentes:
composição: consiste em usar as classes disponíveis em
bibliotecas para originar os objetos da implementação;
herança: consiste em aproveitar a concepção de classes
disponíveis em bibliotecas, no desenvolvimento de outras, a partir de herança.
Uma característica comum à reutilização de rotinas e
à reutilização de classes é que cabe a quem desenvolve a aplicação estabelecer
a arquitetura da aplicação: a organização dos elementos que compõem a aplicação
e o fluxo de controle entre eles. Além disto, há em comum o fato da
reutilização ser de artefatos isolados, cabendo ao desenvolvedor estabelecer
sua conexão ao sistema em desenvolvimento. Em um programa C o programador
determina a chamada de funções; em um programa Smalltalk
o programador procede a interligação das classes
(desenvolvidas e reutilizadas).
A reutilização promovida pela abordagem de
frameworks se situa num patamar de granularidade superior à
reutilização de classes, por reusar classes interligadas, ao invés de isoladas.
A reutilização de código e projeto em um nível de granularidade superior às
outras abordagens citadas, confere aos frameworks o potencial de contribuir
mais significativamente com o aumento de produtividade no desenvolvimento de
software.
O desenvolvimento de software orientado a
componentes é uma outra abordagem que promove o reuso
de artefatos de alta granularidade, com a capacidade de promover reuso de
projeto e código. Nesta abordagem uma aplicação é constituída a partir de um
conjunto de módulos (componentes) interligados. Na medida em que parte das
responsabilidades de uma aplicação seja delegada a um componente reutilizado,
estar-se-á promovendo uma diminuição do esforço necessário para produzir esta
aplicação, o que caracteriza aumento de produtividade - semelhante ao que
ocorre com os frameworks.
Um componente é "uma unidade de composição com
interfaces contratualmente especificadas e dependências de contexto
explícitas" [SZY 96b]. Componentes podem ser desenvolvidos utilizando o
paradigma de orientação a objetos, isto é, como estruturas de classes interrelacionadas, com visibilidade externa limitada [KRA
97], porém, no caso geral, componentes não dependem de tecnologia de implementação. Assim, qualquer artefato de software pode ser
considerado um componente, desde que possua uma interface definida [SZY 97].
Observa-se em comum nas abordagens de
desenvolvimento baseadas em frameworks e em componentes a possibilidade de
reutilização de artefatos de software de alta granularidade, e a caracterização
de reuso de projeto e código. A adoção destas abordagens no desenvolvimento de
software - em conjunto ou isoladamente - pode diminuir significativamente o
tempo para o desenvolvimento de novas aplicações, bem como a quantidade de
código a desenvolver, na medida em que parte das
responsabilidades das novas aplicações são atribuídas a artefatos de
software reutilizados.