You are on page 1of 33

UNIP INTERATIVA

Projeto Integrado Multidisciplinar VI

Cursos Superiores de Tecnologia

Modelagem de Sistemas Orientado a Objetos.

Unip Interativa Piracicaba

2016
UNIP INTERATIVA

Projeto Integrado Multidisciplinar VI

Cursos Superiores de Tecnologia

Modelagem de Sistemas Orientado a Objetos.

Joo Paulo Castro Tinelli Fernando Fonseca

1505231 - 1500492

Anlise e Desenvolvimento de Sistemas

1 Semestre

Unip Interativa Piracicaba

2016
RESUMO

Este documento demonstra um projeto que possui aspectos de Anlise de Sistemas


Orientado a Objetos, com o objetivo de iniciar o desenvolvimento de um sistema
para a empresa Modelo Autopeas, que contratou os servios da empresa Pacific
Solutions, para sanar suas deficincias em seus processos: controle de estoque e
clculos incorretos na comisso de vendedores.

A demonstrao ocorre atravs do levantamento e especificaes de casos de uso,


diagramas de casos de uso, requisitos, diagramas de classes, regras de negcio e
prottipos de interface (layout de telas).

Casos de uso so representaes das funcionalidades externamente observveis, o


sistema se baseia em vendas e controle de estoque de seus produtos, ento foram
identificados como casos de uso: cadastro de produto e cadastro de vendedor (cada
um desses possui a opo de alterao, excluso e consulta), cadastro para lanar
um pedido, podendo selecionar um ou mais produtos e atribuir um vendedor, clculo
de comisso de vendedores encima do pedido (sendo esse feito automaticamente
no momento da finalizao do pedido) .

Tambm foi desenvolvido um caso de uso de cadastro de usurio, onde h trs


tipos: usurio restrito, usurio padro e administrador do sistema. Usurios restritos
tem acesso apenas a funcionalidades de consulta, bem como o usurio padro e
administrador do sistema. Usurio padro responsvel por lanar um pedido e o
administrador do sistema por cadastrar produtos, vendedores e novos usurios.

O diagrama de casos de uso demonstra as atividades do sistema para os tipos de


usurios em um fluxo, e nas especificaes so detalhados os processos internos
(validaes, impresses, opes escolhidas).

Os tipos de requisitos para esse sistema so os requisitos no funcionais


(usabilidade), onde foi especificado o padro dos cadastros, acesso aos dados,
manual de instalao e de usurio, autenticao, segurana (criptografia),
hardwares e ferramentas para o desenvolvimento, sempre voltando para a qualidade
de servio.

Para o diagrama de classes foram especificadas as classes: produto, vendedor,


pedido, pedido item, usurio (sendo classe pai de usurio restrito, usurio padro e
administrador do sistema, gerando uma herana). Cada classe foi atribuda a uma
representao de multiplicidade.

Por fim, os prottipos de tela foram desenvolvidos com base nos atributos das
classes do diagrama e aos requisitos no funcionais.

As metodologias utilizadas para a elaborao foram as aulas de Anlise de Sistemas


Orientado a Objetos, Interface Homem-Mquina e conhecimentos profissionais,
sendo um trabalho que otimiza o tempo de desenvolvimento e garante qualidade.
ABSTRACT

This document shows a project that has Systems Analysis aspects Object Oriented,
in order to initiate the development of a system for the company Model Autoparts,
which hired the services of the company Pacific Solutions to remedy its shortcomings
in its processes: control inventory and incorrect calculations in the commission of
vendors.

The demonstration takes place through the survey and specifications of use cases,
use case diagrams, requirements, class diagrams, business rules and interface
prototypes (layout screens).

Use cases are representations of externally observable features, the system is based
on sales and inventory control of its products, so were identified as use cases:
Product registration and vendor registration (each has the option to change, delete
and consultation), joined to launch an application and may select one or more
products and assign a salesman, salesmen commission calculation on top of the
application (this is done automatically at the time of checkout).

It was also developed a case of user registration use, where there are three types:
restricted user, default user and system administrator. Restricted users have access
only to query features, as well as the default user and system administrator. Standard
User is responsible for launching an application and system administrator for
registering products, sellers and new users.

The use case diagram shows system activities for the types of users in a stream, and
specifications are detailed internal processes (validations, prints, chosen options).

The types of requirements for this system are non-functional requirements (usability),
which was specified standard of entries, access to data, installation and user manual,
authentication, security (encryption), hardware and tools for the development, where
turning to the quality of service.

For the class diagram classes were specified: product, vendor, order, order item, the
user (and user parent class restricted default user and system administrator,
generating an inheritance). Each class has been assigned to a representation of
multiplicity.

Finally, screen prototypes to have been developed based on the attributes of the
class diagram and nonfunctional requirements.

The methodologies used in the preparation were the Systems Analysis classes
Object Oriented, Human Machine Interface and professional knowledge, and a job
that optimizes development time and ensures quality.
SUMRIO

1 INTRODUO

2 CASOS DE USO (DIAGRAMA)

3 ESPECIFICAO DE CASOS DE USO


3.1 Aes para o Cadastro de Produto
3.2 Consulta de Produtos
3.3 Aes para o Cadastro de Vendedor
3.4 Consulta de Vendedores
3.5 Aes para o cadastro de Usurio
3.6 Pedidos e Comisso de Vendedores...........................................................13

3.7 Gerao de Relatrio para Balano

4 REQUISITOS NO FUNCIONAIS
4.1 Padronizao dos Cadastros
4.2 Acesso aos Dados
4.3 Manual de Instalao

4.4 Manual de Usurio....

4.5 Acesso Autenticado.

4.6 Criptografia de Senhas

4.7 Ambiente.......................

4.8 Ferramentas para o Desenvolvimento.........................................................22

4.9 Hardwares.......................................................................................................23

5 DIAGRAMA DE CLASSES.............................................................................24

6 PROTTIPO DE TELAS DO SISTEMA.........................................................25

6.1 Cadastro de Produto


6.2 Consulta de Produto
6.3 Cadastro de Vendedor

6.4 Consulta de Vendedor...

6.5 Cadastro de Pedido


6.6 Consulta de Pedido....
7
CONCLUSO.................................................................................................31

8
REFERNCIAS.............................................................................................32
6

1 INTRODUO

Uma loja chamada Modelo Autopeas, localizada no Rio de Janeiro, possui


processos falhos e deficientes em seu trabalho, com muita ao humana no
registro de informaes, descontrole do estoque, gerao de clculos incorretos
no valor de comisso de vendedores e atrasos nas compras de produtos para
reposio de estoque. Seu proprietrio, visando corrigir esses processos,
contratou a empresa Pacific Solutions para criar um software que possa sanar
essas deficincias em seus processos.

O objetivo para realizao desse trabalho identificar os casos de usos, assim


como elaborar os modelos de casos de uso, os relacionamentos entre as
entidades (classes) necessrias para o desenvolvimento do sistema, descrever os
requisitos no funcionais e de usabilidade, identificar e descrever o contexto de
uso e regras de negcio, elaborar os diagramas de classes de anlise e os
prottipos das telas principais.

Com isso ser possvel desenvolver um sistema slido, com o mnimo de erros e
que se adeque e resolva problemas nos processos da loja, alm de garantir a
usabilidade do usurio, regras de negcios bem elaborados, prazos bem definidos e
a satisfao do cliente.

As metodologias utilizadas para a elaborao sero os conceitos visto em anlise de


sistemas orientado a objetos (construo de digramas, classes, e especificao de
requisitos) e interface homem-mquina (layouts).

2 CASOS DE USO (DIAGRAMA)


7

Foi elaborado um diagrama dos casos de uso principais do sistema,


mostrando os setores da empresa, usurios comuns (padro), usurios
restritos e administradores do sistema, cada um deles associados sua
funo como mostra a imagem a seguir:

3 ESPECIFICAO DE CASOS DE USO


8

3.1 Aes para o Cadastro de Produto

Objetivo: O operador usa o sistema para controlar os produtos do estoque, e os


bens permanentes na entrada, sada.

Atores envolvidos: Administrador do Sistema.

Pr-condies: O produto ser cadastrado, deve ser oriundo de uma Nota Fiscal
vlida.

Fluxo Principal:

1 - O operador faz logon no Sistema e entra no cadastro de Produto.

2 - O operador escolhe os cones de aes que sero executadas. Alterar - Incluir -


Excluir.

3 - Caso a opo escolhida seja Incluir:


- O sistema solicita os dados do novo produto (cdigo, descrio,
unidade de medida, estoque mnimo, estoque mximo e preo unitrio).

- O sistema verifica se o cdigo do produto j est existe ou est


cadastrado.

- Se o cdigo j estiver cadastrado uma mensagem de alerta ser


mostrado e o produto no ser inserido.

- Se o cdigo do produto no existir, esse produto ser includo no


estoque.

4 - Caso a opo escolhida seja Alterar:

- solicitado cdigo do produto para que seja efetuada a sua devida


alterao.

- Ser mostrado os dados j cadastrados desse produto, podendo o


operador atualizar a quantidade no estoque, para mais ou para menos.

- Aps feita a alterao, os novos dados so salvos.

5 - Caso a opo escolhida seja Excluir:

- solicitado o cdigo do produto para que seja efetuada a sua devida


excluso.

- Aps a excluso, o cadastro desse produto apagado do sistema.

6 - Ps-Condies: o sistema deve mostrar a quantidade do produto no


estoque.
9

3.2 Consulta de Produtos


Objetivo: O operador usa o sistema para consultar os produtos do estoque,
e os bens permanentes na entrada, sada.

Atores envolvidos: Usurio Restrito, Usurio Padro e Administrador do


Sistema.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema.

2 - O sistema solicita informaes do produto ser consultado (cdigo, descrio).

3 - O usurio faz a digitao dos dados do produto.

4 - A consulta realizada e as informaes do produto so exibidas na tela.

5 - O sistema oferece ao usurio a opo de impresso.

6 - O operador fecha a tela de exibio.

7 - Ps-Condies: A consulta de dados do produto foi realizada.


10

3.3 Aes para o Cadastro de Vendedor

Objetivo: O operador usa o sistema para fazer a incluso, excluso e alterao no


cadastro de Vendedores.

Atores Envolvidos: Administrador do Sistema.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema e entra no cadastro de Vendedor.

2 - O operador escolhe os cones de aes que sero executadas. Alterar - Incluir -


Excluir.

3 - Caso a opo escolhida seja Incluir:

- O sistema solicita os dados do Vendedor (cdigo, nome, se ele


comissionado e a porcentagem de comisso).

- O sistema verifica se o cdigo do vendedor j est existe ou est


cadastrado.

- Se o cdigo j estiver cadastrado uma mensagem de alerta ser mostrado e


o vendedor no ser inserido.

- Se o cdigo do vendedor no existir, esse vendedor ser includo no


sistema.

4 - Caso a opo escolhida seja Alterar:

- solicitado cdigo do vendedor para que seja efetuada a sua devida


alterao.

- Aps feita a alterao, os novos dados so salvos.

5 - Caso a opo escolhida seja Excluir:

- solicitado o cdigo do vendedor para que seja efetuada a sua devida


excluso.

- Aps a excluso, o cadastro desse vendedor apagado do sistema.

6 - Ps condies: O Vendedor foi cadastrado, alterado ou excludo no sistema.


11

3.4 Consulta de Vendedores

Objetivo: O operador usa o sistema para consultar os vendedores da empresa.

Atores envolvidos: Usurio Restrito, Usurio Padro e Administrador do Sistema.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema.

2 - O sistema solicita informaes do vendedor ser consultado (cdigo, nome).

3 - O usurio faz a digitao dos dados do vendedor.

4 - A consulta realizada e as informaes do vendedor so exibidas na tela.

5 - O sistema oferece ao usurio a opo de impresso.

6 - O operador fecha a tela de exibio.

7 - Ps-Condies: A consulta de dados do vendedor foi realizada.


12

3.5 Aes para o cadastro de Usurio

Objetivo: O Administrador usa o sistema para fazer a incluso, excluso e alterao


dos usurios do sistema e suas devidas prioridades de acesso.

Atores envolvidos: Administrador do Sistema.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema e entra no cadastro de Usurio.

2 - O operador escolhe os cones de aes que sero executadas. Alterar - Incluir -


Excluir.

3 - Caso a opo escolhida seja Incluir:

- O sistema solicita os dados do novo usurio.

- O sistema verifica se o login j est existe ou est cadastrado.

- Se o login j estiver cadastrado uma mensagem de alerta ser mostrado e o


usurio no ser inserido.

- Se o login do usurio no existir, esse usurio ser includo no sistema.

- escolhida a prioridade de acesso ao sistema: A. Usurio Padro - B.


Usurio Restrito - C. Administrador.

- definida senha de acesso.

4 - Caso a opo escolhida seja Alterar:

- solicitado o login para que seja efetuada a sua devida alterao.

- Aps feita a alterao, os novos dados so salvos.

5 - Caso a opo escolhida seja Excluir:

- solicitado o login para que seja efetuada a sua devida excluso.

- Aps a excluso, o cadastro desse usurio apagado do sistema, assim


como sua prioridade de acesso.

6 - Ps condies: O Usurio foi cadastrado, alterado ou excludo no sistema.


13

3.6 Pedidos e Comisso de Vendedores

Objetivo: Operador usa o sistema para lanar um pedido.

Atores envolvidos: Usurio Padro.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema e entra no cadastro de Pedidos.

2 - O operador seleciona um ou mais produtos para entrar no pedido, informa a


quantidade de cada um.

3 - O operador atribui um vendedor para aquele pedido e automaticamente feito o


clculo do valor da comisso encima desse pedido (padro 2%) que o
vendedor ir receber.

4 - O operador finaliza o pedido.

5 - gerado uma listagem com as informaes do pedido, as descries dos


produtos, as quantidades, o preo unitrio, o total a ser pago, o vendedor
associado bem com o valor de comisso.

6 - O estoque atualizado automaticamente de acordo com a quantidade de


produtos que entraram no pedido (sada de estoque).

7 - O sistema oferece ao operador a opo de impresso.

8 - Ps condies: O pedido foi cadastrado e o estoque atualizado.


14

3.7 Gerao de Relatrio para Balano

Objetivo: O operador usa o sistema para gerar um relatrio para balano, de todos
os produtos do estoque.

Atores envolvidos: Usurio Restrito, Usurio Padro e Administrador do Sistema.

Pr-condies: O usurio deve ser identificado pelo sistema.

Fluxo principal:

1 - O operador faz logon no Sistema.

2 - O sistema solicita a data ou perodo.

3 - O operador faz a digitao do perodo.

4 - O relatrio exibido na tela.

5 - O sistema oferece ao operador a opo de impresso.

7 - O operador fecha a tela de exibio.

8 - Ps-Condies: O relatrio para balano por perodo, foi gerado.

4 REQUISITOS NO FUNCIONAIS
15

Para desenvolvimento, implantao e utilizao do sistema, deve ser


correspondido os seguintes requisitos no funcionais:

4.1 Padronizao dos Cadastros

Todos os cadastros do sistema devero obedecer um mesmo padro de usabilidade,


os quais permitam:

- Acesso direto ao registro pelo seu Cdigo (Produto x Vendedor x Pedido).

- Acesso ao registro atravs de uma Pesquisa avanada.

- Operao de Inserir, permitindo a insero de um novo registro.

- Operao de Alterar, permitindo a alterao do registro selecionado.

- Operao de Excluir, permitindo a excluso do registro selecionado.

- Operao de Salvar, permitindo a concluso do processo de insero ou de


alterao, persistindo os dados.

- Operao de Cancelar, permitindo a desistncia do processo de insero ou de


alterao, descartando os dados.

- Operao de Fechar, permitindo a sada da tela de cadastro.

- A tela de Pesquisa Avanada dever ser padro para todos os cadastros,


permitindo filtragem por qualquer campo do registro, de 3 formas:

- Incio: registros retornados conforme o incio do valor informado.

- Meio: registros retornados conforme o valor inteiro informado.

- Fim: registros retornados conforme o final do valor informado.

- Se algum dos campos do registro for uma data, a pesquisa avanada ainda
permitir a filtragem de registros atravs do fornecimento de um intervalo de
datas, filtrando registros cujo campo de data esteja no dado intervalo.
16

4.2 Acesso aos Dados

Todo acesso a dados dever ser realizado via ODBC de forma a reduzir o
acoplamento entre cdigo e banco de dados.

4.3 Manual de Instalao

O sistema deve vir acompanhado com um manual de instalao em formato PDF.


17
18

4.4 Manual de Usurio

O sistema deve vir acompanhado com um manual de operao para o usurio final,
em formato PDF, exemplificando as atividades e funcionalidades assim como
as restries.
19

4.5 Acesso Autenticado

Todo acesso ao sistema dever ser autenticado atravs do fornecimento de login e


senha vlidos. Tais dados de acesso devero estar armazenados no banco de
dados da aplicao.
20

4.6 Criptografia de Senhas

As senhas dos usurios da aplicao devem ser armazenadas de forma


criptografada no banco de dados da aplicao.
21

4.7 Ambiente

O sistema, composto de 2 partes, tem os seguintes requisitos de ambiente:

- Aplicao Cliente: Dever ter como alvo principal o Windows 10, com a linguagem
php instalado e o servidor Web Apache.

- Banco de Dados: Dever ser empregado qualquer sistema operacional que suporte
o Microsoft SQL Server 2012.

- O sistema funcionar em qualquer rede TCP/IP que permita comunicao remota


atravs de ODBC ou Client do SQL Server da aplicao Cliente ao servidor de
Banco de dados. Quaisquer firewalls devem ser configurados para permitir
essa comunicao.
22

4.8 Ferramentas para o Desenvolvimento

O sistema dever ser desenvolvido utilizando o Visual Studio 2013, aproveitando


suas funcionalidades de testes de unitrios e cobertura de cdigo.

Para banco de dados, sero utilizados o SQL Server e o SQL Server Management
Studio.
23

4.9 Hardwares

O sistema, composto de 2 partes, tem os seguintes requisitos de hardware:

- Aplicao Cliente: Mnimo de 128mb de memria livres para a operao do


sistema.

- Banco de Dados: Os mesmos requisitos de hardware do SQL Server 2012.

5 DIAGRAMA DE CLASSES
24

6 PROTTIPO DE TELAS DO SISTEMA

6.1 Cadastro de Produto


25

6.2 Consulta de Produto


26

6.3 Cadastro de Vendedor


27

6.4 Consulta de Vendedor


28

6.5 Cadastro de Pedido


29

6.6 Consulta de Pedido


30

7 CONCLUSO
31

Com a utilizao de tcnicas de levantamentos de requisitos, documentao


dos mesmos, diagramas, casos de uso e prottipos de telas, um projeto pode
ser otimizado no que diz respeito a gerenciamento, mudanas de regras de
negcio, planejamento, acompanhamento dos usurios envolvidos,
promovendo uma maior interao do prprio usurio no ciclo de vida de
desenvolvimento do software.

Neste projeto conseguimos analisar todas essas fazes para sanar uma
dificuldade em um dos processes do nosso cliente, a loja Modelo Autopeas,
localizada no Rio de Janeiro.

Concluiu-se que para poder desenvolver um software de qualidade e que


atenda ao processo, requisitos e expectativas do cliente necessrio aplicar
tcnicas de anlise de sistemas orientados a objetos, otimizar a interface
com o usurio atravs de prottipos, aplicar tcnicas de gerenciamento de
projeto e engenharia de software e o prprio desenvolvimento do sistema
orientado a objeto.

Com isso podemos otimizar o tempo de desenvolvimento, mensurar de forma


mais precisa o cronograma, prazos e custos, analisar de forma precisa os
requisitos do sistema e gerar um produto altamente estvel e funcional.

8 REFERNCIAS
32

Unidades 1, 2, 3 e 4 da disciplina Anlise de Sistemas Orientado a Objetos,


da Unip Interativa, professor Fabio Versolatto.

BECK., and Kent. TDD Desenvolvimento Guiado por Testes. Bookman, 2010.
VitalBook file. Disponvel em: Acesso em: 02 de abril de 2015.

Maldonado, J. C.; Barbosa, E. F.; Vincenzi, A. M. R.; Delamaro, M. E.; Souza, S.


R. S.; Jino, M. Introduo ao teste de software. Relatrio Tcnico 65 - Verso
2004-01, Instituto de Cincias Matemticas e de Computao ICMC-USP.

Conhecimentos sobre sistemas orientado a objetos obtidos em outras


instituies e experincias profissionais.

You might also like