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

Q

YHUGDG

LVW

1y

Qm

JRVWDPR

G

TX

Qm

HQWHQGHPRV DVVXVWD

*$6721

ii


AgradecimentosQuero 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


ResumoInicialmente, 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 .......................................................................................... 6v


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 FigurasFigura 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 TabelasTabela 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. IntroduoDesde 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.

1


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. ObjetivosO 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

1

[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.

2


(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. MotivaoNo 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.

3


A seguir sero apresentadas as definies de alguns conceitos mais importantes na rea de engenharia de software para a compreenso deste trabalho.

4. Aspectos ConceituaisPara 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 processoSistemas 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 MtodosMtodos 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 riscosSegundo [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 requisitosA 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 sistemaA 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 ProjetoO 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 ImplementaoAs 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 TesteLogo 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 ManutenoNa 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 finaisOs 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 ProcessoOs 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].

6


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 waterfallO 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].

2

Essencialmente necessrias, quer dizer, o que geralmente utilizada durante o desenvolvimento de um sistema.

7

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________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 waterfallO 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

3

O mesmo que ordenada, metdica [FER77].

8


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 waterfallAqui 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 prototipaoA prototipao uma tcnica para ajudar a estabelecer e validar os requisitos do sistema [SOM92] e [PRE95].

9


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 FimColeta 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 prototipaoA 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 prototipaoAs 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 prototipaoApesar 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 prototipaoForam 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.

4

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 espiralO 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 espiralSegundo [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 espiralA 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 espiralAs 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 espiralO 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 transformacionalSegundo [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 transformaesFigura 4 - Modelo de Processo Transformacional (SOM94)

5.4.2 Vantagens do modelo transformacionalO 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].

5

6

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 transformacionalSegundo [SOM92], escolher qual transformao aplicar uma tarefa prtica (exige conhecimento) e provar a correspondncia das transformaes difcil.

5.4.4 Aplicabilidade do modelo transformacionalSegundo [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].

5.5 Consideraes finaisA 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 objetoPara 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 ObjetoUm 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].

7

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

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________Objeto Retnguloapagarvrtice = 4

Objeto Tringuloapagar

Atributosdesenhar

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 ClasseSegundo [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 InstnciasOs 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.

PolgonosNome 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 OperaesSegundo [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 EncapsulamentoO 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 MensagemOs 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 PolimorfismoSegundo [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 LigaoA 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.

8

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 HeranaAgregao 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.

9

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 2atr1 atr2

Classe1.1 Herana simples 1 3atr3 atr1 atr2

Classe1.2

1 2atr4 atr1 atr2

2

4

5

Herana mltipla

1 Classe2 3atr1 atr2 atr3 atr4

Legenda2Mtodos herdados Mtodos prprios da classe

4

5 6

Classe Atributos herdados Atributos prprios da classe

Figura 10 Herana (MAR94) 6.11 Modelo use caseEste 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 CenriosO 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 eventosAps 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.

6.14 Consideraes finaisA 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

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo __________________________________________________________________________________________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 ObjetoNesta 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 mtodosInicialmente 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

Uma Avaliao de Mtodos Orientados a Objetos e Modelos de Processo

_________________________________________________________________________________________________________________________________________________

Tabela 1 - Maturidade dos mtodos bsicos orientados a objetosCobertura 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 OOSEO 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.

Construo2 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].

Teste5 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 OOSEEste 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 OMTDo 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


AnliseModelo de Objetos Modelo Dinmico Modelo Funcional

ProjetoProjeto 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 OMTNeste 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 OOADO 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 rel

uma avaliação de métodos orientados a objetos e modelos de processo

Documents