SETI

Visão Geral

O Modelo Conceitual do Diagrama de Classes é um artefato do domínio do problema e não do domínio da solução, portanto, não é utilizado para especificação da arquitetura do sistema. Ele é formado pelos conceitos (classes de abstração) obtidos a partir da análise textual da definição do problema (enunciado do problema e casos de uso), atributos (deve-se preocupar somente com os atributos obtidos a partir da abstração do problema ou em decorrência do conhecimento do domínio do problema) e associações (relacionamentos).
Um modelo “completo” do diagrama de classes será obtido posteriormente, nesse momento, a especificação do diagrama de classes estará voltado às definições da solução a nível de arquitetura do sistema, portanto, do domínio da solução e não mais do domínio do problema. Na fase de Análise e Design o modelo conceitual do diagrama de classes evolui para uma especificação mais completa, com a inclusão de atributos, não identificados no momento da elaboração do modelo conceitual, e das operações das classes. Uma reestruturação das classes e relacionamentos também pode ocorrer nesta evolução do modelo conceitual para o modelo “completo”, provocando a inclusão de novas classes e relacionamentos com semântica mais apurada e, também, especificação de hierarquias de classes com a inclusão de relacionamentos de herança.

Uso Comum

O modelo conceitual do diagrama de classes é um artefato que especifica um nível intermediário de abstração entre as fases de “Requisitos” e “Análise e Design”, cujo objetivo principal é prover um mecanismo capaz de auxiliar no processo de identificação das classes de objetos do domínio do problema.

Termos e Conceitos

A construção do modelo conceitual do diagrama de classes identifica o produto final da abstração das classes candidatas obtidas a partir de uma análise gramatical do domínio do problema.

Identificação de Classes e Objetos

Pode-se começar a identificar objetos (classes) examinando o enunciado do problema ou executando uma “análise gramatical” da narrativa de processamento do sistema a ser construído.
As classes são identificadas sublinhando cada substantivo ou cláusula substantivada, logo após, as possíveis classes candidatas deverão ser relacionadas, para que uma análise mais aprofundada possa ser feita com o objetivo de verificar a existência ou não da classe relacionada.
As candidatas à classe se manifestam da seguinte maneira:

• Entidades externas (outros sistemas, dispositivos e pessoa) – que produzem ou consomem informação a ser usada por um sistema baseado em computador;
• Coisas (relatórios, figuras, cartas, sinais) – que são parte do domínio de informação do problema;
• Ocorrências de eventos (efetua pagamento, emite recibo) – que ocorrem dentro do contexto da operação do sistema;
• Papéis (gerente, engenheiro, vendedor) – desempenhados por pessoas que interagem com o sistema;
• Unidades organizacionais (divisão, grupo, equipe, setor) – que são relevantes para uma aplicação;
• Lugares (recepção, estoque) – que estabelecem contexto do problema ou a função global do sistema;
• Estruturas (sensores, impressora, computadores, leitora de código de barra) – que definem uma classe de objetos ou classes relacionadas de objetos.

A lista continuaria até que todos os substantivos na narrativa de processamento tivessem sido considerados.
Seis características de seleção podem ser usadas quando um analista considera cada classe em potencial para inclusão no modelo de análise:

• Informação retida – A classe potencial vai ser útil durante a análise apenas se a informação sobre ela tiver que ser lembrada para que o sistema possa funcionar.
• Serviços necessários – A classe potencial deve ter um conjunto de operações identificáveis que podem mudar o valor de seus atributos de algum modo.
• Atributos múltiplos – Durante a análise de requisito, o foco deve ficar na informação “importante”; uma classe com um único atributo pode ser útil durante o projeto, mas é provavelmente melhor representada como atributo de outra classe durante a atividade de análise.
• Atributos comuns – Um conjunto de atributos pode ser definido para o objeto potencial e esses atributos se aplicam a todas as ocorrências dos objetos.
• Operações comuns – Um conjunto de operações pode ser definido para a classe potencial e essas operações se aplicam a todas as ocorrências dos objetos.
• Requisitos essenciais – Entidades externas que aparecem no espaço do problema e produzem ou consomem informação essencial para a operação de qualquer solução do sistema vão quase sempre serem definidas como classes no modelo de requisitos.

Uma melhor especificação de atributos, operações e relacionamentos pode ser obtida no documento “Diretriz de Artefato – Modelo de Classes”. Atentar também ao padrão de nomenclatura para classe, atributos e operações.

Identificando Classes Candidatas

Considerando os modelos apresentados nos documentos: “Diretriz de Artefato – Modelo de Caso de Uso” e “Diretriz de Artefato – Modelo de Atividades”, que definem um determinado cenário de um contexto de problema, serão adotados procedimentos (baseados em técnicas de análise gramatical – separando-se os substantivos) para a abstração de classes candidatas.

 

Classe Candidata	Nome da Classe	Situação
Pessoa	Pessoa	Ok
Funcionário	Funcionario	Ok
Vendedor	Vendedor	Ok
Caixa	Caixa	Ok
Cliente	Cliente	Ok
Produto	Produto	Ok
Disponibilidade	NOk
Pedido	Pedido	Ok
Item	ItemPedido	Ok
Pagamento	Pagamento	Ok
Pagamento à vista	tipoPagamento “Pagamento”	Atrib
Pagamento a prazo	tipoPagamento “Pagamento”	Atrib
Recebimento	NOk
Cupom Fiscal	NOk
Estoque	quantEstoque “Produto”	Atrib
Situação: Ok Identificada como classe NOk Descartado como classe ou atributo Atrib Identificado como atributo de uma classe

Modelo Conceitual do Diagrama de Classes

Considerando a abstração de classes candidatas, um modelo conceitual do diagrama de classes pode ser especificado (em um alto nível de abstração). Um segundo modelo conceitual (em um nível menor de abstração) poderá ser obtido, incluindo informações obtidas a partir de um levantamento mais detalhado dos requisitos do sistema.
As classes Vendedor e Caixa, indicadas no modelo conceitual do diagrama de classes da Figura 1 em amarelo, foram incluídas no diagrama apenas para mapear as restrições de relacionamento, sendo assim, poderão ser efetivamente implementadas, porém, não serão consideradas em um projeto de persistência de dados (a persistência será obtida a partir da classe Funcionario). A semântica relacionada a esse tipo de mapeamento indica que um objeto da classe Pedido somente estará relacionado a um objeto da classe Funcionario se o funcionário for Vendedor. Um significado semelhante é adotado para um objeto da Classe Pagamento que somente poderá estar relacionado a um objeto da classe Funcionario se o funcionário for Caixa.
  Modelo Conceitual do Diagrama de Classes (abstração nível 01)

O modelo conceitual do diagrama de classes, indicado pela Figura1, é apresentado em um nível alto de abstração, pois, foi obtido a partir de procedimento mecânico utilizando-se de uma análise gramatical produzindo um levantamento das classes candidatas.
Considerando um conhecimento prévio do domínio do problema e uma experiência em procedimentos de modelagem, o Analista de Requisitos ou o Analista de Projeto podem produzir um modelo um pouco mais detalhado, encontrando novas classes ou atributos que em um primeiro momento não foram possíveis abstrair a partir dos artefatos existentes. Neste momento, quando itens importantes são incluídos no modelo, deve-se avaliar se os artefatos utilizados para a abstração dos conhecimentos necessários para a construção do modelo conceitual do diagrama de classes não estão incompletos e necessitando, assim, de uma readequação (produzindo uma evolução dos modelos).
Construir modelos de sistemas (e o sistema propriamente dito), considerando uma abordagem de ciclo de vida, espera-se que uma evolução ordenada ocorra produzindo uma maturidade do sistema e dos modelos associados. Quando da elaboração de um artefato deve-se considerar que este artefato valide ou agregue modificações a artefatos anteriores produzindo, desta maneira, a maturidade esperada.
Na Figura 2 é apresentado o modelo conceitual do diagrama de classes obtido a partir de um nível de abstração mais detalhado do que o diagrama apresentado na Figura 1. Considerando, desta maneira, um evolução do modelo.
  Modelo Conceitual do Diagrama de Classes (abstração nível 02)

O diagrama da figura acima apresenta um modelo mais apurado do diagrama de classes, entretanto, trata-se ainda de um modelo conceitual, pois, as inclusão das operações e outros atributos ainda não foi considerada na totalidade. Quando a evolução do diagrama de classes obtiver um resultado satisfatório ele deixa de ser um modelo conceitual e passa a ser um representação completa da arquitetura de objetos de dados do sistema e, neste momento, ele é incluído como artefato (diagrama de classes) da disciplina de Análise e Design.

Organização Física do Diagrama Conceitual de Classes

Ao especificar um diagrama conceitual de classes é conveniente atentar para os seguintes itens:

• Dê-lhe um nome capaz de comunicar seu propósito.
• Distribua seus elementos para minimizar o cruzamento de linhas.
• Organize seus elementos espacialmente, de maneira que classes relacionadas entre si apareçam fisicamente próximas.
• Use notas explicativas e cores como indicações visuais e chamar atenção para características importantes do diagrama.