Protótipo de Aplicativo Móvel para Apoiar o Levantamento de Requisitos de Software

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC
CENTRO DE EDUCAO SUPERIOR DO ALTO VALE DO ITAJAI

CEAVI
BACHARELADO EM SISTEMAS DE INFORMAO

ANDERSON KRGER

PROTTIPO DE APLICATIVO MVEL PARA APOIAR O
LEVANTAMENTO DE REQUISITOS DE SOFTWARE

IBIRAMA, SC
2013
ANDERSON KRGER


Trabalho de Concluso de Curso apresentado como
requisito parcial para obteno do grau de Bacharel em
Sistemas de Informao oferecido pelo Centro de
Educao Superior do Alto Vale do Itaja da UDESC.

Orientador: Prof. Pablo Schoeffel.

IBIRAMA
2013
ANDERSON KRGER


Trabalho de Concluso de Curso apresentado como requisito parcial para obteno do grau de
Bacharel em Sistemas de Informao oferecido pelo Centro de Educao Superior do Alto
Vale do Itaja da UDESC.

Banca Examinadora

Orientador:
___________________________________________________________________________
Pablo Schoeffel, MSc.
Centro de Educao Superior do Alto Vale do Itaja CEAVI UDESC

Membro:
___________________________________________________________________________
Gustavo Luiz Pasqualini, MSc.

Membro:
___________________________________________________________________________
Osmar de Oliveira Braz Junior, MSc.

Ibirama SC, 18 de Novembro de 2013

Dedico este trabalho aos meus familiares,
amigos e colegas de trabalho que sempre me
incentivaram e apoiaram quando necessrio.

Cada sonho que voc deixa para trs, um
pedao do seu futuro que deixa de existir.
- Steve Jobs
RESUMO

O desenvolvimento de software vem enfrentando problemas encontrados no processo de
engenharia de requisitos, como diversidade de origem das informaes, problemas de
comunicao decorrentes da linguagem utilizada e principalmente pela falta de estruturao e
organizao das informaes coletadas. Com base nisto, o trabalho apresenta o
desenvolvimento de um aplicativo para iPad para auxiliar na coleta de artefatos de software
de forma que amenize estes problemas citados. As informaes so coletadas atravs das
interfaces disponveis no dispositivo, possibilitando posteriormente a exportao atravs de
arquivos XML no padro XMI, disponibilizando a mobilidade necessria na coleta das
informaes, diminuindo consideravelmente as possibilidades de perda de informaes
relevantes neste processo.

Palavras-chave: Artefatos de Software, Desenvolvimento iOS, Engenharia de Requisitos.
ABSTRACT

Software development is facing problems encountered in the process of requirements
engineering as diverse source of information, communication problems arising from the
language used and especially the lack of structure and organization of the information
collected. Based on these, the paper presents the development of an iPad app to assist in
collecting artifacts of software so that eases these problems cited. The information is collected
through the interfaces available on the device, enabling subsequent export via XML files in
XMI standard, providing the necessary mobility in the data collection, significantly reducing
the chances of loss of relevant information in this process.

Key-words: Artifact Software, iOS Development, Requirements Engineering.
LISTA DE ILUSTRAES

Figura 1 Processo de Engenharia de Requisitos .................................................................................. 17
Figura 2 Exemplo de Caso de Uso ...................................................................................................... 21
Figura 3 Rastreabilidade de Artefatos ................................................................................................. 22
Figura 4 iPhone: Primeira Verso ........................................................................................................ 25
Figura 5 iPad: Primeira Verso ............................................................................................................ 26
Figura 6 Trfego Dirio por Dispositivo ............................................................................................. 28
Figura 7 Faixa de Idade dos Usurios ................................................................................................. 29
Figura 8 Camadas do Sistema Operacional iOS .................................................................................. 30
Figura 9 Xcode: Interface Builder ....................................................................................................... 32
Figura 10 Conceito da Ferramenta: iRequire ...................................................................................... 35
Figura 11 Trabalho Correlato: iRequire ............................................................................................... 36
Figura 12 Trabalho Correlato: Usecase Designs ................................................................................. 36
Figura 13 Diagrama de Atividades ...................................................................................................... 39
Figura 14 Diagrama de Casos de Uso ................................................................................................. 44
Figura 15 Modelo de Dados ................................................................................................................ 52
Figura 16 Estrutura de Dados Resultante ............................................................................................ 53
Figura 17 Estrutura do Projeto: Base de Dados ................................................................................... 54
Figura 18 Xcode: Viso Geral ............................................................................................................. 55
Figura 20 Representao das Integraes do Xcode ........................................................................... 56
Figura 21 Componentes da Estrutura da Aplicao ............................................................................. 57
Figura 22 Interface Builder: Propriedades da Interface ...................................................................... 60
Figura 23 Relacionamentos de classes com Frameworks ................................................................... 60
Figura 24 Componente UIActionSheet ............................................................................................... 63
Figura 25 Parse: Dashboard. ............................................................................................................... 65
Figura 26 Parse: Criao de Classe ..................................................................................................... 66
Figura 27 Parse: Criao de Coluna .................................................................................................... 66
Figura 28 Parse: Frameworks Necessrias .......................................................................................... 67
Figura 29 Parse: Chaves da Aplicao ................................................................................................ 67
Figura 30 Parse: Dados da Classe "Arquivo" ...................................................................................... 69
Figura 31 Parse: Anlise de Requisies ............................................................................................. 70
Figura 32 Estrutura do Documento XMI ............................................................................................. 71
Figura 33 Diagrama de Classes: Gerao XMI ................................................................................... 72
Figura 34 Performance: CPU Utilizada ............................................................................................... 74
Figura 35 Performance: Utilizao de Memria ................................................................................. 75
Figura 36 Tela inicial do Aplicativo .................................................................................................... 76
Figura 37 Lista de Artefatos do Projeto ............................................................................................... 76
Figura 38 Fragmentos de um Artefato ................................................................................................. 77
Figura 39 Definio de Novo Fragmento ............................................................................................ 77
Figura 40 Definio de Fragmento: Texto ........................................................................................... 78
Figura 41 Seleo de Imagem para o Fragmento Imagem .................................................................. 78
Figura 42 Lista de Requisitos do Fragmento ....................................................................................... 79
Figura 43 Definio de Novo Requisito .............................................................................................. 79
Figura 44 Exportao do Projeto ......................................................................................................... 80
Figura 45 Composio do E-mail do Arquivo de Exportao ............................................................. 80
Figura 46 Estrutura do Projeto ............................................................................................................ 81
Figura 47 Diagrama de Requisitos: Enterprise Architect .................................................................... 81
Figura 48 Diagrama de Requisitos: Visual Paradigm for UML .......................................................... 82
Figura 49 Link remoto de acesso ao Fragmento .................................................................................. 82
Figura 50 Fluxo da Aplicao .............................................................................................................. 82
LISTA DE QUADROS

Quadro 1 ndice de Aquisio de Tablets ............................................................................................ 27
Quadro 2 Trfego no proveniente de computadores .......................................................................... 27
Quadro 3 Diferena na chamada de mtodos. ..................................................................................... 31
Quadro 4 Comparativo: Ferramentas Correlatas ................................................................................. 37
Quadro 5 Atores da Especificao ....................................................................................................... 40
Quadro 6 Regras de Negcios ............................................................................................................. 40
Quadro 7 Requisitos No-Funcionais .................................................................................................. 41
Quadro 8 Requisitos Funcionais .......................................................................................................... 42
Quadro 9 UC 01 Manter Projeto ...................................................................................................... 44
Quadro 10 UC 02 Manter Artefato ................................................................................................... 45
Quadro 11 UC 03 Manter Requisito ................................................................................................. 46
Quadro 12 UC 04 Manter Fragmentos de Artefato .......................................................................... 47
Quadro 14 UC 05 Definir Fragmento: Imagem ............................................................................... 48
Quadro 15 UC 06 Definir Fragmento: udio ................................................................................... 49
Quadro 16 UC 07 Definir Fragmento: Texto .................................................................................... 49
Quadro 17 UC 08 Exportar Projeto .................................................................................................. 50
Quadro 18 UC 09 Sincronizao BaaS ............................................................................................ 51
Quadro 19 Definio da classe AppDelegate ...................................................................................... 58
Quadro 20 Core Data: Novo registro. ................................................................................................. 58
Quadro 21 Registro de udio .............................................................................................................. 61
Quadro 22 Parmetros de Configurao do registro de udio ............................................................ 62
Quadro 23 Trecho da classe FragmentoImagemViewController ........................................................ 63
Quadro 24 Adequao ao Protocolo UIActionSheetDelegate ............................................................. 63
Quadro 25 Tratamento do retorno da seleo de imagem ................................................................... 64
Quadro 26 Definio do Parse no Aplicativo ...................................................................................... 67
Quadro 27 Implementao da Category: Fragmento+ParseControls .................................................. 68
Quadro 28 Gerao do Documento XML ........................................................................................... 72
Quadro 29 Representao dos elementos no XML ............................................................................. 73

SUMRIO
1 INTRODUO ........................................................................................................... 11
1.1 IDENTIFICAO DO PROBLEMA .......................................................................... 12
1.2 OBJETIVO ................................................................................................................... 12
1.2.1 Objetivos Especficos .................................................................................................. 13
1.3 JUSTIFICATIVA .......................................................................................................... 13
1.4 METODOLOGIA UTILIZADA ................................................................................... 14
1.5 ESTRUTURA DO TRABALHO .................................................................................. 14
2 FUNDAMENTAO TERICA ............................................................................. 16
2.1 ENGENHARIA DE REQUISITOS .............................................................................. 16
2.1.1 Concepo e Levantamento de Requisitos ............................................................... 17
2.1.2 Definio e Documentao de Requisitos ................................................................. 20
2.1.3 Rastreabilidade ........................................................................................................... 22
2.1.4 Negociao e Validao ............................................................................................... 23
2.1.5 Gesto de Requisitos ................................................................................................... 24
2.2 DISPOSITIVOS E APLICAES MVEIS .............................................................. 24
2.2.1 Definio, Estatsticas e Projeo .............................................................................. 25
2.2.2 Desenvolvimento para iPad ....................................................................................... 29
2.2.3 Computao em Nuvem ............................................................................................. 33
2.3 TRABALHOS CORRELATOS .................................................................................... 34
3 DESENVOLVIMENTO ............................................................................................. 38
3.1 FLUXO GERAL DA APLICAO ............................................................................. 38
3.2 ATORES, REGRAS DE NEGCIO E REQUISITOS. ................................................ 40
3.2.1 Regras de Negcio ....................................................................................................... 40
3.2.2 Requisitos No Funcionais ......................................................................................... 41
3.2.3 Requisitos Funcionais ................................................................................................. 42
3.3 CASOS DE USO .......................................................................................................... 43
3.4 MODELO DE DADOS ................................................................................................ 51
3.5 IMPLEMENTAO .................................................................................................... 55
3.5.1 Ambiente de Desenvolvimento ................................................................................... 55
3.5.2 Desenvolvimento da Aplicao .................................................................................. 56
3.5.3 Sincronizao: Servios BaaS .................................................................................... 64
3.5.4 Integrao: Gerao XML e Padro XMI ................................................................ 70
3.6 RESULTADOS E DISCUSSO .................................................................................. 74
4 SOLUO ................................................................................................................... 76
5 CONCLUSO ............................................................................................................. 84
5.1 EXTENSES ............................................................................................................... 85
REFERNCIAS ...................................................................................................................... 86

11

1 INTRODUO
A procura por aplicaes de qualidade tem crescido devido s exigncias dos consumidores,
que buscam facilidades em atividades do dia-a-dia, dando prioridade aos investimentos de baixo
custo e ampla abrangncia sobre suas necessidades. Por conta deste crescimento, empresas de
desenvolvimento procuram utilizar as melhores tecnologias disponveis para o cumprimento de
prazos e custos estipulados por seus clientes.
Com o surgimento de dispositivos mveis, a gama de tecnologias disponveis no mercado
aumentou, seu rpido crescimento possibilitou ento que aplicaes comuns fossem desenvolvidas
para este novo mercado, possibilitando ento maior mobilidade ao ambiente corporativo.
Por melhor que seja a tecnologia empregada no desenvolvimento de software, a necessidade
do cliente muitas das vezes continua incompreensvel, principalmente pelo fato de no haver um
modelo padro de coleta das suas necessidades, existindo apenas poucos parmetros para definio
de qualidade no registro. So identificados problemas principalmente nas etapas iniciais do
processo de desenvolvimento de software, processo denominado de engenharia de requisitos.
Com base nos problemas de escopo, entendimento e volatilidade, que ocorrem no processo
de engenharia de requisitos, desenvolveu-se um prottipo para gerenciar informaes coletadas que
compem o escopo de um projeto de software, tais como necessidades, regras, e funcionalidades
desejveis.
O proposto aplicativo pretende ser um facilitador no incio do processo de engenharia de
requisitos, mais especificamente na coleta de requisitos. Desenvolvido em plataforma mvel,
pretende minimizar as probabilidades de determinadas tarefas no serem realizadas e
principalmente maximizar a documentao e registro do conhecimento passado pelo interessado no
projeto.
Para se adequar aos processos j existentes, o aplicativo proposto disponibiliza
compatibilidade das informaes coletadas com outras ferramentas de especificao de software.

12

1.1 IDENTIFICAO DO PROBLEMA
Para Leffingwell (2009), muitos projetos acabam se tornando inviveis em decorrncia dos
erros no processo de definio de requisitos, que so os erros mais comuns no processo de
desenvolvimento de software e que exige maior custo para correo, caso exista. Leffingwell (2009)
complementa ainda que so necessrias habilidades de comunicao e compreenso para que sejam
reduzidos consideravelmente os erros na especificao de requisitos de software, que
consequentemente elevar a qualidade do produto final.
De acordo com o Standish Group (2011), em seu relatrio Chaos Report
1
, mesmo com a
utilizao de ferramentas e outras tcnicas, 24% projetos so cancelados antes de serem finalizados
e mesmo os finalizados chegam a 186% de seu custo originalmente estimado. O relatrio aborda
ainda que, mesmo entre os 39% de grandes projetos analisados que foram finalizados no tempo e
com custo previsto originalmente, a maioria no possua os requisitos com as caractersticas
especificadas no incio do projeto.
O Standish Group (2011) classifica os projetos analisados conforme os seus resultados
obtidos, considerando projetos de sucesso, fracasso, e os projetos desafiadores, aqueles que
necessitaram de ajustes, e acabam ultrapassando estimativas de prazo e custo para o escopo
definido. Entre os projetos de sucesso que somam cerca de 13% dos projetos, destaca-se como fator
para tal resultado: a definio clara de requisitos. Entre os principais motivos para que os projetos
fossem considerados como desafiadores destacam-se as especificaes e requisitos incompletos
com 12.3% e a mudana de especificaes e requisitos com 11.8%. Note que os dois fatores so
relevantes na definio de requisitos e foram responsveis por 24.1% das causas de se tornarem
projetos extrapolaram prazo, custo e o escopo.
Por fim, entre os motivos dos projetos no considerados de sucesso, esto: requisitos
incompletos (13.1%) e constante mudana das especificaes e requisitos (8.7%) (STANDISH
GROUP, 2011).
1.2 OBJETIVO
Desenvolver um aplicativo para dispositivo mvel para apoiar a coleta de informaes e
facilitar a definio de requisitos de software.

1
Chaos Report Relatrio que utiliza como base projetos de software realizados, com o objetivo de apresentar um
desempenho geral no processo de desenvolvimento de software.
13

1.2.1 Objetivos Especficos
Permitir a coleta de requisitos em campo, atravs de tablet.
Disponibilizar o projeto em formato XMI para importao em outras ferramentas CASE,
como o Enterprise Architect.
Manter a rastreabilidade quanto a informao que originou um requisito.
1.3 JUSTIFICATIVA
Para Dean Leffingwell (2009), so enormes as evidncias de que a reduo de erros na
especificao de requisitos a nica e eficaz soluo para aumentar a qualidade de software com
reduo de custos. Em complemento a isto, Pressman (2011) menciona que muitas empresas j
utilizam ferramentas para a definio e controle de documentos e artefatos gerados no processo de
engenharia de requisitos. A definio de requisitos deve ocorrer com a utilizao destas
ferramentas, proporcionando consistncia e acessibilidade s informaes.
O registro de todos os dados, no momento em que os mesmos so repassados pelo
interessado no projeto ao analista de software, de grande importncia para que informaes no
sejam ocultadas ou esquecidas no momento da especificao de requisitos. A utilizao de uma
ferramenta para um dispositivo mvel ideal a esta necessidade, por possibilitar a captura imediata
de informaes com auxlio de interfaces de entrada disponveis nos dispositivos.
A necessidade de desenvolvimento de um aplicativo especfico surgiu aps a verificao em
lojas oficiais, buscando-se por aplicativos que possibilitassem a resoluo deste problema. Foram
encontrados poucos aplicativos especficos para Engenharia de Software, onde possuam apenas o
enfoque em processos ou gesto de projetos, no necessariamente para requisitos de software. Outro
fator importante na deciso de desenvolvimento de uma nova ferramenta foi o crescimento na
utilizao de dispositivos mveis nas organizaes.
Com o desenvolvimento da ferramenta, podero ser proporcionados os seguintes benefcios
para as organizaes:
Permitir a coleta das informaes atravs da ferramenta diretamente com o
interessado.
Manter o registro da necessidade do interessado com seu valor original, sem
possibilidades de distoro dos fatos ou desvios.
14

Possibilitar o registro no formato original: udio, imagem ou texto.
Manter um repositrio de todas as necessidades do incio ao fim do projeto, em
qualquer lugar e a qualquer momento.
Melhorar a qualidade do produto final em paralelo a diminuio de custos.
1.4 METODOLOGIA UTILIZADA
Para compreenso das etapas pertinentes ao processo de engenharia de requisitos, foram
realizadas pesquisas bibliogrficas, buscando por tcnicas de levantamento, formas de
documentao e mtodos de rastreabilidade. Foram identificadas caractersticas fundamentais de
um artefato de software e principais formas de coleta de informaes que compem requisitos de
software.
Foram utilizadas pesquisas bibliogrficas de forma que se compreenda a evoluo das
tecnologias mveis e, com base em pesquisas qualitativas, buscou-se mensurar o crescimento e
demonstrar a tendncia destas tecnologias na atualidade.
Por fim, foram realizadas pesquisas exploratrias com o objetivo de adquirir o conhecimento
necessrio para iniciar e realizar por completo o desenvolvimento do aplicativo. Foram realizadas
verificaes de documentos tcnicos na qual abordam conceitos, demonstraes e boas prticas no
desenvolvimento de aplicativos para sistemas iOS.
O prottipo de soluo foi desenvolvido com enfoque para o dispositivo iPad atravs da
ferramenta Xcode 4.5.1 em sistema operacional OS X 10.8.2 - Mountain Lion com a linguagem
Objective-C. O desenvolvimento do aplicativo ser abordado detalhadamente na seo 3.5.
1.5 ESTRUTURA DO TRABALHO
Inicialmente apresentada a fundamentao terica do trabalho, abordando na seo 2.1 os
conceitos da Engenharia de Requisitos, como definio de artefatos de software, processos de
concepo e levantamento de requisitos. Ainda nesta seo so abordados os processos de definio
e documentao, rastreabilidade, negociao, validao e gesto dos requisitos.
Na seo seguinte (2.2) sero abordados resultados referentes a pesquisas de crescimento e
tendncias de aplicaes e dispositivos mveis, os fatores que auxiliaram no crescimento,
tecnologias disponveis no desenvolvimento de aplicativos destes dispositivos.
15

Na seo 2.3 so abordados trabalhos e aplicaes recentes que abordam o desenvolvimento
para aplicaes mveis ou so aplicados diretamente para o gerenciamento de informaes e
requisitos de software, e acabaram motivando o desenvolvimento deste trabalho.
Ser apresentado o desenvolvimento do aplicativo (Seo 3), mostrando detalhadamente o
fluxo geral da aplicao (3.1), a definio de requisitos de software (3.2), cenrios de casos de uso
(3.3), modelo de dados (3.4) e na seo 3.5 a implementao.
Por fim, na seo 4 sero apresentados os resultados do aplicativo desenvolvido e concluso
do trabalho na seo 5.

16

2 FUNDAMENTAO TERICA
Com a finalidade de apresentar assuntos relevantes ao entendimento da soluo proposta,
nesta seo sero abordados tpicos da base terica. Alguns destes tpicos sero importantes para o
entendimento de tcnicas utilizadas na engenharia de requisitos de software, os formatos de
documentao, e o contexto geral da engenharia de requisitos, bem como sua relao com o restante
de um projeto de software.
Outros tpicos apresentaro as tendncias de aplicaes para dispositivos mveis, o
surgimento, histrico de crescimento e avano tecnolgicos destes dispositivos nos ltimos anos,
possibilidades no futuro, bem como tpicos que apresentaro os requisitos bsicos no
desenvolvimento especfico destes dispositivos.
2.1 ENGENHARIA DE REQUISITOS
Tonsig (2008) define um requisito como um conjunto de necessidades que foram
estabelecidos pelo cliente, estrutura e comportamento do software que ser desenvolvido. Em
complemento a isto, explica que o processo de engenharia de requisitos o ato de capturar todas as
funcionalidades para o software que ser desenvolvido, independente de prtica ou tcnica a ser
utilizada.
Para Pressman (2011), o modelo de requisitos do software estabelecido com o interessado
deve ser completo, correto e consistente, de forma que seja realizado um projeto de sucesso, pois o
mesmo ter forte influncia sobre a qualidade do processo completo e, por consequncia, do
produto final. Leffingwell (2009), da mesma forma, atribui que o objetivo no desenvolvimento de
software atender a real necessidade do cliente, de forma que se cumpram prazos e custos
estabelecidos.
A engenharia de requisitos ajuda os engenheiros de software a compreender melhor
o problema que eles vo trabalhar para resolver. Ela inclui o conjunto de tarefas que
levam a um entendimento de qual ser o impacto do software sobre o negcio, do
que o cliente quer e como os usurios finais vo interagir com o software
(SOMMERVILLE, 2011)

Segundo vila (2012), a engenharia de requisitos tem como principais objetivos: a melhor
qualidade do software, permitir o aumento de produtividade considervel no processo de
desenvolvimento, operao e manuteno do software. vila (2012) destaca, com grande
importncia, que a engenharia de requisitos permite um total controle sobre todas as etapas do
17

processo de desenvolvimento, para que o mesmo proceda conforme os custos, prazos e nveis de
qualidade desejveis.
Figura 1 Processo de Engenharia de Requisitos

Fonte: Adaptado de Pressman (2011)
Desta forma, o processo de engenharia de requisitos pode ser composto de acordo com a
Figura 1, iniciando o processo pela concepo e levantamento de requisitos, que abordada na
prxima seo.
2.1.1 Concepo e Levantamento de Requisitos
Pressman (2011) considera que o projeto de software surge no momento em que se v a
necessidade de uma nova ferramenta ou servio, ou identifica-se a necessidade de solucionar algum
problema, chamando esta etapa de concepo.
Pressman (2011) complementa ainda que, neste momento, so estabelecidas caractersticas
bsicas que a soluo requer. Em conjunto com os usurios, o engenheiro de software trabalha para
buscar as melhores solues aos problemas encontrados.
Christel e Kang (1992) abordam a existncia de diversos problemas no processo de
levantamento de requisitos que tambm so abordados por Pressman (2011). Estes problemas
podem ser basicamente classificados em trs categorias:
Problemas de escopo;
Problemas de entendimento;
Problemas de volatilidade.
18

Problemas de escopo, apresentados por Christel e Kang (1992), so encontrados em
situaes em que os requisitos so incompletos, no verificados, desnecessrios e potencialmente
no usuais. So originados pela falta de definio dos objetivos do sistema dentro da organizao.
Complementa que atravs de uma anlise organizacional e de contexto permite que estes objetivos
sejam capturados e, assim, seja realizada uma verificao da real necessidade do requisito.
Problemas de entendimento so caracterizados como a definio de requisitos ambguos,
incompletos, inconsistentes ou at mesmo incorretos, por no atender o que realmente os
interessados necessitam. Para especificar ainda mais, Christel e Kang (1992) definem ainda algumas
questes que podem auxiliar a compreender os problemas de entendimento:
Diversidade de origens e nveis de experincia entre os envolvidos no levantamento
de requisitos, onde o conhecimento comum a um grupo pode ser completamente
estranho a outro. Tais fatos dificultam na interpretao e integrao das informaes.
Problemas de comunicao decorrentes da linguagem utilizada, originado
principalmente pela grande diversidade de comunidades.
Falta na estruturao e organizao dos requisitos, decorridos da enorme quantidade
de informaes geradas. O entendimento da estruturao destas informaes depende
do conhecimento em comum na comunidade do interessado.
O ltimo problema abordado por Christel e Kang (1992) refere-se volatilidade dos
requisitos, que consiste na constante mudana de caractersticas e informaes. Se uma simples
mudana no for documentada corretamente, o requisito original se tornar incompleto,
inconsistente em verses futuras, e potencialmente inutilizado por ser composto de informaes
obsoletas. Outro fator impactante apresentado por Christel e Kang (1992) no problema de
volatilidade o fato de que as informaes so originadas de diversas fontes e em momentos
distintos, o que promove necessidades e objetivos conflitantes.
Com base nestes problemas encontrados, Pressman (2011) complementa que, para que os
engenheiros consigam contorn-los, deve existir uma atividade de coleta de requisitos organizada,
composta por diversas atividades que so sugeridas como necessrias para que se obtenham bons
resultados no processo de elicitao de requisitos. Dentre as tcnicas para realizar essa coleta,
Pressman (2011) cita:
Reunies: para vila (2012), baseia-se em conversas realizadas com usurios, a fim de
conhecer e especificar as principais funcionalidades da aplicao, proporcionando uma viso numa
perspectiva mais ampla. Tonsig (2008) define reunies como atos com maior negociao e
19

flexibilidade, onde duas ou mais pessoas, em carter formal ou no, definem as funcionalidades e
necessidades. Os aspectos contraditrios encontrados em reunies so ideais para a empresa,
auxiliam na explanao dos planos e buscam por superao de convergncias.
Prototipao: baseia-se no processo de desenvolvimento de uma aplicao inicial, para
experimentao, que permita ao usurio identificar funcionalidades necessrias no decorrer da
utilizao. Para Moraes (2009), a prototipao pretende explorar aspectos crticos da aplicao,
apresentando possveis problemas de comunicao com outros produtos, reduzindo
consideravelmente riscos na construo do sistema, pois o usurio verifica que o analista identificou
pontos importantes da aplicao.
Brainstorming: com a finalidade de encontrar ideias diferenciadas, o brainstorming explora
as melhores possibilidades. De modo geral, Moraes (2009) apresenta o brainstorming como uma
atividade onde os interessados, atravs de diversas rodadas, apresentam suas ideias a respeito de um
tpico a ser discutido. Aps cada rodada, ideias podem ser complementadas por outras, onde o
nico objetivo juntar a maior diversidade possvel, aumentando a possibilidade de serem
encontradas boas ideias. Ao final das iteraes, as ideias so analisadas por todo o grupo, mantendo
as boas, e realizando uma classificao por ordem prioritria (MORAES, 2009).
Workshops: uma tcnica complementar reunies que, segundo Moraes (2009), deve ser
uma reunio de forma estruturada, promovendo negociao entre diferentes pontos de vistas.
Workshops devem possuir objetivos, assuntos a serem discutidos, incio e trmino definidos
previamente, e devem ser finalizados ento com uma documentao de resultados obtidos.
Estudo Etnogrfico: no estudo etnogrfico o analista de sistemas integra o ambiente de
trabalho do cliente, as rotinas dirias so observadas e absorvidas, realizando a identificao de
pontos relevantes. Desta forma, so levantados requisitos implcitos, em rotinas reais, ao contrrio
dos processos formais que por muita das vezes no so relevantes para o cliente (MORAES, 2009).
JAD: Moraes (2009) apresenta o Joint Application Development como uma tcnica
estruturada, com o objetivo de formar requisitos para o projeto a ser desenvolvido. Consiste em
reunies composta por usurios experientes, analistas de sistemas e gerentes. Em complemento a
Morais (2009), Paludo et al. (2009) apresenta tambm os princpios do JAD:
Dinmica de grupo: desperta criatividade entre os integrantes para a determinao
dos objetivos e requisitos do sistema. Com orientao, definem escopo, objetivos, e
levantam problemas do processo atualmente aplicado.
20

Recursos Audiovisuais: como o grupo de integrantes da tcnica formado por
profissionais de reas distintas, a utilizao de recursos audiovisuais auxilia na
abstrao do sistema, e comunicao entre os integrantes.
Processo organizado e racional: atividades extremamente definidas, do incio ao fim
do projeto, garantindo um detalhamento suficiente para a identificao de pontos
falhos.
Documentao com abordagem WYSIWIG O que voc v o que voc obtm:
consiste na definio de um documento final, registrando detalhadamente os
resultados do processo, garantindo o aceite de todos os membros.
Moraes (2009) complementa ainda que a utilizao do JAD tem melhores resultados para
projetos de mdio e pequeno porte. Nos projetos de grande porte e complexos, devem ser utilizadas
mltiplas sesses de JAD para acelerar a definio de requisitos.
O processo de levantamento de requisitos demorado e um tanto complicado em alguns
momentos, com problemas decorrentes da falta de conhecimento ou no identificao das
necessidades do software pelo usurio, ou at mesmo na utilizao de uma linguagem tcnica ou
no adequada por parte do engenheiro para com o usurio e vice-versa, complementa vila (2012).
Segundo Filho (2003), uma vez compreendidos, analisados e aceitos, os requisitos devem
ser documentados com um nvel de detalhamento adequado, produzindo a documentao de
requisitos de software.
2.1.2 Definio e Documentao de Requisitos
A especificao do software um processo utilizado para encontrar problemas que
necessitam ser solucionados na organizao.
importante que o analista de sistemas conhea os diversos tipos de requisitos de software,
pois os mesmos sero utilizados constantemente e tero muita influncia quanto consistncia do
projeto e consequentemente no processo da organizao (YOUNG, 2004).
De forma que sejam compreendidos as diversas classificaes de requisitos, Young (2004)
define modelos de anlise que abordam os seguintes tipos de requisitos:
Regras de Negcio: so as bases para o surgimento dos requisitos funcionais. Nas
regras so definidos processos, diretrizes e regras a serem seguidas nos requisitos
funcionais.
21

Requisitos Funcionais: definem o que o software deve fazer. Estes requisitos podem,
por exemplo, especificar a forma de entrada de dados para o software, as sadas de
informaes que o software deve disponibilizar e todos os relacionamentos e
processamentos realizados entre estas informaes.
Requisitos No Funcionais: definem propriedades do sistema, como confiana e
segurana, a forma em que o usurio poder interagir com a aplicao.

Pressman (2011) aborda tambm a existncia de tipos de requisitos referentes validao,
performance, verificao, requisitos de usurios, requisitos do produto e de interface, que podem ser
facilmente adequados aos tipos aqui apresentados sem maiores impactos.
Aps a definio dos requisitos, recomendado atravs do padro internacional IEEE Std.
830 (1998) a realizao da documentao destes requisitos. Esta documentao importante para
estabelecer uma base de aceitao entre o interessado e o prestador do servio, o que reduz o
esforo de desenvolvimento, prov uma linha de base para a validao e verificao no decorrer do
projeto.
Para Blaschek (2002), a documentao de requisitos pode ser realizada atravs da linguagem
natural ou atravs da implementao de diagramas propostos pela UML. J Pressman (2011)
apresenta um modelo de requisitos ou tambm conhecido como modelo de anlise, e sugere ainda o
desenvolvimento de casos de uso para a documentao de requisitos.
Os casos de uso apresentam uma histria que representa a iterao desejada entre usurio e
sistema ao final do projeto, nas mais diversas circunstncias. Esta representao pode ser definida
de forma narrativa, esquemtica (Figura 2), ou com uma descrio geral entre tarefas e iteraes
(PRESSMAN, 2011).
Figura 2 Exemplo de Caso de Uso

Fonte: Elaborado pelo Autor (2013)
uc Exemplo de Caso de Uso
Real i zao de Tarefas
Ator A
Ator B
Tarefa A
Tarefa B
22

As histrias de casos de usos, independente da forma de representao, so compostas por
atores e tarefas realizadas. Para possibilitar maior detalhamento na elaborao, podem ser
adicionadas informaes como prioridade, frequncia de ocorrncia da histria e atores secundrios
(PRESSMAN, 2011).
O processo de documentao de requisitos permite a rastreabilidade dos mesmos,
promovendo maior segurana e controle na qualidade do software em possveis futuras alteraes.
2.1.3 Rastreabilidade
Por definio de Sayo e Leite (2011), a rastreabilidade de requisitos utilizada para prover
relacionamento entre requisitos, arquitetura e implementao final do sistema, possibilitando
adequada compreenso atravs de seus relacionamentos com outros requisitos e artefatos.
Sayo e Leite (2011), bem como Sommerville (2011), apresentam a rastreabilidade de
requisitos como a determinao dos antecedentes e consequncias implicadas. Desta forma, os dois
autores apresentam os seguintes tipos de rastreabilidade:
A rastreabilidade para trs, que permite ao analista de sistemas identificar a origem
de cada requisito. Permite identificar o motivo da existncia do mesmo, e avaliar o
impacto de mudanas realizadas.
A rastreabilidade para frente, tipo de rastreabilidade que permite verificar e avaliar
rotinas desenvolvidas que sero afetados para cada requisito. Permite tambm a
localizao dos requisitos que podero sofrer influncias em uma possvel alterao
de artefato.
Independente do formato da rastreabilidade, o fator de maior relevncia a permanncia de
uma ligao entre artefato original e artefato resultante do processo de anlise ou desenvolvimento
(ou vice-versa). As ligaes entre os mesmos podem ser verificadas na Figura 3.
Figura 3 Rastreabilidade de Artefatos

Fonte: Sayao e Leite (2011)
23

A utilizao da rastreabilidade resulta em melhores resultados na manuteno do software, j
que no momento de definio do software o modelo de requisitos no constitudo por completo,
grandes mudanas surgem no processo de desenvolvimento e com as mudanas a serem
incorporadas a mensurao de impacto se d de forma simplificada e concisa.
Aps a primeira verso do documento de requisitos, e junto com a manuteno da
rastreabilidade dos requisitos, inicia-se o processo de negociao e validao com o cliente, que
abordado na seo seguinte.
2.1.4 Negociao e Validao
Para que os envolvidos no projeto estejam satisfeitos com o desenvolvimento do mesmo,
Pressman (2011) considera a negociao uma etapa importante no desenvolvimento. Com base no
escopo de requisitos e nos recursos disponveis para o projeto, o engenheiro de software necessita
realizar vrias iteraes de anlise.
Pressman (2011) ainda aborda a anlise para negociao dos requisitos levando em
considerao fatores de conflito, prioridades dos interessados, e estimativas grosseiras de esforo
com a finalidade de projetar fatores de custo e impacto no projeto aos interessados. Tomado destas
informaes, em cada iterao de anlise, requisitos so eliminados, alterados, ou modificados em
conjunto, de forma que conflitos e casos inatingveis sejam negociados.
A validao representa a atividade em que obtemos o aceite do cliente sob determi-
nado artefato. No cenrio de engenharia de requisitos, esta atividade significa apro-
var junto ao cliente os requisitos que foram especificados. Embora aparentemente
simples, esta atividade pode ser bastante dificultada pelo cliente ou mesmo por um
processo de validao inadequado utilizado pela empresa (VILA, 2012).
Na validao de requisitos ocorrem novas verificaes de coerncia e qualidade dos
artefatos resultantes. Baseada em uma reviso formal, o principal processo de validao dos
documentos especificados. Requisitos so validados por engenheiros e interessados que ainda
verificam inconsistncias, realizam esclarecimentos de informaes omissas ou distorcidas
(PRESSMAN, 2011).
Para um melhor gerenciamento de requisitos, Pressman (2011) aborda a elaborao e
utilizao frequente de listas de checagem, determinando assim uma estrutura geral e de avaliao
para cada requisito especificado.
24

2.1.5 Gesto de Requisitos
O gerenciamento de requisitos baseia-se no processo de compreender e controlar as
mudanas dos requisitos do sistema, manter o acompanhamento dos requisitos individuais e manter
as ligaes entre os requisitos dependentes, de modo que seja possvel avaliar o impacto de
possveis mudanas (SOMMERVILLE, 2011).
Sommerville (2011) destaca a utilizao de Ferramentas CASE
2
para um apoio automatizado
no gerenciamento de requisitos, auxiliando no armazenamento, mantendo o mesmo em repositrios
de dados seguros e acessveis a todos os envolvidos no processo. Tal ao permite efetuar o
gerenciamento e controle de mudanas, atualizao de rastreabilidade, e a identificao de possveis
inconsistncias ocorridas aps alteraes.
O processo de gesto de requisitos compe a engenharia de requisitos por completo, pois a
mesma engloba todas as etapas aqui apresentadas, onde cada etapa pode ser repetida at a concluso
do projeto, finalizando assim o processo de engenharia de requisitos.
Com base na engenharia de requisitos, o prottipo a ser desenvolvido tem como objetivo
atuar como ferramenta auxiliar do processo de levantamento de requisitos, possibilitando a
definio de documentao do requisito, em seguida prover a rastreabilidade dos mesmos.
2.2 DISPOSITIVOS E APLICAES MVEIS
A gama de dispositivos mveis vem crescendo a cada dia, com o surgimento de novos
dispositivos e tecnologias dos mais diversos fabricantes e marcas. Ser abordado em um primeiro
momento, na Seo 2.2.1, a definio de dispositivos mveis, contextualizar seu surgimento,
apresentar estatsticas atuais de seu mercado e a projeo do mesmo para os prximos anos.
Em seguida, Seo 2.2.2, ser abordado o desenvolvimento para iPad, dispositivo para o
qual o aplicativo foi proposto.

2
Ferramentas CASE (Computer-Aided Software Engineering) o nome dado a categoria de ferramentas que auxiliam
em atividades de engenharia de software.
25

2.2.1 Definio, Estatsticas e Projeo
At o surgimento de smartphones, aparelhos celulares eram utilizados para realizar ligaes,
manter uma agenda de contatos, eventos e realizar simples clculos. Smartphones so definidos por
Cambridge University Press (2013) como aparelhos celulares que podem ser comparados a
pequenos computadores que possibilitam a conexo Internet.
Mesmo com o conceito de smartphones difundido apenas a partir de 2008, o mercado de
celulares e smartphones vm sofrendo uma revoluo. O aumento no poder computacional dos
aparelhos fez com que os mesmos ganhassem diversas funcionalidades atraindo assim seus usurios
(VASCONCELOS, 2013).
Vasconcelos (2013) aponta que as principais mudanas no mercado de smartphones
iniciaram aps o lanamento do primeiro iPhone em 2007 (Figura 4), com configurao de
hardware atraente e com caractersticas marcantes da sua fabricante, Apple. O aparelho possua um
design diferenciado, com foco em usabilidade atravs de uma tela sensvel ao toque e com apenas
um boto fsico.
Ento, ns estamos trazendo software inovador para um dispositivo mvel pela
primeira vez. [...] Um iPod, um telefone, um comunicador de internet mvel. Um
iPod, um telefone, um comunicador de internet mvel, estes no so trs aparelhos
separados! E ns estamos chamando de iPhone! Hoje a Apple vai reinventar o tele-
fone (Steve Jobs, 2007).
Com o lanamento do iPhone, a Apple consolidava sua liderana no mercado de
smartphones atravs de um sistema operacional baseado no OS X (utilizado pelos computadores
pessoais comercializados pela Apple), o iOS, onde seus principais concorrentes eram o sistema
operacional Symbian e Blackberries (CUNHA, 2012).
Cunha (2012) complementa que at o momento da introduo do iPhone no mercado,
celulares e internet eram extremamente separados. A internet era um servio baseado para
computadores, enquanto os celulares baseados apenas a telefonia.
Figura 4 iPhone: Primeira Verso

Fonte: Apple (2013)
26

Em novembro de 2007, a Open Hand Alliance (OHA), um grupo de empresas liderado pela
Google, lana um sistema operacional para smartphones baseados em linux, o Android. Com o
Android qualquer empresa poderia utilizar do projeto para atender suas necessidades, criando uma
nova plataforma de desenvolvimento, sem a necessidade de compartilhar as modificaes. J 2008
foi um marco histrico para equipamentos mveis, em um mercado composto principalmente pelos
sistemas operacionais iOS e Android, era registrada a superioridade na assinatura de planos de
internet para dispositivos mveis em relao a assinaturas fixas (ITU: INTERNATIONAL
TELECOMMUNICATION UNION, 2009).
Aps o surgimento e consolidao dos smartphones, a Apple inova novamente em janeiro de
2010 com o lanamento do tablet iPad (Figura 5). Tablets so computadores portteis, que possuem
um sistema operacional e suas diversas funcionalidades so disponibilizadas por meio de
aplicativos. Possibilita a navegao na Internet, edio de documentos, utilizao de jogos e
visualizao multimdia. Diferentemente de outros computadores, a sua utilizao se d
principalmente pela tela 100% sensvel ao toque (CUNHA, 2012).
Figura 5 iPad: Primeira Verso

Fonte: Apple (2013)
Embora possuam maior capacidade de armazenamento e processamento que um smartphone
e uma tela com maiores propores, os tablets no superam computadores pessoais como desktops
e notebooks (CUNHA, 2012). Atualmente, a gama de dispositivos, considerados por Cunha (2012)
de primeira linha, aborda dispositivos de diversas fabricantes:
iPad Apple.
Galaxy Tab Samsung
Motorola Xoom Motorola
27

Kindle Fire Amazon.com
De acordo com uma pesquisa realizada pela comScore (2013), nos perodos de Abril de
2012 a Dezembro de 2012, considerando as aquisies de tablets nos Estados Unidos, a Apple
lidera a lista de mais adquiridos. Embora a Apple esteja como a fabricante que mais vende,
destacado que a soma dos outros dispositivos que utilizam Android maior que de iOS, a lista pode
ser conferida na Quadro 1.
Quadro 1 ndice de Aquisio de Tablets
Posio Marca Modelo
1 Apple iPad
2 Amazon Kindle 2/Fire/HD
3 Acer Iconia/IconiaTab
4 Samsung Galaxy Note/Tab
5 Barnes & Nobles NOOK Color/Tablet/HD
Fonte: comScore (2012)
Conforme uma pesquisa realizada em 2011, o iPad j era o dispositivo tablet dominante em
todos os continentes, contribuindo com mais de 89 por cento do trfego de tablets em todos os
mercados. [...] O Brasil tem a segunda maior porcentagem de trfego nesses dispositivos vindo do
iPad, com 31,8%, apesar de que os mesmos somam menos de 1% do trfego total no pas. Em
Cingapura, onde os dispositivos que no so computadores somam quase 6% do total do trfego, o
iPad representa 26,2% desse trfego (COMSCORE, 2012).
O crescimento no trfego de Internet demonstrado atravs do Quadro 2, com dados
referentes ao trfego que originado pelo iPad, um produto que entrou no mercado no incio de
2010.
Quadro 2 Trfego no proveniente de computadores

Tablets Celulares Outros
iPad Android Outros iPhone Android Smartphones Celular iPod Touch Outros
Canad 33.5% 0.4% 1.3% 34.6% 8.2% 3.6% 1.5% 14.9% 2.0%
Brasil 31.8% 1.6% 0.0% 21.0% 11.7% 11.3% 17.3% 4.1% 1.1%
Alemanha 29.4% 0.9% 0.0% 35.1% 16.2% 4.6% 2.8% 8.3% 2.5%
Espanha 27.4% 0.8% 0.0% 34.2% 22.1% 7.2% 2.7% 3.6% 1.9%
Frana 26.9% 0.6% 0.0% 34.3% 17.1% 5.7% 5.5% 3.9% 6.0%
Cingapura 26.2% 1.4% 0.1% 51.9% 10.0% 3.9% 1.5% 4.8% 0.2%
Austrlia 25.9% 0.5% 0.0% 50.0% 10.5% 3.8% 1.8% 7.1% 0.4%
E.U.A 21.8% 0.6% 0.1% 23.5% 35.6% 6.7% 2.4% 7.8% 1.5%
Chile 12.9% 0.6% 0.0% 45.2% 13.9% 11.6% 9.1% 6.0% 0.7%
Argentina 12.4% 0.4% 0.0% 12.5% 23.2% 16.8% 27.5% 6.7% 0.5%
28

De acordo com a comScore (2012), estamos testemunhando a revoluo mobile, sendo que a
cada dia cresce a utilizao de dispositivos tablets e smartphones. Estes dispositivos so
considerados ferramentas de trabalho essenciais, se tornando assistentes pessoais e libertando o
usurio dos limites de um escritrio.
A organizao comScore (2012) ressalta ainda que, mesmo com o crescimento da utilizao
de tablets, a utilizao de smartphones no sofreu reduo, comprovando que os tablets no esto
substituindo outros dispositivos mveis, esto apenas complementando a experincia mobile.
O crescimento na utilizao de dispositivos ocorrido nos ltimos anos decorrncia
principalmente do baixo custo de hardware, crescimento de subsdios aos fabricantes, e
principalmente pelos planos de operadoras de telefonia mvel, ocasionando tambm um grande
crescimento no trfego de dados na Internet por meio de dispositivos mveis (COMSCORE, 2012).
Considerando Smartphones e Tablets como equipamentos recentes, e computadores j como
equipamentos muito bem consolidados no mercado, a comScore (2013) realizou uma pesquisa
buscando identificar o fluxo dirio das pginas de internet baseados nos dispositivos utilizados. Os
resultados so apresentados na Figura 6.
Figura 6 Trfego Dirio por Dispositivo

Para a comScore (2013), est sendo criado um padro de utilizao para cada plataforma, os
dispositivos mveis esto em particular criando ocasies de consumo, ou seja, sendo utilizados
quando as pessoas esto em movimento, por exemplo os smartphones no trnsito na hora do rush, e
os tablets em seu momento de relaxamento, como por exemplo a noite na cama. Enquanto os
computadores esto sendo utilizados durante o perodo de trabalho.
29

Tablets so muito intuitivos, as geraes mais antigas esto utilizando estes dispositivos ao
invs de computadores, que necessitam de maiores cuidados, um custo maior de manuteno, alm
de serem mais complicados (COMSCORE, 2013).
A proporo na utilizao de tablets com as respectivas idades dos usurios representado
na Figura 7.
Figura 7 Faixa de Idade dos Usurios

Com base em pesquisas como esta, nota-se a tendncia e o potencial na utilizao de
dispositivos mveis, que em poucos anos tiveram um crescimento considervel no mercado,
fazendo parte do dia a dia das pessoas tanto domesticamente como profissionalmente. A seguir, ser
abordado o desenvolvimento para a plataforma iOS, focado em dispositivos tablets, o iPad.
2.2.2 Desenvolvimento para iPad
Tcnicas utilizadas no desenvolvimento de aplicaes normais no podem ser utilizadas
diretamente no desenvolvimento tablets. Devem ser consideradas diversas abordagens, como os
padres utilizados na interface do usurio, a disponibilizao de novas formas de iterao com o
equipamento, como telas sensveis ao toque, utilizao de cmeras com reconhecimento de imagens
ou realidade aumentada (DEHLINGER e DIXON, 2013).
O iPad um tablet desenvolvido pela Apple que utiliza como sistema operacional o iOS,
composto por um conjunto de camadas, os quais realizam o controle de hardware e possibilitam o
gerenciamento de aplicativos. Junto ao sistema operacional j so disponibilizados diversos
aplicativos como navegador, agenda e gerenciador de e-mails (APPLE, 2013).
O sistema operacional iOS composto por diversas camadas, conforme a Figura 8, o que
possibilita ao desenvolvedor maior praticidade, pois a abstrao destas camadas de baixo nvel
30

reduz a quantidade de cdigos a serem desenvolvidos, encapsulando funcionalidades complexas
(APPLE, 2013).
Figura 8 Camadas do Sistema Operacional iOS

Fonte: Apple (2013)
Segundo Apple (2013), a camada Cocoa Touch dispe ao desenvolvedor a chave para o
desenvolvimento, definindo a estrutura bsica da aplicao e permitindo acesso s tecnologias de
notificaes, multitarefa e gestos.
J a camada Media possibilita ao desenvolvedor acesso a funcionalidades de mdia, tais
como reproduo de imagens, vdeos e sons. Essa camada responsvel pelo aplicativo ter boa
aparncia e ser agradvel (APPLE, 2013).
Para a Apple (2013), a camada de Core Services no deve ser utilizada pelo desenvolvedor,
sendo responsvel pelos servios fundamentais de funcionamento do dispositivo. Permite acesso
persistncia de dados local ou no iCloud
3
.
Na mais baixa camada de funcionalidades, Core OS, esto presentes o sistema operacional
em si, controle de threads, sistema de arquivos, alocao de memria, Bonjour e servios de DNS.
Ainda nesta camada esto presentes a Security Framework, disponibilizando segurana s
informaes contidas em cada aplicativo, e disponibiliza tambm a comunicao do sistema
operacional com hardwares externos (APPLE, 2013).
A Apple, criadora do dispositivo, disponibiliza junto ao sistema operacional a Xcode IDE,
que possui todas as ferramentas necessrias para desenvolver, instalar, executar e testar aplicativos
no dispositivo.
Para proceder o desenvolvimento de aplicativos para dispositivos com Sistema Operacional
iOS, utilizada a linguagem de programao Objective-C, uma variao da linguagem padro
ANSI C. Em adio ao padro ANSI C, o Objective-C tambm baseado no Smalltalk, uma das

3
iCloud um servio de computao em nuvem disponibilizado pela Apple para seus usurios. Possibilita o
armazenamento de Fotos, Msicas e Documentos.
31

primeiras linguagens de programao orientadas a objetos. O Objective-C foi desenvolvido para
disponibilizar ao ANSI C total suporte a orientao objetos (APPLE, 2013).
O Objective-C disponibiliza a framework Foundation, que implementa diversos objetos para
maior abstrao do ANSI C, disponibilizando assim classes como: NSInteger, NSArray,
NSMutableArray, NSString, NSNumber, entre outras. Toda classe no Objective-C definida em
dois arquivos separadamente: um arquivo com extenso .h, representando a interface da classe,
definindo o encapsulamento de atributos e mtodos; um segundo arquivo com extenso .m, no
qual definida a implementao propriamente dita, determinando o funcionamento de seus mtodos
e atributos (APPLE, 2013).
Ao iniciar o desenvolvimento com Objective-C, nota-se grande diferena quanto a sua
sintaxe em relao a outras linguagens. O Quadro 3 demostra um comparativo na chamada de
mtodos entre a linguagem de programao Java e Objective-C.
Quadro 3 Diferena na chamada de mtodos.

// Representao da chamada de mtodos em JAVA
objeto.metodo();
objeto.metodoComParametro(Parametro);
objeto.metodoComMaisParametros(Parametro String, 1);

// Representao da chamada de mtodo em Objective-C
[objeto metodo];
[objeto metodoComParametro: @Nome];
[objeto metodoComParametro: @Nome maisParametro: @1];
Para o desenvolvimento da interface para o aplicativo, a Apple disponibiliza aos
desenvolvedores a UIKit Framework da camada Cocoa Touch, contendo todos os componentes e
protocolos necessrios. atravs dela que possvel atingir o visual amigvel dos dispositivos iOS.
Inicialmente, definies visuais j eram realizadas por esta Framework em arquivos XML do tipo
XIB e manipulados pelo Interface Buider at a verso 4.0 do Xcode. Aps isto, a Apple realizou a
integrao entre todas as ferramentas de desenvolvimento (APPLE, 2013).
Atualmente o Xcode disponibiliza o Interface Builder em formato de Storyboard, definindo
a sequncia de cenrios do aplicativo e representao dos componentes de cada cenrio. Junto
representao de cada cenrio, o Storyboard ainda apresenta visualmente os relacionamentos
existentes entre os mesmos, conforme a Figura 9 (APPLE, 2013).

32

Figura 9 Xcode: Interface Builder

Atravs da interface definida, podemos realizar a ligao entre componentes visuais com
os controladores da aplicao. Como resultado destas ligaes, so criados no controlador
referncias do tipo IBAction para aes e IBOutlet para referncia de objetos, apenas a partir
destes que so disponveis o acesso interface. A prpria ferramenta auxilia nesta etapa, permitindo
que sejam feitas ligaes rpidas entre o Interface Builder e classes, gerando a definio de cada
referncia (APPLE, 2013).
Conforme Apple (2013), o desenvolvimento para plataformas Apple um conjunto de
tarefas administrativas e tcnicas, alm do tempo dedicado ao desenvolvimento do aplicativo,
tambm deve ser considerado um tempo de tarefas de administrao. Para iniciar o processo de
desenvolvimento de aplicativos, pelo menos uma pessoa deve se filiar ao acordo de desenvolvedor.
Esta pessoa, conhecida como agente de equipe, o responsvel legal pela equipe, adicionando
novos membros e atribuindo privilgios e responsabilidades (APPLE, 2013).
Aps o desenvolvimento da aplicao, o mesmo deve ser submetido aprovao, onde so
verificadas caractersticas de usabilidade, exigindo experincia agradvel ao usurio, verificao de
bugs e precaues quanto quebra de diretrizes (APPLE, 2013).
33

Com a aprovao do aplicativo, o mesmo pode ser publicado na App Store, loja de
aplicativos na qual o usurio final realiza as aquisies e download de aplicativos. Ao ser enviado
para publicao na App Store, o aplicativo criptografado e assinado. Tal operao possibilita ao
usurio a certeza de que o mesmo originado de um desenvolvedor filiado ao programa de
desenvolvimento e que o aplicativo possui qualidade comprovada pela Apple. Caso um aplicativo
seja instalado no dispositivo sem a necessria assinatura de segurana, o prprio sistema
operacional realiza o bloqueio de execuo (APPLE, 2013).
No podemos descartar tambm o desenvolvimento de aplicaes mveis hbridas, ou seja,
desenvolvidas em apenas uma tecnologia, de forma que seja acessvel para qualquer sistema
operacional. Para o desenvolvimento de aplicaes neste formato, podem ser encontradas diversas
frameworks, uma das mais conhecidas o Phonegap.
Para atender as necessidades do prottipo desenvolvido, ser abordado na prxima sesso a
computao em nuvem e servios disponveis nesta categoria.
2.2.3 Computao em Nuvem
Para Lane (2013) a computao em nuvem consiste na capacidade de processar e armazenar
informaes em servidores remotos, na qual as informaes so disponibilizadas a qualquer
momento atravs da internet.
Atualmente existem diversos servios para realizar processamento ou armazenamento de
informaes das aplicaes mveis em nuvem, estes servios podem variar de acordo com suas
necessidades, complexidades ou funcionalidades. Lane (2013) apresenta os principais servios para
computao em nuvem como sendo: IaaS, PaaS e Baas:
IaaS (Infrastructure as a Service) o servio que surgiu inicialmente com o propsito de
disponibilizar, principalmente a empresas e desenvolvedores, o completo servio de infraestrutura
necessrio para manter um servio de aplicao em nuvem, disponibilizando assim componentes de
armazenamento e processamento. Destaca-se neste tipo de servio plataformas como a Amazon
Web Services (LANE, 2013).
PaaS (Plataform as a Service) um servio que surgiu posteriormente, com o propsito de
disponibilizar a plataforma completa como servio, ou seja, o cliente contrata os servios da
prestadora e receber, alm da infraestrutura, a plataforma para utilizao, como: sistema
operacional, base de dados e outros, sem se preocupar com toda infraestrutura necessria. Mas,
34

nesse formato, o cliente ainda assim necessita de um conhecimento tcnico avanado para realizar a
gesto (LANE, 2013).
J o BaaS (Backend as a Service) um servio que visa prover aos desenvolvedores de
aplicativos WEB ou mveis uma forma simples de conexo de suas aplicaes a servios de
armazenamento em nuvem, possibilitando uma gesto de usurios, processamento das informaes,
o envio de Push Notifications
4
, integrao com redes sociais, e qualquer funcionalidade necessria
atualmente por aplicaes mveis (LANE, 2013).
Segundo Lane (2013), toda a complexidade referente instalao, manuteno e
disponibilidade dos servios abstrada, facilitando a criao de novas aplicaes. Lane (2013)
ainda cita as diversas vantagens na utilizao do servio, destacando-se a otimizao para
smartphones e tablets, segurana e escalabilidade da infraestrutura sem a interveno do
desenvolvedor e, principalmente, a eficincia dos servios.
O servio de BaaS considerado recente, tendo surgido a partir do ano de 2011 ou posterior,
em um mercado que possui uma estimativa de crescimento de $216.5 milhes em 2012 para $7.7
bilhes em 2017 (LANE, 2013).
Atravs da utilizao do servio de BaaS, o prottipo a ser desenvolvido poder enviar
informaes para que as mesmas estejam disponveis a outras ferramentas CASE.
2.3 TRABALHOS CORRELATOS
Aps pesquisas realizadas, foram encontradas poucas aplicaes comercias e projetos
acadmicos referentes especificao de software com enfoque para mobilidade ou funcionamento
em dispositivos mveis.
Na pesquisa realizada, destacou-se o artigo referente utilizao de aplicaes mobile para
realizar o envolvimento do usurio no processo de especificao de software. O trabalho baseia-se
no fato de que a maioria dos usurios esto acostumados com tecnologias mobile e que o nmero de
aplicaes desta plataforma vem crescendo consideravelmente. So apresentados conceitos
referentes ao envolvimento do usurio final, algumas funcionalidades necessrias para dar suporte a
todas as diferentes formas de documentao e o conceito da ferramenta (SEYFF, GRAF e
MAIDEN, 2010).

4
Push Notification denominado o servio responsvel pelo envio de notificaes do servidor para o dispositivo.
35

O conceito desenvolvido para ferramenta descreve atividades relevantes como realizar a
captura de imagem, som ou texto e realizar a pesquisa de informaes j cadastradas, possibilitando
maior detalhamento da mesma. A interface do conceito iRequire apresentado na Figura 10.
Figura 10 Conceito da Ferramenta: iRequire

Fonte: (SEYFF, GRAF e MAIDEN, 2010)
Aps o conceito definido, a ferramenta foi aplicada para 9 pessoas sem conhecimento em
definio de requisitos por 19 dias. Como resultado, os participantes obtiveram 80% de sucesso ao
registrar suas necessidades da forma que desejavam, imediatamente aps terem percebido a
necessidade. Embora tenham mencionado que as formas de definio sejam bastante limitadas.
Ammann (2011), utiliza o conceito iRequire em um projeto do Departamento de Informtica
da Universidade de Zurique. No projeto desenvolvido (Figura 11), o iRequire tem o objetivo de
possibilitar o usurio final a definio de interesse em novas funcionalidades ao software atravs de
uma aplicao para iPhone. Com base em Imagem ou Texto, o aplicativo registra sua necessidade,
responde algumas informaes relativas necessidade e, por fim, envia estas informaes a um
servidor.

36

Figura 11 Trabalho Correlato: iRequire

Fonte: Apple (2013)
O aplicativo desenvolvido gratuito e disponibilizado apenas na App Store dos Estados
Unidos. Ao utilizar o mesmo, identificam-se diversas restries, como por exemplo: a falta de
definio do projeto do qual est se reportando a necessidade; a falta da relao de necessidades j
reportadas.
Informaes tcnicas referentes ao servidor ou forma de sincronizao do aplicativo no
foram disponibilizadas pelo desenvolvedor.
Usecase Designs, desenvolvido pela Plumhead Software Ltd, um aplicativo tanto para
iPhone como para iPad, que se destina ao desenvolvimento de diagramas de caso de uso de forma
rpida e simplificada. Em sua interface para elaborao dos diagramas, permite a utilizao de
toques para realizar zoom dos componentes, adicionar novos atores, casos de usos, e o
relacionamento entre eles. O aplicativo no permite a realizao de divises em projetos ou pacotes,
permitindo apenas a criao dos diversos diagramas, conforme Figura 12.
Figura 12 Trabalho Correlato: Usecase Designs

Fonte: Apple (2013)
37

Aps o desenvolvimento dos diagramas necessrios, o aplicativo permite realizar o envio do
mesmo atravs de e-mail em formato de imagem ou PDF, dificultando assim o processo de
rastreabilidade das informaes (APPLE, 2013).
Desta forma, pode se identificar a carncia de aplicativos mveis para engenharia de
software no mercado brasileiro e mundial. Aplicativos encontrados possuem funcionalidades muito
restritas, onde poderiam agregar coisas simples, como o caso da gesto dos projetos, e a
exportao para outras ferramentas CASE.
Quadro 4 Comparativo: Ferramentas Correlatas
Funcionalidade
i
R
e
q
u
i
r
e

(
C
o
n
c
e
i
t
o
)

i
R
e
q
u
i
r
e

U
s
e
c
a
s
e

D
e
s
i
g
n
s

P
r
o
t
t
i
p
o

Aplicao Desenvolvida X X X
Planejado para Dispositivo Mvel X X X X
Permite manter Projetos X X
Permite registrar Texto X X X
Permite registrar Imagem X X X
Permite registrar udio X X
Permite registrar Requisitos X
Permite Integrao/Exportao X X X
Permite Rastreabilidade da Informao X
Total 4 5 4 9

No comparativo realizado no Quadro 4, pode verificar que as ferramentas, embora
semelhantes, abordam funcionalidades diferentes, como o caso do Usecase Diagrams que focado
no desenvolvimento de diagramas de casos de uso e o iRequire focado na coleta da informao.
Com a verificao de necessidades e deficincias de ferramentas e trabalhos correlatos,
apresentada na seo seguinte o desenvolvimento da aplicao. No desenvolvimento pretende-se
atender diversos como: a diviso das informaes em projetos, possibilitar a exportao das
informaes para outras ferramentas e a rastreabilidade dos requisitos e informaes coletadas.

38

3 DESENVOLVIMENTO
Nesta seo sero apresentados tpicos referentes especificao da ferramenta proposta,
demonstrando requisitos identificados, estruturas definidas e abordando o processo de
desenvolvimento.
A soluo proposta consiste em disponibilizar a um analista de software atravs de
perifricos presentes em dispositivos mveis, funcionalidades para apoiar a coleta e registro de
informaes relevantes ao processo de levantamento de requisitos de software.
Alm disso, deve possibilitar o gerenciamento de diversos projetos e a definio de vrios
artefatos para cada projeto. Ao gerenciar um artefato de software, permitir o acesso aos perifricos
como cmera e teclado, registrando de diversas formas as informaes obtidas.
3.1 FLUXO GERAL DA APLICAO
Para realizar o desenvolvimento do aplicativo, foi necessrio entender o processo de
levantamento de requisitos e ento definir um processo simplificado, j que dispositivos mveis
necessitam de simplicidade na utilizao.
Na aplicao utilizado o conceito de artefato de software como um conjunto de
informaes relacionadas, este conjunto poder ser definido pelo engenheiro de requisitos de acordo
com sua necessidade, baseando-se pela forma de coleta, local ou perodo.
As informaes contidas no conjunto artefato, considerada pela aplicao como fragmento.
A Figura 13 procura representar, de forma geral, o funcionamento da ferramenta e o relacionamento
com os recursos disponveis.

39

Figura 13 Diagrama de Atividades

O funcionamento do aplicativo inicia-se pelo processo de seleo do projeto de trabalho,
seguido ento pela seleo dos artefatos em questo, que podem ser, por exemplo, quaisquer das
formas de levantamento de requisitos, como: reunies com o cliente, etnografia ou uma entrevista
ao usurio.
Aps a definio de um artefato, o usurio poder realizar a criao dos fragmentos deste
artefato, ou seja, registrar as informaes coletadas. As informaes podero ser registradas como
act Processo Geral
Inci o
Selecionar Proj eto
Sel eci onar Artefato?
Carregar Artefatos
Selecionar Artefato
Sel eci onou?
Carrega o Painel de
Fragmentos
Conectado a Internet?
Exi ste fragmento no si ncroni zado?
Sincronizar contedo do
fragmento
Novo Fragmento?
Selecionar o Tipo do
Fragmento
Fi m
Armazenar Imagem
Sel eci onou Fragmento?
Armazenar udio
Abrir Detalhes do
Fragmento
Gerenci ar Requi si tos?
Carregar Requisitos
Novo Requi si to?
Armazenar Requisito
Fragmento Imagem?
Fragmento udi o?
Fragmento Texto?
Armazenar Texto
Exportar Proj eto
Compor Email
Exportar Proj eto?
[No]
[Si m]
[Si m]
[Si m]
[Si m]
[No]
[No]
[Si m]
[No]
[Si m]
[Si m]
[Si m]
[No]
[Si m]
[No]
[Si m]
[No]
[No]
[No]
[Si m]
[No]
[Si m]
[No]
[No]
40

imagens, a partir do lbum de fotos do aparelho ou da cmera, podem ser pequenas notas de texto
ou gravao de udio.
Com o conjunto de fragmentos do artefato definido, o usurio poder vincular requisitos
registrando informaes bsicas de definio tipo, a sua prioridade e complexidade.
3.2 ATORES, REGRAS DE NEGCIO E REQUISITOS.
O Quadro 5 demonstra os atores representados nas especificaes e uma breve descrio de
cada um.
Quadro 5 Atores da Especificao
Ator Descrio
Usurio Profissional da Tecnologia da Informao responsvel pela utilizao do
aplicativo. Ex: analista de negcio, engenheiro de software.
Servidor Servio de terceiro responsvel pelo armazenamento remoto de parte das
informaes.

Atravs destes atores definidos, so apresentados a seguir os requisitos de software e casos
de usos. Com base nestas especificaes foi realizado o desenvolvimento do aplicativo proposto.
3.2.1 Regras de Negcio
Para determinar conformidade e restries da aplicao, servindo como base para os
requisitos funcionais, so determinadas e apresentadas as regras de negcio no Quadro 6:
Quadro 6 Regras de Negcios
Identificador Descrio
RN 01 Dados para armazenamento de Artefato.
Cdigo, data de registro, e projeto e fragmentos.
RN 02 Dados para armazenamento de Requisitos.
Cdigo, tipo, nvel de prioridade, complexidade, data de criao,
nome e definio.
RN 03 Formato de exportao do projeto:
41

Deve ser disponibilizada a exportao das informaes coletadas do
projeto em documento XML no padro XMI.
RN 04 Composio dos fragmentos de um artefato:
Composto por uma imagem, registro de udio ou uma nota de texto.
RN 05 Origem de um fragmento de imagem:
Pode ser originado do contedo existente no dispositivo (lbuns de
fotos) ou ser capturada no momento do cadastro.
RN 06 Dados especficos do fragmento de Texto.
Contedo.
RN 07 Dados do Projeto
Nome, data de cadastro, detalhes e artefatos.
RN 08 Dados genricos de um Fragmento
Nome, data de cadastro, identificador do servio de sincronizao,
link de acesso online, tipo, artefato e requisitos.
RN 09 Um projeto deve conter pelo menos 1 artefato para possibilitar a exportao.
RN 10 Um artefato deve conter pelo menos 1 fragmento para ser considerado na
exportao.
RN 11 Apenas fragmentos sincronizados devem ser exportados.
RN 12 A sincronizao com o servio BaaS deve limitar-se a uma requisio por
fragmento.
RN 13 O estado inicial do requisito, ao ser exportado para outra ferramenta, deve ser
Proposto.
RN 14 As instrues de utilizao da aplicao devem ser simplificadas.
3.2.2 Requisitos No Funcionais
No Quadro 7, so apresentados os requisitos no funcionais definidos para o aplicativo.
Quadro 7 Requisitos No-Funcionais
Identificador Descrio
RNF 01 No dispositivo, as informaes devem ser armazenadas em SQLLite,
42

manipulados atravs da framework Core Data.
RNF 02 O aplicativo deve ser desenvolvido apenas para o tablet iPad.
RNF 03 O aplicativo deve ser desenvolvido com a ferramenta Xcode, em sistema
operacional Mac OS X.
RNF 04 O aplicativo deve registrar o udio, sem interferir na utilizao do restante do
aplicativo.
RNF 05 O aplicativo deve ser otimizado para iOS 7.
RNF 06 O aplicativo deve atender aos padres de Interface da Apple.
RNF 07 O aplicativo deve suportar as orientaes vertical e horizontal.
3.2.3 Requisitos Funcionais
No Quadro 8 so representados os requisitos funcionais identificados para o aplicativo
proposto.
Quadro 8 Requisitos Funcionais
Identificador Descrio Relacionamentos
RF 01 O sistema deve permitir o registro de artefatos. RN 01; RN 04;
RF 02 O sistema deve permitir o registro de requisitos. RN 02;
RF 03 O sistema deve prover uma consulta de todos os artefatos
registrados.
RN 01; RN 12;
RF 04 O sistema deve prover uma consulta de todos os
requisitos definidos.
RN 02;
RF 05 O sistema deve prover acesso aos dados em formato
XMI, para importao na ferramenta Enterprise
Architect.
RN 03; RN 09;
RN 10; RN 13;
RF 06 O sistema deve sincronizar automaticamente as
informaes aps o cadastro de um fragmento.
RN 09; RN 10;
RN 13;
RF 07 O sistema deve possibilitar o cadastro de projetos. RN 07;
RF 08 O sistema deve possibilitar a seleo do projeto
gerenciado.
RN 07;
43

RF 09 O sistema deve permitir a seleo do artefato gerenciado. RN 01;
RF 10 O sistema deve permitir a visualizao de informaes do
fragmento aps o cadastro.
RN 08;
RF 11 O sistema deve permitir a sincronizao dos dados do
fragmento manualmente.
RN 11; RN 12;
RN 13;
RF 12 O sistema deve permitir a visualizao do contedo do
fragmento armazenado remotamente, caso j
sincronizado.
RN 08;
RF 13 O sistema deve permitir relacionar requisitos existentes a
um ou mais fragmentos.
RN 02;
RF 14 O sistema deve exibir instrues das funcionalidades
bsicas ao usurio no momento que for aberto.
RN 15;
RF 15 O sistema deve sinalizar fragmentos no sincronizados. RN 12; RN 13;
3.3 CASOS DE USO
De forma geral, representado na Figura 14 o diagrama de casos de uso, contendo os
usurios relacionados, casos de usos e suas relaes.

44

Figura 14 Diagrama de Casos de Uso


Para o prottipo proposto, foram definidas funcionalidades de forma que possibilite ao
usurio uma experincia completa com mais de um projeto, podendo verificar separadamente suas
necessidades e sua estrutura. O Quadro 9 descreve o caso de uso referente a definio de projetos.
Quadro 9 UC 01 Manter Projeto
UC-01 Manter Projeto
Rastreabilidade RN07; RF 07; RF 08;
Atores Usurio
Descrio O Usurio realiza o cadastro de novos projetos de acordo com suas
necessidades, de forma que mantenha distino entre projetos e
organizao das informaes.
Pr-Condies
Ps-Condies Projeto definido.
Fluxo Principal 1. O usurio acessa a consulta de projetos.
2. O sistema apresenta os projetos cadastrados.
3. O usurio seleciona a opo de adicionar novo projeto.
5. O sistema solicita o nome do projeto.
6. O usurio informa o nome do projeto.
7. O sistema verifica se o nome j existe.
8. O sistema armazena o projeto.
Fluxo Alternativo 3.a O usurio seleciona a opo detalhes de um projeto j cadastrado.
45

3.a.1 O sistema exibe informaes do projeto selecionado.
3.a.2 O usurio altera o nome do projeto.
3.a.3 O sistema retorna ao passo 4 do Fluxo Principal.
3.b O usurio realiza o gesto Swipe sobre a linha do projeto.
3.b.1 O sistema exibe a opo Remover Projeto.
3.b.2 O usurio seleciona a opo Remover Projeto.
3.b.3 O sistema solicita ao usurio confirmao para excluso.
3.b.4 O usurio confirma excluso.
3.b.5 O sistema remove o projeto.
Fluxo de Exceo 7.a O nome do projeto j existe
7.a.1 O sistema exibe o alerta ao usurio: J existe um projeto
cadastrado com este nome.
Com a definio do projeto, para melhor compreenso, entendimento e rastreabilidade, o
sistema permite definir um artefato para cada novo contato ou momento de coleta de informaes
com o stakeholder do projeto. Desta forma, podem ser definidos diversos artefatos de acordo com o
UC 02 apresentando no Quadro 10.

Quadro 10 UC 02 Manter Artefato
UC-02 Manter Artefato
Rastreabilidade RN 01; RN 04; RN 12; RF 01; RF 03; RF 09;
Atores Usurio
Descrio O Usurio, ao definir uma nova forma de coleta de informaes registra o
Artefato.
Pr-Condies Comunicao com o cliente.
Deve existir pelo menos um projeto cadastrado.
Ps-Condies Documentao das informaes coletadas.
Fluxo Principal 1. O usurio seleciona um Projeto.
2. O sistema apresenta a lista de artefatos j cadastrados para o projeto
selecionado.
3. O usurio seleciona a opo novo artefato.
4. O sistema solicita o nome do artefato.
5. O usurio informa um nome para o artefato.
6. O sistema verifica se o nome j existe.
7. O sistema armazena o artefato.
8. O sistema atualiza a listagem de artefatos cadastrados.
9. O sistema define o artefato recm criado como selecionado.
10. O sistema apresenta ao usurio um painel para que sejam gerenciados
os fragmentos de informaes deste artefato.
Fluxo Alternativo 3.a O usurio seleciona a opo detalhes do artefato.
3.a.1 O sistema exibe informaes do artefato.
3.a.2 O usurio altera o nome do artefato.
3.b O usurio realiza o gesto Swipe sobre a linha do artefato.
46

3.b.1 O sistema exibe a opo Remover.
3.b.2 O usurio seleciona a opo Remover.
3.b.5 O sistema remove o artefato.
Fluxo de Exceo 6.a O nome do artefato j existe para este projeto.
6.a.1 O sistema exibe o alerta ao usurio: J existe um artefato
cadastrado com este nome neste projeto.

A definio de um novo requisito de software baseada em uma necessidade encontrada,
so atribudas neste momento as especificaes deste requisito. Seu cenrio definido no Quadro
11.
Quadro 11 UC 03 Manter Requisito
UC-03 Manter Requisito
Rastreabilidade RN 02; RF 02; RF 04; RF 14;
Atores Usurio
Descrio O usurio realiza a definio de um novo requisito de software, vinculado
a um ou mais fragmentos de artefato.
Pr-Condies Devem existir fragmentos de artefatos cadastrados.
Ps-Condies Um requisito de software definido.
Fluxo Principal 1. O usurio seleciona o projeto.
2. O sistema apresenta a lista de artefatos do projeto.
3. O usurio seleciona o artefato do projeto.
4. O sistema apresenta a lista de fragmentos do artefato.
5. O usurio seleciona o fragmento de artefato.
6. O sistema apresenta os detalhes do fragmento.
7. O usurio seleciona a aba de Requisitos do fragmento.
8. O sistema apresenta os requisitos j cadastrado para este fragmento.
9. O usurio seleciona a opo Novo requisito.
10. O usurio define o detalhamento e especificaes do requisito.
11. O sistema verifica os dados informados.
12. O sistema armazena e relaciona o requisito.
13. O sistema atualiza a lista de requisitos do fragmento selecionado.
Fluxo Alternativo 9.a O usurio seleciona a opo Adicionar Existente.
9.a.1 O sistema apresenta a lista de requisitos do artefato selecionado,
agrupado por fragmentos.
9.a.2 O usurio seleciona um requisito.
9.b O usurio realiza o gesto Swipe sobre a linha do requisito.
9.b.5 O sistema remove o requisito.
47

9.c O usurio seleciona um requisito.
9.c.1 O sistema apresenta o detalhamento do requisito.
9.c.2 O usurio realiza alteraes no requisito.
9.c.3 O sistema retorna ao passo 12 do Fluxo Principal.
Fluxo de Exceo 11.a O usurio informou um identificador duplicado.
11.a.1 O sistema exibe o alerta ao usurio: J existe um requisito
cadastrado com este identificador.
11.b O usurio no informou o identificador.
11.b.1 O sistema exibe o alerta ao usurio: O identificador do requisito
obrigatrio.
11.c O usurio no informou a definio do requisito.
11.c.1 O sistema exibe o alerta ao usurio: A definio do requisito
obrigatria.
Com base nas informaes coletadas no momento da definio dos fragmentos do artefato,
diversas formas de fragmentos podero ser coletados, sendo ento definidos fragmentos de Imagem,
udio, ou fragmentos de texto. O detalhamento deste caso de uso definido no Quadro 12.
Quadro 12 UC 04 Manter Fragmentos de Artefato
UC-04 Manter Fragmentos de Artefato
Rastreabilidade RN 05; RN06; RN 08; RN 09; RN 10; RN 13; RF 06; RF 09;
Atores Usurio
Descrio Atravs das interfaces do dispositivo o usurio registra as informaes
relevantes ao projeto em diversos tipos de fragmentos.
Pr-Condies Deve existir pelo menos um artefato criado.
Ps-Condies criado um novo fragmento de informao do artefato.
Fluxo Principal 1. O usurio seleciona o projeto.
2. O sistema apresenta os artefatos do projeto selecionado.
3. O usurio seleciona o artefato necessrio.
4. O sistema apresenta os fragmentos j cadastrados para este artefato.
5. O usurio seleciona a opo de novo fragmento.
6. O sistema apresenta a listagem com os tipos de fragmentos disponveis.
7. O usurio selecionou o tipo de fragmento de Texto.
8. UC08 Definir fragmento: Texto. <<Extend>>
9. O sistema atualiza a lista de fragmentos do artefato.
10. UC 09 Sincronizao BaaS. <<Include>>
Fluxo Alternativo 7.b O usurio selecionou o tipo de fragmento de Imagem.
7.b.1 UC06 Definir fragmento: Imagem. <<Extend>>
7.b.2 O sistema retorna ao passo 9 do Fluxo Principal.
7.c O usurio selecionou o tipo de fragmento de udio.
7.c.1 UC07 Definir fragmento: udio. <<Extend>>
7.c.2 O sistema retorna ao passo 9 do Fluxo Principal.
5.b O usurio realiza o gesto Swipe sobre a linha do fragmento.
48

5.b.5 O sistema remove o fragmento.
A definio de contedo do artefato pode ser definida por diversos fragmentos, assim como
o fragmento de imagem, que atravs de funcionalidades do dispositivo possvel coletar e
armazenar uma imagem. Este processo definido detalhadamente no Quadro 13.
Quadro 13 UC 05 Definir Fragmento: Imagem
UC-05 Definir fragmento: Imagem
Rastreabilidade RN 04; RN 05; RN 08; RN 11; RN 12; RF 15;
Atores Usurio
Descrio O Usurio atravs de funcionalidades do dispositivo, define imagens
como um fragmento do contedo de um artefato.
Pr-Condies O artefato deve estar criado.
Ps-Condies definida uma nova imagem como fragmento do artefato.
Fluxo Principal 1. O sistema verifica as formas de captura de imagens que esto
disponveis.
2. O sistema verifica as formas de seleo de imagens disponveis.
3. O sistema apresenta as formas de seleo de imagens disponveis.
4. O usurio seleciona a captura atravs da cmera.
5. O usurio seleciona a imagem.
6. O sistema apresenta ao usurio a imagem selecionada.
7. O usurio confirma a imagem selecionada.
8. O sistema armazena o novo fragmento.
Fluxo Alternativo 2.a O dispositivo no possui a cmera disponvel.
2.a.1 O sistema apresenta ao usurio a seleo de imagens a partir do
lbum.
2.a.2 O sistema retorna para o passo 5 do Fluxo Principal.
4.a O usurio seleciona a captura atravs do lbum do dispositivo.
4.a.1 O sistema apresenta ao usurio a seleo de imagens a partir do
lbum.
Fluxo de Exceo 2.a O sistema solicita ao dispositivo acesso a cmera.
2.a.1 O usurio no disponibilizou a cmera.
2.a.2 O sistema fecha a definio do fragmento, nenhum fragmento
criado.
2.b O sistema solicita ao dispositivo acesso ao lbum.
2.b.1 O usurio no disponibilizou acesso ao lbum.
2.b.2 O sistema fecha a definio do fragmento, nenhum fragmento
criado.
Das muitas formas de levantamento de informaes, a entrevista pode ser considerada uma
das mais eficientes. Para este processo, o fragmento de Som pode ser utilizado, armazenando assim
49

as respostas do conhecedor da regra, e do analista. O processo de registro de fragmentos de udio
especificado no Quadro 14.
Quadro 14 UC 06 Definir Fragmento: udio
UC-06 Definir fragmento: udio
Rastreabilidade RN 04; RN 08; RN 11; RN 12; RF 15;
Atores Usurio
Descrio O Usurio, atravs de funcionalidades do dispositivo armazena o som do
ambiente para integrar ao artefato.
Ps-Condies O som do ambiente armazenado junto ao artefato.
Fluxo Principal 1. O sistema verifica se o sistema operacional disponibiliza o microfone
para o sistema.
2. O sistema inicia o registro de udio.
3. O usurio finaliza o registro de udio.
4. O sistema possibilita ao usurio a reproduo do udio.
5. O usurio confirma o udio registrado.
6. O sistema armazena o novo fragmento.
Fluxo Alternativo 1.a O sistema operacional no permisso para liberar o microfone ao
sistema.
1.a.1 O sistema operacional solicita ao usurio permisso para
disponibilizar o microfone do dispositivo.
1.a.2 O usurio disponibiliza o microfone.
No Quadro 15 especificado o caso de uso Definir fragmento: Texto na qual aborda a
definio de informaes ao artefato no formato de fragmentos de texto.
Quadro 15 UC 07 Definir Fragmento: Texto
UC-07 Definir fragmento: Texto
Rastreabilidade RN 04; RN 06; RN 08; RN 11; RN 12; RF 15;
Atores Usurio
Descrio O Usurio atravs de funcionalidades do dispositivo, define um trecho de
texto como contedo do fragmento de um artefato.
Ps-Condies definida um novo fragmento de texto ao artefato.
Fluxo Principal 1. O sistema apresenta para o usurio as informaes necessrias para
realizar o armazenamento.
2. O usurio informa o identificador do fragmento.
3. O usurio informa o definio do fragmento.
4. O usurio confirma a finalizao.
5. O sistema valida os dados do fragmento.
6. O sistema armazena o fragmento.
Fluxo
Alternativo
5.a O usurio no informou o identificador do fragmento.
5.a.1 O sistema exibe a mensagem: O identificador do fragmento deve
ser preenchido..
50

5.b O usurio no informou a definio do fragmento.
5.b.1 O sistema exibe a mensagem: A definio do fragmento deve ser
preenchida..
5.b.2 O sistema retorna para o passo 2 do Fluxo Principal.
Com informaes definidas no projeto, fica disponvel ao usurio, caso necessrio, a
exportao de todas as informaes do projeto para outra ferramenta atravs de um formato padro.
Detalhes no Quadro 16.
Quadro 16 UC 08 Exportar Projeto
UC-08 Exportar Projeto
Rastreabilidade RN 03; RN 09; RN 10; RN 12; RF 05;
Atores Usurio
Descrio O usurio exporta as informaes de um projeto no formato XMI para
que seja importado em ferramentas CASE.
Pr-Condies O projeto deve estar criado.
O projeto deve conter artefatos.
O artefato deve conter fragmentos.
O dispositivo deve estar conectado a internet.
Uma conta de e-mail deve estar configurada no dispositivo.
Ps-Condies disponibilizado ao usurio a possibilidade de enviar o arquivo de
importao por e-mail.
Fluxo Principal 1. O usurio seleciona o projeto desejado.
2. O sistema apresenta junto a listagem de artefatos a opo Exportar
projeto.
3. O usurio seleciona a opo Exportar Projeto.
4. O sistema processa as informaes disponveis.
5. O sistema apresenta ao usurio a composio do e-mail.
6. O usurio informa o e-mail de destino.
7. O sistema envia o e-mail com o documento XMI em anexo.
Fluxo Alternativo 4.a No existem artefatos criados para o projeto selecionado.
4.a.1 O sistema apresenta a mensagem: No existem informaes
suficientes para realizar a exportao.
4.b No existem fragmentos criados para nenhum artefato contido no
projeto selecionado.
4.b.1 O sistema apresenta a mensagem: No existem informaes
suficientes para realizar a exportao.
Fluxo de Exceo 6.a O usurio cancela o envio.
6.b O sistema retorna a lista de artefatos.
7.a O sistema no consegue enviar o e-mail.
7.b O sistema mantm o e-mail na caixa de sada do aplicativo de e-mails.
7.c O sistema retorna a lista de artefatos.
51

Por fim, todo fragmento de artefato pode ser sincronizado com o servio BaaS, ou seja, suas
informaes estaro disponveis para o usurio em um servidor WEB. Tal funcionalidade se faz
necessria para que o contedo do fragmento seja visualizado a partir de ferramentas CASE, como
o Enterprise Architect. O detalhamento do caso de uso, que se repetir para cada fragmento pode ser
verificado no Quadro 17.
Quadro 17 UC 09 Sincronizao BaaS
UC-09 Sincronizao BaaS
Rastreabilidade RN 11; RN12; RN 13; RF 11; RF 15;
Atores Usurio
Descrio O sistema, com base nos fragmentos de artefatos criados, realiza o envio
do contedo do fragmento para um servio remoto de computao em
nuvem.
Pr-Condies Devem existir fragmentos criados.
O fragmento no pode ter sido sincronizado.
Ps-Condies O contedo do fragmento est armazenado no servidor remoto.
Fluxo Principal 1. O sistema, ao carregar os fragmentos do artefato verifica se o mesmo j
est sincronizado.
2. O sistema envia ao servidor o arquivo do fragmento.
3. O servidor retorna ao sistema o link de acesso para o arquivo.
4. O sistema atualiza o link externo do fragmento enviado.
5. O sistema oculta o identificador de necessidade de sincronizao.
Fluxo Alternativo -
Fluxo de Exceo 1.a O fragmento j foi sincronizado anteriormente.
1.a.1 O sistema desconsidera o fragmento na sincronizao.
2.a O dispositivo no est conectado internet.
2.a.1 O sistema cancela a sincronizao.
2.b O servidor remoto no est disponvel.
2.b.2 O sistema cancela a sincronizao.
3.4 MODELO DE DADOS
O modelo de dados representado nesta sesso no pode ser considerado como um modelo de
entidades e relacionamentos. Este modelo definido atravs da ferramenta de desenvolvimento, a
partir dele que a ferramenta realiza a criao dos modelos de dados e mapeamentos para o banco de
dados SQLLite. No modelo (Figura 15) so representadas todas as entidades, seus atributos e
relacionamentos.

52

Figura 15 Modelo de Dados

O modelo de dados acima apresentado desenvolvido diretamente pela ferramenta Data
Modeler, integrada ao Xcode. A ferramenta disponibiliza uma interface para o desenvolvimento do
modelo, que criar junto a ele as configuraes de banco de dados e suas respectivas classes.
Aps a criao do modelo e execuo do projeto, criado automaticamente o banco de
dados fsico no dispositivo. O banco de dados criado e manipulado totalmente atravs da
Framework Core Data. Na Figura 16 apresentado o diagrama das entidades utilizado no
dispositivo.
53

Figura 16 Estrutura de Dados Resultante

No diagrama pode ser visto que existem atributos, ndices e entidades que so criadas
automaticamente para controle da framework, que por sua vez no utiliza a definio de
relacionamentos entre entidades diretamente, mas sim em sua estrutura interna na entidade
Z_METADATA.
Neste modelo so representadas as entidades de Projetos, Artefatos e Fragmentos. Para cada
tipo de fragmento definido, so definidas entidades para armazenar suas particularidades, j os
atributos em comum das entidades so definidos na entidade abstrata Fragmento, da qual todos os
fragmentos herdam.
Percebe-se que os identificadores de entidades so abstrados pela ferramenta, sendo que
seus relacionamentos so controlados automaticamente pela Framework de persistncia.
54

O modelo de dados para o dispositivo prev o armazenamento e a utilizao para diversos
projetos. Cada projeto pode ser definido por um identificador (nome), registrando sua data de
cadastro e demais detalhes para uma viso simplificada do que se trata o projeto.
Todo projeto contar com um conjunto de artefatos, que por sua vez ser definido pelo seu
nome, tipo e posio no painel. O artefato possuir um relacionamento com outras entidades de
acordo com seu tipo, podendo se relacionar com a entidade FragmentoTexto, com a entidade
FragmentoImagem ou com a entidade FragmentoAudio.
Aps a definio de Fragmentos, definida a entidade de registro de requisitos de cada
fragmento, possibilitando armazenar nome, definio, tipo, complexidade, e prioridade.
Como o Core Data uma framework generalizada e automatizada para persistncia de
dados, permite que sua estrutura seja definida atravs do Data Modeler do Xcode e, aps isto, sejam
criados suas classes de modelo de dados (conforme Figura 17), assemelhando-se assim a um ORM
5

ou at mesmo um banco de dados orientado a objetos.
Figura 17 Estrutura do Projeto: Base de Dados

Considerando que esta estrutura de dados pode sofrer alteraes a qualquer momento, a
definio de caractersticas e funcionalidades adicionais deve ser feita atravs da definio de uma
Category
6
para a classe. Desta forma, estas definies no so perdidas em uma possvel alterao
de estrutura de dados. Maiores detalhes quanto ao relacionamento dos modelos de dados so
abordados na seo a seguir, implementao.

5
ORM (Object-relational Mapping) uma metodologia de desenvolvimento que representa a estrutura relacional de
dados atravs de classes.
6
Category uma maneira de separar uma nica classe em diversos arquivos. O objetivo disto facilitar a manuteno
modularizando a classe (APPLE INC, 2013).

55

3.5 IMPLEMENTAO
Nesta seo ser abordada a implementao do prottipo do aplicativo, descrevendo o
ambiente necessrio, as restries encontradas, tecnologias e prticas adotadas para tal. Ser
realizado um detalhamento tcnico apenas nas funcionalidades mais importantes, tais como
sincronizao com o servidor e gerao do arquivo de exportao XMI para ferramentas CASE.
3.5.1 Ambiente de Desenvolvimento
Para realizar o desenvolvimento de aplicaes para dispositivos com o sistema operacional
iOS, foi utilizada a ferramenta Xcode IDE (Figura 18). Esta dispe ao desenvolvedor um pacote de
ferramentas necessrias para realizar a implementao visual, integrao com a lgica da aplicao
e realizao de testes de desempenho (APPLE, 2013).
Figura 18 Xcode: Viso Geral

Fonte: Apple (2013)
Atravs do Xcode IDE, um desenvolvedor devidamente registrado no programa de
desenvolvedores iOS da Apple poder realizar testes diretamente no dispositivo, acessar toda
documentao das frameworks disponibilizadas e realizar o gerenciamento de certificados,
aplicativos e perfis (Figura 19). Caso o desenvolvedor no seja registrado no programa Apple de
56

desenvolvedores, o mesmo poder ter restries como, por exemplo, na realizao de testes
diretamente no dispositivo ou na publicao de seu aplicativo na Apple App Store (APPLE, 2013).
Figura 19 Representao das Integraes do Xcode

Fonte: Apple (2013)
A Xcode IDE gratuita para instalao e atualizao, mas possui como pr-requisito a
instalao em sistema operacional Mac verso 10.7 (Mac OS X Lion) ou superior. O
desenvolvimento para sistema operacional Mac tambm feito atravs da Xcode IDE.
A ferramenta tambm disponibiliza integrao com ferramentas para controle de verso. No
decorrer do desenvolvimento foi utilizado o servio de dPaaS
7
, atravs da plataforma CloudForge
(COLLABNET, 2013).
3.5.2 Desenvolvimento da Aplicao
O desenvolvimento do aplicativo foi dividido em trs etapas, assim como eventualmente
adotado pela indstria de desenvolvimento de aplicativos mveis. Na primeira etapa foram
desenvolvidos os modelos de interface, definidas funcionalidades visuais e iterao com o usurio.
Em um segundo momento foi realizada a estruturao dos modelos de dados, exigidos para a
persistncia de dados da aplicao, conhecidos como subclasses da NSManagedObject
8
. Aps os
modelos de dados, foram desenvolvidas as regras para os controladores.

7
dPaaS (Development Plataform as a Service) o nome dado ao servio que disponibiliza para desenvolvedores toda
plataforma necessria para o desenvolvimento e implantao de software (COLLABNET, 2013).
8
NSManagedObject uma classe genrica que implementa todos os mtodos bsicos requeridos para um modelo da
framework Core Data (APPLE INC, 2013).
57

Na primeira etapa de desenvolvimento do aplicativo foram verificados os componentes
disponveis. O principal foco quanto interface era que a mesma fosse intuitiva e otimizada para a
verso do iOS 7. A verso 7 do iOS trouxe grandes desafios e mudanas: novo padro de
usabilidade, nova forma de navegao e animaes. Com isto, optou-se em utilizar os componentes
padres da Framework Cocoa Touch, j que os mesmos dispem de diversas funcionalidades pr-
definidas.
Com a definio de componentes a serem utilizados, foram definidas as telas no Interface
Builder, montando inicialmente a estrutura base da aplicao: menu, consulta base e detalhamento.
Pode ser verificado na
Figura 20 em destaque os itens base, que foram utilizados como referncia para estruturao
de toda aplicao.
Figura 20 Componentes da Estrutura da Aplicao

Aps a definio dos componentes principais, que so a estrutura da aplicao, foram
definidas as interfaces restantes, detalhando a definio de cada tipo de fragmento, as interfaces de
visualizao e algumas interfaces simples, como: bales de exportao, seleo de tipos dos
requisitos e a interface de auxlio no incio da aplicao.
58

Para a criao dos modelos de dados, j na segunda etapa, foram desenvolvidos os
controladores de cada tela, os quais definem o funcionamento das listas e gerenciam as informaes
no armazenamento local atravs do Core Data.
Ao manipular as informaes com a Framework Core Data, no existe a necessidade de se
realizar a manipulao atravs de SQL. preciso manter na aplicao a referncia a trs
propriedades, para que seja possvel manipular todas as entidades definidas no modelo de dados.
Estas propriedades so definidas na instancia base do aplicativo, sendo que a classe
AppDelegate realiza todo o controle de iterao do aplicativo com o sistema operacional. Desta
forma, estar disponvel para toda a aplicao (Quadro 18).
Quadro 18 Definio da classe AppDelegate
#import <UIKit/UIKit.h>

@interface AppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

@property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
@property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel;
@property (readonly, strong, nonatomic) NSPersistentStoreCoordinator
*persistentStoreCoordinator;

- (void)saveContext;
- (NSURL *)applicationDocumentsDirectory;

@end
Ao definir uma propriedade na classe, existem alguns atributos que Objective-C permite que
sejam definidos, tais como: a forma de acesso propriedade, neste caso readonly (apenas
leitura); a forma que a aplicao manter o valor desta propriedade em memria, neste caso
strong (uma referncia forte); e o controle de integridade que a propriedade ter em caso de
mltiplas threads, neste caso nonatomic (sem controle).
As propriedades necessrias so responsveis pelo contexto da framework em qualquer local
da aplicao (NSManagedObjectContext), por manter a referncia ao modelo de dados que o
contexto se refere (NSManagedObjectModel), e tambm pela forma que este contexto ir
armazenar as informaes (NSPersistentStoreCoordinator).
Para exemplificar o armazenamento de informaes atravs do Core Data, apresentado no
Quadro 19 o armazenamento do fragmento de imagem.
Quadro 19 Core Data: Novo registro.

- (void) saveSelectedImage
{
FragmentoImagem * frag = (FragmentoImagem * ) [NSEntityDescription insertNewObject-
ForEntityForName:@"FragmentoImagem" inManagedObjectContext: self.managedObjectContext];
59

frag.data = [NSDate date];
frag.nome = @"Captura de Imagem";
frag.tipo = [NSNumber numberWithInt: 2 ];
frag.artefato = self.artefato;
frag.conteudo = UIImageJPEGRepresentation(self.imageVisualizacao.image, 1.0);
frag.sincronizadoParse = [NSNumber numberWithBool: NO];

NSError *error;
if (![self.managedObjectContext save:&error]) {
NSLog(@"No foi possvel armazenar o artefato imagem: %@", [error localizedDescrip-
tion]);
} else {
[frag sendFileContentsToParse];
}
}
Ento, para isto, instanciado um objeto da classe FragmentoImagem (subclasse da
NSManagedObject) utilizando o mtodo abstrato
insertNewObjectForEntityForName:inManagedObjectContext: da classe
NSEntityDescription, sendo que o objeto ser retornado para utilizao como qualquer outra
classe. O valor de suas propriedades podero ser alterados, mas no sero armazenados at o
momento que o contexto for salvo, o que ocorre logo aps, atravs do mtodo save: no contexto.
Neste caso, em que o NSPersistentStoreCoordinator foi configurado para que sua
persistncia seja do tipo NSSQLiteStoreType, ou seja utilizando o armazenamento baseado no
SQLite, as instrues SQL para realizar a manipulao das informaes sero criadas e executadas
apenas ao salvar o contexto.
Com a manipulao o modelo de dados criado e referenciado na aplicao, disponvel para
manipulao, iniciamos o terceiro passo, a criao dos controladores das interfaces. Neste passo
criada, para cada interface, uma classe que seja subclasse do tipo da interface. Por exemplo, o menu
do sistema uma interface do tipo UITableView. Ento, para controlar esta interface
precisamos de uma subclasse de UITableViewController, neste caso criamos a
MenuSistemaViewController. Desta forma, o Interface Builder disponibiliza a propriedade
Custom Class da interface (Figura 21).
60

Figura 21 Interface Builder: Propriedades da Interface

As vantagens da criao das classes desta forma que muitos mtodos necessrios para
iterao com a interface j vm definidos e implementados, poupando tempo e trabalho. A definio
das classes customizadas s interfaces implica na alocao em memria e instncia destes
controladores automaticamente, sendo iniciados de acordo com a sequncia definida no
Historyboard.
Figura 22 Relacionamentos de classes com Frameworks

61

Para exemplificar a estrutura de relacionamentos entre classe de controle e modelo da
aplicao com as classes nativas das frameworks UIKit e CoreData, apresentado o diagrama de
classes na Figura 22.
Na aplicao, a classe MenuViewController responsvel por controlar o menu de
projetos contidos no sistema, para a representao do menu utilizado o componente
UITableView. A framework UIKit disponibiliza ao desenvolvedor controles padres para
diversos componentes, neste caso, a classe MenuViewController ser herdada da classe
UITableViewController. Desta forma diversos mtodos para controle de gestos, rotao e
alterao de layout estaro desenvolvidos pela prpria UIKit.
Nos controladores da aplicao ainda existiro classes de modelos de dados, que sero
responsveis por disponibilizar informaes do banco de dados para a interface. Na classe
MenuViewController existe uma referncia para a classe de modelo Projeto, que define o
projeto selecionado. Assim como os outros modelos de dados, o modelo Projeto uma herana de
NSManagedObject da framework CoreData, responsvel por toda manipulao do banco de
dados.
Concluindo a criao de todas as classes controladoras para cada interface, iniciou a
definio da regra da aplicao para cada uma delas, como: apresentar informaes registradas,
realizar o registro de udio ou a seleo de imagens. A seguir sero apresentados alguns exemplos
de regras aplicados nos controles.
Para realizar a definio de um fragmento de udio foi necessrio, na implementao do
controlador FragmentoAudioViewController, utilizar algumas classes disponibilizadas
pela AVFoundation Framework, que responsvel manipulao de arquivos de udio. A utilizao
desta framework apresentada no Quadro 20.
Quadro 20 Registro de udio
[...]
AVAudioSession *session = [AVAudioSession sharedInstance];
[session setCategory:AVAudioSessionCategoryPlayAndRecord error:nil];
[session setActive:YES error:nil];

NSDictionary *recordSettings = [NSDictionary dictionaryWithObjectsAndKeys:
@(AVAudioQualityMax),AVEncoderAudioQualityKey,
@131072,AVEncoderBitRateKey, // 128kbps
@1,AVNumberOfChannelsKey, //
@8000,AVSampleRateKey, // 8Khz
@(kAudioFormatMPEG4AAC),AVFormatIDKey,
nil];
NSError *error = nil;
NSURL *soundFileURL = [NSURL fileURLWithPath:[self getTempFilePath]];
recorderInstance = [[AVAudioRecorder alloc] initWithURL: soundFileURL settings:recordSettings
error:&error];
if (error) {
62

NSLog(@"error: %@", [error localizedDescription]);
} else {
[recorderInstance prepareToRecord];
}

[...]
Para evitar que seja armazenado qualquer udio que esteja sendo reproduzido pelo
dispositivo, criada uma sesso para reproduo e gravao de udio. Atravs da classe
AVAudioSession garantido ao aplicativo que apenas ele estar reproduzindo ou registrando o
udio com base nas interfaces do dispositivo.
Aps a criao e ativao do controle de sesso, criada ento uma instncia da classe
AVAudioRecorder que ser preparada para iniciar o registro de udio. Ao instanciar a classe,
devem ser passadas algumas configuraes de codificao e o local que o mesmo ser armazenado.
Para isto utilizamos os parmetros bsicos para armazenamento de voz, que so
apresentados no Quadro 21.
Quadro 21 Parmetros de Configurao do registro de udio
Parmetro Valor Utilizado
Qualidade Mxima
Bitrate de Codificao 128 kbps
Canais 1
Frequncia 8 Khz
Formato MP4/AAC
A partir disso, atravs da instncia de AVAudioRecorder, pode-se iniciar o
armazenamento a qualquer momento atravs do mtodo record, ou finalizar a gravao atravs
do mtodo stop. Nesta classe ainda so disponibilizadas informaes como o status atual (se esta
gravando ou no) atravs do mtodo isRecording; e em quantos segundos est a gravao
atravs da propriedade currentTime.
J a captura de imagens no fragmento do tipo imagem, foi realizada atravs da classe
FragmentoImagemViewController, que utilizou a classe
UIImagePickerController. No trecho apresentado no quadro Quadro 22 feita a
verificao se o dispositivo possui uma cmera disponvel, atravs do mtodo
isSourceTypeAvailable: com o parmetro referente a cmera
UIImagePickerControllerSourceTypeCamera.

63

Quadro 22 Trecho da classe FragmentoImagemViewController
[...]

if ([UIImagePickerController isSourceTypeAvailable: UIImagePickerControllerSourceTypeCamera])
{
self.actionTipoImagem = [[UIActionSheet alloc] initWithTitle: @"De onde voc deseja
carregar uma nova imagem?" delegate:self cancelButtonTitle: @"Cancelar" destructiveButtonTi-
tle:nil otherButtonTitles:@"lbum",@"Cmera", nil];
[self.actionTipoImagem setTag:kActionOrigemImagem];
UIWindow* window = [[UIApplication sharedApplication] keyWindow];
if ([window.subviews containsObject:self.view]) {
[self.actionTipoImagem showInView:self.view];
} else {
[self.actionTipoImagem showInView:window];
}
} else {
[self callImagemAlbum];
}

[...]
Caso a cmera esteja disponvel para o aplicativo, criado um alerta para que o usurio
selecione qual a origem desejada da imagem. Atravs do componente UIActionSheet,
definido um ttulo, a mensagem de aviso e as opes: lbum e Cmera (Figura 23).
Figura 23 Componente UIActionSheet

No momento da criao do componente UIActionSheet, atravs do parmetro
delegate: definido que a classe FragmentoImagemViewController ser responsvel
por receber todas as notificaes quanto a aes realizadas pelo componente e, na classe controle,
deve ser definido que a mesma se adqua ao protocolo UIActionSheetDelegate (Quadro 23).
Desta forma, ao ser selecionada uma opo, a classe de controle ser notificada.
Quadro 23 Adequao ao Protocolo UIActionSheetDelegate
[...]

@interface FragmentoImagemViewController : UIViewController <UIActionSheetDelegate>

[...]
64

Um dos mtodos que o componente notificada classe de controle o
actionSheet:clickedButtonAtIndex: Desta forma, feita a verificao do item que foi
selecionado e exibido ao usurio o coletor da imagem.
Ao realizar a chamada do UIImagePickerController, deve ser definida a forma
que a imagem ser selecionada. Atravs do mtodo setSourceType:, definido se a imagem
ser coletada pela cmera (UIImagePickerControllerSourceTypeCamera) ou se ser
definida pela biblioteca (UIImagePickerControllerSourceTypePhotoLibrary).
Ainda para a seleo da imagem, deve ser definido que a classe de controle
FragmentoImagemViewController responder por alguns mtodos do
UIImagePickerController. Da mesma forma que o UIActionSheet, a classe de controle
deve ser adequada ao protocolo UIImagePickerControllerDelegate.
Quadro 24 Tratamento do retorno da seleo de imagem

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithIn-
fo:(NSDictionary *)info
{
[...]
self.imageVisualizacao.image = [info objectForKey: UIImagePickerControllerOriginalImage];
[...]
}

Quando o usurio realizar a seleo imagem, independente da origem, o mtodo
imagePickerController:didFinishiPickingMediaWithInfo: (Quadro 24)
implementado na classe FragmentoImagemViewController ser chamado, onde ento
exibir para o usurio a imagem selecionada, podendo ou no ser utilizada para definio do
fragmento.
Desta forma, so definidos os principais fragmentos que o artefato poder ser composto.
Na prxima seo ser abordada como foi realizada a sincronizao do contedo destes fragmentos,
de forma que os mesmos estejam disponveis para o usurio atravs de ferramentas CASE.
3.5.3 Sincronizao: Servios BaaS
Para que o contedo esteja disponvel para usurio quando necessrio, deve existir um
servidor para que receba as requisies e armazene o contedo. Este servidor poderia ser
desenvolvido utilizando tecnologias como JAVA ou PHP. Porm, o desenvolvimento deste servio
complexo, necessitando de controle de segurana, configurao de domnios, entre outros.
65

Para simplificar o processo, foi utilizado o servio gratuito do Parse (2013), que
disponibiliza armazenamento, processamento, notificaes, entre outros. Existem algumas
restries por ser gratuito, como um limite de 1.000.000 requisies e limite de armazenamento.
O primeiro passo para a integrao com o servio Parse foi cadastrar-se no site do servio,
juntamente com a primeira aplicao. Cada aplicao criada neste servio tratada separadamente.
Aps o cadastro da aplicao, devem ser definidas as classes e colunas que sero necessrias
para manter as informaes. Atravs do Dashboard (Figura 24) tem-se acesso definio dos
dados, anlise de uso e trfego gerado pelo aplicativo, alm de configuraes e outros servios
disponibilizados.
Figura 24 Parse: Dashboard.

Para o prottipo desenvolvido foi criado uma classe apenas, de forma que sejam
armazenados apenas os arquivos de contedo dos fragmentos. O contedo ser enviado para o
servidor remoto e no influenciar nas exportaes, reduzindo consideravelmente o tamanho do
arquivo de exportao para outras ferramentas.
O Parse disponibiliza algumas classes padres para agilizar o desenvolvimento do
aplicativo. Estas classes podem ser utilizadas para armazenar usurios, registrar instalaes ou
regras, possuindo um tratamento diferenciado e pr-definido na prpria API disponibilizada pelo
servio.
Foi adicionada apenas uma nova classe (Figura 25) chamada arquivo. Esta classe com
formato customizado no ter a definio de atributos em um formato pr-definido, podendo ser
adicionados novos atributos.

66

Figura 25 Parse: Criao de Classe

Aps a definio desta nova entidade, a mesma fica disponvel para seleo no menu
lateral, exibindo informaes necessrias e registros existentes na mesma. A entidade criada ir
realizar o armazenamento apenas de contedo, ou seja, armazenar os arquivos de Imagens, udio
e Texto coletados pelo usurio no aplicativo. Desta forma, criado nesta entidade apenas um
atributo chamado arquivo com o tipo File e de forma genrica poderemos realizar o envio de
qualquer arquivo ao servio (Figura 26).
Figura 26 Parse: Criao de Coluna

Definida a estrutura de dados no servio, necessrio realizar a configurao do projeto. O
servio disponibiliza em sua seo de downloads uma framework para cada tecnologia, facilitando a
integrao. Adicionando a framework ao projeto, todas as funcionalidades necessrias estaro
disponveis. O conjunto de frameworks necessrias apresentado na Figura 27.

67

Figura 27 Parse: Frameworks Necessrias

O Parse disponibiliza, nas configuraes do aplicativo, um painel (Figura 28) contendo
diversas chaves da aplicao. Atravs desta chave o servio e o aplicativo se comunicam de forma
segura, garantindo a origem das informaes no servidor. Caso existam tecnologias simultneas
acessando as informaes no servidor, cada tecnologia utilizar sua chave.
Figura 28 Parse: Chaves da Aplicao

No dispositivo, aps iniciar o aplicativo, a API deve ser registrada, desta forma as
sincronizaes realizadas sero aceitas pelo servidor. As configuraes do parse so definidas no
mtodo application:didFinishLaunchingWithOptions: (Quadro 25) da classe
AppDelegate, sendo que este mtodo invocado aps finalizar a abertura do aplicativo.
Quadro 25 Definio do Parse no Aplicativo

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary
*)launchOptions
{
68

[...]
[Parse setApplicationId:@"[CODIGO_APLICATIVO]"
clientKey:@"[CODIGO_CLIENTE]"];

[PFAnalytics trackAppOpenedWithLaunchOptions:launchOptions];
return YES;
}

Com a API registrada para o aplicativo que foi criado no site, pode ser feito o envio do
contedo ao servidor. De acordo com o modelo de dados definido e abordado na seo 3.4, todos os
tipos de fragmentos sero subclasses da classe Fragmento. Desta forma, todas as definies em
comum para os tipos de fragmento podem ser definidas nesta classe abstrata, assim foi
implementado o processo de sincronizao na classe Fragmento.
Como a classe fragmento uma subclasse da NSManagedObject, ou seja, uma classe
utilizada pelo Core Data para persistncia de dados e uma classe gerada pelo Xcode IDE, no
pode ser feita nenhuma alterao na mesma. Para adicionar novas funcionalidades a ela deve-se
utilizar a Category chamada Fragmento+ParseControls, em destaque no Quadro 26.
Quadro 26 Implementao da Category: Fragmento+ParseControls
#import "Fragmento+ParseControls.h"
#import "FragmentoAudio.h"
#import "FragmentoImagem.h"
#import "FragmentoTexto.h"
#import "AudioManager.h"
#import <Parse/Parse.h>

@implementation Fragmento (ParseControls)

- (void)sendFileContentsToParse
{
// criamos a classe "arquivo" presente no servidor
PFObject * arquivo = [PFObject objectWithClassName:@"arquivo"];
// adicionamos o contedo do fragmento na coluna "arquivo"
[arquivo setObject: [self getContentsAsParseFile] forKey: @"arquivo"];
// enviamos para o servidor
[arquivo saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) {
if (succeeded && !error) {

PFFile * arquivoSalvo = [arquivo objectForKey:@"arquivo"];

[self setSincronizadoParse: [NSNumber numberWithBool: succeeded] ];
[self setLinkParse: arquivoSalvo.url];
[self setIdParse: arquivo.objectId ];

[self.managedObjectContext save:&error];

if (!error) {
[[NSNotificationCenter defaultCenter] postNotification-
Name:@"listaFragmentosFoiAlterada" object:self userInfo:nil];
}
}
}];
}

- (PFFile *) getContentsAsParseFile
{
if ([[self class] isSubclassOfClass: [FragmentoImagem class]]) {
FragmentoImagem * modelWithContents = (FragmentoImagem*) self;
69

return [PFFile fileWithData: modelWithContents.conteudo];
} else if ([[self class] isSubclassOfClass: [FragmentoAudio class]]) {
FragmentoAudio * modelWithContents = (FragmentoAudio*) self;
NSData * data = [[NSFileManager defaultManager] contentsAtPath: [[AudioManager get-
Instance] getFinalFilePathForName: modelWithContents.fileName]];
return [PFFile fileWithData: data];
} else if ([[self class] isSubclassOfClass: [FragmentoTexto class]]) {
FragmentoTexto * modelWithContents = (FragmentoTexto*) self;
return [PFFile fileWithData: [modelWithContents.conteudo dataUsingEncoding:
NSWindowsCP1252StringEncoding]];
}
return nil;
}

@end
O mtodo sendFileContentsToParse implementado em
Fragmento+ParseControls estar disponvel como extenso a todas as subclasses de
Fragmento. Desta forma, ao ser atualizada a consulta de fragmentos do artefato e caso o
fragmento no esteja sincronizado, este mtodo ser invocado para sincronizao com o servidor.
O envio do objeto PFObject para o servidor pode ser realizado de forma assncrona, ou
sncrona. Neste caso, como a sincronizao no relevante e necessria no momento do cadastro, o
objeto enviado de forma sncrona atravs do mtodo saveInBackgroundWithBlock. Sem
realizar o bloqueio de interface passado como parmetro um bloco de execuo para ser invocado
aps o trmino da sincronizao. No bloco de trmino da sincronizao, so atualizadas as
informaes de status de sincronizao, o identificador do objeto remoto, e o link de acesso ao
mesmo. O processo concludo com a atualizao do objeto em armazenamento local, atravs do
mtodo save do atributo managedObjectContext da classe Fragmento.
Conforme os objetos so enviados para o servidor, os mesmos so disponibilizados em
tempo real na consulta do Dashboard (Figura 29). Algumas colunas da classe so preenchidas
automaticamente e utilizadas como controle de sincronizao da prpria API.
Figura 29 Parse: Dados da Classe "Arquivo"

Junto ao Dashboard so exibidas tambm informaes referentes quantidade de
requisies realizadas no ms. O painel apresentado na Figura 30 apresenta informaes atualizadas
diariamente.

70

Figura 30 Parse: Anlise de Requisies

Desta forma, considerando que todas as informaes foram registradas e devidamente
sincronizadas, as mesmas podero ser exportadas para uma ferramenta CASE.
3.5.4 Integrao: Gerao XML e Padro XMI
Para realizar a integrao com outras ferramentas CASE, foram feitas pesquisas
primeiramente nas formas disponveis de integrao com a ferramenta Enterprise Architect. Entre as
vrias formas de integrao de aplicativo para a ferramenta CASE, algumas so: compartilhar um
banco de dados, realizar o desenvolvimento de uma extenso para a ferramenta em Visual Basic ou
realizar exportao/importao com arquivos XMI.
As alternativas de compartilhamento de banco de dados e desenvolvimento de extenso em
Visual Basic foram descartadas pelo motivo de restringir-se estrutura da empresa ou restrio de
integrao a apenas uma ferramenta.
A soluo adotada foi na gerao do documento XML com o padro XMI, para permitir
tambm ser importado em outras ferramentas. A estrutura bsica deste padro apresentada na
Figura 31.

71

Figura 31 Estrutura do Documento XMI

No elemento base do documento, xmi:XMI so especificadas informaes do padro XMI
e UML a qual o documento se refere, para as exportaes do aplicativo esto sendo usados os
padres XMI 2.1 e UML 2.1 (OMG, 2013).
O elemento base composto por trs outros elementos: Documentation, Model e
Extensions.
O elemento Documentation especifica informaes da ferramenta que est exportando o
arquivo, nome e verso. No elemento Model especificada toda a estrutura de elementos do
modelo, contendo: hierarquia, nome, tipo e identificador de cada elemento. Conforme OMG (2013)
padro XMI permite a definio de qualquer elemento UML. No aplicativo, utilizamos apenas os
elementos: pacote, requisito e artefato.
J no ltimo elemento Extensions existe uma diviso, ele composto por especificao
de cada elemento do modelo e pelos conectores entre todos os elementos.
Na especificao de cada elemento existem muito mais informaes que a representao
dele no elemento Model. Neste conjunto ele composto por atributos como identificador, autor,
status, aparncia, fase, data de criao, entre outros (OMG, 2013).
Os conectores de elementos, so compostos pelo seu prprio identificador e os
identificadores do elemento origem e do elemento de destino.
Para facilitar no desenvolvimento deste modelo e possibilitar a gerao do mesmo baseado
nas informaes dos projetos cadastrados, foi definida um pequeno conjunto de classes
representado na Figura 32.
72

Figura 32 Diagrama de Classes: Gerao XMI

As classes definidas para gerenciar o documento XMI so subclasses de uma API para
gerao XML. Desta forma, aps a definio da estrutura, basta gerar o XML para que o mesmo
seja gerado na estrutura necessria.
No Quadro 27 apresentado mtodo de gerao do documento XML no padro XMI
necessrio para importao em outras ferramentas.
Quadro 27 Gerao do Documento XML

- (NSString *) getContentXmi
{
XMIDocument * documento = [[XMIDocument alloc] init];
XMIPackage * pacoteBase = [[XMIPackage alloc] initPackageWithName: self.modelo.nome];
XMIPackage * pacoteArtefatos = [[XMIPackage alloc] initPackageWithName: @"Artefatos"];

for (Artefato * artefato in self.modelo.artefatos) {
XMIPackage * packArtefato = [[XMIPackage alloc] initPackageWithName: artefato.nome];

if ([artefato.fragmentos count] > 0) {
XMIPackage * pacoteRequisitos = [[XMIPackage alloc] initPackageWithName:
@"Requisitos"];
XMIPackage * pacoteFragmentos = [[XMIPackage alloc] initPackageWithName:
@"Fragmentos"];
73

for (Fragmento * fragmento in artefato.fragmentos) {

// Definio do fragmento
NSString * nomeFragmento = @"Fragmento";
if (fragmento.nome != nil && ![fragmento.nome isEqualToString:@""]) {
nomeFragmento = fragmento.nome;
}
XMIFragment * frag = [[XMIFragment alloc] initFragmentWithName: nomeFragmen-
to ];
if (fragmento.linkParse != nil && ![fragmento.linkParse isEqualToString:@""])
{
[frag setLinkRemoto: fragmento.linkParse ];
}
[pacoteFragmentos adicionaArtefato: frag];

// Definio dos Requisitos de cada fragmento..
if ([fragmento.requisitos count] > 0) {
for (Requisito * requisito in fragmento.requisitos) {
XMIRequirement * req = [[XMIRequirement alloc] initRequirementWith-
Name: requisito.nome];
[req setIdentificadorFragmento: [frag getIdentificadorUnico]];
[pacoteRequisitos adicionaRequisito: req];
}
}
}
[packArtefato adicionaPacote: pacoteFragmentos];
[packArtefato adicionaPacote: pacoteRequisitos];
}
[pacoteArtefatos adicionaPacote: packArtefato];
}
[pacoteBase adicionaPacote: pacoteArtefatos];
[documento adicionaPacote: pacoteBase];

return [documento renderXMLDocumentAsString];
}
Os elementos esto representados no XML conforme a representao do quadro Quadro 28.
Quadro 28 Representao dos elementos no XML

// Definio de pacote
<packagedElement name="Fragmentos" xmi:type="uml:Package" visibility="public"
xmi:id="718C302E-35F8-4D97-95AA-94EF248CE550-4782-00004E350649AF12" >

// Definio do Artefato
<packagedElement name="Captura de Audio" xmi:type="uml:Artifact" visibility="public"
xmi:id="E40ACB02-A307-4C26-A805-0F66114D24BD-4782-00004E35064BCA30" />

// Definio do Requisito
<element name="Requisito XXX" xmi:type="uml:Requirement" scope="public" xmi:idref="D7F8E428-
0BBF-4A6A-AC54-2D807D53A7D4-4782-00004E35064C404D" >
<tags />
<xrefs />
<modelDocument />
<links />
<style appearance="BackColor=-1;BorderColor=-1;BorderWidth=-1;FontColor=-
1;VSwimLanes=1;HSwimLanes=1;BorderStyle=0;" />
<project author="iPad Simulator" status="Proposed" phase="1.0" modified="2013-11-16
17:07:46 +0000" version="1.0" created="2013-11-16 17:07:46 +0000" />
<properties isRoot="false" sType="Requirement" scope="public" isSpecification="false"
nType="0" isAbstract="false" documentation="Pesquisa de Requerente" isLeaf="false" />
<extendedProperties package_name="name_package" tagged="0" />
</element>

74

3.6 RESULTADOS E DISCUSSO
Os resultados da aplicao foram muito favorveis. Pode-se gerenciar diversos projetos,
criar artefatos e simular diversas situaes. Aps a simulao, os projetos foram exportados e
importados com sucesso em pelo menos duas ferramentas CASE, o Enterprise Architect e o Visual
Paradigm for UML.
Um dos maiores problemas foi identificar a melhor maneira de integrao com a ferramenta
CASE, principalmente pelo fato de que contedo dos fragmentos deve estar disponvel tambm na
ferramenta. Com a descoberta dos servios de computao em nuvem e ao verificar que muitos
deles so gratuitos, foram feitos alguns testes e constatado que seria a melhor soluo para
solucionar a integrao.
Aps o desenvolvimento, foram realizados testes de performance do aplicativo em um iPad
2, onde os resultados foram satisfatrios. Para realizar os testes, o aplicativo foi carregado com 1
projeto, 1 artefato e 50 fragmentos.
Na Figura 33 so apresentados os grficos de utilizao da CPU durante a execuo de
algumas rotinas do aplicativo. Em alguns momentos ele chegou a utilizar 15% do processamento
disponvel e chegando ao pico de 42%.
Figura 33 Performance: CPU Utilizada

J a memria utilizada pelo aplicativo chegou ao ponto mximo de 10,9 MB com o mnimo
de 3,8 MB inicial. Representao grfica na Figura 34.

75

Figura 34 Performance: Utilizao de Memria

notvel a quantidade de novas possibilidades e de crescimento para o aplicativo,
possibilidades de novas funes, principalmente se for comparado com os trabalhos correlatos
submetidos a App Store, que carecem de atualizaes ou at a inexistncia de aplicaes desta
categoria para dispositivos mveis.
Algumas restries tiveram que ser adotadas devido ao servio de PaaS ser gratuito. Foi
adicionado uma limitao ao prottipo, para que o mesmo possa registrar apenas 200 fragmentos.
Isto com base no limite de requisies e armazenamento do servidor remoto.
Outra funcionalidade que se optou por no existir, justamente por ser um prottipo, o
controle de usurios. Funcionalidade esta que no inviabiliza a utilizao da ferramenta.

76

4 SOLUO
Nesta seo sero apresentadas as funcionalidades da soluo proposta. Para configurao
do projeto, desenvolvimento, publicao e disponibilizao do aplicativo na Apple App Store, foi
atribudo o nome de Klip.
Ao iniciar a aplicao ser exibida a tela principal do aplicativo, contendo a lista de projetos
e um pequeno manual de ajuda para o usurio. A Figura 35 apresenta a tela inicial do aplicativo.
Figura 35 Tela inicial do Aplicativo

O Usurio, atravs do menu lateral esquerdo, pode realizar a criao de novos projetos ou
selecionar um projeto j criado anteriormente. Aps a seleo de um projeto para ser gerenciado, o
sistema atualiza o menu, exibindo ento os artefatos j definidos. A Figura 36 apresenta esta
listagem.
Figura 36 Lista de Artefatos do Projeto

77

Junto gesto dos artefatos criados possvel alterar o projeto, renomeando o mesmo ou
alterando a sua descrio geral. Ao selecionar um artefato criado, o usurio direcionado para o
painel do artefato (Figura 37), no qual so exibidos todos os fragmentos j definidos.
Figura 37 Fragmentos de um Artefato

No painel do artefato possibilitada ao usurio a principal etapa da aplicao, a realizao
de coleta de informaes junto aos interessados do sistema. Selecionando a opo Novo no menu
superior, disponibilizado ento o registro de novos fragmentos, podendo ser um som ambiente,
fragmentos de texto ou imagens (Figura 38).
Figura 38 Definio de Novo Fragmento

78

Para registrar um novo fragmento de texto, disponibilizada ao usurio uma janela
simplificada com possibilidade de definio do identificador e desenvolvimento do contedo,
conforme Figura 39.
Figura 39 Definio de Fragmento: Texto

Outro fragmento de artefato que pode ser armazenado o fragmento de imagem, na qual
possibilita ao usurio a coleta de imagens atravs da cmera ou atravs da biblioteca de imagens
(Figura 40) do dispositivo. Aps a seleo ou captura da imagem, o usurio tem a possibilidade de
visualizar, em propores maiores, aps isto ento poder confirmar o registro da imagem.
Figura 40 Seleo de Imagem para o Fragmento Imagem

79

J o fragmento de udio registrado em duas etapas: a primeira para sinalizar o incio da
gravao de udio, e a segunda para realizar a finalizao do registro e registro efetivo do
fragmento.
No painel do artefato, o usurio tambm pode realizar o registro de requisitos identificados
para um fragmento. Para isto, basta realizar a seleo do fragmento na qual o requisito foi
identificado e, na barra inferior, selecionar a aba requisitos. Ser apresentada ao usurio uma
listagem de requisitos j definidos, conforme Figura 41.
Figura 41 Lista de Requisitos do Fragmento

Junto a listagem de requisitos j definidos para o fragmento, possvel realizar o cadastro de
um novo, conforme a Figura 42. O requisito baseado em um identificador, tipo, detalhes,
complexidade e prioridade.
Figura 42 Definio de Novo Requisito

Aps todas as informaes coletadas junto aos interessados do projeto e com a definio dos
requisitos de software com base nos artefatos, o analista tem a possibilidade de realizar a exportao
80

do projeto para outras ferramentas. Em detalhe na Figura 43, a funcionalidade de exportao do
projeto.
Figura 43 Exportao do Projeto

Ao realizar a seleo da exportao do projeto, o sistema processar as informaes no
formato padro XMI. Com o documento criado e definido, o aplicativo exibir ao usurio (Figura
44) a possibilidade de enviar este arquivo como anexo por e-mail.
Figura 44 Composio do E-mail do Arquivo de Exportao

Aps a gerao e envio do arquivo de integrao, o mesmo pode ser importado em
ferramentas CASE com suporte importao de arquivos XMI. Para verificao, utilizamos duas: o
Enterprise Architect e o Visual Paradigm for UML. Na Figura 45 apresentada a estrutura do
81

projeto aps a importao. Na esquerda mostrada a estrutura definida pelo Enterprise Architect e
na direita estrutura definida pelo Visual Paradigm for UML.
Figura 45 Estrutura do Projeto

Com a importao do projeto na ferramenta, so disponibilizados os elementos para
utilizao em novos diagramas ou em diagramas j existentes.
A Figura 46 a representao de um novo diagrama de requisitos com base na estrutura
importada pelo arquivo XMI.
Figura 46 Diagrama de Requisitos: Enterprise Architect

Na Figura 47 representada a definio de um novo diagrama de requisitos atravs da
ferramenta Visual Paradigm for UML com base nos elementos do projeto importado.

82

Figura 47 Diagrama de Requisitos: Visual Paradigm for UML

Os fragmentos possuem em sua definio o link de acesso para seu contedo armazenado no
servidor remoto. Atravs da Figura 48 pode ser visualizado este relacionamento no Enterprise
Architect.
Figura 48 Link remoto de acesso ao Fragmento

No processo de importao das informaes para a ferramenta CASE, so importados
apenas os elementos que compem o projeto. Aps isto, fica a critrio do analista em seu projeto
realizar a criao de novos diagramas ou utilizar diagramas j existentes.
Figura 49 Fluxo da Aplicao

De forma simplificada, na Figura 49 apresentado o funcionamento de todo o ambiente da
aplicao: o dispositivo envia informaes para o servio Parse, e permite a exportao destas
83

informaes atravs de um documento no Padro XMI para ferramentas CASE. Aps carregadas as
informaes na ferramenta CASE, possibilitado atravs de um link da internet o acesso s
informaes do fragmento, que por sua vez esto armazenadas no servidor Parse.
Com o ambiente e fluxo completo, finaliza-se o desenvolvimento da aplicao. Nas sees a
seguir, ser apresentada a concluso com resultados e dificuldades obtidas.

84

5 CONCLUSO
O desenvolvimento do projeto mostra que possvel trazer maiores facilidades na coleta de
informaes para a definio de software, possibilitando a definio de forma apropriada sem
restries quanto ferramenta utilizada para realizar a futura especificao e anlise detalhada.
A integrao por meio dos documentos XMI constatou-se como a melhor soluo em
comparao com as outras verificadas, no comprometendo a estrutura do aplicativo com
dependncia de outras tecnologias e, principalmente, no focando em apenas uma ferramenta.
Os tipos de fragmentos disponibilizados para serem registrados tambm foram suficientes
para abranger grande parte dos projetos simulados, mesmo em dispositivos antigos. No caso do
iPad 2, mostrou-se grande qualidade nas interfaces para registro das informaes e tambm para a
execuo da aplicao.
Quanto ao desenvolvimento, as tecnologias empregadas se adequaram com perfeio ao
projeto, sendo tecnologias nativas, no foram encontrados problemas. O Core Data trouxe grandes
facilidades na implementao, necessitando apenas um bom tempo de pesquisa, j que existem
poucas ferramentas semelhantes. A linguagem Objective-C, que pareceu ser totalmente diferente em
um primeiro momento, demonstrou-se bastante dinmica e semelhante s outras, com poucas
mudanas de nomenclatura. A maior dificuldade no desenvolvimento foi a utilizao da prpria
IDE, j que possui um grande conjunto de ferramentas integradas, no se tinha uma viso da
utilidade de cada ferramenta ou funo.
Todos os objetivos especficos foram atingidos. disponibilizada de maneira simples a
definio de requisitos de software, possibilitando a integrao com outras ferramentas CASE e
ento a verificao de rastreabilidade dos requisitos de software.

85

5.1 EXTENSES
Sugere-se vrias complementaes ao trabalho realizado, de forma que aumente sua
relevncia cientifica e o nmero de funcionalidades do aplicativo. Destacam-se algumas novas
funcionalidades importantes:

a) Controle de Usurios.
b) Sincronizao completa de todas as informaes e elementos do projeto.
c) Possibilitar o controle de interessados no projeto e a relao Projeto X Interessado.
d) Permitir o registro de contedo vindo de outros aplicativos, como o gerenciador de e-
mail, navegador ou um aplicativo de terceiro.
e) Possibilitar, de alguma forma, que o usurio d um feedback quanto s informaes
mantidas no aplicativo.
f) Realizar a criao de novos tipos de fragmentos, como checklists, vdeo, diagramas,
link da internet, entre outros.
g) Possibilitar o gerenciamento de checklists de avaliao para a coleta das
informaes, com perguntas ou roteiro padro a ser seguido. Auxiliando o
engenheiro de requisitos na coleta.
h) Desenvolver interface para smartphone e outros sistemas operacionais.
i) Realizar a publicao do aplicativo na App Store.
j) Fazer experimentos comparando projetos que utilizam a ferramenta e projetos que
no utilizam.
k) Realizar anlise para adequar-se aos processos de qualidade como CMMI e
MPS.BR.

86

REFERNCIAS
VILA, A. L. Artigo Engenharia de Software - Introduo Engenharia de Requisitos. Portal DevMedia,
2012. Disponivel em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=8034>. Acesso em: 25
Agosto 2012.

AMMANN, D. Requirements Elicitation: Tools for End-Users. University of Zurich, Department of
Informatics, Zurique, 2011. Disponivel em:
<https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/re_seminar_fs11/RE_Tools_for_End_Users_final_ver
sion.pdf>. Acesso em: 10 Novembro 2013.

APPLE. Apple iPad Features. Apple, 2013. Disponivel em: <http://www.apple.com/ipad/features/>. Acesso
em: 12 Abril 2013.

APPLE. iOS Developer Library. Apple Developer Center, 2013. Disponivel em:
<https://developer.apple.com/library/ios/navigation/>. Acesso em: 15 Maio 2013.

APPLE. iOS Technologies Overview. Apple Developer Portal, 2013. Disponivel em:
<https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/
Introduction/Introduction.html>. Acesso em: 20 Abril 2013.

APPLE. Xcode Download and Resources - Apple Developers. Apple, 2013. Disponivel em:
<https://developer.apple.com/xcode/>. Acesso em: 28 Agosto 2013.

BACKES, J. Rastreabilidade: Definies Iniciais. Engenharia de Software Magazine, So Paulo, n. 13, p.
24-34, 2009. ISSN 1983127-1.

BLASCHEK, J. R. Gerncia de Requisitos: O principal problema dos projetos de software. Developers
Magazine, 2002.

BLOCK, R. Live from Macworld 2007: Steve Jobs keynote. Engadget: International Editions, 17 Agosto
2013. Disponivel em: <http://www.engadget.com/2007/01/09/live-from-macworld-2007-steve-jobs-
keynote/>.

BRITO, R. C.; OGLIARI, R. Android e iPhone - mais parecidos do que voc pensa. Mobile Magazine, p.
31-42, 2012. Disponivel em:
<http://www.devmedia.com.br/websys.4/webreader.asp?cat=5&artigo=4822&revista=webmobile_43#a-
4822>.

CAMBRIDGE UNIVERSITY PRESS. Smartphone noun - definition in the Business English Dictionary.
Cambridge Dictionaries Online, 07 Abril 2013. Disponivel em:
<http://dictionary.cambridge.org/dictionary/business-english/smartphone?q=Smartphone>.

CHRISTEL, M. ; KANG, K. C. Issues in Requirements Elicitation - Technical Report. Carnegie Mellon
University. Pittsburgh, p. 80. 1992. (CMU/SEI-92-TR-012 ESC-TR-92-012).

COLLABNET. About CloudForge. CloudForge, 2013. Disponivel em: <http://www.cloudforge.com/about-
us>. Acesso em: 20 Junho 2013.

COMSCORE. 2012 Mobile Future in Focus. comScore, 2012. Disponivel em:
<http://www.comscore.com/Insights/Presentations_and_Whitepapers/2012/2012_Mobile_Future_in_Focus>.
87

Acesso em: 15 Maio 2013.

COMSCORE. 2013 Mobile Future in Focus. comScore, 2013. Disponivel em:
<http://www.comscore.com/Insights/Presentations_and_Whitepapers/2013/2013_Mobile_Future_in_Focus>.
Acesso em: 14 Novembro 2013.

CUNHA, U. O que um tablet e o que ele faz? MochileiroDigital, 15 Fevereiro 2012. Disponivel em:
<http://www.mochileirodigital.com.br/reviews/tablets/o-que-e-um-tablet/>.

DEHLINGER, J.; DIXON,. Mobile Application Software Engineering: Challenges and Research Directions.
Department of Computer and Information Sciences - Towson University, 07 Abril 2013. Disponivel em:
<http://mobileseworkshop.org/papers/7-Dehlinger_Dixon.pdf>. Acesso em: 01 maio 2013.

FILHO, T. L. Metodologia de Desenvolvimento de Sistemas. Rio de Janeiro: Axcel, 2003.

IEEE SOFTWARE ENGINEERING STANDARDS COMMITTEE. IEEE Recommended Practice for
Software Requirements Specifications. IEEE Standards Association. [S.l.], p. 31. 1998. (IEEE Std 830-
1998).

ITU: INTERNATIONAL TELECOMMUNICATION UNION. The world in 2009: ICT Facts and Figures,
2009. Disponivel em: <https://www.itu.int/net/TELECOM/World/2009/newsroom/pdf/stats_ict200910.pdf>.
Acesso em: 15 Fevereiro 2013.

KENNEY, M.; PON, B. Structuring the Smartphone Industry: Is the Mobile Internet OS Platform the Key.
Social Science Research Network, 27 Janeiro 2011. Disponivel em:
<http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1851686>.

LANE, K. Backend as a Service (BaaS). API Evangelist, 2013. Disponivel em:
<http://baas.apievangelist.com>. Acesso em: 02 Novembro 2013.

LEFFINGWELL, D. Calculating the Return on Investment from More Effective Requirements Management.
Software Quality Matters, 2009. Disponivel em: <http://www.ifsq.org/work-leffingwell-1997.html>.
Acesso em: 15 Abril 2012.

MORAES, J. B. D. Introduo a Abordagens de Identificao de Requisitos. Engenharia de Software, p.
54-58, 2009.

OMG. XMI Mapping Specification, 2013. Disponivel em: <http://schema.omg.org/spec/XMI/2.1/PDF/>.
Acesso em: 4 Novembro 2013.

PALUDO, M. A. et al. O Desenvolvimento de Software Aplicando a Tcnica Joint Application Design.
UTFPR - Universidade Tecnolgica Federal do Paran, 2009. Disponivel em:
<http://www.pg.utfpr.edu.br/ppgep/Ebook/ARTIGOS/56.pdf>. Acesso em: 2 Abril 2012.

PARSE. Parse: Overview. Parse, 2013. Disponivel em: <https://www.parse.com/products/data>. Acesso em:
21 Julho 2013.

PRESSMAN, R. S. Engenharia de Software. 7. ed. Rio de Janeiro: McGraw-Hill Interamericana, 2011.

REZENDE, D. A. Engenharia de Software e Sistemas de Informao. 3. ed. Rio de Janeiro: Brasport,
2005.

88

SAYO, M.; LEITE, J. C. S. D. P. Rastreabilidade de Requisitos. Monografias em Cincia da
Computao: PUC-Rio, Rio de Janeiro, Maio 2011.

SEYFF, N.; GRAF, F.; MAIDEN, N. Using Mobile RE Tools to Give End-Users their Own Voice.
Requirements Engineering Conference (RE), 2010 18th IEEE International. Sydney, NSW: IEEE
International. 2010. p. 37 - 46.

SOMMERVILLE, I. Engenharia de Software. 9. ed. So Paulo: Pearson Education, 2011.

STANDISH GROUP. Chaos Report. [S.l.]. 2011.

TONSIG, S. L. Engenharia de Software - Anlise e Projeto de Sistema. 2. ed. Rio de Janeiro: Cincia
Moderna, 2008.

VASCONCELOS, N. G. D. Android versus iPhone - Artigo WebMobile Magazine 30. DevMedia, 15 Agosto
2013. Disponivel em: <http://www.devmedia.com.br/android-versus-iphone-artigo-webmobile-magazine-
30/17109>.

YOUNG, R. R. The Requirements Engineering. Norwood: Artech House, INC., 2004.

Protótipo de Aplicativo Móvel para Apoiar o Levantamento de Requisitos de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protótipo de Aplicativo Móvel para Apoiar o Levantamento de Requisitos de Software

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC

CENTRO DE EDUCAO SUPERIOR DO ALTO VALE DO ITAJAI

You might also like