trabalho de analise

Prévia do material em texto

UNIP INTERATIVA
Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
PROJETO DESENVOLVIMENTO DE SISTEMA PARA VENDA DE LIVROS ON LINE
MAIO
2020
UNIP INTERATIVA
Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
PROJETO DESENVOLVIMENTO DE SISTEMA PARA VENDA DE LIVROS ON LINE – UNIP
Nathalia Cafaro Salustiano RA:1936197
MAIO
2020
RESUMO
Este trabalho tem por objetivo especificar os requisitos necessários para o desenvolvimento de sistema de vendas on line de livros, conforme solicitação e cenários apresentados pelo cliente, utilizando as técnicas de identificação e elaboração de casos de uso, levantamento de requisitos e suas regras de negócio. O intuito é que esta documentação seja clara e sucinta provendo condições para o desenvolvimento do sistema proposto.
Palavras-chaves: Casos de Uso, Diagrama de Classes, UML, Banco de Dados, usabilidade, usuário, usabilidade.
ABSTRACT
This work aims to specify the requirements for the development of an online book sales system, according to the request and scenarios presented by the client, using the identification and elaboration techniques of use cases, requirements survey and their business rules. The intention is that this documentation be clear and succinct providing conditions for the development of the proposed system.
Keywords: Use Cases, Class Diag
1 Introdução
O desenvolvimento do sistema a ser especificado neste documento, surgiu de proposta apresentada pelo cliente cuja necessidade é realizar vendas de livro pela internet. Foi apresentado o cenário com regras básicas de negócio e utilização que deverá subsidiar toda a especificação e desdobramento dos requisitos. Abaixo, segue cenário proposto:
“Uma livraria resolveu contratar uma empresa para construir um sistema para realizar a venda de livros pela internet. Em linhas gerais, o usuário deverá acessar o site, escolher o (s) livro (s) que deseja comprar e efetuar a compra. Alguns aspectos devem ser levados em consideração:
· O acesso ao site deverá ser feito por meio de login e senha.
· O usuário deverá fazer um cadastro, caso seja o seu primeiro acesso.
· Os dados para cadastro do usuário no site são: nome, endereço, telefone, data de nascimento, login e senha.
· Caso o usuário já possua cadastro, apenas deve digitar seu login e senha. Após a validação do login e da senha, o usuário poderá escolher os livros de seu interesse, consultado os dados no sistema de controle de estoque (já existente).
· Ele irá retornar à informação da disponibilidade ou da indisponibilidade do (s) livro (s) para compra. Após a escolha do (s) livro (s), o usuário deverá efetuar a compra com pagamento somente por cartão de crédito que deve ser validado pelo sistema externo da operadora de cartão de crédito.
· Caso o (s) livro (s) escolhido (s) pelo usuário esteja (m) indisponível (is) para compra no momento, o usuário poderá realizar a reserva.
Para atender esse cenário, o proprietário resolveu contratar uma empresa para desenvolver um sistema para a livraria. ”
As regras básicas apresentadas no cenário, serão utilizadas como insumo para os passos iniciais de Identificação de atores, identificação de casos de uso, elaboração de diagrama e especificação de diagrama, para que na sequência seja especificado os relacionamentos com suas respectivas regras de negócio e requisitos para o desenvolvimento de Banco de Dados.
 (
6
)
2 Elaboração de Casos de uso
2.1 Análise do Caso de Uso
Com base no cenário proposto, foi identificado inicialmente os papéis a serem executados no sistema proposto, considerando relacionamentos com sistema sendo elas humanas ou de sistemas/hardwares com interações no processo para identificação de atores e funções executadas no sistema que representam objetivos do sistema determinar os casos de uso a serem desenvolvidos nesta especificação.
Atores Identificados
· Cliente;
· Sistema de Controle de Estoque;
· Operadora de Carão de Crédito.
Casos de Uso identificados:
· Realizar Cadastro;
· Realizar Autenticação;
· Escolher Livros.
Na representação da Imagem1 - Diagrama de Caso de Uso - Comprar livros, representação do Diagrama de Caso de Uso, cujo objetivo é demonstrar a relação dos atores com os casos de uso identificados.
2.1.1 Relacionamentos especiais:
Identificado tipo de relacionamento “Extend” para entre os casos de uso e “Pagar Cartão de Crédito ” (Caso B) que é uma extensão do caso de uso “Efetuar Compra” (Caso A). Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor (aqui o caso de uso B) para o caso de uso estendido (aqui o caso de uso A).
Não identificados casos de uso de “Generalização” no cenário proposto.
2.1.2 Cadastros Básicos
Aplicado o estereotipo <<CRUD >> no Diagrama de Caso de Uso, para os casos de uso “Realizar Cadastro” e “Escolher Livros”, por se tratar de cadastros básicos cuja relevância para o processo é alta. No primeiro caso, “Realizar Cadastro”, trata-se de dados de cadastro de cliente imprescindíveis para seu acesso ao site e realização de compras no site, sendo premissa do processo. Esta base deve permitir o armazenamento de dados fixos como nome do cliente e CPF e dados que permitam alteração como endereço para entrega, e-mail, número do cartão de crédito.
No segundo caso, “Escolher Livros”, sua relevância se dá pela alteração status de disponibilidades de livros, sendo imprescindível para efetivar compra. Livros entrantes no cadastro do Sistema de Controle de Estoque - SCE, devem possuir status disponível e os esgotados indisponível, sendo transparentes ao usuário no momento da escolhe e, devem ainda possuir status provisório de reserva na base.
Por se tratar de manipulações envolvendo as 4 operações básicas de banco de dados: Create, Read, UpDate e Delete, foram aplicados o estereótipo <<CRUD>> na representação do Diagrama de Casos de Uso para estes dois casos.
3 Contexto de uso
A Análise de Contexto de Uso (CoU em inglês) é um método baseado em questionários, útil para a captura de informações sobre o contexto em que um produto, serviço ou sistema está ou estará inserido.
Os três principais produtos da Análise de Contexto de Uso devem surgir a partir das respostas para as seguintes questões:
· Quem irá usar a aplicação (Usuários)?
· O que eles realizarão com a aplicação (Tarefas)?
· Onde eles usarão a aplicação (Ambiente)?
Aplicando esta técnica de análise no desenvolvimento proposto, classificamos no processo:
· Quem? Clientes - usuários com perfil de leitura interessados em aquisição de novos livros através de compra on line, provida de comodidade e segurança para suas experiências de navegação e compra
· O que? A aquisição será de livros - objeto de desejo do cliente neste contexto, porém é importante destacar neste método de análise por meio de - no sentido de tarefas que lhe irão assegurar pesquisa e efetivação de compra. Desta forma é possível trilhar toda as execuções ou passos que permeiam esta etapa da análise.
· Onde? Determinação do tipo de interface a ser utilizada pelo cliente, ou seja, como ele irá acessar, considerando que o ambiente do sistema já está definido como sendo uma interface web ou página de acesso. A seguir, deve- se garantir o acesso de forma adequada à todos os tipos de dispositivos utilizados pelo cliente para interface com o sistema: dispositivos móveis como tablets e celulares, notebooks e desktops por exemplo.
4 Regras de negócio
Regra de negócio é o que define a forma de fazer o negócio, refletindo a política interna, o processo definido e/ou as regras básicas de conduta. Ou seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições, validações, condições e exceções do processo são exemplos clássicosde regras de negócio. Uma regra de negócio não necessariamente será refletida no sistema como uma funcionalidade, mas ela com certeza determinarão o comportamento de uma ou mais funcionalidades do sistema.
5 Diagramas de Classe de Domínio
6.1 Elaboração do Diagrama de Classe
Na etapa de elaboração do diagrama de Classe, foram aplicadas as técnicas aprendidas de análise do cenário proposto, a fim de identificar todos os insumos necessários para a construção do diagrama:
· Identificação de Classes
· Lista de Classes Candidatas para eleger as classes finais
· Identificação de relacionamentos
· Construção do Diagrama de Classes
Na sequência foram identificados os atributos com base nas características vinculadas às classes eleitas e por fim, identificação dos métodos baseados nas ações a serem realizadas pela classe e seus atributos
6 Estereótipos e Relacionamentos
Na representação do Diagrama de Classes de Domínio, conforme Imagem 14 – Diagrama de Classes, é importante ressaltar, além do relacionamento simples de associação entre as classes, o relacionamento de agregação existente entre as Classes “Carrinho” e a “ <<Intreface>> SCC”. Em ambas as classes, foi demonstrada a criação de uma classe com agregação de composição. Pode-se dizer que composição é uma variação da agregação. Uma composição tenta representar também uma relação todo - parte. No entanto, na composição o objeto- pai (todo) é responsável por criar e destruir suas partes. Em uma composição um mesmo objeto-parte não pode se associar a mais de um objeto-pai.
Estabelecida também os estereótipos <<CRUD>> – que se trata de acrônimo da expressão do idioma Inglês, Create (Criação), Read (Consulta), Update (Atualização) e Delete (Destruição). Este acrônimo é comumente utilizado para definir as quatro operações básicas usadas em Banco de Dados Relacionais e, finalmente os estereótipos de <<Interface>>, identificando classes de sistemas externos que se comunicam com o sistema proposto para desenvolvimento.
7 Modelo Entidade Relacionamento – MER
O modelo relacional modela os dados num conjunto de relações (tabelas ou ficheiros) que são constituídas por um conjunto de atributos (colunas ou campos) que definem as propriedades ou características relevantes da entidade (conceito, objetivo) que representam. Cada linha ou registo da relação caracteriza um elemento único.
A modelo entidade relacionamento (E-R) baseia-se na percepção de um universo constituído por um grupo de objetos Entidades e por relacionamentos entre esses objetos. A entidade relacionamento é a relação efetuada pela ligação de atributos em comum. É um modelo abstrato ou conceitual a fim de representar as estruturas de dados de forma mais natural e mais próxima do mundo real dos negócios, compondo os atributos que se relacionam entre si. Na imagem 15 – Representação MER, em que identificam-se para o sistema proposto as entidades e o relacionamento entre si, ressaltando a existência de relacionamentos fracos para o entidade “cidade_UF”, que possui relação de dependência da entidade “usuário” .
8.1 Diagrama Entidade Relacionamento - ER
Um diagrama entidade-relacionamento (ER) é um tipo de fluxograma que ilustra como “entidades”, p. ex., pessoas, objetos ou conceitos, se relacionam entre si dentro de um sistema. Diagramas ER são mais utilizados para projetar ou depurar bancos de dados relacionais nas áreas de engenharia de software, sistemas de informações empresariais, educação e pesquisa. Também conhecidos como DERs, ou modelos ER, usam um conjunto definido de símbolos, tais como retângulos, diamantes, ovais e linhas de conexão para representar a interconectividade de entidades, relacionamentos e seus atributos. Eles espelham estruturas gramaticais, onde entidades são substantivos e relacionamentos são verbos
por outro lado, entidades fortes como “SCC (Sistema de Controle de Crédito)” e “SCE (Sistema de Controle de Estoque)” que possuem relação de independência, pois conforme regra, tratam-se de sistemas externos que farão interface com o sistema a ser desenvolvido.
9. CONCLUSÃO
As metodologias aplicadas no desenvolvimento da especificação abordam em suas etapas as técnicas adquiridas para garantir o desenvolvimento de análises que subsidiarão a implementação, porém devemos considerar que na execução foram contempladas mais de uma técnica para formalização dos requisitos e regras do sistema. Partiu-se de um cenário inicial apontado pela necessidade do cliente que, pode ser interpretado como uma primeira entrevista, para posteriores elaborações de casos de uso, regras de negócio e representações em Diagramas de Classe de Domínio e Entidade e relacionamento. As elaborações não foram focadas em desenvolvimento voltado para projeto, em que se aplica o gerenciamento por cronograma e entregas pré-estabelecidas de acordo com os frameworks ou modelos de desenvolvimento de softwares de mercado que, são de suma importância para garantir o foco em cada etapa de execução do projeto e qualidade no produto final. Toda via devemos considerar que objetivo voltado para os métodos de documentação tanto descritivas quanto técnicas foram atingidos, porém e que, para
a aplicação prática e real em projeto deve-se avaliar a melhor técnica de execução considerando fatores como custo, equipe de projeto, prazo, entre outros.
10. Referências Bibliográficas
Date, C.J. Introdução a Sistemas de Bancos de Dados (Tradução da 8ª Edição Americana). Editor: Editora Campus. São Paulo, 2003.
Debastiani, Carlos Alberto. Definindo Escopo em Projetos de Software. São Paulo: Nova tec. IS BN 978-85-7522-429-8, 2015.
UNIP INTERATIVA, Manual PIM VI. Disponível em https://ava.ead.unip.br. Acesso em 03/06/2018.
Vazquez,	Carlos;	Simões,	Guilherme.	Engenharia	de	Requisitos:	Software Orientado ao Negócio. [S.l.]: Brasport, 2016.
3.1 Requisitos Não Funcionais
Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. A aplicação dos requisitos não funcionais, surgem conforme a necessidade dos usuários, em razão de orçamento e outros fatores e podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de armazenamento disponíveis. Estes requisitos devem nortear o desenvolvimento no sentido de garantir desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas.