4 MODELAGEM E SOLUÇÃO
4.1.1.1 Abstração
Para Microsoft (2016), a abstração consiste na separação dos objetos de uma totalidade, a segmentação proporciona uma melhor utilização dos recursos da orientação a objetos.
Pelo princípio da abstração, nós isolamos os objetos que queremos representar do ambiente complexo em que se situam, e nesses objetos representamos someta as características que são relevantes para o problema em questão.
Simplificação mental de coisas complexas, a fim de permitir sua avaliação, classificação ou para permitir a comunicação do mesmo. (HOUAISS, 2006)
No próximo tópico explica-se o pilar da orientação a objeto o encapsulamento.
4.1.1.2 Encapsulamento
O encapsulamento esconde a implementação de uma classe.
Trata-se de um dos elementos que adicionam segurança à aplicação em uma programação orientada a objetos pelo fato de esconder as propriedades, criando uma espécie de caixa preta. (DEVMEDIA, 2016a).
Mendes (2009, p.115), através do encapsulamento:
[...] tanto os atributos quanto a implementação dos métodos de uma certa classe não são visíveis ao usuário da classe. Conhecendo-se apenas a interface de uma classe, isto é, os métodos disponíveis e suas respectivas assinaturas, podemos utilizar objetos desta classe sem conhecer detalhes de como ela é implementada internamente.
A implementação do encapsulamento por grande parte das linguagens orientadas a objetos se dá através de atributos privados associados a métodos getters e setters.
4.1.1.3 Herança
A herança “permite o reaproveitamento de métodos e atributos diminuindo o tempo de desenvolvimento, ainda reduz as linhas de código desta forma facilita as manutenções futuras”. (DEVMEDIA, 2016a).
Assim é possível criar uma nova classe a partir de outra já existente.
A utilização da herança é mais que uma simples economia de código, significa mais integridade. Quando um comportamento é alterado, todas as classes que descende dela terá acesso aos métodos atualizados sem necessidade de reprogramação. (MICROSOFT, 2016).
No próximo tópico explica-se o pilar da orientação a objeto o polimorfismo.
4.1.1.4 Polimorfismo
O polimorfismo é um fator chave na programação orientada a objeto, proporciona facilidade de programação ao controlar diferentes objetos com comportamentos específicos em um mesmo método.
“A palavra polimorfismo vem do grego poli morfos e significa muitas formas. Na orientação a objeto, isso representa uma característica que permite que classes diferentes sejam tratadas de uma mesma forma”. (CARVALHO, 2012, p.58)
“O polimorfismo permite escrever programas que processam objetos que compartilham a mesma superclasse (direta ou indiretamente) como se todos fossem objetos da superclasse; isso pode simplificar a programação”. (DEITEL; DEITEL, 2010, p.305).
Com o polimorfismo pode-se desenvolver sistemas mais extensíveis adicionando novas classes sem muitas alterações.
4.1.2 Uml
UML, do inglês Unified Modeling Language, é uma linguagem visual utilizada para modelar sistemas orientados a objetos. Foi aprovada como padrão em 1997 pela OMG, Object Management Group, e desde então tem sido utilizada amplamente pela comunidade de desenvolvedores de sistemas. (BEZERRA, 2006).
Segundo Bezerra (2006, p. 14):
A UML é uma linguagem visual para modelar sistemas orientados a objeto. Isso quer dizer que a UML é uma linguagem constituida de elementos gráficos (visuais) utilizados na modelagem que permitem representar os conceitos do paradigma da orientação a objetos. Através dos elementos gráficos definidos nesta linguagem, pode-se construir diagramas que representam diversas perspectivas de um sistema.
Durante o desenvolvimento de um sistema de software que utiliza a UML como linguagem de suporte à modelagem, são criados diversos tipos de documentos, sendo eles textuais ou gráficos. Esses documentos são denominados artefatos de software, artefatos esses que são produzidos através da utilização dos diagramas da UML. A Figura 14 representa os diagramas UML existentes utilizados para representações gráficas do modelo parcial do sistema.
Figura 14 - Diagramas UML
Fonte: Imagem do site oficial da UML 2.5, 2016. Imagem retirada de http://migre.me/vp2sc
Ainda segundo Bezerra (2006) a UML é independente de qualquer tipo de linguagem de programação, ou seja, a UML pode ser utilizada sem que seja levada em conta a linguagem de programação utilizada no desenvolvimento do sistema ou qualquer que seja o processo de desenvolvimento adotado. Isso faz com que a UML se torne uma importante linguagem de visual adotada para que seja feita uma modelagem gráfica de forma padronizada.
4.1.3 Iconix
ICONIX é uma metodologia ágil de desenvolvimento de software elaborado por Doug Rosenberg e Kendall Scott em 1993.
Silva e Videira (2001, apud BONA, 2002, p.60), apresentam o ICONIX como:
Uma metodologia prática, intermediária entre a complexidade do RUP (Rational Unified Process) e a simplicidade do XP (Extreme Programming). O ICONIX está adaptado ao padrão da UML (OMG®, 2001), é dirigido por casos de uso e o seu processo é iterativo e incremental.
Segundo Beck (2001), metodologia ágil possui algumas características: Indivíduos e interação entre eles mais que processos e ferramentas.
Software em funcionamento mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. Responder a mudanças mais que seguir um plano.
O ICONIX é “um processo simplificado que unifica conjuntos de métodos de orientação a objetos em uma abordagem completa, com o objetivo de dar cobertura ao ciclo de vida”. (BONA, 2002, p.60)
Rosenberg e Scott (1999, apud BONA, 2002) levantam alguns pontos fundamentais sobre o software, respondido pelo ICONIX:
Identificar os atores do sistema: esta resposta pode ser obtida através da utilização dos casos de uso.
Levantar os objetos e suas associações: pode ser obtido pela construção dos diagramas de classe (alto nível).
Identificar os objetos essenciais para cada caso de uso: para isso utiliza-se a análise de robustez.
Verificar a colaboração/ interação dos casos de uso: verifica-se com o diagrama de sequência e de colaboração.
Como será realizado o controle na in time na aplicação: utilizando-se o diagrama de estado.
Borillo (2000, apud BONA, 2002, p.61), apresenta três características principais do ICONIX:
Interativo e incremental: várias iterações ocorrem entre o desenvolvimento do modelo de domínio e a identificação dos casos de uso. O modelo estático é incrementalmente refinado pelo modelo dinâmico.
Rastreabilidade: cada passo referência para os requisitos de alguma forma. Silva e Videira (2001, apud BONA, 2002, p.61) definem rastreabilidade como sendo a capacidade de seguir a relação entre os diferentes artefatos produzidos.
Aerodinâmica da UML: a metodologia oferece o uso “aerodinâmico” da UML como: os diagramas de casos de uso, diagramas de sequência e colaboração, diagramas de robustez.
A figura 15 apresenta o processo realizado pela metodologia ICONIX, de forma simples a área que existe entre os casos de uso e o código. (ROSENBERG; STEPHENS, p.1, tradução nossa).
Figura 15 - Processo ICONIX
O ICONIX possui o modelo estático que modelam o funcionamento sem participação do usuário através dos diagramas de domínio e de classe, já o modelo dinâmico com as interações dos usuários com o sistema através dos diagramas de caso de uso, robustez e sequência (MAIA, 2005).
O ICONIX tem o objetivo de ser claro e sucinto.
4.2 MODELAGEM
A modelagem facilita a identificação e compreensão das características e/ou comportamentos de um software. Assim, apresenta-se as modelagens dos requisitos, protótipos de tela, casos de uso, modelo de domínio, diagrama de robustez, diagrama de sequência e diagrama de classe.
4.2.1 Requisitos
Os requisitos são condições que o sistema deve ter para satisfazer os interesses dos usuários.
“A análise de requisitos resulta na especificação de características operacionais do software, indica a interface do software com outros elementos do sistema e estabelece restrições que o software deve atender”. (PRESSMAN, 2011, p.151)
Nesta seção apresenta-se os requisitos funcionais e não-funcionais da solução proposta.
4.2.1.1 Requisitos funcionais
Os requisitos funcionais informam o que o sistema deve fazer.
Os requisitos funcionais são “as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.”(SOMMERVILLE, 2007, p.80)
Apresentam-se a seguir, os requisitos funcionais da proposta de solução: RF001 – Sistema deve permitir o cadastro de itens por usuário
RF002 – Sistema deve permitir a visualização de todos os itens RF003 – Sistema deve permitir a visualização dos itens por usuário
RF004 – Sistema deve permitir a solicitação de troca de um item por outro
RF005 – Sistema deve permitir visualizar as solicitações de troca propostas pelo usuário RF006 – Sistema deve permitir visualizar as solicitações de troca propostas ao usuário RF007 – Sistema deve permitir autorizar uma troca solicitada
RF008 – Sistema deve permitir negar uma troca solicitada.
RF009 – Sistema deve permitir avaliar troca após a finalização da mesma RF010 – Sistema deve permitir ranquear os usuários que mais trocam RF011 – Sistema deve ser multiplataforma
RF012 – Sistema deve permitir o cadastro do usuário
RF013 – Sistema deve trocar informações entre usuários quando confirmado uma troca. (para se comunicarem de como vai ser realizado a entrega dos itens)
RF014 – Sistema deve permitir busca de item por categoria.
RF015 – Sistema deve permitir usuário visualizar trocas efetuadas com sucesso. RF016 – sistema deve permitir alteração no cadastro do usuário
RF017 – Sistema deve permitir login de usuários cadastrados no sistema RF018 – Sistema deve permitir a edição de um item já cadastrado.
RF019 – Sistema deve permitir que o usuário cancele uma troca proposta.
4.2.1.2 Requisitos não-funcionais
Os requisitos não funcionais são “restrições sobre os serviços ou as funções oferecidos pelo sistema”. (SOMMERVILLE, 2007, p.80)
Apresentam-se abaixo os requisitos não funcionais da proposta de solução:
RNF01 – Deve ser permitido o acesso ao sistema através de dispositivos móveis. (acessibilidade)
RNF02 – Sigilo das informações pessoais. (segurança)
RNF03 – As telas deverão ser de fácil leitura e entendimento por parte do usuário. (usabilidade)
RNF04 – O sistema deverá estar online sempre. (confiabilidade)
RNF05 – O sistema deverá garantir que todos os pedidos de troca devem ser feitos corretamente. (confiabilidade)
4.2.2 Protótipos de tela
Nesta seção são apresentados os protótipos de tela do sistema de troca de itens nerd.
O login é realizado em uma janela pop-up, pois o usuário pode acessar parte do sistema e realizar algumas funções sem estar logado, então, esta opção agiliza o processo de login, conforme figura 16.
Figura 16 - Tela de login
Fonte: Elaboração dos autores, 2016.
A tela principal do sistema lista todos os itens cadastrados no sistema que não possuem troca associada a ele com as informações nome, categoria e usuário proprietário do item, conforme figura 17.
O usuário pode acessar esta página sem realizar login, o menu superior apresenta somente algumas opções devido a isso.
Figura 17 - Tela Principal
Na tela de detalhes do item aparece uma imagem ampliada do item e é acrescentada a informação de descrição do item. Ainda, um botão com a opção “Tenho Interesse” e “Voltar”, conforme figura 18.
A partir do momento em que o usuário registra interesse em um item, faz-se necessário a realização do login.
Figura 18 - Tela de detalhes do item
Fonte: Elaboração dos autores, 2016.
Na tela itens para troca são apresentados os itens do usuário e a opção de oferta- los para troca, conforme figura 19.
Figura 19 - Telas com itens do usuário para troca
Fonte: Elaboração dos autores, 2016.
A solicitação de troca é apresentada conforme figura 20, onde há a imagem dos itens envolvidos na troca e a opção de “Solicitar Troca”. A partir deste ponto é possível acessar o menu com as funcionalidades do sistema.
Fonte: Elaboração dos autores, 2016.
A tela com as solicitações de troca do usuário apresenta os itens envolvidos na solicitação de troca, a data da solicitação e o usuário do item desejado, conforme figura 21.
Figura 21 - Tela com minhas solicitações de troca
Fonte: Elaboração dos autores, 2016.
A tela com as solicitações dos outros usuários apresenta os itens envolvidos na solicitação de troca e as opções de aceitar ou rejeitar a troca, conforme figura 22.
Figura 22 - Tela com as solicitações de troca por outros usuários
Fonte: Elaboração dos autores, 2016.
A tela das trocas já efetuadas apresentam os item envolvidos na troca, os dados do usuário para entrar em contato e a opção de avaliar a troca, conforme figura 23.
Figura 23 - Tela de trocas efetuadas
Fonte: Elaboração dos autores, 2016.
Na tela ranking de troca são apresentados os usuários com maior número de trocas, conforme figura 24.
Figura 24 - Tela Ranking usuários com mais trocas realizadas
Fonte: Elaboração dos autores, 2016.
Na tela ranking de avaliações são apresentados os usuários melhor avaliados, conforme figura 25.
Figura 25 - Tela Ranking usuário melhor avaliado
Fonte: Elaboração dos autores, 2016.
Figura 26 - Tela de cadastro de item
Fonte: Elaboração dos autores, 2016.
A tela de cadastro de usuário apresenta-se conforme figura 27. Figura 27 - Tela de cadastro de usuário
Na próxima seção são apresentados os casos de uso do sistema dando uma primeira visão das funcionalidades realizadas pelos atores do sistema.
4.2.3 Casos de uso
Nesta seção, são apresentados os casos de uso. O sistema possui apenas 1 (um) ator, chamado de Usuário. A figura 28 apresenta os casos de uso do Usuário, que contemplam as funcionalidades do sistema.
Figura 28 - Casos de Uso do ator Usuário
Fonte: Elaboração dos autores, 2016.
A descrição do fluxo principal e alternativo do caso de uso Efetuar Login é descrito no quadro 2, assim como suas condições.
Quadro 2 - Caso de uso Efetuar Login UC001 – Efetuar Login.
Descrição: Autenticação dos Usuários que possuem cadastro do sistema. Pré-Condição: Estar cadastrado no sistema
Pós-Condição: O Usuário é autenticado e com isso libera opções que o possibilitam interagir totalmente com o sistema, como trocar itens, avaliar suas trocas, editar seu perfil, etc.
Requisitos Funcionais: RF017 – sistema deve permitir login de usuários cadastrados no sistema
Fluxo Principal
P1: Usuário clica no botão “Login” no Menu Principal do sistema. P2: Sistema exibe a tela TEL006 - Efetuar Login.
P3: Usuário preenche os campos "Login" e "Senha" com seu login e senha pessoal. P4: Sistema valida os campos preenchidos.
P5: Sistema carrega menu principal para usuários logados e abre a tela TEL004 - Solicitar Troca.
P6: Sistema busca no banco de dados informações sobre novas trocas propostas ao usuário, trocas aceitas e trocas negadas.
P7: Sistema exibe tela TEL007 – Mensagens Gerais com informações buscadas. P9: Usuário interage com sistema de acordo com sua vontade.
P9: Usuário clica em Sair.
P10: Sistema realiza logout do sistema.
P11: Sistema carrega menu principal para usuários deslogados e abre a tela TEL004 - Solicitar Troca.
Fluxo Alternativo A
P9: No P4 do fluxo principal sistema encontra erro na validação.
P10: Sistema exibe tela TEL007 – Mensagens Gerais informando sobre o erro. P11: Sistema retorna para P2 do fluxo principal.
Fonte: Elaboração dos autores, 2016.
No quadro 3, é descrito o fluxo principal e alternativo do caso de uso Cadastrar Usuário, assim como suas condições.
Quadro 3 - Caso de uso Cadastrar Usuário UC002 - Cadastrar Usuário
Descrição: Cadastro de usuários para criação de conta na plataforma de troca. Pré-Condição: ----
Requisitos Funcionais: RF012 – sistema deve permitir o cadastro do usuário. Fluxo Principal
P1: Usuário clica em “Cadastrar-se” no Menu Principal P2: Sistema carrega tela TEL002 – Cadastrar Usuário. P3: Usuário preenche todos os campos.
P4: Sistema valida informações.
P5: Sistema persiste informações no Banco de Dados. P6: Sistema Realiza Login do Usuário.
P7: Sistema carrega tela TEL007 - Mensagens Gerais com mensagem de sucesso. P8: Sistema busca no Banco de Dados lista de produtos disponíveis para troca.
P9: Sistema carrega tela TEL004 - Solicitar Troca com produtos carregados do Banco de Dados.
P10: Usuário seleciona opção desejada no Menu Principal. P11: Sistema realiza opção desejada.
Fluxo Alternativo
P9: No P4 do fluxo principal sistema encontra erro na validação.
P10: Sistema exibe tela TEL007 – Mensagens Gerais informando sobre o erro. P11: Sistema retorna para P2 do fluxo principal.
Fonte: Elaboração dos autores, 2016.
No quadro 4, é descrito o fluxo principal e alternativo do caso de uso Editar Usuário, assim como suas condições.
Quadro 4 - Caso de uso Editar Usuário UC003 - Editar Usuário
Descrição: Edição de usuário, para que o mesmo possa editar suas informações de conta. Pré-Condição: Usuário deve estar cadastrado e logado no sistema.
Pós-Condição: ---
Requisitos Funcionais: RF016 – Sistema deve permitir alteração no cadastro do usuário. Fluxo Principal
P1: Usuário clica em "Minha Conta".
P2: Sistema busca no banco informações do Usuário.
P4: Usuário modifica informações desejadas. P5: Usuário clica em Salvar.
P6: Sistema valida informações.
P7: Sistema persiste, no banco de dados, as informações modificadas. P8: Usuário seleciona opção desejada no Menu Principal.
P9: Sistema realiza opção desejada.
Fluxo Alternativo
P9: No P6 do fluxo principal sistema encontra erro na validação.
P10: Sistema exibe tela TEL007 – Mensagens Gerais informando sobre o erro. P11: Sistema retorna para P3 do fluxo principal.
Fonte: Elaboração dos autores, 2016.
No quadro 5, é descrito o fluxo principal e alternativo do caso de uso Cadastrar Item, assim como suas condições.
Quadro 5 - Caso de uso Cadastrar Item UC004 - Cadastrar Item
Descrição: Cadastro de itens do usuário no sistema.
Pré-Condição: Usuário tem que estar logado e autenticado no sistema. Pós-Condição: Usuário terá um novo item para negociar em suas trocas.
Requisitos Funcionais: RF001 – Sistema deve permitir o cadastro de itens por usuário Fluxo Principal
P1: Usuário seleciona a opção "Itens" no Menu Principal. P2: Usuário seleciona "Cadastrar" no Submenu de "Itens". P3: Sistema carrega tela TEL001 - Cadastrar Item.
P4: Usuário preenche informações do item. P5: Usuário clica no botão "Salvar".
P6: Sistema Valida informações e persiste no banco de dados.
P7: Sistema exibe tela TEL007 – Mensagens Gerais informando sucesso. P8: Usuário seleciona opção desejada no Menu Principal.
P9: Sistema realiza opção desejada.
P9: No P6 do fluxo principal sistema encontra erro na validação.
P10: Sistema exibe tela TEL007 – Mensagens Gerais informando sobre o erro. P11: Sistema retorna para P3 do fluxo principal.
Fonte: Elaboração dos autores, 2016.
No quadro 6, é descrito o fluxo principal e alternativo do caso de uso Solicitar Troca, assim como suas condições.
Quadro 6 - Caso de uso Solicitar Troca UC005 - Solicitar Troca
Descrição: Permite que o usuário pesquise um item e solicite uma troca.
Pré-Condição: Usuário ter itens cadastrados no sistema e disponíveis para troca.
Pós-Condição: Após usuário solicitar uma troca, o mesmo deve esperar a análise e resposta do dono do item que ele tem interesse.
Requisitos Funcionais:
RF002 – Sistema deve permitir a visualização de todos os itens. RF003 – sistema deve permitir a visualização dos itens por usuário
RF004 – Sistema deve permitir a solicitação de troca de um item por outro.
RF005 – Sistema deve permitir visualizar as solicitações de troca propostas pelo usuário. RF014 – Sistema deve permitir busca de item por categoria.
Fluxo Principal
P1: Usuário acessa aplicação.
P2: Sistema busca no banco de dados lista de produtos disponíveis para troca.
P3: Sistema carrega tela TEL004 - Solicitar Troca com lista de produtos buscada no banco P4: Usuário escolhe produto do seu interesse e clica no item.
P5: Sistema carrega tela TEL008 - Detalhes do Produto com informações do produto selecionado e 2 (dois) botões, "Tenho Interesse" e "Voltar".
P6: Usuário seleciona botão desejado. P7: Sistema realiza opção desejada.
P8: Usuário seleciona opção desejada no Menu Principal. P9: Sistema realiza opção desejada.
Fluxo Alternativo A
“Pesquisar”.
P11: Sistema filtra produtos de acordo com pesquisa e apresenta na tela TEL004 - Solicitar Troca
P12: Sistema volta para P4 do fluxo principal.
Fluxo Alternativo B
P13: No P6 do fluxo principal, Usuário clica no botão "Tenho Interesse". P14: Sistema verifica se usuário esta logado.
P15: Sistema busca no banco lista de itens disponíveis do próprio usuário para troca.
P16: Sistema carrega tela TEL009 - Lista Produtos Usuário com lista dos produtos carregada do banco.
P17: Usuário seleciona botão “Oferecer em Troca” no Item que desejado.
P18: Sistema carrega tela TEL010 - Item desejado / oferecido com item desejado e oferecido, juntamente com 2 (dois) botões, “Solicitar Troca” e “Voltar”.
P19: Usuário seleciona botão desejado.