oop - orientada - ventajas y desventajas de la programacion estructurada

Problemas de diseño OOP en las entrevistas (4)

Soy un desarrollador de software con una experiencia de 2 años. He participado en el diseño y desarrollo de varios módulos "pequeños".

He estado dando entrevistas técnicas últimamente. Se me ha pedido que modele el diseño de varios problemas (por ejemplo, Apple Genius Recommendation System, etc.). Mi experiencia hasta ahora ha sido desarrollar módulos relativamente pequeños. Quiero mencionar cómo abordo los problemas de diseño en la mano:

(1) Reconocer el caso de uso más esencial.

(2) Haga un modelado dinámico (como un diagrama de colaboración) para modelar el sistema en base al comportamiento

(3) Dibuje un diagrama de clases basado en el modelado dinámico hecho en el paso 2.

(4) Descubra más casos de uso e itere este proceso.

(5) Cuando estoy satisfecho, le pido a mis compañeros que lo revisen.

Aunque hasta ahora he hecho lo justo en mis proyectos, pero los entrevistadores no están muy contentos con este enfoque. ¿Me estoy perdiendo algo ya que estoy modelando un gran problema?

Apreciaré cualquier puntero.

PD: No empiezo con el diagrama de clases porque encuentro una arquitectura muy centralizada al hacerlo, mientras que el modelado dinámico me ayuda a descentralizar el diseño.

De lo que deduzco de su pregunta es que está pidiendo un " modelo " y no la " metodología " o " proceso " como lo ha descrito.

Por lo tanto, todo lo que tienen que hacer es diseñar (probablemente usando UML) un escenario en el que el sistema de recomendaciones de Apple Genius pueda manejar varios problemas. Sugerencia, si este es el caso, la parte principal del diseño es tener una interfaz llamada Problema con los métodos de interfaz del núcleo que está relacionado con el problema. Por ejemplo, getSeverity , getDescription , getDateReported , getDateSolved , etc. Naturalmente, necesitarán otras clases que colaboren con esta interfaz para completar el diseño.

Espero que lo anterior te ayude.

Creo que su enfoque podría pasar por alto los requisitos no funcionales . También mencionaría cómo se pueden capturar.

¿Le han pedido un diseño de modelo de alto nivel (módulo) o un diseño de modelo de bajo nivel? Enfrentarse a un gran problema o dominio para el diseño de modelos de alto nivel es una buena idea, ya que para el diseño de modelos de bajo nivel generalmente se necesita un problema o dominio más pequeño.

Por lo general, el requisito / problema proviene del solicitante (usuario / entrevistador) por lo que ya no es necesario definir el requisito comercial. Pero todavía tenemos que diseñar el sistema.

Modelo de alto nivel

No estoy muy familiarizado con el "Sistema de recomendaciones de Apple Genius", así que usaré una analogía de problema diferente, ese es el problema común de Point Of Sales . Para el modelo de alto nivel, definirá todo el sistema. Usualmente sobre:

ordenando
orden de compromiso
pago inicial
entrega de la mercancia
regreso

Eso es todo modelo / módulo de alto nivel. Si me preguntan cómo puedo lograr el modelo, aquí están los pasos que voy a hacer:

Definir el caso de uso estándar entre el usuario y los sistemas
Vierta los casos de uso en algún diagrama colaborativo, como una imagen enriquecida (o algo familiar)
Defina los casos de uso de excepciones. Si las excepciones se pueden definir fácilmente, póngalo inmediatamente para modelar. De lo contrario, marque el modelo con las excepciones del caso para analizarlo más a fondo con los equipos comerciales
algunas excepciones de casos de uso pueden estar cambiando la orden comprometida, cambiando la orden comprometida después del pago inicial, cancelando la orden pagada, bienes sin stock, etc.
Itera el proceso. Por lo general, el paso 3 puede convertirse en el paso 1 (la excepción puede / será otro caso de uso)
por ejemplo, el cambio del orden comprometido puede ser un caso de uso, ya que el cambio de ocurrencia es alto.
Cuando el tercero se completa sin excepciones de casos de uso adicionales (se ha manejado todo el caso de uso), generalmente agrego value-additional operations .
Esas operaciones pueden ser notificación (correo electrónico / en pantalla), mantenimiento de datos históricos, recordatorio, manejo de errores, etc. Algunas operaciones también pueden ser otro caso de uso, por lo que tal vez necesite iterar a no.1.
Algunos ejemplos, tal vez cuando recibe un error durante la liquidación del pago inicial, tal vez necesite otro caso de uso para ingresar los datos de anticipo de forma manual. O tal vez necesitará mantener el sistema de recordatorio en otro sistema.
Mover al modelo de bajo nivel

Para información adicional, usualmente uso el diagrama de estado para casos de uso / funcionalidad, como el estado del pedido.

Modelo de bajo nivel

El modelo de bajo nivel abordará problemas más pequeños desde un nivel alto. Fácilmente dicho, toma un caso de uso de alto nivel (tal vez ordenando) y comienza a diseñar un nivel bajo a partir de él. En lugar de definir primero el diagrama de clases, suelo abordarlo con algún tipo de diagrama de secuencia . Aquí hay algunas razones por las cuales:

secuencia le da vista de concurrencia acerca de obtener la entrada, obtener datos y dar respuesta
Proporciona una buena imagen de las relaciones con otros sistemas, como la base de datos y el servicio web
Puede darle imágenes sobre el punto de entrada o la interfaz, en el que puede ser muy útil para la arquitectura básica de sus aplicaciones
Puedes basar tu diagrama de clases y encontrar las dificultades fácilmente durante el diseño de la secuencia en lugar del diagrama de clases

Luego continuaré con el diagrama de estado del sistema (editable, visible, etc.).

Por último, continuaré con el database design de database design y el class diagram .

¿Por qué el diagrama de clases está en el último paso?

El diagrama de clases (y el diseño de la base de datos) es muy dependiente de todo su proceso. Cómo se produce la concurrencia, las notificaciones, las interacciones del sistema externo, etc. pueden afectar el diseño de las interfaces y el diagrama de clases. También es el diseño más cercano con su código base.

Espero esta ayuda y esta es completamente mi experiencia y opinión.

Diría que tal vez se espera que proporciones una perspectiva / visión general general y luego profundices. Al igual que en el ejemplo que le da al "Sistema de recomendaciones Apple Genius", creo que debe comenzar con un diseño general (la imagen general del sistema), para determinar una arquitectura adecuada para el sistema, por ejemplo, determinar qué componentes son necesarios. , qué protocolos, etc. Necesita identificar componentes, conectores y la configuración de tesis. Entonces, puedes comenzar a profundizar sugiriendo patrones y herramientas. Finalmente, valide la arquitectura con escenarios, casos de usuarios, etc.