Ministrio da Educao Centro Federal de Educao Tecnolgica do Paran

Programa de Ps-Graduao em Eng. Eltrica e Informtica Industrial

DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS BASEADO NO MODELO AXIOMTICO

por Andrey Ricardo Pimentel Orientador: Prof. Dr. Paulo Czar Stadzisz

Curitiba, dezembro de 2004

ANDREY RICARDO PIMENTEL

DESENVOLVIMENTO DE SOFTWARE BASEADO NO MODELO AXIOMTICO Monografia de qualificao apresentada ao Programa de Ps-Graduao em Engenharia Eltrica e Informtica Industrial (CPGEI) do Centro Federal de Educao Tecnolgica do Paran (CEFET-PR), como parte dos requisitos para obteno do ttulo de Doutor em Cincias. rea de Concentrao: Informtica Industrial. Orientador: Prof. Dr. Paulo Czar Stadzisz

CURITIBA PR Dezembro 2004

SUMRIO

SUMRIO.................................................................................................................................II NDICE DE FIGURAS ............................................................................................................ IV NDICE DE TABELAS............................................................................................................. V LISTA DE ABREVIATURAS.................................................................................................. VI RESUMO ............................................................................................................................... VII 1 INTRODUO ......................................................................................................................1 1.1 OBJETIVOS........................................................................................................................2 1.2 MOTIVAO E JUSTIFICATIVA PARA O TEMA E OBJETIVOS PROPOSTOS..............4 1.3 ORGANIZAO DO DOCUMENTO ..................................................................................7 2 TEORIA DE PROJETO AXIOMTICO .................................................................................9 2.1 INTRODUO E DEFINIES INICIAIS ..........................................................................9 2.2 AXIOMA 1 - AXIOMA DA INDEPENDNCIA ...................................................................12 2.2.1 Matriz de projeto ........................................................................................................... 13 2.2.2 Medidas para o clculo da independncia funcional .................................................... 15 2.2.3 Hierarquia funcional e decomposio funcional ........................................................... 16 2.2.4 Diagrama de fluxo e Diagrama de juno de mdulos................................................. 18 2.3 AXIOMA 2 - AXIOMA DA INFORMAO ........................................................................19 2.4 TRABALHOS RELACIONADOS ......................................................................................22 2.4.1 Projeto axiomtico de software orientado a objetos ..................................................... 22 2.4.2 Decomposio funcional............................................................................................... 24 2.4.3 Tpicos Gerais em Teoria de Projeto ........................................................................... 25 3 METODOLOGIA DE DESENVOLVIMENTO PROPOSTA .................................................27 3.1 RELACIONAMENTO ENTRE PROJETO AXIOMTICO E PROJETO DE SOFTWARE 27 3.2 DOMNIOS COMPLEMENTARES ...................................................................................29 3.3 DESCRIO DAS ETAPAS DA METODOLOGIA PROPOSTA ......................................32 3.3.1 Mapeamento entre domnios do cliente e funcional ..................................................... 32 3.3.2 Mapeamento entre domnios funcional e fsico. ........................................................... 33 3.3.2.1 Primeiro nvel de decomposio.................................................................................34 3.3.2.2 Segundo nvel de decomposio................................................................................36 3.3.2.3 Terceiro nvel de decomposio.................................................................................38 3.3.2.4 Quarto nvel de decomposio ...................................................................................39

ii

3.3.3 Mapeamento entre domnios fsico e de processo. ...................................................... 46 3.4 -CLCULO DO CONTEDO DE INFORMAO ............................................................47 4 MEDIDA DE CONTEDO DE INFORMAO PARA SISTEMAS DE SOFTWARE .........48 4.1 CONTEDO DE INFORMAO DE SISTEMAS COMPUTACIONAIS ...........................48 4.2 CONTEDO DE INFORMAO NOS NVEIS DE DECOMPOSIO ...........................49 4.2.1 Contedo de informao nos nveis 1 e 2 .................................................................... 50 4.2.2 Contedo de informao do nvel 3.............................................................................. 51 4.2.3 Contedo de informao para o nvel 4........................................................................ 52 4.3 APLICAO DO CONTEDO DE INFORMAO NA METODOLOGIA ........................57 5 PLANO DE TRABALHO PROPOSTO................................................................................61 5.1 ATIVIDADES PLANEJADAS ............................................................................................61 5.2 CRONOGRAMA GERAL DAS ATIVIDADES A SEREM DESENVOLVIDAS...................64 6 CONCLUSES ...................................................................................................................65 6.1 AGRADECIMENTO ..........................................................................................................69 ANEXO 1 - TEOREMAS E COROLRIOS RELACIONADOS COM OS AXIOMAS ............70 1.1 COROLRIOS..................................................................................................................70 1.2 TEOREMAS DE PROJETOS GERAIS.............................................................................71 1.3 TEOREMAS RELACIONADOS COM PROJETO DE SOFTWARE .................................75 REFERNCIAS ......................................................................................................................76

iii

NDICE DE FIGURAS

Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18

Domnios do Projeto Axiomtico .........................................................................11 Ziguezagueamento ...........................................................................................17 Diagrama de juno de mdulo ..........................................................................18 Diagrama de fluxo ...............................................................................................19 Relao entre conceitos do projeto axiomtico e de projeto de software...........28 Domnios complementares sugeridos.................................................................30 Domnios de classes, de interaes e de estados..............................................31 Casos de uso de um sistema de registro de pontos ...........................................36 Subcasos de uso.................................................................................................37 Diagrama de atividades para o subcaso de uso Entrar dados de Empregado 39 Diagrama de atividades da decomposio do subcaso Emprestar Exemplar ....43 Envio de mensagem referente A FR12162 x DP12162 ......................................44 Definio de Mtodo referente A FR12162 x DP12162......................................45 Mudana de estado do objeto IntBD referente clula FR12162 x DP12162 ...46 Profundidade da rvore de herana (DIT) ..........................................................54 Nmero de subclasses (NOC) ............................................................................54 Classes para o clculo do contedo de informao ...........................................59 Classe CIntBDNova ............................................................................................60

iv

NDICE DE TABELAS

Tabela 1 Tabela 2 Tabela 3 Tabela 4 Tabela 5 Tabela 6 Tabela 7 Tabela 8

Matriz de projeto de primeiro nvel......................................................................35 Matriz de projeto de 2o. nvel ..............................................................................38 Matriz de projeto de 4o. nvel ..............................................................................41 Matriz de projeto referente decomposio de confirmar emprstimo ..............44 Mtricas de complexidade e tipos de requisitos funcionais ................................50 Contedo de informao da classe CIntBD......................................................58 Contedo de informao da classe CIntBDNova .............................................60 Cronograma de atividades ..................................................................................64

LISTA DE ABREVIATURAS

UML RUP OMT GRASP CPGEI CEFET-PR WDK FR DP PV CN ADo-oSS MVC ucpc eucp pfc epf WMC DIT NOC CBO RFC LCOM CASE CNPq

Unified Modeling Language Rational Unified Process Object Modeling Technique General Responsibility Assignment Software Patterns Programa de Ps-graduao em Engenharia Eltrica e Informtica Industrial Centro Federal de Educao Tecnolgica do Paran Workshop Design Konstruktion Functional Requirement Design Parameter Process Variable Customer Needs Axiomatic Design of object-oriented Software Systems Modelo-Viso-Controlador use case points contados estimativa baseada nos use case points pontos por funo contados estimativa dos pontos por funo Weighted Methods per Class Depth of the Inheritance Tree Number Of Children Coupling Between Objects Response For a Class Lack of COhesion of Methods Computer Aided Software Engineering Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico

vi

RESUMO

Este trabalho prope a criao de uma metodologia de projeto de software baseada na adaptao da teoria de projeto axiomtico ao projeto de software orientado a objetos. Esta metodologia tem por objetivo fornecer parmetros objetivos para a tomada de deciso sobre qual das possveis solues para um projeto a melhor, visando garantir a qualidade e a robustez do projeto. A motivao para a realizao deste trabalho tornar o processo de projeto de software mais preciso e confivel de forma a garantir sua qualidade. A teoria de projeto axiomtico foi estabelecida para garantir esta qualidade desde a elaborao do projeto do produto. A metodologia proposta neste trabalho baseada na teoria de projeto axiomtico. Neste trabalho, os conceitos do projeto axiomtico so adaptados para o uso em projetos de software, de modo a auxiliar e facilitar a garantia de sua qualidade. Esta metodologia tem como conceito fundamental, os mapeamentos entre os domnios do projeto. Para o uso em projeto de software, so propostos novos domnios complementares, tpicos de projetos de software, como: o domnio de casos de uso, o domnio de classes, o domnio de interaes e o domnio de estados. Outro conceito fundamental o processo de decomposio funcional, que foi adaptado para satisfazer as necessidades do projeto de software. Outro conceito fundamental do projeto axiomtico o contedo de informao do projeto. Neste trabalho, proposta uma adaptao das grandezas usadas para o clculo deste contedo, para facilitar o uso em projetos de software orientado a objetos e para facilitar uma possvel automao deste clculo.

vii

1 INTRODUO

O desenvolvimento de software tem sido objeto de estudos desde a criao do computador. Com os avanos tecnolgicos e da eletrnica, o custo do hardware caiu drasticamente. Isto ocasionou um grande crescimento na utilizao do computador, tanto pelas empresas quanto pela populao em geral. O computador passou a ser usado como ferramenta corrente de trabalho, equipamento de comunicao e at mesmo como forma de entretenimento. Este fato ocasionou um crescimento muito grande na demanda por software, cada vez mais complexos e sofisticados. Os programas de computador, antes construdos para serem executados poucas vezes, comearam a ter sua vida til prolongada aumentando, portanto, a necessidade de alteraes nos sistemas j existentes. Isto elevou os custos para desenvolver e, principalmente, para realizar correes e evolues nos sistemas computacionais. Alm disso, tem-se o fato de que se consegue desenvolver computadores cada vez melhores e mais baratos e, em contrapartida, no se consegue desenvolver software que satisfaa toda a demanda, tanto por tipos e quantidade de sistemas quanto por complexidade. Tambm no se consegue desenvolver software com custos compatveis com os baixos custos de hardware. O processo de desenvolvimento de software teve que evoluir para fazer frente s presses por reduo dos custos e aumento da produtividade. Neste contexto surgiram linguagens e abordagens de desenvolvimento como: metodologia Estruturada (GANE; SARSON, 1995), Anlise Essencial (MCMENAMIM; PALMER, 1991), tcnicas orientadas a objetos como a proposta por Booch (BOOCH, 1994), Object Modeling Technique (OMT) (RUMBAUGH et al., 1991), Object-Oriented Software Engineering (OOSE) (Jacobson, 1994), Unified Modeling Language (UML) (BOOCH, RUMBAUGH, e JACOBSON, 1999), Rational Unified Process (RUP) (JACOBSON, BOOCH e RUMBAUGH, 1999), LARMAN (1997) e, mais recentemente, Extreme Programming

(BECK, 1999), Catalisys (D'SOUZA; WILLS, 1998) e desenvolvimento orientado a aspectos (KICZALES et al., 1997). A partir destas tcnicas, o desenvolvimento de software se tornou cada vez menos um processo baseado nas capacidades individuais ou talento dos desenvolvedores e mais um processo de engenharia, do ponto de vista do rigor dos mtodos aplicados. A teoria de projeto axiomtico (SUH, 1990) surgiu como um processo para projetar produtos, peas e componentes, usado em diversas reas da engenharia. Este processo baseado em conceitos de independncia entre os componentes usados no projeto e na minimizao do contedo de informao do projeto. Estes conceitos se aplicam tambm no desenvolvimento de software e podem melhorar a qualidade do processo de

desenvolvimento, garantindo a qualidade do produto desenvolvido. Com a teoria de projeto axiomtico possvel conseguir parmetros concretos para decidir qual a melhor soluo para um problema entre diversas solues possveis.

1.1 OBJETIVOS

Os objetivos do trabalho de doutorado apresentado neste documento so: Aplicar a teoria de projeto axiomtico ao projeto de software orientado a objetos. Utilizar a UML como linguagem de modelagem para o projeto axiomtico de software. Identificar mecanismos de extenso para a UML e para a teoria de projeto axiomtico aplicada ao desenvolvimento de software. Estabelecer um processo de desenvolvimento de software baseado na teoria de projeto axiomtico usando a UML. Investigar os efeitos da utilizao da metodologia estabelecida com relao a aspectos de qualidade de software e tambm com relao s novas

tendncias na rea de projeto de software. A aplicao da teoria de projeto axiomtico ao projeto de software orientado a objetos consiste basicamente em fazer uma associao entre os principais elementos do projeto de software orientado a objetos como os casos de uso, classes, responsabilidades, atributos e operaes, e os elementos da teoria de projeto axiomtico. Esta associao necessria para que possam ser aplicados os princpios do projeto axiomtico como os axiomas e teoremas, as matrizes de projeto e o processo de ziguezagueamento entre os domnios de projeto. A utilizao da UML como linguagem de modelagem para o projeto axiomtico de software a adaptao do processo de projeto axiomtico aos mecanismos e notao dos projetos orientados a objetos. A UML a linguagem padro para modelagem de sistemas orientados a objetos. Como a UML e a teoria de projeto axiomtico foram criados a partir de diferentes abordagens, esta adaptao envolver a identificao de meios de representao para a UML e para a teoria de projeto axiomtico adequados ao projeto de software. A identificao de mecanismos de extenso para a UML e para a teoria de projeto axiomtico consiste na identificao da necessidade de adaptao dos seus conceitos. A UML e o projeto axiomtico sero avaliados do ponto de vista das diferenas de aplicabilidade entre seus processos e ferramentas. Ento, sero criados mecanismos que iro estender os j existentes, para que a UML e o projeto axiomtico possam ser aplicados em conjunto. necessria a criao de um modelo de ciclo de vida adequado, muito prximo do ciclo de vida de um projeto de software orientado a objetos. Tambm necessria a identificao de quais diagramas e modelos sero usados em cada fase, quais so os prrequisitos de cada fase e quais so seus produtos. Tanto a teoria de projeto axiomtico como a UML so aplicveis em vrios modelos de processos de desenvolvimento. A idia aplicar a teoria axiomtica ao desenvolvimento de sistemas computacionais, de tal forma que se tenha elementos de projeto mais independentes e mais

coesos. Para isso ser necessrio fazer uma associao entre os modelos e diagramas da UML e os da teoria axiomtica. Isto envolve a possvel criao de novos mecanismos para a UML e para a Teoria Axiomtica. Um dos objetivos deste trabalho investigar os efeitos da utilizao da metodologia estabelecida com relao a aspectos de qualidade de software e, tambm, com relao s novas tendncias na rea de projeto de software. Um dos aspectos importantes a investigao sobre a influncia da metodologia em aspectos de qualidade de software como manutenibilidade, adaptabilidade, portabilidade, reutilizao, disponibilidade,

usabilidade, eficincia e correo (PRESSMAN, 2004). Outro aspecto envolve a investigao sobre a possibilidade de desenvolvimento de ferramentas de software para auxiliar no processo de desenvolvimento, em termos de quais so e como seriam os itens automatizados. Tambm envolve a investigao da aplicabilidade da metodologia em conjunto com novas tendncias na rea de desenvolvimento de software como Extreme Programming (BECK, 1999), desenvolvimento orientado a aspectos (KICZALES et. al., 1997), padres (GAMMA et al., 2000), entre outros.

1.2 MOTIVAO E JUSTIFICATIVA PARA O TEMA E OBJETIVOS PROPOSTOS

A motivao para este trabalho tornar o processo de projeto de software mais preciso e confivel de forma a garantir sua qualidade. O projeto de software evoluiu muito desde o surgimento dos primeiros computadores, tendo surgido diversas tcnicas, como as citadas no captulo anterior. Mas, mesmo empregando corretamente uma metodologia, muitas decises importantes de projeto no so baseadas estritamente na metodologia, mas sim na experincia pessoal e profissional do desenvolvedor. Esta experincia no garante que as decises estejam corretas. Ao contrrio, pode levar a modelos com erros, s vezes graves. Os modelos criados dessa forma podem comprometer a qualidade do software criado em termos de adaptabilidade, reutilizao e portabilidade. Ao se realizar um projeto

de software, a estrita aplicao de uma das metodologias existentes, no garante a gerao de um produto com qualidade. As metodologias atuais no possuem mecanismos para garantir a qualidade do modelo. Por isso, comeou-se a adotar os padres de projeto, que nada mais so do que a aplicao da experincia de outros desenvolvedores (LARMAN, 1997). Uma metodologia de desenvolvimento deve prover mecanismos para garantir que os produtos gerados atravs dela tenham a qualidade desejada. No desenvolvimento de software orientado a objetos usando a UML ocorrem, freqentemente, decises de projeto tomadas sem parmetros mais precisos que no a experincia do desenvolvedor. Entre elas esto a identificao e criao de classes e a atribuio de operaes a classes. A identificao e a criao de classes feita a partir da descrio dos casos de uso, segundo processos orientados a objetos como o Unified Process (JACOBSON, BOOCH e RUMBAUGH, 1999) e o apresentado por LARMAN (1997). As classes so identificadas a partir de palavras ou expresses importantes na especificao dos casos de uso. O que ocorre muitas vezes o fato de uma classe possuir operaes que no seriam prprias para ela, existindo ento a necessidade da criao de uma nova classe. Entretanto, a deciso sobre a criao desta classe normalmente tomada de acordo com a experincia do projetista ou seguindo padres de projeto de software como General Responsibility Assignment Software Patterns (GRASP) (LARMAN, 1997). Do mesmo modo, ocorre a atribuio de uma responsabilidade a uma classe. s vezes, identifica-se uma responsabilidade a ser resolvida pelo sistema e esta precisa ser atribuda a uma classe. Novamente, usa-se a experincia do projetista ou padres de projeto. Na teoria de projeto axiomtico temos ferramentas como os axiomas, teoremas e seus corolrios, a matriz de projeto, a hierarquia funcional, o ziguezagueamento e os domnios de projeto (SUH, 1990), que ajudam na tomada de decises sobre a qualidade do projeto de maneira mais precisa. A teoria de projeto axiomtico, desenvolvida para projetos em engenharia industrial pode fornecer ferramentas para ajudar na soluo dos problemas

relacionados com qualidade de projetos. importante prover um mecanismo para saber a ordem na qual os mdulos de software devem ser projetados e quais mdulos podem ser projetados em paralelo por equipes diferentes. Muitas vezes necessria a diviso do trabalho em diferentes equipes de desenvolvimento. A teoria de projeto axiomtico fornece ferramentas para tornar esta diviso mais eficiente e, tambm, formas para fazer com que as equipes trabalhem da maneira mais independente possvel. Estas ferramentas so: os axiomas j citados, que vo permitir tornar os mdulos mais independentes, e a matriz de projeto (SUH, 1990). Esta matriz fornece informaes sobre qual parmetro de projeto satisfaz determinado requisito funcional. Isto permite visualizar quais parmetros de projeto esto relacionados com o mesmo requisito funcional e, portanto, saber quais so independentes. Esta independncia funcional permite que as diferentes equipes possam realizar o desenvolvimento do software, independentemente. Caso contrrio, haver a necessidade de comunicao e sincronizao entre as equipes durante o desenvolvimento. Isto elevar a durao e o custo do desenvolvimento. Um aspecto importante para garantir a qualidade de software a capacidade de rastrear os requisitos a partir de algum artefato que satisfaz este requisito (LEFFINGWELL, WIDRIG, 2003). Esta capacidade de rastreamento garantida pela teoria de projeto axiomtico atravs de ferramentas como a decomposio funcional, a hierarquia funcional e a matriz de projeto. A introduo de mais nveis de abstrao no projeto evita a tomada de deciso diretamente sobre itens de um nvel de abstrao muito mais baixo. Isto ocorre freqentemente na criao dos diagramas de seqncia. Neste caso, o desenvolvedor passa de um nvel de abstrao alto (casos de uso) para um nvel de abstrao muito baixo, que a troca de mensagens entre objetos. Assim, uma decomposio funcional ajudaria a evitar esta discrepncia. Durante a modelagem das classes acontece, freqentemente, um problema que

o de se obter classes que possuem responsabilidades que elas no deveriam ter. Este problema pode ser minimizado aplicando conceitos como herana e agregao. Mas mesmo assim, necessrio que o desenvolvedor possua experincia para evitar estes problemas. A metodologia proposta pode auxiliar a identificao dos mtodos de cada classe atravs da identificao dos servios tcnicos (resultado da decomposio funcional), da matriz de projeto e do clculo do contedo de informao, possibilitando uma tomada de deciso a respeito das classes com parmetros mais concretos, obtidos a partir dos axiomas. Segundo descrito em (PRESSMAN, 2004), existem vrias mtricas de projeto de software. Mtricas baseadas na funcionalidade do sistema como pontos por funo (Function Points) (VAZQUEZ; SIMES; ALBERT, 2003), mtricas baseadas em

caractersticas das classes como as mtricas CK (CHIDAMBER e KEMERER, 1994), e mtricas para o cdigo fonte como as definidas em (HALSTEAD, 1977) e linhas de cdigo. Estas mtricas so baseadas na complexidade do produto a ser desenvolvido. Medem a complexidade das funes do software, a complexidade das classes, o tamanho da soluo, entre outras. No se consegue aferir a qualidade do projeto em si, mas apenas do produto. Usando o projeto axiomtico pretende-se poder decidir sobre a qualidade do projeto em si com base em uma teoria estabelecida e no, somente, na experincia do projetista.

1.3 ORGANIZAO DO DOCUMENTO

Este trabalho apresenta a proposta de continuidade do trabalho de doutorado que est sendo realizado no programa de Ps-Graduao em Engenharia Eltrica e Informtica Industrial (CPGEI) do Centro Federal de Educao Tecnolgica do Paran (CEFET-PR). So apresentados os resultados obtidos e as atividades a serem efetuadas para o trmino do trabalho. No captulo 1 apresentada a introduo ao tema alm dos objetivos deste trabalho e a motivao. No captulo 2 apresentado um resumo da teoria de projeto

axiomtico alm de trabalhos relacionados ao projeto axiomtico e desenvolvimento de software. Nos captulo 3 e 4 apresentada a metodologia de desenvolvimento proposta neste trabalho de doutorado. No captulo 5 so apresentadas prximas etapas a serem realizadas no trabalho de doutorado, o cronograma de realizao e concluses. A metodologia de desenvolvimento proposta neste trabalho de doutorado apresentada com base nos dois axiomas do projeto axiomtico. No captulo 3 so apresentados os aspectos relacionados com o axioma um como: a adaptao das etapas da decomposio funcional para o projeto de software, a adaptao dos principais conceitos do projeto axiomtico para o projeto de software e as extenses teoria propostas neste trabalho. No captulo 4 apresentado o clculo do contedo de informao para a metodologia proposta neste trabalho.

2 TEORIA DE PROJETO AXIOMTICO

Este captulo apresenta um resumo da teoria de projeto axiomtico. A primeira seo apresenta uma introduo teoria e suas definies bsicas. A segunda seo apresenta os principais conceitos do projeto axiomtico relacionados com o axioma da independncia. Na terceira seo so apresentados os principais conceitos relacionados com o axioma da informao. Na quarta seo so apresentados trabalhos relacionados com a teoria de projeto axiomtico e desenvolvimento de software.

2.1 INTRODUO E DEFINIES INICIAIS

Segundo NORLUND (1996), Projetar basicamente uma atividade de processamento de informao. O processo comea com a entrada da descrio das necessidades, requisitos e restries, e termina com uma descrio completa do sistema que ir satisfazer estes requisitos, juntamente com a descrio de como construir este sistema (NORLUND, 1996). A pesquisa sobre projeto de engenharia comeou, de forma mais sistemtica, na Alemanha, na metade do sculo XIX. Muitas destas pesquisas foram compiladas em (BJRNEMO, 1983) e apresentadas em conjunto em (NORLUND, 1996). Entre elas esto teorias como a da Resoluo Inventiva de Problemas (TRIZ) (ALTSHULLER, 1988), desenvolvimento com qualidade total de CLAUSING (1994), a cincia de projeto da escola WDK (Workshop Design Konstruktion) (HUBKA; EDER, 1992), o Projeto Robusto de TAGUCHI (1987) e a Teoria do Projeto Axiomtico (SUH, 1990). A teoria de projeto axiomtico de Suh comeou com a seguinte pergunta: Dado um conjunto de requisitos funcionais para um determinado produto, existem axiomas de

10

aplicao genrica que levam a decises corretas em cada passo da fabricao (desde a etapa de projeto at a montagem final e inspeo) para planejar um sistema de produo timo? (SUH, BELL e GOSSARD, 1978). Para responder a esta pergunta foi elaborado um conjunto de axiomas que foram testados e avaliados em estudos de caso. Os 12 axiomas iniciais foram reduzidos a apenas dois axiomas e um conjunto de corolrios e teoremas (SUH, 1990). Os dois axiomas propostos so: o axioma 1, tambm chamado de axioma da independncia, e o axioma 2, tambm chamado de axioma do contedo de informao. O primeiro axioma define um projeto bom como sendo aquele, onde os requisitos funcionais so independentes entre si. O segundo axioma estabelece que o melhor projeto aquele que possui o menor contedo de informao (SUH, 1990). Na teoria de projeto axiomtico, o desenvolvimento realizado atravs do mapeamento entre os domnios do cliente, funcional, fsico e de processo (SUH, 2001). Este mapeamento ilustrado na Figura 1. O domnio do cliente representa o conjunto das necessidades do cliente. Como exemplo de necessidades do cliente pode-se ter: performance desejada, satisfao dos clientes, atributos desejados, lucro, respostas desejadas do sistema. O domnio funcional representa o conjunto dos requisitos funcionais do sistema que especificam as exigncias impostas ao produto a partir das necessidades dos clientes. Neste domnio estaro representadas as funcionalidades desejadas. Como exemplo, podese ter: prover acesso ao interior, movimentar o veculo, suportar a carga, manter a carga imvel. No caso de sistemas de software: registrar um cliente, registrar uma venda, mostrar o relatrio de acessos, entre outros. O domnio fsico representa o conjunto dos parmetros de projeto que satisfazem os requisitos funcionais. Os parmetros de projeto so as variveis fsicas que so criadas de forma a satisfazer os requisitos funcionais. Como exemplo, pode-se ter: porta, motor, material de isolamento, eixos, paredes, suportes. No caso de sistemas de software: objetos,

11

funes, programas, algoritmos, entre outros. O domnio de processo o conjunto dos processos, representados pelas variveis de processo, que realizam os parmetros de projeto (SUH, 2001). Como exemplo, pode-se ter, no caso de sistemas de software: linhas de cdigo, variveis, compiladores, entre outros. Inicialmente, feito o mapeamento entre o domnio do cliente e o domnio funcional. A seguir feito o mapeamento entre o domnio funcional e o fsico. Por fim feito o mapeamento entre o domnio fsico e o de processo. Em um processo de engenharia concorrente, entretanto, seria possvel realizar um ziguezagueamento entre mais de dois domnios (STADZISZ, 1997). Mapeamento o processo que relaciona um elemento de um domnio com um, ou mais elementos do outro domnio. Por exemplo, o mapeamento entre o domnio funcional e o fsico relaciona um requisito funcional com um parmetro de projeto, usando a matriz de projeto. FIGURA 1 DOMNIOS DO PROJETO AXIOMTICO

Uma definio mais formal para requisito funcional (FR, do ingls, functional requirement) dada por SUH (2001). Os requisitos funcionais (FRs) so o conjunto mnimo de requisitos independentes que especificam completamente as necessidades do produto

12

no domnio funcional. Segundo SUH (2001), os parmetros de projeto (DP, do ingls, design parameter) so as variveis chaves no domnio fsico que caracterizam que o projeto satisfaz os requisitos funcionais (FRs) especificados. Variveis de processo (PV, do ingls, process variable) so as variveis chaves no domnio de processo que caracterizam que o processo pode gerar, ou realizar, os parmetros de projeto (DP) especificados. As Restries (C, do ingls, constraint) so limites para as solues aceitveis. Existem dois tipos de restries: de entrada e de sistema. As restries de entrada so colocadas como parte das especificaes do projeto. As restries de sistema so impostas pelo sistema no qual a soluo do projeto dever funcionar (SUH, 2001).

2.2 AXIOMA 1 - AXIOMA DA INDEPENDNCIA

Apesar do desenvolvimento ser um processo que passa pelos quatro domnios, a atividade de projeto em si representada pelos mapeamentos entre o domnio funcional e o domnio fsico. Neste mapeamento, para cada requisito funcional (FR), identificado um parmetro de projeto (DP) correspondente, de forma a satisfazer o axioma 1 ou axioma da independncia. O enunciado deste axioma Manter a independncia dos requisitos funcionais (SUH, 2001). Um enunciado alternativo para este axioma Em um projeto aceitvel, os parmetros de projeto (DPs) e os requisitos funcionais (FRs) esto relacionados de tal forma que um DP especfico pode ser ajustado para satisfazer um FR sem afetar outros FRs (SUH, 2001). O axioma da independncia estabelece que quando existem dois ou mais requisitos funcionais (FRs), a soluo deve ser tal que cada requisito funcional (FR) deve ser satisfeito sem afetar os outros (SUH, 2001). Isto significa que o conjunto de parmetros de projeto (DPs) deve ser identificado de forma a satisfazer os requisitos funcionais (FRs) e manter sua independncia. A identificao de um conjunto de parmetros de projeto (DP) que satisfaam o axioma da independncia nem sempre possvel. Neste caso, o conjunto

13

de requisitos funcionais (FRs) deve ser modificado, ou seja, deve ser encontrado um novo conjunto de requisitos funcionais (FRs), de forma a conseguir um projeto mais independente. 2.2.1 Matriz de projeto Um dos instrumentos usados no projeto axiomtico a matriz de projeto. Ela representa o mapeamento entre dois domnios, principalmente entre o domnio funcional e o fsico. Em uma das dimenses da matriz esto representados os requisitos funcionais (FRs) e na outra, os parmetros de projeto (DPs). Cada elemento da matriz representa que um determinado parmetro de projeto (DP) est relacionado a um determinado requisito funcional (FR). A relao que representa a matriz de projeto apresentada na expresso (1) (SUH, 1990).

FR

A DP

(1)

A relao apresentada em (1) pode ser representada sob a forma de um sistema de equaes, como em (2) (SUH, 1990). Neste sistema, os elementos Aij representam o relacionamento entre o requisito funcional FRi e o parmetro de projeto DPj . Por exemplo, se o elemento A12 for diferente de zero, significa que o parmetro de projeto DP2 usado para satisfazer o requisito funcional FR1.

FR1 A11 DP 1 A12 DP 2 A13 DP 3 FR 2 A21 DP 1 A 22 DP 2 A23 DP 3 FR 3 A31 DP 1 A32 DP 2 A33 DP 3

Do ponto de vista do axioma de independncia existem trs tipos de matrizes de projeto. Em (3), cada parmetro de projeto (DP) usado para satisfazer um nico requisito funcional (FR). Esta configurao satisfaz completamente o axioma da independncia. Neste caso, o projeto ou soluo dito desacoplado, do ingls, uncoupled. Este considerado o melhor tipo de projeto, pois um ajuste em um parmetro de projeto (DP) no (2)

14

afeta outros requisitos funcionais (FRs) (SUH, 1990).

FR1 FR 2 FR3

A11 0 0

DP 1 DP 2 DP 3
(3)

A 22 0 0 A 33

O tipo de projeto mais comum o projeto dito semi-acoplado1 (SUH, 1990). Neste caso, a matriz de projeto assume o formato de uma matriz triangular inferior como apresentado em (4) (SUH, 1990). Cada parmetro de projeto (DP) usado para satisfazer o requisito funcional (FR) correspondente e os requisitos funcionais (FRs) que esto representados na matriz, abaixo deste. Este fato indica que ir existir uma ordem na qual os parmetros de projeto (DPs) devero ser realizados.

FR1 FR 2 FR3

A11 A 21 A31

0 A22 A32

0 0 A33

DP 1 DP 2 DP 3
(4)

A situao a ser evitada em um projeto quando os parmetros de projeto no s esto relacionados com os requisitos funcionais (FRs) que esto representados na matriz, abaixo deste, mas, tambm, com os que esto representados na matriz, acima deste. Neste caso, a construo de cada parmetro de projeto ser dependente da construo de outros parmetros de projeto, o que envolve muita sincronizao no desenvolvimento. No existe, portanto, uma ordem de na realizao dos parmetros de projeto (DPs) que resolva este problema. Este tipo de projeto o chamado acoplado e a matriz assume um formato cheio, como em (5) (SUH, 1990).

Traduzido do original decoupled (SUH, 1990)

15

FR1 FR 2 FR3

A11 A 21 A31

A12 A22 A32

A13 A23 A33

DP 1 DP 2 DP 3
(5)

Existem casos onde a matriz de projeto no assume a forma quadrada. O nmero de requisitos funcionais (FR) maior que o nmero de parmetro de projetos (DP). Isto resulta em um projeto acoplado. Segundo SUH (1990), este tipo de projeto resultado de fatores que poderiam ser especificados como requisitos funcionais (FRs) e que no foram identificados. Nestes casos, deve-se identificar mais parmetros de projeto (DP) para tornar a matriz desacoplada ou, pelo menos, semi-acoplada (SUH, 1990). 2.2.2 Medidas para o clculo da independncia funcional possvel encontrar uma medida quantitativa de independncia funcional. Em (SUH, 1990) so descritas duas medidas de independncia funcional com base na matriz de projeto. So elas a reangularidade, R, (do ingls reangularity) e a semangularidade, S (do ingls semangularity). Reangularidade mede a ortogonalidade entre os parmetros de projeto (DPs) e pode ser considerada como uma medida de interdependncia entre os parmetros de projeto (DPs) (OLEWNIK; LEWIS, 2003). Uma frmula para o clculo da reangularidade apresentada na equao (6).
n k 1 n k 1 1 2 2

Aki Akj
2 n k 1

R
i 1, n 1 j 1 i, n

(6)

A ki

Akj

semangularidade

mede

relacionamento

angular

entre

os

eixos

correspondentes de parmetros de projeto (DPs) e de requisitos funcionais (FRs) e pode ser considerada como sendo uma medida da correlao entre um requisito funcional (FR) e qualquer conjunto de parmetros de projeto (DPs) (OLEWNIK; LEWIS, 2003). Uma frmula

16

para o clculo da semangularidade apresentada na equao (7). Ambas, possuem um valor mximo de 1, que corresponde a um projeto desacoplado (ideal). Quando o nvel de acoplamento aumenta, o valor de reangularidade e de semangularidade decresce (OLEWNIK; LEWIS, 2003).
n

S
j 1

A jj
n k 1

A kj

2 1 2

(7)

Em (SUH, 2001) so enunciados alguns corolrios e teoremas relacionados com a teoria de projeto axiomtico. Estes teoremas e corolrios so apresentados no anexo 1 deste documento. 2.2.3 Hierarquia funcional e decomposio funcional Quando os requisitos funcionais (FR) so identificados, eles fornecem as especificaes necessrias para o projeto no nvel conceitual. Mas, para a realizao do projeto, necessrio um nvel de detalhamento maior. necessrio decompor esses requisitos em unidades com maior detalhamento. Para isso, os requisitos funcionais (FR) so estruturados em uma hierarquia funcional. Esta hierarquia obtida atravs da decomposio funcional de cada requisito funcional (FR) em sub-requisitos. A

decomposio funcional um processo no qual, aps o mapeamento de todos os requisitos funcionais em parmetros de projeto de um nvel da hierarquia, cada requisito funcional (FR) dividido em funcionalidades menores, chamadas sub-requisitos (sub-FR). Esta decomposio deve seguir algumas restries, de forma a no alterar as relaes de independncia funcional representadas na matriz de projeto (TATE, 1999). Para cada requisito funcional identificado em um determinado nvel de decomposio, identificado um parmetro de projeto. Aps a identificao de todos os parmetros de projeto de um nvel da hierarquia funcional, feita a decomposio de cada requisito funcional em sub-requisitos, fazendo surgir um novo nvel da hierarquia funcional.

17

Ento, o processo realizado novamente, agora para este novo nvel. A decomposio feita at que o projeto esteja completo (SUH, 2001). Para cada novo nvel de decomposio dos requisitos funcionais encontrados, realizado um mapeamento entre os domnios e aps o mapeamento feita uma nova decomposio. Este processo de passar do domnio funcional para o domnio fsico e novamente para o funcional em um outro nvel da hierarquia chamado de ziguezagueamento (SUH, 2001). A Figura 2 ilustra este processo. FIGURA 2 ZIGUEZAGUEAMENTO

No somente os requisitos funcionais (FRs) orientam a definio ou inveno dos parmetros de projeto (DPs), mas tambm, os parmetros de projeto orientam a decomposio dos requisitos funcionais. Isto acontece devido ao fato que para decompor os requisitos funcionais (FRs) necessrio que os parmetros de projeto (DPs)

correspondentes sejam identificados. A identificao do conjunto de sub-requisitos funcionais (sub-FR) ter como ponto de partida os parmetros projeto (DPs) identificados no nvel anterior.

18

2.2.4 Diagrama de fluxo e Diagrama de juno de mdulos Grandes sistemas so caracterizados por possurem um grande nmero de componentes, sejam eles de hardware ou software. Para o projeto de grandes sistemas existe a necessidade de se entender e representar a arquitetura do sistema e cada um de seus mdulos. Para este tipo de representao foram desenvolvidas duas ferramentas: o diagrama de fluxo e o diagrama de juno de mdulos (SUH, 2001). Um mdulo definido como sendo uma linha da matriz de projeto e contm o requisito funcional (FR) e os parmetros de projeto (DP) que o satisfazem. O diagrama de juno de mdulos representa o relacionamento entre os mdulos atravs dos nveis da hierarquia. Um exemplo de diagrama de juno de mdulos apresentado na Figura 3. Neste diagrama, quando os mdulos aparecem relacionados por um conectivo s, eles so independentes e a matriz de projeto que os relaciona desacoplada. Quando os mdulos esto relacionados por um conectivo c, existe uma relao de controle entre eles, o que significa uma matriz de projeto semi-acoplada (SUH, 2001). FIGURA 3 DIAGRAMA DE JUNO DE MDULO

O diagrama de fluxo permite fazer uma representao da arquitetura do sistema. Esta representao baseada na independncia entre os mdulos. Quando a matriz de projeto desacoplada os mdulos so representados em paralelo, indicando a independncia entre eles, e relacionados pelo conector s, como na Figura 4. Quando a matriz de projeto semi-acoplada existe uma dependncia, que representada colocando

19

os mdulos em seqncia, conectados por c (SUH, 2001). Neste tipo de representao no so consideradas matrizes de projeto acopladas. Neste caso o projeto dever ser modificado. Um exemplo deste tipo de diagrama apresentado na Figura 4. FIGURA 4 DIAGRAMA DE FLUXO

2.3 AXIOMA 2 - AXIOMA DA INFORMAO

O axioma 2 estabelece que o melhor projeto um projeto funcionalmente desacoplado que tem o contedo de informao mnimo (SUH, 1990). Ou, em um enunciado mais simples, o axioma 2 consiste em Minimizar o contedo de informao do projeto (SUH, 1990). O contedo de informao um parmetro importante para a definio de um bom projeto. Segundo SUH (2001), o axioma da informao prov uma medida quantitativa de mrito de um dado projeto, alm de prover uma base terica para a otimizao e robustez do projeto. O contedo de informao pode ser usado como parmetro para auxiliar na deciso de qual conjunto de parmetros de projeto usar para satisfazer um conjunto de requisitos funcionais. Informao a medida do conhecimento requerido para satisfazer um dado FR em um determinado nvel da hierarquia de FR (SUH, 1990, p. 65). Isto significa que quanto

20

mais informao for necessria para satisfazer um requisito funcional, maior ser o contedo de informao. Por exemplo, supondo que uma determinada pea foi projetada para satisfazer o requisito funcional cortar folhas de papel. Se a tolerncia de erro no corte for de um centmetro, no necessria muita preciso no projeto e na fabricao da pea. Mas no caso da tolerncia do corte ser de um centsimo de centmetro, sero necessrios parmetros mais precisos para o projeto da pea, alm de testes mais elaborados e, principalmente, ferramentas de fabricao mais sofisticadas que exigem mais informao para sua operao. Neste caso, o contedo de informao bem maior e a dificuldade de projeto e fabricao tambm. Assim, o contedo de informao est intimamente relacionado com a probabilidade de sucesso no projeto e fabricao de um produto. Esta relao ilustrada em (SUH, 2001), onde dito que o axioma de informao estabelece que o projeto que tem a maior probabilidade de sucesso o melhor projeto. O contedo de informao calculado com base na probabilidade de que o parmetro de projeto (DP) satisfaa o requisito funcional (FR) correspondente. Segundo SUH (1990), sendo p a probabilidade de que o DP satisfaa o FR, o contedo de informao I pode ser calculado como indicado na expresso (8):

1 p

(8)

A expresso (8) mostra que o contedo de informao inversamente proporcional probabilidade de sucesso. Para facilitar o clculo de probabilidades relacionadas, o contedo de informao ser calculado de forma logartmica conforme apresentado em (SUH, 1990).

I log

1 p

(9)

O inverso da probabilidade de sucesso pode ser interpretado de diversas formas. Uma forma de interpret-la como a dificuldade ou complexidade em projetar e construir o

21

produto. Por exemplo, quanto mais precisos forem os requisitos funcionais e restries, mais difcil ser projetar e construir um produto ou pea. Ento, o inverso da probabilidade de sucesso definido em termos da preciso requerida dos parmetros de projeto. Neste caso, um parmetro de projeto pode assumir uma determinada faixa de valores, chamada em (SUH, 1990) de system range. Para este mesmo parmetro de projeto existe uma restrio para que os valores assumidos sejam considerados aceitveis. Esta outra faixa de valores chamada de tolerncia (tolerance). Ento, a dificuldade em projetar e fabricar o produto pode ser considerada em termos da razo entre a faixa de valores que o parmetro pode assumir sobre a faixa de valores aceitveis. Assim, foi proposto em (SUH, 1990) a frmula mostrada na expresso (10) para o clculo do contedo de informao.

log

system range tolerance

(10)

O contedo de informao pode ser calculado como a composio dos contedos de informao dos requisitos funcionais do sistema. Esta composio feita atravs da composio das probabilidades. Como o contedo de informao calculado de forma logartmica, a composio dos contedos de informao dos requisitos funcionais do sistema, se estes forem independentes, pode ser dada como a soma destes contedos2.
n

I
i 1

pi log p i

(11)

Neste caso o clculo do contedo de informao no usa fatores ponderados. Um dos motivos que se forem usados fatores ponderados na soma do contedo de informao, este no representar mais a probabilidade total de sucesso. Tambm considerado que o clculo da informao do requisito funcional (FR) baseado na faixa de variao de projeto deste requisito funcional. Segundo SUH (2001, p 42), Se esta faixa de variao for corretamente especificada, ela j definir a importncia relativa de cada

ver Teorema 13, no anexo 1

22

requisito funcional (FR).

2.4 TRABALHOS RELACIONADOS

Nesta seo sero apresentados trabalhos que se relacionam com a teoria de projeto axiomtico e com projeto de software orientado a objetos, passando por temas como ciclo de vida, decomposio funcional e teoria de projeto. 2.4.1 Projeto axiomtico de software orientado a objetos Um dos primeiros trabalhos envolvendo projeto de software orientado a objetos usando o projeto axiomtico foi apresentado por DO e SUH (1999). Neste trabalho, a teoria axiomtica usada para o desenvolvimento de programas orientados a objetos. proposto que, partindo das necessidades do cliente, deve-se encontrar os componentes a serem implementados, definindo assim as classes e objetos que faro parte do sistema (DO e SUH, 1999). HINTERSTEINER e NAIN (1999) usaram a teoria de projeto axiomtico para o desenvolvimento de software com foco em sistemas integrados de software e hardware. proposta uma metodologia para facilitar o desenvolvimento de software de controle em conjunto com seu hardware correspondente. Cada requisito funcional mapeado em um item do domnio de software e um item do domnio de hardware, o mesmo acontecendo com cada parmetro de projeto. (HINTERSTEINER e NAIN, 1999) Em (SUH e DO, 2000) apresentada uma abordagem para projeto de software orientado a objetos chamada Axiomatic Design of Object-Oriented Software Systems (ADo-oSS). Trata-se de uma abordagem baseada na metodologia OMT (RUMBAUGH et al., 1991). Neste trabalho no so utilizados conceitos da UML (BOOCH, RUMBAUGH, e JACOBSON, 1999) como, por exemplo, casos de uso. apresentado um mapeamento entre a matriz de projeto e o diagrama de classes onde os requisitos funcionais (FRs)

23

representam objetos ou classes, os parmetros de projeto representam os atributos destes objetos e as clulas da matriz representam os mtodos dos objetos (SUH e DO, 2000). O trabalho apresentado em (SUH e DO, 2000) serviu de base para o captulo 5 do livro Axiomatic Design: Advances and Applications (SUH, 2001), onde descrita com detalhes a metodologia ADo-oSS. apresentada com detalhes a utilizao da matriz de projeto, do diagrama de classes, do ziguezagueamento, do diagrama de juno de mdulos e o diagrama de fluxo e as relaes entre estes artefatos. Alm disso, apresentado como estudo de caso o projeto do sistema ACCLARO3. A ferramenta de projeto ACCLARO foi desenvolvida para auxiliar na elaborao de projetos usando a teoria de projeto axiomtico. Ela foi dividida em duas ferramentas, o ACCLARO Designer e o ACCLARO Scheduller. O ACCLARO Designer permite que o projeto de produtos e sistemas seja feito com o auxlio desta ferramenta de software. Permite a decomposio funcional e constri automaticamente a matriz de projeto. Permite, tambm, o rastreamento dos requisitos funcionais devido a mudanas, a anlise de acoplamento do projeto, entre outras caractersticas. O ACCLARO Scheduller uma ferramenta integrada com o IBM Rational Rose4 para gerenciar o andamento do projeto. Permite, entre outras coisas, identificar o impacto das mudanas de projeto, gerar um plano de desenvolvimento para o projeto, estimar custos e identificar possveis gargalos no andamento do projeto. Em (DO, 2004) foi apresentada a utilizao da teoria de projeto axiomtico para o gerenciamento do processo de desenvolvimento de software visando garantir a qualidade do processo e do produto. apresentada uma extenso da teoria de projeto axiomtico, que consiste em domnios complementares. Estes domnios complementares so usados para representar conceitos prprios do domnio do projeto. Um domnio complementar importante o domnio de casos de uso usado para modelar os requisitos funcionais. Alm disso, apresentada a utilizao da matriz de estrutura de projeto (DSM) (ULRICH e EPPINGER,
3 4

ACCLARO marca registrada de Axiomatic Design Software, Inc.. IBM Rational Rose marca registrada de IBM

24

2003) para possibilitar anlises de interdependncia dentro de um mesmo domnio (DO, 2004). 2.4.2 Decomposio funcional Baseado, tambm, na estrutura de informao de NORLUND (1996), TATE e NORLUND (1996) criaram um modelo de ciclo de vida de projeto para o projeto axiomtico. O modelo apresentado contempla caractersticas como tomada de deciso, mtricas de desempenho, iteraes, seqncia de atividades, nveis de abstrao e gerenciamento de informao. O modelo tem como objetivo servir como um guia para qualquer processo de projeto de produto (TATE; NORLUND, 1996). Um requisito funcional pode ser decomposto em sub-requisitos de vrios tipos. Segundo HINTERSTEINER (1999), eles podem ser classificados em funes de processo, de comando e controle, e de suporte e integrao. As funes de processo efetuam o processamento propriamente dito dos operandos alm de prover o transporte destes atravs do sistema. As funes de comando e controle representam a lgica necessria para coordenar os diferentes processos no subsistema. As funes de suporte e de integrao mantm o subsistema funcionando de forma coordenada (HINTERSTEINER, 1999). Em (TATE, 1999) foi definida uma seqncia de etapas a serem consideradas para realizar as decomposies funcionais durante um projeto. Alm disso, foram definidas restries a serem consideradas para manter a coerncia entre as decomposies, nos diversos nveis da hierarquia funcional, durante o processo de ziguezagueamento (TATE, 1999). Essas restries dizem respeito escolha apropriada dos sub-requisitos funcionais (sub-FR) de tal forma que a matriz de projeto mantenha o mesmo grau de acoplamento do nvel anterior. Em outras palavras, se a matriz de projeto do nvel anterior era desacoplada, ela manter essa caracterstica no prximo nvel. Em (SCHREYER e TSENG, 2000) apresentada uma notao para representar a decomposio funcional e o processo de ziguezagueamento. Esta notao baseada nos statecharts apresentados em (HAREL, 1987). Esta notao ajuda a identificar estados

25

principais, alm de outros parmetros importantes, como tempo, sinais de sensores e informao de memria compartilhada. apresentada a matriz de transies de estados, que relaciona as condies de entrada com as aes de sada para cada estado (SCHREYER e TSENG, 2000). Em (CAPPETTI, NADDEO e PELLEGRINO, 2004) apresentada uma metodologia para reduzir o acoplamento da matriz de projeto. Esta metodologia baseada na lgica Fuzzy e na teoria da representao (ZADEH, L. A. et al., 1974). proposto que associando-se valores de funo de pertinncia para cada clula da matriz de projeto, possvel reduzir o grau de dependncia entre parmetros de projeto (DP) e requisitos funcionais (FR). Com Isto possvel reduzir o grau de acoplamento da matriz de projeto, otimizando um projeto acoplado, quando no possvel obter um projeto desacoplado (CAPPETTI, NADDEO e PELLEGRINO, 2004). 2.4.3 Tpicos Gerais em Teoria de Projeto Em (NORLUND, 1996) foi estabelecida uma estrutura de informao para o projeto axiomtico. Esta estrutura de informao permite identificar quais as fontes de informao que o projetista ir usar durante o processo de projeto axiomtico e como a informao obtida durante o processo pode ser usada nos estgios finais do projeto (NORLUND, 1996). HARUTUNIAN; NORLUND e TATE (1996) estudaram a tomada de decises de projeto baseada na teoria de projeto axiomtico usando a estrutura de informao de projeto apresentada em (NORLUND, 1996) e criaram um software de desenvolvimento de produtos que usa a teoria de projeto axiomtico para tomar decises de projeto. Quando decises de projeto so tomadas, podem surgir conseqncias para estas decises. Segundo LINDHOLM, TATE e HARUTUNIAN (1999) estas conseqncias podem gerar a necessidade de subsistemas adicionais ao produto. Por exemplo, se um parmetro de projeto escolhido gera calor como conseqncia, aparecer a necessidade de um subsistema de resfriamento. Em (LINDHOLM, TATE e HARUTUNIAN, 1999) foi apresentada

26

uma classificao das conseqncias, em conseqncias originadas de parmetros de projeto, de variveis de processo ou da configurao. Alm disso, foi apresentado um processo para identificar estas conseqncias e gerenci-las (LINDHOLM, TATE e HARUTUNIAN, 1999). Em On a Mathematical Foundation of Axiomatic Design, RUDOLPH (1996) derivou a teoria de projeto axiomtico com um caso especial da chamada hiptese de avaliao. A hiptese de avaliao baseada na tcnica de anlise dimensional conhecida da fsica e que permite a derivao direta de expresses que em casos especiais correspondem aos axiomas de independncia e informao (RUDOLPH, 1996). Em (SHIN et al., 2004) so apresentadas formas de se calcular o contedo de informao de um projeto. So apresentados dois mtodos, o mtodo grfico, para projetos com dois requisitos funcionais e o por integrao, para projetos com mais de dois requisitos funcionais. O clculo feito com base na associao entre o system range e o functional range. O mtodo grfico usa uma distribuio uniforme de probabilidade para a associao. No mtodo por integrao podem ser usados quaisquer tipos de distribuio de probabilidade (SHIN et al., 2004).

27

3 METODOLOGIA DE DESENVOLVIMENTO PROPOSTA

Neste captulo feita a descrio da metodologia de projeto de software proposta neste trabalho. apresentada uma analogia entre os conceitos da teoria de projeto axiomtico e os conceitos de projeto de software orientado a objetos usando UML. feita uma descrio dos domnios complementares que sero usados nesta metodologia, em adio aos domnios do projeto axiomtico. Ento apresentada uma descrio de cada uma das etapas da metodologia indicando os artefatos originados e as aes a serem executadas.

3.1 RELACIONAMENTO ENTRE PROJETO AXIOMTICO E PROJETO DE SOFTWARE

Como apresentado no captulo anterior, a teoria de projeto axiomtico uma teoria que se aplica a todo o tipo de projeto, desde o projeto de um carro at o projeto de um departamento acadmico (SUH, 2001). Para a sua aplicao no desenvolvimento de software orientado a objetos, existe a necessidade de se estabelecer uma relao entre os principais conceitos do projeto axiomtico e os principais conceitos de projeto de software. Na Figura 5 so mostradas estas relaes. No projeto axiomtico existem quatro domnios principais que podem ser entendidos no projeto de software como sendo o modelo ou conjunto de modelos que esto sendo desenvolvidos em cada fase. De acordo com a Figura 5, o domnio do cliente, que representa as necessidades do cliente no projeto axiomtico, corresponde ao modelo do negcio (business model) do projeto de software. O domnio funcional, que representa os requisitos funcionais, corresponde especificao de requisitos no projeto de software. O domnio fsico, que representa os parmetros de projeto, corresponde aos modelos de projeto de software,

28

como modelo de classes, modelo de interaes e modelo de estados. O domnio de processo representa as variveis de processo que correspondem aos modelos relativos implementao e implantao, como o cdigo fonte. FIGURA 5 RELAO ENTRE CONCEITOS DO PROJETO AXIOMTICO E DE PROJETO DE SOFTWARE

Alm das correspondncias entre os domnios e os modelos, existe a correspondncia entre as fases do processo de desenvolvimento e os mapeamentos (ziguezagueamento) entre os domnios. O mapeamento entre os domnios do cliente e funcional corresponde, no projeto de software, atividade de anlise de requisitos. Nesta atividade, as necessidades dos clientes, usurios e stakeholders (BITTNER e SPENCE, 2003) so identificadas e mapeadas em requisitos funcionais e requisitos no funcionais. Segundo LEFFINGWELL e WIDRIG (2003), o modelo do negcio usado para auxiliar na definio do sistema e suas aplicaes. O negcio representa o conjunto das atividades, entidades e seus relacionamentos para os quais o sistema computacional ser implementado. O mapeamento entre os domnios funcional e fsico corresponde atividade de

29

projeto propriamente dito. Nesta atividade, partindo dos requisitos funcionais do sistema, so identificados os parmetros de projeto que satisfazem estes requisitos. A especificao de requisitos de um sistema usada para definir quais funcionalidades o sistema dever oferecer e, tambm, serve de base para validaes e testes. A partir dos requisitos funcionais identificados so construdos os parmetros de projeto. Estes parmetros podem ser processos, classes, objetos, funes, estados. Neste caso, cada parmetro de projeto pode estar relacionado com um ou mais requisitos funcionais. O mapeamento entre o domnio fsico e de processo corresponde atividade de implementao. Os parmetros de projeto, classes, objetos, interaes e estados so usados como base para a implementao do software.

3.2 DOMNIOS COMPLEMENTARES

Os domnios bsicos do projeto axiomtico no so suficientes para representar todas as informaes utilizadas em um projeto de software que utiliza o processo unificado (JACOBSON, BOOCH e RUMBAUGH, 1999). De acordo com (DO, 2004) podem ser adicionados domnios complementares ao processo. Estes domnios representam caractersticas e informaes especficas da natureza do projeto. No caso de projeto de software sero usados os domnios de casos de uso, de classes, de estados e de interaes. Os domnios complementares sero usados em conjunto com os domnios bsicos do projeto axiomtico. Pela importncia do mapeamento entre o domnio funcional e o fsico, como sugerido em (DO, 2004), estes dois domnios sero tratados como domnios abstratos e o mapeamento entre eles ser usado para a aplicao dos axiomas 1 e 2 (SUH, 1990) e dos principais conceitos do projeto axiomtico. Para isso ser feito um mapeamento direto entre estes domnios e os domnios complementares. De acordo com a Figura 6 sero utilizados os seguintes domnios

30

complementares: o domnio de casos de uso, o domnio de classes, o domnio de interaes e o domnio de estados. O domnio de casos de uso ser composto pelo modelo de casos de uso (JACOBSON, BOOCH e RUMBAUGH, 1999). O modelo de casos de uso formado pelo diagrama de casos de uso e as especificaes de caso de uso, e usado para identificar os requisitos funcionais do sistema. O domnio de classes formado pelo diagrama de classes. Este domnio representa aspectos estruturais das classes do sistema, como as classes, seus atributos, seus mtodos e os relacionamentos entre elas (BOOCH, RUMBAUGH, e JACOBSON, 1999). O domnio de interaes formado principalmente pelos diagramas de seqncia. Este domnio representa principalmente a interao entre os objetos do sistema de forma a satisfazer as funcionalidades desejadas. O domnio de estados formado pelos diagramas de estado. Este domnio representa as mudanas de estados dos objetos do sistema causadas, entre outros, pelas interaes entre os objetos. Os domnios de classes, interaes e estados sero usados como auxlio na representao dos parmetros de projeto. FIGURA 6 DOMNIOS COMPLEMENTARES SUGERIDOS

31

O mapeamento entre os domnios do cliente e funcional ser feito atravs do domnio de casos de uso, como sugerido por DO (2004). Neste caso haver uma relao direta entre cada requisito funcional (FR) do domnio funcional e um caso de uso do domnio de casos de uso. Os requisitos funcionais sero mapeados em casos de uso, subcasos de uso, atividades e servios tcnicos. FIGURA 7 DOMNIOS DE CLASSES, DE INTERAES E DE ESTADOS

Os parmetros de projeto sero mapeados em colaboraes, sub-colaboraes que so decompostas at atingir o nvel onde sero representados os objetos que fazem parte da colaborao. Este mapeamento ser feito usando a matriz de projeto. Nesta matriz

32

cada uma das clulas representar um item de projeto que composto por um conjunto de parmetros resultantes da composio das vises esttica (domnio de classes) dinmica (domnio de estados) e de interao (domnio de seqncia). A relao entre o mapeamento dos requisitos funcionais em parmetros de projeto e os domnios de classes, de interaes e de estados est ilustrada na Figura 7.

3.3 DESCRIO DAS ETAPAS DA METODOLOGIA PROPOSTA

Nesta seo ser feita uma descrio das etapas da metodologia de desenvolvimento de software proposta neste trabalho. Esta descrio ser feita com base nas atividades executadas durante o processo de desenvolvimento de software. As etapas so basicamente as atividades de mapeamento entre os domnios do projeto, incluindo os domnios bsicos do projeto axiomtico e os domnios complementares prprios do projeto de software. Neste trabalho sero consideradas trs etapas: o mapeamento entre os domnios do cliente e funcional, o mapeamento entre os domnios funcional e fsico e o mapeamento entre o domnio fsico e de processo. Fazendo-se uma analogia com o processo unificado, o mapeamento entre os domnios do cliente e funcional corresponde fase de elaborao, a fase de construo corresponde aos mapeamentos entre os domnios funcional e fsico e entre o domnio fsico e de processo. 3.3.1 Mapeamento entre domnios do cliente e funcional Na primeira etapa so identificados os requisitos funcionais (FR) a partir das necessidades dos clientes (CN). Esta etapa corresponde anlise de requisitos em um processo de desenvolvimento software convencional. As necessidades dos clientes podem ser representadas atravs do modelo de negcio. Com este tipo de modelo possvel representar o processo a ser automatizado e como este se enquadra no processo da organizao. O modelo de negcio permite avaliar como o futuro software ir afetar os

33

usurios e o negcio em si (LEFFINGWELL e WIDRIG, 2003). Segundo apresentado em (DO, 2004), o modelo do processo axiomtico recomenda que seja estabelecido um domnio de casos de uso para modelar os aspectos dinmicos dos requisitos em software. Segundo apresentado em (SUH, 1990), os requisitos funcionais (FR) so definidos como sendo o conjunto mnimo de requisitos independentes que caracterizam completamente o objetivo do projeto para uma necessidade especfica. Uma forma de se encontrar um conjunto mnimo de requisitos funcionais independentes atravs dos casos de uso. Estes requisitos funcionais so identificados a partir das necessidades do cliente e/ou dos stakeholders. Entre as necessidades dos clientes so encontrados requisitos no funcionais, requisitos funcionais e restries. A decomposio baseada em casos de uso permite que sejam identificadas as principais funcionalidades do sistema (servios desejados), separando-as de requisitos funcionais de menor importncia. 3.3.2 Mapeamento entre domnios funcional e fsico. A partir do momento em que os requisitos funcionais estejam identificados como casos de uso e validados com o cliente, dado incio etapa que, segundo apresentado em (SUH, 1990), corresponde atividade de projeto propriamente dita. Esta etapa o mapeamento entre o domnio funcional e o domnio fsico. Como visto anteriormente, este mapeamento feito a partir dos requisitos funcionais (FR), obtendo-se os parmetros de projeto (DP). A decomposio funcional realizada nesta etapa ser dividida em nveis, de acordo com o tipo de resultado da decomposio. A cada nvel de decomposio podem ser feitas quantas decomposies forem necessrias para que o projeto seja satisfeito para este nvel de abstrao. Cada nvel ser caracterizado pelo tipo de resultado da decomposio. No primeiro nvel so obtidos os casos de uso. No segundo nvel so obtidos os subcasos de uso. No terceiro, so obtidas as atividades e no quarto nvel, os servios tcnicos. Na metodologia proposta neste trabalho a decomposio funcional ser feita de acordo com as caractersticas de um projeto de software. No primeiro nvel de

34

decomposio so feitas decomposies at que todos os casos de uso sejam identificados. A partir dos casos de uso, identificados na etapa anterior, so realizadas decomposies funcionais de forma a obter os subcasos de uso no segundo nvel de decomposio. A partir dos subcasos de uso, so realizadas decomposies e chega-se ao terceiro nvel de decomposio onde so obtidas as atividades, ou segundo a definio apresentada em (BOOCH, RUMBAUGH, e JACOBSON, 1999), o chamado fluxo de eventos. De cada atividade so efetuadas decomposies funcionais e so encontradas funes de servio (STADZISZ, 1997) ou, como sero chamados neste trabalho, os servios tcnicos. Este o quarto nvel de decomposio. A teoria de projeto axiomtico prope que a decomposio seja feita em amplitude (SUH, 2001). Isto significa que antes de ser efetuada uma decomposio funcional, todos os parmetros de projeto deste nvel j devero ter sido identificados e mapeados na matriz de projeto. A decomposio pode ser realizada tambm em profundidade. Isto significa que um caso de uso pode ser decomposto at que seja atingido o nvel de servios tcnicos, sem a necessidade da decomposio dos outros casos de uso ter sido realizada. Este fato impede que a matriz de projeto completa de cada nvel de decomposio seja obtida, mas podem ser obtidas matrizes parciais, para cada ramo da rvore de hierarquia funcional, a cada nvel, que serviro para avaliar parcialmente a independncia funcional. Esta avaliao parcial pode ser til j que no primeiro nvel foram identificadas as dependncias funcionais entre os casos de uso, e esta dependncia ser refletida na decomposio. 3.3.2.1 Primeiro nvel de decomposio. Neste nvel de hierarquia esto os casos de uso representando os requisitos funcionais (FRs). Ento, para cada requisito funcional (FR) sero identificados os parmetros de projeto (DPs) correspondentes, que neste caso ser representado por uma colaborao. De acordo com a UML 2.0 (OBJECT MANAGEMENT GROUP, 2003) uma colaborao descreve uma estrutura de elementos (papis) que colaboram entre si para

35

realizar uma determinada funcionalidade. A colaborao til, pois seus detalhes podem ser mostrados ou ocultados dependendo do nvel de abstrao desejado. Para este nvel, uma colaborao ir representar toda uma estrutura de papis para realizar um caso de uso. Esta estrutura pode ser decomposta em sub-colaboraes em outros nveis. Com esse mapeamento obtm-se uma matriz de projeto onde as linhas representam casos de uso e as colunas representam colaboraes. Quando este mapeamento feito, so identificadas algumas relaes entre os casos de uso (FR) que no so identificadas durante a decomposio funcional. Por exemplo, um caso de uso mostrar relatrio com os dados do cliente dependente de um outro caso de uso cadastrar cliente. Isto indica uma relao de dependncia de projeto. Esta dependncia resolvida no processo unificado (JACOBSON, BOOCH e RUMBAUGH, 1999), de maneira informal, atravs de uma ordenao de prioridades dos casos de uso (LARMAN, 1997). TABELA 1 MATRIZ DE PROJETO DE PRIMEIRO NVEL
Colaborao consultar relatrios gerenciais t Colaborao consultar relatrios de ponto X X

Colaborao cadastrar empregado 1.1 Cadastrar Empregado 1.2 Registrar Ponto 1.3Consultar relatrios gerenciais de ponto 1.4 Consultar relatrios de Ponto X R R R

X R R

Esta dependncia entre casos de uso assinalada na matriz de projeto, como na Tabela 1. Como exemplo mostrado na 0 o modelo de casos de uso identificados para um sistema de registro de pontos. Para este sistema, neste nvel de decomposio funcional,

Colaborao registrar ponto

36

construda a matriz de projeto, na qual as linhas representando os casos de uso e as colunas representando colaboraes. Esta matriz de projeto mostrada na Tabela 1. FIGURA 8 CASOS DE USO DE UM SISTEMA DE REGISTRO DE PONTOS

Na matriz de projeto da Tabela 1, o smbolo R representa que uma determinada FR ir usar na colaborao (DP) uma classe (papel da colaborao) j usada em outra colaborao. No caso ilustrado na Tabela 1, para se fazer o projeto do caso de uso registrar ponto necessrio que dados da colaborao cadastrar empregado j estejam definidos. Ou seja, existe uma dependncia de projeto entre os dois casos de uso. Portanto, haver a necessidade de existir uma ordem na qual os casos de uso sero implementados, que resultante do fato da matriz de projeto ser semi-acoplada. 3.3.2.2 Segundo nvel de decomposio No 2o nvel de decomposio, so identificados o que ser chamado neste trabalho de subcasos de uso. No nvel hierrquico anterior tem-se casos de uso, servios completos prestados pelo sistema aos atores. Cada um destes servios pode ser

37

decomposto em unidades de servio chamadas subcasos de uso. Um subcaso de uso um servio prestado pelo sistema, que no completo e est incluso em algum caso de uso. uma parte da funcionalidade do caso de uso. Nem todos os casos de uso sero decompostos em subcasos, pois apresentam apenas uma funcionalidade menor, como se pode ver na Figura 9. FIGURA 9 SUBCASOS DE USO

Na Tabela 2 apresentada a matriz de projeto referente ao segundo nvel da hierarquia funcional para o exemplo apresentado na Figura 9. Nesta tabela possvel ver que existe uma dependncia funcional entre alguns subcasos de uso. Por exemplo, o subcaso de uso entrar dados de empregado mapeado para a colaborao entrar dados de empregado que usa o mesmo papel que a colaborao gravar empregado. Esta dependncia est de acordo com o mapeamento do nvel anterior, apresentado na Tabela 1.

38

TABELA 2 MATRIZ DE PROJETO DE 2O. NVEL

Colaborao consultar relatrios gerenciais ponto X X

Colaborao entrar dados de empregado

Colaborao entrar dados de ponto

1.1.1 entrar dados de empregado 1.1.2 gravar empregado 1.2.1 entrar dados de ponto 1.2.2 gravar ponto 1.3.1Consultar relatrios gerenciais de ponto 1.4.1 Consultar relatrios de Ponto

X R R R R R

X X R R R X

3.3.2.3 Terceiro nvel de decomposio Os fluxos de eventos so uma forma de descrever os casos de uso (BOOCH, RUMBAUGH e JACOBSON, 1999). Eles descrevem os passos de interao que ocorrem entre o sistema e o ator. Cada um destes passos corresponde a uma ao do ator sobre o sistema e a reao do sistema a esta ao. O conjunto destes eventos pode ser representado por um fluxo, ou um diagrama de atividades. Neste nvel de decomposio cada requisito funcional ser representado por uma atividade. As decomposies sero feitas da seguinte forma. Para cada subcaso de uso encontrado no nvel anterior sero identificadas as atividades correspondentes. Estas atividades so identificadas atravs da descrio da interao do ator com o sistema. Estas atividades podero ser decompostas enquanto for necessrio para este nvel de abstrao. No exemplo apresentado na Tabela 2, o subcaso de uso Entra dados de Empregado (1.1.1) pode ser decomposto no seguinte fluxo de atividades: 1.1.1.1

Colaborao consultar relatrios

Colaborao gravar empregado

Colaborao gravar ponto

39

selecionar a opo inserir; 1.1.1.2 receber dados do empregado; 1.1.1.3 confirmar dados digitados. Esta decomposio pode ser representada pelo diagrama de atividades da Figura 10. FIGURA 10 DIAGRAMA DE ATIVIDADES PARA O SUBCASO DE USO ENTRAR DADOS DE EMPREGADO

Neste nvel de decomposio, cada atividade ser mapeada em uma subcolaborao da colaborao anterior. Formando uma matriz de projeto que representar nas linhas as atividades e nas colunas as colaboraes correspondentes. Novamente, as dependncias funcionais tm que estar de acordo com as dependncias nos nveis anteriores para manter a consistncia no processo de decomposio (TATE, 1999). 3.3.2.4 Quarto nvel de decomposio Logo aps a identificao de todas as atividades (FR) e respectivas colaboraes (DP) para cada atividade, so identificados os servios tcnicos (FR) resultados da decomposio da atividade em sub-requisitos. Para cada servio tcnico encontrado um parmetro de projeto (DP) que um objeto usado para satisfazer o requisito funcional (FR). A clula FR x DP corresponde a uma tripla que composta de um elemento do domnio de interao, um do domnio de classes e um do domnio de estados. Para definir um servio tcnico ser usada a definio de funo de servio (STADZISZ, 1997). Segundo STADZISZ (1997), Uma funo de servio exprime uma ao esperada do produto sobre um elemento do meio exterior, em benefcio de outro elemento deste meio, dentro de uma fase de utilizao. Se um objeto do sistema for considerado

40

como um produto e os outros objetos, com os quais interage, seu meio externo, ento, um servio tcnico um servio esperado de um objeto por outro, para realizar a colaborao. Um requisito funcional pode ser decomposto em sub-requisitos de vrios tipos. Segundo HINTERSTEINER (1999), eles podem ser classificados em funes de processo, de comando e controle, e de suporte e integrao. Esta classificao similar aos conceitos da arquitetura Modelo-Viso-Controlador (MVC) (KRASNER e POPE, 1988) (PRESSMAN, 2004) que pode ser usado como base para a decomposio neste nvel. No caso de sistemas de software, so encontrados trs tipos de funcionalidades. Em uma atividade so comumente encontradas funcionalidades para trocar informaes entre o sistema e atores (humanos ou no), funcionalidades para manipular os dados do sistema e funcionalidades para controlar o processo realizado na atividade. Devido a este fato, pode-se representar cada uma destas funcionalidades como sendo um servio tcnico que, a rigor, um requisito funcional de um nvel hierrquico mais baixo. Neste trabalho, os servios tcnicos sero classificados nas seguintes categorias: servios tcnicos de fronteira; servios tcnicos de entidade; servios tcnicos de controle;

Servios tcnicos de fronteira so servios para fazer a interface do sistema com os atores. Servios tcnicos de entidade so servios para manipular as informaes do sistema. Servios tcnicos de controle so servios para controlar o processo realizado na atividade. Na metodologia apresentada neste trabalho, a decomposio funcional de uma atividade ser feita identificando-se os servios tcnicos de fronteira, controle e entidade que compem a atividade. Por exemplo, para a atividade receber dados de empregado, sero identificados os servios tcnicos mostrar formulrio e receber dados usurio. Para cada servio tcnico identificado sero escolhidos os parmetros de projeto que sero variveis (objetos) que participam da colaborao identificada no nvel anterior.

41

Com o mapeamento FR x DP, cada servio tcnico ser mapeado em um objeto. De acordo com PRESSMAN (2004) um objeto que executa servio de fronteira recebe o esteretipo de <<fronteira>>, o que executa servios de entidade recebe o esteretipo <<entidade>> e o que executa servios de controle recebe o esteretipo <<controle>>. TABELA 3 MATRIZ DE PROJETO DE 4O. NVEL
? ? ? DP 1 2 1 1 2 colaborao Iniciar leitor barras 3 colaborao mostrar cdigo lido 4 consulta tabela emprstimos 5 tela confirmao emprstimo 6 consulta tabela emprstimos

varivel nmero de atrasos

consulta tabela exemplar

Interface banco de dados

consulta tabela usurio

tela de escolha de opo

tela receber id exemplar

colaborao ler cdigo

FR?.?.? - conectar com a base de FR1.2.1.1.1 - mostrar tela escolha FR1.2.1.1.2 - receber opo FR1.2.1.2.1 - mostrar tela receber id exemplar FR1.2.1.2.2 - receber id exemplar FR1.2.1.3.1 - Iniciar leitor de cod barras FR1.2.1.3.2 ler cdigo FR1.2.1.3.3 - mostrar cdigo lido FR1.2.1.4.1 - mostrar tela receber id usurio FR1.2.1.4.2 - receber id usurio FR1.2.1.5.1 - buscar dados Usurio FR1.2.1.5.2 - receber busca dados Usurio FR1.2.1.5.3 - verificar na base emprstimos atrasados FR1.2.1.5.4 - receber busca emprstimos atrasados FR1.2.1.5.5 - buscar dados exemplar FR1.2.1.5.6 - receber busca dados exemplar FR1.2.1.5.7 - buscar dados obra FR1.2.1.5.8 - receber busca dados obra FR1.2.1.5.9 - mostrar tela confirmao FR1.2.1.5.10 - receber confirmao FR1.2.1.6.1 - gravar dados de emprstimo na base FR1.2.1.6.2 - mostrar mensagem de sucesso

X X

X X X X X X X X X X X X X X X X R R X R X X X R X X X X X X X X X X X X X

A matriz de projeto resultante ter representado nas linhas os servios tcnicos e nas colunas os objetos (variveis) que iro execut-los. Como exemplo, na Tabela 3 o

tela sucesso gravao

tela receber id usurio

consulta tabela obra

varivel confirmao

varivel exemplar

varivel usurio

varivel usurio

varivel opo

varivel obra

exemplar

42

servio tcnico receber id usurio (FR 1.2.1.4.2) mapeado no parmetro de projeto varivel usurio (DP 1.2.1.4.2). Nesta forma de mapeamento, quando uma varivel (objeto) usada em mais de um requisito funcional (FR), esta relao marcada com um X. Quando no o mesmo objeto, mas uma outra instncia da mesma classe aparece em outro requisito funcional (FR), esta relao marcada com um R. Ento, das relaes X e R pode-se concluir em quais requisitos funcionais (FRs) aparecem objetos de uma classe. Com isso, pode-se identificar as principais utilizaes de cada objeto e seus mtodos principais. Na clula da matriz de projeto que representa o mapeamento FR x DP representado no apenas o mtodo chamado, mas uma tripla. Esta tripla (interao, estrutura, mudana de estado) representa uma composio das vises interativa, estrutural e dinmica do projeto. Estas vises esto de acordo com a diviso da modelagem em estrutural e comportamental, proposta em (BOOCH, RUMBAUGH, e JACOBSON, 1999). Cada tripla representa a interao onde o envio da mensagem realizado, para qual objeto feito, a mudana na estrutura da classe que o envio da mensagem acarreta e a mudana de estados do objeto que este envio ocasiona. A representao destas vises na forma de uma clula resultante do mapeamento FR x DP permite que seja feito o rastreamento do local de utilizao de cada mtodo e, seja visualizado qual o efeito de cada chamada deste mtodo. Alm disso, permite que todos os mtodos sejam rastreados segundo os requisitos funcionais que eles satisfazem. Este tipo de rastreamento se torna importante em projetos grandes e de risco. Aps o mapeamento do servio tcnico e da varivel (objeto) correspondente na matriz de projeto, os elementos da tripla sero representados nos respectivos diagramas. O envio da mensagem para o objeto correspondente ser representado em um diagrama de seqncia. A definio do mtodo, correspondente ao envio dessa mensagem, ser representada no diagrama de classes. O envio da mensagem para o objeto ir ocasionar a mudana de estado do objeto. Esta mudana de estado ser representada no diagrama de

43

estados para o objeto. Para ilustrar esta representao ser apresentada como exemplo a decomposio da atividade confirmar emprstimo referente a um sistema de gerenciamento de bibliotecas. Esta atividade resultante da decomposio de terceiro nvel de um subcaso de uso, representada na Figura 11. FIGURA 11 DIAGRAMA DE ATIVIDADES DA DECOMPOSIO DO SUBCASO EMPRESTAR EXEMPLAR

A decomposio da atividade confirmar emprstimo (1.2.1.6) resulta nos servios tcnicos criar novo emprstimo (FR 1.2.1.6.1), gravar dados do emprstimo na base (FR 1.2.1.6.2) e imprimir comprovante emprstimo (FR 1.2.1.6.3). Estes servios tcnicos sero mapeados nos seus respectivos parmetros de projeto que so: varivel emprstimo (DP 1.2.1.6.1), varivel consulta tabela emprstimo (DP 1.2.1.6.2) e varivel interface com a impressora (DP 1.2.1.6.3). Este mapeamento est representado em uma matriz de projeto parcial, ilustrada na Tabela 4.

44

TABELA 4 MATRIZ DE PROJETO REFERENTE DECOMPOSIO DE CONFIRMAR EMPRSTIMO

DP 1.2.1.6.3 varivel interface com a impressora X DP 1.2.1.6.2 - varivel de consulta tabela emprstimo X

FR 1.2.1.6.1 criar novo emprstimo FR 1.2.1.6.2 gravar dados do emprstimo na base FR 1.2.1.6.3 imprimir comprovante emprstimo

O servio tcnico gravar dados do emprstimo na base (FR 1.2.1.6.2) utiliza o parmetro de projeto varivel consulta tabela emprstimo (DP 1.2.1.6.2). Para representar os envios de mensagens referentes colaborao confirmar emprstimo (DP 1216) feito um diagrama de seqncia para esta colaborao. Neste diagrama representado o envio da mensagem gravarEmprestimo(emprestimo) referente ao mapeamento do servio tcnico gravar dados do emprstimo na base, ilustrado no diagrama de seqncia da Figura 12. FIGURA 12 ENVIO DE MENSAGEM REFERENTE A FR12162 X DP12162

O mapeamento do servio tcnico gravar dados do emprstimo na base, alm do envio da mensagem gravarEmprestimo(emprstimo) deve produzir a descrio de um

DP 1.2.1.6.1 - varivel emprstimo X X

45

mtodo novo no diagrama de classes. Esta descrio est representada no diagrama da Figura 13. Mesmo no caso da utilizao de um mtodo que j existe, a tripla representa que este mtodo est sendo usado para satisfazer o requisito funcional gravar dados do emprstimo na base (FR 1.2.1.6.2). FIGURA 13 DEFINIO DE MTODO REFERENTE A FR12162 X DP12162

Na tripla tambm representada a mudana de estado que o envio da mensagem gravarEmprestimo(emprstimo) causa no objeto IntBD. Esta mudana de estados representada no diagrama de estados da classe IntBD apresentado na Figura 14.

46

FIGURA 14

MUDANA DE ESTADO DO OBJETO INTBD REFERENTE CLULA FR12162 X DP12162

3.3.3 Mapeamento entre domnios fsico e de processo. A diferena bsica entre as variveis do domnio fsico e as do domnio de processo que as primeiras tm um nvel de abstrao e uma importncia maior para o projeto, so independentes de plataforma de implementao e normalmente representam objetos globais. As variveis do domnio de processo so normalmente variveis que existem em um nvel de abstrao menor, so usadas para realizar os parmetros de projeto e normalmente representam variveis locais. A decomposio dos requisitos funcionais pode ser feita at o nvel de abstrao desejado no projeto. Este nvel atingido, nesta metodologia, quando so obtidos os servios tcnicos. Apesar disso, esses servios tcnicos podem ser decompostos em subservios e assim por diante at que seja atingido o nvel equivalente a uma linha de cdigo do sistema. Esta decomposio pode parecer excessiva a princpio, mas quando exigido que o projeto tenha a capacidade de rastrear cada item da implementao com relao aos requisitos funcionais, ela se torna muito til. Esta capacidade de rastreamento particularmente til quando so feitos testes no sistema.

47

Segundo LEFFINGWELL e WIDRIG (2003) a experincia tem mostrado que a habilidade de rastrear os artefatos de requisitos atravs dos estgios de especificao, arquitetura, projeto, implementao e testes um fator significativo em assegurar a qualidade da implementao do software. Testes em sistemas de software podem ser feitos de varias formas. A forma mais comum a feita com base nos casos de uso (test cases) (BITTNER e SPENCE, 2003). Este tipo de teste requer que o trecho de cdigo se deseja corrigir seja rastreado a partir do erro encontrado na utilizao do sistema (requisito funcional).

3.4 -CLCULO DO CONTEDO DE INFORMAO

Durante o processo de desenvolvimento o contedo de informao calculado. Este contedo definido com sendo a probabilidade do projeto no satisfazer os requisitos funcionais. Segundo o axioma dois (SUH, 1990) e alguns teoremas e corolrios relacionados, quanto menor o contedo de informao melhor ser o projeto (SUH, 1990). O contedo de informao normalmente calculado quando se est fazendo o mapeamento entre o domnio fsico e o de processo, mas ele pode ser calculado a qualquer etapa do desenvolvimento. A utilidade do clculo do contedo permitir que seja possvel identificar, entre solues possveis para o problema proposto, que tenham independncia funcional, qual delas a melhor soluo. Por exemplo, quando se est fazendo uma decomposio em um determinado nvel e aparecem duas decomposies possveis, pode-se decidir qual delas adotar. Apesar da frmula para o clculo do contedo de informao ser independente do domnio do problema (SUH, 1990), seus parmetros devem ser adaptados para o projeto de software. Esta adaptao ser estudada no prximo captulo.

48

4 MEDIDA DE CONTEDO DE INFORMAO PARA SISTEMAS DE SOFTWARE

Neste captulo so definidos os parmetros para o clculo do contedo de informao para projetos de software. Para esta definio sero usadas mtricas de projeto de software. Estas mtricas refletem a complexidade referente ao projeto e a complexidade referente implementao do sistema computacional. As mtricas adotadas consideram as seguintes caractersticas: nmero e complexidade dos diagramas de projeto, tamanho do cdigo (Linhas de cdigo), complexidade do algoritmo, nmero de chamadas a outros mdulos (mtodos) dentro de um mtodo, nmero de parmetros recebidos por um mtodo, nmero e complexidade de tabelas, nmero e complexidade das telas e outros aspectos que influenciam no projeto e construo do software.

4.1 CONTEDO DE INFORMAO DE SISTEMAS COMPUTACIONAIS

As medidas de contedo de informao costumam levar em considerao faixas de valores que as variveis de projeto podem atingir ou a probabilidade de que estas faixas de valores estejam dentro de uma tolerncia. Em termos de projeto de software, as necessidades so diferentes, a variabilidade das variveis de projeto em termos de valores no tem uma importncia to grande como a complexidade destas variveis. Devido a essa diferena, sero estabelecidas medidas de contedo de informao baseada em medidas de complexidade de componentes de sistemas de software que possam ser aplicadas nos diversos nveis de decomposio de um projeto. O contedo de informao calculado a cada decomposio dos requisitos funcionais (FRs). Isto se deve ao fato de que necessrio verificar se os sub-requisitos funcionais (sub-FRs) encontrados e os parmetros de projeto (DPs) correspondentes

49

satisfazem os axiomas 1 e 2. Alm disso, o clculo do contedo de informao mostra a vantagem da escolha de um conjunto de sub-requisitos funcionais (sub-FRs) ao invs de um outro conjunto atravs do axioma 2 (SUH, 1990). No caso, se os dois conjuntos de subrequisitos funcionais (sub-FR) tiverem independncia funcional, o melhor conjunto o que possuir o menor contedo de informao. Como visto anteriormente o contedo de informao pode ser calculado pela frmula em (10). No caso de sistemas computacionais, ser feita uma adaptao destes conceitos. O clculo do contedo de informao ser feito com base no tamanho e na complexidade do sistema. Os sistemas computacionais, em sua grande maioria, ainda so projetados e construdos manualmente. No uma mquina ou sistema computacional que ir construir o software. Portanto, o fator humano deve ser levado em considerao quando o inverso da probabilidade de sucesso calculado. Por esta razo, neste trabalho, o valor da tolerncia ser calculado atravs de uma estimativa de complexidade baseada em registros da complexidade de sistemas construdos anteriormente pela organizao. Isto ser feito pelo fato de que se o valor de complexidade obtido for maior que a estimativa feita com base no registro histrico da organizao, a probabilidade da construo do software ser mais difcil para esta organizao maior.

4.2 CONTEDO DE INFORMAO NOS NVEIS DE DECOMPOSIO

O contedo de informao ser medido a cada decomposio dos requisitos funcionais (FRs). Segundo a metodologia de desenvolvimento adotada, as decomposies so: 1o nvel de decomposio - identificao dos casos de uso; 2o nvel de decomposio - identificao dos subcasos de uso; 3o nvel de decomposio - identificao dos eventos ou atividades; 4o nvel de decomposio - identificao dos servios tcnicos.

50

Como visto no captulo anterior, a cada nvel de composio podem ser realizadas varias decomposies, enquanto houver necessidade para este nvel de abstrao do projeto. A Tabela 5 apresenta as relaes entre os nveis de decomposio, os tipos de requisitos funcionais e as mtricas de complexidade usadas em cada um dos nveis. TABELA 5 MTRICAS DE COMPLEXIDADE E TIPOS DE REQUISITOS FUNCIONAIS Nvel de decomposio 1 nvel de decomposio 2 nvel de decomposio 3o nvel de decomposio 4o nvel de decomposio
o o

Requisitos funcionais Casos de uso Subcasos Atividades Servios tcnicos

Mtrica de complexidade Use case points Use case points Pontos por funo Conjunto de Mtricas C K (CHIDAMBER e KEMERER, 1994)

4.2.1 Contedo de informao nos nveis 1 e 2 No primeiro e no segundo nvel de decomposio (identificao dos casos de uso e subcasos de uso) o contedo de informao calculado com base nos use case points (KARNER, 1993) (ANDA et al., 2001). Os use case points so originados a partir de uma mtrica de sistemas computacionais amplamente utilizada que a de pontos por funo (Function Points) (VAZQUEZ; SIMES; ALBERT, 2003). Tal como os pontos por funo, os use case points permitem que a complexidade do sistema seja mensurada a partir dos seus requisitos funcionais. Alm disso, podem ser medidas as complexidades de partes do sistema, e em diferentes nveis de decomposio funcional e abstrao. Os use case points so calculados da seguinte maneira. A complexidade de cada ator avaliada e atribudo um peso. Estes pesos so somados e obtido o peso no ajustado dos atores. A seguir, a complexidade de cada caso de uso avaliada e atribudo um peso. Estes pesos tambm so somados e obtido o peso no ajustado dos casos de uso. Estes valores so somados e obtido o valor para os use case points no ajustados. A este valor so aplicados os fatores de ajuste tcnico e ambiental, obtendo-se assim o valor para os use case points. Os fatores de ajuste tcnico e de ambiente levam em considerao

51

fatores como usabilidade, instalabilidade, reusabilidade, complexidade de processamento, concorrncia de processos, experincia da equipe, motivao, entre outros. Adaptando a frmula em (10), o system range dado pela contagem dos use case points de cada caso de uso e a tolerncia dada pela estimativa baseada na mdia histrica das contagens de use case points da organizao.

I log

ucpc eucp

(12)

A frmula em (12) representa o clculo do contedo de informao de um requisito funcional (FR), onde ucpc representa os use case points contados para o requisito funcional (FR) especfico e eucp a estimativa baseada nos use case points mdios da organizao para requisitos funcionais (FR) da mesma complexidade. 4.2.2 Contedo de informao do nvel 3 No terceiro nvel de decomposio so definidas as atividades (ver seo 3.3.2.3). A complexidade relativa s atividades no pode ser calculada atravs dos use case points. Neste caso, a mtrica que se mostra mais adequada a de pontos por funo. A mtrica de pontos por funo (Function Points) (VAZQUEZ; SIMES; ALBERT, 2003) amplamente utilizada para a estimativa e medida de tamanho de sistemas computacionais. A contagem de pontos por funo permite que o sistema seja mensurado a partir dos seus requisitos funcionais. Alm disso, podem ser medidas partes do sistema, e em diferentes nveis de decomposio funcional e abstrao. Ento, se para system range for adotado a contagem de pontos por funo do requisito funcional (FR) e para tolerncia for adotada a estimativa feita com base na mdia histrica para requisitos funcionais (FRs) de mesma complexidade, obtm-se a seguinte frmula.

I log

pfc epf

(13)

Em (13) representado o clculo do contedo de informao de um requisito

52

funcional (FR), onde pfc representa os pontos por funo contados para o requisito funcional (FR) especfico e epf, a estimativa dos pontos por funo com base na mdia histrica da organizao para requisitos funcionais (FRs) da mesma complexidade. Com essa frmula consegue-se calcular a razo fundamental do contedo de informao que calcular a probabilidade de que o parmetro de projeto (DP) identificado satisfaa o respectivo requisito funcional (FR). No caso de projetos de software, a organizao que faz os projetos (Por ex: software houses) possui um registro histrico das contagens de pontos por funo. Atravs desse registro historico possvel se fazer uma estimativa para o valor da contagem de pontos por funo. Se a contagem de pontos por funo da FR for maior que a estimativa, o contedo de informao ser positivo e a probabilidade total de insucesso ser menor. Se for menor, I ser negativo e a probabilidade total de insucesso diminuir. O fato de a contagem de pontos por funo do requisito funcional (FR) ser menor que a estimativa feita com base na mdia histrica de contagens tambm significa que este requisito funcional (FR) tem uma complexidade menor que a complexidade mdia dos projetos produzidos na empresa, ou seja, teoricamente mais fcil se ser realizado. No caso contrrio, ele seria mais difcil de ser construdo pela empresa. 4.2.3 Contedo de informao para o nvel 4 Para o quarto nvel de decomposio, o clculo de pontos por funo no mais satisfatrio. Neste nvel precisam ser medidas as complexidades de classes, mtodos, interaes entre objetos, mudanas de estados, hierarquia de herana, entre outros. Para satisfazer essas necessidades ser adotada uma medida de complexidade mais voltada para esses aspectos, como a definida em (CHIDAMBER e KEMERER, 1994). Como os requisitos funcionais neste nvel so servios tcnicos e os parmetros de projeto so objetos ou variveis necessrio usar uma mtrica que contemple caractersticas de classes, atributos e mtodos. Nesta mtrica so definidas seis grandezas que sero medidas: Mtodos ponderados por classe, profundidade da rvore de herana, nmero de subclasses, acoplamento entre objetos, respostas para a classe e falta de

53

coeso nos mtodos (CHIDAMBER e KEMERER, 1994). A grandeza mtodos ponderados por classe (WMC, do ingls weighted methods per class) representa o total das complexidades dos mtodos de uma classe. O valor dado pela soma das complexidades de cada mtodo. Uma forma simplificada de calcular o WMC considerar os mtodos com o mesmo valor para complexidade, sendo este valor igual a 1. Neste caso, o valor do WMC igual ao nmero de mtodos da classe. Segundo CHIDAMBER e KEMERER (1994), o nmero de mtodos de uma classe e a complexidade destes ajuda a estimar o tempo e o esforo para desenvolver e manter a classe. Classes com um nmero grande de mtodos, so muito especficas e limitam a possibilidade de reuso. Sendo ci a complexidade do mtodo i de uma classe, WMC pode ser calculado pela relao em (14).
n

WMC
i 1

ci

(14)

A profundidade da rvore de herana (DIT, do ingls depth of the inheritance tree), para uma classe definida como sendo o comprimento mximo do n que representa a classe at a raiz da rvore. rvores de herana muito profundas geram muita complexidade no projeto pelo fato de mais mtodos e classes estarem envolvidos (CHIDAMBER e KEMERER, 1994). A Figura 15 ilustra uma rvore de herana. Neste exemplo, o valor de DIT para a classe AlunoGraduacao igual a 2.

54

FIGURA 15

PROFUNDIDADE DA RVORE DE HERANA (DIT)

O nmero de subclasses (NOC, do ingls number of children) o nmero de subclasses diretas de uma classe. Segundo CHIDAMBER e KEMERER (1994), quanto maior o nmero de subclasses diretas de uma classe, maior a possibilidade de que a herana tenha sido usada incorretamente para esta classe. A Figura 16 ilustra uma rvore de hierarquia. O valor para NOC para a classe Obra igual a 4 pois ela tem 4 subclasses diretas. FIGURA 16 NMERO DE SUBCLASSES (NOC)

A grandeza acoplamento entre objetos (CBO, do ingls coupling between

55

objects) de uma classe definida como sendo o nmero de outras classes com as quais esta classe se relaciona (CHIDAMBER e KEMERER, 1994). Em outras palavras, o nmero de classes das quais esta classe usa mtodos ou variveis de instncia. Uma maneira prtica para determinar o CBO usando os cartes classe-responsabilidade-colaborador (CRC) definidos por BECK e CUNNINGHAM (1989). Um colaborador uma classe que presta servio para que uma outra classe consiga realizar suas responsabilidades. A grandeza resposta para a classe (RFC, do ingls response for a class) definida como a cardinalidade do conjunto de respostas de uma classe, como na relao em (15).

RFC

RS

(15)

Segundo CHIDAMBER e KEMERER (1994), o conjunto de respostas de uma classe o conjunto de mtodos de uma classe que podem potencialmente ser executados em resposta a uma mensagem recebida. Segundo CHIDAMBER e KEMERER (1994), quanto maior o conjunto de mtodos que podem ser chamados de uma classe, maior a complexidade da classe. Se um grande nmero de mtodos pode ser chamado de uma classe, as operaes de teste e correo ficam muito mais complexas, exigindo maior experincia por parte do desenvolvedor. (CHIDAMBER e KEMERER, 1994) Sendo RS, o conjunto de resposta da classe, { Ri }, o conjunto dos mtodos da classe chamados pelo mtodo i e { M }, o conjunto de todos os mtodos da classe. O conjunto de resposta de uma classe, RS, pode ser definido pela relao em (16).

RS

all i

Ri

(16)

A grandeza falta de coeso nos mtodos (LCOM, do ingls lack of cohesion of methods) o nmero de mtodos da classe que acessam um ou mais dos mesmos atributos. Se dois mtodos de uma classe acessam um mesmo atributo da classe, dito que eles compartilham o atributo. LCOM de uma classe o nmero de mtodos que compartilham atributos. Se LCOM alto, mtodos podem estar acoplados atravs dos

56

atributos. Isto aumenta a complexidade do projeto da classe (PRESSMAN, 2004). A grandeza falta de coeso nos mtodos prov uma medida de desigualdade dos mtodos de uma classe. Segundo CHIDAMBER e KEMERER (1994), qualquer medida de desigualdade dos mtodos ajuda a identificar falhas no projeto de classes. O valor do contedo de informao do 4o nvel de decomposio obtido pela soma dos valores do contedo de informao para cada classe. O valor do contedo de informao de cada classe calculado pela soma dos contedos de informao relativos a cada umas das grandezas definidas por CHIDAMBER e KEMERER (1994), como em (17).

I classe I WMC I DIT I NOC

I CBO I RFC I LCOM

(17)

Este clculo pode ser feito, tambm, usando-se fatores de ponderao para cada grandeza, como na relao (18). Nesta relao , , , , e so os fatores de ponderao. Estes fatores so definidos, pelo projetista, com base na importncia do contedo de informao de cada grandeza.

I classe

I WMC

I DIT

I NOC

I CBO

I RFC

I LCOM

(18)

Os valores dos contedos de informao so calculados pelas relaes entre os valores encontrados para cada classe, para cada grandeza, como em (19), (20), (21), (22), (23) e (24).

I WMC

log

WMC EWMC

(19)

Onde IWMC o contedo de informao relativo a mtodos ponderados por classe (WMC) e EWMC o valor estimado de WMC para a classe com base na mdia histrica.

I DIT log

DIT EDIT

(20)

Onde IDIT o contedo de informao relativo a profundidade da rvore de herana (DIT) e EDIT o valor estimado de DIT para a classe com base na mdia histrica.

57

I NOC log

NOC ENOC

(21)

Onde INOC o contedo de informao relativo a nmero de subclasses (NOC) e ENOC o valor estimado de NOC para a classe com base na mdia histrica.

I CBO log

CBO ECBO

(22)

Onde ICBO o contedo de informao relativo a acoplamento entre objetos (CBO) e ECBO o valor estimado de CBO para a classe com base na mdia histrica.

I RFC log

RFC ERFC

(23)

Onde IRFC o contedo de informao relativo a resposta para a classe (RFC) e ERFC o valor estimado de RFC para a classe com base na mdia histrica.

I LCOM log

LCOM ELCOM

(24)

Onde ILCOM o contedo de informao relativo a falta de coeso nos mtodos (LCOM) e ELCOM o valor estimado de LCOM para a classe com base na mdia histrica.

4.3 APLICAO DO CONTEDO DE INFORMAO NA METODOLOGIA

O contedo de informao um parmetro importante para se escolher entre as diferentes solues possveis para um projeto. A metodologia apresentada neste trabalho prope o clculo do contedo de informao a cada decomposio feita para, no caso de surgir mais de uma possibilidade para a decomposio, facilitar a deciso de qual adotar. Os use case points, usados para calcular o contedo de informao para o primeiro e o segundo nvel de decomposio, podem ser calculados facilmente com a ajuda

58

de ferramentas CASE (Computer Aided Software Engineering) como a Enterprise Architect5. No terceiro nvel de decomposio, o contedo de informao calculado atravs dos pontos por funo. Para isto tambm existem vrias opes de ferramentas de software. Mas para se calcular o contedo de informao necessrio que seja possvel estimar os valores com base em registros histricos da empresa que vai realizar o projeto. Ento, necessrio que a empresa mantenha controle e registros dos projetos realizados, o que uma caracterstica de maturidade de processo de software. (PAULK et al., 1993) Para o quarto nvel de decomposio ser usado o conjunto de mtricas definido por CHIDAMBER e KEMERER (1994). A grande vantagem deste conjunto de mtricas a facilidade em se calcular seus valores. Estes valores podem ser calculados durante o projeto, usando-se os diagramas de classe e seqncia da UML 2.0 (OBJECT MANAGEMENT GROUP, 2003), ou diretamente do cdigo atravs de uma anlise simples, que pode ser automatizada. Isto permite que projetos anteriores da organizao sejam analisados e seus valores obtidos, auxiliando a obteno da estimativa. TABELA 6 CONTEDO DE INFORMAO DA CLASSE CINTBD Grandeza WMC DIT NOC CBO RFC LCOM Valor medido 5 0 0 2 4 5 Estimativas 8 0 0 2 6 3 Contedo de Informao -0,67807 0 0 0 -0,58496 0,73696

Para ilustrar como este clculo do contedo de informao realizado, ser apresentado um exemplo. No diagrama de classes da Figura 17, so apresentadas as classes CIntBD, CPonto e CFuncionrio. Ser apresentado o clculo do contedo de informao para a classe CIntBD. Na Tabela 6 apresentado, na primeira coluna, o nome da grandeza e, na segunda coluna, exibido o valor da grandeza calculado para a classe
5

O software Enterprise Arquitect marca registrada da Sparx Systems

59

CIntBD. Na terceira coluna apresentada a estimativa do valor para cada grandeza. Na quarta coluna apresentado o valor do contedo de informao para cada grandeza. FIGURA 17 CLASSES PARA O CLCULO DO CONTEDO DE INFORMAO

O contedo de informao da classe CIntBD calculado pela soma dos contedos de informao de cada grandeza, apresentados na Tabela 6. O valor obtido ICIntBD = -0,53056. Um valor negativo para o contedo de informao representa um decrscimo no contedo de informao total. Isto pode indicar que esta classe pode ser uma boa soluo. Mas, s possvel ter certeza de que a soluo melhor que outra com base no contedo de informao total, isto , quando todas as classes j tiverem sido projetadas e avaliadas. Supondo os mesmos requisitos funcionais (FRs) do exemplo anterior, ser considerado que o projetista criou apenas uma classe, chamada CIntBDNova, para receber dados de ponto e empregado, retornar dados de ponto e empregado e gravar e

60

remover esses dados. A classe CIntBDNova apresentada na Figura 18. O contedo de informao da classe CIntBDNova calculado pela soma dos contedos de informao de cada grandeza, apresentados na Tabela 7. O valor obtido ICIntBDNova = 1,5539. Um valor positivo para o contedo de informao representa um acrscimo no contedo de informao total. A classe CIntBDNova possui um contedo de informao maior que a classe CIntBD. Neste caso a classe CIntBD pode ser considerada uma soluo melhor que a classe CIntBDNova, pelo axioma 2. FIGURA 18 CLASSE CINTBDNOVA

TABELA 7 CONTEDO DE INFORMAO DA CLASSE CINTBDNOVA Grandeza WMC DIT NOC CBO RFC LCOM Valor medido 9 0 0 0 9 8 Estimativas 8 0 0 0 6 3 Contedo de Informao 0,1177 0 0 0 0,4554 0,9808

61

5 PLANO DE TRABALHO PROPOSTO

Este captulo apresenta o plano de trabalho proposto para a continuidade do trabalho de doutorado. A primeira seo apresenta as atividades realizadas nos dois primeiros anos de trabalho e as atividades propostas para o trmino do trabalho. A segunda seo apresenta o cronograma para as atividades propostas.

5.1 ATIVIDADES PLANEJADAS

Durante os dois primeiros anos deste trabalho de doutorado foram realizadas, as atividades de: Obteno de crditos; Estudo sobre a teoria de projeto axiomtico; Estudo sobre as relaes entre os conceitos do projeto axiomtico, projeto de software e UML; A elaborao de uma metodologia de desenvolvimento envolvendo a teoria de projeto axiomtico e a UML. A reviso da teoria do projeto axiomtico visou a assimilao dos conceitos tericos envolvidos no projeto axiomtico, alm da visualizao de detalhes da aplicao do projeto axiomtico em estudos de caso de projetos de engenharia e, principalmente, em projetos de software. Nesta etapa foram efetuadas as seguintes atividades: Estudo aprofundado sobre a teoria de projeto axiomtico envolvendo a aquisio dos conceitos tericos do projeto axiomtico; Reviso bibliogrfica envolvendo a reviso da literatura das principais contribuies para a teoria de projeto axiomtico e sua aplicao no

62

desenvolvimento de software. Estudo da aplicao desta teoria no desenvolvimento de software envolvendo o estudo sobre a aplicao do processo axiomtico no desenvolvimento de software atravs de estudos de caso; A elaborao da metodologia envolveu a avaliao da aplicao do projeto axiomtico no desenvolvimento de software e a identificao e criao de adaptaes e melhorias para a utilizao do projeto axiomtico no projeto de software orientado a objetos. Esta etapa envolveu as seguintes atividades: Identificao das lacunas do projeto axiomtico para o desenvolvimento de software orientado a objetos; Identificao das modificaes necessrias para a aplicao do projeto axiomtico no desenvolvimento de software orientado a objetos; Proposio e criao de um framework com novos domnios e artefatos para possibilitar a utilizao proposta acima; Para a continuidade deste trabalho de doutorado, as seguintes atividades sero realizadas: Realizao de estudos de caso, aplicando a metodologia proposta; Aprimoramento e ajuste da metodologia proposta; Investigao sobre a aplicabilidade da metodologia; Investigao sobre a aplicao da metodologia auxiliada por ferramentas de software; Investigao sobre a influncia da metodologia sobre a qualidade de software. Uma das atividades importantes ser a realizao de estudos de caso para avaliar a aplicabilidade da metodologia proposta. A aplicao da metodologia proposta pode revelar alguns gargalos no processo, alm de ocasionar alguns efeitos colaterais, desejveis ou indesejveis. A realizao de estudos de caso da aplicao da metodologia servir para

63

identificar os ganhos, gargalos e efeitos colaterais. Estes estudos de caso sero importantes tambm para realizar ajustes nos parmetros usados e na maneira de efetuar o clculo do contedo de informao. Com base nos estudos de caso, a atividade seguinte ser realizar ajustes na metodologia. Estes ajustes ou modificaes so importantes para que a metodologia consiga atingir os objetivos desejados. Neste caso, podero ser modificadas etapas, a maneira de se utilizar os artefatos. A forma de calcular o contedo de informao poder sofrer adaptaes, principalmente nos valores dos fatores de ponderao. Isto para permitir que a aplicao da metodologia seja mais fcil e intuitiva. Uma outra atividade importante a investigao sobre a aplicao da metodologia auxiliada por ferramentas de software. Com esta atividade pretende-se identificar quais componentes da metodologia poderiam ser automatizados. J existem ferramentas de desenvolvimento de software auxiliado por computador que usam aspectos do projeto axiomtico, como a IBM Rational Rose6 integrada com o sistema Acclaro Scheduler7. Ser investigado se artefatos como a matriz de projeto e o diagrama de fluxo podem ser gerados automaticamente. Ser investigado, tambm, se o clculo do contedo de informao poder ser feito com a ajuda de um software. Mas, principalmente, ser investigado se a tomada de deciso sobre qual soluo a melhor poderia ser feita com a ajuda de um software, inclusive usando tcnicas de inteligncia artificial no processo. A investigao sobre a aplicabilidade e relacionamento com outras tecnologias de desenvolvimento de software consistir em analisar a aplicao da teoria de projeto axiomtico em tecnologias como Extreme Programming (BECK, 1999), desenvolvimento orientado a aspectos (KICZALES et. al., 1997), padres (GAMMA et al., 2000), entre outros. tambm importante investigar a influncia da metodologia em aspectos de qualidade de software como reutilizao, manutenibilidade, testabilidade, entre outros.

6 7

IBM Rational Rose marca registrada de IBM ACCLARO marca registrada de Axiomatic Design Software, Inc..

64

5.2 CRONOGRAMA GERAL DAS ATIVIDADES A SEREM DESENVOLVIDAS

A Tabela 8 a seguir contm a relao das atividades a serem desenvolvidas durante o doutoramento, bem como a respectiva previso de tempo para sua realizao. A escala de tempo mostrada em trimestres em cada clula. TABELA 8 CRONOGRAMA DE ATIVIDADES Atividades / Trimestres Desenvolvimento e ajuste da Metodologia Estudos de caso Investigao sobre a aplicabilidade da metodologia Investigao sobre a aplicao da metodologia auxiliada por ferramentas de software Investigao sobre a influncia da metodologia sobre a qualidade de software Elaborao de artigos cientficos / Participao em Congressos Escrita da Tese Defesa da Tese X X X 01o. 02o. 03o. 04o. 01o. 02o. 03o. 04o. 2005 2005 2005 2005 2006 2006 2006 2006 X X X X X X X X X

X X X X X X X X X

65

6 CONCLUSES

Este trabalho prope a criao de uma metodologia de desenvolvimento de software baseada na adaptao da teoria de projeto axiomtico ao projeto de software orientado a objetos e na UML. Esta adaptao foi efetuada considerando as peculiaridades do projeto de software orientado a objetos, as principais ferramentas de projeto providas pela UML e os principais conceitos do projeto axiomtico. A motivao para a realizao deste trabalho tornar o projeto de software mais preciso e confivel de forma a garantir a qualidade dos produtos (software) construdos atravs deste processo. A teoria de projeto axiomtico (SUH, 2001) foi estabelecida para garantir a qualidade de um projeto, atravs do uso de seus axiomas, domnios, ferramentas e processo. A teoria de projeto axiomtico foi criada com o objetivo de ser independente de domnio, podendo ser aplicada em todos os tipos de projeto. Como resultado da pesquisa espera-se obter as seguintes contribuies para a cincia e tecnologia: Uma nova abordagem para a utilizao da UML no desenvolvimento de software, usando ferramentas e processos tirados da abordagem axiomtica. Uma nova abordagem para a aplicao da teoria de projeto axiomtico Uma metodologia para desenvolvimento de software baseada na UML e na teoria de projeto axiomtico que ajude a garantir a qualidade do projeto, propriamente dito, e, portanto, do software produzido. No desenvolvimento de software orientado a objetos ocorrem freqentemente decises de projeto tomadas usando-se a experincia do desenvolvedor, sem parmetros mais precisos. Isto no garante que o projeto seja um bom projeto. A formas de avaliar um projeto so baseadas na qualidade do produto que ele ir gerar. No se leva em considerao a qualidade do projeto em si. Na teoria de projeto axiomtico temos ferramentas como os axiomas, teoremas e seus corolrios (SUH, 1990), que ajudam na tomada de decises a respeito da qualidade do projeto em si, de maneira mais precisa. A

66

teoria de projeto axiomtico, desenvolvida para projetos de engenharia pode fornecer ferramentas para ajudar na garantia da qualidade do projeto. Com este trabalho espera-se tornar o processo de projeto de software mais preciso e confivel de forma a garantir a qualidade dos produtos construdos atravs deste processo. Este trabalho tem por objetivo estabelecer uma metodologia que poder ser usada para garantir a qualidade do projeto de software. Com esta metodologia ser possvel identificar que um projeto no est bom, ou seja, no satisfaz os axiomas. Neste caso, sua realizao seria muito difcil, pois exigiria da equipe de desenvolvimento muito mais sincronizao e comunicao do que seria necessrio. Esta metodologia poder, tambm, ser incorporada a ferramentas CASE adicionando a capacidade de avaliar um projeto que est sendo executado, e dando ao projetista a oportunidade de modificar ou refazer o projeto, antes do incio de sua implementao. Com isto, tenta-se evitar que a implementao, atividade que gasta mais recursos, seja feita a partir de um projeto que, por exemplo, no satisfaz os axiomas. Com esta metodologia tenta-se, tambm, obter uma maior robustez no projeto de software. Uma das grandes dificuldades de um projeto de software o gerenciamento de mudanas nos requisitos durante a elaborao do projeto. Com esta metodologia possvel controlar os efeitos negativos dessas mudanas, evitando que a mudana em um requisito tenha um efeito muito grande sobre os outros requisitos. A metodologia, proposta neste trabalho, tem por objetivo permitir que os conceitos do projeto axiomtico sejam utilizados, de maneira eficaz, para o desenvolvimento de um projeto de software. A metodologia dividida em etapas, baseadas nos mapeamentos entre os domnios do projeto axiomtico. Os domnios originais do projeto axiomtico no so suficientes para representar todas as caractersticas de um projeto de software orientado a objetos. Por este motivo foram propostos novos domnios complementares. Foram usados os seguintes domnios complementares: domnio de casos de uso, domnio de classes, domnio de interaes e domnio de estados.

67

Em DO (2004), proposta a utilizao de um domnio complementar (casos de uso) para capturar os requisitos funcionais (FRs), durante a fase de especificao de requisitos. O trabalho de doutorado, aqui apresentado, estende a utilizao de domnios complementares para a fase de projeto. Alm disso, este trabalho prope uma classificao dos requisitos funcionais (FRs) em relao ao nvel da hierarquia funcional e tambm com relao ao tipo de servio requerido. Com relao ao nvel da hierarquia, foram propostos os seguintes tipos de requisitos funcionais: casos de uso, subcasos de uso, atividades e servios tcnicos. Com relao ao tipo de servio requerido, os servios tcnicos foram classificados em: servios tcnicos de entidade, servios tcnicos de controle e servios tcnicos de fronteira. Esta classificao procura estabelecer uma ligao entre a arquitetura MVC e o projeto axiomtico, aproximando-o das tecnologias usadas, atualmente, para o projeto de software. Conceitos do projeto axiomtico como requisitos funcionais e parmetros de projeto foram adaptados para o projeto de software. Os requisitos funcionais so representados como casos de uso, subcasos de uso, atividades e servios tcnicos. Os parmetros de projeto so representados como colaboraes, subcolaboraes que so decompostas at atingir um item de projeto que equivalente a um objeto e sua representao nas vises esttica (diagrama de classes) dinmica (diagrama de estados) e interativa (diagrama de seqncia). O processo de decomposio funcional foi adaptado para satisfazer as necessidades do projeto de software. Os nveis de decomposio adotados foram: a identificao dos casos de uso; a identificao dos sub casos de uso; a identificao dos eventos ou atividades; a identificao dos servios tcnicos. Com relao decomposio funcional, este trabalho, modifica a decomposio funcional proposta em (SUH e DO, 2000), que no usa o conceito de casos de uso. Este trabalho prope uma decomposio funcional fortemente baseada em casos de uso. Cada caso de uso decomposto em unidades menores de servio at alcanar o nvel de

68

servios prestados por um objeto a outro objeto, chamados servios tcnicos. Esta proximidade torna a decomposio muito mais prxima dos conceitos usados em projeto de software Foi estabelecido um framework para o clculo do contedo de informao, adaptado para o projeto de software orientado a objetos. Este clculo foi efetuado com base em mtricas de complexidade de software orientado a objetos, conhecidas na literatura. Para a continuidade deste trabalho de doutorado, sero realizados estudos de caso para avaliar a aplicabilidade da metodologia proposta. A aplicao da metodologia proposta dever ser refinada para torna-la mais intuitiva e aplicvel. Desta forma tenta-se evitar gargalos e efeitos colaterais, desejveis ou indesejveis. Estes estudos de caso serviro para identificar estes gargalos e efeitos colaterais, alm de servir para realizar ajustes nos parmetros usados e na maneira de efetuar o clculo do contedo de informao. Neste caso, podero ser modificadas etapas, a maneira de se utilizar os artefatos e a forma de calcular o contedo de informao. Ser feita uma investigao sobre a aplicao da metodologia auxiliada por ferramentas de software. Tenta-se identificar quais componentes e etapas da metodologia poderiam ser automatizados, e como seria realizada esta automao. Ser realizada uma investigao sobre a aplicabilidade e relacionamento com outras tecnologias de desenvolvimento de software. tambm importante investigar a influencia da metodologia em aspectos de qualidade de software como reutilizao, adaptabilidade, entre outros. O trabalho de doutorado aqui proposto tem um forte carter terico, no envolvendo a aquisio de equipamentos especiais. Recursos tradicionais como microcomputador e software aplicativos sero suficientes. Sero necessrios ao desenvolvimento do trabalho de doutorado, itens como: livros, artigos, microcomputador e software aplicativos, entre outros. Estes itens devero ser adquiridos com recursos do CPGEI, do CEFET-PR e do CNPq, via bolsa de estudos e taxa de bancada, ambas j

69

implementadas.

6.1 AGRADECIMENTO

O presente trabalho de doutorado est sendo realizado com o apoio do Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico CNPq Brasil.

70

ANEXO 1 - TEOREMAS E COROLRIOS RELACIONADOS COM OS AXIOMAS

Neste anexo so apresentados corolrios e teoremas relacionados com os axiomas 1 e 2. Sero apresentados os teoremas sobre projeto em geral e os teoremas relacionados com projeto de software. Os corolrios e teoremas apresentados abaixo foram traduzidos de (SUH, 2001).

1.1 COROLRIOS

Corolrio 1 Desacoplamento de projetos acoplados. Desacople ou separe as partes ou aspectos de uma soluo se os requisitos funcionais estiverem acoplados ou se tornarem interdependentes no projeto proposto. Corolrio 2 Minimizao dos requisitos funcionais. Minimize o nmero de requisitos funcionais e restries. Corolrio 3 Integrao das partes Fsicas. Integre caractersticas de projeto em uma nica parte fsica se os requisitos funcionais puderem ser satisfeitos

independentemente na soluo proposta. Corolrio 4 Uso de padronizao. Use partes padronizadas ou intercambiveis se o uso destas partes estiver consistente com os requisitos funcionais e restries. Corolrio 5 Uso de simetria. Use formas e componentes simtricos se eles estiverem consistentes com os requisitos funcionais e restries. Corolrio 6 Maior faixa de variao de projeto. Especifique a maior faixa de variao de projeto permitido quando estiver estabelecendo os requisitos funcionais. Corolrio 7 Projeto desacoplado com menos informao. Procure um projeto desacoplado que requer menos informao que projetos acoplados em satisfazer um

71

conjunto de requisitos funcionais. Corolrio 8 Reangularidade Efetiva de um escalar. A reangularidade efetiva R para uma matriz de acoplamento escalar ou elemento de matriz um.

1.2 TEOREMAS DE PROJETOS GERAIS

Teorema 1 Acoplamento devido a um nmero insuficiente de parmetros de projeto (DPs). Quando o nmero de parmetros de projeto (DPs) menor que o nmero de requisitos funcionais (FRs), ou resulta num projeto acoplado ou os requisitos funcionais (FRs) no podero ser satisfeitos. Teorema 2 Reduo do acoplamento de um projeto acoplado. Quando um projeto acoplado devido a um nmero de requisitos funcionais (FRs) maior que o nmero de parmetros de projeto (DPs) (m > n), seu acoplamento pode ser reduzido pela adio de novos parmetros de projeto (DPs) de tal forma a tornar o nmero de requisitos funcionais (FRs) igual ao nmero de parmetros de projeto (DPs) se um subconjunto da matriz de projeto contendo n x n elementos constitui uma matriz triangular. Teorema 3 Projeto redundante. Quando existem mais parmetros de projeto (DPs) que requisitos funcionais (FRs), o projeto ou um projeto redundante ou um projeto acoplado. Teorema 4 Projeto ideal. Em um projeto ideal, o nmero de parmetros de projeto (DPs) igual ao nmero de requisitos funcionais (FRs) e os requisitos funcionais so sempre mantidos independentes uns dos outros. Teorema 5 Necessidade de um novo projeto. Quando um conjunto de requisitos funcionais (FRs) alterado pela adio de um novo requisito funcional (FR), pela substituio de um dos requisitos funcionais (FRs) por um novo ou pela seleo de um conjunto completamente diferente de requisitos funcionais (FRs), a soluo do projeto Teorema 6 - Independncia de caminho do projeto desacoplado. O contedo de

72

informao de um projeto desacoplado independente da seqncia pela qual os parmetros de projeto (DPs) so mudados para satisfazer um dado conjunto de requisitos funcionais (FRs). Teorema 7 - Dependncia de caminho de projeto acoplados e semi-acoplados. O contedo de informao de um projeto acoplado ou semi-acoplado depende da seqncia pela qual os parmetros de projeto (DPs) so mudados e dos caminhos especficos de mudana destes parmetros de projeto (DPs). Teorema 8 Independncia e a faixa de variao de projeto. Um projeto um projeto desacoplado quando a faixa de variao especificada pelo projetista maior que
n i j j 1

FRi DP j

DP j

(25)

Neste caso, os elementos fora da diagonal da matriz de projeto podem ser desconsiderados do projeto. Teorema 9 Projeto para manufaturabilidade. Para um produto ser manufaturvel com confiabilidade e robustez, a matriz de projeto para o produto, [A] (que relaciona o vetor de requisitos funcionais (FRs) para o produto com o vetor dos parmetros de projeto (DPs) do produto), multiplicada pela matriz de projeto do processo de manufatura, [B] (que relaciona o vetor de requisitos funcionais (FRs) para o processo de manufatura com o vetor dos parmetros de projeto (DPs) do processo), deve resultar ou em uma matriz diagonal ou em uma matriz triangular. Conseqentemente, quando tanto [A] quanto [B] representam um projeto acoplado, a independncia dos requisitos funcionais (FRs) e um projeto robusto no podem ser alcanados. Quando as matrizes forem matrizes triangulares completas, tanto ambas devem ser triangulares superiores ou ambas devem ser triangulares inferiores para que o processo de manufatura satisfaa a independncia dos requisitos funcionais (FRs). Teorema 10 Modularidade das medidas de independncia. Supondo que uma

73

matriz de projeto [DM] possa ser particionada em sub-matrizes quadradas que somente possuam elementos diferentes de zero na diagonal principal. Ento a reangularidade e a semangularidade para [DM] so iguais ao produto das suas medidas correspondentes para cada sub-matriz. Teorema 11 Invarincia. A reangularidade e a semangularidade para uma matriz de projeto [DM] no varia com a mudana da ordem dos requisitos funcionais (FRs) e dos parmetros de projeto (DPs) enquanto forem preservadas as associaes entre cada requisito funcional (FR) e seus correspondentes parmetros de projeto (DPs). Teorema 12 Soma da informao. A soma da informao para um conjunto de eventos tambm informao, desde que probabilidades condicionais apropriadas sejam usadas quando os eventos no forem estatisticamente independentes. Teorema 13 Contedo de informao de todo o sistema. Se cada parmetro de projeto (DP) for probabilisticamente independente dos outros parmetros de projeto (DPS), o contedo de informao total do sistema a soma da informao de todos os eventos individuais associados com o conjunto de requisitos funcionais (FRs) que devem ser satisfeitos. Teorema 14 Contedo de informao de projetos acoplados versus desacoplados. Quando o estado dos requisitos funcionais (FRs) mudado de um estado para o outro no domnio funcional, a informao requerida para a mudana maior para projetos acoplados que para projetos desacoplados. Teorema 15 Interface projeto-manufatura. Quando um sistema de manufatura compromete a independncia dos requisitos funcionais (FRs) do produto, ou o projeto do produto deve ser modificado ou um novo processo de manufatura deve ser projetado e/ou utilizado para manter a independncia dos requisitos funcionais (FRs) do produto. Teorema 16 Igualdade do contedo de informao. Todos os contedos de informao que so relevantes para a tarefa de projetar so igualmente importantes, no importando sua origem fsica, e nenhum fator de ponderao dever ser aplicado a eles.

74

Teorema 17 Projeto na ausncia de informao completa. O projeto pode ser feito mesmo na ausncia de informao completa apenas no caso de um projeto semiacoplado se a informao faltante est relacionada com elementos fora da diagonal. Teorema 18 Existncia de um projeto desacoplado ou semi-acoplado. Sempre ir existir um projeto desacoplado ou semi-acoplado que possua menor contedo de informao que um projeto acoplado. Teorema 19 Robustez do projeto. Um projeto desacoplado e um projeto semiacoplado so mais robustos que um projeto acoplado no sentido que mais fcil reduzir o contedo de informao de projetos que satisfazem o axioma da independncia. Teorema 20 Faixa de variao de projeto e acoplamento. Se as faixas de variao de projeto para projetos desacoplados ou semi-acoplados forem apertadas, os projetos podem se tornar projetos acoplados. No sentido contrrio, se as faixas de variao de projeto para projetos acoplados forem relaxadas, eles podem se tornar projetos desacoplados ou semi-acoplados. Teorema 21 Projeto robusto quando o sistema possui uma funo de distribuio de probabilidade no uniforme. Se a funo de distribuio de probabilidade do requisito funcional (FR) na faixa de variao de projeto no uniforme, a probabilidade de sucesso igual a um quando a faixa de variao do sistema est dentro da faixa de variao de projeto. Teorema 22 Robustez comparativa de um projeto semi-acoplado. Dadas as faixas de variao de projeto mximas para um dado conjunto de requisitos funcionais (FRs), projetos semi-acoplados no podem ser to robustos quanto projetos desacoplados em que as tolerncias permitidas para parmetros de projeto (DPs) de um projeto semiacoplado so menores que aqueles para um projeto desacoplado. Teorema 23 Diminuindo a robustez de um projeto semi-acoplado. A tolerncia permitida e, portanto, a robustez de um projeto semi-acoplado com uma matriz triangular completa diminui com um aumento no nmero de requisitos funcionais (FR).

75

Teorema 24 Agendamento timo. Antes que um agendamento para a movimentao de um rob ou agendamento de manufatura possa ser otimizado, o projeto das tarefas deve ser feito de maneira a satisfazer o axioma de independncia pela adio de desacopladores para eliminar o acoplamento. Os desacopladores podem ser na forma de uma pilha de hardware isolado ou buffer.

1.3 TEOREMAS RELACIONADOS COM PROJETO DE SOFTWARE

Teorema Soft 1 Conhecimento requerido para operar um sistema desacoplado. Sistema de software ou hardware desacoplados podem ser operados sem um conhecimento preciso sobre elementos do projeto (mdulos) se o projeto verdadeiramente um projeto desacoplado e se as sadas dos requisitos funcionais (FRs) puderem ser monitorados para permitir um controle dos requisitos funcionais (FRs). Teorema Soft 2 Tomada de decises corretas na ausncia do conhecimento completo para um projeto semi-acoplado com controle. Quando o sistema de software um projeto semi-acoplado, os requisitos funcionais (FRs) podem ser satisfeitos pela mudana dos parmetros de projeto (DPs) se a matriz de projeto conhecida para a extenso que o conhecimento a respeito da seqncia apropriada dada, mesmo que no haja um conhecimento preciso a respeito dos elementos do projeto.

76

REFERNCIAS

ALTSHULLER, G. S.. Creativity as an Exact Science. Gordon and Breach. USA, 1988. ANDA, B.; DREIEM, D.; SJBERG, D.; JRGENSEN, M.. Estimating Software Development Effort Based on Use Cases - Experiences from Industry. In M. Gogolla, C. Kobryn (Eds.): UML 2001 - The Unified Modeling Language.Modeling Languages, Concepts, and Tools, 4th International Conference, Toronto, Canada, October 1-5, 2001, LNCS 2185 Springer. BECK, K.. Extreme Programming Explained. Embrace Change. Addison-Wesley. 1999. BECK, K.; CUNNINGHAM, W.. A Laboratory for Teaching Object-Oriented Thinking. In: Proceedings of OOPSLA 89. 1989. BITTNER, K.; SPENCER, I.. Use Case Modeling. Addison Wesley, Reading, Massachusetts, 2003. BJRNEMO, R. Formalized Design Methods. Thesis. Institute for Machine Design. University of Lund. Sweden. 1983 BOOCH, G.. Object-Oriented Analysis and Design with Applications. Benjamin/Cummings. 1994. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.. The Unified Modeling Language User Guide. Addison Wesley, Reading, Massachusetts, 1999. CAPPETTI, N.; NADDEO, A.; PELLEGRINO, A.. Design Decoupling Method Based on ParaComplete Logics. In Proceedings of the 3rd International conference on axiomatic design ICAD2004. Seul Korea, june, 2004. CHIDAMBER, S. R.; KEMERER, C. F.. A Mtrics Suite for Object-Oriented Design. In IEEE transactions on software engineering, vol. SE-20, no. 6, junho 1994, pp. 476-493. CLAUSING, D. P.. Total Quality Development. ASME press. USA, 1994. DO, S. H.. Software Product Lifecycle Management Using Axiomatic Approach. In Proceedings of the 3rd International conference on axiomatic design ICAD2004. Seul Korea, june, 2004. DO, S.; SUH, N. P.. Systematic OO Programming with Axiomatic Design. IEEE Computer 32(10): 121-124. 1999. D'SOUZA, D. F.; WILLS, A. C.. Objects, Components, and Frameworks With Uml: The Catalysis Approach. ADDISON-WESLEY. 1998 GANE, C.; SARSON,.T.. Anlise Estruturada de Sistemas. LTC editora. Brasil. 1995.

77

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.. Padres de Projeto. Solues Reutilizveis de Software Orientado a Objetos. Bookman editora. 2000. HALSTEAD, M.; Elements of Software Science, North-Holland. 1977. HAREL, D.. Statecharts: A Visual Formalism for Complex Systems. In: Science of computer Programming, v. 8, p. 231-274. 1987. HARUTUNIAN, V.; NORLUND, M. and TATE, D.. Decision Making and Software Tools for Product Development Based on Axiomatic Design Theory. Submited to the 1996 CIRP General Assembly (CIRP Annals, vol. 45/1). Como, Italy. 1996 HINTERSTEINER, J. D.. A fractal representation for systems. In the 1999 International CIRP Design Seminar, Enschede, The Netherlands, 1999. HINTERSTEINER, J. D. and NAIN, A. S.. Integrating Software Into Systems: An Axiomatic Design Approach. Proceedings of the 3rd. International Conference on Engineering Desing and Automation. Vancouver, Canada. 1999. HUBKA, V.; EDER, W. E.. Engineering Design. Heurista. Switzerland, 1992. JACOBSON, I.. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. 1994. JACOBSON, I.; BOOCH , G.; RUMBAUGH , J.. The Unified Software Development Process. Addison Wesley, Reading, Massachusetts, 1999. KRASNER, G.; POPE, S.. A Cookbook for using the Model-View Controller user paradigm in Smalltalk-80. Journal of Object-Oriented programming, vol. 1, no. 3, august/September 1988. pp. 26-49. KARNER, G, Metrics for Objectory. Diploma thesis, University of Linkping, Sweden. No. LiTH- IDA-Ex-9344:21. December 1993. KICZALES, G. J.; LAMPING, A.; MENDHEKAR, C.; MAEDA, C.; LOPES, J.; LOINGTIER, M.; IRWIN, J.. Aspect-Oriented Programming. In: Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland, Springer-Verlag LNCS 1241, june, 1997. LARMAN, C.. Applying UML and patterns An Introduction to Object-Oriented Analysis and Design. Prentice-Hall. 1997. LEFFINGWELL, D.; WIDRIG, D.. Managing Software Requirements: A use case approach. 2nd edition. Addison-Wesley. Boston, 2003. LINDHOLM, D.; TATE, D.; HARUTUNIAN, V.. Consequences of Design Decisions in Axiomatic Design. In: Journal of Integrated Design and Process Science. Society for Design and Process Science. December 1999, v. 3 no. 4 pp. 1-12. MCMENAMIM, S.; PALMER, J. F.. Anlise Essencial de Sistemas. Makron Books. Brasil. 1991. NORLUND, M.. An Information Framework for Engineering Design based on Axiomatic Design. Ph.D. Thesis, Royal Institute of Technology (KTH), Stockholm, Sweden, Nov 1996.

78

OBJECT MANAGEMENT GROUP. UML 2.0 super structure specification. Disponvel em http://www.omg.org/docs/ptc/03-08-02.pdf. 2003 OLEWNIK, A. T.; LEWIS, K. E.. On validating design decision methodologies. Proceedings of DETC 2003 ASME 2003 Design Engineering Technical Conferences. Chicago, IL, September 2- 6. PAULK, M. C.; CURTIS, B.; CHRISSIS, M. B.; WEBER, C. V.. Capability Maturity ModelSM for Software, Version 1.1. Technical Report CMU/SEI-93-TR-024 ESC-TR-93-177. February, 1993. PRESSMAN, R. S.. Software Engineering: A practitioners approach. 6a ed. McGraw-Hill. New York, 2004. RUDOLPH, S.. On a Mathematical Foundation of Axiomatic Design. Proceedings of the 1996 ASME Design Engineering Technical Conference and Computers in Engineering Conference. USA. 1996. RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.. Object-Oriented Modeling and Design. Prentice Hall. 1991. SCHREYER, M.; TSENG M. M.. Hierarchical State Decomposition for the design of PLC Software by Applying Axiomatic Design. In: Proceedings of ICAD2000 First International Conference On Axiomatic Design. Cambridge, MA. June, 2000. SHIN, G. S.; YI, J. W.; YI, S. I.; KWON, Y. D.; PARK, G. J.. Calculation of Information Content in Axiomatic Design. In Proceedings of the 3rd International conference on axiomatic design ICAD2004. Seul Korea, june, 2004. STADZISZ, P. C.. Contribuition une Mthodologie de Conception Intgre des Familles de Produits pour lAssemblage. LUniversite de Franche-Comte. (Tese de doutorado). 1997. SUH, N. P.. Axiomatic design: Advances and Applications. Oxford University Press. New York, 2001. SUH, N. P.. The Principles of Design. Oxford University Press. New York, 1990. SUH, N. P.; BELL, A. C.; GOSSARD, D. C.. On an Axiomatic Approach to Manufactoring and Manufactoring Systems. Journal of Engineering for Industry. Vol. 100, no. 2, p. 127130. 1978. SUH, N. P.; DO, S.. Axiomatic Design of Software Systems. .In: CIRP Annals. Vol. 49, n. 100, p. 95-100. Sydney, Australia, 2000. TAGUCHI, G.. Systems of Engineering Design: Engineering Methos to Optimize Quality and Minimize Cost. American Supplier Institute. Dearborn, MI, 1987. TATE, D.. A Roadmap for decomposition: Activities, Theories, and Tools for System Design. PhD thesis, Department of Mechanical Engineering at Massachusetts Institute of Technology, Cambridge, Massachusetts, 1999.

79

TATE, D.; NORLUND, M.. A Design Process Roadmap as a General Tool for Structuring and Supporting Design Activities. In: Proceedings of the Second World Conference on Integrated Design and Process Tecnology (IDPT vol. 3). Society for Design and Process Science, Austin TX. Pp. 97-104. December 1996. ULRICH, K. T.; EPPINGER, S. D.. Product Design and Development. McGraw-Hill. New York: 2003. VAZQUEZ, C. E.; SIMES, G. S.; ALBERT, R. M.. Anlise de Pontos de Funo: medio, estimativas e gerenciamento de projetos de software. rica. So Paulo: 2003. ZADEH, L. A.; FU, K.S.; TANAKA, K.; SHIMURA, M.. Fuzzy Sets and their Applications to Cognitive and Decision Processes. Academic press.1974.