Análise: Conceitos de documentação de sistemas

Análise de Requisitos

“a análise de requisitos está associada ao processo de descobrir quais são as operações que o sistema deve realizar e quais são as restrições que existem sobre elas”. (WAZLAWICK, 2004)

Esta é a fase em que o analista senta com o cliente para fazer o levantamento das funcionalidades do sistema e as restrições que existe sobre elas.
Exemplos:
Requisito funcional: “O sistema deve permitir a inserção, alteração e a remoção de produtos”
Requisito não funcional: “a base de dados deve ser protegida para acesso apenas de usuários autorizados” ou “o tempo de resposta do sistema não deve ultrapassar 30 segundos”.

Casos de uso

“os grandes processos de negócios da empresa são também chamados de casos de uso. Eles devem cobrir as principais atividades da empresa ligadas ao sistema que será implementado”. (WAZLAWICK, 2004)

Os casos de uso são definidos a partir do levantamento dos requisitos funcionais, por exemplo, seguindo o exemplo de requisito funciona, podemos dizer que o caso de uso para aquele requisito seria “manter produtos”, quando se diz “manter” refere-se as funções de inserir, alterar e remover, este caso de uso poderia ser separado em três outros casos de uso: “inserir produtos”, “alterar produtos” e “remover produtos”, assim o caso de uso “manter produtos” não existiria, isso depende do ponto de vista de quem vai fazer esse levantamento.

Orientação a Objetos
Trata-se de um paradigma de análise, projeto e programação de softwares baseados na composição e interação entre objetos.
Alguns conceitos da orientação a objetos:
Classe: exemplo usado para criar um objeto
Objeto: instância de uma classe
Atributos: características de um objeto
Métodos: definem as habilidades do objeto

Análise Orientada a Objetos
Esta trata-se de definir classes(objetos) a partir da análise de requisitos e identificar os atributos e operações para cada objeto.

UML
A UML trata-se de uma Linguagem Unificada de Modelagem, uma linguagem gráfica para: visualizar, especificar, construir e documentar o desenvolvimento completo de um sistema. A UML não é uma metodologia de desenvolvimento, isso significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela a auxilia na visualização do sistema como um todo.

Alguns diagramas da UML

Diagrama de casos de uso

É a forma de representar visualmente os casos de uso com seus respectivos atores - podemos identificá-los como os usuários do sistema - levantados na análise de requisitos.

Diagrama de classes

Consideraremos a imagem acima como um sistema de venda qualquer.
Este diagrama representa visualmente as classes definidas na análise orientada a objetos.

Diagramas de atividades

Considere que o caso de uso utilizado seja “inserir funcionário”, a imagem representa as atividades de inserção de um funcionário, porém de forma bem simples, poderia ter validações de campos obrigatórios antes de inserir, isso depende do que o sistema realmente terá que fazer. Este diagrama trata a representação das atividades consideradas num determinado caso de uso, seria praticamente um passo a passo de como o caso de uso deve funcionar.

Observações: essas são formas básicas de documentação de sistemas, o que foi apresentado são apenas introduções, por exemplo: existem mais diagramas de UML, a análise de requisitos pode ser expandida, entre outras formas.


Lembrando... que toda essa fase de análise não é completamente finalizada para iniciar o sistema, praticamente ela finalizará juntamente com o sistema, pois todos os dados levantados acima serão sempre atualizados de acordo com o que o cliente deseja. Não se consegue capturar tudo o que o cliente quer logo nas primeiras conversas, novas funcionalidades poderão surgir no andamento do projeto.


Ok... mas porque fazer tudo isso antes de começar um sistema, porque não começar o sistema de uma vez?
Bom... essa é uma forma de facilitar a comunicação entre uma equipe, entender melhor o problema, dividir a complexidade do mesmo além de ajudar a redimensionar recursos e prazos adequadamente.

Mas, toda essa parte de projeto deve facilitar o entendimento de uma determinada situação, se o mesmo for tão complexo quanto ao que está sendo projetado, o seu uso perde o sentido. Então, não há porque seguir exatamente os diagramas da UML, simplificar os estes de forma que você possa entender, ajuda no projeto.


Além de toda essa documentação de projeto, há também a documentação de código-fonte. No caso de documentar a API dos programas em Java, a Sun Microsystem criou um gerador de documentação que gera o mesmo a partir do código-fonte, o resultado é expresso em HTML.

Exemplo:

Comentário durante a geração do código-fonte:

Resultado do método em HTML:

Observações: existem outras tags do JavaDoc para documentação, no caso do exemplo só apresentamos @param e @return.

Outra forma de documentação bem interessante é a prototipação, que trata de criar as telas do sistema, antes de começar o desenvolvimento do mesmo. Assim é possível apresentar ao cliente como ficaria as telas do sistema, de forma rápida e sem implementação de códigos-fonte. O Pencil é um software que permite que essas telas sejam criadas, segue o link: http://pencil.evolus.vn/en-US/Downloads/Application.aspx


Quanto a criação de diagramas tem um site que é gratuito e que permite a criação destes: https://creately.com/


Referência sobre análise de sistemas orientados a objetos


WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.