Modelos de sistema

Os requisitos de usuário devem ser escritos na forma de texto em razão da necessidade de serem entendidos por pessoas que não sejam especialistas técnicas. Entretanto, requisitos de sistema devem ser descritos de um modo mais técnico. Uma técnica utilizada corresponde na documentação da especificação do sistema, como um conjunto de modelos.

Estes são mais representações gráficas baseadas em conceitos computacionais, tais como objetos e funções, descrevendo o processo de negócio, o problema a ser resolvido e o sistema que será desenvolvido, do que conceitos do domínio da aplicação.

Assim, o processo de formulação, estruturação e modelagem dos requisitos pode ser guiado pelos modelos do sistema que são uma abordagem sistematizada para documentar e analisar os requisitos de sistema, sendo um importante elo de ligação entre a análise de requisitos e o projeto do software (SOMMERVILLE, 2007).

O aspecto mais importante de um modelo de sistema é o de não considerar detalhes da solução, já que corresponde a uma abstração de parte SI em estudo, simplificando e colocando em evidência seus aspectos mais importantes.

Tipos diferentes de modelos são caracterizados por distintos tipos de abstração, sendo importante ressaltar que não existe um único modelo ideal. Por exemplo, um modelo de fluxo de dados concentra-se no fluxo dos dados e em suas transformações funcionais, deixando de lado os detalhes de suas estruturas. Já o modelo de entidade e relacionamento de dados documenta as estruturas dos dados em detrimento das funcionalidades (KOTONYA e SOMMERVILLE, 1998).

Nos próximos itens, serão descritos os principais modelos de sistema e respectivas abstrações.

Modelo de fluxo de dados

Modelo de fluxo de dados corresponde a um modo intuitivo para mostrar como os dados fluem por meio de uma sequência dos passos de processamento (funções ou transformações) e fornecem uma abstração orientada para funções, cujos dados são transformados em cada uma dessas sequências, antes de se mover para o próximo estágio. Este modelo utiliza o diagrama de fluxo de dados (DFD) para representar graficamente as entidades externas, processos, fluxo de dados e depósito de dados e foi proposto originalmente por Demarco (1989).

Assim, o DFD é composto por dados que se movem, sendo representado por setas nomeadas pelos dados, pela transformação de dados em outros dados, mostrados nos círculos (o nome deste círculo corresponde a uma função/transformação), fontes e destinos de dados, representados por retângulos (designados de terminadores) e do depósito de dados, mostrado como linhas paralelas (Figura II.9).

As funções representadas pelos círculos são a base para a decomposição funcional posterior, de modo que este tipo de modelo é apresentado de um modo hierárquico, cujo primeiro modelo (também chamado de diagrama de contexto) representa o

sistema como um todo e os próximos DFDs refinem o diagrama de contexto, fornecendo mais detalhes em cada nível do diagrama subsequente.

O diagrama de contexto ajuda na visão do sistema como uma caixa preta onde é feita uma análise do tipo de dados que entram no sistema e suas respectivas fontes, assim como dos dados que saem do sistema e seus destinos, permitindo definir as fronteiras do sistema, de modo a facilitar que clientes e desenvolvedores possam entrar em acordo com o escopo do sistema a ser desenvolvido (PRESSMAN, 2005).

Função/ Transformação

Terminador 1 Terminador 2

Depósito de dados

Dados de entrada Dados de saída

Figura II.9 - Notação do diagrama de fluxo de dados (DFD) Fonte: baseado em Pressman (2005)

Modelo de dados semântico

Este modelo descreve em alto nível de abstração como os dados se relacionam em um sistema; é importante, pois permite evidenciar as estruturas dos dados, suas propriedades e seus relacionamentos, independente do processamento que ocorrerá, permitindo responder questões como: quais são os dados necessários para o negócio? Como estes dados relacionam-se com os demais? Estes dados pertencem a quem? Quem está autorizado a ter acesso aos mesmos?

Para viabilizar um modelo que permitisse fornecer informações a respeito da semântica dos dados, Chen (1990)propôs o modelo de entidade e relacionamentos (MER), que identifica as entidades em um banco de dados, seus atributos e a relação explícita entre eles.

Assim como outros modelos, o MER é descrito por meio de uma notação gráfica para facilitar o entendimento (Figura II.10) e possui os seguintes elementos:

Entidade: representa uma coleção ou um conjunto de objetos (coisas) do mundo real, cujos objetos individuais possuem as seguintes propriedades: só podem ser identificados de uma única forma, exercem um papel no sistema em construção e podem ser descritos por um ou mais elementos dos dados (atributos);

Relacionamento e cardinalidade: são as associações entre as entidades dos dados, representam uma ligação entre objetos do domínio; e seu relacionamento representa um conjunto de conexões entre os objetos, de modo que cada conexão represente uma associação entre zero ou mais ocorrências de um objeto e zero ou mais ocorrências do outro objeto (cardinalidade);

Entidade de relacionamento: corresponde a uma representação de um relacionamento sobre a qual é importante manter informações na forma de uma entidade.

Entidade 1 Entidade 2

Cardinalidade de

entrada Nome do Cardinalidade de saída relacionamento

Atributo de relacionamento

Figura II.10 - Modelo de entidade e relacionamento (MER) Fonte: baseado em Chen (1990)

Modelo de Objetos

O modelo orientado a objetos combina o uso dos dois modelos anteriores, sendo mais próximo do modelo de dados semântico, tendo como diferença fundamental o conceito de encapsulamento dos dados.

No centro deste modelo, estão as classes de objetos que representam uma abstração a respeito de um conjunto de objetos que identifique atributos e serviços (operações) em comum. Cada objeto (ou instância) desta classe possui os atributos

e serviços desta classe e os modelos são desenvolvidos, utilizando como centro da análise os objetos da classe e seus relacionamentos.

Neste tipo de análise, os objetos do mundo real devem ser representados por meio de classes de objetos, criando-se diferentes tipos de classes e de como se relacionam entre si, como os objetos são agregados para formar outras classes e como os objetos relacionam-se entre si.

Vários métodos de análise orientada a objetos foram propostos, sendo os principais: projeto e modelagem orientado a objetos (RUMBAUGH et al., 1991), engenharia de software orientada a objetos (JACOBSON et al., 1992) e análise orientada a objetos (BOOCH, 1994). Uma vez que estes métodos possuíam muitas similaridades, estes três autores decidiram integrar suas propostas para produzir um método unificado denominado UML (Unified Modeling Language) (UML, 2008).

Para certas classes de problemas, o modelo de objetos é um modo natural de refletir as entidades do mundo real que são manipuladas pelo sistema. Esta questão, particularmente, é verdadeira quando o sistema processa informações a respeito das entidades tangíveis, tais como carros, aviões ou livros, que têm atributos claramente identificáveis (por exemplo, sistema em tempo real). Em sistemas que possuem entidades mais abstratas, tais como os comerciais, é mais difícil modelar suas classes de objetos, não possuindo necessariamente uma interface simples com atributos e operações independentes.

Embora este tipo de modelo facilite a transição entre a análise de requisitos e a programação, os usuários com frequência consideram o modo pouco natural e mostram dificuldade para entendê-lo, preferindo adotar o modelo mais funcional de processamento de dados.

Modelo de transição de estados

Este modelo descreve como um sistema responde a eventos internos ou externos, foi proposto inicialmente por Ward e Mellor (1985). O modelo de transição de estados mostra os estados e os eventos que causam mudanças de um estado para outro, enfatizando o comportamento tempo-dependente do sistema.

O tipo de modelo não se preocupa com o fluxo de dados dentro do sistema, sendo útil para representação de sistemas em tempo real, uma vez que, em geral, são guiados pelos estímulos do ambiente do sistema.

Assim, o modelo de transição de estados pressupõe que o sistema seja um dos possíveis estados assumidos pelo mesmo, sendo seu maior problema que o número de possíveis estados aumenta rapidamente com a complexidade do sistema.

Modelo de contexto, processo e de fluxo de trabalho (workflow)

Logo nos estágios iniciais da descoberta de requisitos (elicitação), deve-se decidir onde estão as fronteiras do sistema: deste modo, limitando os custos do sistema e o tempo necessário para análise. Uma vez definida as interfaces do sistema deve-se conhecer o contexto e as dependências dos sistemas e seu ambiente. Para tanto, o diagrama de contexto discutido no modelo de fluxo de dados pode ser utilizado. Assim, após definir o contexto, o modelo deverá ser complementado com o modelo de processo, que mostra as principais atividades envolvidas na execução do fluxo de trabalho. Modelar o processo consiste, basicamente, na representação gráfica de um modelo das relações existentes entre: tarefas, pessoas, informações e objetos envolvidos, com o objetivo de explicitar a realidade estabelecida no ambiente estudado (ver Apêndice A; DAVENPORT, 1993).

Com o processo modelado e o sistema possuindo um número diferente de grupos de usuários, cada um com diversas atribuições, fazendo uso das distintas interfaces do usuário, muitas vezes, é necessário ir além da análise dos processos, aplicando uma análise de fluxo de trabalho (workflow). Esta técnica permite a compreensão de como o processo de trabalho é completado, quando diferentes pessoas (e regras) estão envolvidas.

Na medida que o fluxo de trabalho é analisado, deve ser definida passo a passo uma hierarquia de subatividades para cada atividade do fluxo principal, acompanhada das respectivas interfaces do usuário (PRESSMAN, 2005).