Modelagem

Como já abordamos anteriormente, os requisitos de usuários devem ser escritos em linguagem natural porque precisam de ser compreendidos por pessoas que não são peritos técnicos. Contudo, requisitos de sistemas mais detalhados podem ser expressos de maneira mais técnica. Uma técnica bastante utilizada é documentar a especificação do sistema como um conjunto de modelos de sistema.

E o que são modelos de sistema?

Esses modelos são representações gráficas que descrevem o problema a ser resolvido e o sistema a ser desenvolvido. É um sistema que só é útil se conseguir retratar as características relevantes do sistema a ser desenvolvido, sendo que diferentes características são examinadas pelo uso de vários modelos do mesmo sistema.

E quais são os objetivos desses modelos?
Servem para auxiliar na organização de informações; descrever o que o cliente deseja; estabelecer uma base para a criação de um projeto de software; definir um conjunto de requisitos que pode ser validado quando o software for construído e gerenciar a complexidade do sistema a ser implementado.

E porque isso é importante na análise de requisitos?
Devido as representações gráficas utilizadas (AKA os desenhinhos), os modelos são frequentemente mais compreensíveis do que as descrições detalhadas em linguagem natural dos requisitos do sistema. Além disso, podem ser utilizados no processo de análise para desenvolver uma compreensão do sistema existente a ser substituído ou melhorado ou para especificar o sistema requerido. Devem representar uma solução para o problema, sem se deter em detalhes que cercam a realidade. Em geral, a construção de modelos segue um conceito "Top-Down" - modelos com alto nível de abstração para modelos com baixo nível de abstração.

A utilização de modelos permite ao analista dividir problemas complexos em problemas menores fazendo a representação do relacionamento entre as partes do problema que se deseja resolver.

Em suma, permite ao analista entender a funcionalidade do sistema.

E quais tipos de modelos podem ser usados na análise de requisitos?

Existem vários modelos que podem ser utilizados na análise de requisitos. Iremos citar brevemente alguns nesse artigo.

Modelagem conceitual: Todo sistema incorpora um esquema conceitual. Assim, para que o desenvolvimento de um sistema seja bem-sucedido, é necessário explicitar esse esquema. Esse é o propósito da modelagem conceitual.

O modelo conceitual de um sistema é tipicamente composto de vários modelos, cada um deles enfocando uma perspectiva diferente, mas guardando alguma relação com outros modelos. Os diferentes tipos de modelos conceituais podem ser agrupados em duas grandes categorias:
 

• Modelos Estruturais: procuram capturar os principais conceitos do domínio, suas relações e propriedades, que são relevantes para o sistema que se está desenvolvendo. Abstração é um mecanismo chave e a definição do que é relevante é definido com base no propósito do sistema. Dentre os tipos de modelos estruturais, destacam-se o Modelo de Entidades e Relacionamentos e o Modelo de Objetos (Diagrama de Classes) na Orientação a Objetos.

• Modelos Comportamentais: especificam as mudanças válidas no estado do domínio, bem como as ações que o sistema pode realizar (OLIVÉ, 2007). Tipos de modelos comportamentais bastante utilizados no desenvolvimento orientado a objetos incluem Modelos de Casos de Uso e Modelos Dinâmicos, tais como Diagramas de Transição de Estados e Diagramas de Interação.

Peraí, num tem modelagem conceitual em banco de dados também? Sim, senhor. E qual a diferença entre os dois?

Bom, um modelo conceitual estrutural é uma abstração da realidade segundo uma conceituação. Ele pode ser usado para comunicação, aprendizado e análise de aspectos relevantes do domínio subjacente. O modelo conceitual estrutural de um sistema tem por objetivo descrever as informações que esse sistema deve representar e gerenciar.

A modelagem conceitual é a atividade de descrever alguns dos aspectos do mundo físico e social a nossa volta, com o propósito de entender e comunicar. Os modelos resultantes das atividades de modelagem conceitual são essencialmente destinados a serem usados por pessoas e não por máquinas. Assim, modelos conceituais devem ser concebidos com foco no domínio do problema e não no domínio da solução e, por conseguinte, um modelo conceitual estrutural é um artefato do domínio do problema e não do domínio da solução. As informações a serem capturadas em um modelo conceitual estrutural devem existir independentemente da existência de um sistema computacional para tratá-las.

Assim, o modelo conceitual deve ser independe da solução computacional a ser adotada para resolver o problema e deve conter apenas os elementos de informação referentes ao domínio do problema em questão. Elementos da solução, tais como interfaces, formas de armazenamento e comunicação, devem ser tratados apenas na fase de projeto

Já com relação a banco de dados...

Um modelo conceitual é uma descrição do banco de dados de forma independente de implementação em um SGBD. O modelo conceitual registra que dados podem aparecer no banco de dados, mas não registra como estes dados estão armazenados a nível de SGBD.

A técnica mais difundida de modelagem conceitual é a abordagem entidade-relacionamento (ER). Nesta técnica, um modelo conceitual é usualmente representado através de um diagrama, chamado diagrama entidade-relacionamento (DER).





Entre outras coisas, este modelo informa que o banco de dados contém dados sobre produtos e sobre tipos de produtos. Para cada produto, o banco de dados armazena o código, a descrição, o preço, bem como o tipo de produto ao qual está associado. Para cada tipo de produto, o banco de dados armazena o código, a descrição, bem como os produtos daquele tipo.

O que são linguagens de modelagem?

São técnicas utilizadas para a construção de sistemas computacionais. Tais técnicas foram evoluindo ao longo dos anos até a metodologia que é mais utilizada e aceita na atualidade, a UML.

Mas vamos a um breve resumo de como isso ocorreu:

• Décadas de 1950/60 - Sistemas de softwares bastante simples com desenvolvimento "ad-hoc" ou direto ao ponto. Onde o código fonte do software era o seu próprio modelo.
• Década de 1970 - Começavam a surgir computadores mais avançados e acessíveis. Com a expansão do mercado sistemas mais complexos começaram a surgir. Por consequencia, modelos mais robustos foram propostos. Começava a era da Programação estruturada e o Projeto estruturado.
• Década de 1980 - Computadores ainda mais avançados e baratos surgem. Surge a necessidade de interfaces mais sofisticadas, o que levou a sistemas mais complexos. A Análise estruturada surge no início deste período.
• Início da década de 1990 - Surgimento de um novo paradigma de modelagem, a Análise Orientada a Objetos.
• Fim da década de 1990 - O paradigma de orientação a objetos atinge a sua maturidade. Os conceitos de padrões de projeto, framework, componentes e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem Unificada (UML). Em 1997 a UML foi aprovada pelo OMG (Object Management Group), que é um consorcio internacional de empresas que definem e ratificam os padrões da área da orientação a objetos e desde então tem tido grande aceitação pela comunidade de desenvolvedores de sistemas.

UML
A UML é uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer que a UML é uma baseada em simbolos que representam conceitos do paradigma de orientação a objeto.

A UML é independente tanto de linguagens de programação quanto de processos de desenvolvimento. Isso quer dizer que a UML pode ser utilizada para a modelagem de sistemas, não importa qual a linguagem de programação será utilizada na implementação do sistema ou a forma de desenvolvimento adotada.

Qual a diferença entre modelos ER e diagramas de classes?
Um DER (diagrama entidade-relacionamento) é um modelo formal, preciso, não ambíguo. Isto significa que diferentes leitores de um mesmo DER devem sempre entender exatamente o mesmo. Tanto é assim que o DER pode ser utilizado diretamente como ferramenta para a geração de um banco de dados relacional.

Já os diagramas de classes, descreve as relações sem referência a qualquer implementação especifica, sendo menos formais. Ele não leva em consideração nenhuma restrição inerente à tecnologia a ser utilizada na solução do problema. Destinado a pessoas e não à máquinas.

Basicamente tanto o modelo de ER (entidade relacionamento) e os diagramas de classes descrevem os vários tipos de objetos no sistema e o relacionamento entre eles sendo a sua diferença fundamental é com relação ao domínio, sendo que o diagrama de classes está no domínio do problema já o diagrama de ER no da solução.