En caso de que un desarrollador se adhieren a los diagramas de clases producido durante el diseño del sistema?

Question

El diagrama de clases se modela sobre los requisitos del sistema, y ??es importante para crear soluciones basadas en dichos requisitos. Si he dicho diagrama de clases que debe adherirse estrictamente a ella? ¿Qué hay de refactorización? ¿Qué pasa si el diagrama no proporcionó algún principio de diseño que me siento quedaron fuera?

Answer 1

Respuesta corta: No.

(Esperemos probado) código

Su salida debe estar trabajando que realiza la función de negocios se supone que debe hacerlo. La forma de realizar esa tarea no debe ser obligatorio (de nuevo, a menos que trabaje para la NASA).

Una analogía cojos: me meto en un taxi y les digo dónde ir. Lo dejo hasta que me conducir allí. Confío en ellos para que me allí con seguridad y de manera oportuna. No voy a sentar y microgestión el taxista y le diga cuándo activar el intermitente, ¿cuánto para presionar el acelerador, o cuando para obtener gas. Ese es su trabajo.

Answer 2

Usted tiene diagramas de clases en sus necesidades? Debe ser parte de una especificación, no sus necesidades, pero supongo tiendas de todos son diferentes;) Es importante cumplir con sus especificaciones. Si no lo hace, es posible que impacte otra área de la aplicación sin saberlo cuando se desvía. Si la especificación es incorrecta, volver a abrirlo, comunicar el cambio y que sea revisada y luego cambiar el código. Incluso cuando no está de acuerdo. Usted no puede saber todas las razones una implementación fue elegido sobre otro.

Answer 3

Los siguientes puntos se presentan para su consideración antes de tomar su decisión, la idea es examinar los factores que afectarían generalmente un caso como el suyo.

Punto 0: Es necesario aplicar todas las reglas de negocio sea cual sea su estilo de ejecución podrán ser

.

Punto 1: En UML, diagramas de clase son sólo una parte de todo el modelo. Hay otros esquemas que utilizan las clases definidas como casos de uso, secuencia, etc.

Punto 2: En aplicaciones OO utilizando RDBMS que necesita para decidir si su aplicación se construye a partir de un objeto o una primera aproximación de Datos primer enfoque. Con base en este modelo de dominio se construye. Los dos tipos de modelo pueden ser muy diferentes. Ver: relacional de objetos Imp. Missmatch .

Punto 3: En OO y parcialmente como resultado de punto # 3, los objetos que representan la capa de base de datos puede ser diferente de los objetos que se utilizan en las demás capas o servicios de aplicación. Si está utilizando los servicios web, entonces es probable que la API podría incluso definir objetos de una manera diferente de lo que la definición capa de negocio y la definición capa de datos.

punto 4: modelos UML tienen fases, por lo general definidas por una metodología que en Asignación de modelos a Dev. Procesar , cada fase puede producir un modelo diferente. Cambio de un modelo de fase de aplicación es, por supuesto, la menos deseable y más crítica debido a su impacto.

Punto 5:. Usted debe considerar el impacto del cambio en la fase del ciclo de vida del proyecto, sus datos existentes en su caso y en otros trabajadores compañeros y administradores de bases