From the beginning, modeling meant that the actions and interactions of the objects that the 
program  created  (implemented  in  an  object-oriented  language)  represent  the  actions  and 
interactions of the corresponding real-world physical (or virtual) objects.  
 
The  goal  is  to  model  the  real-world  scenario  through  objects  and  interactions  to  represent 
the  domain  as  best  as  possible.  Clearly,  more  complex  re  al-world  scenarios  are  more 
challenging to be modeled into a set of classes.  
 
 
Parnas​ introduced the concept of information hiding in 
modular programming in his 1972 seminal paper “On the 
Criteria  to  Be  Used  in  Decomposing  Systems  into  Modules”;  a concept related to what later 
was  referred to as high cohesion and loose coupling. In his “The Mythical ManMonth: Essays 
on  Software  Engineering”  from  1975,  Brooks  brought  the  attention  to  the  importance  of 
conceptual  integrity  in  software  design  with  the  idea  that  there  should  be  one  mind  (or  a 
small,  cohesive  team)  that  designs  the  architecture  of  the  system  in  a  consistent  and 
well-thought way . 
 
Meyer​, in his canonical “Object-Oriented Software 
Construction” book, discussed several techniques to make 
reusable, extensible, and maintainable object-oriented design. 
 
The  Gang  of  Four  proposed  a  large  set  of  design  patterns  that  help  developers  when 
looking for elegant solutions to recurrent (creational, structural, and behavioral) and reusable 
object-oriented design systems.  
 
Rumbaugh,  Booch,  and  Jacobson  proposed  the  Unified  Modeling  Language  (UML),  which 
the  goal  was  to  provide  a  general-purpose  language  to  aid  software  developers  and 
business stakeholders throughout the modeling process.  
 
Martin  ​collected  the  five  most  crucial  object-oriented  design  principles,  according  to  his 
experience,  in  his  renowned  paper  “Design  Principles  and  Design  Patterns”  ,  which  later 
were known as the SOLID principles. 
 
Freeman  and  Pryce  presented  their  views  on  how  test  code  and,  more  specifically,  mock 
objects,  can  help  developers  in  understanding  and  better  defining  their class contracts, and 
how they should collaborate.  
 
Evans  ​suggested that developers should work together with domain experts putting all their 
emphasis  on  modeling  the  system  core  domain  and  the  associated  domain  problems,  and 
proposed  several  patterns  to  help  developers  on  such  activity  which  he  called  Domain 
Driven Design (DDD) 
 
 
Due  to  the  joint  effort  and  complementary  work  of  industry  113  2019  IEEE/ACM  41st 
International  Conference  on  Software  Engineering:  New  Ideas  and  Emerging  Results 
(ICSENIER)  and  research,  our  community  believes  it  has  a  clear  vision  about  what  an 
object-oriented  software  design  that  is  aintainable,  evolvable,  and  comprehensible  should 
look  like.  Or  so  we  think.  Although  our  body  of  knowledge  on  software  design  is  already 
extensive  and  significant,  modern  software  brings  modern  challenges.  In  the  following 
sections, we describe three timely challenges we see in modern software design.  
 
We summarize the challenges below: 
1)  The  strong  influence  of  libraries  and  frameworks  on  the  design  decisions.  Developers 
never  start  software  from  scratch.  Instead,  they  reuse  several  libraries,  frameworks,  and 
out-of-the-box  architectures  not  only  to  speed  up  their  development,  but  also  to  support 
their  different  functional  and non-functional requirements. These libraries, frameworks, and 
architectures  often  force  developers  to  change  the  way  they  implement  their  models  in 
object-oriented languages. 
 
2)  The  plethora  of  stakeholders  and  their  different  representations  of  the  same  problem. 
Software  becomes  more  and  more  complex  as  our  businesses  become  more  and  more 
complex.  The  same  software  has  multiple  stakeholders whom all have their perspectives on 
the  business  flow.  Software  supports  multiple  final  users,  which  also  have  their  specific 
requirements.  In  practice,  this  means  that  a  single  model  representation  of  the  real-world 
problem is not enough anymore. 
 
3)  The  need  for  contextual  quality  measurements.  Measuring the quality of a class design is 
fundamental  in  supporting  developers  to  decide  where  to  improve.  Currently,  developers 
often do not trust on   
existing  automated  design  analysis  tools  as  they  generate  too  many  false  positives.  We 
argue  that  a  plausible  cause  for  this  problem  is  that  our  approaches  currently  do  not  take 
the context of the system into account. 
 
 
 
El  presente  paper  nos  da  a  conocer  los  desafíos  prácticos  del diseño orientado a objetos en 
el  desarrollo  de  software  moderno  que  los  desarrolladores  actuales  enfrentan.  A  pesar  del 
amplio  conocimiento  de  técnicas,  patrones  y  principios  para  desarrollar  un  software  de 
calidad, hay un trabajo por realizar 
 
 
El  primero  trata  sobre  el  impacto  de  la  arquitectura  y  el  stack  tecnológico  en  el  diseño  de 
software.  Esto  implica  que  los  desarrolladores  actuales  utilizan  varias  bibliotecas  que  los 
lenguajes  de  programación  tienen  implementadas.  Además,  tenemos  frameworks  y 
arquitecturas  listas  para  usar.  Esto  ayuda  a  los  desarrolladores  a  acelerar  su trabajo y a dar 
soporte  a  sus  requisitos  funcionales  y  no  funcionales.  El  stack  tecnológico  es  una  lista  de 
todos  los  servicios  tecnológicos  utilizados  para  construir  y  ejecutar  una  aplicación.  Estas 
tecnologías  y  arquitecturas  disponibles  influyen  de  sobremanera  en  la  decisión  de  diseño. 
Cuando  un  equipo  de desarrolladores elige una arquitectura, ellos deben adecuar su modelo 
a las restricciones impuestas por esa arquitectura y por la elección del stack tecnológico. 
 
 
Soluciones  actuales:  ​los  profesionales  han  estado  proponiendo  ampliamente  a  los 
desarrolladores  que  separen tanto como sea posible la implementación del dominio en sí, de 
los  requisitos  de  la  aplicación  (por  ejemplo,  bases de datos, Android API). Varios patrones y 
enfoques  siguen  esta  idea,  como  como  Puertos  y  Adaptadores  (Arquitectura  Hexagonal) 
arquitectónicos  patrón  ,  arquitecturas  en  capas  y  contextos  delimitados,  y  descubrimiento 
de interfaz . 
 
Visión  para  el  futuro:  ​necesitamos  teorías  de  implementación  de  diseño  de  software  que 
reconozcan el hecho de que el software es a menudo heterogéneo, distribuido y compuesto 
por  un  gran  conjunto  de  diferentes  marcos  y  bibliotecas.  Cada  la  arquitectura  común 
necesita  ser  estudiada  cuidadosamente,  y  su  Impacto  positivo  y  negativo  en  el  diseño 
explorado.  Nuestra  extensa  antecedentes  sobre  modularización  y  separación  de 
preocupaciones debería servir de base. 
 
 
El  segundo  desafío  que  se  aborda  toca  el  tema  de  los  múltiples  modelos  en  grandes 
dominios  complejos.  En  la  actualidad  las  empresas  son  cada vez más complejas, así mismo, 
el  diseño  de  software  se  vuelve  más  complejo.  Hoy  en  día,  las  empresas  trabajan  con 
eventos  y  estos  eventos  cambian  de estado. También decir que cada módulo tiene su punto 
de  vista  es  decir  para  un  módulo  puede  ser  importante  una  parte  y  para  el  otro  módulo 
quizás  no.  Este  problema  obliga  a  los  desarrolladores  a  pensar  en  varias  representaciones 
de  diferentes  modelos.  Es  decir,  que  los  desarrolladores  no  solo  deben  modelar  las 
principales  entidades  y  sus  acciones,  sino  que también deben modelar eventos de negocio. 
Modelar estos dominios complejos es desafiante para los desarrolladores de software.  
 
Soluciones  actuales:  ​el  enfoque  de  diseño  impulsado  por  dominio  de  Evans  propone  un 
conjunto  de  patrones  de  diseño  estratégico  que  ayudan  a  desarrolladores a dividir modelos 
grandes  en  diferentes  "Limitados  Contextos  ",  y  para  construir  un"  Mapa  de  contexto  "que 
muestre  explícitamente  Las  relaciones  entre  los  diferentes  contextos.  También  observar  el 
surgimiento  de  las  arquitecturas  dirigidas  por  eventos,  donde  los  desarrolladores  tratan 
explícitamente  con  eventos  de  dominio.  Los investigadores también son conscientes de que 
modelar  dominios  del  mundo  real  es  una  actividad  fundamental  en  la  ingeniería  de 
requisitos  y  que  modelar  grandes  sistemas  complejos  es,  de  hecho,  un  desafío  abierto.  Los 
empiristas  han  estado  estudiando  cómo  los  desarrolladores  realizan  la  ingeniería  de 
requisitos  en  la  práctica  ,  las  ventajas  y  desventajas  de  usar  lenguajes  de  modelado  como 
UML y cómo diferentes herramientas de modelado y técnicas realizar. 
Más  recientemente,  los  desarrolladores  han  estado  proponiendo  microservicios  como  una 
posible  alternativa  para  reducir  la  complejidad  y  El  acoplamiento  entre  sus  sistemas  y 
tecnologías  específicas.  En  esencia,  vemos  que  la  idea  de  modularización  es  discutido  por 
los desarrolladores desde diferentes perspectivas.  
 
Visión  para  el  futuro:  ​carecemos  de  una  comprensión  clara  de  cuán  complejos  son  y deben 
ser  los  procesos  comerciales  del  mundo  real  modelado.  Además,  no  entendemos  cómo  los 
múltiples  modelos  interactúan,  evolucionan  y  se  mantienen  juntos,  no  solo  desde  un  nivel 
abstracto,  pero  también  desde  el  punto  de  implementación  de  vista.  ¿Cómo  (y  cuánto) 
pueden los desarrolladores reutilizar la implementación de un modelo a otro? ¿Cuánto puede 
o  debería  un  modelo  estar  acoplado  con  otro  modelo  sin  causar  daño? Cómo interpretar la 
noción  de  cohesión  cuando  ¿El  mismo  aspecto  se  representa  ahora  en  varias  clases?  Las 
teorías  que  explican  tales  preguntas  son  un  paso  fundamental  hacia  la  construcción  de 
pautas  y  enfoques  que  puedan  ayudar  desarrolladores  para  hacer  frente  a  tal  complejidad. 
Lo  vemos  como  una  llamada  para  la  colaboración  entre  ingenieros  de  software  y requisitos 
investigadores de ingeniería. 
 
 
 
El  tercer  desafío  trata  sobre  la  medición  contextual  de  la  calidad  de  un  diseño de software 
orientado  a  objetos. Es muy importante el diseño ya que de él depende la calidad de nuestro 
software.  Tenemos  que  entender  en  qué  contextos  tiene  sentido  medir  la  calidad,  y  lo  más 
importante,  en  qué  contextos  no  tiene  sentido  medirla.  De  hecho,  hay  herramientas  que 
miden  la  calidad  del  diseño,  pero  estas  herramientas  no  son  suficientes.  Se  encuentra  que 
muchas  de  ellas  generan  una  gran  cantidad  de  falsos  positivos  porque  no toman en cuenta 
el contexto del sistema. 
 
Soluciones  actuales:  ​teniendo  en  cuenta  el  dominio  y  la  arquitectura  del  sistema  en estudio 
ha  ido  ganando  atención  de  la  comunidad  en  los  últimos  años.  Aunque  las  linters  se  usan 
ampliamente  y  se  han  propuesto  estrategias  de  monitoreo  de  calidad  como  la  Inspección 
Continua,  los  investigadores  han  demostrado  que  el  dominio  de  la  aplicación  importa 
cuando  se  trata  de  la  presencia  de  olores  de  código,  que  las  distribuciones  métricas  de 
código  son  estadísticamente  diferentes  entre  los  diferentes  roles  arquitectónicos  de  las 
clases  en  un  sistema,  y  que  las  arquitecturas  específicas  pueden  tener  su  propia 
especificidad  huele.  Además,  investigaciones  recientes  sobre  la  deuda  técnica  han 
demostrado  que  El  conocimiento  de  la  deuda  técnica  influye  en  el  comportamiento  del 
equipo.  Desarrollar  mejores  formas  de  identificar,  monitorear,  categorizar,  medir,  priorizar y 
pagar  la  deuda  técnica  puede  mejorar  significativamente  las  prácticas  de  desarrollo  de 
software .  
 
Visión  para  el  futuro:  ​necesitamos  teorías  empíricamente  derivadas  sobre  cuáles  son  las 
características  de  los  modelos  complejos  que  deberían  ser  considerado  de  alta  calidad y en 
qué  contexto,  también  como  formas  numéricas  de  medir  tales  características.Machine 
Learning  y  Data  Science  pueden  desempeñar  un  papel  esencial  en el campo, dado el hecho 
de  que  muchas  características  de  diseño  pueden  ser  determinado  solo  por  combinaciones 
complejas  de  diferente  calidad  atributos.  Conjeturamos  que  tales  teorías  y  enfoques 
apoyará,  de  una  vez  por  todas,  el  desarrollo  de  la  calidad  herramientas  de  evaluación  que 
producen menos falsos positivos.