SISTEMA DE ENSINO PRESENCIAL CONECTADO

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

NOME

INDÚSTRIA TREETORAH
 NOME

INDÚSTRIA TREETORAH
Utilizando tecnologias atuais e modernas para sistemas delivery
 Sumário
1 INTRODUÇÃO ........................................................................................................... 3
2 OBJETIVO ................................................................................................................. 4
3 DESENVOLVIMENTO ............................................................................................... 5
3.1 ABORDAGEM DE REQUISITOS .................................................................. 5
3.2 Projeto orientado á objetos ........................................................................... 5
3.3 Modelagem do sistema ................................................................................. 6
3.3.1 UML ....................................................................................................... 6
3.4 Diagramas uml .............................................................................................. 7
3.5 Diagramas estruturais e comportamentais .................................................... 7
3.5.1 Diagrama de Caso de Uso ..................................................................... 8
3.5.2 Diagrama de Classes............................................................................. 9
3.5.3 Diagrama de atividades ....................................................................... 10
3.6 Modelagem de dados.................................................................................. 12
3.6.1 Modelo Conceitual ............................................................................... 12
3.6.2 (MER) Modelo Entidade Relacionamento ............................................ 12
3.6.3 (MRN) Modelo Relacional Normalizado ............................................... 13
3.7 Server-side e cliente side ............................................................................ 16
3.8 Linguagem de programação para web........................................................ 17
3.9 PHP............................................................................................................. 19
3.10 Programação Orientada a Objetos.............................................................. 21
4 CONCLUSÃO .......................................................................................................... 23
 3

1 INTRODUÇÃO

A produção textual a seguir baseia-se no estudo de caso Indústria de

papéis, a Treetorah, que está com a missão de proporcionar aos seus colaboradores,
parceiros e fornecedores a conscientização da responsabilidade sobre o meio
ambiente. A matéria-prima mais importante da empresa é a madeira, e há diversas
legislações sobre esse assunto. Considerando que o Sistema de Informação a ser
desenvolvido é voltado para o Controle de Reflorestamento, vamos desenvolver os
diagramas da UML, aplicando os conceitos de orientação à objeto, diagramas
estáticos e dinâmicos, tais como: Diagrama de classes, diagrama de caso de uso e
diagrama de atividades. Fazer o diagrama de Entidade-relacionamento para servir de
base para o banco de dados, passando pelas formas normais. Criar uma aplicação
web, com os conceitos de HTML para uma página inicial e inserção de dados e
conceitos de back-end, para a programação, onde vai conter os cálculos necessários,
como número de arvores a serem repostas e valores a serem pagos. A programação
será toda de acordo com os conceitos e normas da Programação Orientada a Objetos,
ou seja, na página que criaremos em PHP, deverão ter todos os dados passados por
uma Classe aplicando o conceito de "Encapsulamento" (métodos gets e sets) antes
de persistir no Banco de dados.
 4

2 OBJETIVO

Desenvolver os diagramas da UML, aplicando os conceitos de

orientação à objetos, elaborar o modelo de banco de dados antes de implementá-lo
no Mysql, passando pelas formas normais. Criar uma aplicação web para o calculo de
controle de reflorestamento, com as linguagens HTML e PHP. Passar os dados por
uma Classe aplicando o conceito de encapsulamento.
 5

3 DESENVOLVIMENTO

3.1 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 a nós, porque não teremos que entregar nada além daquilo que nos foi
solicitado.

3.2 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
 6

operações de cada objeto.

Figura 01: As quatro camadas do projeto orientado a objetos

3.3 MODELAGEM DO SISTEMA

A modelagem é sem dúvida a etapa mais importante da construção

do sistema, nela são destacadas 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ária uma linguagem específica.

3.3.1 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
 7

diagramas criados com UML são: Diagrama de classe, Diagrama de Caso de uso,
Diagrama de robustez e Diagrama de objetos. A ferramenta que vou utilizar aqui é o
Astah Community.

Figura 02: Astah, ferramenta utilizada

3.4 DIAGRAMAS 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.

3.5 DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS

Os diagramas comportamentais mostram como os objetos interagem

uns com os outros. Permitem assim modelar os aspectos dinâmicos de um sistema.
 8

Existem quatro tipos de diagramas de interação: diagrama de sequência, diagrama de

comunicação, diagrama de visão geral de interação, diagramas de tempo. O diagrama
de comunicação pode ser usado para mostrar como os objetos em um sistema
interagem sobre múltiplos casos de uso. Um diagrama de seqüência é tipicamente
usado para mostrar a interação de objetos em um único caso de uso. Um diagrama
de visão geral de interação descreve em alto nível o fluxo principal das interações. Os
diagramas de tempo são especializados para sistemas de tempo real e usam um eixo
de tempo. Ambos, diagramas de tempo e de visão geral serão tratados em um curso
mais avançado.
Os diagramas estruturais tratam o aspecto estrutural tanto do ponto
de vista do sistema, quanto das classes, cobrindo dois dos quatro pontos de vista
essenciais de uma modelagem. Exemplo: Diagrama de Classes.

3.5.1 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.
 9

Figura 03: Diagrama de caso de uso

3.5.2 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.
 10

Figura 04: Diagrama de Classes

3.5.3 Diagrama de atividades

O diagrama de atividades é um diagrama UML utilizado para modelar

o aspecto comportamental de processos. É um dos diagramas que mais sofreu
mudanças em seu meta-modelo, desde seu surgimento no UML 1.0. Neste diagrama,
uma atividade é modelada como uma sequência estruturada de ações, controladas
potencialmente por nós de decisão e sincronismo. Em seu aspecto mais simples, um
diagrama de atividades pode ser confundido com um fluxograma.
Entretanto, ao contrário de fluxogramas, os diagramas de atividades
UML suportam diversos outros recursos, tais como as partições e os nós do tipo fork
e merge, além da definição de regiões de interrupção, que permitem uma modelagem
bem mais rica do que simplesmente um fluxograma.
 11

Figura 05: Diagrama de atividades

 12

Figura 06: Diagrama de atividades 02

3.6 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.

3.6.1 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.

3.6.2 (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
 13

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.

3.6.3 (MRN) Modelo Relacional Normalizado

Normalização é um processo a partir do qual se aplicam regras a

todas as tabelas do banco de dados com o objetivo de evitar falhas no projeto, como
redundância de dados e mistura de diferentes assuntos numa mesma tabela.
Ao projetar um banco de dados, se temos um modelo de entidades e
relacionamentos e a partir dele construirmos o modelo relacional seguindo as regras
de transformação corretamente, o modelo relacional resultante estará, provavelmente,
normalizado. Mas, nem sempre os modelos que nos deparamos são implementados
dessa forma e, quando isso acontece, o suporte ao banco de dados é dificultado. Em
ambos os casos, é necessário aplicar as técnicas de normalização, ou para normalizar
(segundo caso citado), ou apenas para validar o esquema criado (primeiro caso
citado). Aplicando as regras descritas a seguir, é possível garantir um banco de dados
mais íntegro, sem redundâncias e inconsistências. Existem 3 formas normais mais
conhecidas, são elas:
 14

 1FN - 1ª Forma Normal: Todos os atributos de uma tabela devem ser atômicos,
ou seja, a tabela não deve conter grupos repetidos e nem atributos com mais
de um valor. Para deixar nesta forma normal, é preciso identificar a chave
primária da tabela, identificar a (s) coluna(s) que tem dados repetidos e removê-
la(s), criar uma nova tabela com a chave primária para armazenar o dado
repetido e, por fim, criar uma relação entre a tabela principal e a tabela
secundária.

 2FN - 2ª Forma Normal: Antes de mais nada, para estar na 2FN é preciso estar
na 1FN. Além disso, todos os atributos não chaves da tabela devem depender
unicamente da chave primária (não podendo depender apenas de parte dela).
Para deixar na segunda forma normal, é preciso identificar as colunas que não
são funcionalmente dependentes da chave primária da tabela e, em seguida,
remover essa coluna da tabela principal e criar uma nova tabela com esses
dados.

 3FN - 3ª Forma Normal: Para estar na 3FN, é preciso estar na 2FN. Além disso,
os atributos não chave de uma tabela devem ser mutuamente independentes
e dependentes unicamente e exclusivamente da chave primária (um atributo B
é funcionalmente dependente de A se, e somente se, para cada valor de A só
existe um valor de B). Para atingir essa forma normal, é preciso identificar as
colunas que são funcionalmente dependentes das outras colunas não chave e
extraí-las para outra tabela.
 15

Figura 07: Modelo conceitual

Figura 08: Modelo lógico

 16

3.7 SERVER-SIDE E CLIENTE SIDE

O servidor armazena arquivos HTML, o cliente solicita uma cópia

deste arquivo, então o servidor a fornece, a partir do momento que este arquivo está
na máquina cliente, o navegador então começa a ler o código-fonte e então temos
acesso ao conteúdo do site, por isso, essas tecnologias como HTML, CSS e
JavaScript são conhecidas como client-side, ou seja, funcionam do lado do cliente.
Existem tecnologia na web que funcionam de maneira oposta, onde se trabalha com
a linguagem de programação, como PHP. Para fornecer arquivos PHP, o servidor não
pode simplesmente fornecer uma cópia do arquivo, esse servidor precisa ser
especialmente preparado, para isso utiliza uma ferramenta para transformar uma
máquina em um servidor, o Apache. Essa ferramenta possui funcionalidades
adicionais, como o interpretador php, a partir do momento que o interpretador php
começa a agir, todo o código php inserido dentro do documento começa a ser
precessado, esse processamento vai gerar um arquivo HTML, nesse arquivo só vai
conter tecnologias client-side, o arquivo gerado não vai ser armazenado no servidor,
mas sim enviado diretamente para o cliente, a partir daí volta-se ao processo inicial,
onde o navegador começa a interpretar o código HTML. Ou seja, o PHP é uma
tecnologia Server-side, onde tudo funciona do lado do servidor. Existem outras
tecnologias server-side além do PHP, como ASP, que é incorporada à tecnologia
.NET, Ruby e JSP.
Para desenvolver em PHP não é necessário contratar um servidor,
para isso, basta por exemplo dividir o computador em duas partes, onde um lado é o
cliente e o outro lado é o servidor, para que isso seja possível, é preciso instalar o
apache, o MySQL e o interpretador PHP, mas não é necessário instalar as três
ferramentas separadamente, existem ferramentas que incorporam as três tecnologias,
esses programas são chamados de AMP, que significa justamente as iniciais dos
programas (Apache, MySQL,PHP). Isso também varia de acordo com o Sistema
operacional que se usa, se utilizarmos Windows, a ferramenta vai ser WAMP, no caso
do Linux, vai ser LAMP e caso seja Mac OS, vai se chamar MAMP.
 17

Figura 09: Diferenças entre AMP’s

3.8 LINGUAGEM DE PROGRAMAÇÃO PARA WEB

Um formulário HTML é apenas um "rosto bonito” onde os usuários

poderão inserir informações que serão interpretados de alguma maneira por algum
script do lado do servidor. E no nosso caso, esse script é um script PHP.
Primeiro, antes para poder enviar as informações, o formulário deve
conter um botão submit, Segundo: todos os campos que serão tratados no script PHP
devem conter o parâmetro NAME, caso contrário, os dados não serão passados para
o script PHP.
Como as informações do formulário são passadas para esse script
PHP e como as informações do formulário enviado são tratadas, dependem de cada
desenvolvedor. Existem 2 métodos como as informações podem ser passadas: GET
e POST. O recomendável sempre, para todos os formulários é usar o método POST,
onde os dados enviados não são visíveis nas URLs, ocultando possíveis importantes
 18

informações e permitindo o envio de longas informações. O GET é totalmente o

contrário disso.
Nesse caso, a classe escolhida para fazer o CRUD, foi a classe
Cliente.

Figura 10: Front-End, Código-fonte do Cadastro HTML

 19

Figura 11: Tela de formulário HTML

3.9 PHP

O PHP é uma linguagem de criação de scripts do lado servidor, que

foi projetada especificamente para a web.
Dentro de uma página HTML, podemos embutir código PHP que será
executado toda vez que a página for visitada. O código PHP é interpretado no servidor
web e gera o HTML necessário para a aplicação rodar. Geralmente tudo o que um
programa CGI faz, o PHP também faz. Desde a coleta de informações de um
formulário, geração de páginas dinâmicas, enviar e receber cookies, e uma das
melhores características do PHP é o suporte nativo a diversos bancos de dados, tais
como Mysql, Oracle e vários outros.
 20

Figura 12: back-End, Código-fonte do Cadastro PHP

 21

Figura 13: Tela do resultado da calculadora

3.10 PROGRAMAÇÃO ORIENTADA A OBJETOS

A implementação do sistema com C#, consiste na programação da

página “CalculadoraReflorestamento.php”, já vista anteriormente, onde todos os
dados deverão ser passados por uma Classe aplicando o conceito de
Encapsulamento, assim contendo as informações necessariamente requeridas, que
são: Ano, Estado, número de árvores cortadas e volume. Para que seja possível
adicionar todos esses atributos, será preciso criar as respectivas classes. Para ler e
gravar esses dados usamos as propriedades get e set. As propriedades permitem
que uma classe exponha de uma maneira pública a obtenção e definição dos valores.
 22

Figura 14: Código-fonte em C#

 23

4 CONCLUSÃO

Ao final do trabalho, todos os requisitos foram atendidos, desde a

parte estrutural até a implementação do sistema completo de reflorestamento. Foram
elaborados todos os diagramas UML solicitados, utilizando os conceitos aprendidos
sobre orientação à objetos, foi criado também, o modelo de banco de dados, com as
técnicas de Entidade-Relacionamento, passando o diagrama pelas três formas
normais e, posteriormente, foi gerado o modelo lógico. A parte prática do sistema
propriamente dato, foi desenvolvida a aplicação web, para o cálculo de controle de
reflorestamento. Com a linguagem HTML foi feita a página inicial, onde os dados
seriam inseridos, a outra página, essa em PHP, tem como objetivo fazer os cálculos
necessários a partir dos dados inseridos, a programação foi feita utilizando os
conceitos de operadores aritméticos, operadores de atribuição, varáveis. Ao final, com
a linguagem C# (Sharp), criamos a classe com o intuito de passar os dados por uma
inseridos, utilizando método get e set (encapsulamento).

.
 24

REFERÊNCIAS

CURSO PROGRAMAÇÃO ORIENTADA À OBJETOS

https://www.youtube.com/watch?v=djYrOHJc5Jg Acesso em: 28 Ago 2018

CURSO PHP – OPERADORES ARITIMÉTICOS

https://www.youtube.com/watch?v=F7KzJ7e6EAc&list=PLHz_AreHm4dm4beCCCm
W4xwpmLf6EHY9k Acesso em: 30 Ago 2018

FUNDAMENTOS BÁSICOS UML

https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/sep04/
bell/index.html Acesso em: 10 Set 2018

TUTORIAL PHP
https://www.devmedia.com.br/php-tutorial/32540 Acesso em: 15 Set 2018

O QUE É PHP?
https://becode.com.br/o-que-e-php/ Acesso em: 22 Set 2018

FUNDAMENTOS UML
https://docs.kde.org/trunk4/pt_BR/kdesdk/umbrello/uml-basics.html Acesso em: 24
Set 2018

ENTENDENDO O DIAGRAMA DE CLASSES

https://www.ateomomento.com.br/uml-diagrama-de-classes/ Acesso em: 26 Set 2018

TUDO SOBRE PHP

https://www.alura.com.br/cursos-online-programacao/php Acesso em: 30 Set 2018

CONCEITOS ORIENTAÇÃO À OBJETOS

https://www.devmedia.com.br/principais-conceitos-da-programacao-orientada-a -
objetos/32285 Acesso em: 05 Out 2018

PROGRAMAÇÃO ORIENTADA À OBJETOS

https://becode.com.br/programacao-orientada-a-objetos-poo/ Acesso em: 08 Out
2018

LINGUAGEM C#
https://www.devmedia.com.br/guia/linguagem-csharp/38152 Acesso em: 10 Out 2018

O QUE É O C#
https://www.oficinadanet.com.br/artigo/526/c_sharp_csharp_o_que_e_esta_linguage
m Acesso em: 12 Out 2018
25