Resumen
miércoles, 13 de noviembre de 2024 01:19
Workflow de diseño:
- propósito
- diferencia con el de análisis
- modelos que se construyen
- diagramas de UML que se usan
principios de diseño
patrones de diseño
diseño de persistencia
evolución de software <---- lo vemos el jueves
WORKFLOW DE DISEÑO
Propósito: proceso en el que se aplican técnicas y principios para definir un dispositivo, proceso o sistema con el suficiente nivel de detalle para permitir su realización física. Se trata de un
proceso iterativo, que se encarga de la solución de aspectos que tienen que ver con la implementación, es decir que es en donde se empieza a trabaja con los RNF y que busca transformar
un modelo lógico (como lo es el modelo de análisis) en un modelo físico que respete las restricciones del negocio.
Diferencia con el Workflow de Análisis
Modelo de Análisis Modelo de Diseño
Tipo de modelo Modelo lógico, es una abstracción del sistema Modelo físico, es un plano de la implementación
Genérico, es aplicable a varios diseños No genérico, es específico para una implementación
Menos formal Más formal
Menos caro de desarrollar Más caro de desarrollar
Dinámico sin centrarse en la secuencia Dinámico muy centrado en las secuencias
Bosquejo del diseño del sistema Manifiesto del diseño
Puede no estar mantenido durante todo el ciclo de vida del software Debe ser mantenido durante todo el ciclo
Entrada fundamental para modelar el sistema Da forma al sistema manteniendo la estructura definida en el análisis
Modela la solución lógica. Se ocupa de la funcionalidad Modela la solución física. Se ocupa de los aspectos de la implementación
Modelos que se construyen
Diagramas de UML y Artefactos del modelo (artefactos no se si va)
- Modelo de diseño: Es una jerarquía de subsistemas de diseño que contienen clases de diseño, realizaciones de casos de uso– diseño e interfaces. Se trata de un modelo de objetos que
describe la realización física de los casos de uso, centrándose en cómo los RF, RNF y las restricciones de implementación tienen impacto en el sistema. Es una entrada fundamental de
las actividades de implementación. Describe como los requerimientos funcionales y no funcionales tienen impacto en el sistemaa considerar. Sirve como una primera abstracción al
modelo de implementación. Los diagramas utilizados son: diagramas de clases de diseño generalmente, diagramas de componentes,etcétera.
- Clase de diseño: clases cuyas especificaciones tienen el suficiente nivel de detalle como para poder implementarse. Son especificadas mediante un lenguaje de programación, por lo
que las operaciones, atributos y parámetros están especificados en base a la sintaxis del lenguaje de programación elegido, junto con la visibilidad de los atributos y operaciones.
Además estas clases tienen que ser completas y suficientes (proporcionan lo que se espera y nada más), sencillas (ofrece un servicio sencillo) y contar con alta cohesión y bajo
acoplamiento. Este artefacto se ve plasmado en los diagramas de clases de diseño.
- Realización de CU de diseño: describe cómo se realiza un CU específico, y cómo se ejecuta en términos de clases de diseño y sus objetos. Cuenta con una descripción textual que
muestra el flujo que tiene el CU y su desarrollo, un diagrama de clases que especifica las clases de diseño participantes y un diagrama de interacción que muestra la secuencia de
interacciones entre los objetos junto con los mensajes que estos se envían entre ellos.
- Subsistema de diseño: forma de organizar los artefactos en piezas más manejables. Estos deben ser altamente cohesivos y tener bajo acoplamiento (dependencia mínima entre ellos).
Existen dos formas de obtener los subsistemas, una puede ser como una forma de dividir el trabajo, y la otra es que a medida que la evolución del desarrollo del software avance se
vean obligados a dividir la estructura. Los diagramas en los que estos artefactos están presentes son los diagramas de componentes.
- Interfaz: especifica que operaciones tienen que definir las clases y subsistemas de diseño que implementen esa interfaz. Constituyen una forma de separar la funcionalidad de la
operación de su implementación. Estos artefactos se ven en los diagramas de componentes.
- Descripción de la arquitectura (vista del modelo de diseño): contiene la vista arquitectónica del modelo de diseño que refleja los artefactos más importantes para la arquitectura como
subsistemas, interfaces y sus relaciones, y clases de diseño significativas. Dentro de esta vista se ilustra para la parte estática un diagrama de componentes, y la parte dinámica un
diagrama de secuencia.
- Modelo de despliegue: distribuye la funcionalidad del sistema como un conjunto de nodos en una red, reflejando cuantos se necesitan y sus relaciones.
- Descripción de la arquitectura (vista del modelo de despliegue): refleja la vista arquitectónica con una vista de despliegue, mostrando los artefactos más importantes mediante un
conjunto de nodos, incluyendo la correspondencia de los componentes sobre los nodos tal como se identificó durante la implementación.
Nueva sección 1 página 1
Diagramas de UML utilizados en el Workflow para construir los modelos:
- Diagrama de Actividad
- Diagrama de Secuencia
- Diagrama de Descripción de Interacción
- Diagrama de Timing
- Máquina de Estados
Diseño dentro del ciclo PUD
Hace foco principal en las últimas iteraciones de la fase de elaboración y el comienzo de las iteraciones de la fase de construcción. Esta participación se da, principalmente, cuando la
estructura planteada en el análisis es lo suficientemente estable. En la fase de elaboración contribuye a una arquitectura estable y robusta. Mientras que en la fase de construcción crea un
plano para la implementación.
Pregunta:
- En el contexto del PUD: describa en qué consiste el modelo de diseño, cuáles son los diagramas de UML que se utilizan para construir los artefactos del modelo y destaque cuáles son
las diferencias con el modelo de análisis.
PRINCIPIOS DE DISEÑO
1. DRY (no te repitas): orientado a realizar abstracciones para evitar redundancias. Esto ayuda al mantenimiento del software y el código.
2. SoC (separación de intereses): dividir en secciones o componentes para que cada una se encargue de distintas cosas, logrando una estructura más organizada y fácil de mantener. Esta
división puede ser a nivel de arquitectura en capas, o a nivel de programación separando los servicios en distintos niveles. La diferencia con el principio SRN es que operan a distintos
niveles de abstracción
3. KISS (mantenlo simple): se basa en no agregar complejidad, ni funciones o abstracciones que no necesitas para facilitar el desarrollo, comprensión y mantenimiento del sistema.
4. Principle of least knowledge (principio de menor conocimiento/no hables con extraños): se basa en que un objeto interactúe solo con los que conoce de manera directa para evitar alto
acoplamiento y mejorar la modularidad de forma que los cambios en una parte del código no afecten tanto a otras.
5. TDA (Tell, don't ask): se basa en pedirle a otro objeto que lo resuelva, en otras palabras delegar responsabilidad. Aplica elpolimorfismo.
6. Programar hacia la interfaz:
7. Composite reuse: se basa en utilizar composición que representa la relación "tiene un" entre clases en vez de herencia ya queel último obliga a la clase hija a implementar métodos
que capaz no use. La ventaja de composición es que puede sustituir un comportamiento durante el tiempo de ejecución.
8. YAGNI: se basa en no agregar funcionalidades que no se necesitan en el momento para mantenerlo sencillo, fácil de mantener, yevitar complejidad innecesaria.
PRINCIPIOS SOLID
- SRN (responsabilidad única): cada clase tiene una sola responsabilidad. Reduce la complejidad y logra una alta cohesión
- OCP (Open-Close): una clase está abierta a la extensión (agregar nuevas clases, subclases, relaciones) pero cerrada a la modificación (no se puede cambiar el comportamiento), asi
evitamos modificar lo que ya anda.
- LSP (Liskov Sustitution): cuando tenemos una subclase, esta debe permanecer compatible con el comportamiento de la superclase. Al sobrescribir un método, extiende el
comportamiento base en lugar de sustituirlo con algo totalmente distinto.
- ISP (segregación de interfaces): dice que las interfaces no tienen que estar muy cargadas. Si ese fuera el caso se tienen quesegregar (dividir) en interfaces más específicas y con menos
métodos así las clases que las implementan, no tienen un montón de métodos al pedo.
- DIP (inversión de dependencia): busca que las clases de bajo nivel (realizan funcionamientos básicos) dependan de las clases de alto nivel (tienen la lógica de negocio y son
responsables del funcionamiento), por lo que la solución que brinda este principio es crear interfaces.
Nueva sección 1 página 2
PATRONES DE DISEÑO
Patrones de comportamiento
- STATE: relacionado al principio DRY, Single Responsability, Open-Close, Liskov Sustitution
STRATEGY: aplica el principio Favorecer la composición sobre la herencia (Composite reuse), Open-Close, segregación de interfaces
ADAPTER: aplica el principio Single Responsability, Open-Close, segregación de interfaces
ITERATOR: aplica el principio Single Responsability, Open-Close, segregación de interfaces
OBSERVER: Open-Close, segregación de interfaces
DISEÑO DE PERSISTENCIA
La persistencia es la capacidad de almacenar los datos y objetos una vez que termina la ejecución. La persistencia frecuentemente significa que los objetos se copian desde una memoria
primaria y volátil a una memoria secundaria, lenta y persistente.
EVOLUCIÓN DEL SOFTWARE
Nueva sección 1 página 3
