Projeto-Integrado-II-ADS-BackEnd-Web-Mobile-DevOps

Prévia do material em texto

LEIDIANA SOARES DE BARROS
UNIVERSIDADE ANHANGUERA – UNIDERP
CENTRO DE EDUCAÇÃO À DISTÂNCIA
ADS - BACKEND - WEB - MOBILE - DEVOPS 
PROJETO INTEGRADO II
RIO GRANDE
2022
PROJETO INTEGRADO II
Trabalho apresentado à Universidade ANHANGUERA, como requisito parcial para a obtenção de média semestral nas disciplinas de 
Professores: 
Prof.ª Adriane Aparecida Loper;
Prof.º Gilberto Fernandes Junior;
Prof.º Leonardo Santiago Sidon da Rocha;
Prof.º Vanessa Matias Leite. 
Tutor (a): Vanice Dalto
SUMÁRIO
1	INTRODUÇÃO	3
2	DESENVOLVIMENTO	4
2.1 LÓGICA INDUTIVA E LÓGICA DEDUTIVA	4
2.2 FERRAMENTAS CASE	5
2.3 PSEUDOCÓDIGO	11
2.4 REQUISITOS DE SOFTWARE	12
3 CONSIDERAÇÕES FINAIS	14
REFERÊNCIAS	15
.
1 INTRODUÇÃO
Atraídos pela necessidade em disponibilizar conteúdos e serviços aos consumidores, grandes empresas focam seus esforços de publicidade e marketing em aplicativos que sejam acessíveis ao público possuidor de smarthphones. Essa rápida evolução tem oferecido um campo muito atrativo para desenvolvedores de software, que podem oferecer soluções de forma ágil e eficientes para o mercado. Como esse mercado é voltado a consumidores que utilizam diferentes sistemas operacionais, surge à problemática de como atingir efetivamente o maior público possível com uma solução robusta.
Mais de 345 milhões de smarphones foram vendidos até o segundo trimestre de 2015 de acordo com Internacional Data Corporation (IDC), onde 4 sistemas operacionais dominam a maior fatia do mercado. Atualmente a loja da Google contabiliza mais de 1,43 milhões de aplicações enquanto a Apple Store tem 1,21 milhões. 
O modelo padrão de desenvolvimento de aplicativos para dispositivos móveis é a criação de uma aplicação nativa para cada SO (Sistema Operacional), porém isto tem um custo elevado de projeto (MARTIN FOWLER, 2012). 
O crescimento do mercado de aplicações leva a necessidade de atender rapidamente o tempo de mercado. Assim como as oportunidades do mercado levaram ao surgimento de aplicações multiplataformas nos computadores pessoais nos anos 90, aplicativos móveis são mais frequentemente disponibilizados para múltiplas plataformas (ALLEN SARAH, 2010).
3
2 DESENVOLVIMENTO 
2.1 LÓGICA INDUTIVA E LÓGICA DEDUTIVA
· Lógica Indutiva
A lógica indutiva é aquela em que se parte de alguns exemplos para se formular uma teoria. Por exemplo, se eu nunca vejo um avião caindo, eu concluo que avião não cai. Se um ataque terrorista nunca aconteceu contra as torres gêmeas, eu concluo que é impossível haver um ataque terrorista contra as torres gêmeas. Você faz uma teoria baseada em algumas observações.
· Lógica Dedutiva
Já a lógica dedutiva é o contrário: você deduz que uma consequência existirá baseada na verificação de algumas premissas. Por exemplo, se eu sei que todas as pessoas são mortais, e que você é uma pessoa, eu deduzo que você é mortal. Na lógica dedutiva eu não parto de exemplos, mas de premissas (de verdades incontestáveis ou comprovadas). Se as premissas são verdadeiras (“você é uma pessoa” e “todas as pessoas são mortais”), a conclusão também precisa ser verdadeira (“você é mortal”). Por outro lado, se a premissa é falsa (se o que eu achava que era verdadeiro é falso), a conclusão pode ser falsa ou não. Por exemplo, se eu digo que “todo ser humano tem dois olhos e que você é um ser humano, logo você tem dois olhos”, eu parti de uma premissa que não é verdadeira (nem todo ser humano tem dois olhos), e por isso a conclusão pode ser ou não verdadeira (você pode ter ou não dois olhos), e isso será ditado pelo acaso. O que faz uma lógica indutiva funcionar são suas premissas. É por isso que os cientistas perdem tanto tempo testando coisas que todo mundo “já sabe” que é verdadeiro. Na verdade, nós não sabemos, nós achamos. Os cientistas precisam testar para terem certeza que a premissa é verdadeira. Mais um exemplo de lógica dedutiva com uma premissa falsa: aviões não caem, e eu estou em um avião, logo meu avião não vai cair. Se a premissa é falsa (avião não cai), a conclusão pode ser falsa (o avião pode cair) ou não (o avião pode não cair).
2.2 FERRAMENTAS CASE
A definição para a palavra CASE é: Computer Aided Software Engineering, ou seja, engenharia de software assistida por computador. A ideia central é: são ferramentas que auxiliam o processo de engenharia de software. 
Existem diversas ferramentas no mercado tais como (Rational Rose, Genexus, Clarify, Multicase, Paradigm, Together, entre outras.). Citaremos as ferramentas específicas para área de banco de dados, tais como (DBDesigner, Erwin, Embarcadero, Workbench, Oracle Designer).
Principais Características das ferramentas case para banco de dados: 
1) Suporte a Diagramas: 
2) Scripts SQL 
3) Forward Engineer: a partir do Der [diagrama de entidade relacionamento] você conecta no banco e implementa automaticamente o modelo físico. Este recurso permite que uma pessoa sem conhecimentos de SQL, Structured Query Language, implemente um Der diretamente no banco. 
4) Reverse Engineer - a partir do modelo físico implementado no banco você consegue gerar o Der. Este recurso permite que uma pessoa que não conheça o modelo implementado no banco possa extrair o DER. Um cenário que podemos citar é de um novo contratado da empresa que precisa desenvolver um sistema baseando-se no banco de dados já existente em uma empresa. Ele pode, através do uso de uma ferramenta case, conectar-se à base de dados e extrair o modelo existente.
5) Documentação: durante a criação das tabelas e atributos você já documenta, ou seja , já cria o dicionário de dados do seu modelo. Desta forma é possível sempre ter a documentação atualizada.
Principais Vantagens: 
1) Melhor documentação – sempre atualizada 
2) Maior velocidade no desenvolvimento de projetos 
3) Qualidade dos processos 
4) Interface gráfica
· Exemplos de Ferramentas Case:
Mysql Workbech
Características:
Gratuito
Site para download: http://wb.mysql.com/
Versão atual: 5.1.18 - alpha
Suporte para Banco: Mysql
Principais Recursos:
INTERFACE:
	
DIAGRAMAS:
DOCUMENTAÇÃO:
FORWARD ENGINEER:
REVERSE ENGINEER:
GERAÇÃO DE SCRIPTS:
Erwin
Características: Pago ou Trial para teste (30 dias mediante cadastro prévio no site)
Site para download: http://www.ca.com/us/data-modeling.aspx
Versão atual: 7.3
Suporte para Banco: Sql Server, Oracle, db2, entre outros.
OBS: os scripts e o banco escolhido para o exemplo abaixo foi o
ORACLE.
INTERFACE:
DIAGRAMAS:
DOCUMENTAÇÃO: aqui é a interface onde colocamos os comentários para as tabelas e atributos.
GERAÇÃO DE RELATÓRIOS:
FORWARD ENGINEER:
2.3 PSEUDOCÓDIGO
2.4 REQUISITOS DE SOFTWARE
· Requisitos Funcionais
Esclarecido o que são requisitos é hora de desmembrá-los explicando cada um, começamos pelos requisitos funcionais. Dentro da engenharia de uma empresa de software podemos destacar o requisito funcional, onde há a materialização de uma necessidade ou solicitação realizada por um software. Porém, vários Requisitos Funcionais podem ser realizados dentro de uma mesma funcionalidade. São variadas as funções e serviços que um sistema pode fornecer ao seu cliente, descrevemos abaixo algumas das inúmeras funções que os softwares podem executar:
· Incluir/Excluir/Alterar nome em uma tela de manutenção de funcionário;
· Geração de relatório de determinado período de vendas;
· Efetuar pagamentos de compra através de crédito ou débito;
· Consulta e alterações de dados pessoais de clientes;
· Emissão de relatórios de clientes ou vendas
· Consulta de saldo ou estoque.
Os requisitos funcionais são de extrema importância no desenvolvimento de aplicativos, pois, sem eles não há funcionalidades nos sistemas. Seus modelos devem ser construídos em um nível de entendimento claro e objetivo, além de um código fonte totalmente aplicável. Conclusão, parase obter requisitos funcionais de qualidade a fábrica de software deve estar atenta a síntese e a semântica dos mesmos.
· Requisitos Não Funcionais
Uma vez que os Requisitos Funcionais definem o que o sistema fará, a Engenharia de Software afirma que os Requisitos Não Funcionais definem como o sistema fará, embora não seja tão claro assim essa definição. Os Requisitos não Funcionais não estão relacionados diretamente às funcionalidades de um sistema.
Também chamado de atributos de qualidade ainda assim é de grande importância no desenvolvimento do sistema. Tratados geralmente como premissas e restrições técnicas de um projeto os requisitos não funcionais são praticamente todas as necessidades que não podem ser atendidas através de funcionalidades.
Geralmente mensurável, os requisitos não funcionais definem características e impõe limites do sistema como método de desenvolvimento, tempo, espaço, Sistema Operacional, dentre outros e cuja medida pode ser determinada é importante que se associe essa medida ou referência à cada requisito não funcional. Para ficar mais claro temos alguns exemplos de propriedades e suas métricas:
· O tamanho pode ser medido em kbytes e número de Chip de RAM;
· A velocidade está ligada ao tempo de utilização da tela, ou transações processadas por segundos;
· A métrica da portabilidade é o número de sistema-alvo;
· A facilidade de uso pode ser medida pelo número de janelas ou o tempo de treino;
· A confiabilidade tem ligação com o tempo médio que o sistema pode vir a falhar, a disponibilidade ou até mesmo a taxa de ocorrência de falhas.
Esses são apenas alguns dos exemplos onde às propriedades e métricas são associadas a cada requisito não funcional. Além do mais esses requisitos não funcionais são divididos em três tipos principais. Requisitos de Produto Final, Requisitos Organizacionais, Requisitos Externos que se dividem em diversos outros tipos. Listamos abaixo alguns exemplos básicos de requisitos não funcionais:
· Utilização do módulo de Informações Cadastrais em modo off-line;
· O sistema deve ser implementado na linguagem Java;
· O sistema deverá se comunicar com o banco SQL Server;
· Um relatório de supervisão deverá ser fornecido toda sexta-feira;
· O sistema deve ser executável em qualquer plataforma.
3 CONSIDERAÇÕES FINAIS
Através deste estudo foi possível avaliar a performance para utilização de recursos de contatos da plataforma Android. Através dos resultados obtidos pode-se perceber que utilização do SDK nativo Android é muito superior a utilização de outros frameworks, para a funcionalidade avaliada. Vale ressaltar que apesar desta performance de acesso a conteúdo do dispositivo ser baixa, é uma tecnologia que proporciona uma facilidade no desenvolvimento de aplicações móveis devido a utilização de tecnologias Web. 
O presente trabalho focou apenas algumas entre várias funcionalidades disponíveis pelas plataformas de programação, novas comparações entre outras funcionalidades podem ser úteis para projetistas e desenvolvedores na hora de decidir uma abordagem para desenvolver aplicações móveis. Pois a performance das aplicações em dispositivos móveis afeta diretamente a satisfação dos usuários.
REFERÊNCIAS
ALLEN, S. Pro Smartphone Cross-Platform Development. Editora Apress 2010.
FOWLER, M. Developing Software for Multiple Mobile Devices. Disponível em <http://martinfowler.com/articles/multiMobile/>. Acesso em 26 set 2021. 
FOWLER, M. Selecting a Mobile Implementation Strategy. Disponível em <http://martinfowler.com/articles/mobileImplStrategy.html>. Acesso em 26 set 2021.
Material do prof. Rafael de A. Segura: aulas de ferramentas case.
Teorey Toby J; Lightstone Sam; Nadeau Tom. Projeto e Modelagem de banco de dados. 4a ed. Rio de Janeiro: Elsevier, 2007. 
ZANETI, L. A. (2003). Sistemas de informação baseados na tecnologia web: um estudo sobre seu desenvolvimento. Disponível em <http://www.teses.usp.br/teses/disponiveis/12/12139/tde-14082003-104928/>. Acesso em 26 set 2021.