O projeto de sistemas orientados a objetos define diversas fases para o desenvolvimento de um software, e quando aplicadas a uma metodologia específica, define divisões de tempo para que cada uma dessas fases seja desenvolvida.
O processo utilizado para o projeto de sistemas orientados a objetos é conhecido basicamente como ADIT (Analise, Desenho, Implementação e Testes), conceito proposto por Winston W. Royce (1929–1995) que devido ao paradigma procedimental usado na época, não obteve grande sucesso em sua aplicação, mas que anos mais tarde com a criação do paradigma de objetos possibilitou sua utilização.
Todas essas quatro fases são extremamente importantes, mas a principal e que exige mais atenção, é a fase de análise, pois ela trata da descoberta de conceitos (ou objetos) do domínio do problema que irão definir nossas tomadas de decisões durante as outras fases do projeto, gerando documentos que nos possibilitam a compreensão do comportamento que o software deverá desempenhar.
Durante a fase de análise geramos alguns artefatos importantes, tais como: casos de uso, modelos conceituais, glossários, diagramas de sequência do sistema, contratos de operação e diagramas de estado, que além de servirem como documentação contribuem para um aumento do conhecimento do domínio do problema, por isso, devemos frisar que uma boa analise irá refletir diretamente em nossas tomadas de decisões, descobertas de requisitos, modelagem do software e na criação de um bom projeto como um todo.
Entre os artefatos citados temos o modelo conceitual, que em “Utilizando UML e Padrões”, que é considerado leitura essencial para quem pretende seguir a carreira de Engenheiro de Software, Larman o descreve como uma representação de conceitos ou de objetos no domínio do problema.
Sendo assim, um modelo conceitual deve ilustrar os conceitos mais significativos do domínio do problema e por ser um artefato que tem como finalidade demonstrar aspectos relevantes relacionados a um determinado problema, faz dele o artefato mais importante a ser desenvolvido durante a fase de análise e projeto orientado a objeto. O tempo gasto no esforço para a criação de um modelo conceitual vale a pena se for comparado com o retorno que traz para o projeto do sistema, porém, deve ser controlado, pois em alguns casos podemos acabar gastando mais tempo do que necessário para o desenvolvimento de um modelo conceitual que deve conter apenas aspectos relevantes à concepção do domínio do problema.
Devemos ter em mente que um modelo conceitual não é um modelo do projeto de software, um modelo conceitual descreve as coisas como são no mundo real, no domínio do problema, que diferente de um diagrama de classes que descreve a relação entre as classes afim de contribuir na organização da escrita do código Orientado a objetos.
O modelo conceitual é exibido como um conjunto de diagramas de estruturas estáticas onde não são definidas operações, nele enfatizamos os conceitos, associações entre esses conceitos e os atributos desses conceitos no domínio do problema sem pensarmos em questões relacionadas ao software, pois isso será tratado exclusivamente durante a fase de desenho do modelo da aplicação.
Pensando no processo de desenvolvimento ADIT de maneira incremental e iterativa, podemos diversas vezes voltar ao modelo conceitual para aprimorarmos ou corrigirmos o que nele foi descrito, pois a cada iteração alcançada durante o desenvolvimento de software adquirimos um maior conhecimento relacionado ao domínio. Sendo assim não devemos nos esquecer de sempre manter o modelo conceitual atualizado, refinando-o e mantendo sua representação de conceitos do domínio do problema o mais próximo possível do mundo real para que contribua significativamente com a fase de desenho, aonde iremos de fato nos preocupar na maneira em que organizaremos nossas linhas de código.
Recomendo como leitura: “Utilizando UML e Padrões”, Craig Larman.
Abraços e até a próxima!
