Pular para o conteúdo principal

Arquitetura de Software



Olá pessoal!
Já falamos sobre arquiteto, qualidade  e agora vamos falar sobre Arquitetura de Software!
Para começar, o que é uma arquitetura de software ?
A arquitetura de software de um sistema computacional refere-se à sua estrutura, consistindo de elementos de software, propriedades externamente visíveis desses elementos e os relacionamentos entre eles. Ela define elementos de software (ou módulos) e envolve informações sobre como eles se relacionam uns com os outros. Uma arquitetura é antes de tudo uma abstração de um sistema que suprime detalhes dos elementos que não afetam como eles são usados, como eles se relacionam, como interagem e como usam outros elementos. Na maioria das vezes, a arquitetura é usada para descrever aspectos estruturais de um sistema.

Agora que já sabemos, de modo geral, o que é uma arquitetura; como definimos uma ? quais os fatores que devemos considerar ao escolher uma arquitetura ?
Normalmente o projeto da arquitetura é discutido à luz dos requisitos do sistema, ou seja , é necessário conhecer minimamente os requisitos do sistema para se poder projetá-la. Contudo, deve-se considerar o projeto arquitetônico como algo mais abrangente, envolvendo aspectos técnicos, sociais e de negócio. Todos esses fatores (e não somente os requisitos) influenciam a arquitetura de software. As escolhas são guiadas também pela formação e experiência dos projetistas. Se eles já tiverem uma experiência negativa com uma dada arquitetura, mesmo que ela pareça a melhor opção para o problema, eles ficarão relutantes ao adotá-la novamente. O mesmo serve para uma dada arquitetura que deu super certo, eles vão tentar usá-la sempre rs. Outro fator importante, é o ambiente técnico corrente. Assim, no projeto da arquitetura de software, projetistas são influenciados por requisitos para o sistema, estrutura e metas da organização de desenvolvimento, ambiente técnico disponível e por sua própria experiência de formação.

Mas antes de definir uma arquitetura, precisamos conhecer os padrões e estilos mais utilizados não é mesmo ? Padrões não são inventados, são descobertos. Então, não precisamos reinventar a roda, só temos que conhecer os que já existem e observar qual melhor se encaixa no problema em questão. Se você for muito sortudo, você pode ter que descobrir outro padrão kkkk.
Vamos conhecer os padrões e estilos mais utilizados para um sistema de informação.
O principal estilo utilizado em um sistema de informação é o estilo em camadas. Assim, a maior parte dos padrões apresentados refere-se a como decompor Sistemas de Informações (SIs) em camadas e como essas camadas trabalham em conjunto.
No que se refere a organização dos SIs em camadas, componentes podem ser agrupados em três camadas lógicas principais:

  1. Camada de apresentação ou IU.
  2. Camada de lógica de negócio.
  3. Camada de Persistência ou de Gerência de dados.

Os padrões apresentados abaixo são organizados de acordo com essas camadas.

  1. Camada de lógica de negócio: eles tratam da organização das funcionalidades. São eles: script de transação, modelo de domínio, módulo tabela e Camada de serviço.
  2. Camada de apresentação: enfocam a separação dos objetos de interfaces gráficas(visão) do controle da interação com o usuário. São eles: Modelo visão Controlador (MVC), e controlador de aplicação. Tem também os padrões mais voltados para a visão (template view).
  3. Camada de gerência de dados: se referem ao mapeamento objeto relacional, já que a tecnologia dominante para um SI são os bancos de dados relacionais. 


Bom, já aprendemos um pouco sobre o que é arquitetura, como definir e quais os principais padrões e estilos utilizados em um sistema de informação. Para exemplificar tudo o que foi falado, vou usar o trabalho que estou desenvolvendo, juntamente com o grupo. É um sistema de informação para uma escola de surfe.
A plataforma que utilizamos foi a web. A nossa escolha de arquitetura foi MUITO influenciada pela tecnologia que escolhemos. Como nós utilizamos o Django, ele usa  uma arquitetura conhecida como MTV, Model-Template-View, que nada mais é que uma variação do modelo MVC (Model, View, Controller), arquitetura na qual separam-se as regras de negócios (Controller), os dados e métodos de acessos aos mesmos (Model) e as regras de apresentação (View). 

O diagrama abaixo apresenta a divisão em camadas, temos um subsistema para controle de estoque, controle da escola e controle financeiro que foram identificados utilizando essa arquitetura.

E para finalizar, que tal falarmos sobre uma coisa super em alta ? Já ouviu falar de SOA ? 
No podcast do Grok podcast sobre arquitetura de software, eles discutiram os capítulos do livro Introdução à arquitetura e Design de Software, escrito pelos fundadores da Caelum, que fala exatamente sobre isso.
Hoje em dia é difícil imaginar sistemas que vivem isoladamente. Então todas essas tecnologias que aparecem, nós já temos que pensar em como nossos sistemas serão consumidos e como eles irão consumir outros sistemas. Sendo assim, a Arquitetura Orientada a Serviços (SOA) trata os requisitos de baixo acoplamento, desenvolvimento baseado em padrões, computação distribuída independente de protocolo, integração de aplicações e sistemas legados.) é um modelo de planejamento de estratégia da área de tecnologia da informação, alinhando diretamente aos objetivos de negócios de uma organização.

Para mais informações, acesse:
Grok podCast -> aqui você encontra o livro escrito por eles que explica com mais detalhes sobre o assunto.






Comentários

Postagens mais visitadas deste blog

TDD e BDD

Olá pessoal, Hoje nós falaremos sobre TDD e BDD! Logo que eu ouvi sobre eles gerou um confusão enorme na minha cabeça. O que é TDD e BDD ? TDD – Test-Driven Development (Desenvolvimento Orientado a Testes) é o Desenvolvimento de Software orientado a Testes. O processo de desenvolvimento do TDD seria: Escrever um teste, sem mesmo ter escrito o código real a ser testado (Imagine o que deseja testar). Executar os testes e acompanhar a falha (Pode ser um código falso que retorne o  erro) Escrevemos a funcionalidade do sistema que iremos testar. Testar novamente, agora para passar (Se não passou algo saiu errado, faça novamente o passo 3) Refatore sua funcionalidade e a escreva por completo (o teste também) (Refactor) Passe para o próxima estória ou caso de uso e inicie novo teste. Confesso que isso é bem estranho, principalmente os passos 1 e 2 rs, até porque se funcionasse sem código seria mais estranho ainda kkk. BDD – Behavior Driven Dev

Padrões GRASP

Olá pessoal! Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre   padrões GRASP . Vamos lá! Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução. Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião. 1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la. Qual o padrão que estamos utilizando ? O information expert! Os benefícios ao usar são: Encapsulamento mantido  Comportamento é bem mais distribu

Medição de Software

Olá, hoje nós vamos falar sobre medição de software e da experiência em fazê-la no sistema para a escola de surfe que estou desenvolvendo na faculdade juntamente com outros colegas. Os conceitos aqui apresentados, se baseam na apostila de medição de software . Para começar, o que é medição de software ? Segundo Dumke, medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Sendo assim, é possível perceber a importância da análise estatística do desenvolvimento do seu software, pois com ela consegue-se obter informações relevantes, tais como: tamanho do projeto, custos de desenvolvimento, quantidade de defeitos e etc. No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance dos objetivos, à identificação de problemas e à tomada de decisões informadas. No contexto organizacional, a medição pode auxiliar