Uma das maneiras mais apropriadas para lidar com a complexidade é utilizando abstração. Ela é, na realidade, um processo através do qual podemos identificar os aspectos importantes de algum fenômeno e ignorar os detalhes. Abstração pode, ainda, ser vista como um caso especial de separação de interesses, onde separamos o interesse dos aspectos relevantes do interesse daqueles detalhes não importantes. Em tal situação, como a abstração pode ser usada? O que podemos considerar como detalhe e, portanto, pode ser ignorado?

Isto depende do propósito da abstração. Se considerarmos um relógio digital, temos que este possui dois modos de funcionamento: um no qual ele opera normalmente exibindo hora e data; no outro modo, o usuário pode ajustar horário e data. Neste caso, o relógio irá reagir diferentemente à seqüência de comandos, dependendo do modo no qual ele se encontra. De fato, pode haver diferentes abstrações da mesma realidade, cada delas fornecendo uma visão da realidade e atendendo a algum propósito específico.

Geralmente, projetistas e engenheiros de software bem como profissionais de outras áreas, também, fazem uso da abstração para poder lidar com a complexidade de sistemas a serem desenvolvidos. Por exemplo, considere a descrição de um circuito eletrônico em termos de seus componentes constituintes: transistores, resistores, capacitores, etc. Tais componentes são caracterizados por algum modelo em termos de gráficos e/ou equações. Assim, a representação de um circuito eletrônico é uma abstração de algum dispositivo.

É importante observar que as equações constituem um modelo simplificado que busca retratar o comportamento dos componentes. Além disso, perceba que detalhes como a existência de resistência e/ou capacitância entre componentes são desconsideradas. Neste caso, considera-se que as conexões entre esses componentes são ideais e, portanto, as propriedades de resistência e capacitância (no caso de um circuito eletrônico) são desconsideradas.

Se concentrarmos nossa atenção, especificamente, no exemplo de um circuito eletrônico, temos, então, que dois fatos podem ser ignorados por um projetista: a aproximação de um modelo em termos de equações e a inexistência de qualquer resistência ou capacitância entre os componentes. Ambos os fatos são separados pelo projetista face à interesse distintos. Este exemplo ilustra bem a noção de que os modelos de fenômenos que os projetistas desenvolvem, como equações descrevendo o comportamento de dispositivos, constituem abstrações da realidade. Com ela, o projetista concentra-se no que julga relevante e ignora os detalhes.

No desenvolvimento de um sistema de software, esse processo é similar e o engenheiro de software constrói modelos os quais são analisados. Tais modelos podem ser expressos de várias maneiras. Geralmente, emprega-se diagramas que podem ter algum formalismo associado como, por exemplo, expressões matemáticas. Note que um modelo deixa de lado muitos detalhes, abstraindo-os, uma vez que projetistas decidiram que tais detalhes podiam ser ignorados sem qualquer prejuízo por omissão de informações.

Se considerarmos a evolução dos sistemas de software, dentro do contexto histórico, tem-se que aproximadamente quatro décadas atrás, software constituía uma pequena porção dos sistemas computacionais e, portanto, seus custos de desenvolvimento e manutenção eram insignificantes quando comparado ao hardware. Entretanto, hoje em dia software constitui uma grande parcela dos sistemas atuais e seus custos cresceram significativamente. Como resultado desta mudança, muitos métodos têm sido propostos objetivando melhorar o processo de desenvolvimento bem como minimizar os custos de manutenção. Este cenário agrava-se quando sistemas complexos e de grande porte são considerados.

Para lidar com a complexidade e o tamanho de sistemas, engenheiros de software têm feito uso de princípios de projeto como, por exemplo, ocultação de informações e abstração. Contudo, à medida que os sistemas tornam-se cada vez maiores, o uso de uma disciplina deve ser enfatizado de modo a obter resultados de baixo custo e maior qualidade. Dentro deste contexto, arquitetura de software tem entrado em cena de modo a lidar com sistemas grandes e complexos. Perceba que à medida que tamanho e complexidade dos sistemas de software aumentam, o problema do projeto extrapola as estruturas de dados e algoritmos da computação. Em outras palavras, projetar a estrutura geral do sistema emerge como um problema novo. Questões estruturais envolvem organização e estrutura geral de controle; protocolos de comunicação, sincronização; atribuição de funcionalidade a componentes de projeto; escalabilidade e desempenho; seleção de alternativas de projeto. Estas questões compreendem o projeto de software a nível arquitetural.

Adicionalmente, torna-se cada vez mais evidente que processos de engenharia de software requerem projeto arquitetural de software. Primeiro, é importante ser capaz de reconhecer estruturas comuns de modo que projetistas de software possam compreender as relações existentes entre sistemas e desenvolver sistemas novos baseado em variações de sistemas antigos. Segundo, o entendimento de arquiteturas de software permite engenheiros tomarem decisão sobre alternativas de projeto. Terceiro, uma descrição arquitetural do sistema é essencial para analisar e descrever propriedades de um sistema complexo. Quarto, o conhecimento de notações para descrever arquiteturas possibilita engenheiros apresentarem novos projetos de sistemas a outros membros de uma equipe de desenvolvimento. Assim, arquitetura de software e mecanismos de abstração têm sido e serão temas relevantes no desenvolvimento de novas tecnologias baseada no uso de software no decorrer desta década.