Análise e Projetos

de Sistemas
 Material Teórico
Especificação de projeto de software

Responsável pelo Conteúdo:

Prof. Ms. Rodrigo da Rosa

Revisão Textual:
Profa. Ms. Luciene Oliveira da Costa Santos
 Especificação de projeto de software

• Introdução

• Crise do Software

• Análise: o que é?

• Técnicas de Análise Estruturada de Sistemas

• Especificação de Projeto de Software

··Qual o impacto da Engenharia de Software no desenvolvimento

de projetos de sistemas?
··Por que a Análise Estruturada de Sistemas é fundamental no
processo de desenvolvimento de projetos?
··Quais as características principais e essenciais da Especificação
de Projeto de Software?

Nessa unidade faremos um estudo sobre conceitos referentes às Especificações de Projeto

de Software. Você entenderá por que a engenharia de software é importante e conhecerá as
técnicas utilizadas para modelar sistemas.
Para que os objetivos da unidade sejam alcançados, é fundamental que você leia
cuidadosamente todo o material e realize com atenção todas as atividades propostas.
Nesta unidade é importante que, durante as leituras e a realização dos exercícios, você consiga
compreender a importância da análise estruturada de sistemas para o desenvolvimento de
projetos de software.

5
 Unidade: Especificação de projeto de software

Contextualização

Assim que os primeiros computadores tornaram-se acessíveis às pessoas de modo geral,

houve grande demanda de softwares capazes de se adequarem exatamente às expectativas dos
usuários, atendendo às necessidades pessoais e profissionais.
Desse modo, o termo Engenharia de Software surgiu estabelecendo um padrão de análise de
projetos de software para que, desde o início de seu desenvolvimento, fossem bem construídos.
Diversos modelos baseados em gráficos, tabelas e outros foram desenvolvidos e se
enquadraram em duas principais categorias de análise, que são: a Análise Estruturada de
Sistemas e a Análise Orientada a Objetos.
O processo de criação de um software deve, então, seguir tais modelos especificados pela
Engenharia de Software para que consigam os analistas e desenvolvedores fornecerem produtos
e serviços de qualidade para seus clientes usuários.
A especificação do projeto de software envolve a metodologia necessária para poder identificar
o que o software deverá realizar para atender o que os usuários esperam em termos de tarefas
desempenhadas no tempo adequado e dos resultados obtidos a partir disso.
Esta unidade irá demonstrar alguns modelos de especificação de um projeto de software
baseado na estrutura recomendada pela Engenharia de Software.

6
 Introdução

A falta de estrutura padronizada e de mecanismos de análise de processos no desenvolvimento

de software representou, em determinada época em que os recursos e mão de obra qualificada
eram escassos, uma dificuldade enorme enfrentada pelas empresas que buscavam agilidade,
segurança e funcionalidades diversas nos sistemas computacionais. Esse marco levou a criação
da expressão Engenharia de Software; a partir disso, os sistemas passaram a contar com técnicas
e modelos estruturados para que todas as necessidades apontadas pelos usuários e também
aquelas previstas fossem atendidas.
Nesta unidade, abordaremos alguns modelos de representação das informações de empresas
que visam permitir uma visualização detalhada, porém simples, dos processos que o software
deverá seguir para executar as tarefas que dele se espera. Além disso, formas conhecidas de
especificação de projeto de software serão lembradas para que a união com os novos conceitos
torne mais clara a compreensão do assunto.

Crise do Software

Na década 1960, surgiram computadores mais sofisticados e com maior capacidade de

processamento. Nesta época, diversos softwares começaram a ser desenvolvidos; porém,
apresentavam grandes problemas em sua execução devido ao trabalho amador existente
até então. Os problemas que ocorriam com frequência estavam relacionados ao custo de
projetos, ao prazo de entrega, à qualidade precária de softwares que realizavam limitavam só
a determinadas tarefas etc.
Em 1968, quando ainda não havia sido estabelecido o conceito de Engenharia de Software,
houve uma real necessidade de utilização de softwares bem projetados para atender a certas
expectativas de usuários.
Crise do software reflete a ideia de que dificuldades surgiram no desenvolvimento de softwares,
já que as técnicas não acompanhavam, na época, as necessidades crescentes. Tal crise resultou
em uma Conferência sobre engenharia de software da OTAN (NATO Software Engineering
Conference), na Alemanha, cujo objetivo principal foi discutir o que poderia ser feito para que
essa situação pudesse ser solucionada. Metodologias de desenvolvimento estiveram na pauta.
A partir disso, surgiram, por exemplo, a análise estruturada de sistemas e a análise orientada a
objetos. Esse evento motivou o aparecimento do termo engenharia de software/sistemas.

Explore
http://www.youtube.com/watch?v=EbTo14jSJ6Y

7
 Unidade: Especificação de projeto de software

Análise: o que é?

O ser humano é dotado de uma capacidade interessante que é a de decidir. Decidir significa
definir o que deve ser feito diante de uma situação qualquer. Entretanto, nem sempre as decisões
que tomamos são as mais acertadas e, quando isso acontece, as consequências podem trazer
complicações extremas.
Quando falamos de análise, estamos nos referindo ao estudo de uma situação de modo
que tenhamos uma compreensão do problema antes que uma decisão seja tomada. Tal estudo
possibilitará que os riscos de algo dar errado, ou de a decisão ser inadequada, diminuam.
No contexto de análise de sistemas, podemos dizer que se refere ao estudo das necessidades
identificadas para o desenvolvimento de um sistema para que as expectativas de um usuário
sejam atendidas.

Técnicas de Análise Estruturada de Sistemas

Análise estruturada de sistemas se refere ao conjunto de técnicas e/ou ferramentas que servem
como fundamento para desenvolvimento de modelos de sistemas. Os modelos apresentam as
informações inseridas nos sistemas e também o fluxo delas. São representados graficamente
para que seu entendimento seja simples. Além disso, deve procurar reduzir ao máximo as
redundâncias e prever o comportamento geral do sistema.
Algumas técnicas de análise estruturada de sistemas serão descritas a seguir.

DFD - Diagrama de Fluxo de Dados

Como o próprio nome sugere, este diagrama apresenta um fluxo de dados que tenta indicar
com o máximo de detalhes o que o sistema fará e como deverá fazer.

Segundo Sommerville (2007, p. 114, 115), os modelos de fluxo de

dados constituem uma maneira intuitiva de mostrar como os dados
são processados por um sistema. No nível de análise, eles devem ser
usados para modelar a maneira com que os dados são processados no
sistema existente. São usados para mostrar como os dados fluem por uma
sequência de etapas de processamento.

Os DFD são constituídos de elementos básicos utilizados para se estabelecer certo padrão de
visualização de uma situação a ser analisada. Os elementos gráficos básicos de um DFD são:

8
 Processos: os processos são representados por um círculo associado a um nome e descrevem
o que o sistema deverá fazer, ou seja, qual deverá ser o resultado de uma transformação de dados.

Figura 1: processo de um DFD.

Entidade Externa: as entidades externas, também entendidas como origem ou destino,

são elementos que enviam ou recebem informações do sistema. São representadas por um
retângulo associado a um nome. Indicam, geralmente, um grupo de pessoas, um departamento
de empresa, dentre outros.

Figura 2: entidade externa de um DFD.

Fluxo de dados: serve para demonstrar como ocorre o fluxo de dados ou pacote de
informações entre os processos existentes no modelo. É simbolizado por uma seta que sai de
um processo (fluxo de saída), ou chega nele (fluxo de entrada). Além disso, há a possibilidade
de o fluxo ser de entrada e saída ao mesmo tempo (fluxo dialógico).

Figura 3: fluxo de dados de um DFD.

Depósitos: são representados, normalmente, por duas linhas paralelas associadas a um

nome e são utilizados para indicar um conjunto de dados que se encontram armazenados.

Figura 4: depósito de um DFD.

Imagine que você decida acessar a página da Internet de uma empresa que vende DVDs.
Começa a navegar nesse ambiente e encontra um produto que chama a sua atenção, desperta
seu interesse até que a compra seja inevitável.
Para que o pedido seja feito, um cadastro deve ser preenchido através de um formulário
disponibilizado no próprio site. Seus dados pessoais deverão ser inseridos por você para
que o processo seja continuado. A etapa seguinte será a seleção do DVD, podendo ainda
escolher outros, se desejar. Cumprida essa tarefa, você deve registrar o pedido, que será
armazenado em um banco de dados, para que a ordem de pagamento seja liberada.

9
 Unidade: Especificação de projeto de software

Assim que o produto for pago, o departamento de vendas da empresa valida o processo
e solicita a entrega. Todo o status do pedido, ou seja, onde se encontra ou quando será
entregue, poderá ser acompanhado pela empresa ou por você, cliente da loja.
O processo descrito acima quando apresentado em forma de diagrama de fluxo de dados
permite melhor visualização e entendimento das ocorrências de cada etapa e de seu fluxo. A
figura 5 apresenta o diagrama de fluxo de dados da situação acima.

Figura 5: Diagrama de fluxo de dados.

Para que um DFD represente de maneira adequada uma situação passível de análise, deverá
seguir regras básicas descritas abaixo:
• Os objetos inseridos na estrutura de um DFD devem, sem exceção, possuir uma
nomenclatura.
• Os fluxos de dados não podem aparecer “soltos” no modelo, ou seja, eles devem ser
transmitidos por um objeto e recebidos por outro.
• Os processos deverão possuir mais do que um fluxo de dados, podendo, no mínimo, ser
um de entrada e outro de saída ou dois de entrada.
• Os fluxos de dados devem ter início ou término em um processo.
• Redundâncias de objetos no modelo devem ser minimamente apresentadas ou eliminadas.

DER - Diagrama Entidade–Relacionamento

O diagrama Entidade-Relacionamento é uma técnica de análise estruturada de sistemas utilizada
para representação de um modelo de dados. Tal modelo permite a especificação de uma estrutura
empresarial e contribui para o desenvolvimento de um projeto de banco de dados.

10
 Um DER possui, basicamente, três classificações de objetos ou componentes. Os principais
componentes de um diagrama ER são:
Entidades: as entidades são elementos do mundo real em que se pretende armazenar
informações de interesse.

Para Silberschatz et. al.(2006, p.153), uma entidade é uma “coisa” ou

“objeto” no mundo real que é distinguível de todos os outros objetos.

Machado (2008, p.70) contribui com a afirmação de que as entidades

correspondem a quaisquer coisas do mundo real sobre as quais se deseja
armazenar informações.

Os exemplos mais comuns de entidades são:

• Grupo de pessoas (física ou jurídica) que constituem uma entidade Funcionário, Cliente,
Fornecedor, Jogador, Professor, Médico etc.
• Grupo de objetos concretos que constituem uma entidade Produto, Exame, Equipamento,
Veículo etc.
• Grupo de objetos abstratos que constituem uma entidade Curso, Disciplina, Empréstimo etc.
• E outros.

As entidades são representadas por um retângulo associado a um nome, conforme podemos

observar na figura 6.

Figura 6: Entidades.

Atributos: são as propriedades de uma entidade que a caracterizam e descrevem-na

detalhadamente. Por exemplo, se considerarmos uma entidade chamada Cliente, os possíveis
atributos são: nome, endereço, cidade, estado, CEP, país, telefone, e-mail etc. Os atributos são
simbolizados por uma elipse associada a um nome.

Figura 7: Atributos.

11
 Unidade: Especificação de projeto de software

Relacionamento ou Relação: é a descrição das associações entre as entidades. A

representação gráfica de uma relação apresentada por um losango acompanhado por,
geralmente, um verbo que determina o envolvimento existente entre as entidades.

Figura 8: Relacionamentos.

Para que esse conceito fique mais bem definido e contribua para o entendimento mais preciso,
considere uma entidade Cliente e outra Dependente, conforme abaixo. Elas possuem ligações
entre si que possibilitam a visualização de quais são as ocorrências de uma entidade que estão
associadas à outra.

Figura 9: Exemplo de relacionamento entre entidades.

Desse modo, podemos observar que o cliente João possui dois dependentes cadastrados,
que são o Rivaldo e a Beatriz. Luís é dependente de Paulo, e Ricardo de Maria. O cliente José
não possui dependente.
Vamos agora considerar o exemplo da loja de DVDs do item Diagrama de Fluxo de Dados
apresentado anteriormente. Um modelo Entidade-Relacionamento, escrito da maneira mais
simples possível, dessa situação, poderia ser representado da seguinte maneira:

Figura 10: Diagrama Entidade-Relacionamento.

12
 A quantidade de entidades associadas a um único relacionamento determina o grau de
relacionamento existente. Um grau de relacionamento pode ser: binário, quando duas entidades
estão associadas a um relacionamento; ternário, quando três entidades estão associadas a um
relacionamento; e-nário, quando mais de três entidades estão associadas a um relacionamento.

DD - Dicionário de Dados.
É uma técnica apresentada de maneira textual que complementa as definições dos modelos
gráficos elaborados para expressar o funcionamento de um sistema.
Busca exibir através de documentação a descrição detalhada de, por exemplo, tabelas,
identificando características específicas de campos, tipos de dados restrições de integridade,
dentre outros.

Verbete
Restrição de integridade são características atribuídas a determinados atributos de entidades,
visando garantir padrões de armazenamento de dados em um sistema gerenciador de banco de
dados (SGBD). Por exemplo: o atributo idade, em uma entidade cliente, deverá receber somente
valores inteiros e positivos; o atributo nome, na mesma entidade, não poderá receber um valor nulo
(vazio); o atributo CPF não poderá possui valores repetidos em seus registros etc.

Na tentativa de facilitar ainda mais a compreensão, tomemos como base o Diagrama

Entidade-Relacionamento apresentado anteriormente. Um exemplo de dicionário de dados
seria, basicamente, assim:

Tabelas
Tabela Descrição
Cliente Tabela com informações sobre clientes da loja de DVDs.
Produto Tabela com informações dos produtos que a loja de DVDs comercializa.
Vendas Tabela com informações sobre localização e contato do departamento de vendas.
Tabela com informações sobre os produtos que foram comprados, bem como qual cliente
Pedido
comprou e em qual data e hora.

Entidade Cliente
Atributo Descrição Tipo Tamanho Domínio Formato Restrições
Identificação de um cliente
Deve ser um
Código específico do banco de Inteiro 8 - -
valor único
dados
Nome Nome completo do cliente String 25 - - -

13
 Unidade: Especificação de projeto de software

Endereço contendo
Endereço logradouro, número, String 40 - - -
complemento e cep
Cidade de lotação do
Cidade String 15 - - -
cliente
UF Estado de lotação do cliente String 2 - - -
Número do telefone do
(99)
cliente, que pode ser
Telefone String 15 - 9999- -
comercial, celular ou
9999
residencial
Endereço de e-mail do
E-mail String 20 - - -
cliente

Entidade Produto
Atributo Descrição Tipo Tamanho Domínio Formato Restrições
Identificação de um
Deve ser um
Registro produto específico do Inteiro 8 - -
valor único
banco de dados
Descrição Nome dado ao produto String 4 - - -
Nome do fabricante do
Fabricante String 20 - - -
produto

Entidade Vendas
Atributo Descrição Tipo Tamanho Domínio Formato Restrições
Setor da empresa
Localização que abriga este String 20 - - -
departamento
Ramal Ramal do departamento String 4 - - -

Entidade Pedido
Atributo Descrição Tipo Tamanho Domínio Formato Restrições
Identificação de um
Tabela
Código cliente que fez uma Inteiro 8 - -
Cliente
compra
Identificação de um
Tabela
Registro produto comprado por Inteiro 8 - -
Produto
um cliente
Data e hora em que o Deve ser
DD-MM-
Data produto foi comprado Data - - uma data
AAAA
pelo cliente válida
Preço unitário do
Preço produto comprado Valor 6,2 - 9999,99 -
pelo cliente

14
 À medida que o sistema estiver sendo desenvolvido, outras informações serão acrescentadas
ao dicionário de dados; porém, o mesmo padrão deverá ser obedecido. Desse modo, mesmo
que exista a necessidade de “no meio do caminho” substituir um desenvolvedor por determinada
razão, o seguinte terá plenas condições de entender o que foi feito e como deverá continuar,
sem acarretar prejuízos ao projeto.

DTE – Diagrama de Transição de Estados

É uma ferramenta de Análise Orientada a Objetos que será descrita sucintamente nesta
unidade. Ela descreve o estado de processo em determinado momento no sistema, permitindo
que haja a transição de estados dependendo dos eventos recebidos de fatores externos ou
internos. É composto pelos seguintes elementos:
• Estados: representam o conjunto de possíveis situações de processo. São simbolizados
por um retângulo que possuem um nome.

Figura 11: Estados em um Diagrama de Transição de Estados.

• Transições: representam as possíveis trocas de estados que poderão ocorrer no sistema.

São simbolizados por uma seta associada a uma determinada condição.

Figura 12: Transição em um Diagrama de Transição de Estados.

• Condições: representam os motivos pelos quais uma transição pode acontecer.

• Ações: representa a resposta que o sistema irá apresentar no momento em que ocorrer
uma transição.
Um exemplo deste modelo pode ser expresso assim:

Figura 13: Diagrama de Transição de Estados.

15
 Unidade: Especificação de projeto de software

Especificação de Projeto de Software

Em síntese
A análise de projeto de software envolve um trabalho minucioso e detalhista, uma vez que
todo o desenvolvimento de um sistema dependerá das informações levantadas acerca de um
determinado problema sob o qual se deseja uma solução.
Quando utilizamos o termo especificação de projeto de software, estamos nos referindo a
formas de obtenção de informações relevantes que permitirão que os desenvolvedores construam
sistemas que atendam às necessidades dos futuros usuários. A especificação deve ser elaborada
de maneira clara, buscando sempre precisão na proposta.
Especificar um projeto de software exige detalhamento de uma situação através de diversas
técnicas e métodos, como por exemplo:

Levantamento de requisitos:
• de usuário: descrevem os elementos necessários para que os usuários do sistema possam
compreender com facilidade, já que não possuem detalhes técnicos envolvidos. Requisitos
funcionais: o sistema implementado em uma drogaria deve identificar medicamentos com
data de validade a expirar e possibilitar a listagem deles através de relatórios. Requisitos
não funcionais: o sistema deve ser compatível com navegadores x e y; o tempo de resposta
a uma consulta pelo usuário não deve ultrapassar 3 segundos;
• de sistema: descrevem os elementos necessários para atender as necessidades de usuários,
contando com detalhes técnicos que serão projetados pela equipe de desenvolvimento.
Indicam quais serão as funções do sistema, com quais outros sistemas haverá a interação,
hardware específico sob o qual irá funcionar etc.

Técnicas de Análise Estruturada

• DFD – Diagrama de Fluxo de Dados: apresenta o que o sistema fará e também de que
forma através de representação de fluxo de dados.
• DER – Diagrama Entidade-Relacionamento: utilizada elementos do mundo real para
representar os dados.
• DD – Dicionário de Dados: utilizada um esquema de documentação padronizada para
apresentar os modelos de dados, completando-os.

Uma das Técnicas de Análise Orientada a Objetos

• DTE – Diagrama de Transição de Estados: utilizada quando se deseja representar os
possíveis estados de um sistema em determinado momento de seu processo.

16
 Além dessas técnicas existem outras que podem ser utilizadas no desenvolvimento de um
projeto estruturado de sistemas, por exemplo: o Modelo de Caso de Uso e o Português
Estruturado.

Explore
O capítulo 4, Identificando Requisitos, do livro Engenharia de Software: teoria e prática, de Shari Lawren-
ce Pfleeger, apresenta um estudo sobre técnicas em um projeto de software. Vale a pena estudá-lo.

No momento em que esses procedimentos tiverem sido realizados e estiverem de acordo com
as exigências dos usuários, desenvolver o software será uma tarefa bem mais simples do que se
possa imaginar. Ao final dessa etapa, é esperado que os clientes tenham uma visão bem clara
e ampla do sistema como um todo, mesmo que não entendam perfeitamente detalhes técnicos
que serão utilizados no desenvolvimento do projeto.

17
 Unidade: Especificação de projeto de software

Material Complementar

• http://www.portalarquiteto.com.br, portal da Internet com notícias e artigos sobre o

assunto Arquitetura de Softwrare.

• PAULA FILHO, W. P. Engenharia de Software: fundamentos, métodos e padrões.

Rio de Janeiro: LTC, 2009. Disponível na biblioteca virtual da Unicsul.

• PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson, 2011, disponível na

biblioteca virtual da Unicsul.

• SILBRSCHATZ, A. et. al. Sistema de banco de dados. Rio de Janeiro: Elsevier, 2006.

18
 Referências

MACHADO, F. N. R. Banco de Dados: projeto e implementação. São Paulo: Érica. 2008.

SILBRSCHATZ, A. et. al. Sistema de banco de dados. Rio de Janeiro: Elsevier, 2006.

SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Education, 2007.

19
 Unidade: Especificação de projeto de software

Anotações

20
www.cruzeirodosulvirtual.com.br
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000