You are on page 1of 3
[NGENIERIA DEL SOFTWARE. UN ENFOQUE PRACTICO tener la cohesién entre médulos), seria necesario desa- rrollar médulos de dibujo para cada tipo de grfico. Segtin esto, dentro del disefio para cada tipo de gréfico, se debe- 14 afiadir una I6gica de control semejante a la siguiente: case of tipe_grafico: if tipe_grafico = grafico_linéa then Dibujartinea (datos) + if tipe_grafico = grafico DibujarTarta (datos: if tipo_gratico = gratico_histograna then Dibujariisto(datos): if tipo_grafico = grafico_kiviat ‘then Dibujarkiviat (datos) + end case: eta then Aunque este disefio es razonablemente evidente, afa- dir nuevos tipos de graficos puede ser complicado, pues hay que crear un nuevo médulo de dibujo para cada tipo de grifico y actualizar la I6gica de control para cada sritico. ara resolver este problema, cada uno de los grifi- ‘cos mencionados anteriormente se convierte en una sub- clase de una clase general llamada Grafico. Usando un concepto llamado sobrecarga {TAY90), cada subclase define una operaci6n llamada dibujar. Un objeto pue- de enviar un mensaje dibujar a cualquiera de ‘os obje- tos instanciados de cualquiera de las subclases. El objeto ue recibe el mensaje invocard su propia operac:én dibu- Jar para crear el grifico apropiado. Por esto, el diseiio ‘mostrado anteriormente se reduce a: tipo_grafico dibujar ‘Cuando hay que afiadir un nuevo tipo de grifico al sistema, se crea una subclase con su propia operacién Los elementos de un modelo de objetos —clases y obje- tos, atributos, operaciones y mensajes— fueron definidos yy examinados en la seccién precedente. Pero, ,o6mo pode- ‘mos hacer para identificar estos elementos en un proble- ‘ma real? Las secciones que siguen presentan una serie de directrices informales que nos ayudardn en la identifica- Cin de los elementos de un modelo de objetos. 20.8.1. Identificacién de clases y objetos Si usted observa a su alrededor en una habitacién, exis- ten un conjunto de objetos fisicos que pueden ser fécil- ‘mente identificados, clasificados y definidos (en términos de atributos y operaciones). Pero cuando usted «observa» elespacio dé un problema en una aplicacién de software, los objetos pueden ser més dificles de identifica dibujar. Pero no se requieren cambios dentro de un obje= to que quiere dibujar un grafico pues el mensaje tipo_grafico dibujar no cambia. En resumen, el poli= ‘morfismo permite que un niimero de operaciones dife= rentes tengan el mismo nombre. Esto reduce ef acoplamiento entre objetos, haciendo a cada uno ms independiente, as Elfe|_| i if F : fetes k HE ey 5 UE jae) les) (sed FIGURA 20.8b. Jorarquia de clases reestructurada. Podemos empezar a identificar objetos‘ examinando el planteamiento del problema 0 (usando la terminolo- ‘gia del Capitulo 12) realizando un «andlisis sintsctico ‘gramatical» en la narrativa del sistema que se va a cons- ‘tuir, Los objetos se determinan subrayando cada nom- bre o cléusula nominal e introduciéndola en una tabla simple. Los sinénimos deben destacarse. Si se requie- re del objeto que implemente una solucién, entonces ‘TE realidad, el Analisis 00 intentaidenticar las clases a partir de las cuales se instancian los objetes Por tanto, cuando aislamos obje- tos potencials, también ientiicamos miembros de clases poten- lakes, 6 te formaré parte del espacio de solucién; en caso de que el objeto se necesite solamente para describir una solucién, éste forma parte del espacio del problema. Pero, {qué debemos buscar una vez que se han aislado todos los nombres? Como identfcr objets ‘wando estudio como solver un problema? Los objetos se manifiestan de alguna de las formas mostradas en la Figura 20.9. y pueden ser: + entidades externas (por ejemplo: otros sistemas, positivos, personas) que producen o constumen infor- ‘macién a usar por un sistemas computacional; + cosas (por ejemplo: informes, presentaciones, car- tas, sefiales) que son parte del dominio de informa- ci6n del problema; + ocurrencias 0 sucesos* (por ejemplo: una transfe~ rencia de propiedad o la terminacién de una serie de movimientos en un robot) que ocurren dentro del contexto de una operacién del sistema; + papeles o roles (por ejemplo: director, ingeniero, ven- dedor) desempefiados por personas que interactdan con el sistem + unidades organizacionales (por ejemplo: divisién, grupo, equipo) que son relevantes en una aplicacin: + lugares (por ejemplo: planta de produccién o mue- lle de carga) que establecen el contexto del problema y la funcién general del sistema; + estructuras (por ejemplo: sensores, vehiculos de cua- tro ruedas o computadoras) que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos Tin extecontexto, el término suceso denota cualquier ocurenci, Nonecesariamente implica control, en el sentido del Capitulo 12 cartroto a cONCEFTOS Y PRINCI La clasificacién mostrada anteriormente es una de Jas muchas que se han propuesto en la literatura. También es importante destacar qué no son los obje- tos. En general, un objeto nunca debe tener un «nom- bre procedimental imperativo» [CAS89]. Por ejemplo, si los desarrolladores de un software para un sistema ‘grdfico médico definieron un objeto con el nombre inversion de imagen, estarian cometiendo un sutil eror. La imagen obtenida por el software pudiera ser, en efec- to, un objeto (es un elemento que forma parte del domi- nio de informacién), pero la inversién de la imagen es tuna operacién que se aplica a dicho objeto. Inversion debe definirse como una operacién del objeto imagen, Pero no como objeto separado que signifique

You might also like