Especificação Operacional.

Transcrição

1 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) ESPECIFICAÇÃO TRANSFORMADA (orientada implementação) à TESTE REQUISITOS DO SISTEMA (por vezes informais ou incompletos) Figura 1 - Modelo de especificação operacional SISTEMA ENTREGUE 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 -

2 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

3 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 Livro pelo utilizador Prateleiras Título e autor do livro pedido; nome do utilizador Autor Lista de autores Obter um livro Livro Recepção do livro Título Lista de títulos Título do livro; nome do utilizador Lista de livros emprestados Lista de tópicos Título Tópico Tópico Procura por tópicos Mostrar a Lista de títulos referentes ao tópico lista de títulos 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 -

4 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 -

5 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

6 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º Ana Sofia Atanázio - 6 -