El documento describe los principios básicos del diseño de componentes basados en clases, incluyendo el principio abierto-cerrado, el principio de sustitución de Liskov, y el principio de inversión de la dependencia. También cubre lineamientos para el diseño de componentes, interfaces y dependencias, así como conceptos de cohesión y acoplamiento.
Descrição original:
Una pequeña parte del diseño de un software
Título original
Diseño de Componentes Basados en Clase Ingeniera del Software
El documento describe los principios básicos del diseño de componentes basados en clases, incluyendo el principio abierto-cerrado, el principio de sustitución de Liskov, y el principio de inversión de la dependencia. También cubre lineamientos para el diseño de componentes, interfaces y dependencias, así como conceptos de cohesión y acoplamiento.
El documento describe los principios básicos del diseño de componentes basados en clases, incluyendo el principio abierto-cerrado, el principio de sustitución de Liskov, y el principio de inversión de la dependencia. También cubre lineamientos para el diseño de componentes, interfaces y dependencias, así como conceptos de cohesión y acoplamiento.
Cuando se escoge un enfoque de ingeniera orientado al software, el diseo en el nivel de componentes se centra en la elaboracin de clases especificas del dominio del problema y en el refinamiento de las clases de infraestructura contenidas en el modelo de requerimientos, La descripcin detallada de los atributos, operaciones e interfaces que emplean dichas clases es el detalle de diseo que se requiere como precursor de la actividad de construccin. Principios bsicos del diseo Hay cuatro principios bsicos que son aplicables al diseo en el nivel de componentes y que han sido aceptados para la aplicacin de la ingeniera del software orientada a objetos. - Principio Abierto-Cerrado (PAC) Debe especificarse el componente en forma tal que permita extenderlo sin necesidad de hacerle modificaciones internas es decir a nivel del cdigo o de la lgica. Para lograr esto, se crean abstracciones que sirven como bfer entre la funcionalidad que sea probable extender y la clase de diseo en s. - Principio de Sustitucin de Liskov (PSL) Este principio de diseo, originalmente propuesto por Barba Liskov, sugiere que en un componente que use una clase de base debe funcionar bien si una clase derivada de la clase base pasa al componente. PSL demanda que cualquier clase derivada de una clase de base debe respetar cualquier contrato implcito entre la clase de base y los componentes que la usan. - Principio de Inversin de la Dependencia (PID) Las abstracciones son el lugar en el que es posible ampliar un diseo sin muchas dificultades, entre ms dependa un componente de otros componentes concretos ms difcil ser ampliarlo. - Principio de Segregacin de la Interfaz (PSI) Es mejor tener muchas interfaces especificas del cliente que una sola de propsito general. Hay muchas instancias en las que mltiples componentes del clientes usan las operaciones que provee una clase servidor, El PSI sugiere que debe crearse una interfaz especializada y dedicada que atienda a cada categora principal de clientes en las que solo deben especificarse aquellas operaciones que sean relevantes para una categora particular de clientes. - Principio de Equivalencia de la liberacin de la Reutilizacin (PER) Cuando las clases o componentes se disean para ser reutilizables, existe un contrato implcito que se establece entre el desarrollador de la entidad reutilizable y las personas que la emplean. - Principio de cierre comn (PCC) Las clases deben empacarse en forma cohesiva, es decir, cuando las clases se agrupan como parte de un diseo, deben estar dirigidas a la misma rea de funciones o comportamiento.
- Principio de la reutilizacin comn (PRC)
Cuando cambia una o ms clases dentro de un paquete, cambia el nmero de liberacin del paquete. Entonces, todas las dems clases o paquetes que permanecen en el paquete que cambi deben actualizarse con la liberacin ms reciente y someterse a pruebas a fin de garantizar que la nueva versin opera sin problemas. Lineamientos de diseo en el nivel de componentes Se aplican lineamientos prcticos a los componentes, a sus interfaces y a las caractersticas de dependencia y herencia que tengan algn efecto en el diseo resultante. Componentes: Deben establecerse convenciones para dar nombre a los componentes que se especifique que forman parte del modelo arquitectnico, para luego mejorarlos y elaborarlos como parte del modelo en el nivel de componentes. Interfaces: as interfaces dan informacin importante sobre la comunicacin y la colaboracin, sin embargo, la representacin sin restricciones de las interfaces tiende a complicar los diagramas de componentes. Dependencias y Herencia: Para tener una mejor legibilidad, es buena idea modelar las dependencias de izquierda a derecha y la herencia de abajo hacia arriba. Cohesin La cohesin implica que un componente o clase slo contiene atributos y operaciones que se relacionan de cerca uno con el otro y con la clase o componente en s. Funcional: Lo tienen sobre todo las operaciones, este nivel de cohesin ocurre cuando un componente realiza un clculo y luego devuelve el resultado. De Capa: Lo tienen los paquetes, componentes y clases; este tipo de cohesin ocurre cuando una capa ms alta accede a los servicios de otra ms baja, pero esta no tiene acceso a las superiores. De Comunicacin: Todas las operaciones que acceden a los mismos datos se definen dentro de una clase. En genera, tales clases se centran nicamente en los datos en cuestin, acceden a ellos y los guardan. Acoplamiento El acoplamiento es la medicin cualitativa del grado en el que las clases se conectan una con otra. Conforme las clases (y componentes) se hacen ms interdependientes, el acoplamiento crece. -
Acoplamiento de Contenido Acoplamiento Comn Acoplamiento del Control Acoplamiento de Molde Acoplamiento de Datos Acoplamiento de Rutina de Llamada
Acoplamiento de tipo de uso
Acoplamiento de inclusin o importacin Acoplamiento Externo.