Вы находитесь на странице: 1из 148

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

PESQUISA E DESENVOLVIMENTO EM UML

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

PESQUISA E DESENVOLVIMENTO EM UML

ALEXANDRE DE ALMEIDA
REGINALDO DAROLT

Projeto apresentado à disciplina de


Projetos em Ciência da Computação II,
coordenado pelo Professor Luciano
Savio e orientado pelo Professor
Alessandro Zanini.

ARARANGUÁ – SC
2001
ii

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

TERMO DE APROVAÇÃO
PROJETO DE CONCLUSÃO DE CURSO

Aprovamos o Projeto PESQUISA E DESENVOLVIMENTO EM UML, elaborado


pelos alunos ALEXANDRE DE ALMEIDA e REGINALDO DAROLT,
apresentado com requisito parcial para a obtenção de Grau em Bacharel em
Ciência da Computação.

Prof. Carlos Fernando Buss


Coord. do Curso de Ciências da Computação
Banca de Avaliação

Prof. Luciano Savio


Coordenador de PCC

Prof. Alessandro Zanini


Orientador

Prof. Ana Cláudia G. Barbosa


Convidada

Prof. Juarez Bento Da Silva


Convidado
ARARANGUÁ – SC
2001
iii

Dedicamos este Trabalho a nossos pais, namoradas e familiares que

sempre nos apoiaram e estiveram a nosso lado em todos os momentos.


iv

AGRADECIMENTOS

A Deus.

A todos os colegas e professores, em especial Alessandro Zanini,

Ana Claudia, Rafael Ávila Faraco, Luciano Savio e Carlos Fernando Buss, os

quais nos incentivaram e deram apoio no desenvolvimento deste Projeto.

As empresas Seara Alimentos S/A, Domínio Sistemas Ltda e Betha

Sistemas Ltda, em especial ao colega Cristiano Tomasi(Betha Sistemas Ltda).


v

SUMÁRIO

LISTA DE FIGURAS ............................................................................................ xii

RESUMO............................................................................................................. xiv

ABSTRACT.......................................................................................................... xv

Capítulo 1 - INTRODUÇÃO ................................................................................... 1

1.1 Apresentação ............................................................................................ 1

1.2 Objetivos Geral e Específicos ................................................................... 2

1.3 Justificativa................................................................................................ 3

1.4 Abrangência .............................................................................................. 4

1.5 Metodologia............................................................................................... 4

1.6 Estrutura ................................................................................................... 5

Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A OBJETOS ..................... 8

2.1 Conceito.................................................................................................... 8

2.2 Análise Orientada a Objetos ..................................................................... 9

2.3 Projeto Orientado a Objetos.................................................................... 10

2.4 Classes ................................................................................................... 11

2.5 Objetos.................................................................................................... 11

2.6 Abstração ................................................................................................ 12


vi

2.6.1 Abstração de Procedimentos ........................................................... 12

2.6.2 Abstração de dados.......................................................................... 12

2.7 Encapsulamento ..................................................................................... 13

2.8 Herança .................................................................................................. 13

2.9 Polimorfismo ........................................................................................... 14

Capítulo 3 - UML ................................................................................................. 15

3.1 Introdução ............................................................................................... 15

3.2 Histórico .................................................................................................. 16

3.3 Aceitação ................................................................................................ 18

3.4 Padronização OMG................................................................................. 19

3.5 Aplicação ................................................................................................ 19

Capítulo 4 - ETAPAS DO DESENVOLVIMENTO DE SISTEMAS EM UML ....... 20

4.1 Análise de Requisitos.............................................................................. 20

4.2 Análise .................................................................................................... 21

4.3 Projeto..................................................................................................... 21

4.4 Programação........................................................................................... 22

4.5 Testes ..................................................................................................... 23

Capítulo 5 - FERRAMENTAS CASE................................................................... 24

5.1 Conceito.................................................................................................. 24

5.2 Vantagens............................................................................................... 26

5.3 Aceitação no Mercado ............................................................................ 27

5.4 O Futuro .................................................................................................. 28

5.5 Rational Rose.......................................................................................... 28

Capítulo 6 - VISÕES DE SISTEMAS................................................................... 30

6.1 Conceito.................................................................................................. 30
vii

6.2 Visão USE-CASE.................................................................................... 31

6.3 Visão Lógica............................................................................................ 31

6.4 Visão de Componentes........................................................................... 32

6.5 Visão de concorrência............................................................................. 32

6.6 Visão de Organização............................................................................. 33

Capítulo 7 - MODELOS DE ELEMENTOS.......................................................... 34

7.1 Definição ................................................................................................. 34

7.2 Classes ................................................................................................... 35

7.2.1 Nomes .............................................................................................. 36

7.2.2 Atributos ........................................................................................... 37

7.2.3 Operações ........................................................................................ 38

7.3 Objetos.................................................................................................... 39

7.4 Estados ................................................................................................... 40

7.5 Pacotes ................................................................................................... 42

7.6 Componentes.......................................................................................... 43

7.7 Relacionamentos .................................................................................... 43

7.7.1 Associações ..................................................................................... 44

7.7.1.1 Associações Normais .................................................................... 44

7.7.1.2 Associações Recursivas ................................................................ 45

7.7.1.3 Associações Qualificadas .............................................................. 46

7.7.1.4 Associações Exclusivas ................................................................. 46

7.7.1.5 Associações Ordenadas ................................................................ 47

7.7.1.6 Associações de Classe .................................................................. 47

7.7.1.7 Associações Ternárias................................................................... 48

7.7.1.8 Agregação...................................................................................... 49
viii

7.7.2 Generalizações................................................................................. 50

7.7.2.1 Generalização Normal ................................................................... 50

7.7.2.2 Generalização Restrita .................................................................. 51

7.7.3 Dependências e Refinamentos ........................................................ 52

7.8 Mecanismos Gerais ................................................................................ 53

Capítulo 8 - DIAGRAMAS ................................................................................... 55

8.1 Conceito.................................................................................................. 55

8.2 Diagramas de Casos de Uso .................................................................. 56

8.3 Diagramas de Classes ............................................................................ 57

8.4 Diagramas de Objetos ............................................................................ 59

8.5 Diagramas de Estados............................................................................ 61

8.6 Diagramas de Seqüência........................................................................ 62

8.7 Diagramas de Colaboração .................................................................... 63

8.8 Diagramas de Atividade .......................................................................... 64

8.9 Diagramas de Componentes .................................................................. 65

8.10 Diagramas de Implantação ................................................................... 66

Capítulo 9 - METODOLOGIA DESENVOLVIDA................................................. 68

9.1 Introdução ............................................................................................... 68

9.2 Documentação ........................................................................................ 69

9.2.1 Fonte ................................................................................................ 69

9.2.2 Gravação da Documentação ............................................................ 70

9.2.3 Extensão de Arquivos....................................................................... 71

9.2.4 Impressão......................................................................................... 71

9.2.5 Backup ............................................................................................. 72

9.2.6 Controle de Versões......................................................................... 72


ix

9.3 Eventos Iniciais ....................................................................................... 73

9.3.1 Contatos ........................................................................................... 74

9.3.2 Estudo dos Dados ............................................................................ 74

9.3.3 Definição dos Participantes .............................................................. 75

9.4 Análise de requisitos ............................................................................... 76

9.4.1 Reunião/Entrevista ........................................................................... 76

9.4.2 Preenchimento da ata da reunião..................................................... 79

9.4.3 Definições de responsabilidades ...................................................... 79

9.4.4 Resumo do Projeto........................................................................... 79

9.4.5 Atores ............................................................................................... 80

9.4.6 Casos de Uso ................................................................................... 80

9.4.7 Escopo ............................................................................................. 81

9.4.8 Diagrama de caso de uso................................................................. 82

9.4.9 Análise de riscos .............................................................................. 82

9.4.10 Cronograma ................................................................................... 83

9.4.11 Aprovação ...................................................................................... 84

9.5 Análise .................................................................................................... 84

9.5.1 Diagrama de Classes ....................................................................... 84

9.5.2 Diagrama de Objetos........................................................................ 85

9.5.3 Diagramas de Interação ................................................................... 86

9.5.3.1 Diagrama de Seqüência ................................................................ 87

9.5.3.2 Diagrama de Colaboração ............................................................. 88

9.5.4 Diagrama de Estado......................................................................... 89

9.5.5 Diagrama de Atividade ..................................................................... 89

9.6 Projeto..................................................................................................... 90
x

9.6.1 Diagrama de implementação............................................................ 91

9.6.1.1 Diagrama de componente.............................................................. 91

9.6.1.2 Diagrama de implantação .............................................................. 93

9.7 Implementação........................................................................................ 95

9.7.1 Tradução .......................................................................................... 95

9.7.2 Escolha da Linguagem ..................................................................... 95

9.7.3 Documentação do Código ................................................................ 97

9.8 Testes ..................................................................................................... 99

9.8.1 Planejamento de Testes................................................................... 99

9.8.2 Execução de Testes ....................................................................... 100

9.8.2.1 Teste de Unidade......................................................................... 100

9.8.2.2 Teste de Integração ..................................................................... 102

9.8.2.3 Teste de Validação ...................................................................... 103

9.8.2.4 Teste de Sistemas ....................................................................... 104

9.8.3 Avaliação dos Resultados .............................................................. 104

Capítulo 10 - Validação da Metodologia ......................................................... 106

10.1 Introdução ........................................................................................... 106

10.2 Formulário de Documentação ............................................................. 106

10.3 Contatos Iniciais.................................................................................. 107

10.4 Ata da Reunião ................................................................................... 108

10.5 Resumo do Projeto ............................................................................. 109

10.6 Escopo ................................................................................................ 110

10.7 Lista de Casos de Uso ........................................................................ 111

10.8 Diagrama de Caso de Uso .................................................................. 112

10.9 Diagrama de Classes.......................................................................... 113


xi

10.10 Escolha da Linguagem...................................................................... 114

Capítulo 11 - RESULTADOS OBTIDOS ........................................................... 115

Capítulo 12 - CONCLUSÃO .............................................................................. 119

12.1 Recomendações ................................................................................. 120

Capítulo 13 - BIBLIOGRAFIA ........................................................................... 121


xii

LISTA DE FIGURAS

Figura 2.1 : Análise Orientada a Objeto............................................................ 10

Figura 2.2 : Projeto Orientado a Objetos .......................................................... 11

Figura 6.1 : Visões de Sistemas ........................................................................ 31

Figura 7.1 : Classes ............................................................................................ 36

Figura 7.2 : Nomes ............................................................................................. 37

Figura 7.3 : Atributos.......................................................................................... 38

Figura 7.4 : Operações ....................................................................................... 39

Figura 7.5 : Objetos ............................................................................................ 40

Figura 7.6 : Estados............................................................................................ 41

Figura 7.7 : Pacotes............................................................................................ 42

Figura 7.8 : Componentes.................................................................................. 43

Figura 7.9 : Associações Normais .................................................................... 45

Figura 7.10 : Associações Recursiva................................................................ 46

Figura 7.11 : Associações Qualificadas ........................................................... 46

Figura 7.12 : Associações Exclusivas .............................................................. 47

Figura 7.13 Associações de Classe .................................................................. 48

Figura 7.14 : Associações Ternárias................................................................. 48


xiii

Figura 7.15 : Agregação ..................................................................................... 49

Figura 7.16 : Agregação Compartilhada ........................................................... 49

Figura 7.17 : Agregação de Composição ......................................................... 49

Figura 7.18 : Generalização Normal .................................................................. 50

Figura 7.19 : Generalização de Sobreposição ................................................. 51

Figura 7.20 : Generalização Completa .............................................................. 52

Figura 7.21 : Relação de Dependência ............................................................. 52

Figura 7.22 : Refinamentos................................................................................ 53

Figura 7.23 : Ornamentos e Nota ...................................................................... 54

Figura 8.1 : Diagramas de Casos de Uso ......................................................... 57

Figura 8.2 : Diagramas de Classes ................................................................... 59

Figura 8.3 : Diagramas de Objeto...................................................................... 60

Figura 8.4 : Diagramas de Estados ................................................................... 62

Figura 8.5 : Diagramas de Seqüência ............................................................... 63

Figura 8.6 : Diagramas de Colaboração ........................................................... 64

Figura 8.7 : Diagramas de Atividade ................................................................. 65

Figura 8.8 : Diagramas de Componentes ......................................................... 66

Figura 8.9 : Diagramas de Implantação ............................................................ 67

Figura 10.1 Escopo do Sistema....................................................................... 111

Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade.......... 113

Figura 10.3 Diagrama de Classes do Sistema de Contabilidade.................. 114


xiv

RESUMO

Usar uma metodologia de desenvolvimento de sistema para captar

desde os primeiros contatos, até a conclusão das etapas de desenvolvimento

de software, é de extrema importância. A UML(Unified Modeling Language) é a

junção das três mais conceituadas linguagens de modelagem orientados a

objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh), porém

a UML não possui um método de trabalho a ser seguido.

Este trabalho estuda a UML para que se possa criar uma

metodologia de desenvolvimento de sistemas que englobe todas as fases do

processo, desde os eventos iniciais, passando pela Análise de Requisitos,

Análise, Projeto, Programação e Testes.

Para a validação da metodologia desenvolvida será aplicada no

desenvolvimento de um protótipo. Utilizaremos a ferramenta case Rational

Rose, da Rational Software Corporation no apoio a modelagem do sistema.

Ao final do desenvolvimento de cada fase serão feitas observações

que servirão de conclusão e base para futuros melhoramentos.


xv

ABSTRACT

To use a metodology of system development to obtain since the first

contacts until the final version is very important. The UML (Unified Modeling

Language) is the junction of three most respected language of model oriented

for objects (Booch of Grady, OOSE of Jacobson and OMT of Rumbaugh)

[Booch,2001], but the UML doesn’t have a work metod to be follwed.

The paper studies the UML in order to create a metodology of

system development that joints all the steps of the process, since the first

events, passing through the Analysis of Requisites, Analysis, Project,

Programming and Tests.

For the validation of the developed metodology we’ll aplicate on the

development of a prototype, where it will be used the instrument Rational Rose,

of Ratonal Software Corporation, to support the system model.

By the end of the development of each phasis, will be made

observations that will serve as conclusion and basis for future improvement.
Capítulo 1 - INTRODUÇÃO

1.1 Apresentação

Um grande problema no desenvolvimento de novos sistemas

utilizando a orientação a objetos é o fato de não existir uma notação

padronizada e realmente eficaz que possa abranger qualquer tipo de aplicação.

Cada metodologia existente possui suas próprias notações (símbolos usados

para projetar modelos orientados a objetos), processos e ferramentas. Isso faz

com que a escolha do método a ser utilizado torne-se uma decisão

extremamente importante e freqüentemente leva a discussões e debates sobre

qual o melhor método, o mais avançado e adequado para ser utilizado em um

projeto específico.

Com o lançamento da UML (Unified Modeling Language)

desenvolvedores da área de orientação a objetos, ficaram entusiasmados com

sua abrangência. Pois a UML traz novos conceitos que normalmente não são

usados. Um bom entendimento da UML não é somente um conhecimento de


2

sua símbologia e significados, mas também um contexto geral de modelagem

orientada a objetos.

Com a junção das três mais conceituadas metodologias(Booch de

Grady, OOSE de Jacobson e o OMT de Rumbaugh) de modelagem orientado

a objetos criou-se a UML aproveitando o que havia de melhor em cada uma

delas adicionando conceitos e visões da linguagem. UML permite comunicar

certos conceitos mais claramente que as linguagens alternativas [Fowler,

2000].

A UML é uma padronização de modelagem orientado a objetos de

forma que qualquer sistema, seja qual for o tipo, possa ser modelado

corretamente, com consistência, fácil de se comunicar com outras aplicações,

simples de ser atualizado e compreensível.

Com este projeto pretendemos justamente pesquisar sobre esta

linguagem de modelagem, suas aplicações, vantagens e desvantagens. Como

conseqüência dessa pesquisa definiremos uma metodologia de

desenvolvimento de sistemas baseada em UML, a qual analisamos ser o mais

eficaz às necessidades atuais de desenvolvimento.

1.2 Objetivos Geral e Específicos

Objetivamos com esta pesquisa o estudo aprofundado de uma

metodologia unificada de desenvolvimento de sistemas orientado a objetos

baseado em UML, com a perspectiva de desenvolver uma metodologia e

aplicá-la desenvolvendo um protótipo, comprovando sua eficiência e

funcionalidade.
3

Especificamente, os objetivos apresentados são:

• Obter amplos conhecimentos sobre UML;

• Mostrar a sociedade a importância do uso de uma metodologia no

desenvolvimento de sistemas;

• Estudar como se desenvolve uma metodologia de desenvolvimento de

sistemas;

• Desenvolver uma metodologia de trabalho baseado em UML;

• Estudo de uma ferramenta CASE, para modelagem do sistema.

• Desenvolvimento de um protótipo usando a metodologia;

• Apresentação do protótipo desenvolvido.

1.3 Justificativa

Com as constantes inovações que surgem em ferramentas de

desenvolvimento de sistemas orientados a objetos e a necessidade de

desenvolvimento de sistemas mais complexos e precisos, faz com que um

estudo sobre uma metodologia unificada de desenvolvimento torne-se um

grande atrativo a ser pesquisado.

Com este interesse, desenvolveremos o presente projeto com o

intuito de apresentar a analistas uma metodologia de desenvolvimento e

salientar a importância de sua aplicação, a qual poderá resolver muitos

problemas encontrados no decorrer de todo o desenvolvimento de um sistema.

Para isto será desenvolvido um protótipo utilizando-se desta metodologia.


4

1.4 Abrangência

A UML tende a ser uma linguagem de desenvolvimento de sistemas

orientado a objetos dominante, comum entre os melhores analistas e

desenvolvedores. Por conseqüência este projeto pretende comprovar a eficácia

do uso desta metodologia, com base no desenvolvimento de um protótipo.

Destacamos os principais tópicos :

A modelagem de sistemas (não apenas de software) usando os

conceitos da orientação a objetos;

Estabelecer uma união fazendo com que métodos conceituais sejam

também executáveis;

Estabelecer um método de comunicação entre toda a equipe

envolvida (cliente, analista, desenvolvedor, etc);

Mostrar a sociedade a qualidade de um sistema desenvolvido com o

uso da UML.

1.5 Metodologia

Para o desenvolvimento do Trabalho de Conclusão de Curso (TCC),

serão definidas as seguintes etapas:

• Estudo da metodologia UML;

• Conceitos sobre esta metodologia;

• Aprimoramento da metodologia usada, visando sua melhor performance;


5

• Estudo e definição de uma ferramenta CASE que melhor atenda a essa

metodologia;

• Estudo e definição de ferramentas para desenvolvimento do sistema;

• Escolha de um sistema para aplicação da metodologia estudada

comprovando sua eficácia;

• Desenvolvimento de um protótipo do sistema;

• Conclusão sobre a metodologia estudada e sua aplicação.

1.6 Estrutura

Este capítulo apresentará a você leitor, uma breve descrição de

cada capítulo que constitui este trabalho.

No capítulo 2 descreveremos um breve conceito da análise e

projetos orientado a objetos bem como sua necessidade, surgimento, etc.

Faremos uma descrição da base da análise e projetos orientado a objetos

descrevendo seus pontos principais como classes, objetos, abstrações, etc.

Este capítulo é importante para o entendimento da análise orientada a objetos.

O capítulo 3 faz uma introdução à UML(Linguagem Unificada de

Modelagem) dizendo o que ela nos disponibiliza, sua aceitação, padronização

e aplicações. Para um melhor entendimento do processo de criação da UML

apresentaremos um histórico completo, desde o início das pesquisas até a

conclusão da última versão.


6

O capítulo 4 descreve as etapas técnicas da UML, baseada nos

conceitos tradicionais das atividades de desenvolvimento. Estas etapas vão

desde os primeiros passos(Análise de Requisitos) até a fase de testes.

O capítulo 5 faz uma descrição sobre ferramenta CASE, apresenta

algumas vantagens da aplicação desta ferramenta e também descreve sua

aceitação no mercado. Ao final deste capítulo ainda apresentamos uma visão

do futuro desta ferramenta.

No capítulo 6 é apresentado um conceito sobre visões em UML e

qual a importância destas visões para o entendimento do sistema. Descreve-se

ainda em detalhes as 5(cinco) visões utilizadas e o uso de cada uma destas

visões.

O capítulo 7 traz uma definição de modelos de elementos e

descreve detalhadamente todos os modelos de elementos utilizados pela UML,

tais como Classes, Objetos, Estados, Pacotes, Componentes e

Relacionamentos.

O capítulo 8 apresenta um conceito genérico sobre diagramas em

UML, descreve detalhadamente os 9(nove) tipos de diagramas utilizados pela

UML, exemplificando graficamente e indicando o uso de alguns tipos de

diagramas.
7

No capítulo 9 apresentaremos a metodologia desenvolvida.

O capítulo 10 mostra um protótipo desenvolvido aplicando a

metodologia do capítulo anterior.

No capítulo 11 mostraremos os resultados obtidos durante a

validação de cada fase da metodologia.

No capítulo 12 faremos nossas conclusões sobre todo o TCC.

O capítulo 13 apresenta toda a bibliografia utilizada no

desenvolvimento do TCC.
Capítulo 2 - ANÁLISE E PROJETOS ORIENTADOS A
OBJETOS

2.1 Conceito

Com os enormes computadores da década de 1950 e 1960, e a

pouca capacidade de processamento, desenvolvedores de programas tinham

que aproveitar ao máximo todo bit que o hardware disponibilizava. Já na

década de 1960 computadores transistorizados foram surgindo, o que na

época já era um grande avanço, substituindo os enormes computadores de

válvulas.

Desenvolvedores mais radicais afirmavam que os algoritmos para os

sistemas que esses computadores rodavam tinham que ser monolíticos. Ou

seja, se já se chegou na melhor fase do algoritmo não é necessário mais

alterações ou manutenções, ficando do mesmo jeito até deixar de ser usado.

Desenvolvedores menos radicais e com uma visão um pouco

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

a medida que os computadores foram aumentando sua capacidade.

Precursores da analise orientada a objeto, defendiam que devíamos

estruturar programas de computador de acordo com o problema a ser

resolvido. O termo Orientação a Objetos sugere abstrações do mundo real e

trechos de programas de computador, ou objeto.

Um grande fator da orientação a objetos é a reusabilidade. Estamos

reutilizando códigos de programas desde o início da computação. As técnicas

de orientação a objetos nos permitem muito mais que a reutilização de códigos,

podemos reutilizar requisitos, análise, projeto, planejamento de testes,

interfaces de usuário e arquiteturas, ou seja todos os componentes de

engenharia de software podem ser encapsulados como reutilizáveis.

2.2 Análise Orientada a Objetos

Análise é o estudo de um problema, antes de qualquer ação [De

Marco, 1978]

Análise é o estudo do domínio de um problema que leva a uma

especificação de comportamentos observáveis externamente. É uma

declaração completa, consistente e possível do que é necessário, um conjunto

de características operacionais quantificadas e funcionais.

Analisar é obter as necessidades de um sistema e o que este

precisa ser desenvolvido para satisfazer as necessidades do usuário. Analisar

não é definir como o sistema será desenvolvido, mas sim investigar o problema

conforme mostra a Figura 2.1.


10

A AOO tem dois propósitos. Primeiramente formalizar uma “visão”

do mundo real dentro do qual o sistema será desenvolvido, estabelecendo os

objetos que servirão como principais estruturas organizacionais do sistema de

software e também as que o mundo real impõe. Em segundo lugar, a AOO

formaliza a colaboração de um dado conjunto de objetos na execução do

trabalho do sistema de software que está sendo especificado. Esta

formalização representa como cada objeto se comunica com os demais.

Figura 2.1 : Análise Orientada a Objeto

2.3 Projeto Orientado a Objetos

O Projeto Orientado a Objetos (PjOO) é visto como o processo de

especificação das partes da construção, ou seja, instruções, guias,

recomendações, estipulações, qualificações, regras, etc.. Utilizamos estes

processos para implementar um sistema em um ambiente específico, em busca

da solução do problema conforme mostra a Figura 2.2.


11

Durante a PjOO é dado ênfase na elaboração dos elementos lógicos

do software [Larman, 2000]. Sendo implementados em uma linguagem de

programação orientada a objetos, os quais possuem atributos e métodos.

Figura 2.2 : Projeto Orientado a Objetos

2.4 Classes

Uma Classe em linguagens Orientadas a Objetos é a possibilidade

de combinar num único registro, campos de dados e campos que são funções

para operar os campos de dados do registro [Furlan, 1998].

2.5 Objetos

Um objeto é simplesmente alguma coisa que faz sentido no contexto

de uma aplicação [Rumbaugh, 1994]. Objeto é uma entidade independente,

assíncrona e concorrente, armazena dados, encapsula serviços, troca


12

mensagens com outros objetos, e é modelado para executar as funções finais

do sistema.

2.6 Abstração

Abstração é o princípio de ignorar os aspectos de um assunto não

relevante para o propósito em questão, tornando possível uma concentração

maior nos assuntos principais [Cood, 1991]. Consiste na seleção que o analista

faz de alguns aspectos, ignorando outros. Existem duas formas de abstração,

de Procedimentos e de Dados.

2.6.1 Abstração de Proc edimentos

Princípio de que qualquer operação com um efeito bem definido

pode ser tratada por seus usuários como uma entidade única, mesmo que a

operação seja realmente conseguida através de alguma seqüência de

operações de nível mais baixo.

2.6.2 Abstração de dado s

Consiste em definir um tipo de dado conforme as operações

aplicáveis aos objetos deste tipo. Porém, estes objetos só podem ser

modificados e observados através destas operações.


13

2.7 Encapsulamento

Encapsular é omitir informações pelo princípio de que uma

determinada entidade esconde informações as quais são necessárias apenas à

mesma. É fundamental que o objeto proteja seus dados, não permitindo que o

usuário do objeto os acesse diretamente. Mas sim através de métodos se

houver necessidade[Furlan, 1998].

2.8 Herança

Esta é provavelmente a característica mais discutida da abordagem

orientada a objetos [Mazzola, 1999].

É a principal característica do processo de

Generalização/Especialização. Através da herança uma determinada sub-

classe herda todos os atributos e métodos da superclasse.

Permite a um analista especificar serviços e atributos comuns uma

só vez, assim como especializar e estender estes atributos e serviços em

casos específicos.
14

2.9 Polimorfismo

È o conceito usado em linguagens de programação orientada a

objetos para denotar a característica de que a linguagem suporta a utilização

do mesmo identificador (o mesmo nome) para métodos de classes diferentes.

Um conceito em teoria de tipo no qual um nome (como uma

declaração de variável) pode denotar objetos de muitas subclasses diferentes

que são relacionadas por alguma superclasse comum, assim, qualquer objeto

denotado por esse nome tem a capacidade de responder a algum conjunto

comum de operações de modos diferentes [Booch, 2000].


Capítulo 3 - UML

3.1 Introdução

A UML é a linguagem padrão para especificar, visualizar,

documentar e construir artefatos de um sistema e pode ser utilizada com todos

os processos ao longo do ciclo de desenvolvimento e através de diferentes

tecnologias de implementação [Furlan, 1998].

A UML disponibiliza uma forma padrão de modelagem de projetos

de Sistemas, incluindo seus aspectos conceituais tais como processos de

negócios e funções do sistema, além de itens concretos como as classes

escritas em determinada linguagem de programação, processos de banco de

dados e componentes de software reutilizáveis.


16

3.2 Histórico

As linguagens de modelagem orientadas a objetos surgiram entre a

metade da década de 1970 e o final da década de 1980, à medida que o

pessoal envolvido com metodologia, diante de um novo gênero de linguagens

de programação orientadas a objeto e de aplicações cada vez mais

complexas, começou a experimentar métodos alternativos de análise e projeto.

A quantidade de métodos orientados a objetos aumentou de pouco mais de 10

para mais de 50 durante o período de 1989 a 1994. Muitos usuários desses

métodos tiveram dificuldades para encontrar uma linguagem de modelagem

capaz de atender inteiramente às suas necessidades. Destacaram-se algumas

linguagens como o Booch, o OOSE (Object-Oriented Software Engineering) de

Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar

outros métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon.

Todos eram métodos completos, alguns se destacavam em algum ponto,

porém tinham suas limitações. O método Booch destacava-se durante as fases

de projeto e construção de sistemas, o OOSE fornecia excelente suporte para

captura de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil

com a análise e sistemas de informações com uso de dados[Booch, 2000].

Na metade da década de 1990, Grady Booch (Rational Software

Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics)

criadores de métodos orientados a objetos, começaram a pegar as melhores

idéias e partiram para a criação de uma linguagem unificada de modelagem.

Com isso esperavam fornecer ao mercado uma linguagem mais concreta e

madura com os quais os desenvolvedores de ferramentas pudessem criar uma


17

ferramenta mais utilizável. Usando técnicas orientadas a objeto criariam uma

linguagem que iria desde o conceito até o sistema executável, não somente a

sistemas complexos mas também a sistemas menores e também a outros

problemas que não fossem sistemas de informação, podendo ser utilizado por

seres humanos e máquinas[Furlan, 1998].

A criação da UML iniciou oficialmente em outubro de 1994, quando

Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a

unificação dos métodos Booch e OMT[Furlan, 1998]. O esboço da versão 0.8

do Método Unificado foi lançado em outubro de 1995. Mais ou menos na

mesma época Jacobson se associou à Rational com a finalidade de incorporar

o OOSE no escopo inicial da versão 0.8, resultando o lançamento da versão

0.9 da UML em junho de 1996[Booch, 2000]. Foi então aprovada pela

comunidade de engenharia de software em geral. Muitas empresas ficaram

interessadas, foi então criada um consórcio com várias empresas interessadas

em dedicar recursos com o propósito de trabalhar uma definição mais forte e

completa da UML.

Empresas que contribuíram para a definição da UML 1.0, Digital

Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON

Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments

e Unisys. Resultando uma linguagem de modelagem bem definida , expressiva,

poderosa, e que poderia ser aplicada a uma grande variedade de tipos de

problemas[Booch, 2000]. A UML foi oferecida para a OMG (Object

Management Group) em janeiro de 1997, em resposta à solicitação do próprio

OMG de propostas para uma linguagem padrão de modelagem[Furlan, 1998].


18

Entre janeiro a julho de 1997, o grupo original se expandiu,

passando a incluir virtualmente todos os participantes e colaboradores da

resposta inicial ao OMG, entre os quais se encontravam Andersen Consulting,

Ericson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies,

Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris

Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational, com o

propósito de formalizar a especificação da UML e de integrar a linguagem a

outros esforços de padronização. A versão 1.1 foi entregue a OMG em julho de

1997. Em setembro do mesmo ano, essa versão foi aceita pela ADTF (Analysis

and Design Task Force) e pelo Architecture Board do OMG e, posteriormente

submetida a votação de todos os membros da OMG. A versão 1.1 foi adotada

pela OMG em 14 de novembro de 1997[Booch, 2000].

A manutenção da UML foi então assumida pela RTF (Revision Task

Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lançou uma

revisão editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF

lançou a UML 1.3[Furlan, 1998].

3.3 Aceitação

Os criadores da UML procuraram desenvolver uma linguagem

unificada padrão que pudesse ser de fácil entendimento a todos. Preocuparam-

se em deixá-la aberta aos desenvolvedores, onde os mesmos pudessem criar

seu próprio método de trabalho.

Empresas desenvolvedoras de ferramentas estão livres para criarem

uma ferramenta aqueda ao uso da UML. Devido a necessidade de criação da


19

UML empresas e profissionais liberais da área estão desenvolvendo estudos

para melhor aplicá-la.

3.4 Padronização OM G

Quando se iniciaram os trabalhos para criação da UML, os criadores

tinham como intenção fazer sua aceitação com a distribuição da linguagem a

vários desenvolvedores.

A OMG (Object Management Group) fez um requerimento por uma

linguagem de modelagem padrão. Então houve interesse dos criadores da

UML em padronizá-la, para isso foi preciso que os mesmos aprimorassem a

qualidade da linguagem para tal. Pois para serem realmente utilizadas por

empresas era necessário sua padronização.

3.5 Aplicação

A UML pode ser usada para modelar várias fases de um sistema,

desde os primeiros contatos até a geração do código. É aplicada em qualquer

tipo de sistemas em termos de diagramas de orientação a objeto.

Geralmente é mais usada na modelagem de Softwares usando o

conceito de orientação a objetos, mas também pode ser aplicada em sistemas

mecânicos, de engenharia em geral, pode também ajudar na organização de

processos de uma organização.


Capítulo 4 - ETAPAS DO DESENVOLVIMENTO DE
SISTEMAS EM UML

4.1 Análise de Requis itos

Esta fase captura as intenções e necessidades dos usuários do

sistema a ser desenvolvido através do uso de funções chamadas "use-cases"

[Barros, 2001]. É a descrição das necessidades ou desejos de um determinado

sistema. O princípio básico da análise de requisitos é identificar e documentar o

que é realmente necessário, desta forma comunicando a todos os envolvidos

no projeto da forma mais clara possível, de maneira não-ambígua de modo que

os riscos sejam identificados sem correr riscos de imprevistos.

Através do desenvolvimento de casos de uso(em UML chamamos

de “use-cases”), as entidades externas ao sistema (em UML chamamos de

"atores externos") que interagem e possuem interesse no sistema são

modelados entre as funções que eles requerem, funções estas chamadas de

"use-cases". Os atores externos e os "use-cases" são modelados com


21

relacionamentos que possuem comunicação associativa entre eles ou são

desmembrados em hierarquia. Descrevemos um “use-case” através de um

texto especificando os requisitos do ator externo que utilizará este “use-case”.

Um “use-case” tanto pode depender de um ou mais “use-case” como pode ter

seus dependentes. Através do diagrama de “use-cases” mostraremos aos

atores externos(futuros usuários) o que estes podem esperar do sistema.

A análise de requisitos também pode ser desenvolvida baseada em

sistemas de negócios, e não apenas para sistemas de software

4.2 Análise

A fase de análise preocupa-se com as primeiras abstrações(classes

e objetos) e mecanismos presentes no contexto do problema[Larman, 2000].

Descrevemos as classes nos Diagramas de Classes e também para ajudar na

descrição dos “use-cases”, podendo estas estar ligados uma nas outras

através de relacionamentos.

Nesta fase modelamos somente as classes que pertencem ao

domínio principal do problema, ou seja, classes técnicas mais detalhadas não

estarão neste diagrama.

4.3 Projeto

Projeto cria uma representação do domínio de problema do mundo

real e leva-a a um domínio de solução que é o software [Pressman, 1995].


22

Nesta fase partimos para as soluções técnicas, através dos

resultados obtidos na fase da análise. Serão adicionadas novas classes para

oferecer uma infra-estrutura técnica tais como: interface do usuário e

periféricos, banco de dados, interação com outros sistemas, e outras mais. É

feita uma junção das classes da fase da análise com as classes técnicas da

nova infra-estrutura, podendo assim alterar tanto o domínio principal do

problema quanto a infra-estrutura.

Com a elaboração do projeto obtemos detalhadamente as

especificações para dar inicio a fase de programação.

4.4 Programação

Para que uma fase de programação possa ter um bom desempenho,

necessitamos de um projeto bem elaborado, consequentemente converteremos

as classes da fase do projeto para o código da linguagem orientada a objetos

escolhida. Se o desenho foi elaborado corretamente e com detalhes

suficientes, a tarefa de codificação é facilitada [Furlan, 1998].A complexidade

dessa conversão vai depender da capacidade da linguagem escolhida, no

entanto esta pode tornar-se fácil ou difícil de se realizar.

Em UML durante a elaboração dos modelos de análise e projeto,

devemos evitar traduzi-los em códigos. Cabendo esta tarefa à fase de

programação.
23

4.5 Testes

Na fase de teste executamos um programa com a intenção de

descobrir um erro[Pressman, 1995]. Testamos cada rotina ou processo

detalhadamente, bem como a integração de todos os processos e a aceitação.

As rotinas devem ser testadas de duas formas, uma pelos programadores,

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

um todo. Os testes de integração são feitos usando as classes e seus

componentes de integração para verificar se estas classes estão realmente

colaborando uma com as outras conforme especificado nos modelos. Nos

testes de aceitação é verificado se o sistema está de acordo com o

especificado no diagramas de “use-cases”.

Por fim, o sistema será testado pelo usuário final e este verificará se

os resultados apresentados estão realmente de acordo com suas intenções

expressas no início do projeto.


Capítulo 5 - FERRAMENTAS CASE

5.1 Conceito

O termo CASE(Computer-Aided Software Engineering) significa

Engenharia de Software Auxiliada por Computador. Antigamente, os analistas

desenvolviam software para outras áreas (como Engenharia, Arquitetura,

Medicina, etc) mas não se utilizavam de software para fazer seu trabalho.

Tinham necessidade de visualizar o projeto como um todo, ao invés de analisá-

lo em partes. É difícil de acreditar que ferramentas de software tão simples

estejam ficando cada vez mais importantes nos dias de hoje [Cood, 1991].

Com a crescente demanda pela qualidade e integração de

softwares, e também pela unificação de planejamentos administrativos com a

análise, projeto e geração de sistemas, surgiu então as denominadas

Ferramentas Case.
25

Uma Ferramenta Case é um software que auxilia no ciclo de

desenvolvimento de um sistema desde a fase de análise até a fase de testes,

auxiliando também na manutenção do sistema.

Apoiam na utilização de metodologias e métodos, armazenam

informações em sua base de dados, tanto em forma de textos como em forma

gráfica, possibilitando a comunicação com o usuário, a aprovação das

definições de processos, fluxos de informações e atributos de entidades, não

esquecendo de nenhum passo da metodologia usada, proporcionando alto

nível de documentação.

As ferramentas CASE se dividem em 3 tipos:

• Integrated System CASE (I-CASE) , que visam desde a análise/projeto até a

geração do código. Tentam abranger tudo, porém "superlota" uma etapa

com vários tipos de sub-ferramentas com a intenção de abranger várias

metodologias.

• Case's de automação de uma fase(ou mais) de desenvolvimento, são

ferramentas que se prendem a uma etapa do desenvolvimento tal como

ferramentas de modelagem de dados(modelo de dados) e ferramentas de

testes (testes do sistema).

• Ferramentas que seguem uma metodologia especifica, tal como antigo

Composer By IEF que seguia a engenharia da informação. O próprio

Rational Rose, segue como linha base a Orientação a Objetos.


26

5.2 Vantagens

Citamos algumas vantagens com a utilização de Ferramentas CASE

• Maior qualidade dos produtos finais: as ferramentas CASE diminuem a

probabilidade de erros, uma vez que podem ajudar no controle de

consistência dos dados em um ambiente de desenvolvimento, também

proporcionam maior eficácia dos produtos, ao auxiliarem as fases de

Análise e Teste do produto pelo usuário;

• Produtividade: ao ajudar na realização de tarefas e até mesmo ao realizar

algumas automaticamente, as ferramentas contribuem para uma maior

agilidade no desenvolvimento de software, isto é, mais produtos em menos

tempo;

• Eliminação de trabalho que muitas vezes não agregam valor ao produto

final: as ferramentas CASE podem realizar algumas tarefas cansativas para

os desenvolvedores, tais como procurar informações e desenhar símbolos

de um diagrama, as quais são mais sucetíveis ao erro;

• Mais tempo para a tomada de decisão: em conseqüência de as ferramentas

realizarem certas atividades pelas pessoas, estas ficam liberadas para

outras tarefas, geralmente mais nobres, que exigem tomada de decisão e

criatividade, ao invés de tarefas repetitivas;

• Flexibilidade para mudanças: as ferramentas permitem que sejam mudados

dados e diagramas de maneira mais rápida e fácil, o que ajuda o

desenvolvedor no trabalho de tentar satisfazer o usuário;

• Menos programação: as ferramentas eliminam muito tempo do trabalho de

programação, deixando mais tempo para que a equipe técnica se preocupe


27

com a Análise do Sistema, que é onde se define como solucionar o

problema do usuário;

• Melhor documentação: por armazenarem dados e diagramas, as

ferramentas também contribuem para uma melhor documentação do

sistema, agilizando relatórios, busca de informações e alterações;

• Manutenção mais fácil e ágil: por conseqüência do item anterior, é possível

ter mais informações sobre o software na hora de realizar sua manutenção

(correção, atualização ou expansão).

As Ferramentas Case nos auxiliam em todas as fases do projeto,

portanto seu uso é de extrema importância, considerando suas vantagens não

vemos outra saída para um projeto bem desenvolvido e documentado.

5.3 Aceitação no Mer cado

A aceitação de ferramentas CASE ocorreu com diagramas como o

DFD e o E-R, que só foram amplamente utilizados quando surgiram as

primeiras ferramentas para auxiliar na tarefa de diagramação.

Hoje em dia, há também a difusão do termo I-CASE, que é usado

para caracterizar um grupo de ferramentas CASE integradas, isto é, que se

relacionam entre si (entradas e saídas) e que permitem controlar a consistência

dos dados quando seguimos uma metodologia.


28

5.4 O Futuro

Podemos dizer que as ferramentas CASE, evoluirão não de uma

forma fechada, mas de uma forma aberta de maneira que as mesmas cada vez

mais se integrarão com outras ferramentas de fabricantes distintos.

A palavra de ordem dos CASE's de amanhã é diversidade e

especialização. O conceito de CASE's apenas se transformou. O conceito de

CASE de amanhã nasceu hoje. Ou melhor, sofreu uma mutação mercadológica

dado o poder dos fabricantes. Entender o conceito é importante, mas entender

a evolução do mesmo é também importante.

5.5 Rational Rose

Rational Rose é uma ferramenta CASE para desenvolvimento de

sistemas orientados a objetos, sendo também, um repositório para os produtos

gerados por processos de análise e projetos orientados a objetos. Ela acelera

esse desenvolvimento de análise e projetos utilizando metodologias de

desenvolvimento muito difundidas no meio da informática, principalmente o

padrão Unified Modeling Language (UML). O padrão UML é o mais utilizado

hoje em dia, pois com ele há uma documentação interativa e automática dos

processos de modelagem, sendo também possível a geração, pela ferramenta,

de códigos a partir da mesma modelagem. As versões mais novas ferramenta

contemplam até a interação com ambientes de desenvolvimento das mais

variadas linguagens existentes no mercado [DBSERVER, 2001].


29

Por quatro anos consecutivos o IDC nomeou a Rational Rose como

a ferramenta principal de projeto e de construção baseada em análise

orientada a objetos [DBSERVER, 2001].

Segundo RATIONAL, a ferramenta Rational Rose é uma solução

completa para [2001]:

• Empresas e Analistas de Sistemas : Permite analistas visualizar e modelar

processos de empresas e requisitos de sistemas.

• Projetos : Permite projetar modelos de sistemas baseados em UML

mantendo o sincronismo entre o código e o projeto.

• Modelagem de Banco de Dados e Análise : Oferece em uma única

ferramenta linguagem e notação para toda a equipe.

• Desenvolvedores Web : Fornece suporte a XML, Java, EJB. Permite

visualizar a arquitetura da Web de forma compreensiva, até mesmo sites

mais complexos.

• Desenvolvedores UNIX : Suporta a interoperabilidade completa entre UNIX

e Windows, oferece aos usuários UNIX a mesma interface do usuário

Windows e suporta os mesmos formatos de arquivo, permitindo

compartilhar modelos e projetos de desenvolvimento.

• Para todos : O modelo integrado permite melhor o desempenho da equipe

de desenvolvimento. Conhecendo mais profundamente seus algoritmos, irá

gerar um bom resultado ao final do projeto.


Capítulo 6 - VISÕES DE SISTEMAS

6.1 Conceito

O desenvolvimento de um sistema complexo não é uma tarefa fácil.

O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e

que este representasse por completo as reais intenções do sistema sem

ambigüidades, sendo facilmente interpretável [Barros, 2001].

Um sistema é composto por diversos aspectos: funcional (que é sua

estrutura estática e suas interações dinâmicas), não funcional (requisitos de

tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais

(organização do trabalho, mapeamento dos módulos de código, etc.).

Descrevemos um sistema em várias visões, cada visão mostra alguma

particularidade do sistema e estão em alguns de diagramas.

Algumas visões estão interligadas através de diagramas, podendo

uma visão fazer parte de uma ou mais visões. Os diagramas que compõem as
31

visões contém os modelos de elementos do sistema. A Figura 6.1 apresenta as

cinco visões de sistemas.

Figura 6.1 : Visões de Sistemas

6.2 Visão USE-CASE

Descreve a funcionalidade do sistema desempenhada pelos atores

externos do sistema (usuários). A visão use-case é central, já que seu

conteúdo é base do desenvolvimento das outras visões do sistema. Essa visão

é montada sobre os diagramas de use-case e eventualmente diagramas de

atividade.

6.3 Visão Lógica

Descreve como a funcionalidade do sistema será implementada. É

feita principalmente pelos analistas e desenvolvedores. Em contraste com a

visão use-case, a visão lógica observa e estuda o sistema internamente. Ela


32

descreve e especifica a estrutura estática do sistema (classes, objetos, e

relacionamentos) e as colaborações dinâmicas quando os objetos enviarem

mensagens uns para os outros para realizarem as funções do sistema.

Propriedades como persistência e concorrência são definidas nesta fase, bem

como as interfaces e as estruturas de classes. A estrutura estática é descrita

pelos diagramas de classes e objetos. O modelamento dinâmico é descrito

pelos diagramas de estado, seqüência, colaboração e atividade.

6.4 Visão de Compon entes

É uma descrição da implementação dos módulos e suas

dependências. É principalmente executado por desenvolvedores, e consiste

nos componentes dos diagramas.

6.5 Visão de concorrê ncia

Trata a divisão do sistema em processos e processadores. Este

aspecto, que é uma propriedade não funcional do sistema, permite uma melhor

utilização do ambiente onde o sistema se encontrará, se o mesmo possui

execuções paralelas, e se existe dentro do sistema um gerenciamento de

eventos assíncronos. Uma vez dividido o sistema em linhas de execução de

processos concorrentes (threads), esta visão de concorrência deverá mostrar

como se dá a comunicação e a concorrência destas threads. A visão de

concorrência é suportada pelos diagramas dinâmicos, que são os diagramas


33

de estado, seqüência, colaboração e atividade, e pelos diagramas de

implementação, que são os diagramas de componente e execução.

6.6 Visão de Organiza ção

Finalmente, a visão de organização mostra a organização física do

sistema, os computadores, os periféricos e como eles se conectam entre si.

Esta visão será executada pelos desenvolvedores, integradores e testadores, e

será representada pelo diagrama de execução.


Capítulo 7 - MODELOS DE ELEMENTOS

7.1 Definição

Os conceitos usados nos diagramas são chamados de modelos de

elementos [Barros, 2001]. Um modelo de elemento é definido com a semântica,

a definição formal do elemento com o exato significado do que ele representa

sem definições duvidosas ou ambíguas e também define sua representação

gráfica que é mostrada nos diagramas da UML.

Um elemento pode existir em diversos tipos de diagramas, mas

existem regras que definem quais elementos podem ser mostrados em que

tipos de diagramas. Alguns exemplos de modelos de elementos são as

classes, objetos, estados, pacotes e componentes. Os relacionamentos

também são modelos de elementos, e são usados para conectar outros

modelos de elementos entre si.


35

7.2 Classes

As classes são os blocos de construção mais importantes de

qualquer sistema orientado a objetos [Booch, 2000].

Uma classe é uma descrição de um conjunto de objetos que

compartilham os mesmo atributos, operações, relacionamentos e semântica.

Podem ser implementadas em uma ou mais interfaces.

Todos os objetos são instâncias de classes, onde a classe descreve

as propriedades e comportamentos daquele objeto.

Em UML as classes são representadas por um retângulo dividido em

três compartimentos: o compartimento de nome, que conterá apenas o nome

da classe modelada, o de atributos, que possuirá a relação de atributos que a

classe possui em sua estrutura interna, e o compartimento de operações, que

serão os métodos de manipulação de dados e de comunicação de uma classe

com outras do sistema(ver Figura 7.1). A sintaxe usada em cada um destes

compartimentos é independente de qualquer linguagem de programação,

embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
36

Figura 7.1 : Classes

7.2.1 Nomes

Todas as classes devem ter um nome que as diferencie das demais.

Usamos uma seqüência de caracteres para identificá-las. Uma classe pode ter

um nome simples, ou com caminho como mostra a Figura 7.2. O caminho

identifica o pacote ao qual a classe pertence.


37

Figura 7.2 : Nomes

7.2.2 Atributos

Um atributo é uma propriedade de uma classe, que descreve um

intervalo de valores que as instâncias da propriedade podem apresentar. Uma

classe pode ter qualquer número de atributos ou nenhum. Um atributo

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

Figura 7.3 : Atributos

7.2.3 Operações

Operações são os processos que a classe pode realizar.

Operações correspondem claramente a métodos em uma classe. No

nível de especificação, as operações correspondem a métodos públicos.

Normalmente, você não mostra as operações que simplesmente manipulam

atributos, porque elas podem ser freqüentemente inferidas. Entretanto, você

poderá ter que identificar seu um dado atributo é somente para leitura(isto é, o

seu valor nunca muda). No modelo de implementação, você também pode

querer mostrar operações privativas(private) e protegidas(protected).

Uma classe pode ter várias operações ou até mesmo nenhuma, são

representadas logo após os atributos (veja Figura 7.4).


39

Figura 7.4 : Operações

7.3 Objetos

Os objetos são elementos que podemos manipular, acompanhar seu

comportamento, criar, interagir com ele, ou até destrui-lo. Um objeto pode

existir no mundo real ou pode ser uma derivação de estudos da estrutura e

comportamento de outros objetos do mundo real. Corresponde a qualquer

coisa que tenha algum significado para uma dada aplicação [Mazzola,

1999].Por exemplo, uma máquina, uma organização, ou negócio.

Em UML um objeto é mostrado como uma classe só que seu nome é

sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do

nome da classe, conforme mostra a Figura 7.5.


40

Figura 7.5 : Objetos

7.4 Estados

Um estado é uma condição ou situação na vida de um objeto

durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou

aguarda um evento [Booch, 2000]. Todos os objetos possuem um estado que

significa o resultado de atividades executadas pelo objeto, normalmente este

estado é determinado pelos valores dos atributos e ligações com outros

objetos.

Um objeto muda de estado quando acontece algo, o fato do objeto

alterar o seu estado chamamos de evento. Analisando as mudanças de estado

que um objeto pode sofrer, podemos prever todos os possíveis comportamento

de um objeto de acordo com os eventos que o mesmo possa sofrer.

Um estado pode ter três compartimentos (veja Figura 7.6): Nome do

Evento, Atributos e Atividades.


41

• Nome do Evento - mostra o nome do evento, geralmente este nome

descreve o que este estado realiza;

• Atributos – mostra as variáveis de estado, onde os atributos do objeto em

questão pode ser listados e atualizados;

• Atividades – o compartimento de atividades é onde podemos listar os

eventos e ações. Está dividido em três eventos padrões : Entrar, Sair e

Fazer.

Entrar : usado para definir atividades no momento em que o objeto

entra naquele estado;

Sair : usado para definir atividades que o objeto executa antes de

passar para o próximo estado;

Fazer : usado para definir atividades que o objeto executa enquanto

se encontra naquele estado.

Figura 7.6 : Estados


42

7.5 Pacotes

Pacote é um mecanismo de propósito geral para organizar

elementos de modelo em grupos, podendo, inclusive, estar aninhando dentro

de outros pacotes(pacotes subordinados) [Furlan, 1998] (ver Figura 7.7).

Todos os modelos de elementos que são ligados ou referenciados

por um pacote são chamados de "Conteúdo do pacote". Um pacote possui

vários modelos de elementos, e isto significa que estes não podem ser

incluídos em outros pacotes.

Figura 7.7 : Pacotes

Pacotes podem importar modelos de elementos de outros pacotes.

Quando um modelo de elemento é importado, refere-se apenas ao pacote que

possui o elemento. Na grande maioria dos casos, os pacotes possuem

relacionamentos com outros pacotes. Embora estes não possuam semânticas

definidas para suas instâncias. Os relacionamentos permitidos entre pacotes

são de dependência, refinamento e generalização (herança).


43

O pacote tem uma grande similaridade com a agregação. O fato de

um pacote ser composto de modelos de elementos cria uma agregação de

composição. Se este for destruído, todo o seu conteúdo também será.

7.6 Componentes

Um componente pode ser tanto um código em linguagem de

programação como um código executável já compilado. Por exemplo, em um

sistema desenvolvido em Java, cada arquivo .java ou .class é um componente

do sistema, e será mostrado no diagrama de componentes que os utiliza. Veja

na Figura 7.8 a representação de componentes.

Figura 7.8 : Componentes

7.7 Relacionamentos

Os relacionamentos ligam classes/objetos entre si criando relações

lógicas entre estas entidades [Barros, 2001]. Possuímos três tipos de

relacionamentos: associação, generalização e Dependência/Refinamentos.


44

• Associação: É uma conexão entre classes, e também significa que é uma

conexão entre objetos daquelas classes. Em UML, uma associação é

definida com um relacionamento que descreve uma série de ligações, onde

a ligação é definida como a semântica entre as duplas de objetos ligados.

• Generalização: É um relacionamento de um elemento mais geral e outro

mais específico. O elemento mais específico pode conter apenas

informações adicionais. Uma instância (um objeto é uma instância de uma

classe) do elemento mais específico pode ser usada onde o elemento mais

geral seja permitido.

• Dependência e Refinamentos: Dependência é um relacionamento entre

elementos, um independente e outro dependente. Uma modificação é um

elemento independente afetará diretamente elementos dependentes do

anterior. Refinamento é um relacionamento entre duas descrições de uma

mesma entidade, mas em níveis diferentes de abstração.

7.7.1 Associações

Associação é uma relação que descreve um conjunto de vínculos

entre elementos de modelo [Furlan, 1998].Representa a ligação entre classes

ou objetos de classes, podendo ambas conhecer-se. Uma associação é

definida em UML como relacionamento.

7.7.1.1 Associações Norm ais

O tipo mais comum de associação é apenas uma conexão entre

classes. É representada por uma linha sólida entre duas classes. A associação
45

possui um nome (junto à linha que representa a associação), normalmente um

verbo, mas substantivos também são permitidos.

Pode-se também colocar uma seta no final da associação indicando

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

da associação (ver Figura 7.9).

Para expressar a multiplicidade entre os relacionamentos, um

intervalo indica quantos objetos estão relacionados na ligação. O intervalo pode

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

nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou

apenas 1).

Figura 7.9 : Associações Normais

7.7.1.2 Associações Recu rsivas

Podemos conectar uma classe a ela mesma, usando uma

associação recursiva, e ainda podemos representar a conexão entre dois

objetos, sendo os mesmos da mesma classe, conforme mostra a Figura 7.10.


46

Figura 7.10 : Associações Recursiva

7.7.1.3 Associações Quali ficadas

Associações qualificadas são usadas com associações de um para

vários (1..*) ou vários para vários (*). O "qualificador" (identificador da

associação qualificada) especifica como um determinado objeto no final da

associação "n" é identificado, e pode ser visto como um tipo de chave para

separar todos os objetos na associação. O identificador é desenhado como

uma pequena caixa no final da associação junto à classe de onde a navegação

deve ser feita (ver Figura 7.11).

Figura 7.11 : Associações Qualificadas

7.7.1.4 Associações Exclu sivas

Podemos encontrar em alguns modelos combinações não válidas.

Uma associação exclusiva é uma restrição em duas ou mais associações. Ela

especifica que objetos de uma classe podem participar de no máximo uma das

associações em um dado momento. Uma associação exclusiva é representada


47

por uma linha tracejada entre as associações que são parte da associação

exclusiva, com a especificação "{ou}" sobre a linha tracejada.

Figura 7.12 : Associações Exclusivas

Conforme figura 7.12 um contrato não pode se referir a uma pessoa

e a uma empresa ao mesmo tempo, significando que o relacionamento é

exclusivo a somente uma das duas classes.

7.7.1.5 Associações Orden adas

As associações entre objetos podem ter uma ordem implícita. O

padrão para uma associação é desordenada ou seja não possui uma ordem

específica. Podemos resolver este problemas usando a associação ordenada,

ajudando pois existem casos que a ordem precisa estar concisa para o

entendimento da associação. Podemos escrever está associação apenas como

{ordenada} junto a linha da associação.

7.7.1.6 Associações de Cl asse

Uma classe pode ser associada a uma outra associação. Este tipo

de associação não é conectada a nenhuma das extremidades da associação já

existente, mas na própria linha da associação. Esta associação serve para se

adicionar informações extra a associação já existente (ver Figura 7.13).


48

Figura 7.13 Associações de Classe

A associação da classe Fila com a associação das classes Cliente e

Processo pode ser estendida com operações de adicionar processos na fila,

para ler e remover da fila e de ler o seu tamanho. Se operações ou atributos

são adicionados à associação, ela deve ser mostrada como uma classe.

7.7.1.7 Associações Terná rias

A associação ternária e a associação entre três classes. Ela é

mostrada como um grade losango (diamante) e ainda suporta uma associação

de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do

losango para a classe onde seria feita a associação ternária.

Figura 7.14 : Associações Ternárias

Conforme mostra a Figura 7.14 a associação ternária especifica que

um cliente poderá possuir 1 ou mais contratos e cada contrato será composto

de 1 ou várias regras contratuais.


49

7.7.1.8 Agregação

A agregação é uma caso particular da associação, indica que uma

das classes do relacionamento é uma parte, ou está contida em outra classe.

As palavras chaves usadas para identificar uma agregação são: "consiste em",

"contém", "é parte de" (ver Figura 7.15).

Figura 7.15 : Agregação

Existem tipos especiais de agregação que são as agregações

compartilhadas e as compostas.

• Agregação Compartilhada: É dita compartilhada quando uma das classes é

uma parte, ou está contida na outra, mas esta parte pode estar contida na

outra várias vezes em um mesmo momento (ver Figura 7.16).

Figura 7.16 : Agregação Compartilhada

• Agregação de Composição: É uma agregação onde uma classe que está

contida na outra "vive" e constitui a outra. Se o objeto da classe que contém

for destruído, as classes da agregação de composição serão destruídas

juntamente já que as mesmas fazem parte da outra (ver Figura 7.17).

Figura 7.17 : Agregação de Composição


50

7.7.2 Generalizações

Um relacionamento de taxinomia entre um elemento mais geral e um

elemento mais específico que é completamente consistente com o primeiro

elemento somando-o informação adicional especializado [Furlan, 1998].

Um objeto mais específico pode ser usado como uma instância do

elemento mais geral. A generalização, também chamada de herança, permite a

criação de elementos especializados em outros.

Existem alguns tipos de generalizações que variam em sua

utilização a partir da situação. São elas: generalização normal e restrita. As

generalizações restritas se dividem em generalização de sobreposição,

disjuntiva, completa e incompleta.

7.7.2.1 Generalização Nor mal

Na generalização normal a classe mais específica, chamada de

subclasse, herda tudo da classe mais geral, chamada de superclasse (ver

Figura 7.18). Os atributos, operações e todas as associações são herdadas.

Figura 7.18 : Generalização Normal

Uma classe pode ser tanto uma subclasse quanto uma superclasse,

se ela estiver numa hierarquia de classes que é um gráfico onde as classes

estão ligadas através de generalizações.

A generalização normal é representada por uma linha entre as duas

classes que fazem o relacionamento, sendo que coloca-se uma seta no lado da

linha onde encontra-se a superclasse indicando a generalização.


51

7.7.2.2 Generalização Res trita

Uma restrição aplicada a uma generalização especifica informações

mais precisas sobre como a generalização deve ser usada e estendida no

futuro. As restrições a seguir definem as generalizações restritas com mais de

uma subclasse:

• Generalizações de Sobreposição e Disjuntiva: Generalização de

sobreposição significa que quando subclasses herdam de uma superclasse

por sobreposição, novas subclasses destas podem herdar de mais de uma

subclasse (ver Figura 7.19). A generalização disjuntiva é exatamente o

contrário da sobreposição e a generalização é utilizada como padrão.

Figura 7.19 : Generalização de Sobreposição

• Generalizações Completa e Incompleta: Uma restrição simbolizando que

uma generalização é completa significa que todas as subclasses já foram

especificadas, e não existe mais possibilidade de outra generalização a

partir daquele ponto (ver Figura 7.20). A generalização incompleta é

exatamente o contrário da completa e é assumida como padrão da

linguagem.
52

Figura 7.20 : Generalização Completa

7.7.3 Dependências e Re finamentos

Uma dependência indica a ocorrência de um relacionamento

semântico entre dois ou mais elementos do modelo onde uma classe cliente é

dependente de alguns serviços da classe fornecedora, mas não tem uma

dependência estrutural interna com esse fornecedor [Furlan, 1998].

Uma mudança no elemento independente irá afetar o modelo

dependente. Como no caso anterior com generalizações, os modelos de

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

entre estas duas classes, apesar de não ser explícita.

Uma relação de dependência é simbolizada por uma linha tracejada

com uma seta no final de um dos lados do relacionamento. E sobre essa linha

o tipo de dependência que existe entre as duas classes. Conforme mostra a

figura 7.21, as classes "Amigas" provenientes do C++ são um exemplo de um

relacionamento de dependência.

Figura 7.21 : Relação de Dependência


53

Os refinamentos são um tipo de relacionamento entre duas

descrições de uma mesma coisa, mas em níveis de abstração diferentes e

podem ser usados para modelar diferentes implementações de uma mesma

coisa (uma implementação simples e outra mais complexa, mas também mais

eficiente).

Os refinamentos são simbolizados por uma linha tracejada com um

triângulo no final de um dos lados do relacionamento e são usados em modelos

de coordenação (ver Figura 7.22). Em grandes projetos, todos os modelos que

são feitos devem ser coordenados. Coordenação de modelos pode ser usada

para mostrar modelos em diferentes níveis de abstração que se relacionam e

mostram também como modelos em diferentes fases de desenvolvimento se

relacionam.

Figura 7.22 : Refinamentos

7.8 Mecanismos Gera is

A UML utiliza alguns mecanismos em seus diagramas para tratar

informações adicionais.

• Ornamentos: ornamentos gráficos são anexados aos modelos de

elementos em diagramas e adicionam semânticas ao elemento. Um

exemplo de um ornamento é o da técnica de separar um tipo de uma

instância. Quando um elemento representa um tipo, seu nome é mostrado

em negrito. Quando o mesmo elemento representa a instância de um tipo,


54

seu nome é escrito sublinhado e pode significar tanto o nome da instância

quanto o nome do tipo. Outros ornamentos são os de especificação de

multiplicidade de relacionamentos, onde a multiplicidade é um número ou

um intervalo que indica quantas instâncias de um tipo conectado pode estar

envolvido na relação.

• Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem

importar o quanto extensa ela seja. Para permitir adicionar informações a

um modelo não poderia ser representado de outra forma, UML provê a

capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer

lugar em um diagrama, e pode conter qualquer tipo de informação (ver

Figura 7.23).

Figura 7.23 : Ornamentos e Nota


Capítulo 8 - DIAGRAMAS

8.1 Conceito

Quando você faz modelagem, você simplifica a realidade para um

melhor entendimento do sistema em desenvolvimento. Em UML você

desenvolve seus modelos a partir de blocos distintos tais como : classes,

interfaces, colaborações, componentes, dependências, generalizações,

associações, etc. Os diagramas são meios utilizados para visualização de

blocos de construção [Booch, 2000].

Os diagramas utilizados pela UML são compostos de nove tipos:

diagramas de casos de uso, classes, objetos, estados, sequência, colaboração,

atividade, componentes e execução. A seguir trataremos cada um destes tipos

de diagramas. Os exemplos utilizados para apresentar os diagramas foram

retirados de livros utilizados neste projeto e de material encontrado na internet.


56

8.2 Diagramas de Cas os de Uso

Um diagrama de caso de uso ilustra um conjunto de casos de uso

para um sistema, os atores e a relação entre os atores e os casos de uso

[Larman, 2000].

Os casos de uso são usados para modelar como um sistema ou

empresa funciona, ou como os usuários desejam que ele funcione. Os casos

de uso geralmente são o ponto de partida da análise orientada a objetos

utilizando a UML.

O modelo de caso de uso consiste de atores e casos de uso. Os

atores representam usuários e outros sistemas que interagem com sistema

modelado. Eles são representados graficamente por um homem palito. Os

casos de uso mostram o comportamento do sistema, cenários que o sistema

percorre em resposta ao estímulo de um ator. Eles são desenhados como

elipses conforme mostra a Figura 8.1.

No modelo de caso de uso o relacionamento entre um ator e um

caso de uso representa a participação deste ator no caso de uso. Além deste

relacionamento, existe dois outros tipos de relacionamentos entre casos de

uso:

• o relacionamento estender: é representado graficamente por uma seta com

o estereótipo <<extends>>, mostrando que o caso de uso destino pode

incluir o comportamento especificado pelo caso de uso origem;

• o relacionamento usar: é representado por uma seta com o estereótipo

<<uses>>, mostrando que o caso de uso origem inclui o comportamento

especificado pelo caso de uso destino.


57

A figura 8.1 mostra um diagrama de casos de uso.

Figura 8.1 : Diagramas de Casos de Uso

8.3 Diagramas de Cla sses

É uma estrutura lógica estática em uma superfície de duas

dimensões mostrando uma coleção de elementos declarativos de modelo,

como classes, tipos e seus respectivos conteúdos e relações [Furlan, 1998]

(ver Figura 8.2).


58

Uma classe em UML é representada por uma caixa retangular com

três compartimentos: um com o nome da classe, o outro com a lista de

atributos da classe e o último com a lista de operações da classe.

As associações representam relacionamentos estruturados entre

objetos de diferentes classes, e são representados graficamente através de

uma linha conectando as classes. Uma associação pode ter um nome. E as

extremidades da linha que representa uma associação pode ter nome de

papéis mostrando como a classe é vista pelas outras classes na associação.

A multiplicidade de uma associação especifica quantas instâncias de

uma classe relacionam-se a uma única instância de uma classe associada.

Uma multiplicidade é representada por um intervalo de valores possíveis, no

seguinte formato: limite_inferior..limite_superior, onde esses limites são valores

inteiros ( o caracter * pode ser usado como limite_superior para indicar falta de

limite).

A agregação é uma forma especial de associação que representa o

relacionamento todo-parte entre objetos. Ela é representada incluindo-se um

losango na extremidade do objeto todo do relacionamento todo-parte.

A generalização é uma ferramenta poderosa para a abstração. A

generalização é um relacionamento existente entre uma classe mais

geral(superclasse) e uma classe mais específica(subclasse), onde a classe

mais específica é consistente com a mais geral e adiciona informações a ela.

Uma generalização é representada por uma linha com um triângulo, que liga a

classe mais específica a mais genérica. Veja figura 8.2.


59

Figura 8.2 : Diagramas de Classes

8.4 Diagramas de Ob jetos

Os diagramas de objetos fazem a modelagem de instâncias de itens

contidos em diagramas de classes. Um diagrama de objetos mostra um

conjunto de objetos e seus relacionamentos em determinado ponto no tempo.

Estes diagramas não são importantes apenas para a visualização,

especificação e documentação de modelos estruturais, mas também para a

construção de aspectos estáticos de sistemas por meio de engenharia de

produção e engenharia reversa [Booch, 2000] (ver Figura 8.3).

A UML permite a utilização de diagramas de classes para uma

visualização dos aspectos estáticos dos blocos de construção do sistema. Você

usa os diagramas de interação para visualizar os aspectos dinâmicos de seu


60

sistema, formados por instâncias desses blocos de construção e mensagens

enviadas entre eles. Os diagramas de objetos cobrem um conjunto de

instâncias dos itens encontrados nos diagramas de classes. O diagramas de

objetos, portanto, expressa a parte estática de uma interação, composta pelos

objetos que colaboram entre si, mas sem qualquer uma das mensagens

passadas entre eles. Nos dois casos, o diagrama de objetos congela um

momento no tempo.

Os diagramas de objetos são usados para fazer a modelagem da

visão de projeto estática ou da visão de processo estática de um sistema, da

mesma forma como faz com os diagramas de classes, mas a partir da

perspectiva de instâncias reais ou prototípicas. Isso envolverá a modelagem de

um retrato do sistema em determinado momento e a representação de um

conjunto de objetos, seus estados e relacionamentos. Essa visão atende

principalmente aos requisitos funcionais do sistema – ou seja, os serviços que

o sistema deverá proporcionar aos seus usuários finais. Os diagramas de

objetos permitem que você faça a modelagem de estruturas de dados

estáticos.

Figura 8.3 : Diagramas de Objeto


61

8.5 Diagramas de Est ados

Os diagramas de estados são usados para modelar o

comportamento dinâmico de um sistema. Mostram o ciclo de vida de um objeto

em níveis de detalhe arbitrariamente simples ou complexos [Larman, 2000].

Visualizam a seqüência de estados que um objeto ou uma interação percorre

durante sua vida em resposta a estímulos recebidos, junto com suas próprias

ações e respostas conforme mostra a Figura 8.4.

Por exemplo, o comportamento de um objeto é modelado em função

de qual estado ele está inicialmente, e para qual estado ele vai passar quando

um determinado evento ocorrer.

Os estados representam as condições dos objetos em um

determinado momento.

Os eventos representam incidentes que causam a mudança de um

estado para outro. As linhas de transição descrevem o movimento de um

estado para o outro. Cada linha de transição é rotulada com o evento que

causou a transição.
62

Figura 8.4 : Diagramas de Estados

8.6 Diagramas de Seq üência

Os diagramas de seqüências são usados para modelar a interação

entre objetos em um sistema. Tipicamente, um diagrama de seqüência captura

o comportamento de um único caso de uso. O diagrama apresenta os objetos e

as mensagens que são passadas entre estes objetos dentro do caso de uso,

conforme mostra a Figura 8.5. Os objetos são representados por linhas

tracejadas verticais, e a passagem de mensagens entre dois objetos são

representados por vetores horizontais. As mensagens são desenhadas

cronologicamente do topo à base do diagrama.


63

Figura 8.5 : Diagramas de Seqüência

8.7 Diagramas de Col aboração

Os diagramas de colaboração é uma outra alternativa para a

modelagem de interações entre objetos de um sistema. Diferentemente do

diagrama de seqüência que focaliza na seqüência cronológica do cenário que

está sendo modelado, o diagrama de colaboração focaliza no relacionamento

entre os objetos e na compreensão dos efeitos sobre um objeto durante um

cenário. Os objetos são conectados através de associações e cada associação

representa uma instância de associação entre as respectivas classes

envolvidas. As associações mostram as mensagens enviadas entre os objetos,

e a seqüência destas mensagens é determinada usando-se números

seqüenciais (ver Figura 8.6).

Uma Colaboração é uma visão de um conjunto de elementos de

modelagem relacionados para um propósito particular em apoio a interações

[Furlan, 1998].
64

Figura 8.6 : Diagramas de Colaboração

8.8 Diagramas de Ativ idade

Um diagrama de atividade é essencialmente um gráfico de fluxo,

mostrando o fluxo de controle de uma atividade para outra [Booch, 2000] (ver

Figura 8.7).

Os diagramas de atividades são um caso especial de diagramas de

estado, onde todos os estados têm uma ação interna e nenhuma transição tem

um evento de entrada. O propósito de um diagrama de atividades é focar nos

fluxos dirigidos pelo processamento interno e descrever o comportamento de

processamentos paralelos.

Os diagramas de atividades são usados para detalhar classes,

implementação de operações e casos de uso, enquanto os diagramas de

estado são usados para especificar o comportamento global de um tipo.

Os diagramas de atividades representam o que acontece, mas não

representam quem faz o que. Isso significa que o diagrama não diz qual classe

é responsável por cada atividade. Os divisores contornam esse problema

através da organização das responsabilidades da atividades dentro de uma

classe. Através dos divisores podemos separar as atividades de acordo com as

classes responsáveis por essas atividades. Os divisores são representados por

linhas verticais tracejadas.


65

Figura 8.7 : Diagramas de Atividade

8.9 Diagramas de Com ponentes

Mostram dependências entre componentes de software [Furlan,

1998].

Os diagramas de componentes representam, de forma estática,

aspectos físicos do sistema sendo modelado. São importantes tanto para

visualizar, especificar e documentar sistemas baseados em componentes

quanto para construir sistemas através de engenharia reversa (reverse) e direta

(forward). Eles mostram um conjunto de componentes e seus relacionamentos

conforme mostra a Figura 8.8. São tipicamente usados para:

Modelar a organização do código fonte;

Modelar lançamento de executáveis (versões);

Modelar fisicamente um banco de dados;

Modelar sistemas adaptativos;

Engenharia de produção e engenharia reversa;


66

Figura 8.8 : Diagramas de Componentes

8.10 Diagramas de Imp lantação

Os diagramas de implantação são diagramas que mostram a

configuração de nós de processamento em tempo de execução e os

componentes que neles existem (ver Figura 8.9).

Os diagramas de implantação não são importantes somente para

visualizar, especificar e documentar sistemas embutidos, cliente/servidor e

distribuídos, mas também para o gerenciamento de sistemas por engenharia

de produção e engenharia reversa.

Os diagramas de implantação são empregados para modelagem da

visão estática de implantação de um sistema. Essa visão direciona

primariamente a distribuição, entrega e instalação das partes que formam o

sistema físico. Na maior parte, isso envolve a modelagem da topologia do

hardware em que o sistema é executado. Os diagramas de implantação são

essencialmente diagramas de classes que focalizam os nós do sistema.


67

Figura 8.9 : Diagramas de Implantação


Capítulo 9 - METODOLOGIA DESENVOLVIDA

9.1 Introdução

A UML é uma linguagem para especificação, visualização,

documentação e construção que tornam possível expressar modelos

orientados a objetos. Porém não prescreve como o trabalho deve ser feito.

A utilização da UML em grandes projetos pode ajudá-lo a tornar-se

mais eficiente, mas para tal devemos adotar um método de desenvolvimento.

O método de desenvolvimento adotado deve descrever um número

de atividades a ser seguidas em uma determinada ordem. Para alcançar com

êxito nossos objetivos devemos ter bem definido a expectativa do projeto.

Um método tradicional de desenvolvimento orientado a objetos é

dividido em análise de requisitos, análise, projeto, implementação e teste

[Barros, 2001], que é uma visão técnica do desenvolvimento. O RUP(Rational

Unfied Process) é um outro método, desenvolvido pela Rational Inc. que é


69

dividido em concepção, elaboração, construção e transição, que mostra uma

visão mais gerencial do desenvolvimento [Booch,2000].

Ferramentas modernas devem suportar um método de

desenvolvimento de sistemas além da linguagem de modelagem e

programação. Um exemplo é o Rational Rose da Rational Inc. que suporta bem

tanto a linguagem quanto o método de desenvolvimento.

A partir deste ponto descreveremos nossa metodologia,

apresentando cada fase da metodologia detalhadamente. Tomaremos como

base para desenvolvimento de nossa metodologia a visão técnica da UML que

divide-se em 5(cinco) etapas: Análise de Requisitos, análise, projeto,

programação e testes.

Ao final do desenvolvimento de cada fase serão feitas observações

que servirão de conclusão e de base para futuros melhoramentos.

9.2 Documentação

Estabelecemos alguns procedimentos inicias, a fim de manter a

documentação organizada. Esses procedimentos podem interagir com outras

documentações em outros projetos usando a mesma metodologia em

plataformas diferentes.

9.2.1 Fonte

Na documentação será exigido a confecção de alguns documentos,

cujo os quais deve-se redigi-los corretamente para um bom entendimento. Para


70

uma melhor visualização determina-se antes do início do projeto o tipo e o

tamanho da fonte, para que todos os documentos escritos tenham o mesmo

aspecto.

O tipo da fonte usada na documentação tem que ser bem definida,

partindo do princípio que nem todos terão as mesmas ferramentas e que

existem editores que não possuem determinadas fontes. Devemos nos

preocupar em estabelecer uma fonte que toda a equipe envolvida e até mesmo

pessoas não envolvidas naquele projeto possuam. Numa apresentação do

projeto criado os documentos tem que ser facilmente visualizados.

Quanto ao tamanho, fontes pequenas demais tornam a

documentação um pouco cansativa para ser lida, fontes grandes gerariam

muitas folhas e também traria um aspecto desfigurado. O tamanho da fonte

deverá estar relacionada com o seu tipo, normalmente usamos o tamanho de

10 a 14.

9.2.2 Gravação da Docu mentação

Para que todos os envolvidos no projeto possam ter acesso à

documentação do projeto, e para uma melhor organização e entendimento,

devemos gravar todos os processos envolvidos com o projeto numa mesma

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

mãe com o nome do projeto e abaixo dela conforme a necessidade cria-se

outras pastas filhas. Todas as pastas criadas devem sempre fazer relação com

os arquivos que estarão armazenados na mesma.


71

Na confecção de um novo projeto pode-se copiar estas pastas para

um outro local e renomeá-las. Faz-se necessário uma revisão de todas as

pastas para adequação com o novo projeto.

9.2.3 Extensão de Arqui vos

Na preocupação que nosso projeto possa se comunicar com outros

ou até mesmo a junção dos mesmos, devemos estabelecer extensões de

arquivos que possam ser abertas em qualquer plataforma, sistema operacional,

editor, etc. Muito importante para uma boa definição deste item, é saber quais

serão os possíveis editores usados, sistemas operacionais que os envolvidos

no projeto possuem.

Arquivos do tipo .txt seriam de bastante abrangência, exceto no

caso de criação de arquivos um pouco mais complexos, necessitando

ferramentas com um pouco mais de recursos, pois arquivos com este tipo de

extensão podem ser abertas em muitas plataformas. Se houver realmente a

necessidade de criação de arquivos com recursos um pouco mais complexos

que os .txt (modo caracter), procurar usar extensões de arquivos que abram na

grande maioria dos editores.

9.2.4 Impressão

Para que todos os documentos, diagramas, etc., que vierem a ser

gerados e impresso no projeto possam ser bem visualizados e arquivados,

devemos definir anteriormente um tamanho de papel padrão.

As margens podem ser configuradas de acordo com a necessidade,

pois dentro do projeto haverá diagramas que necessitarão de margens um


72

pouco menores ou maiores devido a sua complexidade. Sendo que para sua

melhor visualização às vezes é necessário o uso do papel até sua extremidade.

9.2.5 Backup

Deve-se criar um sistema de backup, sugerindo um responsável pela

execução do mesmo, para que não haja surpresas no decorrer do projeto,

como perdas de dados. Ocasionando atraso na conclusão do projeto, alterando

as datas as quais a equipe se submeteu a cumprir.

A periodicidade dos backup´s depende do envolvimento da equipe e

das informações armazenadas diariamente, se houver necessidade pode-se

realizar os backup´s diariamente, semanalmente ou mensalmente.

Criaremos um formulário sugestão que envolve todos os

procedimentos da documentação, conforme anexo 01.

9.2.6 Controle de Versõe s

Desejamos com o controle de versões que os desenvolvedores

possam manter o sistema atualizado de acordo com sua documentação. Serve

também para diferenciar um software dele mesmo, porém qualquer tipo de

alteração feita será registrada uma nova versão do software.

Uma versão deverá ser representada de modo a controlar desde

pequenas alterações até novas funcionalidades e/ou grandes alterações que

mudem a funcionalidade do sistema.

Sugerimos a representação da versão em seqüências de três blocos

de caracteres (N.NX-NN) onde :

• N é um caracter numérico no intervalo de 1 a 9;


73

• NX : N é um caracter numérico no intervalo de 1 a 9; X é um caracter

alfanumérico no intervalo de A-Z;

• NN são caracteres numéricos no intervalo de 01 a 99;

Os dois primeiros caracteres (N.N) representam a versão principal.

Somente são alterados quando se tratar de grandes modificações e/ou

inovações, como por exemplo : troca de linguagem, inclusão de novo módulo

no sistema, troca ou inclusão de nova plataforma.

O terceiro caracter (X) é destinado a alterações de médio porte e/ou

inclusão de novas rotinas, como por exemplo : cadastros, relatórios,

lançamentos, consultas.

Nos dois últimos caracteres (NN) registramos pequenas alterações

e correções em rotinas já existentes no sistema, como por exemplo : alterações

de relatórios, consultas, cadastros, etc.

9.3 Eventos Iniciais

Após concluído o item documentação, trataremos alguns eventos

que ocorrem antes da análise de requisitos. Trata-se de eventos iniciais de

extrema importância para um bom desenvolvimento da análise de requisitos,

onde são feitos os primeiros contatos, um estudo dos dados e definição de

possíveis envolvidos no projeto.


74

9.3.1 Contatos

Um determinado usuário faz um contato solicitando o

desenvolvimento de um software. Este contato pode ser de forma mais variável

possível: Fone, Fax, email, pessoal, etc.

A empresa ou pessoa que recebeu o contato, solicita ao usuário, ou

acompanha o mesmo no preenchimento de um formulário padrão. Trata-se de

um formulário que servirá para registrar a solicitação do usuário e também para

a convocação de algumas pessoas para uma possível reunião a qual será

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

participantes por parte do usuário quanto da empresa de desenvolvimento de

software.

Este formulário deverá ser preenchido em meio

magnético(aconselhável) ou papel, este último depois de preenchido será

transformado em meio magnético.

Criaremos um formulário sugestão que contém todos os itens

necessários para registrar um contato, conforme anexo 02.

9.3.2 Estudo dos Dados

Tratando-se de um desenvolvimento de um novo software será

analisado:

• Após uma análise da área de negócio, concluindo-se que a empresa não

pode atender a solicitação, será retornado ao mesmo que trata-se de uma

área de negócio a qual a empresa não oferece soluções. Esta resposta


75

também poderá ser dada no momento do preenchimento do formulário

padrão, dependendo de quem e da capacidade do atendente.

• A área de negócio da solicitação é abrangida pela empresa, então será feita

uma avaliação sobre a descrição e com base nesta avaliação e na área de

negócio, serão convocados para uma reunião os possíveis envolvidos no

projeto, tanto por parte do solicitante, quanto por parte da empresa

desenvolvedora.

9.3.3 Definição dos Part icipantes

A definição dos participantes deve sempre girar em torno da área de

negócio e da descrição, pois é ali que contém alguns conceitos básicos que

podem ajudar os responsáveis a convocar as pessoas certas para definir os

possíveis participantes.

Nesta definição procura-se envolver todos que de alguma forma

poderão contribuir para o projeto de ambas as partes. Logicamente de acordo

com o andamento do projeto serão filtrados, ficando apenas aqueles que

podem contribuir para o bom desenvolvimento do projeto. Após definir todos os

participantes da reunião, será marcada a data da mesma e os envolvidos serão

convocados.

Até este ponto trata-se de um evento que antecede as fases da

metodologia de desenvolvimento de sistemas.


76

9.4 Análise de requis itos

Esta fase é a base do projeto, deverá ser bem elaborada para um

bom desenvolvimento das demais fases. Serão abordados itens necessários

para a concepção do projeto, definição de equipe envolvida e também alguns

itens técnicos como: atores, casos de uso, diagrama de casos de uso e análise

de riscos.

9.4.1 Reunião/Entrevista

Nas reuniões, das quais as pessoas convocadas a participar, não

existe nenhuma hierarquia. Todos os participantes, sejam eles analistas,

gerentes, diretores ou escriturários, devem se posicionar livremente, pois se

foram convidados a participar é porque têm alguma contribuição a dar com o

seu conhecimento específico no assunto objeto da reunião. Em uma situação

normal, a hierarquia funciona como um agente inibidor e a opinião da pessoa

de nível mais alto prevaleceria sobre as demais, sem nenhuma garantia de que

fosse a mais indicada.

Para dar início a comunicação entre os participantes, Gause e

Weinberg sugerem que o analista comece fazendo perguntas de livre contexto,

concentrando-se no cliente, nas metas globais e nos benefícios. Por exemplo,

o analista poderia perguntar :

• Quem está por trás do pedido deste trabalho?

• Quem usará a solução?

• Qual o benefício econômico de uma solução bem-sucedida?

• Há outra fonte para a solução exigida?


77

Em seguida, o analista pode fazer perguntas que o ajudarão na

compreensão do problema e ter uma idéia da solução:

• Como você caracteriza um "bom" resultado(saída) que seria gerado por

uma solução bem-sucedida?

• Qual o(s) problema(s) essa solução resolverá?

• Você poderia mostrar-me(ou descrever-me) o ambiente que a solução será

utilizada?

• Existem questões de desempenho ou restrições especiais que afetarão a

maneira pela qual a solução é abordada?

Por fim, o analista fará perguntas decisivas, que concentram-se na

efetividade da reunião:

• Você é a pessoa certa para responder a essas perguntas? Suas respostas

são "oficiais"?

• Minhas perguntas são pertinentes ao problema que você tem?

• Estou fazendo perguntas demais?

• Há mais alguém que possa fornecer informações adicionais?

• Existe algo mais que eu possa perguntar-lhe?

Uma abordagem à coleta de exigências orientadas a equipes

aplicada durante as primeiras etapas de análise e especificação é a

FAST(Facilitaded Application Specification Techniques). Essa abordagem

estimula a criação de uma equipe conjunta de clientes e desenvolvedores que

trabalhem juntos para identificar o problema, propor elementos de solução,

negociar diferentes abordagens e especificar um conjunto preliminar de

requisitos de solução. Hoje, a FAST é usada predominantemente pela


78

comunidade de sistemas de informação, mas a técnica oferece potencial para

uma melhor comunicação em aplicações de todos os tipos.

Outra abordagem especializada de entrevista que pode ser usada é

o JAD(Joint Application Development). Consiste numa rápida entrevista e um

processo acelerado de coleta de dados em que todos os principais usuários e o

pessoal da análise de sistemas agrupam-se em uma única e intensiva

reunião(que pode prolongar-se de um dia a uma semana) para documentar os

requisitos do usuário. A reunião costuma ser supervisionada por um

especialista treinado que atua como mediador para encorajar melhores

comunicações entre os analistas de sistemas e os usuários.

Esses métodos citados possuem suas diferenças, mas todos tem

alguns princípios básicos :

• Um encontro é levado a efeito num local neutro e participam

desenvolvedores e clientes;

• Usam-se regras para preparação e participação;

• Uma agenda formal para captar os pontos importantes, agindo de forma

livre o suficiente para encorajar o fluxo de idéias e sugestões;

• Um moderador (Cliente, Desenvolvedor ou alguém de fora) para controlar a

reunião;

• Utilização de um mecanismo de definição que pode ser uma planilha, um

cavalete, adesivos de parede ou cartazes;

• Identificação do problema, propor elementos de solução, negociar

diferentes abordagens e especificar um conjunto preliminar de requisitos de

solução num clima que facilite a realização da atividade.


79

9.4.2 Preenchimento da ata da reunião

Nesta primeira reunião aparecerão muitas idéias sobre como se

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.

A ata da reunião deverá ser compostas de alguns elementos

essenciais .

Criaremos um formulário sugestão que contém todos os elementos

essenciais, conforme anexo 03.

9.4.3 Definições de resp onsabilidades

Aqui definiremos a responsabilidade de cada um dos envolvidos no

projeto. Coordenador da equipe: Responsável pelo andamento do Projeto.

9.4.4 Resumo do Projeto

Um texto geral sobre o sistema que será desenvolvido. Neste texto

será descrito as principais características e funcionalidades do sistemas.

Também será descrita a abrangência de todo o Projeto, com quem interage e

por quem é interagido(isto pode ser representado por diagramas de casos de

uso) .

Discriminar alguns requisitos mínimos para um bom funcionamento

do projeto também faz parte deste resumo, tais como equipamentos, fontes de

dados, ambiente de trabalho, etc.

Cria-se um arquivo com o nome do sistema cujo o resumo faz

referência.
80

9.4.5 Atores

Atores são usuários e/ou outros meios externos que desenvolvem

algum papel em relação ao sistema. Os meios externos são hardwares e/ou

softwares que, assim como os usuários, geram informações para o sistema ou

necessitam de informações geradas a partir do sistema. Existem atores que

podem desempenhar mais de um papel no sistema, quando se pensar em

atores é sempre bom pensar neles como papéis em vez de pensar como

pessoas, cargos, máquinas. No sistema podem ter usuários com diferentes

permissões, para isto é necessário criar um ator para cada diferente tipo de

permissões. Os atores são quem desempenham os casos de uso, um mesmo

ator pode estar em um ou mais casos de uso.

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.

Criaremos um formulário sugestão para listar os atores do sistema,

conforme anexo 04.

9.4.6 Casos de Uso

Antes da definição de casos de uso, devemos ter definidos os atores

e ter a idéia da funcionalidade do sistema, a partir disto, começaremos a definir

os casos de uso.

Casos de uso especificam o comportamento do sistema ou parte(s)

dele e descrevem a funcionalidade do sistema desempenhada pelos atores.

Você pode imaginar um caso de uso como um conjunto de cenários, onde cada
81

cenário é uma seqüência de passos a qual descreve uma interação entre um

usuário e o sistema. Os casos de uso são representados em forma de elipse.

Não deve-se detalhar muito um determinado caso de uso, o seu

detalhamento vai depender do risco que o mesmo corre, quanto maior o risco,

mais detalhes terá o caso de uso.

Ao definir os casos de uso a serem desenvolvidos, trate apenas dos

casos de usos mais críticos para o sistema, os casos de uso que são tarefas

rotineiras não precisam ser desenvolvidos. Dessa forma sua documentação

não se tornará monótona. Numericamente falando, em modo geral trate apenas

de 10 à 20(%) dos casos de uso mais críticos de seu sistema, estes números

citados é claro que podem variar dependendo do sistema a ser desenvolvido.

Os nomes dos casos de usos devemos sempre usar verbos, pois

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.

Preencher todos os requisitos de um caso de uso é de extrema importância.

Criaremos um formulário sugestão para listar os casos de uso,

conforme anexo 05. Também criaremos outro formulário sugestão contendo

todos os requisitos de uma caso de uso, conforme anexo 06.

9.4.7 Escopo

Uma visão gráfica do sistema, mostrando a idéia geral do sistema

como ele irá interagir com o mundo externo. Esta visão é transformação de

funcionalidades, interação e abrangência descritos no resumo do projeto para

uma representação gráfica. Deve-se usar os atores e casos de uso.


82

9.4.8 Diagrama de caso de uso

O diagrama de caso de uso é um ponto importante de comunicação

entre a equipe de desenvolvimento e o usuário, portanto deverá ser de fácil

entendimento. Sua definição deve deixar bem transparente a idéia do sistema.

Nos diagramas de casos de uso ilustramos conjuntos dos casos de

uso do sistema, os atores e a relação entre os atores e os casos de uso.

Devemos definir o nome do diagrama de caso de uso sempre

relacionado-o com o seu propósito. Então relacionamos os casos de uso de

uma determinada parte ou de todo o sistema e os relacionamos com seus

respectivos atores. Deve-se documentar cada diagrama desenvolvido

observando alguns itens importantes como: nome do diagrama, descrição,

atores e casos de uso relacionados.

Criaremos um formulário sugestão que contém todos os itens de

diagrama de caso de uso, conforme anexo 07.

9.4.9 Análise de riscos

Em todo projeto surgem várias incertezas, devemos considerar

algumas mais críticas, estas deverão ser tratadas com mais importância, pois

poderão comprometer todo o desenvolvimento do sistema. Dentre elas

podemos citar as mais críticas e que geralmente ocorrem na maioria dos

projetos:

• Está realmente claro a importância deste projeto?

• Baseado nos casos de uso, tem-se condições de implementar as funções

dentro prazo previsto?

• Analisar os problemas técnicos que poderão ocorrer ao longo do projeto.


83

• Caso encontre problemas, estes serão resolvidos de forma que não altere o

cronograma do projeto?

• Os requisitos foram bem definidos de modo que se ocorrerem eventuais

mudanças, estas não gerarão alterações consideráveis no tempo e nem nos

custos de desenvolvimento?

• Empenho dos envolvidos no projeto, todos que se comprometeram

realmente irão participar?

A análise de riscos é uma tarefa de grande importância no

gerenciamento de um projeto de software, embora, em muitos casos, esta

atividade nem seja considerada.

O seu objetivo é determinar um conjunto de passos a serem

seguidos para determinar os riscos envolvidos no projeto: identificação,

avaliação, classificação, definição de estratégias para administrar os riscos,

resolução dos riscos, etc...

9.4.10 Cronograma

Os cronogramas são metas que devem ser atingidas, definindo

prazos nos quais os envolvidos deverão empenhar-se na execução de suas

atividades para o cumprimento dos mesmos.

Deverá ser criada uma representação (gráfico ou tabela) que

exprima o tempo dedicado a cada tarefa, determinando assim o prazo final do

projeto.

Criaremos um formulário sugestão que contém todos os itens para

um correto preenchimento de um cronograma, conforme anexo 08.


84

9.4.11 Aprovação

Cria-se um formulário onde responsáveis deverão aprovar a fase.

Criaremos um formulário modelo conforme anexo 09.

9.5 Análise

Esta fase preocupa-se com as primeiras abstrações e mecanismos

que estarão presentes no domínio do problema. Traremos dos diagramas de

classes em conjunto com diagramas de objetos, os diagramas de interação os

dividiremos em seqüência e colaboração, trataremos também dos diagramas

de estado e atividade.

9.5.1 Diagrama de Class es

Nos diagramas de classes modelamos a visão estática do sistema, o

conjunto de classes, interfaces, colaborações e seus relacionamentos. Nestes

relacionamentos dar-se-á mais atenção aos quatro principais tipos que são:

Generalização/especificação, Agregação, Associação e Dependência.

Em sistema de grande complexidade podemos dividir o diagrama de

classes em diagramas menores, logicamente observando sempre a integração

de todas as partes.

Deve-se considerar alguns procedimentos no desenvolvimento de

diagramas de classes:

• Praticamente, ter em mãos todas as informações sobre um modelo de

objetos é pouco provável. Deve-se ter conhecimento dos comportamentos


85

iniciais destes objetos, defini-los, classificá-los e identificar os

relacionamentos entre eles. Devemos nos direcionar mais as abstrações

comportamentais, reduzindo o número de objetos.

• Não devemos nos preocupar muito em usar toda a teoria envolvida nos

diagramas de classes, mas sim as mais simples: classes, associações,

atributos e generalização usando logicamente outras abstrações quando

forem necessárias.

• Ter conhecimento e compreensão da idéia do projeto é fundamental.

• Cria-se modelos apenas das áreas chaves do sistema.

• Atribuir-lhe um nome que indique sua finalidade.

• Na definição das classes podemos usar para definir os nomes substantivos,

para os métodos usamos verbos e para os atributos usamos propriedades

da classe.

A atenção em todos os detalhes desenvolvidos neste diagrama será

de grande influência na construção de um bom sistema.

9.5.2 Diagrama de Objet os

Os diagramas de objetos são utilizados para visualizar, especificar,

construir e documentar a estrutura de um conjunto de objetos, onde cada um

está num estado específico e em um determinado relacionamento com demais

objetos.

Os diagramas de objetos ajudam principalmente na modelagem de

estruturas complexas. Quando construímos diagramas de classes, de

componentes ou de implementação o que captamos realmente é um conjunto

de abstrações que nos interessa como um conjunto e, deste ponto de vista,


86

mostra-se sua semântica e seus relacionamentos com outras abstrações

existentes neste conjunto. Se imaginarmos um determinado momento num

sistema modelado, encontraremos um conjunto de objetos, cada um em um

estado específico e em um determinado relacionamento com os demais

objetos.

Um diagrama de objetos mostra um único conjunto de objetos

relacionados uns com os outros em um momento específico.

Segundo Booch, citamos algumas considerações para

desenvolvimento de diagramas de objetos [1995]:

• Identifique alguma função ou comportamento de parte do sistema cuja

modelagem você está fazendo e que é resultante da interação de uma

sociedade de classes, interfaces e outros itens.

• Para cada função ou comportamento, identifique as classes, interfaces e

outros elementos e seus relacionamentos entre si que participem nessa

colaboração.

• Considere apenas um único cenário capaz de percorrer tudo isto, congele o

cenário em determinado momento e represente cada objeto participante.

• Exponha o estado e os valores dos atributos de cada um desses objetos,

conforme seja necessário, para compreensão do cenário.

• De forma semelhante, exponha os vínculos existentes entre esses objetos,

representando instâncias de associações entre eles.

9.5.3 Diagramas de Inter ação

O diagrama de interação enfatiza a interação de objetos, uma

especificação comportamental que inclui uma seqüência de trocas de


87

mensagens entre objetos dentro de um contexto a fim de realizar um

determinado propósito.

Devemos utilizar diagramas de interação quando necessitamos ver o

comportamento de vários objetos dentro de um único caso de uso, a partir de

mensagens que são trocadas entre eles. Estes diagramas modelam os

aspectos dinâmicos do sistema.

Os diagramas de interação podem ser apresentados de duas

formas: Diagrama de Seqüência e Diagrama de Colaboração.

9.5.3.1 Diagrama de Seqüê ncia

O diagrama de seqüência expõe o aspecto do modelo que enfatiza o

comportamento dos objetos em um sistema, incluindo suas operações,

interações, colaborações e histórias de estado em seqüência temporal de

mensagem e representação explícita de ativação de operações [Furlan, 1998].

Em um diagrama de seqüência, um objeto é representado por um

retângulo no topo de uma linha vertical tracejada projetada para baixo. Esta

linha representa o ciclo de vida de um objeto durante uma interação. As

mensagens são representadas por linhas horizontais entre as linhas verticais

de dois objetos, e a ordem de como as mensagens acontecem também é

mostrada de cima para baixo.

O diagrama de seqüência mostra uma seqüência explícita de

mensagens e devemos usá-lo para especificações de tempo real e para

cenários complexos.
88

9.5.3.2 Diagrama de Colab oração

Um diagrama de colaboração é um contexto, um gráfico de objetos e

vínculos com fluxos de mensagens anexados [Furlan, 1998].

Num diagrama de colaboração, os objetos são desenhados como

ícones, e as setas indicam as mensagens enviadas entre objetos para realizar

um caso de uso.

O diagrama de colaboração auxilia no entendimento de um

comportamento de um conjunto de objetos que trocam mensagens entre si

para realizar um propósito em uma interação global, através deste diagrama

podemos ver somente os objetos e as mensagens envolvidas. Uma

colaboração é anexada a um tipo, uma operação ou um caso de uso para

descrever seus efeitos externos.

Em diagramas complexos devemos separá-los em diagramas

menores para facilitar seu entendimento. Utilizamos a descrição do caso de

uso como ponto de partida para a confecção do diagrama.

Como podemos observar os diagramas de seqüência e colaboração

expressam informações semelhantes, porém de forma diferente. Quando

tivermos que decidir entre qual diagrama devemos adotar para estudar uma

interação, podemos escolher primeiramente o diagrama de colaboração

quando o objeto e seus vínculos facilitam a compreensão da interação, e

somente escolher o diagrama de seqüência se a seqüência precisar ser

evidenciada.
89

9.5.4 Diagrama de Estad o

O diagrama de estado exibe os eventos e os estados interessantes

de um objeto e o comportamento de um objeto em resposta a um evento. O

diagrama de estado implica na importância da ordem de execução dos

eventos. Este diagrama faz a modelagem dos aspectos dinâmicos de sistemas.

Para melhor definir estes diagramas, deve-se desenvolver de forma

individualizada um diagrama para cada classe existente, desta forma

detalhando todos os estados da classe.

Um estado é representado por um retângulo com cantos

arredondados e pode ter de um à três compartimentos que são: compartimento

do nome do estado, compartimento de variáveis e compartimento de atividade

interna.

Deve-se considerar alguns procedimentos no desenvolvimento de

diagramas de estados:

• Atribuir-lhe um nome capaz de comunicar seu propósito

• Comece modelando os estados estáveis do objeto e, em seguida faça a

modelagem das transições legais de um estado para outro.

• No gráfico deste diagrama, procure organizar seus componentes de forma

que reduza o cruzamento de ligações de componentes.

9.5.5 Diagrama de Ativid ade

Podemos fazer uma analogia com um gráfico de fluxo(fluxograma),

pois os diagramas de atividades controlam o fluxo de controle de uma atividade

para outra. Focalizando as atividades que ocorrem entre objetos, modelando

aspectos dinâmicos do sistema.


90

Nos Diagramas de Atividades modelamos a ordem pela qual as

coisas devem ser feitas, em processos seqüências ou paralelos, o que os

diferencia de um fluxograma que são limitados a processos seqüênciais.

Usamos os Diagrama de Atividades para diferentes propósitos

como:

• Análise de Caso de Uso e compreensão do fluxo de trabalho entre vários

casos de uso;

• Capturar o funcionamento interno de um objeto;

• Entender as ações quando executamos uma operação;

• Mostrar o funcionamento de um processo de negócio em termos de atores,

fluxos de trabalho, organizações e objetos;

• Mostrar como uma instância de caso de uso pode ser realizada em termos

de ação e mudanças de estado de objetos;

• Mostrar como um conjunto de ações relacionadas pode ser executado e

como afetará objetos ao seu redor.

9.6 Projeto

Baseado na análise, trataremos nesta fase de soluções técnicas.

Para essas soluções serão usados os diagramas de implementação, os quais

estão divididos em diagramas de componentes e implantação.


91

9.6.1 Diagrama de imple mentação

Os diagramas de implementação modelam os aspectos físicos.

Apresentam aspectos de implementação, inclusive da estrutura de código fonte

e de implementação de runtime.

Estão divididos em diagramas de Componentes e diagramas de

implantação.

9.6.1.1 Diagrama de comp onente

O diagrama de implantação mostra a configuração dos nós de

processamento em tempo de execução e os componentes que nele existem.

Os diagramas de componentes mostram a organização e as

dependências existentes entre um conjunto de componentes, transformam seu

projeto lógico em bits. Modelam os itens físicos que residem em um nó como

executáveis, bibliotecas, tabelas, arquivos e documentos.

Devemos atribuir-lhe um nome que demonstre seu propósito, seu

conteúdo costuma conter: componentes, interfaces, relacionamentos de

dependência, generalização, associação e realização. Podem conter notas e

restrições.

São usados para a modelagem da visão estática de implementação

de um sistema. A reunião das partes modeladas ajudarão na formação do

sistema executável. Usamos os Diagramas de Componentes nas seguintes

formas:

• Para modelagem de código-fonte:

• Identificar um conjunto de arquivos de código-fonte de interesse e

transformá-lo em componentes;
92

• Em sistemas grandes, devemos usar pacotes para mostrar grupos de

arquivos de código-fonte;

• No diagrama de componentes a exposição da versão do arquivo de

código-fonte ajuda no entendimento das dependências de compilação;

• Para modelagem de versões executáveis:

• Identificar o conjunto de componentes, isso envolverá alguns ou todos

que vivem em um único nó ou a distribuição desse conjunto de

componentes por todos os nós existentes no sistema;

• Considere o estereótipo de cada componente desse conjunto;

• Para cada componente existente no conjunto, faça seus

relacionamentos.

• Para modelagem de bancos de dados físicos:

• Identificar as classes existentes no modelo que representam o esquema

de seu banco de dados lógico;

• Faça o mapeamento de suas classes em tabelas;

• Estereótipe suas tabelas para um diagrama de componentes;

• Transforme seu projeto lógico em físico

• Para modelagem de sistemas adaptáveis:

• Identificar a distribuição física dos componentes que poderão mover de

um nó para outro. Especifique a localização de uma instância do

componente, atribua a ela o valor location.

• Para modelagem das causas de mudanças de um componente use um

diagrama de interação para auxiliá-lo.

Para uma melhor compreensão dos diagramas de componentes

podemos usar notas e cores como indicações visuais com a finalidade de


93

chamar a atenção a pontos importantes do diagrama. E também devemos usar

elementos estereotipados com cuidado, escolhendo um conjunto pequeno de

ícones e utilizando-o de maneira consistente.

9.6.1.2 Diagrama de impla ntação

Diagrama de Implantação é usada para mostrar a organização do

hardware e a ligação do software aos dispositivos físicos. Este diagrama

denota vários dispositivos de hardware e interfaces físicas determinadas por

seus estereótipos, como processador, impressora, memória, disco; suficientes

para que o engenheiro de software especifique a plataforma em que o sistema

é executado.

O diagrama de implantação modela a visão estática da implantação

de um sistema entre seus nós físicos e seus relacionamentos e para

especificar seus detalhes referente a construção. Usamos os Diagramas de

Implantação em uma das três formas :

• Para modelar Sistemas Embutidos :

• Identificar os dispositivos e os nós que são únicos para o sistema;

• Crie indicações visuais para dispositivos de hardware e outros tipos

dispositivos;

• Modele os relacionamentos entre os dispositivos;

• Se necessário crie diagramas de implantação mais detalhado em

dispositivos inteligentes.

• Para modelar sistema Cliente/Servidor :

• Identificar os nós que representem os processadores do cliente e do

servidor do sistema;
94

• Junte os dispositivos importantes para o comportamento do sistema.

• Crie indicações visuais para processadores e dispositivos usando

estereótipos

• Modele a topologia dos nós, especificando seus relacionamentos.

• Para modelar sistema totalmente distribuído :

• Identificar os dispositivos e processadores para sistemas cliente/servidor

mais simples;

• Caso precise analisar o desempenho da rede do sistema ou

modificações na rede, modele esses dispositivos em um nível de detalhe

que previna essas avaliações;

• Analise os agrupamentos lógicos de nós, especificando-os em pacotes;

• Identifique a topologia do seu sistema;

• Se for preciso focalizar a dinâmica do sistema, introduza diagramas de

casos de uso para especificar o comportamento em foco e crie diagrama

de interação para expandir esses casos de uso.

Os diagramas de implantação não são muito utilizados em sistema

que residem em uma máquina e que interagem somente com dispositivos

padrão(teclado, monitor, mouse, modem pessoal) dessa máquina, que já são

gerenciados pelo S.O. host. Em contrapartida se estiver desenvolvendo

software que interaja com dispositivos que o sistema operacional host

tipicamente não gerencia, ou por processadores distribuídos fisicamente no

mesmo host, o diagrama de implantação ajudará a analisar o mapeamento de

software para hardware de seu sistema.

Para uma melhor compreensão dos diagramas de implantação

devemos atribuir-lhe um nome que identifique seu propósito, podemos usar


95

notas e cores como indicações visuais com a finalidade de chamar a atenção a

pontos importantes do diagrama. E também devemos usar elementos

estereotipados com cuidado, escolhendo um conjunto pequeno de ícones e

utilizando-o de maneira consistente.

9.7 Implementação

A fase da implementação é, na prática, a construção física do

sistema proposto [Silva,1998]. É onde todos os modelos desenvolvidos no

projeto são traduzidos para código que a máquina possa reconhecer.

É muito importante que as fases anteriores já estejam concluídas,

pois a codificação é uma conseqüência natural do projeto.

9.7.1 Tradução

O processo de tradução acontece quando a compilador aceita o

código-fonte como entrada e gera um código-objeto como saída.

Para que o código-fonte não seja gerado de maneira diferente do

projeto, deve-se ter todos os detalhes do projeto bem elaborados e estudados.

9.7.2 Escolha da Lingua gem

Linguagem de codificação complexa ou pouco conhecida pode levar

a códigos mal elaborado e de difícil legibilidade. Devemos nos concentrar em

escolher linguagens de codificação que tenha suporte ao projeto.


96

A escolha de uma linguagem de programação para um projeto

específico deve-se considerar as suas facilidades e aonde ela irá ajudar o

melhor desenvolvimento do projeto.

PRESSMAN sugere alguns critérios a serem avaliados durante a

escolha de uma linguagem de programação [1995]:

• A área de aplicação geral;

• A complexidade computacional e algorítmica;

• O ambiente em que o software será executado;

• Considerações de desempenho;

• A complexidade da estrutura de dados;

• O conhecimento da equipe de desenvolvimento do software;

• A disponibilidade de um bom compilador.

Geralmente considera-se a área de aplicação geral como um dos

itens mais estudados na escolha da linguagem.

O lançamento de novas linguagens ou versões é muito constante,

portanto muitas vezes necessitamos escolher linguagens do conhecimento da

equipe, que geralmente não são os últimos lançamentos. Porém novas

linguagens devem ser cuidadosamente estudadas e a mudança da linguagem

atual para nova tem que ocorrer.

Na escolha de uma linguagem orientada a objetos deve-se

considerar suporte para definições de classes, herança, encapsulação e

transmissão de mensagens ou ainda características adicionais como herança

múltipla e polimorfismo.

As novas gerações de ferramentas CASE possuem uma variedade

de linguagens, com isto elas podem gerar códigos-fonte baseadas no modelo


97

desenvolvido. Porém devem ser bastante estudadas pois uma falha no modelo

pode comprometer todo o produto final.

9.7.3 Documentação do Código

Um código-fonte bem estruturado e documentado será de grande

importância para futuras manutenções no sistema.

A estruturação e documentação começa com a escolha de nomes

identificadores(variáveis e rótulos), prosseguindo com a colocação e

composição do comentário e por fim com a organização visual do código.

Na escolha de nomes de identificadores devemos considerar alguns

itens a fim de facilitar a interpretação :

• Expressar diretamente o seu propósito.

• Identificação do tipo e de sua abrangência(global, local) no sistema. Podem

ser feitas algumas definições de nomes antes do início da programação.

• Não usar nomes muito extensos, mas que expresse o seu propósito. Neste

caso deverá prevalecer o bom censo e experiência por parte do

programador.

Na colocação e composição de comentários, tomaremos alguns

cuidados para que estes realmente ajudem outros leitores de código na

compreensão do código e até mesmo para que o desenvolvedor possa

localizar-se com mais facilidade e rapidez em futuras manutenções. Isto é de

extrema importância no desenvolvimento de sistemas e/ou funções complexas.

Segundo PRESSMAN, comentários em forma de prólogo são

bastante usados, eles aparecem no início de cada módulo, e seguem o formato

abaixo [1995]:
98

• Uma declaração de propósitos que indique a função do módulo.

• Uma descrição da interface("seqüência de chamada", descrição de todos os

argumentos e uma lista de todos os módulos subordinados).

• Uma discussão de dados pertinente, tais como variáveis importantes e suas

restrições e limitações de uso.

• Um histórico de desenvolvimento(autor do módulo, auditor e data, datas e

descrição das modificações).

Para uma melhor documentação em módulos e/ou funções muito

complexas devemos utilizar também comentários descritivos embutidos no

decorrer do código-fonte. Este tipo de comentário será de grande utilidade para

documentarmos linhas ou conjunto de linhas específicas em determinado local

dentro de um módulo e/ou função. Este comentário deverá sempre anteceder o

bloco de comandos que se deseja documentar, faça apenas a identificação da

funcionalidade de tal linha ou conjunto de linhas, não é necessário documentar

outros dados como datas, autores, etc.

Ao escrevermos código-fontes e também seus comentários devemos

sempre nos preocupar com sua estética, procuramos sempre elaborar códigos

identados e seus comentários devem sempre ter uma boa visualização.

Algumas dicas de PRESSMAN para simplificar a codificação [1995]:

• Evitar o uso de testes condicionais complicados;

• Evitar os testes em condições negativas;

• Evitar um intenso alinhamento de laços ou condições;

• Usar parênteses para esclarecer expressões lógicas ou aritméticas;

• Usar símbolos de espaçamento e/ou legibilidade para esclarecer o

conteúdo da instrução;
99

• Usar somente características com padrão ANSI;

• Auto questionar-se: Será que entenderia este código se não fosse eu o

autor deste?

9.8 Testes

A atividade de teste visa executar um programa ou parte dele com a

intenção de encontrar erros.

Um teste bem executado é aquele que encontra um maior número

de erros com o menor número de tentativas, em um tempo e esforço mínimo.

Certamente que os projetistas codificam o software para que não haja erros.

Uma estratégia de teste de software deve estar dividida nas

seguintes fases : planejamento de teste, projeto de casos de teste, execução

de teste e a resultante coleta e avaliação de dados [Pressman, 1995].

Para tornar esta estratégia mais flexível e customizada sem perder

sua validade e regidez, objetivando a redução de custos e tempo adotamos a

seguinte estratégia : planejamento, execução e avaliação dos resultados.

9.8.1 Planejamento de T estes

Antes do início dos teste devemos definir a equipe responsável pelos

testes. Devemos formar um grupo de testes independentes (GTI), envolvendo

também os desenvolvedores principalmente na etapa de teste de unidade da

fase de execução que será abordado a seguir.


100

Devemos tomar como base para testes os casos de usos

desenvolvido na fase de análise de requisitos, verificando se seu propósito está

contemplado, observando seu fluxo normal e quando este fluxo não é seguido

se os fluxos alternativos estão atendendo tal situação.

9.8.2 Execução de Teste s

Nesta etapa são realizados os testes na integra, abordaremos os

testes de Unidade, Integração, Validação e Sistema.

Durante a execução dos testes, deve-se fazer um relatório de

acompanhamento para registro de todos as ocorrências encontradas.

9.8.2.1 Teste de Unidade

Nestes testes cada unidade de software(classe, procedimento,

função, arquivo, etc) é testado individualmente garantindo que ele funcione

adequadamente. Aqui a participação dos desenvolvedores também é

recomendada, pois estes tem um melhor conhecimento interno de cada

unidade.

Alguns aspectos a serem testados: são a interface, as estruturas de

dados, as condições limite, os caminhos independentes e os caminhos de

tratamento de erros.

• A interface, em busca de erros de passagem de dados para dentro e para

fora do módulo. Deve ser realizada em primeiro lugar, durante a realização

deste teste os seguintes aspectos devem ser observados :

1. Consistência entre o número e o tipo de parâmetros de entrada com o

número e tipo de argumentos;


101

2. Consistência entre o número e o tipo de argumentos transmitidos aos

módulos chamados com os parâmetros;

3. Consistência de variáveis globais ao longo dos módulos;

4. Existência de referências a parâmetros não associados ao ponto de

entrada atual;

5. Modificação de argumentos de entrada/saída.

• As estruturas de dados locais, para se prover a garantia de que todos os

dados armazenados localmente mantêm sua integridade ao longo da

execução do módulo. Neste teste devemos nos preocupar em :

1. Digitação inconsistente ou imprópria;

2. Iniciação ou valores default errôneos;

3. Tipos de dados errados;

4. Underflow e Overflow.

• As condições limite, que permitem verificar que o módulo executa

respeitando os valores máximos e mínimos estabelecidos para seu

processamento.

• Os caminhos independentes (ou caminhos básicos) da estrutura de controle

são analisados para ter garantia de que todas as instruções do módulo

foram executadas pelo menos uma vez. Os erros mais comuns são :

1. Precedência aritmética incorreta;

2. Operações em modo misto;

3. Inicialização incorreta;

4. Erros de precisão;

5. Representação simbólica de uma expressão incorreta;

6. Laços mal definidos;


102

7. Comparação de diferentes tipos de dados;

8. Operadores lógicos utilizados incorretamente.

• Os caminhos de tratamento de erros (se existirem), serão testados para

observar a robustez do módulo. Devemos observar os seguintes itens :

1. Descrição incompreensível do erro;

2. O erro exibido não é o erro encontrado;

3. Intervenção da condição de erro no sistema antes do seu tratamento;

4. O processamento das condições de exceções é incorreto;

5. A descrição do erro não ajuda na localização da causa do erro.

9.8.2.2 Teste de Integraçã o

O teste de integração é uma técnica sistemática para a construção

da estrutura de programa, realizando-se em paralelo, testes com o objetivo de

descobrir erros associados a interfaces. Seu objetivo é montar, a partir dos

módulos testados ao nível de unidade construir a estrutura de programa que foi

determinado pelo projeto.

Este teste está divido em incremental e não incremental. Incremental

aborda o teste de integração top-down o programa é construído e testado em

pequenos seguimentos, onde os erros são mais fáceis de ser isolados e

corrigidos. O teste não incremental aborda o teste de integração bottom-up o

programa é testado como um todo, um conjunto de erros é encontrado e sua

correção é difícil porque o isolamento das causas é complicado pela vasta

amplitude do programa inteiro [Pressman,1995].

1. Integração top-down : Os módulos são integrados movimentando-se

de cima para baixo através da hierarquia de controle, iniciado-se do


103

módulo principal. Os módulos subordinados ao módulo principal de uma

maneira depth-first(pela profundidade) ou breadth-first(pela largura).

2. Integração bottom-up : Inicia-se a construção e testes com módulos

localizados nos níveis mais baixos da estrutura do programa dirigindo-se

ao módulo principal.

9.8.2.3 Teste de Validação

Ao final do teste de integração, o software é finalmente estruturado

na forma de um pacote ou sistema. O teste de validação é a validação e

verificação de que o software como um todo cumpre os requisitos do sistema.

Na fase de análise de requisitos são definidos critérios que servirão

de validação para aprovação ou não do software. O teste de validação aborda

as seguintes estratégias : revisão de configuração e teste alfa e beta.

1. Revisão de configuração: é onde são verificados os elementos de

configuração do software se estão adequadamente desenvolvidos e

detalhados para futuras manutenções.

2. Teste alfa: é feito por um cliente nas instalações do desenvolvedor.

O software é usado num ambiente controlado com o desenvolvedor

"olhando sobre os ombros" do usuário e registrando erros e

problemas de uso.

3. Teste beta: é feito nas instalações do cliente pelo usuário final do

sistema. O desenvolvedor não está presente. O cliente registra os

problemas(reais ou imagináveis) que são encontrados e relata-os ao

desenvolvedor em intervalos regulares.


104

9.8.2.4 Teste de Sistemas

O software é apenas um elemento de um sistema baseado em

computador mais amplo. Este teste envolve um grande número de diferentes

testes, cujo propósito é pôr completamente à prova o sistema baseado em

computador.

Entre os tipos de testes de sistemas destacamos: De recuperação,

de segurança, de estresse e de desempenho.

• O teste de recuperação é um teste de sistema que força o software a falhar

de diversas maneiras e verifica se a recuperação é executada.

• O teste de segurança verifica se todos os mecanismos de proteção

embutidos no sistema o protegerão.

• O teste de estresse força o sistema a usar recursos em quantidade,

freqüência ou volumes anormais.

• O teste de desempenho é feito para testar o desempenho do software em

tempo real.

9.8.3 Avaliação dos Res ultados

Completadas a fase de execução dos testes, passaremos para a

avaliação dos mesmos. Isto será feito analisando os relatórios elaborados

durante a fase anterior.

Esta fase é de grande valia para vários aspectos do sistema. Nesta

poderemos ter uma idéia por completo de todo o desenvolvimento do projeto.

Podemos apontar falhas em determinadas fases do projeto

baseando-se nesta avaliação, bem como certificar-se da qualidade e/ou bom

desempenho do projeto.
105

Ocorrendo pequenos erros ou observações que não interfiram no

objetivo do projeto, estes deverão ser tratados diretamente com o responsável

pela fase onde ocorreu o problema.

Quando na avaliação ocorrem problemas do tipo que tenha que ser

refeito alguma unidade por completo, isto geralmente estará comprometendo

os objetivos do projeto e, consequentemente deverá ser de conhecimento de

toda a equipe envolvida no projeto.

Após feitas as correções dos problemas encontrados, estando de

acordo com as especificações definidas na análise de requisitos e aceitas pelo

cliente, o software estará pronto para uso.


Capítulo 10 - Validação da Metodologia

10.1 Introdução

Neste capítulo documentaremos o protótipo desenvolvido baseado

na metodologia, mostrando a idéia principal do sistema.

Serão abordados os seguintes itens : Formulário de Documentação,

Contatos Iniciais, Ata da Reunião, Resumo do Projeto, Escopo, Lista de Caso

de Uso, Diagrama de Caso de Uso, Diagrama de Classes e Escolha da

Linguagem.

10.2 Formulário de Do cumentação

Fonte

Tipo : Times New Roman Tamanho : 12

Gravação
107

Pasta Mãe : Contabilidade

Descrição : Esta pasta contém toda a documentação do projeto do

sistema de contabilidade.

Extensão de Arquivos : .rtf

Impressão

Tamanho do papel: A4(210 X 297mm)

Backup

Responsável: Reginaldo Darolt / Alexandre de Almeida

Periodicidade: Semanal.

Versão: 1.0A-01

10.3 Contatos Iniciais

Data: 14/03/2001

Razão Social: Escritório Criciumense de Contabilidade

Solicitante: João da Silva

Departamento: Gerencial

Fone: 048-4371159

Fax : 048-4376020

Ramal: 203

Email: joaocri@terra.com.br

Descrição: Sistema de Contabilidade com capacidade de emitir os

relatórios legais como: diário, razão, balancete após os lançamentos nas

contas contábeis do plano de contas da empresa. Irá receber também


108

lançamentos dos sistemas de livros fiscais, folha de pagamento e controle

patrimonial. Irá gerar informações gerenciais para o administrativo.

Tipo do pedido: (X ) Novo ( ) Alteração

Área de negócio do problema: Contábil

Prioridade: (X) Normal ( ) Alta ( ) Urgente

Data pretendida para solução: 12 meses

10.4 Ata da Reunião

Data : 21/03/2001 Hora Início : 19:00 Hora Final: 22:30

Participantes: Alexandre de Almeida, Reginaldo Darolt e João da

Silva

Objetivos:

1.Definir a abrangência do sistema.

2.Definir as possíveis entradas de dados.

3.Definir os procedimentos padrões do sistema.

4.Definir as saídas/relatórios que o usuário necessita.

5.Definir os possíveis tipos de usuário do sistema.

Observações: Utilizamos o método questionário para alcançar os

objetivos da reunião.

Definições da reunião:

1.O sistema irá abranger somente o módulo de contabilidade

2.As possíveis entradas de dados no sistema serão:

Manual(através de digitação) e também automáticas por outros sistemas.

Quando geradas por outros sistemas, estes deverão estar conectados no


109

mesmo banco de dados e sem o auxílio de nenhuma rotina do módulo de

contabilidade para execução de tal tarefa.

3.Procedimentos:

• Cadastro de Usuários.

• Cadastro de Contas Contábeis e Históricos Padrões.

• Lançamentos.

• Emissão de relatórios.

• Definição de parâmetros do sistema como período de

lançamento e máscara contábil.

4.Relatórios:

• Cadastrais: Contas e Históricos.

• Acompanhamento de lançamentos.

• Legais: Diários, Razão, DRE, Balanço e Livro Caixa.

• Tempo gasto no sistema por usuário.

5.Usuários:

• Contador

• Digitador

• Usuários de outros sistemas que somente farão lançamentos no

sistema quando conectados no mesmo banco de dados.

10.5 Resumo do Proje to

Um sistema de Contabilidade com cadastros de contas, históricos e

lançamentos. Recebe lançamentos do sistema de Livros Fiscais nos


110

lançamentos de notas, apuração e pagamento de impostos. Do Controle

Patrimonial recebe lançamentos na atualização dos bens e no fechamento de

período. Na Folha de Pagamento recebe lançamentos no momento do cálculo

mensal.

Este sistema gera informações sobre tempo gasto do usuário para o

sistema administrativo. Emite relatórios cadastrais, de acompanhamentos e

também os relatórios legais tais como: Diário, Razão, DRE, Balanço e Livro

Caixa.

Para um bom desempenho do sistema será necessário o uso de

máquinas com configuração igual ou superior a PII 233 Mhz com 32 Mb.

Ambiente Windows95 ou Windows98, e para uma boa apresentação dos

relatórios faz-se necessário impressora Jato de Tinta ou Laser. No caso de

mais de uma estação de trabalho, estas deverão estar conectadas através de

uma rede que suporte as estações no ambiente citado.

10.6 Escopo

Na figura 10.1 apresentamos o escopo do sistema:


111

Figura 10.1 Escopo do Sistema

10.7 Lista de Casos de Uso

UC001 - EFETUAR LANÇAMENTO

UC002 - MANTER CONTA CONTÁBIL

UC003 - MANTER PARÂMETROS

UC004 - MANTER PERMISSÕES


112

UC005 - EFETUAR LANÇAMENTOS LIVROS FISCAIS

UC006 - APURAR IMPOSTOS LIVROS FISCAIS

UC007 - PAGAR IMPOSTOS LIVROS FISCAIS

UC008 - FECHAR PERÍODO CONTROLE PATRIMONIAL

UC009 - MANTER BENS CONTROLE PATRIMONIAL

UC010 - NAVEGAR EM REGISTROS

UC011 - CALCULAR FOLHA DE PAGAMENTO

10.8 Diagrama de Caso de Uso

A figura 10.2 mostra o diagrama de casos de uso do Sistema de

Contabilidade.
113

Figura 10.2 Diagrama de Caso de Uso do Sistema de Contabilidade

10.9 Diagrama de Clas ses

Na figura 10.3 mostramos o diagrama de classes do Sistema de

Contabilidade.
114

Figura 10.3 Diagrama de Classes do Sistema de Contabilidade

10.10 Escolha da Lingu agem

Para desenvolvimento do Sistema de Contabilidade, escolhemos a

linguagem PowerBuilder versão 5.0.02 da Powersoft com o banco de dados

Sybase SQL Anywhere versão 5.0.03.


Capítulo 11 - RESULTADOS OBTIDOS

Após a validação da metodologia desenvolvida, obtemos alguns

resultados os quais julgamos ser necessários destacar.

Neste capítulo discriminaremos os pontos fortes e pontos fracos de

cada fase da metodologia desenvolvida.

• Documentação

Pontos Fortes:

• A extensão de arquivos utilizada nos auxiliou na comunicação

entre a equipe envolvida no projeto, devido ao fato de poder ser

manipulado nos diversos ambientes encontrados.

• O backup nos salvou de refazer boa parte do projeto, pois

tivemos problemas com vírus na máquina principal onde estava o

projeto e a mesma teve de ser formatada.

Pontos Fracos:

• Necessidade de um arquivo leia-me.rtf contendo todos os

arquivos utilizados no desenvolvimento do projeto e uma

pequena descrição de cada arquivo.

• Estabelecimento de uma padronização para nome de arquivos.


116

• Eventos Iniciais

Pontos Fortes:

• De um modo geral atendeu as necessidades, pois desde o

primeiro contato do cliente com a empresa, tudo foi registrado,

facilitando as próximas etapas. Com o estudo da área de

negócio ficou definido que a empresa atenderia a solicitação do

cliente.

• Análise de Requisitos

Pontos Fortes:

• Com os tópicos abordados na reunião, obteve-se os objetivos

gerais e específicos pretendidos com o sistema. Ao final ficou

registrado na ata da reunião.

• Os casos de uso foram bem detalhados, de modo que qualquer

membro do projeto entendeu o seu funcionamento. Facilitou no

desenvolvimento durante a fase de implementação.

• O diagrama de caso de uso auxiliou na comunicação entre o

cliente e os desenvolvedores.

Pontos Fracos:

• Na lista de Atores deveria ter também a data da criação do ator e

o autor que o criou, desta forma facilitaria no esclarecimento de

possíveis dúvidas sobre o ator.

• Análise

Pontos Fortes:

• Seguindo as definições da metodologia, o diagrama de classes

foi facilmente desenvolvido e compreendido por toda a equipe.


117

• Os diagramas de interação mostraram o fluxo de funcionamento

do sistema, como as informações trafegam no mesmo.

Auxiliando desta forma na compreensão comportamental do

sistema.

• O diagrama de estado mostrou de forma clara os eventos da

principal rotina do sistema que é a rotina de lançamentos.

• O diagrama de atividade mostrou de forma clara a ordem de

funcionamento do caso de uso manter contas.

Pontos Fracos:

• O diagrama de objetos deveria ser detalhado na metodologia

para facilitar seu desenvolvimento.

• Projeto

Pontos Fortes:

• O diagrama de componentes nos auxiliaram na estruturação do

código fonte, separando seus objetos de acordo com sua

finalidade.

• O diagrama de implantação mostrou a toda a equipe a estrutura

física do cliente, bem como informações essenciais para o

software como por exemplo o servidor de banco de dados.

• Implementação

Pontos Fortes:

• Conforme sugerido na metodologia, escolhemos uma linguagem

conhecida pelos desenvolvedores e que atendesse os requisitos

do projeto.
118

• A documentação do código foi de grande importância durante o

desenvolvimento do sistema, pois todos os programadores

poderiam facilmente compreender as rotinas independentes do

autor da mesma. Esta documentação ainda será muito utilizada

em futuras manutenções do sistema.

• Testes

Na estratégia de testes não adotamos a fase de projetos porque

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.

Nas fases de teste demos ênfase ao teste de unidade, cujo no nosso

ponto de vista é o mais importante, os demais são apenas citados para que

sejam explorados caso alguém tenha esta necessidade.


119

Capítulo 12 - CONCLUSÃO

Em virtude das constantes inovações que surgem em ferramentas

de desenvolvimento de sistemas orientadas a objetos, podemos afirmar a

importância do uso de uma metodologia que englobe todas as fases do

processo, desde os eventos iniciais, passando pela análise de requisitos,

análise, projeto, implementação e testes. Durante a realização do trabalho

constatamos o interesse por parte de desenvolvedores de software, de uma

metodologia deste nível.

Com o desenvolvimento de sistemas mais complexos, é necessário

o uso de uma metodologia unificada, tanto para a comunicação entre toda a

equipe envolvida (cliente, analista, programador, etc), quanto para a

documentação(requisitos e código-fonte).

Neste contexto, foi proposta uma metodologia de desenvolvimento

de sistemas orientados a objetos baseada em UML(Unified Modeling

Language), a partir da qual o desenvolvedor poderá seguir suas etapas para o

fluxo correto do desenvolvimento de um projeto.

Após o estudo da ferramenta CASE Rational Rose da Rational

Software Corporation, utilizamos a mesma no apoio a validação da


120

metodologia. Esta ferramenta mostrou-se bastante complexa e eficaz, pois ela

possui uma documentação interativa e automática dos processos de

modelagem, permitindo até mesmo gerar código-fonte a partir do modelo. Na

implementação do sistema utilizamos a ferramenta de desenvolvimento

chamada Power Builder pela facilidade da programação orientada a objetos,

bem como pelo conhecimento que todos envolvidos tinham da mesma.

Com o desenvolvimento do protótipo utilizando a metodologia,

podemos afirmar que os resultados esperados foram alcançados, tendo em

vista que esta atendeu todas as fases de desenvolvimento do protótipo. Desta

forma podemos dizer que a metodologia se torna necessária para um bom

desenvolvimento de sistema orientados a objetos.

12.1 Recomendações

Este trabalho está aberto a futuros melhoramentos, e como

recomendações futuras podemos ressaltar:

• Aplicação da metodologia em um sistema complexo.

• Estudo de novas ferramentas CASE.

• Desenvolver novas pesquisas visando corrigir os pontos-fracos

encontrados.

• Desenvolvimento de uma ferramenta CASE baseado-se na metodologia

desenvolvida.

• Utilização da metodologia no apoio às aulas de engenharia de software.


Capítulo 13 - BIBLIOGRAFIA

1. BOOCH Grady et al. UML : Guia do Usuário, O mais avançado tutorial

sobre Unified Modeling Language. Rio de Janeioro. Campus, 2000.

2. SCHNEIDER, Geri et al. Applying Use Cases : A Pratical Guide.

Massachusetts. Addison-Wesley, 1998.

3. Technologies, ADD. Histórico da UML. http://www.addtech.com.br.

Consultada em 24/03/2001.

4. CABRAL, Adelino Manuel de Oliveira et al. UML : Unified Modeling

Language. http://www.tutprog.cjb.net. Consultada em 24/03/2001.

5. SILVA, Leonardo de Araújo et al. UML : Diagrama de Atividade.

http://www.dcc.ufmg.br/~marcosfg/. Consultada em 24/03/2001.

6. UML - Diagramas de Implementação : importantes quando trata de

questões como reutilização e desempenho.

http://www.dcc.ufmg.br/~gorgulho/tbd/seminario.html. Consultada em

24/03/2001.

7. UML – Introdução : ao modelar alguma coisa, estamos criando uma

simplificação da realidade para um melhor entendimento do sistema.

http://www.dcc.ufmg.br/~lucanaan/tbd/texto.htm. Consultada 24/03/2001.


122

8. ARAÚJO, Bethânia Lagoeiro. Uma Contribuição para o Problema de

Compatibilização de Modelos na UML.

http://www.dcc.ufmg.br/pos/html/spg98/node3.html . Consultada em

24/03/2001.

9. CNPQ, UFSC. UML : Unified Modeling Language. Abrange sua história,

definições, arquivos e sites relacionados. http://www.eps.ufsc.br/~wolff .

Consultada em 24/03/2001.

10. BARROS, Pablo. UML : Linguagem de Modelagem Unificada em

Português. http://cc.usu.edu/~slqz9/uml . Consultada em 24/03/2001 .

11. TECHMARK, Engenharia de Software. Tutoriais.

http://www.techmark.com.br/download.html . Consultada em 24/03/2001.

12. LARMAN, Craig. UTILIZANDO UML E PADRÕES : Uma introdução à

análise e ao projeto orientados a objetos. Porto Alegre - Bookman,

2000.

13. FOWLER, Martin, Kendal Scott. UML ESSENCIAL : Um breve guia para a

linguagem padrão de modelagem de objetos. Porto Alegre - Bookman,

2000.

14. PRESSMAN, Roger S. . ENGENHARIA DE SOFTWARE. São Paulo -

Makron Books ,1995.

15. RUMBAUGH, James, Michael Blaha, William Premerlani, Frederick Eddy,

Willian Lorensen. MODELAGEM E PROJETOS BASEADOS EM

OBJETOS. Rio de Janeiro - Campus, 1994.

16. FURLAN, José Davi. MODELAGEM DE OBJETOS ATRAVÉS DA UML :

The Unified Modeling Languagem. São Paulo - Makron Books, 1998.


123

17. MAZZOLA, Vitório Bruno. CONCEITOS BÁSICOS DA ORIENTAÇÃO A

OBJETOS : Capítulo 1, 1999.

18. COOD, Peter, Edward Yourdon. ANÁLISE BASEADA EM OBJETOS. Rio

de Janeiro - Campus, 1991.

19. YOURDON, Edward, Carl Argila. ANÁLISE E PROJETO ORINTADOS A

OBJETOS : Estudos de Casos. São Paulo - Makron Books, 1999.

20. SILVA, Nelson Peres da. PROJETO E DESENVOLVIMENTO DE

SISTEMAS. São Paulo - Érica, 1998.

21. MIZRAHI, Victorine Viviane. TREINAMENTO EM C++. São Paulo - Makron

Books.

22. RATIONAL, Software Corporation. Rational Rose. www.rational.com.

Consultada em 05/04/2001.

23. DBSERVER, Ferramentas Case. Parceria Rational. www.dbserver.com.br.

Consultada em 30/10/2001.
124

1. Anexo 01 - Formulário de documentação.

Fonte

Tipo : <nome da fonte> Tamanho : <tamanho da fonte>

Gravação

Pasta Mãe : <Nome do Sistema>

Descrição : <Abaixo desta pasta mãe estão todos os arquivos

necessários referentes a documentação do software>.

Extensão de Arquivos : <tipo da extensão>

Impressão

Tamanho do papel: <medidas do formulário>

Backup

Responsável: <Nome do responsável pelo Backup>

Periodicidade:

Versão: <N.NX-NN>
125

2. Anexo 02 - Formulário de contato.

Data: <dd/mm/aaaa> Data do contato do cliente

Razão Social: <Nome da Empresa solicitante do software>

Solicitante: <Nome para contato na empresa>

Departamento: <Departamento do solicitante>

Fone:

Fax :

Ramal:

Email:

Descrição: <Neste item deve-se tentar passar o máximo de

informações possíveis sobre a solicitação>

Tipo do pedido: ( ) Novo ( ) Alteração <Informar neste item se

trata-se de software e/ou rotina novos ou alteração>

Área de negócio do problema: < De acordo com o pedido deve-se

definir a área de negócio, para que os envolvidos possam verificar se podem

atender ou não>

Prioridade: ( ) Normal ( ) Alta ( ) Urgente <Definir aqui a

prioridade do pedido>

Data pretendida para solução: <O preenchimento se faz necessário,

pois será estudada pela equipe onde será discutido a possibilidade ou não de

ser efetuada>
126

3. Anexo 03 - Formulário da ata de reunião

Data : <dd/mm/aaaa> Hora Início : <hh:mm>Hora Final: <hh:mm>

Participantes: <Nome1>, <Nome2>,....

Objetivos: <Deve definir o que se pretende alcançar com o sistema,

os setores atendidos>

Observações: <Definição dos itens que ajudarão no

desenvolvimento do sistema>

Definições da reunião: <A definição engloba tudo o que foi definido

na reunião>
127

4. Anexo 04 - Formulário lista de atores

Nome Descrição

<Nome do ator> <Descrever em poucas palavras

o que o ator faz e com o que ele interage>


128

5. Anexo 05 - Formulário lista de casos de uso.

arquivo caso de uso

<nome do arquivo > <Nome do caso de uso que está no arquivo>


129

6. Anexo 06 - Formulário de requisitos de caso de uso.

NOME : <Nome do caso de uso>

DESCRIÇÃO: <Descrever a funcionalidade do caso de uso>

ATORES: <Listar os atores que interagem no caso de uso>

DATA ALTERAÇÃO AUTOR

<data> <Descrição da alteração> <Listar os autores>

SITUAÇÃO INICIAL DO PROCESSO : <O que precisa para existir o

caso de uso>

FLUXO NORMAL: <Seqüência de passos que ocorre naturalmente

com maior freqüência. Esta seqüência deverá ser ordenada e cada passo

corresponde a uma ação do usuário e uma resposta do sistema ou vice-versa>

FLUXOS ALTERNATIVOS: <Usa-se quando o fluxo normal não for

seguido. Neste caso, também serão feitas seqüências de passos alternativos

ordenados e identados conforme o fluxo normal que o gerou>

REQUISITOS MÍNIMOS: <Os dados que tem que existir ou eventos

que tem que ocorrer para que o caso de uso seja válido>

PONTOS DE EXTENSÃO: <São casos de uso que usam outro caso

de uso>

VARIAÇÕES DE DADOS E TECNOLÓGICAS: <Mudanças que

podem ocorrem que irão afetar no funcionamento do sistema>


130

7. Anexo 07 - Formulário Diagrama de caso uso

NOME : <Nome do diagrama>

DESCRIÇÃO: <Descrever em poucas palavras o propósito do

diagrama>

ATORES RELACIONADOS: <Listar todos os atores relacionados no

diagrama>

CASOS DE USO RELACIONADOS: <Listar todos os casos de uso

relacionados no diagrama>

DATA <data da criação/alteração>

ALTERAÇÃO <descrição da alteração>

AUTOR <nome do responsável da criação/alteração>


131

8. Anexo 08 - Formulário de Cronograma

Fase: <Fase do projeto>

Responsáveis:

Nome do Responsável Assinatura

<Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável>

Data Prevista: <Data prevista para conclusão da fase>


132

9. Anexo 09 - Formulário de Aprovação

Fase: <Fase do projeto>

Declaramos que a presente fase está de acordo com o propósito do sistema.

Aprovado por

Nome Assinatura

<Nome(s) do(s) responsável(is) pela fase> <Assinatura de cada responsável>

Data da Aprovação: <Data que fase foi aprovada>