Cap06 EtapasDesenvolvimentoPrograma SUPER REDUZIDO Apresentacao

Programação Orientada a Objeto com C++ Moderno
Professor André Duarte Bueno

https://sites.google.com/view/professorandreduartebueno/
email: bueno@lenep.uenf.br
UENF-CCT-LENEP-LDSC
12 de junho de 2021
2
3
Copyright(C) André Duarte Bueno.
Todos os direitos reservados e protegidos pela Lei 5.988 de 14/12/1973. É proibida a reprodução desta obra, mesmo
parcial, por qualquer processo, sem prévia autorização, por escrito, do autor.
• Editor:
– ANDRÉ DUARTE BUENO [Dr, Professor UENF/CCT/LENEP]
• Revisão técnica:
– TIAGO RIBEIRO SCHAEWER [M.Sc, UENF/CCT/LENEP]

– CARLOS BAZILIO [Dr, Professor UFF/PURO]
– PEDRO LINHARES [M.Sc, UENF/CCT/LENEP]
– LEANDRO PUERARI[Dr, UENF/CCT/LENEP]
1
2
• Esta apostila foi desenvolvida na UENF/CCT/LENEP/LDSC
• Laboratório de Desenvolvimento de Software Científico - LDSC
– http://www.lenep.uenf.br/~ldsc
• do Laboratório de Engenharia e Exploração de Petróleo - LENEP
– http://www.lenep.uenf.br
• do Centro de Ciências e Tecnologia - CCT
– http://www.cct.uenf.br
• da Universidade Estadual do Norte Fluminense - Darcy Ribeiro - UENF
– http://www.uenf.br
• Site do Professor André Duarte Bueno
– https://sites.google.com/view/professorandreduartebueno/
Programação Orientada a Objeto com C++ Moderno [3 edição rascunho] André Duarte Bueno
3
Sumário
1 Etapas para o Desenvolvimento de um Software Orientado a Objeto, Modelagem UML (Diagramas)
e Umbrello 15
1.1 Concepção – especificações, requisitos e cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1.1 Exemplo especificação (simplificada) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.2 UML - Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2 Elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.1 Exemplo elaboração - cálculo da área (integral) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.2.2 UML - Diagrama de pacotes/componentes – assuntos, módulos . . . . . . . . . . . . . . . . . . . . 37
1.2.3 Montagem de protótipo da interface do software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.3 AOO – Análise Orientada a Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4
SUMÁRIO 5
1.4 AOO – Análise Orientada a Objeto – Modelo estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.4.1 UML - Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.4.2 UML - Diagrama de classes com associações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.4.3 UML - Diagrama de classes com agregações e composições . . . . . . . . . . . . . . . . . . . . . . 54
1.4.4 UML - Diagrama de classes com heranças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.5 AOO – Análise Orientada a Objeto – Modelo dinâmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.5.1 UML - Diagrama de seqüência – eventos e mensagens . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.5.2 UML - Diagrama de comunicação – colaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
1.5.3 UML - Diagrama de máquina de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
1.5.4 UML - Diagrama de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
1.6 Projeto do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
1.6.1 Definição da interface de programação – API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1.6.2 Seleção da implementação de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
1.6.3 Seleção das plataformas a serem suportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
1.6.4 Seleção das bibliotecas externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
1.6.5 Seleção da biblioteca gráfica a ser utilizada – GDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
1.6.6 Seleção do ambiente de desenvolvimento integrado – IDE . . . . . . . . . . . . . . . . . . . . . . . 106
1.6.7 Seleção da licença do software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
SUMÁRIO 6
1.7 Projeto Orientado a Objeto – POO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

1.7.1 Revisão dos modelos considerando o projeto do sistema . . . . . . . . . . . . . . . . . . . . . . . . 113
1.7.2 UML - Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
1.7.3 UML - Diagrama de implantação - distribuição – execução . . . . . . . . . . . . . . . . . . . . . . 118
1.7.4 Construção da lista das características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
1.8 Ciclo planejamento e detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
1.9 Ciclo construção - implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
1.9.1 Antes de iniciar a implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.9.2 Roteiro para montar o código inicial do programa com o Umbrello . . . . . . . . . . . . . . . . . . 134
1.9.3 Dicas para implementação da interface gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
1.10 Teste de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
1.10.1 Porque testar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
1.10.2 Uma sequência para teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
1.11 Documentação do software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.11.1 Porque documentar o software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.11.2 Uma sequência para documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
1.11.3 Arquivos mínimos de documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
1.11.4 Documentação embutida no código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
SUMÁRIO 7
1.11.5 Documentação - manuais do usuário e técnico científico . . . . . . . . . . . . . . . . . . . . . . . . 160

1.12 Manutenção e reuso de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.13 Gestão - o trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
1.14 Leitura complementar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
1.15 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
1.16 Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
1.16.1 Exercícios - concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
1.16.2 Exercícios - elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
1.16.3 Exercícios - análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
1.16.4 Exercícios - projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
1.16.5 Exercícios - projeto orientado a objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
1.16.6 Exercícios - implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
1.16.7 Exercícios - testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
1.16.8 Exercícios - documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Referências Bibliográficas 182
Lista de Figuras
1.1 Engenharia - Modelos, Processos, Projetos, Desenvolvimento/Implantação - Exemplo . . . . . . . . . . . . 16
1.2 Etapas de desenvolvimento de um software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Relacionamento dos diagramas estruturais da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Relacionamento dos diagramas dinâmicos da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Etapas de desenvolvimento de um software: Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6 Diagrama de caso de uso geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.7 Diagrama de caso de uso específico – calcular área função . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.8 Diagrama de caso de uso: analisar resultados (uso de generalização) . . . . . . . . . . . . . . . . . . . . . 27
1.9 Etapas de desenvolvimento de um software: Elaboração - Análise de domínio, identificação de assuntos,
prototipagem e iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8
LISTA DE FIGURAS 9
1.10 Etapas de desenvolvimento de um software: Elaboração - Análise de domínio, identificação de assuntos,

prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.11 Esboço de uma função em vermelho e em azul ilustração do Método do Trapézio . . . . . . . . . . . . . . 34
1.12 Diagrama de Assuntos/Pacotes: a lista de assuntos relacionados ao sistema . . . . . . . . . . . . . . . . . 38
1.13 Diagrama de Assuntos/Pacotes: Veja a relação direta dos assuntos com os pacotes desenvolvidos pela em-
presa Emerson. Site [https://www.emerson.com/pt-br/automation/operations-business-management/reservoir-
management-software] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.14 Interface gráfica e eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.15 Etapas de desenvolvimento de um software: Elaboração - iteração . . . . . . . . . . . . . . . . . . . . . . 43
1.16 Etapas de desenvolvimento de um software: análise orientada a objeto . . . . . . . . . . . . . . . . . . . . 44
1.17 Relacionamento dos diagramas estruturais da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.18 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural . . . . . . . . 49
1.19 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural . . . . . . . 50
1.20 Diagrama de classes – representando classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.21 Diagrama de classes – representando associações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1.22 Diagrama de classes – representando agregações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
1.23 Diagrama de classes – representando heranças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.24 Classe de interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
LISTA DE FIGURAS 10
1.25 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural - iteração . . 61
1.26 Relacionamento dos diagramas dinâmicos da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.27 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico . . . . . . . . 65
1.28 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico . . . . . . . . 66
1.29 Diagrama de seqüência – elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.30 Diagrama de seqüência – montando uma prova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1.31 Diagrama de seqüência – seqüência para cálculo da área de uma função . . . . . . . . . . . . . . . . . . . 70
1.32 Diagrama de comunicação – montando uma prova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1.33 Diagrama de comunicação – seqüência para cálculo da área de uma função . . . . . . . . . . . . . . . . . 74
1.34 Diagrama de máquina de estado – um aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
1.35 Diagrama de máquina de estado – estados de uma thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
1.36 Diagrama de máquinas de estado: estados de um processo . . . . . . . . . . . . . . . . . . . . . . . . . . 80
1.37 Diagrama de máquina de estado – estados do objeto simulador . . . . . . . . . . . . . . . . . . . . . . . . 81
1.38 Em (a) o protótipo de um diagrama de atividades. Em (b) o diagrama de atividades de um método de
binarização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
1.39 Diagrama de atividades – método do Trapézio para cálculo da área . . . . . . . . . . . . . . . . . . . . . 87
1.40 Diagrama de atividades – método do Trapézio para cálculo da área - Usando número intervalos . . . . . . 88
1.41 Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico - Iteração . . 89
LISTA DE FIGURAS 11
1.42 Etapas de desenvolvimento de um software: projeto do sistema . . . . . . . . . . . . . . . . . . . . . . . . 90

1.43 Etapas de desenvolvimento de um software: Projeto do Sistema . . . . . . . . . . . . . . . . . . . . . . . 92
1.44 Etapas de desenvolvimento de um software: Projeto do Sistema - Iteração . . . . . . . . . . . . . . . . . . 108
1.45 Etapas de desenvolvimento de um software: projeto orientado a objeto . . . . . . . . . . . . . . . . . . . . 109
1.46 Etapas de desenvolvimento de um software: Projeto Orientado a Objeto . . . . . . . . . . . . . . . . . . . 112
1.47 Diagrama de componentes - UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
1.48 Etapas de desenvolvimento de um software - exemplo diagrama de componentes . . . . . . . . . . . . . . . 117
1.49 Etapas de desenvolvimento de um software - exemplo diagrama de implantação/distribuição . . . . . . . . 120
1.50 Etapas de desenvolvimento de um software: Projeto Orientado a Objeto - Iteração . . . . . . . . . . . . . 122
1.51 Etapas de desenvolvimento de um software: projeto orientado a objeto: Ciclo Planejamento e detalhamento123
1.52 Etapas de desenvolvimento de um software - ciclo planejamento/detalhamento . . . . . . . . . . . . . . . 126
1.53 Etapas de desenvolvimento de um software - ciclo construção - implementação . . . . . . . . . . . . . . . 128
1.54 Etapas de desenvolvimento de um software - ciclo construção . . . . . . . . . . . . . . . . . . . . . . . . . 130
1.55 Etapas de desenvolvimento de um software - ciclo construção - implementação . . . . . . . . . . . . . . . 131
1.56 Mapeamento: conceito, diagrama uml e implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
1.57 Etapas de desenvolvimento de um software - teste de software . . . . . . . . . . . . . . . . . . . . . . . . 138
1.58 Etapas de desenvolvimento de um software - ciclo construção - implementação - sequência para testes . . . 143
1.59 Etapas de desenvolvimento de um software - documentação . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Lista de Figuras 12
1.60 Etapas de desenvolvimento de um software - ciclo construção - implementação - sequência para documentação152
1.61 Etapas de desenvolvimento de um software - espaço para documentação já esta nos modeladores UML . . 157
1.62 Imagem gerada pelo doxygen/graphviz/dot Ilustração gráfica das dependências do arquivo CRotulador3D . 159
1.63 Usando o trello para gestão do processo de desenvolvimento - 1 . . . . . . . . . . . . . . . . . . . . . . . . 163
1.64 Usando o trello para gestão do processo de desenvolvimento - 2 . . . . . . . . . . . . . . . . . . . . . . . . 164
1.65 Exercício – modelagem sistema aeroporto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Lista de Tabelas
13
Listings
Lista de programas
14
Capítulo 1
Etapas para o Desenvolvimento de um

Software Orientado a Objeto, Modelagem
UML (Diagramas) e Umbrello
A Figura 1.2 ilustra as diversas etapas a serem seguidas, as mesmas são descritas a seguir.
15
Prefácio 16
Figura 1.1: Engenharia - Modelos, Processos, Projetos, Desenvolvimento/Implantação - Exemplo

Prefácio 17
Figura 1.2: Etapas de desenvolvimento de um software

Prefácio 18
Prefácio 19
Figura 1.3: Relacionamento dos diagramas estruturais da UML

Prefácio 20
Figura 1.4: Relacionamento dos diagramas dinâmicos da UML

Prefácio 21
1.1 Concepção – especificações, requisitos e cenários

A primeira etapa do desenvolvimento de um software é a concepção, a definição de requisitos a serem satisfeitos, a
especificação do sistema (descrição do objetivo e o que se espera do sistema a ser desenvolvido, o contexto da aplicação
e seus requisitos) e a construção de cenários.
Na concepção ocorre a primeira reunião da equipe de desenvolvimento com os clientes, quando é feita a especificação
do software. O cliente por meio das especificações e das entrevistas, passa para o analista idéias gerais de uso do sistema.
Estas etapas são ilustradas na Figura 1.5 e serão descritas a seguir.
O resultado da etapa de concepção é um conjunto formal de documentos e requisitos organizados pelo gestor do
sistema com apoio dos usuários/clientes, do mestre e da equipe de desenvolvimento.
Prefácio 22
Figura 1.5: Etapas de desenvolvimento de um software: Concepção

Prefácio 23
1.1.1 Exemplo especificação (simplificada)

• Objetivo:
– Desenvolver um simulador de engenharia para cálculo da área de funções matemáticas do tipo y = f (x).
• Requisitos:
– Interface:
∗ Modo texto.
– Plataformas:
∗ Multiplataforma (GNU/Linux, Windows, Mac OS X).
– Ítens opcionais:
∗ Resultados serão armazenados em disco.
∗ Poderão ser gerados gráficos.
Prefácio 24
1.1.2 UML - Diagrama de casos de uso

O diagrama de casos de uso é uma representação visual dos casos de uso. É o diagrama mais simples da UML, sendo
utilizado para demonstrar os cenários de uso do sistema pelos usuários, os quais ao verem esses diagramas terão uma
visão geral do sistema.
O diagrama de caso de uso pode ser utilizado durante e após a etapa de especificação, adicionando às especificações
textuais alguns cenários de uso do programa a ser desenvolvido.
O diagrama de caso de uso geral da Figura 1.6 mostra o usuário acessando os sistemas de ajuda do software, calculando
a área de uma função e a seguir analisando os resultados.
Prefácio 25
Figura 1.6: Diagrama de caso de uso geral
Prefácio 26
Figura 1.7: Diagrama de caso de uso específico – calcular área função
Prefácio 27
Uma generalização de um caso de uso mostra que este pode ser realizado de uma forma mais específica. Funciona da
mesma forma que herança em classes; o caso de uso geral deve ser abstrato, e os casos de uso herdeiros, específicos.
Figura 1.8: Diagrama de caso de uso: analisar resultados (uso de generalização)
Prefácio 28
1.2 Elaboração
Depois da definição dos objetivos, da especificação do software e da montagem dos primeiros diagramas de caso de
uso, a equipe de desenvolvimento passa por um processo de elaboração que envolve o estudo de conceitos relacionados ao
software a ser desenvolvido, a análise de domínio e a identificação de pacotes.
Na elaboração fazemos uma análise dos requisitos, ajustando os requisitos iniciais de forma a desenvolver um sistema
útil, que atenda às necessidades do usuário e, na medida do possível, permita seu reuso e futura extensão.
Eliminam-se os requisitos "impossíveis", e ajusta-se a ideia do sistema de forma que este seja flexível, considerando-se
aspectos como custos e prazos.
A Figura 1.9 ilustra as atividades relacionadas a etapa de elaboração.
Prefácio 29
Figura 1.9: Etapas de desenvolvimento de um software: Elaboração - Análise de domínio, identificação de assuntos,
prototipagem Orientada
Programação e iteração a Objeto com C++ Moderno [3 edição rascunho] André Duarte Bueno
Prefácio 30
Figura 1.10: Etapas de desenvolvimento de um software: Elaboração - Análise de domínio, identificação de assuntos,
prototipagem
Prefácio 31
1.2.1 Exemplo elaboração - cálculo da área (integral)

A estapa de elaboração consiste em estudar o problema a ser resolvido. Então, vamos apresentar brevemente o conceito
matemático de integral e os métodos de integração numérica do trapézio e Simpson.
• O conceito de integral é visto em disciplinas de cálculo, normalmente "Cálculo I" nos cursos de engenharia. Será
muito brevemente descrito aqui.
Matematicamente podemos ter diferentes funções, as mais utilizadas em engenharia são apresentadas a seguir.
A equação do primeiro (eq: 1.1),
y = a + b ∗ x, (1.1)
do segundo (eq: 1.2)
y = a + b ∗ x + c ∗ x2 , (1.2)
e do terceiro grau (eq: 1.3):
y = a + b ∗ x + c ∗ x2 + d ∗ x3 . (1.3)
De forma genérica podemos escrever:
Prefácio 32
y = f (x), (1.4)
indicando que o valor de y depende do valor de x. Por isso x é chamado independente e y dependente.
Em termos práticos, para a física e a engenharia, é muito interessante saber calcular a área abaixo da curva. Para
resolver este problema, ao longo dos séculos, foram desenvolvidas várias metodologias de cálculo (veja [Bassalo, 1996]).
A mais exata e geral é o cálculo da integral indefinida, cuja expressão formal é dada por:
Z
área = f (x)dx (1.5)
Note que na integral indefinida não existem limites e o resultado é uma equação genérica, ou seja, dado um intervalo
qualquer consigo calcular a área.
Na prática da engenharia o mais usual é a integral definida, em que os limites de integração, isto é, os intervalos, de
interesse são definidos. Então, a equação é reescrita com a definição dos intervalos li - limite inferior e ls - limite superior.
Zls
área = f (x)dx (1.6)
li
No exemplo da Figura 1.11 os limites são li = −2 e ls = 2.
Prefácio 33
O resultado do cálculo desta integral é o valor exato da área abaixo da curva no intervalo especificado. Para entender
em detalhes o formalismo matemático associado sugere-se a consulta a livros de Calculo Diferencial e Integral.
De um modo geral um físico teórico e um pesquisador/cientista esta preocupado com o valor exato das equações. Este
também é um interesse do engenheiro, mas, por questões práticas, o engenheiro aceita resultados com valores aproximados.
Uma maneira de realizar esta aproximação no cálculo da área é utilizar trapézios, conforme ilustrado na Figura 1.11.
Note que é feita uma aproximação da área da curva utilizando-se diversos trapézios. A ideia é calcular a área de cada
trapézio individualmente e depois somar a área de todos eles.
Neste exemplo temos uma amostragem 5 (curva em roxo) e uma amostragem 101 (curva em vermelho). Na curva em
roxo conseguimos identificar que temos 4 trapézios, o primeiro é ilustrado a esquerda na cor verde. Note que para um
valor de x = −2 o valor de y = f (−2) = 32.0, e que para um valor de x = −1 obtemos y = f (−1) = 10.0. A área
deste trapézio é dada por área = 1 ∗ (f (−2) + f (−1))/2 = (32 + 10)/2 = 21. Se calcularmos a área de cada trapézio e
somarmos, teremos uma aproximação da área da curva. Esta é a ideia do método do trapézio.
Prefácio 34
Figura 1.11: Esboço de uma função em vermelho e em azul ilustração do Método do Trapézio
Prefácio 35
Note que a área do primeiro trapézio é definida pela seguinte equação.
f (x1) + f (x2)
AreaT rapézio_1 = ∗ dx (1.7)
2
Observe que calculamos f (x1) e f (x2).
A área do segundo e terceiro trapézio é definida pelas equações.
f (x2) + f (x3) f (x3) + f (x4)

AreaT rapézio_2 = ∗ dx AreaT rapézio_3 = ∗ dx (1.8)
2 2
Note que calculamos f (x2) e f (x3). Ou seja, os extremos como f (x1) e f (xn) são calculados apenas uma vez, e os
valores intermediários, como f (x2) e f (x3)...f (xn−1), são calculados sempre duas vezes.
A área dos demais trapézios pode ser generalizada por:
f (xi) + f (xi+1)
AreaT rapézio_i = ∗ dx (1.9)
2
Prefácio 36
Se somarmos a área de todos estes trapézios teremos a equação abaixo, que é a equação para cálculo da área aproximada
da curva pelo método do trapézio:
Z ls
1
f (x)dx ≈
[f (x1)dx + 2f (x2)dx + 2f (x3)dx + 2f (x4)dx + ... + 2f (xn−1)dx + f (xn)dx] (1.10)
li 2
Podendo ser reescrita de forma a otimizar os cálculos com dx para fora.
Z ls
f (x)dx ≈ dx [f (x1)/2 + f (x2) + f (x3) + f (x4) + ... + f (xn−1) + f (xn)/2] (1.11)
li
A qualidade ou precisão deste cálculo esta diretamente associada ao valor de dx, se for grande estaremos errando
mais, se for pequeno estaremos nos aproximando do valor exato. Se dx for um valor infinitamente pequeno estaremos
convergindo para o valor exato.
Prefácio 37
1.2.2 UML - Diagrama de pacotes/componentes – assuntos, módulos

Os diagramas de pacotes tem como objetivo mostrar a estrutura do sistema em diferentes níveis ou camadas. A ideia é
que possam ser usados para mostrar níveis mais altos e lógicos (como quando nos relacionamos aos assuntos com os quais
estamos lidando), e quando estamos mostrando componentes do sistema e seus relacionamentos, como dependências.
Podemos ter vários diagramas de pacotes, mostrando diferentes camadas e aspectos do sistema.
De forma que um diagrama de pacotes é útil para mostrar as dependências entre as diversas partes do sistema; O
mesmo pode incluir:
• assuntos, sistemas, subsistemas, hierarquias de classes, classes, interfaces, componentes, nós, colaborações e casos
de uso.
Vantagens do uso de diagramas de pacotes:
• Permite ver as diferentes partes do sistema e suas dependêncas, tanto do ponto de vista da lógica como dos compo-
nentes físicos em sí.
• Podem ser usados para correlacionar diagramas de classes de forma simplificada (notadamente os complexos).
• Muito utilizados em projetos de médio e principalmente de grande porte.
Prefácio 38
Nota: quando os diagramas de pacotes se referem a lógica do sistema podem ser chamados diagramas de assuntos,
quando se referem aos aspectos físicos de diagramas de componentes.
Figura 1.12: Diagrama de Assuntos/Pacotes: a lista de assuntos relacionados ao sistema
Prefácio 39
Veja na Figura 1.13, exemplo de site de empresa que desenvolve simuladores de engenharia de petróleo, note que os
pacotes estão diretamente associados aos assuntos que vimos nas disciplinas do curso. Site https://www.emerson.com/pt-
br/automation/operations-business-management/reservoir-management-software. Ou seja, podemos definir a lista de
assuntos/pacotes com base nos conhecimentos existentes ou de softwares existentes.
Prefácio 40
Figura 1.13: Diagrama de Assuntos/Pacotes: Veja a relação direta dos assuntos com os pacotes desenvolvidos pela empresa
Emerson. Site
Programação [https://www.emerson.com/pt-br/automation/operations-business-management/reservoir-management-
Orientada a Objeto com C++ Moderno [3 edição rascunho] André Duarte Bueno
Prefácio 41
1.2.3 Montagem de protótipo da interface do software

O protótipo da interface do software é uma versão simplificada do software que vai ser desenvolvido. No protótipo,
os ícones, botões, menus e diálogos são implementados visualmente em um software do tipo RAD (como o qt-designer ).
Observe que não existe o código; existe apenas a casca externa do software, de modo que, ao pressionar um botão,
nenhuma ação é realizada.
A Figura 1.14 mostra que os eventos gerados pelos atores (eventos do teclado, do mouse e de dispositivos externos
como a entrada auxiliar) são tratados por um controlador. O controlador organiza a fila de eventos e os distribui para
os diferentes objetos do sistema. São mostrados ainda os eventos e mensagens gerados e trocados entre os objetos que
compõem o sistema.
Prefácio 42
Figura 1.14: Interface gráfica e eventos

Prefácio 43
Figura 1.15: Etapas de desenvolvimento de um software: Elaboração - iteração
Prefácio 44
Figura 1.16: Etapas de desenvolvimento de um software: análise orientada a objeto

Prefácio 45
1.3 AOO – Análise Orientada a Objeto

A terceira etapa do desenvolvimento de um programa é a AOO – Análise Orientada a Objeto. A AOO utiliza algumas
regras para identificar os objetos de interesse, as relações entre os pacotes, as classes, os atributos, os métodos, as heranças,
as associações, as agregações, as composições e as dependências.
• O modelo de análise deve ser conciso, simplificado, deve mostrar o que deve ser feito, não se preocupando como isso
será realizado. Ou seja, não se preocupa com aspectos relacionados a implementação dos sistemas.
• Ao final da análise teremos um conjunto de diagramas:
– Estruturais: diagrama de classe, diagrama de estrutura composta(também chamado de diagrama de relaciona-

mento da entidade), diagrama de objetos.
– Dinâmicos: diagrama de sequência, de comunicação, de máquina de estado e de atividade.
• Na próxima etapa, projeto do sistema, iremos considerar: protocolos, recursos, mecanismos de controle, platafor-
mas(sistemas operacionais, linguagens), padrões de projeto e ferramentas.
Prefácio 46
1.4 AOO – Análise Orientada a Objeto – Modelo estrutural

O foco do modelo estrutural é a análise da estrutura do sistema, dos objetos e de seus relacionamentos.
Prefácio 47
Figura 1.17: Relacionamento dos diagramas estruturais da UML

Prefácio 48
A Figura 1.18 ilustra as atividades relacionadas a AOO modelo estrutural.

Este modelo é desenvolvido em camadas; Em uma primeira camada são montados os diagramas de pacotes, mostrando
o relacionamento dos dos módulos e subsistemas. Em seguida, cada pacote é detalhado, incluindo-se os diagramas de
componentes; em uma terceira camada são montados os diagramas de classes e os diagramas de objetos. Opcionalmente,
em uma quarta camada, montamos os diagramas de estrutura composta (em alguns softwares chamado de diagrama de
relacionamento da entidade). Observe que a cada nova camada o nível de detalhamento do sistema é maior.
Prefácio 49
Figura 1.18: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural
Prefácio 50
Figura 1.19: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural
Prefácio 51
1.4.1 UML - Diagrama de classes

Observe na Figura 1.20 a representação UML de uma classe.
Figura 1.20: Diagrama de classes – representando classes
Prefácio 52
1.4.2 UML - Diagrama de classes com associações

Veja na Figura 1.21 como representar uma associação. Observe que a associação recebe um nome, podendo-se ainda
definir o papel de cada classe que participa da associação e sua multiplicidade. Se uma associação for representada com
uma seta, ela só será executada na direção da seta (unidirecional).
Papel
Quando uma associação não é clara, pode-se colocar no diagrama de classes o nome da associação e/ou o nome
do papel exercido por cada classe. Um papel é utilizado para indicar a forma como a classe vai atuar em uma
associação. Deve ter um nome unívoco, normalmente um substantivo, que identifique com clareza o papel que a
classe exerce na associação. Em alguns casos um papel é uma restrição ao objeto. Por exemplo: uma empresa tem
três secretárias, uma cuida da agenda do chefe, as outras duas trabalham na recepção. Observe que as três são
secretárias, mas o papel de cada uma é diferente.
Restrições
Em um modelo de objetos as restrições estabelecem relações funcionais entre objetos, classes, atributos e associações.
Como exemplo de restrições, podemos citar a restrição de que o raio de um círculo não ultrapasse determinado valor,
a restrição de só poder desenhar dentro da área cliente de uma janela. Um modelo de objetos bem desenvolvido
deve ter muitas restrições. Veja na Figura 1.21 que as restrições aparecem dentro de colchetes {}. A Figura 1.34
mostra que o aluno só será aprovado se obtiver nota maior ou igual a seis.
Prefácio 53
Figura 1.21: Diagrama de classes – representando associações
Prefácio 54
1.4.3 UML - Diagrama de classes com agregações e composições

Veja na Figura 1.22 como representar agregações e composições. Observe que uma agregação é representada com um
losango na classe todo e uma composição é representada como um losango cheio. Observe que podemos incluir o papel e
a multiplicidade de cada classe. Também podemos incluir um estereótipo.
Prefácio 55
Figura 1.22: Diagrama de classes – representando agregações

Prefácio 56
1.4.4 UML - Diagrama de classes com heranças

Veja na Figura 1.23 como a UML representa as heranças. Observe que a classe-base é mais genérica, e as classes-
derivadas são especializações da classe-base. A classe-derivada é "um tipo de" classe-base.
Generalização
A generalização (bottom-up) é realizada identificando-se atributos e operações semelhantes. No exemplo da Figura
1.23, um relógio é uma generalização de relógio cronômetro e relógio alarme.
Especialização
Especialização é a criação de classes-derivadas (filhas) a partir de uma classe-base (pai). As classes-derivadas têm
acesso a todos os métodos e atributos da classe-base. A especialização (top-down) pode ser verificada por meio de
frases substantivas compostas por diversos adjetivos relativos ao nome da classe (exemplo: lâmpada incandescente,
lâmpada fluorescente). Uma especialização pode ter um nome como "é um tipo de" ou "é um". No exemplo da
Figura 1.23, um relógio cronômetro é um tipo de relógio que foi especializado.
Discriminador
Em um diagrama de classes, um discriminador costuma indicar qual propriedade de um objeto está sendo general-
izada.
Prefácio 57
Figura 1.23: Diagrama de classes – representando heranças

Prefácio 58
Na Figura 1.24 ilustra-se a classe de interface.
Figura 1.24: Classe de interface
Prefácio 59
Prefácio 60
Prefácio 61
Figura 1.25: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Estrutural - iteração
Prefácio 62
1.5 AOO – Análise Orientada a Objeto – Modelo dinâmico

O modelo dinâmico é utilizado na descrição das transformações dos objetos em relação ao tempo, preocupando-se com
o controle da execução, sua seqüência. Representa a evolução da execução do programa, as respostas do programa aos
eventos gerados pelo usuário. Preocupa-se com aspectos como os eventos, as mensagens e suas seqüências, as comunicações
e colaborações entre objetos e subsistemas, as mudanças de estados e a realização de atividades.
Todo programa que envolva interação e tempo, ou ainda interface gráfica com o usuário e controle de processos, deve
ter um bom modelo dinâmico, o qual pode ser construído com diagramas de seqüência (seção 1.5.1), de comunicação
(seção 1.5.2), diagramas de máquina de estado (seção 1.5.3) e diagramas de atividade (seção 1.5.4).
Prefácio 63
Figura 1.26: Relacionamento dos diagramas dinâmicos da UML

Prefácio 64
A Figura 1.27 ilustra as atividades relacionadas a AOO - modelo dinâmico.

Veja a seguir como identificar os eventos e mensagens e como implementar o modelo dinâmico e seus diagramas.
Prefácio 65
Figura 1.27: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico
Prefácio 66
Figura 1.28: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico
Prefácio 67
1.5.1 UML - Diagrama de seqüência – eventos e mensagens

O diagrama de seqüência enfatiza a troca de eventos e mensagens e sua ordem temporal. Veja o protótipo de um
diagrama de seqüência na Figura 1.29.
Figura 1.29: Diagrama de seqüência – elementos
Prefácio 68
Veja na Figura 1.30 um exemplo de diagrama de seqüência.
Figura 1.30: Diagrama de seqüência – montando uma prova
Prefácio 69
Na Figura 1.31 mostramos a seqüência para cálculo da área de uma função.
Prefácio 70
Figura 1.31: Diagrama de seqüência – seqüência para cálculo da área de uma função
Prefácio 71
Prefácio 72
1.5.2 UML - Diagrama de comunicação – colaboração

No diagrama de comunicação o foco é a interação e a troca de mensagens e dados entre os objetos. Veja na Figura
1.32 uma representação do diagrama de comunicação equivalente ao diagrama de seqüência da Figura 1.30. Observe que
a seqüência de execução é dada por números.
O diagrama de comunicação pode ser utilizado em uma etapa de testes lógicos ou conceituais dos modelos desenvolvi-
dos. Observe que o diagrama de comunicação pode ser desenvolvido como uma extensão do diagrama de caso de uso,
detalhando o caso de uso por meio da inclusão dos objetos, mensagens e parâmetros trocados entre os objetos.
• O diagrama de comunicação inclui atores, objetos, mensagens e componentes do sistema.
• Objetos podem ser conectados por relações de associação ou dependência. As dependências entre os nós representam
relações de comunicação (podendo ser unidirecionais ou bidirecionais).
• Um diagrama de comunicação pode ser detalhado usando-se uma numeração como em 1; 1.1; 1.2; e assim por diante.
• Algumas ferramentas CASE podem gerar o diagrama de comunicação a partir do diagrama de eventos e vice-versa.
• [Fowler and Scott, 2000] consideram que o estudo de alternativas, isto é, variações nos diagramas de comunicação e
seqüência podem ser exploradas com o uso de cartões CRC.
Prefácio 73
Figura 1.32: Diagrama de comunicação – montando uma prova
Prefácio 74
Veja na Figura 1.33 uma representação de um diagrama de comunicação equivalente ao diagrama de seqüência da
Figura 1.31. O diagrama de comunicação ilustrado na Figura 1.33 mostra a seqüência para cálculo da área de uma função.
Figura 1.33: Diagrama de comunicação – seqüência para cálculo da área de uma função
Prefácio 75
1.5.3 UML - Diagrama de máquina de estado

Um diagrama de máquina de estado representa os diversos estados que o objeto assume e os eventos que ocorrem ao
longo de sua vida ou mesmo ao longo de um processo (histórico do objeto). É usado para modelar aspectos dinâmicos
do objeto.
Elementos presentes em um diagrama de máquina de estado são:
• Estado – indica de forma abreviada o estado do objeto. Um exemplo de estado é a realização de uma atividade
demorada. Por exemplo: realizando entrada de dados, processando integração, processando montagem dos gráficos
(veja a Figura 1.37). Veja na Figura 1.34 (a) o protótipo de representação de um estado, o qual inclui: o nome do
estado, a ação de entrada(entry), a atividade a ser realizada(do) e a ação de saída(exit).
– Nome – indica o nome do estado/atividade e deve ser único.

– entry – ação de entrada, a ser executada quando entra no estado.
– do/atividade – indica uma atividade em andamento.
– exit – ação de saída a ser executada quando sai do estado.
Prefácio 76
• Evento – causa a transição de estado (provoca execução da ação que muda o estado do objeto).
• Condição de guarda (guard condition) – uma condição de guarda impõe algum tipo de restrição à transição
de estado. É uma restrição booleana, se verdadeira a ação que provoca a transição de estado é executada. Uma
condição é representada entre colchetes {}. Por exemplo: um aluno só será considerado aprovado se tiver obtido
média final maior que 6 (veja a Figura 1.34).
• Ação – todo método que é executado quase instantaneamente e que está associado a um evento é denominado
ação (action). As ações podem representar operações internas de controle. Ações internas não mudam o estado do
objeto. Quando as transições de um estado executam a mesma ação, pode-se vincular o estado à ação. Ações estão
associadas a transições.
Prefácio 77
Veja na Figura 1.34 (b) um exemplo de diagrama de máquina de estado para um aluno. Observe que este é formado
por nós que representam os estados e setas que representam as transições entre os estados; observe também como são
representados o estado inicial e final.
Inicie a construção do diagrama de máquina de estado a partir dos diagramas de seqüência; use os eventos oriundos
dos casos de uso. Todo caso de uso corresponde a um caminho a ser seguido no diagrama de máquina de estado, ou
seja, deve-se comparar os diversos casos de uso e verificar os pontos em que eles divergem (e que precisam ser codificados
no diagrama de máquina de estados). Lembre-se de que dois caminhos em um diagrama de máquina de estado serão os
mesmos se o objeto esquecer os valores passados.
Veja na Figura ?? os estados de uma thread e na Figura 1.36 os estados de um processo.
Prefácio 78
Figura 1.34: Diagrama de máquina de estado – um aluno

Prefácio 79
Figura 1.35: Diagrama de máquina de estado – estados de uma thread
Prefácio 80
Figura 1.36: Diagrama de máquinas de estado: estados de um processo
Prefácio 81
Figura 1.37: Diagrama de máquina de estado – estados do objeto simulador
Prefácio 82
1.5.4 UML - Diagrama de atividades

O diagrama de atividades também se preocupa com questões dinâmicas, mas em um nível mais detalhado, sendo
utilizado para descrição dos diversos métodos das classes. Segundo [Blaha and Rumbaugh, 2006], "um diagrama de
atividades mostra a seqüência de etapas que compõem um processo complexo, como um algoritmo ou fluxo de trabalho";
seu enfoque são os métodos e não os objetos. Isto é, o objetivo do diagrama de atividades é descrever algoritmos e
funcionalidades complexas, detalhando um estado de atividade do diagrama de máquina de estados.
• O diagrama de atividades se preocupa com os valores de entrada e saída dos métodos, como os atributos são
alterados, as dependências entre os métodos.
• Em um diagrama de atividades os nós representam ações ou atividades, e as linhas representam transições (uma
transição pode ocorrer quando a ação/atividade anterior foi completada).
• Os diagramas de atividades são especialmente importantes em áreas como engenharia.
• O diagrama de atividades é baseado em redes de petri; é semelhante a um fluxograma, a diferença é que ele permite
que atividades sejam executadas paralelamente.
Prefácio 83
Os elementos presentes em um diagrama de atividades são:
• Estado de ação – descreve a atividade que está sendo executada.
• Transições – são setas que indicam que a atividade anterior terminou e que a nova atividade vai ser executada.
• Barra de sincronização (bifurcação/separação) – quando o método admite processamento paralelo, utilizamos

barras de sincronização para indicar uma separação dos processos.
• Barra de sincronização (aglutinação/junção) – a barra de sincronização é utilizada ainda para representar a

aglutinação de uma atividade.
• Losangos – losangos são utilizados para indicar tomadas de decisão, uso de estruturas de controle, como um if,
um switch. Uma breve descrição sobre a decisão pode ser incluída utilizando-se anotações.
Prefácio 84
A Figura 1.38 mostra em (a) o protótipo de um diagrama de atividades. Observe que estão presentes os indicadores de
início e fim da atividade (os mesmos do diagrama de máquinas de estado), losangos para tomada de decisão, bifurcações
e aglutinações (utilizadas para indicar processamento concorrente) e as atividades.
A Figura 1.38 (b) mostra o diagrama de atividades de um método de binarização (transforma uma imagem em tons
de cinza ou colorida em imagem preto/branco). Observe que se a imagem já estiver binarizada o método não faz nada.
Se a imagem é em tons de cinza, chama o método que binariza imagens em tons de cinza e, se for imagem colorida, chama
o método que binariza imagens coloridas. Observe que é um método político e envolve apenas tomadas de decisões. O
processamento será feito em métodos auxiliares.
Prefácio 85
Figura 1.38: Em (a) o protótipo de um diagrama de atividades. Em (b) o diagrama de atividades de um método de
binarização
Prefácio 86
A Figura 1.39 mostra o diagrama de atividades para o método do Trapézio. O mesmo é utilizado para calcular a
área de uma função. Observe que toda seqüência de cálculo é detalhada. Note que temos nas figuras duas versões, qual
a melhor?
Prefácio 87
Figura 1.39: Diagrama de atividades – método do Trapézio para cálculo da área
Prefácio 88
Figura 1.40: Diagrama de atividades – método do Trapézio para cálculo da área - Usando número intervalos
Prefácio 89
Figura 1.41: Etapas de desenvolvimento de um software: Análise Orientada a Objeto - Modelo Dinâmico - Iteração
Prefácio 90
Figura 1.42: Etapas de desenvolvimento de um software: projeto do sistema

Prefácio 91
1.6 Projeto do sistema

Depois da análise orientada a objeto desenvolve-se o projeto do sistema.
O mesmo envolve etapas como a definição dos protocolos, o uso de recursos (a subdivisão do sistema em subsistemas,
a alocação dos subsistemas ao hardware), a seleção das estruturas de controle, a seleção das plataformas do sistema, dos
padrões de projeto, licença do software, ferramentas, além da tomada de decisões conceituais e políticas que formam a
infraestrutura do projeto.
Deve-se definir padrões de documentação, padrões para o nome das classes, padrões de retorno e de parâmetros
em métodos, características da interface do usuário e características de desempenho. Além da definição/seleção das
ferramentas a serem utilizadas.
Prefácio 92
Figura 1.43: Etapas de desenvolvimento de um software: Projeto do Sistema

Prefácio 93
Segundo [Rumbaugh et al., 1994, Blaha and Rumbaugh, 2006], o projeto do sistema é a estratégia de alto nível para
resolver o problema e elaborar uma solução. Você deve se preocupar com itens como:
1. Protocolos
• Definição dos protocolos de comunicação entre os diversos elementos externos

(como dispositivos).
– Por exemplo: se o sistema envolve o uso dos nós de um cluster, devem ser considerados aspectos como o
protocolo de comunicação entre os nós do cluster.
• Definição dos protocolos de comunicação entre os diversos elementos internos
(como objetos).
• Definição da interface API de suas bibliotecas e sistemas (veja a seção 1.6.1).
• Definição do formato dos arquivos gerados pelo programa.
– Por exemplo: prefira formatos abertos, como arquivos txt e xml.
Prefácio 94
2. Recursos
• Identificação e alocação dos recursos globais: como os recursos do sistema serão alocados, utilizados, compar-
tilhados e liberados. Implicam modificações no diagrama de componentes (veja a seção 1.7.2).
• Identificação da necessidade do uso de banco de dados. Implicam em modificações nos diagramas de atividades
e de componentes.
• Identificação da necessidade de sistemas de armazenamento de massa.
– Por exemplo: um storage em um sistema de cluster ou sistemas de backup ou simulação com grande
demanda de disco.
Prefácio 95
3. Controle
• Identificação e seleção da implementação de controle, seqüencial ou concorrente, baseado em procedimentos ou

eventos. Implicam modificações no diagrama de execução (veja a seção 1.7.3).
• Identificação das condições extremas e de prioridades.
• Identificação da necessidade de otimização.
– Por exemplo: prefira sistemas com grande capacidade de memória; prefira vários hds pequenos a um
grande.
• Identificação e definição de loops de controle e das escalas de tempo.
• Identificação de concorrências – quais algoritmos podem ser implementados usando processamento paralelo.
Prefácio 96
4. Plataformas
• Identificação das estruturas arquitetônicas comuns.

• Identificação de subsistemas relacionados à plataforma selecionada. Podem implicar em modificações no dia-
grama de pacotes (veja a seção 1.2.2) e no diagrama de componentes (veja a seção 1.7.2).
• Identificação e definição das plataformas a serem suportadas: hardware, sistema operacional e linguagem de
programação (veja a seção 1.6.3).
5. Padrões de projeto
• Normalmente os padrões de projeto são identificados e passam a fazer parte de uma biblioteca de padrões da
empresa. Mas isto só ocorre após a realização de diversos projetos.
6. Licença do software
• Se ainda não foi definida a licença é hora de escolher. Lembrando que se o pacote for grande diferentes partes
podem ter diferentes licenças.
7. Ferramentas
Prefácio 97
• Seleção das bibliotecas externas a serem utilizadas (veja a seção 1.6.4).

• Seleção da biblioteca utilizada para montar a interface gráfica do programa – GDI (veja a seção 1.6.5).
• Seleção do ambiente de desenvolvimento integrado – IDE (veja a seção 1.6.6).
• Seleção do sistema de controle de versões, documentação, montador (ex: cmake), testes e controle bugs.
Nota: uma das maiores preocupações de simulações de engenharia é o desempenho. A necessidade de se aliar desempenho,
interface gráfica amigável e reuso de bibliotecas limita o número de linguagens a serem utilizadas, de modo que C++
tem sido a mais indicada (veremos a otimização de programas em capítulos específicos).
Prefácio 98
1.6.1 Definição da interface de programação – API

Quando estamos desenvolvendo uma classe, um módulo ou um sistema, precisamos definir sua interface de acesso.
Uma API – Application Programming Interface ou interface de programação de aplicação é um conjunto de instruções
e informações sobre a forma como a biblioteca deve ser acessada. A API separa o que é público (acessível) do que é
protegido ou privado (inacessível).
Já mostramos que a visão do que é publico e do que é privado depende da audiência, isto é, de quem vai utilizar
a classe/módulo/sistema. Na prática isto significa que, quando formos definir as interfaces de nossos sistemas, pre-
cisamos definir claramente quem são seus usuários. Por exemplo: a API de bibliotecas como Qt, GTK, MFC, VCL são
desenvolvidas para programadores medianos.
O protocolo é o conjunto de métodos que podem ser acessados pelo usuário, o conjunto de mensagens a que o objeto
responde; ou seja, o protocolo é o conjunto de métodos públicos da classe.
Prefácio 99
1.6.2 Seleção da implementação de controle

O sistema ou subsistema de controle da execução do software pode ser implementado de diferentes formas. Veja a
seguir alguns exemplos:
• Se o sistema realiza seqüências predefinidas como em arquivos de lote (por exemplo, autoexec.bat, init.d), ou cálculos
seqüênciais, então o controle pode ser feito por arquivos ASCII, os quais determinam a seqüência a ser realizada.
Mecanismos de reinicialização do sistema podem ser incluídos. Este tipo de sistema utiliza uma estrutura de
controle chamada de transformação em lote, bastante utilizada em procedimentos de engenharia, no processamento
de transações bancárias (cheques) e transações agendadas.
• Um sistema com controle do tipo transformação contínua permite a realização de etapas de simulações. Para cada
bloco de tarefas executadas, o usuário analisa os resultados obtidos e toma decisões a respeito da seqüência de
execução do sistema, ou seja, o usuário pode alterar o fluxo de execução do programa.
• Em uma interface interativa os usuários interagem o tempo todo com o sistema (geralmente utilizando uma interface
gráfica - menus e ícones). De maneira geral, este tipo de controle é baseado em eventos e permite a execução
concorrente (pelo uso de múltiplas threads e/ou processos). O acesso compartilhado aos recursos pode ser controlado
por bloqueadores de acesso (mutex ). Sistemas de software modernos com controle do tipo interface interativa
utilizam listas e podem ter macros para execução de atividades repetitivas.
Prefácio 100
Sistemas científicos e simulações de engenharia (como processamento de dados, sinais e imagens, simulações químicas e
ambientais, simulações de reservatório) podem utilizar um dos tipos de controle acima definidos. Se a simulação é fechada
(dados de entrada e saída previamente definidos), pode-se utilizar tranformação em lote, sua grande vantagem é não
requerer paradas para entrada de dados. Se existem poucas necessidades de interação com o usuário, use transformação
contínua. Sistemas modernos de engenharia utilizam interface interativa, possibilitando um controle mais refinado das
simulações a serem realizadas. A dificuldade aqui é que em alguns casos as simulações são lentas e o usuário fica preso, ou
seja, precisa esperar um determinado tempo, responder a um questionamento do software, esperar de novo, e isso pode
ser improdutivo.
Prefácio 101
1.6.3 Seleção das plataformas a serem suportadas

Uma plataforma de programação envolve o hardware, o sistema operacional e a linguagem de programação. Veja a
seguir alguns exemplos:
• Computador do tipo Macintosh – sistema operacional Mac Os X – linguagem C.
• Computador do tipo PC/Intel – sistema operacional Windows – linguagem C++.
• Computador do tipo Workstation/AMD – sistema operacional GNU/Linux – linguagem C++.
Um programa em ANSI C++ pode ser compilado em diversas plataformas. O procedimento é simples; basta copiar o
código-fonte para a plataforma-alvo e, em seguida, compilar os programas usando um compilador padrão Ansi C++.
Atualmente é usual os códigos estarem num repositório na nuvem. A criação automatizado dos arquivos Makefile pode
ser feita por sistemas montadores, como exemplo o cmake.
Prefácio 102
1.6.4 Seleção das bibliotecas externas

No projeto do sistema é necessário definir quais bibliotecas externas serão utilizadas.
• Segundo [Korson and Macgregor, 92], uma biblioteca orientada a objeto deve:
– ter protocolos uniformes (nomes e assinaturas),

– focar um tema completo (fechado), mas considerando generalidades (aliando, na medida do possível, uniformi-
dade, completude e generalidade).
– permitir sua extensão.
– ser eficiente.
• A dica é utilizar bibliotecas reconhecidas e bem-documentadas, como as bibliotecas da GNU.
Prefácio 103
Veja a seguir alguns exemplos de bibliotecas externas.
Exemplos de bibliotecas externas

• Biblioteca boost, veja
http://www.boost.org/.
• Bibliotecas da GNU, veja

http://www.gnu.org.
• Bibliotecas disponibilizadas no site Scientific Applications on Linux (SAL), veja

http://sal.linet.gr.jp/index.shtml.
• Bibliotecas disponibilizadas no site The Object-Oriented Numerics Page, veja

http://www.oonumerics.org/oon/.
• Biblioteca magick++, veja

http://www.simplesystems.org/Magick++/.
• Biblioteca de métodos numéricos, veja

http://users.physik.tu-muenchen.de/gammel/matpack/.
Prefácio 104
1.6.5 Seleção da biblioteca gráfica a ser utilizada – GDI

Há alguns anos desenvolvia-se um programa em computadores PC XT/AT, utilizando-se um ambiente em modo
texto, pois não existiam janelas e ícones. Posteriormente, boa parte dos programas utilizam janelas, ícones, menus etc,
e são desenvolvidos para plataformas computacionais como o PC/Windows Vista, estações de trabalho rodando Unix,
GNU/Linux com interface gráfica padrão MOTIF, GNOME, KDE, ou mesmo Macintosh rodando MAC OS System X.
Desenvolver um programa "For Windows", assim que se lançou o Windows 3.0, era uma verdadeira calamidade, pois
a API do Windows só fornecia algumas funções básicas, e o programador tinha que escrever praticamente tudo o que ia
utilizar. Situação semelhante ocorria com os demais ambientes de janelas.
Desenvolver um programa para um ambiente de janelas tornou-se mais fácil, graças a bibliotecas de interfaces gráficas
orientadas a objeto (GDI), como a Qt, a GTK, a VCL, a MFC, wxwidgets, entre outras. Essas interfaces fornecem toda
uma hierarquia de classes que podem ser imediatamente herdadas pelo seu programa. Você pode criar janelas, menus,
botões, barras de ferramentas, entre outros objetos, com muita facilidade.
Entretanto, para que se possa desenvolver um programa para um ambiente gráfico, é preciso aprender programação
orientada a objeto. Você só conseguirá herdar e utilizar os objetos fornecidos pelas bibliotecas gráficas se compreender a
programação orientada a objeto e a sintaxe de C++.
As bibliotecas gráficas mais utilizadas no ambiente Windows são a VCL, do Builder, Delphi e a MFC, do Microsoft
Visual C++. No ambiente GNU/Linux, as mais utilizadas são as bibliotecas Qt (da TrollTech/KDE), a biblioteca GTK
(da GNU/GNOME) e wxwidgets.
Prefácio 105
• qt: https://www.qt.io/
– Qt usa a licença GNU LGPL (veja seção 1.6.7).
• gtk: https://www.gtk.org/
– GTK usa a licença GNU LGPL. GTK integra o projeto GNU.
• wxwidgets: https://www.wxwidgets.org/
– Usa licença LGPL com uma exceção. "The wxWindows Library Licence is essentially the L-GPL (Library
General Public Licence), with an exception stating that derived works in binary form may be distributed on the
user’s own terms. ".
Prefácio 106
1.6.6 Seleção do ambiente de desenvolvimento integrado – IDE

Uma IDE é uma interface integrada para o desenvolvimento de programas e softwares avançados. Ela facilita a vida do
programador, pois as diversas ferramentas a serem utilizadas – editor de texto, compilador, linker, debugger, montador,
sistema de controle de versões, entre outros – estão integrados em uma única ferramenta (veja https://youtu.be/GPcIjsz-
2cA).
Nota: se o sistema que vai ser desenvolvido é grande, então a etapa de projeto pode ser feita em paralelo à análise e
deve considerar as experiências da equipe de desenvolvimento.
Prefácio 107
1.6.7 Seleção da licença do software

Toda biblioteca de códigos ou software deve ter associado uma licença de uso.
• O site https://choosealicense.com/ pode lhe ajudar a escolher uma licença.
• Para bibliotecas dê uma olhada em LGPL
– LGPL é software livre, permite que software proprietários e livres o utilizem em sua construção. Ou seja, não
há muitas questões legais que impeçam o seu uso, mas lembre de usar linkagem dinâmica e não estática.
– •{} https://choosealicense.com/licenses/lgpl-3.0/.
• Para códigos em geral dê uma olhada GPL3.
– GPL3 é software livre.

– https://choosealicense.com/licenses/gpl-3.0/.
Prefácio 108
Figura 1.44: Etapas de desenvolvimento de um software: Projeto do Sistema - Iteração
Prefácio 109
Figura 1.45: Etapas de desenvolvimento de um software: projeto orientado a objeto

Prefácio 110
Prefácio 111
1.7 Projeto Orientado a Objeto – POO

O projeto orientado a objeto é a etapa posterior ao projeto do sistema (veja a Figura 1.2). Baseia-se na análise, mas
considera as decisões do projeto do sistema.
• Revisão dos modelos considerando o projeto do sistema (veja seção 1.7.1).
• Construção de diagramas de componentes (veja seção 1.47).
• Construção de diagramas de implantação/distribuição (veja seção 1.7.3).
• Construção da lista das características (veja seção 1.7.4).
A Figura 1.46 ilustra estas etapas.
Prefácio 112
Figura 1.46: Etapas de desenvolvimento de um software: Projeto Orientado a Objeto

Prefácio 113
1.7.1 Revisão dos modelos considerando o projeto do sistema

Nesta etapa precisamos revisar os modelos.
• Acrescenta a análise desenvolvida as características do projeto do sistema, incluindo protocolos, recursos,

controle, plataforma escolhida (hardware, sistema operacional e linguagem de programação).
• Passa pelo maior detalhamento do funcionamento do programa, acrescentando atributos e métodos que
envolvem a solução de problemas específicos não identificados durante a análise. De um modo geral a definição
da plataforma impacta as bibliotecas e sistemas externos a serem utilizados e isso precisa ser incluído
nos projetos.
• Envolve a otimização da estrutura de dados e dos algoritmos, a minimização do tempo de execução, de memória e
de custos. Existe um desvio de ênfase para os conceitos da plataforma selecionada.
– Exemplo: na análise você define que existe um método para salvar um arquivo em disco, define um atributo
nomeDoArquivo, mas não se preocupa com detalhes específicos da linguagem. Já no projeto, você inclui as
bibliotecas necessárias para acesso ao disco, cria um objeto específico para acessar o disco, podendo, portanto,
acrescentar novas bibliotecas e classes àquelas desenvolvidas na análise.
Prefácio 114
1.7.2 UML - Diagrama de componentes

O diagrama de componentes mostra a forma como os componentes do programa se relacionam, suas dependências.
Inclui itens como: componentes, subsistemas, executáveis, nós, associações, dependências, generalizações, restrições e
notas.
Exemplos de componentes são bibliotecas estáticas, bibliotecas dinâmicas, dlls, componentes Java, executáveis, ar-
quivos de disco, código-fonte.
Algumas observações úteis para o diagrama de componentes:
• De posse do diagrama de componentes, temos a lista de todos os arquivos necessários para compilar
e rodar o programa.
• Observe que um assunto/pacote pode se transformar em uma biblioteca e será incluído no diagrama de componentes.
• A ligação entre componentes pode incluir um estereótipo indicando o tipo de relacionamento ou algum protocolo
utilizado.
Prefácio 115
Figura 1.47: Diagrama de componentes - UML

Prefácio 116
Prefácio 117
Figura 1.48: Etapas de desenvolvimento de um software - exemplo diagrama de componentes

Prefácio 118
1.7.3 UML - Diagrama de implantação - distribuição – execução

O diagrama de implantação/distribuição/execução é um diagrama de alto nível que inclui relações entre o
software e o hardware, a topologia do sistema.
• Se preocupa com os aspectos da arquitetura computacional escolhida.
• Seu enfoque é o hardware, a configuração dos nós em tempo de execução.
• O diagrama de implantação deve incluir os elementos necessários para que o sistema seja colocado em
funcionamento
– computador, periféricos, processadores, dispositivos externos,
– subsistemas, componentes,
– nós, relacionamentos de dependência, associação, restrições e notas.
• Pode-se utilizar uma anotação de localização para identificar onde determinado componente está residente, por
exemplo {localização: sala 3}.
• Note que muitas vezes um sistema de engenharia inclui dezenas de equipamentos concectados, como ocorre por
exemplo em uma plataforma de petróleo. O diagrama de distribuição mostra todos estes equipamentos, sistemas e
suas conecções.
Prefácio 119
Veja na Figura 1.49 um exemplo de diagrama de implantação/distribuição de um cluster. Observe a presença de um

servidor conectado a um switch. Os nós do cluster (ou clientes) também estão conectados ao switch. Os resultados das
simulações são armazenados em um servidor de arquivos (storage).
Prefácio 120
Figura 1.49: Etapas de desenvolvimento de um software - exemplo diagrama de implantação/distribuição

Prefácio 121
1.7.4 Construção da lista das características

Nesta etapa é feita uma análise que tem como objetivo listar as características principais (ou recursos/features)
do sistema. Esta listagem deve considerar a montagem de tantas versões intermediárias(sub-produtos), quantas forem
necessárias. Na prática, a equipe precisa definir o tamanho de cada ciclo de desenvolvimento/entrega. Se, por exemplo,
um software vai demorar 12 meses para ser concluído e o ciclo previsto é de 30 dias, então teremos 12 versões do software.
• Lista das características:
– Listar as características principais e secundárias.

– Organizar por ordem lógica de implementação (vale a experiência).
• Gestão:
– Estimativa do tempo total de produção, prazo para conclusão do software (considerar margem de erro).
– Definição do prazo de cada ciclo e cálculo do número de ciclos e versões.
– Colocar a lista das características em software de gestão específico, como exemplo o trello e o google tables.
Prefácio 122
Figura 1.50: Etapas de desenvolvimento de um software: Projeto Orientado a Objeto - Iteração
Prefácio 123
Figura 1.51: Etapas de desenvolvimento de um software: projeto orientado a objeto: Ciclo Planejamento e detalhamento
Prefácio 124
Prefácio 125
1.8 Ciclo planejamento e detalhamento

As etapas do ciclo planejamento e detalhamento são as mesmas do projeto orientado a objeto, mas agora, mais
detalhados e focados apenas nas características a serem implementadas no ciclo.
• É feito um detalhamento fino das características a serem desenvolvidas.
• Podem ser levados em conta aspectos de otimização e paralelismo.
• Os diagramas estruturais e dinâmicos são revisados e ampliados (com mais diagramas de atividades por exemplo).
• Também é feito um detalhamento de aspectos relacionados a parte operacional do desenvolvimento dos códigos.
• Entender bem as características da linguagem e bibliotecas selecionadas é fundamental, pois o foco passa a ser os
planos de implementação.
A Figura 1.52 mostra estas etapas do ciclo planejamento e detalhamento.
Nota: Note que existe uma diferença para a etapa de projeto orientado a objeto. Ali o software foi visto e analisado
como um todo, aqui a ênfase se dá apenas na lista de características/funcionalidades a serem implementadas em
cada ciclo c1, c2, ..., cn. É a velha ideia de dividir para conquistar. Note ainda que softwares de pequeno porte
podem ser desenvolvidos em apenas um ciclo.
Prefácio 126
Figura 1.52: Etapas de desenvolvimento de um software - ciclo planejamento/detalhamento

Prefácio 127
A Figura 1.2 ilustra as diversas etapas a serem seguidas, as mesmas são descritas a seguir.
Prefácio 128
Figura 1.53: Etapas de desenvolvimento de um software - ciclo construção - implementação

Prefácio 129
1.9 Ciclo construção - implementação

Nesta seção veremos o ciclo de construção/implementação.
• a implementação/codificação: algumas dicas para implementação da interface gráfica do programa e como montar
o código inicial do programa com o umbrello.
• a documentação do código (seção 1.11).
• os testes (seção 1.10).
– teste de unidade, de integração, de sistema, desempenho, compatibilidade, aceitação, regressão.
• a entrega de versões (sub-produtos).
Prefácio 130
Figura 1.54: Etapas de desenvolvimento de um software - ciclo construção

Prefácio 131
Figura 1.55: Etapas de desenvolvimento de um software - ciclo construção - implementação
Prefácio 132
1.9.1 Antes de iniciar a implementação

• À medida que se modelam as diversas classes e métodos, deve-se testar cada classe e cada método desenvolvido
(teste lógico).
• Antes de iniciar a implementação de um método complexo, você deve concluir o seu diagrama de atividades.
• Na implementação a dica é criar classes de teste para testar as classes e subsistemas criados (veja o item 4 da seção
1.10).
Prefácio 133
Figura 1.56: Mapeamento: conceito, diagrama uml e implementação

Prefácio 134
1.9.2 Roteiro para montar o código inicial do programa com o Umbrello

Softwares modeladores como o umbrello, o dia e o Visual-Paradigm podem ser utilizados para montagem do código
inicial do programa. De modo geral, o código é gerado a partir do diagrama de classes, e a maioria dos modeladores
implementa uma "casca" inicial do programa que inclui as classes, seus atributos, métodos, associações e documentações.
O programa umbrello pode ser utilizado para gerar o código inicial do programa. Uma das vantagens do umbrello é
que ele é software livre e tem a capacidade de gerar os códigos para diversas linguagens.
• C++, Actionscript, Ada, IDL, Java, JavaScript, Pascal, Perl, PHP, Python, Ruby, SQL, TCL, XMLschema.
Nota: se você ainda não tem o programa umbrello instalado, veja https://umbrello.kde.org/.
Prefácio 135
Veja a seguir um roteiro para montar o código inicial do programa com o umbrello.
1. Abra o programa umbrello.
2. Monte os diagramas de classes para seu sistema. Inclua todos os atributos, métodos e associações necessárias.
3. Revise o diagrama de classe. A idéia é só gerar o código depois que o diagrama de classe esteja correto.
4. Inclua as considerações do projeto e revise novamente o diagrama.
5. Selecione o item de menu ’Código->Linguagem Ativa’ e logo após selecione C++.
6. Selecione o item de menu ’Código->Assistente de Geração de Código’. No diálogo ’Assistente de Geração de Código’,
selecione as classes que devem ter seu código gerado e em seguida pressione o botão "Próximo".
7. No diálogo ’Opções de Geração de Código’ temos 3 abas:
(a) Geral – você define a linguagem a ser utilizada, além da pasta onde o programa vai ser armazenado e a política
de substituição de arquivos.
(b) Formatação – define características dos comentários, tipo e quantidade de indentação.
(c) Opções de linguagem – define características específicas da linguagem selecionada.
Prefácio 136
Depois de fazer suas opções pressione o botão "Próximo".
8. Confira as classes selecionadas e então pressione "Gerar". O código gerado estará disponibilizado no diretório
informado.
9. Use o editor ou IDE de sua preferência para editar os códigos gerados.
Com o código inicial do programa gerado por uma ferramenta CASE (como o umbrello ou o Visual-Paradigm), parte-se
para a implementação do programa. Nesta etapa são essenciais não só os conhecimentos da modelagem orientada a objeto,
mas da linguagem de programação, ou seja, as regras de sintaxe e a forma como a linguagem implementa a programação
orientada a objeto.
Prefácio 137
1.9.3 Dicas para implementação da interface gráfica

Para implementar a interface gráfica do programa, o engenheiro de software deve considerar aspectos como:
• Escolha uma biblioteca gráfica que seja software livre, que seja multiplataforma, que seja constantemente
atualizada.
• Padronização (consistência; operações semelhantes têm interfaces semelhantes).
• Na medida do possível, a interface deve ser orientada a objeto, isto é, os elementos visuais da interface devem
representar objetos internos.
• Use threads (processamento paralelo). Por exemplo: é interessante ter uma thread separada responsável pela
atualização da interface gráfica do sistema, enquanto outras threads estão realizando as atividades solicitadas.
• Diálogos devem lembrar as últimas opções selecionadas. Você pode incluir um botão "default".
• Veja um conjunto de instruções para construir interfaces gráficas amigáveis no documento

http://developer.gnome.org/projects/gup/hig/.
Prefácio 138
Figura 1.57: Etapas de desenvolvimento de um software - teste de software

Prefácio 139
Prefácio 140
1.10 Teste de software

Apresenta-se nesta seção o teste de software: o que é, porque devemos testar nossos softwares, a equipe de teste e
uma metodologia simplificada para o teste de software.
Prefácio 141
1.10.1 Porque testar?

O teste se preocupa com o funcionamento lógico do programa, se o software cumpre com seus objetivos,
se os requisitos de qualidade, usabilidade e performance foram atendidos. Segundo [Pressman, 2002], "o
objetivo do teste é encontrar o maior número possível de erros, com um mínimo de esforço aplicado, durante um intervalo
de tempo realístico".
• O objetivo primário do teste de software é diminuir as falhas de um software, tendo como conseqüência
uma redução no custo e no tempo de desenvolvimento do software.
• Entre as vantagens de um software bem testado estão o aumento da qualidade, da funcionalidade e a redução das
falhas. Outras conseqüências de um software bem testado é a redução na necessidade de suporte.
• Incluir no cronograma de desenvolvimento do sistema as atividades de teste.
• Controle o processo de teste. Você precisa definir o rigor, o nível de detalhamento dos testes a serem realizados.
Por exemplo: um programa para controle de vôo requer um sistema de testes extremamente rigoroso.
• Use procedimentos automatizados para execução do teste (como check-list e programas de teste).
• Use uma metodologia de teste adaptada à sua equipe.
Prefácio 142
1.10.2 Uma sequência para teste

A Figura 1.58 mostra uma sequência possível para realização dos testes. Cada equipe deve definir sua metodologia.
Prefácio 143
Figura 1.58: Etapas de desenvolvimento de um software - ciclo construção - implementação - sequência para testes
Prefácio 144
1. Teste da dinâmica do sistema (teste lógico):
• Todos os diagramas de caso de uso foram considerados? Foram utilizados para montagem dos diagramas de
comunicação?
• O teste lógico é realizado sem nenhum código; para tanto, partimos dos diagramas de casos de uso e criamos
os diagramas de comunicação. No teste lógico é verificada a integração entre pacotes, componentes e classes.
• Quando necessário os diagramas de máquina de estado foram montados?
• Você montou os diagramas de atividade para os métodos complexos?
• Foram consideradas questões numéricas, como erros de arredondamento, conversões de dados/tipos.
Prefácio 145
2. Teste de unidade (classes, atributos, métodos e subsistemas):

Utilizado para verificar se cada unidade (classe, subsistema) está consistente. Deve ser realizado depois da imple-
mentação/revisão de cada classe.
3. Teste de integração:
Consiste em testar a integração entre as diversas partes do sistema (classes <-> classes, classes <-> subsistemas,
subsistema<->subsistema).
• Testar a integração entre as classes que fazem parte de um pacote/assunto ou hierarquia. Acesso, comunicação,
funcionalidade (usar diagramas de comunicação, de atividades, de componentes).
• Testar integração dentro de uma hierarquia.
• Testar as relações e integrações entre pacotes/subsistemas.
Prefácio 146
4. Teste de sistema (usuário <-> sistema):
• Teste de operação normal.

– Com alguns usuários (teste do sistema como um todo).
• Teste de estresse/desempenho.
– Rodar o sistema no limite (memória, tempo de processamento).
• Teste de compatibilidade (multiplataforma).
– Verifique se o sistema pode ser compilado, linkado e se roda em outras máquinas, com outros sistemas
operacionais e compiladores. A idéia é verificar se o sistema respeita o conceito multiplataforma.
• Teste de interoperabilidade.
– Testar/verificar o formato dos arquivos gerados. Verificar se o arquivo gerado em uma plataforma pode
ser aberto em outra (a dica é usar padrões abertos).
• Teste de segurança.
– Alguns softwares tem requisitos importantes de segurança e devemos ter testes com esta finalidade.
• Teste de aceitação.
– Teste de instalação. O programa de instalação funciona?
Prefácio 147
– Teste dos manuais, tutoriais. Os manuais foram feitos? Foram revisados? Os links estão corretos?
• Teste de versões.
– Consiste em distribuir o sistema e receber o retorno dos usuários (versões alfa e beta).
Prefácio 148
5. Teste de regressão:
Toda vez que alteramos uma parte do sistema que estava funcionando, podemos adicionar novos bugs. O teste
de regressão é realizado para verificar se o programa continua funcionando. Para reduzir o número de testes de
regressão procure deixar suas classes completas.
• Deve ser realizado sempre que uma classe é alterada.

• Quando temos certeza de que programa está correto, usamos o programa de teste para gerar uma saída-padrão,
que é armazenada no disco (exemplo: NomeClasse.padrao.out). A cada nova execução do teste, uma nova saída
é gerada (exemplo: NomeClasse.regressao.out). As duas versões são então comparadas com o programa diff.
Se existirem diferenças, então o programa não passou no teste, e o código precisa ser corrigido. Atualmente
temos programas que automatizam estes testes (ex: https://github.com/google/googletest).
Prefácio 149
Figura 1.59: Etapas de desenvolvimento de um software - documentação

Prefácio 150
1.11 Documentação do software

1.11.1 Porque documentar o software?
A documentação de um software é essencial pelos seguintes motivos:
• Compreensão do funcionamento do software e de seu planejamento.
• Acompanhamento da execução das atividades de implementação, testes e depuração.
• Compreensão e controle das atividades desenvolvidas.
• Permite a manutenção e a alteração do software por terceiros.
• Preparação dos manuais e da ajuda [help] do software.
• Atualmente a documentação considera conceitos de Clean Code (veja https://youtu.be/ln6t3uyTveQ).
• Atualmente a documentação do código é processada por softwares, como o doxygen, que gera a documentação em
vários formatos, incluindo html, pdf, latex, rtf.
Prefácio 151
1.11.2 Uma sequência para documentação

A Figura 1.60 mostra uma sequência possível para realização da documentação. Cada equipe deve definir sua metodolo-
gia.
Prefácio 152
Figura 1.60: Etapas de desenvolvimento de um software - ciclo construção - implementação - sequência para documentação
Prefácio 153
1.11.3 Arquivos mínimos de documentação

Deve-se criar um diretório onde serão armazenados os arquivos do software a ser desenvolvido. Neste diretório serão
incluídas todas as informações relativas ao software, ou seja, a documentação da análise orientada a objeto, do projeto do
sistema, do projeto orientado a objeto, das bibliotecas desenvolvidas, dos testes realizados, o arquivo de help do software
(tutoriais e manuais).
No diretório-raiz crie os arquivos:
• README/LEIAME
– com informações básicas sobre o sistema;
• INSTALL
– com instruções para instalação do programa;
• ChangeLog
– lista das modificações;
• NEWS
Prefácio 154
– novidades da versão;
• BUGS
– bugs identificados/solucionados;
• COPYING
– instruções sobre a licença do programa;
• AUTHORS
– lista de autores;
• TODO
– tarefas e questionamentos sobre possíveis mudanças;
Nota: para o desenvolvedor existe um efeito secundário associado à documentação do sistema, que é o estudo, a com-
preensão e a descrição do próprio código.
Prefácio 155
1.11.4 Documentação embutida no código

Lista-se abaixo um conjunto de itens que devem ser documentados. Cabe destacar que boa parte deles será documen-
tada dentro do código, usando, por exemplo o doxygen (https://www.doxygen.nl/index.html).
• Documentação do sistema.
• Documentação dos subsistemas, assuntos/pacotes.
• Documentação dos componentes externos, dos artefatos externos.
• Documentação das pastas (diretórios).
• Documentação das classes, classes de interface, atributos e métodos.
• Documentação das associações.
• Documentação das enumerações.
• Documentação dos casos de uso e diagramas que requeiram alguma explicação.
• Documentação dos atores.
Prefácio 156
Note que ao incluir classes, atributos, métodos, associações, artefatos e outras entidades nos diagramas UML, softwares
modeladores como o umbrello, já disponibilizam locais para inserção da documentação. Veja Figura 1.61. Outros itens
são documentados diretamente no código.
Prefácio 157
Figura 1.61: Etapas de desenvolvimento de um software - espaço para documentação já esta nos modeladores UML
Prefácio 158
A titulo ilustrativo veja a seguir como fica a documentação de atributos e métodos usando o padrão javadoc em C++.
Esta documentação será processada por softwares externos como o doxygen.
• Documentação de atributo
1 int b ; // / < Comentário pequeno , embutido

2 int a ; /* * < Comentário detalhado embutido após o atributo */
• Documentação de método
1 /* * Breve descrição do método .

2 * Descrição detalhada do método
3 * @fn Soma
4 * @param int a
5 * @param int b
6 * @return retorna a soma ( int )
7 * @see coloque aqui um link para informações adicionais
8 */
9 int TMath :: Soma ( int a , int b ) { return a + b ; };
Prefácio 159
Figura 1.62: Imagem gerada pelo doxygen/graphviz/dot Ilustração gráfica das dependências do arquivo CRotulador3D
Prefácio 160
1.11.5 Documentação - manuais do usuário e técnico científico

Além da documentação de código os softwares costumam incluir:
• Manual do usuário:
– Antigamente era fornecido junto com os softwares no formato impresso. Atualmente é fornecido no formato
pdf e/ou html.
– Apresenta informações e explicações de instalação e uso do software.
– Deve ser bem feito.
• Manual técnico científico:
– Sempre disponível em aplicativos técnicos, como softwares de engenharia e ciências.

– Apresenta informações técnicas, incluindo detalhes e informações dos modelos, métodos, equações utilizadas
para solução dos diversos problemas.
– Deve ser bem abrangente e com muitas referências técnicas (fontes).
Ambos os manuais podem ser desenvolvidos utilizando-se sistemas profissionais, como exemplo usamos o sistema composto
pelo editor de texto LyX/TeX/LaTeX (http://lyx.org).
Prefácio 161
1.12 Manutenção e reuso de software

A manutenção do software envolve a correção dos bugs remanescentes e a necessidade de se extender o software. A
questão da manutenção envolve ainda aspectos como custo da manutenção, custo para desenvolvimento de novas versões,
além de como manter a equipe de desenvolvimento.
A reutilização consiste em elaborar um software com a preocupação de este ser posteriormente reaproveitado. A idéia
por trás do reuso do software é simples: construir módulos, bibliotecas e classes que possam ser reaproveitados por você,
sua equipe de desenvolvimento e por terceiros. Para conseguir o reuso devemos melhorar os protocolos e aumentar o
empacotamento, viabilizando a construção de bibliotecas e frameworks.
Benefícios do reuso de software

• Redução de custo.
• Software mais testado e "debugado".
• Economia de tempo.
Prefácio 162
1.13 Gestão - o trello

Vimos ao longo de todo este processo que temos diversas reuniões a serem feitas, e que, a cada etapa, resultados são
gerados.
Para gestão do processo de desenvolvimento, o que esta sendo feito, por quem, quando, podemos utilizar diferentes
tipos de aplicativos, um exemplo é o trello ou o google tables.
Nas Figuras a seguir imagens do processo de desenvolvimento apresentado no software trello.
Prefácio 163
Figura 1.63: Usando o trello para gestão do processo de desenvolvimento - 1

Prefácio 164
Figura 1.64: Usando o trello para gestão do processo de desenvolvimento - 2

Prefácio 165
1.14 Leitura complementar

• Site
– Exemplo:
– https://www.emerson.com/pt-br/automation/operations-business-management/reservoir-management-software
• Livros
– Engenharia de software:
∗ [Rezende, 2002, Pressman, 2002, Booch, 1986, Melo, 2004]
– Modelagem:
∗ [Blaha and Rumbaugh, 2006, McLaughlin et al., 2006, Coad and Yourdon, 1993, Rumbaugh et al., 1994,
Winblad and others., 1993, Ann L. Winblad, 1990, Booch, 1986, R and B, 1998]
– UML:
∗ [Guedes, 2018, Lee, 2019, Silva, 2001, Fowler and Scott, 2000, Noback, 2020, de Matos, 2002]
– Processos:
∗ [Palmer and Felsing, 2002, Puri, 2009]
Prefácio 166
– Padrões de projeto
∗ [Eric Freeman, 2020, Erich Gamma and Vlissides, 1994, Gamma et al., 1994]
Prefácio 167
1.15 Resumo do capítulo

Neste capítulo aprendemos as diversas etapas para o desenvolvimento de um software. Desde a especificação até a
documentação e a manutenção.
Vimos que a especificação do software deve ser feita textualmente e pode incluir cenários de uso, exemplos de uso. Os
cenários são visualizados com ajuda dos diagramas de caso de uso, os diagramas mais simples da UML.
Em seguida, aprendemos que precisamos fazer uma elaboração do problema, um estudo do problema, envolvendo a
análise de domínio, a identificação de pacotes e seus diagramas.
Na etapa de análise orientada a objeto, vimos que o modelo estrutural se preocupa com a identificação de classes, dos
atributos, dos métodos e com a montagem do diagrama de classe.
Vimos como identificar as associações, agregações, composições, heranças, restrições, realizações e dependências e
como descrevê-las graficamente com os diagramas de classes.
Pelo modelo dinâmico descrevemos a dinâmica do sistema, tanto do ponto de vista do usuário (diagramas de caso
de uso) quanto do ponto de vista do sistema. O macrosistema é representado pelos diagramas de sequência e de comu-
nicação (eventos e mensagens). O comportamento das classes é descrito pelos diagramas de máquinas de estado. Já a
microdinâmica, que ocorre dentro dos métodos, é descrita pelos diagramas de atividade.
Na etapa de projeto do sistema definimos conceitos como os protocolos – API, a alocação de recursos, a definição
do tipo de controle e a especificação das plataformas. Inclui ainda a seleção de bibliotecas e de ambiente de desenvolvi-
mento. De posse do diagrama de implantação identificamos todos os equipamentos necessários para colocar o sistema em
Prefácio 168
funcionamento.
No projeto orientado a objeto aprendemos a montar os diagramas de componentes e de implantação (execução).
Na implementação aprendemos que podemos usar o umbrello para montagem do código inicial utilizando os diagramas
de classe. Aprendemos a importância do teste de software. Vimos que a documentação é uma etapa fundamental para o
desenvolvimento de programas com qualidade.
Finalmente, a manutenção envolve tanto a adaptação do software às novas solicitações dos usuários quanto a montagem
de bibliotecas reutilizáveis.
Uma maneira de "prever" o futuro é estar sempre atualizado, ler revistas de programação, inscrever-se em sites de
discussão das APIs que for utilizar e inscrever-se em sites de desenvolvimento de software.
Nota: deve-se ressaltar que os seus primeiros programas utilizando POO consumirão o mesmo tempo que os desenvolvidos
utilizando técnicas estruturadas. As vantagens do reaproveitamento aparecem à medida que os programas vão sendo
desenvolvidos, ou quando você já dispõe de uma biblioteca OO e pode desenvolver o software com ela.
Prefácio 169
1.16 Exercícios
1. Descreva, de forma resumida, as etapas para o desenvolvimento de um programa. Diga quais são as quatro etapas
mais importantes e justifique.
1.16.1 Exercícios - concepção

1. Faça a concepção de um software que será utilizado para (dica: consulte livros de métodos numéricos):
(a) cálculo da área de funções quaisquer utilizando diferentes métodos numéricos.

(b) solução de sistemas de equações.
(c) encontrar zeros de funções.
(d) cálculo de equações diferenciais utilizando métodos numéricos (exemplo: Runge-Kutta).
(e) realização de interpolações.
(f) ajuste de curvas (regressões).
(g) aproximação de polinômios.
2. Faça a concepção de um software que será utilizado para:
Prefácio 170
(a) "gerenciamento da manutenção dos sistemas de bombeamento da plataforma".

(b) "gerenciamento e controle do dano a formação do reservatório".
(c) "gerenciamento e controle da produção de óleo da plataforma".
(d) "caracterização de propriedades petrofísicas de rochas reservatório utilizando análise de imagens (imagens
de amostras de calha ou testemunho)". Como exemplo de propriedades temos: porosidade, permeabilidade,
distribuição do tamanho de poros, distribuição do tamanho de sólidos.
3. Faça as especificações de um programa que calcula o ajuste de um conjunto de pares ordenados x,y a uma função
polinomial. Isto é, como determinar uma curva (polinomial, 1D = reta, 2D = parábola) usando métodos como
mínimos quadrados?
(a) Monte um diagrama de caso de uso ilustrando cenários de interação do usuário com o programa.
(b) Monte os diagramas de classe incluindo os conceitos de associação, agregação e herança (generalização/espe-
cialização). Justifique suas decisões.
(c) Monte diagramas de máquina de estado para alguma classe.
(d) Monte diagramas de atividade para algum método.
Prefácio 171
1.16.2 Exercícios - elaboração

1. Faça a etapa de elaboração de um programa de computador relacionado a
(a) determinação da área de funções quaisquer utilizando diferentes métodos numéricos.

(d) solução de equações diferenciais utilizando métodos numéricos (exemplo: Runge-Kutta).
quais atividades devem ser realizadas.
2. Na etapa de elaboração de um programa de computador relacionado ao "gerenciamento da manutenção dos

sistemas de bombeamento da plataforma", quais atividades devem ser realizadas.
3. Na etapa de elaboração de um programa de computador relacionado ao "gerenciamento e controle do dano a

formação do reservatório", quais atividades devem ser realizadas.
Prefácio 172
4. Na etapa de elaboração de um programa de computador relacionado ao "gerenciamento e controle da produção

de óleo da plataforma", quais atividades devem ser realizadas.
5. Na etapa de elaboração de um programa de computador relacionado a "caracterização de propriedades petrofísicas

de rochas reservatório utilizando análise de imagens (imagens de amostras de calha ou testemunho)", quais atividades
devem ser realizadas.
Prefácio 173
1.16.3 Exercícios - análise

1. Um programa antigo, escrito em C, tem as seguintes variáveis e funções:
// Variáveis
float x,y,z, a,b,c;
float media,desvioPadrao;
double area, perimetro, volume;
double limiteInferior, limiteSuperior;
float vetorDados [100];
// Funções
// Calcula área de uma figura
double Area(..);
double Perimetro(..);
double Volume(..);
// Calcula área de uma função
double IntegralSimpson(..);
double IntegralTrapezio(..);
// Função de uma variável
Prefácio 174
float Fy(float x);

// Função de duas variáveis
float Fz(float x, float y);
float FormulaBasca(..);
// Calcula média de um grupo de dados, de um vetor
float Media(..);
float DesvioPadrao(..);
Monte o diagrama UML de um programa equivalente em C++ (diagrama de classes com atributos, métodos e
associações).
Dica: você deve agrupar atributos e métodos que se relacionam dentro de classes.
2. Para o diagrama de classes a seguir, acrescente alguns atributos e métodos (e eventualmente classes) e estabeleça
as relações entre as classes (associações, agregações e heranças).
• Exemplos de atributos: nome, número, capacidade, valor, data, dimensões, sexo, idade, extensão, entre outros.
• Exemplos de métodos: Contratar(), Despedir(), Abastecer(), Limpar(), PrepararPouso(), ConferirPassagem(),
Manutenção(), ApertarCinto(), MoverFlaps(), CheckIn(), entre outros.
Prefácio 175
• Monte um diagrama de eventos para o piloto.

• Monte um diagrama de comunicação para o passageiro.
Figura 1.65: Exercício – modelagem sistema aeroporto
Prefácio 176
3. Faça a análise dinâmica de um software que será utilizado para (consultar livro de métodos numéricos):

4. Faça a análise dinâmica de um software que será utilizado para:

Prefácio 177
1.16.4 Exercícios - projeto

1. Faça o projeto do sistema de um software que será utilizado para (consultar livro de métodos numéricos):

2. Faça o projeto do sistema de um software que será utilizado para:

Prefácio 178
Prefácio 179
1.16.5 Exercícios - projeto orientado a objeto

1. Faça o projeto orientado a objeto de um software que será utilizado para (consultar livro de métodos numéricos):

2. Faça o projeto orientado a objeto de um software que será utilizado para:

Prefácio 180
1.16.6 Exercícios - implementação

1. Veja na apostila de provas exemplos de especificações, elaborações e análises.
2. Escolha uma prova aplicada a modelagem numérica e implemente a mesma.
3. Escolha uma prova aplicada a engenharia - geociências e implemente a mesma.
4. Escolha uma prova aplicada a engenharia de reservatórios e implemente a mesma.
5. Escolha uma prova aplicada a processamento de imagens e implemente a mesma.
1.16.7 Exercícios - testes

1. Para as provas implementadas teste as mesmas.
Prefácio 181
1.16.8 Exercícios - documentação

1. Para as provas implementadas faça a documentação.
Referências Bibliográcas
[Ann L. Winblad, 1990] Ann L. Winblad, e. a. (1990). Object-Oriented Software. Addison-Wesley.
[Bassalo, 1996] Bassalo, J. M. F. (1996). Nascimentos da Física.
[Blaha and Rumbaugh, 2006] Blaha, M. and Rumbaugh, J. (2006). Modelagem e Projetos Baseados em Objetos com
UML 2. Campus, Rio de Janeiro.
[Booch, 1986] Booch, G., editor (1986). Object-oriented development, volume 12 of IEEE Transactions on Software
Engineering.
[Coad and Yourdon, 1993] Coad, P. and Yourdon, E. (1993). Análise Orientada a Objeto. Campus, São Paulo.
[de Matos, 2002] de Matos, A. V. (2002). UML - Prático e descomplicado. Érica, Rio de Janeiro.
182
Prefácio 183
[Eric Freeman, 2020] Eric Freeman, E. R. (2020). Head First Design Patterns: Building Extensible and Maintainable
Object-Oriented Software. O’Reilly Media, 2 edition. ISBN-13: 978-1492078005.
[Erich Gamma and Vlissides, 1994] Erich Gamma, Richard Helm, R. J. and Vlissides, J. (1994). Design Patterns. Addison
Wesley, New York.
[Fowler and Scott, 2000] Fowler, M. and Scott, K. (2000). UML Essencial. Bookman, São Paulo.
[Gamma et al., 1994] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design patterns: elements of reusable
object-oriented software. Pearson Education.
[Guedes, 2018] Guedes, G. T. A. (2018). UML Uma Abordagem Prática. novatec, São Paulo.
[Korson and Macgregor, 92] Korson, T. and Macgregor, J. D. (92). Technical criteria for the specification and evaluation
of object oriented libraries. Software Engineering journal, pages 85–94.
[Lee, 2019] Lee, G. (2019). Modern Programming: Object Oriented Programming and Best Practices: Deconstruct object-
oriented programming and use it with other programming paradigms to build applications. ISBN-13: 978-1838986186.
[McLaughlin et al., 2006] McLaughlin, B. D., Pollice, G., and West, D. (2006). Head First Object-Oriented Analysis and
Design. O’Reilly. ISBN-13: 978-0596008673.
Prefácio 184
[Melo, 2004] Melo, A. C. (2004). Desenvolvendo Aplicações com UML - Do conceitual à implementação. Brasport, Rio
de Janeiro.
[Noback, 2020] Noback, M. (2020). Object Design Style Guide: Powerful techniques for creating flexible, readable, and
maintainable object-oriented code in any OO language. Manning Publications. ISBN-13 : 978-1617296857.
[Palmer and Felsing, 2002] Palmer, S. R. and Felsing, J. M. (2002). A Practical Guide to Feature-Driven Development.
Prentice Hall, 1 edition.
[Pressman, 2002] Pressman, R. S. (2002). Engenharia de Software. MCGraw Hill, Rio de Janeiro, 5 edition.
[Puri, 2009] Puri, C. P. (2009). Agile Management: Feature Driven Development. Global India Publications Pvt Ltd, 1
edition.
[R and B, 1998] R, J. and B, F. (1998). Designing reusable classes. JOOP, pages 22–35.
[Rezende, 2002] Rezende, D. A. (2002). Engenharia de Software e Sistemas de Informação. Brasport, Rio de Janeiro.
[Rumbaugh et al., 1994] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1994). Modelagem e
Projetos Baseados em Objetos. Edit. Campus, Rio de Janeiro.
[Silva, 2001] Silva, D. M. D. (2001). UML - Guia De Consulta Rápida. Novatec, São Paulo.
Prefácio 185
[Winblad and others., 1993] Winblad, A. L. and others. (1993). Software Orientado a Objeto, volume 1. Makron Books,
São Paulo.
Índice Remissivo
Ambiente gráfico, 104 composições, 54
Ambientes de desenvolvimento, 106 comunicação, 72
Análise orientada a objeto, 45, 46, 62 Concepção, 21
AOO, 45, 46, 62 Controle, 95
Associações, 52 controle, 99
assuntos, 37
Diagrama de atividade, 82
Biblioteca gráfica, 104 Diagrama de caso de uso, 24
biblioteca gráfica, 104 Diagrama de classes, 51
bibliotecas, 102 Diagrama de classes com associações, 52
Diagrama de classes com heranças, 56
casos de uso, 24
Diagrama de colaboração, 72
colaboração, 72
Diagrama de componentes, 37, 114
componentes, 37
186
Prefácio 187
Diagrama de execução, 118 interface, 41

Diagrama de máquina de estado, 75
Lista das características, 121
Diagrama de pacotes, 37
Diagrama de sequência, 67 Manutenção, 161
Documentação, 150 Mensagens, 67
Documentação do software, 150 modelo, 62
Modelo de objetos, 46
Elaboração, 28
Modelo dinâmico, 62
especificação, 21
Modelo funcional, 82
Especificações, 21
estado, 75 Plataforma de programação, 101
Etapas de desenvolvimento de um programa, 15 Plataformas, 96
Eventos, 67 plataformas, 101
POO, 111
Ferramentas, 96
Projeto do sistema, 91
Generalização e herança, 56 Projeto orientado a objeto, 111
protótipo, 41
IDE, 106
Protocolos, 93
Implementação, 129
Interface, 98 Recursos, 94
Prefácio 188
Reuso, 161
Seleção de bibliotecas externas, 102
Teste, 140
Teste de Software, 140

Cap06 EtapasDesenvolvimentoPrograma SUPER REDUZIDO Apresentacao

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap06 EtapasDesenvolvimentoPrograma SUPER REDUZIDO Apresentacao

Enviado por

Direitos autorais:

Formatos disponíveis

Programação Orientada a Objeto com C++ Moderno

Professor André Duarte Bueno

– ANDRÉ DUARTE BUENO [Dr, Professor UENF/CCT/LENEP]

– TIAGO RIBEIRO SCHAEWER [M.Sc, UENF/CCT/LENEP]

• Esta apostila foi desenvolvida na UENF/CCT/LENEP/LDSC

• Laboratório de Desenvolvimento de Software Científico - LDSC

• do Laboratório de Engenharia e Exploração de Petróleo - LENEP

• do Centro de Ciências e Tecnologia - CCT

• da Universidade Estadual do Norte Fluminense - Darcy Ribeiro - UENF

• Site do Professor André Duarte Bueno

1.4 AOO – Análise Orientada a Objeto – Modelo estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.7 Projeto Orientado a Objeto – POO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

1.11.5 Documentação - manuais do usuário e técnico científico . . . . . . . . . . . . . . . . . . . . . . . . 160

Referências Bibliográficas 182

1.10 Etapas de desenvolvimento de um software: Elaboração - Análise de domínio, identificação de assuntos,

1.42 Etapas de desenvolvimento de um software: projeto do sistema . . . . . . . . . . . . . . . . . . . . . . . . 90

Etapas para o Desenvolvimento de um

Figura 1.1: Engenharia - Modelos, Processos, Projetos, Desenvolvimento/Implantação - Exemplo

Figura 1.2: Etapas de desenvolvimento de um software

Figura 1.3: Relacionamento dos diagramas estruturais da UML

Figura 1.4: Relacionamento dos diagramas dinâmicos da UML

1.1 Concepção – especificações, requisitos e cenários

Figura 1.5: Etapas de desenvolvimento de um software: Concepção

1.1.1 Exemplo especificação (simplificada)

1.1.2 UML - Diagrama de casos de uso

Figura 1.6: Diagrama de caso de uso geral

Figura 1.7: Diagrama de caso de uso específico – calcular área função

Figura 1.8: Diagrama de caso de uso: analisar resultados (uso de generalização)

1.2.1 Exemplo elaboração - cálculo da área (integral)

Note que a área do primeiro trapézio é definida pela seguinte equação.

f (x2) + f (x3) f (x3) + f (x4)

1.2.2 UML - Diagrama de pacotes/componentes – assuntos, módulos

Vantagens do uso de diagramas de pacotes:

• Muito utilizados em projetos de médio e principalmente de grande porte.

Figura 1.12: Diagrama de Assuntos/Pacotes: a lista de assuntos relacionados ao sistema

1.2.3 Montagem de protótipo da interface do software

Figura 1.14: Interface gráfica e eventos

Figura 1.15: Etapas de desenvolvimento de um software: Elaboração - iteração

Figura 1.16: Etapas de desenvolvimento de um software: análise orientada a objeto

1.3 AOO – Análise Orientada a Objeto

• Ao final da análise teremos um conjunto de diagramas:

– Estruturais: diagrama de classe, diagrama de estrutura composta(também chamado de diagrama de relaciona-

1.4 AOO – Análise Orientada a Objeto – Modelo estrutural

Figura 1.17: Relacionamento dos diagramas estruturais da UML

A Figura 1.18 ilustra as atividades relacionadas a AOO modelo estrutural.

1.4.1 UML - Diagrama de classes

Figura 1.20: Diagrama de classes – representando classes

1.4.2 UML - Diagrama de classes com associações

Figura 1.21: Diagrama de classes – representando associações

1.4.3 UML - Diagrama de classes com agregações e composições

Figura 1.22: Diagrama de classes – representando agregações

1.4.4 UML - Diagrama de classes com heranças

Figura 1.23: Diagrama de classes – representando heranças

Na Figura 1.24 ilustra-se a classe de interface.

Figura 1.24: Classe de interface

1.5 AOO – Análise Orientada a Objeto – Modelo dinâmico

Figura 1.26: Relacionamento dos diagramas dinâmicos da UML

A Figura 1.27 ilustra as atividades relacionadas a AOO - modelo dinâmico.

1.5.1 UML - Diagrama de seqüência – eventos e mensagens

Figura 1.29: Diagrama de seqüência – elementos

Veja na Figura 1.30 um exemplo de diagrama de seqüência.

Figura 1.30: Diagrama de seqüência – montando uma prova

Na Figura 1.31 mostramos a seqüência para cálculo da área de uma função.