Uma Avaliação de Métodos Orientados A Objetos e Modelos de Processo

Relatrio de Pesquisa CIC/UnB - 05/97
Braslia - DF Setembro de 1997
Uma avaliao de Mtodos Orientados a Objetos e Modelos de Processo
Autoras: Gilene do Esprito Santo Borges Prof. Dra. Maria Elenita Menezes Nascimento
Disponvel em ftp://ftp.cic.unb.br/pub/publications/report/rr.97-05.ps.Z
Universidade de Braslia. Instituto Central de Cincias. Departamento de Cincia da Computao. Mestrado em Cincia da Computao. rea: Engenharia de Software. Orientadora: Dra. Maria Elenita Menezes Nascimento.
Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo
Gilene do Esprito Santo Borges.
Setembro - 1997
Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________
Mensagem
YHUGDG
LVW
1y
Qm
JRVWDPR
TX
Qm
HQWHQGHPRV DVVXVWD
*$6721
ii
Agradecimentos
Quero agradecer a Deus pela proteo e orientao que me so sempre concedidos. A minha orientadora, Dr. Maria Elenita Menezes Nascimento, pelas crticas, pela orientao e tambm pelo incentivo que me foram to preciosos. Ao colega M.Sc. Fbio Bianchi Campos pela grande pacincia e inestimvel disponibilidade em poder me esclarecer dvidas a cerca dos aspectos tcnicos deste trabalho. Aos meus pais, Gil Pereira Borges e Leny Cardoso do Esprito Santo Borges, e irmos, Cleide do Esprito Santo Borges e Everton do Esprito Santo Borges, pela ajuda, compreenso e coragem, que mesmo de longe souberam me dar. A um grande amigo e tambm namorado, Alexandre Mesquita Gomes pelo seu carinho e apoio que me foram to preciosos, me possibilitando concluir este trabalho com tranqilidade e perseverana. Aos meus tios Manoel Augusto Soares e Luceny do Esprito Santo e primos, que me acolheram em sua casa, me proporcionando uma tranqilidade inestimvel. Aos colegas de mestrado que, de uma forma ou de outra, me auxiliaram na realizao deste trabalho, em especial M.Sc. Estevam Rafael Hruschka Jnior, Renata Peluso de Oliveira e Hlio Berch Pereira, pela disponibilidade em ajudar-me no entendimento dos aspectos conceituais deste trabalho; no emprstimo de livros e artigos e em como buscar as informaes que me eram necessrias. Aos meus amigos virtuais: Carlos Eduardo de Barros Paes (PUC - So Paulo), Dr. Guilhermo Bustos Reinoso (Chile), Ismar Frango Silveira (ITA - So Paulo), Leandro Pompermaier (UFRGS - Rio Grande do Sul), M.Sc. Rejane Moreira da Costa (USP - So Carlos) e M.Sc. Ricardo Pereira e Silva (UFRGS - Rio Grande do Sul), que foram muito atenciosos; enviando de longe monografias, referncias, artigos e sites para que eu pudesse compreender melhor o assunto.
iii
Resumo
Inicialmente, so apresentados os objetivos deste trabalho e a motivao que possibilitou o incio e a concluso deste. So Apresentam-se neste trabalho alguns conceitos na rea de engenharia de software com o objetivo que o leitor obtenha um esclarecimento destes conceitos bsicos, para melhor compreender o que ser exposto.
A seguir, os modelos de processos clssicos so descritos, so eles: waterfall, prototipao, espiral e transformacional; tambm suas caractersticas, vantagens,
desvantagens e aplicabilidade de cada um destes modelos.
Para que o leitor se sinta familiarizado com o paradigma da orientao a objetos, so abordados os principais conceitos desta sub-rea. E, posteriormente, os cinco mtodos orientados a objetos, escolhidos segundo alguns critrios estabelecidos, so descritos: OMT, OOAD, OOSE, OOA-OOD e FUSION. A descrio dos mtodos um resumo do que o mtodo sugere para ser usado no desenvolvimento de um sistema; as fases a serem seguidas e os modelos e diagramas gerados durante estas fases.
Sero apresentadas tambm: i) as consideraes finais de cada um dos mtodos, descrevendo caractersticas tcnicas e individuais de cada mtodo; ii) uma tabela contendo uma comparao preliminar dos mtodos, onde alguns aspectos so identificados em cada um dos mtodos; iii) uma tabela nivelando os conceitos utilizados pelos autores dos mtodos, pois determinados mtodos nomeiam as definies com nomes diferentes dos que geralmente so utilizados; e iv) uma figura ilustrando a cobertura que cada mtodo faz no ciclo de vida do desenvolvimento.
Esta monografia servir como um background para a dissertao de tese, sendo feito uma pesquisa geral na rea onde futuramente iremos nos aprofundar.
iv
Sumrio
Mensagem ...................................................................................................................... ii Agradecimentos............................................................................................................ iii Resumo.......................................................................................................................... iv Lista de Figuras.......................................................................................................... viii Lista de Tabelas............................................................................................................ ix 1. Introduo ................................................................................................................. 1 2. Objetivos .................................................................................................................... 2 3. Motivao................................................................................................................... 3 4. Aspectos Conceituais ................................................................................................ 4 4.1 Modelos de processo ............................................................................................ 4 4.2 Mtodos ................................................................................................................ 4 4.3 Anlise de riscos .................................................................................................. 4 4.4 Anlise de requisitos ............................................................................................ 5 4.5 Anlise de sistema ................................................................................................ 5 4.6 Projeto.................................................................................................................. 5 4.7 Implementao ..................................................................................................... 5 4.8 Teste ..................................................................................................................... 6 4.9 Manuteno.......................................................................................................... 6 4.10 Consideraes finais .......................................................................................... 6
v
5. Modelos de Processo ................................................................................................. 6 5.1 Modelo Waterfall ................................................................................................. 7 5.2 Modelo Prototipao ........................................................................................... 9 5.3 Modelo Espiral.................................................................................................... 13 5.4 Modelo Transformacional.................................................................................. 15 5.5 Consideraes finais .......................................................................................... 16 6. Aspectos conceituais referente a orientao a objeto .......................................... 17 6.1 Objeto ................................................................................................................. 17 6.2 Classe ................................................................................................................. 18 6.3 Atributos e Instncias......................................................................................... 19 6.4 Operaes .......................................................................................................... 19 6.5 Encapsulamento ................................................................................................. 19 6.7 Mensagem .......................................................................................................... 20 6.8 Polimorfismo ...................................................................................................... 20 6.9 Associao e Ligao......................................................................................... 20 6.10 Agregao e Herana ...................................................................................... 21 6.11 Modelo use case ............................................................................................... 22 6.12 Cenrios ........................................................................................................... 23 6.13 Diagrama de eventos........................................................................................ 24 6.14 Consideraes finais ........................................................................................ 24 7. Mtodos Orientados a Objeto................................................................................ 25 7.1 Escolha dos mtodos ........................................................................................... 26 7.2 Mtodo OOSE .................................................................................................... 29 7.3 Mtodo OMT ...................................................................................................... 33
vi
7.4 Mtodo OOAD ................................................................................................... 37 7.5 Mtodo OOA-OOD ............................................................................................ 44 7.6 Mtodo FUSION ................................................................................................ 48 7.7 Comparao entre os conceitos ......................................................................... 53 7.8 Comparao entre os mtodos........................................................................... 54 7.9 Cobertura dos mtodos ...................................................................................... 57 7.10 Consideraes finais ........................................................................................ 58 8. Concluses ............................................................................................................... 58 Referncias Bibliogrficas.......................................................................................... 60
vii
Lista de Figuras
Figura 1 - Modelo de Processo Waterfall (PRE92) .....................................................8 Figura 2 - Modelo de Processo Prototipao (PRE92) .............................................10 Figura 3 - Modelo de Processo Espiral (PRE92).......................................................13 Figura 4 - Modelo de Processo Transformacional (SOM94) ...................................15 Figura 5 - Objetos da classe Polgonos (baseado em MAR94) ...................................18 Figura 6 - Uma classe (BOO91) .....................................................................................18 Figura 7 - Atributos e Instncias (baseado em SHL90) ..............................................19 Figura 8 - O encapsulamento (baseado em MAR94)...................................................20 Figura 9 Agregao (RUM94) ....................................................................................21 Figura 10 Herana (MAR94) ......................................................................................22 Figura 11 - Um modelo use case (JAC92).....................................................................23 Figura 12 - Um cenrio para uma chamada telefnica (RUM94)..............................24 Figura 13 - Um diagrama de eventos para uma chamada telefnica (RUM94) .......25 Figura 14 - Os processos do mtodo OOSE (JAC92)...................................................29 Figura 15 - A fase de anlise do mtodo OOSE (JAC92) ............................................30 Figura 16 - A fase de construo do mtodo OOSE (JAC92) .....................................31 Figura 17 - A fase de teste do mtodo OOSE (JAC92) ................................................32 Figura 18 - Mtodo OMT (COL96)...............................................................................34 Figura 19 - Macro processo do mtodo OOAD (BOO94) ...........................................38 Figura 20 - Micro processo do mtodo OOAD (BOO94)............................................41 Figura 21 - O modelo OOA - um modelo multicamada (COA91) .............................45 Figura 22 - O modelo OOD - um modelo multicamadas e multicomponentes (COA93).....................................................................................................................46 Figura 23 - Critrios de adio ao CDP (COA93) .......................................................47 Figura 24 - Os componentes do mtodo FUSION (COL96) .......................................49 Figura 25 - As fases do mtodo FUSION.......................................................................49 Figura 26 - Cobertura dos mtodos................................................................................57
viii
Lista de Tabelas
Tabela 1 - Maturidade dos mtodos bsicos orientados a objetos ..............................27 Tabela 2 - Ferramentas CASE que suportam mtodos orientados a objetos ............28 Tabela 3 - Mtodos integradores ....................................................................................28 Tabela 4 - Comparao entre os conceitos utilizados pelos mtodos..........................53 Tabela 5 - Comparao entre os aspectos capturados pelos mtodos ........................55 Tabela 6 - Comparao entre os aspectos capturados pelos mtodos (Cont.) ..........56
ix
1. Introduo
Desde o surgimento da engenharia de software, vrias maneiras de gerenciar o desenvolvimento de sistemas vem sendo propostas, criando abordagens de desenvolvimento, modelos de processo, mtodos, ferramentas automatizadas e grficas, alm de linguagens de programao e mtricas, com a finalidade de desenvolver sistemas que garantam qualidade e produtividade [CAM97]. No entanto, os sistemas desenvolvidos continuam excedendo custos e prazos e, muitas vezes, no retratam os requisitos inicialmente definidos pelo usurio [NAS93] e [PRE95]. Uma pesquisa extensiva tem sido feita para tornar o desenvolvimento de sistemas em uma atividade mais produtiva, controlada e efetiva. Muitos mtodos, modelos de processo e abordagens surgiram para tentar solucionar os problemas do desenvolvimento, mas cada um analisa o desenvolvimento de uma maneira [NAS90]. Isto explica porqu, por exemplo, um mtodo to eficiente no desenvolvimento de um sistema e em outros no. difcil acreditar que com tanto ferramental no se consiga desenvolver um sistema com qualidade. Segundo [PRE95] tais problemas ocorrem devido a: (1) o pouco treinamento formal desse novo ferramental pelos gerentes e desenvolvedores e (2) em conseqncia ao primeiro, estes profissionais utilizam este ferramental de maneira incorreta. Em face aos problemas apresentados, este trabalho visa apresentar um resumo dos principais mtodos orientados a objetos e dos modelos de processo clssicos para desenvolvimento de software, visando que os gerentes e desenvolvedores de software tenham uma melhor compreenso destes aspectos. O trabalho dividido em oito sesses, descritas a seguir. Na seo 2, sero descritos o objetivo geral e os objetivos especficos deste trabalho. Na seo 3, ser descrita qual foi a motivao que fez com que este trabalho fosse realizado. Na seo 4, so apresentados alguns conceitos de engenharia de software para melhor entendimento deste trabalho, como: modelos de processo, mtodos, anlise de requisitos, anlise de sistemas, projeto, codificao, teste e manuteno. Na seo 5, os modelos de processo clssicos (waterfall, prototipao, espiral e transformacional) so apresentados, com sua definio, caractersticas, vantagens, desvantagens e aplicabilidade. Na seo 6, apresentam-se os principais conceitos de orientao a objeto, para uma melhor compreenso dos mtodos orientados a objetos que sero apresentados.
Na seo 7, so apresentados os seguintes itens: i) a escolha dos mtodos; ii) os mtodos orientados a objetos: OOSE, OMT, OOAD, OOA-OOD e FUSION; sua descrio e consideraes finais; iii) a apresentao de uma comparao entre os vrios conceitos dos mtodos; iv) uma comparao preliminar entre os mtodos descritos; e v) a cobertura das fases de desenvolvimento que cada mtodo faz. Finalmente na seo 8, a concluso apresentada onde feita uma crtica ao trabalho e, logo aps as referncias bibliogrficas, que foram utilizadas para o desenvolvimento deste trabalho.
2. Objetivos
O objetivo geral deste trabalho apresentar os aspectos gerais dos modelos de processos e dos mtodos orientados a objetos. A partir do objetivo geral de estudar os modelos de processo e os mtodos, surgem vrios objetivos especficos: (1) apresentar conceitos na rea de engenharia de software; (2) descrever os modelos de processo e suas aplicabilidades; (3) expor conceitos especficos da orientao a objetos, para uma melhor compreenso j que esta rea especfica surgiu recentemente1; (4) descrever cinco mtodos orientados a objetos; (5) fazer uma comparao preliminar entre os mtodos e entre os conceitos utilizados por eles e tambm, uma explanao sobre a cobertura dos mtodos. No objetivo deste trabalho uma descrio de todos os mtodos orientados a objetos, uma vez que a descrio de todos eles levaria muito mais tempo do que o disponvel para a finalizao de uma monografia; e nem tampouco uma comparao ou crtica mais aprofundada dos mtodos orientados a objetos, pois este visa somente um levantamento do estado da arte. Este trabalho servir como um background para a dissertao de tese, que ser o prximo trabalho a ser desenvolvido pelas autoras deste. A dissertao ter como objetivo, auxiliar os desenvolvedores de software na escolha do melhor mtodo orientado a objeto
[PRE95] classifica o surgimento da tecnologia orientada a objetos na quarta era, a qual iniciou-se na metade da dcada de 80; sendo assim uma rea recente.
(dentre os que so apresentados neste trabalho) para o desenvolvimento de um determinado sistema baseando-se em suas caractersticas. Apresentados os objetivos deste trabalho, segue-se a motivao para a sua realizao.
3. Motivao
No incio da dcada de 80 surge uma preocupao com os softwares que so desenvolvidos e uma nova compreenso da importncia do software [PRE95]. Muitos dos problemas relacionados ao desenvolvimento de software foram percebidos no final da dcada de 1960, quando entrou em evidncia a expresso "crise do software". Dentre estes problemas podemos citar: (1) baixa produtividade; (2) qualidade abaixo do adequado; (3) prazos e custos estendidos; (4) falta de tempo na coleta dos requisitos do sistema; (5) alto custo de manuteno; e (6) baixa capacidade de previso; dentre outros. Estes problemas geram insatisfao e falta de confiana por parte dos clientes. Desde a identificao da crise do software, pesquisadores vm propondo alternativas de soluo para tentar minimizar os problemas que afetam o desenvolvimento de software. Algumas das alternativas so as seguintes: criao de modelos de processos, mtodos, ferramentas automatizadas e grficas, mtricas e linguagens de programao. As alternativas de soluo do uma grande margem para a pesquisa, onde os pesquisadores criam, analisam, comparam, criticam e aplicam para verificar a eficincia. Foram propostos os mtodos estruturados, mtodos formais e agora esto sendo propostos os mtodos orientados a objetos. Com tantos mtodos, surge outro problema: os gerentes de desenvolvimento no sabem como escolher o mtodo mais apropriado para o desenvolvimento de seu sistema, pois sua frente est um leque de opes; tornando-se necessrio o estudo e anlise desses novos mtodos. Este trabalho visa contribuir com a rea de engenharia de software, apresentando cinco mtodos orientados a objetos bem conceituados (vide tabela 1), bem como consideraes finais. Se torna tambm necessrio o estudo dos modelos de processo clssicos, pois a escolha do mtodo e do modelo de processo necessita ser feita em conjunto, pois seria bastante complicado escolher um modelo de processo que no se adequa a um determinado mtodo. Por exemplo, o uso do modelo de processo prototipao com um mtodo muito complexo no vivel, necessrio o uso de um mtodo mais simples para que a prototipao possa ser utilizada com sucesso.
A seguir sero apresentadas as definies de alguns conceitos mais importantes na rea de engenharia de software para a compreenso deste trabalho.
4. Aspectos Conceituais
Para que se possa melhor absorver o contedo deste trabalho, necessrio a introduo de alguns conceitos, como: modelo de processo, mtodos, anlise de riscos, anlise de requisitos, anlise de sistema, projeto, codificao, teste e manuteno.
4.1 Modelos de processo

Sistemas de informao so geralmente desenvolvidos seguindo uma seqncia de estgios, tais como: especificao de requisitos, projeto, implementaes e assim por diante. O modelo de processo visto como uma maneira alternativa de executar essa seqncia de estgios [NAS90]. Os modelos de processo determinam os detalhes dos passos a serem seguidos para se desenvolver um software. Eles descrevem o processo e so freqentemente descartados ou includos somente em documentos externos [PRE95].
4.2 Mtodos
Mtodos de engenharia de software proporcionam os detalhes de como fazer para construir o software. Os mtodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, anlise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificao, teste e manuteno. Os mtodos da engenharia de software muitas vezes introduzem uma notao grfica ou orientada linguagem especial e introduzem um conjunto de critrios para a qualidade de software [PRE95].
4.3 Anlise de riscos

Segundo [SOM92], risco um conceito difcil de definir precisamente. Uma boa maneira para pensar em um risco simplesmente algo que no pode dar errado. Por exemplo, 4
se a inteno usar uma nova linguagem de programao, um risco que no exista compiladores apropriados disponveis. Riscos so uma conseqncia de uma informao inadequada e so resolvidos iniciando algumas aes para descobrir informao a qual reduz incerteza. A anlise de riscos uma srie de passos de administrao de riscos que nos possibilita "atacar" o risco: identificao, avaliao, disposio por ordem de prioridade, estratgia de administrao e monitorao dos riscos [PRE95].
4.4 Anlise de requisitos

A anlise de requisitos a fase onde se deve capturar e explicitar os requisitos do usurio a serem satisfeitos [PER96]. O escopo definido para o software proporciona uma direo, mas uma definio detalhada do domnio da informao e da funo do software necessria antes que o trabalho se inicie. Tal definio obtida pela anlise de requisitos.
4.5 Anlise de sistema

A anlise de sistema define o papel de cada elemento num sistema baseado em computador, atribuindo, em ltima anlise, o papel que o software desempenhar. Anlise o estgio do ciclo de desenvolvimento no qual um problema do mundo real examinado para se conhecer seus requisitos sem que se planeje a implementao [RUM94].
4.6 Projeto
O projeto traduz os requisitos do software num conjunto de representaes (algumas grficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura, o procedimento algortmico e as caractersticas de interface [PRE95].
4.7 Implementao
As representaes do projeto devem ser convertidas numa linguagem artificial (uma linguagem de programao convencional; ex.: C++, Eiffel, Visual Basic, Access), que resulte em instrues que possam ser executadas pelo computador [PRE95]. 5
4.8 Teste
Logo que implementado numa forma executvel por mquina, o software deve ser testado para que se possa descobrir defeitos de funo, lgica e implementao [PRE95]. Jacobson [JAC92], sugere que o teste seja dividido em: i) teste dos mdulos separadamente; ii) teste de integrao destes mdulos; e iii) teste do sistema como um todo.
4.9 Manuteno
Na fase de manuteno, concentram-se as mudanas que esto associadas correo de erros, adaptaes exigidas medida que o ambiente do software evolui e ampliaes produzidas por exigncias variveis do cliente [PRE95]. Rumbaugh [RUM94] acrescenta dizendo que esta fase ser a de menor importncia no desenvolvimento de software, pois o esforo deve ser na anlise e projeto.
4.10 Consideraes finais

Os ltimos sete conceitos (anlise de requisitos, anlise de risco, anlise, projeto, codificao, teste e manuteno) so fases do ciclo de desenvolvimento, que deveriam ser cobertas por todos os mtodos para que estes fossem completos; porm veremos no decorrer do trabalho, que poucos mtodos cobrem mais fases do que as essencialmente necessrias2: anlise, projeto e implementao. Agora que j temos os conceitos da rea de engenharia de software estabelecidos, sero apresentados os modelos de processo.
5. Modelos de Processo
Os modelos de processo esto preocupados em estabelecer a ordem de estgios envolvidos no desenvolvimento e evoluo do software e em definir os critrios de transio de uma fase para outra. Tais modelos so importantes, porque eles sugerem a ordem na qual os projetos devem executar suas fases maiores [NAS92].
O provrbio na parede da sala do meu professor na minha escola por que nunca existe tempo suficiente para fazer as coisas certas da primeira vez, mas sempre existe bastante tempo para faz-lo novamente? ... Jessica Keyes
Nos anos 60, o profissional liberal na arte de desenvolver sistemas comea a reconhecer que existia (ou deveria existir) um mtodo para se fazer tal tarefa. No est certo se o conceito apareceu espontaneamente ou cresceu gradualmente (a literatura est cheia de opinies de todo jeito), mas em diferentes reas, aproximadamente ao mesmo tempo, indivduos, pesquisadores, empresas e agncias governamentais comearam a pensar sobre desenvolver sistema de uma maneira mais organizada [KEY93]. Surgiram, ento, modelos de processo preocupados em apresentar etapas pelas quais o desenvolvimento de software deveria se enquadrar, devido as limitaes destes, foram sendo criados, posteriormente, outros modelos, os quais eram a combinao ou extenso dos anteriores. Com esta viso foram definidos vrios modelos de processo; aqui sero apresentados os quatro modelos mais reconhecidos da rea, so eles: waterfall, prototipao, espiral e transformacional, com o intuito de esclarecer profissionais a organizarem o desenvolvimento de software. Veremos tambm nesta seo, definies, caractersticas, vantagens, desvantagens e aplicabilidades dos modelos de processo citados anteriormente.
5.1 Modelo Waterfall 5.1.1 Definio do modelo waterfall

O modelo de processo waterfall foi desenvolvido por Royce [ROY70] para superar os problemas de desenvolver grandes softwares. Neste modelo, o software desenvolvido em sucessivos estgios, os quais so ilustrados na figura 1. Loops de realimentao entre as etapas so recomendados como um meio de verificar a corretude e integrao entre as fases [NAS90].
Essencialmente necessrias, quer dizer, o que geralmente utilizada durante o desenvolvimento de um sistema.

Engenharia de Sistemas Anlise Projeto Codificao Teste Manuteno
Figura 1 - Modelo de Processo Waterfall (PRE92)
O modelo waterfall, ou modelo cascata, o paradigma do ciclo de vida clssico. Este modelo requer uma abordagem sistemtica3 e seqencial ao desenvolvimento do software, que se inicia no nvel do sistema e avana ao longo da anlise, projeto, codificao, teste e manuteno [PRE92].
5.1.2 Caractersticas do modelo waterfall

O modelo waterfall tem um lugar definido e importante na engenharia de software. Ele produz um padro no qual os mtodos para anlise, projeto, codificao, testes e manuteno podem ser colocados. Alm disso, as etapas deste modelo so muito semelhantes s etapas genricas dos outros modelos de processo [PRE92]. Este modelo se caracteriza pelo fato de que a etapa seguinte s se inicia, quando a etapa anterior tiver sido concluda. Por isto, um modelo de processo procedimental.
5.1.3 Vantagens do modelo waterfall

[NAS90] apresenta algumas vantagens em utilizar o modelo waterfall para o desenvolvimento: (1) as etapas sucessivas usadas no modelo waterfall ajudam a eliminar muitas das dificuldades originalmente encontradas nos projetos de software, tais como manuteno cara e programas pobremente estruturados; e (2) o modelo tambm fornece um ambiente mais gerencivel para o desenvolvimento de software distinguindo definies de
O mesmo que ordenada, metdica [FER77].
requisitos de projeto e implementao, permitindo assim, uma maneira mais eficiente de planejar e controlar o desenvolvimento do software.
5.1.4 Desvantagens do modelo waterfall

[SOM92] e [PRE92] concordam que o modelo waterfall o mais antigo e largamente usado, mas tem sido bastante criticado devido aos problemas que, s vezes, surgem quando ele utilizado, que so: (1) requisitos do sistema devem ser bem definidos, nem sempre isso possvel no comeo do desenvolvimento; (2) no existe interao entre desenvolvedor e cliente, ento, uma verso do programa s ser entregue bem mais tarde e encontrar um erro pode ser desastroso; e (3) [PRE92] acrescenta que os projetos reais raramente seguem o fluxo seqencial que o modelo prope, sempre h a incluso de novos requisitos trazendo problemas.
5.1.5 Aplicabilidade do modelo waterfall

Aqui ser apresentado onde o modelo waterfall aplicado com xito e onde no se deve empreg-lo. O modelo waterfall pode ser o modelo de desenvolvimento mais apropriado: i) onde a organizao necessita desenvolver um grande sistema para ser mais estruturado e gerencivel [KAN95]; ii) onde existe o desenvolvimento de sistemas como compiladores e sistemas operacionais [NAS90]. [NAS90] acrescenta que o uso do modelo seria inadequado, quando no possvel construir uma completa descrio dos requisitos e descries intermedirias detalhadas de cada fase.
5.2 Modelo Prototipao 5.2.1 Definio do modelo prototipao

A prototipao uma tcnica para ajudar a estabelecer e validar os requisitos do sistema [SOM92] e [PRE95].
A prototipao um processo que capacita o desenvolvedor a criar um modelo do software que ser implementado. O modelo pode assumir uma das trs formas: (1) um prottipo baseado em computador que retrata a interao homem-mquina de uma forma que capacita o usurio a entender quanta interao ocorrer; (2) um prottipo que implementa algum subconjunto da funo exigida do software desejado; ou (3) um programa existente que executa parte ou toda a funo desejada, mas que tem outras caractersticas que sero melhoradas em um novo esforo de desenvolvimento [PRE92]. A seqncia de eventos para o modelo de processo prototipao ilustrado na figura 2.
Incio Fim
Coleta e refinamento dos requisitos Engenharia do produto Projeto rpido
Refinamen -to do prottipo Avaliao do prottipo pelo cliente
Construo do prottipo
Figura 2 - Modelo de Processo Prototipao (PRE92)
5.2.2 Caractersticas do modelo prototipao

A primeira fase do desenvolvimento utilizando prototipao envolve desenvolver um programa para o usurio experimentar. O objetivo do desenvolvimento estabelecer os requisitos do sistema. Este seguido pela reimplementao do software para produzir um sistema com qualidade [SOM92]. Evidncias mostram que desenvolver um produto atravs da prototipao substancialmente mais rpido e mais barato do que os mtodos tradicionais. [HUM89] aponta algumas consideraes no uso de prototipao:
10
i) se somente se pretende que seja um experimento rpido, os objetivos do prottipo devem ser claramente estabelecidos antes de comear a constru-lo; ii) definir o processo de prototipao. Prototipao no significa desenvolver o cdigo da maneira que ele surge na cabea. Os mtodos usados devem ser apropriados para os objetivos especficos do prottipo; iii) os resultados da prototipao devem ser documentados e analisados antes da deciso ser feita em como proceder; iv) completar o prottipo inicial e analisar os resultados antes de comear outra iterao do prottipo. As iteraes no planejadas podem ser caras; v) no existe uma maneira certa de prototipar. O resultado pode ser jogado fora, usado como uma base para melhoramento, ou reempacotado como produto. Tudo depende dos objetivos originais, o processo usado e a qualidade desejada do resultado. Booch aponta em [BOO96], prottipos devem ser criados exclusivamente por razes nobres, das quais existem poucas: i) obter um entendimento mais profundo sobre os requisitos de um sistema; ii) determinar se certa funcionalidade, performance, custo, confiana ou
adaptabilidade podem ser realizadas; iii) avaliar o risco associado com certo projeto; iv) servir a equipe de desenvolvimento como veculo para comunicar um projeto ao cliente; v) servir como ferramenta de aprendizagem para a equipe de desenvolvimento.
5.2.3 Vantagens da prototipao

As vantagens de utilizar a prototipao, segundo [BOE84] [NAS90], so: (1) produtos com melhores interfaces homem-mquina; (2) sempre tem algo que funciona; (3) reduz o efeito do prazo de entrega no final do projeto; e (4) [HUM89] acrescenta que o desenvolvimento mais rpido e mais barato do que os mtodos tradicionais. Acredita-se que o surgimento destas vantagens se derivam do fato de que desde o comeo do desenvolvimento do sistema, usando-se o modelo de processo prototipao, existe uma interao forte entre o cliente e o desenvolvedor.
11
5.2.4 Desvantagens do modelo prototipao

Apesar de ser um modelo que apresenta vrias vantagens, tambm possui suas desvantagens e dois autores apresentam diferentes vises sobre estas desvantagens. Segundo [BOE84] em [NAS90], as desvantagens de utilizar a prototipao so: (1) proporcionalmente menos esforo em planejamento e projeto e mais em teste e concerto; (2) mais dificuldade em integrao devido a falha de especificao de interface; e (3) projeto menos coerente4. Segundo [PRE92], existem duas desvantagens em se utilizar a prototipao, so elas: (1) quando se consegue realmente definir os requisitos do sistema com a ajuda do usurio, um prottipo foi criado e se parecer, ao modo de ver do usurio, com o produto final, ento o usurio no deseja que este prottipo seja descartado para a criao de um novo produto que levar tempo e dinheiro, mesmo que este seja mais eficiente, e o maior problema que na maioria das vezes a equipe de desenvolvimento cede; (2) acontece quando a equipe de desenvolvimento adota opes como um sistema operacional ou linguagem de programao imprprios, pois esto a disposio, ou algoritmos ineficientes para demonstrar capacidade e se esquecem que estas opes foram adotadas para a rpida prototipao e as englobam ao sistema.
5.2.5 Aplicabilidade do modelo prototipao

Foram encontradas diversas situaes onde o modelo prototipao seria empregado com sucesso, so elas: i) quando o usurio definiu um conjunto de objetivos gerais para o software, mas no identificou os requisitos em detalhes [PRE92]; ii) quando o desenvolvedor pode no ter certeza da eficincia de um algoritmo, da adaptabilidade de um sistema operacional [PRE92]; iii) em situaes onde o projeto do produto complexo e no estruturado [NAS90]; iv) quando os riscos da interface do usurio so dominantes [SOM92], isto significa que a interface muito importante no sistema, ento com o uso da prototipao pode ser verificado se a interface est sendo modelada de maneira correta.
Acredita-se que devido a falta de especificao bem definida, o projeto nem sempre se encontra coerente com os requisitos do usurio.
12
5.3 Modelo Espiral 5.3.1 Definio do modelo espiral

O modelo espiral para a engenharia de software foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento - a anlise de riscos - que falta aos anteriores. O modelo, representado pela figura 3, define quatro importantes atividades representadas pelos quatro quadrantes da figura: (1) planejamento; (2) anlise de riscos; (3) engenharia; e (4) avaliao feita pelo cliente [PRE92].
Planejamento
Anlise dos riscos
No sentido de um sistema concludo
Avaliao do cliente
Engenharia
Figura 3 - Modelo de Processo Espiral (PRE92)
Segundo [JUL88] em [NAS90], o modelo espiral tenta prever e evitar riscos ao invs de s certificar se o produto produzido pela fase de desenvolvimento corrente concorda com as especificaes emitidas pela fase anterior.
5.3.2 Caractersticas do modelo espiral

Segundo [GIL88] em [PRE92], o modelo espiral usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva. O modelo espiral usa a prototipao como um mecanismo de 13
reduo dos riscos, mas, o que mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. Segundo [SOM92], sua caracterstica chave uma avaliao do gerenciamento dos itens de riscos em etapas regulares no projeto e a iniciao de aes para agir contra estes riscos. Antes de cada ciclo, uma anlise de riscos iniciada e no final de cada ciclo, um procedimento de reviso avalia se passa para o prximo ciclo do espiral.
5.3.3 Vantagens do modelo espiral

A grande vantagem do modelo espiral, que neste modelo existe um processo contnuo de reavaliao, possibilitando cliente e desenvolvedor a: (1) identificarem os riscos em cada fase do ciclo; (2) tomarem decises para reagirem contra os riscos; e (3) decidirem se continuam ou no o desenvolvimento.
5.3.4 Desvantagens do modelo espiral

As principais desvantagens em se utilizar o modelo espiral so: (1) pode ser difcil convencer grandes clientes de que a abordagem evolutiva controlvel; (2) ela exige considervel experincia na avaliao dos riscos e fia-se nessa experincia para o sucesso; e (3) se um grande risco no for descoberto, indubitavelmente ocorrero problemas.
5.3.5 Aplicabilidade do modelo espiral

O modelo espiral possui algumas aplicabilidades, que so apresentadas a seguir, segundo [NAS90]: i) aplicvel em desenvolvimento de sistemas para reduzir incerteza; ii) aplicvel em sistemas muito grandes, porque o modelo fornece um mecanismo mais completo de assegurar os requisitos;
14
iii) aplicvel em sistemas altamente distribudos5, devido a caracterstica do modelo de anlise de riscos.
5.4 Modelo Transformacional 5.4.1 Definio do modelo transformacional

Segundo [NAS90] e [SOM92], a abordagem transformacional, apresentada na figura 4, envolve desenvolver uma especificao formal do sistema e transformar esta especificao em um programa. Entretanto, o progresso entre estes dois pontos feito aplicando uma srie de transformaes (T1, T2, T3 e T4), que produziro sucessivas verses at que o programa final seja desenvolvido. Idealmente, todas as regras de transformao6 (R1, R2 e R3) preservam corretude, tal que o produto final satisfaa a especificao original.
Transformaes Formais T1 T2 T3 T4
Especific. Formal R1 R2 R3
Programa Executvel
P1
P2
P3
P4
Provas da corretude das transformaes

Figura 4 - Modelo de Processo Transformacional (SOM94)
5.4.2 Vantagens do modelo transformacional

O modelo transformacional evita a dificuldade de ter que modificar o cdigo o qual tem se tornado pobremente estruturado atravs das repetidas otimizaes, pois as modificaes e ajustamentos so feitos nas especificaes [NAS90].
Sistemas distribudos o processamento no qual parte ou todo o processamento, armazenamento, funes de controle e funes de entrada e sada esto situados em diferentes locais e conectados entre si atravs de recursos de transmisso [CAM93]. Transformao pode envolver especializao ou generalizao da representao corrente, escolhendo uma estrutura de dados, mudando um controle de estrutura para melhorar a eficincia ou outras alteraes [NAS90].
15
[NAS90] apresenta as vantagens da aplicao deste modelo de processo: i) automao da aplicao de transformaes, as quais reduzem o trabalho intensivo do desenvolvimento de software; ii) segurana em aplicar transformaes que podem ser expressas formalmente para assegurar que elas preservam corretude e so livres dos efeitos colaterais; iii) a fase de teste do produto final pode ser substancialmente reduzida ou virtualmente eliminada em muitos casos, o qual pode ser parcialmente substitudo pela verificao das especificaes formais [AGR86]. Segundo [SOM92], quando se pretende provar que o programa est de acordo com suas especificaes, o uso do modelo transformacional melhor, pois a distncia entre cada transformao menor do que a distncia entre a especificao e o programa. Provas de programas so muito grandes e impraticveis para sistemas de grande escala, mas a abordagem transformacional cria uma seqncia de passos menores para ser mais eficiente.
5.4.3 Desvantagens do modelo transformacional

Segundo [SOM92], escolher qual transformao aplicar uma tarefa prtica (exige conhecimento) e provar a correspondncia das transformaes difcil.
5.4.4 Aplicabilidade do modelo transformacional

Segundo [SOM92], o modelo transformacional usado quando os riscos de segurana so a principal considerao no processo de desenvolvimento. O modelo transformacional uma abordagem muito poderosa, mas pode somente ser aplicada a reas muito especficas da cincia da computao. Este modelo de processo apresenta dificuldades quando aplicada a sistemas instveis e pobremente estruturados e orientados a requisitos difceis de serem expressos formalmente [NAS90].

A partir do que foi exposto nesta seo sobre os modelos de processo, pode-se notar que cada um dos modelos apresentados abordam diferentes caractersticas do software a ser desenvolvido. Por exemplo: o waterfall usado para sistemas onde os requisitos so bem definidos, sendo um modelo bastante metdico; a prototipao utilizada para sistemas onde
16
h a necessidade de definir os requisitos e de um desenvolvimento mais rpido e barato; o modelo espiral utilizado quando necessrio a anlise de riscos para decidir se deve continuar o desenvolvimento ou no; e o modelo transformacional aplicado a sistemas bem estruturados com requisitos expressos formalmente. Como cada um desses modelos abordam diferentes caractersticas do software, o estudo e compreenso desses modelos so muito importantes, pois sua escolha vital para o sucesso ou fracasso do desenvolvimento. Com os modelos de processo j apresentados, sero apresentados agora os conceitos de orientao a objeto com a finalidade que o leitor/pesquisador possa compreender melhor os mtodos orientados a objetos que sero descritos logo aps os conceitos.
6. Aspectos conceituais referente a orientao a objeto

Para melhor compreenso dos mtodos orientados a objetos que sero apresentados a seguir, so apresentados aqui alguns conceitos relacionados a orientao a objeto, como: objeto, classe, atributos e instncias, operaes, encapsulamento, mensagem, polimorfismo, associao e ligao, agregao e herana; e outros relacionados aos mtodos que sero apresentados: atores, use cases, modelo use case, cenrios e diagrama de eventos.
6.1 Objeto
Um objeto representa um elemento que pode ser identificado de maneira nica. Em nvel apropriado de abstrao7, praticamente tudo pode ser considerado como objeto. Assim, elementos especficos como pessoas, organizaes, mquinas ou eventos podem ser considerados como objetos [COL96]. A figura 5, ilustra a definio de objetos, que segundo [SHL90], a abstrao de um conjunto de coisas semelhantes. Um objeto tem estado, comportamento e identidade; a estrutura e comportamento de objetos similares so definidos em suas classes comuns [BOO91].
Abstrao o exame seletivo de determinados aspectos de um problema. O objetivo da abstrao isolar os aspectos que sejam importantes para algum propsito e suprimir os que no o forem. A abstrao deve sempre visar a um propsito, porque este determina o que e o que no importante.
17

Objeto Retngulo
apagar
vrtice = 4
Objeto Tringulo
apagar
Atributos
desenhar
vrtice = 3 borda = preta interior = vermelho
Atributos
desenhar
borda = azul interior = branco
mover
Mtodos
mover
Mtodos
Figura 5 - Objetos da classe Polgonos (baseado em MAR94)
6.2 Classe
Segundo [BOO91], uma classe um conjunto de objetos que compartilham uma estrutura comum (atributos) e um procedimento comum (operaes); ilustrado na figura 6.
Polgonos vrtice cor da borda cor do interior desenhar apagar mover
Figura 6 - Uma classe (BOO91)
Uma classe abstrata uma classe que no possui instncias diretas mas cujas descendentes, sim. Uma classe concreta uma classe instancivel; isto , pode ter instncias diretas. Uma classe direta pode ter subclasses abstratas (mas estas, por sua vez, devem possuir descendentes concretos) [RUM94]. As classes so organizadas em nveis hierrquicos compartilhando estruturas e comportamentos comuns e so associadas a outras classes. As classes definem os valores de atributos relativos a cada instncia de objetos e as operaes que cada objeto executa ou a que se submete [RUM94]. Assim, cada objeto dito ser uma instncia de sua classe.
18
6.3 Atributos e Instncias

Os atributos so os dados escondidos pelo objeto em uma classe. Cada atributo tem um valor para cada instncia do objeto. Este valor deve ser um valor de dado puro, no um objeto [BAK96]. A figura 7, ilustra os conceitos j mencionados de atributo e instncia.
Polgonos
Nome Retngulo Tringulo Vrtice 4 3 Cor da borda azul preta Cor do interior branco vermelho
Instncias
Atributos
Figura 7 - Atributos e Instncias (baseado em SHL90) 6.4 Operaes

Segundo [BAK96], operaes ou mtodos so as funes ou transformaes que podem ser aplicados em ou por um objeto numa classe. Todos os objetos numa classe compartilham as mesmas operaes. Cada operao tem um objeto alvo como um argumento implcito. Uma operao pode ter argumentos em adio ao seu objeto alvo, os quais parametrizam a operao. A operao parte da classe e no parte do objeto. A operao pode no ser parte da classe; mas ser uma herana de uma superclasse na hierarquia de classes [MAR94].
6.5 Encapsulamento
O encapsulamento (ilustrado na figura 8), justamente o empacotamento dos atributos e das operaes numa mesma classe. Isto protege os dados contra corrupo, pois somente as operaes da classe podero alterar as estruturas de dados desta classe em questo.
19
Classe
atr1 atr2 atr3
Atributos
Operaes
Figura 8 - O encapsulamento (baseado em MAR94)
6.7 Mensagem
Os objetos se comunicam entre si atravs da mensagem. A mensagem especifica que uma determinada operao de um objeto necessita utilizar uma ou mais operaes de outro objeto. Podem ser passados objetos como parmetro, e, opcionalmente, algum resultado ou valor pode ser retornado. As mensagens especificam que as operaes devem ser executados, no como estas operaes devem ser executados [MON94].
6.8 Polimorfismo
Segundo [MON94], polimorfismo a capacidade de um objeto enviar uma mensagem genrica para muitos outros objetos. Cada objeto alvo implementa a operao, que atende a mensagem genrica, de diferentes maneiras. Mtodo polimrfico8 significa que a mesma operao toma diferentes formas em diferentes classes.
6.9 Associao e Ligao

A associao o relacionamento entre classes e a ligao o relacionamento entre objetos. Assim, uma ligao uma instncia de uma associao [RUM94]. As associaes so bidirecionais e podem ser binrias, ternrias ou de ordem mais elevada; na prtica, geralmente so binrias.
Por exemplo: a classe Arquivo pode ter a operao imprimir para diferentes tipos de arquivos (texto, grfico, arquivos ASCII). Todos estes mtodos executam logicamente a mesma tarefa imprimir arquivo; assim podemos referir-nos a eles pela operao genrica imprimir.
20
6.10 Agregao e Herana

Agregao e herana so tipos de associao, onde a herana tambm chamada por outros autores como generalizao e especializao9. A agregao o relacionamento parte-todo ou uma-parte-de no qual os objetos que representam as partes, so associados a um objeto que representa o todo. Ou seja, as partes formam o todo. A figura 9 ilustra o conceito de agregao.
Microcomputador
Monitor
Teclado
Mouse
CPU
RAM
Figura 9 Agregao (RUM94)

Segundo [MAR94], a herana de classe torna possvel que uma classe compartilhe os atributos e as operaes de outra classe (superclasse). Mas essa classe que herda, tambm tem suas operaes e, s vezes, atributos prprios. Na herana simples, uma classe pode herdar os atributos e as operaes de uma superclasse; e na herana mltipla, uma classe pode herdar os atributos e as operaes de mais de uma superclasse. As trs definies so ilustradas na figura 10. Segundo [RUM94] a vantagem da herana mltipla maior capacidade de especificao de classes e a maior oportunidade de reutilizao; e a desvantagem a perda da simplicidade conceitual e de implementao.
Utiliza-se generalizao para nos referirmos ao relacionamento entre classes, enquanto herana refere-se ao mecanismo de compartilhamento de atributos e mtodos utilizando o relacionamento de generalizao [RUM94].
21
Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________ Classe1 1 2

atr1 atr2
Classe1.1 Herana simples 1 3

atr3 atr1 atr2
Classe1.2
1 2
atr4 atr1 atr2
Herana mltipla
1 Classe2 3
atr1 atr2 atr3 atr4
Legenda
2
Mtodos herdados Mtodos prprios da classe
5 6
Classe Atributos herdados Atributos prprios da classe
Figura 10 Herana (MAR94) 6.11 Modelo use case

Este conceito, por ser utilizado em mais de um mtodo orientado a objeto (OOSE e OOAD), que sero apresentados na prxima seo, merece ser descrito aqui. O modelo use case compe-se de atores e use cases. Estes conceitos so simplesmente uma ajuda para definir o que existe do lado de fora do sistema (atores) e que deve ser executado pelo sistema (use case) [JAC92].
22
Atores modelam algo que necessita trocar informao com o sistema. Atores podem modelar usurios humanos, mas eles podem tambm modelar outros sistemas que comunicam com o que est sendo modelado. Cada use case constitui um percurso completo de eventos iniciados por um ator e ele especifica a interao que acontece entre um ator e o sistema. O use case bastante parecido com o diagrama de eventos de Rumbaugh, ilustrado na figura 13. Os conceitos de atores e use case, os quais compem o modelo use case, esto ilustrados na figura 11.
fronteira do sistema
chamada interna chamada telefnica ator 2
ator 1
Figura 11 - Um modelo use case (JAC92) 6.12 Cenrios

O cenrio um conceito tambm utilizado por mais de um mtodo merecendo ser descrito. Segundo [RUM94], cenrio uma seqncia de eventos que ocorrem durante uma determinada execuo de um sistema. A abrangncia de um cenrio pode variar; ele pode incluir todos os eventos do sistema, ou somente aqueles que influenciam ou que so gerados por certos objetos do sistema. Um exemplo de um cenrio para uma ligao telefnica, ilustrada na figura 12.
23
chamador levanta receptor sinal de discar comea chamador disca dgito (5) sinal de discar pra chamador disca dgito (5) chamador disca dgito (5) chamador disca dgito (1) chamador disca dgito (2) chamador disca dgito (3) chamador disca dgito (4) telefone chamado comea a tocar ouve-se o tilintar do telefone chamando pessoa chamada atende telefone chamado pra de tocar som de chamada desaparece do telefone chamador telefones so interligados pessoa chamada desliga telefones so desligados chamador desliga
Figura 12 - Um cenrio para uma chamada telefnica (RUM94) 6.13 Diagrama de eventos
Aps a escrita do cenrio necessrio identificar os objetos remetente e recebedor de cada evento. A seqncia de eventos e os objetos que permutam eventos podem ser mostrados em um cenrio ampliado denominado diagrama de eventos, o qual ilustrado na figura 13.

A partir da apresentao dos conceitos de orientao a objeto, pode-se notar que as idias so bem diferentes daquelas introduzidas pelos mtodos estruturados. O paradigma de orientao a objetos uma evoluo do paradigma estruturado e vem com o intuito de melhorar o desenvolvimento de software abordando-o de outra maneira, visando principalmente o reuso com o uso de objetos, herana e encapsulamento. Vejamos agora os cinco mtodos orientados a objeto (OMT, OOAD, OOSE, OOAOOD e FUSION), comparaes entre eles e entre seus conceitos, juntamente com a cobertura de cada um.
24

chamador chamador levanta receptor sinal de discar comea disca (5) sinal de discar disca (5) disca (5) disca (1) disca (2) disca (3) disca (4) som de campainha telefone toca atende telefone som de campainha pra telefones interligados campainha pra telefones interligados pessoa chamada desliga conexo desfeita chamador desliga conexo desfeita linha telefnica chamado
Figura 13 - Um diagrama de eventos para uma chamada telefnica (RUM94)
7. Mtodos Orientados a Objeto

Nesta seo sero apresentados cinco mtodos orientados a objeto: OOSE, OMT, OOAD, OOA-OOD e FUSION; uma comparao entre os mtodos apresentados e seus principais conceitos, pois eles diferem uns dos outros; e, posteriormente, a cobertura de cada um dos mtodos. Antes de ser iniciada a descrio dos mtodos faz-se necessria uma explanao sobre a escolha dos mtodos.
25
7.1 Escolha dos mtodos

Inicialmente foram selecionados os mtodos orientados a objetos mais divulgados e citados em monografias e trabalhos comparativos, como exemplo: [SIL96], [AND95], [BRI95] e [MAR], e que so listados na 1 coluna da tabela 1. Na 1 linha da tabela 1, temos as caractersticas: i) cobertura do mtodo, identificar quais fases do ciclo de desenvolvimento (anlise de requisitos, anlise, projeto, implementao, teste e manuteno) que cada mtodo abordava; pois seria de interesse para o estudo os que abordassem mais fases; como no possvel estudar todos os mtodos, seria escolhido os que cobrissem principalmente anlise e projeto; ii) ferramenta CASE genrica, seis ferramentas CASE mais divulgadas, foram analisadas no sentido de qual mtodo ela fornecia suporte; isto significa que o mtodo bem divulgado e aceito como eficiente. As ferramentas CASE se encontram na tabela 2; iii) foi verificado se o mtodo faz parte de algum mtodo integrador, assim verifica-se que o mtodo aceito por outro metodologista, confirmando sua eficincia. Os mtodos integradores observados se encontram na tabela 3. Para cada uma das caractersticas foram dado pontos da seguinte maneira: 1. cobertura do mtodo: 1 ponto para cada fase, (Rq+ , 0,5); 2. ferramenta CASE genrica: 1 ponto para cada ferramenta que abordasse o mtodo; 3. parte de mtodos integradores: 1 ponto para cada mtodo integrador que o mtodo faz parte. Com o total apresentado na ltima coluna da tabela 1, pode-se perceber que os mtodos mais pontuados so: Object Modelling Technique - James Rumbaugh et. al. Object Oriented Analysis and Design - Grady Booch Object-Oriented Analysis - Object-Oriented Design - Peter Coad & Edward Yourdon Object Oriented Software Engineering - Ivar Jacobson et. al. Fusion - Derek Coleman et.al. E o mtodo Fusion, que de 2 gerao tambm foi escolhido, por ser um mtodo j divulgado e bem estabelecido, diferentemente ao mtodo UM (Unified Method - Jacobson, Rumbaugh e Booch), que ainda se encontra em fase de estabelecimento.
26
_________________________________________________________________________________________________________________________________________________
Tabela 1 - Maturidade dos mtodos bsicos orientados a objetos

Cobertura do mtodo integradores Rq. P. I. T. M. 5 Ferramenta genrica Parte de mtodos Total
Mtodo
Autor(es)
Designing Object Oriented Software
R. Wirfs-Brock et.al. A. P. I. 3
Entity Relationship Object Oriented Specification
Research Group A. P. I. 3
Methodology for Object-Oriented Software Engineering of Systems
B. Henderson-Sellers & J. M. Edwards Rq+. A. P. I. 1-2-3-4-5-6 4 13,5
Object Modelling Technique
J. Rumbaugh et. al. Ri. Rq. A. P. I. M. 1-2-3 3 12
Object Oriented Analysis and Design
G. Booch A. P. 2
Object Oriented Analysis and Design
J. Martin & J. Odell Rq+. A. P. I. 1-3-5-6 7,5
Object-Oriented Analysis - Object-Oriented Design
P. Coad & E. Yourdon A. P. I. 1 4
Object Oriented Information Engineering
J. Martin & J. Odell A. 1-3-4 4
Object Oriented System Analysis
S. Shlaer & S. Mellor Rq+. A. P. I. 3,5
Object-Oriented System Development
D. Champeaux et. al. Rq. A. P. I. T. 1-3-6 2 10
Object Oriented Software Engineering
I. Jacobson et. al.
27
A tabela 2, como j foi dito, apresenta as seis ferramentas CASE mais amplamente divulgadas: em revistas e Internet. Na primeira coluna desta tabela temos o nome das ferramentas CASE, na segunda coluna se encontram os fabricantes de cada uma das ferramentas, seguido pelo endereo da Internet, onde podem ser encontradas informaes sobre a ferramenta.
Tabela 2 - Ferramentas CASE que suportam mtodos orientados a objetos Ferramenta CASE Paradigm Plus Rational Rose System Architect ObjectTeam Together Select Perspective Nome do fabricante Platinum Technology Rational Software Corporation Popkin Software & Systems, Inc. Cayenne Software, Inc. Object International, Inc. SELECT Software Tools Endereo Internet http://www.platinum.com http://www.rational.com http://www.popkin.com http://www.cayennesoft.com http://www.oi.com http://www.pmp.co.uk
A tabela 3 apresenta os mtodos integradores, com foi dito anteriormente. A primeira coluna desta tabela mostra o nome do mtodo integrador e seu(s) autor(es); e na segunda coluna, os mtodos utilizados para compor o mtodo integrador. Por exemplo: O mtodo FUSION aborda os mtodos OMT, OOD, mtodos formais e a tcnica CRC.
Tabela 3 - Mtodos integradores Mtodo integrador Autor(es) Catalysis D. D'Souza & A. Wills Fusion D. Coleman et.al. Syntropy Syntropy User Group Unified Method I. Jacobson - J. Rumbaugh - G. Booch OMT (Rumbaugh) / Objectory (Jacobson) Fusion (Coleman) OMT (Rumbaugh) / OOD (Booch) Tcnica CRC (Wirfs-Brock) / Mtodos Formais OMT (Rumbaugh) / OOAD (Booch) OMT (Rumbaugh) / OOAD (Booch) Objectory (Jacobson) Mtodos utilizados
28
7.2 Mtodo OOSE

O mtodo OOSE (Object-Oriented Software Engineering) uma verso simplificada do mtodo orientado a objetos Objectory (The Object Factory for Software Development), e foi desenvolvido por Ivar Jacobson e outros, sendo apresentado em [JAC92]. Segundo [JAC92], a complexidade de um sistema deve ser manuseada de uma forma organizada. Isto feito quando se trabalha com diferentes modelos, cada um focalizando um certo aspecto do sistema. Introduzindo a complexidade gradualmente em uma ordem especfica nos modelos sucessivos, a complexidade do sistema ser gerenciada. Este mtodo derivado de trs tcnicas totalmente diferentes as quais tem sido usadas por um longo tempo. So elas: programao orientada a objetos, modelagem conceitual e projeto de bloco. Da programao orientada a objetos, foram pegos os conceitos de encapsulamento, herana e o relacionamento entre classes e instncias. O objetivo da modelagem conceitual criar modelos do sistema ou organizao a ser analisada. Dependendo do sistema e dos aspectos que se deseja modelar, modelos conceituais diferentes so criados. O projeto de bloco um mtodo que inicialmente era aplicado a projetos de hardware e, agora, tambm modela software, coletando programas e dados juntos em mdulos (blocos) e descrevendo suas comunicaes mtuas atravs de interfaces. Existem trs processos principais no mtodo OOSE, ilustrado na figura 14: (1) anlise, onde se cria uma figura conceitual do sistema que se deseja construir; (2) construo, onde se inclui a implementao e resultados em um sistema completo; e (3) teste, onde se integra o sistema, verifica-o e decide se ele deve ser passado para distribuio.
Anlise
Construo
Teste
Componentes
Figura 14 - Os processos do mtodo OOSE (JAC92)
29
Alm desses existe o processo de desenvolvimento de componentes, o qual comunica principalmente com o processo de construo. Este processo desenvolve e mantm componentes para serem usados durante a construo. Um componente uma abstrao implementada que geral e de alta qualidade; ela desenvolvida e empacotada com o objetivo de reuso. Os componentes so cdigos implementados, os quais podem ser usados em aplicaes diferentes. Um componente pode ser uma white-box10 ou uma black-box11. O processo da anlise produz dois modelos, ilustrado na figura 15, o modelo de requisitos e o modelo de anlise.
Anlise
Requisitos
Modelo de requisitos
Figura 15 - A fase de anlise do mtodo OOSE (JAC92)
A partir dos requisitos do sistema, um modelo de requisitos criado, onde especificado toda funcionalidade do sistema e definidas as limitaes do sistema. Para tanto so desenvolvidos os seguintes modelos: (1) uma ilustrao conceitual do sistema, usando os objetos do domnio do problema; (2) a descrio da interface do sistema, se for significativo para o sistema; e (3) um modelo use case, que captura a funcionalidade do sistema. O modelo use case tambm formar a base dos processos de construo e teste, e ele controla uma grande parte do desenvolvimento do sistema. O modelo de anlise a base da estrutura do sistema. Neste modelo, so especificados todos os objetos lgicos a serem includos no sistema e como estes esto relacionados e agrupados. Seu objetivo estruturar o sistema independentemente do ambiente de implementao atual. A estrutura definida estvel, robusta, manutenvel e extensvel. Na anlise capturamos: (1) a informao contida no sistema; (2) o procedimento que o sistema
10
White-box (caixa branca) - significa que o componente pode ser modificado para reus-lo. Um tipo especial uma estrutura, a qual um esqueleto maior de um projeto que reusvel [JAC92]. 11 Black-box (caixa preta) - significa que no podem ser feitas mudanas dentro do componente [JAC92].
3 2 10 %$ )
Modelo de anlise
$'% (& $ # " !
30
adotar; e (3) a representao que prov os detalhes que representam o sistema para o mundo de fora. O processo de construo (ilustrado na figura 16), projeta e implementa o sistema. A fase de construo necessita como entrada, do modelo de requisitos e do modelo de anlise. Primeiro, um projeto feito resultando em um modelo do projeto, onde cada objeto ser totalmente especificado. O subprocesso implementao implementar estes objetos e resultar no modelo de implementao, o qual consiste de cdigo fonte.
Construo
2 0 11) &$!" ( '% #
Modelo de implementao Modelo de requisitos Modelo de anlise
Figura 16 - A fase de construo do mtodo OOSE (JAC92)
Atravs do subprocesso projeto, criado o modelo de projeto que um refinamento e formalizao do modelo de anlise12. O primeiro trabalho adaptar o ambiente de implementao atual. O modelo de anlise foi desenvolvido assumindo condies ideais, agora deve-se adapt-lo a realidade. O modelo de implementao consiste do cdigo fonte comentado, gerado a partir do subprocesso implementao. A tcnica pode ser usada com qualquer linguagem de programao, entretanto, uma linguagem de programao orientada a objetos desejvel, j que todos os conceitos fundamentais podem ser facilmente traados. O processo de teste necessita do modelo de requisitos, do modelo de projeto e do modelo de implementao, gerando o modelo de teste. Este processo ilustrado na figura 17. Este mtodo, no processo de teste, se preocupa com a verificao, pois segundo [JAC92], a validao capturada atravs da anlise de requisitos, interaes com o cliente e uso de prottipos.
12
A transio do modelo de anlise para o modelo de projeto deve ser feito quando as conseqncias do ambiente de implementao comearem a aparecer [JAC92].

Modelo de projeto
31
O processo de teste pode ser iniciado junto com a anlise e no necessariamente depois da anlise e construo; quanto mais cedo for iniciado, menores sero os custos de correo. O teste de unidade, o de mais baixo nvel e normalmente feito pelo prprio desenvolvedor, principalmente devido aos custos. Este , freqentemente, um teste de procedures e subrotinas. Este subprocesso consiste em teste de estrutura, teste de especificao e teste baseado em estado [JAC92].
Teste
5 4 3 12)0%# " ( ' &$ !
Modelo de requisitos Modelo de projeto Modelo de implementao
Modelo de teste
Figura 17 - A fase de teste do mtodo OOSE (JAC92)
O subprocesso teste de integrao testar se diferentes unidades esto trabalhando juntas com sucesso. Neste processo includo o teste de blocos, pacotes de servio, use cases, subsistemas e o sistema todo. Iro existir diversos testes de integrao durante o desenvolvimento em diferentes nveis. No subprocesso teste do sistema, cada use case testado separadamente a partir de uma viso externa; este baseado no modelo de requisitos. Em seguida, o sistema testado como um todo.
7.2.1 Consideraes finais sobre o mtodo OOSE

Este o mtodo mais completo, dentre os aqui apresentados, cobrindo todas as fases do processo de desenvolvimento, mas seu enfoque maior na fase de anlise de requisitos. Apresenta caractersticas favorveis a sistemas que necessitem da participao de usurios e especialistas do domnio no detalhamento dos requisitos, devido a utilizao de use cases, atores e diagramas de interao.
FGB A9 E DC @ 5 8 &$ 7 & 6

32
Os use cases conduzem todo o desenvolvimento do sistema, o que permite uma coerncia entre os modelos gerados nas diversas fases, pois todos estaro centrados em refinar os use cases. Os outros mtodos no tm esta abordagem, tentam identificar todos os objetos, suas relaes e posteriormente fazer algum tipo de modularizao. O mtodo introduz no modelo de anlise objetos extra-domnio (objetos de controle e objetos de interface). A utilizao destes tipos de objetos defendida pelos autores, como sendo uma maneira de facilitar futuras evolues e manutenes no sistema, pois estas ficariam mais localizadas, afetando apenas os objetos com maior chance de modificaes (interface e controle). A tcnica de anlise de OOSE a evolutiva orientado a dados, que utiliza extenses semnticas de modelos de dados [REI94]. A notao que o mtodo utiliza bastante diferente de todos os outros mtodos aqui apresentados, os quais tm algumas caractersticas comuns entre si. Por exemplo, a representao dos atributos externa a representao do objeto, o que dificulta a compreenso dos diagramas para os iniciantes. O mtodo pode ser utilizado no desenvolvimento de sistemas reais de grande porte. indicado para ser usado por equipes de desenvolvimento e no por um nico desenvolvedor; sendo que as esquipes devem ter treinamento em anlise, projeto e programao.
7.3 Mtodo OMT

Do ingls Object Modeling Technique; tambm conhecido como TMO, Tcnica de Modelagem de Objetos, OMT um mtodo orientado a objetos desenvolvido por James Rumbaugh e outros, sendo apresentado em [RUM94]. A essncia do desenvolvimento orientado a objeto no OMT a identificao e organizao de conceitos do domnio da aplicao ao invs de conceitos do domnio da implementao. A figura 18 apresenta uma viso geral a respeito do processo de desenvolvimento de software do mtodo OMT. O mtodo OMT consiste de 3 fases: anlise, projeto e implementao. Na fase de anlise encontram-se trs modelos: (i) o modelo de objetos, que representa os aspectos estticos e estruturais de dados de um sistema; (ii) o modelo dinmico, que representa os aspectos temporais e comportamentais de controle de um sistema; e (iii) o modelo funcional, que representa os aspectos relativos s transformaes de funes de um sistema. 33
Anlise
Modelo de Objetos Modelo Dinmico Modelo Funcional
Projeto
Projeto do Sistema Projeto de Objetos
Implementao
Figura 18 - Mtodo OMT (COL96)
i) Modelo de Objetos: descreve a estrutura de objetos de um sistema - sua identidade, seus relacionamentos com outros objetos, seus atributos e suas operaes. A meta incorporar os conceitos do mundo real que sejam importantes para a aplicao. O modelo de objetos representado graficamente por diagramas de objetos13 contendo classes de objetos, e descrito por um dicionrio de dados. ii) Modelo Dinmico: descreve os aspectos de um sistema relacionados ao tempo e seqncia de operaes. Ele incorpora o controle, que um aspecto de um sistema que descreve as seqncias de operaes que ocorrem, independentemente do que as operaes fazem, sobre o que elas atuam ou como so implementadas. O modelo descrito por diagramas de estados e diagramas de fluxo de eventos. [RUM94] sugere a criao dos cenrios e, baseando-se nestes, feita a construo de diagrama de eventos. O diagrama de estados relaciona eventos e estados. Ele especifica a seqncia de estados causados por uma seqncia de eventos para um objeto especfico.
34
iii) Modelo Funcional: descreve os aspectos de um sistema relacionados a transformaes de valores: funes, mapeamentos, restries e dependncias funcionais. O modelo abrange o que um sistema faz, independentemente de como ou quando feito. O modelo funcional especifica o significado das operaes do modelo de objetos e as aes do modelo dinmico, bem como quaisquer restries no modelo de objetos. Ele representado por mltiplos diagramas de fluxo de dados, que especificam o significado das operaes e restries. Na figura 18, ilustrada anteriormente, a seta que sai do modelo funcional e retorna ao modelo de objetos indicando que h uma interao para verificar e refinar os modelos. Na fase de projeto encontram-se dois tipos de projetos: (i) o projeto de sistema; e (ii) o projeto de objetos. i) Projeto de Sistema: deve-se tomar as seguintes decises: organizar o sistema em subsistemas, identificar concorrncias inerentes ao problema; alocar subsistemas aos processadores e tarefas; escolher uma abordagem para o gerenciamento de depsitos de dados (depsito de dados internos ou externo ou o uso de um SGBD - Sistema Gerenciador de Banco de Dados); cuidar dos acessos aos recursos globais14; escolher a implementao de controle em software (controle externo ou interno); tratar das condies limites (inicializao, trmino e falhas) e ajustar o equilbrio das prioridades (uso de mais memria ou da prototipao). ii) Projeto de Objetos: deve-se executar as seguintes etapas: combinar os trs modelos da anlise para obter as operaes sobre classes; projetar algoritmos para implementar operaes; otimizar caminhos de acesso aos dados; implementar controle para interaes externas (implementar o modelo dinmico); ajustar a estrutura de classes para aumentar a herana; projetar associaes (implementar todas as associaes de maneira uniforme ou selecionar uma tcnica especial para cada associao); determinar a representao de objetos (tipos primitivos ou combinar grupos de objetos relacionados) e empacotar classes e associaes em mdulos. A fase de implementao: as classes de objetos e os relacionamentos desenvolvidos durante o projeto de objetos so por fim traduzidos para uma determinada implementao em
13
Existem dois tipos de diagramas de objetos: 1) diagrama de classes, que descreve muitas instncias possveis de dados e tambm classes de objetos; e 2) diagrama de instncias, que descrevem como os objetos de um determinado conjunto se relacionam entre si [RUM94]. 14 Recursos globais incluem: unidades fsicas, espao, nomes lgicos e acesso a dados compartilhados [RUM94].
35
uma linguagem de programao, em um banco de dados ou em hardware. A programao deve ser uma parte mecnica e relativamente de menor importncia do ciclo de desenvolvimento, porque todas as decises difceis devem ser tomadas durante o projeto.
7.3.1 Consideraes finais sobre o mtodo OMT

Neste mtodo os conceitos de orientao a objetos so bem explicados e exemplificados. Na fase de anlise, o diferencial em comparao com outros mtodos est na representao das relaes entre classes e objetos, com caractersticas no encontradas em outros mtodos, como: relaes ternrias, atributos de ligao e qualificador de ligao. Sua notao para os modelos de anlise a mais clara dentre as aqui apresentadas, facilitando a visualizao das estruturas. A fase de anlise do OMT leva a identificao de objetos do domnio como os principais objetos do sistema. Esta abordagem diferente da adotada por alguns mtodos (como OOSE), que defendem a utilizao de objetos extra-domnio nesta fase com o objetivo de gerar uma arquitetura mais fcil de evoluir. OMT defende a utilizao de objetos do domnio por serem mais facilmente compreendidos pelos especialistas no domnio, os quais no so especialistas em modelagem de sistemas. A tcnica de anlise do OMT a integracionista, que representa aquelas tcnicas que integram modelos separados das diferentes dimenses (no caso deste mtodo as dimenses so: esttica, dinmica e funcional), no necessariamente de todas estas trs (anteriormente citadas) [REI94]. A fase de analise bastante prescritiva, facilitando o desenvolvimento das atividades. A fase de projeto no apresenta o mesmo detalhamento e riqueza semntica das representaes utilizadas na anlise, dando apenas sugestes genricas de como evoluir os modelos de anlise para os de projeto. Para o detalhamento das operaes das classes, OMT utiliza os Diagramas de Fluxo de Dados (DFDs). Os DFDs so interessantes quando tivermos um fluxo de dados sofrendo transformaes ao longo das operaes, mas no so interessantes para representar fluxo de controle, que melhor representado por fluxogramas como em OOA (Coad/Yourdon). O mtodo uma boa opo para analistas experientes em modelagem com mtodos estruturados de anlise (sem muita experincia em programao) pois o seu enfoque na abstrao no domnio do problema e no na implementao. Facilita o trabalho dos analistas com vrias opes de representao das associaes entre objetos. 36
O mtodo no uma boa opo para programadores que estejam aprendendo a modelar, pois o seu enfoque no direcionado a linguagens de implementao, mas sim a abstraes de alto nvel. Os programadores tendem a querer mapear as representaes de anlise para algo no domnio de implementao, mas os modelos de anlise no tm este objetivo, gerando alguma confuso nos primeiros projetos. Em resumo um mtodo com um forte enfoque conceitual, uma fase de anlise bastante clara, mas incompleto na fase de projeto. Pode ser utilizado no desenvolvimento de sistemas reais por desenvolvedores experientes (que sabero conduzir a fase de projeto sem as prescries que o mtodo no fornece) ou com o complemento de outros mtodos que sejam mais abrangentes na fase de projeto com OOAD (Booch) ou OOSE (Jacobson).
7.4 Mtodo OOAD

O mtodo OOAD - Object-Oriented Analysis and Design - Anlise e Projeto Orientado a Objeto, um mtodo orientado a objetos desenvolvido por Grady Booch. O mtodo foi inicialmente criado somente com a fase de projeto, o OOD (Object-Oriented Design), sendo apresentado em [BOO91]. Em [BOO94], Booch incorpora ao seu mtodo a fase de anlise, o OOAD. O mtodo OOAD dividido em (i) macro processo e (ii) micro processo, que sero descritos logo a seguir.
Use o macro processo para controlar as atividades do projeto como um todo, e use o micro processo para interativamente executar estas atividades e regular a futura conduta do macro processo. Booch
i) Macro processo
O macro processo serve como uma estrutura de controle para o micro processo. A principal preocupao do macro processo o gerenciamento tcnico da equipe de desenvolvimento. Como ilustrado na figura 19, o macro processo apresenta as seguintes atividades: (1) conceitualizao; (2) anlise; (3) projeto; (4) evoluo; e (5) manuteno, que sero descritas a seguir.
37
Anlise Conceitualizao Projeto
Evoluo Manuteno
Figura 19 - Macro processo do mtodo OOAD (BOO94)
1) Conceitualizao O propsito da conceitualizao estabelecer o ncleo dos requisitos para o sistema. Para uma nova parte do sistema ou para adaptao de um sistema existente. Nem todos os projetos requerem esta fase. Durante esta fase, trs produtos so gerados. Em ordem de importncia: (1) um prottipo executvel; (2) uma avaliao dos riscos; e (3) uma viso geral dos requisitos do projeto.
Faa a conceitualizao somente quando os riscos do projeto forem relativamente altos ou quando necessrio inventar um vnculo inicial entre o cliente e a organizao de desenvolvimento; seno, passe diretamente para a anlise. Booch
2) Anlise O propsito da anlise desenvolver um modelo do comportamento do sistema. Este modelo identifica classes e objetos (suas regras, responsabilidades e colaboraes) que formam o vocabulrio do domnio do problema. Durante a anlise, quatro produtos so gerados, todos com importncia quase igual: (1) uma descrio do contexto do sistema, que estabelece os limites do projeto e faz uma distino entre os elementos que esto de dentro e de fora do sistema; (2) uma coleo de cenrios que definem o comportamento do sistema;
38
(3) um modelo do domnio, o propsito visualizar todas as classes centrais responsveis pelo comportamento essencial do sistema; (4) uma reviso da avaliao dos riscos, o produto final da anlise uma avaliao dos riscos que identifica a rea de conhecimento dos riscos tcnicos e no-tcnicos que podem ter impacto no projeto. Se existir a fase de conceitualizao, ento esta avaliao dos riscos justamente uma evoluo daquele, adicionando o que foi aprendido na anlise.
3) Projeto O propsito do projeto criar uma arquitetura para desenvolver a implementao. O projeto arquitetural s pode comear quando a equipe de desenvolvimento tem um entendimento razovel dos requisitos do sistema. O projeto focaliza a estrutura, tanto esttica como dinmica. Anlise mais aprofundada pode ocorrer durante a fase do projeto, principalmente para explorar reas de incerteza a respeito do comportamento desejado do sistema, mas o projeto principalmente serve para criar o esqueleto concreto sobre o qual todo o resto da implementao se projeta. Durante o projeto, so gerados cinco produtos: (1) um executvel e uma arquitetura de linha bsica15; (2) a especificao de todos modelos arquiteturais importantes; (3) um planejamento do release16; (4) critrios de teste; e (5) uma reviso da avaliao de riscos.
Os dois primeiros estabelecem a estrutura do sistema e os outros trs suportam o processo de desenvolvimento baseado em risco para desenvolver a estrutura. Uma arquitetura executvel17 o mais importante produto desta fase de desenvolvimento.
15
Do ingls baseline, linha bsica um software/hardware que foi formalmente revisado e combinado, o qual serve como a base para novo desenvolvimento, e que pode ser mudado somente atravs de procedimentos de controle de mudana formal. um documento ou conjunto de documentos de identificao da configurao software/hardware formalmente revisados e combinados no tempo especfico durante o ciclo de vida do sistema (software), o qual descreve completamente as caractersticas fsicas e/ou funcionais de um item de configurao de hardware/software [THA88]. 16 Um release simplesmente uma verso executvel, completa e estvel de um sistema, junto com quaisquer outros elementos perifricos necessrios para us-lo. Os produtos da evoluo guiam a equipe de desenvolvimento atravs da concluso de uma soluo que satisfaa os requisitos reais do cliente. Um release consiste de um pacote cheio, incluindo software executvel, documentao e resultados de teste [BOO96]. 17 Uma arquitetura executvel existe como aplicao real que executa de maneira limitada; a produo de um cdigo de qualidade; leva alguns ou todos os procedimentos de um pouco de cenrios interessantes escolhidos a partir da fase de anlise [BOO96].
39
4) Evoluo O propsito da evoluo produzir uma implementao atravs de sucessivos refinamentos da arquitetura do sistema. O fim desta fase disponibilizar o sistema, isto envolve uma completa produo do sistema, seu software (executvel), mecanismos de instalao, documentao e facilidades de suporte. A evoluo de um sistema produz quatro produtos distintos: (1) uma torrente de releases executveis; (2) prottipos comportamentais; (3) resultados com garantia de qualidade; e (4) documentao do usurio e do sistema.
5) Manuteno O propsito da manuteno gerenciar o sistema gerado pela evoluo. Esta fase largamente a continuao da anterior. De fato, mudanas mais localizadas so feitas ao sistema como adicionar alguns requisitos novos e aniquilar erros protelados. Desde que a manuteno est no sentido de continuar a evoluo do sistema, seus produtos so idnticos aqueles da fase anterior, com uma adio: uma lista (punch list) de novas tarefas. Esta lista serve como veculo para coletar erros e aumentar requisitos, tanto que eles podem ser priorizados para manuteno futura de releases.
ii) Micro processo
O micro processo a descrio das atividades dirias de um nico ou pequeno grupo de desenvolvedores de software. O micro processo pode, a partir de um observador externo, parecer obscurecido porque as fases de anlise e projeto no so claramente definidas. A figura 20 ilustra o micro processo do mtodo OOAD, o qual contm quatro atividades: (1) identificao de classes e objetos; (2) identificao da semntica das classes e objetos; (3) identificao dos relacionamentos entre classes e objetos; e (4) implementao de classes e objetos; que sero explicadas logo a seguir.
40
Identificao de classes e objetos
Implementao de classes e objetos
Identificao da semntica das classes e objetos
Identificao dos relacionamentos entre classes e objetos
Figura 20 - Micro processo do mtodo OOAD (BOO94)
1) Identificao de classes e objetos O propsito desta fase estabelecer os limites do problema. Esta uma fase de descobrimento. Durante a anlise, este passo aplicado para descobrir as abstraes que formam o vocabulrio do domnio do problema, assim, a equipe de desenvolvimento comea a restringir o problema, decidindo o que e o que no de interesse. Durante o projeto, este passo serve para descobrir abstraes que so elementos da soluo. Durante a evoluo, esta fase identifica as abstraes de mais baixo nvel que constrem as de mais alto nvel e pela identificao de elementos comuns entre as abstraes existentes para simplificar a arquitetura do sistema. Durante esta atividade, existe um nico produto, o dicionrio de dados, que serve como um repositrio central para as abstraes relevantes do problema.
2) Identificao da semntica das classes e objetos O propsito estabelecer os procedimentos e atributos de cada abstrao identificadas anteriormente e fazer a distribuio adequada, refinando as abstraes candidatas. Durante anlise, esta atividade aplicada para alocar as responsabilidades a diferentes procedimentos do sistema. Durante o projeto, este passo serve para estabelecer uma separao clara de assuntos entre as partes da soluo. Durante a evoluo, esta fase visa gradualmente e conscientemente refinar estas semnticas, transformando-as a partir de descries de forma livre em protocolos concretos para cada abstrao.
41
3) Identificao dos relacionamentos entre classes e objetos O propsito desta atividade solidificar os limites das abstraes e reconhecer os colaboradores de cada abstrao j identificada nas fases anteriores. Durante a anlise, este passo primariamente especifica associaes entre classes e objetos (incluindo certos relacionamentos importantes de herana e agregao). Entre outras coisas, estas associaes especificam alguma dependncia semntica entre duas abstraes e alguma habilidade de navegar de uma entidade para outra. Durante o projeto, serve para especificar as colaboraes que formam os mecanismos de nossa arquitetura e agrupar as classes de mais alto nvel em categorias e mdulos dentro de subsistemas. Durante a evoluo, esta fase continua a adicionar detalhes a arquitetura do sistema, com o refinamento dos relacionamentos.
4) Implementao de classes e objetos O propsito desta fase representar cada abstrao e mecanismos concretamente de maneira mais eficiente e elegante. Durante anlise, o projeto bem sucedido proceder com uma modesta implementao, primariamente como um recurso para afastar o risco e como um veculo para revelar novas classes e objetos para serem refinados na prxima interao. Durante o projeto, esta fase serve para criar produtos tangveis e executveis pelos quais a arquitetura do sistema toma forma. Durante a evoluo, a atividade nesta fase do micro processo acelera, tendo um sucessivo refinamento da arquitetura. A atividade associada a este passo a seleo das estruturas e algoritmos que completam as regras e responsabilidades de todas as vrias abstraes identificadas mais cedo no micro processo. Enquanto que as primeiras trs fases do micro processo focalizam a viso externa das abstraes, este passo focaliza a viso interna. Tipicamente, a anlise incluir conjuntos de diagramas de objetos, diagramas de classe e diagramas de transio de estado. O projeto (incluindo arquitetura e implementao) incluir conjuntos de diagramas de classes, diagramas de objetos, diagramas de mdulos e diagramas de processo, to bem como sua viso dinmica correspondente, diagrama de interao. Apresenta-se uma breve descrio dos diagramas citados anteriormente: i) Diagrama de classes - usado para mostrar existncia de classes e seus relacionamentos no projeto lgico de um sistema. Um simples diagrama de classes representa uma viso da estrutura de classe de um sistema;
42
ii) Diagrama de objetos - usado para mostrar existncia de objetos e seus relacionamentos no projeto lgico de um sistema. Um simples diagrama de objetos tipicamente usado para representar um cenrio; iii) Diagrama de interao - usado para traar a execuo de um cenrio no mesmo contexto de um diagrama de objeto; iv) Diagrama de transio de estado - usado para mostrar o estado de uma instncia de uma dada classe, os eventos que causam a transio de um estado para outro e as aes que resultam da mudana de estado; v) Diagrama de mdulo - usado para mostrar a alocao de classes e objetos em mdulos no projeto fsico de um sistema. Um simples diagrama de mdulo representa uma viso da arquitetura de mdulos de um sistema; vi) Diagrama de processo - usado para mostrar alocao de processos a processadores no projeto fsico de um sistema. Um simples diagrama de processo representa uma viso da arquitetura de processo de um sistema.
7.4.1 Consideraes finais sobre o mtodo OOAD

O mtodo utiliza o macro processo para controlar as atividades do desenvolvimento, e o micro processo, para executar estas atividades. A tcnica de anlise do OOAD a reversa, que originada da necessidade de implementao, como, por exemplo, o suporte a conceitos de linguagens de programao orientadas a objetos especficas; no caso deste mtodo, se originou da linguagem ADA [REI94]. A parte conceitual sobre classes e objetos bastante didtica, expondo de maneira precisa vrios conceitos relacionados a objetos. No um mtodo prescritivo, como o OOA-OOD (Coad/Yourdon) e o OMT (Rumbaugh), sendo portanto difcil a sua aplicao por equipes inexperientes. um mtodo bom para equipes de programadores experientes (em linguagens O.O.) que julguem no ser necessria a elaborao de modelos de requisitos e anlise e visualizam o projeto de uma forma interativa com a implementao (documentar a implementao). No um bom mtodo quando se deseja gerar modelos de requisitos e anlise. Em OOAD, Booch sugere a utilizao de conceitos de outros mtodos (OOSE e OMT) na sua fase de anlise, tornando bastante confusa a notao e os conceitos que devem ser utilizados.
43
7.5 Mtodo OOA-OOD

OOA-OOD um mtodo orientado a objetos desenvolvido por Peter Coad e Edward Yourdon que trata as fases de anlise, projeto e programao. O mtodo apresentado em [COA91], cobrindo a parte de anlise e em [COA93], cobrindo a parte de projeto e programao. A anlise (OOA) identifica e define classe&objetos18 que refletem diretamente o domnio do problema e as responsabilidades do sistema dentro dele. O projeto (OOD) identifica e define classe&objetos adicionais, refletindo a implementao dos requisitos (nvel de dilogo, nvel de administrao de tarefas, nvel de administrao de dados). A fase de anlise composta por cinco atividades: (1) encontrar classe&objetos; (2) identificar estruturas; (3) identificar assuntos19; (4) definir atributos; e (5) definir servios. Estas atividades no so passos seqenciais, ficando a critrio do analista a ordem a ser seguida, alm disso, h uma interatividade entre elas. 1) Encontrar classe&objetos - para que isso ocorra de maneira bem sucedida, [COA91] sugere: (1) observar o domnio da aplicao; (2) ouvir os especialistas do domnio da aplicao; (3) checar resultados de anlise feitas anteriormente para domnio de aplicao similar, verificando a possibilidade de reuso; (4) checar outros sistemas do mesmo domnio, verificando o que pode ser aprendido em relao a identificar classe&objetos; (5) assegurar-se dos requisitos existentes em um documento feito pelo cliente; e (6) utilizar a prototipao como meio de obter uma anlise efetiva. Nesta fase deve-se procurar por estruturas, outros sistemas, dispositivos, coisas ou eventos lembrados, identificar papis executados20, procedimentos operacionais, lugares e unidades organizacionais. 2) Identificar estruturas - esta atividade realizada criando-se dois tipos de estruturas: (1) a estrutura de generalizao, que captura a hierarquia de herana entre as classes identificadas; e (2) a estrutura de agregao, que modela as partes de um objeto e como os objetos so agrupados em categorias mais amplas. 3) Identificar assuntos - esta fase realizada para facilitar o entendimento do leitor atravs de um modelo amplo e complexo. feita transformando a classe mais superior de
18 19
Classe&objetos um termo significando uma classe e os objetos nessa classe [COA91]. Assuntos so grupos de classe&objetos. 20 Existem dois tipos de papis executados: (1) usurios do sistema; e (2) pessoas que no interagem diretamente como o sistema, mas de quem a informao mantida pelo sistema (proprietrio de um motor de veculo).
44
cada estrutura em um assunto. Uma classe&objetos pode ser encontrada em mais de um assunto se necessrio. 4) Definio de atributos - consiste em identificar os atributos; aplicar herana em estruturas de generalizao, posicionando-os nas classes apropriadas; identificar conexes de ocorrncias entre objetos; verificar casos especiais de atributos21 e de conexes22 e especificar os atributos (nome, descrio, especificaes). 5) Definio de servios - para definir os servios das classes, so realizados os seguintes passos: (1) identificar os estados de objeto, os valores para os atributos; (2) identificar os servios simples: criar, conectar, acessar e liberar, e complexos: calcular e monitorar; (3) identificar a comunicao entre objetos usando conexo de mensagens; (4) especificar os servios no modelo de classe&objetos usando um diagrama de servios para cada servio; e (5) reunir a documentao da anlise. A documentao da anlise rene: i) o modelo OOA, o qual consiste de cinco camadas: assunto, classe&objetos, estrutura, atributo e servio, sendo ilustrado na figura 21; ii) as especificaes de classe&objetos23, geradas na primeira atividade apresentada; iii) documentao suplementar, na medida do necessrio: tabelas de linhas crticas de execuo, especificaes adicionais do sistema e tabela de servios/estados.
Camada de Assunto Camada de Classe&Objeto Camada de Estrutura Camada de Atributo Camada de Servio
Figura 21 - O modelo OOA - um modelo multicamada (COA91)
Na fase de projeto criado um modelo geral de multicamadas e multicomponentes. O modelo OOD, exatamente como o modelo da OOA, consiste em cinco camadas que so cortes horizontais no modelo geral. O modelo tambm possue quatro componentes: Componente de Domnio de Problemas; Componente de Interao Humana; Componente de Gerenciamento
21 22
Casos especiais de atributos: valor no aplicvel, classe&objetos com apenas um atributo, valores de repetio. Casos especiais de conexes: conexo muitos-para-muitos, conexo entre objetos de uma classe nica, mltiplas conexes entre objetos. 23 As especificaes de classe&objetos esto definidas no modelo de especificao, o qual inclue o diagrama de estado do objeto e o diagrama de servio.
45
de Tarefas e Componente de Gerenciamento de Dados, que so cortes verticais no modelo geral. O modelo OOD ilustrado na figura 22.
Camada de Assunto Camada de Classe&Objeto Camada de Estrutura Camada de Atributo Camada de Servio
Componente de Domnio de Problemas
Componente de Interao Humana
Componente de Gerenciamento de Tarefas
Componente de Gerenciamento de Dados
Figura 22 - O modelo OOD - um modelo multicamadas e multicomponentes (COA93)
Componente de Domnio de Problemas (CDP) - os resultados da OOA se encaixam exatamente no CDP. Os resultados da anlise so uma parte essencial do modelo multicomponentes do OOD. Componente de Interao Humana (CIH) - a interao humana precisa de exame detalhado, tanto na anlise como no projeto. Na OOA, esse exame feito de modo que os atributos e os servios requeridos sejam especificados. No OOD, o CIH acrescenta a esses resultados o projeto da interao humana e os detalhes dessa interao. Esse componente capta como uma pessoa comandar o sistema e como o sistema apresentar as informaes ao usurio. Componente de Gerenciamento de Tarefas24 (CGT) - Para certas espcies de sistemas so necessrias mltiplas tarefas, por exemplo: (1) para certas interfaces humanas; (2) para sistema multiusurio; (3) para arquiteturas de software com muitos subsistemas; (4) para muitas tarefas em um nico processador; (5) para arquiteturas de hardware com multiprocessador; e (6) para um sistema responsvel pela comunicao com outro sistema. Componente de Gerenciamento de Dados (CGD) - Este componente fornece a infraestrutura para o armazenamento e a recuperao de objetos de um sistema de gerenciamento de dados. O componente isola o impacto do esquema de gerenciamento de dados, seja ele arquivo simples, relacional ou baseado em objetos. Os quatro componentes correspondem s quatro atividades principais do OOD: (1) projetar o CDP; (2) projetar o CIH; (3) projetar o CGT; e (4) projetar o CGD; essas atividades como as atividades da anlise no so passos seqenciais.
24
Tarefa outro nome para um processo (um fluxo de atividades, definido pelo seu cdigo). A execuo concorrente de uma srie de tarefas referenciada como multitarefa.
46
1) Projetar o CDP - a estratgia utilizada consiste em: (1) aplicar a OOA; (2) aperfeioar os resultados da OOA durante o OOD, devido a mudana dos requisitos ou devido a falta de compreenso por parte do analista ou dos especialistas em domnio de problemas disponveis; e (3) acrescentar algo aos resultados da OOA durante OOD, os critrios de adio so resumidos na figura 23.
Reutilizar as classes de projeto e programao. Agrupar as classes especficas do domnio do problema. Estabelecer um protocolo pela adio de uma classe de generalizao. Acomodar o nvel de herana suportado. Melhorar a peformance. Suportar o Componente Gerenciamento de Dados. Acrescentar componentes de nvel mais baixo. No modificar apenas para refletir atribuies de equipe. Revisar e reivindicar os acrscimos aos resultados da OOA.
Figura 23 - Critrios de adio ao CDP (COA93)
2) Projetar o CIH - a estratgia consiste em: (1) classificar as pessoas; (2) descrever as pessoas e seus cenrios de trabalhos; (3) projetar a hierarquia de comando25; (4) projetar a interao detalhada; (5) continuar no sentido da prototipao; (6) projetar as classes do CIH; e (7) projetar, levando em conta as Interfaces Grficas com o Usurio.
3) Projetar o CGT - a estratgia consiste em: (1) identificar tarefas dirigidas por eventos; (2) identificar tarefas dirigidas por tempo; (3) identificar tarefas prioritrias e tarefas crticas; (4) identificar um coordenador; (5) desafiar cada tarefa; e (6) definir cada tarefa. O ponto principal dessa estratgia identificar e projetar as tarefas (programas) e os servios includos em cada tarefa.
4) Projetar o CGD - o projeto deste componente precisa incluir: (1) o projeto do layout dos dados de arquivos simples, relacional ou baseado em objetos, e (2) o projeto dos servios correspondentes, acrescentando um atributo e servio a cada classe&objetos com objetos a serem armazenados.
Sobre a implementao, os autores sugerem o uso de linguagens de programao baseadas em objetos, pois estas so excelentes para suportar as construes da anlise e do projeto orientados a objetos. Porm, vrias organizaes utilizam-se de linguagens no
47
baseadas em objetos, que podem ser utilizadas, mas que devero vir combinadas com manuais, disciplina e perseverana, para poderem implementar adequadamente os resultados da anlise e do projeto. [COA93] tambm avalia as principais linguagens baseadas em objetos: C++, Object Pascal, Smalltalk, Objective-C, Eiffel; e no baseadas em objetos: Ada e C.
7.5.1 Consideraes finais sobre o mtodo OOA-OOD

o mtodo mais prescritivo dos mtodos aqui apresentados, indicando com detalhes todas as atividades que devem ser executadas e os seus subprodutos. O enfoque do mtodo tanto para a anlise quanto para o projeto. uma boa opo para equipes iniciantes em tecnologia de objetos pois sua notao simples e suficiente para boa parte dos projetos orientados a dados, com exceo da representao da cardinalidade, que se encontra do lado oposto, diferentemente do que representado pelos outros mtodos. um mtodo fraco na representao da dinmica do sistema, pois no possui cenrios nem diagramas de eventos como em OMT e OOSE. Durante a explanao do mtodo em [COA91] e [COA92], os autores sugerem o reuso, insistindo que o desenvolvedor faa uma busca em projeto anteriormente desenvolvidos.
7.6 Mtodo FUSION

O FUSION um mtodo orientado a objetos que incorpora partes bem-sucedidas de mtodos anteriores orientados a objetos (OMT, CRC26, Mtodos Formais27 e OOD), ilustrado na figura 24, procurando resolver seus pontos fracos. Foi desenvolvido por Derek Coleman e outros e sua completa descrio encontrada em [COL96].
25
Uma hierarquia de comando pode ser: uma srie de telas de menu, uma barra de menu ou uma srie de cones que executam aes quando algo colocado sobre eles. 26 CRC - Classe-Responsabilidade-Colaborador uma tcnica exploratria, e no um mtodo completo. Foi projetado, originalmente, como uma maneira para ensinar os conceitos bsicos de orientao a objetos [COL96]. 27 Os mtodos formais representam uma abordagem de engenharia de software baseada na aplicao de matemtica discreta (ou seja, teoria de conjuntos, lgica, etc.) programao de computadores. As linguagens de especificao, influenciadas por estes formalismos, permitem que as propriedades essenciais de um sistema sejam capturadas em um alto nvel de abstrao.
48
O mtodo possui trs fases: (1) anlise, que descobre os objetos e as classes existentes no sistema, descreve seus relacionamentos e define as operaes que podero ser executadas pelo sistema; (2) projeto, que decide como representar as operaes do sistema atravs de interaes entre objetos relacionados e como estes objetos obtero acessos entre si; e (3) implementao, que codifica o projeto em uma linguagem de programao.
OMT
CRC
modelo de objetos e processos

FUSION
interao de objetos
pr-condies e ps-condies
MTODOS FORMAIS
visibilidade
OOD
Figura 24 - Os componentes do mtodo FUSION (COL96)
Como ilustrado na figura 25, o mtodo no se preocupa com a obteno dos requisitos do sistema, estes requisitos sero informados pelo usurio em um documento informal escrito, possivelmente, em linguagem natural.
Anlise
~~~ ~~~ ~~~
Documento informal de requisitos Modelo de objetos Modelo de objetos do sistema Modelo de interface * modelo ciclo de vida * modelo de operao Dicionrio de dados
Projeto
Grafo de interao de objetos Grafo de visibilidade Descries de classe Grafo de herana Dicionrio de dados
Implementao
Codificao Desempenho Reviso
Figura 25 - As fases do mtodo FUSION 49
Durante a execuo das fases do FUSION, ser necessrio construir e utilizar um dicionrio de dados, que ser o repositrio central das definies de termos e conceitos. O dicionrio de dados representa uma ferramenta vital, devido a seu papel de nico local onde as definies podem ser encontradas, auxiliando o entendimento de pessoas que no estejam familiarizadas com o desenvolvimento em questo. So descritas a seguir, as fases do FUSION: anlise, projeto e implementao.
1) Anlise O objetivo da anlise capturar a maior quantidade possvel dos requisitos do sistema, de forma completa, consistente e sem ambigidades. As informaes que sero consideradas para anlise encontram-se em um documento de definio de requisitos, escrito em linguagem natural. Esta fase gera cinco modelos que capturam aspectos diferentes de um sistema: (1) modelo de objetos, que define os conceitos existentes no domnio do problema e os relacionamentos existentes entre eles, podendo representar classes, atributos e relacionamento entre classes e as extenses que permitem o uso de agregao e generalizao; (2) modelo de objetos do sistema, que representa um subconjunto de um modelo de objetos relacionado ao sistema a ser construdo. Ser formado com a excluso de todas as classes e relacionamentos pertencentes ao ambiente do sistema. Assim, um modelo de objetos do sistema possui um conjunto de classes e relacionamentos, possivelmente redundante, para a modelagem dos estados relativos ao sistema. Este modelo um refinamento do modelo de objetos desenvolvido na primeira etapa da anlise. Ele utiliza as informaes relativas interface do sistema para indicar quais classes e relacionamentos pertencem ao estado do sistema, em oposio quelas que pertencem ao ambiente. Um modelo de objetos do sistema um modelo que mostra a fronteira do sistema. (3) modelo de interfaces, que descreve o comportamento (entrada e sada) do sistema, sendo que a descrio ser feita em termos de eventos e mudanas de estado por eles causados. Um modelo de interfaces utiliza dois modelos28 para capturar aspectos diferentes do comportamento de um sistema: (3.1) modelo de operaes, que especifica o comportamento das operaes do sistema de forma declarativa, definindo seus efeitos em termos de mudanas de estado e eventos gerados. Ele define a semntica de cada operao do sistema que faz parte da
28
A ordem do desenvolvimento no fixa. Entretanto, ser mais apropriado iniciar pelo ciclo de vida, pois ele pode auxiliar no desenvolvimento dos esquemas para o modelo de operaes [COL96].
50
interface do sistema. Cada esquema contm uma especificao informal das pr-condies e ps-condies. (3.2) modelo de ciclo de vida, que descreve o comportamento visto de uma perspectiva mais ampla, mostrando como o sistema se comunica com seu ambiente desde o momento da sua criao at o seu trmino. Ele determina se uma operao do sistema ter que enviar eventos aos agentes.
2) Projeto Durante o projeto so incorporadas estruturas de software que satisfazem s definies abstratas produzidas durante a anlise. O resultado do projeto uma coleo de objetos que interagem entre si de modo a realizar o modelo de operaes. H um total de quatro modelos de projeto que so desenvolvidos durante esta fase: (1) grafos de interao de objetos, que constrem as estruturas que viabilizam as trocas de mensagens entre os objetos, realizando a definio abstrata do comportamento. Construi-se um grafo de interao de objetos para cada operao do sistema. (2) grafos de visibilidade, que decide como os caminhos de comunicao sero realizados no sistema. Seu objetivo o de definir as estruturas de referncia entre as classes existentes no sistema. H uma srie de decises de projeto que precisam ser tomadas quando consideramos a estrutura de referncias para as classes. As decises podem ser organizadas nas seguintes categorias: tempo de vida da referncia, visibilidade do servidor, vinculao do servidor e mutabilidade das referncias. (3) descries de classes, so coletadas informaes existentes no modelo de objetos do sistema, nos grafos de interao de objetos e nos grafos de visibilidade para criar as descries de classes, havendo uma descrio para cada classe. Aqui so estabelecidos para cada classe: as operaes, atributos de dados e atributos-objetos. As descries de classes fornecem os fundamentos para a implementao. (4) grafos de herana, o propsito desenvolver as estruturas de herana para o sistema. Os grafos de herana so construdos para todas as classes, com novas classes sendo introduzidas ao organizarmos a estrutura de classes em camadas abstratas. Finalmente, caso se tenha em mos uma estrutura estvel para o grafo de herana, o projetista pode atualizar as descries de classes para que reflitam as novas classes abstratas e as estruturas de herana.
3) Implementao Esta fase envolve o mapeamento do projeto em uma implementao efetiva. A base utilizada na fase de implementao composta pelas descries de classes, grafos de 51
interao de objetos e o dicionrio de dados, todos produzidos na fase de projeto, incluindo tambm o ciclo de vida gerado durante a fase de anlise. O processo de implementao pode ser dividido em trs partes, cada uma delas com prpria subestrutura: (1) codificao, esta parte da fase de implementao, traduz o resultado obtido no projeto em cdigo na linguagem de implementao, isto envolve quatro elementos: o ciclo de vida, as descries de classes, os corpos dos mtodos e o dicionrio de dados; (2) desempenho, utilizado quando um sistema consome recursos em demasia, deve-se proceder ao levantamento do seu perfil de desempenho, para descobrir onde o recurso consumido. Uma vez localizados os gargalos, sejam eles de espao, tempo ou qualquer outro recurso, o cdigo pode ser melhorado. (3) reviso, uma vez produzido o cdigo, ser preciso revis-lo. O objetivo das inspees29 e dos testes30 detectar erros, antes que sejam passados para o cdigo de produo. O cdigo deve ser inspecionado durante sua produo. Isso permite ao grupo de inspeo impor padres desde o incio da fase de implementao, assegurando que problemas de codificao no fiquem ocultos at que seja tarde demais.
7.6.1 Consideraes finais sobre o mtodo FUSION

O mtodo Fusion defende que no se deve definir comportamentos (dinmica) para os objetos na fase de anlise. Objetos de anlise tambm no possuem interfaces. Fusion no apresenta nenhum mecanismo para representao dos estados possveis dos objetos, o que nos outros mtodos possvel atravs das mquinas de estados. Em alguns tipos de aplicaes este tipo de representao faz falta, pois os estados de objetos individuais podem ser bastante significativos. Este mtodo no indicado para equipes iniciantes em orientao a objetos, pois um mtodo de ampla cobertura, se tornando um mtodo de aprendizado demorado. Tambm no um mtodo indicado para projetos de baixa complexidade, que podero fazer uso de mtodos mais simples. o mtodo ideal para desenvolvedores que j utilizaram na prtica mtodos mais simples, e desejam evoluir para um mtodo mais completo.
29 30
As inspees requerem que o cdigo possa ser lido por outras pessoas que no sejam seu prprio autor. Os testes verificam o comportamento real do sistema, ou apenas de parte dele, em relao s previses feitas com base nos requisitos e nas especificaes.
52
7.7 Comparao entre os conceitos

Nesta seo, feita a comparao entre os conceitos dos mtodos apresentados, pois cada um destes mtodos utilizam diferentes nomes para o mesmo conceito. Atravs da tabela 4, pode-se igualar os conceitos e obter uma melhor compreenso dos mtodos. Esta comparao ser baseada nos nomes referentes aos conceitos que foram apresentados na seo 6 deste trabalho. O conceito de objeto, no foi apresentado na tabela 4, devido ao fato de que todos os mtodos nomeiam este conceito igualmente.
Tabela 4 - Comparao entre os conceitos utilizados pelos mtodos Mtodos Conceitos Classe OMT Classe OOAD Classe OOSE Classe / Objeto Classe abstrata Classe concreta Operao Agregao Classe abstrata Classe concreta Operao Agregao Classe abstrata Classe concreta Operao Agregao Classe abstrata Classe concreta Operao Associao consiste de / agregao Atributo Herana Atributo Herana Campo Herana Atributo Herana Atributo Estrutura Gen-Espec Hierarquia Herana mltipla Mensagem Subsistema Herana mltipla Evento Mdulo Herana mltipla Mensagem Categ. Classe Herana mltipla Estmulo Subsistema
Estrutura Gen-Espec entrelaamento Classe&objetos
OOA-OOD Classe
FUSION Classe
Classe
Classe abstrata -
Servio Estrutura Todo-parte
Operao Agregao
Atributo Gen-Espec
Generalizao mltipla Mensagem -
Mensagem Assunto
Fonte: Baseado em [JAC92] - pp. 501
53
A partir da anlise da tabela 4, podemos observar que quase todos os autores utilizaram o mesmo nome para o mesmo conceito, porm alguns os diferenciaram, possuindo uma pequena divergncia. Exemplos so: 1) o que evento para OMT (mensagens entre objetos), para FUSION significa a comunicao do usurio com o sistema (o que acontece externamente e ao que o sistema tem que reagir); 2) um conceito no ilustrado na tabela 4, e muito utilizado pelo mtodo OOA-OOD, e somente por ele, o conceito classe&objetos, significando a classe e os objetos desta classe. Podemos concluir ainda, que o mtodo FUSION no menciona determinados conceitos: classe concreta e subsistema. Passamos agora a comparao entre os mtodos.
7.8 Comparao entre os mtodos

Assim como foi feito a comparao entre os conceitos, utilizados pelos mtodos para uma melhor compreenso destes, ser realizado uma comparao entre os vrios aspectos capturados pelos mtodos, tambm com a mesma finalidade, facilitar a compreenso. Esta comparao ilustrada na tabela 5 e tabela 6. Atravs da tabela 5 e da tabela 6, pode-se notar que em geral, os mtodos capturam aspectos semelhantes, como: estrutura esttica de objetos e classes, seus relacionamentos, troca de mensagens e a fase de implementao; mas que tambm possuem individualidades, aspectos que outros mtodos no capturam. Somente o mtodo OOSE, se preocupa com a fase de teste; os mtodos OMT e OOAOOD, possuem suporte grfico, importante para um desenvolvimento com maior rapidez. Podemos notar, tambm, atravs da tabela 5 e da tabela 6, que aspectos importantes para o desenvolvimento, como: identificao de requisitos, subdiviso do sistema, suporte grfico, estrutura de agregao e generalizao-especializao e teste do sistema, no so suportados por todos os mtodos. Alguns mtodos realizam a captura de aspectos no importantes para outros mtodos: viso lgica, aspectos funcionais, interface do sistema, apresentar multi-tarefa, conexo de ocorrncia e teste do sistema.
Legenda para a tabela: - D. E. O. - Diagrama de Estado do Objeto. - M. P. - Modelo de Projeto. - M. A. - Modelo de Anlise. - O. O. - Orientao a Objetos.
54
_______________________________________________________________________________________________________________________ Tabela 5 - Comparao entre os aspectos capturados pelos mtodos

MTODOS OOAD Atividade de conceitualizao Modelo de requisitos OOSE OOA-OOD FUSION Fase de anlise
Aspectos capturados
OMT
Identificao dos
Fase de anlise
requisitos Use case M. P. componente interao humana Diagrama de classes Modelo de anlise Descries de interface M. A. camada classe&objetos Modelo de objetos Use case M. A. camada servio Modelo de objetos do sistema
Interao do usurio c/ o
Diagrama de fluxo de dados
sistema
Ord.: diagrama de eventos
Interface do sistema
Formato de interface
Estrutura esttica de
Diagrama de classes
classes Diagrama de objetos Modelo de anlise M. A. camada classe&objetos Modelo de objetos
Estrutura esttica de
Diagrama de objetos
objetos Diagrama de classes Modelo de anlise M. A. camada classe&objetos Modelo de objetos
Relacionamentos entre
Diagrama de classes
classes Diagrama de objetos Modelo de anlise M. A. camada classe&objetos Modelo de objetos
Relacionamentos entre
Diagrama de instncias
objetos Diagrama de classes Diagrama de classes M. A. camada atributos M. A. camada servios Diagrama de servio Diagrama de objetos Ord.: diagrama de interao. Diagrama de classes Diagrama de classes Diagrama de interao e grafos de transio de estado Modelo de anlise M.A. envio: camada classe&objeto M. A. camada estrutura M. A. camada estrutura Grafos de herana Grafos de interao de objetos Descries das classes Descries das classes
Definio de atributos
Diagrama de objetos
Defin. atributos de dados
Definio das operaes
Diagrama de objetos
Troca de mensagens
Diagrama de fluxo de evento
Ord.: diagrama de eventos
Estrutura de agregao
Diagrama de objetos
Estrutura de
Diagrama de classes
generalizao Descries das classes
Documentao de
estrutura de herana
55
_______________________________________________________________________________________________________________________
Tabela 6 - Comparao entre os aspectos capturados pelos mtodos (Cont.)

MTODOS OOAD Modelo de objeto (estmulo inter-processo) Diagrama de transio de D. E. O. Tabela de servio / estado estado M. A. camada servios Diagrama de interao M. A. camada atributos Gerenciamento de tarefas Modelo ciclo-de-vida Modelo de operaes Diagrama de interao M. P. componente OOSE OOA-OOD FUSION Descries das classes -
Aspectos capturados
OMT
Descrio de classes
Dicionrio de estados
Apresentar concorrncia
Diagrama de estado
Conexo de ocorrncia
Sequncia de mensagens
Diagrama de eventos
Sequncia de estados
Diagrama de estados
Servios dependentes de
estados conhecimento Diagrama de mdulos e diagrama de processos Modelo de objeto do domnio do problema Diagrama de mdulos Subsistema (modelo de anlise) M. P. componente gerenciamento de tarefas Atividade de evoluo Modelo de implementao Recomenda-se o uso de linguagem O. O. Teste de unidade, de integrao e de sistema OOATool Codificao, desempenho, reviso M. A. camada de assunto Modelo use case M. A. associao de Grafos de visibilidade
Referenciao entre
objetos
Aspectos funcionais
Viso fsica
Projeto do sistema
Viso lgica
Subdiviso do sistema
Apresentar multi-tarefa
Implementao
Traduo do projeto em
determinada linguagem
Teste do sistema
Suporte grfico
OMTool
56
7.9 Cobertura dos mtodos

Os cinco mtodos orientados apresentados nesta seo, subitens 7.2, 7.3, 7.4, 7.5 e 7.6, cobrem diferentes fases do desenvolvimento. Por esta razo, foi criada a figura 26 onde so apresentadas as fases que cada mtodo cobre.
OMT
OOAD
OOSE
OOAOOD
FUSION
Anlise de Riscos Anlise de Requisitos Anlise Projeto Implementao Teste Manuteno

Legenda: cobre a fase com detalhes. cobre a fase com algum detalhe. no menciona a fase.
Figura 26 - Cobertura dos mtodos

Atravs da anlise da figura 26, pode-se perceber que a fase de anlise de riscos coberta somente pelo mtodo OOAD, onde os riscos so analisados durante todo o desenvolvimento. Somente os mtodos OOAD e OOSE se preocupam com a fase de anlise de requisitos e os mtodos Fusion e OOA-OOD mencionam a fase, dizendo que obtm os requisitos atravs de um documento informal escrito pelo usurio, geralmente em linguagem natural. Todos os mtodos apresentados cobrem a fase de anlise, projeto e implementao e, somente os mtodos OOSE e Fusion descrevem a fase de teste31. O mtodo OOAD cobre com detalhes a fase de manuteno, onde o mtodo OMT cobre com algum detalhe.
31
Acredita-se que durante a fase de implementao sejam executados alguns tipos de testes, mas que no so mencionados pelos autores dos mtodos.
57

Nesta seo foram apresentados os mtodos orientados a objetos - OMT, OOAD, OOSE, OOA-OOD e FUSION -, descrevendo o processo de cada um e algumas consideraes finais. Foi realizada uma comparao entre os mtodos, entre seus conceitos e entre os aspectos capturados por eles e a cobertura que cada um realiza. A partir do exposto pode-se concluir que cada mtodo aborda diferentes aspectos, reforando a idia de que cada mtodo ser mais eficiente no desenvolvimento de determinados tipos de sistemas. Para a finalizao deste trabalho, a seguir so apresentadas as concluses e as referncias bibliogrficas.
8. Concluses
Foram apresentados conceitos da rea de engenharia de software, uma descrio dos modelos de processo clssicos - waterfall, prototipao, espiral e transformacional -, dos conceitos relacionados a orientao a objetos e de cinco mtodos orientados a objetos - OMT, OOAD, OOSE, OOA-OOD e FUSION. Notamos que necessrio uma mudana de paradigma, pois a viso que a rea de orientao a objetos tem para o desenvolvimento bastante diferente da que muitos gerentes e desenvolvedores de software esto acostumados, que o paradigma estruturado. Conceitos como: encapsulamento, objeto, classe e herana so novos e requerem um prazo para estudo e adaptao. Uma comparao preliminar entre os mtodos foi apresentada, em forma de uma tabela (tabela 5 e tabela 6), onde podemos concluir que todos os mtodos abordam as principais caractersticas da orientao a objetos, mas se diferenciam com peculiaridades prprias, tais como: certas tcnicas, diagramas ou modelos que os outros mtodos no possuem. Os mtodos orientados a objetos foram recentemente criados e novos esto surgindo, o que aumenta o leque de opes para pesquisas e comparaes. Os mtodos relacionados na tabela 1, no abordam todas as fases do ciclo de desenvolvimento, e isto tambm poderia ser um estudo no sentido de melhor-los.
58
Atravs do estudo feito, pode-se notar que os mtodos possuem caractersticas que so comuns a todos, mas que tambm possuem caractersticas prprias que o classifica como o mais indicado para ser usado em determinados tipos de sistemas a serem desenvolvidos. Para que a escolha do mtodo e do modelo de processo seja adequada, necessrio o estudo das caractersticas do sistema, por exemplo: 1) se o sistema tem muita funcionalidade; 2) se os requisitos do sistema esto fracamente definidos; etc. Com bases em caractersticas deste tipo, poderemos escolher o mtodo e o modelo de processo mais indicados ao desenvolvimento do sistema, e tambm deve ser observado que cada mtodo adequado para ser usado em conjunto com determinados modelos de processo. Mas, ainda se observa a necessidade de fazer um estudo das caractersticas da organizao, por exemplo: a) se a equipe de desenvolvimento possui treinamento no mtodo e modelo de processo escolhidos; b) se o prazo adequado; etc. Verifica-se ento, a necessidade de um estudo mais aprofundado na rea, onde iremos abranger os aspectos acima mencionados, que resultar em uma dissertao de tese. Este trabalho servir como background, pois aqui foi feito um estudo geral da rea.
59
Referncias Bibliogrficas
[AND95] ANDERSSON, M., BERGSTRAND, J.; Uses Cases in Object-Oriented Analysis. - Dissertao de Mestrado, submetida ao Department of Communication Systems at Lund University, Sweden, 1995. Disponvel em: http://www.efd.lth.se/~d87man/ EXJOBB/Title_Abstract_Preface.html, 1995.
[BAK96]
BAKKER, G.; OMT Object Model: Notation, Concepts and Constructs. Disponvel: http://www.comp.mq.edu.au/courses/comp331/OMT/notation.html, 1996.
[BOO91]
BOOCH, G.; Object Oriented Design with Applications. - California: The Benjamin/Cummings Publishing Company, Inc., 1991.
[BOO94]
BOOCH, G.; Object Oriented Analysis and Design with Applications. - 2 edio. - Canad: Addison Wesley, 1994.
[BOO96]
BOOCH, G.; Object Solutions: Managing the Object Oriented Project. Menlo Park: Addison-Wesley, 1996.
[BRI95]
BRINKKEMPER, S., HONG, S., BULTHUIS, A., GOOR, G. v.d.; Object Oriented Analysis and Design Methods a Comparative Review. University of Twente, 1995. Disponvel em:
http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html.
[CAM93]
CAMARO, P. C. B.; Glossrio de Informtica. - Rio de Janeiro: LTC Livros Tcnicos e Cientficos, 1993.
[CAM97]
CAMPOS, F. B.; Sistematizando o Processo de Desenvolvimento de Software - Uma abordagem Orientada ao Reuso; Dissertao de mestrado submetida ao Departamento de Cincia da Computao da Universidade de Braslia. Braslia, 1997.
60
[CAP93]
CAPRETZ, L. F. e LEE, P. A.; Object Oriented Design: guidelines and techniques. - Information and Software Technology, Vol. 35, n 4, ISSN 09505849, Abril, 1993.
[COA92]
COAD, P., YOURDON, E.; Anlise Baseada em Objetos. - Trad. da 2 ed., CT Informtica. - Rio de Janeiro: Editora Campus, 1992.
[COA93]
COAD, P., YOURDON, E.; Projeto Baseado em Objetos; Trad. PubliCare Servios de Informtica, Vandenberg Dantas de Souza. - Rio de Janeiro: Editora Campus, 1993.
[COL96]
COLEMAN, D., et al.; Desenvolvimento Orientado a objetos: o mtodo Fusion; Trad. de Geraldo Costa Filho. - Rio de Janeiro: Editora Campus, 1996.
[HOD95]
HODGSON, J., Software Engineering Process Models. - Disponvel em: http://www.sju.edu/~jhodson/se/models.html, 1995.
[HUM89]
HUMPHREY, W. S., Managing Software Process. - Canad: AddisonWesley, 1989.
[JAC92]
JACOBSON, I., Object-Oriented Software Engineering: A use case driven approach. - USA: ACM Press, 1992.
[KAN95]
KAN, S. H., Metrics and Models in Software Quality Engineering. Massachusetts: Addison-Wesley, 1995.
[KEY93]
KEYES, J., Software Engineering Productivity Handbook. - USA: McGraw Hill, 1993.
[MAR]
MARQUES, A. F. D. M. R.; Descrio de Metodologias de Anlise orientadas a Objetos. - Universidade do Minho, Braga, Portugal. Ano no identificado.
[MAR94]
MARTIN, J.; Princpio da Anlise e Projeto baseado em Objetos; Trad. de Cristina Bazn. - Rio de Janeiro: Editora Campus, 1994. 61
[MON94]
MONTGOMERY, S. L.; Information Engineering: analysis, design and implementation. - Cambridge: Academic Press, 1994.
[NAS90]
NASCIMENTO, A. R. C., An Expert System to Advise on Information System Development Approaches, Dissertao submetida a Universidade de
Manchester, Departamento de Computao. - Inglaterra, 1990.
[NAS92]
NASCIMENTO, M. E. M., SMM (Software Management Model): A Multidimensional and Integrative Software Development Management Model, Tese submetida a Universidade de Manchester, Departamento de Computao. - Inglaterra, 1992.
[PER92]
PEREIRA, C. E., Mtodos de Anlise de Sistemas de Tempo Real usando Tcnicas de Orientao a Objetos. - So Carlos: X Simpsio Brasileiro de Engenharia de Software, 14-18/outubro, 1996.
[PRE92]
PRESSMAN, R. S., Engenharia de Software; Trad. de Jos Carlos Barbosa dos Santos. - So Paulo: Makron Books, 3a. edio, 1992.
[REI94]
REINOSO, G. B. e HEUSER C. A., Comparando o Processo de Modelagem de Tcnicas de Anlise Orientada a Objetos. - Curitiba - PR: Anais do VIII Simpsio Brasileiro de Engenharia de Software, 25-28/outubro, 1994.
[RUM94]
RUMBAUGH, J., et al.; Modelagem e Projetos baseados em Objetos; Trad. de Dalton Conde de Alencar. - Rio de Janeiro: Editora Campus, 1994.
[SHL90]
SHLAER, S., MELLOR, S.J.; Anlise de Sistemas Orientada para Objetos; Trad. de Anna Terzi Giova. - So Paulo: Editora McGraw-Hill, 1990.
[SIL96]
SILVA, R. P. e ; Avaliao de metodologias de anlise e projeto orientadas a objetos voltadas ao desenvolvimento de aplicaes, sob a tica de sua utilizao no desenvolvimento de frameworks orientados a objetos, Monografia submetida a UFRGS. - Porto Alegre, 1996.
62
[SOM92]
SOMMERVILLE, I., Software Engineering. - USA: Addison-Wesley, 4a. edio, 1992.
[THA88]
THAYER, R. H., Tutorial: Software Engineering Project Management. - Los Alamitos: IEEE Computer Society Press, 1988.
63

Uma Avaliação de Métodos Orientados A Objetos e Modelos de Processo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Avaliação de Métodos Orientados A Objetos e Modelos de Processo

Enviado por

Direitos autorais:

Formatos disponíveis

Relatrio de Pesquisa CIC/UnB - 05/97

Braslia - DF Setembro de 1997

Uma avaliao de Mtodos Orientados a Objetos e Modelos de Processo

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo

Gilene do Esprito Santo Borges.

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

desvantagens e aplicabilidade de cada um destes modelos.

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

4.1 Modelos de processo

4.3 Anlise de riscos

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

4.4 Anlise de requisitos

4.5 Anlise de sistema

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

4.10 Consideraes finais

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.1 Modelo Waterfall 5.1.1 Definio do modelo waterfall

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Figura 1 - Modelo de Processo Waterfall (PRE92)

5.1.2 Caractersticas do modelo waterfall

5.1.3 Vantagens do modelo waterfall

O mesmo que ordenada, metdica [FER77].

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.1.4 Desvantagens do modelo waterfall

5.1.5 Aplicabilidade do modelo waterfall

5.2 Modelo Prototipao 5.2.1 Definio do modelo prototipao

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

Refinamen -to do prottipo Avaliao do prottipo pelo cliente

Figura 2 - Modelo de Processo Prototipao (PRE92)

5.2.2 Caractersticas do modelo prototipao

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.2.3 Vantagens da prototipao

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.2.4 Desvantagens do modelo prototipao

5.2.5 Aplicabilidade do modelo prototipao

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.3 Modelo Espiral 5.3.1 Definio do modelo espiral

Anlise dos riscos

No sentido de um sistema concludo

Figura 3 - Modelo de Processo Espiral (PRE92)

5.3.2 Caractersticas do modelo espiral

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.3.3 Vantagens do modelo espiral

5.3.4 Desvantagens do modelo espiral

5.3.5 Aplicabilidade do modelo espiral

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.4 Modelo Transformacional 5.4.1 Definio do modelo transformacional

Provas da corretude das transformaes

5.4.2 Vantagens do modelo transformacional

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________

5.4.3 Desvantagens do modelo transformacional

5.4.4 Aplicabilidade do modelo transformacional

5.5 Consideraes finais

$'% (& $ # " !

FGB A9 E DC @ 5 8 &$ 7 & 6