sistema academy manages

Prévia do material em texto

DOCUMENTAÇÃO DO SOFTWARE ACADEMY MANAGES 
 
 
 
 
 
 Lima, Pablo Machado1 
 Pires, Vinicius Resende2 
 Silva, Paula Patrícia Oliveira da3 
 
 
 
 
RESUMO: 
 
O seguinte artigo mostrará e exemplificará todos os processos, para a modelagem do 
Academy manages, passando pelos conceitos da engenharia e os implementando no 
sistema. Além de tudo utilizará a linguagem de modelagem unificada a UML, na qual sua 
orientação será extremamente importante para a representação do Academy manages. 
O grande foco do artigo é estruturar todos os conceitos da engenharia software e UML, para 
que os seguintes sejam planejados e usados de formas eficientes, na metodologia de sua 
construção, e os reflita-os nos resultados de todo o processo de desenvolvimento do 
software. 
 
Palavras-chave: 
Academy Manages, Astah Professional, UML. 
 
 
 
 
 
 
1
Pablo Machado Lima Graduando em Análise e Desenvolvimento de Sistemas, pelo IF Baiano campus 
Guanambi. E-mail: pablo.escobar.cs@hotmail.com 
 
2 
Vinicius Resende Pires Graduando em Análise e Desenvolvimento de Sistemas, pelo Instituto Federal Baiano 
campus Guanambi. E-mail: piresvrp@gmail.com 
 
3
 Professora e coordenadora do curso de Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto 
Federal de Educação, Ciência e Tecnologia Baiano campus Guanambi, e-mail: 
paula.patricia@guanambi.ifbaiano.edu.br. 
1. Introdução 
 
O artigo elaborado aborda todas as metodologias, técnicas e ferramentas utilizadas na 
fase de análise do sistema “Academy manages”. Com o desenvolvimento acelerado do 
software, e a introdução da engenharia de software para o controle de todo o processo 
de criação do qualquer sistema, torna-se indispensável às metodologias e os conceitos 
da engenharia de software, nas fases de elaboração de um sistema. Contudo isso ganha 
ainda mais importância a UML para a modelagem do software, na qual sua orientação e 
seus conceitos são importantíssimos para a representação e visualização adequada do 
sistema. 
 
A elaboração deste software foi destinada e focada para um ambiente de uma academia 
física, onde o mesmo controlará todo o fluxo da academia como, por exemplo: cadastro 
de clientes, cadastro de funcionário, controle financeiro entre outras funções que ele 
será encarregado. 
 
Dentre os principais propósitos do software será gerenciar e agilizar as atividades 
principais como: pagamentos, manipulação dos dados cadastrais de clientes e 
funcionários, sendo assim se fazem necessário controlar todas as informações e 
dependências que cercam esse ambiente, dentre outros. Além disso, é preciso que o 
software facilite o fluxo dos clientes ,e cuide de uma boa implementação para que o 
usuário não tenha dificuldades em interagir com o software. 
 
Os principais aspectos que agregam valor ao desenvolvimento do sistema Academy 
manages para é a metodologia utilizada para análise e modelagem do software tais 
como: a elaboração do modelo conceitual, levantamento e análise de requisitos e a 
modelagem dos diagramas do sistema, pois através da aplicação correta da 
metodologia, cria-se uma margem menor para erros, no momento do desenvolvimento 
do sistema. 
 
2. Engenharia de software 
 
Quando se desenvolve um sistema, são necessárias varias etapas desde a elaboração 
do modelo conceitual a até a execução do software, ou seja, são todo esse processo 
tem que ser cumprido de forma eficaz e coesa, para que demais erros futuros sejam 
escassos e pequenos. Tendo em vista toda essa metodologia torna- se indispensável, 
os conceitos e uso da engenharia de software para a elaboração do Academy manages. 
 
Engenharia de software conjuntos de atividades que são feitas através, planejamentos, 
gerenciamento, controle, processos que são suma relevância para desenvolvimento de 
sistemas destinado a criação de software no qual terá seu objetivo principal atender 
todas as exigências do cliente. (PRESSMAN, 2011) 
 
A partir do momento em que software ganhou muita atenção devido ao seu 
desenvolvimento acelerado, e das grandes repercussões diante das tendências que 
surgiram depois da década de 60, houve a necessidade de uma especialização e 
adaptação de uma área que cuidasse e orientasse todas as fases de desenvolvimento 
de um sistema, área essa que era justamente a engenharia de software que surgiu 
exatamente para se tiver o maior controle possível sobre os requesitos de um sistema e 
todo processo que cerca o desenvolvimento do mesmo. 
 
Como sabemos a criação da engenharia de software, foi proporcionada pelo fato de no 
começo não haver a orientação certa para o desenvolvimento de um sistema. Assim era 
comum inúmeros erros que deixavam o processo lento e pouco produtivo prejudicando 
ambas as parte. A partir de então com assimilação da engenharia de software nos 
processo de desenvolvimento do sistema, houve uma diferença significativa em todos os 
fatores que cercam o software, como: os requesitos, métodos, ferramentas etc. , 
Deixando todo a construção do sistema mais solida em ambos os pontos. 
 
Quando se passou a entender o que era, e para que servia a engenharia de software 
compreendeu-se que ela estava totalmente ligada a produção de sistemas complexos ou 
não, e que ela nos permitia que acompanhássemos todos os prazos e exigências da 
construção do software, fato que é especial para os desenvolvedores e analistas de 
sistemas que lidam com problemas que necessitam paciência e habilidade necessária 
para serem resolvidos da melhor forma. 
 
A criação de um software de qualidade é totalmente dependente do seu processo de 
desenvolvimento, pois ele dará acompanhamento preciso e eficaz em todas as fases do 
software, não só a sua construção, mas também trará solidez durante o período em que 
estiver em uso. Por isso a engenharia de software torna-se quase obrigatória para o 
desenvolvimento adequado de um software. 
 
 
Figura 1 - etapas relacionadas ao objetivo, que a qualidade que será feita através de 
processo por meio de atividades e tarefas ordenadas alinhadas a métodos com o apoio 
de ferramentas 
Fonte: http://adsbaixarengenhariadesoftware.blogspot.com.br/2013/05/engenharia-de-
software- responsabilidade.html 
 
 
2.1 Modelos de processos. 
 
Há vários modelos de processo de desenvolvimento de software, cada um com uma 
característica diferenciada dos demais, sempre visando estabelecer uma ordem concreta 
das atividades que cercam o desenvolvimento de um sistema. 
 
Quando se está desenvolvendo um software é muito importante, ter uma ordem 
sincronizadas das atividades que levarão a construção do sistema, ou seja, cada etapa é de 
fundamental importância para que seja criada um sistema solido e eficaz. Os modelos de 
processo são os principais caminhos, para se chegar ao software de qualidade mostrando 
quanto é importante para a elaboração de um software. 
 
2.1.1 principais modelos de processos 
 
2.1.2 cascata 
O modelo cascata é um método de desenvolvimento que é linear e sequencial. Na primeira 
vez que uma fase de desenvolvimento é completada, o desenvolvimento prossegue para a 
próxima fase, mas sem a possibilidade de retorno. A vantagem é que ele permite o controle 
departamental e gerencial. Cada fase de desenvolvimento prossegue em uma ordem 
escrita, sem qualquer sobreposição ou passos iterativos (PRESSMAN, 2006). 
A desvantagem é que não permite muita flexibilidade ou revisão e não é capaz de 
estabelecer como efetuar engenharia reversa de um sistema existente. 
 
2.1.3 interativo. 
 
O modelo iterativo pode ser visto como uma variaçãodo modelo em cascata, visto que o 
software é desenvolvido em incrementos e cada incremento é desenvolvido em cascata 
(BEZERRA, 2002). 
 
Este modelo apresenta como vantagens a possibilidade de avaliar, antecipadamente os 
riscos e os pontos críticos do projeto, identificando medidas para eliminá-los ou controlá-los; 
além de desenvolver uma arquitetura que possa orientar, de um modo melhor todo o 
desenvolvimento do produto (MACORATTI, 2005). 
 
Como desvantagem tem as continuas mudanças no projeto que tendem a corromper a 
estrutura do software e a incorporação destas mudanças torna-se cada vez mais complicada 
e dispendiosa. Além disso, se o sistema for desenvolvido rapidamente, a produção de 
documentos a cada versão torna-se inviável economicamente (SOMMERVILLE 2007). 
 
2.1.4 prototipação 
 
O modelo de processo prototipação, é um modelo ne que se baseia em um protótipo do 
sistema , sempre tendo em vista os requesitos iniciais levantados. O desenvolvimento é feito 
obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a 
codificação e os testes. Essas estas nesse modelo, não precisam ser realizadas com um 
rigor muito forte, porém precisa de ampla atenção ser adequados aos requisitos do 
sistema. 
 
 
Figura 2: representação do ciclo nesse modelo de processo – fonte: 
http://www.abrasus.org.br/ 
 
As vantagens de desse modelo, são muitas como: teste no ambiente de execução do 
software, forte interação com o cliente, e na maioria dos casos tem se um quadro de 
requisitos bem definidos. Porém existem algumas desvantagens como, por exemplo, a 
principal delas em que, o processo de modelagem é feito de maneira rápida, sem que haja 
maior analise e estudo do problema. Podendo ocasionar erros no futuro dificultando sua 
correção. 
 
2.2 Elicitação de requesitos 
 
Tem o proposito de obter informações ou reações, esta fase do processo relaciona-se à 
obtenção dos requisitos do sistema. 
Ela esta voltada para o meio social, ou seja, é uma parte do projeto que visa à interação 
com as pessoas envolvidas no sistema. O grande objetivo da Elicitação são levantar os 
requesitos através de mecanismos , com os quais poderão ser extraídos possíveis 
requesitos e ideias das quais poderão ser uteis para a resolução de problemas , uma 
grande vantagem para se ter em mente do que precisará o sistema. 
Algumas das técnicas de Elicitação de requesitos são: 
 Entrevistas que é um jogo de perguntas e respostas 
 Questionários tem função de guiar para solução de um problema. 
 Casos de Uso Trata se de uma verificação de alguns itens, como se não há 
requisitos faltando ,Verifique que os desenvolvedores entendem os requisitos, a sua 
vantagem é ter apelo visual dos requisitos mais relevantes do cliente. 
 Jogo de Funções Essa técnica esta voltada para troca de lugares para que possam 
verificar alguns erros, para que haja uma solução antes que chegue ao usuário. 
 Brainstorming é uma atividade desenvolvida para explorar a potencialidade criativa 
de um indivíduo ou de um grupo. 
 Workshop de Requisitos consiste numa técnica usada através de uma reunião 
estruturada, da qual devem fazer parte um grupo de analistas e um grupo 
representando o cliente, para então obter um conjunto de requisitos bem definidos. 
2.2.1 Requesitos 
O principal fato que determina são os requesitos, pois eles vão determinar como o sistema 
será o sistema, ou seja, precisam ser amplamentes lapidados para que os mesmos não 
sejam distorcidos, ou não atendidos quando o software estiver em execução . Os requesitos 
basicamente se resume em exigências que o sistema terão que ter eles podem ser: 
 Requesitos funcionais: descrevem as principais funcionalidades que o software irá 
realizar. Por exemplo, o software deve cadastrar clientes em uma loja. 
 Requesitos não funcionais : descrevem aspectos internos do sistema, ou seja, 
voltado para a parte técnica, esses requisitos não são voltados para o cliente, 
mas sim para o desenvolvedor no qual devera aplicar técnicas para que os 
usuários do sistema possam usufruir de forma melhor. 
Tendo em vista a importância dos modelos de processo alinhados com a Elicitação de 
requesitos onde são levantados os requesitos, torna-se fundamental cumprimento de tais 
etapas de forma correta , pois são necessárias para uma modelagem ideal. Essas etapas 
são de suma importância para que o sistema seja visualizado e representado sobre a 
metodologia da UML que buscará representar o software da melhor forma possível. 
 
3. UML – Unified Modeling Language 
 
A UML (Unified Modeling Language) é uma linguagem para especificação, documentação, 
visualização e desenvolvimento de sistemas orientados a objetos. Sintetiza os principais 
métodos existentes, sendo considerada uma das linguagens mais Expressivas para 
modelagem de sistemas orientados a objetos. 
 
A parir do momento em que se trabalha com o desenvolvimento de sistema, é necessário 
ter, a visão necessária para adequar o software no padrão correto e seguindo todas as fases 
de exigências, tendo a UML como uma linguagem que lida com visualização e modelagem 
do sistema desde sua ideia, ate sua execução ela acaba se tornando amplamente 
necessária para o cumprimento ideal de todas as fases de sistema 
 
3.1 Historia da UML 
 
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são 
conhecidos como “os três amigos”. A UML é a junção do que havia de melhor nas três 
metodologias dos desenvolvedores da linguagem, adicionando novos conceitos e visões 
diferentes da que existiam sobre ela. 
 
A UML (Linguagem de Modelagem Unificada) suporta as cinco fases de desenvolvimento 
Software: análise de requisitos, análise, projeto, implementação e testes. Estas fases não 
necessariamente devem ser executadas na ordem sequencial, porém devem ser feitas com 
maior grau de cautela para que não haja futuros como: requesitos não atendidos, danos na 
fase de teste etc. 
 
3.2 Diagramas da UML 
 
A partir do desenvolvimento de um sistema com a metodologia da UML, é possível analisar 
o sistema de uma forma mais segura e abrangente através dos diagramas. Os diagramas da 
UML são utilizados para representação visual de um sistema sobre diversas perspectivas 
ajudando a compreender todo escopo e comportamento do sistema. 
 
Os diagramas da UML são divididos em dois tipos os comportamentais e os estruturais. 
Os diagramas estruturais lidam com o aspecto estrutural tanto do ponto de vista do sistema, 
quanto das classes. Existem para visualizar, especificar, construir e documentar os aspectos 
estáticos de um sistema, ou seja, a representação de sua arquitetura e estruturas que o 
compõe. 
 
Figura 2: Diagramas estruturais da UML fonte: 
http://unibansistemas.files.wordpress.com/2011/10/diagramas-uml_aquilafernandalugli.pdf 
 
Os diagramas comportamentais são voltados para mostrar o comportamento do sistema , 
quando ele estiver em ação , ou seja, trabalhará com simulação visual do sistema facilitando 
e compreendendo aqueles que utilizarão de suas funcionalidades. 
 
Figura 3: diagramas comportamentais fonte: 
http://unibansistemas.files.wordpress.com/2011/10/diagramas-uml_aquilafernandalugli.pdf. 
. 
 
 
3.3 Ferramentas CASE. 
 
Segundo (PRESSMAN, 2002), CASE é uma ferramenta de software apoiada por 
computador que assiste gerentes e profissionais de engenharia de software em toda 
atividade associada com o processo de software. 
 
Em (PRESSMAN, 2002) foi criada uma taxonomia para essas ferramentas utilizando como 
critério a função a qual ela é aplicada. 
 
Em resumo as ferramentas CASE sãoprogramas que auxiliam o desenvolvedor na 
construção do sistema, prevendo ainda na sua concepção, como será sua estrutura, quais 
serão suas classes, entidades, seus fluxos e outros detalhes. Um dos grandes detalhes na 
elaboração de um sistema é a escolha de uma ferramenta CASE correta, pois a ferramenta 
certa poupar á grandes esforços e trará ganho de tempo na preparação do software. 
 
 
3.4 Astah Community 
 
Astah Community é uma ferramenta gratuita voltada para a modelagem de diagramas UML 
(Unified Modeling Language). Além do Astah Community, existem outras três versões: Astah 
UML, Astah Professional e Astah Share que disponibilizam outras funcionalidades além da 
modelagem UML, porém, sua licença é comercial. A ferramenta Astah Community é 
conhecida por sua praticidade e simplicidade em elaborar diagramas como, por exemplo: 
diagramas de classe, caso de uso, sequência, atividades, comunicação, máquina de estado, 
componentes, implantação, estrutura de composição, objetos e pacotes. 
 
A ferramenta CASE “ASTAH” foi utilizada para a elaboração dos diagramas de classe, de 
caso de uso e de atividades além do documento de requisitos do sistema “Academy 
manages”. 
 
4. Metodologia 
 
O projeto escolhido foi um projeto de pequeno porte, onde foram feitas pesquisas e 
levantamentos para que tivéssemos uma visão geral do projeto e como poderíamos 
automatizar e agilizar todos os serviços que a academia fornece para o cliente. Foi 
observando durante o processo de pesquisa que há uma deficiência no quesito de um 
software que gerencie de forma geral as funcionalidades que o software pode proporcionar 
ao ambiente designado. 
Foi necessário que fizéssemos outra pesquisa para achar uma ferramenta que nos der todo 
o suporte necessário para a modelagem do mesmo. 
 
 
5. Resultados 
 
A elaboração do modelo conceitual foi o principio da representação do sistema. Através 
dele passou-se a ter ideia do quais realmente eram as necessidades dos nossos clientes 
e, a partir da análise destas necessidades, pode-se construir uma proposta de sistema 
para resolver os problemas da academia. A partir do modelo conceitual, iniciou-se a fase 
de levantamento, análise e documentação dos requisitos Esta é uma das fases mais 
importante na elaboração de um sistema, pois qualquer concepção errada de um 
requisito compromete todo o andamento do projeto. 
 
Com a identificação dos requisitos finalizada, abriu-se espaço para a representação e 
visualização do sistema através do uso dos diagramas da UML. Pode-se ter ideia de 
como seria a estrutura do sistema através do diagrama de classe e o comportamento 
que terá sistema quando em execução, com os diagramas de caso de uso e de 
atividades. 
 
5.1 Modelo conceitual 
 
Segundo o modelo conceitual o propósito do sistema será: fazer com que a 
automatização do sistema seja destinada a gerencia total da academia, pois atividades 
rotineiras como cadastro de clientes, gerenciamento financeiro, controle de funcionários e 
demais atividades rotineiras e não rotineiras, deverão ser efetuadas através desse controle 
físico, tais processos como esses não deverão tomar muito tempo, por isso é importante ter 
algo que agilize e deixem solidas tais funções sendo processada através de um sistema. 
 
A elaboração do modelo conceitual do sistema “Academy manages”, relatou-se problemas 
diários e comuns, como: dificuldade em gerenciamento de cadastros, pagamentos, ou seja, 
percebeu – se que o sistema seria um gerenciador das atividades rotineiras de um ambiente 
comercial como é uma academia física. A partir da concepção e elaboração do modelo 
conceitual foi fechada esta etapa e avançado para abordagem dos requesitos. 
 
 
5.2 Documento de Requisitos 
No documento de Requisitos foram abordados todos os requisitos funcionais do sistema, ou 
seja, as funcionalidades que o software terá que cumprir. Através dele, foi proporcionada 
uma melhor assimilação das ideias do sistema que garantiram maior agilidade na finalização 
do projeto. 
 
5.3 Tabela de requisitos funcionais. 
 
ID Nome Texto 
RF01 Cadastrar cliente O software deve registrar os 
clientes com nome, telefone, 
endereço, CPF, foto e registro 
biométrico. 
RF02 Registar pagamento O software deve registrar os 
pagamentos das mensalidades. 
RF03 Suspender cadastro O software deve permitir o 
cancelamento da matricula ou 
suspensão temporária se o 
cliente possuir debito com a 
empresa 
RF04 Emitir Comprovante de matricula O software deve gerar um 
comprovante de matricula. 
RF05 Comprovante de pagamento O software deve gerar um 
comprovante de pagamento 
das mensalidades. 
RF06 Gerar relatórios financeiros O software deve gerar um 
relatório ao final de cada dia 
relacionando as receitas 
obtidas. 
RF07 Gerar relatório de avaliações de 
Resultados físicos. 
O software deve gerar um 
relatório que contenha os 
resultados da avaliação física 
de um aluno. 
RF09 Cadastrar modalidade O software deve permitir o 
cadastro de novas 
modalidades. 
RF10 Cadastrar instrutor e as turmas que 
lecionará. 
o software deve cadastrar 
instrutor e salva seus dados no 
sistema, 
RF11 Vincular modalidade instrutor O software deve cadastrar um 
ou mais instrutores a uma 
modalidade para os treinos. 
RF12 Cadastrar funcionário O software deve permitir 
cadastro de novos 
funcionários. 
RF13 Gerar horários de turmas. O software deve gerar horários 
para as turmas matriculadas. 
RF14 Gerar horários para a limpeza da 
academia. 
O software deve gerar horários 
para a limpeza da academia 
feita pelos funcionários 
encarregados. 
RF15 Realizar lançamentos de despesas O software deve lançar o 
relatório das despesas da 
academia. 
Tabela 1: requesitos funcionais do Academy manages. 
5.4 Tabela de requesitos não funcionais. 
ID Nome Texto 
RNF 01 Segurança O software deve implementar o 
controle de acesso a partir da 
permissão de cada funcionário. 
RNF 02 Identificação O software a entrada dos 
clientes e dos funcionários 
devem ser identificados por 
impressão biométrica 
RNF 03 Integração sistema de cartão O Software deve estar 
integrado ao sistema de 
operadoras de cartão de credito 
para enviar e receber 
informações para pagamento. 
RNF 04 Usabilidade O software deve ser fácil de 
usar, devendo-se evitar a 
digitação desnecessária de 
informação de modo a dar 
agilidade no processo. 
RNF 05 Disponibilidade O software deve estar 
disponível no horário de 
funcionamento da academia de 
ginástica. 
RNF 06 Portabilidade O sistema deve em operar 
diferentes sistemas 
operacionais. 
RNF07 Emitir cadastro O software deve permitir a 
consulta dos dados dos 
clientes. 
Tabela 2:representação do requisitos não funcionais do Academy manages 
 
Finalizado os diagramas de requesitos funcionais foi elaborado o diagrama de que 
requesitos não funcionais, ou seja, Esses requesitos são focados determinar não em 
determinar o que o sistema fará, mas sim com ele fará, eles dão suporte para a estrutura e 
execução do sistema. 
 
 
5.3 Diagramas de caso de uso 
 
O diagrama de caso de uso é um diagrama do tipo comportamental, ou seja, são aqueles 
são voltados a descrever o sistema computacional modelado quando em execução, isto é, 
como será foi modelado para que possa ser executado de maneira correta. São usados para 
visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema que é a 
representação das partes que “sofrem alterações”. 
 
O diagrama de caso de uso do sistema “Academy Manages” demonstracomo os atores 
usarão o sistema. São eles: o administrador da academia e o funcionário da academia. 
O administrador da academia será encarregado de atividades que requerem mais 
autoridade e permissão no controle da academia como: como cadastrar um funcionário, 
excluir um cadastro, participar e checar relatório. O funcionário será um usuário do sistema 
encarregado de atividades rotineiras e que não requerem privilégios de administrador, tais 
como: cadastrar um usuário, cadastrar uma modalidade, suspender um cadastro, entre 
outras atividades. 
Figura 4: representação do diagrama de caso de uso 
5.4 Diagrama de atividades 
Assim como o diagrama de caso de uso o diagrama de atividades também é um diagrama 
comportamental. Eles capturam ações e seus resultados. Esse diagrama foca o trabalho 
executado na implementação de uma operação (método), e suas atividades numa instância 
de um objeto. Um diagrama de atividade é uma maneira alternativa de se mostrar 
interações, com a possibilidade de expressar como as ações são executadas, o que elas 
fazem (mudanças dos estados dos objetos), quando elas são executadas (seqüência das 
ações), e onde elas acontecem. 
 
No sistema “Academy manages”, são elaboradas representações das atividades rotineiras 
que acontecem no sistema como: o fluxo de atividade para cadastrar um cliente, um 
funcionário, uma modalidade, execução de uma atividade necessária para suspender um 
cadastro ou excluí-lo, ou seja foi feito um diagrama de atividade para cada caso de uso do 
sistema. 
 
Figura 5: representação de um diagrama de atividade 
 
5.5 Diagrama de classe 
Diferentemente dos diagramas comportamentais os diagramas estruturais como o de classe, 
tratam o aspecto estrutural tanto do ponto de vista do sistema quanto das classes. Existem 
para visualizar, especificar, construir e documentar os aspectos estáticos de um sistema, ou 
seja, a representação e as estruturas que os construirão o esqueleto do sistema. 
 
Na representação do sistema “Academy manages” utilizou-se o digrama de classe para sua 
representação estrutural. Esse diagrama é destinado aos tipos de classes que estão no 
sistema, às características de cada uma, e por fim os métodos que serão utilizados para que 
se possa cumprir todas as funções destinadas à classe. Esse diagrama também é elaborado 
numa visão, na qual a partir da elaboração de suas classes e a definição de seus 
relacionamentos origina-se o banco de dados para o sistema. 
Figura 6 representação do diagrama de classe 
6. Considerações Finais 
 
O objetivo deste artigo foi apresentar todo o processo realizado para a documentação, 
construção e implementação do software Academy Manages, apresentando os artefatos 
necessários para tal. 
O primeiro passo foi identificar através de pesquisas para levantar as características 
relevantes para a construção do software, buscamos ferramentas que desses um 
suporte as características necessárias para a criação da aplicação. 
De forma geral o software proposto vai facilitar a vida do usuário e do cliente de forma a 
automatizar os processos da empresa e evitar problemas comuns que em qualquer meio 
empresarial pode eventualmente ocorrer. 
 
7. Referências 
 
Cysneiros, Luiz Marcio. Requisitos Não Funcionais: Da Elicitação ao Modelo 
Conceitual, 2012 acesso em: http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf 
acesso em 11/10/2014. 
 
EINSBERG, Eric M. e GOODALL Jr. H.L. Organiztional communication: balancing, 
creativity and constraint. Second edition. New York, USA: St Martin’s Press, 1997. 
 
KUNSCH, Margarida M. K. Planejamento de Relações Públicas na Comunicação 
Integrada. 4. ed. revisada, atualizada e ampliada. São Paulo: Summus, 2003. 
 
Pressman, R. S. Engenharia de software: Uma abordagem profissional. Tradução 
Ariovaldo Griesi, Mario Moro Fecchio; Revisão técnica Reginaldo Arakaki, Julio Arakaki, 
Renato Manzan de Andrade. -7. Ed. –Porto Alegre: AMGH, 2011 
 
MACORATTI, J. C. O Processo de Software. Disponível em: 
http://www.macoratti.net/proc_sw1.htm acesso em 12/10/2014 
 
 
PRESSMAN, Roger S. Engenharia de Software. 5º edição. Rio de Janeiro: McGrawHill, 
2002. 
 
PRESSMAN, ROGER S., Engenharia de Software- (6ª edição), São Paulo, 
Ed.McGrawHill, 2006. 
 
 
PUTMAN, Linda L., PHILIPS, Nelson e CHAPMAN, Pamela. Handbook de Estudos 
Organizacionais, Vol. 3, São Paulo, Atlas, (2004). 
 
 
SOMMERVILLE, I. Engenharia de Software.8. ed. São Paulo: Pearson Addison-Wesley, 
2007. 
 
 
Vargas, Thânia Clair de Souza, A história de UML e seus diagramas, 2010. Disponível 
em: HTTPS://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf. Acesso em 
11/10/2014.