Eng. Comp. - Análise O.O. - Caderno 01

Caderno 01
Unidades: 01 e 02
Prof. Sérgio Luiz Tonsig
1
A humanidade é altamente dependente do software em todos os setores. Não existe
segmento de atividade humana que não utilize de alguma forma o software, ele está presente desde
o campo até o espaço.
A criação de um produto baseado em software (sistemas de informação ou automação), a

exemplo de outros tipos de produtos, requer um processo específicos de construção, baseado em
alguma metodologia.
A análise de sistemas é a atividade da Engenharia de Software que cuida de estudar a

necessidade, ou problema, que um usuário deseja resolver, a fim de encontrar o melhor caminho
racional para a criação de produtos de software que irão solucionar o problema. O resultado da
análise é um projeto de software.
É pressuposto desse processo de construção de software, que o contexto de uso do produto
seja conhecido em detalhes, para que possa atender corretamente seus usuários e aos fins para os
quais o produto será construído.
O objetivo dessa unidade curricular é uma introdução ao processo de criação de um projeto
de software, promovendo um entendimento preciso sobre sistemas de informação, apresentando o
ambiente onde o analista de sistema irá atuar, quais são as características esperada nesse
profissional e apresentar os conceitos da metodologia orientada a objetos, que será aplicada para a
construção do projeto de sistemas.
2
Unidade 01 ............................................................................................................................................. 5
1. Teoria Geral dos Sistemas .................................................................................................................. 5
1.1. Conceito de Sistema .................................................................................................................... 5
1.2. Interdependência ...................................................................................................................... 10
1.3. Eventos em Sistemas ................................................................................................................. 13
1.3.1. Importação, alimentação, entrada ou input ...................................................................... 13
1.3.2. Exportação, saída ou output .............................................................................................. 14
1.3.3. Feedback ............................................................................................................................. 17
2. A Informação e as Organizações ...................................................................................................... 19
2.1. O que é dado? ........................................................................................................................... 19
2.2. O que é Informação? ................................................................................................................. 22
2.3. O que é conhecimento? ............................................................................................................ 22
2.4. O que é qualidade da informação? ........................................................................................... 24
2.5. Sistemas de Informação ............................................................................................................ 24
2.6. Desenvolvimento de Sistemas de Informação .......................................................................... 26
Unidade 02 ........................................................................................................................................... 28
3. Atividades da Análise de Sistemas ................................................................................................... 28
3.1. Características de um Analista de Sistema ............................................................................... 28
3.2. Levantamento de Requisitos ..................................................................................................... 29
3.2.1. Classificação de Requisitos ................................................................................................. 31
3.2.2. Como realizar o levantamento de requisitos ..................................................................... 32
3.2.3. Técnicas para o levantamento de requisitos...................................................................... 34
4. Paradigma da Orientação a Objetos ................................................................................................ 36
4.1. Origem ....................................................................................................................................... 36
4.2. Objeto, Classes, Atributos e Métodos ....................................................................................... 36
4.2.1. O que é um objeto? ............................................................................................................ 37
4.2.2. O que é uma Classe?........................................................................................................... 40
4.2.3. Atributos ............................................................................................................................. 41
4.2.4. Métodos.............................................................................................................................. 42
4.3. Herança entre classes................................................................................................................ 45
4.3.1. Sobrecarga do método ....................................................................................................... 46
3
4.4. Encapsulamento ........................................................................................................................ 47
4.4.1. Visibilidade.......................................................................................................................... 49
Referências Bibliográficas .................................................................................................................... 50
4
1.1. Conceito de Sistema
Essa aula vai nos levar a refletir sobre todos os aspectos que envolvem responder à questão
abaixo:
- O que é um sistema?
Tanto eu quanto você saberíamos, a priori, dar uma resposta a essa questão e, ela seria baseada
em nossa experiência de vida e conceitos que temos até o momento.
Seria interessante que você anotasse aí abaixo, na caixa disponível, qual é sua resposta a questão
que foi apresentada (com o conhecimento que possui nesse momento, sem recorrer a qualquer
pesquisa, trata-se de uma resposta pessoal). Observe que a pergunta não é sobre um sistema
específico, mas qualquer um; então, sua resposta deve ser para um sistema, de forma genérica.
Para você, o que é um sistema?
Para a formação de “Analistas de Sistemas” é de fundamental importância que se conheça,

em maior profundidade, o universo de conceitos que estão ligados a resposta solicitada na questão
do quadro acima. A resposta a princípio nos parece bem simples. E, de fato é, mas não deve ser
superficial. Dessa forma, o propósito dessa aula é mergulhar em algumas características que não só
trarão maior entendimento sobre a definição de sistemas, como nos ajudarão a planejar sua
construção.
Essa imersão exploratória que será realizada não é uma busca de conceitos novos, mas uma
redescoberta de aspectos que surgiram com o trabalho do biólogo austríaco Ludwig Von Bertalanffy1
que é considerado o pioneiro da Teoria Geral de Sistemas2.
1
Para saber mais: https://pt.wikipedia.org/wiki/Ludwig_von_Bertalanffy
2
Para saber mais:
https://pt.wikipedia.org/wiki/Teoria_geral_de_sistemas
https://steemit.com/cybernetic/@charlie777pt/teoria-geral-dos-sistemas-de-ludwig-von-bertalanffy
https://www.youtube.com/watch?v=-y55wUlk8bk
5
Observe as imagens na figura 01.
Figura 01 – Sistemas
- Quais são as semelhanças existentes nos sistemas apresentados?
Em qualquer uma das imagens observa-se que a palavra sistema está sempre acompanhada
de outra (s) que a qualifica (m). Esse fato também é percebido dentro das empresas, quando se faz
referências a seus sistemas de informações, como por exemplo:
- Nosso sistema de vendas registrou um recorde no último mês.
- O sistema de contas a receber está integrado com toda rede bancária.
- O sistema de controle de acesso de alunos, precisa de mais uma catraca.
Veja que nos exemplos de sistemas mencionados, todos eles possuem um objetivo
expressamente declarado; ou seja, a finalidade de sua existência. Não significa que um sistema não
possa ter outros objetivos secundários. Entretanto o objetivo declarado é a razão principal de sua
existência.
Existem outras semelhanças que você percebe nos sistemas da figura 01? Escreva abaixo.
A TGS (Teoria Geral de Sistemas) considera que qualquer sistema está inserido em um meio
ambiente; ou seja, tudo que é externo ao sistema, pode ser considerado seu meio ambiente. O meio
ambiente; portanto, pode ser um outro sistema, ou um conjunto de sistemas.
6
Verifica-se que os sistemas utilizam o meio ambiente para um intercâmbio (figura 02).
Figura 02 – Sistemas “importam” e “exportam” elementos através do meio ambiente.
A fotossíntese é um processo de troca gasosa com o meio ambiente. Nossa alimentação nada
mais é que a importação de produtos do meio ambiente e, um notebook, por exemplo “se alimenta”
com a tensão elétrica vindo do seu meio ambiente. Assim como os processos de “input” citados,
existem os de “output”; por exemplo, o notebook exibe em sua tela (exterioriza) informações, gera
sons, etc. que são expostos ao seu meio ambiente.
Através dessa troca é que ocorre a dinâmica de interconexão entre os diversos sistemas
existentes.
A TGS (Teoria Geral de Sistemas) traz conceitos aplicáveis a qualquer sistema,
independentemente de sua composição, estrutura, existência espacial ou temporal (figura 03).
Figura 03 – Sistemas dentro de Sistemas
7
A TGS considera que as funções de um sistema dependem de seu objetivo e sua estrutura.
Por exemplo, os tecidos musculares se contraem em função de que sua estrutura celular, permite
contrações. Um software IOT (Internet of Things3) pode comunicar-se via internet, uma vez que a
estrutura de sua constituição permite essa ação.
Portanto a TGS é aplicada em diferentes campos da ciência (administração, sociologia,

economia, etc.); mas, ela não busca solucionar ou criar alternativas práticas para problemas
existentes, mas produzir teorias e formular conceitos para aplicação em uma realidade empírica,
partindo-se dos problemas lá existentes; em ciência, conforme nos informa Rubens Alves, “todo
pensamento começa com um problema” (ALVES, 1991).
A TGS busca entender o todo (visão holística), que é formado por partes. Dessa forma, analisa
as partes e sua interferência ou contribuição no todo. Por isso, em software, não se tem uma única
opção que faz tudo. O que existe é um conjunto de opções no menu do sistema, que acionam
programas, que juntos, buscam atingir o objetivo a ser alcançado, como por exemplo, sistema de
controle do estoque.
Em um sistema de controle de estoque, podemos ter diversas partes, cada uma com um
objetivo específico dentro do todo. Por exemplo, o cadastro de fornecedores, o cadastro de
produtos, o cadastro de compra de produtos, o registro da saída do estoque, a consulta do estoque
de um determinado produto, etc.
Cada programa citado no exemplo anterior tem um objetivo específico e, não faz o trabalho
do outro; assim como a boca, em um sistema digestório, não faz o trabalho do estômago.
Mas, afinal, o faz um sistema, genericamente, de acordo com a TGS? A figura 04 nos revela a
resposta.
Figura 04 – Input, Processamento e Output.
3
Para saber mais: https://pt.wikipedia.org/wiki/Internet_das_coisas
8
Qualquer sistema, a partir dos “inputs” (entradas), realiza processos que podem gerar
transformação, desgaste, reorganização, consumo e, geram “outputs” (saídas).
Para realização do “processamento” um sistema conta com vários “elementos”. Considere,
por exemplo, o sistema digestório onde encontramos: a boca, o esôfago, estômago, intestino, etc.
Cada uma dessas partes, tem uma responsabilidade dentro do sistema.
O mesmo ocorre com um sistema de informação. Por exemplo, vamos considerar um sistema
de controle de vendas; lá poremos encontrar: o cadastro do cliente, o cadastro do produto, o registro
da venda, a emissão do documento fiscal, etc. Cada uma dessas partes, tem uma responsabilidade
específica, também.
Tanto no sistema digestório, quanto no sistema de vendas, existem “inputs” (entradas). Por
exemplo, uma maçã, que não foi fabricada pelo sistema digestório, poderá passar por ele, sobre
processamentos e depois, poderá originar “outputs”. No sistema de informação, como o caso de
vendas, também pode haver vários “inputs”; por exemplo, o registro de uma venda, onde entram
dados que são processados e depois podem gerar “outputs” (como por exemplo um documento
fiscal, uma consulta em tela, etc.).
Na bibliografia se encontram muitas definições de sistemas, no entanto, percebemos que

todas elas são similares, algumas muito genéricas e outras com maior abrangência.
Vamos ver algumas:
“Um sistema é um conjunto de objetos unidos por alguma forma de interação

ou interdependência. ” (Chiavenato, 1983).
“Conjunto de Elementos, entre os quais haja alguma relação. Disposição das

partes ou elementos de um todo, coordenados entre si, e que forma uma
estrutura organizada. ” (Ferreira, 1988).
“Um sistema é uma coleção significativa de componentes inter-relacionados,

que trabalham em conjunto para atingir algum objetivo. “ (Sommerville, 2011).
“Conjunto de entidades relacionadas, interdependentes, que interagem entre

si, buscando atingir um objetivo declarado e outros correlatos. “ (Tonsig, 2003).
9
1.2. Interdependência
Em vários exemplos apresentados anteriormente percebemos que os sistemas são formados

de partes (ou peças, ou módulos, ou componentes, etc.). Para efeito de facilitar o entendimento no
transcorrer dessa apostila, vamos chamar essas partes de “entidades”.
Há entidades que “nascem com o sistema”, como por exemplo o estômago no sistema
digestório, ou o cadastro de clientes no sistema de vendas. Entretanto, há outras entidades que
“estão em trânsito” pelo sistema, não nascem com ele: os alunos, no sistema de ensino; os dados no
sistema de informação; a maçã no sistema digestório (figura 05).
Figura 05 – Entidades em trânsito pelos sistemas
- O que pode ocorrer a um sistema de ensino, caso ele não tenha alunos?
- O que pode ocorrer com um sistema de locomoção, caso ele não tenha combustível?
- O que pode ocorrer com um sistema de informação, caso não tenha entrada de dados?
Fora as questões acima, ainda temos outros questionamentos referente a entidade que estará
em trânsito pelo sistema, como por exemplo:
- O que ocorre se uma pessoa digitar “1234567890” em um campo da tela, onde deveria ser
informado o nome de uma pessoa?
- Se fosse para abastecer gasolina e foi colocado etanol?
- Se alguém comer a maça estragada?
Acredito que todos responderiam: depende. Mas, com certeza, existe algo de errado nessas
situações e, em condições normais, não deveriam ocorrer para que os sistemas correspondentes
pudessem funcionar sem problemas.
10
Conforme já sabemos os sistemas “se alimentam” de entidades que entram no mesmo,
podem transformar, consumir, alterar essas entidades em trânsito e, ao final, gerar a mesma
entidade alterada, ou gerar outras entidades decorrentes do processo (figura 06).
Figura 06 - Sistema
Imagine uma fábrica que constrói cadeiras, conforme o modelo que se encontra na figura 07.
Figura 07 – Cadeira de madeira com encosto ripado.
Para que tudo possa funcionar perfeitamente no interior da fábrica (sistema), é esperado que
exista a entrada de placas de madeira de reflorestamento como o cedro, jatobá, eucalipto ou pinus.
Essas placas (figura 08) devem vir em uma espessura de 10mm, podendo ter uma variação de 1%
para mais ou para menos.
Figura 08 – Placas de Madeira
Suponha então, que o fornecedor envia placas de 4mm. Veja que o sistema (fábrica) não pode
aceitar a entrada dessa entidade. Está fora dos padrões que permitem ao sistema continuar
funcionando bem.
11
É como a maçã para o sistema digestório. Se for verificado que a superfície da maçã está
dentro de certo padrão aceitável, como uma casca vermelha, sem manchas ou buracos; entretanto,
ao cortá-la, for verificado que seu interior está preto, ela não deve ser consumida.
O mesmo ocorre também em um sistema de informação. Se na tela de cadastro de um

funcionário (figura 9) tem um campo para o CPF e, o conteúdo digitado estiver incompleto, ou for
digitado letras, o sistema não pode aceitar esse conteúdo. O mesmo se aplica a qualquer outra
situação, como por exemplo, um campo data de nascimento, onde a pessoa digite todos os números
certos; entretanto, o ano de nascimento é no futuro (ou seja, a pessoa não nasceu ainda).
Figura 9 – Tela de Cadastro de Funcionário
Veja então que os sistemas, de acordo com sua natureza, devem possuir e utilizar mecanismos
de verificação e validação das entidades que vão entrar no sistema, com objetivo de barrar, caso não
estejam dentro das especificações aceitáveis. Isso ajudará a evitar problemas no funcionamento
normal do sistema.
Portanto, os sistemas classificados como abertos, possuem uma dependência de entidades
que vem de fora deles e, que, em última análise se constituem na energia necessária para o sistema
funcionar (ou sobreviver). Em outras palavras, podemos dizer que os sistemas abertos dependem de
insumos, energia, matéria prima, componentes, etc. produzidos por outros sistemas (que se
encontram no meio ambiente).
Um sistema classificado como fechado, não depende do meio ambiente onde está inserido,
nem para importar entidades e nem para exportar. Ou seja, é absolutamente auto independente.
Cria sua própria energia e consome tudo o que produz, sem interferência e sem interferir no meio
ambiente. Baseado exclusivamente nesse conceito, não observamos ainda até o momento, um
sistema que satisfaça essa definição ao pé da letra. Muito se tem utilizado o termo “sistema fechado”
em contextos para designar ou reforçar aspectos como difícil acesso, proteção, não visibilidade, etc.
e não para a classificação de sistemas de fato.
Então a primeira grande dependência dos sistemas, encontra-se fora deles, que são as
entidades que importam para, de alguma forma, processarem.
Mas, há uma outra situação que pode interferir no bom funcionamento do sistema para que
ele possa atingir seu objetivo: a dependência entre as entidades internas (aquelas que já nascem com
o sistema).
12
Imagine que a boca não mastigue adequadamente e, envie para frente a entidade em
trânsito. Bem, pode ocorrer um mal funcionamento no sistema. Imagine que a lixa que realiza o
acabamento do assento na fábrica de cadeiras, está desgastada e, o assento não está ficando liso;
bom, isso poderá gerar um desconforto no produto que o sistema produz. O padrão das entidades
que saem do sistema, pode sofrer interferências relativas ao mal funcionamento do processo que as
geraram (perda de qualidade, defeitos, etc.).
Existe nos sistemas um processo de interdependência entre as entidades existentes. Isso se
deve ao fato de que cada um tem a sua responsabilidade perante o todo. A boca mastiga, o estomago
não. Para o estomago realizar bem sua função e, cumprir com sua responsabilidade, é pré-requisito
que seus antecessores tenham realizado corretamente suas atividades. Essa divisão do trabalho (ou
especialização das entidades) se verifica em todos os sistemas.
1.3. Eventos em Sistemas
Eventos em um sistema se caracterizam por serem ações deflagradas para o funcionamento

cotidiano, o que permite manter o estado de equilíbrio funcional.
1.3.1. Importação, alimentação, entrada ou input
Um primeiro evento já foi citado anteriormente, mas de forma superficial. Vamos detalhar
um pouco mais o evento de importação de entidades a partir do meio ambiente; fato que permite a
sobrevivência de um sistema.
Esse evento de importação, é também referenciado como ingestão, alimentação e input.
Como é sabido esse evento não existe para sistemas fechados, pois os mesmos não interagem com
seu meio ambiente.
Qualquer sistema aberto é influenciado pelo seu meio ambiente através da importação de
elementos deste meio. Quando se faz a ingestão de uma maça, diz-se que o sistema biológico está
importando, ingerindo, efetuando input, dando entrada de um elemento do meio ambiente, através
de seu subsistema digestório.
Um input, ou entrada de elementos do meio ambiente, pode ser prejudicial ao sistema. Para
se prevenirem quanto a ingestão de elementos prejudiciais, os sistemas devem ser capazes de
identificarem problemas nos elementos, antes de aceita-los. Na impossibilidade desse fato ocorrer,
por conta da escassez desse elemento (que por algum motivo pode faltar ou se tornar oneroso), o
sistema deve se adaptar a nova situação, de acordo com sua natureza.
Por exemplo, seu sistema biológico, normalmente consome carne bovina vários dias na
semana. Você se muda para o Japão. Então, as condições de aquisição de carne bovina não são tão
favoráveis e, seu sistema biológico é adaptado a aceitar outras alternativas.
13
Um elemento que é importado do meio ambiente e entra no sistema, passa a ser uma
entidade do mesmo (uma entidade em trânsito); que irá sofrer transformações ou, eventualmente
ser consumida no processo, podendo gerar algum tipo de resíduo ou produto que será enviado ao
meio ambiente.
A característica de os sistemas permitirem ou não o ingresso de certos elementos no sistema,

é genericamente conhecido como seleção de elementos. Isto é, você escolhe (seleciona de acordo
com certos padrões) a maçã, antes de comê-la.
A seleção é feita seguindo critérios previamente definidos, segundo a característica do
sistema. Veja outro exemplo: a catraca de uma escola só permite a entrada do aluno, se o mesmo
não estiver com atraso de pagamento superior a dois meses.
Para alguns sistemas, além da seleção, há outra característica importante no input de
elementos: a ordenação desses elementos. Um exemplo clássico para essa situação é o sistema de
admissão para uma faculdade, onde a pessoa externa ao sistema (elemento do meio ambiente), além
de passar pelo processo de seleção (término do segundo grau, aquisição de notas mínimas, etc.) é
também submetido a uma ordenação considerando, por exemplo a nota obtida no vestibular que,
poderá ou não determinar o seu ingresso.
1.3.2. Exportação, saída ou output
Durante o período em que os elementos provenientes do meio ambiente transitarem dentro

de um sistema, eles sofrerão mudanças, poderão dar origem a outros elementos ou simplesmente
serão consumidos.
Um aluno em trânsito pelo sistema educacional jamais sairá de lá com as mesmas

características que tinha antes de entrar; mesmo que tenha ficado no sistema por muito pouco
tempo e, sequer tenha, por exemplo, entrado em uma sala de aula. A simples presença dentro do
ambiente educacional é o suficiente para causar novas impressões, deduções e posturas. A mesma
coisa, pode ocorrer com a maçã no sistema digestório. Pode ter permanecido muito pouco tempo na
boca ou no estomago e não seguiu adiante, percorrendo todas as etapas no sistema; certamente, ela
sairá com novas características.
O ato do sistema expelir elementos ao meio ambiente é conhecido como exportação, saída
ou output de elementos.
Essas saídas de um sistema dependem de sua natureza e objetivo. Qualquer que seja a saída,
como por exemplo, materiais, componentes, resíduos, utensílios, equipamentos, etc., eles sempre
são esperados com certas características. Baseando-se nisso os demais sistemas, que se encontram
no meio ambiente, podem utilizá-los. Se um determinado produto que sai do sistema começar a
apresentar desvios das características esperadas dele, isso pode afetar seriamente o meio ambiente
e, em contrapartida ao próprio sistema gerador.
14
Por exemplo, considere uma indústria que produz álcool 70 (esse é o nome comercial). Esse
produto é uma solução aquosa de álcool. A quantidade de álcool esperado nesse caso é 77 °GL. Isso
significa que se esse produto sair do sistema com uma quantidade bem inferior ao esperado, ele estará
com problemas. Isso pode afetar o meio ambiente (outros sistemas e, indiretamente a própria indústria,
ao longo do tempo).
Um processo de produção de software, pode gerar um sistema onde exista algum defeito (Figura
10) e, esse fato pode ocorrer em qualquer outro sistema (mas é algo indesejado por todos).
Figura 10 – Ilustrações de Produtos com Defeitos
Sendo os defeitos de produtos algo não planejado, inesperado e indesejado, a pergunta é:

Porque eles ocorrem?
Diversas causas podem ser apontadas como causadoras de defeitos. Mas, a princípio, vamos
desconsiderar duas delas: erro do usuário na utilização do produto e, desgaste de algum componente
(naturalmente que o software, dado a sua natureza, não tem desgaste de componentes. Isso se
verifica no hardware.).
A ideia então é entender, porque um produto sairia de um sistema com defeito. Quais fatores
podem colaborar para que isso ocorra? Já foi anteriormente mencionado alguns cuidados que os
sistemas devem ter para a importação de elementos do meio ambiente, considerando o padrão que
precisam ter para uso do elemento no sistema. Esse pode ser um fator que, em algum momento, irá
gerar problema no funcionamento do produto.
Considere um cadastro de clientes com exemplo. Imagine que o programa não verifique se o
nome da pessoa realmente foi digitado, há uma probabilidade de que esse sistema, em algum
momento, possa apresentar algum tipo de falha em seu funcionamento, caso alguém se esqueça de
digitar esse campo e guarde os dados de um cliente, sem esse conteúdo.
Veja outro exemplo através da tela que está na figura 11. Se observa uma mensagem
informando que houve a tentativa de realização da operação de divisão, com o divisor igual a zero.
15
Figura 11 – Divisão por zero.
Essa falha do produto software foi originada por um defeito do código escrito, onde não
houve o cuidado de verificar se o divisor era um número superior a zero, antes de se realizar a
operação. Entretanto, aqui tem um aspecto interessante. Esse defeito no código poderia nunca ser
descoberto, se acaso na tela apresentada na figura 12, a quantidade de parcelas fosse sempre
preenchida com o número um ou superior. Para se evitar uma falha de execução, nesse exemplo,
basta que se verifique o número digitado no campo quantidade de parcelas, que deve ser superior a
zero. Incluído essa verificação no código, teremos certeza de que essa falha NUNCA ocorrerá aí.
Figura 12 – Valor Total e Quantidade de Parcelas
Então, no exemplo apresentado, há uma entidade dentro sistema (por exemplo o programa
que calcula o valor das parcelas), que está com defeito. Isso compromete o funcionamento do
sistema.
Assim, vemos que entidades dos sistemas que não funcionam adequadamente, ou tem algum
problema, ainda que esporádico, poderá ser a causa de gerar-se produtos defeituosos. Há a
necessidade de manutenção nessa entidade defeituosa, caso isso seja possível, ou então, sua troca.
16
1.3.3. Feedback
Evento muito utilizado para controle em sistemas. Se caracteriza por inspecionar elementos,
inspecioná-los segundo algum critério e seguir um de dois caminhos: ou está ok, ou não atende o
padrão estabelecido.
Um exemplo bastante simples, onde percebemos bem o feedback em sistemas, é o ar
condicionado (figura 13).
Figura 13 – Aparelho de Ar Condicionado

O aparelho de ar condicionado (sistema), importa elementos do meio ambiente (ar) e
compara sua temperatura com aquela definida pelo usuário. Se estiver fora do padrão, aciona uma
ação reguladora, que é continuar esfriando (ou esquentando) o ambiente. Se estiver dentro do
padrão desejado, apenas ventila.
Veja no esquema apresentado na figura 13, o procedimento de feedback realizado pelo
aparelho do ar condicionado. Em uma síntese: o Feedback é a resposta a um questionamento.
Figura 13 - Feedback
- Você entendeu o conceito de feedback?
Se sim, continue estudando a partir desse ponto. Se não, retroaja para o início desse tópico,
leia mais uma vez sem pressa, refletindo sobre o assunto e, persistindo dúvidas, entre em contato
com o professor.
Então... percebeu a intenção acima? A pergunta feita é um critério de controle a ser verificado
que irá gerar o feedback (se você entendeu ou não o conceito). Dependendo da resposta um ou
vários procedimentos são indicados.
17
Praticamente todo controle existente em sistemas de uma forma geral, é realizado através
desse mecanismo; não importa se controle de qualidade, se controle de fluxo, se controle de limites,
etc.
18
Toda organização, independentemente de seu nicho de negócio e seus fins (visando lucro, ou
beneficiente, particular, governamental ou multinacional), tem na informação um fator decisivo para
sua sobrevivência.
A informação ajuda na tomada de decisão em uma empresa. Ela reduz as incertezas de uma
ação, contribuindo com elementos para análise.
A tomada de decisão pode ser considerada um processo que envolve a seleção de um

caminho, dentre vários possíveis, a ser trilhado e a definição de um curso de ações, para se chegar a
uma solução de um dado problema que a empresa possue; ou uma estratégia que ela deseja
estabelecer.
De onde vem a informação? Hoje, invariavelmente, em sua grande maioria, é gerada pelos
sistemas de informação. A informação não é obtida apenas por conta de que a empresa virá a utilizá-
la para alguma decisão, mas é necessário atentar-se ao fato de que muitas informações devem ser
mantidas por exigências de legislação, o que significa custos financeiros e operacionais paras as
empresas. Assim, qualquer sistema que vier a ser planejado, deve levar em consideração essa
obrigatoriedade dentro da área que irá ser utilizado.
Mesmo em empresas de menor porte, hoje existe um grande volume de informações a serem
tratadas pelos sistemas. Essas informações são provenientes de diversas áreas diretas ou
indiretamente ligadas ao negócio da empresa.
É muito comum as pessoas não estabelecerem um diferencial claro entre alguns termos nas
empresas; especialmente no que ser refere a: dado, informação e conhecimento. A generalização de
um desses termos é mais usual. Entretanto, para os profissionais da Tecnologia da Informação, é
necessário ter uma definição clara sobre esses aspectos, uma vez que um sistema de informação,
pode gerar conhecimento ou informações, a partir de dados.
Com base no conhecimento ou informações obtidas nos sistemas, as organizações tomam

decisões na condução de seus negócios; portanto, é crucial que se deva também conhecer como,
genericamente, estas organizações estão estruturadas para tomada de decisão, a fim de que se possa
melhor preparar os sistemas de informação, inclusive para serem aplicados como auxiliadores nas
tomadas de decisão.
2.1. O que é dado?
Podemos considerar o dado uma unidade fundamental dos sistemas de informação. O dado
representa uma característica ou propriedade de algo, ou de alguém. Sozinho, o dado não tem
nenhum sentido.
19
Observe esse conteúdo: 11/01/2015.
O que significa 11/01/2015? Todos nós conseguimos deduzir, pelo seu formato, que se trata
de uma data. Podemos ainda deduzir que se encontra no século XXI. O mês é janeiro e o dia 11. Por
uma coincidência surpreendente, pode ser que para você ela tenha algum significado específico,
como a data do seu nascimento; mas isso não está explicito ali. Podemos ficar fazendo exercícios
fúteis de imaginação: seria a data de lançamento de algum modelo de avião, descoberta de algo,
término de um campeonato, falecimento de alguma celebridade? Ou seja, esse conteúdo sozinho
não tem significado.
Para melhorar a situação anterior, podemos criar um conjunto de dois elementos. Um
atributo e o seu conteúdo.
Vamos criar um atributo cujo nome será data de nascimento e, em seguida associar e ele um
conteúdo.
data_de_nacimento = 11/01/2015.
O que obtemos na linha acima, é o que chamamos de dado. Dado é a união de um atributo e
seu respectivo conteúdo. Veja outros exemplos de atributo (apenas): nome, cpf, email, função,
valor_total. Perceba que ainda não associamos conteúdo a esses atributos.
Olha agora o exemplo abaixo:
nome = Pedro
Você percebe que um dado sozinho, fora de um contexto, não expressa algo que traga qualquer
certeza, ou elimine dúvidas de qualquer natureza. Pedro é o nome de quem? Quem é essa pessoa (?)
que se chama Pedro? Seria pouco improvável que se desse esse nome a um cachorro; muito embora
não seja impossível. Entretanto, poderia ser o nome de um robô. Não temos como afirmar que trata-se
de uma pessoa.
O conceito de dados pode ser expresso conforme mostra a figura 14.
Figura 14 – Estrutura do Elemento de Dado
20
Os dados podem ser considerados características ou propriedades básicas de algo ou alguém
(pessoas, documentos, objetos, situações e concatenações destas coisas), cujo conteúdo deve ser
unívoco. O dado não deve comportar mais de um conteúdo para o seu atributo (figura 15).
Figura 15 – Conteúdo por Dado

Portanto, de acordo com o conceito mencionado anteriormente, seria equivocado criar um
atributo “telefone” e colocar como conteúdo dele, vários telefones. O ideal, nesse caso, seria criar
atributos diferentes para cada conteúdo: telefone_residencial, celular1, celular2, telefone_principal,
etc.
Para se possa dar sentido aos dados, devemos agrupá-los em um contexto. Então, pode-se
pegar os elementos de dados que sejam propriedades de uma mesma entidade (pessoa, objeto,
documento, situação) e, agrupá-los de maneira a formar o que é chamado de registro4 da entidade,
ou ainda, tupla5 da entidade.
DADO
ATRIBUTO VALOR OBSERVACÕES
Nome Virgulino F. da Silva Nome da Pessoa
Data Nascimento 01/03/1898 Data em que a pessoa nasceu no formato
dd/mm/aaaa
Sexo Masculino Masculino/Feminino
Naturalidade Serra Talhada Local onde a pessoa nasceu
Altura 1,70m Tamanho da pessoa em metros
Celular 9897-9899 Número do telefone celular da pessoa
Tabela 1 – Exemplo de dados de uma pessoa
A tabela 1 especifica um conjunto de atributos sobre uma pessoa. Esta tabela poderia ser
reconstruída conforme mostra a tabela 2, onde cada linha faz referência a uma pessoa, mostrando o
4
Nomenclatura utilizada para armazenamento de dados em arquivos. O conjunto de registros referente a uma mesma
entidade, forma um arquivo daquela entidade.
5
Nomenclatura empregada para armazenamento de dados utilizando-se banco de dados relacionais. A função é similar
aos do registro. Várias tuplas de uma mesma entidade constituem a tabela daquela entidade.
21
conteúdo de seus atributos. O conjunto de linhas (registros ou tuplas) formam um arquivo ou tabela
sobre pessoas.
Rg Nome Data Nascimento Sexo Naturalidade Altura Celular
14.285.258 José da Silva 21/06/2000 Masculino Lagoas 1,60 9898-7654
12.765.767 Joaquim Manoel 25/12/1959 Masculino Sussuro 1,70 9897-9899
13.767.543 Emanuela Gilter 23/01/1974 Feminino Coaltum 1,65 9192-9394
14.768.769 José da Silva 25/12/1959 Masculino Sussuro 1,60
12.987.879 Carmem Barbosa 12/04/1963 Feminino Lagoas 1,75
Tabela 2 – Registro de Pessoas
2.2. O que é Informação?
As tabelas mostradas anteriormente com registros de pessoas, podem ser convertidas em informação
através de algum mecanismo de estruturação ou de decodificação; como por exemplo, um relatório ou a
apresentação dos dados em uma tela de consulta.
Os dados reunidos passam a apresentar um significado, de tal maneira que podem ser interpretado
pelas pessoas, produz-se informação. A informação, sempre tem um contexto. Ela reduz a incerteza sobre um
determinado estado de coisas, mostra um sentido consistente sobre algo (TONSIG, 2008).
Ainda considerando a tabela de pessoas, de acordo com os atributos lá existentes, é possível

criar-se um mecanismo de estruturação (vamos supor um relatório) que pudesse nos informar, por
exemplo, quem são as pessoas aniversariantes desse mês e, em que dia fazem aniversário e, mais do
que isso, poderemos apresentar a informação em ordem crescente de dia (mas, se quem vai usar,
preferir em ordem alfabética, também é possível). E ainda, se houve alguém muito exigente e solicitar
que exista uma coluna no relatório que mostre a idade da pessoa, o relatório conseguirá fazer isso
também.
2.3. O que é conhecimento?
O conhecimento diz respeito a capacidade de resolver problemas, inovar e aprender baseado

em experiências prévias. Envolve a percepção sistematizada do que existe, o aprendizado do passado
e de experiências semelhantes, a compreensão de funcionamento e aplicação de sistemas associados
aos nossos objetivos e, finalmente, a criatividade proativa.
22
De acordo com o dicionário Aurélio, “Ato ou efeito de conhecer”, “Informação ou noção
adquiridas pelo estudo ou pela experiência”, “Prática da Vida; experiência”, “Discernimento, critério,
apreciação” ou “Consciência de si mesmo; acordo” (Ferreira, 1993).
Portanto, o conhecimento compreende a informação, mas envolve também a experiência e

depende do enfoque de quem está lidando com determinada informação.
Se retomarmos a tabela de pessoas vista anteriormente, é possível criar uma consulta ou
relatório que nos faça conhecer quem é a pessoa mais velha lá existente. Observe que isso é uma
dedução ou constatação, a partir das informações históricas lá existentes.
A história clássica que se conta para mostrar essa mineração do conhecimento, sobre uma
grande base de dados (big data ou data warehouse), é a de que, a partir do registro de vendas de
uma loja de conveniência 24 horas, foi constatado que a compra de fraudas (de neném) após as 21h
era realizada por pessoas do sexo masculino.
Veja, isso é um conhecimento. Não estava explicito nas informações geradas pelos dados.
Assim como em nossa tabela de pessoas, não está explicito quem é a mais velha. E, veja que
interessante: como não temos na tabela de pessoa a data de óbito, não temos como dizer, se dentre
aquelas cidades existe alguma em que as pessoas tenham maior longevidade.
Alguém, então, nesse ponto, pode estar pensando: para que me interessa saber isso? Se
existem pessoas de certa cidade vivem mais as que de outra? Ou que na loja de conveniência, após
as 21h são pessoas do sexo masculino que vão comprar fraldas?
No caso das lojas de conveniência, foi esse conhecimento obtido através dos sitemas de
informação que apoiou a decisão dos gestores em organizar suas gondulas com a cerveja ao lado das
fraldas, aumentando a venda das mesmas após as 21h.
Figura 16 – Cerveja ao lado de fraldas na gôndola
23
2.4. O que é qualidade da informação?
Qualidade é o grau de utilidade esperado ou adquirido de qualquer coisa, verificável através

da forma e dos elementos constitutivos do mesmo e pelo resultado do seu uso. A palavra "qualidade"
tem um conceito subjetivo que está relacionada com as percepções, necessidades e resultados em
cada indivíduo ou organização.
A qualidade da informação pressupõe a qualidade do dado, do sistema de informação e do ambiente
computacional. Todos os elementos participantes de um contexto de TI (Tecnologia da Informação) são peças
mutuamente dependentes, de onde a informação se origina. A qualidade deve estar no contexto de todos os
elos de onde se deseja obtê-la.
Um sistema de informação de qualidade pressupõe um sistema que cumpre seus objetivos, é

gerenciável, é passível de manutenção e de aprendizado por uma pessoa que não tenha feito parte
do grupo original que o projetou.
Ainda que seja um conceito subjetivo, é importante estabelecer os parâmetros de avaliação
para não gerar conflitos ou controvérsias sobre a utilidade de um sistema.
Sob a ótica de uma pessoa da tecnologia, um gráfico em pizza talvez possa ser algo que ele
julgue fazer parte do conjunto de qualidade do produto e, talvez sob a ótica do usuário, isso possa
ser irrelevante, já que gostaria de visualizar aquela mesma informação sob a ótica de relatório. É
portanto extremamente necessário o alinhamento dos sistemas com o planejamento estratégico da
empresa; tendo-se um cuidado especial com a interface (formas que as informações serão
apresentadas).
2.5. Sistemas de Informação
Os sistemas de informação são mecanismos que permitem a extração, processamento,

distribuição ou comunicação da informação a partir de um conjunto de dados.
Os sistemas de informação devem estar alinhados com as expectativas de seus usuários, no

que se refere a qualidade da informação, existência da informação necessária, facilidade de uso do
sistema, etc. O sistema de informação de uma empresa (figura 17) pode ser um diferencial
competitivo no mercado, se ele contribuir adequadamente para a gestão empresarial.
24
Figura 17 – Sistema de Informação
Os analistas de sistemas ou engenheiros de software, ao planejarem o desenvolvimento de

um novo sistema de informação, além do domínio do problema, tem que preocupar-se com as três
dimensões de sistemas de informação: organização, pessoas e tecnologia (figura 18).
Figura 18 – Dimensões de um Sistema de Informação
As três dimensões que envolvem o um sistema de informação, exigem atenção do analista ao

planejar um novo sistema e, trazem desafios:
 Disponibilidade das informações

 Tolerância a falhas
 Privacidade, Interceptação, Comunicação (Lei Geral de Proteção de Dados)
 Tempo de execução
 Espaço consumido (Big Data)
 Visualização dos dados
 Integrações (sistemas legados e ambientes heterogêneos)
25
2.6. Desenvolvimento de Sistemas de Informação
Para o processo de desenvolvimento de sistemas de informação, existem várias propostas.

Adotar uma ou não, é um critério da empresa ou pessoa que irá desenvolver.
Na figura 19 é apresentado as principais etapas para a construção de um sistema de
informação. Elas estão dispostas sequencialmente, apenas para efeito de entendimento.
Figura 19 – Etapa em processos de Desenvolvimento de Sistemas
O processo para desenvolvimento de um sistema começa quando alguém requisita um

software para resolver determinado problema ou necessidade. Pode ser que uma pessoa teve uma
ideia sobre um produto novo, que ainda não existe e, gostaria de estar desenvolvendo; como por
exemplo, um aplicativo que será um assistente pessoal para viagens de turismo espacial.
O analista de sistemas não é especialista no domínio do problema; isto é, a área para a qual
será desenvolvido o software. Sendo assim, ele necessita realizar uma “ampla e profunda”
investigação sobre o problema ou necessidade que foi apresentada. A etapa de levantamento de
requisitos é que cuida desses aspectos.
Na sequência o analista deve “pensar em uma solução”. Esse processo, chamado de análise,
pode ser realizado em etapas, cuja solução vai sendo construída progressivamente.
Quando se considera já existir uma solução adequada ao problema, cuja ideia tenha sido
validada com o cliente, a próxima etapa é desenvolver os programas (implementação). Essa etapa
compreende a codificação dos programas e alguns tipos de testes.
A etapa subsequente deve ser uma bateria de testes, preferencialmente não realizada pelos
programados.
26
Quando se considerar que o sistema está funcionando adequadamente, entra-se na fase de
implantação. Essa fase poder ser planejada para acontecer por partes; dependendo do tipo de
sistema. Normalmente um aplicativo libera-se para download e, não existe, por exemplo, um
treinamento; fato que pode ser diferente no ambiente de uma empresa.
27
Análise de sistemas é a atividade que, a partir de um problema ou necessidade, tem como
finalidade a realização de estudos de processos a fim de encontrar o melhor caminho racional para
que a informação possa ser processada com a consequente definição uma solução (projeto), para ser
implementada.
Dentre várias definições equivalentes, também encontramos: “A análise de sistemas consiste
nos métodos e técnicas de investigação e especificação da solução de problemas, a partir dos
requisitos identificados, para o planejamento e implementação de um sistema, a ser executado em
algum meio que o suporte” (TONSIG, 2008).
3.1. Características de um Analista de Sistema
O planejamento do desenvolvimento de um sistema, na maioria das vezes, envolve atividades

e áreas multidisciplinares, onde estão envolvidas pessoas com diferentes formações, diferentes
pontos de vista e diferentes interesses. O profissional que irá desenvolver as atividades da análise,
deve estar preparado para conviver nesse contexto.
Quando se fala em uma empresa pequena ou até média, de desenvolvimento de software,
normalmente não existe o “cargo de analista” ou de “engenheiro de software”. A empresa possui
apenas o que chama de “desenvolvedores”. O desenvolvedor, no caso, é uma pessoa que,
primeiramente terá que realizar as atividades da análise e, depois, será um programador. Esse fato,
em geral, se deve a necessidade que a empresa tem com uma demanda maior em programação e,
bem menos em análise. Entretanto, quando essa empresa começa a crescer, ela se organiza e verifica
a necessidade de ter um profissional exclusivamente para as tarefas da análise. Os nomes atribuídos
a esse profissional podem variar, como por exemplo: analista, engenheiro de software, analista de
negócios, consultor, etc.
Existe uma grande diferença entre atividades da análise e da programação. Para a
programação é pré-requisito alguém que tenha lógica. Para a análise, é necessária uma pessoa com
características que permitam o bom relacionamento interpessoal.
Diferentemente da atividade da programação, o analista não fica exclusivamente sentado à
frente de um computador, digitando código e testando. A principal atividade, aliás, normalmente é
realizada fora da empresa, junto ao estabelecimento do cliente e, dependendo do tamanho do
sistema a ser desenvolvido, o trabalho da análise se estende junto a alguns colaboradores do cliente.
28
Em função do contexto de atuação do analista de sistemas, pode-se estabelecer uma lista de
qualidades desejadas (figura 20); mas seria ilusório pensar que realmente haverá alguém com o
domínio igualitário de todas essas qualidades.
Figura 20 – Qualidades desejadas em um analista de sistemas.
Para um bom desempenho na função de analista, é conveniente observar algumas diretrizes

de conduta, que servirão para facilitar o trabalho:
 Sempre tentar entender o que o usuário “quer dizer” para confirmar seu entendimento
sobre o que ele disse. Use o feedback.
 Escutar muito todos os envolvidos no levantamento de requisitos.
 Estar sempre familiarizado com os últimos progressos da tecnologia da informação e
compreende como aplicá-los (ou não) na própria empresa ou na empresas de clientes.
 Buscar sempre uma forma simples para explicar conceitos ou situações complexas.
Procure exemplificar.
 Junto a usuários tente não usar termos técnicos.
 Buscar conhecer a área de negócio para a qual irá realizar o levantamento de requisitos.
Atentar-se a exigências legais. Passar uma boa parte do tempo com os usuários, ajuda
nesse aspecto.
 Sugerir soluções inovadoras viáveis, com apresentação do custo / benefício envolvido.
3.2. Levantamento de Requisitos
Atualmente, o levantamento de requisitos continua sendo um dos principais fatores que

causam problemas em projetos de software. Quer seja pela superficialidade com que tem sido
29
realizado, pelo pouco contato e comunicação com todos os envolvidos ou entendimento errado
sobre o que deve ser feito.
Mas, o que é um requisito de software?
Vamos observar a seguir alguns comentários, que criam um contexto para entendermos o
significado de requisito de software.
 Requisito de software é um recurso necessário ao sistema que será feito e, tem por
objetivo, cuidar de uma tarefa específica dentro do sistema.
 Um sistema de informação é formado por vários requisitos de software.
 Requisito de software é uma funcionalidade, que o sistema deverá ter quando pronto.
 Sem todos os requisitos necessários para a solução de um dado problema, o sistema não
funcionará.
 Uma especificação de requisito de software é uma descrição de um elemento, uma opção
que deverá existir no sistema a ser desenvolvido.
Antes de falarmos no software, vamos colocar a seguinte afirmação: A boca é um requisito

para o sistema digestório funcionar. A boca, portanto, não é o sistema. É parte dele. É um elemento
que o compõe. Ela tem uma função específica para ajudar a solucionar o problema que o sistema
deve resolver (digestão). Sem ela, o sistema não funciona.
Pois bem, vamos trocar o sistema digestório por um sistema de controle de vendas de uma
loja. Nesse sistema, o cadastro de produtos é um requisito de software. O cadastro de produtos não
é o sistema. É parte dele. É um elemento que o compõe. Existem diversos outros elementos nesse
sistema, cada um deles é um requisito de software, como por exemplo: cadastro de clientes, relatório
dos produtos existentes, registro da venda, emissão do documento fiscal, etc.
Observe, portanto, que estamos focando a funcionalidade do sistema. O que ele precisa ter
para funcionar. No exemplo do sistema de controle de vendas, para que se possa vender produto, é
necessário antes, ter os dados do mesmo. Logo, é necessário criar um recurso para cadastrar esses
produtos. Essa é a linha de raciocínio que deve ser estabelecida para verificação dos requisitos que
envolvem a solução do problema.
As descrições das funções e restrições são os requisitos para os sistemas; e o processo que
envolve a descoberta dos requisitos, sua análise e documentação é a chamada análise de requisitos
ou engenharia de requisitos (SOMMERVILLE, 2011).
“Popularmente”, a análise de requisitos ou engenharia de requisitos é referenciada como
“Levantamento de Requisitos” ou ainda (de uma forma errônea) “Levantamento de dados”.
Segundo o glossário de terminologia para engenharia de software do IEEE (1990)6, a análise

de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar
uma definição correta ou completa para o sistema que será desenvolvido.
6
Pode ser acessado em: https://ieeexplore.ieee.org/document/159342
30
Essa fase é de grande importância, por conta de que os analistas são pessoas da área de
tecnologia da informação e, não especificamente, da área para a qual irão criar um sistema. É através
desse processo que o analista passa a conhecer as funções, integrações e restrições do negócio.
Já imaginou se alguém chegar para você e disser assim:
- Preciso que você desenvolva para mim um sistema de controle da cria, recria e engorda de
jacarés.
Pois bem, o que você faria? Provavelmente você não especialização em Biologia, ou não tem
pós-graduação na área de répteis. Portanto, o processo pelo qual ocorre a descoberta das
funcionalidades para a criação de um sistema de informação, em um domínio de problema (área), é
através do levantamento de requisitos.
3.2.1. Classificação de Requisitos
Os requisitos que definem as funcionalidades que deverão existir no sistema que será
construído, são classificados como requisitos diretos ou funcionais.
Supondo-se um sistema de controle de vendas de uma loja, um exemplo de requisito

funcional é o cadastro de produtos. Também seriam requisitos funcionais: o cadastro de clientes, o
registro a venda, a emissão dos documentos fiscais, etc.
Veja que esses recursos são “funções”, “programas”, “opções” do sistema que deverão ser
construídos pela equipe de desenvolvedores, tendo eles total domínio sobre esses recursos.
Agora considere duas afirmativas hipotéticas de dois usuários:
- Esse sistema vai precisar também de um antivírus – comenta o primeiro usuário.
- Sim, isso é importante. Mas ele também vai precisar de um backup7 – disse o segundo
usuário.
Então, esses dois recursos que os usuários informaram ser necessários, são requisitos diretos?
Ou seja, eles existem por causa do sistema de controle de vendas que está sendo planejado? A
resposta é não. Qualquer sistema precisa de um backup. E o antivírus é para resguardar qualquer
coisa instalada na máquina e, não apenas um sistema.
Portanto, o antivírus e o backup realmente são necessários; porém, são chamados de
requisitos indiretos ou não funcionais. Não existirão por uma exigência funcional de um sistema
específico, mas por um critério geral de segurança.
Além disso requisitos funcionais, como uma simples consulta via web, pode ser tornar um
requisito indireto se houver uma exigência, por exemplo, de que o usuário tenha a resposta dessa
consulta em até dois segundos. E, porque ele se torna indireto a partir dessa exigência de tempo de
7
Cópia de segurança de todo o sistema, dados e demais componentes; para que, em caso de falha ou perda do hardware,
os dados não sejam perdidos também. Atualmente, as cópias de segurança têm sido realizadas em nuvem.
31
resposta na web? Isso se deve pelo fato de que o tempo que a resposta vai chegar até o destino, não
depende diretamente do software que será construído, mas de outros fatores de infraestrutura
alheios à responsabilidade do sistema em questão.
3.2.2. Como realizar o levantamento de requisitos
Quando um cliente solicitar seu serviço ou a empresa designar você para realizar essa
atividade, inicialmente há três aspectos que você deve se preocupar:
 O que deve ser feito? (Qual é o problema? Qual é a necessidade?)

 Porque deve ser feito?
 Quem está envolvido com os processos?
Por certo que, em um primeiro contato, as informações que irá coletar serão genéricas.
Normalmente o cliente vai expor em linhas gerais o que ele deseja fazer. Como por exemplo:
- Preciso controlar todas as informações da cria, recria e engorda de jacarés na minha fazenda.
Acima, foi colocado como exemplo uma área de negócio que, muito provavelmente, é
conhecida por poucos (isso foi proposital). Mas, aconteceria da mesma forma com qualquer outra
área, ou seja, será exposto genericamente o assunto. Veja outros exemplos: preciso de um e-
commerce para minha loja, tenho que controlar o faturamento da minha oficina de veículos, preciso
de um aplicativo na minha lanchonete, etc.
Observe que no máximo, o que descobriremos a partir dos exemplos citados, é praticamente
a área (domínio do problema) para a qual deverá ser criado o sistema. Mas está muito longe daquilo
que realmente precisamos saber.
Voltando ao exemplo referente a “cria, recria e engorda de jacarés” (figura 21), a questão é:
o que, exatamente, se deseja controlar?
Figura 21 - Jacarés
O analista deve conduzir o processo de conhecimento sobre o domínio do problema,
estabelecendo inicialmente qual é a necessidade real do usuário, com relação ao sistema que ele
venha a pedir.
32
Veja que no caso da criação de jacarés8 é muito amplo o escopo do projeto. O analista deve
questionar sobre o início e fim esperado para esse sistema. Pode ser que o cliente tenha se
expressado de uma forma que daria a entender que ele desejasse controlar tudo; mas,
eventualmente, não é isso que estava pensando. De qualquer forma é importante estabelecer a
delimitação das atividades que o sistema irá ter.
O analista deve questionar vários aspectos iniciais para dimensionar as linhas fronteiriças do
sistema:
- O controle desejado vai começar quando se compra o jacaré? Como ocorre esse
procedimento hoje? Ou não é comprado o jacaré e sim os ovos?
- O abate do jacaré será controlado também? Ou isso é terceirizado?
- Será controlado o faturamento da carne, ou do couro também?
Veja que no mínimo essas três questões já irão esclarecer muitos aspectos. Mas com certeza
não serão ainda o suficiente. Poderão aumentar as dúvidas sobre a linha fronteiriça que o sistema
deve alcançar. Então o analista deve ir explorando esse aspecto para identificar onde começará e
onde terminará o sistema e, depois de entender a abrangência, aí sim, em diversos outros
levantamentos vai se aprofundar, etapa por etapa, sobre os requisitos necessários.
Há situações em que o analista deverá conversar com os colaboradores do cliente para

entender como determinado processo é feito. Tanto quanto possível a observação in loco é
altamente recomendada.
Imagine se, nessa criação de jacarés, o dono do negócio informar a você que o sistema deverá
controlar o percentual de nascimento do gênero do jacaré. Ou seja, para cada 100 ovos, o dono do
negócio deseja que nasçam 80 jacarés do sexo feminino e 20 do sexo masculino. Você, como analista
de sistemas, o que faria?
E, depois de resolver o problema acima, você ainda teria que questionar: o que será feito com
os “jacarezinhos”? O sistema terá que catalogar todos eles? Como isso poderá ser feito? O sistema
terá que guardar a informação sobre a localização de um jacaré? O que eles comem? O sistema terá
que controlar o estoque da comida deles? E, assim vai. O analista deve ser curioso nesse sentido;
para explorar exaustivamente cada aspecto do negócio. Só assim, o sistema tem uma chance de
começar de forma adequada.
Claro que estamos utilizando aqui um exemplo de nicho de negócio pouco conhecido. Mas os
mesmos questionamentos devem ser aplicados para qualquer sistema que venham fazer,
especialmente aqueles que o analista “acha que já sabe” sobre o assunto, pelo fato de já ter criado
muitos sistemas para determina área. Fuja dessa armadilha. Mesmo que já tenha passado os últimos
8
Para essa atividade é necessária a autorização do IBAMA no Brasil. A Portaria 126/1990 deu o
suporte legal a esse tipo de manejo, regulamentando a implantação de criadouros comerciais.
33
40 anos fazendo sistemas para a contabilidade, se um escritório contábil vier lhe pedir um sistema,
antes de tudo, faça o levantamento de requisitos.
3.2.3. Técnicas para o levantamento de requisitos
Na maioria dos casos o levantamento de requisitos é realizado com um bate-papo informal,

digamos uma reunião. Quanto menor a empresa, maior a informalidade (pode haver exceções). De
qualquer forma, as técnicas mais utilizadas estão expostas a seguir.
O levantamento de requisitos deve envolver as atividades de todos os stakeholders9.
Existem técnicas que não são frequentemente empregadas e possuem objetivos específicos,
como a utilização de formulários de pesquisa e reuniões de brainstorming10, as quais não serão
tratadas nesse material.
3.2.3.1. Reuniões / Entrevistas
Uma reunião é bastante comum em diversas empresas. As vezes elas são previamente
agendadas e comunicadas aos convocados, com pauta sobre aquilo que será tratado, horário de
início e fim, definição de local e lista dos participantes. Em empresas menores, essa formalidade
normalmente não ocorre.
Não há uma distinção muito clara sobre uma reunião e uma entrevista. Mas, em geral, a
reunião é provocada para elucidar situações problemáticas, definir estratégias ou realizar algum tipo
de comunicação. A entrevista já tem o foco um pouco diferenciado, onde o analista convoca as
pessoas necessárias para poder realizar o levantamento de requisitos, cruzar informações ou eliminar
contradições. Mas, em suma, normalmente termo reunião acaba sendo utilizado para tudo.
Para que se tenha uma reunião ou entrevista eficaz, alguns cuidados são necessários:
 Ter clareza de sua finalidade (para que, exatamente, servirá a reunião?)

 Identifique as palavras-chave (que servem para conduzir a reunião e, não haver desvio do
foco.)
 Quem deve participar?
Uma reunião bem conduzida tem três partes: abertura, o núcleo e a conclusão. Na abertura
se procura estabelecer uma atmosfera amigável, informando sobre o objetivo. O núcleo é a reunião
9
Qualquer pessoa, departamento, setor envolvido direta ou indiretamente com o sistema que será desenvolvido.
10
O brainstorming ou tempestade de ideias, mais que uma técnica de dinâmica de grupo, é uma atividade desenvolvida
para explorar a potencialidade criativa de um indivíduo ou de um grupo.
34
propriamente dita, onde alguns cuidados devem ser observados: mantenha o foco, certifique-se que
está entendendo à medida em que as pessoas falam sobre o assunto abordado, faça as anotações
que julga necessárias (mas seja breve, anote palavras-chave), lembre-se que você está em busca de
informações e as pessoas ali são as que estão envolvidas com os processos. Na conclusão, procure
manter a atmosfera agradável de início, esteja atento ao horário para evitar qualquer transtorno aos
envolvidos e, agradeça a colaboração deles.
3.2.3.2. Observação in loco
Essa atividade compreende ir até o ambiente de trabalho dos usuários, para que possa
observar as atividades que, de alguma forma estejam envolvidas com o sistema que será planejado,
para que possa entender os processos, eliminar dúvidas sobre alguma questão, examinar situações
decorrentes de informações contraditórias ou incompletas, acompanhar como é realizado a parte
operacional de determinado processo.
A observação in loco ajuda também no dimensionamento e escolha de tecnologias, ou ainda,
na eliminação de determinadas possibilidades. Por exemplo, considere um sistema de coleta de
dados sobre o gasto de água, em tempo real, para um aplicativo de gestão de plantação de horta;
onde a observação in loco pode vir a constatar a ausência de sinal wifi para uma situação que havia
sido pensada e, que então, terá que ser revista. Ou, quem sabe, constatar que jacarés não tem orelha
externa e, então, não poderão ser identificados com um brinco nela, como os bovinos. Mais ainda,
talvez concluam que seja desinteressante colocar o brinco no focinho, também.
Como percebe, nem sempre é necessário fazer uso da observação in loco. Mas realmente ela
ajuda muito em diversas situações onde o ambiente deve ser inspecionado. Mesmo que não exista
uma situação com aparente dúvidas que exija realizar alguma inspeção, uma olhada no ambiente de
trabalho e lugares onde o sistema será utilizado, é uma atividade recomendada.
35
4.1. Origem
A orientação a objetos fundamenta-se em princípios que não são novos, emprega um modelo
que já era aplicado nas linguagens de programação. Os conceitos foram adaptados para uso no
processo da análise de sistemas.
A bibliografia nos apresenta, aproximadamente o início dos anos 90, como sendo o momento
em que o modelo orientado a objetos começou a ocupar um lugar de destaque, no desenvolvimento
de software. Três aspectos foram relevantes para a ascensão da orientação a objetos, contrapondo-
se aos métodos estruturados: a unificação de conceitos entre as fases de análise e programação, o
grande potencial de reutilização do software e a facilidade de manutenção. A orientação a objetos
também se apresentou com a esperança de suprir algumas das preocupações da indústria do
software: a necessidade de criar softwares corporativos muito mais rapidamente, mais confiáveis e
a um custo baixo. Os meios para se conseguir esta proeza se encontram nas características
apresentadas pelo paradigma da orientação a objetos, o que leva a um salto quantitativo e qualitativo
na produção do software (TONSIG, 2008).
O paradigma11 da orientação a objetos12, foi aplicado inicialmente nas linguagens de

programação de computadores no final dos anos sessenta, com a linguagem SIMULA. Na análise de
sistemas as primeiras propostas sugiram no início dos anos 90.
4.2. Objeto, Classes, Atributos e Métodos
Um neném se dirige até um chocalho. Intuitivamente, ele leva até a boca, em um momento
inicial (figura 22).
Figura 22 – Neném com chocalho
11
Paradigma, segundo o dicionário Aurélio significa modelo, padrão. Um modelo é uma abstração de alguma coisa, cujo
propósito é permitir que se conheça essa coisa antes de se construi-la. Um modelo é uma simplificação da realidade.
12
Objeto é a representação abstrata de coisas do mundo real, que sob o ponto de vista do nosso problema, possuem
atributos e métodos comuns.
36
Com o passar do tempo, depois de várias tentativas de uso, batendo na cabeça, tentando
colocar no ouvido, etc. o neném já um pouco maior, percebe que, se enviar ao objeto uma mensagem
(chacoalhar), o objeto “responde” com um barulho. Dependendo do tipo de mensagem (tipo de
chacoalhada), o objeto “responde” com barulhos diferentes.
Em face a essa cena, alguns pesquisadores afirmam que para nós, deve ser mais fácil a lógica
orientada a objetos do que a lógica estruturada.
4.2.1. O que é um objeto?
Já temos intuitivamente um conceito formado de objeto. Em nosso cotidiano estamos

cercados de objetos e, nos parece muito natural classificá-los a partir de vários pontos de vista:
forma, utilidade, etc. Cada objeto tem características segundo sua estrutura e funcionalidade.
Ao examinar mais cuidadosamente determinado ambiente, verifica-se que existem objetos
que são semelhantes. Uma caneta azul é muito semelhante a uma caneta vermelha, ambas também
têm alguma semelhança com lápis, dado as características de formato, tamanho e função (escrever).
Nossa capacidade de pensar abstratamente nos permite separar objetos semelhantes,
segundo algumas características e atribuir um nome genérico a este conjunto. Por exemplo: um avião
monomotor, uma aeronave de carga, uma aeronave a jato; todos eles poderiam ser classificados em
um conjunto chamado Avião. Ou seja, Avião é uma abstração13 da realidade – trata-se de uma
generalização de um aspecto da realidade, sob a ótica de quem a observa.
Figura 23 – Objetos do tipo avião
É perceptível que os aviões são diferentes. A generalização deu-se em função dos interesses
do observador, que assim os classificou porque percebeu que eles possuem atributos comuns que
são o foco de interesse no momento: quantidade de assentos, modelo, comprimento, largura, etc.
Veja que os atributos mencionados, todos esses aviões possuem.
13
Princípio de observação de aspectos relevantes para um propósito, sob a perspectiva do observador.
37
Ué..., mas porque esses atributos e não outros. Por enquanto vamos imaginar que esse
observador tem um interesse nesses atributos, porque vai desenvolver um sistema de controle de
limpeza interna dos aviões. Assim como uma escola teria interesse nos atributos cpf, nome,
endereço, celular do João, da Maria, do André da Bruna, etc. e os classificaria em um conjunto
chamado de “Alunos”. Mas porque não incluiu o atributo “cor dos olhos” já que todos os alunos
possuem? Porque esse atributo não é de interesse do sistema que irá usar “Alunos”.
Ou seja, qualquer uma dessas pessoas, possuem os atributos mencionados e perante o
sistema são classificados como “Alunos” e, essas pessoas, também podem ter ações (métodos)
comuns tais como realizar cadastro, realizar matricula, realizar pagamento, etc.
Então, a exemplo de aviões essas pessoas também passaram por um processo de
generalização, onde, baseando-se em objetos existentes do mundo real, criou-se uma única
representação para eles.
Portanto, no modelo orientado a objetos, o termo “Objeto” é a representação de elementos

físicos do mundo real (ou imaginário), que, sob ponto de vista do problema a ser resolvido, possuem
atributos e métodos comuns. Atente ao fato de que, uma personagem criada para um game, pode
ser um objeto (do mundo imaginado), que também poderá ter atributos e métodos.
Perceba que existe uma sutileza na definição de objetos. Ela permite que um mesmo objeto
seja classificado sob pontos de vistas diferentes, dependendo do objetivo do sistema.
Figura 24 – Ovelha
O exercício mental que as duas senhoras na figura 24 estão fazendo é o de abstração14, ao

olhar para a ovelha (uma mesma realidade) e criar a imagem de acordo com um propósito.
Da mesma forma o analista de sistema terá que “interpretar” a realidade de acordo com o
propósito do sistema que irá fazer e, deduzir quais são os objetos e quais são suas características, ou
propriedades, que devem ser consideradas.
14
Operação intelectual em que um objeto de reflexão é isolado de fatores que comumente lhe estão relacionados na
realidade.
38
Figura 25 – Jogador de Futebol
O Vitor é um jogador de futebol amador (figura 25). Em suas atividades profissionais Vitor é
médico e professor. O Vitor é uma dessas pessoas que possui muitos clientes (pacientes e alunos).
Talvez até possa ter público também, quando vai jogar bola. Trata-se de um grande contribuinte de
impostos para o país, estado e município. Recentemente o Vitor ficou estressado, tornando-se
também um paciente.
Perceba que, dependendo do ponto de vista, a classificação que podemos fazer do Vitor, em
função de sistemas de informação, muda totalmente. Isso se reflete nos atributos que teremos que
eleger.
Sob a ótica do sistema de informação que controla o campeonato de futebol da cidade (onde
o Vitor participa), ele será um objeto jogador. E, talvez, um dos atributos que o analista vai definir
sob esse ponto de vista, seja a posição (qual posição o Vitor joga?). Esse atributo, talvez seja inútil
aos outros sistemas onde o mesmo Vitor também está inserido.
Para que a definição de objeto fique mais clara, serão apresentados grupos de objetos a
seguir, com vários comentários que ajudarão a entender as premissas de seu uso em sistemas de
informação.
Figura 26 – Objetos do tipo caneta
39
Na figura 26 podemos observar vários tipos de canetas. Sob a ótica de um sistema de
informação qualquer (sistema de venda de produtos, ou sistema de industrialização, ou sistema de
controle de coleção de canetas, etc.), uma caneta é um objeto. Isso porque uma caneta tem atributos
(características ou propriedades) e métodos (o sistema de informação pode fazer algumas operações
com caneta) e, além disso, uma caneta é identificável. Apesar de ser “igual” a outra, uma caneta é
única. Assim como é possível ter dois alunos (irmãos gêmeos inclusive), mas cada um tem seu RA
(Registro de Aluno), cada caneta pode ter seu próprio código. Objetos devem ser identificáveis.
Esses conceitos que estamos vendo para caneta, você deve estendê-los a qualquer objeto que
conheça.
Como deve ser atribuído o nome ao conjunto de canetas? Há uma discussão sobre se o nome
deve ser no plural ou singular. Devemos seguir a convenção15 de escrita adotada pelo mercado, por
isso utilizaremos sempre no singular.
4.2.2. O que é uma Classe?
Pois bem, aqui entra um novo conceito. Esse nome atribuído a generalização de objetos de
um mesmo tipo, é chamado de classe. Portanto, uma classe representa objetos de um mesmo tipo,
que possuem atributos e métodos comuns.
Diz-se que o objeto é a instância de uma classe. Ou seja, o objeto em sistema de informação
é gerado a partir da especificação de uma classe.
Voltando a questão de como deve ser o nome que será atribuído para a classe, destaca-se
inicialmente, embora pareça óbvio, é que o nome deve ser autoexplicativo. Se vou criar uma classe
para canetas, não vou atribuir o nome de “abobrinha” e, nem ter preguiça escrevendo apenas “can”
(como sendo uma suposta “abreviação” para ser mais rápido).
Os nomes das classes devem ser substantivos, com a primeira letra em maiúsculo e as demais
em minúsculo; com exceção, se usar palavras concatenadas, a primeira letra da segunda palavra
também deve ser em maiúsculo. Não deve ser utilizado palavras acentuadas ou caracteres especiais.
Trocar “ç” por “c”. Seguem alguns exemplos:
 Venda
 VendaItem
 Aluno
 Produto
 ProdutoEstoque
15
Para saber mais: https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html
40
Tenta criar nomes simples e auto sugestivos. Use palavras inteiras, evite siglas e abreviações
(a menos que a abreviação seja muito mais usada e de fácil compreensão).
Então, considerando um conjunto de canetas, o nome da classe que será atribuído a elas
deverá ser: Caneta. Isso se realmente o foco de interesse do analista for apenas caneta. Veja que, se
estivéssemos em uma papelaria, haveriam outros produtos a serem controlados. Então, talvez
pudéssemos generalizar ainda mais a ideia e criar uma classe chamada: Produto. Mas, por ora, vamos
considerar a classe “Caneta”.
4.2.3. Atributos
Depois da definição do nome da classe, o analista vai focar os atributos (lembrando que
atributo é uma característica ou propriedade do objeto). Objetos podem possuir vários atributos.
Quais deles são de interesse para o sistema que será construído? Essa é a grande questão para que
o analista possa estabelecer uma lista dos atributos necessários e, ignorar os que não são relevantes.
Vamos supor que se esteja planejando um sistema de controle de vendas. Quais seriam os
atributos essenciais para o sistema de venda, no que diz respeito a uma caneta? Isso deve ser
identificado pelo analista para que possa definir os atributos que serão considerados.
Vamos destacar um atributo inicialmente: a cor. A cor é importante e necessária para um
sistema de vendas desse produto? Acredito que a resposta unanime seja sim. Ah, que ótimo. Já
descobrimos um atributo necessário para a caneta.
Mas, pera aí. A cor do que exatamente? Com alguma certeza, talvez todos tenham pensado
na “cor da tinta”, é óbvio... Talvez possa ser óbvio, mas faltou precisão no nome do atributo. O
analista de sistema deve ser claro e exato em suas especificações. Se estamos falando da cor da tinta
e não da cor da tampinha da caneta, ou da cor de seu invólucro, que pode ser de metal na cor
prateado, temos que deixar isso claro.
Percebam então que definir ou não determinado atributo dependerá de sua relevância de
uso para o sistema que será criado.
A seguir, na tabela 3, uma possível relação de atributos para “Caneta” que, eventualmente
um analista iria estabelecer em um primeiro momento.
Caneta (nome da classe)
codigoIdentificacao
descricao
corTinta
marca
tipoPonta
tamanhoCaneta
Tabela 3 – Nomes de atributos
41
Por convenção os nomes dos atributos começam sempre com a primeira letra em minúsculo
e, se houver concatenação (junção) com outra palavra a primeira letrada da segunda palavra deve
estar em maiúsculo, as demais em minúsculo. Não deve possuir caracteres com acento ou caracteres
especiais.
Veja que a lista de atributos da tabela 3 estão todos os atributos descobertos, digamos, de
uma forma visual. Será que somente esses atributos são o suficiente para serem utilizado em um
sistema de controle de vendas? O que você acha?
Quando você precisa comprar uma caneta, o que pergunta para o vendedor, ou o que procura
no site onde está comprando?
Com certeza deve ter se lembrado do preço de venda, certo? Talvez tenha se lembrado
também da necessidade de se saber a quantidade disponível em estoque. Então, o analista teria que
acrescentar esses dois novos atributos na lista.
Talvez ainda, fazendo uma observação in loco, onde esse produto é armazenado ou
manuseado para venda, descubra também que ele possui um código de barras, que precisa estar na
lista de atributos necessários.
Isso é tudo? Talvez não. O stakeholder gerente da loja precisa saber a data da última compra
desse produto e, também, a data da última venda. Perceba que, algumas coisas só serão descobertas
se for conversado com todos os envolvidos no processo (nesse exemplo, não só o vendedor ou
cliente).
4.2.4. Métodos
Os objetos não possuem apenas atributos na classe que os representa, também podem ter
uma lista de métodos.
O método é uma função, rotina, ação que um objeto da classe pode executar.
Os métodos são pensados em termos daquilo que o sistema poderá fazer com o objeto. A
execução, ou realização de determinado método, é um procedimento de responsabilidade do objeto.
Quando o objeto tiver que realizar algumas dessas ações, ele receberá uma mensagem solicitando
que faça.
Assim, as vezes o analista, faz um questionamento do tipo: o que se pode fazer com a caneta?
No sentido “daquilo que o sistema” pode fazer com a caneta. Não é incomum ouvir a resposta:
escrever. Ou seja, o sistema não vai escrever com a caneta. Ele realiza outras atividades, com os
dados e representação da caneta.
O que o sistema pode fazer com uma caneta é: cadastrar, consultar, excluir, vender, comprar,
e reservar canetas. Fica observado que nosso foco é sobre sistemas de informação e não sobre
robótica (considerando o fato de que um robô poderia escrever com a caneta).
42
Os sistemas de informação trabalham essencialmente com dados, a partir da definição de
seus atributos, os quais representam um objeto.
Assim, talvez uma classe Caneta, pudesse ser escrito conforme vemos a seguir.
Caneta
Atributos:
codigoIdentificacao
descricao
corTinta
marca
tipoPonta
codigoBarras
valorVenda
dataUltimaCompra
dataUltimaVenda
tamanhoCaneta
Métodos:
gravar()
alterar()
consultar()
excluir()
reservar()
comprar()
imprimir()
Tabela 4 – Classe Caneta
Observe que o nome dos métodos sempre devem ser verbos no infinitivo, isto porque são
ações que serão executadas. O nome está seguido de um abre e fecha parênteses, visto que os
métodos serão funções nas linguagens de programação e, em geral, possuem essa notação para
recebimento, ou não, de parâmetros. Mas não se preocupe agora com a questão das linguagens, elas
serão tratadas no seu devido tempo, junto ao professor da disciplina.
Outro detalhe que está relacionado aos atributos diz respeito ao que é chamado “tipo de
dado”. Por exemplo, o nome de uma pessoa contém caracteres alfabéticos (não possui, por exemplo
números ordinais). De qualquer forma, podemos classificar o nome como sento do tipo de dados
alfanumérico (que permite aceitar letras e números). Já o valor de uma caneta, é um tipo de dado
numérico. Em ambos os casos o nome e o valor, deverão ter um tamanho máximo.
Por exemplo, seria razoável dizer que um nome terá no máximo 60 caracteres de tamanho.
No caso do valor unitário de venda de uma caneta, talvez fosse razoável prever um tamanho máximo
de seis inteiros e duas decimais. Essa questão será vista em maior profundidade com a disciplina de
banco de dados; entretanto, deve-se lembrar que estabelecer esses limites é um trabalho da análise
43
e, não da programação. A importância de se estabelecer tais limites é para efeito do armazenamento
desses dados e também o dimensionamento da interface (campo na tela onde serão digitados esses
dados).
44
4.3. Herança entre classes
Na orientação a objetos, a herança é um princípio através do qual uma classe compartilha

com outras todas suas especificações; isto é, atributo e métodos.
As classes que “recebem a herança”, são chamadas de subclasses ou classes filhas.
A intenção de uso da herança é para o reaproveitamento do código, estabelecendo um

comportamento generalizado, que é herdado pelas classes filhas, as quais acrescentam suas próprias
características.
Figura 27 – Herança
Na figura 27 existe uma classe com nome “Animal”. É uma definição bem genérica que possui
três atributos, o código, tamanho, cor e, dois métodos: gravar e consultar.
Abaixo da classe Animal existe o desenho de um pequeno triângulo, cuja ponta está encostada
na classe e, na base do triângulo é aberto dois segmentos de retas, cada um seguindo para um lado,
à esquerda a classe “Cavalo” e, no lado direito a classe “Leao”.
A presença do triângulo, indica que existe uma herança. Isto é, “Cavalo” e “Leao”, são
subclasses e, portanto, herdam todas as características da classe “Animal”. Isso significa que “Cavalo”
tem código, tamanho e cor, assim como “Leao” e, ambos, possuem os métodos gravar e consultar.
Isso tudo; portanto, herdado da classe mãe.
A classe “Cavalo” acrescenta dois outros atributos aos já herdados: raça e peso que consegue
carregar. Na classe “Leao”, vamos encontrar a mesma situação; onde, além das características
herdadas de animal é acrescentado: tamanho da juba e volume de carne diária para sua alimentação.
Portanto, “tamanho da juba”, não é atributo de Cavalo e nem da classe Animal. É específico
da classe “Leao”.
No diagrama mostrado na figura 27, pode ser feito uma leitura a partir das subclasses, da
seguinte forma: “Cavalo” é um tipo de “Animal”. “Leao” é um tipo de “Animal”. Essa leitura sugerida
pode parecer estranha; mas é crucial para saber se a herança foi aplicada de forma acertiva.
45
Não teria sentido um esquema como o mostrado na figura 28.
Figura 28 – Login herdando características de Pessoa

Por conta desse tipo de mapeamento a leitura da subclasse para a classe mãe é importante.
No diagrama da figura 28, a leitura seria: “Login” é um tipo de “Pessoa”. Fato absurdo. Isso está
errado. “Login” não é um tipo de pessoa. Essa situação deve ser revista. Poderíamos ter até alguém
contra argumentando; mas meu “Login”, será uma classe, porque irá possuir atributos e métodos.
Ok, sem problema. Mas “Login” não é um tipo de pessoa; logo, essa herança está errada.
Você verá no próximo módulo que as classes podem estar relacionadas de outras formas,
além da herança. Então, poderíamos sim ter um relacionamento entre “Pessoa” e “Login”, mas esse
relacionamento não seria de herança. Isso será abordado no próximo módulo.
4.3.1. Sobrecarga do método
Uma subclasse, como vimos, herda tudo de sua classe mãe.

Há situações, que um determinado método herdado tenha que se comportar de forma
diferente na subclasse. Para que isso possa ocorrer é necessário reescrever o método na classe filha.
Essa situação é chamada de sobrecarga do método ou ainda sobrescrita do método.
Nos exemplos anteriores, vimos uma subclasse “Leao” herdando tudo de sua classe mãe
“Animal”. Foi herdado um método consultar(). Como esse método está na classe mãe,
originariamente, ele mostra todos atributos que se encontram naquela classe. Mas, ao consultar um
“Leao”, se deseja acrescentar no resultado da consulta o dado relativo ao tamanho da juba. Dessa
forma a método consultar, teria que ser reescrito e incluído na classe “Leao”. Se houver na classe
filha um método de mesmo nome de um dos herdados, o método da classe filha prevalecerá para
execução.
46
4.4. Encapsulamento
Na figura 29 temos várias capsulas de remédio. Nenhum de nós, olhando do lado de fora da
capsula, conseguirá dizer, o que é que tem lá dentro. Será que temos um pó amarelado? Ou branco?
Ou são cristais muito pequenos? Não temos como afirmar apenas olhando a parte externa.
Figura 29 – Cápsulas
Na orientação a objetos, o conceito de encapsulamento faz referência a ocultação ou

“empacotamento” de dados e procedimentos dentro de um objeto. Não há dados ou procedimentos
fora de um objeto. Por padrão, o acesso a um dado só é permitido aos métodos existentes no objeto
onde o dado se encontra. Ou seja, a visibilidade desse dado não é permitida para quem está fora do
objeto.
Vamos imaginar uma situação hipotética onde a classe “Venda” precisa do nome do cliente,
para poder listar o recibo de venda. Entretanto, em função do encapsulamento, o nome do cliente
(que encontra-se na classe “Cliente”), não está acessível e, “Venda” não tem como acessá-lo
diretamente. Assim, para que “Venda” possa conseguir obter o nome do cliente, deverá enviar uma
mensagem ao objeto do tipo “Cliente”, solicitando o nome.
Figura 30 – Classes Venda e Cliente
Na figura 30 há uma ilustração demonstrando que o método emitirRecibo() da classe “Venda”,

envia uma mensagem consultarDados(cpf) e recebe como retorno o objeto do tipo Cliente,
correspondente ao cpf informado.
47
Esse processo de comunicação entre objetos é o responsável pela dinâmica de funcionamento
em um sistema orientado a objetos. Esse funcionamento será mais detalhado, na prática, quando ver
as disciplinas de programação orientada a objetos.
Um aspecto importante do encapsulamento é que as mudanças no conteúdo dos atributos

(dados) só devem ser realizadas pelos métodos da própria classe, para garantir que ela mantenha o
estado do objeto consistente.
Veja na figura 31, a criação de uma classe em uma linguagem de programação hipotética
qualquer, a partir do diagrama da análise.
Figura 31 – Classe em uma linguagem de programação
Vamos supor agora, sem o uso de encapsulamento, uma operação (desastrosa), utilizando a
classe que se encontra na figura 31.
Figura 31 – Utilizando a classe Conta
No trecho de código de uma linguagem hipotética na figura 31, o atributo saldo está sendo
alterado diretamente pelo programa e, uma inconsistência poderá estar sendo criada se o saldo
estiver abaixo do valor que está sendo subtraído. Utilizando o encapsulamento, essa situação seria
evitada. Ou seja, o programa não poderia acessar diretamente o atributo da classe, teria que executar
o método sacar para poder realizar essa operação e, assim, seria mantido a integridade do estado do
objeto.
48
4.4.1. Visibilidade
Em consequência do conceito de encapsulamento, que “empacota” atributos e métodos em

um objeto, ocultando seu acesso a outros, criou-se uma forma de “controle de acesso” a esses
recursos, chamada de visibilidade.
Foram definidos três níveis de visibilidade.
Visibilidade Efeito
Pública O recurso acessado por qualquer objeto
externo. Por padrão, os métodos têm
visibilidade pública. Dessa forma eles
pode ser executados por qualquer outro
objeto.
Privada Somente os métodos da própria classe
acessam um recurso com essa
visibilidade. Por padrão, os atributos
possuem visibilidade privada.
Protegida Somente os métodos da própria classe e
das classes filhas podem acessar um
recurso com essa visibilidade.
Tabela 5 - Visibilidade
Os métodos existentes nas classes por padrão sempre serão públicos. Essa visibilidade
permite que os outros objetos possam executar esses métodos, permitindo assim o processo de
comunicação entre os objetos do sistema.
Os atributos, devem estar sempre na visibilidade privada e, dessa forma, preservarão o

conceito de encapsulamento, permitindo que apenas os métodos da própria classe acessem esses
atributos.
49
ALVES, R. Filosofia da Ciência: Introdução ao Jogo e suas Regras. Brasiliense, 14ª. Ed., São Paulo, 1991.
BERTALANFFY, L. V. Teoria Geral de Sistemas. Vozes, Petrópolis, Rio de Janeiro, 1977.
CHIAVENATO, I. Teoria Geral da Administração. Campus, 5ª. Ed., São Paulo, 1999.
FERREIRA, A.B.H. Minidicionário da Língua Portuguesa. Nova Fronteira, Rio de Janeiro, 1993.
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 1, 2019. E-Book.
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 2, 2019. E-Book.
LARMAN, C. Utilizando UML e Padrões. BookMan, 3ª. Ed., Porto Alegre, 2007. E-Book
PRESSMAN, R.; MAXIM, B. Engenharia de Software – Uma abordagem profissional. BookMan, 8ª Ed.,
2016. E-Book.
SOMMERVILLE, I. Engenharia de Software. Pearson, 9ª. Ed, São Paulo, 2011.
TONSIG, S.L. Engenharia de Software – Análise e Projeto de Sistemas. Ciência Moderna, 2ª.Ed., Rio
de Janeiro, 2008.
50

Eng. Comp. - Análise O.O. - Caderno 01

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

Eng. Comp. - Análise O.O. - Caderno 01

Enviado por

Direitos autorais:

Formatos disponíveis

Caderno 01

Prof. Sérgio Luiz Tonsig

A criação de um produto baseado em software (sistemas de informação ou automação), a

A análise de sistemas é a atividade da Engenharia de Software que cuida de estudar a

Para você, o que é um sistema?

Para a formação de “Analistas de Sistemas” é de fundamental importância que se conheça,

- Quais são as semelhanças existentes nos sistemas apresentados?

Figura 02 – Sistemas “importam” e “exportam” elementos através do meio ambiente.

Figura 03 – Sistemas dentro de Sistemas

Portanto a TGS é aplicada em diferentes campos da ciência (administração, sociologia,

Figura 04 – Input, Processamento e Output.

Na bibliografia se encontram muitas definições de sistemas, no entanto, percebemos que

“Um sistema é um conjunto de objetos unidos por alguma forma de interação

“Conjunto de Elementos, entre os quais haja alguma relação. Disposição das

“Um sistema é uma coleção significativa de componentes inter-relacionados,

“Conjunto de entidades relacionadas, interdependentes, que interagem entre

Em vários exemplos apresentados anteriormente percebemos que os sistemas são formados

Figura 05 – Entidades em trânsito pelos sistemas

Figura 07 – Cadeira de madeira com encosto ripado.

Figura 08 – Placas de Madeira

O mesmo ocorre também em um sistema de informação. Se na tela de cadastro de um

Figura 9 – Tela de Cadastro de Funcionário

1.3. Eventos em Sistemas

Eventos em um sistema se caracterizam por serem ações deflagradas para o funcionamento

1.3.1. Importação, alimentação, entrada ou input

A característica de os sistemas permitirem ou não o ingresso de certos elementos no sistema,

1.3.2. Exportação, saída ou output

Durante o período em que os elementos provenientes do meio ambiente transitarem dentro

Um aluno em trânsito pelo sistema educacional jamais sairá de lá com as mesmas

Figura 10 – Ilustrações de Produtos com Defeitos

Sendo os defeitos de produtos algo não planejado, inesperado e indesejado, a pergunta é:

Figura 12 – Valor Total e Quantidade de Parcelas

Figura 13 – Aparelho de Ar Condicionado

- Você entendeu o conceito de feedback?

A tomada de decisão pode ser considerada um processo que envolve a seleção de um

Com base no conhecimento ou informações obtidas nos sistemas, as organizações tomam

2.1. O que é dado?

O conceito de dados pode ser expresso conforme mostra a figura 14.

Figura 14 – Estrutura do Elemento de Dado

Figura 15 – Conteúdo por Dado

Tabela 1 – Exemplo de dados de uma pessoa

Rg Nome Data Nascimento Sexo Naturalidade Altura Celular

14.285.258 José da Silva 21/06/2000 Masculino Lagoas 1,60 9898-7654

12.765.767 Joaquim Manoel 25/12/1959 Masculino Sussuro 1,70 9897-9899

13.767.543 Emanuela Gilter 23/01/1974 Feminino Coaltum 1,65 9192-9394

14.768.769 José da Silva 25/12/1959 Masculino Sussuro 1,60

12.987.879 Carmem Barbosa 12/04/1963 Feminino Lagoas 1,75

Tabela 2 – Registro de Pessoas

2.2. O que é Informação?

Ainda considerando a tabela de pessoas, de acordo com os atributos lá existentes, é possível

2.3. O que é conhecimento?

O conhecimento diz respeito a capacidade de resolver problemas, inovar e aprender baseado

Portanto, o conhecimento compreende a informação, mas envolve também a experiência e

Figura 16 – Cerveja ao lado de fraldas na gôndola

Qualidade é o grau de utilidade esperado ou adquirido de qualquer coisa, verificável através

Um sistema de informação de qualidade pressupõe um sistema que cumpre seus objetivos, é

2.5. Sistemas de Informação

Os sistemas de informação são mecanismos que permitem a extração, processamento,

Os sistemas de informação devem estar alinhados com as expectativas de seus usuários, no

Os analistas de sistemas ou engenheiros de software, ao planejarem o desenvolvimento de

Figura 18 – Dimensões de um Sistema de Informação

As três dimensões que envolvem o um sistema de informação, exigem atenção do analista ao

 Disponibilidade das informações