Qualidade de Software Ltda

Neste artigo irei abordar as práticas e técnicas utilizadas para a elaboração do modelo de domínio para o desenvolvimento de software

Quando você está criando seu modelo de domínio, uma boa fonte de classes de domínio inclui a descrição de requisitos em alto nível, aqueles que são geralmente (mas nem sempre) escrito na forma "O sistema deve fazer isso, o sistema não deve fazer isso. " É útil verificar esses requisitos, extraindo os substantivos e frases substantivas. Você pode refiná-las para criar o modelo de domínio inicial. Com isso em mente, vamos percorrer os requisitos de alto nível para para o desenvolvimento de um software para uma Livraria Virtual, e e extrair as classes de domínio possíveis.

Passo 1 : Elencar os requisitos de alto nível para o software a ser modelado

1. A livraria vai ser baseada na Web

2. A livraria deve ser capaz de vender livros, com os pedidos aceitos através da Internet.

3. O usuário deve ser capaz de adicionar livros em um carrinho de compras on-line, antes do processo de checkout.
a. Da mesma forma, o usuário deve ser capaz de remover itens do carrinho de compras.

4. O usuário deve ser capaz de manter listas de desejos dos livros que ele quer comprar posteriormente.

5. O usuário deve ser capaz de cancelar as encomendas antes que eles sejam expedidas.

6. O usuário deve ser capaz de pagar com cartão de crédito ou boleto bancário.

7. Deve ser possível para o usuário devolver os livros.

8. O site da livraria deve ser embutido em sites de parceiros associados usando mini catálogos,
que são derivados de um catálogo global armazenado em um banco de dados central.

a. O mini-catálogos deve ser definido em XML, já que eles vão ser transferidos entre sistemas externos.

9. O usuário deve ser capaz de criar uma conta de cliente, de modo que o sistema armazene detalhes do usuário (nome, endereço e detalhes do cartão de crédito) no início da sessão.

a. O sistema deve manter uma lista de contas no banco de dados central.

b. Quando um usuário faz logon, sua senha deve ser sempre comparada com a
senhas na lista da conta principal.

10. O usuário deve ser capaz de procurar livros por vários métodos de pesquisa: título, autor,
palavra-chave ou categoria, e depois ver os detalhes dos livros.

11. Deve ser possível para o usuário publicar resenhas de livros favoritos; os comentários de revisão
deve aparecer na tela de detalhes do livro. A revisão deve incluir uma avaliação de cliente
(1-5), que normalmente é mostrada junto com o título do livro nas listas de livros.

a. As resenhas bibliográficas devem ser moderadas, isto é, verificados e aprovadas por um membro do
staff antes de serem publicados no site.

b. Comentários mais longos devem ser truncados na tela de detalhes do livro, o cliente pode
clicar para ler a revisão completa em uma página separada.

12. Deve ser possível para o staff publicar opiniões editorial de livros. Estes devem também
aparecem na tela de detalhes do livro.

14. A livraria deve ser escalável, com os seguintes requisitos específicos:

a. A livraria deve ser capaz de manter as contas de usuário para até 100.000
clientes nos seus primeiros seis meses, e depois desse período de 1.000.000 de contas.

b. A livraria deve ser capaz de atender até 1.000 usuários simultâneos (10.000
após seis meses).

c. A livraria deve ser capaz de acomodar até 100 solicitações de pesquisa por minuto
(1.000 / minuto, depois de seis meses).

d. A livraria deve ser capaz de acomodar até 100 compras por hora
(1.000 horas / depois de seis meses).

Passo 2: Análise textual dos requisitos em alto nível – identificar classes de domínio candidatas

Realizar uma análise textual  dos requisitos de alto nível, para identificar os substantivos e registrá-los na tabela abaixo

Passo 3: Analisar quais substantivos representam verdadeiramente uma classe de domínio

Após identificar as classes candidatas a partir dos requisitos de alto nível, o próximo passo é o de analisar quais representam verdadeiramente uma classe do sistema.

Como nós identificamos qual desses nomes candidatos realmente descreve classes no nosso domínio de problema? Uma abordagem muito utilizada é desafiar a nome candidato a algumas questões conforme mostrado a seguir:

1. O nome candidato está dentro das fronteiras do sistema? Se não, ele deve ser um ator do seu sistema

2. O candidato tem um comportamento identificável no domínio do problema (exemplo: nos podemos dar nomes aos serviços ou funções que são necessários no nosso domínio do problema, e que esse candidato irá ser o dono e prover o serviço ou função?)

3. O candidato possui uma estrutura identificada? (exemplo: é possível identificar algum conjunto de dados que esse candidato irá possuir e manipular?)

4. Esse candidato tem relacionamentos com outros candidatos?

Deccorrente dessa análise obtem-se os seguintes resultados:

a. Usuário e Cliente possuem o mesmo significado e representa um ator do sistema e deve ser utilizado nos diagramas de casos de uso

b. Cliente e conta de cliente não são duplicidades e representam coisas diferentes. Conta do cliente é uma entidade que será armazenada no banco de dados. Já cliente ou usuário é um ator.

c. Conta do cliente e conta do usuário são duplicidades, e será mantido conta do cliente

d. Os termos lista de contas e lista de contas principal são duplicidades, e será mantido apenas lista de contas principal.

e. Os termos resenha bibliográfica e comentário de revisão são duplicidades, e será mantido apenas comentário de revisão.

f. Temos diversos termos candidatos a catálogo ou lista de livros: Lista de livros; mini-catálogo; catálogo global. Catálogos e listas são provavelmente conceitos diferentes. Parece que o texto está tentando nos dizer alguma coisa. Quando houver dúvida, pergunte ao cliente até obter um entendimento claro sobre a questão.

g. Lista de livros é provavelmente um termo guarda-chuva para diferentes tipos de listas. Vamos mantê-lo e verificar como ele se sai no desenho do diagrama de domínio

h. O termo internet é muito genérico e não acrescenta algo no modelo de domínio

i. O termo password não representa um objeto e deve ser um elemento de tela, portanto será removido. O mesmo se aplica para título e palavra-chave.

j.Livro e detalhes dos livros são duplicidades. Vamos manter apenas livros.

k.O termo item é vago e confuso mas representa um conceito válido: um item que foi adicionado ao carrinho de compras do cliente. Vamos mudar o nome para item do carrinho e mantê-lo na lista.

l.O termo livraria é muito abrangente e está fora do modelo de domínio.

A partir dessa análise elabora-se uma segunda tabela contendo as classes candidatas de domínio

Passo 4: Desenhar a primeira versão do modelo de domínio

A partir da tabela do passo 3, desenhar o diagrama de classes de domínio do sistema de livraria virtual. Utilizar o relacionamento de agregação (tem um) entre as classes de domínio

Aguarde segunda parte desse artigo, onde será detalhado os passos necessários para o refinamento do modelo de classes.

Artigo adaptado do livro Use Case Driven Object Modeling with UML, Theory and Pratice. Doug Rosenberg e Matt Stephens

Artigo adaptado de texto Geetting from use case to code, Part 1, disponível em http://www.ibm.com/developerworks/rational/library/5383.html

Related posts:

1. Piores práticas para o desenvolvimento de software – Parte 2 de 2
2. Sete erros mais comuns ao se escrever casos de uso