terça-feira, 23 de novembro de 2010

O que é Arquitetura de Software?

A arquitetura de software é descrição abstrata, na forma de modelos, de diferentes visões do sistema em termos de unidade (partes) que interagem entre si.

Arquitetura não é uma fase do desenvolvimento, mas o resultado das decisões de design sobre a estrutura e o comportamento do software. Mesmo que esta atividades não tenha sido deliberadamente realizada, vale ressaltar que:


  • Todo software tem uma arquitetura
  • A arquitetura pode ser analisada por diferentes pontos de vista  (visões arquiteturais)


A arquitetura deve dar suporte à funcionalidade do sistema (requisitos funcionais) e deve estar em conformidade com a qualidade (requisitos não-funcionais).

O design arquitetural é o processo de tomar as decisões que visa definir estrutura e comportamento para atender aos requisitos funcionais e não-funcionais. Um bom arquiteto deve conhecer diferentes modelos e estilos de arquitetura e saber aplica-los de forma a atender aos requisitos.

Um dos princípios básicos para organização da estrutura e comportamento é manter uma alta coesão e um baixo acoplamento entre as unidades, como ilustrado na figura abaixo. Uma unidade com alta coesão mantém unidades dependentes entre si agrupadas em uma unidade maior. Isto implica que unidades dependentes e com alto grau de comunicação e dependência entre si estejam localizadas numa mesma unidade mais abstrata. Os benefícios deste princípio são:

  • Facilitar a manutenção e modificação de uma determinada unidade.
  • Permitir a substituição de unidade por outra.
  • Diminuir a comunicação entre as unidades mais abstratas, o que pode significar um baixo tráfego na rede.


As unidades (ou partes) que formam podem variar dependendo da visão utilizada. Por exemplo, numa visão de execução, as partes podem ser vistas como componentes e conectores. Os componentes podem ser partes que estão em execução como processos ou threads e os conectores os mecanismos de comunicação entre estes processos. Exemplos de conectores são memória compartilhada ou pipes entre processos do Unix/Linux.

Numa visão de implementação ou de código, as unidades podem ser módulos que oferecem serviços a outros módulos. Estes módulos devem estar ligados entre si através de interfaces bem definidas (API) e organizados de acordo com os serviços. É muito comum termos APIs organizadas em camadas, como nas interfaces de usuário gráficas (GUI).

Existem na literatura várias propostas de visões arquiteturais, como em :

  • Hofmeister, Nord e Soni, - Applied Software Architecture, Addison Wesley, 2000;
  • Bass, L.; Clements, P. and Kazman, R. - Software Architecture in Practice - Second Edition, Addison-Wesley 2003.


quinta-feira, 28 de janeiro de 2010

Design de software, de IHC e o Ipad

Já dissemos anteriormente que o desenvolvimento de software deve começar pelo seu design. O design de um software interativo consiste na elaboração do seu modelo conceitual, na representação visual de seus elementos e na forma de interação com as suas funcionalidades.

Para entender isso na prática vejamos os vídeos da apresentação do Ipad.

O Steve Jobs está falando o tempo todo sobre como humanos podem interagir com programas que já conhecemos há tempos: player de mp3, player de vídeos, leitor de emails, browser de páginas Web, visualizador de fotos, leitor de livros eletronicos (e-reader), e outros.

Existem dois aspectos importantes:
1. Jobs está o tempo todo chamando a atenção sobre com podemos interagir com estes programas com os dedos, sentando numa poltrona ou sofá, e ter umaexperiência de uso.
2. Os diferentes produtos foram idealizados para uma plataforma única, compartilhando alguns elementos comuns

Ou seja, houve um design destes programas, com seus elementos visuais e interativos acoplados a um hardware simples (com poucos elementos, embora tecnologicamente sofisticadíssimo), com um modelo de interação baseado em toques na tela.

A apple já disponibilizou a SDK, mas não acho que alguém vai ter sucesso em desenvolver aplicações se começar diretamente programando. É preciso desenhar, prototipar, definir a seqüencia de interações para depois transformar isso em código.

Observe que alguem que não entende de programação, pode ser capaz de idealizar e desenhar uma boa aplicação para um Ip*d, que posteriormente precisará ser codificada por um programador. Mas um bom programador que esteja mergulhado em códigos fontes, não necessariamente conseguirá idealizar tais produtos.