Operacionais e de Extensão
Patrícia Melo Sales1, Antônio César B. G. da Silva1, Glauco Carneiro1
1
Universidade Salvador (UNIFACS)
Salvador –Ba - Brasil
paty1.melo@gmail.com, cesar_dickinson@hotmail.com,
glauco.carneiro@unifacs.br
1. Introdução
Muitos padrões são embutidos em nossa mente: nós herdamos ações e ralações que
garantem a nossa sobrevivência. Outros padrões devem ser aprendidos. A habilidade
para observar padrões nos dá a vantagem humana tanto de mudar quanto de adaptar
nosso ambiente.
O ciclo de vida do software orientado a objeto tem várias fases. Brian Foote identifica-
as como prototipação, expansão e consolidação [FOO, 1992].
A fase da prototipação é meio agitada a medida que o software é trazido a vida através
da prototipação rápida em mudanças incrementais, até que satisfaça um conjunto inicial
de requisitos e atinja a adolescência, neste ponto o software normalmente consiste de
hierarquias de classes que refletem aproximadamente as entidades no domínio do
problema inicial. O principal tipo de reutilização é a da caixa branca, usada em herança.
Uma vez que o software atingiu a adolescência e é colocado em serviço, sua evolução é
governada por duas necessidades conflitantes: (1) o software deve satisfazer mais
requisitos, e (2) o software deve ser mais reutilizável. Comumente os novos requisitos
apresentam novas classes e operações e, talvez, novas hierarquias completas de classes.
O software passa por uma fase de expansão para atender aos novos requisitos. Com
tudo, isto não pode continuar por muito tempo. Eventualmente, o software vai se tornar
muito inflexível “endurecido” para permitir mais mudanças.
Para continuar a evoluir, o software deve ser reorganizado por um processo conhecido
como refatoração [FOWLER, 1999]. Esta é a fase na qual frequentemente se detectam
possíveis frameworks. A refatoração envolve separar as classes em componentes
especiais e componentes de finalidades genéricas, movendo as operações para cima e
para baixo ao longo da hierarquia de classes e racionalizando as interfaces das mesmas.
Esta fase de consolidação produz muitos tipos novos de objetos, frequentemente pela
decomposição de objetos existentes e pela utilização da composição de objetos ao invés
de herança. A necessidade contínua de satisfazer mais requisitos, juntamente com a
necessidade de maior reutilização, faz o software passar por repetidas fases de expansão
e consolidação – de expansão à medida que novos requisitos são atendidos, e
consolidação à medida que o software se torna mais genérico.
expansão
Prototipação Consolidação
É impossível desenvolver aplicação, seja qual for o tamanho que não necessitem ser
mantidos. Sobre o ciclo de vida de um sistema, suas exigências originais serão
modificadas ao refletir necessidades de mudança, o ambiente do sistema mudará, e os
erros obscuros, durante a validação do sistema, emergirão. Porque a manutenção é
inevitável, os sistemas devem ser projetados e executados de modo que os problemas da
manutenção sejam minimizados.
a) Manutenção preventiva.
b) Manutenção adaptável.
c) Manutenção corretiva.
d) Manutenção perfectiva.
O mundo real está em constante mudança, e sistemas são feitos para refletir
comportamentos do mundo real [GALL, 1997], logo é necessário que o software
acompanhe as mudanças de requisitos impostas pelo ambiente na qual ele está inserido.
Uma falha em acompanhar essas mudanças pode implicar em perda de qualidade por
parte do software ou até mesmo no fim da sua vida útil.
Este trabalho propõe, portanto, uma metodologia que atende tais necessidades
considerando somente os padrões de extensão e operacionais. Para isso será utilizada
uma lista de verificação dos padrões, onde através desta, teremos o resultado do nível de
aderência.
Condição 3. Existe uma interface definida para acessar os elementos da coleção a classe
Iteradora?
Condição 3. Existe uma classe abstrata Visitor (classe mãe) para todos os visitantes de
uma árvore do abstract sintaxe?
Cada condição de uma lista de verificação terá um peso, calculado da seguinte forma:
Divide-se 100 pelo número de condições associadas a cada padrão. De cada premissa,
deve ser analisado, de qual (is) esta é dependente ou quais dependem dela. Para cada
uma que ela depende, ela perde 3% da sua importância, e de cada uma que depende
dela, ela ganha 3%. Por exemplo: Num padrão existem 5 premissas. Dividindo por 100
dá 20 para cada. Caso a premissa 1 dependa de duas premissas, seu peso resultante será
de 14%. E cada premissa que a 1 dependeu ganhou 3%, ficando cada uma com 23%.
Exemplo: Template Method:
Template Method Relação entre condições Peso da condição
Condição 3 2 22%
Segue para demais padrões. Como passo seguinte, será executado um estudo de caso
avaliando o nível de aderência dos padrões estudados
6. Considerações Finais
7. Referencias
[ALEXANDER, 1977] ALEXANDER, C. et al. A Pattern Language. New York:
Oxford University, 1977.
[DYER, MARTIN, 95]Dyer, S., Martin, J. and Zulauf, J. (1995) “Motion Capture White
Paper”, http://reality.sgi.com/employees/jam_sb/mocap/MoCapWP_v2.0.html,
December.
[ECKEL, Bruce. [EBook] Thinking In Patterns - Problem-Solving Techniques Using Ja-
va.
[FOO,1992] BRIAN Foot. A fractal model of the lifecycles of reusable objects.
OOPSLA’ 92 Workshop on Reuse, Readgin, Ma, 1992.
[FOWLER,1999] FOWLER, M. Refactoring- Improving the design of the existing code.
Adisson Wesley. 1999.
[GALL, 1997] HARALD, Gall, MEHDI, Jazayeri, RENÉ, Klosch, GEORGE,
Trausmuth- Software Evolution Observations based on product release. Proceedings
of the International Conference on Software Maintenance. 1997.
[GAMMA e outros]GAMMA, E; HELM, Richard; JOHNSON, Ralph, VLISSIDES,
John. Design Patterns - elements of reusable object-oriented software. Addison-
Wesley: Mas-sachusetts, 1995.
[GRUBB e TAKANG,2003] GRUBB, P. TAKANG, A. Software Maintenance- Con-
cepts and practice. Second Edition World Scientific Publishing CO. 2003.
[HOLUB, 2004] HOLUB, A. Holub on Patterns. Apress Publishers, 2004.
[LIENTZ, SWANSON 1980] LIENTZ B, SWANSON E. Software Maintenance Man-
agement. Addison-Wesley, 1980.
[LORGE, 1994] LORGE, Parnas- Software Aging. ICSE. 1994.
[METSKER, 2004] METSKER, Steven John. Padrões de projeto em Java / Steven John
Metsker. trad. Werner Loe_er. - Porto Alegre : Bookman, 2004.
[TURSKI 1981] TURSKI W., Software Stability, Proc. 6th A CM European Conf. on
Systems Architecture, London, 1981.
[SOURCEFORGE,2006]http://sourceforge.net/project/showfiles.php?group_id=23316
&package_id=16653, acesso em 01/11/2006.Boulic, R. and Renault, O. (1991)
“3D Hierarchies for Animation”, In: New Trends in Animation and Visualization,
Edited by Nadia Magnenat-Thalmann and Daniel Thalmann, John Wiley & Sons ltd.,
England.
[SMITH, 99] Smith, A. and Jones, B. (1999). On the complexity of computing. In
Advances in Computer Science, pages 555–566. Publishing Press.