Diseño de Componentes Basados en Clase Ingeniera Del Software

August 10, 2022 | Author: Anonymous | Category: N/A
Share Embed Donate


Short Description

Download Diseño de Componentes Basados en Clase Ingeniera Del Software...

Description

 

10.2 Diseño de Componentes Basados en clase

Cuando se escoge un enfoque de ingeniería orientado al software, el diseño en el nivel de componentes se centra en la elaboración de clases especificas del dominio del  problema y en el refinamiento de las clases de infraestructura contenidas en el modelo de requerimientos, La descripción detallada de los atributos, operaciones e interfaces que emplean dichas clases es el detalle de diseño que se requiere como precursor de la actividad de construcción. Principios básicos del diseño Hay cuatro principios bsicos que son aplicables al diseño en el nivel de componentes y que han sido aceptados para la aplicación de la ingeniería del software orientada a ob!etos.

" Principio Abierto-Cerrado (PAC) (PAC) #ebe especificarse el componente en forma tal que permita e$tenderlo sin necesidad de hacerle modificaciones internas es decir a nivel del código o de la lógica. %ara lograr esto, se crean abstracciones que sirven como b&fer entre la funcionalidad que sea probable e$tender y la clase de diseño en sí. "

Principio de Sustitucin de !is"o# (PS!)

'ste principio de diseño, originalmente propuesto por (arba Lis)ov, 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. %*L demanda que cualquier clase derivada de una clase de base debe respetar cualquier contrato implícito entre la clase de base y los componentes que la usan. " Principio de $n#ersin de la Dependencia (P$D) Las abstracciones son el lugar en el que es posible ampliar un diseño sin muchas dificultades, entre ms dependa un componente de otros componentes concretos ms difícil ser ampliarlo. " Principio de Se%re%acin de la $nter&a' (PS$) +'s me!or tener muchas interfaces especificas del cliente que una sola de propósito general. Hay muchas instancias en las que m<iples componentes del clientes usan las operaciones que provee una una clase servidor, 'l %*- sugiere que debe crearse una interfa especialiada y dedicada que atienda a cada categoría principal de clientes en las que solo deben especificarse aquellas operaciones que sean relevantes para una categoría particular de clientes. " Principio de ui#alencia de la liberacin de la *eutili'acin (P*) Cuando las clases o componentes se diseñan para ser reutiliables, e$iste un contrato implícito que se establece entre el desarrollador de la entidad reutiliable y las  personas que la emplean. " Principio de cierre com+n (PCC) Las clases deben empacarse en forma cohesiva, es decir, cuando las clases se agrupan como parte de un diseño, deben estar dirigidas a la misma rea de funciones o comportamiento.

 

" Principio de la reutili'acin com+n (P*C) Cuando cambia una o ms clases dentro de un paquete, cambia el n&mero de liberación del paquete. 'ntonces, todas las dems clases o paquetes que permanecen en el paquete que cambió deben actualiarse con la liberación ms reciente y someterse a pruebas a fin de garantiar que la nueva versión opera sin problemas. !ineamientos de diseño en el ni#el de componentes   *e aplican lineamientos prcticos a los componentes, a sus interfaces y a las características de dependencia y herencia que tengan alg&n efecto en el diseño resultante. Componentes, #eben establecerse convenciones para dar nombre a los componentes que se especifique que forman parte del modelo arquitectónico, para luego me!orarlos y elaborarlos como parte del modelo en el nivel de componentes. $nter&aces,  as interfaces dan información importante sobre la comunicación y la colaboración, sin embargo, la representación sin restricciones de las interfaces tiende a complicar los diagramas de componentes. Dependencias  erencia,  %ara tener una me!or legibilidad, es buena idea modelar las dependencias de iquierda a derecha y la herencia de aba!o hacia arriba.

Co/esin La cohesión implica que un componente o clase sólo contiene atributos y operaciones que se relacionan de cerca uno con el otro y con la clase o componente en sí. uncional, Lo tienen sobre todo las operaciones, este nivel de cohesión ocurre cuando un componente realia un clculo y luego devuelve el resultado. De Capa, Lo tienen los paquetes, componentes y clases/ este tipo de cohesión ocurre cuando una capa ms alta accede a los servicios de otra ms ba!a, pero esta no tiene acceso a las superiores. De Comunicacin, 0odas las operaciones que acceden a los mismos datos se definen dentro de una clase. 'n genera, tales clases se centran &nicamente en los datos en cuestión, acceden a ellos y los guardan.

Acoplamiento 'l acoplamiento es la medición cualitativa del grado en el que las clases se conectan una con otra. Conforme las clases 1y componentes2 se hacen ms interdependientes, el acoplamiento crece.

" " " "

3cop 3copla lami mien ento to de Cont Conten enid ido o 3coplamien iento Com&n 3cop 3copla lam mient iento o del del Con ontr trol ol 3cop 3copla lam mient iento o de 4old ldee

""

3cop 3c opla lam mient ie nto o de #ato attina ona s de 3cop 3copla lami mien ento to de de 5uti 5u de Llam Llamad adaa

 

" " "

3cop 3copla lam mient iento o de de tip tipo o de de uso uso 3cop 3copla lami mien ento to de de incl inclus usió ión n o imp impor ortac tació ión n 3cop 3copla lam mient iento o '$ter $terno no..

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF