Proposta de um método de aplicação da teoria de projeto axiomático ao desenvolvimento de software PON-POR

Texto

(1)UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ PROGRAMA DE PÓS GRADUAÇÃO EM ENGENHARIA ELÉTRICA E INFORMÁTICA INDUSTRIAL. MÁRCIO VENÂNCIO BATISTA. PROPOSTA DE UM MÉTODO DE APLICAÇÃO DA TEORIA DE PROJETO AXIOMÁTICO AO DESENVOLVIMENTO DE SOFTWARE PON-POR. DISSERTAÇÃO. CURITIBA 2013.

(2) MÁRCIO VENÂNCIO BATISTA. PROPOSTA DE UM MÉTODO DE APLICAÇÃO DA TEORIA DE PROJETO AXIOMÁTICO AO DESENVOLVIMENTO DE SOFTWARE PON-POR. Dissertação apresentada ao Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial da Universidade Tecnológica Federal do Paraná, como requisito parcial à obtenção do título de Mestre em Ciências – Área de Concentração Engenharia de Computação. Orientador: Prof. Dr. Jean Marcelo Simão. CURITIBA 2013.

(3)

(4) Dedico este trabalho a minha família e amigos que me apoiaram durante toda a caminhada..

(5) AGRADECIMENTOS. Aos meus pais, irmãos e verdadeiros amigos pelo amor e pelo apoio que sempre me deram. Ao prof. Dr. Jean Marcelo Simão por ter acreditado em mim e ter me aceito como seu orientado e pela dedicação, paciência e empenho para a realização deste trabalho..

(6) O que não dá prazer não dá proveito. Em resumo, senhor, estude apenas o que lhe agradar. (SHAKESPEARE, William, 1596).

(7) RESUMO. BATISTA, Márcio Venâncio. Proposta de um Método de Aplicação da Teoria de Projeto Axiomático ao Desenvolvimento de Software PON-POR. 2013. 241 f. Dissertação. Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial (CPGEI), Universidade Tecnológica Federal do Paraná (UTFPR) – Paraná, Curitiba, 2013.. Esta pesquisa propõe um método que aplica a Teoria de Projeto Axiomático (PA) ao processo de desenvolvimento de software que se orientam por regras. Nesse âmbito, salienta-se que não foi encontrada na literatura, durante os esforços de pesquisa deste trabalho, a aplicação da Teoria de Projeto Axiomático a sistemas orientados a Regras. Entretanto, a Teoria de Projeto Axiomático já sim foi foco de pesquisa e aplicação no processo de desenvolvimento de software orientado a objeto, servindo de inspiração ao presente trabalho. Dito isso, este trabalho propõe o método Projeto Axiomático aplicado ao Paradigma Orientado a Notificações e ao Paradigma Orientado a Regras (PA-PON-POR) desde que as regras sigam o modelo de estruturação dado pelo PON. O método PA-PON-POR propõe a decomposição funcional de requisitos do sistema em quatro níveis que são: Casos de Uso, Subcasos de Uso Independentes de Características Técnicas, Subcasos de Uso Dependentes de Características Técnicas e Serviços Técnicos. Além disso, o método PA-PON-POR aplica o Axioma da Independência do PA em cada um dos quatro níveis de decomposição por meio das matrizes de projeto e métricas de cálculo da reangularidade e semangularidade do próprio PA. As matrizes de projeto ainda auxiliam na identificação das Premissas exclusivas, elementos esses importantes quando um sistema PON-POR possui Regras que possuem Ações que instigam a geração de fatos conflitantes. O Axioma da Informação do Projeto Axiomático também é aplicado em cada nível de decomposição avaliando as soluções de projeto quanto a sua quantidade de informação. Ainda, o método PAPON-POR apresenta um conjunto de métricas especificas para avaliação da qualidade estrutural da composição de Regras do sistema, fornecendo critérios para tomada de decisão sobre a qualidade do projeto especificado. Além disso, o método PA-PON-POR é passível de aplicação simultânea com o método existente de projeto de software baseado em desenvolvimento de aplicações PON-POR chamado de Desenvolvimento Orientado a Notificações e Orientado a Regras (DON-DOR), auxiliando na obtenção e validação de artefatos do mesmo. O método PA-PON-POR foi aplicado no desenvolvimento de dois softwares, o primeiro software refere-se um simulador de portão eletrônico e o segundo software refere-se a um sistema de vendas. Em ambas as aplicações, o método PA-PON-POR demonstrou ser eficiente no que se propõe, auxiliando no processo de criação de Regras e de sistemas PONPOR com alguma garantia de qualidade.. Palavras-chave: Projeto Axiomático (PA). Paradigma Orientado a Regras (POR). Paradigma Orientado a Notificações (PON). Método de Desenvolvimento Orientado a Notificações e Orientado a Regras (DON-DOR).

(8) ABSTRACT. BATISTA, Márcio Venâncio. A Proposal of a Method of Application of Axiomatic Design Theory in Development of NOP-ROP Software. 2013. 241 f. Dissertação. Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial (CPGEI), Universidade Tecnológica Federal do Paraná (UTFPR) – Paraná, Curitiba, 2013.. This research proposes a method to apply the Axiomatic Design Theory (ADT) in the Rule-oriented software development process. In this context, it was not found in the literature, by the efforts of this work research, the application of ADT in Rule-oriented software development. However, the ADT was focus on research in Object-Oriented software development in a previous work, which was used as inspiration in this current research work. This current research proposes the method Axiomatic Design for Notification-Oriented Paradigm and Rule-Oriented Paradigm (AD-NOP-ROP) since the rules follow the NOP structural model. This method proposes a functional decomposition of system requirements in four levels which are: Use Cases, Use Subcases that are Technical Feature Independent, Use Subcases that are Technical Feature Dependent, and Technical Service . Furthermore, the method AD-NOP-ROP applies the ADT Independence Axiom in each one of the decomposition levels by means of design matrixes and metrics which calculates reangularity and semangularity from ADT. The design matrixes still aids in the identification of Exclusive Premises, which are important elements of NOP-ROP systems with Rules whose Actions instigate the creation of conflicting facts. The Information Axiom from ADT is also applied in each decomposition level in order to evaluate design solutions in terms of its amount of information. Still, the method AD-NOP-ROP presents a set of metrics which are specific for evaluation of structural quality of Rule composition, thereby providing criteria for decision making with respect to design quality. Besides, the method AD-NOP-ROP can be used in a simultaneous way with the existent method used for software design based on NOP-ROP application development, so called Notification-Oriented and Rule-Oriented Application Development (NO-ROAD), in order to assist in the achievement and validation of artifacts. The method ADNOP-ROP was applied during the development of two software systems, the first one refers to an Electronic Gate and the second one refers to a Sales System. In both applications the method displayed efficiency in its purposes, assisting in the Rule creation process and also in the creation of NOP-ROP software with some quality assurance.. Keywords: Axiomatic Design (AD). Rule-Oriented Paradigm (ROP). NotificationOriented Paradigm (NOP). Notification-Oriented and Rule-Oriented Development Method (NOD-ROD)..

(9) LISTA DE ILUSTRAÇÕES. Figura 1 - Engenharia de Software em Camadas ..................................................... 29 Figura 2 – Processo unificado ................................................................................... 35 Figura 3 – Estrutura do Processo unificado .............................................................. 37 Figura 4 – Tabela de rastreamento genérico............................................................. 45 Figura 5 – Classificação dos paradigmas de programação (RONSZCKA, 2012)...... 48 Figura 6 – Arquitetura Interna de um SBR ................................................................ 50 Figura 7 – Exemplo de uma Rule em PON ............................................................... 53 Figura 8 – Relação entre o PON e os paradigmas usuais ........................................ 54 Figura 9 – Cadeia de Notificações ............................................................................ 55 Figura 10 – Principais entidades do PON e seus relacionamentos ........................... 56 Figura 11 – Modelo Centralizado de Resolução de Conflitos .................................... 58 Figura 12 – Definição de Premise Exclusive em código C++ .................................... 61 Figura 13 – Mecanismo de extensão da UML ........................................................... 63 Figura 14 – NOP Profile pacote core......................................................................... 65 Figura 15 – NOP Profile Application pacote application ............................................ 66 Figura 16 – NOP Profile – NOP Core Association..................................................... 67 Figura 17 – NOP Profile – POR Core Association..................................................... 67 Figura 18 – Exemplo de Rede de Petri ..................................................................... 69 Figura 19 – DON contextualizado no PU .................................................................. 70 Figura 20 – Método DON-DOR e suas etapas .......................................................... 71 Figura 21 – Modelo de Classes do Método DON-DOR ............................................. 72 Figura 22 – Exemplo de um Modelo de Componentes ............................................. 73 Figura 23 – Exemplo do Modelo de Redes de Petri .................................................. 73 Figura 24 – Domínios de Projeto ............................................................................... 76 Figura 25 – Processo em Zig-zag ............................................................................. 77 Figura 26 – Matriz de Projeto Desacoplada .............................................................. 78 Figura 27 – Matriz de Projeto Semiacoplada............................................................. 79 Figura 28 – Matriz de Projeto Acoplada .................................................................... 79 Figura 29 – Matriz exemplo para cálculo da independência funcional ...................... 81 Figura 30 – Processo de Desenvolvimento Axiomático de Software ........................ 84 Figura 31 – Realização de Casos de Uso ................................................................. 88 Figura 32 – Decomposição de Casos de Uso e Colaborações ................................. 88 Figura 33 – Níveis da Hierarquia Funcional .............................................................. 90 Figura 34 - Domínios de Projeto Axiomático e as Fases do Processo Unificado ...... 91 Figura 35 – Matriz de Projeto inconsistente com a matriz anterior ............................ 93 Figura 36 – Etapas da abordagem de Pimentel ........................................................ 94 Figura 37 – Atividades realizadas em cada etapa da abordagem de Pimentel ......... 95 Figura 38 – Exemplo de Matriz de Projeto Desacoplada .......................................... 97.

(10) Figura 39 – Colaboração e seus papéis. ................................................................. 104 Figura 40 – Etapas do Método PA-PON-POR......................................................... 108 Figura 41 – Atividades realizadas na quarta etapa do método proposto................. 112 Figura 42 – Mapeamento entre RFs e PPs (FBEs) referente a terceira atividade da quarta etapa ............................................................................................................ 114 Figura 43 – Matrizes de Projeto referentes às atividades do quarto nível de decomposição ......................................................................................................... 115 Figura 44 – Casos de uso do projeto de software de portão eletrônico .................. 118 Figura 45 – Colaboração do caso de uso Abrir Portão............................................ 119 Figura 46 – Matriz A : Matriz de Projeto do 1º Nível ................................................ 119 Figura 47 – Matriz B : Matriz de Projeto do 1º Nível ................................................ 120 Figura 48 – Portão eletrônico deslizante, pivotante e basculante ........................... 121 Figura 49 – Subcasos de uso incluídos do projeto de software de portão eletrônico ................................................................................................................................ 122 Figura 50 – Colaboração do Subcaso de uso incluído Acender a Luz .................... 123 Figura 51 – Colaboração do Subcaso de uso Abrir Portão ..................................... 123 Figura 52 – Matriz C: Matriz de projeto de 2º Nível ................................................. 124 Figura 53 – Matriz D: Matriz de projeto de 2º Nível ................................................. 124 Figura 54 – Matriz E: Matriz de projeto de 2º Nível ................................................. 125 Figura 55 – Colaboração do Subcaso de uso Verificar Estado do Portão............... 130 Figura 56 – Matriz F: Matriz de projeto de 3º Nível ................................................. 131 Figura 57 – Matriz G: Matriz de projeto de 3º Nível ................................................. 132 Figura 58 – Matriz H: Matriz de Projeto de 4º Nível ................................................ 136 Figura 59 – Matriz I: Matriz de Projeto de 4º Nível .................................................. 137 Figura 60 – Matriz J: Matriz de Projeto de 4º Nível ................................................. 138 Figura 61 – Submatriz K: Submatriz de projeto de 4º Nível - Premissas................. 142 Figura 62 – Submatriz L: Submatriz de projeto de 4º Nível – Instigações ............... 143 Figura 63 – Submatriz M: Submatriz de projeto de 4º Nível - Premissas ................ 147 Figura 64 – Submatriz N: Submatriz de projeto de 4º Nível – Instigações .............. 147 Figura 65 – Submatriz O: Submatriz de projeto de 4º Nível - Premissas ................ 149 Figura 66 – Submatriz P: Submatriz de projeto de 4º Nível – Instigações .............. 150 Figura 67 – Submatriz Q: Análise da Submatriz de projeto de 4º Nível – Premissas ................................................................................................................................ 152 Figura 68 – Submatriz R: Análise da Submatriz de projeto de 4º Nível – Instigações ................................................................................................................................ 154 Figura 69 – Submatriz S: Análise parcial da Submatriz de projeto de 4º Nível – Premissas................................................................................................................ 156 Figura 70 – Submatriz T: Análise parcial da Submatriz de projeto de 4º Nível – Instigações .............................................................................................................. 157 Figura 71 – Submatriz U: Análise parcial da Submatriz de projeto de 4º Nível – 2ª Versão – Instigações ............................................................................................... 158 Figura 72 – Submatriz V: Análise parcial da Matriz de projeto de 4º Nível – Instigações .............................................................................................................. 160.

(11) Figura 73 – Acoplamento Aferente e Eferente ........................................................ 167 Figura 74 – Redes de Petri referente às Regras apresentadas na Tabela 6 .......... 175 Figura 75 – Redes de Petri referente às Regras apresentadas na Tabela 7 .......... 176 Figura 76 – Redes de Petri referente às Regras apresentadas na Tabela 8 .......... 177 Figura 77 – Métricas orientadas a Regras aplicadas às Regras da Tabela 6 ......... 178 Figura 78 – Métricas orientadas a Regras aplicadas às Regras da Tabela 7 ......... 178 Figura 79 – Métricas orientadas a Regras aplicadas às Regras da Tabela 8 ......... 179 Figura 80 – Correspondência entre o Método DON-DOR e Método PA-OR ........... 183 Figura 81 – Casos de Uso do Sistema de Vendas .................................................. 190 Figura 82 – Matriz de Projeto AA - 1º Nível para o sistema de vendas ................... 191 Figura 83 – Papéis da colaboração “PP1 - Efetuar Compra” .................................. 191 Figura 84 – Papéis da colaboração “PP2 – Cancelar Compra” ............................... 192 Figura 85 – Subcasos de uso independentes – 2º Nível de decomposição ............ 193 Figura 86 – Papéis da colaboração “PP1.1 – Criar Pedido de Venda”.................... 194 Figura 87 – Matriz de Projeto AB - 2º Nível para o sistema de vendas ................... 195 Figura 88 – Subcasos de uso independentes – 2º Nível – Solução alternativa....... 196 Figura 89 – Matriz de Projeto AC - 2º Nível – solução alternativa ........................... 197 Figura 90 – Matriz de Projeto AD - 3º Nível para o sistema de vendas ................... 199 Figura 91 – Matriz de Projeto AE - 4º Nível para o sistema de vendas ................... 201 Figura 92 – Matriz de Projeto AF - 4º Nível para o sistema de vendas ................... 202 Figura 93 – Modelo de Classes para o sistema de vendas ..................................... 203 Figura 94 – Matriz de Projeto AG - 4º Nível – Premissas do sistema de vendas .... 204 Figura 95 – Matriz de Projeto AH - 4º Nível – Instigações do sistema de vendas ... 206 Figura 96 – Modelo de Regras para o sistema de vendas ...................................... 208 Figura 97 – Redes de Petri para o sistema de vendas............................................ 210 Figura 98 – Novo Modelo de Regras para o sistema de vendas ............................. 212 Figura 99 – Métricas do Axioma da Informação para o sistema de vendas ............ 214.

(12) LISTA DE TABELAS. Tabela 1 – Razões para fracasso em projetos de software ...................................... 41 Tabela 2 – Requisitos Funcionais e Parâmetros de Projeto correspondente ............ 89 Tabela 3 – Métrica de Complexidade ........................................................................ 98 Tabela 4 – Requisitos Funcionais e Parâmetros de Projeto correspondentes ........ 106 Tabela 5 – Exemplo do Modelo de Regras ............................................................. 115 Tabela 6 – Modelo de Regras referente às subamtrizes K e L................................ 145 Tabela 7 – Modelo de Regras referentes às submatrizes M e N............................. 148 Tabela 8 – Modelo de Regras referente às submatrizes O e P ............................... 150 Tabela 9 – Métricas de complexidade e tipos de requisitos funcionais destinadas ao POR ........................................................................................................................ 164 Tabela 10 – Ìndice de Instabilidade de Regras ....................................................... 170.

(13) LISTA DE ACRÔNIMOS. AC. Afferent Coupling - Acoplamento Aferente. AI. Axioma da Independência. AInf. Axioma da Informação. CASE. Computer-Aided Software Engineering. DON. Desenvolvimento Orientado a Notificações. DOR. Desenvolvimento Orientado a Regras. EF. Efferent Coupling - Acoplamento Eferente. ER. Engenharia de Requisitos. ES. Engenharia de Software. FBE. Fact Base Element - Elemento da Base de Fatos. IN. Instability Index - Índice de Instabilidade. NC. Necessidade do Cliente. NI. Number of Instigations - Número de Instigações. NP. Number of Premises - Número de Premissas. PA. Projeto Axiomático. PD. Paradigma Declarativo. PI. Paradigma Imperativo. PON. Paradigma Orientado a Notificações. POR. Paradigma Orientado a Regras. PP. Parâmetro de Projeto. PU. Processo Unificado. RF. Requisito Funcional. RNF. Requisito Não Funcional. RUP. Rational Unified Process – Rational Processo Unificado. SADT. Structured Analysis and Design Technique – Técnica de Análise e Projeto Estruturado. SBR. Sistema Baseado em Regras. TPA. Teoria de Projeto Axiomático. UC. Use Case (Caso de Uso). UML. Unified Modeling Language – Linguagem de Modelagem Unificada. VP. Variável de Processo.

(14) SUMÁRIO. 1 INTRODUÇÃO .....................................................................................................16 1.1 CONTEXTO DO TRABALHO ...........................................................................16 1.1.1 Teoria de Projeto Axiomático ..........................................................................19 1.1.2 Paradigma Orientado a Notificações ..............................................................20 1.1.3 Questionamento do Trabalho..........................................................................22 1.2 OBJETIVOS ......................................................................................................23 1.3 MOTIVAÇÃO ....................................................................................................24 1.4 ORGANIZAÇÃO DO TRABALHO .....................................................................25 2 FUNDAMENTAÇÃO TEÓRICA ...........................................................................27 2.1 ENGENHARIA DE SOFTWARE .......................................................................27 2.1.1 Definições Iniciais da Engenharia de Software ...............................................28 2.1.2 Projeto de Software ........................................................................................29 2.1.3 Processo de Software .....................................................................................31 2.1.4 Modelos de Processo de Software .................................................................33 2.1.5 Processo Unificado .........................................................................................34 2.1.5.1 Estrutura dinâmica ......................................................................................36 2.1.5.2 Estrutura estática ........................................................................................37 2.2 ENGENHARIA DE REQUISITOS .....................................................................39 2.2.1 Definições Iniciais da Engenharia de Requisitos ............................................39 2.2.2 Requisitos de Software ...................................................................................41 2.2.3 Divisão dos Requisitos....................................................................................42 2.2.4 Processo de Engenharia de Requisitos ..........................................................43 2.2.5 Rastreamento de requisitos ............................................................................44 2.2.6 Considerações ................................................................................................46 2.3 PARADIGMAS DE PROGRAMAÇÃO...............................................................47 2.3.1 Visão Geral .....................................................................................................47 2.3.2 Classificação dos Paradigmas de Programação Usuais .................................47 2.3.3 Deficiências dos Paradigmas Usuais ..............................................................51 2.3.4 Paradigma Orientado a Notificações ..............................................................53 2.3.4.1 Mecanismo de notificações .........................................................................54 2.3.4.2 Resolução de conflitos no PON ..................................................................57 2.3.4.3 Materialização do PON ...............................................................................59 2.3.4.3.1 Particularidade do PON referente às premissas .......................................60 2.3.5 Desenvolvimento Orientado a Notificações / Orientado a Regras ..................62 2.3.5.1 Perfil UML para o PON – NOP profile .........................................................63 2.3.5.2 Generalização do NOP Profile ....................................................................66 2.3.5.3 Redes de Petri ............................................................................................68 2.3.5.4 Processo de desenvolvimento orientado a notificações..............................70.

(15) 2.4 PROJETO AXIOMÁTICO..................................................................................74 2.4.1 Introdução à Teoria de Projeto Axiomático .....................................................74 2.4.2 Domínios de Projeto .......................................................................................75 2.4.3 Axioma da Independência ..............................................................................77 2.4.4 Axioma da Informação ....................................................................................81 2.4.5 Complexidade no Projeto Axiomático .............................................................82 2.4.5.1 Complexidade independente do tempo.......................................................82 2.4.5.2 Complexidade dependente do tempo .........................................................83 2.4.6 Projeto Axiomático aplicado ao Desenvolvimento de Software ......................84 2.4.7 Projeto de Software baseado em Projeto Axiomático .....................................85 2.4.7.1 Aspectos gerais...........................................................................................86 2.4.7.2 Domínios de projeto e fases do Processo Unificado ...................................90 2.4.7.3 Etapas e atividades da abordagem .............................................................92 2.4.7.4 Aplicação do axioma da independência ......................................................95 2.4.7.5 Aplicação do axioma da informação ...........................................................97 2.5 CONCLUSÕES .................................................................................................99 3 PROPOSTA DE UM MÉTODO DE APLICAÇÃO DA TEORIA DE PROJETO AXIOMÁTICO AO DESENVOLVIMENTO DE SOFTWARE PON-POR .................101 3.1 INTRODUÇÃO AO MÉTODO PROPOSTO ......................................................102 3.2 DEFINIÇÕES INICIAIS .....................................................................................103 3.3 ETAPAS DO MÉTODO PROPOSTO................................................................107 3.4 ATIVIDADES DAS ETAPAS .............................................................................110 3.5 DECOMPOSIÇÃO FUNCIONAL NO PROJETO DE SOFTWARE PON-POR..116 3.5.1 Decomposição Funcional na Etapa de Modelagem de Casos de Uso ...........118 3.5.2 Decomposição Funcional na Etapa de Modelagem de Subcasos de Uso Independentes de Características Técnicas ...........................................................121 3.5.3 Decomposição Funcional na Etapa de Modelagem de Subcasos de Uso Dependentes de Características Técnicas ..............................................................128 3.5.4 Decomposição Funcional na Etapa de Modelagem de Serviços Técnicos .....134 3.5.4.1 Primeiro grupo de atividades - modelagem de Elementos da Base de Fatos (Fact Base Elements - FBEs) ..................................................................................135 3.5.4.2 Segundo e terceiro grupo de atividades - modelagem de Premissas e Instigações ..............................................................................................................141 3.5.5 Reflexões Sobre a Exclusividade de Premissas .............................................151 3.5.5.1 Considerações ............................................................................................161 3.6 AXIOMA DA INFORMAÇÃO .............................................................................162 3.6.1 Cálculo do Conteúdo de Informação na 1ª e 2ª Etapas ..................................164 3.6.2 Cálculo do Conteúdo de Informação na 3ª Etapa do Método PA-PON-POR..165 3.6.3 Cálculo do Conteúdo de Informação na 4ª Etapa do Método PA-PON-POR..166 3.6.3.1 Acoplamento aferente ou nível de responsabilidade...................................167 3.6.3.2 Acoplamento eferente ou nível de dependência .........................................168 3.6.3.3 Índice de instabilidade.................................................................................169.

(16) 3.6.3.4 Tamanho de Regra .....................................................................................171 3.6.3.5 Cálculo do conteúdo de informação ............................................................171 3.6.4 Aplicação do Cálculo de Conteúdo da Informação .........................................174 3.7 MÉTODO PA-PON-POR APLICADO NAS ETAPAS DO MÉTODO DON-DOR ………………………………………………………………………………………………181 3.8 CONCLUSÃO ...................................................................................................185 4 CASO DE ESTUDO..............................................................................................187 4.1 OBJETIVOS DO CASO DE ESTUDO...............................................................187 4.2 JUSTIFICATIVA PARA A ESCOLHA DO CASO DE ESTUDO ........................187 4.3 DESCRIÇÃO DO CASO DE ESTUDO .............................................................188 4.4 DECOMPOSIÇÃO FUNCIONAL NA ETAPA DE MODELAGEM DE CASOS DE USO ........................................................................................................................189 4.5 DECOMPOSIÇÃO FUNCIONAL NA ETAPA DE MODELAGEM DE SUBCASOS DE USO INDEPENDENTES DE CARACTERÍSTICAS TÉCNICAS........................192 4.6 DECOMPOSIÇÃO FUNCIONAL NA ETAPA DE MODELAGEM DE SUBCASOS DE USO DEPENDENTES DE CARACTERÍSTICAS TÉCNICAS ...........................198 4.7 DECOMPOSIÇÃO FUNCIONAL NA ETAPA DE MODELAGEM DE SERVIÇOS TÉCNICOS ..............................................................................................................200 4.8 MODELO DE REGRAS DO SISTEMA .............................................................207 4.9 CONCLUSÃO ...................................................................................................216 5 CONCLUSÕES E TRABALHOS FUTUROS .......................................................219 5.1 CONCLUSÕES .................................................................................................219 5.2 TRABALHOS FUTUROS ..................................................................................222 REFERÊNCIAS .......................................................................................................224 ANEXO A – TEOREMAS E COROLÁRIOS RELACIONADOS COM OS AXIOMAS …………………………………………………………………………………………….235 A.1 COROLÁRIOS ..................................................................................................235 A.2 TEOREMAS GERAIS DE PROJETO ...............................................................236 A.3 TEOREMAS RELACIONADOS COM PROJETO DE SOFTWARE ..................241.

(17) 16. 1 INTRODUÇÃO. Esta dissertação apresenta um método baseado na Teoria de Projeto Axiomático (TPA) que auxilia no desenvolvimento de aplicações concebidas com o Paradigma Orientado a Regras (POR) e Paradigma Orientado a Notificações (PON). Este capítulo apresenta o tema da dissertação, o contexto no qual o tema está inserido e os problemas e necessidades que motivaram a realização do trabalho. Neste capítulo, ademais, são apresentados ainda os objetivos gerais e específicos a serem alcançados pela pesquisa. Por fim, também será apresentada a organização dos capítulos desta dissertação. Mais precisamente, a Seção 1.1 apresenta o tema e contexto em que este trabalho se enquadra. A Seção 1.2 apresenta os objetivos gerais e específicos do trabalho. A Seção 1.3, por sua vez, resume os fatores motivadores do tema em questão. A Seção 1.4, por fim, apresenta a organização dos capítulos que compõem esta dissertação de mestrado.. 1.1 CONTEXTO DO TRABALHO. O processo de desenvolvimento de software tem sido estudado desde a criação do primeiro computador na década de 40 (BROOKSHEAR, 2006). Desde então, os processadores tem tido um crescimento exponencial seguindo a “lei de Moore”1 (MOORE, 1965). Com o constante crescimento da utilização dos computadores e alta escalabilidade de produção, o custo dessas máquinas pôde ser diminuído, possibilitando que pessoas comuns pudessem ter seu próprio computador (BEZERRA, 2002). De fato, a partir da década de 70, o computador passou a não ser apenas utilizado por grandes empresas, mas também passou a ser utilizado como ferramenta comum de trabalho, equipamento de comunicação, entretenimento. 1. Segundo as afirmações feitas em 1965 por Gordon Moore, as quais fundamentaram a Lei de Moore, a capacidade de processamento tende ao crescimento exponencial (MOORE, 1965). Segundo ele, a quantidade de transistores alojada em uma placa de silício duplica a cada 24 meses, contribuindo para o aumento da capacidade de processamento dos computadores (MOORE, 1965)..

(18) 17. dentre outros (BEZERRA, 2002). Com esta crescente utilização dos computadores, cresceu também a demanda de softwares cada vez maiores e complexos para atender os diferentes públicos usuários do computador (WINCK; GOETTEN, 2006). Paralelos a esse crescimento, no decorrer do tempo foram identificados problemas relativos à elaboração e desenvolvimento de projetos de software. Logo no início dos anos 70, por exemplo, surgiu o termo “Crise de Software” visando expressar as dificuldades enfrentadas pelos desenvolvedores na elaboração de seus projetos (DIJKSTRA, 1972). Naquela época, a engenharia de software era quase que inexistente e os problemas mais comuns no desenvolvimento de software já costumavam ser: acréscimos no orçamento, aumento do prazo previsto, baixa qualidade dos projetos, produtos que muitas vezes não atendiam os requisitos, e códigos difíceis de manter (BROOKS, 1987). Subsequentemente, com a crescente exigência por software de qualidade e o alto número de horas dedicado a fim de alcançar essa qualidade, os custos de desenvolvimento, bem como o de manutenção de sistemas computacionais foram elevados (BROOKS, 1987). Por outro lado, não era possível desenvolver software que pudesse satisfazer toda a demanda, em termos de diversidade, quantidade e complexidade (BROOKS, 1987). Portanto, o processo de desenvolvimento de software teve que, ao menos um tanto, evoluir para fazer alguma frente às pressões por redução de custos e aumento da produtividade (WINCK; GOETTEN, 2006). Neste contexto pela busca de melhoria na criação de software, novas linguagens foram criadas (i.e. Fortran, COBOL, C, Smalltalk, C++, Java2) enquadrando-se ou mesmo alavancando, paradigmas de desenvolvimento (i.e. Paradigma Procedimental, Paradigma Orientado a Objetos, Paradigma Funcional, Paradigma Lógico3). Além disso, novas abordagens foram propostas e, à medida que a importância do software crescia, surgiram novos métodos4 e técnicas para o seu desenvolvimento.. 2. Fortran, Cobol e C são linguagens de programação da Terceira Geração (1954). Smalltalk, C++ e Java são linguagens de programação de Quarta Geração (1970) (BROOKSHEAR, 2006). 3 Paradigma Procedimental (PP) e Paradigma Orientado a Objetos (POO) são considerados como Paradigmas Imperativos (PI). Ao passo que o Paradigma Funcional (PF) e o Paradigma Lógico (PL) são considerados como Paradigmas Declarativos (BANASZEWSKI, 2009). 4 Um método de desenvolvimento de software é caracterizado pela utilização de uma linguagem de modelagem mais um processo de desenvolvimento de software. Alguns processos de.

(19) 18. Apesar desse histórico evolutivo, a qualidade do software não é facilmente alcançada. Nesse contexto, Pressman (2006) diz que os requisitos de software podem ser utilizados para fundamentar a medição da qualidade. Ele complementa isso dizendo que um projeto de alta qualidade levará a um software que exiba qualidade. Ou seja, a qualidade do software está intimamente ligada à qualidade do projeto. Na verdade, nesse mesmo âmbito vislumbrado por Pressman, a qualidade do software também está ligada ao processo de desenvolvimento do mesmo. Um processo de desenvolvimento de software bem definido e gerenciado, ao bem da verdade, pode estabelecer se o projeto de software será bem sucedido ou não (JACOBSON; BOOCH; RUMBAUGH, 1999). Ainda neste contexto, em 1968, Friedrich Ludwig Bauer percebeu que o processo de desenvolvimento de software necessitava ser mais sistemático e controlado (BAUER, 1968). Na verdade, ele percebeu que tal processo se assemelhava muito com um processo convencional de engenharia no tocante a sistematização necessária (BAUER, 1968). Neste interim surgiu o termo Engenharia de Software. Segundo Friedrich Ludwig Bauer, “Engenharia de software” é a criação e a utilização de sólidos princípios de engenharia a fim de se obter softwares de maneira econômica, que sejam confiáveis e que trabalhem eficientemente em máquinas reais (BAUER, 1968). Anos mais tarde Pressman definiu a “Engenharia de software” como a área de conhecimento da computação responsável por oferecer meios para a elaboração de projetos de software (PRESSMAN, 2006). De maneira mais específica, a “Engenharia de software” compreende um conjunto. de. etapas. que. envolvem. métodos,. ferramentas,. processos. e. procedimentos. Uma sequência dessas etapas com feedbacks que resultam na produção e na evolução de um software é chamada de “Processo de Engenharia de Software”. Uma visão tradicional do processo de software é uma sequência de atividades de desenvolvimento do produto (PRESSMAN, 2006). Entre os processos de Engenharia de Software atuais destaca-se o Processo Unificado, da empresa Rational, conhecido como RUP (acrônimo de Rational Unified Process) (KRUCHTEN, 2003). O RUP é um processo proprietário de Engenharia de Software baseado em fases e “disciplinas”, que atribui tarefas e.

(20) 19. responsabilidades dentro de uma organização de desenvolvimento, sendo baseado em uma abordagem iterativa (KRUCHTEN, 2003). Em suma, a meta do RUP é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de cronogramas e orçamentos desejáveis. Um projeto elaborado em RUP faz uso da orientação a objetos, sendo projetado e documentado utilizando a notação da Linguagem de Modelagem Unificada (UML - Unified Modeling Language) (KRUCHTEN, 2003). De fato, toda essa evolução do processo de criação de software, ao longo dos anos, contribui para o estado da arte e da técnica que hoje em dia os desenvolvedores, analistas e projetistas de software dispõem. Graças a toda essa evolução, com o ferramental disponível é possível criar softwares mais confiáveis, precisos. e. controláveis,. quando. comparados. aos. produzidos. antigamente. (PRESSMAN, 2006). Um dos fatores que contribuem com esse cenário evolutivo certamente está relacionado ao fato de novas pesquisas estarem sendo feitas nessa área. Isso faz com que novos processos, métodos e metodologias venham a ser propostos, visando à melhoria de todo o processo de desenvolvimento de software. Uma das vertentes dessas novas contribuições se apresenta na utilização de métodos que anteriormente eram aplicados à engenharia convencional e que agora são aplicados ao processo de desenvolvimento de software. Um desses estudos está relacionado à utilização do Projeto Axiomático que foi inicialmente utilizado em projetos. de. engenharia. mecânica,. principalmente. no. tocante. à. indústria. automobilística (DEO & SUH, 2004).. 1.1.1 Teoria de Projeto Axiomático. A Teoria de Projeto Axiomático (SUH, 1990) surgiu como um processo para projeto de produtos, peças e componentes, tendo sido usado em diversas áreas da Engenharia. Esse processo é baseado em conceitos de independência entre os requisitos funcionais do projeto e na minimização do conteúdo de informação do projeto.. Entretanto, dada a sua generalidade conceitual, o Projeto Axiomático. passou a ser aplicado em outras áreas como indústria eletrônica (DO e PARK, 1996) e manufatura (KULAK, DURMUSOGLU e TUFEKI, 2005)..

(21) 20. Os conceitos de Projeto Axiomático podem também e particularmente serem aplicados no desenvolvimento de software visando melhorar a qualidade do processo de desenvolvimento, garantindo (até certo ponto) a qualidade do produto desenvolvido. Neste sentido, houve trabalhos precedentes sobre Projeto Axiomático para o desenvolvimento de software (DO e SUH, 1999, 2000; SUH, 2001; DO, 2004; PIMENTEL, 2007; PEREIRA, 2010). Em sua tese, particularmente, Andrey Pimentel abordou a utilização dos princípios da Teoria de Projeto Axiomático para o desenvolvimento orientado a objeto de software. Dentre eles estão: critérios para tomada de decisões de projeto, conceitos, ferramentas e sua natureza independente de domínio. Todo esse arcabouço conceitual serviu para aprimorar o processo de desenvolvimento de software orientado a objetos utilizando o Processo Unificado (PIMENTEL, 2007). Mais tarde, Pereira (2010) estende a pesquisa de Pimentel (2007) e propõe a aplicação da Teoria de Projeto Axiomático na especificação de requisitos de sistemas de software e na integração da abordagem no fluxo de requisitos do Processo Unificado. Além de todos esses avanços no campo da aplicação do Projeto Axiomático ao projeto de software, outras pesquisas têm sido desenvolvidas no campo correlato da criação, eficiência e coesão/desacoplamento de módulos em software. De fato, estas características de um software podem ser afetadas por diversas razões, uma delas é o paradigma de programação utilizado. Nesse âmbito a próxima seção apresenta o Paradigma Orientado a Notificações (PON) como um paradigma de programação emergente que visa à criação de softwares mais eficientes.. 1.1.2 Paradigma Orientado a Notificações. Todo avanço tecnológico dos computadores decorrente da supremacia da “lei de Moore” durante todos estes anos, vem afetando os hábitos dos programadores de computadores, desestimulando-os a criar programas ou software mais eficientes em termos de recursos computacionais. Entretanto, é a eficiência de software, inclusive em termos de economia de processamento, que define o uso.

(22) 21. efetivo e correto da capacidade de processamento disponível (SIMÃO e STADZISZ, 2008, 2009a) (BANASZEWSKI, 2009). Nesse contexto, além dos maus hábitos exercidos pelos programadores, há outro fator que influencia na qualidade do software gerado, qual seja a linguagem de programação escolhida bem como o próprio paradigma que rege a linguagem (BANASZEWSKI, 2009). A esse respeito, Simão e Stadzisz (2008), Banaszewski (2009) e Simão et al (2012a) afirmam que técnicas de programação baseadas no estado da arte sofrem de limitações intrínsecas de seus paradigmas. Isso é constado inclusive no Paradigma Orientado a Objetos (POO) e nos Sistemas Baseados em Regras (SBR), sendo cada qual respectivamente classificado como um subparadigma ou parte do Paradigma Imperativo (PI) e do Paradigma Declarativo (PD). Particularmente, esses paradigmas levam ao forte acoplamento de expressões causais e a processamento desnecessário por motivos como redundâncias em avaliações causais e/ou utilização de custosas estruturas de dados para tal. Tais limitações frequentemente comprometem o desempenho pleno das aplicações (BANASZEWSKI, 2009). Nesse âmbito, uma alternativa é o chamado Paradigma Orientado a Notificações (PON). A base do PON foi inicialmente proposta por J. M. Simão como uma solução de controle discreto para sistemas de manufatura inteligentes (SIMÃO, 2001; 2005; SIMÃO e STADZISZ, 2002; 2008; 2009a; 2009b; SIMÃO, STADZISZ e KÜNZLE, 2003; SIMÃO, STADZISZ e TACLA, 2009; SIMÃO et al., 2010). Posteriormente, essa solução evoluiu para uma solução de controle discreto geral e, então, para uma nova solução de inferência, alcançando por fim a forma de um paradigma de desenvolvimento de software (SIMÃO e STADZISZ, 2008; 2009a; SIMÃO et al., 2012a). Atualmente, o PON se propõe a eliminar algumas das deficiências dos paradigmas. usuais. de. programação. em. relação. a. avaliações. causais. desnecessárias e acopladas, evitando o processo de inferência monolítico baseado em pesquisas ou percorrimentos (SIMÃO e STADZISZ, 2008; 2009a). Para tal, o PON faz uso de um mecanismo baseado no relacionamento de entidades computacionais notificantes criadas a partir do conhecimento definido em Regras (e seus componentes) e entidades da Base de Fatos (BANASZEWSKI et al., 2007; SIMÃO e STADZISZ, 2008; 2009a; BANASZEWSKI, 2009; SIMÃO et al., 2012a)..

(23) 22. Além disso, esforços adicionais têm sido produzidos para o estabelecimento desse. paradigma.. Em. particular,. um. desses. esforços. foi. destinado. ao. desenvolvimento de um método chamado de Desenvolvimento Orientado a Notificações (DON) que foi originalmente proposto por Wiecheteck (2011) e que foi mais tarde generalizado por SIMÃO et al (2012e) para ser aplicado não somente a sistemas concebidos com o PON mas também para qualquer Sistema Baseado em Regras (SBR) ou mais genericamente Paradigma Orientado a Regras (POR). SIMÃO. et. al. (2012c). denomina. essa. generalização. como. método. de. Desenvolvimento Orientado a Regras (DOR). A partir dessa generalização, o método passa a ser chamado de DON-DOR. O DON-DOR é empregado em projetos de software baseados em desenvolvimento de aplicações PON ou qualquer outra aplicação sob POR independente do mecanismo de inferência. O Método DON-DOR é compatível com as práticas atuais de Engenharia de Software, porém, apresenta técnicas específicas de modelagem orientadas ao desenvolvimento de software com o PON e POR, ou seja, com desenvolvimento de software que se oriente por regras. O DON-DOR é um método para projetos de software que compreende as fases de requisitos e projeto de software PON e POR. Mais especificamente, quando aplicado ao (já universalizado) processo Rational Unified Process (RUP), o DONDOR envolve a disciplina de “Requisitos” e adapta a disciplina de “Análise e Projeto” a fim de satisfazer as necessidades de modelagem tanto para o PON quanto para o POR.. 1.1.3 Questionamento do Trabalho. Tendo em vista o apresentado até o momento, destaca-se o fato das subseções anteriores terem abordado pesquisas recentes que contribuem para a proposta deste trabalho. Dito isso, a presente dissertação busca correspondência e, de certa forma, faz reuso de parte da abordagem de Pimentel para compor uma proposta de método que aplique a Teoria de Projeto Axiomático ao processo de desenvolvimento de software e que possua seu conhecimento causal regido por regras..

(24) 23. Nesse. âmbito,. esta. dissertação. busca. resposta. para. o. seguinte. questionamento: “É possível e vantajoso aplicar a Teoria de Projeto Axiomático para criação de software que possua seu conhecimento causal gerido por regras?”. Importante ressaltar que este trabalho não almeja apresentar uma maneira definitiva de aplicação da Teoria de Projeto Axiomático para o projeto de software PON-POR. Entretanto, apresenta uma série de visões do Projeto Axiomático à luz dos sistemas PON-POR que contribuem para a geração de uma proposta de aplicação da TPA ao projeto de software PON-POR.. 1.2 OBJETIVOS. Esta dissertação de mestrado apresenta uma proposta de aplicação da Teoria de Projeto Axiomático ao processo de desenvolvimento de software PONPOR por meio da criação de um método denominado PA-PON-POR (do acrônimo Projeto Axiomático aplicado ao Paradigma Orientado Notificações e Paradigma Orientado a Regras). Desse modo, o método pode ser utilizado de forma simultânea (ou concomitante) com o método já estabelecido DON-DOR para desenvolvimento de software PON-POR. O método proposto PA-PON-POR visa auxiliar na geração e validação de artefatos necessários às etapas do método DON-DOR. Além disso, o método PAPON-POR visa estabelecer uma forma padronizada de elicitação desses artefatos de maneira a favorecer a criação de projetos de software PON-POR mais controláveis, confiáveis e com artefatos rastreáveis. Acresce-se a isso o fato de critérios de decisão de projeto também poderem ser estabelecidos com base na aplicação do método PA-PON-POR. Os artefatos gerados pelo método auxiliam em decisões de projeto em diferentes etapas de criação do software. Essa característica do método auxilia na escolha de melhores soluções de projeto enquanto que soluções consideradas inadequadas são descartadas em fases iniciais. Dessa forma, ao utilizar o método PA-PON-POR simultaneamente com o método DON-DOR, é possível projetar software PON-POR a partir de etapas bem definidas do método DON-DOR acrescentando critérios para validação de artefatos.

(25) 24. e tomada de decisão na escolha na escolha da melhor solução de projeto proporcionada pela utilização do método PA-PON-POR.. Os objetivos específicos deste trabalho são:. 1) Estabelecer uma proposta de método de aplicação da Teoria de Projeto Axiomático ao processo de desenvolvimento PON-POR. 2) Propor a criação de etapas e atividades bem definidas para o método proposto. 3) Propor um processo de decomposição funcional de requisitos específico para softwares PON-POR. 4) Criar caso de estudo (i.e. exemplo pragmático) que demonstre a decomposição funcional e em cada nível até chegar ao nível de artefatos de projeto PON-POR. 5) Propor reflexões acerca da aplicação do Axioma da Independência a projeto de software PON-POR. 6) Propor reflexões acerca da aplicação do Axioma da Informação a projeto de software PON-POR. 7) Propor um conjunto de equações e métricas que auxiliem no cálculo do conteúdo de informação. 8) Aplicar o método proposto ao caso de estudo supracitado. 9) Propor meios para utilização do método de forma a auxiliar na criação e validação de artefatos das etapas do método DON-DOR.. 1.3 MOTIVAÇÃO. A partir da apresentação do método DON-DOR por Wiecheteck (2011) e SIMÃO et al (2012e), percebeu-se que em algumas etapas do método não existia atividades bem definidas para elicitação dos artefatos, bem como meios para validação da qualidade dos artefatos elicitados. Entretanto, projetistas experientes na utilização do método DON-DOR para criação de software PON-POR teriam maior garantia de sucesso devido a sua experiência conseguida ao longo do tempo..

(26) 25. Ainda, por outro lado, caso o método DON-DOR seja utilizado por um projetista menos experiente, este certamente poderá encontrar dificuldades devido ao conhecimento implícito sobre o PON-POR exigido para a criação de alguns artefatos de etapas específicas. Tendo isto em vista, este trabalho se justifica pela necessidade de se encontrar uma proposta de um método que auxilie na criação e validação de artefatos PON-POR referentes a etapas específicas do método DON-DOR. Deste modo, artefatos inerentes aos paradigmas PON-POR poderiam ser mais facilmente identificados e com uma melhor garantia de qualidade. Outrossim, importante ressaltar que o método proposto neste trabalho não garante de maneira absoluta o sucesso ou fracasso de um projeto de software PON-POR. Ainda assim, projetistas menos experientes poderão ser beneficiados pela proposta de meios pragmáticos de decomposição dos requisitos funcionais em vários níveis de refinamento até que seja possível relacionar requisitos a artefatos de projeto com alguma indicação da qualidade destes.. 1.4 ORGANIZAÇÃO DO TRABALHO. Neste capítulo foi apresentado o contexto em que este trabalho está inserido. Também foram abordados conceitos importantes para o desenvolvimento da pesquisa como a Teoria de Projeto Axiomático, Paradigma Orientado a Notificações e Paradigma Orientado a Regras. Subsequentemente, foram apresentados os objetivos e as motivações que instigaram o desenvolvimento desta dissertação. Dito isso, este trabalho está organizado em outros 4 capítulos, além desta introdução. O Capítulo 2 apresenta toda a fundamentação teórica necessária para o entendimento do trabalho. Nesse âmbito, apresenta uma discussão mais aprofundada sobre a Engenharia de Software, Engenharia de Requisitos, Paradigmas de Programação e Projeto Axiomático. O Capítulo 3, por sua vez, apresenta o objeto de pesquisa desta dissertação que é constituído de um método para desenvolvimento de aplicações criadas com o Paradigma Orientado a Notificações (PON) ou Paradigma Orientado a Regras (POR)..

(27) 26. O Capítulo 4 apresenta um Caso de Estudo em que o método proposto PAPON-POR é aplicado no desenvolvimento de uma aplicação orientada a regras. Por fim, o Capítulo 5 apresenta as conclusões desta dissertação. Também são apresentadas as contribuições e trabalhos futuros pertinentes..

(28) 27. 2 FUNDAMENTAÇÃO TEÓRICA. Neste Capítulo é apresentada a fundamentação teórica deste trabalho. Inicialmente é abordada a Engenharia de Software (ES) e faz-se uma breve discussão dos métodos e processos atuais de ES relacionados com este trabalho. Em seguida, apresenta-se uma visão geral da Engenharia de Requisitos (ER). Subsequentemente, é apresentada uma visão geral dos paradigmas de programação e de forma mais detalhada é apresentado o Paradigma Orientado a Notificações salientando o Método de Desenvolvimento Orientado a Notificações e Desenvolvimento Orientado a Regras (DON-DOR). Por fim, neste capítulo, é apresentada uma visão geral sobre a Teoria de Projeto Axiomático considerando sua história e essência bem como trabalhos relacionados que abordam a aplicação da TPA para projetos voltados à Engenharia de Software5.. 2.1 ENGENHARIA DE SOFTWARE. Esta seção apresenta a Engenharia de Software (ES). A discussão se inicia pelas. definições. iniciais. e. os. principais. conceitos.. Subsequentemente,. é. apresentada uma breve discussão sobre o que é projeto de software e quais as principais questões relacionadas a esse assunto. Mais adiante é discutido o termo processos de software, apresentando sua definição bem como uma sucinta definição dos processos de software mais conhecidos. O processo de software denominado Processo Unificado (PU) também será abordado com maior ênfase, uma vez que o PU possui uma importante participação na pesquisa de Pimentel (2007) e Wiecheteck (2011) que são trabalhos que servem como referência para esta dissertação.. 5. Caso o leitor já possua conhecimento sobre os assuntos abordados neste capítulo, o mesmo poderá ser ignorado, ou ainda, tópicos específicos podem ser lidos de maneira isolada de acordo com a necessidade do leitor..

(29) 28. 2.1.1 Definições Iniciais da Engenharia de Software. A Engenharia de Software (ES) é uma disciplina da Engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção desse sistema após sua operação pelos usuários (SOMMERVILLE, 2004). O IEEE, particularmente, define a ES como sendo a aplicação de uma maneira sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software. Isto é, a ES seria a aplicação dos princípios da engenharia para o desenvolvimento de software (IEEE, 1990). Uma abordagem da engenharia convencional aplicada à Engenharia de Software caracteriza-se por um desenvolvimento de software prático, ordenado e medido. O principal objetivo dessa abordagem é produzir sistemas satisfatórios que respeitem prazos e orçamentos. A utilização dessa abordagem favorece o planejamento, desenvolvimento, avaliação e manutenção de software. Tais benefícios proporcionam meios para que o caos no desenvolvimento de software possa ser evitado (PRESSMAN, 2006). Durante cada fase do processo de ES, métricas de software são aplicadas aos produtos produzidos. O objetivo desse aspecto da Engenharia de Software é estimar a qualidade, os custos e a confiabilidade do que já foi produzido. Com essa medição, é possível obter uma melhor compreensão dos resultados do software. Essas medições do software servem como indicadores que auxiliam em decisões que determinam se o software deve avançar ou retroceder no processo (PETERS e PEDRYCZ, 2001). Assim, ES é supostamente baseada em métodos e práticas comprovados de desenvolvimento de software. Além disso, sua organização pode ser baseada em modelos personalizados de acordo com a necessidade de cada cliente. Esses modelos são criados a partir de um arcabouço de práticas, sequência, métodos e atividades da equipe de ES (PETERS e PEDRYCZ, 2001). Segundo Pressman (2006), a ES pode ser dividida em camadas. Essa divisão pode ser observada na Figura 1..

(30) 29. Figura 1 - Engenharia de Software em Camadas Fonte: Pressman (2006). Toda e qualquer engenharia, inclusive a Engenharia de Software, deve ter sua base focada na qualidade e em atividades análogas que visam ao aprimoramento do processo e controle de qualidade. O processo é a segunda camada que forma o alicerce da Engenharia de Software (PRESSMAN, 2006). A camada de processo apresentada na Figura 1 apresenta-se como uma base para o controle gerencial de projetos de software e estabelece o contexto no qual os objetivos são estabelecidos, os métodos técnicos são aplicados, os produtos de trabalho (i.e. modelos, documentos, dados, relatórios, formulários etc.) são produzidos, a qualidade é assegurada e, as modificações são adequadamente geridas (PRESSMAN, 2006). A camada de métodos, ao seu turno, fornece a técnica de como construir o software. Essa camada envolve questões como de comunicação, análise de requisitos, modelagem de projeto, construção de software e testes. São exemplos de métodos a Casa da Qualidade (HOQ), a Teoria Inventiva de Resolução de Problemas (TRIZ), etc. (PRESSMAN, 2006). A camada de ferramentas fornece à Engenharia de Software apoio automatizado ou semi-automatizado que suportam a realização dos processos e métodos. Esse tipo de ferramenta denomina-se como Computer-Aided Software Engineering (do acrônimo CASE). Alguns exemplos de ferramentas CASE são: Microsoft Team Foundation Server (TFS), Microsoft Project, CVS, JUnit, Enterprise Architect, entre outros (SOMMERVILLE, 2004).. 2.1.2 Projeto de Software. Quando se considera o projetar algo, essa ação está ligada à realização de algum ato que conduz a um produto final. Projetar está relacionado à elaboração de um plano ou modelo que tem por objetivo conduzir e orientar a realização de um projeto. Frequentemente, o plano e ou modelo advém de um arcabouço que a.

(31) 30. organização possui. Esse arcabouço é criado a partir do primeiro projeto e alimentado com informações e experiências de projetos posteriores (PRESSMAN, 2006). Ainda, todo projeto surge de uma necessidade que necessita ser atendida. Essa necessidade então é satisfeita pelo produto final do projeto. Sob esse viés, o processo de projetar obtém, transforma e canaliza as intenções do cliente e percepções em um objeto de projeto, ou seja, um produto. Portanto, projetar software de maneira objetiva significa determinar como os requisitos do cliente serão implementados na forma de estruturas de software (PRESSMAN, 2006). Durante a elaboração do projeto de software, o conjunto de requisitos é mapeado em estruturas que farão parte do software. Esse processo de mapeamento recebe o nome de arquitetura do software. A arquitetura do software fará parte de uma representação ou modelo do software chamado de modelo de projeto que, além da arquitetura, fornece também detalhes sobre as estruturas de dados, interfaces e componentes do software necessários para implementar o sistema, entre outros (PRESSMAN, 2006). O foco principal do projeto de software é a qualidade. É nessa fase que a qualidade é incorporada à Engenharia de Software (ES). O único modo em que se é possível traduzir precisamente os requisitos do cliente em um produto ou sistema de software é na fase de projeto e, além disso, o projeto de software serve de base para todos os passos de ES e de suporte ao software acabado (PRESSMAN, 2006). De acordo com Pressman (2006), existem diretrizes para a qualidade de um projeto de software, entre elas estão: 1) Um projeto deve ser modular; 2) Um projeto deve conter representações distintas para dados, arquitetura, interfaces e componentes; 3) Um projeto deve levar à estrutura de dados adequadas, sobretudo baseada em padrões de dados reconhecíveis. 4) Um projeto deve levar a componentes que possuam características de independência funcional; 5) Um projeto deve levar a interfaces que reduzam a complexidade das conexões entre os componentes e o ambiente externo..

(32) 31. Analisando as diretrizes 1, 4 e 5, percebe-se que são diretamente relacionadas a dois conceitos bastante conhecidos e fundamentais em Engenharia de Software, tais sejam, Acoplamento e Coesão. O Acoplamento é usado para medir o grau de interdependência entre dois módulos. A Coesão, por sua vez, é definida como a medida da intensidade da associação funcional dos elementos de um módulo (PAGE-JONES, 1988). Em projeto de software, o ideal é sempre reduzir o acoplamento e aumentar a coesão, objetivando melhorar a qualidade do software de maneira geral, bem como aumentar sua manutenibilidade (PAGE-JONES, 1988). Estas diretrizes podem ser usadas para avaliar a qualidade de um projeto de software. Entretanto, para alcançar objetivos propostos pelas diretrizes, é muito importante que o projetista seja disciplinado na aplicação de um processo de desenvolvimento que leve em conta essas diretrizes (PAGE-JONES, 1988). Nesse âmbito a próxima seção aborda a expressão “processos de software” e como os processos auxiliam na obtenção de software de melhor qualidade.. 2.1.3 Processo de Software. Segundo Sommerville (2004) um processo de software é um conjunto de atividades e resultados associados que geram um produto de software. Essas atividades são, em sua maioria, executadas por engenheiros de software. Pressman (2006), no entanto, acrescenta que o processo de software pode ser entendido como uma coleção de padronizações que servem para definir um conjunto de atividades, ações, tarefas de trabalho, produtos e comportamentos necessários ao desenvolvimento do software. Além disso, esses padronizações fornecem métodos bem definidos para descrever características importantes do projeto de software. A combinação de padronizações pode levar uma equipe de software a construir seu próprio processo de criação de software (PRESSMAN, 2006). Nesse âmbito, os processos de software se caracterizam como complexos por necessitarem muito do intelecto e da criatividade por parte de seus idealizadores. Esse processo intelectual e criativo, posteriormente, passa pela.

(33) 32. avaliação de outros profissionais e mesmo de outras pessoas (clientes) envolvidos (PRESSMAN, 2006). Algumas atividades do processo de software já podem ser automatizadas com o auxílio de ferramentas CASE. No entanto, efetivamente, algumas atividades ainda necessitam de intervenção humana. Em um futuro próximo não seria vislumbrada ainda a existência de ferramentas CASE capazes de delegar ao software a parte criativa do processo, fazendo com que o engenheiro do processo de software seja conduzido pelo software (SOMMERVILLE, 2004). Boa parte dessa “deficiência” de ferramentas CASE deve-se ao fato de não existir um processo ideal para a construção de software. Para cada ramo e utilidade um processo de software pode suprir melhor as necessidades do cliente. Outro fator importante é que cada organização pode desenvolver sua própria maneira ou processo de criar software a qual pode não ser consenso entre outras organizações (PRESSMAN, 2006; SOMMERVILLE, 2004). Contudo, apesar da imensa gama de processos de software existentes, todos compartilham de algumas atividades fundamentais, quais sejam (PRESSMAN, 2006; SOMMERVILLE, 2004): • Especificação do software: Requisitos do software referentes à sua funcionalidade e restrições de operação devem ser bem definidos. • Desenvolvimento do software: O software deve ser produzido de modo que atenda as suas especificações, o que normalmente envolveria análise/projeto e implementação. • Validação do software: O software tem de ser validado para garantir que ele faz o que o cliente deseja. • Evolução do software: O software deve evoluir para entender as necessidades mutáveis do cliente. Diferentes processos de software podem organizar as tarefas anteriormente descritas de formas diversas e com diferentes níveis de detalhamento. Além disso, o ciclo de vida de cada tarefa e os prazos são variáveis (PRESSMAN, 2006; SOMMERVILLE, 2004): O objetivo principal dos processos é garantir o desenvolvimento de um produto que solucione os problemas do cliente e tenha qualidade. Ademais, deve ser altamente gerenciável e rastreável quanto aos custos, bem como visar sempre a.