Buscar

paulo Produção textual Produção de computadores

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 24 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 24 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 24 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

6
 
Sistema de Ensino Presencial Conectado
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
paulo sérgio cassol
Elizabete Aparecida Matias
Camila Evanquele Cadona
Eliane da Silva Mutz
Elias Francisco da Silva
projeto orientado á objetos:
Sistema de Controle de Produção de Computadores
Guarantã do Norte
2017
 
paulo sérgio cassol
Elizabete Aparecida Matias
Camila Evanquele Cadona
Eliane da Silva Mutz
Elias Francisco da Silva
 Utilizando tecnologias atuais e modernas para sistemas delivery
 
projeto orientado á objetos
Sistema de Controle de Produção de Computadores
Trabalho de portfólio apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral na disciplina de Análise e desenvolvimento de sistemas.
Orientador: Prof. Merris Mozer; 
 Leonardo Ferrareto;
 Paulo K. Nishitani;
 Iolanda Cláudia Sanches Catarino
 Roberto Nishimura.
Guarantã do Norte
2017
SUMÁRIO
1	INTRODUÇÃO	3
2	OBJETIVO	4
3	DESENVOLVIMENTO	5
3.1	ABORDAGEM DE REQUISITOS	5
3.2	PARADIGMAS DE DESENVOLVIMENTO	5
3.2.1	Pilares da orientação á objetos	6
3.3	PROJETO ORIENTADO Á OBJETOS	7
3.4	MODELAGEM DO SISTEMA	8
3.4.1	UML	8
3.5	DIAGRAMAS DA UML	9
3.6	DIAGRAMA DE CASO DE USO	9
3.7	DIAGRAMA DE CLASSES	10
3.8	MODELAGEM DE DADOS	11
3.8.1	Modelo conceitual	12
3.8.1.1	(MER) Modelo entidade Relacionamento	12
3.8.2	Modelo lógico	13
3.9	PROTÓTIPO DE SISTEMA EM C# (Sharp)	14
3.10	ESTRUTURA DE DADOS COM C#	17
3.11	REFLEXÕES SOBRE O DESENVOLVIMENTO	19
4	CONCLUSÃO	20 REFERENCIAS......................................................................................................................21
5	ANEXOS	22
 ANEXO A - A importancia do levantamento de requisitos no sucesso dos projetos de software
INTRODUÇÃO
Nesta dissertação vou apresentar o projeto do sistema para Produção de computadores, baseado na Engenharia de requisitos e com apoio da Orientação a objetos. Apresentar a UML e os diagramas de classe e de caso de uso, apresentar a estrutura de dados e o código fonte em C# (Sharp), modelo de banco de dados no nível conceitual e lógico e as regras de negócio.
OBJETIVO
Após ter levantado os requisitos de sistema, baseado na descrição textual narrativa do cliente, vou criar os diagramas de Caso de Uso e o Diagrama de Classe utilizando UML e orientação a objetos. A outra etapa é modelar o banco de dados, identificando as Entidades, Relacionamentos, atributos e suas regras de negócio. Criar os modelos conceitual e lógico.
Apresentar a estrutura de dados utilizada e explicar as regras de operação bem como apresentar o código fonte na linguagem C# (Sharp).
DESENVOLVIMENTO
 ABORDAGEM DE REQUISITOS
 Para iniciar o projeto, é preciso fazer o levantamento dos requisitos, entrevistar o cliente para que possamos entender suas necessidades e desejos, estes serão mapeados, e então definirão e documentarão o que o software precisa fazer para atendê-lo de forma adequada.
O conjunto de toda essa documentação formará a especificação de requisitos do produto, além de detalhar o que o software deve fazer, esse documento servirá como uma espécie de contrato entre o cliente e nós, desenvolvedores. Caso ocorra qualquer comportamento diferente do esperado, será considerado um defeito, isso é feito para proteger o cliente, pois ele quer receber o que ele pediu e também protege á nós, porque não teremos que entregar nada além daquilo que nos foi solicitado.
 
Paradigmas de desenvolvimento
Um paradigma de desenvolvimento agrupa métodos e técnicas que seguem um mesmo conjunto de princípios. Um paradigma nada mais é do que um exemplo, modelo, padrão, conjunto de ideias, uma base filosófica. Os dois paradigmas mais utilizados são, estruturado e orientado a objetos. O paradigma estruturado tem algumas desvantagens, por exemplo, o gap semântico é maior, ou seja, a distância entre o problema no mundo real e no mundo computacional é grande, frequentemente gera sistemas difíceis de serem mantidos. Já a orientação a objetos é justamente o oposto, pois ela representa o mundo real no mundo computacional, através das classes, objetos, métodos e atributos. Outras características importantes são: alterabilidade, legibilidade, extensibilidade e apoio à reutilização.
Pilares da orientação a objetos
 Além das características importantes como, reusabilidade e extensibilidade, a orientação a objetos tem alguns conceitos essenciais, são eles: Abstração, que consiste na seleção de alguns aspectos de domínio do problema a modelar. Encapsulamento, o encapsulamento almeja tornar o software mais flexível, fácil de alterar e de criar novas implementações. Métodos, que representam as atividades que uma classe pode executar. Representam um conjunto de instruções que são executadas quando eles são chamados. Os atributos são as características de uma classe, ou seja, as peculiaridades que costumam variar de objeto para objeto. Objeto é uma entidade real ou abstrata, que modela um conceito presente na realidade humana, ocupando espaço físico ou lógico. É a base para todos os outros conceitos da orientação a objetos. Classe, uma classe representa uma categoria e os objetos são membros dessa categoria. Herança, permite o reaproveitamento de atributos e de métodos otimizando, assim, o tempo de construção do código.
Figura 01 : Representação gráfica da diferença entre paradigma estruturado e OO
projeto orientado á objetos
 O projeto Orientado a Objetos, é que vai transformar o modelo de análise criado, usando análise orientada a objetos, num modelo de projeto que serve como documento para a construção do software. Exige uma arquitetura de software multicamada, a especificação de subsistemas que realizam as funções necessárias e fornecem a infraestrutura de apoio, uma descrição de objetos (classes) que formam os blocos construtivos do sistema e uma descrição dos mecanismos de comunicação que permitem aos dados fluir entre camadas, subsistemas e objetos.
As quatro camadas do projeto OO são: Camada de subsistema, contém uma representação de cada um dos subsistemas que permitem ao software satisfazer os requisitos definidos pelo cliente e implementar a infraestrutura técnica que suporta esses requisitos. Camada de mensagens: contém os detalhes de projeto que permitem a cada objeto se comunicar com seus colaboradores. Essa camada estabelece as interfaces externa e interna do sistema. Camada de responsabilidade: contém as estruturas de dados e o projeto algorítmico de todos os atributos e operações de cada objeto. Figura 02 : As quatro camadas do projeto orientado á objetos
MODELAGEM DO SISTEMA
 A modelagem é sem dúvida a etapa mais importante da construção do sistema, nela são destacados as características ou comportamentos de um software que se quer desenvolver. Sendo de grande importância para a análise de requisitos, uma vez que auxilia a especificar as características e funcionalidades que o software deverá prover para o seu perfeito funcionamento. Para fazer a modelagem é necessário uma linguagem específica.
UML
Unified Modeling Language, ou UML, é a linguagem padrão para modelagem orientada a objetos, ela não é uma linguagem de programação, apenas têm como papel auxiliar a visualizar o desenho e a comunicação entre objetos. Permite visualizar os produtos do trabalho em diagramas  padronizados, e é muito usada para criar modelos de sistemas de software. Alguns exemplos de diagramas criados com UML são: Diagrama de classe, Diagrama de Caso de uso, Diagrama de robustez e Diagrama de objetos. A ferramenta quevou utilizar aqui é o Astah Community.
 Figura 03: Logo da ferramenta Astah UML
 
 
diagramas da uml
O objetivo dos diagramas é apresentar múltiplas visões do sistema, sendo que este conjunto de múltiplas visões é chamado de modelo. Podemos dizer que um modelo UML pode ser visto como um conjunto de diagramas que podem ser examinados e modificados a fim de compreender e desenvolver um sistema de software. A criação dos diagramas é extremamente importante para que futuramente o software não tenha erro. Os diagramas são para Engenharia de software o que as plantas são para a Engenharia Civil.
diagrama de caso de uso
Esse diagrama documenta o que o sistema faz do ponto de vista do usuário. Em outras palavras, ele descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz. Este artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos. Diagramas de Casos de Uso são compostos basicamente por quatro partes: Cenário, sequência de eventos que acontecem quando um usuário interage com o sistema. Ator, usuário do sistema, ou, um tipo de usuário. Use Case, é uma tarefa ou uma funcionalidade realizada pelo ator (usuário). Comunicação é o que liga um ator com um caso.
 
 Figura 04: Diagrama de Caso de uso 
diagrama de classes
O diagrama de classes representa a estrutura do sistema, recorrendo ao conceito de classe e suas relações. O modelo de classes resulta de um processo de abstração onde são identificados os objetos relevantes do sistema em estudo. Um objeto é uma ocorrência que tem interesse para o sistema em estudo e que se pretende descrever no seu ambiente, contendo identidade e comportamento. O comportamento de um objeto define o modo como ele age e reage a estímulos externos e a identidade de um objeto é um atributo que o distingue de todos os demais, sendo preservada quando o seu estado muda. Um objeto não é mais do que uma instância de classe.
 Figura 05: Diagrama de classe 
modelagem de dados
A modelagem de dados é uma técnica usada para a especificação das regras de negócios e as estruturas de dados de um banco de dados. Ela faz parte do ciclo de desenvolvimento de um sistema de informação e é de vital importância para o bom resultado do projeto. Modelar dados consiste em desenhar o sistema de informações, concentrando-se nas entidades lógicas e nas dependências lógicas entre essas entidades. 
 Modelagem de dados ou modelagem de banco de dados envolve uma série de aplicações teóricas e práticas, visando construir um modelo de dados consistente, não redundante e perfeitamente aplicável em qualquer SGBD moderno. A modelagem de dados se divide em três partes, modelo conceitual, modelo lógico e modelo físico.
Modelo conceitual
A modelagem conceitual baseia-se no mais alto nível e deve ser usada para envolver o cliente, pois o foco é discutir os aspectos do negócio do cliente e não da tecnologia. Os exemplos de modelagem de dados vistos pelo modelo conceitual são mais fáceis de compreender, já que não há limitações ou aplicação de tecnologia específica. O diagrama de dados que deve ser construído a é o Diagrama de Entidade e Relacionamento, onde deverão ser identificados todas as entidades e os relacionamentos entre elas. 
(MER) Modelo entidade Relacionamento
	 O modelo Entidade Relacionamento (MER) É um modelo conceitual utilizado na Engenharia de software para descrever os objetos (entidades) envolvidos em um domínio de negócios, com suas características (atributos) e como elas se relacionam entre si (relacionamentos). Em geral, este modelo representa de forma abstrata a estrutura que possuirá o banco de dados. Obviamente, o banco de dados poderá conter várias outras entidades, tais como chaves e tabelas intermediárias, que podem só fazer sentido no contexto de bases de dados relacionais.
Entidade, é um conjunto de objetos relevantes para o que se quer representar de maneira abstrata ou concreta e que pode ser encontrado na descrição textual como os substantivos. Simbologia, um retângulo. Relacionamento é um conjunto de associações entre os elementos que também tem relevância quando associados entre si, e que pode ser encontrado na descrição textual como os verbos. Simbologia, um losango. Atributo, é a característica relevante que se quer manter de uma entidade, encontrados com adjetivos na descrição textual. Simbologia, uma elipse. Chave primaria, atributo ou conjunto de atributos que tem a propriedade de identificar de forma única uma ocorrência da entidade. Cardinalidade, é a quantidade de ocorrências de entidades que podem estar associadas a uma ocorrência da entidade que se quer analisar. É a regra de negócio entre as entidades envolvidas no relacionamento, que podem ser 1: N,1:1,N:1 e N:N, onde 1 representa um e N representa vários.
 Figura 06: Modelo de banco de dados no nível conceitual
Modelo lógico
O modelo lógico já leva em conta algumas limitações e implementa recursos como adequação de padrão e nomenclatura, define as chaves primárias e estrangeiras, normalização, integridade referencial. Para o modelo lógico deve ser criado levando em conta os exemplos de modelagem de dados criados no modelo conceitual.
 Figura 07 : Modelo de banco de dados no nível lógico
 protótipo de sistema em c# (Sharp)
A primeira coisa a se fazer em um sistema de vendas é o cadastro de cliente, onde deve conter informações básicas, como: nome, telefone, e-mail e endereço. Essa parte de cadastro, no C#, consiste basicamente nos comandos WriteLine e ReadLine,como trata de números e nomes,vou precisar declarar variáveis do tipo int e Double e variáveis do tipo string. Ao final da execução o programa vai imprimir na tela o cadastro completo do cliente, com nome, telefone, e-mail e endereço.
 Figura 08 : Código fonte 1
 Figura 09 : Código fonte 2
estrutura de dados com C#
A estrutura de dados utilizada será a de fila. Uma fila é uma estrutura do tipo FIFO (First In First Out). Elementos novos são inseridos no lado In (fim da fila) e a retirada ocorre no lado Out (frente ou começo da fila). Nos sistemas de produção de computadores o exemplo de fila é o pedido do cliente, que é colocado em ordem, o primeiro que entra é o primeiro que sai. O pedido 01 precede o pedido 02 que precede o pedido 03 e assim sucessivamente. A linguagem utilizada será o C# . O sistema será capaz de armazenar o pedido. O sistema ainda calcula o valor total e, no fim da execução ele imprime na tela o pedido completo, com nome do cliente, itens do pedido e valor total.
 Figura 10 : Estrutura de dados
 
 
 
reflexoes sobre o desenvolvimento
O desenvolvimento deste projeto nos proporcionou o aprendizado de como proceder de maneira eficiente na estrutura do projeto, evidenciando o quão é importante e necessário os diagramas, estruturais e dinâmicos da UML, bem como o plano de projeto do banco de dados, o produto final só se tornou eficiente graças à uma boa base de projeto.
conclusão
	Com o uso da engenharia de requisitos para ter uma boa abstração do problema a ser resolvido, pude realizar o projeto orientado a objetos. Com base no projeto, montei o diagrama de caso e uso e posteriormente, o diagrama de classes, usando UML. Um modelo de banco de dados também foi um ponto importantíssimo, onde criei o modelo conceitual e ológico, por último utilizando uma estrutura de dados, fila (FIFO) e uma linguagem de programação também orientada a objetos, C#, criei o protótipo do sistema, uma tela de cadastro e outra de pedidos. Se não tivesse tido uma boa abstração, nada disso teria sido possível, com certeza não ficaria um bom trabalho. Isso mostra como a modelagem é importante no mundo computacional.
 
 REFERENCIAS
https://docs.kde.org/stable4/pt_BR/kdesdk/umbrello/uml-basics.html
http://www.youtube.com/watch?v=hfN6n5fJfLc
http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes.aspx
https://msdn.microsoft.com/pt-br/library/dd409432.aspx
http://www.cos.ufrj.br/~rfarias/cos121/filas.html
http://www.youtube.com/watch?v=RDrfZ-7WE8c&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV&index=3
http://www.youtube.com/watch?v=Ig4QZNpVZYs&index=4&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV
http://www.youtube.com/watch?v=v2nCgGSVCeE&index=6&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV
http://www.youtube.com/watch?v=_g05aHdBAEY&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV&index=7
http://www.youtube.com/watch?v=7gGFHzqh4d8&index=8&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV
http://www.youtube.com/watch?v=U5PnCt58Q68&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV&index=9
http://www.youtube.com/watch?v=j9473xQ39vY&list=PLHz_AreHm4dmSj0MHol_aoNYCSGFqvfXV&index=14
http://www.youtube.com/watch?v=vhvmZfxZhPw&list=PLfvOpw8k80WqtWFpNXEFz9zvZHediN2bu
 ANEXO A – A importancia do levantamento de requisitos no sucesso dos projetos de software
 A tarefa de desenvolvimento de software engloba uma série de fases e atividades que independentemente da metodologia escolhida, ocorrem para a realização do seu objetivo maior: entregar software funcionando corretamente dentro do orçamento e prazos previstos para o seu desenvolvimento. 
 Para atingir os objetivos do projeto, todas as atividades de desenvolvimento tem que ser criteriosamente elaboradas e desenvolvidas, seja usando uma abordagem de desenvolvimento mais rica em documentação tais como o poderoso UP (Unified Process) ou as excelentes metodologias ágeis (XP, SCRUM, etc.). Assim sendo, em qualquer uma delas encontraremos com maior ou menor rigor e formalização, atividades de análise de requisitos, design, definição de arquitetura, codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja, identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deve resolver é à base de um projeto de software de sucesso. 
 Muita ênfase é dada pelos profissionais de T.I. Nas atividades de projeto e codificação. Isso se deve em boa parte a formação dada aos profissionais de T.I. Pelas universidades, que focam em suas grades curriculares principalmente em disciplinas técnicas e cientificas. Tem muito a ver também com perfil pessoal e cultural dos profissionais que atuam na área em geral, formada eminentemente por técnicos, bastante interessados em bits e bytes e pouco afetos a assuntos administrativos. Isso tem mudado bastante recentemente, pois os profissionais de T.I. Têm percebido a importância da relação entre negócio e T.I. Entretanto, a atividade de levantamento de requisitos é de fundamental importância para que se construa o software certo, ou seja, é necessário antes de mais nada que os envolvidos no projeto de software saibam exatamente o que é esperado do aplicativo a ser construído. É muito importante também que todos os envolvidos saibam igualmente o que o software não fará. Isso pode parecer óbvio, mas nem sempre fica claro para todos os envolvidos do projeto sobre qual é a fronteira da aplicação. A fronteira da aplicação pode ser entendida como uma linha imaginária que circula e define objetivamente, dentre os requisitos de software, quais serão automatizados e quais não serão. 
É fundamental definir corretamente o que vem a ser um requisito: é uma especificação de uma característica ou propriedade que um sistema deve possuir ou fazer, assim como sua restrição de operação. Os requisitos podem ser definidos por diversas classificações tais como: requisitos de negócio, funcionais, não funcionais, etc. Larga documentação existem sobre o tema, tanto em livros como na Internet, portanto esse artigo não vai se prolongar sobre o assunto. 
Toda metodologia de desenvolvimento de software (MDS) propõe uma série de fases e atividades dentro do seu ciclo de vida e o encadeamento entre elas. Independentemente do nome dado a cada fase é extremamente recomendável que o processo contemple ao menos dois grandes grupos de atividades referentes a requisitos, que poderíamos chamar aqui de:
Especificação de requisitos - São todas as atividades realizadas para identificar, analisar, especificar e definir as necessidades de negócio que um aplicativo deve prover para solução do problema levantado. Requisitos que não refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes, mudanças em requisitos que já foram previamente acordados e a dificuldade para se chegar a um acordo entre profissionais de T.I. E usuários são os maiores problemas enfrentados no grupo de atividades de especificação de requisitos. 
Gestão de requisitos - Preocupa-se com a documentação, versionamento, controle de mudanças e qualidade dos requisitos levantados na fase de especificação de requisitos. Todo requisito apresenta um ciclo de vida único que acompanha a dinâmica dos negócios associados. Assim sendo, não se pode esperar que um requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o requisito se desprende é dinâmico.
O gerente de um projeto de desenvolvimento de software deve atentar para a importância do correto entendimento das necessidades do aplicativo e deve disponibilizar seu(s) melhor(es) analista(s) para realizar a atividade de levantamento de requisitos. Essa etapa bem realizada servirá como uma fundação firme para a realização das atividades seguintes do projeto. É de suma importância que o gerente do projeto envolva-se ou designe alguém capacitado para a realização da gestão de escopo do projeto, inclusive criando um método criterioso de controle de mudanças. Não se dever confundir criterioso com burocrático. Muitas empresas cientes do problemas ocasionados por falta da correta gestão de escopo, tentam "blindar" os requisitos do projeto, tornando qualquer alteração morosa e difícil, cercada de documentos e assinaturas que muitas vezes provocam o efeito contrário ao desejado. É importante que todos os envolvidos no projeto busquem harmonizar seus interesses em prol da consecução dos objetivos do projeto. 
Concluindo, podemos afirmar que sem uma correta definição e gestão dos requisitos do aplicativo é praticamente certo que o projeto terá o seu sucesso comprometido, frustrando as expectativas do cliente e comprometendo as metas e planos da empresa contratante.

Outros materiais