Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Haga coincidir el principio con su respectiva descripción y corrija la descripción en caso de ser necesario.
Principio Enunciado
A - SRP - Single Responsibility Principle 1-Habla sólo con tus “conocidos”, para mantener bajas las
dependencias.
B – Alta cohesión 2 - "Las responsabilidades de una clase, interface o subsistema,
deberían estar muy estrechamente relacionadas entre sí".
C- Deméter 3 - "Una clase debería tener solo una razón para cambiar"
Principio Enunciado
A - SRP - Single Responsibility 1 - "Diseñar hacia las interfaces y no hacia las implementaciones.”
Principle
B- OCP - Open/Closed Principle 2 - "Una operación se debe encargar de una sola responsabilidad, de un solo
tipo de cosas”
D – Desing to Interface 3 - “Al diseñar una solución, se deben dejar puntos abiertos para modificar el
código cuando aparezcan nuevos cambios y cerrado para las extensiones”
Algoritmo1EntradaTexto Algoritmo2EntradaVisual
Iniciar() Iniciar()
RecibirEntradaUsuarioConsola() RecibirEntradaUsuarioPantalla()
InicializarEstructurasAuxiliares() InicializarEstructurasAuxiliares()
CorrerAlgoritmo() CorrerAlgoritmo()
Paso1Algoritmo() Paso1Algoritmo()
Paso2Algoritmo() Paso2Algoritmo()
OptimizaciónTipo11() OptimizaciónTipo22()
AlmacenarResultadosBD() AlmacenarResultadosBD()
Solución:
b) Principios de diseño que pueden estar en la nueva solución: La solución vamos a separarla en dos
partes, solución del acoplamiento de las soluciones con GESTUD (única solución con el recurso de
estudiante) y la segunda parte cambios que se tendrían que introducir en siguen, para que la solución
considere principios de diseño que se están violando.
Segunda parte
Con el objetivo de diseñar teniendo en cuenta los principios de diseño que se están violando podríamos:
INGENIERÍA DE SOFTWARE 2 CURSO 2020-21 CURSO DIURNO
Once & Only One rule: Un fichero de recurso, donde estableceríamos el puente de conexión, de
tal manera que cada vez que se acceda a la BD se busca en un único lugar.
Single responsibility: Las clases controladoras solo se dedicarán a la lógica de negocio, el
acceso a los datos estará en otro lugar.
Encapsular la variabilidad: Diseñaríamos un mecanismo de diseño de acceso a datos,
garantizando separar los elementos variables de los no variables.