Analise e Desenho de

Software
Sumário: Paradigmas de programação e
Modelos de desenvolvimento de software
 Paradigma de
programação
É um modelo básico de construção de
programas. Um modelo que permite
produzir programas em função de umas
directrizes específicas, tais como
desenhar um programa mediante uma
sequência de instruções que operam sobre
os dados que entram e produzem um
resultado como saída.
Categorias de Paradigmas
Segundo Floyd:
• Os que suportam técnicas de
programação de baixo nível.
• Os Que suportam métodos de
desenho de algoritmos (Programação
dinâmica)
• Os que suportam soluções de
programação de alto nível (Baseados
em objectos, funcional, lógico, etc.)
 Exemplos
• Solução Procedimental ou operacional
Descreve etapa por etapa o modo de
construir a solução.
Suponhamos que queremos calcular a
área coberta pela função 3*sen(4*x)
e o eixo das abcissas entre [0; Π]
• A solução é a integral da função entre os
dois pontos, mas neste paradigma devemos
explicar como calcular a referida integral.
• A solução procedimental consistiria em
descrever os passos de qualquer algoritmo
numérico, por exemplo mediante a soma de
trapézios, aplicados a função neste
intervalo.
 Solução declarativa
Assinala as características que deve
ter uma solução, sem descrever como
processa-la.
Para o caso da área da função,
deveríamos simplesmente especificar
que temos que calcular:
π

∫ 3sen(4 x)dx
0
 E a linguagem ou sistema declarativo
utilizado para expressa-lo deve
proporcionar um processo de cálculo
automático para calcula-la.

Nota: Aqui se especifica o que há que

calcular e não como calcular.
Solução demonstrativa
É uma variante da procedimental.
Especifica a solução descrevendo
exemplos, e permitindo que o sistema
generalize a solução destes exemplos
para outros casos.
• Para o caso da área da função
teríamos que descrever exemplos de
cálculo parecidos como:
 Área de 1*sen(2*x) = 2
 Área de -2*sen(3*x)=-2
 Etc.
Engenharia de software
É uma área do conhecimento da
informática voltada para a especificação,
desenvolvimento e manutenção de sistemas
de software aplicando tecnologias e
práticas de ciência da computação,
gerência de projectos e outras disciplinas,
objetivando organização, produtividade e
qualidade.
Os fundamentos científicos para a
engenharia de software envolvem o uso de
modelos abstractos e precisos que
permitem ao engenheiro especificar,
projectar, implementar e manter sistemas
de software, avaliando e garantindo suas
qualidades. Além disso, a engenharia de
software deve oferecer mecanismos para
se planear e gerir o processo de
desenvolvimento.
A Engenharia de Software surgiu em
meados dos anos 70 numa tentativa
de contornar a crise do software e
dar um tratamento de engenharia
(mais sistemático e controlado) ao
desenvolvimento de sistemas de
software complexos..
Um sistema de software complexo se
caracteriza por um conjunto de
componentes abstractos de software
(estruturas de dados e algoritmos)
encapsulados na forma de procedimentos,
funções, módulos, objectos ou agentes e
inter conectados entre si, compondo a
arquitectura do software, que deverão ser
executados em sistemas computacionais
 Áreas de Conhecimento
• Segundo o SWEBOK, as áreas de
conhecimento da Engenharia de Software
são:
• Requisitos de Software
• Projeto (Design) de Software
• Construção de Software
• Teste de Software
• Manutenção de Software
• Gerência de Configuração de Software
• Gerência de Engenharia de Software
• Processos de Engenharia de Software
• Ferramentas e Métodos de Engenharia de
Software
• Qualidade de Software
 História
• Década de 1940: Se estabelece os
fundamentos da computação moderna.
• Decada 1960: Começa a ser comum o
desenvolvimento de aplicações
relativamente grandes: é o inicio da
engenharia do software.
• Nestes anos existia pouco conhecimento
sobre como desenvolver grandes projectos
de Software.
• O hardware podia suportar grandes
projectos. A dificuldade radicava em
organizar e coordenar as actividades
destes projectos, o que conduziu a
chamada “Crise do Software”
• Em 1968 o comité da OTAN
patrocinou uma conferência na
Alemanha cujo objectivo era
identificar, classificar e discutir os
problemas que se produziam no
desenvolvimento de grandes
projectos.
• Formou-se um grupo presidido por F.
L. Bauer, com a missão de avaliar
técnicas para poder desenvolver um
software flexível e de qualidade.
• Esta constatou que o desenvolvimento
do software é uma tarefa de
engenharia (Se aplicou pela 1ª vez o
termo “Engenharia de Software”) que
não é muito diferente de outros tipos
de engenharia.
• O desenvolvimento de software deveria
ser modelado de acordo com os paradigmas
e métodos já estabelecidos por outras
disciplinas de engenharia , e cujo fim era a
produção industrial de programas
eficientes, fiáveis e robustos, elaborados
com um mínimo de custos e tempo
possíveis
Modelos de ciclo
de vida de
desenvolvimento
de software
O termo software se refere a um
conjunto de programas informáticos
que se desenvolvem num computador
e que normalmente se classificam em
três tipos:
• Programas de controlo: controlam e
supervisionam a execução de todas as
tarefas e processos que têm lugar no
computador (exemplo o Sistema
Operativo)
• Programas de processo: Servem para
que o usuário crie os seus próprios
programas (exemplo: compiladores,
interpretes,etc.)
• Programas de aplicação: São os que
são desenvolvidos pelo e para o
usuário do computador para resolver
problemas específicos.
• Quando falamos de “Desenvolvimento
de Programas” estamos a nos referir
(na maioria dos casos) a software de
Aplicação, já que o software de
sistema vem com o computador.
 O Ciclo de Vida Clássico
Engenharias do
Sistema
Planificação
Análise dos
requisitos

Desenvolvimento Desenho

Codificação
Provas

Manutenção Manutenção
Engenharia do
Sistema ou
Analise do
Sistema
Esta etapa tem como objectivo
realizar uma análise global do
sistema, estabelecendo os requisitos
de todos os elementos do sistema. E
depois adjudicar uma parte dos
requisitos ao software.
• A análise do sistema compreende o
tratamento de todas as tarefas
manuais e informáticas que definem o
sistema.
• O engenheiro informático terá que
estudar profundamente o sistema,
especializar-se na sua terminologia e
realizar uma interacção permanente
com o cliente, peritos do sistema e os
usuários de formas que a percepção
que tenha do sistema coincida com a
do cliente, perito e usuário
 Objectivos da análise do
sistema
1. Identificar as necessidades do cliente
O Analista, junto com o cliente, perito e
usuário, define os objectivos do sistema
(o produto a obter), a informação que vai
fornecer ao sistema e a que este irá
proporcionar, as funções e o rendimento
requerido.
• Realizar uma análise técnica e económica
do sistema
A análise técnica avalia a viabilidade
técnica do sistema proposto e recolhe
informação sobre o rendimento, fiabilidade
de manutenção e possibilidade de produção
• Análise económica é uma analise custo
– benefício que avalia os custos
estimados para o desenvolvimento do
sistema e os compara com os
benefícios previstos
2. Estabelecer restrições de custo e de
tempo
3. Avaliar a viabilidade do sistema
Inclui normalmente uma analise de
viabilidade (económica técnica e
legal) junto com uma análise de
riscos.
• Riscos do projecto (problemas
orçamentais, de agenda, de pessoal,
etc.)
• Riscos técnicos (problemas de
desenho, implementação, manutenção,
etc.)
• Riscos do negócio (o produto não
interessa ao mercado, não é facil
comercializa-lo, etc.)

- Se o risco do sistema é grande, a sua

viabilidade diminui na mesma
proporção
4. Adjudicar funções ao software, ao
hardware, as pessoas, as bases de
dados e a outros elementos do
sistema.
5. Definir o sistema de forma que seja a
base para todo o trabalho posterior.
Consiste fundamentalmente em criar um
modelo de arquitectura do sistema que
descreva as interacções entre os distintos
elementos do sistema (interface de
usuário, entradas, função e controlo do
sistema, saídas, manutenção e auto
comprovação)
• O modelo incorpora um “diagrama de
contexto de arquitectura”, que estabelece
os limites de informação entre o sistema e
o entorno em que vai funcionar, e define os
produtores e os consumidores externos,
assim como as entidades que se comunicam
através da interface ou realizam
manutenção ou auto comprovações.
 Exemplo
• Num sistema de Gestão de pessoal
distribuído, que incorpora-se
computadores pessoais em cada
centro de trabalho para a gestão do
seu pessoal, ligados a um servidor
central onde se realizam tarefas
gerais que afectem todo o pessoal
O “Diagrama de contexto” do sistema
seria uma representação gráfica de
todas as configurações informáticas
existentes nos diferentes centros de
trabalho e na sede interligados entre
si.
“O diagrama de fluxo da arquitectura”,
seria outra representação gráfica que
mostra os subsistemas que definem a
arquitectura, junto com os fluxos de
controlo e os dados que produzem os
subsistemas.
 Documento final da
análise
Toda a análise do sistema se sintetiza
num documento, denominado
“Especificações do Sistema” , que
serve como base para a engenharia do
hardware, do software das bases de
dados e a engenharia humana.
 Exemplo
a) Objectivos gerais do sistema
• Fins do sistema
• Funcionamento e Rendimento
requerido
• Entradas do sistema
• Saídas do sistema
• Restrições
b) Definições de Requisitos do:
• Software
• Hardware
• Base de dados
• Pessoal e outros elementos do
sistema.
c) Análise Técnico
• Rendimento
• Fiabilidade
• Manutenção
• Produção
d) Análise Económico
• Custos de produção
• Custos de manutenção
• Relação custo benefício
e) Viabilidade do Sistema:
• Económica e de mercado
• Técnica
• Legal
f) Especificações da Arquitectura do
Sistema
• Diagrama de contexto da
arquitectura
• Diagrama de fluxo da arquitectura
• Descrição dos subsistemas.
• O último passo desta etapa (Análise
do Sistema) é definir o sistema,
sempre que este seja viável em
relação aos custos e as restrições
estabelecidas.
• No que respeita ao documento “Plano
de Software” que é uma parte das
especificações do sistema, deve
incorporar em linhas gerais os
seguintes elementos do documento
“Especificações do Sistema”:
• Objectivos Gerais
• Requisitos do Software
• Requisitos das bases de dados
• Arquitectura do sistema.