H´a ainda recursos para modelagem da implanta¸c˜ao f´ısica do sistema, ou seja, para a especifica¸c˜ao das unidades f´ısicas (hardware) nas quais os componentes de software ser˜ao executados. Tais modelos s˜ao especialmente importantes em sistemas distribu´ıdos e arquiteturas cliente-servidor.
A UML, por´em, ´e apenas uma linguagem de modelagem. Assim, a UML fornece um conjunto de ferramentas, mas n˜ao informa como e com que finalidade tais ferramentas devem ser aplicadas. ´E necess´ario escolher quais e quando utilizar os diversos diagramas dispon´ıveis e qual o n´ıvel de detalhe a ser adotado nos modelos, manter a conex˜ao e a sincroniza¸c˜ao dos modelos com o c´odigo produzido e modelar o sistema a partir de v´arias perspectivas para compreendˆe-lo em sua totalidade. A ado¸c˜ao de um processo de desenvolvimento de software permite escolher os diagramas e o momento de aplic´a-los, bem como as perspectivas nas quais os mesmos devem ser produzidos.
5.3
Considera¸c˜oes sobre as T´ecnicas de Engenharia de Software
A aplica¸c˜ao sistem´atica das t´ecnicas discutidas acima, juntamente com ferramentas adequadas de gerenciamento e sincroniza¸c˜ao de documentos, diagramas e c´odigo, tem certamente contribu´ıdo para trazer mais controle, produtividade e qualidade ao desenvolvimento de software. Por outro lado, mesmo organiza¸c˜oes experientes no desenvolvimento de sistemas extensos tˆem encontrado s´erias dificuldades em suas atividades, freq¨uentemente estourando prazos e or¸camentos, e tamb´em cancelando projetos5.
A conclus˜ao ´obvia ´e que tais procedimentos n˜ao s˜ao garantias infal´ıveis de sucesso, sendo ne- cess´ario considerar que a implanta¸c˜ao e o aprendizado das t´ecnicas podem ser fontes de algum risco, custo e consumo de tempo. Sua correta aplica¸c˜ao, por´em, torna a imprevisibilidade razoavelmente administr´avel, possibilitando lidar de forma mais racional com as dificuldades inerentes `a defini¸c˜ao e organiza¸c˜ao dessa classe de sistemas. Outra contribui¸c˜ao importante para a melhoria dessa atividade seria entender a origem de tais dificuldades.
Se comparada ao projeto e constru¸c˜ao de sistemas f´ısicos, observa-se que a engenharia de software ´e fortemente baseada em experiˆencia, em tentativa e erro (Kruchten, 2001a; Buhrer, 2000), enquanto a evolu¸c˜ao das engenharias de sistemas f´ısicos ´e caracterizada pela aplica¸c˜ao cada vez mais sistem´atica de princ´ıpios f´ısicos (Timoshenko, 1953). Com recursos de an´alise de sensibilidade e otimiza¸c˜ao, por
5Apenas para citar dois exemplos, Windows 2000 e Mac OS X foram lan¸cados com mais de um ano de atraso e com
exemplo, busca-se reduzir a necessidade de experiˆencia pr´evia em v´arias situa¸c˜oes de projeto de sistemas f´ısicos.
Princ´ıpios f´ısicos agem como restri¸c˜oes e objetivos a serem atingidos durante o projeto. Em ´ultima an´alise permitem a defini¸c˜ao de regras de projeto que s˜ao v´alidas em quaisquer casos, respeitando as premissas dessas regras. Em contrapartida, n˜ao h´a princ´ıpios f´ısicos envolvidos na especifica¸c˜ao, organiza¸c˜ao e constru¸c˜ao de software. Os procedimentos discutidos nas se¸c˜oes anteriores s˜ao as me- lhores t´ecnicas extra´ıdas da experiˆencia pr´atica atrav´es da observa¸c˜ao do fracasso e sucesso de grande n´umero de projetos. Por esse motivo, em qualquer processo de engenharia de software ´e crucial alocar desenvolvedores experientes para atividades cr´ıticas como, por exemplo, a defini¸c˜ao de arquiteturas. Julgar a priori se uma arquitetura de software est´a modular ou resiliente o suficiente para suportar os requisitos envolve bem mais que habilidade t´ecnica: requer experiˆencia, talento e sensibilidade. Uma resposta a isso seria o desenvolvimento iterativo, no qual propostas de arquitetura s˜ao produzidas e testadas6. Julgar se o modelo de um sistema f´ısico cumpre seus requisistos requer principalmente habilidade t´ecnica na aplica¸c˜ao dos princ´ıpios f´ısicos e solu¸c˜ao das equa¸c˜oes resultantes, e adicionalmente graus vari´aveis de experiˆencia e talento conforme o caso.
Outra fonte de dificuldades s˜ao as expectativas por vezes errˆoneas surgidas da aplica¸c˜ao impre- cisa dos termos “projeto” e “constru¸c˜ao” no contexto da engenharia de software (Buhrer, 2000). No caso de sistemas f´ısicos, a conclus˜ao do projeto caracteriza-se por um desenho final de produto que descreve em detalhes materiais, subconjuntos, uso de componentes de terceiros, partes a serem pro- duzidas, tolerˆancias, seq¨uˆencias de montagem, etc. A partir dessas informa¸c˜oes ´e poss´ıvel determinar com razo´avel precis˜ao custos e tempos de constru¸c˜ao (produ¸c˜ao). Logo, a etapa de projeto fornece informa¸c˜ao suficiente para se obter o sistema final dentro de prazos e custos conhecidos.
No caso de software, finalizado o “projeto”, tem-se apenas um conjunto estruturado de conceitos, ou seja, entidades, interfaces e rela¸c˜oes que comp˜oem o sistema. Seguindo tais informa¸c˜oes n˜ao ´e poss´ıvel obter o produto final, ou seja, um sistema execut´avel, pois o c´odigo fonte ainda n˜ao foi totalmente escrito. Isso se d´a somente ap´os a fase de “constru¸c˜ao”.
No sentido estrito de se obter um produto final seguindo instru¸c˜oes de um plano detalhado, ´e o compilador que de fato realiza a constru¸c˜ao do sistema de software, a custo e tempo desprez´ıveis nesse caso. No sentido de fornecer um plano detalhado para a constru¸c˜ao do sistema, apenas ao final da
5.3. Considera¸c˜oes sobre as T´ecnicas de Engenharia de Software 169
fase de “constru¸c˜ao” o verdadeiro projeto do sistema de software est´a conclu´ıdo. Em resumo, o que se convencionou chamar de projeto de software corresponde a um esbo¸co de projeto de um sistema f´ısico. Em qualquer disciplina, o projeto de um novo produto envolve imprevisibilidade, pois nessa etapa ´e necess´ario considerar muito mais que seq¨uˆencias de execu¸c˜ao e montagem, e a intera¸c˜ao entre elementos e subconjuntos adjacentes. ´E necess´ario especificar, selecionar e combinar componentes, analisar intera¸c˜oes entre eles (o n´umero de intera¸c˜oes que cresce n˜ao-linearmente com o n´umero de componentes), verificar incompatibilidades e performance.
Desconsiderar as diferen¸cas entre sistemas f´ısicos e software pode levar a conclus˜oes erradas so- bre t´ecnicas de engenharia de software. Inicialmente, por exemplo, acreditava-se que a programa¸c˜ao orientada por objetos, devido `as caracter´ısticas de abstra¸c˜ao e encapsulamento, traria para o desen- volvimento de software a mesma produtividade e evolu¸c˜ao r´apida que tem caracterizado a ind´ustria de componentes eletrˆonicos (Cox, 1986), o que n˜ao se confirmou ap´os a difus˜ao dessa t´ecnica de pro- grama¸c˜ao. Al´em disso, o desenvolvimento de sistemas de software envolve v´arias outras etapas al´em da implementa¸c˜ao, cada qual com impacto na produtividade e na qualidade.
A sistematiza¸c˜ao da reutiliza¸c˜ao de solu¸c˜oes de projeto e arquitetura de sistemas de software ´e uma estrat´egia adicional `as j´a apresentadas para aliviar as incertezas pr´oprias da fase de projeto e a falta de leis gerais de desenvolvimento. Solu¸c˜oes comprovadas de projeto s˜ao encontradas na forma de gabaritos gen´ericos denominados padr˜oes (patterns). V´arios padr˜oes de projeto, an´alise e arquitetura s˜ao encontrados na forma de cat´alogos apresentando motiva¸c˜ao, aplicabilidade e diagramas da estrutura de cada solu¸c˜ao, juntamente com exemplos de c´odigos fonte que os implementam (Gamma et al., 1995; Larman, 1998; Larman, 2001). Construir arquiteturas baseadas em padr˜oes conhecidos e comprovados ´e uma forma razo´avel de reduzir a dependˆencia em termos de experiˆencia e ao mesmo tempo adquiri-la e difundi-la entre os desenvolvedores. Padr˜oes tamb´em surgem das solu¸c˜oes encontradas pelos desenvol- vedores para problemas recorrentes, fazendo parte da defini¸c˜ao de uma arquitetura o reconhecimento de padr˜oes dentro da base de software da organiza¸c˜ao.
`
A primeira vista, a aplica¸c˜ao das t´ecnicas de desenvolvimento de software descritas acima parece desviar parte consider´avel do tempo anteriormente dedicado `a codifica¸c˜ao dos algoritmos para outras atividades. Apesar de ser verdadeira a afirma¸c˜ao de que a utiliza¸c˜ao sistem´atica de um processo de desenvolvimento torna a etapa de codifica¸c˜ao mais objetiva e eficiente ´e ineg´avel a introdu¸c˜ao de novas fases de trabalho. Nesse sentido ´e recomendada a ado¸c˜ao de ferramentas de apoio ao desenvolvimento
de software para modelagem gr´afica, gerenciamento de requisitos, gera¸c˜ao autom´atica de c´odigo e sincroniza¸c˜ao, bem como sistema para controle de vers˜oes de arquivos.