Monografia - Amanda

CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA DE TAQUARITINGA

CURSO SUPERIOR DE TECNOLOGIA EM
PROCESSAMENTO DE DADOS
ABORDAGEM DA METODOLOGIA RUP NO

DESENVOLVIMENTO DE UM SISTEMA DE GESTÃO
COMERCIAL
AUTOR: AMANDA MAKINO
ORIENTADOR: PROF. OSWALDO LÁZARO MENDES
Taquaritinga, SP
2009
AMANDA MAKINO
ABORDAGEM DA METODOLOGIA RUP NO

DESENVOLVIMENTO DE UM SISTEMA DE GESTÃO
COMERCIAL
Monografia apresentada à Faculdade de Tecnologia de

Taquaritinga, como parte dos requisitos para a obtenção
do título de Tecnólogo em Processamento de Dados.
Orientador: Prof. Oswaldo Lázaro Mendes
Taquaritinga, SP
2009
Dedico,
Aos meus pais, que sempre lutaram e nunca mediram

esforços para me darem uma boa educação e um futuro
promissor.
AGRADECIMENTOS
Agradeço ao prof. Oswaldo Lázaro Mendes por sua total disponibilidade e tamanha
dedicação em me orientar durante o desenvolvimento deste trabalho.
Agradeço aos meus pais pela paciência que tiveram e pela força que me deram
enquanto eu desenvolvia este trabalho.
Agradeço a minha amiga Jaqueline Mistron por me ajudar com a elaboração deste
trabalho.
Agradeço a todos os profissionais, em especial ao Paulo Quicoli, pela disponibilização
de materiais e artigos na internet, que foram essenciais para a formulação deste trabalho.
“Tecnologia é a habilidade de organizar o mundo de
forma que não tenhamos que senti-lo."
Max Frisch
MAKINO, A. Abordagem da metodologia RUP no desenvolvimento de um sistema de gestão
comercial. 87 f. (Trabalho de Conclusão de Curso), Faculdade de Tecnologia de Taquaritinga,
Centro Estadual De Educação Tecnológica “Paula Souza”, Taquaritinga, 2009.
RESUMO
O presente trabalho realiza uma abordagem sobre a importância da Engenharia de

Software e da utilização de metodologias de desenvolvimento que viabilizem a criação de
sistemas com qualidade. Através da utilização da metodologia RUP em conjunto com a
Análise Orientada a Objetos e a UML, o trabalho apresenta todo o processo de
desenvolvimento de um sistema de informação, desde a fase de concepção, com a realização
análise e levantamento de requisitos, identificação de casos de uso e estimativa de esforço até
a fase de codificação.
Palavras-chaves: Engenharia de software. UML. Sistema de informação. RUP. WPF.

MAKINO, A. Abordagem da metodologia RUP no desenvolvimento de um sistema de gestão
comercial. 87 f. (Trabalho de Conclusão de Curso), Faculdade de Tecnologia de Taquaritinga,
Centro Estadual De Educação Tecnológica “Paula Souza”, Taquaritinga, 2009.
ABSTRACT
This work presents a discussion of the importance of software engineering and use of
development methodologies that enable the creation of quality systems. By using the RUP
methodology in conjunction with the Object-Oriented Analysis and UML, the paper presents
the process of developing an information system, from the design stage to the implementation
and survey analysis of requirements, identification of cases of use and cost effort until the
coding phase.
Keywords: Engineering software. UML. Information system. RUP. WPF.

SUMÁRIO
INTRODUÇÃO......................................................................................................................18
1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE..........................................19
1.1 Engenharia de Software......................................................................................................19

1.1.1 Modelos de processo de software....................................................................................20
1.2 UML....................................................................................................................................21
2 RUP - PROCESSO UNIFICADO .....................................................................................23
2.1 Características.....................................................................................................................23
2.1.1 Baseado em casos de uso.................................................................................................24
2.1.2 Centrado na arquitetura....................................................................................................24
2.1.3 Desenvolvimento iterativo e incremental........................................................................25
2.2 Conceito de realimentação e adaptação..............................................................................26
2.3 Elementos............................................................................................................................26
2.4 Fases....................................................................................................................................27
3 ESTUDO DE CASO............................................................................................................31
3.1 Ferramentas e tecnologias aplicadas...................................................................................31

3.1.1 Rational Rose Enterprise Edition ....................................................................................31
3.1.2 Visual C# 2008 Express Edition......................................................................................32
3.1.3 SQL Server Management Studio Express........................................................................32
3.1.4 NHibernate.......................................................................................................................33
3.1.5 WPF.................................................................................................................................33
3.2 Padrão de arquitetura MVVM............................................................................................35
3.2.1 View (camada de apresentação).......................................................................................35
3.2.2 Model (camada de dados)................................................................................................36
3.2.3 ViewModel (camada de vinculação)................................................................................36
3.3 Concepção...........................................................................................................................36
3.3.1 Levantamento de requisitos.............................................................................................37
3.3.2 Organização dos requisitos..............................................................................................58
3.3.3 Planejamento dos ciclos iterativos...................................................................................66
3.4 Elaboração...........................................................................................................................69
3.4.1 Expansão dos casos de uso...............................................................................................69
3.4.2 Determinação dos eventos do sistema.............................................................................74
...................................................................................................................................................78
3.4.3 Projeto da camada de domínio.........................................................................................84
3.4.4 Projeto da camada de aplicação.......................................................................................85
CONCLUSÃO.........................................................................................................................89
REFERÊNCIAS......................................................................................................................90
LISTA DE ILUSTRAÇÕES
ILUSTRAÇÃO 1: CAMADAS DA ENGENHARIA DE SOFTWARE............................19
ILUSTRAÇÃO 2: DESENVOLVIMENTO ITERATIVO E INCREMENTAL..............25
ILUSTRAÇÃO 3: FASES DO PROCESSO UNIFICADO (RUP).....................................28
ILUSTRAÇÃO 4: ARQUITETURA DO RUP....................................................................29
ILUSTRAÇÃO 5: DIAGRAMA DE CASOS DE USO DO SISTEMA.............................60
ILUSTRAÇÃO 6: DIAGRAMA DE CASO DE USO “REALIZAR LOGIN”.................61
ILUSTRAÇÃO 7: DIAGRAMA DE CASO DE USO “REALIZAR VENDA SIMPLES”

...................................................................................................................................................61
ILUSTRAÇÃO 8: DIAGRAMA DE CASO DE USO “REALIZAR VENDA

COMPLETA”.........................................................................................................................62
ILUSTRAÇÃO 9: DIAGRAMA DE CASO DE USO “ESTORNAR VENDA”...............63
ILUSTRAÇÃO 10: DIAGRAMA DE CASO DE USO “DAR BAIXA EM CONTAS A

RECEBER”.............................................................................................................................63
ILUSTRAÇÃO 11: DIAGRAMA DE CASO DE USO “ELABORAR ORÇAMENTO”64
ILUSTRAÇÃO 12: DIAGRAMA DE CASO DE USO “ORGANIZAR ESTOQUE

MÍDIA”....................................................................................................................................64
ILUSTRAÇÃO 13: DIAGRAMA DE SEQUÊNCIA “REALIZAR LOGIN”..................74
ILUSTRAÇÃO 14: DIAGRAMA DE SEQUÊNCIA “REALIZAR VENDA SIMPLES”

...................................................................................................................................................75
ILUSTRAÇÃO 15: DIAGRAMA DE SEQUÊNCIA “REALIZAR VENDA
COMPLETA”.........................................................................................................................76
ILUSTRAÇÃO 16: DIAGRAMA DE SEQUÊNCIA “ESTORNAR VENDA”................77
ILUSTRAÇÃO 17: DIAGRAMA DE SEQUÊNCIA “DAR BAIXA EM CONTAS A

RECEBER”.............................................................................................................................77
ILUSTRAÇÃO 18: DIAGRAMA DE SEQUÊNCIA “ELABORAR ORÇAMENTO”...78
ILUSTRAÇÃO 19: DIAGRAMA DE SEQUÊNCIA “ORGANIZAR ESTOQUE DE

MÍDIA”....................................................................................................................................79
ILUSTRAÇÃO 20: DIAGRAMA DE ATIVIDADES “REALIZAR LOGIN”.................79
ILUSTRAÇÃO 21: DIAGRAMA DE ATIVIDADES “REALIZAR VENDA SIMPLES”

...................................................................................................................................................80
ILUSTRAÇÃO 22: DIAGRAMA DE ATIVIDADES “REALIZAR VENDA

COMPLETA”.........................................................................................................................81
ILUSTRAÇÃO 23: DIAGRAMA DE ATIVIDADES “ESTORNAR VENDA”...............82
ILUSTRAÇÃO 24: DIAGRAMA DE ATIVIDADES “ELABORAR ORÇAMENTO”. 82
ILUSTRAÇÃO 25: DIAGRAMA DE ATIVIDADES “DAR BAIXA EM CONTAS A

RECEBER”.............................................................................................................................83
ILUSTRAÇÃO 26: DIAGRAMA DE ATIVIDADES “ORGANIZAR ESTOQUE DE

MÍDIA”....................................................................................................................................83
ILUSTRAÇÃO 27: DIAGRAMA DE CLASSES................................................................84
ILUSTRAÇÃO 28: TELA DE LOGIN.................................................................................85

ILUSTRAÇÃO 29: TELA DE CONFIGURAÇÃO DO SISTEMA...................................85
ILUSTRAÇÃO 30: TELA PRINCIPAL..............................................................................86
ILUSTRAÇÃO 31: TELA DE CONSULTA DE VENDAS (COM OPERAÇÃO DE

ESTORNO)..............................................................................................................................86
ILUSTRAÇÃO 32: TELA DE CADASTRO DE VENDA SIMPLES...............................87
ILUSTRAÇÃO 33: TELA DE CADASTRO DE CLIENTE..............................................87
ILUSTRAÇÃO 34: TELA DE CADASTRO DE VENDA COMPLETA..........................87
ILUSTRAÇÃO 35: TELA DE CADASTRO DE ORÇAMENTO.....................................88
ILUSTRAÇÃO 36: TELA DE CONSULTA DE CONTAS A RECEBER (COM

OPERAÇÃO DE BAIXA)......................................................................................................88
ILUSTRAÇÃO 37: TELA DE ORGANIZAÇÃO DE ESTOQUE DE MÍDIA................88

LISTA DE QUADROS
QUADRO 1: REALIZAR LOGIN.......................................................................................40
QUADRO 2: CONFIGURAR DADOS DE CONEXÃO....................................................40
QUADRO 3: CONFIGURAR JANELA PRINCIPAL.......................................................41
QUADRO 4: CADASTRAR USUÁRIO..............................................................................41
QUADRO 5: CONFIGURAR CONTA USUÁRIO............................................................42
QUADRO 6: CADASTRAR TIPO DE OBSERVAÇÃO...................................................42
QUADRO 7: CADASTRAR STATUS DE CLIENTE.......................................................43
QUADRO 8: CADASTRAR STATUS DE VENDA...........................................................43
QUADRO 9: CADASTRAR SERVIÇO..............................................................................44
QUADRO 10: CADASTRAR FORNECEDOR...................................................................44
QUADRO 11: CADASTRAR PRODUTO..........................................................................45
QUADRO 12: CADASTRAR CLIENTE.............................................................................45
QUADRO 13: CADASTRAR OBSERVAÇÕES DO CLIENTE......................................46
QUADRO 14: CADASTRAR META...................................................................................46
QUADRO 15: CADASTRAR ORÇAMENTO....................................................................47
QUADRO 16: IMPRIMIR ORÇAMENTO.........................................................................47

QUADRO 17: CADASTRAR VENDA SIMPLES...............................................................48
QUADRO 18: CADASTRAR VENDA COMPLETA.........................................................49
QUADRO 19: IMPRIMIR ETIQUETA...............................................................................51
QUADRO 20: CADASTRAR MÍDIAS DA VENDA..........................................................51
QUADRO 21: CADASTRAR MOVIMENTAÇÕES DA VENDA....................................52
QUADRO 22: CADASTRAR MOVIMENTAÇÃO DE CAIXA........................................52
QUADRO 23: CADASTRAR CONTAS A PAGAR............................................................53
QUADRO 24: CADASTRAR CONTAS A RECEBER......................................................54
QUADRO 25: CADASTRAR MÍDIAS DIGITAIS.............................................................54
QUADRO 26: IMPRIMIR RELATÓRIO DE CLIENTES................................................55
QUADRO 27: IMPRIMIR RELATÓRIO DE VENDAS....................................................55
QUADRO 28: IMPRIMIR RELATÓRIO DE CONTAS A PAGAR................................56
QUADRO 29: IMPRIMIR RELATÓRIO DE CONTAS A RECEBER...........................56
QUADRO 30: VISUALIZAR GRÁFICO ESTATÍSTICO DE VENDAS........................57
QUADRO 31: VISUALIZAR GRÁFICO ESTATÍSTICO DE DESEMPENHO............57
QUADRO 32: VISUALIZAR LOGS DE AÇÃO DOS USUÁRIOS..................................57
QUADRO 33: REQUISITOS SUPLEMENTARES............................................................58
QUADRO 34: LISTAGEM DE CASOS DE USO DA FASE DE CONCEPÇÃO............59

QUADRO 35: LISTAGEM DE CONCEITOS E OPERAÇÕES DE MANUTENÇÃO..65
QUADRO 36: LISTAGEM DE CONSULTAS....................................................................66
QUADRO 37: PLANEJAMENTO EM CICLOS ITERATIVOS......................................67
QUADRO 38: CRONOGRAMA DE EXECUÇÃO.............................................................68
QUADRO 39: CASO DE USO EXPANDIDO “REALIZAR LOGIN”.............................69
QUADRO 40: CASO DE USO EXPANDIDO “REALIZAR VENDA SIMPLES”.........70
QUADRO 41: CASO DE USO EXPANDIDO “REALIZAR VENDA COMPLETA”....70
QUADRO 42: CASO DE USO EXPANDIDO “ESTORNAR VENDA”...........................71
QUADRO 43: CASO DE USO EXPANDIDO “DAR BAIXA EM CONTAS A

RECEBER”.............................................................................................................................72
QUADRO 44: CASO DE USO EXPANDIDO “ELABORAR ORÇAMENTO”..............72
QUADRO 45: CASO DE USO EXPANDIDO “ORGANIZAR ESTOQUE DE MÍDIA”

...................................................................................................................................................73
LISTA DE SIGLAS
2D – Duas Dimensões
3D – Três Dimensões
CASE - Computer-Aided Software Enginering
CNPJ – Cadastro Nacional da Pessoa Jurídica
CPF – Cadastro de Pessoa Física
IBM - International Business Machines
IDE - Integrated Development Environment
LOB - Line-Of-Business
MVC - Model-View-Controler
MVP - Model-View-Presenter
MVVM - Model-View-ViewModel
OO - Orientação a Objetos
PU - Processo Unificado
RG - Registro Geral
RUP - Rational Unified Process
SGC - Sistema de Gerenciamento Comercial
SQL - Structured Query Language
TI - Tecnologia da Informação
UML - Unified Modeling Language
WPF - Windows Presentation Foundation
WPF/E - Windows Presentatiom Foundation Everywhere
XAML - Extended Application Markup Language
XHTML - Extensible Hypertext Markup Language
XML - Extended Markup Language
18
INTRODUÇÃO
Desenvolver software é uma tarefa complexa, cujo sucesso é determinado por

inúmeros fatores que ocorrem durante o desenvolvimento. É muito comum encontrar
softwares que não atendem às reais necessidades dos clientes, apresentam tendências a erros,
são difíceis de se usar e modificar e, ainda assim, foram concluídos com prazos e orçamentos
estourados. Isso geralmente acontece devido à falta de disciplina na elaboração e construção
do software, ou seja, devido à falta de uma abordagem de engenharia.
Com a aplicação das técnicas de engenharia de software é possível construir um
software de maior qualidade, que satisfaça todas as necessidades de clientes e usuários, sem
apresentar falhas ou erros, e seja fácil de usar e modificar.
Segundo Pressman (2006, p. 25), modelos de processo de software, métodos de
engenharia de software e instrumentos de software tem sido adotados com sucesso em um
amplo espectro de aplicações na indústria.
Dessa forma, o presente trabalho visa utilizar as melhores técnicas de engenharia de
software na construção de um sistema de gestão comercial. Com base na aplicação da
metodologia de processo unificado, o trabalho segue apresentando todos os artefatos
elaborados durante o desenvolvimento, como os requisitos funcionais e não funcionais, casos
de uso, relação de conceitos e manutenções, cronograma, diagramas de sequência, diagramas
de atividades, diagrama de classes e protótipos do sistema.
O trabalho é dividido em três partes, no primeiro capítulo é apresentada a engenharia
de software e seus modelos de processo de software e a linguagem de modelagem UML. O
segundo capítulo aborda a metodologia de processo unificado, apresentando suas principais
características, conceitos, elementos e fases. E a partir do terceiro capítulo é detalhado o caso
de uso em si, expondo as principais necessidades de um estabelecimento comercial e
apresentando todo o processo de concepção e elaboração do sistema, e as ferramentas e
tecnologias utilizadas, bem como o padrão de arquitetura escolhido.
19
1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
1.1 Engenharia de Software
A Engenharia de Software é um conjunto de métodos, ferramentas, procedimentos e

paradigmas que tem por objetivo produzir softwares eficientes, de alta qualidade, com baixa
taxa de erros e que atendam às necessidades e expectativas do usuário. Para Sommerville
(2003) ela “envolve questões técnicas e não técnicas, tais como especificação do
conhecimento, técnicas de projeto e codificação, conhecimentos dos fatores humanos pelo
engenheiro de software e ainda, gestão de projetos”.
Conforme mostra a ilustração 1, a Engenharia de Software é definida em camadas.
Ilustração 1: Camadas da Engenharia de Software

Fonte: Adaptada de Alejandro Fernandez Moraga (2007)
A base na qual se apóia é o foco na qualidade. O alicerce é a camada de processo que,

segundo Pressman (2006, p. 24) forma a base para o controle gerencial de projetos e
estabelece o contexto no qual os métodos são aplicados, os produtos de trabalho são
produzidos, os marcos estabelecidos, a qualidade é assegurada e as alterações geridas.
Os métodos de engenharia de software contemplam o modo de construir softwares e
abrangem um amplo conjunto de tarefas como comunicação, análise de requisitos,
modelagem de projeto, construção de programas, testes e manutenção.
20
Por fim, as ferramentas referem-se aos instrumentos ou sistemas automatizados que

fornecessem apoio aos processos e aos métodos.
1.1.1 Modelos de processo de software
O processo de software pode ser definido como uma coleção de padrões que definem
um conjunto de atividades, ações, tarefas de trabalho, produtos de trabalho e/ou
comportamentos relacionados (AMB, 1998).
Existem vários modelos de processo que prescrevem um fluxo de trabalho¹, ou seja, a
maneira como os elementos do processo se relacionam. Dentre os principais modelos estão:
• Modelo em cascata
• Modelo incremental
• Modelo evolucionário
• Modelo espiral
• Modelo de desenvolvimento concorrente
• Modelo especializado de processo
• Processo unificado
Embora existam vários modelos de processo, todos apresentam atividades comuns

como: especificação (levantamento de requisitos e restrições de software), desenvolvimento
(projeto e codificação), validação (realização de testes) e evolução (evolução do software
conforme as necessidades do cliente). O que os diferencia é que cada um aplica uma ênfase
diferente a essas atividades, definindo um fluxo de trabalho que invoca cada atividade de
maneira diferente.
O modelo de processo escolhido para a formulação deste trabalho foi o Processo
Unificado e por isso receberá uma maior atenção no decorrer deste trabalho. Pelo fato
desse processo, assim como outros, estar fortemente associado à notação UML, uma breve
apresentação desta é valida antes de se dar continuidade ao estudo.
1.2 UML
A UML (Unified Modeling Language) é uma linguagem de modelagem visual

utilizada para especificar, documentar, visualizar e construir artefatos de um sistema. Tem
como objetivo modelar sistemas de forma correta e consistente com o auxílio dos conceitos da
orientação a objeto, tornando real a possibilidade de métodos conceituais também serem
executáveis.
Segundo Page-Jones (2001), ela “consegue capturar a estrutura de sistemas OO em um
nível acima das linhas individuais de código, e pode ser expressa em diagramas que englobam
a gama de construções que aparecem em sistemas OO”.
A UML apresenta três benefícios principais (FURLAN, 1998):
• Visualização: os relacionamentos existentes entre os diversos
componentes da aplicação podem ser visualizados de forma a
antever o produto final;
• Gerenciamento da complexidade: cada aspecto do sistema é
desenhado à parte em um modelo específico para que se possa
estudar e compreender a estrutura, o comportamento e os possíveis
particionamentos físicos, bem como identificar oportunidades de
reutilização de componentes;
• Comunicação: através da utilização de símbolos e padrões, torna-
se possível uma comunicação direta e não ambígua entre os
participantes do projeto em relação aos detalhes de
comportamento do sistema.
A UML é utilizada pelas fases de análise de requisitos, análise e projeto e oferece a
elas cinco tipos de visões que destacam os diferentes aspectos do sistema que está sendo
modelado. São elas: visão use-case, visão lógica, visão de componentes, visão de
concorrência e visão de organização.
Além disso, a UML disponibiliza nove tipos de diagramas que descrevem o conteúdo
em uma visão e são utilizados em combinação para prover todas as visões do sistema. Esses
diagramas são: diagrama de caso de uso, diagrama de classe, diagrama de objeto, diagrama de
estado, diagrama de sequência, diagrama de colaboração, diagrama de atividade, diagrama de
componente e diagrama de execução.
Por volta de 1997, a UML tornou-se uma norma industrial para o desenvolvimento de
softwares orientados a objetos. Mas, apesar de fornecer a tecnologia necessária para apoiar a
prática de engenharia de software orientada a objetos, ela não guia as equipes de projeto na
aplicação da tecnologia. Cabe ao processo realizar essa tarefa.
2 RUP - PROCESSO UNIFICADO
O Processo Unificado ou Rational Unified Process (RUP²) é uma metodologia de

análise e desenvolvimento de sistemas orientados a objeto baseada na notação UML.
O RUP é um processo bem definido e estruturado, pois define claramente quem é
responsável pelo que, como as coisas devem ser feitas e quando. Ele utiliza a UML para
especificar, modelar e documentar artefatos, e pelo fato de ser flexível e configurável, pode
ser utilizado em projetos de pequeno, médio e grande porte.
O processo unificado tem como principais princípios (MARTINS, 2007):
• Atacar os riscos antecipadamente e continuamente;
• Certificar-se de entregar algo de valor ao cliente;
• Focar no software executável;
• Acomodar mudanças antecipadas;
• Liberar um executável da arquitetura antecipadamente;
• Construir o sistema com componentes;
• Trabalhar junto como uma equipe;
• Fazer da qualidade um estilo de vida, não algo para depois.
Dessa forma, pode-se dizer que o RUP procura não só se apoiar nos melhores recursos
e características dos modelos convencionais, como também implementar muito dos melhores
princípios de desenvolvimento ágil.
2.1 Características
O Processo Unificado reconhece a importância da comunicação com o cliente e dos

métodos diretos para descrever a visão do cliente de um sistema (caso de uso). Ele
enfatiza o importante papel da arquitetura de software e ajuda o arquiteto a se
concentrar nas metas corretas, tais como compreensibilidade, abertura a
modificações futuras e reuso. O fluxo de processo é iterativo e incremental, dando a
sensação evolucionária que é essencial no desenvolvimento moderno do software.
(PRESSMAN, 2006, p.51).
Dessa forma, as principais características do processo unificado são:

• Ser baseado em casos de uso;
• Ser centrado na arquitetura;
• Utilizar o desenvolvimento iterativo e incremental.
_________________________
2 O Processo Unificado também é chamado de RUP (Rational Unified Process) devido ao fato da Rational
Corporation ter sido uma contribuinte pioneira para o desenvolvimento e refinamento do processo e construtora
de ambientes completos (ferramentas e tecnologias) que apoiam o processo.
24
2.1.1 Baseado em casos de uso
Um caso de uso é a descrição de uma sequência de ações realizadas por um ator

(pessoa, máquina ou sistema), que ocorrem enquanto o ator interage com o sistema. Casos de
uso ajudam a identificar o escopo do projeto e fornecem base para o planejamento do projeto
de software.
O processo unificado utiliza os casos de uso para dirigir todo o processo de
desenvolvimento, desde a concepção inicial do sistema até a aceitação dos componentes
(testes), com o objetivo de atender, especificamente, às necessidades dos usuários que
interagem com o sistema.
O RUP é orientado a casos de uso pelo fato deles não estarem ligados apenas à
especificação de requisitos, mas também ao projeto, implementação e testes do sistema, pois:
• Por meio deles é que são registrados os requisitos funcionais;
• Eles auxiliam no planejamento das iterações;
• Eles podem conduzir o projeto;
• Os testes do sistema são baseados neles.
2.1.2 Centrado na arquitetura
A arquitetura baseia-se na visão de todos os modelos, ou seja, na visão do sistema

como um todo, destacando suas principais características sem entrar em detalhes.
Muitos fatores influenciam na arquitetura do projeto, como por exemplo, a plataforma
na qual o software será implantado, os requisitos funcionais e não funcionais, entre outros.
Os casos de uso relacionam-se com a funcionalidade do sistema, enquanto a
arquitetura está ligada à forma deste. Para que se alcance um produto final com qualidade, é
necessário que a funcionalidade e a forma estejam balanceadas. Dessa forma, é necessário que
a arquitetura e os casos de uso estejam relacionados a tal ponto que os primeiros sejam
desenvolvidos de acordo com a arquitetura e esta por sua vez, forneça um ambiente para que
todos os requisitos dos casos de uso sejam realizados.
25
2.1.3 Desenvolvimento iterativo e incremental
Visto que o modelo cascata podia ser usado com sucesso em pequenos projetos,
tornou-se prático dividir projetos grandes em projetos menores. Foi desse contexto que surgiu
o método iterativo e incremental.
O desenvolvimento iterativo e incremental baseia-se em refinamentos e incrementos
sucessivos, a fim de produzir um sistema adequado. A cada iteração o sistema é incrementado
com base na experiência obtida nas iterações anteriores e no feedback do usuário. Cada
iteração é considerada um miniprojeto, desenvolvido com base no modelo cascata, no qual
são realizadas as atividades de identificação de requisitos, análise, projeto, implementação e
testes (Ilustração 2). Quando uma iteração atinge o seu objetivo, o desenvolvimento prossegue
para a próxima iteração e, assim, sucessivamente, até que o ciclo de vida termine.
Ilustração 2: Desenvolvimento iterativo e incremental

Fonte: Adaptada de Celio Oliveira Carçalto (2008)
As iterações tem como resultado um sistema que, apesar de incompleto, foi testado e
integrado possuindo qualidade de produto final. Atualmente esse paradigma de
desenvolvimento é bem aceito e vem sendo utilizado por várias metodologias de
desenvolvimento de software devido às suas grandes vantagens como:
• Reduzir o risco de custo do projeto. Caso os desenvolvedores precisem repetir uma
iteração, o esforço perdido será dedicado apenas à iteração e não ao sistema como um
todo;
26
• Reduzir o risco de violação de prazos. O fato de identificar problemas no início do

desenvolvimento permite que os desenvolvedores aloquem tempo para resolvê-los
sem extrapolar prazos;
• Acelerar o tempo de desenvolvimento do projeto. Os desenvolvedores trabalham em
escopos pequenos e claros, o que torna o desenvolvimento ágil e eficiente.
• Ter consciência de que os requisitos não podem ser completamente definidos no início
do desenvolvimento, que devem ser refinados em sucessivas iterações. Este modo de
operação torna mais fácil a adaptação do sistema a mudanças dos requisitos.
2.2 Conceito de realimentação e adaptação
Ao invés de combater as inevitáveis mudanças que ocorrem no decorrer do

desenvolvimento do software, principalmente na etapa de definição de requisitos, o ideal do
PU é considerar as mudanças e a adaptações como fatores inevitáveis e essenciais. Dessa
forma, se vê contra a tentativa de especificar completa e corretamente o sistema de uma só
vez, criando um conjunto estagnado de requisitos.
No PU, a cada iteração é escolhido um pequeno conjunto de requisitos, que são
rapidamente projetados, codificados e testados pelos usuários, o que leva a uma realimentação
rápida, baseada em dados concretos de usuários, desenvolvedores e testes, que possibilita
modificar ou adaptar a compreensão dos requisitos. Os usuários finais podem ver um sistema
parcial, utilizá-lo e assim serão capazes de realizar críticas construtivas do sistema.
Essas avaliações e detecções de falhas não representam um erro e sim, um modo
prático de descobrir o que é de real valor aos interessados no projeto. , além de
possibilitar uma melhora na compreensão dos requisitos, também possibilita verificar
se o projeto está no caminho certo ou se, por exemplo, alguma mudança na arquitetura
deve ser feita.
2.3 Elementos
O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de

trabalho e disciplinas. Os papéis referem-se às responsabilidades de um determinado
indivíduo ou grupo de indivíduos dentro de uma equipe, eles caracterizam os perfis dos
profissionais envolvidos no projeto (analistas de sistema, projetistas etc).
27
As atividades representam as ações necessárias e importantes realizadas durante o

processo de desenvolvimento do software. Como exemplos de atividades pode-se citar:
planejamento de iterações, definição de casos de uso e atores, revisão do projeto, realização
de testes de performance, entre outras.
Artefatos são elementos produzidos durante o processo de desenvolvimento do
projeto. Como exemplo de artefatos, tem-se: modelos, documentos, código fonte, executáveis,
entre outros.
Para que os artefatos sejam produzidos de tal forma que acrescentem valor ao projeto,
é necessário seguir uma sequência de desenvolvimento das atividades. Essa sequência é
chamada de fluxo de trabalho. Os fluxos de trabalho são representados pelos diagramas de
sequência, colaboração e atividade da UML. O processo unificado utiliza três tipos de fluxos
de trabalho:
• Fluxos de trabalho principais, que estão associados a cada disciplina;
• Fluxos de trabalho de detalhe, que detalha cada fluxo principal;
• Planos de iteração, que especificam o modo como a iteração deve ser executada;
Por fim as disciplinas referem-se a um conjunto de atividades que fazem parte de um
contexto comum dentro do projeto. Com as disciplinas, há um melhor entendimento do
projeto sob a visão tradicional do modelo sequencial. O processo unificado possui nove
disciplinas, que estão divididas entre disciplinas de processo (modelagem de negócios,
requisitos, análise e design, implementação, teste e implantação) e disciplinas de suporte
(gerenciamento de configuração e mudança, gerenciamento de projeto e ambiente).
2.4 Fases
O Processo Unificado comporta as atividades de comunicação, planejamento,

modelagem, construção e implantação, porém as organiza de maneira diferente, apresentando
quatro fases distintas: concepção, elaboração, construção e transição. A Ilustração 3 mostra a
relação dessas atividades com as fases do RUP.
28
Ilustração 3: Fases do processo unificado (RUP)

Fonte: Adaptada de PRESSMAN (2006)
A fase de concepção ou iniciação abrange as atividades de comunicação com o cliente

e de planejamento. É nessa etapa que o analista faz o primeiro contato com o cliente em busca
das primeiras informações sobre o sistema a ser desenvolvido, com o objetivo de identificar
os requisitos, definir o escopo do sistema e dar início ao planejamento. O planejamento é
composto pela avaliação da viabilidade de implantação do sistema, dos recursos e dos
principais riscos que devem ser gerenciados ao longo do projeto, pela elaboração de um
rascunho da arquitetura do sistema e pela definição do cronograma e do custo do projeto.
A fase de elaboração inclui planejamento e atividades de modelagem do processo. É
nela que ocorre a expansão e o refinamento dos casos de uso elaborados pela fase de
concepção. Nessa fase também existe a preocupação de avaliar os riscos técnicos e
arquiteturais, incluindo cinco visões diferentes do software: o modelo de casos de uso, o
modelo de análise, o modelo de projeto, o modelo de implementação e o modelo de
implantação. Ao fim dessa fase, espera-se que a maior parte dos requisitos esteja detalhada, o
núcleo do sistema implementado com qualidade e os principais riscos tratados. Dessa forma,
será possível elaborar estimativas mais realistas.
29
A fase de construção tem como objetivo desenvolver os componentes de software que

tornam os casos de uso operacionais para os usuários finais. Para isso, os modelos de análise e
projeto que foram iniciados durante a fase de elaboração são completados e os componentes
são implementados conforme os requisitos levantados para o incremento de software
referente. Além disso, conforme os componentes são implementados, são realizados testes
unitários e atividades de integração. Por fim, antes de passar para a fase seguinte, são
realizados testes de aceitação conforme as especificações dos casos de uso.
A fase de transição abrange os últimos estágios do processo e a primeira parte de
implantação. Nela, o software é implantado no cliente para testes e com o intuito de se ter um
feedback dos usuários em relação aos defeitos e modificações que se achem necessárias. Além
disso, são elaboradas informações de apoio, como manuais, guias de solução de problemas e
procedimentos de instalação. Ao final da fase de transição, o incremento de software torna-se
uma versão utilizável e de qualidade.
A Ilustração 4 apresenta a relação entre as fases, elementos e disciplinas do RUP
dentro de sua arquitetura:
Ilustração 4: Arquitetura do RUP

Fonte: MARTINS (2007)
Conforma a ilustração 4, o RUP apresenta duas dimensões: o eixo horizontal

representa o tempo e o aspecto dinâmico do processo. Para isso, detalha os aspectos do ciclo
30
de vida do processo à medida que ele é desenvolvido, através da apresentação das fases,
marcos e iterações do processo.
O eixo vertical representa as disciplinas, pelas quais as atividades são organizadas de
forma lógica e estrutural. Pelo eixo vertical, o aspecto estático do processo é representado, por
meio de descrições em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papéis.
31
3 ESTUDO DE CASO
O estudo de caso do sistema de gestão comercial M System foi realizado a partir da

aplicação da metodologia de processo unificado.
Esse capítulo visa abordar todo o processo de desenvolvimento do sistema M System,
apresentando todos os artefatos gerados pelas fases de concepção e elaboração, assim como os
resultados da fase de construção do software. Além disso, irá abordar todas as tecnologias e
ferramentas utilizadas no desenvolvimento da aplicação.
3.1 Ferramentas e tecnologias aplicadas
Dentre as ferramentas utilizadas estão: Rational Rose Enterprise Edition, utilizada para
visualização, modelagem e documentação do projeto, o SQL Server Management Studio
Express utilizado para o gerenciamento do banco de dados, o Visual C# 2008 Express Edition
utilizado para implementar a aplicação e o NHibernate para a realização do mapeamento
objeto-relacional.
A tecnologia empregada no desenvolvimento do sistema foi o Windows Presentation
Foundation (WPF), que possibilitou a criação de interfaces mais ricas.
3.1.1 Rational Rose Enterprise Edition
Rational Rose Enterprise Edition é uma ferramenta CASE (Computer-Aided Software

Enginering) que suporta o processo unificado (RUP). Criada pela Rational e posteriormente
adquirida pela IBM, a ferramenta Rational Rose é uma das mais utilizadas entre os
profissionais e empresas do mercado no processo de modelagem de software.
Com ela é possível realizar a modelagem visual utilizando os nove diagramas da UML
(diagrama de casos de uso, diagrama de classes, diagrama de componentes, diagrama de
desenvolvimento, diagrama de objetos e diagrama de atividades). Além disso, construir
32
modelos de dados e também exportar para construção da base de dados ou realizar engenharia
reversa.
Ela permite identificar requisitos e informações levantadas durante a fase de
concepção, visualizar os relacionamentos entre os componentes do sistema e o modo como
interagem entre si, de forma a não entrar em detalhes específicos, e a comunicação entre o
pessoal da equipe desenvolvimento através de uma linguagem gráfica comum a todos.
3.1.2 Visual C# 2008 Express Edition
Visual C# 2008 Express Edition é uma ferramenta gratuita disponibilizada pela

Microsoft que oferece um ambiente integrado de desenvolvimento (IDE) utilizado para a
criação de aplicativos para desktop (Windows Forms), internet (Web) e celulares (Mobile).
A função do Visual C# 2008 Express Edition é aprimorar o processo de
desenvolvimento, tornando o trabalho de criação mais simples e produtivo para o
desenvolvedor. Para isso, disponibiliza vários recursos que facilitam e agilizam o processo de
desenvolvimento, como editores de código eficientes, assistentes, Intellisense, entre outros.
3.1.3 SQL Server Management Studio Express
SQL Server Management Studio Express é uma ferramenta gráfica gratuita e fácil de
usar. Ela possibilita o gerenciamento do SQL Server 2005 Express Edition de forma simples e
prática.
O SQL Server 2005 Express Edition, por sua vez, é uma plataforma gratuita de banco
de dados baseada nas tecnologias do SQL Server 2005, o qual possui características de rede e
segurança.
33
3.1.4 NHibernate
O NHibernate é a versão do framework de mapeamento objeto relacional Hibernate

para a plataforma .NET. Ela fornece serviços de mapeamento objeto-relacional,
transformando dados de um objeto em uma linha de uma tabela no banco de dados relacional,
ou de forma inversa, transformando uma linha da tabela em um objeto para aplicação
orientada a objetos.
O NHibernate gera o código Structured Query Language (SQL) necessário,
certificando-se que os tipos e o valores são corretamente criados, evitando-se assim a
necessidade de implementação de todo o código de acesso a dados.
3.1.5 WPF
Para dar início à apresentação da tecnologia WPF foram consideradas algumas

evoluções presentes na área tecnológica, como a evolução das placas de vídeo, dos monitores
e dos usuários.
As placas de vídeo evoluíram durante esses anos. As aplicações atuais, com exceção
daquelas voltadas para jogos, não aproveitam o poder de processamento das placas de vídeo
atuais. O WPF veio para mudar isso, pois as aplicações desenvolvidas utilizando a tecnologia
aproveitam ao máximo o poder de processamento das placas, fazendo com que o processador
seja liberado para realizar outras tarefas.
Os monitores também evoluíram, hoje chegam a altas resoluções. As aplicações atuais
não estão preparadas para alta resolução, pois são baseadas em pixels. O WPF resolve essa
questão, pois os aplicativos desenvolvidos são tratados de forma vetorial, permitindo um
escalonamento visual dos objetos através de um sistema de endereçamento de pixels
independente da resolução do monitor.
Além disso, quem evoluiu também foi o usuário. Antigamente os usuários se
contentavam com sistemas de visual simples, que apresentavam telas pretas e caracteres
brancos, hoje com a evolução da tecnologia da informação (TI), os usuários prezam por um
sistema com visual agradável e de usabilidade maior. O WPF permite isso, a partir do
desenvolvimento de aplicações com interfaces mais ricas.
34
Trata-se de um novo modelo para criação de interfaces gráficas, destinado a clientes

sofisticados e exigentes. Ele separa código fonte e o design da interface, permitindo
independência entre eles.
O WPF possui uma série de funções nativas que permitem criar um conjunto de
formulários sofisticados, contendo recursos como elementos 2D e 3D, animações, vídeo,
gráficos, layout, documentos, segurança, bem como um poderoso e flexível mecanismo de
acesso a dados.
Dessa forma, pode-se dizer que o WPF combina o melhor do antigo mundo de
desenvolvimento Windows com inovações para construções modernas e interfaces de usuário
graficamente ricas e seguras.
Segundo Soninno (2006) as principais características do WPF são:
• Flexibilidade da interface, que pode ser independente do código: podemos ter
duas apresentações completamente diferentes compartilhando o mesmo
comportamento;
• Incorpora todas as funções do .NET 2.0, acrescentando às interfaces novos
recursos como 3D, animações, gráficos vetoriais, reconhecimento de voz,
layouts avançados, entre outros;
• Leva para o desktop o conceito já existente na Web de separação entre o design
e o código, permitindo que a interface seja criada por um designer e o código
por um programador especializado, de maneira independente;
• Usa os recursos do sistema operacional, de maneira a otimizar a performance da
interface para o hardware do usuário;
• Os controles podem ser personalizados a qualquer nível que se queira, por
exemplo, podemos criar um botão não retangular que contém uma animação
3D, sem a necessidade de escrever código para isso;
• É independente de plataforma; o mesmo código-fonte funciona tanto na web
quanto para desktop e, no futuro poderá ser distribuído até em sistemas como
Mac, Linux e celulares, usando o WPF/E (WPF Everywhere, que está em
desenvolvimento).
Um programa que utiliza a tecnologia WPF é normalmente composto por duas partes
básicas: um arquivo XML (Extended Markup Language), que possui características especiais
e é chamado de XAML (abreviação para Extended Application Markup Language e
pronunciado “zémmel”), e um código para .NET escrito em qualquer linguagem compatível
como VB.net, C# etc. O arquivo XAML contém as diretrizes de interface e pode ser
comparado ao XHTML em relação ao ASP.net.
35
3.2 Padrão de arquitetura MVVM
O padrão de arquitetura adotado para o sistema M System foi o padrão Model-View-

ViewModel (MVVM), um padrão derivado dos padrões Model-View-Presenter (MVP) e
Model-View-Controller (MVC), que foi disseminado pela comunidade de desenvolvimento
em WPF da Microsoft.
Diferente das views dos outros patterns, as views no padrão MVVM possuem
inteligência e vida própria, pois apesar de ter seus estados manipulados e definidos pela
ViewModel, ela é capaz de manipular as propriedades da ViewModel através de bindings. Por
isso o padrão MVVM (Model-View-ViewModel) é considerado o padrão ideal para
aplicações WPF.
Separando melhor as camadas do padrão MVVM:
• View: composição de XAML e C# que manipula estados do XAML.
• Model: assim como as Models dos padrões MVC e MVP, define as chamadas
de regras de negócio para exibição.
• ViewModel: camada que prepara os dados recebidos da Model para exibição
no XAML.
3.2.1 View (camada de apresentação)
A View é composta de classes que representam a interface gráfica exibida ao usuário.

Cada classe contém os controles visuais que serão mostrados ao usuário, podendo conter
também animações, aspectos de navegação, temas e outras funcionalidades interativas com o
propósito da apresentação visual. No WPF, as classes da View contam com bindings que
identificam os dados a serem exibidos ao usuário (embutidos no XAML). O binding aponta
para o nome das propriedades de dados, mas não tem conhecimento de onde elas estão, nem
de onde vieram. Os bindings são ativados quando o DataContext de uma classe da View é
direcionado para outra (da camada de ViewModel) que contém a fonte para eles.
36
3.2.2 Model (camada de dados)
É representada por classes que apresentam os dados de uma entidade específica. Por
exemplo, a classe Cliente com as propriedades Nome, Rg, CPF etc. Uma classe Model
também pode conter outras classes Models (filhos), permitindo por exemplo, que a classe
Cliente possua filhos do tipo Venda. O propósito do Model é representar os dados, não tendo
conhecimento de onde eles serão apresentados para um usuário, nem mesmo se eles serão
mostrados. A simples responsabilidade é a representação.
3.2.3 ViewModel (camada de vinculação)
Representa a ligação entre a View e o Model. O DataContext da View é vinculado a

uma instância de uma classe do ViewModel. É nela que todos os bindings do XAML da View
são declarados. O ViewModel contém o Model, dessa forma possui todos os dados
necessários em diversos casos. O ViewModel pode também declarar propriedades públicas
para comandos (Commands), que são maneiras de invocar ações da View para o ViewModel,
e também outras propriedades que podem ser vinculadas à View e alteradas por ela, o padrão
MVVM permite isso.
O padrão MVVM é hoje o mais utilizado em aplicações LOB (Line-Of-Business) com
WPF, porque ele permite criar de maneira fácil aplicações bem estruturadas usando recursos
do WPF como databinding e templates.
3.3 Concepção
As atividades da fase de concepção foram divididas em três etapas:

1. Levantamento de requisitos
2. Organização dos requisitos
3. Planejamento do desenvolvimento
37
3.3.1 Levantamento de requisitos
A etapa de levantamento de requisitos tem como objetivo coletar todas as informações

relevantes sobre as funções do sistema e as regras de negócio sob as quais ele deve operar.
Nessa fase foram produzidos três documentos importantes ao desenvolvimento do sistema
SGC M System: o cenário atual, listando as características e deficiências apresentadas pelo
sistema adotado pela empresa atualmente, a visão geral do sistema e os requisitos funcionais e
não funcionais do sistema.
3.3.1.1 Cenário atual
A Vídeo Arte é uma loja de fotografias que oferece vários serviços como revelação,
estúdio, produção e restauração de fotos, cobertura de festas e casamentos, entre outros. O seu
maior problema está no gerenciamento das informações, que é realizado manualmente, a
partir de anotações e alimentação de planilhas eletrônicas.
As vendas são feitas utilizando blocos de anotações e depois são transcritas para uma
planilha eletrônica. Cada funcionário possui a sua planilha e estas não estão ligadas à planilha
de controle de caixa, cabendo a um dos funcionários a tarefa de coletar e repassar os dados
contidos nas planilhas de venda para a planilha de controle de caixa no final do dia. Todas
essas rotinas acabam deixando o processo totalmente sujeito a inconsistências,
impossibilitando a empresa de obter um controle preciso de seu faturamento e das
informações necessárias para a tomada de decisões sobre seu negócio.
A loja não possui cadastro de clientes e por isso é necessário que o funcionário solicite
e grave as informações do cliente a cada serviço prestado, o que pode gerar inconsistência e
duplicidade de informações. Além disso, o controle dos clientes inadimplentes ou que
solicitaram o serviço e não retiraram o produto depende somente da memória dos gerentes, o
que gera problemas de atrasos de pagamento.
Outro problema que a empresa enfrenta está relacionado à localização de arquivos
digitais. Cada serviço produzido pela loja é armazenado em uma mídia e essa informação é
salva na planilha referente àquele mês. Quando um cliente solicita uma cópia de um serviço
realizado em uma data indeterminada, é consumido muito tempo para localizar a planilha na
38
qual as informações sobre a mídia referente ao serviço se encontram. Também existem

problemas quanto ao controle das despesas com fornecedores. No final de cada mês é preciso
conferir as contas confrontando os dados contidos nas planilhas com os dos relatórios dos
fornecedores.
Por fim, a empresa também não tem controle sobre o acesso e a manipulação de
informações por parte de seus funcionários. Não é possível saber a origem da inconsistência
de dados ou quem foi o responsável por tal, o que faz com que a empresa fique vulnerável a
erros.
A fim de solucionar todos esses problemas a empresa Vídeo Arte solicitou a
implantação de um sistema que automatizasse as principais rotinas da loja e auxiliasse a
gerência em relação à tomada de decisões sob o negócio, coletando e manipulando as
informações de forma segura e consistente.
3.3.1.2 Visão geral do sistema
O sistema de gestão comercial M System será responsável por informatizar as rotinas

de atendimento, controle de caixa, controle de contas a pagar e a receber e manutenção de
estoque de arquivos digitais, e com tudo isso oferecer um melhor controle das informações
por parte da gerência.
O sistema tem como objetivo agilizar todo o processo de venda, desde o atendimento
até a finalização da venda, possibilitando que, durante o processo, o usuário formule
orçamentos, cadastre clientes, fornecedores, produtos, serviços e movimentações, de forma
prática e eficiente.
O sistema deverá calcular automaticamente o valor total da venda de acordo com os
itens contidos nela e lançar diretamente no caixa o valor pago como entrada pelo cliente. Caso
fique um valor em aberto, este deve ser armazenado nas contas a receber. Os preços de custo
dos itens contidos na venda devem ir diretamente para as contas a pagar. O sistema deverá
permitir a emissão de etiquetas referentes à venda e a inclusão de informações sobre as mídias
dos arquivos digitais de forma simples e ágil, oferecendo em meio a tudo isso, a possibilidade
do usuário realizar logoff sem perder as informações que estão em andamento.
O sistema ainda deverá possibilitar a baixa, o estorno e o adiamento dos títulos a pagar
e a receber, e a inclusão de informações relevantes em relação aos clientes. Além disso,
39
deverá controlar as movimentações financeiras, as ações dos usuários, por meio de geração de
logs, e o relacionamento dos clientes por meio do controle de histórico de serviços prestados e
da estratégia de qualificações.
A estratégia de qualificações funciona da seguinte maneira: o cliente, ao quitar a
compra, ganha uma qualificação positiva. Caso ele não efetue o pagamento ou haja qualquer
outro tipo de problema com a negociação ele recebe uma qualificação negativa. Se a venda
ainda não foi quitada, ou seja, se a negociação ainda está em andamento, a qualificação fica
em aberto, cabe ao usuário qualificá-la posteriormente. Caso o cliente não tenha efetuado o
pagamento ou a retirada do produto, o sistema bloqueia qualquer venda para o cliente,
permitindo que a venda seja feita apenas se o administrador realizar o desbloqueio desta.
Finalmente deverá gerar relatórios de vendas em relação a cada tipo de serviço e/ou
produto, relatório de clientes, de contas a pagar e a receber, além de gráficos estatísticos de
vendas e de desempenho dos funcionários, fornecendo assim, um maior controle do negócio à
gerência.
3.3.1.3 Requisitos
Os requisitos foram divididos em duas categorias: os requisitos funcionais, que

correspondem à listagem de tudo que o sistema deve fazer, e os requisitos não funcionais, que
são regras colocadas sobre o modo como o sistema deve realizar os requisitos funcionais.
Os requisitos funcionais foram classificados em dois grupos: os requisitos funcionais
evidentes, que são percebidos pelo usuário através da troca de informações com a interface do
sistema, e os requisitos funcionais ocultos, que são realizados sem o conhecimento explícito
do usuário.
Os requisitos não funcionais foram classificados por categoria (se são requisitos de
interface, de implementação, de eficiência etc), e em obrigatórios ou desejados. Os requisitos
obrigatórios são aqueles que devem ser obtidos de qualquer maneira, já os desejados podem
ser obtidos caso isso não cause transtornos no desenvolvimento. Além disso, existem os
requisitos não funcionais que se encontram diretamente ligados a uma função e outros que são
gerais para o sistema, chamados de requisitos suplementares.
40
Nos quadros a seguir são apresentados os requisitos funcionais e não funcionais

levantados pela fase de concepção do sistema, finalizados de acordo com as iterações
realizadas durante o desenvolvimento da aplicação.
Quadro 1: Realizar Login

F1 Realizar login Oculto ( )
Descrição: O sistema deve solicitar a identificação do usuário antes de dar acesso à qualquer
outra funcionalidade.
Requisitos não funcionais
Nome Restrição Categoria Desejável
O sistema deve verificar se os dados de
NF1.1 Verificação dos
conexão com o banco de dados estão
dados de conexão com Segurança ( )
corretos. A configuração dos dados deve
o banco de dados
ser exigida caso os dados não estejam.
NF1.2 Identificação do O usuário deve ser identificado a partir
Interface ( )
usuário de seu login e senha.
NF1.3 Tempo de O tempo de identificação deve ser
Performance (X)
identificação inferior a um segundo.
O sistema deve mostrar ao usuário que
NF1.4 Sinal de
os dados foram informados corretamente Usabilidade (X)
identificação correta
antes do usuário tentar realizar o login.
Após a identificação do usuário o
NF1.5 Exibição da tela
sistema deve exibir a janela principal do Interface ( )
principal do sistema
sistema.
Quadro 2: Configurar dados de conexão

F2 Configurar dados de conexão Oculto ( )
Descrição: O sistema deve solicitar que o usuário informe novos dados de conexão,
armazená-los no arquivo de configurações e reiniciar o sistema.
O sistema deve permitir a configuração
NF2.1 Configuração de dados como: nome do banco, nome
Interface ( )
dos dados de conexão do servidor, nome e senha do usuário
administrador do banco de dados
Caso o usuário confirme a operação, o
NF2.2 Comportamento arquivo de configurações deve ser
diante a ação do atualizado e o sistema reiniciado. Caso o Segurança ( )
usuário usuário cancele a ação, o sistema deve
ser fechado.
41
Quadro 3: Configurar janela principal

F3 Configurar janela principal Oculto (X)
Descrição: O sistema deve configurar a janela principal conforme as informações e
permissões do usuário que efetuou o login.
O sistema deve exibir informações do
NF3.1 Exibição de
login como nome do usuário e data/hora Interface ( )
informações
do login e a data atual de forma extensa
O sistema deve configurar o menu de
acordo com as permissões de acesso do
NF3.2 Configuração
usuário. Os menus das telas as quais o Segurança ( )
do menu
usuário não tem acesso devem ficar
desabilitados.
O sistema deve permitir que o usuário
pesquise pelas telas que tem acesso e
NF3.3 Pesquisa de
abra com maior facilidade a tela Usabilidade (X)
menus
escolhida (exemplo: caixa de pesquisa
no menu iniciar do Windows Vista).
Quadro 4: Cadastrar usuário

F4 Cadastrar usuário Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de usuários
(inclusão, edição, exclusão e consulta).
NF4.1 Controle de As operações só ficam acessíveis caso o
Segurança ( )
acesso usuário tenha as permissões necessárias.
O tempo de consulta e conclusão das
NF4.2 Tempo de
operações deve ser inferior a dois Performance (X)
resposta às operações
segundos.
O sistema deve realizar a consulta de
acordo com os filtros informados e caso
NF4.3 Consulta Interface ( )
não encontre registros, uma mensagem
de aviso deve ser exibida ao usuário.
O sistema deve solicitar o nome, o login,
NF4.4 Inclusão Interface ( )
a senha e o perfil do usuário.
O sistema deve possibilitar que o
NF 4.5 Inclusão
usuário configure e cadastre um novo Usabilidade (X)
conjunta de perfil
perfil pela tela de cadastro de usuário.
As operações de edição e exclusão ficam
NF4.6
acessíveis apenas se existe um registro Interface ( )
Edição/Exclusão
selecionado na listagem.
NF4.7 Mensagem de
O sistema deve exibir uma mensagem de
conclusão de Interface ( )
aviso confirmando as operações.
operações
42
Quadro 5: Configurar conta usuário

F5 Cadastrar usuário Oculto ( )
Descrição: O sistema deve permitir que os usuários possam alterar seus dados de login.
Antes de permitir a configuração, o
NF5.1 Solicitação de
sistema solicita a identificação do Segurança ( )
identificação
usuário através de senha.
Após identificação do usuário, o sistema
deve solicitar o novo login ou a nova
senha. Após confirmação do usuário, o
NF5.2 Configuração Interface ( )
sistema deve armazenar os novos dados
e exibir uma mensagem de aviso
confirmando a operação.
NF5.3 Tempo de O tempo de conclusão da operação deve
Performance (X)
resposta à operação ser inferior a dois segundos.
Quadro 6: Cadastrar tipo de observação

F6 Cadastrar tipo de observação Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de tipos de
observação (inclusão, edição, exclusão e consulta).
Segurança ( )
NF6.2 Tempo de
segundos.
O sistema deve solicitar a descrição do
tipo de observação.
NF6.5
Edição/Exclusão
NF6.6 Mensagem de
operações
43
Quadro 7: Cadastrar status de cliente

F7 Cadastrar status de cliente Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de status do
cliente (inclusão, edição, exclusão e consulta).
Segurança ( )
NF7.2 Tempo de
segundos.
status do cliente.
NF7.5
Edição/Exclusão
NF7.6 Mensagem de
operações
Quadro 8: Cadastrar status de venda

F8 Cadastrar status de venda Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de status de
venda (inclusão, edição, exclusão e consulta).
Segurança ( )
NF8.2 Tempo de
segundos.
status de venda.
NF8.5
Edição/Exclusão
NF8.6 Mensagem de
operações
44
Quadro 9: Cadastrar serviço

F9 Cadastrar seviço Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de serviço
Segurança ( )
NF9.2 Tempo de
segundos.
serviço.
NF9.5
Edição/Exclusão
NF9.6 Mensagem de
operações
Quadro 10: Cadastrar fornecedor

F10 Cadastrar fornecedor Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de fornecedor
Segurança ( )
NF10.2 Tempo de O tempo de consulta e conclusão das
Performance (X)
resposta às operações operações deve ser inferior a dois seg.
O sistema deve solicitar o código,a razão
NF10.4 Inclusão social, o nome fantasia, o CNPJ e o Interface ( )
telefone do fornecedor.
NF10.5
Edição/Exclusão
NF10.6 Mensagem de
operações
45
Quadro 11: Cadastrar produto

F11 Cadastrar produto Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de produto
Segurança ( )
NF11.2 Tempo de
segundos.
O sistema deve solicitar o código,a
descrição, o serviço, o fornecedor, o
preço de custo e o preço de venda do
produto.
NF11.5
Edição/Exclusão
NF11.6 Mensagem de
operações
Quadro 12: Cadastrar cliente

F12 Cadastrar cliente Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de cliente
Segurança ( )
NF12.2 Tempo de
segundos.
O sistema deve solicitar o nome, a data
de nascimento, RG, CPF, um
responsável, telefone, endereço, status e
observações do cliente.
NF12.5 As operações de edição e exclusão ficam Interface ( )
Edição/Exclusão acessíveis apenas se existe um registro
46
NF12.6 Mensagem de
operações
Quadro 13: Cadastrar observações do cliente

F13 Cadastrar observações do cliente Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de observações
do cliente (inclusão, edição, exclusão e consulta).
Segurança ( )
NF13.2 Tempo de
segundos.
O sistema deve solicitar a descrição e o
NF13.4 Inclusão tipo de observação para as observações Interface ( )
do cliente.
NF13.5 Edição /
Exclusão
NF13.6 Mensagem de
operações
Quadro 14: Cadastrar meta

F14 Cadastrar meta Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de metas
Segurança ( )
NF14.2 Tempo de O tempo de consulta e conclusão das
Performance (X)
resposta às operações operações deve ser inferior a dois seg.
47
O sistema deve solicitar a data de início,

a data fim e o valor da meta.
NF14.5 Edição /
Exclusão
NF14.6 Mensagem de
operações
Quadro 15: Cadastrar orçamento

F15 Cadastrar orçamento Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de orçamento
Segurança ( )
NF15.2 Tempo de
segundos.
O sistema deve solicitar um cliente,
itens, data, número, valor total,
observação e atendente do orçamento.
No momento da inclusão o sistema deve
gerar o número de orçamento de acordo
com a data e o número de controle diário
(ex.: 4º orçamento do dia 21/12/2009:
200912210004)
NF15.5 Edição /
Exclusão
O sistema deve permitir a geração de
NF15.6 Geração de
venda a partir do orçamento, passando Usabilidade ( )
venda
as informações deste para ela.
NF15.7 Mensagem de
operações
Quadro 16: Imprimir orçamento

F16 Imprimir orçamento Oculto ( )
Descrição: O sistema deve imprimir o orçamento de acordo com todas os dados orçados.
48
A impressão só poderá ser realizada

NF16.1 Controle de
caso o usuário tenha permissão de Segurança ( )
acesso
cadastrar o orçamento.
O tempo de conclusão da operação de
NF16.2 Tempo de
impressão deve ser inferior a dois Performance (X)
segundos.
O sistema deve exibir um preview da
impressão de acordo com todas as
NF16.3 Visualização Interface ( )
informações contidas no orçamento
antes de imprimi-lo.
Após solicitação de impressão do
usuário, o sistema deve realizar a
NF16.4 Impressão Interface ( )
impressão de acordo com o preview
apresentado anteriormente.
Quadro 17: Cadastrar venda simples

F17 Cadastrar venda simples Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de venda
(inclusão, edição, estorno e consulta).
Segurança ( )
NF17.2 Tempo de
operações deve ser inferior a três Performance (X)
segundos.
O sistema deve possibilitar dois modos
de visualização: tabela/cartão
O sistema deve solicitar a data e os itens
da venda e calcular automaticamente o
valor total conforme os itens.
O sistema só deve permitir o fechamento
e a inclusão da venda caso o valor pago
pelo cliente seja equivalente ao total. O
sistema deve gerar contas a pagar em
relação ao preço de custo de cada item
da venda (F23).
gerar o número de venda de acordo com
a data e o número de controle diário
(ex.: 4ª venda do dia 21/12/2009:
200912210004)
NF17.5 Edição A operação de edição deve ficar Interface ( )
acessível apenas se existir um registro
49
Toda e qualquer alteração realizada
deverá ser gravada em um log, com o
NF17.6 Log alteração Segurança ( )
valor anterior, valor atual, data e hora da
alteração e o usuário responsável.
O usuário só terá acesso à operação se
algum registro estiver selecionado.
O sistema deve solicitar o motivo do
estorno e a confirmação do usuário.
Após confirmação, deve marcar a venda
como estornada e remover as contas a
pagar geradas a partir dos itens da venda
NF17.7 Estorno Interface ( )
e gerar uma movimentação no caixa
referente à data da venda com o valor de
entrada (F22). Caso a venda possua
movimentações, os valores destas devem
ser retirados dos caixas das contas a
receber, dependendo da situação da
movimentação.
NF17.8 Mensagem de
operações
Quadro 18: Cadastrar venda completa

F18 Cadastrar venda completa Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de venda
(inclusão, edição, estorno e consulta).
Segurança ( )
NF18.2 Tempo de
operações deve ser inferior a três Performance (X)
segundos.
O sistema deve possibilitar dois modos
de visualização: tabela/cartão
NF18.4 Inclusão O sistema deve solicitar a identificação Interface ( )
do cliente e a informação dos itens da
venda, valor de entrada, número do
envelope, data da venda e data de
entrega. O sistema deve
automaticamente calcular o total da
venda de acordo com os itens e o valor
em aberto de acordo com a entrada, e
50
gerar contas a pagar em relação ao preço

de custo de cada item da venda (F23).
gerar o número de venda de acordo com
a data e o número de controle diário
(ex.: 4ª venda do dia 21/12/2009:
200912210004)
Imediatamente após a identificação do
cliente, o sistema deve exibir suas
NF18.5 Exibição de
informações e qualificações, e permitir Usabilidade ( )
dados do cliente
que o usuário visualize o cadastro do
cliente e os detalhes da última compra.
NF18.6 Tempo de O tempo gasto para identificar e exibir
resposta à os dados do cliente deve ser inferior a Performance (X)
identificação do cliente um segundo.
Se a última qualificação do cliente for
NF18.7 Bloqueio da negativa, o sistema bloqueia a realização
Segurança ( )
venda da venda, permitindo a operação apenas
se o administrador realizar a permissão.
Após a solicitação do administrador, o
NF18.8 Desbloqueio sistema deve desbloquear a venda e Interface ( )
permitir que ela seja realizada.
Caso o cliente ainda não esteja
cadastrado no sistema, o sistema deve
NF18.9 Inclusão permitir que o os dados do cliente,
Usabilidade ( )
conjunta de cliente informados no próprio cadastro da
venda, sejam armazenados no momento
de inclusão da venda.
NF18.10 Inclusão O sistema deve permitir que o usuário
Usabilidade ( )
conjunta de mídias inclua mídias relacionadas à venda (F21)
NF18.11 Inclusão
O sistema deve permitir que o usuário
conjunta de Usabilidade ( )
inclua movimentações à venda (F22)
movimentações
A operação de edição deve ficar
acessível apenas se existir um registro
selecionado na listagem. Se o valor de
NF18.12 Edição Interface ( )
entrada for alterado, o sistema deve
atualizar o caixa referente a data da
venda conforme este valor.
NF18.13 Estorno O usuário só terá acesso à operação se Interface ( )
algum registro estiver selecionado.
O sistema deve solicitar o motivo do
estorno e a confirmação do usuário.
Após confirmação, deve marcar a venda
como estornada e remover as contas a
pagar geradas a partir dos itens da
venda. Caso a venda já tenha sido paga,
seu valor deve ser retirado do caixa
referente à data de sua realização
(realizando uma movimentação de caixa
51
- F22). Caso a venda possua

movimentações, o sistema deve tratá-las,
alterando os caixas e as contas a receber
necessárias. (F21)
Qualquer alteração/estorno realizado
deverá ser gravado em um log, com o
NF18.15 Mensagem
de conclusão de Interface ( )
operações
Quadro 19: Imprimir etiqueta

F19 Imprimir etiqueta Oculto ( )
Descrição: O sistema deve imprimir a etiqueta, quantas vezes forem solicitadas, contendo
todas as informações da venda.
NF19.1 Controle de
caso o usuário “logado” tenha permissão Segurança ( )
acesso
de cadastrar a venda.
NF19.2 Tempo de
segundos.
impressão da etiqueta, contendo o
número do envelope, os dados do
cliente, os itens da venda, o valor total, o
valor pago e o valor em aberto.
Quadro 20: Cadastrar mídias da venda

F20 Cadastrar mídias da venda Oculto ( )
Descrição: O sistema deve exibir todas as mídias relacionadas à venda e permitir a
manipulação das mídias (inclusão, edição e exclusão).
Segurança ( )
NF20.2 Tempo de
segundos.
O sistema deve solicitar o número,
descrição, serviço e observação da mídia
NF20.4 As operações de edição e exclusão ficam Interface ( )
Edição/Exclusão acessíveis apenas se existe um registro
52
NF20.5 Mensagem de
operações
Quadro 21: Cadastrar movimentações da venda

F21 Cadastrar movimentações da venda Oculto ( )
Descrição: O sistema deve exibir todas as movimentações relacionadas à venda e permitir a
manipulação de movimentações (inclusão, edição e estorno).
Segurança ( )
NF21.2 Tempo de O tempo de conclusão das operações
Performance (X)
resposta às operações deve ser inferior a dois segundos.
O sistema deve solicitar o tipo de
movimentação (à vista ou à prazo). Se
for à vista o sistema deve solicitar o
valor e a descrição da movimentação. Se
for à prazo, deve permitir a inclusão de
outras movimentações futuras,
solicitando sempre a data, o valor e a
forma de pagamento.
acessíveis apenas se existe um registro
selecionado na listagem e se o usuário
possui permissão. Se a movimentação
for estornada ou o valor dela for
NF21.4 Edição / alterado, o sistema deve, dependendo da
Interface ( )
Estorno situação da movimentação (se já foi
dado baixa nela ou ainda não), atualizar
o caixa (realizando uma movimentação
de caixa - F22) ou as contas a receber
(estornando a conta referente da
relação).
NF21.6 Mensagem de
operações
Quadro 22: Cadastrar movimentação de caixa

F22 Cadastrar movimentação de caixa Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes à operação de caixa
(inclusão, edição, estorno e consulta)
53

Segurança ( )
NF22.2 Tempo de
segundos.
O sistema deve solicitar o tipo, a
descrição, valor e a data do caixa.
As operações de edição e estorno ficam
NF22.5 Edição /
selecionado na listagem. Se o usuário Interface ( )
Estorno
solicitou o estorno, o sistema deve
marcar a movimentação como estornada.
NF22.7 Mensagem de
operações
Quadro 23: Cadastrar contas a pagar

F23 Cadastrar contas a pagar Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de contas a
pagar (inclusão, edição, estorno e consulta)
Segurança ( )
NF23.2 Tempo de O tempo de consulta e conclusão deve
Performance (X)
resposta às operações ser inferior a dois segundos.
O sistema deve solicitar a descrição, o
produto, o valor e a data do pagamento.
NF23.5 Edição /
Estorno
NF23.6 Mensagem de O sistema deve exibir uma mensagem de Interface ( )
conclusão de aviso confirmando as operações.
54
operações
Quadro 24: Cadastrar contas a receber

F24 Cadastrar contas a receber Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de contas a
receber (inclusão, edição, estorno e consulta)
Segurança ( )
NF24.2 Tempo de
segundos.
O sistema deve solicitar a descrição, o
valor e a data de recebimento.
NF24.5 Edição /
Estorno
A operação de baixa ficará acessível
apenas quando uma conta estiver
selecionada e não estiver cancelada ou
baixada. Quando o usuário dá baixa em
NF24.6 Baixa
uma conta a receber, o sistema deve
solicitar a data da baixa e atualizar o
caixa referente àquela data (gerando
uma movimentação de caixa - F22).
NF24.7 Mensagem de
operações
Quadro 25: Cadastrar mídias digitais

F25 Cadastrar mídias digitais Oculto ( )
Descrição: O sistema deve realizar todas as operações referentes ao cadastro de mídias
digitais (inclusão, edição, estorno e consulta)
Segurança ( )
NF25.2 Tempo de
segundos.
NF25.3 Consulta O sistema deve realizar a consulta de Interface ( )
55

O sistema deve solicitar deve solicitar o
número, descrição, serviço e observação
da mídia e a seleção de vendas que
deverão estar associadas a ela.
NF25.5 Edição /
selecionado na listagem. A mídia só Interface ( )
Exclusão
poderá ser excluída, caso não esteja
associada a nenhuma venda.
NF25.6 Mensagem de
operações
Quadro 26: Imprimir relatório de clientes

F26 Imprimir relatório de clientes Oculto ( )
Descrição: O sistema deve imprimir o relatório de clientes de acordo com os parâmetros
informados pelo usuário.
NF26.1 Controle de
acesso
acesso ao relatório.
NF26.2 Tempo de
segundos.
O sistema deve solicitar que o usuário
informe algum filtro para a consulta.
NF26.3 Visualização Após isso, deve exibir um preview da Interface ( )
impressão contendo as informações dos
clientes requeridos.
Quadro 27: Imprimir relatório de vendas

F27 Imprimir relatório de vendas Oculto ( )
Descrição: O sistema deve permitir a impressão do relatório de vendas por serviço, produto,
cliente, tipo ou situação da venda.
NF27.1 Controle de A impressão só poderá ser realizada Segurança ( )
acesso caso o usuário tenha permissão de
56
NF27.2 Tempo de
segundos.
impressão contendo os dados do
resultado da consulta.
Quadro 28: Imprimir relatório de contas a pagar

F28 Imprimir relatório de contas a pagar Oculto ( )
Descrição: O sistema deve permitir a impressão do relatório de contas a pagar por
fornecedor, produto ou data.
NF28.1 Controle de
acesso
NF28.2 Tempo de
segundos.
Quadro 29: Imprimir relatório de contas a receber

F29 Imprimir relatório de contas a receber Oculto ( )
Descrição: O sistema deve permitir a impressão do relatório de contas a receber por venda,
cliente ou data.
NF29.1 Controle de
acesso
NF29.2 Tempo de O tempo de conclusão da impressão Performance (X)
57
resposta às operações deve ser inferior a dois segundos.

NF29.4 Impressão usuário, o sistema deve realizar a Interface ( )
impressão de acordo com o preview.
Quadro 30: Visualizar gráfico estatístico de vendas

F30 Visualizar gráfico estatístico de vendas Oculto ( )
Descrição: O sistema deve permitir a visualização do gráfico estatístico de vendas
organizadas por serviço.
NF30.1 Controle de O gráfico só poderá ser visualizado caso
Segurança ( )
acesso o usuário tenha permissão de acesso.
NF30.2 Tempo de O tempo de criação do gráfico deve ser
Performance (X)
criação do gráfico inferior a dois segundos.
O sistema deve solicitar um período.
NF30.3 Visualização Após isso, deve exibir um gráfico das Interface ( )
vendas do período separadas por serviço
Quadro 31: Visualizar gráfico estatístico de desempenho

F31 Visualizar gráfico estatístico de desempenho Oculto ( )
Descrição: O sistema deve permitir a visualização do gráfico estatístico de desempenho dos
atendentes (atendimento) e dos designers (produção).
NF31.1 Controle de O gráfico só poderá ser visualizado caso
Segurança ( )
NF31.2 Tempo de O tempo de criação do gráfico deve ser
Performance (X)
criação do gráfico inferior a dois segundos.
O sistema deve solicitar um período.
Após isso, deve exibir um gráfico de
desempenho da equipe sobre as vendas
em relação a atendimentos e produções.
Quadro 32: Visualizar logs de ação dos usuários

F32 Visualizar logs de ação dos usuários Oculto ( )
Descrição: O sistema deve permitir a visualização dos logs de ação dos usuários .
58
NF32.1 Controle de Os logs só poderão ser visualizado caso

Segurança ( )
NF32.2 Tempo de O tempo de consulta para exibição deve
Performance (X)
consulta de logs ser inferior a dois segundos.
O sistema deve solicitar um período ou
um usuário. Após isso, deve exibir todos
os logs que respeitam os dados
informados.
Quadro 33: Requisitos suplementares

Requisitos suplementares
Cada cadastro deve conter duas interfaces:
S1 Cadastros com uma de consulta, onde se pode consultar e
duas interfaces excluir registros, e outra de manutenção, Interface ( )
distintas onde os dados do registro a ser incluído ou
editado são informados.
Todas as telas do sistema devem possuir um
S2 Help Usabilidade ( )
help que auxilie na sua utilização.
O sistema deve permitir que o usuário faça
S3 Logoff Usabilidade ( )
logoff a partir de qualquer tela.
3.3.2 Organização dos requisitos
Com os requisitos levantados, a próxima etapa foi organizá-los em grupos, de tal

forma que pudessem ser abordados nos ciclos iterativos. Os requisitos foram agrupados da
seguinte forma:
• Casos de uso. Os principais processos de negócio da empresa.
• Conceitos. Os conceitos envolvidos com o sistema sofrerão operações de manutenção
ou cadastro, como inserir, alterar, excluir e consultar.
• Consultas. O termo “consulta” refere-se a qualquer acesso à informação que não a
altere, portanto compreende tanto as consultas exibidas em tela quando os relatórios
impressos pelo sistema.
59
3.3.2.1 Organização dos requisitos em casos de uso
Na fase de concepção foram identificados os grandes processos da Vídeo Arte, como

“realizar venda”, “elaborar orçamento” etc. Esses grandes processos foram transformados em
casos de uso, que estão associados a um conjunto de requisitos funcionais.
O quadro 34 lista e descreve em alto nível os casos de uso apresentados anteriormente:
Quadro 34: Listagem de casos de uso da fase de concepção

Nome Atores Descrição Ref. cruzadas
Realizar O funcionário se identifica informando seu
Funcionário F1, F2, F3, F4
login login e senha e tem acesso ao sistema
O cliente identifica os produtos e serviços
Realizar que necessita. O funcionário faz o registro
Cliente, F9, F10, F11,
venda da venda, gerando uma movimentação de
Funcionário F17, F22, F23
simples caixa referente ao valor de entrada pago
pelo cliente.
O cliente se identifica e identifica os
produtos e serviços que necessita. O F9, F10, F11,
Realizar
Cliente, funcionário faz o registro da venda, F12, F18, F19,
venda
Funcionário realizando as movimentações necessárias F20, F21, F23,
completa
(entrada e parcelas) e a impressão de F24
etiquetas com informações da venda.
O funcionário identifica a venda que
deseja estornar. O funcionário informa o
Estornar F18, F22, F23,
Funcionário motivo e realiza o estorno. São realizadas
venda F24
as movimentações (caixa) e cancelamentos
(contas a pagar e a receber) necessárias.
O funcionário identifica a conta que deseja
Dar baixa baixar. Caso a conta seja referente à última
em contas Funcionário parcela a ser paga da venda, o funcionário F18, F21, F24
a receber realiza o fechamento desta atribuindo uma
qualificação ao cliente.
O cliente se identifica e informa os
produtos e serviços que deseja orçar. O
Elaborar Cliente, funcionário faz o registro do orçamento e F9, F10, F11,
orçamento Funcionário o imprime para o cliente. De acordo com a F12, F16, F18
negociação, opta por gerar ou não uma
venda a partir dele.
Organizar O funcionário identifica a mídia e
estoque de Funcionário seleciona as vendas para as quais a mídia F18, F25
mídia será atribuída.
60
As ilustrações a seguir apresentam: o diagrama de caso de uso geral do sistema e os

diagramas de todos os casos de uso do sistema.
Ilustração 5: Diagrama de casos de uso do sistema

61
Ilustração 6: Diagrama de caso de uso “Realizar login”
Ilustração 7: Diagrama de caso de uso “Realizar venda simples”

62
Ilustração 8: Diagrama de caso de uso “Realizar venda completa”

63
Ilustração 9: Diagrama de caso de uso “Estornar venda”
Ilustração 10: Diagrama de caso de uso “Dar baixa em contas a receber”

64
Ilustração 11: Diagrama de caso de uso “Elaborar orçamento”
Ilustração 12: Diagrama de caso de uso “Organizar estoque mídia”

65
3.3.2.2 Organização dos requisitos em função de conceitos
As operações relativamente simples e elementares (de um único passo), como o

registro do cliente ou de um pagamento, não foram consideradas casos de uso por si só, pois
não há necessidade de estudar seu processo interativo, que consiste em apenas um passo.
Quadro 35: Listagem de conceitos e operações de manutenção

Conceito I A Ex C Es Observação Ref. Cruz.
Usuário x x x x F4
A inclusão e a alteração do perfil serão
Perfil x x F4
feitas a partir do cadastro de usuário.
Só é possível excluir um tipo de
Tipo de
x x x x observação caso ele não esteja F6
observação
associado a nenhuma observação.
Só é possível excluir um status de
Status de
x x x x cliente caso ele não esteja associado a F7
cliente
nenhum cliente.
Só é possível excluir um status de
Status de
x x x x venda caso ele não esteja associado a F8
venda
nenhuma venda.
Só é possível excluir um serviço caso
Serviço x x x x ele não esteja associado a nenhum F9
produto.
Só é possível excluir um fornecedor
Fornecedor x x x x caso ele não esteja associado a nenhum F10
produto.
Só é possível excluir um produto caso
Produto x x x x ele não esteja associado a nenhuma F11
venda.
Só é possível excluir um cliente caso
Cliente x x x x ele não esteja associado a nenhuma F12
venda.
Observações
x x x x F13
do cliente
Só é possível excluir uma meta caso
Meta x x x x F14
ela não tenha sido iniciada.
A inclusão de orçamento só pode
Orçamento x x x x acontecer através do caso de uso F15
“elaborar orçamento”.
A inclusão de venda só pode acontecer
através dos casos de uso “realizar
Venda x x x x venda simples” e “realizar venda F17, F18
completa”. Não é possível excluir uma
venda, somente estorná-la.
Mídias da x x x Não há consulta, o sistema deve exibir F18, F20
66
todas as mídias. A mídia só será de

fato excluída se não possuir mais
venda
nenhuma associação. Pelo contrário,
será somente dissociada.
Não há consulta, pois o sistema deve
Movimentaç sempre exibir todas as movimentações
x x x F18, F21
ões da venda da venda. Não é possível excluir uma
movimentação, somente estorná-la.
Movimentaç Não é possível excluir uma
x x x x F22
ões de caixa movimentação, somente estorná-la.
Não é possível excluir uma conta a
Contas a
x x x x pagar, somente estorná-la. A inclusão F23
pagar
de contas a pagar
Contas a Não é possível excluir uma conta a
x x x x F24
receber receber, somente estorná-la.
Mídias Só é possível excluir uma mídia se não
x x x x F25
digitais houver vendas associadas.
3.3.2.3 Organização dos requisitos em consultas
As consultas listadas aqui não são aquelas que simplesmente permitem visualizar um
conceito armazenado, porque esse tipo de consulta já foi considerado na organização dos
conceitos, e sim as consultas que combinam informações de diferentes conceitos, como
“relatório mensal de vendas”, “relatório de clientes inadimplentes” etc.
Quadro 36: Listagem de consultas

Nome Referências cruzadas
Vendas (diárias, mensais, por serviço, fornecedor, produto,
F9, F10, F11, F12, F17, F18
cliente e situação)
Contas a pagar (vencidas, quitadas, por fornecedor) F23
Contas a receber (vencidas, quitadas, por cliente) F24
Clientes inadimplentes F12, F17, F18
Desempenho funcionários F4, F17, F18
3.3.3 Planejamento dos ciclos iterativos
Como foi visto anteriormente, os ciclos iterativos equivalem a miniprojetos que se

baseiam em casos de uso, conceitos e consultas. Para realizar o planejamento dos ciclos
67
iterativos, os elementos foram organizados por prioridade. Foi dada maior prioridade aos
elementos que apresentavam maiores riscos ao sistema. De fato os maiores riscos estavam nos
processos de negócio da empresa e por isso os casos de uso foram inicialmente abordados.
Para estimar o esforço total de desenvolvimento foram aplicadas medidas de pontos de
casos de uso. O quadro 37 apresenta o planejamento dos primeiros ciclos iterativos já com a
estimativa de esforço:
Quadro 37: Planejamento em ciclos iterativos

Manutenção de Esforço
Ciclo Casos de uso Cons. Observações
informações estimado
Nesse ciclo já será
realizado o
Configurações (20),
1 Realizar login - controle de acesso 120 horas
Usuário (50)
e as padronizações
de design (50)
Serviço (20),
Fornecedor (20),
Realizar Produto (40),
2 - - 170 horas
venda simples Contas a pagar (40),
Movimentação de caixa
(50), Metas (30).
Cliente (50),
Status do cliente (20),
Observações cliente (30),
Realizar
Tipo de observação (20),
3 venda - - 300 horas
Mídias venda (30),
completa
Movimentação da venda
(50), Contas a receber
(50)
Nesse ciclo será
adicionada a
Estornar
4 Venda (40) - operação de 40 horas
venda
estorno ao
cadastro de venda
Nesse ciclo será
Dar baixa em adicionada a
5 contas a Contas a receber (40) - operação de baixa 40 horas
receber ao cadastro de
contas a receber
Elaborar
6 Orçamento (40) - - 40 horas
orçamento
Organizar
7 Mídias digitais (60) 60 horas
estoque mídia
Todas
8 - - 80 horas
(80)
68
3.3.3.1 Cronograma de execução e custos
A elaboração do cronograma de execução (Quadro 38) foi realizada com base nos
seguintes fatores:
• Tempo total estimado para o projeto (850 horas);
• Tempo disponível do desenvolvedor (25 horas/semana).
Quadro 38: Cronograma de execução

1 16 36 56 86 121 166 176 186 196 206 216 226 236 251 261 286
Dias a a a a a a a a a a a a a a a a a
15 35 55 85 120 165 175 185 195 205 215 225 235 250 260 285 295
Sem. 2 3 3 4 5 6 1 1 1 1 1 1 1 2 1 1 1
A I
Ciclo
/P /
1
T
A I
Ciclo
/P /
2
T
A I
Ciclo
/ /
3
P T
A I
Ciclo
/ /
4
P T
A I
Ciclo
/ /
5
P T
A I
Ciclo
/ /
6
P T
A I
Ciclo
/ /
7
P T
A I
Ciclo
/ /
8
P T
Impl. Impl.
Portanto, de acordo com o quadro 38, o tempo total estimado para o desenvolvimento
do sistema foi de trinta e cinco semanas ou oito meses e meio.
69
3.4 Elaboração
A fase de elaboração deu continuidade à análise, comportando as seguintes atividades:

• Expansão dos casos de uso (especificação de fluxos principais e alternativos)
• Determinação dos eventos do sistema (diagramas de sequência e atividades)
Além disso, a fase de elaboração comportou as seguintes atividades de projeto:

• Projeto da camada de domínio (diagramas de classes)
• Projeto da camada de aplicação (protótipos)
3.4.1 Expansão dos casos de uso
Quadro 39: Caso de uso expandido “Realizar login”

CASO DE USO: REALIZAR LOGIN
ID: UC 01
Atores: Funcionário
Precondições: O funcionário já está cadastrado no sistema (como usuário).
Fluxo principal:
1. O funcionário inicia o sistema.
2. O sistema verifica se os dados de conexão são válidos.
3. O sistema solicita identificação do funcionário (login e senha).
4. O funcionário fornece a identificação.
5. O sistema autentica a identificação do funcionário.
6. O sistema exibe a tela principal de acordo com as permissões do funcionário.
Pós-condições: A tela principal foi exibida e o funcionário possui acesso a todas as
operações que lhe foram concedidas.
Fluxo alternativo:
2a – Dados de conexão inválidos
2a. 1 – O sistema verifica que os dados de conexão são inválidos.
2a. 2 – O sistema exibe a tela de configuração solicitando os novos dados de conexão.
2a. 3 – O funcionário fornece os novos dados de conexão.
2a. 4 – O sistema armazena os novos dados.
2a. 5 – O sistema emite a mensagem “Configurações salvas com sucesso. Aguarde pelo
reinício do sistema”.
2a. 6 – O sistema se reinicia.
2a. 7 – Retorna ao fluxo principal no passo 2.
5a – Identificação inválida
5a. 1 – O sistema verifica que a identificação é inválida.
5a. 2 – O sistema emite a mensagem “Login ou senha inválida”.
70
Quadro 40: Caso de uso expandido “Realizar venda simples”

CASO DE USO: REALIZAR VENDA SIMPLES
ID: UC 02
Atores: Cliente, Funcionário
Precondições: O funcionário tem privilégio para cadastro de venda
Fluxo principal:
1. O cliente identifica os produtos que deseja comprar.
2. Para cada item a ser incluso na venda:
2.1 O funcionário informa a descrição do produto desejado.
2.2 O sistema verifica se o produto está cadastrado.
2.3 O sistema inclui o item na venda
2.4 O sistema adiciona o valor do item ao valor total da venda
3. O cliente fornece o valor a ser pago.
4. O funcionário insere o valor pago pelo cliente.
5. O sistema calcula a diferença e informa o valor de troco (se houver).
6. O funcionário solicita a inclusão da venda.
7. O sistema adiciona a venda.
8. O sistema inclui uma movimentação de caixa com o valor pago pelo cliente.
9. O sistema inclui contas a pagar de acordo com cada item contido na venda.
10. O sistema emite a mensagem “Operação efetuada com sucesso”.
Pós-condições: A venda foi cadastrada juntamente com a movimentação de caixa e as contas
a pagar referentes a ela.
Fluxo alternativo:
2.2a – Produto não cadastrado
2.2a. 1 – O sistema verifica que o produto não está cadastrado.
2.2a. 2 – O funcionário solicita a inclusão de um novo produto.
2.2a. 3 – O sistema exibe a tela de cadastro de produto.
2.2a. 4 – O funcionário informa os dados do produto.
2.2a. 5 – O funcionário solicita a inclusão do produto
2.2a. 6 – O sistema adiciona o produto
2.2a. 7 – Retorna ao fluxo principal no passo 2.3.
Quadro 41: Caso de uso expandido “Realizar venda completa”

CASO DE USO: REALIZAR VENDA COMPLETA
ID: UC 03
Precondições: O funcionário tem privilégio para cadastro de venda
Fluxo principal:
1. O cliente se identifica informando seu nome
2. O funcionário informa o nome do cliente
3. O sistema verifica se o cliente está cadastrado
4. O sistema carrega os dados do cliente na tela
5. O sistema verifica se a última qualificação do cliente é positiva
6. Para cada item a ser incluso na venda:
6.3 O sistema inclui o item na venda
7. O cliente fornece o valor de entrada a ser pago.
71
8. O funcionário insere o valor de entrada pago pelo cliente.

9. O sistema calcula a diferença e informa o valor em aberto ou de troco (se houver).
10. O funcionário solicita a inclusão da venda.
11. O sistema inclui uma movimentação de caixa com o valor pago pelo cliente.
12. O sistema inclui contas a pagar de acordo com cada item contido na venda.
13. O sistema verifica se não há valor em aberto
14. O sistema adiciona a venda com status de encerrada.
15. O funcionário atribui uma qualificação ao cliente
16. O sistema altera o cliente.
Pós-condições: A venda foi cadastrada juntamente com a movimentação de caixa e as contas
Fluxo alternativo:
3a – Cliente não cadastrado
3a. 1 – O sistema verifica que o cliente não está cadastrado.
3a. 2 – O funcionário informa os dados do novo cliente
3a. 3 – O funcionário solicita a inclusão do cliente
3a. 4 – O sistema adiciona o cliente
5a – Qualificação do cliente é negativa
5a. 1 – O sistema verifica que a última qualificação do cliente é negativa.
5a. 2 – O sistema bloqueia a venda.
5a. 3 – O funcionário que possui permissão de desbloquear solicita o desbloqueio
5a. 4 – O sistema desbloqueia a venda.
6.2a. 2 – O funcionário informa os dados do novo produto.
14a – Há valor em aberto
14a. 1 – O sistema verifica que há valor em aberto.
14a. 2 – O sistema adiciona uma conta a receber referente ao valor em aberto.
14a. 3 – O sistema adiciona a venda com status em aberto.
Quadro 42: Caso de uso expandido “Estornar venda”

CASO DE USO: ESTORNAR VENDA
ID: UC 04
Precondições: O funcionário tem privilégio para estornar vendas
Fluxo principal:
1. O funcionário informa os dados da venda
2. O sistema verifica se venda está cadastrada.
3. O funcionário solicita estorno da venda.
4. O sistema solicita o motivo.
5. O funcionário informa o motivo.
6. O sistema atribui o motivo à venda.
72
7. O sistema altera status da venda para estornada

8. O sistema estorna as movimentações de caixa referentes.
9. O sistema cancela as contas a pagar referentes.
10. O sistema cancela as contas a receber referentes (se houver).
Pós-condições: A venda foi estornada juntamente com a movimentação de caixa e as contas
Fluxo alternativo:
2a – Venda não cadastrada:
2a. 1 – O sistema verifica emite a mensagem “Nenhum registro encontrado”.
Quadro 43: Caso de uso expandido “Dar baixa em contas a receber”

CASO DE USO: DAR BAIXA EM CONTAS A RECEBER
ID: UC 05
Precondições: O funcionário tem privilégio para dar baixa em contas a receber.
Fluxo principal:
1. O funcionário informa os dados da conta a receber
2. O sistema verifica se a conta está cadastrada.
3. O funcionário solicita a baixa.
4. O sistema altera o status da conta.
5. O sistema inclui uma movimentação de caixa referente ao valor da conta.
6. O sistema verifica se há uma venda relacionada.
7. O sistema verifica se é a última parcela da venda
8. O sistema grava a venda como encerrada.
9. O sistema altera o cliente com uma qualificação positiva.
Pós-condições: A conta foi baixada e uma movimentação de caixa foi gerada.
Fluxo alternativo:
2a – Conta não cadastrada:
2a. 1 – O sistema verifica que a conta não está cadastrada.
2a. 2 – O sistema emite a mensagem “Nenhum registro encontrado”.
6a – Não há uma venda relacionada:
7a – Não é a última parcela da venda:
Quadro 44: Caso de uso expandido “Elaborar orçamento”

CASO DE USO: ELABORAR ORÇAMENTO
ID: UC 06
Precondições: O funcionário tem privilégio para cadastro de orçamento
Fluxo principal:
1. O cliente se identifica informando seu nome
2. O funcionário informa o nome do cliente
3. O sistema verifica se o cliente está cadastrado
4. O sistema carrega os dados do cliente na tela
73
5. O sistema verifica se a última qualificação do cliente é positiva

6. Para cada item a ser incluso no orçamento:
6.3 O sistema inclui o item no orçamento
7. O funcionário solicita a geração de venda
8. O sistema cria uma venda passando os dados do orçamento para ela.
9. O sistema adiciona o orçamento.
Pós-condições: O orçamento foi cadastrado.
Fluxo alternativo:
3a – Cliente não cadastrado
3a. 1 – O sistema verifica que o cliente não está cadastrado.
3a. 2 – O funcionário informa os dados do novo cliente
3a. 3 – O funcionário solicita a inclusão do cliente
3a. 4 – O sistema adiciona o cliente
5a – Qualificação do cliente é negativa
5a. 1 – O sistema verifica que a última qualificação do cliente é negativa.
5a. 2 – O sistema bloqueia o orçamento.
5a. 3 – O funcionário que solicita o desbloqueio
5a. 4 – O sistema verifica se o funcionário possui a permissão de desbloqueio
5a. 4 – O sistema desbloqueia o orçamento.
6.2a. 2 – O funcionário informa os dados do novo produto.
Quadro 45: Caso de uso expandido “Organizar estoque de mídia”

CASO DE USO: ORGANIZAR ESTOQUE DE MÍDIA
ID: UC 07
Precondições: O funcionário tem privilégio para organizar o estoque
Fluxo principal:
1. O funcionário informa os dados da mídia.
2. O funcionário informa os filtros de venda.
3. O sistema consulta vendas de acordo com os filtros informados.
4. O funcionário seleciona as vendas nas quais deseja incluir a mídia.
5. O sistema verifica se pelo menos uma venda foi selecionada.
6. O sistema atribui mídia para cada venda selecionada e as altera.
Pós-condições: A mídia foi atribuída para todas as vendas desejadas.
Fluxo alternativo:
5a – Nenhuma venda foi selecionada
5a. 1 – O sistema verifica que o funcionário não selecionou nenhuma venda.
74
5a. 2 – O sistema emite a mensagem “É necessário selecionar pelo menos uma venda”
3.4.2 Determinação dos eventos do sistema
A UML possui um diagrama que é útil para a representação de uma sequência de

eventos dentro de um caso de uso: o diagrama de sequência.
Portanto, para determinar os eventos do sistema foram elaborados diagramas de
sequência e de atividades para cada caso de uso do sistema, esses diagramas são apresentados
pelas ilustrações a seguir:
Ilustração 13: Diagrama de sequência “Realizar login”

75
Ilustração 14: Diagrama de sequência “Realizar venda simples”

76
Ilustração 15: Diagrama de sequência “Realizar venda completa”

77
Ilustração 16: Diagrama de sequência “Estornar venda”
Ilustração 17: Diagrama de sequência “Dar baixa em contas a receber”

78
Ilustração 18: Diagrama de sequência “Elaborar orçamento”

79
Ilustração 19: Diagrama de sequência “Organizar estoque de mídia”
Ilustração 20: Diagrama de atividades “Realizar login”

80
Ilustração 21: Diagrama de atividades “Realizar venda simples”

81
Ilustração 22: Diagrama de atividades “Realizar venda completa”

82
Ilustração 23: Diagrama de atividades “Estornar venda”
Ilustração 24: Diagrama de atividades “Elaborar orçamento”

83
Ilustração 25: Diagrama de atividades “Dar baixa em contas a receber”
Ilustração 26: Diagrama de atividades “Organizar estoque de mídia”

84
3.4.3 Projeto da camada de domínio
O projeto da camada de domínio consiste na elaboração do diagrama de classes de

projeto, no qual são identificados os métodos, atributos e associações de cada classe. A
ilustração a seguir apresenta o diagrama de classes elaborado para a aplicação:
Ilustração 27: Diagrama de classes

85
3.4.4 Projeto da camada de aplicação
O projeto da camada de aplicação consistiu na elaboração de protótipos do sistema. As

ilustrações a seguir referem-se a eles.
Ilustração 28: Tela de login
Ilustração 29: Tela de configuração do sistema

86
Ilustração 30: Tela principal
Ilustração 31: Tela de consulta de vendas (com operação de estorno)

87
Ilustração 32: Tela de cadastro de venda simples
Ilustração 33: Tela de cadastro de cliente
Ilustração 34: Tela de cadastro de venda completa

88
Ilustração 35: Tela de cadastro de orçamento
Ilustração 36: Tela de consulta de contas a receber (com operação de baixa)
Ilustração 37: Tela de organização de estoque de mídia

89
CONCLUSÃO
No decorrer do trabalho foram apresentados os conceitos de engenharia de software e

seus modelos de processo juntamente com a linguagem de modelagem UML e a metodologia
de desenvolvimento RUP, com todas as suas características, conceitos, elementos e fases.
Além disso, foi abordado um estudo de caso que envolveu o desenvolvimento de um sistema
de gestão comercial realizado com base na aplicação da metodologia RUP, apresentando os
requisitos funcionais e não funcionais levantados pela fase de concepção do sistema, a
expansão dos casos de uso e a elaboração dos diagramas de sequência, atividades e classe, e
dos protótipos do sistema, sem deixar de apresentar todas as ferramentas e tecnologias
utilizadas durante o desenvolvimento, bem como o padrão de arquitetura aplicado ao
software.
Foi possível observar que para produzir um software de qualidade é importante seguir
uma série de etapas. A concepção e a elaboração do sistema são as etapas mais importantes do
desenvolvimento, pois são estas que dão base e condução ao projeto, com o objetivo de
facilitar a codificação do projeto e atender às reais necessidades do cliente, minimizando os
erros quanto à projeção do cronograma e estimativas de esforços.
90
REFERÊNCIAS
BOENTE, A.N.; OLIVEIRA, F.S.; A. J.N. RUP como Metodologia de Desenvolvimento de

Software para Obtenção da Qualidade de Software. Disponível em:
<http://www.boente.eti.br/publica/seget2008rup.pdf> Acesso em: 14 set. 2009.
JONES, P.M. Fundamentos do desenho orientado a objetos com UML. 2a ed. São Paulo:
Makron Books, 2001.
PRESSMAN, R.S. Engenharia de software. 6a ed. Rio de Janeiro: McGraw-Hill, 2006
QUICOLI, P.R. Por que a Microsoft desenvolveu o WPF? Disponível em:

<http://pauloquicoli.spaces.live.com/Blog/cns!B27CCFAA07B93BE8!561.entry> Acesso em:
17 out. 2009
SILVA, A.C.: processo unificado. Trabalho acadêmico. Universidade Federal de Maranhão,

2008. Disponível em: <www.deinf.ufma.br/~acmo/MOO_PUintro.pdf> Acesso em: 21 set.
2009.
SOMMERVILLE, I. Engenharia de software. São Paulo: Addison-Wesley, 2003.
SONINNO, B.; SONINNO, R. Introdução ao wpf. Disponível em:

<http://msdn.microsoft.com/pt-br/library/cc564903.aspx> Acesso em: 17 out. 2009.
WAZLAWICK, R.S. Análise e projeto de sistemas de informação orientados a objeto. 7a ed.

Rio de Janeiro: Elsevier, 2004.

Monografia - Amanda

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Monografia - Amanda

Diunggah oleh

Hak Cipta:

Format Tersedia

CENTRO PAULA SOUZA

FACULDADE DE TECNOLOGIA DE TAQUARITINGA

ABORDAGEM DA METODOLOGIA RUP NO

AUTOR: AMANDA MAKINO

ORIENTADOR: PROF. OSWALDO LÁZARO MENDES

ABORDAGEM DA METODOLOGIA RUP NO

Monografia apresentada à Faculdade de Tecnologia de

Orientador: Prof. Oswaldo Lázaro Mendes

Aos meus pais, que sempre lutaram e nunca mediram

O presente trabalho realiza uma abordagem sobre a importância da Engenharia de

Palavras-chaves: Engenharia de software. UML. Sistema de informação. RUP. WPF.

Keywords: Engineering software. UML. Information system. RUP. WPF.

1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE..........................................19

1.1 Engenharia de Software......................................................................................................19

2 RUP - PROCESSO UNIFICADO .....................................................................................23

3.1 Ferramentas e tecnologias aplicadas...................................................................................31

ILUSTRAÇÃO 1: CAMADAS DA ENGENHARIA DE SOFTWARE............................19

ILUSTRAÇÃO 2: DESENVOLVIMENTO ITERATIVO E INCREMENTAL..............25

ILUSTRAÇÃO 3: FASES DO PROCESSO UNIFICADO (RUP).....................................28

ILUSTRAÇÃO 4: ARQUITETURA DO RUP....................................................................29

ILUSTRAÇÃO 5: DIAGRAMA DE CASOS DE USO DO SISTEMA.............................60

ILUSTRAÇÃO 6: DIAGRAMA DE CASO DE USO “REALIZAR LOGIN”.................61

ILUSTRAÇÃO 7: DIAGRAMA DE CASO DE USO “REALIZAR VENDA SIMPLES”

ILUSTRAÇÃO 8: DIAGRAMA DE CASO DE USO “REALIZAR VENDA

ILUSTRAÇÃO 9: DIAGRAMA DE CASO DE USO “ESTORNAR VENDA”...............63

ILUSTRAÇÃO 10: DIAGRAMA DE CASO DE USO “DAR BAIXA EM CONTAS A

ILUSTRAÇÃO 11: DIAGRAMA DE CASO DE USO “ELABORAR ORÇAMENTO”64

ILUSTRAÇÃO 12: DIAGRAMA DE CASO DE USO “ORGANIZAR ESTOQUE

ILUSTRAÇÃO 13: DIAGRAMA DE SEQUÊNCIA “REALIZAR LOGIN”..................74

ILUSTRAÇÃO 14: DIAGRAMA DE SEQUÊNCIA “REALIZAR VENDA SIMPLES”

ILUSTRAÇÃO 16: DIAGRAMA DE SEQUÊNCIA “ESTORNAR VENDA”................77

ILUSTRAÇÃO 17: DIAGRAMA DE SEQUÊNCIA “DAR BAIXA EM CONTAS A

ILUSTRAÇÃO 18: DIAGRAMA DE SEQUÊNCIA “ELABORAR ORÇAMENTO”...78

ILUSTRAÇÃO 19: DIAGRAMA DE SEQUÊNCIA “ORGANIZAR ESTOQUE DE

ILUSTRAÇÃO 20: DIAGRAMA DE ATIVIDADES “REALIZAR LOGIN”.................79

ILUSTRAÇÃO 21: DIAGRAMA DE ATIVIDADES “REALIZAR VENDA SIMPLES”

ILUSTRAÇÃO 22: DIAGRAMA DE ATIVIDADES “REALIZAR VENDA

ILUSTRAÇÃO 23: DIAGRAMA DE ATIVIDADES “ESTORNAR VENDA”...............82

ILUSTRAÇÃO 24: DIAGRAMA DE ATIVIDADES “ELABORAR ORÇAMENTO”. 82

ILUSTRAÇÃO 25: DIAGRAMA DE ATIVIDADES “DAR BAIXA EM CONTAS A

ILUSTRAÇÃO 26: DIAGRAMA DE ATIVIDADES “ORGANIZAR ESTOQUE DE

ILUSTRAÇÃO 27: DIAGRAMA DE CLASSES................................................................84

ILUSTRAÇÃO 28: TELA DE LOGIN.................................................................................85

ILUSTRAÇÃO 30: TELA PRINCIPAL..............................................................................86

ILUSTRAÇÃO 31: TELA DE CONSULTA DE VENDAS (COM OPERAÇÃO DE

ILUSTRAÇÃO 32: TELA DE CADASTRO DE VENDA SIMPLES...............................87

ILUSTRAÇÃO 33: TELA DE CADASTRO DE CLIENTE..............................................87

ILUSTRAÇÃO 34: TELA DE CADASTRO DE VENDA COMPLETA..........................87

ILUSTRAÇÃO 35: TELA DE CADASTRO DE ORÇAMENTO.....................................88

ILUSTRAÇÃO 36: TELA DE CONSULTA DE CONTAS A RECEBER (COM

ILUSTRAÇÃO 37: TELA DE ORGANIZAÇÃO DE ESTOQUE DE MÍDIA................88

QUADRO 1: REALIZAR LOGIN.......................................................................................40

QUADRO 2: CONFIGURAR DADOS DE CONEXÃO....................................................40

QUADRO 3: CONFIGURAR JANELA PRINCIPAL.......................................................41

QUADRO 4: CADASTRAR USUÁRIO..............................................................................41

QUADRO 5: CONFIGURAR CONTA USUÁRIO............................................................42

QUADRO 6: CADASTRAR TIPO DE OBSERVAÇÃO...................................................42

QUADRO 7: CADASTRAR STATUS DE CLIENTE.......................................................43

QUADRO 8: CADASTRAR STATUS DE VENDA...........................................................43

QUADRO 9: CADASTRAR SERVIÇO..............................................................................44

QUADRO 10: CADASTRAR FORNECEDOR...................................................................44

QUADRO 11: CADASTRAR PRODUTO..........................................................................45

QUADRO 12: CADASTRAR CLIENTE.............................................................................45

QUADRO 13: CADASTRAR OBSERVAÇÕES DO CLIENTE......................................46