NOVABASE

NOVABASE

CABEÇALHO

MENU PRINCIPAL

CAMINHO PERCORRIDO

Home > Liga > Notícias > “A arquitectura de software facilita a sua re-utilização”

CONTEÚDOS

  • 2012-01-24 | Computer World Online

    “A arquitectura de software facilita a sua re-utilização” 


    Muitas empresas ainda não se convenceram dos benefícios de um software com boa arquitectura, sugere David Garlan, investigador da Carnegie Mellon – que está a colaborar com a NOVABASE e a Critical Software. 

    Mesmo no sector das TIC, há gestores pouco convencidos da do retorno proporcionado pelo investimento na arquitectura de software durante o seu desenvolvimento. É um aspecto a mudar, segundo o investigador da Carnegie Mellon Univerity, David Garlan, até porque ela torna mais fácil a reutilização do software – o que é “mesmo crítico” hoje em dia.

    O docente foi distinguido em 2011 com o Outstanding Research Award 2011 (SIGSOFT), e é director dos programas de mestrado em engenharia de software na escola de ciência computacional da universidade.

    Em entrevista ao Computeworld , o investigador revela o desafios de dois projectos nos quais colabora com empresas portuguesas – a Novabase e a Critical Software

    em parceria com a Faculdade de Ciências e Tecnologia da Universidade de Coimbra. Com a primeira está a desenvolver o trabalho “Affidavit – Automatizando a validação de atributos de qualidade para arquitecturas de software de grande escala”.
     
    Com a Critical Software está a orientar o desenvolvimento de uma investigação centrada em formas de, a partir da arquitectura de software, garantir o funcionamento de sistemas adaptativos – “Assegurando a Fiabilidade de Sistemas Adaptativos com base na Arquitectura”, é o nome do trabalho.
     
    Computerworld – Quais são os três principais desafios existentes no desenvolvimento nas arquitecturas de software?

  • David Garlan – Há dois lados para a resposta a essa pergunta: o dos desafios de investigação nessa área, e os desafios mais técnicos. Os dois são motivados pela necessidade de gerir a complexidade, em sistemas muito complicados. A engenharia de software tem progredindo criando novas formas de abstrair sistemas e de pensar sobre eles à medida que se tornam cada vez maiores. A arquitectura de software apareceu nos anos 90 como uma nova fronteira no domínio da complexidade desses sistemas. Mas nos últimos 20 anos houve um desenvolvimento académico considerável relativo à arquitectura e uma série de práticas na indústria mudaram. Contudo, só há cinco anos a indústria começou a reconhecer verdadeiramente a importância da arquitectura.

    CW – Isso está ligado a conceitos como a Service Oriented

    Arquitecture (SOA)?

    DG – Em parte, isso surgiu bastante porque o software moderno é desenvolvido sobre várias camadas de software e matrizes. E quando se desenvolve um sistema novo, a probabilidade de se reutilizarem grandes quantidades de outro software é muito grande.
    Têm um impacto forte no sistema, pois determinam que componentes poderão ser desenvolvidos e a formas como podem ser alargadas.. A SOA é no fundo uma manifestação disso mesmo.

    CW – Como se tornou a arquitectura de software tão importante?

    DG – Para pensar nas estruturas dos sistemas, não se

    podia fazê-lo à escala dos pequenos programas. É necessário considerar grandes componentes como as bases de dados, sistemas cliente-servidor, protocolos de interacção, entre outros
    Já nos anos 60, a importância da arquitectura era reconhecida, quando o termo engenharia de software foi introduzido. Mas até recentemente a arquitectura de software tinha sido muito informal.
    Quem a fazia mostrava um Power Point, com caixas e setas e dizia que era a arquitectura . Isso mudou um bocado na última década. Foi o reconhecimento de que esses artefactos de desenho podem ser formalizados e representados de uma maneira que vai além das imagens.
    Obtém-se agora um aproveitamento analítico, com formas de por exemplo comparar o desenho da solução com aquilo que foi implantado. Portanto evoluiu-se para um maior rigor.

  • CW – Podemos dizer que evoluiu para um cenário mais normalizado?

    DG – Sim e não. Houve uma normalização do vocabulário. Mas reconheceu-se a existência de vários tipos de arquitectura, os quais exigem ferramentas muito especializadas, e até linguagens.
    Construir pontes é diferente de construir arranha-céus. Há sempre uma especialização e percebe-se que quando há especialização há frequentemente um melhor aproveitamento. 

    CW – Portanto um dos maiores desafios é a complexidade e necessidade de especialização para lidar com essa complexidade? 

    DG – Correcto. Mas tirar partido das características nesse domínio também é um desafio. Se estou a desenvolver uma certa classe de software, muito provavelmente é semelhante a outras já desenvolvidas.
    Assim posso partilhar partes da arquitectura e mesmo o código em muitos casos. Portanto, a arquitectura passa
    a ser um elemento facilitador da re-utilização de software a um grau muito superior.

    CW – Isso é muito útil hoje em dia…

    DG – É mesmo crítico. Mas no lado industrial há uma série de desafios. Um deles é mudar as práticas. Há a percepção de que desenvolver bem a arquitectura tem custos muito elevados. Que leva a práticas de desenvolvimento muito rígidas, e por isso não vale a pena investir nisso.

     

    CW – Mas às vezes isso não faz sentido?

    DG – Acho que em qualquer decisão de engenharia, é necessário compreender o investimento a ser realizado, e torná-lo adequado. Há um livro, “Just enough Software Arquitecture”, de George Fairbanks, no qual este explica como a arquitectura de software deve ser usada o quanto baste, para justificar a sua utilização. Portanto, as pessoas começam a perceber os aspectos nos quais a arquitectura pode ajudar melhor.

    CW – Quais são?

    DG – Para a maior parte dos sistemas isso é rotina, por já terem sido feitos muitas vezes. Mas outros têm mais
  • desafios como no desenvolvimento de um novo sistema bancário, desta vez para ser usado em dois países em vez de um só. Ou com dez vezes mais utilizadores, por exemplo. As partes de rotina são normalmente aquelas que percebemos muito bem. Mas há aquelas imprevistas e aí terá de haver um enfoque maior.

    CW – E para essas partes recomenda uma arquitectura forte?

    DG – Sim, principalmente nessas partes.

    CW – Mas mantendo alguma flexibilidade?

    DG – Compreendendo a flexibilidade que é preciso manter. Gosto de dizer que a arquitectura de software colocou a
    engenharia dentro da engenharia de software. Hoje compreendemos que o mais crítico para o sucesso de qualquer sistema, está relacionado apenas em parte com a informação a processar. Outras características dominam, como o desempenho, a disponibilidade, a fiabilidade, a segurança. A arquitectura tem a ver com os atributos de qualidade, e com a necessidade de os conceber já integrados no sistema. Mas o arquitecto tem de perceber que tem de haver um jogo de equilíbrios entre estes aspectos. Portanto a engenharia passa por perceber como se concilia tudo. E a arquitectura é onde se pensa nisso.
    No lado mais prático, em descobrir formas de introduzir boas práticas na indústria é muito importante.

    CW – Há ferramentas suficientes e adequadas?

    DG – Hoje já há ferramentas suficientes, para os arquitectos usarem , preparadas para suportarem a mudança de práticas informais para mais formais. O que nos leva para um dos projectos incorporados na iniciativa da Carnegie Mellon. No campo académico há desafios no provisionamento de boas capacidades que possam ser usadas para analisar um sistema e perceber se tem mecanismos de segurança integrados. É preciso ter algumas métricas, algumas técnicas para detectar vulnerabilidades, baseadas na descrição da arquitecturas.
    Já conseguimos imaginar essas capacidades mas exigem investigações complexas. Quando se tem uma arquitectura mais rigorosa e formalizada , teremos de passar isso para o lado prático.

    CW – O que faz mais falta?

RODAPÉ