Introducción al Diseño orientado a objetos

¿Un pequeño cambio en el software provoco defectos en los cambios de otras partes del código?

​¿Fue difícil reutilizar tu código?

​¿Fue difícil mantener el software después del lanzamiento?

​Proyectos anteriores

¿Tenían un buen diseño?​

¿​Podría haberse realizado mejor?

​¿Hubo algún diseño en absoluto?

¿Cómo sabes si el software estuvo bien diseñado?​

Cuando comenzaste no estabas seguro de cuales eran las funcionalidades.

​Recién empezaste a codear.

​No importa que el código estuviera desorganizado, porque eras el único que lo usaba y tú sabes como funciona.

​Se te ocurre una nueva característica para el programa, pero al implementarlo, rompió el programa en otro lugar

Desarrollo de proyecto personal:

Te unes a un proyecto que se has estado en desarrollando por algún tiempo.

Miras el código y te ven inmediatamente abrtumado.

No se puede decir cuál es el propósito de las piezas, las cosas no están organizadas y la documentación del diseño existente no existe.

No sabes donde empezar.​

Signos de un mal diseño:

Diseño: Se preocupa de los aspectos de bajo nivel del sistema.

Arquitectura: Se preocupa de los aspectos de alto nivel del sistema.

Diferencias

​Características como el tamaño de la empresa.

​El alcanace del proyecto.

​La experiencia del equipo de deasrrollo.

La estructura organizcional​.

La edad de la empresa.​

Arquiteco/Diseñado

​¿Por qué el diseño de software es importante?

​

En muchos casos el cliente no conoce realmente lo que quiere.

Vienen con un vago sentido de que pudieran estar haciendo las cosas mejor.

Entender el problema

Tendencias por el cliente de tener su software en el menor tiempo posible.

​Tendencia por el equipo de crear un software robusto, completamente diseñado e implementado.

​Velocidad vs Calidad

Simplicidad.

"Si es fácil de explicar, debiera ser fácil de programar".

Capacidad de transferir conocimientos​.

​Principios

Debe ser el puente entre los clientes y el equipo de trabajo.

Capacidad de comunicación.​

​Rol del Dis/Arquitecto

Tener la capacidad de comunicar en lenguaje de lógica del negocio con los clientes y en código con los desarrolladores.

Lograr extraer los reales requisitos​.

​Habilidades Blandas

Tener conocimiento técnico.

Mantenerse actualizado de las últimas tecnologías.

Tener la capacidad​ de observar e identificar como ciertas herramientas son más efectivas para resolver ciertos problemas.

​Habilidades Duras

Mira la imagen, ¿Qué ves?

​

​Pensemos en objetos

Esto permite que fácilmente se pueda cambiar los detalles de manera modular.

Al ser modular permite reutilizar código de manera más simple.​

Mantiene tu código organizado, flexible y reutilizable.

Detalles relacionados y funciones específicas en lugares distintos fáciles de encontrar.​

​Observemos nuestro al rededor, ¿Qué más podemos integrar en el pensamiento orientado a objetos?

Replace this with a sub-header that can be in multiple lines. ​

Proceso iterativo, ​que con cada iteración toma requisitos a través de una implementación operativa probada y eventualmente construyendo una solución.

​Proceso de desarrollo de un software

​

La evidencia reconoce que lanzarse directamente a la implementación es la razón principal de los fracasos en el desarrollo de software.

Hacer preguntas sobre problemas que el cliente puede no haber considerado​.

​Tips:

Muchos programadores están ansioso por ir directamente a la codificación, sin entender completamente que programar en primer lugar.

Tener Cuidado:

​Deseño conceptual y Técnico

Pongamos el ejemplo de diseñar una casa.

Antes de ​sentar las bases primero debes entender lo que quiere el propietario. (Obtención de requisitos).

​El propietario quiere una casa de una sola planta. Necesita tener un gimnasio, un baño, tres dormitorios y una sala de estar.

El proceso de obtención de requisitos no solo implica escuchar sino también realizar preguntas.

​

​Deseño conceptual y Técnico

¿Cree que necesitará un baño?

¿​Las habitaciones deben ser del mismo tamaño?

¿Cuál debería ser más grande o más pequeña?​

​¿Qué tan grande debe ser la casa en general?

​¿Hay restricciones de diseño externas? (Ej. Por la comunidad)

Diseñar cómo se cumplen estas responsabilidades son el objetivo del diseño técnico.

Detalles técnicos de cada componente.​ Esto se realiza dividiendo los componentes en más pequeños que son los suficientemente específicos como para ser diseñados en detalle.

​Diagrama Técnico

Ideas iniciales que cumplirán los requisitos.

Componentes​ y C​onexiones.

Aplazar los detalles técnicos.

Cada componente tiene una tarea a realizar llamada responsabilidad.

Maqueta conceptual

Supongamos que nos piden diseñar una página que nos permita encontrar los cursos de una carrera en particular.

¿Cómo lo diseñamos?​

​

​¿Cómo resultaría en una página web?

Continuará...

​La página Web.

Los cursos.​

​Componentes:

Responsabilidades:

Buscar.

​Dibujemos...

​¿Cómo se introduce una palabra clave de búsqueda?

​¿Cómo se inicia la búsqueda?

​¿Cómo se muestra la lista de resultados de búsqueda?

​

​Estos defectos en la maqueta inicial requieren de más aclaraciones del cliente y/o más trabajo de diseño conceptual.

​

​Dibujemos nuevamente...

Se reconocen varias conexiones.

Para que la página ​de búsqueda cumpla su responsabilidad de buscar necesita un Campo de entrada, botón de búsqueda y página de resultados.

Esto también se traduce a que la página de ​búsqueda tiene conexiones con los campos de entrada, el botón de búsqueda y la página de resultados.

Respondemos a la pregunta:

¿Cómo los componentes, conexiones y responsabilidades podrán ser implementados?

Por ejemplo:​

Refinar cada componente hasta que sea lo suficientemente específico como para ser diseñado en detalle.

​

¿La página necesita comunicarse con un sistema externo?​

​Supongamos que la entidad educativa ya tiene una base de datos de cursos a la que se puede conectar la página de búsqueda.

Dado que la página de búsqueda requiere conectarse a la Base de datos ​para cumplir con su responsabilidad de búsqueda, existe una conexión entre estas dos.

Esto ya no se puede resolver en la maqueta conceptual ​ya que ahora estamos diseñando componentes de software internos, por lo tanto debe ser descrito en el diseño técnico.​

¿Al refinar lo suficiente un componente en que se vuelve?​

​Los componentes se transforman en colecciones de funciones, clases y otros componentes.

Estas piezas representan un problema mucho más pequeños que los desarrolladores pueden individualmente implementar.

​Reflexión...