Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Diseño > EX2 > Flashcards

EX2 Flashcards

1
Q

Dependencia

A

No tiene relación estructural
No es todo/parte
No esta contenido
———–>

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Asociación

A

Si tiene relación estructural
No tiene todo/parte
No esta contenido
->

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Agregación

A

Si tiene relación estructural
Si tiene todo/parte
No esta contenido
rombo sin relleno

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Composición

A

Si tiene relación estructural
Si tiene todo/parte
Si esta contenido
rombo relleno
la parte no puede existir fuera del contexto del todo

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Abstracción

A

Determinar características de un ente al mismo tiempo que se desechan carácteristicas que no son de interes

Volver algo mas especifico

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Alto nivel de abstracción

A

Poco detalle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Bajo nivel de abstracción

A

Alto detalle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Acoplamiento

A

Medida de interconexión entre los componentes

Baja es mejor

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Encapsulamiento

A

Cambiar implementación sin afectar a terceros aka firma del método

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Coesión

A

Medida en la que elementos de un componente estan relacionados entre sí

Alta es mejor

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Interface

A

Conjunto de métodos que pueden ser accedidos por mensaje

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Ocultamiento

A

Capacidad de ocultar estructuras/comportamientos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

software legado

A

En el momento que se pone en disposición del usuario final

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Diseño de software

A

Comienza con alto nivel de abstracción y termina con bajo nivel

proceso iterativo e incremental para modelar la estructura y comportamiento para validarlo

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Mensaje

A

Objeto destinatario
Nombre del método
Parámetros

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Componentes de una relación

A

Rol
Navegabilidad
Cardinalidad
Modificador de acceso
Tipo de relación

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

-

A

private

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

+

A

public

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

~

A

package

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

#

A

protected

solo los que lo heredan (diferente paquete)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Refactoring

A

Mejorar diseño sin alterar comportamiento

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Rigidez

A

Dificultad de realizar cambios

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Inmovilidad

A

No se puede separar, no se puede reutilizar

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Repetición innecesaria

A

código duplicado

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Fragilidad
Muchos fallos si se modifica
26
Viscosidad
No se pueden implementar cambios correctos
27
Opacidad
No se entiende que hace el código
28
CC
complejidad ciclomatica le suma +1 casi todo Entre mayor sea es mas probable que el sistema gg Entre menor mejor
29
IM
Indice de mantenibilidad Entre mayor mejor Es la mediana de donde este
30
Arquitecto
Se encarga de definir soluciones para las necesidades del cliente y las documenta Resuelve Comunica Verifica
31
Componente
Pieza de software funcional, reemplazable y que expone sus funcionalidades por interface
32
Axiomas (3)
Alta cohesión Bajo acoplamiento SoC
33
SRP
Separation of responsability principle Cada cosa deberia estar en lo suyo Sabor método Sabor clase Sabor interface Una y solo una razon de cambio
34
OCP
Open and close principle Abierto a extensión - subclase - clase - sobreescritura - sobrecarga Cerrado a modificación - el código existente no se toca
35
LSP
Liskov sustitution principle La interfaz de las subclases deben ser iguales a las de la superclase
36
ISP
Interface segregation principle Cuando se incorpore una interface se debe asefurar la alta cohesión de sus métodos Sino se hace opaca y gg Cada clase tiene su propia interface Una interface debe tener una y solo una razón de cambio
37
DIP
Dependency inversion principle Siempre que se pueda hay que evitar dos clases concretas Entre clases concretas incorpore una capa de abstracción
38
Patrones
Soluciones generales para contextos específicos
39
Propósito: familia de patrones creacionales
Se encarga de separar la lógica de negocio y la creacional Encapsular lógica de creación Clases que consumen servicios
40
Singleton
Una sola instancia de una clase
41
Factory
Crear objetos sin especificar la clase exacta del objeto
42
Factory method
Crear objetos de una misma familia
43
S T U P I D
Singleton usado en todo el diseño Tight coupling/ acoplamiento apretado Unestability no se puede testear Premature optimization -> no comer mas de la cuent Indescriptive naming Duplication
44
MVC
Modelo -> logica de negocio Vista -> logica de presentacion Controlador -> fachada del modelo, recibe respuestas del modelo y las pone en la vista
45
Reflexión
permite crear una instancia a partir de una cadena de caracteres corresponde con un tipo de datos
46
Introspección
Permite determinar los atributos de un tipo de dato
47
DTO
Data transfer object representaciones básicas de las entidades clases con atributos y métodos get/set Transición de datos entre capas
48
Estado de un objeto
Valor de los atributos en un momento determinado
49
Observador
relación de dependencia entre el sujeto y varios observadores, cuando el sujeto cambie su estado se le notifica a los observadores
50
modelos de mensajeria del patrón objervador
Request/response shoot and forget publish and subscribe
51
Decorador
NO en diseño Adicionar comportamiento a objetos existentes evitando inclumplir el OCP original + nuevo nuevo + original nuevo + original + nuevo
52
Estrategia
Selección de algoritmo específico en tiempo de ejecución Variar comportamiento sin modificar estructura
53
Ligado estático
Corresponder en tiempo de compilación con lo que hay en una clase Ver que se va a correr sin correrlo
54
Ligado dinámico
Corresponder en tiempo de ejcución con lo que hay en una clase No se sabe que se va a correr hasta que se corre
55
Final
Hace un atributo tenga un valor final Todas las letras mayúsculas
56
package
Agrupación lógica de declaraciones para importar
57
Copia de código
Agarrar un pedazo de código y meterlo al programa
58
Reusabilidad
Usar código de alguien mas si y solo si no ocupo acceder al código original
59
REP
Reuse realese equivalence principle Organización y distribución coherente con alta cohesión y reutilización Si se reutiliza algo debe estar optimo para que otra persona lo use Los componentes de reutilización no deben ser menores a los de liberación
60
CRP
Common reuse principle Los componentes deberian estar agrupados según funcionalidades comunes Reutilización Alta cohesión Todas las clases contenidas en un mismo paquete deben ser reutilizadas juntas
61
CCP
Common closure principle Los paquetes deben contar con una y solo una razón de cambio Un cambio que afecte a un paquete deberia afectar a todas las clases contenidas en este
62
ADP
Acyclic dependencies principle El gráfico de las dependencias de paquetes debe ser un grafo direccionado acíciclo Los paquetes no deberian depender de ningun otro paquete Mejora la modularidad y mantenibilidad
63
Consecuencias de no ADP
gg mantenibilidad, testeo, lanzamiento, comprender, probar
64
Como curar falta de ADP
Capa de abstracción -> dependencias unidireccionales refactoring reorganizar DIP
65
Bottom up
Crear primero varias clases luego meterlas paquetes Los paquetes no dicen como funciona el sistema Este es el bueno
66
Top down
Este es el malo Noob Paquetes antes que clases
67
SDP
Stable dependencies principle Dependencias acorde a la estabilidad Un paquete solo debe depender de un paquete que no vaya a cambiar least likely Un paquete dificil de cambiar y uno que cambie mucho no son compatibles
68
SAP
Stable-abstractions principle Abstracciones proporcionales a la estabilidad del paquete Paquetes estables (least likely a cambiar) -> abstractos Paquetes inestables (bipolar) -> concretos
69
Familia de algoritmos
Jerarquía con superclase abstracta, subclases implementan metosos abstractos si no hay estructura es con interface OPC friedly Cambiar algoritmo en tiempo de ejecución BFF Factory Method
70
Clase concreta
Provee implementación de todos sus métodos
71
Comportamiento
Conjunto de metodos

Diseño (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions