Escolar Documentos
Profissional Documentos
Cultura Documentos
PRÓ-REITORIA ACADÊMICA
CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ALEXANDRE DE ALMEIDA
REGINALDO DAROLT
ARARANGUÁ – SC
2001
UNISUL – UNIVERSIDADE DO SUL DE SANTA CATARINA
PRÓ-REITORIA ACADÊMICA
CENTRO DE CIÊNCIAS EXATAS, AGRÁRIAS E DAS ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ALEXANDRE DE ALMEIDA
REGINALDO DAROLT
ARARANGUÁ – SC
2001
ii
TERMO DE APROVAÇÃO
PROJETO DE CONCLUSÃO DE CURSO
AGRADECIMENTOS
A Deus.
Ana Claudia, Rafael Ávila Faraco, Luciano Savio e Carlos Fernando Buss, os
SUMÁRIO
RESUMO............................................................................................................. xiv
ABSTRACT.......................................................................................................... xv
1.3 Justificativa................................................................................................ 3
1.5 Metodologia............................................................................................... 4
2.1 Conceito.................................................................................................... 8
2.5 Objetos.................................................................................................... 11
4.3 Projeto..................................................................................................... 21
4.4 Programação........................................................................................... 22
5.1 Conceito.................................................................................................. 24
5.2 Vantagens............................................................................................... 26
6.1 Conceito.................................................................................................. 30
vii
7.3 Objetos.................................................................................................... 39
7.6 Componentes.......................................................................................... 43
7.7.1.8 Agregação...................................................................................... 49
viii
7.7.2 Generalizações................................................................................. 50
8.1 Conceito.................................................................................................. 55
9.2.4 Impressão......................................................................................... 71
9.6 Projeto..................................................................................................... 90
x
9.7 Implementação........................................................................................ 95
LISTA DE FIGURAS
RESUMO
ABSTRACT
contacts until the final version is very important. The UML (Unified Modeling
system development that joints all the steps of the process, since the first
observations that will serve as conclusion and basis for future improvement.
Capítulo 1 - INTRODUÇÃO
1.1 Apresentação
projeto específico.
sua abrangência. Pois a UML traz novos conceitos que normalmente não são
orientada a objetos.
2000].
forma que qualquer sistema, seja qual for o tipo, possa ser modelado
funcionalidade.
3
desenvolvimento de sistemas;
sistemas;
1.3 Justificativa
1.4 Abrangência
também executáveis;
uso da UML.
1.5 Metodologia
metodologia;
1.6 Estrutura
visões.
Relacionamentos.
diagramas.
7
desenvolvimento do TCC.
Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A
OBJETOS
2.1 Conceito
válvulas.
diferente, afirmavam que os sistemas tinham que ser modularizados para que
9
fossem de mais fácil manutenção e compreensão. Este conceito foi mais aceito
Marco, 1978]
não é definir como o sistema será desenvolvido, mas sim investigar o problema
2.4 Classes
de combinar num único registro, campos de dados e campos que são funções
2.5 Objetos
do sistema.
2.6 Abstração
maior nos assuntos principais [Cood, 1991]. Consiste na seleção que o analista
de Procedimentos e de Dados.
pode ser tratada por seus usuários como uma entidade única, mesmo que a
aplicáveis aos objetos deste tipo. Porém, estes objetos só podem ser
2.7 Encapsulamento
mesma. É fundamental que o objeto proteja seus dados, não permitindo que o
2.8 Herança
casos específicos.
14
2.9 Polimorfismo
que são relacionadas por alguma superclasse comum, assim, qualquer objeto
3.1 Introdução
3.2 Histórico
captura de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil
linguagem que iria desde o conceito até o sistema executável, não somente a
problemas que não fossem sistemas de informação, podendo ser utilizado por
completa da UML.
Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris
1997. Em setembro do mesmo ano, essa versão foi aceita pela ADTF (Analysis
revisão editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF
3.3 Aceitação
3.4 Padronização OM G
vários desenvolvedores.
qualidade da linguagem para tal. Pois para serem realmente utilizadas por
3.5 Aplicação
4.2 Análise
descrição dos “use-cases”, podendo estas estar ligados uma nas outras
através de relacionamentos.
4.3 Projeto
feita uma junção das classes da fase da análise com as classes técnicas da
4.4 Programação
programação.
23
4.5 Testes
pois estes tem um conhecimento das classes e grupo de classes que envolvem
esta rotina, sabendo desta forma onde estão os pontos mais críticos que
podem causar falhas. A outra forma de testes de uma rotina é feita por outro
usuário, pois este irá fazer um teste do seu modo, tendo a visão da rotina como
Por fim, o sistema será testado pelo usuário final e este verificará se
5.1 Conceito
Medicina, etc) mas não se utilizavam de software para fazer seu trabalho.
estejam ficando cada vez mais importantes nos dias de hoje [Cood, 1991].
Ferramentas Case.
25
nível de documentação.
metodologias.
5.2 Vantagens
tempo;
problema do usuário;
5.4 O Futuro
forma fechada, mas de uma forma aberta de maneira que as mesmas cada vez
hoje em dia, pois com ele há uma documentação interativa e automática dos
mais complexos.
6.1 Conceito
O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e
uma visão fazer parte de uma ou mais visões. Os diagramas que compõem as
31
atividade.
aspecto, que é uma propriedade não funcional do sistema, permite uma melhor
7.1 Definição
existem regras que definem quais elementos podem ser mostrados em que
7.2 Classes
embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
36
7.2.1 Nomes
Usamos uma seqüência de caracteres para identificá-las. Uma classe pode ter
7.2.2 Atributos
representa o tipo de dados ou estados que cada item de uma classe pode
assumir, são representados logo após o nome da classe (veja Figura 7.3).
38
7.2.3 Operações
poderá ter que identificar seu um dado atributo é somente para leitura(isto é, o
Uma classe pode ter várias operações ou até mesmo nenhuma, são
7.3 Objetos
coisa que tenha algum significado para uma dada aplicação [Mazzola,
7.4 Estados
objetos.
Fazer.
7.5 Pacotes
vários modelos de elementos, e isto significa que estes não podem ser
7.6 Componentes
7.7 Relacionamentos
classe) do elemento mais específico pode ser usada onde o elemento mais
7.7.1 Associações
classes. É representada por uma linha sólida entre duas classes. A associação
45
que esta só pode ser usada para o lado onde a seta aponta. Mas associações
também podem possuir dois nomes, significando um nome para cada sentido
ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários
(1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também possível
expressar uma série de números como (1, 4, 6..12). Se não for descrito
apenas 1).
associação "n" é identificado, e pode ser visto como um tipo de chave para
especifica que objetos de uma classe podem participar de no máximo uma das
por uma linha tracejada entre as associações que são parte da associação
padrão para uma associação é desordenada ou seja não possui uma ordem
ajudando pois existem casos que a ordem precisa estar concisa para o
Uma classe pode ser associada a uma outra associação. Este tipo
são adicionados à associação, ela deve ser mostrada como uma classe.
7.7.1.8 Agregação
As palavras chaves usadas para identificar uma agregação são: "consiste em",
compartilhadas e as compostas.
uma parte, ou está contida na outra, mas esta parte pode estar contida na
7.7.2 Generalizações
Uma classe pode ser tanto uma subclasse quanto uma superclasse,
classes que fazem o relacionamento, sendo que coloca-se uma seta no lado da
uma subclasse:
linguagem.
52
semântico entre dois ou mais elementos do modelo onde uma classe cliente é
elementos podem ser uma classe, um pacote, um use-case e assim por diante.
Quando uma classe recebe um objeto de outra classe como parâmetro, uma
classe acessa o objeto global da outra. Nesse caso existe uma dependência
com uma seta no final de um dos lados do relacionamento. E sobre essa linha
relacionamento de dependência.
coisa (uma implementação simples e outra mais complexa, mas também mais
eficiente).
são feitos devem ser coordenados. Coordenação de modelos pode ser usada
relacionam.
informações adicionais.
envolvido na relação.
• Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem
Figura 7.23).
8.1 Conceito
[Larman, 2000].
utilizando a UML.
caso de uso representa a participação deste ator no caso de uso. Além deste
uso:
inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de
limite).
Uma generalização é representada por uma linha com um triângulo, que liga a
objetos que colaboram entre si, mas sem qualquer uma das mensagens
momento no tempo.
estáticos.
durante sua vida em resposta a estímulos recebidos, junto com suas próprias
de qual estado ele está inicialmente, e para qual estado ele vai passar quando
determinado momento.
estado para o outro. Cada linha de transição é rotulada com o evento que
causou a transição.
62
as mensagens que são passadas entre estes objetos dentro do caso de uso,
[Furlan, 1998].
64
mostrando o fluxo de controle de uma atividade para outra [Booch, 2000] (ver
Figura 8.7).
estado, onde todos os estados têm uma ação interna e nenhuma transição tem
processamentos paralelos.
representam quem faz o que. Isso significa que o diagrama não diz qual classe
1998].
9.1 Introdução
orientados a objetos. Porém não prescreve como o trabalho deve ser feito.
programação e testes.
9.2 Documentação
plataformas diferentes.
9.2.1 Fonte
aspecto.
preocupar em estabelecer uma fonte que toda a equipe envolvida e até mesmo
10 a 14.
pasta. Estas pastas devem estar identadas sempre abaixo de uma que englobe
o projeto como um todo, ou até mesmo o nome do projeto. Cria-se uma pasta
outras pastas filhas. Todas as pastas criadas devem sempre fazer relação com
editor, etc. Muito importante para uma boa definição deste item, é saber quais
no projeto possuem.
ferramentas com um pouco mais de recursos, pois arquivos com este tipo de
que os .txt (modo caracter), procurar usar extensões de arquivos que abram na
9.2.4 Impressão
pouco menores ou maiores devido a sua complexidade. Sendo que para sua
9.2.5 Backup
lançamentos, consultas.
9.3.1 Contatos
marcada. Como trata-se de algo bem genérico, através deste formulário ainda
não se sabe com certeza quem será envolvido no sistema. Define-se tanto os
software.
analisado:
desenvolvedora.
negócio e da descrição, pois é ali que contém alguns conceitos básicos que
possíveis participantes.
convocados.
itens técnicos como: atores, casos de uso, diagrama de casos de uso e análise
de riscos.
9.4.1 Reunião/Entrevista
de nível mais alto prevaleceria sobre as demais, sem nenhuma garantia de que
utilizada?
efetividade da reunião:
são "oficiais"?
desenvolvedores e clientes;
reunião;
deve comportar o sistema ou o que ele deve atingir. Todas as idéias devem ser
incluídas na ata pois serão a partir delas que será dado o start no projeto.
essenciais .
uso) .
do projeto também faz parte deste resumo, tais como equipamentos, fontes de
referência.
80
9.4.5 Atores
atores é sempre bom pensar neles como papéis em vez de pensar como
permissões, para isto é necessário criar um ator para cada diferente tipo de
Cada ator deve possuir um nome cujo terá relação direta com a sua
função, possuirá uma descrição que definirá o que ele faz e com quem ele
interage.
os casos de uso.
Você pode imaginar um caso de uso como um conjunto de cenários, onde cada
81
detalhamento vai depender do risco que o mesmo corre, quanto maior o risco,
casos de usos mais críticos para o sistema, os casos de uso que são tarefas
de 10 à 20(%) dos casos de uso mais críticos de seu sistema, estes números
assim facilitará no entendimento dos mesmos. Devemos possuir uma lista com
todos os nomes dos casos de usos para facilitar na identificação dos mesmos.
9.4.7 Escopo
como ele irá interagir com o mundo externo. Esta visão é transformação de
algumas mais críticas, estas deverão ser tratadas com mais importância, pois
projetos:
• Caso encontre problemas, estes serão resolvidos de forma que não altere o
cronograma do projeto?
custos de desenvolvimento?
9.4.10 Cronograma
projeto.
9.4.11 Aprovação
9.5 Análise
de estado e atividade.
relacionamentos dar-se-á mais atenção aos quatro principais tipos que são:
de todas as partes.
diagramas de classes:
• Não devemos nos preocupar muito em usar toda a teoria envolvida nos
forem necessárias.
da classe.
objetos.
objetos.
colaboração.
determinado propósito.
retângulo no topo de uma linha vertical tracejada projetada para baixo. Esta
cenários complexos.
88
um caso de uso.
tivermos que decidir entre qual diagrama devemos adotar para estudar uma
evidenciada.
89
interna.
diagramas de estados:
como:
casos de uso;
• Mostrar como uma instância de caso de uso pode ser realizada em termos
9.6 Projeto
e de implementação de runtime.
implantação.
restrições.
formas:
transformá-lo em componentes;
92
arquivos de código-fonte;
relacionamentos.
é executado.
dispositivos;
dispositivos inteligentes.
servidor do sistema;
94
estereótipos
mais simples;
9.7 Implementação
9.7.1 Tradução
• Considerações de desempenho;
múltipla e polimorfismo.
desenvolvido. Porém devem ser bastante estudadas pois uma falha no modelo
• Não usar nomes muito extensos, mas que expresse o seu propósito. Neste
programador.
abaixo [1995]:
98
sempre nos preocupar com sua estética, procuramos sempre elaborar códigos
conteúdo da instrução;
99
autor deste?
9.8 Testes
Certamente que os projetistas codificam o software para que não haja erros.
contemplado, observando seu fluxo normal e quando este fluxo não é seguido
unidade.
tratamento de erros.
entrada atual;
4. Underflow e Overflow.
processamento.
foram executadas pelo menos uma vez. Os erros mais comuns são :
3. Inicialização incorreta;
4. Erros de precisão;
ao módulo principal.
problemas de uso.
computador.
tempo real.
desempenho do projeto.
105
10.1 Introdução
Linguagem.
Fonte
Gravação
107
sistema de contabilidade.
Impressão
Backup
Periodicidade: Semanal.
Versão: 1.0A-01
Data: 14/03/2001
Departamento: Gerencial
Fone: 048-4371159
Fax : 048-4376020
Ramal: 203
Email: joaocri@terra.com.br
Silva
Objetivos:
objetivos da reunião.
Definições da reunião:
3.Procedimentos:
• Cadastro de Usuários.
• Lançamentos.
• Emissão de relatórios.
4.Relatórios:
• Acompanhamento de lançamentos.
5.Usuários:
• Contador
• Digitador
mensal.
também os relatórios legais tais como: Diário, Razão, DRE, Balanço e Livro
Caixa.
máquinas com configuração igual ou superior a PII 233 Mhz com 32 Mb.
10.6 Escopo
Contabilidade.
113
Contabilidade.
114
• Documentação
Pontos Fortes:
Pontos Fracos:
• Eventos Iniciais
Pontos Fortes:
cliente.
• Análise de Requisitos
Pontos Fortes:
cliente e os desenvolvedores.
Pontos Fracos:
• Análise
Pontos Fortes:
sistema.
Pontos Fracos:
• Projeto
Pontos Fortes:
finalidade.
• Implementação
Pontos Fortes:
do projeto.
118
• Testes
seus métodos torna essa tarefa cansativa e também eleva os custos. É uma
fase que pode ser eliminada sem comprometer a fase de testes do projeto.
ponto de vista é o mais importante, os demais são apenas citados para que
Capítulo 12 - CONCLUSÃO
documentação(requisitos e código-fonte).
12.1 Recomendações
encontrados.
desenvolvida.
Consultada em 24/03/2001.
http://www.dcc.ufmg.br/~gorgulho/tbd/seminario.html. Consultada em
24/03/2001.
http://www.dcc.ufmg.br/pos/html/spg98/node3.html . Consultada em
24/03/2001.
Consultada em 24/03/2001.
2000.
13. FOWLER, Martin, Kendal Scott. UML ESSENCIAL : Um breve guia para a
2000.
Books.
Consultada em 05/04/2001.
Consultada em 30/10/2001.
124
Fonte
Gravação
Impressão
Backup
Periodicidade:
Versão: <N.NX-NN>
125
Fone:
Fax :
Ramal:
Email:
atender ou não>
prioridade do pedido>
pois será estudada pela equipe onde será discutido a possibilidade ou não de
ser efetuada>
126
os setores atendidos>
desenvolvimento do sistema>
na reunião>
127
Nome Descrição
caso de uso>
com maior freqüência. Esta seqüência deverá ser ordenada e cada passo
que tem que ocorrer para que o caso de uso seja válido>
de uso>
diagrama>
diagrama>
relacionados no diagrama>
Responsáveis:
Aprovado por
Nome Assinatura