Implantação do software

Capítulo 4. Estudo de caso 48

Figura 13 – Protótipo - Modal NovoLead.

Fonte: Autoria própria (2021).

Figura 14 – Protótipo - QualificarLead.

Fonte: Autoria própria (2021).

Capítulo 4. Estudo de caso 49

4.5.2.1 Model

Conforme análise de requisitos e protótipo criado, a implantação do sistema precisou passar por ajustes. O primeiro ajuste realizado, foi a normalização do banco de dados, que compreende em modelar o banco de dados projetando o armazenamento de informações para eliminar ou minimizar a redundância das informações. Esse processo é realizado identificando anomalias no relacionamento e dividindo-as em relacionamentos mais bem estruturados. Com isso, o Diagrama de Classes apresentado na Figura5passou por alterações e acabou evoluindo, conforme visto na Figura15.

Figura 15 – Implantação - Estrutura de da camadamodel.

Fonte: Autoria própria (2021).

Cada arquivo representa uma tabela no banco de dados e possui suas próprias configurações. Em comum à todos os arquivos, criou-se uma função chamadafields, que tem como principal objetivo nos auxiliar nas próximas etapas da implantação. Um exemplo desta função pode ser visto na Figura16.

Figura 16 – Funçãofields.

1 public static function fields() {

2 return [

3 [

4 'name' => 'nome',

5 'type' => 'text',

6 'label' => 'Nome',

7 'placeholder' => 'Digite o nome da cidade',

8 'required' => true,

9 'max' => 255,

10 ],

11 [

12 'name' => 'estado_id',

13 'type' => 'select',

14 'label' => 'Estado',

15 'placeholder' => 'Selecione o estado',

16 'required' => true,

17 'options' => \App\Models\Estado::all(),

18 'options_key' => 'id',

19 'options_value' => 'nome',

20 ],

21 ];

22 }

Capítulo 4. Estudo de caso 50

Fonte: Autoria própria (2021).

A função servirá como suporte para as camadascontroller eview. Com ela, será possível definir regras de validação e padronização de campos, tendo como princípio a reutilização de códigos e fácil manutenção.

4.5.2.2 Controller

Ocontroller é a camada responsável por fazer a ligação domodel e daview, fazendo com que os modelspossam ser repassados para asviewse vice-versa. Na prática, cadamodelapresentado anteriormente possuirá um controller, conforme Figura17.

Figura 17 – Implantação - Estrutura da camadacontroller.

Fonte: Autoria própria (2021).

Para dar continuidade ao projeto, deve-se lembrar que cadamodel possui uma funçãofields que nos traz a definição de regras de validação de cada coluna em nosso banco de dados. Com base nisso, o arquivoController.php foi adaptado para inclusão de um código que será utilizado para validação dos dados antes da inclusão ou edição de dados no banco, conforme visto na Figura 18.

Figura 18 – Funções em comum docontroller.

1 function getValidationFields($fields) {

2 $natives_with_param = array('max', 'min', 'size', 'starts_with',

3 'regex', 'mimes', 'date_format');

4 $natives_no_param = array('required', 'image', 'date');

5

6 $validation = array();

7 foreach($fields as $field) {

8 $validation[$field['name']] = '';

9 foreach($field as $key => $value) {

10

11 foreach($natives_no_param as $n => $v)

12 if ($key == $v)

13 $validation[$field['name']] .= $key . '|';

14

15 foreach($natives_with_param as $n => $v)

Capítulo 4. Estudo de caso 51

16 if ($key == $v)

17 $validation[$field['name']] .= $key . ':' . $value . '|';

18

19 }

20 if (strlen($validation[$field['name']]) > 0)

21 $validation[$field['name']] = substr($validation[$field['name']], 0, -1);

22 }

23 return $validation;

24 }

25

26 protected function validator($req, $totalFields) {

27 $validator = null;

28 if (!is_array($req))

29 $validator = Validator::make($req->all(), $totalFields );

30 else

31 $validator = Validator::make($req, $totalFields );

32

33 if ($validator->fails())

34 return redirect()->back()->withErrors($validator)->withInput();

35 }

Fonte: Autoria própria (2021).

A primeira função, chamada degetValidationFields tem como principal objetivo percorrer uma matriz e identificar quais campos deverão ser utilizados para validação. Para que isso fosse possível, o primeiro passo foi mapear as validações que seriam utilizados, dividindo-as em validações que precisam de parâmetros adicionais e validações que não precisam de parâmetros adicionais. Após isso, a função terá como prioridade percorrer a matriz de elementos em busca destes campos e formar umastring de validação, conforme definido peloframework utilizado.

A segunda função, chamada devalidator tem como principal objetivo realizar a validação dos campos, tendo como primeiro parâmetro a requisição a ser validada, e o segundo parâmetro, as regras a serem aplicadas. Conforme visto no próprio código, o único retorno que a função terá é em caso de falha na validação, que fará com que o usuário retorne a tela anterior apresentando erros. Caso não seja encontrada nenhuma falha, o sistema irá dar continuidade à execução do código.

Sendo assim, todos os arquivos referente aoscontrollersdeverão ter como base o arquivo acima mencionado. Um exemplo prático da validação em funcionamento pode ser vista, por exemplo, na função storedo arquivo CidadeController.php, conforme visto na Figura19.

Figura 19 – Função storedocontroller.

1 public function store(Request $request, $cidade = null)

2 {

3 $valFields = $this->getValidationFields(Cidade::fields());

4 $validator = $this->validator($request, $valFields);

5

6 if ($cidade == null)

7 $new = new Cidade();

8 else

9 $new = $cidade;

10

Capítulo 4. Estudo de caso 52

11 $new->fill($request->input());

12 if ($new->save())

13 return redirect()->back()->with('success', Lang::get('messages.create_done'));

14 else

15 return redirect()->back()->withErrors([Lang::get('messages.create_error')])->withInput();

16 17 }

Fonte: Autoria própria (2021).

Na linha 3 do Código19podemos ver a funçãogetValidationFieldsem ação, tendo como parâmetro principal os campos definidos anteriormente nomodelcriado para a tabela de cidades. Após o processamento desta função, na linha 4 do mesmo código podemos ver a validação dos dados sendo executada e apenas posteriormente podemos identificar alteração e/ou inclusão de dados no modelo.

4.5.2.3 View

Aview é a camada responsável por por renderizar a interface que será apresentada, mostrando as informações domodel para o usuário. A estrutura ficou definida conforme Figura20.

Figura 20 – Implantação - Estrutura da camadaview.

Fonte: Autoria própria (2021).

Conforme definido no protótipo criado anteriormente, temos como base o arquivo template/- main.blade.php que será utilizado comotemplate para que todas as páginas sigam o mesmo padrão. A pasta configuracoescontém todas asviewsreferentes a configurações gerais do sistema, tais como listagem e manutenção dos cadastros junto ao banco de dados. Cada sub-pasta possui um arquivo chamado

Capítulo 4. Estudo de caso 53

list.blade.php que tem como principal objetivo listar os dados para o usuário. Para a inclusão, edição e exclusão de usuários, utiliza-se como padrão o arquivoformulario.blade.php, que tem como principal objetivo realizar a manutenção dos cadastros, independente de qual seja omodel utilizado. Este arquivo deve ser chamado através do controller, que irá passar definições de rotas para formulário, além dos campos necessários para inclusão, edição e exclusão dos registros.

54

5 RESULTADOS

Após a implantação dosoftware, aplicou-se testes para verificar a carga de trabalho mental e a aceitação alcançada pelo sistema desenvolvido. Além disso, os testes irão servir como base para o correto entendimento das funções do sistema, com a finalidade de realizar alterações necessárias antes da liberação da versão final do produto.