Revisões técnicas formais


III. FASE DE DESENVOLVIMENTO



Yüklə 248,76 Kb.
səhifə4/9
tarix01.11.2017
ölçüsü248,76 Kb.
#25554
1   2   3   4   5   6   7   8   9

III. FASE DE DESENVOLVIMENTO

A Fase de Desenvolvimento é a etapa do processo de desenvolvimento e manutenção, descrito na seção I.6, que inclui o Projeto de Sistema, o Projeto de Arquitetura, o Projeto de Dados, o Projeto Procedimental, o Projeto da Interface e a Codificação, além das revisões necessárias aos produtos gerados em cada etapa.


Nesta apostila serão abordados os aspectos fundamentais de projeto e os projetos de sistema, de arquitetura e de dados.

III.1 ASPECTOS FUNDAMENTAIS DE PROJETO





  • Abstração

  • Refinamento

  • Modularidade

  • Arquitetura de software

  • Hierarquia de controle

  • Estrutura de dados

  • Procedimento de software

  • Ocultação de informação



a) Abstração

“... a noção psicológica de abstração permite que uma pessoa se concentre num problema com certo nível de generalização, sem levar em consideração detalhes irrelevantes de menor nível; o uso de abstração também permite que se trabalhe com conceitos e termos que são familiares ao ambiente do problema sem que seja preciso transformá-los em uma estrutura não-familiar...” Wasserman

Durante o desenvolvimento o software é definido em vários níveis de abstração. Durante a análise e especificação de requisitos é definido em termos que são familiares aos usuários. Conforme se caminha no processo de desenvolvimento o nível de abstração vai ficando cada vez mais relacionado a aspectos de implementação.


  • Abstração procedimental:

Uma sequência de instruções designadas que tem uma função específica e limitada.

Considerando um programa, a descrição de seus objetivos seria uma primeira abstração procedimental. Depois a elaboração das tarefas a serem realizadas seria uma segunda abstração. A terceira seria o pseudo-código e por fim a quarta o código-fonte na linguagem escolhida.




  • Abstração de dados:

É uma coleção designada de dados que descreve um objeto de dados. Por exemplo, cheque de pagamento é um objeto de dados que representa várias informações diferentes: nome da pessoa a quem se paga, quantia bruta paga, imposto retido, imposto de renda, contribuição para a previdência, etc..

Contudo podemos nos referir a todos os dados ao declararmos o nome da abstração de dados.

A abstração de dados possibilita que o projetista represente um objeto de dados em níveis variáveis de detalhe e, o que é mais importante, que ele especifique um objeto de dados no contexto das operações que podem ser aplicadas a ele.

Quando usamos o tipo real para representar números reais estamos usando uma abstração de dados, sem saber muito sobre a representação deste tipo no computador. (Esta representação varia de um para outro computador). Para usar um objeto de dados no programa cliente deve-se declarar a variável como daquele tipo.

Logo que uma abstração de dados é definida, um conjunto de operações que podem ser aplicadas a ela também é definido.

Várias linguagens têm mecanismos que permitem a criação de tipos abstratos de dados (combinação de um tipo de dado com seus operadores), que é usado como um padrão ou estrutura de dados genérica a partir da qual outras estruturas de dados podem ser representadas por uma instância.


b) Refinamento

O refinamento é um processo de elaboração.

“Em cada passo (do refinamento), uma ou mais instruções do programa dado são decompostas em instruções mais detalhadas. Essa sucessiva decomposição ou refinamento das especificações termina quando todas as instruções são expressas em termos de qualquer linguagem de programação ou computador subjacente... À medida que as tarefas são refinadas, também os dados podem ter de ser refinados, decompostos ou estruturados, e é natural refinar-se os programas e as especificações de dados paralelamente.

Cada passo de refinamento implica algumas decisões de projeto...” Wirth



c) Modularidade

Um software constituído de um único módulo não pode ser facilmente entendido e modificado. O software deve ser dividido em componentes separadamente nomeados e endereçáveis denominados módulos.

Um sistema pode ser projetado modularmente, mesmo que sua implementação deva ser monolítica. Há situações, como software de tempo real, em que gastos com memória e velocidade introduzidos por subprogramas são inaceitáveis. Em tais situações, o software pode e deve ser projetado, tendo a modularidade como filosofia. Apesar do código-fonte não parecer modular à primeira vista, o programa apresentará os benefícios de um sistema modular.
d) Arquitetura de software

O problema a ser resolvido pelo software, definido na análise de requisitos, é derivado numa arquitetura de software a partir de um processo de divisão em partições. A arquitetura de software trata da estrutura hierárquica de módulos e da estrutura de dados.

Um método de projeto pode ser usado para se derivar a estrutura, mas uma vez que cada um se baseia em diferentes conceitos fundamentais de bom projeto, cada método poderá levar a uma estrutura diferente para o mesmo conjunto de requisitos. Apesar de não se poder afirmar qual a melhor, há características de uma estrutura que podem ser examinadas para se determinar a qualidade da solução.
e) Hierarquia de controle

Também chamada de estrutura de programa, representa a organização de módulos de programa. Uma notação que é utilizada é o diagrama em árvore. Termos que são utilizados são:



  • Profundidade: indicação do número de níveis de controle

  • Largura: indicação do espaço de controle global.

  • Fan-out: medida do número de módulos que são diretamente controlados por outro módulo (ou seja, o número de módulos que chamam o módulo sendo analisado)

  • Fan-in: indica quantos módulos controlam (chamam) diretamente determinado módulo.

  • Subordinado: um módulo controlado por outro é subordinado ao controlador

A hierarquia de controle representa duas características diferentes da arquitetura de software: a visibilidade e a conectividade.



  • Visibilidade: indica o conjunto de componentes de programa que pode ser invocado ou usado como dados por determinado componente.

  • Conectividade: indica o conjunto de componentes que é diretamente invocado ou usado como dados por determinado componente.

De forma a representar a hierarquia de controle pode ser utilizado o Diagrama de Estrutura apresentado na seção V.4 desta apostila.
f) Estrutura de dados

Representa o relacionamento lógico entre elementos de dados individuais. Determina a organização, métodos de acesso, grau de associatividade e alternativas de processamento de informações.

A organização e a complexidade de uma estrutura de dados dependerá da habilidade do projetista. Há no entanto certas estruturas de dados clássicas que formam outras estruturas mais sofisticadas.


  • Item escalar: a mais simples de todas as estruturas de dados. Representa um único elemento de informação que pode ser endereçado por um identificador. Seu tamanho e formato podem variar de acordo com a linguagem de programação.

  • Vetor sequencial: itens escalares organizados como uma lista ou como um grupo contíguo. Quando o vetor sequencial é ampliado para duas, três e mais dimensões, um espaço n-dimensional é criado.

  • Lista: organiza itens de dados, arrays, de modo que possibilita que eles sejam processados como uma lista. Cada nó contém a organização de dados apropriada (por exemplo, um vetor) e um ou mais ponteiros que indicam o endereço de armazenamento do próximo nó da lista. Nós podem ser adicionados a qualquer ponto da lista ao se redefinir os ponteiros que acomodam a nova entrada da lista.

  • Etc...


g) Procedimento de software

Focaliza os detalhes de processamento de cada módulo individualmente. Deve oferecer uma especificação precisa do processamento.


h) Ocultação de informação

De acordo com este princípio os módulos devem ser especificados e projetados de tal forma que as informações (procedimento e dados) contidas num módulo sejam inacessíveis a outros módulos que não tenham necessidade de tais informações. Assim, quando houver necessidade de modificações, os erros que forem introduzidos contra nossa vontade têm menos chances de se propagar para outras localizações dentro do software.





Yüklə 248,76 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin