FELIPE NÜSSLI ÁLVARES PROPOSIÇÃO DE UM ... - PRO - USP

aceitação e de seu manual de usuário. A forma de descrição funcional adotada no
Praxis 2.0 é a modelagem de casos de uso, sendo esta baseada na notação UML.
Paula Filho (2003) destaca que os casos de uso visam descrever o comportamento
do produto esperado como um todo, recomendando que tais casos de uso sejam
detalhados com auxílio de diagramas e fluxos. Enquanto os diagramas de casos de
uso descrevem os relacionamentos dos casos de uso entre si e com os autores, os
fluxos descrevem os detalhes de cada caso de uso. Paula Filho (2003) ressalta que
os passos dos fluxos dos casos de uso devam ter finalidade meramente explicativa,
não constituindo, portanto, em hipótese quanto ao desenho do produto. Afirma,
ainda nesta linha, que a existência de um passo na descrição de uma função não
significa que deva existir um componente correspondente na arquitetura. Para cada
caso de uso, Paula Filho (2003) recomenda ainda descrever os seguintes detalhes:
(i) precondições para a realização do caso de uso, (ii) fluxo principal do caso de uso
descrito na forma de uma seqüência de passos, (iii) subfluxos de caso de uso
descritos na forma de uma seqüência de passos, (iv) fluxos alternativos do caso de
uso com suas próprias precondições e seqüências de passos, (v) descrições mais
formais, caso a complexidade do caso exigir e (vi) observações, quando necessário.
105
Paula Filho (2003) aponta que todo requisito não-funcional apresenta um
campo de descrição em que o requisito deve ser sintetizado. Tal descrição deve ser
sucinta, além de permitir a definição de um teste de aceitação, ou, no mínimo, de um
item de revisão. Destaca ainda que qualquer requisito de desempenho deva ser
especificado de forma quantitativa e mensurável.
As estruturas lógicas de dados persistentes usadas pelo produto são então
descritas, de forma que cada estrutura lógica de dados é apresentada por uma
classe persistente. Dados persistentes são aqueles que mantêm seu valor após a
execução do programa e classe persistente nada mais é do que um grupo de
objetos persistentes de uma mesma classe, sendo tal grupo armazenado em um
banco de dados orientado a objetos ou simulado por meio de tabelas em um banco
de dados relacional (PAULA FILHO, 2003). Ressalta-se que o diagrama de classes
persistentes deva mostrar seus relacionamentos e atributos, de forma que os
relacionamentos de herança também sejam ser mostrados, mesmo que venham a
ser simulados no banco de dados a ser usado para a implementação do produto. A
visibilidade, as operações e os artifícios de implementação, tais como chaves
primárias e estrangeiras de banco de dados relacionais, não devem, contudo, ser