Especificação Operacional.
Para muitos sistemas, a incerteza acerca dos requisitos leva a mudanças e problemas
mais tarde no desenvolvimento de software. Zave (1984) sugere um modelo de processo
que permite aos analistas e clientes examinar os requisitos e as suas implicações
antecipadas no processo de desenvolvimento, onde podem discutir e resolver alguma da
incerteza. No modelo de especificação operacional, os requisitos do sistema são
avaliados ou executados de uma forma que demonstra o comportamento do sistema.
Isto é, uma vez que os requisitos sejam especificados, eles podem ser desenvolvidos
usando um pacote de software, de tal forma que as suas complicações podem ser
estimadas antes do desenho começar. Por exemplo, se a especificação requer que o
sistema controle 24 utilizadores, uma forma executável da especificação pode ajudar
analistas a determinar se esse número de utilizadores coloca demasiado peso na
performance do sistema.
Este tipo de processo é muito diferente dos modelos tradicionais tal como o modelo em
cascata. O modelo em cascata separa a funcionalidade do sistema do desenho (i.e., o que
é para o sistema fazer, separado, de como o sistema o faz), pretendendo manter as
necessidades do cliente separadas da implementação. Contudo, uma especificação
operacional permite que a funcionalidade e o desenho se fundam. Note que a
especificação operacional é semelhante à prototipagem; o processo permite ao utilizador
e analista examinarem requisitos antecipadamente.
Nota: pacote de aplicação (pacote de software) - série de programas ou módulos
dirigidos para um aplicação genérica, podendo ser modelados (possivelmente com
determinadas alterações) para as necessidades de um aspecto específico dessa aplicação.
Executa e examina
ESPECIFICAÇÃO
OPERACIONAL
(orientada para o
problema)
REQUISITOS DO
SISTEMA
(por vezes informais
ou incompletos)
ESPECIFICAÇÃO
TRANSFORMADA
(orientada
à
implementação)
TESTE
SISTEMA
ENTREGUE
Figura 1 - Modelo de especificação operacional
As técnicas utilizadas na tarefa de análise poderão incluir a realização de reuniões com
os interessados, a elaboração de questionários, a observação das actividades e do
funcionamento do dia-a-dia, a recolha e análise de documentação diversa, a elaboração
-1-
de pequenos protótipos de sistemas que permitam validar mais facilmente a percepção
obtida.
O objectivo geral é expressar sem ambiguidades o que o sistema deve fazer e não como
fazer o sistema.
A especificação operacional consiste em diagramas (representação gráfica de
determinado esquema – especificação de um modelo usando uma determinada
linguagem a qual pode ser, formal ou informal (por exemplo linguagem natural), textual
ou gráfica) que dividem o comportamento num conjunto de acontecimentos
protagonistas e respostas do sistema a esses acontecimentos. Os diagramas produzidos
pela especificação operacional são modelos de análise pura.
Os diagramas tratam da fase de análise, comportamento ao nível do sistema somente e
não especificam dados, desenho ou informação de implementação.
O desenho inclui, por exemplo, arquitecturas de computadores, tecnologias de bases de
dados, sistemas de execução de agentes, infra-estruturas de objectos e/ou componentes,
etc. É também nesta tarefa que deve ficar completamente definido o ambiente e as
linguagens a utilizar no desenvolvimento.
A tarefa de implementação inclui todas as actividades de desenvolvimento do sistema
propriamente dito, ou seja, que estão relacionadas com a concretização do modelo de
desenho. As actividades desta tarefa deveriam ser apoiadas por ferramentas, que a partir
da especificação do modelo de desenho produzido seriam capazes de produzir
automaticamente diversos componentes do sistema.
Teste – O objectivo é avaliar a adequada correcção e funcionamento de todos os
componentes do sistema, principalmente os executáveis. A verificação consiste na
confirmação que a codificação/implementação do sistema está conforme (correcta) a
especificação técnica produzida na fase de desenho, que por sua vez resulta dos
requisitos especificados na análise.
Exemplos:
Os diagramas de fluxo de dados (Data Flow Diagrams - DFDs) descrevem os
sistemas como colecções de dados que são manipulados por funções. Os dados podem
ser organizados de várias formas: eles podem ser armazenados em repositórios de
dados, podem fluir em fluxos de dados e podem ser transferidos para ou do meio
externo.
Os elementos básicos do DFD são:
·
·
·
Bolhas (bubbles), usadas para representar funções.
Setas (arrows), usadas para representar o fluxo de dados. Setas que vão para
bolhas representam valores de input que pertencem ao domínio da função
representada pela bolha. Setas que saem representam os resultados da função,
i.e., valores que pertencem ao alcance da função.
Caixas abertas (open boxes), usadas para representar bases de dados. Setas
entrando (saindo) nas caixas abertas representam dados que são inseridos na
(extraídos da) base de dados.
-2-
·
Caixa de I/O ( I/O boxes ), usadas para representar aquisição de dados e
produção durante a interacção do homem com o computador.
DFD descrevendo um sistema de informação de uma biblioteca simplificado.
Pedido do livro
pelo utilizador
Livro
Prateleiras
Título e autor do
livro pedido; nome
do utilizador
Autor
Recepção do
Lista de autores
Livro
Obter um
livro
livro
Título
Título do livro;
nome do utilizador
Lista de títulos
Lista de livros emprestados
Título
Procura
por
tópicos
Lista de tópicos
Mostrar
Lista de títulos
referentes
ao
tópico
Tópico
a
lista de títulos
Tópico
Pedido de tópico
pelo utilizador
Figura 2 – DFD de uma biblioteca.
A figura descreve um sistema de informação simplificado para uma biblioteca pública.
O DFD descreve objectos físicos, tais como livros e prateleiras, juntamente com
-3-
armazenamento de dados que provavelmente, mas não necessariamente, são concebidos
como ficheiros de computador. Obter um livro da prateleira pode ser feito quer
automaticamente - por um robot - quer manualmente. Em ambos os casos, a acção de
obter um livro é representada por uma função representada por uma bolha.
A figura também descreve que para obter um livro é necessário:
· um pedido, explícito, do utilizador consistindo do título, do nome do autor do
livro e do nome do utilizador;
· aceder às prateleiras que contêm os livros;
· uma lista dos autores;
· uma lista de títulos.
Isto fornece a informação necessária para encontrar o livro.
Uma máquina de estado finito (Finite State Machine - FSM) consiste em:
·
·
·
um conjunto finito de estados, Q;
um conjunto finito de inputs, I;
uma função de transição f: Q*I -> Q. f pode ser uma função parcial, i.e., pode
ser indefinida para alguns valores dos seus domínios.
Graficamente, uma FSM é mostrada por um grafo cujos nós representam estados; um
arco rotulado por i vai de q1 para q2 se e somente se f(q1,i)=q2.
FMSs são aconselháveis para descrever sistemas que podem estar num conjunto finito
de estados e que podem ir de um estado para outro como consequência de algum
acontecimento, modelado por um símbolo de input. Por exemplo, uma lâmpada pode
estar quer ligada quer desligada e pode ir de ligada para desligada como consequência
de uma acção externa consistindo em pressionar o interruptor. Pressionar o interruptor
outra vez causa a transição oposta.
Figura 3 - A descrição de uma máquina de estado finito de um interruptor de lâmpada.
Considere o controlo de uma (pequena parte de uma) planta química. Níveis de
temperatura e pressão têm de ser monitorizados por razões de segurança. Sensores são
instalados para gerar sinais apropriados quando qualquer destes níveis exceder alguns
dos valores predefinidos. Uma política trivial para manipular a planta é a seguinte:
quando qualquer um dos sinais é aumentado pelo sensor correspondente, o sistema de
-4-
controlo fecha a planta e aumenta o sinal de alarme; o sistema é reiniciado manualmente
quando a causa da falha for corrigida. Como descrito na figura:
Figura 4 – FSM descrevendo o controlo de uma planta química.
Esta simples política é obviamente inadequada. Uma melhor forma de orientar a planta
é como se segue. Quando um dos dois sinais é aumentado, uma acção de
restabelecimento é automaticamente invocada (existe uma “acção temperatura” e uma
“acção pressão”). Se, depois de um pouco de tempo, a acção de recuperação é bem
sucedida, o sistema é automaticamente desligado para o estado “normal” e uma
mensagem “tudo ok” é emitida para o meio externo. Caso contrário, o sinal de alarme
tem de ser aumentado e a planta tem de ser desligada. O sistema tem também de ser
desligado se está a tentar recuperar de um tipo de anomalia – temperatura e pressão – e
o outro sinal é aumentado. É assumido que os dois sinais não podem ocorrer
simultaneamente. Esta nova política é descrita na figura.
Figura 5 – FSM descrevendo o controlo de uma planta química.
-5-
Vantagens:
·
·
·
O sistema resultante é mais fácil de usar.
Necessidades do utilizador são mais facilmente ajustadas (o envolvimento
contínuo do utilizador resulta em sistemas que melhor satisfazem as
necessidades do utilizador).
Problemas são detectados mais cedo.
Desvantagens:
·
·
·
O sistema resultante tem mais aspectos (uma vez que o intervalo de tempo entre
versões sucessivas é menor, utilizadores podem pensar que é mais fácil conceber
novos aspectos e podem especificar requisitos adicionais).
A performance do sistema resultante é pior (performance tende a ser pior porque
a atenção é focada na funcionalidade e as medidas de performance ou não são
tomadas em conta ou a certa altura tornam-se difíceis de conceber).
O sistema resultante é mais difícil de manter (se estiver preocupado com o pouco
tempo para desenvolvimento, certas actividades necessárias vão receber menos
atenção. Há a possibilidade da documentação ser sacrificada pela velocidade. Por
causa das adições resultantes de frequentemente voltar a trabalhar os passos a
qualidade do desenho pode deteriorar).
Trabalho realizado por:
Grupo 3
Nº 11311
-6-
Ana Sofia Atanázio