Modelando um sistema depois de definir o caso de uso da UML

Question

...Qual é o próximo?

Depois de definir quais atores fazem quais ações, para que caminho você vai? Você modela o banco de dados ou prefere começar com as classes?

Eu pensei que a melhor abordagem era começar com um diagrama de modelagem semelhante a uma classe, focar nos relacionamentos entre objetos. Isso provou estar errado porque eu fui muito profundo em detalhar aulas e, mesmo que o sistema "parecesse funcionar", quando fui à modelagem de banco de dados, tudo simplesmente não se encaixaria naturalmente nas posições que escolhi na fase anterior.

Eu li sobre as pessoas dizendo que se deve colocar a lógica do aplicativo em um banco de dados e aproveitar sua velocidade na recuperação de dados, opostos à construção de objetos grandes na memória que são consultados e fornecem abstração do banco de dados subjacente. Eu sempre pensei que o banco de dados existe para armazenar meus dados e fornecer uma maneira rápida de acessá -los. Mas talvez eu esteja errado, quero dizer, eu realmente tenho que criar um banco de dados que tenha dentro da mesma lógica que eu colocaria em um grupo de classes? O banco de dados não possui as ferramentas para conseguir isso?

Acho que estou falhando em identificar o ponto certo por onde começar, se eu optar por começar com o banco de dados, acho difícil não apenas pensar nisso como um "local para armazenar meus dados, vamos fazer a lógica do aplicativo em um nível superior "Coisa, se eu começar com as aulas, o banco de dados acaba parecendo uma representação não natural das classes, sinto a sensação de perder algo importante, algo como não atribuir o objetivo certo para a ferramenta certa.

Como você lida com isso? Quando se trata de decidir se começar a modelar o banco de dados ou as classes, em sua experiência, que tipo de abordagem provou levar a uma implementação natural e limpa?

desde já, obrigado

Answer 1

Eu tive sucesso usando Análise de robustez.

Este artigo se concentra na análise de robustez, que envolve a análise do texto narrativo dos casos de uso e na identificação de um conjunto de objetos de primeira adivinhação que participará de cada caso de uso e, em seguida, classificar esses objetos em três tipos:

1. Objetos de limite, que os atores usam na comunicação com o sistema.
2. Objetos de entidade, que geralmente são objetos do modelo de domínio (o sujeito do "design de direção: o domínio do problema", janeiro de 2001).
3. Objetos de controle (que geralmente chamamos de controladores porque geralmente não são objetos reais), que servem como a "cola" entre objetos de limite e objetos da entidade. Figura 1 mostra os ícones visuais para esses três tipos de objetos.

Os objetos da entidade são os que (geralmente) acabam no banco de dados/

Ao mapear entre classes e o banco de dados, eu recomendaria Artigo de S.Lott sobre "O Orm Problem" (Ele também é participante do Stackoverflow

Answer 2

Se estiver usando o desenvolvimento orientado a testes, escreva seus testes de unidade primeiro. Suas aulas serão descritas à medida que você avança.

Você pode optar por desenvolver sua lógica de negócios sem um banco de dados (objetos simulados ou stub) ou desenvolver seu banco de dados à medida que continua com seus testes.

Lembre -se de que o seu banco de dados e modelo de domínio não devem mapear um um um com o outro.