PRESSMAN CAP 11

Diseo a nivel de componentes

Qu es el diseo al nivel de componentes?: es el que define las estructuras de datos, los
algoritmos, las caractersticas de la interfaz y los mecanismos de comunicacin asignados a
cada componente de SW , se reduce el nivel de abstraccin, llevando el diseo cerca del nivel de
cdigo. En el paso previo, al conjunto de componentes se lo define en el diseo arquitectnico,
donde ya se han establecido los datos generales y la estructura del programa.
Quin lo hace?: un ingeniero de SW.
Por qu es importante?: porque es necesario asegurarse antes de construir el SW, que este
funcionar bien. Es una representacin de SW, que permite evaluar si funcionar : estructuras
interfaces y algoritmos (con respecto al SW que se va a hacer en la ste etapa). Y tambin si los
diseos de datos, arquitectura e interfaz estn bien con respecto al paso anterior (el diseo de la
arquitectnico).
Cules son los pasos?: con definicin de clases, detallando el diseo mediante el uso de
diagramas UML y notacin complementaria o con la definicin narrativa, detallando el diseo en
forma de texto, que es procedimental (conjunto de instrucciones de programacin estructurada).
Cul es el resultado obtenido?: el principal producto en el diseo de componentes. Es el
diseo de cada uno de estos en forma de grficos, tablas y texto.
Cmo se sabe que se hizo bien?: con una inspeccin de diseo. Se examina el mismo para
verificar los datos que sern la salida son correctos.
11.1 Qu es un componente?
Es un bloque (mdulo) desplegable y reemplazable, o sea que encapsula implementacin y
presenta interfaces.
Ayudan a cumplir con los objetivos y requisitos del sistema. Deben poder comunicarse y
colaborar con otros componentes internos o externos al sistema.
11.1.1 Concepto orientado a objetos
Porque un componente posee un conjunto de clases que colaboran entre s. Estas clases
contienen todos los atributos y operaciones (mtodos, o sea las funciones definidas dentro de la
clase). Tambin las interfaces (mensajes para comunicarse y colaborar con otras clases).
Estas clases surgieron en la etapa del modelo de anlisis (clases de anlisis y clases de
infraestructura(dominio del problema))
Para el caso de los componentes cuando es SW convencional tambin se derivan del modelo del
anlisis. La diferencia es que la derivacin parte del elemento de datos orientado al flujo
(recordar que aqu datos y procesos van por separado). Lo importante es que sale de los
diagramas de flujos de datos.

Estos son componentes de un sistema convencional (datos y procesos por separado again)

Esto es UML, diagrama de actividad, en el que se aprecia el nivel de seudocdigo del algoritmo.
Donde dice accesarBDCostos representa una interfaz de comunicacin con la base de datos.
11.1.3 Un concepto relacionado con el proceso
Habla de la necesidad de trabajar con componentes existentes, que se materializa por medio de
una catlogo de componentes que estn probados a nivel de diseo (seudocdigo) o de
cdigo. Se utilizan a medida que se avanza en el diseo. En la Arquitectura se eligen los
componentes o patrones de diseo (tienen una descripcin completa de la interfaz, funciones y
colaboracin que puede prestar o sea que hay que estudiarlos como si uno los programase, una
boludez).

*MIDDLEWARE: es una coleccin de componentes de infraestructura que permiten que los

componentes del dominio del problema se comuniquen con otros en una red o dentro de un
sistema. Es importante porque segn Pressman es un elemento clave para el xito y por eso el
bolu.. lo mencion en especial en la clase. (www.corba.com y Microsoft COM)
11.2 Diseo de componentes basados en clases
Modelo del anlisis
Clases del anlisis (dominio del problema)
Clases de infraestructura
Modelo arquitectnico
Componentes que tienen Detalles de: Atributos, operaciones e interfaces (de las clases)
Construccin
11.2.1 Principios bsicos de diseo
Para crear diseos que puedan ser modificados sin generar efectos secundarios
principios:

se aplican 4

Principio abierto-cerrado (pac).

El diseador tiene que especificar (detallar ms) el componente (abrir) para que se pueda
extender sin modificar (cerrado) el cdigo del propio componente. En clase dio como ejemplo
de extender el hecho de agregar mtodos (funciones) a la clase y modificar es cambiar los
mtodos.
Aunque en el libro habla de crear abstracciones (son otras clases que extienden el
comportamiento) que sirven de memoria intermedia entre la funcionalidad que podra llegar a
extenderse y la propia clase (como si el cambio no fuera parte de la misma clase) .
SACADO DE INTERNET: Un mdulo est cerrado para su modificacin al depender de una

abstraccin que es fija. Pero el comportamiento del mdulo puede ser extendido
mediante la creacin de clases derivadas.
Conclusin: este pelotudo no sabe una mierda.
Principio de sustitucin de Liscov
Se pueden sustituir subclases por clases principales y seguir funcionando
apropiadamente. Tiene que ver con la herencia en las clases y la posibilidad de que un
mtodo pueda recibir cualquier objeto dentro de la estructura jerrquica. Para cumplir
esto es necesario realizar correctamente las herencias.
Principio de inversin de la independencia

Los mdulos de alto nivel no deben depender de los mdulos de bajo nivel. Ambos
deben depender de las abstracciones. Las abstracciones no deben depender de los
detalles. Los detalles deben depender de las abstracciones.
Cuanto ms dependa un componente de otros componentes concretos (no abstractos,
como la interfaz) ms difcil es extenderlos.
Principio de agregacin de la interfaz (ISP)
Es mejor muchas interfaces de cliente especficas que una sola de propsito general.

( internet )
El ISP no recomienda que cada clase que utilice un servicio tenga una propia clase
interfaz especial de la cual herede el servicio. Lo que indica es que los clientes han de
categorizarse por tipo y crear una interfaz para cada tipo de cliente. Si dos o ms tipos
diferentes de cliente necesitan el mismo mtodo, el mtodo ha de ser aadido en todas
las interfaces.
Principio de equivalencia entre reutilizacin y versin
Agrupar las clases reutilizables en paquetes que puedan manejarse y controlarse a
medida que evolucionan las versiones.
( internet )
La reutilizacin es uno de los ms aclamados principios del DOO. Sin embargo, la
reutilizacin no viene automticamente, no es tan simple como escribir una clase y decir
que es reutilizable. En primer lugar, una clase probablemente tendr una serie de clases
que colaboran con ella. Por tanto, la clase no es reutilizable por s sola, debe reutilizarse
en conjunto con las clases con las que colabora. Por otra parte, los desarrolladores con
reutilizacin no desean tener que mantener los cambios de las clases que ellos
reutilizan.
Por lo tanto se requiere un cierto mecanismo de distribucin de las nuevas revisiones.
Principio del cierre comn
Las clases que cambian juntas deben permanecer juntas. Para esto, las clases, deben
empaquetarse de manera que atiendan la misma rea de funciones o comportamientos.
( internet )
Los cambios que se realizan dentro de un conjunto de clases (paquete) que responde a un
comportamiento no debe extenderse hacia otros paquetes.
Principio comn de la reutilizacin
Las clases que un se reutilizan juntas, no deben agruparse juntas (formando el mismo paquete).
Si cambian una o ms clases en un paquete, tambin cambia el nmero de la versin del mismo.
11.2.2 Lneas generales de diseo al nivel de componentes
Estos son un conjunto prctico que se aplican a componentes, sus interfaces y las
caractersticas de dependencia y herencia que impactan en el diseo.
Componentes: los nombres para componentes deben asignarse mediante convenciones, en el
modelo arquitectnico salen del dominio del problema y deben ser entendibles por todos.
Interfaces: nos dan informacin sobre comunicacin y colaboracin.
1) Representacin de la interfaz mediante lnea y crculo(en lugar del de UML recuadro y lnea
de guiones).
2) Las interfaces deben fluir de izq a der, por razones de consistencia.
3) Solo se muestran las interfaces relevantes del componente en cuestin.
Dependencias y herencias: se modela la dependencia de izq a der y la herencia de abajo
(clases derivadas) hacia arriba (clases principales). Para mejorar las opciones de mantenimiento
del sistema las interdependencias entre los componentes se representan con interfaces.
11.2.3 Cohesin
Es la funcin nica de un componente, implica que un componente o una clase encapsula
atributos y operaciones (propiedades y funciones) relacionadas entre s y con la clase del propio
componente.
Tipos de cohesin ordenados segn su grado.
Funcional: (para operaciones) cuando un mdulo realiza un solo clculo y luego devuelve un
resultado.
De capa: (paquetes, componentes y clases) una capa superior tiene acceso a los servicios de
una inferior, pero no en sentido contrario.

De comunicacin: todas las operaciones (funciones) con acceso a los mismos datos se definen
dentro de una clase.
Los puntos mencionados anteriormente ayudan la implementacin, prueba y mantenimiento de
las clases. Existen otros casos donde se presentan niveles inferiores de cohesin:
Secuencial: para implementar una secuencia de operaciones, se agrupan los componentes de
forma que la salida de uno es la entrada del otro.
Procedimental: el llamado al proceso tiene que ser unvoco (apunte clase).
Temporal: las operaciones que se realizan reflejan un comportamiento o estado especfico,
ejemplo: todas la operaciones que se realizan cuando se detecta un error.
Utilitaria: componentes, clases y operaciones existen dentro de la misma categora pero no
tienen otra relacin.
11.2.4 Acoplamiento
La comunicacin y la colaboracin determinan el grado de conectividad entre las clases. A
medida que esta aumenta se complica la implementacin, prueba y mantenimiento de SW.
El acoplamiento es una medida cualitativa del grado en que las clases se conectan entre s.
Es necesario mantener el acoplamiento lo ms bajo posible.
Categoras de acoplamiento:
Acoplamiento del contenido: cuando un componente modifica datos internos del otro.
Acoplamiento comn: es cuando varios componentes usan una variable global.
Acoplamiento de control: se presenta cuando la operacin A (mtodo o funcin) invoca
(pasaje de parmetros entre los dos mtodos) la operacin B y le pasa una marca (bandera-flag)
de control a este. A dirige a B (controla)
Segn Argibel, A marca a B, mientras pasa esto, C no puede acceder a B y se produce error.
Acoplamiento de estampa: cuando claseB se declara como tipo para un argumento de una
operacin de calseA. Hace ms difcil la modificacin del sistema.
Acoplamiento de datos: se produce en el pasaje de largas cadenas de argumentos de datos,
aumenta el ancho de banda de la comunicacin entre clases, se hace difcil la prueba y
mantenimiento. Aumenta la complejidad de la interfaz.

Acoplamiento de llamada a rutina: cuando una operacin invoca a otra, si bien es necesario,
aumenta la conectividad del sistema (colaboracin y comportamiento).
Acoplamiento de uso de tipo: cuando el componente A usa un tipo de dato definido en el
componente B , si cambia la definicin del tipo, se debern cambiar todos los componentes que
usen esta definicin.
Segn Argibel: si A usa algo de B, debe identificar el cambio o cambiar el componente que lo va
a usar.
Acoplamiento de inclusin o importacin: cuando el componente A importa o incluye un
paquete o el contenido del componente B.
Acoplamiento externo: cuando un componente se comunica o colabora con componentes de
infraestructura. Debe limitarse a un nmero pequeo de componentes o clases.
11.3 CONDUCCIN DEL DISEO AL NIVEL DE COMPONENTES
La informacin del anlisis y los modelos arquitectnicos se deben transformar en una
representacin de diseo que proporcione detalles suficientes para guiar la codificacin y prueba
(construccin).
Conjunto de tareas tpicas para el diseo al nivel de componentes:
Paso 1. Identificar todas las clases del diseo que corresponden al dominio del
problema.
Se emplean lo modelos de anlisis (clase de anlisis) y los modelos arquitectnicos
(componentes arquitectnicos).
Paso 2. Identificar todas las clases de diseo que corresponden al dominio de la
infraestructura.
No se describen en el modelo del anlisis, tienen que estar en esta parte. Aqu se
agregan
componentes de: interfaz grfica de usuario, del sistema operativo, de administracin
de
objetos y datos, etc.
Paso 3. Elaborar todas las clases de diseo que no se adquieran como componentes
reutilizables
Hay que describir detalladamente: interfaces, atributos y operaciones de cada clase.
Aqu
Se debe tener en cuenta el tema de cohesin y acoplamiento, y lo visto en el punto
anterior (se lo llama heurstica).
Paso 3a.Especificar los detalles del mensaje cuando las clases o los componentes
colaboran. En
el modelo del anlisis como colaboran las clases entre s, mediante el diagrama de
colaboracin. Cuando se especifican (detallan) las estructuras de los mensajes que se
pasan entre los objetos del sistema para mostrar los detalles de las colaboraciones. Es
una
actividad opcional, pero sirve como base cuando se especifiquen las interfaces ( es la
manera en que colaboran y comunican los componentes (conectividad).

Diagrama de colaboracin con envo de mensajes

Paso 3b. Identificar las interfaces apropiadas para cada componente. la interfaz es el
equivalente
a una clase abstracta que proporciona conexin controlada ntrelas clases de diseo.
una interfaz no tiene estructura interna, no tiene atributos ni asociaciones.
Las operaciones definidas para la clase de diseo, se encuentran ordenadas dentro de
la
interfaz y deben cumplir con el principio de cohesin.

Detalle de la representacin de la interfaz y las operaciones (funciones) que realiza.

En la figura la cohesin se muestra en el hecho de que tienen una sola funcin.
Paso 3c. Elaborar atributos y definir los tipos y las estructuras de datos necesarios
para
implementarlos. Los atributos se describen con las estructuras y los tipos de
datos
UML define el tipo de datos de un atributo con la siguiente sintaxis:
nombre : tipo-expresion = valor-inicial {propiedad cadena}
nombre: es el nombre del atributo.
tipo-expresion: es el tipo de datos.
valor-inicial: es el valor que toma el atributo cuando se crea el objeto
propiedad cadena: define una propiedad o caracterstica del atributo.
En la primera iteracin del diseo a nivel de componentes, los atributos se describen
por
el nombre. Si un atributo aparece varias veces en clases de diseo con una estructura
compleja, es mejor crear una clase separada.
Paso 3d. Describir de manera detallada el flujo de procesamiento dentro de cada
operacin.
Se hace de dos maneras: usando seudocdigo basado en lenguaje de programacin
o
con el diagrama de actividad UML. Cada componente de SW se hace mediante

iteraciones (refinamiento paso a paso). /*en el libro dice interacciones, est mal,
adems est muy mal traducido, por eso no se entiende una mierda*/
En una primera iteracin se define la funcin, ejemplo: calcularCostoPapel().
En una segunda operacin se expande, ejemplo:
calcularCostPapel(peso, tamanio, color): numerico
los atributos son: peso, tamao y color, y numrico es el valor en pesos que devuelve.
La operacin realiza una sola funcin definida manteniendo un alto grado de
cohesin.

Paso 4. Describir fuentes de datos persistentes (bases de datos y archivos) e

identificar las
clases necesarias para identificarlas. Estos generalmente se especifican
(detallan) en el
diseo arquitectnico, pero conviene agregar detalles adicionales a medida que
avanza la
elaboracin del diseo.
Paso 5. Desarrollar y elaborar representaciones del comportamiento de una clase o
un
componente. Es necesario modelar el comportamiento de una clase de diseo. Se
utiliza
para comprender el comportamiento dinmico de un objeto (instanciacin de una clase
de
diseo mientras se ejecuta el programa) mediante la informacin proporcionada por los
casos de uso para ver los eventos que afectan al objeto y los estados a medida que
pasa el
tiempo. Se emplea un diagrama de estado UML.

El diagrama de estados que sigue, ocurre como consecuencia de un evento:

nombre-evento (lista-parametros)[condicin-guardia] / expresin de accim
lista-parametros: son los datos del evento
condicin-guardia: es la condicin que debe cumplirse antes de que ocurra el evento
expresin de accin: define una accin antes de que ocurra, cuando ocurre la transicin

Cada rectngulo es una transicin.

Paso 6. Elaborar diagramas de despliegue para proporcionar detalles de la
implementacin
adicional. Los diagramas de despliegue que se utilizaron en el diseo arquitectnico
representan las principales funciones del sistema. A nivel de componentes se utilizan
para representar la ubicacin de paquetes clave de componentes, aunque es preferible
representar los componentes dentro de un diagrama de componentes.

Paso 7. Factorizar todas las representaciones del diseo a nivel de componentes y

siempre

deben considerarse alternativas. A lo largo de este proceso iterativo se va

perfeccionando
el diseo a nivel de componentes. Debe usarse la refactorizacin durante el diseo /*el
puto de Pressman no dice que mierda es esto, pero se refiere a que a medida que se
realizan las iteraciones en el diseo, en realidad pasa en todos los rdenes, se
presentan
puntos en comn*/
******************************************
HASTA AQU LO QUE SE DIO EN CLASE, LO QUE SIGUE ES PARA COMPLETAR EL
CAPTULO, POR SI TOMA ALGO MS.
11.4 LENGUAJE DE RESTRICCIN DE OBJETOS
Se utiliza para complementar al UML, utilizando una gramtica y sintaxis formales para construir
instrucciones sin ambigedades para describir los elementos del modelo de diseo: clases y
objetos, eventos, mensajes e interfaces.
Este lenguaje se construye en cuatro partes:
1) Un contexto que define la situacin limitada en que es vlida la instruccin.
2) Una propiedad que representan algunas caractersticas del contexto.
Ej: contexto es una clase y la propiedad sera el atributo.
3) Una operacin que manipula o clasifica una propiedad (se refiere a la utilizacin de
aritmtica de conjuntos).
4) Palabras clave que se utilizan para los operadores condicionales, if, then, else, and, or,
not.
Ejemplo de la notacin:
cliente
tiene.autoridadAutorizacion = si
Donde cliente es la clase, autoridadAutorizacion es un atributo booleano de la misma (es una
instancia de la clase)
Este lenguaje es una herramienta para especificar condiciones previas y posteriores de manera
formal , es algo que se debe cumplir antes o despus de algn comportamiento.
Este tipo de sentencias se puede compilar para realizar un anlisis y evaluacin.
En resumidas cuentas estamos empezando a detallar el diseo a nivel de seudocdigo.
11.5 DISEO DE COMPONENTES CONVENCIONALES
Aqu se hace una introduccin al diseo estructurado partiendo de Dijkstra en los 60 y la
propuesta del uso de construcciones lgicas restringidas: secuencia, repeticin y condicin. Son
construcciones estructuradas que restringen el diseo procedimental del SW y permiten una
ms fcil comprensin.
11.5.1 Notacin grfica del diseo
El diagrama de actividad en UML permite representar una secuencia, condicin y repeticin. Este
desciende del diagrama de flujo (el que ya conocemos).

11.5.2 Notacin tabular del diseo

Se utilizan tablas de decisin para traducir las acciones y condiciones que fueron escritas en
forma narrativa, esto hace ms fcil la interpretacin. La tabla tiene: una lista con todas las
condiciones, una lista con todas las acciones posibles (basada en combinaciones de
condiciones). Estas forman una matriz que indica la combinacin de condiciones y las acciones
correspondientes.

Los pasos para hacer la tabla son:

Hacer una lista de todas las acciones posibles que puedan asociarse a un procedimiento
(mdulo).
Hacer la lista de condiciones durante la ejecucin de un procedimiento.
Asociar conjuntos especficos de acciones especficas, eliminando combinaciones especficas de
condiciones.
Definir reglas para que acciones ocurren para un conjunto de condiciones.
11.5.3 Lenguaje de diseo de programas
Tambin llamado lenguaje estructurado o seudocdigo. Utiliza el lenguaje comn (ingls) y la
sintaxis de otro (estructurado). La diferencia de este y el cdigo de programacin es el texto
narrativo (ingls). Si bien no se puede compilar, existen herramientas que permiten conformar
un esqueleto de lenguaje de programacin. Ejemplo de PDL:

11.5.4 Comparaciones entre notaciones de diseo

La notacin de diseo debe servir para facilitar la comprensin y revisin, mejorar la tarea de
codificacin y que le d la capacidad de mantenimiento. El uso de PDL, diagramas o tablas
depender del tipo de diseo que se est realizando.