Olá, estudante, seja bem-vindo(a) a nossa décima primeira lição da disciplina de Introdução à Programação. Até a lição anterior, nos aprofundamos em conceitos intrínsecos ao desenvolvimento. Nesta lição, como parte de um grande propósito, daremos início a mais uma etapa da nossa jornada, pois começaremos a introduzir conceitos arquitetura e projeto de software. Calma! Vou explicar para você o que isso significa. Vamos lá!

Quando usamos o termo “arquitetura”, acredito que você logo pensa em uma casa ou construção com um design diferenciado, bonito e elegante. É importante que você entenda que a arquitetura de uma casa não é somente a sua frente (fachada), mas também a forma como os vários elementos de uma casa estão integrados. Os projetos de paisagismo, iluminação, elétrico, arquitetônico e estrutural precisam estar harmonicamente alinhados para que se tenha um produto final com uma arquitetura considerada de excelência. E no desenvolvimento de software não é diferente. Você, como um técnico em desenvolvimento de sistemas, deve desenvolver um software que possua uma arquitetura harmonicamente alinhada com as suas funcionalidades. Nada adianta o software ter uma interface maravilhosa se ele não funciona, ou de nada adianta o software funcionar muito bem se a sua interface é ruim e cansa o usuário durante o uso do sistema.

Você já pensou quais são as principais partes de um software? Ou acredita que um software possui uma única parte – a programação que você realiza? Os softwares possuem, no mínimo, três partes centrais que estão interligadas. A interface do usuário é a parte que o usuário vê, o banco de dados é onde os dados ficam armazenados e/ou são inseridos, atualizados ou deletados, e o código é onde o técnico em desenvolvimento de sistemas programa a lógica do software. A junção dessas três partes vamos chamar de arquitetura do software.

Um software pode ter diferentes arquiteturas e é função do técnico em desenvolvimento de sistemas definir qual arquitetura será mais adequada para qual tipo de software. Ademais, o técnico em desenvolvimento de sistemas deve se preocupar com os projetos de interface com o usuário e de Banco de Dados. O projeto de banco de dados você aprendeu ou aprenderá em outra disciplina, mas a interface com o usuário vou discutir aqui nesta lição.

Imagine que você é o técnico em desenvolvimento de sistemas de uma organização e foi solicitado para você desenvolver um aplicativo para smartphone de forma que os clientes possam fazer os seus pedidos. Você sabe que arquitetura esse aplicativo terá? Você sabe qual será a melhor interface para esse aplicativo? Essas são algumas perguntas que esta lição irá ajudá-lo a responder. Vamos lá!

O técnico em desenvolvimento de sistemas pode atuar tanto no desenvolvimento de um novo software quanto realizar a manutenção em um software já existente. Independentemente da situação, você deve analisar a arquitetura do software e identificar onde está o problema. Vamos a um exemplo prático.

A organização que você trabalha já possui um aplicativo móvel em que os clientes podem realizar as suas compras. Contudo, pelas avaliações na loja virtual do aplicativo, percebe-se que muitos usuários do aplicativo estão reclamando da interface que não é intuitiva e há muitos passos a serem seguidos até a conclusão da tarefa final, que é a de realizar uma compra. Há também outras reclamações associadas ao aplicativo que o deixou com uma nota dois na loja de aplicativos.

O técnico em desenvolvimento de sistemas decide realizar um novo projeto de interface com o usuário, pois, de acordo com as reclamações, essa é a parte do sistema que apresenta o maior problema. Não se observou reclamações com relação às funcionalidades ou armazenamento dos dados. Assim, você como um bom conhecedor das técnicas para projetar interface com o usuário define construir uma interface mais intuitiva onde em poucos toques na tela (no máximo três) o usuário consegue fazer a sua compra, retirar produtos do carrinho de compras ou inserir novos. 

Você também percebe que o aplicativo solicitava ao usuário algumas configurações para que o seu uso fosse iniciado. Isso confundia o usuário porque pedia configurações técnicas. Você decide, então, remover esses dados técnicos e simplificar o acesso ao usuário por meio de um único clique com autenticação via redes sociais ou pelo e-mail do usuário já cadastrado no smartphone. 

Algumas reclamações também foram feitas com relação às cores usadas no aplicativo, que cansam a vista do usuário. Você decide usar uma paleta de cores neutra para eliminar esse problema. Por fim, alguns usuários disseram que os ícones na tela não eram intuitivos, o ícone para finalizar uma compra, por exemplo, era uma seta com a palavra “exit”. Você então decide alterar os ícones para algo que faça parte do mundo real do usuário. O ícone para finalizar uma compra é alterado para a imagem com um carrinho de compra com o texto “Finalizar compra” abaixo.

Neste início de conceitualização, é importante definir a diferença entre projeto e arquitetura: um projeto é considerado uma instância de uma arquitetura, assim como um objeto é uma instância de uma classe. Cada decisão na arquitetura pode gerar um novo projeto e geralmente isso acontece. 

Atividades como “Interface com o usuário”, “Definição de cores e posicionamento dos botões na tela”, “Fluxo de ações entre as funcionalidades” e “Quantidade de cliques para realizar um processo do sistema de forma completa” são atividades que podem fazer parte de um projeto de interface homem-máquina para um determinado sistema que possui uma arquitetura cliente-servidor. Vamos compreender isso melhor.

Uma das arquiteturas de software mais simples e ainda bastante utilizada é a centralizada em dados, ou também chamada de 2 camadas. Neste tipo de arquitetura, o software estará localizado no cliente/usuário que acessa um repositório central de armazenamento (banco de dados).

Um outro tipo de arquitetura de software é a do tipo chamadas e retornos, essa arquitetura aplica a ideia de programas e subprogramas em uma estrutura hierárquica. Pode-se dizer que essa arquitetura é muito aplicada em softwares de grande porte como sistemas ERP (Enterprise Resource Planning). Um software mais amplo controla vários subprogramas, como por exemplo um software de Gestão de Recursos Humanos que possui vários subprogramas como: gestão de pagamentos, gestão de empréstimos ou gestão de treinamentos. Um outro programa, do setor contábil, por exemplo, pode ter como subprogramas a gestão de recebimentos, gestão patrimonial ou gestão de estoque. Os programas e subprogramas podem fazer parte de um software maior.

A ideia central da arquitetura em camadas é dividir o software em partes, de forma que recursos mais internos estejam mais próximos do sistema operacional enquanto recursos mais externos estejam próximos do usuário. Pode-se dizer que a arquitetura em camadas é mais utilizada atualmente para se desenvolver softwares, uma vez que permite uma separação clara do que é camada do usuário, camada de dados e camada de lógica do negócio.

O modelo mais aceito pela indústria de software e aplicado pelos principais ambientes de desenvolvimento é chamado de MVC (Model, View, Controller - Modelo, Visão e Controle). Trata-se de uma arquitetura em camadas que se baseia na orientação a objetos.

O MVC objetiva separar o desenvolvimento de um software em partes, sendo a camada mais externa a camada do usuário ou interface do usuário (VIEW). No meio, está a camada MODEL, relaciona-se ao modelo de banco de dados ou estrutura de armazenamento de dados (essa estrutura, geralmente, está relacionada a um diagrama de classes que é mapeado para um Sistema Gerenciador de Banco de Dados – SGBD – relacional). Por fim, tem-se a camada de CONTROLLER (lógica de negócio). Aqui é onde programamos, ou seja, é onde ficará o código da lógica de negócio. Essa camada interpreta as ações do usuário (cliques e seleções) ativando a programação interna do sistema para que a camada MODEL possa enviar para a camada de VIEW aquilo que o usuário deseja (vê) (STURM; PEREIRA; SILVA, 2015).

A arquitetura MVC é muito utilizada como a arquitetura dos principais softwares da atualidade, porque ela permite uma divisão clara das três partes de um software: a camada do usuário – VIEW (representada por formulários, menus e ícones); a camada do banco de dados – MODEL (representada pelas classes e/ou tabelas no mundo relacional); e a camada de Controller (representada pela programação e a lógica de negócio que é aplicada no software). O usuário usa a camada de VIEW para disparar os eventos na camada CONTROLLER que busca os dados na camada MODEL que devolve à camada de VIEW.

Modelando a arquitetura de software

Podemos considerar que a definição da arquitetura que um software terá é que nos guiará durante o processo de desenvolvimento. Essa é uma função clássica de um técnico em desenvolvimento de sistemas: definir a arquitetura do sistema. Nós estudamos em lições anteriores a Linguagem de Modelagem Unificada (UML). Bom, esse é o momento em que a UML poderá nos ajudar!

Vimos na UML vários diagramas, cada um com uma funcionalidade e aplicabilidade. A construção de uma arquitetura de software deve ser vista como a definição da relação de seus componentes, assim como acontece com um projeto de um prédio. O diagrama da UML que nos fornece tal possibilidade é o Diagrama de Componentes, pela sua capacidade de relacionar partes em um contexto geral. Vamos observar um exemplo na Figura 2.

A Figura 2 permite observar claramente a arquitetura MVC sendo utilizada no Diagrama de Componentes. O componente "Página Eletrônica de Submissão de Trabalhos” representa a camada VIEW. O componente “Controlador de Submissões” representa a camada CONTROLLER. O componente SGBD representa a camada MODEL. Perceba o quanto é simples a observação de um sistema por meio da definição de sua arquitetura. Muito mais fácil, não!?

A seguir, apresento algumas dicas para você criar o seu diagrama de componentes e definir a arquitetura do seu sistema, conforme sugerem Pressman e Maxim (2016, p. 299-305):

Como podemos perceber, a criação de uma arquitetura de um sistema só será possível após a criação de vários diagramas da UML que ao final fornecerão as informações necessárias ao diagrama de componentes.

Projeto de interface do usuário

Para o projeto da interface com o usuário, pode-se definir três regras de ouro: (I) deixar o usuário no comando; (II) Reduzir a carga de memória do usuário; (III) Tornar a interface consistente. Vou comentar a seguir cada uma dessas regras, conforme sugerem Pressman e Maxim (2016):

1) Deixar o usuário no comando

O usuário não deve fazer ações desnecessárias, mantenha a navegação o mais simples possível. Proporcione uma interação flexível: não se pode escolher pelo usuário o tipo de interação que ele deve ter com o sistema. Dê opções! Cada usuário tem um tipo de experiência diferente. Possibilite que a interação com o usuário possa ser interrompida e desfeita. O usuário deve ser capaz de fazer outra atividade sem que haja a perda do que já fez. O usuário também deve ser capaz de desfazer qualquer ação realizada. Sempre que possível dê a possibilidade de o usuário personalizar ações. Oculte os detalhes técnicos do funcionamento interno do usuário: não deixe para o usuário configurar aspectos técnicos do sistema ou apresente mensagens técnicas. O sistema deve representar o mundo real daquele usuário. O fato de o usuário arrastar um arquivo para a lixeira é semelhante se ele estivesse fazendo essa ação fisicamente. Sempre busque essa analogia nas ações.

2) Reduza a carga de memória do usuário

Reduza a demanda de memória recente: atividades mais complexas, geralmente, exigem muito da memória recente. A interface deve reduzir a exigência de ações passadas. Estabeleça defaults significativos: Um documento padrão deve se basear naquilo que o usuário mais utiliza. Deve haver também a possibilidade de personalização e reset para o default. Defina atalhos intuitivos: atalhos são sempre um caminho mais rápido para uma ação e em sistemas comerciais, que o usuário passa oito horas ou mais usando aquele mesmo sistema, são essenciais. Os atalhos devem ser intuitivos. O layout visual da interface deve se basear na metáfora do mundo: Se você está desenvolvendo um sistema para uma loja de açaí, tente representar o sistema pela sua atividade principal. Venda e açaí. O mesmo caso vale para um sistema de pagamento que pode usar a metáfora de um talão de cheques. Revele as informações de maneira progressiva: organize as informações de forma hierárquica. Só apresente detalhes se o usuário desejar. Se o usuário solicita dados de um cliente, forneça as informações principais, como: nome, e-mail, telefone. Opções pouco usadas como endereço, cpf, rg, data de nascimento etc. podem ser omitidas e apresentadas caso o usuário queira. Aqui vale uma boa conversa com o usuário do sistema sobre suas necessidades.

3) Tornar a interface consistente

Permita ao usuário inserir a tarefa atual em um contexto significativo: apresente nas janelas títulos, ícones gráficos e sistema de cores adequado. Para o usuário, deve ficar claro de onde ele veio e como ele pode alternar para uma nova tarefa. Mantenha consistência em uma linha de produtos completa: softwares com vários módulos ou subsistemas devem manter a mesma linha, padrões de interface e manter a consistência entre eles.

Um grande problema ao desenvolver interfaces é que cada tipo de usuário tem uma necessidade, para isso, sugiro algumas dicas para identificar os usuários do seu sistema: (i) verifique o tipo de usuário do seu sistema (ex. usuários que trabalham em ambientes de produção podem ter maior dificuldade com o uso de sistemas de informação ou podem trabalhar com equipamento de proteção individual (ex. luvas) – enquanto usuários que trabalham dentro de escritórios tendem a fazer uso cotidiano de sistemas de informação; (ii) verifique também o nível de escolaridade dos usuários – usuários com menor nível de escolaridade podem ter maior dificuldade no uso de recursos tecnológicos; (iii) verifique se a forma de aprendizado dos usuários é facilitada por meio de material escrito, videoaulas ou aulas presenciais; (iv) verifique como os usuários são recompensados pelo trabalho realizado (ex. formas de pagamento); (v) verifique o expediente em que os usuários trabalham – usuários de softwares que trabalham no ambiente noturno podem “sofrer” com o tipo de tela do monitor e paleta de cores usada no software (PRESSMAN; MAXIM, 2016).

Nesta lição, você aprendeu sobre a arquitetura mais utilizada nos softwares (MVC), como projetar essa arquitetura e quais os caminhos para desenvolver a arquitetura de um software. Você também aprendeu como projetar a interface com o usuário, um dos principais projetos do software atualmente. 

A arquitetura de um software pode significar que o seu uso será duradouro ou terá um tempo de vida curto. No atual cenário tecnológico que vivenciamos, a arquitetura de um software tem sido alterada daqueles softwares que são instalados em cada máquina do usuário para uma arquitetura baseada na nuvem e acessada pelo usuário somente pelo navegador web (ex. Google Chrome, Firefox, Safari, entre outros). Independentemente se você vai desenvolver um software para ser instalado na máquina do usuário ou se ele vai funcionar na nuvem, a arquitetura MVC tem sido a mais utilizada e você pode usar como uma referência para os softwares que for desenvolver. A separação do software em camadas permite que mais de uma pessoa trabalhe no software ou apenas uma pessoa, mas com três atividades distintas. Isso vai depender muito da organização em que você estiver trabalhando e como a área de desenvolvimento de sistemas é organizada.

Além da arquitetura do software, o projeto de interface com o usuário, ou em algumas literaturas também chamado de interface homem-máquina ou design orientado pelo usuário (User eXperience - UX design), deve ser planejado com especial atenção. Os usuários da atualidade não aceitam softwares com interfaces pouco intuitivas e que não seguem adequadamente padrões já consolidados no mercado. Tente sempre seguir as interfaces daqueles softwares que muitas pessoas já conhecem e fazem um uso no seu cotidiano. Não “reinvente a roda”, porque isso pode comprometer o seu projeto. As discussões da nossa lição permitem que você tenha condições de identificar o que está correto ou incorreto numa interface com o usuário e resolver o problema. Lembre-se sempre: a interface do usuário não é feita para você, mas para as pessoas que podem passar seis, oito ou mais horas na frente do computador olhando para aquilo que você construiu. Seja sensato e siga as dicas da nossa lição.